MostAwesomeDude: I'm going to BE A MANLY MAN and fix my r200's KMS rendering, which is kinda funky.
mancha: ears perk up - i use r200; elaborate! :)
MostAwesomeDude: 1) The default mode on my test monitor, 1024x768@60, is warbly-wavy and shakes very badly. Switching down to 800x600@60 fixes it. Any hints? I was going to look at bandwidth measurements.
MostAwesomeDude: 2) Gears misrenders so badly it's kinda funny. Acidgears. My rv280 is fine though.
mancha: how many beers did you have this evening?
mancha: i ask because in my case i've noticed gears starts misrendering at the 7th beer :)
airlied: MostAwesomeDude: the real r200?
agd5f: MostAwesomeDude: probably timing related rather than bandwidth
Jonimus: Should I worry if my HD4850 is idling at 92C?
Jonimus: and it has been for a long long time.
Nightwulf|work: hi all
MostAwesomeDude: airlied: R200 QH.
MostAwesomeDude: 7500? Or was it 7200? I need to stick it in again.
airlied: 8500
MostAwesomeDude: That sounds more right.
MostAwesomeDude: I've tested almost a dozen cards in the past 24h; can't keep them separate in my head. :T
airlied: has an 8500LE in a test box in my lab, but no time to look at it
airlied: but at least I'm trying to keep all those rn50 users happy
MostAwesomeDude: Sure, sure. That's why I'm trying to step up.
airlied: I think the only real evil thing on the r200 is emitting texture units in pairs, I think it also chokes CS checker
agd5f: MostAwesomeDude: the CS checker needs love. textures had to be emitted pairwise on r2xx even if you were using an odd number for example
MostAwesomeDude: agd5f: That's kind of screwy.
airlied: hw bugs ftw
MostAwesomeDude: Infinitely preferable to trying to e.g. fix matrox.
MostAwesomeDude: Oh, goodie, CP isn't initing after AGP fails to bind. Let's do the agpmode dance.
Jonimus: Woo AGP
MostAwesomeDude: Grr. 1024x768@60 is not matching either the gtf or cvt timings. :T
airlied: MostAwesomeDude: there was some typos upstream we fixed
airlied: though I thought -60 was okay
MostAwesomeDude: No, switching to the cvt or gtf modes doesn't help. :T
MostAwesomeDude: But 800x600 works just fine.
agd5f: MostAwesomeDude: you could try radeon.new_pll=1
MostAwesomeDude: agd5f: I will.
MostAwesomeDude: Also glxgears works fine now. I must have had an old Mesa before.
MostAwesomeDude: Whoo. So yeah. Changing agpmode has no effect. It tweaks out a bit and recovers in time for the ring test. Probably nothing to worry about.
MostAwesomeDude: new_pll doesn't help the waviness.
gspr: I'm a bit confused with regards to S3TC support on R600 - should it be working or not? Should the external libtxc_dxtn be required? If so, does mesa still need to be built with a particular flag in order to look for that library?
MostAwesomeDude: No; no; no.
MostAwesomeDude: Nobody's fixed r600c to do S3TC.
gspr: Thanks for the quick reply
gspr: forgive my ignorance, but shouldn't something like this be relatively straight forward, especially if using the external library?
Pallokala: IP issues are preventing it afaik.
mjr: gspr was probably talking about making it possible to use the external library; for this, ip issued shouldn't matter
gspr: mjr: Yeah, that's what I meant.
gspr: From what I can make out, it seems that <=r500 has working s3tc now. Is that correct?
Pallokala: it is implemented on chip there, isn't it?
airlied: same thing on r600, jsut needs tiling enabled I think to work properly
airlied: along with the s3tc texture formats
DrDisk: hm
DrDisk: on the following setup i've experienced sone on screen corruption: IBM T42 laptop w/ ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP)" (ChipID = 0x4e50) running suSE 11.2 (X.org 1.6.5, w/ SuSE radeon driver or a newer 6.12.7)
DrDisk: i already had a look at the bugzilla on freedesktop.org but none of the bugs quite matched the bevaiour i see
DrDisk: its either a small strip on the right of output VGA-0 or DVI-0 (when running 1400x1050x24 on output LVDS and anything on either VGA-0 or DVI-0), also when resizing VGA-0/DVI-0 past it initial size of 1280x1024 the new screen area gets corrupted also
DrDisk: (WM is KDE on that box which is a company supplied laptop)
boris64: Hey folks, do i need some extra firmware if i want to use KMS on my brand new 5850 (like on my old 4870)? Is there any (experimental?) 2D hardware support (like xvideo)?
Jonimus: DrDisk: the key word there might be AGP, you might try messing with the agpmode settings
Jonimus: boris64: yes you do need firmware for KMS on the evergreen cards.
Jonimus: http://people.freedesktop.org/~agd5f/radeon_ucode/
boris64: Jonimus: Thank you, just found the link in the wiki
DrDisk: Jonimus, interestingly ist just a small strip on the external monitors it never occurs on the LVDS display, just on the externals. i'll giv it a try though, haven't tried what happens if the resolution on VGA-0/DVI-0 is dentical to that of LVDS...
agd5f: DrDisk: using compiz or another compositer?
agd5f: if so, your screen is probably larger than the max texture size
mjg59: agd5f: Hey, are you able to release anything about the ATIF method? I've just been looking at a radeon system that doesn't send video hotkey notifications unless that's called first.
MrCooper: agd5f: are you sure the RandR 1.2 gamma hooks ever worked correctly for 16bpp? I think the server was previously still using the old palette hooks
agd5f: MrCooper: don't know.
yangman: iirc there's no difference for 16bpp with RandR gamma loading
yangman: but that was needed for VidMode
yangman: er, whatever that extension was called
agd5f: MrCooper: IIRC, I fixed the 16bpp support in the cmap code when we added randr 1.2 support to the radeon driver years ago and it worked until xserver 1.7 ish
agd5f: in the radeon randr cmap code
MrCooper: agd5f: that was the old palette hooks, wasn't it?
agd5f: MrCooper: not sure, I don't remember. I did have to fix the radeon randr pallete hook at the time
agd5f: I think
dafox: agd5f: did you have a chance to look at this bug: https://bugs.freedesktop.org/show_bug.cgi?id=28402 ?
agd5f: dafox: I've looked, but lockup bugs are really hard to diagnose unless you can pinpoint a commit
dafox: I've tried, but I think that's as close as I can get
dafox: it does narrow it down quite a bit though
dafox: and I think there is a high probability it's in one of those two last commits that do stuff with memory management, as I haven't yet experienced a lock up with the commit before those
dafox: although I have not tested it to my satisfaction (e.g. use that kernel for long enough) because it's just too slow
marvin24: agd5f: is it possible that the memory reserved in assemble_alu_instruction (r700_assembler.c) is never freed in the error path?
glisse: dafox: what does the kernel log says about your memory size
marvin24: I'm trying to find a huge memleak, ~30 MB/s in certain cases
dafox: glisse: [TTM] Zone kernel: Available graphics memory: 385048 kiB. [drm] radeon: 64M of VRAM memory ready [drm] radeon: 256M of GTT memory ready.
glisse: dafox: please attach full dmesg other information might be interesting
dafox: with my good 2.6.33 kernel
twnqx: 30MB/s sounds like a mplayer bug i once had :P
agd5f: marvin24: I think it all gets freed after compilation
marvin24: agd5f: what if the compilation fails?
marvin24: I get "Failed to translate vertex shader."
dafox: glisse: do you want all of it or just for today
agd5f: marvin24: I think it gets freed
agd5f: but you could double check
glisse: dafox: just one is good enough
marvin24: I added some debug code, http://pastie.org/1001065 is the typical output
marvin24: there is only _one_ free
dafox: glisse: done
glisse: maybe we need to program mc to cover full aperture
glisse: iirc there was a bug on some asic
marvin24: in case some tried the above url and got a 503 -> http://pastebin.com/V67PzfTB
ossman: agd5f, do the omlsync and glxswapcontrol programs work for you guys? or is testing a bit lacking? :)
agd5f: ossman: I don't mess with the vsync stuff. not enough room in my brain at the moment
ossman: agd5f, fair enough. just wondering why things keep braking for me without the guys hacking on vsync noticing in their end
glisse: ossman: what doesn't work ?
ossman: glisse, opengl vsync. I can get a number of different failure modes, but not something working
ossman: fdo bug "28410
ossman: playing around with mesa demos right now to produce a more lightweight test case
ossman: glisse, are you familiar with how things are supposed to interact to achieve opengl vsync?
ossman: doesn't really know where to start
glisse: i will take a look latter but i don't think it's linked to my dri2 sync stuff thought i can't remember if it's in f13 or not
ossman: glisse, my life was simple and happy until all of that DRI2 stuff :)
GNU\colossus: my life was simple and happy until yesterday, when I installed a new motherboard into my box.
ossman: glisse, I'm testing mostly git master stuff right now. didn't see much point in debugging something old
spreeuw: whn is the tiling stuff merged in mesa git?
agd5f: spreeuw: once the tiling patches get into the kernel
agd5f: which won't be until 2.6.36
glisse: ossman: we had to move on
ossman: glisse, yeah I understand the DRI2 is a much better design. it's just that I seem to be getting my share of the fallout :)
glisse: you not alone all the bug i have depress me
twnqx: points at GNU\colossus and laughs
agd5f: http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-atom-disable-pplls-during-dpms.patch
agd5f: patch to disable pplls during dpms to save power for those that want to try it
crocket: Hi
crocket: I use ATI Mobility X1250 and radeon driver. I try to use compiz well.
crocket: If I turn off metacity while using gtk-window-decorator of compiz, everything works well.
crocket: If I use kde4-window-decorator or metacity themes, windows borders flicker in white while resizing windows.
crocket: All of them happen with compiz.
crocket: Compiz doesn't even work witout KMS.
crocket: It could be radeon issue.
crocket: Why would it happen?
Reilithion: crocket: I can explain part of that.
crocket: I'm listening
crocket: Reilithion: Only gtk-window-decorator + cairo make compiz work well with X1250 and KMS radeon.
Reilithion: crocket: Currently, gem/ttm is only enabled if KMS is enabled. I believe compiz relies on gem/ttm support. gem/ttm relying on KMS might change in the future (or, at least I hope it will), but as for right now, the implementation depends on it.
Reilithion: As for the rest, or why your windows flicker during resize, I'm afraid I'm not sure.
crocket: Reilithion: cairo theme is stable.
Reilithion: crocket: Are you making use of the fusion icon?
crocket: Not at all
crocket: fusion icon is not available for now
crocket: i can change setting swithout fusion icon.
Reilithion: So, if I'm understanding correctly, you're using compiz as your window manager, and the only difference is which window decorator you're using?
crocket: yes
crocket: I went into Default applications of KDE system settings and changed the windows manager to compiz.
crocket: KWin is out of way.
Reilithion: Hmm. It sure sounds strange to me. I'm afraid it's beyond my limited expertise. The only relevant information I had was about gem/ttm. Perhaps someone else has a suggestion.
crocket: Reilithion: It doesn't make sense since compiz existed before KMS.
crocket: How about proprietary fglrx drivers?
Reilithion: crocket: I know even less about fglrx than I do about radeon. I am but a worthless well of ignorance.
crocket: Reilithion : how about compiz before KMS?
Reilithion: Yeah, I don't know very much about it either. Perhaps it didn't always depend on gem/ttm, but now makes use of it?
crocket: maybe
agd5f: updated r3xx-r5xx accel guide: http://www.x.org/docs/AMD/R5xx_Acceleration_v1.5.pdf
echosystm: harro
echosystm: this one ATI Mobility Radeon HD 5470 works?
echosystm: yes?
dileX_: Linux 2.6.35-rc3 released