| View previous topic :: View next topic |
| Author |
Message |
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
 Posted: Wed Mar 25, 2015 5:09 pm Post subject: info on RL exp: radeon, kernel upgrades, vdpau, X dies |
 |
|
Over the past two months, I've been going through interesting times regarding upgrading kernels beyond 3.17.X, enabling VDPAU and testing video playback.
I'm reporting some of my real life experiences regarding same. I hope this is of benefit for anyone else encountering the same problems.
I don't know if this also applies to people with nvidia or intel GPUs, but for ati GPUs, kernel 3.18.0 marks the transistion when the kernel made access to ati GPU built-in video hardware decoders available. This is a snip of vdpuinfo output running under gentoo-sources-3.17.8-r1: | Code: | vdpauinfo : gentoo-sources-3.17.8-r1 : xf86-video-ati-9999 (Installed versions: 9999{tbz2}[1](06:13:13 PM 03/23/2015)(udev -glamor))
display: :1 screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0
Video surface:
name width height types
-------------------------------------------
420 8192 8192 NV12 YV12
422 8192 8192 UYVY YUYV
444 8192 8192 Y8U8V8A8 V8U8Y8A8
Decoder capabilities:
name level macbs width height
----------------------------------------------------
MPEG1 0 262144 8192 8192
MPEG2_SIMPLE 3 262144 8192 8192
MPEG2_MAIN 3 262144 8192 8192
H264_BASELINE --- not supported ---
H264_MAIN --- not supported ---
H264_HIGH --- not supported ---
VC1_SIMPLE --- not supported --- |
This is the same system rebooted under gentoo-sources-3.19.2: | Code: | vdpauinfo : gentoo-sources-3.19.2 : xf86-video-ati-9999 (Installed versions: 9999{tbz2}[1](06:13:13 PM 03/23/2015)(udev -glamor))
display: :1 screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0
Video surface:
name width height types
-------------------------------------------
420 8192 8192 NV12 YV12
422 8192 8192 UYVY YUYV
444 8192 8192 Y8U8V8A8 V8U8Y8A8
Decoder capabilities:
name level macbs width height
----------------------------------------------------
MPEG1 0 9216 2048 1152
MPEG2_SIMPLE 3 9216 2048 1152
MPEG2_MAIN 3 9216 2048 1152
H264_BASELINE 41 9216 2048 1152
H264_MAIN 41 9216 2048 1152
H264_HIGH 41 9216 2048 1152
VC1_SIMPLE --- not supported ---
VC1_MAIN --- not supported ---
VC1_ADVANCED 4 9216 2048 1152
MPEG4_PART2_SP --- not supported --- |
Not only were the video hardware decoders not actually available prior to 3.18.0, the information reported represented placeholders for future real info. This is perfectly fine for kernel development because they were making sure the structure for supporting access to the hardware decoders was in place and working first. This is known as "A Good Thing".
However, if you had vdpau configured and enabled for ati as per the Gentoo Wiki VDPAU page and you set your video player to use hardware decoding (if available), then you may have video playback issues upon upgrading to any kernel starting with 3.18.0. This is going to depend on many different factors including which model ati GPU, ati driver version, xorg-server version, mesa version .. yada yada yada.
The sympton is your screen (or screens) will blank then come back. The mouse and keyboard will stop responding. Don't panic. Your life has not ended and not all is lost.
In fact, everything else is still running fine. If you had a torrent client running, it's till active in whatever swarms it's part of. If you had an irc client up, people may wonder where you are but it still shows you lurking in the groups you were in. If you're doing some XDCC downloads, those are still happening. Any large file transfers from one system to another? Still happening. Any file shares you set up? Still happening. The only thing that's halted is X-windows.
What you need to do is log in as root from another computer, monitor whatever processes you feel need to complete (file transfers are a good thing to wait for completion) and then 'kill -u username'.
To 'fix' this problem, the simple work around is to disable vdpau in your video player. For 'mpv player' this is ~/.config/mpv/mpv.conf. You want your vdpau settings to look like this: | Code: | # Oops! vdpau is still not ready for prime time yet!
#hwdec=vdpau
#vo=vdpau,opengl,
# Instead - choose opengl if available - otherwise let the player choose a different software renderer
vo=opengl, |
Note: as far as I know, the default for all video players is to use software decoding.
The trigger for this seems to be when one of the built-in video hardware decoders is asked to decode a video for which it is not correct or the perhaps the data stream is malformed. The fail mode is .. ungraceful .. to say the least.
I didn't see anything in the X.org logs that would indicate the source of the problem though I suspect xf86-video-ati driver. I'm not sure how and where I can collect better failure information and since this is my main workstation and also functions as the house server and network backup, I don't really like using it as a test platform. 
So long as I don't play Russian Roullette by trying to use video hardware decoding, my system runs real sweet. Since I don't have any problem playing virtually all of my 1080p video collection and since all 10-bit videos would use opengl anyway, the current problem is moot for me.
In other words, ati vdpau for video hardware decoding is not ready for prime time yet (for at least some ati GPUs) whatever the root cause is.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
 |
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Wed Mar 25, 2015 7:32 pm Post subject: Re: info on RL exp: radeon, kernel upgrades, vdpau, X dies |
|
|
| dufeu wrote: | | I don't know if this also applies to people with nvidia or intel GPUs, but for ati GPUs, kernel 3.18.0 marks the transistion when the kernel made access to ati GPU built-in video hardware decoders available. |
That's incorrect. I've been using VDPAU_DRIVER=r600 for several years. |
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Fri Mar 27, 2015 2:01 am Post subject: Re: info on RL exp: radeon, kernel upgrades, vdpau, X dies |
|
|
| Ant P. wrote: | | dufeu wrote: | | I don't know if this also applies to people with nvidia or intel GPUs, but for ati GPUs, kernel 3.18.0 marks the transistion when the kernel made access to ati GPU built-in video hardware decoders available. |
That's incorrect. I've been using VDPAU_DRIVER=r600 for several years. |
You might be correct. I could be wrong in my assumption that vdpauinfo is not directly reporting what the kernel has exposed. You didn't say so but if you're using fxlgr (AMD/ATI's) proprietary driver, it may actually be a driver issue and I don't use the propriatary driver. However, that doesn't match my actual recorded results. In the two sets of results I cut and pasted from, the only difference between them is which kernel I booted with. vdpauinfo reports it's results here using the same installed xf86-video-ati driver in each case. That makes is pretty certain that the different kernel versions are exposing different levels of information.
I agree that access to the vdpau structures has been in the kernel for awhile now.
However, I'm can only go by what vdpauinfo reports. It's pretty clear that prior to 3.18 for the ati GPUs I have access to, that the vdpau structure was there but actual usable access to the hardware decoders was not there. Note above that I'm comparing the last available gentoo-sources-3.17.8-r1 with 3.19.2. I also tested vanilla-sources-3.17.X series and both vanilla and gentoo sources 3.18.X series. The vdpauinfo results for the 3.18.X series match what you see for 3.19.2.
You can also tell that the 3.17.X information exposed by the kernel is bogus by inspection. If you look at the available specs of the GPU chips described built-in hardware video decoders, there are no such decoders with playback capabilities of 8192x8192 pixels. i.e. Hence my assertion that the reported figures are placeholder figures.
On the other hand, in the 3.19.2 kernel, the reported playback pixel dimensions of 2048x1152 match AMD's reported specs for their hardware video decoders.
This is what the full vdpauinfo report looks like under 3.19.2: | Code: | # vdpauinfo
display: :0 screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0
Video surface:
name width height types
-------------------------------------------
420 8192 8192 NV12 YV12
422 8192 8192 UYVY YUYV
444 8192 8192 Y8U8V8A8 V8U8Y8A8
Decoder capabilities:
name level macbs width height
----------------------------------------------------
MPEG1 0 9216 2048 1152
MPEG2_SIMPLE 3 9216 2048 1152
MPEG2_MAIN 3 9216 2048 1152
H264_BASELINE 41 9216 2048 1152
H264_MAIN 41 9216 2048 1152
H264_HIGH 41 9216 2048 1152
VC1_SIMPLE --- not supported ---
VC1_MAIN --- not supported ---
VC1_ADVANCED 4 9216 2048 1152
MPEG4_PART2_SP --- not supported ---
MPEG4_PART2_ASP --- not supported ---
DIVX4_QMOBILE --- not supported ---
DIVX4_MOBILE --- not supported ---
DIVX4_HOME_THEATER --- not supported ---
DIVX4_HD_1080P --- not supported ---
DIVX5_QMOBILE --- not supported ---
DIVX5_MOBILE --- not supported ---
DIVX5_HOME_THEATER --- not supported ---
DIVX5_HD_1080P --- not supported ---
H264_CONSTRAINED_BASELINE --- not supported ---
H264_EXTENDED --- not supported ---
H264_PROGRESSIVE_HIGH --- not supported ---
H264_CONSTRAINED_HIGH --- not supported ---
H264_HIGH_444_PREDICTIVE --- not supported ---
Output surface:
name width height nat types
----------------------------------------------------
B8G8R8A8 8192 8192 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8
R8G8B8A8 8192 8192 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8
R10G10B10A2 8192 8192 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8
B10G10R10A2 8192 8192 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8
Bitmap surface:
name width height
------------------------------
B8G8R8A8 8192 8192
R8G8B8A8 8192 8192
R10G10B10A2 8192 8192
B10G10R10A2 8192 8192
A8 8192 8192
Video mixer:
feature name sup
------------------------------------
DEINTERLACE_TEMPORAL y
DEINTERLACE_TEMPORAL_SPATIAL -
INVERSE_TELECINE -
NOISE_REDUCTION y
SHARPNESS y
LUMA_KEY -
HIGH QUALITY SCALING - L1 -
HIGH QUALITY SCALING - L2 -
HIGH QUALITY SCALING - L3 -
HIGH QUALITY SCALING - L4 -
HIGH QUALITY SCALING - L5 -
HIGH QUALITY SCALING - L6 -
HIGH QUALITY SCALING - L7 -
HIGH QUALITY SCALING - L8 -
HIGH QUALITY SCALING - L9 -
parameter name sup min max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH y 48 2048
VIDEO_SURFACE_HEIGHT y 48 1152
CHROMA_TYPE y
LAYERS y 0 4
attribute name sup min max
-----------------------------------------------------
BACKGROUND_COLOR y
CSC_MATRIX y
NOISE_REDUCTION_LEVEL y 0.00 1.00
SHARPNESS_LEVEL y -1.00 1.00
LUMA_KEY_MIN_LUMA y
LUMA_KEY_MAX_LUMA y |
Don't forget, I'm focusing only on hardware video decoders. vdpau is more than just the decoders. There's also the 'video mixer' which gives access to the built-in video filters as well as other hardware accelerated features.
On my systems, I have hardware acceleration enabled but I now have my video playback blocked from using the decoders.
When the hardware decoders work, they work very well. When they don't, X windows dies hard. Rather than run the risk of having to remotely log in, kill processes and then reboot to be on the safe side, I choose not to use the hardware decoders.
As an aside, moving to the git version of xf86-video-ati made a difference in the numbers movies that I can correctly play using the hardware decoders. The recent commits since version 7.5.0 have markedly increased stability. This is one of the reasons I suspect the hold up here is the radeon driver. I've been monitoring the comments on new commits. I'll definitely pulls those too but I'm holding off that the moment as I wait to see what else may pop up. Don't forget that AMD just recently release support for DRI3 and Present. Like any release of something new, there appears to be a wee bit of pain involved.
--o--
I'd like to re-emphasize that to encounter the conditions I met, certain circumstances must be true:- You have to have vdpau enabled as per the Gentoo wiki VDPAU page in my OP.
- You have to have your video player correctly configure vo (Video Out) to use vdpau first. By default, all media players I'm aware of (in Linux) are configured for opengl and/or xv out of the box. Really. I looked. There are no exceptions in any of the ones I've looked at. In fact, the default is to fail if they can't find a software video decoder. Out of the box, they simply will never try looking for a hardware decoder. You must explicitly tell your media player that a) you have hardware decoding available (vdpau, vaapi usually). b) You have to tell your media player to try using the hardware decoders first and fall back to software decoding if a suitable hardware decoder isn't found.
In other words, you need to do more than simply enabling vdpau.
I hear what you're saying, but are you certain you've actually used ati based hardware video decoders pre 3.18.X? I'm really curious to know which kernel versions and which GPU chips. That would imply some significant differences in binary blobs for the various r600 family chips.
If you really want to check this with pre 3.18.X kernels, this is typical of results I got with mpv's media player under 3.17.8-r1 with vdpau enabled. Of course, mpv was configured to always try vdpau first: | Code: | Playing: /Mov01/Movies Zero-K/Interstellar - 2014/Interstellar.2014.1080p.BluRay.x264-DAA.mkv
(+) Video --vid=1 (h264)
(+) Audio --aid=1 --alang=eng (*) (dts)
(+) Subs --sid=1 --slang=eng (subrip)
Subs --sid=2 --slang=eng 'SDH' (subrip)
Using hardware decoding.
AO: [pulse] 48000Hz 5.1(side) 6ch float
[vdpau] Codec or profile not supported by hardware.
[vdpau] Codec or profile not supported by hardware.
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
Error while decoding frame!
Error using hardware decoding, falling back to software decoding.
VO: [vdpau] 1920x1080 yuv420p
[vo/vdpau] Compositing window manager detected. Assuming timing info is inaccurate.
(Paused) AV: 00:00:06 / 02:49:03 (0%) A-V: -0.000 Cache: 10s+282709KB |
As you can see, it tried several times to use one of the built-in hardware decoders.
Under kernel 3.19.2, this video successfully plays via the built-in hardware decoder.
I consider the message: | Code: | | VO: [vdpau] 1920x1080 yuv420p |
to be a bug though I haven't checked mpv's site if someone's reported it yet. I would have expected to see: | Code: | | VO: [opengl] 1920x1080 yuv420p |
as it's perfectly clear that no available hardware decoder was found.
I haven't had time to look into the fail specifics. I suspect a possible issue with scenarios (for example) where a video is encoded under the H264_HIGH profile but with advanced options not compatible with the designated hardware decoder and then the radeon driver not being able to gracefully cope with the it. That's only speculation but I think it's fairly reasonable.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Sat Apr 11, 2015 9:49 am Post subject: |
|
|
I'm having trouble fully understanding your posts but I think I may be experiencing the same thing. I have a HD4670 and VDPAU was working fine under 3.17. I just jumped back to that version to confirm it wasn't some userspace change. I don't recall if I ever tried playing a Blu-ray under 3.18, perhaps not because it flat out refuses to work now and vdpauinfo reports that H.264 isn't supported at all. On 3.19.3 and 4.0-rc7, I get the same vdpauinfo output as you and playback is jumpy for low quality 1080p and barely moving for high quality (Blu-ray) 1080p. I don't get this blank screen and X lock-up though. Apart from the slow video, everything continues to work normally. You should check your dmesg output because every time I try to use VDPAU, I get this.
| Code: | | [drm:rv770_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed |
I tried switching to profile-based power management but it doesn't seem to let you switch when you boot with DPM enabled. I rebooted with radeon.dpm=0 and selected the high profile. Low quality 1080p played just fine and high quality 1080p improved from barely moving to just jumpy. Maybe "high" doesn't crank the card up as much as DPM can. The DPM code hasn't changed lately. I tried xf86-ati-video-9999 and enabled DRI3 to see if either of those would make a difference but no dice. I fired up Portal to make sure the DPM glitch isn't affecting games but it ran fine. Strange that it would only apply to VDPAU. I guess I'll file a bug on freedesktop.org later. |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Sat Apr 11, 2015 12:05 pm Post subject: |
|
|
| I read that dynpm (not DPM) is more aggressive than the high profile so I tried that and Blu-ray played smoothly. |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
| Posted: Sat Apr 11, 2015 2:47 pm Post subject: |
|
|
| Haven't had a chance to file a bug report yet because I'm looking after my daughter but I did at least make one more interesting discovery. If I boot up normally and disconnect my second screen, it works. If I keep my second screen connected but set it to a lower resolution like 720x480 then 1080p video on the first screen works. Before trying this, I did notice the :1 in dufeu's output so I guess he has a second screen too? I use Zaphod mode though so it's :0.1. |
|
| Back to top |
|
|
Chewi
Developer
Joined: 01 Sep 2003
Posts: 886
Location: Edinburgh, Scotland
|
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Wed Apr 22, 2015 1:28 am Post subject: |
|
|
| Chewi wrote: | | https://bugs.freedesktop.org/show_bug.cgi?id=89987 |
Little late in replying because sometimes I'm a bit erratic in checking things out and following up.
I'm happy my post gave you some hints and leads which appears to have both helped you and uncovered some additional issues. I read your posted bug report and it clarified a few things for me as well. So .. Thanks!
To give you have a better understanding of what I sometimes do: I do indeed run a two display set up. However the :1 versus :0.1 is not a display choice. What I'm doing is sometimes logging into two different WMs at the same time.
What happens is that I always have my systems boot into a CLI login. Depending on what I need to do and which login account I need to do it from, I'll do ctl-alt-F[1-6] to perform additional different account logins as needed. Once logged into the first account, I'll execute XSESSION=kde-4 startx -- :0. On the second account, I'll execute XSESSION=lxqt startx -- :1 and so on. You can switch between each logged in account's CLI and GUI by doing ctl-alt-F1 for the first CLI login, ctl-alt-F2 for the second login, ctl-alt-F7 for the first account's GUI, ctl-alt-F8 for the second account's GUI etc. The ctl-alt-F7 and up assignments are done in the order in which you actually execute each startx command. There are usually 12 function keys and most distributions set up support for up to 6 consoles. So F1-6 are the consoles and F7-12 are the available GUI slots.
I wouldn't try this with the Gnome WM and I wouldn't recommend it with multiple kde GUIs either. I have no idea how well this works with wayland etc. What ever drivers you have must respect their respective 'save state' commands. A sloppy driver will kill you if you try this.
This is a very, very 'old school' way of using X windows and I rather like it. Usually it works pretty well but it's very dependent on stable drivers. 
Oh! Before I forget. It is not a good idea to open different wms using the same account! It's not a problem for X nor your graphics subsytems, but it's really easy to confuse your applications when they're open in two different wms at the same time in the same account.
Of course, if you want to stress test any part of your graphics subsystem ..
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
