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

21–30 of 32 posts

Re: Real-Time Ray-Tracing in WebGPU

#21

Post by royjacobs »

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…

Would that be a textual format that is essentially already compiled, or do you mean a textual format that is just source (like glsl)? The latter historically has had a bunch of issues with compiler incompatibility across vendors, so I assume you mean the former. But what is then the benefit of having essentially textual bytecode compared to binary?

Re: Real-Time Ray-Tracing in WebGPU

#22

Post by flohofwoe »

Jasper_ wrote: post #17
Keverw wrote: post #8

Earlier quoted context omitted.

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/…

I don't agree. The Vulkan and D3D12 APIs didn't have to be so programmer hostile, they're just badly designed APIs.

Thankfully, WebGPU took a lot of inspiration from the Metal API, and less from Vulkan and D3D12, and thus is usable without a "sanity layer".

Re: Real-Time Ray-Tracing in WebGPU

#23

Post by mschuetz »

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…

> there should be a tipping point where ray-tracing is more efficient than rasterization.

How so? Wouldn't both scale logarithmically with respective hierarchical acceleration structures? In what way does ray tracing scale better?

Re: Real-Time Ray-Tracing in WebGPU

#24

Post by inferiorhuman »

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…

there should be a tipping point where ray-tracing is more efficient than rasterization

In a previous life I worked for a company that was developing real-time ray tracing products. The founders had this magical algorithm but the catch was that dedicated ray tracing hardware was almost never successful because by the time the dedicated hardware made it to market general purpose processors had caught up.

However, what it seemed like to me was that the founders had developed a blazing fast algorithm that cut a ton of corners. Each time they'd fix an edge case the product got slower. Regardless they were moderately successful and might still be around.

And then there was the time I accidentally nuked all of our internal infrastructure in the middle of a product release demo.

Re: Real-Time Ray-Tracing in WebGPU

#25

Post by mantap »

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…

I do agree that a text based format is better in many cases. A byte code format would suck for debugging. People want to type their shaders directly into a browser window and have compilation happen in less than a frame. Shader compilation needs to be fast enough that it takes less than a frame because people do have things like colour pickers in their in-browser shader editor where you can drag the value around and it changes the text. To emulate this without browser support would require a lot of work.

But that text based format should be GLSL because that's what everybody's shaders are already written in for WebGL and obviously there will be a transition period where both WebGL and WebGPU will have to be supported (which is easy since most people use a library such as Babylon or Three).

Having a text based language that is not GLSL is pointless IMO. You have the drawbacks of both a bytecode language (need to ship a compiler with the page to compile GLSL into WSL) and textual formats.

As an outsider the most logical option is to support both GLSL and SPIR-V.

Re: Real-Time Ray-Tracing in WebGPU

#26

Post by cuu508 »

inferiorhuman wrote: post #24
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…

there should be a tipping point where ray-tracing is more efficient than rasterization In a previous life I worked for a company that was developing real-time ray tracing products. The founders had this magical algorithm but the catch was that dedicated ray tracing hardware was almost never successful because by the time the dedicated hardware made it to market general purpose processors had caught up. However, what…

> However, what it seemed like to me was that the founders had developed a blazing fast algorithm that cut a ton of corners.

No idea if it's your company, but this bit sort of reminds me of Euclideon demos: https://www.youtube.com/watch?v=DrBR_4FohSE

Re: Real-Time Ray-Tracing in WebGPU

#27

Post by pjmlp »

flohofwoe wrote: post #22
Jasper_ wrote: post #17

Earlier quoted context omitted.

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/…

I don't agree. The Vulkan and D3D12 APIs didn't have to be so programmer hostile, they're just badly designed APIs. Thankfully, WebGPU took a lot of inspiration from the Metal API, and less from Vulkan and D3D12, and thus is usable without a "sanity layer".

That sanity layer ended up being yet another way to foster adoption of middleware engines.

Re: Real-Time Ray-Tracing in WebGPU

#28

Post by pixelpoet »

corysama wrote: post #16
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 i…

I (lycium) wrote a bunch on this topic on a recent thread on reddit r/hardware, with many similar points: https://www.reddit.com/r/hardware/comments/enn41z/when_do_yo...

Re: Real-Time Ray-Tracing in WebGPU

#29

Post by sitkack »

corysama wrote: post #16
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 i…

Isn’t < 1 day per pixel totally ok because of the DNN denoising kernels? One could even train the de loser on offline computer frames indicative of the specific scenes.

Re: Real-Time Ray-Tracing in WebGPU

#30

Post by raphlinus »

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…

As someone who really wants to use this stuff, I just want mommy and daddy to stop fighting. I personally lean towards a SPIR-V approach for a number of reasons, including faster shader compilation and a more unified ecosystem. I also see the advantages of a high level text format, but feel like that could get polyfilled in 100k or so of wasm in the most important cases.

But it's clear that either approach can work. From what I'm seeing so far, flipping a coin and doing "disagree and commit" would be a healthier process than what's going on right now.

Post reply on HN