On Nov 26, 2007 3:40 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote: > 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, ...)
Great, thanks for clarifying. Sounds good. > >> 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 :) Hehe, I guess I've been a bit unclear too: what I want to make sure we can get rid of is the *userspace* lock that's currently shared between the X server and the DRI clients. What hear you saying above is that you still need a kernel side lock to synchronize access to the ring buffer, which of course is required. The ring buffer and the lock that protects is lives in the kernel and user space can't access it directly. When emitting batchbuffers or fences, the ioctl() will need to take the lock, but will always release it before returning back to userspace. Sounds like this will all work out after all :) 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
