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