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

151–160 of 186 posts

Re: WebGPU and WSL in Safari

#151

Post by pjmlp »

ezoe wrote: post #108
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…

They have to implement the existing API or their own. The cost will be the same for both cases. For big platform vendors, almost no(extra) cost. On the other hand, we, the ordinary developer must pay the cost of supporting N APIs on M platforms. Every APIs carelessly invented by vendors just because almost no extra cost burden us all.

Hence middleware engines, with productive high level APIs, while using every feature across all boards, without having to deal with messy extensions.

AMDN and Khronos are still fighting to get the love of CAD industry, adding back OpenGL features, because after having to create Iris Inventor like APIs in-house, they aren't keen in switching to yet another low level API.

Re: WebGPU and WSL in Safari

#153

Post by Tobu »

Please let Apple's shader language die an early death.

Maybe they're on some ego trip to leave their mark in a more visible way than through shaping the shared effort in various places and want to have a big thing to call their own. Or maybe they just want to get some vendor lock-in.

But it's yet another slightly-incompatible, slightly-better slightly-worse alternative to the existing shader languages, and nobody wants to deal with that, just like nobody really wanted to care about Metal. Apple's tight control over their devices will probably force some people to build some kind of compatibility layer into their pipelines, but it won't have to be good, and it won't be the primary target.

Re: WebGPU and WSL in Safari

#154

Post by cromwellian »

Haven’t we been down this text based vs Bytecode avenue before? The same arguments were made with asmjs against Bytecode wireformat, and ultimately we ended up with wasm. WSL seems to be making the same arguments.

Re: WebGPU and WSL in Safari

#155

Post by pjmlp »

TazeTSchnitzel wrote: post #146
saagarjha wrote: post #144

Earlier quoted context omitted.

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.

Actually they created Quickdraw 3D, and only adopted OpenGL as the NeXT team came onboard.

Although they created and gave OpenCL 1.0 to Khronos, they were not happy with the path that Khronos was taking it and their support basically stagnated on OpenCL 1.0.

As side note Google is yet to support OpenCL on Android, instead just like they did with their Android Java, they decided to create their own flavour, Renderscript, which isn't compatible with OpenCL.

As for OpenGL ES, I bet they only did it, as they were trying to "play pretend" being another kind of Apple as survival mechanism, nowadays they don't need it any longer.

Finally, Metal is one year older than Vulkan, offers a modern API instead of plain old C, and contrary to Khronos, just like other platform vendors, Apple understands the value of providing nice frameworks and debugging tools to go along an API.

Re: WebGPU and WSL in Safari

#156

Post by pjmlp »

saurik wrote: post #138
om2 wrote: post #54

Earlier quoted context omitted.

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…

What you are describing is exactly shipping a compiler, the JIT compiler bundled in the .NET Framework and Core runtimes.

You cannot do that in .NET Native, for example.

Re: WebGPU and WSL in Safari

#157

Post by The_rationalist »

pjmlp wrote: post #134
greggman2 wrote: post #116

Earlier quoted context omitted.

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.

That's why it's versioned.. Webgpu could start from Vulkan 1.1 or the latest Vulkan version could be bumped to Vulkan 1.2 for marking it's the one used for webgpu.

Re: WebGPU and WSL in Safari

#158

Post by techdragon »

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

I don’t know if they hate the Khronos group, but they sure do seem to not care about them, or their standards. Pushing Metal, letting OpenCL languish, now this, it’s frustrating for people like me who have no time for learning multiple platform specific languages like these.

The only way I’m using any thing like this is through a tool or library or framework like Unreal Engine, where I just don’t have to care.

This is short term win long term loose, yes the platform specific programs look good now, but long run this stuff is going to be a negative as people look to avoid dealing with multiple platform specific frameworks.

I’m hoping the return of a proper Mac Pro is going to steer back against this trend. I’m reasonably confident that if third party gpu support is ok, then all of the work apple puts into optimisations on these Apple specific graphics languages is going to take a back seat, if NVidia are going to sell me a GPU for the Mac Pro, I’m confident that they care much more about CUDA than anything apple specific.

Re: WebGPU and WSL in Safari

#159

Post by pjmlp »

The_rationalist wrote: post #157
pjmlp wrote: post #134

Earlier quoted context omitted.

With extensions count growing every week. Good luck making sense of Vulkan in 10 years time.

That's why it's versioned.. Webgpu could start from Vulkan 1.1 or the latest Vulkan version could be bumped to Vulkan 1.2 for marking it's the one used for webgpu.

Except that OpenGL and WegGL already proven that there is what the paper says, what the driver states and what the GPGPU actually does.

Re: WebGPU and WSL in Safari

#160

Post by kvark »

TazeTSchnitzel wrote: post #98
kvark wrote: post #27

The article is pretty good at explaining why WebGPU is needed for the Web. It could probably be more clear about the fact that all browser vendors are developing this API (i.e. it's not Apple's thing, and never been, if you don't count the name borrowed from their earlier prototype) and have implementations in the works. For shading languages, it's not clear to me why GLSL-to-SPIRV would be so slow. Would be great to…

> A bigger question though that needs to be resolved is how to specialize SPIR-V shaders. Is the OpSpecConstant family not enough? Those exist specifically for specialisation.

My main problem with SPIR-V specialization today is that it doesn't affect the shader interface. For WebGPU, we don't want to validate presence of resources that the user doesn't need, we don't want to allocate registers for them in our pipeline layouts, etc. I think having this ability is critical.
Post reply on HN