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."
Isn't VGA a very thoroughly documented and widely implemented standard?
... performance will be terrible .
Also, they can't possibly approach competing with NVidia or ATI and I doubt anyone's going to shell out a billion dollars to build a plant to make their cards. If they're just playing around with FGPAs then this isn't really a serious "Open Graphics Card"
Do you want to be tied to a vendor?
If the answer is no, then you understand. if you don't mind being tied to a vendor and at their mercy, then i guess the answer for you is that there is no benefit.
Open hardware has the same value as open software.
---- Booth was a patriot ----
Well obviously it's of academic interest. American consumers have sunk billions into video card research and for the most part the implementations are shrouded in mystery locked up in labs. Nobody un-NDA-bound really knows how to build these things: computer graphics is a highly specialized and difficult problem for hardware engineers. The real interest is in making a hardware design that actually works well and then writing up the design in abstract, not to actually make working video cards.
Also I guess it's useful to hammer out some foundational "building blocks" and make them available freely so that entry into video card research is easier.
We're geeks... So the reason is "because we can". It provides a system where we don't have another blackbox. We can actually understand down to the lowest level how things are working. This is great for people who desire to understand how things work, and also people that hope for a future of machines and hardware that are under the control of the owners.
Sorry to get a bit crazy here, but imagine a world with technology like that in Ghost in the Shell. I would not go getting such implants and additions if I did not and could not have complete control and understanding over the stuff. This type of project is a small step in maintaining individual control.
When a piece of music, or a play, enters the public domain, there are effects beneficial to the public:
These have analogs here. Having a Free video card design means that low-end video cards can become that much cheaper (and that there's more room for new entrants into the very-low-end market), and that there's a common, available base on which new and innovative work can be done.
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.
If you had RTFA you would have noticed that that's exactly what they have done !!
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.
Well obviously it's of academic interest. American consumers have sunk billions into video card research and for the most part the implementations are shrouded in mystery locked up in labs.
The problem with this line is that the American consumers may have sunk billions into buying video cards, they were never promised any or all the knowledge required to build one. In other words, you bought a product, not the product design process process, and your line seems to suggest confusion on that part.
There's not that much mystery about the things. Making a VGA emulator in an FPGA is no big deal. If all you implemented was text mode and mode 13H, it would probably boot Linux. Getting to a card that runs OpenGL is a big job, but not out of reach. The pipeline is well understood, and there are software implementations to look at. As you get to later versions of Direct-X, it gets tougher, because Microsoft controls the documentation.
But the real problem is that you'll never get anything like the performance of current generation 3D boards with an FPGA. There aren't anywhere near enough gates. You need custom silicon.
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.
Unfortunately the BIOS and boot loader will still need VGA. Maybe Linux BIOS could remove that requirement, but you can't count on that.
They seem to have implemented it in a very cool way too. Quote from a linked OSNews article:
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.
Slashdot, RTFA, blah blah blah.
If you go to the Wiki, and read the link in the top article, there is a link to OS News. If you follow that and read down in the comments, you'll find this post by the architect of the VGA emulation.
Apparently it really is emulation. Their MCU that they use as a PCI interface has a mode that generates the raw pixels when given VGA commands. It handles the VGA interface. The graphics processor just receives (from it's perspective) pixmaps that are constantly generated by the MCU in VGA mode.
The guy says that VGA on their card is actually resolution independent (since the MCU generates what is needed) and could actually be up-sampled to show clearer fonts without the OS having any idea it was going on.
He says it's not the cleanest way of doing things (from a methodology standpoint), but it has the least impact on the design of the hardware (compared to a "real" VGA interface).
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Implementing OpenGL efficiently isn't just a "big job" it's essentially the entire field of computer graphics hardware.
It's understood, though. And you can do it in sections. Start with an OpenGL implementation that does tessellation, geometry transforms, and fill in software. Build something that just does the fill part. (That's 1995 technology in PC graphics.) Then add the 4x4 multiplier and do the geometry on the board (that's 1998 technology on the PC, 1985 technology for SGI.). Once all that's working correctly and the read-back of the frame buffer matches the OpenGL spec for the tests, you can start to work on parallelism. (That's 2000 technology). Then comes programmable shaders and arbitrary computation on the graphics board, which gets hard.
It's a lot like Linux; a decade behind, but still useful.
Why don't you get involved in the project then and tell them that.
For what it's worth, nVidia cards can do this just fine and have been able to for a long time. See the "full GPU scaling" option in nvidia-settings. My HTPC's nVidia card also shows the BIOS on my HDTV at 1080p link resolution (while pretending to be VGA to the software).
If the answer is no, then you understand. if you don't mind being tied to a vendor and at their mercy, then i guess the answer for you is that there is no benefit
Yeah, but open vendors are vendors too. That's the thing. Basically, what you are trying to do is suppress innovation for the sake of commoditization, and that's not a proposition that people want to make.
This is my sig.
Agreed. I'm not a gamer, but I like the idea of having an open implementation of a graphics card for my use. Lower the barriers to entry to the market, and things get really interesting.
I hope this group of engineers can succeed in producing an open board that eventually provides high-end graphics capabilities.
The diversity and expression of human opinion is essential to human survival.
Sure it does, the BIOS boot screen, settings, etc are kind of important to be able to see sometimes. The boot loader also counts on the VGA mode too.
Now of course you could use Linux BIOS instead, but then that adds the requirement to have a supported motherboard, and wanting to risk flashing it.
But it probably still uses a 8x16 pixel font, which doesn't look that good on a 30" screen.
I think the idea is that the video card could pretend it's VGA, while substituting an antialiased 32x64 font in its place. Nothing earthshaking of course, but that sure would look nice.
Your text mode could look like this
Ok, and how many people are going to run a desktop on it? It's server hardware.
Again, you seem to be missing my point. Yes, Linux technically doesn't need the BIOS. Yes, there exist other architectures besides x86.
But, a video card is a product for desktops, and the vast majority of desktops are x86. The vast majority of those start booting in text mode.
Pretty much all other architectures are unimportant in comparison, because they're used in embedded hardware, or are technically outdated. If anybody is going to buy this thing, I doubt they're going to put it into a modern Sun server.
It's already a project that's going to find it hard to get wide adoption, why would you make it even harder for it to find an use, by making it incompatible with the most common by far hardware it could be plugged into?
This is why I love Slashdot: lazy Saturday, talking about video cards, not even 100 posts up yet...
BAM! Godwin!
I've used Sparc desktops in the past. I even used one as my main home machine for a while. You could even get Sparc laptops.
In their time they beat the Intel option imo and they are still in use in some places.
Having just finished a semester project writing a bootloader for an ARM processor, I can say without a doubt that there's no way you can get around BIOS. Linux most certainly needs BIOS. But not only does it need BIOS, it needs a bootloader. Linux is all kinds of cool things, but ain't magic, you know.
Linux needs some sort of bios to boot. With no code at all, the computer is useless! Having said that, Linux does not require the MEGA-BIOS that most PC's come equiped with in this day and age. Even the original PC BIOS is overkill. You only need some code to initialise basic things like timers, uarts, ethernet controllers, etc, some IPL code for the Disk/Flash, and if you want to be really nice, a simple text mode to show the initial boot progress.
Writing a bios specifically to boot straight into Linux is relatively straight forward, and one benefit is that the machine boot up time is minmised. Watching an X86 machine boot into linux when running a minimal BIOS is a gratifyingly fast experince!
You fail to take into account how fast things can change on the desktop arena. I say we have had enough of either BIOS, VGA and the text mode as such. For all it is worth, do it like Macs do - startup the minimalistic OFI/EFI with the video card in graphics mode, and boot up the OS from the disk blocks as fast as you can. If anybody wants to mess with their system before the OS loads up, they should press that Alt+Option+O+F or whatever that was, and type firmware commands into console. BIOS accomplishes neither task well - it gives experts stipid interfaces, while they could be using command line instead, and novices do not even know what they are doing in BIOS.
And no stupid 4-bit color Dell/Lenovo/HP/Asus/Acer logos with stupid BIOS text and even more stupid BIOS itself.
There is no need for two operating systems on one computer for the majority of us, BIOS being one. And it will save us 10 seconds of idle time at startup. Degrade the common subset of hardware interfaces so that the only thing the bootstrap procedure needs to do is get to the boot block of whatever device that contains the further loading code. No VGA BIOS and BIOS interface is needed for that in their entirety. Just a way to read the boot sector from a device. That does not need a vendor logo on the screen or the multitude of settings BIOS provides, before these are superceded with OS drivers anyway.
The tighter the NDA, the more you should suspect that the underlying tech is not rocket science.
So to speak.
In this case, graphics is not that hard. Fast graphics, even, is not all that hard.
The cruft is the thing that is hard. Mechanisms to manage (emulate) the cruft are about the only thing non-obvious enough to get a good patent on, and much of that, if shown to the light of day, will be seen to be covered by prior art.
A big part of the reason INTEL got so excited about ray-tracing was that they were/are hoping there will be something in there that will be hard enough and innovative enough to get some solid IP protection on.
False hopes. (... besides IP being an oxymoron ...)
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Copy a Linux kernel to /dev/fd0 and it will so boot without a boot loader
Will it? How does the CPU know how to read the image off the floppy?
As a person who actually did proprietary BIOS development, I can tell you that:
1. It's possible to make BIOS boot without VGA.
2. It's usually a massive pain in the neck.
One of my projects involved making one of the popular proprietary BIOSes boot on custom x86 hardware that lacked VGA. On the development board (where I could attach and remove PCI VGA card) all it took was setting console redirection in CMOS setup, turning the computer off, removing VGA and booting it again. On production board (with no built-in graphics adapter and no PCI slots) I also had to modify BIOS so console redirection was on by default.
Then I had to spend weeks rewriting console redirection code to make it work properly -- I had to rely on console messages when debugging custom hardware support, and existing implementation was way too crude to actually display all messages those. Existing implementations merely allocate "VGA" buffer in memory, occasionally check it for changes and send the updates to the serial port using VT100 escape sequences. "Occasionally" is a key word here.
Contrary to the popular belief, there indeed is no God.
If anything, a modern GPU is easier to implement than an older one. Modern APIs basically ditch the entire fixed-function pipeline in favour of an entirely programmable one. The fixed-function OpenGL 1-style pipeline is implemented entirely in the drivers. The GPU is just a very fast arithmetic engine. Some are SIMD architectures, but a lot of the newer ones are abandoning even this and just having a lot of parallel ALUs. You could probably take an FPU design from OpenCores.org, stamp 128 of them on a die, and have a reasonable (if not stellar) GPU that just needs drivers writing. With an architecture like Gallium3D, even this is relatively easy; the driver is effectively a compiler from an intermediate bytecode to the hardware's instruction set and you can create one by just implementing an LLVM back end for your code (typically around 10KLOC), reusing all of the OpenGL state-tracking from Mesa.
This is essentially the approach Intel are taking with Larabee. The GPU is just a load of relatively slow CPUs with beefy vector units all on the same die.
I am TheRaven on Soylent News
We are proposing the same thing. It's just that you use the term BIOS instead of firmware. BIOS is a x86-centric word.
Booting linux without a BIOS have already been done, check that out : http://en.wikipedia.org/wiki/Splashtop
Some Asus MB have this feature. My M3A78-EM have this feature, it can boot a small Linux distro in about 5 seconds.
Votator.com implements a fair voting scheme (free
To all of those who keep saying this project is useless because it will never compete with NVIDIA/ATI:
Although I agree with those who cite "because we can" as a perfectly valid reason, it is not the only reason. The lack of high quality open source 3D graphics drivers has long been an issue with desktop applications of Linux/*BSD, and while NVIDIA's closed drivers do fairly well they still limit the options of the open source community. If a bug in those drivers is responsible for a crash, it's up to NVIDIA to do something about it. The open source community is prohibited from fixing it. Remember the story about how Stallman reacted when he couldn't fix the code for a printer?
Plus, who knows what optimizations might be possible if the major open source toolkit devs could sit down with the X.org guys and the OpenGraphics folk and really start to optimize the whole stack on top of an open graphics card? It wouldn't be up to the standards of NVIDIA or ATI for 3D games, but in this day and age you need decent 3D graphics for a LOT more than that! Scientific apps, Graphics applications, CAD applications... even advanced desktop widget features can take advantage of those abilities if they are present. What if ALL the open source apps that need "good but not necessarily top of the line" graphics card support could suddenly get rock solid, flexible support on an open card?
The paradigm for graphics cards has been "whoever can give the most features for the newest game wins" for a long time now. But there is another scenario - what if maturity starts becoming more important for a lot of applications? For many years, people were willing to toss out their desktop computer and replace it with one that was "faster" because usability improved. Then the hardware reached a "fast enough" point and the insane replacement pace slowed. For some specialized applications, there is no such thing as a computer that is "fast enough" but for a LOT (perhaps the grand majority) of users that point is dictated by what is needed to run their preferred software well. If the open source world can get their applications running very well atop OpenGraphics, who cares what the benchmark performance is? If the user experience is top notch for everything except the "latest and greatest games" (which usually aren't open source games, bty - most of the most advanced open source games are using variations on the quake engines, which being open source could certainly be tuned for the new card) and that experience is better BECAUSE THE CARD IS OPEN AND OPEN SOURCE IS SUPPORTING IT WELL it will have a market that NVIDIA and ATI can't hope to touch. Perhaps not a huge market, but niche products do well all the time.
There is one final scenario, which is the open nature of this board's design allowing virtually all motherboard manufactures to include it as a default graphics option on their boards at very low cost. That might allow for logic that uses that card for most things and fires up the newest cards specifically for games or other "high demand" applications if someone has one installed (presumably installed because they do have a specific need for the raw power). This would mean broader GOOD support for Linux graphical capabilities across a wide span of hardware as part of the cost of the motherboard, which is a Very Good Thing.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org