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

Ilia Mirkin imirkin at alum.mit.edu
Sun Apr 28 20:01:31 UTC 2019

Hi Viktor,

I'm not intimately familiar with AMD hardware (but Marek is, I'm sure
he'll opine when he gets a chance). Note that RV7xx is among the
DX10-class hardware which is older less tested nowadays compared to
the DX11-class r600-derived hardware (EG/NI), which admittedly is also
not exactly as popular as it once was. 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.

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?

I'm also CC'ing the wider list, as I believe it's of interest there.



On Sun, Apr 28, 2019 at 3:44 PM Viktor Jaegerskuepper
<viktor_jaegerskuepper at freenet.de> wrote:
> Dear Ilia, dear Marek,
> a few weeks ago I filed a bug for Firefox Nightly (68.0a1) which occurs
> when I use the new WebRender compositor on Linux. If you don't know what
> WebRender is, see here:
> https://wiki.mozilla.org/Platform/GFX/Quantum_Render
> The bug is that videos on Twitter aren't displayed properly. At first I
> thought that this is a regression in WebRender because it used to work
> before, so I used a Mozilla tool called mozregression to find the "bad"
> commit. Afterwards I remembered that I had upgraded Mesa from 18.3.4 to
> 19.0.0 a few days ago, and that this might have triggered the bug. So I
> bisected Mesa and found the commit which triggers this bug, which was
> indeed a change between the branch points of Mesa 18.3.0 and 19.0.0.
> This is the reason that I am writing to you now, it is commit
> 1250383e367fef6fdb954d69a7444634c6788f5d
> st/mesa: remove sampler associated with buffer texture in pbo logic
> with the following description:
> A long time ago, when this was first implemented, not having a sampler
> bound would cause problems on Fermi. I didn't work out the reasons, but
> the solution was simple -- just put the samplers back in.
> Since then, regular texturing paths appear to have lost their associated
> samplers which required a fuller investigation and fix in nouveau. Now
> that this is done, this code should no longer need a sampler state for
> fetching texels from a buffer texture.
> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
> Reviewed-by: Marek Olšák <marek.olsak at amd.com>
> I have two very old PCs, one desktop machine with an AMD RV770 running
> Arch Linux and a laptop with an AMD RV710 running Debian testing. On the
> desktop PC I am using a current (as of today) snapshot of the Mesa
> master branch built with LLVM 8.0.0, on the laptop I am using Mesa
> 19.0.2 from the Debian experimental repo (built with LLVM 8.0.0), I can
> reproduce the bug on both machines.
> Since the commit doesn't mention AMD hardware and so far nobody from
> Mozilla has reproduced the bug, do you have any idea why this old AMD
> graphics hardware could be affected by the change in Mesa? I didn't want
> to file another bug in the Mesa bug tracker, and neither the mesa-dev
> nor the mesa-users mailing lists seemed appropriate to ask for help.
> The Mozilla bug is:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1536878
> Thanks,
> Viktor

More information about the mesa-dev mailing list