I love AMD! They don’t have the fastest gpus but they do bring amazing performance at a small price point,and even greater performance if you go up in class. But amd and blender do not get along,rendering with amd takes ages. Why? Because configuring opencl if hard asf ,and if you want to use Linux tuff luck. I hope that with volcan things will change but for now rendering is a struggle. If any of you have different experiences and opinions I would like to hear them.
AMD loves you too.
They don’t have the fastest gpus but they do bring amazing performance at a small price point,and even greater performance if you go up in class. But amd and blender do not get along,rendering with amd takes ages.
Have you actually compared this? What GPU did you use? Rendering with Cycles in general takes “ages”. It was my impression that as of recent (with support from AMD engineers) OpenCL on AMD had decent performance, even surpassing NVIDIA (though with a reduced feature set).
Why? Because configuring opencl if hard asf ,and if you want to use Linux tuff luck.
What’s so hard about it? As far as Blender is concerned, all you need to do is pick “OpenCL” as your compute device. On Linux, you need to use the proprietary drivers (fglrx), the free ones don’t support OpenCL yet.
I hope that with volcan things will change but for now rendering is a struggle. If any of you have different experiences and opinions I would like to hear them.
Vulkan most likely won’t change anything. It’s not a viable backend for Cycles until there is a C-like language (like OpenCL) available for a Vulkan context - GLSL is not enough.
To answer your original question…
Why doesn’t blender do well with AMD?
Historically, the OpenCL implementation of AMD was very poor, far from what was necessary to run Cycles. OpenCL could never be a first-class citizen during most of the development time. When things finally improved, it was pretty late: The original author (and core developer) of Cycles had already left for greener pastures.
Not just Cycles but most of GPU render engines have problems with AMD. I guess it is easier to develop for CUDA?
And Linux drivers are mess, always were and nowdays even more…
Why? Because AMD has garbage drivers and garbage support for the OpenCL standard in its compiler. Every piece of OpenCL code in Blender is compliant with the standard. AMD, rather than actually fixing things on their own end, instead offered to change Cycles to fit their compiler. And they didn’t even do that right. They came in, started the project of splitting the kernel into pieces, dumped a bunch of unfinished code on the Blender devs, and haven’t been heard from since. Now, it’s definitely not their job to “fix” Cycles, but to commit to a project like that and then suddenly disappear without any explanation is very unprofessional.
In addition, OpenCL just “isn’t there” in terms of being a fully featured coding solution. Many path tracers with GPU support only support CUDA, or have a gimped OpenCL implementation (like Cycles). OpenCL issues aren’t a Blender anomaly. A few renderers claim that they’ll have full OpenCL support in their next versions. I’ve yet to see any proof of this. There’s a reason the market penetration in the CG/VFX field for nVidia hovers somewhere between 80-85%. The majority of the remainder are made up of studios who have Mac workstations sitting around.
On a personal note, AMD made the only ever piece of reference equipment (as in made and sold by AMD) in the 100+ PCs I’ve built over the years to ever straight up catch on fire at base clocks with stock cooling. So, yeah, AMD will never see another penny from me, and I can’t in good faith recommend them to anyone interested in the 3D field either.
… another thing, it is new tech and open source, so it’s not really loved with proprietary run profit sector. Can consider as communism vs capitalism. OK? Ali baba rings a bell?
Also worth checking…
- Lux Renderer (CPU + OpenCL; open source)
- Indigo renderer (CPU + OpenCL - v4 public beta)
- FireRender (3dsMax 2016 only; open source)
- FireRays (news on Fire Rays 2, open source library)
- Octane promise to port CUDA to “all available processing units”
Sometimes (often) those who come late® to the party bring the fun & joy with them
Is it really?
A 200$ AMD gpu is faster than a Titan in Cylces rendering, so I don’t see the problem? Regarding setting up, just click on GPU compute.
I wouldn’t be so sure about that. There’s no tool to verify this. It may be syntactically compliant, though I’m not even sure about that. Again, no reference implementation exists to verify this. (That’s one of the things Vulkan addresses, btw)
There’s also a lot of things that the standard leaves undefined, i.e. where does it say a compliant implementation has to be able to compile arbitrarily large kernels? Nowhere, because you can’t expect this to work on hardware that was designed to run very short programs like shaders without tremendous compiler magic.
AMD just happened to be too lazy with their implementation, whereas NVIDIA chose just the right amount of laziness to still be able to get away with compiling Cycles. At the same time, NVIDIA never implemented OpenCL 2 (which AMD did), so there’s that.
This isn’t true. Companies love open-source software, as long as it benefits their business: Webkit, LLVM/Clang, Linux, they all are directly run by large companies or have major corporate backers.
Nobody besides NVIDIA likes CUDA - why would a company want to build a product that depends on technology from another company, when an equally good “open” alternative exists? It makes no sense. The problem is, that alternative doesn’t exist. OpenCL isn’t (or at least wasn’t) good enough in practice.
Also, OpenCL is not open-source. There is no source! It’s an “open”, royalty-free specification. Neither AMDs nor NVIDIAs implementation is open-source (if they were, that would be great!). There is no open-source reference implementation, either.
Thanks for clearing the murky parts and corrections… got me motivated to do more thorough research. :yes:
OpenCL (Open Computing Language) is an open, royalty-free parallel programming specification developed by the Khronos Group, a non-profit consortium.
The OpenCL specification describes a programming language, a general environment that is required to be present, and a C API to enable programmers to call into this environment.
Also some other notes to get a bit better grasp on…
Both of those CPU + GPU implementations only use the GPU for intersection testing when using them together, and support only a subset of features when using GPU only. The next two are “toy” renderers without a full suite of production-ready features and tools, and the last has spent well over a year claiming full OpenCL support without providing any proof that they’ll have 100% feature parity with CUDA.
Not quite, LuxRender does actually use OpenCL CPU devices as well as OpenCL GPU devices at the same time, for the full OpenCL render (not just ray interstection).
It does work with Intel CPU + Intel iGPU + 2x nVidia GPU’s, however the chances of getting any decent seen to compile on all those devices is next to nothing!
Personally, I find it much more useful when LuxRender uses the iGPU for tonemapping, which includes basic post pro, tonemapping, mixing light groups and some filters. Works better than the CPU does especially on 4K images.
OpenCL right now may not support as much as CUDA at the moment, but it’s not like the Blender developers haven’t had their own headaches trying to support Nvidia hardware (like that infamous bug report about the new architectures actually having less performance than the old ones with no apparent fix in sight).
It might be argued that some of the issues is simply the attempt to support GPU’s in general for very heavy tasks such as rendering (as opposed to powering the graphics and other effects in games). It would seem to be that the only real way forward might be for Nvidia and AMD to actually change the architectures in a way that, while still being fast for games, become more and more favorable for general computing tasks as well.
Attention to the confusion, Vulkan is an API for gaming and graphics as is DirectX12, Mantle ( it is based on Mantle ), and is the new close to the metal OpenGL version.
OpenCL will still be there for computing.
Crimson 220.127.116.11 has an issue so you can’t render on GPU.
I hope fix will be released.
When will volumetric shaders and HDRI be computed on GPU ?
I really, really don’t understand this. AMD gpus haven’t been working with Cycles (and loads of other soft) for years and years. Why are people still buying these cards when they know they don’t work? Is it that they would rather come here and complain then get some work done?
Can we have some kind of auto-reply on anyone who posts these silly threads that says something to the effect of “Look, it doesn’t work - it is probably never going to work - get another card”
With cycles ?
Dont have this problem with mine 7970’s based system with luxrender anyway ( not tested with cycles yet )… But something to know, thoses beta drivers are specially there for update, fix particular games, for this one it was for fix a bug with Doom and and the 390x. ) i will take care to dont allways use thoses hotfix drivers for OpenCL render ). As with Nvidia, thoses hotfix drivers are made for a specific case, and it can happend they have not fully been tested for other games or other tasks.
I have maybe not follow, but i had the feeling that cycles have been updated with opencl support ( i should said again ), even if yet not all features are implemented ( each release of Blender, they add what was miss ).
And if we look at it, they have been what ? 2 updates of Blender since the 2.77, when CUDA Cycles version is running since how many time ?
But this is why i have use Blender + Luxrender since a long time instead of cycles anyway.
OpenCL dont concern only AMD, the problem is Nvidia still dont support last version of OpenCL, performance and stability of OpenCL drivers with Nvidia gpu’s are a nightmare just because they dont want to support it as they could ( cant blame them to dont bring full support on OpenCL vs Cuda ) ( It is quite funny when the director of Khronos group, is the number 2 of the Nvidia director board ).
Lets be honest, i absolutely not recommend anyone with an Nvidia gpu’s to use OpenCL render computing for now. Not untill Nvidia have stop to sabotage their OpenCL drivers.
Just for remind that the physic engine in Blender is based on Bullet and use OpenCL . ( Bullet who have been developped from DMM in collaboration with AMD ).
double post-- sorry-
Yes, you can’t use cycles GPU compute with 18.104.22.168.
I have test, and effectively… it render but it bug, everything is grey ( even if the objects are rendered, but it seems the light paths is not fully calculated )…
I have check the usage on my gpu’s during the renders and they are completely abnormal ( 69% on the first and 45% on the second )… both should be ofc at 100%.
no problem before with the 16.5.2 ( not the hotfix version for the last Doom )…
I will recommend to dont use this driver, ofc, could be a problem if you are playing Doom and have a 290x-390x… As i dont play Doom right now, back to 16.5.2 so for me. ( And suddenly, i know why i only use Quadro and FirePro at work )
Um, there is no GPU compute. At least there was no option on my old machine… about three years ago. Maybe things changed, or maybe the card is not expensive enough.
As far as I know Nvidia is worse for Linux than AMD. At least for me, AMD GPU never worked in Linux on my old machine but with my current machine I tried really hard - meaning I did pretty much everything the net threw at me, and nothing worked… by which I mean that every time I installed the drivers it either didn’t sense my Nvidia GPU or flat out broke the display. I reinstalled Linux more than 50 times in a few months during that time, and now, with the generic drivers selected the GPU option is not even present in the properties panel.
Are you Really speaking aboout … 3 years ago ? … Cycles was not support OpenCL 3 years ago …it was only support Nividia proprietary solution named CUDA and was monterarize it ( well, Blender 2.4 was support OpenCL but it have been retired, and only re introduced with Blender 2,77 released some months ago ) .
Guys… come on… OpenCL Cycles introduced some weeks ago, miss some features , not due to OpenCL , but that they have not get the time to implement it… CUDA cycles is here from some several years, maybe let 2-3 months and some updates for Blender for the Cycles OpenCL team to update all features available on Cycles and fix all codes problem no ?