Metal: Shader Compilation Error (EEVEE) #116414

New Issue

Closed

opened 2023-12-21 08:56:29 +01:00 by Jeroen Bakker · 8 comments

Jeroen Bakker commented

2023-12-21 08:56:29 +01:00

Member

System Information
Operating system: macOS-14.2-x86_64-i386-64bit 64 Bits
Graphics card: Metal API Intel(R) UHD Graphics 630 1.2

Blender Version
Broken: version: 4.1.0 Alpha, branch: Fix_116216, commit date: 2023-12-20 18:14, hash: 1d0bec9e1835
Worked: (newest version of Blender that worked as expected)

Short description of error

Shader compilation error in Metal backend (EEVEE eevee_deferred_planar_eval)

Exact steps for others to reproduce the error

Use Mac with Intel iGPU
Set render engine to EEVEE (next)
Set shading mode to material or rendered

ERROR (gpu.shader): eevee_deferred_planar_eval Vertex Shader: 
      | 
 5064 | {
      |                                                    ^
      | Error: incompatible pointer types assigning to 'texture2d<unsigned int, (metal::access)0> *' from 'texture2d_array<uint32_t, access::sample> *' (aka 'texture2d_array<unsigned int, access::sample> *')
      | 
      | vertex_shader_instance.shadow_atlas_tx.texture = &shadow_atlas_tx;
      | ^~~~~~~~~~~~~~~~

EEVEE: error: Could not compile static shader "eevee_deferred_planar_eval"

This is after #116250 is applied, but I don't think it is related to that issue.
Might be related that shadow_atlas_tx is part of the atomic texture workaround? Unclear why it isn't using an array here.
Issue is not solved by #116396

**System Information** Operating system: macOS-14.2-x86_64-i386-64bit 64 Bits Graphics card: Metal API Intel(R) UHD Graphics 630 1.2 **Blender Version** Broken: version: 4.1.0 Alpha, branch: Fix_116216, commit date: 2023-12-20 18:14, hash: `1d0bec9e1835` Worked: (newest version of Blender that worked as expected) **Short description of error** Shader compilation error in Metal backend (EEVEE `eevee_deferred_planar_eval`) **Exact steps for others to reproduce the error** * Use Mac with Intel iGPU * Set render engine to EEVEE (next) * Set shading mode to material or rendered ``` ERROR (gpu.shader): eevee_deferred_planar_eval Vertex Shader: | 5064 | { | ^ | Error: incompatible pointer types assigning to 'texture2d<unsigned int, (metal::access)0> *' from 'texture2d_array<uint32_t, access::sample> *' (aka 'texture2d_array<unsigned int, access::sample> *') | | vertex_shader_instance.shadow_atlas_tx.texture = &shadow_atlas_tx; | ^~~~~~~~~~~~~~~~ EEVEE: error: Could not compile static shader "eevee_deferred_planar_eval" ``` This is after #116250 is applied, but I don't think it is related to that issue. Might be related that `shadow_atlas_tx` is part of the atomic texture workaround? Unclear why it isn't using an array here. Issue is not solved by #116396

Jeroen Bakker added this to the 4.1 milestone 2023-12-21 08:56:29 +01:00

Jeroen Bakker added the

labels 2023-12-21 08:56:30 +01:00

Jeroen Bakker added this to the EEVEE & Viewport project 2023-12-21 08:56:32 +01:00

Jeroen Bakker added the

EEVEE & Viewport

labels 2023-12-21 08:57:01 +01:00

Jeroen Bakker added

and removed

labels 2023-12-21 08:58:26 +01:00

Jeroen Bakker commented

2023-12-21 08:59:51 +01:00

Author

Member

I mark this as a high priority. Reason is that it is a crash and also blocks enabling render tests for EEVEE next and validating performance of these devices on a non OpenGL platform.

I mark this as a high priority. Reason is that it is a crash and also blocks enabling render tests for EEVEE next and validating performance of these devices on a non OpenGL platform.

Jeroen Bakker referenced this issue

2023-12-21 10:05:13 +01:00

EEVEE Next: Blender freezing when render mode is selected #114597

Jeroen Bakker referenced a pull request that will close this issue

2023-12-21 12:50:06 +01:00

WIP: Fix #116414: Metal Shader Compilation Error #116423

Michael Parkin-White commented

2024-01-04 15:19:20 +01:00

Afaik this should be resolved by: #116657

Afaik this should be resolved by: https://projects.blender.org/blender/blender/pulls/116657

Vincenzo-3 referenced this issue

2024-01-08 12:13:26 +01:00

EEVEE Next crashing on daily build #116884

Vincenzo-3 commented

2024-01-08 12:14:20 +01:00

Just want to say, this issue is present on the windows build as well.

Just want to say, this issue is present on the windows build as well.

Jeroen Bakker commented

2024-01-08 14:05:59 +01:00

Author

Member

@Michael-Parkin-White-Apple still an issue, but slightly different and on a different shader

ERROR (gpu.shader): eevee_deferred_light_double Fragment Shader: 
      | 
 9505 |       is_directional, shadow_atlas_tx, shadow_tilemaps_tx, light, P);
      |                       ^
      | eevee_thickness_lib.glsl:33:23: Error: no viable conversion from '_mtl_combined_image_sampler_2d_array<uint32_t, access::sample>' (aka '_mtl_combined_image_sampler_2d_array<unsigned int, access::sample>') to '_mtl_combined_image_sampler_2d_array_atomic_fallback<uint>' (aka '_mtl_combined_image_sampler_2d_array_atomic_fallback<unsigned int>')

This platform is important to fix as it is a prerequisite of enabling the render tests on the buildbot.

@Michael-Parkin-White-Apple still an issue, but slightly different and on a different shader ``` ERROR (gpu.shader): eevee_deferred_light_double Fragment Shader: | 9505 | is_directional, shadow_atlas_tx, shadow_tilemaps_tx, light, P); | ^ | eevee_thickness_lib.glsl:33:23: Error: no viable conversion from '_mtl_combined_image_sampler_2d_array<uint32_t, access::sample>' (aka '_mtl_combined_image_sampler_2d_array<unsigned int, access::sample>') to '_mtl_combined_image_sampler_2d_array_atomic_fallback<uint>' (aka '_mtl_combined_image_sampler_2d_array_atomic_fallback<unsigned int>') ``` This platform is important to fix as it is a prerequisite of enabling the render tests on the buildbot.

Michael Parkin-White commented

2024-01-08 14:12:10 +01:00

Oh hmm, not sure if there is a possible mismatch on non TBDR platforms.
There is another patch to correct the usage of the TBDR flag: #116250
Which was erroneously enabled on iOS. (If its unintentionally using a mix of the atomic and TBDR solutions).

I'll have another look into this as the fallback mechanism should be working correctly.

@Jeroen-Bakker Were you running on Apple Silicon or on Intel/AMD based macbook?

Oh hmm, not sure if there is a possible mismatch on non TBDR platforms. There is another patch to correct the usage of the TBDR flag: https://projects.blender.org/blender/blender/pulls/116250 Which was erroneously enabled on iOS. (If its unintentionally using a mix of the atomic and TBDR solutions). I'll have another look into this as the fallback mechanism should be working correctly. @Jeroen-Bakker Were you running on Apple Silicon or on Intel/AMD based macbook?

Jeroen Bakker commented

2024-01-08 14:23:36 +01:00

Author

Member

It is an Mac Mini (Intel)

Operating system: macOS-14.2-x86_64-i386-64bit 64 Bits
Graphics card: Metal API Intel(R) UHD Graphics 630 1.2

I forgot to mention that I tested it using #116250 applied

It is an Mac Mini (Intel) Operating system: macOS-14.2-x86_64-i386-64bit 64 Bits Graphics card: Metal API Intel(R) UHD Graphics 630 1.2 I forgot to mention that I tested it using #116250 applied

Jeroen Bakker commented

2024-01-12 15:39:18 +01:00

Author

Member

@Michael-Parkin-White-Apple do you have a commit (done in the past) that might resolve a similar issue? Perhaps I can learn from that commit what is needed to solve it as I have the hardware available.

@Michael-Parkin-White-Apple do you have a commit (done in the past) that might resolve a similar issue? Perhaps I can learn from that commit what is needed to solve it as I have the hardware available.

Michael Parkin-White commented

2024-01-12 16:33:20 +01:00

@Jeroen-Bakker Apologies for this one, not sure why this is failing and don't have an Intel GPU to hand.

So yes, this is the fallback for texture atomic support for platforms which do not support native texture atomics. Then, there is also consideration for which shadow technique is being used.

There are a few cases to consider:

Native texture atomics are only supported on macOS Sonoma 14.0+. This is performed via a runtime check , but the build machine also needs to support the atomic texture symbols (i.e. needs to be on macOS 14.0 with the correct SDK version available, i.e. recent or latest xcode).
See #if defined(MAC_OS_VERSION_14_0). This feature flag should inject the ATOMIC_DEFINE_STR into the shader source if atomics are supported, in which case, native tex atomics should be used, and this error should not be present.
If native texture atomics are not available, we instead use the atomic fallback which is emulated using a texture buffer. Texture buffers only support texture1D/2D, so in this case, texture2D_Array and texture3D are implemented under the hood as texture2D.

(Internally, the fallback texture type is _mtl_combined_image_sampler_2d_array_atomic_fallback or _mtl_combined_image_sampler_3d_atomic_fallback, which instead contains a ref to a regular 2D texture and some re-alignment params.

For the shadow shader in particular, Intel GPUs will be using the atomic path. In this case, as texture atomics should be supported, the incoming type of texture2D_Array is correct. However, the fallback path seems to be compiled in for the shader.

My guess is that the shader is the deferred lighting shader possibly not flagged as utilising BuiltinBits::TEXTURE_ATOMIC. Whereas the writing kernel is eevee_surf_shadow_atomic. We may need to add this builtin to the GPU_SHADER_CREATE_INFO(eevee_shadow_data) , to ensure shaders which compile with shadow atlas access are correctly tagged.

Or to avoid this confusion in the future, remove the texture atomic builtin bit flag, and just detect it from the bound texture types.
(This flag is used to ensure a shader is compiled with Metal3_0 shading language instead of Metal2_4, but should only apply to systems with native support, hence why it is aimed to limit it).

Although i'm not 100% sure if this is the cause of the issue.

@Jeroen-Bakker Apologies for this one, not sure why this is failing and don't have an Intel GPU to hand. So yes, this is the fallback for texture atomic support for platforms which do not support native texture atomics. Then, there is also consideration for which shadow technique is being used. There are a few cases to consider: - Native texture atomics are only supported on macOS Sonoma 14.0+. This is performed via a runtime check , but the build machine also needs to support the atomic texture symbols (i.e. needs to be on macOS 14.0 with the correct SDK version available, i.e. recent or latest xcode). - See `#if defined(MAC_OS_VERSION_14_0)`. This feature flag should inject the `ATOMIC_DEFINE_STR` into the shader source if atomics are supported, in which case, native tex atomics should be used, and this error should not be present. - If native texture atomics are not available, we instead use the atomic fallback which is emulated using a texture buffer. Texture buffers only support texture1D/2D, so in this case, texture2D_Array and texture3D are implemented under the hood as texture2D. (Internally, the fallback texture type is `_mtl_combined_image_sampler_2d_array_atomic_fallback` or `_mtl_combined_image_sampler_3d_atomic_fallback`, which instead contains a ref to a regular 2D texture and some re-alignment params. - For the shadow shader in particular, Intel GPUs will be using the atomic path. In this case, as texture atomics should be supported, the incoming type of texture2D_Array is correct. However, the fallback path seems to be compiled in for the shader. My guess is that the shader is the deferred lighting shader possibly not flagged as utilising `BuiltinBits::TEXTURE_ATOMIC`. Whereas the writing kernel is `eevee_surf_shadow_atomic`. We may need to add this builtin to the `GPU_SHADER_CREATE_INFO(eevee_shadow_data)` , to ensure shaders which compile with shadow atlas access are correctly tagged. Or to avoid this confusion in the future, remove the texture atomic builtin bit flag, and just detect it from the bound texture types. (This flag is used to ensure a shader is compiled with Metal3_0 shading language instead of Metal2_4, but should only apply to systems with native support, hence why it is aimed to limit it). Although i'm not 100% sure if this is the cause of the issue.

Jason Fielder referenced a pull request that will close this issue

2024-01-18 13:15:10 +01:00

Fix #116414: EEVEE Shadow compilation macOS #117278

Jeroen Bakker referenced this issue from a commit

2024-01-18 14:10:34 +01:00

Fix #116414: EEVEE Shadow compilation macOS

Jeroen Bakker closed this issue

2024-01-18 14:10:35 +01:00

Blender Bot added

and removed

labels 2024-01-18 14:10:37 +01:00

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project (Legacy)

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#116414

No description provided.