similar to: [Bug 96931] New: Request: git.freedesktop.org/nouveau/ commit access

Hi, On 15-12-15 20:04, Ilia Mirkin wrote: > Also, where's the exit op? Perhaps what's happening is that you don't > have an exit and it just goes off executing into the ether? Sorry I only included a small bit of the program in my original mail because I found the use of "MOV" instructions to load constants suspicious, is that normal ? I've put a log with

BTW, you may be interested in https://github.com/imirkin/mesa/commits/atomic3 which has working ARB_shader_atomic_counters and ARB_shader_storage_buffer_object support (while ripping out things like TGSI_FILE_RESOURCE). Still working on proper memory qualifier support, and obviously need to do some cleanup before upstreaming. Should be getting into a pushable state probably early January. Cheers,

Hi, On 16-12-15 18:24, Ilia Mirkin wrote: > 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

Hi, On 30-07-15 16:09, Ilia Mirkin wrote: > FWIW this is a fail on nv50+ as well. See for example > https://bugs.freedesktop.org/show_bug.cgi?id=91445 > > My suspicion is that this is due to the lack of PUSH_KICK in the *Done > exa handlers -- works fine with DRI2, but DRI3 has no synchronization > and so the commands never get flushed out. Easily verified by sticking >

On Mon, Nov 30, 2015 at 8:27 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > On 26-11-15 13:52, Samuel Pitoiset wrote: > > <snip> > >>> I do not have a GK106, I've a GK208, and IIRC that one is known to not >>> work, >>> I guess I can give it a try. >> >> >> Compute support is not supported on GK110+,

Hi, On 26-11-15 13:52, Samuel Pitoiset wrote: <snip> >> I do not have a GK106, I've a GK208, and IIRC that one is known to not >> work, >> I guess I can give it a try. > > Compute support is not supported on GK110+, yeah... > > If you provide me a MMT trace of, for example, vectorAdd from the CUDA samples I could have a look. Ok, here is a MMT trace of

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 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 14-03-16 21:50, Samuel Pitoiset wrote: <snip> >>> Btw, do you need someone with commit access to push your previous >>> series (the tgsi thing)? I can do this for you. >> >> Thanks for the offer. IIRC Ilia wanted some minor fixes there, so I'll do >> a v2 tomorrow. Talking about commit rights, I guess it would be >> convenient for all

Hi, On 03-08-15 17:36, Ilia Mirkin wrote: > On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> On 30-07-15 16:09, Ilia Mirkin wrote: >>> >>> FWIW this is a fail on nv50+ as well. See for example >>> https://bugs.freedesktop.org/show_bug.cgi?id=91445 >>> >>> My suspicion is that this is

Also, where's the exit op? Perhaps what's happening is that you don't have an exit and it just goes off executing into the ether? On Tue, Dec 15, 2015 at 12:00 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > A few things that stand out: > > 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) > > wtf is that 0x0000000000000 thing doing there? Was it a %rX which got

Hi all, As part of my compute work I'm trying to get some TGSI compute code to work. The code from mesa/src/gallium/tests/trivial.c works. So now I'm trying to get a "native" tgsi kernel to run via clover, I'm using Francisco's nbody.c example for this: https://fedorapeople.org/~jwrdegoede/nbody.c Which does not work, at first I thought there was an issue with the

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

Hi, On 10-03-16 16:35, Aaron Watry wrote: > On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > >> Extend the MEMORY file support to differentiate between global, local >> and shared memory, as well as "input" memory. >> >> "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a >> special

Hi, On 20-11-15 17:07, Samuel Pitoiset wrote: > > > On 11/20/2015 11:36 AM, Hans de Goede wrote: >> Hi Samual, et al, > > Hi Hans, > >> >> In >> http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd >> >> you write: "This compute support has been tested by >> Pierre

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 yet. > > I've rebased Francisco's (curro's) latest

On 11/20/2015 11:36 AM, Hans de Goede wrote: > Hi Samual, et al, Hi Hans, > > In > http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd > > you write: "This compute support has been tested by > Pierre Moreau and myself with some compute kernels." > > Can you provide testing instructions (and the

On 11/30/2015 02:27 PM, Hans de Goede wrote: > Hi, > > On 26-11-15 13:52, Samuel Pitoiset wrote: > > <snip> > >>> I do not have a GK106, I've a GK208, and IIRC that one is known to not >>> work, >>> I guess I can give it a try. >> >> Compute support is not supported on GK110+, yeah... >> >> If you provide me a MMT trace

A few things that stand out: 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) wtf is that 0x0000000000000 thing doing there? Was it a %rX which got constant-folded into 0? That indirectness should have then been removed... that said, the final encoding looks fine. I believe that kepler has this launch descriptor thing too... is that being set correctly? Please generate a mmt trace, and we can