[Mesa-dev] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware

[Ilia Mirkin]

On Mon, Apr 29, 2019 at 3:06 PM Viktor Jaegerskuepper
<viktor_jaegerskuepper at freenet.de> wrote:
>
> Hi Ilia,
>
> Ilia Mirkin:
> > If you can reproduce the issue
> > at will, could I recommend you try undoing this hunk:
> >
> > @@ -1192,7 +1192,6 @@ try_pbo_upload_common(struct gl_context *ctx,
> >        return false;
> >
> >     cso_save_state(cso, (CSO_BIT_FRAGMENT_SAMPLER_VIEWS |
> > -                        CSO_BIT_FRAGMENT_SAMPLERS |
> >                          CSO_BIT_VERTEX_ELEMENTS |
> >                          CSO_BIT_AUX_VERTEX_BUFFER_SLOT |
> >                          CSO_BIT_FRAMEBUFFER |
> >
> > and seeing if that helps? Knowing whether it helps, or doesn't help,
> > would likely be useful for the investigation.
>
> It didn't help.

OK. That's actually good -- indicates it's not just a straight-up
state management bug in the driver.

>
> > Also, can you check whether the piglit
> >
> > bin/arb_texture_buffer_object-subdata-sync -fbo -auto
> >
> > passes or fails both before and after this change?
>
> It passes both times, i.e. I get:
>
> PIGLIT: {"result": "pass" }
>
> Although you didn't write it explicitly, I assumed that I had to build
> piglit (and waffle) from source (current git master branch). I have
> never compiled or used piglit before, so if my result doesn't make sense
> or some information is missing, please tell me because I might have done
> a mistake.

Sounds like you did it right. This was a piglit that I used to
reproduce some issues in nouveau which had to be fixed before this
change could be pushed. Sounds like r600 isn't sensitive to precisely
the same conditions. There are a bunch of pbo piglits too -- try those
out, see if they fail after the change.

Marek/Nicolai/Dave - could one of you take a look? As I recall, you
guys comprise the current r600 texturing expertise.

This change was to remove explicit setting of samplers in the PBO
upload path in st/mesa, where it sets up the PBO as a texbuffer and
then uses TXF to read from it. In theory, a sampler should not be
necessary, and other paths in mesa already don't set one. This path
was a left-over from the original PBO upload logic introduced by nha,
I believe, where I had requested that it keep setting the samplers
anyways, since it would break nouveau otherwise, and I didn't (at the
time) know why.

A hardware quirk on NVIDIA Tesla and Fermi era GPUs caused the texture
lookup mode we used (separate texture view/sampler) to have to have a
valid sampler bound at slot 0 no matter what, even though it was not
really used (except for an SRGB setting, I believe, which we keep
always-on in all samplers). Perhaps the DX10 r600/r700 GPUs had
something similar?

My fix on nv50 is here: de49e065077fcf26462f1859beafabf5e7a33757.

Reverting the change to st/mesa would also be fine -- it's not a big
deal -- however there are other ways for these conditions to occur, so
it would not be a complete fix for the underlying problem.

Cheers,

  -ilia