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

Connor Abbott cwabbott0 at gmail.com
Fri Jul 29 05:10:30 UTC 2016

(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.
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!).


> 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

More information about the mesa-dev mailing list