On Nov 22, 2007 4:23 AM, Keith Whitwell <[EMAIL PROTECTED]> wrote: ... > > My guess for one way is to store a buffer object with the current state > > emission in it, and submit it with the superioctl maybe, and if we have > > lost context emit it before the batchbuffer.. > > The way drivers actually work at the moment is to emit a full state as a > preamble to each batchbuffer. Depending on the hardware, this can be > pretty low overhead, and it seems that the trend in hardware is to make > this operation cheaper and cheaper. This works fine without the lock. > > There is another complimentary trend to support one way or another > multiple hardware contexts (obviously nvidia have done this for years), > meaning that effectively the hardware (effectively) does the context > switches. This is probably how most cards will end up working in the > future, if not already. > > Neither of these need a lock for detecting context switches.
Sure enough, but the problem is that without the lock userspace can't say "oops, I lost the context, let me prepend this state emission preamble to the batchbuffer." in a race free way. If we want conditional state emission, we need to make that decision in the kernel. For example, the super ioctl could send the state emission code as a separate buffer and also include the expected context handle. This lets the kernel compare the context handle supplied in the super ioctl with the most recently active context handle, and if they differ, the kernel queues the state emission buffer first and then the rendering buffer. If the context handles match, the kernel just queues the rendering batch buffer. However, this means that user space must prepare the state emission code for each submission, whether or not it will actually be used. I'm not sure if this is too much overhead or if it's negligible? Kristian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
