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

181–186 of 186 posts

Re: WebGPU and WSL in Safari

#181

Post by om2 »

Jyaif wrote: post #139
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.

SPIR-V with full web safety rules and translation to native shader formats is not really simpler to implement than WSL with those same properties. People make these claims but the code doesn’t best that out.

There’s also a good chance that in the end the shader processing will be in a common library like ANGLE.

With GLAL the issues were much more about the drivers consuming a textual language than about the browser consuming a textual language.

Re: WebGPU and WSL in Safari

#182

Post by om2 »

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…

three.js does shader generation at runtime and I expect they don’t want to significantly increase their download size by adding a compiler, so a text-based language is likely better for frameworks like that. The calculus may be different for a game engine like Unity. In that case there is already an offline tool chain involved.

Re: WebGPU and WSL in Safari

#183

Post by DerekL »

pjmlp wrote: post #126
slavik81 wrote: post #102

Earlier quoted context omitted.

It's true, but for most applications, games consoles are not even a consideration. There's a mountain of programs that only target Windows, Linux, macOS, Android, and iOS or some subset thereof.

Doesn't change the fact that OpenGL was never available in all platforms, regardless how often one spreads that urban myth. Even on Mac OS it wasn't available, rather Quickdraw 3D was the API to go to. Had Apple been successful with their in house OS, and surely they wouldn't have cared about OpenGL.

Are you saying OpenGL wasn't on Mac OS before Mac OS X? That's not true. Apple released OpenGL for Mac OS 9 in 1999.

WWDC 1999: Mac OS 9 - A work in progress https://youtu.be/LkmSrCsKPLk?t=1360

Re: WebGPU and WSL in Safari

#184

Post by pjmlp »

pcwalton wrote: post #178
pjmlp wrote: post #127

Earlier quoted context omitted.

And it shows, given the lack of tooling versus what platform APIs offer out of the box. Instead of a modern API, frameworks, 3D model format, IDE support for debugging shaders, we get plain old C, extensions creep, and go search yourself for basic feature like displaying text or loading textures. Hardly an improvement on OpenGL status quo.

OK, of the criticisms of Vulkan I've heard, "it doesn't have a function for display text" is the weirdest one. I would be upset if Khronos did include a function for displaying text, because it would invariably be broken in numerous ways.

That attitude is why plenty of graphical developers rather adopt platform APIs instead, because we get the full package for anything graphics related, instead of learning to make fire with sticks.

I did my graduation thesis in OpenGL, hunting for libraries that kind of work together, and doing from scratch what every other OpenGL beginner has to go through, is no fun.

Every Vulkan book does the same, first set of chapters are tips about which libraries to hunt for.

The dark side allows for a better gratification on time to pixel, instead of rites of passage.

Something that Khronos has failed to learn with OpenGL and their Vulkan SDK proves that they didn't actually learn their lesson.

If Vulkan SDK was actually at the same level as DirectXTK, Metal Kit, 3DS SDK, PhyreEngine,GX2... maybe it would get more love from those us that rather embrace the dark side.

Re: WebGPU and WSL in Safari

#185

Post by pjmlp »

DerekL wrote: post #183
pjmlp wrote: post #126

Earlier quoted context omitted.

Doesn't change the fact that OpenGL was never available in all platforms, regardless how often one spreads that urban myth. Even on Mac OS it wasn't available, rather Quickdraw 3D was the API to go to. Had Apple been successful with their in house OS, and surely they wouldn't have cared about OpenGL.

Are you saying OpenGL wasn't on Mac OS before Mac OS X? That's not true. Apple released OpenGL for Mac OS 9 in 1999. WWDC 1999: Mac OS 9 - A work in progress https://youtu.be/LkmSrCsKPLk?t=1360

WWDC 1999 was after NeXT's acquisition, the engine was already rolling, adopting NeXTSTEP features.

Also note that Copland did not have any OpenGL support planned.

Re: WebGPU and WSL in Safari

#186

Post by nsthorat »

modeless wrote: post #85
zelly wrote: post #4

is tensorflow going to use this?

Tensorflow.js will probably add a WebGPU backend when WebGPU becomes widely available in browsers. But that won't by itself close the performance gap with native ML libraries. For that there is a new W3C community group specifically looking at ways of adding machine learning acceleration to the web: https://www.w3.org/community/webmachinelearning/

This backend work has already begun (and can run posenet, albeit still slower than WebGL): https://github.com/tensorflow/tfjs/tree/master/tfjs-backend-...
Post reply on HN