search for: load64

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

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 /...

...o the buffer. So this means that currently we are limited to U32 since TEMP[#].x is only 32 bits wide. Internally 40 bits addresses can and should probably be used so that at least the different memory spaces each have the full 32 bits available. Note that we could fix this by adding some sort of LOAD64 opcode, which uses TEMP[#].x and TEMP[#].y as address for 1d buffers, I'm not sure how this would work for 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 indexe...

...eans that currently we are limited to U32 since TEMP[#].x is > only 32 bits wide. Internally 40 bits addresses can and should probably > be used so that at least the different memory spaces each have the full > 32 bits available. > > Note that we could fix this by adding some sort of LOAD64 opcode, which > uses TEMP[#].x and TEMP[#].y as address for 1d buffers, I'm not sure > how this would work for 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 indi...

...we are limited to U32 since TEMP[#].x is >> only 32 bits wide. Internally 40 bits addresses can and should probably >> be used so that at least the different memory spaces each have the full >> 32 bits available. >> >> Note that we could fix this by adding some sort of LOAD64 opcode, which >> uses TEMP[#].x and TEMP[#].y as address for 1d buffers, I'm not sure >> how this would work for 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 LOAD6...

...2 since TEMP[#].x is >>> only 32 bits wide. Internally 40 bits addresses can and should probably >>> be used so that at least the different memory spaces each have the full >>> 32 bits available. >>> >>> Note that we could fix this by adding some sort of LOAD64 opcode, which >>> uses TEMP[#].x and TEMP[#].y as address for 1d buffers, I'm not sure >>> how this would work for 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 someth...

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

...purpose register, to "and" and then move it into address register. Unfortunately, the register allocator crashes. Here's machine code: %reg1030 = - %reg1027, 1 %reg1031 = move %reg1030 %reg1032 = + %reg1031, -2 %reg1033 = move %reg1032 %ar1 = load64 %gr1<def>, %reg1033 and here's assertion: llc: LiveIntervals.cpp:507: void llvm::LiveIntervals::joinIntervals(): Assertion `rcA == rcB && "registers must be of the same class"' failed. (gdb) up 4 ..... (gdb) p *intA $1 = (llvm::LiveInterval &) @0x8064698: {reg...

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:

...something 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 somethin...

...a000: load61b ALLOC > READONLY CODE > ??? 0x7f73f21fb000->0x7f73f21fd000 at 0x078ba000: load62 ALLOC LOAD > READONLY HAS_CONTENTS > ??? 0x7f73f21fd000->0x7f73f21fe000 at 0x078bc000: load63 ALLOC LOAD > HAS_CONTENTS > ??? 0x7f73f24c2000->0x7f73f2835000 at 0x078bd000: load64 ALLOC LOAD > HAS_CONTENTS > ??? 0x7ffd0ddc5000->0x7ffd0dddb000 at 0x07c30000: load65 ALLOC LOAD > HAS_CONTENTS > ??? 0x7ffd0dde4000->0x7ffd0dde5000 at 0x07c46000: load66 ALLOC LOAD > READONLY CODE HAS_CONTENTS > ??? 0xffffffffff600000->0xffffffffff601000 at 0x07c470...

On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote: > Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek: > > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote: > > > On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: ... > > > 1. Do you have any idea what the imap process was doing at the time of the > > >

...0->0x7f73f1fc2000 at 0x078ba000: load61b ALLOC READONLY CODE 0x7f73f21fb000->0x7f73f21fd000 at 0x078ba000: load62 ALLOC LOAD READONLY HAS_CONTENTS 0x7f73f21fd000->0x7f73f21fe000 at 0x078bc000: load63 ALLOC LOAD HAS_CONTENTS 0x7f73f24c2000->0x7f73f2835000 at 0x078bd000: load64 ALLOC LOAD HAS_CONTENTS 0x7ffd0ddc5000->0x7ffd0dddb000 at 0x07c30000: load65 ALLOC LOAD HAS_CONTENTS 0x7ffd0dde4000->0x7ffd0dde5000 at 0x07c46000: load66 ALLOC LOAD READONLY CODE HAS_CONTENTS 0xffffffffff600000->0xffffffffff601000 at 0x07c47000: load67 ALLOC LOAD READONL...