Slashdot Mirror
Basic Linux Boot On Open Graphics Card
David Vuorio writes "The Open Graphics Project aims to develop a fully open-source graphics
card; all specs, designs, and source code are released under Free
licenses. Right now, FPGAs (large-scale reprogrammable chips) are used
to build a development platform called OGD1. They've just completed
an alpha version of legacy VGA emulation, apparently
not an easy feat.
This YouTube clip
shows Gentoo booting up in text mode, with OGD1 acting as the primary display.
The Linux Fund is receiving donations, so that
ten OGD1 boards can be bought (at cost) for developers. Also, the FSF
shows their interest by asking
volunteers to help with the OGP wiki."
The /. post gives the wrong impression about the VGA implementation - it was difficult because they wanted to implement it in a extremely simple fashion, not because VGA itself is complex
A lot of times, FPGAs are used for development. Once the design is proven, then you can go to etching into silicon. Almost nobody builds a fab for one chip, the good news is that chip fabs can make numerous different kinds of chips. There are many fabs that are willing to take any design that comes their way, as long as the money is there.
If I don't like my NVidia card, I can move to a competitor's chipset.
Only if the competitor is friendly to the free software community. There are plenty of hardware makers that have declined the free software community's requests for low-level specifications useful for writing free drivers.
from http://www.osnews.com/permalink?360100 As the original architect of the way VGA is done on this board, perhaps I can offer an explanation. There is perhaps a more straightforward way of implementing VGA than the way we did it. The direct route would require two components. One piece is the host interface that interprets I/O and memory accesses from PCI and manipulates graphics memory appropriate. The other piece is a specialized video controller that is able to translate text (which is encoded in two bytes as an ASCII value and color indices) in real-time into pixels as they're scanned out to the monitor. This is actually how others still do it. To us, VGA is legacy. It should be low-priority and have minimal impact on our design. We didn't want to hack up our video controller in nasty ways (or include alternate logic) for such a purpose, and we didn't want to dedicate a lot of logic to it. Doing it the usual way was going to be too invasive and wasteful. Also, we want eventually to do PCI bus-mastering, which requires some high-level control logic, typically implemented in a simple microcontroller. So we thought, if we're going to have a microcontroller anyhow, why not give it dual purpose. When in VGA mode, the uC we designed (which we call HQ) intercepts and services all PCI traffic to OGD1. Microcode we wrote interprets the accesses and stores text appropriately in graphics memory. Then, to avoid hacking up the video controller, we actually have HQ perform a translation from the text buffer to a pixel buffer over and over in the background. Its input is VGA text. Its output is pixels suitable for our video controller. Aside from the logic reduction, this has other advantages. The screen resolution as seen by the host is decoupled from the physical display resolution. So while VGA thinks it's 640x400, the monitor could be at 2560x1600, without the need for a scaler. It's easily programmable, and we have complete control over how the text is processed into pixels; for instance, we could have HQ do some scaling or use a higher-res font different from what the host thinks we're using. We call it emulation because, in a way, our VGA is implemented entirely in software, albeit microcode that's loaded into or own microcontroller.
Cool, yes. Useful - hardly.
If you start with a clean slate, why would you bother with VGA emulation? Could you not just go for a sane solution, such as a flat frame buffer? Any other architecture does that, why does the PC architecture have to drag along legacy modes such as CGA with a number of 4 colors palettes?
A flat 8bit RGB buffer would make a lot more sense, and I am sure Linux would boot faster on it, too.
and your line seems to suggest confusion on that part.
Doesn't seem that way to me. He's just pointing out that when compared to other electronics, we have shockingly little info available.
Even for CPUs, there are fully documented "open-source" microcontrollers available, but for GPUs there's basically nothing. It is a big mystery, how it's all done. And now we've gone so far that GPUs are doing incredible things like juggling 10,000 threads that manage all the shading when, you fire up a game.
nVidia and ATI stated GPUs are many times more complex than CPUs, and I fully believe them.