José Fonseca pisze: > On Thu, 2009-07-30 at 02:52 -0700, Micha?? Kr??l wrote: > >> Module: Mesa >> Branch: master >> Commit: b724dd28e24ec1c38af1082f5e16cd9a12d1653d >> URL: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=b724dd28e24ec1c38af1082f5e16cd9a12d1653d >> >> Author: Michal Krol <[email protected]> >> Date: Thu Jul 30 10:12:09 2009 +0200 >> >> tgsi: Document LOOP/ENDLOOP instruction operation. >> >> --- >> >> .../auxiliary/tgsi/tgsi-instruction-set.txt | 20 >> ++++++++++++++++++-- >> 1 files changed, 18 insertions(+), 2 deletions(-) >> >> diff --git a/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt >> b/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt >> index a3f4947..5f88cc2 100644 >> --- a/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt >> +++ b/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt >> @@ -667,7 +667,16 @@ TGSI Instruction Specification >> >> 1.9.8 LOOP - Loop >> >> - TBD >> + dst.x = floor(src.x) >> + dst.y = floor(src.y) >> + dst.z = floor(src.z) >> + >> + if (dst.y <= 0) >> + pc = [matching ENDLOOP] + 1 >> + endif >> + >> + Note: The destination must be a loop register. >> + The source must be a constant register. >> >> >> 1.9.9 REP - Repeat >> @@ -687,7 +696,14 @@ TGSI Instruction Specification >> >> 1.9.12 ENDLOOP - End Loop >> >> - TBD >> + dst.x = dst.x + dst.z >> + dst.y = dst.y - 1.0 >> + >> + if (dst.y > 0) >> + pc = [matching LOOP instruction] + 1 >> + endif >> + >> + Note: The destination must be a loop register. >> > > Michal, > > Does ENDLOOP (now known as as ENDFOR) really benefits from a destination > register? There is none in > http://msdn.microsoft.com/en-us/library/ms800316.aspx . It seems that a > destination register here only adds redundancy/inconsistency to the > shader. > > Yes, this is an oversight -- we should indicate in BGNFOR description that the destination register becomes the current loop register and it is going to be used in ENDFOR. I am going to fix that as soon as I get my hands on an iegd dev environment. Thanks.
> Also, I don't think there is any point in describing what's in dst.x, > dst.y, dst.z, AFAICT, D3D LOOP variables can only be used for relative > addressing, and cannot have swizzles, i.e., are scalar, so they should > be described as such. > > I don't remember if it has been documented, but the LOOP register access is restricted to .x component read as an indirect register in all instructions except BGNFOR. We document the .y and .z components of the source register for BGNFOR so that both the state tracker and the driver have to agree on how to pack the constants (it's slightly different for GL and D3D). Specifying that for the LOOP register is just a consequence of that and doing otherwise would introduce unpleasant precedences -- having a scalar register for loop indexing and having magic, opaque registers for loop counting. As long as we allow access only to the .x component, that should not matter. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
