While uvd video playback (no difference with mplayer, mpv or xbms) video frequently stops at the loop of several frames, while sound move further. It very similar to video from https://bugs.freedesktop.org/show_bug.cgi?id=73191 but loop is endless (if gpu will not hang there). Sometimes there are visible screen corruptions (color squares) before video looping, sometimes gpu hangs up before visible corruptions. card - rv730 agp, kernels - 3.12.7, 3.13-rc7 and before. mesa, drm, video - from oibaf ppa, i suppose it is current git (own compiled give the same). It looks like disabling ColorTiling2D in xorg.conf.d solve this problem.
I am sorry, disabling ColorTiling2D does not fix it, but it definitely makes situation better. I suppose there are different bugs mixed here, and disabling ColorTiling2D hide some of them.
mesa-9.2.5 (kernel-3.13-rc7) seems to work (at least with mpv), so it looks like regression in mesa.
Can you bisect?
Will try, but this machine is so slow
(In reply to comment #4) > Will try, but this machine is so slow Can you be more specific what you did, which movie you looked? I have the same gfx card and Mesa git, so maybe I can help. Did severall tests for Christian and Alex with UVD. Only this "Sometimes there are visible screen corruptions (color squares)...) makes me wonder. Do you get it during UVD playback or later (xdm/kdm) logout? I see it sometimes since later 3.13-rcX versions and Mesa git during KDM (glamor-0.5.1-39.14) logout. I'll try to get a picture (with photo camera) and retest with 3.12.7 and Mesa 10.0.2. Maybe it arise only after UVD playback.
(In reply to comment #5) > (In reply to comment #4) > > Will try, but this machine is so slow > > Can you be more specific what you did, which movie you looked? For example this movie most of time triger instability http://d-h.st/bvr I do nothing special: player in full-screen mode, mouse in idle. > > Did severall tests for Christian and Alex with UVD. > > Only this "Sometimes there are visible screen corruptions (color > squares)...) makes me wonder. Do you get it during UVD playback or later > (xdm/kdm) logout? It is about UVD playback. I does not see any desktop corruption without GPU hanging. If it hangs, reboot are required in most cases, as image does not restored properly after gpu reset and restarting of Xorg does not help.
(In reply to comment #2) > mesa-9.2.5 (kernel-3.13-rc7) seems to work (at least with mpv), so it looks > like regression in mesa. "looping" and corruptions exist and with mesa-9.2.5, but seems that finely found trick: sleep 1; xset dpms force off before first use vdpay allow eliminate this.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Will try, but this machine is so slow > > > > Can you be more specific what you did, which movie you looked? > For example this movie most of time triger instability > http://d-h.st/bvr Nice BD snipping...;-) > I do nothing special: player in full-screen mode, mouse in idle. Tried (all) combinations. big window (start up) switch to full-screen switch back change window to smaller KDE 4.12.1 default size switch to full-screen switch back... I even can 'scroll' with the mouse wheel forth and back => NO blocks (squares). Linux 3.13.0-rc7 Mesa git and 10.0.2 (openSUSE 12.3) X.org 1.15 (openSUSE 12.3, Xorg repo) xf86-video-ati-7.2.0 (latest openSUSE 12.3, Xorg repo) > > Did severall tests for Christian and Alex with UVD. > > > > Only this "Sometimes there are visible screen corruptions (color > > squares)...) makes me wonder. Do you get it during UVD playback or later > > (xdm/kdm) logout? > It is about UVD playback. I does not see any desktop corruption without GPU > hanging. If it hangs, reboot are required in most cases, as image does not > restored properly after gpu reset and restarting of Xorg does not help. But I found something with your test.mkv and another .mkv file. It seems to be that we have a start up/initialization problem with UVD (2.2, here). When your test.mkv file is the first one after start up/login it takes several seconds to start and I had one hang. Whole system was not dead but X. Sadly no log. After running other files with UVD *.mkv (big files?) start up is somewhat better. But slower then others (e.g. Serenity - HD DVD Trailer.mp4). But NO squares/blocks at all. Some redraw stuttering during switch from full-screen to (small) window and fewer back to full-screen. Much WORSE with Glamor. Generally speaking UVD takes much more cycles under Glamor. Glamor (a bug/leak; glamor-0.5.1-39.14) is the culprit for my reported color squares during logout from KDE 4.12.1. If system starts without Glamor (the X server 1.15.0 thing, https://bugs.freedesktop.org/show_bug.cgi?id=70706 ;-) I get NOT any such things during fade out/logout from KDE. Last thing: Sometimes UVD starts reliable with sound (I even can scroll with the mouse wheel forth and back) but with empty black video window (only the white mplayer scale during scroll). Worst case was: 1 normal start then 5 BAD then OK, again... Christian? System: AMD Duron 1800 (without SSE2!) - my little one...;-) 2 GB RAM RV730 AGP 1 GB 2 x 24" BenQ DVI 1920x1080 all SSDs openSUSE 12.3 (plus latest devel stuff)
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730 Pro AGP [Radeon HD 4600 Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device 0028 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 (2000ns min), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M] Region 1: I/O ports at a800 [size=256] Region 2: Memory at dfdf0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at dfdc0000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] AGP version 3.0 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8 Kernel driver in use: radeon
Created attachment 92254 [details] Xorg.0.log
Created attachment 92255 [details] dmesg-3.13.0-rc7.log
Now I get partially some color squares: Glamor (glamor-0.5.1-39.14) KDE 4.12.1 kwin GL desktop effects ON UVD/video window on all virtual desktops (sticky) scroll with mouse wheel through all (4 virtual desktops) GL cube Sometimes some redraws show partially color squares, as long as I gave the system time for full refresh... => system is on its limits?! Or glamor is in the way or need optimization.
I think there are two kinds of problems here: first: looping, corruption, black window (also have this). and seems there are 'sleep 1; xset dpms force off' in terminal before using vdpau workaround for that. second: gpu hangs, which seems to be a mesa regression after 9.2.5 > Last thing: > > Sometimes UVD starts reliable with sound (I even can scroll with the mouse > wheel forth and back) but with empty black video window (only the white > mplayer scale during scroll). > Worst case was: > 1 normal start > then 5 BAD > then OK, again... Did you try to set dpms off after boot before seeing that?
I suggest you put the dpms off into your X startup script and then try to bisect the GPU lockup first.
(In reply to comment #14) > I suggest you put the dpms off into your X startup script and then try to > bisect the GPU lockup first. I try to do that, but seems my testing was not enough in some case as R600_DEBUG=nosb helps. BISECT_LOG: git bisect start # bad: [32637f56a5422b09ad945d21d8e60a8b990b0182] os: First check for __GLIBC__ and then for PIPE_OS_BSD git bisect bad 32637f56a5422b09ad945d21d8e60a8b990b0182 # good: [a32330eb93ad4cdb7f4c5bc4c730d7f3ff4042d0] Bump version to 9.2.5 git bisect good a32330eb93ad4cdb7f4c5bc4c730d7f3ff4042d0 # good: [9f07ca11c1797ac12de1e1c6aef13cf58824b5f5] mesa: Dispatch ARB_framebuffer_object and EXT_framebuffer_object differently git bisect good 9f07ca11c1797ac12de1e1c6aef13cf58824b5f5 # good: [e29931aa7423209d29a23be2ad754abb0f79315e] i965: Dump more information about batch buffer usage. git bisect good e29931aa7423209d29a23be2ad754abb0f79315e # good: [e496583975dcbca657cb29a3b15580030394e2b0] docs: Add news item for 9.2 release git bisect good e496583975dcbca657cb29a3b15580030394e2b0 # bad: [51a279254fecc05691524dab1bf291c7dfefccd5] mesa: Setup remaining infrastucture and enable KHR_debug git bisect bad 51a279254fecc05691524dab1bf291c7dfefccd5 # bad: [b3a4d5c78544ee957c4880cec7eb67f00ae04afd] i965: Move vec4 register allocation data structures to brw->vec4. git bisect bad b3a4d5c78544ee957c4880cec7eb67f00ae04afd # bad: [7801a8cc8957fc58e5a493c4da2b4941f5cf9f4a] intel: Reuse intel_glFlush(). git bisect bad 7801a8cc8957fc58e5a493c4da2b4941f5cf9f4a # good: [e95b7d89b9cd7d82b6122f9ad9bbf2249a0a8802] freedreno: updates for msm drm/kms driver git bisect good e95b7d89b9cd7d82b6122f9ad9bbf2249a0a8802 # good: [74be77a99e1196d07ebd941aee24313f7aa123c9] nvc0/ir: Initialize NVC0LegalizePostRA member variables. git bisect good 74be77a99e1196d07ebd941aee24313f7aa123c9 # bad: [09e2df5961cfe04925bdd820e6ea59af3ba783f6] i965/vs: Fix regression on pre-gen6 with no VS uniforms in use. git bisect bad 09e2df5961cfe04925bdd820e6ea59af3ba783f6 # bad: [f7217b99f243738f941a5d009c68387dfadcb50a] r600g: enable SB backend by default git bisect bad f7217b99f243738f941a5d009c68387dfadcb50a # bad: [29ff2e907d6c54f95be6dfa72201fd25bbd50fcd] r600g: fix color exports when we have no CBs git bisect bad 29ff2e907d6c54f95be6dfa72201fd25bbd50fcd # first bad commit: [29ff2e907d6c54f95be6dfa72201fd25bbd50fcd] r600g: fix color exports when we have no CBs
My classification of problems was wrong, while bisecting from step to step was looping or gpu hanging. It seems that problems exists more early (it is why commit 29ff2e907d6c54f95be6dfa72201fd25bbd50fcd was marked as bad), but with sb it mach easy to reproduce. Enabling sb with mesa-9.2.5 makes it behavior with uvd similar to current current git (looping almost immediately, but not sure about gpu hangups).
It seems to me that uvd is stable with R600_DEBUG=nosb and current mesa (it is only necessary workaround). I mean stable behaviour - if it able to play some movie it always play it, or if it hang gpu on other it always hang it there.
my card: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV730 XT [Radeon HD 4670] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Device 0028 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 (2000ns min), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M] Region 1: I/O ports at c800 [size=256] Region 2: Memory at ff7f0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at ff7c0000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] AGP version 2.0 Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x4 Kernel driver in use: radeon
Created attachment 92712 [details] dmesg 3.13-rc7
Created attachment 92713 [details] xorg log
Sorry, I wouldn't offend anybody and hijack this thread with the KDE logout (glamor) thing! ;-) It is here, now: Graphics corruption in KDE logout effect https://bugs.freedesktop.org/show_bug.cgi?id=73759 Something new about RV730 AGP and UVD in a few minutes.
(In reply to comment #17) > It seems to me that uvd is stable with R600_DEBUG=nosb and current mesa (it > is only necessary workaround). I mean stable behaviour - if it able to play > some movie it always play it, or if it hang gpu on other it always hang it > there. There are some low resolution (1024x560, 1024x600) h264 movies that with R600_DEBUG=nosb hang GPU, but strange thing - uvd work with R600_DEBUG=sb with it!
> There are some low resolution (1024x560, 1024x600) h264 movies that with > R600_DEBUG=nosb hang GPU, but strange thing - uvd work with R600_DEBUG=sb > with it! It is seems a different issue and this: http://lists.freedesktop.org/archives/dri-devel/2014-January/052945.html helps here (it works with R600_DEBUG=nosb), thanks.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/485.
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.