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