What exactly are the developers doing wrong from your point of view?
1 Like
Well, the jury is still out on whether AMD will be able to compete with NVIDIA next gen - a smaller chip process doesnât assure much.
But for those who want to make the jump, just keep the old NVIDIA card(s) in a ârender machineâ that you can use until things are better. Thatâs what I do, and itâs great.
Wrong design and less work. Example they work on CUDA 100 hours, work on OpenCL 10 hours, maybe 20 hours.
Are you play console port games? These games are generally bad optimised and bugged. Why, because designed for console, and after that converted to PC, and not worked required for porting and valaa. Result is bad.
For Blender, they design for CUDA, after that convert OpenCL, and they are not working required for convert, and result is bad.
For say this is good this is bad, must master coders write codes (CUDA master and OpenCL master) and comparison this two code.
How do you get to those calculus?
The last big feature in Cycles related to nvidia is optix render and optix AI denoiser support, all changes that came from Patrick Mours, an nvidia developer. Not a Blender developer.
3 Likes
Every version have OpenCL bugs. One version fix, another version return. I know, because this is my job. Nobody said why Optix does not work on AMD cards, then Blender developers are bad. This is Nvidia exclusive feature. We want standard features work right.
Man, If you are so experienced in openCL programming (so you could do those bold statements about how OK openCL api actually is), why donât you just help BF guys to fix those bugs?
Blender is an Open Source project after all.
4 Likes
You donât seem to get how a libre project like Blender is maintained.
Blender is not Cycles. Cycles was developed by Brecht, outside of Blender project.
Brecht choosed to work on CUDA because it was something he wanted to explore at a time when OpenCL had 1 year of existence and CUDA 4 years of existence.
Then, Ton convinced Brecht to mature his project under protection of Blender project.
But Cycles is still available as a stanalone. There are versions of Cycles for different proprietary software.
There are contributors to Cycles who donât care about Blender.
Anybody can contribute to Cycles.
Yes, according to anybody coding Cycles (Developers from AMD included), Cycles is not build for OpenCL and can not be as efficient as a software built for it.
But that does not mean that Blender Team will drop Cycles just to build another version for OpenCL from scratch.
They did what they could to provide an OpenCL support. But they canât be experts in all fields.
And their reply if you ask them on chat how to have better performance with OpenCL, will be : Use and support LuxCoreRender which is another libre project, perfect for that.
3 Likes
I am not OpenCL programmer, I am graphic programmer and I have a job, I am not have a time.
zeauro
I know this, but Cycles was a whole with Blender. And I try explain OpenCL not bad, programmers did not work required. But this is cause Nvidiaâs monopolism. This is valid for Cycles and other render engines, especially open source render engines.
But some guys are fanatic Nvidia users, and defend Nvidia blindly, so they are not know what they defend.
Are you talking about Cycles?
Yes, I am talking about Cycles.
Cycles will have full support for OpenCL once AMD makes drivers that work as advertised. It is true that AMD is starting to get more serious about software quality, but Nvidia has rarely made software that did not work (at least from the 2nd generation onward).
Even AMDâs Prorender works better on Nvidia than Radeon, that should tell you something when the manufacturerâs own code runs better on the competing product.
4 Likes
They refactored the whole project to use smaller kernels to even getting it to work with OpenCL. If I remember correctly, that wasnât sufficient and AMD had to actually fix their drivers in order to getting it to work.
If I understand you correctly, you are claiming that OpenCL in on par with CUDA. That is not true in my experience. I am working a lot with machine learning where in theory OpenCL could be use as a replacement for CUDA. Pretty much everyone gave up, because it simply didnât work well enough in practise.
3 Likes
I did not use Pro Render. This is your claim.
Are you a programmer, am I right?
I am graphic programmer, and I always says: API is only a interfece. If you programmed good, then your program will be good, if you programmed bad, then your program will be bad. If API donât support somethings, or some parts not works good, then you write your own functions.
Example, when I write DirectX program, I am usually not use DirectX tools, I am use my own tools, own functions, own utility classes. If I totally addicted DirectX or OpenGL functions, I am never write good programs and I am never be creative. DirectX or OpenGL, CUDA or OpenCL only a interface with GPU and programmer, not too much.
If you are relying on an interface with a clear specification, such as OpenCL, you are still dealing with various drivers which have different issues. Thatâs an unfortunate reality. Now, the users also have different driver versions making it an absolute nightmare to work with bad drivers.
As programmer, you have to rely on quite a few things and there isnât a practical workaround for every driver issue. Programming around bugs is a nightmare as you never know what is going to change in the next versions. Optimally, you would still support different driver versions, but in practise thatâs very difficult.
If you have a broken driver behind the API, the situation becomes very difficult. In that regard, CUDA seems to be way more reliable than OpenCL.
Here is what Redshift guys say when asked about opencl:
quote:
âThis has been touched upon many, many, many times in these forums. OpenCL is not possible with Redshift.â
I donât think that thayâre just nvidia fanboys - they are one of the most skilled gpu developers with huge gamedev experience.
They also said that theiâd love to see redshift working on amd if it was so simple.
Same things goes for DirectX and OpenGL. Drivers (Nvidia and AMD) always have bugs and you must write your codes know with this reality.
I have usually met problems not based driver, its based programming errors. If I met driver problem, I am easily change my driver.
Now the point is: OpenCL drivers seem to be particularly buggy according to people who are actually using them. Definitely way more unstable than CUDA.
And to make it very clear: There have been lots of actual driver issues. As an example, the OpenCL kernels could not be compiled due to issues in the drivers. That forced the developers to implement smaller kernels, but even with those, it was necessary to fix issues in the drivers. That was doable because AMD actually funded the development and pretty much had to fix their driver issues.
This is way worse than working around some minor driver issues where you have to avoid using certain functions.
Thatâs it for me regarding OpenCL vs CUDA.
I spoke to an RS dev at one of the early get-togethers in London and he said that they had a version working on opencl, but there were so many roadblocks to performance it wasnât worth continuing at the time. This was probably 5 years ago at least. I know that they would love to be platform agnostic if they could - sounds like there could be some movement on that in the few months.
This is not excuse on programming society. We are always met like this situations (not only for graphic APIs, nearly in almost all areas).