spstarr: firmware?
spstarr: airlied: was I missing some firmware(?)
dileX: glisse: thank you for "radeon/kms: add simple DownloadFromScreen implementation"
dileX: for better comparison (w/o dfs)
DanaG: that IS interesting. Anyway, I tested what I wanted to test; now I'm back to fglrx, for now.
DanaG: But the fact that it runs... is yet another step on the way.
DanaG: I get the "slow", but it's odd that "cube" crashes Xorg.
spstarr: DanaG: which firmware is airlied speaking of?
DanaG: Hmm, I missed any mention of firmware.
DanaG: (09:55:00 PM) DanaG: Though trying to rotate my cube crashes Xorg, even with no glxgears.
DanaG: that was the last thing I saw. Then I did it again, and crashed it again. =þ
agd5f: dileX, glisse: untested kms uts implementation: http://www.botchco.com/alex/xorg/radeon_kms_uts.diff
spstarr: agd5f: what firmware is this?
spstarr: Fedora I thought provided this (it shows that it loaded it)
agd5f: spstarr: firmware?
dileX: agd5f: good morning, is this on top of latest DDX-from-git?
agd5f: dileX: yeah
spstarr: EXA and Xv accel for r600/r700 - no 3D - for OMG free distros, make sure you have firmware installed before speaking". <----
agd5f: spstarr: the CP microcode. debian ships it in a separate package
spstarr: ah
spstarr: yeah i have this then
EruditeHermit: agd5f: does this require any new kernel components?
agd5f: EruditeHermit: that is 'this'?
agd5f: what is 'this'?
EruditeHermit: uts
agd5f: EruditeHermit: no
Nightwulf|work: hi all
dileX_: agd5f: e17 looked strange - stripes. kde-4.3 froze while loading. (looking into Xorg.log)
EruditeHermit: agd5f: massive text corruption
agd5f: dileX_: may be typos, it's untested
EruditeHermit: let me get you a screenshot
EruditeHermit: well
EruditeHermit: do you want one?
dileX_: agd5f: info->accel_state->exa->UploadToScreen = RADEONUploadToScreenCS;
dileX_: missing *&*RADEONUploadToScreenCS
EruditeHermit: brb unreadable now
EruditeHermit: agd5f: http://imagebin.org/58415
EruditeHermit: http://xkcd.com/619/
EruditeHermit: Sarvatt: hi
glisse: 32bits kernel gives way better profile, things makes sense now :)
MrCooper: bummer, hopefully the performance counters in 2.6.31 will work better
glisse: MrCooper: what gives percount ? never looked at that
MrCooper: glisse: everything I know about it I learned on LWN, seems quite interesting
glisse: i should read lwn more often :)
airlied: it just needs a nice gui ;-)
MrCooper: tell me about it, I'm lagging about a month on weekly editions :}
airlied: glisse: so does sysprof tell you CS slower?
MrCooper: airlied: I wonder if sysprof could use it in the future
airlied: I think the sysprof gui could be ported alright
airlied: there was an attempt at in-kernel sysprof over ftrace which failed miserably
glisse: right now 30% is buffer create from which 11% is setwc and 12% is debug_dma_map_page
glisse: and cs ioctl is 15%
glisse: all this for q3 demo1
glisse: setwc is on PCIE computer :)
airlied: you using page allocator?
glisse: airlied: so i think you should push my patch which set all MASKING for GTT domain rather than only setting WC or uncached :)
glisse: not using the allocator here
airlied: glisse: where is that?
glisse: so buffer create should be 9% without debugging and wc
glisse: it's in mm tree
glisse: don't know how it ended up there
glisse: :)
glisse: it's 1 line patch
airlied: akpm hoovers p lkml
airlied: ah I'll push that to Linus tomorrow morning
airlied: btw you'll want to pull the r600 patch out of rawhide kernel
airlied: I had to rebase it
glisse: will redo more benchmark with this 32bits thingy which gives nice call chains :)
glisse: i should setup a fedora mirror i am wasting so much time dl packages on all boxes...
airlied: hehe.. I always think about doing that then don't bother ;-)
airlied: though I do have most of my boxes on the office network
airlied: which has a mirror
glisse: yeah, i first need to find a box which can do the mirror
glisse: ie somethings that i don;t mess with... this the hardest part ;)
MrCooper: a caching HTTP proxy might be more efficient
glisse: MrCooper: there is somethings like that in fedora, at least i read somethings on the wiki about a mirror who mirror only packet which are asked
glisse: so you don't dl the whole stuff
glisse: i am missing my university connectivity where downloading was faster than my harddrive
EruditeHermit: suokko: hey
suokko: hey
suokko: glisse: btw, I just remembered that some 64bit systems are using 2-way stack which might confuse oprofile
glisse: yeah oprofile or sysprof are definitly confuse on 64bits
suokko: What could cause hang where I can't ssh or give normal input localy but sysrq magic works for reboot?
suokko: If anyone has any ideas it would help debugging that hang :)
ferret_: extreme memory usage by a root process
glisse: suokko: kms enabled ?
suokko: yes
suokko: Without kms there is no hang
glisse: which card what apps cause that ?
MrCooper: spinlock deadlock maybe? Not sure Magic Sysrq would work in that case
suokko: rv280 and xdemos/manywin 2
suokko: (I have one patch that affects manywin demo in my tree)
suokko: btw, First time that hang happened I was able to see the achine with nmap but not able to login using ssh
suokko: 2nd time I had ssh connection but that connection did freeze and nmap didn't see open ports at all
suokko: And nothing in dmesg
suokko: Maybe I shoudl try to cause that hang with drm.debug enabled
suokko: I think that r200 clear is buggy too
suokko: In fact all rendering is buggy that it randomly draws only to upper part of window
suokko: But if window is small enough there seems to be no problems
suokko: small=height less than 50px
suokko: width doesn't seem to affect the problem
MrCooper: suokko: I think there's a bug report about that
suokko: I'm just looking at what could cause it
suokko: I guess there is some hw state set badly because swclear works correctly
suokko: What should be in rmesa->radeon.sarea->boxes?
MrCooper: nothing that affects DRI2
MrCooper: DRI1 communicates cliprects to the DRM via the SAREA
suokko: MrCooper: What if dri2 would try to use that?
MrCooper: that would probably be a bug
glisse: suokko: we don't to use that we want to kill that, rm -fR and then takes a big amount of pills that helps us forget about that ;)
dileX: glisse: red or blue pill (film "matrix")?
glisse: the one where i follow the rabbit
dileX: wrong, it was the blue pill "...and the blue pill simply for life to carry on as before." ... "The red pill will answer the question "what is the Matrix?"
steffen_: hi there
steffen_: are there some new about xf86-video-ati and kms? i get the error: "radeon.o kernel module version is 2.0.0 but version 1.17.0 or newer is needed"
MrCooper: steffen_: your X driver lacks KMS support
steffen_: it appears even with xf86-video-ati from the kms-support branch
steffen_: i will give it one more try
MrCooper: steffen_: that branch is obsolete, just use master
suokko: steffen_: you should use master and build libdrm with --enable-radeon-expreimental-api
steffen_: libdrm is already built
MrCooper: the option is critical, and that xf86-video-ati finds libdrm_radeon.pc
steffen_: MrCooper, if has found the libdrm_radeon.pc
steffen_: i'm building right now
steffen_: since when was kms_support merged into master?
MrCooper: a while ago
MNZ: do the radeon drivers from git support the latest kernel or the latest stable kernel or what exactly?
nanonyme: reminds himself to teach himself the difference between a git subject and a description
nanonyme: MnZ: Both?
nanonyme: You just get different capabilities of the driver depending on the kernel version.
suokko: Let see how much ccache speeds up bisecting :)
nanonyme: suokko: Assumably a lot. :)
steffen_: MrCooper, do i need a git version of mesa or is ubuntu's mesa 7.5. recent enough?
steffen_: i get the following in the Xorg.0.log
steffen_: (EE) AIGLX error: Calling driver entry point failed
steffen_: (EE) AIGLX: reverting to software rendering
suokko1: steffen_: You need mesa 7.6. That is available from xorg-edgers ppa with new libdrm that is required for it
steffen_: suokko1, thanks for the information, but there are many repo's there. the packages in radeon-kms are way old. could you tell me where i can find the new mesa and the new needed libdrm?
suokko1: They are in base repo now because of all relevant code (except r600+) has been merged to master
steffen_: is this the base repo: http://ppa.launchpad.net/xorg-edgers/ubuntu ?
suokko1: https://launchpad.net/~xorg-edgers/+archive/ppa
suokko1: That is the web interface
steffen_: whole x will be updated
MNZ: agd5f, hi, I'm trying to compile your drm code from the r6xx-r7xx-3d branch. What kernel is this written against? I can't get it to compile with 2.6.30
nanonyme: 2.6.30.1, actually.
nanonyme: MNZ: What's the problem?
phercek: MNZ: I could compile it against 2.6.30.4-ARCH with this patch added: http://www.hck.sk/users/peter/pub/paste/init_mm_not_in_2.6.30.patch
phercek: the reason for the patch needed is probably arch backport, but I did not check exactly; the error I had was cannot find symbol init_mm
glisse: MNZ: you need 2.6.28 iirc
nanonyme: agd5f: Hmm, appears that 32bit CONFIG_HIGHMEM issue is with 2.6.30 too. Apparently needs that patch from phercek as well.
nanonyme: That's an annoying bug since it doesn't appear on 64bit systems at all.
MNZ: here's the error I'm getting http://pastebin.com/m6f6ff53f
nanonyme: Oh.
steffen_: yes, it works. thats very cool ;)
nanonyme: That looks separate.
steffen_: but one thing, my second monitor is off. it's detected bei the radeon drv but is blank
phercek: MNZ: that is something different than what I had
nanonyme: That sounds familiar to me, just don't remember where I've seen it.
nanonyme: MNZ: Are you sure you've the newest commits?
MNZ: the newest drm commits yes. but kernel no
nanonyme: That's strange.
nanonyme: Double-check.
nanonyme: It looks fine to me.
MNZ: I'm pretty sure because I just git-clone-d them today
MNZ: I mean right now
nanonyme: A 2.6.28 fix fixed the issue you pastebinned so your DRM must be pretty old.
MNZ: maybe I've got the wrong tree...
MNZ: the 3d code is on master or on a different branch? I was following a guide that is probably written for 2.6.28
MNZ: I'm on the r6xx-r7xx-3d
MNZ: git branch
nanonyme: The DRM code is in agd5f's tree, r6xx-r7xx-3d branch.
MNZ: yes that's the one
nanonyme: I can't see how it could fail with recent git except if your kernel sources claim they're 2.6.27.
nanonyme: And they're actually 2.6.28+.
yokto: can someone point me to a documentation that explains how rendering works on different interfaces (opengl,xv,x11,...)? sort of "the way from the application to the monitor". I mean i've heard a lot about (drm,dri,kms,mesa,gallium) but it's really put it all together.
MNZ: hmmm. I DO have 2.6.27. But at the start of the build I see make entering the 2.6.30 header tree
MNZ: but wait, the /usr/src/linux link points to 2.6.27 :S can that be it?
nanonyme: MNZ: That struct is never called if check for 2.6.28 succeeds.
nanonyme: drm_compat.h lines 59-63.
MNZ: ah
MNZ: nanonyme, thanks for that little pointer. I remove the /usr/src/linux link and it built just fine
nanonyme: Nice.
MNZ: but that's weird because I'm pretty sure it was using the 2.6.30 headers at first
nanonyme: It doesn't even need a /usr/src/linux symlink, I think. :)
MNZ: ah no wait my bad XD
MNZ: that last build was in the drm directory, not linux-core
steffen_: it uses the ehaders installed in /usr/include iirc
MNZ: ok it's still not building
MNZ: and what are the headers in /usr/include/linux?
nanonyme: MNZ: Btw, FYI most programs find the kernel source tree by doing a /lib/modules/kernelversion/source check.
nanonyme: Using the running kernel's version.
MNZ: yes I thought so, but building some modules a while ago I had to create a link at /usr/src/linux.
nanonyme: Well, what's it erroring out on now?
MNZ: same thing
nanonyme: How are you trying to compile it exactly?
MNZ: entering the linux-core directory
MNZ: then make DRM_MODULES='radeon'
MNZ: I had another error before this one, about irqreturn_t
nanonyme: Hmm, that should work assuming you're on 2.6.30 atm...
steffen_: someone any idea why my second monitor is blank?
nanonyme: MNZ: The irqreturn_t thing is fixed in git.
MNZ: I do have git :S
nanonyme: Then you're doing something wrong.
MNZ: ok. I've removed the drm repo
MNZ: now 'git clone git://anongit.freedesktop.org/~agd5f/drm'
nanonyme: Right.
MNZ: cd drm && git checkout -b r6xx-r7xx-3d origin/
MNZ: btw I'm following this guide http://neo-technical.wikispaces.com/radeonhd-3d
nanonyme: There's your problem.
nanonyme: Should be git checkout -b r6xx-r7xx-3d origin/r6xx-r7xx-3d
MNZ: oh my
nanonyme: The error matches what you would get with master branch.
MNZ: ok thanks, I'll try building now, once the clone is complete
nanonyme: MNZ: Friendly tip, don't use that guy's guides. ;)
MNZ: haha the rest of the command is actually on the next line on the guide *facepalm*
nanonyme: Apparently he doesn't test them.
MNZ: I've just been told that by another fellow, but not about this guide in specific....
MNZ: but I can't find much info elsewhere, so better than nothing :-/
nanonyme: MNZ: Yeah, Neo apparently put a space between origin/ and r6xx-r7xx-3d. :3
nanonyme: (and apparently you have a narrower screen than he does if it wrapped)
MNZ: I would have noticed this if I had the vaguest understanding of git. But no amount of reading can help with that :S someday I will
nanonyme: MNZ: git branch -r shows remote branches, git checkout -b (local branch name) origin/(remote branch name)
nanonyme: Not that complex.
steffen_: what means that origin ?
nanonyme: I'm not sure if it means anything. :) It's a term signifying the following keyword is a remote branch.
nanonyme: (in that context)
nanonyme: Since you could be creating branches of local branches too.
nanonyme: Erm, local branches out of local branches even.
MNZ: nanonyme, thanks for the quick primer
MNZ: compiles now, thanks for the help!
nanonyme: MNZ: There's probably not much you need to know if you use git as end-user. Important parts are git branch (creating branches, deleting branches and so, checkout uses this when you use -b switch), git checkout (changing branches) and git clone (creating local repos). man pages are available like man git-checkout.
nanonyme: That's more of a primer. ;)
nanonyme: MNZ: Oh, and another thing: always use git:// links unless explicitly told otherwise and cgit pages hold the respective git:// link at the bottom-most part of the main screen.
agd5f: origin is just an alias for the remote repo. it's specified in the git config for your tree. By default it's the repo you cloned from
MNZ: I've read the man pages and a starting out guide somewhere, but when I stopped using it daily for a few months I forgot all about again
nanonyme: agd5f: Btw, are you using 32bit or 64bit kernels?
agd5f: nanonyme: mostly 64 bit
nanonyme: Right.
nanonyme: Hmm.
nanonyme: http://lkml.org/lkml/2008/4/24/420 this is odd
nanonyme: agd5f: Your r6xx-r7xx-3d might actually not work even with 2.6.27 32bit with CONFIG_HIGHMEM. :)
nanonyme: Oh, wait.
nanonyme: Sure it would..
MNZ: do I need mesa from git?
nanonyme: So the issue wasn't actually init_mm being dropped but more kmap_atomic_prot_pfn getting defined in kernel.
agd5f: MNZ: yes
nanonyme: (so it no longer needs compat)
nanonyme: Which apparently happened here http://lkml.org/lkml/2008/10/24/66
nanonyme: headdesks
agd5f: nanonyme: this is why it's a PITA to support the drm out of tree
nanonyme: agd5f: I noticed it a while ago myself.
EruditeHermit: are you going to merge it in 2.6.32?
agd5f: EruditeHermit: that's the plan hopefully
EruditeHermit: hopefully that will be soon
EruditeHermit: probably less than a month till 2.6.31
nanonyme: agd5f: I guess the only solution to actually find out is me checking earlier kernel versions on when it was actually introduced...
nanonyme: http://koti.kapsi.fi/nanonyme/public/really_fix_init_mm.patch needs testing on x86 with CONFIG_HIGHMEM but I think that should do it
nanonyme: agd5f: And yeah, it appears my suspection was right: the DRM shouldn't compile on 32bit 2.6.27 and 2.6.28 on distros that have CONFIG_HIGHMEM on (I think at least Debian).
nanonyme: (of course this doesn't matter much since it'll be merged into 2.6.32 anyway, hopefully)
nanonyme: I'd suspect the slow amount of complaining shows most people testing r6xx/r7xx 3D are running 64bit kernels.
nanonyme: Ah, well. At least it works for 2.6.31 for everyone. :P
mcgreg: it now does, thx to you :)
nanonyme: mcgreg: Yeah. But while doing some more background-checking I found out everyone with kernels from 2.6.25 to 2.6.30 has it still broken. >.<
nanonyme: Oh, wait. I meant 2.6.27 to 2.6.30.
nanonyme: The original compat code handles 2.6.26 and lower.
phercek: nanonyme: it compiled for me on 32 bit 2.6.30.4 (the small patch I had is probably because of ARCH backporting from 2.6.31)
nanonyme: phercek: No, it really should not compile even on 2.6.27 according to the sources and commits. :D
nanonyme: That's my point.
nanonyme: Except if you either are running 32bit with CONFIG_HIGHMEM=n or 64bit.
nanonyme: init_mm was removed from UNUSED_SYMBOLS and kmap_atomic_prot_pfn was introduced both in 2.6.27.
nanonyme: Which means the whole compat section is only valid for 2.6.26 or lower.
phercek: ach ok; my kernel has CONFIG_HIGHMEM=y
nanonyme: (whole original compat section, that is)
nanonyme: phercek: My problem here was that I assumed that it would compile on 2.6.29 or lower since I hadn't bumped into that issue myself but this was obviously a false belief.
adamk: rnoland: Have you seen this before? http://pastebin.com/f4ba4e097
adamk: rnoland: It seems to happen nearly every time I restart my X server, and I only get direct rendering the first time X starts up after rebooting.
rnoland: adamk: I haven't seen it, but I almost never try to restart X... It has a tendency to fail often on different chips in different ways.
nanonyme: Out of memory? o.O
rnoland: I expect it is some resource that isn't being released that should be.. but I'll have to try and check it.
adamk: It used to work fine, but has been this way for a little while for me.
adamk: And if I kldunload the module, X just won't start back up at all.
rnoland: adamk: a drm debug over the restart might prove useful
rnoland: see exactly what allocation is failing..
rnoland: adamk: does it report memory leak when you unload?
adamk: Hold on, I think I can grab debug information now. And then I'll try rebooting.
rnoland: I'm currently in via hell...
adamk: Errr... Not rebooting, but unloading the module.
rnoland: adamk: ok, cool
adamk: rnoland: Yes, memory type drm_bufs leaked memory
adamk: And let me pastebin the debug info.
adamk: http://pastebin.com/f7ab9f7ca
rnoland: adamk: ok... i don't think that is uncommon... i never finished tracking that down.
adamk: D'oh.
adamk: Hold on, let me clean that up.
rnoland: adamk: um, why is all of that stuff coredumping on SIGABRT?
adamk: http://pastebin.com/f21dea212
adamk: Probably because I started pkg_delete'ing everything this morning.
adamk: I had some really serious issues with portupgrade last night :-)
adamk: After unloading the module, trying to start X results in "No Valid MMIO address" in the Xorg log file.
rnoland: hrm, it is the scatter gather allocation that is failing...
adamk: Anyway, I know you are busy. Next time you trade in your current hell for the radeon hell, you may want to take a look :-)
rnoland: adamk: ok, i've just become aware of an issue with SG allocations in the last couple of days... but i'm not sure it would cause this.
rnoland: It seems that we request uncached pages in the kernel and then mmap those to userspace as Write-Back
rnoland: jhb/alc have sent me fixes for that...
rnoland: it might be something else in the kernel... nouveau is acting wierd on me as well and it uses the sg allocation.
rnoland: it is hanging on shutdown for me right now... but i haven't tracked down what change broke it..
adamk: You're a busy guy these days :-)
rnoland: adamk: actually, can you try this....
rnoland: after you unload the module, do a vmstat -m and see what and how much memory is still allocated to bits of drm
adamk: Maybe.
adamk: I just rebooted and am having a hard time reproducing the problem, oddly enough.
rnoland: adamk: yes, i'm not really surprised...
rnoland: adamk: we are asking for 256M of contiguous memory which is under 4G
rnoland: and after the system has been running for a bit, that becomes harder to come by....
adamk: Ahhh.
adamk: I'll keep an eye on it and grab that info for you next time this happens.
rnoland: iirc, I now allow bus_dma to sleep waiting to get resources, but i'll have to double check...
rnoland: adamk: technically the sg pages don't need to be contiguous, but bus_dma needs some work for that to happen i think.
rnoland: adamk: are you running zfs, btw?
adamk: rnoland: Nope. Have no desire to go near it, either :-)
rnoland: heh, well i am, but was just checking... the arc can suck up a bit of ram...
adamk: The only reason I even brought it up now was that someone else came on here Monday evening with the same issue. For the longest time, I thought it was just something odd about my setup.
rnoland: adamk: no, i'm asking jhb@ about it now...
rnoland: not sure what we can do though...
rnoland: but i'll take a look and see....
nanonyme: bridgman: Hey.
bridgman: hi
nanonyme: Been doing any testing of r6xx-r7xx-3d on 32bit? :)
bridgman: yeah, that was actually why I logged on this time
nanonyme: CONFIG_HIGHMEM=y?
bridgman: I was testing yesterday on rv620; most of the intermittent geometry corruption is gone but there's some permanent wrong geometry showing up on a few tests
bridgman: probably not
bridgman: don't think I have enough RAM for that ;)
bridgman: now if someone builds a 30-bit kernel, I'm all over it
nanonyme: Just wondering. Apparently r6xx-r7xx-3d currently doesn't work with 32bit with CONFIG_HIGHMEM from 2.6.26 to 2.6.30.
nanonyme: With the latest commit it now actually works with 2.6.31 though.
nanonyme: Hmm, I meant 2.6.27 to 2.6.30, I think.
nanonyme: You find funky stuff when people end up trying the DRM on distro stock kernels. :3
nanonyme: Debian just happened to have that config thing on with generic kernels so the DRM took a completely unexpected code path. :p
nanonyme: (or rather chose unexpected macros)
nanonyme: bridgman: Which test were you getting the corruption with, btw?
suokko1: I think r600 is now in better state thanr200 dri2 ;)
nanonyme: :p
bridgman: engine was the most obvious one
bridgman: singlebuffer isn't working well any more
nanonyme: Right.
bridgman: teapot as well IIRC
bridgman: the rest seemed ok
EruditeHermit: bridgman: would you know how soon the 795 chipset might come?
bridgman: haven't heard anything about it - presumably you mean an upclocked 785 ?
EruditeHermit: bridgman: yeah
EruditeHermit: bridgman: the equivalent of what 790 is to 780
PuffTheMagic_: why am i getting this:
PuffTheMagic_: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
PuffTheMagic_: [dri] radeon.o kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
adamk: Someone else reported the same problem this morning.
nanonyme: Oh. My. God.
adamk: MrCooper told him that his radeon driver is lacking KMS support.
nanonyme: Wonder if this is just the kernel I'm currently using or geartrain has horribly broken.
bridgman: oh yeah, geartrain had geometry corruption too ;)
nanonyme: Does it have anything else than geometry corruption? ;)
nanonyme: Though it looks interesting. Now I know what an engine must look when it's breaking up. :3
agd5f: nanonyme: mostly works fine here, just periodic glitches
bridgman: yeah, it's the same thing you see at a dragstrip right after the yellow flash
DanaG: "AMD 785G Update - Multi-Channel LPCM is not Available" -- dang.
marvin24: on my system, all demos are rendered in the upper left corner, even when moving the window
bridgman: agd5f; I used to see the belt spinning around with the gears occasionally, now more of the geometry spins around as well
marvin24: I also have other serve problems (see dri-devel)
DanaG: http://anandtech.com/weblog/showpost.aspx?i=629
adamk: PuffTheMagic_: So, most likely, you just need to upgrade your radeon driver.
DanaG: dang,
suokko1: PuffTheMagic_: You need to build libdrm with --enable-radeon-experimental-api
PuffTheMagic_: i am using 31-rc5
PuffTheMagic_: and i have that in libdrm
PuffTheMagic_: but i may have disabled kms in kernel
PuffTheMagic_: cause it was acting wonky before
PuffTheMagic_: checks
suokko1: PuffTheMagic_: and then you need you need to recompile ddx
adamk: PuffTheMagic_: But what version of xf86-video-radeon do you have?
adamk: SOrry, xf86-video-at
suokko1: PuffTheMagic_: And you have KMS enabled because drm version is 2.0.0
adamk: Stupid fingers... xf86-video-ati
nanonyme: bridgman: http://koti.kapsi.fi/nanonyme/public/geartrain.jpg like this?
marvin24: nanonyme: like to know how to build this :-)
legume: nanonyme: geartrain got worse for me after last mesa updates.
bridgman: I'm getting something similar but the details of corruption are different
nanonyme: marvin24: Hmm, build what?
bridgman: vertical shaft is OK for me, other stuff mixed up
bridgman: the "modified" geartrain
marvin24: nanoyme: the geartrain
bridgman: Escher on acid
nanonyme: marvin24: It's in progs/demos in Mesa sources and gets compiled unless you tell it not to.
bridgman: I think marvin24 means the geartrain as rendered
nanonyme: Ah.
marvin24: ok, not a good joke
nanonyme: Well, I'm not sure I'd know how to build that either, at least not when sober.
bridgman: anyways, bbl
EruditeHermit: where do you get these demos from?
nanonyme: As said, they're shipped with Mesa sources.
soreau: Is DRM supposed to be disabled in the kernel since building libdrm separately?
adamk: soreau: No. libdrm is just the userspace library. You need the DRM from the kernel modules.
jcristau: soreau: libdrm is what talks to the kernel drm
soreau: hmm
soreau: I need help with this then http://sprunge.us/hCHV
soreau: It works with 2.6.31-r4 but I have -r5 now and not sure I got the .config right
soreau: huh. wonder why it's trying to use xaa
adamk: Does 'modinfo radeon' show anything?
adamk: XAA was still the default till very recently.
nanonyme: soreau: Should be pretty straightforward to config the KMS stuff, just have to remember to set kernel modesetting in staging on.
soreau: adamk: It shows a lot.
soreau: nanonyme: I have staging and kms radeon stuff enabled in the kernel
adamk: Is the module loaded? Anything interesting in 'dmesg | grpe drm' ?
soreau: adamk: http://pastebin.com/m259d381e
soreau: $ dmesg|grep drm
soreau: [drm] Initialized drm 1.1.0 20060810
soreau: [drm] radeon default to kernel modesetting.
soreau: [drm] radeon kernel modesetting enabled.
soreau: http://pastebin.com/m69780187
adamk: Well I'm out of ideas, then.
adamk: Oh, wait.
adamk: Do not load radeonhfb.
adamk: That's bad.
adamk: Not sure it would cause this problem, but it's something you'll want to fix.
soreau: Damn
suokko1: yes. You have to use fbcon
adamk: radeon should now provide the framebuffer, not radeonfb.
soreau: I was trying to get a splash image to work for boot up/fb console
jcristau: you don't need radeonfb for that
soreau: Ok, lemme fix it
DanaG: Can you use fbcondecor on KMS?
nanonyme: shudders at the excessive use of *printf functions in drmCheckModesettingSupported
nanonyme: s/excessive //
nanonyme: Then again, who cares, the libdrm code is run with user privileges anyway. :)
MNZ: Hi. I'm trying to build mesa from git now, and I'm getting http://pastebin.com/m2c4c238c
MNZ: which drm.h is that? I tried a locate drm.h and found several ones
nanonyme: The one that comes with libdrm?
MNZ: that's xf86drm.h?
adamk: No, that's drm.h
adamk: xf86drm.h comes with libdrm too.
MNZ: xf86drm.h should go into include/drm or include/ ?
adamk: YOu should really install libdrm :-)
suokko1: MNZ: right one sohuld be from libdrm/shared-core/ nd it should be installed to $prefix/include
MNZ: I'm trying to install from git
rnoland: adamk: so we are looking into making bus_dma smarter... to deal with non-contiguous allocations...
adamk: rnoland: Yay :-)
soreau: Alright, now when 2.6.31-r5 boots when it gets to the part where it changes the bootup screen to a different resolution, there is no output from the screen until after X completely starts
soreau: But, at least after X starts dri2 is working
adamk: soreau: Odd... You get kernel messages before it loads but not after?
adamk: Maybe fbcon isn't built into the kernel or loaded as a module?
soreau: adamk: I will have to check that
soreau: I assume messages are present, but I just can't see them. It doesn't turn the monitor off, it's just black
MNZ: make[3]: *** No rule to make target `eglcurrent.c', needed by `depend'.
suokko1: soreau: I have same problem with Ubuntu rc5 kernel but my own works ocrrectly
adamk: Yeah, that sounds like missing fbcon.
soreau: adamk: I don't see fbcon in kernel config
soreau: At least find can't find it
adamk: Alright, so apparently I'm confused...
adamk: HOld on a a second.
soreau: But I do think it may be related to frame buffer something or other
adamk: Yeah, I think I have the module name wrong.
adamk: Do you have FRAMEBUFFER_CONSOLE enabled in the .config file?
suokko1: soreau: missing fbcon would cause console not to show with kms. But for me fbcon loads nicely after VT switch
adamk: Wow... The kernel config stuff has really changed since the last time I compiled a kernel.
adamk: Where are all the framebuffer types?
adamk: Oh, found that.
soreau: adamk: It is a module and I cannot change that. I will change some other related things and try again
soreau: And yes, the config is constantly changing
adamk: Is the module that it compiles to currently loaded?
soreau: adamk: module fb is in use by radeon
adamk: Alright, that sounds right.
adamk: I'm definitely out of my league on this one.
soreau: What does Framebuffer Console Rotation do?
adamk: goes sulking off to freebsd land again.
soreau: adamk: Gentoo has really been working out great for all this kms/dri2 stuff. With the x11 overlay, one command builds all the live/git stuff with appropriate flags/options :)
soreau: Also, thanks for your help
soreau: enables 'Map the console to the primary display device'
adamk: That is pretty cool.
adamk: I thought you had switched to Ubuntu :-)
MNZ: Everything is in place, but now I get libGL error: Calling driver entry point failed
suokko1: adamk: It is just me ;) But I use self compiled kernel
agd5f: MNZ: LIBGL_DEBUG=verbose glxinfo
soreau: adamk: I still run ubuntu on the other partition and the slower boxes but this gentoo install has been going strong for like three years now. I have got it into some sticky situations but nothing too bad to where I've ever had to reformat or anything
MNZ: agd5f, that's where the message is from
agd5f: MNZ: what does the whole message say
agd5f: is it trying ot load the right lib?
MNZ: r600
soreau: The no text on boot problem persists, but getting radeonfb out of the equation at least allows dri2 to work
adamk: Well I made one good call today, then :-)
MNZ: I thought it had to load the radeon one, and didn't actually build the r600 dri driver but then I found it in the debug message and built it. That's the right one for HD4650?
soreau: Interesting.. when I try to switch to tty* it effectively does nothing but freeze the X image on screen
soreau: suokko1: Is this what you experienced?
agd5f: MNZ: yes
nanonyme: soreau: Got fbcon?
soreau: And when I get back to 'F7' it refreshes everything
MNZ: I just found this too: libGL error: __driCreateNewScreen_20050727 not defined in r600_dri.so!
suokko1: soreau: no. I get black screen untill X start but when I do vt switch console start working
adamk: MNZ: Did you ever have fglrx installed on that machine?
soreau: nanonyme: I have FRAMEBUFFER_CONSOLE as a module and fb is loaded in use by radeon
adamk: MNZ: Sounds like the libGL.so.1.2 from it might still be installed.
soreau: suokko1: Oh, that's different than what I have. vt switch doesn't work at all here
nanonyme: soreau: I meant the kernel module fbcon.
soreau: nanonyme: I don't know how to check that
MNZ: adamk, ah ok. I'll remove it completely and install mesa again
nanonyme: soreau: lsmod|grep fbcon? :p
soreau: nanonyme: Nuthin
adamk: MNZ: Yeah, fglrx really needs to be completely removed for the mesa drivers to work properly.
nanonyme: soreau: Try loading it and then doing VT switch.
soreau: I searched kernel config for fbcon and nothing there either
nanonyme: soreau: It might be that FRAMEBUFFER_CONSOLE, actually.
suokko1: soreau: What if yo utry modprobe -v fbcon?
soreau: nanonyme: Yup, that worked. Can I tell it to load at boot or is this the same problem?
nanonyme: soreau: Make it inbuilt.
adamk: Can't he add it to his initrd ?
soreau: nanonyme: It is -M- and I cannot change that in the make menuconfig
soreau: nanonyme: Should I manually edit .config 0.o?
nanonyme: adamk: Sure.
nanonyme: soreau: Preferably not. :)
soreau: heh
adamk: Something that fbcon depends on is also built as a module.
nanonyme: Wonder what it depends on.
suokko1: soreau: You can add fbcon to /etc/modules
nanonyme: But then he won't get flicker-free X start at boot. :o
MNZ: fglrx purged, mesa reinstalled http://pastebin.com/m215f3411
adamk: MNZ: I'm not 100% sure, but this sounds like you are using an older version of mesa now: unknown chip id 0x9480
MNZ: that's mesa from git master, just cloned a few hours ago
adamk: No, it's not.
adamk: OpenGL version string: 1.4 (2.1 Mesa 7.0.4)
adamk: Definitely not :-)
adamk: So now I'm 100% sure :-)
MNZ: :S
nanonyme: Agh, apparently you can't get inbuilt fbcon without inbuild drm and radeon. :(
nanonyme: s/inbuild/inbuilt/
soreau: nanonyme: Ahh
soreau: nanonyme: Should I try that?
nanonyme: Worth a try.
nanonyme: You're not very likely to use out-of-tree DRM anymore anyway, right?
soreau: I don't think so..
soreau: Anyway it's worth a shot. Will let you know
nanonyme: soreau: Hey, I was wrong.
nanonyme: Wait still a bit.
nanonyme: DRM can be modular, "Support for frame buffer devices" has to be builtin.
soreau: is already recompiling with -*- fbcon
suokko1: btw, athcool with kms does cause only mild slow down with rc5 kernel :) It use to be horrible slowdown in earlier versions
nanonyme: soreau: That setup unlocks fbcon and you can pick whether you want it modular or builtin.
soreau: nanonyme: Which, modular drm and builtin support for frame buffer devices?
nanonyme: Yeah.
nanonyme: Modular DRM and radeon, builtin support for frame buffer devices, builtin fbcon.
soreau: nanonyme: You are right on one count so far.. and I have the penguin at the top now too :D
nanonyme: If dri works properly, might not be worth it to try that last version.
soreau: nanonyme: I still am just cause but I have a slightly unrelated question. What about Scrollback Buffer Size (in KB)? Can I change that value somehow?
soreau: And you are right about the modular drm to make fbcon have module option
nanonyme: Yeah, I'm kinda making this up on the fly extrapolating on what I know. ;) I haven't got a GPU to use KMS with nor have I looked very deeply into the kernel development.
soreau: Well you helped me out to do exactly what I wanted really
soreau: Thanks nanonyme!
nanonyme: No problem.
nanonyme: Now I at least know how it should be done.
soreau: nanonyme: And you were right yet again. Compiling fbcon as module just doesn't work on boot
nanonyme: soreau: Well, with that one I got a tip: airlied said he does fbcon as inbuilt for Fedora.
nanonyme: So that's gotta be a good and working choice. ;)
nanonyme: It's configuring rest of the stuff I didn't know how to do.
soreau: Must be a good choice indeed :)
nanonyme: But yeah, too bad might take until F13 to get r6xx/r7xx 3D. :)
nanonyme: (depending on how fast time flies compared to the speed of code maturing)
MNZ: Hi again. I finally got direct rendering (turns out I had an old libGLU that was getting loaded though it wasn't the one libked from libGLU.so) but I still get "unknown chip id 0x9480, can't guess."
soreau: MNZ: So what's the problem/
MNZ: s/libked/linked
MNZ: no problem really, just thought someone ought to know about this bug (if it is a bug, not something stupid I'm doing :S)
suokko1: MNZ Wat mesa version glxinfo is reporting?
suokko1: 7.6-devel?
MNZ: yes
MNZ: and I got direct rendering. Though it's slower than indirect
suokko1: not indirect but software
soreau: nanonyme: fwiw, without radeon compiled into the kernel, the boot logo does not work and it takes a second to kick into a nice resolution, even then it displays the text from half of the screen. Hard to explain, but anyway, having everything built-in it works much nicer on boot
soreau: MNZ: What does 'glxinfo|grep renderer' say?
MNZ: Software Rasterizer
nanonyme: soreau: Hmm, interesting.
nanonyme: soreau: And the dri node got created nice and fine with inbuilt?
nanonyme: That is, inbuilt radeon.
soreau: nanonyme: That problem was because I had enabled radeonfb
nanonyme: Ah. :)
soreau: It was working with dri1 but falling back to sw rasterizer for kms with radeonfb messing things up
nanonyme: MNZ: Well, the rendering is done entirely as software rendering so no surprise if it's slow.
nanonyme: soreau: Makes sense. Now you have working DRI2?
soreau: MNZ: You still don't have direct rendering and your X log should give a clue as to why. Posting /var/log/Xorg.0.log somewhere might be helpful
soreau: nanonyme: Beautifully, yes. Was working on 2.6.31-r4 but now with -r5 and everything built-in, it works right from first loading the kernel very nicely
MNZ: now I'm confused. glxinfo tells me I've got direct rendering.. but with the software rasterizer??
nanonyme: Actually iirc someone said indirect rendering mostly means "rendered through a pipe" or something similar, doesn't have really anything to do with software rendering.
soreau: MNZ: Yes. You have direct rendering but it is using sw routines to get there (slow)
nanonyme: Or hardware rendering either. They're separate.
soreau: indirect-rendering means the rendering are passed through the X server and not directly to the graphics driver
MNZ: (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/dri/r
MNZ: 600_dri.so: undefined symbol: __driCreateNewScreen_20050727)
soreau: rendering commands even
MNZ: directly followed by (EE) AIGLX: reverting to software rendering
nanonyme: Eww. o.O
soreau: But yes, indirect-rendering doesn't have anything to do with software rasterization
nanonyme: MNZ: Have you had fglrx before?
MNZ: yes, but not anymore
MNZ: and I completely removed it
soreau: So you think ;)
MNZ: purrrrggge
nanonyme: MNZ: Are you sure you reinstalled all relevant Mesa libraries?
MNZ: make install in mesa base
MNZ: I had a left over libGLU from the old mesa though and had to remove it manually....
suokko1: What does change in mesa/xserver when I enable metacity coposite with kms? I have huge rendering problems if I don't enable composite but when I use composite rendering works a lot better but not perfectly
nanonyme: MNZ: Are you sure libGL.so and libglx.so are also new?
MNZ: ah no libglx is not
nanonyme: (Oh, libglx might actually not be with fglrx)
nanonyme: That is, I'm not sure if it replaces it at all.
MNZ: libglx is from the debian pkgs here. This ships with mesa?
soreau: Does anyone have the problem in tty's where the input is missing some keys? For instance, loggin in I have to type the password twice. The first time I enter it, it acts as if I've done nothing. And frequently the first letter I type in tty is not typed at all
dileX: MNZ: reinstall libgl1-mesa-glx. next time check with 'glxinfo | grep -i opengl'
soreau: Everything inside of X is ok, just messes up with tty's
nanonyme: Well, it's very possible I just remember more replaced stuff than is necessary since I used nvidia years ago. :) libglx.so is usually part of X server package.
nanonyme: (which implies fglrx probably actually didn't touch it)
dileX: MNZ: $ grep _dri.so /var/log/Xorg.0.log might also be helpful
MNZ: dileX, reinstalling the mesa glx package from debian removes the unknown chip warning
MNZ: but then reverts to indirect rendering and software rasterizer is reported to be Mesa GLX Indirect
MNZ: make install in mesa git base brings back the unknown chip warning, with direct rendering on, and the software rasterizer
dileX: are you using libgl1-mesa-dri from Debian repo?
MNZ: yeah
dileX: DDX? repo - selfcompiled?
MNZ: self compiled
MNZ: latest git
dileX: xserver 1.6.3 I guess?
MNZ: and mesa from git too. xserver is 1.7.3
dileX: oha
dileX: step beyond you are
dileX: or three steps
MNZ: ?
dileX: 1.7 is next release of xorg-xserver (might be a typo 1.7.3)
NeKit: git clone git://anongit.freedesktop.org/~agd5f/drm
MNZ: dileX, terribly sorry, that was a meta package. Xorg server is 1.4.2
suokko1: MNZ: I guess you have to upgrade a lot of X stuff
dileX: not sure if you need a newer version of xserver >= 1.6 for ddx-from-git
bsund: Hey, using xorg 'ati' driver on a RS690 with KMS, I get some black flicker. Any workarounds? .29 kernel and 6.12.2 driver.
NeKit: do I need to enter git checkout r6xx-r7xx-3d?
suokko1: git checkout -b r6xx-r7xx-3d origin/r6xx-r7xx-3d
dileX: NeKit: see instructions here
NeKit: thanks
nanonyme: It should work with fdo *libdrm* nowdays too, requires DRM kernel modules still according to that guide.
NeKit: can you explain step 9. copy the new modules into your kernel tree. Depending on your kernel, either:?
NeKit: how to tell, to what directory should I copy?
NeKit: 2.6.28-11-generic, Kubuntu 9.04 x64
nanonyme: NeKit: Likely /lib/modules/kernelversion/kernel/drivers/gpu/drm for drm.ko and sub-directory radeon for radeon.ko.
nanonyme: You might want to make sure first with find though that they aren't in different locations in your kernel modules directory.
nanonyme: find /lib/modules/kernelversion -name radeon.ko -o -name drm.ko, I think
NeKit: I used locate
nanonyme: locate requires an index, don't rely on it. :)
NeKit: nekit@COREQUAD:~/mesa/drm/linux-core$ locate drm.ko
NeKit: /lib/modules/2.6.28-11-generic/kernel/drivers/gpu/drm/drm.ko
nanonyme: It depends on the position of the Moon whether it happens to work or not. ;)
kdekorte: doesn't "make install" work in the linux-core directory
kdekorte: I know it works on Fedora 11
kdekorte: you can also do "modinfo drm" and "modinfo radeon" to see where the modules are
nanonyme: kdekorte: It might or it might not. Usually better to double-check since most problems with kernel modules come with you having two drm.ko's and two radeon.ko's. :(
nanonyme: Or rather the most easy problems.
kdekorte: if you just want radeon on drm installed you can do "make DRM_MODULES='radeon' install
dileX_: agd5f: v2 of the uts patch applied. kde-4.3 started (no freeze). screen heavily corrupted - but I could see the outlines of windows and menue. couldnt make a screenshot (maybe not hit OK). Xorg.log has EXA w/ UTS and DFS
nanonyme: As said, rather replace the old ones with new ones, then you can be sure you don't get duplicates.
kdekorte: I've found that the modues in /lib/modules/kernelver/extra are loaded before the ones deeper in the tree
NeKit: Is hd3870x2 r600?
nanonyme: kdekorte: Hasn't happened for everyone.
nanonyme: NeKit: Should be.
nanonyme: HD3870 is rv670.
NeKit: but r600 driver will work, right?
agd5f: NeKit: yes. the r600 driver supports r6xx and r7xx chips
kdekorte: NeKit, yes it should.. not sure it will use both GPUs, but it will work..
kdekorte: Although support is pretty basic at the moment
NeKit: stupid fglrx refuses to work on HD3870x2 :(
nanonyme: Doing GPGPU or why'd you get the x2 version? :)
NeKit: because I didn't thought that there are so many problems with x2
MostAwesomeDude: Dual GPU support is currently missing.
MostAwesomeDude: We have no problems turning on and using the first GPU.
nanonyme: NeKit: Well, mostly I've heard two GPU's doesn't really increase performance except for GPGPU scenarios.
MostAwesomeDude: nanonyme: Not quite. You could do triple-buffered alternate frame rendering.
MostAwesomeDude: Or GPU load balancing.
MostAwesomeDude: All kinds of possibilities.
zhasha: nanonyme: what you've heard is probably the stats for SLI on NVIDIA cards
zhasha: which is a not-quite-worth-it gain
nanonyme: MostAwesomeDude: Well, sure if all you need for those is driver support and doesn't need to be specifically targeted for the program.
zhasha: whereas a dual core single card or anything on CrossFireX is significantly faster
nanonyme: thought CrossFireX is done pretty much on software-specific profiling where it's done at all
zhasha: A friend of mine does hardware reviews and benchmarks for a major danish site. His observations have generally been about 20-30% increase when using 2 identical cards in SLI, and around 60% with CrossFireX
nanonyme: Or utilized even.
nanonyme: (and fglrx doesn't utilize it)
zhasha: well, fglrx is a binary ball of failure
DanaG: I wouldn't call it failure... but "suckage" works for me.
DanaG: Total failure would be nvidia 96, at least last time I tried it.
nanonyme: zhasha: Well, fglrx doesn't utilize it because they're not doing profiling on Linux side as they're doing in Windows. :)
nanonyme: That's not saying it couldn't do it.
zhasha: I don't have the choice of fglrx anymore so I'm on the open drivers
nanonyme: But you mostly missed my point, I think.
zhasha: hmm? no I see your point
zhasha: I'm not contradicting you. I'm not saying it's fail in that particular area
zhasha: I'm saying it's kind of an all-over fail. At least in my case
nanonyme: zhasha: My point was that it's atm hard for me to see open drivers would get profiling so I'm interested if there's actually use cases for it which don't need the driver to know what kind of software is being run.
nanonyme: (or the target program to explicitly trigger features on)
zhasha: nanonyme: use statistical probability
nanonyme: MostAwesomeDude gave several very good use cases but I don't know if they require modifications in the target program to be useful.
zhasha: there's no real reason not to enable the second GPU, unless you're trying to save power
nanonyme: Speaking of which, does OpenGL define triple buffering?
zhasha: triple buffering requires no modification other than triple buffering support, which some apps already have
nanonyme: Right.
zhasha: I'm not sure if it defines it
nanonyme: Well, right. :3 You do have a good use case for x2 cards then.
zhasha: nanonyme: it might be possible to do triple buffering behind the scenes when double buffering is on
zhasha: but it would likely create timing issues
nanonyme: Yeah. But it's a considerable use case already if some programs can/do request triple buffering.
nanonyme: I don't need more convincing. ;)
MNZ: I am about to give up on this :( I have the do I need xserver from git to use the latest drm/ddx/mesa ?
nanonyme: You shouldn't afaik if this is about the r600.
nanonyme: I think I'm running 1.6.2 myself.
MNZ: I just updated to 1.6.3 from debian repos
MNZ: I still get unknown chip id 0x9480, can't guess. And direct rendering, but with the software rasterizer. I have tried both radeon and radeonhd drivers
MNZ: I have rebuilt everything after upgrading X
XenoPL: Hi all, just a quick question. Can anyone confirm powersaving features working on radeon+KMS?
agd5f: MNZ: the error means you have an old r600_dri.so
agd5f: LIBGL_DEBUG=verbose glxinfo should tell you more
agd5f: make sure the lib listed in the output is the one you built
MNZ: (EE) AIGLX error: Calling driver entry point failed(EE) AIGLX: reverting to software rendering
MNZ: that's from xorg log
XenoPL: My display stays on all the time. But DPMS functions work when I boot with nomodeset
soreau: XenoPL: My display is always on too
MNZ: and from the glxinfo with debug, libGL error: Calling driver entry point failedlibGL error: reverting to software direct rendering
MNZ: libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
agd5f: XenoPL: yes dpms works
agd5f: MNZ: can you pastebin the whole output?
XenoPL: Thanx for info agd5f, then I've gotta talk with fedora ppl
MNZ: I build mesa with egl disabled btw, I don't know what it is and whether it's relevant, it's just that mesa doesn't build with it
XenoPL: I've tried both with Gnome and KDE, absolutly nogo for me.
XenoPL: So i guess it's distro specific thing
MNZ: http://pastebin.com/m7b9f2e86 <--- glxinfo
kdekorte: agd5f, wasn't that the pci id you added just the other day? MNZ, how old is mesa git master
MNZ: kdekorte, about 6 hours old
soreau: tear free xv video is amazing with compiz
agd5f: kdekorte: 0x9480 has been there for a wile
soreau: tears a little with opengl apps (glxgears) but still is working fantabulously
kdekorte: MNZ, what is the file date on /usr/lib/dri/r600_dri.so
MNZ: already checked, and double checked now, 2009-08-05 23:28
zhasha: MNZ: what card is it?
MNZ: HD 4650
MNZ: hold on
agd5f: MNZ: you sure you don't have some fglrx bits still around?
Xeno_PL: Funny thing is monitor goes offline as it should when I'm in the console or not logged in.
kdekorte: Xeno_PL, I've had a lot of dpms issues with gnome-power-manager 2.26... I have one machine that never goes off and another that only turns off the displays every now and then
kdekorte: So perhaps you are running into that problem
zhasha: agd5f: why would that particular error be caused by fglrx?
agd5f: zhasha: fglrx preovides a replacement libgl
Xeno_PL: kdekorte, I've tried with GNOME 2.26, KDE 4.2 and 4.3
agd5f: plus some other libs
kdekorte: I wonder if MNZ has the libglx and libdrm from fglrx...
kdekorte: They are part of X and not mesa at least in Fedora
MNZ: kdekorte, replaced them. did a full removal of fglrx and installed all the oss stuff
zhasha: agd5f: yes but that error is thrown by r600_dri.so and there are no dl errors as far as I can see
kdekorte: MNZ, the ones in /usr/lib/xorg/modules/extensions?
zhasha: MNZ: are you using mesa from git?
MNZ: is there a debug mode where it can tell us why driver entry point is failing?
MNZ: kdekorte, no actually I haven't seen those files at all, none of them have been replaced from today :-/
MNZ: shouldn't mesa install libdri and libglx there?
zhasha: MNZ: you need a git checkout as PCI_CHIP_RV730_9480 was only added 3 days ago
MNZ: zhasha, yes I'm using mesa from git
MNZ: just cloned about 6 hours ago
zhasha: could you go to the git root dir and cd src/mesa/drivers/dri/radeon
zhasha: then git grep PCI_CHIP_RV730_9480
MNZ: 0_0 nothing
MNZ: I'm supposed to use the master branch right?
zhasha: yes
zhasha: what does git branch say?
MNZ: omg... r6xx-rewrite *facepalm* *headbang*
zhasha: occam's razor
MNZ: damn you old guidddessssssss.
MNZ: I read I had to use the master branch somewhere more recent and forgot that I had already switched branches
MNZ: how do I switch branches again?
zhasha: git checkout master
MostAwesomeDude: nanonyme: If you're looking for actual ways to utilize it...
suokko1: MNZ: you could also try packages from https://launchpad.net/~xorg-edgers/+archive/ppa
MostAwesomeDude: In kernel-side CS, when a CS buffer is submitted, retarget it for whichever GPU is idle, or whichever GPU has the least pending work.
MostAwesomeDude: Doesn't require *any* application awareness.
suokko1: But there is not yet drm for r600 3D
nanonyme: MostAwesomeDude: Interesting.
MNZ: suokko1, nice, but not after I finally found the idiotic mistake I was making
agd5f: suokko1: yes there is
zhasha: MNZ: got it working?
suokko1: agd5f: I didn't notice that :)
nanonyme: MostAwesomeDude: Doesn't sound very trivial to implement though.
MNZ: zhasha, building now. thanks a lot for the help
agd5f: suokko1: compiz even works
suokko1: if you have igp :)
MostAwesomeDude: nanonyme: Well, there's only two ways that the card works, that I can think of.
nanonyme: I was actually thinking of the actual scheduling.
MostAwesomeDude: Either (a) the second GPU has the same register layout, but at a different register offset, or (b) it has a second ring buffer to itself.
MNZ: OpenGL renderer string: Mesa DRI R600 (RV730 9480) 20090101 TCL
zhasha: let's just focus on having 1 gpu work with gallium first
MostAwesomeDude: Either way is pretty easy to do with the current CS.
MostAwesomeDude: nanonyme: How do you mean, the scheduling? Once something's been submitted to the card, it's submitted. There's no time slots or priority selection; CS buffers are run in the order they are received.
agd5f: suokko1: igp and discrete
zhasha: MostAwesomeDude: he means "how do we know how much pending work a GPU has"
suokko1: agd5f: HAve you already implemented optimized copy?
nanonyme: MostAwesomeDude: Oh, read wrong. You were just keeping them in one queue and sending to the first active GPU. :) Works.
nanonyme: Erm, first idle even.
agd5f: suokko1: working on it now
MostAwesomeDude: zhasha: Oh, easy. Either poll for idle, or send it to the one with the smaller pending ring buffer.
nanonyme: Probably scales for up to n GPU's pretty easily?
MostAwesomeDude: If you wanna get fancy, you could count VBO sizes.
suokko1: I don't think compiz works before faster buffer swap
agd5f: suokko1: it does, just slowly :)
suokko1: 1fps is not working ;) I think my laging kms desktop with r200 is not working either ;)
nanonyme: Compiz also works wrong for me but that's nothing new. I don't think I've ever had working Compiz with any drivers.
nanonyme: (on any display card)
EruditeHermit: MostAwesomeDude: don't you need some way of checking to see if you somehow have an infinite loop and infinite submissions that will crash the card?
nanonyme: Define infinite submissions. :)
EruditeHermit: nanonyme: there was a long loops test for a program I use that crashed certain cards with certain video drivers
MostAwesomeDude: EruditeHermit: That's part of current CS, not something only needed for multiple GPUs.
EruditeHermit: MostAwesomeDude: so there is a check already?
EruditeHermit: some scheduler exists
phercek: MostAwesomeDude: You mentioned limits for max resolution yesterday (scanout, blitting, max 3D texture). ATI cards (both 6xx and 7xx) cannot display 5040x1050x57Hz on windows. Do you happen to know which of the three reasons is the limit in this case? Or is it only because of the driver?
nanonyme: That's a, ehm, big screen. :)
soreau: I'd say
phercek: nanonyme: it is actually 3 screens connected using matrox triplehead2go (3 x 1680 x 1050)
nanonyme: Ah, right.
nanonyme: Wonder at which point you run out of bandwidth...
bsund: Hey, using xorg 'ati' driver on a RS690 with KMS, I get some black flicker. Any workarounds? .29 kernel and 6.12.2 driver.
phercek: but for a VGA it is one screens, just curious why 5040x1050x57Hz does not work with ATI cards and works with Nvidia
nanonyme: I'd assuem Windows drivers attempt to be well on the safe side of software limitations though. :)
nanonyme: Erm, hardware limitations even.
bsund: Fedora 11..
bsund: Would it work better with radeon/hd ?
suokko1: agd5f: btw, What about my horrible git mess up patch for locking reference counting? I have been running it since I got it working in my system so it should at least work in basic ussage
bsund: 3D, KMS is ace, it's just the flickering.
nanonyme: Hmm, was RS690 r5xx or what?
nanonyme: Just wondering.
bsund: nanonyme, second guessing, x19?? something?
suokko1: bsund: ati=radeon
bsund: the selling name that is
suokko1: And can you be more detailed what kind of flickering and when?
nanonyme: No no, I meant which chip it's based on.
bsund: suokko1, ah didn't know that
nanonyme: Or rather chip family.
nanonyme: Sounds like one of those crossbreeds.
bsund: suokko1, it happens more or less all the time, seems maybe that the sync isn't right. but when using firefox it sometimes just flicker in the application. It's gnome without compiz/effects
bsund: Sadly I don't use the machine atm.
bsund: http://pastebin.com/m1a7a4feb <-- lspci
bsund: Radeon X1200 Series
bsund: It's a hp business model, and it was in the dock. Maybe sending the video through the dock triggered the flickering. (speculating)
bsund: And don't trust my word that it was just flickering in a application
agd5f: bsund: might be disply underflow or pll issues. try that latest kernel bits if possible
agd5f: suokko1: looks good, I haven't gotten a chance test it much yet
suokko1: I don't know why intel has mutex for drm lock. But is there any reason to have same for radeon?
nha: nanonyme: if I remember bridgman correctly, it's indeed a crossbreed; R500 3d engine, but R600 (or something) display
nanonyme: Ah.
nanonyme: nha: But if it's R600 display, it's definitely not in the list of ready cards for KMS, right?
nanonyme: 00:17 < bsund> Hey, using xorg 'ati' driver on a RS690 with KMS, I get some black flicker. Any workarounds? .29 kernel and 6.12.2 driver.
osiris_: nha: actually it is r400 3d and r500 2d
nanonyme: Oh, then should work. :)
nha: ah damnit, those wacky IGPs...
nha: thanks for clearing that up
nanonyme: bsund: Btw, if you want unless you want to migrate to the newer KMS stuff than what Fedora 11 has, probably want to keep nagging Fedora devs.
nanonyme: Erm, unless you want to even.
nanonyme: The alternative being installing a newer ddx, newer Mesa, newer libdrm and a newer kernel.
bsund: nanonyme, well the Fedora devs only keep pushing rawhide. And I think they run pretty well alongside the ati guys?
nanonyme: bsund: Technically yes... It's just that if you've problems with Fedora 11, you're better off filing bugs, really.
nanonyme: No one else except Fedora 11 users is using that KMS stuff anymore.
bsund: uhm.. KMS seems to be kinda nice?
nanonyme: Everyone else has shifted to the kernel support in 2.6.31, ddx from git, libdrm from git and Mesa from git.
nanonyme: It is.
bsund: rootless X is worth it I think
nanonyme: I didn't say people stopped using KMS, I said they stopped using the KMS stuff Fedora 11 has. :)
DanaG: no, you may have meant that, but it didn't come out that way.
DanaG: =þ
nanonyme: True.
nanonyme: Ambiguous sentences for the lose, Murphy's law dictates they're always misinterpreted. :)
nanonyme: bsund: In a nutshell: update or complain to Fedora bugzilla. :)
bsund: nanonyme, ya but it's not my comp, and I think the owner will survive with it, just wanted to know if it was a known bug..
nanonyme: bsund: It might also be a fixed bug. ;)
bsund: nanonyme, It might be and everything else works flawless.
nanonyme: Pretty much if you want it fixed for Fedora 11, you'll have to complain on Fedora bugzilla. If you suspect it might still be a problem with current drivers, you'll have to update the system far enough to see if it is.
bsund: I don't care about Fedora.. Personally I think it's badass. I just wanted to check with you guys, if you had any clue what it was about.
bsund: Which you had and said 'that should probably have been fixed'
bsund: So I'm happy :-)
nanonyme: I don't know if it is since I don't have applicable hardware...
nanonyme: I just know there's been lots of changes so it might not be there anymore. But it also might be.
bsund: I sadly don't have time to research it further, but I will keep contact with the owner and see what happens.
bsund: But Fedora 11 is frozen since a long time ago so he'll "suffer" from it until F12 comes out, and I'll help him upgrade ofc.. (The good thing with Fedora, loads of release parties!)
nanonyme: bsund: They do fix bugs still.
nanonyme: They might be more cautious with tampering with frozen systems but that doesn't mean they're unmaintained. :)
DanaG: pavucontrol CRASHES when I connect my bluetooth headset.
bsund: whoa! I was just thinking about buying a bluetooth headset :)
bsund: nanonyme, I probably will be able to check his comp out and i'll make sure to do the bugzilla.redhat.com, Thanks for you help :)
nanonyme: bsund: No problem. Of course, they'd probably be leaner if it was a security-related bug but but. I suspect they'll at least see if they can backport a fix without breaking anything.
bsund: Is there any ati guys with redhat? They fetched the nouveau guy and they have very good support for intel.
nanonyme: bsund: At the very least, you might get a "fixed in rawhide" status in the bug. ;) Then you know you don't have to worry about whether it'll get fixed for F12.
nanonyme: Well, airlied is one RH developer anyway.
bsund: Ya, i'm using a RS780 and it works flawless, no KMD no 3D, but the rest is badass
bsund: s/KMD/KMS
nanonyme: Same... Personally hoping rest of the r600 KMS gets ready enough to get into F12.
nanonyme: Then again, my hopes aren't going to chance much anything, really.
bsund: I'm just happy with 2d, emacs works, I can scroll fast in firefox and I can watch all porn that I get, unless it's _really_ high-res
nanonyme: :P
nanonyme: HD porn sounds a bit icky to me, I don't want to see the actors' skin too accurately...
bsund: hehe there is a xkcd for that
bsund: http://xkcd.com/598/
nanonyme: Meh, yeah.
bsund: :-)
nanonyme: I think I'll just throw a reinstall on F12, running out of hard disk space. :)
nanonyme: Want to reorganize partitions.
nanonyme: didn't expect his OS to bloat up to 25 gigabytes
bsund: How did you manage that? :)
nanonyme: I'm not really sure.
suokko1: HD porn? :P
nanonyme: No, my stash is on another partition.
bsund: suokko1, nah that it's on the /home partition :)
nanonyme: Yups.
bsund: s/it's/is
nanonyme: Meh, I'll probably just wipe my testing partition since I don't need to run fglrx anymore, will free 30GB more for OS partition.
bsund: if you use fedora it's nice to do the rpmbuild thing.. you always end up half rawhide half stable.. Which is really nice.. I'm on a new laptop so I haven't even enabled testing on this one :)
bsund: with last one I followed the stuff I was interested in, got srpm from koji and built it for f11
nanonyme: I tend to compile the components I need from git and be sated. :)
nanonyme: Probably should some day figure out some way to do it with srpm's but haven't had *that* much extra time.
nanonyme: (that is, have an srpm work as a git wrapper)
nanonyme: I'm fairly sure it's possible.
bsund: wha, hafta go thanks for the talk! nanonyme and the rest of you! :-) catchya laters
MNZ: I'm off, thanks everyone who's helped me out today. And great job on the drivers!
airlied: so the r100 post code works out the video ram wrong herre I think
airlied: agd5f: ^
agd5f: airlied: likely
EruditeHermit: agd5f: hi
EruditeHermit: agd5f: do I have to set the registers one at a time and restart if it fails and try again?
EruditeHermit: or can I go through setting them all in one shot
EruditeHermit: for bug 23103