On Tue, Jan 10, 2017 at 9:28 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> With shaders using a lot of inputs/outputs, like this (from Gtk+) :
>
> layout(location = 0) in vec2 inPos;
> layout(location = 1) in float inGradientPos;
> layout(location = 2) in flat int inRepeating;
>
On 2017-01-10 02:48:55, Alejandro Piñeiro wrote:
> On 09/01/17 23:54, Jordan Justen wrote:
> > Is this code doing the 'downsize' for gen >= 8 as well?
>
> No. As mentioned on the commit message, gen >= 8 supports the PASSTHRU
> formats natively, so they use it directly.
>
> Note that this patch
Currently, we can store up to 256 immediates in a static array,
but this is not always enough, instead we should allocate a
dynamic array. But for performance reasons, only do that when
the limit is reached because static allocation is better.
This fixes a segfault with
Lionel just set a few patches which should make this one redundant.
On Mon, Jan 9, 2017 at 11:37 PM, Kenneth Graunke
wrote:
> Signed-off-by: Kenneth Graunke
> ---
> src/intel/vulkan/genX_pipeline.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>
1-3 are
Reviewed-by: Jason Ekstrand
Thanks for cleaning this up!
On Tue, Jan 10, 2017 at 9:28 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/vulkan/anv_private.h | 11
Signed-off-by: Lionel Landwerlin
---
src/intel/vulkan/anv_private.h | 11 +++
src/intel/vulkan/genX_pipeline.c | 7 +--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
With shaders using a lot of inputs/outputs, like this (from Gtk+) :
layout(location = 0) in vec2 inPos;
layout(location = 1) in float inGradientPos;
layout(location = 2) in flat int inRepeating;
layout(location = 3) in flat int inStopCount;
layout(location = 4) in flat vec4 inClipBounds;
Signed-off-by: Lionel Landwerlin
---
src/intel/vulkan/anv_private.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 954eaf49fd..8a69aa22f6 100644
--- a/src/intel/vulkan/anv_private.h
+++
Signed-off-by: Lionel Landwerlin
---
src/intel/vulkan/anv_private.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 9e3b72e77b..954eaf49fd 100644
---
Assuming the answer to both of the below questions is "yes", everything
except patch 10 is
Reviewed-by: Jason Ekstrand
I don't think caching will be all thar thard to fix.
On Tue, Jan 10, 2017 at 9:06 AM, Jason Ekstrand
wrote:
> On Mon, Jan 9, 2017
On Mon, Jan 9, 2017 at 11:37 PM, Kenneth Graunke
wrote:
> v2: Merge more TCS/TES info.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/intel/vulkan/anv_pipeline.c | 189 ++
> +-
> 1 file changed, 187
On Tue, 2017-01-10 at 16:43 +, Emil Velikov wrote:
> On 10 January 2017 at 15:04, Vedran Miletić wrote:
> > On 09/19/2016 08:39 PM, Vedran Miletić wrote:
> > > On 09/07/2016 06:52 PM, Vedran Miletić wrote:
> > > > LLVM and Mesa both define the DEBUG macro in incompatible
On Mon, Jan 9, 2017 at 11:37 PM, Kenneth Graunke
wrote:
> v2: Use info->tess.
>
> Signed-off-by: Kenneth Graunke
> Reviewed-by: Dave Airlie [v1]
> Reviewed-by: Iago Toral Quiroga [v1]
> Reviewed-by: Jason
On Tue, Jan 10, 2017 at 8:59 AM, Ilia Mirkin wrote:
> On Tue, Jan 10, 2017 at 11:50 AM, Lionel Landwerlin
> wrote:
> > With shaders using a lot of inputs/outputs, like this (from Gtk+) :
> >
> > layout(location = 0) in vec2 inPos;
> >
On 10/01/17 16:59, Ilia Mirkin wrote:
On Tue, Jan 10, 2017 at 11:50 AM, Lionel Landwerlin
wrote:
With shaders using a lot of inputs/outputs, like this (from Gtk+) :
layout(location = 0) in vec2 inPos;
layout(location = 1) in float inGradientPos;
layout(location
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #50 from Marek Olšák ---
It would be useful to have a debug build of the game and run it with a profiler
or debugger to see where it's looping.
--
You are receiving this mail because:
You are the assignee for the
On Tue, Jan 10, 2017 at 11:50 AM, Lionel Landwerlin
wrote:
> With shaders using a lot of inputs/outputs, like this (from Gtk+) :
>
> layout(location = 0) in vec2 inPos;
> layout(location = 1) in float inGradientPos;
> layout(location = 2) in flat int inRepeating;
>
With shaders using a lot of inputs/outputs, like this (from Gtk+) :
layout(location = 0) in vec2 inPos;
layout(location = 1) in float inGradientPos;
layout(location = 2) in flat int inRepeating;
layout(location = 3) in flat int inStopCount;
layout(location = 4) in flat vec4 inClipBounds;
On 10 January 2017 at 15:04, Vedran Miletić wrote:
> On 09/19/2016 08:39 PM, Vedran Miletić wrote:
>> On 09/07/2016 06:52 PM, Vedran Miletić wrote:
>>> LLVM and Mesa both define the DEBUG macro in incompatible ways. As a
>>> general practice, we should avoid using such generic
From: Nicolai Hähnle
As remarked by the comment in the original code, the old algorithm fails when
(tc + deriv) points at a different cube face. Instead, simply project the
derivative directly to the plane of the selected cube face.
The new code is based on exactly
On Tue, Jan 10, 2017 at 4:50 AM, Nayan Deshmukh
wrote:
> On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss wrote:
>> Christian König wrote:
>>>
>>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
dri3 allows us to send handle of a texture
Hi Wu Zhen,
On 6 January 2017 at 17:35, Wu Zhen wrote:
> From: WuZhen
>
> adds a new type of winsys handle type that allows passing
> a pointer sized handle to winsys
>
> Change-Id: I3bf1732619206d2bc50f6aca6b27258bb026a212
> Reviewed-by: Mauro Rossi
You grabbed the setup from the "precompile" version which is just a guess.
We need the version from wm_populate_key which pulls from the geometry or
vertex VUE map.
On Tue, Jan 10, 2017 at 6:35 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> With shaders using a lot of
On Tue, Jan 10, 2017 at 10:31 AM, Nicolai Hähnle wrote:
> On 10.01.2017 16:21, Ilia Mirkin wrote:
>>
>> This will just cause shader based workarounds in the affected
>> applications, no? What's the benefit of removing this? Fwiw, Nvidia hw
>> has support for this.
>
>
> It's
On 6 January 2017 at 17:35, Wu Zhen wrote:
> From: WuZhen
>
> rename old swrast to softpipe, add a new driver llvmpipe
>
Generic comment:
Please keep mechanical changes (rename) separate from new
functionality (llvmpipe support).
Two [somewhat] open
On 6 January 2017 at 17:35, Wu Zhen wrote:
> From: WuZhen
>
> since (cf410574 gallivm: Make MCJIT a runtime optioni.), llvmpipe assume
> MCJIT is available on x86(_64). this is not the case for android prior to M.
>
Wu Zhen, what exactly is the issue
On 10.01.2017 16:21, Ilia Mirkin wrote:
This will just cause shader based workarounds in the affected
applications, no? What's the benefit of removing this? Fwiw, Nvidia hw
has support for this.
It's only supposed to remove the extension string, nothing else. Can you
explain in which scenario
On 6 January 2017 at 17:35, Wu Zhen wrote:
> From: WuZhen
>
> linking against llvm with both static and shared lib will
> cause problems.
Nicely spotted - I did not see/realise that we do shared LLVM link further up.
Maybe (_only_ maybe) the Mesa
Hi Wu Zhen,
On 6 January 2017 at 17:35, Wu Zhen wrote:
> From: WuZhen
>
> this commit fixes mesa building on lollipop, however,
> llvm on lollipop is too old to build amdgpu
>
On top of the comment by Mauro, please make sure patches are split logically.
This will just cause shader based workarounds in the affected applications,
no? What's the benefit of removing this? Fwiw, Nvidia hw has support for
this.
On Jan 10, 2017 9:59 AM, "Nicolai Hähnle" wrote:
From: Nicolai Hähnle
Some parts of the
Patches 4-6:
Acked-by: Nicolai Hähnle
On 10.01.2017 01:53, Mauro Rossi wrote:
LLVMInitializeAMDGPU* functions need to be explicitly declared
and mesa expects them via header,
but LLVM needs to be instructed to invoke its own LLVM_TARGET(AMDGPU) macro,
or the
From: Nicolai Hähnle
... by straight-forward search & replace, and eliminate
emit_llvm_intrinsic.
---
src/amd/common/ac_nir_to_llvm.c | 120 ++--
1 file changed, 41 insertions(+), 79 deletions(-)
diff --git
On 6 January 2017 at 17:35, Wu Zhen wrote:
> From: WuZhen
>
> Redirect logs printed to stderr to logcat.
>
> Change-Id: I58e3966a608af361b86c54b4c95a92561b711968
> Signed-off-by: Chih-Wei Huang
> Reviewed-by: Mauro Rossi
From: Nicolai Hähnle
Sourcing coords_arg[4] is actually never correct, since bias is handled
differently in tex_fetch_args anyway.
---
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git
From: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_shader_internal.h | 4 -
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 197 --
2 files changed, 201 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_internal.h
From: Nicolai Hähnle
... and eliminate emit_fdiv and nir_to_llvm_context::fpmath_md_*, which
are now unused.
---
src/amd/common/ac_nir_to_llvm.c | 28 ++--
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git
From: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 28 ---
1 file changed, 28 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
index
On 10 January 2017 at 00:52, Mauro Rossi wrote:
>
> Hi,
>
> I'm sending a series of 12 patches for android,
> comprising fixes for build errors, LLVMInitializeAMDGPU* declarations,
> Android 7 fixes and a (small) i915 patch for feature parity with i965.
>
> Tested with
From: Nicolai Hähnle
Code is taken from a combination of radv (for the more basic functions,
to avoid gallivm dependencies) and radeonsi (for the new and improved
derivative calculations).
---
src/amd/common/ac_llvm_util.c | 362
From: Nicolai Hähnle
... and eliminate the non-ac copies. Mostly straight-forward
search & replace.
---
src/amd/common/ac_nir_to_llvm.c | 89 +++--
1 file changed, 24 insertions(+), 65 deletions(-)
diff --git
From: Nicolai Hähnle
As remarked by the comment in the original code, the old algorithm fails when
(tc + deriv) points at a different cube face. Instead, simply project the
derivative directly to the plane of the selected cube face.
The new code is based on exactly
From: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 76 +--
1 file changed, 43 insertions(+), 33 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
Hi all,
this series has two parts:
Patches 1-5 fix a bug in how radeonsi handles explicit derivatives for cube
map sampling plus some related cleanups. The old computation is based on a
"finite differences" approach that fails when the texture coordinate +
derivative vector lands in a different
From: Nicolai Hähnle
The correct offset is really 0.5, both intuitively and according to the
formulas in Section 8.13 (Cube Map Texture Selection) of the OpenGL spec.
This mistake probably never hurt because wrap-around is constrained to
individual cube faces.
---
On 09/19/2016 08:39 PM, Vedran Miletić wrote:
> On 09/07/2016 06:52 PM, Vedran Miletić wrote:
>> LLVM and Mesa both define the DEBUG macro in incompatible ways. As a
>> general practice, we should avoid using such generic names when it is
>> possible to do so.
>>
>> This patch renames all
From: Nicolai Hähnle
Some parts of the extension were explicitly removed for core profiles,
and all the remaining functionality has been in core since core profiles
exist. So there's no loss of exposed functionality.
The corresponding change was applied to i965 in 2013
From: Nicolai Hähnle
The old setting didn't hurt, but this is cleaner.
---
src/gallium/drivers/radeonsi/si_shader.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index
With shaders using a lot of inputs/outputs, like this (from Gtk+) :
layout(location = 0) in vec2 inPos;
layout(location = 1) in float inGradientPos;
layout(location = 2) in flat int inRepeating;
layout(location = 3) in flat int inStopCount;
layout(location = 4) in flat vec4 inClipBounds;
2017-01-10 1:53 GMT+01:00 Mauro Rossi :
> Integration of rules that set correct HAVE_LLVM value for Android 7.0
> ---
> Android.common.mk | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Android.common.mk b/Android.common.mk
> index 1745b08..36a44bb
Hi Christian,
On 23 December 2016 at 22:04, Christian Gmeiner
wrote:
> As the original patchstack is now about 300 patches, I have choosen to
> squash the patches together into three different parts.
>
> - renderonly library
> A lightweight library to add basic
Hi Christian,
Similar to 2/3 there's a few trivial nitpicks which can be addressed
at a later stage.
On 23 December 2016 at 22:04, Christian Gmeiner
wrote:
> Changes from V1 -> V2:
> - updated Copyright
> - added $(top_srcdir)/src/gallium/winsys to include path
On 4 January 2017 at 09:10, Thierry Reding wrote:
> On Fri, Dec 23, 2016 at 11:04:51PM +0100, Christian Gmeiner wrote:
> [...]
>> +struct pipe_screen *imx_drm_screen_create(int fd)
>> +{
>> + struct renderonly ro = {
>> + .create_for_resource =
On 01/10/2017 01:45 PM, Timothy Arceri wrote:
On Tue, 2017-01-10 at 22:41 +1100, Timothy Arceri wrote:
On Tue, 2017-01-10 at 22:34 +1100, Timothy Arceri wrote:
On Tue, 2017-01-10 at 12:20 +0200, Tapani Pälli wrote:
On 01/09/2017 05:42 PM, Emil Velikov wrote:
On 9 January 2017 at 15:36,
On Mon, 2017-01-09 at 15:41 -0800, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez writes:
>
> > From: "Juan A. Suarez Romero"
> >
> > In IVB/VLV, for instructions dealing with DF, execsize will be
> > duplicated in the final code.
> >
> > So take
https://bugs.freedesktop.org/show_bug.cgi?id=94194
--- Comment #6 from Plamena Manolova ---
Ping :)
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev
Andy Furniss wrote:
Though recent testing shows this is not true with DAL/DC on 3.7 -
todo test DC on new drm-next branch.
todo done, DC for some reason on both amd-staging-4.7 and
amd-staging-drm-next is "slower" = the tear region is 2 to 3 times
larger than non DC kernel with powerplay
On Tue, 2017-01-10 at 22:41 +1100, Timothy Arceri wrote:
> On Tue, 2017-01-10 at 22:34 +1100, Timothy Arceri wrote:
> > On Tue, 2017-01-10 at 12:20 +0200, Tapani Pälli wrote:
> > >
> > > On 01/09/2017 05:42 PM, Emil Velikov wrote:
> > > > On 9 January 2017 at 15:36, Emil Velikov
On Tue, 2017-01-10 at 22:34 +1100, Timothy Arceri wrote:
> On Tue, 2017-01-10 at 12:20 +0200, Tapani Pälli wrote:
> >
> > On 01/09/2017 05:42 PM, Emil Velikov wrote:
> > > On 9 January 2017 at 15:36, Emil Velikov > > m>
> > > wrote:
> > > > On 9 December 2016 at 05:58,
On Tue, 2017-01-10 at 12:20 +0200, Tapani Pälli wrote:
>
> On 01/09/2017 05:42 PM, Emil Velikov wrote:
> > On 9 January 2017 at 15:36, Emil Velikov
> > wrote:
> > > On 9 December 2016 at 05:58, Tapani Pälli > > > wrote:
> > > > When
On Mon, 2017-01-09 at 14:42 -0800, Francisco Jerez wrote:
> Matt Turner writes:
>
> > On 01/05, Samuel Iglesias Gonsálvez wrote:
> > > From: Iago Toral Quiroga
> > >
> > > 4-wide DF operations where NibCtrl applies require and execsize
> > > of 8
> > > in
Nayan Deshmukh wrote:
On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss wrote:
Christian König wrote:
Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to
On 09/01/17 23:54, Jordan Justen wrote:
> Is this code doing the 'downsize' for gen >= 8 as well?
No. As mentioned on the commit message, gen >= 8 supports the PASSTHRU
formats natively, so they use it directly.
Note that this patch only touches brw_draw_upload.c, that includes the
Hi,
On 10 January 2017 at 05:49, Ben Widawsky wrote:
> On 17-01-09 11:56:04, Jason Ekstrand wrote:
>> Do we need to do any error checking here? Do we need to check for the
>> right dri image extension version? Do we need to check queryImage !=
>> NULL? Do we need
On 01/09/2017 05:42 PM, Emil Velikov wrote:
On 9 January 2017 at 15:36, Emil Velikov wrote:
On 9 December 2016 at 05:58, Tapani Pälli wrote:
When 'evict_random_item' attempts to remove cache content to make more
space, it may try to remove
On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer wrote:
> On 06/01/17 05:50 AM, Andy Furniss wrote:
>> Christian König wrote:
>>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
dri3 allows us to send handle of a texture directly to X
so this patch allows a state
On Fri, Jan 6, 2017 at 2:20 AM, Andy Furniss wrote:
> Christian König wrote:
>>
>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>>
>>> dri3 allows us to send handle of a texture directly to X
>>> so this patch allows a state tracker to directly send its
>>> texture to X to
Otherwise we will end up with an extra instruction to compare the
result of the inot.
On BDW:
total instructions in shared programs: 13060620 -> 13060481 (-0.00%)
instructions in affected programs: 103379 -> 103240 (-0.13%)
helped: 127
HURT: 0
total cycles in shared programs: 256590950 ->
On BDW:
total instructions in shared programs: 13061890 -> 13061877 (-0.00%)
instructions in affected programs: 2441 -> 2428 (-0.53%)
helped: 13
HURT: 0
total cycles in shared programs: 256612254 -> 256611784 (-0.00%)
cycles in affected programs: 16418 -> 15948 (-2.86%)
helped: 10
HURT: 2
V2:
From: Kenneth Graunke
I'm going to add a boolean scheduling pass that I want run late, but
after copy propagation and dead code elimination. Yet, I don't want
to have to think about registers. So, move the register conversion
a little later.
No impact on shader-db.
---
src/compiler/nir/nir_algebraic.py | 5 -
src/compiler/nir/nir_search.c | 3 +++
src/compiler/nir/nir_search.h | 8
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_algebraic.py
b/src/compiler/nir/nir_algebraic.py
index 19ac6ee..b0fa9e7
From: Kenneth Graunke
This tries to move comparisons (a common source of boolean values)
closer to their first use. For GPUs which use condition codes,
this can eliminate a lot of temporary booleans and comparisons
which reload the condition code register based on a
We can just get the swizzle from the instruction.
---
src/compiler/nir/nir_search.c | 3 +--
src/compiler/nir/nir_search.h | 3 +--
src/compiler/nir/nir_search_helpers.h | 22 ++
3 files changed, 12 insertions(+), 16 deletions(-)
diff --git
We turn these from bcsel into inot/b2f combos in order for other
optimisation passes to get further. Once we have finished turn
the ones that remain and are used in more than a single expression
back into a bcsel.
On BDW:
total instructions in shared programs: 13060965 -> 13060297 (-0.01%)
If we just check that we are not dealing with an identity swizzle
in match_value() before calling match_expression() we can avoid
a bunch of temp swizzle arrays and the passing it around and
resetting craziness.
---
src/compiler/nir/nir_search.c | 89 ++-
1
This is a collection of patches I've written and collected that
aim to reduce the pain when dropping brw_do_channel_expressions()
and brw_do_vector_splitting() two passes that combined take about
14% of the time it takes to run shader-db. This series includes
Ken's move comparisions series with a
From: Kenneth Graunke
While the below stats are encouraging this pass will also become
very usefull for avoiding regression once
brw_do_channel_expressions() and brw_do_vector_splitting() are
disabled.
On Broadwell:
total instructions in shared programs: 13078787 ->
On 01/10/2017 11:03 AM, Mauro Rossi wrote:
2017-01-10 9:38 GMT+01:00 Tapani Pälli :
Patches 1 & 2
(we've had patch 1 for some time in android-ia but forgot to send it)
Reviewed-by: Tapani Pälli
Patch 3 is not needed, this change is already
On Sat, 2017-01-07 at 11:13 -0800, Matt Turner wrote:
> On Sat, Jan 7, 2017 at 3:58 AM, Timothy Arceri
> wrote:
> > We turn these from bcsel into inot/b2f combos in order for other
> > optimisation passes to get further, once we have finished turn
> > the ones that
On 01/09/2017 10:03 PM, Roland Scheidegger wrote:
Am 06.01.2017 um 10:42 schrieb Samuel Pitoiset:
D3D always computes the absolute value while GLSL says that the
That should probably say "d3d9" - it is completely wrong for d3d10 and
later (which have it to be defined as a guaranteed NaN).
2017-01-06 18:35 GMT+01:00 Wu Zhen :
> From: WuZhen
>
> rename old swrast to softpipe, add a new driver llvmpipe
>
> Change-Id: Ia8bc1005ad6846df78bc1f6d0a4196310a049aca
> Reviewed-by: Mauro Rossi
> Reviewed-by: Chih-Wei Huang
2017-01-10 9:38 GMT+01:00 Tapani Pälli :
> Patches 1 & 2
>
> (we've had patch 1 for some time in android-ia but forgot to send it)
>
> Reviewed-by: Tapani Pälli
>
> Patch 3 is not needed, this change is already in Mesa. I'll try to
> compile-test
On Mon, 2017-01-09 at 15:47 -0800, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez writes:
>
> > From: "Juan A. Suarez Romero"
> >
> > The execution data size is the biggest type size of any instruction
> > operand.
> >
> > We will use it to know
Patches 1 & 2
(we've had patch 1 for some time in android-ia but forgot to send it)
Reviewed-by: Tapani Pälli
Patch 3 is not needed, this change is already in Mesa. I'll try to
compile-test the rest. For some reason this series does not apply for me
as is, patches
On 01/10/2017 10:14 AM, Tapani Pälli wrote:
this is to avoid following compilation error on Android:
error: control may reach end of non-void function [-Werror,-Wreturn-type]
Signed-off-by: Tapani Pälli
---
src/compiler/nir/nir.c | 6 +++---
1 file changed, 3
Reviewed-by: Samuel Iglesias Gonsálvez
On Tue, 2017-01-10 at 10:14 +0200, Tapani Pälli wrote:
> this is to avoid following compilation error on Android:
>
> error: control may reach end of non-void function [-Werror,-
> Wreturn-type]
>
> Signed-off-by: Tapani Pälli
this is to avoid following compilation error on Android:
error: control may reach end of non-void function [-Werror,-Wreturn-type]
Signed-off-by: Tapani Pälli
---
src/compiler/nir/nir.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
101 - 186 of 186 matches
Mail list logo