Reverting the st/mesa commit would be fine. Marek
On Mon, Apr 29, 2019 at 3:20 PM Ilia Mirkin <[email protected]> wrote: > On Mon, Apr 29, 2019 at 3:06 PM Viktor Jaegerskuepper > <[email protected]> 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
