The Vulkan API

[robmar]

Be nice to give Vulkan a test with Irrlich

[Mel]

Writting the video driver could prove an interesting challenge indeed

[Mel]

Vulkan bumps into 1.1!

https://www.khronos.org/news/press/khro ... vulkan-1-1

Among other features, the multiple GPU support is now part of the core of Vulkan 1.1, besides some synchronization facilities for the shaders to work in parallel and the usage of protected memory allocations (i.e. memory that is not possible to pick out from the API via transfers, enabling the potential usage of content protection schemes via external libraries, this, alongside a new sampler that reads YCB images, makes me believe it is for video playing within VK.

Also, there is the initiative to port a subset of Vulkan over Direct3D12 and METAL to allow VK applications to run on systems that only allow closed APIs such as MAC IOs and Win10 mode S, or the Universal Windows Platform. (but instead of being Microsoft or Apple doing a port of the API to their systems, with the forgetable OpenGL implementation Microsoft did over Direct3D to promote their API and damage OpenGL image in the process, it is done by the community)

[devsh]

I like low level work and filling buffers manually and exposing the whole API, but Vulkan is soo verbose it makes me s**t myself.

Don't hold your breath for Vulkan in irrlicht.

[Mel]

It is tedious indeed. I've said many times Irrlicht design doesn't map well to Vulkan, but to OpenGL.

[devsh]

We're doing it, but only because we need/want Android support.
https://github.com/buildaworldnet/Irrli ... projects/3

P.S. Irrlicht design maps only to DirectX 9, thats why we have stuff like lock() and unlock() as well as names such as RenderTargets and not FrameBufferObjects or Attachments or DrawBuffers.

[Mel]

And that's the reason i got really confused when i started messing with vulkan =.=U
In Android you want to get along with the renderpasses/Multipasses well, as well as transient images and memory, the drivers use that information to optimize internally the usage of tiled renderers, and reduce the memory footprint.
https://www.youtube.com/watch?v=M1M5z39q2i0

[devsh]

Already on it.

All GPUs and architectures benefit from subpasses, even AMD that doesn't make tiled renderers, it helps to let it know if they need to clear the framebuffer or decompress/compress it, as well as what rendering operations can run in parallel.

P.S. Nvidia Maxwell and onwards are tiled.

[Mel]

Enables cache optimizations on AMD. Even if it is a bit of a nuisance to manage all the renderpass/subpass thing from the shaders point of view, the performance gains are worth.

NVidia is working on a raytrace extension for Vulkan
https://www.phoronix.com/scan.php?page= ... ing-NVIDIA

[devsh]

Funny that even making an OpenGL engine work a little bit like vulkan will give you 50-100% perf boost even using a single core

http://irrlicht.sourceforge.net/forum/v ... =2&t=52265

[devsh]

Vulkan is amazingly painful.

This is how many objects and reference counted interface objects I had to come up with to replace the simple SMaterialLayer and without the Texture member!
(although to be fair, I did it to avoid using a wierd SMaterialLayer+E_MATERIAL_TYPE to Vulkan Objects associative cache and the new objects deal not only with textures but with SSBOs, UBOs and storage images)
https://repository.genmymodel.com/devsh ... lineLayout

[robmar]

Looks the the Vulkan EZ wrapper would make the job a lot easier to do.

https://www.gamingonlinux.com/articles/ ... pper.12414