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

How can I reproduce this? I tested some H264 videos on Cape Verde and they work fine.

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. :-)

(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.

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.

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. :-)

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.

How do I enable the vdpau mixer in SMPlayer?

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.

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?

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. :-)

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 :)

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.

(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.

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.

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?

(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=4f66c59922cbcda14c9e103e6c7f4ee616360d43
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4ca5a6cba53e13b8fd153b0762b4128fab6a3cfb
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=84f3d9f7b4781dea6e11dcaf7f81367c1b39fef0

I was replying to vladi, who reported it on a 7540D

(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.

Agreed; in fact, it looks like the commit specifically merges r600 code with radeonsi

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.

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.

confirming in case you need it: running xbmc with R600_DEBUG=noinvalrange fixes it here, on radeon hd7750.

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)?

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.

@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.

(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.

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.

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.

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.

@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 ;-)

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.

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.

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.

(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).

> 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.

(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).

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.

(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.

Fernet squashed everything into his master branch. Squash means: The patch that fell from heaven is now also applied.

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.

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.

(In reply to comment #42)
> Additionally cherry-picked to 10.1 branch.

Thx alot for this. Looks like we can close this bug then.