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