Re: [Dri-devel] Architecture of graphics contexts

[Jon S. <jon...@ya...>]

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 <do...@di...> 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
jon...@ya...

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com