Re: [PATCH 3/5] wined3d: Don't clamp texture lookups in the GLSL fixed function fragment pipe.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-03 13:41, schrieb Henri Verbeet:> It ends up being a performance bottleneck in some cases. This is > particularly visible in the 3DMark03 multi-texture fill-rate test, > in other cases the impact is usually a bit more modest. That's interesting. I'd say that's a good motivation to remove them. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJdGuAAoJEN0/YqbEcdMwapcP/1vrDRVNZiG8OxbpJdKrcAnc UhOBAFGgQynarSu/clL//ln5HPxpttgD5sK75U8vCbuEg+4pJpQb7dfnNRGYekSP n5ntF+I8PfoFZC5bbvA2L4MLO/Svoev8Ti/nCl9/Mi+vpwTulFYHIZiIl26RrLXF LgnfFfx6OpICRss4BA6+UbDM5XdAOnL8I5m2iiRXTafZTeIPdBU0PhGN8lQeReuK ayFWQoTAG0Hq1g3RXy5S2v/tF4nEvAEpvQuw6PHWNniu9lG1wejmqpZmxs886vRX RBtSTD3PzbJY3+w4A0atvBhq6xjP9hzMv5Gl6fUf1SdliEAd2Jsf+xW8gb5eOuGh Ng8uAqtoYAEcKlUoa3yAN+iYA0ECa8q368BQLCZmaOL2vrPdaIWN04pTXAZ7Ybgt 5Nz3pA0iUhjwZo5axvG25EU6eIBVlGt8ajZlRjKxG0Czom+eL3NaG483mIVTD+J7 WTqfe3mH0F4uDt2ZF0WDY3TXAo08JoyiFppn1F3xQXkbMY3DASV8MDba2TMh2dBc rzQSrX98lA4gMG3geVgJeGMiHXNVnkZrOX/lOKKtOM60ARRlm3a6n2HDcuDhKMfK TfE2jx0ofRrZ/MysQl4zY2mZUFUhE5xkvUjwZPR4WXOcMeWu2uLT66Zzn6Fb8w4i OvpGr6YLpMRI9IvPSy4H =yVNO -END PGP SIGNATURE-
Re: [PATCH 3/5] wined3d: Don't clamp texture lookups in the GLSL fixed function fragment pipe.
On 3 September 2013 13:31, Stefan Dösinger wrote: > The idea behind the clamps is that the fixed function pipeline is > generally limited to the [0.0;1.0] range. bbf313e7 added a test for > that, and there was e.g. 14706 (which doesn't contain much info tbh). > Yes, but that's for stage operations, where it kind of makes sense, and on most hardware is just an instruction modifier. For texture sampling operations it's more questionable, and the driver can't necessarily just use an instruction modifier. > Personally I'd keep the clamps in unless a test says otherwise or > there's another compelling reason to remove them. But since it is > quite unlikely to matter that's not a strong opinion. The ideal > solution is of course to write a test. > It ends up being a performance bottleneck in some cases. This is particularly visible in the 3DMark03 multi-texture fill-rate test, in other cases the impact is usually a bit more modest.
Re: [PATCH 3/5] wined3d: Don't clamp texture lookups in the GLSL fixed function fragment pipe.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-09-03 09:47, schrieb Henri Verbeet: > This originally came from the ARB fragment program implementation, > but I don't see a justification for clamping there either. For the > texture formats typically used with the fixed function pipe > clamping wouldn't make a difference, and we don't have any tests > that say we need to clamp. The idea behind the clamps is that the fixed function pipeline is generally limited to the [0.0;1.0] range. bbf313e7 added a test for that, and there was e.g. 14706 (which doesn't contain much info tbh). Personally I'd keep the clamps in unless a test says otherwise or there's another compelling reason to remove them. But since it is quite unlikely to matter that's not a strong opinion. The ideal solution is of course to write a test. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJciCAAoJEN0/YqbEcdMwQ2gP/Ayrnyv1b7VmviOCBLdKpW3P YjEgLSFtaiEMGjJ6DD3iTLTRBaMOWZIryKyXdE5QLecKx35xuk6GbC+OAXgCCZfU a558nJwymMtMpiU9Wa2nuUXF4p+KuC8CHkCgfOGF1D4wDZcQQxfEcvKcwAGPaZwV PWiKKI8SWO69XlawZHOLyWz97gghYpLrHIexOxbCVXGMXee7pqAQTSz2oRVppHot 39T2qbFo21qtoyK7sgqMgnRko52eiJGSBVHCfcfhhMPh+mksQvPoZDcdK/KSAl6r K5Py0kbVjBDjE9I6uCGO9+bt6a6RrJpC/6JGIOypDvicnjd/7X4LK8SYfGv3Cvr6 qejlsAouxrQgdYARrdjnoR4IEK8WviBzOZDnvxOS8dlEsJxjMjxIScnemdNacNKO QY3DJ/GmfnsnOXnrrvADKkLvCkeIUCE5v6U9Kv+S9GsMgNeJs1IEHzQpROBmt/iO ukUH+aOe4JReH1mtynrX+GsjwZkDPzatx48SxOOopWW5akiCbEsJNFirR4m1St9E 5+iOCkGQkjWVz95XgZt3VRpUBxx12JHsX1/UscBmprvkutmbUOYvRIpgqdTyZknD dW4x79KWQ6YUu3k8Lho8EfChR8rzPoDeaHwclY/WrwE+yuHugk+z0dv/gclC3eiL HAQ0T8GuuElJvdPfgE3F =8XAf -END PGP SIGNATURE-
