similar to: Some llvm questions (for tgsi backend)

Hi Tom, Thanks for taking the time to answer this. On 11-01-16 18:10, Tom Stellard wrote: > On Mon, Jan 11, 2016 at 12:07:14PM +0100, Hans de Goede wrote: >> Hi, >> >> After a few distractions I'm back to work on the llvm tgsi backend. I've >> added clang integration and I can now compile a simple opencl program >> to something which sort of looks like

On Mon, Jan 11, 2016 at 6:07 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > After a few distractions I'm back to work on the llvm tgsi backend. I've > added clang integration and I can now compile a simple opencl program > to something which sort of looks like tgsi. > > You can find my latest work on this here: >

On Mon, Jan 11, 2016 at 12:07:14PM +0100, Hans de Goede wrote: > Hi, > > After a few distractions I'm back to work on the llvm tgsi backend. I've > added clang integration and I can now compile a simple opencl program > to something which sort of looks like tgsi. > > You can find my latest work on this here: > http://cgit.freedesktop.org/~jwrdegoede/llvm >

Hi, On 13-11-15 19:51, Tom Stellard wrote: > On Fri, Nov 13, 2015 at 02:46:52PM +0100, Hans de Goede wrote: >> Hi All, >> >> So as discussed I've started working on a TGSI backend for >> llvm to use as a way to get compute going on nouveau (and other gpu-s). >> >> I'm still learning all the ins and outs of llvm so I do not have >> much to show

Hi All, So as discussed I've started working on a TGSI backend for llvm to use as a way to get compute going on nouveau (and other gpu-s). I'm still learning all the ins and outs of llvm so I do not have much to show yet. I've rebased Francisco's (curro's) latest version on top of llvm trunk, and added a commit on top to actual get it build with the latest trunk. So

Hi, On 22-02-16 13:41, Samuel Pitoiset wrote: > Hi there, > > On 02/22/2016 12:26 PM, Hans de Goede wrote: <snip> >> So back to the problem of getting OpenCL(ish) code to work again with >> the recent mesa changes. For starters I would like to get: >> >> src/gallium/tests/trivial/compute.c and then the test with mask 8, >> test_input_global() to work

Hi, On 22-02-16 14:04, Samuel Pitoiset wrote: > > On 02/22/2016 01:46 PM, Hans de Goede wrote: >> Hi, >> >> On 22-02-16 13:41, Samuel Pitoiset wrote: >>> Hi there, >>> >>> On 02/22/2016 12:26 PM, Hans de Goede wrote: >> >> <snip> >> >>>> So back to the problem of getting OpenCL(ish) code to work again with

Hi, On 19-02-16 20:43, Ilia Mirkin wrote: > On Fri, Feb 19, 2016 at 5:36 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> On 18-02-16 17:39, Ilia Mirkin wrote: >>> >>> 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

Hi, On 18-02-16 17:39, Ilia Mirkin wrote: > 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 Cool, I will take a look at those. >> So some questions: >> -The commit by

Hi All, I've been working on translating the tests/trivial/compute.c tests to opencl (for the buffer setup and kernel launch, I'm keeping the compute kernels in tgsi as an intermediate step). I've got the test_input_global() test working, see: https://fedorapeople.org/~jwrdegoede/compute-opencl-tgsi.c Next I wanted to convert the test_system_values() test and there I've gotten

I believe that your problem is this: /*01a0*/ LD R8, [R8]; /* 0x8000000000821c85 */ That needs to be LD.E (and your ST's need to be ST.E). You're using a 32-bit gmem address, but you need to be using a 64-bit one. I believe the 32-bit ones work on fermi, but afaik not on Kepler. Cheers, -ilia On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede

On 02/22/2016 01:46 PM, Hans de Goede wrote: > Hi, > > On 22-02-16 13:41, Samuel Pitoiset wrote: >> Hi there, >> >> On 02/22/2016 12:26 PM, Hans de Goede wrote: > > <snip> > >>> So back to the problem of getting OpenCL(ish) code to work again with >>> the recent mesa changes. For starters I would like to get: >>> >>>

Well the pipe_loader stuff is buggy in compute.c, I can't even create a screen object... That's sad. It fails in pipe_loader_probe() & co. On 02/22/2016 02:08 PM, Hans de Goede wrote: > Hi, > > On 22-02-16 14:04, Samuel Pitoiset wrote: >> >> On 02/22/2016 01:46 PM, Hans de Goede wrote: >>> Hi, >>> >>> On 22-02-16 13:41, Samuel Pitoiset

On Mon, Feb 22, 2016 at 8:08 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > > On 22-02-16 14:04, Samuel Pitoiset wrote: >> >> >> On 02/22/2016 01:46 PM, Hans de Goede wrote: >>> >>> Hi, >>> >>> On 22-02-16 13:41, Samuel Pitoiset wrote: >>>> >>>> Hi there, >>>> >>>>

Hi there, On 02/22/2016 12:26 PM, Hans de Goede wrote: > Hi, > > On 19-02-16 20:43, Ilia Mirkin wrote: >> On Fri, Feb 19, 2016 at 5:36 AM, Hans de Goede <hdegoede at redhat.com> >> wrote: >>> Hi, >>> >>> On 18-02-16 17:39, Ilia Mirkin wrote: >>>> >>>> On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede <hdegoede at

Hi, Here are patches which implement the support for OpenCL kernel input parameters we discussed. They also add the tgsi parsing bits for adding support for global / local mem, but no implementation yet. Regards, Hans

LOAD loads upto 4 components from the specified resource starting at the passed in x value of the 2nd source operand, the y, z and w components of the address should not be used. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -New patch in v2 of this patch-set --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 2 +- 1 file changed, 1 insertion(+), 1

When support for decl.Atomic and .Shared was added, tgsi_build_declaration was not updated to propagate these properly. Signed-off-by: Hans de Goede <hdegoede at redhat.com> Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Changes in v2: -Add Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 6 ++++++ 1 file changed, 6

The llvm TGSI backend does things like: LOAD TEMP[0].y, MEMORY[0].xxxx, TEMP[0].x Expecting the data at address TEMP[0].x to get loaded to TEMP[0].y. Before this commit the data at TEMP[0].x + 4 would be loaded instead. This commit fixes this. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 8 ++++++-- 1 file changed,

On 03/16/2016 10:23 AM, Hans de Goede wrote: > Commit c3083c7082 ("nv50/ir: add support for BUFFER accesses") disabled / > commented out some of the old resource handling code, but not all of it. > > Effectively all of it is dead already, if we ever enter the old code > paths in handeLOAD / handleSTORE / handleATOM we will get an exception > due to trying to access the