search for: store64

...t;> >> LOAD TEMP[0].x, MEMORY[1], TEMP[0].yyyy >> >> Correct ? And the shared mem to will take shared virtual memory >> addresses, just like global takes global virtual memory >> addresses ? > > That's how I see it. Good. > You may have to add LOAD64/STORE64 for 64-bit > addresses though. Or we could decree that all addressing on global > memory shall be 64-bit (and thus read the .xy components of the > address source). I would prefer to keep LOAD / STORE semantics the same as with other LOAD / STORE -s to / from 1d buffers. I think that in...

On 11:43 AM - Feb 23 2016, Hans de Goede wrote: > Hi, > [snip] > > >You may have to add LOAD64/STORE64 for 64-bit > >addresses though. Or we could decree that all addressing on global > >memory shall be 64-bit (and thus read the .xy components of the > >address source). > > I would prefer to keep LOAD / STORE semantics the same as with > other LOAD / STORE -s to / from 1d...

Hi, On 22-02-16 17:13, Ilia Mirkin wrote: > On Mon, Feb 22, 2016 at 11:00 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede <hdegoede at redhat.com> wrote: >>>> But assuming I'm right, what I'm proposing is that instead of passing >>>> the input in as a global buffer, to instead pass it in as a

...extensions to a MIPS like architecture: 1.) double store : Ri,Ri+1 are stored to the memory at address specified by (Rj). Here the instruction encoding includes only 'i' but it implicitly uses also Ri+1. I can define a special intrinsic for this in "C" such as store64(int v1,int v2,int *address), but then I run into problems with the register allocation as I need to tell it that I want to use Ri and Ri+1 an not just any general pair of registers .... 2.) Just any kind of instruction with register update semantics. like for simplicity sake suppose I have...

...r 3d buffers though. I foresee the llvm backend > eventually getting a 64 bit mode where it will use 64 bits for all > pointers and use something like a LOAD64 opcode to indicate that > the indexes (which it effectively uses as addresses / pointers) > are 64 bit wide. Well, this LOAD64/STORE64 would just only be defined for MEMORY[] src/dest, so you don't need to worry about 3d or anything like that. I believe this is a good solution to the problem. > >> Also it would be highly preferable to avoid using GLOBAL at all in the >> first place, and just use BUFFER[] or IMA...

...ng from the shared mem at offset TEMP[0].y: > > LOAD TEMP[0].x, MEMORY[1], TEMP[0].yyyy > > Correct ? And the shared mem to will take shared virtual memory > addresses, just like global takes global virtual memory > addresses ? That's how I see it. You may have to add LOAD64/STORE64 for 64-bit addresses though. Or we could decree that all addressing on global memory shall be 64-bit (and thus read the .xy components of the address source). > >> Another way of looking at it is that instead of having the hacky >> RES[12345] being hardcoded to mean something specia...

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

...resee the llvm backend >> eventually getting a 64 bit mode where it will use 64 bits for all >> pointers and use something like a LOAD64 opcode to indicate that >> the indexes (which it effectively uses as addresses / pointers) >> are 64 bit wide. > > Well, this LOAD64/STORE64 would just only be defined for MEMORY[] > src/dest, so you don't need to worry about 3d or anything like that. I > believe this is a good solution to the problem. Right for MEMORY this will work fine. I've no clue yet how images will work with OpenCL though, hopefully we can avoid th...

...gt;>> eventually getting a 64 bit mode where it will use 64 bits for all >>> pointers and use something like a LOAD64 opcode to indicate that >>> the indexes (which it effectively uses as addresses / pointers) >>> are 64 bit wide. >> >> Well, this LOAD64/STORE64 would just only be defined for MEMORY[] >> src/dest, so you don't need to worry about 3d or anything like that. I >> believe this is a good solution to the problem. > > Right for MEMORY this will work fine. I've no clue yet how images will > work with OpenCL though, hop...