OpenCL?

[JColyer]

Okay so I'm running out of options for increasing the speed of my 'brute force' DE-less fractal raytracer.  The two options I have left to explore are to move my code to .Net 4.0 with it's built in support for parallel CPU operations or move the code base to OpenCL.  I've been digging around trying to find a decent 'simple' non-realtime OpenCL based implementation just to learn the basics of OpenCL programming from but I'm coming up really short.  Most of what I'm finding is oriented more towards the 'real-time' flying / zooming type of work, but I'm really looking for detail and quality so the 'real-time' portion isn't as important.  Rendering images larger that the display size or window is a must.

Thanks all!

[cKleinhuis]

hi there,

my problem with gpu is the limited floating point precision ... but sure, for the first few ( 40 ? ) iterations it would be sufficent to use a gpu system

for opencl i can say, it is the "open" standard for gpu programming,and should be used ( nor ati or nvidia proprietary )

functionality like big images rendering has nothing to do with the underlying system, because it is a virtualisation your program has to do,
and which shouldnt be too hard, there are a lot of tutorials on how to divide a single render job to many smallers ....

in the last years, texture size was limited to 4096x4096 and hence the output, but nowadays it could be that it is a bit higher ...

so, what you need is to define a virtually image size, and a renderer which renders block by block ( e.g. 64x64 squares ) on the gpu,
save the result in cpu memory, and build up a large bitmap, that can then be saved in standard image formats....

[JColyer]

I just found a flame renderer built using c#/winforms for the GUI and CUDA for the 'heavy lifting'.  So this might be enough to get me going in the multi-tile GPU render game...  It's called Fractron 9000 - full source available on source forge.

Thanks for the feedback!