Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Real-Time Ray-Tracing in WebGPU

maierfelix.github.io

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Real-Time Ray-Tracing in WebGPU

#11

Post by modeless »

darknoon wrote: post #9

Hey, I really appreciate your work on these bindings. I have done a lot of work with Metal on iOS, and found it frustrating to start over from scratch when trying to combine graphics and deep learning (CUDA on Linux). It would be awesome to see a future where you can write high-performance GPU-driven apps in a cross-platform way with js/webgpu/wasm and slap in platform-specific UI, without bundling all of Unreal or U…

You may be interested in this Chromium fork that Intel is working on which adds a machine learning API, loosely modeled on Android's NNAPI: https://github.com/otcshare/chromium-src/commits/webml

It's not likely to be standardized as is, but the code demonstrates how to integrate something like this into Chromium. There's a Web ML community group that's working to figure out what could be standardized in this area. https://webmachinelearning.github.io/

Re: Real-Time Ray-Tracing in WebGPU

#12

Post by blurbleblurble »

91edec wrote: post #6

Is there any good WebGPU tutorials? I've been wanting to play around with graphics programming for a while and the web is such a perfect platform due to cross platform compatibility and lower barrier for entry.

I'm excited for it, but WebGPU is hardly close to ready yet. Right now they're still negotiating the shader language.

But if you want to learn some graphics programming on the web, I really recommend trying out regl. It's a great way to learn about graphics primitives without getting bogged down in the WebGL API directly.

https://github.com/regl-project/regl

Re: Real-Time Ray-Tracing in WebGPU

#13

Post by Arelius »

hinkley wrote: post #5

I read Practical Parallel Rendering (1st Edition: 2002) quite a long time ago, on someone's recommendation. There's quite a substantial section on how to build and manage effective job queues that's worth a read even if you don't do any CGI. But there's also a thesis in there: given that scene descriptions grow in size much faster than screen resolution increases, there should be a tipping point where ray-tracing is…

Yes, so the primary test, "Does this triangle cover this pixel" is the same between rasterization and ray-tracing. So the fundamental difference is the outer loop.

Rasterization goes for each triangle, which pixels does this intersect, whereas for ray-tracing it's for each pixel which triangles does this intersect.

Clearly, this allows us to build lookup data structures over the inner loop. So back of the hand ray-tracing becomes more efficient when you have more triangles than pixels (give or take an order of magnitude or so due to algorithmic differences)

So, the complexity of real-time content development has slowed due to multiple of reasons, not the least of which being that rasterization (especially modern GPU rasterization with quad based shading) is poorly suited to scenes where polygons approach pixels in coverage. And more importantly, we've hit the polygon density where we appear to be getting better visual quality gains by spending cycles on improved shading rather than more polygons.

Then add in the transition to 4K and we get a much larger pile of pixels once again changing the math all over again.

I don't know what this means for the future. I suspect we won't see much increase in scene complexity until we get to the cliff where ray-tracing is then viable, then I imagine scene complexity for real-time scenes will make a big jump.

Keep in mind, what you read is with offline CGI in mind. And we've already hit that tipping point for offline rendering. Even the last major rasterization hold-out (PRMAN) has switched to path-tracing even primary rays. It's just that real-time rendering is a bit of a different beast.

Re: Real-Time Ray-Tracing in WebGPU

#14

Post by blurbleblurble »

CountHackulus wrote: post #3

Now if only Apple would get off their high horse and allow SPIRV so that the WebGPU standard can go forward.

Totally! I share your frustration.

And I'm cautiously optimistic that the recent conversation the GPU Web working group had with the Khronos liaison will spur some SPIR-V progress.

https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...

The meeting notes also reveal a clue as to why Apple might be pushing WSL so hard:

> MS: Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that.

> NT: nobody is forced to come into Khronos’ IP framework.

Re: Real-Time Ray-Tracing in WebGPU

#15

Post by Jasper_ »

Arelius wrote: post #13
hinkley wrote: post #5

I read Practical Parallel Rendering (1st Edition: 2002) quite a long time ago, on someone's recommendation. There's quite a substantial section on how to build and manage effective job queues that's worth a read even if you don't do any CGI. But there's also a thesis in there: given that scene descriptions grow in size much faster than screen resolution increases, there should be a tipping point where ray-tracing is…

Yes, so the primary test, "Does this triangle cover this pixel" is the same between rasterization and ray-tracing. So the fundamental difference is the outer loop. Rasterization goes for each triangle, which pixels does this intersect, whereas for ray-tracing it's for each pixel which triangles does this intersect. Clearly, this allows us to build lookup data structures over the inner loop. So back of the hand ray-tr…

Rasterization has some niceties for things like cache coherency. Since you're rasterizing a triangle at a time, all with the same shaders, textures, and buffers, SIMD techniques used in GPUs is very effective. But when you have ray-tracing, any ray can hit any triangle. If you cast 64 rays and each one hits a different triangle, you lost your entire parallelism. You possibly have to give up on SIMD if the material models between the triangles are different.

For this reason, and for the reason of real-time ray budgets barely approaching 1 ray per pixel at 1080p on the highest cards, ray-tracing tends to mostly be used for specular effects at this time.

Even in non-real-time workloads, this was a massive time sink until ray sorting and batching entered the common practice, collecting rays that hit a single coherent area to be processed at once. And the current RTX model has no strong support for ray batching.

Re: Real-Time Ray-Tracing in WebGPU

#16

Post by corysama »

hinkley wrote: post #5

I read Practical Parallel Rendering (1st Edition: 2002) quite a long time ago, on someone's recommendation. There's quite a substantial section on how to build and manage effective job queues that's worth a read even if you don't do any CGI. But there's also a thesis in there: given that scene descriptions grow in size much faster than screen resolution increases, there should be a tipping point where ray-tracing is…

"Practical Parallel Rendering" is a great book for anyone. It really is "Parallel Work Distribution Options: The Book".

The argument that "Ray tracing is logarithmic in scene complexity while rasterization is linear. Therefore, ray tracing will win eventually!" ignores the fact that rasterizers also use hierarchical graphs to maintain logarithmic complexity just like ray tracers do. You could make the same argument if you compared a well-designed rasterization-based system vs. a naive ray tracer that brute-forces every triangle vs. every pixel.

The difference is really a focus on local vs. non-local data. Rasterizers focus on preparing data ahead of time so that it can be directly indexed without searching. Ray tracers focus on making global searching as fast as possible. Rasterizers do more work at the start of a frame (rendering shadow, reflection, ambient occlusion maps). Ray tracers do more work in the middle of the frame (searching for shadowing/reflecting/occluding polygons).

It's wonderful that we finally have both accelerated in hardware. HW ray tracing still has a very long way to go. Currently, budgets are usually less than 1 ray per pixel of the final frame in real time apps! Figure that out how to use that effectively! :D But, it still opens up many new possibilities.

Re: Real-Time Ray-Tracing in WebGPU

#17

Post by Jasper_ »

Keverw wrote: post #8
cogman10 wrote: post #7

Earlier quoted context omitted.

It's barely got any support ATM. https://github.com/gpuweb/gpuweb/wiki/Implementation-Status I doubt you'll see a lot of good tutorials for it until you start seeing it land in stable versions of browser (or even nightly builds tbh). While starting to show it's age, WebGL should have a lot of tutorials and you can start working with it today.

I wonder if people will use WebGPU directly or use a higher level framework/library such as Babylon? Looks like it has support for it but doesn't seem everything is supported yet but haven't personally played with it.

I'm of the opinion that WebGPU should try not to be a friendly API on its own, but instead practically mandate a framework on top. This is the philosophy that the newer APIs like Vulkan/D3D12 adopt; that you should have a higher-level renderer driving it that's able to reason about your entire scene graph. I've suggested as much to the WG before, who roughly seem to agree.

[0] https://github.com/gpuweb/gpuweb/issues/171

Re: Real-Time Ray-Tracing in WebGPU

#18

Post by windoze »

Jasper_ wrote: post #15
Arelius wrote: post #13

Earlier quoted context omitted.

Yes, so the primary test, "Does this triangle cover this pixel" is the same between rasterization and ray-tracing. So the fundamental difference is the outer loop. Rasterization goes for each triangle, which pixels does this intersect, whereas for ray-tracing it's for each pixel which triangles does this intersect. Clearly, this allows us to build lookup data structures over the inner loop. So back of the hand ray-tr…

Rasterization has some niceties for things like cache coherency. Since you're rasterizing a triangle at a time, all with the same shaders, textures, and buffers, SIMD techniques used in GPUs is very effective. But when you have ray-tracing, any ray can hit any triangle. If you cast 64 rays and each one hits a different triangle, you lost your entire parallelism. You possibly have to give up on SIMD if the material mo…

I would have thought that for physically based shaders, most polygons are the same shader with different material parameters, wouldn't that allow SIMD techniques to continue to work?

Re: Real-Time Ray-Tracing in WebGPU

#19

Post by om2 »

blurbleblurble wrote: post #14
CountHackulus wrote: post #3

Now if only Apple would get off their high horse and allow SPIRV so that the WebGPU standard can go forward.

Totally! I share your frustration. And I'm cautiously optimistic that the recent conversation the GPU Web working group had with the Khronos liaison will spur some SPIR-V progress. https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25... The meeting notes also reveal a clue as to why Apple might be pushing WSL so hard: > MS: Apple is not comfortable working under Khronos IP framework, because of dispute betwee…

We sincerely think a text-based language is better for the web. It’s honestly weird that anyone thinks a binary format is a good webby choice. Both our browser engine people and our GPU software people agree.

Khronos basically said in that meeting that it would be fine to fork SPIR-V, which would solve Apple’s and Microsoft’s issues with their IPR framework. We’ve also discussed using a textual form of the SPIR-V format. We’ve offered all sorts of compromises. It’s Google that isn’t willing to budge, even stating in a WebGPU meeting that they never even considered what compromises would be acceptable to them. Encourage Google to be open to meeting in the middle and maybe we will get somewhere.

Re: Real-Time Ray-Tracing in WebGPU

#20

Post by flohofwoe »

om2 wrote: post #19
blurbleblurble wrote: post #14

Earlier quoted context omitted.

Totally! I share your frustration. And I'm cautiously optimistic that the recent conversation the GPU Web working group had with the Khronos liaison will spur some SPIR-V progress. https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25... The meeting notes also reveal a clue as to why Apple might be pushing WSL so hard: > MS: Apple is not comfortable working under Khronos IP framework, because of dispute betwee…

We sincerely think a text-based language is better for the web. It’s honestly weird that anyone thinks a binary format is a good webby choice. Both our browser engine people and our GPU software people agree. Khronos basically said in that meeting that it would be fine to fork SPIR-V, which would solve Apple’s and Microsoft’s issues with their IPR framework. We’ve also discussed using a textual form of the SPIR-V for…

Why would a shader byte code standard prevent text based shaders?

The only difference would be that (runtime) compilation happens in an optional Javascript / WASM module instead of being baked into the standard and browsers, and Apple can ship such a WHLSL compiler with Safari, so that startup is faster there for WebGPU code which uses WHLSL shaders, but please don't force it on everybody else.

And the "web people" are used now to compile stuff for quite some time (see TypeScript, WebPack, JS Minifiers, etc etc). Just one more compile step won't make much of a difference, but offer a lot of freedom.

(I guess in the end, byte-code versus text representation isn't that much different, but it is important that it is a good compilation target, let's not repeat the long journey from transpiled JS to asm.js to WASM).

Post reply on HN