https://bugs.freedesktop.org/show_bug.cgi?id=73191
Priority: medium Bug ID: 73191 Assignee: dri-devel@lists.freedesktop.org Summary: [radeonsi] vdpau playback issues, skipping & looping Severity: major Classification: Unclassified OS: Linux (All) Reporter: rachel@strangenoises.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa
Created attachment 91375 --> https://bugs.freedesktop.org/attachment.cgi?id=91375&action=edit git bisect log
Simplest to illustrate the issue with a video taken on my phone: www.youtube.com/watch?v=GvuNu1ZEgsw
In words, I would describe it as being stuck on looping a short sequence of frames, then it skips forward in the stream to a later sequence of frames; I think this is simply to keep it in range of the audio, which plays normally throughout (but not through hdmi/displayport, audio is going out via usb speakers)
This affects all h.264 playback; interlaced or progressive, SD or HD, though the test clip shown above is a 23.976p movie. Unsure if it affects playback of other codecs: I've been having system crashes attempting to play mpeg2 video streams, but I believe that's an unrelated issue.
This behaviour seems to have been introduced in commit 91aca8c662faf0ec311968b2897a72a6d08b199d ("r600g,radeonsi: consolidate buffer code, add handling of DISCARD_RANGE for SI") on Dec 12; discovered using git bisect and a spare afternoon. :-) Before starting that process I had tested the current ppa:wsnipex/mesa build (bad), the current master HEAD (bad), the current 10.0 branch head (good)
On the previous commit, 12806449fa35aff47ad6f4615ede55776c9f66c8, playback is fine.
Affected system is running Ubuntu 13.10 x86_64, running XBMC test builds from https://launchpad.net/~wsnipex/+archive/xbmc-fernetmenta-master - afaik the most developed vdpau-enabled *player*. Graphics card is an AMD Radeon HD 7750 (with four mini-displayports). lspci:
rachel@twilight:~/src/mesa$ lspci | grep Radeon 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde PRO [Radeon HD 7750] 03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]
Test builds of mesa directly from the read-only git repo; while for convenience I borrowed the debian directory from the ppa builds to make .debs for installation/deinstallation, I removed the patches (emptied debian/patches/series) so it should all be vanilla builds.
Tried with stock current Ubuntu Saucy generic kernel and with 3.13-rc6 mainline kernel build and with several other of the rc builds too until decided to bisect mesa instead.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #1 from Vladi vladi@aresgate.net --- I am suffering from the same issue only when I enable vdpau + vdpau mixer. I am running kernel 3.13-rc6 + mesa 10.0.0 or 10.0.1.
[AMD/ATI] Trinity [Radeon HD 7540D]
Portage 2.2.7 (default/linux/amd64/13.0/desktop, gcc-4.7.3, glibc-2.16.0, 3.13.0-rc6 x86_64) ================================================================= System uname: Linux-3.13.0-rc6-x86_64-AMD_A6-5400K_APU_with_Radeon-tm-_HD_Graphics-with-gentoo-2.2 KiB Mem: 7822124 total, 287272 free KiB Swap: 0 total, 0 free Timestamp of tree: Wed, 08 Jan 2014 07:45:01 +0000 ld GNU ld (GNU Binutils) 2.23.2 distcc 3.1 x86_64-pc-linux-gnu [enabled] ccache version 3.1.9 [enabled] app-shells/bash: 4.2_p45 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.5-r3, 3.2.5-r3, 3.3.2-r2 dev-util/ccache: 3.1.9 dev-util/cmake: 2.8.11.2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.10.3, 1.11.6, 1.12.6, 1.13.4 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.7.3-r1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.9 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo x11 x-portage ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=amdfam10 -mcx16 -mpopcnt -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=amdfam10 -mcx16 -mpopcnt -pipe" DISTDIR="/mnt/das1/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs ccache config-protect-if-modified distcc distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LC_ALL="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j8 -l2" PKGDIR="/mnt/das1/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/cache/gentoo" PORTDIR="/mnt/das1/portage" PORTDIR_OVERLAY="/var/lib/layman/x11 /usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow 3dnowext 64bit a52 aac acpi adns alsa amd64 async bash-completion berkdb branding bzip2 cairo cdda cdr cgi chroot ck-server clang cli command-args consolekit cracklib crypt ctype curl cxx dedicated device-mapper dri dts dvb dvdr dynamicplugin emboss enca encode enscript epoll exif extensions faac faad fasttrack ffmpeg firefox flac fontconfig fpm fuse gbm gd gdbm geoip gif glamor glibc-omitfp gnutella gnutls hardcoded-tables hash hpn iconv imap inline inotify iproute2 ithreads jpeg kerberos lcms libnotify llvm-shared-libs logrotate lzo mad magic matroska mmx mmxext mng modules mp3 mp4 mpeg mpm-worker mudflap multilib mysql nagios-dns nagios-ping nagios-ssh ncurses network nfsv3 no-old-linux nonfsv4 nptl odbc offensive ogg ogm opencl opengl openmp openvg optimization pam pango pcre pdf pdo perl php pic png policykit ppds python python3 qt3support r600-llvm-compiler readline rpc rrdtool rtmp samba sdl session shared-dricore silvercity slang smi smtp snmp snortsam sockets spell sqlite sqlite3 sse sse2 sse3 ssl ssse3 subversion svg sysfs syslog theora threads tidy tiff truetype udev udisks unicode upower urandom userlocales v4l vdpau vhosts vim-syntax vorbis vpx wifi x264 xcb xml xrandr xv xvid zero-penalty-hit zip zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="alias auth_basic authz_host authz_user authn_file autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config mime mime_magic negotiation proxy proxy_http rewrite setenvif so status unique_id userdir usertrack vhost_alias cgid" APACHE2_MPMS="worker" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DRACUT_MODULES="btrfs" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en bg" LIRC_DEVICES="userspace" NGINX_MODULES_HTTP="access auth_basic autoindex browser charset empty_gif fastcgi geo gzip limit_req limit_zone map referer rewrite scgi split_clients ssi upstream_ip_hash userid uwsgi dav gzip_static proxy mp4" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="radeon r600" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #2 from Marek Olšák maraeo@gmail.com --- How can I reproduce this? I tested some H264 videos on Cape Verde and they work fine.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #3 from Rachel Greenham rachel@strangenoises.org --- I'm away from the computer so I'll try more tests later, specifically:
1: Test again with latest master, on the offchance it got inadvertently fixed there by other work since I reported it.
2: Test with XBMC running standalone, instead of in the Unity (ie: with composite) desktop. XBMC devs advise that while composite being enabled makes it suboptimal, it shouldn't break it like this, and indeed as reported on earlier versions it didn't. (xmir definitely isn't enabled btw; that utterly fails to work for me, won't even start.)
In the meantime just noting: Contrary to the previous commenter it *worked* for me on mesa 10.0 and 10.0.1 and only failed from the specified commit onwards
Also to reiterate, the player I'm using is xbmc from the fernetmenta branch, which is where, I understand, the vdpau/radeon work is going on at the moment. I was having issues enabling vdpau in vlc, but I'd given up on that some time earlier and was my impression it was an unrelated issue, but I can look at that again. If you have a preferred vdpau player for testing issues like this let me know. :-)
I could upload some example media showing the problem but as noted already, it affects *all* h.264 playback for me (live tv, handbraked ie: x264, raw-bluray), so I reckoned uploading a sample was redundant. :-)
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #4 from Rachel Greenham rachel@strangenoises.org --- (damn, logged out to try somethign while my last reply was unsaved!)
Results:
1: Updated mesa to latest master (git 90368875e), the problem still occurs exactly as previously described.
2: Problem occurs not only on unity desktop, also when xbmc is running standalone with composite disabled.
3: Problem occurs on each of the three monitors attached, whether or not other monitors are selected to be switched off, and including the monitor that can switch refresh rates to the correct one.
4: situation with VLC is confusing at the moment. While release notes claim VDPAU the GUI makes no mention of it, so I'm not sure what's working or not, but when it does fail it seems to be a different problem anyway. So putting that aside for now.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #5 from Rachel Greenham rachel@strangenoises.org --- Clip of movie shown failing in test video is http://luna.strangenoises.org/~rachel/xbmctesting/worldsend-1min.mkv
Confirmed issue occurs with this actual 1 minute clip as well. But as already noted, when it occurs, it affects *everything*. So this upload for completion's sake.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #6 from Rachel Greenham rachel@strangenoises.org --- One more finding for now.
Starting with current master, I did git revert 91aca8c662fa (the commit discovered by git bisect above) and rebuilt... and sure enough, there's no problem. There's definitely something in *that* commit that breaks it for me.
Sadly I see it's one of the bigger commits of recent times. :-} But something in there isn't right. :-)
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #7 from Rachel Greenham rachel@strangenoises.org --- requested by fritsch to try with vdpau enabled but vdpau *mixer* disabled. I find with vdpau mixer disabled, playback looks fine, the problem disappears. So the problem would appear to be in the mixer part. :-)
This matches that portion of vladi's findings, though to reiterate 10.0 and 10.0.1 worked fine for me with vdpau mixer enabled.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #8 from Marek Olšák maraeo@gmail.com --- How do I enable the vdpau mixer in SMPlayer?
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #9 from Rachel Greenham rachel@strangenoises.org --- i don't have a clue. I've been saying throughout, my testing is with xbmc; specifically the builds from here https://launchpad.net/~wsnipex/+archive/xbmc-fernetmenta-master tracking fernetmenta's dev branch of xbmc where the vdpau/radeon work is being done here https://github.com/FernetMenta/xbmc
i guess if smplayer doesn't support vdpau mixer it can't test whether something's wrong with it.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #10 from Roman Elshin roman.elshin@gmail.com --- I have very similar looping (but without skipping) which frequently end up gpu hangup on rv730 agp, and i think vdpau was never working with that card/mb, or at least it is not this regression, should i open a new bug?
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #11 from Rachel Greenham rachel@strangenoises.org --- tbh sounds to me like quite a different problem on quite a different card; especially as i already isolated it as having started with a commit adding specific radeonsi (which my card is) behaviour.
So I'd say yours needs a new bug raised. :-)
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #12 from Roman Elshin roman.elshin@gmail.com --- I agree, but there are little chance that these commits are change work logic for your card to the logic that was never working with mine :)
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #13 from Rachel Greenham rachel@strangenoises.org --- well firstly what you describe doesn't sound quite the same as what i describe.
secondly actually it *might* be spreading an older bug to affect more hardware, as the commit in question is explicitly consolidating some functionality: ie: similar operations that were implemented differently for different cards have been consolidated, or rationalised, into a single generalised implementation. So in that process I suppose it *is* possible that a bug in the implementation for one card was thus carried forward into the consolidated implementation, to affect more.
OTOH you were saying vdpau never worked on that card? This issue is definitely associated with vdpau, specifically the vdpau mixer. It's entirely possible i suppose that new XBMC code is the only thing out there that's seriously trying to use that yet, at least on radeon.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #14 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #10)
I have very similar looping (but without skipping) which frequently end up gpu hangup on rv730 agp, and i think vdpau was never working with that card/mb, or at least it is not this regression, should i open a new bug?
If this is a regression and you can bisect it to this commit, then it's a duplicate, if not, it's probably a different bug.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #15 from Vladi vladi@aresgate.net --- My issue happens only when I enable vdpau mixer in xbmc. If i dont however then the SD content looks verry edgy ie the edges are very blocky. I will try and take a picture. I have tried mesa-9999, mesa-10.0.1. Will update kernel / mesa / xbmc today and report back, as i see that a new mesa 10.0.2 is out.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #16 from Rachel Greenham rachel@strangenoises.org --- It remains interesting (maybe) that you're having problems with 10.0.1 and I don't.
Looking at the commit, with an outside eye, it seems to be consolidating bits of code that were split out for different cards into a single implementation. So is it possible this bug actually arose some time back, only affecting a few cards (eg: yours) but after the consolidation it affects more cards (eg: now including mine too).
We're both south-islands hd7000-series cards, but not the exact same. Idunno, just my observations.
Can you take a video like the one I did (maybe just for consistency using the video sample I uploaded, linked in an earlier comment), so we can actually all see and confirm it's the same problem?
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #17 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #16)
We're both south-islands hd7000-series cards, but not the exact same. Idunno, just my observations.
rv730 is not southern islands. It's r7xx (HD4000 series). Completely different hardware.
(In reply to comment #10)
I have very similar looping (but without skipping) which frequently end up gpu hangup on rv730 agp, and i think vdpau was never working with that card/mb, or at least it is not this regression, should i open a new bug?
For AGP cards and r7xx cards, make sure your kernel has these patches for proper UVD support: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f... http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4c... http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=84...
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #18 from Rachel Greenham rachel@strangenoises.org --- I was replying to vladi, who reported it on a 7540D
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #19 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #18)
I was replying to vladi, who reported it on a 7540D
That's also a different family (northern islands) which is handled by the the r600 driver rather than radeonsi.
r600 driver: r6xx, r7xx, evergreen, northern islands families
radeonsi driver: southern islands, sea islands families
That said, the commit in question hits both drivers.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #20 from Rachel Greenham rachel@strangenoises.org --- Agreed; in fact, it looks like the commit specifically merges r600 code with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #21 from Marek Olšák maraeo@gmail.com --- Setting the environment variable R600_DEBUG=noinvalrange should fix this. I'm still trying to figure out what's wrong with it. It looks like a synchronization issue, because doing a context flush in r600_buffer_transfer_unmap fixes it.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #22 from Vladi vladi@aresgate.net --- Confirmed noivalrange fixes the issue for me. Thanks Marek. If it helps i also had the issue with the gl flicker in xbmc which Alex fixed recently in rc6.
(In reply to comment #21)
Setting the environment variable R600_DEBUG=noinvalrange should fix this. I'm still trying to figure out what's wrong with it. It looks like a synchronization issue, because doing a context flush in r600_buffer_transfer_unmap fixes it.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #23 from Rachel Greenham rachel@strangenoises.org --- confirming in case you need it: running xbmc with R600_DEBUG=noinvalrange fixes it here, on radeon hd7750.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #24 from Kertesz Laszlo laszlo.kertesz@gmail.com --- I just hit this bug after i updated mesa yesterday. I have a Radeon HD 8570D (from the A8-6500 APU, uses the r600 driver.
I have this skipping and looping issue with xbmc IF i have the "prefer vdpau mixer" option activated. If i deactivate it, playback is fine, although it seems a bit blockier. Launching xbmc ith R600_DEBUG=noinvalrange doesnt change anything.
mpv on the other hand works just fine with vdpau playback and has better image quality than xbmc with the mixer option deactivated.
dmesg doesnt show anything out of the ordinary. I updated the kernel from git today and even merged Dave's drm-next into it. No change.
Maybe this is related to the vdpau/gl interop method which is used by xbmc to play vdpau content over opengl (since "pure" vdpau playback such as mpv's doesnt seem to be ffected)?
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #25 from Marek Olšák maraeo@gmail.com --- FYI, we know where the problem is, but XBMC needs some fixing too before we can proceed. BTW, the workaround won't work anymore with Mesa master.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #26 from Peter Frühberger fritsch@xbmc.org --- @Marek: Could you be a bit more precise on what the problem is in our (xbmc) code. We are happy to fix every possible bug.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #27 from Christian König deathsimple@vodafone.de --- (In reply to comment #26)
@Marek: Could you be a bit more precise on what the problem is in our (xbmc) code. We are happy to fix every possible bug.
We need the map/unmap event for buffers. And then flush the VDPAU context while mapping the buffer for GL use and flush the GL context while unmapping the buffer for VDPAU use.
Going to take a closer look after FOSDEM, so just be patient for a while longer.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #28 from Rainer Hochecker fernetmenta@online.de --- Note that XBMC's implementation of NV_vdpau_interop works for more than two years on NVidia without those issues. I can't find any documentation which proofs right what you request here. I tried this on NVidia but it fails.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #29 from Grigori Goronzy greg@chown.ath.cx --- The GL_NV_vdpau_interop spec says:
Using any other API to access a VDPAU surface while that surface is in the mapped state in the GL will yield undefined results, potentially including program termination.
i.e. it's clearly not allowed to use any VDPAU API functions on mapped surfaces.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #30 from Rachel Greenham rachel@strangenoises.org --- Tested Christian's xbmc-test branch of mesa with Rainer's amd branch of xbmc (doin' what i'm told ;-))
Well it's fixed *a* problem; just not the one this bug is reporting. :-} If you watch the video I linked at the top of this bug, there's a second or so of glitchiness covering the whole screen before the looping behaviour (but otherwise good-looking video) plays.
That initial glitchiness is gone! But the loopiness that follows is still there. Also, I just get a black screen for what seems about the duration of the glitchiness before, while the audio plays. Actually the video should be fading in quickly from black from the very start.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #31 from Peter Frühberger fritsch@xbmc.org --- @Rachel:
Could you please retest with the mesa patches of christian I sent you some time ago ( http://cgit.freedesktop.org/~deathsimple/mesa/log/?h=xbmc-test ) and important: together with this ppa: https://launchpad.net/~wsnipex/+archive/xbmc-nightly/+packages
That does unmapping / mapping of surfaces everytime and the AMD folks considers our "usage of mapped surfaces" as wrong spec - which they are probably right, despite it is working perfect since more than 2 years.
That mesa 10 is working for us is "pure luck" I was told on IRC. Cause I am not such a lucky man, we need to investigate further ;-)
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #32 from Rachel Greenham rachel@strangenoises.org --- that combo is already tested, reported in my comment above yours. Neither that deathsimple xbmc-test branch nor the xbmc-nightly ppa have had any updates since I ran that test. (That "Rainer's amd branch" referred to is the xbmc-nightly ppa, which is still showing the same version as the one I tested then.)
Reminder: It cured the second or so of full-screen glitch at the start of playback, but not the ongoing loopiness.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #33 from Eric Valette eric.valette@free.fr --- Just to confirm, I have a kabini chipset with Libux kernel 3.13.2, mesa rc1 + the last two flush patches I got from this thread applied, and XBMC with amd surface patch from amd branch and still have exactly the same symptoms as described in the beginning of the bug (short video sequence repeating itself and then jumping to a new sequence). When I disable vdpau mixer all is fine.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #34 from Kertesz Laszlo laszlo.kertesz@gmail.com --- This bug is fixed by this commit in FernetMenta's xbmc branch at least:
vdpau: map/unmap surfaces on every cycle, requested by AMD
https://github.com/FernetMenta/xbmc/commit/5ef43abeab315c8b7b96da7e8d67899c1...
After building xbmc again from git, VDPAU playback works well on my A8-6500 (r600g) with the "Prefer VDPAU mixer" option enabled.
I have compiled everything from git: kernel, mesa, xf86-ati, glamor, drm.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #35 from Eric Valette eric.valette@free.fr --- (In reply to comment #34)
This bug is fixed by this commit in FernetMenta's xbmc branch at least:
vdpau: map/unmap surfaces on every cycle, requested by AMD
https://github.com/FernetMenta/xbmc/commit/ 5ef43abeab315c8b7b96da7e8d67899c1c6a02e1
After building xbmc again from git, VDPAU playback works well on my A8-6500 (r600g) with the "Prefer VDPAU mixer" option enabled.
I have compiled everything from git: kernel, mesa, xf86-ati, glamor, drm.
As I already tested with this commit applied to XBMC (was already in the now defunct amd branch and I picked it up), looking at what I used and what you have, I think mesa git makes the most difference (kernel?). It may be worth backporting what is needed to 10.1 so that most people can benefit it as soon as it's released. The second flush patch (st/vdpau: add flush on unmap) is at least missing from 10.1 branch (but is not sufficient as I applied it manually on top of orginal rc1 tarball).
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #36 from Kertesz Laszlo laszlo.kertesz@gmail.com ---
As I already tested with this commit applied to XBMC (was already in the now defunct amd branch and I picked it up), looking at what I used and what you have, I think mesa git makes the most difference (kernel?). It may be worth backporting what is needed to 10.1 so that most people can benefit it as soon as it's released. The second flush patch (st/vdpau: add flush on unmap) is at least missing from 10.1 branch (but is not sufficient as I applied it manually on top of orginal rc1 tarball).
Might be. I built mesa about an hour or less before i built xbmc, kernel is 3.14 rc1+, almost rc2.
That commit was the last in the FernetMenta's xbmc git at that point (thats why i saw it). Note that i re-cloned the whole xbmc git from scratch before building it.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #37 from Eric Valette eric.valette@free.fr --- (In reply to comment #36)
That commit was the last in the FernetMenta's xbmc git at that point (thats why i saw it). Note that i re-cloned the whole xbmc git from scratch before building it.
The commit is an "old" one (24 days if you look at description) that has been applied. Anyway, upgrading kernel to RC2 is the first thing I will do and then I will try mesa git (but only when back home).
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #38 from Christian König deathsimple@vodafone.de --- The kernel version is unrelevant this is a pure userspace problem between the two components (XBMC & VDPAU driver).
What you need to avoid it is the mesa patch "vdpau: flush the context before exporting the surface v2" and the second version of FernetMenta's XBMC patch (The first version of the XBMC patch had a minor bug in it preventing it from working correctly).
Appart from that we also have another bug (so far only reported on Kabini) that produces similar looking results, but has a completely different origin.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #39 from Eric Valette eric.valette@free.fr --- (In reply to comment #38)
The kernel version is unrelevant this is a pure userspace problem between the two components (XBMC & VDPAU driver).
What you need to avoid it is the mesa patch "vdpau: flush the context before exporting the surface v2" and the second version of FernetMenta's XBMC patch (The first version of the XBMC patch had a minor bug in it preventing it from working correctly).
Appart from that we also have another bug (so far only reported on Kabini) that produces similar looking results, but has a completely different origin.
as explained in comment 33, I have "vdpau: flush the context before exporting the surface v2" but may be not the second version of the XBMC patch (have to check but anyway I will probably rebase xbmc git tree on last fernetmenta).
But I'm using a Kabini chipset (on a zotac nano AQ0) so from your comment, I guess it is still unfixed. Tell me if I can test something on this.
Thanks for your help.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #40 from Peter Frühberger fritsch@xbmc.org --- Fernet squashed everything into his master branch. Squash means: The patch that fell from heaven is now also applied.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
--- Comment #41 from Eric Valette eric.valette@free.fr --- Its fixed for me too. I probably had version 1 of xbmc patch for surface mapping/unmapping. So 10.1-rc1 + the last two patches from http://cgit.freedesktop.org/~deathsimple/mesa/log/?h=xbmc-test works.
Could someone make sure the two mentioned patches land in 10.1 before its released or is there a good reason not doing it bacause it breaks other parts?
Thanks to anyone one involved in finding the solution.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
Andreas Boll andreas.boll.dev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #42 from Andreas Boll andreas.boll.dev@gmail.com --- Fixed with the following commits:
commit 3f98053fc94a964930c73c43154daddfd7824e7c Author: Marek Olšák marek.olsak@amd.com Date: Mon Jan 13 14:13:01 2014 +0100
vdpau: flush the context before exporting the surface v2
Bugzilla (bug needs XBMC changes as well): https://bugs.freedesktop.org/show_bug.cgi?id=73191
When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which always flushes the context in the winsys if the buffer being mapped is busy. Since I added handling of DISCARD_RANGE, DONTBLOCK has had no effect when combined with DISCARD_RANGE and I think the context isn't flushed anywhere else, so no commands are submitted to the GPU until the IB is full, which takes a lot of frames.
Using DISCARD_RANGE is not the only way to trigger this bug. The other way is to reallocate the vertex buffer before every upload.
BTW, I'm not sure if this is the right place for flushing, but it does fix the bug.
v2 (chk): move the flush to the right place.
Signed-off-by: Christian König christian.koenig@amd.com Tested-by: StrangeNoises (rachel@strangenoises.org)
commit db54fca9b86aa124447d11d2bdbe359a2742cfd5 Author: Christian König christian.koenig@amd.com Date: Tue Jan 28 15:22:05 2014 +0100
st/vdpau: add flush on unmap
Flush the context when we unmap a buffer, otherwise VDPAU might start rendering the next frame while we still reference that buffer.
Signed-off-by: Christian König christian.koenig@amd.com Tested-by: StrangeNoises (rachel@strangenoises.org)
Additionally cherry-picked to 10.1 branch.
https://bugs.freedesktop.org/show_bug.cgi?id=73191
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #43 from Christian König deathsimple@vodafone.de --- (In reply to comment #42)
Additionally cherry-picked to 10.1 branch.
Thx alot for this. Looks like we can close this bug then.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org