[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: upcoming Blender 4.4 ROCm driver requirements



Hi Cory,

It's sad to hear. Thou we work in completely different fields I know how it feels to be burned out. I wish you a quick return to form.

If the max version of ROCm in trixie will be 5.7 - so be it. It covers all current hardware, but it will limit the max version of Blender that should be included in trixie to 4.3.x. I think its perfectly reasonable as it was released fairly recently on nov 19 2024. For people who want newer Blender version it should be possible to compile alpha version with lower ROCm version set in the make file.

I was thinking about automatic Blender tests for a while actually. Blender has a testing suite for all kinds of stuff, but AFAIK it's not used outside of Blender Foundation infrastructure. The repo for tests that could be relevant to GPUs is here [1]. There are specific Cycles [2] EEVEE [3] and Workbench (viewport renderer) [4] test sets and a lot, lot more. Test data repository (scenes and reference images) is here [5] - it takes around 2GB. It should be easily tailored for ROCm related features. From what I know some test results are known to be wrong, they should be ignored even if they do not produce identical reference images. I don't know which one specifically. There are also tests that fit with the GPU coverage like OpenGL, and in the future - Vulkan, but are not related to compute or ROCm. EEVEE and Workbench are in that category as they both use OpenGL. Vulkan backend is WIP and can be enabled as an experimental feature. My opinion is that Cycles should be a priority as it needs ROCm to work on GPU at all.

Overall I think automatic tests are something worthwhile, but it could require collaboration with Blender developers to some degree. At least for deciding which tests should be a priority and where to report potential issues. I can try to do some work like stripping unwanted tests and modify python test files after the decision is done what is needed.

Additional info:
Blender Foundation runs their buildbot and testing suite on Rocky Linux i I'm not mistaken.
Most recent problems with AMD GPUs on Linux machines [6,7,8].

[1] https://projects.blender.org/blender/blender/src/branch/main/tests/python [2] https://projects.blender.org/blender/blender/src/branch/main/tests/python/cycles_render_tests.py [3] https://projects.blender.org/blender/blender/src/branch/main/tests/python/eevee_next_render_tests.py [4] https://projects.blender.org/blender/blender/src/branch/main/tests/python/workbench_render_tests.py
[5] https://projects.blender.org/blender/blender-test-data

[6] https://projects.blender.org/blender/blender/issues/126458
[7] https://projects.blender.org/blender/blender/issues/131773
[8] https://projects.blender.org/blender/blender/issues/112084

As always thank you for your work.
Best regards,
Jakub Jaszewski

W dniu 1/26/25 o 22:14, Cordell Bloor pisze:
Thanks Silex,

On 2025-01-24 13:28, silex wrote:
Forwarding information about driver requirements that are about to be in upcoming Blender version 4.4 scheduled for release march 18 this year. Beacuse of rendering artifacts with ROCm 6.1 the min version will most likely be bumped to 6.2.4.

I think our goal is to get the HIP Runtime to ROCm 6.3 / LLVM 18 before the freeze. With that said, I'm not sure how we are going to do it. It seems like the entire Debian ROCm Team is just kind of exhausted. I know I am. Back in March/April, I did the blitz for Ubuntu 24.04, but I don't think I have it in me to do that again.

With regards to Blender support, one thing I think we're missing is a continuous integration job that verifies that Blender is functioning. Is there a test suite we could run to verify that Eevee and Cycles are functioning correctly on AMD GPUs? If there exists a script that does some headless renders and compares the outputs against a reference image, that would be helpful.

Sincerely,
Cory Bloor



Reply to: