Nouveau - Feb 2016 - Dealing with opencl kernel parameters in nouveau now that RES support is gone

On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin <imirkin at alum.mit.edu>
wrote:
> INPUT is for shader inputs which come from fixed function loaders.
> This is not what you want. You want CONST. Stick the input params into
> a constbuf, and you're done.
Oh, and in case it's not clear, I think this should be done by the st,
not by the driver. Not a big fan of the current interface where the
driver is responsible for uploading the kernel input parameters.

  -ilia

Hi,

On 22-02-16 14:47, Ilia Mirkin wrote:
> On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin <imirkin at
alum.mit.edu> wrote:
>> INPUT is for shader inputs which come from fixed function loaders.
>> This is not what you want. You want CONST. Stick the input params into
>> a constbuf, and you're done.
>
> Oh, and in case it's not clear, I think this should be done by the st,
> not by the driver. Not a big fan of the current interface where the
> driver is responsible for uploading the kernel input parameters.
Moving this to the state-tracker will likely break clover for amd
cards, also what is the right place to stick the input params my
differ from one gpu to the other, also the opencl -> tgsi compiler
will need to know how to "address" input params without it needing to
know too much details of the targetted gpu. So of INPUT is not suitable,
then I think we are going to need MEMORY[#], INPUT for this, which
nouveau can then just treat as CONST.

Regards,

Hans

On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede <hdegoede at redhat.com>
wrote:
> Hi,
>
> On 22-02-16 14:47, Ilia Mirkin wrote:
>>
>> On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin <imirkin at
alum.mit.edu> wrote:
>>>
>>> INPUT is for shader inputs which come from fixed function loaders.
>>> This is not what you want. You want CONST. Stick the input params
into
>>> a constbuf, and you're done.
>>
>>
>> Oh, and in case it's not clear, I think this should be done by the
st,
>> not by the driver. Not a big fan of the current interface where the
>> driver is responsible for uploading the kernel input parameters.
>
>
> Moving this to the state-tracker will likely break clover for amd
> cards, also what is the right place to stick the input params my
Not really. Could just have a PIPE_CAP. Could make it part of the
whole TGSI logic in the first place. This functionality isn't used for
the OpenGL compute shader, and it'd be nice to bring OpenCL in line
with the OpenGL stuff.
> differ from one gpu to the other, also the opencl -> tgsi compiler
> will need to know how to "address" input params without it
needing to
> know too much details of the targetted gpu. So of INPUT is not suitable,
> then I think we are going to need MEMORY[#], INPUT for this, which
> nouveau can then just treat as CONST.
That doesn't make sense... MEMORY is for... memory. Perhaps there's
something I don't understand about kernel inputs that would make my
suggestion unworkable? The way I see it is that you stick them into a
user constbuf (i.e. pipe->set_constant_buffer({cb.user = pointer to
your thing})), and then launch the grid. Your TGSI would have been
composed such that it would expect the user params to show up in the
first constbuf.

You *really* want to be using constbufs here -- they're designed for this.

  -ilia