On Mon, Apr 29, 2019 at 3:06 PM Viktor Jaegerskuepper <viktor_jaegerskuep...@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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev