Revert the move of lost_context setting to UNLOCK_HARDWARE that was done in the

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.

1 files changed, 0 insertions, 11 deletions

diff --git a/src/mesa/drivers/dri/radeon/radeon_lock.h b/src/mesa/drivers/dri/radeon/radeon_lock.h
index e18a642088..c2e0c3706b 100644
--- a/src/mesa/drivers/dri/radeon/radeon_lock.h
+++ b/src/mesa/drivers/dri/radeon/radeon_lock.h
@@ -99,23 +99,12 @@ extern int prevLockLine;
       DEBUG_LOCK();						\
    } while (0)
 
-/* Unlock the hardware.  We must assume that state has been lost when we unlock,
- * because when we next grab the lock (to emit an accumulated cmdbuf), we don't
- * have the information to recreate the context state as of the last unlock in
- * in the case that we did lose the context state.
- *
- * The alternative to this would be to copy out the state on unlock
- * (approximately) and if we did lose the context, dispatch a cmdbuf to reset
- * the state to that old copy before continuing with the accumulated command
- * buffer.
- */
 #define UNLOCK_HARDWARE( rmesa )					\
    do {									\
       DRM_UNLOCK( rmesa->dri.fd,					\
 		  rmesa->dri.hwLock,					\
 		  rmesa->dri.hwContext );				\
       DEBUG_RESET();							\
-      rmesa->lost_context = GL_TRUE;					\
    } while (0)
 
 #endif