Mesa Vulkan Drivers Now Tracking Game Engine/Version For Handling More Workarounds

[phoronix]

Phoronix: Mesa Vulkan Drivers Now Tracking Game Engine/Version For Handling More Workarounds

Currently the Mesa OpenGL/Vulkan drivers have relied upon matching executable names for applying game/application-specific workarounds. But with Vulkan as part of the instance creation information and VkApplicationInfo it's possible to optionally advertise the rendering engine and version in use. The Mesa Vulkan drivers are now making use of that information to allow for more uniform workarounds...

http://www.phoronix.com/scan.php?page=news_item&px=Mesa-VLK-Game-Engine-Workaround

[plonoma]

But with Vulkan as part of the instance creation information and VkApplicationInfo it's possible to optionally advertise the rendering engine and version in use.

Does this mean there is no similar functionality; getting engine name and version, in OpenGL?
If not they should bring the info VkApplicationInfo provides in Vulkan to OpenGL. It needs this (engine name and more importantly engine version) much more and waaaaaay harder than Vulkan!
Especially applications using earlier versions of OpenGL (between 3.0 and 4.5=4.6) which have lots of old applications including games doing different things.
And even a bigger can of worms: the legacy of old drivers doing different things causing applications to try to code for those quirks and driver specific behaviours.

[smitty3268]

Does this mean there is no similar functionality; getting engine name and version, in OpenGL?
If not they should bring the info VkApplicationInfo provides in Vulkan to OpenGL. It needs this (engine name and more importantly engine version) much more and waaaaaay harder than Vulkan!
Especially applications using earlier versions of OpenGL (between 3.0 and 4.5=4.6) which have lots of old applications including games doing different things.
And even a bigger can of worms: the legacy of old drivers doing different things causing applications to try to code for those quirks and driver specific behaviours.

That's correct, OpenGL doesn't have an equivalent to this.

It's too late for it to be useful there. OpenGL is mostly dead for new applications, and nobody is going to release updates to the thousands of existing old games just to add the name of the engine they use.

[plonoma]

That's correct, OpenGL doesn't have an equivalent to this.

It's too late for it to be useful there. OpenGL is mostly dead for new applications, and nobody is going to release updates to the thousands of existing old games just to add the name of the engine they use.

Thanks for answering my question.
Does VkApplicationInfo have optional, separate engine and engine version info for physics engine and other middleware integrated into the engine.
You know for when someone integrates a third party physics engine (e.g. Bullet Physics engine) or other middleware into their engine.

[oiaohm]

Thanks for answering my question.
Does VkApplicationInfo have optional, separate engine and engine version info for physics engine and other middleware integrated into the engine.
You know for when someone integrates a third party physics engine (e.g. Bullet Physics engine) or other middleware into their engine.

https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkApplicationInfo.html

The answer is no its not that detailed.

You have application name and engine name that kind of it.

I am not sitting on a vulkan supporting system to see if I can in a single program run vkCreateInstance twice with different VKapplicationinfo. If this would work it would most likely be the best way so that all engines could request the vulkan version they in fact want and expect.

[plonoma]

https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkApplicationInfo.html

The answer is no its not that detailed.

You have application name and engine name that kind of it.

I am not sitting on a vulkan supporting system to see if I can in a single program run vkCreateInstance twice with different VKapplicationinfo. If this would work it would most likely be the best way so that all engines could request the vulkan version they in fact want and expect.

The use case I'm thinking is game engine components/extensions/middleware.
Basically mostly third-party software used with a game engine but also useful for engines consisting of modules that can be used and reused independently and optionally.
An application could have multiple pieces of game engine engine components/extensions/middleware or extra software in it.
Some applications using the same engine might not using or use a different version of those game engine components/extensions/middleware.
Thus the use of some extra information for those extra pieces of software that can have bugs independent from the main game engine.
Might needing those component specific workarounds in the drivers.

[oiaohm]

The use case I'm thinking is game engine components/extensions/middleware.
Basically mostly third-party software used with a game engine but also useful for engines consisting of modules that can be used and reused independently and optionally.
An application could have multiple pieces of game engine engine components/extensions/middleware or extra software in it.
Some applications using the same engine might not using or use a different version of those game engine components/extensions/middleware.
Thus the use of some extra information for those extra pieces of software that can have bugs independent from the main game engine.
Might needing those component specific workarounds in the drivers.

https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkApplicationInfo.html

This is so you can give component specific work around. But it requires you application to be well behaved as in declared VkApplicationinfo correctly so that eahc component has a individual info/identity to the graphic vulkan stack.

Vukan has Instance Layers that you can apply on a per application base these vulkan instances layers can look at the VkApplicationInfo and decide if their alteration to a function request applies or not.

So as long as all your components/extensions/middleware use vulkan and use vulkan correctly by declaring a different Vkapplicationinfo per part by the engine value dealing with needing different versions of vulkan for different components/extensions/middleware is as straight forwards as making a vulkan instance layer for your application than process the VkApplicationinfo to alter what vulkan parts are exposed and how those parts function based on VkApplicationinfo info. Great part is this fixme Vulkan instance layer can be graphic solution neutral.

This is one of the advantages of vulkan over opengl that applying application and application component work around is in fact part of the standard with Vulkan as long as your application was built correctly in the first place and declares the information required.. Yes this vulkan system allows the work around to a graphic driver issue causing you application problems to be done by the graphics driver developer or the application developer.

So its not longer having to wait for the graphics driver vendor to push out a driver update that will hopefully detect and apply the work around correct that has been the case with opengl. Remember in a lot of cases the application developer normally has more information about the component even a closed source one they bought.,

Yes the vulkan instance layers stuff works with wine so a windows application using vulkan can ship with its own windows instance layer fix and this will still be applied and work under wine.

also useful for engines consisting of modules that can be used and reused independently and optionally.

Remember nothing about the VkApplicationinfo says that these optional modular parts have to have the same engine value in the VkApplicationinfo. In fact they can have individual engine values to allow individual generic work around.

Yes VkApplicationinfo is recording two bits of info the application id name and version and the engine/engine module id and version. The work around vulkan instances layers are able to pickup and process this information. If it X application + Y engine don't do generic Y engine work around because that different is possible.

This basically takes two to tango and do it successfully. You need the parts of application to declare the correct information so the work around vulkan instance layers can separate them and apply the right alterations.

Remember with engine optional parts they do not have to be dynamic linked so they can be static linked into one single file so the engine need to declare it parts in source code so when the source code it built the parts can get individual treatment.

Now if you have program that has used a single Vkapplicationinfo for everything and has linked everything into a single file then using anti debugging stuff on top of that there is no effective way to apply stuff differently on a per components/extensions/middleware in this case. Now every else is done the same bar the fact used Vkapplicationinfo correctly to declare the individually use parts you can apply corrections on a per components/extensions/middleware.

Basically you have to plan your workaround segment layout at application development stage to be able to apply workarounds effectively. If you don't have the information there are a lot cases you will be forced to limit to the lowest common version to work. So how well or how bad applications work arounds to apply purely comes down to how well developed the application is with Vulkan. Well constructed application with correct usage of VkApplication applying work around is straight forwards. Without that information you are back to like opengl where you are making a single special lowest common deliminator version basically disabling sections of the program that can safely use newer faster code so the program works.

Vkapplicationinfo and the vulkan instance layers combination is designed to make application workarounds effective with min performance crippling.