On 5/13/06, Nicolas Capens <[EMAIL PROTECTED]> wrote:
In fact, one of the fundamental questions raised a year ago still exists: Do we really need open-source hardware to solve the actual problem? As you have indicated as well, it is very much a software problem. Hardware can solve ONLY the performance aspect of the problem but that's just a fraction of the work (not underestimating the complexity of hardware design). What we need (first) is a complete software infrastructure, from high level GUI API to 2D/3D API, to O.S. interface, to kernel, to driver, to device emulator.
Actually, what you're suggesting is an excellent idea. I developed a software model of OGA. How about we take it from another direction. We don't know exactly what needs to go into the design, but we can figure it out empirically. Start by making up a set of rendering features (forget "2D" and "3D" and start with "stuff we need"). Develop a DDX, a kernel driver, and some user-space pseudo-device that everything talks to and which pretends to be this piece of hardware. It can talk to any existing graphics card whose framebuffer we can init and mmap. Instrument the heck out of it and profile it. From this, we'll figure out which features are most performance critical and which are not. We can consider tradeoffs between software rendering (in the DDX) and hardware rendering (in the simulation of the hardware) and estimate relative performance, etc. As we're going along, we need to still think like hardware designers. Break things down to "primitives" and "attributes". Primitives correspond to high-level operations, and attributes correspond to variables like colors and coordinates. When OGD1 is ready (which it probably will be before the above is finished), we implement a bunch of this in hardware and try it out. If we discover that we have room left over, we can revisit some of the ideas we threw out and see if it won't hurt to include them for "future proofing". Note that we figured out a lot of the math when working OGA, so borrow liberally from the model rather than reinventing the wheel. Same goes for software rendering parts of X11 (cfb/fb/mfb/mi). Get in tough with Keith Packard and tell him that we're reevaluating our direction and that he can get essentially any sort of feature he and his colleagues with X.org could want. What do they need? What do they want? Since the focus right now is getting OGD1 finished, it would certainly not be an unwise use of time to reinvent OGA while it isn't in the critical path. Just keep in mind that it needs to be convergent. If this turns into a total bickering mess, I'm going to be forced to reject it and go with the original OGA design because I know I can get it to do all of the X11 functions we need, even if it's not the best possible design. Oh, and practicality must prevail. Choose needs over wants. Choose generalized designs over unnecessry optimizations. Make compromises for the sake of getting something GOOD built. Put aside your idealism and think concretely. I never thought OGA was a wonderful design; I have stuck with it because I felt it was GOOD ENOUGH to get the job done. I still believe that. But if you guys want something different, I won't stand in your way. So, just to make this clear, I think it's hyperbole to say that OGA, as it's spec'd, is "the wrong thing to do." It is suboptimal and no one's argued otherwise. (Everything is suboptimal!) It is, however, one possible design that is capable of being made to do all of the things we need it to do. No matter what design you guys come up with, there's always something better that is possible with the resources we have. It would just take an eternity to design it. It's funny that it was complained about OGA having been designed by committee, while it is committee that is going to have to replace it. If we go through all of this hassle and end up with something that basically looks like OGA with just superficial differences, I will personally find you people, fly to your homes, and smack you silly. :) _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
