Christian König wrote:
> 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);
> }
It does fix xvmc - my chip is RV770 (well RV790) so I wasn't expecting
any change.
I haven't tried Alexes' patch yet as it doesn't apply to pipe-video.
>
> 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?
Still showing the new artifacts even with the patch. It's also quite
slow, I have CPU to spare according to top.
My HD4890 on low (240MHz) gives about 15fps on newmobcal, it's a bit
under 30 fps on high (850MHz).