[Mesa-dev] [PATCH 2/3] radeonsi: add sampling of 4:2:2 subsampled textures

[Andy Furniss]

Grigori Goronzy wrote:
> On 04.07.2014 01:24, Andy Furniss wrote:
>> Maybe not 1/frame but anyway the first couple of a run have
>> numbers rather than 0000s
>>
>> [27977.386795] radeon 0000:01:00.0: GPU fault detected: 146
>> 0x0c035014 [27977.386800] radeon 0000:01:00.0:
>> VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x000015E0 [27977.386802] radeon
>> 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03050014
>> [27977.386804] VM fault (0x04, vmid 1) at page 5600, write from CB
>> (80) [27977.386841] radeon 0000:01:00.0: GPU fault detected: 146
>> 0x0c03e014 [27977.386842] radeon 0000:01:00.0:
>> VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x000015E0 [27977.386844] radeon
>> 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x030E0014
>> [27977.386846] VM fault (0x04, vmid 1) at page 5600, write from CB
>> (224)
>>
>
> OK, so I finally have some time to look into this.

Thanks for doing this.

> These faults appear to be caused by the surface format mangling that
> vl applies to subsampled formats, which results in an incorrect
> framebuffer setup, so that rendering causes writes beyond the size of
> the texture BO. Typically the only rendering operation on video
> buffers is clearing them and that's why you only see these errors a
> couple of times after starting a video, one for each video surface
> that is created. I'm not yet sure what's the best way to solve this
> issue. The format mangling would need to also change the surface
> width appropriately. Or maybe it's for the best to make rendering
> support optional and never try to render to subsampled surfaces. Any
> thoughts about this, Christian?
>
> As for that 4:2:2 "doesn't work", AFAICT it absolutely does, but
> there is no linear interpolation for chroma, so quality isn't ideal.
> This seems to be a hardware restriction, unfortunately.

Hmm, we may have to disagree on the definition of working here :-)

Of course I don't understand the hardware - but are you saying that
because the chrome needs horizontal interpolation you have to have
vertical interpolation too?

I haven't had time to retest, my tests may have been flawed - but when I
did I noted -

Tests were 1:1 vertical scale.

With weave shader a test pattern rgbymc 422 chroma looked much like it
would if I had used ffmpeg to convert to it 420 (ie none of those at all
rendered). On real video it bled between fields, so my use case of
feeding it to a TV to deinterlace would fail - luma was OK.

With mesa hacked to use progressve shader 422 renders OK - no bleeding
between fields and a test pattern of rgbymc lines was maintained.

So is it just luck that the progressive works because there is less 
scaling/vertical position change?