Nintendo 64 Emulator Gaining Vulkan Rendering Support

[phoronix]

Phoronix: Nintendo 64 Emulator Gaining Vulkan Rendering Support

RetroArch is picking up a Nintendo 64 video plugin that makes use of the Khronos Vulkan graphics API...

http://www.phoronix.com/scan.php?page=news_item&px=Libretro-N64-Vulkan

[microcode]

And perhaps as things settle down, this will lead ultimately to better compatibility. :-)

[duby229]

Holy glitches Batman! This is cool news.

I expected it so many years ago though. I had this exact same conversation on HardOCP's forum like 12 years ago. There are plenty of people that have known about the problems with HLE plugins for years. It's not even fair to call it emulation, it doesn't even try to do equivalent translations. Instead they just try to "satisfy" the end result by whatever screwy means will make it run.

[bachchain]

This will be the first time most will be able to get anywhere close to playable speeds with an accuracy-based N64 video renderer.

Are you sure that's because of the API and not the rewrite?

[tarceri]

Are you sure that's because of the API and not the rewrite?

Looks like it's compute support and not Vulkan that give the real boost.

With this video renderer we have aimed for a GL 4.3 / Vulkan featureset in order to escape most of the bottlenecks and limitations that usually drags N64 emulation down. From now on, there will be two big remaining tasks to be done:

• We will have to port the code over to OpenGL 4.3+. Lower subsets of OpenGL won’t work as this renderer requires compute shader support.

[stiiixy]

From an end-user point of view, I plan on knocking up a cabinet or two (one stand up and one cocktail/coffeee-'table' with tilt-up screen) for every conceivable game out there, and what I would like to know is how good is the linux-side support for the majority of systems? And is there a decent front-end for linux, like GameEx?

Yes, yes, I know how to conduct searches, but I'd rather get input from people who have been floating around the scene for a long while. Saves me a bunch of time and getting technical feedback prior to mucking things up is always valued.

[Azpegath]

I don't get it, what's an accuracy-based video renderer, and why was it slow before? Shouldn't N64 games be extremely simple to emulate? I've never heard of this before, so be patient with me

[TechMage89]

I don't get it, what's an accuracy-based video renderer, and why was it slow before? Shouldn't N64 games be extremely simple to emulate? I've never heard of this before, so be patient with me

Basically, there are two approaches to emulation: high-level emulation (HLE) and low-level emulation (LLE).

High-level emulation basically tries to figure out what effect a game's code is trying to achieve (say, render this strip of polygons on screen with this color) and "translate" that into code that achieves the same effect natively on the hardware you're running on. This can be very fast, and often lets you do interesting things (e.g. render at a higher resolution than the original hardware supported or add effects). However, this compromises accuracy and compatibility, because if the game is using special tricks or tacking advantage of the particulars of the hardware it was programmed on, the emulator won't be able to figure out what it's trying to do, and you'll get a result that looks wrong, or maybe nothing at all.

Low-level emulation actually tries to run through the same process that the original hardware would. Basically, in this case you are actually simulating the way the hardware functions, often one operation at a time. This is a lot slower than high-level emulation, but it should operate exactly like the original hardware, or as near as anyone can figure out, so anything that works on the original hardware should work exactly the same on a low-level emulator. However, as you can imagine, simulating the full functionality of hardware is a lot more work, so it runs a lot slower.

In the case of the Nintendo 64, part of the challenge of emulating it is that it had a really unique GPU. The N64 GPU had programmable microcode, which basically means that a program could change how the GPU works on the fly. It was way more flexible than other GPUs of the day, more comparable to a modern GPU in that sense (although obviously a lot less powerful than a modern GPU). This, however, has made it very difficult to emulate, because there aren't a fixed set of functions it performs, but rather its functionality can be changed by altering the microcode. Therefore, if you wanted to accurately emulate the N64 GPU's functionality, you had to do it on CPU (which is still very slow).

However, with modern GPUs capable of general computation, it is now increasingly possible to use a modern GPU to emulate the N64 GPU. I'm not completely sure how their implementation works, but from their post, it seems like they're using GPU compute shaders to interpret and execute microcode originally written for the N64 GPU. This allows a modern GPU to accurately emulate the N64 GPU and run a much wider range of N64 games without rendering flaws.

[mudig]

This and the roadmap they present for N64 emulation makes me drool. Fantastic progress after a decade of stagnation!

[curaga]

I'm more excited about the improving homebrew status. New third-party N64 carts can finally be made affordably, there's gcc, and a homebrew lib that supports everything but 3d so far. The microcode is the hangup for that, too, since they can't use Nintendo's, SGI's, Rare's, or other microcode legally, and nobody has bothered to write their own yet.