Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Given the quality of Khronos SDKs and stubborness to C bindings, that might not be a bad thing.

As they have learned the hard way with OpenCL, most devs like to be pampered with modern toiling.

Heck, it is thanks to Microsoft that we have glTF 2.0, and NVidia for any kind of usable C++ Vulkan bindings.



> Given the quality of Khronos SDKs and stubborness to C bindings, that might not be a bad thing.

None of which has anything to do with SPIR-V? It's a standardised intermediate language, not an API, and it has no dependency on Khronos tooling.


It kind of has, if Khronos never provides anything better, as it has been proven before, hardly anyone will step up to improve it, until the standard starts being put aside in preference to proprietary middleware or competing APIs.


There is nothing wrong per se with SPIR-V to provide anything much better. What you said has indeed nothing to do with the intermediate language itself.


It's relevant to what you choose to use as the standard. A language can be fine on its own terms, but also you should only install it with a layer on top and not by itself.


SPIR-V is fine as a standard. What you put on top and transpile into it should be completely flexible. I.e. no need to mandate higher level languages.

And if anyone wants to make a better higher level language and compiler for it to generate SPIR-V, they are always welcome.


Using C bindings you can plug in any language you want, C ABI is simple. Try that with C++ or anything of the sort, and you'll be in trouble.

If you want to improve quality - anyone can contribute and improve, instead of like Apple trying to sabotage and derail.


Yeah, around 500 boilerplate lines of code to draw a triangle on Vulkan, plus having to going hunting for features that every graphics application requires and all other APIs provide on their SDKs.

With Khronos APIs, every newbie graphics developer learns to build their engine from day one.


It's not so easy to contribute to Khronos.


Surely easier than collaborating with Apple who are extreme lock-in proponents.

See for example projects like dxvk, which affected Vulkan spec:

* https://www.youtube.com/watch?v=1fU4w2ZGxH4&t=12m21s

* http://jason-blog.jlekstrand.net/2018/10/transform-feedback-...

Good luck for such thing happening with anything Apple related.


Spec development? No.

But for bug reports, debugging and fixing bugs in the shader compiler, validation layers, etc they are pretty responsive to issue reports and pull requests.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: