XFree86 5.0 TODO

On Fri, 21 Mar 2003, Mark Vojkovich wrote:

> On Thu, 20 Mar 2003, Kendall Bennett wrote:
>
> > Mark Vojkovich <[email protected]> wrote:
> > 
> > > > If you kill it, make sure you replace it with something that will provide 
> > > > equivalent functionality. Games and applications that wish to use 
> > > > fullscreen graphics under X11 can utilise DGA today, but if you kill it, 
> > > > you lose that ability. DGA is the closest thing that XFree86 has to 
> > > > DirectX, but it could be *way* better.
> > > 
> > >     The problem IS the functionality.  That functionality is
> > > unsafe and should go away.  There aren't many apps that use DGA in
> > > a legitimate way, and those that do should be seeking alternatives.
> > 
> > What particular functionality do you believe is unsafe? More 
> > particularly, if you believe it is unsafe, should we design a 'better' 
> > DGA style interface for fullscreen applications that can be safe? Once 
> > you have a safe replacement for DGA, then kill it off.
> 
>    I believe direct framebuffer access by clients to be unsafe.
> Part of this is because it can never have exclusive access to
> this hardware.  The server can VT switch away and you'll be
> writing over the framebuffer of another server.  At least in
> the case of NVIDIA hardware, there is critical state stored in
> the framebuffer and you can hang the system.  Additionally,
> there are implementation issues on various operating systems
> requiring clients to have root permissions.  While that can
> probably be worked around at the OS level, it doesn't change
> that fact that there are problems with arbitration of this
> shared resource that become difficult to solve when you are
> relying on any-old-client to work with it.  OpenGL direct
> rendering allows clients to touch the hardware directly - 
> sortof.  There is an arbitration architecture in place that
> is outside of the client's view and the applications itself
> doesn't see this hardware.  It goes through a trusted library.  
> OpenGL apps themselves aren't given pointers to hardware.
> So there's a big difference between OpenGL and DGA.
> 
>    I also believe the apps that operate by scribbling in the 
> framebuffer are passe.  If you're writing a game, use OpenGL.

 All of this is true.
DGA is an 2D graphics API providing an direct access of the
CPU to the framebuffer memory, but does not provide any
DMA-benefit mechanism. (except it's XDGACopy* funcs, but
they are "included with some reserveration" and are restricted
only from video memory to video memory).
And as we all know, the DMA transfer is much efficient than
the CPU-driven one (at least because the CPU is free to do
something else). So the only possible benefit of the DGA
would be if the application directly synthesizes it's image
in the frame buffer. But, of course, no-one goes this way,
because the video memory is much slower for the CPU
to work with it than the system memory, so all apps
generate their frames (or parts of them) - or already have them
in the system memory and then transfer them to the frame-buffer.
So in it's current form DGA is pretty useless even when we ignore
it's sequrity problems.

The only possible scenario I can see for meaningful use of DGA is this:
store your static sprites/pictures in an off-screen part of the frame-buffer
and then synthesize your on-screen frames by copying them
to the view-port by XDGACpoy* funcs.

Lucho