vulkan icon indicating copy to clipboard operation
vulkan copied to clipboard

Reducing Vulkan API call overhead

Open mackst opened this issue 7 years ago • 4 comments

hi realitix,

Just read this blog few days ago.

Reducing Vulkan API call overhead

That's very similar this extension binding from cffi doing. The difference is that article was loading all API with vkGetInstanceProcAddr and vkGetDeviceProcAddr. In this extension only extension api were loading with those two function. So I'm very curious will it fast if you doing like the article way? I did a very simple test. Duplicate the installed vulkan to vk and make some change to the _vulkan.py in vk.

def vkCreateInstance(pCreateInfo
        ,pAllocator
        ,):

    pName = 'vkCreateInstance'
    fn = _callApi(lib.vkGetInstanceProcAddr, ffi.NULL, pName)
    fn = ffi.cast('PFN_' + pName, fn)
    pInstance = ffi.new('VkInstance*')

    result = _callApi(fn, pCreateInfo,pAllocator,pInstance)
    if result != VK_SUCCESS:
        raise exception_codes[result]

    return pInstance[0]



def vkDestroyInstance(instance
        ,pAllocator
        ,):
    pName = 'vkDestroyInstance'
    fn = _callApi(lib.vkGetInstanceProcAddr, instance, pName)
    fn = ffi.cast('PFN_' + pName, fn)
    result = _callApi(fn, instance,pAllocator)

and run a simple test

import timeit

test2 = '''
appInfo = vk.VkApplicationInfo(
            sType=vk.VK_STRUCTURE_TYPE_APPLICATION_INFO,
            pApplicationName='Hello Triangle',
            applicationVersion=vk.VK_MAKE_VERSION(1, 0, 0),
            pEngineName='No Engine',
            engineVersion=vk.VK_MAKE_VERSION(1, 0, 0),
            apiVersion=vk.VK_MAKE_VERSION(1, 0, 3)
)

createInfo = vk.VkInstanceCreateInfo(
                sType=vk.VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO,
                pApplicationInfo=appInfo,
                enabledExtensionCount=0,
                enabledLayerCount=0
)

instance = vk.vkCreateInstance(createInfo, None)

vk.vkDestroyInstance(instance, None)
'''

print(timeit.timeit(test2, setup='import vulkan as vk', number=1000))
print(timeit.timeit(test2, setup='import vk', number=1000))

# 9.073086824310769
# 8.990983812290121

That seems a bit fast.

mackst avatar May 21 '18 07:05 mackst

Hello @mackst, Indeed it's a good practice to use vkGetInstanceProcAddr and vkGetDeviceProcAddr to retrieve functions. Like you know, these functions require an Instance or a Device. My wrapper has to be tiny so I don't want to manage this. The application is responsible of loading all functions.

If I expose all functions without the need to retrieve them, it's because the Vulkan SDK exposes theses functions and behind the scene use vkGetInstanceProcAddr.

Are you talking about all functions or only vkCreateInstance ?

realitix avatar May 24 '18 07:05 realitix

All functions of cause. But this is kind of draw attention issue not a have to be fixed issue(at least for me). I'm kind of happy for the current implementation and is not that slow. But there are peoples want to get more better performance. And this can be a way to improve the performance.

As you can see from the test it only speed up about 0.1s. By calling vkCreateInstance and vkDestroyInstance. And those two will only get 1 call for a real vulkan app.

I actually did a test with example_mandelbrot_compute.py. What I did was replace all the _callApi(lib. in vulkan.py to _callApi(lib.PFN_. I'm very surprise it works. But I don't get a very good compare result. So do you know if functions retrieve from vkGetInstanceProcAddr and vkGetDeviceProcAddr is exactly the same as cffi directly access to the PFN* functions?

mackst avatar May 25 '18 07:05 mackst

Hello @mackst. If you retrieve functions with vkGetInstanceProcAddr and vkGetDeviceProcAddr it will be faster. Not because of cffi, but because you call the function directly in the driver instead of in the Vulkan SDK.

I looked at my code and indeed you are right. Like we can see here, we can only load extension functions with vkGet..ProcAddr, I should add the possibility to load all functions.

I will think about it.

realitix avatar May 25 '18 07:05 realitix

Hello @mackst, I really have to work on this ! It's a must have feature, shame on me :see_no_evil:

realitix avatar Jun 20 '19 12:06 realitix

I will not work on it for now. If someone really want it I could take a look

realitix avatar Jan 18 '24 13:01 realitix