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
capturing fglrx command streams?
Hi, I had absolutely no luck getting any usable R300_CP_IB_BASE address with glxtest. I get and address like this 0xe0711000 which is not a valid address for the application. 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
[Bug 7770] libGL error: open DRM failed (Operation not permitted) on ia64 (Itanium)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=7770 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #6456|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 7770] libGL error: open DRM failed (Operation not permitted) on ia64 (Itanium)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=7770 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #6457|text/x-log |text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 7770] libGL error: open DRM failed (Operation not permitted) on ia64 (Itanium)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=7770 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #6458|text/x-log |text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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: capturing fglrx command streams?
Rune Petersen wrote: Hi, I had absolutely no luck getting any usable R300_CP_IB_BASE address with glxtest. I get and address like this 0xe0711000 which is not a valid address for the application. Am I missing something obvious? Neither can I recently (though I use it for r200). I believe it got broken with a kernel update some time ago (could have been a fglrx driver update though). I didn't really look into it (you can still extract information from the map file if you search for some known packets). 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
[Bug 7770] libGL error: open DRM failed (Operation not permitted) on ia64 (Itanium)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=7770 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2006-08-06 12:38 --- We need to find out which ioctl is failing. The kernel output might give a hint if setting /sys/module/drm/parameters/debug to 1 before running glxinfo. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 7774] Warcraft III crashes Xorg with R300
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=7774 --- Additional Comments From [EMAIL PROTECTED] 2006-08-06 13:01 --- The log file looks like there's a second server generation (i.e. some client connects and disconnects again before the window manager starts) and there's confusion about whether direct rendering is enabled or not in the second server generation. The freeze could be fixed in current xf86-video-ati git, otherwise it's most likely an r300 DRI driver issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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: capturing fglrx command streams?
Roland Scheidegger wrote: Rune Petersen wrote: Hi, I had absolutely no luck getting any usable R300_CP_IB_BASE address with glxtest. I get and address like this 0xe0711000 which is not a valid address for the application. Am I missing something obvious? Neither can I recently (though I use it for r200). I believe it got broken with a kernel update some time ago (could have been a fglrx driver update though). I didn't really look into it (you can still extract information from the map file if you search for some known packets). I've been trying to use it for fragment program comparison, but the the only commands for the fragment shader is either stale or bogus, the same for every program. I can read the fragment program from the MMIO, but it doesn't give me the whole picture. 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
[Bug 7774] Warcraft III crashes Xorg with R300
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=7774 --- Additional Comments From [EMAIL PROTECTED] 2006-08-06 14:36 --- (In reply to comment #4) The log file looks like there's a second server generation (i.e. some client connects and disconnects again before the window manager starts) and there's confusion about whether direct rendering is enabled or not in the second server generation. The freeze could be fixed in current xf86-video-ati git, otherwise it's most likely an r300 DRI driver issue. In the test I did not use a window manager, I just started X from console and then run DISPLAY=:0 wine war3.exe via SSH. Maybe it was a bad idea, but other programs (glxgears and Half-life in wine including) work fine this way. And I think it shouldn't crash X server. I tried xorg-server-1.1.1, it's the same. I will try xf86-video-ati from git. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 7790] New: Polygons incorrectly clipped by mach64 driver (ATI Rage Pro LT card)
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=7790
Summary: Polygons incorrectly clipped by mach64 driver (ATI Rage
Pro LT card)
Product: DRI
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: General
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
Partially offscreen polygons are rendered incorrectly. Visible part of them is
misplaced and texture coordinates are sometimes set to random values. Problem
appears only when clipping to viewport, polygons that are fully located inside
the viewport are rendered correctly.
Here's what glxinfo says about renderer:
OpenGL vendor string: Gareth Hughes, Leif Delgass, José Fonseca
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x
OpenGL version string: 1.2 Mesa 6.4.2
I'm not the sole victim, the same problem with Mach64 driver (on another card)
is described by another user here (you can get some screenshots there):
http://www.linuxquestions.org/questions/showthread.php?p=2368337
I'm attaching code that reproduces the problem with clipping.
-8 cut here 8--
#include GL/glut.h
void display(void)
{
glClearColor( 0.0, 0.0, 1.0, 0.0 );
glClear( GL_COLOR_BUFFER_BIT );
/* The white triangle is located inside the viewport
and is rendered correctly */
glColor3f( 1.0f, 1.0f, 1.0f );
glBegin( GL_TRIANGLES );
glVertex2f( 0.25f, 0.25f );
glVertex2f( 0.75f, 0.25f );
glVertex2f( 0.5f, 0.85f );
glEnd();
/* The red triangle is partially offscreen and various clipping
artefacts occur during render.
When rendered correctly, the red triangle should look the
same as white one, just translated to the left */
glColor3f( 1.0f, 0.0f, 0.0f );
glBegin( GL_TRIANGLES );
glVertex2f( -0.15f, 0.25f );
glVertex2f( 0.35f, 0.25f );
glVertex2f( 0.1f, 0.85f );
glEnd();
glutSwapBuffers();
};
int main(int argc, char **argv)
{
glutInit( argc, argv );
glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGBA );
glutInitWindowSize( 640, 480 );
glutCreateWindow( ATI Mach64 driver bug? );
gluOrtho2D( 0, 1, 0, 1 );
glutDisplayFunc( display );
glutMainLoop();
return 0;
}
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
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
