right,
so in d_add micro code we could have:
tgsi_double dsrc0, dsrc1, ddst;
src0.msb = src0->f[0];
src0.lsb = src0->f[1];
src1.msb = src1->f[0];
src2.lsb = src1->f[1];
ddst.reg = src0.reg + sr1.reg;
dst->f[0] = ddst.lsb;
dst->f[1] = ddst.msb;
and the tgsi_double would be something like:
union tgsi_double {
float lsb;
float msb;
double reg;
};
On Wed, Jan 6, 2010 at 7:56 PM, Zack Rusin <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
