Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-12-07

Search This Log:

SoxFan1521: hi anyone there?
chainsawbike: maybe
SoxFan1521: Hi all. i am new to Linux and have an older machine that is a 733mhz processor, pent 3, 512ram and I am using the onboard graphics at the moment which seems to be slow when watching videos on sites like youtube.com.
SoxFan1521: There is an open AGP slot on the motherboard
SoxFan1521: I wanna know what card would be ok for this setup
SoxFan1521: i believe the power supply is only 200 watts
SoxFan1521: so i know i cant use a card made recently
SoxFan1521: anyone have any ideas?
SoxFan1521: oh also i am running Puppy Linux ver. 4.2.1
SoxFan1521: yep im probably not gonna find one
SoxFan1521: lol
SoxFan1521: peace
happycube: sadly he probably needs a gf8/9k
happycube: ^ and hw-accel flash
DanaG: oh yeah, hw-accel flash for windows freezes my system momentarily on start of videos. it's really weird.
DanaG: It's worse than non-accel, in effect.
happycube: owwww
dmb: ouch
Nightwulf|work: hi all
MostAwesomeDude: airlied: Just got home, messing with kernel patches right now.
MostAwesomeDude: eosie: Workin' on this patch.
MostAwesomeDude: Looks like you put that the first two conditions don't apply if depth/stencil is off.
MostAwesomeDude: verifies
MostAwesomeDude: Hm.
MostAwesomeDude: It looks like if depth/stencil isn't going to get writes, then you're okay.
MostAwesomeDude: eosie: Pushed.
MostAwesomeDude: Also pushed a handful of other things.
MostAwesomeDude: Gallium's radeon winsys is now r600-safe, although r600g itself is still not in master.
rah: with git radeon I get:
rah: (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.31.0
rah: with linux 2.6.32, non-kms
rah: that's with git libdri as well
MostAwesomeDude: Sounds right.
MostAwesomeDude: What were you expecting?
rah: umm
rah: nm
rah: I saw
rah: drmOpenDevice: Open failed
rah: and assumed it was an error report
rah: but then I just saw
rah: drmOpenDevice: open result is 11, (OK)
MostAwesomeDude: No, that usually means you're on non-KMS and it had to probe more than once.
MostAwesomeDude: Yeah, looks like it worked fine.
rah: aye
rah: hmm
rah: I have no TV output connector :/
MostAwesomeDude: God, kernel builds take forever.
glisse: airlied: how do you plane to do hyperz ?
airlied: glisse: I was just playing around for r100 to see how fast it was
airlied: glisse: I don't think what I did would work well
MostAwesomeDude: airlied, glisse : Is there a faster way than rpmbuild to get kernels built?
airlied: I just copied the fast Z clear code, none of other bits
MostAwesomeDude: I did "rpmbuild -bb --target=`uname -m` --without pae --with baseonly ~/rpmbuild/SPECS/kernel.spec" but it seems to still be building PAE kernels. :C
airlied: MostAwesomeDude: I genearlly just build my own
MostAwesomeDude: airlied: And Fedora doesn't mind?
airlied: I rarely build Fedora kernels outside of koji or the 24-way nehalem box
airlied: MostAwesomeDude: nah it works fine
airlied: as long as you get all the configs right
glisse: yeah i also don't build fedora kernel too long
glisse: btw i was looking at Thomas's patch i think we should move to interruptible call now rather than latter
airlied: glisse: yeah we definitely should I thought I did some interruptilbe changes before I wonder where that was
MostAwesomeDude: Okay, so I'm going to try waiting for idleclean after setting the scratch reg for fence.
MostAwesomeDude: The other thing you suggested was to do host idleclean?
airlied: glisse: I did 3b170c3b2e688665fbc2845ba5bb4304bf38a119
airlied: glisse: if you can send a fixed patch I'll apply TH's other two patches
glisse: yeah today i should be able to finish patch i need to do
glisse: it seems the ttm changes work, i am cleaning up the patches
airlied: glisse: btw ever seen an oops ttm_swap process? calling the radeon surface clear functions?
glisse: no ?
glisse: kernel oops got one ?
airlied: I got one today on Fedora kernel but I thought your object rework might fix it
glisse: yeah will likely fix that
airlied: so I'll test on latest drm-next tomorrow and see if I can make it happen
airlied: I think I had to use lots of RAM so shrinker got called
glisse: there was 3 major bug that might rework fixed
glisse: but i can't remember where i spoted them i should have written them down
siimo: i have problems watching youtube with a X2300 laptop card RV550 and radeon OSS driver, very choopy :S and slows down heaps when the video controls appear over the video when i move the mouse
siimo: what gives ? :(
siimo: oh and one core is hitting 100% CPU usage, this is with a normal youtube video no HD stuff
AstralStorm: siimo: which version of X and driver? (check xorg.0.log)
AstralStorm: oh, and kernel
siimo: X.Org X Server 1.6.3
siimo: kernel #2 SMP PREEMPT
AstralStorm: not the freshest
AstralStorm: that version didn't support the necessary feature for accelerated flash at all
siimo: huh? wat version do i need?
AstralStorm: you should at least upgrade Mesa.
siimo: this is only a r300 card
AstralStorm: ah, right
AstralStorm: hm. then I suppose you're hitting the flash block ;) upgrade or patch mesa anyway
AstralStorm: need that client vendor string changed.
siimo: what
AstralStorm: flash has some stupidity included where it checks for software rendering by checking for SGI in client vendor string
siimo: whats this: (II) RADEON(0): Direct rendering enabled
siimo: (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead.
siimo: (II) RADEON(0): Render acceleration disabled
AstralStorm: glxinfo will display that one
AstralStorm: oh, XAA
AstralStorm: the name of the option eludes me
siimo: would that be causing any problems?
AstralStorm: now EXA is the default
AstralStorm: the driver is old
adamk: siimo: Add this line to the Device section of your xorg.conf file:
AstralStorm: yes, it will, no Render = slow font rendering and a bunch of other things
adamk: Option "AccelMethod" "EXA"
AstralStorm: yes, this.
siimo: ok
siimo: any other ways to improve performance
AstralStorm: upgrading X (including libdrm), kernel and mesa
siimo: heres the whole log : http://pastebin.com/m3c8e0d74
siimo: thought it would only help for R600+ ?
AstralStorm: no
AstralStorm: :)
AstralStorm: esp. the pixman update in new X is highly beneficial
siimo: its not so easy to upgrade all those things, kernel is easy but X stuff i tend to not deal with and just upgrade distribution
siimo: do you see any other problems in my log
sannes: Is the pixman update included in xorg-server 1.7.x ?
AstralStorm: sannes: yes and no
AstralStorm: it's unrelated to x server, but it went out at the same time
AstralStorm: uhm, was released
AstralStorm: (modular X is fun)
AstralStorm: so you can have new pixman and older X server - but then, you won't benefit due to missing feature info in drivers
HTT-Bird: hey all
HTT-Bird: got a friend with a Radeon Xpress 200 (Mobile) IGP who currently uses fglrx and is quite displeased with the results
AstralStorm: so, need new xorg-server and new pixman for the extra speed
AstralStorm: affects KMS the most
AstralStorm: but normal as well
HTT-Bird: how much improvement would radeon be for him? (he wants to run EvE Online in Wine, presumably under low settings)
AstralStorm: it won't affect 3D, if that's what you're after
siimo: HTT-Bird: wow you can get fglrx for that?
AstralStorm: for this, you want mesa
AstralStorm: and latest at that
HTT-Bird: siimo, thats what he has, presumably an old version tho
AstralStorm: plus latest drm
siimo: 9.3 was the last one. only supports kernels upto 2.6.29
siimo: :(
HTT-Bird: siimo, hmmm...do you think radeon'd be an improvement for him?
siimo: i dont know but i hav a similar generation card and radeon sucks on it for me
siimo: any distro that has xxorg 1.7?
AstralStorm: siimo: yeah, let fglrx die :)
AstralStorm: siimo: Arch, Gentoo at least.
AstralStorm: I suppose Ubuntu has already or will in the next release
siimo: currently run slackware which isnt the latest
AstralStorm: yeah, slackware is usually slacking
AstralStorm: ;)
AstralStorm: (it's also bad for mental health)
siimo: but dont wanna spend hours setting up a new distro, takes me a while on laptop with bluetooth and wifi and all that
AstralStorm: heh
AstralStorm: if you can manage slack, I suppose you'll be at home with either of the first two I mentioned
siimo: have got it just rite with hibernation and turning off various leds etc
HTT-Bird: also, I saw that the Mesa support for the r600 was coming along in trunk...
siimo: HTT-Bird: what you said is r300 i think
AstralStorm: HTT-Bird: not just there, it's in 7.6 as well, but a bit... cut
AstralStorm: older
siimo: Xpress 200
HTT-Bird: yeah, the Xpress 200 is on the r300 driver
AstralStorm: mhm
AstralStorm: r300 is supposed to work right now and fine
AstralStorm: but a mesa upgrade or the client string patch should help Flash
siimo: will that client patch and mesa upgrade come in the next releases of distros
siimo: i am too lazy to compile all that myself
AstralStorm: mesa 7.7 still has some time to maturity
AstralStorm: now, the patch is obviously for source code
siimo: fedora rawhide i heard is very bleeding
HTT-Bird: yeah, heard that 7.7 was about a month or so out
AstralStorm: and slackware is especially loath to include patches
HTT-Bird: Arch, basically...
HTT-Bird: is a little behind the bleeding edge tho, he runs Debian testing atm
siimo: testing would be slow now considering new release is coming soonish?
AstralStorm: that's nowhere near soonish
siimo: heh firefox 3.0.x still
AstralStorm: but yes, it is getting stable
AstralStorm: you might need a fresh kernel to use it though
AstralStorm: esp. with >=r5xx
AstralStorm: otherwise the kernel will nicely hang
HTT-Bird: siimo, nah, 3.5 just came in
AstralStorm: yeah, just, as in we're at 3.5.5 already
siimo: distrowatch outdated
AstralStorm: ;p
HTT-Bird: lol :P
siimo: i need atleast kernel 2.6.29 for wifi
AstralStorm: and 3.6 is around the corner (beta4 now?)
AstralStorm: siimo: then 2.6.32 will fit, won't it
AstralStorm: that is about to come out - I expect it in january
siimo: am waiting for a vmware patch for 2.6.32 i hate vmware
AstralStorm: then use virtualbox or KVM?
AstralStorm: ;)
HTT-Bird: is waiting for 2.6.32 to come out so he can use b43 with his 14e4:4315, but that's neither here nor there
siimo: it was out last week
AstralStorm: 2.6.32?
HTT-Bird: oh, :D
siimo: yea
AstralStorm: mhm
HTT-Bird: need to check b43 ML
AstralStorm: neat, I expected one more rc
siimo: contains R600+ KMS
AstralStorm: yeah
AstralStorm: that I know, running rc8 with drm-next branch added
stikonas: airlied: X server does not start for me unless I revert 88a50a30df in xf86-video-ati.
Trisquel-user: hello
eosie: MostAwesomeDude: do you remember the blue color on the background in glxgears? it's back with accelerated clear
bartmon: Hi guys! I hate to ask for support with a non-current version (I have 1:6.12.99+git20090929.7968e1fb-0ubuntu1) but I've had this problem with XVideo for a long time. XVideo output isn't following the window (canvas ?) it is shown in for me. See this video if you want(22 MB!): wget http://stoenka.boldlygoingnowhere.org:8080/files/ati-2-weirdness.avi
zhasha: bartmon: that's especially weird given that XVideo is not supposed to do that and hasn't done that for a long-ass time
bartmon: Well for me it has been doing this for me ever since Ubuntu jaunty when i started using the xorg radeon driver.
bartmon: zhasha: I do have an "exotic" vard, a FireGL V5000 mobile, esentially a X700, aka RV480 or M26 but i don't think that's the problem.
adamk: bartmon: What video card?
adamk: Make sure that your video player is configured to use the textured Xv device, not the overlay.
eosie: bartmon: try using KMS
adamk: That's not it.
adamk: That would only impact playback if he's using opengl.
zhasha: he's right, the only reasonable explanation is that it's not textured xc
zhasha: xv*
adamk: For Xv, though, he needs to be using the textured Xv port. All cards prior to r500 support overlay Xv, which does not work properly in composited environments.
bragon: Hi
zhasha: adamk: is overlay Xv rendered through DRI or something?
bragon: I have a black screen with xorg-1.7.3 xf86-video-ati (from GIT) and the 2.6.32 ...
bragon: i have kms enable
adamk: zhasha: No, it's rendered through the overlay :-)
zhasha: bragon: try disabling KMS
bragon: zhasha: i try that
zhasha: adamk: so essentially it's just the same effect but for a different, equally bad reason
adamk: zhasha: Pretty much. In both cases (DRI and Xv overlay), the X server just opens up a window and lets the application dump it's contents to that window.
zhasha: yeah... srsly, offscreen buffers. I mean come on.
bragon: zhasha: it works without KMS
zhasha: I can appreciate catering to systems with only 2MB of memory but at some point you just got to stop the backwards compatibility and make it work right
zhasha: bragon: are you using a new enough libdrm?
zhasha: always with the libdrm... I feel like a ****ing parrot.
bragon: zhasha: how to check that ?
bragon: i'm using : x11-libs/libdrm-2.4.16
zhasha: try updating it to git head
zhasha: then rebuild xf86-video-ati
zhasha: also, what card are you on?
bragon: HD4770
zhasha: is the screen black from boot or just after starting X?
bragon: second
bragon: after restarting X and impossible to switch to tty after
bragon: i must reboot
zhasha: I'd build libdrm from git then, then rebuild xf86-video-ati
bragon: x11-libs/libdrm-2.4.16 == what version should i have ?
bartmon: adamk: Thank you, I tried mplayer with textured XV and it works! :D Now on to convince gstreamer apps... Also, I think I'll file a bug report on Launchpad to make some configuration changes.
zhasha: bragon: you should have the git head
AstralStorm: mmm :)
AstralStorm: new pixman + xorg-server + xf86-video-ati with kms is as fast as w/o
AstralStorm: great job
AstralStorm: now, the question is
AstralStorm: why doesn't mplayer -vo gl work still
AstralStorm: :)
AstralStorm: still no fragment shaders on r6xx?
AstralStorm: uhnm GL_ARB_fragment_program
AstralStorm: I'm getting some meaningless error from mplayer
AstralStorm: some error 9815360
zhasha: -vo gl2
AstralStorm: no, that's crummy
AstralStorm: and doesn't support nice shader scalers
AstralStorm: gl:yuv=1 works now, why?
adamk: AstralStorm: GL_ARB_fragment_program is definitely supported.
AstralStorm: higher yuv modes fail
AstralStorm: I suppose shader parsing problem
AstralStorm: GL_NV_register_combiners should fail actually, what?
AstralStorm: 2 and up fail
AstralStorm: (fragment programs)
AstralStorm: yuv=6 fails extra chunky
AstralStorm: :)
AstralStorm: I'll try in sliced mode
AstralStorm: who wants the shader program it tries? it looks avlid to my eyes
AstralStorm: yet is rejected
AstralStorm: I'll drop the OPTION ARB_precision_hint_fastest from it
AstralStorm: and we'll see
adamk: Anyone know the meaning of this: "/usr/bin/Xorg: symbol lookup error: /usr/lib64/xorg/modules/drivers//radeon_drv.so: undefined symbol: drmGetDeviceNameFromFd"
sannes: adamk : is it too old libdrm?
AstralStorm: yes, and/or the driver
adamk: Hmmm... Yeah, I see the post on phoronix.
adamk: What'd odd is that I just updated the various components.
adamk: In the proper order, of course. Let me try again and actually check for any warnings/errors :-)
AstralStorm: does anyone have a simple app that will try to compile a given fragment program?
AstralStorm: this one fails for no apparent reason
AstralStorm: very simple yuv conversion as well :)
AstralStorm: yuv=5 works, but incorrectly
AstralStorm: (invalid colors)
AstralStorm: yuv=1 and yuv=5 work incorrectly - but that's because the extensions aren't supported I bet
AstralStorm: others fail
AstralStorm: the simple shader program fails to compile for some reason. help?
eosie: has sent his proposal to accelerate clearing on various gallium drivers to the mailing-list
AstralStorm: ...
AstralStorm: who will fix the darned bug that's been troubling me for so long?
eosie: you can file a bug
AstralStorm: I'm doing it right now
AstralStorm: I've expected someone else to hit this as well
AstralStorm: it's as trivial as playing any movie in mplayer -vo gl:yuv=2
pzanoni: after an update to 1.7.3, radeon 6.12.4 started segfaulting the X server. backtrace: http://pastebin.mandriva.com/15581. This problem doesn't happen with the master branch. I'll try to find out which commit fixes the problem, but if anybody has any idea on which commit it should be, that would save me some time =)
glisse: eosie: what do you call fast clear on r5xx/r3xx ?
legume: AstralStorm: mplayer -vo gl:yuv=2 works for me on rv670 using current gits, mplayer is a bit older.
TBBle: Late, I know, but drmGetDeviceNameFromFd was added to libdrm in 2.4.16, but the configure script for radeon DDX to check for it hasn't been updated yet, because its use by Radeon was added before drm 2.4.16 was shipped.
AstralStorm: legume: interesting
AstralStorm: here it fails 100% of the time, almost
AstralStorm: RV670 as well
AstralStorm: I'll check the drm-next version
AstralStorm: mesa is latest, as is xf86-video-ati
adamk: Well I've updated libdrm and xf86-video-ati but I'm still getting the same error.
adamk: pkg-config --modversion libdrm even shows 2.4.16
AstralStorm: this means your X server is too old?
TBBle: Weird.
AstralStorm: did you rebuild the driver *after* upgrading libdrm?
AstralStorm: does it have the "radeon experimental apis"?
adamk: Yes to both.
TBBle: That's not a radeon experimental API. It's a drm-core API.
AstralStorm: mhm
TBBle: ldd /usr/lib64/xorg/modules/drivers/radeon_drv.so and make sure it's linking the right libdrm, maybe?
AstralStorm: weird that it fails
adamk: xf86-video-ati... The configure script for xf86-video-ati even showed that it kernel modesetting is enabled.
TBBle: Yeah, but the configure script won't notice that that symbol's missing from libdrm, it doesn't check for it. Or didn't yesterday.
AstralStorm: legume: I'm updating the kernel
AstralStorm: we'll see where it goes
adamk: TBBle: That may be it... libdrm_radeon.so.1 is from the version I compiled. libdrm.so.2 is from the system.
AstralStorm: this is 2.6.32, drm branch says 92fb261 commit
adamk: Let me try this again.
AstralStorm: oh, wait
AstralStorm: that tells nothing
legume: AstralStorm: I had to make sure mplayer built against my new libs/headers - but then I have a wierd setup with git under ~/.
AstralStorm: drm-radeon-dp and drm-radeon-testing are in it, wtf?
AstralStorm: I'll better ask the person responsible
TBBle: 05551295c5e0946745163f17e5c1d3d41b94bcbf is the commit that uses that API.
TBBle: adamk: Yeah, that'll be it, unless you system libdrm is 2.4.16 already.
adamk: Odd... Even after pushing /usr/local/lib64 to the top of /etc/ld.so.conf and running ldconfig, it still tries to link against /usr/lib64/libdrm.so.2
TBBle: Weird. Anyway, I'm off, but that should be enough to get you going in the right direction to solve it. ^_^
TBBle: You could rename libdrm.so.2 in /usr/lib64 out of the way. ^_^
AstralStorm: adamk: --prefix I bet
AstralStorm: or pkg-config
TBBle: It's not the build, it's the run-time library loader.
adamk: Yeah, I just moved the system libdrm.so.2 to /usr/lib64/old/ :-)
TBBle: If the build order was bad, it would have failed to compile.
adamk: It's not elegant, but it works.
AstralStorm: it wouldn't have failed
AstralStorm: check your LDPATH and LD_LIBRARY_PATH if any
korc: anybody here who has gone through 2.6.32 + debian + r600 + 3D ?
eosie: glisse: fastfill
eosie: glisse: it can be enabled via ZB_BW_CNTL
BioTube: korc: I am
korc: BioTube: care to share what to get it working?
BioTube: korc: I just followed the guide
korc: radeonBuildHowTo ?
BioTube: yes
BioTube: i'm running squeeze -it might not work on lenny
korc: i'm running squeeze + some stuff from unstable
korc: i was just worried if the guide is out-dated because they have Mesa 7.5 in the examples.. squeeze is already on 7.6
BioTube: korc: the instructions on fusing the 2.6.31 kernel won't work, but the rest is fine
korc: good to know. thnx.
korc: btw, did you get kms working properly, too?
BioTube: yes
korc: ok. then it must be my xorg drivers i guess (stripe hell).
BioTube: if radeon and fbcon aren't given time to initialize before X is loaded, then it fails to see KMS
korc: oh. will try that on next boot ;)
glisse: eosie: zb_cb_clear doesn't need a tiled zbuffer
korc: one more "user support" question;) if i don't enable kms, will i lose GEM functionality, too?
eosie: glisse: that's not stated in the docs... do you mean that only Z compression needs tiling?
MostAwesomeDude: eosie: Still up and scratching your head at clear?
eosie: glisse: also I thought zb_cb_clear doesn't clear a zbuffer, it helps in clearing the colorbuffer according to docs, right?
eosie: MostAwesomeDude: I am basically finished
MostAwesomeDude: eosie: Any regressions? How are you doing it?
eosie: but I am not gonna implement fastfill in a forseeable future
eosie: MostAwesomeDude: I sent a patch to mesa3d-dev
glisse: eosie: where in the doc you think it says that it needs z to be tiled ?
eosie: glisse: section 10.4.4
glisse: my understanding is that zb_cb_clear lead to zpipe to write to cb buffer
MostAwesomeDude: Damn Droid won't let me open it.
MostAwesomeDude: But yeah, I'll read in a bit.
MostAwesomeDude: eosie: keithw will need to approve or not; he said that he doesn't want any more API changes without his okay.
eosie: I know
glisse: eosie: still i think zbuffer doesn't enter in the equation when using zb_cb_clear to clear colorbuffer
eosie: glisse: well, I need to know for sure, I don't want to implement it by trial and error, or as is common in the driver development, aby trial and lockup
eosie: *by
eosie: if it works in the kernel/ddx, then you must be right
glisse: implementing this feature first in demo is the best way to try
glisse: or easiest way
cxo: did any of you guys try that system-crashing screensaver? /usr/lib/xscreensaver/hyperspace
MostAwesomeDude: airlied: http://paste.pocoo.org/show/155426/ did not help me at all; trying now with HOST_IDLECLEAN added to the previous wait instead.
Paulie: Hello, I want to say thank you to every developer here, because I just got Warcraft 3 working (with great framerates!) for a first time with open-source drivers since amd dropped my card from fglrx driver. You are doing excellent job, thanks again.
taiu: agd5f: more cleanups, addons http://cgit.freedesktop.org/~andrem/mesa
agd5f: glisse: Z is always tiled. I think rv100 was the last chip with the option of a linear z buffer
taiu: maybe richard or you can review/comment what can be useful from that
agd5f: taiu: thanks! I'll take a look
taiu: ok, bbl
MostAwesomeDude: agd5f: Any ideas on the rv410 errata? I'm going with what airlied suggested right now...
MostAwesomeDude: So far, no lockups, but it can take an hour or two.
agd5f: MostAwesomeDude: what's the issue?
MostAwesomeDude: agd5f: rv410 causes eventual hardlocks when enabled. Increasing 2D load appears to trigger it, but I have no reliable testcase.
MostAwesomeDude: Dave suspects an rv410 errata where DMA from CP to main mem causes a lock if 2D is not idle.
MostAwesomeDude: I added HOST_IDLECLEAN to r100_fence_wait_emit, and testing that right now.
agd5f: MostAwesomeDude: there's a patch in the pre-kms drm that needs to be ported to kms
MostAwesomeDude: agd5f: Link? Hint?
agd5f: trying to find it
agd5f: MostAwesomeDude: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=aadd4e17452d3d5c2269cd2b000b7de7cfb6c79e
MostAwesomeDude: agd5f: This applies to my rv410 too, not just to r420?
agd5f: MostAwesomeDude: should probably be done on all r4xx chips
agd5f: MostAwesomeDude: probably wouldn't hurt to try it on r3xx-r5xx in general
MostAwesomeDude: agd5f: Hmm, alright, I'll try this if my current patch doesn't work.
crimsonflame123: I asked this question a few days ago too... I've been getting scary messages in /var/log/messages... like these... http://pastebin.com/d2ef7b2bc
crimsonflame123: X restarts after some time... when I happen to be opening a window
crimsonflame123: its always happens when I boot with a dual monitor setup
agd5f: crimsonflame123: file a bug https://bugs.freedesktop.ortg and attach your xorg log and dmesg output
agd5f: https://bugs.freedesktop.org
crimsonflame123: https://bugzilla.redhat.com/show_bug.cgi?id=543812
crimsonflame123: I've already done so
agd5f: ok
crimsonflame123: No activity in it for many days... while I continue to grapple with restarting X and at times losing data :(
MostAwesomeDude: Well, there we go.
MostAwesomeDude: Took long enough, but I got another hardlock.
cxo: Have you tried /usr/lib/xscreensaver/hyperspace ?
cxo: (apt-get install xscreensaver-gl if you dont already have it)
MostAwesomeDude: Nope.
MostAwesomeDude: Which chipset?
cxo: hd4870
MostAwesomeDude: Nope, I'm working on an X700.
cxo: Does it crash for you?
MostAwesomeDude: I'm on a completely different driver.
cxo: So it doesn't crash for you?
MostAwesomeDude: (Also I am too lazy to install xscreensaver.)
cxo: ok
MostAwesomeDude: Well, once I get this thing to stop hardlocking, I can take a look.
cxo: Its probably already in your distro's repos. I get a segfault from r600_dri.so when I run it
cxo: Sometimes it brings down X completely
adamk_: It's not in xscreensaver here.
adamk_: Using xscreensaver 5.10 on FreeBSD.
MrCooper: rss-glx
cxo: try the -extras package maybe? or is there is an rss-glx one too
adamk_: Ahhh...
adamk_: Yeah, really slick screensavers.
adamk_: I'll test it on my 3450 in a few minutes.
adamk_: cxo, Is this with or without KMS, btw?
cxo: with KMS
adamk_: Have you tried it without?
cxo: no
cxo: ubuntu9.10 x86_64, linux-2.6.32
cxo: Does it work on whatever you're running now?
adamk_: Well no lockup here, but FreeBSD doesn't have KMS, so if it's KMS specific, I wouldn't see it anyway.
cxo: Oh ok.
cxo: How come you use FreeBSD?
adamk_: Because I like it.
adamk_: It's clean, simple, easy to maintain and update.
adamk_: Basically, it does what I need it to do.
cxo: I used freeBSD 2.0 (some 10 years ago), was alright. I find Linux is much better these days
soreau: Apparently not too easy to update if it doesnt have kms caps yet ;)
cxo: But I get what you say about it being cleaner
cxo: Linux distros are just a mess these days
adamk_: chooses to ignore soreau's snarky remark.
soreau: heh
cxo: SELinux, Pulseaudio, DBus,
cxo: throws up on linux distros
MostAwesomeDude: cxo: Protip, of those, only one is complete fail.
cxo: Do the BSD guys get any benefit of the X and mesa work? Or does that need to be ported to BSD?
MostAwesomeDude: Most of it's cross-platform, except the kernel modules.
adamk_: cxo, For the most part, I think the mesa drivers are cross platform. The DRM (kernel code) has to be ported.
MostAwesomeDude: And even those used to be built from one tree.
MostAwesomeDude: All the Mesa code's been refactored to the point where it depends on libdrm instead of drm.
adamk_: There is one absolutely awesome developer who does an incredible job keeping up with the maintenance of the drivers on FreeBSD.
agd5f: taiu: Richard reviewed the patches and acked them, so feel free to commit
agd5f: taiu: although we probably want to leave glsl disabled for now
glisse: agd5f: would be good if you can dig up info on fast fill, because the doc seems unclear on that, my understanding is that you need to setup the zbuffer offset to point to colorbuffer
glisse: but i am unsure (this is also unclear on r600/r700 iirc)
agd5f: glisse: I think the idea is the same on both families (r300 and r600). Z always has to be tiled.
agd5f: glisse: see pm4play_clear_test_r6xx/pm4play_clear_test_r7xx in r600_demo
agd5f: http://cgit.freedesktop.org/mesa/r600_demo/tree/r600_pm4.c
taiu: agd5f: ok, i'll go over them and see ...
daggs1: hello, abit of topic, but where can I report a radeon kernel crash in kernel 2.6.32?
agd5f: glisse: the clear requires tiled buffers
agd5f: daggs1: https://bugs.freedesktop.org
glisse: agd5f: my question was more on how do we setup the z stage
daggs1: agd5f, I'm having distortion issues with the latest libdrm, mesa and radeon driver, is there a way to negate hardware problems?
glisse: ie do we setup z color offset to point to color buffer
agd5f: glisse: yeah. see the code in r600_demo
daggs1: agd5f, should I submit under xorg?
agd5f: daggs1: DRI
agd5f: then DRM/Radeon for component
daggs1: ok
daggs1: thnaks
bjaglin: Hi there! For a few days, I am trying to figure out why/how to fix the terrible scrolling performance with KMS on my RV250. In KMS, gtkperf performs up to 6x slower than UMS, and is also much slower than VESA. Is there any tool I can use to profile/point out where the bottleneck is? I do have DRI2, and I tried xorg edgers and Xserver 1.7, it did not help.
Consul_Falx: hello folks... please have a look on my xorg log... http://pastebin.com/fbe2d155
Consul_Falx: am using amd64bit karmic... the xorg falls back in the pre-logon phase...
MostAwesomeDude: agd5f: Hm, for waiting on fences, could we use CP_RESYNC instead of just having CP write directly to the scratch reg?
MostAwesomeDude: Also it looks like r300 has its own fence_ring_emit instead of using r100's?
agd5f: MostAwesomeDude: not instead, but in addition to
MostAwesomeDude: agd5f: Really? It doesn't look like r300_fence_ring_emit calls r100_fence_ring_emit, but just reimplements its functionality.
MostAwesomeDude: agd5f: Oh, first "instead," sorry.
agd5f: MostAwesomeDude: you probably want to queue a resync token be fore submitting an ib, and then add the flush/finish after submitting the ib
mmp: agd5f: hello; Dave Airlie mentioned yesterday that you are working on KMS support for RS600 (bug http://bugs.freedesktop.org/show_bug.cgi?id=25408 ); if you need to test anything; just tell me
agd5f: mmp: do the patches there help fo you?
MostAwesomeDude: agd5f: That's what I figured.
mmp: agd5f: afaik those are the same airlied sent me yesterday, so they do; but with DRI2 enabled, I experience the same behaior as Dariem
MostAwesomeDude: Ugh, so many magic numbers.
MostAwesomeDude: So uncool.
agd5f: mmp: ok. keep your eye on that bug, I'll post any patches to there
mmp: okay, will do
xmikos: Hello, can someone help me with KMS bug on rs690m laptop? I am running kernel 2.6.32, xorg-server 1.7.2, libdrm-git 20091202, mesa-git 20091202 and xf86-video-ati-git 20091202.
xmikos: Whenever I try KMS, everything looks great untill KDE (4.3.4) is started. Login screen (KDM) and KDE starting progress animation looks good, but after Plasma desktop starts, everything is messed up.
xmikos: Here is screenshot: http://eutopia.cz/kms.png
turmlos: xmikos: Looks familiar. https://bugs.freedesktop.org/show_bug.cgi?id=25469
agd5f: xmikos: might be a dup of bug 25469
agd5f: mmp: are you using a GL compositer? if so does disabling it fix the issues?
xmikos: agd5f: Yes, but even if I disable compositing in KDE, results are same.
mmp: agd5f: no composition, as far as I know
xmikos: agd5f: It seems related to Plasma...
mmp: agd5f: even gdm is affected, and I believe that's a way too early for any composition
agd5f: mmp: ok
xmikos: mmp: KDM is not affected here
mmp: agd5f: but I noticed that raw pixmaps are rendered correctly
mmp: e.g. my background photo was rendered without artefacts
turmlos: mmp: gdm can be composited.
mmp: turmlos: hmm... don't know then; but I didn't explicitly turn on any compositing
xmikos: agd5f: Even KDE startup animation looks great, but whenever Plasma desktop (or maybe kwin?) starts, corruption is here
mmp: agd5f: my very uneducated guess is that anything accelerated, like RENDER extension, causes these artefacts
turmlos: mmp: gconftool-2 --get /apps/gdm/simple-greeter/wm_use_compiz
xmikos: Is there something I can do to help debug this? I would really like to be able to use KMS...
mmp: turmlos: not set
spstarr: hmm
spstarr: agd5f: ping
agd5f: spstarr: pong
turmlos: mmp: Might have to run it as user gdm.
spstarr: agd5f: several observations with irq
spstarr: agd5f: you are aware of the stalling?
spstarr: agd5f: 2nd, do we have VBOs working?
agd5f: xmikos: you can try the patches on mentioned on bug 25469
mmp: turmlos: user gdm doesn't have gconf directory
mmp: (nor other gnome directory in its home)
agd5f: agd5f: I haven't experienced any stalling. and vertex buffers work in general, as to second life, I don't know
spstarr: agd5f: glxgears (when maximized window) you see stalls in the gears spinning
agd5f: spstarr: only with irqs?
spstarr: agd5f: yes, w/o irqs no stalls im in non-KMS right now and glxgears is fine
turmlos: mmp: I guess it isn't set then. :)
mmp: turmlos: :-) I guess so
xmikos: agd5f: Btw. I get slight occasional corruptions even with UMS sometimes (it has been good before update to xorg-server 1.7.x, mesa 7.6, etc.)
xmikos: agd5f: But nothing so drastic like with KMS
spstarr: agd5f: VBO issue was irrespective of irq, or KMS w/o KMS thats something else.. im still trying to get a capture of whos telling second life there's no VBO buffer size
turmlos: agd5f: I submitted 25469. No compositer.
spstarr: attempts again to capture the VBO error
spstarr: ok turned on VBOs set tex RAM to 256MB
spstarr: lets get a useful crash
spstarr: agd5f: I know we have a ways to go when I used my GPU in Windows 7 SL was extremely high FPS, but we'll get there
mmp: agd5f: btw, one more thing, which might or might not be realted -- (at least on my laptop) with xf86-video-ati, I sometimes get some part of screen re-painted incorrectly; e.g. a block of wanna-be text in vim is instead black rectangle
mmp: that happens with old DRI, without KMS
spstarr: ERROR: mapBuffer: glMapBuffer returned NULL (no vertex data)
mmp: just in case it could have something to do with current issue...
spstarr: #8 0x0000000001eeb492 in LLVertexBuffer::mapBuffer(int) ()
spstarr: I assume OpenGL mapBuffer() function passes info about VBO buffer ?
spstarr: the stack dump shows no DRI calls
spstarr: but turning off VBOs it works, still, but slowly, and more oddly, I dont know if this is a bug in the DRI driver or not, but over time, it begins to get slower, and slower FPS
spstarr: until I get to the point of 1 FPS and have to restart the program. I am unsure if that is due to Linux graphics stack but the same code in Windows 7 does not have this slowdown, too many variables to look at
spstarr: agd5f: right now, the irq stalling is something I can debug with you
spstarr: agd5f: just need to know what you want me to do do and I'll reboot into KMS so we can find whats causing the stalls
agd5f: spstarr: anything in dmesg when it happens?
spstarr: i didn't notice anything
spstarr: rebooting into KMS now...brb
spstarr: ok, in KMS
spstarr: [ 26.032867] platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin
spstarr: [ 26.101001] [drm] radeon: ib pool ready.
spstarr: [ 27.202169] fb0: radeondrmfb frame buffer device
spstarr: [
spstarr: glxgears is running
spstarr: and i see the gears stuttering as it spins
spstarr: dmesg shows nothing
spstarr: agd5f: any RADEON env debug flags you want me to turn on?
xmikos: agd5f: Sorry for interrupting, can I somehow compile only radeon module with those patches (#25469) or do I need to recompile whole kernel?
spstarr: agd5f: at first, I thought it was due to me using power management (ForceLowPower) but turning that off it still showed stals
spstarr: stalls
agd5f: spstarr: the pm options have no affect with kms
spstarr: ok
agd5f: xmikos: you have to build a whole kernel unless you patch the source of your current kernel
spstarr: agd5f: anything you want me to do next?
agd5f: spstarr: are you sure it's not just wagonwheel effect?
spstarr: wagonwheel? no, there is clear stalls
xmikos: agd5f: I can patch source of my current kernel version... but how can I then build only radeon module?
agd5f: xmikos: you'll have to rebuild all the modules and just copy over the new radeon ones
MostAwesomeDude: agd5f: Hmm. The workaround code doesn't quite mesh with what's in the docs. The RESYNC_ADDR and _DATA go at the top of the IB, then CP_SYNC is used at the end to get the CP to write to scratch, right? But there's no CP_SYNC call in that workaround patch you pointed me at...
MostAwesomeDude: ...and it doesn't look like any CP_SYNC is used at all, really.
spstarr: agd5f: RES: 23948 25697 Rescheduling interrupts
spstarr: 32: 97611 92300 PCI-MSI-edge radeon
spstarr: agd5f: even more suspicious is it looks like the radeon is doing an irq storm since all IRQs are stalling
spstarr: agd5f: when the gears stall so does my typing, mouse, network
spstarr: agd5f: that should not happen
agd5f: MostAwesomeDude: I'm not following
agd5f: MostAwesomeDude: RB3D_DC_FINISH is the important bit
MostAwesomeDude: agd5f: Oh, that has some magic meaning?
agd5f: that's what tells the CB's to update the CP when they are synced
MostAwesomeDude: Ah, and that internally causes the pending RESYNC to fire.
MostAwesomeDude: Cool.
agd5f: MostAwesomeDude: would could (maybe should) use that for fences rather than sw interrupts
MostAwesomeDude: Now I just have to figure out how to get this shoehorned in. The first part in fence_ring_emit is pretty easy...
MostAwesomeDude: Not sure where to put that DC_FINISH though.
MostAwesomeDude: I need to go turn in papers though. I'll look at this more. Thanks for the insight.
agd5f: MostAwesomeDude: put it whereever the timestamp gets emitted
agd5f: spstarr: might try diabling MSIs
spstarr: doing so now
spstarr: can I disable msi just for radeon?
spstarr: hmm no MSI param for radeon
spstarr: so i have to disable it for PCIE
spstarr: agd5f: can you add a kernel parm to radeon module to disable MSI for radeon specifically?
spstarr: i can turn it off globally
agd5f: spstarr: you can edit radeon_irq_kms.c and comment out the msi enable code
agd5f: there's no option at the moment
spstarr: ok
spstarr: in commented out that block in radeon_irq_kms_init()
spstarr: so it does not call pci_enable_msi() anymore it wont use MSI
agd5f: spstarr: yeah
spstarr: agd5f: building
airlied: agd5f: that aptch only works though at start/stop time
airlied: we see this issue at rutime
agd5f: airlied: right. it needs to be set for each ib I think
spreeuw: oh nice vegastrike works after all
spreeuw: it was the shaders crashing it
spreeuw: not dxtn
airlied: spstarr: how long are the stalls?
airlied: like seconds? or < 1 sec
cxo: what do you do in vegastrike
spreeuw: space trading
spreeuw: its a privateer like game
spreeuw: bit of a time killer, but it has a nice nerdy unfinished floss vibe
airlied: the stalls might be the irq mitigation code
spreeuw: http://www.esnips.com/nsdoc/b319f0b3-3200-4123-86ed-b33ff208a7d7
airlied: I need to add some debugging to the irq handler
airlied: also to detect the case where we get a sw irq but the fence reg hasn't changed
cxo: i thought all the irq code was done and it had been checked by the IP review guys
airlied: cxo: whats that got to do with it?
glisse: airlied: i also need to finaly dig out my radeon lockup fence cleanup i send weeks ago
airlied: osiris: btw have you tested compressed mipmaps are aligned correctly for the hw on r300?
airlied: and r500
cxo: airlied, i dont know, you tell me
osiris: airlied: I've tested on r300 only
airlied: osiris: cool don't think it would change (maybe rs690 did)
glisse: cxo: ip review are done, discussion is on an issue spstarr is having
airlied: cxo: IP review doesn't mean it doesn't have bugs
airlied: it means it doesn't get AMD sued
cxo: It should also include 'doesn't get AMD laughed at'. Most OSS contribution reviews do that too :)
airlied: cxo: no they don't caer about that
lordheavy: got some stall problem, but currently i'm running only git master code (no irq)
cxo: airlied, :) I can tell
lordheavy: it's a rs880 chipset
airlied: cxo: how?
airlied: cxo: like if you don't want AMD to release any code until they've tested and QAed
cxo: I can tell because, fglrx bares testament to the rigour involved in AMDs engineering processes.
spstarr: glisse: about to test, just watching a huge tree being chopped down
airlied: cxo: fglrx isn't aimed at consumer users, so really if you are using it, its just because they let you
cxo: right
airlied: I'm not sure how plainly anyone can state that *you* don't matter to any gpu manufacturer
airlied: money matters
airlied: any Linux consumers just don't generate enough money
stikonas: airlied: do you know why commit 88a50a30df11a06263209340a42251851f8e2334 in xf86-video-ati can prevent X server from starting
stikonas: Mesa DRI R600 (RV730 9480) 20090101 TCL DRI2
lordheavy: open drivers is the reason i've bought a motherboard with ati & amd chipset (and a laptop with intel gfx chipset)
spstarr: ugh how long does it take for the guy to chop down a tree
cxo: "If a man is called to be a street sweeper, he should sweep streets even as Michelangelo painted, or Beethoven composed music, or Shakespeare wrote poetry. He should sweep streets so well that all the hosts of heaven and earth will pause to say, here lived a great street sweeper who did his job well"
airlied: stikonas: wierd
airlied: does turning the KMS_MULTI_OP to 0 fix it?
airlied: in r6xx_accel.c
glisse: airlied: are you able to reproduce the ums segfault with firefox on f12 ?
airlied: glisse: we fixed that I thought
glisse: i think so too
airlied: the one with the flush indirect in the backtrace/
airlied: I pushed out the drive rupdate to stable already
airlied: at least I think I did
spstarr: lol
spstarr: the 2 guys can't bring down that big oak tree
spstarr: the tree has fallen
spstarr: what a big crack and bang
spstarr: that must be over 100 years old
spstarr: it was dead anyway
stikonas: airlied: turning KMS_MULTI_OP to 0 doesn't fix it
airlied: stikonas: kms or ums btw?
spstarr: ok now to test no-MSI radeon to see if i get stalls or not
stikonas: kms
airlied: stikonas: can you start X with X -retro?
stikonas: with KMS_MULTI_OP 0?
stikonas: airlied: or leave KMS_MULTI_OP to 1
airlied: yup or without,
airlied: its wierd that didn't fix it
airlied: since it should work like the old code with that
airlied: leave it at 1 and try just X -retro
stikonas: airlied: it works with X -retro
airlied: stikonas: so what is running X for you? gdm? kdm?
stikonas: kdm
stikonas: airlied: ^^
airlied: stikonas: does kdm do any compositing effects?
spstarr: testing now
spstarr: agd5f: still doing it
spstarr: not MSI related
stikonas: airlied: I don't think so
spstarr: MSI is only enabled for ahci, e1000e
spstarr: agd5f: next?
spstarr: glisse: ping
airlied: spstarr: can you revert the irq mitigation patch?
spstarr: glisse: anything else I can do determine why radeon is causing irq stallouts (blocking the whole system)
airlied: its just after the r600 irq patch in my tree
spstarr: airlied: is that the patch that adds irq support ?
airlied: no the patch after that
spstarr: drm-next?
spstarr: oh on ML
spstarr: gets
airlied: drm-radeon-next
airlied: oh if you applied irq support by hand then its not that I assume
airlied: I thought you were running drm-radeon-next
spstarr: i grabbed the patch agd5f posted + the .bin files, but i have git latest i think
spstarr: on top checking...
airlied: spstarr: you have the v3 of agd5f patch?
spstarr: i have:
spstarr: the first patch
spstarr: airlied: from Nov 30th
spstarr: has there been successive updates?
airlied: the patch has v3 in the title
agd5f: spstarr: you want v3 I emailed it the next day
agd5f: same thread
spstarr: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg45005.html
spstarr: ok getting
spstarr: if its already in drm-next
spstarr: i'll just git hard reset
airlied: spstarr: that not v3
airlied: not sure how you fail to read what we wrote
airlied: just get drm-radeon-next or drm-next
airlied: it'll be easier
spstarr: i thought i did that already
stikonas: airlied: btw, I'm on drm-radeon-testing now
airlied: stikonas: what gpu btw/
airlied: ?
airlied: stikonas: does gdm start (if you have it isntalled)
stikonas: Mesa DRI R600 (RV730 9480) 20090101 TCL DRI2
stikonas: I can install ir and test
airlied: I'll see if I can try kdm today on some r600 hw
spstarr: ok im updated now
spstarr: last change is you pulling in korg/drm-radeon-next
airlied: drm-next is always just going to be merges now
airlied: I'm rebasing it every day or two
spstarr: drm/radeon/kms: add irq mitigation code for sw interrupt.
spstarr: dec 1st, ok testing now
spstarr: i will test with MSI on again
stikonas: airlied: gdm works
osiris_: airlied: looks like small compressed textures doesn't work currently. 63c00c53a3019b801c5eee8a12f7862422f79f10 revealed an old bug
osiris_: airlied: I've got a fix already, but I need to test it some more
airlied: stikonas: hopefully me running kdm will screw up here
osiris_: airlied: here's proposed patch http://pastebin.ca/1706047
osiris_: airlied: basically for compressed textures we need to correctly copy data when src rowstride != dst rowstride
osiris_: airlied: just like for other formats
airlied: osiris_: yeah makes sense
airlied: btw why do we get cases where they don't match?
airlied: do we migrate images into old miptrees where the values are different?
airlied: or is just the rounding up cases?
airlied: .win 4
airlied: oops
osiris_: airlied: when image isn't stored in miptree it isn't aligned to min 32 bytes rowstride
osiris_: airlied: so during migration from user memory to miptree you have different rowstrides
airlied: cool sounds correct then
spstarr: built, now to see if drm-next stops the stalling
airlied: office &
spstarr: [ 9.680972] radeon 0000:01:00.0: irq 32 for MSI/MSI-X
spstarr: [ 9.680979] [drm] radeon: using MSI.
spstarr: ok testing
AstralStorm: hey
AstralStorm: apparently my drm-next fails to set the mode
AstralStorm: it boots, enables modesetting, no errors
AstralStorm: yet I get no radeondrmfb
AstralStorm: should I set something special there?
spstarr: airlied / glisse / agd5f: same stalling
AstralStorm: I've noticed some stall here too
spstarr: with interrupts and KMS?
agd5f: spstarr: does disabling MSIs system-wide fix it?
spstarr: doing that now
AstralStorm: not sure when they fail
AstralStorm: I mean, when I get the stall
AstralStorm: but I definitely don't get the radeondrmfb
AstralStorm: which is real bad
rhodan: Does every graphics card have a frame buffer?
agd5f: rhodan: pretty much
AstralStorm: Dec 7 22:11:40 transcendent kernel: [ 62.433846] r600_cp: Failed to load firmware "radeon/R600_rlc.bin"
AstralStorm: Dec 7 22:11:40 transcendent kernel: [ 62.433851] [drm:r600_init] *ERROR* Failed to load firmware!
AstralStorm: Dec 7 22:11:40 transcendent kernel: [ 62.433854] [drm:radeon_driver_load_kms] *ERROR* Fatal error while trying to initialize radeon.
AstralStorm: hmm.
AstralStorm: why would it fail?
AstralStorm: my firmware is built-in
AstralStorm: uh, was at least
agd5f: AstralStorm: the rlc firmware is not part of the kernel
spstarr: erm
stikonas: AstralStorm: this file is not in kernel
spstarr: nomsi i thought
AstralStorm: oh damn
AstralStorm: that's some change
stikonas: agd5f: will rlc firmware always be not part of a kernel?
AstralStorm: it worked before
AstralStorm: what does it do anyway
agd5f: stikonas: yes
AstralStorm: and why wasn't it necessary before
agd5f: AstralStorm: no irq support before
AstralStorm: ahha
AstralStorm: ok, fixing that
AstralStorm: where do I get it and how do I tell the driver to try to load it after / is mounteeed
spstarr: agd5f: hmm kernel is not respecting 'nomsi' ?
AstralStorm: actually, maybe I'll just have to update my initramfs
agd5f: spstarr: isn't it pci=nomsi
AstralStorm: now, the question is
AstralStorm: where do I get the firmware file from
spstarr: hmm kernel-parameters.txt is outdated then
agd5f: AstralStorm: I sent it to dri-devel last week
AstralStorm: oh heck
spstarr: doing that
AstralStorm: now I get to find a mailing list archive that doesn't mangle junk
amarks: rlc stands for?
AstralStorm: something or other
AstralStorm: what matters is it's not licenced properly
AstralStorm: so it can be included with Linux
AstralStorm: what a failure
spstarr: msi is off now
spstarr: testing glxgears
spstarr: still seeing irq stalls
spstarr: .......................................................................................................................................................................................................................
AstralStorm: we're getting dots
spstarr: typing stalls when the gears stall
AstralStorm: ;p
AstralStorm: sounds real bad
spstarr: well lemme do a network download
AstralStorm: are other firmware files still included in the kernel?
spstarr: there is some irq contention going on
AstralStorm: agd5f: could you drop me a link leading to the firmware file?
spstarr: downloading kernel source the gears are stalling even more
spstarr: ouch
spstarr: RES: 123451 127561 Rescheduling interrupts
spstarr: 16: 48585 40764 IO-APIC-fasteoi ahci, uhci_hcd:usb6, yenta, radeon
spstarr: reschedule interrupts, meaning the irq failed and another irq has been requested?
AstralStorm: sounds like that
AstralStorm: or it has been stalled
AstralStorm: bumped by something higher priority
AstralStorm: now
AstralStorm: I need that firmware link
AstralStorm: looking through sourceforge archive in 80x25 links is really uncomfortable
AstralStorm: (they have no threaded view)
adamk_: So I have drm-next installed from November 14th and still have issues where I can't disable coherent mode, making it unusable on my x1900. Any chance a newer kernel or newer version of drm-next would have this resolved?
spstarr: starts second life up
AstralStorm: dammit, could *someone* dump me that link...
spstarr: hmm
spstarr: Couldn't write debug register: No space left on device.
spstarr: lovely from gdb
spstarr: 19GB is not enough? :)
AstralStorm: ENOSPC doesn't mean disk space necessarily
AstralStorm: now, firmware link. pretty please...
spstarr: its on dri-devel
AstralStorm: ...
AstralStorm: links. 80x25
AstralStorm: stupid sourceforge needs javascript for threading.
AstralStorm: and it's a busy mailing list.
spstarr: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg45004.html
rhodan: By how much can 2D be sped up on Radeon cards, still? I tried OSX86 on my Thinkpad and Quartz was friggin' fast. Will this be possible with Gallium?
AstralStorm: hmm, mail-archive.com. why didn't it come up first ;)
spstarr: massive stalling in SL still
AstralStorm: rhodan: gallium has nothing to do with it
bjaglin: hi again here, i am reapeating myself, but could someone point me to some tool or method to identify possible bottlenecks in gtkperf or any idea what to try? KMS/DRI2 on RV250 is painfully slow and cpu demanding for scrolling, even on 2.6.32+xorg edgers+xserver 1.7
spstarr: agd5f:
spstarr: [ 680.460035] CE: hpet increasing min_delta_ns to 15000 nsec
spstarr: [ 723.848070] CE: hpet increasing min_delta_ns to 22500 nsec
spstarr: [ 606.744912] do_trap: 11 callbacks suppressed
amarks: md5 hash 411b41ca3117ca88dbd9689a57f09a89 R700_rlc.bin, yes?
rhodan: AstralStorm: not? I thought Gallium would use the 3D units for 2D and make things faster :/
AstralStorm: ?
AstralStorm: there's no 2D in new cards anymore
agd5f: AstralStorm: http://marc.info/?l=dri-devel&m=125960757404659&w=2
AstralStorm: all the work is done on 3D units
AstralStorm: agd5f: too late, got it from spstarr
AstralStorm: :)
AstralStorm: bjaglin: it works fine here with 1.7.2 xorg-server
rhodan: Oh, I see.
AstralStorm: very fast
AstralStorm: latest pixman
AstralStorm: latest xf86-video-ati
AstralStorm: latest libdrm
AstralStorm: and mesa as well
AstralStorm: (latest meaning git master)
AstralStorm: bbiab
bjaglin: AstralStorm: on a RV250? Did you experience problems earlier?
rhodan: But compositing still seems slow. Is it just lacking optimization or will something need to change substantially for constant 60fps while moving transparent windows?
spstarr: agd5f: next?
adamk_: rhodan: What GPU are you using? I've never experienced any serious slow down doing something as simple as dragging a transparent window around.
agd5f: spstarr: maybe disable hpet
rhodan: adamk_: r5XX (Mobile X1400)
spstarr: can try that agd5f
adamk_: rhodan: I haven't considered the radeon/r3xx driver slow for a long time with my x850 or x1900.
spstarr: agd5f: so we've ruled out MSI being the issue
agd5f: spstarr: if it still does it with msi enabled
spstarr: it did
spstarr: 'nohpet' brb
rhodan: Maybe just kwin sucks...
spreeuw: please lemme know when the irq stuff is no longer stalling
mjr: well, there _are_ those dudes doing EXA/XV on top of gallium, but this doesn't necessarily have much to do with compositing performance
spstarr: agd5f: no go, still stalling
spstarr: trying secondlife also
spstarr: RES: 34788 36881 Rescheduling interrupts
spstarr: i hit this real fast too
spstarr: it should be using PIT now
AstralStorm: still I get yuv fail
AstralStorm: with -vo gl:yuv=2
AstralStorm: shouldn't happen
AstralStorm: the shader program is really meek
AstralStorm: oh btw, I still get "falling back to busy waits"
spstarr: then your not using irq patch or you have a .dri config
AstralStorm: I'm using drm-next
AstralStorm: oh, it needs dri2?
AstralStorm: disregard it then for now
spstarr: must use KMS or no IRQ
AstralStorm: how do I build that firmware into Linux
AstralStorm: or otherwise make my kms start from initramfs
spstarr: agd5f: next?
spstarr: RES: 78054 80891 Rescheduling interrupts
spstarr: it certainly is rising fast
spstarr: right now no radeon interrupts are being emitted
AstralStorm: somehow delay drm startup until initramfs is loaded
spstarr: 32: 11646 9328 PCI-MSI-edge radeon
spstarr: per CPU
AstralStorm: so it can find the firmware
AstralStorm: I don't want radeon as module on initramfs
AstralStorm: that sucks quite a lot
AstralStorm: while loading it after mounting root smells bad
AstralStorm: the best (for me, not lawyers) would be building the firmware in
AstralStorm: how do I do that
AstralStorm: somethin with CONFIG_EXTRA_FIRMWARE I bet
spstarr: runs powertop
spstarr: 35.2% ( 55.3) : Rescheduling interrupts
spstarr: wtf
AstralStorm: this sound like irqs pingpong between your cpus
AstralStorm: not too good
kdekorte: spstarr, that is an aweful high percentage for rescheduling ints
spstarr: Top causes for wakeups:
spstarr: 31.8% ( 37.1) : Rescheduling interrupts
spstarr: 28.7% ( 33.5) : extra timer interrupt
spstarr: 19.4% ( 22.6) : iwlagn
kdekorte: I was get 4.8% (325.3) : Rescheduling interrupts
spstarr: 11.1% ( inf) : radeon
spstarr: runs glxgears
kdekorte: 1.8% (132.3) : radeon
kdekorte: that is what I am running, under compiz
spstarr: 73.0% (1675.7) : Rescheduling interrupts
spstarr: 17.0% (391.0) : radeon
spstarr: 2.1% ( 48.0) Xorg : ttm_bo_cleanup_refs (delayed_work_timer_fn)
kdekorte: Xorg is not even on my list
AstralStorm: spstarr: sounds like your irq handler pingpongs between cpu
kdekorte: something is not right on your setup... I'm using drm-radeon-testing branch of drm-next
AstralStorm: is it standard CFS?
AstralStorm: kdekorte: that's outdated
AstralStorm: at least, it was
kdekorte: AstralStorm, are you sure.. Airlied said last week that was the branch to use
soreau: is using latest drm-radeon-testing too
soreau: airlied said drm-next is going to be used for other things now
AstralStorm: hmmh
airlied: adamk_: not sure I thought we had coherent mode all along
AstralStorm: rebooting again
kdekorte: AstralStorm, http://sourceforge.net/mailarchive/forum.php?thread_name=21d7e9970912012010t62a2a98dy1c7545e160c0c2fd%40mail.gmail.com&forum_name=dri-devel
spstarr_: ok, im in no KMS mode
spstarr_: wtf
spstarr_: 59.1% (148.4) : Rescheduling interrupts
spstarr_: 11.6% ( 29.1) : iwlagn
spstarr_: 6.0% ( 15.0) : uhci_hcd:usb6, yenta, radeon@pci:0000:01:00.0
spstarr_: lemme go offline
spstarr_: i doubt its the wifi card
airlied: you can still use drm-next
spstarr: not wifi
airlied: its just going to be tree with all the other branches pulled into it
airlied: drm-radeon-testing is probably still best though
spstarr: im gonna ask lkml why i have high interrupt rescheduling
airlied: running irqbalance?
spstarr: agd5f: glxgears full screen shows no stalls in no-KMS mode
airlied: or something like that? might be it
spstarr: airlied: nope
airlied: spstarr: non-kms doesn't use irqs
spstarr: airlied: ya, no stalls with non-kms code path
spstarr: airlied: the rescheduling interrupts is quite high
spstarr: but im gonna ask on LKML something doesn't seem right on that
spstarr: but with KMS radeon interrupts, im getting stalls that are being impacted by radeon
amarks: how long does it stall for?
amarks: and how often?
spstarr: not long, fractions of seconds
spstarr: but it stalls mouse, keyboard
amarks: constantly?
spstarr: yes
amarks: so your cursor jerks across the screen?
spstarr: but it might be compounded by me having high interrupt rescheduling irrespective of radeon
spstarr: so let me first find out why that is happening
spstarr: amarks: some jerkness, but you'd have to move the mouse to notice it, it is quite short stalls
kdekorte: spstarr, I believe I am on the same code as you and I am not experiencing those stalls
AstralStorm: hmmh
AstralStorm: I got a nice black screen w/ KMS
AstralStorm: no hang though
AstralStorm: checking logs
kdekorte: AstralStorm, did it happen after x started? also do "dmesg | grep drm" might give you a hint
spstarr: kdekorte: what is your rescheduling interrupts
agd5f: AstralStorm: is X still running?
AstralStorm: kdekorte: ...
spstarr: kdekorte: which GPU type
AstralStorm: no, you don't get it
AstralStorm: it happened on boot
AstralStorm: no error there
kdekorte: spstarr, post reschedualting above, and I'm on an rv635
AstralStorm: just a black screen
agd5f: AstralStorm: scren will go blank unless you have fbcon loaded
AstralStorm: I have it builtin
AstralStorm: fbcon might have failed due to one option, disabling it
spstarr: kdekorte: this is happening w/o KMS also but not radeon stalling
spstarr: i think the two issues are not related
AstralStorm: I'm getting a WARNING though after fb pitch
spstarr: let me first find out if something is broken in .32 with interrupt rescheduling
AstralStorm: before "Initialized radeon"
AstralStorm: no mapping of fb message, weird
kdekorte: spstarr, where did you get your kernel config from?
kdekorte: I used the one from Fedora 12
AstralStorm: maybe I need some video line?
spstarr: kdekorte: hybrid mixture
AstralStorm: you know, like, video=radeondrmfb
AstralStorm: but it should've been autoselected
spstarr: nmi_watchdog=0
spstarr: i do not think turning off the watchdog for NMI is the reason(?)
spstarr: if it is...
cxo: Anyone try /usr/lib/xscreensaver/hyperspace yet on >=R600?
spstarr: tries with nmi on
spstarr: makes no difference with NMI on off
spstarr: Rescheduling interrupts is 60%
spstarr: 41\
spstarr: agd5f: so aside from that, you think there might be problems with radeon and irq code still?
agd5f: spstarr: seems specific to your system. I don' think it's a radeon issue
spstarr: agd5f: what else debugging ?
spstarr: agd5f: should have such stalls like that :(
spstarr: agd5f: makes using KMS with DRI2 useless for games
airlied: we might have some waits that should be more interruptible but not sure they would cause that long a stall
airlied: the patches on dri-devel probably need to get merged
spstarr: airlied: the stalls are not very long, they are very fractional
spstarr: airlied: secondlife shows huge stalls when rendering from network info, but i can't assume its due to that, since glxgears shows stalls
spstarr: just not long
spstarr: runs SL w/o KMS now
agd5f: spstarr: seems like a general interrupt issue on your system, it's just that you don't notice stalls when the GUI isn't dependant on interrupts
airlied: yeah no stalls running gers fullscreen on 2560x1600 monito here
spstarr: no stalls in SL w/ KMS off
spstarr: even if its downloading textures to GPU
airlied: we already worked out irqs aren't used with kms off
airlied: so you can't get stalls
spstarr: right
airlied: so no need to mention that ever 2 mins
airlied: we've mostly worked out your machine is doing something wron,g and its most likely not radeons fault
airlied: but might be
adamk_: cxo: I just tested it at home... Slackware 13.0. 2.6.32-rc7 with KMS enabled. No lockups.
spstarr: airlied: im working to get the answer of the high interrupt rescheduling first
spstarr: if that is related or playing into KMS causing stalls, i dont know
airlied: did you ask google?
cxo: adamk, ok, it could be my userspace thats wonky then
spstarr: https://bugzilla.redhat.com/show_bug.cgi?id=438974
spstarr: thats still an old bug
AstralStorm: hmm
AstralStorm: my KMS still fails
AstralStorm: RV670, LVDS output
AstralStorm: worked before, of course
AstralStorm: sounds like it doesn't start fb at all
AstralStorm: but it inits the card
AstralStorm: I see no reference to fb0
AstralStorm: who wants the relevant part of the log?
AstralStorm: (there's a WARNING in it)
spstarr: airlied: it could just be a regression in kernel, or bug in ACPI (wouldn't surprise me)
AstralStorm: http://dpaste.com/130527/ - the part of the log
AstralStorm: no fb mentioned before or after
AstralStorm: looks like radeon drm-next fails to register an FB driver
airlied: AstralStorm: loaded fbcon?
AstralStorm: builtin!
AstralStorm: so, yes.
AstralStorm: do I need to give some video line? it wasn't necessary in the past
airlied: no it should work
AstralStorm: maybe fbcon doesn't like 24b colormaps
AstralStorm: maybe it should've been 32b
AstralStorm: is a bug magnet
AstralStorm: first that mplayer gl bug, now this
AstralStorm: ugh
AstralStorm: I'll try on top of squeaky clean 2.6.32
AstralStorm: that is, pure drm-next
cxo: i sometimes get a crash when using mplayer -vo gl
AstralStorm: I get a shader failure
cxo: but i sometimes get a crash for a lot of things, so i dont think too much about it
AstralStorm: with weird error number
AstralStorm: huge one
AstralStorm: which branch should I use? drm-next or other?
cxo: There are too many merge conflicts with drm-radeon-testing and 2.6.32
AstralStorm: I've tried drm-next btw
AstralStorm: and the abovementioned problem is with it
cxo: that conflicts too
AstralStorm: it doesn't
AstralStorm: it gets in perfectly
uyf: i merged drm-radeon-testing with 2.6.32-git1 without conflicts
cxo: crazy, i'm following linux-2.6 stable
AstralStorm: ?
AstralStorm: there's no such thing
AstralStorm: there's only master
cxo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
AstralStorm: I bet stable has some drm fixes pushed
uyf: i mean 2.6.32-git1 master branch
cxo: i cant merge drm-next or drm-radeon-testing, into that
AstralStorm: because it has some extra drm work, that's why
cxo: i thought so
cxo: but i though airlied would keep up with that tree
AstralStorm: use 2.6.32 for now
chithead: there is a 2.6.32 stable repository
cxo: ok
AstralStorm: -git1 is already into the next release
chithead: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=summary
uyf: yeah thats the one i merged into too but i patched it first with the git1 patch
AstralStorm: wrong
AstralStorm: git1 is NEXT RELEASE.
AstralStorm: pulling that is like running rc0.5 ;)
AstralStorm: or more like, running prebeta
cxo: how do i add that tree and check it out?
AstralStorm: hmmh?
cxo: (instead of doing a clean clone)
AstralStorm: it's just a tree
AstralStorm: clone it with --reference linux-2.6
cxo: yeah, so how do i add it?
uyf: oh, i thought it was just a patch with fixes, well i'm not experienced with this so don't do like i did, just wanted to say i got a clean merge
AstralStorm: then it will share the commits that are in linux-2.6
cxo: I dont get it
cxo: I'm following linux-2.6 now, so how do i back peddle that to 2.6.32
AstralStorm: you have linux-2.6 pulled, right?
cxo: yes
AstralStorm: so git clone that 2.6.32.y tree with option --reference
cxo: inside linux-2.6 folder?
AstralStorm: no
AstralStorm: clone outside it
AstralStorm: nesting repositories is BAD, capital letters and all
cxo: yeah, thats what i'm trying to avoid
cxo: isnt there a tag or something i can use to get me back to 2.6.32
AstralStorm: ...
AstralStorm: drm-next has 2.6.32 in it
AstralStorm: why would you need a tag anyway
AstralStorm: can't use git properly I see?
Zajec: what is MSI?
AstralStorm: Zajec: Message Signalled Interrupts or something
AstralStorm: the next generation interrupt system
cxo: i think i got it
Zajec: thx
cxo: how do i delete all untracked files?
cxo: ok it merged!
cxo: 2.6.32 = 22763c5cf3690a681551162c15d34d935308c8d7
cxo: so i just checked out that commit and then pull drm-radeon-testing
Zajec: glisse: ping
AstralStorm: how nice
AstralStorm: my machine just got a forced threshold reached shutdown
AstralStorm: due to a kernel build
AstralStorm: impossible ;p
Zajec: glisse: ok, mailed dri-devel@
AstralStorm: cxo: pointless
AstralStorm: as drm-radeon-testing contains 2.6.32
AstralStorm: why would you need to merge it manually
AstralStorm: (or does it?)
uyf: 2.6.32-rc8 i'm pretty sure of that
AstralStorm: heh
AstralStorm: drm-next is on 2.6.32 at least
AstralStorm: now I need to find out why my laptop heats up so much now
AstralStorm: sounds like it's not going into the next fan trip point
AstralStorm: why would that be ;p
AstralStorm: but that's for another channel
uyf: is there any way of checking the version of the kernel in the source tree without compiling it?
AstralStorm: does drm-next contain some power saving tunings that could affect temperature?
AstralStorm: (if not working)
AstralStorm: I'm in pure console right now
uyf: AstralStorm: so do u think that using a git1 kernel could have to do with a bug i've found in compiz. the rc8 is more stabler than git1 if i understand u right?
cxo: AstralStorm, i didnt merge it manually, it merges automatically
uyf: stable*
cxo: i was just saying that i found the commit for 2.6.32 in the master tree, so i just check'd out that commit, instead of the latest commit and then pull drm-radeon-testing
uyf: cxo: well i did just like u but i took the latest commit instead and my kms driver is working very good, i added airlieds git to remote and then pulled drm-radeon-testing it merged automatically
cxo: there arent any r700 updates anyways, so i dont know why i even bother
airlied: cxo: how do you know none of the changes don't affect r700?
cxo: What i meant is, there arent any commits progressing 3d on r700, i see a lot of fixes and misc that would benefit the r700, but i'm not really concerned with those
cxo: The only updates that matter to me are 3D, 3D and 3D :)
DanaG: Zajec is the one working on KMS power savings.
airlied: cxo: like irqs?
DanaG: That's the last blocker for me, that makes me not able to use Radeon KMS.
cxo: airlied, yeah like those, who needs them, all they are is a warning message at the moment, its not like its going to help me play anything on wine either way
airlied: cxo: they should make things faser
airlied: by not keeping your CPU at 100%
cxo: whats the point, if "things" dont even run because of the lack of features
airlied: cxo: what the point of you being in here?
airlied: really kenrel isn't where 3D features go to live
airlied: its all mesa
cxo: yeah, i was just saying how i merged the trees, i dont know if you were following
AstralStorm: hehe
spstarr: hmm
airlied: cxo: no I just saw pointless giving out without a clear idea of what is actually in the kernelk
AstralStorm: now, mesa radeon driver is here :)
AstralStorm: I've a q though
AstralStorm: that drm-next problem is clean
spstarr: airlied: I will test any changes your making to the irq stuff
AstralStorm: is any extra debug
AstralStorm: necessary or wanted?
AstralStorm: ok, so should I bisect the KMS bug?
cxo: Do you have time, energy and lots of beer?
airlied: AstralStorm: whats the bug I'm not really following along
AstralStorm: airlied: no framebuffer with drm-next
AstralStorm: in other words, black screen
AstralStorm: the machine is up and running otherwise
AstralStorm: logs say the device inited, but I see no framebuffer binding
AstralStorm: RV670, log piece I've pasted before, want it again?
airlied: ah I'd go and revert the cmap patch maybve
airlied: as a first test
DanaG: weird... fbgrab doesn't grab X under KMS... it grabs whatever TTY was last open BEFORE that.
airlied: DanaG: X doesn't use fbdev undre Kms
AstralStorm: airlied: I suspect that one as well
AstralStorm: airlied: 2.6.32 is still now working here with -vo gl:yuv=2
AstralStorm: *not
cxo: works for me, 2.6.32, kms, r700
airlied: AstralStorm: you using a video= command line?
AstralStorm: airlied: not.
AstralStorm: is it necessary now?
airlied: no shouldn't be
cxo: http://pastebin.com/m6f68d40e
airlied: I've been running that patch on all my boxes for a while and haven't seen issues
AstralStorm: do you have one RV670?
AstralStorm: with LVDS.
AstralStorm: [drm-next 041c862] Revert "drm/kms: allocate framebuffer cmap"
AstralStorm: this one?
AstralStorm: http://dpaste.com/130527/ - log again, in case you've missed it
airlied: AstralStorm: no but the fb drvier doesn't cre about whats plugged in generally
airlied: its pretty standalone
AstralStorm: ok, cmap reversed = working KMS
AstralStorm: so the problem is there
airlied: AstralStorm: that warning you get seems like it might mean something
AstralStorm: still no joy with -vo gl:yuv=2
AstralStorm: yes, it might
AstralStorm: but w/o cmap it happens anyway
AstralStorm: yet stuff works
airlied: AstralStorm: where are you running -vo gl:yuv=2?
AstralStorm: still, less WARNs means more happiness
AstralStorm: now w/ new KMS
airlied: ah cool
airlied: so it seems like alloc_cmap is failing
airlied: I should add a printk there so we get told that
AstralStorm: now, on to mplayer -vo gl:yuv=2 problem
AstralStorm: it is some kind of fragment program compilation problem
AstralStorm: weird error code is returned
AstralStorm: (large number)
AstralStorm: happens since at least 2.6.32-rc6
AstralStorm: or drm-next of that time
AstralStorm: can't bisect earlier
airlied: wierd the kerne lshouldn't really affect that
airlied: just mesa
AstralStorm: I bet it is still mesa :)
AstralStorm: but can't bisect it too far w/o downgrading the kernel
AstralStorm: any extra debug that could be useful?
airlied: not sure I haven't done much with r600 mesa driver yet
AstralStorm: hm
airlied: file a bug might be a good start
AstralStorm: who has?
AstralStorm: mhm
AstralStorm: onto it
AstralStorm: https://bugs.freedesktop.org/show_bug.cgi?id=25505 filed
edt: with r600 with Saturdays's drm-next, libdrm, ddx, mesa -vo gl:yuv=2 works fine with a .avi file
edt: unlike the bug report I do not get an: Error number: 9...
edt: instead I get: [gl] Program statistics:
edt: [gl] instructions: 7/16384
edt: and more
airlied: AstralStorm: I think nouveau ppl found the bug
AstralStorm: :)
AstralStorm: edt: if you read the bug carefully... I said the Error number is my own debug patch
airlied: AstralStorm: the fbdev one btw not the mplayer gl one :)
AstralStorm: ah.
AstralStorm: now, there's only one scaler I'd love to have in there more than the unsharp mask
AstralStorm: lanczos.
AstralStorm: alternatively, cardinal spline bicubic (the normal one is B-spline, which is blurrier)
MostAwesomeDude: airlied: Back, and studying the fence emit code now.
AstralStorm: in other words, Lanczos2 with unsharp mask in the pipeline
yangman: I've been toying with bicubic filtering for XV for r6xx on paper for a while. still haven't gotten around to implementing it, though
AstralStorm: now, someone would have to write a fragment program to do that and that won't be me - I know far too little about GLSL
AstralStorm: yangman: :)
AstralStorm: cardinal spline bicubic is fairly trivial and parallelizable in FIR form
MostAwesomeDude: AstralStorm: Sounds fun, you should do it. :3
yangman: yeah, I had the shader assembly code written up at one point. it's missing the texture setup stuff
yangman: *on paper
AstralStorm: MostAwesomeDude: no time right now
AstralStorm: I have... other things to finish
MostAwesomeDude: airlied: Can everybody take advantage of CP_RESYNC, or just r300+?
airlied: MostAwesomeDude: I think its just r300+
airlied: I implemented it a year or two ago in my kms tree and it didn't work for me
MostAwesomeDude: Hmm.
MostAwesomeDude: I've already got a couple trivial cleanup patches, it'd be a shame if I couldn't get this damn card working right.
airlied: http://fpaste.org/cinp/ is from the F11 kernel
MostAwesomeDude: Since it's the holidays, I'm not likely to see my new card for a while.
AstralStorm: really, since we can have the card run arbitrary programs on arbitrary textures, why anyone needs OpenCL?
DanaG: It gives a standardized way to do GPGPU stuff.
AstralStorm: are people that badly trained in assembly? then we just need a C-like language that compiles to shaders ;)
DanaG: That's the key: standardized.
airlied: making that an if 0 made some fail
MostAwesomeDude: AstralStorm: That's the fun of standards: There's so many to choose from!
MostAwesomeDude: Brook, Cg, BTM, CUDA, GLSL, HLSL...
BioTube: wonders when they'll make an incomprehensible OCL++
AstralStorm: GLSL is likely the most known...
AstralStorm: barring that, Cg
MostAwesomeDude: airlied: I'm not seeing that in my tree; I think I haven't located the IB emit yet.
airlied: MostAwesomeDude: it was my old kernel
airlied: MostAwesomeDude: before glisse rewrote it
MostAwesomeDude: airlied: Oooh.
AstralStorm: mplayer "who needs CUDA" edition - full GLSL h264 decoder? ;p
MostAwesomeDude: airlied: The scratches aren't reserved anymore, right? AFAICT scratch_reg is always #0?
spstarr: mesa -vo gl:yuv=2 == works fine for me w/o KMS... didnt try with it.
AstralStorm: spstarr: yeah, I bet it's something RV670-specific
AstralStorm: it has worked for me before
AstralStorm: now, I've a q - how can I have software scaling, yet accelerated output?
AstralStorm: (e.g. -vo xv w/o the scaling)
eosie: AstralStorm: you can't run generic C code on a GPU... or you can, but it'll be slow like a 10 year old CPU
zhasha: eosie: opencl looks like c
BioTube: i believe it's a subset
eosie: I know how it looks like
eosie: I said *generic* code
yangman: AstralStorm: that makes no sense. the formats Xv accepts almost always involve scaling
eosie: to utilize even the most modern GPUs you must allocate thousands of threads (you can use millions threads on NV50) and code branching must be gpu-friendly, otherwise you're screwed
eosie: the highest number of GPU threads I allocated in CUDA was 600^3 and the CUDA programming guide allows even higher numbers
eosie: plus alignment to a thread block
AstralStorm: yangman: ...
AstralStorm: yangman: the idea is for mplayer to do scaling
AstralStorm: and push the scaled image back
AstralStorm: it doesn't seem to work though
yangman: so, you'd need to be feeing Xv Y'UV444
airlied: MostAwesomeDude: we have a scratch allocator
AstralStorm: that's no problem
yangman: might as well just use x11 output if you want software scaling that badly
AstralStorm: the swscaler can work in YVUV space
AstralStorm: and work well at that
airlied: so you don't know what number reg it is
AstralStorm: x11 output is *slow*
AstralStorm: and I don't want to hardcode the scale in -vf scale
yangman: I don't know if the current Xv implementation accepts any non-subsampled data. it didn't when I was still working on it
MostAwesomeDude: airlied: I noticed. I'm starting to dig deep into the fences.
eosie: MostAwesomeDude: that will come in handy when GL_ARB_sync hits master ;)
moeSizlak: the snozberries taste like snozberries
MostAwesomeDude: eosie: Shouldn't be a big deal. Gonna hafta wire the fences up in winsys though. :T
MostAwesomeDude: airlied: Ooh, r100_ring_ib_execute looks like a prime spot to do IB wrapping.
MostAwesomeDude: I'm not totally sure if it's safe to do CP_RESYNC around an IB though.
MostAwesomeDude: Like, RESYNC; ib_execute; DC_FINISH
MostAwesomeDude: eosie: Oh, FYI; the half-float vert formats are probably in those "reserved" tags in the vert format docs.
MostAwesomeDude: They're covered by license IIRC, so the docs don't have details on them.
MostAwesomeDude: If you dump an fglrx buffer, they should just be sitting there.
MostAwesomeDude: (If I'm wrong, then the dump will show fglrx converting half-floats up to regular floats for god-knows-why.)
eosie: MostAwesomeDude: Which license? I think the SGI patent is talking about floating-point textures and renderbuffers, not half-float vertex formats
MostAwesomeDude: eosie: nV would be my guess. At any rate, it'd be typical fglrx lamesauce if they supported half-float by expanding it in the driver.
amarks: airlied: i'm seeing these everyday
amarks: [87471.094529] [TTM] Failed moving buffer. Proposed placement 0x00060004
amarks: [87471.094532] [drm:radeon_object_list_validate] *ERROR* radeon: failed to validate.
amarks: [87471.094533] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation
amarks: any ideas
eosie: MostAwesomeDude: oh, I wasn't reading the docs thoroughly, it's there - VAP_PROG_STREAM_CNTL.DATA_TYPE_0: 11 (FLT16_2) and 12 (FLT16_4)
spstarr: poor GPU
spstarr: wonders why the main fans on laptop dont turn on
wellwell: quick report for 2.6.32 + debian sqeeze + RV635: following instructions on radeonBuildHowTo, including dri recompile, 3d works fine (compiz). unfortunately, with KMS, it's stripe madness (though you can see blob of stripes representing mouse cursor)
wellwell: well, colorful at least :P
BioTube: wellwell: did you rebuild xf86-video-ati with KMS support?
wellwell: isn't that built-in in the latest git (following the wiki recipe) ?
BioTube: did configure's output tell you it was enabled?
wellwell: i don't know that anymore, but quick grep shows that kms is represented only by git's packed-refs file..
wellwell: so i guess it's not in there.
BioTube: look for kms in your Xorg log file
airlied: amarks: what gpu? how much VRAM?
wellwell: should it show even if kernel module has it disabled? (right now there is no kms-word)
BioTube: it'll mention not finding support for it, though that test can yield false negatives
wellwell: M86M DDR3 600E/700M , about vram, i don't see any message showing size but only that: Cannot get VRAM scratch space. Allocating in main memory instead
wellwell: (that's without kms)
wellwell: ah, here it is: Detected total video RAM=524288K, accessible=262144K
wellwell: how do you enable kms in xf86-video-ati?
BioTube: make sure you compiled libdrm with --enable-radeon-experimental-api and build against it\
wellwell: ah, that i did.
wellwell: (otherwise mesa wouldn't let me compile r600_dri.so too)
wellwell: and yes, i recompiled xf86 after that.
BioTube: well, with KMS you need to load the module and fbcon with time to initialize for X to see KMS is there
wellwell: on console, kms works fine. switches resolution and everything appears working
wellwell: but when i run X, it shows colorful stripes (including cursor), but gdm doesn't seem to do the login
BioTube: then X should see it and enable it
wellwell: is that what you see if kms is not supported by X?
BioTube: yes
wellwell: ok, i'll then look into that later on again. thanks ;)
ryann: i've just upgraded to ubuntu 10.04 lucid lynx beta
ryann: and am having trouble getting X to start
ryann: the radeon module loads without error, though X reports no screen available
ryann: is the driver supported?
Ingmar: airlied: Could you have a look at this patch please? :) http://lists.x.org/archives/xorg-driver-ati/2009-November/012742.html
cxo: distcheck is important
cxo: the more to-the-book autoconf code the better
airlied: Ingmar: ping agd5f about that I'm happy for it to go in, just don't have time to test it at the moment
Ingmar: agd5f: ^ If you've got a moment
Ingmar: airlied: thanks
Ingmar: Is that the right list to mail patches btw?
airlied: Ingmar: generally that or the xorg lists
Ingmar: alright
dmb: MostAwesomeDude, your famous, your listed in the gallium slides!
dmb: one thing i don't really understand though, why wasn't the concept of gallium implemented before?
dmb: its a relatively simple concept
BioTube: gallium's designed around modern hardwar
BioTube: s/hardwar/hardware/
MostAwesomeDude: dmb: Am I ? I haven't read through the stuff yet.
dmb: hardware that is adaptable and programmable?
dmb: MostAwesomeDude, http://www.lunarg.com/wordpress/wp-content/downloads/Gallium3DComponents.pdf
airlied: dmb: when before?
dmb: airlied, when they first started implementing mesa drivers
airlied: dmb: because hw didn't work like that back then
airlied: hence why gallium can't work on older gpus
dmb: hmm
dmb: airlied, meaning video cards were non programmable and only supported directx x and opengl extensions strictly?
airlied: dmb: pretty muhc
MostAwesomeDude: dmb: Yeah, if you go through the years, you can see how each of the fixed pipelines was more and more featureful, but still not programmable.
MostAwesomeDude: Up until the turn of the millennium, that was the cool thing, BTW. Everybody was sure that fixed-function would rule, because programmable chipsets were just too spendy to get fast.
MostAwesomeDude: At our current rate, I bet we'll go FF again in a decade. :3
happycube: depends on how process shrinks go - i could see GPU's becoming mostly/entirely generic vector processors
airlied: move everything into the cpu as a coprocessor
airlied: then start new ifxed rfunction hw
DanaG: Hmm, might be nice to see CPUs and GPUs become one and the same, and make us just have tons of them?
MostAwesomeDude: Yep.
MostAwesomeDude: airlied's got the future goggles. :3
DanaG: wishes somebody would bring back Aureal's sort of stuff -- raytraced audio, essentially!
happycube: :)
airlied: DanaG: thats not really far off, thats pretty much what Intel larrabee would do if it actually launched
dmb: how about vector audio?
dmb: wait, that exists, midi
MostAwesomeDude: Yeah, MIDI's still awesome.
DanaG: As long as you have a good soundfont.
DanaG: like the GUS patchset.
zhasha: raytraced audio = le what?
DanaG: I found a .zip of it, that has some files as symlinks to nonexistent files... when extracted on Linux.
MostAwesomeDude: Yeah, GUGS is what I use for anything but performances.
dmb: is midi expandable?
DanaG: Specifically, there are a bunch of symlinks to "GF1PATCH110"
DanaG: ... which does not exist.
dmb: it should include vocals someday
DanaG: I had to boot Windows... and there, it extracts as actual files.
zhasha: DanaG: get a virtual machine. They're awesome
DanaG: Yet, if you look at GF1PATCH110... that's exactly the first few bytes of the .pat file format!
DanaG: Not for games.
DanaG: =รพ
zhasha: let's you totally scrub your computer clean of any windows crap, but still have an emergency windows installation
DanaG: Wine doesn't cut it, though -- it sucks badly at audio.
dmb: only if it worked well with 3d :P
zhasha: I don't dare install EXT2IFS for windows because I'm afraid some crapware will start deleting files
zhasha: but in a virtual machine, there's no problem
dmb: zhasha, is that the fs-driver.org one?
DanaG: My only ext2 partition (used with ext2ifs) is the one with my firefox and thunderbird profiles and pidgin logs.
zhasha: dmb: yeah, that one
dmb: yeah
dmb: i let it do read only stuff
dmb: but never write
DanaG: ext2ifs sucks... ext2fsd is better.
dmb: thats the opensource one right?
DanaG: Yeah.
dmb: well, i don't think any of them support ext4 yet
zhasha: essentially, I don't trust windows with write access, so I sandbox it in a VM
DanaG: Hence my creation of a small, 1-gig ext2.
dmb: even if it did, i would never trust write access
DanaG: er wait, it's 3 gigs.
dmb: considering the ext4 developers can't even get it write
DanaG: right?
dmb: yeah
zhasha: dmb: something wrong with ext4?
dmb: as you can see, i am a bit tired :P
dmb: zhasha, lost a lot of data by upgrading to kernel 2.6.32 rc something
dmb: ext4 devs screwed up on something
zhasha: dmb: that's like arguing windows = crap from playing with a leaked beta
dmb: there was a huge bug on it, even linus was able to reproduce
dmb: yeah
DanaG: i didn't lose anything, myself...
dmb: but now i just use ext3 for data just in case
DanaG: I left my backups ext3 until very recently.
DanaG: Now I do have my backup as ext4... but about all I ever do is write NEW files to it.
zhasha: I've had no problem with ext4, except for my harddisk being too slow to keep up with the sheer awesomeness it's brought
DanaG: And remove really old files.
dmb: yeah, i wish i could say that
zhasha: what we need now, is a gallium state tracker for directx and commit that to WINE
DanaG: Biggest thing I want from radeon is power management with KMS.
zhasha: and my windows can be mostly eliminated
DanaG: Too bad Wine still sucks at audio!
zhasha: it does?
dmb: biggest thing i want from radeon is evergreen support :P
dmb: someday
DanaG: Can't handle PulseAudio, yet they reject patches that make it work with PA.
dmb: dvi
zhasha: I'm using spotify right now in WINE
DanaG: It also simply doesn't even try to do surround sound.
zhasha: DanaG: AFAIK they just made it go all OpenAL
DanaG: I tried the Creative ALChemy dsound->openal wrapper in Wine... doesn't work.
DanaG: Which is a big bummer, because it'd let me use EAX.
zhasha: but then again, this PC can't even output more than stereo
dmb: i wonder if radeon can accelerate PCI video cards
dmb: i heard fglrx wouldn't do that
dmb: (just curious, don't own any)
zhasha: I'm baffled at this by the way, WINE works perfectly with Spotify, which is a Mac OS X program, ported to Windows by as far as I know using a library you link against for automagic Windows support
zhasha: dmb: PCI as in regular old PCI and also, do radeon PCI cards even exist pre-PCIe
dmb: zhasha, they sell some r7xxs i think that are pci
dmb: maybe thats r6xx
zhasha: what like, 66MHz PCI?
zhasha: and if that is the case, why oh god why would anyone ever buy one?
dmb: newegg sells over 60 of them
dmb: http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=2010380048%201069609642%201305520549&name=ATI
zhasha: are you sure they're not PCI express?
DanaG: There ARE some pci modern-radeon cards.
DanaG: Odd but true.
dmb: look at this: http://www.newegg.com/Product/Product.aspx?Item=N82E16814161283
dmb: looks pretty modern
dmb: 4350
dmb: hd
zhasha: looks like PCI Express
zhasha: or well, looks like it's too narrow a connector
zhasha: my question still stands: why?!
dmb: dunno, i guess old machines
dmb: i'm guessing it MIGHT work
zhasha: but you can't transfer data to that thing fast enough for it to be a viable ANYTHING
dmb: at least modesetting
zhasha: DanaG: got an explanation for this weirdness?
DanaG: hmm, beats me. I don't need one.
happycube: UVD2, assuming it'd work
happycube: you don't need much bandwidth for bitstream video decoding ;)
happycube: but that doesn't even work in windows drivers
zhasha: happycube: well... I have a PC clocked at 1.6GHz (old pile) that is in fact so old that it only has an AGP x4 slot yet it is able to decode and display 720p video in software onto a big screen without frame-lag. As amazing as this is, you need to take into consideration that it also implies UVD2 would have to be used in the case where software can't keep up, thus we step up to serious HD where you need a freight-train of bus width to tr
zhasha: ansfer the video data
DanaG: happycube: just takes registry tweaks.
happycube: ah cool
DanaG: dxvatweaker, I think it is.
DanaG: er
DanaG: checker, not tweaker.
happycube: zhasha - full OTA mpeg-2 is 20Mb/sec. PCI can handle 200-300Mb/s easily.
happycube: I doubt BR goes >50
dmb: zhasha, how about an old pile i have, a 400 mhz p2 with one of the older agp slots :)
zhasha: dmb: I used to have a 25MHz PC but it broke :(
zhasha: happycube: now throw into the equation that that bandwidth is shared with all other PCI buses on the board, throw in a nice and slow north bridge and finally, try to DMA the buffer over (which I assume is how you'd get the data from mem to vmem)
flyback: ponders watching "the men who stare at canucks"
zhasha: I mean, we get what, under 100MB/s on PCIe x16 DMAing buffers over.
DanaG: hmm, worst SATA controller I've ever used was a SiI3112 on my old Abit NF7-S.
zhasha: I remember suggesting something like "oh, just DMA it over" and someone (airlied) shot me down on the grounds that it's actually not a very fast operation
DanaG: PCI... means all I/O chokes it.