Messages in this thread |  | | Date | Sat, 1 Jun 1996 21:27:38 -0700 (PDT) | From | "Jon M. Taylor" <> | Subject | Re: SVGA kernel chipset drivers. |
| |
On Sat, 1 Jun 1996, Tom May wrote:
> I've spliced together a few messages in which Linus writes: > > First, the executive summary: > > >The ONLY solution is X, and anything else is just noise. They should be > >supported, but not at the cost of extra complexity in the kernel. > > Truly. I have worked on projects where 70% of the coding and > debugging and testing effort required to support a board under certain > OSs was wasted on the goddamn text-graphics-hotkey-dos-compatibilty-lcd- > panel-virtual-device-etc bullshit! Go into graphics and stay there or > don't go in at all.
Jesus, this isn't THAT big of a hassle! You are exaggerating.
> And if you have to read the state of the hardware back, > in anything other than a diagnostic, that is a bad software system design.
Look there are things wrong now, and kernel video would be a AWFULLY convenient way to deal with a lot of them in one fell swoop. Sure, it isn't going to be a walk in the park, but it'll be worth it and it IS doable.
> Now the rest of it: > > >Could we PLEASE stop this framebuffer nonsense? > > > >It's not going to happen. There are LOTS of cards that don't even _have_ > >framebuffers (and they are usually the really high-end ones, the ones > >that people will want support for in the future). > > I feel compelled to reply that I have made my living as a display > driver programmer for the past six or seven years and have worked on a > lot of high-end PC video cards as a 3rd-party contractor.
Should you ever come around to our way of thinking, the GGI project could really use someone like you.
> All the > high-end cards that I have worked on have frame buffers. Why? > Because you can only provide hardware acceleration for a certain > subset of common and important operations. So when your Windows > driver, NT driver, OS/2 driver, or X server (I've done all of these > and more) wants to do something weird (e.g., arbitrary-size stipple on > X, maskblt on NT, background transparency on OS/2), the easiest and > fastest way to do it is with direct frame buffer access instead of > trying to break a complex operation into things the card can do in > hardware -- which may be impossible, in which case you're stuck with > bltting a rectangle from frame buffer to memory, drawing to it, and > bltting it back.
At the very least, it is common enough that it isn't worth worrying about overmuch.
> >Finally, IO port acccess is not at all less critical. As far as I know, > >there are _no_ PC graphics cards that you can really program without > >using IO ports. Stuff like colourmaps etc are almost invariably done with > >IO port access on PC's. > > I/O port access is not critical because only suboptimal cards use I/O > ports anyway. The best way to make I/O ports faster is not to use > them. Since at least the early 90s, good cards use memory mapping for > everything except maybe some init functions.
[Snip]
> Anybody using a card that is I/O mapped should not complain about the > performance -- they are using intrinsically suboptimal hardware and > there is no reason to make hacks for it when they could be using good > hardware and leave programmers to work on projects which advance the > state of the art instead of holding it back.
On the other hand, one of the strong points of Linux is that is supports even old, slow, brain-damaged hardware and pushes it as far as it can go.
> >Trust me, we're not talking VGA here. We're talking _high_ end graphics, > >that don't have frame-buffers because that interferes with the normal > >mode of operations (painting the screen) for no real good reason (the > >actual drawing is then done using screen commands and/or DMA to the card > >to fill a area with data). > > Are you thinking of the XGA? That's the only card I can think of that > uses DMA. There may have been others, I don't read the specs for > every chip ever made, just the ones I haved worked on which is pretty > much a who's-who list, and one or two I have evaluated. Anyway, IBM > did all kinds of weird stuff in HW to deal with physical to virtual > mapping and it ended up not working anyway. > > >> That is good enough because the virtual memory hardware can be > >> used to make it appear to be linear. The process does not need > >> port IO to move the window. > > > >Wrong. You _can_ do it that way, but if you do that then you're shooting > >yourself in the foot. Mainly because it's horrible for performance. > > It's perfectly usuable. I kind of stopped doing display drivers > because things got to the point where I thought things were fast > enough. Nevermind that the marketing guys are still pressuring > engineers to make things go faster -- the benchmark numbers are now > +infinity as far as I care, meaning that once things are fast enough, > you don't notice if they are faster. I've done some god-awful slow > drivers that do everything in software a couple times over (I had my > reasons) and they are still totally usable. Memory-mapping tricks + > software drawing are certainly fast enough and require only a very > small amount of chip-dependent code once the OS or whatever is set up > for it. But I don't endorse such a thing because it's just a hack for > bad hardware.
Better that than have that hardware be completely unusable, no?
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
|  |