Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
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. > With all the changes that landed lately for r600 I wanted to check how things are doing, but unfortunately the series doesn't apply anymore, specifically the file compiler/glsl/lower_64bit.cpp was renamed to compiler/glsl/lower_64int.cpp and changed in a way that requires to make nontrivial changes to the patch. Could you respin? many thanks, Gert ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
Am Mittwoch, den 14.03.2018, 21:05 +1100 schrieb Timothy Arceri: > > > Anyway I'm not trying to convince Dave as I'm sure he has a good idea > of the work involve. Just thought I'd mention this stuff in case > anyone else has considered working on NIR for r600 and are scared by > Daves time estimate :) I was actually thinking about this, but it seems that apart from [1] there is not much documentation available that lifes outside the source code, so for me who doesn't know anything about the inner workings of NIR at this point, the learing curve would add quite some overhead. In any case, I'd guess implementing a nir->tgsi translation might be more useful, because it would help more drivers, I'm just wondering whether TGSI can represent NIR well enough ... [1] https://people.freedesktop.org/~cwabbott0/nir-docs/intro.html#organ ization ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
On Tue, Mar 13, 2018 at 04:54:27PM -0700, Matt Turner wrote: > On Mon, Mar 12, 2018 at 9:24 PM, Dave Airlie wrote: > > This is the main code for the soft fp64 work. It's mostly Elie's > > code with a bunch of changes by me. > > > > 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). > Hi Matt > Have you thought about making a NIR backend for R600? > > Elie sent patches for lowering fp64 operations in NIR, and it's what > I'm going to start from when I do the analogous project for some > future Intel hardware. It's sad to duplicate all of this code, much > less all of this effort. Let me know when you start this project, I will be happy to help. Some (bad) idea here. Can we wire the GLSL IR version for your hardware? Once the NIR version finished, we just remove it. > ___ > 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
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
On 14/03/18 21:05, Timothy Arceri wrote: On 14/03/18 11:04, Dave Airlie wrote: On 14 March 2018 at 09:54, Matt Turner wrote: On Mon, Mar 12, 2018 at 9:24 PM, Dave Airlie wrote: This is the main code for the soft fp64 work. It's mostly Elie's code with a bunch of changes by me. 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). Have you thought about making a NIR backend for R600? It would be a lot more work and way too uncertain, I reckon it's taken Timothy 6 months to get radeonsi even close with nir, I don't have 6 months to spend on getting r600 close, it's backend situation is a lot worse than radeonsi. I don't doubt its a lot of work, but I should note that a chuck of time has been ironing out the somewhat rough state the state tracker was in in spots and adding the missing stages, nir passes, nir shader cache etc. Also as the goal was to make the NIR backend better than tgsi I did spend a bunch of time working on NIR linking support and related passes (added to RADV too). Oh and uniform packing the last couple of days. Anyway I'm not trying to convince Dave as I'm sure he has a good idea of the work involve. Just thought I'd mention this stuff in case anyone else has considered working on NIR for r600 and are scared by Daves time estimate :) Oh and I meant to add that there is also some time overhead in making sure both the tgsi radeonsi backend and radv didn't break in the process (mostly the tgsi backend). Depending on how NIR support was added to r600 this may not be such an issue. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
On 14/03/18 11:04, Dave Airlie wrote: On 14 March 2018 at 09:54, Matt Turner wrote: On Mon, Mar 12, 2018 at 9:24 PM, Dave Airlie wrote: This is the main code for the soft fp64 work. It's mostly Elie's code with a bunch of changes by me. 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). Have you thought about making a NIR backend for R600? It would be a lot more work and way too uncertain, I reckon it's taken Timothy 6 months to get radeonsi even close with nir, I don't have 6 months to spend on getting r600 close, it's backend situation is a lot worse than radeonsi. I don't doubt its a lot of work, but I should note that a chuck of time has been ironing out the somewhat rough state the state tracker was in in spots and adding the missing stages, nir passes, nir shader cache etc. Also as the goal was to make the NIR backend better than tgsi I did spend a bunch of time working on NIR linking support and related passes (added to RADV too). Oh and uniform packing the last couple of days. Anyway I'm not trying to convince Dave as I'm sure he has a good idea of the work involve. Just thought I'd mention this stuff in case anyone else has considered working on NIR for r600 and are scared by Daves time estimate :) Elie sent patches for lowering fp64 operations in NIR, and it's what I'm going to start from when I do the analogous project for some future Intel hardware. It's sad to duplicate all of this code, much less all of this effort. Yes it sucks, but maybe the nir code will get a lot more effort put in and I can improve the GLSL code, I'm mostly hoping the GLSL code is fire and forget since I doubt anyone in the real world will ever use it. 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
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
Am 13.03.2018 um 05:28 schrieb Dave Airlie: > On 13 March 2018 at 14:24, Dave Airlie wrote: >> This is the main code for the soft fp64 work. It's mostly Elie's >> code with a bunch of changes by me. >> > > All the patches are in my tree here, along with some other bits: > https://cgit.freedesktop.org/~airlied/mesa/log/?h=glsl_arb_gpu_shader_fp64_v4 > I've commented on a couple of the actual functions (first 18 patches). I think in general the code is definitely too branchy, far from optimal for gpus (or in general for dealing with vector values ultimately). But, as long as it works, noone cares about performance all that much I suppose. Someone could optimize it later if really interested... Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
On 14 March 2018 at 09:47, Gert Wollny wrote: > > 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 ... I think I've been using -t fp64. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
On 14 March 2018 at 09:54, Matt Turner wrote: > On Mon, Mar 12, 2018 at 9:24 PM, Dave Airlie wrote: >> This is the main code for the soft fp64 work. It's mostly Elie's >> code with a bunch of changes by me. >> >> 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). > > Have you thought about making a NIR backend for R600? It would be a lot more work and way too uncertain, I reckon it's taken Timothy 6 months to get radeonsi even close with nir, I don't have 6 months to spend on getting r600 close, it's backend situation is a lot worse than radeonsi. > > Elie sent patches for lowering fp64 operations in NIR, and it's what > I'm going to start from when I do the analogous project for some > future Intel hardware. It's sad to duplicate all of this code, much > less all of this effort. Yes it sucks, but maybe the nir code will get a lot more effort put in and I can improve the GLSL code, I'm mostly hoping the GLSL code is fire and forget since I doubt anyone in the real world will ever use it. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
On Mon, Mar 12, 2018 at 9:24 PM, Dave Airlie wrote: > This is the main code for the soft fp64 work. It's mostly Elie's > code with a bunch of changes by me. > > 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). Have you thought about making a NIR backend for R600? Elie sent patches for lowering fp64 operations in NIR, and it's what I'm going to start from when I do the analogous project for some future Intel hardware. It's sad to duplicate all of this code, much less all of this effort. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
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 > > 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
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
On Tue, Mar 13, 2018 at 02:28:04PM +1000, Dave Airlie wrote: > On 13 March 2018 at 14:24, Dave Airlie wrote: > > This is the main code for the soft fp64 work. It's mostly Elie's > > code with a bunch of changes by me. > > > > All the patches are in my tree here, along with some other bits: > https://cgit.freedesktop.org/~airlied/mesa/log/?h=glsl_arb_gpu_shader_fp64_v4 > First, thanks for your help/work on this project. Much much appreciated! Patch 7 doesn't land on the ML probably because of its size so please checkout the tree. For information, the failure are due to ssbo and arrays of arrays. > 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
Re: [Mesa-dev] soft fp64 support - main body (glsl/gallium)
On 13 March 2018 at 14:24, Dave Airlie wrote: > This is the main code for the soft fp64 work. It's mostly Elie's > code with a bunch of changes by me. > All the patches are in my tree here, along with some other bits: https://cgit.freedesktop.org/~airlied/mesa/log/?h=glsl_arb_gpu_shader_fp64_v4 Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] soft fp64 support - main body (glsl/gallium)
This is the main code for the soft fp64 work. It's mostly Elie's code with a bunch of changes by me. 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
