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

[Ilia Mirkin]

Thing is, I think that would not be enough - with the "recent" (like
past 2 years) CSO/state change detection changes, I think that you can
end up with no sampler set for a buffer view. Perhaps someone with the
hw can investigate what goes wrong?

On Mon, Apr 29, 2019 at 5:42 PM Marek Olšák <maraeo at gmail.com> wrote:
>
> 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