On 9/12/18 11:44 PM, Roland Scheidegger wrote:
Am 12.09.2018 um 23:43 schrieb Roland Scheidegger:
I small precision I want to add: This is not the only place clamping
makes a difference.
Indeed else MUL_ZERO_WINS would be safe to use and remove all the clamping.
The rasterizers can produce
Am 12.09.2018 um 23:43 schrieb Roland Scheidegger:
> Am 12.09.2018 um 08:31 schrieb Axel Davy:
>> On 9/12/18 8:17 AM, Axel Davy wrote:
>>>
>>> The goal is to catch inf and -inf and replace them by FLT_MAX and
>>> -FLT_MAX.
>>>
>>> Without, the NaN would appear when doing mul or mad.
> Ah I somehow
Am 12.09.2018 um 08:31 schrieb Axel Davy:
> On 9/12/18 8:17 AM, Axel Davy wrote:
>>
>> The goal is to catch inf and -inf and replace them by FLT_MAX and
>> -FLT_MAX.
>>
>> Without, the NaN would appear when doing mul or mad.
Ah I somehow completely missed this (but indeed this code will replace
On 9/9/18 9:40 PM, Ilia Mirkin wrote:
On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy wrote:
Tests showed Intel on windows does always clamp
RCP, RSQ and LOG (thus preventing inf/nan generation),
for all shader versions (some vendor behaviours vary
with shader versions).
By the way, this happens
On 9/12/18 8:17 AM, Axel Davy wrote:
The goal is to catch inf and -inf and replace them by FLT_MAX and
-FLT_MAX.
Without, the NaN would appear when doing mul or mad.
Axel
I small precision I want to add: This is not the only place clamping
makes a difference.
Indeed else MUL_ZERO_WINS
On 9/11/18 11:28 PM, Roland Scheidegger wrote:
Am 09.09.2018 um 21:19 schrieb Axel Davy:
Tests done on several devices of all 3 vendors and
of different generations showed that there are several
ways of handling infs and NaN for d3d9.
Tests showed Intel on windows does always clamp
RCP, RSQ
Am 09.09.2018 um 21:19 schrieb Axel Davy:
> Tests done on several devices of all 3 vendors and
> of different generations showed that there are several
> ways of handling infs and NaN for d3d9.
>
> Tests showed Intel on windows does always clamp
> RCP, RSQ and LOG (thus preventing inf/nan
On 9/9/18 9:40 PM, Ilia Mirkin wrote:
On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy wrote:
Tests showed Intel on windows does always clamp
RCP, RSQ and LOG (thus preventing inf/nan generation),
for all shader versions (some vendor behaviours vary
with shader versions).
By the way, this happens
On 9/9/18 9:35 PM, Ilia Mirkin wrote:
On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy wrote:
For now clamp for all drivers. An ulterior optimization
would be to avoid clamping for drivers with MUL_ZERO_WINS
for the specific shader versions where NV or AMD don't
clamp.
Too bad. The whole point of
On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy wrote:
> Tests showed Intel on windows does always clamp
> RCP, RSQ and LOG (thus preventing inf/nan generation),
> for all shader versions (some vendor behaviours vary
> with shader versions).
By the way, this happens because on Intel, the ALU is put
On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy wrote:
> For now clamp for all drivers. An ulterior optimization
> would be to avoid clamping for drivers with MUL_ZERO_WINS
> for the specific shader versions where NV or AMD don't
> clamp.
Too bad. The whole point of this feature was for nine to use
Tests done on several devices of all 3 vendors and
of different generations showed that there are several
ways of handling infs and NaN for d3d9.
Tests showed Intel on windows does always clamp
RCP, RSQ and LOG (thus preventing inf/nan generation),
for all shader versions (some vendor behaviours
12 matches
Mail list logo
