Workaround crash in pipeline creation on Intel Mesa devices by avoiding using half floats in derivative functions#114765
Conversation
…ng using half floats in derivative functions
akien-mga
changed the title
blueskythlikesclouds
left a comment
blueskythlikesclouds
left a comment
There was a problem hiding this comment.
These changes resolve the SPIR-V validation errors reported by VVL, so I'm not convinced this is a driver bug. The driver is not receiving sane shader input in the first place.
This implies it may be a glslang issue, though. Out of curiosity, I ran the CI artifact from #114075 and the validation still fails there, so the issue may still exist in the latest version of glslang.
This workaround should be good until that is figured out.
|
Thanks! |
|
For the record, there's already a tentative fix for the issue in Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14600 |
Indeed, it looks like using a half float type in a derivative function violates the SPIRV spec (https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_derivative_instructions). So this is indeed the correct fix for a bug in our shader. Mesa is fixing the source of the crash at any rate https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39226 The remaining action item for us is to determine if this is a bug in GLSLang, and if so, make a proper bug report to them |
…esa-half-workaround Workaround crash in pipeline creation on Intel Mesa devices by avoiding using half floats in derivative functions
3 participants
Fixes: #114743
Fixes: #114292
Functionally this shouldn't change much on any platform.
vec3_to_oct_lodtakes vec3 input so the results of dFdx and dFdy need to be promoted to vec3 anyway. I suspect that drivers typically promote to vec3 after doing the derivative function, but many drivers don't support taking derivatives of half floats anyway and will implicitly convert to full float, then convert back to half float after. In that case, the result will be the same both before and after this PR.This is a safe workaround that should have minimal impact on performance for any device.
Future considerations
It is clear from both this issue and #110363 that these classes of Intel iGPUs have very poor half float support on Mesa drivers.
Comminux's investigation also confirms that this issue seems to have been fixed and reintroduced in later versions of Mesa #114292 (comment)
IMO we should go ahead with the workaround and just deal with it since we can't force end users to use the working versions of Mesa. In a few years this workaround can probably be dropped, but until then I think we are stuck with it