Subject: Re: radeon driver design (was Re: generic virtual consoles)
To: None <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 12/22/2005 07:42:53
Thor Lancelot Simon wrote:
>On Thu, Dec 22, 2005 at 06:54:30AM -0500, Michael Lorenz wrote:
>>>The end result will *not* be compatible with any current X11 driver.
>>>However, one could write a driver and probably even make it "safe" to
>>This would be a nice addition to XFree's wsfb driver. And handling
>>acceleration in kernel would allow to queue blitter commands and use
>>interrupts to run them asynchronously. Maybe there should be a simple
>>packet format describing them ( like a command, plane mask, ROP,
>>coordinates, other data, so it would easily be usable for X ) and an
>>ioctl that simply takes a pointer to a buffer full of them, enqueues
>>them and maybe sets completion flags.
>This sounds eerily like the interface DEC used in Ultrix, sometime
>in the late 1980s. The pmax port implements the kernel side of that
>interface, for some graphics hardware at least -- it might be worth
>I think it's also written up in at least one paper.
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.
Apparently this graphics hardware is not directly mapable to the CPU, so
they have to use a command packet type of interface.
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.
Of course I'd like this all to be hardware/driver agnostic, and I will
aim for that so that it can be used with other framebuffers.
I'm also a little reassured that no one has found serious flaws with my
design, only refinements. It sounds like this is the way for me to proceed.
Garrett D'Amore http://www.tadpolecomputer.com/
Sr. Staff Engineer Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc. Phone: (951) 325-2134