Subject: Re: radeon driver design (was Re: generic virtual consoles)
To: Garrett D'Amore <>
From: Michael Lorenz <>
List: tech-kern
Date: 12/22/2005 11:11:57
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable


> I can't find the paper, but it looks like this is the PXG graphics
> architecture, and there is stuff for this in sys/arch/pmax/dev/px.c.=20
> Apparently this graphics hardware is not directly mapable to the CPU,
> so they have to use a command packet type of interface.

well, some drivers don't access framebuffer memory directly ;)

> I'm not proposing quite this level of removal.  I still want to
> provide for directly mapped framebuffers, but I also want allow for
> hardware acceleration of some 2D operations.

The only reason I suggested something packet-oriented is the ability to
pass more than one command, queue them and run them asynchronously, at
least on hardware that provides command completion or pipeline low water
interrupts. Obviously we'd also need something to signal when it's safe
to access framebuffer memory. ( I just don't like the thought of the CPU
actively waiting for the blitter to do its work when it could do
something useful instead. On a Radeon that's probably not too
relevant but on older hardware it may be different. )

Something else - if at all possible please allow your driver to work as
a semi-dumb wsdisplay that could be used by XFree and its radeon driver,
for instance on sparc64 and macppc where we can't (or don't want to) use
vga. For both we have dumb OpenFirmware framebuffer drivers but being
able to use acceleration for the console would be nice. 'Semi-dumb' as
in no VRAM tricks, use whatever video mode the firmware set up but use
the blitter for scrolling, rectangle filling, probably character

have fun

Content-Type: application/pgp-signature

Version: GnuPG v1.4.0 (NetBSD)