Cycles AMD HIP device feedback

Just tested with a production shot with a bunch of hair. CPU used for creating the BVH as normal. Rendering though it hovers around 9% (Ryzen 7 2700), about the same with a 3080.

Make sure you disable the CPU in the blender system prefs from being a rendering device.

My friend, my opinion of you is very ‘Good’ compared to people I have seen over the years in AMD camp. My point was not to hurt you in anycase. It is people like you who are genuinely trying to do good work and are open to feedback … that give me hope about AMD.

Some of my bad experience in past with AMD has been with the ML related support over the last 5-6 years, and many a times I ran into ‘opaque’ walls of silence (and no progress).

To put it simply, At the end of the day a lot of people who invested in AMD hardware are feeling burnt at this point as we can simply not use the GPU (hardware we paid ‘lot of money’ for) for rendering on Blender 3.x. And with kind of resources AMD has… both in terms of financial capacity and engineering workforce, it doesn’t feel right as end-user to see the current state of things. In an ‘Relatively Opaque’ organization as AMD, its not clear, where the bottleneck has been, but wherever it is, its causing economic loss down the line to end-users.

Having said that, at least I personally don’t want an engineer (my assumption) like you to feel burnt out over that ‘backlash’ which is a ‘collective fault’ and not the fault of an individual imho. My apologies, if the impatience on our part is getting to you. Keep up the good work, and thank you for being active in the community here.

3 Likes

Thanks. I tried with just the GPU. Both Default and Experimental options result in the same. I see you mentioned 3080, so it might be that CUDA/Optix is able to consume 100% but HIP doesn’t seem to at least in my case. :frowning:

As i said in my post, did you go itno the system prefs and disable hte CPU from rendering?

I believe by default, when using the GPU, the CPU will help out since blender 3.0

Yes, I tried just the GPU, via system pref.

My question is are you using Nvidia or AMD GPU? your response mentioned 3080.

I could be wrong here, but while rendering currently we’re not yet using the OpenGL interop. So the framebuffer will have to come down to the CPU and back to display. So I would expect some CPU usage.

https://developer.blender.org/D14360

1 Like

It also would not surprise me if NVIDIA and AMD measurements for this are not directly comparable? I can imagine “usage” being measured in different ways in various drivers and hardware.

We are certainly not using 100% of the NVIDIA GPU either. There’s always going to be some time where the GPU is waiting, or where there’s not enough rays to occupy all cores, or rasterization and tensor cores are not used at all.

There may be more things to optimize here, but a 90% or 100% number in the task manager is not a clear indication either way.

2 Likes

I’ll mention that with OpenCL when I rendered it showed closer to 100% “compute” usage and also in GPU-Z. With HIP its almost flat line at 90% through the entire render. Not fluctuating much.

Will need to test CLI to see if there would be any difference.

Also if you have any recommendations for better software GPU usage monitoring on Windows?

As far as I know MSI Afterburner and Asus GPUTweak are much more accurate then default windows task manager. I have seen this issue crop up many times in Blender discord, where people complained that in Windows Task Manager, the GPU utilization was almost negligible (below 10%) even during rendering.

For Win Task Manager issue you mentioned. Most users are unaware that you have to change one of the windows to “compute0” or “compute1” then it shows actual GPU usage. Like mentioned also used GPU-Z. Both confirmed hovering around 90% of usage. I’ll give MSI afterburner a go though.

I’m looking for anyone to confirm with an AMD GPU in Windows if they are also seeing this, or might be something particular to my setup.

1 Like

If your decision to buy AMD was based on OpenCL support in Blender at the time, that support was removed for Blender 3.0 (not by AMD’s decision). Our solution was to add HIP support to cover as much support for AMD GPUs as possible.

I do agree with this sentiment, and I’m wondering why OpenCL was removed even though HIP wasn’t ready for most existing cards yet, even though CUDA is still available well after OptiX was introduced. OptiX also started with newer NVIDIA models and later gained support for some (but not all) older models, and nobody got upset about that; the difference is that CUDA support was not dropped from Blender prematurely.

1 Like

I wasn’t partial to the decisions made by the blender team, but I do work with OpenCL for the day job.

(edit: I’m now doubting if ‘I wasn’t partial to’ means what I meant it to mean :wink: . I meant I had no influence on the decision)

The situation with OpenCL is a sad one. It’s deprecated on MacOS and it doesn’t get any love from either NVidia or AMD on windows or linux either. It’s basically still around until it dies. On the GPU driver side all energy is spent on Vulkan (probably a good thing) and the planned/promised (by Khronos) OpenCL/Vulkan interop hasn’t really materialized.

NVidia has really cornered the GPGPU/machine learning market with CUDA and it’s using all it’s marketing power to keep it that way. NVidia and Apple basically killed OpenCL between them to promote CUDA or Metal. And while OpenCL is still supported on most systems , for the time being, it doesn’t have any real future right now.

So I guess when the Cycles rewrite was decided it was decided to not spend lots of time on a dying platform. Which I can understand. I wouldn’t use OpenCL for any new project right now either.

It’s a sad state of affairs. I really liked OpenCL. To get the same sort of code-once-use-everywhere GPGPU code is hard now. Maybe Vulkan compute shaders are the way (if MoltenVK gets a bit better. Curse you, Apple). Or maybe HIP becomes a usable platform on all major OSes. I really hope it will, but I’m not very optimistic. I think AMD is really trying, but I’m afraid they’re just not rich enough compared to NVidia.

/rant

1 Like

As an RX580 owner on linux i’m surprised some people were actually able to use OpenCL up til recently, it hasn’t worked for me in years. I was able to get it going briefly back in 2019, but with the compile time it ended up taking 2-3 times longer than if i used my i7 4770 cpu, with the added bonus of it also locking the whole system up to a crawl because all the gpu resources were taken up…

Can we expect for HIP to come bundled with the standard amdgpu package? I remember this being a major pain in the neck with OpenCL in the old fglrx days where it didn’t work unless you jumped through a bunch of hoops tracking down which separate packages you had to install to get the GPU to show up in the compute device list in the Blender settings.

3 Likes

Nvidia was “prepared” because the tools required to add a Nvidia rendering backend to Cycles, CUDA and OptiX, already existed, was thoroughly tested and in a relatively mature state. Pretty much all that had to be done to add CUDA and OptiX to Cycles-X was to write all the GPU specific code. As for why Nvidia didn’t “drop non-RTX GPUs”, that’s because a lot of stuff required to get RTX GPUs working can be re-used with non-RTX GPUs dating back a few generations without much issue.

In the case of AMD, they were updating HIP to add new features and/or fix bugs. Along with that they were bringing HIP to Windows both in the form of a new compiler and GPU driver updates. And then they were also writing the HIP specific code (which as far as I can tell is mostly a HIP adaptation of the CUDA code). Each of these tasks were probably handled by a different team within AMD, so it could be argued that development could of happened quicker. But the reality is that the different teams had to work closely with each other to ensure what they were doing was right, and not some error in the project another team was working on. And as such, development in certain sectors probably had to be delayed as one team fixed an issue the other found.

Yes, Polaris and Vega are supported in HIP, but there are bugs somewhere. Either in the compiler or the GPU driver, or both, that stop these GPUs from working with the HIP implementation found in Blender. Yes, it would be nice if AMD fixed that, but at the moment they haven’t and I know that upsets a lot of people and has lead to many people losing trust in AMD with regard to Blender support. And you are allowed to feel that way. However, an investigation is underway to see what AMD needs to do to fix these issues. What will the outcome be? Will the issues be fixed and Polaris/Vega support be added? I have no idea. And you have every right to believe that AMD won’t fix this issue in a timely manner. Because all they’ve said so far is that they’ll “investigate it” with low priority. There’s no guarantees.

Linux support was “dropped” because there were compiler and/or driver bugs on Linux that needed to be fixed for the HIP implementation in Blender to be fixed. As for why these issues were fixed in Windows first and not Linux or both at the same time? I don’t know. I assume that AMD put more priority on getting things to work on Windows first because that’s where a large portion of their users are. Plus HIP support was being added to Windows, more focus had to be put on making sure everything worked properly on this new platform.

Linux support is planned. The plan is to add support for it in Blender 3.2. However, with all the things that a company says they “plan to do” or “plan to investigate”, you don’t have to believe what they say will actually happen in a timely manner. And you don’t have to trust them. And if you don’t trust AMD in adding support for Vega + Linux to Blender’s HIP implementation in a timely manner, then feel free to look at alternatives.

4 Likes

Guys moderation warning; negative feedback is fine, but keep it constructive, don’t make it personal with employees who clearly have no control over many of these decisions.

https://wiki.blender.org/wiki/Contact/CodeOfConduct

5 Likes

According to the 3.2 planned release schedule there are 10 days left to Bcon 2.

What is the update on HIP ? Is it still targeting 3.2 ?

HIP support is already in Cycles. Support has been these since the release of Blender 3.0. Or are you asking about a specific feature being added to Cycles HIP (E.G. Linux support)?

Sorry thought I had mentioned the OS. Linux support mainly.

There is a patch available from an AMD employee that enables AMD HIP support in Cycles on Linux. It can be found here: ⚙ D14360 Linux and GL Interop enablement for Cycles on HIP

As noted in the patch, the Cycles developers are waiting for ROCm 5.1.0 to release before officially activating support on Linux. So when Linux support is enabled is based on when ROCm 5.1.0 is released.

2 Likes

Any eta on when older AMD GPU’s like a R480 can be used with HIP both for WIndows/Linux?

3 Likes