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

WebGPU and WSL in Safari

webkit.org

Post reply on HN
Print view View original

131–140 of 186 posts

Re: WebGPU and WSL in Safari

#131

Post by om2 »

Jasper_ wrote: post #62
pizlonator wrote: post #60

Earlier quoted context omitted.

> WSL tells you very little about how the language is actually executed. I do not see any explanation of, say, waves and quads, which will need to be spelled out explicitly when these things are added. It's a requirement for proper LOD selection for texturing, along with ddx/ddy. The spec has a semantics that describes that the language does when executed in great detail. It seems that your complaint is that there is…

> The spec has a semantics that describes that the language does when executed in great detail. Here's what the WSL specification says about loading a texture, one of the simplest possible features of a shading language, but one that introduces a lot of complexity (again, to load a texture requires calculating an LOD, which requires talking about derivatives and scheduling pixels and shader execution in terms of quad…

> The WebGPU working group does not currently have any participation from AMD or NVIDIA. Khronos and the SPIR-V working group do. I trust them to get these details right.

On the other hand, the SPIR-V working group has no participation from Apple or Microsoft (vendors of relevant platform APIs, relevant shading languages, and in Apple's case, of relevant GPUs).

You might argue that Apple should join the SPIR-V group but you could likewise argue that AMD and Nvidia should join the WebGPU group. After all, their voices would be valuable as to the API and not just the shader language. The barrier to entry to a W3C Community Group is also much lower.

Re: WebGPU and WSL in Safari

#132

Post by pjmlp »

markdog12 wrote: post #15
adossi wrote: post #9

Earlier quoted context omitted.

I just assumed that Apple exposed some API functionality in Webkit that allowed more efficient low-level usage of the GPU hardware. This leads me to believe that adoption of the WebGPU technology will probably fail to break out of the Apple ecosystem.

No, the other browser vendors are on board too. In the case of Apple, the API backend will be Metal. It'll be Vulkan or DX12 on other systems.

Or NVN, libGNM.

Re: WebGPU and WSL in Safari

#133

Post by pjmlp »

The_rationalist wrote: post #91
aseipp wrote: post #39

Earlier quoted context omitted.

It wasn't just Apple, even several Google engineers working on WebGPU agreed that simply mimicking Vulkan wasn't the right model. There are some notes here: https://docs.google.com/document/d/1-lAvR9GXaNJiqUIpm3N2XuGU... The bit about network transparency is the most interesting one IME (which, in this case, assumes the "network" is essentially a collection of intercommunicating system processes, not nodes), as well…

This is not about being a Vulkan fan. Not even about portability. The real issue is the one no one talk about. Webgpu is the intersection of features from Vulkan, directX 12 and metal. Which means that webGPU is a subset of Vulkan, metal and DX, by design it is less powerful than metal, less powerful than DX and less powerful than metal. By being an intersection, by design they've created a sub-par, non evolutive api…

Just like WebGL fails short of OpenGL ES, with less features and lower FPS count on the same hardware.

Re: WebGPU and WSL in Safari

#134

Post by pjmlp »

greggman2 wrote: post #116
The_rationalist wrote: post #91

Earlier quoted context omitted.

This is not about being a Vulkan fan. Not even about portability. The real issue is the one no one talk about. Webgpu is the intersection of features from Vulkan, directX 12 and metal. Which means that webGPU is a subset of Vulkan, metal and DX, by design it is less powerful than metal, less powerful than DX and less powerful than metal. By being an intersection, by design they've created a sub-par, non evolutive api…

WebGPU is for the Web. You're expected to be able to put up a webpage and have it run everywhere (as much as is possible). Vulkan is designed so you have to make paths for every differen type of hardware. That's a non-starter for the web

With extensions count growing every week.

Good luck making sense of Vulkan in 10 years time.

Re: WebGPU and WSL in Safari

#135

Post by om2 »

slavik81 wrote: post #105
xigency wrote: post #84

Earlier quoted context omitted.

Are there any technical obstacles to using GLSL with WebGPU? It's popular with some people. See: https://www.shadertoy.com/

It might be that browser vendors would be better at writing compilers than GPU vendors, but there were a lot of bugs in GLSL compilers. SPIR-V was introduced to be a simpler format for GPUs to ingest, letting you do the complex parsing up front on your machine (where it's easier to identify and fix problems). The other benefit was that changes could be made to improve the usability of the shading language without hav…

Browser vendors are a lot better at writing compilers than GPU vendors. Also there are fewer different browser engines than different GPU drivers so that also helps.

Re: WebGPU and WSL in Safari

#136

Post by xenadu02 »

atq2119 wrote: post #122
mehmetoguzderin wrote: post #81

The course of development with WebGPU initiative is breathtaking. The effort poured into the API is producing content that will be consumed by people that desire to study GPGPU applications. Included in the final specification or not, a well-tailored shading language is only of benefit to the GPGPU community, similar to how simultaneous existence of DirectX, Metal, Vulkan has been to the robustness of the abstraction…

The claim that the developers shaping the WSL specification are experts is questionable given that the actual experts in shading languages -- i.e., the implementers building GPU hardware -- are looking at SPIR-V and seem to be pretty frustrated by the NIH syndrome of the web developer community here.

Do you have some evidence for this assertion? Because Apple happens to make its own GPUs and shading language... a shading language that also runs on other people's GPUs. Seems like relevant expertise to me.

Re: WebGPU and WSL in Safari

#137

Post by saurik »

slavik81 wrote: post #105
xigency wrote: post #84

Earlier quoted context omitted.

Are there any technical obstacles to using GLSL with WebGPU? It's popular with some people. See: https://www.shadertoy.com/

It might be that browser vendors would be better at writing compilers than GPU vendors, but there were a lot of bugs in GLSL compilers. SPIR-V was introduced to be a simpler format for GPUs to ingest, letting you do the complex parsing up front on your machine (where it's easier to identify and fix problems). The other benefit was that changes could be made to improve the usability of the shading language without hav…

Hilariously, Apple actually considers the shift from C++98 to C++11 something that required an operating system upgrade (they purposefully shipped an ancient version of libstdc++ while disingenuously doing comparisons against only what they shipped, not what had come from upstream, for as long as they could until libc++ was reasonable, which debuted on macOS 10.7--where I will note it was horribly broken due to an LLVM optimizer bug in the specific clang build they used to compile it, so really it wasn't available until macOS 10.8--and as Apple does not believe in static linking, their SDK doesn't have a way to work around this; of course, you can, and I did--by getting the code for libc++, modifying it to use an underlying libstdc++ as the moral equivalent of libc++abi, and statically linking that, which worked great and is frankly what Apple should have done themselves during the transition period :/--it is notable that Apple didn't want people to: they really do mentally model that as an operating system upgrade, which to me is an amazing demonstration of how little they understand of the power and potential of decoupled toolchains).

Re: WebGPU and WSL in Safari

#138

Post by saurik »

om2 wrote: post #54
magicalist wrote: post #41

Earlier quoted context omitted.

But presumably if that was the eventually standardized format the compiler could ship with browsers, though, right? It just seems weird to compare against another format that hasn't been agreed to either but they shipped the compiler with the browser preview so people can test it. It should either be comparing sources or comparing (source + compiler to get it working in a shipping stable browser), not mixing the two.

The proposal from SPIR-V advocates is to not ship any high level language compiler with the browser. That could change, but currently no one is excited about accepting both a binary language and a text-based language.

Why would you expect people to ship a compiler though? Like: when I want to do runtime code generation on .NET, I don't concatenate strings containing C# and run them through a C# compiler... that would be madness!!... instead I use the APIs provided to do IL generation, which have been extremely amazing essentially since day one and provide unbounded flexibility over working with any specific textual language. If I really really wanted a compiler at runtime, maybe I want a different one, and I can then use differently models like F# or a Lisp variant... things that are much harder if someone insists I translate everything into some silly specific language :/.

Re: WebGPU and WSL in Safari

#139

Post by Jyaif »

greggman2 wrote: post #119

Random comment. I've monitored the discussions of WHLSL/WSL vs SPIR-V and I can't decide which side I'm on. I started in the SPIR-V camp. I liked the idea that WebGPU would just get "shader assembly language" and that would let a 1000 other higher level languages blossom. I also liked the idea that injesting assembly seemed easier and less code than injesting a higher level language. But, Apple had their original WHL…

Also, with SPIR-V the browsers are simpler, thus less likely to be buggy, incompatible, or have widely different performances.

All in all there's waaaaay more reasons to use SPIR-V.

Post reply on HN