AMD Made OpenCL A Bit Faster This Year On Linux

[phoronix]

Phoronix: AMD Made OpenCL A Bit Faster This Year On Linux

To be published on Thursday and Friday of this week is the annual "year in review" articles for the AMD Catalyst and NVIDIA Linux graphics drivers. While those articles are looking at the OpenGL performance for all driver releases made in the past year, some OpenCL benchmarks were also conducted...

http://www.phoronix.com/vr.php?view=MTI1NzI

[blackholesbrightidea]

I just registered to ask the following (nice captcha btw):

Can anyone with good insight/working on the closed/open source driver give an estimation when/if the OpenCl driver will support the Cycles Blender Renderer in OpenCl mode?

I'd be happy to hear a rough estimate like in

* maybe a few months
* 1/2 - 1 year
* more than 1 year / never.

I heard the blender devs say that the problem is in the driver, I d love to hear a driver dev's opinion on the theme.

And in general, if you are working on the drivers, many thanks for your efforts! The improvents you made are awesome!

[Marc Driftmeyer]

I just registered to ask the following (nice captcha btw):

Can anyone with good insight/working on the closed/open source driver give an estimation when/if the OpenCl driver will support the Cycles Blender Renderer in OpenCl mode?

I'd be happy to hear a rough estimate like in

* maybe a few months
* 1/2 - 1 year
* more than 1 year / never.

I heard the blender devs say that the problem is in the driver, I d love to hear a driver dev's opinion on the theme.

And in general, if you are working on the drivers, many thanks for your efforts! The improvents you made are awesome!

It would be wise for blender devs to get involved on the LLVM/Clang mail lists and work with the R600 Target now inside LLVM Proper. The more they learn about LLVM the better OpenShadingLanguage, OpenColor, OpenImageIO and Cycles will become.

[zeealpal]

I just registered to ask the following (nice captcha btw):

Can anyone with good insight/working on the closed/open source driver give an estimation when/if the OpenCl driver will support the Cycles Blender Renderer in OpenCl mode?

I'd be happy to hear a rough estimate like in

* maybe a few months
* 1/2 - 1 year
* more than 1 year / never.

I heard the blender devs say that the problem is in the driver, I d love to hear a driver dev's opinion on the theme.

And in general, if you are working on the drivers, many thanks for your efforts! The improvents you made are awesome!

I'm a regular Phoronix reader, and an AMD (7970) Blender user

I'd hate to be disappointing, but its unlikely Cycles will support OpenCL, and if it does, far in the future. Reasons include, but are not limited to:

• AMD/ATI's OpenCL Kernel Compiler cannot currently compile the Cycles kernel, its rather large (Apparently ~20MB IIRC)
• AMD Cards have many cores, but each being weaker generally, so handling something as complex as Cycles is not well suited to them.
• As mentioned above, the architecture of Cycles (using a shader virtual machine) does not work well on AMD cards/drivers.
• Given AMD has shown little change in this (maybe their GPU's cannot support such large kernels) why support OpenCL at the moment, given it will take extra effort, while giving no benefit to AMD users, or nVidia ones (CUDA was faster for Cycles than OpenCL on nVidia hardware)

The final issue is, even nVidia GPU's are currently having issues supporting all the features of Cycles, such as Open Shading Language, or Non progressive rendering. Cycles won't be getting simpler, we can only hope GPU's, and their drivers become capable of running Cycles with all its features (AMD ones too, as nVidia seems to want GPGPU to go Tesla)

[Personal Opinion]
I think the Blender Dev's should have architected/designed Cycles to work on both AMD/nVidia hardware, perhaps using only OpenCL, as being locked into a single vendor seems to go against the Open Source nature of Blender. the LuxRays library which LuxMark (used in this benchmark) was designed to be used for any render engine, not just SmallLuxGPU. This was mentioned to the Cycles dev but he came from the Octane team, and had already started Cycles with CUDA)
[/Personal Opinion]

I hope my essay answered your questions :P

[Veerappan]

I'm a regular Phoronix reader, and an AMD (7970) Blender user

I'd hate to be disappointing, but its unlikely Cycles will support OpenCL, and if it does, far in the future. Reasons include, but are not limited to:

• AMD/ATI's OpenCL Kernel Compiler cannot currently compile the Cycles kernel, its rather large (Apparently ~20MB IIRC)
• AMD Cards have many cores, but each being weaker generally, so handling something as complex as Cycles is not well suited to them.
• As mentioned above, the architecture of Cycles (using a shader virtual machine) does not work well on AMD cards/drivers.
• Given AMD has shown little change in this (maybe their GPU's cannot support such large kernels) why support OpenCL at the moment, given it will take extra effort, while giving no benefit to AMD users, or nVidia ones (CUDA was faster for Cycles than OpenCL on nVidia hardware)

The final issue is, even nVidia GPU's are currently having issues supporting all the features of Cycles, such as Open Shading Language, or Non progressive rendering. Cycles won't be getting simpler, we can only hope GPU's, and their drivers become capable of running Cycles with all its features (AMD ones too, as nVidia seems to want GPGPU to go Tesla)

[Personal Opinion]
I think the Blender Dev's should have architected/designed Cycles to work on both AMD/nVidia hardware, perhaps using only OpenCL, as being locked into a single vendor seems to go against the Open Source nature of Blender. the LuxRays library which LuxMark (used in this benchmark) was designed to be used for any render engine, not just SmallLuxGPU. This was mentioned to the Cycles dev but he came from the Octane team, and had already started Cycles with CUDA)
[/Personal Opinion]

I hope my essay answered your questions :P

That answers a few questions I had as well. I tried to compile the Cycles kernel as a Piglit test on r600g, but it (expectedly) blew up in my face. When I started looking at the code, I realized that it was essentially CUDA code with a bunch of #DEFINEs to translate the CUDA code to OpenCL at compile time. There are plenty of pieces of code that look like they also are not-completely-compliant OpenCL, and should probably be fixed by the Blender folks.

I can't say how long it will be before the clover state tracker can handle this code, but I would assume we'll be looking at 6+ months at the minimum, and more likely a timescale of 1+ year.

[Zalamander]

I think the Blender Dev's should have architected/designed Cycles to work on both AMD/nVidia hardware, perhaps using only OpenCL, as being locked into a single vendor seems to go against the Open Source nature of Blender. the LuxRays library which LuxMark (used in this benchmark) was designed to be used for any render engine, not just SmallLuxGPU.

With the reliability of the OpenCL drivers (especially at the time), you couldn't just have "designed" it to work on either hardware. It was a already a gamble to just have it be more-or-less gpu-friendly C code. It paid off in at least working on NVIDIA hardware and working well with the autovectorization in GCC.
As for LuxRays: There's no point in integrating an external dependency to solve a comparably small part of Cycles that had already been solved by the time it was made public. There's also no reason to believe that the driver problems would've been avoided by just using LuxRays.

When I started looking at the code, I realized that it was essentially CUDA code with a bunch of #DEFINEs to translate the CUDA code to OpenCL at compile time. There are plenty of pieces of code that look like they also are not-completely-compliant OpenCL, and should probably be fixed by the Blender folks.

You must've not looked at it very closely, then. There's very little CUDA-specific code in Cycles. Pretty much the only parts that are specific to CUDA/OpenCL (as far as the kernel is concerned) are the texture load/store functions. Apart from that, it is standard C code that is used for CPU, CUDA and OpenCL. As for strict standard compliance, there might be such cases, but it is worth noting that OpenCL does work on NVIDIA hardware.

I can't say how long it will be before the clover state tracker can handle this code, but I would assume we'll be looking at 6+ months at the minimum, and more likely a timescale of 1+ year.

Supposedly there was a statement from AMD which basically reads "we give up"

[zeealpal]

With the reliability of the OpenCL drivers (especially at the time), you couldn't just have "designed" it to work on either hardware. It was a already a gamble to just have it be more-or-less gpu-friendly C code. It paid off in at least working on NVIDIA hardware and working well with the autovectorization in GCC.
As for LuxRays: There's no point in integrating an external dependency to solve a comparably small part of Cycles that had already been solved by the time it was made public. There's also no reason to believe that the driver problems would've been avoided by just using LuxRays.

No, certainly not, what you said is my understanding at this point in time. . I was saying that (as an opinion) from when (before) Cycles was started, rather than at any time later in its development. Then again, it would be a different render engine if it had started with luxrays as part of the base, probably less advanced too, so not having used LuxRays might have been better for the advancemnt of Cycles. Except for AMD users perhaps :P

[smitty3268]

As for strict standard compliance, there might be such cases, but it is worth noting that OpenCL does work on NVIDIA hardware.

I'm not sure that means much, since NVidia is pretty famous for having a very "forgiving" implementation of OpenGL. It wouldn't surprise me if they allow all sorts of non-compliant OpenCL, especially since they started out with CUDA first.