When gpu_shader5 was enabled, it triggered GLES3.1CTS failures:
dEQP Core GL-CTS-2.0 (0x0052484b) starting..
target implementation = 'intel-gbm'
Test case 'ES31-CTS.gpu_shader5.fma_precision_vec2'..
Fail (Error in test execution)
Test run totals:
Passed: 0/1 (0.00%)
Failed: 1/1 (100.00%)
Not supported: 0/1 (0.00%)
Warnings: 0/1 (0.00%)
Here's a stab in the dark - we set nir_compiler_options::lower_ffma to true, to try and allow for better CSE of MULs and ADDs. But this causes ffmas that came from the actual fma() GLSL built-in, where the point is increased precision, to be split up as well.
We probably want to avoid *creating* new ffmas, but avoid *splitting* ones that come in from GLSL IR.
These seem to fail, even with Jason's recent precision patches. Assigning to Jason so he can take a look.
Apparently the fma_precision tests are hitting some kind of transform feedback related bug. They're getting a GL error when trying to set up their vertex buffers, because their VS inputs apparently don't exist. It looks like we dead code eliminated the whole program, due to transform feedback outputs being removed for whatever reason.
I have a patch to fix ES31-CTS.gpu_shader5.fma_precision_*.
(In reply to Kenneth Graunke from comment #4)
> I have a patch to fix ES31-CTS.gpu_shader5.fma_precision_*.
And here it is:
I looked into the ES31-CTS.gpu_shader5.precise_qualifier bug, and it is indeed a precision issue caused by fusing multiply adds. GLSL IR passes appear to be throwing away all precision information.
I have a patch for that as well, though it's a bit of a hack.
mesa 26c56e2 fixes most of these tests. The only remaining failure is:
(In reply to Mark Janes from comment #7)
> mesa 26c56e2 fixes most of these tests. The only remaining failure is:
precise_qualifier is passing for me on gen8 with master.
fixed in mesa 95d622e16df0ddbf52e43a34bd6ed6dd15e3bdee