61–70 of 98 posts
Earlier quoted context omitted.
AIR is not a documented or supported endpoint. MSL is the supported endpoint. You will hear from Apple's lawyers if toy reverse engineer AIR, as one of my colleagues knows from experience.
I thought AIR was just LLVM bitcode.
I'm really rooting for WebGPU as the "cross-platform 3D-API for the rest of us" (where "rest of us" is everybody who isn't a highly specialized rendering engineer in an AAA-game engine team). There's "one small thing" I'd like to see in WebGPU for the native use case: an optional compile-time configuration feature which allows to pass in "backend-native" shaders so that all the runtime-shader-translation code isn't n…
Given that any most implementations of WebGPU will be open source it should be trivial for you to add a way to use pre-compiled native shaders to whatever implementation you choose to use.
Sounds promising — would be great to know the history on why the other people who tried to make the one graphics api to rule them all failed? Seems like that could be helpful in the whole “learning from the past thing”.
Because hardware vendors don't want one. Lock-in when you are leading your particular niche gives big profits, so companies go for it. That is why Microsoft, Sony, NVIDIA, Apple, Xilinx, etc. create their own platforms and APIs.
Earlier quoted context omitted.
It's literally in past WebGPU meeting minutes: Apple objected to SPIR-V due to disputes with Khronos. Tint is a compromise, it doesn't matter who proposed it. "MS: Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re di…
I know, I was there. I also think that objection to SPIR-V wasn't completely unfounded. SPIR-V is a nice binary representation of shaders, but it has problems in the context of WebGPU adoption: 1. It's so low level that generating HLSL and MSL from it is more painful than it could be. For example, it represents branching in the form of a Control Flow Graph (which is typical for an IR). This is lower level than either…
There’s a lot of opinions from people outside the working group for WGSL as to why it exists.
I think most of the PR damage right now comes from those people not having enough context and thus framing it in a negative light.
A blog post with more context and information would probably help imho
Earlier quoted context omitted.
> where "rest of us" is everybody who isn't a highly specialized rendering engineer in an AAA-game engine team Then you should be looking at WebGL, not WebGPU!
No, WebGPU will be easier to use than WebGL, because it doesn't have the global state. Global state is the worst thing about OpenGL and requires a lot of code to get it under control.
WebGPU is a low-level API is more flexible than WebGL, which means more complexity. That is why it is being introduced, after all!
Earlier quoted context omitted.
I thought AIR was just LLVM bitcode.
It is, but that won't do anything about overeager lawyers.
Earlier quoted context omitted.
I don't think getting into OpenGL is actually that hard. There are wrapper libraries, e.g. for Java, and tons of tutorials. The hardest part for beginners is probably wrapping their head around the concept of the rendering pipeline, with it's various stages. Once this is settled, it becomes much clearer what the various shaders do and how they interact with each other. So I'd higly recommend spending some time to und…
OpenGL isn't hard, but it's API is outdated and full of surprises. Error reporting is bad (glGetError), debug context works somewhat better (error callbacks), but I had errors that reproduce on debug context only. C API is very weakly typed, so it's easy to pass GL_RGBA to a function which expects GL_RGBA8. But the worst part of OpenGL is the state machine. OpenGL is the only graphical API still remaining that has th…
WebGL is better than that because it is only the useful, fast subset, and provides some objects too. Plus JavaScript is easier to work with than C, too.
Anyway modern APIs are not stateless, having an object that contains the state is the same. In the end, it is still all about bind this, bind that, do this, do that.
Earlier quoted context omitted.
Except going forward, those are going to be the only APIs available, regardless of one is doing AAA or not. It would be the same as using SVAlib or Allegro nowadays. They are still there, but not longer map to existing graphics hardware.
> Except going forward, those are going to be the only APIs available That is false. There are already library implementations of legacy OpenGL, modern OpenGL, OpenGL ES, WebGL, legacy Direct3D, Direct3D 10/11, Direct3D 12, Vulkan and others. Major players like Microsoft, AMD, Khronos, Valve and others already depend and employ people on providing those APIs and libraries long-term. Those APIs are not going anywhere,…
That is like telling someone that coding against POSIX.1 is all they will ever need for their applications.
Web and client-side WebAPI has security first in mind. The conception of WASM and WebGPU is pushing Web into wider audiences and influence, taking up what used to be OS' market. On the OS side, Google the capability-based OS Fuchsia. Someone in Google understands that user's consent over their computation resource (file/directory, network) is more important than ever. And then there's WASI where it will enable OS to…
What I am missing is not a Web replacing operating systems, but better operating systems!