hifi: oh no"
hifi: he pasted it to a private chat
hifi: well ok, I saw it coming, should've been more specific
Kaneda: ok understand i dont do this in irc very much
Kaneda: if at all
hifi: first, the log you pasted was not complete
Kaneda: i understand that
hifi: http://pastebin.com/ and second, we meant that
hifi: paste the whole log there and submit the form, then paste the link generated here
Kaneda: like i said i dont ask for help in irc
Kaneda: i usually get my info from forums but they are limited
hifi: thats ok, now you know
hifi: people generally paste things that are more than just a few lines to sites like pastebin
hifi: (II) RADEON(0): Skipping TV-Out
hifi: well, that kind of explains everything
hifi: so airlied was probably right, it isn't enabled for R400
Kaneda: so all i have to do is enable it
Kaneda: with thisin xorg right
Kaneda: Driver "radeon"
Kaneda: Option "TVDACLoadDetect" "TRUE"
Kaneda: Option "TVStandard" "ntsc"
Kaneda: Option "monitor-S-video" "TV-monitor"
hifi: I think it's more like in the driver itself
hifi: you can try Option "ForceTVOut" "true"
hifi: but I doubt it has any effect
hifi: thats probably just for forcing the output on without checking if a cable is connected
Kaneda: so your implying that i should look for an older driver and try to install it which is a pain
Kaneda: if not impossible
hifi: umm, no
Kaneda: well it doesnt hurt to try the xorg edit
hifi: I mean it's not *done* in the driver
hifi: though I might be wrong, just guessing
Kaneda: could i try editing xorg.conf to see if it does work
Kaneda: i can always go back and erase it
hifi: the configuration is mostly empty
hifi: you can add the options to the section named "Configured Video Device"
Kaneda: this is the page im looking at if you didnt know
Kaneda: should i add all that stuff under tvout static
Kaneda: hifi, is that page valid and should i add all the stuff under tvout static
hifi: I don't know
hifi: when I had S-video it magically just worked with the Radeon 9200 using xrandr
Kaneda: i had it working on 9800 sapphire as well
Kaneda: but that was before the open source ati drivers
Kaneda: and i was using the dreaded windows
hifi: it probably works with 9800 if you try it out
Kaneda: im glad i awoke from that nightmare
Kaneda: i dont have that card anymore unfortunately
Kaneda: ok so i added all that stuff on that page lets see if it works
Kaneda: if not then i shouldnt be any worse off than i am now
Kaneda: well it botted just fine
Kaneda: and yes i made a backup of the original
Kaneda: ok that didnt do anything
hifi: kind of expected
Kaneda: ehh didnt hurt
Kaneda: wait maybe it did
Kaneda: it worked
hifi: it did?
Kaneda: ok i rebooted my system
Kaneda: and i saw everything to the ubuntu splash screen then it went blank
Kaneda: i saw ubuntu loading then it went out
hifi: thats when the X server starts
hifi: and radeon driver kicks in
Kaneda: so im still back to where i started
Kaneda: which section were you looking at on the log
Kaneda: i wanna see if it changed any when i edited xorg
Kaneda: or would it change the log at all
Kaneda: hifi, you still there
hifi: uh, yeah
hifi: Kaneda: it's still skipping tv-out
hifi: best to wait for airlied to get back
Kaneda: well hell
Kaneda: i wonder if i have to run xrandr commands when x-serv isdown
Kaneda: how do i halt x serv
stikonas: airlied: latest r300 driver segfaults with progs/sample/olympic, yesterday it worked fine
Vash63: Ok, last time I tried the git release it made X crash hard whenever I started it, are there any new dependencies to the git versionr ight now that weren't in 6.12.2?
Vash63: I'm about to try it again because I want my power management working. It's been a few days.
Vash63: Yep, still kills Xorg.
Vash63: ssh'd in and the system was ok but I couldn't figure out how to get Xorg back up... could kill the process but not start it back up again without a reboot.
Vash63: It was stuck at 100% CPU usage.
Vash63: Until I killed X.
Vash63: hald was using 100% at times too for some reason.
Vash63: This is on an R700.
Netzpython: Vash63: xorg from git?
Vash63: Nah, stable Xorg.
Vash63: xorg-server 188.8.131.521
Netzpython: hehe, thats far away from stable...
Vash63: Oh? It's a full release isn't it?
Vash63: checks site
Netzpython: just a freeze og git master 8 weeks ago
Vash63: Should I downgrade it?
Netzpython: its worth a try
Netzpython: i cant recommend upgrading to git-master ^^
Netzpython: except for the radeon driver itsself
Vash63: 1.6.0 isn't in the Gentoo tree.
Vash63: It jumps from 1.5.3 to 1.6.1
Netzpython: try to merge 1.5
Vash63: Would EXA still work through DRI1?
Vash63: On an R700?
yangman: Vash63: EXA on r7xx doesn't go through DRI
airlied: Kaneda: sounds like we don't have tv-out on r400, need to ask Alex exactly why I always forget
Vash63: Ok, time to downgrade... hope it works.
Kaneda: im using r480
airlied: Kaneda: yup same thing
Kaneda: is there a way to change the setting or another alternative next to getting a new card
airlied: Kaneda: actually try adding Option "ATOMTVOut" "true"
airlied: I forget r480s have atom
Kaneda: in xorg
Kaneda: well i was using http://www.x.org/wiki/radeonTV
Kaneda: and edited my own from it
airlied: yah it only says that option for R600s
Kaneda: let me know where to put
airlied: but it is needed on r480s
stikonas: airlied: have you seen regression in r300 with progs/samples/olympic ?
airlied: just add it to the device section
airlied: stikonas: nope I'm not near r300, I'll look on Monday
airlied: must have been one of those r200 fixing commits (
stikonas: ok, and not only olympic, but many other programs segfault
airlied: oh have you got a backtace from gdb?
stikonas: not yet
Kaneda: did i do it right
airlied: yup looks okay
Kaneda: cool ill try it
Kaneda: ok rebooting
Kaneda: lets see if it works
Kaneda: i know it has to be xorg and the ati driver cause i get display all the way up to xorg loads
airlied: Kaneda: yeah tv-out without the X driver is done by the bios
stikonas: airlied, sorry after full mesa recompilation, all segfaults are gone, everything works
airlied: stikonas: I love mesa, make clean is always useful :)
Kaneda: ok it has 2 monitors now
Kaneda: one unknown
Kaneda: and then when i turn it on it says something about resolution needing to be set
Kaneda: but i thought it was in xorg
airlied: can you pastebin the /var/log/Xorg.0.log
airlied: Kaneda: so it claims to see s-video now
Kaneda: yeah claims to im checking out right now
Kaneda: i was doing most of my stuff remotely but just now had to drag out another kb and mouse
airlied: the only other option I know is Option "R4xxATOM" "true" if it isn't working now
Kaneda: ok i clicked the other monitor and turned it on
Kaneda: and then it pops up
Kaneda: monitor resolution settings has detected that the virtual resolution must be set in your config file in order to apply settings. would you like the screen resolution to set the virtual resolutionfor you?
airlied: it should have been on already
Kaneda: so try yes?
Kaneda: it says recommended
airlied: shouldn't harm but I'd expect when X started something on the tv
Kaneda: well it said log out and log back in and i did and nothing stuck
Kaneda: all went back to previous settings
Kaneda: did i have something wrong in my config file
airlied: Kaneda: as I said I've never know if anyone has gotten tv-out to work
airlied: on the r400s
Kaneda: well hmmm
Kaneda: i understand
airlied: thats why I'd probably try the last option above,
airlied: it should light up at 800x600 in clone mode with the vga
Kaneda: this Option "R4xxATOM" "true"
Kaneda: should i put it in place of atomtv out or in addition too
airlied: in addition
Kaneda: it still detects it just doesnt allow for cloning
Kaneda: who ever coded my bios did it right thats all i can say
Kaneda: airlied, are there any other options someone else might know or are we tapped out\
Vash63: Yay, still crashes.
Vash63: I guess the git driver just hates my system or something.
mikkoc: airlied: the blank console problem with kms is gone with latest git snapshot of the kernel :)
Zajec: hm, Linus included patches?
mikkoc: but now i have another problem: i cant seem to get dri working in X, although i think i got all i need
mikkoc: [dri] radeon.o kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
mikkoc: Zajec: i guess
mikkoc: xorg log: http://zlin.dk/p/?MjFkNjZi
Zajec: oh, ok: 33 hours ago Linus Torvalds Merge branch 'drm-fixes' of git://git./linux/kernel ...
Vash63: That's my Xorg.0.log from the crash. It works fine with the currently released version, that's the git version. I tried it 3 days ago or so with the same issue.
Vash63: Tried with xorg-server 1.6.1 and 1.5.3 now.
mikkoc: what branch of xf86-video-ati do i need to work with kms?
Kaneda: well looks like i might be reverting back to intrepid
Kaneda: airlied, would i have this problem with intrepid or should i go earlier
Kaneda: airlied, im out i have one other option im going to try ill be back later to let you know how it went
aberres: i was to fast with my report, that the external monitor via hdmi works now. today the content on the external screen is scrambled again and after a short while the monitor switches itself off
aberres: what the monitor itself shows seems to be ok, but everything is overlayed with flickering colors
aberres: if anyone ever hass seen this, or has any clue how to fix it: tell me :)
[DarkSun]: sorry, i got cutoff, im not trying to spam, not sure if this posted before my disconnect
[DarkSun]: im having some issues with compiz on my rv250, im not sure if its a driver issue or a compiz problem, im having an issue with 1400x1050 resolution on my ati rv250 (mobility 9000) card, i know what the problem is, i just dont know how to fix it. on ubuntu glxinfo -l reports "GL_MAX_TEXTURE_SIZE = 1024" on knoppix live cd it reports 2048 and everything works fine at the higher res. both seem to use the same driver version.
nanonyme: darksun_: Same Mesa driver version, that is?
darksun_: same radeon and mesa driver, all version #'s in the log file seemed to be the same
darksun_: please forgive me if i get cutoff randomly, they are working on the phonelines and the dsl is up/down
amarsh04: I know the feeling, darksun_
darksun_: amarsh: yes, were on day 6 right now, goooo verizon!
darksun_: any ideas on that issue?
mikkoc: is anyone using kms?
AndrewR: mikkoc, i'm using it
mikkoc: AndrewR: what branch of xf86-video-ati do you use?
AndrewR: mikkoc, * kms-support
mikkoc: right, and libdrm?
AndrewR: mikkoc, master
mikkoc: hm me too.. but i dont understand why i keep getting [dri] radeon.o kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
mikkoc: i suppose you dont get it?
AndrewR: hm, may be some stale headers somewhere?
AndrewR: i usually compile everything with --prefix=/usr/X11R7
mikkoc: i use gentoo ebuilds, which should take care of everything :(
AndrewR: and run autogen && autoreconf before ./configure. but it should work with any other locations ....(slackware here)
mikkoc: what xorg version do you have?
AndrewR: i once compiled X server on gentoo, on mips r5k (and it was working enough for testing)
AndrewR: git master, few commits behind current head. one moment
mikkoc: hm, do you know if xorg master is needed for kms?
AndrewR: commit 84662e40c3d4141ebb298a1ad714f75056a4ab74 ( Xi: check for GetAttr permission when listing or querying devices.)
AndrewR: I hope not, but i want to use git server anyway.
mikkoc: using 184.108.40.2061 here
amarsh04: only has ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) and runs Debian unstable... building from source is a bit hairy unless you don't mind having your distro's configuration overwritten
nanonyme: Well, unstable version isn't for production use anyway so it doesn't matter that much, right? ;)
skodde: unstable is just fine for a stable desktop
darksun_: arm: what res do you run, and do you use compiz?
skodde: AndrewR: a mips r5k? was it a sgi o2? :-)
AndrewR: skodde, yes
skodde: AndrewR: nice toy, i had one of them
AndrewR: skodde, gentoo on this machine can trigger NFS bugs really easy in new kernels .... so, myself mostly using this sgi for testing my host kernel (for nfsd/xfs bugs).
AndrewR: emerge-webrsync - and after 12hrs all kernels after 2.6.27 (.29, .30, .31) dies here ...
AndrewR: skodde, i want to compile-test (at least, i don't have pci radeon) kms for this SGI machine .. but .. with such instability .. (i use NFS-root, hdd still occupated by irix)
skodde: AndrewR: it would not be very useful anyway, i guess :-)
AndrewR: skodde, at least on such low-end machine all bloat is very visible ..say, audacious ...uses all cpu. mplayer uses barely 20% (probably, FFT display eats a lot ...)
AndrewR: skodde, probably, at the later time, it can be theoretically used as lowest-possible platform for testing ...
skodde: AndrewR: but you have to consider that it's a totally different (and no more used) architecture, many bugs can depend only on this and the resources consumption cannot be very indicative, probably on a more common arch the same software have different and more useful optimizations, and so on..
AndrewR: skodde, i really interested in early graphics systems, at the time when fast CPU was about 10 MIPS (millon inst. /s) and guys tried to write fast software X for it ... it was interesting.
AndrewR: skodde, of cource (for example, any modern x86 has sse and co)... but it nice to see lowest possible end still working with free software
AndrewR: *of course
skodde: AndrewR: that for sure, as i said it's a nice toy and it's still somehow supported :-) but to use it as a testing/debugging machine.. mmh..
skodde: i don't wanna even know how much time will it take to compile the x server on it :-)
AndrewR: skodde, for just X server - few hours. Mplayer takes 3 (three)
AndrewR: skodde, gcc/glibc combo - all day
AndrewR: (but it was with correct NFS host)
AndrewR: skodde, really not good for git bisect :)
skodde: AndrewR: eheh
amarsh04: I used to use some Indigo machines at work, along with some sparcstation 10's - I remember compiling gcc 3.3 for the ss10 using gcc 3.2 from sunfreeware.com
amarsh04: we even had one of the 2 cpu winnt sgi machines
amarsh04: I'd agree on making the most efficient use of lower power cpu/gpu combinations
amarsh04: I've done kernel git bisect on a PII-266 with 384 MiB RAM... took the best part of a week then someone on linux-scsi took 10.5 hours from me posting the bug to me receiving a working patch
skodde: let's try kms again..
daum: can anyone help me setting up a radeon pci-e x1 1550 card?
otaylor: daum: you'll have to be more specific - on the hardware level, you just plug it in
skodde: still nothing, this is the kernel log http://pastebin.com/m36dc0b3f , the strange thing is the drm version indicated, i'm using .31rc1-git3 and drm/mesa master.. is it normal?
daum: otaylor, ha, sorry, so its in, i'm trying to setup a dual montior setup, just need some help doing that
otaylor: daum: with what software? (what linux distribution and version, say)
daum: on gentoo, 2.6.29-r5
otaylor: sorry, can't really help with gentoo. If you have any sotr of reasonably recent X server, you can just use the 'xrandr' command line tool or the graphical tool provided by your distribution
otaylor: 'xrandr --auto' may be good enough
daum: otaylor, i get Can't open display
otaylor: daum: inside X
daum: otaylor, hm so the xrandr --auto just did duplicates on both screens
otaylor: daum: xrandr has more options - you can find info around if you search for it on the web
otaylor: something like 'xrandr --output DVI-1 --right-of DVI-0' is probably what you want (excpet that that's from memory so almost certainly wrong in detail)
daum: thanks, will look into it
nanonyme: hopes the GUI frontends some day get good enough that xrandr won't really be necessary anymore ^^
Zajec: what's wron with current GUIs?
nanonyme: Zajec: They obviously can't be good if people still need to ask for command line switches? ;)
Zajec: maybe ppl don't even try them
nanonyme: I know a few situations where command line will stay the better option but in most desktop functionality I think the GUI frontends would be easier.
daum: Zajec, hm which gui frontend do you recommend?
nanonyme: Gnome and KDE probably ship with their own tools for it.
daum: i'm in kde
nha: it's not so much that the GUI frontends to xrandr itself are bad, it's more that the desktops aren't well integrated in the face of multiple monitors
nha: e.g. panel positioning is a regular pita
daum: right now i'm trying xrandar --output DVI-1 --mode 1280x1024 --left-of DVI-0 --mode 1280x1024, but it says screen cannot be larger than1 600x1600 (desired size 2304x1024)
daum: rather xrandr
nanonyme: nha: Simple "link monitors" and "drag monitor to the side of the other monitor" would probably be just fine for most users.
Zajec: daum: you need just "Virtual" in xorg.conf for bigger size
nanonyme: Oh, and X server seriously should be made to be capable of changing the virtual line on the fly. :p
nanonyme: Possibly calculating a proper amount by what the monitors need.
mjg59: nanonyme: You can't do that without a proper memory manager
otaylor: nanonyme: it does work with kms (I think, for intel anyways)
nanonyme: That's definitely a good sign. :)
daum: ah hm so i create my xorg.conf (before i guess it was jsut using a default one, however now i get cannot find mode 1280x1024
otaylor: daum: your xorg.conf shyould be almost completely empty
daum: otaylor, oh its huge right now-- what should i have it in it?
otaylor: I think it should be suffiicent to have
otaylor: Section "Screen"
otaylor: SubSection "Display"
otaylor: You might need a bit more than that (Identifier for the Screen section, perhaps)
daum: otaylor, ya right now i get no screens found doing that
daum: alright added the identifier
daum: ah close! is there a way to get it so that the second montior is just the "expanded" montior , ie no menu bar you can just drag windows over to it?
daum: right now it seems kde doesn't really know there are two monitors it just things i have one really big monitor
daum: so full screen windows sprawl across both etc
daum: otaylor, any suggestions on how to fix that?
AndrewR: daum, poke kde developers ... iirc they don't have dual-monitor setups ....
nanonyme: daum: Eh, wasn't the point to get one big monitor? o.O
daum: nanonyme, well i really just want the second montior to be a monitor where i can place a window and have it maximied only to that montior
dli: r5xx card, why does glxgears keep flashing?
dli: I'm running hal without xorg.conf. compiz works
nanonyme: daum: Meh, I've never had two monitors, no idea.
otaylor: daum: sorry, I'm a gnome devel. It's probably in the kde config dialogs somewhere :-)
PuffTheMagic: does anyone know if glisse's repos for xf86-video-ati and libdrm are still needed for kms?
PuffTheMagic: on r500
nha: wrong keyboard :}
nha: PuffTheMagic: for libdrm, use master and --enable-radeon-experimental-api; for xf86-video-ati, you can use the main repository, branch kms-support
PuffTheMagic: ok cool
PuffTheMagic: fixes ebuilds
PuffTheMagic: hmm i already had that
PuffTheMagic: idk i was thinkiing it was glisses still
nanonyme: nha: The time of a zillion branches finally closing its end? :)
PuffTheMagic: :D drm devel has so many damn repos and branches
nanonyme: It has had. :)
PuffTheMagic: seems like ariled still makes a new branch every day
PuffTheMagic: for random fixes and this and that
nanonyme: Well, random experiments belong to branches, true. ;)
nanonyme: But it'd be nice if branching for active development would calm down a bit when KMS+ttm gets done.
Emme_NK: My RS690 is annoying me more an more, so I am looking for a plugin card...
Emme_NK: Some PCIe, GL_MAX_TEXTURE_SIZE greater than 2048, passively cooled, and of course supported by -ati
Emme_NK: what would be recommended?
nha: many branches are not a bad thing, I just wish people would delete their branches more often
nha: having tons of zombie branches lingering around = a bad thing
nanonyme: nha: I heard the freedesktop policy is to never delete.
nha: nanonyme: then maybe they should be moved into a kind of attic instead
nanonyme: One justification for it was iirc that while the sum of the commits in the branch might not be useful to be worth saving, the actual history might be or something along the lines.
nha: oh, I'm all for saving history
nha: I'm just against cluttering the default use case
nha: the default case is people want to look at current developments
nha: ergo the suggestion of moving it into some kind of attic
nanonyme: nha: I'd be fine with a compromise to have a final commit to obsolete branches that this is closed. :)
nanonyme: So people see that they shouldn't be using it.
nha: also note that "preserving history" is not a valid argument for not meddling with branches anyway
nha: I mean, if we are ever going to have a radeon rewrite of a similar scope, we would not be able to reuse the name radeon-rewrite
nha: ... and it looks like somebody broke glReadPixels again :/
nanonyme: nha: One could also argue that radeon-rewrite is not a very descriptive name in the first place. ;)
nha: nanonyme: so what would you have suggested?
nha: ... which is misleading, because radeon-rewrite also included unifying a lot of common code among the different radeon drivers
nha: ... also, dri2
nha: ... also, cs
nanonyme: Hmm, right...
nanonyme: I guess there isn't really one good short name for it.
nanonyme: Guess you could start numerating rewrites? :3
nha: like that's more informative :P
AndrewR: nha, hey, can you look at 0952645fe04a27968565ea4d913500c23b1b11e3 in mesa master? (it was about re-using dma buffers for r200, but it broke some demos, like teapot. I was just thinking .. may be Dave forgot to push some changes, or it was re-using too much from buffer)
nha: AndrewR: you're certain that this patch is the one causing breakage?
nha: two possibilities come to mind: either something's wrong with alignment (maybe we were implicitly getting more than 4-byte alignment before, and now we're only getting 4-byte alignment; I don't see why that could be too little, but who knows)
nha: or somehow the validation of the buffer doesn't check out, though that would be even weirder
nha: so to summarize, just from a quick visual inspection I don't see anything particularly damning
nha: oh wait!
nha: r200FlushElts() calls radeon_bo_unmap
nha: ah no, never mind
nha: AllocEltsOpenEnded does call radeon_bo_map
AndrewR: nha, sorry, i will check in few secs ... (right now fresh mesa without this one commit ready to install)
nha: osiris_: I thought we had occlusion_query? What's the status on that?
nha: also, there appears to be something wrong with the interaction of KIL with the new CS
nha: glisse: do you know what's going on there?
nha: I get a drmRadeonCmdBuffer: -22 on piglit's fp-kil test, for example
amarsh04: hmmm... vt1..vt6 are blank when I do control-alt-f1 .. control-alt-f6 but I can log into them, and control-alt-f7 returns me to the graphical login
osiris_: nha: oq is working at least on my rv515. sw tcl is known to be broken. don't know about other GPUs
osiris_: nha: I think I know why you're getting -22 error - with KIL first texture need to be enabled, and we probably don't set offset there and it trips cs check
skodde: nha: maybe you can help me, i'm trying to get KMS working on a radeon X1650 XT, using a 2.6.31rc1-git3 (so with the last drm-fixes branch merged) and drm, mesa and ati driver from git, i get a broken terminal (it works just for a second, showing the last rows of the drm fail and then it freezes there) and a working xorg without acceleration, here is the kernel log: http://pastebin.com/m36dc0b3f
MostAwesomeDude: osiris_: That could be a Bad Thing in CS when we start to use texture stuffing.
nha: what is texture stuffing?
nha: and this obviously means that the drm must be made aware of the fact that KIL needs to have textures enabled
nha: skodde: hmm, that "ring test failed" looks quite suspicious; unfortunately, I don't know too much about that
nha: osiris_: is the oq code in Mesa master already?
skodde: nha: can i get more useful information somehow?
skodde: (i already enabled the radeon debug output, but that's only for the fb, i guess..)
nha: for KIL vs. drm, maybe we should just register some fake texture instead; ah well
nha: skodde: I don't think so; but you should have output of lspci and the like ready for somebody who knows more about this stuff
nha: after all, the ring test really shouldn't fail at all, it could point to all sorts of strange things happening with your system setup
nha: but at least you have PCIE; I thought PCIE was better about writeback and stuff
skodde: nha: no problem about that, i've also saved the log of a working x session, with acceleration and everything (but without kms, of course)
skodde: nha: i was wondering.. i've enabled the dma remapping support (but also with the graphic workaround) and activated it in the bios (i've 4GB of RAM), could it be relevant?
nha: yes, that sounds like it could be very relevant
skodde: so maybe i can give it a try without it
nha: it's at least worth a shot
skodde: nha: i'll recompile it now :-)
osiris_: nha: no the oq code is sitting in my private repo (fdo/~osiris). I haven't had time recently to finish it
osiris_: MostAwesomeDude: texture stuffing isn't related to this
osiris_: MostAwesomeDude: texture stuffing is about texture coordinates only
skodde: ok, let's try, brb
MostAwesomeDude: osiris_: Oh, CS is checking texcoord routes, not texture enables?
osiris_: MostAwesomeDude: it is checking about texture enables and texture offsets only
MostAwesomeDude: osiris_: Oh, okay.
MostAwesomeDude: I guess that'll work.
skodde: nha: wow, it was it, now it's working fine
skodde: now it would be nice to debug the problem somehow
osiris_: glisse: ping
amarsh04: does anyone know why text consoles are blank but graphical vt7 is ok? RV280, radeon
ssieb: is there any ATI chipset that works really well, with decent 3d performance and no really bad bugs?
MostAwesomeDude: ssieb: R100 :3
ssieb: decent 3d?
MostAwesomeDude: Well, you asked three really vague, relative questions.
MostAwesomeDude: And any Radeon in R100-R500 probably fits.
MostAwesomeDude: Just buy an X1600 or X1900.
ssieb: unfortunately not... my RS690 has really bad bugs. I put an RV370 / X300SE in and it has bad bugs or painful performance...
osiris_: ssieb: what mesa version do you have?
ssieb: amarsh04: I'm assuming you're not using KMS then?
ssieb: latest available in F11, checking
ssieb: mesa 7.5-0.15
ssieb: I don't see the bugs in bugzilla, but I'm getting frustrated with entering so many bugs... :-/
amarsh04: no ssieb
osiris_: ssieb: do you have KMS enabled?
ssieb: osiris_: I tried it both ways
ssieb: I get better performance without KMS, but there are other bugs then
ssieb: like GL windows stay on top of everything
ssieb: and textures flash randomly
MostAwesomeDude: ssieb: GL windows staying on top of everything is *not* a bug.
MostAwesomeDude: It's just an artifact of DRI1.
ssieb: except it says DRI2 in the log
ssieb: and the textures are bad too
osiris_: how bad?
ssieb: hmm, I'll try
osiris_: ssieb: forget it. I know what the problem
ssieb: one other bug I've kept hitting with the card as well was that GL games hang sometimes on exit. I'll try to get a proper backtrace on one of them
osiris_: it is already fixed in mesa git
ssieb: thought he'd seen some mention of that here
ssieb: any idea when that will get into a package?
er0x: any ideas with this? (EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: cannot open shared object file: No such file or directory)
ssieb: does that file exist?
er0x: only for r200 and r300
ssieb: oh, there is no 3d support for r600, so that's probably a normal message
ssieb: is away
AndrewR: nha, http://img218.imageshack.us/img218/1992/teapotrv280dri2bug.jpg (teapot demo with mesa master on rv280/dri2)
AndrewR: nha, in reality, there was red text over 3d image ... not sure why ksnapshot doesn't capture it
MostAwesomeDude: Oh, wow. :C
fcami: ssieb: R400 for instance. X700/X700 Pro if you don't need much speed, otherwise get a X850XL. R500 should work as well but I don't have any. Try a 1650 Pro or XT, or 1900xx. R600/R700 support is coming though, making those cards obsolete.
fcami: *X800XL , not X850XL.
Kaneda: MostAwesomeDude, does the radeon drivers work the same in intrepid and hardy as they do in jaunty with the svid
MostAwesomeDude: Kaneda: Same or worse, since they're older.
skodde: another question: i'm using a 64bit system (debian sid), i've set up a chroot for a 32bit system, inside it i've compiled the same drm and mesa libraries, but glxinfo tells me "OpenGL renderer string: Software Rasterizer" instead of "Mesa DRI R300 (RV560 7291) 20090101 TCL DRI2" as it says in the host, what did i miss?
Kaneda: does the catalyst console help
Kaneda: MostAwesomeDude, does the catalyst console help with my issue or does it have no eefect
amarsh04: found out that vt1...vt6 being invisible was due to an svn version of GRUB I was trying out
MostAwesomeDude: Kaneda: Catalyst/fglrx utilities do not work with the open-source drivers.
Kaneda: ok then
glisse: osiris_: pong
glisse: nha: likely what osiris_ said
glisse: didn't thought to kill when doing the checker
glisse: that's tricky
glisse: osiris_: got to go, if you got anyquestions let me know i might popup latter tonight
osiris_: glisse: I'm getting [drm:r300_cs_track_check] *ERROR* (PW 2) Vertex array 0 need 196593 dwords have 55296 dwords
osiris_: but when I try to trace in userspace such a bug bo I can't find it
nanonyme: skodde: How complete is the chroot? Do you pass /dev (specifically /dev/dri) to it?
skodde: nanonyme: yup, /dev is mounted with -o bind from the host
skodde: nanonyme: and the user has access to the device
nanonyme: Care to pastebin xorg log?
skodde: nanonyme: wait, there is something wrong, i have to cut it
skodde: nanonyme: ok, here it is: http://pastebin.com/m1889fe76
skodde: btw i'm not running a x server inside the chroot, i'm just exporting the display
_Groo_: hi/2 all
_Groo_: airlied: ping?
nanonyme: skodde: I'd seriously recommend against doing that, can cause additional difficulties.
skodde: nanonyme: which one? :-)
nanonyme: Read wrong.
nanonyme: Yeah, running X server inside chroot should work, I think.
nanonyme: Why do you need to export the display though?
skodde: nanonyme: wait, i'm not running a x server inside the chroot
nanonyme: Ah. :)
nanonyme: Then I read right the first time. ;)
skodde: nanonyme: i simply do 'export DISPLAY=:0.0' and then run the program
skodde: nanonyme: so i should run another xorg inside the chroot?
nanonyme: I still fail to see why that should cause anything especial to happen.
nanonyme: I mean, DISPLAY is automatically set by your X server.
mjr: (actually, not, but the session startup scripts)
nanonyme: I can back down on that one, my point was that if you only have one X server running, setting DISPLAY explicitly to :0.0 is very likely to have no effect.
mjr: laso, if you want to connect to the unix domain socket (as you seem to be trying to do), bind-mount /tmp
nanonyme: (Since it was already that)
skodde: nanonyme: inside the chroot that variable is simply not set
skodde: mjr: i can try that
nanonyme: True, yeah.
nanonyme: Must seriously be too tired. *sigh*
skodde: mjr: same result with the /tmp binded from the host
skodde: (and i also have some security concerns about sharing the /tmp)
mjr: well, check the permissions to the socket, and also having access to the .Xauthority file etc
skodde: mjr: the permissions seem to be fine, i can run applications, but they're slow, also the demos run at ~10fps, the hardware acceleration doesn't work somehow
skodde: (i.e. teacup)
mjr: oh, right
skodde: uops, teapot
mjr: I had managed to miss the original question :]
skodde: but that's funny 'cause without kms it was working, with the same setup
mjr: AFAIK 32-bit DRI1 clients are incompatible with the 64-bit DRI1 kernel driver (which doeth sucketh), and I don't really know if that's being considered for fixing with the current work...
mjr: do you happen to be certain if it was actually direct rendering that was working, or merely indirect GLX?
mjr: (regardless, hey, someone who knows something, please tell me 32-bit clients will work with 64-bit kernels for direct rendering ;)
skodde: mjr: i'm pretty sure it was dri, glxgears was running at ~4k fps
skodde: i didn't check the glxinfo strings though..
skodde: i did it now when i saw the performance loss
mjr: (and yes, at this point I turned completely useless as to the actual question)
skodde: so i guess dri is fine and maybe dri2 has this incompatibility?
mjr: dri wasn't fine, or if it is, it's a fairly recent development
skodde: mjr: well, it was fine with recent version of mesa :-)
_Groo_: hi/2 all
_Groo_: i summon all the devs!!
_Groo_: the latest mesa update broke kwin 3d!!!!
_Groo_: compiz works though
MostAwesomeDude: Could you expound a bit?
_Groo_: cairo-dock dies.. freeorion dies...
MostAwesomeDude: Screenshots, explanations?
MostAwesomeDude: Backtraces? Symptoms?
_Groo_: MostAwesomeDude: for kwin3d it doesnt goes up anymore
_Groo_: MostAwesomeDude: dont know where he dumps the logs
_Groo_: for freeorion see..
_Groo_: [13628.803623] freeorion: segfault at 54 ip b599ef91 sp bfb04920 error 4 in r300_dri.so[b594c000+23c000]
_Groo_: and a lot of Allocating 16 x 16 radeon RBO (pitch 16)
_Groo_: cairo-dock dies with drmRadeonCmdBuffer: -22
_Groo_: [13740.081559] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x16
_Groo_: [13740.081565] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
_Groo_: rs485 btw... the evil one.
_Groo_: and till yesterday and the entire mesa code since dri2/kms started, kwin3d worked... with today commits isnt working anymore...
_Groo_: simples way is to actiavte composite in kde4 and see for yourself
MostAwesomeDude: Then revert to yesterday. Better yet, bisect.
_Groo_: MostAwesomeDude: how do i do that?
_Groo_: the freeorion and cairo-dock never worked in dri2/kms btw.. arent new bugs.. kde is
MostAwesomeDude: _Groo_: git bisect
_Groo_: MostAwesomeDude: can you be a little more specific?
MostAwesomeDude: _Groo_: It's a git command that can be used to track down a bad commit.
_Groo_: MostAwesomeDude: btw im compiling with --with-dri-drivers=r300,swrast --prefix=/usr
_Groo_: did the dri drivers name changed?
_Groo_: well i need some dev to help me out finding out which commit broke kde4 3d
terracon: the dri kicked the bucket, the dri kicked the bucket . lalalala
_Groo_: MostAwesomeDude: xorg log is giving me this also
_Groo_: RADEON DRM CS failure - corruptions/glitches may occur -22
_Groo_: bufmgr: last submission : r:0 vs g:33554432 w:0 vs v:234101142
MostAwesomeDude: Looks like there's issues with your stack. Your DDX is misbehaving.
_Groo_: MostAwesomeDude: also a lot of this in dmesg
_Groo_: [14147.762445] [drm:r300_cs_track_check] *ERROR* [drm] No buffer for color buffer 0 !
_Groo_: [14147.762449] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
_Groo_: [14261.394675] [drm:r300_packet0_check] *ERROR* Invalid texture format 17
_Groo_: [14261.394683] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
_Groo_: but i was hitting a lot of those for weeks now...
_Groo_: latest drm master, mesa master, xf86ati from glisses, glisses kernel (since linus is too unstable for me for now)
MostAwesomeDude: Those should *not* be happening.
MostAwesomeDude: Also, you should really try the kms-support branch of the main DDX.
_Groo_: MostAwesomeDude: well they always did with my rs485
_Groo_: ddx you mean xf86ati?
dli: r5xx card, why does glxgears keep flashing?
dli: I tried the -git version and 6.12.2
_Groo_: acording to airlied, ddx is broken for rs485.. i need to use glisses if i wanna see anythng beyond little sttriped boxes
_Groo_: dli: dri1?
_Groo_: dli: compositing active? (compiz kde4 3d)
_Groo_: MostAwesomeDude: but let me try anyway :P
dli: _Groo_, yes, compiz enabled
dli: _Groo_, so, I should disable compiz to get 3D working
_Groo_: dli: yep
_Groo_: dli: or got for dri2/kms
_Groo_: go i mean
dli: _Groo_, I have dri2proto installed, still have to wait for kms?
_Groo_: MostAwesomeDude: just recompiled and installed ddx kms branch..
_Groo_: MostAwesomeDude: it will crash most likely, so ill be back in about 1 min if it works or half an hour if it dont (most likely)
_Groo_: dli: heheh is more complicated then that.. brb
_Groo_: MostAwesomeDude: beautiful green and blue strippes all over the screen and a kernel crash to top it of.. back to glisses ddx :P
_Groo_: MostAwesomeDude: airlied is punishing me!
_Groo_: MostAwesomeDude: just because i called him alex ;)
_Groo_: well anyway... ddx and mesa are seriously broken with rs485.. no ddx, no fbo, no modesetting, no kde4 3d... compiz works..
_Groo_: hi/2 all
_Groo_: airlied: ping
_Groo_: glisse: ping
airlied: _Groo_: don't call us we'll call you?
airlied: we aren't magically fixing rs485s without telling you
airlied: AndrewR: looking at r200 teapot now, messed up something silly, might be tomorrow though until I can fix it
airlied: wonders if the r200 index fetcher is just crap, and can't hanle vertices and indices in the same buffer
airlied: but that just seems wiered
_Groo_: airlied: ok, dont know if you read backlogs but with today mesa commits, kde4 3d doesnt work anymore
airlied: hehe.. kde, I care less about than rs485 :)
airlied: if you can git bisect t othe broken commit it might get fixed
_Groo_: airlied: ¬¬ what i mean is that kde4 3d is a good regressions test
_Groo_: airlied: can you point me a wiki that explains how git bisect works?
airlied: googole search for git bisect
airlied: basically you identify a good commit and a bad commit
_Groo_: airlied: but might not be mesa , could be the ddx, since i cant use kms-branch (rs485 is broken there also)
airlied: well thats the first thing to figure out then
_Groo_: airlied: well since im using ddx from glisses and mesa broken today, i believe its mesa.. but since the two are kinda dependent.. the only way it for you to fix at least ddx, so i can test mesa
_Groo_: drm and mesa are from master, only ddx from glisses
MostAwesomeDude: _Groo_: Does your VT work?
_Groo_: MostAwesomeDude: yes... dri2/kms works just fine
_Groo_: MostAwesomeDude: the only problem with kms is lack of modesetting modes...
_Groo_: airlied: btw i rerun the mesa tests... fbo is still broken but with the two tests at least now i see a totally garbled picture instead of none at all :D
_Groo_: airlied: im not even in the position to report individual apps bugs like cairo-dock, freeorion, blender or ufoai
_Groo_: airlied: i understand that your priority might be 600/700 up to speed, and that my shitty card is very low in the todo list, but ill just keep posting bugs till it breaks completely :D
_Groo_: or im banished ¬¬ whatever comes first lol
nha: glisse: for the KIL bug, I'm not really sure since I'm not too familiar with the whole GEM and CS thing, but maybe the best way is to just fix it in userspace; maybe we can setup a fake texture that has zero size based on the current renderbuffer or something
airlied: hates dma buffer code, need a better plan :)
kylem: airlied, heh?
airlied: kylem: ah my mesa userspace, seems to be having problems with my optimising its buffer allocation system
coleys: Uhh, how does one enable direct rendering?
airlied: coleys: normally it just works
_Groo_: airlied: i reverted to yesterday mesa.. kwin 3d is working again.. also i was getting a LOT of crashes and hangs... :(
airlied: _Groo_: so you can bisect between the two mesas to find the commit that broke then
_Groo_: airlied: the problem is that im using an old ddx since the new one from kms-branch doesnt support my card.. im not sure its mesa per se, or if its just an unfortunate case of old ddx with new mesa
airlied: if yesterday mesa works and today meas doesn't and you don't change anything else
airlied: then its clearly mesa
airlied: I do wonder if you are trying to use the gallium driver or something
_Groo_: airlied: nope, just r300 and swrast
coleys: Uhh... x200M wouldn't be supported by the radeon driver, if im correct?
airlied: coleys: should be
coleys: This must be outdated, im assuming. =x (http://www.thinkwiki.org/wiki/Radeon_
coleys: This must be outdated, im assuming. =x (http://www.thinkwiki.org/wiki/Radeon)
airlied: yse a long way out of date
coleys: ahah. Just noticed the... Last modified portion on the bottom =p
coleys: Last modified on march 1 2008.\