The Vulkan API

[Mel]

I guess you've heard of it. Called initially "GL Next", suposedly its release is almost imminent, and they promise big things, such as multithreaded safety and thus, multiple cores support. Among its features, besides the mentioned multithreading support, they claim it to be a low level API with direct control over the GPU, uniformity across platforms (mobile and computer sharing the same API), a single binary representation for shaders, external shader compilers (which will support GLSL, among other stuff) and more stuff that I sure forget to mention now.

Coming out of AMD's MANTLE API, donated for the project, and adopted by the other major vendor of GPUs, NVidia, it promises to put order in the world post Direct3D, and finally offer a consistent alternative to Direct3D12.

Yay? Nay? Things look promising (though i bet they aren't exent of any sort of bias so the transition is easier...) But they promise big things, the ones i like the most being the independence of platform, and the development of the Vulkan drivers directly by the hardware manufacturers for the diferent platforms (so there are no ill manners this time on MS's behalf to promote D3D over the competende...)

This is a demo showing it in motion against OpenGL ES...

https://www.youtube.com/watch?v=P_I8an8jXuM

I won't enter in details, obviously, Vulkan wins there, but i think it would be good that the miriad of GL extensions and GL heterogeny (and the single core dictatorship XD) was finally gone, superseeded by an API that unified the good things of GL and offered processing power for all.

[CuteAlien]

It's the kind of tech for which you have to love getting very close to the metal. As I understood it's feature is basically having less abstraction being done by the drivers. Like shaders gave you full access to the drawing pipelines instead of offering a few fixed functions, this should more or less give you access to the memory management.

[hendu]

A hello world triangle program was 500 lines IIRC. And it doesn't run on any of my hardware, so hard to care

[Mel]

I see it as the next logical step. Currently there are still limitations, namely for instance, texture stages amount. Imagine that you can transfer blocks of memory and you define your own routine to sample that memory block as a texture. You can have any amount of textyres accessed from a shader, and Vulkan, perhaps, could manage the cache misses and hits, while you can still sample your textures as you wish. This for instance, removes the needs for special texture stage states or registers, simplifiyng that task. No more overhead in texture stage samples, if you want to sample other way, write another sampler, The same goes to the raster operations. You define, for instance, a vertex processor, this vertex processor knows implicitly that another segment of memory you provide it has a specific layout, position, normal, texture coordinates, etc, but instead of providing the output of the vertex processor to a raster routine, also customised, you provide it to another routine that is able to tesellate this geometry, and this is fed to another routine that process the whole stuff. Say this routine is able to render quads instead of triangles (for example) all done in the GPU.

From the CPU you just ask this or that processor to work, and the rest is up to how you've done it and Vulkan setting the appropriate fences. I think it is pretty interesting. It may require a lot of work, i won't deny it, and probably, it won't go down to the point of reinventing the wheel, but when i hear about that it goes to low level, i can't help but just imagine you programming everything, and working from that. It is basically, reducing everything to compute on the GPU, and use the API to compile shaders, set the contexts and transfer the memory, and pretty much, that would be it.

[devsh]

if you use core OpenGL 4.1+ with new ways of doing stuff (texture storage, buffer storage, DSA) jumping to Vulkan should be a very small step

[Mel]

From what i've seen also, Vulkan is "explicit" in the meaning that everything it does has to be explicitly told to the API, for instance, texture loading in some cases are deferred until the time of the first usage. In Vulkan, if you tell the system to load a texture, it loads a texture, end of it. Relies more on the programmer to do stuff, and less in driver optimizations. Also, if what i've seen really works that way, operations such as locking and unlocking make no sense anymore, as the GPU memory is directly mapped on system memory, and if you write to a certain memory adresses, you write into video memory directly, for video streaming purposes, that may provide an advantage as well, as you write and read directly from that memory. The more i read, the more i am liking this thing.

Surely GL and Vulkan will share traits so the transition is the least traumatic possible XD

[chronologicaldot]

Sounds intriguing. If memory management is directly controllable, it may allow for better (and by that I mean easier) voxel management on the GPU. hm...

Even still, as with hendu, nothing I have supports it, which puts it out of reach for the time being.

But yeah, looking forward to it at least. It'd be nice to have an easy transition from OpenGL. The next problem would be finding someone to write the driver for irrlicht - Seems to be a bit harder to do, lol. XD

[Mel]

More than that, the most important thing that i think it should do is to efectively make use of multithreading. From that standpoint, perhaps it should be a separate project, as the scene manager, the loaders and the absence of fixed pipeline would make much of a diference for the current architecture to achieve its true potential under Vulkan (The same thing goes for D3D12, or so they say, eventhough that is as limiting as WIN10 only currently ). Maybe that could finally be Irrlicht 2.0? the multithreaded friendly version of irr?

With regard to the memory management, i've read some crazy things... and perhaps with irrlicht's current system of grab/drop, the "hideous" memory leaks inside the video drivers may finally end, as, esentially, everything is directly accessible. You just have to "tell" vulkan the things you want. The example i saw was this: to make a video texture you have to create your own texture in system memory, ask Vulkan for a memory pointer in videomemory, and memcpy the system memory to that memory. If the memory is copied, what tells you not to release your own memory and work from that point on with the texture in video memory?, No more "shadowed" memory, which in my opinion is a redundancy on some cases. If you wanted to handle video memory so you move in and out textures so you can use more memory than what the system has actually, is a posibility.

In the end, it should be seen if that posibility is actually real or not but it could mean no more "lock" function to read a texture. the reads can be concurrent, the writes are what need to be syncronised between the threads.

[mongoose7]

Asking for a pointer to video memory *is* a lock. You may be reading more into the interface than is actually there.

[Mel]

Dunno. Probably. When we can have some hands on the actual API we might see. The example I saw was this:

[mongoose7]

Staging buffers? So, you are not interacting with actual device buffers. So, the API may be "explicit", but it is just a model for how the OpenGL driver may be working today. They certainly aren't allowing you to access the device memory, though they are giving you a model for it.

[Mel]

Hmmm... i guess that the part that lost me was that the pointer could remain mapped while in use... :/ Anyway, i've indeed read that the "reads" can be concurrent, that and that the memory may remain mapped made me think that you could always read from a texture. Anyway, I hope they have more stuff under their sleeve

[mongoose7]

In a PPT you don't have to talk about unmapping memory

[Mel]

Guess so... anyway, i see that most of the weight of the API is in multithreading and explicit control. real time graphics programmers will finally have to learn how to multithread XD

That makes me think that if you could, instead of sending commands concurrently to create a single scene, you could create 2 scenes at a time (namely gbuffer creation and shadowmap creation), that would definitely boost stuff like crazy.

[sunnystormy]

Vulkan was released today:

http://www.phoronix.com/scan.php?page=a ... n-10&num=1