Re: [Mesa-dev] [PATCH v2 05/27] configure: enable the surfaceless platform by default

2017-05-07 Thread Tapani Pälli 

Yes please!

Acked-by: Tapani Pälli 

On 05/04/2017 07:29 PM, Emil Velikov wrote:

From: Emil Velikov 

A simple platform that you want to use in a many usecases. See the
spec file details.

It has no special requirements plus it takes less than a second to
build.

Cc: Tapani Pälli 
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Emil Velikov 
---
  configure.ac| 5 ++---
  docs/releasing.html | 2 +-
  2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index f4f488a25bc..b132edef255 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1648,10 +1648,9 @@ AC_ARG_WITH([egl-platforms],
  [with_egl_platforms=auto])
  
  if test "x$with_egl_platforms" = xauto; then

+with_egl_platforms="x11,surfaceless"
  if test "x$enable_gbm" = xyes; then
-with_egl_platforms="x11,drm"
-else
-with_egl_platforms="x11"
+with_egl_platforms="$with_egl_platforms,drm"
  fi
  else
  AC_MSG_WARN([--with-egl-platforms is deprecated. Use --with-platforms 
instead.])
diff --git a/docs/releasing.html b/docs/releasing.html
index 83f4a52b49f..68d83f2ae20 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -405,7 +405,7 @@ Here is one solution that I've been using.
--enable-glx-tls \
--enable-gbm \
--enable-egl \
-   --with-platforms=x11,drm,wayland
+   --with-platforms=x11,drm,wayland,surfaceless
make -j2  DESTDIR=`pwd`/test make -j6 install
__glxinfo_cmd='glxinfo 2>1 | egrep -o "Mesa.*|Gallium.*|.*dri\.so"'
__glxgears_cmd='glxgears 2>1 | grep -v "configuration file"'


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

Re: [Mesa-dev] [PATCH] android: i965: add per-gen libmesa_i965_gen{4, 45, 5} static

2017-05-07 Thread Tapani Pälli 

Reviewed-by: Tapani Pälli 

On 05/06/2017 05:03 PM, Mauro Rossi wrote:

Needed to fix android building errors:

external/mesa/src/mesa/drivers/dri/i965/brw_state_upload.c:148: error: 
undefined reference to 'gen5_init_atoms'
external/mesa/src/mesa/drivers/dri/i965/brw_state_upload.c:150: error: 
undefined reference to 'gen45_init_atoms'
external/mesa/src/mesa/drivers/dri/i965/brw_state_upload.c:152: error: 
undefined reference to 'gen4_init_atoms'
clang++: error: linker command failed with exit code 1 (use -v to see 
invocation)

Fixes: 5a19d0b "i965: Get real per-gen atom lists"
---
  src/mesa/drivers/dri/i965/Android.mk | 66 
  1 file changed, 66 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/Android.mk 
b/src/mesa/drivers/dri/i965/Android.mk
index ac0a4446b9..7c4fadaa46 100644
--- a/src/mesa/drivers/dri/i965/Android.mk
+++ b/src/mesa/drivers/dri/i965/Android.mk
@@ -40,6 +40,9 @@ I965_PERGEN_STATIC_LIBRARIES := \
libmesa_nir
  
  I965_PERGEN_LIBS := \

+   libmesa_i965_gen4 \
+   libmesa_i965_gen45 \
+   libmesa_i965_gen5 \
libmesa_i965_gen6 \
libmesa_i965_gen7 \
libmesa_i965_gen75 \
@@ -47,6 +50,69 @@ I965_PERGEN_LIBS := \
libmesa_i965_gen9
  
  # ---

+# Build libmesa_i965_gen4
+# ---
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libmesa_i965_gen4
+
+LOCAL_C_INCLUDES := $(I965_PERGEN_COMMON_INCLUDES)
+
+LOCAL_SRC_FILES := $(i965_gen4_FILES)
+
+LOCAL_SHARED_LIBRARIES := $(I965_PERGEN_SHARED_LIBRARIES)
+
+LOCAL_STATIC_LIBRARIES := $(I965_PERGEN_STATIC_LIBRARIES)
+
+LOCAL_CFLAGS := -DGEN_VERSIONx10=40
+
+include $(MESA_COMMON_MK)
+include $(BUILD_STATIC_LIBRARY)
+
+# ---
+# Build libmesa_i965_gen45
+# ---
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libmesa_i965_gen45
+
+LOCAL_C_INCLUDES := $(I965_PERGEN_COMMON_INCLUDES)
+
+LOCAL_SRC_FILES := $(i965_gen45_FILES)
+
+LOCAL_SHARED_LIBRARIES := $(I965_PERGEN_SHARED_LIBRARIES)
+
+LOCAL_STATIC_LIBRARIES := $(I965_PERGEN_STATIC_LIBRARIES)
+
+LOCAL_CFLAGS := -DGEN_VERSIONx10=45
+
+include $(MESA_COMMON_MK)
+include $(BUILD_STATIC_LIBRARY)
+
+# ---
+# Build libmesa_i965_gen5
+# ---
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE := libmesa_i965_gen5
+
+LOCAL_C_INCLUDES := $(I965_PERGEN_COMMON_INCLUDES)
+
+LOCAL_SRC_FILES := $(i965_gen5_FILES)
+
+LOCAL_SHARED_LIBRARIES := $(I965_PERGEN_SHARED_LIBRARIES)
+
+LOCAL_STATIC_LIBRARIES := $(I965_PERGEN_STATIC_LIBRARIES)
+
+LOCAL_CFLAGS := -DGEN_VERSIONx10=50
+
+include $(MESA_COMMON_MK)
+include $(BUILD_STATIC_LIBRARY)
+
+# ---
  # Build libmesa_i965_gen6
  # ---
  


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

[Mesa-dev] [PATCH] mesa: Make _mesa_primitive_restart_index a static inline in the header.

2017-05-07 Thread Kenneth Graunke 
It's now basically a single expression, so it probably makes sense to
have it inlined into the callers.

Suggested by Marek.
---
 src/mesa/main/varray.c | 18 --
 src/mesa/main/varray.h | 17 +++--
 2 files changed, 15 insertions(+), 20 deletions(-)

diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 9497090e88a..0eb8e623dcc 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -1949,24 +1949,6 @@ _mesa_VertexAttribDivisor(GLuint index, GLuint divisor)
 }
 
 
-unsigned
-_mesa_primitive_restart_index(const struct gl_context *ctx,
-  unsigned index_size)
-{
-   /* From the OpenGL 4.3 core specification, page 302:
-* "If both PRIMITIVE_RESTART and PRIMITIVE_RESTART_FIXED_INDEX are
-*  enabled, the index value determined by PRIMITIVE_RESTART_FIXED_INDEX
-*  is used."
-*/
-   if (ctx->Array.PrimitiveRestartFixedIndex) {
-  /* 1 -> 0xff, 2 -> 0x, 4 -> 0x */
-  return 0xu >> 8 * (4 - index_size);
-   }
-
-   return ctx->Array.RestartIndex;
-}
-
-
 /**
  * GL_ARB_vertex_attrib_binding
  */
diff --git a/src/mesa/main/varray.h b/src/mesa/main/varray.h
index ac49434ab90..2d184adf8bc 100644
--- a/src/mesa/main/varray.h
+++ b/src/mesa/main/varray.h
@@ -343,9 +343,22 @@ _mesa_VertexAttribDivisor_no_error(GLuint index, GLuint 
divisor);
 extern void GLAPIENTRY
 _mesa_VertexAttribDivisor(GLuint index, GLuint divisor);
 
-extern unsigned
+static inline unsigned
 _mesa_primitive_restart_index(const struct gl_context *ctx,
-  unsigned index_size);
+  unsigned index_size)
+{
+   /* From the OpenGL 4.3 core specification, page 302:
+* "If both PRIMITIVE_RESTART and PRIMITIVE_RESTART_FIXED_INDEX are
+*  enabled, the index value determined by PRIMITIVE_RESTART_FIXED_INDEX
+*  is used."
+*/
+   if (ctx->Array.PrimitiveRestartFixedIndex) {
+  /* 1 -> 0xff, 2 -> 0x, 4 -> 0x */
+  return 0xu >> 8 * (4 - index_size);
+   }
+
+   return ctx->Array.RestartIndex;
+}
 
 extern void GLAPIENTRY
 _mesa_BindVertexBuffer(GLuint bindingIndex, GLuint buffer, GLintptr offset,
-- 
2.12.2

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

Re: [Mesa-dev] [PATCH] glsl: destroy function and subroutine hash tables

2017-05-07 Thread Timothy Arceri 

Pushed, thanks!

On 03/05/17 04:06, Grazvydas Ignotas wrote:

Just like other type hash tables are destroyed in
_mesa_glsl_release_types(), also destroy the ones for function and
subroutine types.

Signed-off-by: Grazvydas Ignotas 
---
  src/compiler/glsl_types.cpp | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 0480bef..26cf755 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -415,10 +415,20 @@ _mesa_glsl_release_types(void)
 if (glsl_type::interface_types != NULL) {
_mesa_hash_table_destroy(glsl_type::interface_types, NULL);
glsl_type::interface_types = NULL;
 }
  
+   if (glsl_type::function_types != NULL) {

+  _mesa_hash_table_destroy(glsl_type::function_types, NULL);
+  glsl_type::function_types = NULL;
+   }
+
+   if (glsl_type::subroutine_types != NULL) {
+  _mesa_hash_table_destroy(glsl_type::subroutine_types, NULL);
+  glsl_type::subroutine_types = NULL;
+   }
+
 ralloc_free(glsl_type::mem_ctx);
 glsl_type::mem_ctx = NULL;
  }
  
  


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

[Mesa-dev] [AppVeyor] mesa master #4289 failed

2017-05-07 Thread AppVeyor 



Build mesa 4289 failed


Commit 1f743a0edf by Grazvydas Ignotas on 5/2/2017 6:06 PM:

glsl: destroy function and subroutine hash tables\n\nJust like other type hash tables are destroyed in\n_mesa_glsl_release_types(), also destroy the ones for function and\nsubroutine types.\n\nSigned-off-by: Grazvydas Ignotas \nReviewed-by: Timothy Arceri 


Configure your notification preferences

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

[Mesa-dev] [Bug 100782] [GLVND] X fails to start AMDGPU DDX when GLVND compiled into Mesa

2017-05-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100782

Shawn Starr  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #3 from Shawn Starr  ---
Seems one of the RPMs for glvnd or something didn't create libEGL.so.1 and
things broke.

With this fixed, reinstalled with latest libglvnd-egl RPM, all works. closing

-- 
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] st/xvmc: deal with drivers wanting different texture formats

2017-05-07 Thread Ilia Mirkin 
Previously, texture formats were being used unconditionally without
checking. However nv30 supports neither RGBX8 nor R4A4/A4R4 formats. Add
sufficient fallbacks so that the nv30 driver can have working OSD.

Tested on a NV44A/PCI.

Signed-off-by: Ilia Mirkin 
---

I need to double-check that I didn't break everything on nv50+, which does
support all the various formats. Will definitely do that before pushing.

 src/gallium/state_trackers/xvmc/subpicture.c | 151 ---
 1 file changed, 115 insertions(+), 36 deletions(-)

diff --git a/src/gallium/state_trackers/xvmc/subpicture.c 
b/src/gallium/state_trackers/xvmc/subpicture.c
index 8b95a4e..bc26976 100644
--- a/src/gallium/state_trackers/xvmc/subpicture.c
+++ b/src/gallium/state_trackers/xvmc/subpicture.c
@@ -48,22 +48,43 @@
 #define FOURCC_AI44 0x34344941
 #define FOURCC_IA44 0x34344149
 
-static enum pipe_format XvIDToPipe(int xvimage_id)
+static enum pipe_format XvIDToPipe(struct pipe_screen *screen,
+   int xvimage_id)
 {
-   switch (xvimage_id) {
-  case FOURCC_RGB:
- return PIPE_FORMAT_B8G8R8X8_UNORM;
-
-  case FOURCC_AI44:
- return PIPE_FORMAT_R4A4_UNORM;
+   enum pipe_format ret;
+   assert(screen);
 
-  case FOURCC_IA44:
- return PIPE_FORMAT_A4R4_UNORM;
+   switch (xvimage_id) {
+   case FOURCC_RGB:
+  ret = PIPE_FORMAT_B8G8R8X8_UNORM;
+  break;
+
+   case FOURCC_AI44:
+  ret = PIPE_FORMAT_R4A4_UNORM;
+  if (!screen->is_format_supported(
+screen, ret, PIPE_TEXTURE_2D, 0, PIPE_BIND_SAMPLER_VIEW))
+ ret = PIPE_FORMAT_B4G4R4A4_UNORM;
+  break;
+
+   case FOURCC_IA44:
+  ret = PIPE_FORMAT_A4R4_UNORM;
+  if (!screen->is_format_supported(
+screen, ret, PIPE_TEXTURE_2D, 0, PIPE_BIND_SAMPLER_VIEW))
+ ret = PIPE_FORMAT_B4G4R4A4_UNORM;
+  break;
+
+   default:
+  XVMC_MSG(XVMC_ERR, "[XvMC] Unrecognized Xv image ID 0x%08X.\n", 
xvimage_id);
+  return PIPE_FORMAT_NONE;
+   }
 
-  default:
- XVMC_MSG(XVMC_ERR, "[XvMC] Unrecognized Xv image ID 0x%08X.\n", 
xvimage_id);
- return PIPE_FORMAT_NONE;
+   if (!screen->is_format_supported(
+ screen, ret, PIPE_TEXTURE_2D, 0, PIPE_BIND_SAMPLER_VIEW)) {
+  XVMC_MSG(XVMC_ERR, "[XvMC] Unsupported 2D format %s for Xv image ID 
0x%08X.\n", util_format_name(ret), xvimage_id);
+  ret = PIPE_FORMAT_NONE;
}
+   return ret;
+
 }
 
 static unsigned NumPaletteEntries4XvID(int xvimage_id)
@@ -82,29 +103,44 @@ static unsigned NumPaletteEntries4XvID(int xvimage_id)
}
 }
 
-static int PipeToComponentOrder(enum pipe_format format, char *component_order)
+static int PipeToComponentOrder(struct pipe_screen *screen,
+enum pipe_format format,
+enum pipe_format *palette_format,
+char *component_order)
 {
+   assert(screen);
assert(component_order);
+   assert(palette_format);
 
switch (format) {
-  case PIPE_FORMAT_B8G8R8X8_UNORM:
- return 0;
-
-  case PIPE_FORMAT_A4R4_UNORM:
-  case PIPE_FORMAT_R4A4_UNORM:
- component_order[0] = 'Y';
- component_order[1] = 'U';
- component_order[2] = 'V';
- component_order[3] = 'A';
- return 4;
-
-  default:
- XVMC_MSG(XVMC_ERR, "[XvMC] Unrecognized PIPE_FORMAT 0x%08X.\n", 
format);
- component_order[0] = 0;
- component_order[1] = 0;
- component_order[2] = 0;
- component_order[3] = 0;
- return 0;
+   case PIPE_FORMAT_B8G8R8X8_UNORM:
+  return 0;
+
+   case PIPE_FORMAT_A4R4_UNORM:
+   case PIPE_FORMAT_R4A4_UNORM:
+   case PIPE_FORMAT_B4G4R4A4_UNORM:
+  *palette_format = PIPE_FORMAT_R8G8B8X8_UNORM;
+  component_order[0] = 'Y';
+  component_order[1] = 'U';
+  component_order[2] = 'V';
+  component_order[3] = 'A';
+  if (!screen->is_format_supported(
+screen, *palette_format, PIPE_TEXTURE_1D, 0,
+PIPE_BIND_SAMPLER_VIEW)) {
+ /* One of these formats better be supported... */
+ *palette_format = PIPE_FORMAT_B8G8R8X8_UNORM;
+ component_order[0] = 'V';
+ component_order[2] = 'Y';
+  }
+  return 4;
+
+   default:
+  XVMC_MSG(XVMC_ERR, "[XvMC] Unrecognized PIPE_FORMAT 0x%08X.\n", format);
+  component_order[0] = 0;
+  component_order[1] = 0;
+  component_order[2] = 0;
+  component_order[3] = 0;
+  return 0;
}
 }
 
@@ -186,6 +222,41 @@ upload_sampler(struct pipe_context *pipe, struct 
pipe_sampler_view *dst,
pipe->transfer_unmap(pipe, transfer);
 }
 
+static void
+upload_sampler_convert(struct pipe_context *pipe, struct pipe_sampler_view 
*dst,
+   const struct pipe_box *dst_box, const XvImage *image,
+   unsigned src_x, unsigned src_y)
+{
+   struct pipe_transfer *transfer;
+   int i, j;
+

[Mesa-dev] [PATCH] gallivm: Make sure module has the correct data layout when pass manager runs

2017-05-07 Thread Tom Stellard 
The datalayout for modules was purposely not being set in order to work around
the fact that the ExecutionEngine requires that the module's datalayout
matches the datalayout of the TargetMachine that the ExecutionEngine is
using.

When the pass manager runs on a module with no datalayout, it uses
the default datalayout which is little-endian.  This causes problems
on big-endian targets, because some optimizations that are legal on
little-endian or illegal on big-endian.

To resolve this, we set the datalayout prior to running the pass
manager, and then clear it before creating the ExectionEngine.

This patch fixes a lot of piglit tests on big-endian ppc64.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/auxiliary/gallivm/lp_bld_init.c | 34 +++--
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c 
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index ef2580e..9f1ade6 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -125,19 +125,6 @@ create_pass_manager(struct gallivm_state *gallivm)
LLVMAddTargetData(gallivm->target, gallivm->passmgr);
 #endif
 
-   /* Setting the module's DataLayout to an empty string will cause the
-* ExecutionEngine to copy to the DataLayout string from its target
-* machine to the module.  As of LLVM 3.8 the module and the execution
-* engine are required to have the same DataLayout.
-*
-* TODO: This is just a temporary work-around.  The correct solution is
-* for gallivm_init_state() to create a TargetMachine and pull the
-* DataLayout from there.  Currently, the TargetMachine used by llvmpipe
-* is being implicitly created by the EngineBuilder in
-* lp_build_create_jit_compiler_for_module()
-*/
-
-#if HAVE_LLVM < 0x0308
{
   char *td_str;
   // New ones from the Module.
@@ -145,9 +132,6 @@ create_pass_manager(struct gallivm_state *gallivm)
   LLVMSetDataLayout(gallivm->module, td_str);
   free(td_str);
}
-#else
-   LLVMSetDataLayout(gallivm->module, "");
-#endif
 
if ((gallivm_debug & GALLIVM_DEBUG_NO_OPT) == 0) {
   /* These are the passes currently listed in llvm-c/Transforms/Scalar.h,
@@ -628,6 +612,24 @@ gallivm_compile_module(struct gallivm_state *gallivm)
}
 
if (use_mcjit) {
+  /* Setting the module's DataLayout to an empty string will cause the
+   * ExecutionEngine to copy to the DataLayout string from its target
+   * machine to the module.  As of LLVM 3.8 the module and the execution
+   * engine are required to have the same DataLayout.
+   *
+   * We must make sure we do this after running the optimization passes,
+   * because those passes need a correct datalayout string.  For example,
+   * if those optimization passes see an empty datalayout, they will assume
+   * this is a little endian target and will do optimizations that break 
big
+   * endian machines.
+   *
+   * TODO: This is just a temporary work-around.  The correct solution is
+   * for gallivm_init_state() to create a TargetMachine and pull the
+   * DataLayout from there.  Currently, the TargetMachine used by llvmpipe
+   * is being implicitly created by the EngineBuilder in
+   * lp_build_create_jit_compiler_for_module()
+   */
+  LLVMSetDataLayout(gallivm->module, "");
   assert(!gallivm->engine);
   if (!init_gallivm_engine(gallivm)) {
  assert(0);
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH v3 0/4] Disable glthread if libX11 isn't thread-safe

2017-05-07 Thread Axel Davy 

Hi,

There should be very few X11 calls while rendering (basically only at 
the beginning or end of a frame).


Why not just always run these calls in the main thread (and wait for 
glthread work to finish) ?


That's basically what we do for gallium nine.

Yours,

Axel

On 05/05/2017 17:37, Gregory Hainaut wrote:

Hello Mesa developers,

Following the discussion from
https://lists.freedesktop.org/archives/mesa-dev/2017-April/153137.html

A check was added to ensure that X11 display can be locked. It should be enough
to ensure thread safety between X11 and glthread.

I also did the check on DRI3 as I'm not 100% sure that it is really thread safe.



v2: based on Nicolai/Matt reviews
Add a check on DRI extension version
Use C comments :)

v3: based on Emil reviews
Split the initial first patch into 3 sub patches dri extension / glx / egl
Improve error message
Improve code readability
Just include libX11 on EGL protected by ifdef

Thanks you for all the review comments.

Best regards,

Gregory Hainaut (4):
   dri: Extend __DRIbackgroundCallableExtensionRec to include a callback
 that checks for thread safety
   glx: implement __DRIbackgroundCallableExtension.isThreadSafe
   egl: implement __DRIbackgroundCallableExtension.isThreadSafe
   glthread/gallium: require safe_glthread to start glthread

  include/GL/internal/dri_interface.h  | 11 +++
  src/egl/drivers/dri2/egl_dri2.c  | 28 +++-
  src/gallium/state_trackers/dri/dri_context.c | 21 +
  src/glx/dri2_glx.c   | 15 ++-
  src/glx/dri3_glx.c   | 15 ++-
  5 files changed, 83 insertions(+), 7 deletions(-)



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

Re: [Mesa-dev] [PATCH] docs: remove released versions from the calendar

2017-05-07 Thread Eric Engestrom 
On Thursday, 2017-05-04 17:37:56 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Signed-off-by: Emil Velikov 

Reviewed-by: Eric Engestrom 

I guess updating the release calendar could be added as part of
docs/releasing.html#release (at the end, just before #announce)

> ---
>  docs/release-calendar.html | 16 ++--
>  1 file changed, 2 insertions(+), 14 deletions(-)
> 
> diff --git a/docs/release-calendar.html b/docs/release-calendar.html
> index fa67987da10..d05007852ff 100644
> --- a/docs/release-calendar.html
> +++ b/docs/release-calendar.html
> @@ -39,13 +39,7 @@ if you'd like to nominate a patch in the next stable 
> release.
>  Notes
>  
>  
> -17.0
> -2017-04-28
> -17.0.5
> -Andres Gomez
> -
> -
> -
> +17.0
>  2017-05-12
>  17.0.6
>  Emil Velikov
> @@ -58,13 +52,7 @@ if you'd like to nominate a patch in the next stable 
> release.
>  Final planned release for the 17.0 series
>  
>  
> -17.1
> -2017-04-28
> -17.1.0-rc3
> -Emil Velikov
> -
> -
> -
> +17.1
>  2017-05-05
>  17.1.0-rc4
>  Emil Velikov
> -- 
> 2.12.2
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 07/27] configure: error out when building GLX w/o the X11 platform

2017-05-07 Thread Eric Engestrom 
On Thursday, 2017-05-04 17:29:52 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Building EGL/Vulkan/other without X11, while GLX is enabled is confusing
> and misleading. In practise anyone aiming at the former will also
> disable GLX.
> 
> The inverse (some examples below) should still work:
>  ./configure --disable-glx --with-platforms=x11 --with-vulkan-drivers=intel
>  ./configure --disable-glx --with-platforms=x11 --enable-egl
> 
> Keep in mind that the X11 platform is enabled, by default.
> 
> Cc: 
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/configure.ac b/configure.ac
> index d76ad5039a2..920e3c53e7b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1724,6 +1724,12 @@ for plat in $platforms; do
>   esac
>  done
>  
> +if test "x$enable_glx" != xno; then
> +if ! echo "$platforms" | grep -q 'x11'; then
> +AC_MSG_ERROR([Building without the x11 platform as GLX is enabled, 
> is not supported])

"Building GLX without the x11 platform is not supported"

Patches 1-11 are
Reviewed-by: Eric Engestrom 

I don't seem to have received patches 12-27 of this series though?

> +fi
> +fi
> +
>  AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
>  AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
>  AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
> -- 
> 2.12.2
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: add KHR_no_error support for glUseProgram

2017-05-07 Thread Timothy Arceri 
V3: use always_inline attribute (Suggested by Nicolai)

Cc: Nicolai Hähnle 
---
 src/mapi/glapi/gen/gl_API.xml |  2 +-
 src/mesa/main/shaderapi.c | 75 +--
 src/mesa/main/shaderapi.h |  2 ++
 3 files changed, 54 insertions(+), 25 deletions(-)

diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index a304ac0..50d60f5 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -5493,21 +5493,21 @@
 
 
 
 
 
 
 
 
 
 
-
+
 
 
 
 
 
 
 
 
 
 
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index eb75a3e..f91cc89 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1841,20 +1841,70 @@ _mesa_ShaderSource(GLuint shaderObj, GLsizei count,
   free(source);
   source = replacement;
}
 #endif /* ENABLE_SHADER_CACHE */
 
shader_source(sh, source);
 
free(offsets);
 }
 
+/* The ARB_separate_shader_object spec says:
+ *
+ * "The executable code for an individual shader stage is taken from
+ * the current program for that stage.  If there is a current program
+ * object established by UseProgram, that program is considered current
+ * for all stages.  Otherwise, if there is a bound program pipeline
+ * object (section 2.14.PPO), the program bound to the appropriate
+ * stage of the pipeline object is considered current."
+ */
+static ALWAYS_INLINE void
+reference_pipeline_and_use_program(struct gl_context *ctx,
+   struct gl_shader_program *shProg,
+   bool no_error)
+{
+   if (shProg) {
+  /* Attach shader state to the binding point */
+  _mesa_reference_pipeline_object(ctx, >_Shader, >Shader);
+  /* Update the program */
+  _mesa_use_shader_program(ctx, shProg);
+   } else {
+  /* Must be done first: detach the progam */
+  _mesa_use_shader_program(ctx, shProg);
+  /* Unattach shader_state binding point */
+  _mesa_reference_pipeline_object(ctx, >_Shader,
+  ctx->Pipeline.Default);
+  /* If a pipeline was bound, rebind it */
+  if (ctx->Pipeline.Current) {
+ if (no_error)
+_mesa_BindProgramPipeline_no_error(ctx->Pipeline.Current->Name);
+ else
+_mesa_BindProgramPipeline(ctx->Pipeline.Current->Name);
+  }
+   }
+}
+
+  \
+
+void GLAPIENTRY
+_mesa_UseProgram_no_error(GLuint program)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   struct gl_shader_program *shProg = NULL;
+
+   if (program) {
+  shProg = _mesa_lookup_shader_program(ctx, program);
+   }
+
+   reference_pipeline_and_use_program(ctx, shProg, true);
+}
+
 
 void GLAPIENTRY
 _mesa_UseProgram(GLuint program)
 {
GET_CURRENT_CONTEXT(ctx);
struct gl_shader_program *shProg = NULL;
 
if (MESA_VERBOSE & VERBOSE_API)
   _mesa_debug(ctx, "glUseProgram %u\n", program);
 
@@ -1875,44 +1925,21 @@ _mesa_UseProgram(GLuint program)
  return;
   }
 
 #ifdef DEBUG
   if (ctx->_Shader->Flags & GLSL_USE_PROG) {
  print_shader_info(shProg);
   }
 #endif
}
 
-   /* The ARB_separate_shader_object spec says:
-*
-* "The executable code for an individual shader stage is taken from
-* the current program for that stage.  If there is a current program
-* object established by UseProgram, that program is considered current
-* for all stages.  Otherwise, if there is a bound program pipeline
-* object (section 2.14.PPO), the program bound to the appropriate
-* stage of the pipeline object is considered current."
-*/
-   if (program) {
-  /* Attach shader state to the binding point */
-  _mesa_reference_pipeline_object(ctx, >_Shader, >Shader);
-  /* Update the program */
-  _mesa_use_shader_program(ctx, shProg);
-   } else {
-  /* Must be done first: detach the progam */
-  _mesa_use_shader_program(ctx, shProg);
-  /* Unattach shader_state binding point */
-  _mesa_reference_pipeline_object(ctx, >_Shader, 
ctx->Pipeline.Default);
-  /* If a pipeline was bound, rebind it */
-  if (ctx->Pipeline.Current) {
- _mesa_BindProgramPipeline(ctx->Pipeline.Current->Name);
-  }
-   }
+   reference_pipeline_and_use_program(ctx, shProg, false);
 }
 
 
 void GLAPIENTRY
 _mesa_ValidateProgram(GLuint program)
 {
GET_CURRENT_CONTEXT(ctx);
validate_program(ctx, program);
 }
 
diff --git a/src/mesa/main/shaderapi.h b/src/mesa/main/shaderapi.h
index 99b4fe8..0a28185 100644
--- a/src/mesa/main/shaderapi.h
+++ b/src/mesa/main/shaderapi.h
@@ -120,20 +120,22 @@ _mesa_IsProgram(GLuint name);
 
 extern GLboolean GLAPIENTRY
 _mesa_IsShader(GLuint name);
 
 extern void GLAPIENTRY
 _mesa_LinkProgram(GLuint

Re: [Mesa-dev] [PATCH 2/2] docs: extend until the end of August

2017-05-07 Thread Eric Engestrom 
On Saturday, 2017-05-06 18:46:13 +0300, Andres Gomez wrote:
> Completed the 17.1 cycle and added the beginning of the 17.2 one.
> 
> Cc: Emil Velikov 
> Cc: Juan A. Suarez Romero 
> Signed-off-by: Andres Gomez 

Reviewed-by: Eric Engestrom 

As for patch 1/2, I guess I missed the discussion around this, but
what's the logic behind who-maintains-which-branch/release?

> ---
>  docs/release-calendar.html | 62 
> +-
>  1 file changed, 61 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/release-calendar.html b/docs/release-calendar.html
> index 897fb41ead..72dfdd2d07 100644
> --- a/docs/release-calendar.html
> +++ b/docs/release-calendar.html
> @@ -58,7 +58,7 @@ if you'd like to nominate a patch in the next stable 
> release.
>  Final planned release for the 17.0 series
>  
>  
> -17.1
> +17.1
>  2017-04-28
>  17.1.0-rc3
>  Emil Velikov
> @@ -87,6 +87,66 @@ if you'd like to nominate a patch in the next stable 
> release.
>  Andres Gomez
>  
>  
> +
> +2017-06-30
> +17.1.4
> +Andres Gomez
> +
> +
> +
> +2017-07-14
> +17.1.5
> +Andres Gomez
> +
> +
> +
> +2017-07-28
> +17.1.6
> +Emil Velikov
> +
> +
> +
> +2017-08-11
> +17.1.7
> +Juan A. Suarez Romero
> +
> +
> +
> +2017-08-25
> +17.1.8
> +Andres Gomez
> +Final planned release for the 17.1 series
> +
> +
> +17.2
> +2017-07-21
> +17.2.0-rc1
> +Emil Velikov
> +
> +
> +
> +2017-07-28
> +17.2.0-rc2
> +Emil Velikov
> +
> +
> +
> +2017-08-04
> +17.2.0-rc3
> +Emil Velikov
> +
> +
> +
> +2017-08-11
> +17.2.0-rc4
> +Emil Velikov
> +May be promoted to 17.2.0 final
> +
> +
> +2017-08-25
> +17.2.1
> +Emil Velikov
> +
>  
>  
>  
> -- 
> 2.11.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] bin/get-fixes-pick-list.sh: don't warn if more than one, go over them

2017-05-07 Thread Eric Engestrom 
On Saturday, 2017-05-06 17:09:35 +0300, Andres Gomez wrote:
> If an identified commit was having more than one fix, we would warn
> about that and only treat the first.
> 
> Now, we don't warn but treat all of them.

This was on my todo list, thanks for fixing this :)

> 
> Signed-off-by: Andres Gomez 
> ---
>  bin/get-fixes-pick-list.sh | 51 
> +++---
>  1 file changed, 26 insertions(+), 25 deletions(-)
> 
> diff --git a/bin/get-fixes-pick-list.sh b/bin/get-fixes-pick-list.sh
> index f1398f320c..cf95f28377 100755
> --- a/bin/get-fixes-pick-list.sh
> +++ b/bin/get-fixes-pick-list.sh
> @@ -33,37 +33,38 @@ do
>  
>   # For each one try to extract the tag
>   fixes_count=`git show $sha | grep -i "fixes:" | wc -l`
> - if [ "x$fixes_count" != x1 ] ; then
> - printf "WARNING: Commit \"%s\" has more than one Fixes tag\n" \
> -"`git log -n1 --pretty=oneline $sha`"
> - fi
> - fixes=`git show $sha | grep -i "fixes:" | head -n 1`
> - # The following sed/cut combination is borrowed from GregKH
> - id=`echo ${fixes} | sed -e 's/^[ \t]*//' | cut -f 2 -d ':' | sed -e 
> 's/^[ \t]*//' | cut -f 1 -d ' '`
> + while [ $fixes_count -gt 0 ] ; do
> + fixes=`git show $sha | grep -i "fixes:" | tail -n $fixes_count 
> | head -n 1`

This will break when there are line breaks within a `Fixes:`. Consider
something like the following:

Fixes: ddb99127a6f6c6d0284f3395e0b06aed575f0ecd ("egl/x11: Honor the
   EGL_PLATFORM_X11_SCREEN_EXT attribute")

I'm not sure how best to fix this though. Replace newlines that are not
followed by `Fixes:` with a space, before splitting and parsing each
line?

I guess this is better than what we currently have, and it won't fail
more than it would before, so it's good enough for now;
Reviewed-by: Eric Engestrom 

> + fixes_count=$(($fixes_count-1))
> + # The following sed/cut combination is borrowed from GregKH
> + id=`echo ${fixes} | sed -e 's/^[ \t]*//' | cut -f 2 -d ':' | 
> sed -e 's/^[ \t]*//' | cut -f 1 -d ' '`
>  
> - # Bail out if we cannot find suitable id.
> - # Any specific validation the $id is valid and not some junk, is
> - # implied with the follow up code
> - if [ "x$id" = x ] ; then
> - continue
> - fi
> + # Bail out if we cannot find suitable id.
> + # Any specific validation the $id is valid and not some junk, is
> + # implied with the follow up code
> + if [ "x$id" = x ] ; then
> + continue
> + fi
>  
> - # Check if the offending commit is in branch.
> + # Check if the offending commit is in branch.
>  
> - # Be that cherry-picked ...
> - # ... or landed before the branchpoint.
> - if grep -q ^$id already_picked ||
> -grep -q ^$id already_landed ; then
> + # Be that cherry-picked ...
> + # ... or landed before the branchpoint.
> + if grep -q ^$id already_picked ||
> +grep -q ^$id already_landed ; then
>  
> - # Finally nominate the fix if it hasn't landed yet.
> - if grep -q ^$sha already_picked ; then
> - continue
> + # Finally nominate the fix if it hasn't landed yet.
> + if grep -q ^$sha already_picked ; then
> + continue
> + fi
> +
> + printf "Commit \"%s\" fixes %s\n" \
> +"`git log -n1 --pretty=oneline $sha`" \
> +"$id"
> + fixes_count=0

Ha, I'm 90% sure I would've missed this!

>   fi
>  
> - printf "Commit \"%s\" fixes %s\n" \
> -"`git log -n1 --pretty=oneline $sha`" \
> -"$id"
> - fi
> + done
>  
>  done
>  
> -- 
> 2.11.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Fix -Wint-to-pointer-cast

2017-05-07 Thread Eric Engestrom 
On Friday, 2017-05-05 12:27:03 -0700, Chad Versace wrote:
> main/egldisplay.c: In function '_eglParseX11DisplayAttribList':
> main/egldisplay.c:491:38: warning: cast to pointer from integer of different 
> size [-Wint-to-pointer-cast]
>   display->Options.Platform = (void *)value;
> 
> The fix: cast to uinptr_t before void*.
>   ^
> Fixes: ddb99127 egl/x11: Honor the EGL_PLATFORM_X11_SCREEN_EXT attribute
> Cc: Adam Jackson 

Reviewed-by: Eric Engestrom 

> ---
>  src/egl/main/egldisplay.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisplay.c
> index b047a5de42..56f802b1aa 100644
> --- a/src/egl/main/egldisplay.c
> +++ b/src/egl/main/egldisplay.c
> @@ -488,7 +488,7 @@ _eglParseX11DisplayAttribList(_EGLDisplay *display, const 
> EGLint *attrib_list)
> * EGL_PLATFORM_X11_SCREEN_EXT, which is optional.
> */
>if (attrib == EGL_PLATFORM_X11_SCREEN_EXT) {
> - display->Options.Platform = (void *)value;
> + display->Options.Platform = (void *)(uintptr_t)value;
>} else {
>   _eglError(EGL_BAD_ATTRIBUTE, "eglGetPlatformDisplay");
>   return EGL_FALSE;
> -- 
> 2.12.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3 v2] r600g: get rid of dummy pixel shader

2017-05-07 Thread Dieter Nützel 

Am 26.04.2017 14:37, schrieb tournier.elie:

Hello,

I'm not an r600g person but I will be pleased to have a look to this 
work.


Hello Elie,

I know, read most of your posts about your 'former' fp64 lib which was 
indeed HW-agnostic.



I'm currently working on the fp64 for r600g. Hope to be able to send a
series in fews days.


Do you have something handy for testing?
My r600g (Turks XT / HD 6670) times run out... ;-)
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/950505-radeon-rx-550-amdgpu-pro-vs-drm-next-mesa-17-2-dev?p=950577#post950577


The fp64 code is not HW specific, I can test it on my laptop with an
Intel card. I don't even own a r600g card.


Do you want my above card for testing r600g?


Have a nice day.


Have a nice spring, late here in old (northern) Europe...

Dieter


On 25 April 2017 at 03:00, Dieter Nützel  wrote:

Am 12.04.2017 22:06, schrieb Dave Airlie:


On 13 April 2017 at 06:03, Markus Trippelsdorf 


wrote:


On 2017.04.12 at 20:45 +0100, Emil Velikov wrote:


On 12 April 2017 at 20:34, Constantine Kharlamov 


wrote:

>> I suspect this breaks because r600 more often fails to
>> compile some shaders,
>> and the hw requires a fragment shader and we use the empty one as a
>> fallback in that case.
>
> Ok, that wasn't obvious, I running the system with the patchset on
> HD5730, including
> piglit testing — so far is fine.
>
If in doubt ask the bug reporter(s) to test a patch on their 
machines.



Well, the question is why bother with this legacy code at all?
I would expect a much more conservative approach. Except for 
essential

patches to keep the hardware running, everything else should be
rejected. Nobody is expecting new features for this ancient hardware
anyway.



I do have 90% of GL4.3 for evergreen and newer done in a branch,

It's just a lack of time to fix the last few hangs and motivate 
myself

to get it posted/reviewied.

Then of course getting sb support.

Dave.



Hello Dave,

can you please send the link to your latest work on this?
So someone (we) can have a look and learn/maybe fix it.
Maybe Elie step in and offer fp64 for r600g if he has some time left.
My times on r600g come to an end...
RX 580, 8 GB, Nitro+ is coming on Friday/Saturday, Yea ;-)

Then I have to decide if I hold the Turks XT (6670) or to comp it.

Greetings around the world!

Dieter

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

Re: [Mesa-dev] [PATCH v2 21/27] st/xvmc: add DRI3 support

2017-05-07 Thread Ilia Mirkin 
Tested-by: Ilia Mirkin 

Seems to work with a NV44A (with some hacks to deal with its
non-pcie/agp-ness, but that's entirely separate). The "background"
area when entering full-screen mode appears to not get cleared with
dri3 like it does with dri2, although I think I've seen that with
vdpau as well on newer chips. Probably an issue core to VL rather than
something xvmc-specific. Also tested that this code falls back to dri2
properly when dri3 is not enabled.

Cheers,

  -ilia


On Thu, May 4, 2017 at 12:46 PM, Ilia Mirkin  wrote:
> On Thu, May 4, 2017 at 12:33 PM, Emil Velikov  
> wrote:
>> UNTESTED.
>>
>> Ilia, can you give this a try?
>
> Weekend at the earliest.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa] egl: avoid dereferencing a null display

2017-05-07 Thread Eric Engestrom 
Fixes: ddb99127a6f6c ("egl/x11: Honor the EGL_PLATFORM_X11_SCREEN_EXT 
attribute")
Signed-off-by: Eric Engestrom 
---
 src/egl/main/egldisplay.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisplay.c
index b047a5de42..c4b0fd6aab 100644
--- a/src/egl/main/egldisplay.c
+++ b/src/egl/main/egldisplay.c
@@ -505,8 +505,10 @@ _eglGetX11Display(Display *native_display,
_EGLDisplay *display = _eglFindDisplay(_EGL_PLATFORM_X11,
   native_display);
 
-   if (!display)
+   if (!display) {
   _eglError(EGL_BAD_ALLOC, "eglGetPlatformDisplay");
+  return NULL;
+   }
 
if (!_eglParseX11DisplayAttribList(display, attrib_list)) {
   return NULL;
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [PATCH 1/7] radv/meta: add srgb conversion to end of resolve shader.

2017-05-07 Thread Dave Airlie 
On 5 May 2017 at 01:46, Bas Nieuwenhuizen  wrote:
> Can't we just use a non-SRGB image view into the destination image?
> That should save some operations.

We could possibly here, but not in the subpass path, which a later
patch enables.

I wasn't sure it was worth the effort.

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

Re: [Mesa-dev] [PATCH 1/5] radv: set base/ranges for push constant loads.

2017-05-07 Thread Bas Nieuwenhuizen 
This series is

Reviewed-by: Bas Nieuwenhuizen 

On Fri, May 5, 2017 at 2:59 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This isn't necessary yet but I'd like to use the range in
> some future patches.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_meta_blit2d.c |  2 ++
>  src/amd/vulkan/radv_meta_buffer.c |  2 ++
>  src/amd/vulkan/radv_meta_bufimage.c   | 14 ++
>  src/amd/vulkan/radv_meta_resolve_cs.c |  4 
>  src/amd/vulkan/radv_query.c   |  2 ++
>  5 files changed, 24 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_meta_blit2d.c 
> b/src/amd/vulkan/radv_meta_blit2d.c
> index 10e20d2..473d2f2 100644
> --- a/src/amd/vulkan/radv_meta_blit2d.c
> +++ b/src/amd/vulkan/radv_meta_blit2d.c
> @@ -488,6 +488,8 @@ build_nir_buffer_fetch(struct nir_builder *b, struct 
> radv_device *device,
> sampler->data.binding = 0;
>
> nir_intrinsic_instr *width = nir_intrinsic_instr_create(b->shader, 
> nir_intrinsic_load_push_constant);
> +   nir_intrinsic_set_base(width, 0);
> +   nir_intrinsic_set_range(width, 4);
> width->src[0] = nir_src_for_ssa(nir_imm_int(b, 0));
> width->num_components = 1;
> nir_ssa_dest_init(>instr, >dest, 1, 32, "width");
> diff --git a/src/amd/vulkan/radv_meta_buffer.c 
> b/src/amd/vulkan/radv_meta_buffer.c
> index 0bb926f..68de81e 100644
> --- a/src/amd/vulkan/radv_meta_buffer.c
> +++ b/src/amd/vulkan/radv_meta_buffer.c
> @@ -36,6 +36,8 @@ build_buffer_fill_shader(struct radv_device *dev)
> nir_builder_instr_insert(, _buf->instr);
>
> nir_intrinsic_instr *load = nir_intrinsic_instr_create(b.shader, 
> nir_intrinsic_load_push_constant);
> +   nir_intrinsic_set_base(load, 0);
> +   nir_intrinsic_set_range(load, 4);
> load->src[0] = nir_src_for_ssa(nir_imm_int(, 0));
> load->num_components = 1;
> nir_ssa_dest_init(>instr, >dest, 1, 32, "fill_value");
> diff --git a/src/amd/vulkan/radv_meta_bufimage.c 
> b/src/amd/vulkan/radv_meta_bufimage.c
> index 1d491ac..a40d4b4 100644
> --- a/src/amd/vulkan/radv_meta_bufimage.c
> +++ b/src/amd/vulkan/radv_meta_bufimage.c
> @@ -68,12 +68,16 @@ build_nir_itob_compute_shader(struct radv_device *dev)
>
>
> nir_intrinsic_instr *offset = nir_intrinsic_instr_create(b.shader, 
> nir_intrinsic_load_push_constant);
> +   nir_intrinsic_set_base(offset, 0);
> +   nir_intrinsic_set_range(offset, 12);
> offset->src[0] = nir_src_for_ssa(nir_imm_int(, 0));
> offset->num_components = 2;
> nir_ssa_dest_init(>instr, >dest, 2, 32, "offset");
> nir_builder_instr_insert(, >instr);
>
> nir_intrinsic_instr *stride = nir_intrinsic_instr_create(b.shader, 
> nir_intrinsic_load_push_constant);
> +   nir_intrinsic_set_base(stride, 0);
> +   nir_intrinsic_set_range(stride, 12);
> stride->src[0] = nir_src_for_ssa(nir_imm_int(, 8));
> stride->num_components = 1;
> nir_ssa_dest_init(>instr, >dest, 1, 32, "stride");
> @@ -264,12 +268,16 @@ build_nir_btoi_compute_shader(struct radv_device *dev)
> nir_ssa_def *global_id = nir_iadd(, nir_imul(, wg_id, 
> block_size), invoc_id);
>
> nir_intrinsic_instr *offset = nir_intrinsic_instr_create(b.shader, 
> nir_intrinsic_load_push_constant);
> +   nir_intrinsic_set_base(offset, 0);
> +   nir_intrinsic_set_range(offset, 12);
> offset->src[0] = nir_src_for_ssa(nir_imm_int(, 0));
> offset->num_components = 2;
> nir_ssa_dest_init(>instr, >dest, 2, 32, "offset");
> nir_builder_instr_insert(, >instr);
>
> nir_intrinsic_instr *stride = nir_intrinsic_instr_create(b.shader, 
> nir_intrinsic_load_push_constant);
> +   nir_intrinsic_set_base(stride, 0);
> +   nir_intrinsic_set_range(stride, 12);
> stride->src[0] = nir_src_for_ssa(nir_imm_int(, 8));
> stride->num_components = 1;
> nir_ssa_dest_init(>instr, >dest, 1, 32, "stride");
> @@ -460,12 +468,16 @@ build_nir_itoi_compute_shader(struct radv_device *dev)
> nir_ssa_def *global_id = nir_iadd(, nir_imul(, wg_id, 
> block_size), invoc_id);
>
> nir_intrinsic_instr *src_offset = 
> nir_intrinsic_instr_create(b.shader, nir_intrinsic_load_push_constant);
> +   nir_intrinsic_set_base(src_offset, 0);
> +   nir_intrinsic_set_range(src_offset, 16);
> src_offset->src[0] = nir_src_for_ssa(nir_imm_int(, 0));
> src_offset->num_components = 2;
> nir_ssa_dest_init(_offset->instr, _offset->dest, 2, 32, 
> "src_offset");
> nir_builder_instr_insert(, _offset->instr);
>
> nir_intrinsic_instr *dst_offset = 
> nir_intrinsic_instr_create(b.shader, nir_intrinsic_load_push_constant);
> +   nir_intrinsic_set_base(dst_offset, 0);
> +   nir_intrinsic_set_range(dst_offset, 16);
> dst_offset->src[0] = nir_src_for_ssa(nir_imm_int(, 8));
>

Re: [Mesa-dev] [PATCH 1/7] radv/meta: add srgb conversion to end of resolve shader.

2017-05-07 Thread Bas Nieuwenhuizen 
This series is

Reviewed-by: Bas Nieuwenhuizen 

On Thu, May 4, 2017 at 5:27 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> If we are resolving into an srgb dest, we need to convert
> to linear so the store does the conversion back.
>
> This should fix some wierdness seen when we subresolves
> hit the compute path.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_meta_resolve_cs.c | 58 
> ---
>  src/amd/vulkan/radv_private.h |  1 +
>  src/amd/vulkan/vk_format.h|  7 +
>  3 files changed, 61 insertions(+), 5 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_resolve_cs.c 
> b/src/amd/vulkan/radv_meta_resolve_cs.c
> index dc4a1bb..99a3a06 100644
> --- a/src/amd/vulkan/radv_meta_resolve_cs.c
> +++ b/src/amd/vulkan/radv_meta_resolve_cs.c
> @@ -32,7 +32,7 @@
>  #include "vk_format.h"
>
>  static nir_shader *
> -build_resolve_compute_shader(struct radv_device *dev, bool is_integer, int 
> samples)
> +build_resolve_compute_shader(struct radv_device *dev, bool is_integer, bool 
> is_srgb, int samples)
>  {
> nir_builder b;
> char name[64];
> @@ -45,7 +45,7 @@ build_resolve_compute_shader(struct radv_device *dev, bool 
> is_integer, int sampl
>  false,
>  false,
>  GLSL_TYPE_FLOAT);
> -   snprintf(name, 64, "meta_resolve_cs-%d-%s", samples, is_integer ? 
> "int" : "float");
> +   snprintf(name, 64, "meta_resolve_cs-%d-%s", samples, is_integer ? 
> "int" : (is_srgb ? "srgb" : "float"));
> nir_builder_init_simple_shader(, NULL, MESA_SHADER_COMPUTE, NULL);
> b.shader->info->name = ralloc_strdup(b.shader, name);
> b.shader->info->cs.local_size[0] = 16;
> @@ -158,6 +158,44 @@ build_resolve_compute_shader(struct radv_device *dev, 
> bool is_integer, int sampl
> b.cursor = nir_after_cf_node(_if->cf_node);
>
> nir_ssa_def *newv = nir_load_var(, color);
> +
> +   if (is_srgb) {
> +   nir_const_value v;
> +   unsigned i;
> +   v.u32[0] = 0x3b4d2e1c; // 0.00313080009
> +
> +   nir_ssa_def *cmp[3];
> +   for (i = 0; i < 3; i++)
> +   cmp[i] = nir_flt(, nir_channel(, newv, i),
> +nir_build_imm(, 1, 32, v));
> +
> +   nir_ssa_def *ltvals[3];
> +   v.f32[0] = 12.92;
> +   for (i = 0; i < 3; i++)
> +   ltvals[i] = nir_fmul(, nir_channel(, newv, i),
> +nir_build_imm(, 1, 32, v));
> +
> +   nir_ssa_def *gtvals[3];
> +
> +   for (i = 0; i < 3; i++) {
> +   v.f32[0] = 1.0/2.4;
> +   gtvals[i] = nir_fpow(, nir_channel(, newv, i),
> +nir_build_imm(, 1, 32, v));
> +   v.f32[0] = 1.055;
> +   gtvals[i] = nir_fmul(, gtvals[i],
> +nir_build_imm(, 1, 32, v));
> +   v.f32[0] = 0.055;
> +   gtvals[i] = nir_fsub(, gtvals[i],
> +nir_build_imm(, 1, 32, v));
> +   }
> +
> +   nir_ssa_def *comp[4];
> +   for (i = 0; i < 3; i++)
> +   comp[i] = nir_bcsel(, cmp[i], ltvals[i], gtvals[i]);
> +   comp[3] = nir_channels(, newv, 3);
> +   newv = nir_vec(, comp, 4);
> +   }
> +
> nir_ssa_def *coord = nir_iadd(, global_id, _offset->dest.ssa);
> nir_intrinsic_instr *store = nir_intrinsic_instr_create(b.shader, 
> nir_intrinsic_image_store);
> store->src[0] = nir_src_for_ssa(coord);
> @@ -230,12 +268,13 @@ static VkResult
>  create_resolve_pipeline(struct radv_device *device,
> int samples,
> bool is_integer,
> +   bool is_srgb,
> VkPipeline *pipeline)
>  {
> VkResult result;
> struct radv_shader_module cs = { .nir = NULL };
>
> -   cs.nir = build_resolve_compute_shader(device, is_integer, samples);
> +   cs.nir = build_resolve_compute_shader(device, is_integer, is_srgb, 
> samples);
>
> /* compute shader */
>
> @@ -282,12 +321,15 @@ radv_device_init_meta_resolve_compute_state(struct 
> radv_device *device)
> for (uint32_t i = 0; i < MAX_SAMPLES_LOG2; ++i) {
> uint32_t samples = 1 << i;
>
> -   res = create_resolve_pipeline(device, samples, false,
> +   res = create_resolve_pipeline(device, samples, false, false,
>   
>

[Mesa-dev] [PATCH] util: move ALWAYS_INLINE macro to util/macro.h

2017-05-07 Thread Timothy Arceri 
Also added clang check.

macro.h is include by p_compiler.h so no other change is needed.
---
 src/gallium/include/pipe/p_compiler.h | 11 ---
 src/util/macros.h | 11 +++
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/gallium/include/pipe/p_compiler.h 
b/src/gallium/include/pipe/p_compiler.h
index 0d7b014..2869517 100644
--- a/src/gallium/include/pipe/p_compiler.h
+++ b/src/gallium/include/pipe/p_compiler.h
@@ -86,31 +86,20 @@ typedef unsigned char boolean;
 #endif
 
 #ifndef va_copy
 #ifdef __va_copy
 #define va_copy(dest, src) __va_copy((dest), (src))
 #else
 #define va_copy(dest, src) (dest) = (src)
 #endif
 #endif
 
-/* Forced function inlining */
-#ifndef ALWAYS_INLINE
-#  ifdef __GNUC__
-#define ALWAYS_INLINE inline __attribute__((always_inline))
-#  elif defined(_MSC_VER)
-#define ALWAYS_INLINE __forceinline
-#  else
-#define ALWAYS_INLINE inline
-#  endif
-#endif
-
 
 /* XXX: Use standard `__func__` instead */
 #ifndef __FUNCTION__
 #  define __FUNCTION__ __func__
 #endif
 
 
 /* This should match linux gcc cdecl semantics everywhere, so that we
  * just codegen one calling convention on all platforms.
  */
diff --git a/src/util/macros.h b/src/util/macros.h
index 6f55ac6..a10f1de 100644
--- a/src/util/macros.h
+++ b/src/util/macros.h
@@ -129,20 +129,31 @@ do {   \
 #else
 #define PRINTFLIKE(f, a)
 #endif
 
 #ifdef HAVE_FUNC_ATTRIBUTE_MALLOC
 #define MALLOCLIKE __attribute__((__malloc__))
 #else
 #define MALLOCLIKE
 #endif
 
+/* Forced function inlining */
+#ifndef ALWAYS_INLINE
+#  if defined(__GNUC__) || defined(__clang__)
+#define ALWAYS_INLINE inline __attribute__((always_inline))
+#  elif defined(_MSC_VER)
+#define ALWAYS_INLINE __forceinline
+#  else
+#define ALWAYS_INLINE inline
+#  endif
+#endif
+
 /* Used to optionally mark structures with misaligned elements or size as
  * packed, to trade off performance for space.
  */
 #ifdef HAVE_FUNC_ATTRIBUTE_PACKED
 #define PACKED __attribute__((__packed__))
 #else
 #define PACKED
 #endif
 
 /* Attribute pure is used for functions that have no effects other than their
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH 7/7] mesa: add KHR_no_error support for glUseProgram

2017-05-07 Thread Timothy Arceri 

On 08/05/17 06:29, Nicolai Hähnle wrote:

On 04.05.2017 16:28, Nicolai Hähnle wrote:

On 04.05.2017 05:34, Timothy Arceri wrote:



On 04/05/17 13:31, Dave Airlie wrote:

+/* The ARB_separate_shader_object spec says:
+ *
+ * "The executable code for an individual shader stage is taken
from
+ * the current program for that stage.  If there is a current
program
+ * object established by UseProgram, that program is considered
current
+ * for all stages.  Otherwise, if there is a bound program
pipeline
+ * object (section 2.14.PPO), the program bound to the 
appropriate

+ * stage of the pipeline object is considered current."
+ */
+#define
USE_PROGRAM(no_error)\
+   if (program)
{\
+  /* Attach shader state to the binding point
*/ \
+  _mesa_reference_pipeline_object(ctx, >_Shader,
>Shader); \
+  /* Update the program
*/   \
+  _mesa_use_shader_program(ctx,
shProg); \
+   } else
{  \
+  /* Must be done first: detach the progam
*/\
+  _mesa_use_shader_program(ctx,
shProg); \
+  /* Unattach shader_state binding point
*/  \
+  _mesa_reference_pipeline_object(ctx,
>_Shader,\
+
ctx->Pipeline.Default);\
+  /* If a pipeline was bound, rebind it
*/   \
+  if (ctx->Pipeline.Current)
{   \
+
_mesa_BindProgramPipeline##no_error(ctx->Pipeline.Current->Name);   \
+
}
\
+
}
\
+


why the macro, inline functions are a thing, or just one common
function that both entrypoints call.



So that we can avoid adding an if to call

_mesa_BindProgramPipeline_no_error vs _mesa_BindProgramPipeline


I have to say I also don't like this very much. Do you have benchmarks
to back up the usefulness of this?

This is where C++ templates would be great, because there could just be
a boolean no_error template parameter. Maybe there's a way to get
somewhere similar in C, even if it requires some compiler extensions?


I thought about this some more, and I feel that at least with gcc/clang, 
the always_inline attributes provides a reasonably elegant solution. I 
mean this code pattern:


__attribute((always_inline))
static inline void useprogram(GLuint program, bool check_error)
{
   GET_CURRENT_CTX(ctx);

   ...
}

void GLAPIENTRY
_mesa_UseProgram(GLuint program)
{
   useprogram(program, true);
}

void GLAPIENTRY
_mesa_UseProgram_no_error(GLuint program)
{
   useprogram(program, false);
}

This would avoid the code duplication and macro magic that I'm finding a 
bit worrisome while still getting fully optimized code in both paths. 
This could also be used to clean up some of the other _no_error variants. >
There's a bit of a question of other compiler support. At least judging 
from the online docs, MSVC's __forceinline should have the same effect, 
so it looks like all the relevant bases are covered.


What do you think?


I'm happy with this solution, thanks. I'll send out a new version for 
review.




Cheers,
Nicolai






Cheers,
Nicolai





Dave.


+void GLAPIENTRY
+_mesa_UseProgram_no_error(GLuint program)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   struct gl_shader_program *shProg = NULL;
+
+   if (program) {
+  shProg = _mesa_lookup_shader_program(ctx, program);
+   }
+
+   USE_PROGRAM(_no_error)
+}
+

  void GLAPIENTRY
  _mesa_UseProgram(GLuint program)
  {
 GET_CURRENT_CONTEXT(ctx);
 struct gl_shader_program *shProg = NULL;

 if (MESA_VERBOSE & VERBOSE_API)
_mesa_debug(ctx, "glUseProgram %u\n", program);

@@ -1875,44 +1915,21 @@ _mesa_UseProgram(GLuint program)
   return;
}

  #ifdef DEBUG
if (ctx->_Shader->Flags & GLSL_USE_PROG) {
   print_shader_info(shProg);
}
  #endif
 }

-   /* The ARB_separate_shader_object spec says:
-*
-* "The executable code for an individual shader stage is
taken from
-* the current program for that stage.  If there is a current
program
-* object established by UseProgram, that program is
considered current
-* for all stages.  Otherwise, if there is a bound program
pipeline
-* object (section 2.14.PPO), the program bound to the
appropriate
-* stage of the pipeline object is considered current."
-*/
-   if (program) {
-  /* Attach shader state to the binding point */
-  _mesa_reference_pipeline_object(ctx, >_Shader,
>Shader);
-  /* Update the program */
-  _mesa_use_shader_program(ctx, shProg);
-   } else {
-  /* Must be done first: detach the progam */
-

[Mesa-dev] [Bug 100960] Special block from Minecraft mod rendered out of place

2017-05-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100960

--- Comment #2 from Fabian Maurer  ---
Created attachment 131245
  --> https://bugs.freedesktop.org/attachment.cgi?id=131245=edit
screenshot(broken) on linux

-- 
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 100960] Special block from Minecraft mod rendered out of place

2017-05-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100960

--- Comment #1 from Fabian Maurer  ---
Created attachment 131244
  --> https://bugs.freedesktop.org/attachment.cgi?id=131244=edit
screenshot (working) on windows

-- 
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 100960] Special block from Minecraft mod rendered out of place

2017-05-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100960

Bug ID: 100960
   Summary: Special block from Minecraft mod rendered out of place
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: dark.shad...@web.de
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 131243
  --> https://bugs.freedesktop.org/attachment.cgi?id=131243=edit
Compressed apitrace, 142MB unpacked

Running a certain mod (ProjectE) with Minecraft results in a special block
being rendered to high. It's hard to describe, please check the apitrace and
screenshots for more info.
LIBGL_ALWAYS_SOFTWARE doesn't change the result.

Apitrace attached.
Images in following comments, both taken from frame 850 of the trace file:
-One on linux
-One on win10 with latest closed source AMD drivers.

System the bug was tested on:
- Arch Linux 64bit
- Linux 4.10.13, AMDGPU driver
- Mesa 17.2.0-devel (git-ccf9669cc1) / Mesa 17.0.5
- Radeon R9 285

-- 
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 7/7] mesa: add KHR_no_error support for glUseProgram

2017-05-07 Thread Nicolai Hähnle 

On 04.05.2017 16:28, Nicolai Hähnle wrote:

On 04.05.2017 05:34, Timothy Arceri wrote:



On 04/05/17 13:31, Dave Airlie wrote:

+/* The ARB_separate_shader_object spec says:
+ *
+ * "The executable code for an individual shader stage is taken
from
+ * the current program for that stage.  If there is a current
program
+ * object established by UseProgram, that program is considered
current
+ * for all stages.  Otherwise, if there is a bound program
pipeline
+ * object (section 2.14.PPO), the program bound to the appropriate
+ * stage of the pipeline object is considered current."
+ */
+#define
USE_PROGRAM(no_error)\
+   if (program)
{\
+  /* Attach shader state to the binding point
*/ \
+  _mesa_reference_pipeline_object(ctx, >_Shader,
>Shader); \
+  /* Update the program
*/   \
+  _mesa_use_shader_program(ctx,
shProg); \
+   } else
{  \
+  /* Must be done first: detach the progam
*/\
+  _mesa_use_shader_program(ctx,
shProg); \
+  /* Unattach shader_state binding point
*/  \
+  _mesa_reference_pipeline_object(ctx,
>_Shader,\
+
ctx->Pipeline.Default);\
+  /* If a pipeline was bound, rebind it
*/   \
+  if (ctx->Pipeline.Current)
{   \
+
_mesa_BindProgramPipeline##no_error(ctx->Pipeline.Current->Name);   \
+
}
\
+
}
\
+


why the macro, inline functions are a thing, or just one common
function that both entrypoints call.



So that we can avoid adding an if to call

_mesa_BindProgramPipeline_no_error vs _mesa_BindProgramPipeline


I have to say I also don't like this very much. Do you have benchmarks
to back up the usefulness of this?

This is where C++ templates would be great, because there could just be
a boolean no_error template parameter. Maybe there's a way to get
somewhere similar in C, even if it requires some compiler extensions?


I thought about this some more, and I feel that at least with gcc/clang, 
the always_inline attributes provides a reasonably elegant solution. I 
mean this code pattern:


   __attribute((always_inline))
   static inline void useprogram(GLuint program, bool check_error)
   {
  GET_CURRENT_CTX(ctx);

  ...
   }

   void GLAPIENTRY
   _mesa_UseProgram(GLuint program)
   {
  useprogram(program, true);
   }

   void GLAPIENTRY
   _mesa_UseProgram_no_error(GLuint program)
   {
  useprogram(program, false);
   }

This would avoid the code duplication and macro magic that I'm finding a 
bit worrisome while still getting fully optimized code in both paths. 
This could also be used to clean up some of the other _no_error variants.


There's a bit of a question of other compiler support. At least judging 
from the online docs, MSVC's __forceinline should have the same effect, 
so it looks like all the relevant bases are covered.


What do you think?

Cheers,
Nicolai






Cheers,
Nicolai





Dave.


+void GLAPIENTRY
+_mesa_UseProgram_no_error(GLuint program)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   struct gl_shader_program *shProg = NULL;
+
+   if (program) {
+  shProg = _mesa_lookup_shader_program(ctx, program);
+   }
+
+   USE_PROGRAM(_no_error)
+}
+

  void GLAPIENTRY
  _mesa_UseProgram(GLuint program)
  {
 GET_CURRENT_CONTEXT(ctx);
 struct gl_shader_program *shProg = NULL;

 if (MESA_VERBOSE & VERBOSE_API)
_mesa_debug(ctx, "glUseProgram %u\n", program);

@@ -1875,44 +1915,21 @@ _mesa_UseProgram(GLuint program)
   return;
}

  #ifdef DEBUG
if (ctx->_Shader->Flags & GLSL_USE_PROG) {
   print_shader_info(shProg);
}
  #endif
 }

-   /* The ARB_separate_shader_object spec says:
-*
-* "The executable code for an individual shader stage is
taken from
-* the current program for that stage.  If there is a current
program
-* object established by UseProgram, that program is
considered current
-* for all stages.  Otherwise, if there is a bound program
pipeline
-* object (section 2.14.PPO), the program bound to the
appropriate
-* stage of the pipeline object is considered current."
-*/
-   if (program) {
-  /* Attach shader state to the binding point */
-  _mesa_reference_pipeline_object(ctx, >_Shader,
>Shader);
-  /* Update the program */
-  _mesa_use_shader_program(ctx, shProg);
-   } else {
-  /* Must be done first: detach the progam */
-  _mesa_use_shader_program(ctx, shProg);
-  /* Unattach shader_state binding point */
-  _mesa_reference_pipeline_object(ctx, >_Shader,
ctx->Pipeline.Default);
-

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

2017-05-07 Thread AppVeyor 


Build mesa 4285 completed



Commit dab6a2dfd9 by Jose Fonseca on 5/7/2017 4:58 PM:

nir: Fix missing snprintf symbol on Windows.\n\nCopy nir_print.c's snprintf definition for now, to unbreak Windows\nbuilds.\n\nWe can and should cleanup all snprintf definitions in a follow up\nchange, but I rather not leave Windows build broken any further.\n\nTrivial.


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH 02/13] mesa/dri: always link against shared glapi

2017-05-07 Thread Aaron Watry 
I ran into the same thing...  Do you by chance have '--with-dri-driverdir='
in your configure command?

I had '--prefix=/usr/local' and '--with-dri-driverdir=/usr/local/dri', and
removing the --with-dri-driverdir fixed my build.

--Aaron

On Sat, May 6, 2017 at 7:48 PM, Grazvydas Ignotas  wrote:

> This causes a strange build failure for me:
>
> make[7]: Entering directory '/home/notaz/src/radeon/mesa/
> src/mesa/drivers/dri'
> make[7]: Nothing to be done for 'install-exec-am'.
>  /bin/mkdir -p '/opt/xorg/lib/dri/'
>  /bin/bash ../../../../libtool   --mode=install /usr/bin/install -c
> mesa_dri_drivers.la '/opt/xorg/lib/dri/'
> libtool:   error: error: cannot install 'mesa_dri_drivers.la' to a
> directory not ending in /opt/xorg/lib/dri/
> Makefile:651: recipe for target 'install-driLTLIBRARIES' failed
>
> And no it's not a missed "make clean" that google might suggest, I've
> long learned to use "git clean -fdx" before building mesa...
>
> Gražvydas
>
>
> On Fri, Apr 28, 2017 at 4:14 PM, Emil Velikov 
> wrote:
> > From: Emil Velikov 
> >
> > Analogous to previous commit. Check with the extensive commit
> > description and bug report referenced.
> >
> > Cc: mesa-sta...@lists.freedesktop.org
> > Signed-off-by: Emil Velikov 
> > ---
> >  src/mesa/drivers/dri/Makefile.am | 16 +---
> >  1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/Makefile.am b/src/mesa/drivers/dri/
> Makefile.am
> > index 1c6dd08a85d..fb0fc3258bf 100644
> > --- a/src/mesa/drivers/dri/Makefile.am
> > +++ b/src/mesa/drivers/dri/Makefile.am
> > @@ -6,12 +6,9 @@ MEGADRIVERS_DEPS =
> >
> >  SUBDIRS+=common
> >
> > -# On Android, we need to explicitly link to libglapi.so.
> > -if HAVE_ANDROID
> >  if HAVE_SHARED_GLAPI
> >  SHARED_GLAPI_LIB = $(top_builddir)/src/mapi/shared-glapi/libglapi.la
> >  endif
> > -endif
> >
> >  if HAVE_I915_DRI
> >  SUBDIRS += i915
> > @@ -59,10 +56,15 @@ driinclude_HEADERS = \
> >  nodist_EXTRA_mesa_dri_drivers_la_SOURCES = dummy.cpp
> >  mesa_dri_drivers_la_SOURCES =
> >  mesa_dri_drivers_la_LDFLAGS = \
> > --module -avoid-version -shared -shrext .so \
> > -$(BSYMBOLIC) \
> > -$(GC_SECTIONS) \
> > -$()
> > +   -shared \
> > +   -shrext .so \
> > +   -module \
> > +   -no-undefined \
> > +   -avoid-version \
> > +   $(BSYMBOLIC) \
> > +   $(GC_SECTIONS) \
> > +   $(LD_NO_UNDEFINED)
> > +
> >  mesa_dri_drivers_la_LIBADD = \
> >  ../../libmesa.la \
> >  common/libmegadriver_stub.la \
> > --
> > 2.12.1
> >
> > ___
> > 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] [AppVeyor] mesa master #4283 failed

2017-05-07 Thread AppVeyor 



Build mesa 4283 failed


Commit c297e68828 by Dave Airlie on 4/28/2017 6:17 AM:

radv: set PERF_MOD in sample state like radeonsi.\n\nThis just aligns the code with radeonsi.\n\nReviewed-by: Bas Nieuwenhuizen \nSigned-off-by: Dave Airlie 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH] radv: apply the tess+GS hang workaround to Polaris12 as well

2017-05-07 Thread Bas Nieuwenhuizen 
Reviewed-by: Bas Nieuwenhuizen 

On Sun, May 7, 2017 at 11:54 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> As I pointed out for radeonsi, and AMD confirmed, so fix this
> in radv as well.
>
> Cc: "17.1" 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/si_cmd_buffer.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
> index 1382272..d94e23b 100644
> --- a/src/amd/vulkan/si_cmd_buffer.c
> +++ b/src/amd/vulkan/si_cmd_buffer.c
> @@ -672,7 +672,8 @@ si_get_ia_multi_vgt_param(struct radv_cmd_buffer 
> *cmd_buffer,
> if (family == CHIP_TONGA ||
> family == CHIP_FIJI ||
> family == CHIP_POLARIS10 ||
> -   family == CHIP_POLARIS11)
> +   family == CHIP_POLARIS11 ||
> +   family == CHIP_POLARIS12)
> partial_vs_wave = true;
> } else {
> partial_vs_wave = true;
> --
> 2.7.4
>
> ___
> 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] radv: apply the tess+GS hang workaround to Polaris12 as well

2017-05-07 Thread Dave Airlie 
From: Dave Airlie 

As I pointed out for radeonsi, and AMD confirmed, so fix this
in radv as well.

Cc: "17.1" 
Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/si_cmd_buffer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index 1382272..d94e23b 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -672,7 +672,8 @@ si_get_ia_multi_vgt_param(struct radv_cmd_buffer 
*cmd_buffer,
if (family == CHIP_TONGA ||
family == CHIP_FIJI ||
family == CHIP_POLARIS10 ||
-   family == CHIP_POLARIS11)
+   family == CHIP_POLARIS11 ||
+   family == CHIP_POLARIS12)
partial_vs_wave = true;
} else {
partial_vs_wave = true;
-- 
2.7.4

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