On Tue, 2007-11-27 at 15:44 -0500, Kristian Høgsberg wrote: > 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?
For that, you'd either want 'switch context' ioctls, or context arguments with every request. The former is easy to retrofit, the latter would have to be done right now. > > 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. I think Keith's comment that knowing how to reinit is effectively the same as computing the reinitialization buffer may be relevant here. I'm not entirely sure this is true; it might be possible to save higher level information about the state than the ring contents. For Intel, I'm not planning on using this anyway, so I suspect Radeon will be the test case here. > > 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. From what I can tell, all Intel chips support MI_SET_CONTEXT, with the possible exception of i830. I'm getting some additional docs for that chip to see what it does, but the i845 docs mention the 'new context support'; dunno if that's new as of i830 or i845... > 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? With MI_SET_CONTEXT, you should never lose context, so we'd never need to be able to do this. > 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? Hardware context support actually looks really easy to add; it's just a page in GTT per drm client, then an extra instruction in the ring when context switching is required. I'll have to see if the i830 supports it though. The current mechanism actually looks a lot harder to handle; I don't know why the driver didn't use MI_SET_CONTEXT from the very start. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
