XAA vs. EXA in old hardware support

[Alex Deucher]

On 6/16/06, Michael Lorenz <macallan at netbsd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> >> just a stupid question - a while ago I wrote an XFree86 driver for the
> >> Weitek P9100 graphics chip found in Tadpole SPARCbook 3GX and similar
> >> laptops. ( the P9100 driver in XFree86 3.x wasn't really helpful -
> >> this
> >> P9100 has an SBus interface and does a few things rather differently.
> >> It also lacks the VGA part. )
> >> So the question is - the driver of course uses XAA primitives. Should
> >> I
> >> bother with EXA when porting it over to xorg? There is no hardware
> >> support for alpha-blending or anything like that - just plain old
> >> rectangles, area copies, lines, clipping, colour expansion.
> >>
> >> The same goes for suncg6 - I added support for most of the hardware
> >> acceleration these old critters offer ( didn't bother with pattern
> >> fills but that's trivial to add ).
> >>
> >
> > I would say it's up to you.  EXA is the future, but I don't see XAA
> > going anywhere anytime soon.
>
> Ok, so I'll leave it as it is for now.
>
> >   For that hardware with EXA all you'd
> > really have to worry about is solids and copies (and possibly hostdata
> > blits for UTS depending on the performance) so it's somewhat less code
> > to port.
>
> So EXA dropped hardware line drawing? On both the P9100 and the cg6
> it's significantly faster than in software, especially on newer cg6
> where it's quite a huge margin. Probably doesn't have much of an effect
> on overall X performance I guess.

Most modern desktops don't use lines anymore and EXA takes care of
some lines internally via solid rectangles.

>
> About host-to-vram blits - so far I'm running the P9100 with
> endianness-conversion on vram accesses enabled. This doesn't affect the
> upload port though, so data would have to be endianness-converted in
> 32bit chunks which I didn't bother with. Being able to use this would
> be useful since the sparc requires natural alignment of all memory
> accesses and the upload port is a way around that.
> So, question is - do you think that's worth checking? I'm really not
> sure if the extra cycles needed for endianness conversion would eat up
> the benefit.

You'd have to benchmark it and see if it was a win.  Implement a
memcpy based exa UploadtoScreen() and a hostdatablit based
UploadtoScreen() and see who wins.

Alex

>
> have fun
> Michael
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
>
> iQEVAwUBRJMgpMpnzkX8Yg2nAQI7hwgAgp7g8rY+A4xG8tDwVIX5kr4QpqF0dy6e
> ctj8Xgd28+nDYafnztap8y7PAq2QSrFxpI3Bxpi+jW5I4XLwCEd7sSBuGeWisJG3
> 4KGgqLcDAjm+PLMqmzL3ahijJMNCsQMvrsEoWqyGV8dqe+zNdGDnQuQSqnyNhUxW
> DT4m8CQ0v7ABhEVa1AbS818FXvH85XdtXsHw55oCk9ckmdG2v3oTIOn99jM7KOqj
> ZTUtl25Z8rrSuHi3jaQjE+6Apoj6SgZK/FIE7s+Yr3GW7fqw3Aqcs9MoCcJaQE8E
> /vX1wza9rljKTUF0rK8uImcRo+dvpBTc3wcoGisjRxNGgGzLsI295g==
> =QHSm
> -----END PGP SIGNATURE-----
>
>