iXit / wine-nine-standalone

Build Gallium Nine support on top of an existing WINE installation
GNU Lesser General Public License v2.1
272 stars 23 forks source link

Risen 3 - broken visuals #40

Closed aufkrawall closed 3 years ago

aufkrawall commented 5 years ago

The game's visuals are severely broken, while it works with wined3d: Screenshot_20190527_163342

Here is an apitrace: https://drive.google.com/open?id=18L9br-WvuI97-N4inOqYtM-8InYMbw7j

axeldavy commented 3 years ago

The code to enable/disable csmt is in device9.c. The variable is csmt_active. If that's easy enough for you, you can try force it to false.

aufkrawall commented 3 years ago

I can't find device9.c either in https://github.com/iXit/Mesa-3D.git nor https://github.com/iXit/wine-nine-standalone .

axeldavy commented 3 years ago

Mesa-3D's src/gallium/frontends/nine/device9.c

aufkrawall commented 3 years ago

Whoops, Github searches files only with the file finder and my locally cloned repo isn't in clear file structure. :scream:

aufkrawall commented 3 years ago

Took quite a while to make it crash, as debug mode made it run in slow motion. The process didn't fully crash, but became unresponsive with a black window content and I waited ten minutes in which nothing was written to the log file anymore.

a_file.7z.zip

axeldavy commented 3 years ago

Thanks for the log.

This log ends up like that:

nine:0x7f32233a0b80:device9:SetRenderState: This=0x7eca06a0 State=7(D3DRS_ZENABLE) Value=00000001
nine:0x7f32233a0b80:device9:SetRenderState: This=0x7eca06a0 State=14(D3DRS_ZWRITEENABLE) Value=00000001
nine:0x7f32233a0b80:device9:SetRenderState: This=0x7eca06a0 State=22(D3DRS_CULLMODE) Value=00000003
nine:0x7f32233a0b80:device9:SetRenderState: This=0x7eca06a0 State=23(D3DRS_ZFUNC) Value=00000004
nine:0x7f32233a0b80:device9:SetSamplerState: This=0x7eca06a0 Sampler=0 Type=ADDRESSU Value=00000001
nine:0x7f32233a0b80:device9:SetSamplerState: This=0x7eca06a0 Sampler=0 Type=ADDRESSV Value=00000001
nine:0x7f32233a0b80:device9:SetSamplerState: This=0x7eca06a0 Sampler=0 Type=ADDRESSW Value=00000001
nine:0x7f32233a0b80:device9:SetSamplerState: This=0x7eca06a0 Sampler=1 Type=MAGFILTER Value=00000001
nine:0x7f32233a0b80:device9:SetSamplerState: This=0x7eca06a0 Sampler=1 Type=MINFILTER Value=00000001
nine:0x7f32233a0b80:texture9:GetLevelDesc: This=0x7f30c37a6080 Level=0 pDesc=0x21f190
nine:0x7f32233a0b80:basetexture9:GetLevelCount: This=0x7f30c37a6080
System page size: 4096
Could not find page for trampoline in +/- 2GB range of function to hook
Error allocating trampoline memory (no memory within +/-2gb? prior failures?)
System page size: 4096
Could not find page for trampoline in +/- 2GB range of function to hook
Error allocating trampoline memory (no memory within +/-2gb? prior failures?)
System page size: 4096
Could not find page for trampoline in +/- 2GB range of function to hook
Error allocating trampoline memory (no memory within +/-2gb? prior failures?)

The part at the bottom is not specific to the app and must be some wine or steam error handler. Given you had an unresponsive black window, maybe the crash occured in a secondary thread and the main thread is stuck on a mutex.

I found no trace of crashing thread in the log. There seems to be a main thread for all the d3d9 calls, except the vertex buffers which seem to be filled by secondary threads.

We can see in the log that sometimes the main thread executes d3d9 calls at the same time as the threads that lock the vertex buffers. Indeed that is possible because while d3d9 functions are thread-safe (mutex protection for almost all calls), some functions (at least for gallium nine) that only returns information about objects (number of surface levels, etc) are not mutex-protected. I went through the list of functions not protected by a mutex, and I found that the PrivateData functions (the ones the app uses a lot) are not mutex-protected for Volume textures, while they should be. I'll push a patch to fix that, but that is quite unlikely to be our bug, as the other threads do not seem to call PrivateData functions.

aufkrawall commented 3 years ago

Thanks for your efforts and commentary that is really illuminating for also non-technical folk like me! :) I wouldn't mind if you found that further inquiries wouldn't be worth the efforts, since we already spent so much time on this particular game, or the apitrace issue doesn't let us pursue it further. Anyhow, if the game worked stably in the end: great! If not, I wouldn't be sad either. :)