[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
Tue Apr 26 10:41:11 PDT 2011
Hi Alex,
Am Dienstag, den 26.04.2011, 09:52 -0400 schrieb Alex Deucher:
> This looks great Christian. Nice work. One quick note regarding
> 68cc6bc5d8b6986acc7f5780d705f4ae9be2a446, COLOR[0-7]_INFO does need a
> bo. It's required since that reg has the tiling field and we need the
> reloc to know if the surface is tiled or not.
Ah, thanks for that. I was really wondering why this register was market
with this flag, because it contains neither addr nor length of a block.
But one question remains: What's the correct way to fix that?
Hacking the winsys code to do the relocation only when a bo is specified
is easy, but I'm not really sure what the drm cb checker will say to
that. Ok, I just implemented this while typing and it seems to work fine
(at least on kernel 2.6.37).
Another open end I wanted to ask you is about this diff fragment from
r600_state.c:
/* on R600 this can't be set if BLEND_CLAMP isn't set,
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)
+ 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);
+ }
color_info |= S_0280A0_SOURCE_FORMAT(V_0280A0_EXPORT_NORM);
+ }
According to the documentation and comments BLEND_CLAMP seems to be
necessary on R600 with 8bit snorm buffers, but this implies that we
would never be able to fully implement the clamping control from
ARB_color_buffer_float spec...
Tests on my RV710 are showing that 8bit snorm buffers are still working
quite fine even without BLEND_CLAMP, so what does R600 means in this
case? R6xx, but not R7xx chipset family? or just the original R600
chipset?
Regards,
Christian.
More information about the mesa-dev
mailing list