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

141–150 of 186 posts

Re: WebGPU and WSL in Safari

#141

Post by egeozcan »

paulddraper wrote: post #124
gok wrote: post #103

Earlier quoted context omitted.

> There is almost no cost to the platform developers to add new APIs To anyone who has ever spent time working on a platform API this is deeply insulting. > …the costs are borne by the application developers. Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users. This is literally the attitude that lead to Java applets and then Flash, then later mistakes like Web SQL and (P)Na…

WebSQL wasn't a mistake. It make an enormous amount of existing code available on the web. It just wasn't agreed to by Firefox because it didn't have enough JS.

It wasn't agreed on because it was not standardized and most importantly, because there were no alternative implementations. SQLite is amazing but accepting a single implementation as standard is a huge dependency. I was very sad to see it getting dropped but it had to be.

Re: WebGPU and WSL in Safari

#142

Post by saagarjha »

gok wrote: post #103
pcwalton wrote: post #55

As a cross-platform graphics developer who is currently knee-deep in papering over platform incompatibilities, what I mostly care about at this point is compatibility . I don't care about shader size or compilation time, as long as both are reasonable. I do care about having yet another shading language to cross-compile to. Please, everyone, just use something that already exists. It is frustrating how the big player…

> There is almost no cost to the platform developers to add new APIs To anyone who has ever spent time working on a platform API this is deeply insulting. > …the costs are borne by the application developers. Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users. This is literally the attitude that lead to Java applets and then Flash, then later mistakes like Web SQL and (P)Na…

> Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users.

I’m one of the most vehement proponents for the use of platform-specific UI toolkits here, but even I disagree with that this statement without qualification. Standards, in general, are a useful thing to have. We’ve occasionally seen (for example, in the case of application frameworks) that each platform doing their own thing has now made it so that the better experience for the user is the non-general API. But standardized interfaces (POSIX, OpenGL, JavaScript) when done right have been a boon for developers and end-users alike.

Re: WebGPU and WSL in Safari

#143

Post by saagarjha »

saurik wrote: post #137
slavik81 wrote: post #105

Earlier quoted context omitted.

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

> Apple does not believe in static linking, their SDK doesn't have a way to work around this

Apple isn’t alone this regard; as far as I can tell Windows does this too because they don’t commit to a stable syscall interface like Linux does. That being said, you may find Apple’s official stance on statically linking your binaries amusing: https://developer.apple.com/library/archive/qa/qa1118/_index...

In general, Apple links a lot of things to their OS releases: while their toolchains are distributed separately they’re practically tied to one or two major OSes unless you engage in hacks to make them continue working. And the languages which they exercise significant control over (namely Swift and Objective-C) are often tied to OS versions.

Re: WebGPU and WSL in Safari

#144

Post by saagarjha »

ericflo wrote: post #110
TazeTSchnitzel wrote: post #88

Earlier quoted context omitted.

If we can compile GLSL, GLSL ES, HLSL and OpenCL C to SPIR-V, and we can use SPIR-V in OpenGL, Vulkan and OpenCL, then why on earth can't WebGPU just use SPIR-V? If it's not safe enough, then define a safe subset or safety extensions with strict validation. If it's not Appley enough, then write a Metal Shading Language to SPIR-V compiler (the reverse has already been done). Hell, if SPIR-V really is too low-level, GL…

Because Apple hates Khronos

Considering that Apple is a Promoter Member of the Khronos Group, I doubt this.

Re: WebGPU and WSL in Safari

#146

Post by TazeTSchnitzel »

saagarjha wrote: post #144
ericflo wrote: post #110

Earlier quoted context omitted.

Because Apple hates Khronos

Considering that Apple is a Promoter Member of the Khronos Group, I doubt this.

They created OpenCL and supported OpenGL (ES) as the only graphics API on their platforms for years, but now they have dumped both open standards in favour of their own proprietary ones.

Re: WebGPU and WSL in Safari

#147

Post by The_rationalist »

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

The intersection of hardware features is greater than the intersection of Vulkan, dx12 and metal features. Moreover, hardware features should be queryable at runtime

Re: WebGPU and WSL in Safari

#148

Post by The_rationalist »

om2 wrote: post #114
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…

Turns out that the intersection is already a huge advance over WebGL, and that much of the stuff outside the intersection is of marginal value or even outright regrettable.

How can you make such a massive claim? Did you read all of Vulkan extensions?

Re: WebGPU and WSL in Safari

#149

Post by KenanSulayman »

Jasper_ wrote: post #24
flohofwoe wrote: post #20

Earlier quoted context omitted.

The performance comes mainly from a different programming model, not primarily from direct access to GPU resources (although the access is more direct than before). The potentially expensive stuff has basically been moved out of the render loop, and into the initialization phase. For instance, when you create a shader in WebGL, that shader may be patched and recompiled internally when it is used for different situati…

If you are 100% careful, you can get equal performance with a good WebGL implementation, like ANGLE, and good user code. But this is very difficult, and requires very careful programming. I built a WebGPU-like layer [0] for my 3D web application https://noclip.website , so I get some of the performance benefits today, under ANGLE, but WebGPU has these best-practices baked in, so everyone will see an increase. [0] htt…

This is incredible.. I spent over an hour going through all the rooms of Banjo-Kazooie; I always loved that game. The performance is great!

Great job you did there..

Re: WebGPU and WSL in Safari

#150

Post by pjmlp »

saagarjha wrote: post #142
gok wrote: post #103

Earlier quoted context omitted.

> There is almost no cost to the platform developers to add new APIs To anyone who has ever spent time working on a platform API this is deeply insulting. > …the costs are borne by the application developers. Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users. This is literally the attitude that lead to Java applets and then Flash, then later mistakes like Web SQL and (P)Na…

> Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users. I’m one of the most vehement proponents for the use of platform-specific UI toolkits here, but even I disagree with that this statement without qualification. Standards, in general, are a useful thing to have. We’ve occasionally seen (for example, in the case of application frameworks) that each platform doing their own…

All those standards are good examples of write once, debug everywhere, implement multiple code paths tailored by bugs, OEM specific features and workarounds.

Making the end result in industrial code bases hardly much different from implementing multiple times.

Post reply on HN