Created attachment 45259 [details]
Geralt in-dialogue

Close-up from a dialogue scene

Created attachment 45260 [details]
Shani in-dialogue

Close-up from dialogue scene

I have attempted setting the VideoMemorySize key. It does not resolve the issue for me, but it increases load time on the main menu extremely much.

Many games suffer from that bug. See my report here notably for the Witcher, but also for Heroes VI and the King's bounty series : http://bugs.winehq.org/show_bug.cgi?id=32273

Confirming on 1.7.0.
Bug can be reproduced in demo http://www.fileplanet.com/183167/180000/fileinfo/The-Witcher-Demo

(In reply to comment #5)
> Confirming on 1.7.0.
> Bug can be reproduced in demo
> http://www.fileplanet.com/183167/180000/fileinfo/The-Witcher-Demo

Confirming.

Also in the GoG version of the game.

1.7.4 also affected

This bug happens only from time to time on my machine, so it is really hard to find. I tried bisecting wine code, but I hard hard time to reproduce it. On newest wine it happens one time for something like 20 runs.

I have the same issue with Wine 1.7.8 (tried many other versions too).  It happens to me every time.  I always just see eyeballs and teeth. Given the repeatability on my system, if there are any diagnostics I can run to help locate the issue, let me know.

Sean, if you can do regression testing: http://wiki.winehq.org/RegressionTesting

New link is http://www.gamershell.com/download_22384.shtml

Many times have launched on 1.7.11 and models are not an invisible as for now.
Driver 331.38. Need to test by someone else.

I can verifiy with wine 1.7.11 and nvidia driver 331.38 on gentoo am64 that the char is no longer invisible.

Confirmed fixed by two different people that were able to reproduce the issue.

(In reply to comment #14)
> Confirmed fixed by two different people that were able to reproduce the
> issue.

Tested with wine 1.7.11 and nvidia 331.38 a while ago and bug still occurs.

Perhaps problem was fixed by updating other packages?

I don't have any problems when I run game using intel graphics card. But when I use nvidia through bumblebee, I see this bug.

Wine without any changes in configuration.

Tried today with wine 1.7.12 and 1.7.10 nvidia 331.38-2 on arch. Still have this bug, installed only d3dx9_36 to fix black screen. Also tried all sorts of combinations of GLSL, Video memory, Offscreen renderer and Render target mode lock, nothing seems to work

(In reply to comment #17)
> Tried today with wine 1.7.12 and 1.7.10 nvidia 331.38-2 on arch. Still have
> this bug, installed only d3dx9_36 to fix black screen. Also tried all sorts
> of combinations of GLSL, Video memory, Offscreen renderer and Render target
> mode lock, nothing seems to work

Ok, I tried it again on xfce4. It works perfectly in there. However when using i3 it doesn't.

Is there possibility to reopen bug report? Current wine and nvidia drivers 331.38 don't solve this issue for me.

I may have just found the userside fix. Seems the issue actually relates to using native d3dx9_36.dll with the nvidia driver.

Having the same symptom everyone's describing. I'm on Fedora 20 64-bit, affects the 1.7.8 version the distro provides, also affected various versions I built on my own: 1.6.2, 1.7.11 and 1.7.12, only custom option was --without-gstreamer. Using nvidia 331.38 driver and the Steam version of the game.

After going backwards I upgraded back to 1.7.12. I then ran regedit and manually changed d3dx9_36 from native to builtin (see: HKEY_CURRENT_USER\Software\Wine\DllOverrides). Character models are now loading perfectly fine. I'll start a playthrough this week to confirm if it's stable. I'm not getting a black screen with 1.7.12.

Closing bugs fixed in 1.7.13.

For me the bug is still there, either whit wine 1.7.13

This bug is no longer immediately present for me. I only tried once, but the models were there.

I tried once again with wine 1.7.13 and nvidia 331.38 and I still have the same bug...

I catched this bug on every wine version I used. It is 1.7.17 now.

I found interesting fact. I hope it will be usefull.
When my game was on ext4 FS this bug was in 1 cases of 10
When I moving game, steam and wine prefix on btrfs I catch it in 9 cases of 10!

Why this f***ing bug closed and there is no possibility to reopen it?

In my case:
 - when I use nvidia with bumblebee - 10/10
 - when I use nvidia prime - maybe 1-3/10, so it's playable.
 - with integrated intel - 0/10, playable but on medium details

Bug also occurs more rarely when I have already opened other wine application.

So, I suppose that loading data from btrfs is slower than from ext4 ;-)

(In reply to Deve from comment #26)
> Why this f***ing bug closed and there is no possibility to reopen it?
> 
> In my case:
>  - when I use nvidia with bumblebee - 10/10
>  - when I use nvidia prime - maybe 1-3/10, so it's playable.
>  - with integrated intel - 0/10, playable but on medium details
> 
> Bug also occurs more rarely when I have already opened other wine
> application.
> 
> So, I suppose that loading data from btrfs is slower than from ext4 ;-)

There are multiple bugs, it appears. Likely your issue is either with the bumblebee driver, or btrfs.

(In reply to Austin English from comment #27)
> There are multiple bugs, it appears. Likely your issue is either with the
> bumblebee driver, or btrfs.

No, it's more likely that there is a single, not clearly reproducible, bug.

I can still reproduce this sometimes with current Wine, using Nvidia binary drivers (and no bumblebee or btrfs or anything weird). I tried to investigate this some time ago but with no real luck. IIRC an interesting tidbit was that replaying a game trace recorded with apitrace multiple times might give different results on different runs.

It looks like this happens only on Nvidia binary drivers? This might be a driver bug, although I don't have any hard evidence of that. OTOH, I'm pretty sure this is not FIXED.

Still an issue with the latest Wine.

Bug occurs when using optirun/primusrun to run the game.

If I use the intel gfx everything is fine. I haven't tried dri prime though

(In reply to Nicky from comment #30)
> Bug occurs when using optirun/primusrun to run the game.
> 
> If I use the intel gfx everything is fine. I haven't tried dri prime though

It also occurs with nvidia prime but much more rarely.


@Austin English
> There are multiple bugs, it appears. Likely your issue is either with the 
> bumblebee driver, or btrfs.

I wrote about btrfs because someone other said that it occurs much more frequently on btrfs. I suppose that some kind of data must be loaded fast enough. If it's not loaded on time, then we see this bug. It's because I wrote that ext4 is faster file system.

Possibly the same bug as bug #25325 ?

Missing models again occur only with nvidia drivers and some users report that they can get all models loaded after several tries (never happened with me though...)

I can confirm that when using DP output attached directly to the nvidia card and no primus/optirun I can get textures in all problematic games approximately every other time that I start them.

When running with primus/optirun I have yet to get textures in Witcher on Titan quest.

I can confirm on 

# uname -a
FreeBSD fbsdmain 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014     root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

% wine --version
wine-1.7.23

% glxinfo | grep -i version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL core profile version string: 4.3.0 NVIDIA 340.32
OpenGL core profile shading language version string: 4.30 NVIDIA via Cg compiler
OpenGL version string: 4.4.0 NVIDIA 340.32
OpenGL shading language version string: 4.40 NVIDIA via Cg compiler

This bug is triggered *every time* on my system. Really annoying... is there any workaround?

Thanks for your help!

There is a potential work around that works for me.

Once the game is running, switch to Virtual Console 1 (ctrl + alt + f1) and return to X (ctrl + alt + f7).  This corrects the invisible character problem, although I need to repeat this each time I run the game.

I have to correct myself: after setting the options

"OffscreenRenderingMode"="fbo" 
"RenderTargetLockMode"="textex" 

it works /most of the time/.

I had this bug a few times as well:
https://bugs.winehq.org/show_bug.cgi?id=25696

But restarting the computer (sic) "fixes" the issue.

@up

I'm not sure what you actually did, but http://wiki.winehq.org/UsefulRegistryKeys says that OffscreenRenderingMode is by default set to "fbo". And RenderTargetLockMode doesn't have property "textex" (only "disabled", "readdraw", "readtex").

https://bugs.winehq.org/attachment.cgi?id=45260
Shani is the best :-D

I reported this bug to nvidia:
https://devtalk.nvidia.com/default/topic/773623/linux/character-models-are-sometimes-invisible-in-the-witcher-game/

Arch, wine 1.7.30, Xorg 1.16.2, Awesome

Compton running -> invisible characters
Compton not running -> visible characters

(In reply to Deve from comment #38)
> https://bugs.winehq.org/attachment.cgi?id=45260
> Shani is the best :-D
> 
> I reported this bug to nvidia:
> https://devtalk.nvidia.com/default/topic/773623/linux/character-models-are-
> sometimes-invisible-in-the-witcher-game/

Hey,

nvidia guys are requesting more details. I have provided a post, but for some reason I've fallen victim to the auto banner of the nvidia forums. Please repost this:

As mentioned in the wine bug, it happens all the time to people using primus/optirun. The bug does occur when running an application directly on the nvidia card (via directly attached to the device display port) but much more rarely. It also occurs with nvidia prime setup but much more rarely.

Tl;Dr;

You need a dual video card machine where the nvidia card renders through bumblebee in order to get the bug every time. Otherwise it is a hit or a miss.

(In reply to Lauern from comment #39)
> Arch, wine 1.7.30, Xorg 1.16.2, Awesome
> 
> Compton running -> invisible characters
> Compton not running -> visible characters

Forgot to mention, GTX 750 Ti with driver 343.22, single GPU so no optirun/bumblebee/whatever. GOG version of the game.

Created attachment 50908 [details]
wined3d: Reorder shader constants.

Can you give this patch a try? It may fix the bug.

The issue here is that The Witcher reads past the end of the vertex shader constant array and gets an undefined value back. On paper d3d promises to return (0.0, 0.0, 0.0, 0.0) in this case, which makes The Witcher happy. In practise d3d isn't reliable either, but reads > 255 return 0 and reads < 0 return other data.

If you have two GPUs please test this patch with both of them. There's a risk that this patch fixes Nvidia GPUs and breaks others.

(In reply to Stefan Dösinger from comment #42)
> Created attachment 50908 [details]
> wined3d: Reorder shader constants.
>
> If you have two GPUs please test this patch with both of them. There's a
> risk that this patch fixes Nvidia GPUs and breaks others.

Indeed it does break rendering on Evergreen with Mesa :/
Specifically some wooden planks / wheels / boxes flicker with changing colors.

The patch seems to workaround the bug on Nvidia as expected.

I tested my patch on r600g and indeed some geometry that looked OK previously now starts to flicker.

With a different test I looked what the driver returns for reads with indices < 0 and > 255. My patch works as intended in the sense that it moves the int constants into the general range of c[-1] to c[-30]. Unfortunately the driver returns random values for uniforms that aren't defined by our shader, whereas Nvidia pretty reliably returns 0 for them. So instead of reading wrong but stable values (the int constants) the game now reads wrong and unstable values.

*** Bug 38711 has been marked as a duplicate of this bug. ***

Created attachment 51668 [details]
Range check relative array accesses

I'm attaching an alternative fix from bug 38711. This one SHOULD work without regressions but it will probably have somewhat of a performance impact. AFAICS not even ARB_robust_buffer_access_behavior guarantees any specific result. From the spec: "Out-of-bounds reads return undefined values".

I'm not sure we want this patch in Wine but I don't know of any other "safe" fix.

The patch from comment #(In reply to Stefan Dösinger from comment #42)
> Created attachment 50908 [details]
> wined3d: Reorder shader constants.

This patch fixes the issue for me.

(In reply to Matteo Bruni from comment #46)
> Created attachment 51668 [details]
> Range check relative array accesses

This patch also seems to work for me.

I've tested the two proposed patches. Is there anything else I can do to improve on the chances for a fix getting approved?

(In reply to Freso from comment #49)
> I've tested the two proposed patches. Is there anything else I can do to
> improve on the chances for a fix getting approved?

Thanks for testing!

No, I think that's all you can do. The problem is that my patch probably introduces a performance hit for a check that is usually unnecessary while Stefan's might not work depending on drivers' uniforms allocation patterns, so we don't have a clear way forward.

Maybe I should just go with something like my patch but with a registry setting to disable it?

I don't know the best way to move forward, but it would be great to not have to custom patch Wine on each update (though of course, at least there *is* a patch!), so if making a reg. entry for it is the best way to go, then please go for it. :)

(In reply to Freso from comment #51)
> I don't know the best way to move forward, but it would be great to not have
> to custom patch Wine on each update (though of course, at least there *is* a
> patch!), so if making a reg. entry for it is the best way to go, then please
> go for it. :)

Registry entry sounds good to me too, and would make it trivial to handle this with, for example, winetricks.

*** Bug 25696 has been marked as a duplicate of this bug. ***

(Replying to bug 25696 comment 19)
Fever, how much of a performance hit do you get with my patch?

(In reply to Matteo Bruni from comment #54)
> (Replying to bug 25696 comment 19)
> Fever, how much of a performance hit do you get with my patch?

It seems like I was talking nonsense... just felt like it had less performance (last time I played the game was through NVIDIAS optimus support where you cannot switch and have lots of tearing there it felt a bit faster (or better I could turn on the AA) now I'm using bumblebee)

From what I get know from my benchmark I even get an overall performance gain of 8 fps with this patch using primusrun. Plain wine run with primusrun I get like 30 fps in the temple quarter in vizima. With patch 38 and no artifacts. Measured over 2 minutes.

So I have to withdraw my previous comment when stating I got a performance hit.

Sorry for the false information!

Relevant System Information:

Awesome WM
1280x720
NVIDIA Corporation GK208M [GeForce GT 740M]
Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz

Witcher Settings:
No AA nor AF
Rest to high.

A performance gain seems really odd. Are you sure you benchmarked it right?

I expect the performance impact of this change to only show up in a GPU-limited situation. So it'd be interesting to run on a high resolution with multisampling and filtering set to the maximum. You can also try my CSMT patches to speed up things on the CPU side and then apply Matteo's hack on top of that.

I'm definetly not sure. I'll benchmark it again with your given advices. I also got a little heat problem with my laptop maybe that was the cause of the performance gain.

FYI I tried with your CSMT patches but this resulted for me in a very strange bug:
periodically freezes of the picture. The game went on and jumped after a few seconds back to normal. Maybe I messed up the build so I'll try it again.

This time I tried to be more precise. As soon as my cpu throttled down I stopped benchmarking (around a minute). This is without CSMT patches just because I don't have enough time today to apply the patches and recompile.

Settings:
everything max
1366x768 (sry but my laptop display doesn't support higher resolutions and I don't have another machine or monitor at hand)

My results

Plain wine:   34.67 fps average (last time value has to be a thermal issue)
patched wine: 33.68 fps average

I am still not quite sure if these values are correct as my cpu may be the problem, like I said I tried to only use the values before any overheating took place to get decent values but you never know :D. Maybe someone else should benchmark this too.

Is anything holding back the/a patch right now? It would be great to not have to custom patch Wine every update. :)

Arch Linux, up to date packages
NO bumblebee, NO optirun, ext4

Bug happens every single time, game is unplayable. :(

Bug still present with Wine 1.8rc1 each time I run the game.

My config: 
Ubuntu 15.10 Wily 64 bits
NVIDIA  GeForce GTX 770
official Ubuntu Nvidia drivers 340.93 resolution 1920x1080
Processor Intel i5-3570 3,4 Ghz
8 Go RAM

Reproducing here my reply from https://devtalk.nvidia.com/default/topic/773623/linux/character-models-are-sometimes-invisible-in-the-witcher-game/

---

We have investigated this issue and found out the cause of the problem.
An OpenGL vertex shader (generated by Wine based on a D3D shader in the Witcher) is created with the following uniform:
uniform vec4 vs_c[256];

The shader then dereferences vs_c[x], with "x" a dynamically computed value that sometimes exceeds 255. Reading outside of the bounds of a uniform array in GLSL is undefined behavior, which means that the implementation is allowed to do whatever it likes. On NVIDIA GPUs, the value returned will sometimes be 0.0, and sometimes different.
Since this value is used to warp the bones of the characters (to animate them), having an unpredictable value can result in some vertices being offscreen and even some geometry disappearing entirely.

The problem is not a NVIDIA bug, since the application is asking the GPU to do something that is undefined in the specification. We have been working with Wine on the investigation of this issue, and have also communicated our findings to the developers of the game.
A patch on the Wine bug tracker appears to work around the issue.

---


Arthur Huillet
NVIDIA Linux Graphics

attachment 50908 [details] and attachment 51668 [details] both work as workarounds, but the decisions seems to be to implement this in a toggleable fashion, since there might be a performance hit. I think we're waiting for either Fever to do more performance tests or Matteo Bruni to rewrite his patch. Not entirely sure which.

I wonder, if the patches exist since several months, why a fix is still not implemented?

Because it's a problem in one game only, it is arguably a game bug, and because the hack has the potential to cause a slowdown in all other games.

It would be nicer if we could get a semi-reliable 0.0 return from out of bounds reads without an explicit range check - attachment 50908 [details] is an attempt in that direction, but it has other problems that are difficult to address.

(In reply to Stefan Dösinger from comment #65)
> Because it's a problem in one game only, it is arguably a game bug, and
> because the hack has the potential to cause a slowdown in all other games.
> 
> It would be nicer if we could get a semi-reliable 0.0 return from out of
> bounds reads without an explicit range check - attachment 50908 [details] is
> an attempt in that direction, but it has other problems that are difficult
> to address.

Not one game. It seems bug 32273 is the same.
Games Heroes of Might And Magic VI and King's Bounty:* affected same way. And only on Nvidia. The bug appears in MacOSX so it doesn't depend on linux drivers. 

As well I encounter a bug with index shader out of range in game Sims 2 Season (bug 8051) that proposed a software rendering. I don't know if it is related just my thoughts.

I don't know if it is related to this bug: the "The longest Journey", some character models are sometimes invisible too:
https://bugs.winehq.org/show_bug.cgi?id=11819
https://bugs.winehq.org/show_bug.cgi?id=31278

(In reply to legluondunet@free.fr from comment #67)
> I don't know if it is related to this bug: the "The longest Journey", some
> character models are sometimes invisible too:
> https://bugs.winehq.org/show_bug.cgi?id=11819
> https://bugs.winehq.org/show_bug.cgi?id=31278

No, 11819 is a different bug. It is affected by Radeon drivers as well and corrected by those patchset.

(In reply to Sergey Isakov from comment #66)
> (In reply to Stefan Dösinger from comment #65)
> > Because it's a problem in one game only, it is arguably a game bug, and
> > because the hack has the potential to cause a slowdown in all other games.
> > 
> > It would be nicer if we could get a semi-reliable 0.0 return from out of
> > bounds reads without an explicit range check - attachment 50908 [details] is
> > an attempt in that direction, but it has other problems that are difficult
> > to address.
> 
> Not one game. It seems bug 32273 is the same.
> Games Heroes of Might And Magic VI and King's Bounty:* affected same way.

Does attachment 51668 [details] make any difference for those games?

(In reply to Matteo Bruni from comment #69)
> (In reply to Sergey Isakov from comment #66)
> > (In reply to Stefan Dösinger from comment #65)
> > > Because it's a problem in one game only, it is arguably a game bug, and
> > > because the hack has the potential to cause a slowdown in all other games.
> > > 
> > > It would be nicer if we could get a semi-reliable 0.0 return from out of
> > > bounds reads without an explicit range check - attachment 50908 [details] is
> > > an attempt in that direction, but it has other problems that are difficult
> > > to address.
> > 
> > Not one game. It seems bug 32273 is the same.
> > Games Heroes of Might And Magic VI and King's Bounty:* affected same way.
> 
> Does attachment 51668 [details] make any difference for those games?

Yes, preliminary testing, not final.
Attached screens before patching and after the patch.
Game Might & Magic.Heroes 6.Gold Edition.v 2.1.1.0 + 4 DLC
It is not me who tested ;( , in my case Radeon graphics has no such problem.

Created attachment 53516 [details]
Missing parts with unpatched wine

Created attachment 53517 [details]
Good picture after the patch

The user has a crash but I waiting some more testing. It may be other reason.

So I started playing this game again after quite some time.

Now I have a different laptop, an Asus N550JV, running arch linux. I find that with the lastest wine (1.9.2-1), I get this bug if I activate my nvidia card, but I have no bug running on the Intel card. If there's some more advanced reports I can provide I would be happy to do so, but the game is playable for me on Intel right now.

New result.
Patch from Matteo did the work. Patch from Stefan - no.
Game Might & Magic.Heroes 6.Gold Edition.v 2.1.1.0. Nvidia graphics.

A variant of my patch was just committed as 8e696dee5ff05377c8ccc59b4d204eb42d4cdeca. It's disabled by default, to enable it you can set the HKCU/Software/Wine/Direct3D/CheckFloatConstants registry key to "enabled".

(In reply to Matteo Bruni from comment #75)
> A variant of my patch was just committed as
> 8e696dee5ff05377c8ccc59b4d204eb42d4cdeca. It's disabled by default, to
> enable it you can set the HKCU/Software/Wine/Direct3D/CheckFloatConstants
> registry key to "enabled".

I got a message that the bug is fixed by this commit.
Tested games:
Heroes of Might & Magic VI
King's Bounty: Armored Princess - bug 32273
Titan Quest - bug 25325
For my mind these bugs can be closed fixed by this commit.

Bug 30550 should be fixed as well if someone with Nvidia test it.

CheckFloatConstants fixes same "invisible characters" issue in Grim Dawn, too.

Enabling CheckFloatConstants doesn't fix bug 30550 (invisible sprites in Rayman Origins).

Tested on ArchLinux, wine version 1.9.5, with an nVidia GeForce 560 Ti, proprietary driver version 361.28.

Enabling "CheckFloatConstants" works. I've played several hours without encountering this bug again.
Archlinux, Wine 1.9.6 with the Nvidia blob (GTX 780ti)

Hi all,

Tested today with Debian Jessie, wine 1.9.8 from the winehq repository, Nvidia blob (GTX680 - nouveau would not let me load a game).

Unfortunately, after 4 launches of the game, the bug was still present twice.

Do not hesitate to contact me to give further information, testing and logs if needed.

(In reply to vartaghan from comment #81)
> Hi all,
> 
> Tested today with Debian Jessie, wine 1.9.8 from the winehq repository,
> Nvidia blob (GTX680 - nouveau would not let me load a game).
> 
> Unfortunately, after 4 launches of the game, the bug was still present twice.
> 
> Do not hesitate to contact me to give further information, testing and logs
> if needed.

"A variant of my patch was just committed as 8e696dee5ff05377c8ccc59b4d204eb42d4cdeca. It's disabled by default, to enable it you can set the HKCU/Software/Wine/Direct3D/CheckFloatConstants registry key to "enabled". "

Did you enable the patch before testing?

I had to create the HKCU/Software/Wine/Direct3D/CheckFloatConstants registry key as there was no Direct3D under Wine in my registry. I set it to "enabled" (double quote included).

I think you shouldnt include "" in registery.

I removed the quotes and the bug did not reproduce so far on about half a dozen launch. My bad, I think it's good now.

Matteo, the patch was committed (8e696dee5ff05377c8ccc59b4d204eb42d4cdeca) and the game works, so we can consider it as fixed using the registry switch or there are more things to do in order to fix this?

Tested with all the King's Bounty in the Ultimate Edition (more than 10 hours with King's Bounty The Legend) and Fantasy Wars and it works perfectly.

(In reply to vartaghan from comment #85)
> I removed the quotes and the bug did not reproduce so far on about half a
> dozen launch. My bad, I think it's good now.

(In reply to Ottopower from comment #87)
> Tested with all the King's Bounty in the Ultimate Edition (more than 10
> hours with King's Bounty The Legend) and Fantasy Wars and it works perfectly.

Assuming as fixed by 2 different people.

Closing bugs fixed in 1.9.11.

Removing 1.8.x milestone from bugs included in 1.8.4.

Could someone please add the option in the "Useful registry keys" wiki ( https://wiki.winehq.org/Useful_Registry_Keys ) so I don't have to browse through the bug report to find the workaround. I would do it myself, but I don't have access.

(In reply to Nicky from comment #91)
> Could someone please add the option in the "Useful registry keys" wiki (
> https://wiki.winehq.org/Useful_Registry_Keys )

I already did some time ago.

*** Bug 25325 has been marked as a duplicate of this bug. ***

*** Bug 32273 has been marked as a duplicate of this bug. ***

*** Bug 39176 has been marked as a duplicate of this bug. ***

*** Bug 28062 has been marked as a duplicate of this bug. ***

Hello, just to give more (unneeded) feedback! :)

With Manjaro, GTX 770, Drivers 470.94, wine 7.0-rc2 the issue was 100%.
After a bit googling I found the NVidia discussion and the link to this issue.

Adding the registry key solved it, thanks Matteo!