blender/blender
170
530
Fork 806
Code Issues 6.5k Pull Requests 962 Projects 21 Wiki Activity

Windows: Disable shader draw parameter support on certain Qualcomm GPUs #127148

Merged
Anthony Roberts merged 1 commits from Anthony-Roberts/blender:x-elite-shader-draw-parameters into main 2024-09-04 18:20:14 +02:00
Conversation 2 Commits 1 Files Changed 1 +21
1 changed files with 21 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 41b00ef8b8 - Show all commits

21
source/blender/gpu/opengl/gl_backend.cc
View File

@ -453,6 +453,27 @@ static void detect_workarounds()
}
}
/* Snapdragon X Elite devices currently have a driver bug that results in
* eevee rendering a black cube with anything except an emission shader
* if shader draw parameters are enabled (#122837) */
#if defined(WIN32)
long long driverVersion = 0;
if (GPU_type_matches(GPU_DEVICE_QUALCOMM, GPU_OS_WIN, GPU_DRIVER_ANY)) {
if (BLI_windows_get_directx_driver_version(L"Qualcomm(R) Adreno(TM)", &driverVersion)) {
/* Parse out the driver version */
WORD ver0 = (driverVersion >> 48) & 0xffff;
/* X Elite devices have GPU driver version 31, and currently no known release version of the
* GPU driver renders the cube correctly. This will be changed when a working driver version
* is released to commercial devices to only enable these flags on older drivers. */
if (ver0 == 31) {
Ray molenkamp commented 2024-09-04 16:27:52 +02:00
Review
Copy Link

are there older versions we need to worry about?

are there older versions we need to worry about?
Anthony Roberts commented 2024-09-04 16:36:01 +02:00
Review
Copy Link

No, version 30.x.x.x, which is the current release on 8cx Gen3, doesn't have the issue.

Only public builds of 31.x.x.x (the current release on X Elite devices, the new generation) exhibit the issue. In the future, when we get a fixed version of the driver, I'll expand the check to only enable these flags below that sub-version

There is a similar check in that file (line 153) where I disable older drivers due to a bug, also, which by extension disables older devices.

No, version 30.x.x.x, which is the current release on 8cx Gen3, doesn't have the issue. Only public builds of 31.x.x.x (the current release on X Elite devices, the new generation) exhibit the issue. In the future, when we get a fixed version of the driver, I'll expand the check to only enable these flags below that sub-version There is a similar check in that file (line 153) where I disable older drivers due to a bug, also, which by extension disables older devices.
Ray molenkamp commented 2024-09-04 16:53:28 +02:00
Review
Copy Link

Allright, fair enough, if driver 32 comes out and it doesn't fix the issue, people are back to black cubes for blender versions that may not get any more maintenance releases, if (ver0 >= 31) { be better here, You can always come in back later and add a && vers < N to whitelist the newer drivers and disable the workaround on those.

I'd rather see people on the workaround longer than needed, than potentially going back to black cubes.

Allright, fair enough, if driver 32 comes out and it _doesn't_ fix the issue, people are back to black cubes for blender versions that may not get any more maintenance releases, `if (ver0 >= 31) {` be better here, You can always come in back later and add a `&& vers < N` to whitelist the newer drivers and disable the workaround on those. I'd rather see people on the workaround longer than needed, than potentially going back to black cubes.
Anthony Roberts commented 2024-09-04 17:25:46 +02:00
Review
Copy Link

Driver 32 would be with the next generation of chips that aren't due for a few years yet :) the new release for this gen would be a sub-version release, which I was intending on adding later - can swap it to a > though, no problem

Driver 32 would be with the next generation of chips that aren't due for a few years yet :) the new release for this gen would be a sub-version release, which I was intending on adding later - can swap it to a `>` though, no problem
GCaps.shader_draw_parameters_support = false;
GLContext::shader_draw_parameters_support = false;
}
}
}
#endif
/* Some Intel drivers have issues with using mips as frame-buffer targets if
* GL_TEXTURE_MAX_LEVEL is higher than the target MIP.
* Only check at the end after all other workarounds because this uses the drawing code.