<div dir="ltr"><div>Reverting the st/mesa commit would be fine.</div><div> </div><div>Marek </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at 3:20 PM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Apr 29, 2019 at 3:06 PM Viktor Jaegerskuepper <<a href="mailto:viktor_jaegerskuepper@freenet.de" target="_blank">viktor_jaegerskuepper@freenet.de</a>> 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 <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a></blockquote></div>