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

[Christian König]

Am 29.08.2014 um 01:54 schrieb Grigori Goronzy:
> 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.
>
> 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?

That sounds like something doesn't work correctly.

The resources are created with the subsamled formats R8G8_R8B8 or 
G8R8_B8R8, but since this can't be accessed by the CB we need to use 
R8G8B8A8 as surface format for writing to them.

If that doesn't work the whole blitter and transfer code won't work 
either and we obviously have a problem. Can you figure out what's the 
real cause of this? Maybe we use the wrong tiling mode with such surfaces?

> 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.

Interesting, from the docs I thought that linear interpolation should 
also work for G and B components but I might remember that incorrectly.

Anyway, it might be easier to handle YUYV and UYVY as planar formats 
anyway and only to the transformation while we upload the data to them.

Christian.

>
> Grigori
>