Am 18.03.2013 15:12, schrieb Roland Scheidegger:
Am 18.03.2013 14:36, schrieb Christian König:
From: Christian König <christian.koe...@amd.com>
To further improve the optimization of source and destination
indirect addressing we need the ability to store a reference
to the declaration of the addressed operands.
Since most of the fields in tgsi_src_register doesn't apply for
an indirect addressing operand replace it with a separate
tgsi_ind_register structure and so make room for extra information.
v2: rename Declaration to ArrayID, put the ArrayID into () instead of []
Signed-off-by: Christian König <christian.koe...@amd.com>
---
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index cd140de..be99ae0 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -62,6 +62,7 @@ struct ureg_src
int IndirectIndex : 16; /* SINT */
int DimensionIndex : 16; /* SINT */
int DimIndIndex : 16; /* SINT */
+ unsigned ArrayID : 10; /* UINT */
};
/* Very similar to a tgsi_dst_register, removing unsupported fields
@@ -84,6 +85,7 @@ struct ureg_dst
int Index : 16; /* SINT */
int IndirectIndex : 16; /* SINT */
int IndirectSwizzle : 2; /* TGSI_SWIZZLE_ */
+ unsigned ArrayID : 10; /* UINT */
};
Not sure I like the ordering of these fields...
In any case it would be difficult (but possible) to make ureg_dst fit
into a 64bit struct.
FWIW (but that's not your fault) IndirectSwizzle really ought to be a
unsigned too, looks to me like this misdeclaration really could cause
bugs somewhere.
Noticed the strange declaration of IndirectSwizzle also, and I have it
on my todo list (as very low priority) to figure out if this causes any
problems or not, but as far as I have seen we currently only use
indirect addressing with swizzle X, and then it probably won't hurt.
Regarding putting everything into a 64bit struct, well I'm pretty sure
that I don't like that idea. Bitfields might make sense for TGSI tokens,
but for ureg_src/ureg_dst saving some bytes of memory probably doesn't
judge the extra overhead related to them.
Christian.
Roland
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
