Thanks for taking the time to respond to this. I am starting to understand why so few people choose to work on the OpenGL code. Much of what you need to know is either undocumented or restricted by the hardware vendors.
--- Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > > When multitasking, how does the context get > changed? > > 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? > 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? > > 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 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. > > 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. After changing clears I think per context drawables should work on the r200. > Best regards, > Denis Oliver Kropp ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- 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
