Quoting Jon Smirl ([EMAIL PROTECTED]): > --- Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > > I don't know how that's handled by others, > > but DirectFBGL applications have to Lock() and > > Unlock() the context. > > Only one context can be locked at the same time (in > > each DirectFB session). > > The Lock() method acquires DirectFB's graphics card > > lock and makes > > the context the current one, like > > glXMakeCurrent(non-null). > > The Unlock() method clears the current context, like > > glXMakeCurrent(null), > > and releases the graphics card lock. > > Does unlock really clear the context? There are loops > all over the drivers doing lock/unlock while waiting > on things to finish. Wouldn't it be better to track > which context is loaded?
With Lock()/Unlock() I refered to the IDirectFBGL::Lock()/Unlock() which is not called by the drivers but the application for each frame. The drivers' loops don't clear the context. > > Applications usually lock/unlock the context once > > around initialization and > > once for each complete frame, most probably calling > > IDirectFBSurface::Flip() > > afterwards or doing DirectFB graphics operations on > > the buffer in between. > > So is DRI vunerable to an app seg faulting while it > holds the context lock? AFAIK the DRM blocks certain signals like SIGSTOP while the lock is held. I don't know about SIGSEGV. This is an issue of DirectFB, too. When an application terminates (even on SIGKILL) the Fusion kernel module automatically releases all locks and decreases all reference counters by the app's amount. This doesn't handle SIGSTOP, e.g. if you are running a DirectFB app started from a terminal within a DirectFB session and press Ctrl-Z, it may happen that the session is dead locked because you cannot type "bg" or "fg" to resume the app. I'm not sure if I should block or defer SIGSTOP while global locks are held. > > > Do state changes get queued like other 3D ops? > > > > Do you mean changes to the current state or > > switching from one > > state to another? > > One possible hardware implementation would work by > queuing a "load context" command follow by operations > on the selected context. That way you wouldn't have to > acquire a lock on the card, you would just add your > stuff to the queue. I guess that the queue is flushed before loading another context. > I used to work on network hardware with a similar > command queue structure. The fastest scheme for it was > to leave the network processor in a loop executing NOP > commands. The main CPU would then alter the NOP > command to point to a chain of commands. At the end of > the chain there is another NOP loop. This lets you > avoid start/stopping the coprocessor and avoids > interrupts from the coprocessor saying it was > finished. On a Matrox you simply advance the DMA end pointer IIRC. I don't know about other cards. > > > Finally, the questions I am trying to answer for > > the R200... > > > 1) When implementing per context drawables how do > > I > > > make sure the hardware knows what buffer I am > > drawing > > > to? Is the code already written for this since > > each > > > context can be drawing into either the front or > > the > > > back buffer? > > > 2) How do modify the clear functions not to use a > > > global variable for the buffer pointer, instead > > they > > > need to get it from the context? > > > > You should have a look at how it's done for MGA in > > the embedded-2-branch. > > The DRM module provides an "extended state" bound to > > each context > > without breaking compatibility. > > > > The r200 context already contains pointers to the > buffer: CTX_RB3D_COLOROFFSET, CTX_RB3D_COLORPITCH. So > I don't think I need to extend the state structure. > The only problem I see is that clears are implemented > using the 2D hardware. Clears get the buffer address > from a global variable in the device driver instead of > getting it from the context. The clears in the mga module use the global values or the extended state values if requested. > After changing clears I think per context drawables > should work on the r200. Fine, but does it also include per context depth buffers? -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
