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? 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. Grigori
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
