[Bf-cycles] OpenCL and AMD GPUs
George.Kyriazis at amd.com
Tue Oct 28 02:25:18 CET 2014
Thank you, Thomas, for the welcome..
Yes, for GPUs (I'm generalizing without knowing too much about nvidia, though), a more modular design will most definitely benefit. The thing that I don't know, though, is what effect will a modular design have to CPU processing.. with queues between components (and components mapping into GPU kernels). Cache coherency may help performance, but on the other hand, the overhead of queues may slow things down.
On Oct 27, 2014, at 8:01 PM, Thomas Dinges wrote:
> Hi George,
> your initiative is very welcome and I welcome you to the bf-cycles list.
> Splitting the Cycles kernel is a good idea and it will hopefully fix the problems on the AMD architecture, while improving performance for GPUs in general as well. We managed to do „ok“ in the past few years on nvidia, but we were also constantly hitting boundaries and limitations. So a more future proof and modular design is likely the way to go.
> I am looking forward to more details, and we are available when you have questions.
> Best regards,
> Thomas Dinges
> Am 27.10.2014 um 21:34 schrieb Kyriazis, George <George.Kyriazis at amd.com>:
>> Greetings bf-cycles,
>> I work for AMD, and we have been thinking about working in the OpenCL kernel (read: have started working on it). It is, I presume, a well-known fact that the OpenCL implementation has "issues" on AMD.
>> Our current approach is to split up the OpenCL kernel into multiple (smaller) kernels, in order to get better utilization of the GPU. I've had brief discussions with Martijn, Brecht and Ton, and they all seem eager to finally "fix" (for a lack of a better term) OpenCL, which is a good sign.
>> Technical details have not been discussed yet, but an open forum like bf-cycles is a better place for that.
>> As a starter point of discussion, I'd like to comment about the main motivation of the kernel split. As it is well known, the AMD OpenCL implementation has some problems compiling the current OpenCL kernel. This has been mainly attributed to the length of the kernel, and problems with register allocation. Although the above is correct, those causes fail to address the main issue, which is the fact that a huge kernel (like cycles) that is a straight-forward port of CPU code, does have a lot of code divergence. Code divergence causes a lot of workitems go idle during kernel execution, which is not a good thing.
>> Splitting the kernel allows for each (sub)-kernel to have better GPU utilization, and hence better performance. As a side-effect, it decreases the size of each kernel, and makes things easier for the register allocator. So, the current problems that the AMD OpenCL implementation has will not express themselves in a split kernel. Our current thought is to have those individual kernels communicate via queues.
>> Any questions / comments / etc. about our approach is welcome, of course.
>> George Kyriazis
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
> Bf-cycles mailing list
> Bf-cycles at blender.org
More information about the Bf-cycles