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

From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>,
	Samuel Pitoiset
	<samuel.pitoiset-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Dealing with opencl kernel parameters in nouveau now that RES support is gone
Date: Thu, 18 Feb 2016 15:45:13 +0100	[thread overview]
Message-ID: <56C5D8F9.6030408@redhat.com> (raw)

Hi Ilia and Samuel,

I rebased my mesa git tree today (it was getting a bit stale)
and after that src/gallium/tests/trivial/compute.c stopped
working as well as any opencl programs with the kernel in TGSI
(as clover on nouveau currently only supports having the kernel
in TGSI).

The problem is that RES no longer is a valid register-file
name in TGSI, specifically this is caused by this commit:

https://cgit.freedesktop.org/mesa/mesa/commit?id=8cc9a8aa2a97ca9e7a36a993954a3480d44c13d3
(no surprises there)

I noticed that Samual adds TGSI_FILE_MEMORY support here:
https://cgit.freedesktop.org/mesa/mesa/commit?id=a8328e3a50169c3c74656df7f63f56f061d9e751

But this does not seem to be hooked up yet for nouveau.

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.

-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 ?

  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 ?

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.
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau