[Nouveau] NV50 compute support questions

[Ilia Mirkin]

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