Re: State of Linux graphics

[Jon Smirl]

On 8/31/05, Eric Anholt <eta@xxxxxxxxxx> wrote:
> the X Render extension."  No, EXA is a different acceleration
> architecture making different basic design decisions related to memory
> management and driver API.

I did start the EXA section off with this: "EXA replaces the existing
2D XAA drivers allowing the current server model to work a while
longer."

I'll edit the article to help clarify these points but Daniel has
disabled my login at fd.o so I can't alter the article.

> 
> "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@xxxxxxxxxx
> http://people.freebsd.org/~anholt/              anholt@xxxxxxxxxxx
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (FreeBSD)
> 
> iD8DBQBDFUr4HUdvYGzw6vcRAl0SAKCVOCHuVweh5CJoz8UzmkTqNxrEuwCfU/t0
> BJVf4HCTUJGn/g4JtsQO0Ds=
> =tWVr
> -----END PGP SIGNATURE-----
> 
> 
> 


-- 
Jon Smirl
jonsmirl@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/