Radeon IRC Logs For 2008-5-02

airlied: agd5f: on r300/r500 what is the diff between 0x2090/4 and 0x4000/4?
airlied: agd5f: and why am I not programming the 0x4000 ones.
airlied: the r5xx doc 6.4.5 seems to mention both sets
edwi1: is there a primary output when there are multiple screens, and how can you set which output is the primary for the radeon driver ?
tulcod: edwi1: afaik, there’s simply monitor 1 and monitor 2
tulcod: edwi1: why would one screen be primary, and what would that change?
edwi1: tulcod: well it seems as if my tv-out is now “primary” and the DVI-0 secondary. because the standard resolution when both are connected is the resolution of the S-video connection. Furthermore when I try to disable the S-video the system crashes. Also in some gnome desktop tool the S-video output is now the primary screen.
tulcod: edwi1: i doubt it has to do with “primary” or “secondary”
tulcod: doesn’t it have to do with the corresponding maximum size?
tulcod: edwi1: like, if s-video only supports 800×600 max, then dvi-0 will use that too?
edwi1: tulcod: I want to make a minimal xorg.conf file with only the DVI-0 enabled and with the maximum resolution. and i want to be able to dynamically enable / disable the S-video
edwi1: tulcod: yes that is it, the other problem is that the s-video should also support 1024×768, but only the 800×600 mode is available
tulcod: edwi1: “should”?
tulcod: how do you know?
edwi1: tulcod: but regardless of the maximum resolution of S-video the DVI-0 should be 1280×1024
MrCooper: edwi1: I use Option “Enable” “false” in the monitor section associated with the S-video output
edwi1: tulcod: I know because that is the resolution I used to have ( when I was running with fgrlx in linux and in windows, radeon did now work for me until recently )
edwi1: mrcooper: if i do that, xserver will not start, and i get the ” running in low resolution ” dialog, if you know what i mean
tulcod: edwi1: this might have something to do with this: http://gentoo-wiki.com/HOWTO_Dual_Monitors#Switchscreen
MrCooper: edwi1: sounds like your DVI-0 isn’t autodetected properly
tulcod: edwi1: not sure though
tulcod: edwi1: maybe pastebin your Xorg.0.log?
edwi1: tulcod: i will pastebin it, but i have tried a lot of different variations to my xorg.conf, so i am not sure if this is the optimal one
tulcod: edwi1: they all had the same result right?
edwi1: tulcod: well neither had the correct result 😉
edwi1: tulcod: some were worse than others
tulcod: edwi1: fair enough :p
tulcod: okay…
tulcod: edwi1: well, pastebin the log of a setup which describes your curernt problem
edwi1: tulcod: hmm the log is too big for pastebin 🙂
tulcod: edwi1: try rafb.net/paste
edwi1: tulcod: same problem i think :S
edwi1: tulcod: the log has more than 14k lines apparently
tulcod: edwi1: i can’t imagine that
tulcod: edwi1: 14000 lines ?!
edwi1: tulcod: yeah strange isnt it :S
tulcod: edwi1: du -hs /var/log/Xorg.0.log
tulcod: no, without -s
edwi1: 552 kb
edwi1: tulcod: i think it has all kinds of debugging output in it
edwi1: tulcod: wait ill try a different xorg.conf, be right back!
tulcod: edwi1: meh, it doesn’t look unreasonable to me… i can upload it
tulcod: no!
tulcod: stop!
tulcod: stay where you are!
edwi1: ok 🙂
edwi1: haha
tulcod: edwi1: do you have wgetpaste or anything like that?
tulcod: cause the problem might just be browser-related
edwi1: maybe
tulcod: edwi1: try & install wgetpaste (it’s a great tool anyway, so you’ll want to have it)
tulcod: then: wgetpaste /var/log/Xorg.0.log
tulcod: wait a few secs
tulcod: then it’ll give you a link 🙂
edwi1: tulcod: i will
edwi1: tulcod: i think there are just too many lines, when i paste it without line breaks it works, the size is not the problem i think
tulcod: edwi1: using your browser or wgetpaste?
edwi1: browser, i will try your suggestion now
edwi1: tulcod: http://pastebin.com/f2ee06a06 is it, but when i open it it errors out
tulcod: edwi1: that’s not wgetpaste’s work 🙂
tulcod: edwi1: seriously, rafb.net/paste pwnz most, if not all, paste services in many ways
tulcod: use wgetpaste & start pwning too!
edwi1: hahaha
edwi1: i used pastebinit, shouldnt that be just the same?
tulcod: edwi1: that pastes to pastebin 😉
tulcod: edwi1: wgetpaste pastes to rafb.net/paste
edwi1: ah ok
tulcod: bbias
edwi1: tulcod: Pasting > 10000 lines often tend to fail with rafb. Use –verbose or –debug to see the
edwi1: error output from wget if it fails. Alternatively use another pastebin service.
edwi1: The paste is too big. Try another service or paste smaller chunks of data.
edwi1: shall i paste the first 10k lines ?
edwi1: tulcod: this was with your program
tulcod: edwi1: heh – the same order of paste size worked for me
tulcod: i just pasted 6k lines, 410kb
tulcod: edwi1: well hten, split the paste!
edwi1: tulcod: sir yes sir! 😉
edwi1: tulcod: http://rafb.net/p/WHGCLP37.html and http://rafb.net/p/1fbESH55.html
tulcod: edwi1: cool
tulcod: edwi1: line 987-988 seem to be interesting
tulcod: that’s all i can find though 😛
edwi1: ill check
edwi1: tulcod: yes that is the problem
edwi1: tulcod: should be DVI-0 1280×1024, S-video: 1024×768. That would be perfect
tulcod: edwi1: you know that the s-video output can handle that?
edwi1: tulcod: yes, but i am already satisfied with 1280×1024-800×600
edwi1: tulcod: the S-video is a secondary problem for another time 😉
tulcod: edwi1: what are your modelines?
tulcod: in xorg.conf
edwi1: tulcod: well at first i didnt have any, but now i have these:
edwi1: modeline “1280×1024@75” 135.0 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync
edwi1: modeline “1280×1024@60” 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync
agd5f: edwi1: S-video currently only supports 800×600
agd5f: in theory the scaler can support any mode, but no ones’s sorted ou the proper clocks an such for modes other than 800×600
edwi1: agd5f: ok too bad, well it used to work with fgrlx and also in windows, but i can live with the 800×600. But i really want the DVI-0 to have a higher initial resolution if possible
agd5f: edwi1: right. someone just needs to add the code
tulcod: agd5f: but why can’t the dvi be at a higher res simultaneously?
agd5f: edwi1: you’ll have to add a monitor section and set a perferred mode for DVI since the server default is to clone the outputs
edwi1: agd5f: i have had this in one of my previous attempts, but it did not work really well, ill try again
agd5f: tulcod: you can at runtime using xrandr: xrandr –output DVI-0 –mode 1280×1024, or by adjusting your xorg.conf
agd5f: edwi1: http://www.intellinuxgraphics.org/dualhead.html
edwi1: agd5f: i have read the same webpage, but no success
edwi1: agd5f: i will try again now. how can i force to not clone the outputs initially in the xorg.conf ?
edwi1: agd5f: with the preferredmode ?
agd5f: edwi1: yes
agd5f: unless you want daulhead
agd5f: *dual
agd5f: then you need Option “rightof”, etc.
edwi1: sorry my computer hung
agd5f: edwi1: for example: http://rafb.net/p/zcXgMO36.html
edwi1: agd5f: ok that is approximately what i had, ill try it again and report back
edwi1: agd5f: like this: http://rafb.net/p/9rsrcT61.html ?
agd5f: airlied: 0x4000 is a shadow of 0x2090
edwi1: agd5f: well that works a bit. the login screen is still a 800×600 image but now on a 1280×1024 desktop, but i guess that is not a radeon driver problem. however the S-video does not seem to work
agd5f: edwi1: yeah the server defaults tend to be lacking
edwi1: agd5f: wow the desktop is really unstable now, another crash
edwi1: afd5f: i think this time it is my ignorance, but how can i enable the S-video ?
agd5f: edwi1: using xrandr, or via xorg.conf
agd5f: xrandr –addmode S-video 800×600; xrandr –output S-video –mode 800×600
edwi1: agd5f: using xrandr ( xrandr –output S-video –mode 800×600 ) i only get some flickering but nothing more
agd5f: edwi1: did it ever work?
edwi1: agd5f: not with the radeon driver, it used to with the closed driver
agd5f: edwi1: what chip?
edwi1: agd5f: but normal dvi also didnt used to work for me, but now it does, so optimistically i am trying
edwi1: agd5f: X700 pro
agd5f: edwi1: IIRC r4xx users still have issues with tv-out. I think the gpio control bits changed
edwi1: agd5f: ok that means it is in the current state expected not to work ? ok too bad, if i can test or try anything i would be glad to.
rschmidt: hi guys, I’m working on a bit of a ‘special’ system (Samsung TV with computer built-in, like a laptop with a giant screen), and I’m having trouble getting X to recognize the outputs as ‘connected’ (xrandr 1.2 reports everything as disconnected)
rschmidt: anyone seen something like this before with the radeon driver? I’m using Xorg 1.3.0 on Fedora 8 with the latest packages installed.
MrCooper: rschmidt: can you put up the full Xorg.0.log somewhere?
rschmidt: sure thing
rschmidt: lemme just restart it here, it’s full of junk from me calling xrandr –auto six hundred times
rschmidt: MrCooper: Full Xorg log is here: http://www.pastebin.ca/1005019
rschmidt: btw, the card is a Radeon X1200
edgecase: rschmidt, got a URL for that TV?
rschmidt: sure… it’s a Samsung 400Dxn… 1 sec
rschmidt: umm, a 460 DXn, I mean…
rschmidt: here’s the webpage from the Samsung site, although I’m not sure it’ll be much use (it’s very sparse): http://www.samsung.com/ca/consumer/detail/detail.do?group=computersaccessories&type=monitors&subtype=largeformatlcd&model_cd=LS46BPTNB/XAA
rschmidt: it’s actually a 46″ LCD panel with a dual-core AMD PC built in.
rschmidt: the strangest part is that if I connect a regular PC to the TV’s VGA inputs (without using the internal PC), it displays just fine.
agd5f: rschmidt: they may not provide an edid since it’s an oem all-in-one
agd5f: their drivers may hardcode stuff
rschmidt: agd5f: yeah, that’s possible… I don’t really mind no EDID, and I tried forcing a mode that I know works (tested using the external PC) for that panel
rschmidt: oh, and another interesting thing… I got Slax (Slackware-based liveCD distro) to display on that screen… but they’re using Xorg 1.4, IIRC
agd5f: also, It’s not clear what output they are using. connector table indicates ddia, but the connector able may be bogus if their driver hardcodes everything
rschmidt: right, I agree
agd5f: rschmidt: can you post your xorg.conf?
rschmidt: sure thing
rschmidt: thanks for all your help, btw, guys, it’s much appreciated
rschmidt: I build digital signage devices for a living and I’ve had my share of playing with X, but this one’s got me stumped.
rschmidt: and of course, Samsung is absolutely useless when it comes to supporting VARs like me.
edgecase: rschmidt, it doesn’t mention the PC inside, is that an add-on?
rschmidt: no, it comes with the machine, but they only refer to it as ‘MagicNet’
edgecase: what chipset does it have? those could make really nice HTPC + LCD units, with linuxbios instant-on…
rschmidt: if you look in the manual, you’ll find a section on ‘using the software’… they preinstall XP embedded in that PC and use it as digital signage software.
rschmidt: I’m not 100% sure on the chipset, but I can dump all the info you want…
rschmidt: and yeah, they are very nice.
edgecase: yeah lspci -v | pastebin
agd5f: rschmidt: I suspect it will work if you force on the DVI port rather than the VGA port
rschmidt: only problems: no optical drives, only 4 GB of solid state storage
edgecase: which radeon does it have, can it do HDTV decode?
rschmidt: it should…. it’s got an x1200
rschmidt: or an x1250
edgecase: it’s not using LVDS to drive the LCD panel directly?
quicksilver: where is the big list of which “marketing names” for radeons have which chips inside?
agd5f: rschmidt: xrandr –addmode DVI-0 1368×768; xrandr –output DVI-0 –mode 1368×768
edgecase: quicksilver, radeon man page, there’s one at x.org if you can find it
rschmidt: agd5f: trying that now
quicksilver: edgecase: thangs
rschmidt: agd5f: sorry bout taking so long on xorg.conf, I’m playing with it and I broke it 😛
quicksilver: Ah. OK. it’s an rv610.
quicksilver: So my question is: to get dual-head on an rv610, best to use ati or radeonhd?
rschmidt: agd5f: still no display, although xrandr reports current resolution as being 1368×768
rschmidt: still says VGA-0 and DVI-0 are both siconnected.
rschmidt: disconnected, that is
rschmidt: xorg.conf is here: http://www.pastebin.ca/1005044
agd5f: rschmidt: is there a * next to the modes in the xrandr output?
rschmidt: yes, there is (wasn’t there before)… lemme paste current xrandr output in pastebin
agd5f: rschmidt: they won’t show up as connected since there’s not edid
rschmidt: ah, okay
rschmidt: xrandr output is here: http://www.pastebin.ca/1005045
agd5f: rschmidt: try xrandr –verbose
rschmidt: contents are here: http://www.pastebin.ca/1005048
rschmidt: it looks like the timings are all OK
agd5f: rschmidt: try adding Option “Monitor-DVI-0” “Monitor0” to your device section
rschmidt: done
agd5f: and then add Option “enable” “true” to the monitor section
rschmidt: retrying
rschmidt: hmmm… no visual change, checking the logs
rschmidt: hmmmm… seems to have changed the log output a little bit… pasting it now
quicksilver: agd5f: rv610 will dual head with the radeon driver?
agd5f: quicksilver: should work
edgecase: rschmidt, can you pastebin lspci -v ?
quicksilver: agd5f: how recent a version needed? roughly?
rschmidt: yup! 1 sec.
rschmidt: edgecase: pastebin is here: http://www.pastebin.ca/1005060
agd5f: quicksilver: 6.8.0 or newer should work
rschmidt: seems to be an ATI chipset with AMD CPU
rschmidt: edgecase: I tried LVDS too, but it only seems to find VGA and DVI…
quicksilver: agd5f: many thanks.
rschmidt: edgecase: although, the panel IS connected via an LVDS cable (I checked)
agd5f: rschmidt: you’ll have to hack the driver to try different outputs
rschmidt: agd5f: oboy!
agd5f: rschmidt: I can probably whip a some patches in a bit
rschmidt: agd5f: I guess I’ll dig out my compilation tools
rschmidt: well, that’d be really great
rschmidt: I’ll start by grabbing the sources and poking around a bit
rschmidt: also, I’ll reboot on slax and see what kind of options they’ve set
rschmidt: maybe this whole thing is due to a bug in X and not in the driver
agd5f: rschmidt: radeon_atombios.c: RADEONGetATOMConnectorInfoFromBIOSConnectorTable()
rschmidt: okay, thanks
agd5f: you can just hardcode the connectors and at the top and return
rschmidt: uhhhh… maybe I’m a little dense here, but where can I get the source for the driver?
rschmidt: ahh, freedesktop.org, right?
agd5f: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati
rschmidt: thanks
agd5f: rschmidt: http://www.botchco.com/alex/xorg/rschmidt.diff
rschmidt: wow, thanks
rschmidt: interesting note: I just booted up Slax again, they’re using Xorg 1.4.0.90, and VGA-0 reports it’s connected via xrandr
agd5f: rschmidt: log?
rschmidt: pasting it in a sec, gotta open SSH on this machine so I can grab it
rschmidt: damn, pastebin.ca has a 150Kb limit… here’s the log: http://pastebin.com/mc892b6
rschmidt: seems to be the same version of the driver (4.3.0), different version of X.
rschmidt: this is the xorg.conf slax uses: http://www.pastebin.ca/1005085
agd5f: rschmidt: the only difference is that that driver is using 1024×768 on VGA rather than 1368×768
rschmidt: right, no big differences there
rschmidt: and in 1024×768 the output is garbled on the panel… I have to set it to 1368×768 if I want something usable (but it displays *something*, which is better than nothing)
rschmidt: however, the xrandr output is very different…
MrCooper: the radeon_drv.so version hasn’t been changed in an eternity…
rschmidt: you can see it here: http://www.pastebin.ca/1005089
rschmidt: ah, so it might have a bunch of patches applied or something.
agd5f: rschmidt: I suspect it uses DDIA, but it’s a matter of getting the right mode. the slax version works because they are using a old version of the driver that didn’t know about DDIA
agd5f: so it didn’t turn the output off
rschmidt: aha.
agd5f: then when the driver programs the VGA, the DDIA is still on so it comes up
rschmidt: what’s DDIA, exactly?
rschmidt: dual display on single output?
agd5f: rschmidt: it’s one of the digital outputs on the RS6xx chips
rschmidt: ah
agd5f: it’s basically TMDS over PCIE lanes
agd5f: anyway, BBL
rschmidt: ah, I see
rschmidt: thanks, I’ll set up a spot where I can compile the driver
MrCooper: so TMDS over PCIE lanes over an LVDS cable? 🙂
rschmidt: heheh, looks like!
rschmidt: it’s really weird
agd5f: LVDS cable?
agd5f: I could be LVDS I suppose
rschmidt: yeah, the LCD panel is connected to the computer via an LVDS cable
agd5f: but that would use the LVTMA block
rschmidt: although, I don’t know if there’s some sort of unit in front of it doing something-to-LVDM conversion
agd5f: rschmidt: I’ll whip up a patch later to test LVDS
rschmidt: I mean, something to LVDS
rschmidt: I just ripped the TV open and found an LVDS cable.
agd5f: lvtma can do either LVDS or TMDS depending how it’s programmed
rschmidt: okay, thanks… I’ll test the patch you already sent me first… but it’s lunchtime
agd5f: yeah
agd5f: bbl
rschmidt: later
timofonic: Hello
rschmidt: again, thanks
timofonic: I sent a bug report to a developer and he said me to use the closed source ATI Radeon drivers… http://www.lxdream.org/forums/viewtopic.php?p=315
timofonic: So it’s true what he says? If it’s true, how it can be resolved and if will be possible to resolve it someday?
quicksilver: timofonic: which versions of the ati driver are you using?
quicksilver: and mesa/drm etc?
MrCooper: timofonic: he’s right, and it will be resolved with DRI2 and/or Gallium
MrCooper: uh oh, who mentioned bridgman’s name? 😉
bridgman: timofonic: I expect the open drivers will pick up most of the functionality of
bridgman: fglrx, but it won’t happen quickly. The general consensus is that we should
timofonic: quicksilver, x11-libs/libdrm-2.3.0 media-libs/mesa-7.0.2 and the radeon driver let me find it…
bridgman: use Gallium for any serious increase in gl functionality, and that’s going to
bridgman: take some time. The mesa software renderer should have the capabilities you
timofonic: bridgman, good. I’m totally against binary drivers/blobs, so it’s good it will get resolved
bridgman: need today, but of course it wouldn’t be as fast
bridgman: (understatement of the century ;))
timofonic: bridgman, probably too slow for a Dreamcast emulator
bridgman: yeah, unless you had some way to slow your brain down
timofonic: bridgman, do you have a spy there? Appeared and replied directly 🙂
quicksilver: superficially ext_framebuffer_objects sounds liek something which could be handled in software pretty well actually?
timofonic: bridgman, but that way can be illegal 😉
bridgman: depends on what country you’re in, just like reverse engineering 😉
timofonic: yep
quicksilver: just swapping buffers in and out of the card
quicksilver: OK it’s not instant but the actual rendering woudl still be hardware
bridgman: no spy; I can’t access IRC from work yet so whenever I am able to access I check the
bridgman: logs and see if anything interesting is going on that I can meddle with 😉
rx__: what kind of work is this… can’t IRC
rx__: unless you mean no time for irc 🙂
bridgman: a lot of companies doing sensitive work block IRC. I can get access opened but haven’t had
bridgman: time to make arrangements yet
bridgman: no time for IRC either but policy is not to use it
timofonic: quicksilver, here is the driver version (I think)
timofonic: (II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so
timofonic: (II) Module radeon: vendor=”X.Org Foundation”
timofonic: compiled for 1.4.0.90, module version = 4.3.0
timofonic: Module class: X.Org Video Driver
timofonic: ABI class: X.Org Video Driver, version 2.0
bridgman: gotta run, bye
timofonic: Should I update to mesa 7.0.3?
timofonic: bridgman, bye
rx__: bye
quicksilver: timofonic: that is a very old radeon driver
quicksilver: timofonic: very very old.
timofonic: quicksilver, uhm?
timofonic: quicksilver, I use Gentoo
quicksilver: although I forget exactly which version numbers go where.
MrCooper: quicksilver: the radeon_drv.so version hasn’t been changed in an eternity…
quicksilver: ah.
MrCooper: it could be any version of xf86-video-ati
quicksilver: then that’s not the version I want 🙂
timofonic: Can I blame devs for that lack of discipline? 🙂
MrCooper: and the video driver doesn’t really matter for this anyway
quicksilver: timofonic: no, turns out I’m confused.
timofonic: quicksilver, oh ok 🙂
quicksilver: timofonic: that’s not the important number.
quicksilver: there is another number somewhere.
quicksilver: MrCooper knows more than me but since no one was helping you I thouhgt I’d try.
quicksilver: since he’s here now I suggest you listen to him 🙂
MrCooper: actually, I’m as good as gone 🙂
timofonic: quicksilver, ok 🙂
MrCooper: bbl
timofonic: quicksilver, good tactic for avoiding problems 🙂
quicksilver: timofonic: can you paste your glxinfo into a pastebin?
timofonic: MrCooper, so I must wait until some dev adds the feature? Get a life? Forget the app that needs the feature?
timofonic: quicksilver, Ok
timofonic: quicksilver, http://rafb.net/p/UEThxg37.html
ghepeu: hi
ghepeu: could hardware problems cause X lockups?
timofonic: The system is finishing to build the latest paludis, I’ll update MESA later if needed. I use Gentoo GNU/Linux but with Paludis, because it sucks less tan Portage 🙂
MostAwesomeDude: Whoo-hoo! TEX/TXP works.
timofonic: quicksilver, was the info useful?
MostAwesomeDude: Now gotta figure out the temps…
timofonic: I’m going away a few hours, learning C. I’ll read your reply later
agd5f: rschmidt: http://www.botchco.com/alex/xorg/rschmidt-lvds.diff lvds patch
agd5f: MostAwesomeDude: you should post a git tree
MostAwesomeDude: agd5f: I would love to. How do I get an fdo account?
agd5f: http://www.freedesktop.org/wiki/AccountRequests
agd5f: feel free to cc me
ghepeu: mmmh… could unrelated hardware problems be causing X lockups?
agd5f: ghepeu: sure. anything’s possible
ghepeu: X lockups with the X process unkillable and using 100% CPU
ghepeu: while it’s still possible to ssh in?
agd5f: ghepeu: sounds like a gpu hang
MostAwesomeDude: ghepeu: I love those!
ghepeu: yeah, that’s what I suspected
ghepeu: could it be due to a hw problem, for example overheating, or the motherboard dieing
ghepeu: (tell me “NO”, please)
MostAwesomeDude: ghepeu: I get them with Xorg 1.4 (’tis why I’m still on 1.3…), so it could easily be software.
agd5f: ghepeu: does reverting 31815730732a5d2a446aa316a5b4d837766762e6 in the drm help?
ghepeu: “r300: Added the CP maximum fetch size and ring rptr update variables.”
ghepeu: I don’t think so
ghepeu: Thing is, I had a stable machine (stable as in compiz for 6 months without a single problem)
ghepeu: then I upgraded here and there and it started locking
ghepeu: so I’m reverting to “proven stable releases” (as in the ones who gave me those 6 months)
ghepeu: but it doesn’t seem to be a xf86-video-ati problem, nor an xserver problem
ghepeu: and now I’m trying with the diff between mesa 7.0.3_rc2 and 7.0.3_rc3
ghepeu: and it’s a random lockup, so it’s hard to test
agd5f: ghepeu: that diff is about a year old
agd5f: it probably didn’t make it into the kernel for some time
ghepeu: I started having problem when I switched to git in march 2008
ghepeu: checking kernel git
ghepeu: agd5f, you could be right
ghepeu: it seems that that change went in on february 7, that is after 2.6.24 was released
MostAwesomeDude: agd5f: Okay, I’m ready to submit the bug. What email do you want attached?
ghepeu: i upgraded to 2.6.25 on april 19
ghepeu: in my list of lockups I had seven good days with mesa 7.0.3, xserver 1.4.0.90 and a february snapshot of the ati driver
ghepeu: lockups on 20080410 1540, 20080420 1215, 20080421 2330, 20080424 1512, 20080428 1355, 20080430 0938, 20080502 1525
agd5f: MostAwesomeDude: [email protected]
ghepeu: before 20080420 it was possible to kill X, then it became impossible (and the mouse became jerky after the lockup)
ghepeu: I’m reverting that commit and rebuilding the kernel module
MostAwesomeDude: agd5f: Committed.
agd5f: MostAwesomeDude: can I see your latest patch?
MostAwesomeDude: Sure, lemme gen.
MostAwesomeDude: Okay, rebased, lemme make sure that it still builds.
MostAwesomeDude: At some point, the suits going to take my git privileges away.
MostAwesomeDude: Gonna be all, “It’s for the public welfare.”
MostAwesomeDude: agd5f: http://rafb.net/p/6dhLYr28.html
agd5f: cool
quicksilver: DISPLAY=:0 xrandr –output VGA-0 –same-as S-video
quicksilver: is that correct syntax? because it didn’t appear to work.
quicksilver: S-video is still working fine by VGA-0 is showing a blank screen.
quicksilver: I wonder if the ForceTVOutput is msessing it up
funda3: just doing xrandr –output S-video –preferred duplicates what’s on VGA-0 unless you change the position of either from 0+0
funda3: –same-as has has never worked for me for some reason, yeah, i would get rid of such lines in xorg.conf
quicksilver: hmm
quicksilver: wirth forcetvoutput off, the VGA works
quicksilver: but the S-video stops working :-/
quicksilver: it says it’s disconnected
quicksilver: so I can get either one but not both
funda3: you might need to do xrandr –output S-video –set load_detection 1
quicksilver: ah.
quicksilver: clever!
quicksilver: hmm.
quicksilver: funda3: that turned it on
funda3: 🙂
quicksilver: funda3: but I can’t make it output anything
quicksilver: ooh, now it is.
quicksilver: it’s because it was in the middle of Xv-inf something
quicksilver: evidently Xrandr doesn’t work during open XV “sessions”?
quicksilver: hmm no.
quicksilver: Xv doesn’t work at all.
quicksilver: the “menu screen” (this is mythtv, btw) is mirrored on both
quicksilver: but when I actually play video it’s only on one
agd5f: quicksilver: what card are you using?
agd5f: quicksilver: only one overlay. can only be one crtc at a time
agd5f: if you want Xv to show up on both heads, use textured video adapter
quicksilver: agd5f: ah!
quicksilver: agd5f: Radeon 9250.
quicksilver: agd5f: thanks.
quicksilver: agd5f: even with mirrored heads?
quicksilver: I thought it could just share the vram, or something
agd5f: for the overlay use XV_CRTC av attribute to siwtch which head the overlay is on
quicksilver: guess it’s not htat sensible
quicksilver: simple
agd5f: quicksilver: the overlay data gets combined with the graphics data during scan out
quicksilver: nods
quicksilver: I don’t rally need mirrored at any one time
quicksilver: it’s just more convenient if I don’t have to chooseexplicitly which video out I’m using.
quicksilver: agd5f: many thanks!
quicksilver: I know how to switch now.
agd5f: quicksilver: np
rschmidt: ok, looks like it’s time to patch the radeon driver and give it a spin…
rx__: bleh..
rx__: keep forgetting to rmmod fglrx before testing…
rx__: agd5f; powerplay seems to work wonderfully here
agd5f: rx__: cool
rx__: get the set engine success for both core/mem
rx__: i can check powertop later and see if it’s actually dropping watts
rx__: but it parsed the tables correctly afaict
rx__: anything to test for w/r345-cleanup?
rx__: oh.. and thanks agd5f 🙂
rx__: hmm..
rx__: it lists 3 optimal battery life entries, 1 high battery entry, and 1 balanced entry
rx__: wonders what happened to high performance and optimal performance
agd5f: MostAwesomeDude: I got r5xx tcl working
agd5f: airlied: ^^
rx__: ooo..
agd5f: posting my meas tree now
agd5f: *mesa
dli: agd5f, I would like to try it!
agd5f: dli: justing waiting for my mesa tree to transfer 🙂
rx__: guesses…
rx__: http://cgit.freedesktop.org/~agd5f/mesa/ when it’s done? 😉
agd5f: rx__: yup
agd5f: r345-cleanup branch
agd5f: just need to fix FPs
rschmidt: agd5f: just tried your first patch, compiled with no problems but still the same Xorg.log, xrandr output and results on screen (no display, xrandr reports both VGA-0 and DVI-0 are disconnected), trying your LVDS patch now
agd5f: rschmidt: you’ll have to force the outputs on.
agd5f: since ther’s no edid
rschmidt: you mean post-startx, via xrandr I imagine?
agd5f: xrandr –addmode DVI-0 ; xrandr –output DVI-0 –mode
rschmidt: ok, I’ll try that, thanks
agd5f: replace DVI-0 with LVDS for the second patch
agd5f: although you may need the PanelSize option for that
rschmidt: ok, I’ll check it out, thanks
agd5f: ok, mesa is uploaded, it’ll show up as soon as the git daemon picks it up
MostAwesomeDude: agd5f: Just got back from lunch. I’m trying to figure out how to push to my own personal repo; after that, I’ll look at your code.
agd5f: http://gitweb.freedesktop.org/?p=users/agd5f/mesa.git;a=shortlog;h=r345-cleanup
dli: git://people.freedesktop.org/~agd5f/mesa
agd5f: MostAwesomeDude: scp -r .git [email protected]:~/mesa.git
agd5f: then in mesa.git on people.freedesktop.org, touch git-daemon-export-ok
dli: agd5f, could you write a word at least in .git/description?
rschmidt: still no dice with the new patch, agd5f… if I use –output LVDS it complains that it doesn’t exist. if I use –output DVI-0 I get a * beside the mode, but still no display
rschmidt: unfortunately, I’m not in front of the screen anymore, so I’m gonna stop testing this stuff till Monday
rschmidt: thanks for all the help though, it’s very cool
agd5f: rschmidt: no worries. we can pick up later
agd5f: dli: better 🙂
rschmidt: all right, thanks again 🙂
dli: agd5f, do you need the Xorg.0.log file?
agd5f: dli: nope
agd5f: it’s just 3D changes
dli: agd5f, glxgears is faster now
agd5f: yup 🙂
agd5f: no textures yet though
mcgreg: agd5f: does it mean we made a large step ahead to 3D for r500 🙂
agd5f: mcgreg: not really. fragment shaders are the hardest part and they still aren’t done
agd5f: mcgreg: vertex shaders were mostly unchanged
agd5f: although there are some new PVS instructions we could take advantage of for r5xx
MostAwesomeDude: agd5f: With the exception of sine and cosine, the big thing in PVS are GLSL-specific instructions, I think.
MostAwesomeDude: mcgreg: TCL makes everything fast, but fragment shaders make everything pretty.
agd5f: yeah, probably
MostAwesomeDude: Gah, 90% uploaded. I hate Comcast sooo much.
mcgreg: sounds good 🙂 hhe you dont know how much I am looking forward to get nice 3d support for r500 🙂
MostAwesomeDude: mcgreg: I have exactly one box with a head, and it’s the laptop I do all the radeon work on, so I think I know how much you are looking forward. ( ^^)
dli: agd5f, fullscreen X-video still hangs the machine
airlied: agd5f: nice work..
agd5f: dli: overlay or textured video?
agd5f: airlied: thanks
airlied: agd5f: we should probably make an offical r5xx branch 🙂
dli: agd5f, textured, “mplayer -vo xv”
agd5f: dli: is the drm loaded?
agd5f: airlied: yes. I might as well do it now
dli: drm 151424 3 radeon
airlied: agd5f: did you see that bug with connector/ddc type 8?
dli: agd5f, yes drm radeon both loaded
agd5f: airlied: yeah. I can’t find anything about type 8. I’m guess sdvo, which I have no idea how to program
agd5f: dli: got a xorg log?
airlied: agd5f: yeah rs4xx yet again.
agd5f: yup
dli: agd5f, http://pastebin.ca/1005496
airlied: agd5f: guess the raster stuff doesn’t solve my problem then..
airlied: agd5f: trying to solve the compiz on rs690 again yesterday.
agd5f: airlied: I think we were setitng up the pvs wrong wrong on rs chips. I fixed it in my mesa branch
agd5f: s/pvs wrong/pvs routing/
airlied: what pvs 🙂 the bypass routing
airlied: ?
agd5f: airlied: the vec_last stuff
airlied: oh wierd how so ..
agd5f: airlied: the logic in swtcl.c: r500TranslateFragmentShader() looked wrong. it should be the same as the tcl patch I think
agd5f: sorry r300VAPInputRoute0()
airlied: agd5f: could be, last time I amde the same same it all broke.
airlied: agd5f: I’ve got a cleaner version of that function here..
agd5f: airlied: might be broke again 🙂 I haven’t tried on rs yet
airlied: I actually think the non-tcl case is broken but works as we always emit 4 vectors.
airlied: the swtcl isn’t so blessed..
airlied: I should probably do the rs690 work on the r5xx branch 🙂
agd5f: yes
agd5f: I’ll go ahead and push my r345-cleanup branch to mesa
agd5f: so everyone can play
airlied: I’ve cleaned up the rs setup..
agd5f: cool
agd5f: should I merge first?
airlied: you put up your branch and I’ll rebase my stuff on it.
agd5f: k
airlied: you might want to rebase all of your branch.
airlied: includeing my coommits.
airlied: so we can see them linearly.
agd5f: what’s the best way to do that?
airlied: hmm I think just git rebase master
airlied: should rebase all commits not in master
airlied: or origin/master
airlied: http://people.freedesktop.org/~airlied/r300_fixes.txt
airlied: btw is my hackage on rs690 so far.
airlied: doesn’t fix compiz though..
MostAwesomeDude: airlied, agd5f: I’m getting one or two faces not drawing right in glxgears, but otherwise it’s excellent. Up from ~2000 FPS to ~2500 FPS. Mednafen (GBA emulator) and mplayer -vo gl2 draw stuff now. (Still have FP issues, though…)
airlied: MostAwesomeDude: excellent..
MostAwesomeDude: TEX works fine. TXP should, but all the TXP tests use temps and MUL, which don’t work well together yet.
mcgreg: MostAwesomeDude: what gfx card do you have?
agd5f: airlied: You must edit all merge conflicts and then
agd5f: mark them as resolved using git update-index
MostAwesomeDude: mcgreg: M66, R515 Radeon Mobility X1700.
agd5f: I’ve fixed the conflicts…
mcgreg: MostAwesomeDude: well, I have an rv515 , seems lie almost the same 🙂
mcgreg: x1300, desktop
MostAwesomeDude: mcgreg: The r515, r525, and r530 are all the same, but with different numbers of pipes.
MostAwesomeDude: The r520, confusingly, is a different chip.
mcgreg: so, did I underastand correct, you are going to merge airlieds mesa-branch and agd5f mesa-branch .. and merge it into master?
MostAwesomeDude: Okay, so my git tree is http://gitweb.freedesktop.org/?p=users/csimpson/mesa.git;a=summary
dli: no, mplayer -vo gl2 doesn’t draw video, just a colorful box
agd5f: mcgreg: I’m just going to push to a new branch in the main mesa tree
mcgreg: okay
MostAwesomeDude: dli: It used to not draw anything at all.
dli: do_wait: drmWaitVBlank returned -1, IRQs don’t seem to be working correctly
dli: that’s from -vo gl
MostAwesomeDude: dli: AFAIK, we don’t have vsync.
dli: video card temperature is always high now, 93C
mcgreg: sounds very unhealthy
MostAwesomeDude: ‘k. Time for an adventure. I’ll be back later.
mcgreg: n8
agd5f: airlied: http://cgit.freedesktop.org/mesa/mesa/log/?h=r500-support
agd5f: airlied: what do you think we should do about the pipe setup? we really need to read it in from GB_PIPE_SELECT. I’d like to move that to the drm, but not sure what teh best backwards compatible approach is
airlied: agd5f: I think the drm should probably set it up if possible.
agd5f: airlied: that part is easy, but what about users with old drms?
airlied: agd5f: don’t start 🙂
airlied: at least on r500.
roh: *sigh* updated recompile.. hoping it does better this time
agd5f: I suppose I should merge my r345-cleanup drm branch
agd5f: I’ve gotten reports that it works ok on rs4xx
roh: any new code for r515 lately? (last few weeks)
agd5f: roh: lots of stuff probably
roh: xaa and x11 video worked some time now (with performance impact of course) but the mouse cursor is weird. it flickers on some ‘colums’ of the screen
roh: like 6 cleanly identically spaced bars, 1-2chars wide accross 1680 pixels
roh: xv video in exa and xaa crashed sometimes for me (100% cpu, x11 unkillable via ssh. propanbly stateD related (while in a mesa call?)
roh: updated mesa also and compiled x again
roh: do i need to select some special head on git?
agd5f: roh: neither textured video nor exa uses mesa
roh: eh.. sorry.. drm.. will try the new build now
MostAwesomeDude: Evening, all.
rx__: evening 🙂

Radeon IRC Logs For 2008-5-02

Rig Lab Hardware

You Might Also Like

RadeonHD.org | Radeon IRC Logs For 2008-3-02

RadeonHD.org | Radeon IRC Logs For 2008-10-24

RadeonHD.org | Radeon IRC Logs For 2008-5-19