Mdthbs

How can I convince my reader that I will not use a certain trope?

Who gets an Apparition licence?

Can a police officer film me on their personal device in my own home?

What does grep -v "grep" mean and do?

Golf the smallest circle!

How would an order of Monks that renounce their names communicate effectively?

Different budgets within roommate group

Averting Real Women Don’t Wear Dresses

I'm reinstalling my Linux desktop, how do I keep SSH logins working?

In native German words, is Q always followed by U, as in English?

How exactly is a normal force exerted, at the molecular level?

Did Wakanda officially get the stuff out of Bucky's head?

Can a single server be associated with multiple domains?

Mean Value Theorem: Continuous or Defined?

I hit a pipe with a mower and now it won't turn

Is there a way for presidents to legally extend their terms beyond the maximum of four years?

Most elegant way to write a one shot IF

Reverse of diffraction

Prime parity peregrination

What is the name of this OOB notification method/popup, and is it customizable?

What does Mildred mean by this line in Three Billboards Outside Ebbing, Missouri?

Is it allowed to spend a night in the first entry country before moving to the main destination?

Needle Hotend for nonplanar printing

Do space suits measure "methane" levels or other biological gases?

Mismatch between mesa+vulkan driver verison used by Proton and the host mesa driver version

Finding the best working driver for a video cardDifference between wine-wingdings and wingdings?Gallium renderer used instead of Intel MesaAfter switching to the nvidia video card driver, the whole xfce setup messed upDoes amdgpu support my Fury X and why isn't the driver loaded?How can I get my Optimus-addled NVIDIA card to offer output via xrandr?Updating Mesa for instaling VulkanUbuntu 18.04->18.10 doesn't bootWhy Wayland is using OpenGL ES instead of OpenGL?Why does inxi report that I am using the nvidia (which is deinstalled) and not the nouveau driver?

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}

0

Proton is working fine with the latest dxvk implementation but when I browse on the log files of the games used by Proton I notice a mismatch between the mesa driver version of my host system and the listed there. What I know so far is that dxvk is a bridge so calls from dx10/11 can be translated to vulkan and processed in your host system, thus relying on your graphical driver and the vulkan mesa driver (amdgpu radv in my case).

These are the mesa driver version and the apiversion used by vulkan listed on the log of the game loaded by Proton (a win64 game):

AMD RADV POLARIS10 (LLVM 7.0.1):

Driver: 18.3.6

Vulkan:
1.1.70

The output of vulkaninfo reports apiversion "1.1.90" which is different form the version "1.1.70" used on Proton:

Vulkan Instance Version: 1.1.107

GPU id : 0

(AMD RADV
POLARIS10 (LLVM 8.0.0))

apiVersion = 0x40105a (1.1.90)

driverInfo = Mesa 19.1.0 (LLVM 8.0.0)

The output from glxinfo agrees on the mesa driver version and on the version of LLVM displayed on vulkaninfo:

OpenGL renderer string: Radeon RX 570 Series (POLARIS10, DRM 3.30.0,
5.1.14-arch1-1-ARCH, LLVM 8.0.0)

OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.1.0

Also, before the vulkan environment initialization happens, the following DLLs are loaded as reported by the log of the game:

Loaded L"C:windowssystem32vulkan-1.dll" at 0x7fa05e6e0000: builtin

Loaded L"C:windowssystem32winevulkan.dll" at 0x7fa05e6a0000: builtin

Maybe these DLLs are the causative of such a mismatch.

EDIT: When opening another game on Lutris with custom DXVK_HUD options I can see that both vulkan API version and mesa version match respective versions on my host. Still don't know why Proton has that behaviour.

Summarizing

1. LLVM version from Proton is different from the version found on my
   graphics driver: LLVM 7.0.1 (Proton) - LLVM 8.0.0 (Host)


2. Mesa driver version from Proton is different from the version of the
   mesa driver that provides GL and VK implementation on my host
   system: Mesa 18.3.6 (Proton) - Mesa 19.1.0 (Host)


3. Vulkan API version from Proton is different from the version used by
   the implementation of Vulkan as reported by vulkaninfo: 1.1.70
   (Proton) - 1.1.90 (Host)

I'm missing something here AFAIK Proton doesn't provide it's own mesa implementation. Can anyone shed some light and tell me why such a mismatch exists between these versions?

graphics wine steam mesa vulkan

share|improve this question

edited 1 hour ago

kub0x

asked 2 hours ago

kub0xkub0x

10111 bronze badge

New contributor

kub0x is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a comment | 

0

Proton is working fine with the latest dxvk implementation but when I browse on the log files of the games used by Proton I notice a mismatch between the mesa driver version of my host system and the listed there. What I know so far is that dxvk is a bridge so calls from dx10/11 can be translated to vulkan and processed in your host system, thus relying on your graphical driver and the vulkan mesa driver (amdgpu radv in my case).

These are the mesa driver version and the apiversion used by vulkan listed on the log of the game loaded by Proton (a win64 game):

AMD RADV POLARIS10 (LLVM 7.0.1):

Driver: 18.3.6

Vulkan:
1.1.70

The output of vulkaninfo reports apiversion "1.1.90" which is different form the version "1.1.70" used on Proton:

Vulkan Instance Version: 1.1.107

GPU id : 0

(AMD RADV
POLARIS10 (LLVM 8.0.0))

apiVersion = 0x40105a (1.1.90)

driverInfo = Mesa 19.1.0 (LLVM 8.0.0)

The output from glxinfo agrees on the mesa driver version and on the version of LLVM displayed on vulkaninfo:

OpenGL renderer string: Radeon RX 570 Series (POLARIS10, DRM 3.30.0,
5.1.14-arch1-1-ARCH, LLVM 8.0.0)

OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.1.0

Also, before the vulkan environment initialization happens, the following DLLs are loaded as reported by the log of the game:

Loaded L"C:windowssystem32vulkan-1.dll" at 0x7fa05e6e0000: builtin

Loaded L"C:windowssystem32winevulkan.dll" at 0x7fa05e6a0000: builtin

Maybe these DLLs are the causative of such a mismatch.

EDIT: When opening another game on Lutris with custom DXVK_HUD options I can see that both vulkan API version and mesa version match respective versions on my host. Still don't know why Proton has that behaviour.

Summarizing

1. LLVM version from Proton is different from the version found on my
   graphics driver: LLVM 7.0.1 (Proton) - LLVM 8.0.0 (Host)


2. Mesa driver version from Proton is different from the version of the
   mesa driver that provides GL and VK implementation on my host
   system: Mesa 18.3.6 (Proton) - Mesa 19.1.0 (Host)


3. Vulkan API version from Proton is different from the version used by
   the implementation of Vulkan as reported by vulkaninfo: 1.1.70
   (Proton) - 1.1.90 (Host)

I'm missing something here AFAIK Proton doesn't provide it's own mesa implementation. Can anyone shed some light and tell me why such a mismatch exists between these versions?

graphics wine steam mesa vulkan

share|improve this question

edited 1 hour ago

kub0x

asked 2 hours ago

kub0xkub0x

10111 bronze badge

New contributor

kub0x is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a comment | 

Proton is working fine with the latest dxvk implementation but when I browse on the log files of the games used by Proton I notice a mismatch between the mesa driver version of my host system and the listed there. What I know so far is that dxvk is a bridge so calls from dx10/11 can be translated to vulkan and processed in your host system, thus relying on your graphical driver and the vulkan mesa driver (amdgpu radv in my case).

These are the mesa driver version and the apiversion used by vulkan listed on the log of the game loaded by Proton (a win64 game):

AMD RADV POLARIS10 (LLVM 7.0.1):

Driver: 18.3.6

Vulkan:
1.1.70

The output of vulkaninfo reports apiversion "1.1.90" which is different form the version "1.1.70" used on Proton:

Vulkan Instance Version: 1.1.107

GPU id : 0

(AMD RADV
POLARIS10 (LLVM 8.0.0))

apiVersion = 0x40105a (1.1.90)

driverInfo = Mesa 19.1.0 (LLVM 8.0.0)

The output from glxinfo agrees on the mesa driver version and on the version of LLVM displayed on vulkaninfo:

OpenGL renderer string: Radeon RX 570 Series (POLARIS10, DRM 3.30.0,
5.1.14-arch1-1-ARCH, LLVM 8.0.0)

OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.1.0

Also, before the vulkan environment initialization happens, the following DLLs are loaded as reported by the log of the game:

Loaded L"C:windowssystem32vulkan-1.dll" at 0x7fa05e6e0000: builtin

Loaded L"C:windowssystem32winevulkan.dll" at 0x7fa05e6a0000: builtin

Maybe these DLLs are the causative of such a mismatch.

EDIT: When opening another game on Lutris with custom DXVK_HUD options I can see that both vulkan API version and mesa version match respective versions on my host. Still don't know why Proton has that behaviour.

Summarizing

1. LLVM version from Proton is different from the version found on my
   graphics driver: LLVM 7.0.1 (Proton) - LLVM 8.0.0 (Host)


2. Mesa driver version from Proton is different from the version of the
   mesa driver that provides GL and VK implementation on my host
   system: Mesa 18.3.6 (Proton) - Mesa 19.1.0 (Host)


3. Vulkan API version from Proton is different from the version used by
   the implementation of Vulkan as reported by vulkaninfo: 1.1.70
   (Proton) - 1.1.90 (Host)

I'm missing something here AFAIK Proton doesn't provide it's own mesa implementation. Can anyone shed some light and tell me why such a mismatch exists between these versions?

graphics wine steam mesa vulkan

share|improve this question

edited 1 hour ago

kub0x

asked 2 hours ago

kub0xkub0x

10111 bronze badge

New contributor

kub0x is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

share|improve this question

edited 1 hour ago

kub0x

asked 2 hours ago

kub0xkub0x

10111 bronze badge

New contributor

kub0x is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

share|improve this question

edited 1 hour ago

kub0x

asked 2 hours ago

kub0xkub0x

10111 bronze badge

New contributor

kub0x is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

asked 2 hours ago

kub0xkub0x

10111 bronze badge

New contributor

kub0x is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

asked 2 hours ago

kub0xkub0x

10111 bronze badge