diff options
author | Eric Anholt <anholt@FreeBSD.org> | 2004-08-17 01:41:29 +0000 |
---|---|---|
committer | Eric Anholt <anholt@FreeBSD.org> | 2004-08-17 01:41:29 +0000 |
commit | 6f3cc6a5226fd4b5d44cca91e2f76216ecaff831 (patch) | |
tree | 958ff79f2f928f34a522f4e4f16303ea2e215d6a /src/mesa/drivers/dri/radeon/radeon_ioctl.h | |
parent | 7e27ab4c6ae528daa0f64b9ce79231ff39a58b79 (diff) |
Close some races with locking on R100 and R200 which could manifest as rendering
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%).
Diffstat (limited to 'src/mesa/drivers/dri/radeon/radeon_ioctl.h')
-rw-r--r-- | src/mesa/drivers/dri/radeon/radeon_ioctl.h | 33 |
1 files changed, 33 insertions, 0 deletions
diff --git a/src/mesa/drivers/dri/radeon/radeon_ioctl.h b/src/mesa/drivers/dri/radeon/radeon_ioctl.h index 3f6e1751cf..695eb5770b 100644 --- a/src/mesa/drivers/dri/radeon/radeon_ioctl.h +++ b/src/mesa/drivers/dri/radeon/radeon_ioctl.h @@ -164,6 +164,39 @@ do { \ } \ } while (0) +/* Command lengths. Note that any time you ensure ELTS_BUFSZ or VBUF_BUFSZ + * are available, you will also be adding an rmesa->state.max_state_size because + * r200EmitState is called from within r200EmitVbufPrim and r200FlushElts. + */ +#if RADEON_OLD_PACKETS +#define AOS_BUFSZ(nr) ((3 + ((nr / 2) * 3) + ((nr & 1) * 2)) * sizeof(int)) +#define VERT_AOS_BUFSZ (0) +#define ELTS_BUFSZ(nr) (24 + nr * 2) +#define VBUF_BUFSZ (6 * sizeof(int)) +#else +#define AOS_BUFSZ(nr) ((3 + ((nr / 2) * 3) + ((nr & 1) * 2)) * sizeof(int)) +#define VERT_AOS_BUFSZ (5 * sizeof(int)) +#define ELTS_BUFSZ(nr) (16 + nr * 2) +#define VBUF_BUFSZ (4 * sizeof(int)) +#endif + +/* Ensure that a minimum amount of space is available in the command buffer. + * This is used to ensure atomicity of state updates with the rendering requests + * that rely on them. + * + * An alternative would be to implement a "soft lock" such that when the buffer + * wraps at an inopportune time, we grab the lock, flush the current buffer, + * and hang on to the lock until the critical section is finished and we flush + * the buffer again and unlock. + */ +static __inline void radeonEnsureCmdBufSpace( radeonContextPtr rmesa, + int bytes ) +{ + if (rmesa->store.cmd_used + bytes > RADEON_CMD_BUF_SZ) + radeonFlushCmdBuf( rmesa, __FUNCTION__ ); + assert( bytes <= RADEON_CMD_BUF_SZ ); +} + /* Alloc space in the command buffer */ static __inline char *radeonAllocCmdBuf( radeonContextPtr rmesa, |