Kristian Høgsberg wrote: > 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.
I didn't explained myself properly, i did mean that it's up to the client to reemit all state in each call to superioctl so there will be full state emission but i won't check it ie if it doesn't emit full state then userspace can just expect to buggy rendering. Meanwhile there is few things i don't want the userspace to mess with as they likely need special treatment like the offset in ram where 3d rendering is going to happen, where are ancillary buffers, ... i expect to have all this informations attached to a drm_drawable (rendering buffer, ancillary buffer, ...) so each call of superioctl will have this: -drm_drawable (where rendering will be) -full state -additional buffers needed for rendering (vertex buffer, textures, ...) >> 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? This ring lock is for internal use only, so if one client is in superioctl and another is emitting a fence both need to write to ring but with different path to avoid any userspace lock i have a kernel lock which any functions writing to ring need to take; as writing to ring should be short this shouldn't hurt. So no i don't need a lock and i don't want a lock :) Hope i expressed myself better :) Cheers, Jerome Glisse ------------------------------------------------------------------------- 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
