On Tue, Aug 10, 2021 at 2:10 PM Henri Verbeet hverbeet@gmail.com wrote:
On Tue, 10 Aug 2021 at 09:22, Stefan Dösinger stefan@codeweavers.com wrote:
Am Montag, 9. August 2021, 18:47:18 EAT schrieb Henri Verbeet:
On Sat, 7 Aug 2021 at 09:00, Stefan Dösinger stefan@codeweavers.com wrote:
Afaics we have no test that tests if we are doing the right thing in d3d9 and earlier. I'll add one, that should hopefully give some clues if the 63.0/128.0 is still correct on today's GPUs or if we need a flat 1.0/2.0 on some. If it's the former - and I am not aware of any d3d <= 9 games that have any pixel boundary issues right now - there might be some d3d9/d3d10 difference.
Yeah, we don't have existing tests for this.
Actually, d3d9's test_viewport is sensitive enough that it starts failing on Radeon-MacOS when I change the d3d9 offset to 1.0 (64.0 / 64.0, half a pixel thanks to the -1 to 1 NDC). On Linux with the same HW 1.0 is ok. Same things apply to the clip control version of viewport_miscpart.
So far all HW/OS combinations I tested pass the d3d9 test with the current 63/64 or 63/128 in the CC case, but need a flat 0.0 shift for d3d11's test (and World of Tanks). However, I now have two differently behaving drivers to try to detect some behavior difference. Not sure though if the difference matters for the bug I am trying to solve.
(And note that originally part of the issue was that the filling convention ended up being different for onscreen and offscreen render targets due to the y-flip; "AlwaysOffscreen" got rid of at least that part of the issue.)
Why did we use the not-quite-0.5-pixels shift in the X direction? We don't flip that one.
For the "left" part of "top-left"; we don't flip the x-axis, but we still want to make sure we get the convention Direct3D applications expect.
I remember the bug we tried to solve was Spore generating broken maps. It used to work on dx9 cards, broken on dx10 ones, then we fixed dx10 but broke dx9, and the 63/64 construct made both happy. I think we blamed it on some drivers implicitly rendering upside down in FBOs (and thus reverting our flip) while others did not do that. Sadly d3d9's visual.c readback is broken with backbuffer rendering, so I couldn't (yet) check if the y-flip still matters.
I think Everquest was also affected at some point.
Yeah, it was Everquest 2 the "trigger" for the AlwaysOffscreen setting.
WRT readback with backbuffer ORM, I have some patches around. I sent them a while back (https://www.winehq.org/pipermail/wine-devel/2021-March/182929.html the main one), they weren't quite proper but I could have another go at it.
I still have a NVIDIA Tesla I would be able to test this on, although I don't remember for sure whether it was originally affected by this issue. Perhaps others like e.g. Matteo would also be able to help with testing.
I have one of those available too, and at least Windows and MacOS El Capitan. Not sure about the state of my Linux system on it, presumably I'll struggle with the EOL driver. What I don't have right now is a d3d9 or earlier GPU to compare to - my GeForce 7 died a while ago and my Radeon X1600 and Radeon 9000 Mobility are in Vienna.
I'm running mine on Nouveau, for what it's worth. (Apple hardware, so it needs hacks for GPU switching, but it works.)
In theory I could run tests on a GeForce 4 Go (which is basically a GeForce 2 MX, fixed function only) on XP and Linux. Assuming it still works...