I'm trying to watch video via MPlayer's OpenGL video output. All works fine if i use software colorspace conversion. But i have wrong colors if any fragment-prog based colorspace conversions in use (-vo gl:yuv=[2|3|4]). With software OpenGL (Mesa-6.5.3) same version of MPlayer works fine. I'll attach Xorg.0.log, screenshot showing two MPlayer windows and glxinfo.
Created attachment 10618 [details] Xorg log
Created attachment 10619 [details] glxinfo -v -l
Created attachment 10620 [details] two mplayers Upper window with software colorspace conversion, lower window with wrong colors
Created attachment 10621 [details] part from MPlayer's debug output (-v)
Created attachment 10622 [details] Fragment program, used by mplayer for YV12 -> RGB conversion
I noticed some of the other formats seem to be black and white. I guess this is not supposed to happen either? I would guess it's either a bad texture format; I have seen blue patches on argb8888, or a bad fragment program; I think there are some cases where swizzle is broken... Where does mplayer install the fragment and vertex programs?
some conversion types shouldn't work on r300 dri (like old Ati_fragment_shader method, #5, and NV-specific method #1) some OpenGL functions are in mplayer/libvo/gl_common.c mplayer/libvo/vo_gl.c
The fragment programs used for color space conversion from planar YUV to RGB by mplayer with the methods 2, 3 and 4 are using TEX instructions with writemasks, and it seems the R300 driver does not use that information. I have had the exact same issue in a project (Pigment) using a color space conversion program, and have worked it around writing a fragment program using one more TEMP. I took a look at the code and did not find the registers to handle that feature.
(In reply to comment #8) > The fragment programs used for color space conversion from planar YUV to RGB by > mplayer with the methods 2, 3 and 4 are using TEX instructions with writemasks, > and it seems the R300 driver does not use that information. I have had the > exact same issue in a project (Pigment) using a color space conversion program, > and have worked it around writing a fragment program using one more TEMP. > > I took a look at the code and did not find the registers to handle that > feature. > Thanks for explanation! What do you think is better - fix mplayer side or try to reverse engineering closed-source ati driver? For me, fixing R300 DRI side is preferable, but i don't know how long this will take ....
Created attachment 11908 [details] [review] patch to use writemask in tex instruction Does the attached patch (i just tested that it does compile haven't the hw right now) fix this issue (once you rebuilded mesa you might need to install newly build libGL and co with new r300_dri.so).
(In reply to comment #10) > Created an attachment (id=11908) [details] > patch to use writemask in tex instruction > > Does the attached patch (i just tested that it does compile haven't > the hw right now) fix this issue (once you rebuilded mesa you might > need to install newly build libGL and co with new r300_dri.so). > Yes, it works!
Ok, i have pushed the fix, closing the bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.