Messages in this thread |  | | Date | Wed, 5 Jun 1996 17:31:53 -0700 (PDT) | From | "Jon M. Taylor" <> | Subject | Re: SVGA kernel chipset drivers. |
| |
On Tue, 4 Jun 1996, Linus Torvalds wrote:
> > > On Mon, 3 Jun 1996, Brad Pepers wrote: > > > > Why are graphics cards singled out as the only PC hardware that cannot > > be in the kernel? > > > > Don't get me wrong - I don't want to see massive drivers included in the > > kernel. But some basic support from the kernel for mode switching and > > querying of card information along with a user land program that provides > > a standard API that uses this information sounds like a good idea to me. > > There are a few things that singles out graphics as a special case: > > - extreme performance requirements. It's one of the few devices (the > others being mainly disk drivers and high-speed networking) where > every cycle counts.
Well, we have plenty of disk stuff in the kernel already...
> - no good generic interface.
A linear framebuffer and a set of IOCTLs? How complicated is that? If you take away hardware acceleration, all you really have left is a bunch of pixels, and the accelerations are all atomic within the hardware - all the driver needs to do is to be able to take the IOCTL and either tell the hardware to go do it or be able to tell the userland stuff that this operation can't be done directly.
There will probably be some sort of bitmap to store this info for each driver, so the userland libraries can tell right away what can be done in hardware and what can't. This sort of design would be flexible as hell, because just about any type of graphics operation can be atomicized this way. Whatever wierd, tweak types of acceleration get put into video cards in the future can be IOCTLized and supported.
Everything else, as far as the kernel-level stuff is concerned, is just video memory. It may need bank-switching to patch together a linear framebuffer out of banks, but that is part of life in the PC video card world (and is going away, thankfully). Everyone else has to do it too. This stuff really *isn't* that complex. The problem is that each card has its own way of doing things, which have to be taken into account by the drivers.
>This is where it differs from disks and > networking and most of the rest. A disk is a disk is a disk - they > look more-or-less the same to the end user, and you can virtualize > them behind a driver pretty well.
The end user only sees the filesystem, usually. As far as the disk itself, you have block mode switching, cyl/trk/sec addressing, controller configuration (which *do* have a bunch of peculiarities and *do* have individual kernel drivers), etc. Video stuff is a LOT less complex.
> However, trying to virtualize a > graphics card is not really possible in a reasonably small API. You > end up losing "special features" that can be critical (like bitmap > caching in video memory etc - stuff like that is very hard to virtualize > without exposing all the details you want to hide in the first place)
In your example above, the userland code would probably need to ask the kernel driver for a chunk of video memory for the bitmap cache, in addition to whatever memory would be needed for the visible/virtual display memory. Manual massaging of the video cache would then be possible, as well as hardware blitting to/from it.
> The problem is really that while you can say that "yes, we can virtualize > bitmap caching" etc, the stuff just keeps coming and coming, and in the > end you have a list of hundreds of things that the driver needs to know > about, and you have a rather complex API to it all, including a "get > features" request that tells the user exactly which things are available.
On what grounds do you assume this to be true? I see no evidence of it.
> In contrast, look at a disk driver: you want to get very good performance > from that too, but the interface is rather simple. You read a block, > write a block, and have a few special ioctl's to do special cases that > are conceptually very simple ("ask geometry", "lock door" etc).
Same with a video driver. You read a pixel, write a pixel, and have special IOCTLs for the hardware accelerations thatare conceptually very simple (bitblits, linedrawing, clipping, etc).
> And the > special cases aren't really performance critical, so you don't have to > worry overmuch about them.
In our case, the special cases are done in hardware, so we hand them off and from then on it's not a driver issue anymore. Simple as anything.
> The closest thing to a video driver in the current kernel is probably the > sound driver: that's a reasonably complex beast with a reasonably complex > interface.
The interface is A LOT more complex than the GGI interface. You have FM, MIDI, wavetables, stereo vs. mono, sound file formats issues, etc.
> However, the performance constraints are _much_ less of an issue > (orders of magnitude less data to shuffle around), and while games etc want > to do strange things, the strange things are usually reasonably well-defined > ("play this snippet of sound in the background while I do other things").
The "strange things" are quite well defined in our case as well. They are the graphics primitives and messing with your video buffer mem directly.
Jon Taylor = <taylorj@gaia.ecs.csus.edu> | <http://gaia.ecs.csus.edu/~taylorj> ------------------------------------------------------------------------------ "Everything in excess! To enjoy the flavor of life, take big bites. Moderation is for monks." - Lazarus Long
|  |