Re: Doom3 benchmarks.
Aapo Tahkola wrote: On Sun, 13 Aug 2006 02:17:40 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Roland Scheidegger wrote: Rune Petersen wrote: Roland Scheidegger wrote: 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? I've had been looking into this, and the vertex shader is supplying the position to the fragment shader as a texcoord, the only apparent difference in shader setup between a position and a real texcoord, is a real texcoord is supplied as input for the vertex shader. I would really like to capture the vertex program of program/fp/tri-depth and the fglrx driver. But I'm betting the vertex shader is capable of writing to a texcoord. All I need is a safe way for the vertex shader code to know if the fragment shader needs the position. Any help with this would be great. Bug #8056 patch can do this. Take a look at r300_select_vertex_shader(). Thank you. Getting wpos to the fragment shader is not too reliable atm, but something strange: Only x y are valid for hpos in the vertex shader.. z = 0 w = 1 as you would expect if they weren't set... Am I missing something obvious? Rune Petersen - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 benchmarks.
On Wed, 30 Aug 2006 20:50:16 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sun, 13 Aug 2006 02:17:40 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Roland Scheidegger wrote: 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? I've had been looking into this, and the vertex shader is supplying the position to the fragment shader as a texcoord, the only apparent difference in shader setup between a position and a real texcoord, is a real texcoord is supplied as input for the vertex shader. I would really like to capture the vertex program of program/fp/tri-depth and the fglrx driver. But I'm betting the vertex shader is capable of writing to a texcoord. All I need is a safe way for the vertex shader code to know if the fragment shader needs the position. Any help with this would be great. Bug #8056 patch can do this. Take a look at r300_select_vertex_shader(). Thank you. About your patch: Can't reproduce your result with gearbox [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4e28 sz=1) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed It should be same as t-offset when the cube is drawn. subtexrate: The result is not too reliable with this, but at least it doesn't crash =) There looks to be a mess up of src dest. sometimes the src is the teapot other times the root window. doSubRect cases will definitely fail. It would seem as if the clip rects would be relative to something else. Odd that it never crashes with default clip rects... -- Aapo Tahkola - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 benchmarks.
On Sun, 13 Aug 2006 02:17:40 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Roland Scheidegger wrote: 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? I've had been looking into this, and the vertex shader is supplying the position to the fragment shader as a texcoord, the only apparent difference in shader setup between a position and a real texcoord, is a real texcoord is supplied as input for the vertex shader. I would really like to capture the vertex program of program/fp/tri-depth and the fglrx driver. But I'm betting the vertex shader is capable of writing to a texcoord. All I need is a safe way for the vertex shader code to know if the fragment shader needs the position. Any help with this would be great. Bug #8056 patch can do this. Take a look at r300_select_vertex_shader(). -- Aapo Tahkola - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 benchmarks.
Roland Scheidegger wrote: 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? I've had been looking into this, and the vertex shader is supplying the position to the fragment shader as a texcoord, the only apparent difference in shader setup between a position and a real texcoord, is a real texcoord is supplied as input for the vertex shader. I would really like to capture the vertex program of program/fp/tri-depth and the fglrx driver. But I'm betting the vertex shader is capable of writing to a texcoord. All I need is a safe way for the vertex shader code to know if the fragment shader needs the position. Any help with this would be great. Rune Petsen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Doom3 benchmarks.
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.) 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. WIth the fglrx driver: x700 + fglrx (with arb renderer) - 4.4 x700 + fglrx (with r200 renderer) - 28.7 9000 + fglrx (with arb renderer) - 3.9 9000 + fglrx (with r200 renderer) - 16.4 Adam - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 benchmarks.
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? 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... WIth the fglrx driver: x700 + fglrx (with arb renderer) - 4.4 x700 + fglrx (with r200 renderer) - 28.7 9000 + fglrx (with arb renderer) - 3.9 9000 + fglrx (with r200 renderer) - 16.4 Looks like fglrx has some performance problems too... I can't remember it being that slow with the arb path, what driver version is this? arb path should always be faster quite a bit as the scene complexity is lower (no bump maps etc. though you can switch them off for the other render paths too). 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 benchmarks.
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. 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. Rune Petersen - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 benchmarks.
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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 benchmarks.
On Sun, 06 Aug 2006 22:57:21 +0200 Rune Petersen [EMAIL PROTECTED] 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. 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. Light bloom usually need render to texture type of functionality which in turn needs accelerated CopyTexSubImage2D or ReadPixels. These are implemented using the span functions currently. CopyTexSubImage2D cannot be accelerated because we need to update copy of the texture kept in system memory(for raster fallbacks). Secondly, normal bitblt cannot be used to perform these operations since it doesn't support necessary pitches and offsets - x/y tricks used in r300_texmem.c will not work as r300 tends to think that micro tile starts at given offset. dxtn happens to be broken because we cant do micro tiling on normal textures. I tried implementing blits using 3d engine and textures but I ran into trouble with clip rects so I had to give up. Buffer swaps work fine with it though. -- Aapo Tahkola - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
