State of Linux graphics

[Eric Anholt]

On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> I've written an article that surveys the current State of Linux
> graphics and proposes a possible path forward. This is a long article
> containing a lot of detailed technical information as a guide to
> future developers. Skip over the detailed parts if they aren't
> relevant to your area of work.
> 
> http://www.freedesktop.org/~jonsmirl/graphics.html
> 
> Topics include the current X server, framebuffer, Xgl, graphics
> drivers, multiuser support, using the GPU, and a new server design.
> Hopefully it will help you fill in the pieces and build an overall
> picture of the graphics landscape.
> 
> The article has been reviewed but if it still contains technical
> errors please let me know. Opinions on the content are also
> appreciated.

"EXA extends the XAA driver concept to use the 3D hardware to accelerate
the X Render extension."  No, EXA is a different acceleration
architecture making different basic design decisions related to memory
management and driver API.

"If the old hardware is missing the hardware needed to accelerate render
there is nothing EXA can do to help."  Better memory management allows
for better performance with composite due to improved placement of
pixmaps, which XAA doesn't do.  So EXA can help.

"So it ends up that the hardware EXA works on is the same hardware we
already had existing OpenGL drivers for."  No.  See, for example, the nv
or i128 driver ports, both completed in very short timeframes.

"The EXA driver programs the 3D hardware from the 2D XAA driver adding
yet another conflicting user to the long line of programs all trying to
use the video hardware at the same time."  No, EXA is not an addition to
XAA, it's a replacement.  It's not "yet another conflicting user" on
your machine (and I have yet to actually see this purported conflict in
my usage of either acceleration architecture).

"There is also a danger that EXA will keep expanding to expose more of
the chip’s 3D capabilities."  If people put effort into this because
they see value in it, without breaking other people's code, why is this
a "danger?"

-- 
Eric Anholt                                     eta at lclark.edu
http://people.freebsd.org/~anholt/              anholt at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050830/e0dc95bb/attachment-0001.pgp>