END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

wohoo, if you are finished with the gpu stuff let me know, and be suro to include such params in the package

I must admit, I'm currently unsure about the CUDA part. Unfortunately, there are not those many parts which can be run in parallel in the fractal flame algorithm. But it's possible to certain parts, with some tricks... but if I do so, the memory transfer between CPU and GPU always eats up the advantage of any CUDA computation on my system. In fact, currently I have the complete set ported to the GPU, and can choose which parts to run on it. But it always seems to loose, the pure C solution (which I optimized in parallel) is just faster.
So I'm currently asking myself either to create a totally platform independent CPU solution (without any CUDA features) or to continue with the (for me) more appealing CUDA code.
Any thoughts? :-)

Thank you very much :-)

And this was just an "overlapping" post :-), I'm unsure about the CUDA part, plz see above.
And I just chose CUDA as platform for playing around because it works for ME, I'm no nvidia-advocate or something :-) If the CUDA parallel implementation would work great there would be no reason to move it not to OpenCL or something, I'm just here in the forums to share such thoughts ;-)

Yes, this is my dream/vision: that you can "craft" fractal flames with you fingertips. Not just downloading precalculated stuff (like electric sheep for Android). You DO do it and you LOVE it because you can PLAY with it. But this will need some further investigation/ressources to do, the current project is just one step into this direction :-)

I'm running this with C++, i. E. I'm re-creating the Java renderer from scratch. Therefore I'm easy, because it will be faster in any way :-)
The Java renderer will survive because it renders with more accuracy, has more features (which are not that easy to port) and is much friendlier to try out new stuff.

Best regards

Hello Syntopia,

thanks for your feedback on my work and the interesting link, I will study this as soon as possible :-)

You are asking the right question, the algorithm I use is not optimal for CUDA. But I was still surprised by the poor the results.

I'm using the "standard" way of iterating, but using a large pool of points . At every iteration step I randomly chose a small number of points of this pool and perform the same operation on all those points (in parallel on the GPU). After the iteration the points are written back to the pool. This both ensures that I can do things in parallel and that I walk through many different paths (One thing I tried before was just iterating the whole pool all the time. This gives interesting but unwanted results).

This all works fine but collecting/preparing/coordinating things on the CPU always eats up any advantage from the parallelism. I must admit that I only tested on my i7 CPU which is rather fast and my graphics card is a more mediocre one. So the solution would be not useless at all if I include some more "tricks", but it is not really a "burner" on the other side ;-)

So you led me into the right direction which I avoided at first try because I was a little bit lazy and under pressure from the current "load" of features. Users expect a  faster renderer with all features they know from the Java version. Those are rather numerous so it's really hard to start with a new algorithm under the hood.
But what I have seen is really convincing so I think it makes sense to have three renderers: full-fledged-Java renderer with integrated compiler for experiments etc., fast renderer for doing movies in high quality (the thing I'm currently on) and realtime renderer with less features (at least at the first place).

Need to be a cat... ;-)

Best regards,
Andreas