[Mesa-dev] [GSoC] Update about floating point library

[Connor Abbott]

(Re-adding the list)

On Mon, Jul 25, 2016 at 4:46 AM, tournier.elie <tournier.elie at gmail.com> wrote:
> Hi.
>
> Thanks for your email.
> It seems that you don't work for nvidia. :P.
>
> 1.
> In my *.shader_test files, I have:
> [require]
> GLSL >= 1.30
>
> Should I still add "#version 130" at the top of each shaders?

Yes, since AFAIK that's just a requirement on the OpenGL
implementation ("you must support at least GLSL 1.30 to run this
test") and it doesn't actually add the version tag. If you take a look
at any random shader_test file in piglit (e.g.
tests/spec/glsl-1.30/execution/vs-attrib-ivec4-precision.shader_test)
you'll see that it declares the version explicitly. And you've already
seen the kind of shenanigans that happen when you don't add it and
don't test with Mesa.

>
> 3.
> I think that I just need recip and rsqrt to finish the library. (and to test
> my code of course.)
> I will check which functions does I need to implement
> GL_ARB_gpu_shader_fp64.

Ok, although I think you'll need to implement fma to get the precision
you need to implement sqrt, inverse, and rsqrt. I believe "real"
softfloat libraries use some kind of integer-based higher-precision
thing, but you don't need an exact result so you don't need to be that
fancy (again, a good reason why our implementation is probably better
to base off of!).

Connor

>
>
> Elie
>
>
> Le samedi 23 juillet 2016, Connor Abbott <cwabbott0 at gmail.com> a écrit :
>>
>> On Sat, Jul 23, 2016 at 3:32 PM, tournier.elie <tournier.elie at gmail.com>
>> wrote:
>> > Hello,
>> >
>> > I hope you are well and that you enjoy these beautiful summer days.
>> >
>> > You can found a new post on my blog : https://hopetech.github.io/ .
>> > During these few days, I implemented eq_fp64, le_fp64, lt_fp64,
>> > mul_fp64,
>> > add_fp64 and fp64-to-fp32-conversion. The code can be found on
>> > https://github.com/Hopetech/libSoftFloat .
>> >
>> > Like I say in my post, I will try to make a Docker file for Mesa and
>> > Piglit
>> > developers.
>> > The goal is to have an "easy to install" working environment.
>> > If you have any ideas/recommandations, please don't hesitate to contact
>> > me.
>> >
>> > Have a nice day.
>> > Elie Tournier
>> >
>> > _______________________________________________
>> > mesa-dev mailing list
>> > mesa-dev at lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> >
>>
>> Hi,
>>
>> Here are a few things to consider:
>>
>> 1. If you want your implementation to be pure GLSL 1.30, then you need
>> to add "#version 130" at the top of all your shaders. Otherwise,
>> you'll nominally get GLSL 1.10 (which doesn't support bit-twiddling at
>> all), but certain vendors (*cough* nvidia *cough*) will take it to
>> mean "just turn all of the extensions on." If you don't add the
>> version tag, then you might accidentally do something that won't fly
>> on other implementations. For example, you're using pointers all over
>> the place in function parameters when that's not valid GLSL 1.30 (or
>> any other unextended version of GLSL) since GLSL doesn't have the
>> concept of pointers. Instead, you should be using out/inout parameters
>> (e.g. "out uint zExpPtr").
>>
>> 2. I wouldn't worry too much about underflow, etc. since GLSL doesn't
>> require it. The goal in the end is to implement fp64 in a way that
>> satisfies the GLSL spec, so you don't need to worry about implementing
>> all of IEEE if GLSL says it isn't required.
>>
>> 2. For sqrt, rsqrt, mod, and so on, I'd check out Intel's
>> implementation of them in our compiler:
>>
>> https://cgit.freedesktop.org/mesa/mesa/tree/src/compiler/nir/nir_lower_double_ops.c
>> Intel GPU's are missing a lot of the fp64 operations required by GLSL
>> (they basically only have the ones you already implemented, plus fma),
>> so we had to emulate the others ourselves. Once you get fma working,
>> you can just follow the code there to implement the rest, since your
>> goal is very similar to ours. This should be much more straightforward
>> than basing your code on another softfloat library, since, like you,
>> we assume the existence of all the fp32 operations and don't try to be
>> exact when GLSL doesn't require us to be.
>>
>> Connor