Le mercredi 18 juillet 2007 à 23:00 -0400, Timothy Normand Miller a écrit : > I'm still interested in taking suggestions, but things look like > they're winding down. > > First, the update to the slides: > > http://www.traversaltech.com/files/speech4.odp > > Slide 2 still needs a proper-looking image. http://lucmars.perso.orange.fr/ava/board.png
> Slide 7 is kinda weak and > needs a better way to visualize the concepts of sequential vs. > parallel. > > For 7, one idea that comes to mind is to have some code with arrows > from line to line for sequential. For parallel, some logic gates with > some feedback or something. But really, the concepts need to be > abstract, and it just needs to be finalized. ??? > I'm going to be spending > most of my time now just practicing. > > Thanks, everyone! > > > Here's the updated text of the speech: > > [Root window with OGP wallpaper] > # Well, good afternoon, everyone. My name is Timothy Miller, and I'm > the founder of the open graphics project. > # My usual soapbox is a keyboard, and I much prefer interacting to > lecturing, so if I say something that raises questions or needs > clarification, please feel free to ask. I'll also take longer > questions at the end. > ## Anyhow, I have been using Linux since 1995, and I've been an avid > fan and user of Free Software ever since. > # Historically, it's been hard to get graphics cards that work well > with Free Software. Even now, most available graphics solutions are > proprietary cards with proprietary drivers. > They lack the advantages of open source, letting you make changes, fix > bugs, keep up with kernel upgrades, learn from them, or whatever else > you might want to do. > # Many people feel that proprietary drivers in Linux violate the GPL, > making it a potentially serious legal issue as well. Some Linux > distros, for ethical reasons, simply don't come with these binary-only > drivers. A particularly prominent one is Fedora. > ## Well, my background is in graphics hardware design, and I thought > it would be interesting to try to do something about this. So my > associates and I set out to make a truly open graphics card, and this > is what I want to talk to you about. I'm going to cover our project, > our plan, our achievements and some of the unique challenges involved > in making hardware. > > [2 Slide with OGD1 board pic] > # To get things started, we decided to begin with a bootstrapping > effort, which is a development platform. We needed a facility to try > out and test graphics processor designs. > # So I'd like to show you something we've built. > # THIS is the OGD1 board, the open graphics development board. > ## At the moment, it's functioning as a basic framebuffer for the OS > with a simple x.org driver. And as a matter of fact, that's what is > displaying the presentation right now. An OGD1 board is here in this > PC next to me. As proof, I can give you a little demo that shows why > you don't usually want to go without hardware acceleration. > [do some dragging and stuff] > [while demoing] Some people have told me that they're willing to put > up with this. They actually prefer to use the unaccelerated fb driver > over using a proprietary one, because they don't trust the proprietary > drivers. Also, for a lot of common UI stuff, it's hard to tell the > difference. [minimize a window, open a menu] So for an early > prototype, it's really quite usable. > > [3 Slide with diagram of OGD1 with some Verilog code] > # OGD1 is built around an FPGA. FPGA stands for Field Programmable > Gate Array, with the key words being "field programmable". It's a > chip that you can reprogram. > # We develop our logic designs in a language called Verilog and > "compile" or "synthesize" it to instructions for the hardware. These > aren't like instructions for a CPU but rather control bits that > specify signal routing and functions for logic gates. With this basic > shell of a graphics card, we can program new designs into it at will. > # In addition to the FPGA, the OGD1 board also has memory chips, DVI > transmitters (two pairs of dual-link DVI, which is actually pretty > high-end), digital to analog converters, a TV chip, and a number of > user I/O signals available for extensions. > ## Of course, there are actually other FPGA prototyping boards > available on the market, but we believe ours is a better bargain. It > has open source origins, which made the development less expensive. > And for our purposes, we've added additional hardware specific to > graphics. > > [4 Slide with URL for SVN repository] > # In fact, this board itself is a free hardware design. There's the > URL to our subversion repository, and you'll find a link to it on the > open graphics home page. > # Schematics are available online, as is most of the Verilog code for > the logic that we currently have working. It's all copylefted, so > modifications and derivative works are allowed under the terms of the > GPL. And the software driver is free software too, of course. > # Pretty soon you'll be able to buy one and use it for graphics or to > make other hardware designs. > > [5 OGA Requirements and specs slide] > # Now what we want to do is take what we've done and use the FPGA as > an environment for developing a full-featured open graphics card. > # A lot of community discussion went into this. Debate went on for > months, and the spec that came out of it, we think will satisfy 90% of > the users of free software desktops. > # We've cherry-picked the most important features from the OpenGL > specs from versions 1.3 through 2.0. The result is a fixed-function > 3D rasterizer and fragment shader. And then we included some > additional features that weren't specified by OpenGL. > # Further into the future, we would be interested in targeting the > high end, but before we can hope to do that, we need to be successful > at something smaller. > > [6 Contributors slide] > # I just mentioned a lot of community discussion. The open graphics > project is a real community effort. The mailing list currently has > over 500 members. > # Here are just a few of the people who have contributed something > significant to the requirements, design, and many other things that > keep a project focused and productive. > # They deserve huge thanks for what they've done. > > [7 Challenges] > # I also mentioned earlier the challenges with making hardware. > # I like to think of chip design as like taking multithreaded > programming to its ultimate extreme. It's as though every little > block of code in your program is running in parallel with every other > block of code in your program. Imagine being required to break even > simple programs into a multitude of threads that work together by > sending each other messages. > # With a single processor PC, parallelism is largely an illusion. The > operating system schedules many independent tasks to run one after the > other in a way that makes it look like all these things are happening > at once. > # By contrast, in a chip, absolutely everything happens at once. > Sequential behavior is constructed on top of the underlying logic. > # It took me several years to get used to this way of thinking. Part > of the challenge was breaking old habits. For instance, a rule of > thumb that is often true is that if you write smaller, cleverer code, > the object code will be smaller, and often you also get faster code as > well. With chip design, the more elaborately and explicitly you > describe your logic, the better your result [and the less likely it is > that the synthesizer will produce something terribly inefficient]. > Clever tricks with the programming language will only hurt you. > # Many software techniques for design, development, debugging, and > testing do have an analogue in hardware design, at least when it comes > to logic in an FPGA. Circuit boards and integrated circuits impose a > whole other level of technical challenges. The main thing is that > hardware is expensive to make. Fortunately we believe we've developed > a business model that will solve this problem. > > [Organizational slide] > # Since a lot of money has to be handled, we absolutely must form > corporate entities. So we've done so. > # Traversal Technology is there to handle the commercial aspects and > hardware fabrication. > # [And] The Open Hardware Foundation is a non-profit corporation. > They handle donations and function as a democratic body to represent > community interests. > # These two will be able to generate revenue streams in their > respective ways and use that money to fund the development of open > hardware. > > [Other pieces slide] > # So our plan goes as follows. > # First, we build the development environment, OGD1. That's done, and > it works, and we can already use it as a graphics card. > # Then we spec out the abstract architecture, OGA1. That's done too. > # Now we have to do the rest of the pieces. > # We need to implement the OGA1 logic design and test it thoroughly on > OGD1 boards. When the design is proven, we retarget it to a faster, > lower-power, non-programmable chip called an Application Specific > Integrated Circuit, ASIC for short. > # We've named this part TRV10. This is the really expensive bit, > because although individual chips are cheap, having the initial masks > made is costly. > # In order to to keep volumes up and prices down, we plan to sell it > into two markets. > # One is the OGC1 card for open source desktops. The other is as a > bare chip for embedded systems. > > [Open Hardware slide] > # Of course, we're not interested only in graphics. We started there, > and that's where we're maintaining our focus. We need to maintain > that focus in order to have an attainable goal that we can achieve in > a finite amount of time. > # But we ARE interested in the bigger picture, and that's why the OHF > was formed. We hope that what will come out of this project is a > wider open hardware community. > # There are already lots of projects such as open cores where there > are some clever and talented people working away. We want to form an > organization which will advocate and advance the interests of this > community. We want to build an environment where enthusiasts can take > their designs and turn them into real hardware. The OHF even plans to > fund development work. Initially, the OHF is offering discounts on > OGD1 boards to open graphics developers, and as donations come in, > they'll direct that money to help more and more hardware projects go > from clever designs to clever open hardware. > > [Getting involved] > # We're excited about being able to produce hardware with all of the > advantages of Free Software. And we hope that some of you are too. > # If you would like to help out financially, you can donate to the OHF. > # If you are interested in hardware development, you can assist with > our design work. [Delete: Hardware design can be very different from > software development, but for those who are interested, we're > developing tools and learning aids that should make things easier.] > # If you have software talent, you can assist with CAD tools, device > drivers, and other useful applications. > # And of course, if you're interested in using any of the hardware > we're developing, we'd be happy to discuss it with you. > > [Questions slide] > # Here are some URLs you can write down and visit later to get more > information about the Open Graphics Project, the Open Hardware > Foundation, and Traversal Technology. > # I want to thank all of you for taking the time to listen to me, and > I hope it was interesting. > # Okay, who's got the first question? > > > Other stuff for anticipated questions > > [Programmable shaders] > As it turns out, a so-called modern programmable shader design is an > order of magnitude more complicated than the simple fixed-function > pipeline we've decided to go with. For a given level of performance > for the most basic things, a programmable shader design requires > vastly more logic, a much higher clock rate, significantly more power, > and for us, infinitely more development time. We just don't have the > resources for it. Sure, there are things that you can't do without > programmable shaders, but those are limited mostly to lighting and 3D > texturing effects used by only the most aggressive games. Actually if > I understand correctly, Windows Vista requires them for Aero Glass, > but this is ostensibly as a way to offload some of the UI > functionality form the CPU to the GPU. It's not strictly necessary, > as you can observe when using MacOS 10 or Beryl on much older graphics > cards. > > [When do you expect to release these products] > OGD1 is basically done. We've identified all of the bugs. There are > just some tedious steps remaining to do before we can hand it off to > a board house and have them mass-produced. The other major thing is > fabricating the OGA1 logic into TRV10. That's a big open question. > One factor is the money. Prices change, so we can't say exactly how > much it would cost, but we either need to raise a lot of money, or we > need to find partners who are interested in the technology. The next > issue is fabrication. Even if we could design and finish testing OGA1 > infinitely fast, it would still take 6 months to get chips in our > hands. So, in short, you can get OGD1 at the end of the summer. You > can get consumer graphics cards, say, one year after we have enough > money. > > ["a good spec doesn't suffice instead of creating hardware?"] > There seems to be an increasing trend where hardware vendors are > choosing to support Linux but also choosing to provide only binary > drivers. The result is an ever-increasing amount of proprietary > software that users of Free Software have to put up with. This isn't > the direction we want to go. With Open Hardware, we want to reverse > this trend, and the approach that we prefer is to develop our own > hardware when the vendors aren't willing play by our rules. No matter > how well-documented something is, it's hard to work around an > undocumented bug when you have no way of finding out what's really > going on inside of the hardware. Not only that, but the general idea > of open hardware puts freedom and knowledge back into the hands of the > users. Open Hardware isn't just about tinkering; it's about > information and communication. > > [If some other vendor were to release specs on their hardware, what do you > do?] > I'm not sure that would change much. Just because they release specs > one day doesn't mean they won't take then down another day or refuse > to publish specs on future designs. You're always subject to the whim > of the hardware vendor. In the early to mid 90's, a number of > graphics vendors were willing to publish specs. Some went out of > business, while others were gobbled up by bigger companies. Now we > don't have very many major graphics chip vendors, and they're fighting > each other over the Windows gamer market, with only passing interest > in free software platforms. With open hardware, you never have to > worry about this. So what the proprietary vendors do may have some > effect on the open hardware market, but only until they change their > minds again. Besides, open hardware is its own interesting thing, so > if a graphics vendor decides to get a piece of our pie by releasing > specs, it may affect our graphics market share, but it won't affect > other open hardware projects. The thing that's a double-edged sword > for us is that we're not interested in market share as much as we are > in freedom, which gives us different priorities. If and when some > other hardware vendor decides to compete with us on our terms, we'll > just have to see what happens. > > [What Patrick McNamara said about fabbing ASICs] > The masks ARE that expensive. A 90nm mask set is going to run well over > $500k US. Obviously, the older the tech, the cheaper the masks, but the > lower the clock rate and the higher the power consumption. For a 300mm > wafer, figure around $3k+ per finished wafer. If you get 300 dies per > wafer, you are looking at $10 per die before packaging and testing. If > you do a run of 1200 chips (4 wafers), your cost for the chips is about > $12k and the cost for your mask set is say $700k. After amortizing the > mask over the chips, you cost per chip is $593. If you do a run of > 300,000 chips (1000 wafers) then your amortized cost per chip is ~$12 > per chip. Volume really pays in this case. > > > Special features we have that other cards don't > Some things that OGD1 would be useful for (PCI sniffing) > [Mention specifically PCI controller, memory, video?] > > -- > Timothy Normand Miller > http://www.cse.ohio-state.edu/~millerti > Open Graphics Project > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
