egbert: dmb: it will in the quick_and_dirty_2d branch.
ndim: Yay! rhd.h lists (supported?) chipsets which are not mentioned in rhd_id.c logs, and rhd_id.c mentions supported chips which are not in radeonhd.man.
ndim: And partially vice versa.
ndim: 's head implodes.
libv: ndim: urgh
libv: ndim: is it only because of rv770 or is there more than that?
ndim: BTW, can anyone make sense of https://bugzilla.redhat.com/show_bug.cgi?id=452755 ? Second Xorg invocation hangs system with HD 2400 XT, both radeon and radeonhd.
ndim: libv: more
ndim: libv: I have dug out a rejected man page updating patch from october 2007 :)
ndim: libv: I'm trying to make sense of the "supported" lists.
libv: hrm... but 2400 has little that can lock up, we're shadowfb anyway
libv: could it be an FB addressing issue?
ndim: libv: man page is missing RS780 and RV770, and M86 is in man page but is missing from rhd_id.c. rhd_id.c has 34 chipsets, rhd.h has 36.
libv: urgh
ndim: (II) RADEONHD(0): PCI FB Address (BAR) is at 0x00000000 while card Internal Address is 0xD0000000
ndim: (II) RADEONHD(0): Mapped FB at (nil) (size 0x00000000)
ndim: Indeed. That looks fishy.
libv: yeah... what is libpciaccess doing :)
ndim: I can automatically update the man page from rhd_id.c, but mapping rhd.h to rhd_id.c automatically is non-trivial.
ndim: He's using a radeonhd from mid-April.
ndim: I'll ask him to reproduce on the current code, and if that does not help, ask you again.
ndim: libv: The strange thing is that that (nil) mapping is on the first successful run?
libv: ndim: my guess is that this is a bleeding edge kernel and bleeding edge X server issue
libv: ndim: since it happens on both drivers
ndim: Ah, i.e. a "Fedora" issue.
libv: ndim: there have been a fix going into the drm today which fixes some issue with PAT and writecombining
libv: ndim: my guess is that this here has to be searched for in the same area
ndim: I guess I'll do the lazy thing and reassign the bug to the -ati package, and let the knowledgeable people fix the issue for me.
libv: it's consistent between radeonhd and radeon, first X server run, libpciaccess provides correct data, second X server run, libpciaccess provides us with wrong data
ndim: libv: I'll quote you on that.
libv: i don't think -ati should be assigned here, it's a general issue with at least the xserver
ndim: The -ati maintainers know more about that than I do.
libv: X.Org X Server 1.4.99.902 (1.5.0 RC 2)
ndim: I'll leave that for ajax and airlied to sort out.
udovdh: do I see a PAT issue?
udovdh: does it help if I boot and check the HD2600pro on my fedora 9 box w/ 2.6.26?
udovdh: I can check Xorg.log
udovdh: log here looks normal
udovdh: and I do have CONFIG_X86_PAT=y and recent radeonhd
Terman: is there an eta for combined 2d and 3d acceleration?
Tanktalus: whenever I play a movie in, say, kaffeine, it's *extremely* choppy ... is that because I'm missing some configuration or something, or is that expected? (3870HD = RV670)
libv: Tanktalus: to be expected, we have no hardware acceleration
ibrahim: hello I am using Ati x1400 and ubuntu 8.04. I have a lot of problems with fglrx and compiz enabled at the same time because of the DRI problem. the movies are flickering and opengl applications are not rendering correctly. What is the current status of the "radeonhd" drivers? Is that available ? Are there 3d acceleration,
m-c: ibrahim: http://wiki.x.org/wiki/RadeonFeature ; http://www.phoronix.com/forums/showthread.php?s=844e52238b85865d489a98d68b85e322&t=9951
adamk_: ibrahim, radeonhd (and even just 'radeon') now support 3D on your GPU.
adamk_: However, opengl applications have the same problem under compiz. That's an issue with the DRI that's been/being resolved with DRI2
ibrahim: Ok , as I understand that problem will remain also If I install radeonhd or radeon, right?
adamk_: ibrahim, Correct. Though the open source drivers will likely be updated to DRI2 before fglrx.. At least that's my guess.
m-c: Why not take this opportunity to get off of binary blob drivers, if it is all the same to you.
adamk_: ibrahim, Video plaback will actually work properly with compiz, though, with the open source drivers.
ibrahim: My video playback is also fine If I run in full screen mode. It is flickering If I run it in window
adamk_: It works fine in windowed mode with the radeon and radeonhd drivers...
adamk_: Well definitely the 'radeon' driver. Not sure about radeonhd.
ibrahim: hmm ok adamk_ . Do you have any idea when DRI2 will out. Also we need to wait from developers for implement that features to new driver release
adamk_: ibrahim, Well DRI2 is available for testing now on intel GPUs. It requires a memory manager for each DRM driver... I don't have any idea what the ETA is on that.
adamk_: Or if there's even anyone working on it.
ibrahim: Ok adamk_ thanks for your comments. Everything is not clear yet. We should wait new drivers with DRI2 support. And does not matter If I change my drivers to open sourced ones.
adamk_: Well, if you change to the open source ones, you get proper windows Xv video playback in compiz now.
adamk_: DRI2 is not needed for that.
ibrahim: adamk_ , what about the complete stability and features ? Is that open sourced drivers support change frequency of GPU on battery power?
adamk_: I do not believe that power management is functional, no.
adamk_: I would consider them more stable than fglrx, but not as feature complete.
ibrahim: Unfortunately that is really necessary feature because battery will drain very very quick If frequency high on battery
dvandyk: does anybody know where to find the GEM sources?
adamk_: dvandyk, A quick google search suggests there's a drm-gem branch of the drm repo.
dvandyk: see, i wasn't smart enough to add drm to the search
adamk_: :-)
dvandyk: however, google only returns matches for the mesa repo
dvandyk: what i'm searching for is the kernel side of GEM
adamk_: I'm basing my assumption on this: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg35336.html
adamk_: The subject refers to a drm-gem branch.
dmb: MostAwesomeDude, does the backport to mesa 7.0 mean one can use aiglx in an older version of X?
adamk_: dvandyk, I'm cloning now and trying to remember how to checkout a particular branch.
dmb: has to go to work for now so won't be able to respond
adamk_: dvandyk, Looks like this would do it 'git-clone git://anongit.freedesktop.org/git/mesa/drm && cd drm && git-checkout origin/drm-gem'
adamk_: And, on that note, I'm going to get some food.
MostAwesomeDude: dmb: The backport ideally adds r5xx support to the 7.0.3 release. That's it.
MostAwesomeDude: Unfortunately, I couldn't get it to work...
Tanktalus: libv: thanks. I think. :-)
Tanktalus: Is there a page somewhere that lists the TODOs, and their relative priorities? (I'm not looking for "deadlines" or anything silly... just vague ideas of how long before features I really need/want get looked at by the devs.)
BigBrain: Tanktalus: http://www.phoronix.com/forums/showthread.php?p=23918&highlight=roadmap#post23918
Tanktalus: So ... that's a "yes"? :-)
BigBrain: however, depending on how quick radeonhd catches up with radeon, you may need to wait a bit longer
BigBrain: it's not a TODO list, but it can give you "vague ideas of how long before features [...] [you] really need/want get looked at by the devs" ;-)
Tanktalus: yeah, that it does. It even includes dates ... ;-)
Tanktalus: (I'm not sure the dates are accurate or realistic, though.)
Tanktalus: 2D acceleration in 4Q07? Apparently, it's 3Q08 and I still don't have it ;-)
BigBrain: Tanktalus: yeah, that roadmap is speaking about radeon
Tanktalus: oh ... ok. Didn't notice.
BigBrain: Tanktalus: and afaik we already got 2d in rhd too, don't we?
BigBrain: at least on r500
Tanktalus: Unfortunately, I suspect radeon doesn't work on my 3870HD :-(
BigBrain: no problem ;-)
BigBrain: heh, it "works", but no 2d or 3d :D
Tanktalus: Earlier I said "whenever I play a movie in, say, kaffeine, it's *extremely* choppy ... is that because I'm missing some configuration or something, or is that expected? (3870HD = RV670)" and libv responded "Tanktalus: to be expected, we have no hardware acceleration" - I assumed (probably incorrectly) that that is 2D acceleration.
BigBrain: Tanktalus: yeah, for anything above r500 we have no docs yet
BigBrain: which is why I'm happy with my X1600 :D
Tanktalus: wanted something a bit bigger to handle 8 desktops and compositing ... but without proper driver support, apparently I'm not going to see that for a loooong while.
BigBrain: :D
BigBrain: No RV670 support in fglrx, yet?
Tanktalus: It hangs every time I log out.
Tanktalus: Hangs as in deadlock.
Tanktalus: Ctrl-Alt-F1 doesn't get me to a console.
Tanktalus: Can't even ssh in.
Tanktalus: Can't recall, but I don't think I could even ping the machine.
Tanktalus: But I did have compositing working just fine ;-)
mikkoc: what card?
mikkoc: lockups with r500 + drm & mesa git are known
mikkoc: i get 3/4 every day :D
MostAwesomeDude: Somehow, I haven't had ANY r500 lockup.
mikkoc: MostAwesomeDude: how come?
mikkoc: with all the stuff from git?
GerbilSoft: i've got no lockups since those drm lockup fixes were committed
MostAwesomeDude: mikkoc: I honestly don't know.
mikkoc: GerbilSoft: r500?
GerbilSoft: though i've occasionally had X segfaults when trying to unlock xscreensaver after standby
GerbilSoft: yes, rv530 specifically
GerbilSoft: using radeon though, not radeonhd
mikkoc: yea me too
MostAwesomeDude: But yeah, the only lockups I've had were due to testing, when airlied and I were making r5xx stuff at the beginning.
mikkoc: r530 =?
GerbilSoft: FireGL V5200
MostAwesomeDude: Once we got going, I didn't get any lockups.
mikkoc: MostAwesomeDude: what card do you own?
GerbilSoft: leaving now
glisse: MostAwesomeDude: you lucky :) it seems there is quite many card which lockups but of course it's hard to actualy know proportions as people for who it works don't scream on top of the building that it works, neither they jump to protest because it works :)
mikkoc: heh
mikkoc: so i guess x1400 is one of those unlucky cards
mikkoc: mobility x1400 to be precise :)
MostAwesomeDude: glisse, mikkoc: The card is a Radeon Mobility X1600, which is an RV535 (RV515, with RV530 pipes and a bit more speed)
mikkoc: glisse: btw, how is your work on the lockup thing proceeding? ;)
Tanktalus: mikkoc: my hard-lock is with fglrx on RV670 (3870HD) on logout.
Tanktalus: No locks with radeonhd so far.
mikkoc: ah nevermind.. totally different scenario then :)
glisse: well now i fix lockup but after a while one part of the pipe dramaticly slow down and it gives an unusable card ie you have to wait 1s for anyscrolling
mikkoc: ah i see
mikkoc: "after a while" that the lockup should have happened?
glisse: well i go under a lockup condition and the one part of the pipe will slow down
glisse: it's just that i need to find which part and why and how to avoid it, 3 questions none which are easy
mikkoc: i see
mikkoc: glisse: btw, i forgot to mention: i wouldn't mind a slow-down instead of a hard-lockup.. at least i can shutdown the pc properly :)
mikkoc: or maybe restarting X is enough
glisse: mikkoc: patch is not ready at all there is tar at fdo/~glisse with easy name to guess
glisse: note that there is one lockup case not solved due to memory overflow
glisse: this drm only solve bad cmd stream
mikkoc: ah, i dunno which one i got
mikkoc: cant find it here http://cgit.freedesktop.org/~glisse/drm/
glisse: http://people.freedesktop.org/~glisse/hardlock...tar
glisse: it's not a git repository
glisse: it's a ugly hack
glisse: to test and find out what its wrong
mikkoc: ah
mikkoc: i guess i should give it a try
glisse: well knowing if it helps someone else is always valuable
mikkoc: eheh, well i dont think it could get worse than it is now :P
mikkoc: glisse: which part do i need to compile? kernel modules? or libdrm too?
glisse: kernel module only
mikkoc: ok
Nightwulf: hi
Nightwulf: anybody minds to help me with configuring radeon driver with dri (not radeonhd)?
Nightwulf: libGL thinks it can't find r300_dri.so
MostAwesomeDude: Sure.
Nightwulf: but it is installed in /usr/lib/xorg/modules/dri and that path is given as module path in xorg.conf
Nightwulf: all kernel modules loaded correctly and rights on /dev/dri/card0 are ok too
Nightwulf: so how can I tell libGL where to look for the r300_dri.so?
MostAwesomeDude: Nightwulf: The DRI lib path is set at compile-time.
Nightwulf: lol
Nightwulf: so the Archlinux guys did a mistake
MostAwesomeDude: So whatever you set it to when you built it...
Nightwulf: is it set in libGL or libdri or where?
MostAwesomeDude: Easiest way IMO is: pkg-config dri --variable=dridriverdir
Nightwulf: MostAwesomeDude: found the bandit....the env var LIBGL_DRIVERS is set to /usr/lib/dri...thanks!
mikkoc: glisse: im now running your patched modules.. I had to use XAA, because EXA was screwing up really bad (no fonts, almost no windows, etc)
mikkoc: if i suspect the lockup should have taken place, is there a way to find out? (dmesg, Xorg.log?)
glisse: mikkoc: launch several glxgears
glisse: and one heavy texture app like celestia
glisse: or a game in windowed mode
mikkoc: don't have that
mikkoc: yea, game ok :)
glisse: and move one glxgears window over the texture app
mikkoc: heh, i tried both tremulous and ut2004, but they seem to be really messed up
mikkoc: dunno if it's related
mikkoc: File r300_texstate.c function compute_tex_image_offset line 231
mikkoc: DXT 3/5 suffers from multitexturing problems!
mikkoc: ut2004 gives that
glisse: well my drm might lead to rendering issue as it's lazy on flush
glisse: best bet is to compare with current drm head rendering
mikkoc: ah
glisse: see if it's due to my code or if it's an already existing problem
mikkoc: well, i played games just fine
mikkoc: until now :P
mikkoc: but it's ok, i'll keep using it for a full day tomorrow.. if the lockup doesn't happen it's probably solved :)
Nightwulf: re
rafael2k: hi there people
rafael2k: I got the driver working here (w/ the hdmi patch)
rafael2k: but I also got:
rafael2k: Unknown card detected: 0x9610:0x1043:0x82F1.
MostAwesomeDude: rafael2k: IIRC that's purely informational.