search for: swizzled

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

Hi, On 08-04-16 17:02, Ilia Mirkin wrote: > On Fri, Apr 8, 2016 at 5:27 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> 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

...d367%40mail.gmail.com&forum_name=mesa3d-dev . Here are the findings from running it. The result is that our miptree layout code is partially broken, and overly complex. In particular: 1. 3D textures are broken because they are not laid out like cube maps, but first by level and then by face 2. Swizzled 3D texture are all 3 texture coordinates swizzled together 3. Cube maps have their faces 128 byte aligned, not only 64 like in my patch or unaligned like without it (not applied IIRC). 4. Swizzled 2D/3D/cube textures don't have any gaps, except for cube map face alignment. The current code cont...

On Fri, Apr 8, 2016 at 5:27 AM, Hans de Goede <hdegoede at redhat.com> wrote: > 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

Hello, everyone: I am writing a compiler for a programmable graphics hardware. Each registers of the hardware has four channels, namely 'r', 'b', 'g', 'a', and each channel is a 32-bit floating point. It's similar to the high and low 8-bit of an x86 16-bit general purpose register "AX" can be individually referenced as "AH" and

...t; that it will > > (a) fetch 4 values from the coordinates provided (4 sequential dwords > from src1.x in the case of buffer/memory, RGBA colors from src1.xyz in > the case of images) > (b) swizzle them according to the swizzle on the MEMORY/BUFFER/IMAGE argument > (c) store that swizzled result into the destination based on the writemask > > That would sound reasonable to me, and if I understand correctly, is > option 2 of your proposal. Yes that is option 2, and is basically what the patch which started this thread does. So that would work for me :) > We'd need s...

Thanks for the last info it was truely helpful. Anyways, I'm currently trying to implement 3D textures into yuzu, as far as I know they are twiddled in a different manner to 2D textures. Could one of you guys point me in the right direction? I've been meddling around: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv50/nv50_tex.c but I can't see where the

Hi, On 22-04-16 09:08, Marek Olšák wrote: > On Thu, Apr 21, 2016 at 7:04 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> [+radeon folk] >> >> Marek, Nicolai, Bas - please have a look at the doc change and let us >> know if you think this will cause a problem for radeon. >> >> Hans is solving the issue that he wants to swizzle the data loaded

...st > @@ -2288,6 +2288,9 @@ Resource Access Opcodes > texture arrays and 2D textures. address.w is always > ignored. > > + A swizzle suffix may be added to the resource argument > + this will cause the resource data to be swizzled accordingly. > + > .. opcode:: STORE - Write data to a shader resource > > Syntax: ``STORE resource, address, src`` > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp > index e2db731...

...AD will now work (logically) is that it will (a) fetch 4 values from the coordinates provided (4 sequential dwords from src1.x in the case of buffer/memory, RGBA colors from src1.xyz in the case of images) (b) swizzle them according to the swizzle on the MEMORY/BUFFER/IMAGE argument (c) store that swizzled result into the destination based on the writemask That would sound reasonable to me, and if I understand correctly, is option 2 of your proposal. We'd need some docs updates and buy-in from the other gallium driver developers. STORE remains unchanged, as the MEMORY/etc is in the destination,...

...>> (a) fetch 4 values from the coordinates provided (4 sequential dwords >> from src1.x in the case of buffer/memory, RGBA colors from src1.xyz in >> the case of images) >> (b) swizzle them according to the swizzle on the MEMORY/BUFFER/IMAGE argument >> (c) store that swizzled result into the destination based on the writemask >> >> That would sound reasonable to me, and if I understand correctly, is >> option 2 of your proposal. > > Yes that is option 2, and is basically what the patch which started this > thread does. So that would work for m...

...ty and instead it got >>> drawn all on a line. If it were merely a stride problem, I'd expect to >>> see strips of the moon below and offset from one another. >>> >>> So... take a look at nv30_miptree_from_handle -- I wonder if it can >>> now receive swizzled textures where it couldn't before. >> >> >> Ok, that does go in the direction I am expecting the problem to be, >> but I'm afraid I'm going to need a bit more guidance, what exactly >> am I looking for in that function / which "knobs" should I try...

Hey, as some of you may know we're in process of experimenting with LLVM in Gallium3D (Mesa's new driver model), where LLVM would be used both in the software only (by just JIT executing shaders) and hardware (drivers will implement LLVM code-generators) cases. While the software only case is pretty straight forward I just realized I missed something in my initial evaluation. That

The llvm TGSI backend does things like: LOAD TEMP[0].y, MEMORY[0].xxxx, TEMP[0].x Expecting the data at address TEMP[0].x to get loaded to TEMP[0].y. Before this commit the data at TEMP[0].x + 4 would be loaded instead. This commit fixes this. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 8 ++++++-- 1 file changed,

On Thu, 27 Sep 2007, Zack Rusin wrote: > as some of you may know we're in process of experimenting with LLVM in > Gallium3D (Mesa's new driver model), where LLVM would be used both in the > software only (by just JIT executing shaders) and hardware (drivers will > implement LLVM code-generators) cases. Yep, nifty! > That is graphics hardware (basically every single

Each register is a 4-component (namely, r, g, b, a) vector register. They are actually defined as llvm packed [4xfloat]. The instruction: add_sat r0.a, r1_bias.xxyy, r3_x2.zzzz Explaination: '.a' is a writemask. only the specified component will be update '.xxyy' and '.zzzz' are swizzle masks, specify the component permutation, simliar to the Intel SSE permutation

...That means that it expected some locality and instead it got > drawn all on a line. If it were merely a stride problem, I'd expect to > see strips of the moon below and offset from one another. > > So... take a look at nv30_miptree_from_handle -- I wonder if it can > now receive swizzled textures where it couldn't before. Ok, that does go in the direction I am expecting the problem to be, but I'm afraid I'm going to need a bit more guidance, what exactly am I looking for in that function / which "knobs" should I try to vary / play with to maybe fix this ? Re...

...c/gallium/docs/source/tgsi.rst @@ -2288,6 +2288,9 @@ Resource Access Opcodes texture arrays and 2D textures. address.w is always ignored. + A swizzle suffix may be added to the resource argument + this will cause the resource data to be swizzled accordingly. + .. opcode:: STORE - Write data to a shader resource Syntax: ``STORE resource, address, src`` diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index e2db731..01df4f3 100644 --- a/src/g...

On Fri, Apr 22, 2016 at 9:23 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > On 22-04-16 09:08, Marek Olšák wrote: >> >> On Thu, Apr 21, 2016 at 7:04 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >>> >>> [+radeon folk] >>> >>> Marek, Nicolai, Bas - please have a look at the doc change and let us >>> know

Dear all: To write a compiler for Microsoft Direct3D shaders from our hardware, I have a program which translates the Direct3D shader assembly to LLVM assembly. I added several intrinsics for this purpose. It's a vector ISA and has some special instructions like: * rcp (reciprocal) * frc (the fractional portion of each input component) * dp4 (dot product) * exp (exponential) * max, min These