rpm/Mesa
SHA256
1
0
Fork 0
forked from pool/Mesa
Code Pull Requests Activity

Accepting request 438299 from X11:XOrg

Browse Source 
1

OBS-URL: https://build.opensuse.org/request/show/438299
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/Mesa?expand=0&rev=273
This commit is contained in:
Dominique Leuenberger 2016-11-05 20:22:45 +00:00 committed by Git OBS Bridge
commit 91f2ba56bf
8 changed files with 26 additions and 144 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
Mesa.changes
View File

@ -1,3 +1,22 @@
-------------------------------------------------------------------
Wed Nov 2 11:44:47 UTC 2016 - zaitor@opensuse.org
- Drop u_Mesa_i965-import-prime-buffers.patch: Upstream fixed the
bug in a different way, and we should not keep the now obsolete
patch (boo#991638, fdo#71759).
-------------------------------------------------------------------
Tue Nov 1 18:14:28 UTC 2016 - mimi.vx@gmail.com
- update to 13.0.0
- openGL 4.5 with i965 driver on intel bbroadwell and newer hw
- openGL ES for haswell supports 3.1, skylake 3.2
- fixes for intel vulkan driver
- early support fot GP100
- better radeonSI performace
- dropped U_r300g-Set-R300_VAP_CNTL-on-RSxxx-to-avoid-triangle-flickering.patch
- refreshed u_Mesa_i965-import-prime-buffers.patch
-------------------------------------------------------------------
Tue Oct 25 10:05:26 UTC 2016 - sndirsch@suse.com

13
Mesa.spec
View File

@ -22,7 +22,7 @@
%define glamor 1
%define _name_archive mesa
%define _version 12.0.3
%define _version 13.0.0
%define with_opencl 0
%define with_vulkan 0
%ifarch %ix86 x86_64 %arm ppc ppc64 ppc64le s390x
@ -49,7 +49,7 @@
%endif
Name: Mesa
Version: 12.0.3
Version: 13.0.0
Release: 0
Summary: System for rendering interactive 3-D graphics
License: MIT
@ -66,7 +66,6 @@ Source7: Mesa.keyring
Patch0: n_Fixed-build-against-wayland-1.2.1.patch
# to be upstreamed
Patch11: u_Fix-crash-in-swrast-when-setting-a-texture-for-a-pix.patch
Patch12: u_Mesa_i965-import-prime-buffers.patch
# Patch from Fedora, fix 16bpp in llvmpipe
Patch13: u_mesa-8.0.1-fix-16bpp.patch
# Patch from Fedora, use shmget when available, under llvmpipe
@ -75,8 +74,6 @@ Patch15: u_mesa-8.0-llvmpipe-shmget.patch
Patch18: n_VDPAU-XVMC-libs-Replace-hardlinks-with-copies.patch
# never to be upstreamed
Patch21: n_Define-GLAPIVAR-separate-from-GLAPI.patch
# Already upstream
Patch22: U_r300g-Set-R300_VAP_CNTL-on-RSxxx-to-avoid-triangle-flickering.patch
# Nouveau multithreading workarounds from https://github.com/imirkin/mesa/commits/locking
Patch61: N_01-WIP-nouveau-add-locking.patch
@ -455,8 +452,8 @@ implementation of Mesa.
%if 0%{?with_nine}
%package libd3d
Summary: Mesa Direct3D9 state tracker
Group: System/Libraries
# Manually provide d3d library (bnc#918294)
Group: System/Libraries
%ifarch x86_64 s390x ppc64le aarch64
Provides: d3dadapter9.so.1()(64bit)
%else
@ -604,10 +601,8 @@ rm -rf docs/README.{VMS,WIN32,OS2}
#%patch11 -p1
#%patch15 -p1
#%patch13 -p1
%patch12 -p1
%patch18 -p1
%patch21 -p1
%patch22 -p1
%if %{use_broken_nouveau_locking_patches}
%patch61 -p1
@ -1023,7 +1018,7 @@ install -m 644 $RPM_SOURCE_DIR/README.updates \
%defattr(-,root,root)
%dir %{_datadir}/vulkan
%dir %{_datadir}/vulkan/icd.d
%{_datadir}/vulkan/icd.d/intel_icd.json
%{_datadir}/vulkan/icd.d/intel_icd.*.json
%{_libdir}/libvulkan_intel.so
%files libVulkan-devel

67
U_r300g-Set-R300_VAP_CNTL-on-RSxxx-to-avoid-triangle-flickering.patch
View File

@ -1,67 +0,0 @@
From: Max Staudt <mstaudt@suse.de>
Date: Thu Sep 8 01:53:45 2016 +0200
Subject: [PATCH]r300g: Set R300_VAP_CNTL on RSxxx to avoid triangle flickering
Patch-mainline: 02675622b02742960678c438f1b239321c075f50
Git-repo: git://anongit.freedesktop.org/mesa/mesa
References: bsc#985650
Signed-off-by: Max Staudt <mstaudt@suse.de>
On the RSxxx chip series, HW TCL is missing and r300_emit_vs_state()
is never called.
However, if R300_VAP_CNTL is never set, the hardware (at least the
RS690 I tested this on) comes up with rendering artifacts, and
parts that are uploaded before this "fix" remain broken in VRAM.
This causes artifacts as in fdo#69076 ("triangle flickering").
It seems like this setup needs to happen at least once after power on
for 3D rendering to work properly. In the DDX with EXA, this happens in
RADEON_SWITCH_TO_3D() when processing an XRENDER Composite or an
Xv request. So playing back a video or starting a GTK+2 application
fixes 3D rendering for the rest of the session. However, this auto-fix
doesn't happen when EXA is not used, such as with GLAMOR or Wayland.
This patch ensures the register is configured even in absence of
the DDX's EXA module.
The register setting is taken from:
xf86-video-ati -- RADEONInit3DEngineInternal()
mesa/src/mesa/drivers/dri/r300 -- r300EmitClearState()
Tested on RS690.
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Max Staudt <mstaudt@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
---
src/gallium/drivers/r300/r300_context.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r300/r300_context.c b/src/gallium/drivers/r300/r300_context.c
index 82ba043..0998fac 100644
--- a/src/gallium/drivers/r300/r300_context.c
+++ b/src/gallium/drivers/r300/r300_context.c
@@ -190,7 +190,7 @@ static boolean r300_setup_atoms(struct r300_context* r300)
/* VAP. */
R300_INIT_ATOM(viewport_state, 9);
R300_INIT_ATOM(pvs_flush, 2);
- R300_INIT_ATOM(vap_invariant_state, is_r500 ? 11 : 9);
+ R300_INIT_ATOM(vap_invariant_state, is_r500 || !has_tcl ? 11 : 9);
R300_INIT_ATOM(vertex_stream_state, 0);
R300_INIT_ATOM(vs_state, 0);
R300_INIT_ATOM(vs_constants, 0);
@@ -314,6 +314,14 @@ static void r300_init_states(struct pipe_context *pipe)
if (r300->screen->caps.is_r500) {
OUT_CB_REG(R500_VAP_TEX_TO_COLOR_CNTL, 0);
+ } else if (!r300->screen->caps.has_tcl) {
+ /* RSxxx:
+ * Static VAP setup since r300_emit_vs_state() is never called.
+ */
+ OUT_CB_REG(R300_VAP_CNTL, R300_PVS_NUM_SLOTS(10) |
+ R300_PVS_NUM_CNTLRS(5) |
+ R300_PVS_NUM_FPUS(2) |
+ R300_PVS_VF_MAX_VTX_NUM(5));
}
END_CB;
}

3
mesa-12.0.3.tar.xz
View File

@ -1,3 +0,0 @@
version https://git-lfs.github.com/spec/v1
oid sha256:1dc86dd9b51272eee1fad3df65e18cda2e556ef1bc0b6e07cd750b9757f493b1
size 8577408

BIN
mesa-12.0.3.tar.xz.sig
View File

Binary file not shown.

3
mesa-13.0.0.tar.xz Normal file
View File

@ -0,0 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:94edb4ebff82066a68be79d9c2627f15995e1fe10f67ab3fc63deb842027d727
size 9151388

BIN
mesa-13.0.0.tar.xz.sig Normal file
View File

Binary file not shown.

65
u_Mesa_i965-import-prime-buffers.patch
View File

@ -1,65 +0,0 @@
From e180e9e3c830d3611a6cf7d32e988b4c28d20942 Mon Sep 17 00:00:00 2001
From: Martin Peres <martin.peres@linux.intel.com>
Date: Wed, 3 Aug 2016 12:58:23 +0300
Subject: [PATCH] i965: import prime buffers in the current context, not screen
This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and
fixes many applications when using DRI3:
- Totem with libva on hw-accelerated decoding
- obs-studio, using Window Capture (Xcomposite) as a Source
- gstreamer with VAAPI
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71759
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
---
src/mesa/drivers/dri/i965/intel_screen.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c b/src/mesa/drivers/dri/i965/intel_screen.c
index ae51c40..169d578 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -702,8 +702,11 @@ intel_create_image_from_fds(__DRIscreen *screen,
int *fds, int num_fds, int *strides, int *offsets,
void *loaderPrivate)
{
+ GET_CURRENT_CONTEXT(ctx);
struct intel_screen *intelScreen = screen->driverPrivate;
+ struct brw_context *brw = brw_context(ctx);
struct intel_image_format *f;
+ dri_bufmgr *bufmgr;
__DRIimage *image;
int i, index;
@@ -744,8 +747,26 @@ intel_create_image_from_fds(__DRIscreen *screen,
size = end;
}
- image->bo = drm_intel_bo_gem_create_from_prime(intelScreen->bufmgr,
- fds[0], size);
+ /* Let's import the buffer into the current context instead of the current
+ * screen as some applications like gstreamer, totem, or obs create multiple
+ * X connections which end up creating multiple screens and thus multiple
+ * buffer managers. They then proceed to use a different X connection than
+ * the one used by the currently-bound context to call GLXBindTexImageExt()
+ * which should then import the buffer in the current bound context and not
+ * the current screen. This is done properly upstairs for texture management
+ * so we need to mirror this behaviour if we don't want the kernel rejecting
+ * our pushbuffers as the buffer would not have been imported by the same
+ * buffer manager that sent the pushbuffer referencing it.
+ *
+ * If there is no context currently bound, then revert to using the screen's
+ * buffer manager and hope for the best...
+ */
+ if (brw)
+ bufmgr = brw->bufmgr;
+ else
+ bufmgr = intelScreen->bufmgr;
+
+ image->bo = drm_intel_bo_gem_create_from_prime(bufmgr, fds[0], size);
if (image->bo == NULL) {
free(image);
return NULL;
--
2.9.0