Vulkan released, do we care?

[jrago...@gmail.com]

Yesterday Khronos released Vulkan, with SDK, drivers, and examples, at khronos.org/Vulkan.

My question is does go-gl as a developer group care?

In the past, I've argued "no" because Vulkan isn't really meant for people to use. It's a backend -- a "so you want to write your own OpenGL" sort of thing. I think that, philosophically, it doesn't mesh with Go (manual graphics card memory management at a much finer level than GL), and the entire thing is a such a morass of parameter setting function calls that Go would likely choke on constantly suspending the runtime, unless either we or the Go compiler implement some sort of call batching. My opinion hasn't really changed. I think writing a Go graphics middleware on top of Vulkan would be appropriate, as would a Go->SPIRV pseudo-compiler, but everyone probably needs more experience with Vulkan until a sound design can be made for the former.

Thoughts?

[Some-Punk]

Well I am interested in learning about Vulcan, but I wouldn't know where to begin to help with a wrapper (at the moment).

Basic questions:

- Did golang 1.6 changed anything significantly that makes working with a c api difficult/different?
- Can the current method of generating the golang wrapper for opengl be applied to vulkan?  This must be more complex because memory management is pushed onto the consumer of the api as I understand it.

I would like to see a library that makes working with vulkan easier, but this forum isn't very active unfortunately.

[Duke Abbaddon]

#vulkan is vastly faster ... here are some #tools

http://lunarg.com/vulkan-sdk/

https://community.amd.com/community/gaming/blog/2016/02/16/radeon-gpus-are-ready-for-the-vulkan-graphics-api

https://developer.nvidia.com/Vulkan

https://www.khronos.org/vulkan/