----- Original Message ----- > On Tue, Jan 17, 2012 at 15:47, Stéphane Marchesin > <stephane.marche...@gmail.com> wrote: > > On Wed, Jan 11, 2012 at 10:13, Jose Fonseca <jfons...@vmware.com> > > wrote: > >> ----- Original Message ----- > >>> Where else would the flush go? > >> > >> Maybe one of the callers already invoked glFlush, or something > >> like that. > >> > >>> I'll look into fixing it differently > >>> but if the flush is anywhere in the makecurrent path, the same > >>> issue > >>> will happen. Again, none of the classic dri drivers do it. > >> > >> If you wanna a short term fix, it might be OK with just commenting > >> out the flush call, but please leave a note there saying that a > >> flush is needed for strict conformance. > >> > > > > Ok I'll push this for now as it fixes a bunch of Chrome bugs. I > > guess > > I'm confused why no other drivers do it, but maybe they're just all > > non-conformant.... > > > > Ah I understand how things work a little better now. I see two cases > where the removal of this flush could be an issue: > - The unbind-after-destroy case. In that case we're good since the > flush has happened in dri_destroy_context already. > - Makecurrent path. Again in that case dri_make_current flushes the > old context. > > Therefore I think the flush in dri_unbind_context is not needed. > Please let me know if you see a flaw in this analysis.
It looks you got all covered. And it would explain why other drivers don't need it. So your patch looks good. Before commiting, please put a comment describing that flush already happens elsewhere, so that this issue doesn't pop up again. Thanks Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
