Opaque political language is a major red flag for me. #1
Comments
|
@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. |
|
This proposal would only add another layer of abstractionmost to what most engines already have |
|
There are already a number of cross platform tools for working with SPIR-V. I hope it will be supported. |
|
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. |
|
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. |
|
Replying to @xorgy 's comment.
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:
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 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. |
|
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. |
|
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. |
|
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:
(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.) |
|
@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.
Driver updates are installed automatically via Windows Update. Every vendor (AMD, Intel and Nvidia) is shipping conformant Vulkan drivers.
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. |
|
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 . |
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.
ChromeOS is getting Vulkan support this year for both x86 and ARM devices, long before this new web standard would materialize.
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. |
|
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: With something like this: 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. |
This is political limitation, not technical one.
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?
https://bugs.chromium.org/p/chromium/issues/detail?id=581473
API we discussing here will not run on such devices either. What you proof with this argument?
So, essentially:
|
|
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. |
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. |
|
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. |
|
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. |
|
@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. |
|
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 . |
|
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." |
|
"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. |
|
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 |
|
@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. |
|
@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. |
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. |
|
@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. |
|
@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.) |
|
Here is something I don't understand, and would appreciate clarification.
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 #1 (comment)). |
|
Well @grorg, the whole thread started with this quote:
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. |
|
@niner said it better than I could ever manage to. And that opens up the pandora's box: original wording had its share of issues. New wording, trying to fix those, brings in technical aspects that were excluded in the first place. Because of that, new wording is even more opaque than the original. That might mean we're trying to workaround a problem in the wrong place. Let's assume that wording tries to describe a design flaw of the project itself, making it look like the killer API of the century: it will always be wrong. I think we can't fully separate charter wording from technical aspects: we're talking about an API after all. The fourth goal should detail more precisely what "reasonably", "modern" and "low level" mean. Or we should remove it altogether and decide if the first three goals are enough for a new API. |
|
@lucrus73 It's common for charters to state high-level requirements in fairly general language, and expect the group to figure out their detailed meaning as part of its work. So I think the language is fine as-is. But since you made two alternate proposals: (1) Can you provide alternate language that you think defines all the terms precisely enough? Then we can compare specific language instead of a specific to a general idea. We'll then have to compare the benefits of being more specific to the costs of overconstraining the group. (2) If you feel the requirement should be removed, can you state a reason? I think "terms not fully defined" isn't a good enough reason. Clearly many want a requirement along these lines. Both Apple and Google representatives have gone on the record as supporting it. I expect others will as well. Apple's reasons for wanting it are that we believe browser engines will want to build on top of multiple of these APIs. So there would have to be a very good reason for removing it entirely. |
|
I don't know if writing this will be helpful or not but hoping it is. I understand why people think Vulkan should be the solution but ... as someone that worked on Chrome's GPU infrastructure in the past (4 years ago) it feels like some here are unaware of the many issues that come up when actually implementing this stuff. For example, similar arguments could be made for WebGL. Some people are happy it's based on OpenGL ES but then others got angry that ANGLE was created instead of using OpenGL drivers. But, OpenGL on Windows is not a first class citizen. All kinds of APIs from DirectVideo or Direct2D etc don't interoperate well with OpenGL drivers or require proprietary extensions that may or may not exist. OpenGL drivers are not installed by default. I just tried running GL-Z on my Windows 10 installation. This is what I got
This is a machine I've run various modern DX games on. Modern OpenGL is still not installed by default in Windows. Vulkan is currently no different AFAIK. Gamers and Graphics enthusiasts install drivers but mom, dad, and corp machines do not. This is one reason why ANGLE exists. Now you might say so what, base spec on Vulkan and then write ANGLE-Vulkan for any platform that needs to translate to their native API. Well, that brings up other issues. If you've ever ported any OpenGL code across platforms you'll likely quickly find all the places you were doing something platform specific. Maybe you thought attribute locations are assigned in the order found in the shader only to find your code broke on another platform. Maybe you thought uniform array element locations were just the 0th element's location + index but then found out your code fails on another platform. Those are minor examples, the bigger issue is that when actually porting an OpenGL app across platforms you generally find there is a porting step. That's fine for native apps. You want to ship on Android you need to make an Android executable. You want to ship on Raspberry PI you need to make a Raspberry PI executable. That process of making the executable for the specific platform is where you find out all the things you need to do special for that platform, OpenGL related or not. But that's not how the web is supposed to work. You shouldn't make your webpage on Windows 10 with NVidia drivers and then have a porting step to get it to work on PowerVR on an Android device. (well, baring memory/speed issues). It's my understanding Vulkan has these same issues. The API assumes there's a porting step. A step were you'll have to get your executable built on the target platform, that you'll deal with all these little issues. Okay you say, then let's make WebVulkan that fixes these issues (which is what WebGL did for OpenGL as much as possible). But AFAICT that's not Vulkan's design. Vulkan you query all the GPUs in the system. You then query features. That's not how to make a webpage. A webpage, if you're lucky, should be write once run everywhere. In general, at most you should have to query whether webgpu exists or not, not then check a ton of features and branch on them. Vulkan is designed to not do too many checks. You can run a validation library on top of your code if you want to see if you're breaking any rules. Of course WebVulkan would always have to do all of these checks. Are any of the checks expensive? Would a different API allow those checks to be cheap? An example in WebGL, index buffers (ELEMENT_ARRAY_BUFFER) are shadowed in CPU memory but other buffers are not. This is because WebGL requires index validation for security reasons. WebGL added some restrictions. A buffer used as an ELEMENT_ARRAY_BUFFER can only be used as an ELEMENT_ARRAY_BUFFER. It can't be used freely with other buffers. Would WebVulkan need a similar restriction? How much would the API need to change to enforce such a restriction? Vulkan kind of assumes your app has direct memory access. OpenGL ES mostly does not and the one API function that allowed that (glMapBuffer) is removed from WebGL2 because it's way too hard to implement. It's not as simple as mapping an ArrayBufferView, modern browsers run the GPU in another process so you now need some way to map a piece of memory across 3 things, the driver, the GPU process, the process running your JavaScript. Somehow all of that communication between 3 processes needs to be super efficient but if you've ever done any cross process communication you know that's unlikely to be an efficient thing. Every time you call So now we come to Vulkan whose entire design assumes you have direct access to GPU memory. Similar issues are going to come up. One would be the fact that when you submit a command buffer in Vulkan the system assumes you aren't going to write to the command buffer while the GPU/Driver is using it. As in you're not trying to actively screw up the driver, you're trying to make a working app. But that's not how Webpages work. You visit a webpage and it's untrusted. So now you've got to change the API so that the moment you give memory to the driver (submit a command buffer) that memory is no longer accessible from JavaScript. For Chrome (and probably other browsers), that doesn't just mean making V8 disallow access. Chrome's defense in depth means that memory can't be accessible to that process running JavaScript period because any bug in V8/HTML/CSS could allow code execution (there are always bugs in all code) so Chrome tries to prevent access to that process entirely. Chrome does this for WebGL by reading the command buffer and validating in the GPU process. A rogue piece of code in the JavaScript process can trash the command buffer all it want's, the GPU process will just end up failing validation and "WebGL hit a snag, Rats!" For Vulkan (or for any similar API) the process will likely have to be that JavaScript builds a command buffer, that command buffer is read by GPU process and as it's validated it is COPIED to a new real command buffer in the GPU process. That real command buffer is then actually submitted to the driver. So that also begs the question, what's the best API for this? Is it Vulkan? Would some other API allow simpler validation and cause less overhead? In other words, let's design an API that fits the needs of browsers (letting untrusted random websites have safe access to your GPU in an efficient manner). That wasn't a goal of Vulkan or OpenGL (or DirectX or Metal). The goals of those APIs are in general, don't worry about security, let the app access the GPU as efficiently as possible. WebGPU's goals have to add security on top of that. That added goal will most likely require or at least suggest a significantly different API. There's probably another goal which could be stated as "avoid long synchronous operations, make the API async where it should/can be". In WebGL those places are arguably Yet another goal should be portability. That came up above but there are other areas. Like I mentioned above because OpenGL and Vulkan are native APIs they require a porting step (making the app run on the new platform). Often apps can be doing something wrong but be running by luck. An example in OpenGL would be to start a query and then later read its result without checking if the result is ready. If your timing is lucky or maybe just if your GPU is fast and your CPU, monitor refresh rate is slow your app appears to be working fine. It's only later when the GPU runs slower or the user's refresh rate is higher (VR?) that you check the result before it's ready and your app screws up. For native apps that's an issue but it's far less of an issue than it is on the web. You could instead the design the API so you can't make that mistake in the first place. It seems like those types of things should at least be on the table for a web based GPU API. Let's start with a blank slate, take the Web's special needs into account before starting and see where it leads? |
|
@greggman vulkan got those two critical things right from the start , windows support( its bundled with drivers , so it is either already installed on pcs ( do windows have vulkan out of the box now ? ) , or it gets installed the first the computer is updated ( which is almost always the first time you boot it ) (how many people never update their drivers ? ) and api consistency , vulkan is really implemented the same across vendors , the situation is completly unlike open gl , thats why mainstream games can use it without having to support dx12 too ( they dont install the api in your machine , they rely on it already being installed |
|
@diegor8 Well, ok, I just ran vulkan-test on my Windows 10 installation
I think you and I have a different definition of "got right" 😅 To add to that, first off I made a bunch of points above about vulkan irrespective of if it happened to be installed by default in Windows. But, as pointed out, it's not installed by default. Now you might think "just tell the user to install new drivers" but lots of users don't have that option. To give one example pretty much every corp user on a locked down machine does not have the option to install drivers. If it was that easy Chrome and Firefox would not have shipped ANGLE, they'd just tell users "if you want to run WebGL download an OpenGL driver for your system". Research showed that was an unrealistic requirement. To a gamer / expert user it seems obvious just install the latest drivers. I certainly thought it having come from gamedev. But, I learned it's not that simple for many many users. |
|
Is that vulkan/dx12 compatible pc updated ? |
|
Yes it is updated
|
|
@greggman Nit: Vulkan command buffers are different from other buffers. You don't map them and get a pointer; they're opaque objects intended to be manipulated only with the command functions, not too different from OpenGL display lists. So for command buffers Chrome would probably end up proxying the functions themselves rather than doing any mapping tricks, similar to what it does with GL. (I know WebGL doesn't do display lists, but it's the same idea, just stored instead of executed immediately.) But for regular buffers, cross-process mapping would definitely be an issue... not sure why I didn't think of that. If only all operating systems worked like Darwin where you can just remap arbitrary memory into other processes :) |
|
Oh, another nit: "modern browsers run the GPU in another process" isn't really accurate AFAIK. Neither Firefox nor WebKit does so. I don't know whether IE/Edge does, but if not then it's just Chrome :) |
|
Being able to remap memory isn't the the only issue. Consider glMapBuffer
That round trip of waiting for and coordinating with the GPU process is slow. Then the JS process calls wants to call glUnmapBuffer and again there's more coordination required because before the GPU process can call glUnmapBuffer for real it has to make 100% sure the JS process is no longer looking at that memory as once glUnmapBuffer is called that pointer is no longer valid and could be being used for anything. As for "modern browsers" what was a poor word choice. That said if we're picking nits IE is not a modern browser and is irrelevant to this discussion as it is no longer being updated so this API will not appear there. Firefox has/is going multi-process and has a GPU process AFAICT. I can't say whether WebKit or Edge will do the same but I can say pretty confidently that Chrome will keep its GPU process for security reasons and I suspect Firefox as well so designing an API that takes the issues that that brings up should be part of the goal of a web based GPU api. |
|
I've read all the comments and the threads on other sites linked here. Other than the conspiracy theorists who are completely convinced that Apple developed Metal for the sole purpose of political domination and destruction of all other efforts, I haven't seen any compelling arguments against Dean's original statement that WebGPU should be implementable on a variety of platforms. Isn't openness and inclusion the hallmark of the web? And let me say that, even though I work for Apple, I don't work on Metal and therefore have no insights into Apple's motivations for creating it. These are just opinions from one engineer who uses these APIs. Please don't make assumptions about the motivations of companies who choose to create proprietary APIs. There are many reasons to do so, not the least of which is the ability to advance the API more quickly. Apple clearly decided that a proprietary API that got as much out of the relevant hardware as possible was more important than a cross-platform API. I imagine Microsoft has made similar decisions about DirectX. An API for the web has different goals. By definition it must be cross-platform. The more platforms covered, the more web developers can use the API and get their message to their intended audience. The reason for starting this group is not to subvert the web to Apple's will, it's to allow new technologies to be used on the web. Why not just use WebGL? As has been mentioned many times, WebGL is related to OpenGL ES. In fact it was designed to follow the style of OpenGL. It is very C like, with lots of function calls and few objects. Modern GPU APIs are much more object oriented, which reduces the number of function calls required and makes them inherently more efficient. So while you could, and I sure someone will, make a WebGPU API on top of WebGL, it would not be as efficient as it could be. The job ahead is a technical, not political one. Let's put aside our opinions of the "best" API and make a really cool GPU API for the web. |
|
@greggman: I agree with the majority of what you said, but the issue with So I see three obvious approaches:
Solely converting the API to be more object-oriented will not drive the kinds of efficiency gains that people are seeking with the low level APIs. They're driven by concepts such as command queues, multi-threading, lower level access to the GPU, SPIR-V, etc. Most of those issues could be solved with added functionality in OpenGL ES (i.e. AZDO functionality in OpenGL core) without recreating the entire API. Not to say I believe we need to stick with WebGL, but I do not think it's worthwhile to recreate the entire WebGL API to make it slightly more object-oriented and expect huge performance gains. So before we fragment the ecosystem let's consider whether we can improve WebGL to add any proposed functionality (this corresponds to approach 3 in the list above). |
I consider what you're suggesting as a separate proposal as input to this work, similar to what Google and Apple have provided. And it would be worthwhile for someone to flesh it out, and maybe even implement something so we can start to measure performance. However, we need to be careful to separate this work from the existing Khronos WebGL group. If you're suggesting changes to WebGL, then it should be done there. (I'd still encourage you to make the proposal and post it here) |
|
@greggman Firefox has a GPU process for compositing, but I checked the source and it doesn't seem to proxy WebGL. I don't think the performance of map/unmap matters much, since most applications should call map once as a setup step and reuse the buffer across many frames. However, it may not be possible to get the memory mapped in another process… Anyway, I guess this sort of discussion belongs in a different thread. |
|
@grorg: Agreed. Any improvements to WebGL should be proposed at the Khronos group. However because the concept above (i.e. approach 3 in my list) is not fully orthogonal, it would be important to agree upon which functionality would be added by the proposed APIs over the existing WebGL 2/OpenGL ES 3 API. I'd only expect us to know that after considering many proposals. Because the working groups overlap so greatly it would be good if this was kept in mind while reviewing various WebGPU proposals. While I'd like to submit a sample implementation, I'm not personally familiar enough with browser engine internals to provide an implementation or even a proposal. I simply think it's an important consideration that shouldn't be automatically excluded from the discussion because it's assumed to be infeasible (API or performance wise). It seems reasonable to verify any assumptions and evaluate any reconciliation efforts before deciding to move forward with a new API. As I said above, I'm not personally tied to amending WebGL and I'm fine with migrating away from it if it's not suitable. As an end user I'm excited about any approach that improves the web, and will be happy to provide feedback wherever I can. I think it's great this conversation is happening and look forward to the solutions we come up with. |
|
I really appreciate @greggman's detailed comments above. He explained many of the difficulties in exposing an API like this to the Web better than I could have. While WebKit doesn't have a GPU process, it might in the future. Either way, the ability to serialize the API to another process is a definite requirement for Chrome. @grovesNL - we discussed your suggestion at the WebGL meeting today and there was agreement that it is an interesting direction to consider. Could you send an email to [email protected] (or [email protected] if you're a Khronos member or would like to keep the discussion private) to describe it again? @niner and @lucrus73 - I'm going to update the charter to be more precise with terminology. However, since I think you do know what was meant by "modern, low-level graphics API", I'm going to assume clarity wasn't your main issue. @kainino0x answered a bunch of your comments. I'd like to see your answers to @othermaciej's question. Here's my characterisation of the current state of this issue:
|
|
I think that it needs to be clarified a little bit this overlap. Is this effort motivated to be done here instead of Kronos cause W3C it is a more "natural home" for web standardizzation processes? |
|
@grorg regarding the "modern, low-level graphics API" wording. You actually detail it further in "Scope of Work", so I guess it's ok already. Adding "(like DirectX 12, Metal or Vulkan)" could make it clear from the outset without the reader having to know much context. I'm fine either way. |
It's a combination of things. Yes, the W3C is a more natural home for Web standardization. The W3C hosts nearly all other standards efforts for the Web, but importantly WebAssembly and WebVR, which have important relationships to this work. A W3C Community Group is also open to everyone without a membership fee. And the W3C has a different IP and Patent Policy which, in Apple's opinion, makes it easier for us to produce a royalty-free specification for the Web. Khronos's advantage is that it has all the GPU hardware vendors as members. We put a lot of effort in to making sure they would be able to participate in the W3C too. And of course, this work needs input from all parts of the community: hardware vendors, software developers, browser engines and the generally Web community. WebGL benefits from being in Khronos, especially since it is a JS version of Khronos's OpenGL ES technology. This "GPU for the Web" work is higher-level, and not based on a single existing technology (well... some of the discussion above disagrees with that, but that was the goal) |
|
Ok probably if this is was also related to the computing component to cover the defunct WEBCL I think that it is also needed to attract other kinds of accellerators vendors (dsp, fpga, etc.). Would be an unified effort like SPIR-V? |
|
As a developer of HTML rendering engines in the games domain, I have to deal with a large number of platforms, some of which are quite different than the PC, iOS, Android examples that are repeated over and over here. In that sense an API that tries to address a more general case is definitely more compelling than blindly implementing Vulkan. Platforms that have no native support for it shouldn't be second calls citizens. WebGL was completely designed around GLES and it maps badly to multi-process architectures where it's easy for user to introduce stalls in the pipeline. The same way, Vulkan was not designed with the restrictions and requirements of a browser and will probably map poorly as well. Vulkan is designed for an environment where the developer has "complete control" over the application GPU, which simply impossible in browsers that have to implement security, multiple tabs and often run the GPU work in a different process. I strongly believe that a much more thorough process of API design is required that takes into account both the specifics of the browser environment and the target platforms. |
|
@grorg: Thanks! I submitted it to public_webgl for further discussion. |
|
@greggman wrote
This is not true any more. The GPU drivers from all the major vendors, AMD, Intel & NVidia that get installed by Windows Update include OpenGL. I have 2 systems running Windows 10 (and 7 or 8.1 before that), one with AMD the other Intel. Both have OpenGL and I did not do anything to install it. When I bought the one with Intel about 2 years ago I ran OpenGL Extensions Viewer on the display model in the store to see which version. It was 4.2. A subsequent Windows Update several months later brought it up to 4.3. I do not know why GL-Z failed for you. I suggest trying the OpenGL Extensions Viewer to find out what, if any version your GPU has and what extensions are supported. Your Vulkan test almost certainly failed because of the age of your GPU. (That may be the reason for the GL-Z failure too.) Intel only supports Vulkan in Windows on their latest generation "Skylake" hardware. They do not support it on the previous generation "Broadwell" hardware though that is supported by their open source driver on Linux. Anything earlier than Broadwell is probably not capable of supporting Vulkan. |
|
This issue has been open for a long while now. It seems that the originators of this group are in one camp (the goals described in the charter), but there are still some people who think a solution based purely on Vulkan should be required. At this point I'm going to close the issue, and incorporate the Vulkan-only request as strong design input. I don't believe there is anything in the charter that would forbid a Vulkan-only solution, assuming that solution is compatible with the requirement to be reasonably implementable on platforms with a modern low-level graphics API. W3C Community Groups are set up so that the people who propose the group get to decide on the initial scope of the charter. |
|
A Vulkan-only proposal is also welcome in the proposals repository |
Integrate feedback received on draft charter
and others
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:
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.
The text was updated successfully, but these errors were encountered: