> > I'm trying to figure out how context switches acutally work... the DRI > lock is overloaded as context switcher, and there is code in the > kernel to call out to a chipset specific context switch routine when > the DRI lock is taken... but only ffb uses it... So I'm guessing the > way context switches work today is that the DRI driver grabs the lock > and after potentially updating the cliprects through X protocol, it > emits all the state it depends on to the cards. Is the state emission > done by just writing out a bunch of registers? Is this how the X > server works too, except XAA/EXA acceleration doesn't depend on a lot > of state and thus the DDX driver can emit everything for each > operation?
So yes userspaces notices context has changed and just re-emits everything into the batchbuffer it is going to send, for XAA/EXA stuff in Intel at least there is an invarient state emission functions that notices what the context was and what the last server 3D users was (EXA or Xv texturing) and just dumps the state into the batchbuffer.. (or currently into the ring) > How would this work if we didn't have a lock? You can't emit the > state and then start rendering without a lock to keep the state in > place... If the kernel doesn't restore any state, whats the point of > the drm_context_t we pass to the kernel in drmLock? Should the kernel > know how to restore state (this ties in to the email from jglisse on > state tracking in drm and all the gallium jazz, I guess)? How do we > identify state to the kernel, and how do we pass it in in the > super-ioctl? Can we add a list of registers to be written and the > values? I talked to Dave about it and we agreed that adding a > drm_context_t to the super-ioctl would work, but now I'm thinking if > the kernel doesn't track any state it wont really work. Maybe > cross-client state sharing isn't useful for performance as Keith and > Roland argues, but if the kernel doesn't restore state when it sees a > super-ioctl coming from a different context, who does? > 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.. Dave. ------------------------------------------------------------------------- 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
