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.
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.
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.
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.
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.
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.
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 . 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.
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.
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.
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.
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)?
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.