The patch I posted there is old and not worth looking at.
I've got an improved version, which also does this on r200 class chips, but I didn't have time to test it yet (and thus likely fails on r200).
As far as performance goes, don't expect too much from it, it only saves a little cpu time. In fact it could be slower if performance is limited by the gpu, though a little benchmarking (with rather small source and upscaled to fullscreen to show a difference) didn't really show a measurable difference (in contrast to bicubic filtering, which indeed had a larger than 2 times performance hit - not that it would really matter in that case as it still was 5 times faster than real time).
Though there are other advantages to manual yuv->rgb conversion, it allows incorporating saturation/hue/contrast/brightness adjustments in the same transform.

I noticed some patches for this got applied in git. I am now testing git revision d2c3964f on my RV530 with

 mplayer -benchmark -quiet -nosound filename

but I don't notice any performance difference when enabling or disabling XV_HWPLANAR Xv attribute (tested with or without XV_VSYNC and with XV_BICUBIC disabled).

So, is this supported on R500? What sample should I use to see the improved performance (I tested a 1280x720 clip)? Anything other should I know?

Thanks.

just r2xx and r3xx/r4xx at the moment.  No r5xx support yet.

Created attachment 24703 [details] [review]
implement brightness/contrast/hue/saturation/gamma controls for textured video

Here's some more stuff to play with. This implements contrast/brightness/hue/saturation controls for r200/r300 plus gamma (same gamma value for all channels used though separate values would be trivial) control for r300.
Some issues left:
- only r200/r300
- still can't be combined with bicubic
- controls will silently cease to work if the format used is packed and not planar (except for rv250)
- gamma range is from 100 to 10000 corresponding to 0.1 and 10.0 like used in overlay. However, usable range is far smaller. Over 2.0 picture gets dark pretty quickly, and below 0.6 or so black seems to turn into purple (I've verified that even with gamma 1.0 black actually often seems to be RGB 1/0/1 so this explains this since that gets amplified by low gamma values - not sure if this is a rounding problem somewhere, bogus reference values or is somehow expected).
- gamma adds a bit too many instructions for my taste (7) though the alternative (3 texture lookups + some swizzling instructions) doesn't seem any better.

I've started reworking the tex vid code here:
http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=tex_vid2

Implemented so far:
- general re-org, cleanup
- r1xx: implement native planar Xv
- r2xx: switch to shader-based csc
- r6xx: implement Xv attributes (brightness, contrast, etc.)
- r3xx: implement shader-based csc for packed formats

Stuff left to do:
- r3xx: integrate shader-based csc with bicubic
- r5xx: implement shader-based csc (both packed and planar)
- r5xx: integrate shader-based csc with bicubic
- r6xx: implement bicubic

Some more updates in my tree.  I'm tempted to merge this now, but it can get a bit confusing when switching between between bicubic and non-bicubic WRT to Xv attributes like brightness, contrast, etc.

Stuff left to do:
- r3xx: integrate shader-based csc with bicubic
- r5xx: integrate shader-based csc with bicubic
- r6xx: implement bicubic

I've merged this to master.  You'll need to disable bicubic filtering to use Xv attributes for hue/contrast/brightness however.

Nice but I noticed two problems with my RV530:
1) the new attributes have effects only when BICUBIC is 0, but not when BICUBIC is 2 but disabled because the image is not scaled;
2) with a small video (512x368) I noticed a 8% speedup (with mplayer -benchmark -quiet -nosound filename) no matter XV_SYNC, with a larger video (1280x720) I noticed a slowdown (over 61% and the video is jerkily), unless XV_SYNC is disabled, where I get the same performance. But maybe this is a collateral effect of the XV_SYNC that must paint all the frames and is noticeable only when doing benchmark (i.e. fps > video refresh)?

(In reply to comment #8)
> Nice but I noticed two problems with my RV530:
> 1) the new attributes have effects only when BICUBIC is 0, but not when BICUBIC
> is 2 but disabled because the image is not scaled;

This is the intended behavior.  If bicubic is enabled or auto, I don't enable the attributes since it would be confusing to have the effects suddenly disappear when the video gets scaled.  The only way to use them is to disable bicubic (XV_BICUBIC = 0).

> 2) with a small video (512x368) I noticed a 8% speedup (with mplayer -benchmark
> -quiet -nosound filename) no matter XV_SYNC, with a larger video (1280x720) I
> noticed a slowdown (over 61% and the video is jerkily), unless XV_SYNC is
> disabled, where I get the same performance. But maybe this is a collateral
> effect of the XV_SYNC that must paint all the frames and is noticeable only
> when doing benchmark (i.e. fps > video refresh)?
> 

XV_VSYNC is unrelated to these changes.  It will decrease performance in benchmark type scenarios because it stalls the engine while it waits for the current vline to pass beyond the video.  It's used to avoid tearing.  Turn it off for benchmarking.

(In reply to comment #9)
> (In reply to comment #8)
> > Nice but I noticed two problems with my RV530:
> > 1) the new attributes have effects only when BICUBIC is 0, but not when BICUBIC
> > is 2 but disabled because the image is not scaled;
> 
> This is the intended behavior.  If bicubic is enabled or auto, I don't enable
> the attributes since it would be confusing to have the effects suddenly
> disappear when the video gets scaled.  The only way to use them is to disable
> bicubic (XV_BICUBIC = 0).

OK. What about changing the default of the bicubic from auto to no, since it has this limitation (that also confuses users) and it causes slowdown (and also I dislike its smoothing effect)?

> > 2) with a small video (512x368) I noticed a 8% speedup (with mplayer -benchmark
> > -quiet -nosound filename) no matter XV_SYNC, with a larger video (1280x720) I
> > noticed a slowdown (over 61% and the video is jerkily), unless XV_SYNC is
> > disabled, where I get the same performance. But maybe this is a collateral
> > effect of the XV_SYNC that must paint all the frames and is noticeable only
> > when doing benchmark (i.e. fps > video refresh)?
> > 
> 
> XV_VSYNC is unrelated to these changes.  It will decrease performance in
> benchmark type scenarios because it stalls the engine while it waits for the
> current vline to pass beyond the video.  It's used to avoid tearing.  Turn it
> off for benchmarking.

OK, thanks for clearing this. The strange thing, however, is that before the latest xv merge I got the same performance with or without vsync enabled, while now I get the previous performance only with the vsync disabled and a large slowdown with it enabled.

Thanks

(In reply to comment #10)

> OK. What about changing the default of the bicubic from auto to no, since it
> has this limitation (that also confuses users) and it causes slowdown (and also
> I dislike its smoothing effect)?

It's a tough call. A lot of people (myself included) prefer the bicubic filtering.  I'm not sure what the best answer is.

> 
> > > 2) with a small video (512x368) I noticed a 8% speedup (with mplayer -benchmark
> > > -quiet -nosound filename) no matter XV_SYNC, with a larger video (1280x720) I
> > > noticed a slowdown (over 61% and the video is jerkily), unless XV_SYNC is
> > > disabled, where I get the same performance. But maybe this is a collateral
> > > effect of the XV_SYNC that must paint all the frames and is noticeable only
> > > when doing benchmark (i.e. fps > video refresh)?
> > > 
> > 
> > XV_VSYNC is unrelated to these changes.  It will decrease performance in
> > benchmark type scenarios because it stalls the engine while it waits for the
> > current vline to pass beyond the video.  It's used to avoid tearing.  Turn it
> > off for benchmarking.
> 
> OK, thanks for clearing this. The strange thing, however, is that before the
> latest xv merge I got the same performance with or without vsync enabled, while
> now I get the previous performance only with the vsync disabled and a large
> slowdown with it enabled.

Any chance you could bisect and find out the bad commit?  None of the texvid rework touched the xv vsync code, so it's probably something prior.

> > The strange thing, however, is that before the
> > latest xv merge I got the same performance with or without vsync enabled, while
> > now I get the previous performance only with the vsync disabled and a large
> > slowdown with it enabled.
> 
> Any chance you could bisect and find out the bad commit?  None of the texvid
> rework touched the xv vsync code, so it's probably something prior.
> 

Strangely, I noticed that the slowdown appears only sometimes when running with vsync enabled. Sometimes it works indeed at the right speed (the same as without vsync) sometimes slower and very jerkily. The same happens with 6.12.2.