GPU Subdivision: Crash after opening particular files #97737

New Issue

Rey Leonard M. Amorato · 2022-04-30T15:46:39+02:00

2022-04-30 15:46:39 +02:00

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: ac88123e29
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

In #97702#1349274, @DFair wrote:
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 :
debug.txt
3D-101-INSTALLATIONS.crash.txt
3D-101-BUILDING-MATERIALS.crash.txt

Sample blend file that does not open
3D-101-BUILDING-MATERIALS.blend

Screencast of the problem (GPU Subdivision)
Screencast from 2022-05-01 08:04:44 PM.webm

**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: `ac88123e29` 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 > In #97702#1349274, @DFair wrote: > 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 `: [debug.txt](https://archive.blender.org/developer/F13041441/debug.txt) [3D-101-INSTALLATIONS.crash.txt](https://archive.blender.org/developer/F13041667/3D-101-INSTALLATIONS.crash.txt) [3D-101-BUILDING-MATERIALS.crash.txt](https://archive.blender.org/developer/F13041681/3D-101-BUILDING-MATERIALS.crash.txt) Sample blend file that does not open [3D-101-BUILDING-MATERIALS.blend](https://archive.blender.org/developer/F13041677/3D-101-BUILDING-MATERIALS.blend) Screencast of the problem (GPU Subdivision) [Screencast from 2022-05-01 08:04:44 PM.webm](https://archive.blender.org/developer/F13043465/Screencast_from_2022-05-01_08_04_44_PM.webm)

Rey Leonard M. Amorato commented

2022-04-30 15:46:39 +02:00

Added subscriber: @RL

blender-admin commented

2022-04-30 15:46:39 +02:00

#97473 was marked as duplicate of this issue

blender-admin commented

2022-04-30 15:46:39 +02:00

#97963 was marked as duplicate of this issue

blender-admin commented

2022-04-30 15:46:39 +02:00

#97873 was marked as duplicate of this issue

blender-admin commented

2022-04-30 15:46:39 +02:00

blender/blender-addons#97803 was marked as duplicate of this issue

blender-admin commented

2022-04-30 15:46:39 +02:00

#97806 was marked as duplicate of this issue

blender-admin commented

2022-04-30 15:46:39 +02:00

#97702 was marked as duplicate of this issue

Robert Guetzkow commented

2022-04-30 16:02:20 +02:00

Added subscriber: @rjg

Robert Guetzkow commented

2022-04-30 16:02:20 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Robert Guetzkow commented

2022-04-30 16:02:20 +02:00

Please upload /home/workstation/.cache/blender/3D-101-INSTALLATIONS.crash.txt and ideally a minimal example project file that allows us to reproduce the issue.

Please upload `/home/workstation/.cache/blender/3D-101-INSTALLATIONS.crash.txt` and ideally a minimal example project file that allows us to reproduce the issue.

Rey Leonard M. Amorato commented

2022-04-30 17:18:23 +02:00

There, I added a few things.

Robert Guetzkow commented

2022-04-30 17:26:40 +02:00

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.

Rey Leonard M. Amorato commented

2022-04-30 21:07:51 +02:00

This is a file without any libraries, but I still can't open it using 3.2.
3.1 opens it fine.
3D-101-STATIONERY-NO-LINKED-LIBRARY.blend

This is a file without any libraries, but I still can't open it using 3.2. 3.1 opens it fine. [3D-101-STATIONERY-NO-LINKED-LIBRARY.blend](https://archive.blender.org/developer/F13042248/3D-101-STATIONERY-NO-LINKED-LIBRARY.blend)

Pratik Borhade commented

2022-05-01 05:14:36 +02:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2022-05-01 05:14:36 +02:00

Hi, can you disable GPU subdivision and then load the file?: {nav Edit > Preferences > Viewport > Subdivision > GPU 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)

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?: {nav Edit > Preferences > Viewport > Subdivision > GPU 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```

Pratik Borhade commented

2022-05-01 13:04:00 +02:00

Maybe related to this report?: #97702 (Crash loading demo flat-archiviz with 3.2 Alpha)

Rey Leonard M. Amorato commented

2022-05-01 13:58:51 +02:00

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.

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

Pratik Borhade commented

2022-05-02 12:56:48 +02:00

Added subscribers: @OmarEmaraDev, @JacquesLucke

Pratik Borhade commented

2022-05-02 12:56:48 +02:00

@OmarEmaraDev or @JacquesLucke according to hardware list you both have similar system (Linux + AMD GPU)
Can you confirm this crash?
Also test #97702

@OmarEmaraDev or @JacquesLucke according to hardware list you both have similar system (Linux + AMD GPU) Can you confirm this crash? Also test #97702

Jacques Lucke commented

2022-05-02 13:06:52 +02:00

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.

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.

Jacques Lucke commented

2022-05-02 13:22:52 +02:00

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. Stack trace: [P2917](https://archive.blender.org/developer/P2917.txt) Some errors from asan, but not sure if those are related: [P2918](https://archive.blender.org/developer/P2918.txt) I can open the file when I turn off `WITH_OPENSUBDIV`.

Pratik Borhade commented

2022-05-02 13:31:37 +02:00

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

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

> Couldn't bisect it in a reasonable amount of time right now, issue might also be caused a library update. Same also mentioned in #97702#1349274 `So this was one of the more painful bisects, but it's related to a bump in dependencies for 3.2.x here` @JacquesLucke , can you merge these reports if both are same? I'm marking this as `confirmed`

Jacques Lucke commented

2022-05-02 13:49:38 +02:00

Added subscribers: @DFair, @EAW, @ThomasDinges

Pratik Borhade changed title from ~~Segfault trying to open a file~~ to GPU Subdivision: Crash after opening particular files

2022-05-02 13:50:34 +02:00

Pratik Borhade commented

2022-05-02 13:51:59 +02:00

Changed status from 'Needs User Info' to: 'Confirmed'

Kévin Dietrich commented

2022-05-02 15:05:43 +02:00

Added subscriber: @kevindietrich

Kévin Dietrich commented

2022-05-02 15:05:43 +02:00

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.

The new version of OpenSubDiv has [some changes for OpenGL initialization problems on MacOS](https://github.com/PixarAnimationStudios/OpenSubdiv/pull/1216/files). Maybe this causes some issues on AMD cards. Or maybe it is something else.

David Fair commented

2022-05-02 21:36:48 +02:00

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

> 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

Pratik Borhade commented

2022-05-03 12:43:56 +02:00

Added subscriber: @jean-martin-barbut

jean-martin commented

2022-05-03 14:32:34 +02:00

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

Mike Harris commented

2022-05-04 13:17:08 +02:00

Added subscriber: @onikuma

Mike Harris commented

2022-05-04 13:17:08 +02:00

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 e86b62f195 3.2 beta.

The last build of 3.2 alpha that worked for me was 17eb8a9ceb. 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 17eb8a9ceb, 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

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 ```

Ray molenkamp commented

2022-05-04 23:22:56 +02:00

Added subscribers: @dr.sybren, @LazyDodo

Sybren A. Stüvel was assigned by Ray molenkamp

2022-05-04 23:22:56 +02:00

Ray molenkamp commented

2022-05-04 23:22:56 +02:00

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.

@dr.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](https://archive.blender.org/developer/P2917.txt) , the only crash i could see in [that function](https://github.com/PixarAnimationStudios/OpenSubdiv/blob/release/opensubdiv/osd/glVertexBuffer.cpp#L97) would be OSD_OPENGL_HAS(ARB_direct_state_access) is true but glNamedBufferDataEXT is a nullptr. @dr.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](https://github.com/PixarAnimationStudios/OpenSubdiv/blob/release/CMakeLists.txt#L378) can you take a look here?

Pratik Borhade commented

2022-05-05 03:57:21 +02:00

Added subscriber: @qq4945286

Aleksi Juvani commented

2022-05-05 12:28:24 +02:00

Added subscriber: @aleksijuvani

Aleksi Juvani commented

2022-05-05 12:28:24 +02:00

In #97737#1352199, @LazyDodo wrote:
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.

> In #97737#1352199, @LazyDodo wrote: > Given the function it crashes in [P2917](https://archive.blender.org/developer/P2917.txt) , the only crash i could see in [that function](https://github.com/PixarAnimationStudios/OpenSubdiv/blob/release/opensubdiv/osd/glVertexBuffer.cpp#L97) 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](https://github.com/PixarAnimationStudios/OpenSubdiv/commit/82988d04ad298c764287550a58e6b191fa11f48f#diff-7fb2f434d0837f8e612028d59bdc9f244dd4ae8816dc8ff7814f70ac186feae9), this is probably an oversight on their part when switching from `EXT_direct_state_access` to `ARB_direct_state_access`.

Sybren A. Stüvel commented

2022-05-05 14:46:09 +02:00

In #97737#1352199, @LazyDodo wrote:
@dr.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.

> In #97737#1352199, @LazyDodo wrote: > @dr.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](https://github.com/PixarAnimationStudios/OpenSubdiv/blob/release/CMakeLists.txt#L378) 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.

Brecht Van Lommel commented

2022-05-05 15:41:52 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2022-05-05 15:41:52 +02:00

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.

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.

Pratik Borhade commented

2022-05-09 04:52:52 +02:00

Added subscribers: @B4rr3l, @dimant72

Evan Wilson commented

2022-05-09 06:50:27 +02:00

In #97737#1350127, @JacquesLucke wrote:
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.

> In #97737#1350127, @JacquesLucke wrote: > Some errors from asan, but not sure if those are related: [P2918](https://archive.blender.org/developer/P2918.txt) 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.

Sybren A. Stüvel removed their assignment 2022-05-09 14:22:44 +02:00

Sybren A. Stüvel commented

2022-05-09 14:22:44 +02:00

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

In #97737#1352568, @brecht wrote:
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 (3c14f02eac) 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.

I can't seem to reproduce this issue, I guess because I have an NVIDIA card and not an AMD one. > In #97737#1352568, @brecht wrote: > 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 (3c14f02eac) 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.

Brecht Van Lommel commented

2022-05-09 15:58:38 +02:00

In #97737#1354630, @dr.sybren wrote:
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 (3c14f02eac) 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.

> In #97737#1354630, @dr.sybren wrote: > 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](https://archive.blender.org/developer/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 (3c14f02eac) 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.

Aleksi Juvani commented

2022-05-09 17:07:37 +02:00

Removed subscriber: @aleksijuvani

David Fair commented

2022-05-09 19:26:35 +02:00

I checked out f4827d08bc 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

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

Brecht Van Lommel commented

2022-05-09 19:41:27 +02:00

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

Brecht Van Lommel commented

2022-05-10 17:54:44 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Brecht Van Lommel closed this issue

2022-05-10 17:54:44 +02:00

Brecht Van Lommel self-assigned this 2022-05-10 17:54:44 +02:00

Brecht Van Lommel commented

2022-05-10 17:54:44 +02:00

This should be fixed now by {rBL62917}.

Rey Leonard M. Amorato commented

2022-05-10 19:26:22 +02:00

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

Germano Cavalcante commented

2022-05-10 22:21:43 +02:00

Added subscribers: @worksblender6, @mano-wii

Roberto commented

2022-05-10 22:47:23 +02:00

In #97737#1356075, @brecht wrote:
This should be fixed now by {rBL62917}.

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

> In #97737#1356075, @brecht wrote: > This should be fixed now by {rBL62917}. Thank you very much, how can I apply this fix or when it will be released?

Thomas Dinges commented

2022-05-11 09:00:59 +02:00

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

jean-martin commented

2022-05-11 12:49:24 +02:00

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.

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. ![Peek 11-05-2022 12-46_02.gif](https://archive.blender.org/developer/F13067516/Peek_11-05-2022_12-46_02.gif) ![Peek 11-05-2022 12-46_01.gif](https://archive.blender.org/developer/F13067518/Peek_11-05-2022_12-46_01.gif)

Roberto commented

2022-05-11 13:35:58 +02:00

In #97737#1356458, @ThomasDinges wrote:
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

> In #97737#1356458, @ThomasDinges wrote: > 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

Sybren A. Stüvel commented

2022-05-11 17:00:05 +02:00

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 commented

2022-05-11 17:24:38 +02:00

Changed status from 'Resolved' to: 'Needs User Info'

Brecht Van Lommel reopened this issue

2022-05-11 17:24:38 +02:00

Brecht Van Lommel commented

2022-05-11 17:24:38 +02:00

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.

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.

Pratik Borhade commented

2022-05-11 17:36:03 +02:00

There was another crash report on linux system: #97330 (Adding subdivision surface modifier to default cube causes silent crash.)
Is also fixed now

There was another crash report on linux system: #97330 (Adding subdivision surface modifier to default cube causes silent crash.) Is also fixed now

Roberto commented

2022-05-11 20:55:26 +02:00

In #97737#1356889, @dr.sybren wrote:
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 1bb7fda600 is working now! But latest 3.2 Beta b47c5505aa is not.

> In #97737#1356889, @dr.sybren wrote: > 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.

jean-martin commented

2022-05-12 11:43:44 +02:00

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.

blender_debug_output.txt

blender.crash.txt

glxinfo.txt

rocminfo.txt

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. [blender_debug_output.txt](https://archive.blender.org/developer/F13070496/blender_debug_output.txt) [blender.crash.txt](https://archive.blender.org/developer/F13070497/blender.crash.txt) [glxinfo.txt](https://archive.blender.org/developer/F13070498/glxinfo.txt) [rocminfo.txt](https://archive.blender.org/developer/F13070499/rocminfo.txt) ![blender_crash.gif](https://archive.blender.org/developer/F13070504/blender_crash.gif)

Sybren A. Stüvel commented

2022-05-12 16:05:25 +02:00

In #97737#1357356, @jean-martin-barbut wrote:
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

In #97737#1357356, @jean-martin-barbut wrote:
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.

> In #97737#1357356, @jean-martin-barbut wrote: > 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 > In #97737#1357356, @jean-martin-barbut wrote: > 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 commented

2022-05-12 18:58:17 +02:00

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

Now we are talking! 6700XT + OpenSUSE Tumbleweed

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

jean-martin commented

2022-05-12 19:49:33 +02:00

In #97737#1357564, @dr.sybren wrote:

In #97737#1357356, @jean-martin-barbut wrote:
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
In #97737#1357356, @jean-martin-barbut wrote:
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.

> In #97737#1357564, @dr.sybren wrote: >> In #97737#1357356, @jean-martin-barbut wrote: >> 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 > > >> In #97737#1357356, @jean-martin-barbut wrote: >> 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.

Rey Leonard M. Amorato commented

2022-05-13 13:27:47 +02:00

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

Brecht Van Lommel commented

2022-05-13 15:52:50 +02:00

Changed status from 'Needs User Info' to: 'Resolved'

Brecht Van Lommel closed this issue

2022-05-13 15:52:50 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

GPU Subdivision: Crash after opening particular files #97737