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
