Live data from Hacker News

UE5 Nanite in WebGPU

github.com

51–60 of 117 posts

Re: UE5 Nanite in WebGPU

#51
post #2

It's cool that it kind of works, but they had to make some nasty compromises to get around WebGPUs lack of 64 bit atomics. Hopefully that will be added as an optional extension at some point, hardware support is almost ubiquitous on desktop-class hardware at least (AMD and Nvidia have had it forever but Apple has only had it since the M3).

Since the M2

Re: UE5 Nanite in WebGPU

#53
post #43
post #35

Earlier quoted context omitted.

It may not be based on what the mesh's creator considered repetition, but repetition is encoded within the mesh. Not sure if the mesh builder discovers some of the repetition itself. Look at a terrain example: https://www.youtube.com/watch?v=DKvA7NZRUcg

I'm not seeing what you claim to be seeing in that demo video. I see a per-triangle debug view, and a per-cluster debug view. None of that is showing repetition.

If there wasn't repetition, you'd need a really huge GPU for that scene at that level of detail.

Re: UE5 Nanite in WebGPU

#54
post #51
post #2

It's cool that it kind of works, but they had to make some nasty compromises to get around WebGPUs lack of 64 bit atomics. Hopefully that will be added as an optional extension at some point, hardware support is almost ubiquitous on desktop-class hardware at least (AMD and Nvidia have had it forever but Apple has only had it since the M3).

Since the M2

Right you are, 64 bit atomics were added with the Apple8 GPU but only in M-series chips (M2 and up) and then the Apple9 GPU made it universal (A17 Pro and up).

https://developer.apple.com/metal/Metal-Feature-Set-Tables.p...

Re: UE5 Nanite in WebGPU

#55
post #45

Wow, I can't remember the last time I read a project summary with so much jargon - I literally didn't understand anything: > UE5's Nanite implementation using WebGPU. Includes the meshlet LOD hierarchy, software rasterizer and billboard impostors. Culling on both per-instance and per-meshlet basis.

UE5 Nanite -> https://dev.epicgames.com/documentation/en-us/unreal-engine/... WebGPU -> https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API Meshlet -> https://developer.nvidia.com/blog/introduction-turing-mesh-s... LOD -> https://en.wikipedia.org/wiki/Level_of_detail_(computer_grap... Software rasterizer -> https://en.wikipedia.org/wiki/Rasterisation ("software" means it runs on the CPU instead of GPU) Billbo…

> ("software" means it runs on the CPU instead of GPU)

no, in this context it means that the rasterisation algorithm is implemented in a compute kernel, rather than using the fixed hw built into the gpu. so rasterization still happens on the gpu, just using programmable blocks.

Re: UE5 Nanite in WebGPU

#56
post #30

Honest question: It is calim that software rasterizer is faster than hardware one. Can someone explain me why? isn't the purpose of the GPU to accelerate rasterization itself? Unless is a recent algorithm or the "software rasterizer" is actually running on the GPU and not the CPU I don't see how

I thought it was a software rasterizer running inside fragment shader on the GPU. Not actually on the CPU. I need to watch that video again to be sure, but I cant see how a CPU could handle that many triangles.

To be precise, this is running in a compute shader (rasterizeSwPass.wgsl.ts for the curious). You can think of that as running the GPU in a mode where it's a type of computer with some frustrating limitations, but also the ability to efficiently run thousands of threads in parallel.

This is in contrast to hardware rasterization, where there is dedicated hardware onboard the GPU to decide which pixels are covered by a given triangle, and assigns those pixels to a fragment shader, where the color (and potentially other things) are computed, finally written to the render target as a raster op (also a bit of specialized hardware).

The seminal paper on this is cudaraster [1], which implemented basic 3D rendering in CUDA (the CUDA of 13 years ago is roughly comparable in power to compute shaders today), and basically posed the question: how much does using the specialized rasterization hardware help, compared with just using compute? The answer is roughly 2x, though it depends a lot on the details.

And those details are important. One of the assumptions that hardware rasterization relies on for efficiency is that a triangle covers dozens of pixels. In Nanite, that assumption is not valid, in fact a great many triangles are approximately a single pixel, and then software/compute approaches actually start beating the hardware.

Nanite, like this project, thus actually uses a hybrid approach: rasterization for medium to large triangles, and compute for smaller ones. Both can share the same render target.

[1]: https://research.nvidia.com/publication/2011-08_high-perform...

Re: UE5 Nanite in WebGPU

#57

Honest question: It is calim that software rasterizer is faster than hardware one. Can someone explain me why? isn't the purpose of the GPU to accelerate rasterization itself? Unless is a recent algorithm or the "software rasterizer" is actually running on the GPU and not the CPU I don't see how

A couple reasons

1. HW does 2x2 blocks of pixels always so it can have derivatives, even if you don't use them..

2. Accessing SV_PrimitiveID is surprisingly slow on Nvidia/AMD, by writing it out in the PS you will take a huge perf hit in HW. There are ways to work around this, but they aren't trivial and differ between vendors, and you have to be aware of the issue it in the first place! I think some of the "software" > "hardware" raster stuff may come from this.

The HW shader in this demo looks wonky though, it should be writing out the visibility buffer, and instead it is writing out a vec4 with color data, so of course that is going to hurt perf. Way too many varyings being passed down also.

In a high triangle HW rasterizer you want the visibility buffer PS do a little compute as possible, and write as little as possible, so it should only have 1 or 2 input varyings and simply writes them out.

Re: UE5 Nanite in WebGPU

#58
post #17

Oh, nice. Third party implementations of Nanite playback. Nanite is a very clever representation of graphics meshes. They're directed acyclic graphs rather than trees. Repetition is a link, not a copy. It's recursive; meshes can share submeshes, which in turn can share submeshes, all the way down. It's also set up for within-mesh level of detail support, so the submeshes drop out when they're small enough. So you can…

> Making a nanite mesh is complicated, with a lot of internal offsets for linking, and so far only Unreal Engine's editor does it.

meshoptimizer [1] is an OSS implementation of meshlet generation, which is what most people think of when they think of "Nanite's algorithm". Bevy, mentioned in a sibling reply, uses meshoptimizer as the generation tool.

(Strictly speaking, "Nanite" is a brand name that encompasses a large collection of techniques, including meshlets, software rasterization, streaming geometry, etc. For clarity, when discussing these concepts outside of the context of the Unreal Engine specifically, I prefer to refer to individual techniques instead of the "Nanite" brand. They're really separate, even though they complement one another. For example, software rasterization can be profitably used without meshlets if your triangles are really small. Streaming geometry can be useful even if you aren't using meshlets. And so on.)

[1]: https://github.com/zeux/meshoptimizer

Re: UE5 Nanite in WebGPU

#60
post #24

Name and description are very confusing and a trademark violation since despite the claims it seems to be completely unrelated to actual Nanite in UE5, just an implementation of something similar by a person unaffiliated with UE5. There is also Bevy's Virtual Geometry that provides similar functionality and is probably much more useful since it's written in Rust and integrated with a game engine: https://jms55.github…

I don’t think it’s really an issue. It’s clear from the readme that it’s an implementation.

If I made an “implementation of OpenAI’s GPT-3 in JS” you would understand that to mean I took the architecture from the whitepaper and reimplemented it.

Post reply on HN