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

[Christian König]

Hi Andy & Emeric,

On 07.06.2012 16:29, Emeric Grange wrote:
>
> 2012/6/7 Andy Furniss <andyqos at ukfsn.org <mailto: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
>
>
>             Hi
>
>             It doesn't fix decoding (for my 9600) - which that bug is
>             mainly about.
>
Yes, indeed. I also doesn't plan to close this bug after pushing this 
fix, it's just for avoiding the crash.

>
>             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.
>
>
Mhm, that is interesting. Can you start mplayer with gdb and put a 
breakpoint on vlVdpVideoMixerRender and then see what is provided as 
"video_source_rect" by the player? Or just set VDPAU_TRACE=1 and send me 
the output.

>         Playing some more - enabling npot for r300 will make it the
>         same as r600
>         with the patch.
>
Yeah, but there was some regression with NPOT+VDPAU, I can't remember 
what it was exactly but that was the reason we added a separate NPOT 
property for video in the first place.

>
>         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
>
r300g doesn't supports that format, but I don't know why it fails with 
that error message, it should just gracefully tell mplayer though VDPAU 
that this isn't supported. Ah, wait a moment, IIRC mplayer never checked 
those properties....

>
>         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).
>
Sounds like we just hit some bandwidth limit in the combination NPOT+HD 
content.

Don't know what to do about it, the basic problem is that I don't have 
an r3xx system any more, together with my RV670 that stopped working 
when my last AGP based board died.

>     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
Thanks Emeric, otherwise I wouldn't have noticed Andys mails. The only 
good reason I still use this vodafone address is its good spam filter, 
but that sometimes is to strict. If that happens again just contact me 
on my AMD address (christian.koenig at amd.com).

Cheers,
Christian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120608/2098d55e/attachment.html>