Emulator

Also, I update my graphics drivers weekly, always a clean install.

I also have a GeForce GTX 960 with 2 GB Video Memory and I'm running Windows 10 x64 as well (however, different CPU).
So I was looking through the game INIs distributed with Dolphin whether any of my games was set up to enforce Real XFB.

The only one I could find was RH8P4F Tomb Raider Underworld.

The distributed RH8.ini says:
EmulationIssues = Needs real Xfb for the videos to display.

And it enforces Real XFB:

[Video_Settings]
UseXFB = True
UseRealXFB = True


However, I didn't find any issue with the Intro video. It played fine. No blackness at all.

So either the distributed game INI is inaccurate and the game doesn't actually need real XFB
or there's something different on my system that causes it to work fine here.

Possible things that come to mind are:

• CPU i7-4790S
• Dual Monitor Setup (playing the game on the primary monitor)
• Using real full screen (not borderless window mode)
• When installing the nVidia GFX driver I always make sure I don't install the two 3D components it offers

The issue I have with Real XFB is that it looks really crappy. What I mean by that is that instead of either blocky pixels or blurry pixels due to upscaling (nearest pixel or interpolation, respectively) as I would expect, I get anomalies per upscaled pixel that show up as extra or missing real pixels and can go as far as displaying extra very thin lines that shouldn't be there.

The extra lines at the bottom are probably due to the lack interlacing support.

The reason it looks blocky/filtered is because RealXFB can't be upscaled to higher resolutions, and also has some color stuff in how it processes things. That's just part of RealXFB and isn't really fixable.

I didn't mean extra lines at the bottom. The lines I was talking about are part of the upscaled pixel anomalies.

Anyway. Apart from that it works for me. I'm ready to try stuff in terms of Dolphin configuration changes or using different Dolphin versions, in order to try to break it on my system.

Yes, I don't believe what you describe is an issue at all. Some games used to need Real XFB but due to improvements in accuracy don't anymore. The behavior I described happen in every game.

I have uploaded a video demonstrating this bug in action: https://youtu.be/9FVmfmt0F8I

Interesting note: I couldn't get OBS to capture Vulkan in dolphin at all. Maybe some kind of third party program is interfering with Dolphin's ability to do CPU <-> GPU communication. Do games like Super Mario Galaxy with the starbits work?

The thing is, I have no idea of what it could be. Tommorrow I'll post my full installed programs list (which is not that long) on the forums so we can dissect it.

Yeah seems like OBS doesn't like something Dolphin does when initializing video. Did you use a Display Capture or Game Capture scene? The Game Capture one didn't work for me.

Also one more question. If this is indeed some software messing with Dolphin, is it Dolphin's responsibility to fix it?
Because at this point I'm just doing this for the sake of debbuging Dolphin. I want to get to the bottom of this, but not because I really need Real XFB that much xD

PS: I'll redump Mario Galaxy tommorrow, I had to delete some stuff a while back during a system refresh and never got it back. Why? Do the starbits need Real XFB?

OBS Couldn't capture Dolphin on Monitor 2, only on Monitor 1. I wonder if this is a multi-monitor issue too...

I find the discolored intro video particularly interesting. It's like there's some color preset instead of black or some colored overlay. There's still white where in the correctly colored video there is white, but where the correctly colored video has black, the discolored one has some kind of purple. It's not even fully saturated magenta (#FF00FF). The red component seems to be roughly half intensity.

Does OBS use a purple chroma key for overlays or something like that?

Do you use any non-standard display mode for your desktop? Like 16 bit depth instead of 32? (The NVidia settings don't allow me to use 16 bit modes for the Desktop, so I can't try here.)

Well, I only use one monitor.
What bugs the hell out of me now is that it isn't just a plain black like no output like I had thought. I mean, did you see that weird purple on the videos? Something, whatever it is, is interferring with XFB emulation on some machines, while managing not to affect anything else!

Nope, my video mode is a standard 60hz 32bit 1600x900
Note that I get that behavior when not using OBS as well

Well, I was implying that OBS might have installed some kind of driver or something which might interfere regardless of you recording or not. I wouldn't know. Just making unlikely suggestions ;)

No problem, I encourage it lol, I'm almost out of ideas anyway. I just installed OBS to record the video though, it was happening before. This is a relatively fresh Windows installation.. Only driver stuff intalled is NVIDIA and Razer stuff.

Hey,where does the Vulkan implementation used by Dolphin to render come from? NVIDIA's drivers I assume? I just noticed I have a Vulkan API on my list of installed Software. I never installed it, so I'm guessing it came with the graphics drivers?

Yes, it comes with the NVidia driver.

I'm considering setting up a Virtual machine and fresh installing W10 on it. I'll see what I can do tommorrow, it's already 1:30am here xP

We're getting closer to narrowing it down to a cause. I'm also pretty sure this is related to https://bugs.dolphin-emu.org/issues/10224

Refer to https://forums.dolphin-emu.org/Thread-real-xfb-broken-on-vulkan-on-some-systems?pid=444047#pid444047

As a noob, I think someone should compare OpenGL, Dx11 and Dx12 RealXFB code with the Vulkan one, in order to understand what are the differences that cause the Vulkan plugin to fail...

The problem is this doesn't affect everyone. As of now, all we know is that some of Vulkan's features are not rendering correctly for everyone. We could try and find what it is using TDD, I reckon. It's something(s) that is used in Real XFB and probably also the Vertex Rounding hack.

This isn't NVIDIA only, we had someone on a Radeon report the issue now too. We attempted to debug it but were unable to figure out what was going on.

I'm running out of ideas as well. I am open to try anything if you want though

Could you try with this PR: https://github.com/dolphin-emu/dolphin/pull/5477
Download link: https://dl.dolphin-emu.org/prs/pr-5477-dolphin-latest-x64.7z

I found two errors in XFB uploads that could potentially be an issue (should be fixed by the PR), but the AMD user with the issue reported that it didn't make any difference.

I've tried every config of hardware I can think of and haven't been able to reproduce the error. Tried GPUs that are the same as people with the issue, and it's fine for me. I'm out of ideas as to what the common denominator is here, but I'm sure there is one somewhere.

I doubt it's vertex rounding, that has nothing to do with XFB uploads, as it's still broken even when the EFB/normal rendering isn't involved.

No deal, same behaviour across all test cases.
I even deleted my Dolphin user folder and started from scratch. I'm reinstalling my graphics driver once again, I wanna test something.

Yes, as I have the same GPU as Runo and don't have the issue here, the GPU (at least alone) can't be the culprit.

But what's different on my system is the CPU.
While I admit it sounds unlikely, it's still technically possible that it could make a difference.

There are even very subtle differences between AMD and Intel CPUs that could potentially affect user space in rare edge cases. According to what I read, the BSF and BSR instructions have an edge case with different semantics as well as there being a mode where AMD can save/restore a reduced version of the floating point state while Intel cannot: https://stackoverflow.com/a/29834370/794539

But more importantly the graphics driver could be using different code paths depending on CPU architecture, a specific range of CPUs or supported processor features, respectively.

ok perhaps this helps?

so i'm having the identical BUT opposite issue in Rogue Squadron with on Win10 / GTX970

i.e. i enable Real XFB or else i get the black screen...

No, Rogue Squadron II and III needing XFB is normal. That's also why it's enabled in the game INI (both in GSW.ini and GLR.ini).

Personally, I would avoid those 2 games as a reference, as they use all kinds of tricks that most other games do not.

Oh, wait, you're saying it only works for you with real XFB enabled as opposed to virtual XFB, right? (It works with both for me.)

Then disregard my last comment.

Yeah none of us can reproduce this.

Can you tell us if you run anything like overlays, game capture recorders (Like OBS), or anything at all that would hook into the video output?

So stuff like

Steam overlay
Win10 xbox game capture / mode / on demand (This one might very well be it, its on by default)
MSI afterburner overlay
FRAPS
OBS
nvidia geforce experience overlay / recording

Also, if you run any anti-virus, what is it?

If it's some sort of software interfering, then why only with the Vulkan backend, while OGL, DX11 and 12 work perfectly?

Under installed programs having only Vulkan runtime libraries 1.0.42.1 should be enough or there should be some other sort of library installed (like an older Vulkan version or legacy one)?

Yes, the only thing that has the word Vulkan in it in the installed programs list is "Vulkan Run Time Libraries 1.0.42.1".
Surely the actual graphics driver ("NVIDIA Graphics Driver 382.33" for me) has parts for Vulkan in it, too (the libraries are likely just presenting the interface to application programs), but everyone will have their actual graphics driver installed, I assume.

As to your question as to why only Vulkan, well, we don't know. If we did, we'd likely be closer to solving this mystery. Vulkan is different from both DirectX and OpenGL, otherwise it would be called DirectX or OpenGL, respectively (well, it's supposed to be an evolution of OpenGL, but it's still different).

Other parts of your system (i. e. Software) have to talk to each of the 3 in a different way. So there's the chance for a mistake to mess one of them up but not the other two. Also, all 3 do things in different ways and likely make use some different resources, different parts of the operating system or different features of the graphics card or driver. So if anything messes with things only one of the 3 uses, it will affect only one of them.

I've read that some users got a black screen with the new game Doom using Vulkan, but it was caused by a SLI configuration and I have only one video-card...

Finally on my system Real XFB works on Vulkan like others plugins and since it happened between 5.0-4837 and 5.0-4869 I think Ubershaders 2.0 fixed the problem.
Thanks.

Unfortunately the issue is no more fixed! someone broke it again :-( :-( :-(
5.0-5320 works
5.0-5426 doesn't work (also PR-5343 doesn't work)
Now I'll try to find who/what revision is responsible of that

Ok, found out that is Dolphin 5.0-5419 (Drop VK_NV_glsl extension support) https://github.com/dolphin-emu/dolphin/pull/6012 that breaks again real XFB on Vulkan!

Interesting. That suggests that there is an issue with NV's SPIR-V frontend, or glslang. I also still can't reproduce this issue, so it makes it very difficult to figure out exactly what in the shader(s) is causing the problem.

We can't bring that extension back because it breaks ubershaders (dynamic sampler indexing, specifically) on the 385.41+ driver, so until NV fixes their driver it will stay "broken".

Does that confirm it's an NVidia only issue?

Could you please try with PR 6038? I'm wondering if this is a glslang issue.

Link: https://github.com/dolphin-emu/dolphin/pull/6038
Windows build: https://dl.dolphin-emu.org/prs/pr-6038-dolphin-latest-x64.7z

in PR6038 real XFB still doesn't work, also I can't reproduce the Ubershader "385.41 Driver bug" using older Dolphin versions...it should be that all games are affected or only some?

Hmm okay, I'm out of ideas for now then. It's really difficult to debug this when I can't reproduce it on any of the systems I've tried it on (Kepler, Maxwell v2, Pascal, on various CPUs).

385.41 definitely breaks ubershaders on my system. Some very simple games that only use a single texture may not be affected, but anything that uses more than one texture should be broken (that is, using versions before VK_NV_glsl was reverted).

I can't see anything wrong with older versions of Dolphin: for example Super Mario Galaxy works perfectly here using Dolphin 5.0-5417 and Drivers 385.41 (Vulkan Ubershaders on Hybrid)...maybe Nvidia uploaded a new corrected version of the Driver?

markwest76 wrote:

I can't see anything wrong with older versions of Dolphin: for example Super Mario Galaxy works perfectly here using Dolphin 5.0-5417 and Drivers 385.41 (Vulkan Ubershaders on Hybrid)...maybe Nvidia uploaded a new corrected version of the Driver?

Try Exclusive mode. It's possible Hybrid is masking the bug.

With Exclusive mode the menu hand pointer in SMG turns into a black square, but in game textures are perfect, and also RE videos (mentioned in the issue) here work perfectly

markwest76 wrote:

With Exclusive mode the menu hand pointer in SMG turns into a black square, but in game textures are perfect, and also RE videos (mentioned in the issue) here work perfectly

If you try other games you'll probably find there is more significant breakage. See https://bugs.dolphin-emu.org/issues/10508

I've pushed another fix for PR 6038, which caused all shaders to break on my system. Please let me know if that changes anything.

Tried the new PR6038: real XFB still don't work, but everything else works perfectly (at least I can't see anything wrong)

I think I'm at the point where I can say your computer is broken ;)

Maybe, who knows, but in fact I think that there are many users that have this problem and don't even know about it: there are very few games that need real XFB and also not everyone uses the Vulkan backend...if it wasn't for Batman Vengeance I would have never noticed this problem...

I second that. I went so far as to fresh install Windows 10 in a second partition of my PC, and the problem occurs for me. I have tried every vulkan benchmark and diagnostic tool I could find, nothing gave me any clues as to what could be. It's a very real problem, check the video above I posted here some months ago.

Don't take me seriously when I go to "your computer is broken"

That's just something I say when I have no idea what's going on :P It could still be a hardware issue with various graphics cards.

I can't do much else about this for now, then. If NV fixes the regression in their drivers, we can re-enable the GLSL extension support, but it seems more likely this is a driver bug in the first place.

I'm not saying the issue doesn't exist, but it's very difficult to debug when none of us can reproduce it, aside from throwing random ideas out there.

And is there a clue why on some system the Driver uses that extension and others not? Is there an option in the Nvidia control panel to manage it?

markwest76 wrote:

And is there a clue why on some system the Driver uses that extension and others not? Is there an option in the Nvidia control panel to manage it?

It's application-controlled, not driver-controlled. The extension replaces our normal glslang->SPIR-V path with NV's frontend.

We used it on all NV systems prior to the revert commit, because using NV's frontend resulted in slightly faster ubershaders. However, the newer driver has reduced the performance difference significantly. Also, it just plain doesn't work, as dynamic sampler indexing is broken with the extension as of 385.41.

Some users have reported that "Hybrid XFB" potentially fixes works-around the issue.

Link: https://github.com/dolphin-emu/dolphin/pull/5498
Windows build: https://dl.dolphin-emu.org/prs/pr-5498-dolphin-latest-x64.7z

Yes, I confirm that PR5498 fixes the issue

This PR breaks the Tales of Symphonia (GC) at least for me. Does this happen to anyone else?

Using Opengl:

Invalid read from 0x01fe02056, PC = 0x800f7e98

Invalid read from 0x01fe0202, PC = 0x800f7e98

Using Vulkan:

Source rect is too large for copyrectanglefromtexture. Ignore and continue?

Yes: Invalid read from 0x01fe0206, PC = 0x800f7e98

Invalid read from 0x01fe0202, PC = 0x800f7e98

Yup, can confirm that PR5498 both fixes the issue with XFB and breaks Tales of Symphonia.

Tales of Symphonia is working fine for me?