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)
>
