Bug 111213 - VA-API nouveau SIGSEGV and asserts
Summary: VA-API nouveau SIGSEGV and asserts
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: 19.1
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Nouveau Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-25 07:16 UTC by KJ Liew
Modified: 2019-08-24 02:51 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
libva-vdpau-driver-chromium AUR patch (5.57 KB, patch)
2019-07-27 02:02 UTC, KJ Liew
Details | Splinter Review
vdpau_dmesg (9.66 KB, text/plain)
2019-07-28 03:30 UTC, KJ Liew
Details

Description KJ Liew 2019-07-25 07:16:35 UTC
Tested hardware: Geforce 9300 mGPU (NVAC), GT730-GK208B (NV106)
VA-API apps: gstreamer-vaapi, Chromium-vaapi-bin(AUR)
OS: ArchLinux x86_64 kernel 5.2.2-arch1-1-ARCH
GUI: GNOME/Wayland using nouveau

- vainfo & vdpauinfo SIGSEV due to NULL pointer
ArchLinux discussion thread
https://bbs.archlinux.org/viewtopic.php?id=247466

- h264 video decode failed with assertion and tendency to crash GNOME/GUI
Test h264 clip:
$ youtube-dl -f mp4 https://www.youtube.com/watch?v=azvR__GRQic
Gstreamer command line
$ gst-launch-1.0 playbin uri=file:///path/to/MP4
or
$ gst-launch-1.0 filesrc location=/path/to/MP4 ! qtdemux ! vaapidecodebin ! vaapisink

Use enhanced-h264ify plugin on Chromium to playback the same h264 video clip from YouTube.com
Geforce 9300 mGPU - video played as garbage, browser may crash
GT730 - fallback to FFmpegVideoDecoder after asserts
ve4_set_surface_info:969 - unsupported surface format, try is_format_supported() !
romium/chromium --type=gpu-process --field-trial-handle=7734813049068668419,17986421265460211344,131072 --disable-breakpad --gpu-preferences=KAAAAAAAAAAgAACgAQAAAAAAAAAAAGAAAAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAA --service-request-channel-token=7551475798706255496: ../mesa-19.1.3/src/gallium/drivers/nouveau/nvc0/nve4_compute.c:396: nve4_compute_validate_constbufs: Assertion `i > 0' failed.
Comment 1 LoneVVolf 2019-07-25 12:33:25 UTC
Problem started with mesa 19.1.x and is also present in git master
Comment 2 Ilia Mirkin 2019-07-25 14:05:51 UTC
There have been a lot of changes to st/va lately, without much effort to making sure the changes work on more than the target hardware (which nouveau is not). As such, this is not surprising.

I can't get gst-launch to work, probably missing something, I try to avoid having gstreamer installed (but seem to have failed, since gst-launch is there...). Can't seem to get ffplay to do it either. Someone who cares about va-api will have to investigate this.

[In the meanwhile, looks like vdpau also got f'd, but I'll fix that... it's some kind of generic compiler optimization failure.]
Comment 3 KJ Liew 2019-07-25 17:22:22 UTC
(In reply to LoneVVolf from comment #1)
> Problem started with mesa 19.1.x and is also present in git master

I am not quite sure if this started with mesa 19.1.x. On GT730 I downgraded mesa 
back to 19.0.6 and gstreamer is still broken. The vainfo/vdpauinfo SIGSEGV started with mesa 19.1.x. But that was just the simplest VA-API sanity check and I found that h264 video decoding remains broken.

$ pacman -Qs mesa | grep ^[a-z]
local/glu 9.0.0-5
local/libva-mesa-driver 19.0.6-1
local/mesa 19.0.6-1
local/mesa-demos 8.4.0-1
local/mesa-vdpau 19.0.6-1

$ gst-launch-1.0 playbin uri=file:///path/to/MP4 
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayWayland\)\ gldisplaywayland0";
Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayEGL\)\ vaapidisplayegl0";
Caught SIGSEGV
Spinning.  Please run 'gdb gst-launch-1.0 1280' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.

# gdb gst-launch-1.0 1280
(gdb) bt
#0  0x00007fa2e8de1667 in poll () from /usr/lib/libc.so.6
#1  0x00007fa2e8b1aa80 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007fa2e8b1ba63 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#3  0x00007fa2e8c73f52 in gst_bus_poll () from /usr/lib/libgstreamer-1.0.so.0
#4  0x0000563693c9f974 in ?? ()
#5  0x0000563693c9e85c in ?? ()
#6  0x00007fa2e8d16ee3 in __libc_start_main () from /usr/lib/libc.so.6
#7  0x0000563693c9ed0e in _start ()
Comment 4 Ilia Mirkin 2019-07-26 03:00:48 UTC
Good news -

../src/gallium/drivers/nouveau/nvc0/nve4_compute.c:396: nve4_compute_validate_constbufs: Assertion `i > 0' failed.

also happens with vdpau. It's because we don't expect ever receiving a non-user constbuf at position 0. Will add handling for it.
Comment 5 Ilia Mirkin 2019-07-26 03:45:28 UTC
If you guys are able to compile mesa, there's a patch series that fixes the various issues with vdpau for me, at least with a GK208:

https://patchwork.freedesktop.org/series/64282/
Comment 6 KJ Liew 2019-07-27 01:34:54 UTC
I don't know how you had verified VDPAU to make sure it is working. Running vdpauinfo is not enough. I used the VA-API translation layer for VDPAU backend since my goal is to get VA-API. I had also verified that the VA-API translation layer worked with nvidia-390xx propriety blobs and Chromium-vaapi accelerated H264 playback.

The change *ONLY* fixed "vainfo & vdpauinfo SIGSEGV due to NULL pointer".

$ LIBVA_DRIVER_NAME=vdpau vainfo
vainfo: VA-API version: 1.5 (libva 2.5.0)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG4Simple            :	VAEntrypointVLD
      VAProfileMPEG4AdvancedSimple    :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD


$ LIBVA_DRIVER_NAME=vdpau VDPAU_DRIVER=nouveau chromium
[19735:19735:0726/182126.662312:ERROR:vaapi_wrapper.cc(455)] GetConfigAttributes failed for va_profile 13
[19735:19735:0726/182126.662353:ERROR:vaapi_wrapper.cc(455)] GetConfigAttributes failed for va_profile 6
[19735:19735:0726/182126.662359:ERROR:vaapi_wrapper.cc(455)] GetConfigAttributes failed for va_profile 7
[19735:19735:0726/182126.764805:ERROR:sandbox_linux.cc(368)] InitializeSandbox() called with multiple threads in process gpu-process.
[19735:19735:0726/182126.808082:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
romium/chromium --type=gpu-process --field-trial-handle=7302155616383548209,8433935369873353489,131072 --disable-breakpad --gpu-preferences=KAAAAAAAAAAgAACgAQAAAAAAAAAAAGAAAAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAA --service-request-channel-token=6382519074401266972: ../mesa-19.1.3/src/gallium/drivers/nouveau/nvc0/nvc0_video.c:43: nvc0_decoder_begin_frame: Assertion `ret == 2' failed.

There was a long pause, I think the GPU process crashed and then restarted with more lengthy logs spit until Chromium was killed

[20217:20217:0726/182241.032544:ERROR:vaapi_wrapper.cc(455)] GetConfigAttributes failed for va_profile 13
[20217:20217:0726/182241.032617:ERROR:vaapi_wrapper.cc(455)] GetConfigAttributes failed for va_profile 6
[20217:20217:0726/182241.032636:ERROR:vaapi_wrapper.cc(455)] GetConfigAttributes failed for va_profile 7
[20217:20217:0726/182241.120438:ERROR:sandbox_linux.cc(368)] InitializeSandbox() called with multiple threads in process gpu-process.
[20217:20217:0726/182241.149352:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
[20217:20217:0726/182241.204625:ERROR:gles2_cmd_decoder.cc(18461)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[20217:20217:0726/182241.208930:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182255.379961:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182255.400308:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.316376:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.344654:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.350918:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.363405:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.394713:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.396760:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.411122:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.442865:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.445224:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.503684:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.530002:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.547899:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.583440:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[20217:20217:0726/182256.589853:ERROR:gles2_cmd_decoder.cc(10734)] [.DisplayCompositor]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
Comment 7 KJ Liew 2019-07-27 02:02:22 UTC
Created attachment 144875 [details] [review]
libva-vdpau-driver-chromium AUR patch

Added patch for libva-vdpau-driver-chromium AUR.
Fixed build error and <unknown profile>.
Comment 8 Ilia Mirkin 2019-07-27 02:21:20 UTC
(In reply to KJ Liew from comment #6)
> I don't know how you had verified VDPAU to make sure it is working. Running
> vdpauinfo is not enough.

mplayer -vo vdpau the-video

See https://nouveau.freedesktop.org/wiki/VideoAcceleration/ -- "Using VDPAU". (You also have to tell it to use the "vdpau" codecs.)

> $ LIBVA_DRIVER_NAME=vdpau VDPAU_DRIVER=nouveau chromium
> [19735:19735:0726/182126.662312:ERROR:vaapi_wrapper.cc(455)]
> GetConfigAttributes failed for va_profile 13
> [19735:19735:0726/182126.662353:ERROR:vaapi_wrapper.cc(455)]
> GetConfigAttributes failed for va_profile 6
> [19735:19735:0726/182126.662359:ERROR:vaapi_wrapper.cc(455)]
> GetConfigAttributes failed for va_profile 7
> [19735:19735:0726/182126.764805:ERROR:sandbox_linux.cc(368)]
> InitializeSandbox() called with multiple threads in process gpu-process.
> [19735:19735:0726/182126.808082:ERROR:buffer_manager.cc(488)]
> [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error
> from previous GL command
> romium/chromium --type=gpu-process
> --field-trial-handle=7302155616383548209,8433935369873353489,131072
> --disable-breakpad
> --gpu-
> preferences=KAAAAAAAAAAgAACgAQAAAAAAAAAAAGAAAAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAA
> --service-request-channel-token=6382519074401266972:
> ../mesa-19.1.3/src/gallium/drivers/nouveau/nvc0/nvc0_video.c:43:
> nvc0_decoder_begin_frame: Assertion `ret == 2' failed.

Ah yeah, that's something else.

This appears like it would happen as a result of

   ret = nouveau_bo_map(bsp_bo, NOUVEAU_BO_WR, dec->client);

failing. No clue how that could happen... OTOH, I see messages about threads, and certainly video decoding + GL in different threads is highly likely to be broken with nouveau.

Please try to build a debug version, see if that yields more info. Also look for errors in dmesg.
Comment 9 KJ Liew 2019-07-28 03:30:21 UTC
Created attachment 144895 [details]
vdpau_dmesg

$ LIBVA_DRIVER_NAME=vdpau VDPAU_DRIVER=nouveau chromium
file:///path/to/h264.mp4
Comment 10 Ilia Mirkin 2019-07-29 13:31:34 UTC
I've pushed a number of changes which make vdpau work, at least on a GK208. Didn't get a chance to test pre-fermi.

Someone who has the correct quantity of gst installed can test out whether that works now too perhaps?
Comment 11 KJ Liew 2019-07-29 22:44:40 UTC
$ LIBVA_DRIVER_NAME=nouveau chromium
nve4_set_surface_info:969 - unsupported surface format, try is_format_supported() !
nve4_set_surface_info:969 - unsupported surface format, try is_format_supported() !
nve4_set_surface_info:969 - unsupported surface format, try is_format_supported() !
nve4_set_surface_info:969 - unsupported surface format, try is_format_supported() !
nve4_set_surface_info:969 - unsupported surface format, try is_format_supported() !

$ LIBVA_DRIVER_NAME=vdpau VDPAU_DRIVER=nouveau chromium

[  550.938006] chromium[1880]: segfault at 1ad ip 00007fef0d3c9afb sp 00007ffc0e96a530 error 4 in libvdpau_nouveau.so.1.0.0[7fef0d0ad000+4ea000]
[  550.938013] Code: 55 41 54 55 48 89 fd 53 48 83 ec 08 4c 8b a7 e8 04 00 00 48 8b 9f 20 05 00 00 4c 8b af c0 03 00 00 41 0f b6 44 24 02 c0 e8 07 <38> 83 ad 01 00 00 74 25 48 83 bb f0 01 00 00 00 74 15 48 8d bb f0
[  551.612811] ------------[ cut here ]------------
[  551.612912] WARNING: CPU: 3 PID: 168 at drivers/gpu/drm/nouveau/nvif/vmm.c:68 nvif_vmm_put.cold+0xc/0x13 [nouveau]
[  551.612912] Modules linked in: fuse rfcomm cmac bnep nls_iso8859_1 nls_cp437 vfat fat hid_logitech_hidpp mousedev joydev input_leds snd_hda_codec_hdmi bridge stp llc nouveau edac_mce_amd kvm_amd hid_logitech_dj ccp rng_core kvm irqbypass btusb mxm_wmi snd_hda_codec_realtek btrtl wmi btbcm btintel i2c_algo_bit ttm snd_hda_codec_generic bluetooth ledtrig_audio drm_kms_helper hid_generic snd_hda_intel drm crct10dif_pclmul snd_hda_codec crc32_pclmul ecdh_generic snd_hda_core usbhid rfkill ghash_clmulni_intel snd_hwdep ecc snd_pcm agpgart hid syscopyarea r8169 sysfillrect aesni_intel snd_timer sysimgblt realtek sp5100_tco fb_sys_fops aes_x86_64 snd crypto_simd cryptd fam15h_power k10temp pcspkr libphy glue_helper soundcore i2c_piix4 evdev pcc_cpufreq mac_hid acpi_cpufreq crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 ohci_pci sd_mod ahci libahci libata xhci_pci crc32c_intel ehci_pci scsi_mod xhci_hcd ehci_hcd ohci_hcd
[  551.612945] CPU: 3 PID: 168 Comm: kworker/3:1 Not tainted 5.2.3-arch1-1-ARCH #1
[  551.612946] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./970A-DS3P, BIOS FD 02/26/2016
[  551.612986] Workqueue: events nouveau_cli_work [nouveau]
[  551.613026] RIP: 0010:nvif_vmm_put.cold+0xc/0x13 [nouveau]
[  551.613028] Code: 45 31 e4 e9 65 1d f1 ff 48 c7 c7 98 1a c6 c0 e8 f3 04 d6 d3 0f 0b 45 31 e4 e9 4f 1d f1 ff 48 c7 c7 e8 1a c6 c0 e8 dd 04 d6 d3 <0f> 0b e9 dc 21 f1 ff 48 c7 c7 e8 1a c6 c0 e8 ca 04 d6 d3 0f 0b b8
[  551.613029] RSP: 0018:ffffb14c41d1bdc8 EFLAGS: 00010246
[  551.613030] RAX: 0000000000000024 RBX: ffffb14c41d1bdf0 RCX: 0000000000000000
[  551.613031] RDX: 0000000000000000 RSI: ffff9ea8dead76e8 RDI: 00000000ffffffff
[  551.613032] RBP: ffffb14c41d1be20 R08: 00000000000003b2 R09: 0000000000000001
[  551.613032] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9ea8c18e3780
[  551.613033] R13: dead000000000200 R14: dead000000000100 R15: ffff9ea8d8ad76a8
[  551.613034] FS:  0000000000000000(0000) GS:ffff9ea8deac0000(0000) knlGS:0000000000000000
[  551.613035] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  551.613035] CR2: 00007f3038178000 CR3: 00000003ef73e000 CR4: 00000000000406e0
[  551.613036] Call Trace:
[  551.613080]  nouveau_vma_del+0x81/0xc0 [nouveau]
[  551.613121]  nouveau_gem_object_delete_work+0x36/0x60 [nouveau]
[  551.613161]  nouveau_cli_work+0xbd/0x100 [nouveau]
[  551.613165]  process_one_work+0x1d1/0x3e0
[  551.613167]  worker_thread+0x4a/0x3d0
[  551.613170]  kthread+0xfb/0x130
[  551.613171]  ? process_one_work+0x3e0/0x3e0
[  551.613172]  ? kthread_park+0x80/0x80
[  551.613175]  ret_from_fork+0x22/0x40
[  551.613177] ---[ end trace eae1db9979ded55f ]---
Comment 12 Ilia Mirkin 2019-07-29 23:00:08 UTC
(In reply to KJ Liew from comment #11)
> $ LIBVA_DRIVER_NAME=nouveau chromium
> nve4_set_surface_info:969 - unsupported surface format, try
> is_format_supported() !

This means someone's trying to use an image format (i.e. ARB_shader_image_load_store image) that's not supported by the backend. Guess it works OK on AMD, so they just use it... sigh. Looks like it just takes the fb's format and sticks it into an image. That's definitely not generically OK.

Maybe the compute pipeline just needs to check if it's running on radeonsi, since it's not a generic gallium API usage.

Just noticed that mpv supports VA-API -- I'll try using that to test it later.
Comment 13 KJ Liew 2019-08-10 17:55:33 UTC
Both VA-API and VDPAU do not play video on GK208B using mpv. There was only sound and black screen.

Linux 5.2.7-arch1-1-ARCH
local/libva-mesa-driver 19.1.4-1
local/mesa 19.1.4-1
local/mesa-demos 8.4.0-1
local/mesa-vdpau 19.1.4-1

$ LIBVA_DRIVER_NAME=nouveau mpv --hwdec=vaapi -vo=vaapi /path/to/MP4
Playing: /path/to/MP4
 (+) Video --vid=1 (*) (h264 1280x720 23.976fps)
 (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
Using hardware decoding (vaapi).
AO: [pulse] 44100Hz stereo 2ch float
VO: [vaapi] 1280x720 vaapi[nv12]
nve4_set_surface_info:969 - unsupported surface format, try is_format_supported() !
nve4_set_surface_info:969 - unsupported surface format, try is_format_supported() !
nve4_set_surface_info:969 - unsupported surface format, try is_format_supported() !
nve4_set_surface_info:969 - unsupported surface format, try is_format_supported() !
nve4_set_surface_info:969 - unsupported surface format, try is_format_supported() !

$ VDPAU_DRIVER=nouveau mpv --hwdec=vdpau -vo=opengl /path/to/MP4 
Driver 'opengl' has been replaced with 'gpu'!
Playing: /path/to/MP4
 (+) Video --vid=1 (*) (h264 1280x720 23.976fps)
 (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
Cannot load libcuda.so.1
Using hardware decoding (vdpau).
VO: [gpu] 1280x720 vdpau[yuv420p]
AO: [pulse] 44100Hz stereo 2ch float
AV: 00:00:12 / 00:02:03 (10%) A-V:  0.000
Comment 14 Ilia Mirkin 2019-08-10 18:08:49 UTC
(In reply to KJ Liew from comment #13)
> Both VA-API and VDPAU do not play video on GK208B using mpv. There was only
> sound and black screen.
> 
> Linux 5.2.7-arch1-1-ARCH
> local/libva-mesa-driver 19.1.4-1
> local/mesa 19.1.4-1
> local/mesa-demos 8.4.0-1
> local/mesa-vdpau 19.1.4-1
> 
> $ LIBVA_DRIVER_NAME=nouveau mpv --hwdec=vaapi -vo=vaapi /path/to/MP4
> Playing: /path/to/MP4
>  (+) Video --vid=1 (*) (h264 1280x720 23.976fps)
>  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
> Using hardware decoding (vaapi).
> AO: [pulse] 44100Hz stereo 2ch float
> VO: [vaapi] 1280x720 vaapi[nv12]
> nve4_set_surface_info:969 - unsupported surface format, try
> is_format_supported() !
> nve4_set_surface_info:969 - unsupported surface format, try
> is_format_supported() !
> nve4_set_surface_info:969 - unsupported surface format, try
> is_format_supported() !
> nve4_set_surface_info:969 - unsupported surface format, try
> is_format_supported() !
> nve4_set_surface_info:969 - unsupported surface format, try
> is_format_supported() !

Yep, I know about this. Needs yet another change... just need to figure out how to best resolve it.

> 
> $ VDPAU_DRIVER=nouveau mpv --hwdec=vdpau -vo=opengl /path/to/MP4 
> Driver 'opengl' has been replaced with 'gpu'!
> Playing: /path/to/MP4
>  (+) Video --vid=1 (*) (h264 1280x720 23.976fps)
>  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
> Cannot load libcuda.so.1
> Using hardware decoding (vdpau).
> VO: [gpu] 1280x720 vdpau[yuv420p]
> AO: [pulse] 44100Hz stereo 2ch float
> AV: 00:00:12 / 00:02:03 (10%) A-V:  0.000

mpv doesn't seem to work, yeah. FWIW I'd expect -vo vdpau to work (not -vo opengl, which is unlikely to work with vdpau decoding). But it doesn't, I get some kind of error (something is trying to submit a batch with an unregistered bo or something).

mplayer works fine though. See https://nouveau.freedesktop.org/wiki/VideoAcceleration/ for instructions on how to use it.
Comment 15 KJ Liew 2019-08-11 00:13:28 UTC
(In reply to Ilia Mirkin from comment #14)
> Yep, I know about this. Needs yet another change... just need to figure out
> how to best resolve it.
Thanks for looking into this. I believe this is the final hurdle to get Chromium-vaapi working with Nouveau.
 
> > 
> > $ VDPAU_DRIVER=nouveau mpv --hwdec=vdpau -vo=opengl /path/to/MP4 
> > Driver 'opengl' has been replaced with 'gpu'!
> > Playing: /path/to/MP4
> >  (+) Video --vid=1 (*) (h264 1280x720 23.976fps)
> >  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
> > Cannot load libcuda.so.1
> > Using hardware decoding (vdpau).
> > VO: [gpu] 1280x720 vdpau[yuv420p]
> > AO: [pulse] 44100Hz stereo 2ch float
> > AV: 00:00:12 / 00:02:03 (10%) A-V:  0.000
> 
> mpv doesn't seem to work, yeah. FWIW I'd expect -vo vdpau to work (not -vo
> opengl,

It works for r600 and radeonsi on my 2 other laptops using mpv and the same command-line using -vo gpu. I think it also works with Geforce9300/Nouveau but need to double check again.
Comment 16 Ilia Mirkin 2019-08-11 00:31:48 UTC
(In reply to KJ Liew from comment #15)
> (In reply to Ilia Mirkin from comment #14)
> > > $ VDPAU_DRIVER=nouveau mpv --hwdec=vdpau -vo=opengl /path/to/MP4 
> > > Driver 'opengl' has been replaced with 'gpu'!
> > > Playing: /path/to/MP4
> > >  (+) Video --vid=1 (*) (h264 1280x720 23.976fps)
> > >  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
> > > Cannot load libcuda.so.1
> > > Using hardware decoding (vdpau).
> > > VO: [gpu] 1280x720 vdpau[yuv420p]
> > > AO: [pulse] 44100Hz stereo 2ch float
> > > AV: 00:00:12 / 00:02:03 (10%) A-V:  0.000
> > 
> > mpv doesn't seem to work, yeah. FWIW I'd expect -vo vdpau to work (not -vo
> > opengl,
> 
> It works for r600 and radeonsi on my 2 other laptops using mpv and the same
> command-line using -vo gpu. I think it also works with Geforce9300/Nouveau
> but need to double check again.

Apologies - I should have clarified I was talking about nouveau specifically. The issue is multi-threaded submission, which mpv (at least at one point) attempted to do with hwdec + video output in separate threads.

mpv -vo vdpau --hwdec vdpau should work. But it doesn't, at least not in my testing. Hits an assert in libdrm about rather incorrect usage. Haven't investigated it though.

Like I said, this works fine with mplayer. This is my preferred player, so I tend not to go much further.
Comment 17 KJ Liew 2019-08-13 22:17:17 UTC
On GeForce 9400, mpv works with both VA-API and VDPAU. This is on GNOME/Xorg, I can't checkout GNOME/Wayland on this machine.

Linux 5.2.8-arch1-1-ARCH
local/libva-mesa-driver 19.1.4-1
local/mesa 19.1.4-1
local/mesa-vdpau 19.1.4-1

$ lspci | grep VGA
04:00.0 VGA compatible controller: NVIDIA Corporation C79 [GeForce 9400] (rev b1)

$ mpv --hwdec=vaapi -vo=vaapi /path/to/MP4
Playing: /path/to/MP4
 (+) Video --vid=1 (*) (h264 1280x720 23.976fps)
 (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
Using hardware decoding (vaapi).
AO: [pulse] 44100Hz stereo 2ch float
VO: [vaapi] 1280x720 vaapi[nv12]
AV: 00:00:24 / 00:02:03 (20%) A-V:  0.000

$ mpv --hwdec=vdpau -vo=vdpau /path/to/MP4
Playing: /path/to/MP4
 (+) Video --vid=1 (*) (h264 1280x720 23.976fps)
 (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
Using hardware decoding (vdpau).
AO: [pulse] 44100Hz stereo 2ch float
VO: [vdpau] 1280x720 vdpau[yuv420p]
[vo/vdpau] Compositing window manager detected. Assuming timing info is inaccurate.
AV: 00:00:16 / 00:02:03 (13%) A-V:  0.000
Comment 18 Ilia Mirkin 2019-08-21 04:36:57 UTC
I've pushed a change to mesa which disables the compute paths for the video compositor on nouveau (well, basically just enabled for AMD). Unfortunately it was relying on AMD-specific features. We probably could have implemented these, but the benefits are dubious, so I didn't want to bother...

This also seems to fix the assertion in libdrm, which is probably triggerable in more general ways, but oh well.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=958390a9bf8904522a50f8e9c26c50c96179c183

commit 958390a9bf8904522a50f8e9c26c50c96179c183
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Sat Aug 17 12:13:34 2019 -0400

    gallium/vl: use compute preference for all multimedia, not just blit
    
    The compute paths in vl are a bit AMD-specific. For example, they (on
    nouveau), try to use a BGRX8 image format, which is not supported.
    Fixing all this is probably possible, but since the compute paths aren't
    in any way better, it's difficult to care.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111213
    Fixes: 9364d66cb7 (gallium/auxiliary/vl: Add video compositor compute shader render)
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Reviewed-by: Marek Ol<C5><A1><C3><A1>k <marek.olsak@amd.com>
Comment 19 KJ Liew 2019-08-24 02:34:20 UTC
Thanks for the patch. I backported it for mesa-19.1.5 and mpv works for VA-API and VDPAU. Chromium-vaapi works, too. Gstreamer-vaapi still failed, but I would wait til the next stable 1.18 release. The current stable 1.16 release seems too buggy.

I noticed that the patch was not included in the recently branched 19.2 release. Any plan to backport this to 19.1 or 19.2?
Comment 20 Ilia Mirkin 2019-08-24 02:51:39 UTC
I pushed the patch after both of those releases were cut. I expect it to be included in the next 19.1.x and 19.2.x releases (based on the "Fixes" tag).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.