lib32-mesa: update to 18.1.1

lib32-mesa/0004-loader_dri3-Variant-2-Wait-for-pending-swaps-to-comp.patch

@@ -1,74 +0,0 @@
-From patchwork Tue May  8 09:42:05 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [Mesa-dev,
- 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete
- before drawable_fini.
-From: =?utf-8?q?Michel_D=C3=A4nzer?= <michel@daenzer.net>
-X-Patchwork-Id: 221466
-Message-Id: <ad7564c6-1e1b-8322-3e5c-d8045e181e10@daenzer.net>
-To: Mario Kleiner <mario.kleiner.de@gmail.com>,
- Mike Lothian <mike@fireburn.co.uk>
-Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>,
- ML xorg-devel <xorg-devel@lists.x.org>
-Date: Tue, 8 May 2018 11:42:05 +0200
-
-On 2018-05-05 06:25 AM, Mario Kleiner wrote:
-> On Sat, May 5, 2018 at 4:08 AM, Mike Lothian <mike@fireburn.co.uk> wrote:
->> I definately saw the steam bug with patch 1 but not with plasmashell,
->> I started seeing it with patch 2 but it seemed to fix itself
-> 
-> I had two hangs of kwin_x11 within the last 6 hours when alt-tabbing
-> between windows, where it got stuck in the
-> loader_dri3_swapbuffer_barrier() from patch 1/2. Not sure how that is
-> possible, or if the stacktrace was misleading, because i had to VT
-> switch to a text console to attach the debugger and this might be just
-> a side effect of that. But if it is true, then patch 1/2 would not be
-> it. Also 1/2 has a potential performance impact, whereas 2/2 doesn't.
-> However 2/2 would also need more work, as i can think of more complex
-> scenarios where it would filter the wrong events, although not in the
-> case of plasmashell or steam. Probably we'd need to sacrifice a few
-> sbc bits in the Present events serial field to transport a unique tag
-> for each incarnation of the loader_dri3_drawable, like a mini-hash of
-> the draw->eid. Ugly ugly...
-
-How about the below?
-
-Idle notify events shouldn't need special treatment, since the pixmap
-XIDs of the buffers will be different between loader_dri3_drawable
-incarnations, aren't they?
-
-
-This still leaves the issue that the SBC moves backwards, which could
-theoretically result in hangs with apps using glXWaitForSbcOML. Fixing
-that would probably require changing the loader_dri3_drawable lifetime
-cycle, which would probably be very invasive, if feasible at all. Maybe
-we don't need to care about that for the time being, until there's a
-real world app running into it.
-
-diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
-index 6db8303d26d..f0ff2f07bde 100644
---- a/src/loader/loader_dri3_helper.c
-+++ b/src/loader/loader_dri3_helper.c
-@@ -370,9 +370,17 @@ dri3_handle_present_event(struct loader_dri3_drawable *draw,
-        * checking for wrap.
-        */
-       if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) {
--         draw->recv_sbc = (draw->send_sbc & 0xffffffff00000000LL) | ce->serial;
--         if (draw->recv_sbc > draw->send_sbc)
--            draw->recv_sbc -= 0x100000000;
-+         uint64_t recv_sbc = (draw->send_sbc & 0xffffffff00000000LL) | ce->serial;
-+
-+         /* Only assume wraparound if that results in exactly the previous
-+          * SBC + 1, otherwise ignore received SBC > sent SBC (those are
-+          * probably from a previous loader_dri3_drawable instance) to avoid
-+          * calculating bogus target MSC values in loader_dri3_swap_buffers_msc
-+          */
-+         if (recv_sbc <= draw->send_sbc)
-+            draw->recv_sbc = recv_sbc;
-+         else if (recv_sbc == (draw->recv_sbc + 0x100000001ULL))
-+            draw->recv_sbc = recv_sbc - 0x100000000ULL;
-
-          /* When moving from flip to copy, we assume that we can allocate in
-           * a more optimal way if we don't need to cater for the display

lib32-mesa/PKGBUILD

@@ -1,6 +1,6 @@
 pkgbase=lib32-mesa
 pkgname=('lib32-vulkan-intel' 'lib32-vulkan-radeon' 'lib32-libva-mesa-driver' 'lib32-mesa-vdpau' 'lib32-mesa')
-pkgver=18.1.0
+pkgver=18.1.1
 pkgrel=1
 arch=('x86_64')
 makedepends=('python2-mako' 'lib32-libxml2' 'lib32-expat' 'lib32-libx11' 'glproto' 'lib32-libdrm' 'dri2proto' 'dri3proto' 'presentproto'
@@ -10,13 +10,11 @@ url="http://mesa3d.sourceforge.net"
 license=('custom')
 source=(https://mesa.freedesktop.org/archive/mesa-${pkgver}.tar.xz{,.sig}
         LICENSE
-        0001-glvnd-fix-gl.pc.patch
+        0001-glvnd-fix-gl.pc.patch)
-        0004-loader_dri3-Variant-2-Wait-for-pending-swaps-to-comp.patch)
+sha512sums=('7783adc1ec7a1c3d092acfcca6b4ba19450c15a7f0d7f41fbf25e482236615d79ce24afe60959066ea7aa851df4f74fa3c569fa6d847ea79e6bfe046b8c65e90'
-sha512sums=('8b26af2df8b94373cbc339521974cd568c1d4ff4204986ee7b439e4cf3ebe14d822ea081a7769b68eca9263b7bc6dbca01836b8bb0d6495d2e2614c4e3d601ad'
             'SKIP'
             'f9f0d0ccf166fe6cb684478b6f1e1ab1f2850431c06aa041738563eb1808a004e52cdec823c103c9e180f03ffc083e95974d291353f0220fe52ae6d4897fecc7'
-            '2f40198eff47664c831c56e8a63f60a4d1b815cf697e6bdb0be39e6d9c5df043857f6264b7cd2ccf46c07626186c565144e80f4214b5f7936ef7024c47201437'
+            '2f40198eff47664c831c56e8a63f60a4d1b815cf697e6bdb0be39e6d9c5df043857f6264b7cd2ccf46c07626186c565144e80f4214b5f7936ef7024c47201437')
-            '724912f9b0fef29caa956efa413276bca6d2299a1a7dd648550d08cab81aaa01682b2cfc9a1f47963b4c4d3c7a86a57a0058888453f7723b45ada5fc858cd09d')
 validpgpkeys=('8703B6700E7EE06D7A39B8D6EDAE37B02CEB490D'  # Emil Velikov <emil.l.velikov@gmail.com>
               '946D09B5E4C9845E63075FF1D961C596A7203456'  # Andres Gomez <tanty@igalia.com>
               'E3E8F480C52ADD73B278EE78E1ECBE07D7D70895'  # Juan Antonio Suárez Romero (Igalia, S.L.) <jasuarez@igalia.com>"
@@ -29,11 +27,6 @@ prepare() {
   # glvnd support patches - from Fedora
   # non-upstreamed ones
   patch -Np1 -i ../0001-glvnd-fix-gl.pc.patch
-
-  # experimental patch, should fix FS#58549
-  # see https://bugs.freedesktop.org/show_bug.cgi?id=106351
-  # and https://patchwork.freedesktop.org/series/42687/
-  patch -Np1 -i ../0004-loader_dri3-Variant-2-Wait-for-pending-swaps-to-comp.patch
 }
 
 build() {