On Tue, 06 May 2008 17:02:10 +0200 Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> Yes, that's the primary reason. But it's in any case not obvious why > more phases would be faster. > Though I've got some vague theory here. When I did some performance > measurements on rv250 some years ago, I remember that basically you got > 1 alu instruction for free for each texturing "instruction" (so if there > were 4 texturing instructions performance was exactly the same if there > were 1-4 alu instructions). I never ran tests to see how this behaves > when using more than 1 phase (well rv250 has only 2 anyway), but > basically phases should still work the same on r300 (obviously, with > more phases, more alu / tex slots). It might be possible that the chip > only can schedule tex/alu instructions together (so it'll execute alu > instructions from one pixel quad while executing texture fetches on > another), in which case if you have less alu instructions (or texture > instructions) those instruction slots are basically wasted. If that > theory would be true, it would be best to have the same amount of > texture instructions and alu instructions per phase (or possibly more > alu instructions than texture instructions, since trilinear probably > takes 2 cycles and aniso might use even more, whereas all alu > instructions are single-cycle). Just a guess though... > That sounds like a correct explication, as stalling gpu for waiting or not for texture likely would not show massive performance improvement. So my thinking of gpu being stall while texture are fetch is likely wrong. So r3xx/r4xx likely have some kind of scheduler, save pixel stack frame and restore it when you go back to the first quad. I guess looking through old review should give us some clue. If this is the case then the key is not put as much alu instructions as possible in a node but to find a good balance btw the number of texture fetches instructions and the number of alu intructions in a node. Cheers, Jerome Glisse ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
