|
|
Mesh Filters.qtz from Apple OpenCL Developer Examples with Fully Working Mesh Noise, and Mesh Bend Update This is, as the title says, a revised version of the "Mesh Filters.qtz" example from Open CL Apple Developer Examples. In it, is a fully working updated revision of Mesh Noise filter. Also included, is a revised version of the Mesh Bend filter (also posted in a revised "Pages Jiggle.qtz" earlier today), which retains most of the functionality of the original Mesh Bend.
|
I ended up more fully fixing the Mesh Bend in this qtz after posting this. So, all of these filters are 100% of original functionality now.
Here's the update.
Really nice to see all of these working fully again.
What was the problem with the old versions?
a|x
Well, besides the fact that they just didn't work anymore... ;-)
Specifically, the problem is that some constants get reassigned in those two compositions/filters (not allowed), so wherever that happened, new floats had to be made.
You mean there were some constants defined in the OpenCLl kernel, and they were later written to?
a|x
Yeah, exactly. Writes to variables declared " __constant" are a compile time error.
I see.
I'm still really confused about OpenCL. It seems all the tutorials out there concentrate almost exclusively on memory-management, and that's all handled behind-the-scenes in QC. I'm also a little discouraged by what cwright said about OpenCL being slightly crippled in QC by the necessity constantly to shuttle all the data backwards and forwards between CPU and GPU. Hopefully the whole pipeline will be better-optimised in the future.
a|x
This is because memory management is of particular importance on GPUs, and it's quite different from the standard CPU model (where you essentially get a large flat memory space).
It only shuttles data off the GPU it use use it in a non-GPU way (i.e. iterating over output structure elements, or feeding it to javascript). Using it to create images is fine, as is creating meshes. In my experience, a lot of common uses don't simply create images or meshes, which then causes some roundtripping.
Ah, I seeee
Thanks for the clarification cwright.
What still confuses me about OpenCL is how you define what is the 'work item', when you have multiple inputs. I mean, can you have an array as an input, and have the kernel iterate through the array, reading from an arbitrary location in a 2nd texture input, for example?
Also, is it possible to return an array of varying length. OpenCL doesn't seem to have even the most basic array functions, which leads me to suspect this isn't possible.
a|x
Just reading http://www.browndeertechnology.com/docs/BDT_OpenCL_Tutorial_NBody.html which looks like quite a good introduction to basic concepts. I don't know how much of what's mentioned is directly-applicable to OpenCL in QC though.
a|x
The spec itself is a good source of info...
http://www.khronos.org/registry/cl/specs/opencl-1.0.29.pdf
I was watching some videos on the subject when sl was beta and the problem with shuttling data from gpu to CPU is that the pci bus is slow. maybe in the future we will see some other way of connecting the gpu to the CPU. I'm sure there is a good answer to why we still use pci. what Chris says about using cl with js makes since. I guess cl is only a fast solution if you keep the data on gpu in which case you can do some very fast calculations particularly if your doing vector calculations and texturing etc... as the gpu has a specific place it calculates textures etc... that's why there is all this memory management stuff Im thinking. I'm still trying to figure it out. it seems as George said the declaring a constant float4 has been changed to a global.
The whole memory-management thing seems to be critical in OpenCL, I think for a couple of reasons.
GPUs don't seem to have any memory-protection (one of the major reasons OpenCL in QC seems to be so flaky, as I understand it)
GPUs are massively-parallel, so organising kernels so they can work in parallel and still read/write from/to the same memory is key.
I'm vague on the details though, at best...
a|x
The following attachments create structure array that are variable and also outputs an optical flow of the image being read and subsequently written after processing - bit slow, just a quick and dirty mock up.
Uses two really nice images from the new Philippines telescope. [hence about 1MB]
The second attachment works far faster and allows for a much quicker reading of the image array structure produced [color values o to 255].
Some good points all around; in regards of porting command line operable / compilable code,one has to alter the scalars and output terms employed to conform to those preferred by QC, which terms are always given at the beginning of a new OpenCL Kernel patches editor panel.
Also, when porting a kernel that has been laid out in a particular 'tiered' fashion within the function, I have found that it is necessary to place all declared scalars and outputs onto one line for the inputs to fall upon the correct side of the patch in the editor window.
Wrong place.
Cool, let me try that one. Maybe that marching-cubes setup I was tinkering with a while back will be possible, afterall...
a|x
It looks like I deleted my first upload, which is just as well, because it was real total plodder [CPU and GPU yawn].
This attached file is much, much snappier and you've got the option of outputting either a 2d image derived from a Turbulence Array, 2d image derived from a Turbulence image based kernel or a particle grid mesh image.
Have just tried this composition and got an error in openCl kernel. What could it be? (rMBP 10.7.5)
Whatever version of OpenCL that has been loaded in the past has been updated, and there has been some shift in what is considered proper syntax....and/or something with it is just screwed up.
I'm looking at the kernels and failing to understand why a few things are failing in some kernels, but not others. It's doing some really weird thing with going "no previous function prototype" where it seems it definitely should not, and also some weird problem with "main must return int" and how the function ins/outs happen with globals...it may just be screwed up, but I will hold out on that judgement until reviewing a newer OpenCL guide.