[Mesa-dev] [PATCH v3 01/24] mesa/format_utils: Fix a bug in unorm_to_float helper function
Michel Dänzer
michel at daenzer.net
Thu Dec 11 00:42:02 PST 2014
On 11.12.2014 14:50, Jason Ekstrand wrote:
>
> On Dec 10, 2014 8:13 PM, "Michel Dänzer" <michel at daenzer.net
> <mailto:michel at daenzer.net>> wrote:
>>
>> On 11.12.2014 01:08, Jason Ekstrand wrote:
>> >
>> >
>> > On Tue, Dec 9, 2014 at 10:53 PM, Michel Dänzer <michel at daenzer.net
> <mailto:michel at daenzer.net>
>> > <mailto:michel at daenzer.net <mailto:michel at daenzer.net>>> wrote:
>> >
>> > On 09.12.2014 21:06, Iago Toral Quiroga wrote:
>> > > From: Jason Ekstrand <jason.ekstrand at intel.com
> <mailto:jason.ekstrand at intel.com> <mailto:jason.ekstrand at intel.com
> <mailto:jason.ekstrand at intel.com>>>
>> > >
>> > > This patch fixes the return of a wrong value when x is lower than
>> > > -MAX_INT(src_bits) as the result would not be between [-1.0 1.0].
>> > >
>> > > v2 by Samuel Iglesias <siglesias at igalia.com
> <mailto:siglesias at igalia.com> <mailto:siglesias at igalia.com
> <mailto:siglesias at igalia.com>>>:
>> > > - Modify unorm_to_float() to avoid doing the division when
>> > > x == -MAX_INT(src_bits)
>> > >
>> > > Reviewed-by: Ian Romanick <ian.d.romanick at intel.com
> <mailto:ian.d.romanick at intel.com> <mailto:ian.d.romanick at intel.com
> <mailto:ian.d.romanick at intel.com>>>
>> > > ---
>> > > src/mesa/main/format_utils.c | 2 +-
>> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/src/mesa/main/format_utils.c
> b/src/mesa/main/format_utils.c
>> > > index 93a0cea..5dd0848 100644
>> > > --- a/src/mesa/main/format_utils.c
>> > > +++ b/src/mesa/main/format_utils.c
>> > > @@ -152,7 +152,7 @@ unorm_to_float(unsigned x, unsigned src_bits)
>> > > static inline float
>> > > snorm_to_float(int x, unsigned src_bits)
>> > > {
>> > > - if (x == -MAX_INT(src_bits))
>> > > + if (x <= -MAX_INT(src_bits))
>> > > return -1.0f;
>> > > else
>> > > return x * (1.0f / (float)MAX_INT(src_bits));
>> > >
>> >
>> > The commit log talks about unorm_to_float, but the code modifies
>> > snorm_to_float. Also, I think something like
>> >
>> > mesa: Fix clamping to -1.0 in snorm_to_float
>> >
>> > would be a more useful shortlog.
>> >
>> >
>> > BTW, don't this function and unorm_to_float also need corresponding
>> > clamping to 1.0 for values >= MAX_INT(src_bits)?
>> >
>> >
>> > Yes and no. Every place that we use [us]norm_to_*, we assume that the
>> > value passed in is represented by the given number of bits. Therefore,
>> > clamping above should always be useless. The one edge case is the
>> > signed value MIN_INT(src_bits) (or, if you prefer, -MAX_INT(src_bits) -
>> > 1) in which is representable in the given number of bits but is actually
>> > less than -1 according to the formula. Technically, using an equality
>> > there was Ok, it's just that I had it equal to the wrong thing.
>>
>> So, is returning -1.0 for -MAX_INT(src_bits) correct then, or should the
>> test be '== MIN_INT(src_bits)' or '== -MAX_INT(src_bits) - 1' or either
>> variant using <=?
>
> -MAX_INT(src_bits) will map to -1.0 even without the if statement (just
> look at the formula). The problem is that, thanks to the clamping
> implicit in the conversion formulas, so should -MAX_INT(src_bits)-1.
> Therefore, any of "< -MAX_INT(src_bits)", "== -MAX_INT(src_bits) - 1",
> or "<= -MAX_INT(src_bits)" will work. The best (most clear) would
> probably be "< -MAX_INT(src_bits)". If I recall correctly, I decided on
> the other simply because, while we have the branch in there anyway, we
> might as well cut the calculation when we can.
Actually, you had 'x < -MAX_INT(src_bits)' in your original patch, and I
pointed out that 'x <= -MAX_INT(src_bits)' would save the calculation in
the == -MAX_INT(src_bits) case. Sorry for coming full circle on this.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
More information about the mesa-dev
mailing list