NVIDIA driver specific warning is wrongly showing for the Dozen driver

[Joaozin-tech]

Quick summary

Problem occurs with NVIDIA's latest 551.23 drive when I start any game and put it in full screen, a bug simply occurs where the screen goes black and nothing shows in Windows or RPCS3, I simply have to reset my PC. RPCS3 asks every time to update the drive even though it is already in its latest drive versions this has been happening for days another thing using drive version 472.12 this has not happened now if I use the VULKAN beta version this occurs or the latest NVIDIA version this problem occurs game INFAMOUS 1 INFAMOUS 2 INFAMOUS FESTIVAL BLOOD

Details

RSX: Found Vulkan-compatible GPU: 'NVIDIA GeForce RTX 3060' running on driver 551.23.0.0

• RSX: Found Vulkan-compatible GPU: 'Microsoft Direct3D12 (NVIDIA GeForce RTX 3060)' running on driver 24.0.1.35
  E RSX: Your current NVIDIA graphics driver version 24.0.1.35 has known issues and is unsupported. Update to the latest NVIDIA driver.

Attach a log file

RPCS3.log

Attach capture files for visual issues

System configuration

RPCS3.log

Other details

No response

[Joaozin-tech]

[Megamouse]

You're using an insider windows build.
It literally tells you that it could have many issues.
I'm assuming you have some drivers pre-installed with that windows version.

[Joaozin-tech]

@Megamouse Worse than not, I installed Windows Insider Preview from scratch to avoid these problems, I even used DDU DRIVE, I cleaned old drives that Windows Installs this version here NVIDIA - Display - 30.0.14.7212 corresponds to version 472.12 I updated to the latest, this problem occurs when I was 472.12 without any problem

[AniLeo]

Do you mistakenly have "OpenCL™, OpenGL®, and Vulkan® Compatibility Pack" installed by any chance?

[Joaozin-tech]

@AniLeo Let's check something out here Windows Store

[Joaozin-tech]

@AniLeo Thanks for the tip Windows Store install it here I uninstalled it here it came back normal my RPCS3 this is what was happening my Windows Insider Preview with your license I close this

[jenatali]

It seems like the problem is that the version check here is done based on NVIDIA's vendor ID rather than driver ID. Perhaps this should have checked against VK_DRIVER_ID_NVIDIA_PROPRIETARY instead of 0x10DE.

[AniLeo]

The vendor is determined here based on the driverID property

rpcs3/rpcs3/Emu/RSX/VK/vkutils/device.cpp

Line 262 in 85f4c38

case VK_DRIVER_ID_NVIDIA_PROPRIETARY_KHR:

And then we log said error regarding outdated drivers

rpcs3/rpcs3/Emu/RSX/VK/vkutils/device.cpp

Line 187 in 85f4c38

else if (get_driver_vendor() == driver_vendor::NVIDIA)

Looking at the code, my guess is that the device provided by the compatibility pack does not have a defined driverID and it ends up using the !driverID fallback for detecting vendor which is based on device name, by matching NVIDIA on the deviceName plus checking what OS we're on

But regardless the error itself is not preventing the emulator from working, all that code is doing is log an error message for old NVIDIA drivers

The bigger problem is that on AMD side it will crash if people have that compatibility pack installed due to an issue with device enumeration inside amdxc64 (PCSX2/pcsx2#10746)

As for the black screen seen here, my guess is that the user tried to boot the render with the dozen based device, instead of the correct dGPU device provided by their NVIDIA driver, can't say for sure because the log doesn't contain a game boot

[jenatali]

Looking at the code, my guess is that the device provided by the compatibility pack does not have a defined driverID

That would make sense, though it does have one: VK_DRIVER_ID_MESA_DOZEN.

The bigger problem is that on AMD side it will crash if people have that compatibility pack installed due to an issue with device enumeration inside amdxc64

Thanks for that link. I had seen that crash a little while ago but I'm not able to reproduce it anymore. Either way, we're working with AMD to get it addressed, either on our side or theirs.

[AniLeo]

Let's at least fix the warning/error from not triggering for the wrong driver, I've reopened this ticket

[kd-11]

I can reproduce by just adding dozen dll and icd json to my driver files list. I'll push a workaround.

[kd-11]

@jenatali The driverID is 0 because dozen does not report support for "VK_KHR_driver_properties" and rpcs3 is built against vulkan 1.0 base. A workaround to identify Direct3D in the string will work well enough for now however.

EDIT: I was mistaken. It does report the extension. However, it fails to fill in the details so the structure comes back empty. This is the code section that sets up the driver properties retrieval: https://github.com/RPCS3/rpcs3/blob/master/rpcs3/Emu/RSX/VK/vkutils/device.cpp#L44-L49
I checked the response and it's all untouched/empty.

[kd-11]

This seems to be a mesa bug when compiled with windows target. The same issue occurs with lavapipe and I believe the driver properties stuff is in mesa common code. Does mesa officially support windows? I'm not sure whether I should open a ticket with them.

[jenatali]

You can open an issue on Mesa or else I can just investigate based on this bug. I've not used rpcs3 before, do I need a ROM to get to the point of reproducing the issue?

I don't know that anybody else cares about Mesa Vulkan support on Windows, but I sure do, so I can fix it if it's broken

[Darkhost1999]

Does mesa officially support windows?

microsoft/wslg#40 (comment)

I don't believe there's official support yet. I also don't believe it's entirety intentional for stuff like this to work with WSL (see comment in other issue).

Maybe there is support microsoft/wslg#1077

[AniLeo]

You do not need a commercial game to be able to start up the emulator with a Vulkan render

1. Download RPCS3
2. Download the PS3 firmware from https://www.playstation.com/en-us/support/hardware/ps3/system-software/
3. Open RPCS3
4. File > Install Firmware to install PS3UPDAT.PUP
5. File > Boot (S)elf > Boot test > gs_gcm_cube.elf

On Settings > GPU you can pick the Render (OpenGL or Vulkan) and the Vulkan Device

---

Edit: But you should also be able to reproduce the issue without RPCS3 by writing a simple Vulkan application that tries to access the driverID with VK_KHR_DRIVER_PROPERTIES and run it through dozen on Windows

[jenatali]

@Darkhost1999 my team (primarily me) supports Mesa on Windows, both natively and through WSL

@AniLeo I'll take a look on Monday, should be straightforward to fix I expect.

[jenatali]

Okay. Yes, I linked both links I noticed were relevant. It seems Vulkan isn't fully implemented yet. I'm curious about Mesa cause I thought it was only for OpenGL.

Mesa is the repository that hosts many OpenGL drivers (including a framework for implementing GL drivers, Gallium), as well as Vulkan, CL, and more. Vulkan in general is complete in Mesa drivers. Dozen specifically is a mostly-conformant Vulkan 1.2 driver, though obviously there's more to be done (extensions, 1.3, conformance, app compat, etc).

But then Mesa is working on Dozen?

Dozen is hosted inside of Mesa, yes.

So is Dozen the recommended way to use Vulkan on WSL? Is there just no hardware acceleration yet?

Yes, depending on your distro, they should be including Dozen. If not, it's buildable as part of Mesa. In WSL, it provides hardware acceleration via paravirtualization.

I would love to expand my tests but maybe this isn't the right place for that discussion.

Right, probably not.

[AniLeo]

@jenatali we worked around the issue on our side by checking device name instead, but the missing driver properties struct issue is still valid, do you want us to open an issue on the mesa repository on freedesktop?

[jenatali]

@AniLeo Thanks for the reminder. I'll take a look at that today.

[jenatali]

@AniLeo My simple test is unable to reproduce:

#include <vulkan/vulkan.h>
#include <vector>
#pragma comment(lib, "vulkan-1.lib")

int main()
{
	VkInstance instance;
	VkInstanceCreateInfo args = { VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO };
	VkApplicationInfo appInfo = { VK_STRUCTURE_TYPE_APPLICATION_INFO };
	appInfo.apiVersion = VK_API_VERSION_1_0;
	args.pApplicationInfo = &appInfo;
	const char *extensions[] = { "VK_KHR_get_physical_device_properties2" };
	args.enabledExtensionCount = _countof(extensions);
	args.ppEnabledExtensionNames = extensions;
	VkResult result = vkCreateInstance(&args, nullptr, &instance);
	if (result != VK_SUCCESS)
		return result;

	uint32_t deviceCount = 0;
	result = vkEnumeratePhysicalDevices(instance, &deviceCount, nullptr);
	if (deviceCount == 0)
		return -1;

	std::vector<VkPhysicalDevice> devices(deviceCount, nullptr);
	result = vkEnumeratePhysicalDevices(instance, &deviceCount, devices.data());
	if (result != VK_SUCCESS)
		return result;

	auto pfnvkGetPhysicalDeviceProperties2KHR = (decltype(&vkGetPhysicalDeviceProperties2KHR))vkGetInstanceProcAddr(instance, "vkGetPhysicalDeviceProperties2KHR");
	if (!pfnvkGetPhysicalDeviceProperties2KHR)
		return -1;

	VkPhysicalDeviceDriverPropertiesKHR driverProps = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR };
	VkPhysicalDeviceProperties2KHR propArgs = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2_KHR };
	propArgs.pNext = &driverProps;
	pfnvkGetPhysicalDeviceProperties2KHR(devices[0], &propArgs);

	return 0;
}

In a debugger I see the driver properties filled out. I tried stepping through RPCS3's initialization and I don't actually see it querying for driver properties.

And now that I opened the link you pasted above (https://github.com/RPCS3/rpcs3/blob/master/rpcs3/Emu/RSX/VK/vkutils/device.cpp#L44-L49), you're querying for driver properties via VkPhysicalDeviceFeatures2KHR. It's supposed to be chained into VkPhysicalDeviceProperties2KHR .

[kd-11]

@jenatali Thanks for checking. You're indeed correct, that was a copypasta, now fixed in #15214. Strangely the validation layers never complained about this.
With the fix in place the ID is populated correctly as expected.