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
> are the enemy, esp when you hit glsl copy prop and the r600/sb
> 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
> allowing drivers to choose if they want no fp64, hw fp64, or emulated
> 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
> cause a lot of long compile times in both the glsl compiler and the
> backend, however I'd really like to get this stuff checked in so we
> 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
> but fixes for the other parts of the stack.
> Also I'm not really interested in bikeshedding the nitty gritty
> 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
> is going to use it that often in practice, and if we can get it to
> 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
> than optimising it to reduce GPU usage.
> mesa-dev mailing list
mesa-dev mailing list