On Nov 22, 2007 5:37 AM, Jerome Glisse <[EMAIL PROTECTED]> wrote: ... > I will go this way too for r300/r400/r500 there is not so much registers > change with different contexts and registers which need special treatment > will be handled by the drm (this boils down to where 3d get rendered and > where is the zbuffer and pitch/tile informations on this 2 buffers; this > informations will be embedded in drm_drawable as the cliprect if i am > right :)). It will be up to client to reemit enough state for the card > to be in good shape for its rendering and i don't think it's worthwhile > to provide facilities to keep hw in a given state.
Are you suggesting we emit the state for every batchbuffer submission? As I wrote in my reply to Keith, without a lock, you can't check that the state is what you expect and the submit a batchbuffer from user space. The check has to be done in the kernel, and then kernel will then emit the state conditionally. And even if this scheme can eliminate unecessary state emission, the state still have to be passed to the kernel with every batch buffer submission, in case the kernel need to emit it. > So i don't need a lock > and indeed my actual code doesn't use any except for ring buffer emission > (only shared area among different client i can see in my case). So you do need a lock? Could the ring buffer management be done in the drm by the super-ioctl code and would that eliminate the need for a sarea? 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
