Opaque political language is a major red flag for me.

[xorgy]

I realize that businesses have priorities and needs; but in my opinion the draft charter guards Apple Inc.'s business priorities above the excellence of the standard.

Specifically this passage:

A technology that does not follow a single native API, which reduces the difficulty of implementation on platforms that do not support the chosen native API.

Reads, to me, as: "A technology that does not follow a single native API," -> A technology which forsakes Vulkan, "which reduces the difficulty of implementation" -> to support "platforms that do not support the chosen API" -> Apple Inc.'s lack of interest in implementing Vulkan.

I don't mean to be overly critical, but I don't think technical compromises are a healthy start to a community; and I can almost guarantee that having no standard native API will make the work of every independent implementation much harder. Considering the shading language alone, this is the difference between shipping SPIR-V, and defining yet another abstract shading IR or language, four or more separate implementations of it, a whole new set of codegen tools, and more performance overhead. That's a lot to commit to in one sentence.

[xorgy]

@timofonic I wouldn't call iOS a niche; but all iOS devices have PowerVR GPUs, and all new [S]GXs (and all the PowerVRs Apple shipped in iPhones back to the 6, possibly the 5S) have Vulkan drivers. Every GPU that Apple ships in MacBooks and MacBook Pros has not just one but two or three Vulkan implementations, at least one of which is open source.

[GunpowderGuy]

This proposal would only add another layer of abstractionmost to what most engines already have Graphics api < plataform abstraction layer <Game engine < would become Graphics API < gpuweb < plataform abstraction layer < game engine

[xcube16]

There are already a number of cross platform tools for working with SPIR-V. I hope it will be supported.

[grorg]

Firstly, let's restrict this discussion to just the wording in the charter.

SPIR-V and the general choice for shader runtimes/languages is a separate discussion.

[mg-13]

Agreed. The only company that blocks Vulkan from availability on all platforms, yet bold enough to suggest that everyone should implement a new API. The ridiculous part is the goal of reducing the difficulty of implementation.

Also, as xorgy already stated, all of Apple's GPU vendors (AMD, ImgTec and Intel) support Vulkan on other platforms.

Apple should wake up, nobody will buy this. I'm pretty sure, Khronos would be glad to welcome Apple to participate in WebVulkan, though.

[grorg]

Replying to @xorgy 's comment.

but in my opinion the draft charter guards Apple Inc.'s business priorities above the excellence of the standard.

The charter was not designed to protect anyone's business. We shared it with multiple vendors before it was made public here.

The goal is an excellent standard. It seems that you're concluding that the only way to get to an excellent standard is by building on Vulkan. There are a few issues there:

• As you point out, Vulkan is not supported on Apple platforms. That's a significant portion of the market for a standard that is designed to be universal.
• But it isn't just Apple platforms. Microsoft Windows does not support Vulkan out of the box. There is no official Vulkan driver from Microsoft. It requires the end-user to install drivers from the GPU manufacturer, assuming they are available. It's not clear how supported those drivers are. Also, there are a lot of people who simply can't install 3rd-party drivers since they don't control their machine. That's another significant portion of the market who are locked out.
• Another platform without Vulkan support: ChromeOS
• Let's consider a system that does offer support for Vulkan: Android. In this case the driver comes from the hardware manufacturer, and many devices do not receive updates. It requires a device with the appropriate version of Android, and the hope that the driver doesn't have showstopping bugs.

So while Vulkan is a great attempt at a cross-platform API, it doesn't have the universal support required to use it as the basis for the Web. This is not a criticism of Vulkan.

I don't mean to be overly critical, but I don't think technical compromises are a healthy start to a community; and I can almost guarantee that having no standard native API will make the work of every independent implementation much harder.

I don't think there are any technical compromises. This API needs to run on the Web platform. Vulkan is not designed to run on the Web platform. Again, this isn't a criticism of Vulkan - it achieved its goal of exposing low-level control of the GPU and improved performance.

The Web has other priorities, such as safety and privacy. It's essential that a Web page can't crash your machine, or read content from another app. You don't get those guarantees from Vulkan.

Vulkan is also, in my opinion, too low-level for the Web. It requires a lot of information about the host memory architecture. This is not something that a Web developer can know about, since the content might be running on any machine. We also can't expose raw GPU memory to the Web.

So whatever API we come up with will have to be new, in that it won't look too much like an existing technology. It may be based on Vulkan's design - that's really up to the group to decide.

I'll also add that this isn't just my position. The other browser engine developers have come to the same conclusion.

[grorg]

A shorter version of my comment above would be:

If you think Vulkan is the appropriate starting point for a new Web GPU API, then please explain why. No one has ruled anything out.

The important thing is that the Web GPU API (or whatever it is called) is able to be implemented on as many platforms as possible. Unless there is compelling evidence to the contrary, this means that the API needs to run on at least Microsoft, Apple and Google platforms out of the box.

[grorg]

Also, I'll happily change what you think is opaque political language if there is a better suggestion that conveys the restrictions I've explained.

[ssokolow]

I think the concern that needs to be assuaged is that this could turn into something similar to Linux's infamous audio situation, where the driving principle is "Someone is unwilling to do work necessary to get API X fixed... we'll just use an abstraction layer" until you're abstracted half a dozen layers deep.

Actual examples I've seen:

• OpenAL → SDL → libalsa userland → PulseAudio mixer → Kernel ALSA → Actual Hardware
• Phonon → GStreamer → libalsa userland → PulseAudio mixer → Kernel ALSA → Actual Hardware

(Often after SDL or GStreamer supported PulseAudio directly, because going through the libalsa compatibility shim worked around some bug that nobody was willing to take responsibility for fixing in a prompt manner.)

[mg-13]

@grorg you try to make a point with the current availability of Vulkan, still the draft states the new API should be "implemented on top of modern GPU libraries, such as Microsoft's DirectX 12, Apple's Metal, and Khronos's Vulkan".

Android will never support d3d12 or Metal, neither will ChromeOS. MacOS or iOS won't support d3d12. Windows versions < 10 (you mentioned users that don't control their machine) won't support it. On the other hand, ChromeOS and iOS/MacOS could support Vulkan. WebVulkan would be one more strong reason to do so.

Microsoft Windows does not support Vulkan out of the box. There is no official Vulkan driver from Microsoft. It requires the end-user to install drivers from the GPU manufacturer, assuming they are available. It's not clear how supported those drivers are.

Driver updates are installed automatically via Windows Update. Every vendor (AMD, Intel and Nvidia) is shipping conformant Vulkan drivers.

Let's consider a system that does offer support for Vulkan: Android. In this case the driver comes from the hardware manufacturer, and many devices do not receive updates. It requires a device with the appropriate version of Android, and the hope that the driver doesn't have showstopping bugs.

That applies on each API. OpenGL implementations have bugs. And do you really think including devices, that are not receiving updates anymore, in this discussion is somehow worth it? Also, performance was stated as a main goal in the draft. A lower level API can't be implemented efficiently on top of ancient GLES versions. And you know, you have to build upon something.

I agree with you that Vulkan can't be used as is. But WebGL is not OpenGL and WebVulkan doesn't have to be Vulkan. IMHO The first step is getting the last major platform vendor not actively blocking the low-level, cross-plattform graphics- and computing-API.

[GunpowderGuy]

Mg_ 13 , Exactly , using vulkan on Windows requiering special configuration or driver installation is a fallacy . If that was truly the case , no one would have used doom on vulkan mode , and because of that , Id software wouldn't have bothered to release that to begin with .

[d2kx]

But it isn't just Apple platforms. Microsoft Windows does not support Vulkan out of the box. There is no official Vulkan driver from Microsoft. It requires the end-user to install drivers from the GPU manufacturer, assuming they are available. It's not clear how supported those drivers are. Also, there are a lot of people who simply can't install 3rd-party drivers since they don't control their machine. That's another significant portion of the market who are locked out.

Sorry, that is just wrong. First of all, there are no official GPU drivers from Microsoft, period. A barebone Windows doesn't come with any accelerated drivers. The first thing Windows does is install the appropriate GPU vendor driver, either from the installation medium or from Windows Update (online) in the background. And the vendor drivers provide support for DX11, DX12, OpenGL and Vulkan. They are not independent, they are bundled. You install Windows, Windows installs the NVIDIA/AMD driver, you have Vulkan support. These are not 3rd party drivers, these are the only drivers.

Another platform without Vulkan support: ChromeOS

ChromeOS is getting Vulkan support this year for both x86 and ARM devices, long before this new web standard would materialize.

Let's consider a system that does offer support for Vulkan: Android. In this case the driver comes from the hardware manufacturer, and many devices do not receive updates. It requires a device with the appropriate version of Android, and the hope that the driver doesn't have showstopping bugs.

This has nothing to do with this discussion, since the new Web API would depend on either DX12/Vulkan/Metal or be independent, so it's not like old Android devices that do not support Vulkan would get support for the new Web API anyway. Also similarly to ChromeOS, by the time this Web API would launch, all new Android devices that could support a lowlevel WebAPI will support Vulkan.

[othermaciej]

If anyone objects to anything specific in the charter, please specify what passage you object to and what kinds of changes would address your objection.

My own suggestion would be to replace this:

A technology that does not follow a single native API, which reduces the difficulty of implementation on platforms that do not support the chosen native API.

With something like this:

A technology that an reasonably be implemented on top of all modern graphics APIs.

It's better to state what the CG will do than what it won't do. And it better matches text later in the document that is more clear on this point. If the spec ended up looking much like one of the existing modern graphics APIs but was still reasonably implementable on top of all of them, that would be good enough. So that's what the requirement should say.

[RussianNeuroMancer]

@grorg

As you point out, Vulkan is not supported on Apple platforms. That's a significant portion of the market for a standard that is designed to be universal.

This is political limitation, not technical one.

Microsoft Windows does not support Vulkan out of the box.

Neither Windows below 10 support Direct3D 12, which is majority of Windows installations. However, Vulkan is available on Windows 7/8.0/8.1/8.1Update1/10 with GPU vendor drivers. So what's your point here?

Another platform without Vulkan support: ChromeOS

https://bugs.chromium.org/p/chromium/issues/detail?id=581473

Let's consider a system that does offer support for Vulkan: Android. In this case the driver comes from the hardware manufacturer, and many devices do not receive updates.

API we discussing here will not run on such devices either. What you proof with this argument?

So while Vulkan is a great attempt at a cross-platform API, it doesn't have the universal support required to use it as the basis for the Web.

So, essentially:

1. Apple can implement Vulkan support if they wanted.

2. Majority on Windows installations (below 10) with capable GPU can support Vulkan but will never get support of other API like Direct3D 12 or Metal. Windows 10 and above have support for Vulkan too.

3. ChromeOS will get Vulkan soon.

[grorg]

As @othermaciej said, let's try to come up with wording for the charter that is less controversial. There was never an intent to exclude something or force a particular direction.

It will then be up to the group to decide what the technology solution is.

[grorg]

Sorry, that is just complete bullshit.

While this doesn't offend me personally, I'll note that this group operates under the W3C's code of conduct. I will delete/ban/edit whatever behaviour doesn't meet those standards. I think there would be people who would be upset if the comment was directed at them, so let's not get to that point.

The rest of the comment, after that opening line, is appreciated.

[RussianNeuroMancer]

@grorg

With taking into account notes from @mg-13, @D2KX and my comments, please clarify if Vulkan support will be implemented by Apple, it well be enough to state that Vulkan have "universal support required to use it as the basis for the Web"? (In form of hypothetical WebVulkan/WebVK adjusted for usage in web.)

Thanks in advance.

[grovesNL]

I believe the statement should be removed entirely, unless the community agrees that following a native API is definitely not worthwhile given the technical challenges. Regardless it seems there should be a debate around whether any of Vulkan/DX12/Metal can be made suitable for the web (i.e. sandboxing and other concerns) before they're dismissed outright. Some of these technical challenges will be inevitable for any lower level GPU API so they should be seriously considered.

There were substantial benefits due to WebGL's ties to OpenGL ES (single ecosystem for resources, tooling, direct codegen for use with WebAssembly/asm.js) so it would be excellent if the same strategy could be applied here.

Personally I'm curious whether some of these improvements could be applied to WebGL incrementally, but it doesn't appear that has been considered in the charter either. Assuming it was technically feasible to apply features such as SPIR-V incrementally, the WebGL community could take advantage of these changes relatively quickly. This could have major upside for browser vendors as well (i.e. no team fragmentation due to maintaining WebGL2+ while implementing a new WebGPU standard) and community adoption.

[othermaciej]

@grovesNL (and others), would you disagree with this alternate requirement:

"A technology that an reasonably be implemented on top of all modern graphics APIs."

This doesn't rule out looking just like one of the APIs, if that seems what is technically best, as long as it can be implemented on top of the others. Also, if it starts looking like there is only one relevant modern graphics API, it doesn't rule out building around that.

I think browser engine implementors generally agree with the requirement as stated above, so I don't think we can make it any weaker.

[GunpowderGuy]

Grorg , lests not do that , this conversation deviated from that direction once we started correcting the fallacies you commented , now this is discussion is more about why won't apple support vulkan and why webgpu is not a fix to that situation . Edit : Here is another thread discussing webgpu , more along the lines of what I'm saying https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/930309-apple-proposing-a-new-lower-level-graphics-api-for-the-web/page3

[LEW21]

I suggest:

"A technology that is built on top of the open, multi-platform API - Vulkan - which reduces the difficulty of implementation for multi-platform web engines."

[alexm77]

"So while Vulkan is a great attempt at a cross-platform API, it doesn't have the universal support required to use it as the basis for the Web."

Vulkan is young, everybody's working on supporting it (besides of course, Apple). I don't see that as reason enough to slap an entire layer on top of gfx APIs. As we all know, that opens the gates for Microsoft to come and say "well, your generic API can't do X that DX12 can, so we need an extension". And then the whole thing goes down the drain.

[fingolfin]

I would love if Apple supported Vulcan, too.

However. I do not think at all that directly mapping Vulcan into a browser API would be a good idea; a higher level, like what Apple propose here, seems like a much better idea to me. Here is a good writeup: https://floooh.github.io/2016/08/13/webgl-next.html

[Vistaus]

@grorg I'm sorry to say it, but I find your response rather weak. Instead of replying to the things people have criticized about your initial response, you only reply by saying that you will edit/ban people's posts if not appropriate. Why don't you reply to the criticism instead? People have made some valid points.

[DanCraft99]

@grorg I am quite sorry to say it. But the truth is: whatever proposed from Apple on common Graphics API will not be welcomed before Vulcan API is adopted by Apple.

[illwieckz]

As you point out, Vulkan is not supported on Apple platforms. That's a significant portion of the market for a standard that is designed to be universal.

Apple is the only one retaining Vulkan on Apple platforms, so Apple is the one preventing universality, so Apple has no one right to base anything on this precise lack of universality.

Well, perhaps it just means it's up to Apple to lose the Vulkan market.

[grorg]

@diegor8 @vistaus All I said was that comments must follow the code of conduct. That's the rules of the W3C. I wanted to make that clear to everyone. It wasn't a threat or attempt to shut down disagreement.

I actually welcome the disagreement, and especially welcome anyone correcting my mistakes. I just haven't had an opportunity to reply.

[othermaciej]

@LEW21 Everyone agrees working on top of Vulkan is one requirement.

It sounds like you want to remove the requirements to work on top of Metal and on top of DirectX 12 because you believe it will help multi-platform browser engines. Can you explain how you know this? Do you work on a browser engine? Everyone we've heard from who works on a cross-platform browser engine wants those requirements in place. Do you have more specific information?

More specifically, for anyone who wants to drop the requirements to work on top of Direct3D and Metal, can you please provide a technical arguments for doing so? ("I like Vulkan" is not a technical argument, nor is "Apple is against Vulkan omg I am super mad").

(If anyone agrees with these requirements but wants the final API to look a lot like Vulkan - that's a spec issue, not a charter issue.)

[grorg]

Here is something I don't understand, and would appreciate clarification.

1. There are people here who demand the work be "based on" Vulkan
2. Those people also claim that Apple should implement Vulkan. (Other people here might be just demanding that, regardless of this Web API)
3. There doesn't seem to be much (or any) disagreement that Vulkan is not suitable for the Web environment, without significant modifications

If those three statements are wrong, then please explain why before reading on :)

The three things seem disconnected to me.

Point 1 is a valid opinion. I disagree, but that's cool. There are some arguments earlier in the thread for this point, which I promise to examine in more detail.

I understand the demand around 2. While Vulkan is young, and there isn't much content written for it, it's basically the only modern low-level API available on some platforms (e.g. Linux), so its success is important to many people. However, it would be a mistake to assume that this Web API would force anyone into implementing Vulkan for their OS. Even if Point 1 was accepted, Point 2 would not necessarily follow.

Basically, Point 2 is a request to Apple, not to the W3C group. It's better to make that request directly via bugreporter.apple.com rather than here.

And Point 3 is where I get confused. Given that it is unlikely that the output of this group will be source code compatible with Vulkan, it doesn't matter if Point 1 is accepted. (By compatible I mean that you'll be able to push Vulkan code directly through a C++ to JS compiler)

I don't see the benefit of Point 1 given Point 3. Instead, it seems much more useful to start by investigating all the available low-level APIs, see which design features are common, what parts are beneficial in actual shipping code, what things need modification for the Web environment, etc.

And it is even more useful to produce something that can work on top of Vulkan, D3D12 and Metal. I think this is a great requirement, and I would be strongly against a suggestion to drop support for any of them.

As @othermaciej said, wanting the specification to start with Vulkan is something we should discuss when we start the technical work. If necessary, the charter can be changed to make it clear that we are not ruling out such an outcome, but I think it already does that (especially with the suggested wording in https://github.com/gpuweb/admin/issues/1#issuecomment-278247871).

[illwieckz]

Well @grorg, the whole thread started with this quote:

A technology that does not follow a single native API, which reduces the difficulty of implementation on platforms that do not support the chosen native API.

This quote just means someone is trying to workaround Apple mistakes. It's not this one to convince, it’s Apple to convince. Everything else than convincing Apple is pure waste of time. Any effort to workaround mistakes is a waste.

[grorg]

@grovesNL

There were substantial benefits due to WebGL's ties to OpenGL ES (single ecosystem for resources, tooling, direct codegen for use with WebAssembly/asm.js) so it would be excellent if the same strategy could be applied here.

This was indeed a benefit for WebGL, one I mentioned in the WebKit blog post. I think that you'll see something similar for whatever comes out of here, but not to the same extent. There will likely be tooling to directly map from C++ code into WebAssembly, possibly without having to go through JavaScript. (In fact, one of the browser engines has shown a prototype that moves in that direction, but it was in a Khronos meeting behind an NDA, so I'll have to let them make it public)

Personally I'm curious whether some of these improvements could be applied to WebGL incrementally, but it doesn't appear that has been considered in the charter either. Assuming it was technically feasible to apply features such as SPIR-V incrementally, the WebGL community could take advantage of these changes relatively quickly. This could have major upside for browser vendors as well (i.e. no team fragmentation due to maintaining WebGL2+ while implementing a new WebGPU standard) and community adoption.

There is nothing stopping WebGL from incrementally adding features like SPIR-V support. That's a good suggestion that you should make to the WebGL group.

However, the problem is that WebGL is tied to OpenGL, and OpenGL isn't headed in the direction of these modern APIs. There are particular OpenGL techniques that can reduce overhead, but they are coding styles, not features. SPIR-V doesn't give you any new capabilities.

[grorg]

@illwieckz

Well @grorg, the whole thread started with this quote:

A technology that does not follow a single native API, which reduces the difficulty of implementation on platforms that do not support the chosen native API.

This quote just means someone is trying to workaround Apple mistakes. It's not this one to convince, it’s Apple to convince. Everything else than convincing Apple is pure waste of time. Any effort to workaround mistakes is a waste.

I understand how that statement reads that way. It wasn't intended.

@othermaciej has suggested alternate wording:

"A technology that can reasonably be implemented on top of all modern graphics APIs."

@grovesNL has suggested removing it completely. As I said above, I strongly believe the charter should push for implementability on at least D3D, Metal and Vulkan.

Does the change in the wording satisfy you? (cc @xorgy who raised the issue)

[illwieckz]

As I said above, I strongly believe the charter should push for implementability on at least D3D, Metal and Vulkan.

D3D is only a need on Xbox platform, it can be a convenience on other platform but not a need elsewhere. Metal is only a need on Apple platform and is not a convenience on any other platform. So, are we discussing the Xbox or the Mac being the platform, or are we discussing the Web being the platform?

[bgse]

@grorg Somehow I feel the wording still suggests practice of standard following vendors, not vendors following standard.

"A technology that can reasonably be implemented on top of all modern graphics APIs."

This does sound better, but doesn't it sell the same cat in the bag? I'd hope for something like

"A technology on top of a modern graphics API that can either be reasonably implemented (the API) or reasonably wrapped on all platforms."

[grovesNL]

@othermaciej That sounds more reasonable, however it still sounds as though the new API caters to certain OS vendors that may be unwilling to implement the same native API.

@grorg I certainly appreciate what is being proposed, however I think more people would be comfortable with this if there was greater justification why another API is required. I understand there are technical limitations that may make it challenging or even impossible to use an existing native API (i.e. Vulkan) without major changes to the API itself. However it seems necessary to justify the additional abstraction layer beyond the fact that OS vendors may not prefer to support certain native APIs.

However, the problem is that WebGL is tied to OpenGL, and OpenGL isn't headed in the direction of these modern APIs. There are particular OpenGL techniques that can reduce overhead, but they are coding styles, not features. SPIR-V doesn't give you any new capabilities.

I agree, WebGL1/2 is tied to OpenGL ES today, but there doesn't seem to be a reason concepts like command queues couldn't be brought into future versions of WebGL or even WebGL2 behind extensions depending on the API changes required. The example of WebGPU provided was essentially equivalent to WebGL today except for the command queue functionality. I'd be surprised if OpenGL ES is not considering some of these concepts for future versions.

Perhaps the discussion should be around which low level features should be exposed to the web as a starting point. I'm slightly skeptical that a common abstraction would significantly vary from WebGL2's existing API, given that Vulkan appears to be out of the picture because it's too low level. If the goal is to provide a slightly more object-oriented API with some additional functionality then it's a quite a large investment for the benefits it provides.

[xorgy]

@othermaciej

"A technology that an reasonably be implemented on top of all modern graphics APIs."

Not to stoke the flames, but there is already a Vulkan implementation on top of Metal (MoltenVK), so the statement means very little.

[othermaciej]

@illwieckz "So, are we discussing the Xbox or the Mac being the platform, or are we discussing the Web being the platform?" -- We're talking about the Web platform. The Web is a universal platform that runs on a wide range of native platforms. So Web APIs should be widely implementable.

@bgse "A technology on top of a modern graphics API that can either be reasonably implemented (the API) or reasonably wrapped on all platforms." -- This seems to assume that building on top of a single graphics API is good. Also that it's possible. The idea that it's better than working with all modern graphics APIs needs to be justified. As for the second, it's not the place of web standards to dictate what native platforms implement. Web standards should work on a wide range of platforms as they exist.

@xorgy If the statement means very little then hopefully that means you don't disagree with it? Note, my proposed charter language doesn't rule out a super Vulkan-like Web API that was implemented on top of metal using MoltenVK, if that can be done with reasonable completeness, correctness, and performance. Judging that is a technical question for the spec, not a charter question.

For browser engine vendors, working on top of all the modern graphics APIs is a hard requirement. So far no one has given a good reason why this requirement should be removed. I do agree with adjusting the wording. This requirement doesn't rule out making the web API look very much like one of the native APIs. But the requirement needs to be there.

[comex]

Any chance we can get into the technical weeds a little? Caveat: I'm new to these APIs.

I keep hearing that Vulkan is too low-level to be supported on top of other APIs, on the web, etc., but what are the exact issues? Where (if anywhere) would changes have to be made, and how difficult would it be to port existing Vulkan code?

One thing I've seen mention of is memory allocation; it seems that Vulkan forces you to allocate raw VkDeviceMemory and then bind higher-level objects like VkBuffer to the memory. Some Googling suggests that DirectX 12 and Metal have higher-level objects allocate their own memory by default, but they can alternately be manually placed in "resource heaps", similar to the Vulkan approach (in Metal's case, new in iOS 10 / macOS 10.12). So it seems like it should be mostly possible to reasonably emulate this aspect of Vulkan on top of the other APIs. Are there some cases that cannot be emulated? How common are they?

Regarding supporting this on the Web, I don't see obvious problems with exposing vkMapMemory as a function that returns an ArrayBuffer. Are there any cases where missing synchronization of buffer accesses can lead to violations of memory safety, as opposed to 'mere' unpredictable results? How important is it to avoid unpredictable results?

(As things stand, that wouldn't quite be enough for existing C/C++ code ported using WebAssembly, because such code will expect mapped buffers to be accessible through regular pointers, while the WebAssembly MVP expects all linear memory to point to a single ArrayBuffer. But AFAIK it is already planned to add mmap-like features in future versions, which should cover that.)

Certainly there would be additional locking required around API calls; that's true regardless of the design of the web API, unless it's heavily restricted to one thread at a time. Vulkan was of course designed with the expectation that the application would handle locking. But are there any cases where a Vulkan-based web API would require excessive locking overhead in a way that could be avoided with a custom API? (I thought command buffers might be an example, but uses of command-appending APIs have to be surrounded by begin and end calls, so a web wrapper could have begin and end take a lock and set a 'current owning thread' field, allowing the appending APIs to just check the field.)

What other issues are there?

[grorg]

@comex These are great questions, but I think we should limit the discussion here to the charter wording. I'll create a new repository for technical/specification issues very soon and let you know, so that you can ask there.

[illwieckz]

@othermaciej: We're talking about the Web platform. The Web is a universal platform that runs on a wide range of native platforms. So Web APIs should be widely implementable.

To me reading that:

@grorg: The [GPUWeb] charter should push for implementability on at least D3D, Metal and Vulkan.

is like reading that:

The HTML charter should push for implementability on at least RTF, LaTeX and SGML.

or that:

The JavaScript charter should push for implementability on at least VBScript, AppleScript and ECMAScript.

Back in the days a private company named Netscape worked on LiveScript and after some heavy work a standard named ECMAScript was published, JavaScript being ECMAScript implemented in web browsers.

Please rewrite this sentence this way:

Back in the days a private company named AMD worked on Mantle and after some heavy work a standard named Vulkan was published, GPUWeb being Vulkan implemented in web browsers.

Please allow our children to hear this story for the next 20 years and later like we can tell it today about JavaScript. If you know what I mean…

We are talking about the Web. There is no place for short view. I really don't care if ChromeOS does not ship RADV or ANV yet, it's not the point.

The Web must be the platform. GPUWeb must be the platform.

[othermaciej]

@illwieckz I don't think your suggested sentence accurately describes what implementors or other stakeholders want. You also didn't give a technical reason for this requirement. "Think of the children" is not a technical reason. You also didn't give a reason for dropping the requirement to work on top of Metal and DirectX. The bar is high for dropping someone else's technically justified requirement.

Finally, your analogies are not on point. They show the exact opposite of what you intend, if you think about them.

HTML isn't implemented on top of other text markup formats at all. It's implemented on top of UI toolkits and graphics APIs. Saying WebGPU should be a direct reflection of Vulkan and only implementable on top of it is like saying HTML should be a direct reflection of Gtk+ and only implementable on top of it. That would be awful, even though Gtk+ is very portable and can run on platforms with a different native toolkit. (As it happens, HTML can be translated to RTF, LaTeX and SGML, but full fidelity of these conversions is not expected or required.)

ECMAScript isn't (generally) implemented on top of other programming languages. The relevant targets are CPUs (and in some cases kernel capabilities). If a new JS language feature was efficiently implementable on x86 but not on ARM, you'd better believe that would be a problem. It would be a problem even though x86 simulators for ARM exist. If JS wasn't efficiently implementable on top of AppleScript, that would be a curiosity but not a practical issue, since no one wants to do that.

Both of your examples illustrate why a web standard shouldn't be tied to a single implementation technology.

[illwieckz]

@othermaciej If my analogies are not on point it's OK. It means there is no need to quote Vulkan in that charter (nor the other similar and competing technologies), and perhaps the wording issue is to quote them at first.

Remember the glNext/Vulkan thing: Khronos was referring to glNext first so when the name change happened this renaming was not understood by people because it looked irrelevant to name something related to OpenGL with a name unrelated to OpenGL and loosing all the reputation of the name. In fact Vulkan appeared to be awesome and not related at all to OpenGL, and everyone has now understood there is no reference between them, no link between them, and if someone now confuses them he looks stupid. In fact the issue was Khronos making references to OpenGL first in early Vulkan wording, because there was no reference to do. People complained because the name lost the reference to OpenGL, but the issue was making people believe there were references. It's OK if I look stupid this time.

[illwieckz]

HTML isn't implemented on top of other text markup formats at all. […] ECMAScript […] relevant targets are CPUs

It's OK if GPUWeb must be implemented on top of other formats since GPUWeb relevant targets can't be GPUs at all. It's OK if the comparison does not work due to the specificness of these kinds of technologies. People are afraid because the current wording suggests this fact is not due to the specificities of that technology field but due to some company politic refusing standards, something nobody wants. If these differences are technical needs and not politic workarounds, it's OK.

[grorg]

I've made an attempt at better language in the commit referenced above.

It's pretty much what @othermaciej suggested. The goal is to not exclude implementation on any platform that has a modern graphics API, and to also not require that the end result follows one of those APIs.

If you disagree with those statements, then we can continue discussing it here, or you could open another issue. If you're absolutely convinced that a Web API should be based only on Vulkan, then you could also propose your own group. Even if you don't want to do that, I'd encourage you to draft a Web API based on Vulkan, and start implementing it in one of the open source browsers as well as produce examples in JavaScript, to the same level that is in the WebKit blog post. Other browser engines have done this too - it's just not all public yet.

Here is one from a Mozilla Servo engineer that is public, but not necessarily the official position of Mozilla. slides source

@bgse I don't see the point in explicitly mentioning implementing vs wrapping. The former may be a case of the latter, if the APIs are compatible. For example, on macOS Google Chrome wraps OpenGL to implement WebGL, but on Windows, they use a separate library called ANGLE because there isn't an OpenGL to wrap. They still end up with a WebGL implementation.

[grorg]

@illwieckz

People are afraid because the current wording suggests this fact is not due to the specificities of that technology field but due to some company politic refusing standards, something nobody wants. If these differences are technical needs and not politic workarounds, it's OK.

I believe we've said this a few times already, but I'll try to make it more clear.

• The particular technology you want to require this API to be based on, Vulkan, is not appropriate for the Web.
• The fact that a platform doesn't implement all the modern graphics APIs, or even just doesn't implement Vulkan, might seem to you like a political issue. However, it's a technical issue for the browser engine implementors. They don't control the platform, so if the API requires something that is not present, then the API fails.
• Following on from that, since there isn't a technology that is universally available, picking one of them as a requirement and excluding implementations using the others is a non-starter. For example, this API should be able to run on XBOX and PS4 systems.

At this point I'm tempted to close this issue. I feel like we've addressed the original complaint, which was a fear that the wording in the charter was trying to protect Apple's interests. It now suggests that any or all of the modern graphics APIs can be used as input, and that the API produced should not exclude any platforms that have a modern graphics API.

If someone wants to push Vulkan as the sole input for the API, let's discuss that as a technical matter in the area where we'll do specification work (coming soon). I'd also reiterate what I said above: that an argument along those lines should probably do the same legwork we did for WebGPU (API proposal, prototype implementation, example code).

[illwieckz]

@grorg I've seen this change and it looks OK to me. :+1: Thanks. I'm not convinced that a Web API should be based only on Vulkan, I just don't want to get an API which is thought as a workaround at first, and a layer hell.

@ssokolow quoted the audio Linux hell. As an example I discovered some years ago the GStreamer framework was never able to record live alsa sources and it looks to be still true today. This bug was not reported in more than ten years since people were all relying on a broken workaround (setting the live source as asynchronized, which is only able to delay the problem to occur) or people put an extra layer (like PulseAudio) between GStreamer and ALSA. I faced that nasty bug because I was implementing a realtime long distance sound broadcasting and switching system for some FM radio stations and I wanted to get rid of all unneeded layers to save latency. The GStreamer project will be 18th years old in October and is not yet able to support ALSA correctly. But in 18 years nobody is really facing this bug due to a gigantic hell that almost hides it.

I'm just afraid of layer hells. I'm not the one who created this issue so I can't say if is his complaints are addressed but to me it's fine now.

[GunpowderGuy]

grorg , Concerning your last point , we do know that vulkan can be efficiently translated to direct x 12 ( much better than direct x to opengl ) , as those two apis are extremly close , the same is very likely the case for ps4 ( amd had a hand at developing it ) ; that would only leave out apples product's ; but they dont have to , there is vulkan drivers already for all of them , if they do implement it , then : windows , linux , mac os , android , ios and the switch could get webgraphics natively , while only two consoles would get it emulated , albeit efficiently ( vulkan to metal presumably isnt as fast , because metal cant go as low level , although the devs of molten vk say otherwise , so webvulkan can be posible without vulkan on mac and ios , although it definitely wouldn't be the best )

About if webgpu makes sense , or webvulkan would be tecnically posible, and thus an option, i started this issue https://github.com/KhronosGroup/Vulkan-Docs/issues/451

[amitsheokand]

If they can't support OpenGL 4.5, WebGL 2, or Vulkan - they shouldn't be proposing a standard. They need to start following standards more before the other industry players should trust them.

[niner]

We shared it with multiple vendors before it was made public here.

That doesn't mean anything. If I emailed this comment to office@mozilla.org and friends before posting it here I also shared it. Does it make my comment any more "official" or a common statement? Of course not.

With commit 47f73515c5755ba92b3aec611ea77f573fa6a887 the language may have become a bit less political, but is still just as opaque. What does "A technology that can be reasonably implemented on all platforms that have a modern, low-level graphics API." mean?

When can something be "reasonably" implemented? Is it "reasonable" to require a browser vendor to write 3 different backends? Or is it "reasonable" to require vendors who ship systems meant to support web browsing to expose the functionality that the graphics drivers already bring?

What exactly is a "modern, low-level graphics API"?

When does it mean for a platform to "have" such an API? Linux itself will give you kms and drm, not anything a normal program would use directly. So if "have" means that it's available if the user installs extra software, Vulkan is available today even on Apple's systems by way of MoltenVK. So does iOS "have" Vulkan? If not, Linux doesn't "have" either Vulkan, openGL or Direct3D.

@othermaciej I find it quite disingenuous to require technical arguments when technical issues have been explicitly excluded from this discussion earlier.

Everyone we've heard from who works on a cross-platform browser engine wants those requirements in place.

An who is this everyone? Everyone I've heard from who works on a cross-platform browser engine wants the API to be based on Gallium3D. That's a completely true statement. Of course "Everyone I've heard from" is an empty set in my case. So without further details, the sentence is completely useless. Even better, why not have those people join the discussion and speak for themselves? I'm do not believe that they outsourced their communications to Apple?

[BolandJS]

Has this place become an extension of the Phoronix forums? This is painful to read.