[Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

[Ilia Mirkin]

On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede <hdegoede at redhat.com> wrote:
> But this does not seem to be hooked up yet for nouveau.

Samuel has patches. See
https://cgit.freedesktop.org/~hakzsam/mesa/log/?h=arb_compute_shader_v3

>
> So some questions:
> -The commit by Samual says:
>  This introduces TGSI_FILE_MEMORY for shared, global and local memory. Only
> shared memory is currently supported.
>
>  The commit introduces MEMORY[x] and MEMORY[x],SHARED so in reality it also
> introduces
>  a second option next to shared, so what are we going to use plain MEMORY[x]
> for?
>  I suggest using it for global memory but we need to be in agreement on
> this.

That sounds fine to me. However what I had in mind was switching the
SHARED field into a 2-bit field and making it

1 = SHARED
2 = GLOBAL
3 = LOCAL

(since for OpenCL you also need to be able to address local or private
memory). I sorta wanted Samuel to do it, but since I had no idea where
you were at, or if you were even still working on this, I figured it
should be fixed up by the first person who needed it.

>
> -What about kernel input parameters, so far these have been using RES[32764]
>  I must admit that I do not understand where the file_index of 32764 comes
>  from (or where any of the file indexes come from for
> src/gallium/tests/trivial/compute.c ?
>  I have the feeling that these are not used at all, and everything simply
> goes
>  to a flat (virtual) memory space, with the params at address 0, correct ?

It was never particularly well-specified, which was one of the reasons
it went away. It also didn't map nicely onto the OpenGL model. There
is a remaining question of how to do addressing in memory... there's
40 bits of address space. Should these implicitly be U64
(dual-component in TGSI) addresses that are passed around? Not sure
what the OpenCL position on all this is.

Also it would be highly preferable to avoid using GLOBAL at all in the
first place, and just use BUFFER[] or IMAGE[] or whatever. However
after having a look at how OpenCL works, I don't think that's
possible. But perhaps I missed something?

>
>  This seems like a nvidia implementation detail though, and we should IMHO
> still
>  implement a specific TGSI register file for accessing kernel input params,
>  agreed ?

I believe that kernel input params should be passed in via user
uniforms. i.e. CONST. It doesn't have to be a separate UBO, it can use
the user buffer thing, which is basically what it is now.

>
> If we can agree on the TGSI syntax for all this, then I'm pretty sure I can
> hack
> something together to get things to work with the latest master again, and
> then we
> can use this as a starting point for properly implementing this.
>
> Regards,
>
> Hans
>
>
> p.s.
>
> I must say I was somewhat unpleasantly surprised by the RES breakage, yes I
> know
> some changes were coming but still. In the future when my llvm->tgsi work is
> more
> stable and I'll be pushing it to llvm upstream we really cannot make
> breaking tgsi
> changes like this.

I thought I had sufficiently explained to you that the resource thing
was going away -- it was never spec'd, and there were no users.
Perhaps I didn't make it clear enough though -- sorry. The reality is
that TGSI is a living thing, and things change every so often. I don't
think people would be comfortable with locking down TGSI in such a
way.

  -ilia