quadrium | flame oly uses one processing core?

quadrium | flame : flame fractals & strange attractors : build, mutate, evolve, animate

Post Reply
Posts: 1
Joined: Sun May 20, 2007 7:06 pm

quadrium | flame oly uses one processing core?

Post by paul » Sun May 20, 2007 7:12 pm

Is it true that quadrium | flame oly uses one processing core?
I have a brandnew 8 core intel mac pro.
Render jobs only run on one core at a time and switch from core to core not makeing use of the full rendering potetial of the machine. Is this due to software implementation? If so, are you planning on altering the code to use multiple processors in the future?



Posts: 1464
Joined: Wed Feb 04, 2004 6:02 pm

Post by gandreas » Mon May 21, 2007 9:20 am

This is true.

In quadrium2, every pixel is completely independent, and can be generated as needed, so we can separate the image up into different areas and let multiple threads generate each area and then stitch them all together.

In flame, however, the only way to know the value of any given pixel is to generate the entire image (i.e. apply all the iterations) and look at the final result. So if we were to break the image up, we'd basically just generate the entire image twice, which would be no performance improvement. This is because the whole algorithm is iterative (the "I" in "IFS"), and there is no way to "skip ahead".

Basically, the renderer generates a point (figures out its location and color) and then merges that with a running total (a histogram of each pixel, showing how often it is "hit"), and then repeats (using the location of the last pixel to do the next one), until it generates as many points as you've asked for. It then converts those histograms to RGB values to display it.

I've tried doing things like separating the "generate the points" from the "merge with histograms" but it turns out that overhead of communicating safely between the two results in making the whole thing actually run slower (and use two cores to do so, instead of just one). I've also looked into generating and merging multiple sets of iterations in parallel, but again, the overhead of synchronizing them destroyed any advantage. The fundamental problems is that this is just not an algorithm designed to be parallelizable. (I've got a few other options to play with, but they will require a significantly higher amount of memory, and I don't expect miracles out of them)

Future versions will, however, be able to render movies using multiple cores (since each frame can be rendered in parallel and independently), but that won't help rendering in general.

Posts: 2
Joined: Mon Dec 10, 2007 2:07 pm

Re: quadrium | flame oly uses one processing core?

Post by DocDEB » Tue Aug 11, 2009 9:04 pm

I use Apophysis running on Windows 7RC which is running in a VM (Parallels). My machine is an 8-core Mac Pro. The VM is set to 4-procs. Apophysis is set to use 4 threads.

When rendering in Apophysis 4-cores are maxed => very short render times. q | f of course uses only one. So it appears that multi-processor use is certainly possible.

Apophysis and q | f are two different programs but they are essentially doing the same thing. Apophysis is open source. I wonder if a look at the source would give some ideas on implementation of multithreading in q | f?

With Snow Leopard just around the corner it would seem that there will be opportunities to bring the quadrium family of programs into the 64-bit multi-processing world.

BTW I'm so tempted to get q | flame for my Touch... OK I just bought it. The store has the wrong program description displayed... something about the locations of heavenly bodies...?????

Post Reply