lkml.org 
[lkml]   [1996]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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




\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.128 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site