Ian Romanick <i...@freedesktop.org> writes: > I'm a little bit skeptical of this. _mesa_make_current doesn't call > intelMakeCurrent. intelMakeCurrent calls _mesa_make_current, and it > calls _mesa_make_current much later in this function. By the time > _mesa_make_current is called, a bunch of driver state has been > changed... and I bet the later call to _mesa_flush will do bad things. > > This also seems like a really tough bug to trigger. :(
Hrm, looking at it a bit more with gdb, it looks like the call to _mesa_flush in intelMakeCurrent is never actually used at least with GLX. The reason is that MakeContextCurrent in glxcurrent.c first calls unbind if there is a context before calling bind. This calls intelUnbindContext which in turn calls _mesa_make_current(NULL…). So I guess that means whenever intelMakeCurrent is called then curCtx is always NULL. The call to _mesa_flush in _mesa_make_current was added in 93102b4c. In the log message for that commit it says that that was to fix a regression since b4bb668020. That commit is actually the one that adds _mesa_make_current(NULL) in intelUnbindContext so I guess that makes sense. If it's true that the flush is never actually hit then I think it would be good to remove it regardless of this patch series. However if we are worried that not flushing when switching contexts will mess up some expectations in intelMakeCurrent then we have a bigger problem that the extension is not going to work at all. I guess I should try to explore intelMakeCurrent in a bit more detail to try to determine whether it's ok not to flush. - Neil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
