Re: Removal of mach64
On 02/07/10 13:24, Kristian Høgsberg wrote: On Sun, Feb 7, 2010 at 1:32 AM, Catalin Patuleac...@vv.carleton.ca wrote: Hello, I am interested in getting DRI working on my ATI Rage XL card under 2.6.31-14 with mach64_drv 6.8.2 (Xorg 1.6.3 from Ubuntu Karmic koala). Git says that the mach64 driver was deleted, along with shared-code, linux-core, etc, in commit 9dd361. Do these drivers live anywhere else now? Has anyone tried compiling them against a recent kernel? They live in the kernel. Except for mach64 :-) Unless I'm mistaken, that never made it into the linux kernel. Adam -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 14:16:13 vehemens wrote: [snip] Your missing the point of using a development structure which supports collobration. [snip] The difference is that you are the only one doing the work now. [snip] Again, your missing the point of using a development structure which supports collobration. [snip] It hasn't moved ... well beyond what was in drm git. If you believe otherwise, your only fooling yourself. [snip] See above comments. Yes, you have made it abundantly clear that you are in favor of having a centralized repository for all DRM development. The fact is, that's not happening now and is not going to happen. That used to be the case, but the linux DRM developers did not see an advantage to that for themselves, and though rnoland was unhappy with the decision (because it made his job harder), the linux DRM developers did what they felt was best. Since then, rnoland has made significant progress porting the linux specific changes over to FreeBSD. If you don't believe the changes he's made in the FreeBSD source tree go 'well beyond' what had been in mesa/drm on freedesktop git then you are fooling yourself. Frankly, if I were Robert, I would be offended by that statement you made. As has been said time and again, the kernel specific code in mesa/drm serves no purpose other than providing a historical log of the DRM development from that time, so there was no harm in pulling it. The FreeBSD DRM code follows the same development model as the rest of FreeBSD, and I have a hard time believing that such a model doesn't support collaboration. That is certainly an accusation I've never once heard made against the FreeBSD project in recent years till just now. Now, the changes are made, and what's done is done. Can we please just move on? Adam -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 18:54:31 vehemens wrote: On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote: On Sunday 29 November 2009 14:16:13 vehemens wrote: [snip] Your missing the point of using a development structure which supports collobration. [snip] The difference is that you are the only one doing the work now. [snip] Again, your missing the point of using a development structure which supports collobration. [snip] It hasn't moved ... well beyond what was in drm git. If you believe otherwise, your only fooling yourself. [snip] See above comments. Yes, you have made it abundantly clear that you are in favor of having a centralized repository for all DRM development. The fact is, that's not happening now and is not going to happen. That used to be the case, but the linux DRM developers did not see an advantage to that for themselves, and though rnoland was unhappy with the decision (because it made his job harder), the linux DRM developers did what they felt was best. You assuming what what good for Linux for a developer, is also good for a BSD developer. As for making rnoland's job harder, it was his choice. Nice try, but I am making no such assumptions. It was not rnoland's choice to stop having the linux DRM developers stop using a centralized repository for all DRM code. He was quite clearly opposed to it and did not consider it a good choice. Since then, rnoland has made significant progress porting the linux specific changes over to FreeBSD. If you don't believe the changes he's made in the FreeBSD source tree go 'well beyond' what had been in mesa/drm on freedesktop git then you are fooling yourself. Frankly, if I were Robert, I would be offended by that statement you made. I've diffed the code. Suggest that you do the same and see if you can still make the same statements. r6xx/r7xx DRM code, alone, pushes FreeBSD DRM well beyond what was in mesa/drm on freedesktop. As has been said time and again, the kernel specific code in mesa/drm serves no purpose other than providing a historical log of the DRM development from that time, so there was no harm in pulling it. The FreeBSD DRM code follows the same development model as the rest of FreeBSD, and I have a hard time believing that such a model doesn't support collaboration. That is certainly an accusation I've never once heard made against the FreeBSD project in recent years till just now. If one stashes his/her development code where few if any can get at it, I don't consider that collaboration. Many developers have private source repos for their code and only make such code available when it's actually usable for testing or further development by others. Now, the changes are made, and what's done is done. Can we please just move on? I was going to move along, but I felt your email had so many errors, I couldn't let it got by. Nice try baiting me. I've said my two cents worth, and I'm done with this discussion. Adam -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Broken reflection in compiz on r300
Markus Amsler Thu, 10 Apr 2008 18:10:53 -0700 Adam K Kirchhoff wrote: Before I open up a bug report, I was wondering if anyone wanted to comment on this problem. I was recently doing some testing of r300 vs. fgrlx for one of the compiz dev's when I noticed that the reflection plugin no longer (with mesa from git) works on my x700 even though it worked fine with mesa 7.0.1. After a little bit of git-bisecting and recompiling xf86-video-ati and xserver, I managed to locate the commit where it broke: # bad: [c34b024cf49f3fc06271d561a4069c77d7b65c48] r300: add artificial output to match fragment program input That's my commit :(. I'm going to look at it. Markus Sorry, I didn't see your e-mail response till this morning, after I opened up a bug report for it: https://bugs.freedesktop.org/show_bug.cgi?id=15447 If there's anything you'd like to to test, just let me know. Onestone had me test mesa/progs/fp/tri-position with the latest git driver, and that's broken, too. He assumes that they are related, as both tri-position and the reflection plugin use fragment.position. I'm rebuilding a working version of the driver and x server now to confirm that tri-position worked before your commit. Adam - 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Broken reflection in compiz on r300
On Friday 11 April 2008 07:38:31 Markus Amsler wrote: Adam K Kirchhoff wrote: Markus Amsler Thu, 10 Apr 2008 18:10:53 -0700 Adam K Kirchhoff wrote: Before I open up a bug report, I was wondering if anyone wanted to comment on this problem. I was recently doing some testing of r300 vs. fgrlx for one of the compiz dev's when I noticed that the reflection plugin no longer (with mesa from git) works on my x700 even though it worked fine with mesa 7.0.1. After a little bit of git-bisecting and recompiling xf86-video-ati and xserver, I managed to locate the commit where it broke: # bad: [c34b024cf49f3fc06271d561a4069c77d7b65c48] r300: add artificial output to match fragment program input That's my commit :(. I'm going to look at it. Markus Sorry, I didn't see your e-mail response till this morning, after I opened up a bug report for it: https://bugs.freedesktop.org/show_bug.cgi?id=15447 If there's anything you'd like to to test, just let me know. Onestone had me test mesa/progs/fp/tri-position with the latest git driver, and that's broken, too. He assumes that they are related, as both tri-position and the reflection plugin use fragment.position. I'm rebuilding a working version of the driver and x server now to confirm that tri-position worked before your commit. Adam I just sent the attached to mesa-devel. It fixes tri-position and the compiz reflection issue. I have no mesa commit right, so it may take 1-2 days until it gets into git. Please test this patch, just to be sure. Thanks for your time resolving this, I know bisecting is a PITA. Markus That patch works great here. Thanks for your time fixing this :-) Adam - 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 8056] s3tc broken in ut2004
On Tuesday 26 June 2007 14:14:06 [EMAIL PROTECTED] wrote: http://bugs.freedesktop.org/show_bug.cgi?id=8056 --- Comment #19 from [EMAIL PROTECTED] 2007-06-26 11:13 PST --- Patches implementing micro tiling on r300, if someone wants play with them. FYI, I just gave these patches a shot. I have the libtxc_dxtn.so library installed and both GL_EXT_texture_compression_s3tc and GL_S3_s3tc are showing up in glxinfo. ut2004 and doom3 both play fine, with none of the texture problems associated with s3tc without these patches. Having S3TC enabled, though, does not give a big performance increase in either game. I consistently ended up with 2-3 extra fps in various ut2004 DM levels, and in doom3 demo1, but I'm not sure I can chalk that up to S3TC :-) Adam - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 11283] blender menus don't show up with r300 driver from git
On Wednesday 20 June 2007 18:07:52 Brian Paul wrote: Adam K Kirchhoff wrote: On Wednesday 20 June 2007 13:02:47 Brian Paul wrote: Eric Anholt wrote: On Tue, 2007-06-19 at 12:20 -0400, Adam K Kirchhoff wrote: On Sat, 2007-06-16 at 09:44 -0700, [EMAIL PROTECTED] wrote: http://bugs.freedesktop.org/show_bug.cgi?id=11283 --- Comment #4 from [EMAIL PROTECTED] 2007-06-16 09:44 PST --- Finished with git-bisect: 9e8a961dd7d7b717a9fb4ecdea1c1b60ea355efe is first bad commit commit 9e8a961dd7d7b717a9fb4ecdea1c1b60ea355efe Author: Brian [EMAIL PROTECTED] Date: Sun May 20 12:27:39 2007 -0600 Overhaul/simplify SWvertex and SWspan attribute handling. Instead of separate fog/specular/texcoord/varying code, just treat all of them as generic attributes. Simplifies the point/line/triangle functions. :04 04 9f70804d38a62512f185453df294c7e1df8e44e0 3ef1f5e6a5ae338ef5ccce99bc62cfbaf7f8987c M src Brian, Can you shed some light onto what this commit did to blender? :-) I was just looking into this commit. It broke the software drawpixels path with the drawpix demo, at least. Yeah, try my latest commits and see what happens with Blender (and drawpix). -Brian Sorry, but blender is still broken :-( Does anyone know how blender draws its menus (glDrawPixels, glBitmap, textured polygons, etc)? -Brian 171dcdfa27dda30916a7f9bfed89577feee5d350 fixes the menus in blender. ed5ed6fe2f64f45eb3a43f9c57037d9e9b7fa5ea fixed another bug that I saw with blender (which I assumed was the same bug that messed up the menus) where the lines in blender were screwed up :-) Adam - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 11283] blender menus don't show up with r300 driver from git
On Wednesday 20 June 2007 13:02:47 Brian Paul wrote: Eric Anholt wrote: On Tue, 2007-06-19 at 12:20 -0400, Adam K Kirchhoff wrote: On Sat, 2007-06-16 at 09:44 -0700, [EMAIL PROTECTED] wrote: http://bugs.freedesktop.org/show_bug.cgi?id=11283 --- Comment #4 from [EMAIL PROTECTED] 2007-06-16 09:44 PST --- Finished with git-bisect: 9e8a961dd7d7b717a9fb4ecdea1c1b60ea355efe is first bad commit commit 9e8a961dd7d7b717a9fb4ecdea1c1b60ea355efe Author: Brian [EMAIL PROTECTED] Date: Sun May 20 12:27:39 2007 -0600 Overhaul/simplify SWvertex and SWspan attribute handling. Instead of separate fog/specular/texcoord/varying code, just treat all of them as generic attributes. Simplifies the point/line/triangle functions. :04 04 9f70804d38a62512f185453df294c7e1df8e44e0 3ef1f5e6a5ae338ef5ccce99bc62cfbaf7f8987c M src Brian, Can you shed some light onto what this commit did to blender? :-) I was just looking into this commit. It broke the software drawpixels path with the drawpix demo, at least. Yeah, try my latest commits and see what happens with Blender (and drawpix). -Brian Sorry, but blender is still broken :-( Adam - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 11283] blender menus don't show up with r300 driver from git
On Sat, 2007-06-16 at 09:44 -0700, [EMAIL PROTECTED] wrote: http://bugs.freedesktop.org/show_bug.cgi?id=11283 --- Comment #4 from [EMAIL PROTECTED] 2007-06-16 09:44 PST --- Finished with git-bisect: 9e8a961dd7d7b717a9fb4ecdea1c1b60ea355efe is first bad commit commit 9e8a961dd7d7b717a9fb4ecdea1c1b60ea355efe Author: Brian [EMAIL PROTECTED] Date: Sun May 20 12:27:39 2007 -0600 Overhaul/simplify SWvertex and SWspan attribute handling. Instead of separate fog/specular/texcoord/varying code, just treat all of them as generic attributes. Simplifies the point/line/triangle functions. :04 04 9f70804d38a62512f185453df294c7e1df8e44e0 3ef1f5e6a5ae338ef5ccce99bc62cfbaf7f8987c M src Brian, Can you shed some light onto what this commit did to blender? :-) Adam - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM under FreeBSD
FYI, DRM from git is broken on FreeBSD: cc -O2 -fno-strict-aliasing -pipe --param large-function-growth=1000 -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I- -I. -I.. -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -c /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_do_init_cp': /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c:1684: error: structure has no member named `table_size' /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c:1691: error: structure has no member named `gart_reg_if' /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c:1691: error: `DRM_ATI_GART_PCIE' undeclared (first use in this function) /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c:1691: error: (Each undeclared identifier is reported only once /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c:1691: error: for each function it appears in.) /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c:1693: error: structure has no member named `gart_reg_if' /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c:1693: error: `DRM_ATI_GART_PCI' undeclared (first use in this function) /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c:1702: error: structure has no member named `gart_reg_if' /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c:1702: error: `DRM_ATI_GART_IGP' undeclared (first use in this function) /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c:1704: error: structure has no member named `gart_reg_if' /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_driver_firstopen': /home/adamk/git/drm/bsd-core/radeon/../radeon_cp.c:2291: error: structure has no member named `table_size' *** Error code 1 Stop in /home/adamk/git/drm/bsd-core/radeon. *** Error code 1 - 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockups with Googleearth
Adam K Kirchhoff wrote: On Mon, 2007-03-05 at 14:13 -0500, Adam K Kirchhoff wrote: On Mon, 2007-03-05 at 20:03 +0100, Michel Dänzer wrote: On Sun, 2007-03-04 at 11:16 -0500, Adam K Kirchhoff wrote: I've been trying to track down this problem I've been having with the r300 driver and Googleearth. Sometime, since 6.5.2 was released. It's an odd problem as I've only see it on my PCIe x800, but not my AGP x700. In addition, it only seems to happen when I'm using MergedFB. If I set MergedFB to '0', I don't have this problem. Basically, what's happening is that my system completely locks up usually after just a few seconds (the earth starts to zoom in). Sometimes it doesn't lockup till I manually grab and move the earth, or actually type in an address. I can't ping the machine and the serial console is unresponsive. Does it lock up if you don't move the mouse? Does it happen with SW cursor or no silken mouse? I believe it does lock up even if I don't move the mouse, though I'll want to confirm that when I get home in a bit. I can also try with SW cursor and/or no silken mouse later today. And I was wrong. I was able to browse the world, as long as I only typed in the places I wanted to visit. Hit three or four different cities without any problems, but just a second or two after I started moving the globe with my mouse, it locked up. And, I'm happy to report, disabling silken mouse gets it working again. I'll see if I can wrangle git into giving me a version of the drivers right before the vbo merge and right after it, though I may not get those results till tomorrow. Adam So this is what I'm seeing commit 09e4df2c65c1bca0d04c6ffd076ea7808e61c4ae causes the lockup.. If I'm reading the git log properly this is right after the merge from vbo-0.2. However, commit 47d463e954efcd15d20ab2c96a455aa16ddffdcc also causes the lockup, and this is right before the merge from vbo-0.2. I continued with the git-bisect from there last night, but still ended up at the same point: I kept getting versions that I couldn't compile, and using git reset --hard HEAD~10 ends up getting me stuck in a circle. I'll see if I can narrow it down further this afternoon. 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: Lockups with Googleearth
Michel Dänzer wrote: On Tue, 2007-03-06 at 04:32 -0500, Adam K Kirchhoff wrote: commit 09e4df2c65c1bca0d04c6ffd076ea7808e61c4ae causes the lockup.. If I'm reading the git log properly this is right after the merge from vbo-0.2. However, commit 47d463e954efcd15d20ab2c96a455aa16ddffdcc also causes the lockup, and this is right before the merge from vbo-0.2. No, that's still on vbo-0.2. The last commit on master before the merge is 325196f548f8e46aa8fcc7b030e81ba939e7f6b7. I really recommend gitk. :) Sorry about that. I turned back to the log after browsing through gitk last night well past after I should have been asleep :-) Anyway, you're suspicion was correct, this problem did not exist prior to the merge of the vbo-0.2 branch, but did start immediately after the merge. Does this need to be narrowed down further on the vbo-0.2 branch? 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: Lockups with Googleearth
On Mon, 2007-03-05 at 20:03 +0100, Michel Dänzer wrote: On Sun, 2007-03-04 at 11:16 -0500, Adam K Kirchhoff wrote: I've been trying to track down this problem I've been having with the r300 driver and Googleearth. Sometime, since 6.5.2 was released. It's an odd problem as I've only see it on my PCIe x800, but not my AGP x700. In addition, it only seems to happen when I'm using MergedFB. If I set MergedFB to '0', I don't have this problem. Basically, what's happening is that my system completely locks up usually after just a few seconds (the earth starts to zoom in). Sometimes it doesn't lockup till I manually grab and move the earth, or actually type in an address. I can't ping the machine and the serial console is unresponsive. Does it lock up if you don't move the mouse? Does it happen with SW cursor or no silken mouse? I believe it does lock up even if I don't move the mouse, though I'll want to confirm that when I get home in a bit. I can also try with SW cursor and/or no silken mouse later today. I suspect the problem is that this is on the vbo-0.2 branch. Can you try a commit from before or after its merge? Use git-reset --hard commit hash with the bisect branch checked out. gitk is nice for finding a suitable commit. I'll give that a shot. With one of the bad drivers (not the one from current git) I get the following message logged before locking up: Uhhuh. NMI received. Dazed and confused, but trying to continue You probably have a hardware problem with your RAM chips. I've run memtest for about 45 minutes now, completed one pass (it's about half way through a second pass) without any errors, so I'm disinclined to believe this is a RAM issue. I guess this could also be a symptom of the lockup. Well, I let it run for two hours, four total passes. No errors, so I'm definitely more inclined to believe that the impending lockup was causing the NMI error, rather than the other way around :-) 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: Lockups with Googleearth
On Mon, 2007-03-05 at 14:13 -0500, Adam K Kirchhoff wrote: On Mon, 2007-03-05 at 20:03 +0100, Michel Dänzer wrote: On Sun, 2007-03-04 at 11:16 -0500, Adam K Kirchhoff wrote: I've been trying to track down this problem I've been having with the r300 driver and Googleearth. Sometime, since 6.5.2 was released. It's an odd problem as I've only see it on my PCIe x800, but not my AGP x700. In addition, it only seems to happen when I'm using MergedFB. If I set MergedFB to '0', I don't have this problem. Basically, what's happening is that my system completely locks up usually after just a few seconds (the earth starts to zoom in). Sometimes it doesn't lockup till I manually grab and move the earth, or actually type in an address. I can't ping the machine and the serial console is unresponsive. Does it lock up if you don't move the mouse? Does it happen with SW cursor or no silken mouse? I believe it does lock up even if I don't move the mouse, though I'll want to confirm that when I get home in a bit. I can also try with SW cursor and/or no silken mouse later today. And I was wrong. I was able to browse the world, as long as I only typed in the places I wanted to visit. Hit three or four different cities without any problems, but just a second or two after I started moving the globe with my mouse, it locked up. And, I'm happy to report, disabling silken mouse gets it working again. I'll see if I can wrangle git into giving me a version of the drivers right before the vbo merge and right after it, though I may not get those results till tomorrow. 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
Lockups with Googleearth
Sorry, I just realized I sent two e-mails about this problem to [EMAIL PROTECTED] Not even sure how that address got into my address book in the first place, or where that mail actually goes... But, onto my problems: I've been trying to track down this problem I've been having with the r300 driver and Googleearth. Sometime, since 6.5.2 was released. It's an odd problem as I've only see it on my PCIe x800, but not my AGP x700. In addition, it only seems to happen when I'm using MergedFB. If I set MergedFB to '0', I don't have this problem. Basically, what's happening is that my system completely locks up usually after just a few seconds (the earth starts to zoom in). Sometimes it doesn't lockup till I manually grab and move the earth, or actually type in an address. I can't ping the machine and the serial console is unresponsive. Thanks to help from Michel Dänzer on IRC, I was started using git-bisect to track down this problem, using 6.5.2 as a known good, and current Mesa from git as bad. It went well at first, but proceeded down hill :-) Here's the bisect log: git-bisect start # good: [76b1b692688a75986ac7ff2e96d5803a6f154715] remove directfbgl.h file git-bisect good 76b1b692688a75986ac7ff2e96d5803a6f154715 # bad: [95577064040ceeaaf7b0a460f91eac951cf8af18] r300: Use register name add a register about shading. git-bisect bad 95577064040ceeaaf7b0a460f91eac951cf8af18 # good: [89f91d1804c0c4919c25d6b9931973733db1e664] nouveau: Implement much of the fog handling. git-bisect good 89f91d1804c0c4919c25d6b9931973733db1e664 # bad: [b59657ad965f9471574e914b861bb1d2a17d772e] Merge branch 'vbo-0.2' git-bisect bad b59657ad965f9471574e914b861bb1d2a17d772e # good: [876e372567ad44c03b9d9db6e57d3a06b684f6e1] regenerated git-bisect good 876e372567ad44c03b9d9db6e57d3a06b684f6e1 # good: [876e372567ad44c03b9d9db6e57d3a06b684f6e1] regenerated git-bisect good 876e372567ad44c03b9d9db6e57d3a06b684f6e1 # bad: [25b2e50229592ecd4cc3d058471bdee1cb8a0c55] remove remaining traces of r200FlushVertices... git-bisect bad 25b2e50229592ecd4cc3d058471bdee1cb8a0c55 # bad: [25b2e50229592ecd4cc3d058471bdee1cb8a0c55] remove remaining traces of r200FlushVertices... git-bisect bad 25b2e50229592ecd4cc3d058471bdee1cb8a0c55 # good: [8ed319796f35ccd82863a270704752555706f1e2] special case END in _mesa_print_instruction() git-bisect good 8ed319796f35ccd82863a270704752555706f1e2 I'm now getting a problem building the drivers: mklib: Making Linux shared library: libGL.so.1.2 mklib: Installing libGL.so.1.2 libGL.so.1 libGL.so in ../../../lib make[3]: Leaving directory `/home/adamk/workarea/git/mesa/src/glx/x11' make[3]: Entering directory `/home/adamk/workarea/git/mesa/src/mesa' Makefile:186: depend: No such file or directory make[3]: *** No rule to make target `tnl/t_draw.c', needed by `depend'. Stop. make[3]: Leaving directory `/home/adamk/workarea/git/mesa/src/mesa' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/home/adamk/workarea/git/mesa/src' make[1]: *** [default] Error 1 If I do a 'git reset --hard HEAD~5', and then try to build them again, it dies at the same place. So I did a 'git reset --hard HEAD~10', completed a build, did a test run, passed without any problems, and I marked it good. After running git-bisect, I get: Bisecting: 14 revisions left to test after this [70dd0126bd25f2cc2fedae60281ab5c256cb8664] pickup structs from vbo.h Unfortunately, at that point I end up with the same build problems (t_draw.c missing). So, any tips on where I go from here? Has this actually narrowed down the problem to one of a handful of commits? With one of the bad drivers (not the one from current git) I get the following message logged before locking up: Uhhuh. NMI received. Dazed and confused, but trying to continue You probably have a hardware problem with your RAM chips. I've run memtest for about 45 minutes now, completed one pass (it's about half way through a second pass) without any errors, so I'm disinclined to believe this is a RAM issue. 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
UT2004 and _mesa_fetch_state
FYI, I decided to give ut2004 a spin this morning, for the first time with the free driver in quite a while. I had heard good things since the VBO merge... Unfortunately, I very quickly ran into a problem with I loaded up the Icefields Bombing Run level: Mesa 6.5.3 implementation error: Invalid state in _mesa_fetch_state Please report at bugzilla.freedesktop.org At Michel's suggestion, I ran the game through gdb, with _mesa_problem set as a breakpoint. At the first instance of the breakpoint, I grabbed a backtrace: http://www.visualtech.com/backtrace.txt I then realized that this didn't refer to the _mesa_fetch_state problem, so I tried again, continuing through breakpoints before I hit _mesa_fetch_state with the third. I grabbed a backtrace at that specific breakpoint: http://www.visualtech.com/backtrace-_mesa_fetch_state.txt All three breakpoints had to do with state: Breakpoint 2, _mesa_problem (ctx=0x0, fmtString=0x699f11fc Invalid state in make_state_string) at main/imports.c:963 Breakpoint 2, _mesa_problem (ctx=0x0, fmtString=0x699f1248 unexpected state[0] in make_state_flags()) at main/imports.c:963 Breakpoint 2, _mesa_problem (ctx=0xbbb5c20, fmtString=0x699f118c Invalid state in _mesa_fetch_state) at main/imports.c:963 Between the two links above, there are backtraces for the 1st and 3rd instance of _mesa_problem, though I can also grab one at the 2nd if necessary :-) Now, if no one is familiar with this problem, I'm more than willing to open up a report on the bugzilla. Please let me know :-) 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: UT2004 and _mesa_fetch_state
On Wed, 2007-02-14 at 16:39 +0100, Roland Scheidegger wrote: Roland Scheidegger wrote: Adam K Kirchhoff wrote: FYI, I decided to give ut2004 a spin this morning, for the first time with the free driver in quite a while. I had heard good things since the VBO merge... Unfortunately, I very quickly ran into a problem with I loaded up the Icefields Bombing Run level: Mesa 6.5.3 implementation error: Invalid state in _mesa_fetch_state Please report at bugzilla.freedesktop.org At Michel's suggestion, I ran the game through gdb, with _mesa_problem set as a breakpoint. At the first instance of the breakpoint, I grabbed a backtrace: http://www.visualtech.com/backtrace.txt Oops. Looks like it's caused by the optimizations I did in t_vp_build.c (in particular, the fog using optimized internal fog state params). I'll look into it. Ok should hopefully be fixed. And so it is. Thanks! 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: DRI on FreeBSD with a PCIe X800
So I thought I might try and debug this problem further... I was looking at the various options in the radeon man page and came across the BusType option. I had tried both leaving that option out, and setting the option to PCIE. This morning, I decided to try setting it to PCI though, according to the man page, PCIE simply falls back to PCI at the present time, so I figured it wouldn't make a difference... Except that it does make a difference. If I set the BusType to PCI dmesg shows: info: [drm] Initialized radeon 1.25.0 20060524 info: [drm] Setting GART location based on new memory map error: [drm:pid1311:radeon_do_init_cp] *ERROR* Cannot use PCI Express without GART in FB memory The only thing different that shows up in the Xorg log file is: (WW) RADEON(0): Direct rendering disabled This is after all the usual DRI setup including the opening of the /dev/dri/card0 device. I'm not sure if this is at all related to the problem I'm seeing when I use BusType PCIE and get the screen corruption... However, at the very least it shows that BusType PCIE does not, in fact, fall back to PCI and something is being setup differently. If anyone wants to look at the full Xorg from the PCI session, it's available at: http://www.visualtech.com/Xorg.0.log.PCI.txt.gz Dmesg: http://www.visualtech.com/dmesg.txt.gz If anyone has any tips or pointers on debugging either of these problems further, I'm all ears :-) Adam Adam K Kirchhoff wrote: For anyone interested in following this, I've opened up a problem report: http://www.freebsd.org/cgi/query-pr.cgi?pr=106370 Adam Hello all, I'm having a problem getting direct rendering working on one of my workstations. I'm running -CURRENT from November 17th with Xorg installed from the modular Xorg ports tree yesterday (though I first noticed this a couple weeks back when I built modular Xorg using jhbuild): [ [EMAIL PROTECTED] - ~ ]: Xorg -version X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: FreeBSD 7.0-CURRENT i386 Current Operating System: FreeBSD sorrow.ashke.com 7.0-CURRENT FreeBSD 7.0-CURRENT #7: Tue Nov 14 08:33:41 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 28 November 2006 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present If I boot up with DRI enabled in the config file, the server starts, but the very top of the screen shows some visual corruption. http://www.visualtech.com/screenshot.png I dropped the resolution of the image from 2304x864 to 1600x800, but you can still make out the corruption. What's particularly odd, though, is that the root window is never drawn. The background you see is actually the background from my previous X session (when I had DRI disabled), using windowmaker. This time I launched X and had fvwm2 in my .xinitrc file (you can see the outline of the fvwm pager in the screenshot, though that never finished drawing, either). After that nothing else gets drawn. I can move the mouse pointer, but that's about it. I can safely kill X and restart it, but the same thing happens unless I disable DRI. In comparison, I have another workstation with an AGP x700. -CURRENT from the same date, and modular Xorg from the ports tree from yesterday, too. It works just fine (start up fine, and the mesa demos run with acceleration). You can find the Xorg log file from the PCIe system at http://www.visualtech.com/Xorg.0.log.gz Any ideas? Thanks! Adam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to [EMAIL PROTECTED] - 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: DRI on FreeBSD with a PCIe X800
On Mon, 2006-12-04 at 14:42 +0100, Michel Dänzer wrote: On Sat, 2006-12-02 at 12:14 -0500, Adam K Kirchhoff wrote: So something occurred to me last night... I've seen these same symptoms before when trying to get DRI working on FreeBSD a long time ago... On another machine, if I accidentally had the AGPSize set to a value higher than was set in the BIOS, I saw the exact same problem in FreeBSD (but not in Linux, which didn't have any problem with that particular situation). I don't have any config options set for GARTSize, but could something similar be happening now? I think that's unlikely with PCIe, although my first guess would have been something related to GART as well given that the same configuration seems to run or not depending on the OS. Maybe the OSs set up something differently related to PCIe. I'm having a problem getting direct rendering working on one of my workstations. I'm running FreeBSD -CURRENT from November 17th with Xorg installed from the modular Xorg ports tree yesterday (though I first noticed this a couple weeks back when I built modular Xorg using jhbuild): If you're saying that some previous version worked with the same configuration, could you try isolating the regression with git-bisect? If I boot up with DRI enabled in the config file, the server starts, but the very top of the screen shows some visual corruption. http://www.visualtech.com/screenshot.png I dropped the resolution of the image from 2304x864 to 1600x800, but you can still make out the corruption. What's particularly odd, though, is that the root window is never drawn. The background you see is actually the background from my previous X session (when I had DRI disabled), using windowmaker. This time I launched X and had fvwm2 in my .xinitrc file (you can see the outline of the fvwm pager in the screenshot, though that never finished drawing, either). After that nothing else gets drawn. Sounds like a GPU hang/lockup. I can move the mouse pointer, but that's about it. I can safely kill X and restart it, but the same thing happens unless I disable DRI. That's a relatively graceful way for it to deal with the above though. :} This seems to be a FreeBSD specific problem as the same PCIe x800 works fine with the OSS drivers under Linux, but no on on the freebsd-x11 lists seems to have any ideas, and I'm running out of ideas. I thought some of the great minds on this list might be able to shed some light. Any interesting differences between the server log files, DRM related kernel output etc. between OSs? The log file on FreeBSD doesn't show the same warning as the log file on linux about the support being experimental. Hmmm... FreeBSD shows: (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::07:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc56df000 (II) RADEON(0): [drm] mapped SAREA 0xc56df000 to 0x28557000 (II) RADEON(0): [drm] framebuffer handle = 0xc000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [pci] 8192 kB allocated with handle 0x (II) RADEON(0): [pci] ring handle = 0xc56e3000 (II) RADEON(0): [pci] Ring mapped at 0x38648000 (II) RADEON(0): [pci] Ring contents 0xfc181616 (II) RADEON(0): [pci] ring read ptr handle = 0xc57e4000 (II) RADEON(0): [pci] Ring read ptr mapped at 0x28559000 (II) RADEON(0): [pci] Ring read ptr contents 0xff3a492d (II) RADEON(0): [pci] vertex/indirect buffers handle = 0xc57e5000 (II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x38749000 (II) RADEON(0): [pci] Vertex/indirect buffers contents 0xff252d1e (II) RADEON(0): [pci] GART texture map handle = 0xc59e5000 (II) RADEON(0): [pci] GART Texture map mapped at 0x38949000 (II) RADEON(0): [drm] register handle = 0xdfbe (II) RADEON(0): [dri] Visual configs initialized And linux shows: (II) RADEON(0): [drm] DRM interface version 1.3 (II) RADEON(0): [drm] created radeon driver at busid pci::07:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xf8dee000 (II) RADEON(0): [drm] mapped SAREA 0xf8dee000 to 0xb7bac000 (II) RADEON(0): [drm] framebuffer handle = 0xc000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [pci] 8192 kB allocated with handle 0xf8f2e000 (II) RADEON(0): [pci] ring handle = 0xf8f2e000 (II) RADEON(0): [pci] Ring mapped at 0xa797 (II) RADEON(0): [pci] Ring contents 0x (II) RADEON(0): [pci] ring read ptr handle = 0xf902f000 (II) RADEON(0): [pci] Ring read ptr mapped at 0xb7bab000 (II) RADEON(0): [pci] Ring read ptr contents 0x (II) RADEON(0): [pci] vertex/indirect buffers handle = 0xf903 (II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0xa777 (II) RADEON(0): [pci] Vertex/indirect buffers contents 0x (II) RADEON(0): [pci] GART texture map handle = 0xf923 (II) RADEON(0): [pci
Re: DRI on FreeBSD with a PCIe X800
On Mon, 2006-12-04 at 15:42 +0100, Michel Dänzer wrote: On Mon, 2006-12-04 at 09:26 -0500, Adam K Kirchhoff wrote: The log file on FreeBSD doesn't show the same warning as the log file on linux about the support being experimental. Hmmm... FreeBSD shows: (II) RADEON(0): [drm] DRM interface version 1.2 [...] And linux shows: (II) RADEON(0): [drm] DRM interface version 1.3 So it looks like you're using a newer DRM on Linux but a newer xf86-video-ati on FreeBSD. Does making either of these equal between OSs change anything? Well, the DRM module itself is the same version as under linux (1.25.0). Are you referring to libdrm? I'll see if I can upgrade that on FreeBSD. 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: DRI on FreeBSD with a PCIe X800
On Mon, 2006-12-04 at 19:01 +0100, Michel Dänzer wrote: On Mon, 2006-12-04 at 12:49 -0500, Adam K Kirchhoff wrote: On Mon, 2006-12-04 at 15:42 +0100, Michel Dänzer wrote: On Mon, 2006-12-04 at 09:26 -0500, Adam K Kirchhoff wrote: The log file on FreeBSD doesn't show the same warning as the log file on linux about the support being experimental. Hmmm... FreeBSD shows: (II) RADEON(0): [drm] DRM interface version 1.2 [...] And linux shows: (II) RADEON(0): [drm] DRM interface version 1.3 So it looks like you're using a newer DRM on Linux but a newer xf86-video-ati on FreeBSD. Does making either of these equal between OSs change anything? Well, the DRM module itself is the same version as under linux (1.25.0). Are you referring to libdrm? No, see the different DRM interface versions (corresponding to the 'drm' kernel module) above. Maybe they're just different between OSs though. Yeah, I think that must be the case. I pulled the latest drm from the git repo and built both a newer libdrm and a newer drm.ko and radeon.ko kernel modules. I get the same results (and the same output in the Xorg log file about the interface version). I've also updated the xf86-video-ati driver on the linux installation to 6.6.3, so it's now the same version as the FreeBSD driver. DRI still works fine on the linux installation. Any other ideas? :-) 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: DRI on FreeBSD with a PCIe X800
On Mon, 2006-12-04 at 13:17 -0500, Adam K Kirchhoff wrote: On Mon, 2006-12-04 at 19:01 +0100, Michel Dänzer wrote: On Mon, 2006-12-04 at 12:49 -0500, Adam K Kirchhoff wrote: On Mon, 2006-12-04 at 15:42 +0100, Michel Dänzer wrote: On Mon, 2006-12-04 at 09:26 -0500, Adam K Kirchhoff wrote: The log file on FreeBSD doesn't show the same warning as the log file on linux about the support being experimental. Hmmm... FreeBSD shows: (II) RADEON(0): [drm] DRM interface version 1.2 [...] And linux shows: (II) RADEON(0): [drm] DRM interface version 1.3 So it looks like you're using a newer DRM on Linux but a newer xf86-video-ati on FreeBSD. Does making either of these equal between OSs change anything? Well, the DRM module itself is the same version as under linux (1.25.0). Are you referring to libdrm? No, see the different DRM interface versions (corresponding to the 'drm' kernel module) above. Maybe they're just different between OSs though. Yeah, I think that must be the case. I pulled the latest drm from the git repo and built both a newer libdrm and a newer drm.ko and radeon.ko kernel modules. I get the same results (and the same output in the Xorg log file about the interface version). I've also updated the xf86-video-ati driver on the linux installation to 6.6.3, so it's now the same version as the FreeBSD driver. DRI still works fine on the linux installation. Any other ideas? :-) Adam For what it's worth, I've also heard from a user on the freebsd-x11 mailing list with a PCIe x600 mobility that has fully functional 2D with DRI enabled. 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: DRI on FreeBSD with a PCIe X800
So something occurred to me last night... I've seen these same symptoms before when trying to get DRI working on FreeBSD a long time ago... On another machine, if I accidentally had the AGPSize set to a value higher than was set in the BIOS, I saw the exact same problem in FreeBSD (but not in Linux, which didn't have any problem with that particular situation). I don't have any config options set for GARTSize, but could something similar be happening now? Adam On Fri, 2006-12-01 at 15:16 -0500, Adam K Kirchhoff wrote: Hello all, I'm having a problem getting direct rendering working on one of my workstations. I'm running FreeBSD -CURRENT from November 17th with Xorg installed from the modular Xorg ports tree yesterday (though I first noticed this a couple weeks back when I built modular Xorg using jhbuild): [ [EMAIL PROTECTED] - ~ ]: Xorg -version X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: FreeBSD 7.0-CURRENT i386 Current Operating System: FreeBSD sorrow.ashke.com 7.0-CURRENT FreeBSD 7.0-CURRENT #7: Tue Nov 14 08:33:41 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 28 November 2006 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present If I boot up with DRI enabled in the config file, the server starts, but the very top of the screen shows some visual corruption. http://www.visualtech.com/screenshot.png I dropped the resolution of the image from 2304x864 to 1600x800, but you can still make out the corruption. What's particularly odd, though, is that the root window is never drawn. The background you see is actually the background from my previous X session (when I had DRI disabled), using windowmaker. This time I launched X and had fvwm2 in my .xinitrc file (you can see the outline of the fvwm pager in the screenshot, though that never finished drawing, either). After that nothing else gets drawn. I can move the mouse pointer, but that's about it. I can safely kill X and restart it, but the same thing happens unless I disable DRI. In comparison, I have another workstation with an AGP x700. -CURRENT from the same date, and modular Xorg from the ports tree from yesterday, too. It works just fine (starts up fine, and the mesa demos run with acceleration). You can find the Xorg log file from the PCIe system at http://www.visualtech.com/Xorg.0.log.gz This seems to be a FreeBSD specific problem as the same PCIe x800 works fine with the OSS drivers under Linux, but no on on the freebsd-x11 lists seems to have any ideas, and I'm running out of ideas. I thought some of the great minds on this list might be able to shed some light. Any ideas? Thanks! 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 - 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: What can the FSF do to help?
Patrick McFarland wrote: As such, I'd love to use the R300 driver (and maybe even help development, if not just testing), but as it stands, on my run of the mill RV350 AP revision hardware (a Radeon 9600), initialization of X hangs if I enable DRI, but continues fine if DRI is off (ie, its not the 2D driver's own code hanging X). This I'd think is a severe bug, as RV350 hardware of all revisions is quite common (and, in fact, many revisions of RV350 hardware do work fine), but adding features over fixing bugs like this is, well, stupid, especially if I, and others like me in my position, cannot use them. Just as a point of reference... I have two of those RV350 revisions that work fine. Indeed, they both worked fine even before the 9800 fix went into the ati driver a while back. In my case, the cards care both: pci bus 0x0001 cardnum 0x00 function 0x00: vendor 0x1002 device 0x4153 ATI Technologies Inc RV350 AS [Radeon 9550] Patrick, did you try disabling AGP support and using the card as a generic PCI card using the BusType option? Sorry if this is covered in your previous bug report... Adam - 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: results of Radeon 9800 Pro test
Jacek Poplawski wrote: I tried doom3, while it doesn't work correctly with default renderer, it is quite playable with arb renderer. And it has much more than 5fps. Sorry, but not here it doesn't. I updated my drivers from CVS on August 29th and have just run demo1. 800x600 resolution, lowest quality video settings, arb renderer, on a dual 2.8 gig xeon with a gig of RAM. The demo averaged 5.6 FPS. Have you run demo1? What's your system configuration? Made any changes to your doom config file? Anything special in your .drirc? Adam - 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: results of Radeon 9800 Pro test
Jacek Poplawski wrote: Hi, I removed fglrx from my system yesterday. I was using it to initialize my Radeon 9800 Pro before (old DRI driver crashed without that). Then I installed new drivers, and I tested following applications: snip I think that it is safe to say that Radeon 9800 Pro works stable and r300 driver is the best OpenGL implementation I ever seen in Linux (much more stable than radeon, r200 or voodoo3, much more correct than mga or i810 and of course much more free than propertiary drivers). I hope that PCI-E cards are working great, too. I will check it within next few weeks. While the r300 driver has, indeed, come a long way, I'm hesitant to call it the best OpenGL implementation I've ever seen. As of July, the r200 driver still out performed the r300 driver at nearly every OpenGL application and game on my system. I do agree with your assessment that the r300 driver is much more stable than most of the other open source drivers, however. Adam - 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: results of Radeon 9800 Pro test
Jacek Poplawski wrote: While the r300 driver has, indeed, come a long way, I'm hesitant to call it the best OpenGL implementation I've ever seen. As of July, the r200 driver still out performed the r300 driver at nearly every OpenGL application and game on my system. But the problem is that r200 is not stable (at least on my system) which makes it unusable. It's very annoying when you want to play Enemy Territory for few hours or create something in complex Blender, and then see a crashed system. I've noticed that performance drops when software changes OpenGL states too often. I am not sure how it works on other drivers/implementations. The only real stability problems I've had with the r200 driver recently is when I have multiple GL contexts running, and one of them goes beyond the 2048x2048 hardware limit (in terms of location, not size). So, for example, when running a mergedfb setup at 2560x2048 and having GL screensavers running on both heads. I have no problems playing doom3 or quake4 for hours on end with the r200 driver and it is significantly faster than with the r300 driver. Having said that, there's such progress being made on the r300 driver that I rarely switch back to my9000Pro unless I really need to for some reason. Adam - 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
Xi Graphics marketing.
FYI, Apparently Xi Graphics has kicked off a new marketing campaign again... This PDF is linked to from their homepage: ftp://ftp.xig.com/pub/docs/State_of_Accelerated-X.pdf Adam - 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: 9800 lockups, why fixing them seems to be that hard ?
Jacek Poplawski wrote: On 6/18/06, *Adam K Kirchhoff* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:Jacek Poplawski wrote: It's interesting that both Blender and Neverball work for you. I tried them (about a month ago) with the r300 driver from CVS, and was getting immediate lockups when launching those two applications. I had immediate lookups only when I forgot to start fglrx or when I tried applications like oolite. Well, the only time I have immediate lockups are when I use nearly anything other than glxgears and I haven't started X with fglrx first. And, even then, the lockups are simply X, not the full machine. I can remotely log in and reboot (though I can't kill the GL application... That seems to cause even more problems). This is an improvement from months ago when the entire machine would essentially lockup (the cursor would move, but I couldn't kill X and couldn't ssh in). As long as I use fglrx first (and simply loading the 2D driver seems to work, loading the kernel module and 3D drivers are unnecessary) I don't get any real lockups. Googleearth hangs at times, but I can just ssh in and kill it. Adam -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 9800 lockups, why fixing them seems to be that hard ?
Jacek Poplawski wrote: I use 9800 Pro and it works stable under two circumstances: - start X with fglrx once (I put it in my /etc/rc.d/rc.local) Unfortunately, that's not an option for users where fglrx won't work :-) - avoid some applications Stuff like Blender, Enemy Territory or NeverBall works great. Stuff like Cube works without acceleration. Stuff like oolite crashes whole system. Oh, and you have to set R300_FORCE_R300, I have no idea why this is still required. It's required so that unsuspecting 9800 users won't get lockups when using various applications. It's interesting that both Blender and Neverball work for you. I tried them (about a month ago) with the r300 driver from CVS, and was getting immediate lockups when launching those two applications. I'll update my drivers and give them another shot tomorrow. Adam -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Rune Petersen wrote: Adam K Kirchhoff wrote: Rune Petersen wrote: set r_renderer arb r_renderer arb2 is broken. My guess is that with Mesa 6.5, Doom 3 (demo) defaults to arb unlike with Mesa CVS. Another thing: I think we need an up-to-date list of what is working and what is still missing. I have a small list for my own enjoyment, but it is far from complete: http://megahurts.dk/rune/r300_status.html Rune Petersen Well, certainly one of the biggest bugs (lockups with the 9800) isn't on there :-) I added a list of working cards and a list of non-working cards, both incomplete, but it's a start :) When you get a chance, you can add X700 (specifically AGP, though I imagine PCIe would work) to the list of working cards. Adam -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Rune Petersen wrote: set r_renderer arb r_renderer arb2 is broken. My guess is that with Mesa 6.5, Doom 3 (demo) defaults to arb unlike with Mesa CVS. Another thing: I think we need an up-to-date list of what is working and what is still missing. I have a small list for my own enjoyment, but it is far from complete: http://megahurts.dk/rune/r300_status.html Rune Petersen Well, certainly one of the biggest bugs (lockups with the 9800) isn't on there :-) Adam -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Doom3/r300 problems.
So last night I decided to give the new vertex programs on the r200 driver a shot and to see how doom3 stacked up with the r200 driver vs the fglrx driver now. With both drivers, I was getting approximately 12 FPS with demo1 (with the r200 renderer, of course). This morning I decided to give the r300 driver a shot, but ran into some problems: http://68.44.156.246/shot-current.jpg Everything is shiny and textures are all screwed up :-) Same room, but with the Mesa 6.5 drivers: http://68.44.156.246/shot-6.5.jpg If this isn't something currently being worked on, I'll go ahead and open up a new bug for it. Adam -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Rune Petersen wrote: Adam K Kirchhoff wrote: So last night I decided to give the new vertex programs on the r200 driver a shot and to see how doom3 stacked up with the r200 driver vs the fglrx driver now. With both drivers, I was getting approximately 12 FPS with demo1 (with the r200 renderer, of course). This morning I decided to give the r300 driver a shot, but ran into some problems: http://68.44.156.246/shot-current.jpg Everything is shiny and textures are all screwed up :-) Same room, but with the Mesa 6.5 drivers: http://68.44.156.246/shot-6.5.jpg If this isn't something currently being worked on, I'll go ahead and open up a new bug for it. set r_renderer arb r_renderer arb2 is broken. My guess is that with Mesa 6.5, Doom 3 (demo) defaults to arb unlike with Mesa CVS. Sorry, but according to the output from doom3, it's using the ARB render path for both 6.5 and CVS. Adam -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Rune Petersen wrote: Adam K Kirchhoff wrote: Rune Petersen wrote: Adam K Kirchhoff wrote: So last night I decided to give the new vertex programs on the r200 driver a shot and to see how doom3 stacked up with the r200 driver vs the fglrx driver now. With both drivers, I was getting approximately 12 FPS with demo1 (with the r200 renderer, of course). This morning I decided to give the r300 driver a shot, but ran into some problems: http://68.44.156.246/shot-current.jpg Everything is shiny and textures are all screwed up :-) Same room, but with the Mesa 6.5 drivers: http://68.44.156.246/shot-6.5.jpg If this isn't something currently being worked on, I'll go ahead and open up a new bug for it. set r_renderer arb r_renderer arb2 is broken. My guess is that with Mesa 6.5, Doom 3 (demo) defaults to arb unlike with Mesa CVS. Sorry, but according to the output from doom3, it's using the ARB render path for both 6.5 and CVS. Not for me unless I set r_renderer to arb. You're absolutely right, my mistake... Not sure how I missed that :-) However, with drivers from CVS, I do get a segfault when quitting doom3, which I believe has been brought up here before: idRenderSystem::Shutdown() doom.x86: r300_context.c:389: r300FreeGartAllocations: Assertion `r300-rmm-u_l ist[i].pending' failed. signal caught: Aborted si_code -6 Trying to exit gracefully.. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: _glapi_add_dispatch
Brian Paul wrote: Alan Hourihane wrote: On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote: On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Poplawski wrote: On 5/30/06, Pedro Maia [EMAIL PROTECTED] wrote: To run quake2 please use, LD_PRELOAD=path/to/libGL.so quake2 In my case it works fine, with that trick , without it didn't work. But why it didn't work? It opens /usr/lib/libGL.so for sure, because without it even software accelerated OpenGL doesn't work in the game. Quake2 is the only application I tried which loads libGL with dlopen. I think the way that Quake2 dlopens libGL prevents some symbols in libGL from being exposed to the driver. I seem to remember alanh mentioning something about this, but I don't recall the details. My dlopen-fu is lacking, so I'm not sure what the problem or the solution might be. Basically, what happens is this A game may try to dlopen libGL itself at runtime rather than linking at build time. So, the linux dllinker does not bother to search for symbols to resolve that exist in the DRI driver. I'm not sure exactly why it doesn't though. Actually I do remember my theory When a program is linked at build time, libGL is the one responsible for dlload'ing the DRI driver and resolves symbols perfectly well with the current RTLD flags. But when the program dlopen's libGL itself, it resolves what it currently has access to which the DRI driver isn't actually loaded. I suspect for this to work the libGL's dlinit() routine (that's called when dlopen'ed) would need to someone link in the correct DRI driver at that time - but I'm pretty sure all the available details to do that wouldn't be available. I don't think there's any easy fix, which is why I resorted to the LD_PRELOAD approach. This may all be bogus though. This sounds related to the -Bsymbolic linker option. When you build a shared library, the -Bsymbolic option tells the linker to resolve references in the shared library to symbols defined within the library, in preference to other locations. For example, if libGL had a function called init_driver(), -Bsymbolic would ensure that references to init_driver() were resolved to that function, and not another init_driver() function that might be defined in the application itself. The lack of -Bsymbolic in some libraries has caused me grief in the past. I've also raised this issue with some commercial OpenGL vendors. -Brian -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel Just a quick FYI... Something has changed in my installation recently (in the last week) to create the need for LD_PRELOAD in games that previously didn't need it. I don't know if it's the 'apt-get upgrade' I did or the upgrade of the Mesa drivers, but suddenly Orbz and MarbleBlast, both of which previously worked fine, now need to be run with LD_PRELOAD. I imagine that this is going to become an even bigger issue as games and applications are added to KDE/Gnome/XFCE menus and users can't figure out why those applications are running so slowly. Adam -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Neverball reflections
Philipp Klaus Krause wrote: Adam K Kirchhoff wrote: I was running some test comparing the r200 vs the r300 driver this morning, and noticed a slight rendering issue with the r200 driver with reflections in the game neverball. I suggest you file a bug, so that this problems isn't forgotten as completly as it would be when only mentioned on the mailing list. Philipp I normally would, but I'm unable to reproduce it consistently. Sometimes it appears correct, sometimes it doesn't. Till I can confirm that it's not a bug with the game, I'm going to hold off on adding it to the bug database. Adam -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Neverball reflections
I was running some test comparing the r200 vs the r300 driver this morning, and noticed a slight rendering issue with the r200 driver with reflections in the game neverball. http://68.44.156.246/neverball-9200.jpg As you can see, the reflections for the coins on the two bridges on the right are displayed even where there is no reflective surface. At first I thought this was a problem with the game, but when I tried with the drivers from XiG, this is what I saw: http://68.44.156.246/neverball-9200-xig.jpg The reflection is only visible on the reflective surface. For anyone interested, the r300 driver doesn't handle the refelective surfaces at all: http://68.44.156.246/neverball-9800.jpg You'll also be able to notice the framerate for the three drivers. Though the images only show a single frame, the difference in the framerate is pretty consistent. The XiG driver is generally at least 10-20 FPS higher than the r200 driver in neverball and Orbz. With other games (NWN, Q3A, for example) I've noticed that the difference is less (and in Q4, the XiG driver is a few FPS slower, probably due to hyperz support in the r200 driver since disabling that drops the FPS to roughly the same as the XiG driver). Aapo, I also tested the r200 driver after commenting out the ctx-Array.LockFirst = first; and ctx-Array.LockCount = count; lines as you suggested. I didn't see any real slowdown in NWN when I did that. Adam -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
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
freebsd-dri from CVS
Just wanted to point out that freebsd-dri no longer builds on two of my machines running -CURRENT. It manages to build libGL.so.1, but dies with Bad fd number when it goes to build the DRI drivers: [ [EMAIL PROTECTED] - ~/saved/source/Mesa ]: make freebsd-dri (cd configs rm -f current ln -s freebsd-dri current) make default Making sources for freebsd-dri gmake: Nothing to be done for `default'. gmake[1]: Entering directory `/home/adamk/saved/source/Mesa/src/mesa' gmake[2]: Entering directory `/home/adamk/saved/source/Mesa/src/mesa/x86' gmake[2]: Nothing to be done for `default'. gmake[2]: Leaving directory `/home/adamk/saved/source/Mesa/src/mesa/x86' gmake[2]: Entering directory `/home/adamk/saved/source/Mesa/src/mesa/x86-64' gmake[2]: Nothing to be done for `default'. gmake[2]: Leaving directory `/home/adamk/saved/source/Mesa/src/mesa/x86-64' cd drivers/dri ; gmake gmake[2]: Entering directory `/home/adamk/saved/source/Mesa/src/mesa/drivers/dri' echo radeon r200 r300 radeon r200 r300 radeon gmake[3]: Entering directory `/home/adamk/saved/source/Mesa/src/mesa/drivers/dri/radeon' touch depend makedepend -fdepend -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DRADEON_COMMON=0 -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../../drm/shared-core -I../../../../../include -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../../src/mesa/main -I../../../../../s rc/mesa/glapi -I../../../../../src/mesa/math -I../../../../../src/mesa/transform -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/local/include `pkg-config --cflags libdrm` ../../common/driverfuncs.c ../common/utils.c ../common/texmem.c ../common/vblank.c ../common/dri_util.c ../common/xmlconfig.c ../common/drirenderbuffer.c radeon_context.c radeon_ioctl.c radeon_lock.c radeon_screen.c radeon_state.c rad eon_state_init.c radeon_tex.c radeon_texmem.c radeon_texstate.c radeon_tcl.c radeon_swtcl.c radeon_span.c radeon_maos.c radeon_sanity.c radeon_vtxfmt.c radeon_vtxfmt_c.c radeon_vtxfmt_sse.c radeon_vtxfmt_x86.c\ /dev/null Syntax error: Bad fd number gmake[3]: *** [depend] Error 2 gmake[3]: Leaving directory `/home/adamk/saved/source/Mesa/src/mesa/drivers/dri/radeon' gmake[2]: *** [subdirs] Error 1 gmake[2]: Leaving directory `/home/adamk/saved/source/Mesa/src/mesa/drivers/dri' gmake[1]: *** [linux-solo] Error 2 gmake[1]: Leaving directory `/home/adamk/saved/source/Mesa/src/mesa' gmake: *** [default] Error 2 *** Error code 1 --- 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
FreeBSD -CURRENT + DRM CVS
Just want to give a heads up that the above combination is broken again: cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I.. -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_state.c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_state.c: In function `radeon_surface_free': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_state.c:1999: error: incompatible types in assignment /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_state.c: In function `radeon_cp_cmdbuf': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_state.c:2779: error: incompatible types in assignment *** Error code 1 Stop in /home/adamk/saved/source/drm/bsd-core/radeon. *** Error code 1 Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Blender + r100
I have a radeon mobility U1, with the latest and greatest from Mesa and drm CVS. Blender launches fine, but as soon as I right click on a light souce to move it around, the display gets very screwed up, making the application unusable. http://68.44.156.246/blender.png Any ideas before I open this as a bug report? I've also noticed that doing the same thing (rigt clicking on a light souce) on any r300 card I have will cause blender to seg fault using the latest r300 drivers from CVS. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Blender + r100
On Wednesday 15 February 2006 14:34, Roland Scheidegger wrote: Adam K Kirchhoff wrote: I have a radeon mobility U1, with the latest and greatest from Mesa and drm CVS. Blender launches fine, but as soon as I right click on a light souce to move it around, the display gets very screwed up, making the application unusable. http://68.44.156.246/blender.png Any ideas before I open this as a bug report? There are already two bugs about this (different drivers, but same cause): https://bugs.freedesktop.org/show_bug.cgi?id=5601 https://bugs.freedesktop.org/show_bug.cgi?id=2365 I've also noticed that doing the same thing (rigt clicking on a light souce) on any r300 card I have will cause blender to seg fault using the latest r300 drivers from CVS. Might also be related. Roland I'll refrain from opening another bug for the r300 driver then. Is there any information that I can give (and that the developers don't already have) to help track down this bug. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Problems compiling.
For the past day or two I've been getting the following error when trying to compile DRI from Mesa CVS: gcc -c -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa/main -I../../../src/mesa/glapi -I../../../src/mesa/drivers/dri/common `pkg-config --cflags libdrm` -I/usr/X11R6/include -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER -Wmissing-prototypes -g -std=c99 -Wundef -fPIC -ffast-math -I/usr/X11R6/include -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER glxcmds.c -o glxcmds.o glxcmds.c:1726: warning: no previous prototype for 'glXSwapIntervalMESA' glxcmds.c:1758: warning: no previous prototype for 'glXGetSwapIntervalMESA' glxcmds.c:1788: warning: no previous prototype for 'glXBeginFrameTrackingMESA' glxcmds.c:1808: warning: no previous prototype for 'glXEndFrameTrackingMESA' glxcmds.c:1829: warning: no previous prototype for 'glXGetFrameUsageMESA' glxcmds.c:1857: warning: no previous prototype for 'glXQueryFrameTrackingMESA' glxcmds.c:2595: warning: no previous prototype for 'glXBindTexImageEXT' glxcmds.c: In function `glXBindTexImageEXT': glxcmds.c:2618: error: `X_GLXvop_BindTexImageEXT' undeclared (first use in this function) glxcmds.c:2618: error: (Each undeclared identifier is reported only once glxcmds.c:2618: error: for each function it appears in.) glxcmds.c: At top level: glxcmds.c:2636: warning: no previous prototype for 'glXReleaseTexImageEXT' glxcmds.c: In function `glXReleaseTexImageEXT': glxcmds.c:2659: error: `X_GLXvop_ReleaseTexImageEXT' undeclared (first use in this function) gmake: *** [glxcmds.o] Error 1 *** Error code 1 Stop in /home/adamk/saved/source/Mesa/src. This has been happening on two machines, one running Debian and one running FreeBSD. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Fix DRM on FreeBSD (also makes my X600 finally work)
FYI, this patch works here. Now I have a working current DRI with DRM
1.22.0.
Adam
Hi list!
I am very happy to announce that I got my Radeon X600 working on both
Linux/i386 and FreeBSD/amd64. I needed to apply Benjamin's latest
patches and also the small attached patch for FreeBSD. The biggest
problem (that caused the crahes on FreeBSD) was that the virtual field
of the struct drm_sg_mem_t was never initialized.
BTW, I think the PCI ID of this card (0x5b62) should be added to the
drm_pciids.txt
Thanks for your great work!
Markus
Index: drmP.h
===
RCS file: /cvs/dri/drm/bsd-core/drmP.h,v
retrieving revision 1.73
diff -w -u -d -r1.73 drmP.h
--- drmP.h8 Nov 2005 20:24:59 - 1.73
+++ drmP.h29 Jan 2006 07:31:28 -
@@ -341,7 +341,7 @@
#define DRM_COPY_FROM_USER_IOCTL(kern, user, size) \
if ( IOCPARM_LEN(cmd) != size) \
return EINVAL; \
- kern = *user;
+ memcpy(kern, user, size);
#define DRM_COPY_TO_USER(user, kern, size) \
copyout(kern, user, size)
#define DRM_COPY_FROM_USER(kern, user, size) \
Index: drm_scatter.c
===
RCS file: /cvs/dri/drm/bsd-core/drm_scatter.c,v
retrieving revision 1.11
diff -w -u -d -r1.11 drm_scatter.c
--- drm_scatter.c 26 Apr 2005 05:19:11 - 1.11
+++ drm_scatter.c 29 Jan 2006 07:31:28 -
@@ -35,7 +35,7 @@
void drm_sg_cleanup(drm_sg_mem_t *entry)
{
- free((void *)entry-handle, M_DRM);
+ free(entry-virtual, M_DRM);
free(entry-busaddr, M_DRM);
free(entry, M_DRM);
}
@@ -72,8 +72,9 @@
return ENOMEM;
}
- entry-handle = (long)malloc(pages PAGE_SHIFT, M_DRM,
+ entry-virtual = malloc(pages PAGE_SHIFT, M_DRM,
M_WAITOK | M_ZERO);
+ entry-handle = (unsigned long)entry-virtual;
if (entry-handle == 0) {
drm_sg_cleanup(entry);
return ENOMEM;
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Marbleblast + r300
On Thursday 26 January 2006 08:41, Jerome Glisse wrote: On 1/26/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Marbleblast, a game from GarageGames, seems to have an issue with the r300 driver... The game crashes when it goes to start a new level. It crashes with: drmRadeonCmdBuffer: -22 (exiting) drmRadeonCmdBuffer: -22 (exiting) dmesg shows: [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=3) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed This likely due to an old drm, Aapo added a new reg lately to fix texture upload issue. Thus you need a new drm which accept to program this reg. best, Jerome Glisse How new of a DRM do I need? :-) This is what I have that isn't working: [drm] Initialized drm 1.0.1 20051102 [drm] Initialized radeon 1.22.0 20060120 on minor 0: PCI device 1002:5e4b (ATI Technologies Inc) Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Current DRM on FreeBSD
Just thought I'd point out that DRM has stopped compiling on FreeBSD again: === radeon (all) Warning: Object directory not changed from original /home/adamk/saved/source/drm/bsd-core/radeon cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I.. -I. -I@ -I@/contrib/altq -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_state.c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_state.c: In function `radeon_cp_cmdbuf': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_state.c:2750: error: incompatible types in assignment *** Error code 1 Stop in /home/adamk/saved/source/drm/bsd-core/radeon. *** Error code 1 DRI, from Mesa CVS, still builds, but falls back to indirect rendering since it needs DRM 1.22.x to run. Isn't it possible to only make newer functionality in the DRI drivers depend on newer DRM? This way, users stuck with a particular version of the DRM still have functional DRI drivers, even if they are missing out on newer features of the driver? Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status
On Wednesday 25 January 2006 19:01, Aapo Tahkola wrote: On Wed, 25 Jan 2006 20:29:05 +0100 khaqq [EMAIL PROTECTED] wrote: On Wed, 25 Jan 2006 11:51:17 +0100 Kristoffer [EMAIL PROTECTED] wrote: I'm thinking of trying the radeon driver again, but i'm wondering wether or not it will ever catch up with the fglrx driver on speed? what's the status of this, or goal? and what's the status on 9800 pro dual monitor support with 3d? thanks for all your hard work anyway. my guess is that you're going to get either silence from the list, or a answer to your own question by doing benchmarks-type response. the only thing I can say is that fglrx is better than dri on some aspects of GL, unfortunatly this is what is used in UT2K3 / UT2K4 for example. there are plans to fix this, as time allows. The ut2k4 problem(s) have been in a semi-fixed state for a while now. Bits and bolts dealing with it arent just enabled by default because quite a few changes are needed to get it fully transparent. Couple shots: http://www.rasterburn.org/~aet/ut2k4_tweaked.png http://www.rasterburn.org/~aet/ut2k4_vanilla.png Do these fixes remove the need to disable s3tc to avoid the flickering tiling problem? And just a general warning to the original writer of the original question about the r300 driver on 9800 hardware: there are problems with pretty regular lockups. Other r300 hardware (X700, X800, for example) don't seem to have this issue, though. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Marbleblast + r300
Marbleblast, a game from GarageGames, seems to have an issue with the r300 driver... The game crashes when it goes to start a new level. It crashes with: drmRadeonCmdBuffer: -22 (exiting) drmRadeonCmdBuffer: -22 (exiting) dmesg shows: [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=3) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed If anyone is interested, there is a demo available: http://www.garagegames.com/demos/browse/game/ Orbz, another game from them, seems to work fine. ** Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
On Thu, 2006-01-05 at 06:11 -0500, Adam K Kirchhoff wrote: Anish Mistry wrote: On Wednesday 04 January 2006 10:05 pm, khaqq wrote: On Thu, 5 Jan 2006 04:51:31 + Aapo Tahkola [EMAIL PROTECTED] wrote: On Wed, 04 Jan 2006 21:07:41 -0400 Jon [EMAIL PROTECTED] wrote: I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing with r300 DRI module. I tried Quake3 (wont get past beginning of opening game video, locks computer solid) and Xmoto (lasts for a few seconds than computer locks) GLXGears runs fine and for a long time, no freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 6.0 Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel module and the r300 DRI module. Is their anything I can test or do? This is a known problem with r9500, r9700 and r9800 cards. You can initialize the card with official drivers. No other fix beyond that exist nor is being planned on. Unless I am missing something, I believe there are no official drivers for FreeBSD from ATI at this point. Someone is working with ATI on it and just posted something last week to the FreeBSD current mailling list. A search should turn up something. I don't know if that'll help at all in this case since it (currently) doesn't have a port of the kernel module and doesn't support any 3D functionality. I'm guessing that it probably won't initialize the card properly, though I could be wrong Hmmm, I might give that a shot next week, though, just to see. Adam Apparently I was wrong. Launching X with the port of the fglrx driver does seem to initialize the card properly, despite the fact that the fglrx port doesn't have a working kernel module. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
Jerome Glisse wrote: On 1/7/06, Jerome Glisse [EMAIL PROTECTED] wrote: On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Have you tried checking what's going on with the card memory map ? (values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE, CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ? There is definitely a bug or two lurking around when we have CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those lockups). It seems to be related to card memory map, with your patch (radeon mem fix) i have no lockups (at least no during last 10 minutes) but as i update many things and have tweaks in many place i will double check that... In the mean time if more people could test with your patch (even if their regression with it on some hardware) see if this fix the lockup for them. More people testing benh patch on radeon 9800 (or any other radeon that used to lockup) are welcome: http://lists.freedesktop.org/archives/xorg/2005-December/011679.html http://lists.freedesktop.org/archives/xorg/2005-December/011717.html It really seems to fix it. I have been on ut2004 for several minutes without a lockups while it used lockup pretty fast the card before. I will give a look a fglrx way to setup all this. best, Jerome Glisse Well, I was able to launch Blender, open up a few files, and play neverball for a while. That's a first! I haven't tested it beyond that, yet, but this is definitely an improvement. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
Benjamin Herrenschmidt wrote: On Thu, 2006-01-05 at 11:05 +0100, Jerome Glisse wrote: On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2006-01-05 at 02:30 +0100, Jerome Glisse wrote: On 1/5/06, Jon [EMAIL PROTECTED] wrote: I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing with r300 DRI module. I tried Quake3 (wont get past beginning of opening game video, locks computer solid) and Xmoto (lasts for a few seconds than computer locks) GLXGears runs fine and for a long time, no freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 6.0 Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel module and the r300 DRI module. Is their anything I can test or do? -- Thanks I have been trying to track down the issue during last few month. No success so far, maybe i am not a good hunter ;). Anyway could you test to first run an xserver with fglrx (no need for the drm module) and then run a server with r300 and see if you still have lockup (you shouldn't) thus i know you probably face the same lockup as i do. Have you tried checking what's going on with the card memory map ? (values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE, CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ? There is definitely a bug or two lurking around when we have CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those lockups). So far i have quite ignored such things. I will take a closer look to that, i haven't even tested your patch on that. I will give it a try. You may have to hack the kernel DRM too so that it puts the same values in there, currently, it's broken too. Ben. Is it safe to say that this is only a problem for cards with 256 bit memory interfaces? From http://en.wikipedia.org/wiki/Radeon_9700_core: Radeon 9700 275 256-bit Radeon 9800 325 256-bit Radeon 9700 Pro 325 256-bit Radeon 9800 Pro 380 256-bit Radeon 9800 XT 412 256-bit Do all these experience the same lockups? Then with the X300 - X850, I think it's only the X800 and X850 cards have 256-bit interfaces, correct? Do X800 cards experience the same lockups? Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
Alex Deucher wrote: On 1/6/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Benjamin Herrenschmidt wrote: On Thu, 2006-01-05 at 11:05 +0100, Jerome Glisse wrote: On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2006-01-05 at 02:30 +0100, Jerome Glisse wrote: On 1/5/06, Jon [EMAIL PROTECTED] wrote: I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing with r300 DRI module. I tried Quake3 (wont get past beginning of opening game video, locks computer solid) and Xmoto (lasts for a few seconds than computer locks) GLXGears runs fine and for a long time, no freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 6.0 Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel module and the r300 DRI module. Is their anything I can test or do? -- Thanks I have been trying to track down the issue during last few month. No success so far, maybe i am not a good hunter ;). Anyway could you test to first run an xserver with fglrx (no need for the drm module) and then run a server with r300 and see if you still have lockup (you shouldn't) thus i know you probably face the same lockup as i do. Have you tried checking what's going on with the card memory map ? (values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE, CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ? There is definitely a bug or two lurking around when we have CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those lockups). So far i have quite ignored such things. I will take a closer look to that, i haven't even tested your patch on that. I will give it a try. You may have to hack the kernel DRM too so that it puts the same values in there, currently, it's broken too. Ben. Is it safe to say that this is only a problem for cards with 256 bit memory interfaces? From http://en.wikipedia.org/wiki/Radeon_9700_core: Radeon 9700 275 256-bit Radeon 9800 325 256-bit Radeon 9700 Pro 325 256-bit Radeon 9800 Pro 380 256-bit Radeon 9800 XT 412 256-bit Do all these experience the same lockups? I think 9500s have the same problem. I have a 9550 which doesn't experience the lockups. Then with the X300 - X850, I think it's only the X800 and X850 cards have 256-bit interfaces, correct? Do X800 cards experience the same lockups? no problems on my pcie x800 Oh well... Thought I saw a pattern. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
Aapo Tahkola wrote: On Wed, 04 Jan 2006 21:07:41 -0400 Jon [EMAIL PROTECTED] wrote: I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing with r300 DRI module. I tried Quake3 (wont get past beginning of opening game video, locks computer solid) and Xmoto (lasts for a few seconds than computer locks) GLXGears runs fine and for a long time, no freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 6.0 Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel module and the r300 DRI module. Is their anything I can test or do? This is a known problem with r9500, r9700 and r9800 cards. You can initialize the card with official drivers. No other fix beyond that exist nor is being planned on. My only concern is that the r300 driver is now making it onto more and more machines, either through Xorg, or just by being packaged by their distribution. Many of these machines will have those cards that will lockup almost immediately when a 3D application (other than glxgears) is launched. Instead of having all these people think that Xorg (or the DRI) is just an unstable POS, it might make sense to have the server automatically disable 3D on those cards unless the users specifies an option (EnableUnstableDRIon9800Hardware) in their xorg.conf file. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
Anish Mistry wrote: On Wednesday 04 January 2006 10:05 pm, khaqq wrote: On Thu, 5 Jan 2006 04:51:31 + Aapo Tahkola [EMAIL PROTECTED] wrote: On Wed, 04 Jan 2006 21:07:41 -0400 Jon [EMAIL PROTECTED] wrote: I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing with r300 DRI module. I tried Quake3 (wont get past beginning of opening game video, locks computer solid) and Xmoto (lasts for a few seconds than computer locks) GLXGears runs fine and for a long time, no freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 6.0 Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel module and the r300 DRI module. Is their anything I can test or do? This is a known problem with r9500, r9700 and r9800 cards. You can initialize the card with official drivers. No other fix beyond that exist nor is being planned on. Unless I am missing something, I believe there are no official drivers for FreeBSD from ATI at this point. Someone is working with ATI on it and just posted something last week to the FreeBSD current mailling list. A search should turn up something. I don't know if that'll help at all in this case since it (currently) doesn't have a port of the kernel module and doesn't support any 3D functionality. I'm guessing that it probably won't initialize the card properly, though I could be wrong Hmmm, I might give that a shot next week, though, just to see. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
Michel Dänzer wrote: On Thu, 2006-01-05 at 06:09 -0500, Adam K Kirchhoff wrote: [...] it might make sense to have the server automatically disable 3D on those cards unless the users specifies an option (EnableUnstableDRIon9800Hardware) in their xorg.conf file. Agreed, except that IMHO it should be the standard (in some other drivers) Option DRI, the default of which should be something like * (at least problematic) r300 cards: disabled * other cards: current behaviour (enabled if the dri module is loaded, disabled otherwise) When the option is enabled explicitly, the driver should load the dri module if necessary. This option will also be useful to manage which of several cards enables the DRI. Now, somebody get his hands dirty. :) As long as there's an explanation in the Xorg logfile which explains why the DRI option was disabled in that case :-) Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FreeBSD CURRENT + DRM + agp_ati
Felix Kühling wrote: Am Donnerstag, den 29.12.2005, 20:40 -0500 schrieb Adam K Kirchhoff: [snip] What's really bizarre, however, is that if I set hw.dri.0.debug to 1, glxgears gets roughly 200 FPS, faster than software Mesa, but slower than it can get (undoubtedly due to the massive amounts of debugging information that the kernel is logging). I tried a few more GL programs, all from the xscreensaver package. glforestfire also appear to display less than a frame per second. Same with flip-flop and flyingtoasters. flurry, on the other hand, is quite smooth and the FPS meter shows roughly 30 fps. Any ideas? Thanks! So not only does setting the debug sysctl seem to affect the framerate, so does displaying the framerate within the application. If I launch any of those xscreensaver apps with the -fps option (including flurry, glforestfire, flipflop, queens, and flyingtoasters), I get quite reasonable framerates. If I launch them without the -fps option, I get 1 FPS if I'm lucky (and I mean that literally... The window only updates itself once every second, if that). -fps causes a software fallback which implies a glFinish. Without -fps it hits no software fallbacks and interrupt-based frame-throttling will be used. Maybe interrupts get lost so that you time-out in the frame-throttling code (radeon_wait_irq has a 3-second time-out ATM). That would explain low frame rates. With debugging output the waiting condition is probably true when it gets to radeon_wait_irq most of the time, so it doesn't have to wait - no time-out. Can you try playing with the fthrottle_mode option to test that theory anyway. fthrottle_mode=0 glxgears would run glxgears with busy-waiting instead of interrupts. Regards, Felix glxgears (and the few other GL apps I've just tried) runs much more like expected with fthrottle_mode set to 0 :-) Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
FreeBSD CURRENT + DRM + agp_ati
I sent this to the freebsd-current mailing list yesterday, but haven't heard back from anyone. And, since I'm not sure if this is an AGP issue or a DRM specific issue, I thought I'd mention it here as well: When I boot up, the agp driver is loaded properly: agp0: ATI RS100 AGP bridge on hostb0 When I launch X, the drm and radeon modules are loaded: drm0: ATI Radeon RS100 Mobility U1 on vgapci0 info: [drm] AGP at 0xd400 64MB info: [drm] Initialized radeon 1.19.0 20050911 According to the X server, Direct Rendering is enabled: (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:05.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc3ce7000 (II) RADEON(0): [drm] mapped SAREA 0xc3ce7000 to 0x283d3000 (II) RADEON(0): [drm] framebuffer handle = 0xe000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x0f000207 [AGP 0x/0x; Card 0x1002/0x4336] (II) RADEON(0): [agp] 32768 kB allocated with handle 0xc381f700 (II) RADEON(0): [agp] ring handle = 0xd400 (II) RADEON(0): [agp] Ring mapped at 0x2c433000 (II) RADEON(0): [agp] ring read ptr handle = 0xd4101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x282df000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xd4102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x2c534000 (II) RADEON(0): [agp] GART texture map handle = 0xd4302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x2c734000 (II) RADEON(0): [drm] register handle = 0xd010 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 32 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 29 MB for GART textures snip (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 9 (II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 (II) RADEON(0): Direct rendering enabled According to glxgears, the DRI driver is being used: name of display: scroll.netops.dci.lan:0.0 display: scroll.netops.dci.lan:0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20051013 AGP 4x NO-TCL OpenGL version string: 1.3 Mesa 6.5 However, glxgears is only giving me about 1 FPS. Most other GL applications (gltext, for example, from the xscreensaver package) are even slower. Software Mesa is even faster. The DRM driver is giving the following error message: error: [drm:pid51336:drm_alloc_resource] *ERROR* Couldn't find resource 0x0 The PID changes, of course, depending on the PID of the X server, but the rest of the error stays the same. What's really bizarre, however, is that if I set hw.dri.0.debug to 1, glxgears gets roughly 200 FPS, faster than software Mesa, but slower than it can get (undoubtedly due to the massive amounts of debugging information that the kernel is logging). I tried a few more GL programs, all from the xscreensaver package. glforestfire also appear to display less than a frame per second. Same with flip-flop and flyingtoasters. flurry, on the other hand, is quite smooth and the FPS meter shows roughly 30 fps. Any ideas? Thanks! Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net
Re: FreeBSD CURRENT + DRM + agp_ati
Adam K Kirchhoff wrote: I sent this to the freebsd-current mailing list yesterday, but haven't heard back from anyone. And, since I'm not sure if this is an AGP issue or a DRM specific issue, I thought I'd mention it here as well: When I boot up, the agp driver is loaded properly: agp0: ATI RS100 AGP bridge on hostb0 When I launch X, the drm and radeon modules are loaded: drm0: ATI Radeon RS100 Mobility U1 on vgapci0 info: [drm] AGP at 0xd400 64MB info: [drm] Initialized radeon 1.19.0 20050911 According to the X server, Direct Rendering is enabled: (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:05.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc3ce7000 (II) RADEON(0): [drm] mapped SAREA 0xc3ce7000 to 0x283d3000 (II) RADEON(0): [drm] framebuffer handle = 0xe000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x0f000207 [AGP 0x/0x; Card 0x1002/0x4336] (II) RADEON(0): [agp] 32768 kB allocated with handle 0xc381f700 (II) RADEON(0): [agp] ring handle = 0xd400 (II) RADEON(0): [agp] Ring mapped at 0x2c433000 (II) RADEON(0): [agp] ring read ptr handle = 0xd4101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x282df000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xd4102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x2c534000 (II) RADEON(0): [agp] GART texture map handle = 0xd4302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x2c734000 (II) RADEON(0): [drm] register handle = 0xd010 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 32 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 29 MB for GART textures snip (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 9 (II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 (II) RADEON(0): Direct rendering enabled According to glxgears, the DRI driver is being used: name of display: scroll.netops.dci.lan:0.0 display: scroll.netops.dci.lan:0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20051013 AGP 4x NO-TCL OpenGL version string: 1.3 Mesa 6.5 However, glxgears is only giving me about 1 FPS. Most other GL applications (gltext, for example, from the xscreensaver package) are even slower. Software Mesa is even faster. The DRM driver is giving the following error message: error: [drm:pid51336:drm_alloc_resource] *ERROR* Couldn't find resource 0x0 The PID changes, of course, depending on the PID of the X server, but the rest of the error stays the same. What's really bizarre, however, is that if I set hw.dri.0.debug to 1, glxgears gets roughly 200 FPS, faster than software Mesa, but slower than it can get (undoubtedly due to the massive amounts of debugging information that the kernel is logging). I tried a few more GL programs, all from the xscreensaver package. glforestfire also appear to display less than a frame per second. Same with flip-flop and flyingtoasters. flurry, on the other hand, is quite smooth and the FPS meter shows roughly 30 fps. Any ideas? Thanks! So not only does setting the debug sysctl seem to affect the framerate, so does displaying the framerate within the application. If I launch any of those xscreensaver apps with the -fps option (including flurry, glforestfire, flipflop, queens, and flyingtoasters), I get quite reasonable framerates. If I launch them without the -fps option, I get 1 FPS if I'm lucky (and I mean that literally... The window only updates
Re: FreeBSD DRM
Eric Anholt wrote: On Mon, 2005-12-26 at 15:49 -0500, Adam K Kirchhoff wrote: So at some point in the not too distant past, I managed to get current Mesa/DRI CVS working on my FreeBSD workstation (with an X700Pro). Just earlier today, though, I did a make buildworld and make installworld and suddenly Direct Rendering is not working any more. It turns out that -CURRENT on FreeBSD only has DRM version 1.19.0 but the version of Mesa/DRI I have installed requires version 1.20.0. Since I managed to get 1.20 installed before, I figured I could get it working again. Except that I can't. I pulled DRM from CVS, changed to the bsd-core directory, and did a make. It died with: /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c: In function `drm_device_find_capability': /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:62: error: `AGP_CAPPTR' undeclared (first use in this function) /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:62: error: (Each undeclared identifier is reported only once /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:62: error: for each function it appears in.) /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:66: warning: implicit declaration of function `AGP_CAPID_GET_NEXT_PTR' /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:66: warning: nested extern declaration of `AGP_CAPID_GET_NEXT_PTR' /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:71: warning: implicit declaration of function `AGP_CAPID_GET_CAP_ID' /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:71: warning: nested extern declaration of `AGP_CAPID_GET_CAP_ID' /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:45: warning: unused variable `ret' I started jumping back one month at a time, starting on December 2nd, going back to June 2nd. From June 2nd, this is what I get when I try make: /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c: In function `drm_device_is_agp': /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:50: error: structure has no member named `driver' /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:51: error: structure has no member named `driver' /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:68: error: `AGP_CAPPTR' undeclared (first use in this function) /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:68: error: (Each undeclared identifier is reported only once /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:68: error: for each function it appears in.) /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:72: warning: implicit declaration of function `AGP_CAPID_GET_NEXT_PTR' /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:72: warning: nested extern declaration of `AGP_CAPID_GET_NEXT_PTR' /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:77: warning: implicit declaration of function `AGP_CAPID_GET_CAP_ID' /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:77: warning: nested extern declaration of `AGP_CAPID_GET_CAP_ID' *** Error code 1 Different functions, but essentially the same errors. Yet I know that somehow I did manage to get 1.20.0 installed on this machine because I had it working before :-( Any ideas what I'm doing wrong? Thanks! Nothing. I need to commit jhb's DRM patch from the vga master device changes. Eric, Is there an ETA on when that patch will be committed? Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM + agp_ati + -CURRENT...
Adam K Kirchhoff wrote: As of yesterday morning, my HP Laptop, with a Mobility RS100 Radeon, is running -CURRENT. Unfortunately, I seem to be having problems with Direct Rendering. When I boot up, the agp driver is loaded properly: agp0: ATI RS100 AGP bridge on hostb0 When I launch X, the drm and radeon modules are loaded: drm0: ATI Radeon RS100 Mobility U1 on vgapci0 info: [drm] AGP at 0xd400 64MB info: [drm] Initialized radeon 1.19.0 20050911 According to the X server, Direct Rendering is enabled: (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:05.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc3ce7000 (II) RADEON(0): [drm] mapped SAREA 0xc3ce7000 to 0x283d3000 (II) RADEON(0): [drm] framebuffer handle = 0xe000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x0f000207 [AGP 0x/0x; Card 0x1002/0x4336] (II) RADEON(0): [agp] 32768 kB allocated with handle 0xc381f700 (II) RADEON(0): [agp] ring handle = 0xd400 (II) RADEON(0): [agp] Ring mapped at 0x2c433000 (II) RADEON(0): [agp] ring read ptr handle = 0xd4101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x282df000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xd4102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x2c534000 (II) RADEON(0): [agp] GART texture map handle = 0xd4302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x2c734000 (II) RADEON(0): [drm] register handle = 0xd010 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 32 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 29 MB for GART textures snip (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 9 (II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 (II) RADEON(0): Direct rendering enabled According to glxgears, the DRI driver is being used: name of display: scroll.netops.dci.lan:0.0 display: scroll.netops.dci.lan:0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20051013 AGP 4x NO-TCL OpenGL version string: 1.3 Mesa 6.5 However, glxgears is only giving me about 1 FPS. Most other GL applications (gltext, for example, from the xscreensaver package) are even slower. Software Mesa is even faster. The DRM driver is giving the following error message: error: [drm:pid51336:drm_alloc_resource] *ERROR* Couldn't find resource 0x0 The PID changes, of course, depending on the PID of the X server, but the rest of the error stays the same. What's really bizarre, however, is that if I set hw.dri.0.debug to 1, glxgears gets roughly 200 FPS, faster than software Mesa, but slower than it can get (undoubtedly due to the massive amounts of debugging information that the kernel is logging). Any ideas? Thanks! Adam Well, I've tried a few more GL programs, all from the xscreensaver package. glforestfire also appear to display less than a frame per second. Same with flip-flop and flyingtoasters. flurry, on the other hand, is quite smooth and the FPS meter shows roughly 30 fps. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https
FreeBSD DRM
So at some point in the not too distant past, I managed to get current Mesa/DRI CVS working on my FreeBSD workstation (with an X700Pro). Just earlier today, though, I did a make buildworld and make installworld and suddenly Direct Rendering is not working any more. It turns out that -CURRENT on FreeBSD only has DRM version 1.19.0 but the version of Mesa/DRI I have installed requires version 1.20.0. Since I managed to get 1.20 installed before, I figured I could get it working again. Except that I can't. I pulled DRM from CVS, changed to the bsd-core directory, and did a make. It died with: /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c: In function `drm_device_find_capability': /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:62: error: `AGP_CAPPTR' undeclared (first use in this function) /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:62: error: (Each undeclared identifier is reported only once /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:62: error: for each function it appears in.) /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:66: warning: implicit declaration of function `AGP_CAPID_GET_NEXT_PTR' /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:66: warning: nested extern declaration of `AGP_CAPID_GET_NEXT_PTR' /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:71: warning: implicit declaration of function `AGP_CAPID_GET_CAP_ID' /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:71: warning: nested extern declaration of `AGP_CAPID_GET_CAP_ID' /home/adamk/saved/source/drm.current/bsd-core/drm/../drm_agpsupport.c:45: warning: unused variable `ret' I started jumping back one month at a time, starting on December 2nd, going back to June 2nd. From June 2nd, this is what I get when I try make: /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c: In function `drm_device_is_agp': /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:50: error: structure has no member named `driver' /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:51: error: structure has no member named `driver' /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:68: error: `AGP_CAPPTR' undeclared (first use in this function) /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:68: error: (Each undeclared identifier is reported only once /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:68: error: for each function it appears in.) /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:72: warning: implicit declaration of function `AGP_CAPID_GET_NEXT_PTR' /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:72: warning: nested extern declaration of `AGP_CAPID_GET_NEXT_PTR' /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:77: warning: implicit declaration of function `AGP_CAPID_GET_CAP_ID' /home/adamk/saved/source/drm/bsd-core/drm/../drm_agpsupport.c:77: warning: nested extern declaration of `AGP_CAPID_GET_CAP_ID' *** Error code 1 Different functions, but essentially the same errors. Yet I know that somehow I did manage to get 1.20.0 installed on this machine because I had it working before :-( Any ideas what I'm doing wrong? Thanks! Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debian the dri-devel snapshots
The DRI snapshots can be used with the Xorg packages in Debian experimental. I've edited the wiki to reflect this. Hope that's OK! I've got the r200 snapshot working happily[1]. cheers, Phil [1] PageFlip seems broken however -- rendering errors with Quake4[2] at least, which go away when PageFlip is turned off. [2] No, Quake4 is not playable with an r200 :) Depends on what you mean by playable. The framerate sucks, there are definite graphical glitches, but the game launches and loads the first level, at least :-) Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + NWN
Roland Scheidegger wrote: Stephane Marchesin wrote: Philipp Klaus Krause wrote: Adam K Kirchhoff schrieb: I'm sure this confirms what are already known issues with the r300 driver, but felt it'd be worth posting anyway. There's definitely something bizarre going on with textures. They're much crisper with the fglrx driver. To me it looks like the fglrx driver does linear filtering, while r300 does nearest filtering. It could be the mipmap selection offset that fglrx applies to textures. There's a setting for this reg on r200 (see the R200_EMIT_PP_TRI_PERF_CNTL reg), it probably applies to r300 too. That setting doesn't affect mipmap selection - just how the transition area from one to another mipmap looks like. You'd only get banding as the worst thing possible. Looks like nearest filtering to me too, and/or no mipmaps (so yes mipmap selection offset (LOD setting?) could be an issue there but if so it would be ways off). No idea what's wrong with the inventory there - some issue with transparent textures? Strange that not the whole inventory gets affected exactly the same way though. Roland Hello all. I've narrowed down this problem to something that changed in Mesa between the 5th of December and the 11th, when I first noticed this problem. I have a system at work with a 9800. I started up NWN (after first initializing the card with the fglrx driver, of course), and the textures looked just fine (though the fog problem still existed). The drivers were built from CVS on the 5th. I upgraded it to what's currently in CVS, started up NWN, and had the same texture problem. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + NWN
Roland Scheidegger wrote: Adam K Kirchhoff wrote: I've narrowed down this problem to something that changed in Mesa between the 5th of December and the 11th, when I first noticed this problem. I have a system at work with a 9800. I started up NWN (after first initializing the card with the fglrx driver, of course), and the textures looked just fine (though the fog problem still existed). The drivers were built from CVS on the 5th. I upgraded it to what's currently in CVS, started up NWN, and had the same texture problem. On a quick glance (though I'm not familiar with that driver), it looks to me like introducing texture rectangle caused mipmaps to be disabled for compressed textures. Roland I'll give it a shot over lunch, hopefully. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + NWN
Roland Scheidegger wrote: Adam K Kirchhoff wrote: I've narrowed down this problem to something that changed in Mesa between the 5th of December and the 11th, when I first noticed this problem. I have a system at work with a 9800. I started up NWN (after first initializing the card with the fglrx driver, of course), and the textures looked just fine (though the fog problem still existed). The drivers were built from CVS on the 5th. I upgraded it to what's currently in CVS, started up NWN, and had the same texture problem. On a quick glance (though I'm not familiar with that driver), it looks to me like introducing texture rectangle caused mipmaps to be disabled for compressed textures. Roland Your patch seems to have solved the texture problem with NWN. Thanks! Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 + NWN
FYI, Just wanted to post a few screenshots of Neverwinter Nights with the r300 driver vs Neverwinter Nights with the fgl driver. This is with a Radeon X700, drm 1.20.0, and a Mesa from CVS this weekend. http://68.44.156.246/NWN-fgl.png This is a scene with the fglrx driver from ATI. http://68.44.156.246/NWN0002-r300.png http://68.44.156.246/NWN0005-r300.png Same scene (different angle) with the r300 driver. I'm sure this confirms what are already known issues with the r300 driver, but felt it'd be worth posting anyway. There's definitely something bizarre going on with textures. They're much crisper with the fglrx driver. Instead of seeing the red fog, like in the first shot, with the r300 driver you just get a red wall in the distance. I'm not quite sure what's going on with the inventory display in that last shot, but that's essentially how entire levels look in UT2004. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 seems to be broken.
Since yesterday afternoon, starting many (though not all) GL apps results in: No ctx-FragmentProgram._Current!! drmRadeonCmdBuffer: -22 (exiting) dmesg shows: [drm] Loading R300 Microcode [drm:r300_emit_carefully_checked_packet0] *ERROR* Register 4500 failed check as flag=00 [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
X700 support.
FYI, I'm attaching two very small patches that get the r300 driver working with my AGP X700 card. Adam Index: shared-core/drm_pciids.txt === RCS file: /cvs/dri/drm/shared-core/drm_pciids.txt,v retrieving revision 1.29 diff -r1.29 drm_pciids.txt 23a24 0x1002 0x5E4B CHIP_R420 ATI Radeon RV410 X700PRO Index: src/mesa/drivers/dri/radeon/radeon_chipset.h === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_chipset.h,v retrieving revision 1.1 diff -r1.1 radeon_chipset.h 38a39 #define PCI_CHIP_RV410_5E4B 0x5E4B 121a123 CHIP_FAMILY_RV410, Index: src/mesa/drivers/dri/radeon/radeon_screen.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_screen.c,v retrieving revision 1.47 diff -r1.47 radeon_screen.c 576a577 case PCI_CHIP_RV410_5E4B:
Re: Cedega r200 CVS.
Felix Kühling wrote: Am Samstag, den 12.11.2005, 11:01 -0500 schrieb Adam K Kirchhoff: So I heard from someone on the transgaming forums that Morrowind is running just as fast with the DRI drivers as it with the drivers from ATI on their system. Which surprised me, since it was painfully slow on my machine. I gave it another shot, but this time setting LIBGL_DEBUG to verbose. When I tried to launch Morrowind, I noticed an undefined symbol: _glapi_Dispatch error when libGL tried to load r200_dri.so. However, all native apps run just fine, and I get the following from glxinfo: GL_MAX_VIEWPORT_DIMS=4096/4096 GL_RENDERER = Mesa DRI R200 20050831 AGP 4x TCL GL_VERSION= 1.3 Mesa 6.5 GL_VENDOR = Tungsten Graphics, Inc. Any ideas? There is a known problem with applications that load libGL dynamically with RTLD_LOCAL. Not sure if this is the problem in this case, but the symptom (driver not finding a symbol that should be exported by libGL) and the fact that it's application-dependent point in that direction. I vaguely remember hearing about a Cedega patch for this issue. That was the problem. I was able to add a line to the winex3 script to preload libGL.so.1 and it started working fine (minus a few rendering errors). Thanks for your help. Adam --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Cedega r200 CVS.
So I heard from someone on the transgaming forums that Morrowind is running just as fast with the DRI drivers as it with the drivers from ATI on their system. Which surprised me, since it was painfully slow on my machine. I gave it another shot, but this time setting LIBGL_DEBUG to verbose. When I tried to launch Morrowind, I noticed an undefined symbol: _glapi_Dispatch error when libGL tried to load r200_dri.so. However, all native apps run just fine, and I get the following from glxinfo: GL_MAX_VIEWPORT_DIMS=4096/4096 GL_RENDERER = Mesa DRI R200 20050831 AGP 4x TCL GL_VERSION= 1.3 Mesa 6.5 GL_VENDOR = Tungsten Graphics, Inc. Any ideas? Adam --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 powerpc: success (quite some...)
Mattias Nissler wrote: snip Any ideas what could be causing those problems? Is quake3 rendering correctly on x86 at the moment? /snip Yes, I just played it for a while on Sunday, with the latest and greatest in CVS at the time. Adam --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Doom3 + r300
FYI, doom3 seems to run with the latest r300 drivers. It's slow, and there are definite texture problems (lots of flickering), but it doesn't crash. You can see a screenshot at http://68.44.156.246/doom3.png It looks washed out because I had to increase the brightness in gimp to make anything viewable. Interestingly enough, the image looks fine, and doesn't show any of the stuttering. Adam --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: problem while installing Mesa
Vitaliy A. Matuschenko wrote: Adam Jackson wrote: On Wednesday 21 September 2005 06:51, Vitaliy A. Matuschenko wrote: So i've decided to install libdrm manually. I've downloaded libdrm-1.0.3 but it also didn't want to install at any way. If you'd tell me how it failed to install I'd get it fixed. - ajax while installing libdrm i've got mesages as file X11/Xlibint.h not found.. so i made symlink of /usr/X11R6/include/X11 to libdrm dir and successfully installed it... Yeah, libdrm assumes that the X11R6 headers are installed in /usr/inclue/X11. That's clearly not the case in FreeBSD. But even then Mesa didn't want to install. It asked me of locatoin of libdrm.pc. So i added PKG_CONFIG_PATH /lib/pkgconfig to my env. I thought that it is the end, so i made make clean, make install and got once again a pack of errors, but without package libdrm not found (: libdrm installed to /usr/local/lib, so you should actually add /usr/local/lib/pkgconfig to PKG_CONFIG_PATH. After you do that, Mesa should build fine. Adam K. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: xc does not compile: not any rule to build target `grammar_mesa.o'
[EMAIL PROTECTED] wrote: Sergio [EMAIL PROTECTED] dijo: [EMAIL PROTECTED] a écrit : I try to build following http://dri.freedesktop.org/wiki/Building. I succeeded before, but now xc compilation stops with this: make[5]: *** There is not any rule to build target `grammar_mesa.o' necessary to `DONE'. Halt. make[5]: Leaving directory `/descargas/xorg/xc/lib/GL/mesa/drivers/osmesa' make[4]: *** [all] Error 2 make[4]: Leaving directory `/descargas/xorg/xc/lib/GL' make[3]: *** [all] Error 2 make[3]: Leaving directory `/descargas/xorg/xc/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/descargas/xorg/xc' make[1]: *** [World] Error 2 make[1]: Leaving directory `/descargas/xorg/xc' make: *** [World] Error 2 Under rule, it mean that it doesn't find in the directory one ore more files necessary to build the .o (target). It can be : - one or more headers (e.g. grammar_mesa.h, grammar.h or similar), but normally it complains only reading the source file ; - the source file (files) itself : grammar_mesa.c or grammar_mesa.cpp. Sergio Thank you for your answer. I have deleted all my files from xc/lib/GL/mesa/shader/grammar/ xc/extras/Mesa/src/mesa/shader/grammar/ and xc/programs/Xserver/GL/mesa/shader/grammar/, then updated my CVS files and the problem is the same. Their ./CVS/Entries folder contents match the entries of the folder. I have no knowledge to de able to see what fails. If other people has got to compile it, the problem should be in my computer. It's not your computer, as it fails for me, too. I've opened a bug for it in the freedesktop tracker: https://bugs.freedesktop.org/show_bug.cgi?id=4349 Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + FreeBSD -CURRENT?
Vladimir Dergachev wrote: And so on, through /dev/dri/card254 Mind you, /dev/dri/card0 exists: [ [EMAIL PROTECTED] - ~ ]: ls -la /dev/dri total 1 dr-xr-xr-x 2 root wheel 512 Aug 21 18:37 . dr-xr-xr-x 5 root wheel 512 Dec 31 1969 .. crw-rw-rw- 1 root wheel0, 162 Aug 21 18:35 card0 Any ideas? Is the major ok ? On my (linux) system I get: crw-rw-rw- 1 root root 226, 0 Aug 21 19:07 card0 I would expect a difference, but, it might have changed.. Also, check that the DRM driver knows your PCI id. best Vladimir Dergachev It's listed: shared/drm_pciids.txt:0x1002 0x4153 CHIP_RV350 ATI Radeon AS 9600 AS Would the kernel driver even attach to the device (as it appears to be doing) if it didn't know my PCI ID? Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + FreeBSD -CURRENT?
Jung-uk Kim wrote: On Monday 22 August 2005 02:49 pm, Adam K Kirchhoff wrote: Vladimir Dergachev wrote: And so on, through /dev/dri/card254 Mind you, /dev/dri/card0 exists: [ [EMAIL PROTECTED] - ~ ]: ls -la /dev/dri total 1 dr-xr-xr-x 2 root wheel 512 Aug 21 18:37 . dr-xr-xr-x 5 root wheel 512 Dec 31 1969 .. crw-rw-rw- 1 root wheel0, 162 Aug 21 18:35 card0 Any ideas? Is the major ok ? On my (linux) system I get: crw-rw-rw- 1 root root 226, 0 Aug 21 19:07 card0 I would expect a difference, but, it might have changed.. Also, check that the DRM driver knows your PCI id. best Vladimir Dergachev It's listed: shared/drm_pciids.txt:0x1002 0x4153 CHIP_RV350 ATI Radeon AS 9600 AS Would the kernel driver even attach to the device (as it appears to be doing) if it didn't know my PCI ID? Correct. AFAIK, if you built r300_dri.so from Mesa CVS, you need libGL.so and its friends from the Mesa CVS also. It's all from Mesa CVS. If you did it already, please set: sysctl hw.dri.0.debug=1 Start Xorg and do: grep drm /var/log/messages drm_debug.txt Please send us drm_debug.txt. Attached. Thanks! Adam Aug 22 15:23:06 sorrow kernel: drm0: ATI Radeon AS 9600 AS port 0xa000-0xa0ff mem 0xc000-0xcfff,0xe900-0xe900 irq 10 at device 0.0 on pci1 Aug 22 15:23:06 sorrow kernel: info: [drm] AGP at 0xe000 128MB Aug 22 15:23:06 sorrow kernel: info: [drm] Initialized radeon 1.17.0 20050720 Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_open] open_count = 0 Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_open_helper] pid = 897, minor = 0 Aug 22 15:50:24 sorrow kernel: [drm:pid897:radeon_driver_open] Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_addmap] offset = 0xe900, size = 0x0001, type = 1 Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_addmap] Added map 1 0xe900/0x1 Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_addmap] offset = 0xc000, size = 0x1000, type = 0 Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_addmap] Added map 0 0xc000/0x1000 Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_firstopen] Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_ioctl] pid=897, cmd=0xc0246400, nr=0x00, dev 0xc2358300, auth=1 Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_ioctl] pid=897, cmd=0xc0246400, nr=0x00, dev 0xc2358300, auth=1 Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_close] open_count = 1 Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_close] pid = 897, device = 0xc2358300, open_count = 1 Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_lastclose] Aug 22 15:50:24 sorrow kernel: [drm:pid897:radeon_do_cleanup_cp] Aug 22 15:50:24 sorrow kernel: [drm:pid897:drm_rmmap] mtrr_del = 0 Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_open] open_count = 0 Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_open_helper] pid = 897, minor = 0 Aug 22 15:50:25 sorrow kernel: [drm:pid897:radeon_driver_open] Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_addmap] offset = 0xe900, size = 0x0001, type = 1 Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_addmap] Added map 1 0xe900/0x1 Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_addmap] offset = 0xc000, size = 0x1000, type = 0 Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_addmap] Added map 0 0xc000/0x1000 Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_firstopen] Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_ioctl] pid=897, cmd=0xc0246400, nr=0x00, dev 0xc2358300, auth=1 Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_ioctl] pid=897, cmd=0xc0246400, nr=0x00, dev 0xc2358300, auth=1 Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_close] open_count = 1 Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_close] pid = 897, device = 0xc2358300, open_count = 1 Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_lastclose] Aug 22 15:50:25 sorrow kernel: [drm:pid897:radeon_do_cleanup_cp] Aug 22 15:50:25 sorrow kernel: [drm:pid897:drm_rmmap] mtrr_del = 0 Aug 22 15:50:26 sorrow kernel: [drm:pid897:drm_open] open_count = 0 Aug 22 15:50:26 sorrow kernel: [drm:pid897:drm_open_helper] pid = 897, minor = 0 Aug 22 15:50:26 sorrow kernel: [drm:pid897:radeon_driver_open] Aug 22 15:50:26 sorrow kernel: [drm:pid897:drm_addmap] offset = 0xe900, size = 0x0001, type = 1 Aug 22 15:50:26 sorrow kernel: [drm:pid897:drm_addmap] Added map 1 0xe900/0x1 Aug 22 15:50:26 sorrow kernel: [drm:pid897:drm_addmap] offset = 0xc000, size = 0x1000, type = 0 Aug 22 15:50:26 sorrow kernel: [drm:pid897:drm_addmap] Added map 0 0xc000/0x1000 Aug 22 15:50:26 sorrow kernel: [drm:pid897:drm_firstopen] Aug 22 15:50:26 sorrow kernel: [drm:pid897:drm_ioctl] pid=897, cmd=0xc0106407, nr=0x07, dev 0xc2358300, auth=1 Aug 22 15:50:26 sorrow kernel: [drm:pid897:drm_ioctl] pid=897, cmd=0xc0086401, nr=0x01, dev 0xc2358300, auth=1 Aug 22 15:50:26 sorrow kernel: [drm:pid897:drm_ioctl] pid=897, cmd=0xc0086401
Re: r300 + FreeBSD -CURRENT?
Jung-uk Kim wrote: It seems you built DRM from DRI CVS, right? Yep. Is that not the correct way to do it these days? Can you try the following patch and do the test again? http://people.freebsd.org/~jkim/fbsd_vs_drm-20050818.diff That patched solved my problems. I now have DRI working on FreeBSD with my r300. Thanks! Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 + FreeBSD -CURRENT?
I'm curious if anyone has gotten r300 working on FreeBSD now that the driver has been merged with Mesa and the DRM cvs tree? I managed to get Mesa CVS to build on FreeBSD with some help from Adam Jackson and Daniel Stone on irc today. DRM from the cvs tree compiled as well. The kernel module loads when I start X: drm0: ATI Radeon AS 9600 AS port 0xa000-0xa0ff mem 0xc000-0xcfff,0xe900-0xe900 irq 10 at device 0.0 on pci1 info: [drm] AGP at 0xe000 128MB info: [drm] Initialized radeon 1.17.0 20050720 Xorg gives me the standard warning about DRM on r300: (WW) RADEON(0): Enabling DRM support *** Direct rendering support is highly experimental for Radeon 9500 *** and newer cards. The 3d mesa driver is not provided in this tree. *** A very experimental (and incomplete) version is available from Mesa CVS. *** Additional information can be found on http://r300.sourceforge.net *** This message has been last modified on 2005-08-07. But Direct Rendering is disabled. I get: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenByBusid: drmOpenMinor returns 6 drmOpenByBusid: drmGetBusid reports drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1013 And so on, through /dev/dri/card254 Mind you, /dev/dri/card0 exists: [ [EMAIL PROTECTED] - ~ ]: ls -la /dev/dri total 1 dr-xr-xr-x 2 root wheel 512 Aug 21 18:37 . dr-xr-xr-x 5 root wheel 512 Dec 31 1969 .. crw-rw-rw- 1 root wheel0, 162 Aug 21 18:35 card0 Any ideas? Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP + DRI + xfce4 = Hang.
Roland Scheidegger wrote: Adam K Kirchhoff wrote: Thanks for the tip. I updated to not only the latest Mesa cvs and drm cvs, but the latest xorg cvs. This is a vast improvement, and XFCE4 works with DRI enabled. But... glxgears segfaults: (gdb) run Starting program: /usr/X11R6/bin/glxgears [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 5369)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 5369)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0xb7a300e4 in execute_list (ctx=0x805e7b8, list=145) at main/dlist.c:6420 #2 0xb7a30940 in _mesa_CallList (list=1) at main/dlist.c:6749 #3 0xb7a81a3d in neutral_CallList (i=1) at vtxfmt_tmp.h:304 #4 0xb7e8d615 in glCallList (list=1) at glapitemp.h:85 Try this patch here: http://marc.theaimsgroup.com/?l=mesa3d-devm=112337787415898w=2 That should fix the issue. I believe it not only fixes it, but it's the right thing to do, mesa maps the gl vertex attrib functions (such as glNormal) to glVertexAttribNV functions somewhere in the display list code - and the dispatch offsets for these won't exist otherwise (unless you have a driver which claims to support NV_vertex_program). Someone might want to check this in (with a better comment...), I can't until next week. Roland Roland, Thanks! That fixed the crahes for me. Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP + DRI + xfce4 = Hang.
Jerome Glisse wrote: On 8/8/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Jerome, Thanks for the tip. I updated to not only the latest Mesa cvs and drm cvs, but the latest xorg cvs. This is a vast improvement, and XFCE4 works with DRI enabled. But... glxgears segfaults: (gdb) run Starting program: /usr/X11R6/bin/glxgears [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 5369)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 5369)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0xb7a300e4 in execute_list (ctx=0x805e7b8, list=145) at main/dlist.c:6420 #2 0xb7a30940 in _mesa_CallList (list=1) at main/dlist.c:6749 #3 0xb7a81a3d in neutral_CallList (i=1) at vtxfmt_tmp.h:304 #4 0xb7e8d615 in glCallList (list=1) at glapitemp.h:85 #5 0x08049fa4 in ?? () #6 0x0001 in ?? () #7 0x in ?? () #8 0x in ?? () #9 0x3f80 in ?? () #10 0x in ?? () #11 0x0804c050 in ?? () #12 0xbfd011f8 in ?? () #13 0xb7db1509 in XPending () from /usr/X11R6/lib/libX11.so.6 #14 0x0804a6dd in ?? () #15 0x0804c050 in ?? () #16 0xbfd01250 in ?? () #17 0xbfd01258 in ?? () #18 0xb7b1159b in _mesa_set_enable (ctx=0x804c050, cap=3221225472, state=0 '\0') at main/enable.c:1017 #19 0x0804a8d9 in ?? () #20 0x0804c050 in ?? () #21 0x0142 in ?? () ---Type return to continue, or q return to quit--- #22 0x in ?? () #23 0x in ?? () #24 0x in ?? () #25 0x012c in ?? () #26 0x012c in ?? () #27 0xbfd01320 in ?? () #28 0xbfd01324 in ?? () #29 0xbfd01314 in ?? () #30 0xb7d3ec6a in pthread_mutex_unlock () from /lib/libpthread.so.0 #31 0xb7c0d469 in __libc_start_main () from /lib/libc.so.6 #32 0x08049141 in ?? () All the xscreensaver apps work, as does blender. So far, it's just glxgears that crashes. Any ideas? Hhhmm i have got this things with Ian change but it disapear with lastest Mesa (he fixed such issue). Maybe you still have an old copy of libGL laying around in some dark place :) Double check that you don't have an old libGL (the one with current xorg cvs may not cause that, thus install the one from mesa cvs). Anyway glxgears isn't the killer app you want to start everyday and look at the beautifull gear :) Jerome Glisse Yeah, but I've now tried ppracer and bzflag. I get segfaults with both of those as well. I've updated by locate database, and pulled up all copies of libGL.so.1. I've also run ldd on those particular apps. It's definitly linking to the correct copy of libGL.so.1 (which is from Mesa CVS). Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP + DRI + xfce4 = Hang.
Jerome Glisse wrote: On 8/8/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Adam K Kirchhoff wrote: I have an interesting problem with an HP Pavilion. It's an IGP320M with a Radeon Mobility. DRI works just fine when using WindowMaker or gnome. However, when I try to use xfce4 instead, X locks up when the splash screen would normally be displayed. I can move the mouse around, but I can't always control-alt-delete out of it (though sometimes I can... I think the difference may have to do with whether it was the first time X started up since I rebooted). I can ssh into the machine and reboot it. If I disable the DRI, xfce4 has no problems. This is with recent Mesa cvs and drm 1.16.0 (2.6.12.3, specifically, though I've noticed this with each of the 2.6.12 releases Can't speak about anything earlier). Any ideas? Thanks, Adam No one knows what's going on here? Has anyone ever seen this before? I don't know much about this, but did you try with lastest xorg cvs, radeon driver and dri changed a bit lattly, maybe it's fixed now... Jerome Glisse Jerome, Thanks for the tip. I updated to not only the latest Mesa cvs and drm cvs, but the latest xorg cvs. This is a vast improvement, and XFCE4 works with DRI enabled. But... glxgears segfaults: (gdb) run Starting program: /usr/X11R6/bin/glxgears [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 5369)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 5369)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0xb7a300e4 in execute_list (ctx=0x805e7b8, list=145) at main/dlist.c:6420 #2 0xb7a30940 in _mesa_CallList (list=1) at main/dlist.c:6749 #3 0xb7a81a3d in neutral_CallList (i=1) at vtxfmt_tmp.h:304 #4 0xb7e8d615 in glCallList (list=1) at glapitemp.h:85 #5 0x08049fa4 in ?? () #6 0x0001 in ?? () #7 0x in ?? () #8 0x in ?? () #9 0x3f80 in ?? () #10 0x in ?? () #11 0x0804c050 in ?? () #12 0xbfd011f8 in ?? () #13 0xb7db1509 in XPending () from /usr/X11R6/lib/libX11.so.6 #14 0x0804a6dd in ?? () #15 0x0804c050 in ?? () #16 0xbfd01250 in ?? () #17 0xbfd01258 in ?? () #18 0xb7b1159b in _mesa_set_enable (ctx=0x804c050, cap=3221225472, state=0 '\0') at main/enable.c:1017 #19 0x0804a8d9 in ?? () #20 0x0804c050 in ?? () #21 0x0142 in ?? () ---Type return to continue, or q return to quit--- #22 0x in ?? () #23 0x in ?? () #24 0x in ?? () #25 0x012c in ?? () #26 0x012c in ?? () #27 0xbfd01320 in ?? () #28 0xbfd01324 in ?? () #29 0xbfd01314 in ?? () #30 0xb7d3ec6a in pthread_mutex_unlock () from /lib/libpthread.so.0 #31 0xb7c0d469 in __libc_start_main () from /lib/libc.so.6 #32 0x08049141 in ?? () All the xscreensaver apps work, as does blender. So far, it's just glxgears that crashes. Any ideas? Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP + DRI + xfce4 = Hang.
Adam K Kirchhoff wrote: I have an interesting problem with an HP Pavilion. It's an IGP320M with a Radeon Mobility. DRI works just fine when using WindowMaker or gnome. However, when I try to use xfce4 instead, X locks up when the splash screen would normally be displayed. I can move the mouse around, but I can't always control-alt-delete out of it (though sometimes I can... I think the difference may have to do with whether it was the first time X started up since I rebooted). I can ssh into the machine and reboot it. If I disable the DRI, xfce4 has no problems. This is with recent Mesa cvs and drm 1.16.0 (2.6.12.3, specifically, though I've noticed this with each of the 2.6.12 releases Can't speak about anything earlier). Any ideas? Thanks, Adam No one knows what's going on here? Has anyone ever seen this before? Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
IGP + DRI + xfce4 = Hang.
I have an interesting problem with an HP Pavilion. It's an IGP320M with a Radeon Mobility. DRI works just fine when using WindowMaker or gnome. However, when I try to use xfce4 instead, X locks up when the splash screen would normally be displayed. I can move the mouse around, but I can't always control-alt-delete out of it (though sometimes I can... I think the difference may have to do with whether it was the first time X started up since I rebooted). I can ssh into the machine and reboot it. If I disable the DRI, xfce4 has no problems. This is with recent Mesa cvs and drm 1.16.0 (2.6.12.3, specifically, though I've noticed this with each of the 2.6.12 releases Can't speak about anything earlier). Any ideas? Thanks, Adam --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 testing..
FYI I've had a chance today to test the r300 driver (using a Radeon 9550) with every 3d game and application I have installed. This includes UnrealTournament, ut2004, q3a, RTCW, Rune, Tribes2, Orbz, MarbleBlast (both from GarageGames), neverball, neverputt, NWN, doom3, blender, ppracer, and gltron. There were no lockups and very few rendering errors that I could see. Doom3 refused to launch, just stopping with: - R_InitOpenGL - Setup X display connection dlopen(libGL.so.1) Initializing OpenGL display Using XFree86-VidModeExtension Version 2.2 DGA DirectVideo Mouse (Version 2.0) initialized Free86-VidModeExtension Activated at 800x600 Performance wise, the driver seems to be on par with the r200 driver. Orbz and NWN are noticably slower. UT2004 is painfully slow, but I'm chalking that up to the S3TC fallback in the games renderer. Blender, which used to crash when opening up a couple files, seems to work flawlessly. This is on an SMP xeon system, with 1 gig of RAM, running 2.6.12.1 and Debian -unstable. Adam --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 bsd drm?
Jung-uk Kim wrote: On Wednesday 22 June 2005 06:55 pm, Adam K Kirchhoff wrote: At one point in the not-too-distant past, the r300 drm would compile on FreeBSD 5.4. After bringing a Radeon 9550 home from work to test out and being really impressed with how well the driver works (without those pesky 9800 specific lockups), I decided to give it a whirl in FreeBSD. Unfortunately, the drm module wouldn't compile: c -O -pipe -I. -I.. -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I.. -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_set_pciegart': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:1246: warning: unsigned int format, dma_addr_t arg (arg 5) /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_do_init_cp': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:1533: error: too many arguments to function `drm_ati_pcigart_init' /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_preinit': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:2087: warning: implicit declaration of function `drm_device_is_pcie' /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:2087: warning: nested extern declaration of `drm_device_is_pcie' *** Error code 1 Any ideas? Recent preliminary PCI-Express support code commit broke *BSD. I have a quick-and-dirty fix for this. If you are interested, let me know. Jung-uk Kim Definitely pass it along when you a chance :-) Thanks! Adam --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 bsd drm?
At one point in the not-too-distant past, the r300 drm would compile on FreeBSD 5.4. After bringing a Radeon 9550 home from work to test out and being really impressed with how well the driver works (without those pesky 9800 specific lockups), I decided to give it a whirl in FreeBSD. Unfortunately, the drm module wouldn't compile: c -O -pipe -I. -I.. -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I.. -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_set_pciegart': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:1246: warning: unsigned int format, dma_addr_t arg (arg 5) /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_do_init_cp': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:1533: error: too many arguments to function `drm_ati_pcigart_init' /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_preinit': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:2087: warning: implicit declaration of function `drm_device_is_pcie' /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:2087: warning: nested extern declaration of `drm_device_is_pcie' *** Error code 1 Any ideas? --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Vladimir Dergachev wrote: On Wed, 1 Jun 2005, Adam K Kirchhoff wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. Are you doing a cold restart ? I would help a lot if you could try this with glxgears and/or quake3: I just gave it a shot with UnrealTournament. I'll try with Q3A in a little bit * cold restart * start one of 3d programs measure time before lockup 2 minutes... That's with just twm, an xterm, and UT running. I'm not even using half of my systems memory at the time of the lockup (about 400 megs of the 1 gig). Nothing being swapped. * cold restart * put some memory pressure to mix things up - I would suggest loading a few files in OpenOffice, opening gimp with large pictures, etc, until most of memory is used up. use quiet programs (like word processors or spreadsheets) that can be swapped out. * start one of 3d programs, measure time before lockups. Less than 30 seconds. This time I have KDE, openoffice, abiword, gimp, gv, epiphany, mozilla, firefox, thunderbird, and a few other apps running in the background. Amazingly, I still wasn't swapping. When the lockup occurred, I was using 1021364k of 1034532k according to top. Now to see if I can repeat the results with Q3A. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Vladimir Dergachev wrote: Adam, Great, thank you very much ! No, the system did not need to be actively swapping in fact this would probably have confused the results. (this is why I asked for passive apps) Could you also let me know the following information: Output of free At the moment: [ [EMAIL PROTECTED] - ~ ]: free total used free sharedbuffers cached Mem: 1034532 483876 550656 0 113452 154604 -/+ buffers/cache: 215820 818712 Swap: 2038136 02038136 If you want the output after/during a lockup, I'll get it this afternoon. Output of cat /proc/pci Doesn't exist any more :-) However: :00:00.0 Host bridge: Intel Corp. 82875P Memory Controller Hub (rev 02) :00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 02) :00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02) :00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2 (rev 02) :00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02) :00:1d.3 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4 (rev 02) :00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) :00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) :00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller (rev 02) :00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro] :01:00.1 Display controller: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro] (Secondary) :02:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) :02:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a) :02:09.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a) :02:0a.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 26) :02:0b.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 08) :02:0c.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) :02:0c.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) :02:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Output of cat /proc/interrupts [ [EMAIL PROTECTED] - ~ ]: cat /proc/interrupts CPU0 CPU1 0:8326778 0IO-APIC-edge timer 1:519 0IO-APIC-edge i8042 2: 0 0 XT-PIC cascade 4: 7 0IO-APIC-edge serial 8: 1 0IO-APIC-edge rtc 12: 4214 0IO-APIC-edge i8042 14: 46373 0IO-APIC-edge ide0 15: 74596 0IO-APIC-edge ide1 16: 211299 0 IO-APIC-level uhci_hcd, uhci_hcd, [EMAIL PROTECTED]::01:00.0 18: 0 0 IO-APIC-level uhci_hcd 19: 0 0 IO-APIC-level uhci_hcd 20: 8 0 IO-APIC-level ohci1394, bttv0 21: 4545 0 IO-APIC-level EMU10K1, eth0 22: 64 0 IO-APIC-level sym53c8xx 23: 54207 0 IO-APIC-level ehci_hcd, Ensoniq AudioPCI NMI: 0 0 LOC:83266788326673 ERR: 0 MIS: 0 Output of cat /proc/iomem [ [EMAIL PROTECTED] - /home/adamk ]: cat /proc/iomem -0009ebff : System RAM 0009ec00-0009 : reserved 000a-000b : Video RAM area 000c-000ccfff : Video ROM 000d-000d3fff : Adapter ROM 000f-000f : System ROM 0010-3fed : System RAM 0010-00322922 : Kernel code 00322923-00402a7f : Kernel data 3fee-3fee2fff : ACPI Non-volatile Storage 3fee3000-3fee : ACPI Tables 3fef-3fef : reserved 3ff0-3ff003ff : :00:1f.1 d800-dfff : :00:00.0 e000-efff : PCI Bus #01 e000-e7ff : :01:00.0 e000-e7ff : radeon e800-efff : :01:00.1 f000-f1ff : PCI Bus #01 f100-f100 : :01:00.0 f100-f100 : radeon f101-f101 : :01:00.1 f300-f3003fff : :02:03.0 f3004000-f30040ff : :02:0a.0 f3004000-f30040ff : sym53c8xx f3005000-f3005fff : :02:0a.0 f3005000-f3005fff : sym53c8xx f3006000-f30067ff : :02:03.0 f3006000-f30067ff : ohci1394 f3007000-f30070ff : :02:0d.0 f3007000-f30070ff : 8139too f400-f4000fff : :02:0c.0 f400-f4000fff : bttv0 f4001000-f4001fff : :02:0c.1 f410-f41003ff : :00:1d.7 f410-f41003ff : ehci_hcd fec0- : reserved Anything special about your computer (is it SMP ?) Dual Xeon (HT is disabled). 1 gig of RAM. Intel i875 chipset. Adam
Re: [r300] [patches] debugging lockups
Aapo Tahkola wrote: I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) Well, there's no point in stopping now. I'll give it a shot when I get home. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Aapo Tahkola wrote: Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) You guys seem to be getting closer... When I had X + xfce4 + quake3 running (with this patch + patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X locked up within 2 minutes. However, X + quake3 (no window manager), I went thirty minutes before my first problem. Quake3Arena crashed, and X quit. There was some message on the terminal about radeon_wait and IRQ 16. Being a fool, I typed 'dmesg' before writing down the error. Of course nothing showed up in dmesg, and the error from X (or Q3A) was no longer in the buffer. There was no lockup. I started X up again (without rebooting). Went another thirty minutes playing Q3A. Same thing happened, except that the terminal never came back up. I ssh'ed in, and neither Q3A nor X were running. So I rebooted. And here I sit. Another thing I noticed. When playing Q3A with a window manager running, every 10-30 seconds the screen goes black for a second. The game continues, even in darkness, but this doesn't happen when running without a window manager. I have no idea if it's related, but I thought I'd pass it along. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Adam K Kirchhoff wrote: Aapo Tahkola wrote: Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) You guys seem to be getting closer... When I had X + xfce4 + quake3 running (with this patch + patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X locked up within 2 minutes. However, X + quake3 (no window manager), I went thirty minutes before my first problem. Quake3Arena crashed, and X quit. There was some message on the terminal about radeon_wait and IRQ 16. Being a fool, I typed 'dmesg' before writing down the error. Of course nothing showed up in dmesg, and the error from X (or Q3A) was no longer in the buffer. There was no lockup. I started X up again (without rebooting). Went another thirty minutes playing Q3A. Same thing happened, except that the terminal never came back up. I ssh'ed in, and neither Q3A nor X were running. So I rebooted. And here I sit. Another thing I noticed. When playing Q3A with a window manager running, every 10-30 seconds the screen goes black for a second. The game continues, even in darkness, but this doesn't happen when running without a window manager. I have no idea if it's related, but I thought I'd pass it along. Adam One more thing... No matter what patches I apply, or what other X programs and X clients I have running, I've never been able to get more than 3-4 minutes out of UnrealTournament. I was able to play Q3A for an hour without a single X lockup (just Q3A crashing), but UT still locked up within 30 seconds or so. So either UT is more likely to cause this bug, or it's causing an entirely different bug. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Adam K Kirchhoff wrote: Aapo Tahkola wrote: Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) You guys seem to be getting closer... When I had X + xfce4 + quake3 running (with this patch + patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X locked up within 2 minutes. However, X + quake3 (no window manager), I went thirty minutes before my first problem. Quake3Arena crashed, and X quit. There was some message on the terminal about radeon_wait and IRQ 16. Here it is: radeonWaitIrq: drmRadeonIrqWait: -16 Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Adam K Kirchhoff wrote: Vladimir Dergachev wrote: Are you doing a cold restart ? I would help a lot if you could try this with glxgears and/or quake3: I just gave it a shot with UnrealTournament. I'll try with Q3A in a little bit * cold restart * start one of 3d programs measure time before lockup 2 minutes... That's with just twm, an xterm, and UT running. I'm not even using half of my systems memory at the time of the lockup (about 400 megs of the 1 gig). Nothing being swapped. * cold restart * put some memory pressure to mix things up - I would suggest loading a few files in OpenOffice, opening gimp with large pictures, etc, until most of memory is used up. use quiet programs (like word processors or spreadsheets) that can be swapped out. * start one of 3d programs, measure time before lockups. Less than 30 seconds. This time I have KDE, openoffice, abiword, gimp, gv, epiphany, mozilla, firefox, thunderbird, and a few other apps running in the background. Amazingly, I still wasn't swapping. When the lockup occurred, I was using 1021364k of 1034532k according to top. Now to see if I can repeat the results with Q3A. Adam Sorry for sending the previous e-mail from my work address. Not quite sure how that happened. Anyway, I've repeated the test with Quake3... Cold restart, no other X apps (not even twm or xterm): 10 minutes before a lockup. Cold restart, X, vncserver, gimp, abiword, openoffice, mozilla, etc.: 10 seconds. Again, it still wasn't swapping when the lockup happened according to top, but loading up the memory definitely seems to have an impact. Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
Nicolai Haehnle wrote: Hi everybody, I once again tripped upon an R300 lockup (possibly the same one that everybody's been talking about) and spent the last one and half days chasing it down. It turns out that writing the vertex buffer age to scratch registers (the ones that are written back to main memory) during a 3D sequence is a bad idea. Apparently, this confuses the memory controller so much that some part of the engine locks up hard. The attached patch.out-of-loop-dispatch-age fixes this, at least for me. The attached patch.remove-userspace-pacifiers removes additional unnecessary emission of the pacifier sequence from the userspace driver. Userspace isn't supposed to emit this sequence anyway. Could everybody please test whether a) the first patch really does fix the lockups people are seeing and b) whether combining both the first and the second patch causes any regressions. If everything's fine with these patches, I'm going to commit them in a few days or so. cu, Nicolai A) The first patch may help a little, but definitely doesn't eliminate the lockups. B) Huge regression. With both patches I get an immediate lockup when launching glxgears (before the window is even drawn). Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
Vladimir Dergachev wrote: Vladimir Dergachev wrote: In the past I found useful not to turn drm debugging on, but, rather, insert printk statements in various place in radeon code. This should also provide more information about what is actually going on. I can't make any promises. My partner already thinks I spend too much time in front of the computer :-) I'll see what I can do, though. Think a printk statement at the start and end of every function? Have any This is probably overkill and might not be very useful Rather try, at first, to just print a printk logging which command is being executed (r300_cmd.c) - this is not very thorough, but, maybe, there is a pattern. I added a printk for each function in r300_cmdbuf.c... When Q3A locked up, and the last thing showing up in syslog was r300_pacify. So I added printk's after every line in r300_pacify :-) The last thing in syslog was: OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) ) OUT_RING( 0x0 ) ADVANCE_RING() So it seems to be making it all the way through r300_pacify, which had been called from r300_check_range, from r300_emit_unchecked_state. Here's the sequence: r300_emit_raw r300_emit_packet3 r300_emit_raw r300_emit_unchecked_state r300_check_range r300_emit_unchecked_state r300_check_range r300_pacify RING_LOCALS BEGIN_RING(6) OUT_RING( CP_PACKET0( R300_RB3D_DSTCACHE_CTLSTAT, 0 ) ) OUT_RING( 0xa ) OUT_RING( CP_PACKET0( 0x4f18, 0 ) ) OUT_RING( 0x3 ) OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) ) OUT_RING( 0x0 ) ADVANCE_RING() Does this tell us anything? Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
