On Tue, Jan 26, 2016 at 9:48 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Tue, Jan 26, 2016 at 3:23 PM, Marek Olšák <mar...@gmail.com> wrote: >> On Tue, Jan 26, 2016 at 3:12 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>> On Tue, Jan 26, 2016 at 8:57 AM, Marek Olšák <mar...@gmail.com> wrote: >>>> On Tue, Jan 26, 2016 at 2:25 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>>>> I'd be fine with a new TGSI_FILE_MEMORY which provided options for >>>>> shared, global, and local(/private?) memory. I believe the old >>>>> TGSI_FILE_RESOURCE had support for these in a hacky way, this would be >>>>> the clean way of doing it. >>>> >>>> I think they mean: >>>> global = global shared memory >>>> local = shared within a thread group (GL "shared memory") >>>> private = ??? >>> >>> memory that is local to a thread. >>> >>>> >>>> ureg_DECL_local_temporary seems like a good match. I'd prefer to have >>>> a separate file though. >>>> >>>> Shared memory is the same as TEMPs, except that they are TEMPs shared >>>> within a thread group. >>> >>> It's much more of a memory area than a TEMP area though. TEMP's imply >>> 16-byte wide stride for indirect indexing, etc -- not easy to work >>> with. >> >> Yeah, TGSI implies that. If you want just loads, stores, and atomics >> without declarations, you can add TGSI_FILE_SHARED. If drivers get >> instructions with TGSI_FILE_SHARED in the resource operand, they can >> just assume it's a load/store/atomic on the shared memory. For >> example: >> >> LOAD TEMP[0], SHARED, address >> >> Note that I deliberately didn't type "SHARED[0]" to show that the >> index should be ignored. >> >> In order to prevent confusion, please try to avoid using the word >> "memory" without the word "shared", because shared memory is not a >> typical memory resource. It's actually closer to registers in my >> opinion. > > Hm... well on NVIDIA hardware it's accessed the same as any other > memory area, like global memory, local memory, or constbufs. Same > types of opcodes too... loads + stores. And GLSL/OpenCL want to be > able to perform atomic operations on it too. Feels a lot more like > memory to me than registers. But of course what are registers but > super-mega-fast memory :) > > Sicne we eventually want to allow OpenCL TGSI to work, and from the > looks of it, OpenCL *really* wants to just be able to pass in any > number of pointers it feels like, and not be limited to N resources, > we'll also need global and local (or private, as OpenCL calls it), in > addition to shared. > > So I think a TGSI_FILE_MEMORY file would make sense, where you could > specify in the declaration whether that specific one refers to > global/shared/local somehow.
Can you give me a TGSI example how it should look like? Thanks, Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
