Page MenuHome

GPU Subdivision: Crash after opening particular files
Closed, ResolvedPublic

Description

System Information
Operating system: Linux-5.15.0-27-generic-x86_64-with-glibc2.35 64 Bits
Graphics card: AMD Radeon RX 5700 XT (navi10, LLVM 13.0.1, DRM 3.42, 5.15.0-27-generic) AMD 4.6 (Core Profile) Mesa 22.0.1

Blender Version
Broken: version: 3.2.0 Alpha, branch: master, commit date: 2022-04-30 11:49, hash: rBac88123e29d4
Worked: 3.1

Short description of error
Crash occurs when trying to open a file with GPU subdivision enabled
Crash probably started to happen after library updates

So this was one of the more painful bisects, but it's related to a bump in dependencies for 3.2.x here https://developer.blender.org/T95206

Exact steps for others to reproduce the error

  • Open blender (default scene)
  • Enable GPU subdivision
  • Load attached file

Here is the output of blender --debug-all :



Sample blend file that does not open

Screencast of the problem (GPU Subdivision)

Related Objects

Mentioned In
T97993: subdivision modifier crashes blender
rBf4827d08bc9b: Build: disable usage of GLEW, CLEW, CUDA, GLFW in OpenSubdiv
D14898: Build: disable usage of GLEW, CLEW, CUDA, GLFW in OpenSubdiv
T97963: Blender 3.2 / Linux - Crashing To Desktop at opening any .blend file
T97877: Broken shadow in solid mode with GPU Subdiv
rB56407432a6aa: Fix T94479: GPU Subdivision surface modifier does not apply to Cycles renders
T97873: Blender 3.2beta version adds Subdivision Surface, which crashes directly
T97806: Blender 3.2.0 beta linux crashes with subdivision surface modifier
T97702: Crash loading demo flat-archiviz with 3.2 Alpha
Mentioned Here
rB8d9d5da13706: Cleanup (UI): Make space for more internal button flags
rB502e1a44b948: Cleanup: fix compiler warnings on macOS
rBb47c5505aa37: Fix T96892 Overlay: Hiding all of a mesh in edit mode causes visual glitch
rB1bb7fda600c0: CMake: Fix noisy PUGIXML warning.
T97330: Adding subdivision surface modifier to default cube causes silent crash.
rBL62917: Linux: OpenSubdiv 3.4.4
rBf4827d08bc9b: Build: disable usage of GLEW, CLEW, CUDA, GLFW in OpenSubdiv
D12034: GHOST/X11: setup GLEW and GLEW for EGL
rB3c14f02eac36: Build: add scripts to build dependencies for Windows and macOS.
rBe86b62f1951b: Fix wrong task priority for particle distribution and tanget computation
rB17eb8a9cebd5: Cleanup: remove special cases for getting internal span or single
T95206: Libraries Changes for Blender 3.2
P2918 (An Untitled Masterwork)
P2917 (An Untitled Masterwork)
T97702: Crash loading demo flat-archiviz with 3.2 Alpha

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Unfortunately the crash logs do not provide much insight. I can open the attached file without issues, so the problem could be with one of the library files that you've linked, as you've suspected.

This is a file without any libraries, but I still can't open it using 3.2.
3.1 opens it fine.

Hi, can you disable GPU subdivision and then load the file?: EditPreferencesViewportSubdivisionGPU Subdivision
There is a subdivision modifier on your object so I want you to check if crash is related to GPU subdiv feature.
Also I can't reproduce on current master (blender version 3.2)

Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: Intel(R) UHD Graphics 620 Intel 4.5.0 - Build 30.0.101.1660

Hi, can you disable GPU subdivision and then load the file?: Edit → Preferences → Viewport → Subdivision → GPU Subdivision

I tried this running with --factory-startup and disabled GPU Subdivision as you instructed, and it does open the file without any problems. With the file open, the moment I click on the checkbox to enable GPU Subdivision, blender crashes.
Might this be a linux specific problem since you can open the file normally?

I also added a screencast showing the problem. Nice find on the GPU Subdiv! Thanks.

@Omar Emara (OmarSquircleArt) or @Jacques Lucke (JacquesLucke) according to hardware list you both have similar system (Linux + AMD GPU)
Can you confirm this crash?
Also test T97702

I can reproduce the issue. It seems to be the same issue that I just mentioned 20 min ago on #blender-coders.
Seems to be related to opensubdiv, will try to bisect.

Couldn't bisect it in a reasonable amount of time right now, issue might also be caused a library update.
Stack trace: P2917
Some errors from asan, but not sure if those are related: P2918
I can open the file when I turn off WITH_OPENSUBDIV.

Couldn't bisect it in a reasonable amount of time right now, issue might also be caused a library update.

Same also mentioned in T97702#1349274
So this was one of the more painful bisects, but it's related to a bump in dependencies for 3.2.x here
@Jacques Lucke (JacquesLucke) , can you merge these reports if both are same?
I'm marking this as confirmed

Pratik Borhade (PratikPB2123) renamed this task from Segfault trying to open a file to GPU Subdivision: Crash after opening particular files.Mon, May 2, 1:50 PM
Pratik Borhade (PratikPB2123) changed the task status from Needs Information from User to Confirmed.
Pratik Borhade (PratikPB2123) triaged this task as High priority.
Pratik Borhade (PratikPB2123) updated the task description. (Show Details)

The new version of OpenSubDiv has some changes for OpenGL initialization problems on MacOS. Maybe this causes some issues on AMD cards. Or maybe it is something else.

Hi, can you disable GPU subdivision and then load the file?: Edit → Preferences → Viewport → Subdivision → GPU Subdivision

Just any FYI: this resolved the segmentation fault for me locally too

I can confirm : I I disable the GPU subdivision, no more crash. I didn't have this bug on the 3.2.0 alpha.

I was searching for a bug that matched my problem before creating a new one, and found this. Of all my blend files that stopped working recently on 3.2 builds, disabling the GPU subdivision resolved the problem and blender doesn't crash when opening the files. Verified with e86b62f1951b 3.2 beta.

The last build of 3.2 alpha that worked for me was 17eb8a9cebd5. Using this build I didn't have to turn off the GPU Subdivide and it opened my blend files as expected. I wasn't getting builds everyday, so there might have been newer builds that also worked, but all of the builds since 17eb8a9cebd5, blender 3.2 crashed on opening most of my blend files.

Ubuntu 20.04.4 LTS
Package: rocm-libs
Version: 5.1.1.50101-48
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon RX 6600 (dimgrey_cavefish, LLVM 13.0.1, DRM 3.45, 5.13.0-40-generic) (0x73ff)
    Version: 22.0.0
    Accelerated: yes
    Video memory: 8192MB

Given the function it crashes in P2917 , the only crash i could see in that function would be OSD_OPENGL_HAS(ARB_direct_state_access) is true but glNamedBufferDataEXT is a nullptr.

@Sybren A. Stüvel (sybren) can you validate what opensubdiv is using for our linux? glew or the glapiloader? (grep your OSD build folder for OSD_USES_GLEW and OSD_USES_INTERNAL_GLAPILOADER and see which one pops up)

prodding through the binary it appears the glapiloader is used, this would only happen if it can't find glew

can you take a look here?

Given the function it crashes in P2917 , the only crash i could see in that function would be OSD_OPENGL_HAS(ARB_direct_state_access) is true but glNamedBufferDataEXT is a nullptr.

glNamedBufferDataEXT is provided by EXT_direct_state_access, not ARB_direct_state_access. Since they are checking for ARB_direct_state_access, the function to call is glNamedBufferData, not glNamedBufferDataEXT. Looking at the last commit to the file in question, this is probably an oversight on their part when switching from EXT_direct_state_access to ARB_direct_state_access.

@Sybren A. Stüvel (sybren) can you validate what opensubdiv is using for our linux? glew or the glapiloader? (grep your OSD build folder for OSD_USES_GLEW and OSD_USES_INTERNAL_GLAPILOADER and see which one pops up)

prodding through the binary it appears the glapiloader is used, this would only happen if it can't find glew

Hmmmm my build dir shows this:

> grep -E '(OSD_USES_GLEW|OSD_USES_INTERNAL_GLAPILOADER)' -rn
external_opensubdiv-build/glLoader/CMakeFiles/glLoader_obj.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW
external_opensubdiv-build/opensubdiv/CMakeFiles/osd_static_cpu.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW
external_opensubdiv-build/opensubdiv/CMakeFiles/osd_static_gpu.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW
external_opensubdiv-build/opensubdiv/CMakeFiles/osd_dynamic_cpu.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW -Dosd_dynamic_cpu_EXPORTS
external_opensubdiv-build/opensubdiv/CMakeFiles/osd_dynamic_gpu.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW -Dosd_dynamic_gpu_EXPORTS
external_opensubdiv-build/opensubdiv/tools/stringify/CMakeFiles/stringify.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW
external_opensubdiv-build/opensubdiv/sdc/CMakeFiles/sdc_obj.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW
external_opensubdiv-build/opensubdiv/vtr/CMakeFiles/vtr_obj.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW
external_opensubdiv-build/opensubdiv/far/CMakeFiles/far_obj.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW
external_opensubdiv-build/opensubdiv/osd/CMakeFiles/osd_cpu_obj.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW
external_opensubdiv-build/opensubdiv/osd/CMakeFiles/osd_gpu_obj.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW
external_opensubdiv-build/regression/common/CMakeFiles/regression_common_obj.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW
external_opensubdiv-build/regression/common/CMakeFiles/regression_far_utils_obj.dir/flags.make:5:CXX_DEFINES = -DGLFW_VERSION_3 -DOPENSUBDIV_HAS_CLEW -DOPENSUBDIV_HAS_GLSL_COMPUTE -DOPENSUBDIV_HAS_GLSL_TRANSFORM_FEEDBACK -DOPENSUBDIV_HAS_OPENCL -DOPENSUBDIV_HAS_OPENGL -DOPENSUBDIV_HAS_TBB -DOPENSUBDIV_VERSION_STRING=\"3.4.4\" -DOSD_USES_GLEW

so it would seem OSD_USES_GLEW is passed.

Running strings lib/libosdGPU.a | grep -iE 'GLEW|GLAPI' shows symbols for both GLEW and (internal) GLAPI.

I'm not sure how this is supposed to work when we build Blender with extern/glew and use an older GLEW for the library dependencies. We'd have to be lucky the symbols are compatible between versions.

I think we should actually not be using GLEW for OpenSubdiv, which seems was the case for the 3.1 libraries.

Some errors from asan, but not sure if those are related: P2918

I think those are related to https://github.com/PixarAnimationStudios/OpenSubdiv/pull/1207

This change fixes a bug in the double precision template for Far::StencilTableFactory, i.e. Far::StencilTableFactoryReal.

I can't seem to reproduce this issue, I guess because I have an NVIDIA card and not an AMD one.

I'm not sure how this is supposed to work when we build Blender with extern/glew and use an older GLEW for the library dependencies. We'd have to be lucky the symbols are compatible between versions.

Why do we have extern/glew anyway, since GLEW is also part of the pre-built libraries?

I think we should actually not be using GLEW for OpenSubdiv, which seems was the case for the 3.1 libraries.

-DNO_CLEW=OFF and other DGLEW_xxx build options were already present in the commit that introduced the current deps-build infrastructure (rB3c14f02eac36) from back in 2017, so I don't think it was disabled in 3.1 either.

I'm fine rebuilding OpenSubDiv with some other options. A patch with the required changes would be much appreciated, because since I can't reproduce the issue, I also can't check if my changes help anything.

Why do we have extern/glew anyway, since GLEW is also part of the pre-built libraries?

I'm not sure about the historic reasons. D12034 may add a new reason. In any case, not something we'd want change for 3.2 I think.

-DNO_CLEW=OFF and other DGLEW_xxx build options were already present in the commit that introduced the current deps-build infrastructure (rB3c14f02eac36) from back in 2017, so I don't think it was disabled in 3.1 either.

Your strings command on the 3.1 libraries seems to show it was using glApi and no GLEW symbols.

The current default in OpenSubdiv is NO_GLEW=ON, and that's no affected by NO_CLEW or GLEW_* variables. This was different in 2017, before the introduction of glApi.

I'm fine rebuilding OpenSubDiv with some other options. A patch with the required changes would be much appreciated, because since I can't reproduce the issue, I also can't check if my changes help anything.

I'll make a patch.

I'm not sure it will solve the issue as I can't reproduce it either. But I don't see anything else in the diff between OpenSubdiv 3.4.3 and 3.4.4 that would explain it, so seems worth trying.

I checked out f4827d08bc9 and did a build locally and this is still triggering a segmentation fault

I'll try and get a trace in GDB (this take 30+ minutes locally) to confirm that it's still at the same place with this patch

It's not expected to be fixed yet, the libraries still need to be updated.

I haven't done an extensive test, but so far I no longer experience problems described in the initial report. Thank you everyone.

Roberto (B4rr3l) added a comment.EditedTue, May 10, 10:47 PM

This should be fixed now by rBL62917: Linux: OpenSubdiv 3.4.4.

Thank you very much, how can I apply this fix or when it will be released?

Download the latest 3.2 Beta or 3.3 Alpha build from https://builder.blender.org/download/daily/ it will have the fix.

Still an issue for me on the last 3.2 beta : if I disable normals/autosmooth and then apply a subdiv modifier. Eazy to reproduce : just add a mesh then apply subdiv modifier without checking the normals/autosmooth. See attached gif for demonstration. I'm using the latest 3.2 beta available.

Download the latest 3.2 Beta or 3.3 Alpha build from https://builder.blender.org/download/daily/ it will have the fix.

still crashing while turning GPU subdivision on

Please include more information, like which exact version you downloaded, and when. 3.2-beta and 3.3-alpha use different branches for their libraries, and those were updated at different times.

Brecht Van Lommel (brecht) reopened this task as Needs Information from User.Wed, May 11, 5:24 PM

I'll reopen the report then. More information will be needed to figure out why it works for some and not others.

  • Mention your graphics card and driver versions (as shown by Help > Report a Bug).
  • Try running blender with --debug-gpu from the terminal and attach full output logs here.
  • Check if the issue is specific to autosmooth, or also happens with subdivision surfaces without that.
Roberto (B4rr3l) added a comment.EditedWed, May 11, 8:55 PM

Please include more information, like which exact version you downloaded, and when. 3.2-beta and 3.3-alpha use different branches for their libraries, and those were updated at different times.

latest 3.3 Alpha 1bb7fda600c0 is working now! But latest 3.2 Beta b47c5505aa37 is not.

With blender-3.2.0-beta+v32.502e1a44b948 : can't even launch blender. Terminal output of ./blender --debug-gpu is :

./blender --debug-gpu
Color management: using fallback mode for management
Color management: Error could not find role data role.
Read prefs: /home/jean-martin/.config/blender/3.2/config/userpref.blend
Color management: scene view "Filmic" not found, setting default "Standard".
INFO (gpu.debug): Notification : Successfully hooked OpenGL debug callback using OpenGL 4.3
INFO (gpu.debug): Notification : Successfully hooked OpenGL debug callback using OpenGL 4.3
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = '/home/jean-martin/sources/blender/blender-3.2.0-beta+v32.502e1a44b948/blender'
  isolated = 0
  environment = 1
  user site = 0
  import site = 1
  sys._base_executable = '/usr/bin/python'
  sys.base_prefix = '/home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/Release/python'
  sys.base_exec_prefix = '/home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/Release/python'
  sys.platlibdir = 'lib'
  sys.executable = '/usr/bin/python'
  sys.prefix = '/home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/Release/python'
  sys.exec_prefix = '/home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/Release/python'
  sys.path = [
    '/home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/Release/python/lib/python310.zip',
    '/home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/Release/python/lib/python3.10',
    '/home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/Release/python/lib/lib-dynload',
  ]
Internal error initializing Python!
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00007fbf0f2ad180 (most recent call first):
  <no Python frame>

No log files seem to have been recorded.

With blender-3.2.0-beta+v32.b47c5505aa37 :

First see the attached GIF file that shows when the crash occures (seems to be related to autosmooth as it crashes when I unchecked the autosmooth after usin au subdv modifier (with GPU subdiv anabled). See log filsthat refer to that version.

My GPU is a AMD RX6800xt, see attached files for the terminal output of rocminfo and glxinfo -B.

With version blender-3.3.0-alpha+master.1bb7fda600c0, this bug seems to be solved.

With blender-3.2.0-beta+v32.502e1a44b948 : can't even launch blender.

That commit is from the same day as the new libraries were committed. I'm not 100% convinced that the buildbots have picked up on the new libs

With blender-3.2.0-beta+v32.502e1a44b948 : can't even launch blender. Terminal output of ./blender --debug-gpu is :

./blender --debug-gpu
[...]
Internal error initializing Python!
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

That has nothing to do with this issue; this happens when Blender can't find Python. It could be due to a missing make install/ninja install step.

As also asked before: please be clear in which Blender you're using. A release name and a Git hash number is a good start, but in this case it doesn't mean much when we don't even know whether it's self-compiled or built by the buildbot.

Roberto (B4rr3l) added a comment.EditedThu, May 12, 6:58 PM

Alright, 3.2 Beta 502e1a44b948 and 3.3 Alpha 8d9d5da13706, both working great with GPU subdivision enabled + HIP at latest 5.1.2 ROcm drivers

Now we are talking! 6700XT + OpenSUSE Tumbleweed

With blender-3.2.0-beta+v32.502e1a44b948 : can't even launch blender.

That commit is from the same day as the new libraries were committed. I'm not 100% convinced that the buildbots have picked up on the new libs

With blender-3.2.0-beta+v32.502e1a44b948 : can't even launch blender. Terminal output of ./blender --debug-gpu is :

./blender --debug-gpu
[...]
Internal error initializing Python!
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

That has nothing to do with this issue; this happens when Blender can't find Python. It could be due to a missing make install/ninja install step.

As also asked before: please be clear in which Blender you're using. A release name and a Git hash number is a good start, but in this case it doesn't mean much when we don't even know whether it's self-compiled or built by the buildbot.

Isn't it weird that one 3.2 version has no issue with python and another has an issue with python ? One version can find python and another one can't ?
I don't understand what you mean beacause i gave the build version of each instance of Blender I was running. I don't build Blender myself, I only get what is available on the nightly build.

Anyway I just downloaded the las available version : blender-3.2.0-beta+v32.502e1a44b948-linux.x86_64-release and it seems to be solved, at least on my computer (kubuntu 20.04 + studio) and RX6800XT with mesa+rocm.

I believe this can be marked as resolved. Thank you everyone for working on this.