Vulkan on Linux needs to auto-detect window system at runtime (PPSSPPSDL)

[Anuskuss]

OS: LibreELEC 8.2.2 (Linux)
PPSSPP: v1.5.4-232-g2dda2bf (SDL)

LibreELEC has no build tools so I'm forced to use the precompiled binaries from build.ppsspp.org.

Log

Vulkan might be available.
I: Config.cpp:440: Longest display side: -1 pixels. Choosing scale 1
Pixels: 960 x 544
Virtual pixels: 960 x 544
W: VulkanLoader.cpp:258: Vulkan base functions loaded.
E: VulkanContext.cpp:168: Failed to create instance : -7
Vulkan init error 'Failed to create Vulkan instance' - falling back to GL
OpenGL 2.0 or higher.
I: gpu_features.cpp:136: GPU Vendor : Intel Open Source Technology Center ; renderer: Mesa DRI Intel(R) Iris Plus Graphics 640 (Kaby Lake GT3e)  version str: 4.5 (Core Profile) Mesa 17.3.0-rc6 ; GLSL version str: 4.50

Vulkan works fine since I'm able to use it in RetroArch. I can give you the output of vulkaninfo if that is of any use.

[hrydgard]

Interesting:

"E: VulkanContext.cpp:168: Failed to create instance : -7"

VK_ERROR_EXTENSION_NOT_PRESENT = -7

Seems we are asking for some extension that's not available, for whatever reason.

[unknownbrackets]

I'm guessing it's the windowing system it was built for?

Does LibreELEC use MIR or Wayland or...?

-[Unknown]

[hrydgard]

I'll add some logging to be sure.

[hrydgard]

@Anuskuss Please update and rebuild and try again :)

[namarrgon]

Running b972624 produces this when running on pure Xorg:

% ppsspp
Vulkan might be available.
I: Config.cpp:440: Longest display side: -1 pixels. Choosing scale 1
Pixels: 960 x 544
Virtual pixels: 960 x 544
W: VulkanLoader.cpp:258: Vulkan base functions loaded.
W: VulkanContext.cpp:143: WARNING: Does not seem that instance extension 'VK_KHR_wayland_surface' is available. Trying to proceed anyway.
E: VulkanContext.cpp:179: Failed to create instance : -7
Vulkan init error 'Failed to create Vulkan instance' - falling back to GL
OpenGL 2.0 or higher.
I: gpu_features.cpp:136: GPU Vendor : NVIDIA Corporation ; renderer: GeForce GTX 750 Ti/PCIe/SSE2 version str: 4.6.0 NVIDIA 387.34 ; GLSL version str: 4.60 NVIDIA
I: NativeApp.cpp:618: NativeInitGraphics
I: NativeApp.cpp:702: NativeInitGraphics completed
loading control pad mappings from gamecontrollerdb.txt: SUCCESS!
Control pad device 0 not supported by SDL game controller database, attempting to create default mapping...
Added default mapping ok
found control pad: Logitech Logitech Extreme 3D, loading mapping: SUCCESS, mapping is:
030000006d04000015c2000010010000,Logitech Logitech Extreme 3D,x:b3,a:b0,b:b1,y:b2,back:b8,guide:b10,start:b9,dpleft:b15,dpdown:b14,dpright:b16,dpup:b13,leftshoulder:b4,lefttrigger:a2,rightshoulder:b6,rightshoulder:b5,righttrigger:a5,leftstick:b7,leftstick:b11,rightstick:b12,leftx:a0,lefty:a1,rightx:a3,righty:a4
pad 1 has been assigned to control pad: Logitech Logitech Extreme 3D
I: NativeApp.cpp:711: NativeShutdownGraphics
I: NativeApp.cpp:734: NativeShutdownGraphics done
I: NativeApp.cpp:1136: NativeShutdown called

The nvidia 387.34 driver indeed seems to not support the 'VK_KHR_wayland_surface' extension.
The question is why it matters when not using wayland?

As a sidenote: The failed attempt of enabling vulkan produces a second window that hangs around while ppsspp falls back to opengl and, otherwise, functions as usual.

[hrydgard]

The CMake build seems to have detected wayland, which does not seem to be the right idea...

Should probably switch to fully runtime detection, SDL exposes it nicely.

[namarrgon]

On arch linux all packages are built with wayland support enabled but in this scenario it's just not functional, mainly because of the nvidia driver.

[unknownbrackets]

Maybe we just take the first of those extensions that are both available and compiled on?

-[Unknown]

[hrydgard]

Nah, we'll just make use of this, as we already do: https://github.com/hrydgard/ppsspp/blob/master/SDL/SDLMain.cpp#L442

And make sure that we enable all the VK_USE_PLATFORM defines if they're available, and not just one, from the CMakeLists.txt.

Although this makes me a little confused.. doesn't the above results mean that SDL currently is erroneously returning wayland there?

[unknownbrackets]

I think it's because that check isn't on this line:

ppsspp/Common/Vulkan/VulkanContext.cpp

Line 123 in 191c4dd

instance_extensions_enabled_.push_back(VK_KHR_WAYLAND_SURFACE_EXTENSION_NAME);

It's not that we're trying to create a surface with it, just that we're trying to enable an extension that doesn't exist, right?

-[Unknown]

[hrydgard]

Oh, duh. Should be pretty easy to fix..

[Anuskuss]

@hrydgard Thanks for the effort. As I stated earlier LibreELEC doesn't provide build tools and I'm not experienced enough to cross-compile, so I'll wait until a new SDL build is online ☺️
@unknownbrackets I think it's using X11 in 8.2.2

[Anuskuss]

One week later still no update. Did something break the buildbot?

[valpackett]

@Anuskuss please test now with 025c382

[namarrgon]

I built e119d37 and vulkan works fine now.
It's not possible to resize the window without artifacts and freezing but that's an issue for another bugreport.

[unknownbrackets]

I'll mark this closed then - if there are still issues with the window system detection, we can reopen.

-[Unknown]

[Anuskuss]

I tried to cross-compile it myself and don't know what to blame (ppsspp, my build or the intel vulkan driver) but although the game ran fullspeed, it was a garbled mess. Don't know if it's worth creating an issue for that since I guess everything will mature over time.

[hrydgard]

@Anuskuss Definitely worth reporting. Please create a new issue.

[Anuskuss]

@hrydgard It has to be my fault. First I assumed it has something to do with the fact that I'm building in a debian container, but even dualbooting Ubuntu on the same machine (and even going back to v1.5.4-232-g2dda2bf) resulted in the exact same graphical corruptions for Vulkan and OpenGL (OpenGL less than Vulkan).

So if you don't want to debug my environment (which would be a huge waste of time IMHO) I'll just stick with the precompiled SDL builds from your website.

[hrydgard]

Oh it works with the prebuilts? Odd.

[Anuskuss]

That's really odd indeed. I mean I haven't even done something unusual, just installed cmake, git and libsdl and built with b.sh.

[Anuskuss]

I've done some testing because parts of the car were invisible in both APIs. I could fix this on Debian by switching to Clang. On my Arch docker container the problem is still present when switching to Clang. Maybe it's an error with Clang 5 (Debian Buster still uses 4). Is this a known issue?
If I can help in some way, please let me know and I'll create a seperate issue.

P.S. The build instructions page could use some overhaul. Is Clang still recommended and is it really necessary to have libsdl12 when the CMake detects libsdl2 just fine? Also it didn't build on my machine without glew, maybe list that as a dependency?