Low-overhead rendering with Vulkan on Android | Hacker News Reader

Low-overhead rendering with Vulkan on Android

android-developers.blogspot.com

43 pointssam4211 comments

It's great that Google Android will support Vulkan. Now, the support list seems to be: Android, Windows, SteamOS, Tizen, and many Linux distributions including Ubuntu and Red Hat. [1]

It's sad that it doesn't include Apple, most likely because they have now their Metal API.

[1] http://venturebeat.com/2015/08/10/khronos-wins-support-from-...

EDIT: here's another list of hardware vendors: AMD, ARM, Intel, Imagination, NVIDIA, Qualcomm, Samsung.

https://www.khronos.org/news/press/khronos-expands-scope-of-...

I'd love to see a WebVulkan [0], as wrestling with WebGL's setup is really a slog to get it to work predictably in the way you want.

WebGL is making progress via extensions with Uniform Buffers, instanced geometry, etc., but as most people end up using e.g. Three.js, it seems like exposing a sane, more fine-grained API would help everyone.

[0] Knowing full-well that WebVulkan naturally won't magically solve any performance issues, and seems to be a very different beast https://twitter.com/Tojiro/status/628660898756825089

I think WebVulkan would be great with WebAssembly! The nice thing about those technologies is that they are low-level APIs, which means less rooms for bugs.

WebGL, HTML, DOM, and most other web technologies suffer from not being consistent and they are full of bugs. How many graphics cards have been blacklisted from WebGL because the drivers don't have the required features or have too many bugs? [1][2]

[1] https://www.khronos.org/webgl/wiki/BlacklistsAndWhitelists [2] https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drive...

Can someone knowledgeable tell me if Vulkan is a good API? I've heard that OpenGL is a bit of a mess (maybe DirectX is too?), did they get it right this time?

Good by what measure? Very little is public so far, though we are likely to see more come out during SIGGRAPH. It is expected that Vulkan will be very similar to Metal and DX12. They are all designed to be simple but hard in the "Simple made Easy" sense. For example, in Metal you can update part of a buffer using memcpy Is that better or worse than glBufferSubData? (yes, yes. gl has mapped ranges too)

A year ago I wrote a bit about how OGL3 and D3D9 were well designed for the hardware when they came out. But, the hardware has changed dramatically since then. After a decade of incremental changes, graphic APIs really needed a clean break from the past to move forward. https://news.ycombinator.com/item?id=8146533

Vulkan is still in development. I don't believe anything about the api is published yet.

But you can check out the SPIR-V IR spec which is almost finished:

https://www.khronos.org/registry/spir-v/

Not only the Vulkan API but new programming languages will target this IR, so far it appears to be an innovative architecture for concurrent software, that integrates graphics and compute, not a bolt-on like OpenCL.

I know next to nothing, but it seems that the situation became a huge absurdity where game devs had to write ugly hacks around OpenGL, that the graphics card drivers would have to interpret and optimize when and if it could. Double blind, the wrong way.

Vulkan aims at doing less but predictably so, devs will have more work to put in at first, but at least they understand what going on.

see this thread for a comparison demo https://news.ycombinator.com/item?id=10034574

This is worth reading: https://news.ycombinator.com/item?id=9193521

>Vulkan aims at doing less but predictably so, devs will have more work to put in at first, but at least they understand what going on.

The engine devs will probably know exactly what's going on and be able to optimize accordingly. The actual game/application devs will probably get a new, easier-to-use black box and be extremely happy about it.

Amazing link.

> So the game is guessing what the driver is doing, the driver is guessing what the game is doing, and the whole mess could be avoided if the drivers just wouldn't work so hard trying to protect us.

That was what I've read too.

All in all the 3D world is a massive clusterfk blend of many common failure seen elsewhere. Trying to hide too much backfires.

I don't know if Vulkan will influence hardware design toward something more regular, and ultimately open source drivers (a long unicorn, the most blatant missing part of the mainstream open source adoption)

I'd suggest reading this article which is full of historical and technical detail and i enjoyed it very much: http://programmers.stackexchange.com/questions/60544/why-do-...

(The article doesn't touch Vulkan but the state of DirectX vs OpenGL)

Reply on news.ycombinator.com