In some cases, Vulkan may be automatically disabled when using the 0ad svn appimage

[andy5995]

This issue has been discussed somewhat in the WFG forum:

https://wildfiregames.com/forum/topic/104382-vulkan-new-graphics-api/?do=findComment&comment=540919

I am testing on two separate systems. On both, the host system is Manjaro 22:

Laptop:

0000:00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) (prog-if 00 [VGA controller])

 Vulkan enabled when the AppImage is built in containers:

• Manjaro
• Ubuntu Jammy

Vulkan disabled when the AppImage is built in

• Ubuntu Bionic
• Ubuntu Focal

Desktop:

01:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050] (rev a1) (prog-if 00 [VGA controller])

 Vulkan enabled when the AppImage is built in containers:

• Manjaro
• Ubuntu Jammy
• Ubuntu Bionic (the container used to build appimages for the previous releases. Building appimages on older systems means they are more likely to run on more systems).

When the AppImage is run, there is a brief message in the console when Vulkan is auto-disabled:

FILES| Main log written to '/home/andya/.config/0ad/logs/mainlog.html'
FILES| Interesting log written to '/home/andya/.config/0ad/logs/interestinglog.html'
TIMER| CONFIG_Init: 3.40999 ms
Sound: AlcInit success, using OpenAL Soft
ERROR: Unable to create device for Vulkan backend, switching to GL.
FILES| UserReport written to '/home/andya/.config/0ad/logs/userreport_hwdetect.txt'

Also, the ~/.config/0ad/logs/system_info.txt will have lines like

GL_SGIS_generate_mipmap
GL_SGIS_texture_border_clamp
GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod
GL_SUN_multi_draw_arrays

instead of

VK_KHR_workgroup_memory_explicit_layout
VK_KHR_zero_initialize_workgroup_memory
VK_NV_compute_shader_derivatives
VK_VALVE_mutable_descriptor_type

The fact that Vulkan can't be enabled may indicate that normal 0ad builds on Ubuntu focal or bionic may not be able to use Vulkan with Intel chipset, or it might indicate that the native Vulkan drivers on newer systems can't interact correctly with the libraries included with the AppImage.

More reports will be needed. If you have tried the svn AppImage and Vulkan worked, or if it didn't work, please report your hardware and distro specs here (or in the WFG forum if you prefer).

[andy5995]

@Jammyjamjamman reported on the Ubuntu bionic AppImage with a Manjaro host system:

I'm using the igpu in a ryzen 4800u cpu. I ran the binary extracted from the appimage (--appimage-extract), but vulkan failed to be detected and 0ad fell back to gl.

I also built latest git (48d13b) on my own laptop. Vulkan renderer worked fine in 0ad in this build. (No errors and userreporthwdetect file showed lots of "VK" .)

[tuxayo]

My GPUs are an HD 4000 (gen7 ivy bridge) and an AMD 7950 (GCN 1.0) so basically the firsts Intel and AMD GPUs with Vulkan support (but incomplete/unofficial!). Right at the frontier in the middle of the minefield, so I should get a lot of trouble :D 💥 Then the devs will see how to handle these dodgy GPUs ^^"

GPU: mobile Intel HD 4000 OS: EndeavourOS (Arch Linux based)

Despite incomplete/unofficial support I can run vkcube and play Veloren (not playable FPS and a few rendering bugs) with Vulkan backend. Hopefully if I have issues I hope most will not be related to my dodgy Vulkan support and can help everyone. Anyway, with that caveat said:

Sound: AlcInit success, using OpenAL Soft
WARNING: Failed to create a Vulkan window: Installed Vulkan doesn't implement the VK_KHR_surface extension
ERROR: Unable to create device for Vulkan backend, switching to GL.

At least compared to previous posts here it's telling me I'm lacking VK_KHR_surface

I asked in the mesa chat room (IRC #dri-devel@OFTC), it seems VK_KHR_surface support isn't conditional and should be supported by my GPU. Is there a way to know which vulkan driver is ran? Like it could be lavapipe instead of hasvk/anv (Intel forked the anv driver to move gen7 & gen8 GPU support to hasvk (a sort of legacy branch) to ease maintenance)

But anyway, vulkaninfo tells me I support KHR_surface so there is something fishy here. :shrug:

[andy5995]

@tuxayo Thanks for the report!

I installed Ubuntu Focal on my Laptop (with the Intel GPU). I built 0ad from svn and Vulkan was detected. The AppImage I built with Focal didn't detect Vulkan on that laptop. So that tells me this issue is an AppImage problem, not a 0ad problem. :) It's a safe bet that the same would hold true for builds on Bionic.

The good news is that when you run the next release of 0ad, most likely Vulkan will be detected with no trouble.

I don't know how to fix the AppImage problem. The Vulkan drivers on the system that's running the AppImage probably can't interact correctly with the libraries embedded within the AppImage.

[StanleySweet]

Could be SDL2 built without Vulkan support?

[andy5995]

Could be SDL2 built without Vulkan support?

It works with NVIDIA GPUs

Maybe some hints at https://discourse.appimage.org/t/opengl-core-context-vulkan/1742

Also, I opened a discussion about this issue on the AppImage forum at https://discourse.appimage.org/t/vulkan-disabled-when-running-0ad-appimage-with-intel-or-amd-chipsets/2908 @tuxayo Maybe you could share that link in the mesa chat room you visit?

I also posted to the AppImage subreddit

[ppavacic]

On Intel Arch GPU I get error:

WARNING: Failed to create a Vulkan window: Installed Vulkan doesn't implement the VK_KHR_surface extension
ERROR: Unable to create device for Vulkan backend, switching to GL.

but vulkaninfo shows it as supported:

    VK_KHR_surface                         : extension revision 25
    VK_KHR_surface_protected_capabilities  : extension revision 1

Seems to be SDL issue. I will try to debug it. Perhaps SDL version is creating problems since for games such as Dota, SDL doesnt seem to cause any issues.

Here is that line: https://github.com/0ad/0ad/blob/0e3507495e263938b34ff820b1350582d981840b/source/ps/VideoMode.cpp#L425

[tuxayo]

The good news is that when you run the next release of 0ad, most likely Vulkan will be detected with no trouble.

Still the same issue with 0ad-0.0.27-rc1-27645-alpha-2305191528-x86_64.AppImage

~ ❯❯❯ vulkaninfo | grep VK_KHR_surface                                                                                                                                                                                                   
MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete
    VK_KHR_surface                         : extension revision 25
    VK_KHR_surface_protected_capabilities  : extension revision 1

Extension is still there. Should this be related to the appimage built or should I report this upstream?

[andy5995]

@tuxayo Thank you for confirming this is still a problem. I don't have any more info yet on how to fix it. I suspect it's related to the Appimage build because I haven't heard yet that detection is a problem when 0ad is built normally and not run as an AppImage.

One of the AppImage devs stated:

All I can say is that AppImage does not use any form of sandboxing or virtualization by default; so it is likely a driver/library compatibility issue? Try experimenting with bundling more/less components.

https://discourse.appimage.org/t/vulkan-disabled-when-running-0ad-appimage-with-intel-or-amd-chipsets/2908/2

At some point the 0ad developers might be able to spend more time helping me troubleshoot the AppImage build, but as their primary focus is directly developing 0ad right now, I can't provide an ETA on when this will get fixed. And I have no clues right now as to what to try next.

[tuxayo]

I suspect it's related to the Appimage build because I haven't heard yet that detection is a problem when 0ad is built normally and not run as an AppImage.

Almost confirmed. I built 0ad from source (0ad-git AUR package on Arch Linux) and with rendererbackend = "vulkan" in user.cfg it doesn't fallback to gl but it crashes. So I assume that it managed to detect Vulkan support and moved on. But then crashed due to my HD 4000 having wacky support. So I'm reporting that upstream. If my interpretation is correct, that still leaves the mystery for the AppImage.

Maybe something is automagically super smart and know I don't have full vulkan support :P

[tuxayo]

Maybe something is automagically super smart and know I don't have full vulkan support :P

Obviously not because the problem was 1st noticed with a "TigerLake-LP GT2 [Iris Xe Graphics]"

[tuxayo]

About my other wacky GPU: AMD 7950 (GCN 1.0) so the first AMD GPUs with Vulkan support (experimental).

The same happens, it doesn't detect Vulkan support and falls back to OpenGL. And when building from source (0ad-git AUR package) it works.

[tuxayo]

No sure if relevant, but in case that rules out something or gives a clue: checking ~/.config/0ad/logs/userreport_hwdetect.txt shows that Mesa 23.1 is used on my system which is the native version. And any version of Ubuntu ships an at least a bit older version of Mesa. So we have proof that for OpenGL the Mesa lib of the Ubuntu building the images are not embedded and overriding the ones of the running system. But that doesn't tell anything about Vulkan, so...

[StanleySweet]

Could be a mesa bug or a missing mesa-vulkan driver?

[tuxayo]

missing mesa-vulkan driver?

I’ve been told in the Mesa chat (#dri-devel@OFTC IRC) that something like this is missing: probably the vulkan loader, probably also mesa vulkan drivers and maybe also the headers to build against.

So yeah good intuition

Opened a ticket there: https://github.com/AppImage/AppImageKit/issues/1270

[StanleySweet]

Thanks!

[andy5995]

More libraries can be included by using the --library flag, like is done for one library right now:

https://github.com/0ad-matters/0ad-appimage/blob/eb8e4440baf4bf79a6181c3ee98bfe3b89f0065a/workflow.sh#L196-L204

[andy5995]

missing mesa-vulkan driver?

I’ve been told in the Mesa chat (#dri-devel@OFTC IRC) that something like this is missing: probably the vulkan loader, probably also mesa vulkan drivers and maybe also the headers to build against.

Headers are only used for compiling 0ad itself, and should never need to be included with an AppImage.

So yeah good intuition

Opened a ticket there: AppImage/AppImageKit#1270

Thanks. I subscribed and saw that they already closed it.

I opened https://github.com/0ad-matters/0ad-appimage/pull/24 maybe we can get somewhere with it. I'm pretty sure it won't work on the first try.

[andy5995]

Could be SDL2 built without Vulkan support?

@StanleySweet How do you determine if SDL2 is built with or without Vulkan support? If that's required, that might explain why 0ad AppImages built using Ubuntu Jammy, not Focal or Bionic, work with my Intel GPU.

[StanleySweet]

SDL2 has a confguration header with a bunch of flags.

See the windows header for example.

https://trac.wildfiregames.com/browser/ps/trunk/libraries/win32/sdl2/include/SDL/SDL_config.h#L247

Depending on the version too 2.0.6 added support

[andy5995]

SDL2_config.h from the Focal source package looks quite a bit different, but as far as I could tell, Vulkan is enabled by default. But I think this proves that Vulkan is enabled:

[andy@prometheus lib]$ docker run -it --rm andy5995/0ad-build-env:focal 
root@991d8c2f2a9f:/# cd /usr/lib/x86_64-linux-gnu/
root@991d8c2f2a9f:/usr/lib/x86_64-linux-gnu# nm -D libSDL2.so | grep -i vulkan
000000000003b960 T SDL_Vulkan_CreateSurface
000000000003b970 T SDL_Vulkan_GetDrawableSize
000000000003b950 T SDL_Vulkan_GetInstanceExtensions
000000000003b930 T SDL_Vulkan_GetVkGetInstanceProcAddr
000000000003b920 T SDL_Vulkan_LoadLibrary
000000000003b940 T SDL_Vulkan_UnloadLibrary

[StanleySweet]

Right I never think of grepping binary files

[andy5995]

@tuxayo Can you try the AppImage (artifact) from https://github.com/0ad-matters/0ad-appimage/actions/runs/5293011281#artifacts and let me know if it works for you? (I built it using Ubuntu Jammy)

[tuxayo]

@andy5995 it works! (tested on my HD 4000) mangohud confirms that it's using vulkan

Congrats for having found what's necessary :D

[tuxayo]

So was it building on Ubuntu 22.04 or installing libvulkan-dev or both?

[andy5995]

So was it building on Ubuntu 22.04 or installing libvulkan-dev or both?

Built on 22.04. I didn't make any changes to installed packages. At this point, I have no idea why it works on jammy and not focal or ubuntu.

Unfortunately, this doesn't technically solve the issue. The AppImage devs strongly recommend building images on older distros to help ensure people on older distros will be able to run the image.

So I'm going to start publishing focal and jammy images. I didn't want to do that because it's going to be more confusing for end-users. Someone might download a jammy image initially, and it might not run at all on their system. Then they'd have to download the focal image.

But despite the confusion aspect, this is the best solution so far, imo, until we have more information about the source of the problem.

Thanks for your persistence and detective work @tuxayo

[andy5995]

A "jammy" image is now available on the releases page for 0.0.27-rc1-27645-alpha

[tuxayo]

Works also on my AMD HD 7950 :D

[tuxayo]

Unfortunately, this doesn't technically solve the issue. The AppImage devs strongly recommend building images on older distros to help ensure people on older distros will be able to run the image.

Oh ok, so that's not all T_T

But despite the confusion aspect, this is the best solution so far, imo, until we have more information about the source of the problem.

Yes, that the best for now.

A "jammy" image is now available on the releases page for 0.0.27-rc1-27645-alpha

Thanks :)

So the next step is to find which lib install on Ubuntu 20.04 for it to have Vulkan support?

[tuxayo]

So the next step is to find which lib install on Ubuntu 20.04 for it to have Vulkan support?

IIUC, libvulkan-dev didn't help when building on 20.04 or wasn't it tried?

Another candidate is https://packages.ubuntu.com/focal/libvulkan1 "Vulkan loader library" The deps are "vulkan-icd" which is a virtual package for mesa-vulkan-drivers Which is very encouraging.

[andy5995]

Well, if there's a library missing for the 0ad build, then the build would fail. If there's a missing '-dev' package, then the 0ad-build would fail (most commonly the message would be a message about a missing '.h' file).

If there was a required library missing from the AppImage, then the image would likely fail to run, giving a message about "failed to locate/load shared library...".

Some library on focal or bionic may not have vulkan support compiled in. @StanleySweet does that all sound about right to you? And do you know of any 0ad dependency other than SDL2 that requires vulkan support built into it?

[StanleySweet]

SDL2 sounds like the only thing requiring Vulkan to be missing but I might be wrong.