Adding a GPU (or just a video card)

So… I’ve added video card. It’s a little underpowered to call it a GPU. My video card is an AMD HD 6450. FreeBSD sees it as:

[1:10:310]root@ump:~> dmesg | grep pci7
pci7: on pcib7
vgapci0: at device 0.0 on pci7
pci7: <multimedia, HDA> at device 0.1 (no driver attached)

… and I have my own issues to solve there, but I’m posting here because the unmatched doesn’t use it for boot. Is this intended? Seems unfriendly, if so.

The unmatched doesn’t display video output for the first minute or so on boot. This is regardless of which graphics card you are using.

To be more precise, I think you’re detailing that the firmware doesn’t do video at all.

Correct. As graphics cards don’t come with a video BIOS for RISC-V, there’s no way to do display from the firmware. Well, it would require adding drivers for every graphics card to u-boot.

Isn’t that what VESA is for? Maybe this brings us right back around to an opensource video card?

VESA is x86 specific. However, it does look like I was wrong. I just found that UEFI GOP supports platform-independent graphics display drivers (in the form of “EFI byte code”), I have no idea in how far graphics cards provide this in practice, nor if u-boot supports this, but it sounds like an interesting possibility.

An open source video card would be even better of course.

Yes… that’s the nirvana. TBH, right now, I’d be buy an opensource card that did matrox millennium level stuff — ie: multimonitor support, vector graphics and blits. Audio would be nice add since we don’t have.

EFI bytecode is a bit of a misnomer, it’s really just “we took x86_64, slightly abstracted and simplified it and then made people emulate it”. It’s not a proper bytecode, and has baked-in assumptions like pointers and integers being completely interchangeable, unlike something like ACPI that properly abstracts memory regions and addresses in its AML.

1 Like

Yes… that’s the nirvana. TBH, right now, I’d be buy an opensource card that did matrox millennium level stuff
ie: multimonitor support, vector graphics and blits. Audio would be nice add since we don’t have.

Yes, exactly. What I would personally really like is a reasonably-beefy (but supported by the Yosys FOSS toolchain) FPGA, connected through high-speed interface with the CPU, with HDMI output(s). There’s no way this is competitive with AMD/NVidia’s GPUs but it could do basic 2D/3D acceleration, sound, and application-specific fun stuff.

Haah thanks for the explanation, leave it to EFI to do… that. Microsoft’s hand is way too visible for comfort in these kind of PC/server standards.

Let me know when an OSS video card becomes available that does not suck. It would be nice to get away from proprietary vendors but I am not holding my breath. I don’t need it to run pick your latest game at 4K 120hz…….

I am not aware of graphics cards using EFI byte code.

Support for graphics cards during boot will require EDK II and the X86EmulatorDxe package from

The emulator package contains parts of QEMU and executes the x86 GOP driver from the PCI-card ROM.

This is why an opensource video card is so necessary. That’s an abominable amount of goo to pass through to put text on the screen. It would really suck power, too.

Maybe it’s worth looking into what the Commander X16 (a retrocomputing project) did. Now their implementation, as I understand, is a cheap FPGA outputting to HDMI. It has a one byte register with auto advance addressing, but there’s no reason an PCIe interface couldn’t be slapped on (those exist for fpga, right?). I think it’s also only 8 bit colour or somesuch, but again, it’s a starting point that is known to work.

1 Like

A simple framebuffer with VGA or (even easier) DVI output is totally trivial to implement yourself, using SRAM and a handful of 7400-series chips, or in an FPGA or SoC.

That’s all the first decade of Macintosh and Windows computers had. And the Linux kernel has built in support for that.

But people now expect to be able to drag whole windows around – not just a dotted outline of where they will eventually be redrawn – and menus and menu bars to slide smoothly in and out, and fancy transparency effects. This requires 2D acceleration of compositing multiple layers of different bitmaps together.

And people expect 3D games, and not just fake 3D like Doom. That’s a lot of work. And it’s not ready for standardisation. Even a company like nVidia still today doesn’t know what the best ISA or GPU architecture looks like and is still making radical changes from generation to generation.

But we should be able to come together on a compromise. Like the unleashed itself. Does it compete with even the weakest new desktop? No. Not on your life. In seat-of-the-pants feel, I put it in league with the how the core-2-duo felt. That’s about 2004 to 2006 time frame.

But-to-be-clear, I accept this wholeheartedly for finally being in control of a system that I can use for serious (if light) work. And I’m still sore that there are a few binary blobs, but that’s another post.

Similarly, a compromise on a video card is a good start. I think it should have the following feature list:

  1. HDMI out with at least 2 ports (or at least capable to be built that way)
  2. HDMI audio. I think that’s all digital — so the component count is easy for it.
  3. 24/32 bit colour. Simple enough.
  4. shoot for at least (2x) 1080p.
  5. Sensible 2D acceleration along the lines that X11 likes. I said something like Matrox Millennium — and I mean it.
  6. A dead simple console mode — dead simple to implement — might get a lot of hobiest buy-in. Maybe something like a built-in vt-100 or vt-220 (colour) emulation.

This isn’t about chasing what people expect, it’s about creating what hobbiests need. It doesn’t need to change as often. If it becomes easy for someone to implement some basic 3D stuff — make the spec easy to implement while being compatible. Point 5 can be a simple serial protocol that emulates a 16550 class register set (or some such) to make easy consoles. Point 4 is probably starting with a bitmap display … and maybe adding basic compositing… or just blitting … I recall the Millennium being able to move full windows around in real time circa 2000-ish.

Anyways … if nobody has appetite for this idea, fine. I don’t need another person to detail how to fail — failing is the easy part.

HDMI isn’t going to happen. It needs licenses and NDAs.


Add your own DVI to HDMI dongle if you must.

The rest of what you ask is very simple and could be implemented in any decent FPGA chip. There are open source designs for framebuffer DVI video with some 2D acceleration already out there.

Haiku is quite fast with pure software rendering and without any kind of hardware acceleration. So it should work fast even on framebuffer graphics card. Fast software graphics is achieved by using screen double buffering and performing all drawing on back buffer in RAM. Drawing on front buffer is very slow because of slow GPU memory read access by CPU.

2D acceleration is obsolete for more than 10 years. OpenGL ES etc. is used for accelerated compositing.

I heard that passive DVI <-> HDMI adapters exist. Maybe it is possible to make DVI port with HDMI connector?

Or finally go for display port. It’s 2021 and HDMI really is a pain for the known reasons.

We’re talking about using a simple framebuffer because we don’t have open source 3D acceleration, remember?

Simple BitBLT acceleration is 1970s technology and relatively easy to add.

Maybe it is better to add fast CPU memory access?