[Mesa-dev] [PATCH] st/vdpau: fix YCbCr down/up-loads for buffers larger than requested

[Emeric Grange]

2012/6/7 Andy Furniss <andyqos at ukfsn.org>

> Andy Furniss wrote:
>
>> Andy Furniss wrote:
>>
>>> Christian König wrote:
>>>
>>>> When the video buffer turns out to be larger than
>>>> requested by the application we shouldn't upload
>>>> or download more data into / from it original requested.
>>>>
>>>> Fixes: https://bugs.freedesktop.org/**show_bug.cgi?id=39309<https://bugs.freedesktop.org/show_bug.cgi?id=39309>
>>>>
>>>
>>> Hi
>>>
>>> It doesn't fix decoding (for my 9600) - which that bug is mainly about.
>>>
>>> It does avoid the crashing with s/w decode that r300 had because npot
>>> wasn't enabled and the one case I found that mplayer would crash on r600
>>> mentioned in the bug is also fixed.
>>>
>>> Unfortunately it's not quite right, there's an artifact on r300 s/w
>>> decode = thin green lines right and bottom.
>>> R600 with the patch doesn't show it as much, but 1080 stuff does have
>>> one at the bottom.
>>>
>>
>> Playing some more - enabling npot for r300 will make it the same as r600
>> with the patch.
>>
>> Never tried 422 -vo on r300 before, but it fails whatever combination of
>> npot/patch is used -
>>
>> VO: [vdpau] 704x576 => 704x576 Packed YUY2
>> r300: Ooops. Got unsupported format r8g8_r8b8_unorm in
>> r300_create_sampler_view_**custom.
>> r300_state.c:1497:r300_create_**sampler_view_custom: Assertion `hwformat
>> != ~0' failed.
>> Trace/breakpoint trap
>>
>> The next test may be a regression but I can't be sure - just would be
>> surprised if I didn't test HD decode as well as SD in the past.
>>
>> Anyway this is with or without patch. SD decode as before renders junk,
>> but HD is now throwing errors.
>>
>> r300: Implementation error: Render targets are too big in
>> r300_set_framebuffer_state, refusing to bind framebuffer state!
>> radeon: The kernel rejected CS, see dmesg for more information.
>> Then lots of -
>> r300: Implementation error: Render targets are too big in
>> r300_set_framebuffer_state, refusing to bind framebuffer state!
>>
>> from dmesg -
>>
>> [drm] Initialized radeon 2.15.0 20080528 for 0000:02:00.0 on minor 0
>> [drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer !
>> [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
>>
>> If I enable npot -
>>
>> diff --git a/src/gallium/drivers/r300/**r300_screen.c
>> b/src/gallium/drivers/r300/**r300_screen.c
>> index da47fa2..758c690 100644
>> --- a/src/gallium/drivers/r300/**r300_screen.c
>> +++ b/src/gallium/drivers/r300/**r300_screen.c
>> @@ -325,7 +325,7 @@ static int r300_get_video_param(struct pipe_screen
>> *screen,
>>        case PIPE_VIDEO_CAP_SUPPORTED:
>>           return vl_profile_supported(screen, profile);
>>        case PIPE_VIDEO_CAP_NPOT_TEXTURES:
>> -         return 0;
>> +         return 1;
>>        case PIPE_VIDEO_CAP_MAX_WIDTH:
>>        case PIPE_VIDEO_CAP_MAX_HEIGHT:
>>           return vl_video_buffer_max_size(**screen);
>>
>> Then the errors go away (it still renders junk).
>>
>
> I don't know how Christian handles his mail, but Vodafone are blocking my
> ISP's SMTP address, so this is just going to the list - unless someone else
> can reply all.


Replied all, I hope it helps.
Emeric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120607/5d7d11f3/attachment.html>