tomsh: radeonhd 3d acceleration works on ATI Technologies Inc Mobility Radeon HD 3450/ RV620 ?
airlied: the development code should do
tomsh: airlied: i use git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd
airlied: its in a branch from that repo
airlied: you also need a drm branch
tomsh: airlied: i use all X.org from git
airlied: libdrm is kernel modules, not sure there is a build howto yet
tomsh: compiled for 1.5.2, module version = 1.2.4 my radeonhd
airlied: drm is kernel modules, libdrm is not.
airlied: the branch is r6xx-r7xx-support
tomsh: libdrm is not part of drm of git repository?
airlied: yup you need the kernel modules from the same branch name in drm.git
tomsh: i think i have compiled all needed
airlied: you used git to checkout the branches?
tomsh: and in my /usr/lib i have libdrm.so.2.4.0
airlied: its more the drm.ko and radeon.ko modules you load into the kernel
airlied: you didn't need to do that before
airlied: and the radeonhd from the branch intead of from master
tomsh: and i have both drm.ko and radeon.ko module compiled
tomsh: i'm not familiar with git
airlied: did you do git checkout origin/r6xx-r7xx-support for radeonhd and drm.git
tomsh: mm ok...i use only git clone
airlied: for accel experiments you need branch
tomsh: perfect
tomsh: but with git branch i see only master branch
airlied: git branch -a
airlied: for remote branches
tomsh: ok... and origin/r6xx-r7xx-support ?
tomsh: i'm too newbie for using...
airlied: yup
Veza: How soon will r6xx-r7xx-support be part of trunk and release?
Zajec: agd5f: you wrote you probably got rid of all corruptions
Zajec: agd5f: please keep in mind my bug report http://bugs.freedesktop.org/show_bug.cgi?id=19874
Zajec: i tested radeonhd from git 3 days ago... will check this today to make sure it still happens, but i guess it still does
biker_rat: r6xx_accel.c: In function ‘R600CPFlushIndirect’:
biker_rat: r6xx_accel.c:133: error: implicit declaration of function ‘RHDDRMFDGet’
biker_rat: r6xx_accel.c:133: warning: nested extern declaration of ‘RHDDRMFDGet’
biker_rat: make[3]: *** [radeonhd_drv_la-r6xx_accel.lo] Error 1
biker_rat: I get this error after make, any clues?
biker_rat: This is git r6xx-r7xx-support branch.
biker_rat: Anybody have any input about the compilation error? If not Im going to logoff and go eat.
Ge0rG: hey guys, radeonhd/r6xx with EXA enabled collides with software suspend... after a resume, I have 100% cpu load (in kernel mode) on all cores. any idea on how to fix that? :>
Ge0rG: nothing strange in dmesg though.
udovdh: hello
udovdh: how well does the latest commit work? (opitiize overlapping copy on r6/7xx
Anorick: udovdh: Very well, aside from rare corruption.
rehabdoll: great
udovdh: ok...
udovdh: so less corruptian than last week
udovdh: and almost usable?
rehabdoll: not almost, it is
rehabdoll: atleast for me
udovdh: (I saw some corruption, font colours that were off, etc)
udovdh: I am on Rv635/630
udovdh: and windows are quicker
udovdh: when they are dragged?
udovdh: last week they were slow, sluggish
Anorick: They are.
udovdh: slower than the unaccellerated situation
udovdh: ah, ok.
rehabdoll: rv630 2600xt here
udovdh: good news!!
Anorick: ...the only corruption I've encountered this week is with dragging highlighted text in Firefox.
udovdh: I have a 2600pro
udovdh: and a rv635 in this box here
udovdh: ok ok.. we're getting there...
udovdh: cool!!
rehabdoll: i have yet to see any font corruption
ech0s7: i have rv620 and with EXA and DRI i have monitor color corruption
ech0s7: font corruption
ech0s7: freeze of X
ech0s7: and i have to reboot system
zakalwe: i'm getting that text dragging corruption and some jpg corruption in the latest git for hd4850
ech0s7: this is situation to me (hd3470): http://g.imagehost.org/view/0471/screenshoot
ech0s7: this is dmes & xorg log: http://rafb.net/p/4zJUHP44.html
ech0s7: any suggest ?
bridgman: ech0s7; maybe try Option EXANoComposite True, might help track down where the problem is
ech0s7: ok bridgman
ech0s7: reboot
bridgman: I noticed your log said driver was built from commit 1377446a
Ge0rG: hi bridgman
bridgman: that doesn't seem to be the latest
bridgman: hi Ge0rG (geez your nick is a pain to type ;))
Ge0rG: bridgman: were you able to find anything out regarding the underscan issue I mentioned some weeks ago? ;)
kcodyjr: bridgman, tab-completion ;)
Ge0rG: bridgman: you are free to call me "georg" too
kcodyjr: 'morning by the way, not used to seeing you here at this hour...
bridgman: late friday afternoon the bios architect ran up to me in the elevator, apologized for not having time to talk this week but saying we'll talk next week
bridgman: so, not yet but hopefully soon
Ge0rG: hehe, you guys are pretty busy, eh? :)
bridgman: let me rephrase, ran up while I was getting in the elevator
bridgman: not that we have big elevators
ech0s7: bridgman: not solved
ech0s7: Xorg.log: http://rafb.net/p/qTzqdr52.html
bridgman: ok, worth a try - take it back out so we don't forget
bridgman: looks like your driver was built only a couple of commits ago, so don't think that's the problem
ech0s7: [mi] EQ overflowing. The server is probably stuck in an infinite loop.
ech0s7: yes bridgman
bridgman: no, I take that back; the next commit was "fix typos in cache flushing"
ech0s7: i have compiled yesterday
bridgman: compile today please ;)
ech0s7: ok
Ge0rG: ah, the last line in my suspend2disk Xorg.log is "(II) RADEONHD(0): Query for Restore Registers: failed" repeated twice
bridgman: kcodyjr; normally I'm at work and 100% IRC-free
PWMx: Tried again with the lastest git commits - And still EXA is broken. Then I tried r600_demo - And even there EXA tests seem broken. What next ?
_kopsu_: allright. the latest commit seems to speed-up the drawing of windows :) works great for me (x.org 1.5.3, radeon 4850)
bridgman: PWMx; what is your hardware again ?
bridgman: GPU, bus etc...
_kopsu_: i have no corruption on desktop.
PWMx: bridgman: RS780 + some AMD64x2 (One minute for the details ..)
bridgman: ok, that's enough, thanks
bridgman: can you pastebin x log and dmesg ?
bridgman: and maybe conf while you're at it
PWMx: I think agd5f & co alredy checked those few days ago. I could re-pastebin if needed ..
bridgman: you're running newer code now, so wouldn't hurt to re-paste
_kopsu_: any idea how to benchmark desktop drawing etc.?
_kopsu_: just curious
ech0s7: _kopsu_: gtkperf
bridgman: I don't think we have a good benchmark for "dragging windows around" but gtkperf covers some
_kopsu_: hmm. i have to check out if i find ebuild for that
bridgman: there was a Phoronix article recently with a bunch of different tests
_kopsu_: found it. i'll try that...
bridgman: worth looking at because those tests are probably all set up in the automated test framework
PWMx: Do you wan't everything with DRI+EXA ? (If so need to re-capture some logs ..)
bridgman: yes, nothing else is expected to work
bridgman: _kopsu_; http://www.phoronix.com/scan.php?page=article&item=amd_r700_2d&num=1
bridgman: all set up in the test suite AFAIK; would be interesting to re-run with the latest radeonhd code
_kopsu_: hmm
_kopsu_: i guess phoronix will check out the performance of newest code sooner or later
PWMx: dmesg : http://pastebin.com/m6cd58408
PWMx: xorg.log : http://pastebin.com/mcc39bd6
PWMx: xorg.conf http://pastebin.com/d4034cc3d
bridgman: the only odd thing in dmesg is that drm seems to initialize twice with that hda-intel message between the instances
bridgman: could be normal (maybe one set of messages from kernel startup and another from X startup) but I don't think I've seen that before
ech0s7: bridgman: i have compiled the latest git
bridgman: any change ?
_kopsu_: hmmh. i guess i have same in my dmesg...
ech0s7: bridgman: something... see: http://g.imagehost.org/view/0943/Schermata
ech0s7: bridgman: this is the log
ech0s7: $ cat xorg.log dmesg.log |nopaste
ech0s7: http://rafb.net/p/0ZmnBF62.html
bridgman: _kopsu_; good to know
PWMx: There were also some aperture and PCI BAR 3 warnings. But based on google those are common ..
bridgman: PWMx; was it your system that was showing corrupted screens even with acceleration turned off ?
bridgman: pretty sure it was; if so we need to get that fixed first
bridgman: your log says you have an M82 (RV620 mobile), not 780 - maybe you have one of those hybrid crossfire rigs ?
PWMx: No, none & shadowfb has always worked OK. With DRI+EXA there is corruptions and ExaNoComposite won't help.
ech0s7: bridgman: for my error ?
ech0s7: i have to add nopat to kernel ?
_kopsu_: there.. my dmesg http://pastebin.com/d6433e1c1
bridgman: sorry, too many logs ;0) ech0s7 has M82, PWMx has 780
bridgman: needs more coffee
PWMx: Just check one at the time .. ;)
bridgman: ech0s7; you're running VirtualBox ?
ech0s7: with "nopat" i have fixed this error
ech0s7: Xorg:5449 conflicting memory types c0000000-d0000000 write-combining<->uncached-minus
ech0s7: reserve_memtype failed 0xc0000000-0xd0000000, track write-combining, req write-combining
ech0s7: but i have always monitor corruption
ech0s7: $ cat xorg.log dmesg.log |nopaste
ech0s7: http://rafb.net/p/y5PN5I56.html
bridgman: PWMx; what problems are you seeing right now ?
ech0s7: bridgman: have you seen my log ?
bridgman: yep, looks fine
ech0s7: but i have always
ech0s7: monitor corruptio
ech0s7: http://g.imagehost.org/view/0943/Schermata
ech0s7: i have to wait some other commit ?
bridgman: before I try to understand those white bars every 90-ish pixels I guess I should check that they're not part of your desktop pattern
PWMx: brigdman: With EXA+DRI there is checkerboard as background, missing icons (black boxes) and wrong or corrupted fonts .. (in KDE4.2)
bridgman: ech0s7; are you running VirtualBox ?
ech0s7: no bridgman
ech0s7: only daemon
ech0s7: vboxdrv
ech0s7: excuse me
ech0s7: kernel module
ech0s7: $ lsmod | grep vbox
ech0s7: vboxdrv 1698540 0
bridgman: i'm just guessing at what could be different on your system
ech0s7: also you have rv620 '
ech0s7: ?
ech0s7: i'm on x64
PWMx: Just now I'm running DRI + none. This is OK but slow and tears. (And can run r600_demo: draws tris but EXA tests seem to fail.)
bridgman: none=NoAccel ?
ech0s7: bridgman: i have to remove vboxdrv and retry ?
bridgman: can you guys try reverting the last commit (the overlapping blit optimization) ?
ech0s7: bridgman: i have the latest commit
bridgman: I'm only guessing at vboxdrv right now, can't say I have any reason to think it's the problem
PWMx: Yes, AccelMethod none & shadowfb are OK.
ech0s7: 20min ago i have recompiled from git
ech0s7: bridgman: how can i revert the last commit ?
bridgman: understood; I'm trying to make sure that the performance optimizations aren't causing your problems
bridgman: actually maybe "revert" isn't the right command, hold on...
ech0s7: yes
ech0s7: git revert [options]
bridgman: ok; anyways, can you folks try building without the last commit ?
bridgman: don't need fresh logs or anything, just see if the screen is any different
bridgman: dragging & scrolling will definitely be slower
ech0s7: ok, i don't know how revert the last commit
_kopsu_: i know that there is corruption with images atleast on commit that was before latest... tried it yesterday
_kopsu_: some images like browsers icons (back/refresh) on toolbar were messed half...
ech0s7: bridgman: i have compiled yesterday at 10:00 pm, and same situation of today
PWMx: brigdman: It didn't work even before those optimizations. (And I did seem to have more corruptions than others even back then.)
bridgman: the problem is that there have almost always been performance optimizations in the tree; we back them out when problems are found but new and better optimizations go in before we have a chance to confirm that the unoptimizied code is solid
bridgman: the second-last commit fixed a cache flushing bug so even yesterday
bridgman: 's code wouldn't have necessarily worked
bridgman: you really need "everything except the last commit" to have the best chance of working
bridgman: and to see whether the corruption you are getting is related to optimizations or something else
ech0s7: ok bridgman
ech0s7: what commit i have to do ?
bridgman: yangman's new optimization code looks pretty good although I haven't done a walkthrough or anything
bridgman: actually, there is a line where "return FALSE" was commented out; might be enough to just uncomment that
bridgman: take a look right at the start of yangman's latest commit, in r600_exa.c
bridgman: around line 680
ech0s7: line 666
ech0s7: ah okk
ech0s7: line 680
ech0s7: accel_state->planemask = planemask;
ech0s7: //return FALSE;
ech0s7: bridgman: uncommented
ech0s7: compiled, restarting X
PWMx: One sec - I'll ty too ..
bridgman: this is too much like "cut the red wire" for my liking ;)
_kopsu_: just waiting for the explosion ;)
bridgman: yeah, I always get worried when they don't come back ;)
bridgman: I don't want to read about it in the news or anything... "driver error levels city block
bridgman: "
ech0s7: bridgman
ech0s7: not solved
bridgman: yo
bridgman: ok, any noticeable difference ?
ech0s7: i'm upload screen
ech0s7: http://g.imagehost.org/view/0049/Schermata-1
bridgman: can you confirm that performance is slow on drags & scrolls so we know we hit the right code ?
bridgman: I'm going to look through the rest of yangman's commit to see if we missed anything
ech0s7: bridgman: the desktop is not usable
PWMx: For a second it looked like it was going to work. Then corruptions hit everywhere ..
ech0s7: if i try to drag and drop some icon, it became black
ech0s7: bridgman: $ cat xorg.log dmesg.log |nopaste
ech0s7: http://rafb.net/p/MjxE1Y46.html
PWMx: So, in my case it's probably something different than the optimization trick..
Ge0rG: however, it seems that with the last commits in r6xx the shadowfb copying became as slow as exa was before
PWMx: I have also those black icons (among all other wierd corruptions).
_kopsu_: interesting that i have quite good performance and no corruptions with the latest commits. but then again i have R700..
ech0s7: rv6xx series is unlucky :)
bridgman: seems like it; I'm not 100% sure that uncommenting that one line properly disabled the "same surface" operations but at first glance it seemed right
ech0s7: bridgman: if you say me how came back to right commit, i do
bridgman: Ge0rG; shadowfb copying ? with DRI disabled and AccelMethod forced to ShadowFB ?
bridgman: ech0s7; I'm not sure myself and don't want to muck up your tree; I would just re-comment that line, rebuild, and let's go from there
ech0s7: ok bridgman
bridgman: IIRC we've only seen problems with 610/620/780 with the latest code, 630/635 seem to be OK
bridgman: anyone seeing something different, ie good results with 610/620/780 or problems with 630 and up ? I think some people were getting good results with 780 but not 100% sure
Ge0rG: bridgman: "RADEONHD(0): Selected ShadowFB." without config file parameter. option DRI is set, but should not have any effect. the only other reason I can think of is that I didnt reboot since starting X with EXA on the last time
ech0s7: bridgman: i'm compiling almost all days, and exa+dri on rv620 has always caused the same monitor corruption
bridgman: ahh, so accel method is defaulting to shadowfb even when DRI is enabled ? interesting...
Ge0rG: bridgman: yup
bridgman: understood, looking for what other people with similar hardware are seeing
bridgman: once we find a pattern it gets a lot easier to guess what the problem might be
bridgman: ech0s7; do you get the white horizontal lines again after recompile ? and are the black icons on drag gone ?
ech0s7: ok
ech0s7: bridgman: with return FALSE not commented, the horizontal lines are the same color of backroung image
ech0s7: with return FALSE commented the horizontal lines are white
ech0s7: now i'm recompiling
yangman: weird
bridgman: yeah, I saw that in your screenshot; looks like they come from somewhere else in the image but haven't found where; trying to see if they're "from wrong place" or are transformed somehow
bridgman: yangman; yeah ;)
bridgman: so far your patch is not implicated but the corruption is *different* when we comment out that line
yangman: the only thing I can suggest is go through each of the R600Prepare* functions and uncomment the return FALSE lines in each, and see which one stops the corruption
ech0s7: i have seen that in xorg
ech0s7: i have Composite Enabled
ech0s7: ok yangman
ech0s7: now i do
yangman: have you tried disabling composite?
yangman: that's where my guess is
ech0s7: now i have disabled it
yangman: but I don't know what code paths compositing will hit
Ge0rG: is there a bug tracker for radeonhd, besides from asking here?
yangman: Ge0rG: bugs.freedesktop.org
Ge0rG: is it worth it to submit bugs for r6xx with EXA enabled, or is it too unstable/experimental anyway? ;)
yangman: if it's not something that's already been reported, by all means do
ech0s7: yangman: i have uncommented 3 return FALSE in r600_exa.c
ech0s7: at line 111, 666, 680, 1267
ech0s7: all this are of some R600Prepare* functions
ech0s7: solved monitor corruption
ech0s7: pheraps because i have also removed composite enable from xorg.conf
yangman: now try it with only the one at 1267 uncommented
ech0s7: ok
ech0s7: ok
ech0s7: yangman: with only 1267 uncommented > monitor corruption
yangman: huh
yangman: hmmm
bridgman: need to run for a few hours, bbl
yangman: what's the setup? probably easier to try and debug this if I can reproduce it
yangman: metacity with compositing enabled or some other wm?
ech0s7: yangman: i haven't composite enabled
ech0s7: i'm using metacity and gnome
ech0s7: with murrine engine
yangman: hm.
ech0s7: but i have corruption also in gdm
ech0s7: before to load gnome
yangman: well, 111, 666, and 1267 controlls whether SolidFill, Copy, and Composite are accelerated or not
yangman: respectively
ech0s7: actually this is my r600_exa.c
ech0s7: $ cat r600_exa.c | nopaste -l C
ech0s7: http://rafb.net/p/jRBEO677.html
Ge0rG: system freeze. I think I give up for today :)
ech0s7: yangman: i have to retry to uncomment some other ?
yangman: try uncommenting the one at 111, but leave 666 and 1267
ech0s7: ok
ech0s7: 680 commented or not ?
yangman: leave it commented
yangman: it's not relevant for us
ech0s7: ok
ech0s7: yangman: monitor corruption with this .c: http://rafb.net/p/DPo9eR30.html
PWMx: In my case commenting or un-commenting those lines didn't really help. (If it made any difference it wasn't too pronounced.)
yangman: ech0s7: lets uncomment 1267 as well. so, only 666 is commented
ech0s7: ok
PWMx: I noticed when I move cursor back and forth over icons on a list there is cyclic corruption. (I.e. Same wrong pieces of texture is repeatedly cycled together with the right one.) Cache issue ?
yangman: PWMx: does the cursor interaction do something visually?
ech0s7_: yangman: monitor corruption
ech0s7_: $ cat r600_exa.c | nopaste -l C
ech0s7_: http://rafb.net/p/dV4zto45.html
PWMx: yangman: Yes, but it's because of KDE4.2 . Now without EXA rmb empty desktop brings up meny where the selection is darkened and follows mouse.
PWMx: With EXA there wasn't this darkened area but changing corrupted icons instead. Also icon at the uppermost corner cycles via black box. (That color highlighting plasma thingy ..)
ech0s7: yangman: what i have to do ?
yangman: ok, so we have: no accel: OK, composite off: corruption, copy only: corruption
ech0s7: yes
yangman: is the places where corruption happen consistent?
yangman: and you said it happens in gdm as well. is it the same corruption pattern?
ech0s7: on button...
ech0s7: on icon
ech0s7: on panel
yangman: how about the pattern itself? on a fresh gnome startup
ech0s7: in gdb the font are corrupted
ech0s7: gdm
ech0s7: s/gdb/gdm
ech0s7: if you would i take a photo
ech0s7: ok?
yangman: sure
ech0s7: ok
ech0s7: 2 min.
ech0s7: yangman: http://g.imagehost.org/0034/08022009.jpg and http://g.imagehost.org/0171/08022009_002.jpg
yangman: hm
yangman: lets try the solidfill only and composite only cases
yangman: so, everything but 111 uncommented, then everything but 666 uncommented
yangman: er, wait
yangman: everything but 111 commented, and everything but 666 commented
yangman: is that right? my brain decided to suddenly go dumb
yangman: make the "return FALSE" lines disable all but one of the acceleration methods ;)
ech0s7: so like this ?
ech0s7: $ cat r600_exa.c | nopaste -l C
ech0s7: http://rafb.net/p/bvYUZm95.html
yangman: uncomment 111 as well
yangman: that would give is composite only
ech0s7: ok
ech0s7: $ cat r600_exa.c | nopaste -l C
ech0s7: http://rafb.net/p/WlcSEF41.html
yangman: right
ech0s7: yangman: ok
ech0s7: seems no corruption
yangman: ok
ech0s7: i have composite disabled
ech0s7: in xorg
ech0s7: yangman: mouse pointer has changed image
ech0s7: instead of normal pointer mouse i have icon of gedit
yangman: .. mouse pointer changed?
ech0s7: yes
ech0s7: corrupted
yangman: does it change to something else in the cases where it should? resize window, etc
ech0s7: yes
ech0s7: change, but return to corrupted image
yangman: does it change to the correct cursor image or something else random?
ech0s7: if i take a screenshoot it seems normal
ech0s7: resizing windows it change to correct cursor
yangman: ok
yangman: bizzare
ech0s7: yes
ech0s7: :)
ech0s7: now i do to eat
yangman: is there the normal desktop corruption?
ech0s7: no, no desktop corruption
yangman: ok
yangman: lets try solid only after you get back, then. I'm suspecting that should be issue-free as well
ech0s7: ok
nanonyme: Yay, finally found the warranty receipt.
ech0s7: yangman: i'm came back
yangman: cool. lets try the solidfill only case, then
yangman: 111 commented, 666 and 1267 uncommented
yangman: I'm suspecting there's something going on with the copy code. trying all the cases just so we're covering everything
ech0s7: ok
ech0s7: done
ech0s7: yangman: monitor corruption
yangman: huh
yangman: can you pastebin the code again
ech0s7: ok
ech0s7: $ cat r600_exa.c | nopaste -l C
ech0s7: http://rafb.net/p/N0lzys95.html
yangman: hm.. ok
yangman: so we have Composite-only: OK, copy-only: corruption, and fill-only: corruption
ech0s7: yes
yangman: does corruption get worse when dragging windows around?
ech0s7: yes
ech0s7: of course!
yangman: notice anything different in the corruption when dragging in certain directions?
ech0s7: N-W
ech0s7: Up-Left
ech0s7: now i return to latest git ?
yangman: yeah
yangman: dragging up-left corrupts differently?
ech0s7: i'm not sure, but seems of yes
ech0s7: if you would i retry
ech0s7: if you would i can take a video
yangman: please do. left-right, up-down. the directions that follow the axis would be useful
ech0s7: yangman: but with latest git ?
yangman: yeah. pretty sure it's copy, and solidfill shouldn't affect things too much
ech0s7: yangman: ftp://ech0s7.serveftp.org/08022009.mp4
ech0s7: yangman: have you seen ?
yangman: oh wow. ok
yangman: that's a lot worse than I thought it was
ech0s7: good
ech0s7: :)
ech0s7: yangman: if you want that I make some other test, don't worry you say it to me, I return to work
yangman: what's the corruption when only solidfill is enabled?
yangman: just fills chunks of the screen with a solid colour?
ech0s7: yes
yangman: ok
ech0s7: yes both question
ech0s7: but not only when solidfill si enabled
ech0s7: also when copy is enabled
yangman: seems like there's a quirk with that GPU the setup code isn't handling properly
yangman: agd5f would probably have a better idea. I'm not familiar with the relevant functionalities yet
ech0s7: ok
Zajec: ech0s7: i experience something very similiar to the corruption I saw on beggining of your video
Zajec: when I put mouse over any icon, I see weird-colored rectangle from top-left corner to my cursor
Zajec: it's 34xx Mobility here, Sony Vaio FW11S notebook
Zajec: I also experience lockup every time i start some application in KDE, I'm quite sure it's something about setup code
Zajec: when you start moving window... then I can see these rectangles
yangman: both source and destination addresses are out of wack
yangman: I'm guessing the horizontal corruption is gnome-panel coming in. it actually does a "drop in" animation which causes EXACopy to trigger
yangman: then all hell breaks loose once an entire window is moved
yangman: http://g.imagehost.org/view/0049/Schermata-1
yangman: so, just looking at that again, we have horizontal lines, which seems to be copy corruption
yangman: then the big white block is probably solidfill due to notification
nrg-: lockup when resizing window in vdr
FuzzyTheBear: when we got dri setup .. ex a 1650 r5** with a 2gig athlon 2400+ .. should we be able to play ex tuxracer ?
nrg-: what is tux racer?
FuzzyTheBear: tux the penguin .. going down snowy mountains ..
FuzzyTheBear: or any gl game for that matter .. like a gl pool game or some such ?
yangman: try it
FuzzyTheBear: i did .. and cant .. i get a frame every 2 3 seconds at best
FuzzyTheBear: which i find rather low
FuzzyTheBear: :)
MostAwesomeDude: FuzzyTheBear: Sounds like your Mesa's not set up right..
FuzzyTheBear: glxgears give 120 fps or so
FuzzyTheBear: mesa ?
FuzzyTheBear: im all ears and opened to suggestions
FuzzyTheBear: media-libs/mesa 7.3 installed
FuzzyTheBear: mesa progs is the same
MostAwesomeDude: Hm. What's glxinfo say about rendering?
FuzzyTheBear: it's there
FuzzyTheBear: direct rendering: Yes
FuzzyTheBear: server glx vendor string: SGI
FuzzyTheBear: server glx version string: 1.2
MostAwesomeDude: Which renderer, though?
FuzzyTheBear: OpenGL vendor string: Mesa Project
FuzzyTheBear: OpenGL renderer string: Software Rasterizer
FuzzyTheBear: OpenGL version string: 2.1 Mesa 7.3
MostAwesomeDude: Yeah, that's not right.
adamk: FuzzyTheBear, What video card?
adamk: Oh, never mind.
adamk: I see now.
MostAwesomeDude: Try "LIBGL_DEBUG=verbose glxinfo" and pastebin it, please.
FuzzyTheBear: radeon 1650 extreme 512 mb
er0x: do we got any 3d accel on hd3xxx series cards?
adamk: er0x, No.
FuzzyTheBear: ah .. wth .. i see a bunch errors .. i
FuzzyTheBear: ok .. momento .. wont take long
er0x: want to wach movies with this driver :D
yangman: FuzzyTheBear: make sure you enable both DRI and EXA in xorg.conf
adamk: er0x, You might be able to do that with the latest development code in git. It does provide EXA and Xv acceleration.
er0x: switching to git xorg now
FuzzyTheBear: http://pastebin.com/m5d41ff8
adamk: er0x, You need a specific branch of the radeonhd driver to get it working.
FuzzyTheBear: EXA ?
er0x: git says that r6xx-r7xx-support branch dont exist
adamk: fulgas, You are missing the the r300 mesa driver.
adamk: aklsdfjasdlk;f
adamk: FuzzyTheBear, Sorry.. You're missing the r300 mesa driver.
da1l6: er0x: http://www.x.org/wiki/radeonhd:r6xx_r7xx_branch
er0x: i know but git says it dont exist
adamk: FuzzyTheBear, I don't know what distribution you are on, but you should reinstall whatever package provides it.
FuzzyTheBear: the r 300 mesa driver ?? /..\ ??
da1l6: er0x: it does, please paste the output of git checkout -b r6xx-r7xx-support origin/r6xx-r7xx-support if it dosnt work for you
adamk: FuzzyTheBear, That's what I said :-)
FuzzyTheBear: yes but im none the wiser for it :DDDDD
adamk: FuzzyTheBear, Well what distribution are you using?
FuzzyTheBear: gentoo .. let me make a quick search
adamk: It's probably just provided by the mesa port.
adamk: Also, make sure you run eselect to select the correct driver.
adamk: Not sure if that's necessary if you only have one installed, but it can't hurt.
yangman: FuzzyTheBear: you need VIDEO_CARDS="radeon" in your make.conf
yangman: FuzzyTheBear: r5xx uses the same Mesa driver as r3xx
FuzzyTheBear: VIDEO_CARDS="radeonhd" here
FuzzyTheBear: ok .. explains it
nanonyme: Are radeon and radeonhd separate there, btw?
FuzzyTheBear: R ] x11-base/xorg-server-1.5.3-r2 VIDEO_CARDS="radeon* -radeonhd*"
FuzzyTheBear: hmmm i dont like the looks of this
nanonyme: Might put them both in then.
FuzzyTheBear: yep .. let me give that a spin
nanonyme: Then pick the right driver via xorg.conf if it complains.
yangman: FuzzyTheBear: enable both
yangman: FuzzyTheBear: or you can enable it for Mesa only
nanonyme: Shouldn't harm to have both anyway. At worst you just have to override X autoconfiguration.
FuzzyTheBear: im not too sure the meaning of the * here : media-libs/mesa-7.3 VIDEO_CARDS="radeon*"
FuzzyTheBear: if that means radeon and radeonhd ..
FuzzyTheBear: what the heck .. im going
nanonyme: FuzzyTheBear: Probably implies a change.
FuzzyTheBear: presses the big red button
yangman: FuzzyTheBear: it means the flag for "radeon" changed since the last emerge
FuzzyTheBear: --with-dri-drivers=,swrast,radeon,r200,r300
FuzzyTheBear: i act in blind faith here cause this is all news to me .. it's reemerging 5 packages...
FuzzyTheBear: up to now radeonhd was stable. i hope this works :) will take some time .. bb in a bit
FuzzyTheBear: what a mess !
FuzzyTheBear: x11-drm-20080710 build fails ..
FuzzyTheBear: disable DRM in the kernel config
FuzzyTheBear: do i really want to do that ?
yangman: FuzzyTheBear: yes. external kernel modules would conflict with the kernel-bundled one. this is standard for all kernel module ebuilds
yangman: FuzzyTheBear: you shouldn't need x11-drm anyway. support is already in 2.6.27
FuzzyTheBear: ric bin # ls /usr/lib/dri/r300_dri.so
FuzzyTheBear: /usr/lib/dri/r300_dri.so
FuzzyTheBear: that's there ..
FuzzyTheBear: err .. restart x ?
FuzzyTheBear: why not ?
FuzzyTheBear: :) bb in a min
FuzzyTheBear: libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
FuzzyTheBear: drmOpenDevice: node name is /dev/dri/card0
FuzzyTheBear: drmOpenDevice: open result is 4, (OK)
FuzzyTheBear: .. that error's cleared
FuzzyTheBear: Gentlemen ..
FuzzyTheBear: 9131 frames in 5.0 seconds = 1826.142 FPS
FuzzyTheBear: i was at 120 fps minutes ago
FuzzyTheBear: no kernel rebuild either ..
yangman: you were only missing the correct mesa component
nootoyahora: hello to everyone
nootoyahora: I'm usig debian testing, and I like to know if radeon HD 3870 isi supported
nootoyahora: I have read the wiki and it seems to be so, right?
nanonyme: Depends on what you mean by supported.
nanonyme: Supported as in basic functionality, yeah.
da1l6: nootoyahora: Basic 2D, randr: Yes, EXA, XVideo: Experimental, 3D: no
nootoyahora: by "basic" do you mean 2D?
nanonyme: By basic we mean non-accelerated 2D.
nootoyahora: mmmmmmmmmmm
nootoyahora: waht bad
nootoyahora: which is the highest 2D-accelerated radeon?
nootoyahora: in the wiki does not get clear about the level of accelration
nanonyme: Note though that the as da1l6 said, the 2D acceleration is currently experimental.
nanonyme: So it does exist, it's not just yet stable and thus might be wrong to say it's supported as such.
bridgman: although it seems to be working well on 3870, at least for the few reports we have so far
nootoyahora: nanonyme, what's XVIdeo? ( I thougt it was an extnsion for playing video...)
da1l6: "Accelerated" 2D is slower than non-accelerated 2D for me (hd2600).
nanonyme: da1l6: With latest git?
da1l6: yes
bridgman: yep, XVideo (or the Xv API) is for video render acceleration
nanonyme: Iirc yangman added some optimizations, did they improve the situation any?
bridgman: colour space conversion, scaling etc...
bridgman: they made it go faster without any obvious corruption
da1l6: nanonyme: acually git from yesterday
nootoyahora: I'm doing workstation job: programming, browsing and such (maybe a little GIS)
bridgman: GIS would probably need 3D, wouldn't it ?
nootoyahora: I need a card which is supported in 2D and which runs CAL from ATI, only that
bridgman: the rest is probably fine even without 2D acceleration
bridgman: CAL requires the proprietary drivers - it's built around the shader compiler in Catalyst
nootoyahora: bridgman, GIS in 3D? why? you only need to rasterize 2D, maps, you don't want to render it in beautiful 3D ;D
bridgman: I agree, but a lot of them seem to use GL anyways
nootoyahora: bridgman, I know that i need catalyst in roder to get CAL working, but for the "day to dy" work I do prefer working with a free driver
airlied: because its faster :)
bridgman: that said, it only has to support your GIS, not everyone else's ;)
airlied: and lots more standard.
nootoyahora: bridgman, if my GIS works uopn openGL... it only needs to support openGL ;D
bridgman: for most day-to-day use you would probably find the open drivers fast enough without any 2D acceleration - they both have "shadowfb" which is surprisingly fast
nootoyahora: which is the highest radeon with opeGL support? (in hardware I mean)
nanonyme: r5xx?
da1l6: that would be the r500 based cards
da1l6: radeon X1xxx i think
nootoyahora: I don't know, if I'd do i weren't here asking it ;D
bridgman: yep, 5xx is the highest with OpenGL support today
nootoyahora: x1xx? where I can buy one of them???
bridgman: look for something like X1650 or X1900/1950 if you can
nootoyahora: I thougt that there was some GL support in higher radeons...
bridgman: be careful with the price though, some stores are still selling them at full price from a few years ago
nanonyme: bridgman: Yay, found the warranty receipt today. :) Will be taking the card back to the shop tomorrow.
bridgman: not in the open source drivers
bridgman: nanonyme; great
nanonyme: Apparently it has a 36 month manufacturer warranty.
bridgman: even better
bridgman: nootoyahora
nootoyahora: yes?
bridgman: nootoyahora; the 690 is fully supported but that has 4xx-class 3d
bridgman: sorry, pressed
nootoyahora: does not matter ;D
nanonyme: Out of interest: why do you use semicolons there? ^^
nootoyahora: 690 is the RS690? the RV690? or the R690? (I get mad about ATI's numeration)
nootoyahora: 4xx-class means 4thclss support?
nootoyahora: (poor support I mean)
bridgman: nanonyme; one less key press (no shift), so saves time ;)
bridgman: just fewer features in the future; the 4xx 3D engine didn't have dynamic flow control in the shaders, for example
bridgman: also smaller maximum texture size which affects multi-monitor Compiz
nanonyme: bridgman: Right, you have a different keyboard layout than me then. For me the simple key would be ','. (Personally using autocompletion for names anyway so the IRC client decides the separator)
bridgman: if you download the 5xx acceleraction guide the first chapter summarizes the differences
bridgman: ahh.. ever since I first saw "Terminator" I haven't let my computers think for me ;)
nanonyme: Btw, could RV670 theoretically handle two Full HD monitors?
bridgman: actually it was probably before Terminator; Karn Evil 9 third impression
Ge0rG: that's becoming harder with every software update. the programmers seem to make their software designed for stupid users :(
bridgman: I think so; certainly there's enough output and display bandwidth
nanonyme: Right. Just thinking for the future.
bridgman: if you mean playing back two simultaneous full-res HD video streams it would be tight but probably doable
nanonyme: I probably can't afford more than one for quite some time anyway.
bridgman: the CPU would have to do a bunch of work
nanonyme: AH.
nanonyme: s/H/h/
bridgman: assuming you have two DVI connectors, not DVI+VGA ;)
nanonyme: I have two DVI connectors, yes.
nootoyahora: and which one would be best for two fullHD monitors?
Ge0rG: there is a new mplayer/ffmpeg multi-threading branch. playing back h264 1080p on a quad-core phenom at 1200mhz with <40% load per core
bridgman: that's pretty good; so a dual-core should be able to squeak by
Ge0rG: bridgman: and that was using shadowfb with no xvideo ;)
nanonyme: Heh. My current CPU might have trouble handling that...
bridgman: nootoyahora; until we know exactly how open source video decode is going to end up, 7xx is safest
nanonyme: It's only AMD64 3500+.
bridgman: sorry, are you talking about 2 HD video streams or just driving 2 HD monitors ?
nootoyahora: I have a p4@3GHzHT and a radeon 9250 AGPx4...
nootoyahora: bridgman, driving two monitors (at fullHD resolution)
bridgman: any of the cards will do that, but I think you're close to being bandwidth limited on HD2400/HD3450/HD43xx
bridgman: memory bandwidth
nootoyahora: so a HD38xx would make it rght?
bridgman: yep, no problem
nanonyme: Heh, the RV670 one I was talking about was HD3870 iirc. :)
nanonyme: (I've trouble remembering them both at the same time)
nootoyahora: me too
nootoyahora: maybe a bit of off-topic but.... better and radeon? or an intel 4500?
bridgman: I'll stay out of this one, you know what I think ;)
nootoyahora: why would you stay away?
bridgman: I work for AMD
nootoyahora: ah
nootoyahora: I did not know, really?
nanonyme: nootoyahora: Well, I only found out myself after reading his posts on Phoronix forums.
nanonyme: So undertandable. :)
nootoyahora: nanonyme, erh, what?
nanonyme: nootoyahora: bridgman's title in Phoronix forums says he's from AMD. I don't remember the exact wording.
bridgman: I think it says "AMD Linux". There have been requests to change it to something more obvious, like "Official AMD Open Source Graphics Weenie" or something
nanonyme: ;)
nootoyahora: nanonyme, ah ok, then maybe I should read that forums in order to know what he thinks about intel 4500...
nootoyahora: hahahahaha
nanonyme: nootoyahora: I suspect he might refrain from having public opinions on that kind of stuff.
nootoyahora: I understand that
nanonyme: A bit tricky thing, that. You have to keep in mind when doing all posts that you don't break any NDA's and someone could interpret everything you say as public announcements from AMD.
nootoyahora: I know, and I understand it
nootoyahora: but I'm onily asking quetion in order to choose my new grahpic crds, for work and for home
bridgman: the 4500 (and all current Intel graphics products) are IGPs, so they would only be used on a motherboard with an Intel CPU
bridgman: you end up kinda having to compare the platform if you're going with integrated graphics - you can't use an AMD chipset with an Intel CPU and vice versa
nootoyahora: bridgman, I know it, and i don't like it,but ti seems to be the better supported graphic solution, right? (I would like to choose ATI, but...)
bridgman: discrete graphics is different - AMD, NVidia and VIA are pretty much the only players these days
nanonyme: I suspect what you'd want is do some feature mapping to figure out roughly what you want, then try to find out benchmarks and price comparison to figure out actually which one is the best.
bridgman: apologies if I forgot someone ;)
nanonyme: (Best as in gives you the most with the least price)
bridgman: yeah, generally the ATI/AMD integrated graphics have more processing power
nootoyahora: no no, the platform is ok whatever it be, the problem is choosing a grapchis solution... disrete grahpics are not working
bridgman: just curious, what do you mean by "discrete graphics are not working" ?
nootoyahora: I mwean, they have almost no free-drivers
nootoyahora: I cannot go to a store and pick up a low-end card and get it to work wirh free-drivers
bridgman: that was a lot more true 2 years ago
nootoyahora: it's a nightmare
nootoyahora: yes, in the past was even worse
nanonyme: And it's getting even less true every week.
nootoyahora: but today is noto good, ins only "less worse"
bridgman: it's funny, from the developer's POV the discrete cards are easier to support than integrated
nootoyahora: maybe is getting less true
bridgman: in a few months it won't be true at all
nootoyahora: but the question is that I'm scratching my head about which card buy... an element which ciosts less than 100$'s
nootoyahora: bridgman, maybe, but I need to make a configuration for tomorrow, for my boss...
nanonyme: Eek.
bridgman: ok for tomorrow pick up a cheap 5xx board, look for an X1650 or similar
bridgman: that has out-of-the-box support in recent distros, eg Ubuntu 8.10 "just works"
bridgman: any of the new chips would probably be fine unless you need GL support; that will be a couple more months
nootoyahora: the problem is that it has to be ready available from local suppliers,
nootoyahora: mmmmmmmmmmmmmm
nootoyahora: a new chip which works in 2D tomorrow is accpetable
bridgman: what part of the world ?
nootoyahora: bridgman, Spain
bridgman: ok, hold on
bridgman: are you buying from local dealer or online ?
nootoyahora: so if I can choose a card with works tomorrows with 2D, I can wait for the 3D support in a few months, no worry about that
nootoyahora: bridgman, local dealer, and I'm not buying it directly, they are the IT guys which are buyying it... (you know, "corporate policies")
bridgman: understood; if an HD4650 fits your budget that's what I would go for
bridgman: I think they're maybe $90 in NA
nootoyahora: 90? in my country are mor or less about 200?...
nanonyme: Well, yeah, hardware tends to be quite a bit more expensive in Europe than in the USA...
bridgman: even today ? I thought that got fixed...
nootoyahora: i was thinking more about a HD3870, it is about 90?, it can be gett with passive cooling and it works with CAL (we want to give it a try)
nootoyahora: bridgman, yeah, it got "fixed" the y have fixedprices :P
bridgman: 4650 should be about the same price as 3870; either would be fine
bridgman: I'm surprised you can do a passive 3870 though...
bridgman: that's why I suggested 4650, should be same price & lower power
nanonyme: bridgman: My 3870 cost about 143 euros last Summer.
nootoyahora: 4650 cannot do double preccision floats on CAl... we should go to a 4850...
bridgman: whoops, you're right
bridgman: yeah, for DP you need 38xx or 48xx
nootoyahora: that is
nootoyahora: that's why I'm so focused asking about that two specific lines ;D
nootoyahora: I need to get a graphic card... ad maybe a CAL crd (to try it if there is some time left)
bridgman: the driver programming is very similar for 38xx and 48xx; we have 2d and video acceleration running for both today in the 6xx-7xx support branches
bridgman: if you go with 38xx or 48xx you can do both on the same card
bridgman: CAL is just another client for the 3D engine, alongside GL (and DX on Windows)
bridgman: be right back...
nootoyahora: so both of them (38xx and 48xx) would wokr out of the box for 2D, ad in a few months we would have 3D free dirvers? (I don't mind having CAL propietary)
nootoyahora: argh
yangman: nootoyahora: yes
Urigeller23: nootoyahora: at least that's the plan, I believe
nootoyahora: mmmmmmmmm
nootoyahora: I can go with that
FuzzyTheBear: yangman : i tried a few games like tuxracer and billiardsGL they freeze the computer ..
nootoyahora: that's all what I need
Ge0rG: I wish r6xx would also mix well with swsusp
nootoyahora: I only need "D done right right know
yangman: FuzzyTheBear: http://bugs.freedesktop.org/show_bug.cgi?id=18097
Urigeller23: I have a HD3850 running with radeonhd right now, basic 2D works without problems..
nootoyahora: what's basic 2D? gui? or waht?
Urigeller23: well, things like xv are only in the r6xx-r7xx support branch
Urigeller23: which you can get easily from git
nootoyahora: I do't need video support
nootoyahora: and I can live woithout it some months
nootoyahora: it is oly a developer workstation
Urigeller23: that's what I meant with 'basic'.. I'm using video :)
yangman: Ge0rG: unresponsive machine to resume?
Ge0rG: yangman: 100% cpu load on all cores in kernel mode, yes
FuzzyTheBear: tryign xorg without exa ..
nanonyme: Urigeller23: Doesn't basic 2D usually mean "modesetting support"?
Ge0rG: yangman: plus, black screen and no way to kill X
yangman: Ge0rG: right, seeing the same thing, although I haven't checked CPU load
Urigeller23: nanonyme: depends on who you ask, I guess
nootoyahora: nd a HD3870 or so can run two monitor in fullHD mode? (not video streams, only 2d graphics)
Ge0rG: yangman: I've got an external LCD displaying cpu utilization ;)
yangman: ah
yangman: neat
yangman: 100% cpu utilization probably means a bad loop somewhere
Ge0rG: yangman: yeah. spares me ssh login when the machine really hangs
Ge0rG: yangman: probably in drm.ko / radeon.ko, because its kernel mode
Ge0rG: yangman: also, it loads up all four cpu cores. no idea how though
nanonyme: nootoyahora: I got the impression it should be able to do that fine and possibly barely even do two Full HD video streams.
nootoyahora: nanonyme, thanks
nanonyme: (With a massive CPU usage)
Urigeller23: Full HD = 1080p?
nanonyme: Heck, 3870 doesn't even have inbuilt MPEG4 decoding so it ought to take quite a bit horsepower from the CPU.
nanonyme: Urigeller23: Yeah.
nootoyahora: fullHD 1920*1080
Urigeller23: thinks it's wierd to refer to ordinary resolutions for non-video applications as "FullHD"
nanonyme: My current display can only barely display 720p at 1:1. :P
Ge0rG: my pc monitor has "fullhd" resolution
nanonyme: (I'm using 1280x1024 and 720p is 1280x720)
nootoyahora: my actual display runs at 1280*1024... but "it's time to change" hahahahahaha
Urigeller23: yeah, mine too.. although if I span it across both monitors..
nanonyme: Urigeller23: Meh, I'd just use scaling there.
nanonyme: Monitor borders are annoying.
Urigeller23: 1280x1024 + 1680x1050.. dammit, FullHD by 30 vertical pixels off ^^
nootoyahora: hahahahahahaha
nootoyahora: it's time to change for you otoo my friend ;D
Urigeller23: well, I'm fine with my current setup ;)
bridgman: nanonyme; "2D" used to mean "using all the 2D hardware that every chip has, you know, video and XAA-like acceleration and that stuff"
bridgman: then 2D and video started using the 3D engine and things got real confusing ;)
nanonyme: Ah.
bridgman: I never included video in "2D" myself but a lot of people did
bridgman: and then when we took out 2D hardware and overlay video processing things got REALLY confusing
Ge0rG: how good were the times when the only acceleration a gpu provided was palette color cycling...
bridgman: so now we talk about "modesetting" and specific acceleration APIs, and try not to talk about anything ambiguous if possible ;)
bridgman: ah yes, back in the days of cool screensavers in 256-colour
nanonyme: bridgman: Well, different people consider different kind of things "core functionality". I might personally go even so far that I'd put OpenGL support to core functionality so no card that can't do that in the GPU isn't supported. ;)
bridgman: it takes a huge amount of processing power to do that with shaders ;)
nanonyme: s/isn't/is/
bridgman: but you have OpenGL; it's just using that swrast hardware ;)
nanonyme: But surely swrast is its own separate driver so what it has can't be included in telling what eg radeonhd supports?
yangman: I wish suspend/resume were straight forward...
bridgman: when Mesa started doing direct rendering with software rasterization that was another big dollop of confusion; for years the rule of thumb was "direct rendering = hardware acceleration" even though there was no reason for that
airlied: yangman: it mostly should be :)
airlied: yangman: if drivers are where they are supposed to be
Ge0rG: yangman: maybe enabling debug in drm.ko will help locate the issue?
Ge0rG: at least you can ssh in when X dies
yangman: well, I'm just pondering about how I can even get useful information out of hte failed resume
nanonyme: bridgman: Yes and we got the idea of finding out if there are rendering problems by checking the direct rendering string. (Which in the end turned out to be based on the false assumption)
yangman: Ge0rG: does ssh still work on the failure cases?
nanonyme: As in, nowadays the card can still be using slow software rendering while the string says yes. :)
Ge0rG: yangman: it does for me, two out of three times
hatseflats: evening everyone
nanonyme: I tried to remind people on eg #winehq that you can't trust that anymore.
yangman: ok, that's a start
bridgman: nanonyme; I guess the decision to enable sw direct rendering happened the same time that the fastest software renderers started outperforming the slowest hardware accelerators
hatseflats: I'm having a weird problem with my X sessions, it seems that 'sometimes' X only recognizes 1 monitor, and sometimes both my monitors
yangman: I haven't just gone and tested this myself because it takes a while to reboot the hardware
hatseflats: the distinction seems to be completely arbitrary, and I have no idea what or who I should blame or what to do to fix this
hatseflats: any ideas?
nanonyme: bridgman: Yeah, I guess. Still, swrast is *way* too slow for any real game usage.
Ge0rG: yangman: do you need debugging support?
bridgman: some day I want to fire up Quake in 320x240 with software renderer and see if it is faster than the old Voodoo cards
nanonyme: Might be. :)
Ge0rG: probably you can play quake in software rendering at fullhd with current cpus ;)
Ge0rG: at least quake1
nanonyme: bridgman: Wasn't OpenGL support added to original Quake as an addon?
Ge0rG: brb. hibernatin'
yangman: Ge0rG: I guess I'll let you know? I've not actually hacked on kernel modules before
biker_rat: I am having trouble compiling git on archlinux. Has anyone here experience with this?
da1l6: yes
nanonyme: Egh, just remembered I probably have to learn how to compile Mesa as multilib..
biker_rat: any obscure packages I need to install, I get an error.
da1l6: what version are you trying to compile?
biker_rat: r6xx-r7xx-support
biker_rat: amd64
bridgman: nanonyme; yes, I think so.. first glide, full GL later if at all
nanonyme: Btw, am I the only one who regards ./configure --help|less a pun? ^^
nanonyme: (Probably not a planned one but an accidental)
hatseflats: heh, no nanonyme, not only you :)
biker_rat: r6xx_accel.c: In function ‘R600CPFlushIndirect’:
biker_rat: r6xx_accel.c:133: error: implicit declaration of function ‘RHDDRMFDGet’
biker_rat: r6xx_accel.c:133: warning: nested extern declaration of ‘RHDDRMFDGet’
biker_rat: it stps there
nanonyme: bridgman: It seems to have --enable-32-bit and --enable-64-bit. I'm really hoping it's enough to just compile with both on to get multilib. :)
Ge0rG: yangman: my dmesg is flooded with (mostly): [drm:radeon_freelist_get] done_age = 0
da1l6: biker_rat: does ./configure enable DRI?
da1l6: r6xx-r7xx compile doesn't work without
biker_rat: no
biker_rat: dall6 what do you think I'm missing if configure says dri is not enabled?
da1l6: damn, forgot the dependencies
da1l6: anyway, do you have r6xx-r7xx-support branch of drm already installed?
biker_rat: yes
Ge0rG: yangman: http://rafb.net/p/dHs20v77.html if that helps
yangman: Ge0rG: thanks
da1l6: biker_rat: try instslling glproto package
yangman: spares me from doing this myself :)
yangman: Ge0rG: so the last line just keeps repeating forever?
Ge0rG: yangman: until I kill Xorg
da1l6: biker_rat: and xf86driproto
yangman: ok
Ge0rG: kill -9 :>
Ge0rG: from time to time, it overflows the klog buffer
biker_rat: xf86driproto was the one. Much thanks. I am going to try it out now.
Ge0rG: yangman: around the kill time, there were also the following lines in the log: http://rafb.net/p/NFE4Aw83.html
Ge0rG: the comments for radeon_freelist_get() suggest that it could deadlock...
Ge0rG: there is even an out-commented version of the function with less complicated logic
yangman: Ge0rG: adding some more debug into r600_cp_init_ring_buffer is probably a good start. there's a line of debug at 2051 that I'm not seeing in your log
airlied: Ge0rG: that code has worked on the original radeons for many years.
Ge0rG: airlied: good to know. maybe it is used wrong then in r600 code?
airlied: I doubt it, if it hangs its normally because the GPU has crashed
Ge0rG: it does not hang, it rather loops :>
airlied: you are looking at a symptom not the cause
airlied: something is looking for a free DMA buffer after the GPU has hung
Ge0rG: hm... I tried to spawn a new X server on :1 before returning to my session (UseDummyXServer in hibernate.conf), but it did not help
airlied: Ge0rG: a hung GPU isn't usually coming back
Ge0rG: airlied: it does after I kill Xorg and start a new session
Ge0rG: so maybe its not a gpu crash
bridgman: maybe not a hung GPU then ? restarting X won't un-hang a GPU AFAIK
bridgman: or is there new code in there somewhere ?
Ge0rG: there is at least VPU recover in windows :>
bridgman: yeah, but we had to build that into the driver
bridgman: I don't think we have that in fglrx
bridgman: and I'm pretty sure we don't have it in the open drivers yet
bridgman: although glisse and I spoke about it
Ge0rG: it would already help to have KMS or some other way not to f*ck up the framebuffer console every time X dies a horrible death :>
bridgman: yep; kms should help a lot
bridgman: of course you can argue that it just moves the crash-y things into the kernel, but from what I have seen acceleration is much more likely to cause hangs & crashes than modesetting
Ge0rG: oh, guess what. I switched to the console right now, and when I switched back, X crashed and the cpus went up to 100%
Ge0rG: the last message from Xorg log is: "(II) RADEONHD(0): Query for Restore Registers: failed"
yangman: oh, it's a VT switch issue
yangman: I just went into a VT then back, and I'm seeing the same bug as on hibernate resume
biker_rat: with radeonhd +xv xchat locks up x? it just happened twice I have switched to weechat. before the lockup it looked great
biker_rat: dvb with mplayer was much better
biker_rat: scrolling on firefox is almost perfect
biker_rat: lockups suck though
Ge0rG: yangman: yup
Ge0rG: yangman: just figured that out for myself. it took me two reboots ;)
Ge0rG: yangman: maybe related to vesafb console?
biker_rat: the kernel was still up. the mouse was still controlling the cursor
yangman: Ge0rG: VT switch tends to be a DDX issue
biker_rat: everything else was frozen and I couldn't switch consoles or kill x
yangman: biker_rat: master or r6xx-r7xx-support? and what would xchat be doing that would cause graphics to freeze up...
biker_rat: I don't know what is special about xchat, but r6xx-r7xx-support doesn't seem to like it
Ge0rG: I just had a crash with only conky and urxvt as X clients running
Ge0rG: yangman: what does DDX stand for?
biker_rat: maybe it will freeze while I'm typing this in weechat in gnome-terminal and prove me wrong, can't say.
yangman: Ge0rG: I don't actually know. it's the term referring to the X drivers
bridgman: AFAIK there are device-independent (DIX) and device dependent (DDX) portions of X
biker_rat: I have an HD3200 onboard graphics 780G motherboard, what is that RS780?
bridgman: yes, that is rs780
bridgman: 7xx display plus graphics from rv610
Ge0rG: ok, X dies as well when using only vga text mode console
Ge0rG: so its a radeon/drm VT switch problem then?
yangman: yup
biker_rat: I am going to start mplayer rendering full 1080p on the other desktop, and see how long before we crash here
biker_rat: I'm still running x
Ge0rG: maybe a program with only one texture at a fixed position is not as reliable at crashing X ;)
yangman: Ge0rG: you're on a rv770, right?
Ge0rG: yangman: yup
yangman: (II) RADEONHD(0): Query for Restore Registers: failed
yangman: this is probably the root of the problem
Ge0rG: yangman: it was actually when switching _to_ VT 1, not when coming back
biker_rat: I just opened hollywood.com and dragged the window. That pretty much overtaxed my system. Mplayer sound cut out and there was great difficulty rendering the firefox windo, but no x crash..
yangman: hm, wait, n/m, that failure's present on my laptop, too
yangman: false alarm
biker_rat1: That killed it. It was alive when I went to console 1 but when I returned to console 7 where x resides, I got a black screen of death.
Ge0rG: biker_rat1: its not quite death. only your screen is dead, the rest is still ticking ;)
biker_rat1: I have to go watch the Grammys. She who must be obeyed commands it. I drop in again tomorrow.
Ge0rG: bye biker_rat
Ge0rG: yangman: please ping me if you find out something new about the VT switching
Ge0rG: wonders if XvBA will ever appear, and which of the three different APIs will make it in the end
kcodyjr: what's XvBA?
kcodyjr: B A Baracas? "Play the video fool!" ;)
Ge0rG: its ATI's vaporware(?) HD video playback acceleration API
kcodyjr: ok so for the moment yes, it is mr. t's video api. ;)
Ge0rG: maybe it can actually be used by night elf warriors... ;)
kcodyjr: actually i'll cut them a little slack on faith; if it's what I think it is, it's an interface to UVD, and it's decoding, not rendering; hence it'll be tied in all kinds of IP bullshit that actually isn't AMD/ATI's fault in that area
Ge0rG: thats something an enduser with HD ambitions could care less about ;)
kcodyjr: i agree, though possibly for different reasons
kcodyjr: i'm of the opinion that, particularly on a dedicated HD-HTPC, decoding belongs on the CPU
Ge0rG: however, this probably means a major problem for providing video playback acceleration of any kind in radeonhd
Ge0rG: kcodyjr: thats rather irrational. the gpu has much more "video power" per watt
kcodyjr: if you're pushing video through a display large enough to call "home theater", watts simply aren't one of the concerns
kcodyjr: i would prefer to spend all available gpu power on rendering
kcodyjr: otherwise the CPU is sitting there idle
Ge0rG: hm. its actually watts/volume... small boxes need loud fans to keep cool
Ge0rG: the CPU has also very good power saving modes ;)
kcodyjr: which aren't going to get a whole lot of usage when it has to deal with dma flows, app execution, reading off the disc/nic/whatever
Ge0rG: the cpu can render the OSD and demux the container, video decoding and rendering should be done by more-specialized hardware
kcodyjr: also, modern cpu's are a bit of a chump for heat vs grunt
kcodyjr: actually i disagree on two counts there; OSD should definitely be done by the GPU
kcodyjr: and decoding is enough of a moving target, not to mention computationally complex, that full blown CPU's will always have an edge
Ge0rG: full blown cpus have a hard time decoding h264 cabac at 1080p
Ge0rG: so they need all the help they can get
kcodyjr: i have not seen a modern cpu have trouble decoding anything 1080p provided there is full rendering acceleration
Ge0rG: you mean: colorspace conversion and scaling?
kcodyjr: yes
Ge0rG: I have seen cpus choke on bluray / hddvd playback
kcodyjr: haven't seen it personally. do you remember what the cpu was?
Ge0rG: there they have to do disk-io and decrypt AES too ;)
Ge0rG: IIRC it was a c2d at 2ghz
Ge0rG: amd64 has an even harder time
kcodyjr: now, AES is actually something that dedicated hardware can do well, though the jury is still out on whether shader programs will be efficient at it
Ge0rG: I'd really like to see it implemented
kcodyjr: hmm. i had no trouble on a c2d 1.86Ghz
Ge0rG: yeah. VIA has an AES engine in their cpu, which is by orders of magnitude faster than the memory bus... :>
Ge0rG: I assume intel is not putting one in their cores because they want to sell more GHz
kcodyjr: or perhaps they want to sell pcie cards for that
Ge0rG: no regular user is going to by crypto cards :>
Ge0rG: *buy
Ge0rG: adding AES into the cpu core will probably cost near to nada, and allow really nifty things :>
kcodyjr: actually, come to think of it, the AES algorithm is largely based on lookup tables... a GPU might do quite well
Ge0rG: the last time I did gpu coding was a polygon drawing algorithm in pascal for mode 13h... I have no clue about all this modern shader stuff :(
kcodyjr: it's SIMD instructions in batch mode, really
RTFM_FTW: well color-space conversion is pretty trivial to do with shaders
RTFM_FTW: and is likely to give you one of the largest performance wins when it comes to video display performance
kcodyjr: quite agree; colorspace conversion is a no brainer
kcodyjr: it's the early decoding steps that i question
Ge0rG: btw, is the colorspace conversion in the r6xx tree somehow biased? the video gamma looks overly brightÂ
kcodyjr: the LUT branch hasn't been merged, has it?
Ge0rG: there are some LUT related commits, but not a whole branch
kcodyjr: i'll need to review it to know what's going on, and i don't want to let myself get distracted at the moment
kcodyjr: but yangman did do some work that got committed somewhere
kcodyjr: not sure if you're running it or not because i don't remember where it was committed
kcodyjr: but there is a possible flaw that must be tolerated until a real solution is found
kcodyjr: and that is, that something might be writing sRGB into a buffer that's being interpreted as linear, or vice versa
Ge0rG: so maybe another time :)
kcodyjr: yeah. i wanna finish this r600_cp stuff that i told airlied i'd take a whack at last week that's still half done.
kcodyjr: but, if there is confusion about colorspace handling still, don't be too harsh... to do that right including handling calibration, there is much that needs to be done... or rather, minor adjustments that need to happen in several places
kcodyjr: heads over to the git survival guide to dig out the instructions for removing a bad commit...
Ge0rG: "git reset HEAD^" if its local only
kcodyjr: Ge0rG, thanks... you're about 2 seconds ahead of digging it out via google ;)
Ge0rG: maybe "git reset --hard HEAD^" if you know what you do
Ge0rG: if you submitted it anywhere, it might wreak havoc
Ge0rG: is the r600_cp code related to VT switching in any way? ;)
kcodyjr: nope, and yes it 's a local tree
kcodyjr: r600_cp exists in r6xx-r7xx-support but not in airlied's kernel tree nor in the modesetting-gem branch; i'm working on migrating it over
yangman: my lut branch just fixes some overflow issues with actually writing the LUT values. nothing beyond that
kcodyjr: then we may or may not still be dealing with linear/sRGB issues, on top of the question of what code Ge0rG is running exactly... but that does answer the question, there does indeed exist a branch for LUT
masa-: does LUT here stand for lookup table?
kcodyjr: yes
kcodyjr: in particular, the color lookup tables used by the CRTCs
masa-: just funny seeing LUT here all the time, since it also happens to be the name of my university ;)
masa-: os short for it anyways