Subject: Re: radeon driver design (was Re: generic virtual consoles)
To: Kurt J. Lidl <>
From: Michael Lorenz <>
List: tech-kern
Date: 12/29/2005 13:08:26
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable


> All this arguing about "just gimme a flat frame buffer and I'll
> twiddle the bits myself" fly in the face of modern high-performance
> graphics hardware.  While it certainly was fashionable to whack
> directly on framebuffers in 1988, it is just not a sane way of
> extracting good performance.  Anytime one can exploit the a graphics
> accelerator that has more-or-less direct access to the framebuffer
> memory, it is almost certainly going to be a performance win.  The
> problem arises in a cross-platform system like NetBSD that wants
> to support the full range of hardware that crosses multiple
> generational boundaries -- older hardware may just be a a dumb
> framebuffer (e.g. cg3) and requires a full software implementation
> to do anything.  Newer hardware (e.g. cg6) might support some
> accelation features (line drawing, polygon fill, etc) and that
> helps a lot.  Semi-modern hardware (e.g. FFB) can do all that and
> much, much more.

Actually, our cg6, machfb and pnozz drivers don't access any video
memory anymore, at least when used with wscons. FFB is different, it
doesn't use the colour expansion hardware (yet), probably for lack of
documentation but the XFree driver should be good enough to figure it
out. I guess nobody bothered because - thanks to UPA - there's plenty of
bandwidth and drawing characters by hand isn't really slow.
Maybe I'll add it at some point, I'll have to hack it anyway.

> NetBSD's various hardware drivers have a graphics model that is
> far, far below the functionality of even Quickdraw.

Yes, it's intended for terminal emulation, nothing else.

have fun

Content-Type: application/pgp-signature

Version: GnuPG v1.4.0 (NetBSD)