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

[Marek Olšák]

Reverting the st/mesa commit would be fine.

Marek

On Mon, Apr 29, 2019 at 3:20 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190429/0ca6b09d/attachment.html>