kokachev: airlied: how about TV out support on amd64 platform? is it working? configure scripts reports, that it's only works on x86 platform. is it up-to-date?
airlied: kokachev: it should work fine on amd64 , but I haven't tested it..
airlied: kokachev: only the mach64 code is broken on 64-bit I think.
kokachev: ok. I'll test it right now and will let you now. One more: should i modify configure script to make ATIMISC_TV_OUT=yes or it should work as it is?
airlied: kokachev: ATIMISC is only for mach64..
airlied: kokachev: it should just work..
kokachev: airlied: hmm.. it works and no..
kokachev: airlied: i see cursor, but there are running diagonal dark lines. seems like synchronization problem.
airlied: what card? and what tv type?
kokachev: m2a-vm hdmi MB with x1250 IGP. TVout - compi
kokachev: airlied : composite. And the same happens on Svideo out.
airlied: pal or ntsc?
kokachev: airlied: ntsc
airlied: can you pastebin.com a log?
kokachev: airlied: sure.
kokachev: airlied: http://pastebin.com/me753284
airlied: hmm not spoptting anything obviously wrong.
airlied: except maybe the dac type..
kokachev: airlied: and also i think, driver determines wrong modes. in my xorg.conf i have "Modes "1024x768" "800x600" "640x480"", but driver only is able to use 640x480.
kokachev: airlied: and vesa driver is happy with 1024x768.
kokachev: airlied: maybe the problem is in modes?
airlied: kokachev: you should remove all the modes for tv from conf file.
airlied: kokachev: I'm not sure how well we set the scaler for tv stuff up ytet
kokachev: airlied: I removed all modes from xorg.conf, but no effect.
kokachev: how can i help you to correctly setup scaler?
airlied: kokachev: I need to re-test the latest code locally..
airlied: kokachev: Alex checked in some changes after my last set of tests.
airlied: kokachev: you could go back a few commits and re-test maybe..
airlied: oops.. pm'ed it by mistake
airlied: ah cool then it hasn't broken further..
airlied: hmm I'll try and test it locally in a while.. just working on the machine at the moment with r600 in it..
kokachev: airlied: btw: i see two different case: 1 - running diagonal lines, 2 - shaking pisture in horizontal direction.
kokachev: airlied: case #1 happens in 80% of X launxh, case #2 in 20%.
kokachev: airlied: DAC type should be TVDAC? if so, I'll try to find why it is "primary" instead of "TVDAC".
airlied: kokachev: the BIOS says its is primary.. maybe there isn't a difference on r500..
airlied: kokachev: play with xrandr to see if you can get a working mode..
kokachev: airlied: could you point some examples how to do that?
airlied: kokachev: xrandr --output S-video --mode
airlied: hmm I'm getting a loop for ever here on second run..
airlied: hmm backtracking to my old code looks better..
airlied: need to figure out what Alex did..
kokachev: airlied: i have some strange xrandr output
kokachev: Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1024 x 1024
kokachev: VGA-0 disconnected (normal left inverted right)
kokachev: LVDS connected 1024x768+0+0 (normal left inverted right) 0mm x 0mm
kokachev: 1024x768 60.0*+ 60.0
kokachev: 800x600 60.3
kokachev: 640x480 59.9
kokachev: S-video disconnected (normal left inverted right)
kokachev: airlied: but i connected only composite output..
airlied: it should show up on S-video due to bad naming.
airlied: kokachev: try with the latest git please.
airlied: kokachev: I think I fixed the wavy problem..
kokachev: airlied: i'll try now.
kokachev: airlied: nothing changed..
airlied: hmm wierd..
kokachev: airlied: do you need X.log?
airlied: I'm just seeing can reproduce it locally
kokachev: airlied: do you have this problem localy?
airlied: kokachev: hmm my pal mode now has a problem.
airlied: my ntsc mode seems fine though..
kokachev: airlied: same problem as in my case or something new?
airlied: well it looks like it is scrolling across the screen..
airlied: my only issue I'm not sure how good this monitor is at figureing out modes from tv-out
airlied: kokachev: you could try in atombios_crtc.c around line 279
airlied: switcihing the tv timings..
airlied: kokachev: swap the 1 and 2 and see what happens..
airlied: kokachev: I need to add more debugging to dump the modes to the script
kokachev: airlied: do you mean,that I got NTSC-J intead of NTSC?
kokachev: airlied: sorry .. my mistake..
airlied: kokachev: I'm not sure the timings actually relate to..
airlied: kokachev: I'll have to head off.. I'll see if Alex can figure out any mroe..
airlied: I'll add more debugging to it all tomorrow..
kokachev: airlied: thanks.. I'll test timing issue tmrw.
Kristoffer: Anyone awake?
arekm: is this normal that thing played via xv are not visible on cloned output?
arekm: so for example I run mplayer and on lvds I see a move while on cloned VGA-0 I see only mplayer window with blue/dark background instead of a movie
MrCooper: yes, the overlay can only be active on one CRTC
arekm: On the other hand if I do --output VGA-0 --right-of LVDS and then run mplayer on lvds and move to vga-0 then everything works fine
MrCooper: you can use the XV_CRTC attribute to choose which one
arekm: thanks
MrCooper: or, as you found out, if the window is only visible on one CRTC, the driver chooses it automagically
kdekorte: I've been reading Carl Worth's blog about storing glyphs as pixmaps when using EXA. I'm wondering if any of this has been done with the radeon driver
glisse: kdekorte: iirc Carl change were done in xserver so it should be driver independant
MrCooper: yes, it's merged on the xserver master branch
MrCooper: the previous glyph handling probably wasn't as bad for us though thanks to the accelerated UploadToScreen
kdekorte: which xserver is that patch in
OipOS: master.
kdekorte: so not 1.3 then? That is what I have in F8
MrCooper: no, not even 1.4
OipOS: No idea actually. It might only be in git.
MrCooper: kdekorte: again, I wouldn't expect it to make a significant difference anyway with radeon
kdekorte: MrCooper, well I have a radeon r300 chipset using XAA and a r500 using EXA and using gtkperf (I know crappy way to test). The r500 takes twice as long for the DrawingArea - Text test... DrawingArea - pixmap is blazing comparitivly
kdekorte: that is why I was asking
kdekorte: r300 DA-T is 25secs, r500 DA-T is 66secs
kdekorte: r300 DA-P is 12secs, r500 DA-P is 6 secs
MrCooper: R300 and newer can't accelerate glyph drawing anyway due to missing RENDER acceleration, so that change definitely doesn't matter
kdekorte: on the r500 DA-T is the only slow test, every thing else is reasonable
kdekorte: in fact the DA-T test is about 50% of the total runtime of the test (gtkperf -c 500 -a)
MrCooper: have you compared to the other XA on each card?
kdekorte: XAA on the r500 feels much slower than EXA (firefox menus popup much slower, etc)
kdekorte: and NoAccel is just glacial
kdekorte: BTW, I am using drm with kernel modules from git and radeon from git
MrCooper: how about EXA on the R300 then
kdekorte: EXA on the r300 hardly works
OipOS: Really?
OipOS: EXA works awesome on my r300.
tilman: it works if you have a fast CPU
kdekorte: Yeah, lots of rendering errors on my machine (thinkpad t41p, FireGl T2)
OipOS: Define fast CPU.
kdekorte: t41p has 1.7Ghz 2GB RAM
tilman: i hardly notice the render software fallbacks on this athlon64 4000+
OipOS: Hmm.
kdekorte: t60p (fireGL v5200, 3GB RAM) is my r500 machine
tilman: i guess that agp vs pcie makes a difference, too
kdekorte: t60p is pcie, t41p is agp
tilman: since DFS isn't accelerated on agp systems, iirc
MrCooper: not without Option "AccelDFS"
MrCooper: kdekorte: newer versions of xserver may help due to other EXA improvements, but hardly that particular one
tilman: okay, it was the "problems with some agp bridges" that i had in mind
kdekorte: MrCooper I know radeonhd is using a shadowfb and so it is different method, but the gtkperf tests using that driver are MUCH faster.. about 50%
MrCooper: right, some of them can't do transfers to the host reliably
kdekorte: And that is all I change, radeonhd vs radeon
kdekorte: but other things on radeonhd are slower and so I still prefer radeon
MrCooper: yes, doing everything with the CPU in system RAM can be faster than ping-ponging between CPU and GPU and between system and video RAM
kdekorte: I'm just wondering why the text rendering is so much slower than the pixmap rendering, the driver seems to affect the performance alot without anything else changing, so it is not freetype or cairo getting in the way
kdekorte: I just switched my r300 to EXA mode and when I run gtkperf it spikes the CPU and is very slow on GtkComboBox
MrCooper: how did you conclude that the driver affects performance? you have a lot of variables...
kdekorte: not really... I have radeonhd (XAA) and radeon(EXA)
kdekorte: all I do is switch between those two
kdekorte: on a single machine
kdekorte: I did some benchs using radeonhd, vesa and radeon...
kdekorte: GtkDrawingArea - Text - time: 2.53 (radeonhd) (very high CPU)
kdekorte: GtkDrawingArea - Text - time: 4.26 (vesa)
kdekorte: GtkDrawingArea - Text - time: 67.25 (radeon) (EXA on 12/13/07, current is no better)
kdekorte: same machine, same test, same everything else
MrCooper: the difference between radeonhd and vesa is odd, but radeon has to wait for GPU idle, read-modify-write video RAM directly with the CPU, ...
kdekorte: Well then how can you explain this then...
kdekorte: GtkDrawingArea - Lines - time: 1.45 (radeonhd, which we know has no acceleration)
kdekorte: GtkDrawingArea - Lines - time: 2.49 (vesa)
kdekorte: GtkDrawingArea - Lines - time: 3.44 (radeon EXA)
kdekorte: I consider that difference reasonable, bit not the order of magnitude like Text
kdekorte: In the Circles test, radeon is about 30% faster than radeonhd, so I'm just confused
MrCooper: I don't know what the pixbuf test does (gtkperf seems broken with newer GTK), but maybe in contrast to the text it can be accelerated, or each operation is larger than a glyph, ...
MrCooper: http://gtkperf.sourceforge.net/images/sc_drawing_pixbufs.png looks like it's rather the latter
kdekorte: right the pixbufs are about 200x200ish and the Text is probably more like 600x100 so maybe the size of the object being blitted is part of the slowness
MrCooper: you could try profiling with sysprof or oprofile to see where it's burning the cycles in the pathological case
MrCooper: I'm off for tonight, bbl
agd5f: radeonhd is just sw or shadowfb right now. no xaa or exa yet
joss193: aah hello
joss193: r300 drivers any assistance with it?
guenter: hello agd5f, ponyboy here (different country) i finally managed to get git running and applied your patch. unfortuneatly it did not help
agd5f: guenter: ok. it's probably the gpio thing. hopefully I'll be able to sort out how it works from the internal folks when I get a chance
guenter: ok cool thanks. no stress.. just wanted to give you a report
damentz: airlied: someone else has the same problem i do
damentz: with hte lcd screen blooming on radeon cards
airlied: damentz: on the same card?
damentz: xpress 200
damentz: airlied: want me to upload a log of the chat?
damentz: its in a public room so theres lots of other people talking too
damentz: airlied: http://paste.debian.net/46091
airlied: damentz: xprses 200 may have another problem..
damentz: oh shoot
damentz: one second need to reboot
damentz: used the wrong kernel, no fglrx module...
damentz: brb
agd5f: damentz: does it only happen when you have XAAnooffscreenpixmaps or always?
OipOS: Oh hey, turning on DRI on my X200M makes my screen go black.
damentz: agd5f: xaanooffscreenpixmaps and using exa
damentz: agd5f: it also does it when a game, like openarena, requests the resolution to change, by default to 640x480
agd5f: damentz, ok, but does it work when you do xrandr --output LVDS --mode 800x600 for example
agd5f: or xrandr --output LVDS --mode 640x480
rx__: that caused blooming for me (w/o the --output LVDS) when i tried it once :)
damentzlap: agd5f: can't test right now, i'm using 6.6.193
damentzlap: i cna upgrade right now if you need me to test some things
damentzlap: whats the difference with that command than xrandr -s 640x480?
agd5f: damentzlap: I just want to know if there a problem with the rmx set (all mode changes) or if something else is at work
rx__: you just need someone with mobility to test resolution changes? :)
agd5f: rx__: well someone that has the problem
agd5f: it works for most people
rx__: the blooming?
agd5f: yeah
damentzlap: agd5f: 6.7.197 ok to test with?
damentzlap: just installed it
agd5f: damentzlap: sure
damentzlap: ok
damentzlap: i'll keep xaanooffscreenpixmaps enabled
agd5f: damentz: are you sure that option makes a difference?
damentz: yes
damentzlap: ok, so xrandr --output LVDS --mode 640x480
agd5f: damentz: can you test both with and without the xaanooffscreenpixmaps option?
agd5f: yes
damentz: can't see anything now
damentz: lets restart X
damentzlap: ok
damentzlap: resolution change worked
agd5f: same command?
damentzlap: yes
damentzlap: i copied the xorg logs just incase
damentzlap: good thing about lcd panels, it automatically antialiases everything at non-native resolutions
agd5f: no, that's the scaler
damentzlap: oh really?
agd5f: panel always runs at native res
damentzlap: oh, didn't know that
damentzlap: i thought the lcd panel is supposed to do the processing
damentzlap: ok well, any other testing you need?
agd5f: damentzlap: log pastebins?
damentzlap: sure, which paste site do you prefer?
agd5f: doesn't matter
damentz: ah crap
damentz: changed back to 1400x1050, screen went white
damentz: ok well at least i still have hte log
rx__: i guess i should say my problem is different.. :)
agd5f: rx__: what problem are you having?
rx__: i don't have any xaanooffscreenpixmap setting
rx__: resolution changing just doesn't work
rx__: at 640x480 i got a half white half grey screen
agd5f: rx__: what chip?
rx__: and it wasn't exactly half
rx__: m56
agd5f: oh, yeah, we don't support the scalers on r5xx chips yet
rx__: oh ;/
damentzlap: http://rafb.net/p/Lv0Hfe89.html
damentzlap: http://rafb.net/p/gFqApY80.html
damentzlap: those are the two logs
damentzlap: first one is with XAANoOffscreenPixmaps
airlied: OipOS: you've got one of the rs4xx that we don't support..
airlied: OipOS: and have little idea how to support.
OipOS: Oh, damn.
OipOS: I guess I'll have to wait until AMD releases the docs then.
diego_: hi guys.
damentz: agd5f: anything else i should do?
agd5f: damentz: not at the moment
rx__: what hw is glisse using for gallium test?
agd5f: rx__: some r3xx hw I think
rx__: ah
rx__: thx
tiger2wander: i have install a lastest ATI driver for my radeon X300 video card and enabled fglrx drive but when i loged in, have a dirty rectange on bottom left corner of screen, have anybody known about that?
rx__: try #ati
tiger2wander: i have post my question on ati room, but nobody answer even 1 hour, :(
rx__: did you try using the open source ati driver? :)
tiger2wander: i tried to used both open source ati driver
tiger2wander: from liva repository and from ati's site
tiger2wander: it work fine
rx__: so use that then
tiger2wander: but my problem is only a dirty rectangle on bottom left corner of screen after i loged on
tiger2wander: i'm using fedora core 8
rx__: you mean livna repository?
tiger2wander: when i remove fglrx driver the dirty rectangle was removed!
tiger2wander: yep
rx__: so don't use fglrx if it's causing you problems
tiger2wander: but i need to use it for 3d aceleration support
tiger2wander: :D
tiger2wander: fedora core built in driver not support fully 3d
rx__: i thought xf86-video-ati had r4xx 3d accel
werdz: it does
werdz: not quite up to r200 standards yet, but in general it seems to work far better then fglrx ever did
tiger2wander: what your fps you receive when run 3d test?
tiger2wander: but my driver is ATi radeon X300
werdz: less then fglrx. but there are less stupid bugs like artifacts on screen, dirty rectangles, etc
tiger2wander: yep, that is standard
werdz: X300 = R4xx
airlied: x300 is rv370
tiger2wander: ok
werdz: ah
tiger2wander: i have try to play some windows
tiger2wander: i have try to play some windows game on linux by cedega
tiger2wander: and by wine
rx__: oh .. rv370
agd5f: r3xx and r4xx are more or less the same
agd5f: just more pipes