Hacker News Reader

Comment by thot_experiment | Hacker News Reader

Don't get me wrong, this is very fucking cool. I have long yearned for a world where an FPGA PCIe add-in card is something practically useful and every year I gain a bit of hope that we're slowly plodding along toward that future.

But what I really want to see is quake running on quake specific hardware, with everything burned into the logic elements running at some thousands of FPS, rather than quake running on a softcore.

While we're on the subject, the real thing that's holding back broader adoption of FPGA programming is the fucking tooling. I cannot wait till we have something FOSS like clang/gcc for verilog/vhdl that can be reasonably relied upon. Quartus is... quartus is something else.

(ok maybe the real thing holding back adoption is that it's extremely fucking niche that you actually need FPGA latency, but let me dream)

View on HN

So I realize that the title is slightly misleading. It's obviously not a pure hardware implementation of Quake, but rather the original Quake software renderer running on a custom soft processor in an FPGA.

I like to use it as a benchmark while developing the CPU. E.g cache performance and branch predictor performance is so much more interesting in the context of a full game, rather than some boring synthetic benchmark.

The reason for the title, though, is that I have not seen many instances of Quake running on an FPGA, in any form (Doom is fairly common, but not Quake).

However there area few interesting projects on the aame theme:

* Quake level viewer with a custom GPU and a RISC-V soft processor: https://twitter.com/sylefeb/status/1564758778830065666

* A pretty fast general purpose GPU on an FPGA that can display Quake (FuryGPU): https://www.youtube.com/@dbarrie/videos

Hey! I'm the developer of the FuryGPU, and it's very cool to see others working in a similar space - Doom is neat but Quake is where 3D graphics really came into their own.

For anyone curious, FuryGPU is a full mid-90s-era GPU built from the ground up which covers the entire stack of both hardware and software development. I designed a custom PCB to expose the PCIe lanes on the Kria K26 (Zynq UltraScale+) FPGA and allow for fast host-GPU communication, built and optimized the actual GPU hardware, wrote both an entirely custom graphics API to drive it as well as Windows drivers to have the OS interact with the hardware correctly, and finally ported Quake to that new API. It's been about three years of work and is still my first and only FPGA project.

Once everything is "finished," I do plan on open-sourcing the project. When and what that will look like depends on a lot of factors, but I've nearly ticked all the boxes I set for myself originally so it probably won't be too far in the future.

Thanks for the plug!

That's amazing!

What does the API look like? I see you're calling it FuryGL so it must have some roots in OpenGL? What did you have to change because of the underlying hardware? compared to OpenGL? Compared to what a software rasterizer API would look like? You probably are familiar with Glide?

It's actually modeled very closely after Vulkan, but I couldn't think of a clever re-wording that would fit that and "Fury" together. I would have taken Vulkan's API as-is, but the hardware itself is fixed-function and does not support shaders, which Vulkan's API takes for granted; if you've seen Vulkan applications, it's nearly identical except that the pipelines do not include shaders. The way Vulkan (and D3D12) build and submit command buffers very closely matches how the hardware actually works, so it felt like a good fit.

If the hardware were ever to support actual shaders, I would be writing a full D3D-driver stack for it as Windows would then be able to utilize the GPU as a "real" GPU, rather than as just a display controller. As things are now, Windows has no idea that the device can do anything other than display a pre-composited desktop. When an application wants to utilize its 3D rendering capabilities, the driver actually does a mode swap similar to how the old Voodoo cards used to work - the OS still thinks it's rendering the desktop, but the hardware is actually displaying the application's content.

I guess in Linux it would be so much easier. KMS for modswitching and DRI for 3d stuff.

Question for both of you: What would it take for the MRISC32 CPU to use FuryGPU as a peripheral over PCIe?

If the FPGA contains a hard PCIe IP that can act as a host and the proper transceivers and the CPU implemented all of the necessary things to interface with it, it'd be about as difficult as writing a driver for any other machine. Actually building a board for the FPGA with all of the required power supplies, peripherals, and a PCIe host is not a trivial undertaking however, and an FPGA with a hard PCIe controller generally isn't cheap!

It would be much simpler to just put the FuryGPU and the MRISC32 CPU on the same FPGA, I guess.

I love this. Do you have a blog or only videos?

I started off creating a 2d focused GPU out of an esp32 for use with microcontrollers to accelerate graphics for resource constrained, and have "faked" 3d by drawing single color shaded triangles.

Ive been ping pinging between creating software 3d rendering support and learning digital circuits to graduate it into a full fpga based system.

Believe it or not, I'm looking for this exact kind of thing. Also, a custom SoC that is close to x86. I am not a fan of modern x86, would want something closer to the original Pentium Pro.

Does FuryGPU have a homepage or something? Can't find anything relevant.

Some resources for noobs looking to enter this space would also be appreciated.

I'm really impressed by your work! I'd love to see more details (like the code ;-) ) in the future.

Perhaps meaningless, but a cool demo would be the FuryGPU being driven by an MRISC32 CPU. Everything custom FTW.

Very, very impressive works, both MRISC32 and FuryGPU (which I just learned about, love the idea of a FPGA-retro-GPU that could go in a modern computer!). It's hard to overstate the amount of passion, care and technical expertise that go into such projects.

I'm the author of 'q5k' (Quake viewer in 5K LUTs) and so I wanted to say Hi to my fellow Quake-on-FPGA enthusiasts. Thanks for the mention, and looking forward to the next steps of your projects!

PS: Q5k is of course much, much slower (runs on a small $10 ice40 up5k FPGA), and only a viewer. The renderer is custom using fixed-point only. Unlikely I'll be ever able to run the full game at any decent speed, but I'm surely going to try :) For anyone interested, here's the repo of q5k and doomchip-onice: https://github.com/sylefeb/tinygpus

Thanks a bunch for the link! I love how you fit a quake renderer onto such a small device (having a demo scene size coding history, I enjoy the challenge of a constrained target and I'd like to do something similar with the MRISC32 ISA some time - e.g. an "MRISC32-A0").

Nyuzi GPGPU had demo of Quake

In the mean time, there's the FPGA "DOOM chip"

https://github.com/sylefeb/Silice/blob/master/projects/doomc...

https://www.youtube.com/watch?v=2ZAIIDXoBis

Love the idea of Quake specific hardware. We're still a few years away from having 1khz oled (or faster) displays but i am sure they'll arrive by the time I won't be able to make use of them due to old age. But I want to see it.

If course, all that goodness would be for nothing if we don't bake a proper version of the game. It's been a while but I think Quake server tickrate is likely to be on the low side.

Quick searching confirms that. From https://speeddemosarchive.com/quake/qdq/articles/WallHug/fra...

"In normal Quake, the server framerate is controlled by a console variable called sys_ticrate. This measures the amount of time each frame should last, and its default value is 0.05 (that is, twenty frames per second.) Most server administrators don't bother to change this."

I say someone should take your idea, fix Quake 3 to run at 1khz on both the client and the server, then bake that into fpga. I would buy it

> We're still a few years away from having 1khz oled (or faster) displays

Fine. We can always go with 240 fps AR with 8K HDR 180-degree FoV instead.

How would mods work? That's half the fun of quake...I suppose since quakevm itself is open source maybe run that on hardware and allow software extensions.

surely we could already do 1khz displays with OLED, but i assumed that the bandwidth required to meet that wouldn't be available on any of todays display outputs.

True, LG is releasing OLED monitors this year that reach 480hz but at 1080p (240hz at 4K).

Interesting that 4x the pixels only requires a halving of the refresh rate

Might be due to compression of frames as its sent over the cable (called digital stream compression iirc

I think they're going to have to adjust a lot more than just.

Let's see. Bandwidth seems to be the main problem but so far no one has shipped a 640x480bay 2khz or whatever. Who knows

Even an old program like Quake has many lines of code, right? Maybe a more plausible setup could be softcore+Quake specific instructions? Plus the author will get to write their own fast approximate square root instruction which is neat.

There are efforts to bring FOSS FPGA tooling. Check out Yosys (still far from as mature as LLVM though). But yes, I agree...

Open source FPGA tooling (F4PGA previously called SymbiFlow): https://f4pga.readthedocs.io/en/latest/

Ha I came here to ask about the potential for this and its the top comment.

Is there a name for this that I can search for more info on?

Could Windows/macOS one day ship on an FPGA like this?

Realistically: No that won't happen (sorry to disappoint you).

There are some niche demos, like a HW raytracer on an FPGA, but full systems is not realistic. General purpose code simply is a bad match for FPGAs.

Reply on news.ycombinator.com