Rune Petersen wrote: > Roland Scheidegger wrote: >> Adam K Kirchhoff wrote: >>> Just thought I'd post some updated benchmarks of Doom3. These >>> were all run with the first timedemo at 640x480, and (for the >>> open source drivers) with ColorTiling turned on in the xorg.conf >>> file. I'll list all tests with the open source drivers first: >>> >>> x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point >>> in testing it with the r200 or arb2 renderers at the moment.) >> What's the problem with arb2? > > fragment.position input is not implemented yet. fglrx driver parses > it from VP to FP via a texcoord route. I've been hitting my head on > this for some time. Only got as far as only getting a soft lockup > which isn't very useful. That kinda makes sense. On r200 you could already pass vertex data to the fragment registers (but you couldn't use position as input), so the data was interpolated by the texcoord interpolator but texture lookup was disabled (see the ATI_fs spec / r200 dri implementation). At first sight looks like a similar mechanism might be used by r300 I guess, interpolating position or texcoords isn't too different is it?
>> The r300 driver does not currently support the r200 render path >> (and I doubt it will in the future - there's just not enough >> interest in supporting ATI_fs on r300 which is not widely used). >> >>> 9000 (with arb renderer) - 15.9 9000 (with r200 renderer) - 15.4 >>> >>> The huge performance increase I get by using an r200 card is >>> pretty consistent with what I see in other games. >> There seems to be some performance problems with the r300 driver. I >> don't think anyone knows what's going on but I could be wrong... > > I have seen some strange slowdowns not caused bu any apparent > fallback (Nexiuz w/bloom) though I could have missed a fallback path. It's strange the (simple) arb path of doom3 is slow. btw the "real" reference point would probably be drivers from another OS, they are often a lot faster (and I'm really wondering where ati gets the additional performance there at least for r200). Those drivers might include things which we don't really want to implement but I don't think all of the performance difference is caused by that. Roland ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
