Skip to content

Draft: [RFC] glsl: Keep matrix inversion in highp

Alyssa Rosenzweig requested to merge alyssa/mesa:matrix-invers into master

I think there is a risk of overflow while calculating the 2x2 determinant ad - bc. The difference may fit in fp16 though the individual products may not. The Mali blob promotes the products to highp, doing the same fixes failures on Bifrost:

dEQP-GLES3.functional.shaders.matrix.inverse.dynamic.mediump_mat2_float_vertex dEQP-GLES3.functional.shaders.matrix.inverse.dynamic.lowp_mat2_float_vertex

WIP because I can't tell if:

  • This is actually a bug in the GLSL compiler as opposed to buggy tests (that would get waived if we ever submitted for conformance) or buggy hardware (that probably still needs a GLSL compiler workaround but not one affecting other hardware).

  • Other operations (determinant?) are also affected and need the same treatment even though the tests are fine.

The tests confuse me, since their fragment versions pass, as do their mat3/mat4 ones, and the highp version. Only these two tests are failing. And I believe they're both passing on Midgard which already has fp16 wired in. Even so, looking at the error mask, we are very close and @jekstrand thinks the issue occurs near singular matrices where all bets are off for numerical stability. So even so it might be a test issue. (If so, why does Arm have a similar workaround? To deal with exactly these tests perhaps?)

Merge request reports