Am Dienstag, den 13.03.2018, 14:24 +1000 schrieb Dave Airlie:
> This is the main code for the soft fp64 work. It's mostly Elie's
> code with a bunch of changes by me.

Many thanks for this work, Elie and Dave. I've tested the patches on
BARTS with nosb, piglit set all, -t fp64, and I get 2976 of 2995 test
pass, skip: 16, fail: 3 (like Elie pointed out: ssbo and arrays of
arrays are the culprits).

I'm wonderig a bit what is the subset that gives you 1375 piglits ... 

In any case: Tested-By: Gert Wollny <gw.foss...@gmail.com> 

> 
> This patchset has all the glsl lowering code. (using float64.glsl,
> yes I know checked in files are bad, but not bad enough for anyone
> to have solved int64.glsl yet, so we have a precedent).
> 
> It introduces the builtin code for all the functions first,
> this code has seen some optimisation using findMSB and mix opcodes
> to remove if branches, I'm sure it could see a lot more. if
> statements
> are the enemy, esp when you hit glsl copy prop and the r600/sb
> backend.
> 
> The second part is just the lowering hooks to use the builtins,
> but also to do a bunch of non-builtin lowering.
> 
> Finally the gallium patches adds a new interpreation for the
> PIPE_CAP_DOUBLES,
> allowing drivers to choose if they want no fp64, hw fp64, or emulated
> fp64.
> I don't think we should be enabling this for everyone, just drivers
> who ask.
> 
> There is no r600 patch in this series, it's a one liner, but the code
> does
> cause a lot of long compile times in both the glsl compiler and the
> r600
> backend, however I'd really like to get this stuff checked in so we
> have
>  a known stable good base (it passes
> [1375/1375] skip: 5, pass: 1368, fail: 2
> on r600 nosb at the moment).
> 
> I think most of the remaining issues are not to be found in this
> code,
> but fixes for the other parts of the stack.
> 
> Also I'm not really interested in bikeshedding the nitty gritty
> details
> of the fp64 emulation, the main goal for this code is to provide the
> fp64 bit so we can enable GL4.3 on evergreen GPUs, I don't think
> anyone
> is going to use it that often in practice, and if we can get it to
> the
> level that passes conformance (still WIP) then I'll be happy. I think
> optimising it to reduce CPU usage at compile time is way more
> important
> than optimising it to reduce GPU usage.
> 
> Dave.
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to