Vulkan Tutorial

Re:Vulkan Tutorial by shmerl on Monday July 18, 2016 @04:27PM (#12117871)

It's not better, it's lower level than even Vulkan, and Vulkan itself is already very low level. Sure you can go as low as hardware specific machine code in theory. The question is whether it's something needed, or it's an overkill for most intents and purposes.

Consoles had a distinct need for assembly like level APIs - their hardware had very long update cycle (7+ years), so it used to quickly become outdated, and developers had to go to insane lengths to squeeze performance out of it. It's not only very costly to do it, it can't be reused (it's all platform specific). Currently consoles are moving away from these long cycles (under competitive pressure), so need for that will be less as well.

[ Parent | on HN ]

Re:Vulkan Tutorial by zanny on Monday July 18, 2016 @10:47PM (#12119229)

There is also the fact that in modern CPU-side development you will find it almost always is a bad idea to try to drop to assembly micro-optimization. Your compiler is going to almost always do a better job optimizing the general case into an optimal set you won't be able to easily implement in raw ASM, especially when you start using vectorization instructions.

The same concept applies to Vulkan / DX12. The hardware manufacturers will know better than any developers about per-device shortcuts to put into their drivers, and if they do not need to maintain millions of LOCs of OpenGL state machine and validation layers they might find time to optimize the shader compiler to be in the same class of "the compiler is smarter than you" reasons not to use a hard ASM language.

In the case of consoles, all of them are using AMD based graphics, and when the next generation comes out they will all be on a similar cadence of GCN. I cannot imagine in what world an optimized AMD SPIR-V compiler that AMD already needs to write for the desktop and mobile won't beat 99% of developers on both the Sony / MS / Nintendo and 3rd party sides trying to microoptimize RadeonSI ASM.

[ Parent | on HN ]

Re:Vulkan Tutorial by shmerl on Monday July 18, 2016 @11:19PM (#12119342)

> I cannot imagine in what world an optimized AMD SPIR-V compiler that AMD already needs to write for the desktop and mobile won't beat 99% of developers on both the Sony / MS / Nintendo and 3rd party sides trying to microoptimize RadeonSI ASM.

Good point. Today not to provide Vulkan on consoles is a political diversion (to make cross platform development more costly by taxing developers with doing the same thing multiple times).

[ Parent | on HN ]

Re:Vulkan Tutorial by pcwalton on Monday July 18, 2016 @11:57PM (#12119504)

> There is also the fact that in modern CPU-side development you will find it almost always is a bad idea to try to drop to assembly micro-optimization. Your compiler is going to almost always do a better job optimizing the general case into an optimal set you won't be able to easily implement in raw ASM, especially when you start using vectorization instructions.

I agree. In fact, the fact that it's not even a good idea in most situations to write in assembly on x86 CPUs proves the point even more. GPUs are less willing to spend die space on things like sophisticated branch prediction, complex superscalar architectures, register renaming, and so forth. This effectively means that GPUs punish naive codegen (which is the kind of codegen that humans without in-depth knowledge of the architecture tend to produce with their brains) significantly worse than x86 CPUs do. For an extreme example, look at the vector part of the low-power VideoCore IV architecture [1]: compared to a compiler, I don't trust myself for a second to program this optimally.

[1]: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...

[ Parent | on HN ]