[PATCH 1/3] wined3d: Don't shift geometry for d3d10/11.

[Henri Verbeet]

On Tue, 10 Aug 2021 at 09:22, Stefan Dösinger <stefan at 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 at 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.

> > 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.)