The Vulkan API

[Mel]

I am taking a look at it already, something has called my attention uppon close inspection...

Code: Select all

 
VK_FORMAT_R64G64B64A64_SFLOAT = 121,
 

256 bit rendertargets?! XDDDD

Also, they're using CMAKE for the samples. Seems they've taken seriously the initiative to make it completely multiplatform.

edit: 'kay, haven't done a thing, not yet but i am taking a look at the API now, and while it is a bit "frightening", looks crystal clear. I hope things keep this clear on further updates and that i can catch a glimpse of it (if i get to render something on my own without burning my GPU i'll be really happy XD) . So far, i am liking it. It doesn't set you a sort of wall you cannot trespass so you never really know what do you have to do to start. On the other hand, it is like D3D was ripped open and all its guts exposed to you so you can really choose what to do or what not. Pretty much it seems what they said. You need to tell the API what to do or what not. And the API won't do what you don't tell it to. Straight to the point.

[devsh]

We're sitting waiting for Intel to announce their new drivers, if Ivy Bridge will be supported, then Vulkan will be our primary renderer.

[Mel]

Sounds nice Seems you're being able to catch up with vulkan pretty quick, too bad i am not used to GL but nothing to do with the infamous D3D samples, compared to the vulkan ones =.=U

I've tested the nvidia drivers on win... so far, so good. nothing fancy actually, but they work.

[sunnystormy]

@devsh

There's this:

http://www.phoronix.com/scan.php?page=n ... -Published

Hopefully that sets up some expectations?

[Virion]

Vulkan 1.0 has been released!

https://www.khronos.org/news/press/khro ... cification
http://arstechnica.com/gaming/2016/02/v ... md-driver/
http://www.phoronix.com/scan.php?page=a ... n-10&num=1

[Mel]

I've been scratching the belly of vulkan a bit... at least, something works...

Code: Select all

 
#include <vulkan\vulkan.h>
#include <iostream>
 
void main()
{
    //Vulkan application parameters...
    VkApplicationInfo vkApp;
    vkApp.sType = VK_STRUCTURE_TYPE_APPLICATION_INFO;
    vkApp.pNext = NULL;
    vkApp.applicationVersion = 1;
    vkApp.engineVersion = 1;
    vkApp.pEngineName = "Hello Vulkan";
    vkApp.apiVersion = VK_API_VERSION;
    
    //Vulkan instance creation parameters... There are NO DEFAULT values, everything is necesary or else IT MIGHT BE INITIALIZED TO TRASH!
    VkInstanceCreateInfo vkInfo;
    vkInfo.sType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO;
    vkInfo.pNext = NULL;
    vkInfo.pApplicationInfo = &vkApp;
    vkInfo.enabledLayerCount = 0;
    vkInfo.enabledExtensionCount = 0;
    vkInfo.ppEnabledExtensionNames = NULL;
    vkInfo.ppEnabledLayerNames = NULL;
 
    VkInstance instance;
 
    VkResult RESULT = vkCreateInstance(&vkInfo,NULL,&instance);
    uint32_t gpuCount;
    
    if(RESULT==VK_SUCCESS)
    {
        std::cout<<"Hello Vulkan!"<<std::endl;
 
        //Let's see how many devices does the vulkan driver report...
        vkEnumeratePhysicalDevices(instance,&gpuCount,NULL);
        std::cout<<"Enumerating devices... "<<gpuCount<<" device(s) found"<<std::endl;
 
        //LONG TIME I DIDN'T DO A MALLOC! 
        VkPhysicalDevice* devices = (VkPhysicalDevice*) malloc(sizeof(VkPhysicalDevice)*gpuCount);
        vkEnumeratePhysicalDevices(instance,&gpuCount,devices);
        
        for(unsigned int i=0;i<gpuCount;i++)
        {
            VkPhysicalDeviceProperties properties;
            vkGetPhysicalDeviceProperties(devices[i],&properties);
 
            std::cout<<"Device: "<<properties.deviceName<<std::endl;
 
            int version,minor,patch;
            
            version = (properties.apiVersion & 0xFFC00000) >> 22;
            minor = (properties.apiVersion & 0x003FF000) >> 12;
            patch = (properties.apiVersion & 0x00000FFF);
 
            std::cout<<"API version "<<version<<"."<<minor<<"."<<patch;
            version = (properties.driverVersion & 0xFFC00000) >> 22;
            minor = (properties.driverVersion & 0x003FF000) >> 12;
            patch = (properties.driverVersion & 0x00000FFF);
 
            std::cout<<"-ICD version "<<version<<"."<<minor<<"."<<patch;
 
            std::cout<<std::endl;
 
            std::cout<<"Type: ";
            switch(properties.deviceType)
            {
            case VK_PHYSICAL_DEVICE_TYPE_OTHER:
                std::cout<<"Other GPU type... unknown";
                break;
            case VK_PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU:
                std::cout<<"Integrated GPU";
                break;
            case VK_PHYSICAL_DEVICE_TYPE_DISCRETE_GPU:
                std::cout<<"Discrete GPU";
                break;
            case VK_PHYSICAL_DEVICE_TYPE_VIRTUAL_GPU:
                std::cout<<"Virtual GPU";
                break;
            case VK_PHYSICAL_DEVICE_TYPE_CPU:
                std::cout<<"CPU";
                break;
            }
            std::cout<<std::endl;
        }
 
        //OH MY GOD! A FREE!
        free(devices);
        std::cout<<"destroying the Vulkan instance..."<<std::endl;
        vkDestroyInstance(instance,NULL);
    }
    else
    {
        std::cout<<"Unable to create the Vulkan instance"<<std::endl;
    }
}
 

[Virion]

I reckon it would be like... hundreds of lines of code before you can draw a single triangle.

[Mel]

NVidia claims that

https://developer.nvidia.com/transition ... ngl-vulkan

But I feel it is like RISC processors, A small amount of instructions, but concise. The most surprising thing is that i get what most of the instructions are just by reading their name, okay, maybe not exactly, but I don't get lost in the code of the demos... until i reach a WIN API section...

Also, a thing that calls my attention is that, by default, everything on Vulkan are rendertarget operations, each command buffer reffers to a specific rendertarget, the presentation to a window is an extension, which uses some surfaces to swap between them and present them to the client window.

And i am not sure, but it is possible that Irrlicht was specially "vulkan friendly", as the reusability of the command buffers, and their renderstate "bindings" matches well Irrlicht's scene passes.Maybe, just maybe, I am not sure if this is just my lack of knowledge or the real thing, if Irrlicht operation extended to multiple cores, and the scene passes could be synchronized so certain command buffers executed in the right order (i.e. background pass, solid rendering, then transparent, then shadows...) could be that Vulkan would shine with Irr, but it is just a theory, and would involve syncing the scene manager with the video driver

[Virion]

Theoretically, vulkan will work on windows, linux, android, etc. (not sure about mac and ios) and even work on older OSes (windows xp), then will it be a good idea to focus on vulkan renderer for irrlicht? It's easier to just maintain the vulkan renderer compare to maintaining so many different renderers, OpenGL 2.0 + OpenGL 3.x + DirectX9 + DirectX10 + OpenGL ES + .......?

EDIT: After I read the link "Transitioning from OpenGL to Vulkan" by nVidia, it seems like it's not feasible lol.

Especially this:



Don't think anyone has the time for that.

[mongoose7]

You try to present Vulkan as a replacement for OpenGL. But many people use D3D. And D3D is very similar to (same as?) OpenGL, so both can be supported using common routines. But if you throw in Vulkan, you have to do one of two things: provide an OpenGL-like wrapper or provide a totally new implementation. We have the OpenGL-like wrapper - it is called OpenGL. We don't have a Vulkan implementation.

[Mel]

Vulkan is an evolution of the graphics API, they keep what it is worth, and remove what it is not. Irrlicht would need a whole new vulkan driver, IMO, wrapping OpenGL calls around Vulkan makes no sense to me, eventhough, for instance, to write a vulkan driver, it should have the glsl to SPIR-V converter, as it is the only shader code vulkan uses. But, for instance as well, i think i've read somewhere Vulkan keeps the D3D left handedness in its NDC (i.e. inverted Y axis and half of the depth range, which, i asume it is comparing to Open GL) so it seems the transition is not only intended for Open GL, it is also for Direct3D.

In fact, many people presents Vulkan as the Open GL replacement, but i don't see it like that. Open GL is a general purpose, open graphics library, not only a hardware acceleration API, but Vulkan's domain on the other hand, is precisely that, eventhough it may run on the CPU, (for instance as a software reference rasterizer, or even a secondary GPU to use).

Wrapping OpenGL over Vulkan, while perfectly feasible, only adds another layer of abstraction. If you then add Irrlicht over that, you're not only adding OpenGL overhead as a driver, but also, Irrlicht's code in GL style, which is just adding too many intermediaries to handle the GPU(s)

And for comparison purposes, people say the only Direct3D version which is direct competitor with Vulkan, is Direct3D12, so perhaps we would also need a D3D12 driver.

[devsh]

BREAK THE API
BREAK THE API
BREAK THE API
BREAK THE API
BREAK THE API
BREAK THE API

Irrlicht doesnt even fully support modern OpenGL, I'm rewriting all of the IMesh and IMeshBuffer classes because the "implicit" hardware bufffer object hints are just painful and dont really support streaming

[chronologicaldot]

...Or Fork it.
But sourceforge isn't a fun place to fork on, apparently.
Anyone else get frequent guru meditations, or is that just my luck?

[Mel]

I get my ration of guru wisdom from time to time...

Perhaps it could be a good time to start thinking about IRR 2.0... OGRE is preparing their ground for D3D12 and VULKAN on a similar basis

[Virion]

I get my ration of guru wisdom from time to time...

Perhaps it could be a good time to start thinking about IRR 2.0... OGRE is preparing their ground for D3D12 and VULKAN on a similar basis

AFAIK OGRE 2.1 beta already supports PBR materials, and some other new features. They rewrote part of the engine to support the new features while abandoning the old ones.