Nvidia driver discussion

[zaps166]

Nvidia introduced new Vulkan SPIR-V compiler. Games using DXVK runs very slow with it (it can be disabled by using __GL_NextGenCompiler envvar).

Comparision [3840x2160, new vs old, disabled by envvar]:

• Tomb Raider 2013 main menu (ultra, but without tesselation): [7 FPS vs 40 FPS]
• NieR:Automata (some scene, full details, anti-aliasing off): [14.5 FPS vs 24 FPS]
• Sword Art Online Hollow Realization (Teleport Gate Plaza, full details, anti-aliasing off): [13 FPS vs 45 FPS]

Moreover:

• Tomb Raider 2013 scene with tesselation enabled is black (on old nvidia shader compiler graphics is corrupted, but visible)
• Sword Art Online Fatal Bullet scene is also black
• No performance difference on Unigine Heaven (DXVK) and Vulkan Examples (native Linux)

System information

• GPU: GeForce GTX 1080
• Driver: 396.18
• Wine version: 3.5
• DXVK version: 41132b8
• X11 Compositor: none/disabled
• Nvidia Force Composition Pipeline: enabled
• UseNvKmsCompositionPipeline: false

[doitsujin]

Well, the new compiler doesn't seem to be mature yet, don't use it for gaming with DXVK. Gathering some feedback might help them improve it though, and maybe uncover some new bugs in DXVK.

As for Tessellation in Tomb Raider 2013 not working properly, that is a DXVK bug I think.

@pdaniell-nv Could you keep an eye on this thread as well?

[pdaniell-nv]

Thanks for the heads up. I'll report back when I know more.

[xpander69]

Confirming its slow. GTA V usual 60-90FPS went to 20-35 FPS
Fixes GTA V sun issue though

396.18 with __GL_NextGenCompiler=1

396.18 with __GL_NextGenCompiler=0

Crysis 2 Tesselation got broken and performance went down

396.18 with __GL_NextGenCompiler=1

396.18 with __GL_NextGenCompiler=0

[vesim987]

@pdaniell-nv
There is example from The Witcher 3: https://streamable.com/0zgjl it is approximately 1/3 of performance of the old compiler.
Disabling Hull and Domain Shaders bumps up performance twice.

[pingubot]

Hi,

here are the issues i noticed so far:

My Card: GTX 970
Driver: 396.18

Crysis2:

• Tesselation is broken, see pictures of XPander
• Performance is minimum cut into half (gpu is fully loaded all the time)

Crysis3:

• Performance is minimum cut into half (gpu is fully loaded all the time)
• Didn't notice huge display issues yet, need to check

Battlefield Bad Company 2:

• I can enable MSAA now which crashes the game before
• Performance is 30% of the old driver and gpu load increased from ~60% to 100%
• Graphical issue, file attached:
• Enabling MSAA fixes those graphical issues
  

Battlefield 3:

• I can enable MSAA now which crashed the driver before
• Without MSAA the performance is unaffacted with the new driver. With MSAA 2x enabled the per is cut down to 30%, from ~ 100fps to ~30fps.

Far Cry 3:

• I can enable MSAA now which crashed the driver before
• Without MSAA the performance is unaffacted with the new driver. With MSAA 2x enabled the perf is cut down to ~36fps, from ~ 56fps.

Diablo 3:

• I can enable MSAA now which crashed the driver instntly before. But it is still not usable due to game freezes
• Performance is ~ 30 fps in the menu, was >100 fps before with MSAA disabled

Unigine Heaven.

• Doesn't launch for me anymore with Tesselation on, works with tesselation off
• No graphical issues detected so far, but was a super quick test

Many thanks !
Christian

[doitsujin]

It should be noted that not all of the games @pingubot mentioned are well-tested and some of them have known issues. I think only Crysis 2 and Unigine Heaven are expected to work properly.

[pingubot]

I haven't played all the games from beginning to the end (i did that for crysis 2, also a few hours into crysis 3, for the rest it is really less than 1 hour per game), but the things i mentioned are the things that have changed between the new and the old nvidia driver spirv compiler. So it is just to show the differences.

[pdaniell-nv]

@doitsujin Are there any SPIR-V work arounds in place for our old compiler? If so, they probably need to be removed for the new compiler in 396.18 and beyond.

[doitsujin]

@pdaniell-nv the only Nvidia-specific workaround in my compiler is adding an extra component to the coordinate vector for the OpImageSampleDref* instructions, which is legal in SPIR-V and doesn't actually seem to cause any issues with the new compiler.

With the exception of the aforementioned workaround, as well as GPUs which do not support the ShaderImageReadWithoutFormat capability, it generates the same code for all GPUs.

@pingubot What I'm trying to say is that you might simply be hitting undefined behaviour in some cases, which just happened to work for some reason with the old compiler.

[pdaniell-nv]

Ok, thanks. We're looking into the functionality and performance regressions described above.

[SveSop]

Using __GL_NextGenCompiler=1 (default) causes some sort of "black/green'ish" picture in Unigine benchmarks. This is with commit: 140dc27
On the other hand, there was a change vs. previous in Unigine Superposition with the setting __GL_NextGenCompiler=0 when it comes to lightreflections.. (Did not start with default =1 setting)

[pchome]

TW3:

• CPU usage: ~18%
• GPU usage: 100%
• Inverted colors (yellow == green)
• Texture glitches
• low fps (1/3, due to low cpu usage ?)
• log diff:
  old : warn: D3D11Device: No matching border color found for (1e+10,1e+10,1e+10,1e+10)
  new: warn: D3D11Device: No matching border color found for (1e+010,1e+010,1e+010,1e+010)

[pchome]

As an opposite effect to bugs in other games/applications I can report Just Cause 3 runs without issues (except green color dominated) now.

This is for wine-staging, game was launched from steam menu, no other settings touched.
Without DXVK it fully unplayable, a lot of glitches and missing textures.

[dmitry64]

Tested Dark Souls 2 and Dark Souls 3 on this commit: adb1789.
Both games now have inverted colors (yellow is now green) with __GL_NextGenCompiler=1. With old compiler colors are normal.

UPDATE: On the latest commit 8dfe708 color issues are gone (with new compiler). Or maybe it was just a glitch.

On my GTX 970 with 396.18 driver, with 1440p resolution, wine 3.5, on low settings Dark Souls 3 is playable at 40-55 FPS. If i enable shadows in graphics settings (Off->Low) performance drops to 1-2 FPS.

[nairaner]

With new compiler Path of Exile crash while loading with:
NVRM: Xid (PCI:0000:01:00): 8, Channel 0000006a
Setting __GL_NextGenCompiler=0 makes the game work
Using DXVK: 8dfe708
PathOfExile_x64_d3d11.log
PathOfExile_x64_dxgi.log
shaders.zip

[pingubot]

Want to add FEAR 3 to the list of affected games:
All game settings at max, 1920x1080, MSAAx 4. GPU load is 100% with the new and with the old compiler:

Driver 396.18:

New Compiler: 9 fps
Old Compiler: 63 fps

Disabling MSAA leads to:

New Compiler: ~ 35fps
Old Compiler: ~ 150fps

Many thanks !
Christian

[Glog78]

Want to add Skyrim SE to the list of affected games:

New Compiler = 3.5 to 5 fps
Old Compiler = 60+ fps (vsync on)

Settings have no influence at all on the bad performance of the New Compiler.

[tpruzina]

I suggest using __GL_NextGenCompiler=0 until this gets resolved (presumably upstream problem).

[pingubot]

Want to add Dirt 2 demo to the list:

Old Compiler: No graphical issues, ca. 100fps in menu outside
New Comppiler: ~ 15fps in menu outisde and those funky pictures:

[pdaniell-nv]

Thanks for all the reports posted here on our 396.18 driver. We have just released a new 396.18.02 beta driver on our Vulkan driver page here: https://developer.nvidia.com/vulkan-driver

This should resolve some of the performance and corruption issues reported. As an added bonus this driver also increases the number of UBOs allowed per shader stage from 12 to 15 as discussed in issue #90.

We look forward to hearing feedback on the new 396.18.02 driver. Thanks!

[varris1]

Driver version: 396.18.02
DXVK: b82ae16
Card: GTX 970

This is what Overwatch via DXVK (b82ae16) looks like with:
__GL_NextGenCompiler=1
https://imgur.com/a/eNRnK

__GL_NextGenCompiler=0
https://imgur.com/a/9Knko

So it seems like there is still some corruption going on.

EDIT: fixed with commit 5eaacf7

[varris1]

Driver version: 396.18.02
DXVK: 05a96e9
Card: GTX 970

This Unity engine demo seems to have issues with corruption as well:
https://blogs.unity3d.com/en/2015/06/24/releasing-the-blacksmith/

__GL_NextGenCompiler=1:
https://imgur.com/a/9xfhs

__GL_NextGenCompiler=0:
https://imgur.com/a/mZKTi

EDIT: fixed with commit 5eaacf7

[sambow23]

Driver: 396.18.02
DXVK: 05a96e9
GPU: GTX 1060 6GB

The performance issues on GTAV with __GL_NextGenCompiler=1 are fixed, but with the maximum settings, this line exists onscreen

This does not happen with __GL_NextGenCompiler=0

[pdaniell-nv]

For the issue with the Unity engine demo that @varris1 reported, it appears the SPIR-V is invalid in at least one of the shaders. In one of them there is this:

        %84 = OpFAdd %v3float %79 %83
        %85 = OpLoad %float %o0
        %86 = OpVectorShuffle %float %85 %84
              OpStore %o0 %86

In this example %o0 is actually a pointer to v4float and the OpVectorShuffle should have be used with vector types. So some kind of scalar/vector mixup going on. Actually the spir-v validator catches the OpLoad type mismatch above, but not the OpVectorShuffle issue.

[doitsujin]

@pdaniell-nv what are the settings that generate the invalid shader? Just tested with Higher and I'm not getting spirv-val errors on any of the spir-v shaders.

Edit: Not getting any errors with the other presets either.

[fls2018]

For those curious, there is a new rebased Vulkan beta driver available version 435.19.02, which can be found in the usual place: https://developer.nvidia.com/vulkan-driver. This has all the goodness that went into 435.17, and all the extra Vulkan stuff that was in the old 418.52.xx driver series.

I had a small issue after installing this in TW3 where hairworks didn't appear to be working but after manually wiping the shader cache the hair came back.

Edit: This new dev driver definitely breaks hairworks. First run it renders correctly but upon reloading the shaders it doesn't:

I didn't have this issue with 435.17, haven't tried 435.21 yet.

Edit again: I've resolved the issue with DXVK_STATE_CACHE=0 so maybe @doitsujin can take a look at it although it only seems to affect the 435.19.02 driver.

[liam-middlebrook]

We just released Vulkan Beta Driver Linux: 435.19.03

Fixes:

• Fixed a bug which caused corruption in the following DXVK titles:
  • Saints Row IV
  • Saints Row: The Third
• Fall back to system memory when video memory is full for some driver-internal allocations. This can help fix Xid 13 and Xid 31 cases when video memory is full.

[SveSop]

@liam-middlebrook

Tested the following with this new 435.19.03 driver:
Clear ~./nv/ folder of any cache data (eg. cd ./nv/ rm -rf *). Delete the game.dxvk-cache files (eg. /drive_c/Program Files (x86)/Unigine/Valley Benchmark 1.0/bin/Valley.dxvk-cache)

Run a few rounds of Unigine Valley - OK
Open in the SAME wine-prefix: Unigine Valley - 1600x900 windowed + Unigine Heaven - 1600x900 windowed.

Result:

NVRM: GPU at PCI:0000:01:00: GPU-49e16335-552c-8128-77c9-81cbe8aed6bf
NVRM: GPU Board Serial Number: 
NVRM: Xid (PCI:0000:01:00): 32, pid=1124, Channel ID 00000023 intr0 00040000
NVRM: Xid (PCI:0000:01:00): 32, pid=25970, Channel ID 00000023 intr0 00040000
NVRM: Xid (PCI:0000:01:00): 31, pid=25970, Ch 00000023, intr 00000000. MMU Fault: ENGINE HOST0 HUBCLIENT_HOST_CPU faulted @ 0x1_2004c000. Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_READ
NVRM: Xid (PCI:0000:01:00): 31, pid=25970, Ch 00000024, intr 00000000. MMU Fault: ENGINE CE3 HUBCLIENT_CE1 faulted @ 0x1_1ca80000. Fault is of type FAULT_PTE ACCESS_TYPE_VIRT_READ

PID:1124 is nvidia-persistenced, 25970 is Unigine Heaven.

Fiddling with these caches does sometimes produce these results, and did also with the new 435.19.03 driver. Now, one can argue that "there is no need to touch that", but the facts are that whenever something changes - be it wine, dxvk or driver version - the caches ARE being rebuilt, and imo these unexpected results seem to pop up out of the blue.

I will keep testing more tho. And it might just aswell be 2 different bugs here, and that the 435.19.03 driver fixes memory allocations that the #1100 thread is about. Lets hope so :)

Thanks for working on this problem!

[pchome]

For: 435.19.03

Saints Row IV
Still glitching like hell, seems even more bugs was introduced since last time I checked, but runs w/o __GL_NextGenCompiler=0.

Saints Row: The Third
I'll check eventually, don't want to do this right now, should be the same as Saints Row IV.

Jotun: Valhalla Edition
Forced Proton, just side-check after I remove __GL_NextGenCompiler everywhere. For both DXVK/D9VK:

[  295.687624] NVRM: GPU at PCI:0000:01:00: GPU-106440f5-fdea-afa0-176b-9611e38e703c
[  295.687629] NVRM: Xid (PCI:0000:01:00): 13, pid=884, Graphics Exception: Shader Program Header 9 Error
[  295.687632] NVRM: Xid (PCI:0000:01:00): 13, pid=884, Graphics Exception: ESR 0x405840=0x82000200
[  295.687765] NVRM: Xid (PCI:0000:01:00): 13, pid=884, Graphics Exception: ChID 0044, Class 0000b097, Offset 0000238c, Data 00005700

[  488.599790] NVRM: Xid (PCI:0000:01:00): 13, pid=4897, Graphics Exception: Shader Program Header 9 Error
[  488.599800] NVRM: Xid (PCI:0000:01:00): 13, pid=4897, Graphics Exception: ESR 0x405840=0x82000200
[  488.599974] NVRM: Xid (PCI:0000:01:00): 13, pid=4897, Graphics Exception: ChID 0044, Class 0000b097, Offset 00001614, Data 00000000

Same as prev. driver versions.

[doitsujin]

@pchome did you try deleting your Nvidia shader cache? Apparently some people are having issues that it doesn't always get invalidated properly after a driver update, although I'm not sure if there's anything to it.

[pchome]

@doitsujin
Ok, I dropped all caches and settings (except winetricks vd=1280x720), and now everything looks good on default "Ultra" preset. Except the character still flicker sometimes.

[pchome]

Shader dump and debug logs for Jotun: Valhalla Edition: Jotun.zip

[pchome]

... character still flicker sometimes.

Happened to me several times in Mad Max (linux vulkan branch). So it's not DXVK issue.

[tannisroot]

@pchome the fact that 2 completely different games have visually similar issues does not prove that it's not a DXVK issue.

[pchome]

@tannisroot

the fact that 2 completely different games have visually similar issues does not prove that it's not a DXVK issue.

That's true. Let's say, it's very likely not DXVK issue. Because:

• it was in native linux port of Mad Max game (not Wine/DXVK)
• it was very similar, visually (usually happen in cutscenes or right after, temporary disappearing parts of closes/equipment, depend on point of view)

This thing is very random, very hard to "catch". I just can't spend the whole day in "apitrace" mode, hunting it. If there are other methods I can use to help with this, I'll happily use them.

[kakra]

@pchome "native linux ports" often are not authentic native ports: They are usually derived from the Win32 code base by using wrappers similar or based off wine. You can see that from the console output of some native ports when comparing error messages to wine logs: They look exactly the same. This is also true for Feral ports: While they don't seem to use a simple EXE wrapper but instead a native compile output, they still use wrappers around the original code base which works much like DXVK or wine - with the difference being optimized exactly for the game. It may even share the same ideas and thus produce similar bugs to wine/DXVK. In fact, such bugs may actually be in Direct3D - and the game working around it will then see a bug in the port. Feral ports may have the benefit of instead wrapping the Direct3D calls, they may actually swap the graphics engine to a native Linux version, then apply their wrapper patches on top. This still may show similar bugs.

BTW: I didn't see any graphical issues in the Mad Max port, neither with the OpenGL nor with the Vulkan beta.

[pchome]

@kakra

BTW: I didn't see any graphical issues in the Mad Max port, neither with the OpenGL nor with the Vulkan beta.

It appears nobody can reproduce this, could be setup (or hardware) problem. I do have some custom settings. In case it can help with the issue, here they are:

xorg.conf.d/70-device.conf , "Device" section:

# reduces window lag, default 0x3 (?)
Option "RegistryDwords" "OGL_MaxFramesAllowed=0x1"

# for >= 375.10 and ForceFullCompositionPipeline
Option "ForceCompositionPipeline" "true"

# fix CompositionPipeline GPU usage for >= 390.25
Option "UseNvKmsCompositionPipeline" "false"

The first one was there for testing purposes, and forgotten. I'm not sure it changes anything, copy/pasted from internet. The other two are for Vsync OFF options. The last one was a "hot-fix", but I didn't checked if something changed since 390.x version.

I have Vsync OFF everywhere (KWin compositor/Nvidia settings/game), also Flipping disabled in Nvidia settings. KWin compositor always ON, while I playing a game in windowed mode. Finally some Nvidia specific environment variables are set in .profile:

export __GL_SHADER_DISK_CACHE_PATH=$XDG_CACHE_HOME/nv
export CUDA_CACHE_PATH=$XDG_CACHE_HOME/nvCUDA

to move the .nv directory from user's home root directory.

In addition, __GL_SHOW_GRAPHICS_OSD=1 and __GL_SHADER_DISK_CACHE_PATH=/path/to/game/root are usually set for each game individually.

[kakra]

@pchome These are a lot of settings, and some of those you seem to have for quite a long time. I can only tell you that I neither need nor use any of those. I've set kwin to always use vsync here because otherwise I'd see tearing in videos played on Youtube. For the rest of the window system it doesn't seem to matter what vsync mode kwin is using. Instead I allowed fullscreen windows to disable compositing, I think my Proton patch for that has been ported also to Lutris.

Of course, this won't work properly if you force a composition pipeline through the driver. The driver will always force scaling and vsync in the last instance. I tried "ForceCompositionPipeline" once and I had bad performance effects due to this. I reverted that change. This setting does not work well if anything else tries vsync.

I also allow flipping because in theory it allows higher performance: Swapping back buffers won't be a blitter operation then but just a page flip (the GPU doesn't have to copy video memory around). This only works properly with single monitor or when using clone mode. Otherwise the driver will force blitting anyways.

I'm also not sure if it is wise to force a maximum frame count because some graphics stacks need at least 3 frames to work properly, especially if you're using a composition pipeline.

Regarding your environment vars: The path vars should be safe tho I don't see a point in micromanaging this.

Have you ever tried with reverting any of those Xorg settings to default? This combination of settings may actually make a difference for stability, I think. Also, on my machine, these are not needed for tear-free, stutter-free, and low-lag gaming. And I'm pretty confident that using "ForceCompositionPipeline" is the wrong flag to fix any of the tear/lag/stutter problems: That option is made for a different purpose, and some of its "positive" effects are just side-effects.

[pchome]

@kakra

Have you ever tried with reverting any of those Xorg settings to default?

Yes, I even tried to set up triple-buffering, and it works flawlessly, but for a very few games.

I have two problems with this: weak hardware and ultra-wide monitor. For the first case, it's very hard to reach stable 60fps, and for the second, many games in my library are not designed for other then 16:9 monitor resolutions. So, this setup is ok for me, when I usually play games in 16:9 window, and I'm fine to loose 10-15fps (due to KWin compositor and a composition pipeline) to have stable ~30fps and similar behavior in most cases. In addition, I able to observe a game/system behavior via Conky monitors on left and right desktop sides. That's why I don't like if something trying to force full-screen mode and disable composition.

[rawfoxDE]

There is a problem with shader creation with StarCitizen.
I dont know, where to show that problem, so im doing here, best pool i know for gfx issues with Linux/Wine.

There is a new SC update incoming and while we first saw some issues with the hairwork.
We then missed whole heads or issue of all game toons (add 1) until the recent update completely made our screens dark (add3) as a couple shaders do not work because they are only 20bytes and did not get created properly.

This is, what the directory looks like:

`[rawfox@operator CGCShaders]$ ll

insgesamt 412
-rwxrwxr-x 1 rawfox rawfox 49158 11. Okt 02:06 GasCloudGen@AccumulatePointLightsCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 48506 11. Okt 02:06 GasCloudGen@AccumulateSunLightCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 42426 11. Okt 02:06 GasCloudGen@AccumulateZeroLightsCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 61551 11. Okt 02:06 GasCloud@ProcessScatteringQueriesCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 69863 11. Okt 02:06 GasCloud@TraceCloudCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 20 11. Okt 02:07 GpuSkinning@Deformer_BShapes_DQSkinning.fxcb
-rwxrwxr-x 1 rawfox rawfox 20 11. Okt 02:07 GpuSkinning@WrapDeformer.fxcb
-rwxrwxr-x 1 rawfox rawfox 28166 11. Okt 02:06 PlanetTerrainHeightMap@HeightMapResolvePass.fxcb
-rwxrwxr-x 1 rawfox rawfox 33196 11. Okt 02:06 PlanetTerrainShadows@ShadowMapGenPass.fxcb
-rwxrwxr-x 1 rawfox rawfox 20 11. Okt 02:06 TiledShading@TiledDeferredShadingCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 20 11. Okt 02:06 VolumetricFog@InjectInscatteringCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 20 11. Okt 02:06 VolumetricFog@ReprojectCS.fxcb
`

When we copy the already created shaders from a Windows installation of the game, everything under Linux is going ok, until the game creates new shaders were some are 20bytes/broken as well, so we (#LUG Linux Users Group at CIG) think, there is a problem with the shader creation under wine. We suspect missing functions in wine again and we are also hard at debugging atm, but im here now for more input, info's, just a salvage strategy.

What would you say ?

add1:

add2:

add 3:

[fls2018]

There is a problem with shader creation with StarCitizen.
I dont know, where to show that problem, so im doing here, best pool i know for gfx issues with Linux/Wine.

There is a new SC update incoming and while we first saw some issues with the hairwork.
We then missed whole heads or issue of all game toons (add 1) until the recent update completely made our screens dark (add3) as a couple shaders do not work because they are only 20bytes and did not get created properly.

This is, what the directory looks like:

`[rawfox@operator CGCShaders]$ ll

insgesamt 412
-rwxrwxr-x 1 rawfox rawfox 49158 11. Okt 02:06 GasCloudGen@AccumulatePointLightsCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 48506 11. Okt 02:06 GasCloudGen@AccumulateSunLightCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 42426 11. Okt 02:06 GasCloudGen@AccumulateZeroLightsCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 61551 11. Okt 02:06 GasCloud@ProcessScatteringQueriesCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 69863 11. Okt 02:06 GasCloud@TraceCloudCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 20 11. Okt 02:07 GpuSkinning@Deformer_BShapes_DQSkinning.fxcb
-rwxrwxr-x 1 rawfox rawfox 20 11. Okt 02:07 GpuSkinning@WrapDeformer.fxcb
-rwxrwxr-x 1 rawfox rawfox 28166 11. Okt 02:06 PlanetTerrainHeightMap@HeightMapResolvePass.fxcb
-rwxrwxr-x 1 rawfox rawfox 33196 11. Okt 02:06 PlanetTerrainShadows@ShadowMapGenPass.fxcb
-rwxrwxr-x 1 rawfox rawfox 20 11. Okt 02:06 TiledShading@TiledDeferredShadingCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 20 11. Okt 02:06 VolumetricFog@InjectInscatteringCS.fxcb
-rwxrwxr-x 1 rawfox rawfox 20 11. Okt 02:06 VolumetricFog@ReprojectCS.fxcb
`

When we copy the already created shaders from a Windows installation of the game, everything under Linux is going ok, until the game creates new shaders were some are 20bytes/broken as well, so we (#LUG Linux Users Group at CIG) think, there is a problem with the shader creation under wine. We suspect missing functions in wine again and we are also hard at debugging atm, but im here now for more input, info's, just a salvage strategy.

What would you say ?

add1:

add2:

add 3:

I noticed shadercache creation issues since 435.19.02 on the vulkan beta branch exclusively in both Witcher 3 (as reported above) and FO76.

Swapping back to non developer branches gets rid of it, that said I haven't tested Star Citizen or later dev branches myself.

[rawfoxDE]

Thanks for reply, but this happens on AMD users as well, so this is rather offtopic and while im really sorry about abusing this thread, i just cant find a better place as people here in this thread are specialized on such issues.

Its a wine problem and doitsujin as well as daniell may have a good insight, how shaders are created under wine, so i hope to get some input here :)

[rawfoxDE]

It turned out that just vcrun2017 was missing in the wine prefix.
Sorry for rubbing this thread /wave

[xPakrikx]

Witcher 3 with new driver 440.31 keeps stuttering. Do you have same experience ? I use Fedora 31 + drivers from rpmfusion repo. Game settings: DXVK 1.4.4, Esync ON, wine: lutris-nofshack-4.19 (other lutris default, no special options)

[Joshua-Ashton]

Does the stutter go away after playing for a while/restarting the game?

[xPakrikx]

looks like its better in windowed borderless mode :) interesting

[DadSchoorse]

@liam-middlebrook
I'm working on reshade effects in my post processing vulkan layer.(DadSchoorse/vkBasalt#45) However there seems to be an issue in games that run with proton on nvidia systems. Other games and applications aren't affected.
The bug causes a hang on vkCreateGraphicsPipelines for the pipelines that vkBasalt tries to create.
The driver I'm using for testing is 440.44.

Edit: I fixed the issue in DadSchoorse/vkBasalt@8310fd6
That's not great because dxvk might run into the same issue someday.

[pchome]

@pdaniell-nv
Not DXVK-related, but FYI. I noticed that on https://developer.nvidia.com/vulkan-driver page both GeForce GTX 750 Ti and GeForce GTX 750 GPUs are listed under Kepler GPU Architecture section, but known to be Maxwell 1 GPUs.

$ grep GM107 /var/log/Xorg.0.log

[   183.696] (II) NVIDIA(0): NVIDIA GPU GeForce GTX 750 Ti (GM107-A) at PCI:1:0:0 (GPU-0)

[pdaniell-nv]

@pchome Thanks for noticing and reported that issue. You have a sharp eye. Should be fixed in the next few minutes.

[SveSop]

@pdaniell-nv
Hopefully this is not too much off-topic, but if it is, i apologize for that.

I am wondering something when it comes to nVidia's "driver branches" - as of now it is the "Current official release" and the "vulkan driver" branch. Does fixes from the "vulkan driver" branch get incorporated in the "official release", or are these somewhat more separate than that?

As of now, the "official release" driver is 440.59, where as the "vulkan driver" is 440.58.02, and my understanding is that this is "branch" 59 and 58 respectively. Thus the "release driver" is of a newer "version" than the vulkan one, but from what i understand this is just because of "different branches"? Or have i misunderstood?

So, if i have not misunderstood, am i right in thinking that "fixes" that happens in the same "branch" carry over, but not necessarily to the other branch?

eg. If a fix for DXVK happens in 440.43.02 it will carry over to 440.48.01 and subsequently over to 440.58.01? But not necessarily over to the "release branch" of 440.59?

I am aware that new bugs could be introduced, but atleast it would be easier to figure out, cos it seems as installing a newer "version" is not really the best bet when it comes to compatibility with vulkan/dxvk at times. I have had quite a few weird crashes with the 440.59 "release branch" that does not happen with the 440.43.02 driver.

If you say that all "fixes" introduced in the 440.43.02 "vulkan driver branch" is incorporated in the 440.59 "release branch", it means it would be a new bug vs. if those two driver "branches" not really have the same code-base it is somewhat harder to compare between those branches.

Hopefully you understand what i mean, and again sorry if this is too much off-topic.

[pdaniell-nv]

Driver 440.59, and the rest of the Linux 440.xx drivers, come from the core "r440" release branch. Driver 440.58.02, and the other 440.xx.yy drivers found in the Vulkan beta driver page, come from a side-branch off the main r440 release banch, let's call it vk440. That side-branch has special Vulkan integrations from our "main" development branch, to get those changes out to the public sooner. Those changes are usually "beta" quality and would introduce too much risk going directly to the r440 release branch. Those changes will eventually land in some future release branch.

So, from your example, if a DXVK fix was integrated from main to vk440 and released in 440.43.02, then that same fix will also appear in later 440.xx.yy Vulkan beta drivers like 440.48.01 and 440.58.01. That fix may not land in the 440.xx general release drivers, like 440.59. The changelog should indicate what's new in each 440.xx general release driver.

If you're a bleeding-edge Vulkan developer the 440.xx.yy Vulkan beta drivers might be a good choice to get the very latest features and fixes for use during development. If you see regressions between Vulkan beta releases, please let us know.

For most people the 440.xx general release drivers are the best choice. Shipping products should only rely on the users having general release drivers.

[SveSop]

@pdaniell-nv
It seems as there is some instability with the 440.58.0x set vs. the previous 440.48.0x and 440.43.0x set, as those are working fine. I also experience random crashes when playing WoW with release 440.59 drivers.

There is nothing suspicious logged in the dxvk logs, nor in syslog (no XID errors). When using DXVK World of Warcraft just crashes with a Error 132, (without that being very telling of anything) but there is a difference when using vkd3d. When using vkd3d and D3D12, WoW will hang for 3-5 seconds, then continue. The WoW logs sais something about reinitializing the driver when that happens.

I will check out the next vulkan driver when that gets posted and compare then, and if i still struggle i will delve more into trying to get some logging done. But it is a nut to crack, as it (as before) can crash 2 times in 30 minutes, or 0 times in 5 hours.

From the changelog of the 440.58.02 driver:

Fixed a visual glitch of Vulkan applications when falling out of flipping (such as when doing alt-tab) [Linux]

We are still investigating a glitch that reproduces with the GNOME desktop

I do alt-tab a bit when playing, as i usually have Chrome open on my second monitor... and i use a GNOME desktop.. so it could be related to something there.

[doitsujin]

Closing due to old age. Please open a new issue when encountering bugs.