Le jeudi 19 juillet 2007 à 09:13 -0400, Timothy Normand Miller a écrit : > Excellent. Thank you. I noticed that the RAM chips look kinda > blacked out there. Any idea what happened? Just a setting with more constrast, but if you want I can hide their layers. > > > On 7/19/07, luc marschall <[EMAIL PROTECTED]> wrote: > > 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)
