Getting to a GL based X server

[Adam Jackson]

On Friday 27 May 2005 15:04, Ian Romanick wrote:
> Adam Jackson wrote:
> > KAA basically just accelerates blits and solid fills (and Render blends,
> > but we're assuming no hardware alpha).  I really wouldn't worry about
> > line drawing at all; it never gets used by real apps and it almost
> > assuredly won't conform to the X spec.
>
> That's *it*?  To do this, how many functions does the driver expose?
> The idea of adding one or two trivial GL extensions that expose fast
> paths for all the KAA functionality is sounding better and better to me.

Look at KaaScreenInfoRec in xserver/hw/kdrive/src/kdrive.h.  Basically for 
each of Solid, Copy, Blend, Composite and Trapezoid you have a three 
functions: PrepareFoo, Foo, DoneFoo.  There's also two helpers to control 
uploading pixmaps to the card.

I don't think there are any cards with no 3D engine but with a hardware alpha 
channel, so we're really only considering Solid and Copy plus the helpers, so 
that's all of eight functions.

> 2. Scanline cards.  Cards like the Virge and G100 fall into this
> category.  These are cards where the driver has to rasterize triangles
> and send information about each scanline to the card.  Not all cards in
> this category support texturing (e.g., pre-G100 Matrox cards and 3dlabs
> 300SX), so this /may/ need to be divided into two categories.  Either
> way, there is no easy way to make Mesa accelerate anything on cards like
> this.

Max Lingua did write a DRI driver for the virge.  It even builds in Mesa HEAD, 
though there's no DDX or DRM support for it yet.  He claimed it made things 
faster, I have no reason to doubt this claim.

However you're certainly right that there's no _easy_ way to support these.  
The s3v code is a macro nightmare.

Render pretty well corresponds to ARB_multitexture, and I don't know of any 
scanline cards that could pull that off.  It may be possible to acheive the 
same effect using a multipass algorithm, but I don't think that algorithm has 
been written yet.  Blit and solid fill for this class of card would probably 
be best done using the 2d engine though.

> There are three bits of information that would be interesting to gather.
>   I think this will help guide where effort should be applied first.
>
> 1. Which cards are in which categories based on available drivers &
> documentation *today*?  The Permedia2 is technically a category 1 card,
> but is in category 3 today.

Assuming we're referring only to drivers in Mesa and Xorg:

1) ffb (barely), i810 (and successors), mach64, mga (g200+), rage128, r100, 
r200, savage (3d and 4), sis (300 and 315 series only), tdfx (voodoo3+), 
trident (barely), unichrome, 3dlabs gamma (kinda)
2) virge (kinda)
3) apm, ark, chips, cirrus, cyrix, any other 3dlabs cards, i128, i740, 
ixmicro, mga (pre-g200), neomagic, newport, nsc, nv, r300, r400, rendition, 
s3 (pre-virge), savage (2000), siliconmotion, sis (everything else), tga, 
trident (basically everything), tseng, voodoo (1 and 2), any sun* driver 
besides sunffb
4) fbdev, vesa, vga, vmware, any chip not previously mentioned (s3 
deltachrome, xgi, powervr, etc.)

I suppose it's not exactly correct to list r300 in group 3 but trident in 
group 1.  Oh well.

> 2. Which cards would be in different categories with additional
> documentation?  The FireGL2 is in category 4, but could be in category 1.

I'll drop "with additional documentation" for this response, there are some 
that are documented that no one's done anything with yet:

nvidia (nv1 and nv3+), rendition, sis (everything else), xgi, one or two 
cirrus cards, neomagic magicmedia 256xl+, 3dlabs non-gamma, voodoo 1 and 2, 
i128, siliconmotion, ati r300 and r400, intel i740/i752, powervr, sunleo (and 
anything else newer than sunffb), various SGI/DEC/HP/IBM/E&S workstation 
cards, mga p-series, firegl's 1 through 4, various tridents, s3 deltachrome 
and gammachrome, ixmicro, savage 2k.  and then about a dozen more first-gen 
cards that were announced but may not have ever actually shipped, and a fair 
stack of embedded chips from people like broadcom and bitboys.

So out of the 29 in class 3 above, we could move at least 15 of them into 
classes 1 or 2.  There's also at least a half-dozen cards where we have no 
driver support at all but could have them in class 1.  And maybe nv1, 
although it's neither triangle-oriented nor scanline-oriented.

> 3. How much do we "care" about each card?

Tough to answer that one.  I'm not particularly interested in cards with no 3D 
engine, but as we can see, that's not exactly eliminating a large subset.  
And class 2 is pretty small.  Even if you limit it to cards with working 
ARB_multitexture there's still about 10 we could support but don't.

I think of the above list the only card where the docs have in fact fallen off 
the face of the earth is the iXMicro, unless someone knows who bought them up 
when they folded or has a copy of the old MacOS driver source.  For 
everything else it's just a social challenge of making it in their best 
interests to enable the driver to exist.

As a practical matter, you're going to want to support those chips which you 
can buy retail.  So that's anything from ATI, nVidia, Matrox, Intel, Via, 
SiS, S3, XGI, and I guess 3dlabs.  Five those those ship closed drivers for 
their current cards, which is a bad thing for us to encourage; three have 
open drivers with varying degrees of usefulness (only one through any sort of 
formal support process, afaict); and one doesn't have drivers for their 
current cards in X.

So KAA-style support for these cards is okay in a sense, since it gets us to 
at least xcompmgr-level functionality with a minimum of pain.  But we really 
need a culture of open drivers.  And my fear in diving headlong into an Xegl 
world is that we're raising the barrier to entry to driver hacking from the 
KAA level of 17 entrypoints to accelerate, to the Mesa level of several 
hundred.  If we can make DRI skeletons that expose blit acceleration for the 
dumb or undersupported cards, that a start.  But it's a technical workaround 
for the social problem that IHVs are actively hostile to the idea of open 
drivers, and I don't think we should resign ourselves to that fate.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050527/e96a69f6/attachment.pgp>