Subject: Re: radeon driver design (was Re: generic virtual consoles)
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Michael Lorenz <macallan@netbsd.org>
List: tech-kern
Date: 12/22/2005 06:54:30
--Signature_Thu__22_Dec_2005_06_54_30_-0500_wl+ofyRK2=Twchq5
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

> The radeon framebuffer driver that I'm working on will be able to
> benefit from this (vons), I think.  However, I wanted to send out a
> description of what I'm doing, so folks can critique it.

> Third, I want the ability to run these virtual screens at arbitrary
> logical and physical resolutions, where they may not be the same.=20

Hmm, then you'll need a callback in show_screen() ( or hook it instead
of just overwriting ) to notify your driver when a screen became visible
before redrawing it. And a flag indicating wether a screen needs to be
redrawn when becoming visible. I'll add these things, others may need
them as well.

> Fourth, I want to render directly from application layer into
> framebuffer memory, for performance.

Easy to do, every screen has its own struct rasops_info, there's
absolutely no reason why they should point at the same VRAM area ( or at
a VRAM area at all ) or have the same dimensions, depth and so on.

> * alloc_screen() carves up framebuffer memory on demand.  This means
> the number of virtual consoles is limited by how much framebuffer
> memory you have (and the resolution of those consoles).  I'm only
> planning on supporting 32bpp for now.

Sure, just have it return ENOMEM when you run out of VRAM. I'll check if
my code handles that in a halfway sane way.

> * the show_screen (or is it switch_screen?) routine works simply by
> changing the CRTC registers to point to the right location in
> framebuffer memory (plus work for resolution changes and panning)

Yeah, callback and flag for redrawing.

> * if the mode is not text mode, then I will support additional device
> specific ioctls to set physical display resolution, panning offsets,
> etc.
>=20
> * I will also provide ioctls for 2D acceleration (draw a line, etc.)

Just keep them generic enough so I can support them on mach64, cgsix and
so on. Maybe have a bunch of flags indicating hardware capabilities.

> The end result will *not* be compatible with any current X11 driver.=20
> However, one could write a driver and probably even make it "safe" to
> run unprivileged.

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.

> My first implementation of this will not include much acceleration,
> other than basic line, fill, blit, and maybe some stuff like YUV
> decode.  3D acceleration will not be included in my code.

Well, wscons only uses screen-to-screen blits, rectangle fills and
probably mono-to-colour expansion to draw characters ( pnozz, machfb and
cgsix do that, most others use only the first two as far as I know )
Adding support for a hardware cursor would be useful ( wsfb from
-current xsrc would use it for instance )

> I'd like the architecture to be good enough that folks would be happy
> to have other drivers built using the same ioctls.  (Imagine e.g. a
> silicon motion driver, or drivers for embedded LCD panels.)

This would certainly make a few things easier. Writing an XFree driver
isn't really hard but something like this would definitely reduce
duplicate work ( like writing acceleration code once for wsdisplay, then
again for XFree and then take care that they don't stomp over each other
)
The XFree folks won't like this approach and there will be a few who
complain about graphics-in-kernel but the code is already there and has
to be there in quite a few cases, this would only add a way to use it
from userland.

just two more cents
Michael

--Signature_Thu__22_Dec_2005_06_54_30_-0500_wl+ofyRK2=Twchq5
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)

iQEVAwUBQ6qT+spnzkX8Yg2nAQJeIAf/RYgOCBV8rTu/4kj76jCd0mbIhxofwzIY
rRnmwFczGGNaYN2QALLKtyuDsEcncVuEoTH5ANkv9PxpylP4mtV3RPKXIHh1vl4Y
EEoIJnLvqm1TbSoSopHfDBXA2eaMPDChaJp56zYtgDnlvUT/RoTOSE01Y0jYFWnC
3FsYXZ/zBaYUqC4ajtH/YeuuM1cIPUiLO3s1/LVhkJ3tQ8ab5/fFp7zRgaToUr+9
IhHc6yoK4KWVxwTOYvK4U8c5SJpUEvhGb8OQ15+459NXNs2Y4RBycu0B6JPq2UlR
DtIp+gYkbk6BYzSe+7FzRHImbNaI4EGnTe0z/UsVFutH5RKDcZctDg==
=Rek1
-----END PGP SIGNATURE-----

--Signature_Thu__22_Dec_2005_06_54_30_-0500_wl+ofyRK2=Twchq5--