[Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)

Christian König deathsimple at vodafone.de
Thu May 5 14:10:27 PDT 2011


Am Donnerstag, den 05.05.2011, 12:11 +0100 schrieb Andy Furniss:
> Andy Furniss wrote:
> > There has been a regression though -
> >
> > [g3dvl] remove resource_format workaround
> >
> > causes quite bad artifacts on newmobcal.
> 
> I can get rid of the new artifacts for xvmc with the patch below.
> 
> ffmpeg12vdpau shows the same "new" artifacts, but is not fixed by this.
The problem is more complicated than this, using a signed buffer format
is just a workaround, the real solution is to implement blender clamping
in r600g. You could try this (temporary) patch until I figured out how
to do this correctly on all supported hardware:

--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -786,10 +786,10 @@ static void r600_cb(struct r600_pipe_context *rctx, struct r600_pipe_state *rsta
           if BLEND_FLOAT32 is set of > 11 bits in a UNORM or SNORM */
        if (desc->colorspace != UTIL_FORMAT_COLORSPACE_ZS && desc->channel[i].size < 12) {
                //TODO: Seems to work on RV710, but i have no idea what to do between R600-RV710
-               if (rctx->family < CHIP_RV710) {
-                       color_info |= S_0280A0_BLEND_CLAMP(1);
-                       color_info_mask |= S_0280A0_BLEND_CLAMP(1);
-               }
+               //if (rctx->family < CHIP_RV710) {
+               //      color_info |= S_0280A0_BLEND_CLAMP(1);
+               //      color_info_mask |= S_0280A0_BLEND_CLAMP(1);
+               //}
                color_info |= S_0280A0_SOURCE_FORMAT(V_0280A0_EXPORT_NORM);
        }

I'm currently focusing more on the variable length decoding part of the
vdpau mpeg2, by the way: How is well does this work on your hardware?

Regards,
Christian.



More information about the mesa-dev mailing list