161–170 of 186 posts
Earlier quoted context omitted.
Considering that Apple is a Promoter Member of the Khronos Group, I doubt this.
They created OpenCL and supported OpenGL (ES) as the only graphics API on their platforms for years, but now they have dumped both open standards in favour of their own proprietary ones.
Earlier quoted context omitted.
They created OpenCL and supported OpenGL (ES) as the only graphics API on their platforms for years, but now they have dumped both open standards in favour of their own proprietary ones.
Actually they created Quickdraw 3D, and only adopted OpenGL as the NeXT team came onboard. Although they created and gave OpenCL 1.0 to Khronos, they were not happy with the path that Khronos was taking it and their support basically stagnated on OpenCL 1.0. As side note Google is yet to support OpenCL on Android, instead just like they did with their Android Java, they decided to create their own flavour, Renderscri…
Is it really though? Vulkan is based on AMD Mantle which AMD gave to Khronos. AMD Mantle (2013) predates Apple Metal (2014).
Earlier quoted context omitted.
> The spec has a semantics that describes that the language does when executed in great detail. Here's what the WSL specification says about loading a texture, one of the simplest possible features of a shading language, but one that introduces a lot of complexity (again, to load a texture requires calculating an LOD, which requires talking about derivatives and scheduling pixels and shader execution in terms of quad…
> The WebGPU working group does not currently have any participation from AMD or NVIDIA. Khronos and the SPIR-V working group do. I trust them to get these details right. On the other hand, the SPIR-V working group has no participation from Apple or Microsoft (vendors of relevant platform APIs, relevant shading languages, and in Apple's case, of relevant GPUs). You might argue that Apple should join the SPIR-V group…
Nobody inside the WG but Apple wants WSL.
Earlier quoted context omitted.
I think we should focus more on the advantages and disadvantages of WSL and SPIR-V, and their relevance to existing or future ecosystems -- not debate over which language had the first web tests.
When someone says one option is a nonstarter because it's new and immature, I think its fair to look at different signs of maturity to evaluate that statement. (I personally don't think any option is a "nonstarter" but it's hard to even get agreement on the relevant evaluation criteria.)
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 player…
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.
We still don't know when Apple will actually remove GL from their platforms, but since the backlash will be so huge, it might be a while. And even when they do, the first step of 95% of code-bases that rely on GL will be to link in some GL on Metal emulation library. The net effect will be a slight performance drop for Apple vs other platforms. Well done Apple.
At some point switching to Vulkan (and Vulkan on Metal for Apple, or the reverse if you're an Apple centric developer) may be worth it, but for the moment the amount of apps and games that will see close to identical performance in GL and Vulkan is still huge. If you are e.g. geometry/shader/memory bound, you'll see exactly 0% speedup from API changes. You really need to be pushing significant amount of draw calls to see a difference. If you're not doing this, its worth "hanging in there" with GL to see if the post-GL landscape de-clusterfucks itself in the meantime :)
Earlier quoted context omitted.
They created OpenCL and supported OpenGL (ES) as the only graphics API on their platforms for years, but now they have dumped both open standards in favour of their own proprietary ones.
Actually they created Quickdraw 3D, and only adopted OpenGL as the NeXT team came onboard. Although they created and gave OpenCL 1.0 to Khronos, they were not happy with the path that Khronos was taking it and their support basically stagnated on OpenCL 1.0. As side note Google is yet to support OpenCL on Android, instead just like they did with their Android Java, they decided to create their own flavour, Renderscri…
I'm not talking about pre-NeXT Apple, that's ancient history.
Earlier quoted context omitted.
Turns out that the intersection is already a huge advance over WebGL, and that much of the stuff outside the intersection is of marginal value or even outright regrettable.
How can you make such a massive claim? Did you read all of Vulkan extensions?
Earlier quoted context omitted.
When someone says one option is a nonstarter because it's new and immature, I think its fair to look at different signs of maturity to evaluate that statement. (I personally don't think any option is a "nonstarter" but it's hard to even get agreement on the relevant evaluation criteria.)
It's not "new and immature." It has a formal specification and is used in production on devices/pcs everywhere. The comment itself was sort of vacuous and nitpicking a single aspect which is something that could be remedied through collaboration.
Earlier quoted context omitted.
The proposal from SPIR-V advocates is to not ship any high level language compiler with the browser. That could change, but currently no one is excited about accepting both a binary language and a text-based language.
Why would you expect people to ship a compiler though? Like: when I want to do runtime code generation on .NET, I don't concatenate strings containing C# and run them through a C# compiler... that would be madness!!... instead I use the APIs provided to do IL generation, which have been extremely amazing essentially since day one and provide unbounded flexibility over working with any specific textual language. If I…
Earlier quoted context omitted.
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.
OpenGL is STILL viable today. You can use a shared subset of ES 3.x and Desktop GL 3.x, and the amount of places where you need to if/#ifdef because of differences is vanishingly small (mostly some minor shader decls). Certainly don't need a giant library like ANGLE to do this. We still don't know when Apple will actually remove GL from their platforms, but since the backlash will be so huge, it might be a while. And…