Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-11-29

Search This Log:

agd5f: ossman: ums turns them off before IIRC
Zajec: AndyWas: so where are you from finally? :)
[[n1x]]: What drivers should I have installed on my fedora 12 ati mobility radeon laptop because I'm getting some compiz crashes that leave no log and I need to know what I have or need?
soreau: [[n1x]]: Make sure to pastebin /var/log/Xorg.0.log and the output of dmesg
[[n1x]]: ok, I'm gonna go make it crash a couple of times and like that stuff
[[n1x]]: like = link
Nightwulf: hi all
[[n1x]]: soreau: that dmesg gives a lot of info and it doesnt show everything when I scroll all the way back
[[n1x]]: Here is xorg stuff: http://paste2.org/p/538387
[[n1x]]: Here is dmesg stuff: http://paste2.org/p/538392
soreau: See all those drm errors at the bottom? thats not good
soreau: you need to update your kernel, libdrm, mesa and ddx
MostAwesomeDude: Eh.
MostAwesomeDude: [[n1x]]: You're playing a game with S3TC. Either turn off compressed textures, or turn off KMS.
MostAwesomeDude: Unless it's been fixed and I didn't notice...
[[n1x]]: I have no idea what those are and how to turn off or on
soreau: to turn off kms, you can add nomodeset as a kernel parameter
[[n1x]]: oops I know what kms is, lol
[[n1x]]: i want kms on
soreau: I dont know how to turn off compressed textures
soreau: maybe MostAwesomeDude can enlighten you
[[n1x]]: update kernel, libdrm, mesa and ddx?? there are up to date though
soreau: Not so much
[[n1x]]: well, i dont know where to look then, cause when I look through yum there are no newer packages
soreau: There are repos that provide newer packages in fedora but if what MostAwesomeDude says is correct, you probably need to turn off compressed textures for whatever 3D app youre running
MostAwesomeDude: Hmm. I'd really rather just fix the problem with submitted texture sizes.
MostAwesomeDude: But first, sleep.
soreau: me too :p
[[n1x]]: ok, thanks
MostAwesomeDude: Screw it, gonna look at it right now.
MostAwesomeDude: Cloning a kernel tree.
[[n1x]]: lol
MostAwesomeDude: No, this is a combo of bugs.
MostAwesomeDude: First off, kernel's wrong; it's reporting bpp but doing maths with cpp.
MostAwesomeDude: Second, Mesa appears to be passing in absurdly large textures.
MostAwesomeDude: [[n1x]]: What were you doing to trigger this?
soreau: MostAwesomeDude: From #compiz <[[n1x]]> I can make it crash easily all the time
soreau: <[[n1x]]> For example, if I enable visualizations in audacious it will cause compiz to crash and lose window borders
[[n1x]]: yeah, and when I adding stuff to gnome panel
MostAwesomeDude: Hm. So this isn't S3TC bug, then.
MostAwesomeDude: Mesa's not setting things up right.
MostAwesomeDude: I'm gonna need airlied for this, or at least I need to sleep before digging more.
[[n1x]]: If I do an add to panel for gnome and drag one of the applets to panel it will crash compiz
[[n1x]]: If I change the fonts in a terminal window and exit settings it will crash compiz
soreau: [[n1x]]: In the meantime, if you can figure out how to upgrade those components I mentioned, especially mesa and test again that might be helpful. You can try asking in #fedora-qa on how to get these latest package versions from other repos
[[n1x]]: soreau: yeah, thats what I'm doing right now, looking for updates
[[n1x]]: I'm also gonna see if I can make a vid so you can see exactly what I'm talking about if I dont get updated stuff and check that first
Ghworg: I hate the mesa build system. It somehow ignores ccache and builds from scratch every time
ossman: airlied, ping
ossman: agd5f, ping
gimzo: ossman: aren't they sleeping now ?
ossman: gimzo, you never know. they seems to have fairly flexible schedules :)
ossman: and it's only late evening in australia, so airlied might still be up
scarabeus: i would need one patch backported to 6.12 branch
scarabeus: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=78fcbf577ad6eba6399cc39f74b7ce5f9c8e265e
scarabeus: so i can just grab head to 6.12.4 and create new repack for us in gentoo
scarabeus: :]
scarabeus: anyone around who can do it for me? :]
bttb: I can't believe it, I played a level of xmote ~120 times and still I can't make it through :D
bttb: Must be a driver issue :)
ZeZu: I can't find anything on *D1MODE_VIEWPORT* or other regs @ 65xx other than D1OVL_RT_* regs, anyone know where they came from in the radeon xf86 drivers??
ZeZu: that is, they aren't in docs from ati
BioTube: the docs don't include everything
BioTube: those registers were probably reverse engineered
ZeZu: i have noticed they dont include a lot
ZeZu: thanks
Ronis_BR: does radeon is better with XORG 1.7?
spreeuw: it doesnt matter
spreeuw: if you're talking about running git on top of it
spreeuw: if you mean release versions then it will be better I guess
spreeuw: Ronis_BR: see if your distribution has experimental packages for radeon
spreeuw: and install them
Ronis_BR: spreeuw: libdrm, mesa and radeon driver are all from git
Ronis_BR: but xorg is 1.6.5
Ronis_BR: 1.6.
Ronis_BR: 2
Ronis_BR: 1.6.5 :d
BioTube: Ronis_BR: same here, no problems
Ronis_BR: ok so :D
Ronis_BR: thanks BioTube
spreeuw: the Ronis_BR it doesnt matter much then
Ronis_BR: spreeuw: ok! thanks
spreeuw: damn clicking around in celestia rules in HD
spreeuw: the high res texture loading of objects goes a bit bumpy
spreeuw: hmm open scene graph compile takes minutes
spreeuw: gonna give flightgear another spin
Ronis_BR: airlied: hello fellow, have you had any ideas about incompatibility of KMS+tuxonice?
cbmuser: airlied: I had another crash with kms, it's always related to pixmaps, according to the Xorg.log
cbmuser: http://pastebin.org/58423
cbmuser: this is on Fedora 12, with RV-370
cbmuser: ATI Radeon mobility X300
cbmuser: same happened with Intel Q45 on Debian Testing, with Kernel 2.6.30
agd5f: ossman: pong
cbmuser: airlied: http://pastebin.org/58425 <= thats Intel on Debian
ossman: agd5f, do you remember this: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=9c2f909ea437a63a408d2398ecabe0b378dbb982
ossman: agd5f, did that scare you off? :)
agd5f: ossman: that fixed some issues with dualhead on some r6xx chips. kms doesn't seem to exhibit the same behavior, so I don't think it's needed
ossman: agd5f, I copied the basic idea to KMS to solve my issue
ossman: on r300
ossman: agd5f, http://bugs.freedesktop.org/attachment.cgi?id=31547
agd5f: ossman: looks good. you'll probably want to loop over the num_crtcs rather than 0/1 since newer hw supports more than 2
ossman: agd5f, sure, although that piece of code will be insignificant compared to how much else needs to be changed to handle more than two CRTCs :)
ossman: pokes ajax and airlied
ossman: any of you awake so that I can get a koji build? :)
agd5f: also, pre-avivo chips (r1xx-r4xx) had a bug where crtc2 had to be restored before crtc1 if both were in use
agd5f: s/restored/enabled/
ossman: agd5f, yeah, I saw something about that in the UMS code
ossman: didn't look like it was moved over to KMS though
agd5f: ossman: feel free to add Acked-by to that patch
agd5f: from me
ossman: agd5f, maybe you want to see the updated version first ;)
agd5f: ossman: yes of course ;)
ossman: agd5f, which tree will the irq changes pop up first in? drm-next?
agd5f: ossman: yeah probably. I'll post the patch to dri-devel too
agd5f: I think we got legal stuff sorted out on friday, so, should be able to release tomorrow
ossman: yay
ossman: agd5f, hmm... there is no num_crtcs
ossman: so the best I can do is ARRAY_SIZE(crtcs)
agd5f: ossman: you need to walk the crtc list in the drm
ossman: that seems like overengineering things. the information is there without going through the drm layer after all
agd5f: list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
ossman: agd5f, and the caller is required to hold the mode lock when calling prepare/commit?
agd5f: ossman: I think so
agd5f: should already have it when doing a modeset
ossman: compiling...
ossman: agd5f, what was the state of the GLSL things? Apparently it wasn't enabled by default
agd5f: ossman: there are still some missing extensions
agd5f: but the hard part (flow control in the compiler) is pretty much done
ossman: k
ossman: agd5f, this version works fine as well. I'll prepare a patch
agd5f: ossman: cool
ossman: agd5f, http://pastebin.com/m6896683
agd5f: ossman: looks good
ossman: I'll add your ack then and update fdo
agd5f: ossman: great. thanks for tracking that down
ossman: well, it's my itch so ;)
ossman: should I use your gmail address?
agd5f: ossman: yeah
ossman: agd5f, bug updated. if you talk to airlied then please ask him to commit (and do a koji build if possible)
agd5f: ossman: will do
MichaelLong: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB!, [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB! <- getting this after resume from s2ram on a T40p (r250) linux 2.6.32-rc8 KMS enabled, a known issue?
agd5f: MichaelLong: you probably need an updated drm. I'm not sure the last round of s/r fixes didn't make it into linus kernel
MichaelLong: hmm
ossman: agd5f, will Richard continue working on the r600 compiler once it's feature complete, or does his allotted time end there?
agd5f: ossman: he's part of the open source team, so he'll always be working on some open source stuff. I suspect he may start working on evergreen once he finishes gl2 support
agd5f: MichaelLong: make sure you ahve this patch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=23115b0592bde5da249fcbdad7714c1f96a8e5f5
ossman: agd5f, I see. Basically I was wondering if there is someone who will work on optimising the compiler
agd5f: ossman: yes, he's planning to
MichaelLong: agd5f, thx I'll give it a look
ossman: agd5f, is there some way of measuring how much load you're putting on the gpu?
ossman: to know what needs improving
agd5f: ossman: generally targeted benchmarks
agd5f: there are some perf counters you can look at to see where bottlenecks are, but I haven't found any good docs on how to use them
ossman: agd5f, those would be very interesting for my day job. I work for a terminal server vendor, and measuring gpu load to do proper load balancing would be a nice thing to have
agd5f: the ISA guides have optimization advice as well, and the shader analyzer on our developer site is useful
agd5f: ossman: the easiest method is to look at the number of command buffers queued up
agd5f: ossman: you could actually do some scoring when the command buffer is parsed to generate predicted load
agd5f: based on when commands you are sending
agd5f: ossman: anyway, gotta run. bbl
ossman: I guess this is not stuff that's currently done and exported to userspace?
ossman: seeya
agd5f: ossman: nope
agd5f: should be pretty easy though. just add a scoring function to the CS parser and add a GET_SCORE function to the GET_PARAM ioctl
agd5f: it would return a score based on the number and complexity of scheduled command buffers
agd5f: ossman: you could even submit hints from userspace in NOP packets
MostAwesomeDude: It should be pretty easy. Shaders have a length and number of texture lookups. Add that to the poly count, cb size and count, and whether AA's enabled.
ossman: historic use would be the most interesting, so an ever increasing counter would probably be best
ossman: kind of like the cpu counter used for top and alike
MostAwesomeDude: agd5f: Any idea what causes textures to fail track checking with outrageous sizes?
MostAwesomeDude: I was reading through the checker code, and it looks like there's textures that aren't even getting set up correctly.
agd5f: MostAwesomeDude: mesa or CS bug
agd5f: gotta run for real this time. bbl
MichaelLong: hmm the schedule IB failed thing changed from IB(0) to IB(15) :/
airlied: MostAwesomeDude: btw I like keithw's i965g bo winsys i/f for relocs
airlied: we should move r300g to something like that where we define type of bos, and let winsys translate them to kernel ones
airlied: allows us to do a new drm i/f in the future and just make a new winsys
MostAwesomeDude: airlied: Sure. My next move was either to do atoms, or to figure out WTF kernel fails my textures sometimes.
tormod: airlied, I am packaging radeontool for Debian. What about bumping to 1.6? It's getting far off the 1.5 from 6 years ago.
tormod: and should I send/forward patches directly to you?
airlied: tormod: yeah I should really do a release, it just sort of drifts along in my repo
airlied: tormod: yeah I'll take patches
airlied: MostAwesomeDude: textures is probably misflushing or something like that
airlied: MostAwesomeDude: the kernel assumes largest texture size
airlied: MostAwesomeDude: and replaces it with the values from userspace when it gets a new CS
MostAwesomeDude: airlied: Weird. Some guy was in here last night getting compiz problems with classic, so I popped open the check code.
MostAwesomeDude: Looks alright.
MostAwesomeDude: It seems to really only happen on r300g when using compressed textures.
damentz: hey guys, i'm ordering one last upgrade for my agp system
damentz: radeon 4650 with 1gb of video ram
damentz: quick question though, should i pick a card with gddr2 or ddr2?
damentz: i was reading that gddr2 runs at a higher voltage and generates more heat
damentz: but would it be faster?
gimzo: damentz: it's the same, that G does not specify anything important, AFAIK
spreeuw: hey ioqake brightness still doesnt work
spreeuw: but xgamma beforehand works fine
spreeuw: I recommend everybody to buy the fastest radeon without fan they can get ;p
gimzo: spreeuw: does that mean a driver that will make it usable coming soon ?
damentz: spreeuw, i just got the highest model number with agp
damentz: most likely it has better power efficiency
damentz: :P
airlied: MostAwesomeDude: s3tc might be broken
spreeuw: gimzo: oh didnt know there was anything above 4670
spreeuw: which works fine with r600
gimzo: spreeuw: no, I meant most passive cards are slow in 3d, and with unoptimized drivers are even slower :)
MostAwesomeDude: airlied: I'd believe it.
spreeuw: gimzo: well my 4670 is fucking fast
gimzo: spreeuw: my x700 is not, at least not on 1920x1200 :)
spreeuw: no those are not, had one before
spreeuw: but you can go out and buy a 4670 plug it in and just compile r600 instead of r300
spreeuw: its 2-5x faster
spreeuw: compensates well for the unoptimized drivers
spreeuw: openarena is at last playable in 1280x720
spreeuw: and ut2004 too
gimzo: right now I'm waiting for improved r300 drivers or working free hd500 drivers, whichever comes first :)
spreeuw: in anycase dont get a 3450
spreeuw: those are a factor too slow too
spreeuw: had one
spreeuw: but they have nice passive versions too
gimzo: openarena is not playable for me, framerate is ok, but there is input lag, but it looks like it will be fixed in gallium, so I'll wait
spreeuw: is it a monitor issue for you?
spreeuw: I can handle a little lag
gimzo: monitor issue ? only monitor issue is that my monitor doesn't like 75hz so I can't lower the resolution
spreeuw: but I'm not sharp enough to notice input lag in my setup
gimzo: it's half a second lag, pretty noticeable :)
spreeuw: gonna play a few more games this week to get up to old quake speed again
gimzo: q3 live worked ok, last time I checked :)
spreeuw: half a second I certianly dont have
spreeuw: but its hard to know for sure without a crt
gimzo: I can't see any lag on my lcd, so I guess if there is any, it doesn't bother me
spreeuw: in naycase the 4670 is a good choice now
spreeuw: especially if the features of r600 driver shape up more
airlied: MostAwesomeDude: I think the checker works out the texture size wrong
spreeuw: gimzo: ok between a mousepress and a firing weapon I have no noticable lag here
spreeuw: nor did I when I used the r700
spreeuw: oops x700
spreeuw: but I agree it was too slow for competitive quake
spreeuw: at default settings
gimzo: spreeuw: I have lag between moving a mouse and seeing pointer move, in menus, and the same with turning in game
spreeuw: gimzo: you're talking about the open drivers right?
gimzo: but tremulous works ok, padman works ok, and openarena seems to work ok with gallium drivers (but graphics is broken so I don't see too much)
gimzo: spreeuw: yes, open drivers
gimzo: fglrx doesn't work on r300 anymore
spreeuw: even a 3450 has problems with the blood in openarena
spreeuw: it runs even slower than ut2004 in many cases
spreeuw: nexuiz is also a bit too heavy
gimzo: spreeuw: nexuiz is a slideshow to me :)
spreeuw: very prety effects
spreeuw: have you ever seen it with the normal effects on?
spreeuw: this is not the default
spreeuw: defualt is low
spreeuw: it looks pretty stunning
spreeuw: dynamic lighting plasma stuff
spreeuw: glowing ooze
gimzo: I've seen it, but a few versions ago, so I guess it looks better now
spreeuw: it has a very annoying rocket launcher
spreeuw: the rocket comes out sideways or so
spreeuw: and travels relaly slow
spreeuw: plop
spreeuw: the player models have to little animation too
spreeuw: they all moonwalk
spreeuw: which looks retarded
spreeuw: must be some quake1 limitiation
spreeuw: but for the rest its a cool mix of ut and quake
spreeuw: I wonder if devs of open source games focus on open source drivers at all
gimzo: probably not before, because there weren't any drivers worth focusing on, but now it's the time for that :)
spreeuw: r200 has been aorund forever
spreeuw: its avery good thing to focus on
spreeuw: as target audience
spreeuw: optimize for that class
gimzo: but r200 is not a gaming gpu today, and it probably stopped being that 3 years ago, and for newer hardware there is either no drivers (nvidia) or drivers that are just starting to be useful
spreeuw: open source games could run fine on it
spreeuw: if the devs didnt programm for their nvidio ubuntu blobs
gimzo: even closed source games could run fine on it, I played ut on it without problems
gimzo: but that was then
gimzo: now, I'm still playing ut, but I don't expect nexuiz to work on r200
spreeuw: no that wont work
tlp: hmm. I should have tried Savage 2 to update the RadeonProgram wiki before rebooting to my nvidia card. I see it's not listed.
tlp: (if anyone is interested in doing that, the client/game is a free download)
damentz: hey guys, just letting you know, i've had good reports that fglrx worked with 2.6.32 + tree rcu preemption
damentz: no patches
damentz: thats why i'm buying a card this time around, seems that amd is keeping ahead of the game this time... or at least for these few months
damentz: i guess it'll be a surprise to see how kde4 performs with fglrx
Zajec: damentz: that's channel for radeon
Zajec: damentz: plus Mesa's drivers for radeon eventually
Zajec: damentz: just see topic
damentz: ohh
damentz: Zajec, was unaware of that
damentz: i'll stick around in there and see if i can get fglrx patches early
Zajec: damentz: np :)
damentz: Zajec, it looks a little neglected though, they think the latest fglrx version is 9.9
Zajec: damentz: don't know anythin about fglrx, didn't use it for about a year
Zajec: and when I did that was just to RE something
damentz: RE?
Zajec: reverse engineering
damentz: hmm
Zajec: finding registers for HDMI audio control for radeonhd
damentz: i use it so i can play games :\
Zajec: hopefully you will able to play with Mesa soon
damentz: it's so strange that my favorite games run on linux: warsow, savage 2, and heroes of newerth
damentz: all the other games are not fun... nexuiz is ok but it doesn't feel like a serious game to me
damentz: yes, i'm really looking forward to gallium acceleration
chithead: spring rts > hon
damentz: chithead, nah, hon is a totally different type of game
DanaG: oh yeah, will those new KMS powersavings patches be going into one of the more normal git branches? (or have they already done so?)
fistfuxx: hello?
MostAwesomeDude: ?
fistfuxx: well i am trying to get my ati driver set up and the 3d works fine, but the 2d doesn't work very well
fistfuxx: is this a place to get some info on that?
MostAwesomeDude: fglrx or radeon?
fistfuxx: it's a rv350 in a g4 powerbook
fistfuxx: radeon
MostAwesomeDude: Sure. Are you using a compositor?
fistfuxx: i checked and the fglrx isn't installed
fistfuxx: i don't know what a compositor is
BioTube: compiz, kwin4 effects, xcompmgr, etc
MostAwesomeDude: Um, compiz, metacity effects, kwin effects, etc.
fistfuxx: i haven't installed anything like that so i don't have one unless it came with my distro which is debian lenny
MostAwesomeDude: Hm. You're using GNOME?
fistfuxx: yeah
MostAwesomeDude: So what kind of 2D problems are you having?
fistfuxx: when i move around windows there are trails behind them, which i don't really care about, but when I run pure data the cpu gets to 100% with not very complicated patches
fistfuxx: i checked and pd is only using like 15% of the cpu and xorg is using 75% so I am assuming that is because the gpu isn't dealing with the 2d rendering correctly
MostAwesomeDude: Could you pastebin your Xorg.0.log, please?
airlied: I'm going to guess AccelDFS maybe
MostAwesomeDude: I'm going to guess no linux-firmware.
MostAwesomeDude: Heh. We should have a pool. "Guess the configuration problem!"
airlied: if 3D works then I think I'm right ;-)
chithead: maybe some watermark "you don't have firmware" should be displayed (like fglrx does it with betas / unsupported hardware)
airlied: draw a big RMS picture?
airlied: just RMS's head saying NO FIRMWARE FOR YOU!
airlied: I'm totally with this idea
MostAwesomeDude: I'll file that with the Walken boot splash.
fistfuxx: http://pastebin.com/m383fc03d there is the Xorg.0.log thanks for the help too
airlied: eeww XAA
airlied: ah debian
chithead: Module ati: vendor="X.Org Foundation" compiled for 1.4.2, module version = 6.9.0
MostAwesomeDude: XAA.
fistfuxx: xaa is default right?
airlied: you are running Debian stable, there isn't a huge amount we can do
airlied: I thought NoOffscreenPixmaps would make it useable
MostAwesomeDude: Unfortunately. OTOH, with an Xserver like that, XAA's still better than EXA.
airlied: but you have that
fistfuxx: ok so its just gonna run like that in debian stable? alright maybe i'll try exa
fistfuxx: thanks for the help
soreau: EXA probably wont help unless you have X 1.5 or better at least
chithead: with x server 1.4 exa was not working very well for me. with migrationheuristic in xorg.conf I could switch between slow, broken and both
airlied: yeah debian stable is stably old and crappy, though I'd expect XAANoOffscreenpixmaps to provide usefu
fistfuxx: oh so it's because my debian comes with an old Xorg? so I should try a distro with Xorg 1.5 or newer?
BioTube: i would recommend upgrading to squeeze(though you'll need to install firmware-linux)
fistfuxx: ok cool
BioTube: wait - have you tried AGPMode -1?
airlied: with XAA I don't think AGPMode will help 2D, I'm guessing its all being done in sw
jcristau: xaanooffscreenpixmaps is on in debian stable's x server iirc
fistfuxx: I haven't tried AGPMode -1
Wein: doesnt xvideo work with rv770? when I run a 720p video it take up 20-30%~ of my cpu, seems high to me. is this normal?
airlied: why does it seem high? the cpu is still doing a lot of work
Wein: it well it take as much as x11 output
BioTube: 720p takes a lot of muscle to decode
airlied: if Xv output shows something then its working
MostAwesomeDude: Xv's big win over X11 is when SHM is off and/or the source frames aren't very big but you want to scale them to fullscreen.
Wein: I see
Wein: does opengl output work with the lastest drivers in git,
Wein: ?
BioTube: yes
Wein: okay thanks
airlied: ah finally, multi-ops work
airlied: now to clean up the hacky pile of crap
soreau: :)
soreau: airlied: What functionality does multi-ops provide?
airlied: it just batches X rendering operations into a single cmdbuffer
airlied: pretty much what all cards pre-r600 did
airlied: agd5f: I ported the mesa driver DMA code, got x11perf on card doubled now
ZeZu: whats up airlied
airlied: ZeZu: ah not much, suffering at the hands of ati hw
ZeZu: yea you and me both
ZeZu: I'm having an interesting time with powerpc+custom embedded Xenos chipset
ZeZu: it follows some of the r600 regs at least
airlied: thats the Xbox one?
ZeZu: yea
ZeZu: xbox360
ZeZu: we have working framebuffer + hw 3d but the guy who wrote it just mimic'd writes from regs in proprietary stuff, i went back and used all of the info / naming out of the docs and I'm planning on adding it into gallium3d framework here shortly
happycube: nice :)