Kristian Høgsberg wrote: > On Nov 27, 2007 2:30 PM, Keith Packard <[EMAIL PROTECTED]> wrote: > ... >>> 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). > > Oh, right we don't need one per GLContext, just per DRI client, mesa > handles switching between GL contexts. What about multithreaded > rendering sharing the same drm fd? > >>> 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'. > > Exactly. > >>> 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. > > Is it that bad? We will still need the resubmit code for older > chipsets that dont have the hardware context support. The drivers > already have the code to emit state in case of context loss, that code > just needs to be repurposed to generate a batch buffer to prepend to > the rendering code. And the rendering code doesn't need to change > when resubmitting. Will that work? > >> 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. > > Yeah - I'm trying to limit the scope of DRI2 so that we can have > redirected direct rendering and GLX1.4 in the tree sooner rather than > later (before the end of the year). Maybe the best way to do that is > to keep the lock around for now and punt on the lock-less super-ioctl > if that really blocks on hardware context support. How far back is > hardware contexts supported?
There are three ways to support lockless operation - hardware contexts - a full preamble emit per batchbuffer - passing a pair of preamble, payload batchbuffers per ioctl I think all hardware is capable of supporting at least one of these. That said, if the super-ioctl is per-device, then you can make a choice per-device in terms of whether the lock is required or not, which makes things easier. The reality is that most ttm based drivers will do very little differently on a regular lock compared to a contended one -- at most they could decide whether or not to emit a preamble they computed earlier. Keith ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel