Hi,
so basically instead of add double in exec_channel it would be?
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index f43233b..3c90677 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -380,6 +380,33 @@ micro_trunc(union tgsi_exec_channel *dst,
dst->f[3] = (float)(int)src->f[3];
}
+static void
+micro_movd(union tgsi_exec_channel *dst,
+ const union tgsi_exec_channel *src)
+{
+ union tgsi_double dsrc, ddst;
+
+ TGSI_CREATE_DOUBLE(dsrc, src);
+
+ ddst = dsrc; /* we do not need it */
+ TGSI_DOUBLE_TO_EXECCHANELL(dst, ddst);
+}
+
+static void
+micro_ddiv(union tgsi_exec_channel *dst,
+ const union tgsi_exec_channel *src0,
+ const union tgsi_exec_channel *src1)
+{
+ union tgsi_double dsrc0, dsrc1, ddst;
+
+ TGSI_CREATE_DOUBLE(dsrc0, src0);
+ TGSI_CREATE_DOUBLE(dsrc1, src1);
+
+ if (dsrc1.reg != 0) {
+ ddst.reg = dsrc0.reg/dsrc1.reg;
+ TGSI_DOUBLE_TO_EXECCHANELL(dst, ddst);
+ }
+}
#define CHAN_X 0
#define CHAN_Y 1
@@ -3491,6 +3518,14 @@ exec_instruction(
exec_vector_binary(mach, inst, micro_usne, TGSI_EXEC_DATA_UINT,
TGSI_EXEC_DATA_UINT);
break;
+ case TGSI_OPCODE_MOVD:
+ exec_vector_unary(mach, inst, micro_movd,
TGSI_EXEC_DATA_DOUBLE, TGSI_EXEC_DATA_DOUBLE);
+ break;
+
+ case TGSI_OPCODE_DDIV:
+ exec_vector_binary(mach, inst, micro_ddiv,
TGSI_EXEC_DATA_DOUBLE, TGSI_EXEC_DATA_DOUBLE);
+ break;
+
case TGSI_OPCODE_SWITCH:
exec_switch(mach, inst);
break;
@@ -3503,7 +3538,8 @@ exec_instruction(
exec_default(mach);
break;
- case TGSI_OPCODE_ENDSWITCH:
+
+ case TGSI_OPCODE_ENDSWITCH:
exec_endswitch(mach);
break;
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h
b/src/gallium/auxiliary/tgsi/tgsi_exec.h
index aa3a98d..7da44d9 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
@@ -50,6 +50,18 @@ union tgsi_exec_channel
unsigned u[QUAD_SIZE];
};
+union tgsi_double
+{
+ float lsb;
+ float msb;
+ double reg;
+};
+
+#define TGSI_CREATE_DOUBLE(dsrc, src) dsrc.lsb = src->f[0], \
+ dsrc.msb = src->f[1]
+
+#define TGSI_DOUBLE_TO_EXECCHANELL(channel, dvalue) channel->f[0] =
dvalue.lsb, \
+ channel->f[1] = dvalue.msb
/**
* A vector[RGBA] of channels[4 pixels]
*/
diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c
b/src/gallium/auxiliary/tgsi/tgsi_info.c
index de0e09c..acbd7dc 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_info.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
@@ -171,6 +171,8 @@ static const struct tgsi_opcode_info
opcode_info[TGSI_OPCODE_LAST] =
{ 1, 2, 0, 0, 0, 0, "USGE", TGSI_OPCODE_USGE },
{ 1, 2, 0, 0, 0, 0, "USHR", TGSI_OPCODE_USHR },
{ 1, 2, 0, 0, 0, 0, "USLT", TGSI_OPCODE_USLT },
+ { 1, 1, 0, 0, 0, 0, "MOVD", TGSI_OPCODE_MOVD },
+ { 1, 2, 0, 0, 0, 0, "DDIV", TGSI_OPCODE_DDIV },
{ 1, 2, 0, 0, 0, 0, "USNE", TGSI_OPCODE_USNE },
{ 0, 1, 0, 0, 0, 0, "SWITCH", TGSI_OPCODE_SWITCH },
{ 0, 1, 0, 0, 0, 0, "CASE", TGSI_OPCODE_CASE },
diff --git a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
index e4af15c..f441636 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
@@ -167,6 +167,8 @@ OP12(USGE)
OP12(USHR)
OP12(USLT)
OP12(USNE)
+OP11(MOVD)
+OP12(DDIV)
#undef OP00
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index 550e2ab..939d02f 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -319,7 +319,10 @@ struct tgsi_property_data {
#define TGSI_OPCODE_CASE 142
#define TGSI_OPCODE_DEFAULT 143
#define TGSI_OPCODE_ENDSWITCH 144
-#define TGSI_OPCODE_LAST 145
+
+#define TGSI_OPCODE_MOVD 145
+#define TGSI_OPCODE_DDIV 146
+#define TGSI_OPCODE_LAST 147
#define TGSI_SAT_NONE 0 /* do not saturate */
#define TGSI_SAT_ZERO_ONE 1 /* clamp to [0,1] */
On Wed, Jan 6, 2010 at 7:56 PM, Zack Rusin <za...@vmware.com> wrote:
> On Wednesday 06 January 2010 14:56:35 Igor Oliveira wrote:
>> Hi,
>>
>> the patches add support to double opcodes in gallium/tgsi.
>> It just implement some opcodes i like to know if someone has
>> suggestion about the patches.
>
> Hi Igor, first of all this should probably go into a feature branch because
> it'll be a bit of work before it's usable.
> The patches that you've proposed are unlikely what we'll want for double's.
> Keith, Michal and I discussed this on the phone a few days back and the
> biggest issue with doubles is that unlike the switch between the integers and
> floats they actually need bigger registers to accomodate them. Given that the
> registers in TGSI are untyped and its up to instructions to define the type it
> becomes hard for drivers to figure out the size of the registers beforehand.
> The solution that I personally like and what seems to becoming the facto
> standard when dealing with double support is having double precision values
> represented by a pair of registers. Outputs are
> either the pair yx or to the pair wz, where the msb is stored in y/w. For
> example:
> Idata 3.0 => (0x4008000000000000) in register r looks like:
> r.w = 0x40080000 ;high dword
> r.z = 0x00000000 ;low dword
> Or:
> r.y = 0x40080000 ;high dword
> r.x = 0x00000000 ;low dword
> All source double inputs must be in xy (after swizzle operations). For
> example:
> d_add r1.xy, r2.xy, r2.xy
> Or
> d_add r1.zw, r2.xy, r2.xy
> Each computes twice the value in r2.xy, and places the result in either xy or
> zw.
> This assures that the register size stays constant. Of course the instruction
> semantics are different to the typical 4-component wide TGSI instructions, but
> that, I think, is a lot less of an issue.
>
> z
>
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
