Skyrim - Black screen when FSAA enabled

[TRPB]

When using wine-pba and running skyrim (original steam version, not the DX11 special edition) it works fantastically well (Performance is much better than wine or wine-staging) but if FSAA is enabled the menus and loading screen works but once the game loads the screen is black with just the HUD. Selecting 2/4/8 samples or FXAA makes no difference.

I have tried the same installation/settings with both vanilla wine and wine-staging which both work with FSAA but run a lot slower.

OS: ArchLinux
GPU: nvidia 980ti with nvidia driver 396

[Goldpaw]

I believe that the FSAA bug is in wine-staging, or possibly even wine (haven't tested). In some games you just get a white or black screen with it enabled. World of Warcraft and Path of Exile amongst them, this I know from my own testing. I've tried with no PBA, just regular wine-staging.

Meaning I don't think this bug or problem originates here. Wine doesn't have hardware support for all of D3D11, since not all of D3D11 can be reproduced with OpenGL at all. So the driver support isn't there. And what wine does to compensate, is to use the CPU for a lot of the D3D11 calls. Which doesn't always work as intended. And hardly ever with a good framerate.

Or to put it another way, for new D3D11 titles, I think you might have better luck trying out dxvk. It's possible to have both installed. I'm running Arch Linux too, and I'm using PBA for games using calls to DX9 and DX10, but I've made wine prefixes with dxvk installed for newer games using DX11 exclusively. Dxvk is a layer above the wine installation, so it does not replace any of the original wine files. It only changes prefixes, not wine installs. :)

[TRPB]

Well I tried skyrim with wine and wine-staging, both work fine with FSAA. It's only wine-pba which has the issue so I think the issue is here.

I've tried DXVK but get ~30-40fps in SkyrimSE. With wine-pba and Skyrim (original DX9) I get 40-60fps.

[Goldpaw]

Yeah... I don't get it. Or sort of.

You saying that with no FSAA you get a far higher framerate in PBA, but with FSAA you get low framerate in any version, but it's only with PBA the screen completely blacks out, yes?

@FireRat this might be something that your texture environment variables can help with? :/

[TRPB]

It's only with PBA+FSAA that I get a black screen.

PBA (without FSAA) gives the best performance when doing a fair test with no AA in vanilla wine/staging/DXVK.

[Goldpaw]

Not that I'm even going to pretend to understand the theory behind it, but can it be that wine sends the 3D data through a different buffer than the ones PBA is using when FSAA is active? Causing the black/white/default screens?

And if so, is there some way we can create a buffer state for FSAA too? :/

[ghost]

https://en.m.wikipedia.org/wiki/Spatial_anti-aliasing
scroll down to
Super sampling / full-scene anti-aliasing

FSAA will use more gpu, vram, and hurt fps
upping the heap sizes may fix blackscreen issue, but may lead to performance drop

just play around with it and see what works best for you
https://github.com/Firerat/wine-pba
new(ish) https://github.com/Firerat/wine-staging

looks like 2xFSAA would use 4x the vram
so to have effective PBA defaults ( geo @ 512 and cb @ 128 ) you would need geo @ 2048 and cb @ 512
have fun turning the pba knobs ;/

[TRPB]

Thanks, yes. using 4x the defaults for both worked.

Having played around with it more, pba has higher average FPS but larger dips. DXVK has a far more consistent framerate.

[SveSop]

@FireRat @TomBZombie I did a quick test with 8xAA on Unigine Valley doitsujin/dxvk#67 (comment) and initially PBA crashed due to not having enough heap space. Using Firerat patches i could up that and get it working...

However, performance of PBA vs regular wine was virtually the same (after winehq devs fixed something of late). So it does not seem as there is anything to be gained by PBA patches when you pass a certain point tho? Any ideas? Running with 0xAA with the same GEO/CB heapsizes gives worse performance than the defaults of 512/128. Some slowdown when too large heapsizes?

Running GTX970 w/4GB vram, so should not be a ram issue either... As Valley did not consume more than around 1.2'ish GB.

[ghost]

yeah, @SveSop
I'm not certain I understand the code well enough, but I suspect that larger heap sizes results in a greater 'housekeeping' overhead.
The trick would be to have enough heap to keep most of what you want mapped without being so large that it negates any benefit.

I did intend to learn C and add some kind of balloon feature so that heap could be extended when a persistent demand is seen.
But I never got round to it.