Pcsx2: Blood Will Tell (NTSC-U) - Flickering/Floating garbage while in black & white mode.

[piau9000]

PCSX2 version: 1.5.0 build 1581.
PCSX2 options: Tried all combinations of Clamp and Round. Also tried Software/Hardware mode and OpenGL/DirectX. Other settings are default.
Plugins used: All default plugins.
How to reproduce the issue: Right at the beggining, in the tutorial. Software mode.
Last known version to work: Haven't tested.
PC specifications: Intel Core I5 4690, EVGA Geforce GTX 750Ti, Windows 7 64 Bit.

Description of the issue: In the beggining of the game, the screen will be black and white. This is normal. What is not normal is the flickering/garbage all over the screen. It seems that some polygons/textures are being drawn in the wrong place and keep aprearing/disapearing on the screen.
At first I thought it was normal but, after chekcing the real PS2, it seems to be a bug.
Screenshot:

Here is a gsdump: http://www5.zippyshare.com/v/2ECiJ1d6/file.html

When you get your eye, and it turns the black and white effect off, the flickering is gone.
This means that the problem is with the post processing itself.

[piau9000]

EDIT: If you start the game in software and then change to hardware mode while in game (by pressing F9) it will turn to black.
But if you press ESC and then change to hardware mode (or if you start in hardware mode) it will work and the flickering is gone. Then, if you press F9, it will go to software and the flickering will return.
So it seems to be something with software mode.
Here's a gsdump while it is working: http://www67.zippyshare.com/v/j4MtB3mI/file.html

[piau9000]

It happens on software mode so I don't think it's a hardware mode problem.
Like I said in my second post if you start the game in hardware mode it works fine. It's software that have the weird corruption.
If you start in software and changes to hardware without pausing the emulator the screen turns to black. But this can be a complety different bug as far as I now.

[FlatOutPS2]

I don't see the bug in either dump. It seems fine in both Hardware and Software modes.

[piau9000]

That's weird.
Everything in my PC is fine. The iso integrity is also fine. The emulator too.
Just reinstalled the video driver to be sure but the problems persists.
Tried with different version of PCSX2 and even on a different machine. The same thing happens.
This is the only game that have this problem, and it's happening in a part that have a postprocessing effect so I'm pretty sure something is making it run wrong.

Maybe it's something that don't show on the gsdump.

[piau9000]

I can try to record some videos. I never did it before so I don't know what the best program is.
I tried camstudio but the results are very bad.

[lightningterror]

Is the issue still present on the latest version ?

[piau9000]

Yes. I tested build 1703 and still happens.
The commit that you mentioned fixed a problem in hardware mode.
Like I said this bug is in software mode. Hardware is fine.

[lightningterror]

Hmm I changed my mind and deleted the comment since I thought it's not relevant to this issue since the build numbers are not the same.

But here it is just in case someone needs some info just in case it's related.
report https://github.com/PCSX2/pcsx2/issues/1674
fix https://github.com/PCSX2/pcsx2/commit/211c7745de1bc260f10658e5ef49a06a0b52e8d3

I also can't reproduce the issue which is odd.

[willkuer]

Maybe OP can try to reproduce it with the gs replayer? Then you know if it is an error in his system or if the gsreplayer just doesn't show it.

[piau9000]

Update: I have a I5 so I enabled 3 rendering threads. It works with all the games that I have, but in this one it causes this glitch. If I set it to 0 rendering threads the bug is fixed. Very weird.
Can you guys try different rendering threads to see if it happens to you too?

Here's a video that I made.
https://www.youtube.com/watch?v=Mb-lTm8C520

EDIT: Can confirm. If rendering threads are set to 0 or 2 (1 is debug) is works perfectly fine. If I set it to 3 the artifacts began to pop in.
The mistery deepens.

[FlatOutPS2]

Update: I have a I5 so I enabled 3 rendering threads. It works with all the games that I have, but in this one it causes this glitch. If I set it to 0 rendering threads the bug is fixed.

I tried that when I first tested the dump, I didn't notice the bug with that setting either. I'll check again to be sure. There are more games that have glitches with SW renderering threads. Did you try just using 2 rendering threads?

[piau9000]

Yes. With 2 it works fine too. Only 3 seems to be sketchy.
But only in this game. Others works fine in 3.

[FlatOutPS2]

That's a relief. As far as I know the other rendering thread issues also only occur from 3 rendering threads and up. That should make it easier to track down.

[lightningterror]

This is the first time I see rendering threads causing an issue on software mode.

[gregory38]

Hum it could be the recent GS threads updates

[lightningterror]

Hmm , which commit is that?

[turtleli]

It's not the recent update - I can reproduce the issue using GSdx from both master and 1.4.0. OS and ISA don't seem to matter. FWIW if I decrease extrathreads_height from the default of 4 to 1 or 2 the flickering seems to disappear (at least on my system using the first dump).

EDIT: Second dump also shows the issue.

[gregory38]

Maybe I did something bad when I ported the code to std:: atomic. Or it misses a sync point.

[FlatOutPS2]

Issue persists even in 1.0.0. build(didn't check older builds), so it's not a recent regression. ;)

[gregory38]

There's also a glitch on gt4. Both games use the channel effect. It could be related, It need to be tested with multiple threads.

[FlatOutPS2]

There's also a glitch on gt4

Which one? :D

[gregory38]

There is a purple glitch in the top when you start a race (vague memories).

[FlatOutPS2]

There is a purple glitch in the top when you start a race (vague memories).

Yes, but that's not related to rendering threads.

[gregory38]

Extrathreads_height = 8 (<=> 256 pixel band) helps to trigger the isssue. In this case all glitches are located to the bottom of the screen, upper part is good. I'm pretty sure it is related to grey scale effect.

Here an overview of the effect with the expected sync.

Frame is renderer in 0x700
Sync 0x700 (RT will be used as input)

Foreach page of frame
    Sync 0x2800 (not the first iteration, texture will be used as a RT)
    Copy page from 0x700+offset to 0x2800

    Sync 0x2800 (RT will be used as input)
    Render Effect line1 from 0x2800 to 0x700
    Render Effect line2 from 0x2800 to 0x700
    Render Effect line3 from 0x2800 to 0x700
    Render Effect line4 from 0x2800 to 0x700
    Render Effect line5 from 0x2800 to 0x700

The case RT will be used as input is rather standard. So the bad sync could be the other one. Which can be translated too.

• thread 0 will copy data from 0x700 to 0x2800
  
  
  
  • the drawing is always located on the top of the buffer. So it always be thread 0
  
  
• thread N will copy data from 0x2800 to 0x700.
  
  
  
  • upper part will be thread 0 (which is good, because serialized?)
  
  
  • bottom part will be thread 1 (which is bad, because in concurrence of the thread 0 copy?)
  
  

[gregory38]

The only texture sync that have found are

• related to EE write (not the case here)
• CheckSourcePages
  
  
  
  • check if the texture is not part of a target currently in use
  
  
• CheckTargetPages
  
  
  
  • check if there is an overlap between this and previous targets
  
  
  • but don't check if current area is an old texture.
  
  

[gregory38]

I'm quite happy. I think I have found the issue :grinning: Please test PR #1855

[piau9000]

Tested the last build and it seems to be fixed. :+1:
I've only tested with 3 threads tho (the max that my CPU can handle).

[gregory38]

Actually the trick to reproduce the bug is to slow down some threads. Thread 0 and MTGS must execute faster than others threads.

[piau9000]

So I have to slow down thread 2 and 3?

[gregory38]

@piau9000 You need asynchornous thread. Anyway I'm rather confident so I merged the code :+1: