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
Re: Quake4 benchmarks
http://www.nuclearelephant.com/papers/s3tc.html http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html And I has problems with one ATI mobile r300 and Xorg 6.8.2 from Fedora 4, and now with Xorg 7.0 it works quite right, and I try to see what is the trick and appears to me not just disabling dri but disable ACCEL render! . On Tue, 2006-05-23 at 19:18 -0400, Adam K Kirchhoff wrote: FYI, I downloaded the hwspirit timedemo for quake4 yesterday and decided to compare the framerate between the fglrx, r200, and xig drivers with my Radeon 9000: 9000 - xig - 14.7 9000 - fgl - 11.3 9000 - xorg - 16.2 Today I decided to give it a shot with my 9600. The fglrx drivers gave me 16.8 FPS, and the r300 drivers gave me this: http://68.44.156.246/quake4-screenshot.png As you can see, everything is quite shiny (but not quite as washed out as the screenshot shows... I had to brighten it a little to make it visible). This is with both page flipping and color tiling enabled (though I tried without page flipping and got the same results). And I have the libtxc_dxtn library compiled and installed. If I remove that library, quake4 completely refuses to start: ..using GL_ARB_multitexture ...using GL_ARB_texture_env_combine ...using GL_ARB_texture_cube_map ...using GL_ARB_texture_env_dot3 ...using GL_ARB_texture_env_add X..GL_ARB_texture_non_power_of_two not found ...using GL_NV_blend_square ...using GL_ARB_texture_compression X..GL_EXT_texture_compression_s3tc not found signal caught: Segmentation fault si_code 1 Trying to exit gracefully.. Any ideas? --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Quake4 benchmarks
FYI, I downloaded the hwspirit timedemo for quake4 yesterday and decided to compare the framerate between the fglrx, r200, and xig drivers with my Radeon 9000: 9000 - xig - 14.7 9000 - fgl - 11.3 9000 - xorg - 16.2 Today I decided to give it a shot with my 9600. The fglrx drivers gave me 16.8 FPS, and the r300 drivers gave me this: http://68.44.156.246/quake4-screenshot.png As you can see, everything is quite shiny (but not quite as washed out as the screenshot shows... I had to brighten it a little to make it visible). This is with both page flipping and color tiling enabled (though I tried without page flipping and got the same results). And I have the libtxc_dxtn library compiled and installed. If I remove that library, quake4 completely refuses to start: ..using GL_ARB_multitexture ...using GL_ARB_texture_env_combine ...using GL_ARB_texture_cube_map ...using GL_ARB_texture_env_dot3 ...using GL_ARB_texture_env_add X..GL_ARB_texture_non_power_of_two not found ...using GL_NV_blend_square ...using GL_ARB_texture_compression X..GL_EXT_texture_compression_s3tc not found signal caught: Segmentation fault si_code 1 Trying to exit gracefully.. Any ideas? --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Quake4 benchmarks
On Tue, 23 May 2006 19:18:56 -0400 Adam K Kirchhoff [EMAIL PROTECTED] wrote: FYI, I downloaded the hwspirit timedemo for quake4 yesterday and decided to compare the framerate between the fglrx, r200, and xig drivers with my Radeon 9000: 9000 - xig - 14.7 9000 - fgl - 11.3 9000 - xorg - 16.2 Today I decided to give it a shot with my 9600. The fglrx drivers gave me 16.8 FPS, and the r300 drivers gave me this: http://68.44.156.246/quake4-screenshot.png As you can see, everything is quite shiny (but not quite as washed out as the screenshot shows... I had to brighten it a little to make it visible). This is with both page flipping and color tiling enabled (though I tried without page flipping and got the same results). And I have the libtxc_dxtn library compiled and installed. If I remove that library, quake4 completely refuses to start: ..using GL_ARB_multitexture ...using GL_ARB_texture_env_combine ...using GL_ARB_texture_cube_map ...using GL_ARB_texture_env_dot3 ...using GL_ARB_texture_env_add X..GL_ARB_texture_non_power_of_two not found ...using GL_NV_blend_square ...using GL_ARB_texture_compression X..GL_EXT_texture_compression_s3tc not found signal caught: Segmentation fault si_code 1 Trying to exit gracefully.. Any ideas? AFAIK, dxt3/5 textures need to be tiled in order to work with multitexturing. fglrx does texture uploads differently so I dont know how to tile them on upload. Textures looking washed out might be another bug as ut2k4 doesnt show similar artifacts(only squares). -- Aapo Tahkola --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Benchmarks.
On Mon, 06 Mar 2006 04:11:58 +0100 Roland Scheidegger [EMAIL PROTECTED] wrote: Adam K Kirchhoff wrote: Using umark for benchmarking UT2004 (1024x768 with all low or very low display settings)... First DM-1on1-Albatross: 9600 - fgl - 11.378239 / 35.393394 / 82.763985 fps - Score = 35.407494 9600 - dri - 5.033368 / 8.846323 / 17.930601 fps - Score = 8.850811 Nothing new here, dri performance is still limited by the lack of ARB_vbo or at least decent drawArrays performance avoiding fallbacks. r300 driver now supports this in HW. It should work pretty well as long as GART is big enough and application doesn't request to draw with more than 65535 verts. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Benchmarks.
I had some time yesterday and thought I'd do a quick comparision of the DRI drivers and fglrx drivers for three different cards I have, and I thought others on this list might be interested in the results. All tests were conducted on a dual 2.8 xeon, with a gig of RAM. The cards are a 9600AS with 256 megs of RAM, a 9000Pro with 129 megs of RAM, and an X700 with 256 megs. After each test with the DRI drivers, I rebooted and ran the exact same one with the FireGL drivers. The DRI drivers are from Mesa (and DRM) CVS from Thursday. The FireGL drivers are the latest available at the moment (I don't remember the version number off the top of my head). There have been no game specific changes made in driconf. Using timedemo demo1 in doom3 (640x480, low quality settings), this is what I got: 9600 - fgl - 13.4 FPS 9600 - dri - 15 FPS 9000 - fgl - 14 FPS 9000 - dri - 17.6 FPS X700 - fgl - 13.8 FPS X700 - dri - 14.7 FPS Using umark for benchmarking UT2004 (1024x768 with all low or very low display settings)... First DM-1on1-Albatross: 9600 - fgl - 11.378239 / 35.393394 / 82.763985 fps - Score = 35.407494 9600 - dri - 5.033368 / 8.846323 / 17.930601 fps - Score = 8.850811 9000 - fgl - 13.003528 / 31.308100 / 93.127403 fps - Score = 31.318676 9000 - dri - 6.515143 / 11.408949 / 22.809250 fps - Score = 11.415204 X700 - fgl - 12.597370 / 43.225315 / 114.483971 fps - Score = 43.069965 X700 - dri - 5.531275 / 9.642255 / 24.157600 fps - Score = 9.647329 DM-Rustorium: 9600 - fgl - 11.864109 / 39.673630 / 107.136818 fps - Score = 39.679264 9600 - dri - .76 / 9.333500 / 21.820055 fps - Score = 9.336345 9000 - fgl - 13.001156 / 27.800968 / 77.328308 fps - Score = 27.807644 9000 - dri - 7.519938 / 12.948973 / 27.574434 fps - Score = 12.951131 X700 - fgl - 21.063986 / 69.125237 / 155.321548 fps - Score = 65.804871 X700 - dri - 6.243832 / 9.895700 / 32.778217 fps - Score = 9.896439 In retrospect, I should have done ut2004 at 640x480 to get a better comparison of how it stacks up to doom3. Adam --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Benchmarks.
Adam K Kirchhoff wrote: I had some time yesterday and thought I'd do a quick comparision of the DRI drivers and fglrx drivers for three different cards I have, and I thought others on this list might be interested in the results. All tests were conducted on a dual 2.8 xeon, with a gig of RAM. The cards are a 9600AS with 256 megs of RAM, a 9000Pro with 129 megs of RAM, and an X700 with 256 megs. After each test with the DRI drivers, I rebooted and ran the exact same one with the FireGL drivers. The DRI drivers are from Mesa (and DRM) CVS from Thursday. The FireGL drivers are the latest available at the moment (I don't remember the version number off the top of my head). There have been no game specific changes made in driconf. Using timedemo demo1 in doom3 (640x480, low quality settings), this is what I got: 9600 - fgl - 13.4 FPS 9600 - dri - 15 FPS 9000 - fgl - 14 FPS 9000 - dri - 17.6 FPS X700 - fgl - 13.8 FPS X700 - dri - 14.7 FPS The fgl numbers are downright awful for the r300 based cards (obviously more so for the X700), though the dri performance isn't good neither (but honestly you really should expect better performance from the ATI drivers at this point probably). The 9000 scores aren't quite comparable unless you used r_renderer arb on both cards, and you didn't take the rendering errors with dri driver which still are present with hw tcl into account. Though, with Mesa cvs since about last friday, r_renderer r200 actually works on r200 :-) (need to enable software ARB_vertex_program, need to enable 6 texture units, need to disable hw tcl, and for somewhat useful performance also need to use x86 optimized build with MESA_EXPERIMENTAL env var set with a cpu that supports sse...). Using umark for benchmarking UT2004 (1024x768 with all low or very low display settings)... First DM-1on1-Albatross: 9600 - fgl - 11.378239 / 35.393394 / 82.763985 fps - Score = 35.407494 9600 - dri - 5.033368 / 8.846323 / 17.930601 fps - Score = 8.850811 Nothing new here, dri performance is still limited by the lack of ARB_vbo or at least decent drawArrays performance avoiding fallbacks. In retrospect, I should have done ut2004 at 640x480 to get a better comparison of how it stacks up to doom3. dri numbers would just stay almost completely the same, you can configure ut2k4 however you want but the amount of vertices sent remains pretty much constant. Roland --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Some bsd-3-0-0-branch benchmarks.
Well, I've got most of the FreeBSD troubles straightened out I think. I went ahead and did some glxgears benchmarks, waiting for the numbers to stabilize, of gentoo vs freebsd-current. System is a 128MB 2xCeleron517 (BP6, OCed), diskless, booting gentoo or -current off of a -current system. Video at 1280x1024x60hz, 16 bit. gentoo 1.1, kernel 2.4.19-gentoo-r5 (custom, p2 opts but nothing special think) bsd-3-0-0-branch as of a few days ago kernel modules from bsd-3-0-0-branch from today twm FreeBSD-current as of a few days ago. WITNESS and INVARIANTS disabled. bsd-3-0-0-branch as of a few days ago kernel modules from bsd-3-0-0-branch from today. No wm (sshing in). Radeon 64MB VIVO, no pageflip: linux: 1325 fps bsd: 1324 Rage 128 Pro: linux: 581 bsd: 582 Matrox G400 linux: 923 bsd: 755 Only the Matrox had problems, don't know what that was.Still, I'm very excited about the Radeon numbers. -- Eric Anholt [EMAIL PROTECTED] http://gladstone.uoregon.edu/~eanholt/dri/ --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Some bsd-3-0-0-branch benchmarks.
Eric Anholt wrote: Well, I've got most of the FreeBSD troubles straightened out I think. I went ahead and did some glxgears benchmarks, waiting for the numbers to stabilize, of gentoo vs freebsd-current. System is a 128MB 2xCeleron517 (BP6, OCed), diskless, booting gentoo or -current off of a -current system. Video at 1280x1024x60hz, 16 bit. gentoo 1.1, kernel 2.4.19-gentoo-r5 (custom, p2 opts but nothing special think) bsd-3-0-0-branch as of a few days ago kernel modules from bsd-3-0-0-branch from today twm FreeBSD-current as of a few days ago. WITNESS and INVARIANTS disabled. bsd-3-0-0-branch as of a few days ago kernel modules from bsd-3-0-0-branch from today. No wm (sshing in). Radeon 64MB VIVO, no pageflip: linux: 1325 fps bsd: 1324 Rage 128 Pro: linux: 581 bsd: 582 Matrox G400 linux: 923 bsd: 755 Only the Matrox had problems, don't know what that was.Still, I'm very excited about the Radeon numbers. Nice. I'm just looking a little at the code, wonder if there can be some name changes to simplify the macros a little. We're using DRM_ prefixes for os-abstractions already, like DRM_DEBUG, so I don't think it's necessary to further specialize the namespace to DRM_OS_ --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Some bsd-3-0-0-branch benchmarks.
Keith Whitwell wrote: Eric Anholt wrote: Well, I've got most of the FreeBSD troubles straightened out I think. I went ahead and did some glxgears benchmarks, waiting for the numbers to stabilize, of gentoo vs freebsd-current. System is a 128MB 2xCeleron517 (BP6, OCed), diskless, booting gentoo or -current off of a -current system. Video at 1280x1024x60hz, 16 bit. gentoo 1.1, kernel 2.4.19-gentoo-r5 (custom, p2 opts but nothing special think) bsd-3-0-0-branch as of a few days ago kernel modules from bsd-3-0-0-branch from today twm FreeBSD-current as of a few days ago. WITNESS and INVARIANTS disabled. bsd-3-0-0-branch as of a few days ago kernel modules from bsd-3-0-0-branch from today. No wm (sshing in). Radeon 64MB VIVO, no pageflip: linux: 1325 fps bsd: 1324 Rage 128 Pro: linux: 581 bsd: 582 Matrox G400 linux: 923 bsd: 755 Only the Matrox had problems, don't know what that was.Still, I'm very excited about the Radeon numbers. Nice. I'm just looking a little at the code, wonder if there can be some name changes to simplify the macros a little. We're using DRM_ prefixes for os-abstractions already, like DRM_DEBUG, so I don't think it's necessary to further specialize the namespace to DRM_OS_ ... (doh) So, instead of DRM_OS_COPYFROMUSR_NC, maybe DRM_COPY_FROM_USER_UNCHECKED might be clearer. Similarly, DRM_OS_KRNFROMUSR is pretty cryptic -- maybe DRM_COPY_FROM_USER_IOCTL or something? Oh, and I just found DRM_OS_FETCHU_32_NC -- that's ugly... I How about: DRM_OS_COPYFROMUSR_NC -- DRM_COPY_FROM_USER_UNCHECKED DRM_OS_COPYFROMUSR -- DRM_COPY_FROM_USER DRM_OS_KRNFROMUSR -- DRM_COPY_FROM_USER_IOCTL DRM_OS_FETCHU_32_NC -- DRM_GET_USER_UNCHECKED and so on. Keith --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Linux vs. Windows Quake3 Demo Benchmarks
Hello I made some Benchmark comparisons with my Video card under WinME and Linux, here are the resulst: Perhaps using the new tdfx driver branch 3.1, DRI inbuild Mesa 3.5 and Kernel 2.4 could be a little bit faster. Linux vs. WindowsME Quake3Arena Demo Benchmarks: How To Benchmark: Start Quake3 Arena Demo Open console (to open console with a German keyboard layout press right shift + ` - the key next to ß ) and insert the following commands: timedemo 1 return demo demo001.dm3 after that go back to console and read the values. then enter timedemo 1 return demo demo002.dm3 Computer: Athlon 500 MHz 128 MB SDRAM 100 MHz 3Dfx Voodoo 3 2000 PCI ASUS K7M Mainboard Terratec EWS64XL Soundcard Linux Slackware 7.1 XFree 4.0.2 CVS-DRI TDFX drivers (tdfx branch 3.0) - from end of March DRI-XFree inbuild Mesa3d was 3.4 Kernel 2.2.18 WindowsME 3dFX Driver from 2 November 2000 = (11/02/2000) (22bit Postfilter is turned on in WinME !) Percent Rate is: (fpsLinux*100)/fpsWin = Linux Value Windows Percent Value is allways set to 100 % Normal Detail Benchmark: 640*480 frames sec fps% Demo001: Linux 1346 26,3 51,2 87,52 % WindowsME 1346 23,0 58,5100,00 % Demo002: Linux 1399 28,0 49,9 85,89 % WindowsME 1399 24,1 58,1100,00 % Normal Detail changed to 1024*786 resolution: frames sec fps% Demo001: Linux 1346 43,5 31,2 80,00 % WindowsME 1346 34,5 39,0100,00 % Demo002: Linux 1399 46,6 30,073,17 % WindowsME 1399 34,1 41,0 100,00 % Custom Detail Benchmark: - Settings are nearly similar to highest Quality Benchmark Seeting! Video: GL Ext = On color depth = 16 bit Fullscreen lightmap Geometrie Detail = High texture Detail= Max texture Quality= 16 bit texture Filter= Bilinear Sound: Sound = High A3d= off Game Options: Simple items= off Walls = on Brass = on Light = on Target = on Sky= on Sync = off Modds = off Overly = off 640*480: frames sec fps % Demo001: Linux 1346 42,5 31,7 55,91 % WindowsME 1346 23,8 56,7100,00 % Demo002: Linux 1399 81,6 17,1 30,87 % WindowsME 1399 25,3 55,4100,00 % _ 1024*768: frames sec fps % Demo001: Linux 1346 59,2 22,7 61,85 % WindowsME 1346 36,7 36,7100,00 % Demo002: Linux 1399 93,7 14,9 39,11 % WindowsME 1399 36,7 38,1100,00 % = End of Benchmarking = The Linux drivers are not very fast compard to their windows counterpart. I hope that will change some day. Best Regards Oliver C. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linux vs. Windows Quake3 Demo Benchmarks
Kreuzritter2000 wrote: Hello I made some Benchmark comparisons with my Video card under WinME and Linux, here are the resulst: Perhaps using the new tdfx driver branch 3.1, DRI inbuild Mesa 3.5 and Kernel 2.4 could be a little bit faster. It might be a bit faster but I haven't benchmarked it personally. In any case, we're unlikely to put any significant work into the tdfx drivers anymore, for obvious reasons. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
