Live data from Hacker News

RT64: N64 graphics renderer in emulators and native ports

github.com

51–54 of 54 posts

Re: RT64: N64 graphics renderer in emulators and native ports

#51
post #50
post #46

Earlier quoted context omitted.

Having worked on some of the latter part of that era of GPUs, the "frontend" of the shader compiler was a pretty small fraction of the total time cost, most of it was in the later optimization passes that often extremely hardware specific (so not really possible at the level of DXBC). Especially as hardware started to move away from the assumptions used in designing it. I think a big part of the user-visible differen…

One advantage of contemporary bytecode implementations is that many optimizations can occur in the “middle end”—which is to say on the IR itself, before lowering to ISA.

Yes, many optimizations can be done at the vendor-neutral IR level, but my point is that on GPUs they tend to be some of the computationally less expensive ones - the vast majority of the compilers time (in my experience) was in levels lower than that, like register allocation (as on GPUs "registers" are normally shared for all waves - so there's trade offs in using fewer registers but allowing more waves, for example), or trying to reorder things to hide latency from asynchronous units or higher latency instructions. And all those are very hardware specific.

It's a classic example of the "first 50%" being relatively easy - like an "optimizing" compiler can get pretty good with pretty simple constant propagation/inlining/dead code elimination. But that second 50% takes so much more effort.

Re: RT64: N64 graphics renderer in emulators and native ports

#52

Earlier quoted context omitted.

> Compiling shaders directly from a high level representation to the GPU ISA only really happens on consoles. No, that's not correct. In fact, it's mostly the other way around. Consoles have known hardware and thus games can ship with precompiled shaders. I know this has been done since at least PS2 era since I enjoy taking apart game assets. While on PC, you can't know what GPU is in the consumer device. For example…

> Consoles have known hardware and thus games can ship with precompiled shaders. I know this has been done since at least PS2 era since I enjoy taking apart game assets. That's what I said. Consoles ship GPU machine code, PCs ship textual shaders (in the case of OpenGL) or some intermediate representation (DXIL, DXBC, SPIRV, ...)

Alright!, sorry for the misunderstanding on my part.

Re: RT64: N64 graphics renderer in emulators and native ports

#53
post #47
post #39

Earlier quoted context omitted.

It would be an interesting feedback loop to capture a screenshot of a game (sm64), determine the green texture is grass, update the texture realtime, take another screenshot, and iterate, having the game flesh itself out realtime as it’s being played.

Four years ago there was demo of exactly that in GTA5 https://www.ign.com/articles/experimental-ai-tool-makes-gta-...

was that a filter over the final render, or was it updating the assets, textures, polygons, and lighting behind the scenes?

Re: RT64: N64 graphics renderer in emulators and native ports

#54
post #38

Here's a 2022 video that shows it in action https://www.reddit.com/r/Games/comments/v42611/dario_on_twit...

Doesn't seem to be a noticeable improvement from N64-era graphics. It probably needs generative AI based upscaling to high resolution meshes, textures and realistic materials to actually achieve a quality improvement.

I need to emphasise that this is dramatically different. Comparing the first clip of OoT to [1], I see: - Higher framerate - Real-time lighting - Real-time shadows - Higher render resolution - Water ripples/splashes (unsure about these being new) - Widescreen, motion blur, etc.

If your contention is "they're not an improvement on the graphics, just changes", then we can agree to disagree, but they're otherwise incredibly noticeable!

[1]: https://www.youtube.com/watch?v=nySI72vRl_4

Post reply on HN