4 ms·
With great power, comes great responsibility. For those who don't prefer this level of abstraction, just use a higher level zero cost abstraction.
by foodmart 11y ago
With great power, comes great responsibility.
For those who don't prefer this level of abstraction, just use a higher level zero cost abstraction.
- samstave 11y agoThis might be a completely ignorant question; How can there not be an drawing app built on top of this so that you can just model/draw and have it translate??
- 0942v8653 11y agoThere will be. That's open source's job. Vulkan isn't a complete replacement for OpenGL; it's a GPU API aimed to be built upon.
- Turbo_hedgehog 11y agoThe goal is to have a cross-platform low level API that can be easily tested for compliance/conformance, right?
- azernik 11y agoAlso one that exposes graphics card mechanics so that higher-level tools can use them more intelligently for optimization purposes. A good analogy is the RISC transition - implementations were made easier and faster, but as a tradeoff assembly was made much more difficult to program in. The idea being that only a small group of tool-makers with specialized knowledge of the underlying mechanics (in that case compiler developers, in this case engine developers) would ever have to deal with them.
- whatever_dude 11y agoThere will be. The point of Vulkan wasn't to change the OpenGL API to something else. It was to expose more of what the inner workings of a modern graphics card is, and to remove ambiguity introduced by higher level abstractions used by OpenGL. It is more of a direct translation of what can be done with a graphics driver. This means that developers (engine writers) who want to can now get a lower level access to what the graphics card can do, and do so in a more deterministic fashion. Everyone else will be able to use higher-level abstractions that will undoubtedly appear, and those probably be easier to use than OpenGL itself. Best of all, they'll be open source so anyone can dig in and tweak (or understand) something rather than forever depend on some obscure OpenGL behavior no one really understands. There will be growing pains. The existing engine codebases are heavily based on OpenGL, as are helper libraries. That will need to change. Things won't just be faster overnight. But judging by what I read, in the long run it will be better for everyone involved.
- sdegutis 11y agoI don't know, I feel like D3 solidly demonstrated that you can have absolute configurability without sacrificing any conciseness.
- hodwik 11y agoD3 is not concise compared with most simple js graphing libs -- e.g. highcharts.
- scardine 11y agoI agree, but it is not fair to compare D3 and highcharts because they are not in the same league. There are many higher level libraries leveraging on D3 that could be compared to highcharts. There are also many lower level libraries that have the same scope as D3, and compared to most of them D3 is pretty concise - the parent comment has a point.
- ajross 11y agoD3 is not remotely an abstraction API for a hardware compute engine. Vulkan isn't about "configurability", it's about cleanly expressing the specific operations that the hardware can perform, and the specific requirements for talking to it. Those are complicated, inherently. Data graphing, fundamentally, is "simple" in comparison (and to be fair, D3 exploits that beautifully).
- deleted 11y ago[deleted]
- Narishma 11y agoThe higher level abstractions aren't zero-cost.
- lmm 11y agoNo reason they can't be.