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 a/src/compiler/nir/nir.c b/src/com
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
> ---
> src/compiler/nir
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 insertions(+), 3 deletions(-
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 7,8,10,11 are causing some
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 if the instruction deals with DF, because in
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 the rest. For some reason this series does not appl
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
> ---
> Android.common.mk| 2 +-
> Andr
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).
(Ot
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 remain and are used in more than
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 in Mesa. I'll try to
compile-test the rest. For so
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 -> 13060898 (-0.14%)
instructio
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 c
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 boolean.
V2: (Timothy Arceri
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 a/src/compiler/nir
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%)
instru
---
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 1
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
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. Suggested by Jason Ekstrand
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: do
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 -> 256587
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 be used as back buffe
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 tracker to directly send it
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 from new cache directory it just created
which only
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 to check a return value?
>>
>>
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
implementation
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 X to be used as back
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 IvyBridge/Valleyview.
> >
> > Wow, the
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 'evict_random_item' attempts to remove cache content to
> > > >
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, Tapani Pälli > > > om
> >
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 > > > co
> > > >
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 auto.
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 mailing list
mesa-dev@lists.f
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 this in account when checking if instructio
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, Emi
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 = renderonly_create_kms_dumb_buffer_for_resource
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 (suggested by Emil)
> - adapted
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 infrastructure for renderonly
>
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 100644
> --- a/Android.c
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;
layout(lo
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 8dec55c..a1d300e 100644
--- a/src/ga
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 (commit
bd850cb4f2c77e2eb6
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 occurrenc
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 f
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.
---
src/gallium/drivers/radeonsi/si
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
b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
index 277ed5b..c0d7220 1
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 differentiating (using the cha
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 +
src/amd/common/ac_llvm_
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 nougat-x86 and marshmallow-x
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 a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common
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 a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_n
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 fb2c7dc..4021800 100644
--- a/src/ga
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
b/src/gallium/drivers/radeonsi/si
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 a/src/gallium/drivers/radeonsi/
Reviewed-by: Edward O'Callaghan
On 01/11/2017 01:59 AM, Nicolai Hähnle wrote:
> 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 funct
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
> Reviewed-by: Chih-Wei Huang
> ---
> src/gallium/auxiliary/os/os_misc.c
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 a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/a
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 functions will not be available.
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 extension were explicitly removed for core profiles
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.
For example:
> based on initial work by M
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 Android build can get a toggle to select
which on
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
>
> 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 you're getting - build or link-time error ?
L
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 questions:
- If we rename swrast I would sugge
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 only supposed to remov
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 inputs/outp
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
> Reviewed-by: Chih-Wei Huang
Thanks for s
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 directly to X
so this patch allows a state tracke
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 differentiating (using the cha
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 names when it is
>>>
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;
layout(lo
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;
> layout(location = 3) in flat int
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 bug.___
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 = 2) in flat int inRepeating;
la
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;
> > layout(location = 1) in float inGradientPos;
> > layout(locat
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 Ekstrand [v1]
> ---
> src/compiler/spirv/spirv_to_nir.c | 45 ++
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 ways. As a
> > > > gen
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 insertions(+), 2 deletions(-)
>
> Jason and I figured out ca
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 at 11:37 PM, Kenneth Graunke
> wrote:
>
>>
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
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/a
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
+++ 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;
layout(lo
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
index 8a69aa22f6..dbc8c3cf68 10064
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 +++
> src/intel/vulkan/genX_pipeline.c | 7 +-
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(+)
>
> diff --git a/src/intel/vulkan/genX_pipeline.c b/s
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
dEQP-GLES31.functional.ssbo
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 o
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;
>
I'll be honest, I'm not a fan... Given that D3D10 has one defined behavior,
D3D9 has another, and GL doesn't specify, I don't really think we should be
making a global change to all drivers to do the D3D9 behavior just to fix
one app. Sure, other apps probably have the same bug, but are we going t
On Tue, Jan 10, 2017 at 9:48 AM, Jason Ekstrand
wrote:
> I'll be honest, I'm not a fan... Given that D3D10 has one defined
> behavior, D3D9 has another, and GL doesn't specify, I don't really think we
> should be making a global change to all drivers to do the D3D9 behavior
> just to fix one app.
On Tue, Jan 10, 2017 at 12:51 PM, Jason Ekstrand wrote:
> On Tue, Jan 10, 2017 at 9:48 AM, Jason Ekstrand
> wrote:
>>
>> I'll be honest, I'm not a fan... Given that D3D10 has one defined
>> behavior, D3D9 has another, and GL doesn't specify, I don't really think we
>> should be making a global ch
On 2017-01-09 09:10:01, Juan A. Suarez Romero wrote:
> From: Alejandro Piñeiro
>
> ---
> src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index 5dd
Alex Deucher wrote:
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 directly to X
so this patch allows a state tracke
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;
layout(lo
Reviewed-by: Jason Ekstrand
On Tue, Jan 10, 2017 at 9:57 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 =
On Tue, Jan 10, 2017 at 12:56 PM, Andy Furniss wrote:
> Alex Deucher wrote:
>>
>> 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
On Tue, Jan 10, 2017 at 12:07 PM, Jan Vesely wrote:
> 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 de
On Tuesday, January 10, 2017 9:06:08 AM PST Jason Ekstrand wrote:
> 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 Ekstr
I don't like adding workarounds to our codebase for someone else's
problem, generally, but specifically I think this is a bad idea
because the name MESA_DEBUG is already used (it's an environment
variable), and this is a completely separate meaning.
___
m
On 17-01-09 16:42:19, Jason Ekstrand wrote:
Somehow I didn't actually get the original e-mail so I'm replying via
git-send-email...
On 01/02, Ben Widawsky wrote:
Modifiers will be obtains or guessed by the client and passed in during
image creation/import.
This requires bumping the DRIimage ve
before commit f871946594129500a67c05a6d9fe99db54b4bb64
image_loader_extension was always present in dri2_dpy->extensions,
after that commit it is only present for render nodes.
Its removal broke partial render based on buffer age on (at least)
raspberry pi.
Signed-off-by: Derek Foreman
---
I'm
1 - 100 of 187 matches
Mail list logo
