soreau: As a side note, with dri2 + 2.6.31_r4 KMS on rv350 radeon 9600 AGP there is some 'noise' on the right side of the screen, like small horizontal mini lines with gl 'stuff' (compiz)
agd5f: soreau: sounds like display underflow. you can tweak that, but I don't think we've exposed that under kms yet
soreau: Mostly noticeable when using 'it' (rotating cube, wobbly windows, games) and some 'stops' where input, mouse cursor most noticeably is unmoveable for periods of about right under a second or so
soreau: agd5f: You know much better than I, just making observations mere as they might be here :)
soreau: So far as 'stable' goes, this is very nice. Running all latest git 'stuff' including but not limited to 'all' X packages, kernel, mesa and driver
soreau: No lockups at all yet
soreau: (Again, Radeon 9600 rv350)
soreau: Oh yea, libdrm too :)
dileX:
spstarr: :)
spstarr: reminisces the days of the rv350
soreau: You guys rock, and I'm advertising now. Did I mention the radeon driver developers are doing a fantastic job? :D
soreau: spstarr: I must inquire, why have you taken a break from testing? Was it because your card died?
spstarr: the LCD screen died, not the laptop
spstarr: the laptop is on my other desk in the den
spstarr: so i can always test the rv350
soreau: My LCD died recently. Fortunately this is a desktop
soreau: I'm using the dead LCD to trick an Intel gfx chip into starting X headless as it may be. The LCD is plugged into the VGA port, without even any power directly
spstarr: i can only use the VGA/DVI connector on the laptop+docking port
soreau: Works great with all modes :)
soreau: spstarr: I was wondering why you weren't testing on your r6-7 though?
soreau: used to enjoy listening to spstarr 'realtime' mode ;)
spstarr: im waiting for the next r6xx status
spstarr: 25% passing for 3D so far
soreau: status, as in working 3D?
spstarr: yep
spstarr: and KMS
soreau: ahh
soreau: ok
spstarr: this new laptop has 2 GPUs in it
spstarr: so im just using the Intel GMA until then
soreau: That satisfies my inquiries for the night :)
spstarr: hehe
DanaG: I wish HP would've done switchable graphics.
soreau: spstarr: How's intel doing btw ?
spstarr: now I've had crashes with the intel though
soreau: ouch
spstarr: firefox + google maps and mouse cursor focus loss
spstarr: no VT switch, and not recoverable
soreau: I've had none with dri2 on this gentoo with rv350
DanaG: oh yeah, that other laptop with the dead LCD.... try disconnecting lvds, and you'll see bugs pop up. =þ
soreau: tries VT switch
soreau: Input a bit buggy, but looks nice!
spstarr: but what I have now is 'ok' while I wait to really use the r6xx + 512MB on it
soreau: spstarr: Using fglrx currently?
spstarr: no
spstarr: never used the AMD proprietary stuff
soreau: Oh yea, plus VT switch is working fine
spstarr: I tried it once on the rv350, i got corruption, gave up went back to radeon
soreau: I'm really happy with the whole situation. I'm glad I 'bought' into oss :)
soreau: trips over airlied_'s tail
spstarr: I know once things settle down, Graphics issues in the future will be non headlines
spstarr: short term pain long term gain
soreau: spstarr: Who cares about headlines? I sure don't. I know of phoronix, but I ony want what works
soreau: only*
spstarr: I expect in 7 years, (if this laptop lives that long) when i get a new card it'll take much less time for FLOSS drivers with Gallium 3D
soreau: My only disappointment is not being able to have tv-out@1024x768
DanaG: Nice e-mail address. So says pidgin. =þ
soreau: Apparently that might never happen after I looked into the mess
soreau: s/mess/source
DanaG: I wish I could stick an HD4650 in my laptop to replace the 3650. =þ
soreau: gives DanaG a solder gun
DanaG: Actually, it's MXM.
DanaG: Either that, or an HP variant.
DanaG: ah, I just tested: gnome is not the thing trampling on touchpad boundaries.
DanaG: Next suspect: the xorg driver itself. Now to get the source of that.
mcgreg: do I understand correctly that the branch of current mesa is now master and not radeon-rewrite anymore?
dileX: mcgreg: yupp
mcgreg: thx
dileX: mcgreg:
mcgreg: ok, thx again
dileX: n.p.
mcgreg: hmm just decided to get a fresh mesa git master (deleted the old one completely)... now I just need the mess with the prefixes and extra argument to build it. can you maybe help me? all I remember is --prefix=/usr
mcgreg: ther was also somethink like --with-dri=radeon --disable=gallium .. but I'm not sure anymore
dileX: mcgreg: which gpu?
mcgreg: ok, I believe I got it mostly. do I need to disbale egl too?
mcgreg: gpu is RV730 - r7xx
mcgreg: building swrat, radeon, r600 - and disbaled gallium. is that correct?
mcgreg: *swrast
dileX: disabling gallium (exp.) saves hdd-space and build-time
dileX: swrast I would build as fallback when radeon-drivers have problems
mcgreg: ok,build finished
dileX: its correctly --with-dri-drivers=radeon,r600
mcgreg: now, let's see the magic
mcgreg: ok,glxgears "works" , 20fps and is flickering and corrupted :)
mcgreg: bt didnt crash ;D
mcgreg: hehe "aapoly" , a window with two lines building a X - but when I resize the window the one line disapears :)
mcgreg: no.. aargb I mean
mcgreg: hmm most of the demo break in some way when the window gets resized. but there never crash at least ;)
glisse: airlied_: yup Venki is aware
mcgreg: ahhh glxgears is fine with a small window .. like when the fps is 50fps it totally ok, but if it's smaller it looks broken
bridgman: mcgreg; try singlebuffer and reflect
bridgman: should be no corruption there
bridgman: something funny is happening with vertex buffers but we haven't figured out what
bridgman: geartrain is worst
bridgman: gearbox should be ok
bridgman: and running 2 apps at the same time still results in vertex buffers being mixed up between the apps
bridgman: which is cool but not the way it's supposed to be working
boghog: :p
boghog: i was still getting the black screen issue with single-buffered visual last time I tried :/
bridgman: when was that ? I haven't seen it for a long time...
boghog: few days ago
boghog: it was fixed with double-buffered visuals
boghog: but when I tried singl-buffered I still got it
bridgman: does progs/demos/singlebuffer show the problem ?
boghog: let me just try with the latest mesa
boghog: one sec, booting up test machine
EruditeHermit: the mixup should be fun
EruditeHermit: you can get cool new games
bridgman: yeah, sort of a mashup, but without the careful coordination between tracks
suokko: bridgman: I think any direct color visual is buggy with wrong compination of coponents
suokko: bridgman: glsync show problem for me
suokko: bridgman: singlebuffer demo does't show it
bridgman: ok, will check glsync, thanks
suokko: There is bug report about that too ;)
bridgman: quote of the day... "The X Window system is a big and complex hairball"
bridgman: FSF, 1999
suokko: How can I make glut tell me visual id which it uses?
boghog: bridgman, yeah still getting it with progs/demos/singlebuffer
suokko: Or is it easier just to hack mesa to output it? :)
suokko: Intresting singlebuffer works for me
suokko: boghog: Does xdemo/glsync work for you?
EruditeHermit: bridgman: at least its not monolithic anymore
boghog: ok that is just weird
boghog: glsync showed it too
bridgman: which GPU ?
boghog: but machine just locked up
boghog: with a blue screen!
bridgman: are you running Linux ?
boghog: yes :p
bridgman: just checking ;)
boghog: ah not locked up actually, can still ssh into it
boghog: but it is amazingly slow
suokko: boghog: I think you got the DRM deadlock :)
boghog: hmm, no errors on dmesg though
boghog: X using 100% cpu
EruditeHermit: is this r600?
boghog: r700
suokko: boghog: Sounds familiar situation
raevol: .j #ubuntu-gaming
raevol: :P
suokko: r300 did have that sometime ago when ogl app did cause freeze and xorg went mad
suokko: boghog: What happens if you apply http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg08184.html ?
boghog: hmm, tried to kill X over ssh but now the machine really died :p
suokko: boghog: If oyu see that again better just trace what xorg does and reboot ;)
suokko: (If you can attach trace to it any more)
boghog: hmm, how does that work?
boghog: ok i can at least reliably reproduce it by running xdemos/glsync and then CTRL+Cing it from xterm
suokko: boghog: Then maybe better first attach gdb to xserver (over ssh) and then kill the glsync and see where xserver is running
boghog: ah ok
suokko: boghog: http://linux.die.net/man/1/strace
suokko: That for tracing
suokko: You can attach it also before causing the hang
boghog: ah, didnt know you could attach with strace
EruditeHermit: suokko: is that patch included in mesa now?
suokko: No :) Seems like none has had time to review my patches in few days
EruditeHermit: would that stop r300 freezes too?
boghog: hmm, is it safe to copy/paste that patch? seems some lines have been broken
suokko: EruditeHermit: I'm not sure. It is possible that it prevents some of them. But if you get GPU hang that doesn't help at all
suokko: And GPU hang is a lot more likely for r300
EruditeHermit: I get a slow moving mouse cursor
EruditeHermit: and no response when clicking
EruditeHermit: and I have to reboot
suokko: EruditeHermit: Can you ssh to the machine when it happens?
EruditeHermit: yes
EruditeHermit: err actually
EruditeHermit: it depends
EruditeHermit: sometimes I get the slow moving cursor
EruditeHermit: and sometimes the cursor doesn't move at all
EruditeHermit: in which case I can't ssh in
bridgman: suokko; I think the guys are working on the underlying problem you identified
suokko: Because if you can't ssh then your kernel locks and it is harder to debug
bridgman: might be over-running the relocs list
suokko: bridgman: sure. But my clip rectangles batch is also waiting still ;)
bridgman: Cooper noticed that a few hours ago
EruditeHermit: suokko: http://bugs.freedesktop.org/show_bug.cgi?id=19129
bridgman: sorry, didn't we respond re: cliprects ? both agd5f and I found that the patch resulted in a different & worse type of corruption
boghog: hrm, I attached gdb to X, then triggered the lockup, but can't interrupt from gdb
suokko: bridgman: But I think my patch would help debugging problems because it reduces chance of lock up
bridgman: no frequent horizontal lines but less frequent big blotches of corruption
suokko: bridgman: But that is real bug even in r200/r300 driver
bridgman: the blotches of corruption or lockup ?
boghog: oh, looks like machine locked up completely right away now
suokko: Because without moving update of clipping rectangles driver reads already freed memory that is security problem
bridgman: ok, will discuss with agd5f tomorrow
bridgman: um.. today...
bridgman: soon
bridgman: crap.. zzz
boghog: nn :p
suokko: boghog: Then your best bet is to strace and see what calls happen there
boghog: ok, i alsi tried attaching gdb to glsync and then doing CTRL+C, but then it doesnt trigger the lockup (which I guess makes sense since i guess gdb intercepts it?)
boghog: also*
suokko: It might be some timing issue that somehow when gdb is attached clean up of gpu is not called too early that would cause problems
suokko: I have seen before some bugs not reproducing when using gdb with breaks
boghog: yeah if I just kill glsync it triggers the lock up as well, but again not with gdb attached, then it exists cleanly
boghog: ill try strace
suokko: EruditeHermit: Your bug report sounds like gpu hang which is not going to be worked out by protecting lock ussage
MrCooper: actually it just sounds like a DRM lock deadlock
MrCooper: e.g. if the client prints to the terminal with the lock held, it may deadlock with the X server
EruditeHermit: MrCooper: is that boghog's problem or mine?
MrCooper: boghog's
suokko: boghog: Did you try my patch from mailing list? That should work around the drm lock deadlock and print error message (but run it with ./glsync 2> err.log)
boghog: not tried it yet, seems that mailinglist thing mangled the patch or something
suokko: Just in case you would get deadlock from xserver because of terminal output from inside DRM lock
suokko: boghog: I can upload plain text one
MrCooper: suokko: btw, I'm not sure your patch is multi-threading safe; I think the intel driver uses a mutex for this, may want to look at that
suokko: MrCooper: It is not. But is there support to call opengl from multiple threads to same context?
suokko: I though it wasn't allowed
boghog: heh.. with strace attached no lockup either
boghog: just ends with http://pastebin.com/m64b23cfd
suokko: boghog: http://sprunge.us/EOiO
MrCooper: suokko: I don't remember the details, ask Thomas Hellstrom or Keith Whitwell
boghog: thanks suokko
suokko: MrCooper: I think that thread safety was the big planed feature for ogl 3.0 but it was dropped because of too invasive changes if I remember the news about it correctly
suokko: But I can of course change the patch to be thread safe :)
MrCooper: suokko: for one, that it's not supported doesn't mean nobody tries...
suokko: yes
boghog: is it okay to only copy over r600_dri.so? or are other things touched by that patch
suokko: boghog: it is ok
suokko: MrCooper: Is there atomic increment and test somewhere in mesa or drm?
MrCooper: suokko: have you looked at the intel driver?
suokko: I think that is what is really required for patch to be thread safe without locking
suokko: No.
boghog: humm
boghog: "Machine check events logged"
boghog: that's not good is it? :/
boghog: last time I got that I had failing hardware
suokko: "A machine check event is a hardware error detected by the CPU. "
boghog: hmm still lockup with patch, except screen went black this time, not blue as before
boghog: but i guess this is all a bit futile if I might have actual hardware issues
suokko: MrCooper: I did found atomic implementation from gallium but it doesn't include increment and compare :(
MrCooper: and you couldn't use that in a non-Gallium driver anyway; but there's really no need to reinvent the wheel...
g-zu: some commit to the KMS between 2.6.31-rc3-git3 and 2.6.31-rc4-git4 results in an infinite loop or some other mechanism which keeps the cpu 100% busy
g-zu: I will try to narrow it down later today if needed, for now I have some work to do
dileX: g-zu: which processes cause that?
g-zu: if I build radeon as a module inserting it locks the kernel and init doesn't ever finish
dileX: which gpu?
g-zu: if I built in into the kernel, it initializes but than even xterm freezes after the termination of a 3d application launched from it
g-zu: rv380
dileX: g-zu: dmesg output?
g-zu: there's nothing in there
g-zu: and I didn't really save one, I will make one sometime later if you want... but for the moment I really have to stay with a stable kernel cause I have work to do
g-zu: but I did take a look at it and did not find anything after the start of X
g-zu: also I have a dual-core system and first one core got in an infinite loop and was ok, after the second one got too even sysrq didn't work
dileX: I noticed that I have 100% cpu-usage when watching video-streams in firefox - thats X-server itself at 100%
dileX: didnt investigate deeper
g-zu: in my case it was xterm after quitting from glxgears
g-zu: I also tried with other tests, like texture mapping
boghog: btw, not sure what changed or if I am doing dumb myself, but loading the 'medium' sized vbo that would previously cause recursive lock, now just makes my app crash with 'realloc: invalid next size' from r600_cs_begin
g-zu: and had the same result
boghog: valgrind sees no issues in my app on other pc
stalkerg: Kernel module from git x11-drm not work now? (I have 2.6.30 without drm)
stalkerg: radeon.ko load and register but not start...
stalkerg: oh.. i see
stalkerg: comapre radeon_drv.c in kernel 2.6.30 and from x11-drm.... heh
g-zu: stalkerg: if you want drm in 2.6.30 you have to build it in
g-zu: x11-drm currently only works with 2.6.28
g-zu: by build it in I meant build the kernel with the drm from inside the kernel source
stalkerg: g-zu: build now...
g-zu: stalkerg: you have to also check the module specific to your video card (just in case you didn't know)
stalkerg: g-zu: thx, all work
stalkerg: g-zu: drm up and driver connect to dri
g-zu: no problem stalkerg
stalkerg: :)
suokko: MrCooper: I did looked at intel code and it isn't thread safe :)
MrCooper: hmm, thought it was (supposed to be)
suokko: MrCooper: count++; if (count > 1) is not thread safe
suokko: That is what intel does
MrCooper: isn't it guarded by a mutex?
suokko: No
suokko: But if you change that to atomic_inc_and_test (or gcc builtin __sync_add_and_fetch) it would be thread safe
suokko: So intel assumes that only one thread is accessing context at once but context may include shared resources that are late protected by mutex
suokko: btw, That gcc built-in is not nice idea because it is only available in gcc 4.2 or later
nanonyme: suokko: Sorry, which built-in?
suokko: nanonyme: __sync_*_and_* :)
suokko: see the message at 1:42:35 ;)
nanonyme: can't spot anything relevant by Finnish timezone
suokko: nanonyme: (or gcc builtin __sync_add_and_fetch)
nanonyme: Ah.
aliverius1: hi
aliverius1: effects with kwin are kinda slow, is that normal? i have an x1600 mobile
chithead: should be acceptably fast if you have dri and exa enabled
aliverius1: i dont have a xorg.conf, glxgears give me ~2500fps and how do i troubleshoot exa? just look at the logs?
g-zu: aliverius1: Xorg log should be enough to know if it works or anything went wrong
aliverius1: if i had a little better results i would call them "acceptable"
g-zu: look for lines starting with (EE) or (WW)
aliverius1: ok
MrCooper: aliverius1: might also try the different kwin backends, OpenGL may work better than XRender
aliverius1: II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead.
aliverius1: and also
MrCooper: Option "AccelMethod" "EXA"
aliverius1: (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
aliverius1: hmm this means i need a xorg conf right?
MrCooper: or a driver from Git, yes
aliverius1: can it only contain only the line you specified?
MrCooper: probably needs at least a Section "Device" for Driver "radeon" around it
aliverius1: thanks!
aliverius1: oh and i have tried opengl too, it wasnt better either
MrCooper: np
aliverius1: brb hopefully
nanonyme: Probably need option "accelmethod" "exa" as well.
aliverius: it is A LOT better now! thanks!
aliverius: should i suppose that such settings can be done through HAL too?
aliverius: not that i love it ... =/
MrCooper: aliverius: well, for this particular option it's the default in current upstream
aliverius: so this is why Xrender has always sucked
aliverius: i found out when trying Enlightenment with h/w accel
aliverius: now even kwin with opengl is faster too??
aliverius: !!!
aliverius: just because i switched to EXA ?
MrCooper: yeah, it's more efficient in general for compositing
aliverius: then thanks twice :)
aliverius: i will keep opengl for kwin
aliverius: but now there is another problem
g-zu: skip to the subject of the problem
aliverius: whenever i run glxgears when i run my pointer over its window the screen will blank
aliverius: i thought it was kwin but i sitched to twm to get the same problem there
MrCooper: aliverius: fixed in Mesa Git
EruditeHermit_: there is a typo in the man page
EruditeHermit_: R300 Radeon 9700PRO/9700/9500PRO/9500/9600TX, FireGL X1/Z1
EruditeHermit_: should read 9600XT
kdekorte: on r6xx with the latest mesa the black screen (broken color map) is back again... now with the gamma demo
aliverius: it is my lucky day, very good support guys! thanks once again MrCooper
MrCooper: kdekorte: yeah the problem shifted to single-buffered apps, I suspect it needs to be fixed properly in xserver by making the depth 32 GLX visual separate from the rest again
kdekorte: MrCooper... thanks for the info
kdekorte: I don't have any 32bit depth visuals however
kdekorte: Oh, wait... I have one and it is marked nonconformant
kdekorte: 0x61 32 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 Ncon
g-zu: oh, so that's what Ncon means
g-zu: I thought it was something like not connected (to what I don't know)
g-zu: this is mine 0x64 32 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 Ncon
MrCooper: kdekorte: yeah, there's been a whole saga which started when xserver was changed to make that visual replace one of the depth 24 visuals; I've fixed at least two different problems in Mesa but it finally looks like there's no way round making it separate in xserver again
kdekorte: Well at least you know what the problem is... which is good
MrCooper: yeah, now I just need the time to fix it, or somebody to beat me to it :}
g-zu: isn't this the most used visual?
MrCooper: no
MrCooper: it's only really needed by GLX compositing managers
MrCooper: in fact it isn't usable for anything else with DRI1, that's why it's marked as non-conformant there
g-zu: oh, well
g-zu: is it supported with dri2 yet?
MrCooper: yeah
g-zu: I guess I'll just have to try it, I tried yesterday but opengl was rather slow with kms, maybe it's the same think aliverius had with exa, I'll look at it today
g-zu: ^^thing
MrCooper: g-zu: XAA isn't supported with KMS
g-zu: hmm
g-zu: but even glxgears ran at half the performance I have on dri1
MrCooper: 'glxgears' ;}
g-zu: not to mention that if I enable page flipping with dri1 I get more than 3 times the performance I got with dri2
g-zu: yea... running it fullscreen I got only 30 fps with dri2
MrCooper: g-zu: the DRI2 SwapBuffers doesn't allow quite as insane framerates, but it shouldn't matter so much for real apps
MrCooper: also DRI2 is still missing things like tiling, once that's back it should be at least on par for non-glxgears
g-zu: well kde was set to run on opengl and wasn't capable to initialize it
g-zu: aha
MrCooper: that should be fixed now, worked for me recently
g-zu: in that case I'll try again
glisse: agd5f, MrCooper: any reason for kms not having Upload to screen and download from screen ?
glisse: here we endup hitting memcpy :(
g-zu: MrCooper: if you don't mind my asking what exact version from 2.6.31 did you use?
MrCooper: glisse: for me the reason is the same as most other things I haven't done: haven't got around to it
EruditeHermit: MrCooper: hi
MrCooper: g-zu: no 2.6.31, I'm cherry-picking KMS stuff on top of 2.6.30.y; but I think the KDE4 problem was in Mesa or some other userspace component
g-zu: might have been, although I recompiled all yesterday, except for xorg-server
glisse: MrCooper: it didn't used memcpy in the past somethings changed somewhere
glisse: anychange in core exa that would lead to always download from screen ?
MrCooper: glisse: airlied didn't port the KMS UTS/DFS stuff from kms-support
glisse: oh missed that
g-zu: oh, should I try that branch and run on top of 2.6.30 for it to work better?
MrCooper: I'm not sure we should bother anyway short of via userbuffers anyway
MrCooper: g-zu: probably not unless you know what you're doing
g-zu: I know how to build and install the drm kernel module, but other than that I'm quite far from knowing about kms and stuff like that
gmartyn: trying to get composite to work with kwin and xrender on fedora 11. in xorg log i see (WW) RADEONHD(0): DRI support has been disabled at compile time, (II) AIGLX: Screen 0 is not DRI2 capable, (II) AIGLX: Screen 0 is not DRI capable, (II) GLX: Initialized DRISWRAST GL provider for screen 0 using radeonhd compiled for 1.6.0, module version = 1.2.5
gmartyn: is it not going to work?
chithead: dri disabled at compile time means it was miscompiled
gmartyn: chithead: so fedora messed up and it's not going to work for anyone?
chithead: did you use distro provided packages or did you compile your own drivers
gmartyn: chithead: distro
reaVer: chithead: does this driver support the card I just mentioned to you?
chithead: radeon driver supports all radeons
MrCooper: note that radeonhd != radeon
chithead: gmartyn: probably a bug then
kdekorte: which card is it?
chithead: gmartyn: check redhat bugzilla if the problem is already reported
reaVer: ok
gmartyn: ATI Technologies Inc M76XT [Mobility Radeon HD 2600 XT]
reaVer: then here goes my current issue: OpenGL is VERY slow
reaVer: 01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200M] <--- and that'
reaVer: s the card
chithead: reaVer: some performance issues can be worked around by disabling low-impact fallback in driconf, also some versions of mesa shipped with broken radeon dri
zhasha: Xpress 200 has no vertex shaders
reaVer: zhasha: I don't think mplayer uses those
reaVer: chithead: driconf?
zhasha: mplayer does everything but scaling on the cpu anyway
reaVer: zhasha: glxgears is also slow
kdekorte: reaVer, does xv work? That should give your best performance
reaVer: and xv currently runs faster than gl2
agd5f: reaVer: there was a regression on igpp chipsets since mesa 7.2. you need mesa from git (7.6) for the fix
reaVer: kdekorte: with my nvidia card(in my PC which is currently shipped away for repairs thanks to the cooler leaking cooling gasses) had very little difference in performance between the 2 display methods
reaVer: agd5f: k
reaVer: aur/libgl-git 20090507-1 (18)
reaVer: is that recent enough?
agd5f: reaVer: I don't recall
reaVer: hmmm, hope it works from the master branch or something
rnoland: agd5f: thanks for the note about updating drm in the commit message.
agd5f: rnoland: np
kdekorte: rnoland, I use a script that pulls agd5f's drm, mesa and the ddx all at once... useful for knowing when things need recompiled
rnoland: kdekorte: i have to port his changes...
kdekorte: ah
rnoland: kdekorte: i presume it will be a simple merge, but i have to look.
rnoland: <- FreeBSD you know...
reaVer: agd5f: should I use dri-driver radeon?
agd5f: rnoland: they are very small
agd5f: reaVer: r300 3d driver for your hw
reaVer: k
reaVer: is the git repo slow or unresponsive btw?
reaVer: nvm
glisse: agd5f: should exa try to map pixmap instead of calling download from screen on fallbakc
agd5f: glisse: maybe
nha: MostAwesomeDude: ping?
Zajec2: glisse: what about r67xx kms?
Zajec2: glisse: can you publish something?
glisse: yeah tomorrow i will push the patch
glisse: got to go
Zajec2: :)
ShamwowVideoProf: hahaha i asked him the same thing in #dri-devel
Zajec2: :)
kdekorte: rnoland, how is your drm tree different than agd5f's? And if I have an r6xx should I be using it?
agd5f: kdekorte: his tree is for bsd
rnoland: kdekorte: are you using FreeBSD?
kdekorte: guess that answers that... I'm on Fedora 11...
rnoland: agd5f: it would be great to have a version based on drm-linux
rnoland: drm-linus.....
rnoland: i have all the ring_ptr functions and a lot of whitespace differences...
rnoland: as well as using switch for microcode, which still seems to be missing from all trees.
rnoland: agd5f: btw, i've been shipping using msi interrupts for a while now with no apparent issues.
ShamwowVideoProf: does r7xx have dri2?
ShamwowVideoProf: oh yay I got TCL!
Neo_The_User: disregard that questio
Neo_The_User: n
reaVer: agd5f: dri won't load now
kdekorte: agd5f, I've been looking at the pointblast demo (uses 2d textures) and I can't seem to find out why the alpha channel is not set, however it is just an RGB and not an RGBA texture...
kdekorte: never even seems to call r600GetTexFormat... which I would think it would need to
Neo_The_User: agd5f: ping
Neo_The_User: can you put in a "EnableIRQ" feature for radeonhd like there is for the via drivers? please please please please?
agd5f: Neo_The_User: the drm will use irqs automatically if they are supported. it has nothign to do with the ddx
Neo_The_User: how do i turn on not automatically?
Neo_The_User: because they arent going on
agd5f: Neo_The_User: you have no idea what you are talking about
Neo_The_User: all i know is that smplayer keeps crashing because IRQs report -22
Neo_The_User: or something like that
kdekorte: Neo_The_User r6xx/r7xx?
Neo_The_User: ATi Radeon MSI 4650 PCI Express 2.0 1 GB DDR2. thats my card :)
zhasha: Neo_The_User: that's a bug
kdekorte: Neo_The_User... are you using xv or x11 in mplayer?
Neo_The_User: opengl
agd5f: Neo_The_User: there's no irq support yet on r6xx/r7xx chips
zhasha: IRQ is a CPU interrupt
zhasha: and IRQ*
zhasha: an*
reaVer: --with-driver=dri \
kdekorte: no opengl on that card yet
reaVer: what does that do?
Neo_The_User: you dont need that to compile mesa
Neo_The_User: its on automatically iirc
Neo_The_User: agd5f: ohh
kdekorte: Neo_The_User on that card you only have xv and x11 now... opengl does not work for mplayer
zhasha: reaVer: what exactly is your problem and what have you done?
Neo_The_User: or any players. even the small ones that me and my friends made
reaVer: my original problem was that my openGL acceleration was terribly slow
zhasha: agd5f: how can you have 3d support without having an IRQ mapped to the card?
zhasha: reaVer: did you have acceleration or was it using swrast?
agd5f: zhasha: just don't use it
reaVer: I tried installing the latest dri from the git through the AUR PKGBUILD
reaVer: zhasha: I think it was using swrast
zhasha: agd5f: won't that create a series of horrible timing issues?
reaVer: and I tried to switch to r300
zhasha: ah, archlinux user I see
zhasha: what version of mesa do you have?
agd5f: zhasha: not really
reaVer: git
reaVer: git head
zhasha: alright, well, arch's packages are poorly divided in that area
agd5f: you only really need them for vblank and as a helper for other things, but they are definitely not required
reaVer: zhasha: that doesn't help me a lot
rnoland: agd5f: what do we need for irq support?
zhasha: reaVer: getting package names
reaVer: the package I made from the git repo should contain the file I'm missing
rnoland: agd5f: that i feel qualified to work on....
agd5f: rnoland: irq's have a whole separate ring buffer on the new chips
rnoland: i've spent so much time screwing with interrupts on intel that I know that code well...
zhasha: reaVer: there's a special symlink inserted to make up for some old X bug
rnoland: agd5f: oh, hrm....
reaVer: libdricore?
zhasha: pacman -S libgl xf86-video-ati mesa ati-dri libdrm
zhasha: then try restarting, and tell me what errors you're getting (if any)
reaVer: no, I just switched away from those because they don't support hardware accel with my graphics card
reaVer: for all of those, except mesa and ati-dri, I got the git head version
zhasha: okay well, if you want a newer 3d driver:
zhasha: pacman -Rd libgl mesa ati-dri
zhasha: and I'll type you up some appropriate pkgbuilds for git versions
reaVer: there's already pkgbuilds out there for the git versions
reaVer: which I'm using
zhasha: you'll want libdrm and xf86-video-ati from the arch repos
reaVer: one of them simply seems to not install some file that's actually important
reaVer: and there's nothing in that pkgbuild that specifically excludes that file
zhasha: what file are you missing specifically?
zhasha: and what PKGBUILDs are you using
reaVer: the ones found on the aur
zhasha: there's a lot of PKGBUILDs on AUR
reaVer: libgl-git, xf86-video-ati-git and libdrm-git
reaVer: ati-dri doesn't seem to have a git specific package
reaVer: and that package is at 7.5 in the repo
zhasha: okay well, you'll want to remove the xf86*-git and libdrm-git packages and swap them for the regular ones
reaVer: k
zhasha: the 3 you need to get from git are libgl, mesa and ati-dri
zhasha: you can download the official PKGBUILDs for those packages and modify them to grab from git
reaVer: ati-dri doesn't have a PKGBUILD for it on the AUR
zhasha: http://repos.archlinux.org/viewvc.cgi/ati-dri/repos/extra-i686/PKGBUILD?revision=46791&view=markup
reaVer: looking at the buildscript I won't be needing ati-dri anymore with the current compilation XD
reaVer: I put r300 in the libgl pkgbuild
zhasha: reaVer: with modification it becomes something like: http://pastebin.ca/1514025
reaVer: zhasha: http://pastebin.ca/1514028 <--- this is what my libgl-git pkgbuild looks like
zhasha: you'll need to mod: http://repos.archlinux.org/viewvc.cgi/libgl/repos/extra-i686/PKGBUILD?revision=46797&view=markup and http://repos.archlinux.org/viewvc.cgi/mesa/repos/extra-i686/PKGBUILD?revision=46799&view=markup as well
reaVer: mesa has a git version on the aur
zhasha: reaVer: last I tried using aur packages for that, it set me waaaay back
reaVer: my editing to libgl gives it the stuff that ati-dri would provide for me
Neo_The_User: oh nice. with our custom video player we can have xv with radeonhd specific textures
Neo_The_User: that works \o/
zhasha: reaVer: I'm not sure that works :/
reaVer: zhasha: now it's no longer compiled against libdricore.so
reaVer: the r300 thingie
zhasha: I recommend you take the official PKGBUILDs, modify them slightly to pull from git, then build those 3 packages
reaVer: so now it should work:p
zhasha: the AUR git PKGBUILDs tend to be horribly outdated
Neo_The_User: yeah
zhasha: case in point: your PKGBUILD there claims to provide libgl=7.4.1, where we're now on version 7.6
Neo_The_User: i use LFS and arch and i always build everything myself
Neo_The_User: well 7.5 stable
Esmil: zhasha: Actually I find it easier, now that I compile my own package anyway, to just include it all in one custom mesa-git package. mesa, libgl and ati-dri all comes from the same source anyway
zhasha: Esmil: yeah, that's a good idea as well, but I maintain the separation to avoid confusing myself too much when updating the PKGBUILDs
zhasha: basically, www.zhasha.com/radeonkms
zhasha: it's old, but it worked really well
Esmil: Here is how it works for me: http://pastebin.org/5606
zhasha: Esmil: no further modification of the dst tree needed?
Esmil: dst tree?
reaVer: zhasha: how can I verify which dri so has been loaded?
zhasha: the folder all the files are installed into
zhasha: glxinfo
Esmil: No, most of the complication comes from splitting the compiled output in seperate packages
reaVer: working
zhasha: Esmil: I use fedora now :P
tpocra: My entire X11 just broke with a X1900 (r5xx) and Debian says that it failed to load the module "ati"
tpocra: (EE) No drivers available
reaVer: zhasha: why did mesa need a git upgrade?
zhasha: reaVer: actually, libgl, ati-dri and mesa are all mesa
tpocra: (EE) Failed to load module "ati" (modules does not exist, 0)
zhasha: it's just split up into 3 smaller packages to ease distribution
jcristau: tpocra: is xserver-xorg-video-ati installed?
reaVer: yeah I got that part
reaVer: but what does mesa in arch linux perspective provide that requires me to update it?
zhasha: reaVer: so they all need to be in sync with each other to keep up with api changes
reaVer: but if it already runs, there isn't a problem right?
zhasha: your libgl package provides what mesa provides
reaVer: (because mesa-git wants to switch glproto and dri2proto to git versions etc etc)
reaVer: oh ok
zhasha: as well as ati-dri
tpocra: jcristau: no
zhasha: incidentally you might want to change the provides line
jcristau: tpocra: that would explain why X doesn't find it
zhasha: provides=('libgl=7.6', 'ati-dri=7.6', 'mesa=7.6')
zhasha: or however that's set up
zhasha: might not need the commas
reaVer: it's currently in 3 different packages but mesa package seems to be providing just glu and some glx
zhasha: and mesa itself :P
reaVer: no, the original libGL is not being supplied by that package
zhasha: libGL != mesa
reaVer: libGL.so I mean
tpocra: jcristau: Thank you!!!
jcristau: np
Neo_The_User: would I be better off setting DRI "True" or leave it commented out?
Neo_The_User: on r7xx?
zhasha: Neo_The_User: I don't know, what does it default to and what do you want?
Neo_The_User: well with it commented out, i get software rasterizer with 128 GLX thingys and 68 or so of something else. with it on,i get direct rendering with 8 glx things and 8 other things. havent tried out blu-ray playback to see which ones better though
Neo_The_User: as far as performance goes
Neo_The_User: what im trying to do now is get DRI working without me telling it to get it working and I am very very close
zhasha: Neo_The_User: well, if you want DRI, and it doesn't default to on, then set it
Neo_The_User: or i can fix it
g-zu: depending on what xvinfo says if you don't force dri on you can find out if you have xvideo support, if that's what you're after
Neo_The_User: well i cant play blu-ray with my intel core 2 duo with software rasterization so im fixing DRI. i think i got it now
Neo_The_User: ugh ok this is weird. i fix that, and DRI works but im still getting software rasterization
Neo_The_User: i think i need to reboot
Neo_The_User: rb
g-zu: I thought opengl didn't have anything to do with bluray playback
g-zu: at least not until the code for gpu video decoding through shaders will be written ... in a future far far away
kdekorte: g-zu it has nothing to do with it, but you need dri to get xv to work
g-zu: he said he has dri
g-zu: you can have dri and mesa use software nonetheless
Neo_The_User: right
Neo_The_User: as i do right now
kdekorte: mplayer doesn;t work very with with software opengl
kdekorte: if you want the best playback on r6xx (2000HD or higher cards) the best option is xv
g-zu: yes
Neo_The_User: http://pastebin.ca/1514059
Neo_The_User: see anything fish-ay?
g-zu: Neo_The_User: is your movie encoded as x264?
Neo_The_User: h264
Neo_The_User: no x264
Neo_The_User: sorry
Neo_The_User: meh one of the two
MostAwesomeDude: Neo_The_User: Protip: h.264 is the codec; x264 is the open-source library that can encode h.264. :3
Neo_The_User: ah
Neo_The_User: thanks
MostAwesomeDude: Now You Know *de de do da de do*
g-zu: Neo_The_User: and the movie is full hd, right?
kdekorte: Neo_The_User, why are you asking about radeonhd, in the ati/radeon chat?
Neo_The_User: well i can choose. 720p or 1080p
g-zu: you don't have enough horsepower for mplayer to decode it in real-time
g-zu: if you use mplayer that is
Neo_The_User: no its custom
g-zu: than I can't help you, with mplayer I know a few options which help
g-zu: I had the same problem
Neo_The_User: shoot :)
g-zu: try mplayer -lavdopts skiploopfilter=all movie_name
Neo_The_User: kdekorte: its more so about mesa / dri. not so much just the DDX
Neo_The_User: nice thanks
g-zu: also if you're using ati driver might help to run xvattr -a XV_VSYNC -v 0 first
Neo_The_User: OH I GOT OPENGL WORKING WITH DRI!
g-zu: mplayer doesn't do double buffering with X and
Neo_The_User: our player does that
kdekorte: Just because you have DRI, doesn;t mean it will run well on r6xx and above
Neo_The_User: wow this is slow. at least i got direct rendering though working with opengl with ati tuning
Neo_The_User: 3 maybe 4 frames a second
g-zu: Neo_The_User: you should really use xv output for now with r600+
g-zu: opengl is extremely slow
Neo_The_User: trys out fglrx on archlinux and goes to #ati for a bit
kdekorte: I can't get any thing other than a rainbow out of mplayer with -vo gl on my r6xx.. -vo xv works great
agd5f: kdekorte: need to fix rectangle textures
g-zu: I thought textures worked already
agd5f: g-zu: they do
agd5f: just not rectangle textures
agd5f: try texrect for example
kdekorte: pointblast, also needs some help...
g-zu: I actually tried a few and they worked
g-zu: that's why I said
agd5f: ie.e non-power of two
g-zu: agd5f: there was a regression in KMS somewhere between 2.6.31-rc3-git3 and 2.6.31-rc4-git4
kdekorte: I tried to debug it and never found what was going on... except it would allocate a 16x16, then and 8x8 and then 4x4 and 2x2 and finally a 1x1 texture... think it was displaying the 1x1 in the 16x16 cell...but really other than that, I don't understand it
g-zu: KMS works for me on rv380 with rc3-git3 but freezes the machine with rc4-git4 if it's built as a module
agd5f: g-zu: wc problem, there's a patch on lkml
g-zu: is it in the current git tree?
g-zu: cause I'd really like to try, there were quite a few changes
kdekorte: agd5f, looks like you fixed the inital box position in gamma, it used to be in the wrong spot...
agd5f: kdekorte: cool
agd5f: g-zu: no, looking for the link
agd5f: g-zu: http://bugzilla.kernel.org/show_bug.cgi?id=13881
kdekorte: unfortunately, tunnel seems to be getting worse.. couple of days ago (right after fog patches) it was near flawless... now a lot of random errors
kdekorte: same with teapot....shadow is much better... but everynow and then the floor is in the air... both could be a race with memcpy however...
agd5f: there are some geometry issues still be sorted out. I think they are related to state emit
agd5f: gears has similar issues
kdekorte: geartrain as well...
boghog: yay, just wrote and applied my first GLSL shader
kdekorte: holy crap!.... etracer is starting to work...I can drive the penguin now
kdekorte: whooping 5fps... and lots of geometry errors,,, but better than this morning where it hung
mcgreg: yeah, gfx errors are okay as long it doesn't crash :)
_moep_: agd5f: I updated the bugreport for bug 22562 btw
dli: radeon-git version has fullscreen XVideo output messed up, after resuming from suspend to ram
agd5f: dli: try this patch: http://www.botchco.com/alex/xorg/reload_bicubic.diff
dli: agd5f, thanks
Esmil: cd
Esmil: wops, sorry
dmb: gives Esmil a cd
EruditeHermit: cd
EruditeHermit: do I get one too?
EruditeHermit: $1 million
airlied: oh yeah i should do trhat
airlied: port DFS that is
dli: agd5f, http://www.botchco.com/alex/xorg/reload_bicubic.diff fixed XV after s2ram
Rabenklaue: Hi, is there a way using DRI2 with the free radeon drivers?
Rabenklaue: In my Xorg.log there is this info entry:
Rabenklaue: (II) AIGLX: Screen 0 is not DRI2 capable
Rabenklaue: I want to launch some 3D applications based on Clutter within my Compiz desktop
Rabenklaue: Xorg.log http://pastebin.ca/1514330
Rabenklaue: My xorg.conf: http://pastebin.ca/1514331
adamk_: Are you using KMS?
Rabenklaue: I thought KMS is currently only available for intel chipsets?
adamk_: No, it's not. It's available for r100 through r500 radeon cards. And it's required for DRI2.
Rabenklaue: adamk_: And where can I check whether KMS is enabled?
Rabenklaue: Within my kernel configs I only find DRM_I915_KMS
adamk_: What's the output of 'cat /proc/fb' ?
Rabenklaue: for intel
Rabenklaue: /proc/fb is empty
adamk_: Then you don't have KMS enabled.
adamk_: I'm not sure what kernel version you need for radeon kms.
adamk_: I thought 2.6.30 was new enough, but haven't compiled it myself.
Rabenklaue: 2.6.30-tuxonice-r4
Rabenklaue: respectively linux-2.6.30.3
adamk_: Yes, I saw then... Hence my comment about think that 2.6.30 was new enough.
adamk_: s/then/that/
Rabenklaue: http://www.phoronix.com/scan.php?page=news_item&px=NzMzMA
adamk_: Yeah, just saw that.
adamk_: Time to upgrade if you want KMS :-)
Rabenklaue: Hmpf, but then I have to wait for an adoption of aufs2 to *31
Rabenklaue: But anyway, I'll have a look on the rc4 of 2.6.31. Thanks
adamk_: aufs?
adamk_: aufs2, rather?
Rabenklaue: http://aufs.sourceforge.net/README.aufs2
adamk_: Ahhh... Just curious because I use FreeBSD which uses UFS (unix file system) so I thought it might be related.
adamk_: Apparently not :-)
dileX: Rabenklaue:
Rabenklaue: dileX: wow, thank you very much
dileX: might be mergeable w/ linus-tree
Rabenklaue: And now as Linus himself seems to be involved there is some hope, that aufs2 will be merged into the main kernel soon
dileX: really?
Rabenklaue: I hope so
dileX: wasnt union-mounst favorized
dileX: "Note: it becomes clear that "Aufs was rejected. Let's give it up." According to Christoph Hellwig, linux rejects all union-type filesystems but UnionMount."
dileX: from
dileX: dont know if its still correct
Rabenklaue: If there is at least one working unionfs in the kernel, I'm happy. But at the moment I'm used to aufs, so wait for a definite
Rabenklaue: 02:24 < dileX> from
Rabenklaue: oops
Rabenklaue: decision
dileX: yeah, author is contiuing his work. hope :-)
Rabenklaue: Do I need to upgrade to the git versions of xf86-video-ati and xorg-server in order to get KMS to work on userspace base?
Rabenklaue: http://airlied.livejournal.com/66958.html
Rabenklaue: Here, they say it's only needed to get the git versions of libdrm and mesa with --enable-radeon-experimental-api
Rabenklaue: Ahrg, I'm that blind - git://git.freedesktop.org/git/xorg/driver/xf86-video-ati kms-support branch
yangman: Rabenklaue: use master of xf86-video-ati
yangman: Rabenklaue: kms-support is already merged
Rabenklaue: yangman: I'm using gentoo and currently installing x11-drivers/xf86-video-ati-9999 with kms USE flag - so I think it'll work. Thanks