Subject: re: Creator3D device driver running Xsun24 on Ultra 1E
To: Greywolf <greywolf@starwolf.com>
From: Charles Carvalho <carvalho@employees.org>
List: port-sparc64
Date: 08/20/2002 16:41:55
At 12:09 PM -0700 8/20/02, Greywolf wrote:
>On Tue, 20 Aug 2002, matthew green wrote:
>
>#    Considering, at near future, that accelearated XFree would run on
>#    NetBSD/sparc64, is this work meaningful ?
>#
>#
># i think that given there is no time frame or really anyone even
># actually doing the work wrt xf86, this work is extremely useful.
>
>Question:
>
>is the tcx stupid (read: non-accelerable), or is our/XFree's/X11's
>implementation less than optimal?

The current implementation (in 1.6 and current) is less than optimal; the
S24, at least, appears to have smarts we're not using, although I don't know
how much improvement we'd see if we were able to take advantage of 
the extra hardware.  The onboard framebuffer in the SS4 also uses the 
tcx driver; it
supports a maximum of 8 bits/pixel, but is apparently similar to the S24
card for the SS5 otherwise.  Both are currently supported by the tcx driver
as dumb framebuffers.

Part of the problem is that documentation is sparse; we have register
definitions, but don't know how to use them.  Another part of the problem
is that the X server isn't smart enough to use the parts we do know about;
the S24 provides both an 8-bit-deep framebuffer and a 32-bit-deep (24 usable)
framebuffer at different addresses, and in theory, the X server could use
the 8-bit-deep version for any windows that didn't need the greater depth,
for a potential memory savings (for backing store, etc) and 
performance improvement from reducing the memory accesses by a factor 
of four; but I
don't know the innards of the X server well enough to guess what it would
take to actually implement that, let alone undertake it.  The newer X tree
(xsrc/xfree/xc) didn't appear to have any additional acceleration support
for tcx, the last time I checked.

Charles

>
>				--*greywolf;
>--
>NetBSD:  Got source?