Vulkan GPU rendering

[MirceaKitsune]

I assume everyone in the Blender community is aware of how iffy GPU rendering is, on both Cuda (Nvidia) and especially OpenCL (AMD); Many video card models can’t be guaranteed to work as the specs need to be just right… for instance the official stance on GCN is that 1.0 might work, whereas 2.0 is the only version receiving support officially. The free video drivers and libraries (Radeon, Nouveau, Mesa, etc) also don’t currently support it, which is a huge bummer for us Linux users.

Often times this got me wondering why there isn’t any other API which could allow rendering on the GPU… one that permits full flexibility in programming on the video card, while also being a common standard across every make and model of card. Last night it suddenly struck me that, unless I’m greatly misunderstanding the requirements for GPU based raytracing, there already is: Vulkan.

Now I’m no expert on the matter, but I did read up on the basics: Vulkan is the predecessor to OpenGL, offering a completely new approach to the way GPU processing is done. The relevant bit here is that unlike OpenGL, which only lets you modify vertices or niche aspects of polygonal surfaces, Vulkan should allow you to program anything you wish on the GPU. Unless there are limitations that I’m missing here, this should provide the environment Cycles needs to do its calculations.

What are your thoughts on a Vulkan GPU renderer, which would hopefully be available for all Nvidia / AMD / Intel cards that have Vulkan support? Has the idea ever been considered, perhaps even being worked on? Is it technically possible, and if so is it a good idea (not a waste of time) to attempt implementing it?

[SterlingRoth]

CUDA rendering has never been iffy in cycles. There are some older cards that have been depreciated, and some cards certainly work better than others, but it is a fairly reliable platform that has worked for cycles from day 1.

[bvz2000]

OpenCL is actually an open standard, not proprietary to AMD. It’s just that nVidia is already using their own standard (Cuda) which seems fairly well supported by enough third party applications (because they were out first) that the company feels comfortable continuing to push it vs. OpenCL.

That said, their cards can also run OpenCL. It’s just that they put more effort into their Cuda technology and are not at all interested in making it cross compatible. So software vendors are forced to make a choice, Cuda vs. OpenCL vs. doing both.

Since some have already settled on Cuda they are continuing on that path. Others will choose Cuda because it seems to have either better performance or more features (depending on your opinion on the matter) and they decide that that outweighs having a smaller target market. Others will (and have) chosen openCL because it is open (or for any number of other reasons).

But ultimately, OpenCL is an open standard like you are asking for.

That said, I have zero experience with either one so I can’t say whether one is better than another.

[skw (Stefan Werner)]

I don’t think you understand fully all the things that Vulkan is not: Vulkan does not abstract away the differences between hardware. Quite the opposite, the purpose of Vulkan is to expose hardware details to the application that a higher level abstraction (such as OpenGL) hides. A developer using Vulkan compute to write a hardware renderer still needs to deal with differences in hardware capabilities, driver versions and driver bugs just like with OpenGL.

The problems with OpenCL and Cycles are found mostly in different hardware and driver capabilities - some drivers are unable to compile the kernel, some hardware lacks functionality that Cycles would need.

That said, it is perfectly possible to write a render engine using OpenCL for Nvidia hardware, as AMD demonstrates with ProRender.

[MirceaKitsune]

Thank you for the answers. I’m aware that OpenCL is an open standard, which is one of its advantages over Cuda that is not. This is one of the reasons why I use an AMD card over Nvidia; AMD is friendlier to the FOSS community, which in consequence involves better builtin drivers for Linux… Nvidia however is proprietary about everything and some of their technologies might not even be available to us, so for a user in my department they are a less preferable option.

Indeed I was hoping that Vulkan would be a more generalized standard, that lets you program a piece of software and expect it to work on all video cards equally. Of course if the program deliberately uses card specific variables, that situation can change… I think Cycles wouldn’t necessarily need this for ray trace calculations though.

[BoFZeVampire]

Hi,
It seems that OpenCL and Vulkan will converge:
‘…We are also working to converge with, and leverage, the Khronos Vulkan API — merging advanced graphics and compute into a single API…’

Khronos Releases OpenCL 2.2 With SPIR-V 1.2

[MirceaKitsune]

@BoFZeVampire

Hi,
It seems that OpenCL and Vulkan will converge:
‘…We are also working to converge with, and leverage, the Khronos Vulkan API — merging advanced graphics and compute into a single API…’

https://www.khronos.org/news/press/khronos-releases-opencl-2.2-with-spir-v-1.2

Wow… that is quite the news. Since Blender already has OpenCL for GPU rendering, this definitely answers my question: It will be using Vulkan after all

[Grimm]

Hmm, Nvidia drivers have always been better than AMD’s on Linux, at least in my experience. This is the biggest reason why I have personally always gone with Nvidia cards even before I was using them to render with.

I think it would be ok to combine the graphic display side with the compute side, but we pretty much already have that now. When I download an Nvidia driver it includes support for Directx (if on Windows), OpenGL, OpenCL, and CUDA. Otoy has been working on a cross-compiler that will take CUDA code and compile it to AMD driver bite code where it will run on AMD cards. But as usual AMD has driver issues that stop it from being a complete solution. In the end, what it comes down to, is that OpenCL just does not have feature parity with CUDA. And until it does, it’s going to be difficult for vendors or the Blender devs for that matter to support AMD cards fully. That will still be true even if they merge OpenCL with Vulkan.

[BeerBaron]

@MirceaKitsune"

Many video card models can’t be guaranteed to work as the specs need to be just right… for instance the official stance on GCN is that 1.0 might work, whereas 2.0 is the only version receiving support officially.

Cycles support for GCN 1.x has been dropped in 2.79 and it will reportedly not work.

The free video drivers and libraries (Radeon, Nouveau, Mesa, etc) also don’t currently support it, which is a huge bummer for us Linux users.

You don’t have to use a free driver just because you’re a Linux user, unless you intend to make your life more miserable (in that case: you’re on your own). The non-free NVIDIA driver works fine. The situation on AMD is a bit complicated, but there is a working driver there.

Last night it suddenly struck me that, unless I’m greatly misunderstanding the requirements for GPU based raytracing, there already is: Vulkan.

You are misunderstanding it. Vulkan is more limited than OpenCL, in many regards. Then again, OpenCL doesn’t expose the graphics pipeline (which Cycles doesn’t need) like Vulkan does.

Vulkan does not really have more features than OpenGL, it’s just a different abstraction layer. OpenGL has a lot of legacy cruft that makes API usage less efficient than it could be. For a renderer like Cycles, API overhead usually doesn’t really matter, there are very few API calls involved. The performance benefit is mainly for games that may issue many thousands of draw calls to rasterize individual objects.

The other benefit of Vulkan is that shaders are pre-compiled, like in Direct3D. This reduces startup time and makes programming shaders less error-prone. The same feature exists for OpenCL 2, where the kernels can be pre-compiled to SPIR-V (the same IR used by Vulkan).

The relevant bit here is that unlike OpenGL, which only lets you modify vertices or niche aspects of polygonal surfaces, Vulkan should allow you to program anything you wish on the GPU.

Both OpenGL 4.3 and Vulkan have GLSL Compute Shaders, which can be used for “anything”. However, those are still more limited than OpenCL (no pointers).

Unless there are limitations that I’m missing here, this should provide the environment Cycles needs to do its calculations.

It’s not about “calculations”, it’s about the language. OpenCL and C and CUDA C are similar enough for Cycles to share most of its code on all platforms. GLSL is too different, the entire kernel would need to be rewritten.

What are your thoughts on a Vulkan GPU renderer, which would hopefully be available for all Nvidia / AMD / Intel cards that have Vulkan support? Has the idea ever been considered, perhaps even being worked on? Is it technically possible, and if so is it a good idea (not a waste of time) to attempt implementing it?

There is no “good” cross-platform API now or in the foreseeable future. Vulkan doesn’t work on Mac, OpenGL is crippled on Mac, Metal only works on Mac, OpenCL 2 doesn’t work on Mac/NVIDIA, CUDA doesn’t work on AMD (but on Win/Linux/Mac).

OpenCL 1.2 remains the best option for now.

[Tea_Monster]

@MirceaKitsune"

I assume everyone in the Blender community is aware of how iffy GPU rendering is, on both Cuda (Nvidia) and especially OpenCL (AMD)

I’ve been enjoying the speed-up of GPU rendering on my Nvidia cards for many years.

Works just fine thank you!

[skw (Stefan Werner)]

@BeerBaron

There is no “good” cross-platform API now or in the foreseeable future. Vulkan doesn’t work on Mac, OpenGL is crippled on Mac, Metal only works on Mac, OpenCL 2 doesn’t work on Mac/NVIDIA, CUDA doesn’t work on AMD (but on Win/Linux/Mac).

At least, Nvidia is slowly moving towards OpenCL 2.0:
https://streamhpc.com/blog/2017-02-22/nvidia-enables-opencl-2-0-beta-support/

For Apple platforms, it does appear that Metal and CUDA are the only supported options we’ll have there in the long run. I don’t expect them to update their implementations of OpenGL or OpenCL any more, nor do they show any interest in Vulkan.

[BeerBaron]

@skw

For Apple platforms, it does appear that Metal and CUDA are the only supported options we’ll have there in the long run. I don’t expect them to update their implementations of OpenGL or OpenCL any more, nor do they show any interest in Vulkan.

Most Mac GPUs for the foreseeable future will be AMD-based though, so CUDA is problematic. I don’t have any experience with it, but from a cursory look Metal SL seems close enough to OpenCL C to be a viable backend for Cycles.

[JustinBarrett]

@Grimm

Hmm, Nvidia drivers have always been better than AMD’s on Linux, at least in my experience. This is the biggest reason why I have personally always gone with Nvidia cards even before I was using them to render with.

I have to say that from my experience this is correct…I actually was a big ati fanboy back ‘in the day’…as time went on though I started to realize that nvidia had just plain better and more stable drivers…and hardware…I don’t know if ati cut corners or anything, but it was crystal clear that if I wanted stability I needed to go with nvidia…I only came to this conclusion in 2010 or 2011 when my skyrim game kept crashing…before that I had issues in blender and other games…I borrowed an old nvidia(don’t remember the model) from a friend and from then on I stayed nvidia…I don’t really care about the name brand, but I do need stability…

Since I have also moved to linux…and almost any linux user will tell you that using amd graphics is a poor choice.

[Tea_Monster]

@MirceaKitsune

Thank you for the answers. I’m aware that OpenCL is an open standard, which is one of its advantages over Cuda that is not. This is one of the reasons why I use an AMD card over Nvidia; AMD is friendlier to the FOSS community, which in consequence involves better builtin drivers for Linux… Nvidia however is proprietary about everything and some of their technologies might not even be available to us, so for a user in my department they are a less preferable option.

Indeed I was hoping that Vulkan would be a more generalized standard, that lets you program a piece of software and expect it to work on all video cards equally. Of course if the program deliberately uses card specific variables, that situation can change… I think Cycles wouldn’t necessarily need this for ray trace calculations though.

You can’t pick your hardware based on politics. You pick what works. Any kind of artwork should be about creating, not preaching. I picked Nvidia as it works. Until very recently, AMD GPUs did not work, or had a lot of problems rendering with Cycles.

I don’t understand how people can sit there with a card that doesn’t work for YEARS, and convince themselves that they are fighting some brave anti-corporate agenda (Like AMD is giving it’s cards out for free). You should be creating and making stuff, not looking at your computer and waiting an appreciable chunk of a decade for a driver update.

You are a 3D artist, not a corporate/OS/political/software evangelist.

[MirceaKitsune]

@Tea_Monster

You can’t pick your hardware based on politics. You pick what works. Any kind of artwork should be about creating, not preaching. I picked Nvidia as it works. Until very recently, AMD GPUs did not work, or had a lot of problems rendering with Cycles.

I don’t understand how people can sit there with a card that doesn’t work for YEARS, and convince themselves that they are fighting some brave anti-corporate agenda (Like AMD is giving it’s cards out for free). You should be creating and making stuff, not looking at your computer and waiting an appreciable chunk of a decade for a driver update.

You are a 3D artist, not a corporate/OS/political/software evangelist.

I’m not using AMD cards because I need to support someone’s agenda; I’m using them because AMD is closer to the open-source community, and the free drivers (not the proprietary ones) are better for their cards. To some of us, this sort of thing matters.

I simply don’t want to rely on or have proprietary software on my machine. Already I make an exception with Skype since I have friends there… I don’t plan to increase it any further. Nvidia doesn’t understand my side of things as well as AMD, so they lose customers on my side on the fence.

[Ace_Dragon]

@Tea_Monster

You can’t pick your hardware based on politics. You pick what works. Any kind of artwork should be about creating, not preaching. I picked Nvidia as it works. Until very recently, AMD GPUs did not work, or had a lot of problems rendering with Cycles.

I don’t understand how people can sit there with a card that doesn’t work for YEARS, and convince themselves that they are fighting some brave anti-corporate agenda (Like AMD is giving it’s cards out for free). You should be creating and making stuff, not looking at your computer and waiting an appreciable chunk of a decade for a driver update.

You are a 3D artist, not a corporate/OS/political/software evangelist.

AMD has made changes to their product development and business that make them appear as a viable choice for reasons other than ideology now (look at Ryzen and Polaris, look at the more frequent driver release since the Crimson versions started coming out).

One also shouldn’t forget that it was an AMD API creation attempt that inspired the creation of Vulkan (Mantle), everyone is benefiting from that now including the Nvidia fans (who are also benefiting from their recent moves in the GPU market by way of lower card prices).

[Romanji]

@MirceaKitsune

I simply don’t want to rely on or have proprietary software on my machine…

That is some kind of ideology which you have there and exactly what Tea_Monster described. You put your ideology above your creativity and as such limiting it. It shouldn’t be about proprietary or free software, just about what tool do you need to get the job done as efficient as possible.
Every minute you get out of optimizing your workflow is one minute more you can spent on creating.

On the other hand it has nothing to do with ideology when you want to have more options and want to be a little bit future proof.
With Nvidia you get access to CUDA and OpenGL, with AMD you’ll get only OpenGL.
That is still a very clear advantage.
If you are stubborn like me you want to have this option available.

[BeerBaron]

@MirceaKitsune

I’m not using AMD cards because I need to support someone’s agenda; I’m using them because AMD is closer to the open-source community, and the free drivers (not the proprietary ones) are better for their cards. To some of us, this sort of thing matters.

As it is, the best-working AMD driver is not completely FOSS either. Maybe it will be, maybe it won’t. NVIDIA also panders to the FOSS community, large parts of CUDA are FOSS (just not the drivers). Either company acts in their economic interest, not out of ideology. AMD scores brownie points with people like you by shipping an inferior product that’s more “open” (whatever that means). I don’t think you’re getting a good deal out of this.

@Ace Dragon

One also shouldn’t forget that it was an AMD API creation attempt that inspired the creation of Vulkan (Mantle), everyone is benefiting from that now including the Nvidia fans (who are also benefiting from their recent moves in the GPU market by way of lower card prices).

Who is actually benefiting from Vulkan the most? It’s AMD users with slow AMD drivers on slow AMD CPUs. The NVIDIA drivers never had that much driver overhead to begin with and the Intel CPUs ran the drivers (which are bottlenecked by single-threaded performance) 50%+ faster.

If you look at the benchmarks for these low-overhead APIs like Mantle, Vulkan and D3D12 you will very rarely find a game that benefits massively on a real-world gaming PC at high quality levels. Most games are not designed to require a gazillion draw calls.

NVIDIA actually did go the “open” route by providing AZDO extensions to OpenGL when AMD was still fucking around with its proprietary Mantle API. There was nothing stopping AMD from adopting those OpenGL extensions besides the fact that their OpenGL drivers were crappy as well.

[Romanji]

The reason we don’t see this technical advanced games is because of the limited power of consoles.
Star Citizen might be the first game which will use that power since its an AAA+ PC exclusive.

[MirceaKitsune]

@Romanji

That is some kind of ideology which you have there and exactly what Tea_Monster described. You put your ideology above your creativity and as such limiting it. It shouldn’t be about proprietary or free software, just about what tool do you need to get the job done as efficient as possible.
Every minute you get out of optimizing your workflow is one minute more you can spent on creating.

On the other hand it has nothing to do with ideology when you want to have more options and want to be a little bit future proof.
With Nvidia you get access to CUDA and OpenGL, with AMD you’ll get only OpenGL.
That is still a very clear advantage.
If you are stubborn like me you want to have this option available.

You can call it an ideology too. For me it’s primarily three different reasons:

• I do not feel that proprietary software actually is mine. As in, I do not sense that I’m using something I’m allowed to own in any classic sense of ownership, but rather something I’m borrowing which belongs exclusively to somebody else. Why would I want to use a program that’s so tightly under the control of a third party, I’d be a criminal if I even tried to share it or copy it to another computer I own? Thank modern copyright fanaticism for consolidating this view in my mind.
• You cannot know what lies within a proprietary piece of software. With open-source and the official software repositories of Linux distributions, an application is always secure, because if anyone tried to sneak something in people would notice it in the source code then point it out and whoever did it would be in serious trouble. With proprietary software however, you cannot check what’s in the code… so how do you know the devs didn’t hide means of spying on you or facilitating viruses or an OS kill-switch? With Windows 10 for instance, Microsoft can force updates on your computer and you can’t disable them, meaning they have the centralized power to control every Windows device in the world! With all the surveillance and censorship scandals going around, people should think twice about this sort of thing and not dismiss it easily.
• I don’t like relying on the idea that a program will go away if the group behind it abandons it or ceases to exist. If you’re using a proprietary piece of software, it will be there for as long as its developers continue issuing updates, but once they stop that program becomes frozen in time and will eventually end up so outdated it will stop working on any up-to-date OS. With open-source software this is a risk too, however if the original developers abandon it, you or someone else can still fork it and continue its development, thus there are lower chances the application will disappear.