Re: CG14 in 8-bit color

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

Hello,

On Sun, 7 Nov 2021 08:31:15 +0100
Malte Dehling <mdehling%gmail.com@localhost> wrote:

> admittedly it doesn't seem that useful, but I run my cg14 in 8-bit color
> to allow for higher resolutions (1920x1200).  "Out of the box" the Xorg
> driver included with NetBSD 9.2 works only in 24-bit color; with a few
> changes to xsrc/external/mit/xf86-video-suncg14/dist/src/cg14_driver.c
> it works in either 8-bit or 24-bit mode.  I've attached a diff.  Simply
> set DefaultDepth in xorg.conf or use the -depth command line parameter.
> 
> Part of the change is to trust the OBP on the VSIMM size instead of
> assuming an 8MB VSIMM for higher resolutions.  I'm not sure if that
> breaks anything?  (Older OBP versions?  The SS10SX?)

As promised I finally sat down to make suncg14 work in 8bit. Please cvs
update and report success or failure, the code should work on 9.x
What I committed is more or less what you did, except explicitly
requesting 8 bit mode from the kernel instead of assuming that's what
we get.

> I also have no clue how to fix the acceleration code.  Currently if you
> enable the Accel option, you will see vertical bars on your screen
> (looks like 3 black pixels followed by 1 pixel of the actual image.)

That's a weirdness in SX's STBS ( STore Bytes from Scalar )
instruction, if you store a bunch of bytes from a scalar you need to
repeat the byte-to-be-stored in all four sub-bytes of the source
register. Apparently that saved the designers a few gates on the chip,
and that was a bug in the original code.

I fixed a handful pixels-are-32bit assumptions in the accel code and
optimized the Solid8() method to use 32bit vector accesses whenever
possible, Copy8() is still working on bytes but I'll fix that next.
This will probably be a few more commits since moving 8bit pixels in
32bit registers is a bit of a pain, and in order to be fast you need to
do 32bit accesses, which is annoying when source and destination aren't
on the same 32bit alignment. If they are ( for example, when scrolling
) we can use straight 32bit ops for most of it, which simplifies things
a great deal.

> With ShadowFB enabled I find the speed acceptable, but of course
> acceleration would be preferable.

I didn't find much of a difference when using a shadow fb, which isn't
surprising since VRAM is accessed through the same memory controller as
regular RAM, so caching is the only difference.

have fun
Michael