Emilio Pozuelo Monfort pushed to branch debian-unstable at X Strike Force / lib
/ mesa
Commits:
f815839d by Dylan Baker at 2018-06-29T11:00:48-07:00
docs: Add SHA256 sums to notes for 18.1.3
- - - - -
f102eada by Ross Burton at 2018-07-03T10:24:58-07:00
egl: fix build race in automake
There is a parallel make build issue in src/egl/drivers/dri2/
for wayland builds. Can be reproduced with:
$ rm src/egl/drivers/dri2/*.h src/egl/drivers/dri2/platform_wayland.lo
$ make -C src/egl/ drivers/dri2/platform_wayland.lo
../../../mesa-18.1.2/src/egl/drivers/dri2/platform_wayland.c:50:10: fatal
error: linux-dmabuf-unstable-v1-client-protocol.h: No such file or directory
This patch adds the missing dependency.
Fixes: 02cc359372773800de817 "egl/wayland: Use linux-dmabuf interface for
buffers"
Reviewed-by: Eric Engestrom <eric.engest...@intel.com>
[Eric: fixed up the commit title]
Signed-off-by: Eric Engestrom <eric.engest...@intel.com>
(cherry picked from commit d7c4ce1d1d800a4721122a20b5a289951e7f4fbc)
- - - - -
2fa4b4df by Jason Ekstrand at 2018-07-03T10:24:58-07:00
intel/fs: Split instructions low to high in lower_simd_width
Commit 0d905597f fixed an issue with the placement of the zip and unzip
instructions. However, as a side-effect, it reversed the order in which
we were emitting the split instructions so that they went from high
group to low instead of low to high. This is fine for most things like
texture instructions and the like but certain render target writes
really want to be emitted low to high. This commit just switches the
order back around to be low to high.
Reviewed-by: Matt Turner <matts...@gmail.com>
Fixes: 0d905597f "intel/fs: Be more explicit about our placement of
[un]zip"
(cherry picked from commit d5b617a28e89fda62fb6cceec10686b0bb4b4fb2)
- - - - -
fb39f5d2 by Rhys Perry at 2018-07-03T10:24:58-07:00
nvc0/ir: fix TargetNVC0::insnCanLoadOffset()
Previously, TargetNVC0::insnCanLoadOffset() returned whether the offset
could be set to a specific value. The IndirectPropagation pass expected
it to return whether the offset could be increased by a specific value,
which is what TargetNV50::insnCanLoadOffset() does.
Fixes: 37b67db6ae34fb6586d640a7a1b6232f091dd812
("nvc0/ir: be careful about propagating very large offsets into
const load")
Signed-off-by: Rhys Perry <pendingchao...@gmail.com>
Reviewed-by: Karol Herbst <kher...@redhat.com>
Signed-off-by: Karol Herbst <kher...@redhat.com>
(cherry picked from commit 6bb0f87c6003e1d80aa79f6a591620aecc7b031d)
- - - - -
45bea648 by Timothy Arceri at 2018-07-03T10:24:58-07:00
glsl: skip comparison opt when adding vars of different size
The spec allows adding scalars with a vector or matrix. In this case
the opt was losing swizzle and size information.
This fixes a bug with Doom (2016) shaders.
Fixes: 34ec1a24d61f ("glsl: Optimize (x + y cmp 0) into (x cmp -y).")
Reviewed-by: Ian Romanick <ian.d.roman...@intel.com>
(cherry picked from commit 2a5121bf355001e2c69ba05e8d9be4ed633c7bf4)
- - - - -
fde83d5f by Marek Olšák at 2018-07-03T10:24:58-07:00
radeonsi: fix memory exhaustion issue with DCC statistics gathering with DRI2
Cc: 18.1 <mesa-sta...@lists.freedesktop.org>
(cherry picked from commit 41f80373b46604f585497086f971a43aeea7f0c1)
Conflicts fixed by Dylan
Conflicts:
src/gallium/drivers/radeonsi/si_blit.c
- - - - -
fed76b32 by Jason Ekstrand at 2018-07-03T10:25:21-07:00
anv: Be more careful about hashing pipeline layouts
Previously, we just hashed the entire descriptor set layout verbatim.
This meant that a bunch of extra stuff such as pointers and reference
counts made its way into the cache. It also meant that we weren't
properly hashing in the Y'CbCr conversion information information from
bound immutable samplers.
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Timothy Arceri <tarc...@itsqueeze.com>
(cherry picked from commit d1c778b362d3ccf203f33095bee2af45dc8cde9a)
- - - - -
52b78ae7 by Iago Toral Quiroga at 2018-07-03T10:25:26-07:00
anv/cmd_buffer: make descriptors dirty when emitting base state address
Every time we emit a new state base address we will need to re-emit our
binding tables, since they might have been emitted with a different base
state adress.
Reviewed-by: Lionel Landwerlin <lionel.g.landwer...@intel.com>
Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net>
CC: <mesa-sta...@lists.freedesktop.org>
(cherry picked from commit 1b54824687df5170e1dd5ab701b2b76da299b851)
- - - - -
ebaa43be by Iago Toral Quiroga at 2018-07-03T10:25:32-07:00
anv/cmd_buffer: clean dirty push constants flag after emitting push constants
Reviewed-by: Lionel Landwerlin <lionel.g.landwer...@intel.com>
Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net>
CC: <mesa-sta...@lists.freedesktop.org>
(cherry picked from commit 6a1d8350c91eed4ab10569683902a0fea4c048c5)
- - - - -
a4aec345 by Iago Toral Quiroga at 2018-07-03T10:25:38-07:00
anv/cmd_buffer: never shrink the push constant buffer size
If we have to re-emit push constant data, we need to re-emit all
of it.
Reviewed-by: Lionel Landwerlin <lionel.g.landwer...@intel.com>
Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net>
CC: <mesa-sta...@lists.freedesktop.org>
(cherry picked from commit 198a72220b63e812e8b853cb5caa088d93720e7d)
- - - - -
a14f1d21 by Marek Olšák at 2018-07-03T10:25:43-07:00
glsl/cache: save and restore ExternalSamplersUsed
Shaders that need special code for external samplers were broken if
they were loaded from the cache.
Cc: 18.1 <mesa-sta...@lists.freedesktop.org>
Reviewed-by: Timothy Arceri <tarc...@itsqueeze.com>
(cherry picked from commit 99c6cae2278011309b7ca3d4735c7b341cbb4eef)
- - - - -
4cd70c4c by Ian Romanick at 2018-07-03T10:26:11-07:00
i965/vec4: Don't cmod propagate from CMP to ADD if the writemask isn't
compatible
Otherwise we can incorrectly cmod propagate in situations like
add(8) g10<1>.xD g2<0>.xD -16D
...
cmp.ge.f0(8) null<1>D g2<0>.xD 16D
...
(+f0) sel(8) g21<1>.xyUD g14<4>.xyyyUD
g18<4>.xyyyUD
Sadly, this change hurts quite a few shaders.
v2: Refactor writemask compatibility check into a separate function.
Suggested by Caio.
Ivy Bridge and Haswell had similar results. (Haswell shown)
total instructions in shared programs: 12968489 -> 12968738 (<.01%)
instructions in affected programs: 60679 -> 60928 (0.41%)
helped: 0
HURT: 249
HURT stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
HURT stats (rel) min: 0.22% max: 0.81% x̄: 0.46% x̃: 0.44%
95% mean confidence interval for instructions value: 1.00 1.00
95% mean confidence interval for instructions %-change: 0.44% 0.48%
Instructions are HURT.
total cycles in shared programs: 409171965 -> 409172317 (<.01%)
cycles in affected programs: 260056 -> 260408 (0.14%)
helped: 0
HURT: 176
HURT stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
HURT stats (rel) min: 0.04% max: 0.34% x̄: 0.17% x̃: 0.17%
95% mean confidence interval for cycles value: 2.00 2.00
95% mean confidence interval for cycles %-change: 0.16% 0.18%
Cycles are HURT.
Sandy Bridge
total instructions in shared programs: 10423577 -> 10423753 (<.01%)
instructions in affected programs: 40667 -> 40843 (0.43%)
helped: 0
HURT: 176
HURT stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
HURT stats (rel) min: 0.29% max: 0.79% x̄: 0.48% x̃: 0.42%
95% mean confidence interval for instructions value: 1.00 1.00
95% mean confidence interval for instructions %-change: 0.46% 0.51%
Instructions are HURT.
total cycles in shared programs: 146097503 -> 146097855 (<.01%)
cycles in affected programs: 503990 -> 504342 (0.07%)
helped: 0
HURT: 176
HURT stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
HURT stats (rel) min: 0.02% max: 0.36% x̄: 0.12% x̃: 0.11%
95% mean confidence interval for cycles value: 2.00 2.00
95% mean confidence interval for cycles %-change: 0.11% 0.13%
Cycles are HURT.
No changes on any other platforms.
Signed-off-by: Ian Romanick <ian.d.roman...@intel.com>
Fixes: cd635d149b2 i965/vec4: Propagate conditional modifiers from compares to
adds
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.olive...@intel.com>
(cherry picked from commit 995d9937103771d9318124b91adfd20d7c6d5fed)
- - - - -
81af1a0a by Timothy Arceri at 2018-07-03T10:26:16-07:00
nir: fix selection of loop terminator when two or more have the same limit
We need to add loop terminators to the list in the order we come
across them otherwise if two or more have the same exit condition
we will select that last one rather than the first one even though
its unreachable.
This fix is for simple unrolls where we only have a single exit
point. When unrolling these type of loops the unreachable
terminators and their unreachable branch are removed prior to
unrolling. Because of the logic change we also switch some
list access in the complex unrolling logic to avoid breakage.
Fixes: 6772a17acc8e ("nir: Add a loop analysis pass")
Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net>
(cherry picked from commit 463f849097193ad20e7622ddd740fd15b96f4277)
- - - - -
83716106 by Dave Airlie at 2018-07-05T10:00:02-07:00
r600/sb: cleanup if_conversion iterator to be legal C++
The current code causes:
/usr/include/c++/8/debug/safe_iterator.h:207:
Error: attempt to copy from a singular iterator.
This is due to the iterators getting invalidated, fix the
reverse iterator to use the return value from erase, and
cast it properly.
(used Mathias suggestion)
Cc: <mesa-sta...@lists.freedesktop.org>
Reviewed-by: Mathias Fröhlich <mathias.froehl...@web.de>
(cherry picked from commit 8c51caab2404c5c9f5211936d27e9fe1c0af2e7d)
- - - - -
7333112e by Neil Roberts at 2018-07-05T10:00:13-07:00
i965: Fix output register sizes when variable ranges are interleaved
In 6f5abf31466aed this code was fixed to calculate the maximum size of
an attribute in a seperate pass and then allocate the registers to
that size. However this wasn’t taking into account ranges that overlap
but don’t have the same starting location. For example:
layout(location = 0, component = 0) out float a[4];
layout(location = 2, component = 1) out float b[4];
Previously, if ‘a’ was processed first then it would allocate a
register of size 4 for location 0 and it wouldn’t allocate another
register for location 2 because it would already be covered by the
range of 0. Then if something tries to write to b[2] it would try to
write past the end of the register allocated for ‘a’ and it would hit
an assert.
This patch changes it to scan for any overlapping ranges that start
within each range to calculate the maximum extent and allocate that
instead.
Fixed Piglit’s arb_enhanced_layouts/execution/component-layout/
vs-fs-array-interleave-range.shader_test
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.olive...@intel.com>
Fixes: 6f5abf31466 "i965: Fix output register sizes when multiple variables
share a slot."
(cherry picked from commit 2d5ddbe960f7c62a8f00d5e800925865f115970f)
- - - - -
3ddbe5d4 by Samuel Pitoiset at 2018-07-06T09:12:27-07:00
radv: fix emitting the view index on GFX9
For merged shaders, VS as HS for example.
Cc: <mesa-sta...@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <b...@basnieuwenhuizen.nl>
(cherry picked from commit 85865dbe0d96f18ac768b4063da94f52ee67a7fd)
- - - - -
d68f2d7e by Roland Scheidegger at 2018-07-09T09:24:30-07:00
r600/sb: fix crash in fold_alu_op3
fold_assoc() called from fold_alu_op3() can lower the number of src to 2,
which then leads to an invalid access to n.src[2]->gvalue().
This didn't seem to have caused much harm in the past, but on Fedora 28
it will crash (presumably because -D_GLIBCXX_ASSERTIONS is used, although
with libstdc++ 4.8.5 this didn't do anything, -D_GLIBCXX_DEBUG was
needed to show the issue).
An alternative fix would be to instead call fold_alu_op2() from within
fold_assoc() when the number of src is reduced and return always TRUE
from fold_assoc() in this case, with the only actual difference being
the return value from fold_alu_op3() then. I'm not sure what the return
value actually should be in this case (or whether it even can make a
difference).
https://bugs.freedesktop.org/show_bug.cgi?id=106928
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Dave Airlie <airl...@redhat.com>
(cherry picked from commit 817efd89685efc6b5866e09cbdad01c4ff21c737)
- - - - -
c1027505 by Ian Romanick at 2018-07-09T09:24:36-07:00
intel/compiler: Relax mixed type restriction for saturating immediates
At the time of commit 7bc6e455e23 (i965: Add support for saturating
immediates.) we thought mixed type saturates would be impossible. We
were only thinking about type converting moves from D to F, for
example. However, type converting moves w/saturate from F to DF are
definitely possible. This change minimally relaxes the restriction to
allow cases that I have been able trigger via piglit tests.
Fixes new piglit tests:
-
arb_gpu_shader_fp64/execution/built-in-functions/fs-sign-sat-neg-abs.shader_test
-
arb_gpu_shader_fp64/execution/built-in-functions/vs-sign-sat-neg-abs.shader_test
Signed-off-by: Ian Romanick <ian.d.roman...@intel.com>
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.olive...@intel.com>
(cherry picked from commit f8e54d02f79057f679302c06847066edc3ae7aa7)
- - - - -
7dd72c1c by Ian Romanick at 2018-07-09T09:24:45-07:00
i965/vec4: Properly handle sign(-abs(x))
This is achived by copying the sign(abs(x)) optimization from the FS
backend.
On Gen7 an earlier platforms, this fixes new piglit tests:
- glsl-1.10/execution/vs-sign-neg-abs.shader_test
- glsl-1.10/execution/vs-sign-sat-neg-abs.shader_test
Signed-off-by: Ian Romanick <ian.d.roman...@intel.com>
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.olive...@intel.com>
(cherry picked from commit 9626ea497de8af5580ee3af76df79ad8083c5922)
- - - - -
e7d4549a by Ian Romanick at 2018-07-09T09:24:51-07:00
i965/fs: Properly handle sign(-abs(x))
Fixes new piglit tests:
- glsl-1.10/execution/fs-sign-neg-abs.shader_test
- glsl-1.10/execution/fs-sign-sat-neg-abs.shader_test
- glsl-1.10/execution/vs-sign-neg-abs.shader_test
- glsl-1.10/execution/vs-sign-sat-neg-abs.shader_test
Signed-off-by: Ian Romanick <ian.d.roman...@intel.com>
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.olive...@intel.com>
(cherry picked from commit 88bd37c01060169b451ca2c3900830342d34a9a2)
- - - - -
a47e6da2 by Marek Olšák at 2018-07-09T09:24:56-07:00
st/dri: fix a crash in server_wait_sync
Ported from i965 including the comment.
This fixes:
dEQP-EGL.functional.reusable_sync.valid.wait_server
Cc: 18.1 <mesa-sta...@lists.freedesktop.org>
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
(cherry picked from commit 0eaf069679ccf86de6739d5eaa439db075f02903)
- - - - -
9401dcdb by Lionel Landwerlin at 2018-07-09T09:25:09-07:00
i965: fix clear color bo address relocation
Fixes: 7987d041fda0c9 ("i965/surface_state: Emit the clear color address
instead of value.")
Signed-off-by: Lionel Landwerlin <lionel.g.landwer...@intel.com>
Reviewed-by: Kenneth Graunke <kenn...@whitecape.org>
(cherry picked from commit 420bf14e12f7e55637cfc79da17990bb4f150288)
- - - - -
6fa04b17 by Jason Ekstrand at 2018-07-09T13:21:07-07:00
intel/fs: Mark LINTERP opcode as writing accumulator on platforms without PLN
When we don't have PLN (gen4 and gen11+), we implement LINTERP as either
LINE+MAC or a pair of MADs. In both cases, the accumulator is written
by the first of the two instructions and read by the second. Even
though the accumulator value isn't actually ever used from a logical
instruction perspective, it is trashed so we need to make the scheduler
aware. Otherwise, the scheduler could end up re-ordering instructions
and putting a LINTERP between another an instruction which writes the
accumulator and another which tries to use that result.
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Matt Turner <matts...@gmail.com>
(cherry picked from commit 566e6abd6d70266aea2f43ad9fefaf7718d76c57)
Rebased version provided by Jason
- - - - -
a0b97410 by zhaowei yuan at 2018-07-10T09:30:09-07:00
glsl: Treat sampler2DRect and sampler2DRectShadow as reserved in ES2
"sampler2DRect" and "sampler2DRectShadow" are specified as
reserved from GLSL 1.1 and GLSL ES 1.0
Signed-off-by: zhaowei yuan <zhaowei.y...@samsung.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106906
Reviewed-by: Eric Anholt <e...@anholt.net>
Fixes: 34f7e761bc61 ("glsl/parser: Track built-in types using the
glsl_type directly")
(cherry picked from commit 73ec437627448466b2d3da3adc74310ccd4f41e7)
- - - - -
9ce4c7b4 by Jose Maria Casanova Crespo at 2018-07-10T09:30:32-07:00
i965/fs: Register allocator shoudn't use grf127 for sends dest
Since Gen8+ Intel PRM states that "r127 must not be used for return
address when there is a src and dest overlap in send instruction."
This patch implements this restriction creating new grf127_send_hack_node
at the register allocator. This node has a fixed assignation to grf127.
For vgrf that are used as destination of send messages we create node
interfereces with the grf127_send_hack_node. So the register allocator
will never assign to these vgrf a register that involves grf127.
If dispatch_width > 8 we don't create these interferences to the because
all instructions have node interferences between sources and destination.
That is enough to avoid the r127 restriction.
This fixes CTS tests that raised this issue as they were executed as SIMD8:
dEQP-VK.spirv_assembly.instruction.graphics.8bit_storage.8struct_to_32struct.storage_buffer_*int_geom
Shader-db results on Skylake:
total instructions in shared programs: 7686798 -> 7686797 (<.01%)
instructions in affected programs: 301 -> 300 (-0.33%)
helped: 1
HURT: 0
total cycles in shared programs: 337092322 -> 337091919 (<.01%)
cycles in affected programs: 22420415 -> 22420012 (<.01%)
helped: 712
HURT: 588
Shader-db results on Broadwell:
total instructions in shared programs: 7658574 -> 7658625 (<.01%)
instructions in affected programs: 19610 -> 19661 (0.26%)
helped: 3
HURT: 4
total cycles in shared programs: 340694553 -> 340676378 (<.01%)
cycles in affected programs: 24724915 -> 24706740 (-0.07%)
helped: 998
HURT: 916
total spills in shared programs: 4300 -> 4311 (0.26%)
spills in affected programs: 333 -> 344 (3.30%)
helped: 1
HURT: 3
total fills in shared programs: 5370 -> 5378 (0.15%)
fills in affected programs: 274 -> 282 (2.92%)
helped: 1
HURT: 3
v2: Avoid duplicating register classes without grf127. Let's use a node
with a fixed assignation to grf127 and create interferences to send
message vgrf destinations. (Eric Anholt)
v3: Update reference to CTS VK_KHR_8bit_storage failing tests.
(Jose Maria Casanova)
Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net>
Cc: 18.1 <mesa-sta...@lists.freedesktop.org>
(cherry picked from commit 232ed8980217dd65ab0925df28156f565b94b2e5)
- - - - -
e681c0eb by Jose Maria Casanova Crespo at 2018-07-10T09:30:39-07:00
intel/compiler: grf127 can not be dest when src and dest overlap in send
Implement at brw_eu_validate the restriction from Intel Broadwell PRM,
vol 07, section "Instruction Set Reference", subsection "EUISA
Instructions", Send Message (page 990):
"r127 must not be used for return address when there is a src and
dest overlap in send instruction."
v2: Style fixes (Matt Turner)
Reviewed-by: Matt Turner <matts...@gmail.com>
Cc: 18.1 <mesa-sta...@lists.freedesktop.org>
(cherry picked from commit 0e47ecb29acf8bdd213236d7306c47f8ec0e937f)
- - - - -
658d4e8e by Adam Jackson at 2018-07-10T09:30:44-07:00
glx: Don't allow glXMakeContextCurrent() with only one valid drawable
Drawable and readable need to either both be None or both be non-None.
Cc: <mesa-sta...@lists.freedesktop.org>
Signed-off-by: Adam Jackson <a...@redhat.com>
Reviewed-by: Eric Anholt <e...@anholt.net>
(cherry picked from commit d257ec01360be05a745bbb851f08e944bcb23718)
- - - - -
251cf0dc by Jose Maria Casanova Crespo at 2018-07-13T10:00:41-07:00
i965/fs: unspills shoudn't use grf127 as dest since Gen8+
At 232ed8980217dd65ab0925df28156f565b94b2e5 "i965/fs: Register allocator
shoudn't use grf127 for sends dest" we didn't take into account
the case
of SEND instructions that are not send_from_grf. But since Gen7+ although
the backend still uses MRFs internally for sends they are finally
assigned to a GRFs.
In the case of unspills the backend assigns directly as source its
destination because it is suppose to be available. So we always have a
source-destination overlap. If the reg_allocator assigns registers that
include the grf127 we fail the validation rule that affects Gen8+
"r127 must not be used for return address when there is a src and dest
overlap in send instruction."
So this patch activates the grf127_send_hack_node for Gen8+ and if we
have any register spilled we add interferences to the destination of
the unspill operations.
We also need to avoid that opt_bank_conflicts() optimization, that runs
after the register allocation, doesn't move things around, causing the
grf127 to be used in the condition we were avoiding.
Fixes piglit test tests/spec/arb_compute_shader/linker/bug-93840.shader_test
and some shader-db crashed because of the grf127 validation rule..
v2: make sure that opt_bank_conflicts() optimization doesn't change
the use of grf127. (Caio)
Found by Caio Marcelo de Oliveira Filho
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107193
Fixes: 232ed89802 "i965/fs: Register allocator shoudn't use grf127 for
sends dest"
Cc: 18.1 <mesa-sta...@lists.freedesktop.org>
Cc: Caio Marcelo de Oliveira Filho <caio.olive...@intel.com>
Cc: Jason Ekstrand <ja...@jlekstrand.net>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.olive...@intel.com>
(cherry picked from commit 62f37ee53d9d5388eecef94369893b5467349306)
- - - - -
4078bff6 by Dylan Baker at 2018-07-13T11:15:47-07:00
Bump version for release
- - - - -
7f76bfcc by Dylan Baker at 2018-07-13T11:34:55-07:00
docs: Add release notes for 18.1.4
- - - - -
9134ba4c by Emilio Pozuelo Monfort at 2018-07-15T12:08:27+02:00
Merge branch 'upstream-unstable' into debian-unstable
- - - - -
e87aa7e8 by Emilio Pozuelo Monfort at 2018-07-15T12:09:01+02:00
New upstream release
- - - - -
4e47fb07 by Emilio Pozuelo Monfort at 2018-07-15T13:00:00+02:00
Release to unstable
- - - - -
30 changed files:
- VERSION
- debian/changelog
- docs/relnotes/18.1.3.html
- + docs/relnotes/18.1.4.html
- src/amd/vulkan/radv_cmd_buffer.c
- src/compiler/glsl/glsl_lexer.ll
- src/compiler/glsl/opt_algebraic.cpp
- src/compiler/glsl/serialize.cpp
- src/compiler/nir/nir_loop_analyze.c
- src/compiler/nir/nir_opt_loop_unroll.c
- src/egl/Makefile.am
- src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp
- src/gallium/drivers/r600/sb/sb_expr.cpp
- src/gallium/drivers/r600/sb/sb_if_conversion.cpp
- src/gallium/drivers/radeonsi/si_blit.c
- src/gallium/state_trackers/dri/dri_helpers.c
- src/glx/glxcurrent.c
- src/intel/compiler/brw_eu_validate.c
- src/intel/compiler/brw_fs.cpp
- src/intel/compiler/brw_fs_bank_conflicts.cpp
- src/intel/compiler/brw_fs_nir.cpp
- src/intel/compiler/brw_fs_reg_allocate.cpp
- src/intel/compiler/brw_shader.cpp
- src/intel/compiler/brw_vec4.cpp
- src/intel/compiler/brw_vec4_cmod_propagation.cpp
- src/intel/compiler/brw_vec4_nir.cpp
- src/intel/compiler/test_vec4_cmod_propagation.cpp
- src/intel/vulkan/anv_cmd_buffer.c
- src/intel/vulkan/anv_descriptor_set.c
- src/intel/vulkan/genX_cmd_buffer.c
The diff was not included because it is too large.
View it on GitLab:
https://salsa.debian.org/xorg-team/lib/mesa/compare/db11d152ded5a9f9686af0fed809a00ac2ac9d94...4e47fb07e70a319f0adb69541c62b4a78c1ba568
--
View it on GitLab:
https://salsa.debian.org/xorg-team/lib/mesa/compare/db11d152ded5a9f9686af0fed809a00ac2ac9d94...4e47fb07e70a319f0adb69541c62b4a78c1ba568
You're receiving this email because of your account on salsa.debian.org.
