On Tue, 2007-11-27 at 14:03 -0500, Kristian Høgsberg wrote: > 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).
Yeah, intel hardware uses memory and has no intrinsic limit to the number of contexts; they just need to be pinned in GTT space and given a unique address. > 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. We needn't expose the contexts to user-space, just provide a virtual consistent device and manage contexts in the kernel. We could add the ability to manage contexts from user space for cases where that makes sense (like, perhaps, in the X server where a context per client may be useful). > 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... I recall having the same discussion in the past; have the superioctl fail so that the client needn't constantly compute the full state restore on every submission may be a performance win for some hardware. All that this requires is a flag to the kernel that says 'this submission reinitializes the hardware', and an error return that says 'lost context'. > 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. We should do the lockless and context stuff at the same time; doing re-submit would be a bunch of work in the driver that would be wasted. Right now, we're just trying to get 965 running with ttm; once that's limping along, figuring out how to make it reasonable will be the next task, and hardware context support is clearly a big part of that. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
