7 ms·

As a cross-platform graphics developer who is currently knee-deep in papering over platform incompatibilities, what I mostly care about at this point is compati

As a cross-platform graphics developer who is currently knee-deep in papering over platform incompatibilities, what I mostly care about at this point is compatibility. I don't care about shader size or compilation time, as long as both are reasonable. I do care about having yet another shading language to cross-compile to. Please, everyone, just use something that already exists. It is frustrating how the big players constantly use new and incompatible graphics APIs to try to obtain some sort of competitive advantage, adding to the workload we developers have to deal with. There is almost no cost to the platform developers to add new APIs; instead, the costs are borne by the application developers. It's a classic case of negative externalities.

om2 7y ago
The only thing that already exists that is provably web-safe is the WebGL dialect of GLSL (which no one seems to like). WebSPIR-V would be based on SPIR-V but in many ways has to be a new thing as well. Edit: I originally said "WebGPU dialect of GLSL" which is not a thing. I meant "WebGL dialect of GLSL", which is a thing and which works ok in practice.
- pcwalton 7y ago
  I don't see any way in which it won't be way more work to migrate to this proposed WSL than to get my existing SPIR-V tooling working with Web SPIR-V.
  - om2 7y ago
    The actual functionality exposed is close enough that cross-compiling is a solvable problem. But fair point. (On the flip side, having two syntactically very similar but actually different things can be dangerous, as it may lead devs to think some tooling works when it actually doesn't.)
- kevingadd 7y ago
  You can always just cross compile your SPIR-V to GLSL or something. People have been cross compiling between HLSL and GLSL for ages, it's a solved problem even if there are sharp edges.
- kangz 7y ago
  There is no WebGPU dialect of GLSL, only a SPIR-V execution environment for WebGPU. Lnaguages in themselves aren't "safe" or "unsafe", their implementations are. Also please stop trying to influence a technical debate in a standardization group by putting blog posts on top of Hacker News.
  - saamyjoon 7y ago
    You're absolutely wrong here. A language must specify its semantics. Those semantics describe the safety properties of that language.
  - om2 7y ago
    Sorry, I meant WebGL, simply mistyped. As far as posting blog posts, we think this is just as fair as the Chrome team's communication about their own WebGPU implementation, which included a public demo and sessions at Google I/O which were widely reported. As for the post getting upvoted to the top of Hacker News, that's the community's choice, not ours. The initial poster wasn't even an Apple person (afaik). If you are insinuating some kind of vote manipulation then that is inaccurate.
- xigency 7y ago
  Are there any technical obstacles to using GLSL with WebGPU? It's popular with some people. See: https://www.shadertoy.com/ https://www.shadertoy.com/
  - om2 7y ago
    It strangely hasn’t been seriously considered but it might not be a bad option (though it may need a more rigorous reformilation of the spec).
  - slavik81 7y ago
    It might be that browser vendors would be better at writing compilers than GPU vendors, but there were a lot of bugs in GLSL compilers. SPIR-V was introduced to be a simpler format for GPUs to ingest, letting you do the complex parsing up front on your machine (where it's easier to identify and fix problems). The other benefit was that changes could be made to improve the usability of the shading language without having to wait on all vendors to update their compilers. If the change was just syntactic sugar, it could be made without changing the SPIR-V. It's kind of like how you don't need an operating system update to move from C++98 to C++11.
    - saurik 7y ago
      Hilariously, Apple actually considers the shift from C++98 to C++11 something that required an operating system upgrade (they purposefully shipped an ancient version of libstdc++ while disingenuously doing comparisons against only what they shipped, not what had come from upstream, for as long as they could until libc++ was reasonable, which debuted on macOS 10.7--where I will note it was horribly broken due to an LLVM optimizer bug in the specific clang build they used to compile it, so really it wasn't available until macOS 10.8--and as Apple does not believe in static linking, their SDK doesn't have a way to work around this; of course, you can, and I did--by getting the code for libc++, modifying it to use an underlying libstdc++ as the moral equivalent of libc++abi, and statically linking that, which worked great and is frankly what Apple should have done themselves during the transition period :/--it is notable that Apple didn't want people to: they really do mentally model that as an operating system upgrade, which to me is an amazing demonstration of how little they understand of the power and potential of decoupled toolchains).
dman 7y ago
I miss the years where inspite of all its flaws, OpenGL was a non deprecated option on all the platforms. I know it left performance on the table, I know the drivers for some vendors were iffy and I know reasoning about performance across different vendors / drivers / platforms was difficult - but it worked most of the time and allowed me to have a mostly unified codebase everywhere.
- mooman219 7y ago
  This really. I'm still using OpenGL and it's worth so much to have an adequate truly cross platform graphics API. The gfx-hal people are doing good work in Rust for a cross platform vulkan like api, but it's not there yet.
- modeless 7y ago
  You can still kind of have that experience by using ANGLE[1] as your OpenGL implementation. It lets you use the same dialect of OpenGL ES on Windows, Linux, Mac, and Android, with consistent behavior across platforms. ANGLE is the base of the WebGL implementation in Chrome. For WebGPU, we (Google) are working on a new native library called Dawn[2] that will fill the same role that ANGLE does for WebGL. I'm personally hopeful that Dawn itself can eventually be useful as a cross platform graphics abstraction for native apps as well as web apps. There's also Mozilla's gfx-rs[3] in the same space. [1] https://github.com/google/angle https://github.com/google/angle [2] https://dawn.googlesource.com/dawn https://dawn.googlesource.com/dawn [3] https://github.com/gfx-rs/gfx https://github.com/gfx-rs/gfx
  - bla3 7y ago
    That's nice, but it's a pretty big dependency to add.
- pjmlp 7y ago
  Only when "all platforms" leaves out game consoles, which never had full support for OpenGL, besides a timid attempt with GL ES 1.0 + Cg on PS2.
  - 7y ago
pjmlp 7y ago
I rather care about middleware that takes advantage of best hardware integration in each platform, instead of bare bones APIs full of endless extensions, which are only portable in theory, with "portable code" full of OEM specific code paths.
kvark 7y ago
> Please, everyone, just use something that already exists. Says one "who is currently knee-deep in papering over platform incompatibilities", instead of using one of the solutions that do it for you.
- pcwalton 7y ago
  I wasn't referring to pathfinder_gpu. :) (I didn't downvote you.)
gok 7y ago
> 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)NaCL.
- pcwalton 7y ago
  > To anyone who has ever spent time working on a platform API this is deeply insulting. I've worked on platform APIs too. Maybe "almost no cost" wasn't the right phrase, but there's certainly less cost for the platform vendor. > Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users. It's a tradeoff that has to be evaluated on a case-by-case basis. So far I haven't seen arguments for WSL that are compelling enough.
  - lmeyerov 7y ago
    My critique on all of these remains largely the same since we tried doing WebCL: -- Path 1: We do need a leap here, and that leap should be essentially unleashing GPGPU primitives (memory barriers, etc.). The web is a ~decade behind, when we have a chance to 10X+ over what regular apps do. -- Path 2: If not, then pure conservative standards work a la webgl2. Useful, and should take care for politicking to not prevent Path 1 from happening in parallel. It's disconcerting for, ~7 years later, the same problems to keep happening.
- ezoe 7y ago
  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.
  - pjmlp 7y ago
brailsafe 7y ago
What are you working on? I have no experience in graphics development, only a cursory familiarity with some concepts, but can I help? Typical Frontend has kind of become boring now that everything is abstracted and the harder stuff mostly resides in graphics or on the edge. Just haven't really found a way to make that change yet.

om2 7y ago

The only thing that already exists that is provably web-safe is the WebGL dialect of GLSL (which no one seems to like). WebSPIR-V would be based on SPIR-V but in many ways has to be a new thing as well. Edit: I originally said "WebGPU dialect of GLSL" which is not a thing. I meant "WebGL dialect of GLSL", which is a thing and which works ok in practice.

pcwalton 7y ago
I don't see any way in which it won't be way more work to migrate to this proposed WSL than to get my existing SPIR-V tooling working with Web SPIR-V.
- om2 7y ago
  The actual functionality exposed is close enough that cross-compiling is a solvable problem. But fair point. (On the flip side, having two syntactically very similar but actually different things can be dangerous, as it may lead devs to think some tooling works when it actually doesn't.)
kevingadd 7y ago
You can always just cross compile your SPIR-V to GLSL or something. People have been cross compiling between HLSL and GLSL for ages, it's a solved problem even if there are sharp edges.
kangz 7y ago
There is no WebGPU dialect of GLSL, only a SPIR-V execution environment for WebGPU. Lnaguages in themselves aren't "safe" or "unsafe", their implementations are. Also please stop trying to influence a technical debate in a standardization group by putting blog posts on top of Hacker News.
- saamyjoon 7y ago
  You're absolutely wrong here. A language must specify its semantics. Those semantics describe the safety properties of that language.
- om2 7y ago
  Sorry, I meant WebGL, simply mistyped. As far as posting blog posts, we think this is just as fair as the Chrome team's communication about their own WebGPU implementation, which included a public demo and sessions at Google I/O which were widely reported. As for the post getting upvoted to the top of Hacker News, that's the community's choice, not ours. The initial poster wasn't even an Apple person (afaik). If you are insinuating some kind of vote manipulation then that is inaccurate.
xigency 7y ago
Are there any technical obstacles to using GLSL with WebGPU? It's popular with some people. See: https://www.shadertoy.com/ https://www.shadertoy.com/
- om2 7y ago
  It strangely hasn’t been seriously considered but it might not be a bad option (though it may need a more rigorous reformilation of the spec).
- slavik81 7y ago
  It might be that browser vendors would be better at writing compilers than GPU vendors, but there were a lot of bugs in GLSL compilers. SPIR-V was introduced to be a simpler format for GPUs to ingest, letting you do the complex parsing up front on your machine (where it's easier to identify and fix problems). The other benefit was that changes could be made to improve the usability of the shading language without having to wait on all vendors to update their compilers. If the change was just syntactic sugar, it could be made without changing the SPIR-V. It's kind of like how you don't need an operating system update to move from C++98 to C++11.
  - saurik 7y ago
    Hilariously, Apple actually considers the shift from C++98 to C++11 something that required an operating system upgrade (they purposefully shipped an ancient version of libstdc++ while disingenuously doing comparisons against only what they shipped, not what had come from upstream, for as long as they could until libc++ was reasonable, which debuted on macOS 10.7--where I will note it was horribly broken due to an LLVM optimizer bug in the specific clang build they used to compile it, so really it wasn't available until macOS 10.8--and as Apple does not believe in static linking, their SDK doesn't have a way to work around this; of course, you can, and I did--by getting the code for libc++, modifying it to use an underlying libstdc++ as the moral equivalent of libc++abi, and statically linking that, which worked great and is frankly what Apple should have done themselves during the transition period :/--it is notable that Apple didn't want people to: they really do mentally model that as an operating system upgrade, which to me is an amazing demonstration of how little they understand of the power and potential of decoupled toolchains).

dman 7y ago

I miss the years where inspite of all its flaws, OpenGL was a non deprecated option on all the platforms. I know it left performance on the table, I know the drivers for some vendors were iffy and I know reasoning about performance across different vendors / drivers / platforms was difficult - but it worked most of the time and allowed me to have a mostly unified codebase everywhere.

mooman219 7y ago
This really. I'm still using OpenGL and it's worth so much to have an adequate truly cross platform graphics API. The gfx-hal people are doing good work in Rust for a cross platform vulkan like api, but it's not there yet.
modeless 7y ago
You can still kind of have that experience by using ANGLE[1] as your OpenGL implementation. It lets you use the same dialect of OpenGL ES on Windows, Linux, Mac, and Android, with consistent behavior across platforms. ANGLE is the base of the WebGL implementation in Chrome. For WebGPU, we (Google) are working on a new native library called Dawn[2] that will fill the same role that ANGLE does for WebGL. I'm personally hopeful that Dawn itself can eventually be useful as a cross platform graphics abstraction for native apps as well as web apps. There's also Mozilla's gfx-rs[3] in the same space. [1] https://github.com/google/angle https://github.com/google/angle [2] https://dawn.googlesource.com/dawn https://dawn.googlesource.com/dawn [3] https://github.com/gfx-rs/gfx https://github.com/gfx-rs/gfx
- bla3 7y ago
  That's nice, but it's a pretty big dependency to add.
pjmlp 7y ago
Only when "all platforms" leaves out game consoles, which never had full support for OpenGL, besides a timid attempt with GL ES 1.0 + Cg on PS2.
- 7y ago

pjmlp 7y ago

I rather care about middleware that takes advantage of best hardware integration in each platform, instead of bare bones APIs full of endless extensions, which are only portable in theory, with "portable code" full of OEM specific code paths.

kvark 7y ago

> Please, everyone, just use something that already exists. Says one "who is currently knee-deep in papering over platform incompatibilities", instead of using one of the solutions that do it for you.

pcwalton 7y ago
I wasn't referring to pathfinder_gpu. :) (I didn't downvote you.)

gok 7y ago

> 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)NaCL.

pcwalton 7y ago
> To anyone who has ever spent time working on a platform API this is deeply insulting. I've worked on platform APIs too. Maybe "almost no cost" wasn't the right phrase, but there's certainly less cost for the platform vendor. > Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users. It's a tradeoff that has to be evaluated on a case-by-case basis. So far I haven't seen arguments for WSL that are compelling enough.
- lmeyerov 7y ago
  My critique on all of these remains largely the same since we tried doing WebCL: -- Path 1: We do need a leap here, and that leap should be essentially unleashing GPGPU primitives (memory barriers, etc.). The web is a ~decade behind, when we have a chance to 10X+ over what regular apps do. -- Path 2: If not, then pure conservative standards work a la webgl2. Useful, and should take care for politicking to not prevent Path 1 from happening in parallel. It's disconcerting for, ~7 years later, the same problems to keep happening.
ezoe 7y ago
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.
- pjmlp 7y ago

brailsafe 7y ago

What are you working on? I have no experience in graphics development, only a cursory familiarity with some concepts, but can I help? Typical Frontend has kind of become boring now that everything is abstracted and the harder stuff mostly resides in graphics or on the edge. Just haven't really found a way to make that change yet.