Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-11-03

Search This Log:

DeX77: hi
DeX77: agd5f: I build a kernel with CONFIG_FIRMWARE_IN_KERNEL not set.. it still fails in loading the firmware
DeX77: "r600_cp: Bogus length 3392 in firmware "radeon/RV770_me.bin""
DeX77: 5440 3. Nov 00:05 /lib/firmware/radeon/RV770_me.bin
DeX77: 3392 3. Nov 00:05 /lib/firmware/radeon/RV770_pfp.bin
DeX77: so I think somehow the two firmware files (or the length check for them) got mixed
taiu: glisse: gb_tiling_config |= BANK_TILING((mc_arb_ramcfg & NOOFBANK_SHIFT) >> NOOFBANK_MASK);
taiu: isn't the shift & mask backwards
airlied: taiu: if you read the bits I don't think it is
taiu: airlied: maybe, but its different in r600.c and rv770
Zajec: feels some bug in resuming :|
Zajec: sometimes it locks up on resume
Zajec: KMS, non-kms-radeon, non-kms-radeonhd
Zajec: and drm-next
Zajec: anyone know that?
airlied: Zajec: non-kms-radeon?
airlied: oh it locks up no matter what?
taiu: glisse: airlied and in couple of lines further:
taiu: (mc_arb_ramcfg & NOOFROWS_MASK) & NOOFROWS_SHIFT) > 3)
taiu: should't that be >>
Zajec: airlied: right
Zajec: airlied: going to test .30
Zajec: and maybe .i'll try 27 with r6xx-r7xx-support mesa/drm...
Zajec: however not sure if i'll able to compare that mesa/drm with mainline
Zajec: airlied: what do you need to push my patch into drm-next?
Zajec: airlied: ack from someone?
Zajec: airlied: from agd5f? glisse?
airlied: Zajec: no just time to get off my ass ;-)
Zajec: :D
airlied: I've been debugging another bug so I could test that fix
Zajec: airlied: fix is one thing, i rather think about pm debugfs :)
Zajec: AFAIR i was told we can implement exporting clocks using debugfs, so i hope that's what i did in patch
airlied: Zajec: yeah for PM stuff it might be best to queue a few things up in another tree
airlied: though maybe just pushing some stuff out might get it moving more
Zajec: airlied: yeah, i'd love to see that in queue for mainline in normal drm-next
Zajec: airlied: do you see some real reason for pushing that in separated tree?
Zajec: airlied: the patch i've sent shouldn't introduce anything we won't want in future
Zajec: and merging/rebasing.... i'm already sick of it ;)
Zajec: airlied: asic functions changes sometimes to introduced conflict twice already and converting to new init patch also broke my old patch
Zajec: to -> so introduced
Zajec: it's just debugfs so nothing we can not even delete in future
Zajec: (what won't happen, at least i can no see reason for deleting it)
Zajec: but it means we can modify this without consecuentces
Zajec: airlied: so if there is not big problem with it, i'd appreciate putting that in drm-next
airlied: yeah thats life, but I'd like to see a coherent design for power management before adding too much
airlied: but I'll take a look when I process my queue again
Zajec: airlied: hope simple debugfs is not "too much"
airlied: its more asic hooks
Zajec: airlied: ah, that one part
airlied: but it seems mostly sane, but we should probably startthinking about how pm works now that we've pushed out F-12 stuff
Zajec: i've this planned, just too lazy to prepare all patches that will be need to rebased 5 times before hitting master
Zajec: i've this planned, just too lazy to prepare all patches that will be need to rebased 5 times before hitting master
Zajec: that's why i try to get single patch up so hardly ;)
airlied: Zajec: welcome to development ;-) rebasing is like 50% of time ;-)
Zajec: i like other 50% of development :P
Zajec: *the other ;)
aszlig: hullo
aszlig: trying to get KMS running with an radeon, so far all seems okay (at least if it comes to framebuffer), on startx (with the "radeon" module from git, _not_ with radeonhd ;-) i just get a blank screen and this error:
aszlig: [drm:radeon_cp_start_kms] *ERROR* invalid ioctl with kms radeon_cp_start_kms
aszlig: it's a X300SE
aszlig: kernel is a 2.6.32-rc5
aszlig: and this ioctl seems to be really marked as invalid in the kernel source
aszlig: but what i'm wondering is that x is trying to use EXA, shouldn't it just use UXA?
airlied: your libdrm/-ati driver isn't built with kms support
airlied: no EXA is correct
aszlig: ah, okay...
aszlig: libdrm is compiled with kms support
aszlig: same with ati
airlied: look in /var/log/Xorg.0.log
aszlig: ah, hi arlied (seem to remember your name from somewhere)
aszlig: yah, i'll pastebin it, sec...
airlied: but it definitely loosk like libdrm or -ati is wrong
airlied: since otherwise it would workd most likely
Zajec: aszlig: maybe you installed libdrm after installing -ati?
Zajec: aszlig: then -ati autoconfigured without kms support
aszlig: http://www.pastebin.org/50454
aszlig: Zajec: nope, i installed libdrm first
aszlig: compiled the ati module afterwards and it said after the autocanf script that modesetting is turned on
Zajec: ok, -ati seems to have kms compied in
aszlig: and i've built libdrm with --enable-radeon-experimental-api
aszlig: http://www.pastebin.org/50456 <- kernel log
aszlig: hm, so a kms enabled userspace shouldn't call radeon_cp_start_kms... i guess it's the -ati driver which usually calls this?
aszlig: just took a raw look through the ddx source but didn't find any reference to that syscall
aszlig: ah, faund...
aszlig: s/fau/fou/
aszlig: hm, seems to be called by mesa
aszlig: hm, RADEONScreenInit() seems to bail out correctly when not able to call
aszlig: recompiling mesa, so at least it should get rid of this error ;-)
glisse_: airlied: for t60 it seems that accessing vram through mmindex works :)
glisse_: thus it's hdp which is broken
glisse_: and mmindex likely doesn't go through hdp
glisse_: i will do a patch to reset hdp after resume see if it helps
glisse_: anyway good news is that it seems vram is properly restored and this what i was thinking when checking the atombios dump
Zajec: hm
Zajec: i've done 10 tests that failed
Zajec: and 3 success tests
Zajec: i can *not* resume (lock up) when i boot with vga=normal
Zajec: vga=0x323 works fine...
Zajec: is this possible?
aszlig: damn...
aszlig: okay, with mesa from git the error doesn't occur anymore
aszlig: now i get no more errors in dmesg and not in Xorg.0.log, but a blank screen without being able to switch to a VT
aszlig: (as before)
aszlig: though sysrq is still working
Nightwulf|work: hi all
jdizzle: anyone alive?
jdizzle: i just upgraded to the ubuntu 9.10
jdizzle: and the graphics performance of my radeon card is unusable
adamk_: Congratulations :-)
jdizzle: heh, thanks I try
adamk_: What is the card? What is the output of 'glxinfo | grep -i render'?
jdizzle: direct rendering: Yes
jdizzle: OpenGL renderer string: Mesa DRI R300 (RV530 71C1) 20090101 AGP 4x x86/MMX/SSE2 TCL
adamk_: Well that's normal.
jdizzle: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon X1650 Pro (rev 9e)
adamk_: Pastebin your /var/log/Xorg.0.log file?
jdizzle: "pastebin"?
jdizzle: i'm new to IRC support O:)
ferr: pastebin.ca
adamk_: User a service like http://pastebin.com/ or http://pastebin.ca/
ferr: http
adamk_: jdizzle: And what are you using to judge the graphics performance?
jdizzle: http://pastebin.com/d1bac56fc
jdizzle: if I enable the graphical fanciness (which I have had on historically), when I type "yes" into an xterm, it floors the CPU and I can't even interact anymore
jdizzle: it got bad under 9.04, but it's even worse in 9.10
jdizzle: but oddly enough gnome terminal doesn't have the same problem
adamk_: And your log file looks fine, too.
jdizzle: right now I have visual effects disabled
adamk_: Sorry, but based on what you've shown, I don't see any reason for the bad performance.
jdizzle: you want me to turn on visual effects?
adamk_: Someone else, might, though.
jdizzle: i found some scant information about weird compatibility issues with new Xorg
jdizzle: and that some text rendering became more CPU intensive
jdizzle: iirc
taiu: glisse: ping.. you dont' read scrollback I assume
Diablo-D3: I can't wait until glsl can run on galliumized r700s
jdizzle: anyone ready to help me with my challenge?
jdizzle: my challenge of "why do I have really terrible performance"? :)
twnqx: because you have an ATI card. now gobuy nvidia.
jdizzle: it seems to me that typing "yes" into an xterm shouldn't kill my machine, no matter what card I have
twnqx: um
twnqx: i can crash my X by running xdpyinfo
Diablo-D3: woah
Diablo-D3: twnqx: hardcore
twnqx: i don't even get to the point of "start xterm" with KMS.
adamk_: Well that's clearly a bug. Hopefully you opened up a bug report.
twnqx: it's not a bug, it's an ATI
twnqx: btw, you should add aegisub to the apps to test with openlg
twnqx: still doesn't work at all with some memcpy errors
glisse: taiu: i do, from top of my head the code is right
glisse: just weird code
glisse: well better way to put it, weird reg setup
taiu: glisse: sure? BANK_TILING((mc_arb_ramcfg & NOOFBANK_SHIFT) >> NOOFBANK_MASK);
taiu: where rv770d.h:#define NOOFBANK_SHIFT 0
glisse: taiu: yeah you right
glisse: i need to generate proper header for r6xx/r7xx hw
glisse: i wonder how i messed up this one
glisse: i mostly used regular expression when doing this code
taiu: it's not header ... i think it should be like :
taiu: - gb_tiling_config |= BANK_TILING((mc_arb_ramcfg & NOOFBANK_SHIFT) >> NOOFBANK_MASK);
taiu: + gb_tiling_config |= BANK_TILING((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT);
taiu: and
taiu: - if (((mc_arb_ramcfg & NOOFROWS_MASK) & NOOFROWS_SHIFT) > 3) {
taiu: + if (((mc_arb_ramcfg & NOOFROWS_MASK) >> NOOFROWS_SHIFT) > 3) {
glisse: taiu: what i was thinking is to generate header like i did for all other chipset
glisse: look at rv515d.h
glisse: for instance
glisse: and use this
glisse: instead of manual shifting
taiu: mhmh
agd5f: taiu: those should be fixed. I'll send out a patch
glisse: .win 25
eosie: happycube: was that you to say that we should mark R300_NEW_VERTEX_SHADER_CONSTANTS in the dirty state?
cxo: Which rXXX is a 9700pro?
Dr_Jakob: isn't that r300 ish..
Dr_Jakob: http://en.wikipedia.org/wiki/R300
cxo: yeah just found it
cxo: I have one of those on my laptop
cxo: Thinking of building the latest x stuff for it
cxo: dont know if its worth the effort
cxo: Since the gallium3d stuff for the r300 is mostly done, which driver will mesa be using if i build mesa right now?
cxo: Do any of you know the VGA mode for 1440x1050?
Dr_Jakob: the old one... it is still better.
cxo: I found this table http://wiki.antlinux.com/pmwiki.php?n=HowTos.VgaModes
cxo: but i cant find my native 1440x1050 on it
glisse: agd5f: do you know a place where we store one of the multiple avivotools ?
agd5f: glisse: http://cgit.freedesktop.org/~airlied/radeontool
happycube: eosie - yeah, but then figure out why it needs to be there
happycube: per-run constants aren't being reset correctly, so otherwise you only see the first 'set' of vertices for any object
MostAwesomeDude: The constants belong to the shader, not the verts.
happycube: ahhh
happycube: in any case, there's data that's not being updated without it
happycube: cxo - get the 'gtf' utility and you can make modelines for any resolution
agd5f: or cvt
blaise: Hello?
cxo: happycube, thanks
blaise: Does it not support texture compression or something?
cxo: happycube, but how do i pass that info to the kernel at bootup?
cxo: ie what parameter do i pass to radeon or whatever during boot up?
adamk_: cxo, To my knowledge, you can not yet specific a mode to the kernel for the framebuffer console.
adamk_: cxo, Last I heard, there are patches floating around that might let you do this, but they hadn't been committed yet.
happycube: that's a bummer
cxo: ok. i've just got the vesa mode now, vga=0x318 and i get 1024x768 24bit
cxo: http://tldp.org/HOWTO/Framebuffer-HOWTO-5.html
cxo: looks like there was support once upon a time
cxo: append = "video=atyfb:mode:1024x768,font:SUN12x22"
adamk_: Well, yeah, with non-KMS framebuffer drivers, sure.
adamk_: If you are using KMS (which is what I assumed) then it's not yet possible (unless something has changed in that regard recently)
cxo: so what was the point of kms and all if you cant even set the mode?
cxo: i'm using ubuntu 9.10 (2.6.31-14) not sure if that has KMS
adamk_: KMS is supposed to detect the preferred mode from the monitor.
gimzo: Hi, does r500 support PAL TV (ie composite sync, interlaced output and low speed clocks) with new-ish drivers ?
adamk_: I"m quite sure that feature will be added.
cxo: maybe i should build 2.6.32
adamk_: I have no idea if Ubuntu 9.10 uses KMS by default, but I doubt it.
adamk_: So unless you did something to specifically enable KMS, the framebuffer is probably not being drived by the DRM driver.
cxo: yeah ok, i'll build my own kernel and see what happens
blaise: guess no one can see me
adamk_: And if you are using the vesa framebuffer driver (as is suggested by the ability to use vga= ) then you can only use vesa modes.
adamk_: Sure we see you.
adamk_: HI.
cxo: well how do i use the radeon framebuffer?
blaise: ah
adamk_: Either we don't know the answer to your question, or we didn't understand it.
cxo: you mean i shouldnt need to specify anything at boot if KMS is enabled
adamk_: cxo, If you enable KMS by default, you should not need to specify anything.
cxo: ok
cxo: i'm guessing thats part of the kconfig then?
adamk_: If your kernel is new enough, you can enable KMS by default in the staging section under drivers.
cxo: ok
blaise: for some reason I get the following errors... X..GL_ARB_texture_non_power_of_two not found X..GL_EXT_texture_compression_s3tc not found
blaise: Fatal Error: Texture compression unavailable
blaise: does the radeon driver even support texture compression?
gimzo: blaise, I don't think radeon driver supports s3tc
blaise: =(
adamk_: You need a separate library: http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html
adamk_: Which does not work properly with multitexturing.
adamk_: But does work fine with NWN.
blaise: what is nwn ?
adamk_: (Note, what I just said about multitexturing and NWN is true for r300).
adamk_: Neverwinter Nights.
blaise: never heard of it..
blaise: I'm trying to play quake4
blaise: lol
adamk_: Right, that won't work with the open source drivers.
adamk_: It might be like that forever, quite possibly.
gimzo: is there anyone working on s3tc issues? there was something on phoronix a few weeks ago ?
blaise: then I'm gonna go stuff myself in a commercial trash compactor
adamk_: Bye
blaise: why doesn't the opensource drivers support s3tc?
biotube: IP issues
blaise: IP issues?
ajax: IP issues.
ajax: it's called S3 Texture Compression because S3 owns the patents on it.
adamk_: And it if you use that library, you will get that extension. But, as I said, it just won't work properly and your textures will be completely broken.
adamk_: quake4 starts up, and the speed is acceptable, but the game is pretty psychedelic.
blaise: Shazbot.
cxo: do any of you have experience with SSD drives? The old IDE thing in my laptop is dying and i was wondering if SSD would still be worth it without sata
happycube: cxo - depends on the ssd, how much storage you need, and the laptop itself
happycube: (and your wallet ;) )
happycube: also do pata ssd's have TRIM support?
cxo: just need under 40gb really
cxo: dont want to spend too much either, under $100
happycube: 32gb pata ssd's are often jmicron, and w/o trim their older controllers suck
happycube: http://www.newegg.com/Product/Product.aspx?Item=N82E16820208445 - definitely has the write-slowdown prob tho
happycube: i'd look at a sandisk extreme iii compactflash card + adapter
happycube: dunno if it has the slowdown issue as an ssd, but sandisk controllers > jmicron ;)
jdizzle: can anyone explain why a busy xterm eats up 100% CPU on an ubuntu 9.10 box with visual effects enabled? O:)
jdizzle: continues the help-seeking
blaise: becuase xterm is a biabia..
blaise: try using something a bit more friendly
jdizzle: biabia?
jdizzle: friendly?
jdizzle: what's wrong with xterm? =o
blaise: because it's not resource friendly
blaise: never claimed to be..
jdizzle: but.. but why? it's xterm! it's the least fancy you can get, it seems to me
blaise: lol
blaise: it's actualy one of the more fancy terminal emulators available
jdizzle: wow
jdizzle: though I believe my problem stems from text rendering
jdizzle: if I turn off ubuntu's visual effects, xterm stops being so evil
blaise: that is a distinct possiblity..
jdizzle: gnome terminal has no problems, even with transparency
jdizzle: but 'yes' in xterm made my interface freeze until I logged in from elsewhere and killed it
blaise: although I use urxvt in kde-4.3.3 and have all effects turned on and suffer no such issues..
adamk_: For what it's worth, my xterm behaves nicely under compiz with an x1900.
jdizzle: i think the version of Xorg on my ubuntu flavor is part of the problem, too
blaise: I can watch a 1080p movie in the background with mplayer and have four irc windows in forground with transparancies
adamk_: Running yes in an xterm here does increase the CPU usage, but nothing to cripply my machine.
jdizzle: i could have all the visual effects and had no problems
jdizzle: but the text rendering in xterm would make life hell
jdizzle: but *only* with visual effects on?
biotube: I wouldn't be surprised if xterm was just crappy code
blaise: yeah..
jdizzle: it's Xorg that's spiking the cpu, though
jdizzle: and it never happened before
jdizzle: and it doesn't happen when visual effects are off
biotube: could be the pathways used in xlib
jdizzle: also, I had to add these options to xorg.conf to make un-fancy window rendering not be painfully slow:
jdizzle: Option "AccelMethod" "EXA"
jdizzle: Option "MigrationHeuristic" "greedy"
blaise: lol
jdizzle: with ubuntu 8.10 I had visual effects and no slowdown from xterm and life was great
jdizzle: it was noticably bad in 9.04 and now it's unusable in 9.10
jdizzle: i'm fairly certain it has to do with my graphics card
jdizzle: but I'm not sure exactly why/how
jdizzle: and i'm trying to see if anyone knows the driver well enough to explain why some simple renderings would have become computationally expensive in the last few releases
jdizzle: i believe it has to do with updates to the Xorg api, but, again, I'm not sure
kdekorte: jdizzle, are you using compiz? I'm guessing so.. might try without compiz
blaise: lol
kdekorte: Ah... reading above already covered that...
agd5f: jdizzle: AGP?
agd5f: jdizzle: likely some compositor plugin is hitting an unaccelerated path
maggot_brain: so how is the stuff for r600 and r700 coming along? I'm desperate to replace my Nvidia card
agd5f: maggot_brain: 3d works pretty well already
maggot_brain: agd5f: that's good, when can we expect a stable releases of the driver and mesa to be out?
jdizzle: agd5f: pci
agd5f: maggot_brain: 7.6 mesa branch should already be pretty solid.
|wilco|: i just tried the radeonhd driver with my m92 card. for some reason 3d is running at about half the speed as with the radeon driver. Cant see anything weird in my X log that would explain it
jdizzle: agd5f: would be it because of xterm using a deprecated api or something?
wirry: i want opengl2.0 :(
rnoland: wow, i was expecting 7.6.1 way sooner than that...
maggot_brain: agd5f: will it be radeon or radeonhd required for full functionality?
|wilco|: running latest master branch of libdrm, mesa and xf86-video-radeon* and kernel wtih drm-next
biotube: maggot_brain: radeon
jdizzle: i'm perplexed why text rendering in xterm (and emacs) could be so poor
biotube: although rhd should work if you don't want kms
agd5f: jdizzle: I'm not sure what xterm is doing. you'd need to profile it
maggot_brain: so the next releases of Mesa and the radeon X driver + kernel 2.6.32 should sort me out then?
agd5f: jdizzle: do other terminal apps have the same problem?
agd5f: maggot_brain: yeah
jdizzle: agddf: gnome terminal does not
otaylor: the obvious thing would be non-suppor for 1bpp masks
maggot_brain: agd5f: this is really great news, thanks to all the devs. non-free firmware is still required though isn't it?
otaylor: (assuming that xterm is not being used with an antialiased font)
agd5f: maggot_brain: for the CP
maggot_brain: agd5f: CP?
agd5f: maggot_brain: command processor, part of the GPU
jdizzle: otaylor: so you're saying the fact that an app isn't anti-aliasing is causing it to go down the slow path?
otaylor: jdizzle: quite likely
jdizzle: that seems so silly :)
maggot_brain: agd5f: ok, I suppose it's not as bad as nvidia's blob, so nothing will work without the firmware then?
otaylor: jdizzle: well, yes, and no. The X server is set up to do bitmaps (black and white) as 1-bit-per-pixel, but modern graphics cards just don't support that
agd5f: maggot_brain: no accel will work without it
jdizzle: otaylor: so it has to do a bunch of work to shoe-horn it into the fancier way?
agd5f: modesetting will still work
otaylor: jdizzle: so there has to be logic to expand out those bitmaps in the CPU to 1-byte-per-pixel, and that's a lot of complex code that likely isn't going to be done upfront if the devels aren't using non-antialised fonts
ajax: we should really come up with a decent internal expansion from 1bpp to 8bpp
maggot_brain: agd5f: right, I take it the firmware is non-free?
ajax: it's useful enough for masks.
jdizzle: otaylor: has this stuff changed lately?
jdizzle: my graphics card hasn't changed, but performance has gone down the tubes the further up ubuntu's release # gets
otaylor: ajax: it certainly would be nice if it just was handled in exa in a nice centralized place
otaylor: jdizzle: things get shuffled around and that can cause performance regressions in less frequent code paths
agd5f: jdizzle: you probably used xaa in previous releases, which was mostly software
kdekorte: jdizzle, might be a change from using shadowfb to true acceleration. shadowfb was pretty fast, but wasn't really acceleration
MostAwesomeDude: maggot_brain: It's free enough. You can't mod it, but why would you want to?
maggot_brain: don't worry I'm not going to go into an RMS rant!
MostAwesomeDude: IIRC the firmware has received one update to fix a bug, and I think that's it.
MostAwesomeDude: And even if AMD didn't want to help us, we could still dump it from fglrx.
jdizzle: otaylor, agd5f, kdekorte: i had to enable Option "AccelMethod" "EXA"
jdizzle: Option "MigrationHeuristic" "greedy"
kdekorte: EXA should be on by default
jdizzle: to make non-fancy window rendering work right, too
jdizzle: (right == not-slow)
jdizzle: how do those effect things?
agd5f: jdizzle: you shouldn't need to mess with MigrationHeuristic
maggot_brain: Anyways, the long and short of it is: wait for Mesa 7.6, next stable version of Radeon and kernel 2.6.32 and I should be able to use an r700 based card with free drivers?
kdekorte: jdizzle, in fact you can probably run without an xorg.conf file
agd5f: maggot_brain: you already can, if you don't mind building some stuff from git
kdekorte: maggot_brain, what distro are you using?
maggot_brain: agd5f: I don't want to build stuff from git, I'd rather use released versions of software
maggot_brain: kdekorte: Arch
agd5f: maggot_brain: 7.6 is already released. so you'll need the 7.6 branch from git, or wait for 7.6.1 or 7.7
agd5f: maggot_brain: well the 7.6 branch is stable
agd5f: point releases just get cut from it periodically
maggot_brain: agd5f: I prefer keeping stuff integrated into the package manager and 'clean' if you see what I'm getting at
|wilco|: you can always read up on the package format for arch and make your own package from the git version. that way you wont mess up the installation
kdekorte: maggot_brain, then prompt your package maintainer to update it
|wilco|: or install it to an alternate location
maggot_brain: yeah I can use Arch's AUR no problem and have submitted packages to it so that shouldn't be a problem
agd5f: although you will need the 2.6.32 radeon drm to use 3D
|wilco|: drm-next applies cleanly to 2.6.31 afaik
|wilco|: if you feel like running the rest of the kernel from stable sources
maggot_brain: agd5f: one final query, does fan control work for cards that have them? my nvidia makes an absolute racket until X loads up
jdizzle: kdekorte: if the migrationheuristic doesn't do anything, then the accelmethod did. It used to take 5 seconds to render my thunderbird window
kdekorte: jdizzle, what card and driver are you using again?
agd5f: maggot_brain: not yet. hasn't been implemented yet
jdizzle: kdekorte: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon X1650 Pro (rev 9e)
jdizzle: using driver "ati" in xorg.conf, i don't know how else to tell
kdekorte: jdizzle, is it AGP?
jdizzle: n, it's pci
maggot_brain: agd5f: that's a bit of a deal breaker for me, looks like I'll have to wait until that's available
agd5f: maggot_brain: you could use fglrx in the meantime
kdekorte: jdizzle, in the /var/log/Xorg.0.log file looks for radeon_drv.so and right below that there is a version number can you tell us that
maggot_brain: agd5f: no offence, but no thanks, I've had really bad experiences with fglrx in the past and I've no intention of using it
jdizzle: (II) Module radeon: vendor="X.Org Foundation" compiled for 1.6.4, module version = 6.12.99 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0
kdekorte: maggot_brain, get a fanless card... I have an ASUS Silent Magic and the thing is huge, but no fan..
spreeuw: or a 3450
maggot_brain: kdekorte: good idea, any recommendations?
spreeuw: I have a passive 3450 form club3d
kdekorte: maggot_brain, this is what I have.. http://www.newegg.com/Product/Product.aspx?Item=N82E16814121243 but you'll have to look for a newer model
cxo: KMS gets its info from monitor EDID or something?
spreeuw: and it isnt even a fragile heatpipe one
cxo: so silent
agd5f: cxo: yes. so does the ddx
agd5f: in non-kms mode
maggot_brain: kdekorte: right, and I take it you use the free drivers and not fglrx?
spreeuw: nice card
dileX: Linux 2.6.32-rc6 released
cxo: ah come on!
cxo: i just started building rc5
kdekorte: maggot_brain, correct... kernel, ddx and libdrm from Fedora Rawhide and mesa from git, cause the one in rawhide is about 2 months old now
cxo: there is no tarball
cxo: I didn't realise you could get EDID from a VGA capable. I though you needed some sort of digital interface
dileX: cxo: GIT
cxo: doesnt track linux with git
jdizzle: kdekorte: (II) Module radeon: vendor="X.Org Foundation" compiled for 1.6.4, module version = 6.12.99 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0
cxo: i guess a tarball will be out in a few minutes
spreeuw: hmm rolled back my mesa git to oct20 and now it no longer reboots my box or hardlocks in glxgears
maggot_brain: kdekorte: I'll look into it. I've been impressed with the free drivers on my X1400 laptop and I have a 'bit' of the RMS mentality so I'm wanting to switch to ATI+free drivers ASAP
kdekorte: jdizzle, hum, looks like that driver should have EXA enabled by default, maybe agd5f has a thought
agd5f: kdekorte: yeah, it should, unless it has less than 32 MB of ram
jdizzle: kdekorte: let me restart without any options and see if it's as bad as I remember
spreeuw: hmm how do I get back on the main branch with git
spreeuw: like HEAD
spreeuw: oh co master
cxo: git checkout master
cxo: origin/master
cxo: There was a really cool git crib sheet hanging around once
crib: sheet?
cxo: http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png
jdizzle: kdekorte: yeah, when I take out the migration hueristics option, thunderbird takes 5 seconds to render it's window when I switch back and forth between desktops
cxo: crdlb, http://www.google.ca/search?q=define%3Acrib+sheet&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox-a
cxo: crib, i meant , http://www.google.ca/search?q=define%3Acrib+sheet&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox-a
crib: I know :)
kdekorte: jdizzle, I don't know that option did much on r300, how much RAM does your video card have? Could be why you need it.
jdizzle: kdekorte: according to ati's website, 512 MB
spreeuw: huh git log is not chronological
spreeuw: is the commit order at least fixed?
kdekorte: jdizzle if you disable desktop effects and disable migration hueristics is the redraw still slow?
jdizzle: kdekorte: no
jdizzle: kdekorte: i just enabled the middle effects level
jdizzle: kdekorte: wait, yes to your first question
jdizzle: if I have visual effects off, and take it the migration hueristics option
jdizzle: the redraw is slow
jdizzle: i haven't tried with visual effects on and migration hueristics out
jdizzle: s/take it/take out/
jdizzle: kdekorte: i just enabled medium effects, and xterm isn't quite so bad as I've seen it
jdizzle: Xorg still takes up 100% cpu when I do 'yes' in an xterm, but it's actually usable
jdizzle: and paging through text documents in less doesn't take a full second to render the text
jdizzle: i think i can actually live with this level
kdekorte: the pci interface may be limiting the amount of data that can be pushed along with a non-accelerated path may be why it is slower
maggot_brain: kdekorte, adg5f: thanks for the information and suggestions
kdekorte: jdizzle, might try with Option "NoAccel" "true" and see how it performs
taiu: jdizzle: you could try Option "AccelDFS" true or some sort of that
jdizzle: what do those do?
taiu: jdizzle: it may work for you, but since you'r on AGP it may also not
jdizzle: taiu: on pci, not agp
taiu: jdizzle: your xorg log claims AGP card
jdizzle: taiu: i could be retarded
taiu: and it doesn't enable DownloadFromScreen by default
jdizzle: i probably am :)
jdizzle: right now i have all effects enabled
jdizzle: and the migration huerusstics option on
jdizzle: and xterm is performing better than it had been in 9.04
jdizzle: and way better than it was when I upgrade to 9.10
kdekorte: jdizzle, so was the mh option the only one you ended up changing?
jdizzle: the migration hueristics
jdizzle: err i'm assuming "mh" meant inside xorg.conf
agd5f: jdizzle: remove the migrationheuristics option and enable acceldfs
osiris_: MostAwesomeDude: I've found the proper fix for textures
osiris_: MostAwesomeDude: the texture cache need to be invalidated before! we set new textures
jdizzle: agd5f: what will that do?
airlied: osiris_: make texrect work?
agd5f: jdizzle: should perform better
osiris_: airlied: nope, texrect doesn't work yet because the in-driver generated constants aren't handled yet
airlied: osiris_: ah thats where it was failing, I was also getting busted blending as well which I think the tex flush might fix
osiris_: airlied: blending ops where fixed recently by eosie
spreeuw: grr tracking down bugs to commits is annoying
MostAwesomeDude: git bisect is your friend
spreeuw: I'm no programmer all I can do is rebuilds and try
spreeuw: but I'm getting nearer
stikonas: git bisect requires no programming knowledge
spreeuw: what i do now is look in git log
spreeuw: and step through the commits
spreeuw: in commit order
stikonas: git bisects automatically does that for you
spreeuw: of appearance
stikonas: in a more optinal way
agd5f: spreeuw: git bisect is probably easier
stikonas: it reduces the number of commits each time by 2 times
stikonas: instead of by 1 commit
agd5f: all you need to know is when it last worked
spreeuw: I'm tracking that down
spreeuw: will try bisect later
spreeuw: its a hardlock in glxgears
spreeuw: theres specific mention of glxgears in the gitlog
spreeuw: but thtas not the commit that breaks it
spreeuw: ok after doing git bisect next it starts on the good or on the bad side?
spreeuw: does it do the checkout?
spreeuw: after doing the step
agd5f: spreeuw: you specify good and bad and it bisects the the commits between them
spreeuw: yep, so when i do bisect next it steps on up?
spreeuw: one
agd5f: spreeuw: there is no next. good, bad, skip, or reset are all you generally need
agd5f: git bisect start
agd5f: then git bisect bad or git bisect good, and it does the rest
blaise: sobs profusely about no s3tc
spreeuw: blaise: hehehe
blaise: totaly prevents me from playing basicly any modern game..
spreeuw: yep
osiris_: MostAwesomeDude, airlied: here's the patch for texrect http://pastebin.ca/1655561 it mostly works, and if you figure out how to properly calculate the dims without border, go ahead and commit it
spreeuw: disabling it hard in drirc helps for a bunch blaise
blaise: drirc?
spreeuw: find the driconf program
spreeuw: and disable s3tc there
spreeuw: it will seperate the bad games from the good games
spreeuw: agd5f: ok and what about git log, does that order mean anything?
agd5f: spreeuw: lit log just shows the commits in the tree, in the order they were committed
spreeuw: seeing commits of august after november 3 looks weird
agd5f: merges from other branches
|moe|_: hi there. kubuntu karmic 9.10 runs the ati/radeon-drivers on my rs690 (x1250). how can i make it a) run radeonhd or b) use KMS?
|moe|_: there is no xirg.cong anymore in 9.10
|moe|_: s/xirg.cong/xorg.conf
chithead: |moe|_: both a) and b) is not going to work. for a), create xorg.conf with radeonhd in device section
|moe|_: chithead: so there is still an option to use an xorg.conf?! that's nice - do i need a complete xorg.conf or only the specified option?
chithead: just the device section
|moe|_: chithead: even simpler. thanks, i'll try. if i knew that before it wouldn't have been so hard to enable shmconfig and horizontal scroll with my synaptics TP. i had to go the long road writing a hal-policy
chithead: huh? all input related stuff in xorg.conf is ignored by default
chithead: must be configured via hal fdi
|moe|_: in openSuse 11.1 it worked fine by just using the xorg.conf
|moe|_: gotta go, c ya
chithead: and hal fdi example files are in /usr/share/hal and only need to be adjusted
agd5f: |moe|_: for b, boot with radeon.modeset=1
blaise: spreeuw: driconf doesn't seem to have anything about disabling s3tc
|moe|_: agd5f: thank's i'll try that as well
blaise: besides that, the games that I want to play require it.. so I don't think disabling something I don't even have support for via radeon driver will help much
agd5f: |moe|_: can't use radeonhd with kms however
blaise: spreeuw: ah, never mind, I found it..
spreeuw: hey cool i found it with bisect agd5f
spreeuw: 5f7d5d3ea3932ef6028b21bb22d8d28dbdd9fa9f hangs my r600 when I start glxgears
spreeuw: it also crashes the kernel i think because audio quits too
agd5f: spreeuw: what card?
spreeuw: rv620
spreeuw: a 3450
twnqx: wonders if that's also the one that kills my rv635
agd5f: spreeuw: what drm are you using?
spreeuw: uh-oh
spreeuw: Initialized drm 1.1.0 20060810
spreeuw: Initialized radeon 1.29.0 20080613
agd5f: spreeuw: are you using drm-next or my old r6xx-r7xx-3d tree?
spreeuw: I downgraded back to 31.5 with your tree
spreeuw: drm-next confuses me
stikonas: this tree is unsupported
spreeuw: it downloaded a 1GB linux tree
twnqx: the one from the topic is unsupported? great job...
stikonas: you can use precompiled 2.6.32-rc6 packages, if your distribution provides them
spreeuw: I'll u[grade to 32rc6 tomorrow
spreeuw: should that be good?
rehabdoll: .32-rc includes all the new good stuff?
stikonas: it does not have all patches drom drm-next
rehabdoll: ah
stikonas: but it is better than r6xx-r7xx-3d
twnqx: ummm
twnqx: it's an rc, which usually means it's not stable enough for normal use :X
spreeuw: but what about the code quality of drm next for the rest of the kernel?
stikonas: rc6 should be stable enough, it is not rc1
rehabdoll: atleast they seem to have fixed the ext4 horrors from the previous rc's with the one released today
agd5f: spreeuw: you can pull drm-next into a stable kernel as per the topic
spreeuw: help I'm using ext4
spreeuw: ;p
twnqx: seem to have fixed is actually not good enough
twnqx: but i'm also interested in 2.6.32 scheduler fixes :X
spreeuw: git bisect is helpful indeed will remmeber it for the future
spreeuw: once I understood it picks the middle commit eacht time between known good and known bad
kdekorte: airlied, I'm using the rawhide -112 kernel and between -97 and -110 (but present in -112), the line at the top of the cursor is back... but not everywhere on the screen
kdekorte: may happen when the default pointer is reloaded (maybe only by GTK)
airlied: kdekorte: wierd, can't think of anything that sohuld affect that
spstarr: ext4 has bugs in -rc4
kdekorte: I can make the line go away with gdk_window_set_cursor(window->window, NULL);
spstarr: and -rc5
spstarr: ew
spstarr: Revert "ext4: Remove journal_checksum mount option and enable it by default"
chithead: http://bugzilla.kernel.org/show_bug.cgi?id=14354#c167
chithead: is fixed since yesterday (or the day before yesterday depending on your time zone)
spstarr: chithead: i reported other ext4 corruption
spstarr: it might be this
spstarr: building -rc6 + drm-next...
spstarr: drm-next is merged into -rc6 already
spstarr: or maybe not
chithead: anyway you don't want to use 2.6.32-rc kernels with ext4
spstarr: chithead: it should be ok in -rc6+
|moe|_: agd5f: so for that option modeset=1 i create a file in /etc/modprobe.d/ containing "options radeon.modeset=1" right?
agd5f: |moe|_: if you want to to be default
|moe|_: agd5f: i only see benefits, don't you?
agd5f: |moe|_: yeah
|moe|_: agd5f: do i have to reboot to make changes take effect?
agd5f: |moe|_: shouldn't need to
|moe|_: agd5f: just relogin?!
agd5f: |moe|_: once the modules is loaded, it's loaded
agd5f: it only makes a difference when you load the module the next time
|moe|_: agd5f: i'm gonna reboot - less thinking :D
|moe|_: c ya
|moe|_: and thanks
|moe|: drm reports modesetting isn't supported, hmpf
|moe|: what could "open /dev/fb0 no such file or directory" mean?
twnqx: "there is no devicenode named /dev/fb0"
twnqx: which in the days of udev would mean that you don't have framebuffer support
|moe|: twnqx: which does me effect practically when i do what?
biotube: it means KMS is disabled
|moe|: biotube: unfortunately it is :( - how could i possibly fix that?
biotube: you'd need to compile a KMS-enabled kernel
biotube: either 2.6.32-rcX or something from drm-next
|moe|: shouldn't this darn karmic have kms enabled anyway?
|moe|: oh
|moe|: biotube: thanks for the info
twnqx: options radeon.modeset=1 <--- no, options radeon modeset=1, space not dor
|moe|: twnqx: worth a try! would that also work with a 2.6.31-kernel?
twnqx: well
biotube: |moe|: you'd need the drm-next overlay described in the topic link
twnqx: rmmod radeon; modprobe radeon modeset=1 enables KMS
twnqx: wiith a patched 2.6.31 kernel as per topic
twnqx: it just... fails after this.
twnqx: (for me)
twnqx: btw, what are the userspace tools for kms textmode?
|moe|: biotube: now that is not intended, the stable tree is plain vanilla from which in would have to build, right?
|moe|: maybe i'll wait for the ubuntu crew to provide a 2.6.32 at x-mas
cxo: Is agpart still needed with new cards?
cxo: well i mean non agp card
airlied: no, only on intel gpus
cxo: hey mekius
mekius: cxo: hi
cxo: is there e17 in the default ubuntu 9.10 repos?
cxo: drivers/gpu/drm/radeon/radeon_atombios.c:609: warning: the frame size of 1464 bytes is larger than 1024 bytes
cxo: (from 2.6.32rc6)