Hi, On 20-11-15 17:07, Samuel Pitoiset wrote:> > > On 11/20/2015 11:36 AM, Hans de Goede wrote: >> Hi Samual, et al, > > Hi Hans, > >> >> In >> http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd >> >> you write: "This compute support has been tested by >> Pierre Moreau and myself with some compute kernels." >> >> Can you provide testing instructions (and the >> necessary files) so that I can try to reproduce >> your tests ? >> >> And once I've reproduced your tests, the next >> question is where / how did you get the compute >> kernels for testing. I guess you manually wrote them ? > > Yeah, I wrote those compute kernels directly in assembly by hand. > > I already said few days ago, you have some examples in src/gallium/tests/trivial/compute.c which show how to use that compute support stuff with TGSI kernels and without clover.Ah, right. Ok I'll take a look at those.> Because clover is not currently able to do OpenCL -> TGSI using Clang/LLVM, you can't really use your backend directly.I know I'm fine with manually copying TGSI output by llc for my first tests. I've the feeling I need to understand how inputs to / outputs from the TGSI code are handled better before I can do further work on the llvm TGSI backend.> An other way to achieve what you need is to copy/paste your TGSI kernel in src/gallium/tests/trivial/compute.c, set up the global buffers and other stuff (maybe samplers, textures and so on) yourself. This is a bit painful but should work as expected. > >> >> As you know I'm working on a llvm tgsi backend, >> it actually produces some output now, if you want >> to take a peek it lives here: >> http://cgit.freedesktop.org/~jwrdegoede/llvm > > I'm currently building your TGSI branch. :-)Cool, note this is very very preliminary. This really is just curro's work ported to the latest llvm trunk without me having added anything (yet).>> Before working further on this I want to take >> a bottom up approach, so I want to first make >> sure we've working TGSI -> compute-kernel and >> compute-kernel -> hardware steps. So the next >> question is, do you know if we can go from >> (manually written) TGSI to a compute-kernel >> using say nouveau-compiler ? > > Sure, you can use nouveau-compiler to convert TGSI to NV50 IR, but as I said, you can't directly execute your compute kernel without setting a ton of stuff before... That's a bunch of fun! :-) > > Btw, do you still need compute support on your GK208? or did you have an other card for testing ?No I've a GT 610 / GF119 card now (still need to plug it in). Regards, Hans
On 11/20/2015 05:29 PM, Hans de Goede wrote:> Hi, > > On 20-11-15 17:07, Samuel Pitoiset wrote: >> >> >> On 11/20/2015 11:36 AM, Hans de Goede wrote: >>> Hi Samual, et al, >> >> Hi Hans, >> >>> >>> In >>> http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd >>> >>> >>> you write: "This compute support has been tested by >>> Pierre Moreau and myself with some compute kernels." >>> >>> Can you provide testing instructions (and the >>> necessary files) so that I can try to reproduce >>> your tests ? >>> >>> And once I've reproduced your tests, the next >>> question is where / how did you get the compute >>> kernels for testing. I guess you manually wrote them ? >> >> Yeah, I wrote those compute kernels directly in assembly by hand. >> >> I already said few days ago, you have some examples in >> src/gallium/tests/trivial/compute.c which show how to use that compute >> support stuff with TGSI kernels and without clover. > > Ah, right. Ok I'll take a look at those. > >> Because clover is not currently able to do OpenCL -> TGSI using >> Clang/LLVM, you can't really use your backend directly. > > I know I'm fine with manually copying TGSI output by llc for my first > tests. I've the feeling I need to understand how inputs to / outputs > from the TGSI code are handled better before I can do further work > on the llvm TGSI backend. > >> An other way to achieve what you need is to copy/paste your TGSI >> kernel in src/gallium/tests/trivial/compute.c, set up the global >> buffers and other stuff (maybe samplers, textures and so on) yourself. >> This is a bit painful but should work as expected. >> >>> >>> As you know I'm working on a llvm tgsi backend, >>> it actually produces some output now, if you want >>> to take a peek it lives here: >>> http://cgit.freedesktop.org/~jwrdegoede/llvm >> >> I'm currently building your TGSI branch. :-) > > Cool, note this is very very preliminary. This really > is just curro's work ported to the latest llvm trunk > without me having added anything (yet). > >>> Before working further on this I want to take >>> a bottom up approach, so I want to first make >>> sure we've working TGSI -> compute-kernel and >>> compute-kernel -> hardware steps. So the next >>> question is, do you know if we can go from >>> (manually written) TGSI to a compute-kernel >>> using say nouveau-compiler ? >> >> Sure, you can use nouveau-compiler to convert TGSI to NV50 IR, but as >> I said, you can't directly execute your compute kernel without setting >> a ton of stuff before... That's a bunch of fun! :-) >> >> Btw, do you still need compute support on your GK208? or did you have >> an other card for testing ? > > No I've a GT 610 / GF119 card now (still need to plug it in).Cool, note that compute support is available on tesla, fermi and kepler since I merged the nv50 compute ~one week ago. Some bits are missing for tesla and fermi, but I can have look if you need them. Those bits are mostly related to textures, surfaces and samplers, but you can already launch "simple" kernels.> > Regards, > > Hans-- -Samuel
On 01-12-15, Samuel Pitoiset wrote:
 >>> Ok, here is a MMT trace of vectorAdd:
 >>>
 >>> https://fedorapeople.org/~jwrdegoede/vectorAdd.log.gz
 >>
 >> Hi Hans,
 >>
 >> Thanks a lot.
 >
 > Well, I didn't know but Martin has a GK208...
 > I just tested the compute support on his card and ... it works without
 > any changes. :-)
 >
 > I'm sorry, I was sure the compute support didn't work on this
chipset.
No need to be sorry because, ...
 > Feel free to test on your GK208 and report back if you have problems.
I've done that, and for me it does not work, if I try to enable compute
support like this:
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 461fcaa..ab4ea85 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -187,7 +187,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum
pipe_cap param)
     case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
        return (class_3d >= NVE4_3D_CLASS) ? 1 : 0;
     case PIPE_CAP_COMPUTE:
-      return (class_3d <= NVE4_3D_CLASS) ? 1 : 0;
+      return 1;
     case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
        return nouveau_screen(pscreen)->vram_domain & NOUVEAU_BO_VRAM ? 1
: 0;
@@ -246,8 +246,6 @@ nvc0_screen_get_shader_param(struct pipe_screen *pscreen,
unsigned shader,
           return 0;
        break;
     case PIPE_SHADER_COMPUTE:
-      if (class_3d > NVE4_3D_CLASS)
-         return 0;
        break;
     default:
        return 0;
@@ -574,11 +572,10 @@ nvc0_screen_init_compute(struct nvc0_screen *screen)
     case 0xd0:
        return nvc0_screen_compute_setup(screen, screen->base.pushbuf);
     case 0xe0:
-      return nve4_screen_compute_setup(screen, screen->base.pushbuf);
     case 0xf0:
     case 0x100:
     case 0x110:
-      return 0;
+      return nve4_screen_compute_setup(screen, screen->base.pushbuf);
     default:
        return -1;
     }
Then as soon as I do startx (which starts gnome-shell) the machine
freezes. This is with mesa-master with the above changes on top.
X / gnome-shell will happily work of I do not call nve4_screen_compute_setup()
but then test/trivial/compute fails with a null-ptr exception.
Do you perhaps have some extra patches in your tree, or am I just unlucky ?
I've tested this on both a 4.2 and a 4.4-rc3 kernel.
Regards,
Hans