Markus Amsler wrote: > Oliver McFadden wrote: >> Hmm, this is interesting... Have you profiled with some other programs? My >> concern is that this might make a particular game faster, but other games >> slower. >> > No I haven't. I'll try out other programs. > >> If it's making everything faster, then we're probably doing something >> inefficient and that code can be killed. >> > I thought this optimization was there because otherwise some shaders > wouldn't fit into the hardware. 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...
Roland ------------------------------------------------------------------------- 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
