last commit. I've been convinced by keithw that it's sufficient, and put a note
in the code about it.
Close another race for state in the Clear functions. I made the situation worse
in my last commit, but this should fix things. Might be a slight performance
hit, which could be regained by splitting the R*_FIREVERTICES calls in r*Clear
up so that the EmitState doesn't happen in a separate new cmdbuf.
errors on r100 and rendering errors and hangs on r200 (same for R100 without
OLD_PACKETS).
If a command buffer filled after some state (EmitState or a VBPNTR write) was
emitted, the lock was grabbed, the buffer flushed, a new buffer prepared, and
the lock dropped. Another client could come in, set its own state as part of
rendering, and when the first client flushed the rendering commands depending
on the previous state, it got the 2nd client's state. This is fixed by checking
for enough space before beginning a set of state emits and rendering, and
flushing the buffer first if so. This guarantees that the buffer won't wrap.
Also, move the "lost_context = 1" from the end of cmdbuf flushing to
UNLOCK_HARDWARE for clarity (at a minimum) that any time the lock is dropped,
state may get overwritten. We don't have enough information at the point of the
LOCK_HARDWARE to reset our state to the last UNLOCK_HARDWARE point in the case
that we did lose our context, but saving the information to rebuild that state
may be a useful optimization (ipers data suggests up to 5%).
I shouldn't:
Official BeOS GLView.h defines a virtual ErrorCallback(GLenum) method, assuming
a unsigned long GLenum.
But under Mesa, GLenum is unsigned int.
To keep binary compatibility, BeOS apps including Mesa GL/gl.h MUST include *our*
GLView.h, or linker will report a missing ErrorCallback(unsigned int) symbol. Glup.
