search for: destmask

...ling postfix would be honored and when storing to y (the only component set in the dest-mask) the x component at address (TEMP[0].x) would be loaded, rather then the y component at (TEMP[0].y) Note that another approach would be to not increment the address by a 32 bit word for skipped (not set in destmask) components. The way I see it either: 1) We see that LOAD does not deal with vectors, but with flat memory, in which case skipping 4 bytes because x is not set in the destmask does not make sense, as that is a vector thing todo. 2) LOAD is vector layout aware in which case supporting swizzling m...

...ng to y (the only component set in the dest-mask) >> the x component at address (TEMP[0].x) would be loaded, rather then the >> y component at (TEMP[0].y) >> >> Note that another approach would be to not increment the address by >> a 32 bit word for skipped (not set in destmask) components. >> >> The way I see it either: >> >> 1) We see that LOAD does not deal with vectors, but with flat memory, >> in which case skipping 4 bytes because x is not set in the destmask >> does not make sense, as that is a vector thing todo. >> >&gt...

...nored and when storing to y (the only component set in the dest-mask) > the x component at address (TEMP[0].x) would be loaded, rather then the > y component at (TEMP[0].y) > > Note that another approach would be to not increment the address by > a 32 bit word for skipped (not set in destmask) components. > > The way I see it either: > > 1) We see that LOAD does not deal with vectors, but with flat memory, > in which case skipping 4 bytes because x is not set in the destmask > does not make sense, as that is a vector thing todo. > > 2) LOAD is vector layout aware...

...mponent set in the dest-mask) >>> the x component at address (TEMP[0].x) would be loaded, rather then the >>> y component at (TEMP[0].y) >>> >>> Note that another approach would be to not increment the address by >>> a 32 bit word for skipped (not set in destmask) components. >>> >>> The way I see it either: >>> >>> 1) We see that LOAD does not deal with vectors, but with flat memory, >>> in which case skipping 4 bytes because x is not set in the destmask >>> does not make sense, as that is a vector thin...

Hi, On 07-04-16 15:58, Ilia Mirkin wrote: > That's wrong. It used to work with the old RES[] code and if one cannot specify a source swizzle, then how can I do something like LOAD TEMP[0].y, MEMORY[0], address And get the data at absolute global memory address "address" into TEMP[0].y ? This is a must-have for llvm to be able to generate working TGSI code, I do not see any