[prev in list] [next in list] [prev in thread] [next in thread]
List: wine-devel
Subject: Re: [PATCH v2 1/4] d3d9/tests: Add Fetch4 tests
From: Stefan_Dösinger <stefandoesinger () gmail ! com>
Date: 2019-01-31 16:42:08
Message-ID: 75CB231F-65DC-41C3-AF3E-5889BFB9CCB6 () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
[Attachment #4 (multipart/alternative)]
Hi,
Those tests look pretty good. One of the tests appears to expect a wrong swizzle \
(evergreen & r500), and the DF16/DF24 tests fail on r500 due to green / blue handling \
that is yet again different from what we've seen elsewhere (XXX1).
I'd say just AND the OFF output color with 0xffff0000 and add a comment that green \
and blue are unreliable.
> Am 31.01.2019 um 02:30 schrieb DarkZeros <mailszeros@gmail.com>:
>
> Hi,
>
> I drafted what I think is a final implementation. This one should pass on all the \
> HW you have. After that, I will clean the patches for submission.
>
> Wine results are set to emulate the results with
> * +0.5 offset (unconditionally)
> * AMD swizzle,
> * 3d textures off,
> * Fetch4 on for all texldXX instructions. (texldp projected).
>
> - Some AMD HW decides not to enable fetch4 on texldl, texldb, texldd.
> But I think it makes more sense to have it on, since some AMD devices have it on, \
> and intel as well.
> - 3D textures are a mess, some enable fetch4, some not, some round the z axis to \
> nearest texels, and some set it to 0. Best and simplest thing to do in my opinion \
> is consider it totally broken, and leave it disabled, like some AMD HW does. Also \
> because is quite hard to implement it in GL.
> In the end I increased the test range to 2, to overcome rounding issues.
>
> PD: Thanks Axel for the comment on the R500 bug. That is really helpful and \
> explains why we are seeing the results we have. In the end, looks like it is true \
> that Intel is following the spec, and is AMD the one that introduced the bug. It is \
> funny though that AMD never amended the spec to clarify what they considered to be \
> the default fetch4 behavior in their devices.
> BR,
> Daniel
>
> El lun., 28 ene. 2019 a las 22:42, Axel Davy (<davyaxel0@gmail.com \
> <mailto:davyaxel0@gmail.com>>) escribió: On 28/01/2019 11:16, Stefan Dösinger \
> wrote:
> > On 27/01/2019 01:04, Axel Davy wrote:
> > > Hi,
> > >
> > > Another info about the 0.5 offset is the following comments in the
> > > r600 gallium driver:
> > > /* Gather4 should follow the same rules as bilinear
> > > filtering, but the hardware
> > > * incorrectly forces nearest filtering if the texture
> > > format is integer.
> > > * The only effect it has on Gather4, which always
> > > returns 4 texels for
> > > * bilinear filtering, is that the final coordinates
> > > are off by 0.5 of
> > > * the texel size.
> > This is interesting, and I guess it explains why I saw this behavior on
> > r500 only when point mag filtering was enabled, but not when linear mag
> > filters were set.
> >
> > Does that also apply for minification filters?
> >
> >
> I'm not able to say, I guess you'd have to ask an AMD dev.
> > > I experimented with 3DMark06, disabling support for D24X8 texturing to
> > > force FETCH4.
> > Do you know any application that uses fetch4 without having an
> > alternative codepath, or insisting on using it on AMD cards even though
> > an alternative codepath like PCF is supported by the application and
> > used on Nvidia cards? For us, the reason to implement fetch4 is because
> > DF24 implies it, and there are games like CS:GO that insist on using
> > DF24 on AMD cards even though it happily uses INTZ on Nvidia cards.
> >
> Well I think it makes sense to use DF24 over INTZ if one doesn't need
> stencil.
>
>
> As for the apps, apparently some old AMD demos are supposed to use it,
> but I haven't tested.
>
>
> Axel
>
> <patches_v3.7z>
[Attachment #7 (multipart/mixed)]
[Attachment #9 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: \
space; line-break: after-white-space;" class="">Hi,<div class=""><br \
class=""></div><div class="">Those tests look pretty good. One of the tests appears \
to expect a wrong swizzle (evergreen & r500), and the DF16/DF24 tests fail on \
r500 due to green / blue handling that is yet again different from what we've seen \
elsewhere (XXX1).</div><div class=""><br class=""></div><div class="">I'd say just \
AND the OFF output color with 0xffff0000 and add a comment that green and blue are \
unreliable.</div><div class=""><br class=""><div></div></div></body></html>
["evergreen.txt" (evergreen.txt)]
visual.c:25232: Driver string: "aticfx32.dll"
visual.c:25233: Description string: "AMD Radeon HD 5700 Series"
visual.c:25236: Device name string: "\\.\DISPLAY1"
visual.c:25238: Driver version 8.17.10.1404
visual.c:15679: Test failed: Test 4,FFP expected color 0x10400000 at (360, 270), got 0x00004010.
visual.c:15679: Test failed: Test 4,texld expected color 0x10400000 at (360, 270), got 0x00004010.
0c5c:visual: 677 tests executed (0 marked as todo, 2 failures), 0 skipped.
[Attachment #11 (unknown)]
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: \
after-white-space;"><head><meta http-equiv="Content-Type" content="text/html; \
charset=us-ascii"></head><div><div \
class="AppleOriginalContents"></div></div></body></html>
["r500.txt" (r500.txt)]
visual.c:25232: Driver string: "atiumdag.dll"
visual.c:25233: Description string: "Radeon X1600 Series "
visual.c:25236: Device name string: "\\.\DISPLAY1"
visual.c:25238: Driver version 8.14.10.647
visual.c:15679: Test failed: Test 4,FFP expected color 0x10400000 at (360, 270), got \
0x00004010. visual.c:15679: Test failed: Test 4,texld expected color 0x10400000 at \
(360, 270), got 0x00004010. visual.c:15847: Test failed: Test OFF Expected color \
0xfffe0000 at (20, 15) for format DF16, got 0xffffffff. visual.c:15847: Test failed: \
Test OFF Expected color 0xff9f0000 at (260, 15) for format DF16, got 0xff9f9f9f. \
visual.c:15847: Test failed: Test OFF Expected color 0xff800000 at (20, 255) for \
format DF16, got 0xff808080. visual.c:15847: Test failed: Test OFF Expected color \
0xff600000 at (260, 135) for format DF16, got 0xff606060. visual.c:15847: Test \
failed: Test OFF Expected color 0xffff0000 at (20, 15) for format DF24, got \
0xffffffff. visual.c:15847: Test failed: Test OFF Expected color 0xff9f0000 at (260, \
15) for format DF24, got 0x9f9f9f9f. visual.c:15847: Test failed: Test OFF Expected \
color 0xff800000 at (20, 255) for format DF24, got 0x80808080. visual.c:15847: Test \
failed: Test OFF Expected color 0xff600000 at (260, 135) for format DF24, got \
0x60606060. 04a0:visual: 517 tests executed (0 marked as todo, 10 failures), 0 \
skipped.
[Attachment #13 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><div class=""><div></div><div><br \
class=""><blockquote type="cite" class=""><div class="">Am 31.01.2019 um 02:30 \
schrieb DarkZeros <<a href="mailto:mailszeros@gmail.com" \
class="">mailszeros@gmail.com</a>>:</div><br \
class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div \
class="">Hi,</div><div class=""><br class=""></div><div class="">I drafted what I \
think is a final implementation. This one should pass on all the HW you \
have.</div><div class="">After that, I will clean the patches for \
submission.</div><div class=""><br class=""></div><div class="">Wine results are set \
to emulate the results with <br class=""></div><div class="">* +0.5 offset \
(unconditionally)<br class=""></div><div class="">* AMD swizzle, <br \
class=""></div><div class="">* 3d textures off, <br class=""></div><div class="">* \
Fetch4 on for all texldXX instructions. (texldp projected).</div><div class=""><br \
class=""></div><div class="">- Some AMD HW decides not to enable fetch4 on texldl, \
texldb, texldd. <br class=""></div><div class=""> But I think it makes more \
sense to have it on, since some AMD devices have it on, and intel as well.</div><div \
class="">- 3D textures are a mess, some enable fetch4, some not, some round the z \
axis to nearest texels, and some set it to 0. <br class=""></div><div class=""> \
Best and simplest thing to do in my opinion is consider it totally broken, and leave \
it disabled, like some AMD HW does.</div><div class=""> Also because is quite \
hard to implement it in GL.<br class=""></div><div class=""><br class=""></div><div \
class="">In the end I increased the test range to 2, to overcome rounding \
issues.</div><div class=""><br class=""></div><div class="">PD: Thanks Axel for the \
comment on the R500 bug. That is really helpful and explains why we are seeing the \
results we have.</div><div class="">In the end, looks like it is true that Intel is \
following the spec, and is AMD the one that introduced the bug.</div><div class="">It \
is funny though that AMD never amended the spec to clarify what they considered to be \
the default fetch4 behavior in their devices.<br class=""></div><div class=""><br \
class=""></div><div class="">BR,</div><div class="">Daniel</div></div><br \
class=""><div class="gmail_quote"><div dir="ltr" class="">El lun., 28 ene. 2019 a las \
22:42, Axel Davy (<<a href="mailto:davyaxel0@gmail.com" \
class="">davyaxel0@gmail.com</a>>) escribió:<br class=""></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On 28/01/2019 11:16, Stefan Dösinger wrote:<br \
class=""> > On 27/01/2019 01:04, Axel Davy wrote:<br class="">
>> Hi,<br class="">
>><br class="">
>> Another info about the 0.5 offset is the following comments in the<br \
class=""> >> r600 gallium driver:<br class="">
>> \
/* Gather4 should follow the same rules as bilinear<br class=""> >> filtering, \
but the hardware<br class=""> >> \
\
* incorrectly forces nearest filtering if the texture<br class=""> >> format is \
integer.<br class=""> >> \
\
* The only effect it has on Gather4, which always<br class=""> >> returns 4 \
texels for<br class=""> >> \
\
* bilinear filtering, is that the final coordinates<br class=""> >> are off by \
0.5 of<br class=""> >> \
\
* the texel size.<br class=""> > This is interesting, and I guess it explains why \
I saw this behavior on<br class=""> > r500 only when point mag filtering was \
enabled, but not when linear mag<br class=""> > filters were set.<br class="">
><br class="">
> Does that also apply for minification filters?<br class="">
><br class="">
><br class="">
I'm not able to say, I guess you'd have to ask an AMD dev.<br class="">
>> I experimented with 3DMark06, disabling support for D24X8 texturing to<br \
class=""> >> force FETCH4.<br class="">
> Do you know any application that uses fetch4 without having an<br class="">
> alternative codepath, or insisting on using it on AMD cards even though<br \
class=""> > an alternative codepath like PCF is supported by the application \
and<br class=""> > used on Nvidia cards? For us, the reason to implement fetch4 is \
because<br class=""> > DF24 implies it, and there are games like CS:GO that insist \
on using<br class=""> > DF24 on AMD cards even though it happily uses INTZ on \
Nvidia cards.<br class=""> ><br class="">
Well I think it makes sense to use DF24 over INTZ if one doesn't need <br class="">
stencil.<br class="">
<br class="">
<br class="">
As for the apps, apparently some old AMD demos are supposed to use it, <br class="">
but I haven't tested.<br class="">
<br class="">
<br class="">
Axel<br class="">
<br class="">
</blockquote></div>
<span id="cid:f_jrjxyhc50"><patches_v3.7z></span></div></blockquote></div><br \
class=""></div></body></html>
["signature.asc" (signature.asc)]
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEQxb0tqoFWyeVMl1sPRO8yFRPGiIFAlxTJWAACgkQPRO8yFRP
GiJDTw/7B4W+EijNJ3kpmXGz8hYmpCMUeKujHBa0+Jw0XNZ7bkQqjskSpBps2x8j
RPFI7q4g2IVmJY2UeEva3lBj1XobUFaj6F/b3V+1Dd+dPs2hUOOpMM5ZeJeE1eyS
jKy9GP3I4e+mLaid0Qw+E3g4CZgTTs+/g//n+OEdpAlSI7yGytvNWe+9VT0eq6f7
skyDIb2Pxc57iux7KBb1T02Ip+FbEGoZhqdoaZOYXzQMEplNf5lt1F8ezY4JJruN
SqCJ2xUJSx4nG5AdHzqhrPD2GArmsDdfwg1TSJHC+ragBZ/qPzftq+rcpEuzh2Vj
B+hQWyPe3AiYkN2h1Cu7AA1u+FOWqUYE9kQ3imH24GOKec0O+fxKrJyGRmN4mwlN
/lnA8JnXmC0u1Qe+d/e5U5JLqHgkTxGlmCHiYJ44o+OJ14W6kNAmDTcoIz9xXL2m
RJIXdkFxYcUi98gNr9PoHPIn+kK3oF49lPslmVHfGhQi3Xu6A5Q9oQavdNPW1i1c
HpkrYtiZg8ZBZgrg+wQxwCiTVRBkhyaqcfVgCe3rcwL3B8NoRu0Ur+O9YwbrTT+T
rdznql46sVUtwGszNhDZR7tJFr9XR+AYR7iEAdWPA/6WTV1EZK5OWMlfWpeyh7nR
cZGj/SC7qWO3g/xL1fwSmTGOXae8w6XkJ6LWOju+jqhBNa8twLE=
=z7Xz
-----END PGP SIGNATURE-----
[Attachment #15 (text/plain)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic