These don't seem to have been used since d1d12efb36074.
---
src/compiler/Makefile.sources | 1 -
src/compiler/nir/nir.c | 23 ---
src/compiler/nir/nir.h | 14
src/compiler/nir/nir_clone.c| 6 +-
src/compiler/nir
On Monday, August 1, 2016 10:35:06 AM PDT Timothy Arceri wrote:
> Cc: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 3309f
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 3309f61..d1ac80a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/dri
On Sun, 2016-07-31 at 18:43 +0300, Andres Gomez wrote:
> When an argument for a structure constructor or initializer doesn't
> match the expected type, only Section 4.1.10 “Implicit Conversions”
> are allowed to try to match that expected type.
>
> From page 32 (page 38 of the PDF) of the GLSL 1.2
On Sun, 2016-07-31 at 18:43 +0300, Andres Gomez wrote:
> Implicit conversions were added in the GLSL 1.20 spec version.
Does this help fix the CTS test or are you just adding it because you
noticed it?
Also I'd probably just add this to the ES check bellow.
/* GLSL 1.10 and ESSL do not allow
From: Marek Olšák
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97140
---
src/gallium/drivers/ddebug/dd_draw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/ddebug/dd_draw.c
b/src/gallium/drivers/ddebug/dd_draw.c
index 716208a..833454a 100644
--- a/src/ga
From: Marek Olšák
v_fma_f32 runs at FP64 rate (= slow). Alien Isolation and F1 2015 seem
to use fma for all d3d multiply-add instructions, which is silly.
This tries to restore performance for those games.
The main difference between v_mad_f32 and v_fma_f32 is that v_mad doesn't
support denorma
From: Marek Olšák
LLVM doesn't use it.
---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index e7354de..
From: Marek Olšák
---
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 32 +++---
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index cd9ac26..e7354de 1
From: Marek Olšák
---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 4c603fb..cd9ac26 100644
--- a/src/galli
From: Marek Olšák
This will be used by: amdgcn_glslc -mcpu=[family]
It can also be used for shader-db if you want stats for a different family.
---
src/gallium/drivers/radeonsi/si_pipe.c | 32
1 file changed, 32 insertions(+)
diff --git a/src/gallium/drivers/ra
From: Marek Olšák
They can only be run manually as described in HOW_TO_RUN.
It should help catch suboptimal code generation.
Some of the tests already fail.
---
src/gallium/drivers/radeonsi/glsl_tests/HOW_TO_RUN | 8
.../drivers/radeonsi/glsl_tests/bitcount.ll| 15 ++
.../rade
From: Marek Olšák
This will be used by GLSL lit tests.
For developers only. It shouldn't be distributable and it doesn't use
the Mesa build system.
---
src/gallium/drivers/radeonsi/glsl_tests/.gitignore | 2 +
src/gallium/drivers/radeonsi/glsl_tests/Makefile | 29 ++
.../drivers/radeonsi/g
Inspired by LLVM, I created a small test suite that looks like "lit" tests,
except that the input is GLSL and it verifies asm.
The motivation was to verify that we generate optimal code when starting from
GLSL.
[PATCH 1/3] radeonsi: add environment variable SI_FORCE_FAMILY
[PATCH 2/3] radeonsi:
Kenneth Graunke writes:
> On Friday, July 22, 2016 8:59:03 PM PDT Francisco Jerez wrote:
>> The problem with the current approach is that driver output locations
>> are represented as a linear offset within the nir_outputs array, which
>> makes it rather difficult for the back-end to figure out w
AST_NUM_OPERATORS stores the dimension of the ast_operators
enumeration but was not updated after its last modification.
This doesn't add any real modification for any code paths but it makes
sense for coherence.
Signed-off-by: Andres Gomez
---
src/compiler/glsl/ast.h | 19 ++--
Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>
---
src/egl/drivers/dri2/egl_dri2.h| 19 ++-
src/gallium/auxiliary/vl/vl_winsys_dri3.c | 2 +-
src/glx/dri3_glx.c | 1 +
src/glx/dri3_priv.h|
Implicit conversions were added in the GLSL 1.20 spec version.
Signed-off-by: Andres Gomez
---
src/compiler/glsl_types.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 8a06695..24aec25 100644
--- a/src/compiler/glsl_types
When an argument for a structure constructor or initializer doesn't
match the expected type, only Section 4.1.10 “Implicit Conversions”
are allowed to try to match that expected type.
From page 32 (page 38 of the PDF) of the GLSL 1.20 spec:
" The arguments to the constructor will be used to set
When an argument for a structure constructor or initializer doesn't
match the expected type, only Section 4.1.10 “Implicit Conversions”
are allowed to try to match that expected type.
Fixes GL44-CTS.shading_language_420pack.initializer_list_negative
Andres Gomez (2):
glsl/types: disallow implic
Found with valgrind:
==4841== Invalid read of size 4
==4841==at 0x56BDC80: dri2_initialize (egl_dri2.c:783)
==4841==by 0x56BAFE5: _eglMatchAndInitialize (egldriver.c:261)
==4841==by 0x56BB15E: _eglMatchDriver (egldriver.c:295)
==4841==by 0x56B58C9: eglInitialize (eglapi.c:480)
==48
If packing doesn't cross locations we can easily make use of
ARB_enhanced_layouts to do packing rather than using the GLSL IR
lowering pass lower_packed_varyings().
Shader-db Broadwell results:
total instructions in shared programs: 8716541 -> 8716423 (-0.00%)
instructions in affected programs: 7
On Tue, Jul 26, 2016 at 03:11:28PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_blorp.c | 43
> ---
> 1 file changed, 25 insertions(+), 18 deletions(-)
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
>
On Tue, Jul 26, 2016 at 03:11:27PM -0700, Jason Ekstrand wrote:
> The helpers are completely miptree-unaware and each fairly cleanly do a
> single thing. This does come at the downside of not doing proper debug
> reporting on whether or not we're doing replicated clears.
> ---
> src/mesa/drivers/
On Tue, Jul 26, 2016 at 03:11:26PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 +-
> src/mesa/drivers/dri/i965/brw_meta_util.c | 27
> +++
> src/mesa/drivers/dri/i965/brw_meta_util.h | 2 +-
> 3 files changed, 17 inserti
On Tue, Jul 26, 2016 at 03:11:25PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
Patches 20 and 21 (preparing for patch 23) are:
Reviewed-by: Topi Pohjolainen
>
> diff --git a/s
On Thursday, July 28, 2016 12:45:36 AM PDT Kenneth Graunke wrote:
> On Friday, July 22, 2016 8:58:54 PM PDT Francisco Jerez wrote:
> > This is an implementation of non-coherent framebuffer fetch as
> > described here [1] working on most hardware generations supported
> > by the i965 driver (from Ge
On Tue, Jul 26, 2016 at 03:11:23PM -0700, Jason Ekstrand wrote:
> The blorp_surface_info_init call above should ste the format for us and
set
Reviewed-by: Topi Pohjolainen
> stomping it later does nothing whatsoever.
> ---
> src/mesa/drivers/dri/
Subject says: "Only modify the input parameters in get_fast_clear_rect".
This is about stopping to re-apply gl_framebuffer.
Other than that patches 16-18 are:
Reviewed-by: Topi Pohjolainen
On Tue, Jul 26, 2016 at 03:11:22PM -0700, Jason Ekstrand wrote:
> We had another inline copy of brw_meta_
On Friday, July 22, 2016 8:59:10 PM PDT Francisco Jerez wrote:
> This surface state control has been supported by all hardware
> generations since G45.
> ---
> src/mesa/drivers/dri/i965/brw_device_info.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_devi
On Tue, Jul 26, 2016 at 03:11:19PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 5 ++--
> src/mesa/drivers/dri/i965/brw_meta_util.c | 43
> +--
> src/mesa/drivers/dri/i965/brw_meta_util.h | 8 ++---
> 3 files changed, 28 in
Configure checks for compiler to be gcc and then it enables asm_offsets
generation. see
https://cgit.freedesktop.org/mesa/mesa/commit/?id=73c9b4b0e05fc66629ba250846948dc55c0e7a0d
However, we missed the check when enabling this on cross compilation
when architecture for both host and target is x8
On Tue, Jul 26, 2016 at 03:11:18PM -0700, Jason Ekstrand wrote:
> Now that we have the brw_blorp_surf struct, we can start to make bits of
> blorp completely miptree-unaware. To start things off, we split the guts
> of brw_blorp_blit_miptrees into a brw_blorp_blit function which knows
> nothing ab
On Tue, Jul 26, 2016 at 03:11:17PM -0700, Jason Ekstrand wrote:
> At the moment, this seems to make all of the interfaces messier rather than
> clener. However, it does provide a representation of a surface that
> simultaneously contains everything and is completely unaware of miptrees.
Quite a b
On Sun, Jul 31, 2016 at 10:32:33AM +0300, Pohjolainen, Topi wrote:
> On Tue, Jul 26, 2016 at 03:11:06PM -0700, Jason Ekstrand wrote:
> > ---
> > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965
On Friday, July 22, 2016 8:59:05 PM PDT Francisco Jerez wrote:
> This gets the non-coherent framebuffer fetch path hooked up to the NIR
> front-end.
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/
On Tue, Jul 26, 2016 at 03:11:05PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers
On Tue, Jul 26, 2016 at 03:11:06PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index
On Friday, July 22, 2016 8:59:03 PM PDT Francisco Jerez wrote:
> The problem with the current approach is that driver output locations
> are represented as a linear offset within the nir_outputs array, which
> makes it rather difficult for the back-end to figure out what color
> output and index so
39 matches
Mail list logo
