Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-11-05

Search This Log:

editka: happycube: so my kernel grub line will look like this? resume=/dev/disk/by-id/ata-ST3120827AS_4MS1WGFS-part1 splash=silent quiet showopts radeon.modeset=0
editka: is this OK?
happycube: change the radeon.modeset to 1 and reboot
editka: oh i mean 1
editka: ok
editka: lets cross fingers
editka: :-)
editka: happycube: now i cannot enable compositing at all :-(
happycube: ouch
happycube: can you pastebin your current xorg.log?
editka: (WW) RADEON(0): Direct rendering disabled
cxo: we need context
editka: yep i know i have delay... waiting for pastebin... :-)
agd5f: 6.12.4 doesn't support kms
agd5f: you need git master
editka: oh
editka: :-((
happycube: doh :(
cxo: git://anongit.freedesktop.org/git/mesa/mesa
cxo: git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
editka: i really dont want to install anything for source code... i would rather upgrade suse's packages but they are incredibly messy i wil need to adjust at least 50 patches to newer versions etc...
editka: and that's a longtime job :-(
editka: i am not doing this for myself but for other people..
editka: i just wanted to show her fancy effects on her new shiny linux box
cxo: Well you could get the src rpms from the dev release and just rpmbuild --rebuild them on your box
cxo: but its easier just to stick to source, and you be the version control
editka: cxo: we have build service ;-).
editka: cxo: wait sec i will show you what i mean
editka: 36 packets transmitted, 17 received, 52% packet loss, time 35020ms OMG :-(
editka: :-(
editka: ok.. to sum it up... i need to upgrade a) kernel b) mesa c) anything else?
editka: mesa is the easiest one to upgrade imho
editka: why i must discover this corruption few days before release long time after feature and version freeze?? :-(((
editka: i see the ton of bugreports of suse users that their graphics isn't working in 11.2 :-(
soreau: editka: You will want latest kernel configured with kms, preferably drm-next, libdrm, mesa and ddx also configured with modesetting support. See the link in the topic
zhasha: editka: c) libdrm
editka: soreau: ok thx... and what advantages does kms provide?
soreau: editka: Basically it allows for compositing managers and 3D apps to play nicely together as well as running both with direct rendering
soreau: It does a lot more than that, but those are some of the noticeable things
editka: soreau: oh ok... and since what kernel version it is implemented?
editka: and also, how do i check if it is enabled in my kernel config
editka: ?
soreau: I would say you are safe using 2.6.32 rc versions should be ok or as I said, drm-next which is described in the topic link
soreau: It will be available by simply selecting DRM>Radeon module
soreau: You can have it on by default by setting KMS in staging drivers section iirc
editka: ok thx much
soreau: Seems with latest updates and drm-next, enemy territory crashes X when it tries to go full screen
soreau: builds 2.6.32_rc6
soreau: I can't seem to reproduce it with any other fullscreen game yet though
soreau: emerges openarena
soreau: Last time I had OA installed, it was flat out segfaulting at runtime so I uninstalled it
soreau: It had been working before some updates
amarks: i moved to rc6 due to that ext4 issue
soreau: 'that' ext4 issue?
soreau: I don't use ext4 at all
amarks: yes there was a bug in unclean shutdowns
soreau: There are probably a lot of bugs still with ext4
amarks: when i rebooted var was fscked up
soreau: I don't see what they'd have to do with radeon drivers though
amarks: not related, but i am only on rc kernel because of kms etc
soreau: I like to test the latest code and possibly bisect in the event of problems
amarks: i just want my r600 to work properly and end up in release drivers so i do not have to worry about it
soreau: now I remember.. OA segfaults when going to init openal
soreau: but seems to init fullscreen ok for the brief moments it does
bobbens: mmm
bobbens: any known issues with vbos? just got to opengl 1.5 driver and it seems like my vbo code that works fine with other cards (and worked fine with sw vbo) doesn't work anymore with hw vbo
soreau: xserver still crashing with 2.6.32_rc6
editka: i seem to found why KMS is disabled in suse... https://bugzilla.novell.com/show_bug.cgi?id=527910 it is KMS really so unstable?
soreau: I wonder if it's not kernel related, but mesa or something else
soreau: editka: It is mostly experimental atm
airlied: they also ship radeonhd from what I know
soreau: To clarify, xserver crashes when enemy territory tries to go fullscreen. Other wise, it works in windowed mode
editka: but it doesnt support my graphics airlied
airlied: its definitely not ready for on by default yet anywhere but Fedora
editka: what has fedora different?
airlied: two full time developers working on it
soreau: it has airlied inside (TM)
soreau: ;)
airlied: myself and glisse have been doing the bug fixing march for the last few weeks
editka: oh... :-) nice to meet you xD
dileX: soreau: whats exactly not working? is that "pure" rc6?
soreau: dileX: I don't really know what you mean by pure, but what is not working is one video game when it goes to fullscreen, it crashes the xserver
dileX: soreau: rc6 with no additional patches
dileX: is that with kms? dri2? r300g?
soreau: dileX: Oh, it is with no patches.. well except one.. kms/dri2 not r300g
twnqx: glxinfo will tell you about dri2
soreau: I just got openarena working and it 'works' in fullscreen meaning it does not crash the xserver
soreau: input and exiting cleanly is another story
soreau: dileX: So it seems to happen only with enemy territory. I can't find another fullscreen gl app that will crash the xserver when it goes fullscreen
twnqx: random question: xdpyinfo reports DRI2, but glxinfo doesn't have the "DRI2" in the opengl renderer string - how comes?
soreau: twnqx: What does your X log say?
dileX: soreau: is "enemy territory" a commercial game?
twnqx: soreau: about what exactly? :X
soreau: dileX: I don't really know what that means specifically, but it is a free game that runs natively on linux
soreau: twnqx: grep -i dri2 /var/log/Xorg.0.log <- does it say dri2 setup complete
dileX: soreau: you have a URL for me?
soreau: dileX: Sure, one moment
twnqx: soreau: no, only mentions DRI, but then only the DRI2 extension is available
soreau: dileX: http://www.liflg.org/?catid=6&gameid=52 the link etf_1.6-english-5.run (265.07MB)
soreau: twnqx: You may need to rebuild mesa against libdrm that was kms support
soreau: s/was/has
twnqx: nah
twnqx: need to update kernel first
twnqx: enableing KMS makes X unusable (dies ~2s after enlightenment dr17 start)
twnqx: and KMS does exactly what is originally was intended to avoid :P
twnqx: console doesn't show up after killall -KILL X, and X can't re-initialize the screen :P
soreau: dileX: Further, this is rv350, X 1.7.1, all latest libdrm, mesa and ddx from git as of today on gentoo
twnqx: so, does 2.6.32-rc6 need any extra patches for rv635?
soreau: It was working last week at least and not sure exactly when it broke but it was by one of the userland trio I suspect
dileX: soreau: thx for URL
soreau: np
soreau: It is not the most popular game, but it is native linux and I like to play it every now and again ;)
soreau: dileX: Also, when I start X, S-video out is enabled, I start the game and it is in 1280x1024 window (even though settings are for fullscreen) then I turn --off S-video and it seems to go to start in fullscreen, but crashes the X server instantly
soreau: I am running at 1280x1024 on VGA-0
MrCooper: twnqx: xdpyinfo isn't relevant, it just means the X server could support DRI2
soreau: I would be willing to bisect if I knew for sure which component it was breaking it
dileX: twnqx: e17 runs fine here: with kms and dri2, currently w/ r300g (dri/st) (and I started also xorg/st on e17)
twnqx: for me it crashes after 2s, just when the top shelf fades away
twnqx: but good to know that it's not e17 causing this :P
twnqx: man git sucks
twnqx: i edited a file
twnqx: and now it says "omgno file is different, can't update"
twnqx: just overwrite it like svn does
twnqx: stupid software
MrCooper: no it doesn't
MrCooper: man git-stash
twnqx: i just want svn behavior
MrCooper: I want a pony
twnqx: actually i don't care about the changes
twnqx: i run git to get rid of them...
twnqx: can i just delete the file and git will restore it?
MrCooper: git reset --hard then
twnqx: so how do i get that in layman...
soreau: layman -S?
twnqx: that's where the "omgfilechanged" comes in
twnqx: layman -d; layman -a
twnqx: and somehow the zugaina overlay just disappeared :(
soreau: I you want to change files, you probably should consider building manually..
twnqx: nah, just use a sane repository system
twnqx: there's actually no need to have 20x the size for all old versions in the checkout :\
dileX: wtf - Searching Return to Castle Wolfenstein: Enemy Territory.... (scanning my whole hdd?)
twnqx: lol
soreau: dileX: Sounds like you got true combat elite...
soreau: It's looking for an enemy territory install
soreau: to install on top of
soreau: You don't want true elite, only enemy erritory
Ghworg: git is the swiss army knife of version control systems. Can do lots of stuff, but if you just want to cut something it can be overcomplicated
dileX: soreau: seems I cant test etf: Could not find Return to Castle Wolfenstein: Enemy Territory
dileX: soreau: and no its "etf_1.6-english-5.run"
soreau: dileX: Gah, I must have given you a link to *mods* for enemy territory, not enemy territory itself.
soreau: Very sorry
soreau: Let me see if I can dig up the actual game
Ghworg: ftp://ftp.idsoftware.com/idstuff/et/linux/ IIRC
soreau: dileX: Ghorg's link may also be correct http://www.filefront.com/thankyou.php?f=852003&k=8204f3c9c5df900112a8ecd1fafc241780fb0be84e698fd7c166146bcca036ff
soreau: Yes, Ghworg's link is better
dileX: Ghworg: hehe, wondered whats the "f" in etf (f*** u: I scan your hdd and the whole world knows now about your pr0n collections below $HOME/src)
soreau: lol
soreau: dileX: and you don't want the update, that's for servers and will cause problems
dileX: soreau: downloading from the URL Ghworg gave
soreau: dileX: Many apologies for the wrong link :P
dileX: n.p.
twnqx: hm i should just use udev-git...
dileX: that link is slow
soreau: that means it's a good link ;)
Nightwulf|work: hi all
dileX: seems to be faster and has et-2.60
soreau: dileX: All's you need is that .run binary, they should be all the same (as long as the size is consistent of course)
dileX: soreau: tried w/ r300g dri/st - start fails but no Xorg crash . test kms and dri2 later.
soreau: dileX: I wouldn't expect anything more out of r300g dri/st.. are there any games that run at all with that setup?
soreau: also, thanks for testing btw
dileX: soreau: hehe. I could start openarena w/ "r300g as softpipe" yesterday (but unplayable)
MrCooper: llvmpipe should be less unplayable :)
twnqx: so once i upgrade the kernel, will i have to rebuild the driver, too?
twnqx: or libdrm?
dileX: twnqx: see build-wiki in topic. yes, you need fitting libdrm, mesa (built against that libdrm) ddx and xorg-server >=1.6.2 (IIRC)
twnqx: those i have, all 1 day old
twnqx: just wondering if 2.6.31-drm-next => 2.6.32rc6 needs recompile
twnqx: X with KMS is still totally broken for the RV635, also with 2.6.32-rc6
mikkoc: twnqx: here too
twnqx: yey, i finally got something in the xorg log!
dileX: twnqx: 2.6.32-rc6 has not all patches from drm-next
twnqx: 2.6.31.y with now 5 days old drm-next patchset shows the same
twnqx: so is there anything newer i can try?
mikkoc: twnqx: u get a black screen with some other colors?
twnqx: no
dileX: there were 6 commits last night to drm-next
twnqx: entrance (login manager) comes up fine
mikkoc: ah, further than me then
twnqx: with 2.6.32-rc i get visual errors i didn't get with 2.6.31.y (random blocks)
twnqx: but a few seconds after login X just freezes
twnqx: http://pastebin.com/d4029c598 the bottom would likely be the most interesting
dileX: whats the status of entrance - working. last time I asked on #e they didnt recommend to use it.
twnqx: uh, i'm using it for years
twnqx: so how do i get a drm-next? pleast don't recommend a full git checkout, downloading 1GB will take about 1-2 days here
dileX: twnqx: its not one gig. its about 300-400M
twnqx: what about nightly tarballs, should be only 30MB :X
dileX: twnqx: if you want I provide a single patch for rc6
twnqx: that would be great, indeed
dileX: twnqx: incl. revert-drm-fixes + drm-next (2009-11-04).
twnqx: thank you
ferr: i have same issue with 2.6.32-rc6
mikkoc: dileX: how do u generate it?
ferr: X freezes if i try to run opengl application
dileX: mikkoc: from drm-2.6 and linux-2.6 GIT tree
mikkoc: you need a checkout of both?
dileX: for revert-drm-fixes (3 commits) you need linux-2.6. the idea is to have drm-next "completely" (I hate to comment out patches).
twnqx: ferr: i wouldn't be aware of opengl apps, but who knows what e17 does :P
dileX: drm-2.6/drm-next is a 2.6.31-branch
twnqx: hm i have lots of failures :X
twnqx: for the patch i mean
dileX: should be ignorable Hunks
twnqx: and some occasions of Reversed (or previously applied) patch detected! Assume -R? [n]
twnqx: 15 rejects
twnqx: patch unexpectedly ends in middle of line Oo
dileX: oops
twnqx: but it doesnt
twnqx: weird
dileX: twnqx: I will look - after kernel-upgrade
twnqx: guess if i'll git pull my 2.6.31.y it would get me the same new drm-next?
dileX: so I splitted the three patches
twnqx: git-pulls on top of his existing 2.6.31.y-drm-next
dileX: twnqx: the patches are against rc6 (only to clarify)
twnqx: yeah
twnqx: but i guess the drm-next will be the same for both, right?
twnqx: is off to boot
soreau: twnqx: Just make sure to use the git pull instructions in the wiki
soreau: If you use only git pull, it might mess it up
twnqx: wow
twnqx: OpenGL renderer string: Mesa DRI R600 (RV635 9591) 20090101 TCL DRI2
twnqx: and it lives to tell the tale!
honk: cheers =D
twnqx: hugs airlied
dileX: twnqx: what did you do with the patch? applies perfectly .
twnqx: didn't apply against my vanilla 2.6.32rc6
twnqx: 1800 glxgears now!
dileX: anyway
twnqx: my 285gtx rofls :(
scarabeus: meh i should really do some ebuild to actauly be able to grab only drm from next...
dileX: soreau: et works fine here w/ kms & dri2
soreau: dileX Which version of X?
dileX: soreau: 1.7.1
soreau: I wonder what my problem is here then
dileX: libdrm is 2.4.15 (not master GIT)
soreau: Ah really
dileX: mesa latest GIT master
soreau: I assumed youd be using all user side components from git
dileX: ddx is one commit behind
twnqx: ferr: apparently one of the very latest changes to the kernel i key to get it working :)
soreau: Ok, then I guess the only thing I can try is downgrading libdrm
dileX: soreau: or revert "radeon: fix allocation" (commit 6eafd1cf386d93bb9e34660227ca6f26aadfeb32)
dileX: hmm, I am 2 commits behind (ddx)
soreau: dileX: I am using gentoo -9999 builds so it will be easier to install 2.4.15 here
dileX: I try ddx first
soreau: ok, lets see here...
dileX: soreau: with new ddx et is also fine
soreau: I was thinking it would be easier for you to test that :P
soreau: dileX: Which card are you testing with?
dileX: rv515 (aka x1300 pci-e)
dileX: GL_RENDERER: Mesa DRI R300 (RV515 714A) 20090101 x86/MMX/SSE2 TCL DRI2
soreau: dileX: Hmm.. this is rv350 here
soreau: I guess I will try downgrading libdrm
soreau: It has to be one of these components
soreau: attempts to build libdrm-2.4.15; mesa and ddx from git against it
dileX: soreau: building libdrm with "radeon: fix allocation" patch
dileX: (rebuilding mesa)
soreau: damn you're quick
soreau: dileX: Is that libdrm master?
dileX: no, libdrm-2.4.15 with that patch only
dileX: (but I can do master GIT in a further step)
soreau: Well right now I am building mesa and ddx against libdrm-2.4.15 to see if that makes the difference
dileX: you can compile ddx separately
soreau: my cpu is certainly not as fast as yours :)
dileX: important is: changed libdrm -> always rebuild mesa against it
soreau: dileX: Not ddx?
dileX: no, ddx rebuild makes sense if xorg-server has changed especially input and video ABI
soreau: huh. I just assumed since you have to build it against libdrm with --exp-radeon-api to get kms support for ddx
dileX: soreau: with libdrm-single-patch et OK
soreau: dileX: Curious, which fullscreen resolution do you have it set to?
dileX: soreau: see paste :-)
dileX: (using games preferred resolution - no manual interaction)
soreau: Well it's sort of ambiguous.. I was wondering which resolution you were running at and what you had the game set to
dileX: here: native is 1280x800 (LVDS)
soreau: ok
soreau: dileX: No luck with downgrading libdrm, will try reverting mesa and ddx 5 commits each and see if I can't track something down
dileX: soreau: I am build mesa against libdrm-from-git
soreau: dileX: No telling though since we are testing different chips, but I appreciate your help in this
dileX: yeah, could be indeed the different hardware
dileX: no, its not for nothing here
soreau: looks around for EruditeHermit
dileX: I will jump to jbarnes dri2-swapbuffers stuff (mesa and xorg-server). will need upgrading dri2-proto.
soreau: He has a very similar chip to mine, rv370 iirc
dileX: (IIRC libdrm-from-git is required)
dileX: soreau: seems to be your hardware :-)
soreau: dileX: Well like I said, thanks for testing. Maybe I will get fortunate enough with someone else that has my hw and this particular game installed to test
dileX: soreau: I tested with et-2.60
soreau: Yea, that's pretty much all there is
soreau: Like I said, it used to work last week
soreau: I might have to look at the commits on cgit
dileX: soreau: what says 'X 2>X.stderr'?
soreau: dileX: I start X using a script, standalone without a DE or anything
soreau: and it has proved to be seemingly slightly more fragile
soreau: But I could pipe it to file if you want
dileX: I dunno if you have your stuff with debug-bits compiled. just look.
soreau: Pretty sure I build everything with -g
soreau: dileX: Will this be ok? /usr/bin/X :0 -br -audit 0 -nolisten tcp vt7 2>/tmp/X.stderr
dileX: not so complicated, you can try 'X 2>X.stderr' from ssh-session.
soreau: dileX: At what point?
soreau: To start X or what
dileX: yupp, from init-3
soreau: Because that will start X and pipe the stderr output to X.stderr, right?
soreau: no need to do it from ssh me thinks
soreau: dileX: Interesting or not? http://pastebin.com/m7e1a755d
dileX: you could start from local machine. but if machine gets in a corrupt state, sometimes you can save/debug etc. from ssh
soreau: I don't even know what the record extension is supposed to do TBH :P
kdegel: good morning
dileX: soreau: (==) Using config file: "/etc/X11/xorg.conf" <- whats in there?
dileX: soreau: anyway, I have to go, now
soreau: dileX: It seems to have something to do with S-video being plugged, because I can start it at fullscreen with 800x600 while s-video is enabled, but I disable it then it only shows in the upper 800x600 part of the 1280x1024 screen
soreau: If S-video is enabled and I set the game to 1280x1024, it will go 1280x1024 in a window. but when I disabled S-video out and try to start it at that mode, that's when it segfaults X
twnqx: so mplayer -vo gl still stutters
twnqx: :(
soreau: use xv
twnqx: yupp, that works
mikkoc: agd5f: i tried to apply your patch http://bugs.freedesktop.org/attachment.cgi?id=30983 to drm-next but Hunk #1 FAILED at 409.
mikkoc: can i ignore it?
agd5f: mikkoc: I guess I need to rebase my tree
agd5f: don't leave out any parts
mikkoc: agd5f: full output: http://pastebin.ca/1658456
agd5f: mikkoc: you may have to hand patch r600.c until I rebase it
mikkoc: what should i change?
twnqx: so ummm
twnqx: now that KMS is working, next stop
twnqx: i never got powermanagement to work
agd5f: twnqx: there is no power management support with kms yet
twnqx: *sigh*
twnqx: and without, it's also not enabled by default?
agd5f: twnqx: yes
agd5f: mikkoc: just looks up the parts in the patch and hand patch it
agd5f: or wait for me to rebase
mikkoc: the problem is that there's no such line
mikkoc: - if (rdev->family == CHIP_RS780 || rdev->family == CHIP_RS880) {
mikkoc: + if (rdev->flags & RADEON_IS_IGP) {
agd5f: mikkoc: hold on
mikkoc: yep
agd5f: mikkoc: yeah, that part was removed. should be finx
agd5f: fine
mikkoc: ok cool
mikkoc: brb, reboot
mikkoc: agd5f: it works!
mikkoc: thanks
agd5f: mikkoc: cool
mikkoc: corruption and slowness are all over kde but yea it finally works :P
mikkoc: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
mikkoc: Try adjusting the vblank_mode configuration parameter.
mikkoc: should that happen? ^
Luzipher: does happen for me, too, mikkoc
mikkoc: ok
kdekorte: mikkoc, that is correct at this time, IRQ support should be coming "soon"
Luzipher: btw ... do i have to do anything to get DRI2 or do i get that automagically with KMS ?
kdekorte: Luzipher, if you have KMS you have DRI2
Luzipher: ok, thanks kdekorte
kdekorte: you can check it with glxinfo | grep render
kdekorte: should say DRI2 after TCL
kdekorte: OpenGL renderer string: Mesa DRI R600 (RV635 9598) 20090101 TCL DRI2
Luzipher: will do that later :) I'm on non-kms at the moment, as kms seems to have strange slowdowns
Luzipher: and thanks again ;)
kdekorte: Luzipher, KMS is a tad slower in some cases, but for me it is faster in 3d for the most part. It seems quite dependent on what kernel you have
kdekorte: In Fedora rawhide I've seen 3d frame rates double with a kernel upgrade
Luzipher: 3d seems a little faster in glxgears, but i have a lot of Firefox tabs open and the whole system is a lot more sluggish than without kms (and so are the 3d apps)
Luzipher: I'll relog into kms and check for dri2 ... :)
Luzipher: yup, it says DRI2 :) (Mesa DRI R600 (RV770 9440) 20090101 TCL DRI2)
Luzipher: hmm, and it runs a lot better since upgrading mesa/ddx/libdrm
reinoud2: Hi
reinoud2: WTF is going on here:
reinoud2: > glxinfo
reinoud2: name of display: :0.0
reinoud2: libGL: XF86DRIGetClientDriverName: 4.3.0 r300 (screen 0)
reinoud2: libGL: OpenDriver: trying /usr/X11R7/lib/modules/dri/r300_dri.so
reinoud2: drmOpenDevice: node name is /dev/dri/card0
reinoud2: drmOpenDevice: open result is 4, (OK)
reinoud2: drmOpenByBusid: Searching for BusID pci:0002:02:00.0
reinoud2: drmOpenDevice: node name is /dev/dri/card0
reinoud2: drmOpenDevice: open result is 4, (OK)
reinoud2: drmOpenByBusid: drmOpenMinor returns 4
reinoud2: drmOpenByBusid: drmGetBusid reports pci:0002:02:00.0
reinoud2: unknown chip id 0x9440, can't guess.
reinoud2: libGL error: Calling driver entry point failedlibGL error: reverting to software direct rendering
reinoud2: libGL: OpenDriver: trying /usr/X11R7/lib/modules/dri/swrast_dri.so
adamk_: reinoud2, Come on.
reinoud2: libGL error: dlopen /usr/X11R7/lib/modules/dri/swrast_dri.so failed (/usr/X11R7/lib/modules/dri/swrast_dri.so: Undefined PLT symbol "_glapi_check_multithread" (symnum = 113))
reinoud2: (sorry for the big paste)
adamk_: reinoud2, Use a pastebin service next time.
reinoud2: sorry, i forgot :(
kdekorte: reinoud2, probably need to upgrade a bunch of things... BTW what card do you have?
reinoud2: Sapphire Radeon HD 4870 Vapor-X 1024 Mb
reinoud2: info: [drm] Loading RV770/RV790 Microcode
agd5f: reinoud2: you need a newer ddx
agd5f: xf86-video-ati
agd5f: 6.12.3/4 or git master
reinoud2: tnx :)
ky0j1n: Hello there! I have an issue. With KMS Direct rendering doesn't work on RV630, without it does. Is it normal at current state of drivers?
ky0j1n: I'm using Fedora 12 rawhide
adamk_: It should work.
adamk_: My guess would be that you are using using a KMS enabled DDX.
adamk_: s/are/aren't/
ky0j1n: i have only software rasterization
adamk_: Can you pastebin your /var/log/Xorg.0.log file from when you used KMS?
agd5f: ky0j1n: or you need version of mesa built with kms support
ky0j1n: i'll take a look
twnqx: ky0j1n: try today's checkout, first ones that work for me on a 635
adamk_: Yeah, that might be, too.
ky0j1n: hm so in future there might be mesa release with KMS support?
mattst88: yeah
chithead: mesa 7.6 already has kms, doesn't it?
ky0j1n: also xrandr doesn't work properly with KMS
chithead: only r6xx 3d is missing from that release still
Luzipher: ky0j1n: what do you mean by "not properly" ? Under KMS the devices are numbered differently, maybe that's the problem ?
spreeuw: and dri1 seems broken for rv620 atm
spreeuw: atleast for my combination
spreeuw: so it sounds like you're trapped atm
spreeuw: atleast with current
agd5f: spreeuw: what's broken?
spreeuw: glxgears crash at launch, no gamma control in ioquake3
agd5f: spreeuw: have you updated since yesterday? gears should be working
spreeuw: but I need to ground in some stable reference versions again
spreeuw: oh
spreeuw: agd5f: hey indeed it works again
kdekorte: ky0j1n, I'm using KMS on an rv635 with rawhide and it works ok... did you install the mesa-experimental-drivers package?
ky0j1n: kdekorte yes
kdekorte: I'm using everything from rawhide except mesa... I build that myself cause the one in rawhide is old
ky0j1n: kdekorte mesa is the problem i think, i will w8 for stable release with KMS
kdekorte: mesa doesn't care about KMS... all that matters to is is libdrm
ky0j1n: read the post agd5f above
kdekorte: ky0j1n, what kernel are you using in rawhide?
reinoud2: ah, its only in git/cvs
dileX: cvs?
reinoud2: you know, cvs ;) but i guess xorg/xfree is no longer in cvs but in git
dileX: xorg and git (xfree86 and cvs was yesterday)
dileX: (but some projects use still cvs)
reinoud2: *BSD still use that....
dileX: I have seen some cvs-server in fedora-project
[Enrico]: mhm what's the status of r200 kms used with mesa 7.6 and xorg-server 1.7.1 ?
[Enrico]: if i use kms i get strange color in glxgears and if i disable kms i get some screen corruption (with composite enabled)
[Enrico]: composite enabled in both cases*
[Enrico]: i'm using archlinux system updated few hours ago
[Enrico]: [strange colors in glxgears appears even with composite disabled]
scott_ino2: hello all, how is 3D coming along for r6xx/r7xx? Well I hope
scott_ino2: Is the guide on x.org still the best set of instructions to enable this?
agd5f: scott_ino2: see topic
scott_ino2: agd5f, sorry and thanks ;)
phealy: Hello all - I've been trying to find a good answer for this, but have yet been unable to do so. Is there support for running two separate cards to drive 3 displays available currently? one is an x3450, the other an ancient mach64 I had laying around.
Luzipher: I'd be interested in an answer to phealy's question as well ;)
chithead: only with vga arbiter. and additionally you will face the problem to get working drm for the mach64 card
Luzipher: chithead: do you know should vga arbiter
Luzipher: err, sorry ... do you know if vga arbiter works out of the box ?
Luzipher: or does it need some setup (xorg.conf maybe ?)
chithead: vga arbiter is included in drm-next and kernel 2.6.32-rc1. regarding mach64 drm, I think it died with drm.git, but maybe airlied can clarify
DanaG: x3450? you mean hd3450? =þ
phealy: yeah, hd3450, sorry.
DanaG: was reading x3nnnn as Intel graphics... =þ
phealy: old card was an x1300, just got the new box ;)
DanaG: hmm, do you have two PCIe slots? Old one AGP, or PCIe?
Luzipher: well, i do have vga arbiter compiled in my kernel, but so far there is no change in xrandr
phealy: I thought I used to be able to do this with xinerama... is that completely gone?
DanaG: You may be able to stick the 1300 in a secondary PCIe slot -- perhaps after "filing away" part of the plastic on a smaller PCIe slot to make it open-ended.
DanaG: Yeah, it's a gratuitous hack, but it'll beat the mach64.
phealy: Unfortunately, this is a work PC, so there's two caveats: the x1300 went with the old system - I don't have it anymore and 2) it's a small form factor box, with exactly one pcie x16 and one PCI slot.
phealy: and the cards have to be low profile - hence why I'm limited on selection ;)
DanaG: awww.
DanaG: wonders about EyeFinity and low profile.
phealy: Is xinerama-type support not available anymore?
phealy: If it involves spending money, I'm stuck with two displays ;)
chithead: low profile pcie cards with 4 outputs exist, but they are not exactly cheap
phealy: also, to make it more fun - two primary monitors are DVI - 3rd monitor is a spare and is vga only.
DanaG: hmm, what about FireMV?
DanaG: Would be R500 type or older.
DanaG: http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&Description=firemv&bop=And&ActiveSearchResult=True&Order=PRICE
DanaG: wow, yeah, expensive.
phealy: that found nothing for me.
phealy: and clicking go fixes it
DanaG: http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=2%2050001126%2040000449%201573838207&name=PCI&SpeTabStoreType=1
DanaG: e
DanaG: er
phealy: so there's not a way to do it with what I already have?
DanaG: hmm, beats me on the mach64... probably just won't be able to do much with it.
DanaG: Something to try: boot with ONLY the mach64... see what it offers.
Luzipher: hmm, i'm unable to find any nice docs about actually _using_ VGA Arbitration ... the wiki-page on x.org is from 2008 ... does anybody know of any more recent docs ?
phealy: What do you mean? I can get the mach64 started under X using a different serverlayout - it'll run 1280x1024 at 24 bit, which is all I need.
phealy: I just can't get the two to cooperate ;)
DanaG: ah.
DanaG: I wonder if you could even get two modern cards to cooperate.
DanaG: Now, on PCI, which is better: HD2600, or HD3450? =þ
chithead: using x server 1.7? earlier versions don't have vga arbiter support
chithead: DanaG: get a 4350 if you can
chithead: 2600 and 3450 are yesterday's technology
phealy: may just end up going with xp64 until windows 7 is allowed here :-P
phealy: this area is a major PITA with linux.
phealy: as much as I'd rather have it.
Luzipher: chithead: yep, kernel 2.6.32-rc6 and xorg-server 1.7.1, libpciaccess is also most recent
DanaG: er
DanaG: the newegg was 4350.
DanaG: http://www.newegg.com/Product/Product.aspx?Item=N82E16814161283
chithead: yikes, that is expensive
DanaG: 2400: http://www.newegg.com/Product/Product.aspx?Item=N82E16814102846
DanaG: also wonders: can mach64 do xv?
DanaG: ... or plain metacity composite?
phealy: I don't know, actually - I'm just going to run simple apps there, so it doesn't need 3d accel or video ;)
phealy: I also don't run a compositing wm - I turn that off
DanaG: wonders: what does xorg log show when booting with both cards?
agd5f: mach64 had an overlay, so it can do Xv
phealy: the log shows it hanging half way through startup - no crash notification or anything.
phealy: bbiab :)
DanaG: hmm, can you ssh in and strace it? or gdb it?
DanaG: Or use serial console. =þ
glisse: airlied: you did have a patch to look at vram fragmentation right ?
airlied: glisse: its in kernel
glisse: oh it's a debugfs file ?
airlied: mount debugfs /sys/kernel/debug/dri/0/radeon_vram_mm
[Enrico]: can i ask what's the status of kms for r200 based cards?
glisse: nice, the big virtual bug might be related to fragmentation will look into that tomorrow
Zajec: glisse: again, can you comment on ring info bug fix? would be nice to have your opinion as it's your code http://bugs.freedesktop.org/show_bug.cgi?id=24837
glisse: zzzZZZzzz
[Enrico]: couse i'm trying kms on archlinux with mesa 7.6 and xorg-server 1.7.1 and video-ati from git
[Enrico]: and i have strange colors in glxgears
glisse: Zajec: sorry i forgot about that
Zajec: glisse: :)
[Enrico]: and without kms i have some screen corruptions
glisse: Zajec: dont remove the register reading
glisse: best is to had what is the gpu thinking of the ring and what is the driver thinking of the ring
Zajec: glisse: what about printing both: registers and local copies?
glisse: to add
glisse: yeah that's what i just said :)
Zajec: glisse: starte writing before reading ;)
glisse: otherwise it looks good
glisse: post a new one an ping me, i will look at it first thing in the morning tomorrow
Zajec: glisse: ok, thanks a lot :)
agd5f: [Enrico]: should work. worked last time I tried
[Enrico]: agd5f: mhm strange
[Enrico]: agd5f: well for what can i say with kms i have no screen corruption at all
agd5f: [Enrico]: AGP?
[Enrico]: agd5f: but glxgears report strange colors
[Enrico]: agd5f: yeah agp :'(
[Enrico]: radeon 9250
[Enrico]: i know AGP is a mess
agd5f: [Enrico]: there are some fixes for that on the mailing list and drm-next. you can also try pci mode
[Enrico]: agd5f: pci mode.... so i have to set something in xorg.conf i guess
agd5f: [Enrico]: radeon kernel option modprobe radeon apgmode=-1
[Enrico]: agd5f: oh with a kernel option, let me try
[Enrico]: agd5f: can i put it also in the kernel line in menu.lst ?
agd5f: [Enrico]: yeah, or in your modprobe options
[Enrico]: agd5f: ok let's try with the kernel command line (couse i have to change it anyway to switch to kms :D )
[Enrico]: agd5f: ok i'm rebooting, kms is working let's wait for xorg
agd5f: [Enrico]: on the kernel command like you'll need radeon.agpmode=-1
[Enrico]: indeed :D
[Enrico]: ok i'm logging in kde
[Enrico]: screen corruption are not present
[Enrico]: agd5f: you did it! glxgears has the normal colors now :D
[Enrico]: the cpu is at 55% but ok
[Enrico]: i guess i need to wait a bit for more optimization :D
[Enrico]: but this is less important for that pc eheh
agd5f: [Enrico]: you might try other agpmode like 1 or 2 or 4
kdekorte: agd5f, it is almost to the point where agp should be disabled by default and have people enable it
[Enrico]: agd5f: thank you very very much!
agd5f: kdekorte: it's getting better
[Enrico]: agd5f: mhm..... i set 4 in xorg.conf so i think i should try setting 4 also in the kernel command line, let's try
Zajec: @all how would you call "rdev->cp.wptr" ? "local value of wptr"? "local copy of wptr"? "driver's value of wptr"?
kdekorte: can't wait to try it on my Athlon 64 with the VIA K8T800 AGP Host bridge
agd5f: [Enrico]: with kms the agpmode in the xorg.conf isn't used
agd5f: Zajec: driver's copy of the CP write pointer
[Enrico]: agd5f: ok i see thanks :D
[Enrico]: agd5f: now i'm trying with radeon.agpmode=4
kdekorte: [Enrico], what goes 'lspci | grep AGP' give you on that machine
Zajec: agd5f: :)
[Enrico]: kdekorte: Intel Corporation 82850 850
kdekorte: [Enrico], thanks
[Enrico]: agd5f: lol now cpu usage is 70% :D
[Enrico]: kdekorte: np :D
agd5f: [Enrico]: gears is cpu bound
[Enrico]: yeah i know
[Enrico]: mhm i worder which one is better
kdekorte: [Enrico], is the fps higher even though the cpu is being used more
[Enrico]: well i'l test with something like nexuiz
[Enrico]: kdekorte: mhm i didn't read the FPS
kdekorte: higher cpu might mean that it is waiting less on the data to be moved
[Enrico]: but now it is 392
[Enrico]: kdekorte: that's true
[Enrico]: i will leave it with agpmode 4
[Enrico]: agd5f: last question, where i have to put the modprobe conf instead of the kernel command line ?
[Enrico]: s/command//
kdekorte: I have a 9200 in my Athlon
agd5f: /etc/modprobe.d/options or something like that. depends on the distro
[Enrico]: agd5f: oh ok then i know where, thank you very much again :D
agd5f: [Enrico]: np
[Enrico]: agd5f: ehm really the last question. in modprobe.d/modprobe.conf (used in archlinux) i have to put "option radeon agpmode=4" without quotes right ?
agd5f: [Enrico]: maybe... not sure on the syntax off hand
[Enrico]: rofl
[Enrico]: ok let's try
mzz: [Enrico]: are you sure that file is available early enough? You might have to do this on the kernel commandline (via grub) instead, depending on how things are configured
[Enrico]: agd5f: ok options radeon agpmode=4 worked!
mzz: ah, ok
[Enrico]: mzz: i configured the system to include the radeon module in the initrd
mzz: [Enrico]: I wasn't sure if you'd made radeon a builtin, or if that file was automatically copied into the initrd
[Enrico]: mzz: the kernel is the distribution one, not done by me :D
[Enrico]: mzz: i build the kernel only for my gentoo :D
[Enrico]: wow 2d perfomance are boosted to the crazy!!!
[Enrico]: now flash works flawlessy!!! amazing
[Enrico]: now loves KMS
[Enrico]: i'm starting thining trying it on my r600 (since i use gentoo on this pc i can compile the git packages easly :D )
[Enrico]: ok cpu il at 95% but still i can whatch youtube videos now!
twnqx: radeonTexSubImage2D still crashes :X
legume: soreau: I can crash et/x as well, there are workarounds - http://pastebin.com/m7e1a755d I will try the patch later.
legume: soreau: Oops wrong link in clip - http://bugs.freedesktop.org/show_bug.cgi?id=24532
soreau: legume: Cool
Ronis_BR: does anyone use radeon 3D accel with a R700?
stikonas: yes, many people do
Luzipher: yep, Ronis_BR
Ronis_BR: Luzipher: is it usable now?
Ronis_BR: I'm tired of fglrx
Ronis_BR: what do I need?
Luzipher: Ronis_BR: depends ... Quake Live is playable for example ... most wine stuff doesn't work well or at all
stikonas: kernel 2.6.32, and mesa 7.7 snapshot
Ronis_BR: I just need kde effects
Ronis_BR: I doesn't use anything more
Luzipher: Ronis_BR: best take a look at http://wiki.x.org/wiki/RadeonProgram for an idea
stikonas: kde can have some effects even without 3d accel
Ronis_BR: stikonas: but it is veeeeeeeeery bad :
Ronis_BR: :D
stikonas: you can use XRender backend for 2D effects
Luzipher: Ronis_BR: i actually have some artifacts in 2D on KMS/r700, but it's not so bad
stikonas: with latest git versions, KDE effects are usable, but there is some artifacts
stikonas: some grey arreas in task manager...
Ronis_BR: hum
Ronis_BR: so I think I'll wait... :(
Luzipher: Ronis_BR: but that's with KMS, with xorg-server 1.6 and no KMS I didn't have any problems last time i checked :)
stikonas: no KMS is so last year... :)
Ronis_BR: Luzipher: KMS?
Ronis_BR: never heard about
Luzipher: last week you mean ;) couldn't use kms since a few days ago
Ronis_BR: ah
Ronis_BR: I'm using uvesafb
Ronis_BR: and xorg 1.7
Ronis_BR: ops
Ronis_BR: 1.6
Luzipher: Ronis_BR: KMS = Kernel Mode Switching ... it's the big hype everywhere: Mode Switching is done in the kernel and you get a flickerless boot and stuff
Ronis_BR: Luzipher: hum
Luzipher: Ronis_BR: fast console switching ... DRI2 ...
Ronis_BR: Luzipher: without kms radeon 3D is ok for kde compositing?
Luzipher: Ronis_BR: essentially, memory management is done in kernel with kms, that's the only big change
Luzipher: Ronis_BR: well, last time i checked, yes
Luzipher: Ronis_BR: but as git moves daily ... i can't promise
Ronis_BR: :)
Ronis_BR: are anyone else using radeon + 3d accel with kde?
Luzipher: Ronis_BR: which distro do you use ?
Ronis_BR: gentoo
Luzipher: well, on gentoo it's not too hard to try that stuff ... you just need a recent kernel and mesa-9999 (maybe from x11 overlay) afaik
twnqx: not the *only* big change
twnqx: it's supposed to not corrupt your console e.g. if X crashes (lol)
Luzipher: and you should be able to switch easily (eselect opengl and changing the driver in xorg.conf)
Luzipher: twnqx: wow, didn't know about that great feature ! :) (last time i switched to the console it didn't let me switch back to x ;) )
twnqx: btw, i'd recommend for rv635
Ronis_BR: Luzipher: just it?
twnqx: all earlier ones crashed :P
Ronis_BR: Luzipher: and the driver itself?
Luzipher: Ronis_BR: AFAIK the current release (xf86-video-ati) should be enough
twnqx: libdrm-9999
Ronis_BR: Luzipher: for xorg 1.6.5?
twnqx: no, 1.7.1
Ronis_BR: I don't use 1.7.1 instead
twnqx: you should
Luzipher: Ronis_BR: hm, i think ... 1.6.5 should work ... but I'm not sure about libdrm, maybe you really need libdrm-9999
Ronis_BR: that will be a problem
Luzipher: twnqx: 1.7 introduced artifacts for me where 1.6 was ok
Luzipher: (of course i stay on 1.7.1 ... downgrading is for waeklings ! :D )
Ronis_BR: Luzipher: ehehhe
Luzipher: nah, actually i wanted to try vga arbitration, you need 1.7 for that ... but i don't know how to actually try that ;)
Luzipher: hmm, does anyone know the state of HDMI (via DVI and no audio, just graphics) on r700 ?
yangman: Luzipher: HDMI without audio and extra bits is essentially DVI. it's worked on r7xx for a long time
Luzipher: and does anyone else have random failures when compiling mesa from git ? (get those for a few days now - second or third try usually is successful ...)
Luzipher: yangman: ok, thanks
chithead: don't forget to make clean after pulling from git
chithead: or if you use gentoo, make sure libdrm and mesa were checked out at the same time
Luzipher: chithead: I am on gentoo and ... well, let me check which gets pulled first, mesa or libdrm ...
Luzipher: chithead: i always pull libdrm first and immediatly after that mesa
chithead: "qlop -lu libdrm mesa" will tell
Luzipher: ah, interesting command :)
Luzipher: To update all -9999 packages, i use: emerge -a1 `eix -Jc | grep 9999 | cut -d" " -f2 | tr "\n" " "`
Luzipher: still, mesa fails randomly and then compiles fine after a few tries ... without changing libdrm or any commits in between ... just after "ar: creating libr300compiler.a" with "gmake[4]: *** [subdirs] Error 1"
chithead: maybe parallel build issue
Luzipher: ahh ... found something farther up: gmake[5]: *** No rule to make target `compiler/libr300compiler.a', needed by `r300_dri.so'. Stop.
Luzipher: yep, looks like a parallel build issue then
Luzipher: hm, should i report that somewhere ?
chithead: bugs.freedesktop.org
Luzipher: hm, ok, I'll have a look if there is something reported already
moeSizlak: http://answers.yahoo.com/question/index?qid=20090922014626AAqNCZa
agd5f: Luzipher: I don't think mesa supports parallel build
Luzipher: agd5f: hmm ... well, that parallel building stuff was more or less a guess ...
Luzipher: agd5f: at least there are multiple jobs running in parallel ... why else should it wait for jobs to finish ?
Luzipher: agd5f: btw, if you want to look at the build-log, check https://bugs.freedesktop.org/show_bug.cgi?id=24950