I'm also playing with OpenCL and I think is a good thing to start exploring.
I started playing with it recently and I consider that my knowledge on this area is still small but I will follow your discussion very closely. I also want to make some observations to what has already been said. Most of then made from my small knowledge side of OpenCL so don't be afraid to correct me. When you are talking about the fallback to normal CPU execution you are talking about an optimized CPU execution? I mean, as I understand OpenCL, there's always at least one OpenCL capable device, the CPU. So the same code that was written for the GPU version will run (maybe not optimized for that) even if the user doesn't have a GPU with OpenCL features. So when you talk of fallback to CPU you mean to provide special code for that instead of letting the GPU prepared kernels execute in the CPU? I don't know if I like this approach. The maintenance price will raise and we even don't know if the GPU prepared kernels will be slower or not in the CPU, think that we will have an OpenCL multithreading code that will benefit all the compute units available in the CPU. Or if we start in the OpenCL world maybe the OpenCL context was created grouping more than one CPU, or a CPU + a small limited GPU. The Idea that seduces me more is to have standard OpenCL code that will ask for a desired configuration based on memory needs, image support or not for the OpenCL device, etc... and some kind of selector functions or context builder functions will try to build the best context for the calculation that is going to be performed. In this way in some machines one will end up with a context of GPU, CPU + GPU, GPU1 + GPU2, CPU, etc... depending on the hardware. If the "ideal" context can be build... perfect, if the "ideal" context can not be build... at least the code will work and will behave in the same way. Our work will be to provide a unique way of providing work to our "OpenCL calculus server" and efficiently try to deliver the work through all the created queues of the context. Different parts of Blender maybe desire different ideal context, so the context builder functions can change the OpenCL context and the way the queues are managed. If this idea is not quite clear and you think it could be interesting we can discuss it in future emails. If you think all this is in the wrong way please state it :-). Cheers Artur. El 24/08/2010, a las 19:18, Jeroen Bakker escribió: > Hi all > > I have been experimenting with OpenCL and are planning a basic framework > to support it in Blender. > > main features are: > * OpenCL is disabled by default, CPU fall-back must ALWAYS be > available. OpenCL can be enabled with command-line parameter > * Compiler directive to completely disable OpenCL in Blender. > * Basic implementation to access and use GPU-devices > * I am not targeting the blender-render, but other time-consuming > processes (fluids, node systems etc) > > I think this matches the basic blender principles: > * can work on standard home PC's > * blender installation is unzipping an zip > > Are other people also busy with this subject? > > Best regards, > Jeroen > > http://wiki.blender.org/index.php/User_talk:Jbakker > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
