Vulkan 1.0.60 Brings A Few New Extensions

[phoronix]

Phoronix: Vulkan 1.0.60 Brings A Few New Extensions

Vulkan 1.0.60 was released today as the newest version of the Khronos Group's high-performance graphics API...

http://www.phoronix.com/scan.php?page=news_item&px=Vulkan-1.0.60-Released

[carewolf]

All these extensions worries me. What I would want out of an OpenGL replacement is a more stable basis and fewer extensions.

Anybody know if they are planning for instance 1.1 versions with most of the non-vendor extensions required?

[bug77]

All these extensions worries me. What I would want out of an OpenGL replacement is a more stable basis and fewer extensions.

Anybody know if they are planning for instance 1.1 versions with most of the non-vendor extensions required?

What worries me is the number of extensions. Wasn't Vulkan supposed to be a thin, mostly pass-through layer between the hardware and the program?
Now we're sitting at close to 100 extensions for Vulkan vs ~600 for OpenGL. Granted, OpenGL still wins, but where's the promised simplicity? Unless I'm missing something here.

[Gusar]

but where's the promised simplicity?

Vulkan was never meant to be simple. The point of it is to be low-level. As such, it's *more* complex, not less. It takes a lot more code to draw a triangle in Vulkan compared to OpenGL. And that's by design.

[artivision]

Evolves faster than D3D12 and Metal.

[Kemosabe]

Evolves faster than D3D12 and Metal.

Metal? HAHAHAHAHAHA!
I have no idea what Apple thinks it is doing here ...

[bug77]

Vulkan was never meant to be simple. The point of it is to be low-level. As such, it's *more* complex, not less. It takes a lot more code to draw a triangle in Vulkan compared to OpenGL. And that's by design.

Yes, it takes more program code. But does the API really need to be this complex?
I mean, writing in assembly also takes lots and lots (and lots) of lines of code, but the assembly language can be learned in an afternoon.

[jrch2k8]

Yes, it takes more program code. But does the API really need to be this complex?
I mean, writing in assembly also takes lots and lots (and lots) of lines of code, but the assembly language can be learned in an afternoon.

More Extensions != less performance != bloat.

OpenGL problem was never even related to extension is a design problem since the basic core of OpenGL/DX were designed to have synced Serial execution and Driver SIDE memory allocation which make it "easier" but in modern hardware it has become one monster of a bottleneck(in the 90's was the bomb tho) but the driver is the worst possible place to handle memory allocation since there is no way for the application(that actually should know better) to control it and depending on the driver implementation the latency behaves randomly and is basically impossible by design to regulate power efficiently(may no matter much on big fat x86 CPUs but in ULV/ARM is a real huge problem and this is counting the fact OpenGL ES design is less retarded than full OpenGL).

Vulkan does not suffer from any of the design problems of OpenGL/DX and for those that fail to get what extension actually are, is basically hardware specific features or missing functionality(that is not yet supported enough across vendors to move it into the Core specification) that does not affect performance in any way or add bloat since is not a library or an executable or any of the sort that will uselessly take resources at runtime in any way unless you specifically use it in your Vulkan code and it that case you actually are using it so it stop been useless.

Vulkan is more programatic simply for the same reason ISO C is more programatic that PHP, is lower level so it let you optimize closer to what the actual hardware does instead of using generic approaches internally and hope for the best and the extensions will keep coming in the future simply because you can now use the hardware more directly and unlike x86/ARM/PowerPC there is no standard hardware implementation or feature set(in your example you will have to learn at least 6 completely different types of assembly because unlike CPUs each GPU assembly is vendor specific, so see Vulkan as an vendor neutral higher level GPU assembly abstraction(Like C on the CPU world)), also remember GPU uses also evolve over time so you need extensions to stay on top of new design paradigms instead of completely redesign Vulkan every year(Like C on the CPU world)

Its also important for anyone going into Vulkan, be careful and test your code in several GPUs because some of the extension are vendor specific as in only that vendor(or vendors) have the actual silicon for that specific feature and this extension may fail or fall back to emulation on other vendors GPU(in the same way AVX2 won't work on PowerPC but you can get close or the same functionality using the vendor specific Altivec but the rest of your C code should work just fine). This is why those are extensions are not in the CORE specification.

about the complexity question, yes it has to otherwise it gets in your way like OpenGL does and also you should stop assuming GPU grade assembly is even remotely close in complexity to CPU assembly since you will be wrong by several orders of magnitude also you should stop assuming GPU assembly between vendors are even close to each another enough because they are GPUs because you will be again wrong by several orders of magnitude. if you don't believe this then simply see AMD specific assembly and lets say Qualcomm Adreno specific GPU assembly for the same functionality, is like learning French and then try to use it as a base to speak Korean

[andre30correia]

the big problem here is vulkan become stable and stop this upgrades every week

[bug77]

jrch2k8 A very insightful post that completely misses my point.
As we have both noted, the lower you go, the simpler the language/API becomes (I used ASM as an example, you used C and PHP). I never meant to imply that Vulkan is bloated or something. I just stated I don't understand why it seems to rival OpenGL in complexity, instead of being a leaner API. In my understanding Vulkan should be a "here are your primitives, knock yourself out" API, but it appears it's not.
And again, I'm not accusing Vulkan of any wrongdoing, I'm simply wondering what am I missing.