Re: Xorg vs. SPARC, was Re: "Hard memory error" on TurboSPARC equipped SS5 only when using NetBSD

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Tue, 25 Aug 2015 16:09:48 +0300
lausgans%gmail.com@localhost wrote:

> >> One problem with some of them is that the only acceleration scheme
> >> supported is XAA - EXA just assumes that the blitter supports offsets
> >> and variable pitch, which isn't true on a lot of older hardware ( like
> >> cg6 ) and XAA is supposed to be dropped, or was already. Since there is
> >> other hardware with the same problem I'll just have to write a memory
> >> manager for EXA that uses coordinates instead of offset & pitch, and
> >> use that on cg6, crime and the like.
> 
> Thanks for pointing to this. I thought EXA is suitable for these prior.

On CG6 we usually don't have useful amounts of off-screen memory anyway
( most are 1MB running at 1152x900 ), and there is nothing that would
help xrender, so we could get away with simply not trying to use
off-screen memory. Then again, I have several CG6 that do have enough
memory.
Crime uses main memory and supports all sorts of alpha blending so that
one definitely needs decent EXA support, which is not trivial thanks to
the coordinates issue.
Newport is another special case, along with sunffb - no useful
off-screen memory but has support for alpha blending. EXA, by default,
will only try to accelerate alpha blending operations within video
memory. I'm currently working on tricking EXA into using the hardware
for all supported alpha blending ops that have video memory as target,
no matter where the source or mask are.
Pnozz should be easy - the graphics chip is a Weitek P9100 behind an
SBus-PCI bridge, IIRC it supports offsets and variable pitch. Kinda
obscure though ( used in the SPARCbook 3 GX and TX ), so not a high
priority.
Finally, the AG10E driver. It's a GLint 300SX ( and a bunch of other
chips ) behind another SBus-PCI bridge. It uses part of the general
glint driver, as far as I know there is no EXA support in that driver
for that chip yet. Also kinda obscure, will do it when I get there.

> > FWIW, XAA was removed from xorg-server 1.13.  they're upto 1.17.2
> > now.

> How do you folks deal with it in NetBSD? Just ship and old Xorg, or
> have XAA ported to newer one?

I'm adding EXA support to the more common chips whose drivers still
lack it. By far the most common one would be sunffb, aka Sun
Creator/Creator3D/Elite3D, which just got basic EXA support ( as in, no
xrender acceleration yet for reasons described above ), and suncg6, aka
Lego, GX, XGX, TurboGX, *GXplus etc.

Some of the drivers I wrote in the last few years ( or added
acceleration to ) already got EXA support and nothing else. Examples
are suntcx ( think tcx and S24 ) - basic blitter stuff, doesn't have
anything to help with xrender, and suncg14, which grew acceleration
support via SX when someone left a bunch of documentation on my
doorstep. This one is special, the accelerator is a vector processor
built into the memory controller, so it needs kernel support. The good
thing about that - no concept of coordinates and it's more or less
freely programmable so no problems with EXA and I added support for the
more common xrender operations as well. Not very fast, but then again
it was designed 25+ years ago.

have fun
Michael