Created attachment 142326 [details]
Not sure if it is normal to create [regression] bugs for tests that are not on any upstream branch, but as today is a bank day here in Spain, I will not have time for triagging for some days, so I prefer to save it somewhere, in order to not forget about it.
Initially I found it while testing ARB_gl_spirv with borrowed tests (tests from other specs). But it also fails with vulkan, by using vkrunner.
So, attached the ARB_gl_spirv test. Can also be found here:
And the vkrunner equivalent here:
FWIW, the ARB_gl_spirv test is executed as any other piglit shader_test, although it needs to override the extension, so:
$ export MESA_EXTENSION_OVERRIDE=GL_ARB_gl_spirv
$./bin/shader_runner tests/spec/arb_gl_spirv/execution/fs-large-local-array-vec4.shader_test -auto
After bisecting, the candidates for the guilty commits are:
* dc349f07b5f9c257f68ecf0cbb89f9722a42233a ("nir: Take call instruction into account in copy_prop_vars")
* b3c6146925595ec3a7eece3afb9ccaad32906d4c ("nir: Copy propagation between blocks")
I have two candidates because the first commit doesn't build correctly ("error: ‘copies’ undeclared (first use in this function)")
Those commits changes nir_opt_copy_prop_vars among other things. And in fact, if we don't call that optimization (dirty hack just to scope where the problem is), the test goes back to passing (although everything gets slower).
> Not sure if it is normal to create [regression] bugs for tests that are not on any upstream branch
Now that vkrunner has been integrated on piglit, I have just sent a series with tests:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/23 should fix this.
Author: Caio Marcelo de Oliveira Filho <email@example.com>
Date: Fri Dec 14 16:10:32 2018 -0800
nir: properly find the entry to keep in copy_prop_vars
When copy propagation handles a store/copy, it iterates the current
copy entries to remove aliases, but keeps the "equal" entry (if
exists) to be updated.
The removal step may swap the entries around (to ensure there are no
holes), invalidating previous iteration pointers. The bug was saving
such pointer to use later. Change the code to first perform the
removals and then find the remaining right entry.
This was causing updates to be lost since they were being made to an
entry that was not part of the current copies.
Fixes: b3c61469255 "nir: Copy propagation between blocks"
Reviewed-by: Jason Ekstrand <firstname.lastname@example.org>