[PATCH 1/3] wined3d: Don't shift geometry for d3d10/11.
matteo.mystral at gmail.com
Tue Aug 10 07:41:25 CDT 2021
On Tue, Aug 10, 2021 at 2:10 PM Henri Verbeet <hverbeet at gmail.com> wrote:
> 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
> > 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
the main one), they weren't quite proper but I could have another go
> > > 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
More information about the wine-devel