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 <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