max_r: does anyone here knows what's going on in r6xx-r7xx-support branch of mesa?
max_r: wow, the problem with my redbook hello not running on r6xx-rewrite was 1.5.3 xorg-server, with 1.6.2 RC1 something is actually trying to run :)
eschat: hi, can anyone hear me?
ikaiyu: eschat: yes
eschat: can anyone help with ati radeon mobility (ibm thinkpad), xorg and freebsd 7.2?
hifi: yes, uninstall freebsd ánd you're done!
eschat: never!
hifi: whats the problem
eschat: it hangs. the complete system stop's. no log entry, no led activity, nothing
hifi: try Option "BusType" "PCI"
hifi: if it's an agp card
eschat: ok, afk...
Kano: hi, do you want to release a new driver soon
nanonyme: Err, have they even merged anything interesting into master after the last version? o.O
Kano: i define soon within this week
nanonyme: Since I doubt they're going to put stuff that isn't even yet in master into a release.
Kano: i do not need another branch than master
Kano: but as ids have been added like 4770 and some fixes have been made a new stable release would be nice
nanonyme: Oh, right.
Kano: version+git-xyz does not look good somehow
nanonyme: Looks fine to me. ;)
nanonyme: Most distros tend to use that.
Kano: no most distros add hidden patches and keep the last stable name
Kano: then you have got a collection of patches in it, i dont think thats usefull as it still reports the old name
max_r: Kano: afaik there is no support for 4770 now in xf86-video-ati, and until it is there and tested there is no point in making a release
Kano: then test it
max_r: Kano: there is nothing to test yet
Kano: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=15ee78d37f8b64c3e6d234e7ab37a31e82327b6b
Kano: how do you call that
max_r: ( in the sense of 4770, other features like new pm support looks pretty good)
max_r: I call it adding pciid for variant of 4850 x2, you?
Kano: dont know
max_r: look at the patch itself, and btw, title says that this is pciids for rv770, not 4770
max_r: afaik 4770 != rv770
max_r: rv770 == 48xx
max_r: 4770 == RV740
Kano: correct, the missing id must be 9495 because that was the id which was added from 9-4 to 9-5
Kano: and that was the only one
sannes: Hm, where is the FAQ that answers this question: If I'm going to buy a new graphicscard that is supported well by the open source driver (pci express, desktop computer) what is the best card to go for?
rah: there's isn't one
rah: the word "best" is too general to be useful
max_r: sannes: fully supported now are <=r5xx
sannes: max_r: ah, thank you
stikonas: sannes: you will have to wait a few of months if you want 6600, r700
stikonas: s/6600/r600/
max_r: yeah, so if you want card that is supported right now you have to buy quite obsolete card
sannes: Got an X800 now, using the git drivers, I don't update my computer very often (just putting one together now).. but I have been bitten by fglrx before, so I always stick to the open source one ..
sannes: (and with the open source one I mean radeon, not radeonhd)
max_r: sannes: they both have nearly same features
LordVan: hi
sannes: max_r: So what constitutes "fully supported" .. ?
max_r: sannes: 2d/3d accelration
LordVan: got a question: i got about 1-2 weeks old svn r600 driver and when I run gnome with vino (the vnc server prog/lib that comes with gnome) i get one of my 2 cpu cores on 100% at all times ..
LordVan: i just noticed now that it was that
max_r: r6xx/r7xx have full 2d and Xvideo acceleration now but no 3d
LordVan: could it be that there's something in the driver slow / not implemented yet which could cause this or woudl this be a problem with vino
LordVan: ?
sannes: max_r: which means that I will get a software renderer for atleast a year or two before getting acceleration? :P
max_r: sannes: for 3d hopefully it will be fully ready by the end of the year
max_r: sannes: afaik
max_r: sannes: there is already some 3d code in r6xx-rewrite branch of mesa, and it can even run one opengl program for at least one person
max_r: sannes: but buying some r5xx card now seems quite strange to me
sannes: max_r: Most important feature for me is actually KMS :P Which is working with my current card (altough with an OOPS and corruption issue when using multiple screens)..
max_r: sannes: then if it works for you, you could probably stick with that card and wait for r6xx/r7xx KMS support
max_r: sannes: by the time it will be ready there will be faster/cheaper cards on the market so if you don't need it right now there is no point in buying it
sannes: max_r: Heh, yeah, that was my original plan until I remebered I do not have any cooling for it (using water cooling now) and it is not going to be available on the new computer ..
dileX: buy hardware when you have 1. defined your budget 2. a "real" demand.
glisse: dileX: btw i don't remember you don't corruption anymore ?
LordVan: i have to say the current radeon driver works fine for 2d / normal desktop stuff for me
LordVan: of course 3d would be nice but fglrx is a lot worse since it crashes when I stat emacs :d
LordVan: although for a while i had the strangest thing ..
dileX: glisse: hi, the screen corruption is gone. I saw you updated the missing parts of 1/12 subpx precision in the drm-next-radeon kernel.
LordVan: fglrx would work but *only* as root , not with gnome (in my case with e17) and not with things like emacs but WoW through wine worked RoFL
sannes: glisse: hey, by the way, in addition to that OOPS I get trying to use the framebuffer, I also get on-screen corruption in the console when I have two screens connected doing modprobe modeset=1 .. :P
dileX: glisse: I had better looked into the ddx git commits first
glisse: .win 4
glisse: sannes: you're Mike ?
max_r: glisse: are there any eta for end of radeon-rewrite active bugfix season?
glisse: max_r: i am in the middle of
glisse: i have pretty much fixed all r200 bugs
sannes: glisse: No, I'm just me :P
max_r: I am asking because as far as I undestand after radeon-rewrite will merge to master r6xx-rewrite will get more attention, right? :)
glisse: max_r: after radeon-rewrite get merged i will focus on newttm bugs and try to be on time for merging with 2.6.31
max_r: :(
glisse: then i will work on fixing speed regression
glisse: then i will switch to work on new hw
glisse: but there is already people working on r6xx
glisse: hopefully there won't be much left when i will have time to work on r6xx ;)
glisse: but having working kms on new hw is also high on the list
max_r: btw, do you think that r6xx kms/drm bits will be ready in time for 2.6.32?
glisse: hopefully if 2.6.30 is bit slow i should be able to have bit in 2.6.30
glisse: 31
glisse: but it will be in 32 for sure
sannes: newttm/dri2/kms is pretty much stuck together right?
max_r: in .31? really? so next ubuntu version will be able to ship with working kms for all radeon card? it will very good for testing :)
max_r: *will be
glisse: don't know what ubuntu will do but f12 will have all the bits f11 already have some of the bits for newhw kms
max_r: what can we do to deleay release of 2.6.30? :)
glisse: find a regression or serious bug that kernel dev can reproduce
sannes: max_r: Find hard to debug regressions, and lots of them :P
max_r: glisse: btw, do you know what's going on in r6xx-r7xx-support branch of mesa?
glisse: haven't been following closely this work beside cmd submission
nanonyme: Hmm, I wonder if r6xx-r7xx-support could run glxgears properly now.
nanonyme: http://cgit.freedesktop.org/mesa/mesa/commit/?h=r6xx-r7xx-support&id=ce3d7270479744bbe9f19773f34b74743ad61e57 sounds much like a fix to the issue it was having but can't know without trying...
nanonyme: Is it just me or does a lot of the bug fixes seem to be around incorrect calls to functions and incorrect order of function calls...
max_r: nanonyme: I tried today, it doesn't work on hd3650
max_r: nanonyme: but it didn't show anything for me before that fix too
max_r: so it may be working fully now for some lucky guys that had it semi-working back at the first drop
nanonyme: Maybe.
nanonyme: max_r: What does it do for you exactly?
max_r: max_r: crashes
nanonyme: How badly?
max_r: will recompile that branch and pastebin now
max_r: nanonyme: have you tried it?
max_r: nanonyme: http://pastebin.com/m19305f74
nanonyme: Sure.
nanonyme: It locks the whole system for me.
nanonyme: Way worse than what you're getting.
max_r: full log: http://pastebin.com/m706f2d17
max_r: nanonyme: I found out today that using xorg-server 1.6 instead of 1.5 makes redbook hello show a window with r6xx-rewrite :)
max_r: maybe the problem is in 2.6.29 kernel...
osiris__: glisse: could you take a look at http://pastebin.com/m480daaa . this patch makes us of hw accelerated vertex attrs formats like byte and short
osiris__: glisse: it's WIP, I got some simple apps (mesa/progs/trivial glxgears) working, but none of mesa/progs/trivial/draw* works. maybe you will have an idea what I am doing wrong
glisse: osiris__: you compute el_size but dont use it
glisse: in r300EmitElts
glisse: also in fireeb the number of element of cpindex changes if its 16 or 32bits
glisse: maybe also check your change in r300SetupRSUnit
glisse: as i am not remembering offhand what should happen there
glisse: beside that i don't see anyobvious bug
glisse: i will take a deeper look later if you have revised version of the patch let me know
osiris__: glisse: ok, thanks
glisse: note that emitting to much index in fireeb when in 16bits mode would likely cause lockup
osiris__: glisse: hmm, what cpindex in fireeb are you talking about?
glisse: PACKET3_INDX_BUFFER
glisse: mesa names aren't following ati names here i think
glisse: osiris__: here you should do vertex_count >> 1 if you are using 16bits index
osiris__: glisse: yeah, I'm already doing it
glisse: oh yes missed that sorry
osiris__: size = (vertex_count + 1) >> 1; then I use size instead of vertex_count
mekius: Anyone know of any leaks in the radeon driver?
mekius: memory leaks that is
glisse: mekius: none that we are aware off
mekius: hmm, my X seems to just amass large amounts of memory if I'm away from my computer for a long time, know any good ways to debug what's causing it?
glisse: xrestop will give you proper number
glisse: ignore top
Gnutoo: hi, how do I make shaders work on my x700 that has a r300 chipset?
mekius: glisse: ok running xrestop gives me a very different picture heh
mekius: http://pastebin.com/m2a267157
mekius: would seem the allocation is way lower there :/
mekius: I usually use htop
mekius: Which is showing like 975M RES right now heh
mekius: glisse: What could top be seeing that xrestop not be?
mekius: ah, would seem xrestop just displays the client usage?
glisse: http://sourcefrog.net/weblog/software/linux-kernel/free-mem.html
mekius: glisse: Yeah I understand caching and such, but I've never seen this level of memory usage on my other machines
glisse: mekius: well i think there was a small leak in one xserver few revision ago but i think it's now fixed
mekius: well i'm on 1.6.1, going to see if I can find something
mekius: It's just interesting that i only happens when I walk away
mekius: If I'm using the computer it doesn't seem to increase
glisse: bbl
Gnutoo: anyone? according to http://xorg.freedesktop.org/wiki/RadeonFeature I have pixel and vertex shaders...how do I enable them...yo frankie says I've no support for them...
agd5f: Gnutoo: use a GL extension to take advantage of them
agd5f: arb_v_p or arb_f_p
Gnutoo: agd5f, ok how do I enable that?
Gnutoo: and thanks a lot
agd5f: Gnutoo: what are you trying to do?
Gnutoo: just playing yo frankie
agd5f: Gnutoo: not sure what that game requires
Gnutoo: http://rafb.net/p/pgg5IS43.html
agd5f: Gnutoo: it's not clear what extension it's looking for
Gnutoo: ok
Gnutoo: agd5f, it's satiric
Gnutoo: or something like this
Gnutoo: oops
Gnutoo: wrong channel sorry
Gnutoo: agd5f, ok so I can't do nothing ...maybe I should grep the source code?
agd5f: Gnutoo: check the yo frankie source and see what causes that message to be printed
agd5f: or ask on the mailing list if there is one
Gnutoo: ok thanks I'll download the source
Gnutoo: I guess I'll have to wait...there is a "500 - Internal Server Error" on the download page
AndrewR: glisse, hello!
adamk: Are there plans to remove modesetting from the ddx once KMS is completed?
yangman: adamk: not for some time
MostAwesomeDude: adamk: Not from -ati. -modesetting and the Gallium-based DDX might end up becoming popular, though.
adamk: Someone on one of the BSD forums made the claim that modesetting was going to be pulled out of the Xorg drivers once KMS was completed, which is bad news for the BSDs. Since I hadn't heard that, I thought I would check.
osiris__: agd5f: is it possible to use relative addressing with negative offset in r300 vertex program?
MostAwesomeDude: adamk: If the XAA/EXA switch is any indication, we're talking about four or five years before making it the default, and probably another five years before it gets ripped out. :3
MostAwesomeDude: But the guy on the BSD forums can stuff it. :3
adamk: Kind of what I thought.
adamk: I'll relay that information, but skip the part where he can go stuff it :-)
MostAwesomeDude: I figured. :3
MostAwesomeDude: But I always get ticked when people don't talk to us, but then say that they talked to us and that they know "the inner circle's opinion."
adamk: yeah, the first thing I did when i saw his post was to ask who he had heard that from.
adamk: There appears to be a lot of disinformation in the Xorg world, and even more in the Xorg/FreeBSD world :-)
MostAwesomeDude: Yeah, right now I'm correcting a few people on /. who think that DGA's a good thing to use in brand-new code. :C
adamk: Hasn't it been deprecated for years now?
MostAwesomeDude: Oh yeah.
MostAwesomeDude: They want to use it for mouse-grabbing, so that's DGA1.
MostAwesomeDude: And that was deprecated in 2003, when it was first imported into git. :3
MostAwesomeDude: The copyright on the header was 1995. I think that saying it was deprecated a decade ago isn't a stretch. :3
scarabeus: ow come on it is just 15 years
scarabeus: we use older cars somewhere ;]
Curan: MostAwesomeDude: but it's quite obvious why people claim they know what the inner X.org circle i going to do: they want to seem important ad admired...
Curan: MostAwesomeDude: such people are virtually on every platform about IT I've read so far
gravity: The inner circle hasn't traditionally been very good about communicating even to the outer circle what its plans are
MostAwesomeDude: Curan: Yeah, but the only private place in all of X is XDC, and we release all the notes from that.
mjg59: Well, Intel plan to remove stuff like DRI1 support
MostAwesomeDude: gravity: Should we have press releases? We already have the ML. In particular, xorg-announce still is used.
jcristau: mjg59: they already did
gravity: MostAwesomeDude: I don't know. I've been trying to come up with good ideas about this for years and still don't have any :-\
mjg59: And modesetting at some point
gravity: Lots of shitty ideas though
Curan: gravity: I think if something unclear one can ask on IRC, at least that is my experience
MostAwesomeDude: To be fair, DRI1 is intensely painful, and if you can force people to upgrade their entire stack at once, then you might as well break the backwards compat.
mjg59: BSD really needs to have more developers step up if they want continued hardware support
mjg59: It's not a focus of many developers
mjg59: And you can't expect people to continue carrying otherwise dead code just for OSs that aren't contributing any significant development back
gravity: Curan: A lot of times things come out of the blue so you don't even know what to ask until after the thing is done
gravity: MostAwesomeDude: To be honest, I like the trend of blogging that's been going on. keithp's blog entries, though infrequent, are the most valuable source of new information on X that I've seen yet.
adamk: mjg59: Lack of developers does not equate to a lack of users... I can understand why primarily linux developers don't want to carry dead weight to support other OSes, but it does negatively impact a lot of users.
mjg59: adamk: I really don't think the number of desktop *BSD users is large compared to Linux at this point
adamk: mjg59: Sure, not as large as the linux user base, but I think you might be surprised at how big it is... Especially when they start e-mailing the Xorg mailing lists complaining about the direction of Xorg.
Curan: gravity: to be honest: I'm not that bleeding edge with X stuff and most of the time rely on the DDs (like you) to do the right thing™ but as I'm quite interested in the progress of the radeon driver I visit this channel from time to time so I get a feeling (so to speak) what will probably come up soon
mjg59: And, at the end of the day, usermode modesetting sucks. And if you can't provide KMS then users are going to migrate to an OS that has it.
adamk: If it weren't for rnoland's work so far on FreeBSD, I think that would already be happening.
MostAwesomeDude: adamk: The big thing, I feel, is that the few of us that *are* paid are not paid to do BSD work.
mjg59: adamk: Precisely. If there were more development from the BSD side, this wouldn't be an issue.
adamk: MostAwesomeDude: I realize that. That doesn't change the feelings of the BSD users who don't like what they are seeing :-)
gravity: Curan: Well, since I have to learn what the Right Thing To Do is, it's nice to be able to understand it first. IRC is a huge help, and the community is great, but being surprised every few weeks by a new acronym or design has been... trying.
MostAwesomeDude: "You must be the change you wish to see in the upstream."
adamk: mjg59: You say that usermode modesetting sucks, but in these users minds, it's been working for years, and working just fine.
adamk: In any case, I'm hopefuly that in 10 years, when mode-setting is dropped from the DDX, it will be available via KMS on the BSDs :-)
Curan: gravity: I hope you didn't get me wrong on that, I didn't intend to give offence. Anyway I very much appreciate the work of the DXS (now even evdev and KDE are working for me *g*)
mjg59: adamk: If users are happy with the status quo, then they don't need to care about loss of functionality in later releases
gravity: Curan: No, not at all. Like I said, it's just been something I've been thinking about for a long time and would love to see improved if I could come up with good ways to do it :-)
mjg59: But people are simply going to stop writing userlevel modesetting support for newer chipsets
gravity: I tried to do the relnotes for the katamari a while back, but they didn't get used for whatever reason
mjg59: It's not so bad on Radeon, where atom will probably carry on working
mjg59: But I'd be surprised if anyone ever writes a UMS driver for poulsbo, for instance
mjg59: Well. Ok, to be fair, it wouldn't surprise me if nobody ever writes a proper KMS driver for Poulsbo either
kylem: i'm suprised you haven't done it yet. ;-)
kylem: guess there isn't enough liquor in london.
mjg59: No hardware
kylem: ;-)
mjg59: Not drunk enough
spstarr: hmm
spstarr: AMD is hiring
spstarr: but i'd need to settle on a junior/int job not senior ;/
salvo: hiall
salvo: can't fix yellowish desktop with radeon ,i did try many xorg.conf configs. using radeon 9000 on ubuntu jaunty. EXA.
salvo: do you have a fix?
MostAwesomeDude: Are you sure that your monitor's okay?
MostAwesomeDude: When did it start being yellow? Did you do any updates?
salvo: btw i did follow many howtos and wannabe fixes , i built my xorg.conf with many tentatives and reading man radeon. 3D is good enough 2D on the DE too. but i have that yellow flickering all over.
salvo: MostAwesomeDude, it is new and apparently i'm not the only one
salvo: MostAwesomeDude, jaunty installed from scratch
MostAwesomeDude: salvo: I haven't heard of this problem before.
salvo: MostAwesomeDude, just google for (jaunty) radeon yellow {terminal|desktop|flickering} yourself and see
salvo: rolls up a cigarette
MostAwesomeDude: Hm. Let's see. I have one Ubuntu Forums post saying "yellow plz help" and one post related to fglrx.
MostAwesomeDude: What did you put in your xorg.conf for radeon?
MostAwesomeDude: Could you pastebin your xorg.conf?
salvo: MostAwesomeDude, here's my search http://tinyurl.com/pybmtc , xorg.conf coming in a sec
salvo: MostAwesomeDude, http://pastebin.com/f7de61258
MostAwesomeDude: salvo: A lot of those options are bogus or unneeded. Did somebody tell you to use those options?
MostAwesomeDude: Also is this a PCI or AGP card?
salvo: MostAwesomeDude, nope. did that myself .
salvo: MostAwesomeDude, it's AGP but in a bug on launchpad they told touse PCI (with AGP it doens' work. i get no X starting)
salvo: at least the one time i tried
agd5f: salvo: your probably have to force a particular agp mode
salvo: i can try again
MostAwesomeDude: Yeah, AGP cards are buggy sometimes.
salvo: i did put AGP 4
agd5f: Option "AGPMode" "X" where X= 1 or 2 or 4 or 8
adamk: Very few of those google results seem to actually pertain to yellow graphics, btw :-)
salvo: i did put AGP 4
salvo: adamk, i can see 4 in page one
salvo: 5 even =)
agd5f: salvo: you have to remove the bustype option if you want to test agp
MostAwesomeDude: You should comment out XAA no offscreen pixmaps, use FB dev, at least, since those have no effect.
agd5f: also, if 4 doesn't work, try 1 or 2 or 8 (depending on what type your motherboard supports)
salvo: MostAwesomeDude, i can try that again. but even if they are not used X won't start without them.
adamk: One talks about a yellow terminal, another about yellow glyphs,
salvo: agd5f, my 9000 is 4, i might check the BIOS too beofre changing
salvo: adamk, i have both
MostAwesomeDude: salvo: Something is very wrong if XAANoOffscreenPixmaps keeps your card from coming up with EXA.
salvo: MostAwesomeDude, arf
agd5f: salvo: ok, but if 4 causes a lockup, try 1 or 2
adamk: salvo: My point is that you might be over estimating how common of a problem this is, which is why no one here has heard about it.
salvo: adamk, MostAwesomeDude, http://pastebin.com/f9ec12e1 http://pastebin.com/f73d1172 http://pastebin.com/f2134380a
agd5f: as alot of agp chipsets are broken and only work in certain modes
salvo: adamk, MostAwesomeDude : those paste are cat /var/log/Xorg.0.log | grep WW | pastebinit && cat /var/log/Xorg.0.log | grep EE | pastebinit && cat /var/log/Xorg.0.log | grep EXA | pastebinit
MostAwesomeDude: salvo: If you're going to pastebin the log, pastebin the entire thing.
salvo: MostAwesomeDude, ok sorry. i tought that WW EE and EXA could be enough
salvo: should i paste?
salvo: MostAwesomeDude, should i paste the log?
MostAwesomeDude: salvo: You can pastebin it, sure.
agd5f: salvo: yes
salvo: ok
salvo: adamk, MostAwesomeDude here it is http://pastebin.com/f19f75236
Curan: salvo: Maybe starting with a fresh and clean xorg.conf (dpkg-reconfigure -phigh xserver-xorg) helps (at least to nail down the culprit, by changing one option at a time)?
MostAwesomeDude: I'm not seeing a problem in the log.
agd5f: salvo: try the agpmode option until you find one that works so we can add a quirk for your chipset
salvo: Curan, that's what i've started from. the i tried XXA and afterward EXA.
MostAwesomeDude: Although the log *does* say that XAANoOffscreenPixmaps, UseFBDev, and TripleBuffer aren't used.
salvo: MostAwesomeDude, i know it says that. but believe me... without them X won't start.
salvo: anyway i'm going to try hat you and adamk said.
adamk: salvo: Remove those options, try to start X, and then pastebin the newly formed /var/log/Xorg.0.log file.
salvo: AGP 1 2 or 4 and comment out few things
agd5f: salvo: also comment out the bydtype option when you test agpmode
agd5f: *byustype
salvo: adamk, ok. let me install weechat so i'll have a client for IRC in bad case
agd5f: bustype
salvo: ok
salvo: so to sum up: comment out bustype , unused options and ?
salvo: change AGP to?
agd5f: Option "AGPMode" "1" or "2"
salvo: ok
salvo: trying with 2
salvo: adamk, MostAwesomeDude be back in a sec
rainbyte: hi
salvo: hi im back , please forgive bad typos since im on en_US locale with an it_IT keyboard
salvo: adamk: MostAwesomeDude http://pastebin.com/f4a0b7e28
salvo: FYI: X failed
agd5f: salvo: log looks fine, also, you still have pci bustype set
salvo: agd5f: nope BusType is commented with #
agd5f: salvo: well, it's still being used according to the log you pastebined
salvo: adamk: agd5f: logs seems the previous one
agd5f: salvo: well, if it locked up, it might not have written the log
agd5f: salvo: did you try agpmode 1?
salvo: i will mv the log and create a new one
salvo: only 2 for now
salvo: going the restart X
salvo: i moved the log
salvo: adamk: agd5f MostAwesomeDude: new log http://pastebin.com/f1c4d89d9 (X started)
salvo: but yellow flicker still there
salvo: FYI:yellow flickering happens only in X , here in TTY it is ok
Maestro123: gentoo? driver radeon! eselect opengl set ati or x11 ?
sannes: x11
Maestro123: thanks
chithead: Maestro123: make sure that the fglrx kernel module is not loaded when using radeon
Maestro123: fglrx not installed
chithead: you have ati in eselect opengl only after installing fglrx
Maestro123: eselect opengl list
Maestro123: Available OpenGL implementations:
Maestro123: [1] ati
Maestro123: [2] xorg-x11 *
Maestro123: but fglrx not installed
chithead: then it was not uninstalled properly or so. "qlop -lu ati-drivers"
chithead: anyway as long as you don't load fglrx kernel module you should be ok
Maestro123: x11 ?
yangman: Maestro123: fglrx's OpenGL is "ati"
Maestro123: ok
Maestro123: cat /var/log/Xorg.0.log|grep EE
Maestro123: (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
Maestro123: (II) Loading extension MIT-SCREEN-SAVER
Maestro123: (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)
Maestro123: (EE) AIGLX: reverting to software rendering
adamk: Maestro123: There is no 3D acceleration for your video card in Xorg.
Maestro123: is it bad?
adamk: Maestro123: If you want 3D acceleration, you must use fglrx.
Maestro123: 3d experimental from git ?
adamk: *Very* experimental and only of use to developers.
chithead: will allow to run hardly more than mesa demos and glxgears
Maestro123: =(
Maestro123: long wait for 3d?
chithead: it is under development. r600 3d support comparable to what is r500 today is announced to happen this year
yangman: nothing announced
yangman: rough target
Maestro123: radeon or radeonhd ? what is better?
nanonyme: Irrelevant nowadays unless you have very specific needs and in the future it's likely they both will get replaced... :)
adamk: They are roughly the same in terms of features and performance.
chithead: Maestro123: if you want hdmi audio, use radeonhd. if you want power management, use radeon. else what nanonyme and adamk said
nanonyme: chithead: I thought radeonhd could do power management nowadays too.
nanonyme: And it was mostly radeon for tv out and radeonhd for HDMI audio.
nanonyme: Could be wrong of course.
chithead: nanonyme: seems you are correct
nanonyme: For a generic desktop user it *really* should make no difference.
nanonyme: I heard it said that the most significant differences were in modesetting and that's moving to KMS anyway.
Maestro123: radeonhd - all exits card,but not read xorg.conf (1024X768_!84.9!ghz =))
MostAwesomeDude: Actually, the biggest difference is in the length.
MostAwesomeDude: See, radeon is six letters, and radeonhd is eight letters.
MostAwesomeDude: That's a two-letter difference.
nha: OMG!
nha: that means radeon must be much more efficient and lean!
MostAwesomeDude: OMG
nanonyme: MostAwesomeDude: Isn't r500 modesetting done in differing ways in the two drivers?
MostAwesomeDude: nanonyme: Not anymore.
nanonyme: Oh.
nanonyme: Since when did that change?
MostAwesomeDude: There's a few tiny differences, but they don't matter much.
MostAwesomeDude: (Except sometimes radeonhd fails to bring up cards that radeon brings up, and vice versa, but those are really rare now.)
yangman: nanonyme: well, by default, yes
phoenix64: okay, a friend of mine told me of several segfaults in connection with the radeon driver that disappear with LIBGL_ALWAYS_SOFTWARE=1 (radeon 9600, same thing probably also described here: http://code.google.com/p/pyglet/issues/detail?id=419)
phoenix64: could that be a fault of the driver? If not, where would I have to look for?
phoenix64: if does not only crash in glGetStrings in some program, in mine it crashes somewhere completely unrelated, jumps to 0 when it's supposed to call a constructor
MostAwesomeDude: phoenix64: Probably DRI setup problems.
phoenix64: there he is
PommesDieFritte: hello :D
phoenix64: well, I have virtually no idea of all that
phoenix64: "
nha: PommesDieFritte: do you create an OpenGL context before calling glGetString()?
phoenix64: would mesa succeed with software rendering if the game he ran didn't?
nha: PommesDieFritte: calling glGetString() without a current context is undefined and allowed to crash, though I think both binary drivers kind of paste over that
phoenix64: also, I definately do
PommesDieFritte: I don't know, that's not my game, i don't have the source code
nha: okay, just asking, because it's a typical mistake
phoenix64: we already looked at that one actually
phoenix64: DRI error messages are in the xorg log?
phoenix64: (rendering does usually work however)
nha: hehe, the referenced bug report http://www.mail-archive.com/debian-x@lists.debian.org/msg75197.html already talks about glGetString before context creation
nha: well, if a context is indeed current when you call glGetString, the next step would be to create a backtrace with debugging information included
phoenix64: sure, but I doubt it is this
phoenix64: well
PommesDieFritte: I'm downloading the source right now...
phoenix64: in my program it crashes somewhere completely different, and I definately do have a correct OGL context
nha: sometimes distros have -dbg packages
phoenix64: "libgl1-mesa-dri-dbg"?
nha: phoenix64: then you should probably provide a backtrace and more detailled info :)
nha: phoenix64: that would be the one
phoenix64: the thing is that I cannot get any useful backtrace as it ends up in "#0 0x00000000 in ?? ()" instead of calling a constructor.
phoenix64: that being in a function that has nothing to do with OGL
phoenix64: hm, wait
nha: you mean to say that the backtrace contains nothing else?
phoenix64: PommesDieFritte, could you paste the output of valgrind again?
phoenix64: http://pastebin.com/d4eac89d7
nha: oh, another typical bug in this arena is to call OpenGL functions that are associated to extensions without checking whether the extension is actually availabe
PommesDieFritte: valgrind? okay
phoenix64: I think there were some references to unitialized memory in valgrind, don't remember though
nha: so, what does backlot::Map::compile do? does it call any OpenGL functions at all?
MostAwesomeDude: Yeah, sounds like somebody didn't fill out a callback properly.
phoenix64: "that has nothing to do with OGL"
phoenix64: it's a *constructor* :D
phoenix64: sec, I'll paste those lines
MostAwesomeDude: nha: You mean, like the no-op dispatch bug?
nha: phoenix64: do you also get "Unknown ioctl" lines in valgrind? Unfortunately, I don't think anybody has created valgrind specs for the radeon drm ioctls, which means that valgrind will often think that the driver is trying to access uninitialized memory even though the memory is valid, only returned by an unknown ioctl
phoenix64: ok, then that's probably
phoenix64: *that's it
nha: phoenix64: huh? How is a function called "compile" in a class called "Map" a constructor?
phoenix64: http://pastebin.com/m61ab7999 <- crashes in line 4
nha: MostAwesomeDude: something like that
phoenix64: the constructor seems to have the value "0", so it's jumping there
nha: ah I see
phoenix64: hm, QuadBatch indeed executes OGL functions.
phoenix64: PommesDieFritte, could you try to comment them out from the constructor?
PommesDieFritte: line 4?
PommesDieFritte: http://pastebin.com/m38ae36db <- that's what valgrind says if you still need it
nha: phoenix64: yeah, if you compiled with optimizations enabled, maybe the constructor call is inlined? I don't know if g++ does that kind of stuff, but it could explain the strange backtrace.
phoenix64: d'oh, yeah, that'll be it
phoenix64: cmake always enables optimization by default (also happened in debug mode)
nha: PommesDieFritte: re valgrind: dunno about the first one in SDL, but the next three certainly seem to be of the type "valgrind doesn't know about our ioctl and so produces incorrect warnings"
MostAwesomeDude: Conditional in r300CreateContext is our bug.
nha: it's unfortunate, really, and on my long list of things I should probably do some day if nobody else does them
MostAwesomeDude: The null pointer call is not.
nha: MostAwesomeDude: you think that's a genuine bug? Go fix it :)
MostAwesomeDude: nha: I need line numbers. Don't feel like hex editing today. :3
MostAwesomeDude: PommesDieFritte: Could you rebuild your DRI with symbols (a debug build)?
MostAwesomeDude: Or is this reproducible?
phoenix64: MostAwesomeDude, wouldn't "libgl1-mesa-dri-dbg" be enoguh?
MostAwesomeDude: phoenix64: Yes, it would.
MostAwesomeDude: didn't know which distro it was
nha: MostAwesomeDude: I see valgrind warnings a lot, I'm almost certain this is reproducible
phoenix64: well, we have one other person who experiences this probably, might be something else though
nha: MostAwesomeDude: Syscall param ioctl(generic) points to uninitialised byte(s)
nha: MostAwesomeDude: this looks to me like valgrind thinks it understands the ioctl, but it actually understands it incorrectly
nha: I've seen this with one of those GET_PARAM ioctls
nha: somebody should really go over valgrind's understanding of what the DRM does
MostAwesomeDude: nha: Yeah, I traced those, and it's basically valgrind not quite getting the point of GET_PARAM.
MostAwesomeDude: Didn't know how to fix it though.
nha: well, this is something for another day
nha: is going to crash
phoenix64: hm, okay, how to set the dri driver path again?
phoenix64: -.-
phoenix64: ah
phoenix64: I'm too stupid to enable the dri debugging symbols
phoenix64: I'll try again tomorrow
phoenix64: gn8
tormod: I get blooming when switching to a VT, can this be radeon-rewrite's fault, or kernel?
tormod: on an M26 laptop screen that is.
DanaG: I'm switching back to the open drivers; I'm sick of the closed drivers' screwed-up video playback. :(
DanaG: I'll be using the ones in Tormod's PPA.
DanaG: Screwed-up video playback and unreliable resume outweigh compiz and now not as big power savings.
DanaG: That is, now radeon has some power savings, so the difference between it and fglrx is less than it was before.
DanaG: zaps xorg
DanaG: Note to self: don't let compiz try to run on software rasterizer; it gives a white screen.
spstarr: waits for r6xx code to test in rawhide
DanaG: hmm, what'll be next down the line for R600>
DanaG: ... to go into Master?
DanaG: Neither KMS nor 3D is there. =þ
MostAwesomeDude: DanaG: KMS is trivial for r6xx. I think it'll be KMS+GEM.
DanaG: yay: http://www.phoronix.com/scan.php?page=news_item&px=NzI4OA
spstarr: looks
spstarr: http://www.phoronix.com/scan.php?page=news_item&px=NzI3MQ <---
spstarr: this would seem to play into switchable graphics somehow
mjg59: Not really, no
mjg59: VGA arbitration only matters when you have multiple cards
MostAwesomeDude: Well, it's related, yeah.
spstarr: mjg59: well technically 2 GPUs 'is' two cards
mjg59: spstarr: But not simultaneously
spstarr: right
MostAwesomeDude: But the arbiter could still make it easy to pick *which* card is on.
mjg59: MostAwesomeDude: Unf. It works out harder than that.
mjg59: We can't tie PCI bus locations to state in any sane way
mjg59: Well, that's not entirely true. With the nvidia one we can to a certain extent