It is a little hard to see where development is going:
is EXA a one-for-one replacement for XAA, or just for some use cases?
Is UXA a replacement for EXA, or a branch of some ideas that will be remerged?
Surely 99.999% of graphics implementations will be one of Intel, Nvida, AMD/ATI and Via (I've not come across anything else for years now, and certainly not one which allows you to use multiple adapters).
Is there a case for streamlining X down to EXA/UXA and drivers which support one of those....?
I've rootled around on xorg.freedesktop.org, but can't really find obvious answers to these sorts of questions.
Users of, say Matrox, would probably be pretty content with the feature set of Xorg 7.current.
Posted Feb 19, 2009 12:48 UTC (Thu) by nix (subscriber, #2304)
[Link]
As far as I can tell the intention is for EXA to replace XAA entirely. As of (very) recently it even does core fonts nice and fast, so unless you rely on things like stipple acceleration (!) I'd say it's getting there quite well.
(downside: it looks like Speedo and Type1 core fonts are about to stop working, as the code to handle them has been torn out of libXfont 1.4.0. I doubt anyone misses Speedo, but Type1 may very well be missed, because they *do* still work client-side.)
Acceleration Architectures, state of the art.
Posted Feb 20, 2009 5:05 UTC (Fri) by jamesh (guest, #1159)
[Link]
While the Type1 code is gone from libXfont, it still has the FreeType backend. Given that FreeType can read Type1 fonts, is it possible that they were just removing a superfluous backend and switching to the code base that everyone else uses? (including the apps that use Xft).
Acceleration Architectures, state of the art.
Posted Feb 20, 2009 10:44 UTC (Fri) by nix (subscriber, #2304)
[Link]
It's possible. I'm not entirely sure *where* libXfont is used, to be
honest (something or other to do with core fonts). I used to know; I need
a prosthetic memory.
Acceleration Architectures, state of the art.
Posted Feb 20, 2009 14:47 UTC (Fri) by jamesh (guest, #1159)
[Link]
LibXfont is pretty much just the core font support library. Any application that has been ported to fontconfig (using Xft or cairo) won't be using it, and should retain Type1 support through the use of freetype.
Looking at the libXfont 1.4.0 release notes, it looks like you were correct about Type1 fonts not working with the new version. That said, I totally understand the desire to reduce the size/complexity of the core font code: the feature is deprecated, but can't easily be removed as it is not an extension to the X protocol.
If they can support Type1 fonts through FreeType with minimal effort, then great. If they can't, it isn't a huge loss.
Acceleration Architectures, state of the art.
Posted Feb 23, 2009 16:54 UTC (Mon) by jcristau (subscriber, #41237)
[Link]
Only the old type1 libXfont backend has been removed, support for type1 fonts from the freetype backend is still there.
Acceleration Architectures, state of the art.
Posted Feb 19, 2009 18:59 UTC (Thu) by kingdon (subscriber, #4526)
[Link]
Posted Feb 20, 2009 0:57 UTC (Fri) by wookey (subscriber, #5501)
[Link]
Those manufacturers may account for nearly all PC/x86 type machines, but that is not the whole X space. Modern ARM chips, as used in things like smartphones, and soon to be seen in netbooks, now have 3D graphics cores in them, such as the powerVR from Imagination in Cortex A8-based CPUs. This looks likely to be a non-trivial fraction of devices in the future, so X shouldn't be ignoring them, although my understanding is that Imagination are about as helpful as nVidia when it comes to free drivers.
Acceleration Architectures, state of the art.
Posted Feb 21, 2009 14:00 UTC (Sat) by roblucid (subscriber, #48964)
[Link]
> Surely 99.999% of graphics implementations will be one of Intel, Nvida,
> AMD/ATI and Via (I've not come across anything else for years now, and
> certainly not one which allows you to use multiple adapters).
Some of us still have Matrox cards, which were a well supported card if you liked Open Source drivers, not so long ago and thus reccomended. I don't know if the dual monitor output still works, but it'd be bad form to drop support of cards that were FOSS favoured, only five years ago.
Acceleration Architectures, state of the art.
Posted Feb 23, 2009 17:48 UTC (Mon) by dbnichol (subscriber, #39622)
[Link]
It has definitely been the plan for a long time to get all drivers onto EXA. XAA is only receiving bug fixes in the server. On the other hand, UXA is used by the intel driver to play nice with GEM and KMS. It started as a straight clone of EXA, though. I don't know if the UXA features can be ported back to EXA in the server. You'd probably have to ask keithp or anholt.
Acceleration Architectures, state of the art.
Posted Feb 28, 2009 12:53 UTC (Sat) by daenzer (✭ supporter ✭, #7050)
[Link]
> On the other hand, UXA is used by the intel driver to play nice with GEM
> and KMS. It started as a straight clone of EXA, though. I don't know if
> the UXA features can be ported back to EXA in the server. You'd probably
> have to ask keithp or anholt.
And take their answers with a big grain of salt... There's nothing to be
ported back, really. UXA basically just removes the EXA code the intel
driver doesn't need. However, it could 'play nice with GEM and KMS' (i.e.
use buffer objects for pixmap storage) in pretty much the same way with EXA,
and the code that was removed would be inactive.
Acceleration Architectures, state of the art.
Posted Feb 28, 2009 13:10 UTC (Sat) by daenzer (✭ supporter ✭, #7050)
[Link]
> is EXA a one-for-one replacement for XAA, or just for some use cases?
EXA is designed for modern compositing environments, whereas XAA is
excessively optimized for every little bit of core X11 rendering operations
and hasn't really evolved much this millenium. So while EXA should be on par
or faster with modern applications (especially with a compositing manager,
even just xcompmgr -a) it'll probably never be able to match XAA in all
cases with older applications, at least not without turning into the same
kind of monster.