[Mesa-dev] [PATCH] tgsi/exec: fix LDEXP in softpipe

2017-11-15 Thread Nicolai Hähnle
From: Nicolai Hähnle 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103128
Fixes: cad959d90145 ("gallium: add LDEXP TGSI instruction and corresponding 
cap")
---
 src/gallium/auxiliary/tgsi/tgsi_exec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index afed96c9b1d..793c0da39ab 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -5123,21 +5123,21 @@ exec_instruction(
 
case TGSI_OPCODE_LG2:
   exec_scalar_unary(mach, inst, micro_lg2, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
   break;
 
case TGSI_OPCODE_POW:
   exec_scalar_binary(mach, inst, micro_pow, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
   break;
 
case TGSI_OPCODE_LDEXP:
-  exec_scalar_binary(mach, inst, micro_ldexp, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_INT);
+  exec_vector_binary(mach, inst, micro_ldexp, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
   break;
 
case TGSI_OPCODE_COS:
   exec_scalar_unary(mach, inst, micro_cos, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
   break;
 
case TGSI_OPCODE_DDX:
   exec_vector_unary(mach, inst, micro_ddx, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
   break;
 
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] amd: build addrlib with C++11

2017-11-15 Thread Dylan Baker
Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
cannot be built without it (Because of LLVM). As far as I can tell the GLSL
compiler and the Intel Compiler are the only C++ code in mesa not using C++11.

Quoting Kai Wasserbäch (2017-11-15 08:45:30)
> Doesn't the meson.build file need the same change?
> 
> Nicolai Hähnle wrote on 15.11.2017 12:55:
> > From: Nicolai Hähnle 
> > 
> > It is required for LLVM anyway.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103658
> > Fixes: 7f33e94e43a6 ("amd/addrlib: update to latest version")
> > ---
> >  src/amd/Makefile.addrlib.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am
> > index 46689637f9b..90dfe963445 100644
> > --- a/src/amd/Makefile.addrlib.am
> > +++ b/src/amd/Makefile.addrlib.am
> > @@ -26,15 +26,15 @@ addrlib_libamdgpu_addrlib_la_CPPFLAGS = \
> >   -I$(srcdir)/common \
> >   -I$(srcdir)/addrlib \
> >   -I$(srcdir)/addrlib/core \
> >   -I$(srcdir)/addrlib/inc/chip/gfx9 \
> >   -I$(srcdir)/addrlib/inc/chip/r800 \
> >   -I$(srcdir)/addrlib/gfx9/chip \
> >   -I$(srcdir)/addrlib/r800/chip \
> >   -DBRAHMA_BUILD=1
> >  
> >  addrlib_libamdgpu_addrlib_la_CXXFLAGS = \
> > - $(VISIBILITY_CXXFLAGS)
> > + $(VISIBILITY_CXXFLAGS) $(CXX11_CXXFLAGS)
> >  
> >  noinst_LTLIBRARIES += $(ADDRLIB_LIBS)
> >  
> >  addrlib_libamdgpu_addrlib_la_SOURCES = $(ADDRLIB_FILES)
> 
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] amd: build addrlib with C++11

2017-11-15 Thread Dylan Baker
Quoting Ilia Mirkin (2017-11-15 09:52:06)
> On Wed, Nov 15, 2017 at 12:47 PM, Dylan Baker  wrote:
> > Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
> > cannot be built without it (Because of LLVM). As far as I can tell the GLSL
> > compiler and the Intel Compiler are the only C++ code in mesa not using 
> > C++11.
> 
> Actually C++11 isn't used anywhere except clover and swr, AFAIK. (Look
> for CXX11_CXXFLAGS.)
> 
>   -ilia

I should have added the Nouveau compiler to the list of code that doesn't
require C++11, sorry about that :)

However, LLVM has been built with C++11 since at least 4.0, and anything linking
to it (r300, r600, radeonsi, radv, llvmpipe) have to be built with it even if
they don't use C++11 features, because LLVM does. I think we mostly get around
this because autotools doesn't set a standard (by default), and clang++ and g++
have had C++11 as the default standard for quite a while now (at least back to
gcc 4.8).

For giggles I tried to build just llvmpipe with the C++ standard set to c++03
and I got a massive pile of syntax errors from the compiler.

If you want to try that with meson you could run:
sed -i -e 's@c++11@c++03@g' meson.build
meson build-cpp03 -Dgallium-drivers=swrast -Ddri-drivers= -Dvulkan-drivers=

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] amd: build addrlib with C++11

2017-11-15 Thread Nicolai Hähnle

On 15.11.2017 17:45, Kai Wasserbäch wrote:

Doesn't the meson.build file need the same change?


I don't really know Meson, but the master build file looks to me like 
Meson always builds with C++11.


Cheers,
Nicolai



Nicolai Hähnle wrote on 15.11.2017 12:55:

From: Nicolai Hähnle 

It is required for LLVM anyway.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103658
Fixes: 7f33e94e43a6 ("amd/addrlib: update to latest version")
---
  src/amd/Makefile.addrlib.am | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am
index 46689637f9b..90dfe963445 100644
--- a/src/amd/Makefile.addrlib.am
+++ b/src/amd/Makefile.addrlib.am
@@ -26,15 +26,15 @@ addrlib_libamdgpu_addrlib_la_CPPFLAGS = \
-I$(srcdir)/common \
-I$(srcdir)/addrlib \
-I$(srcdir)/addrlib/core \
-I$(srcdir)/addrlib/inc/chip/gfx9 \
-I$(srcdir)/addrlib/inc/chip/r800 \
-I$(srcdir)/addrlib/gfx9/chip \
-I$(srcdir)/addrlib/r800/chip \
-DBRAHMA_BUILD=1
  
  addrlib_libamdgpu_addrlib_la_CXXFLAGS = \

-   $(VISIBILITY_CXXFLAGS)
+   $(VISIBILITY_CXXFLAGS) $(CXX11_CXXFLAGS)
  
  noinst_LTLIBRARIES += $(ADDRLIB_LIBS)
  
  addrlib_libamdgpu_addrlib_la_SOURCES = $(ADDRLIB_FILES)




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

2017-11-15 Thread Dylan Baker
Quoting Nicolai Hähnle (2017-11-15 06:35:49)
> From: Nicolai Hähnle 
> 
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
> 
> Cc: Jon Turney 
> Cc: Rob Herring 
> Cc: Alexander von Gluck IV 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
> Fixes: f1a364878431 ("threads: update for late C11 changes")
> ---
>  SConstruct  | 7 +++
>  configure.ac| 1 +
>  include/c11/threads_posix.h | 2 +-
>  meson.build | 2 +-
>  4 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/SConstruct b/SConstruct
> index a59a8ea210e..1ef134af27d 100644
> --- a/SConstruct
> +++ b/SConstruct
> @@ -122,20 +122,27 @@ if env['crosscompile'] and not env['embedded']:
>  Export('env')
>  
>  SConscript(
>  'src/SConscript',
>  variant_dir = host_env['build_dir'],
>  duplicate = 0, # 
> http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
>  )
>  
>  env = target_env
>  
> +if env['platform'] != 'windows':
> +   # This is quite incomplete, but it hopefully covers the platforms that
> +   # people actually use SCons on...
> +   env.Append(CPPDEFINES= [
> +  'HAVE_TIMESPEC_GET',
> +   ])
> +

I think that haiku uses scons, I've added one of (and hopefully an appropriate)
person that works on Haiku.

Otherwise I think this looks good, as long as the Haiku guys think this is fine
for them,
Reviewed-by: Dylan Baker 


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 103128] [softpipe] piglit fs-ldexp regression

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103128

--- Comment #2 from Nicolai Hähnle  ---
https://patchwork.freedesktop.org/patch/188544/ fixes this for me.

-- 
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.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v5 00/10] new series of Mesa for Tizen

2017-11-15 Thread Eric Anholt
"Mun, Gwan-gyeong"  writes:

> Hi all,
>
> I am sorry that I didn't have enough discussion about why new window
> system code is needed for Tizen on mesa.
>
> This is a brief architecture of Tizen Window System.
>
>   
> +--+
>   | [Tizen Window System Architecture]
>   |
>   |
>   |
>   |
>   |
>   |
>   |
>   |  +---+
> ++  ++  |
>   |  | Enlightenment Display |   |
>|  |   3D UI|  |
>   |  |  Server for Tizen +-->|
> EvasGL   |  |   Toolkit  |  |
>   |  |   |   |
>|  ||  |
>   |  |   |
> +-+--+  +-+--+  |
>   |  +--+-+--+
> |   | |
>   | | |
> v   | |
>   | | |
> ++| |
>   | | |  | GPU
> Vendor || |
>   | | |  |
> GL/EGL|<---+ |
>   | | |  |
> Driver|  |
>   | | |
> +-+--+  |
>   | | |
> | |
>   | v v
> v |
>   |   +---++--+
> ++  |
>   |   | TDM   ||TBM   |  |
>|  |
>   |   |(Tizen Display Manager)+--->|(Tizen Buffer Manager)|<-|
> TPL-EGL  |  |
>   |   |   ||  |  |
>|  |
>   |   +---++--+
> ++  |
>   |
>   |
>   
> +--+
>
>
>
> < display server / wayland-egl client >
>
> +-+
> +---+
> | |   |
>|
> |  +---+  |   |
> +---+   |
> |  | Enlightenment Display +---+  |
> |  wayland-egl client   |   |
> |  |  Server for Tizen |  ||  |
> +--+-+--+   |
> |  +--++  ||  |
>   | |  |
> | |   ||  |
>   | |  |
> | v   ||  |
>   | |  |
> |  +---+  ||  |
>   | |  |
> |  | EVAS GL TBM   |  ||  |
>   | |  |
> |  ++-++  ||  |
>   | |  |
> |   | |   ||  |
>   | |  |
> |   | v   ||  |
>   v v  |
> |   |+-+  ||+--+  |
> +-+   +-+   |
> |   ||   EGL   +---|--->|  GPU Vendor
> |<-+ EGL |   | wayland-egl |   |
> |   |+++  |||  GL Driver   |  |
> +--+--+   +---+-+   |
> |   | |   ||+--+  |
>   |  |  ^  |
> |   v v   ||  |
>   v  v  |  |
> |  +-+   +-+  ||+--+  |
> ++--+   |
> |  |   TBM   |<--+ TPL-EGL +---|--->| wayland-tbm
> |<-+TPL-EGL|   |
> |  +-+   +-+  ||+--+  |
> +---+   |
> | ||^ |
>|
> | ||| |
>|
> +-+++
> 

Re: [Mesa-dev] [ANNOUNCE] mesa 17.3.0-rc4

2017-11-15 Thread Andres Gomez
On Tue, 2017-11-14 at 11:28 -0800, Matt Turner wrote:
> On Tue, Nov 14, 2017 at 6:37 AM, Emil Velikov  
> wrote:
> > The fourth release candidate for Mesa 17.3.0 is now available.
> > 
> > As per the issue tracker [1] we still have a number of outstanding bugs
> > blocking the release.
> > 
> > [1] https://bugs.freedesktop.org/show_bug.cgi?id=103491
> > 
> > Andreas Boll (3):
> >   broadcom/vc5: Add vc5_drm.h to the release tarball
> >   broadcom/vc5: Remove unused v3d_compiler.c
> >   glsl: Fix typo fragement -> fragment
> > 
> > Dave Airlie (2):
> >   radv: free attachments on end command buffer.
> >   radv: add initial copy descriptor support. (v2)
> > 
> > Dylan Baker (1):
> >   autotools: Set C++ visibility flags on Intel
> > 
> > Emil Velikov (5):
> >   targets/opencl: don't hardcode the icd file install to /etc/...
> >   automake: intel: correctly append to the LIBADD variable
> >   configure.ac: loosen --enable-glvnd check to honour egl
> >   configure.ac: require xcb* for the omx/va/... when using x11 platform
> >   Update version to 17.3.0-rc4
> > 
> > Jason Ekstrand (15):
> >   intel/fs: Use a pure vertical stride for large register strides
> 
> I've reverted this on master and sent an email to mesa-stable@ to
> cherry-pick two other commits instead. Please revert this from 17.3.
> 
> Andres, you probably should do the same for 17.2.

Thanks for the heads up, Matt. Fortunately, we don't need to revert on
17.2, just not cherry-pick it.

I've also included your 2 nominations, in any case.

-- 
Br,

Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] meson: Don't define HAVE_PTHREAD only on linux

2017-11-15 Thread Dylan Baker
Quoting Jon Turney (2017-11-15 02:52:29)
> I'm not sure of the reason for this. I don't see anything like this in
> configure.ac

I hadn't had a chance to test other platforms, and I wasn't sure about Windows
and Haiku. Some of the BSD's also stiil use pthread-stubs, and I don't think
those get HAVE_PTHREADS.

I also don't konw what depdnency('threads') returns on windows, but in mean time
this probably fixes some platforms and doesn't break any that previous worked.

Reviewed-by: Dylan Baker 

> 
> In include/c11/threads.h the cases are:
> 
> 1) building for Windows -> threads_win32.h
> 2) HAVE_PTHREAD -> threads_posix.h
> 3) Not supported on this platform
> 
> So not defining HAVE_PTHREAD for anything not Windows just means we can't
> build at all.
> 
> When we are building for Windows, I'm not sure if dependency('threads')
> would ever find anything, or defining HAVE_PTHREAD has any effect, but avoid
> defining it there, just in case.
> 
> Signed-off-by: Jon Turney 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 84c0e102737..a0dd02b1f64 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -668,7 +668,7 @@ endif
>  # TODO: some of these may be conditional
>  dep_zlib = dependency('zlib', version : '>= 1.2.3')
>  dep_thread = dependency('threads')
> -if dep_thread.found() and host_machine.system() == 'linux'
> +if dep_thread.found() and host_machine.system() != 'windows'
>pre_args += '-DHAVE_PTHREAD'
>  endif
>  dep_elf = dependency('libelf', required : false)
> -- 
> 2.15.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-15 Thread Lucas Stach
Hi Wladimir,

Am Mittwoch, den 15.11.2017, 18:03 +0100 schrieb Wladimir J. van der Laan:
> A recent commit (see below) fixed flat shading but at the same time
> broke the use of point sprites with multiple varyings. This resulted in
> particle systems rendering wrongly.
> 
> The reason for this is that it set VARYING_COMPONENT_USE_POINTCOORD_[XY]
> for all non-color varyings, causing them to be replaced with the point
> coordinate when rendering points.
> 
> VARYING_COMPONENT_USE_POINTCOORD_[XY] is a misnomer, it should be
> TEXCOORD. Its semantics are: texture coordinates will get replaced with
> the point coordinate when rendering GL_POINTS, for other primitives
> their interpolation is independent of the shading model.
> 
> So use VARYING_COMPONENT_USE_POINTCOORD_[XY] only for texture coordinates.
> This causes them to be interpolated correctly while flat shading, while
> generic varyings are left as-is when rendering point sprites.

Sorry for noticing before, but this breaks glmark2 texture. I didn't
yet dig into the issue but it's definitely caused by this commit.

To reproduce, simply run
glmark2-es2-drm -b texture:texture-filter=mipmap

Regards,
Lucas

> Fixes: cedab87e762aa38997a07bc8a2eb624aed584afd "etnaviv: fix varying 
> interpolation"
> > Signed-off-by: Wladimir J. van der Laan 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_compiler.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
> b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> index 3180646..6569979 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> @@ -2561,7 +2561,11 @@ etna_link_shader(struct etna_shader_link_info *info,
>    const struct etna_shader_inout *fsio = >infile.reg[idx];
>    const struct etna_shader_inout *vsio = etna_shader_vs_lookup(vs, fsio);
>    struct etna_varying *varying;
> -  bool interpolate_always = fsio->semantic.Name != TGSI_SEMANTIC_COLOR;
> +  /* Texture coordinates will get replaced with the point coordinate when
> +   * rendering GL_POINTS, for other primitives their interpolation is
> +   * independent of the shading model. */
> +  bool is_texcoord = fsio->semantic.Name == TGSI_SEMANTIC_TEXCOORD ||
> + fsio->semantic.Name == TGSI_SEMANTIC_PCOORD;
>  
>    assert(fsio->reg > 0 && fsio->reg <= ARRAY_SIZE(info->varyings));
>  
> @@ -2571,13 +2575,14 @@ etna_link_shader(struct etna_shader_link_info *info,
>    varying = >varyings[fsio->reg - 1];
>    varying->num_components = fsio->num_components;
>  
> -  if (!interpolate_always) /* colors affected by flat shading */
> +  /* PA_ATTRIBUTES appears to be unused on HALTI0 and up */
> +  if (!is_texcoord) /* colors affected by flat shading */
>   varying->pa_attributes = 0x200;
>    else /* texture coord or other bypasses flat shading */
>   varying->pa_attributes = 0x2f1;
>  
> -  varying->use[0] = interpolate_always ? 
> VARYING_COMPONENT_USE_POINTCOORD_X : VARYING_COMPONENT_USE_USED;
> -  varying->use[1] = interpolate_always ? 
> VARYING_COMPONENT_USE_POINTCOORD_Y : VARYING_COMPONENT_USE_USED;
> +  varying->use[0] = is_texcoord ? VARYING_COMPONENT_USE_POINTCOORD_X : 
> VARYING_COMPONENT_USE_USED;
> +  varying->use[1] = is_texcoord ? VARYING_COMPONENT_USE_POINTCOORD_Y : 
> VARYING_COMPONENT_USE_USED;
>    varying->use[2] = VARYING_COMPONENT_USE_USED;
>    varying->use[3] = VARYING_COMPONENT_USE_USED;
>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] meson: Add dridriverdir variable to dri.pc.

2017-11-15 Thread Dylan Baker
Reviewed-by: Dylan Baker 

Quoting Rafael Antognolli (2017-11-15 09:32:47)
> Xorg (and possibly other things) depend on this variable to find the
> path to DRI drivers.
> 
> Signed-off-by: Rafael Antognolli 
> Cc: Dylan Baker 
> ---
>  src/mesa/drivers/dri/meson.build | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/mesa/drivers/dri/meson.build 
> b/src/mesa/drivers/dri/meson.build
> index a2fc8db8ada..217f1e5c71c 100644
> --- a/src/mesa/drivers/dri/meson.build
> +++ b/src/mesa/drivers/dri/meson.build
> @@ -58,6 +58,7 @@ if dri_drivers != []
>  filebase : 'dri',
>  description : 'Direct Rendering Infrastructure',
>  version : meson.project_version(),
> +variables : ['dridriverdir=${prefix}/' + dri_drivers_path],
>  requires_private : ['libdrm >= 2.4.75'],  # FIXME: don't hardcode this
>)
>  
> -- 
> 2.13.6
> 


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] amd: build addrlib with C++11

2017-11-15 Thread Ilia Mirkin
On Wed, Nov 15, 2017 at 12:47 PM, Dylan Baker  wrote:
> Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
> cannot be built without it (Because of LLVM). As far as I can tell the GLSL
> compiler and the Intel Compiler are the only C++ code in mesa not using C++11.

Actually C++11 isn't used anywhere except clover and swr, AFAIK. (Look
for CXX11_CXXFLAGS.)

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

2017-11-15 Thread Wladimir J. van der Laan
> Sorry for noticing before, but this breaks glmark2 texture. I didn't
> yet dig into the issue but it's definitely caused by this commit.
> 
> To reproduce, simply run
> glmark2-es2-drm -b texture:texture-filter=mipmap

That's weird, as that neither uses point sprites nor flat shading.

I'll have a look...

Regards,
Wladimir
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/13] i965: remove ARB_compute_shader extension override

2017-11-15 Thread Jordan Justen
On 2017-11-14 07:37:27, Emil Velikov wrote:
> On 10 November 2017 at 23:39, Jordan Justen  wrote:
> > On 2017-11-10 08:19:38, Emil Velikov wrote:
> >> On 7 November 2017 at 11:54, Emil Velikov  wrote:
> >> > From: Emil Velikov 
> >> >
> >> > Checking the override was useful in the early stages of developing the
> >> > extension.
> >> >
> >> > Now that everything is wired, where possible, we can drop the check.
> >> > Doing so allows us to simplify some of the related code.
> >> >
> >> > Cc: Jordan Justen 
> >> > Signed-off-by: Emil Velikov 
> >> > ---
> >> >  src/mesa/drivers/dri/i965/brw_context.c | 3 +--
> >> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >> >
> >> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> >> > b/src/mesa/drivers/dri/i965/brw_context.c
> >> > index 1bf39b07382..3947a71a46a 100644
> >> > --- a/src/mesa/drivers/dri/i965/brw_context.c
> >> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
> >> > @@ -348,8 +348,7 @@ brw_initialize_context_constants(struct brw_context 
> >> > *brw)
> >> >   (_mesa_is_desktop_gl(ctx) &&
> >> >ctx->Const.MaxComputeWorkGroupSize[0] >= 1024) ||
> >> >   (ctx->API == API_OPENGLES2 &&
> >> > -  ctx->Const.MaxComputeWorkGroupSize[0] >= 128) ||
> >> > - _mesa_extension_override_enables.ARB_compute_shader,
> >> > +  ctx->Const.MaxComputeWorkGroupSize[0] >= 128),
> >>
> >> Jordan can you throw an Ack on this patch if it makes sense?
> >> Brian already reviewed the series, but I'd appreciate input from
> >> someone familiar with the Intel specifics.
> >
> > Regarding patches 2 & 8, the point of those being non-static was so
> > the driver could take some action if the user requested an extension
> > override.
> >
> > I can't remember, but maybe with SIMD32 being supported, this might no
> > longer affect any i965 devices.
> >
> > I still think it could be good to allow the driver to easily know what
> > extensions were overridden, but I'll concede that it is not too
> > important. So, go ahead with the change if you want.
> >
> Agreed allowing the driver to query the extension status is useful,
> esp. during development.
> 
> Since they're not used I made them static for now, but can add a
> comment as below to make it clearer.
> What do you think? Can I get your official blessing (ack/r-b) with that?

For this patch, Reviewed-by: Jordan Justen 

I'm not sure what you are proposing for patch 8. I would prefer to
just drop 8, but I'm not sure how big of an impact that makes to your
series.

If you are proposing to drop patch 8, and instead add the comment
below on the variables... What about this small tweak?

/* Sometimes the driver wants to query the extension override status before
 * a context is created. These variables are filled with extension override
 * information before context creation.
 *
 * This can be useful during extension bring-up when an extension is
 * partially implemented, but cannot yet be advertised as supported.
 *
 * Use it with care and keep access read-only.
 */


> Thanks
> Emil
> 
> 
> /* Sometimes the driver wants to query the extensions status before a context
>  * is created. To achieve that one should use the following two variables. 
> This
>  * is very useful during extension bring-up, but can be a double-edged sword.
>  *
>  * Use it with care and keep access read-only.
>  */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/13] i965: remove ARB_compute_shader extension override

2017-11-15 Thread Emil Velikov
On 15 November 2017 at 19:30, Jordan Justen  wrote:
> On 2017-11-14 07:37:27, Emil Velikov wrote:
>> On 10 November 2017 at 23:39, Jordan Justen  
>> wrote:
>> > On 2017-11-10 08:19:38, Emil Velikov wrote:
>> >> On 7 November 2017 at 11:54, Emil Velikov  
>> >> wrote:
>> >> > From: Emil Velikov 
>> >> >
>> >> > Checking the override was useful in the early stages of developing the
>> >> > extension.
>> >> >
>> >> > Now that everything is wired, where possible, we can drop the check.
>> >> > Doing so allows us to simplify some of the related code.
>> >> >
>> >> > Cc: Jordan Justen 
>> >> > Signed-off-by: Emil Velikov 
>> >> > ---
>> >> >  src/mesa/drivers/dri/i965/brw_context.c | 3 +--
>> >> >  1 file changed, 1 insertion(+), 2 deletions(-)
>> >> >
>> >> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
>> >> > b/src/mesa/drivers/dri/i965/brw_context.c
>> >> > index 1bf39b07382..3947a71a46a 100644
>> >> > --- a/src/mesa/drivers/dri/i965/brw_context.c
>> >> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
>> >> > @@ -348,8 +348,7 @@ brw_initialize_context_constants(struct brw_context 
>> >> > *brw)
>> >> >   (_mesa_is_desktop_gl(ctx) &&
>> >> >ctx->Const.MaxComputeWorkGroupSize[0] >= 1024) ||
>> >> >   (ctx->API == API_OPENGLES2 &&
>> >> > -  ctx->Const.MaxComputeWorkGroupSize[0] >= 128) ||
>> >> > - _mesa_extension_override_enables.ARB_compute_shader,
>> >> > +  ctx->Const.MaxComputeWorkGroupSize[0] >= 128),
>> >>
>> >> Jordan can you throw an Ack on this patch if it makes sense?
>> >> Brian already reviewed the series, but I'd appreciate input from
>> >> someone familiar with the Intel specifics.
>> >
>> > Regarding patches 2 & 8, the point of those being non-static was so
>> > the driver could take some action if the user requested an extension
>> > override.
>> >
>> > I can't remember, but maybe with SIMD32 being supported, this might no
>> > longer affect any i965 devices.
>> >
>> > I still think it could be good to allow the driver to easily know what
>> > extensions were overridden, but I'll concede that it is not too
>> > important. So, go ahead with the change if you want.
>> >
>> Agreed allowing the driver to query the extension status is useful,
>> esp. during development.
>>
>> Since they're not used I made them static for now, but can add a
>> comment as below to make it clearer.
>> What do you think? Can I get your official blessing (ack/r-b) with that?
>
> For this patch, Reviewed-by: Jordan Justen 
>
> I'm not sure what you are proposing for patch 8. I would prefer to
> just drop 8, but I'm not sure how big of an impact that makes to your
> series.
>
> If you are proposing to drop patch 8, and instead add the comment
> below on the variables... What about this small tweak?
>
I was split between dropping or keeping with the comment squashed.
Let's drop 08 - the dead trivial conflict in 12/13 is fine.

> /* Sometimes the driver wants to query the extension override status before
>  * a context is created. These variables are filled with extension override
>  * information before context creation.
>  *
>  * This can be useful during extension bring-up when an extension is
>  * partially implemented, but cannot yet be advertised as supported.
>  *
>  * Use it with care and keep access read-only.
>  */
>
Nice - it reads a lot easier. I'll whip it into a patch form and send
out (for posterity) tomorrow.

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] tgsi/exec: fix LDEXP in softpipe

2017-11-15 Thread Brian Paul

Reviewed-by: Brian Paul 


On 11/15/2017 11:35 AM, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

Bugzilla: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D103128=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=xmgFaDIVj7aLD3q4rCR_QYavBqvQH6DsYgtLGUXvpcQ=reW4GkhIDPr33R7C6PMnrgFtF-JCGUQl6oc89AqDDM4=
Fixes: cad959d90145 ("gallium: add LDEXP TGSI instruction and corresponding 
cap")
---
  src/gallium/auxiliary/tgsi/tgsi_exec.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index afed96c9b1d..793c0da39ab 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -5123,21 +5123,21 @@ exec_instruction(

 case TGSI_OPCODE_LG2:
exec_scalar_unary(mach, inst, micro_lg2, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
break;

 case TGSI_OPCODE_POW:
exec_scalar_binary(mach, inst, micro_pow, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
break;

 case TGSI_OPCODE_LDEXP:
-  exec_scalar_binary(mach, inst, micro_ldexp, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_INT);
+  exec_vector_binary(mach, inst, micro_ldexp, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
break;

 case TGSI_OPCODE_COS:
exec_scalar_unary(mach, inst, micro_cos, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
break;

 case TGSI_OPCODE_DDX:
exec_vector_unary(mach, inst, micro_ddx, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
break;




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

2017-11-15 Thread Jon Turney

On 15/11/2017 14:35, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds

Cc: Jon Turney 
Cc: Rob Herring 
Cc: Alexander von Gluck IV 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11 changes")
---
  SConstruct  | 7 +++
  configure.ac| 1 +
  include/c11/threads_posix.h | 2 +-
  meson.build | 2 +-
  4 files changed, 10 insertions(+), 2 deletions(-)


Reviewed-by: Jon Turney 

Thanks!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] Driver testing system for Steam games

2017-11-15 Thread Pierre-Loup A. Griffais

Hi Mesa-Devel,

Today we're happy to announce that we're making the LunarG driver
testing system available to the Mesa development community. We've been
using this system internally for quite some time, but we've recently
done some more work so the results could also be publicly available for
the community to track regressions, and for developers to be able to
submit their branches for pre-submit testing.

The LunarG test system is a service that provides regular regression
testing on Mesa releases for Intel and AMD OpenGL graphics drivers. It
also enables users to test their own Mesa builds and compare results to
LunarG baselines, LunarG test runs, or user test runs. The objective of
the LunarG test system service for Mesa is to identify regressions in
performance or rendering for Mesa releases and developer's branches that
would negatively impact the gaming experience.

The test suite is a collection of trace files created from hundreds of
Linux OpenGL games from Steam. These trace files are used to automate
testing of rendering correctness as well as game performance. There are
currently 6 graphics platforms available for test (3 configurations each
of Intel and AMD graphics). The full suite of games typically runs
overnight with results posted the next day.

To access the test system and browse results: https://share.lunarg.com 
(click on "Test System") on the left.


Here's an example of a test report that a Mesa bug could possibly be 
filed from after inspection: https://imgur.com/a/cBonz


To learn more about how the test system works, read the short user
manual: https://share.lunarg.com/test/manual

Let us know if you have any feedback or questions. Vulkan support is
planned for the future, but not ready quite yet.

Thanks,
  - Pierre-Loup

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v3] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

2017-11-15 Thread Nicolai Hähnle
From: Nicolai Hähnle 

Tested with Travis and Appveyor.

v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
v3: use check_functions in Scons (Eric)

Cc: Rob Herring 
Cc: Alexander von Gluck IV 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11 changes")
Reviewed-by: Eric Engestrom  (v2)
Reviewed-by: Dylan Baker  (v2)
Reviewed-by: Jon Turney  (v2)
---
 configure.ac| 1 +
 include/c11/threads_posix.h | 2 +-
 meson.build | 2 +-
 scons/gallium.py| 3 +++
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 411c4f6b3e0..a7ae920ab9c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -841,20 +841,21 @@ if test "x$enable_asm" = xyes; then
 AC_MSG_RESULT([no, platform not supported])
 ;;
 esac
 fi
 
 AC_HEADER_MAJOR
 AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
 AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
 AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
 AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
+AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
 
 AC_MSG_CHECKING([whether strtod has locale support])
 AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #define _GNU_SOURCE
 #include 
 #include 
 #ifdef HAVE_XLOCALE_H
 #include 
 #endif
 int main() {
diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
index 7bf6a0f6ef6..45cb6075e6e 100644
--- a/include/c11/threads_posix.h
+++ b/include/c11/threads_posix.h
@@ -375,21 +375,21 @@ tss_get(tss_t key)
 // 7.25.6.4
 static inline int
 tss_set(tss_t key, void *val)
 {
 return (pthread_setspecific(key, val) == 0) ? thrd_success : thrd_error;
 }
 
 
 /* 7.25.7 Time functions */
 // 7.25.6.1
-#if 0
+#ifndef HAVE_TIMESPEC_GET
 static inline int
 timespec_get(struct timespec *ts, int base)
 {
 if (!ts) return 0;
 if (base == TIME_UTC) {
 clock_gettime(CLOCK_REALTIME, ts);
 return base;
 }
 return 0;
 }
diff --git a/meson.build b/meson.build
index 314d15ac461..25a5cd658d1 100644
--- a/meson.build
+++ b/meson.build
@@ -527,21 +527,21 @@ if cc.has_header_symbol('sys/sysmacros.h', 'major')
 elif cc.has_header_symbol('sys/mkdev.h', 'major')
   pre_args += '-DMAJOR_IN_MKDEV'
 endif
 
 foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h']
   if cc.has_header(h)
 pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
   endif
 endforeach
 
-foreach f : ['strtof', 'mkostemp', 'posix_memalign']
+foreach f : ['strtof', 'mkostemp', 'posix_memalign', 'timespec_get']
   if cc.has_function(f)
 pre_args += '-DHAVE_@0@'.format(f.to_upper())
   endif
 endforeach
 
 # strtod locale support
 if cc.links('''
 #define _GNU_SOURCE
 #include 
 #include 
diff --git a/scons/gallium.py b/scons/gallium.py
index 94022df1808..ef3b2ee81ae 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -348,20 +348,23 @@ def generate(env):
 'GLX_DIRECT_RENDERING',
 'GLX_INDIRECT_RENDERING',
 ]
 
 if check_header(env, 'xlocale.h'):
 cppdefines += ['HAVE_XLOCALE_H']
 
 if check_functions(env, ['strtod_l', 'strtof_l']):
 cppdefines += ['HAVE_STRTOD_L']
 
+if check_functions(env, ['timespec_get']):
+cppdefines += ['HAVE_TIMESPEC_GET']
+
 if platform == 'windows':
 cppdefines += [
 'WIN32',
 '_WINDOWS',
 #'_UNICODE',
 #'UNICODE',
 # http://msdn.microsoft.com/en-us/library/aa383745.aspx
 ('_WIN32_WINNT', '0x0601'),
 ('WINVER', '0x0601'),
 ]
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH mesa 2/2] egl: drop EGL driver `name`

2017-11-15 Thread Eric Engestrom
On Wednesday, 2017-11-15 16:51:29 +, Kai Wasserbäch wrote:
> I'm still good with this, thanks for reapplying!

To be clear, is that an ack, or an r-b? :P

> 
> Eric Engestrom wrote on 14.11.2017 18:26:
> > This is a revert of Marek's 2cb9ab53dd3ae6850a26 revert.
> > It was needed to revert the previous commit, and didn't have any issue
> > itself.
> > --
> > 
> > The "DRI2" name was reported as confusing when printing EGL infos (one
> > user reported thinking DRI3 was not working on his X server), and the
> > only alternative is Haiku, which can only be used on a Haiku machine.
> > 
> > The name therefore doesn't add any information that the user wouldn't
> > know already, so let's just drop it.
> > 
> > Cc: Kai Wasserbäch 
> > Suggested-by: Emil Velikov 
> > Related-to: b174a1ae720cb404738c ("egl: Simplify the "driver" interface")
> > Signed-off-by: Eric Engestrom 
> > ---
> >  src/egl/drivers/dri2/egl_dri2.c | 2 --
> >  src/egl/drivers/haiku/egl_haiku.cpp | 2 --
> >  src/egl/main/eglapi.c   | 3 +--
> >  src/egl/main/egldriver.c| 2 --
> >  src/egl/main/egldriver.h| 2 --
> >  5 files changed, 1 insertion(+), 10 deletions(-)
> > 
> > diff --git a/src/egl/drivers/dri2/egl_dri2.c 
> > b/src/egl/drivers/dri2/egl_dri2.c
> > index 7c63920c54624e0e674e..3dce5f82320b2465037a 100644
> > --- a/src/egl/drivers/dri2/egl_dri2.c
> > +++ b/src/egl/drivers/dri2/egl_dri2.c
> > @@ -3269,6 +3269,4 @@ _eglInitDriver(_EGLDriver *dri2_drv)
> > dri2_drv->API.GLInteropQueryDeviceInfo = dri2_interop_query_device_info;
> > dri2_drv->API.GLInteropExportObject = dri2_interop_export_object;
> > dri2_drv->API.DupNativeFenceFDANDROID = dri2_dup_native_fence_fd;
> > -
> > -   dri2_drv->Name = "DRI2";
> >  }
> > diff --git a/src/egl/drivers/haiku/egl_haiku.cpp 
> > b/src/egl/drivers/haiku/egl_haiku.cpp
> > index 590e43f00fb96b051fb4..0b56653395a94ac1f303 100644
> > --- a/src/egl/drivers/haiku/egl_haiku.cpp
> > +++ b/src/egl/drivers/haiku/egl_haiku.cpp
> > @@ -325,7 +325,5 @@ _eglInitDriver(_EGLDriver *driver)
> >  
> > driver->API.SwapBuffers = haiku_swap_buffers;
> >  
> > -   driver->Name = "Haiku";
> > -
> > TRACE("API Calls defined\n");
> >  }
> > diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> > index c1bf5bbfe19b3172429e..306db209cd94748f048f 100644
> > --- a/src/egl/main/eglapi.c
> > +++ b/src/egl/main/eglapi.c
> > @@ -619,8 +619,7 @@ eglInitialize(EGLDisplay dpy, EGLint *major, EGLint 
> > *minor)
> >_eglCreateExtensionsString(disp);
> >_eglCreateAPIsString(disp);
> >snprintf(disp->VersionString, sizeof(disp->VersionString),
> > -   "%d.%d (%s)", disp->Version / 10, disp->Version % 10,
> > -   disp->Driver->Name);
> > +   "%d.%d", disp->Version / 10, disp->Version % 10);
> > }
> >  
> > /* Update applications version of major and minor if not NULL */
> > diff --git a/src/egl/main/egldriver.c b/src/egl/main/egldriver.c
> > index 71bfca21ed8c6a666c14..f1973bde274ec768c4cf 100644
> > --- a/src/egl/main/egldriver.c
> > +++ b/src/egl/main/egldriver.c
> > @@ -99,8 +99,6 @@ _eglMatchDriver(_EGLDisplay *dpy)
> > }
> >  
> > if (best_drv) {
> > -  _eglLog(_EGL_DEBUG, "the best driver is %s",
> > -best_drv->Name);
> >dpy->Driver = best_drv;
> >dpy->Initialized = EGL_TRUE;
> > }
> > diff --git a/src/egl/main/egldriver.h b/src/egl/main/egldriver.h
> > index ba12a060cab7f7c6c223..5695fc06ffb03102cc64 100644
> > --- a/src/egl/main/egldriver.h
> > +++ b/src/egl/main/egldriver.h
> > @@ -75,8 +75,6 @@ extern "C" {
> >   */
> >  struct _egl_driver
> >  {
> > -   const char *Name;  /**< name of this driver */
> > -
> > _EGLAPI API;  /**< EGL API dispatch table */
> >  };
> >  
> > 
> 
> -- 
> 
> Kai Wasserbäch (Kai Wasserbaech)
> 
> E-Mail: k...@dev.carbon-project.org
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/3] RFC: vulkan/wsi: Rework the way prime support works

2017-11-15 Thread Dave Airlie
On 15 November 2017 at 04:40, Jason Ekstrand  wrote:
> This commit significantly reworks the way prime support works and lets
> us pull it even further into radv.  The old mechanism required the
> specific WSI layer to be aware of the linear shadow copy that has to be
> done in order for prime to work.  In the new paradigm, we better define
> what bits of wsi_image go to the client and what bits go off to the
> window system.  It's then the job of the driver to allocate two separate
> images and stash whatever intermediates it needs in driver_private.
> There are a few advantages to this method:
>
>  1) It separates supporting prime from the driver decision as to whether
> it's better to render directly into the window-system-compatible
> image or if it's better to blit.
>
>  2) Because of this separation, it's now possible for a driver to use a
> different scheme for WSI image presentation where it hooks the
> vkCmdPipelineBarrier that transitions the image to
> VK_IMAGE_LAYOUT_PRESENT_SRC_KHR and does the blit there.
>
>  3) It lets us pull more of the details into radv and, in my opinion,
> actually makes the radv code more straightforward.

For the record, PRIME is not radv specific, stop trying to make it so,
anv should support display to other GPUs.

I've tested these patches work and I'm only acking them because nobody
seems to be listening to my objections.

Unhappily-acked-by: Dave Airlie 
Tested-by: Dave Airlie 

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radv/wsi: don't use a helper for blit, just call copy image.

2017-11-15 Thread Dave Airlie
From: Dave Airlie 

We ignore layout currently, not sure what would be correct to pass.

(this is based on Jason's last wsi rfc)

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_meta.h  |  4 
 src/amd/vulkan/radv_meta_copy.c | 20 
 src/amd/vulkan/radv_wsi.c   | 19 ---
 3 files changed, 16 insertions(+), 27 deletions(-)

diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
index d10ec99..0974df0 100644
--- a/src/amd/vulkan/radv_meta.h
+++ b/src/amd/vulkan/radv_meta.h
@@ -187,10 +187,6 @@ void radv_meta_resolve_fragment_image(struct 
radv_cmd_buffer *cmd_buffer,
  uint32_t region_count,
  const VkImageResolve *regions);
 
-void radv_blit_to_prime_linear(struct radv_cmd_buffer *cmd_buffer,
-  struct radv_image *image,
-  struct radv_image *linear_image);
-
 /* common nir builder helpers */
 #include "nir/nir_builder.h"
 
diff --git a/src/amd/vulkan/radv_meta_copy.c b/src/amd/vulkan/radv_meta_copy.c
index a42b15a..c3fe10e 100644
--- a/src/amd/vulkan/radv_meta_copy.c
+++ b/src/amd/vulkan/radv_meta_copy.c
@@ -432,23 +432,3 @@ void radv_CmdCopyImage(
meta_copy_image(cmd_buffer, src_image, dest_image,
regionCount, pRegions);
 }
-
-void radv_blit_to_prime_linear(struct radv_cmd_buffer *cmd_buffer,
-  struct radv_image *image,
-  struct radv_image *linear_image)
-{
-   struct VkImageCopy image_copy = { 0 };
-
-   image_copy.srcSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
-   image_copy.srcSubresource.layerCount = 1;
-
-   image_copy.dstSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
-   image_copy.dstSubresource.layerCount = 1;
-
-   image_copy.extent.width = image->info.width;
-   image_copy.extent.height = image->info.height;
-   image_copy.extent.depth = 1;
-
-   meta_copy_image(cmd_buffer, image, linear_image,
-   1, _copy);
-}
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 0145da6..7515284 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -233,6 +233,7 @@ radv_wsi_create_blit_cmd_buffer(VkDevice device_h,
uint32_t queue_family_index,
VkCommandPool *cmd_pool_p,
VkCommandBuffer *cmd_buffer_p,
+   const VkSwapchainCreateInfoKHR *pCreateInfo,
const VkAllocationCallbacks* pAllocator)
 {
VkResult result = VK_SUCCESS;
@@ -272,9 +273,20 @@ radv_wsi_create_blit_cmd_buffer(VkDevice device_h,
 
radv_BeginCommandBuffer(cmd_buffer_h, _info);
 
-   radv_blit_to_prime_linear(radv_cmd_buffer_from_handle(cmd_buffer_h),
- radv_image_from_handle(client_image_h),
- radv_image_from_handle(wsi_image_h));
+   struct VkImageCopy image_copy = { 0 };
+
+   image_copy.srcSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
+   image_copy.srcSubresource.layerCount = 1;
+
+   image_copy.dstSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
+   image_copy.dstSubresource.layerCount = 1;
+
+   image_copy.extent.width = pCreateInfo->imageExtent.width;
+   image_copy.extent.height = pCreateInfo->imageExtent.height;
+   image_copy.extent.depth = 1;
+
+   radv_CmdCopyImage(cmd_buffer_h, client_image_h, 0, wsi_image_h, 0,
+ 1, _copy);
 
radv_EndCommandBuffer(cmd_buffer_h);
 
@@ -370,6 +382,7 @@ radv_wsi_image_create(VkDevice device_h,
 q,
 
>blit_cmd_pools[q],
 
>blit_cmd_buffers[q],
+pCreateInfo,
 pAllocator);
if (result != VK_SUCCESS)
goto fail;
-- 
2.9.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

2017-11-15 Thread kallisti5

On 2017-11-15 08:35, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds

Cc: Jon Turney 
Cc: Rob Herring 
Cc: Alexander von Gluck IV 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11 changes")


I don't have the power to approve (I assume), but both look good to me.

Thanks for doing SCons as well.
We have a few incomplete patches floating around to add autotools 
support...

They should be finished someday :-)

 -- Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

2017-11-15 Thread Dylan Baker
This should make scons work correctly on every platform, so:
Reviewed-by: Dylan Baker 

Quoting Nicolai Hähnle (2017-11-15 12:58:12)
> From: Nicolai Hähnle 
> 
> Tested with Travis and Appveyor.
> 
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
> v3: use check_functions in Scons (Eric)
> 
> Cc: Rob Herring 
> Cc: Alexander von Gluck IV 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
> Fixes: f1a364878431 ("threads: update for late C11 changes")
> Reviewed-by: Eric Engestrom  (v2)
> Reviewed-by: Dylan Baker  (v2)
> Reviewed-by: Jon Turney  (v2)
> ---
>  configure.ac| 1 +
>  include/c11/threads_posix.h | 2 +-
>  meson.build | 2 +-
>  scons/gallium.py| 3 +++
>  4 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 411c4f6b3e0..a7ae920ab9c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -841,20 +841,21 @@ if test "x$enable_asm" = xyes; then
>  AC_MSG_RESULT([no, platform not supported])
>  ;;
>  esac
>  fi
>  
>  AC_HEADER_MAJOR
>  AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
>  AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
>  AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
>  AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
> +AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
>  
>  AC_MSG_CHECKING([whether strtod has locale support])
>  AC_LINK_IFELSE([AC_LANG_SOURCE([[
>  #define _GNU_SOURCE
>  #include 
>  #include 
>  #ifdef HAVE_XLOCALE_H
>  #include 
>  #endif
>  int main() {
> diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
> index 7bf6a0f6ef6..45cb6075e6e 100644
> --- a/include/c11/threads_posix.h
> +++ b/include/c11/threads_posix.h
> @@ -375,21 +375,21 @@ tss_get(tss_t key)
>  // 7.25.6.4
>  static inline int
>  tss_set(tss_t key, void *val)
>  {
>  return (pthread_setspecific(key, val) == 0) ? thrd_success : thrd_error;
>  }
>  
>  
>  /* 7.25.7 Time functions */
>  // 7.25.6.1
> -#if 0
> +#ifndef HAVE_TIMESPEC_GET
>  static inline int
>  timespec_get(struct timespec *ts, int base)
>  {
>  if (!ts) return 0;
>  if (base == TIME_UTC) {
>  clock_gettime(CLOCK_REALTIME, ts);
>  return base;
>  }
>  return 0;
>  }
> diff --git a/meson.build b/meson.build
> index 314d15ac461..25a5cd658d1 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -527,21 +527,21 @@ if cc.has_header_symbol('sys/sysmacros.h', 'major')
>  elif cc.has_header_symbol('sys/mkdev.h', 'major')
>pre_args += '-DMAJOR_IN_MKDEV'
>  endif
>  
>  foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h']
>if cc.has_header(h)
>  pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
>endif
>  endforeach
>  
> -foreach f : ['strtof', 'mkostemp', 'posix_memalign']
> +foreach f : ['strtof', 'mkostemp', 'posix_memalign', 'timespec_get']
>if cc.has_function(f)
>  pre_args += '-DHAVE_@0@'.format(f.to_upper())
>endif
>  endforeach
>  
>  # strtod locale support
>  if cc.links('''
>  #define _GNU_SOURCE
>  #include 
>  #include 
> diff --git a/scons/gallium.py b/scons/gallium.py
> index 94022df1808..ef3b2ee81ae 100755
> --- a/scons/gallium.py
> +++ b/scons/gallium.py
> @@ -348,20 +348,23 @@ def generate(env):
>  'GLX_DIRECT_RENDERING',
>  'GLX_INDIRECT_RENDERING',
>  ]
>  
>  if check_header(env, 'xlocale.h'):
>  cppdefines += ['HAVE_XLOCALE_H']
>  
>  if check_functions(env, ['strtod_l', 'strtof_l']):
>  cppdefines += ['HAVE_STRTOD_L']
>  
> +if check_functions(env, ['timespec_get']):
> +cppdefines += ['HAVE_TIMESPEC_GET']
> +
>  if platform == 'windows':
>  cppdefines += [
>  'WIN32',
>  '_WINDOWS',
>  #'_UNICODE',
>  #'UNICODE',
>  # http://msdn.microsoft.com/en-us/library/aa383745.aspx
>  ('_WIN32_WINNT', '0x0601'),
>  ('WINVER', '0x0601'),
>  ]
> -- 
> 2.11.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 100151] Front buffer drawing mode shows black window with gallium software rasterizers

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100151

--- Comment #12 from Pradeep Yadav  ---
As I mentioned while filing this defect that Mesa's classic software rasterizer
has no such black window issue. So we have potential temporary solution for our
customers who are using older Linux versions.

So for a CentOS version, like 6.x, I downloaded Mesa 13.0.5 sources and built
swrast_dri.so (the classic software rasterizer) and it works (Need to set
LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH to swrast_dri.so path).

But our customers/users cannot build Mesa on their systems. They don't have the
expertise and sometimes their IT support are also not willing to do so.

We cannot provide a pre-built swrast_dri.so to them as it might be incompatible
with the other libraries (dependencies) on customer's system. For example a
customer may be facing this issue on their CentOS 7.x system and if we provide
Mesa 13.0.5 swrast_dri.so, then it might not work.

My questions:

- Is there a way (probably like an environment variable) to activate Mesa's
classic software rasterizer?

- Do we have a documentation of which Mesa version is compatible with which
Linux kernel version?

- On installing CentOS version V, a Mesa version M is installed. How and who
decides Mesa version M corresponding to CentOS version V?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] vulkan/wsi: use function ptr definitions from the spec.

2017-11-15 Thread Dave Airlie
From: Dave Airlie 

This just seems cleaner, and we may expand this in future.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_wsi.c   | 3 ++-
 src/intel/vulkan/anv_wsi.c  | 3 ++-
 src/vulkan/wsi/wsi_common.h | 4 +---
 src/vulkan/wsi/wsi_common_wayland.c | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 7a9064b..0145da6 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -29,8 +29,9 @@
 #include "vk_util.h"
 #include "util/macros.h"
 
+#define WSI_CB(x) .x = radv_##x
 MAYBE_UNUSED static const struct wsi_callbacks wsi_cbs = {
-   .get_phys_device_format_properties = radv_GetPhysicalDeviceFormatProperties,
+   WSI_CB(GetPhysicalDeviceFormatProperties),
 };
 
 VkResult
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 363f70f..a8b01dc 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -27,8 +27,9 @@
 #include "vk_util.h"
 
 #ifdef VK_USE_PLATFORM_WAYLAND_KHR
+#define WSI_CB(x) .x = anv_##x
 static const struct wsi_callbacks wsi_cbs = {
-   .get_phys_device_format_properties = anv_GetPhysicalDeviceFormatProperties,
+   WSI_CB(GetPhysicalDeviceFormatProperties),
 };
 #endif
 
diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
index 3fa2631..7171de3 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -122,9 +122,7 @@ struct wsi_device {
 };
 
 struct wsi_callbacks {
-   void (*get_phys_device_format_properties)(VkPhysicalDevice physicalDevice,
- VkFormat format,
- VkFormatProperties 
*pFormatProperties);
+   PFN_vkGetPhysicalDeviceFormatProperties GetPhysicalDeviceFormatProperties;
 };
 
 #define WSI_DEFINE_NONDISP_HANDLE_CASTS(__wsi_type, __VkType)  \
diff --git a/src/vulkan/wsi/wsi_common_wayland.c 
b/src/vulkan/wsi/wsi_common_wayland.c
index 60e72fb..4df5bb8 100644
--- a/src/vulkan/wsi/wsi_common_wayland.c
+++ b/src/vulkan/wsi/wsi_common_wayland.c
@@ -84,7 +84,7 @@ wsi_wl_display_add_vk_format(struct wsi_wl_display *display, 
VkFormat format)
/* Don't add formats that aren't renderable. */
VkFormatProperties props;
 
-   
display->wsi_wl->cbs->get_phys_device_format_properties(display->wsi_wl->physical_device,
+   
display->wsi_wl->cbs->GetPhysicalDeviceFormatProperties(display->wsi_wl->physical_device,
format, );
if (!(props.optimalTilingFeatures & VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT))
   return;
-- 
2.9.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radv: get rid of another api bypass in the wsi code.

2017-11-15 Thread Dave Airlie
From: Dave Airlie 

This just uses the vulkan api to get the fd from the memory.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_wsi.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index e4f7fa7..3cf0cbd 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -277,7 +277,7 @@ radv_wsi_image_create(VkDevice device_h,
VkImage client_image_h = VK_NULL_HANDLE;
struct radeon_surf *surface;
struct radv_image *image;
-   struct radv_device_memory *memory;
+   VkDeviceMemory memory_h;
int fd;
RADV_FROM_HANDLE(radv_device, device, device_h);
 
@@ -297,7 +297,7 @@ radv_wsi_image_create(VkDevice device_h,
if (result != VK_SUCCESS)
goto fail;
image = radv_image_from_handle(client_image_h);
-   memory = radv_device_memory_from_handle(private->client_memory_h);
+   memory_h = private->client_memory_h;
 
if (different_gpu) {
result = radv_wsi_image_create_common(device_h,
@@ -309,7 +309,7 @@ radv_wsi_image_create(VkDevice device_h,
if (result != VK_SUCCESS)
goto fail;
image = radv_image_from_handle(private->wsi_image_h);
-   memory = radv_device_memory_from_handle(private->wsi_memory_h);
+   memory_h = private->wsi_memory_h;
 
for (uint32_t q = 0; q < RADV_MAX_QUEUE_FAMILIES; q++) {
result = wsi_create_blit_cmd_buffer(_cbs, device_h,
@@ -325,10 +325,12 @@ radv_wsi_image_create(VkDevice device_h,
}
}
 
-   if (!radv_get_memory_fd(device, memory, )) {
-   result = vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
+   VkMemoryGetFdInfoKHR getfdinfo;
+   getfdinfo.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR;
+   getfdinfo.memory = memory_h;
+   result = radv_GetMemoryFdKHR(device_h, , );
+   if (result != VK_SUCCESS)
goto fail;
-   }
 
surface = >surface;
 
-- 
2.9.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 2/5] etnaviv: Check that resource has a valid TS in etna_resource_needs_flush

2017-11-15 Thread Christian Gmeiner
2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> Resources only need a resolve-to-itself if their TS is valid for any
> level, not just if it happens to be allocated.
>
> Signed-off-by: Wladimir J. van der Laan 

Reviewed-by: Christian Gmeiner 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 13 +
>  src/gallium/drivers/etnaviv/etnaviv_resource.h |  6 +-
>  2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 0a82807..1fb73c4 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -629,6 +629,19 @@ etna_resource_used(struct etna_context *ctx, struct 
> pipe_resource *prsc,
> rsc->pending_ctx = ctx;
>  }
>
> +bool
> +etna_resource_has_valid_ts(struct etna_resource *rsc)
> +{
> +   if (!rsc->ts_bo)
> +  return false;
> +
> +   for (int level = 0; level <= rsc->base.last_level; level++)
> +  if (rsc->levels[level].ts_valid)
> + return true;
> +
> +   return false;
> +}
> +
>  void
>  etna_resource_screen_init(struct pipe_screen *pscreen)
>  {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 0b135e2..11ccf8f 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -103,11 +103,15 @@ etna_resource_older(struct etna_resource *a, struct 
> etna_resource *b)
> return (int)(a->seqno - b->seqno) < 0;
>  }
>
> +/* returns TRUE if a resource has a TS, and it is valid for at least one 
> level */
> +bool
> +etna_resource_has_valid_ts(struct etna_resource *res);
> +
>  /* returns TRUE if the resource needs a resolve to itself */
>  static inline bool
>  etna_resource_needs_flush(struct etna_resource *res)
>  {
> -   return res->ts_bo && ((int)(res->seqno - res->flush_seqno) > 0);
> +   return etna_resource_has_valid_ts(res) && ((int)(res->seqno - 
> res->flush_seqno) > 0);
>  }
>
>  /* is the resource only used on the sampler? */
> --
> 2.7.4
>



-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] i965: Listen to BRW_NEW_*_PROGRAM in L3 state atom.

2017-11-15 Thread Kenneth Graunke
This looks at prog->*.  You don't get to do that unless you listen to
BRW_NEW_*_PROGRAM, which is a superset of the cases where
BRW_NEW_*_PROG_DATA is flagged.
---
 src/mesa/drivers/dri/i965/gen7_l3_state.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c 
b/src/mesa/drivers/dri/i965/gen7_l3_state.c
index 8c8f4169e7e..7044d5a8984 100644
--- a/src/mesa/drivers/dri/i965/gen7_l3_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_l3_state.c
@@ -255,11 +255,16 @@ const struct brw_tracked_state gen7_l3_state = {
   .mesa = 0,
   .brw = BRW_NEW_BATCH |
  BRW_NEW_BLORP |
+ BRW_NEW_COMPUTE_PROGRAM |
  BRW_NEW_CS_PROG_DATA |
+ BRW_NEW_FRAGMENT_PROGRAM |
  BRW_NEW_FS_PROG_DATA |
+ BRW_NEW_GEOMETRY_PROGRAM |
  BRW_NEW_GS_PROG_DATA |
+ BRW_NEW_TESS_PROGRAMS |
  BRW_NEW_TCS_PROG_DATA |
  BRW_NEW_TES_PROG_DATA |
+ BRW_NEW_VERTEX_PROGRAM |
  BRW_NEW_VS_PROG_DATA,
},
.emit = emit_l3_state
-- 
2.15.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 3/5] etnaviv: Add TS_SAMPLER formats to etnaviv_format

2017-11-15 Thread Christian Gmeiner
2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> Sampler TS introduces yet another format enumeration for
> renderable+textureable formats. Introduce it into the etnaviv_format
> table as another column.
>
> Signed-off-by: Wladimir J. van der Laan 

Reviewed-by: Christian Gmeiner 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_format.c | 162 
> +++
>  src/gallium/drivers/etnaviv/etnaviv_format.h |   3 +
>  2 files changed, 91 insertions(+), 74 deletions(-)
>
> I changed this to add a new column to the table for the TS format (for all
> texturable formats) instead of a trick based on RS format and name as used
> before, as that didn't cover depth formats correctly.
>
> (did not add Christian Gmeiner's reviewed-by as the patch changed 100%)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.c 
> b/src/gallium/drivers/etnaviv/etnaviv_format.c
> index 3dd212f..7943c81 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_format.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_format.c
> @@ -40,6 +40,7 @@ struct etna_format {
> unsigned vtx;
> unsigned tex;
> unsigned rs;
> +   unsigned ts;
> boolean present;
> const unsigned char tex_swiz[4];
>  };
> @@ -53,6 +54,8 @@ struct etna_format {
>  #define RS_FORMAT_X8B8G8R8(RS_FORMAT_X8R8G8B8 | RS_FORMAT_RB_SWAP)
>  #define RS_FORMAT_A8B8G8R8(RS_FORMAT_A8R8G8B8 | RS_FORMAT_RB_SWAP)
>
> +#define TS_SAMPLER_FORMAT_NONE  ETNA_NO_MATCH
> +
>  #define SWIZ(x,y,z,w) {\
> PIPE_SWIZZLE_##x,   \
> PIPE_SWIZZLE_##y,   \
> @@ -61,21 +64,23 @@ struct etna_format {
>  }
>
>  /* vertex + texture */
> -#define VT(pipe, vtxfmt, texfmt, texswiz, rsfmt)  \
> +#define VT(pipe, vtxfmt, texfmt, texswiz, rsfmt, tsfmt)  \
> [PIPE_FORMAT_##pipe] = {   \
>.vtx = FE_DATA_TYPE_##vtxfmt, \
>.tex = TEXTURE_FORMAT_##texfmt, \
>.rs = RS_FORMAT_##rsfmt,\
> +  .ts = TS_SAMPLER_FORMAT_##tsfmt,\
>.present = 1,   \
>.tex_swiz = texswiz,\
> }
>
>  /* texture-only */
> -#define _T(pipe, fmt, swiz, rsfmt) \
> +#define _T(pipe, fmt, swiz, rsfmt, tsfmt) \
> [PIPE_FORMAT_##pipe] = {\
>.vtx = ETNA_NO_MATCH,\
>.tex = TEXTURE_FORMAT_##fmt, \
>.rs = RS_FORMAT_##rsfmt, \
> +  .ts = TS_SAMPLER_FORMAT_##tsfmt, \
>.present = 1,\
>.tex_swiz = swiz,\
> }
> @@ -91,16 +96,16 @@ struct etna_format {
>
>  static struct etna_format formats[PIPE_FORMAT_COUNT] = {
> /* 8-bit */
> -   VT(R8_UNORM,   UNSIGNED_BYTE, L8, SWIZ(X, 0, 0, 1), NONE),
> +   VT(R8_UNORM,   UNSIGNED_BYTE, L8, SWIZ(X, 0, 0, 1), NONE, NONE),
> V_(R8_SNORM,   BYTE,  NONE),
> V_(R8_UINT,UNSIGNED_BYTE, NONE),
> V_(R8_SINT,BYTE,  NONE),
> V_(R8_USCALED, UNSIGNED_BYTE, NONE),
> V_(R8_SSCALED, BYTE,  NONE),
>
> -   _T(A8_UNORM, A8, SWIZ(X, Y, Z, W), NONE),
> -   _T(L8_UNORM, L8, SWIZ(X, Y, Z, W), NONE),
> -   _T(I8_UNORM, I8, SWIZ(X, Y, Z, W), NONE),
> +   _T(A8_UNORM, A8, SWIZ(X, Y, Z, W), NONE, NONE),
> +   _T(L8_UNORM, L8, SWIZ(X, Y, Z, W), NONE, NONE),
> +   _T(I8_UNORM, I8, SWIZ(X, Y, Z, W), NONE, NONE),
>
> /* 16-bit */
> V_(R16_UNORM,   UNSIGNED_SHORT, NONE),
> @@ -111,17 +116,17 @@ static struct etna_format formats[PIPE_FORMAT_COUNT] = {
> V_(R16_SSCALED, SHORT,  NONE),
> V_(R16_FLOAT,   HALF_FLOAT, NONE),
>
> -   _T(B4G4R4A4_UNORM, A4R4G4B4, SWIZ(X, Y, Z, W), A4R4G4B4),
> -   _T(B4G4R4X4_UNORM, X4R4G4B4, SWIZ(X, Y, Z, W), X4R4G4B4),
> +   _T(B4G4R4A4_UNORM, A4R4G4B4, SWIZ(X, Y, Z, W), A4R4G4B4, A4R4G4B4),
> +   _T(B4G4R4X4_UNORM, X4R4G4B4, SWIZ(X, Y, Z, W), X4R4G4B4, A4R4G4B4),
>
> -   _T(L8A8_UNORM, A8L8, SWIZ(X, Y, Z, W), NONE),
> +   _T(L8A8_UNORM, A8L8, SWIZ(X, Y, Z, W), NONE, NONE),
>
> -   _T(Z16_UNORM,  D16,  SWIZ(X, Y, Z, W), A4R4G4B4),
> -   _T(B5G6R5_UNORM,   R5G6B5,   SWIZ(X, Y, Z, W), R5G6B5),
> -   _T(B5G5R5A1_UNORM, A1R5G5B5, SWIZ(X, Y, Z, W), A1R5G5B5),
> -   _T(B5G5R5X1_UNORM, X1R5G5B5, SWIZ(X, Y, Z, W), X1R5G5B5),
> +   _T(Z16_UNORM,  D16,  SWIZ(X, Y, Z, W), A4R4G4B4, D16),
> +   _T(B5G6R5_UNORM,   R5G6B5,   SWIZ(X, Y, Z, W), R5G6B5, R5G6B5),
> +   _T(B5G5R5A1_UNORM, A1R5G5B5, SWIZ(X, Y, Z, W), A1R5G5B5, A1R5G5B5),
> +   _T(B5G5R5X1_UNORM, X1R5G5B5, SWIZ(X, Y, Z, W), X1R5G5B5, A1R5G5B5),
>
> -   VT(R8G8_UNORM,   UNSIGNED_BYTE,  EXT_G8R8 | EXT_FORMAT, SWIZ(X, Y, 0, 1), 
> NONE),
> +   VT(R8G8_UNORM,   UNSIGNED_BYTE,  EXT_G8R8 | EXT_FORMAT, SWIZ(X, Y, 0, 1), 
> NONE, NONE),
> V_(R8G8_SNORM,   BYTE,   NONE),
> V_(R8G8_UINT,UNSIGNED_BYTE,  NONE),
> V_(R8G8_SINT,BYTE,   NONE),
> @@ -156,26 +161,26 @@ static struct etna_format 

Re: [Mesa-dev] [PATCH v2 4/5] etnaviv: Flush TS cache before changing TS configuration

2017-11-15 Thread Christian Gmeiner
2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> This is to make sure that the TS is properly flushed to memory before
> rendering to a new surface starts.
>
> Signed-off-by: Wladimir J. van der Laan 

Reviewed-by: Christian Gmeiner 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_emit.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> index d313af6..b6b06e3 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> @@ -322,6 +322,11 @@ etna_emit_state(struct etna_context *ctx)
>etna_stall(stream, SYNC_RECIPIENT_RA, SYNC_RECIPIENT_PE);
> }
>
> +   /* Flush TS cache before changing TS configuration. */
> +   if (unlikely(dirty & ETNA_DIRTY_TS)) {
> +  etna_set_state(stream, VIVS_TS_FLUSH_CACHE, VIVS_TS_FLUSH_CACHE_FLUSH);
> +   }
> +
> /* If MULTI_SAMPLE_CONFIG.MSAA_SAMPLES changed, clobber affected shader
>  * state to make sure it is always rewritten. */
> if (unlikely(dirty & (ETNA_DIRTY_FRAMEBUFFER))) {
> --
> 2.7.4
>



-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] mesa/teximage: add TEXTURE_CUBE_MAP_ARRAY target for CompressedTexImage3D

2017-11-15 Thread Ilia Mirkin
On Wed, Nov 15, 2017 at 5:49 PM, Nanley Chery  wrote:
> On Wed, Nov 15, 2017 at 12:08:58PM -0500, Ilia Mirkin wrote:
>> On Wed, Nov 15, 2017 at 11:54 AM, Juan A. Suarez Romero
>>  wrote:
>> > From section 8.7, page 179 of OpenGL ES 3.2 spec:
>> >
>> >   An INVALID_OPERATION error is generated by CompressedTexImage3D
>> >   if internalformat is one of the the formats in table 8.17 and target
>> >   is not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
>> >
>> >   An INVALID_OPERATION error is generated by CompressedTexImage3D if
>> >   internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube Map Array”
>> >   column of table 8.17 is not checked, or if internalformat is
>> >   TEXTURE_3D and the “3D Tex.” column of table 8.17 is not checked.
>> >
>> > So far it was only considering TEXTURE_2D_ARRAY as valid target. But as
>> > "Cube Map Array" column is checked for all the cases, in practice we can
>> > consider also TEXTURE_CUBE_MAP_ARRAY.
>> >
>> > This fixes KHR-GLES32.core.texture_cube_map_array.etc2_texture
>> > ---
>> >  src/mesa/main/teximage.c | 25 +
>> >  1 file changed, 17 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
>> > index 4ec6148bf42..174731d0d8a 100644
>> > --- a/src/mesa/main/teximage.c
>> > +++ b/src/mesa/main/teximage.c
>> > @@ -1403,17 +1403,26 @@ _mesa_target_can_be_compressed(const struct 
>> > gl_context *ctx, GLenum target,
>> > * have already been handled by normal ETC2/EAC behavior.
>> > */
>> >
>> > -  /* From section 3.8.6, page 146 of OpenGL ES 3.0 spec:
>> > +  /* From section 8.7, page 179 of OpenGL ES 3.2 spec:
>> > *
>> > -   *"The ETC2/EAC texture compression algorithm supports only
>> > -   * two-dimensional images. If internalformat is an ETC2/EAC 
>> > format,
>> > -   * glCompressedTexImage3D will generate an INVALID_OPERATION 
>> > error if
>> > -   * target is not TEXTURE_2D_ARRAY."
>> > +   *  An INVALID_OPERATION error is generated by 
>> > CompressedTexImage3D
>> > +   *  if internalformat is one of the the formats in table 8.17 
>> > and target is
>> > +   *  not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
>> > *
>> > -   * This should also be applicable for glTexStorage3D(). Other 
>> > available
>> > -   * targets for these functions are: TEXTURE_3D and 
>> > TEXTURE_CUBE_MAP_ARRAY.
>> > +   *  An INVALID_OPERATION error is generated by 
>> > CompressedTexImage3D
>> > +   *  if internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube 
>> > Map
>> > +   *  Array” column of table 8.17 is not checked, or if 
>> > internalformat
>> > +   *  is TEXTURE_- 3D and the “3D Tex.” column of table 8.17 is 
>> > not
>> > +   *  checked.
>> > +   *
>> > +   * The instances of  above should say .
>> > +   *
>> > +   * This should also be applicable for glTexStorage3D().
>> > +   *
>> > +   * Such table 8.17 has checked "Cube Map Array" column for all the
>> > +   * cases. So in practice, TEXTURE_CUBE_MAP_ARRAY is now valid.
>> > */
>
> This deletes the comment describing the old OpenGL ES 3.0 behavior.
>
>> > -  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx))
>> > +  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx) && 
>> > !_mesa_is_gles32(ctx))
>
> Some of these lines look longer than 80 chars.
>
>>
>> Perhaps this should be
>>
>> !_mesa_has_OES_texture_cube_map_array(ctx)?
>>
>
> I think you're right. It looks like OES_texture_cube_map_array was folded
> into ES 3.2. I haven't done the comparison myself to confirm this
> however.
>
>> It's unclear from that spec though... perhaps ES 3.2 goes further and
>> is required to be supported.
>>
>
> If the OpenGL ES Wikipedia page is reliable, we should probably be checking 
> for
> this extension before exposing ES 3.2.

https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/version.c#n547

Anyways, the question is whether OES_texture_cube_map_array is
sufficient, or if ES 3.2 is needed for this change to apply. Not sure.
I didn't dig in deeply enough.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

2017-11-15 Thread Eric Engestrom
On Wednesday, 2017-11-15 20:59:18 +, Nicolai Hähnle wrote:
> From: Nicolai Hähnle 
> 
> Tested with Travis and Appveyor.
> 
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
> v3: use check_functions in Scons (Eric)
> 
> Cc: Rob Herring 
> Cc: Alexander von Gluck IV 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
> Fixes: f1a364878431 ("threads: update for late C11 changes")
> Reviewed-by: Eric Engestrom  (v2)

You can update that r-b to apply to this revision too :)

> Reviewed-by: Dylan Baker  (v2)
> Reviewed-by: Jon Turney  (v2)
> ---
>  configure.ac| 1 +
>  include/c11/threads_posix.h | 2 +-
>  meson.build | 2 +-
>  scons/gallium.py| 3 +++
>  4 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 411c4f6b3e0..a7ae920ab9c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -841,20 +841,21 @@ if test "x$enable_asm" = xyes; then
>  AC_MSG_RESULT([no, platform not supported])
>  ;;
>  esac
>  fi
>  
>  AC_HEADER_MAJOR
>  AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
>  AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
>  AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
>  AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
> +AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
>  
>  AC_MSG_CHECKING([whether strtod has locale support])
>  AC_LINK_IFELSE([AC_LANG_SOURCE([[
>  #define _GNU_SOURCE
>  #include 
>  #include 
>  #ifdef HAVE_XLOCALE_H
>  #include 
>  #endif
>  int main() {
> diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
> index 7bf6a0f6ef6..45cb6075e6e 100644
> --- a/include/c11/threads_posix.h
> +++ b/include/c11/threads_posix.h
> @@ -375,21 +375,21 @@ tss_get(tss_t key)
>  // 7.25.6.4
>  static inline int
>  tss_set(tss_t key, void *val)
>  {
>  return (pthread_setspecific(key, val) == 0) ? thrd_success : thrd_error;
>  }
>  
>  
>  /* 7.25.7 Time functions */
>  // 7.25.6.1
> -#if 0
> +#ifndef HAVE_TIMESPEC_GET
>  static inline int
>  timespec_get(struct timespec *ts, int base)
>  {
>  if (!ts) return 0;
>  if (base == TIME_UTC) {
>  clock_gettime(CLOCK_REALTIME, ts);
>  return base;
>  }
>  return 0;
>  }
> diff --git a/meson.build b/meson.build
> index 314d15ac461..25a5cd658d1 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -527,21 +527,21 @@ if cc.has_header_symbol('sys/sysmacros.h', 'major')
>  elif cc.has_header_symbol('sys/mkdev.h', 'major')
>pre_args += '-DMAJOR_IN_MKDEV'
>  endif
>  
>  foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h']
>if cc.has_header(h)
>  pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
>endif
>  endforeach
>  
> -foreach f : ['strtof', 'mkostemp', 'posix_memalign']
> +foreach f : ['strtof', 'mkostemp', 'posix_memalign', 'timespec_get']
>if cc.has_function(f)
>  pre_args += '-DHAVE_@0@'.format(f.to_upper())
>endif
>  endforeach
>  
>  # strtod locale support
>  if cc.links('''
>  #define _GNU_SOURCE
>  #include 
>  #include 
> diff --git a/scons/gallium.py b/scons/gallium.py
> index 94022df1808..ef3b2ee81ae 100755
> --- a/scons/gallium.py
> +++ b/scons/gallium.py
> @@ -348,20 +348,23 @@ def generate(env):
>  'GLX_DIRECT_RENDERING',
>  'GLX_INDIRECT_RENDERING',
>  ]
>  
>  if check_header(env, 'xlocale.h'):
>  cppdefines += ['HAVE_XLOCALE_H']
>  
>  if check_functions(env, ['strtod_l', 'strtof_l']):
>  cppdefines += ['HAVE_STRTOD_L']
>  
> +if check_functions(env, ['timespec_get']):
> +cppdefines += ['HAVE_TIMESPEC_GET']
> +
>  if platform == 'windows':
>  cppdefines += [
>  'WIN32',
>  '_WINDOWS',
>  #'_UNICODE',
>  #'UNICODE',
>  # http://msdn.microsoft.com/en-us/library/aa383745.aspx
>  ('_WIN32_WINNT', '0x0601'),
>  ('WINVER', '0x0601'),
>  ]
> -- 
> 2.11.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] mesa/teximage: add TEXTURE_CUBE_MAP_ARRAY target for CompressedTexImage3D

2017-11-15 Thread Nanley Chery
On Wed, Nov 15, 2017 at 12:08:58PM -0500, Ilia Mirkin wrote:
> On Wed, Nov 15, 2017 at 11:54 AM, Juan A. Suarez Romero
>  wrote:
> > From section 8.7, page 179 of OpenGL ES 3.2 spec:
> >
> >   An INVALID_OPERATION error is generated by CompressedTexImage3D
> >   if internalformat is one of the the formats in table 8.17 and target
> >   is not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
> >
> >   An INVALID_OPERATION error is generated by CompressedTexImage3D if
> >   internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube Map Array”
> >   column of table 8.17 is not checked, or if internalformat is
> >   TEXTURE_3D and the “3D Tex.” column of table 8.17 is not checked.
> >
> > So far it was only considering TEXTURE_2D_ARRAY as valid target. But as
> > "Cube Map Array" column is checked for all the cases, in practice we can
> > consider also TEXTURE_CUBE_MAP_ARRAY.
> >
> > This fixes KHR-GLES32.core.texture_cube_map_array.etc2_texture
> > ---
> >  src/mesa/main/teximage.c | 25 +
> >  1 file changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> > index 4ec6148bf42..174731d0d8a 100644
> > --- a/src/mesa/main/teximage.c
> > +++ b/src/mesa/main/teximage.c
> > @@ -1403,17 +1403,26 @@ _mesa_target_can_be_compressed(const struct 
> > gl_context *ctx, GLenum target,
> > * have already been handled by normal ETC2/EAC behavior.
> > */
> >
> > -  /* From section 3.8.6, page 146 of OpenGL ES 3.0 spec:
> > +  /* From section 8.7, page 179 of OpenGL ES 3.2 spec:
> > *
> > -   *"The ETC2/EAC texture compression algorithm supports only
> > -   * two-dimensional images. If internalformat is an ETC2/EAC 
> > format,
> > -   * glCompressedTexImage3D will generate an INVALID_OPERATION 
> > error if
> > -   * target is not TEXTURE_2D_ARRAY."
> > +   *  An INVALID_OPERATION error is generated by 
> > CompressedTexImage3D
> > +   *  if internalformat is one of the the formats in table 8.17 
> > and target is
> > +   *  not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
> > *
> > -   * This should also be applicable for glTexStorage3D(). Other 
> > available
> > -   * targets for these functions are: TEXTURE_3D and 
> > TEXTURE_CUBE_MAP_ARRAY.
> > +   *  An INVALID_OPERATION error is generated by 
> > CompressedTexImage3D
> > +   *  if internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube Map
> > +   *  Array” column of table 8.17 is not checked, or if 
> > internalformat
> > +   *  is TEXTURE_- 3D and the “3D Tex.” column of table 8.17 is not
> > +   *  checked.
> > +   *
> > +   * The instances of  above should say .
> > +   *
> > +   * This should also be applicable for glTexStorage3D().
> > +   *
> > +   * Such table 8.17 has checked "Cube Map Array" column for all the
> > +   * cases. So in practice, TEXTURE_CUBE_MAP_ARRAY is now valid.
> > */

This deletes the comment describing the old OpenGL ES 3.0 behavior.

> > -  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx))
> > +  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx) && 
> > !_mesa_is_gles32(ctx))

Some of these lines look longer than 80 chars.

> 
> Perhaps this should be
> 
> !_mesa_has_OES_texture_cube_map_array(ctx)?
> 

I think you're right. It looks like OES_texture_cube_map_array was folded
into ES 3.2. I haven't done the comparison myself to confirm this
however.

> It's unclear from that spec though... perhaps ES 3.2 goes further and
> is required to be supported.
> 

If the OpenGL ES Wikipedia page is reliable, we should probably be checking for
this extension before exposing ES 3.2.

-Nanley

> >  return write_error(error, GL_INVALID_OPERATION);
> >target_can_be_compresed = _mesa_has_texture_cube_map_array(ctx);
> >break;
> > --
> > 2.13.6
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] Difference between Meson and autotools release builds

2017-11-15 Thread Rogovin, Kevin
Hi,

I do not know if anyone has noticed or if it is deliberate, but the meson 
builds have that assert()'s are active but the autotools release builds have 
that assert() is inactive.

-Kevin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [AppVeyor] mesa master #6164 completed

2017-11-15 Thread AppVeyor


Build mesa 6164 completed



Commit 059d25a06d by Samuel Pitoiset on 11/14/2017 4:27 PM:

radv: add the vertex buffers BO to the list at bind time\n\nThis should reduce the overhead of adding a BO to the current\nlist, especially when the list is huge. Also, when a new pipeline\nis bound, we only need to update the descriptor, the buffer objects\nshould already be in the list.\n\nSigned-off-by: Samuel Pitoiset \nReviewed-by: Bas Nieuwenhuizen 


Configure your notification preferences

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 102122] [softpipe] piglit fdo10370 regression

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102122

Vinson Lee  changed:

   What|Removed |Added

 Blocks||103491


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=103491
[Bug 103491] [TRACKER] Mesa 17.3 release tracker
-- 
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.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 103128] [softpipe] piglit fs-ldexp regression

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103128

Vinson Lee  changed:

   What|Removed |Added

 Blocks||103491


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=103491
[Bug 103491] [TRACKER] Mesa 17.3 release tracker
-- 
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.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] r600: shader CF_OP_VTX also doesn't use the EOP bit.

2017-11-15 Thread Gert Wollny
Am Mittwoch, den 15.11.2017, 11:28 +1000 schrieb Dave Airlie:
> 
> I'll likely apply this as well at some point, that test however hangs
> my cayman with or without my patch (and your patch doesn't do
> anything on cayman).

BTW: valgrind showed that there was some problem in sb in the parser
(branch based on un-unitialized value), and by changing 

r600_shader.c:3121; r600_shader_from_tgsi  

  } else if (ctx.type == PIPE_SHADER_TESS_EVAL) {
ctx.tess_input_info = 0;
ctx.tess_output_info = ctx.bc->ar_reg + 3;
-   ctx.temp_reg = ctx.bc->ar_reg + 4;
+   ctx.temp_reg = ctx.bc->ar_reg + 5;
 } else if (ctx.type == PIPE_SHADER_GEOMETRY) {
ctx.gs_export_gpr_tregs[0] = ctx.bc->ar_reg + 3;
ctx.gs_export_gpr_tregs[1] = ctx.bc->ar_reg + 4;
ctx.gs_export_gpr_tregs[2] = ctx.bc->ar_reg + 5;

the GPU lockup what triggered reliably for me on BARTS.  

Running this with R600_DUMP_SHADERS=1 also crashed, because sb accessed
unallocated memory trying to decode non-existing instructions. 

maybe that helps to locate the problem on cayman. 

Best, 
Gert 






___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] r600: fix cubemap arrays

2017-11-15 Thread Marc Dietrich
Hi Dave,

Am Dienstag, 14. November 2017, 23:28:38 CET schrieb Dave Airlie:
> From: Dave Airlie 
> 
> A lot of cubemap array piglits fail, port the texture type
> picking code from radeonsi which seems to fix most of them.
> 
> For images I will port the rest of the code.
> 
> Fixes:
> getteximage-depth gl_texture_cube_map_array-*
> fbo-generatemipmap-cubemap array
> getteximage-targets cube_array
> amongst others.

getteximage-depth still fails on r600 < eg. All others are skipped due to 
missing cube_array support. Can this also be fixed?

Marc


> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/drivers/r600/evergreen_state.c | 26 +-
>  1 file changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/evergreen_state.c
> b/src/gallium/drivers/r600/evergreen_state.c index 68977bb..b02d7ee 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -169,9 +169,20 @@ static uint32_t r600_translate_blend_factor(int
> blend_fact) return 0;
>  }
> 
> -static unsigned r600_tex_dim(unsigned dim, unsigned nr_samples)
> +static unsigned r600_tex_dim(struct r600_texture *rtex,
> +  unsigned view_target, unsigned nr_samples)
>  {
> - switch (dim) {
> + unsigned res_target = rtex->resource.b.b.target;
> +
> + if (view_target == PIPE_TEXTURE_CUBE ||
> + view_target == PIPE_TEXTURE_CUBE_ARRAY)
> + res_target = view_target;
> + /* If interpreting cubemaps as something else, set 2D_ARRAY. */
> + else if (res_target == PIPE_TEXTURE_CUBE ||
> +  res_target == PIPE_TEXTURE_CUBE_ARRAY)
> + res_target = PIPE_TEXTURE_2D_ARRAY;
> +
> + switch (res_target) {
>   default:
>   case PIPE_TEXTURE_1D:
>   return V_03_SQ_TEX_DIM_1D;
> @@ -805,13 +816,10 @@ static int evergreen_fill_tex_resource_words(struct
> r600_context *rctx, va = tmp->resource.gpu_address;
> 
>   /* array type views and views into array types need to use layer offset 
> */
> - dim = params->target;
> - if (params->target != PIPE_TEXTURE_CUBE)
> - dim = MAX2(params->target, texture->target);
> -
> - tex_resource_words[0] = (S_03_DIM(r600_tex_dim(dim,
> texture->nr_samples)) | -
> S_03_PITCH((pitch / 8) - 1) |
> -S_03_TEX_WIDTH(width - 1));
> + dim = r600_tex_dim(tmp, params->target, texture->nr_samples);
> + tex_resource_words[0] = (S_03_DIM(dim) |
> +  S_03_PITCH((pitch / 8) - 1) |
> +  S_03_TEX_WIDTH(width - 1));
>   if (rscreen->b.chip_class == CAYMAN)
>   tex_resource_words[0] |=
> CM_S_03_NON_DISP_TILING_ORDER(non_disp_tiling); else



signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [RFC PATCH 6/6] r600_shader.c: Preload some LDS values.

2017-11-15 Thread Gert Wollny
Pre-load all the LDS values who's range is accessed more than once.

Signed-off-by: Gert Wollny 
---
 src/gallium/drivers/r600/r600_shader.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 163ae75eb5..7c999fbb0b 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -2047,6 +2047,34 @@ static void count_tess_inputs(struct r600_shader_ctx 
*ctx)
}
 }
 
+static void preload_tes_lds(struct r600_shader_ctx *ctx)
+{
+   int i;
+   ctx->max_driver_temp_used = 0;
+   r600_get_temp(ctx);
+
+   for (i = 0; i < ctx->tess_input_cache.fill; ++i) {
+   struct r600_tess_input_cache_entry *ce = 
>tess_input_cache.data[i];
+   fetch_tes_input(ctx, >key, ce->reg, ce->mask);
+   ce->initialized = 1;
+   }
+}
+
+static void preload_tcs_lds(struct r600_shader_ctx *ctx)
+{
+   int i;
+   ctx->max_driver_temp_used = 0;
+   r600_get_temp(ctx);
+   for (i = 0; i < ctx->tess_input_cache.fill; ++i) {
+   struct r600_tess_input_cache_entry *ce = 
>tess_input_cache.data[i];
+   if (ce->key.Register.File == TGSI_FILE_INPUT)
+   fetch_tcs_input(ctx, >key, ce->reg, ce->mask);
+   else
+   fetch_tcs_output(ctx, >key, ce->reg, ce->mask);
+   ce->initialized = 1;
+   }
+}
+
 static int tgsi_split_lds_inputs(struct r600_shader_ctx *ctx)
 {
struct tgsi_full_instruction *inst = 
>parse.FullToken.FullInstruction;
@@ -3624,6 +3652,11 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
return r;
}
 
+   if (ctx.type == PIPE_SHADER_TESS_EVAL)
+   preload_tes_lds();
+   else if (ctx.type == PIPE_SHADER_TESS_CTRL)
+   preload_tcs_lds();
+
tgsi_parse_init(, tokens);
while (!tgsi_parse_end_of_tokens()) {
tgsi_parse_token();
-- 
2.13.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [RFC PATCH 3/6] r600_shader.c: Add a caching structure for load tesselation data

2017-11-15 Thread Gert Wollny
Cache values that are loaded more then once, or where various components
are loaded at separate places. This saves repeated calculation of the offsets.

Signed-off-by: Gert Wollny 
---
 src/gallium/drivers/r600/r600_shader.c | 211 +
 1 file changed, 190 insertions(+), 21 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 9fa83189bc..5713eda6b0 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -317,6 +317,20 @@ struct eg_interp {
unsignedij_index;
 };
 
+struct  r600_tess_input_cache_entry {
+   struct tgsi_full_src_register key;
+   unsigned reg: 16;
+   unsigned initialized:1;
+   unsigned read_access:1;
+   unsigned was_written:1;
+   unsigned mask:4;
+};
+
+struct r600_tess_input_cache {
+   struct r600_tess_input_cache_entry data[32];
+   int fill;
+};
+
 struct r600_shader_ctx {
struct tgsi_shader_info info;
struct tgsi_parse_context   parse;
@@ -353,6 +367,7 @@ struct r600_shader_ctx {
unsignedenabled_stream_buffers_mask;
unsignedtess_input_info; /* temp with 
tess input offsets */
unsignedtess_output_info; /* temp with 
tess input offsets */
+   struct r600_tess_input_cachetess_input_cache;
 };
 
 struct r600_shader_tgsi_instruction {
@@ -1810,7 +1825,8 @@ static int fetch_mask( struct tgsi_src_register *reg)
return mask; 
 }
 
-static int fetch_tes_input(struct r600_shader_ctx *ctx, struct 
tgsi_full_src_register *src, unsigned int dst_reg)
+static int fetch_tes_input(struct r600_shader_ctx *ctx, struct 
tgsi_full_src_register *src,
+  unsigned int dst_reg, unsigned mask)
 {
int r;
unsigned temp_reg = r600_get_temp(ctx);
@@ -1826,13 +1842,14 @@ static int fetch_tes_input(struct r600_shader_ctx *ctx, 
struct tgsi_full_src_reg
if (r)
return r;
 
-   r = do_lds_fetch_values(ctx, temp_reg, dst_reg, 
fetch_mask(>Register));
+   r = do_lds_fetch_values(ctx, temp_reg, dst_reg, mask);
if (r)
return r;
return 0;
 }
 
-static int fetch_tcs_input(struct r600_shader_ctx *ctx, struct 
tgsi_full_src_register *src, unsigned int dst_reg)
+static int fetch_tcs_input(struct r600_shader_ctx *ctx, struct 
tgsi_full_src_register *src,
+  unsigned int dst_reg, unsigned mask)
 {
int r;
unsigned temp_reg = r600_get_temp(ctx);
@@ -1852,13 +1869,14 @@ static int fetch_tcs_input(struct r600_shader_ctx *ctx, 
struct tgsi_full_src_reg
if (r)
return r;
 
-   r = do_lds_fetch_values(ctx, temp_reg, dst_reg, 
fetch_mask(>Register));
+   r = do_lds_fetch_values(ctx, temp_reg, dst_reg, mask);
if (r)
return r;
return 0;
 }
 
-static int fetch_tcs_output(struct r600_shader_ctx *ctx, struct 
tgsi_full_src_register *src, unsigned int dst_reg)
+static int fetch_tcs_output(struct r600_shader_ctx *ctx, struct 
tgsi_full_src_register *src,
+   unsigned int dst_reg, unsigned mask)
 {
int r;
unsigned temp_reg = r600_get_temp(ctx);
@@ -1874,12 +1892,153 @@ static int fetch_tcs_output(struct r600_shader_ctx 
*ctx, struct tgsi_full_src_re
if (r)
return r;
 
-   r = do_lds_fetch_values(ctx, temp_reg, dst_reg, 
fetch_mask(>Register));
+   r = do_lds_fetch_values(ctx, temp_reg, dst_reg, mask);
if (r)
return r;
return 0;
 }
 
+static int tgsi_full_src_register_equal_for_cache(struct 
tgsi_full_src_register *lhs,
+   struct tgsi_full_src_register *rhs)
+{
+   if (lhs->Register.Index != rhs->Register.Index)
+   return 0;
+
+   if (lhs->Register.File != rhs->Register.File)
+
+   if (lhs->Register.Indirect || rhs->Register.Indirect)
+   return 0;
+
+   if (lhs->Register.Dimension)  {
+   if (!rhs->Register.Dimension ||
+(rhs->Dimension.Index != lhs->Dimension.Index) ||
+(rhs->Dimension.Dimension != lhs->Dimension.Dimension))
+   return 0;
+
+   if (lhs->Dimension.Indirect || rhs->Dimension.Indirect)
+   return 0;
+   } else if (rhs->Register.Dimension)
+   return 0;
+
+   return 1;
+}
+
+static void tess_input_cache_store(struct r600_tess_input_cache *cache,
+  struct tgsi_full_src_register *src)
+{
+   if (cache->fill < 32) {
+   memcpy(>data[cache->fill].key, src, sizeof(struct 
tgsi_full_src_register));
+   cache->data[cache->fill].mask = fetch_mask(>Register);

[Mesa-dev] [RFC PATCH 5/6] r600_shader.c: Pre-caclculate some offsets for LDS access

2017-11-15 Thread Gert Wollny
Some offsets used for the LDS access are recalculated quite regularly.
Since tesselation shaders are not optimized by the SB manually pre-evaluate
some offsets to speed up this type of shader.

Signed-off-by: Gert Wollny 
---
 src/gallium/drivers/r600/r600_shader.c | 253 ++---
 1 file changed, 172 insertions(+), 81 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 873b525449..163ae75eb5 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -183,6 +183,7 @@ int r600_pipe_shader_create(struct pipe_context *ctx,
R600_ERR("translation from TGSI failed !\n");
goto error;
}
+
if (shader->shader.processor_type == PIPE_SHADER_VERTEX) {
/* only disable for vertex shaders in tess paths */
if (key.vs.as_ls)
@@ -329,6 +330,7 @@ struct  r600_tess_input_cache_entry {
 struct r600_tess_input_cache {
struct r600_tess_input_cache_entry data[32];
int fill;
+   int uses_lds_io;
 };
 
 struct r600_shader_ctx {
@@ -367,7 +369,8 @@ struct r600_shader_ctx {
unsignedenabled_stream_buffers_mask;
unsignedtess_input_info; /* temp with 
tess input offsets */
unsignedtess_output_info; /* temp with 
tess input offsets */
-   struct r600_tess_input_cachetess_input_cache;
+   unsigned  tess_io_info_precalc; /* temp with precalcuated 
offsets */
+   struct r600_tess_input_cache tess_input_cache;
 };
 
 struct r600_shader_tgsi_instruction {
@@ -392,7 +395,8 @@ static void r600_bytecode_src(struct r600_bytecode_alu_src 
*bc_src,
const struct r600_shader_src *shader_src,
unsigned chan);
 static int do_lds_fetch_values(struct r600_shader_ctx *ctx, unsigned temp_reg,
-  unsigned dst_reg, unsigned mask, int param);
+  unsigned temp_chan, unsigned dst_reg,
+  unsigned mask, int param);
 
 static int tgsi_last_instruction(unsigned writemask)
 {
@@ -1027,13 +1031,8 @@ static int tgsi_declaration(struct r600_shader_ctx *ctx)
 d->Semantic.Name == TGSI_SEMANTIC_TESSOUTER) {
int param = r600_get_lds_unique_index(d->Semantic.Name, 
0);
int dreg = d->Semantic.Name == TGSI_SEMANTIC_TESSINNER 
? 3 : 2;
-   unsigned temp_reg = r600_get_temp(ctx);
-
-   r = get_lds_offset0(ctx, 2, temp_reg, true);
-   if (r)
-   return r;
 
-   do_lds_fetch_values(ctx, temp_reg, dreg, 0xF, param);
+   do_lds_fetch_values(ctx, ctx->tess_io_info_precalc, 3, 
dreg, 0xF, param);
}
else if (d->Semantic.Name == TGSI_SEMANTIC_TESSCOORD) {
/* MOV r1.x, r0.x;
@@ -1648,7 +1647,9 @@ static int tgsi_split_gs_inputs(struct r600_shader_ctx 
*ctx)
  * All three shaders VS(LS), TCS, TES share the same LDS space.
  */
 /* this will return with the dw address in temp_reg.x */
-static int r600_get_byte_address(struct r600_shader_ctx *ctx, int temp_reg,
+static int r600_get_byte_address(struct r600_shader_ctx *ctx,
+unsigned *result_reg, unsigned *result_chan,
+int base_offset_reg, int base_offset_chan,
 const struct tgsi_full_dst_register *dst,
 const struct tgsi_full_src_register *src,
 int stride_bytes_reg, int stride_bytes_chan, 
int *param)
@@ -1656,7 +1657,11 @@ static int r600_get_byte_address(struct r600_shader_ctx 
*ctx, int temp_reg,
struct tgsi_full_dst_register reg;
ubyte *name, *index, *array_first;
int r;
+   int temp_reg = -1;
struct tgsi_shader_info *info = >info;
+   *result_reg = base_offset_reg;
+   *result_chan = base_offset_chan;
+
/* Set the register description. The address computation is the same
 * for sources and destinations. */
if (src) {
@@ -1686,14 +1691,18 @@ static int r600_get_byte_address(struct r600_shader_ctx 
*ctx, int temp_reg,
sel = V_SQ_ALU_SRC_LITERAL;
chan = reg.Dimension.Index;
}
-
+   temp_reg = r600_get_temp(ctx);
+   *result_reg = temp_reg;
+   *result_chan = 0;
r = single_alu_op3(ctx, ALU_OP3_MULADD_UINT24,
   temp_reg, 0,
   stride_bytes_reg, stride_bytes_chan,
   sel, chan,
-  temp_reg, 0);
+  

[Mesa-dev] [RFC PATCH 1/6] r600:shader: Fix all warnings issed with "-Wall -Wextra"

2017-11-15 Thread Gert Wollny
- fix a number of -Wsign-compare warnings
- fix two warnings for -Woverride-init because TGSI_OPCODE_CEIL == 83, and
  the according field was defined two times.

Signed-off-by: Gert Wollny 
---
 src/gallium/drivers/r600/r600_shader.c | 67 ++
 1 file changed, 36 insertions(+), 31 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 625537b48b..a2dc08c596 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -289,7 +289,7 @@ error:
return r;
 }
 
-void r600_pipe_shader_destroy(struct pipe_context *ctx, struct 
r600_pipe_shader *shader)
+void r600_pipe_shader_destroy(struct pipe_context *ctx UNUSED, struct 
r600_pipe_shader *shader)
 {
r600_resource_reference(>bo, NULL);
r600_bytecode_clear(>shader.bc);
@@ -1094,7 +1094,8 @@ static int allocate_system_value_inputs(struct 
r600_shader_ctx *ctx, int gpr_off
 
{ false, >fixed_pt_position_gpr, TGSI_SEMANTIC_SAMPLEID, 
TGSI_SEMANTIC_SAMPLEPOS } /* SAMPLEID is in Fixed Point Position GPR.w */
};
-   int i, k, num_regs = 0;
+   int num_regs = 0;
+   unsigned k, i;
 
if (tgsi_parse_init(, ctx->tokens) != TGSI_PARSE_OK) {
return 0;
@@ -1997,11 +1998,12 @@ static int process_twoside_color_inputs(struct 
r600_shader_ctx *ctx)
 }
 
 static int emit_streamout(struct r600_shader_ctx *ctx, struct 
pipe_stream_output_info *so,
- int stream, unsigned 
*stream_item_size)
+ int stream, unsigned 
*stream_item_size UNUSED)
 {
unsigned so_gpr[PIPE_MAX_SHADER_OUTPUTS];
unsigned start_comp[PIPE_MAX_SHADER_OUTPUTS];
-   int i, j, r;
+   int j, r;
+   unsigned i; 
 
/* Sanity checking. */
if (so->num_outputs > PIPE_MAX_SO_OUTPUTS) {
@@ -2153,13 +2155,14 @@ static int generate_gs_copy_shader(struct r600_context 
*rctx,
struct r600_shader_ctx ctx = {};
struct r600_shader *gs_shader = >shader;
struct r600_pipe_shader *cshader;
-   int ocnt = gs_shader->noutput;
+   unsigned ocnt = gs_shader->noutput;
struct r600_bytecode_alu alu;
struct r600_bytecode_vtx vtx;
struct r600_bytecode_output output;
struct r600_bytecode_cf *cf_jump, *cf_pop,
*last_exp_pos = NULL, *last_exp_param = NULL;
-   int i, j, next_clip_pos = 61, next_param = 0;
+   int next_clip_pos = 61, next_param = 0;
+   unsigned i, j; 
int ring;
bool only_ring_0 = true;
cshader = calloc(1, sizeof(struct r600_pipe_shader));
@@ -2475,10 +2478,11 @@ static int emit_inc_ring_offset(struct r600_shader_ctx 
*ctx, int idx, bool ind)
return 0;
 }
 
-static int emit_gs_ring_writes(struct r600_shader_ctx *ctx, const struct 
pipe_stream_output_info *so, int stream, bool ind)
+static int emit_gs_ring_writes(struct r600_shader_ctx *ctx, const struct 
pipe_stream_output_info *so UNUSED, int stream, bool ind)
 {
struct r600_bytecode_output output;
-   int i, k, ring_offset;
+   int ring_offset;
+   unsigned i, k; 
int effective_stream = stream == -1 ? 0 : stream;
int idx = 0;
 
@@ -2619,8 +2623,9 @@ static int r600_fetch_tess_io_info(struct r600_shader_ctx 
*ctx)
 
 static int emit_lds_vs_writes(struct r600_shader_ctx *ctx)
 {
-   int i, j, r;
+   int j, r;
int temp_reg;
+   unsigned i; 
 
/* fetch tcs input values into input_vals */
ctx->tess_input_info = r600_get_temp(ctx);
@@ -2793,10 +2798,10 @@ static int r600_tess_factor_read(struct r600_shader_ctx 
*ctx,
 
 static int r600_emit_tess_factor(struct r600_shader_ctx *ctx)
 {
-   unsigned i;
int stride, outer_comps, inner_comps;
int tessinner_idx = -1, tessouter_idx = -1;
-   int r;
+   int i, r;
+   unsigned j;
int temp_reg = r600_get_temp(ctx);
int treg[3] = {-1, -1, -1};
struct r600_bytecode_alu alu;
@@ -2843,11 +2848,11 @@ static int r600_emit_tess_factor(struct r600_shader_ctx 
*ctx)
 
/* R0 is InvocationID, RelPatchID, PatchID, tf_base */
/* TF_WRITE takes index in R.x, value in R.y */
-   for (i = 0; i < ctx->shader->noutput; i++) {
-   if (ctx->shader->output[i].name == TGSI_SEMANTIC_TESSINNER)
-   tessinner_idx = i;
-   if (ctx->shader->output[i].name == TGSI_SEMANTIC_TESSOUTER)
-   tessouter_idx = i;
+   for (j = 0; j < ctx->shader->noutput; j++) {
+   if (ctx->shader->output[j].name == TGSI_SEMANTIC_TESSINNER)
+   tessinner_idx = j;
+   if (ctx->shader->output[j].name == TGSI_SEMANTIC_TESSOUTER)
+   tessouter_idx = j;
}
 
if (tessouter_idx == -1)
@@ -2948,7 +2953,8 @@ static int 

[Mesa-dev] [RFC PATCH 2/6] r600_shader: only load from LDS what is really used

2017-11-15 Thread Gert Wollny
Use the destination write mask to determine which values are really to be
read from LDS and load only these.

Signed-off-by: Gert Wollny 
---
 src/gallium/drivers/r600/r600_shader.c | 33 ++---
 1 file changed, 26 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index a2dc08c596..9fa83189bc 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -377,7 +377,7 @@ static void r600_bytecode_src(struct r600_bytecode_alu_src 
*bc_src,
const struct r600_shader_src *shader_src,
unsigned chan);
 static int do_lds_fetch_values(struct r600_shader_ctx *ctx, unsigned temp_reg,
-  unsigned dst_reg);
+  unsigned dst_reg, unsigned mask);
 
 static int tgsi_last_instruction(unsigned writemask)
 {
@@ -1025,7 +1025,7 @@ static int tgsi_declaration(struct r600_shader_ctx *ctx)
if (r)
return r;
 
-   do_lds_fetch_values(ctx, temp_reg, dreg);
+   do_lds_fetch_values(ctx, temp_reg, dreg, 0xF);
}
else if (d->Semantic.Name == TGSI_SEMANTIC_TESSCOORD) {
/* MOV r1.x, r0.x;
@@ -1743,14 +1743,18 @@ static int r600_get_byte_address(struct r600_shader_ctx 
*ctx, int temp_reg,
 }
 
 static int do_lds_fetch_values(struct r600_shader_ctx *ctx, unsigned temp_reg,
-  unsigned dst_reg)
+  unsigned dst_reg, unsigned mask)
 {
struct r600_bytecode_alu alu;
int r, i;
 
if ((ctx->bc->cf_last->ndw>>1) >= 0x60)
ctx->bc->force_add_cf = 1;
+   
for (i = 1; i < 4; i++) {
+   if (!(mask & (1 << i)))
+   continue;
+   
r = single_alu_op2(ctx, ALU_OP2_ADD_INT,
   temp_reg, i,
   temp_reg, 0,
@@ -1759,6 +1763,9 @@ static int do_lds_fetch_values(struct r600_shader_ctx 
*ctx, unsigned temp_reg,
return r;
}
for (i = 0; i < 4; i++) {
+   if (! (mask & (1 << i)))
+   continue;
+   
/* emit an LDS_READ_RET */
memset(, 0, sizeof(alu));
alu.op = LDS_OP1_LDS_READ_RET;
@@ -1774,6 +1781,8 @@ static int do_lds_fetch_values(struct r600_shader_ctx 
*ctx, unsigned temp_reg,
return r;
}
for (i = 0; i < 4; i++) {
+   if (! (mask & (1 << i)))
+   continue;
/* then read from LDS_OQ_A_POP */
memset(, 0, sizeof(alu));
 
@@ -1791,6 +1800,16 @@ static int do_lds_fetch_values(struct r600_shader_ctx 
*ctx, unsigned temp_reg,
return 0;
 }
 
+static int fetch_mask( struct tgsi_src_register *reg)
+{
+   int mask = 0;
+   mask |= 1 << reg->SwizzleX;
+   mask |= 1 << reg->SwizzleY;
+   mask |= 1 << reg->SwizzleZ;
+   mask |= 1 << reg->SwizzleW; 
+   return mask; 
+}
+
 static int fetch_tes_input(struct r600_shader_ctx *ctx, struct 
tgsi_full_src_register *src, unsigned int dst_reg)
 {
int r;
@@ -1807,7 +1826,7 @@ static int fetch_tes_input(struct r600_shader_ctx *ctx, 
struct tgsi_full_src_reg
if (r)
return r;
 
-   r = do_lds_fetch_values(ctx, temp_reg, dst_reg);
+   r = do_lds_fetch_values(ctx, temp_reg, dst_reg, 
fetch_mask(>Register));
if (r)
return r;
return 0;
@@ -1833,7 +1852,7 @@ static int fetch_tcs_input(struct r600_shader_ctx *ctx, 
struct tgsi_full_src_reg
if (r)
return r;
 
-   r = do_lds_fetch_values(ctx, temp_reg, dst_reg);
+   r = do_lds_fetch_values(ctx, temp_reg, dst_reg, 
fetch_mask(>Register));
if (r)
return r;
return 0;
@@ -1855,7 +1874,7 @@ static int fetch_tcs_output(struct r600_shader_ctx *ctx, 
struct tgsi_full_src_re
if (r)
return r;
 
-   r = do_lds_fetch_values(ctx, temp_reg, dst_reg);
+   r = do_lds_fetch_values(ctx, temp_reg, dst_reg, 
fetch_mask(>Register));
if (r)
return r;
return 0;
@@ -2792,7 +2811,7 @@ static int r600_tess_factor_read(struct r600_shader_ctx 
*ctx,
if (r)
return r;
 
-   do_lds_fetch_values(ctx, temp_reg, dreg);
+   do_lds_fetch_values(ctx, temp_reg, dreg, 0xf);
return 0;
 }
 
-- 
2.13.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [RFC PATCH 4/6] r600_shader: Move calculation of offset to do_lds_fetch_values

2017-11-15 Thread Gert Wollny
Instead of calculating creating the code for calculating a base offset
and then to caclucate the component offfsets, calculate this offset
for all components directly. This saves one instruction group.

Signed-off-by: Gert Wollny 
---
 src/gallium/drivers/r600/r600_shader.c | 113 -
 1 file changed, 56 insertions(+), 57 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 5713eda6b0..873b525449 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -392,7 +392,7 @@ static void r600_bytecode_src(struct r600_bytecode_alu_src 
*bc_src,
const struct r600_shader_src *shader_src,
unsigned chan);
 static int do_lds_fetch_values(struct r600_shader_ctx *ctx, unsigned temp_reg,
-  unsigned dst_reg, unsigned mask);
+  unsigned dst_reg, unsigned mask, int param);
 
 static int tgsi_last_instruction(unsigned writemask)
 {
@@ -1033,14 +1033,7 @@ static int tgsi_declaration(struct r600_shader_ctx *ctx)
if (r)
return r;
 
-   r = single_alu_op2(ctx, ALU_OP2_ADD_INT,
-  temp_reg, 0,
-  temp_reg, 0,
-  V_SQ_ALU_SRC_LITERAL, param * 16);
-   if (r)
-   return r;
-
-   do_lds_fetch_values(ctx, temp_reg, dreg, 0xF);
+   do_lds_fetch_values(ctx, temp_reg, dreg, 0xF, param);
}
else if (d->Semantic.Name == TGSI_SEMANTIC_TESSCOORD) {
/* MOV r1.x, r0.x;
@@ -1658,12 +1651,11 @@ static int tgsi_split_gs_inputs(struct r600_shader_ctx 
*ctx)
 static int r600_get_byte_address(struct r600_shader_ctx *ctx, int temp_reg,
 const struct tgsi_full_dst_register *dst,
 const struct tgsi_full_src_register *src,
-int stride_bytes_reg, int stride_bytes_chan)
+int stride_bytes_reg, int stride_bytes_chan, 
int *param)
 {
struct tgsi_full_dst_register reg;
ubyte *name, *index, *array_first;
int r;
-   int param;
struct tgsi_shader_info *info = >info;
/* Set the register description. The address computation is the same
 * for sources and destinations. */
@@ -1736,51 +1728,54 @@ static int r600_get_byte_address(struct r600_shader_ctx 
*ctx, int temp_reg,
if (r)
return r;
 
-   param = r600_get_lds_unique_index(name[first],
+   *param = r600_get_lds_unique_index(name[first],
  index[first]);
 
} else {
-   param = r600_get_lds_unique_index(name[reg.Register.Index],
+   *param = r600_get_lds_unique_index(name[reg.Register.Index],
  index[reg.Register.Index]);
}
 
-   /* add to base_addr - passed in temp_reg.x */
-   if (param) {
-   r = single_alu_op2(ctx, ALU_OP2_ADD_INT,
-  temp_reg, 0,
-  temp_reg, 0,
-  V_SQ_ALU_SRC_LITERAL, param * 16);
-   if (r)
-   return r;
-
-   }
return 0;
 }
 
 static int do_lds_fetch_values(struct r600_shader_ctx *ctx, unsigned temp_reg,
-  unsigned dst_reg, unsigned mask)
+  unsigned dst_reg, unsigned mask, int param)
 {
struct r600_bytecode_alu alu;
int r, i;
+   int lasti = tgsi_last_instruction(mask);
+   int firsti = param > 0 ? 0 : 1;
 
if ((ctx->bc->cf_last->ndw>>1) >= 0x60)
ctx->bc->force_add_cf = 1;
-   
-   for (i = 1; i < 4; i++) {
+
+   /* Add the offsets to the base address */
+   for (i = firsti; i <= lasti; i++) {
if (!(mask & (1 << i)))
continue;
-   
-   r = single_alu_op2(ctx, ALU_OP2_ADD_INT,
-  temp_reg, i,
-  temp_reg, 0,
-  V_SQ_ALU_SRC_LITERAL, 4 * i);
+
+   memset(, 0, sizeof(struct r600_bytecode_alu));
+   alu.dst.sel = temp_reg;
+   alu.dst.chan = i;
+   alu.dst.write = 1;
+   alu.op = ALU_OP2_ADD_INT;
+   alu.src[0].sel = temp_reg;
+   alu.src[0].chan = 0;
+   alu.src[1].sel = V_SQ_ALU_SRC_LITERAL;
+   alu.src[1].value = 4 * i + 16 * param;
+
+   if (i == lasti)
+  

[Mesa-dev] [RFC PATCH 0/6] r600: speed up tesselation shaders

2017-11-15 Thread Gert Wollny
Dear all, 

since on r600 the tesselation shaders don't go through the sb-optimizer I 
though it might help to improve performance by applying some optimizations 
to the created assembly. The patches are experimental but to a point where 
I think some input from you could be helpful. 

This patch series does the following optimizations: 
- pre-calculate and re-use address offsets that were always calculated 
  on the fly
- only load from LDS what is really requested (based on the source swizzle 
masks 
  of the input values). 
- preload all used elements in cases where the shader would only partially load 
  data in different places. 

At this point there are no piglit regressions, but an unrelated GOU lockup is 
triggered. (Dave and me are already testing patches for this).

Benchmarking on BARTS with Unigine-Heaven and Tessmark x32 (with 
MESA_GL_VERSION_OVERRIDE=4.0) I get the following improvements: 

pre-opt post-opt
  master: fb0e9b5197
===
Heaven

Res:1280x1024
Q:High
Tess:Normal
---
Time:260.2  260.2
Frames:  32764192

FPS: 12.6   16.1
Min FPS: 4.0 4.6
Max FPS: 60.9   69.0

Score: 317.2   405.8
---

Tessmark x32
R: 1024x640
---
Points:635  700
FPS:10   11

A github repo inclusing these patches can be found at 
 
  https://github.com/gerddie/mesa/tree/r600-tess-speedup

many thanks for any comments, 
Gert 

Gert Wollny (6):
  r600:shader: Fix all warnings issed with "-Wall -Wextra"
  r600_shader: only load from LDS what is really used
  r600_shader.c: Add a caching structure for load tesselation data
  r600_shader: Move calculation of offset to do_lds_fetch_values
  r600_shader.c: Pre-caclculate some offsets for LDS access
  r600_shader.c: Preload some LDS values.

 src/gallium/drivers/r600/r600_shader.c | 636 -
 1 file changed, 476 insertions(+), 160 deletions(-)

-- 
2.13.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 07/18] intel/compiler: fix for memmove argument on annotating error

2017-11-15 Thread Rogovin, Kevin
I have just seen that I have had an epic brain lapse on this.

The code is pretty clear, the correct value of count should be ann_count - i. 
This is because:
  a. The value of ann_count is the value of the array size BEFORE the insert; 
this is clear from the code within the if (offset + ..) where it increments 
ann_count.
 b. Since ann_count is the size before the insert, it should move the content 
in the open range [i, ann_count) to [i + 1, ann_count + 1); thus the number of 
elements is given by ann_count - i.

Changing the count to ann_count - i does the right thing, and also makes it 
quite clear that Matt is correct on patch 11: that it was just papering over a 
bug from using the wrong count value.

However, once this is done, the build does assert() on some shaders that I 
have; this is because it fails to understand some registers.

-Kevin

-Original Message-
From: Matt Turner [mailto:matts...@gmail.com] 
Sent: Monday, November 13, 2017 11:21 PM
To: Rogovin, Kevin 
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 07/18] intel/compiler: fix for memmove argument 
on annotating error

On Mon, Nov 13, 2017 at 1:12 PM, Rogovin, Kevin  wrote:
> Hi,
>
>
>  I confess I am not 100% on this code and I did educated guessing what it is  
> trying to do; I figured it was trying to insert contents at the current index 
> i; and that ann_count is the size -after- the insert. thus I figured the 
> memmove is to move the half open interval [i, ann_count-1) to the half open 
> interval [i + 1, ann_count). The number of elements in the half open range 
> [i, ann_count - 1) is given by ann_count - i - 1.
>
> I tried changing the count from ann_count - i - 1 to ann_count - i + 1 and 
> then the disassembler crashed in annotation on the same shaders that I have 
> had it crash on before.

Interesting. Could you send me the shader binary? I'll take a look.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 103699] Latest mesa breaks firefox on kde plasma with compositing on

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103699

--- Comment #8 from Tapani Pälli  ---
(also please try again with latest mesa)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] util: add new ASSERT_BITFIELD_SIZE() macro (v2)

2017-11-15 Thread Brian Paul
For checking that bitfields are large enough to hold the largest
expected value.

v2: move into existing util/macros.h header where STATIC_ASSERT() lives.
---
 src/util/macros.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/util/macros.h b/src/util/macros.h
index a9a52a1..3fd0ffd 100644
--- a/src/util/macros.h
+++ b/src/util/macros.h
@@ -68,6 +68,22 @@
 
 
 /**
+ * Check that STRUCT::FIELD can hold MAXVAL.  We use a lot of bitfields
+ * in Mesa/gallium.  We have to be sure they're of sufficient size to
+ * hold the largest expected value.
+ * Note that with MSVC, enums are signed and enum bitfields need one extra
+ * high bit (always zero) to ensure the max value is handled correctly.
+ * This macro will detect that with MSVC, but not GCC.
+ */
+#define ASSERT_BITFIELD_SIZE(STRUCT, FIELD, MAXVAL) \
+   do { \
+  STRUCT s; \
+  s.FIELD = (MAXVAL); \
+  assert((int) s.FIELD == (MAXVAL) && "Insufficient bitfield size!"); \
+   } while (0)
+
+
+/**
  * Unreachable macro. Useful for suppressing "control reaches end of non-void
  * function" warnings.
  */
-- 
1.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] st/glsl_to_nir: don't generate nir twice for gs

2017-11-15 Thread Timothy Arceri
This was left out of c980a3aa3133
---
 src/mesa/state_tracker/st_program.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 97b2e1234b..dc81a17289 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -1424,29 +1424,23 @@ st_translate_program_common(struct st_context *st,
 
 /**
  * Translate a geometry program to create a new variant.
  */
 bool
 st_translate_geometry_program(struct st_context *st,
   struct st_common_program *stgp)
 {
struct ureg_program *ureg;
 
-   if (stgp->shader_program) {
-  nir_shader *nir = st_glsl_to_nir(st, >Base, stgp->shader_program,
-   MESA_SHADER_GEOMETRY);
-
-  stgp->tgsi.type = PIPE_SHADER_IR_NIR;
-  stgp->tgsi.ir.nir = nir;
-
+   /* We have already compiler to NIR so just return */
+   if (stgp->shader_program)
   return true;
-   }
 
ureg = ureg_create_with_screen(PIPE_SHADER_GEOMETRY, st->pipe->screen);
if (ureg == NULL)
   return false;
 
ureg_property(ureg, TGSI_PROPERTY_GS_INPUT_PRIM,
  stgp->Base.info.gs.input_primitive);
ureg_property(ureg, TGSI_PROPERTY_GS_OUTPUT_PRIM,
  stgp->Base.info.gs.output_primitive);
ureg_property(ureg, TGSI_PROPERTY_GS_MAX_OUTPUT_VERTICES,
-- 
2.14.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] st/glsl_to_nir: don't generate nir twice for gs

2017-11-15 Thread Dylan Baker
Quoting Timothy Arceri (2017-11-15 16:16:10)
> This was left out of c980a3aa3133
> ---
>  src/mesa/state_tracker/st_program.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_program.c 
> b/src/mesa/state_tracker/st_program.c
> index 97b2e1234b..dc81a17289 100644
> --- a/src/mesa/state_tracker/st_program.c
> +++ b/src/mesa/state_tracker/st_program.c
> @@ -1424,29 +1424,23 @@ st_translate_program_common(struct st_context *st,
>  
>  /**
>   * Translate a geometry program to create a new variant.
>   */
>  bool
>  st_translate_geometry_program(struct st_context *st,
>struct st_common_program *stgp)
>  {
> struct ureg_program *ureg;
>  
> -   if (stgp->shader_program) {
> -  nir_shader *nir = st_glsl_to_nir(st, >Base, stgp->shader_program,
> -   MESA_SHADER_GEOMETRY);
> -
> -  stgp->tgsi.type = PIPE_SHADER_IR_NIR;
> -  stgp->tgsi.ir.nir = nir;
> -
> +   /* We have already compiler to NIR so just return */
 
 compiled
> +   if (stgp->shader_program)
>return true;
> -   }
>  
> ureg = ureg_create_with_screen(PIPE_SHADER_GEOMETRY, st->pipe->screen);
> if (ureg == NULL)
>return false;
>  
> ureg_property(ureg, TGSI_PROPERTY_GS_INPUT_PRIM,
>   stgp->Base.info.gs.input_primitive);
> ureg_property(ureg, TGSI_PROPERTY_GS_OUTPUT_PRIM,
>   stgp->Base.info.gs.output_primitive);
> ureg_property(ureg, TGSI_PROPERTY_GS_MAX_OUTPUT_VERTICES,
> -- 
> 2.14.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 17/24] mesa/main: Add a 'spirv' flag to gl_shader_program_data

2017-11-15 Thread Timothy Arceri

On 16/11/17 00:22, Eduardo Lima Mitev wrote:

This will be used by the linker code to dfferentiate between
programs made out of SPIR-V or GLSL shaders.


So far everywhere this is used it seems you could just do something like:

 if (shProg->_LinkedShaders[stage]->spirv_data)
   ... spriv stuff ...
 else
   ... glsl stuff ...




---
  src/mesa/main/mtypes.h | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index d624f2cbd19..db9c2e1deaa 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2902,6 +2902,12 @@ struct gl_shader_program_data
  
 /* Mask of stages this program was linked against */

 unsigned linked_stages;
+
+   /* Whether the shaders of this program are loaded from SPIR-V binaries
+* (all have the SPIR_V_BINARY_ARB state). This was introduced by the
+* ARB_gl_spirv extension.
+*/
+   bool spirv;
  };
  
  /**



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 4/4] meson: Remove completed or irrelevant TODO comments

2017-11-15 Thread Dylan Baker
These are all either done already, or are autotools specific. The
misspelled gallium G3DVL is the autotools specific bit, meson is
handling that via build_by_default.

Signed-off-by: Dylan Baker 
---
 meson.build | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/meson.build b/meson.build
index 5ac2ebc9e5d..d0e14b549fc 100644
--- a/meson.build
+++ b/meson.build
@@ -547,13 +547,6 @@ endif
 # TODO: powr8
 # TODO: shared/static? Is this even worth doing?
 
-# I don't think that I need to set any of the debug stuff, I think meson
-# handles that for us
-
-# TODO: ldflags
-
-# TODO: texture-float (gallium/mesa only)
-
 # Building x86 assembly code requires running x86 binaries. It is possible for
 # x86_64 OSes to run x86 binaries, so don't disable asm in those cases
 # TODO: it should be possible to use an exe_wrapper to run the binary durring
@@ -800,12 +793,8 @@ else
   dep_unwind = []
 endif
 
-# TODO: flags for opengl, gles, dri
-
 # TODO: gallium-hud
 
-# TODO: glx provider
-
 if with_osmesa != 'none'
   if with_osmesa == 'classic' and not with_dri_swrast
 error('OSMesa classic requires dri (classic) swrast.')
@@ -898,10 +887,6 @@ if with_platform_x11
   endif
 endif
 
-# TODO: osmesa
-
-# TODO: vallium G3DVL
-
 # TODO: nine
 
 # TODO: clover
-- 
2.15.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/4] meson: disable x86 asm in fewer cases.

2017-11-15 Thread Dylan Baker
This patch allows building asm for x86 on x86_64 platforms, when the
operating system is the same. Previously cross compile always turned off
assembly. This allows using a cross file to cross compile x86 binaries
on x86_64 with asm.

This could probably be relaxed further thanks to meson's "exe_wrapper",
which is way to specify an emulator or compatibility layer (wine) that
can run the foreign binaries on the build system. Since the meson build
at this point only supports building on Linux I can't test this and I
don't want to write/enable code that cannot even be build tested.

Signed-off-by: Dylan Baker 
---
 meson.build | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/meson.build b/meson.build
index 0d201c711a0..261c4753427 100644
--- a/meson.build
+++ b/meson.build
@@ -554,13 +554,16 @@ endif
 
 # TODO: texture-float (gallium/mesa only)
 
-# TODO: cross-compiling. I don't think this is relavent to meson
-
-# FIXME: enable asm when cross compiler
-# This is doable (autotools does it), but it's not of immediate concern
-if meson.is_cross_build() and host_machine.cpu_family().startswith('x86')
-  message('Cross compiling, disabling x86/x86_64 asm')
-  with_asm = false
+# Building x86 assembly code requires running x86 binaries. It is possible for
+# x86_64 OSes to run x86 binaries, so don't disable asm in those cases
+# TODO: it should be possible to use an exe_wrapper to run the binary durring
+# the build. 
+if meson.is_cross_build() 
+  if (not (build_machine.cpu_family() == 'x86_64' and 
host_machine.cpu_family() == 'x86')
+  and build_machine.system() == host_machine.system())
+message('Cross compiling to x86 from non-x86, disabling asm')
+with_asm = false
+  endif
 endif
 
 with_asm_arch = ''
-- 
2.15.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

2017-11-15 Thread Dylan Baker
This patch checks for an and then enables sse4.1 optimizations if the
host machine will be x86/x86_64.

Signed-off-by: Dylan Baker 
---
 meson.build  | 27 ++-
 src/mesa/meson.build | 14 +++---
 2 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/meson.build b/meson.build
index 1c4200705f3..0d201c711a0 100644
--- a/meson.build
+++ b/meson.build
@@ -502,7 +502,32 @@ foreach a : ['-Wno-override-init', 
'-Wno-initializer-overrides']
   endif
 endforeach
 
-# TODO: SSE41 (which is only required for core mesa)
+with_sse41 = false
+if host_machine.cpu_family().startswith('x86')
+  sse41_args = ['-msse4.1']
+  # GCC on x86 (not 64) with -msse* assumes a 16 byte aligned stack, but that's
+  # not guaranteed
+  if host_machine.cpu_family() == 'x86'
+sse41_args += '-mstackrealign'
+  endif
+
+  _code = '''
+  #include 
+  int param;
+  int main () {
+  __m128i a = _mm_set1_epi32 (param), b = _mm_set1_epi32 (param + 1), c;
+  c = _mm_max_epu32(a, b);
+  return _mm_cvtsi128_si32(c);
+  }
+  '''
+
+  if cc.compiles(_code, args : sse41_args, name : 'SSE4.1')
+pre_args += '-DHAVE_SSE41'
+with_sse41 = true
+  endif
+else
+  sse41_args = []
+endif
 
 # Check for GCC style atomics
 if cc.compiles('int main() { int n; return __atomic_load_n(, 
__ATOMIC_ACQUIRE); }',
diff --git a/src/mesa/meson.build b/src/mesa/meson.build
index b839fd02981..05a3a9ac55d 100644
--- a/src/mesa/meson.build
+++ b/src/mesa/meson.build
@@ -592,9 +592,6 @@ files_libmesa_gallium = files(
   'state_tracker/st_vdpau.h',
 )
 
-# TODO: sse41
-libmesa_sse41 = []
-
 matypes_h = []
 if with_asm_arch == 'x86' or with_asm_arch == 'x86_64'
   gen_matypes = executable(
@@ -692,6 +689,17 @@ files_libmesa_common += [
   sha1_h,
 ]
 
+if with_sse41
+  libmesa_sse41 = static_library(
+'mesa_sse41',
+files('main/streaming-load-memcpy.c', 'main/sse_minmax.c'),
+c_args : [c_vis_args, c_msvc_compat_args, sse41_args],
+include_directories : inc_common,
+  )
+else
+  libmesa_sse41 = []
+endif
+
 libmesa_classic = static_library(
   'mesa_classic',
   [files_libmesa_common, files_libmesa_classic],
-- 
2.15.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 3/4] meson: Fix TODO for missing dl_iterate_phdr function

2017-11-15 Thread Dylan Baker
This function is required for both the Intel "Anvil" vulkan driver and
the i965 GL driver. Error out if either of those is enabled but this
function isn't found.

Signed-off-by: Dylan Baker 
---
 meson.build | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index 261c4753427..5ac2ebc9e5d 100644
--- a/meson.build
+++ b/meson.build
@@ -672,8 +672,10 @@ endif
 
 if cc.has_function('dl_iterate_phdr')
   pre_args += '-DHAVE_DL_ITERATE_PHDR'
-else
-  # TODO: this is required for vulkan
+elif with_intel_vk
+  error('Intel "Anvil" Vulkan driver requires the dl_iterate_phdr function')
+elif with_dri_i965 and get_option('shader-cache')
+  error('Intel i965 GL driver requires dl_iterate_phdr when built with shader 
caching.')
 endif
 
 # Determine whether or not the rt library is needed for time functions
-- 
2.15.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 103412] gallium/wgl: Another fix to context creation without prior SetPixelFormat()

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103412

Brian Paul  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Brian Paul  ---
Pushed as commit bf41b2b2627aa3790d380092c28c5d3395cc9cde

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Driver testing system for Steam games

2017-11-15 Thread Karen Ghavam
Folks,

If you have feedback or questions, you can mail them to i...@lunarg.com

Karen Ghavam
CEO and Engineering Director
LunarG, Inc. - 3D Graphics Software Innovations
ka...@lunarg.com
970-988-9043

On Wed, Nov 15, 2017 at 1:32 PM, Pierre-Loup A. Griffais <
pgriff...@valvesoftware.com> wrote:

> Hi Mesa-Devel,
>
> Today we're happy to announce that we're making the LunarG driver
> testing system available to the Mesa development community. We've been
> using this system internally for quite some time, but we've recently
> done some more work so the results could also be publicly available for
> the community to track regressions, and for developers to be able to
> submit their branches for pre-submit testing.
>
> The LunarG test system is a service that provides regular regression
> testing on Mesa releases for Intel and AMD OpenGL graphics drivers. It
> also enables users to test their own Mesa builds and compare results to
> LunarG baselines, LunarG test runs, or user test runs. The objective of
> the LunarG test system service for Mesa is to identify regressions in
> performance or rendering for Mesa releases and developer's branches that
> would negatively impact the gaming experience.
>
> The test suite is a collection of trace files created from hundreds of
> Linux OpenGL games from Steam. These trace files are used to automate
> testing of rendering correctness as well as game performance. There are
> currently 6 graphics platforms available for test (3 configurations each
> of Intel and AMD graphics). The full suite of games typically runs
> overnight with results posted the next day.
>
> To access the test system and browse results: https://share.lunarg.com
> (click on "Test System") on the left.
>
> Here's an example of a test report that a Mesa bug could possibly be filed
> from after inspection: https://imgur.com/a/cBonz
>
> To learn more about how the test system works, read the short user
> manual: https://share.lunarg.com/test/manual
>
> Let us know if you have any feedback or questions. Vulkan support is
> planned for the future, but not ready quite yet.
>
> Thanks,
>   - Pierre-Loup
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/24] mesa: add gl_shader::SpirVBinary and getter

2017-11-15 Thread Timothy Arceri

On 16/11/17 00:22, Eduardo Lima Mitev wrote:

From: Nicolai Hähnle 

---
  src/mesa/main/mtypes.h| 1 +
  src/mesa/main/shaderapi.c | 3 +++
  2 files changed, 4 insertions(+)

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 1c953b83155..cfc763f043e 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2579,6 +2579,7 @@ struct gl_shader
 GLchar *Label;   /**< GL_KHR_debug */
 unsigned char sha1[20]; /**< SHA1 hash of pre-processed source */
 GLboolean DeletePending;
+   GLboolean SpirVBinary;


As with my other comment about a special spirv bool. I think you should 
move this patch to later in the series drop the bool and instead query 
whether spirv_data is NULL or not to decide if this is a spriv shader.




 bool IsES;  /**< True if this shader uses GLSL ES */
  
 enum gl_compile_status CompileStatus;

diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 72824355838..5db335b695b 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -960,6 +960,9 @@ get_shaderiv(struct gl_context *ctx, GLuint name, GLenum 
pname, GLint *params)
 case GL_SHADER_SOURCE_LENGTH:
*params = shader->Source ? strlen((char *) shader->Source) + 1 : 0;
break;
+   case GL_SPIR_V_BINARY_ARB:
+  *params = shader->SpirVBinary;
+  break;
 default:
_mesa_error(ctx, GL_INVALID_ENUM, "glGetShaderiv(pname)");
return;


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 103757] eglGetDisplay() is broken for Wayland

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103757

--- Comment #10 from Pekka Paalanen  ---
(In reply to Michael Olbrich from comment #9)
> (In reply to Pekka Paalanen from comment #1)
> > Any reason you cannot use EGL_KHR_platform_wayland?
> 
> It's not my code. It's somewhere in gstreamer-vaapi. I was just debugging
> why my application was crashing.

Ok, while this issue is being worked on in Mesa, I would very much recommend
filing a bug against gstreamer-vaapi to start using the EGL platform extensions
whenever available. It's the only reliable way forward.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 103699] Latest mesa breaks firefox on kde plasma with compositing on

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103699

--- Comment #11 from Tapani Pälli  ---
Created attachment 135512
  --> https://bugs.freedesktop.org/attachment.cgi?id=135512=edit
test case

Could you please compile and run this test application and attach what is
prints? Does it create a visible window? Also please attach your glxinfo
output. Many thanks!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/2] i965/tcs: support gl_PatchVerticesIn as a system value from SPIR-V

2017-11-15 Thread Iago Toral Quiroga
We currently handle this by lowering it to a uniform for gen8+ but
the SPIR-V path generates this as a system value, so handle that
case as well.
---
 src/mesa/drivers/dri/i965/brw_tcs.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c 
b/src/mesa/drivers/dri/i965/brw_tcs.c
index 4424efea4f0..b07b11f485d 100644
--- a/src/mesa/drivers/dri/i965/brw_tcs.c
+++ b/src/mesa/drivers/dri/i965/brw_tcs.c
@@ -296,7 +296,14 @@ brw_tcs_populate_key(struct brw_context *brw,
   per_patch_slots |= prog->info.patch_outputs_written;
}
 
-   if (devinfo->gen < 8 || !tcp)
+   /* For GLSL, gen8+ lowers gl_PatchVerticesIn to a uniform, however
+* the SPIR-V path always lowers it to a system value.
+*/
+   bool reads_patch_vertices_as_system_value =
+  tcp && (tcp->program.nir->info.system_values_read &
+  BITFIELD64_BIT(SYSTEM_VALUE_VERTICES_IN));
+
+   if (devinfo->gen < 8 || !tcp || reads_patch_vertices_as_system_value)
   key->input_vertices = brw->ctx.TessCtrlProgram.patch_vertices;
key->outputs_written = per_vertex_slots;
key->patch_outputs_written = per_patch_slots;
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/2] nir/gather_info: recognize load_patch_vertices_in as a system value

2017-11-15 Thread Iago Toral Quiroga
This intrinsic is produced to load SYSTEM_VALUE_VERTICES_IN, which is
generated to load gl_PatchVerticesIn in the SPIR-V path for both
Vulkan and OpenGL.
---
 src/compiler/nir/nir_gather_info.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compiler/nir/nir_gather_info.c 
b/src/compiler/nir/nir_gather_info.c
index 13cdae39eca..a322af794e5 100644
--- a/src/compiler/nir/nir_gather_info.c
+++ b/src/compiler/nir/nir_gather_info.c
@@ -246,6 +246,7 @@ gather_intrinsic_info(nir_intrinsic_instr *instr, 
nir_shader *shader)
case nir_intrinsic_load_tess_coord:
case nir_intrinsic_load_tess_level_outer:
case nir_intrinsic_load_tess_level_inner:
+   case nir_intrinsic_load_patch_vertices_in:
   shader->info.system_values_read |=
  (1ull << nir_system_value_from_intrinsic(instr->intrinsic));
   break;
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

2017-11-15 Thread Matt Turner
On Wed, Nov 15, 2017 at 5:10 PM, Dylan Baker  wrote:
> This patch checks for an and then enables sse4.1 optimizations if the
> host machine will be x86/x86_64.

There's some stack realignment stuff that probably needs to stay, but
depending on what gcc version we require we can just always enable SSE
4.1. It's existed since GCC 4.3 (March 2008).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 103586] OpenCL/Clover: AMD Turks: corrupt output buffer (depending on dimension order?)

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103586

--- Comment #14 from Jan Vesely  ---
(In reply to Dave Gilbert from comment #12)
> 
> It doesn't seem to help, if I add:
> --- a/ocl.cpp
> +++ b/ocl.cpp
> @@ -74,6 +74,7 @@ static int got_dev(cl::Platform ,
> std::vector , cl::Dev
>  cl::Event eventBarrier2;
>  queue.enqueueBarrierWithWaitList(NULL,);
>  std::cerr << __func__ << "enqueueMapBuffer gave: " << err << std::endl;
> +event.wait();
>  eventMap.wait();
>  eventBarrier2.wait();
>  
> 
> that doesn't seem to help and I think event is the event triggered by the
> kernel.

can you move it few lines up? (before the call to mapBuffer).

-- 
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.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 103128] [softpipe] piglit fs-ldexp regression

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103128

Nicolai Hähnle  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Nicolai Hähnle  ---
commit f3fa3b0d95c712c00318ca5601433bce1b82432d

-- 
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.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 103674] u_queue.c:173:7: error: implicit declaration of function 'timespec_get' is invalid in C99

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103674

Nicolai Hähnle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Nicolai Hähnle  ---
commit 2e3d0dd6c8f405f27d68b1ac35e928233bf8b89c

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/2] util: fix compatibility of timespec_get() across OSes

2017-11-15 Thread George Kyriazis
while timespec_get() is supposed to hide OS differences, compatibility doesn't
cover old OSes (like CentOS 6) where timespec_get() does not exist.

Fall back to using os_get_time_nano(), but separate out the functionality
that populates struct timespec, so it can also be called from
_util_queue_fence_wait_timeout(), where timespec_get() was initially called.
---
 src/util/os_time.c | 31 ---
 src/util/os_time.h |  6 ++
 src/util/u_queue.c |  5 -
 3 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/src/util/os_time.c b/src/util/os_time.c
index 1c34bfd..a3cef81 100644
--- a/src/util/os_time.c
+++ b/src/util/os_time.c
@@ -48,37 +48,36 @@
 #  error Unsupported OS
 #endif
 
-
-int64_t
-os_time_get_nano(void)
+void
+os_time_get_sec_nano(int64_t *sec, int64_t *nsec)
 {
 #if defined(__linux__)
 
-   struct timespec tv;
-   clock_gettime(CLOCK_MONOTONIC, );
-   return tv.tv_nsec + tv.tv_sec*INT64_C(10);
+   struct timespec ts;
+   clock_gettime(CLOCK_MONOTONIC, );
+   *sec = ts.tv_sec;
+   *nsec = ts.tv_nsec;
 
 #elif defined(__unix__)
 
struct timeval tv;
gettimeofday(, NULL);
-   return tv.tv_usec*INT64_C(1000) + tv.tv_sec*INT64_C(10);
+   *sec = tv.tv_sec;
+   *nsec = tv.tv_usec * INT64_T(1000);
 
 #elif defined(_MSC_VER)
 
static LARGE_INTEGER frequency;
LARGE_INTEGER counter;
-   int64_t secs, nanosecs;
if(!frequency.QuadPart)
   QueryPerformanceFrequency();
QueryPerformanceCounter();
/* Compute seconds and nanoseconds parts separately to
 * reduce severity of precision loss.
 */
-   secs = counter.QuadPart / frequency.QuadPart;
-   nanosecs = (counter.QuadPart % frequency.QuadPart) * INT64_C(10)
+   *sec = counter.QuadPart / frequency.QuadPart;
+   *nsec = (counter.QuadPart % frequency.QuadPart) * INT64_C(10)
   / frequency.QuadPart;
-   return secs*INT64_C(10) + nanosecs;
 
 #else
 
@@ -87,6 +86,16 @@ os_time_get_nano(void)
 #endif
 }
 
+int64_t
+os_time_get_nano(void)
+{
+   int64_t secs, nanosecs;
+
+   os_time_get_sec_nano(, );
+
+   return secs*INT64_C(10) + nanosecs;
+}
+
 
 
 void
diff --git a/src/util/os_time.h b/src/util/os_time.h
index 049ab11..6169431 100644
--- a/src/util/os_time.h
+++ b/src/util/os_time.h
@@ -46,6 +46,12 @@ extern "C" {
 #define OS_TIMEOUT_INFINITE 0xull
 
 /*
+ * Get the current time in seconds and nanoseconds from an unknown base.
+ */
+void
+os_time_get_sec_nano(int64_t *sec, int64_t *nsec);
+
+/*
  * Get the current time in nanoseconds from an unknown base.
  */
 int64_t
diff --git a/src/util/u_queue.c b/src/util/u_queue.c
index 43c28ac..753d59e 100644
--- a/src/util/u_queue.c
+++ b/src/util/u_queue.c
@@ -168,9 +168,12 @@ _util_queue_fence_wait_timeout(struct util_queue_fence 
*fence,
int64_t rel = abs_timeout - os_time_get_nano();
 
if (rel > 0) {
+  int64_t sec, nsec;
   struct timespec ts;
 
-  timespec_get(, TIME_UTC);
+  os_time_get_sec_nano(, );
+  ts.tv_sec = sec;
+  ts.tv_nsec = nsec;
 
   ts.tv_sec += abs_timeout / (1000*1000*1000);
   ts.tv_nsec += abs_timeout % (1000*1000*1000);
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mapi: Use correct shared library name on macOS.

2017-11-15 Thread Eric Engestrom
On Tuesday, 2017-11-14 17:57:38 -0800, Dylan Baker wrote:
> I think "suffix" would be better for the title "name". Also, library ->
> libraries.
> 
> With that changed:
> Reviewed-by: Dylan Baker 

Reviewed-by: Eric Engestrom 

> 
> Quoting Vinson Lee (2017-11-14 17:17:49)
> > Signed-off-by: Vinson Lee 
> > ---
> >  src/mapi/es1api/ABI-check | 7 ++-
> >  src/mapi/es2api/ABI-check | 7 ++-
> >  2 files changed, 12 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/mapi/es1api/ABI-check b/src/mapi/es1api/ABI-check
> > index bd9d0288d60d..0a867343c79a 100755
> > --- a/src/mapi/es1api/ABI-check
> > +++ b/src/mapi/es1api/ABI-check
> > @@ -9,7 +9,12 @@ set -eu
> >  # or in extensions that are part of the ES 1.1 extension pack.
> >  # (see 
> > http://www.khronos.org/registry/gles/specs/1.1/opengles_spec_1_1_extension_pack.pdf)
> >  
> > -LIB=${1-es1api/.libs/libGLESv1_CM.so.1}
> > +if [ $(uname) == "Darwin" ]
> > +then
> > +  LIB=${1-es1api/.libs/libGLESv1_CM.dylib}
> > +else
> > +  LIB=${1-es1api/.libs/libGLESv1_CM.so.1}
> > +fi
> >  
> >  if ! [ -f "$LIB" ]
> >  then
> > diff --git a/src/mapi/es2api/ABI-check b/src/mapi/es2api/ABI-check
> > index 179bea132e3b..716e6679a49f 100755
> > --- a/src/mapi/es2api/ABI-check
> > +++ b/src/mapi/es2api/ABI-check
> > @@ -6,7 +6,12 @@ set -eu
> >  # GL_EXT_multi_draw_arrays
> >  # GL_OES_EGL_image
> >  
> > -LIB=${1-es2api/.libs/libGLESv2.so.2}
> > +if [ $(uname) == "Darwin" ]
> > +then
> > +  LIB=${1-es2api/.libs/libGLESv2.dylib}
> > +else
> > +  LIB=${1-es2api/.libs/libGLESv2.so.2}
> > +fi
> >  
> >  if ! [ -f "$LIB" ]
> >  then
> > -- 
> > 2.15.0
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [AppVeyor] mesa master #6163 failed

2017-11-15 Thread Jose Fonseca
I could post a remark on AppVeyor's forums, but it sounds from the logs the 
issue could be on our (freedesktop.org's) side.


I've reconfigured AppVeyor to use 
https://anongit.freedesktop.org/git/mesa/mesa.git/ instead of 
git://anongit.freedesktop.org/mesa/mesa .  Perhaps fewer things can go wrong 
when using HTTP.


Jose


From: mesa-dev  on behalf of Roland 
Scheidegger 
Sent: Wednesday, November 15, 2017 02:27
To: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [AppVeyor] mesa master #6163 failed

Does someone know what's going on with that?

Build started
git clone -q --depth=100 --branch=master
git://anongit.freedesktop.org/mesa/mesa C:\projects\mesa
remote: fatal: unable to read 7a5d62c8e87c50bacaf697e05230ba49a71a0129

remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
Command exited with code 128

I mean there were failures like this before. But now since a couple of
days, this seems to happen at least daily, which is quite annoying.

Roland

Am 15.11.2017 um 03:19 schrieb AppVeyor:
>
>   Build mesa 6163 failed
>   
>
> Commit 65123ee62c by Roland Scheidegger  on
> 11/9/2017 6:53 PM:
> r600: set the number type correctly for float rts in cb setup\n\nFloat
> rts were always set as unorm instead of float.\nNot sure of the
> consequences, but at least it looks like the blend clamp\nwould have
> been enabled, which is against the rules (only eg really bothered\nto
> even attempt to specify this correctly, r600 always used clamp
> anyway).\nAlbeit r600 (not r700) setup still looks bugged to me due to
> never setting\nBLEND_FLOAT32 which must be set according to docs...\nNot
> sure if the hw really cares, no piglit change (on
> eg/juniper).\n\nReviewed-by: Dave Airlie 
>
> Configure your notification preferences
> 
>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] meson: Don't define HAVE_PTHREAD only on linux

2017-11-15 Thread Jon Turney
I'm not sure of the reason for this. I don't see anything like this in
configure.ac

In include/c11/threads.h the cases are:

1) building for Windows -> threads_win32.h
2) HAVE_PTHREAD -> threads_posix.h
3) Not supported on this platform

So not defining HAVE_PTHREAD for anything not Windows just means we can't
build at all.

When we are building for Windows, I'm not sure if dependency('threads')
would ever find anything, or defining HAVE_PTHREAD has any effect, but avoid
defining it there, just in case.

Signed-off-by: Jon Turney 
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 84c0e102737..a0dd02b1f64 100644
--- a/meson.build
+++ b/meson.build
@@ -668,7 +668,7 @@ endif
 # TODO: some of these may be conditional
 dep_zlib = dependency('zlib', version : '>= 1.2.3')
 dep_thread = dependency('threads')
-if dep_thread.found() and host_machine.system() == 'linux'
+if dep_thread.found() and host_machine.system() != 'windows'
   pre_args += '-DHAVE_PTHREAD'
 endif
 dep_elf = dependency('libelf', required : false)
-- 
2.15.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] ac/nir: don't write tcs outputs to LDS that aren't read back.

2017-11-15 Thread Nicolai Hähnle

On 14.11.2017 06:18, Dave Airlie wrote:

From: Dave Airlie 

If the TCS doesn't read back the outputs, no need to store them
to LDS in the first place. (except for tess factors).

This seems to give about 50fps (3290->3330) with tessellation demo.

I haven't tested if it impacts DoW3 at all.

Signed-off-by: Dave Airlie 


Reviewed-by: Nicolai Hähnle 


---
  src/amd/common/ac_nir_to_llvm.c | 17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 3d9f613..e7133ec 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -150,6 +150,9 @@ struct nir_to_llvm_context {
unsigned tes_primitive_mode;
uint64_t tess_outputs_written;
uint64_t tess_patch_outputs_written;
+
+   uint32_t tcs_patch_outputs_read;
+   uint64_t tcs_outputs_read;
  };
  
  static inline struct nir_to_llvm_context *

@@ -2790,7 +2793,15 @@ store_tcs_output(struct nir_to_llvm_context *ctx,
const unsigned comp = instr->variables[0]->var->data.location_frac;
const bool per_vertex = nir_is_per_vertex_io(instr->variables[0]->var, 
ctx->stage);
const bool is_compact = instr->variables[0]->var->data.compact;
+   bool store_lds = true;
  
+	if (instr->variables[0]->var->data.patch) {

+   if (!(ctx->tcs_patch_outputs_read & (1U << 
instr->variables[0]->var->data.location)))
+   store_lds = false;
+   } else {
+   if (!(ctx->tcs_outputs_read & (1ULL << 
instr->variables[0]->var->data.location)))
+   store_lds = false;
+   }
get_deref_offset(ctx->nir, instr->variables[0],
 false, NULL, per_vertex ? _index : NULL,
 _index, _index);
@@ -2827,7 +2838,8 @@ store_tcs_output(struct nir_to_llvm_context *ctx,
continue;
LLVMValueRef value = llvm_extract_elem(>ac, src, chan - 
comp);
  
-		ac_lds_store(>ac, dw_addr, value);

+   if (store_lds || is_tess_factor)
+   ac_lds_store(>ac, dw_addr, value);
  
  		if (!is_tess_factor && writemask != 0xF)

ac_build_buffer_store_dword(>ac, 
ctx->hs_ring_tess_offchip, value, 1,
@@ -6550,6 +6562,9 @@ LLVMModuleRef 
ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,
ctx.gs_next_vertex = ac_build_alloca(, ctx.ac.i32, 
"gs_next_vertex");
  
  			ctx.gs_max_out_vertices = shaders[i]->info.gs.vertices_out;

+   } else if (shaders[i]->info.stage == MESA_SHADER_TESS_CTRL) {
+   ctx.tcs_outputs_read = shaders[i]->info.outputs_read;
+   ctx.tcs_patch_outputs_read = 
shaders[i]->info.patch_outputs_read;
} else if (shaders[i]->info.stage == MESA_SHADER_TESS_EVAL) {
ctx.tes_primitive_mode = 
shaders[i]->info.tess.primitive_mode;
} else if (shaders[i]->info.stage == MESA_SHADER_VERTEX) {




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Initial GS NIR support for radeonsi

2017-11-15 Thread Timothy Arceri

On 15/11/17 22:06, Nicolai Hähnle wrote:

On 10.11.2017 04:13, Timothy Arceri wrote:

The support is still WIP but the patches as starting to pile
up so thought I'd see if I could land these before continuing.


Thanks for working on this!



Whats missing?

Vega support for gs_vtx_offset handling (see patch 3), I don't
have one yet for testing so didn't attempt to adapt the code.


The existing code should work though, right? It's actually not clear to 
me what patch 3 is really trying to achieve, since the caller provides a 
plain integer vertex index either way. It's a nice cleanup though.


The nir to llvm path accesses these via an array index (expecting no 
gaps) we just need to update the Vega path to use an array also.






Lots of piglit tests still fail. The gs clip distance piglit
tests currently cause my system to hang for instance.


This is usually a mismatch/disagreement between SPI_SHADER_POS_FORMAT 
and PA_CL_VS_OUT_CNTL: the PA tries to pull more data from the position 
cache than is allocated there by the SPI, and the hardware gets 
permanently confused. Probably something in the setup for the GS copy 
shader needs to be fixed.


Yeah I'm got this fixed now.



The series looks pretty good already. I'd second Marek's comments, and I 
think the load_inputs ABI should be reworked to not depend on NIR; I've 
sent a comment on patch 17 for this.


I've sent a reply I think you missed what I'm trying to work around there :)



Patches 2-4, 8, 14-16, 18 and 19:


Thanks.



Reviewed-by: Nicolai Hähnle 

Cheers,
Nicolai

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] nir: fill outputs_read field and add patch outputs read

2017-11-15 Thread Nicolai Hähnle

On 14.11.2017 06:18, Dave Airlie wrote:

From: Dave Airlie 

This is to be used for TCS optimisations on radv.
---
  src/compiler/nir/nir_gather_info.c | 29 ++---
  src/compiler/shader_info.h |  2 ++
  2 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/src/compiler/nir/nir_gather_info.c 
b/src/compiler/nir/nir_gather_info.c
index 13cdae3..ab2d519 100644
--- a/src/compiler/nir/nir_gather_info.c
+++ b/src/compiler/nir/nir_gather_info.c
@@ -25,7 +25,8 @@
  #include "nir.h"
  
  static void

-set_io_mask(nir_shader *shader, nir_variable *var, int offset, int len)
+set_io_mask(nir_shader *shader, nir_variable *var, int offset, int len,
+bool is_output_read)
  {
 for (int i = 0; i < len; i++) {
assert(var->data.location != -1);
@@ -64,6 +65,14 @@ set_io_mask(nir_shader *shader, nir_variable *var, int 
offset, int len)
  shader->info.outputs_written |= bitfield;
   }
  
+ if (is_output_read) {

+if (is_patch_generic) {
+   shader->info.patch_outputs_read |= bitfield;
+} else {
+   shader->info.outputs_read |= bitfield;
+}
+ }


This should probably not set {patch_}outputs_written when is_output_read 
== true...


Cheers,
Nicolai



+
   if (var->data.fb_fetch_output)
  shader->info.outputs_read |= bitfield;
}
@@ -75,7 +84,7 @@ set_io_mask(nir_shader *shader, nir_variable *var, int 
offset, int len)
   * represents a shader input or output.
   */
  static void
-mark_whole_variable(nir_shader *shader, nir_variable *var)
+mark_whole_variable(nir_shader *shader, nir_variable *var, bool is_output_read)
  {
 const struct glsl_type *type = var->type;
  
@@ -88,7 +97,7 @@ mark_whole_variable(nir_shader *shader, nir_variable *var)

var->data.compact ? DIV_ROUND_UP(glsl_get_length(type), 4)
  : glsl_count_attribute_slots(type, false);
  
-   set_io_mask(shader, var, 0, slots);

+   set_io_mask(shader, var, 0, slots, is_output_read);
  }
  
  static unsigned

@@ -124,7 +133,7 @@ get_io_offset(nir_deref_var *deref)
   * occurs, then nothing will be marked and false will be returned.
   */
  static bool
-try_mask_partial_io(nir_shader *shader, nir_deref_var *deref)
+try_mask_partial_io(nir_shader *shader, nir_deref_var *deref, bool 
is_output_read)
  {
 nir_variable *var = deref->var;
 const struct glsl_type *type = var->type;
@@ -186,7 +195,7 @@ try_mask_partial_io(nir_shader *shader, nir_deref_var 
*deref)
return false;
 }
  
-   set_io_mask(shader, var, offset, elem_width);

+   set_io_mask(shader, var, offset, elem_width, is_output_read);
 return true;
  }
  
@@ -209,8 +218,13 @@ gather_intrinsic_info(nir_intrinsic_instr *instr, nir_shader *shader)
  
if (var->data.mode == nir_var_shader_in ||

var->data.mode == nir_var_shader_out) {
- if (!try_mask_partial_io(shader, instr->variables[0]))
-mark_whole_variable(shader, var);
+ bool is_output_read = false;
+ if (var->data.mode == nir_var_shader_out &&
+ instr->intrinsic == nir_intrinsic_load_var)
+is_output_read = true;
+
+ if (!try_mask_partial_io(shader, instr->variables[0], is_output_read))
+mark_whole_variable(shader, var, is_output_read);
  
   /* We need to track which input_reads bits correspond to a

* dvec3/dvec4 input attribute */
@@ -339,6 +353,7 @@ nir_shader_gather_info(nir_shader *shader, 
nir_function_impl *entrypoint)
 shader->info.inputs_read = 0;
 shader->info.outputs_written = 0;
 shader->info.outputs_read = 0;
+   shader->info.patch_outputs_read = 0;
 shader->info.double_inputs_read = 0;
 shader->info.patch_inputs_read = 0;
 shader->info.patch_outputs_written = 0;
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 5f14ad1..bcb3f0f 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -66,6 +66,8 @@ typedef struct shader_info {
 uint32_t patch_inputs_read;
 /* Which patch outputs are actually written */
 uint32_t patch_outputs_written;
+   /* Which patch outputs are read */
+   uint32_t patch_outputs_read;
  
 /* Whether or not this shader ever uses textureGather() */

 bool uses_texture_gather;




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] threads: fix MinGW build breakage

2017-11-15 Thread Nicolai Hähnle

On 15.11.2017 12:30, Jon Turney wrote:

On 15/11/2017 11:21, Nicolai Hähnle wrote:

On 13.11.2017 23:55, Rob Herring wrote:

On Fri, Nov 10, 2017 at 12:39 PM, Jon Turney
 wrote:

On 10/11/2017 15:42, Nicolai Hähnle wrote:


On 10.11.2017 14:00, Jon Turney wrote:


On 09/11/2017 21:41, Nicolai Hähnle wrote:


Sorry for the mess.



I'm going to suggest that the fallback declaration of 
timespec_get() also

needs to be provided for POSIX systems which don't have it.

Not noticed previously as it (or xtime_get()) doesn't seem to have 
had

any users, prior to this series.

Patch attached.



Do you have a system where this is actually needed? Currently
HAVE_TIMESPEC_GET is only defined in threads_win32.h, so some more 
detection
logic somewhere would be required if this actually turns out to be 
an issue.



Hmm.. yes, I'd assumed that HAVE_TIMESPEC_GET was the result of an 
autoconf

check, but it isn't.

Cygwin doesn't (currently) have timespec_get().

I'm thinking the correct solution here is actually to unconditionally
declare timespec_get(), just like all the other C11 thread functions 
(and as

the unused xtime_get() was, prior to
f1a364878431c8c5f4fd38b40b9766449e49f552)?

Revised patch attached.


That should fix Android builds.

Acked-by: Rob Herring 


The issue with this is that it makes the compiler unhappy when 
timespec_get *is* available. I'm looking at adding a configure check. 


Ah, and this doesn't effect the other C11 emulation functions in this 
header because we don't include threads.h, but we do include time.h?


Right.
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] r600 evergreen+ shader image support

2017-11-15 Thread Gert Wollny
Am Mittwoch, den 15.11.2017, 10:11 +1000 schrieb Dave Airlie:
> 
> It's not 100% on piglits, but it's quite close, and better than fglrx
> does, so I'd probably prefer to land it before doing too much more
> destructive hacking on it!

I ran the piglits shader set on barts - no regressions, and all the
newly tested piglits pass, i.e. 

   basic-imagestore-const-uniform-index
   basic-imagestore-mixed-const-non-const-uniform-index
   basic-imagestore-mixed-const-non-const-uniform-index2
   basic-imagestore-non-const-uniform-index
   arb_shader_image_load_store
   basic-imagestore-from-uniform
   disable_early_z
   image_checkerboard
   load-from-cleared-image
   write-to-rendered-image
   arb_shading_language_420pack
   different-bindings-image2d
  

For the series: 

  Tested-By: Gert Wollny  

Best, 
Gert 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Initial GS NIR support for radeonsi

2017-11-15 Thread Nicolai Hähnle

On 10.11.2017 04:13, Timothy Arceri wrote:

The support is still WIP but the patches as starting to pile
up so thought I'd see if I could land these before continuing.


Thanks for working on this!



Whats missing?

Vega support for gs_vtx_offset handling (see patch 3), I don't
have one yet for testing so didn't attempt to adapt the code.


The existing code should work though, right? It's actually not clear to 
me what patch 3 is really trying to achieve, since the caller provides a 
plain integer vertex index either way. It's a nice cleanup though.




Lots of piglit tests still fail. The gs clip distance piglit
tests currently cause my system to hang for instance.


This is usually a mismatch/disagreement between SPI_SHADER_POS_FORMAT 
and PA_CL_VS_OUT_CNTL: the PA tries to pull more data from the position 
cache than is allocated there by the SPI, and the hardware gets 
permanently confused. Probably something in the setup for the GS copy 
shader needs to be fixed.


The series looks pretty good already. I'd second Marek's comments, and I 
think the load_inputs ABI should be reworked to not depend on NIR; I've 
sent a comment on patch 17 for this.


Patches 2-4, 8, 14-16, 18 and 19:

Reviewed-by: Nicolai Hähnle 

Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 17/20] ac: add si_nir_load_input_gs() to the abi

2017-11-15 Thread Timothy Arceri



On 15/11/17 21:56, Nicolai Hähnle wrote:

On 10.11.2017 04:13, Timothy Arceri wrote:

---
  src/amd/common/ac_nir_to_llvm.c   | 24 
-

  src/amd/common/ac_shader_abi.h    |  7 ++
  src/gallium/drivers/radeonsi/si_shader.c  |  1 +
  src/gallium/drivers/radeonsi/si_shader_internal.h |  5 +
  src/gallium/drivers/radeonsi/si_shader_nir.c  | 26 
+++

  5 files changed, 53 insertions(+), 10 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c 
b/src/amd/common/ac_nir_to_llvm.c

index 158e954fa8..483dd52b36 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2854,32 +2854,31 @@ load_tes_input(struct nir_to_llvm_context *ctx,
  buf_addr = LLVMBuildAdd(ctx->builder, buf_addr, comp_offset, "");
  result = ac_build_buffer_load(>ac, 
ctx->hs_ring_tess_offchip, instr->num_components, NULL,
    buf_addr, ctx->oc_lds, is_compact ? (4 * 
const_index) : 0, 1, 0, true, false);

  result = trim_vector(>ac, result, instr->num_components);
  result = LLVMBuildBitCast(ctx->builder, result, 
get_def_type(ctx->nir, >dest.ssa), "");

  return result;
  }
  static LLVMValueRef
-load_gs_input(struct nir_to_llvm_context *ctx,
-  nir_intrinsic_instr *instr)
+load_gs_input(struct ac_shader_abi *abi,
+  nir_intrinsic_instr *instr,
+  unsigned vertex_index,
+  unsigned const_index)
  {
-    LLVMValueRef indir_index, vtx_offset;
-    unsigned const_index;
+    struct nir_to_llvm_context *ctx = nir_to_llvm_context_from_abi(abi);
+    LLVMValueRef vtx_offset;
  LLVMValueRef args[9];
  unsigned param, vtx_offset_param;
  LLVMValueRef value[4], result;
-    unsigned vertex_index;
-    get_deref_offset(ctx->nir, instr->variables[0],
- false, _index, NULL,
- _index, _index);
+
  vtx_offset_param = vertex_index;
  assert(vtx_offset_param < 6);
  vtx_offset = LLVMBuildMul(ctx->builder, 
ctx->gs_vtx_offset[vtx_offset_param],

    LLVMConstInt(ctx->ac.i32, 4, false), "");
  param = 
shader_io_get_unique_index(instr->variables[0]->var->data.location);

  unsigned comp = instr->variables[0]->var->data.location_frac;
  for (unsigned i = comp; i < instr->num_components + comp; i++) {
  if (ctx->ac.chip_class >= GFX9) {
@@ -2966,21 +2965,26 @@ static LLVMValueRef visit_load_var(struct 
ac_nir_context *ctx,

  if (instr->dest.ssa.bit_size == 64)
  ve *= 2;
  switch (instr->variables[0]->var->data.mode) {
  case nir_var_shader_in:
  if (ctx->stage == MESA_SHADER_TESS_CTRL)
  return load_tcs_input(ctx->nctx, instr);
  if (ctx->stage == MESA_SHADER_TESS_EVAL)
  return load_tes_input(ctx->nctx, instr);
  if (ctx->stage == MESA_SHADER_GEOMETRY) {
-    return load_gs_input(ctx->nctx, instr);
+    LLVMValueRef indir_index;
+    unsigned const_index, vertex_index;
+    get_deref_offset(ctx, instr->variables[0],
+ false, _index, NULL,
+ _index, _index);


The indentation looks wrong here.


+    return ctx->abi->load_inputs(ctx->abi, instr, 
vertex_index, const_index);

  }
  for (unsigned chan = comp; chan < ve + comp; chan++) {
  if (indir_index) {
  unsigned count = glsl_count_attribute_slots(
  instr->variables[0]->var->type,
  ctx->stage == MESA_SHADER_VERTEX);
  count -= chan / 4;
  LLVMValueRef tmp_vec = ac_build_gather_values_extended(
  >ac, ctx->abi->inputs + idx + chan, count,
@@ -6489,22 +6493,22 @@ LLVMModuleRef 
ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,

  for(int i = 0; i < shader_count; ++i) {
  ctx.stage = shaders[i]->info.stage;
  ctx.output_mask = 0;
  ctx.tess_outputs_written = 0;
  ctx.num_output_clips = 
shaders[i]->info.clip_distance_array_size;
  ctx.num_output_culls = 
shaders[i]->info.cull_distance_array_size;

  if (shaders[i]->info.stage == MESA_SHADER_GEOMETRY) {
  ctx.gs_next_vertex = ac_build_alloca(, 
ctx.ac.i32, "gs_next_vertex");

-
  ctx.gs_max_out_vertices = shaders[i]->info.gs.vertices_out;
+    ctx.abi.load_inputs = load_gs_input;
  } else if (shaders[i]->info.stage == MESA_SHADER_TESS_EVAL) {
  ctx.tes_primitive_mode = 
shaders[i]->info.tess.primitive_mode;

  } else if (shaders[i]->info.stage == MESA_SHADER_VERTEX) {
  if (shader_info->info.vs.needs_instance_id) {
  ctx.shader_info->vs.vgpr_comp_cnt =
  MAX2(3, ctx.shader_info->vs.vgpr_comp_cnt);
  }
  } else if (shaders[i]->info.stage == MESA_SHADER_FRAGMENT) {
  

[Mesa-dev] [PATCH] radv: use a 16 bytes array for the sampled/storage image descriptors

2017-11-15 Thread Samuel Pitoiset
This allows to update them with only one memcpy().

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_descriptor_set.c | 9 +
 src/amd/vulkan/radv_image.c  | 5 +
 src/amd/vulkan/radv_private.h| 6 ++
 3 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/src/amd/vulkan/radv_descriptor_set.c 
b/src/amd/vulkan/radv_descriptor_set.c
index a98ff37ced..382fc9330a 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/src/amd/vulkan/radv_descriptor_set.c
@@ -629,15 +629,16 @@ write_image_descriptor(struct radv_device *device,
   const VkDescriptorImageInfo *image_info)
 {
RADV_FROM_HANDLE(radv_image_view, iview, image_info->imageView);
+   uint32_t *descriptor;
 
if (descriptor_type == VK_DESCRIPTOR_TYPE_STORAGE_IMAGE) {
-   memcpy(dst, iview->storage_descriptor, 8 * 4);
-   memcpy(dst + 8, iview->storage_fmask_descriptor, 8 * 4);
+   descriptor = iview->storage_descriptor;
} else {
-   memcpy(dst, iview->descriptor, 8 * 4);
-   memcpy(dst + 8, iview->fmask_descriptor, 8 * 4);
+   descriptor = iview->descriptor;
}
 
+   memcpy(dst, descriptor, 16 * 4);
+
if (cmd_buffer)
radv_cs_add_buffer(device->ws, cmd_buffer->cs, iview->bo, 7);
else
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 163d35d76b..b532aa916a 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -956,15 +956,12 @@ radv_image_view_make_descriptor(struct radv_image_view 
*iview,
bool is_stencil = iview->aspect_mask == VK_IMAGE_ASPECT_STENCIL_BIT;
uint32_t blk_w;
uint32_t *descriptor;
-   uint32_t *fmask_descriptor;
uint32_t hw_level = 0;
 
if (is_storage_image) {
descriptor = iview->storage_descriptor;
-   fmask_descriptor = iview->storage_fmask_descriptor;
} else {
descriptor = iview->descriptor;
-   fmask_descriptor = iview->fmask_descriptor;
}
 
assert(image->surface.blk_w % 
vk_format_get_blockwidth(image->vk_format) == 0);
@@ -983,7 +980,7 @@ radv_image_view_make_descriptor(struct radv_image_view 
*iview,
   iview->extent.height,
   iview->extent.depth,
   descriptor,
-  fmask_descriptor);
+  descriptor + 8);
 
const struct legacy_surf_level *base_level_info = NULL;
if (device->physical_device->rad_info.chip_class <= GFX9) {
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 5be3f47b46..5a59012a28 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1370,14 +1370,12 @@ struct radv_image_view {
uint32_t level_count;
VkExtent3D extent; /**< Extent of VkImageViewCreateInfo::baseMipLevel. 
*/
 
-   uint32_t descriptor[8];
-   uint32_t fmask_descriptor[8];
+   uint32_t descriptor[16];
 
/* Descriptor for use as a storage image as opposed to a sampled image.
 * This has a few differences for cube maps (e.g. type).
 */
-   uint32_t storage_descriptor[8];
-   uint32_t storage_fmask_descriptor[8];
+   uint32_t storage_descriptor[16];
 };
 
 struct radv_image_create_info {
-- 
2.15.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] threads: fix MinGW build breakage

2017-11-15 Thread Nicolai Hähnle

On 13.11.2017 23:55, Rob Herring wrote:

On Fri, Nov 10, 2017 at 12:39 PM, Jon Turney
 wrote:

On 10/11/2017 15:42, Nicolai Hähnle wrote:


On 10.11.2017 14:00, Jon Turney wrote:


On 09/11/2017 21:41, Nicolai Hähnle wrote:


Sorry for the mess.



I'm going to suggest that the fallback declaration of timespec_get() also
needs to be provided for POSIX systems which don't have it.

Not noticed previously as it (or xtime_get()) doesn't seem to have had
any users, prior to this series.

Patch attached.



Do you have a system where this is actually needed? Currently
HAVE_TIMESPEC_GET is only defined in threads_win32.h, so some more detection
logic somewhere would be required if this actually turns out to be an issue.



Hmm.. yes, I'd assumed that HAVE_TIMESPEC_GET was the result of an autoconf
check, but it isn't.

Cygwin doesn't (currently) have timespec_get().

I'm thinking the correct solution here is actually to unconditionally
declare timespec_get(), just like all the other C11 thread functions (and as
the unused xtime_get() was, prior to
f1a364878431c8c5f4fd38b40b9766449e49f552)?

Revised patch attached.


That should fix Android builds.

Acked-by: Rob Herring 


The issue with this is that it makes the compiler unhappy when 
timespec_get *is* available. I'm looking at adding a configure check.


Cheers,
Nicolai



Rob




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v2 1/3] radeonsi: add nir support for ls epilogue

2017-11-15 Thread Timothy Arceri
v2: make use of existing si_tgsi_emit_epilogue()
---
 src/gallium/drivers/radeonsi/si_shader.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 3293dd44c6..a64f0d69a6 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1106,27 +1106,25 @@ static LLVMValueRef lds_load(struct 
lp_build_tgsi_context *bld_base,
return bitcast(bld_base, type, value);
 }
 
 /**
  * Store to LDS.
  *
  * \param swizzle  offset (typically 0..3)
  * \param dw_addr  address in dwords
  * \param valuevalue to store
  */
-static void lds_store(struct lp_build_tgsi_context *bld_base,
+static void lds_store(struct si_shader_context *ctx,
  unsigned dw_offset_imm, LLVMValueRef dw_addr,
  LLVMValueRef value)
 {
-   struct si_shader_context *ctx = si_shader_context(bld_base);
-
-   dw_addr = lp_build_add(_base->uint_bld, dw_addr,
+   dw_addr = lp_build_add(>bld_base.uint_bld, dw_addr,
LLVMConstInt(ctx->i32, dw_offset_imm, 0));
 
ac_lds_store(>ac, dw_addr, value);
 }
 
 static LLVMValueRef desc_from_addr_base64k(struct si_shader_context *ctx,
  unsigned param)
 {
LLVMBuilderRef builder = ctx->ac.builder;
 
@@ -1258,21 +1256,21 @@ static void store_output_tcs(struct 
lp_build_tgsi_context *bld_base,
uint32_t writemask = reg->Register.WriteMask;
while (writemask) {
chan_index = u_bit_scan();
LLVMValueRef value = dst[chan_index];
 
if (inst->Instruction.Saturate)
value = ac_build_clamp(>ac, value);
 
/* Skip LDS stores if there is no LDS read of this output. */
if (!skip_lds_store)
-   lds_store(bld_base, chan_index, dw_addr, value);
+   lds_store(ctx, chan_index, dw_addr, value);
 
value = ac_to_integer(>ac, value);
values[chan_index] = value;
 
if (reg->Register.WriteMask != 0xF && !is_tess_factor) {
ac_build_buffer_store_dword(>ac, buffer, value, 1,
buf_addr, base,
4 * chan_index, 1, 0, true, 
false);
}
 
@@ -3126,36 +3124,37 @@ static void si_set_es_return_value_for_gs(struct 
si_shader_context *ctx)
   8 + 
GFX9_SGPR_GS_SAMPLERS_AND_IMAGES);
 
unsigned vgpr = 8 + GFX9_GS_NUM_USER_SGPR;
for (unsigned i = 0; i < 5; i++) {
unsigned param = ctx->param_gs_vtx01_offset + i;
ret = si_insert_input_ret_float(ctx, ret, param, vgpr++);
}
ctx->return_value = ret;
 }
 
-static void si_llvm_emit_ls_epilogue(struct lp_build_tgsi_context *bld_base)
+static void si_llvm_emit_ls_epilogue(struct ac_shader_abi *abi,
+unsigned max_outputs,
+LLVMValueRef *addrs)
 {
-   struct si_shader_context *ctx = si_shader_context(bld_base);
+   struct si_shader_context *ctx = si_shader_context_from_abi(abi);
struct si_shader *shader = ctx->shader;
struct tgsi_shader_info *info = >selector->info;
unsigned i, chan;
LLVMValueRef vertex_id = LLVMGetParam(ctx->main_fn,
  ctx->param_rel_auto_id);
LLVMValueRef vertex_dw_stride = get_tcs_in_vertex_dw_stride(ctx);
LLVMValueRef base_dw_addr = LLVMBuildMul(ctx->ac.builder, vertex_id,
 vertex_dw_stride, "");
 
/* Write outputs to LDS. The next shader (TCS aka HS) will read
 * its inputs from it. */
for (i = 0; i < info->num_outputs; i++) {
-   LLVMValueRef *out_ptr = ctx->outputs[i];
unsigned name = info->output_semantic_name[i];
unsigned index = info->output_semantic_index[i];
 
/* The ARB_shader_viewport_layer_array spec contains the
 * following issue:
 *
 *2) What happens if gl_ViewportIndex or gl_Layer is
 *written in the vertex shader and a geometry shader is
 *present?
 *
@@ -3169,22 +3168,22 @@ static void si_llvm_emit_ls_epilogue(struct 
lp_build_tgsi_context *bld_base)
 */
if (name == TGSI_SEMANTIC_LAYER ||
name == TGSI_SEMANTIC_VIEWPORT_INDEX)
continue;
 
int param = si_shader_io_get_unique_index(name, index);
LLVMValueRef dw_addr = LLVMBuildAdd(ctx->ac.builder, 
base_dw_addr,
 

[Mesa-dev] [Bug 103658] addrlib/gfx9/gfx9addrlib.cpp:727:50: error: expected expression

2017-11-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103658

--- Comment #3 from Nicolai Hähnle  ---
Created attachment 135484
  --> https://bugs.freedesktop.org/attachment.cgi?id=135484=edit
build addrlib with C++11

Does the attached patch help?

-- 
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.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] amd: build addrlib with C++11

2017-11-15 Thread Nicolai Hähnle
From: Nicolai Hähnle 

It is required for LLVM anyway.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103658
Fixes: 7f33e94e43a6 ("amd/addrlib: update to latest version")
---
 src/amd/Makefile.addrlib.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am
index 46689637f9b..90dfe963445 100644
--- a/src/amd/Makefile.addrlib.am
+++ b/src/amd/Makefile.addrlib.am
@@ -26,15 +26,15 @@ addrlib_libamdgpu_addrlib_la_CPPFLAGS = \
-I$(srcdir)/common \
-I$(srcdir)/addrlib \
-I$(srcdir)/addrlib/core \
-I$(srcdir)/addrlib/inc/chip/gfx9 \
-I$(srcdir)/addrlib/inc/chip/r800 \
-I$(srcdir)/addrlib/gfx9/chip \
-I$(srcdir)/addrlib/r800/chip \
-DBRAHMA_BUILD=1
 
 addrlib_libamdgpu_addrlib_la_CXXFLAGS = \
-   $(VISIBILITY_CXXFLAGS)
+   $(VISIBILITY_CXXFLAGS) $(CXX11_CXXFLAGS)
 
 noinst_LTLIBRARIES += $(ADDRLIB_LIBS)
 
 addrlib_libamdgpu_addrlib_la_SOURCES = $(ADDRLIB_FILES)
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

2017-11-15 Thread Nicolai Hähnle
From: Nicolai Hähnle 

Cc: Jon Turney 
Cc: Rob Herring 
Cc: Alexander von Gluck IV 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11 changes")
---
 configure.ac| 1 +
 include/c11/threads_posix.h | 2 +-
 meson.build | 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 411c4f6b3e0..a7ae920ab9c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -841,20 +841,21 @@ if test "x$enable_asm" = xyes; then
 AC_MSG_RESULT([no, platform not supported])
 ;;
 esac
 fi
 
 AC_HEADER_MAJOR
 AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
 AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
 AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
 AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
+AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
 
 AC_MSG_CHECKING([whether strtod has locale support])
 AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #define _GNU_SOURCE
 #include 
 #include 
 #ifdef HAVE_XLOCALE_H
 #include 
 #endif
 int main() {
diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
index 2d7ac1326de..45cb6075e6e 100644
--- a/include/c11/threads_posix.h
+++ b/include/c11/threads_posix.h
@@ -375,21 +375,21 @@ tss_get(tss_t key)
 // 7.25.6.4
 static inline int
 tss_set(tss_t key, void *val)
 {
 return (pthread_setspecific(key, val) == 0) ? thrd_success : thrd_error;
 }
 
 
 /* 7.25.7 Time functions */
 // 7.25.6.1
-#ifdef __HAIKU__
+#ifndef HAVE_TIMESPEC_GET
 static inline int
 timespec_get(struct timespec *ts, int base)
 {
 if (!ts) return 0;
 if (base == TIME_UTC) {
 clock_gettime(CLOCK_REALTIME, ts);
 return base;
 }
 return 0;
 }
diff --git a/meson.build b/meson.build
index 1c4200705f3..7fdc3c280e6 100644
--- a/meson.build
+++ b/meson.build
@@ -571,21 +571,21 @@ if cc.has_header_symbol('sys/sysmacros.h', 'major')
 elif cc.has_header_symbol('sys/mkdev.h', 'major')
   pre_args += '-DMAJOR_IN_MKDEV'
 endif
 
 foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h']
   if cc.has_header(h)
 pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
   endif
 endforeach
 
-foreach f : ['strtof', 'mkostemp', 'posix_memalign']
+foreach f : ['strtof', 'mkostemp', 'posix_memalign', 'timespec_get']
   if cc.has_function(f)
 pre_args += '-DHAVE_@0@'.format(f.to_upper())
   endif
 endforeach
 
 # strtod locale support
 if cc.links('''
 #define _GNU_SOURCE
 #include 
 #include 
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radeonsi/gfx9: fix VM fault with fetched instance divisors

2017-11-15 Thread Nicolai Hähnle
From: Nicolai Hähnle 

We need to account for SGPR locations in merged shaders.

This case is exercised by KHR-GL45.enhanced_layouts.vertex_attrib_locations

Fixes: 79c2e7388c7f ("radeonsi/gfx9: use SPI_SHADER_USER_DATA_COMMON")
---
 src/gallium/drivers/radeonsi/si_shader.c | 13 +++--
 src/gallium/drivers/radeonsi/si_shader.h |  4 +---
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 3293dd44c63..281449e9eeb 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -5878,25 +5878,27 @@ static void si_get_vs_prolog_key(const struct 
tgsi_shader_info *info,
 unsigned num_input_sgprs,
 const struct si_vs_prolog_bits *prolog_key,
 struct si_shader *shader_out,
 union si_shader_part_key *key)
 {
memset(key, 0, sizeof(*key));
key->vs_prolog.states = *prolog_key;
key->vs_prolog.num_input_sgprs = num_input_sgprs;
key->vs_prolog.last_input = MAX2(1, info->num_inputs) - 1;
key->vs_prolog.as_ls = shader_out->key.as_ls;
+   key->vs_prolog.as_es = shader_out->key.as_es;
 
if (shader_out->selector->type == PIPE_SHADER_TESS_CTRL) {
key->vs_prolog.as_ls = 1;
key->vs_prolog.num_merged_next_stage_vgprs = 2;
} else if (shader_out->selector->type == PIPE_SHADER_GEOMETRY) {
+   key->vs_prolog.as_es = 1;
key->vs_prolog.num_merged_next_stage_vgprs = 5;
}
 
/* Enable loading the InstanceID VGPR. */
uint16_t input_mask = u_bit_consecutive(0, info->num_inputs);
 
if ((key->vs_prolog.states.instance_divisor_is_one |
 key->vs_prolog.states.instance_divisor_is_fetched) & input_mask)
shader_out->info.uses_instanceid = true;
 }
@@ -6763,20 +6765,22 @@ si_get_shader_part(struct si_screen *sscreen,
 
struct si_shader shader = {};
struct si_shader_context ctx;
 
si_init_shader_ctx(, sscreen, tm);
ctx.shader = 
ctx.type = type;
 
switch (type) {
case PIPE_SHADER_VERTEX:
+   shader.key.as_ls = key->vs_prolog.as_ls;
+   shader.key.as_es = key->vs_prolog.as_es;
break;
case PIPE_SHADER_TESS_CTRL:
assert(!prolog);
shader.key.part.tcs.epilog = key->tcs_epilog.states;
break;
case PIPE_SHADER_GEOMETRY:
assert(prolog);
break;
case PIPE_SHADER_FRAGMENT:
if (prolog)
@@ -6805,24 +6809,29 @@ si_get_shader_part(struct si_screen *sscreen,
 
 out:
si_llvm_dispose();
mtx_unlock(>shader_parts_mutex);
return result;
 }
 
 static LLVMValueRef si_prolog_get_rw_buffers(struct si_shader_context *ctx)
 {
LLVMValueRef ptr[2], list;
+   bool is_merged_shader =
+   ctx->screen->b.chip_class >= GFX9 &&
+   (ctx->type == PIPE_SHADER_TESS_CTRL ||
+ctx->type == PIPE_SHADER_GEOMETRY ||
+ctx->shader->key.as_ls || ctx->shader->key.as_es);
 
/* Get the pointer to rw buffers. */
-   ptr[0] = LLVMGetParam(ctx->main_fn, SI_SGPR_RW_BUFFERS);
-   ptr[1] = LLVMGetParam(ctx->main_fn, SI_SGPR_RW_BUFFERS_HI);
+   ptr[0] = LLVMGetParam(ctx->main_fn, (is_merged_shader ? 8 : 0) + 
SI_SGPR_RW_BUFFERS);
+   ptr[1] = LLVMGetParam(ctx->main_fn, (is_merged_shader ? 8 : 0) + 
SI_SGPR_RW_BUFFERS_HI);
list = lp_build_gather_values(>gallivm, ptr, 2);
list = LLVMBuildBitCast(ctx->ac.builder, list, ctx->i64, "");
list = LLVMBuildIntToPtr(ctx->ac.builder, list,
 si_const_array(ctx->v4i32, SI_NUM_RW_BUFFERS), 
"");
return list;
 }
 
 /**
  * Build the vertex shader prolog function.
  *
diff --git a/src/gallium/drivers/radeonsi/si_shader.h 
b/src/gallium/drivers/radeonsi/si_shader.h
index 41851627a87..148356b87ff 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -142,23 +142,20 @@ struct nir_shader;
 
 #define SI_MAX_VS_OUTPUTS  40
 
 /* Shader IO unique indices are supported for TGSI_SEMANTIC_GENERIC with an
  * index smaller than this.
  */
 #define SI_MAX_IO_GENERIC   46
 
 /* SGPR user data indices */
 enum {
-   /* GFX9 merged shaders have RW_BUFFERS among the first 8 system SGPRs,
-* and these two are used for other purposes.
-*/
SI_SGPR_RW_BUFFERS,  /* rings (& stream-out, VS only) */
SI_SGPR_RW_BUFFERS_HI,
SI_SGPR_BINDLESS_SAMPLERS_AND_IMAGES,
SI_SGPR_BINDLESS_SAMPLERS_AND_IMAGES_HI,
SI_SGPR_CONST_AND_SHADER_BUFFERS, /* or just a constant buffer 0 
pointer */

Re: [Mesa-dev] [PATCH 03/14] intel/blorp/blit: Rename blorp_nir_txf_ms_mcs

2017-11-15 Thread Lionel Landwerlin

I thought I sent a Rb on this one...

Reviewed-by: Lionel Landwerlin 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v5 00/10] new series of Mesa for Tizen

2017-11-15 Thread Nicolai Hähnle
Not sure if it's just my client, but all the nice ASCII art got messed 
up unfortunately :/


On 14.11.2017 21:21, Mun, Gwan-gyeong wrote:

   
+--+
   | [Tizen Window System Architecture]
   |
   |
   |
   |
   |
   |
   |
   |  +---+
++  ++  |
   |  | Enlightenment Display |   |
|  |   3D UI|  |
   |  |  Server for Tizen +-->|
EvasGL   |  |   Toolkit  |  |
   |  |   |   |


and so on...






* TBM:
- Tizen Buffer Manager (TBM) provides the abstraction interface for
the graphic buffer manager
  in Tizen. [1]

- Why does it needed?
  Because different vendors provides different user-level interface
for the memory manager,
  Tizen made TBM for supporting a common interface. refer [3], page 6-8.


So it would be possible for the TBM backend to just call into libgbm, right?

Cheers,
Nicolai





* TDM:
- TDM stands for Tizen Display Manager. Tizen Display Manager (TDM)
provides the display device
  abstraction interface for the display server to allow the direct
access to graphics hardware
  in a safe and efficient manner as a display HAL. The primary goal
of TDM is the unification
  of display hardware management procedures in user space. [2]

- Why does it needed?
  Because different vendors provides different user-level interface
for the display devices,
  Tizen made TDM for supporting a common interface. refer [3], page 15-16.


* wayland-tbm:
 - wayland-tbm is a protocol for graphics memory management for Tizen.
   The wayland-tbm provides the library for sharing the
tbm_surfaces between the client and the server.
   When the client creates the wl_buffer though the wayland-tbm
library, the client can gets
   the wl_buffer which is shared with the server through the wl_tbm 
protocol.

 - wayland-tbm suppots two major features
1) sharing the tbm_surfaces between the client and the server
   * it is similar with wayland-drm but it shares tbm_surface
as a base buffer.

2) obtaining the scanout buffer and assigning it to the server
or the client.
   * Because some vendor provide limited scanout buffers,
therefore tizen added a protocol
 of releasing/assigning scanoutbuffers.

   * non-compisite mode / direct rendering: obtaining scanout
buffer from display-server and
assigning it to the
wayland-egl client.
   * composite mode: obtaining the scanout buffer from the
wayland-egl client and assigning it
 to the display-server.


* TPL-EGL:
 - TPL-EGL is an abstraction layer for surface and buffer
management on Tizen platform aimed to
   implement the EGL porting layer of OpenGLES driver over various
display protocols.
   TPL-EGL treats tbm_surface as a base buffer object. And it uses
wayland-tbm protocol
   instead of wayland-drm for sharing buffers on wayland-egl.
   It supports tbm, wayland-egl, gbm window system.
   And tizen's enligthenment display server create egl_display from
tbm instead of gbm. [4],[5]


Compared to mesa, Tizen Platform depends on TBM, TDM, wayland-tbm protocol.
Tizen uses TBM for treating a native buffer. And Display manager uses
tbm_surface as a base buffer for displying.
And for sharing native buffers between display server and wayland-egl
client tizen uses wayland-tbm protocol
also wayland-tbm protocol/library provides a manners of managing
limited scanout buffers between the client and the server.
Therefore to support Tizen to mesa egl, I am suggesting to add new
window system code for Tizen.

Thanks for reading this far, comments welcome.

Thanks,

Gwan-gyeong.

[1] https://wiki.tizen.org/TBM
[2] https://wiki.tizen.org/TDM
[3] Tizen Buffer HAL and Tizen Display HAL
  
https://www.tizenconference.com/frontend/site/show-details?eventId=2612=session=21124
  https://swoogo.s3.amazonaws.com/uploads/46837-5926fd6b24dfd.pdf
[4] 
https://www.x.org/wiki/Events/XDC2016/Program/XDC2016_Tizen_Window_System_EGL_Vulkan.pdf
[5] https://wiki.tizen.org/3.0_Porting_Guide/Graphics_and_UI

2017-10-28 2:22 GMT+09:00 Kenneth Graunke :

On Thursday, October 26, 2017 11:16:06 AM PDT Eric Anholt wrote:

Gwan-gyeong Mun  writes:


Hi,

These Patch v5 series modified with new helper function series [1].

These series only have mesa for tizen feature.

[1] https://patchwork.freedesktop.org/series/32577/


Rather than have another giant pile of window system code in the tree,
I'd like to see a 

Re: [Mesa-dev] [PATCH 01/20] st/glsl_to_nir: disable io type lowering for stages other than vs and fs

2017-11-15 Thread Nicolai Hähnle

On 10.11.2017 04:13, Timothy Arceri wrote:

This is too simple and breaks gs and I'm not sure its required there
anyway.


Can you add an example for what breaks?

Thanks,
Nicolai



---
  src/mesa/state_tracker/st_glsl_to_nir.cpp | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 6c474cb718..d478725fbe 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -359,21 +359,24 @@ sort_varyings(struct exec_list *var_list)
   * variant lowering.
   */
  void
  st_finalize_nir(struct st_context *st, struct gl_program *prog,
  struct gl_shader_program *shader_program, nir_shader *nir)
  {
 struct pipe_screen *screen = st->pipe->screen;
  
 NIR_PASS_V(nir, nir_split_var_copies);

 NIR_PASS_V(nir, nir_lower_var_copies);
-   NIR_PASS_V(nir, nir_lower_io_types);
+
+   if (nir->info.stage == MESA_SHADER_VERTEX ||
+   nir->info.stage == MESA_SHADER_FRAGMENT)
+  NIR_PASS_V(nir, nir_lower_io_types);
  
 if (nir->info.stage == MESA_SHADER_VERTEX) {

/* Needs special handling so drvloc matches the vbo state: */
st_nir_assign_vs_in_locations(prog, nir);
/* Re-lower global vars, to deal with any dead VS inputs. */
NIR_PASS_V(nir, nir_lower_global_vars_to_local);
  
sort_varyings(>outputs);

nir_assign_var_locations(>outputs,
 >num_outputs,




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/20] st/glsl_to_nir: disable io type lowering for stages other than vs and fs

2017-11-15 Thread Timothy Arceri

On 15/11/17 21:39, Nicolai Hähnle wrote:

On 10.11.2017 04:13, Timothy Arceri wrote:

This is too simple and breaks gs and I'm not sure its required there
anyway.


Can you add an example for what breaks?


It breaks because it removes the outer array on gs inputs.

I have an updated series which makes use of the more fully featured 
array splitting pass from my nir linking series instead of this. It 
still needs some cleaning up but I hope to send out the new series 
sometime tomorrow.


https://github.com/tarceri/Mesa/compare/radeonsi_nir_v7




Thanks,
Nicolai



---
  src/mesa/state_tracker/st_glsl_to_nir.cpp | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp

index 6c474cb718..d478725fbe 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -359,21 +359,24 @@ sort_varyings(struct exec_list *var_list)
   * variant lowering.
   */
  void
  st_finalize_nir(struct st_context *st, struct gl_program *prog,
  struct gl_shader_program *shader_program, nir_shader 
*nir)

  {
 struct pipe_screen *screen = st->pipe->screen;
 NIR_PASS_V(nir, nir_split_var_copies);
 NIR_PASS_V(nir, nir_lower_var_copies);
-   NIR_PASS_V(nir, nir_lower_io_types);
+
+   if (nir->info.stage == MESA_SHADER_VERTEX ||
+   nir->info.stage == MESA_SHADER_FRAGMENT)
+  NIR_PASS_V(nir, nir_lower_io_types);
 if (nir->info.stage == MESA_SHADER_VERTEX) {
    /* Needs special handling so drvloc matches the vbo state: */
    st_nir_assign_vs_in_locations(prog, nir);
    /* Re-lower global vars, to deal with any dead VS inputs. */
    NIR_PASS_V(nir, nir_lower_global_vars_to_local);
    sort_varyings(>outputs);
    nir_assign_var_locations(>outputs,
 >num_outputs,





___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v2 2/3] radeonsi: add nir support for es epilogue

2017-11-15 Thread Timothy Arceri
v2: make use of existing si_tgsi_emit_epilogue()
---
 src/gallium/drivers/radeonsi/si_shader.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index a64f0d69a6..0c77739f20 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -3177,55 +3177,56 @@ static void si_llvm_emit_ls_epilogue(struct 
ac_shader_abi *abi,
for (chan = 0; chan < 4; chan++) {
lds_store(ctx, chan, dw_addr,
  LLVMBuildLoad(ctx->ac.builder, addrs[4 * i + 
chan], ""));
}
}
 
if (ctx->screen->b.chip_class >= GFX9)
si_set_ls_return_value_for_tcs(ctx);
 }
 
-static void si_llvm_emit_es_epilogue(struct lp_build_tgsi_context *bld_base)
+static void si_llvm_emit_es_epilogue(struct ac_shader_abi *abi,
+unsigned max_outputs,
+LLVMValueRef *addrs)
 {
-   struct si_shader_context *ctx = si_shader_context(bld_base);
+   struct si_shader_context *ctx = si_shader_context_from_abi(abi);
struct si_shader *es = ctx->shader;
struct tgsi_shader_info *info = >selector->info;
LLVMValueRef soffset = LLVMGetParam(ctx->main_fn,
ctx->param_es2gs_offset);
LLVMValueRef lds_base = NULL;
unsigned chan;
int i;
 
if (ctx->screen->b.chip_class >= GFX9 && info->num_outputs) {
unsigned itemsize_dw = es->selector->esgs_itemsize / 4;
LLVMValueRef vertex_idx = ac_get_thread_id(>ac);
LLVMValueRef wave_idx = unpack_param(ctx, 
ctx->param_merged_wave_info, 24, 4);
vertex_idx = LLVMBuildOr(ctx->ac.builder, vertex_idx,
 LLVMBuildMul(ctx->ac.builder, wave_idx,
  LLVMConstInt(ctx->i32, 
64, false), ""), "");
lds_base = LLVMBuildMul(ctx->ac.builder, vertex_idx,
LLVMConstInt(ctx->i32, itemsize_dw, 0), 
"");
}
 
for (i = 0; i < info->num_outputs; i++) {
-   LLVMValueRef *out_ptr = ctx->outputs[i];
int param;
 
if (info->output_semantic_name[i] == 
TGSI_SEMANTIC_VIEWPORT_INDEX ||
info->output_semantic_name[i] == TGSI_SEMANTIC_LAYER)
continue;
 
param = 
si_shader_io_get_unique_index(info->output_semantic_name[i],
  
info->output_semantic_index[i]);
 
for (chan = 0; chan < 4; chan++) {
-   LLVMValueRef out_val = LLVMBuildLoad(ctx->ac.builder, 
out_ptr[chan], "");
+   LLVMValueRef out_val = LLVMBuildLoad(ctx->ac.builder, 
addrs[4 * i + chan], "");
out_val = ac_to_integer(>ac, out_val);
 
/* GFX9 has the ESGS ring in LDS. */
if (ctx->screen->b.chip_class >= GFX9) {
lds_store(ctx, param * 4 + chan, lds_base, 
out_val);
continue;
}
 
ac_build_buffer_store_dword(>ac,
ctx->esgs_ring,
@@ -4422,21 +4423,20 @@ static void create_function(struct si_shader_context 
*ctx)
 
/* VGPRs */
declare_vs_input_vgprs(ctx, , _prolog_vgprs);
break;
}
 
declare_per_stage_desc_pointers(ctx, , true);
declare_vs_specific_input_sgprs(ctx, );
 
if (shader->key.as_es) {
-   assert(!shader->selector->nir);
ctx->param_es2gs_offset = add_arg(, ARG_SGPR, 
ctx->i32);
} else if (shader->key.as_ls) {
/* no extra parameters */
} else {
if (shader->is_gs_copy_shader) {
fninfo.num_params = ctx->param_rw_buffers + 1;
fninfo.num_sgpr_params = fninfo.num_params;
}
 
/* The locations of the other parameters are assigned 
dynamically. */
@@ -5729,44 +5729,41 @@ static bool si_compile_tgsi_main(struct 
si_shader_context *ctx,
 bool is_monolithic)
 {
struct si_shader *shader = ctx->shader;
struct si_shader_selector *sel = shader->selector;
struct lp_build_tgsi_context *bld_base = >bld_base;
 
// TODO clean all this up!
switch (ctx->type) {
case PIPE_SHADER_VERTEX:
ctx->load_input = declare_input_vs;
-   if 

[Mesa-dev] [PATCH v2 3/3] radeonsi: add nir support for gs epilogue

2017-11-15 Thread Timothy Arceri
v2: add emit_gs_epilogue() helper function to reduce duplication.
---
 src/gallium/drivers/radeonsi/si_shader.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 0c77739f20..a4a2041b93 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -3241,31 +3241,47 @@ static void si_llvm_emit_es_epilogue(struct 
ac_shader_abi *abi,
 }
 
 static LLVMValueRef si_get_gs_wave_id(struct si_shader_context *ctx)
 {
if (ctx->screen->b.chip_class >= GFX9)
return unpack_param(ctx, ctx->param_merged_wave_info, 16, 8);
else
return LLVMGetParam(ctx->main_fn, ctx->param_gs_wave_id);
 }
 
-static void si_llvm_emit_gs_epilogue(struct lp_build_tgsi_context *bld_base)
+static void emit_gs_epilogue(struct si_shader_context *ctx)
 {
-   struct si_shader_context *ctx = si_shader_context(bld_base);
-
ac_build_sendmsg(>ac, AC_SENDMSG_GS_OP_NOP | AC_SENDMSG_GS_DONE,
 si_get_gs_wave_id(ctx));
 
if (ctx->screen->b.chip_class >= GFX9)
lp_build_endif(>merged_wrap_if_state);
 }
 
+static void si_llvm_emit_gs_epilogue(struct ac_shader_abi *abi,
+unsigned max_outputs,
+LLVMValueRef *addrs)
+{
+   struct si_shader_context *ctx = si_shader_context_from_abi(abi);
+   struct tgsi_shader_info UNUSED *info = >shader->selector->info;
+
+   assert(info->num_outputs <= max_outputs);
+
+   emit_gs_epilogue(ctx);
+}
+
+static void si_tgsi_emit_gs_epilogue(struct lp_build_tgsi_context *bld_base)
+{
+   struct si_shader_context *ctx = si_shader_context(bld_base);
+   emit_gs_epilogue(ctx);
+}
+
 static void si_llvm_emit_vs_epilogue(struct ac_shader_abi *abi,
 unsigned max_outputs,
 LLVMValueRef *addrs)
 {
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
struct tgsi_shader_info *info = >shader->selector->info;
struct si_shader_output_values *outputs = NULL;
int i,j;
 
assert(!ctx->shader->is_gs_copy_shader);
@@ -5754,21 +5770,22 @@ static bool si_compile_tgsi_main(struct 
si_shader_context *ctx,
bld_base->emit_fetch_funcs[TGSI_FILE_INPUT] = fetch_input_tes;
if (shader->key.as_es)
ctx->abi.emit_outputs = si_llvm_emit_es_epilogue;
else
ctx->abi.emit_outputs = si_llvm_emit_vs_epilogue;
bld_base->emit_epilogue = si_tgsi_emit_epilogue;
break;
case PIPE_SHADER_GEOMETRY:
bld_base->emit_fetch_funcs[TGSI_FILE_INPUT] = fetch_input_gs;
ctx->abi.emit_vertex = si_llvm_emit_vertex;
-   bld_base->emit_epilogue = si_llvm_emit_gs_epilogue;
+   ctx->abi.emit_outputs = si_llvm_emit_gs_epilogue;
+   bld_base->emit_epilogue = si_tgsi_emit_gs_epilogue;
break;
case PIPE_SHADER_FRAGMENT:
ctx->load_input = declare_input_fs;
ctx->abi.emit_outputs = si_llvm_return_fs_outputs;
bld_base->emit_epilogue = si_tgsi_emit_epilogue;
break;
case PIPE_SHADER_COMPUTE:
break;
default:
assert(!"Unsupported shader type");
-- 
2.14.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radv: do not add the query pool BO to the list in vkCmdEndQuery()

2017-11-15 Thread Samuel Pitoiset
As per the spec, the query identified by queryPool and query
must currently be active. Applications have to call vkCmdBeginQuery()
before, and thus the query pool BO will already be in the list.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_query.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 6a80740ce0..5dc88af8f8 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1125,7 +1125,9 @@ void radv_CmdEndQuery(
uint64_t avail_va = va + pool->availability_offset + 4 * query;
va += pool->stride * query;
 
-   radv_cs_add_buffer(cmd_buffer->device->ws, cs, pool->bo, 8);
+   /* Do not need to add the pool BO to the list because the query must
+* currently be active, which means the BO is already in the list.
+*/
 
switch (pool->type) {
case VK_QUERY_TYPE_OCCLUSION:
-- 
2.15.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 17/20] ac: add si_nir_load_input_gs() to the abi

2017-11-15 Thread Nicolai Hähnle

On 10.11.2017 04:13, Timothy Arceri wrote:

---
  src/amd/common/ac_nir_to_llvm.c   | 24 -
  src/amd/common/ac_shader_abi.h|  7 ++
  src/gallium/drivers/radeonsi/si_shader.c  |  1 +
  src/gallium/drivers/radeonsi/si_shader_internal.h |  5 +
  src/gallium/drivers/radeonsi/si_shader_nir.c  | 26 +++
  5 files changed, 53 insertions(+), 10 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 158e954fa8..483dd52b36 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2854,32 +2854,31 @@ load_tes_input(struct nir_to_llvm_context *ctx,
buf_addr = LLVMBuildAdd(ctx->builder, buf_addr, comp_offset, "");
  
  	result = ac_build_buffer_load(>ac, ctx->hs_ring_tess_offchip, instr->num_components, NULL,

  buf_addr, ctx->oc_lds, is_compact ? (4 * 
const_index) : 0, 1, 0, true, false);
result = trim_vector(>ac, result, instr->num_components);
result = LLVMBuildBitCast(ctx->builder, result, get_def_type(ctx->nir, 
>dest.ssa), "");
return result;
  }
  
  static LLVMValueRef

-load_gs_input(struct nir_to_llvm_context *ctx,
- nir_intrinsic_instr *instr)
+load_gs_input(struct ac_shader_abi *abi,
+ nir_intrinsic_instr *instr,
+ unsigned vertex_index,
+ unsigned const_index)
  {
-   LLVMValueRef indir_index, vtx_offset;
-   unsigned const_index;
+   struct nir_to_llvm_context *ctx = nir_to_llvm_context_from_abi(abi);
+   LLVMValueRef vtx_offset;
LLVMValueRef args[9];
unsigned param, vtx_offset_param;
LLVMValueRef value[4], result;
-   unsigned vertex_index;
-   get_deref_offset(ctx->nir, instr->variables[0],
-false, _index, NULL,
-_index, _index);
+
vtx_offset_param = vertex_index;
assert(vtx_offset_param < 6);
vtx_offset = LLVMBuildMul(ctx->builder, 
ctx->gs_vtx_offset[vtx_offset_param],
  LLVMConstInt(ctx->ac.i32, 4, false), "");
  
  	param = shader_io_get_unique_index(instr->variables[0]->var->data.location);
  
  	unsigned comp = instr->variables[0]->var->data.location_frac;

for (unsigned i = comp; i < instr->num_components + comp; i++) {
if (ctx->ac.chip_class >= GFX9) {
@@ -2966,21 +2965,26 @@ static LLVMValueRef visit_load_var(struct 
ac_nir_context *ctx,
if (instr->dest.ssa.bit_size == 64)
ve *= 2;
  
  	switch (instr->variables[0]->var->data.mode) {

case nir_var_shader_in:
if (ctx->stage == MESA_SHADER_TESS_CTRL)
return load_tcs_input(ctx->nctx, instr);
if (ctx->stage == MESA_SHADER_TESS_EVAL)
return load_tes_input(ctx->nctx, instr);
if (ctx->stage == MESA_SHADER_GEOMETRY) {
-   return load_gs_input(ctx->nctx, instr);
+   LLVMValueRef indir_index;
+   unsigned const_index, vertex_index;
+   get_deref_offset(ctx, instr->variables[0],
+false, _index, NULL,
+_index, _index);


The indentation looks wrong here.



+   return ctx->abi->load_inputs(ctx->abi, instr, 
vertex_index, const_index);
}
  
  		for (unsigned chan = comp; chan < ve + comp; chan++) {

if (indir_index) {
unsigned count = glsl_count_attribute_slots(
instr->variables[0]->var->type,
ctx->stage == 
MESA_SHADER_VERTEX);
count -= chan / 4;
LLVMValueRef tmp_vec = 
ac_build_gather_values_extended(
>ac, ctx->abi->inputs + 
idx + chan, count,
@@ -6489,22 +6493,22 @@ LLVMModuleRef 
ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,
  
  	for(int i = 0; i < shader_count; ++i) {

ctx.stage = shaders[i]->info.stage;
ctx.output_mask = 0;
ctx.tess_outputs_written = 0;
ctx.num_output_clips = 
shaders[i]->info.clip_distance_array_size;
ctx.num_output_culls = 
shaders[i]->info.cull_distance_array_size;
  
  		if (shaders[i]->info.stage == MESA_SHADER_GEOMETRY) {

ctx.gs_next_vertex = ac_build_alloca(, ctx.ac.i32, 
"gs_next_vertex");
-
ctx.gs_max_out_vertices = 
shaders[i]->info.gs.vertices_out;
+   ctx.abi.load_inputs = load_gs_input;
} else if (shaders[i]->info.stage == MESA_SHADER_TESS_EVAL) {

Re: [Mesa-dev] [PATCH 17/20] ac: add si_nir_load_input_gs() to the abi

2017-11-15 Thread Nicolai Hähnle

On 15.11.2017 12:09, Timothy Arceri wrote:



On 15/11/17 21:56, Nicolai Hähnle wrote:

On 10.11.2017 04:13, Timothy Arceri wrote:

---
  src/amd/common/ac_nir_to_llvm.c   | 24 
-

  src/amd/common/ac_shader_abi.h    |  7 ++
  src/gallium/drivers/radeonsi/si_shader.c  |  1 +
  src/gallium/drivers/radeonsi/si_shader_internal.h |  5 +
  src/gallium/drivers/radeonsi/si_shader_nir.c  | 26 
+++

  5 files changed, 53 insertions(+), 10 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c 
b/src/amd/common/ac_nir_to_llvm.c

index 158e954fa8..483dd52b36 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2854,32 +2854,31 @@ load_tes_input(struct nir_to_llvm_context *ctx,
  buf_addr = LLVMBuildAdd(ctx->builder, buf_addr, comp_offset, "");
  result = ac_build_buffer_load(>ac, 
ctx->hs_ring_tess_offchip, instr->num_components, NULL,
    buf_addr, ctx->oc_lds, is_compact ? (4 * 
const_index) : 0, 1, 0, true, false);

  result = trim_vector(>ac, result, instr->num_components);
  result = LLVMBuildBitCast(ctx->builder, result, 
get_def_type(ctx->nir, >dest.ssa), "");

  return result;
  }
  static LLVMValueRef
-load_gs_input(struct nir_to_llvm_context *ctx,
-  nir_intrinsic_instr *instr)
+load_gs_input(struct ac_shader_abi *abi,
+  nir_intrinsic_instr *instr,
+  unsigned vertex_index,
+  unsigned const_index)
  {
-    LLVMValueRef indir_index, vtx_offset;
-    unsigned const_index;
+    struct nir_to_llvm_context *ctx = 
nir_to_llvm_context_from_abi(abi);

+    LLVMValueRef vtx_offset;
  LLVMValueRef args[9];
  unsigned param, vtx_offset_param;
  LLVMValueRef value[4], result;
-    unsigned vertex_index;
-    get_deref_offset(ctx->nir, instr->variables[0],
- false, _index, NULL,
- _index, _index);
+
  vtx_offset_param = vertex_index;
  assert(vtx_offset_param < 6);
  vtx_offset = LLVMBuildMul(ctx->builder, 
ctx->gs_vtx_offset[vtx_offset_param],

    LLVMConstInt(ctx->ac.i32, 4, false), "");
  param = 
shader_io_get_unique_index(instr->variables[0]->var->data.location);

  unsigned comp = instr->variables[0]->var->data.location_frac;
  for (unsigned i = comp; i < instr->num_components + comp; i++) {
  if (ctx->ac.chip_class >= GFX9) {
@@ -2966,21 +2965,26 @@ static LLVMValueRef visit_load_var(struct 
ac_nir_context *ctx,

  if (instr->dest.ssa.bit_size == 64)
  ve *= 2;
  switch (instr->variables[0]->var->data.mode) {
  case nir_var_shader_in:
  if (ctx->stage == MESA_SHADER_TESS_CTRL)
  return load_tcs_input(ctx->nctx, instr);
  if (ctx->stage == MESA_SHADER_TESS_EVAL)
  return load_tes_input(ctx->nctx, instr);
  if (ctx->stage == MESA_SHADER_GEOMETRY) {
-    return load_gs_input(ctx->nctx, instr);
+    LLVMValueRef indir_index;
+    unsigned const_index, vertex_index;
+    get_deref_offset(ctx, instr->variables[0],
+ false, _index, NULL,
+ _index, _index);


The indentation looks wrong here.


+    return ctx->abi->load_inputs(ctx->abi, instr, 
vertex_index, const_index);

  }
  for (unsigned chan = comp; chan < ve + comp; chan++) {
  if (indir_index) {
  unsigned count = glsl_count_attribute_slots(
  instr->variables[0]->var->type,
  ctx->stage == MESA_SHADER_VERTEX);
  count -= chan / 4;
  LLVMValueRef tmp_vec = 
ac_build_gather_values_extended(
  >ac, ctx->abi->inputs + idx + chan, 
count,
@@ -6489,22 +6493,22 @@ LLVMModuleRef 
ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,

  for(int i = 0; i < shader_count; ++i) {
  ctx.stage = shaders[i]->info.stage;
  ctx.output_mask = 0;
  ctx.tess_outputs_written = 0;
  ctx.num_output_clips = 
shaders[i]->info.clip_distance_array_size;
  ctx.num_output_culls = 
shaders[i]->info.cull_distance_array_size;

  if (shaders[i]->info.stage == MESA_SHADER_GEOMETRY) {
  ctx.gs_next_vertex = ac_build_alloca(, 
ctx.ac.i32, "gs_next_vertex");

-
  ctx.gs_max_out_vertices = 
shaders[i]->info.gs.vertices_out;

+    ctx.abi.load_inputs = load_gs_input;
  } else if (shaders[i]->info.stage == MESA_SHADER_TESS_EVAL) {
  ctx.tes_primitive_mode = 
shaders[i]->info.tess.primitive_mode;

  } else if (shaders[i]->info.stage == MESA_SHADER_VERTEX) {
  if (shader_info->info.vs.needs_instance_id) {
  ctx.shader_info->vs.vgpr_comp_cnt =
  MAX2(3, ctx.shader_info->vs.vgpr_comp_cnt);
  }
  } else if (shaders[i]->info.stage == 

Re: [Mesa-dev] [PATCH 17/20] ac: add si_nir_load_input_gs() to the abi

2017-11-15 Thread Timothy Arceri

On 15/11/17 22:17, Nicolai Hähnle wrote:

On 15.11.2017 12:09, Timothy Arceri wrote:



On 15/11/17 21:56, Nicolai Hähnle wrote:

On 10.11.2017 04:13, Timothy Arceri wrote:

---
  src/amd/common/ac_nir_to_llvm.c   | 24 
-

  src/amd/common/ac_shader_abi.h    |  7 ++
  src/gallium/drivers/radeonsi/si_shader.c  |  1 +
  src/gallium/drivers/radeonsi/si_shader_internal.h |  5 +
  src/gallium/drivers/radeonsi/si_shader_nir.c  | 26 
+++

  5 files changed, 53 insertions(+), 10 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c 
b/src/amd/common/ac_nir_to_llvm.c

index 158e954fa8..483dd52b36 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2854,32 +2854,31 @@ load_tes_input(struct nir_to_llvm_context *ctx,
  buf_addr = LLVMBuildAdd(ctx->builder, buf_addr, comp_offset, "");
  result = ac_build_buffer_load(>ac, 
ctx->hs_ring_tess_offchip, instr->num_components, NULL,
    buf_addr, ctx->oc_lds, is_compact ? (4 * 
const_index) : 0, 1, 0, true, false);

  result = trim_vector(>ac, result, instr->num_components);
  result = LLVMBuildBitCast(ctx->builder, result, 
get_def_type(ctx->nir, >dest.ssa), "");

  return result;
  }
  static LLVMValueRef
-load_gs_input(struct nir_to_llvm_context *ctx,
-  nir_intrinsic_instr *instr)
+load_gs_input(struct ac_shader_abi *abi,
+  nir_intrinsic_instr *instr,
+  unsigned vertex_index,
+  unsigned const_index)
  {
-    LLVMValueRef indir_index, vtx_offset;
-    unsigned const_index;
+    struct nir_to_llvm_context *ctx = 
nir_to_llvm_context_from_abi(abi);

+    LLVMValueRef vtx_offset;
  LLVMValueRef args[9];
  unsigned param, vtx_offset_param;
  LLVMValueRef value[4], result;
-    unsigned vertex_index;
-    get_deref_offset(ctx->nir, instr->variables[0],
- false, _index, NULL,
- _index, _index);
+
  vtx_offset_param = vertex_index;
  assert(vtx_offset_param < 6);
  vtx_offset = LLVMBuildMul(ctx->builder, 
ctx->gs_vtx_offset[vtx_offset_param],

    LLVMConstInt(ctx->ac.i32, 4, false), "");
  param = 
shader_io_get_unique_index(instr->variables[0]->var->data.location);

  unsigned comp = instr->variables[0]->var->data.location_frac;
  for (unsigned i = comp; i < instr->num_components + comp; i++) {
  if (ctx->ac.chip_class >= GFX9) {
@@ -2966,21 +2965,26 @@ static LLVMValueRef visit_load_var(struct 
ac_nir_context *ctx,

  if (instr->dest.ssa.bit_size == 64)
  ve *= 2;
  switch (instr->variables[0]->var->data.mode) {
  case nir_var_shader_in:
  if (ctx->stage == MESA_SHADER_TESS_CTRL)
  return load_tcs_input(ctx->nctx, instr);
  if (ctx->stage == MESA_SHADER_TESS_EVAL)
  return load_tes_input(ctx->nctx, instr);
  if (ctx->stage == MESA_SHADER_GEOMETRY) {
-    return load_gs_input(ctx->nctx, instr);
+    LLVMValueRef indir_index;
+    unsigned const_index, vertex_index;
+    get_deref_offset(ctx, instr->variables[0],
+ false, _index, NULL,
+ _index, _index);


The indentation looks wrong here.


+    return ctx->abi->load_inputs(ctx->abi, instr, 
vertex_index, const_index);

  }
  for (unsigned chan = comp; chan < ve + comp; chan++) {
  if (indir_index) {
  unsigned count = glsl_count_attribute_slots(
  instr->variables[0]->var->type,
  ctx->stage == MESA_SHADER_VERTEX);
  count -= chan / 4;
  LLVMValueRef tmp_vec = 
ac_build_gather_values_extended(
  >ac, ctx->abi->inputs + idx + chan, 
count,
@@ -6489,22 +6493,22 @@ LLVMModuleRef 
ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,

  for(int i = 0; i < shader_count; ++i) {
  ctx.stage = shaders[i]->info.stage;
  ctx.output_mask = 0;
  ctx.tess_outputs_written = 0;
  ctx.num_output_clips = 
shaders[i]->info.clip_distance_array_size;
  ctx.num_output_culls = 
shaders[i]->info.cull_distance_array_size;

  if (shaders[i]->info.stage == MESA_SHADER_GEOMETRY) {
  ctx.gs_next_vertex = ac_build_alloca(, 
ctx.ac.i32, "gs_next_vertex");

-
  ctx.gs_max_out_vertices = 
shaders[i]->info.gs.vertices_out;

+    ctx.abi.load_inputs = load_gs_input;
  } else if (shaders[i]->info.stage == MESA_SHADER_TESS_EVAL) {
  ctx.tes_primitive_mode = 
shaders[i]->info.tess.primitive_mode;

  } else if (shaders[i]->info.stage == MESA_SHADER_VERTEX) {
  if (shader_info->info.vs.needs_instance_id) {
  ctx.shader_info->vs.vgpr_comp_cnt =
  MAX2(3, ctx.shader_info->vs.vgpr_comp_cnt);
  }
  

Re: [Mesa-dev] [PATCH] threads: fix MinGW build breakage

2017-11-15 Thread Jon Turney

On 15/11/2017 11:21, Nicolai Hähnle wrote:

On 13.11.2017 23:55, Rob Herring wrote:

On Fri, Nov 10, 2017 at 12:39 PM, Jon Turney
 wrote:

On 10/11/2017 15:42, Nicolai Hähnle wrote:


On 10.11.2017 14:00, Jon Turney wrote:


On 09/11/2017 21:41, Nicolai Hähnle wrote:


Sorry for the mess.



I'm going to suggest that the fallback declaration of 
timespec_get() also

needs to be provided for POSIX systems which don't have it.

Not noticed previously as it (or xtime_get()) doesn't seem to have had
any users, prior to this series.

Patch attached.



Do you have a system where this is actually needed? Currently
HAVE_TIMESPEC_GET is only defined in threads_win32.h, so some more 
detection
logic somewhere would be required if this actually turns out to be 
an issue.



Hmm.. yes, I'd assumed that HAVE_TIMESPEC_GET was the result of an 
autoconf

check, but it isn't.

Cygwin doesn't (currently) have timespec_get().

I'm thinking the correct solution here is actually to unconditionally
declare timespec_get(), just like all the other C11 thread functions 
(and as

the unused xtime_get() was, prior to
f1a364878431c8c5f4fd38b40b9766449e49f552)?

Revised patch attached.


That should fix Android builds.

Acked-by: Rob Herring 


The issue with this is that it makes the compiler unhappy when 
timespec_get *is* available. I'm looking at adding a configure check. 


Ah, and this doesn't effect the other C11 emulation functions in this 
header because we don't include threads.h, but we do include time.h?

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Difference between Meson and autotools release builds

2017-11-15 Thread Eric Engestrom
On Wednesday, 2017-11-15 09:43:59 +, Rogovin, Kevin wrote:
> Hi,
> 
> I do not know if anyone has noticed or if it is deliberate, but the meson 
> builds have that assert()'s are active but the autotools release builds have 
> that assert() is inactive.

Hi,

Yep, this is by design, meson decouples the build type (eg. "release")
from whether asserts are enabled; you can read more about it in this
thread:
https://lists.freedesktop.org/archives/mesa-dev/2017-November/175739.html

You can already read the not-yet-landed documentation in this patch:
https://lists.freedesktop.org/archives/mesa-dev/2017-November/175854.html

(or if it lands before you read this, the up-to-date meson-for-mesa
documentation will live at: https://mesa3d.org/meson.html)

Cheers,
  Eric
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 2/5] etnaviv: Check that resource has a valid TS in etna_resource_needs_flush

2017-11-15 Thread Lucas Stach
Am Dienstag, den 14.11.2017, 10:21 +0100 schrieb Wladimir J. van der
Laan:
> Resources only need a resolve-to-itself if their TS is valid for any
> level, not just if it happens to be allocated.
> 
> Signed-off-by: Wladimir J. van der Laan 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 13 +
>  src/gallium/drivers/etnaviv/etnaviv_resource.h |  6 +-
>  2 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 0a82807..1fb73c4 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -629,6 +629,19 @@ etna_resource_used(struct etna_context *ctx,
> struct pipe_resource *prsc,
> rsc->pending_ctx = ctx;
>  }
>  
> +bool
> +etna_resource_has_valid_ts(struct etna_resource *rsc)
> +{
> +   if (!rsc->ts_bo)
> +  return false;
> +
> +   for (int level = 0; level <= rsc->base.last_level; level++)
> +  if (rsc->levels[level].ts_valid)
> + return true;
> +
> +   return false;
> +}
> +
>  void
>  etna_resource_screen_init(struct pipe_screen *pscreen)
>  {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 0b135e2..11ccf8f 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -103,11 +103,15 @@ etna_resource_older(struct etna_resource *a,
> struct etna_resource *b)
> return (int)(a->seqno - b->seqno) < 0;
>  }
>  
> +/* returns TRUE if a resource has a TS, and it is valid for at least
> one level */
> +bool
> +etna_resource_has_valid_ts(struct etna_resource *res);
> +
>  /* returns TRUE if the resource needs a resolve to itself */
>  static inline bool
>  etna_resource_needs_flush(struct etna_resource *res)
>  {
> -   return res->ts_bo && ((int)(res->seqno - res->flush_seqno) > 0);
> +   return etna_resource_has_valid_ts(res) && ((int)(res->seqno -
> res->flush_seqno) > 0);
>  }
>  
>  /* is the resource only used on the sampler? */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Has anyone stressed radeonsi memory?

2017-11-15 Thread Matias N. Goldberg
Hi!

> Are you using the amdgpu kernel driver from an amdgpu-pro release or
> from the upstream Linux kernel? (If you're not sure, provide the dmesg
> output and Xorg log file)

> If the latter, can you try a 4.13 or 4.14 kernel and see if that works
> better?


I'm using upstream Linux kernel (without my distro's patches), with amdgpu (not 
pro).

I could try newer kernels.

> Why, doesn't your distro have LLVM development packages?
They aren't as up to date. Keeping up-to-date with everything mesa needs is 
exhausting.
I started compiling LLVM from source when I needed to test an LLVM patch to fix 
a GLSL shader compiler bug.

I also compile mesa from source (rather thank using Oibaf or Padoka's PPA for 
Ubuntu) because as a graphics dev, being able to debug inside Mesa has proven 
to be an invaluable tool.


So I take it from your questions, that this behavior I saw isn't exactly 
"normal" or "expected" and I should dedicate some time to see if I can repro in 
newer versions, and if possible create a small repro.

Thanks,

Cheers
Matias

De: Michel Dänzer 
Para: Matias N. Goldberg  
CC: ML Mesa-dev 
Enviado: Martes, 14 de noviembre, 2017 14:43:28
Asunto: Re: [Mesa-dev] Has anyone stressed radeonsi memory?



On 13/11/17 04:39 AM, Matias N. Goldberg wrote:
> 
> I am on a Radeon RX 560 2GB; using mesa git-57c8ead0cd (So... not too new not 
> too old), Kernel 4.12.10
> 
> I've been having complaints about our WIP branch of Ogre 2.2 about out of 
> memory crashes, and I fixed them.
> 
> I made a stress test where 495 textures with very different resolutions (most 
> of them not power-of-2), and total memory from those textures is around 700MB 
> (for some reason radentop reports all 2GB of my card are used during this 
> stress test).
> Additionally, 495 cubes (one cube for each texture) are rendered to screen to 
> ensure driver keeps them resident.
> 
> The problem is, we have different strategies:
> 1. In one extreme, we can load every texture to a staging region, one at a 
> time; and then from staging region copy to the final texture.
> 2. In the other extreme, we load all textures to RAM at once, and use one 
> giant staging region.
> 
> Loading everything at once causes a GL_OUT_OF_MEMORY while creating the 
> staging area of 700MB. Ok... sounds sorta reasonable.
> 
> But things get interesting when loading using a staging area of 512MB:
> 1. Loading goes fine.
> 2. For a time, everything works fine.
> 3. If I hide all cubes so that they aren't shown anymore:
> 1. Framerate usually goes way down (not always), like 8 fps or so (should 
> be at 1000 fps while empty, around 200 fps while showing the cubes).
> How slow it becomes is not consistent.2. radeontop shows consumption goes 
> down a lot (like half or more).
> 3. A few seconds later, I almost always get a crash (SIGBUS) while 
> writing to an UBO buffer that had been persistently mapped (non-coherent) 
> since the beginning of the application.
> 4. Running through valgrind, I don't get a crash.
> 5. There are no errors reported by OpenGL.
> 4. I don't get a crash if I never hide the cubes.
> 
> Using a smaller staging area (256MB or lower) everything is always fine.
> 
> So... is this behavior expected?
> Am I uncovering a weird bug in how radeonsi/amdgpu-pro handle memory pages?

Are you using the amdgpu kernel driver from an amdgpu-pro release or
from the upstream Linux kernel? (If you're not sure, provide the dmesg
output and Xorg log file)

If the latter, can you try a 4.13 or 4.14 kernel and see if that works
better?



> I'd normally update to latest git, then create a test if the problem 
> persists; but I've pulled latest git and saw that it required me to recompile 
> llvm as well...

Why, doesn't your distro have LLVM development packages?


-- 
Earthling Michel Dänzer   |  http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


  1   2   >