amarks: airlied: one reboot this morning and kms showed blurry text during boot, had to reboot to fix it, but couldn't immediately reproduce, i have a photo on my camera if you want to see
amarks: airlied: http://imagebin.org/73709
agd5f: airlied: sent
agd5f: sorry for the delay was waiting for the build to finish
ossman: agd5f, airlied, is suspend supposed to be working for r300?
agd5f: ossman: yes generally
ossman: agd5f, I'm not getting any output back
ossman: machine and the gpu seems to be working fine otherwise
soreau: ossman: Last time I tried it here on my rv350 it acts like it goes to s then instantly bounces back to r :P
yangman: ossman: no output on resume?
agd5f: ossman: get reg dumps before and after suspend
ossman: agd5f, radeontool's, or something more?
agd5f: ossman: yeah radeontool should work. from airlied's git tree
ossman: agd5f, DISP_OUTPUT_CNTL as well as CRTC 0's registers differ
agd5f: ossman: does regset to the pre-suspend values fix it?
ossman: let's see
agd5f: ossman: what output(s) are you using?
ossman: agd5f, s-video
ossman: restoring the regs did not fix it
ossman: hang on, missed one
agd5f: ossman: does s/r work with other outputs?
agd5f: ossman: any of the TV_* regs different?
ossman: agd5f, no idea about other outputs. haven't got anything else hooked up to it
ossman: agd5f, how is regmatch supposed to work?
Nightwulf|work: hi all
agd5f: ossman: it takes a wildcard
ossman: agd5f, for what? name? hex?
agd5f: ossman: radeontool regmatch '*'
agd5f: to dump everything
ossman: I generally just get a bunch of MC lines
ossman: agd5f, that tends to lock up the machine
ossman: [root@munin radeontool]# ./radeontool regmatch RADEON_TV_*
ossman: that's not how it works?
agd5f: ./radeontool regmatch TV*
agd5f: don't need the RADEON
ossman: confusing... some regs have the RADEON_ prefix, some don't
ossman: ok, so now I have the after values
ossman: let's reboot and see what they're supposed to be
ossman: agd5f, TV_HCOUNT and TV_VCOUNT are the only that differ
ossman: might be enough for the TV to lose sync though, I guess
agd5f: ossman: I think those are read only regs
agd5f: for getting the current h/v count
agd5f: so they will very with each dump
ossman: agd5f, you're right. they keep changing
ossman: the TV acts as if nothing is connected
ossman: so I'm thinking it has powered down that output
agd5f: ossman: suspend to ram or disk?
agd5f: ossman: can you diff radeontool regmatch '*' before and after resume?
ossman: last time I tried that it completely killed the machine, but I can see if it's different now with the s-video hang gone
ossman: Message from syslogd@munin at Dec 2 09:46:32 ...
ossman: kernel:Uhhuh. NMI received for unknown reason b1 on CPU 0.
ossman: Message from syslogd@munin at Dec 2 09:46:32 ...
ossman: kernel:You have some hardware problem, likely on the PCI bus.
ossman: Message from syslogd@munin at Dec 2 09:46:32 ...
ossman: kernel:Dazed and confused, but trying to continue
agd5f: ossman: guess there's some reg it doesn't like
ossman: agd5f, probably related to the s-video hang as it locks up in the middle of the CRTC 2 regs
ossman: agd5f, any way to force KMS to do a complete reinit?
agd5f: ossman: it does
ossman: odd that things aren't set up the same way then
agd5f: ossman: it only sets up what's active, things it doesn't need aren't touched and may have been set up differently by the bios at boot
agd5f: ossman: 90% if the tv-out setup is magic, so likely the problem is there, might be some gpio setup we aren't handling or something
ossman: agd5f, and how do we find the missing pixie dust?
agd5f: ossman: compare reg dumps
agd5f: you can skip the crtc regs
agd5f: see if that helps
ossman: is it possible to do regmatch with "everything except these"
agd5f: ossman: not that I know of
ossman: I'll have a look at it tonight
ossman: see if I find anything
agd5f: we should probably add a "all" option to radeontool to dump everything rather than just the defined regs, similar to the regs all option in avivotool
amarks: how busy should the X process be under kms with opengl effects?
airlied: amarks: gpu? if r600 with/without irqs?
amarks: the same rv790 without irqs
airlied: it'll be busy waiting a fair bit I expect without irqs
hifi: is the irq patch a silver bullet for r6xx/r7xx for something?
amarks: if i run top -d 0.5 -p
airlied: its the silver bullet that adds irqs
amarks: is this normal without irqs?
hifi: what do I gain with irqs
airlied: X and 3D apps don't have to busy wait
hifi: <- tech sawwy, but not at hardware level
airlied: they put the cpu to sleep and get an interrupt
hifi: was the patch at kernel level and not included in 3.6.32 yet?
airlied: yes and not in 2.6.32
airlied: since its well past feature merge
airlied: like 3 months past
amarks: so we are waking up X every time we want to do anything?
amarks: (wihtout irqs)
airlied: amarks: no X is waiting on the CPU bustily
airlied: busily (??)
amarks: so it's hogging the cpu doing what
hifi: hmm, someone have a ubuntu PPA for IRQ patched kernel? :)
airlied: amarks: waiting for the gpu
hifi: airlied: might it help for one app where background videos are sluggish and fast forward for a moment?
hifi: and input is laggy when it does that
airlied: not sure, it all depends on why X is waiting for the gpu
airlied: and how long it waiys for
amarks: how is the proposed irq patch looking?
airlied: well I merged it to my testing tree, will push it to -next later in week
hifi: and yes, I'm too interested when it'll be sent to 2.6.33 upstream
airlied: upstream process is simple, the merge window for features is open for 2 weeks after the kernel reelases
airlied: all features need to be ready before the merge window opens
amarks: ok so you plan to put this in .33?
airlied: yes thats the plan
airlied: any distro wanting to use kms will hopefully backport it
hifi: airlied: so the patch is already ready for the merge window, just waiting for it?
airlied: hifi: pretty close
Zajec: airlied: i pinged 3 patches you missed
Zajec: on dri-devel@
hifi: I hate compiling the kernel these days, it was much simpler when 2.4 was the big hit :/
amarks: airlied: one other question, my display is 2560x1600, i see a reference to 2048x2048 in a recent commit for xv?, just wondering if in general there are any particular limits with single head at this res?
airlied: Zajec: oh yes will do that tomorrow
airlied: amarks: depends on the gpu, all r600s should be fine
airlied: runs at 2560x1600 for a long time
amarks: airlied: ok cool, just checking
hifi: airlied: I didn't bug report this, but I'll say it to you here, RV740ish (HD 4650, I don't remember the exact chip) had corrupted Xorg with KMS, xrandring the resolution fixes that
amarks: airlied: did you see my kms blurry boot image?
airlied: hifi: corrupt how?
hifi: airlied: like all garbled, I'll get a cam shot later today if you want
hifi: the image repeats horizontally and is striped
hifi: when I use xrandr to change the resolution it all works after that
rah: corrupted like that?
rah: airlied: that's what I get with git
hifi: yeah, something like that
hifi: I just have a different background so it's hard to compare :)
rah: I get that with both kms and non-kms
airlied: file bugs with the pics so I can look later
airlied: looks like somrt sort of tiling issues
hifi: rah: did you try to change the resolution?
hifi: with xrandr
hifi: if it fixes it we have the same problem
rah: I haven't, no
hifi: something like "xrandr -s 1; xrandr -s 0" works fine if you use autodetected settings
rah: (I tried from the console but evidently changing the mode with kms from the console is a no-no)
amarks: airlied: i saw this http://imagebin.org/73709 once today only
hifi: rah: sleep 10; xrandr -s 1; xrandr -s 0;
rah: well, I would deal with it now but I'm a bit busy
hifi: sure, test whenever you can
hifi: but if thats a recent DDX regression I can trace it later today
airlied: amarks: wierd
eosie: MostAwesomeDude: pong, I test all of glean tests and they worked by the time I finished my latest work
MostAwesomeDude: eosie: Ignore me; there was a build problem. Looks like r300g didn't get much testing during the recent feature branch merges.
airlied: tries xorg st with r300g today, failed
MrCooper: airlied: been meaning to try that but not got around to it yet... how does it fail?
airlied: -retro doesn't render anything, running an xterm actually draws it (sw rendered I assume)
airlied: starting metacity moves the xterm but doesn't draw anything useful
MrCooper: fun :}
JohnDoe_71Rus: http://pastebin.com/m5a086c21 normal xorg.0.log DRI enable
JohnDoe_71Rus: http://pastebin.com/m477d5a3e try kms DRI
JohnDoe_71Rus: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
JohnDoe_71Rus: [dri] Disabling DRI.
airlied: the ddx isn't kms enabled
JohnDoe_71Rus: yes RS482 [Radeon Xpress 200M]
airlied: no i meant you haven't built -ati and/or libdrm with kms support
JohnDoe_71Rus: today update from
JohnDoe_71Rus: http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu karmic main
JohnDoe_71Rus: http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main
JohnDoe_71Rus: libdrm-radeon1 2.4.15+git20091201.8ffd2
JohnDoe_71Rus: libdrm2 2.4.15+git20091201.8ffd2
airlied: anything in dmesg?
JohnDoe_71Rus: now or when kms try?
airlied: when kms tries
JohnDoe_71Rus: http://pastebin.com/m5ff2600b dmesg kms
airlied: radeon: Unknown parameter `modeset'
airlied: no kms in that kernel
JohnDoe_71Rus: here said that the kernel does not understand option but should work
airlied: thats only at bootup
airlied: not when you load the module later
adamk: Hmmm... I just noticed that I can't get sync to vblank working here on my r500 though vblank_mode is set to 3 in .drirc... Thoughts? :-)
adamk: No errors, but glxgears gives me ~2500 fps
glisse: adamk: dri1 ?
Zajec: airlied: you commited IRQs without clarified issue of emited fences list
Zajec: airlied: does it mean that what I see is not a bug?
Zajec: airlied: could you explain it then, please?
adamk: Interestingly, openarena gives me roughly 61 fps, even if I set vblank_mode=0
adamk: So there's something odd going on here.
adamk: When I tried at home this morning under FreeBSD (DRI1, obviously), sync-to-vblank clearly worked fine with glxgears
MrCooper: adamk: vblank_mode doesn't do anything yet with DRI2
adamk: Well that might explain it :-)
JohnDoe_71Rus: kms in new kernel by default. or not?
honk: r600_cp: Failed to load firmware "radeon/R700_rlc.bin" <-- mhh.. shouldnt that file be committed to the drm-radeon-testing branch, too? =)
eosie: MostAwesomeDude: do you have an idea how to fix the CS overflow in r300g? When should we flush (and where)? In CHECK_CS or after emit_draw_xxx?
markinfo: I am trying to compile mesa drivers. On wiki is "./configure --prefix=/opt/xorg --with-dri-drivers=radeon,r200,r300 --disable-galliu" But where to start command "configure" in Mesa directory? there is no configure script. Only configure.ac
BioTube: replace configure with autogen.sh
markinfo: BioTube, wit the same parameters as above?
BioTube: you might want to add the swrast fallback and you only need the driver for your hardware
markinfo: I have ATI Mobility Radeon X1800, r58 I think
markinfo: or r520
BioTube: then you'll want r300
markinfo: o.k. then "./autogen.sh --prefix=/opt/xorg --with-dri-drivers=r300 --disable-galliu ?
BioTube: almost: --disable-gallium
markinfo: o.k. then "./autogen.sh --prefix=/usr/local --with-dri-drivers=r300 --disable-gallium ...for debian.
markinfo: make runs already - looks good. "sudo make install" causes that the compiled drivers are moved to /usr/local ? anything else?
markinfo: make runs.
BioTube: that should be it
markinfo: eh - compilation stopped with errors.
adamk_: You probably need to update your version of libdrm.
BioTube: you need a newer libdrm
markinfo: libdrm-dev? I have 2.4.15
Ghworg: git mesa requires git libdrm
markinfo: and xserver 1.6.5 is O.K.?
markinfo: will it be stable (usable) such system?
BioTube: the ddx is the only component that matters
markinfo: on the wiki is: latest libdrm from master branch 2.4.13+ preffered
markinfo: I have 2.4.15
adamk_: You still need to update libdrm :-)
adamk_: The wiki needs some work.
markinfo: with these all gits and sources - kernel, ddx, libdrm mesa ....I am going out of disk space - it is alreday over 1GB.
BioTube: for your purposes, you only really need a shallow clone
BioTube: git clone --depth 3
markinfo: "--depth 3
BioTube: it'll save space
markinfo: mesa takes 230MB ...can I now delete older commits?
BioTube: I don't know
Ghworg: markinfo: Run "git gc --aggressive", will compress all the git stuff down
markinfo: with !git --depth 3" has mesa instead of 240MB, 140MB
markinfo: hm - may be wrong - i did not started make still
eosie: MostAwesomeDude: nevermind, I've already fixed it
eosie: r300g is xmoto-compliant now ;)
adamk: Hey guys. Trying to help some slackware user get 3D acceleration going on an Xpress 200M. It should have worked just fine out-of-the-box, but he screwed some things up here...
adamk: I'm seeing '[dri] RADEONDRIGetVersion failed (libdri.a too old)' in his Xorg.0.log file. Any thoughts on what might cause that?
agd5f: adamk: sounds like slackware fail
adamk_: No, I don't think so. DRI works fine out-of-the-box on my x850, x1900, x700, radeon 9800.
adamk_: He started... Doing things...
adamk_: He's running 2.6.32-rc7, but also had parts of fglrx installed, including the libglx.so from ATI. That's been removed and xserver-xorg reinstalled.
agd5f: adamk: probably libdri leftoevers from fglrx
adamk_: Here, if you have any ideas: http://pastebin.com/m40a9d296
agd5f: adamk_: IIRC, libdri needs to be replaced as well
adamk_: Hmmm... Reinstalling the X server package *should* have put back the correct libdri, but that does seem like the best place to start.
adamk_: The log file doesn't even show Xorg loading libdri.so anywhere.
adamk_: Disable "dri" in his xorg.conf file.
kdekorte: I pulled drm-radeon-testing and noticed the r6xx interrupt patch was in there, but I didn't see the firmware R600_rlc.bin and R700_rlc.bin installed, appears they are not in the firmware/Makefile
kdekorte: Sent a patch to agd5f and airlied to hopefully fix this
agd5f: kdekorte: you need the firmware I sent the other day
kdekorte: it is in git
agd5f: to dri-devel
kdekorte: just not installed
agd5f: not in git
agd5f: you need to install it manually
kdekorte: I must have put them there then...
kdekorte: funny that switching branches in git and rechecking out drm-radeon-testing didn't clear them out
agd5f: kdekorte: git only hcanges tracked files
kdekorte: Any point to having the interrupt patch in the code, but not the firmware... would think they would both be needed to make it work
agd5f: kdekorte: you need both, but the firmware has a different license
agd5f: kdekorte: just put the ucode in /lib/firmware/radeon
agd5f: all kernels look there you'll be set
kdekorte: agd5f, yup I already did that...
Luzipher: agd5f: is there any way to put the firmware in-kernel ? (so I don't need an initramfs)
agd5f: Luzipher: not at the moment
Luzipher: agd5f: a pity but thanks for the info :)
kdekorte: agd5f, any plans to put the _rlc firmware in ihex format is put it into git? And if not why can the other files be there but not the _rlc ones
agd5f: kdekorte: the rlc firmware has a difference license.
glisse: Zajec: what's the issue
Ronis_BR: airlied: hello fellow, I still having problems with KMS and Radeon. Since it seems to work with default kernel suspend software, where you think the problem is? I have some intel video cards systems working well with tuxonice and KMS
Ronis_BR: I have seen some*...
mjg59: Ronis_BR: If it's working with the default kernel and failing with tuxonice, the issue is probably something that tuxonice is doing
Ronis_BR: mjg59: but tuxonice works with others drivers :)
Ronis_BR: mjg59: what isn't working is X after resume
Ronis_BR: mjg59: I can still use KMS, so I'm thinking it is something with radeon
Ronis_BR: because the X after resume is the grub background and a mouse
mjg59: If it works with the default kernel and fails with tuxonice, then tuxonice is doing something different
mjg59: It shouldn't be
Ronis_BR: but if tuxonice works with intel and doesn't with radeon, than it can be something about radeon :)
Ronis_BR: I don't know, just asking to see what people are thinking
BioTube: might be a memory issue
Ronis_BR: I'm updating my kernel with drm-radeon-testing from now to see
BioTube: radeon uses TTM while intel uses GEM
Ronis_BR: too many changes
Ronis_BR: BioTube: hum, I don't have a clue about what you have just said :)
BioTube: Ronis_BR: they're the memory managers each driver uses
Ronis_BR: ah, ok
yangman: Ronis_BR: what's broken?
MostAwesomeDude: Eh. Everybody uses GEM's ioctls.
mjg59: Ronis_BR: I can't really say this any more clearly, but: if it works with the stock kernel and doesn't work with an out of tree kernel patch, then the out of tree kernel patch is doing something different
Ronis_BR: yangman: resume with tuxonice
yangman: Ronis_BR: resume while tuxonice is running?
mjg59: yangman: tuxonice is an out of tree kernel suspend to disk implementation
Ronis_BR: yangman: resuming with tuxonice
yangman: oh. bah, brain fart
Ronis_BR: mjg59: I need it because it supports suspend to a file
yangman: I was thinking of the game
mjg59: Ronis_BR: You'll need to talk to the tuxonice maintainers
yangman: Ronis_BR: what mjg59 said
Ronis_BR: mjg59: that's why I'm asking here, to see if anyone has any opinions
Ronis_BR: mjg59: ah, btw, with uvesafb everything goes fine
mjg59: Ronis_BR: Yes. Ask the tuxonice maintainers.
Ronis_BR: well many things were commited to drm-radeon-testing, I'll try with this an after I'll ask tuxonice devs
Ronis_BR: an = and
BioTube: Ronis_BR: i'd also make sure to test whether it has the problem if you suspend without X running
Ronis_BR: BioTube: no problems
Ronis_BR: BioTube: the problem is resuming X
Ronis_BR: BioTube: it works perfectly if I shutdown X and suspend
Ronis_BR: and resume and start X
hnsr: was drm-radeon-testing rebased?
glisse: Ronis_BR: out of curiosity what you get when resuming with X? broken framebuffer ? weird color ? Black screen ?
glisse: btw i think you can suspend to disk with the stock kernel
ppman: what obvious thing am I missing wrt getting X to work
ppman: it's something I miss every time, and can never remember
ajax: use the knife with the black handle, and two goats.
ajax: that sure does look like a successful X launch to me.
ppman: all except the part where there's no X
BioTube: just a black screen?
BioTube: I've had that happen to me before
ppman: BioTube: not even
ppman: drops back to tty1
ajax: run 'X -retro'. if that draws the classic X stipple and cursor, then your session isn't launching correctly.
MostAwesomeDude: ppman: How are you starting X?
ppman: this happens every time I try this driver, once I figure the solution I should write it down..
ppman: MostAwesomeDude: gentoo, so /etc/init.d/xdm restart
BioTube: ppman: that's merciful: I had to go through all sorts of hoops to get visuals back when mine screwed up
virtuald: I thought the random dpms offs was fixed
ppman: ajax: failed to load module... lemme re-compile it
ppman: woah, nvm.. I had a xorg.conf in place I didn't want
ppman: X -retro works fine
ppman: so it's a kdm problem... thanks :D
blathijs: Argh, I could have sworn there was a bug report for an issue I've been bisecting, but I can't find the report anymore :-S
blathijs: Ah, found it. It was marked fixed, apparently :-)
blathijs: Funny thing is that I've bisected to a commit that's not in 6.12-branch, while 6.12 branch also seems broken
blathijs: Let's do some more bisecting :-)
amarks: hmm noticed this
amarks: [ 3028.620904] [TTM] Failed moving buffer. Proposed placement 0x00060004
amarks: [ 3028.620908] [drm:radeon_object_list_validate] *ERROR* radeon: failed to validate.
amarks: [ 3028.620911] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
airlied: Zajec: no you can keep asking about the bug in irqs
airlied: just because I merge something doesn't mean its finished, jsut that it works well enough here
airlied: and I only merged it to -testing I thoguht
Zajec: where changing mode starts in KMS?
airlied: Zajec: which change? from X or fbcon?
Zajec: airlied: err, any
Zajec: airlied: i need to disable PM every time we change modes
kdekorte: airlied, do you have any idea when a F12 kernel will come out that supports R6xx IRQs?
Zajec: hm, maybe drm_crtc_helper_set_mode is a tip
airlied: Zajec: yup there
airlied: kdekorte: I have to package the firmware for it F12
airlied: then wait until that is is in the distro, then bump dracut-kernel I thknk
airlied: so not this week
kdekorte: airlied, fair enough... thanks for the update. I'm using drm-radeon-testing on rv635 and so far it is going well
airlied: its in rawhide already
kdekorte: airlied, in kernel-2.6.32-0.63.rc8.git2.fc13? It wasn't clear from the notes that IRQs were included in that
airlied: oh the firmware is in, I can add irqs to kernel now
airlied: I forgot what I'd done
kdekorte: for the kernel-firmware for f12 (latest in koji) the firmware is not in there
kdekorte: Doesn;t appear to be in the F13 version of kernel-firmware either
airlied: kdekorte: in f13 its in xorg-x11-drv-ati-firrmware
airlied: can't put it in kernel
kdekorte: licensing huh... ok... probably will need to blog that somewhere... cause a lot of people miss mesa-dri-drivers-experimental
kdekorte: There was a post today on Fedora planet about using fglrx on F12... I just cringed as I read it
ajax: i kinda want -experimental to go away soon
kdekorte: I don't see why it can't go away now.... r6xx mesa is pretty stable
kdekorte: I'm using mutter as my window manager just to test how r600 works
airlied: yeah we should remove -experimental for r600 and add nouveau ;-)
airlied: kdekorte: the fw will be automatic once done
airlied: I just need to add a depend to dracut-kernel I think
kdekorte: airlied, ok that is good to know
airlied: it works for every other device in history
kdekorte: BTW, I tested m AGP Radeon 9200se the other day and had some funny colors in glxgears
airlied: loves how ppl are all "this is a showstopper it must be reverted" when it was reverted already
agd5f: Zajec2: what's the problem you are having with irqs?
airlied: kdekorte: yeah I think the flushing is messed up the colors
airlied: kdekorte: my r100 does the same I started fixing it, I should probably check it again
kdekorte: I don't sit at the machine, so it does not bother me, but I'm sure it will come up somewhere... card is in my fileserver
Tanktalus: git commit f03450796d2e9247a1228c4e2abb1dfad7aecddf ... and I get radeon_dri2.c:339: warning: implicit declaration of function ‘drmGetDeviceNameFromFd’
kdekorte: Tanktalus, upgrade libdrm
Tanktalus: That function isn't declared anywhere that I can see ...
agd5f: Tanktalus: need newer libdrm
Tanktalus: oh, ok.
Tanktalus: hmm... I'm already at 2.4.15 ... the newest that gentoo seems to have.
kdekorte: you need it from git
kdekorte: probably libdrm-9999 or something
Tanktalus: yeah, if it exists, it's not in any overlay I currently have installed. But I can look elsewhere for it, or even create it myself. Thanks!
gimzo: today's git gallium works very nice on my r400... only problem is 3D apps lock up on exiting, so I need to vt-switch and kill them
MostAwesomeDude: gimzo: Wait, lock up *everything*, or just the app?
Ghworg: We could really do with a release of libdrm, to coincide with mesa 7.7 would be ideal
Zajec2: osiris_: can you check http://bugs.freedesktop.org/show_bug.cgi?id=25193 ?
chithead: and xf86-video-ati
chithead: Zajec2: it has been reverted in mesa 7.7 branch today
gimzo: MostAwesomeDude: just the app, but it's fullscreen so I can't see below it, but I can normally switch to console and kill it, then everything works
Zajec: chithead: ah, should be noted in report
chithead: Zajec: http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_7_branch&id=e84dddde9b6eb7727760814ae211c95218bb28a3
Zajec: yup, i see
kdekorte: Is there any power management in R500 KMS?
MostAwesomeDude: gimzo: I would appreciate a bug report.
MostAwesomeDude: Also see if you can run it windowed and/or in gdb.
Zajec: kdekorte: short be very doable after i get r6xx/r7xx working
Zajec: kdekorte: r5xx is also AtomBIOS
gimzo: MostAwesomeDude: ok, just where do I fill it, redhat bugzilla ?
Zajec: kdekorte: for now I think it only disables unused blocks
Zajec: kdekorte: no reclocling
gimzo: MostAwesomeDude: and what should I do with gdb ?
Zajec: and actually I believe to have working fully reclocking right now :) rebooting to test it :)
amarks: airlied: i did not notice you reverted it, thanks
kdekorte: gizmo, attach to the pid and then backtrace?
gimzo: kdekorte: ok, thanks
Ronis_BR: does drm-radeon-testing is now for kernel 2.6.32?
Ronis_BR: I got tons of conflicts on 2.6.31...
kdekorte: gizmo, probably want to attach before it crashes
MostAwesomeDude: gimzo: fdo bugzilla, please.
kdekorte: Ronis_BR, I found I had to delete my local branch and then re-checkit out
gimzo: kdekorte: it doesn't crash
gimzo: MostAwesomeDude: ok
MostAwesomeDude: gimzo: If you can find where it's getting caught up...
MostAwesomeDude: What app is this?
Ronis_BR: kdekorte: what?
gimzo: MostAwesomeDude: I'll try, openarena, tremfusion and xbmc all lock up
gimzo: glxgears does not :D
MostAwesomeDude: Oh, is 64kb the correct size limie to pass to radeon_cs_create?
kdekorte: Ronis_BR, I had merge problems with drm_radeon_testing so I deleted the local branch, git branch -D drm_radeon_testing and then rechecked it out git checkout -b drm_radeon_testing origin/drm_radeon_testing
Ghworg: drm-radeon-testing had a forced push I believe, which can cause some problems unless you do a forced fetch
Ronis_BR: kdekorte: but with linux2.6.31.y right
Ghworg: I did git-pull --force then git-reset --hard and it sorted it for me
kdekorte: Ronis_BR, I just use the whole branch, and the new kernel is 2.6.32-rc8
Ronis_BR: kdekorte: what branch are you using? I'm using linux 2.6.31.y
Ronis_BR: kdekorte: do you have git address?
kdekorte: I'm using airlieds drm-next branch. git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
taiu1: agd5f: do occlusion queries work on all r6xx now or are some of them still problemaitc?
Ronis_BR: kdekorte: ah, I can't do this because tuxonice, I need the official branch
airlied: taiu1: one of the rv7xx is still messed up
airlied: agd5f: we need to dig out smoe more info on rv740 tiling stuff
airlied: I suspect it isn't the same as rv730 which we mostly say
agd5f: taiu1: they work on everything but rv740 which only reports for half of it's pipes for some reason
Ronis_BR: does anyone know how to upgrade from linux.2.6.31.y to the newest kernel?
taiu1: ahh, ok i get may opengl20 manually for now then ...
lowkyalur: hi all. how do i fix r300VertexProgUpdateParams:Params exhausted when using wine and a 3d app?
kdekorte: lowkyalur, Thought that was a wine bug...
lowkyalur: kdekorte: sure, that's why they sent me here. aw...
kdekorte: lowkyalur, what program are you using in wine
eosie: MostAwesomeDude: it should be, 64kB is the size of an indirect buffer
lowkyalur: kdekorte: that's perfect world
lowkyalur: kdekorte: inits the graphics fine, but crashes after a second or so... as soon as it starts shoving the tree leaves and things up the vram
eosie: MostAwesomeDude: I can asure you that the driver can utilize all of it without a problem
MostAwesomeDude: eosie: Yeah, I'm just going over some notes and making sure I didn't miss anything.
eosie: well, except the CS overflow
gimzo: gdb question: I'm installing debuginfo packages, and mesa-debuginfo gets installed, but I'm using self-built mesa in /opt, not the system one.
jcristau: that's not a question :)
gimzo: ok, the question is: is that ok ?
jcristau: gdb will just ignore the debuginfo that doesn't match, afaik
jcristau: so, yeah
gimzo: ok, thanks
eosie: MostAwesomeDude: today I've fixed two issues in r300g, do you wanna see my patches?
MostAwesomeDude: eosie: Sure.
eosie: MostAwesomeDude: http://storm.unas.cz/eo-02.tar.gz
MostAwesomeDude: eosie: They both look good, but I just re-wrote those areas of code. If you want to get credited in the log, could you fix your patches?
MostAwesomeDude: I can do it, if you're busy.
eosie: I'll do it
eosie: MostAwesomeDude: you can remove r300_lacks_vertex_textures, it can be NULL (commit debc0b6fa8ce110eb suggests that)
eosie: or it doesn't matter
gimzo: MostAwesomeDude: I see some updates on r300 in mesa master, should I update before reporting bugs ?
eosie: MostAwesomeDude: here: http://storm.unas.cz/eo03.tar.gz
eosie: MostAwesomeDude: also, there is missing #include "r300_texture.h" in r300_context.h
yehia: i have ati radeon hd 3200 and fedora 12, and i have some issues
agd5f: yehia: using a GL compistor like kwin or compiz?
yehia: now I do, but the problem started even before ...
yehia: some examples, in red rectangles
yehia: I tried to get some more pictures, but I couldn't ....
yehia: I just hope this is enough to get and idea about what I mean ..
yehia: sometimes it's even worse than what you see in the picture ..
eosie: MostAwesomeDude: here: http://storm.unas.cz/eo04.tar.gz
yehia: and sometimes I get some horizontal lines here or there ...
agd5f: yehia: link doesn't work. likely a mesa bug. does disabling GL compositing fix the problems?
yehia: no, It occures even when I disable GL ...
osiris_: airlied: I've seen you've reverted "radeon/r300: no need to flush the cmdbuf when changing scissors state in KMM mode"
osiris_: airlied: any ideas why would it break r600?
airlied: osiris_: not off hand, it was just obviously causing pain
yehia: does the picture appear ?
agd5f: yehia: https://bugs.freedesktop.org/show_bug.cgi?id=25346
osiris_: airlied: are you aware of any other regressions or texture bugs?
agd5f: yehia: something with kwin
airlied: osiris_: that was the only one ppl made enough noise about that I had to go look ;-)
agd5f: or maybe related to that exa pitch patch
airlied: I'll see if I can figure out why r600 needs that
agd5f: airlied, osiris_: r600 doesn't emit scissors when emitting colorbuffer. might be related
yehia: @agdf5 : thank you very much ... that's pretty the same ...
agd5f: they are separate states
yehia: but is there some way I can get around it ?
agd5f: yehia: not sure what causes it yet
agd5f: yehia: did it used to work?
yehia: nope ...
agd5f: why is kwin such a botch. everything seems to break it
gimzo: doesn't that make it a good testing tool ?
chithead: depends on who does the Right Thing™
yehia: thank very much you for your help, I'll go now ...
airlied: agd5f: ping
agd5f: airlied: pong
airlied: that patch you sent yesterday, should the USE_REF_DIV be outside the atombios chec?
airlied: it appears to move it inside
agd5f: no. pll->refernece_div doesn't get set for atom IIRC
airlied: the atombiox_crtc code sets it as well for non-avivo
airlied: which might be a bug then
agd5f: yeah, that should be removed too probably
airlied: we have code to set refernece_div
airlied: in radeon_clocks.c
Tanktalus: kdekorte / agd5f : thanks, got git libdrm, and now git xf86-video-ati compiles cleanly.
agd5f: airlied: I dunno
agd5f: airlied: lets see what the ddx does
agd5f: airlied: ddx appears to use it
amarks: agd5f: i'm not seeing 25346 anymore, something fixed it
airlied: agd5f: so move it back outside the check?
agd5f: airlied: yeah
airlied: agd5f: that guys laptop still resumes funny, but at least the pll numbers make some sense now
agd5f: airlied: although I wonder is that is why r4xx mobility chips always have so much trouble with lvds
airlied: yeah maybe I shuold leave it out for now and see if anyone gives out
agd5f: airlied: you might try removing lines 184/185 in radeon_legacy_encoders.c too
agd5f: that might be problematic on resume
agd5f: since it selects fb_div 0 which the driver doesn't set
airlied: agd5f: och
airlied: I totally missed that line
airlied: maybe I should reprogram fb div 0
agd5f: however, some r4xx lvds don't seem to work with the plls we choose, so that selects what the bios programmed
airlied: agd5f: maybe since you fixed other stuff they'll be happy now ;-)
agd5f: airlied: maybe lets try this? http://www.botchco.com/alex/xorg/0001-drm-radeon-kms-further-r4xx-lvds-fixes.patch
agd5f: in addition to my patch from yesterday
airlied: yup I'll build him a kernel to try
erik_____: if I get OpenGL renderer string: Software Rasterizer when running glxinfo is something wrong with my setup?
BioTube: erik____: usually
erik_____: I get OpenGL renderer string: Mesa DRI R600 (RV770 9442) 20090101 TCL when i run it as root
erik_____: any ideas what could be wrong?
BioTube: what's the output of 'ls -l /dev/dri'?
MostAwesomeDude: Just got another hardlock with my RV410. Should I see if I've got an r300 to switch to instead?
MostAwesomeDude: was fairly certain his r300s were AGP
erik_____: BioTube: crw-rw---- 1 root video 226, 0 3 dec 00.28 card0
erik_____: ahh thanks
erik_____: not in the video group
BioTube: happy to help
soreau: BioTube: Why the CamelCase?
BioTube: soreau: why not?
soreau: No reason, just curious why
BioTube: i just prefer it
BioTube: just was too lazy to fix the program
Soreau: Nah, doesn't feel right ;)
airlied: MostAwesomeDude: I should probably bring my rv410 in from home
MostAwesomeDude: airlied: In the meantime, lemme dig through the Box o' Cards and see what I've got. I know I've an RV280 PCI at least.
airlied: bah still no xorg st workee
soreau: last time I tried it, X just segfaulted immediately
airlied: it starts now and doesn't really render anything
MostAwesomeDude: airlied: Just checked. I've got an RV280 PCI sitting out in my server, and somewhere around here there was an RV350 AGP but this board doesn't have a slot for it.
MostAwesomeDude: Oooh, I know where it is. Doesn't help me though.
MostAwesomeDude: I think I'll take this X1650 AGP and try and obtain the PCIe version with clever return hax.
FergatROn: This is amazing.. I didn't know this channel existed. I have an issue with my on-board ATI video port. I have a BioStar TA690G AM2 5.x and I can't get X to run properly in my Fedora 11 x86_64 partition. When I load it with the "radeon" drivers, it looks like 8bit colors and the image is fuzzy and titled. Virtually unusable.
MostAwesomeDude: FergatROn: Could you upload your Xorg.0.log to a pastebin?
airlied: it might be worth trying F12 liveCSD
airlied: we did a lot of work in F12 that F11 just won't see
FergatROn: crap MostAwesomeDude i'm in my windows partition. What's that tool that allows windows to see ext3 or LVM partitions?
MostAwesomeDude: FergatROn: Don't worry about it; I just wanted to see which video chipset you had. I do agree that an F12 liveCD should work a lot better.
chithead: for opening ext3 on windows there exist ext2ifs or e2fsd
MostAwesomeDude: Ugh, X1250 which is IIRC RS690.
FergatROn: MostAwesomeDude @airlied I'm torrenting the LiveCD now.
MostAwesomeDude: FergatROn: No problem. I'm not exactly sure why your video tweaks out like that, but if F12 still has the problem, I think we would like to know.
Zajec: agd5f: are you still awake?
Zajec: agd5f: could you check if you can help me with mode setting detection? (dri-devel@)
Zajec: just posted
rehabdoll: i just bought a new card, 4770. Im experiencing some new icon-corruption with qt-apps. driver is 6.12.4 and drm is from 22.214.171.124. fixes in git perhaps?
Vash63: Is there a known fix for the KWIN OpenGL issues in DRI2 lately? Been happening for over a week now.
Vash63: Just redraw issues.
airlied: get latest mesa 7.7 branch
Vash63: Ah, have to switch branches? I've just been compiling from master.
airlied: pull 7.7 into master, someone shuold do that in the next few days
Vash63: Ok, cool. Performance for 2d stuff has gotten a lot better lately. Pretty happy now overall.
edt: git revert 286bf89e5a1fc931dbf523ded861b809859485e2
edt: on master should fix it
edt: its the same fix as was applied to 7.7
flyback: can you tell me if there is any rage open source drivers
flyback: like point me to the right channel
flyback: I know we went over this before a little but radeons are too pricey and big for what I want
airlied: rage what?
flyback: rage pro LT
airlied: is that mach64 or e128?
airlied: r128 e
flyback: small fanless card with tv out which is what I am looking for
flyback: mach64 core for 2d afaik
airlied: should work with -mach64 then
airlied: I think m64 tvout worked at one stage
flyback: hmm didn't think of that
airlied: though I suspect a 32MB radeon 7000 would be a beter investment
flyback: cause that's pretty damn cheap for projects driving small portable dvd players with analog input
airlied: or 64MB one
flyback: too big and expensive for this
flyback: you are talking about lcd's with a native res of 480x234 or 800x480 at best
flyback: for a normal crt or lcd yeah for sure I wouldn't even look at < radeon
airlied: seems cheaper
witukind: Hi, what are the requirements for KMS with X.org ? I got KMS working on the console but it doesn't seem to work with X
flyback: HOW COME THAT DIDN'T COME UP IN MY SEARCHES
flyback: bangs head into cement
flyback: thx airlied
airlied: flyback: granted it might go up by the time it finsihed selling
flyback: yeah might be a tad big too
airlied: witukind: see the page in the topic
flyback: but I can use it for experimenting
flyback: so I will get it
flyback: na the other card is cheaper fixed price $12
witukind: I just read that page carefully, I've got Linux 126.96.36.199, xorg-server 1.7.2, libdrm 2.4.15, Mesa 7.6.1-rc2, and I tried with either xf86-video-ati 6.12.4 and a clone of git from an hour ago. When I tried with the git clone version, my box locks up.
airlied: witukind: for -ati git you need libdrm git
airlied: and 6.12.4 won'tdo kms at all
witukind: airlied, yes I saw that, that's why I compiled 6.12.99 just a few minutes ago but my box just locks up when I try to load X with that
flyback: you know what though
flyback: i'll bid low
flyback: if I lose then I will just buy it now the other
flyback: thx a lot airlied
witukind: ah damn so that's the missing thing, I need a git libdrm...
witukind: ok thanks
flyback: yeah I got outbid already
witukind: If I update libdrm, do I need to recompile the DDX and Mesa again ?
airlied: witukind: ddx at least in this situation
airlied: make sure you --enable-radeon-experimental-api in libdrm
witukind: airlied, I didn't forget that :)
witukind: ok done, let's try (crosses fingers) ^^
witukind: hurray, works perfect :D
witukind: thanks again
witukind: strangely my desktop feels faster than before now... I was expecting it to be slower