struberg1: hi folks, just like to catch up with latest powermanagement status. I have a HD3470 mobility and used Option "ForceLowPowerMode" but cannot see a drop of temerature
struberg1: I'm using current git version of radeonhd
struberg1: is there any line in Xorg.0.log indicating which freqs and voltages have been set actually? Or is this yet to be implemented?
legume: http://www.andyqos.ukfsn.org/601-100b-709vs601.png 709 colourspace = mucky greens for SD, which I assume is more used than HD.
legume: I think a xv attribute like radeon would be nicer than forcing 709.
yangman: legume: *sigh* and people insist there's no clear noticible difference. thanks for that
yangman: I'll see if I have some time next week to get that implemented :\
legume: yangman: cool - to be fair I suppose it is far harder to notice on "normal" video, but it's still there if there are solid colours when compared side by side.
legume: I sometimes wonder if I am a bit OTT with worst case test streams - seems like I am the only person so far who noticed the filtering difference between OSS R6xx and older cards or fglrx xv|gl.
legume: I mentioned it ages ago and found it's because tex_samp.xy_mag_filter = SQ_TEX_XY_FILTER_BILINEAR; applies even if unscaled and will totally eat alternate verticle lines @ 720p/i
yangman: CrCb will always be scaled
yangman: and there may have been a off-by-0.5 somewhere
yangman: it's not exactly trivial to treat native-size as a special case
legume: Changing to SQ_TEX_XY_FILTER_POINT fixes it, but that only works for the unscaled case and can't really do the (arguably more typical) just H scale.
yangman: IIRC deinterlatcing isn't done by Xv
legume: All other drivers and OSS on my r500 don't behave like this.
yangman: different shader
yangman: there was a off-by-0.5 bug in EXA. Xv may have the same thing, but I'm not sure
legume: deinterlacing?? seperate issue - Ironically one which made the me notice the difference, though.
yangman: oh, misunderstood. you said "just H scale"
legume: It would be good if it is an off by bug, but I did change to point and got a clean unscaled image,
yangman: like I said, CrCb will always be scaled. it'd be easier to see if it's actually a scaling issue by looking at Y' only
legume: yea - for me watching 16/9 PAL on a 4/3 monitor @1024x768 I only ever need Horiz scale - In theory I suppose the same would be true is I had a 1080 panel as BBC HD still needs hscale
legume: Agree with chroma scale, I am really noticing it on luma (overly wicked test streams again)
yangman: in any case, it's either just deal with bilinear, or implement something better
legume: yea you are right, I keep looking to try and understand how things work, but it's not happening yet :-)
yangman: I've been working at implementing bicubic on-and-off for a while now
legume: I assume you could make a texture to scale like bilinear does for
legume: It would be handy if there were a ready made SQ_TEX_X_FILTER rather than XY filter :-)
yangman: r6xx still has built-in bicubic filter
yangman: r7xx doesn't
yangman: it's something that's suited for shaders, though
legume: yea I tried SQ_TEX_XY_FILTER_BICUBIC while playing = green, I guess that bicubic reg I recall seeing in the docs needs setting up.
yangman: it just doesn't work, really
yangman: that's why nothing uses it
legume: Ahh OK
agd5f: well in theory it works, but you have to setup the filter kernel, which is just about as complex as writing filter as a shader
agd5f: legume: also, if you haven't, you may want to try the latest git code as we were previously using d3d pixel centers which led to the 0.5 offset yangman mentioned. that fixed some Xv issues as well
legume: agd5f: Ahh, yes it does seem better than before on a vertrez test
legume: wishes he had re run the rez tests before mentioning the now fixed issue :-(
gspr: Am I correct in understanding that the radeonhd drivers should support tear-free xv on r700?
gspr: 2D feels snappy, but video still tears
legume: gspr: In theory, but I currently have an issue which stops it working for me.
agd5f: gspr: it only works on crtc0 on radeonhd at the moment
gspr: I see
gspr: have you had any luck with the radeon drivers?
legume: gspr: It works OK on radeon for me.
gspr: thanks, I'll give that a shot then
gspr: at least switching between radeon and radeonhd is easy
gspr: been using fglrx with opengl video so far
gspr: thanks for the info
gspr: do you know anything about how work is progressing with radeonhd btw?
legume: gspr: The interesting 3D work for radeon and radeonhd is in the mesa driver which they both use
gspr: ah, I see... I'll pay attention there instead then
legume: agd5f: I don't know why, but with radeonhd I don't get vsync because in wait for vline in r6xx_accel.c rhdCrtc->CurrentMode->VDisplay is always 0.
agd5f: legume: yeah, I'm not familiar with how that var gets set, something in the modesetting code I guess
legume: agd5f: yangman did suggest I find why, but I haven't go very far at all :-)
legume: agd5f: updating xserver and xrand didn't help, and if I change res with xrandr it still doesn't get set.
agd5f: legume: that var is part of radeonhd, it's set somewhere in the driver, not in the xserver
legume: agd5f: Ahh OK