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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
