On Nov 26, 2007 11:15 PM, Keith Packard <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-11-26 at 17:15 -0500, Kristian Høgsberg wrote: > > > > -full state > > I assume you'll deal with hardware which supports multiple contexts and > avoid the need to include full state with each buffer?
As for hardware contexts, I guess there are two cases; hardware that has a fixed set of contexts builtin and hardware where a context is just a piece of video memory that you can point to (effectively an unlimited number of contexts). I both cases, the kernel will need to know how to activate a given context and the context handle should be part of the super ioctl arguments. In the case of unlimited contexts, that may be all that's needed. In the case of a fixed number of contexts, you will need to be able to restore state when you have more software contexts in use that you have hardware contexts. I imagine one optimiation you could do with a fixed number of contexts is to assume that loosing the context will be very rare, and just fail the super-ioctl when it happens, and then expect user space to resubmit with state emission preamble. In fact it may work well for single context hardware... But the super-ioctl is chipset specific and we can decide on the details there on a chipset to chipset basis. If you have input to how the super-ioctl for intel should look like to support lockless operation for current and future intel chipset, I'd love to hear it. And of course we can version our way out of trouble as a last resort. cheers, 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
