leo: ok soreau
leo: i am still having problems
leo: i'm going to pastebin my Xorg.0.log
leo: http://pastebin.archlinux.fr/346768
leo: please hurry
leo: tired
leo: oh and the xorg.conf:
leo: http://pastebin.archlinux.fr/346769
leo: hello?
leo: this shit is all broken
leo: root
leo: please, someone help out of here~
leo: /msg me if somebody has a guide to install radeon x1200, information on how to do it, anything
leo: i'm going to sleep
fcami: I think "RS690 is evil" should be included in /topic
AndrewR: testing KMS on my AGP radeon [rv280] card ... it works, for 2d. But for 3d it shows "adding fb map from 0 for 800000 ret -22 0" and no 3d .. Is it normal?
oyvind: Hi, I'm having a problem building the latest snapshot of the radeon-driver from git://anongit.freedesktop.org/xorg/driver/xf86-video-ati. Configure bails out on some macro-errors: http://paste.ubuntu.com/162706/ any takes ?
dileX: glisse: hope this fixes problems with latest drm-next-radeon
glisse: dileX: i already pushed the missing file
dileX: glisse: 4min ago, but atombios_crtc.c is complaining see my paste
glisse: it shouldn't not complain anymore i push ~2min ago
glisse: here my tree compile and it's same as what is in git now :)
dileX: glisse: I will update and see
JamesLast: airlied: i have a strange problem with modesetting, chipset is an x700 mobility. Booting rawhide results in an whitescreen, however when i close the laptop lid after X started and open it again everything works like it should.
dileX: glisse: OK, I see. you removed the includes
airlied: JamesLast: wierd, can you log a bug from a boot with drm.debug=1 on the kerenl command line?
JamesLast: airlied: ok, will do so
JamesLast: airlied: boot-dmesg: http://pastebin.com/m73102141
osiris__: airlied: have you seen my e-mail on mesa3d-dev?
glisse: osiris__: we would like to see your email on mesa-commit list ;)
osiris__: glisse: hehe, I just want to know if the proposed solution (new field radeon structure) is the good one)
osiris__: *in radeon structure
adamk: airlied, Any ideas why this is happening with KMS enabled? http://www.npark.com/wavy.mpg
glisse: osiris__: what is the mail topic name ?
osiris__: glisse: "One patch for radeon-rewrite branch"
glisse: osiris__: according to patch there is only change in mipmap_tree.c
osiris__: glisse: read all emails in the topic
glisse: only 2 emails in the archive, the others is from Roland
glisse: maybe your last one didn't yet get through
osiris__: glisse: yeah, looks like I've send the reply to Roland, not to list
osiris__: glisse: anyway, I think there's no point in calculating the alignment for every compute_tex_image_offset function call because it is always the same during context lifetime
osiris__: glisse: so I propose to add one field to radeon structure, and initialize it during context creation based on chip family
airlied: osiris__: sounds like a good plan to me
airlied: adamk: no idea, probably need to use avivotool to diff the pll/mode regs
adamk: Hmmm. Never used it... I'll see what I can find out and open up a bug report.
asdgasd: ok i'm still trying to fix this x1200 (rs690)
asdgasd: i don't seem to have startx or xinit for some reason, but when i load Xorg it flashes white real quick and then freezes completely
airlied: asdgasd: got a log file?
adamk: Alright, so where can I grab avitool? :-) I thought it might be in the source for xf86-video-ati
airlied: its inmy radeontool repo
airlied: assuming you are on a r5xx or later
airlied: we need to use radeontool for the older ones
airlied: which is harder work.
adamk: Hmm... This is an x850.
adamk: I wonder if I can reproduce it with my x1900.
airlied: can do it with radenotool just a lot more hassle so wont be now :)
glisse: airlied: is their a piglit test for mipmapping ?
asdgasd: what log file do you want airlied
airlied: asdgasd: /var/log/Xorg.0.log
asdgasd: hold on
airlied: glisse: mipmap_limit test and not sure mayb glean has one
asdgasd: airlied: http://pastebin.archlinux.fr/346798
airlied: asdgasd: you seem to have half an fglrx install still there, also radeonhd is in #radeonhd
airlied: if you have a radeon log I can look at it
asdgasd: how do i wipe out the rest of fglrx
asdgasd: i got rid of hte packages for catalyst and catalyst utils
airlied: you might need to reinstalled the mesa packages
glisse: crap it seems i regress everythings with newtmm
airlied: glisse: be careful of the freeglut trap :)
airlied: glisse: you testing vs rawhdie or nomodesetting at all?
glisse: userspace exactly the same
glisse: lastest rawhide kernel
glisse: i think it's the missing irq stuff
glisse: what is the freeglut trap ?
glisse: btw sorry ofr forgetting that adding scissor stuff would need update to r300_cmdbuf
airlied: glisse: freeglut fails lots of test randomly
airlied: it has a startup race with window exposure
airlied: mesa glut is fine
glisse: i think my problem is that r300 driver is falling back to busy wait
glisse: no irq stuff
airlied: I've no irq stuff either
airlied: it should call the wait for bo in that finish path
glisse: well with rawhide i don't see the error message
glisse: while with newttm i see it
airlied: might be getparam failing
glisse: yup there is no more getparam :)
airlied: that can cause piglit fail
airlied: check my createscreen2 path
airlied: and remove irq setup if its in there.
airlied: piglit doesn't like stray output
nanonyme: wonders how much time developers spend on just trying to figure out the differences between different branches :)
airlied: glisse: just set screen->irq to 1 and drop the getparam
adamk: Hmmm.. It does happen with the x1900, too.
adamk: Not as bad, but still quite wavy.
glisse: airlied: yeah seems to fix things
glisse: glean/texture_srgb fail but it works on rawhide and on the opposite glean/texgen fail on rawhide but work on newttm...
airlied: asdgasd_: try reinstalling mesa and xorg packagse
airlied: and maybe try using radeon instead of radeongd
asdgasd_: radeonhd has better support doesn't it
asdgasd_: http://pastebin.archlinux.fr/346800 this is what i have now
airlied: not really.
airlied: its still got libdri from fglrx installed
airlied: which means you need to reisntall xserver
dileX: airlied: the "freeglut trap" is explaining why piglit failed here. which version did you try? Freeglut 2.6.0 Release Candidate 1 [Released: 23 Apr 2009]
asdgasd_: brb
airlied: dileX: not yet I meant to fix it just haven' thad time
dileX: glisse: regressions with latest drm-next-radeon (w/ dmesg)
glisse: dileX: what where you doing ?
dileX: glisse: scrolling down a photo-gallery in firefox
glisse: one of the object is 32M :)
glisse: too big for the GART or VRAM
dileX: glisse: dont misunderstand - I have no ambition to marry. thats the website
dileX: glisse: its a x1300 (pcie) with 64M vram
mcgreg: hi
mcgreg: what version of radeon do I need to get "xv" working?
nanonyme: Which card?
mcgreg: ohh good counter question :) 4670 :)
nanonyme: Unsure, I haven't been using releases for quite some time.
glisse: mcgreg: don't think ddx code is in any release yet, anyway you will need drm from git
mcgreg: so -> wait for now :)
osiris__: MostAwesomeDude: space accounting seems to be broken on with swtcl path (gallium driver)
MostAwesomeDude: osiris__: I know, it's broken to hell, I haven't fixed it up yet. :3
MostAwesomeDude: Gotta move the vertbuf setup and accounting over to the r300_emit setup.
osiris__: MostAwesomeDude: too bad, I was going to play a little with it
MostAwesomeDude: Need to validate all the bufs (colorbufs, zsbuf, vertbuf, texs) at once.
osiris__: MostAwesomeDude: does the driver has some function to print command sequence that it's pushing to gpu?
MostAwesomeDude: osiris__: Nope. It'll dump the CS if it can't be submitted. You could add something in radeon_r300 to fix that.
JamesLast: airlied: did you have time to look at my log ?
nielsslot: mcgreg: for Xv on a 4670 see http://wiki.x.org/wiki/radeon%3Ar6xx_r7xx_branch
mvw: hi i have troubles getting the ati/radeon driver to run on FreeBSD 7.2, what is a good place to post that problem?
nanonyme: Unsure but what's the card and what's the problem?
mvw: it gets detected aATI Technologies Inc M9+ 5C61 [Radeon Mobility 9200 (AGP)] rev 1s
mvw: It is a notebook card within an Acer Travelmate 290 (or rather 292)
mvw: I tried many configurations
nanonyme: What is it that doesn't work? X at all or some acceleration thing?
mvw: but it dies always after it switches into graphics mode
mvw: if try to load the radeon.ko kernel module the notebook freezes as well except for one curious exception
mvw: i was able to load that, when i had the vesa x driver running
mvw: very strange
nanonyme: You aren't trying to load it while running X, are you?
mvw: normaly i don't touch it
mvw: so it gets not loaded by me
mvw: just out of curiosity i loaded it using kldload
mvw: but it froze the notebook
mvw: except in that one case, when X with vesa was running
nanonyme: I've no idea what kldload is. :)
mvw: it loads kernel modules under freebsd
mvw: in this case it is supposed to offere drm for radeon
dileX: glisse: w/ latest drm-next-radeon and ddx scrolling the huge photo-gallery looks good, now.
mvw: (i think)
nanonyme: mvw: But you did use kldload while X was not running, right?
mvw: in that case radeon.ko froze my system
mvw: it was only loadable under x (vesa) so far :)
mvw: is there any chance to sort out is going on?
mvw: or do i need to revert to my old system?
MostAwesomeDude: mvw: You need to stop X before loading any DRM modules.
mvw: I do not normaly try loading anything at all
mvw: the driver should load the drm.ko or?
osiris__: MostAwesomeDude: btw, it would be good if you could create some guidelines for code style & formatting for radeon gallium driver
MostAwesomeDude: Stop X, kldload radeon, start X.
mvw: that freezes the box
MostAwesomeDude: osiris__: Four-space tabs, clean is better than quick, use nice C that's easy to read.
MostAwesomeDude: mvw: You should probably file a bug then.
mvw: where xorg or freebsd.org?
nanonyme: MostAwesomeDude: *chuckle* @ the last part in the guidelines
MostAwesomeDude: nanonyme: Yes, I know my C is hax.
osiris__: MostAwesomeDude: if { or if\n { ? int some_variable or int someVariable ?
MostAwesomeDude: osiris__: Ah.
nanonyme: MostAwesomeDude: Naw, nothing personal. Writing "nice C that's easy to read" just seems to be a near impossible task. :)
MostAwesomeDude: nanonyme: I think I come close in some parts of r300-gallium.
nanonyme: Yeah? Neat.
phoenix64: r300-gallium *is* easy to read :D
MostAwesomeDude: osiris__: Don't cuddle function braces, cuddle switch/if/while, use underscores instead of camelCase.
MostAwesomeDude: Generally follow what's already there. If I *really* don't like something, I'll change it. :3
MostAwesomeDude: But I'd rather have "working" than "pretty" right now.
MostAwesomeDude: should switch to dev environment and finish space accounting.
nanonyme: thought of taking a look at r600 Mesa driver but got fed up with the idea in 2 seconds after seeing how many files there are :D
nanonyme: Apparently 211k lines total.
MostAwesomeDude: looks at r600
spstarr: it helps having LONG_DESCRIPTIVE_DEFINED_NAMES when reading the code :-)
MostAwesomeDude: Ick.
MostAwesomeDude: I mean, wow.
MostAwesomeDude: Ag. That is a lot of code.
nanonyme: Yeah, not a very welcoming codebase.
MostAwesomeDude: And lots of magic.
MostAwesomeDude: is not having fun imagining turning that into Galliumized code
nanonyme: MostAwesomeDude: I suspect the porting from r6xx-r7xx-support stuff to r6xx-rewrite might be more annoying.
osiris__: agd5f: ping
MostAwesomeDude: nanonyme: Honestly, the thing is just getting an understanding of the HW.
MostAwesomeDude: Stuff like the RS block gets really simple once it's re-conceptualized in terms of Gallium and not OGL.
nanonyme: Hmm, right.
MostAwesomeDude: I expect that the r600-gallium driver will be a shader assembler, a relocator to set up shaders for VS, GS, and FS; a handler for the PA, and then bits of glue.
nanonyme: MostAwesomeDude: I just noted since that 211k lines of code will still hve to get rewritten to be compliant with radeon-rewrite. :3
MostAwesomeDude: Lots and lots of shaders.
nanonyme: I suspect it will not be a fun task.
MostAwesomeDude: Nope.
MostAwesomeDude: Not at all.
nanonyme: And the plan is that it will be done first, only then new features for r600 codebase will be written. ^^
nanonyme: Afaik.
chithead: I am trying radeon kms from glisse's drm-next-radeon, but fonts are huge. this was also the case with non-kms before an edid quirk was added. can I add the quirk to the kms code somehow?
nanonyme: chithead: Kinda, I think the EDID quirks with KMS are in kernel.
chithead: apparently not, at least not for my display
chithead: the quirk was added to xorg following freedesktop bug 10304 and bug 12784
chithead: also in Xorg.0.log I see an EDID quirk message only if kms is disabled
bridgman: nanonyme, where are you getting 211k lines ?
bridgman: the initial push was 21k lines and a lot of that was register header files
nanonyme: Hrm.
nanonyme: Maybe it was a tenfold error on my part? Re-checking.
nanonyme: wc -l git/mesa/src/mesa/drivers/dri/r600/* -> 211391 total
bridgman: get a character count; I think there's only 500-600k bytes
bridgman: the biggest code file is the shader assembler and that's only 4k lines
nanonyme: wc -c git/mesa/src/mesa/drivers/dri/r600/* -> 20656374 total
bridgman: wierd; which branch are you looking at ? I'm in r6xx-r7xx-support
nanonyme: Yes.
nanonyme: I'm in the same.
bridgman: can you pastebin a directory listing or something ? you must have wedding pictures in there
bridgman: here's the listing in cgit...
spstarr: hello bridgman
bridgman: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r600?h=r6xx-r7xx-support
bridgman: hi spstarr
bridgman: agp still working ?
spstarr: yep on both newttm and oldttm
bridgman: cool; sounds like the guys are solving some long-standing mysteries
spstarr: bridgman: I have a feeling alot of the AGP quirks in drm should be removed
spstarr: or disabled for now
spstarr: at least, the IBM T42 quirks should be removed
spstarr: since we know this is false
bridgman: yeah, those things are always tricky; they get added over the years for individual machines, and if you take them out there's a chance of breaking those individual machines again
bridgman: but of course you can't find the owner of the machine who had the problem in the first place
bridgman: uh-oh, I think nanonyme is hand-counting the lines in the 6xx-7xx 3d driver ;)
bridgman: fourty three, fourty four...
spstarr: hehe
spstarr: bridgman: well, we should turn them off for the models we do know
bridgman: nanonyme, any chance you have binaries in the directory ?
spstarr: I will ask airlied if he can disable them for the T42 models
bridgman: or at least have some kind of #ifdef _horrible_quirks_
spstarr: they all use the same agp controller
nanonyme: bridgman: Oh, good point.
nanonyme: Lemme see, make clean
nanonyme: 866188 total characters now ^^
nanonyme: And yeah, only 21k lines. You were right. ;)
nanonyme: bridgman: I was kinda already puzzled as to the numbers I was getting being way out of proportion compared to the ones on the forum.
bridgman: yeah, it's always good to check from time to time
bridgman: there's probably <10k of code that isn't either shader assembler or header files
bridgman: some of that will go away with the port to -rewrite
bridgman: and some more will go away with the port to gallium
osiris__: bridgman: could you find out which cards besides RS690 requires 64 bytes texture row alignement?
bridgman: but I'm sure more will get added in along the way too ;)
nanonyme: bridgman: I was mostly trying to get an idea whether r6xx-rewrite would be only time-consuming or shear pain to write. ;)
bridgman: osiris; sure, although note that info on the igp parts is really hard to find
nanonyme: 211k lines would've gone in the category of shear pain. ;)
bridgman: yeah; I think about 50% of the time will end up being spent understanding bufmgr/cs and the new api (which, in turn, kind of requires understanding the current GEM API as well)
bridgman: the rest should be pretty straightforward
bridgman: and I think we're past the "understanding" part now, after a couple of false starts
mcgreg: oh .. what I wanted to say ... thx for supporting even the very current ati-radeon-cards :) it#s really nice to see my 4670 working quite well with the free drivers :)
bridgman: yeah, it's nice to be "almost caught up"... we just need to get 6xx/7xx 3d a bit further
nanonyme: bridgman: Plus port the EXA for KMS+memory manager. ^^
mcgreg: bridgman: it much nice to see exa and xv working though it's not yet in the stable release :)
mcgreg: *nicer
bridgman: plus *write* the memory manager code for 6xx/7xx, I think
nanonyme: Yeah, that of course first.
nanonyme: Currently EXA works fine without KMS, KMS works fine withut EXA but would be very interesting to get them both work at the same time. ^^
mcgreg: heh
bridgman: yep, although if A works without B, B works without A, and A+B work together on the previous generation of GPU I wouldn't worry too much about getting A and B working together on the newer GPUs ;)
nanonyme: Yeah.
bridgman: ahh... Astronomy Domine, perfect saturday morning music
nanonyme: I'm not worrying per se, I'm perfectly confident it gets done eventually. ;)
nanonyme: It's just the classic problem that it's impossible for someone to know how hard something is without doing it themselves.
bridgman: estimating the work usually isn't too hard (say within +100/-50%... the hard problem in the open source world is usually estimating the amount of time people will be able to spend on the work
bridgman: that's what kills the schedules
nanonyme: Hmm, right.
bridgman: of course estimation relies on either having done something similar in the past you can use as a model, or at least knowing someone who did something similar in the past
nanonyme: Which eg I haven't. ;)
bridgman: yeah, that's why you have to talk to people ;)
bridgman: but the old rules of thumb still work pretty well, eg 10 lines of designed, documented, tested working code per person per day
bridgman: everyone thinks they can write a thousand lines a day, but then they spend 3 months fixing it ;)
nanonyme: Depends on how much code duplication there is though?
nanonyme: (Though yeah, with good design there probably shouldn't be much)
bridgman: yep, although the time savings for modifying existing code vs writing new isn't that much, you probably still end up spending 50% of the time
nanonyme: And not like one of my UI's in a school programming project where I ended up writing about a thousand lines in two or so hours (read: the whole UI) out of which 50% was probably me copying code from one place in the UI to another.
osiris__: when I saw those SETfield, CLEARbit and similar macros I just fell in love in the code :)
nanonyme: (It was a horrible contraption, I was somewhat shocked I got it to work)
bridgman: yeah, copying unchanged *does* save you a lot of time, as long as you already understand the code
nanonyme: Note though that I had already spent weeks writing the stuff that worked behind the UI.
bridgman: it also helps if you have some flexibility in requirements, ie "I don't know exactly what the code I copied does, but it still does it so I guess that's OK"
bridgman: yeah, the rules of thumb only work on large chunks of code; sometimes you really *can* write a thousand lines a day if it's sufficiently simple code
bridgman: and other times you spend a week and change one line
osiris__: bridgman: are you going to release some programming guide for r600/r700?
bridgman: we weren't planning to (since we already had working code) but Alex put one together a couple of months ago
bridgman: we've gone through about 5 cleanup passes and I think it's getting pretty close
yangman: the working code is still pretty hard to understand :\
bridgman: I have a printout here (waves stack of papers) that's on my review list for the weekend
yangman: as a whole, anyway
bridgman: so is the programming guide ;)
bridgman: but it helps
bridgman: hmm... might have been 4 months ;)
yangman: sounds about right ;)
osiris__: bridgman: cool, I hope to start developing on r600 in about 3 months. there are still some features/bugs that I'd really like to implement/fix on r300-r500 hw and there is radeon gallium driver of course that I would want to hack at least a little
bridgman: anyways, I think we're down to little stuff, and the last revision might have closed all the issues
spstarr: :-)
bridgman: I'll need to check with some folks on Monday to be sure, but fingers crossed
spstarr: bridgman: im so glad we don't need any quirks now or having to bug other AMD people to find out
nanonyme: Imo the neatest thing about current speed of progress would be that the radeon drivers might eventually reach a point at which the necessity of work force would decrease dramatically. ;) (Yeah, I keep on dreaming)
nanonyme: But shouldn't that happen if drivers for a particular chipset become feature-complete so to say?
nanonyme: In an ideal situation "legacy" chipsets would only need housekeeping but nothing more.
osiris__: nanonyme: I don't think we will ever rich the feature-complete state (at least on r300-r500 hw)
bridgman: the work required for current level of functionality will go down but the requested level of functionality will keep going up, so it probably won't end
nanonyme: bridgman: But surely you reach hardware limitations at some point?
nanonyme: Like what happened for r100 and r200: no Gallium due to hardware limitations.
AStorm: hehehe :)
bridgman: we have hundreds of devs and we haven't hit the hardware limitations yet
AStorm: how's that going anyway?
bridgman: which ?
AStorm: r6xx 3D
AStorm: (I want at least simple 2D surface w/ scaling for dosbox, hehehe)
bridgman: pretty well, although the porting to bufmgr/cs for radeon-rewrite compatibility has been a bit rocky
bridgman: learning curve plus no docco = pain ;)
nanonyme: bridgman: Should I assume the devs are doing it in huge segments since there haven't been any commits in r6xx-rewrite for a while? :)
bridgman: if that makes you happy ;)
nanonyme: Hehe.
bridgman: it's being done in chunks, but we had to toss a chunk last week
bridgman: it's only been 10 days since the last commit, right ?
bridgman: we're not talking 5 years here
nanonyme: Yeah, sure. It's not like it's dead or anything.
nanonyme: It's just, like you said, that a developer might be able to produce 10 lines a day so depends wholly on the chunk size how frequent commits are.
nanonyme: (And yeah, of course also on whether they get tossed :3)
nanonyme: bridgman: Surely if developers were doing several hundred line chunks, we wouldn't probably see any activity in months. :)
bridgman: it depends a lot on exactly what you are doing; we're porting big chunks of upper level code to a new drm api and changing some mid-level code, so writing a hundred lines might let you bring 5000 lines of upper level code across
bridgman: I think we'll see commits next week
rnoland: is still waiting on r6xx commits...
bridgman: rnoland; it's not next week yet ;)
rnoland: hehe...
nanonyme: Well, next week isn't long to wait for. ;)
rnoland: well i was looking at fixing the memory management issues... but there was no point if it was a dead end...
bridgman: on 3d ? probably dead end but not 100% sure
rnoland: yeah, i think it is all being re-written or at least changed a lot for r6xx-rewrite.
bridgman: if it rains I'll go through the code and try to get sure ;)
rnoland: alex said richard was porting it all to cs ioctls.
bridgman: yep, my assumption is that most of the r700* files will be only lightly changed and the 600* files will be heavily changed or replaced
rnoland: i have to re-port the drm code...
rnoland: i fried the disk that i did the work on week before last...
bridgman: I've fried enough disks over the years that I'm pretty obsessive about pushing wip code
rnoland: but it looked like it needed a fair amount of cleaning up once things begin to stabilize...
rnoland: it will only take me an hour or so to fix it back up...
bridgman: oh good
rnoland: i had all of my other work pushed offsite...
rnoland: at least everything i've needed so far...
rnoland: saphire card was exhausting into my drive cage...
rnoland: could have fried an egg on that drive...
bridgman: ah yes, like those low-budget woodstove installs where the chimney vents into the attic
rnoland: yep
nanonyme: bridgman: Had any May Day celebrations there?
spstarr: not here :)
nanonyme: Here everyone seemed to have forgotten it turned the first of May at all and just went to watch ice hockey championship matches. ;)
yangman: yeah, we don't do May Day up here
stikonas: MostAwesomeDude: r300-gallium shouldn't work at all with newttm kms (drm-radeon-next)?
stikonas: I only get: do_ioctls: Failed to get GB pipe count, error number -22
osiris__: stikonas: nope it shouldn't. newttm uses new ioctls which aren't implemented in r300 gallium yet
agd5f: oyvind: you need xorg macros package, xorg-utils depending on distro
agd5f: osiris__: rs600 and rs690 shoudl require 64 byte alignment
agd5f: I think rs4xx as well probably, but I 'll try and double check
agd5f: adamk: I wonder if the kms code disables spread spectrum, that may account for the waves
agd5f: if it doesn;t
davi: What is the repository to get builds .debs of recent drivers?
davi: for Debian lenny
adamk: Hmm... That's an interesting thought.
agd5f: osiris__: feel free to close bugs with no feedback for a few months. good idea
adamk: I've been at a first communion and party for my niece so I haven't had a chance to play with avitool at all yet. I may give it a shot in a little bit.
osiris__: agd5f: what about rs740 and rs400?
bridgman: nanonyme; no, after the Easter Fire that was about it, our next big holiday is the May Two Four weekend
agd5f: osiris__: yes rs740 should almost always be treated like rs690
agd5f: it's basically a tweaked rs690
agd5f: rs400/rs480, I'm not sure about, but IIRC, smal textures were broken on them as well
agd5f: I'll see if I can find out more
davi: Have some of you debs of the last radeon driver?
dileX: davi:
davi: thanks
pecisk: hi people, should Radeon Mobility X1600 with TV out as S-composite work automatically or I need thinker with xorg.conf to manage that?
pecisk: I try randr based gnome gui to autodetect it, some flickering goes on when I do it
pecisk: but no detection
osiris__: agd5f: what resolution should I give to bugs lacking of user input?
pecisk: hi people, how can I see which cards has TV output enabled in radeon/ati xorg driver?
pecisk: have to check out code? :)
emvivre: xrandr i think
pecisk: how?
emvivre: just, launch xrandr, and see output
mvirkkil: well, at least with the radeonhd it detects my tv-out correctly, but I still can't use it
pecisk: emvivre: ok, you propably didn't get me :)) I meant is there a list of cards which has TV output enabled at driver level
pecisk: because wiki says it is enabled for selected cards
pecisk: obviously not for all
pecisk: xrandr doesn't show TV-out
pecisk: but my laptop clearly has one
emvivre: oups, sorry
pecisk: np :)
emvivre: my glxinfo says that : libGL error: dlopen /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: undefined symbol: _glapi_tls_Context) and seg fault, can you help me ?
pecisk: emvivre: version of distro/Xorg?
mvirkkil: usually means mismatch between compiled program and installed mesa
mvirkkil: emvivre: --^
mvirkkil: ugh, I might be confused here, but that looks more like mismatched mesa<->dri
emvivre: I m on gentoo, my xorg is xorg-server-1.5.3-r5, with mesa-7.4.1-r1
emvivre: re
adamk: Odd.. Now that I've switched to the x1900 to test for that waviness, my LCD monitor doesn't display *anything* at 1280x1024@60
adamk: Whether in Xorg or just booting up with KMS enabled.
adamk: If I switch to 1024x768, I get this: http://www.npark.com/MOV00191.MPG
adamk: Let me test with KMS disabled.
adamk: With KMS disabled, I get the same nothingness at 1280x1024, but I can at least use 1024x768 without the static.
adamk: Let's see what happens when I switch outputs.
adamk: The monitor had been on DVI-0
adamk: It's now on DVI-1... But the results are the same.
adamk: Nothingness at 1280x1024... Static at 1024x768, plus the monitor keeps flashing...
adamk: It wasn't flashing on DVI-0, so this is even worse.
adamk: Now to try it on DVI-1 with KMS disabled.
nanonyme: Which X server version, btw?
adamk: 1.6.1... Fedora rawhide at the moment.
nanonyme: Ah, right.
nanonyme: Just wondered since you mentioned the different behaviour on different ports.
nanonyme: Sounded like 1.6.0.
adamk: With KMS disbled, the monitor shows nothing at 1280x1024, but is perfectly fine at 1024x768 again.
adamk: So nearly the same results between the ports, but with the monitor blanking regularly on DVI-1.
adamk: I may have to switch back to my x850.
adamk: Hmmm... There are a few updates... Ahhh, but none related to the kernel or Xorg.
nanonyme: Well, they should really be behaving identically unless there's a bug in that area too. :/
rothwell-alt: hi. i've just tried xorg with the radeon driver on freebsd 7.2 and seem to be getting a poor frame frate. glxinfo claims direct rendering is enabled but also lists the renderer as "Mesa software rasterizer"
rothwell-alt: the card is a radeon x1950
rothwell-alt: Xorg.0.log: http://paste.lisp.org/display/79565
rothwell-alt: wondering if there's anything blatantly obvious that i've done wrong... it was pretty much "X -configure && Xorg -config xorg.conf.new"
rothwell-alt: 'lo robert
rothwell-alt: we spoke briefly on one of the freebsd lists ("diagnosing DRI freeze")
rothwell-alt: turned out to be entirely my problem!
adamk: rothwell-alt, pastebin the output of 'LIBGL_DEBUG=verbose glxinfo' please.
adamk: Your X server is enabling direct rendering, which means there is something wrong with the Mesa driver.
rothwell-alt: one sec...
rothwell-alt: ah, may be a permissions problem
adamk: For some reason, Xorg is also loading the software rasterizer for AIGLX.
rothwell-alt: http://paste.lisp.org/display/79571
rothwell-alt: think i probably need to set permissions in /etc/devfs.conf
chithead: rothwell-alt: is your user member of the video group? (if such exists on bsd)
rothwell-alt: he soon will be
rothwell-alt: (there isn't a video group, but i'll be creating one)
adamk: You will still need a "DRI" section of your xorg.conf file, I think.
adamk: rothwell-alt, I believe /dev/dri/card0 is 660 by default, with 'wheel' being the group.
adamk: rothwell-alt, Is your user in wheel?
rothwell-alt: nope
chithead: check the group of /dev/dri/*
rothwell-alt: yes, definitely a permissions issue
adamk: Yeah, adding yourself to wheel should do it. Or you can create a DRI section in your xorg.conf file to give everyone access to /dev/dri/card0
rnoland: hrm... xv syncing is still not fixed in radeon driver on r6/7xx
rnoland: i thought that it was working...
osiris__: glisse: kms seems to be working fine in general. the only bugs I found is: Xv is broken when not in fullscreen mode, and sometimes it doesn't recover from lockup http://pastebin.com/m441430e2
osiris__: glisse: but I don't think it's a lockup actually. I think the timeout should be set to higher value
rothwell-alt: permissions fixed anyway, thanks for the help
rothwell-alt: i look forward to running glxgears at a million frames a second until i get everything else copied over to the new machine
osiris__: airlied: heh, I don't know how it happend (I'm almost sure it worked someday), but currently r300 doesn't have fallback to software rasterizer if necessary
rnoland: radeon master seems to have that issue with aiglx enabled i just discovered...
rnoland: tried to load r600_dri and couldn't so aborted the server.
airlied: osiris__: wierd, you mean we don't return false from the render somewhere?
airlied: rnoland: it should try and load swrast_dir.so then
rnoland: airlied: right... it isn't...
osiris__: airlied: no, for tcl fallbacks it is ok, because r300_pipeline contains necessary stages, but when e.g. we cannot do smooth lines we do nothing about it (of course it reaches the _tnl_render_stage but we have plugged r300 functions there)
osiris__: airlied: I'm going to implement it
osiris__: airlied: looks like r100 and r200 handles it correctly
airlied: I thought reutrning false from the NonTclRender would fail
airlied: fallback
airlied: returning TRUE even
airlied: hmm we havea check for the CHIPSET_TCL flag in the nontcl render
airlied: which seesm tcl fallbacks won't ever work
osiris__: airlied: we check if the HW supports TCL, if not we go to _tnl_render_stage
osiris__: airlied: so tcl fallbacks should work
osiris__: returning GL_TRUE means go to next stage
spstarr: looks at radeon-rewrite
IFixedMyUbuntu: hi guys... I have a X1950 PRO, what driver should I use?
yangman: IFixedMyUbuntu: radeon or radeonhd are both fine
IFixedMyUbuntu: what has better support for advanced functionality, like 3d Acceleration?
yangman: the same
IFixedMyUbuntu: are they as good as fglrx?
yangman: no
IFixedMyUbuntu: :(
IFixedMyUbuntu: is there ANY way for me to install fglrx in 9.04?
IFixedMyUbuntu: last time I tried my whole system broke... :/
yangman: I'm not familiar with ubuntu
yangman: nor fglrx
IFixedMyUbuntu: hrmm
IFixedMyUbuntu: well do you know what I need to do to set up the open source ATI radeon driver without breaking my system?
yangman: just install whatever's in apt
IFixedMyUbuntu: theres two pkgs... radeon and radeonhd, and I don't know what one won't break my system...
yangman: neither would
airlied: you must be running one already if you intalled
chithead: IFixedMyUbuntu: the fglrx in ubuntu 9.04 does not support r500 class chipsets such as your x1950
IFixedMyUbuntu: lspci says this about my card:
IFixedMyUbuntu: 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon X1950 PRO [1002:7288] (rev 9a)
IFixedMyUbuntu: what should I use then?
airlied: whatever installed by default
IFixedMyUbuntu: how can I check what ATI driver I'm using?
chithead: normally the 3d acceleration works out of the box for your card. check /var/log/Xorg.0.log
IFixedMyUbuntu: chithead: sadly, video flickers when I play it, and I experience poor performance in 3D FullScreen games that does not occur in windows, as well as sub-par OpenGL support...
chithead: IFixedMyUbuntu: sometimes it helps to turn off desktop effects
chithead: also the performance with open source drivers is worse than fglrx for many 3d apps, this won't change for another ubuntu release or two
IFixedMyUbuntu: is there a way to quickly enable / disable desktop effects in terminal?
chithead: in kde it's alt+shift+f12, not sure about your desktop environment
IFixedMyUbuntu: I'm on GNOME.
IFixedMyUbuntu: Version 2.26.1
IFixedMyUbuntu: I THINK the effects are from Compiz.
adamk: You can just run 'metacity --replace &' in a terminal.
adamk: Assuming you were/are using compiz.'
IFixedMyUbuntu: what does that do?
adamk: It starts up metacity.
adamk: Which is the normal gnome window manager.
IFixedMyUbuntu: and how do I switch from Metacity back to Compiz using Terminal?
chithead: compiz --replace &
IFixedMyUbuntu: I wanted to make a script that would automatically turn off effects, run a game or whatever, and then turn them back on when done...
IFixedMyUbuntu: hmm compiz --replace & doesn't seem to terminate when it's done though, the process stays active.
chithead: IFixedMyUbuntu: it will terminate when you run metacity --replace &
IFixedMyUbuntu: ah ok, that works.
IFixedMyUbuntu: Hmm... I can't get certain things such as the Dolphin Gamecube Emulator to work now that I have the open source drivers, but it worked fine with proprietary ATI drivers... could you guys help me fix this? the error message that I get is: 06:49:930 W: COMMON IsDirectory: stat failed on ./USER/WII/TITLE/00000001/00000002/CONTENT:
IFixedMyUbuntu: 06:51:893 N: Video glX-Version 1.2
IFixedMyUbuntu: 06:51:923 N: BOOT Booting /media/sda1/dolphin-games/ssbm.gcm
IFixedMyUbuntu: 06:51:961 N: OSREPORT (PC=81200304) OSReport: Apploader Initialized. $Revision: 26 $.
IFixedMyUbuntu: 06:51:961 N: OSREPORT (PC=81200320) OSReport: This Apploader built Sep 8 2001 02:11:26
IFixedMyUbuntu: 06:52:239 N: Video GLWin Depth 24
IFixedMyUbuntu: 06:52:239 N: Video detected direct rendering
IFixedMyUbuntu: Can't create opengl renderer. You might be missing some required opengl extensions, check the logs for more info
IFixedMyUbuntu: 06:52:383 N: BOOT Saving Settings to ./User/Config/Dolphin.ini
IFixedMyUbuntu: how do I get opengl extensions?
IFixedMyUbuntu: Segmentation fault
IFixedMyUbuntu: or whatever...?
adamk: You don't. You'll probably have to wait for the mesa driver to implement those extensions.
adamk: Work is being done to improve the situation, but it may be a while.
IFixedMyUbuntu: What is the 'mesa' driver?
adamk: The open source driver that you are using.
IFixedMyUbuntu: i thought is was called radeonhd...
adamk: radeonhd and radeon are both 2D drivers. 3D acceleration is provided by Mesa.
IFixedMyUbuntu: ah...
IFixedMyUbuntu: is there a way for me to try like an alpha version of mesa using SVN or something so I can see if OpenGL works? :/
IFixedMyUbuntu: I'd really like to be able to use all the games, etc. that worked perfectly in fglrx
otaylor: IFixedMyUbuntu: you have to realize that fglrx and mesa/open source drivers have quite different strengths
IFixedMyUbuntu: "strengths"> I haven't noticed a single advantage of MESA other than open source...
chithead: IFixedMyUbuntu: you can try the dri2/ttm/kms stuff which should fix the flickering video. but it is still a bit experimental and won't help with 3d games
otaylor: the open source drivers are going to be more robust and handle desktop integration better, but they aren't going to handle all the obscure corners of GL as well, and aren't going to be as fast as fglrx, which is just a straight port of the windows drivers (and correspondingly tends to be rather buggy in Linux)
airlied: IFixedMyUbuntu: well fglrx not supporting your hw is clearly a disadvantage
adamk: lol
IFixedMyUbuntu: whats the website for mesa development? I'd like to find out more about these drivers... maybe check development progress.
chithead: http://wiki.x.org/wiki/RadeonFeature summarizes the current state of open source radeon support
IFixedMyUbuntu: how do I figure out the R number for my card?
adamk: lspci | grep -i vga
adamk: It's an r500 family GPU.
IFixedMyUbuntu: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon X1950 PRO (rev 9a)
IFixedMyUbuntu: where does it say?
IFixedMyUbuntu: just says rev 9a...
IFixedMyUbuntu: :/
adamk: Hmm... Odd.
adamk: In any case, it's still an r500 family GPU :-)
IFixedMyUbuntu: I think my card is manufactured by Sapphire Technologies. When I bought it, it was THE best ATI card that Sapphire sold... now it's one of the worst, and barely supported :(
adamk: Not to be rude, but complaining about it here is not going to change anything.
IFixedMyUbuntu: Is there any support for DirectX in mesa?
chithead: IFixedMyUbuntu: it is going to take a few months until the code is in place which allows faster operation on your graphics card. directx is translated (sort of) to opengl via wine
IFixedMyUbuntu: wishes he could help develop the code, but he knows nothing about how the ATI cards work or how to develop drivers
IFixedMyUbuntu: Thanks for taking the time to answer my questions, I really appreciate it. :)
IFixedMyUbuntu: Do you know if I can usse the S-Video out on my card with mesa or not?
IFixedMyUbuntu: What about dual monitor support?
chithead: mesa is only about 3d. managing of outputs is done using radeon/radeonhd
chithead: and see the wiki page for the status of tvout
IFixedMyUbuntu: how do I manage my card? Is there a GUI like Catalyst Control Center available?
chithead: most desktop environments now include a xrandr gui
IFixedMyUbuntu: how do I get to that?
chithead: in kde there is krandrtray, certainly there is a gnome equivalent
IFixedMyUbuntu: what would it be called?
airlied: prefernces->display?
airlied: or somewherelike thatr
IFixedMyUbuntu: that just lets me change screen resolution...
IFixedMyUbuntu: and refresh rate
chithead: IFixedMyUbuntu: there ought to be some "detect monitors" button, press that after attaching the second display
dileX: IFixedMyUbuntu:
spstarr: airlied: ping
spstarr: airlied: think we can turn off the T42 quirks ?
spstarr: we clearly dont have to use those
osiris__: airlied: I think there's a problem with fbo extension
osiris__: airlied: there's a comment in radeonInitScreen that extensions need to be initialized there before the context is created
osiris__: airlied: but fbo extension isn't initialized there
osiris__: airlied: ah, sorry. it is, I'm too tired. I think I should get some sleep (nearly 4 am here)
spstarr: glisse: building newttm, will test AGP s/r
spstarr: it's onto newttm once F11 is released, airlied's work is done for agp, its good enough for users
spstarr: glisse: cannot Suspend/resume with AGP
spstarr: same problem
spstarr: take airlied's suspend/resume code? :)