----- Original Message ----- > On Wed, Jan 11, 2012 at 10:13, Jose Fonseca <[email protected]> > wrote: > > ----- Original Message ----- > >> Where else would the flush go? > > > > Maybe one of the callers already invoked glFlush, or something like > > that. > > > > Not that I could see. > > >> 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. > > Maybe I'll do that, what about those lines in > g/st/dri/common/dri_drawable.c: > /* XXX remove this and just set the correct one on the framebuffer */ > drawable->flush_frontbuffer(drawable, statt); > > It's on the same path that leads to that crash and seems to suggest > that the flush might not be required?
No, I don't think so. This will just flush the drawable and not the context, ie., whatever was renderered to the fake front buffer will be displayed, but draw calls batched in the context may not happen. Jose _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
