| Priority | medium |
|---|---|
| Bug ID | 76564 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | [AMD Fusion E-350] Radeon UVD giving incorrect fps when playing videos |
| Severity | normal |
| Classification | Unclassified |
| OS | Linux (All) |
| Reporter | jeroenk61@hotmail.com |
| Hardware | x86-64 (AMD64) |
| Status | NEW |
| Version | 10.1 |
| Component | Drivers/Gallium/r600 |
| Product | Mesa |
Created attachment 96302 [details]
dmesg
I'm currently experiencing problems when playing videos on my AMD fusion e-350
with HD6310 graphics(r600) with OpenELEC 4 beta2, which uses Mesa 10.1 and the
latest Linux 3.13 kernel. This is with the system connected through HDMI to my
television.
Either the video is being decoded too slow, which causes skipped frames, or it
is decoding too fast, which causes missed frames.
23.976fps becomes 23.92/23.95 and sometimes goes to 22.93fps
25fps becomes 25.02 or 25.05fps
29.97 interlaced decodes with around 58fps instead of 59.94fps.
It is if like the clock that is used for decoding is all over the place (PLL
issue?)
I confirmed with the old OpenELEC 3, which uses AMD's fglrx, and everything is
playing perfectly and the fps is spot on, as in. 23.98fps, 25fps and 59.94fps.
I also tried disabling the new VDPAU hardware acceleration and VDPAU mixer, but
with no effect.
All tests were done with the television frame rate being matched to the
content, so for example in the case of 23.976fps content the television is at
the same frequency.
| What | Removed | Added |
|---|---|---|
| Summary | [AMD Fusion E-350] Radeon UVD giving incorrect fps when play= ing videos | [AMD Fusion E-350] HDMI refresh rates doesn't match expectat= ions |
HDMI refresh rate seems to be off, UVD decoding speed is compl= etely unrelated to this.
(In reply to comment #0= ) > 23.976fps becomes 23.92/23.95 and sometimes goes= to 22.93fps > 25fps becomes 25.02 or 25.05fps > 29.97 interlaced decodes with around 58fps instead of 59.94fps. That the refresh frequency is a bit off might happen, but not that much. How did you measured those nunmbers?
Sorry for not providing that information. OpenELEC uses XBMC to play the videos. XBMC has the option to display stats (http://wiki.xbmc.org/?title=Codecinfo). One of the stats is the actual video frame rate. Other useful stats are the amount of frames dropped and skipped. When I look at for example the numbers 23.95 and 23.92 it seems it is off by 1/1000 or 2/1000 respectively.
(In reply to comment #5) > Probably a duplicate of bug 71753. Yes I read that report. What I don't understand is how the audio clock, uvd clock, hdmi clock, etc relate to each other. For audio I use the realtek chip and it's SPDIF. I guess with the audio clock, the HDMI audio clock is used? Which in my case is not used I guess.
(In reply to comment #6) > (In reply to comment #5) > > Probably a duplicate of bug 71753. > > Yes I read that report. What I don't understand is how the audio clock, uvd > clock, hdmi clock, etc relate to each other. > > For audio I use the realtek chip and it's SPDIF. I guess with the audio > clock, the HDMI audio clock is used? Which in my case is not used I guess. They are not really related on the hw side. UVD decodes as fast as it can based on it's own clocks. When the decoded frame is displayed is up to the application. The audio chip has it's own clock and the display has it's own clock. The hdmi audio information is embedded in the display stream. The monitor uses special packets that the GPU embeds in the display stream to reconstruct the audio stream on the monitor based on the display clock. There seem to be cases where the hdmi stream is not set up properly so the audio clock is not recovered properly on the monitor side.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > Probably a duplicate of bug 71753. > > > > Yes I read that report. What I don't understand is how the audio clock, uvd > > clock, hdmi clock, etc relate to each other. > > > > For audio I use the realtek chip and it's SPDIF. I guess with the audio > > clock, the HDMI audio clock is used? Which in my case is not used I guess. > > They are not really related on the hw side. UVD decodes as fast as it can > based on it's own clocks. When the decoded frame is displayed is up to the > application. The audio chip has it's own clock and the display has it's own > clock. The hdmi audio information is embedded in the display stream. The > monitor uses special packets that the GPU embeds in the display stream to > reconstruct the audio stream on the monitor based on the display clock. > There seem to be cases where the hdmi stream is not set up properly so the > audio clock is not recovered properly on the monitor side. Okay, but doesnt that mean in this case it is a problem with the display (HDMI?) clock, as I am not using HDMI audio? Is there a way I could get more detailed logging of what is happening on my system?
Created attachment 96379 [details]
drm_debug log
This big drm log was created while starting xbmc with the display set to 50fps,
then playing a 23.976fps test clip and afterwards switching back to 50fps
In the log I notice:
[ 1.982022] [drm:drm_calc_timestamping_constants], crtc 12: clock 148500 kHz
framedur 20000000 linedur 17777, pixeldur 6
[ 32.608813] [drm:drm_calc_timestamping_constants], crtc 12: clock 74176 kHz
framedur 41708234 linedur 37073, pixeldur 13
[ 124.623308] [drm:drm_calc_timestamping_constants], crtc 12: clock 148500 kHz
framedur 20000000 linedur 17777, pixeldur 6
These correspond to the 50fps -> 23.976fps -> 50fps mode switches
Does this log tell you guys what is going wrong?
(In reply to comment #8) > Okay, but doesnt that mean in this case it is a problem with the display > (HDMI?) clock, as I am not using HDMI audio? > > Is there a way I could get more detailed logging of what is happening on my > system? I don't know how XBMC calculates the frame rate off hand. The PLL used to generate the display clock may not always match the exact pixel clock of the monitor. The driver calculates pll dividers to get as close as possible to the pixel clock of the display mode. See radeon_compute_pll_avivo() in radeon_display.c
Created attachment 96380 [details]
drm debug log with kms and driver level
I found out to see the PLL numbers KMS level debugging needed to be on. So I
redid the test and attached a new log file that shows the pll information.
(In reply to comment #= 10) > (In reply to comment #8) > > Okay, but doesnt that mean in this case it is a problem with the = display > > (HDMI?) clock, as I am not using HDMI audio? > >=20 > > Is there a way I could get more detailed logging of what is happe= ning on my > > system? >=20 > I don't know how XBMC calculates the frame rate off hand. The PLL use= d to > generate the display clock may not always match the exact pixel clock = of the > monitor. The driver calculates pll dividers to get as close as possib= le to > the pixel clock of the display mode. See radeon_compute_pll_avivo() in > radeon_display.c Yeah, but on multiple occasions I had the feeling that fglrx might do a bet= ter job on this than the radeon kernel module. We might want to take a second look at this and try to compare the settings fglrx and radeon uses for the same mode.
Do the PLL values in the log files I posted indicate a problem, or are they okay? How can you see the PLL values fglrx is using?
(In reply to comment #13) > Do the PLL values in the log files I posted indicate a problem, or are they > okay? [drm:radeon_compute_pll_avivo], 14875, pll dividers - fb: 23.8 ref: 2, post 8 [drm:radeon_compute_pll_avivo], 7406, pll dividers - fb: 23.7 ref: 2, post 16 The display pll looks fine to me. The clock formula is: pixel_clock = (reference_frequency * feedback_divider) / (reference_divider * post_divider) The reference frequency is 100 Mhz, so: (100Mhz * 23.8) / (2 * 8) = 148.75Mhz (100Mhz * 23.7) / (2 * 16) = 74.0625Mhz > > How can you see the PLL values fglrx is using? You'd need to dump the PLL registers using radeonreg (http://cgit.freedesktop.org/~airlied/radeontool/). PPLL1 0x400 - ref div - bits 9:0 0x404 - fb div - whole part bits 26:16, fractional part bits 3:0 0x408 - post div - bits 6:0 PPLL2 0x440 - ref div - bits 9:0 0x444 - fb div - whole part bits 26:16, fractional part bits 3:0 0x448 - post div - bits 6:0 e.g., ./radeonreg regmatch 0x400
(In reply to comment #14) > (In reply to comment #13) > > Do the PLL values in the log files I posted indicate a problem, or are they > > okay? > > [drm:radeon_compute_pll_avivo], 14875, pll dividers - fb: 23.8 ref: 2, post 8 > [drm:radeon_compute_pll_avivo], 7406, pll dividers - fb: 23.7 ref: 2, post 16 > > The display pll looks fine to me. The clock formula is: > > pixel_clock = (reference_frequency * feedback_divider) / (reference_divider > * post_divider) > > The reference frequency is 100 Mhz, so: > > (100Mhz * 23.8) / (2 * 8) = 148.75Mhz > > (100Mhz * 23.7) / (2 * 16) = 74.0625Mhz > > > > > How can you see the PLL values fglrx is using? > > You'd need to dump the PLL registers using radeonreg > (http://cgit.freedesktop.org/~airlied/radeontool/). > PPLL1 > 0x400 - ref div - bits 9:0 > 0x404 - fb div - whole part bits 26:16, fractional part bits 3:0 > 0x408 - post div - bits 6:0 > PPLL2 > 0x440 - ref div - bits 9:0 > 0x444 - fb div - whole part bits 26:16, fractional part bits 3:0 > 0x448 - post div - bits 6:0 > > e.g., ./radeonreg regmatch 0x400 I got the results with fglrx: PPLL1@50Hz: fb=23.7 ref=2 post=6 PPLL2@50Hz: fb=296.16 ref=7 post=6 PPLL1@23.976Hz: fb=23.7 ref=2 post=12 PPLL2@23.976Hz: fb=296.16 ref=7 post=6 PPLL2 does seem to be used as it does not change. PPLL1 has different values than with the radeon OSS driver. What does this mean?
(In reply to comment #15) > I got the results with fglrx: > PPLL1@50Hz: fb=23.7 ref=2 post=6 > PPLL1@23.976Hz: fb=23.7 ref=2 post=12 > > PPLL2 does seem to be used as it does not change. PPLL1 has different values > than with the radeon OSS driver. What does this mean? (100Mhz * 23.7) / (2 * 6) = 197.5Mhz (100Mhz * 23.7) / (2 * 12) = 98.75Mhz Maybe fglrx is using different modelines with a different display clock? Can you print what modes are being used with fglrx and radeon? E.g., xrandr --verbose.
| What | Removed | Added |
|---|---|---|
| Product | Mesa | DRI |
| Version | 10.1 | unspecified |
| Component | Drivers/Gallium/r600 | DRM/Radeon |
(In reply to comment #16) > (In reply to comment #15) > > I got the results with fglrx: > > PPLL1@50Hz: fb=23.7 ref=2 post=6 > > PPLL1@23.976Hz: fb=23.7 ref=2 post=12 > > > > PPLL2 does seem to be used as it does not change. PPLL1 has different values > > than with the radeon OSS driver. What does this mean? > > > (100Mhz * 23.7) / (2 * 6) = 197.5Mhz > > (100Mhz * 23.7) / (2 * 12) = 98.75Mhz > > Maybe fglrx is using different modelines with a different display clock? > Can you print what modes are being used with fglrx and radeon? E.g., xrandr > --verbose. I attached both xrandr outputs. I also noticed that for fgrlx the PLL values are the same for 50Hz,60Hz and 59.94Hz output.