Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-11-20

Search This Log:


DanaG: http://www.phoronix.com/forums/showthread.php?t=20208
DanaG: interesting... whoever decided that 1280x1024 should be a VESA standard, and 1280x960 NOT be one... needs to be slapped. Perhaps with one of these:
DanaG: http://www.jakkspacific.com/node/744
DanaG: =P
MightyMu: They should come in fish-shapes
Eddi|zuHause: the vesa standard is like 20 years old by now?
MightyMu: and possibly fish-scents, as well
Eddi|zuHause: maybe someone back then thought powers of 2 would be more fun
DanaG: Or maybe they liked squares more than rectangles.
DanaG: But yeah, 1280x1024 is really stupid.
soreau: airlied: You know the 'tv-out gives black screen' bug I was complaining about? It was a compiz - outputs issue. I know you probably already ignored that noise but figured I'd tell you anyway :)
DanaG: I mean, you don't see 1600x1024 monitors, do you? Same aspect ratio.
soreau: airlied: Also, that strange compiz ezoom problem was also a compiz issue as you expected
DanaG: Or 1920x1536. =P They all look just as stupid.
DanaG: 1024 x 819.2. Not even an integer. =P
DanaG: Anyway, done with that rant now.
DanaG: Last thing that keeps me on fglrx is power management. :Q <== hmm, what kind of smiley is that? It's accidental, whatever it is.
Eddi|zuHause: it's a wart?
MightyMu: It's a cigarette-smoking smilie
DanaG: EEw, wart is less bad.
soreau: yelling with spittle flying out
DanaG: or sucking on a lollipop.
DanaG: Oh boy, look what I started.... =รพ
MightyMu: :o
soreau: or a bugger stuck on the side :Q)
DanaG: hmm, anyway, the thing that blocks me from using radeon right now, is lack of even static power management with KMS (R600).
soreau: DanaG: Why don't you use dri1?
DanaG: It doesn't work as well with compiz... or at least, it didn't, last time I tried.
DanaG: And videos under compiz with non-kms... ouch.
soreau: I would assume xv should work ok
DanaG: It was all flickery last time I tried it.
soreau: You have to set the port
soreau: per the output of xvinfo
DanaG: hmm, I'll try that next time I shut down.
DanaG: I really wish the fglrx packages on Ubuntu used alternatives, instead of diversions... that way I wouldn't have to purge the package to get back the proper GL libs.
cxo: DanaG, git init /usr/lib :)
dman777: hey
simplexe: hi all
simplexe: when scrolling some text remains at the original location, while another part of the text, usually with the edges (the bottom or top with a vertical scrolling), scroll.
simplexe: ...and in the log this error now...
dman777: i have a ATI Technologies Inc Radeon XPRESS 200M 5955. when i use opacity in compiz fusion, typing on my system lags. resources are good. i've been told it is mesa. who can i email to let them know about this?
simplexe: Nov 20 00:41:33 arch kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 14
simplexe: Nov 20 00:47:06 arch kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 23
simplexe: Nov 20 00:47:28 arch kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 23
cxo: RAVE ONNNN! RADEONNNN
eosie: Does anybody happen to know whether mesa3d-dev will accept a 72kB-large message?
cxo: laughs - "kB"
EruditeHermit: airlied, saw your post
EruditeHermit: will try
eosie: cxo: I think there is an absurd limit
cxo: if its a patch, maybe put it in a pastebin
hnsr: meh, I am suddenly getting the software rasterizer after updating everything to the latest from git
hnsr: I can't really figure out why
EruditeHermit: airlied, thanks again for looking at this stuff
hnsr: mesa is compiled with r600, no errors on dmesg, nothing in xorg.0.log as far as I can see
hnsr: also recompiled libdrm, mesa, and xf86-video-ati just to be sure
cxo: hnsr, LIBGL_DEBUG=1 glxinfo
DanaG: Interesting... DRI1 is being more reliable than in the past... that's good.
DanaG: Still uses more power than fglrx, but it's less hideously MUCH more than KMS would use.
Zajec: do we use rdev->pm.sclk for anything?
Zajec: can not grep that in code
DanaG: hmm, will OpenGL 2 support be KMS-only?
hnsr: thanks cxo, that gave some helpful info, r600_dri.so is missing symbol radeon_bo_is_referenced_by_cs
hnsr: i saw a commit about that with libdrm but not sure what to make of it
MrCooper: eosie: should be fine I think, or I should be able to approve it manually
urosn: does anyone know where to find documentation for Gallium3D
urosn: ?
MostAwesomeDude: urosn: Gallium's headers in src/gallium/include are the formal API specification, and most of the non-nouveau drivers are self-documenting.
MostAwesomeDude: I wish we had better docs, but that's how it is.
MostAwesomeDude: eosie: Saw your patches and whatnot. We need to get you an account so you can keep track of those easier. :3
MostAwesomeDude: glxgears and all work now. I don't wanna push patches while half-asleep, but I can get to them first thing in the morning.
EruditeHermit: MAD: is this in gallium?
EruditeHermit: r300g
urosn: I'm interested on older radeon cards
urosn: since open source is very interesting for less developed countries
urosn: for example radeon 9250
urosn: very old card
glisse: urosn: won't have gallium
glisse: gallium is designed for GPU with shader unit, ps/vs 3.0 in microsoft world
urosn: what about X1300?
mwk: zhasha: MostAwesomeDude: what's the status of rules-ng?
EruditeHermit: urosn, should be fine
eosie: MostAwesomeDude: ok
eosie: is gonna sleep now
EruditeHermit: me too
EruditeHermit: gnight
MrCooper: MostAwesomeDude: is there a plan for non-software clears yet? I'm thinking maybe make the clear hook optional and let the state trackers deal with it
Zajec: how can I benchmark using openarena?
Zajec: there is http://dri.freedesktop.org/wiki/Benchmarking
Zajec: but cfg and demo are not available from anholt
adamk: http://adam.npark.com/anholt.cfg and http://adam.npark.com/anholt.dm_68
Zajec: adamk: thanks for backup :)
adamk: I need to ping him later and get him to replace those files.
Zajec: help, please?
Zajec: libGL error: dlopen /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so: undefined symbol: radeon_bo_is_referenced_by_cs)
Zajec: libGL error: unable to load driver: r600_dri.so
lordheavy: Zajec: need to be rebuild
lordheavy: mesa
zhasha: mwk: rules-ng what?
Zajec: ah, mesa scripts bug
Zajec: remember that
chithead: Zajec: your libdrm is too old
lordheavy: it's due to a libdrm change
mwk: zhasha: I wanted to get rules-ng to generate headers for nouveau and pq told me to ask you
Zajec: eh, already did make clean ;)
lordheavy: http://cgit.freedesktop.org/mesa/drm/commit/?id=b4312b639d56a6cad78953af0fd4f863182007e3
Zajec: ok, will rebuild both
hnsr: hm, I did rebuild mesa but that didn't help any
zhasha: mwk: I don't really do nouveau. The tools I cloned from rules-ng haven't really received much care. Your best bet is to look at nouveau's CVS
hnsr: (getting same error as Zajec here)
Zajec: hnsr: libdrm as I was told?
hnsr: oh
mwk: ok, so you don't have anything extra-cool that's not in nouveau's CVS already?
hnsr: hmm, well I did rebuild that too, but I think i will just rebuild everything again just to be sure
hnsr: not sure what order I did it in
mwk: is it used for radeon anymore?
lordheavy: libdrm then mesa
zhasha: mwk: I don't generate headers, but http://cgit.freedesktop.org/~jsindholt/rsim uses the rules-ng xml file to generate a table of all registers
mwk: ok then... I'll just take what we have in cvs then, thanks
Zajec: any idea why i don't have 3D and LIBGL_DEBUG=1 doesn't show anything/
spreeuw: using firegl?
Zajec: me?
Zajec: M82=]RV620
Zajec: ==RV620
spreeuw: no but those ati drivers maybe
spreeuw: they overwrote your mesa gl lib r so
spreeuw: see what your xorg log says during initialising r600_dri.so
Zajec: http://pastebin.com/md4e6b4b
Zajec: it's glxinfo
Zajec: (WW) RADEON(0): Direct rendering disabled
Zajec: hm
Zajec: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
Zajec: [dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
Zajec: don't get it
Zajec: Xorg.0.log http://pastebin.com/m1abda01e
Zajec: 2.0.0 IS newer than 1.17.0 :|
spreeuw: Zajec: you need 2.6.32 or 2.6.31.x with drm next patch
spreeuw: from git
mesaGL: is tormod volden in this channel ?
Zajec: maybe my drm-next is outdated
chithead: Zajec: your ddx is not kms capable
chithead: disable kms or build xf86-video-ati from git
Zajec: ok, let me recompile
Zajec: oh, great, some dependency was bumped:
Zajec: configure.ac:35: error: xorg-macros version 1.3 or higher is required but 1.2.2 found
Zajec: /usr/share/aclocal/xorg-macros.m4:45: XORG_MACROS_VERSION is expanded from...
Zajec: what are macros actually?
Zajec: it's openSUSE 11.2
Zajec: xorg 7.4 and server 1.6.x
Zajec: ok, my mistake, sorry
Zajec: i build libdrm only, not whole "drm" (with shared code and so on)
Zajec: *build
Zajec: *built
lordheavy: is there a kernel irc channel ? got a bug and would like to report it correctly (not related to radeon :-) )
Zajec: openarena: radeon_mipmap_tree.c:422: migrate_image_to_miptree: Assertion `dstlvl->width == image->base.Width' failed.
Zajec: it's mesa master
Zajec: up-to-date
Zajec: ok, it's regression https://bugs.freedesktop.org/show_bug.cgi?id=25197
kernelpanic: I built xf86-video-ati, mesa and libdrm stable according to the howto a while ago, but kwin kept crashing with 3d enabled. Now I tried using different branches, but I always get either no sane picture or the "RADEONDRIGetVersion failed" error. What are the best branches to use with a RV530LE and xorg-server-1.6.3.901-r2 (on gentoo)?
kernelpanic: and what about the firmware? the howto does not mention the word firmware, did i miss something?
adamk_: Depends on your needs. If you need/want KMS/DRI2, you should follow the guide in the topic here. And if you have any problems, we should really see the generated /var/log/Xorg.0.log file.
adamk_: As for the firmware... It comes with the kernel source. There is an option in the kernel config to enable firmware loading that you want to enable, iirc. I don't recall having to do anything special with it, though.
kernelpanic: adamk_: thanks! but, the guido offers stable/master branches. Which are you referring to? the stable one, I guess?
adamk_: Well the stable branch doesn't provide KMS from what I'm seeing in the guide. I'm going to assume that you are compiling things from source because you want an updated version that supports something (such as KMS) that your distributions version doesn't support, right?
kernelpanic: I'm quite sure that stable supports KMS, at least for up to r500. I think I had that working on the stable branch. But it kept crashing (I have no errorlog available now :|), so I tried to use master and screwed up quite badly :)
kernelpanic: I guess I'll keep trying until 6.12 and mesa7.5 work again, then I'll bug you guys with the error...
hifi: note to self: --enable-radeon-experimental-api when building libdrm
kernelpanic: ok, now I've built drm master with --enable-radeon-experimental-api, then xf86-video-ati master, then mesa master with --disable-gallium --with-dri-drivers=r300,radeon, everything in prefix=/usr/. Rebooted, dmesg says lots of nice drm things, then "[drm] Initialized radeon 2.0.0 20080528 for 0000:01:00.0 on minor 0". But Xorg.0.log still says "(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.", "[dri] radeon
kernelpanic: kernel module version is 2.0.0 but version 1.17.0 or newer is needed.". Why is that?
kernelpanic: I'm running gentoo on amd64, 2.6.31 and RV530LE
kernelpanic: oh, and drm is compiled into the kernel, not a module
hifi: make[6]: *** No rule to make target `/usr/include/gnu/stubs-32.h', needed by `radeon_code.o'. Stop.
hifi: umm
adamk_: kernelpanic, You're xf86-video-ati wasn't built with support for KMS.
adamk_: (Most likely, anyway).
adamk_: When you ran ./configure, it should have said something like "Modesetting: enabled" towards the end.
hifi: right, libc6-dev-i386
adamk_: kernelpanic, Actually it's "Kernel modesetting: yes"
adamk_: kernelpanic, If it doesn't say that, then your DDX wasn't built with KMS support.
kernelpanic: it *does* say that now (couldn't swear it did before), so I'm compiling and trying again now
kernelpanic: adamk_: restartig X should be good enough, right? or do I need to reboot?
adamk_: Yeah, after doing that, if it still gives the version mismatch, then there's something else going on.
adamk_: Yep, just restarting X is fine.
kernelpanic: adamk_: still the same :( I'm wondering whether its ok that "make install" in xf86-video-ati only installs ati_drv.la, radeon_drv.la, theatre200_drv.la, theatre_detect_drv.la, theatre_drv.la and a couple of manpages. Don't I need .so's, too?
adamk_: Yes, you most certainly do.
adamk_: The .so is the actual driver.
adamk_: Hmmm.
kernelpanic: oh, sorry, make install DOES install them, it just doesn't say so. I "rm /usr/lib/xorg/modules/drivers/*" and did make install again, the .so's are there
kernelpanic: (and the la's, too)
adamk_: Alright, can you restart X just one more time since we can only be 100% certain it installed them this time? I know it seems odd, but just on the 1 in 1,000,000 chance it didn't install them last time :-)
kernelpanic: sure
adamk_: Can you pastebin the full /var/log/Xorg.0.log and 'dmesg' after you restart?
adamk_: Someone else on here mentioned another situation where the version mismatch would happen. I'll have to see if I can find it in my channel logs.
kernelpanic: adamk_: did not help, http://pastie.org/707491 and http://pastie.org/707494
adamk_: Wait... You said that it installed the drivers to /usr/lib/xorg/modules/drivers?
adamk_: Your module path for Xorg is /usr/lib64/xorg/modules though.
kernelpanic: lrwxrwxrwx 1 root root 5 2009-09-08 22:37 /usr/lib -> lib64
kernelpanic: :)
adamk_: Oh.
adamk_: What's the output of 'cat /proc/fb' ?
kernelpanic: 0 radeondrmfb
adamk_: I'm afraid I don't know them.
adamk_: s/them/then/
kernelpanic: I do have a love/hate relationship with git, though, and I'm not too sure whether I really corectly checked out the master branches. Is there a way to check which version of libdrm and mesa is really installed? Maybe in some .h includes?
adamk_: What's the output of 'pkg-config --modversion libdrm' ?
kernelpanic: 2.4.15, and /usr/include/drm/drm.h has DRM_MAJOR 226, DRM_MAX_MINOR 15
adamk_: As for mesa... It doesn't have anything to do with this error. We're not even getting to the point of the mesa driver getting loaded.
kernelpanic: ah, ok
kernelpanic: mmh. Is there some strace magic or verbose switch I could try?
adamk_: Alright, so your libdrm would appear to be recent enough.
adamk_: Not that I know of.
adamk_: You might have to wait for someone with more knowledge than I currently possess.
kernelpanic: ouh :(
adamk_: You could try booting with the 'nomodeset' option and see if it works without KMS.
kernelpanic: one last questino: how can I check I really am using master branch of xf86-ati?
hifi: RS690 is so awfully slow, is X1200 really that bad?
hifi: even glxgears gives only 350fps when accelerated (I know)
adamk_: kernelpanic, Your definitely using radeon from git master. 6.12.99 is the version I get.
adamk_: All you should need to do is clone it with 'git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-ati' . That will always give you master.
kernelpanic: adamk_: ah, yeah, found it in Xorg.0.log
legume: kernelpanic: wiki mentions that error and mentiond dri2proto - along with other things.
legume: kernelpanic: Though your xserver seems to be new enough.
kernelpanic: legume: x11-proto/dri2proto-2.1 is installed. But the wiki doesn't give a minimum version, so I don't know whether thats recent enough
adamk_: kernelpanic, Does libdrm_radeon.so exist?
kernelpanic: adamk_: yes
adamk_: kernelpanic, Can you pastebin the output of 'ldd /usr/lib/xorg/modules/drivers/radeon_drv.so' ?
legume: kernelpanic: I am not sure what is needed - mine are all git. Maybe you could update dri2proto and rebuild.
kernelpanic: adamk_: this is me building xf86-ati: http://pastie.org/707508, this is ldd: http://pastie.org/707509
adamk_: Well we've confirmed that xf86-video-ati definitely has KMS support...
adamk_: I'm sorry, but I honestly don't know.
kernelpanic: adamk_, thank you for taking the time! I guess I'll wait around here and see.
adamk_: Yeah, agd5f or airlied might be able to help you out. It's simply a matter of waiting till they become active and catching them in a good mood. There are, of course, others who might be able to lend a hand later, so keep those links close by.
Zajec: i have to downclock GPU when it is not doing anything, do you have idea how can I check that?
Zajec: i tried checking if ring buffer is empty: radeon_ring_free_size(rdev); if (rdev->cp.ring_free_dw * 4 == rdev->cp.ring_size)
Zajec: but it seems to do not report values correctly as my performance drops from 75FPS to 18FPS
owen_: Zajec: ring buffer is just the start of the pipeline anyways
Zajec: i don't want to wait 30ms from last command submission like mjg59 tried as we can not be sure engine will process everything from buffer in 30ms
Zajec: owen_: seems so
owen_: Zajec: there are various types of "breadcrumbs" support you can use to find out when things finish
Zajec: owen_: i fell like engine is taking from buffer and buffer it empty quite fast but it seems to still process sth
Zajec: owen_: what do you mean?
Zajec: owen_: breadcrumbs? should I google it?
owen_: Zajec: maybe if there's free space in the submitted command buffer at the end the kernel could add stuff to there
Zajec: owen_: what kind of stuff? what for?
Zajec: owen_: i guess we align with NOP currently
owen_: tries to recall any details
stikonas: it seems that screen is not properly updated with mesa master after mipmap-rework was merged
owen_: Zajec: it's definitely different between versions too; more capabilities were added in later generations
Zajec: stikonas: we already have some bug reports on that
Zajec: owen_: sry, but I really don't understand your idea... what do you want to add at end of buffer?
Zajec: and what is purpose of that?
owen_: Zajec: for an example of the kind of stuff I"m talking about, see R5xx_acceleration.pdf, section 4.9
Zajec: owen_: let me see
owen_: (Not the stuff on the first page, but beyond that about sync pulses from the back-end of the pipeline)
Zajec: owen_: 4.9? what is your version of pdf file?
Zajec: i have v1.4 without section 4.9 :)
owen_: 1.3
owen_: Is there a section titled " Command Stream Synchronization" ?
Zajec: owen_: ok, it's 5.9 now
owen_: Yeah.
owen_: Anyways, basically the point is that you can program the card to tell you when it finishes it, but it is going to require extra register writes, etc
owen_: You could do it by submitting an additional command buffer from the kernel. But maybe you'd get some extra efficiency by sticking that into unused padding space. Or maybe that's just complexity that isn't needed.
owen_: Probably figuring out how to program the interrupts is the hard part :-)
Zajec: owen_: ok, understand the idea now
gnubien: hi, is the radeon hd3x00 / hd4x00 780g/790g chipsets video supported by open source radeon video driver?
Zajec: i even saw we have scratch implemented
Zajec: it's in some writeback test
adamk_: gnubien: Yes, if you use development code.
Zajec: gnubien: plus what do you expect? 2D? Xv? 3d?
gnubien: adamk_: ok, dev code still early alpha or maturing?
gnubien: Zajec: just 2D
biotube: gnubien: it's fairly mature
biotube: only had one noticable 2d bug for me and that was a while bug
gnubien: biotube: nice, looking into buying a new motherboard with 780g chipset
gnubien: will the vesa video driver work with 780g chipset before i compile radeon source tarball?
Zajec: gnubien: should work, of course with limitations
gnubien: Zajec: right, just need CLI to install linux distro
gnubien: adamk_: any idea when 780g will be included in radeon stable release, not dev release?
Zajec: gnubien: er, is it not?
biotube: Zajec: well, the DRM certainly isn't
gnubien: anyone got the url of the radeon changelog or is it only in the source tarball?
Kano: hi, is there any known problem with current git?
biotube: gnubien: 2d support for r600 and r700 is fairly old
Kano: which will be fixed tody
Zajec: gnubien: err
Zajec: gnubien: so what are you talkig about radeon stable release OR drm (kernel) release?
gnubien: biotube: is the 780g chipset a r600 and r700 video card?
Zajec: kernel 2.6.30 already supports 2D for r6xx/r7xx
adamk_: Yeah, for 2D I'm fairly certain it's supported now.
Zajec: gnubien: it is
gnubien: Zajec: ok, thanks to all
Zajec: :)
glisse: Zajec: to achieve that you need to take cs mutex
glisse: and wait for last fence to report
glisse: then you know the GPU is idle and won't get anymore work until you release cs
Kano: glisse: will be patches needed for r600+ and .32 kernel?
Zajec: glisse: but i don't want to stop CP
Zajec: glisse: by taking mutex
Zajec: glisse: I just want to check if it has any more work to do
Zajec: glisse: if it doesn't have work to do, i'll downclock
hifi: even 9600 Pro beats X1200 on KMS
Luzipher: Hm, on current mesa git, should the glxinfo version string say 7.7 or 7.8 already ?
biotube: 7.7 got branched off a day or two ago
Luzipher: yup, but did they already change the string ? I've lost hardware accel (3d only) and have no idea why ...
glisse: Zajec: there is no other way than taking this mutex
glisse: otherwise cmd can be submited while you are downclocking
glisse: Kano: it should work
Luzipher: ah yes ... version is bumped to 7.8 ... so there is sth wrong with my installation ...
adamk_: Luzipher: Does /var/log/Xorg.0.log show that Direct rendering is enabled?
Luzipher: adamk_: yes: (II) RADEON(0): Direct rendering enabled
adamk_: Can you pastebin the full output of 'LIBGL_DEBUG=verbose glxinfo' ?
Zajec: glisse: you don't get what I want :)
Zajec: glisse: i don't want to downclock... when I'm downclocking, I get that mutex
Luzipher: adamk_: http://pastebin.com/m551df11c ... but I saw the error already, loading r600_dri.so fails
Zajec: glisse: i need heuristic IF i should downclock
Luzipher: (just at the very beginning of the output)
adamk_: Luzipher: "undefined symbol: bswap_16"
Zajec: glisse: if engine is processing sth I don't want to downclock
adamk_: Luzipher: I'm pretty sure you need to update libdrm.
Zajec: glisse: if engine finished processing i want to downclock
Zajec: glisse: i miss detection if engine is or isn't processing
Luzipher: adamk_: I did update libdrm together with mesa ... and it's git as well ... but I'll try again, thanks for the hint
glisse: Zajec: it's not reliable
glisse: Zajec: no other way than: lock(cs) waitlastfence() downclock() unlock(cs)
glisse: there is no other reliable way to get the engine idle for enough time for downclock to finish
Luzipher: adamk_: I probably forgot rebuilding xorg-server ... thanks for the hint in the right direction :)
adamk_: I doubt that the X server needs to be updated.
Luzipher: adamk_: not updated but rebuilt ... at least that's what my gentoo ebuild says I should do ... last libdrm change is 41h ago, so I had that for sure already
Luzipher: well ... I'll no in a few minutes anyway ;)
Luzipher: s/no/know
Luzipher: adamk: you were right ... rebuilding xorg-server didn't help ... :-/
Luzipher: adamk_: any other ideas ? :)
adamk_: Not really. I'm updating right now to see what happens.
legume: Luzipher: Try running make distclean before updating & building mesa.
legume: Luzipher: That error was mesa but only briefly a couple of days ago IIRC.
Luzipher: hm, one or two days ago glxinfo failed with a segfault for me ...
lurkinglurk: tried oprofile on the touhou bug: https://bugs.freedesktop.org/show_bug.cgi?id=25142#c3 any ideas?
Luzipher: legume: gentoo starts from a clean copy of the git repository anyway (i believe) ... so i doubt make --distclean would help
legume: Luzipher: OK, I haven't got a clue what gentoo does or how up to date it is.
Luzipher: now this is interesting ... how can my branch be ahead of origin/master by 119 commits if i never touched it ...
Luzipher: legume: probably it's gentoo's fault, I'm checking right now ... :)
legume: Luzipher: Mesa history sometimes changes when they merge.
Luzipher: legume: ohh, ok ... I actually have no real idea about git (and no clue about "history") :) ... well, I'll try with a new repository ...
adamk_: Well the latest from git works fine here and reports 7.8-devel
Luzipher: adamk_: mine reports 7.7 ... so it's definitely something wrong with mesa
Zajec: glisse: I think you do not understand me still ; "there is no other reliable way to get the engine idle for enough time for downclock to finish"
Zajec: glisse: i don't want to get engine idle and i do not want to downclock if and do not want make sure it has enought time to downclock
Zajec: glisse: i just want to check if this is idle
Zajec: glisse: just check, only check that
Zajec: glisse: and if this *is* idle then i'll indeed lock mutex, downclock, free mutex
Zajec: glisse: but first i need to know if engine is idle to determine if I even want to downclock engine
Kano: hi, whats the purpose to make radeon not be able to compile with older xorg macros
Kano: even radeonhd has got no problem
Kano: only the 6.12 branch works directly
mjg59: Kano: Because nobody's written support for building against old X?
mjg59: (Not that I'd inherently expect it to be added)
Kano: bevor it was enough to revert 76af48c43f829e7aebacc9f2a623823fa26ee22b
Zajec: mjg59: it was compiling fine before commit
Kano: now you explict check against the macro version
Zajec: Kano: checkout to one commit older
Zajec: Kano: unfortunately you won't up to date
Luzipher: Well, now I got mesa 7.8 but still the same error ... I guess I'll try resetting the repository for libdrm as well ...
glisse: Zajec: still takes the mutex so you don't do a test for nothing
glisse: otherwise it will be : if(is_idle()){lock(); if(is_idle()) { downclock }
glisse: rather than lock(); if (is_idle()) downclock(); unlock()
glisse: and for knowing if engine is idle you first wait for the lastestfence
glisse: there is a function which does that
Kano: hi libv , did you notice that problem too?
Zajec: glisse: ahh
glisse: once fence expired than you can check others bit to double it's idle
Zajec: glisse: probably wait for the lastestfence with some timeout?
glisse: you can query fence statis without waiting
Zajec: ok, let me read about what fence is ;)
glisse: status
Luzipher: adamk_, legume: got it working by deleting gentoo's git trees. Seems this doesn't really work as I thought in gentoo. Thanks for your hints :)
kernelpanic: Luzipher: what ebuilds are you using? an overlay's?
Luzipher: kernelpanic: x11 overlay
Luzipher: kernelpanic: -9999 ebuilds for mesa, libdrm, xf86-video-ati
jweiss: i just upgraded from fedora11->12, now my 2nd monitor shows 'input out of range' when i try to use its native res (1680x1050) - any idea where to start fixing this?
jweiss: anyone?
fpoibaf: jweiss: I had a similar problem with an intel card: http://bugs.freedesktop.org/show_bug.cgi?id=23833
fpoibaf: in my case it worked however
jweiss: fpoibaf: any way to work around?
kdekorte: jweiss, what does xrandr say?
jweiss: fpoibaf: kdekorte: huh, rebooting seems to have fixed it. weird.
kdekorte: did you update anything between reboots?
jweiss: kdekorte: nope
jweiss: but that was my first reboot after my initial boot after upgrading
kdekorte: jweiss, might want to run yum update, and then reboot again
jweiss: so, i guess something wasn't quite right
jweiss: kdekorte: there were no packages to install before or now
jweiss: was already up to date
kdekorte: also, gnome-display-properties might help
kdekorte: I'm on F12 and I got updates today
jweiss: kdekorte: i just upgraded today, so i have the updates alerady
Zajec: glisse: could you tell me sth more about fence? i can not find this in R5xx accel pdf
Zajec: glisse: and just reading code doesn't give me much idea
Zajec: i see there is fence_driver and just fences
agd5f: Zajec: the CP scratch registers
agd5f: Zajec: you place a write to the scratch regs in on the ring after an IB
agd5f: the write writes a timestamp to a scratch reg
agd5f: the driver then checks the scratch reg to see what the current timestamp is and compares it to what it expects
Zajec: ahh, so that's what owen_ today suggested
agd5f: that tells you that a particular command has completed
Zajec: already implemented
Zajec: agd5f: so fence is just command to write timestamp to scratch?
agd5f: Zajec: yeah. buffers pend on a fence
Zajec: agd5f: sry, "pend"?
Zajec: can's see that in dictionary :)
agd5f: so you know you can free an IB for example when the the fence it depends on comes up
Zajec: clever :)
agd5f: you also know if the pipeline is idle if there are no pending fences
Zajec: agd5f: thanks, now I'll read code again, hopefulyl with better undestanding :)
Zajec: in radeon_fence_driver i've 3 list_head: created, emited, signaled
Zajec: what are that lists?
Zajec: created is probably for fences attached to IB, but not yet sent to CP
Zajec: emited for IB sent to CP
Zajec: and singaled for IB already proccessed by CP?
Zajec: is that right?
agd5f: I think so, but it's been a while since I read that code
lurkinglurk: I'm trying to build the r300-blit branch from http://cgit.freedesktop.org/~osiris/mesa. Can I follow the instructions for building the latest stable version in http://wiki.x.org/wiki/radeonBuildHowTo#head-3319dbcc49ca1fdfe7d790fb74e3ed29e36547e7 or do I have to do the whole bleeding edge stuff (http://wiki.x.org/wiki/radeonBuildHowTo#head-1191ac0cb6acf7d6f2bb129bb55dc09e8af776fe)?
soreau: If you want to build osiris' r300-blit branch, that's the branch you are building which != stable branch
soreau: It's probably closer to master branch than anything
llurk: damn it
llurk: looks like i only need libdrm for now, i hope the 2.6.31.6 kernel is fresh enough, don't want to go -rc
soreau: Depends on your card and what you want to do
soreau: If you want 3D, you can't just pick and choose what components you would like to use
llurk: r500 card and testing his mesa
hifi: on ubuntu karmic you only need libdrm and the mesa branch
llurk: so it has to be at least libdrm, xf86-video-ati and mesa
hifi: DDX is not important
llurk: I use arch, so i got all the stable stuff
Zajec: agd5f: ok, it just seems that fences use "seq", not timestamp
Zajec: agd5f: rest starts looking reasonable for me :)
llurk: hifi: so no xf86?
hifi: nothing important regarding osiris' branch in master ddx
DanaG: interesting... with dri1, water and ezoom crash Xorg. or perhaps it's just Mesa calling "exit".
soreau: DanaG: Does video work better for you now?
DanaG: Yeah, XV is not flickering like it used to; at least that's good.
Zajec: is compiling downclocking based on comparing last emitted fence with last signaled
Zajec: let me check this ;)
Eddi|zuHause: speaking of which, what exactly is this "video tearing" i keep hearing about? i can't imagine what that would look like
Kano: Eddi|zuHause: thats the same as in games without forced vsync
Kano: Eddi|zuHause: http://en.wikipedia.org/wiki/Screen_tearing
Eddi|zuHause: aha, thanks.
DanaG: hmm, anyway, so how do I make ezoom and water not abort Xorg?
DanaG: Guess I need to run it through gdb, perhaps?
llurk: ./configure gives me the warning: "unrecognized options: --enable-maintainer-mode" for a freshly fetched libdrm. Shouldn't be a problem?
llurk: ah, it dissappeared after retry, good
DanaG: hmm, yeah, ezoom and water disabled, for now.
DanaG: Now, to see how well dri1 suspends and resumes...
soreau: adamk_: Do kwin effects work with the latest driver there on any of your cards adamk_: soreau: With drivers updated this morning they work fine (via opengl) on my x1900.
soreau: adamk_: Is that to say it was not working before this morning?
adamk_: No, it was fine even before the update this morning.
fpoibaf: airlied: please take a look at this: https://bugs.freedesktop.org/show_bug.cgi?id=22851#c6
soreau: adamk_: ok thanks
spstarr: hm
llurk: "After changes to the files you have to restart your system to make ld reload configuration." <- why not just use ldconfig?
llurk: oh damnit, following the wiki didn't work, still stuck with /usr/.../r300_dri.so
adamk_: llurk: What exactly is happening?
llurk: it uses the wrong r300_dri.so, not the one I installed in /opt/..., but the one which came with my distro
llurk: wait, why do I have "OpenGL version string: 1.5 Mesa 7.7-devel"????
adamk_: If you built Mesa from git today, it should be 7.8-devel.
llurk: no, i have the one from osiris, could be he is still on 7.7-devel
biotube: llurk: what does echo $LIBGL_DRIVERS_PATH say?
adamk_: llurk: Yes, he could definitely still be on 7.7-devel.
kdekorte: llurk, mesa master seems to have the patches from osirus in it as of today
llurk: $ echo $LIBGL_DRIVERS_PATH
llurk: /opt/xorg/lib/dri/
kdekorte: but I could be incorrect
biotube: llurk: that's right...
llurk: this is bad, it did the right thing with mesa, but fucked somehow up with dri
kdekorte: llurk, you can set LIBGL_DEBUG=verbose to see which dri is loaded, and then you can use LIBGL_DRIVERS_PATH to tell it where to look for them
llurk: thanks
kdekorte: LIBGL_DEBUG=verbose glxinfo should tell you which dri is loaded
llurk: ohdamnit
llurk: 64vx32bit problems ahead
llurk: libGL: OpenDriver: trying /opt/xorg/lib/dri//r300_dri.so for glxgears
kdekorte: on Fedora when building 64bit libs we use --libpath=/usr/lib64, for 32 bit --libpath=/usr/lib is used
kdekorte: that keeps them separate
llurk: yes, but r300_dri.so is used by the xorg-server
llurk: as far as top told me
llurk: except you can run 32+64bit code in the same address space
kdekorte: usually the X server is 64bit, but you can run 32bit code that connected to the 64bit xserver
kdekorte: the 32bit DRI is loaded as needed
kdekorte: by the 32bit mesa
kdekorte: slight performance hit when using 32bit DRI on a 64bit setup
llurk: but why did top show X as eating up all space and oprofile r300_dri.so?
kdekorte: llurk, would need to know what you are running to see that
llurk: and i can't find a 32bit dri :|
kdekorte: on my machine 32bit code glxgears I get about 1950fps, 64bit glxgears I get about 2100 (HD3650 + Q6600 @ 2.4Ghz)
spreeuw: nice
spreeuw: almost 10% faster
spreeuw: how about real world apps
spreeuw: like nexuiz
kdekorte: spreeuw, quake3 on 32vs 64 no difference... I only have 32bit NWN and it is 40+fps
adamk_: llurk: You are using a 64 bit distribution, but you are using a 32 bit game via wine, right?
llurk: yes
spreeuw: ah nwn, i did that on r200
adamk_: llurk: Then you need the to update your 32 bit installation of Mesa.
kdekorte: trying 32bit secondlife now
llurk: ohright
adamk_: llurk: If you don't have a 32 bit installation of Mesa installed, then whatever application you are using would fall back to indirect rendering.
kdekorte: yeah I have two git pulls of mesa, one that I build in 54bit and one that I build in 32bit
adamk_: llurk: Which might explain why r300_dri.so was showing up in oprofile that way.
adamk_: 54bit? That's impressive.
kdekorte: haha
llurk: adamk_: indeed, all my 32bit programs use indirect rendering
kdekorte: it is right next to my 31bit mainframe
adamk_: llurk: So you don't have a 32 bit installation of Mesa :-)
llurk: adamk_: but how does the indirect rendering cause the problems? Can't i just make it so that it does indirect rendering with the new r300_dri.so?
adamk_: indirect rendering is done via the r300_dri.so driver loaded by the X server.
adamk_: So you need to get the X server to load the newer r300_dri.so
llurk: so xorg-server uses the wrong one
adamk_: "Wrong one"? No. The older one, probably, yes.
adamk_: llurk: But, seriously, if you want any sort of decent performance, you need to install the 32-bit libraries.
llurk: so how can i get it to use the right/new one?
cxo: build a 32bit version
adamk_: Copy it to the directory that Xorg is looking for.
adamk_: Then Xorg will load the new one.
llurk: oh right, i could use the hack and slay one
adamk_: But, again, really,, install a 32 bit version of mesa.
kdekorte: yeah, you need 32bit and 64bit versions on a dual arch machine
adamk_: Otherwise 32-bit apps will continue to use indirect rendering, which is not going to give you good performance 99% of the time.
llurk: warning: lib32-mesa-7.6-2 is up to date -- reinstalling
llurk: seems like i need to update some lib32-drm/xf86
llurk: yay
kdekorte: for r300 distro packages are pretty decent, but it sounds like you want to try the new stuff
cxo: I build 32bit mesa with these params, --libdir=/usr/lib32 CFLAGS=-m32 LDFLAGS='-L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32'
kdekorte: With second life I get the same frame rate if I am in low quality or hight quality settings
soreau: kdekorte: That's what you get for leading a double life ;)
kdekorte: hehe
llurk: this is weird, i have lib32-mesa, lib32-libdrm, lib32-libgl, there doesn't seem to be a lib32-ati-dri for my distro, no wonder i only get indirect rendering
llurk: ok, copied the r300_dri.so over the old one and restarted X, seems to work so far
kdekorte: did you copy a 64bit one over?
llurk: yes, 64->64
llurk: i don't wanted to waste more time
llurk: now i get 48fps, much better
llurk: except the in-game rendering is broken
llurk: looks like when you set a too high resolution to an old CRT
llurk: which means I have to recompile for lib32 the whole way to rule out it is an indirect rendering bug
adamk_: llurk: Yep.
spstarr: osiris__: ping
osiris__: pong
llurk: I thought I can use the easy way out and just use the PKGBUILDs from arch, but it seems like they import straight from a 32bit repository
cxo: Real men roll their own
adamk_: But what do you do, cxo? :-)
cxo: has been rolling his own since 1969
llurk: cxo: these parameters just with ./configure?
llurk: --libdir=/usr/lib32 CFLAGS=-m32 LDFLAGS='-L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32'
cxo: here, http://en.pastebin.ca/1679779
cxo: thats what i use to build 32bit mesa
cxo: obviously you might have to change some of those values depending on which card you have and how our distro treats 32bit libs
llurk: yeah
cxo: you need a similar config for drm as well
cxo: build drm first, then mesa
llurk: the usual stuff, except now gcc says no
cxo: pastebin the error
cxo: reboots
llurk: it doesn't have gnu/stubs-32.h, so configure fails at the first test
cxo: Holy! I just pulled the latest stuff, and my glxgears FPS has doubled since a build from 2 days ago
cxo: I had 9000fps, now I have 18000fps
cxo: pats airlied and co on the head... good open source developers, good
llurk: congratulations. And I found out I just need to recompile the whole gcc so I can compile mesa 32bit
cxo: well you dont need to recompile gcc, just install the 32bit toolchain from your distro
llurk: or do a chroot
llurk: cxo: there is none
cxo: there has to be
llurk: http://wiki.archlinux.org/index.php/Arch64_FAQ#Can_I_build_32-bit_packages_for_i686_inside_Arch64.3F
cxo: damn
hnsr: 18000fps? my epenis is sad :( only 3k for my radone 4850 :p
cxo: go with the gcc-multilib
cxo: thats odd, you should have something similar, i have a 4870 with 512mb
hnsr: it's been at 3k ish fps for ages, but I dunno, I have a feeling something is not quite right
hnsr: not that 3k fps isn't fat enough
hnsr: fast* but other apps are somewhat slowish too
twnqx: so you're getting close to my gtx285 :C
hnsr: blender feels sluggish, quake3 often drops below 60fps
hnsr: 2d is blazing fast though
hnsr: with KMS turned off that is
cxo: but it didnt translate into game performance, i'm still down 30% in FPS from a much older version of git in openarena
cxo: (was 100fps, now 70fps)
cxo: (home brew demo)
cxo: twnqx, what do you get on openarena? I bet its a lot more though
twnqx: dunno, i don't play on linux
llurk: nice, the creator of multilib also provides a binary
cxo: Why does enabling compiz reduce performance by 75%?
spreeuw: its an extra thing swallowing video memory?
spreeuw: so is 32 rc8 good enough for mesa git or not?
llurk: doesn't look like I'm able to build libdrm 32bit :| has problems with udev and there is no 32bit counterpart for it
cxo: is using 2.6.32-rc8
cxo: llurk, your distro sounds like some really 64bit purist thing.
cxo: You might not even have 32bit libc
llurk: is it normal that even though I'm configuring libdrm with --disable-udev it still wants to link against it?
cxo: udev is not a library
llurk: cxo: I have the bare minimum 32bit, yes it's 64bit pure for most parts
cxo: udev basically means dynamic device nodes
llurk: but I choose it that way because it's annoying to install a complete 32bit system alongside for firefox or similar things
llurk: cxo: but it could use mknod
cxo: i guess
llurk: or am I getting something wrong
spreeuw: yep you can mknod ontop
spreeuw: or replace it all
spreeuw: udev is handy for some usb shit though
llurk: then something is weird, you can configure libdrm with --disable-udev and it says it will use mknod instead, but it still wants to link against udev
gsedej: is there release date of stable openGL 2.0 support?
llurk: cxo: thanks for help, but getting 32bit going is too retarted, can only test it for 64bit
gsedej: is there known release date of stable openGL 2.0 support for radeon driver?
Ghworg: When it's ready
lordheavy: before ten years
gsedej: ok :D
kdekorte: the list to get to 2.0 is getting shorter, but still some big things to do
meoblast001: hi
meoblast001: i'm assuming this answer will be "no", but does the radeon driver run on MINIX?
MostAwesomeDude: It runs anywhere X runs.
meoblast001: ok
meoblast001: that's good
cxo: Open Sauce baby, restecp!
MostAwesomeDude: Res...tech-up?
ajax: there hasn't been a build of X for minix in a long time though
MostAwesomeDude: "Yes. You gots ta be restecpin' each otha."
meoblast001: i'm still trying to figure out how to install MINIX
cxo: remembers one of his undergrad profs going on about how amazing Minix was
ajax: i'm still trying to figure out why to install minix
cxo: Yeah, the linux scheduler kicks ass these days. You dont need minix for anything
llurk: You never needed minix for anything
cxo: That got me thinking. What about those guys on opensolaris. They can have mesa and ddx and X, but they need their own kernel bits right?
adamk_: Correct. And they don't have those kernel bits yet.
spreeuw: they do have dri right?
cxo: But I guess porting Linux kernel code is easier than writing things from scratch
cxo: I was reading the feature list for Chrome OS and one of the things was "Stores your wifi settings on your google account"
cxo: And I was like WTF? Whats the point of storing wifi settings online?
cxo: Unless of course there is a local database that just caches your google account
EruditeHermit: hello
cxo: yellow
flyback: suddentely feels cold :/
flyback: been sick to his bowels too
EruditeHermit: fever?
spreeuw: take a good long dump with your favourite scifi book
spreeuw: 67.3 FPS on 1920x1280 glxgears
spreeuw: oops 1920x1200
spreeuw: upgraded to 32rc8
spreeuw: still get this nexuiz crash
spreeuw: bo(0x166fc088, 221184) is mapped (-1) can't valide it.
spreeuw: invalid bo(0x166fc088) [0xD3E09000, 0xD3E61000]
spreeuw: gonna try a clean rebuild of current mesa git too
eosie: osiris__: i am getting lots of "implicit declaration of function 'radeon_bo_is_referenced_by_cs'" with mesa master, r300 classic
osiris__: eosie: you need current libdrm
eosie: osiris__: oh, i see, thanks
AndrewR: hey, great respect for //#define R600_ENABLE_GLSL_TEST 1 (from someone who really only started to understand how complex OpenGL is)
cxo: huh?
spstarr: osiris__: ping
osiris__: pong
spstarr: osiris__: im ready for further tests
osiris__: spstarr: I need to reproduce it on my machine, otherwise debugging won't be that easy
spstarr: oh, ok
llurk: oh, you are *that* osiris?
spstarr: heh
spstarr: hes a radeon folk
eosie: osiris__: FYI, piglit/fbo-clearmipmap is broken on current r300c master (RV530) and it worked before
osiris__: eosie: can you bisect it?
eosie: I guess I could ;)
MostAwesomeDude: eosie: Started going through your patches. Don't expect them to all hit master at once. :3
eosie: MostAwesomeDude: if you have any objections, let me know
MostAwesomeDude: eosie: Well, a couple of them are funky and a couple of them don't match what r300 classic is doing.
MostAwesomeDude: Just trying to keep the number of outstanding bugs down.
phercek: I just updated mesa, libdrm, agd5f drm module for r6xx 3D and xf89-video-ati from git and when i move a windows it is sometimes not drawn on the new position; resize always fixes it. Is it something known?
MostAwesomeDude: eosie: One down, twelve to go. Thanks for your patience.
Tanktalus: phercek: which xorg-server, and which card? :-)
Tanktalus: I'm still hoping for a fix to the repaint-during-scroll issue that seems new with xorg-server 1.7...
phercek: Tanktalus: RV670PRO, X.Org X Server 1.7.1.901 (1.7.2 RC 1)
Tanktalus: May be related...
phercek: yes scroll is sometimes a problem too, but it happens with move more often
Tanktalus: If you check your dmesg, do you get a bunch of "*ERROR* sending pending buffer" messages in there?
phercek: yes, I do
Tanktalus: Sounds related, then.
koolfy: I get some visual garbage happening in pidgin's conversation window when there are more than one tab, with Xpress200M, xorg 1.7 and the drivers from git
phercek: Tanktalus: cool; thanks for looking at it; any ETA at all yet?
Tanktalus: koolfy: same question about dmesg ;-)
Tanktalus: phercek: I'm a user, not a dev :-(
phercek: ach! :)
koolfy: Tanktalus: no, nothing similar in my dmesg
rikkman: accelerated 3D on opensolaris?
rikkman: ati rv370
koolfy: ok, that was fast :D
Tanktalus: phercek: http://bugs.freedesktop.org/show_bug.cgi?id=24300
phercek: Tanktalus: thanks
edt: Mesa build from git is still fscked up. Yesterday I opened 25193 against mesa (its now closed - problem is not fixed here). With todays git, I DRI2 activates again, but the corruption (lots of background artifacts) mentioned in the bug report is still present.
MostAwesomeDude: eosie: I'm gonna NAK patch 6 (is_buffer_referenced) changes for now. There's a new set of functions in libdrm_radeon to do this a bit better, and also I'm not totally convinced that we actually need to return anything useful there.
edt: agd5f you awake - 25193 is only half fixed here.
flyback: CANUCK
Tanktalus: Yup, I'm a Canuckian. So?
agd5f: edt: what's wrong?
edt: pulling in today's git allows dri2 to start ok. The problem with artifacts i the background still exists. When I start a kterm large part of it appear on other parts of the screen. Update from typing do not always appear in the kterm until an enter is pressed. Wierd corruptions... I am now recloning the repo to see if that helps.
edt: maybe there was more than one merge error...
Tanktalus: wonders why painting is so slow, and if that is related to the drm:radeon_cp_indirect problems...
eosie: MostAwesomeDude: do you mean that libdrm_radeon will resolve this issue for us?
MostAwesomeDude: eosie: Well, libdrm_radeon should have a call that will tell if buffers are referenced.
MostAwesomeDude: I think osiris added it.
MostAwesomeDude: Also, as with i915g, we don't actually hand off mmaps of VRAM, so we might never actually be referencing HW.
MostAwesomeDude: But I'd have to check with Jakob about that.
agd5f: edt: I don't think there was a merge error, I think it was user error at least far as bug 25193 is concerned
agd5f: edt: sounds like you are having a different issue
MostAwesomeDude: eosie: The patches that I haven't pushed are part of the SWTCL cleanup, or depend on it. I get an abort when I apply all of them and run glxgears. Could you see if you also get this?
eosie: MostAwesomeDude: is_buffer_referenced - the osiris's function in libdrm is the same as mine, I didn't notice... well, I meant referencing by CS, not hw... anyway, it should be fixed somehow sooner or later
eosie: MostAwesomeDude: do you mean abort with swtcl or hwtcl?
cxo: DudesAwesomeNick is too long
edt: agd5f I am the original reported. What was the user error?
cxo: needs a greesemonkey like script for xchat to hash nicks into 3 characters
edt: notes gezz my typing is bad tonight
edt: s/reported/reporter/
agd5f: edt: sorry, I was referring to florian
eosie: MostAwesomeDude: there is a segfault with swtcl because it tries to emit vertex shader, which is uninitialized, do you mean this?
MostAwesomeDude: eosie: Nope, I'm trying the HW TCL path.
agd5f: edt: what does LIBGL_DEBUG=verbose glxgears give you?
MostAwesomeDude: cxo: I tried going as "MAD" for a while, and other abbreviations, but nobody recognized it.
edt: with todays build it just works (no debug output and gears runs) I still get corruption though.
MostAwesomeDude: Also it's only 15 letters. "CorbinSimpson" would only be a 2-character savings.
MostAwesomeDude: eosie: Here, lemme pastebin.
agd5f: edt: do you have hw rendering?
cxo: how about just Simpson
MostAwesomeDude: cxo: Already taken.
MostAwesomeDude: eosie: http://pastebin.com/m3355631
MostAwesomeDude: Besides, I've had this nick longer than any other, and I've grown fond of it even though nobody knows what it means. So laziness wins.
cxo: What does it mean then?
edt: agd5f I'll try again once the clone finishes (its moving at a glacial pace). Yes today I have hw rendering, yesterday (when it was reported sw rendering)
edt: so the corruption seems to be independant of the type of rendering
edt: it does go away if I use 7.6 or reset --hard back to the commit mentioned in 25193
edt: just to reiterate. The only change to 'fix' the problem is to revert mesa.
MostAwesomeDude: cxo: Bill & Ted.
cxo: oh
eosie: MostAwesomeDude: no idea what's wrong, it doesn't make sense to me, I think I didn't touch translate_vertex_shader, I wish I could debug it
biotube: hmm...
biotube: r600_dri.so: undefined symbol: checkStackDepth
biotube: trying to test GLSL
MostAwesomeDude: eosie: Well, you're on an r500, so it's a non-r500 path.
MostAwesomeDude: I'll dig in a bit more, but it'd be really cool if we could take these patches and make them bisectable across HW TCL chipsets.
eosie: MostAwesomeDude: to make it bisectable, you should merge 0003 and 0004 together
MostAwesomeDude: eosie: Yeah, at the least.
MostAwesomeDude: Or can you separate all the others?
eosie: MostAwesomeDude: I can
eosie: I think ;)
eosie: is working on it
Vash63: Hmm. My taskbar is flickering on and off.
Vash63: When composited with OpenGL.
edt: agd5f still have the problem post clone. Looks like gentoo's -9999 ebuild sets up without debug... build with debug enabled I get:
edt: LIBGL_DEBUG=verbose glxgears
edt: libGL: OpenDriver: trying /usr/lib64/dri/r600_dri.so
edt: 5037 frames in 5.0 seconds = 1007.353 FPS
agd5f: looks ok
edt: and HW render: Mesa DRI R600 (RS780 9614) 20090101 TCL DRI2
agd5f: edt: can you bisect it?
edt: It would be ok if there was not corruption all over the screen. Most obvious corruption occurs when moving windows. They leave pieces of themselves all over the screen...
flyback: CANUCK
flyback: bites edt
edt: agd5f I was hoping you will not ask that... I should be able to do it though
edt: flyback to top it off I lived in Labrador - where real FLYS live
biotube: anybody got any idea why an inline function would show up in the symbol table?
edt: must be why I _hate_ bugs
flyback: flyback is a type of electrical transformer
flyback: YOU TUPID CANUCK
flyback: :P
edt: when a fly bites its a BUG
spreeuw: GL_VERSION: 1.5 Mesa 7.8-devel
edt: grins
spreeuw: hey
edt: off to bisect
flyback: radeon 7000's are ok for video playback and basic 2d right?
flyback: might have to use something other than ati for a basic 2d card with tv out
flyback: :/
EruditeHermit: airlied, you about/
flyback: hmm
flyback: even low end radeons tend to go $20's or so on ebay :/
flyback: hmm
flyback: radeon 7000 is +5 pci only
flyback: ick
EruditeHermit: can anyone help me with this compile error in drm-2.6
EruditeHermit: http://pastebin.com/m4dc0f543
cxo: EruditeHermit, make menuconfig, go to drivers, staging and deselect all that crap
cxo: you dont need it
cxo: just leave radeon
edt: agd5f I get as far as afe84fa698eae3e035e967589f0a8d55f6a83698 and get errors building: r600_texstate.c:652: error: 'struct _radeon_mipmap_tree' has no member named 'firstLevel'
EruditeHermit: cxo, can I remove all the staging drivers?
edt: is there a way to tell bisect to go ahead or behind a few commits?
cxo: EruditeHermit, yes, all except the radeon one
EruditeHermit: radeon isn't in staging
EruditeHermit: in that tree
cxo: oh i guess they moved it
cxo: EruditeHermit, wait, are you sure? I'm using 2.6.32rc8 and there is radeon under staging
EruditeHermit: hmm
cxo: go through it one by one and if you dont know what it does, then just remove it :)
cxo: That section is purely experimental stuff
EruditeHermit: oh I see it
EruditeHermit: ok how do I restart the kernel compile without redoing every module
EruditeHermit: took 2hrs to get here
cxo: 2hours? didn't you customise the kernel at all? just hit make, it'll continue from where it left off?
cxo: it will continue from where it left off
EruditeHermit: cxo, i am using the Ubuntu kernel compile method
cxo: I have no idea what that is. But as long as its powered by GNU Make, it won't rebuild things it doesnt need to
chi: hrm, my mouse shows up as a black box. also i can't see anything i type in a aterm or xterm =o
chi: any known bugs like that?
chi: i'm using xf86-video-ati-6.12.4 with xorg-server-1.6.3.901-r2
edt: agd5f and the winner is (25193 corruption)
Ronis_BR: airlied: hi fellow, are you there?
edt: agd5f: commit 286bf89e5a1fc931dbf523ded861b809859485e2
edt: agd5f: Author: Maciej Cencora
edt: agd5f: radeon/r300: no need to flush the cmdbuf when changing scissors state in KMM mode
agd5f: edt: thanks. can you re-open the bug and put that in there?
edt: already done
chi: =/
edt: now to see if reverting the bad commit fixes HEAD
eosie: MostAwesomeDude: ping
edt: agd5f Just to confirm, reverting 286bf89e5a1fc931dbf523ded861b809859485e2 fixes the corruption here (report updated with this info).
cxo: chi, all sounds really old. Have you tried upgrading? Everyday there has been 1000s of changes in the code
chi: cxo, will do now
chi: actually 6.12.4 is the newest in portage
chi: did you mean xorg?
flyback: http://en.wikipedia.org/wiki/POCSAG <--- sounds like someone molesting a atari 2600
flyback: the sound clip
Bigshot_: adamk: can you check my xorg.0.log and tell me wtf is the problem? http://fpaste.org/WMds/ i cant' enable desktop effects
adamk_: Bigshot_, Looks fine to me.
adamk_: What's the output of 'glxinfo | grep -i render' ?
Bigshot_: hold on
Bigshot_: IRQ's not enabled, falling back to busy waits: 2 0
Bigshot_: direct rendering: Yes
Bigshot_: OpenGL renderer string: Mesa DRI R600 (RS780 9612) 20090101 TCL
Bigshot_: using F12 as you suggested :(
adamk_: That's all fine.
adamk_: How are you starting compiz? What error are you getting?
Bigshot_: check your xorg.conf file
Bigshot_: desktop effects could not be enabled
Bigshot_: i don't have xorg.conf file
adamk_: That doesn't answer both questions :-)
adamk_: In any case, install compiz-manager, and run it from a terminal.
Bigshot_: kwin is what i am starting
Bigshot_: ok just got compiz-manager how to start it?
adamk_: Oh, so KDE desktop effects, not compiz.
Bigshot_: yeah
adamk_: In which case, compiz-manager doesn't do any good.
adamk_: I have no idea what KDE does or what checks it runs.
Bigshot_: i got compiz how to enable it?
adamk_: But I don't see anything in your log file or the glxinfo renderer strings that suggests that anything is wrong.
adamk_: Run 'compiz-manager & ' in a terminal.
adamk_: Pastebin the output.
Bigshot_: http://fpaste.org/Bn08/
Bigshot_: adamk_:
cxo: chi, i mean, build master git
adamk_: Well, you don't have any window decorations installed, such as gtk-window-decorator, kde4-window-decorator, or emerald.
adamk_: I suggest installing some of the basic compiz packages that F12 may not ship with, such as compiz-kde or compiz-fusion-plugins-extra, etc.
chi: cxo, okay will do thank you
stikonas: uhh, finally this corruption is gone
stikonas: thanks for the bisection
MostAwesomeDude: agd5f: If you're around... the so-called "hwfmt" registers in the VAP are kind of weird.
MostAwesomeDude: R300_VAP_VTX_STATE_CNTL, R300_VAP_VSM_VTX_ASSM, R300_VAP_OUTPUT_VTX_FMT_0, R300_VAP_OUTPUT_VTX_FMT_1
Bigshot_: adamk:
Bigshot_: when i start compiz
MostAwesomeDude: They don't really follow any sane patterns, they look like they were copied from r200, and R300_VAP_VTX_STATE_CNTL is always set to 0x5555. This is kinda iffy.
Bigshot_: everything becomes blue and white
MostAwesomeDude: Are they needed always, or just for SW TCL? If they're set wrong, does it hurt anything?
Bigshot_: adamk_: you there bud?
adamk_: Bigshot_, Yeah, but not for long.
Bigshot_: what to do?
adamk_: Bigshot_, I'm not sure what's going on. Your log file looks fine. compiz should work fine.
adamk_: Wait around and hope someone else can lend a hand, I guess.
Bigshot_: everything looks white and blue
Bigshot_: how to check if i have
Bigshot_: all the compiz pacakges?
Bigshot_: packages*
Bigshot_: needed
adamk_: All I can suggest for that is asking on #radeon. I'm heading out for the night now.
Bigshot_: k
eosie: MostAwesomeDude: here's the rest of them: http://storm.unas.cz/eosie-patches-11-21.tar.gz
EruditeHermit: cxo, have you built a kernel from drm-next recently?
cxo: I use drm-radeon-testing which is newer than drm-next
cxo: and yes, i built one last night
EruditeHermit: cxo, is it based off 2.6.32-rc6?
EruditeHermit: thats why it is reporting
MostAwesomeDude: eosie: Working on cleaning these up right now.
eosie: thanks
cxo: EruditeHermit, I pull airlied stuff into the latest stable source (which is currently 2.6.32rc8 )
flyback: bbl
DanaG: weird... trying to resume from suspend with radeon, gives a hard-reboot instead.
EruditeHermit: cxo, thats unstable =p
EruditeHermit: or rather rc of yet to be released kernel
cxo: its called "Mainline", http://kernel.org/
EruditeHermit: right
EruditeHermit: ok my kernel compiled!
EruditeHermit: brb after reboot
eosie: MostAwesomeDude: BTW, you committed changes from the former set of patches, not the latter
eosie: not that it matters much
MostAwesomeDude: eosie: Yeah, I know. Since that path appears to fully work now, I didn't see any reason to keep it uncommitted.
eosie: ok
chi: cxo, now my monitor goes blank and wont come back up until i reboot
chi: =o
cxo: What kind of monitor do you have?
chi: a dell 2560x1600
chi: hrm seems i can break out of it now
cxo: Are you talking about X or just when the kernel boots?
chi: no /usr/lib64/dri/r600_dri.so
chi: X
cxo: did you not build xf86-video-ati?
cxo: looks like you may need --prefix=/usr --libdir=/usr/lib64 as well
chi: yes from git
chi: kk
cxo: did you build mesa?
chi: not from git but i did rebuild it
cxo: if you're going to build from git, you must build drm, mesa and xf86-video-ati together
cxo: changes in one usually requires the other
chi: ah okay
cxo: drm first, then mesa,
chi: not xorg-server though?
cxo: not really, as long as you have something decent
chi: 1.6.3.901-r2
cxo: thats a little old, but i think it should be ok
chi: k
basilgohar: I just wanted to say, good job on the drivers in F12, whatever they are.
basilgohar: I just installed F12 on my laptop which has a RV350 (I think), and it's very fast and smooth, both for 2D & 3D.
basilgohar: It wasn't that was since F8, if I'm not mistaken.
basilgohar: *way
basilgohar: KMS also works very well.
basilgohar: So thanks for all the hard work, everyone!
EruditeHermit: airlied, I posted the register dumps that you wanted concerning bug 23103.
chi: hrm, just a blank screen http://sprunge.us/LRPj
_Groo_: hi/2 all, any dev awake?
_Groo_: rs485 is broken again :P
biotube: glslnoise hung my GPU
biotube: good reason that code's hidden behind a #define
chi: cxo, well i got it back to what it was. my mouse is a black square and i can't see text in aterm =o
cxo: chi, which kernel are you using?
cxo: you better have something > 2.6.31
chi: 2.6.30
chi: ah okay
chi: thank you for your time btw
_Groo_: any dev alive?
_Groo_: latest gits broke a lot of stuff for my rs485
cxo: chi, get linus' stable tree and pull in drm-next
chi: will do
_Groo_: cxo: how do i pull drm-next? can you paste the url?
chithead: _Groo_: if you can bisect it to pinpoint the commit which broke your setup, report a bug
soreau: might want to use drm-radeon-testing
cxo: _Groo_, there is a guide in /topic
cxo: http://www.x.org/wiki/radeonBuildHowTo#head-a6271d23a9199673cea21478e0198d772a55fad3
cxo: and yeah, what soreau said
_Groo_: chithead: i updated git from 7.7 dev to 7.8, there where a lot of commits, and in the 4 trees, mesa/ddx/drm/kernel
_Groo_: chithead: kde4 + composite is crashing X and giving dmesg errors , gkrellm crashes X.. compiz works but some modules crash X...
chi: not sure what git sources are considered 'linus' stable tree' ?
chithead: _Groo_: ensure that xserver, mesa and xf86-video-ati were built against the same version of libdrm
chi: is 2.6.32_rc8-r1 new enough?
chithead: for r600 3d, you need 2.6.32-rc1 or later
chi: okay thanks
_Groo_: chithead: they where, i always pull all from git master and build in this order, drm/mesa/ddx
_Groo_: kernel is 2.6.32 rc8
chithead: _Groo_: and where is the x server in that?
_Groo_: chithead: master from today
chithead: _Groo_: in that order I mean
_Groo_: chithead: its the first of course
chithead: [05:38:41] _Groo_: ensure that xserver, mesa and xf86-video-ati were built against the same version of libdrm
_Groo_: chithead: hmmm xserver must be built against libdrm?
_Groo_: chithead: mesa and ddx i know they need, but xorg?
soreau: -_-
chithead: _Groo_: check xserver configure.ac line 768
_Groo_: chithead: gonna rebuild it then and kernel using the wiki, against drm-next.. doing it now
chithead: kernel is mostly independent from the rest
_Groo_: chithead: yeah ok LIBDRM="libdrm >= 2.3.0" but its dynamic, not static.. i can build x with any libdrm above 2.3.0 and i can rebuild a later libdrm from master , x will hapilly work
chithead: it will compile. it will probably run too, at least for some time. then it crashes.
_Groo_: and kernel isnt so independent with kms/dri2... im suspecting im having this behaviour because i used kernel stock and not drm-next
_Groo_: chithead: but ill do what you told me, im rebuilding X too :)
MostAwesomeDude: Oh goody, it's time for more freezes.
cxo: Freeze with me!
cxo: (Prodigy parody)
MostAwesomeDude: airlied: Hard locks with kernel -127 in F12. Sometimes quick, sometimes slow. All with RV410 in PCIe slot, with onboard R600 disabled.
MostAwesomeDude: -122 seems to not have the problem, but it froze too. Admittedly, it took 2 days instead of 2 hours.
chi: YAY success!
chi: hugs cxo
chi: thank you =D
cxo: yay