search for: clcreatebuff

...een using U32 for addresses as 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 o...

...es as 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 > v...

...rancisco'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 pass...

...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[#]....

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: