Nightwulf|work: hi all
airlied: agd5f, mjg59 : rv530 thinkpad t60p - dynpm=1 corrupts my LVDS panel at boot, can still read but its got lots of bits repeated and overlapping
airlied: with static pm, echo 1.0 > power_state; echo 4.0 > power_state hard hangs
agd5f: airlied: just about done setting up the t60p I just got, so hopefully I can start debugging that tomorrow
airlied: agd5f: oh cool is it the x1400 or firegl one?
airlied: or s x1400 just a t60. me forgets
agd5f: firegl I think
airlied: agd5f: btw I tihnk it was 8016ab27b84e780461a867a1c33be3d7f5e7f787 that causes the lvds mess u
airlied: though maybe not since you rebasd
twnqx: i think i once had a x1400 t60p
twnqx: surely no firegl there
airlied: I think that was just the plain t60
twnqx: nah, i had the 15.4" widescreen
twnqx: i wonder if i have some old logs from tha tone
airlied: yeah t60 as ell
airlied: http://www.thinkwiki.org/wiki/Category:T60
airlied: the T60p had firegls
twnqx: hm yeah
twnqx: strange... gonna take a look when i again meet the colleague who uses it now
airlied: mjg59, agd5f : one other thing we have to be careful of is fbcon, since it always has a mapping of VRAM, not sure if taking the console sempahore is good enough
agd5f: good point
Tommeh: Woot. Ubuntu 10.04, KMS, compositing... All with open source drivers on an R600 card. :D
Tommeh: thanks airlied for that VGA/contrast commit
Tommeh: I still have flickering of my 2nd screen when booting/changing anything, but the contrast is right when it's in use and that's what really mattered.
twiztid: hello all =)
twiztid: could someone help with choppy video playback in web browsers? compiz is flawless and im using adobe flash 10
KotH: the main cause of choppy flash playback in browsers are the browsers
KotH: using about 5 to 10 times more cpu then would be necessary
twiztid: ive installed karmic on a laptop and pc both with nvidea cards and they dont have a problem... mine however is ati
twiztid: btw i appreciate your response, been having bad luck with help lately :/
twiztid: ive also been to hell and back with many different approcahes to this problem from forums and tutorials and so on..
twiztid: would Kernel Mode Setting (KMS) fix what ever setting is wrong?
twiztid: firefox runs better in WINE vs. natively, but still bad video streaming
twiztid: ive already enable pipelining and increased max.requests
twiztid: KOTH: ive also tried using the AMD Semperon build 'swiftfox' and it too doesent like to stream videos...
KotH: are teh cpu's comparable?
twiztid: of course... its the .i686 i believe
twiztid: can someone please help me with choppy video streaming in web browsers?
twiztid: ive tried countless workarounds and am here on last resorts...
edwin: twiztid: are you using the latest DDX driver?
twiztid: DDX, enlighten please?
edwin: xf86-video-ati
edwin: the xorg driver
twiztid: if its a recent update thats required manually no,
edwin: can you pastebin your Xorg.0.log?
chithead: many distros ship very outdated xf86-video-ati packages
edwin: twiztid: /var/log/Xorg.0.log, and paste it on pastebin.com, or a similar place, then give us the URL
twiztid: sure... 1 sec
twiztid: k
legume: Is the pm stuff in today's drt likely to change soon - is it worth filing a bug for glitching and not doing anything when two screens active?
twiztid: http://pastebin.com/ndh8KKbF
edwin: 6.12.99 thats not that bad
edwin: it is the RC for 6.13 I think
legume: On a separate issue - is it just me (AGP RV670) or has anyone else noticed that since dri2 vsync was forced on, mesa demos when maximised glitch when there is other output - like their framerate.
twiztid: ok, im still ubernoob but far from pc illiterate... let me know what i gotta do or read...
twiztid: ...so KMS isnt supported?
twnqx: mh?
twiztid: kernel mode setting?
twiztid: so how do i get 6.13? and what does it mean that dri2 vsync was forced on?
chithead: see if your linux distributor has a newer package
twnqx: also, what's your kernel?
twiztid: how do i quick check?
twnqx: 2.6.32-020632-generic - it's in the log
twnqx: i'd move to some 2.6.33 or ven 2.6.34rc to get KMS
twiztid: and as far as ubuntu that would be the lucid kernal within karmic?
twnqx: no idea about ubuntu
twnqx: i'm also not sure if that xorg server 1.6.4 matters
c1de0x: hi. I'm looking into possibly migrating to ati from my nvidia quadro nvs 440.
twiztid: so should i get rid of it?
c1de0x: i want to know if there is some ati card with 4 outputs which will allow me a single seamless x screen
c1de0x: ?
c1de0x: does anyone have a working quad-head single-screen setup?
twnqx: twiztid: no idea, i'd just upgrade everything
twnqx: c1de0x: there are 4port and 6 port ATI cards, but i'm not sure if this driver supports them
c1de0x: twnqx: which cards are those? is there any linux support for them?
adamk_: I believe you would need an HD5xxx card as all previous cards only have two CRTCs.
chithead: there is a radeon 5770 with 5 outputs from powercolor
adamk_: But I also don't know if they support 4 monitors with the open source drivers.
chithead: and radeon 5870 eyefinity6 with 6 outputs (but hot and expensive)
c1de0x: do the closed source drivers support single-screen?
c1de0x: do they support randr?
chithead: fglrx supports xrandr, for details ask in their channel #ati
adamk_: fglrx supports xrandr.
c1de0x: ok. let me check with them.
twiztid: twnqx: thx, ...one last q: what was edwin and legume reffering to? or need i worry if upgrading and enabling KMS solves whatever it was they were lookin at?
twnqx: c1de0x: http://www.engadget.com/2010/04/26/amd-firepro-2460-multi-view-four-mini-displayport-sockets-13w/
twnqx: (if you don't need massive 3D power)
chithead: firepro cards are way more expensive than consumer cards
c1de0x: twnqx: any idea if those cards are supported in linux?
c1de0x: and if i'll get my single screen?
twnqx: no idea.
twnqx: i'd guess you'll get it since it's 4 CRTC on one card
c1de0x: oh? nice.
c1de0x: is that card supported by the open source drivers?
chithead: it should work. be aware that at least two of the monitors need displayport connectors
twnqx: rather four... the card only has displayport :P
chithead: two can use cheap passive adapters
twnqx: uh, my displayport->hdmi adapter was 20€
twnqx: and the hdmi->dvi cable another 3
c1de0x: ok.
mjr: 20€? was it active?
chithead: active adapters start around 70 €
twnqx: it has electronics for level shifting, yes
chithead: if it has no external power source (usually usb) then it is not active
twnqx: so what powers the electronics inside?
Tommeh: would love four displayport screens and that card here. If only!
c1de0x: now if only they card were on sale!?
c1de0x: i'm happy to pay pro prices... this is for work...
twnqx: that's an announcement from two days ago
c1de0x: is there any other card which will do the trick for me?
legume: twiztid: Nothing I said was aimed at you.
chithead: c1de0x: powercolor 5770 eyefinity5 should also work
chithead: but I don't know any retailer in europe who sells them
twiztid: ok my bad, =P
twnqx: chithead: how could i tell if my laptop's displayport really requires an active converter?
chithead: you can have two non-displayport displays
chithead: these can be connected directly or via passive adapters
c1de0x: chithead: doesn't look like those powercolor cards are on sale yet either...
c1de0x: just announced a month ago.
chithead: they are listed in price search engines, but no shops have them in the catalogue yet
c1de0x: would the 5870 eyefinity6 card work?
chithead: yes. be aware that you need to run latest code from git if you want to use it with the open source drivers, and 2d/3d/xv acceleration is still being worked on
c1de0x: ok. but i'd get my 4 display single-screen?
chithead: yes, that should be possible
c1de0x: excellent. I'll pick on up now.
chithead: be aware of the displayport requirements
c1de0x: yup... i'm gonna need to convert to dvi and vga...
Tommeh: Wish I could just 'pick one up' :D
c1de0x: hehe ;)
mschaal: i'm runnung a evergreen triple head setup. stable so far, hence no acceleration
twnqx: the radeon can't just span multiple cards into a single screen?
twnqx: +driver
c1de0x: twnqx: ?
twnqx: i'ma sking
twnqx: i used multiple nvidia cards before
jcristau: that should work with xinerama afaik
c1de0x: hrm. if i have a minidisplayport to dvi adapter, is that dvi-d or dvi-i? i.e. can i use a dvi-i to vga dongle to go to vga?
Thunderbird: it is dvi-d
c1de0x: damn.
chithead: c1de0x: you need a displayport to vga adapter (these are also cheap)
c1de0x: chithead: ok.
Thunderbird: converters only work if analog signals are carried by the output
ezzieyguywuf: ok, so I'm pretty sure I've got my video card set up and configured properly using the Radeon driver. My problem now is that wine does not seem to like my openGL setup. Can anyone help me get this straightened out?
edwin: ezzieyguywuf: are you on 64-bit system?
ezzieyguywuf: edwin: no, I am on a 32-bit system
edwin: and what exactly doesn't it like (error message)?
ezzieyguywuf: edwin: let me pastebin it for you
ezzieyguywuf: http://dpaste.com/188568/ linen 14 is the culprit I believe
edwin: does glxinfo work?
ezzieyguywuf: edwin: yes. wanna see the output?
ezzieyguywuf: http://dpaste.com/188569/ <---glxinfo
edwin: are you on fedora? google turns up a lot of old fedora users with this problem
ezzieyguywuf: edwin: I'm on gentoo :-/
edwin: ezzieyguywuf: looks like this bug? http://bugs.freedesktop.org/show_bug.cgi?id=17328
ezzieyguywuf: edwin: I'll take a look
ezzieyguywuf: edwin: I don't think his fix will work for me, as I have a pure 32-bit system. How can I check to make sure I don't have these 64 bit libs installed?
edwin: well just check kernel version, drm version and mesa version
edwin: on 32-bit you won't have the 64-bit libs installed, so thats not the problem
edwin: but an old version of libdrm might be an issue
ezzieyguywuf: pastebin.com/iQXy0Xg7 here is what I got in my X log when I try to start WoW in wine
adamk_: ezzieyguywuf: Try setting LD_PRELOAD=/usr/lib/libGL.so.1.2 when you run wine.
ezzieyguywuf: this is the bottom of the file mind you, not the whole thing
adamk_: it's unlikely that anything would end up in the Xorg log file.
ezzieyguywuf: adamk_: well, looks to me like something got repeated there until I killed wine. that "unknown vendor specific block" and surrounding
ezzieyguywuf: ERROR: ld.so: object '/usr/lib/libGL.so.1.2' from LD_PRELOAD cannot be preloaded: ignored.
ezzieyguywuf: times about 10
adamk_: Well, where is your libGL.so.1.2 installed to?
ezzieyguywuf: good question.
ezzieyguywuf: I dunno! find and whereis don't return nothing
ezzieyguywuf: although I may just not be using find and whereis properly :-P
adamk_: Check the output of 'ldd /usr/bin/glxinfo | grep libGL.so '
ezzieyguywuf: libGL.so.1 => //usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0xb777a000)
adamk_: Bah... STupid gentoo.
adamk_: Alright, so LD_PRELOAD that library.
ezzieyguywuf: yea that seems silly
ezzieyguywuf: I remember when I was doin LFS there being a lot of controversy as to where to put X stuff though...
c1de0x: jcristau: you mentioned xinerama... i thought xinerama + randr == fail?
jcristau: c1de0x: and?
c1de0x: and as such, you couldn't use 'modern' drivers such as this one, or the nouveau driver with xinerama.
ezzieyguywuf: ok, I preloaded that library with no errors related to IT, but same errors in wine.
adamk_: ezzieyguywuf: Same "reverting to software direct rendering"?
adamk_: c1de0x: You just can't use xrandr to enable/disable monitors if you are using xinerma.
ezzieyguywuf: adamk_: yes
adamk_: But you can certainly still use xinerama.
ezzieyguywuf: err:winediag:X11DRV_WineGL_InitOpenglInfo The Mesa OpenGL driver is using software rendering, most likely your OpenGL drivers haven't been installed correctly
c1de0x: adamk_: oh. well that's not a huge deal!
c1de0x: woot...
adamk_: ezzieyguywuf: ..
adamk_: Not sure. That was just a shot in the dark as the LD_PRELOAD is required on FreeBSD, but I'd never seen it required on Linux.
ezzieyguywuf: hrm.
Thunderbird: the error means your 32-bit libGL setup is broken
adamk_: Except that glxinfo shows that it isn't :-)
Thunderbird: that was using a 32-bit glxinfo?
ezzieyguywuf: I know! so frustrating!
adamk_: Thunderbird: He's using a 32-bit installation of gentoo :-)
Thunderbird: we check several things first whether indirect rendering is used and if indirect rendering is used whether the X11 server is a local or remote one
Thunderbird: check the output of WINEDEBUG=+wgl (the first couple of lines are important) and post those to a pastebin
jcristau: c1de0x: you can use the driver, you just won't have the randr protocol extension
jcristau: oh adamk_ already said that..
c1de0x: ok. great ;)
adamk_: Heh.
ezzieyguywuf: pastebin.com/mmgbZibb <--- WINEDEBUG=+wgl
Thunderbird: I have just checked the code again but mesa is really giving software rendering if you get that error
Thunderbird: hm
ezzieyguywuf: apparently, that line 9 is misleading, as True means you do NOT have hardware acceleration
Thunderbird: when you get the winediag error, it is printed directly after line 9
ezzieyguywuf: Thunderbird: when I get that error it just spits it out right when I wine Wow.exe -opengl
Thunderbird: to be exact this is the check we are performing:
Thunderbird: if(!strcmp(gl_renderer, "Software Rasterizer") || !strcmp(gl_renderer, "Mesa X11"))
Thunderbird: ERR_(winediag)("The Mesa OpenGL driver is using software rendering, most likely your OpenGL drivers haven't been installed correctly\n");
ezzieyguywuf: well shux it seems to be done giving me that error.
adamk_: Except that GL renderer isn't software rasterizer in his debug outgput.
adamk_: lol
Thunderbird: sure but I guess a software fallback is triggered when wow is started
Thunderbird: attach the +wgl log of wow
ezzieyguywuf: I DID just trash my .wine folder in the hopes that that would fix it. This got rid of the registry tweak that did DisabledExtensions on openGL or some such
ezzieyguywuf: I can put that back in if you'd like.
Thunderbird: at startup wow uses directdraw (yes even in opengl mode for some info) and then moves to opengl perhaps something happens there which the drivers don't like
ezzieyguywuf: Thunderbird: you mean the full ouptut? that was the first few lines of it that I just posted
Thunderbird: it can be that a lot of lines later similar info appears again
Thunderbird: (in case of multithreading)
ezzieyguywuf: pastebin.com/GRyFQSb7 here is the full output
Thunderbird: likely you have to store the full log elsewhere as it will be huge
Thunderbird: it should be a log containing the error message
ezzieyguywuf: That last link has the full log.
ezzieyguywuf: does it seem truncated?
Thunderbird: it is abotu 1600 lines
ezzieyguywuf: Yea, I &> wine.debug and that file is 1568 lines
Thunderbird: the log doesn't contain the winediag error message, so it is not that useful
Thunderbird: reinstall wow
ezzieyguywuf: :-( A 5th time? lol. lemme re-do the registry tweak and see if that brings the diag error back. h/o
ezzieyguywuf: ok, still no error but nI have visuals now! still not running great though, but maybe trashing the .wine folder fixed at least this issue?
mjg59: airlied: Ok, I'll try to find one of those
mjg59: airlied: I haven't tested 500 and I haven't tested lvds, so who knows what could go wrong
mjg59: Hm. Looks like I got a lockup at 100x100 PutImage
mjg59: Not trivially reproducible.
mjg59: But does make me worry that there's still a case we're not catching
mjg59: airlied: Ah, ok. 500 uses the r100 pm path, and I haven't fixed that up
mjg59: Blim. General protection faults all over this place.
edwin: Thunderbird: I get this when trying llvmpipe with wine: fixme:d3d_caps:wined3d_guess_card No card selector available for GL vendor 4 and card vendor 0000.
edwin: Thunderbird: any workarounds?
ajax: mjg59: dcon was reliably exactly one line late, in that it would raise its interrupt pin exactly at the start of vertical back porch, just after vsync had ended
ajax: mjg59: of course, to do flicker-free handoff, you needed to do the transition during vsync.
mjg59: Awesome
Thunderbird: edwin, it is not that important (it is our gpu pci id detection code and more importantly video memory) you can set those in the registry
Thunderbird: I think we have a selector though, lets check
edwin: Thunderbird: it crashes afterwards
edwin: (in WoW)
Thunderbird: likely unrelated to that though (try setting the amount of video memory in the registry)
Thunderbird: see http://wiki.winehq.org/UsefulRegistryKeys
edwin: how much video memory does a software impl have?
Thunderbird: set a sensible amount e.g. 128MB or so
Thunderbird: what vendor is shown in the glxinfo output?
Thunderbird: oh, you are using llvmpipe
edwin: vmware
edwin: but same happens with swrast and classic mesa
Thunderbird: I think we default to 64MB ram
Thunderbird: what sort of crash are you seeing?
edwin: Thunderbird: the game crashes http://paste.debian.net/71049/
edwin: Thunderbird: and this one http://paste.debian.net/71050/
Thunderbird: no idea why it is crashing
edwin: failed to create drawable
edwin: also see this
glisse: agd5f: do you have any more patch like the one you did send ? about disabling accel on resume ?
agd5f: glisse: just those two
mjg59: agd5f: I read vblank start from D1CRTC_V_BLANK_START_END. It's 1086. I set VLINE_START_END to start at start-10 and finish at start-9 and enable vline interrupts. I get an interrupt at line 1043.
agd5f: mjg59: are you setting the interrupt for inside or outside the range?
mjg59: ...hm. That would be embarrassing.
mjg59: Let me try that the other way around.
mjg59: Yeah, think that was ok
agd5f: not sure. I'll see if I can find anything
shadowmaster: um. mesa's git master branch doesn't compile for me atm
shadowmaster: ( http://pastebin.com/VcubNuDc )
mjg59: agd5f: Let me check the register value when we're in the irq handler and make sure it's not awkward latency
mjg59: Nope. Only one line of latency.
agd5f: is it reliably early?
mjg59: No
mjg59: Let me check a bit more
mjg59: Just got one at line 409
mjg59: And one at 949
mjg59: Is the inside/outside control just the order of start/end?
agd5f: the interrupt can be set to the rising of falling edge of the vline IIRC
agd5f: *or
agd5f: then vline will be asserted for the range of the period
mjg59: Ok
mjg59: agd5f: I can see a bit for WAIT_UNTIL
mjg59: But not an obvious one for the irq - but the docs seem to be missing most of the vline registers
agd5f: that's for the CP stall for vline stuff
mjg59: Ah. Is it the same as r300? If so, it looks like I'm triggering when it's between start and end, rather than outside that
agd5f: mjg59: yeah, works the same way, IIRC
mjg59: wait.
mjg59: No, ok, I'm *not* turning off the crtc while waiting this time :)
mjg59: The vline status register is 0 when I hit the interrupt
mjg59: It actually looks kind of like it fires the moment I enable the interrupt?
agd5f: not sure. You might try setting bit 17 of VLINE_STATUS. that selects between level-based (0) and pulse based (1)
agd5f: before you enable the interrupt
mjg59: 17?
agd5f: yeah
mjg59: Ok, that may well explain things
mjg59: Which bits are start and which are end?
mjg59: I'd thought 0-14 and 16-30
mjg59: Which means I'm writing garbage
agd5f: 13:0 is start
agd5f: 16: 29 is end
mjg59: Oh, VLINE_STATUS
mjg59: Sorry, got you
agd5f: 31 is inside/outside selector
agd5f: you're on r6xx right?
mjg59: Right
agd5f: r5xx only supported level based ints so there was no bit 17 in the STATUS regs
agd5f: actually, looks like vline should be level based.
agd5f: you might try setting bit 17 in VBLANK_STATUS and trying vblanks again
agd5f: looks like pulse is the preferred method for vblank
mjg59: agd5f: Doesn't obviously help
agd5f: ok
agd5f: mjg59: what bits are set in D1CRTC_INTERRUPT_CONTROL?
mjg59: agd5f: At what point?
agd5f: doesn't really matter
mjg59: Ok, testing
mjg59: I'm back to trying vblank rather than vsync now
mjg59: agd5f: It's 0
agd5f: ok, good
mjg59: Now that's odd
mjg59: I don't seem to be getting vblanks at all
mjg59: This can't be right
mjg59: Oh, hang on.
mjg59: I bet this is hardware state I haven't cleaned up
mjg59: agd5f: Ok, so the current state of things is that with no further setup, I get vblank interrupts at somewhere between 1084 (2 lines before vbl) and 13
mjg59: 0 seems to be the most common
agd5f: weird. I dunno. I'll ask around internally
mjg59: I'll work around it for now
shadowmaster: 21
shadowmaster: oops.
oga: /act/wg 2
oga: shit.
mjg59: agd5f: I've added 0009-radeon-Try-harder-to-ensure-we-reclock-in-vblank.patch
mjg59: Which seems to leave things stable and attractive
agd5f: cool
mjg59: Eh. Except it's still sometimes missing vbl on exit
agd5f: could check current vline too
mjg59: Yeah, doing that now
agd5f: make sure we have enough time
mjg59: But I think I'm being a little too liberal
mjg59: THe problem is that being stricter means that we fail on most attempts to reclock
mjg59: We really need a more accurate indicator here
agd5f: I emailed the hw guys about it. I'll let you know what I hear back
mjg59: Awesome, thanks
mjg59: I'll try to dig up some mobile r500 after lunch
mjg59: And maybe an Evergreen
Obscene_CNN: dirthead, get your machine going yet?
eichi: hello ;) some interessing situation: if you know hedgewars, its a 2d worms clone. if i use it native with linux, i have invisible gamefield and much things are flickering or show strange things
eichi: if i use the same game with wine, i dont get any problems
che_: eichi, which version of hedgewars?
eichi: Hedgewars0.9.13 windows and linux
che_: i run 0.9.12 fine atleast
eichi: che_: its not a problem only with this game
che_: on a radeon hd4650
eichi: i have a generally graphical problem
che_: hmm well i also see textures missing in some games. e.g. in yofrankie the ground textures
che_: volumetric textures in ogre 1.7 sample browser also dont work but hmm most stuff shows here.
che_: what distro do you use?
che_: what versions of the stack x mesa kernel?
che_: and what card?
stringfellow: edwin: the most common reason for crashes like that in WoW is it not liking some caps, like e.g. MAX_PROGRAM_NATIVE_PARAMETERS
che_: lspci |grep VGA
kdekorte: HI All, I'm trying to test the new PM code on the rv635, I put radeon.dynpm=1 in the kernel line and see that PM is enabled, but according to debugfs, it never seems to downclock
kdekorte: in radeon_pm_info the state is PM_STATE_PAUSED does that need to be set to something else
kdekorte: or do I need libdrm from git?
mjg59: kdekorte: How many displays are you running?
kdekorte: 2
mjg59: kdekorte: Ok, you don't get any pm right now
kdekorte: :(
mjg59: It's... difficult to reclock in vblank when you have two displays
kdekorte: ok, and mine are also not the same display
kdekorte: any info I could give to help with the situation?
mjg59: An algorithm that allows us to synchronise vsync on different displays with no visible artifacts
kdekorte: mjg59, um... 42?
mjg59: Yeah. We basically don't have a good answer for this right now.
ajax: it's doable, it's just very very difficult
kdekorte: basically you need to calculate a common vsync for both displays based on the vsync of each display or can you align them?
ajax: it depends.
ajax: there's two variables:
ajax: the source clocks of the two crtcs, and the proper refresh rates of the two crtcs
ajax: if the source clocks are different, the refresh rates will drift relative to each other
ajax: if they were the same, they'd stay locked relative to each other, but they wouldn't necessarily be aligned
kdekorte: ok...
ajax: surprisingly, it's difficult to know when scanout _starts_ for a buffer.
kdekorte: I was just reading about the pm stuff and it is interesting to me because I have a fanless rv635 card and so PM would help it run cooler
ajax: anyway, my theory right now is that you modify the mode timings of one or both crtcs to slowly push their vsync times together
eichi: che_: arch linux
ajax: so you'd eventually downclock, even if not immediately
eichi: yeah yofranky flickers textures too ;)
kdekorte: ajax, so how long to sync them up... 5 mins 30 mins? or unknown at this point
ajax: kdekorte: don't know yet. i need to test on a few monitors to figure out how much timing variation they can tolerate without losing sync
kdekorte: is there a userspace app you could write to test with or pure kernel?
kdekorte: Also, I'm willing to test once you think you have something
ajax: i suspect it's on the order of 0.5%, so in the worst case where the pipes are 180° out of phase, 100 frames? bit over 1.5 seconds.
kdekorte: ajax, 1.5 sec ain't bad at all, hardly time for PM to kick in
ajax: it's pretty much something you have to test in-kernel, otherwise it looks like a mode switch and you do the full dpms cycle thing
ajax: and the whole point here is to drift the display timings without making the display glitch
kdekorte: ajax, right, I understand what you are trying to accomplish and realize that it is difficult to get right
ajax: if you can get both pipes driven from the same clock, then you're potentially in a really good position, because once you get them synced they're not going to drift relative to each other
kdekorte: especially for all the weird HW out there
kdekorte: additionally that would solve tearing when moving a window between displays
kdekorte: ajax, so once they are set do they drift anymore? If not perhaps you could just force it once when you bring up the displays... 1 flicker
ajax: if they're derived from the same source clock, then the only drift is from the innate difference in real refresh rate between the two modes.
MostAwesomeDude: So you're still best off with identical monitors.
ajax: eg, 1680x1050 rb is 59.88Hz, but 1920x1200 rb is 59.95Hz
kdekorte: what is the command to get that info?
ajax: cvt -r 1680 1050
kdekorte: I remember mine being weird
ajax: omit -r if you don't want reduced blanking timings
ajax: cvt is the LCD version too, use gtf if you want the CRT version
kdekorte: I have dual LCDs
kdekorte: 1280x1024 59.89 Hz & 1680x1050 59.95 Hz
kdekorte: so real close
ajax: so yeah, same clock source _and_ same mode timings on both displays would give you zero drift once they're aligned.
kdekorte: so the drift is something you have to keep adjusting while running
kdekorte: if different displays
Jonimus: cvt looks like it would make adding modelines easy, is that part of the xorg-utils?
ajax: % rpm -qf `which cvt`
ajax: xorg-x11-server-Xorg-1.7.1-7.fc12.i686
Jonimus: ahh so its part of the xorg group of packages
ajax: kdekorte: you don't really need to keep them perfectly aligned all the time. you probably don't want to, since that would mean waking up once every 10 frames or so
MostAwesomeDude: Hey, hey ajax.
ajax: vertical blank interval is never more than about 30 lines, after all
MostAwesomeDude: You should add ipers to the glxgears/glxinfo package. :3
ajax: MostAwesomeDude: mesa-demos
ajax: pretty sure it's in there anyway
MostAwesomeDude: ajax: That's everything though, isn't it? Even redbook?
ajax: it's a lot of stuff, yeah
kdekorte: the samples/wave demo doesn't look right on my rv635, the checkerboard is missing.. there is a FDO bug on it
ajax: so yeah, six wakeups a second to keep vblank aligned is probably not worth it, you'd be burning CPU watss to save marginal GPU watts
ajax: i think you want to just start drifting at GPU idle
kdekorte: ajax so I guess a max "drift" needs to be calculated and then resync before that max drift is reached
ajax: keeping syncs within 10% or so is probably okay, yeah.
ajax: meaning, within 1.6ms of each other.
kdekorte: just don't want it to drift out so that 1. you don't get a blank screen and 2. you can still enable PM
ajax: again, a lot depends on how tolerant LCDs are. if you can do 2% mode clock drift without glitching, 180° out of phase is 0.4 seconds.
kdekorte: ajax, and that is probably where the bug reports are going to come from.. non-tolerant hardware
ajax: it would help a lot if there were any way of discovering the LCD driver on the other end of the cable
ajax: naturally, there isn't.
kdekorte: of course not...
zhasha: that would be to easy
zhasha: too*
kdekorte: EDID doesn't have anything to help?
zhasha: E-EDID might
ajax: nothing i've seen, no.
zhasha: in the form of vendor specific blocks
kdekorte: other than creating a table of EDID id to LCD driver in the code
ajax: EDID usually describes the panel, not the interface chip
ajax: there are plenty of vendor-specific block possibilities, but in general, we don't know how to parse them
zhasha: well yes but you might be able to narrow it down if you can at least tell who made the panel
kdekorte: that however is a lot to maintain
kdekorte: probably should not be in driver either but some common lib or something
zhasha: quirk tables
kdekorte: wonder if there would be a way to "tune in" using input from a user.. like a test program that drifts out .. but again since this for multihead.. not sure it is worth all this
kdekorte: cause you know you'll get a bug report from someone with monitors from 1990 that it is not working
ajax: i suspect CRTs are more forgiving than LCDs, actually.
ajax: they're already inherently analog devices
kdekorte: I'm sure they are
kdekorte: I only have one CRT left in my house.. and that is a monitor I got in 2000
zhasha: ajax: I want you to imagine an AGP card, running with an off brand Chinese monitor, with a VERY cheap interface chip
zhasha: braces for impact
Jonimus: ajax: that is an understatement, I have a CRT that supports more modes than all of the LCD's in my house combined :P
kdekorte: zhasha, if there is only one display, this is not an issue.. you would need two cheap chinese displays with different resolutions
zhasha: anything + AGP = KABOOM!
zhasha: I wonder if AGP stands for A Grave Problem
Jonimus: lol
mjg59: agd5f: Engine reclocking seems to be working fine on r500
agd5f: weird. I wonder what caused the lockups for airlied
Jonimus: I might have to build d-r-t tonight to test on my r730 cards...
agd5f: kdekorte: you can still manually select power states using sysfs
mjg59: agd5f: The static code doesn't seem to wait for vblank?
agd5f: mjg59: nope
mjg59: Could be that, then
agd5f: there's no point for the static stuff. You are actively selecting it and you want to be able to do it for the multi-head case
Jonimus: agd5f: has anyone with a r7xx card testing it yet?
Jonimus: at least that you know of?
agd5f: Jonimus: works fine here
Jonimus: ahh kk, good to know
Jonimus: then I will def build on tonight
Jonimus: it*
legume: agd5f: Where in /proc is manual PM setting? drt is glitching in games again today & still misses vblank sometimes.
agd5f: legume: /sys/class/drm/card0/device/power_state or dynpm
mjg59: agd5f: Ok, memory reclocking also seems fine
mjg59: Same vblank issues
Jonimus: agd5f: do you think that once the reclocking is a bit more stable that overclocking will be supported?
mjg59: agd5f: Except we *always* miss vblank during mem reclock
mjg59: Could be that it needs the hardcoding stuff I had before
legume: agd5f: Thanks.
mjg59: I'll time how long it takes later on
agd5f: Jonimus: need to get the thermal stuff sorted out first
twnqx: would prefer blibless downclocking first :P
agd5f: twnqx: try d-r-t
twnqx: it's different from your patchset?
twnqx: i think what i have is pretty close to the pm2 branch
mjg59: agd5f: Seems to save about 3W on this rv530
mjg59: It'll be interesting to look at the voltage scaling
legume: agd5f: *ERROR* Invalid power state for multi-head: 1.0 is what I get if I try to force low power with TV enabled
mjg59: legume: That means that 1.0 is flagged as being valid for running with multiple CRTC active
mjg59: Sorry, invalid
dileX: cat /sys/class/drm/card0/device/dynpm
dileX: disabled
dileX: echo 1 > /sys/class/drm/card0/device/dynpm
dileX: will try that
edwin: stringfellow: GL_MAX_PROGRAM_NATIVE_PARAMETERS_ARB is zero with llvmpipe
legume: mjg59: OK - I only have 1.0 and 2.2, and from UMS experience I know it should be OK - With more messing around it seems I can now force it as long as dynpm is disabled first.
dileX: puh, X frozen
mjg59: dileX: What were you doing at the time, and what kernel tree are you running?
legume: mjg59: Hmm, more testing. Just turning off dynpm then setting low doesn't work - I have to turn off TV + dynpm, then set low then turn on TV and it stays low.
mjg59: legume: That's a bug
dileX: mjg59: 2.6.34-rc5-git8 + latest d-r-t pulled in. rv515 here. I started into init-3 with modeset=1 and dynpm=1. seems dynpm is diabled. started X and did the change via echo/sysfs and X frozen. my wlan-led was blinking
mjg59: We're failing to switch you back to high
mjg59: dileX: Did which change?
dileX: echo 1 > /sys/class/drm/card0/device/dynpm
mjg59: dileX: Hm. I think that might force a single static transition, which might break things.
mjg59: Try to make sure it's enabled before you start X
mjg59: legume: Your BIOS tells us that your chipset shouldn't run at that lowest speed while it has two outputs active
mjg59: legume: So if you can force it to have low speed while you have two displays active, that's a bug and we should fix that
dileX: compiled the kernel this morning (~10hrs ago). I started into init-3 with nomodeset. and wanted to load radeon k-m with kms and dynpm activated - got a blank screen. thats why I tried via grub-line.
mjg59: dileX: Ok. You might also want to grap patches 9 and 10 from www.codon.org.uk/~mjg59/tmp/radeon_pm
dileX: mjg59: OK, give it a try.
legume: mjg59: OK - more testing, the way to get low according to cat /sys/class/drm/card0/device/power_state is
mjg59: legume: I suspect I know how you're getting that, I'm just telling you that the fact that you can get that with two outputs is a bug and in future you will not be able to do so
legume: mjg59: turn off TV so dynpm sets 1.0, then disable dynpn and turn TV back on.
legume: mjg59: It's a pain - maybe fglrx and windows treat TV differently as I am pretty sure I don't get full clock just because I have TV connected with them - but would need to recheck to be sure.
mjg59: legume: Could you put dmesg somewhere?
legume: mjg59: Yea, but it will be full of pm changes from earlier when I was testing games - which have started glitching again.
mjg59: legume: Yes, that's fine
legume: mjg59: http://www.andyqos.ukfsn.org/dmesg-out-pm
mjg59: legume: Ok, so 2.0 is low-clock and supports multiple displays
dileX: mjg59: seems to work
dileX: mjg59: dynpm=1 via grub-line should work?
mjg59: dileX: radeon.dynpm
mjg59: Not dynpm on its own
legume: mjg59: Thanks, that works.
dileX: mjg59: modeset=1 here so I assumed dynpm=1
mjg59: Yeah, ne's interpreted by the core and one by the driver
dileX: how to acrivate drm debug mode via grub-line?
dileX: drm.debug=1?
mjg59: Think so? It's been a long time since I did that.
legume: mjg59: Spoke too soon - I was already @ 30000 if I am at 66900 then 2.0 doesn't reduce clock.
mjg59: What happens?
dileX: yeah, me too. thats why I prefer to start with nomodeset - unload radeon - (load drm k-m with debug option) - load radeon k-m with desired module-options
dafox: agd5f: hi, are you there?
legume: mjg59: Nothing apart from cat ... says 2.0 instead of 2.2
mjg59: Well, I'm not sure what the failure is
mjg59: What happens if you're using dynpm?
dileX: definitely it is now lesser "[drm] not in vbl for pm change 00000000 at exit" seen in dmesg
mjg59: dileX: Awesome
mjg59: dileX: If vblank actually fired reliably, this would work better
mjg59: With luck we can get something sorted with vline interrupts instead, but I haven't been able to get that working
legume: mjg59: Ugh - it does show 30000 if I do 2.2 first then 2.0 so I guess it was working just didn't display the change.
dileX: seems only to happen when I start and stop glxgears on dynclock change or 'xset dpms force off'
mjg59: dileX: It wouldn't surprise me that much if there's some sort of contention with the cp
dileX: mjg59: hope that horizontal flickering is gone - happens mostly on high cpu-load (kernel build with -j5)
mjg59: Yeah, the horizonal flickering should have been just from the engine reclocking
mjg59: Which should be vblank-synced enough
dileX: mjg59: good job - thanks!
dileX: hope your 0009 and 0010 patches go into d-r-t soon
mjg59: Once airlied is awake, with luck
kdekorte: Any news on the r600g front? I tried the code the other day, but only got a black screen with glxgears
mjg59: kdekorte: Pull d-r-t and add the extra two patches (9 and 10) from www.codon.org.uk/~mjg59/tmp/radeon_pm
kdekorte: mjg59, will that help dual screen?
mjg59: Well, with luck it'll refuse to do anything on dual screen
mjg59: So, yeah
kdekorte: So why would I want to try it?
mjg59: Because it shouldn't crash
kdekorte: It doesn't do anything now
mjg59: Or lock up
kdekorte: I don;t have either of those issues
mjg59: And because it'll land in mainline at some point
mjg59: So if it's broken, better to find out now
kdekorte: mjg59, ok... I'll try them
kdekorte: mjg59, if I disable one display with xrandr with dynpm on should pm then start working?
mjg59: Yeah
kdekorte: ok I'll give that a try with the new kernel
kdekorte: switching xchat to antoher machine
mjg59: airlied: Which patch did you think was killing your lvds?
mjg59: airlied: I've got things running acceptably on r500 now, though it could do with a couple of extra patches
Radioactiveman: Hello, I have to tell you that I'm really impressed how the driver support powerplay on r700 now
kdekorte: mjg59, I get some compile warnings.. radeon_pm.c line 288 and 289
evil_core: is r500 fixed too?
kdekorte: warning about ignoring returned result
mjg59: evil_core: Try with www.codon.org.uk/~mjg59/tmp/radeon_pm patches 9 and 10
mjg59: kdekorte: Yeah, ignore that
mjg59: evil_core: Add them on top of drm-radeon-testing
Radioactiveman: kernel 2.6.34rc5 and latest git packages, powerconsumption: fglrx 73W, radeon: 76W
kdekorte: if the PM patches work, I might be able to enable my radeon card in my T400 laptop.. it cooks in radeon, but ok with the intel card
evil_core: mjg59: ok, thx, but you now that old pm2 hanged GPU and system completely?
evil_core: I am not talking about some glitxhes, etc
kdekorte: Radioactiveman, what was the power consumption without dynpm?
mjg59: evil_core: Yes
evil_core: nad it should fix that?
mjg59: With luck
Radioactiveman: without: something around 100w
evil_core: heh
kdekorte: Radioactiveman, well about 25W is a decent savings
evil_core: how much 15" IPS uses?
Radioactiveman: can I disable om on the fly?
Radioactiveman: to see the real number?
evil_core: friends told me that buyinh 15" IPS is stupidity because IPS users power, but ton backlight uses that?
mjg59: Radioactiveman: Yeah
Radioactiveman: tell me how ;)
Radioactiveman: i mean pm ...
mjg59: echo 0 >/sys/bus/pci/devices/whatever/dynpm
kdekorte: What is a 15" IPS?
evil_core: Flexview/AFFS
evil_core: its not TN, its display for graphics
evil_core: and it works nicely for xterm ;)
Radioactiveman: hmm, I have sometimes screenflickering
evil_core: theres no vsync in KMS
mjg59: Radioactiveman: Yes, you will right now. We're working on that.
Radioactiveman: ok, nice
mjg59: If you check dmesg you'll probably see an error about not being in vbl
Radioactiveman: I make a restart, brb
Radioactiveman: [drm] not in vbl for pm change ..., yes
kdekorte: mjg59, REGRESSION...
mjg59: Do you mean regression?
mjg59: Or do you mean bug?
kdekorte: current engine clock is now 297000 with dual displays and glxgears running... default engine is 725000
kdekorte: memory clock is 495000 out of 500000
kdekorte: which is what it was before 9 & 10
kdekorte: engine was 700000ish before 9 & 10
kdekorte: and you said that with dual displays I should not see it at all
mjg59: What does dmesg say?
Radioactiveman: without dynpm: 105W
Radioactiveman: mjg59: you mean me?
mjg59: No
mjg59: kdekorte: Yeah, so you won't see any transitions
mjg59: I suspect we fail to restore clocks when a second crtc is enabled
kdekorte: And switching on a single display and running stuff, the clock does not bump up
mjg59: kdekorte: dmesg, please
kdekorte: mjg59, http://www.pastebin.com/WWkk6qLt
mjg59: Interesting. We request a state, but it never gets set
mjg59: Which would be consistent with two displays being active
mjg59: But there may be another cause
mjg59: I'll look into that later
kdekorte: ok, reverting out 9 & 10 and going to retest
mjg59: I can't see any good way that doing so could make your life better
kdekorte: everything is 20% slower with 9 & 10 in
dileX: if someone is interested in latest d-r-t against Linus-tree with mjg59 additional pm-patches
mjg59: kdekorte: I can't see any plausible way for that to be true
Radioactiveman: is there an advantage if I would use xserver 1.8?
mjg59: But I'll test
mjg59: Radioactiveman: No
mjg59: Not from a power consumption perspective, at least
Radioactiveman: sure, I mean general
Radioactiveman: performance, stability ...
evil_core: mjg59: only 9 and 10, can I apply everything?
mjg59: evil_core: Everything else is already in drm-radeon-testing
edwin: wow, new fglrx with xorg 7.5 support. guess I'll have something to compare r600 against... except I'm at xorg 7.6. They're one version late again :))
kdekorte: mjg59, hum... even though engine clock is low.. only thing really affected is some GL stuff
Radioactiveman: fglrx supports 7.6 if you rename it to 7.5
Radioactiveman: read here: http://bbs.archlinux.org/viewtopic.php?id=57084&p=72
evil_core: 9 rejected
evil_core: it doesnt apply against d-r-t
mjg59: evil_core: How does it fail?
evil_core: Hunk #1 FAILED at 289.
evil_core: 1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/radeon/r600.c.rej
evil_core: patching file drivers/gpu/drm/radeon/radeon.h
evil_core: Hunk #1 FAILED at 175.
evil_core: 1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/radeon/radeon.h.rej
evil_core: patching file drivers/gpu/drm/radeon/radeon_pm.c
evil_core: Hunk #1 FAILED at 387.
mjg59: Hm
mjg59: Oh well, I'll take a look later
kdekorte: I just applied 9 and 10 to d-r-t and it went clean
Radioactiveman: bye
dileX: kdekorte: yeah, even linus-tree w/ d-r-t worked well
evil_core: kdekorte: when?
evil_core: how to reset all to origin/drm-radeon-testing?
kdekorte: evil_core, best way to reset... git branch -D drm-radeon-testing; drm checkout -b drm-radeon-testing origin/drm-radeon-testing
dileX: kdekorte: switch to master first
kdekorte: dileX, good point
Droste: airlied: I just got two times the same kernel bug... is this radeon related or just coincidence? http://pastebin.org/190537
Droste: (latest drm-radeon-testing)
airlied: pushed latest two patches to d-r-t
mjg59: airlied: Thnaks
airlied: Droste: seems like a regression in d-r-t
Droste: airlied: what can cause this error? free()/kfree()?
evil_core: so maybe 'patch -R -p1 < `git diff -u`'?
dileX: mjg59: tried with radeon.modeset=1 and radeon.dynpm=1 in grub-line - worked
kdekorte: airlied, those patches seemed to slow down my rv635 with dual head setup..
evil_core: dileX: r500?
dileX: evil_core: yes. rv515
evil_core: ok, must try too
mjg59: dileX: \o/
mjg59: dileX: 515 is probably going to be a pain
dileX: $ dmesg | grep -i rv515
dileX: [ 10.532347] [drm] initializing kernel modesetting (RV515 0x1002:0x714A).
mjg59: The atom code for switching memory clock is too slow, but it's a different memory controller to r520
dileX: mjg59: I will kill this damn HP local dealer - he told me sth of 512M V(ideo)RAM.
dileX: I should taken a linux-live-cd with me
dileX: +have
mjg59: Oh, hey, turns out this is a 515 as well
dileX: thats the good side of rv515 - glisse mjg59 and other radeon devs have it :-)
evil_core: wtf, I got different copies od up-to-date d-r-t, with git diff -u drm-radeon-testing showing nothing; but different rejects with his patches :/
evil_core: ouch, 9 and 10 is upstream, right?
mjg59: Now, yes
evil_core: dileX: who cares about them, airlied got identical T60p with r500 like me :)
evil_core: it was reason I bought it too
evil_core: and I was reading about gallium and intel before
evil_core: and helped many persons with wine and needforspeed, got nvifdia then, and talked with intel players too
dileX: evil_core: hehe - "buy devz hard warez"
evil_core: so was bit dissapointed how crap is support for OpenGL in that ;)
evil_core: I would buy intel powered laptop, on one side its mistake I bought with radoen, bugt on second hand I wanted FlexView
evil_core: and I wanted then intell too because of longer battery life(didnt knowed about performance)
evil_core: but now I still would probablyt cxhoose FlexView one
evil_core: so cannot say I am damny unhappy
agd5f: airlied, mjg59: I'm getting an oops in radeon_bo_unref when I start X with d-r-t even with the dynpm stuff disabled
evil_core: and I dont need performance in reality, the worst is compatibility with wine(10+ yr old games) I play
evil_core: I would even live without them, and always used dosbox and znsnes, but they sucks battety as hell
agd5f: mjg59: is there enough time to do sclk and mclk in the same blanking period?
mjg59: agd5f: Yeah, plausibly not.
mjg59: Splitting that up would certainly help, but setting engine clock tends to be fast
evil_core: mjg59: need I to make clean?
mjg59: evil_core: TO be safe sure
mjg59: Ok, 515 sleeps for 2 milliseconds
mjg59: So it's going to need rewriting
evil_core: dynpm causes blackscreen
airlied: I think rv530 does that as well
evil_core: and caps reaxts after few minutes
evil_core: capslock LED
evil_core: dynclks=1 works, but it changes anything?
mjg59: airlied: Yeah, I've already got 520's approach rewritten
mjg59: But 515 has a different memory controller
evil_core: can I enable dynp,m using proc interface at any time?
mjg59: No
mjg59: THere's an interface in /sys
anv: I grew a beard until Radeon driver started work, (between february and april), and now it seems again that I have to start again growing, I hope it's not coming over belly before radeon works again
anv: last kernel 2.6.33.3-1 killed KMS in Arch
anv: :)>
Jonimus: anv: it works for me?
Jonimus: anv: what does modprobe radeon say?
anv: moment..
Jonimus: bets he has a typo'ed or invalid kernel cmdline arg
anv: nothing
anv: dmesg | grep firmware
anv: platform r600_cp.0: firmware: requesting radeon/RS780_pfp.bin
anv: platform r600_cp.0: firmware: requesting radeon/RS780_me.bin
anv: glxinfo | grep -i openglOpenGL
Jonimus: anv: install radeon_ucode
anv: IRQ's not enabled, falling back to busy waits: 2 0
Jonimus: I think it may still be in the aur but it may have been moved
anv: ok, I have source on my machine
evil_core: http://carme.pld-linux.org/~evil/radeon/pm2.dmesg
evil_core: dmesg is ncated there all the time
evil_core: I was able to start X, but after disabling dynpm trough /sys
evil_core: theres vsync, I got 50fps in glxgears
evil_core: yay, I got uit running, should be in logs
evil_core: but to low value for something and got fuzzy screen
evil_core: and even urxvt lags
evil_core: and mouse lags when running glxgears
anv: nope didn't help I tried with radeon_ucode installed KMS but no X
anv: black screen
Jonimus: anv: ok so is KMS working now?
anv: no
Jonimus: you installed radeon_ucode, rebooted and still nothing?
anv: true
anv: it didn't let start X
anv: ..or screen went just black
anv: monitor > no signal
anv: it worked partially with last official kernel but not with this new
Jonimus: does dmesg still have the errors about firmware?
Jonimus: if yes then your kernel26-firmware is out of date
anv: it followed new kernel26-firmware along new kernel today
Jonimus: anv: is the error still there then?
Jonimus: pacman -Qo /lib/firmware/radeon/RS780_pfp.bin
Jonimus: /lib/firmware/radeon/RS780_pfp.bin is owned by kernel26-firmware 2.6.33.3-1
anv: "modpobe radeon" nothing
anv: "modprobe radeon" nothing
Jonimus: I mean in dmesg
anv: dmesg | grep firmware
anv: platform r600_cp.0: firmware: requesting radeon/RS780_pfp.bin
anv: platform r600_cp.0: firmware: requesting radeon/RS780_me.bin
Jonimus: oh its not erroring about them not being there, its just telling you it is using them
anv: dmesg | grep radeon
anv: [drm] VGACON disable radeon kernel modesetting.
anv: [drm] Initialized radeon 1.32.0 20080528 for 0000:01:05.0 on minor 0
anv: platform r600_cp.0: firmware: requesting radeon/RS780_pfp.bin
anv: platform r600_cp.0: firmware: requesting radeon/RS780_me.bin
Jonimus: hmm ok, well kms should be working then
chithead: if you really had a 2.6.33 kernel it would also request R600_rlc.bin
Jonimus: chithead: he does
Jonimus: and I have the same one with no issues
chithead: no, dmesg doesn't mention this
chithead: that R600_rlc.bin is not mentioned in dmesg indicates that the kernel is earlier than 2.6.33
Jonimus: chithead: he has a 2.6.33 kernel
Jonimus: anv: how are you enabling KMS?
anv: I have HD3300 and tried with HD4350
chithead: on 2.6.33 you should see something like this: [ 0.496802] platform radeon_cp.0: firmware: using built-in firmware radeon/R600_rlc.bin
Jonimus: chithead!!! I know for a fact he has a .33 kernel now stop
anv: I understood it's inbuilt in kernel default and needs just disable by "nomodeset" if needed
Jonimus: anv: no its disabled by default
anv: oh in last it wasn't
Jonimus: add radeon.modeset=1 to your kernel line in grub and try again
anv: ooh I try it...
Jonimus: anv: they may have re-enabled it but if its not asking for that firmware then it must be disabled
Jonimus: chithead: it will only ask for that firmware when using KMS
anv: before ro ?
Jonimus: sure, I don't think it matters
Jonimus: but I have it right before in mine
anv: k soon...
evil_core: http://carme.pld-linux.org/~evil/radeon/pm2.dmesg
evil_core: it hangs with dynpm on r500
evil_core: its lastlog while hang
anv: ok didn't work tried in tty and it loads now modules, but even so black screen
Jonimus: anv: can you switch back to the tty?
anv: yes
Jonimus: and what DE do you use?
anv: no not after that black screen I had to reset
anv: Xfce4
Jonimus: hmm ok
Jonimus: do you have any of the X or 3d related packages built from -git?
anv: no
Jonimus: anv: do you have testing enabled?
evil_core: ok, I can finally play 2 1080p at once :D
evil_core: but Zeneck Glide wrappers still fails under KMS :/
anv: maybe
evil_core: so I cannot play Deathkrz
Jonimus: anv: if so your issue is not radeon related
Jonimus: read the Arch linux news
anv: no : core,extra ,community
Jonimus: hmm and X worked before the kernel update?
anv: true
evil_core: mjg59: did you looked over mine dmesg?
Jonimus: anv: can you ssh in after starting X to see if there are any errors in dmesg or xorg.0.log?
anv: no
Jonimus: and does X work without modesetting enabled?
anv: yes
Jonimus: then I guess your best bet is to not use KMS for now
anv: I try tomorrow with another card I had HD4350 but I'd need 3D quite soon because I work with Blender, thanks for this, until tomorrow then..
evil_core: GLSL still not ready for r500?
zhasha: evil_core: it works, we just have no (real) branching
zhasha: you can compile simple shaders
evil_core: I got "unknwn error initializing graphics" in nfshp2 with KMS
evil_core: and nothing strange in output
zhasha: oh, well it only works in the gallium driver AFAIK. Don't quote me on that though
zhasha: I can tell you for certain that simple shaders work, as I used it recently to compile and test shaders :)
evil_core: nfshp2 works in UMS
zhasha: that could be a different problem
zhasha: do you have any way of getting something specific?
evil_core: what means 'specific'?
evil_core: itsone machine. pne mesa version
zhasha: evil_core: I mean specific details as to what 'Unknown error' is
zhasha: even though I wish I could, I can't read minds
agd5f: airlied, mjg59: the bo_unref oops seems to be something in d-r-t. the dynpm patches on drm-next work fine with/without dynpm
airlied: agd5f: yeah I think its the gem handle cleanups
agd5f: airlied: I reproduced the lockup with power_state on my t60, looking at it now
airlied: agd5f: thats the dynpm off?
agd5f: airlied: yeah, echoing power_state to sysfs
agd5f: airlied: nope. got the bo_unref thing on drm-next too
airlied: agd5f: yeah the gem code is in drm-next
agd5f: mjg59: your 0009 breaks evergreen. different crtc reg locations
agd5f: should probably just move that cline check into the vbl check in radeon_pm.c
agd5f: *vline
agd5f: airlied: found the problem. enabling the gui idle int seems to cause the hang
airlied: agd5f: continuous gui idles? or just dead gpu?
agd5f: I don't know. maybe gui idle irq spam? I lose network
agd5f: I suppose the gui idle irq isn't strictly necessary. just make it a bit harder to change clocks
agd5f: as it may need to be rescheduled
agd5f: airlied, mjg59: http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-more-pm-fixes.patch
airlied: agd5f: tried the rv530 in dynpm mode?
agd5f: not yet. everytime I start X, I get the bo_unref oops
airlied: agd5f: oh wierd, I don't even to X with dynpm
airlied: oh no I do
airlied: I just get dodgy LVDS straight away
agd5f: airlied: it's that lowest power state that causes the problem with lvds. The others seem to work fine
agd5f: I bet it has some lvds flags or something
airlied: wierd to ship a laptop with a power state too low, maybe we need to change the lvds mode to lower refresh rate
airlied: agd5f: pushed that patch to d-r-t
agd5f: yeah, likely
agd5f: or some spread spectrum magic
agd5f: might be some weird feedback thing between the plls
agd5f: or backbias en