Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2010-4-24

Search This Log:

eichi: hello, someone here has the ati radeon mobility x1400? would nicely hear some experiences with the radeon driver. I have good and bads. would hear if its a driver or other problem. how does the x1400 work on your system, if you have one?
dileX: hi
dileX: here I get w/ openaren and mesa (commit 94b04d3d1ccd1b717dbc9d797341f1170121645a) compiled with --debug: state_tracker/st_atom_framebuffer.c:162:update_framebuffer_state: Assertion `framebuffer->zsbuf->texture->bind & (1 << 0)' failed.
dileX: commit 17249ae8e0e459dea250733a0b3e45036cdb67bd "st/mesa: assert that binding flags are properly set for drawing surfaces" seems to be culprit
dileX: that works: GALLIUM_ABORT_ON_ASSERT=false openarena
dileX: Reverting culprit commit lets openarena play with r300g st/dri
Dr_Jakob: dileX: I'll look into it.
Dr_Jakob: dileX: fix found
dileX: Dr_Jakob: thx
Dr_Jakob: dileX: push
Dr_Jakob: ed
dileX: Dr_Jakob: ...and ten point go to... Sweden - la Suède dix point - Schweden 10 punkte
Dr_Jakob: Hehe :)
maniac103: I have horrible compositing slowness with a r430 (X800XL) AGP (gnome-shell needs minutes to start, compiz is unusably slow without CPU load) on Fedora 13 ... is there anyone around who can help me with that?
evil_core: can I play with drm w/o hanging all machine(VT i.e.)?
maniac103: hmm, vsync seems pretty broken ... glxgears reports 'The framerate should be approximately 1/1835103081 the monitor refresh rate'
evil_core: maniac103: AGP cards are 3rd category citizens
maligor: maniac103, is it accelerated?
maniac103: maligor: 'it'?
maligor: your opengl
evil_core: xdriinfo
evil_core: and glxinfo | grep -i render
maligor: oh, didn't know about xdriinfo.. handy
maniac103: yes ('Screen 0: r300')
maligor: you might want to check your mesa version too
maniac103: 7.8.1 according to glxinfo
evil_core: maniac103: try switching to PCI mode
maligor: even if it was just working in pci mode, it shouldn't be abysmally slow
maniac103: evil_core: how?
maligor: AGP was a dreadful mistake anyway if you ask me
evil_core: modinfo radeon
evil_core: radeon agpmode=-1
maniac103: evil_core: already tried that one
maniac103: no change at all
maligor: what ships 7.8.1?
maligor: I think 7.8.1 was still marked as unstable (or something like that)
maniac103: Fedora 13 (beta)
maligor: maniac103, did you try disabling modesetting?
maniac103: maligor: not yet (will do in a sec), but this issue predates kms
maniac103: is just waiting for this yum update to finish
maligor: made a bugreport of it?
maniac103: not yet
maniac103: I use this PC only rarely, thus I always forget about that ;-)
adamk: Yeah, there's something odd going on there. Even my AGP x700 never had those problems.
adamk: maniac103: Do you get decent 3D performance without compositing?
maniac103: adamk: how can I check without downloading a huge game? ;-)
adamk: Oh, and have you tried enabling AccelDFS? It's disabled by default on AGP, but could be stable for you.
adamk: Hmmm... GOod question, I normally would recommend openarena, but that's a pretty big game :-)
maniac103: glxgears says ~400fps
maniac103: looks a bit slow to me
adamk: Yeah, as much as I harp on glxgears not being a benchmark, 400fps sounds suspiciously low.
adamk: Can you pastebin your Xorg log file?
maniac103: sure, sec
adamk: I wish I had kept my Fedora installation around to test with.
maniac103: http://pastebin.com/92bb9r18
soreau: sounds like something similar that was happening here with my rv350, on Arch. Seemed everything worked, except mesa felt like LIBGL_ALWAYS_SOFTWARE was set or it was falling back to all sw routines making compiz unusably slow and gears <100
maniac103: soreau: and how was it resolved for you?
soreau: my problem ended up being that Virtual >4080x4080 is not cool
maniac103: ok, that's not the case here
adamk: maniac103: So this has been an issue for a while, even before F13?
maniac103: adamk: yes, at least since F10, can't remember whether it also happened before
soreau: yea I don't think it's the same issue. Has this card ever ran well?
adamk: Huh... DFS is already accelerated. I thought it was disabled on AGP by default. At least that's what the man page says.
maniac103: soreau: yes, in Windows ;-)
maniac103: ok, now booted with radeon.modeset=0, glxgears 1600fps (although no vsync), compiz MUCH faster
maniac103: (usable, that is)
maniac103: gnome-shell still weird, though
soreau: maniac103: maybe you can try 1) Creating an xorg.conf and specifically setting Virtual 2048 2048 2) A less experimental distro live cd (ubuntu?) 3) tried nomodeset yet?
maligor: maniac103, like the textures going weird?
maniac103: soreau: for 3) read a few lines above yours ;-)
soreau: right.
maniac103: maligor: no, taking minutes to startup and even when the activities bar is present, the windows aren't shown
adamk_: maniac103: Without KMS you were clearly using indirect rendering for compiz and gnome-shell. How about with KMS enabled?
maniac103: adamk_: hmm, good point, probably direct
maniac103: let me check
soreau: along that line, you could probably try gears with LIBGL_ALWAYS_INDIRECT set
adamk_: might have to give F13 a shot on a flash drive just to see how it's doing these days.
maniac103: gears with LIBGL_ALWAYS_INDIRECT -> ~60fps due to vsync
maniac103: modeset enabled + compiz --indirect-rendering -> compiz usable (like without modeset)
adamk_: Huh.
adamk_: I'd have to lean towards some serious vsync issues going on.
maniac103: indeed, that's what I was going to write
adamk_: maniac103: I'd keep an eye out for the developers on here or simply open up a bug report and ping them with it when you see them.
maniac103: quoting glxgears again: 'Running synchronized to the vertical refresh. The framerate should be approximately 1/1835103081 the monitor refresh rate.'
adamk_: Yeah.
soreau: mine says "Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate."
soreau: but even with indirect set, I still get 6-700 :P
vadi: Debian Lenny with some newer packages as:
vadi: * linux 2.6.32
vadi: * xserver-xorg 7.4
vadi: * xserver-xorg-video-radeon 6.12
Ke: ancient
Ke: esp. xserver-xorg-video-radeon 6.12
vadi: Hardware:
vadi: * ATI Technologies Inc RV730 PRO [Radeon HD 4650]
vadi: Problem:
vadi: * I note all windows scroll is done by the CPU, not by the Radeon GPU
vadi: How to fix it? Upgrade to radeon 6.13?
soreau: What renderer string is reported by glxinfo?
vadi: Is is a long output
vadi: Can i paste elsewhere?
soreau: glxinfo|grep renderer
soreau: should give you a single line
vadi: # glxinfo|grep renderer
vadi: OpenGL renderer string: Software Rasterizer
dileX: vadi: which mesa version do you have installed?
vadi: libgl1-mesa-glx 7.4.1
soreau: maniac103: Have you tried with a different user by chance?
vadi: ii mesa-common-dev 7.0.3-7 Developer documentation for Mesa
vadi: ii mesa-utils 7.0.3-7 Miscellaneous Mesa GL utilities
vadi: Some 7.4.1 packages and others 7.0.3 !
soreau: vadi: software rasterizer means your 3D isn't working, at least. Can you pastebin your X log?
vadi: # dpkg -la | grep mesa
vadi: ii libgl1-mesa-dev 7.0.3-7 A free implementation of the OpenGL API -- GLX development fi
vadi: ii libgl1-mesa-dri 7.4.1-1 A free implementation of the OpenGL API -- DRI modules
vadi: ii libgl1-mesa-glx 7.4.1-1 A free implementation of the OpenGL API -- GLX runtime
vadi: pi libglu1-mesa 7.0.3-7 The OpenGL utility library (GLU)
vadi: ii libglu1-mesa-dev 7.0.3-7 The OpenGL utility library -- development files
vadi: ii mesa-common-dev 7.0.3-7 Developer documentation for Mesa
soreau: vadi: STOP
vadi: ii mesa-utils 7.0.3-7 Miscellaneous Mesa GL utilities
vadi: sorry
soreau: vadi: Use a pastebin service
vadi: ack
dileX: vadi: install libgl1-mesa-dri and libgl1-mesa-glx (7.7.1-1) <--- its in the lenny repos
dileX: vadi: http://packages.debian.org/search?keywords=linux-image <--- 2.6.32+25~bpo50+1 from lenny-backports (enhance sources.list if necessary)
vadi: http://paste.lisp.org/display/98269
vadi: dileX, trying, thanks
vadi: 0 upgraded, 0 newly installed, 0 to remove and 42 not upgraded.
vadi: Trying to look that version in Lenny by hand
soreau: vadi: Looking at your X log, best I can tell you might not have firmware package installed
soreau: it's something like linux-firmware-nonfree
vadi: dileX, Version is lenny is 7.0.3-7
vadi: not 7.7.1
dileX: vadi: OK, I mixed with squeeze
vadi: Thanks soreau. I am going to look for that package
soreau: and of course, no version of mesa installed will have working 3D without the firmware ;)
vadi: E: Couldn't find package linux-firmware-nonfree
soreau: That's not the package name exactly
soreau: do something like 'apt-cache search firmware'
soreau: |grep nonfree
soreau: or w/e
vadi: I did not know it Radeon required firmware! It is said to be Free Software, you know
vadi: thanks, trying
dileX: firmware-linux-nonfree
soreau: Yea, thanks dileX
vadi: trying
vadi: E: Couldn't find package firmware-linux-nonfree
vadi: looking by hand
soreau: might need to enable whatever repo has it
dileX: vadi: some place where to get additionale infos and hints (esp. debian) and (in general)
vadi: thanks dileX
vadi: Trying to find the repo which offer that package
soreau: maybe dileX can show an 'apt-cache policy firmware-linux-nonfree' :)
vadi: it would be great :)
dileX: vadi: lenny-backports squeeze sid has it
dileX: http://packages.debian.org/search?keywords=firmware-linux-nonfree
vadi: thanks dileX, I am going to install the one at lenny-backports
dileX: vadi: http://www.backports.org/dokuwiki/doku.php?id=instructions
vadi: thanks dileX
vadi: Installed.
vadi: Do I need to reboot or just restart X?
soreau: reboot it
vadi: ack
vadi: update-initramfs: Generating /boot/initrd.img-2.6.32-bpo.4-amd64
vadi: W: Possible missing firmware /lib/firmware/rtl8168d-2.fw for module r8169
vadi: That is not related, but I am not sure it I should fix it now
vadi: Suggestion welcome
Ke: vadi: you don't need it
soreau: If you don't use the module, maybe you don't need to worry with it
vadi: ack, thanks
Ke: if your networking works
Ke: It does the same for me with no noticeable lack of functionality
vadi: it work, as I can chat with you
vadi: I do not use that module:
vadi: lsmod | grep 8168
vadi: rebooting. I will came back to report
vadi: # glxinfo|grep renderer
vadi: OpenGL renderer string: Software Rasterizer
vadi: It shows yet "by software"
vadi: ii firmware-linux-nonfree 0.23~bpo50+1 Binary firmware for various drivers in the Linux kernel
vadi: is installed.
vadi: Linux version 2.6.32-bpo.4-amd64 (Debian 2.6.32-11~bpo50+1)
soreau: vadi: pastebin your current X log
dileX: show us dmesg and Xorg.log
vadi: ack, doing 2 pastebin
vadi: Xorg.0.log at http://paste.lisp.org/display/98273
soreau: (EE) AIGLX error: dlopen of /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so: cannot open shared object file: No such file or directory)
soreau: I didn't realize you had r7xx
dileX: vadi: you didnt upgrade ddx
soreau: dileX: 3D wont work since his kernel's too old ;)
vadi: dmesg at http://paste.ubuntu.com/421677/
dileX: that backported kernel has .33 kernel-drm
soreau: oh well.. I though I saw .31, but it's .32
soreau: vadi: You need to install whatever mesa package provides /usr/lib/dri/r600_dri.so
vadi: OK. So I do not need to install linux kernel 2.6.33 ?
soreau: no
vadi: thanks!
soreau: On ubuntu it's libgl1-mesa-dri
vadi: Yes, provided by libgl1-mesa-dri in squeeze
dileX: hmm, only sid has 6.13.0 xserver-xorg-video-radeon
vadi: 6.12 here
vadi: installed from an old squeeze package I think
vadi: Debian Lenny here with now newer packages
vadi: Installing libdrm-intel1 and other required packages too
vadi: just rebooting X, not the whole system
vadi: # glxinfo | grep ender
vadi: IRQ's not enabled, falling back to busy waits: 2 0
vadi: direct rendering: Yes
vadi: OpenGL renderer string: Mesa DRI R600 (RV730 9498) 20090101 TCL
soreau: Looks good, how's your scrolling?
vadi: yep :)
vadi: testing
vadi: good, good. It is instantaneous. Thanks a lot!
soreau: Glad we could help ;)
dileX: vadi: which version of ddx?
vadi: How to look? no *ddx* package here
vadi: server glx version string: 1.2
dileX: ddx == xserver-xorg-video-radeon
vadi: xserver-xorg-video-radeon 1:6.12.2-2
vadi: from an old Debian squeeze package I think
dileX: hmm, interesting
dileX: you could upgrade to 6.12.6 from testing - to have all latest from squeeze
vadi: Let me try it upgrading does not raise any dependence issue, as I want to stay on Debian lenny
vadi: It bring lost of new packages. I think by now I will stay as now, as it works
dileX: vadi: if you have libdrm mesa and ddx from squeeze that shouldnt matter
vadi: Trying to install the update via dpkg -i because apt-get brings a lot more packages with it
dileX: vadi: you installed manually last time?
vadi: apt-get install xserver-xorg-video-radeon
vadi: yes, I installed manually last time
vadi: the less required packages possible
vadi: to avoid upgrade to squeeze
dileX: squeeze might be 1st stable debian I would install freshly on a computer-system
Ke: =D
vadi: dpkg -i Desktop/xserver-xorg-video-radeon_6.12.6-1_amd64.deb
vadi: This command brings new dependences too. So I avoid it. I stay as I am :)
vadi: KDE 4.x sucks, and so squeeze too
vadi: Debian Lenny rocks :)
vadi: Debian Lenny for ever :D
dileX: vadi: you will love kde4 when you are used to it - but its no more that lightweight as 3.5.x thats true
vadi: I have played with it to see how I would work with it
vadi: There are things which are not bad ideas, but other I have to check yet
vadi: The first impression of KDE 4.3 was, "What a mess!"
vadi: After I tuned it, it was: "Let me try research how to customize it to fit my needs."
vadi: What is true, is that KDE 3.5 is a lot better to me than KDE 4.4
vadi: KDE 4.4 needs more configuration flexibility to be able to look and work as a KDE 3.5
vadi: Maybe in 1 or 2 years more of work, at KDE 4.8 maybe
vadi: Now I can stay at Debian lenny with new linux kernel and new xorg
vadi: It 'flash' a little, but I think it is normal
magaio: Any improvements using evergreen with the newest mainline kernel + radeon?
FireBurn: Hi there
FireBurn: I noticed the green screen issue was back with my card with the lastest git from Linus and the drm-radeon-testing branch
edwin: how do I enable llvmpipe with configure and make (not scons)
edwin: or is it only supported on scons, and with 'make linux-llvm'?
edwin: hmm 'make linux-llvm' works if you actually add LLVM_CFLAGS to CFLAGS :)
edwin: hmm I only get 845 FPS in glxgears on a quad core Q9550 @2.83Ghz. I heard I should get ~6000? (llvm 2.7, llvm 2.6, release-asserts build)
AndrewR: edwin, may be 6000 was about radeon driver + unpublished (?) patches ?
agd5f: airlied, mjg59: new pm patches: http://people.freedesktop.org/~agd5f/pm3/
agd5f: basically allows you to switch between dynpm and static pm at run time using sysfs
agd5f: still sclk only at the moment
agd5f: airlied, mjg59: also fixes up evergreen pm support
Jonimus: agd5f: and those should work with 2.6.34rc?
yoshi314: hi there
Jonimus: ohai
yoshi314: anybody testing radeon gallium around?
MostAwesomeDude: Hm?
yoshi314: i have this weird issue nowadays with ta3d game
yoshi314: if you played total annihilation before, you might understand better
yoshi314: there is an effect in game when building something that looks like a green spray of sorth
yoshi314: *sorts
yoshi314: in ta3d they implemented it as simple particles
yoshi314: whenever this effect appears, all rendering stops
yoshi314: until it goes away
yoshi314: game makes sounds, etc
MostAwesomeDude: Hm. Anything on the console? Could you check dmesg?
yoshi314: when graphics starts moving again - it's evident that gameplay was happening at that time
yoshi314: hmm okay
yoshi314: oh , there is something there
yoshi314: http://pastebin.com/UJY3HHAz
yoshi314: i'll try again and keep watching dmesg to make sure what happens at what point
MostAwesomeDude: Ugh, that's no good.
yoshi314: yup, this time game appeared to render a few frames every few seconds
yoshi314: second run : http://pastebin.com/t6ZxL6fJ
yoshi314: nothing else seems affected by the problem
yoshi314: i've tested darkplaces and doom3 so far
yoshi314: maybe this particular effect is not used there
MostAwesomeDude: Hm. Wonder what we're doing wrong.
MostAwesomeDude: I'll check it out later.
yoshi314: ok, need more debug info ?
yoshi314: e.g mesa logs ?
yoshi314: this effect didn't lock up the game so heavily a week ago or so
yoshi314: but sometimes the green particles were not visible at all
MostAwesomeDude: Wait, wait, it didn't do this a week ago?
yoshi314: http://www.youtube.com/watch?v=eh_APBlgH-E movie that illustrates that effect, if that helps with anything
yoshi314: i'll have to check out where exactly it broke
yoshi314: i've been frequently testing this game recently
yoshi314: it was broken on apr 18
MostAwesomeDude: Could you bisect? It'd be a big help.
MostAwesomeDude: I don't know why that effect might cause GPU resets.
yoshi314: ok, i'll try getting to it
yoshi314: i hope libdrm didn't change too drastically recently
MostAwesomeDude: You shouldn't have to touch libdrm.
MostAwesomeDude: Just Mesa.
yoshi314: ok
yoshi314: since i've relied on gentoo's ebuild, will --enable-gallium-radeon and correct prefix suffice?
MostAwesomeDude: Yeah.
MostAwesomeDude: loves informed bug reporters :3
yoshi314: ok, building
yoshi314: somehow, i feel left out :]
DanaG1: http://people.freedesktop.org/~agd5f/pm3/0016-drm-radeon-kms-pm-rework-power-management.patch
DanaG1: hmm, interesting idea... though it might be nice to accept not only x.y (state.clock), but also just state (so it varies clocks within that state).
Jonimus: Well I'm off to build me a new kernel :P
yoshi314: whew, i'm closing in on the bug
Jonimus: :/ the patches don't work with rc5 :(
Jonimus: tires with kernel26-git
yoshi314: ok, i found it
yoshi314: it's the commit 745c4b568573fd5353e0f790251af64098742b1a "r300g: add generating texture coordinates for point sprites"
yoshi314: i'll post a bug on b.fd.o
MostAwesomeDude: Oh goddie.
yoshi314: ok, what driver should i specify?
yoshi314: Drivers/DRI/Radeon ?
yoshi314: i have a rv515
MostAwesomeDude: drivers/dri/r300g
yoshi314: i can't see it on the list
yoshi314: only r300
yoshi314: in Mesa product
MostAwesomeDude: file against mesa, then
yoshi314: ok
Jonimus: playing flash games while compiling a kernel seems to have broke something, my compile just stopped :P
Jonimus: hmm this is odd I get no errors applying the patches but the build still fails :/
maxi_jac: I can't link dri radeon gallium anymore
maxi_jac: radeong_dri.so.tmp: undefined reference to `draw_pt_fetch_pipeline_or_emit_llvm'
maxi_jac: radeong_dri.so.tmp: undefined reference to `lp_build_engine'
maxi_jac: radeong_dri.so.tmp: undefined reference to `lp_build_init'
adamk_: I just built it here a few minutes ago.
maxi_jac: a header also lacks a #define STD_CONSTANT_MACROS
adamk_: Try a 'make clean' first.
adamk_: New enough xorg-macros?
maxi_jac: totally fresh git
maxi_jac: I don't know for xorg-macros, it used to build yesterday
MostAwesomeDude: Hm.
MostAwesomeDude: How are you configuring?
maxi_jac: ./configure --prefix=/usr --with-state-trackers=dri,glx --enable-gallium-radeon --with-dri-drivers=r300 --disable-gallium-intel --disable-gallium-nouveau
maxi_jac: I think it used to work with the same ./configure yesterday
MostAwesomeDude: Hm. Try without glx state tracker.
maxi_jac: ok
MostAwesomeDude: You might have to autoreconf first.
maxi_jac: ./autogen.sh
maxi_jac: ?
MostAwesomeDude: $ autoreconf
maxi_jac: ah, did'nt do it :p but I always start from a fresh git clone
maxi_jac: still complaining about #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h"
MostAwesomeDude: Stop doing that.
maxi_jac: what ?
MostAwesomeDude: If you need to clear out your tree, $ make realclean && git reset --hard origin/mastser
MostAwesomeDude: Uf, * origin/master
MostAwesomeDude: You don't need to re-clone every time.
MostAwesomeDude: Anyway.
MostAwesomeDude: Where's this #define error?
maxi_jac: I have cloned in a directory once and I copy to another directory before building
MostAwesomeDude: supposes he should pull the current head
maxi_jac: hehe ^^
maxi_jac: I added it in draw_private.h
maxi_jac: MostAwesomeDude, still not linking, even with autoreconf before configure
maxi_jac: and onli st=dri
maxi_jac: *only
MostAwesomeDude: maxi_jac: Add --disable-gallium-svga to your configure line and try again.
maxi_jac: ok
twnqx: why would libX11 do uname() ?
MostAwesomeDude: S&G, possibly. Ask in #xorg-devel.
MostAwesomeDude: Why does it matter, though?
twnqx: because i'm faking an i686 with modified syscall returned, and the app stops working
MostAwesomeDude: Ask in #xorg-devel, definitely.
maxi_jac: MostAwesomeDude, still not linking
maxi_jac: radeong_dri.so.tmp: undefined reference to `draw_pt_fetch_pipeline_or_emit_llvm'
maxi_jac: radeong_dri.so.tmp: undefined reference to `lp_build_engine'
maxi_jac: radeong_dri.so.tmp: undefined reference to `lp_build_init'
airlied: maxi_jac: can you pastebin the confiugure output?
maxi_jac: http://pastebin.com/YYbgQmdt
MostAwesomeDude: maxi_jac: Install LLVM devel for your system (llvm-dev or llvm-devel) and see if things work.
maxi_jac: there's no devel packages
maxi_jac: devel files included
maxi_jac: I have llvm 2.6
maxi_jac: (I use Archlinux )
maxi_jac: (I was using an SVN version when it last built (maybe 2 or 3 weeks old), I switched back to 2.6 when I've had this error)
Hazelesque: Hello, I have a Radeon HD 4350, should I be using the "radeonhd" or "radeon" (xf86-video-ati) driver?
mjg59: Hazelesque: radeon
Hazelesque: right, OK, I'm currently running with "radeonhd", but I compiled both radeon and radeonhd drivers recently
Hazelesque: I currently get a message about "(II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so" in my Xorg.0.log, is this the reason why moving windows is veeeeeeeeery slooooooow?
Hazelesque: (and scrolling through text, for that matter)
Jonimus: Hazelesque: how new are your libdrm and mesa packages
Hazelesque: as in, the OS-provided ones?
Hazelesque: ii libdrm2 2.4.18-3 Userspace interface to kernel DRM services
Hazelesque: on debian squeeze (I've not updated in a little while, though)
Hazelesque: Jonimus: is that what you meant?
Jonimus: you may need newer a newlibdrm and mesa in order to get hardware accel with that card
Jonimus: yes that is what I meant
Hazelesque: should I try to see if a newer version is available in squeeze, or try to compile one?
Jonimus: I'd ry both in that order
Hazelesque: ah, it appears they are "up-to-date" [with what is in squeeze]
Hazelesque: last time I was doing this, for radeonhd, the guide said something about compiling drm.ko/radeon.ko from the linux-core subdirectory of the mesa/drm repository
Hazelesque: is that necessary here? ISTR someone telling me it wasn't necessary before
airlied: hmm I messed up a bit on llvm
airlied: lemme fix it
maxi_jac: airlied, about the problem I have ?
maxi_jac: if so take the opportunity to add the #define before including
airlied: maxi_jac: yup
maxi_jac: nice :)
Hazelesque: Jonimus: also, you mentioned mesa... do I need to update mesa if I'm not using 3D?
Jonimus: Hazelesque: what DE do you use if any, and what WM, if you use compiz 3d will mater
Hazelesque: Jonimus: I use fluxbox.
Hazelesque: I sometimes play HD video with mplayer (-vo xv?)
Jonimus: ahh then I doubt it will matter but IDK
airlied: maxi_jac: fix pushed in theory
maxi_jac: ok, I'll check that and tell you if it's fixed
agd5f: Jonimus: should work. patches are against drm-next
Wizzup: Hazelesque: I think it matters if you use -vo gl
maxi_jac: airlied, fixed ! great
Hazelesque: do I need to use the "r6xx-r7xx-support" branch in the linux-core directory of the checkout of the mesa/drm repository?
Jonimus: agd5f: well it errored while building against git and the patches failed to apply against 2.6.34 rc5 :/
Jonimus: agd5f: these are the errors I gothttp://jonimus.pastebin.com/FtLYkct6
Jonimus: http://jonimus.pastebin.com/FtLYkct6 *
Hazelesque: also, the build howto says I should be using "6.12-branch" of the radeon driver rather than master, is that correct?
Hazelesque: (I had already "git pull"ed whatever it was I checked out last time, yesterday, and compiled that... I think that was probably master)
Hazelesque: .git/HEAD contains "ref: refs/heads/master", I think that means it was master, I'm not too familiar with git
evil_core: can I check GPU temperature?
evil_core: mine palmrest is very hot :/
evil_core: and I got 75 on CPU
mattst88: airlied, I was looking at how to make a function like radeon_cs_write_dwords(struct radeon_cs *cs, ...) and wound up writing one to take an array and a length
mattst88: then I realized that it's functionally identical to radeon_cs_write_table.
mattst88: why don't we use that function? I don't see it used anywhere in the DDX.
MostAwesomeDude: Hm, good question.
agd5f: mattst88: ddx was written before that function existed
mattst88: of course :)
agd5f: Jonimus: might have to try drm-next then
agd5f: evil_core: only if you laptop has a thermal chip hooked up. I don't think the t60's do
agd5f: evil_core: there might be a thermal sensor provided by acpi for the gpu
agd5f: check the thinkpad-acpi driver
agd5f: evil_core: http://www.thinkwiki.org/wiki/Thinkpad-acpi
evil_core: As of kernel 2.6.27 the thinkpad-acpi bay and dock drivers should no longer be used. Instead use the standard ACPI bay and dock drivers. As of kernel 2.6.31 the thinkpad-acpi bay and dock drivers have been removed completely.
evil_core: I got that module built-in
agd5f: evil_core: thinkpad-acpi provides much more than dock and bay support.
agd5f: http://www.thinkwiki.org/wiki/Thermal_Sensors
MVXA: (join #ati
MVXA: hups
evil_core: agd5f: thanx, I got lm_sensors confoigured, but temp1..temp14 was unusable for me up to now ;)
evil_core: temp11: +53.0°C
evil_core: ERROR: Can't get value of subfeature temp12_input: Can't read
evil_core: tanyway I wonder why I got such errors :/
evil_core: and if temp4 is GPU then its 70 celsius while idlling!
evil_core: iddling*
evil_core: ok, I understand
evil_core: agd5f: is 70 normal for idling mobile r500?
Hazelesque: right, I think I've compiled new libdri and installed it, will reboot and find out if it worked
Hazelesque: (it didn't actually take me a million years, I was distracted by tea and daleks.)
evil_core: agd5f: d oyou plan to make pm2 aplicable to d-r-t?
evil_core: what is "bliting shader"?
Hazelesque: right
Hazelesque: well, despite adding /usr/local/mesa-rubbish/lib to a new file called /etc/ld.conf.so.d/00-mesa-rubbish.conf, and putting "LIBGL_DRIVERS_PATH=/usr/local/mesa-rubbish/lib/dri/" in /etc/environment, and running ldconfig as root, and rebooting
Hazelesque: (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
Hazelesque: ^ I still get that in my Xorg.0.log file
Hazelesque: which suggests it isn't using the paths it's supposed to
Hazelesque: any ideas?
evil_core: [ 64.838] (II) AIGLX: Loaded and initialized /usr/lib64/xorg/modules/dri/r300_dri.so
evil_core: should I be worried about that?
evil_core: I am usign drivers from /opt/xorg (etc)
adamk: Hazelesque: The path Xorg uses to load the driver for AIGLX is hardcoded.
adamk: LIBGL_DRIVERS_PATH is only used by libGL.
Hazelesque: adamk: oh, http://www.x.org/wiki/radeonBuildHowTo seemed to suggest that I should build mesa and the DRI drivers and put them in /opt/Xorg or "what ever you prefer" (I don't like /opt, hence "/usr/local/mesa-rubbish") and to set some environment vars/ld.so.conf stuff
Hazelesque: does that mean that guide is wrong? or did I miss something out? ...
evil_core: no
evil_core: all is OK
_ds_: normally builds .debs…
adamk: Hazelesque: The guide is right in that new opengl applications will use the dri driver in the LIBGL_DRIVERS_PATH
adamk: Hazelesque: But, as I said, Xorg loads the DRI driver from a hard coded directory.
_ds_: (packaging from testing/unstable, lightly hacked)
adamk: So AIGLX will use the hard coded one.
Hazelesque: adamk: hmm
evil_core: adamk: but it matters also when libGL revert to indirect rendering?
evil_core: and Xv?
adamk: Yes, as I said, AIGLX will use the hard coded one :-)
adamk: Xv has nothing to do with any of this.
adamk: We're talking about 3D drivers not 2D video playback.
Hazelesque: so, if I were to put the new libdri stuff into /usr/lib, would that change the fact that the log currently says "(II) AIGLX: Screen 0 is not DRI2 capable" and "(II) AIGLX: Screen 0 is not DRI capable"?
Hazelesque: or is something else broken?
evil_core: you need to enable KMS then
adamk: Most likely something else.
evil_core: and dont ut into /usr/lib
adamk: Pastebin the full log file.
evil_core: you can get multipl libs installed
DanaG: I usually just plain put stuff in /usr
DanaG: IF I want to revert, I reinstall the distro packages.
Hazelesque: evil_core: well, yes, clearly I don't like the idea of trampling all over /usr/lib, I could put it in a package and use dpkg-diverts, or something
Hazelesque: my point was whether that was the problem or not
evil_core: its not a problem
evil_core: especially if you arent using compositng
evil_core: I got scripts in ~/bin to running apps using different drivers
Hazelesque: http://qwerty.pastebin.com/TTBCK0BZ
Hazelesque: ^ my current Xorg.0.log
Hazelesque: and, I thought kernel modesetting was optional?
adamk: KMS is option for DRI, not for DRI2.
adamk: Give me a second to check the log file.
adamk: Bah.
Hazelesque: hmm?
adamk: Check 'dmesg | grep drm'. I bet you are missing the firmware package.
Hazelesque: ah, hmm
Hazelesque: [ 387.790052] [drm:r600_do_init_cp] *ERROR* Failed to load firmware!
Hazelesque: I thought I installed the linux-firmware-nonfree package
Hazelesque: er, firmware-linux-nonfree
evil_core: but you got custom kernel
adamk: Did you reload the 'radeon' kernel module after you installed that package?
evil_core: or maybe I dont kno what you got ;)
adamk: Having a custom kernel has nothing to do with this.
evil_core: firmware dont need to be in kernel dir?
Hazelesque: adamk: um? I have rebooted several times this evening, and I believe that I installed linux-firmware-nonfree several days ago, so I think that is a yes?
Hazelesque: minus typo again
adamk: Pastebin the 'dmesg | grep drm' output.
Hazelesque: evil_core: and, I'm pretty sure it's a stock kernel from debian squeeze
adamk: And double check that linux-firmware-nonfree is installed and up-to-date.
Hazelesque: http://qwerty.pastebin.com/npU4VDFJ
Hazelesque: firmware-linux-nonfree is already the newest version
adamk: Of course it doesn't say which firmware file is missing.
adamk: But you're clearly missing something.
adamk: So perhaps the Debian package is just out-of-date.
Hazelesque: right, where should I get the latest from? http://people.freedesktop.org/~agd5f/radeon_ucode/ ? http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=radeon ?
adamk: I don't know which one is newer. I assume the kernel git one is fine, but there is at least one firmware that isn't distributed there, but I believe is only necessary for KMS.
adamk: That would be the R700_rlc.bin one in the first link.
adamk: bbl.
Hazelesque: OK
Hazelesque: :)
Hazelesque: _ds_: which packages do you need to grab the source from, to build these debs? libgl1-mesa-dri?
Hazelesque: [ 5514.700840] r600_cp: Failed to load firmware "radeon/RV710_cp.bin"
adamk: Hazelesque: Is it in /lib/firmware/radeon/ ?
adamk: And is the radeon kernel module being loaded from an initrd?
Hazelesque: it's not in /lib/firmware/radeon, no
Hazelesque: and, I don't know, although I don't believe I've modified the radeon.ko from the stock version, should I?
adamk: It's not a matter of modifying it. It depends on whether debian creates an initrd that loads radeon.
adamk: I don't know as I don't use Debian.
adamk: Having said that, I'm pretty sure not having the firmware in /lib/firmware/radeon/ is going to be a problem either way.
Hazelesque: (although, after copying the firmware from those URLs, I shut down X and rmmod'd radeon, then re-modprobed it)
Hazelesque: (and those URLs don't seem to have the file "RV710_cp.bin")
adamk: http://www.google.com/#hl=en&source=hp&q=RV710_cp.bin&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=3f73b7d243bf661
adamk: The first three results apparently have to do with Debian.
adamk: I'm pretty sure there's something wrong with your installation if you have to download all those firmware files manually and install them.
adamk: Seriously, this post is from April of last year: http://lists.alioth.debian.org/pipermail/kernel-svn-changes/2009-April/012243.html
Hazelesque: re: those first three results, none of them appear to be relevant, all random buildd logs and patches
adamk: And RV710_cp.bin is clearly listed as part of the firmware-nonfree package.
Hazelesque: although maybe I see a different first three results to you
Hazelesque: adamk: yes, that file *used* to be there
Hazelesque: in that package
Hazelesque: madarame:linux-firmware$ apt-file search "RV710_cp.bin"
Hazelesque: firmware-linux: /lib/firmware/radeon/RV710_cp.bin
Hazelesque: I then ran apt-file update, and the same search finds nothing
talcite: Hi. I'm about to buy a used laptop with a X1300 in it. It's a RV515 gpu. Does that mean it would have R500 features in the driver?
airlied: talcite: yes
talcite: airlied: great to hear. So then does this mean under gallium 2, the x1300 will have some kind of VDPAU/VA API support?
talcite: gallium3d*
talcite: oops
MostAwesomeDude: Eventually.
talcite: eventually works for me. I still have athlon XP systems in the family =). Thanks for your help guys