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
On 12/02/2015 04:34 PM, Hans de Goede wrote:> 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.Hi, My bad... I used the wrong card on reator (which is the REing machine of Martin). The primary card is a GK106 and the second one is the GK208. That doesn't explain why I did something wrong but heh? :-) You are right. With those bits added locally, the compute support totally hangs the GPU on my GK208 (NV108), and a reboot is needed. Please give a shot at this branch : http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute It fixes the initialization of the compute state and allows me to launch 'test_input_global' (ie. ./compute 8) on my GK208 without any dmesg fails. That's a good start but more patches are coming. :-) Btw, according to the trace you sent me, you have a GK208b (NV106). Thanks!> > Regards, > > Hans
On Wed, Dec 2, 2015 at 1:33 PM, Samuel Pitoiset <samuel.pitoiset at gmail.com> wrote:> > > On 12/02/2015 04:34 PM, Hans de Goede wrote: >> >> 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. > > > Hi, > > My bad... I used the wrong card on reator (which is the REing machine of > Martin). The primary card is a GK106 and the second one is the GK208. That > doesn't explain why I did something wrong but heh? :-) > > You are right. With those bits added locally, the compute support totally > hangs the GPU on my GK208 (NV108), and a reboot is needed. > > Please give a shot at this branch : > http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute > > It fixes the initialization of the compute state and allows me to > launch 'test_input_global' (ie. ./compute 8) on my GK208 without > any dmesg fails. That's a good start but more patches are coming. :-)The firmware methods are implemented by the ctxsw fw, in the fuc. You should try to see what the blob firmware used that one for and see if we need to implement the same thing or not. I've generally ignored them. There is another firmware method for the equivalent of a context-aware nv_mask()... I think you write the reg/mask/new into the SCRATCH methods, and then invoke the firmware command. Or something. I looked into when I thought it was related to atomic fail. -ilia
Hi, On 02-12-15 19:33, Samuel Pitoiset wrote:> > > On 12/02/2015 04:34 PM, Hans de Goede wrote: >> 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. > > Hi, > > My bad... I used the wrong card on reator (which is the REing machine of Martin). The primary card is a GK106 and the second one is the GK208. That doesn't explain why I did something wrong but heh? :-) > > You are right. With those bits added locally, the compute support totally hangs the GPU on my GK208 (NV108), and a reboot is needed. > > Please give a shot at this branch : > http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute > > It fixes the initialization of the compute state and allows me to > launch 'test_input_global' (ie. ./compute 8) on my GK208 without > any dmesg fails. That's a good start but more patches are coming. :-)This branch indeed works somewhat better, but things still hang on the test_system_values compute test for me (this is the first test executed I did not try the others). So this seems to need more work. I've ordered a GTX740 (GK107) card, which should arrive soon, and I'll be using that so I can (hopefully) focus on the llvm tgsi bits again.> Btw, according to the trace you sent me, you have a GK208b (NV106).Right, sorry I thought the differences between GK208 and GK208b would not matter. Thanks for all the input / help! Regards, Hans