search for: cl_mem

...that is what Francisco's original code was using. And this also is what things like the tgsi LOAD instruction take. If you're doing a LOAD on a 1d buffer then you will use TEMP[#].x to specify the index, and the way how this currently works with OpenCL is that clCreateBuffer() will return a cl_mem type which then gets passed into the kernel as input parameter and gets treated as a pointer by the compiler, so e.g. global mem gets treated as a single address space even if there are multiple global buffers and TEMP[#].x contains the value passed in via cl_mem as start offset for the buffer + th...

...9;s > original > code was using. And this also is what things like the tgsi LOAD instruction > take. If you're doing a LOAD on a 1d buffer then you will use TEMP[#].x to > specify the index, and the way how this currently works with OpenCL is that > clCreateBuffer() will return a cl_mem type which then gets passed into > the kernel as input parameter and gets treated as a pointer by the compiler, > so e.g. global mem gets treated as a single address space even if there > are multiple global buffers and TEMP[#].x contains the value passed in > via cl_mem as start offset...

...l >> code was using. And this also is what things like the tgsi LOAD instruction >> take. If you're doing a LOAD on a 1d buffer then you will use TEMP[#].x to >> specify the index, and the way how this currently works with OpenCL is that >> clCreateBuffer() will return a cl_mem type which then gets passed into >> the kernel as input parameter and gets treated as a pointer by the compiler, >> so e.g. global mem gets treated as a single address space even if there >> are multiple global buffers and TEMP[#].x contains the value passed in >> via cl_mem...

...ings like the tgsi LOAD >>> instruction >>> take. If you're doing a LOAD on a 1d buffer then you will use >>> TEMP[#].x to >>> specify the index, and the way how this currently works with OpenCL >>> is that >>> clCreateBuffer() will return a cl_mem type which then gets passed into >>> the kernel as input parameter and gets treated as a pointer by the >>> compiler, >>> so e.g. global mem gets treated as a single address space even if there >>> are multiple global buffers and TEMP[#].x contains the value pass...

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:

...does not allow. The closest thing is a constant parameter in OpenCL, at first I've tried binding this as a 2d image, but that leads to the gpu hanging, this is the code activated with "#define USE_IMAGE_FOR_BUF 1" in the above file. So in a 2nd attempt I've hacked clover to bind cl_mem objects passed in as constants as rw. This is the code when USE_IMAGE_FOR_BUF is not defined and works. In a 3th attempt because the hack is not something workable in the long run, I've tried to rewrite the test to use a global buffer (not sure this is the best approach other ideas are welcome...