Well, apparently, the email I wrote was too long and is being held up in the server, and we can't get to it, so I've split the email. Here's the first half.
On 8/19/06, Richard Cooper <[EMAIL PROTECTED]> wrote:
So what have we got here? We don't seem to actually have OGD1 cards. We don't seem to have a clear understanding of what we're even going to do.
You start off very hostile, and that's going to be a barrier for some people reading what you wrote. But give us some credit here, and we'll give you plenty. I've read what you've written, and you make some _incredibly_ compelling arguments. I don't agree with _everything_ you say, but I agree with a great deal of it, and I applaud you for having the courage to criticize some of the things that need criticism. I think most of the ideas you present are things that really SHOULD be done, regardless of the whole closed vs. open debate. Mostly what you're talking about is good design, and that's something we appreciate around here. Lighten up, and join us. Once we start to respect each other's differences, we'll get along well... you'll like us, and we'll like you. And you won't have to "give up," because I think you're talking to some people who appreciate very much your point of view and want to work with you to realize it. You're someone who is frustrated with the status quo and wants revolution. The bourgeois of old-school Linux and X11 drivers have stuck to their out-dated and cruel ways for much too long, and you want the wrongs to be righted. You've just joined a mailing list full of people who want revolution. Maybe for different areas, but we nevertheless understand your drive and appreciate it. A lot of what you say hits me where I live. I love elegant design, and much of what you describe is nothing but. On this list, I play the role of the pragmatist, making sure that this feature or that feature is fully justified, etc. But the rest of the time, I'm a philosopher (or at least, I think I am). You're thinking outside of the box, and you have no idea how important that is to me. Don't misjudge the OGP. We don't think we're going to solve all problems. As with any open source project, we're here to scratch an itch. We're doing this because it's fun and interesting. We like designing graphics cards... and hardware in general. Some people like golf. Some people like hacking OS kernels. Others like designing chips. What's wrong with that? I could address your statements about us not knowing our direction, but the rest of your email is MUCH more interesting. Suffice it to say that we feel that we have a solid direction, and we know where we're going. Some of what we want to do is completely orthogonal to what you want to do. We can work together on this, although many of us here are interested in hardware design for its own sake.
We seem to be assuming that graphics in Linux suck because of lack of hardware vendor support, and that if we simply create our own video card, then we'll have support and everything will magically become better.
Who is assuming that? No. We're assuming that graphics for Free Software is a very politically complex issue, and that we are in for a lot of hard work ahead of us. We like the idea of having Free Software drivers for our graphics cards. Some people demand it. But many of us here want to learn to design our own hardware... because that's what interests us. I'm a professional graphics chip designer. In my opinion, I don't get to spend enough time designing chips. I want to do it more. This project is a way for me to fix that, and I'm having a ball, and I'm feeling appropriately challenged. It's humbling and rewarding to work on this project and work with the incredible people involved.
So we're planning ahead, and asking for people to write the code now and then we'll get around to creating the actual video card when we have time.
No. They can't write code for hardware that doesn't exist yet.
Basically, I guess we're looking to do as much work as possible before figuring out that are base assumptions were wrong. The problem isn't lack of vendor support, the problem is that everyone on the open-source side of things is to stupid to see what they're doing wrong. Linux graphics could be fixed right now, without a new video card, but no one cares to do it.
Inertia is a bitch, ain't it? Some of the resistance you run into comes from different values. Some of it comes from laziness. Some of it comes from people who just don't think the same way you do. After reading the rest of your argument, I don't believe open source vs. closed source is a central issue here. The central issue is bad design vs. good design and is completely orthogonal to whether or not we can see the source code. On the other hand, visible source code is part of what makes Linux an amazing things. As you start hiding bits, you start taking away its ability to grow. The very fact that it's open source is what makes it possible for people with ideas like yours to make fundamental changes to the way we do things. And I am convinced that we need fundamental changes to the way we do graphics. Perhaps Linux graphics can be fixed without a new video card. Fine. Keep in mind that that doesn't make it wrong for us who like hardware design to decide to design some new hardware. That's what we want to do and fits into the "scratch one's itch" philosophy of open source as well as anything else.
Now I realize that what I'm saying isn't what anyone wants to hear, so rest assured that I'll ignore most people's replies because I've delt with Linux graphics as much as I care to.
I'm rather amazed at how polite everyone on the OGML has been. I've run other mailing lists in the past that were thrown into turmoil by a handful of jerks who wanted to ruin things for everyone. People on OGML are intelligent and truly interested in working with or designing open hardware. They're also open-minded and willing to consider other people's points of view. If you want to make an argument that will be listened to, you've come to the right place. I cannot emphasize enough how important I think some of your ideas are.... just to give you a sense of how receptive some of us here will be.
I've given up.
No, you haven't. If you had, you wouldn't be posting here. Obviously, you think you have something important to say. I think so too. I'm glad that you didn't give up. More than anything, I would like to encourage you to become a voice for change in the way things are done. Not everyone will agree with all of your philosophy, but the fact that Linux graphics architecure needs to be completely redone is a no-brainer.
However, I do know what needs to be done, and so I figure the least I can do is explain it so that, assuming everyone here is more interested in improving Linux graphics than they are in the happy idea of creating an open graphics card, they'll at least know what needs to be done. Just don't expect any programming help from me. I've programmed this nonsense for the last eight years and I've had all I can take.
Not everyone here can program or wants to. There are many non-technical people who have contributed in a variety of ways that have had a lasting impact on our philosophy. The key factor in our "culture" here that makes OGML work is that we engage in DIALOGUE. Many of our list members put an unusual amount of effort into being very clear when they debate issues, and this has generally minimized the fuss that often comes from people talking past each other. Another thing I've seen a lack of here is nit-picks. On other mailing lists, I would sometimes see people argue with the form of someone's arguement, completely missing the point that they were trying to make. For instance, someone would make a brilliant argument but make a spelling error. The responder would then ignore the whole argument and focus exclusively on the spelling error. Kinda like slashdot. That's never happened on OGML. I hope it never does.
So anyway, if you want to fix graphics in Linux, here's what you need to do: 1. Remove the VT-100 emulator from the kernel, as well as the code which does console switching, and even the VESA framebuffer code. Remove every lame excuse the kernel has for a graphics driver as it's all simply done the wrong way and any attempt to build a new system based on the old system will result in a new system that sucks just like the old system.
I didn't understand this until I read what you'd written below. I don't think we want to remove it from the kernel completely. But I do agree that it should behave in many ways like a user process. The main problem is that we need to have it running very early in boot. This is also one of those things that is so core and fundamental that I really don't want to remove it from the kernel and make it rely on a userspace app. But see what I say later about X11 stepping into its role when X11 is running.
2. Create an easy, standardized, and well documented kernel video driver interface that allows card manufacturers to easily create a video driver for Linux. The manufacturers don't have to create the drivers now or even ever, but the interface needs to exist. This would be a simple interface that allows someone to copy a file from their video card's CD-ROM, tell Linux to load it, and then it's their video driver. It would not require the driver to be open source, it would not require it to link into the kernel, it would have it's own driver API where the kernel simply tells it things like "what modes are available" and it says "these modes are available" and the kernel says "I would like to switch to this mode now" and the driver code simply does the necessary hardware access and then reports back "that mode is now set" and then the kernel asks "so where is the video memory located at" and the driver says "it's right over there..."
Lots of people have made this suggestion before. I'm one of them. The only problem is that we'd have to define some sort of pcode language for the drivers to be written in. Otherwise, you won't be able to use the same drivers for x86, x86-64, PowerPC, Sparc, etc. Architecture-specific binaries are out of the question, because they're not portable. And if anything performance-critical has to be in the driver (which a lot of rendering code is), then the pcode interpreter is likely to be a major performance bottleneck. JIT compilers are popular, but the kernel is the wrong place to put one. Perhaps a pcode-to-native compiler could be part of the installation software. This way, driver writers can obfuscate their driver functionality (no source code), but can still make their drivers portable and work with unlimited kernel versions, as well as perform reasonably well. Is this what you had in mind? Of course, part of the problem here is that we're taking away from Linux one of the things that makes it great: Open development. With the pcode solution, we could solve a lot of the crash and general quality problems of closed-source drivers by making the pcode virtually run in a sandbox. But there's no room for Free Software developers to improve the drivers, taking away part of the biggest benefit of Free Software. Why cripple that philosophy? Before long, every sort of driver will have an API defined for it, relegating the open source parts of the kernel to only rudimentary pieces. After a while, so little of the kernel will be open source that there's little point in it being open source, and the development stagnates. This defeats the whole idea behind Free Software and giving one full control over one's computer. You won't be able to look under the hood anymore, making Linux no better than Windows. So why not just use Windows?
This interface has to be easy because the cost of a video card manufacturer creating a driver has to be less than the revenue they will recieve from increased sales, and a complicated interface isn't going to make that possible. It has to be standardized because tech support is also a large expense for manufacturers, and they can't claim "this card supports Linux" on the box and then refuse to accept tech support calls about it. If the interface isn't stable, if it is going to change with every new release of the kernel, then that would be a huge expense to anyone who cares to create a driver.
The argument has often been made that having changable kernel interfaces allows for innovation that would be impossible if we were locked down to something unchangable. What if someone wanted to innovate in an interesting way, but couldn't without changing the API? That's happened lots before. Your suggestion would most certainly impede innovation. Innovation is what makes Linux great. Do you seriously want to take away from Linux what makes it great? What I think we need are standardized interfaces that are scalable, in the sense that they can grow and adapt to innovation without requiring excessive work to adapt to. Some of those innovations may require deep changes in drivers, unfortunately. With open source drivers, those making the changes to the framework can also fix up the drivers at the same time.
It also has to be well documented because video card manufacturers don't want to support Linux for idealogical reasons and so while the average Linux hacker has no problem with spending weeks digging up information on an undocumented or poorly documented interface, a video card manufacturer who is only in it for the money will want the information to be easy to find, easy to understand and comprehensive or else they simply won't bother because it will cost them more to create the driver than the additional profits they anticipate it will create. There shouldn't be any problem with the information being up-to-date because, like I said, the interface has to be standard meaning that it doesn't change over time.
My pcode suggestion, I think, would take is one step further beyond just a stable API. It would provide a stable and secure environment for drivers to run in. The driver compiler could compile pcode to native with various levels of debugging (array bounds checking or not, etc.). This would really help in development, because enabling full debugging would find all sorts of flaws. Also, things that often require complex function calls, like mapping your drawing engine memory space so you can send it commands, are built into the pcode language and made dead simple. I still think the ability to change over time is important. But perhaps the pcode idea would allow that by extending the command set of the pcode without breaking older commands. After a while, the compiler would become very bloated, supporting lots of relatively obsolete opcodes, but that wouldn't necessarily be a problem after it is compiles to native. It would take a longer period of time before the kernel interfaces started to get really krufty due to legacy stuff having to stick around to support old drivers.
This is one of the biggest failings of Linux graphics. In the days of DOS, some applications such as AutoCAD had a driver included with every video card, but less important applications such as Microsoft Windows weren't so lucky and had to either write their own drivers or use the BIOS. Linux seems to think it is simply going to jump in the game, make no effort to make creating a video driver easy, and all of the hardware vendors are simply supposed to bend over backwards to support it.
Actually, I think Linux supporters don't expect much help at all from hardware vendors. They want hardware vendors to provide documentation so kernel hackers can write the drivers for free. In that case, who cares how easy or hard it is to write a driver? The manufacturer doesn't have to do it! On the other hand, I think it would be very good for kernel hackers to make their OWN lives easier by developing an intelligent infrastructure.
What no one wants to acknowledge about Windows is that it got to where it is by making things easier for people. Windows wanted video drivers, but I don't think they demanded that anyone create them because at one time Windows wasn't big enough to demand such things. Instead, Windows just made things easy. DOS developers switched to writing Windows games because Windows supplied easy memory access and easy graphics access. Office application developers switched to Windows because Windows supplied easy printer access and easy network access. Linux on the other hand doesn't want to make anything easy, it simply wants to scream "I'm an operating system too!" and expect businesses to give it what it wants.
Actually, I completely agree with you on this point. Of course, I have worked on Windows drivers before, and they're no picnic. But the fact that there are standardized interfaces helped immensely.
Hardware manufacturers aren't stupid. Businesses become big by being smart. They create a formula to calcuate wether or not it is a good idea to support Linux, which involves the potential increase in sales revenue, and the costs of driver development, driver maintainence, and technical support.
The only cost for supporting Linux, though, is releasing docs. And any vendor worth their weight in salt has good internal documention on their hardware. Actually, many of them don't, but that's their failing.
Linux simply doesn't offer much for increased sales revenue, its lack of a standard API for video drivers to utilize means that driver development costs are high, and the general poor design of the entire system means that making the driver work for everyone is no easy task, which means it will fail for many people and the technical support costs will be high. If Linux wants video card drivers, it needs to first of all provide an API for video card drivers and then make things such that the formula solves to a positive dollar amount.
BTW, where do you want this API to be? I've been assuming the kernel. Should it be somewhere else? If not in the kernel, how does the kernel communicate with the display? Just curious exactly what you have in mind here. [Later edit: Never mind. See my suggestions below.] BTW, as far as APIs go, XAA is quite nice, and I've heard that DRI is very good too. They're both very well standardized. But like anything, they can be improved. That's the problem, of course. You can't develop an API that's perfect.
In particular, an open video card isn't going to fix everything. It would allow open source developers to create video drivers, but look at the quality of our current VGA driver and our current VESA driver? What's that? You don't know what drivers I'm talking about? Yes, I don't know what I'm talking about either.
Oh, trust me. When it comes time to write Linux drivers for this thing, I'm going to have some complaints to make. There are things that I think are fundamental to getting good throughput from a graphics chip that I think may be difficult or impossible to support given the existing frameworks. Those frameworks will have to change. And that brings us to back to the problem of unchangable APIs. What if we forgot something? What do we do? Here's an example: Many drawing engines have an "I am completely done" interrupt. DMA hardware and software use that to set up the transfer for the next block of commands. In the mean time, the GPU is IDLE. Just sitting there wasting time. What if we wanted an interrupt that said "I'm nearly done; go ahead and set me up for some more commands"? The only drawing engine I know of that does this is the one I designed for Tech Source. If you were to base your API around existing GPU designs, you would be forever unable to take advantage of this unusual feature, and you'd lose out on a potentially significant performance boost.
The kernel has no video drivers, instead it has about 1/4 of a VGA driver and 1/17 of a VESA driver. SVGAlib is a little more complete, it has 2/3 of a VESA driver, but no VGA driver for reasons that are a complete mystery to me. X11 has a VGA driver, at least as far as graphics modes go, but it supplies a similar 2/3 of a VESA driver and the occasional support for an odd video card here and there.
Is your complaint that there are multiple pieces of drivers floating around in numerous different locations? Are you complaining that they totally lack any kind of centrality or unity? I completely agree. That does suck.
What I'm saying is that whole mess shouldn't exist. X11 and SVGAlib shouldn't have drivers at all, they should use the same graphics API everything else has available, which ultimately ends in the kernel having a video driver API.
Well, there would have to be two APIs in the framework. One is the API for drivers themselves (D). The other is the API for applications (A). There would be an A in the kernel, and one available to userspace apps. The same A interface, but the internals to the bindings would be different. It would also be good to have a D in the kernel, and one in userspace. For security reasons, some of the things D would do in user space would actually make calls to the kernel and use D in the kernel. But that would be completely hidden from the driver developer who writes for one API (D) or the application writer who writes for one API (A). Nobody cares if their driver gets loaded fully or partially into different places. The driver only has to be written once!
There would be a default VGA driver and a VESA driver, and anyone who has specs on a video card can write a driver, and in particular the easy API would make it easy for hardware manufacturers to supply their own drivers.
Ok, so what you're saying is that all the stuff necessary to support a text console (graphical or not) would be abstracted out to use the API (A), making it work with any graphics driver written to conform to D. Right? With some rudimentary arbitration code, this would make it trivial and seamless to support multiple consoles, some graphical, some not. The driver and app writers wouldn't necessarily even have to know about it, because the code in between A and D would take care of all of the switching stuff. [Later edit: You basically say this below.]
What I am ususally told is that graphics do not belong in the kernel because graphics are unstable, but this simply isn't true. What is unstable is the way that the kernel handles, or rather doesn't handle, graphics.
Or the broken way that some closed-source drivers are written. This is why pcode and sandboxing are viable solutions to the problem of poor-quality drivers.
The reason graphics are unstable is that they currently involve direct hardware access from userspace, which everyone agrees is a big no-no, but for some reason everyone also seems to agree is the way that graphics should be done. I have no idea why people think this way, but I think it's obvious that they are wrong and I have no idea how to explain it to anyone who does not agree with me.
There are performance concerns involved here. That's why they do it. Going through kernel API calls is SLOW. Writing to a chip register is WAY faster. But I agree. It's stupid if you do things the RIGHT way. We are designing OGA to principally use DMA. DMA requires interrupt handling, making kernel calls the only way to solve the problem. We don't even want to map the GPU register set into X11. X11, like any other graphical app, would generate DMA packets that it would have to ask the kernel to submit to the GPU (zero-copy, because the pages allocated for DMA packets are DMA-able). The GPU itself takes care of security issues regarding what the DMA packets can tell it to do. Ironically, to get the best possible throughput, OGA has requirements that make user-space-mapped hardware pointless. Rather than spending lots of time waiting on the PCI bus, pushing writes directly to registers over a slow interface, we want to generate DMA packets in host memory, which is fast, and then ship them off to the GPU while the host CPU is doing something else productive. [continued] _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
