summaryrefslogtreecommitdiffstats
path: root/debian
diff options
context:
space:
mode:
authorwm4 <wm4@mplayer2.org>2011-11-20 20:54:13 +0100
committerUoti Urpala <uau@mplayer2.org>2011-11-25 23:59:49 +0200
commit9ffd1cdaf802acf71c7e4db86b650be33b7c05ba (patch)
treeff9c7303eaa61ed3f1e264dbb6bfbb4a8f6f31d5 /debian
parent046692d90b3282ae99c9470aec711158eb2f1c40 (diff)
downloadmpv-9ffd1cdaf802acf71c7e4db86b650be33b7c05ba.tar.bz2
mpv-9ffd1cdaf802acf71c7e4db86b650be33b7c05ba.tar.xz
vo_gl: fix cscale=4 and cscale=5 doing nothing
The ARB shader code generated at the end of the shaders for scaling mode 4 and 5 was something like: MAD yuv.g, b.r, {0.5}, a.r; This appears to be semantically equivalent with: MAD yuv.g, b.rrrr, {0.5, 0, 0, 0}, a.rrrr; This has the consequence that the result register, yuv.g, will not contain the value computed by the scale filter, but a.r. a.r is the unchanged value sampled from the normal texture coordinates, so the filter did effectively nothing and behaved as if cscale=0 was specified. The basic mistake here is that yuv.g does not specify a single register, but it specifies the full vector register yuv, with writing enabled on the g channel. This means yuv.g will assigned the g channel of the the result vector computed by the MAD instruction.
Diffstat (limited to 'debian')
0 files changed, 0 insertions, 0 deletions