Kudos & AGP questions

[Execute_Method]

You guys rock!!!!

I recieved an x1650 as a present, and not wanting to look a gift horse in the mouth I didn't say anything... Besides, it was better than my other "problem" card (nvidia mx4000) that I couldn't get proprietary drivers working on anyway.

I now feel that as long as the OS drivers keep gettting better,(w/ the doc. release from AMD/ATI) that I will continue to use ATI cards.

Many Kudos to all the people who are working so hard to make our money worth our while.

I did the ATI/MESA/Xserver install last night!!!

I now have working 3d w/ 2300fps in glxgears!!! As well as capability w/ Compiz (super smooth and no problems), and games (Openarena).

In all there are a couple ??s I have in regaards to this:

1) What is the difference between DRI & DRI2? I noticed somewhere else that dri2 output isn't possible fo some reason.

....
(II) "dri" will be loaded by default.
(II) "dri2" will be loaded by default.

2) Is there a way to get 8X agp? Or will it help?

....
(II) RADEON(0): AGP card detected
....
(==) RADEON(0): Using AGP 4x

3) What do these other lines about agp mean?

....
(II) RADEON(0): [agp] Mode 0x1f000a09 [AGP 0x1106/0x3188; Card 0x1002/0x71c1]
(II) RADEON(0): [agp] 8192 kB allocated with handle 0x00000001
(II) RADEON(0): [agp] ring handle = 0xe0000000
(II) RADEON(0): [agp] Ring mapped at 0xb7852000
(II) RADEON(0): [agp] ring read ptr handle = 0xe0101000
(II) RADEON(0): [agp] Ring read ptr mapped at 0xb7851000
(II) RADEON(0): [agp] vertex/indirect buffers handle = 0xe0102000
(II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0xa75ad000
(II) RADEON(0): [agp] GART texture map handle = 0xe0302000
(II) RADEON(0): [agp] GART Texture map mapped at 0xa70cd000
(II) RADEON(0): [drm] register handle = 0xe9000000
(II) RADEON(0): [dri] Visual configs initialized

4) Last but not least, I had a hard lock when running Openarena (when still using Metacity). I have no experience with linux gaming (I'm not a big gamer anyway), so I'm not sure what settings to play with to try and get it to run right.
Some help would be much obliged.




Thank YOU for bringing me 3d!!!!
Open Source FTW!!!!!

[oblivious_maximus]

You can read about DRI2 here and I won't comment on it further because that document goes way over my head. I'm positive bridgman has explained DRI/DRI2/DRM/TTM/GEM at least once or twice in other threads, those posts are probably a much better bet if you want an explanation that mere mortals have a hope of comprehending.

8x AGP should certainly improve performance if you're currently using 4x. If there's an option for you to change, it will be in your BIOS. Generally the user doesn't need to be involved in that option though, and I wouldn't be surprised if you're running at 4x because that's the best your motherboard(or the card perhaps, but it's not that old so I suspect it's the mobo) supports.

Just a guess, but those [agp] lines look like they're probably all bits of assigned memory. Whatever they are, unless there's a (WW) or (EE) at the start of the line(this is Xorg.0.log we're talking about right?), you don't need to be too concerned about them.

If you're looking for errors in the Xorg log, try running this to reveal the relevant lines:
$egrep "EE|WW" /var/log/Xorg.0.log

[Execute_Method]

Maximus thank you for your reply.

Yes, I was quoting lines from my Xorg log, and there aren't any errors and the system is running very stable.


In response to your comment regarding agp speed, I'm sure it cannot be set in bios. Although the MB is 4x/8x capable, and will autodetect. According to the manual, anyway.

When I was running XP I had an FX5200 video card and it ran at 8X. Is there a line I can pass in my xorg.conf that will try to force it? I do wish however that I could manually select this in the MB bios.


The MoBO is a gigabyte k8nvxp (socket 754, running athlon 64 3000+, with the newest firmware) so I guess it could be considered old, but is definitely quite capable.

The card is Definitely 8x agp.

Anything else I could try to get the max capability from the card.
BTW I am running x86 and NOT x86 64.

[agd5f]

Option "AGPMode" "8"

However, I doubt you'll notice much difference performance-wise. The driver defaults to the current mode as setup by the bios which tend to be the most reliable, but YMMV.

[bridgman]

regarding DRI2, afaik it is not being used today. Kristian's blog entries are probably the most accessible (links below). What he is talking about is Redirected Direct Rendering, which relies on two other things -- DRI2 (an improved way for mesa, drm and x drivers to talk to each other) and TTM (an improved memory manager in the drm driver).

First link (last fall, talking about how nice it will be) :

http://hoegsberg.blogspot.com/2007/0...rendering.html

Second link (a couple of months ago, talking about how nice it is) :

http://hoegsberg.blogspot.com/2008/0...dri2-work.html

There is some hot debate right now about which direction memory managers should follow in the short term - GEM vs TTM. One of the potential complications is that GEM is moving towards having driver- and/or vendor-specific portions of the API, but that conflicted with Kristian's need for some standard memory management calls to support DRI2. As of the last week I *think* this has been resolved by separating the GEM API calls into "enough common calls to support DRI2" and "everything else being driver/vendor-specific to avoid having to come up with an API that worked for all hardware". I still have a nagging worry that driver-specific memory management API will come back and bite us on our collective butts soon, but there's also a lot to be said for taking a chance, letting other work like Gallium move ahead and get closer to being production-ready.

[Execute_Method]

Thank You all for your replies.

Well... Passing the AGPMode option worked out very well. :-)

I am now seeing 2900FPS in glx gears, as compared to 2200FPS, so I'm happy.

I guess I'll have to see over time, but the system is running very well w/ 3D.