From: Terje Mathisen on
Ken Hagan wrote:
> On Thu, 10 Sep 2009 11:16:30 +0100, Terje Mathisen
> <Terje.Mathisen(a)tmsw.no> wrote:
>
>> Another place where fp really helps is when doing gamma-corrected
>> blending/sampling.
>
> How? I'm surprised because I'd have thought a pre-computed LUT was far
> and away the fastest solution for 8-bit images (12-bit once linearised),
> despite its cache-busting tendencies. (That said, since you haven't
> spent a zillion transistors on hardware FP, perhaps your cache is
> larger. :)

You might well be right, in that we already have 12bit accurate parallel
invsqrt() and reciprocal() lookup functions.

The gamma stuff needs to be 10-bit accurate afair from the DX9/10 specs.

I do remember that for tri-lin sampling the log2() function needs to
have at least 10 fractional bits correct, I was able to discover/invent
a fast SIMD style code that managed this without any lookup tables.

I would not have been able to do the same without fp hardware!

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
From: nmm1 on
In article <376dneGNbOn-ZDXXnZ2dnUVZ8jGdnZ2d(a)lyse.net>,
Terje Mathisen <Terje.Mathisen(a)tmsw.no> wrote:
>
>>> I believe you could indeed make a
>>> 'multiply_setup/mul_core1/mul_core2/mul_normalize' perform close to
>>> dedicated hw, but you would have to make sure that _nobody_ except the
>>> compiler writers ever needed to be exposed to it.
>>
>> Nah. You are forgetting yourself, me and other authors of the
>> intrinsic numerical functions and auxiliary code (e.g. complex
>> division) :-) But, with that niggle, I agree.
>
>The math library writers are part of the compiler team, particularly
>since you would want many (most?) of these functions to be intrinsic to
>the compiler, so that it could unroll & interleave as many of them as
>would fit in the register set.

Er, no, they're not! Not in practice, and not entirely in theory. At
most the compiler team will take responsibility for the most important
of the standard intrinsics.

'Tain't true for gcc and glibc, for example.

>I.e. not just a callable math library, but I assume this has been part
>of your suggestion from the start?

Yes. It's standard compiler technology, so I was assuming that it
would be done by the teams that are most concerned about performance.


Regards,
Nick Maclaren.
From: nmm1 on
In article <wOmdnaYJINxgZzXXnZ2dnUVZ8jidnZ2d(a)lyse.net>,
Terje Mathisen <Terje.Mathisen(a)tmsw.no> wrote:
>
>I do remember that for tri-lin sampling the log2() function needs to
>have at least 10 fractional bits correct, I was able to discover/invent
>a fast SIMD style code that managed this without any lookup tables.

No floating-point hardware is needed for implementing fast, efficient
logarithm functions - indeed, most implementations do most of their
work in fixed point!

number = mantissa * 2^exponent
logarithm = exponent + polynomial(mantissa)

Working out a suitable polynomial is easy, and the scaling can be (and
usually is) done statically. There really isn't a problem.

As someone posted, you can vary the precision of the multiplications,
as the higher-order ones are needed to less accuracy. In fact, you
can do an initial linear approximation using only shifting and
addition, to ensure that all multiplications use only a few bits.

number = mantissa * 2^exponent
logarithm = exponent + constant + k*mantissa + polynomial(mantissa)

where k is a convenient number like 5/8.



Regards,
Nick Maclaren.
From: Terje Mathisen on
nmm1(a)cam.ac.uk wrote:
> In article<376dneGNbOn-ZDXXnZ2dnUVZ8jGdnZ2d(a)lyse.net>,
> Terje Mathisen<Terje.Mathisen(a)tmsw.no> wrote:

>> The math library writers are part of the compiler team, particularly
>> since you would want many (most?) of these functions to be intrinsic to
>> the compiler, so that it could unroll& interleave as many of them as
>> would fit in the register set.
>
> Er, no, they're not! Not in practice, and not entirely in theory. At

Sorry, I meant that the math code needs to be part of the compiler team,
for _this_ particular architecture.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
From: nmm1 on
In article <oeSdnTfEupOWyzTXnZ2dnUVZ8i5i4p2d(a)lyse.net>,
Terje Mathisen <Terje.Mathisen(a)tmsw.no> wrote:
>nmm1(a)cam.ac.uk wrote:
>> In article<376dneGNbOn-ZDXXnZ2dnUVZ8jGdnZ2d(a)lyse.net>,
>> Terje Mathisen<Terje.Mathisen(a)tmsw.no> wrote:
>
>>> The math library writers are part of the compiler team, particularly
>>> since you would want many (most?) of these functions to be intrinsic to
>>> the compiler, so that it could unroll& interleave as many of them as
>>> would fit in the register set.
>>
>> Er, no, they're not! Not in practice, and not entirely in theory. At
>
>Sorry, I meant that the math code needs to be part of the compiler team,
>for _this_ particular architecture.

Oh, right. Yes. I misunderstood you.

But my point that the facilities would be useful to other people as
well stands. My experience of writing numeric functions is that a
good half of my problems arose from the fact that I couldn't get at
operations that I knew perfectly well were there in the hardware.

For all of performance, accuracy and exception handling, too.


Regards,
Nick Maclaren.