[Mesa-dev] [PATCH] docs: update shading.html

2018-05-13 Thread Timothy Arceri 
This just drops a buch of outdated information.
---
 docs/shading.html | 104 +-
 1 file changed, 2 insertions(+), 102 deletions(-)

diff --git a/docs/shading.html b/docs/shading.html
index a0bbe997c1b..0d61c9df3ea 100644
--- a/docs/shading.html
+++ b/docs/shading.html
@@ -14,10 +14,10 @@
 
 
 
-Shading Language Support
+OpenGL Shading Language
 
 
-This page describes the features and status of Mesa's support for the
+This page describes some features from Mesa's implementation of the
 https://opengl.org/documentation/glsl/;>
 OpenGL Shading Language.
 
@@ -27,12 +27,7 @@ Contents
 
 
 Environment variables
-GLSL 1.40 support
-Unsupported Features
-Implementation Notes
-Programming Hints
 Stand-alone GLSL Compiler
-Compiler Implementation
 Compiler Validation
 
 
@@ -94,83 +89,6 @@ Notably, this captures linked GLSL shaders - with all stages 
together -
 as well as ARB programs.
 
 
-GLSL Version
-
-
-The GLSL compiler currently supports version 3.30 of the shading language.
-
-
-
-Several GLSL extensions are also supported:
-
-
-GL_ARB_draw_buffers
-GL_ARB_fragment_coord_conventions
-GL_ARB_shader_bit_encoding
-
-
-
-Unsupported Features
-
-XXX update this section
-
-
-The following features of the shading language are not yet fully supported
-in Mesa:
-
-
-
-Linking of multiple shaders does not always work.  Currently, linking
-is implemented through shader concatenation and re-compiling.  This
-doesn't always work because of some #pragma and preprocessor issues.
-The gl_Color and gl_SecondaryColor varying vars are interpolated
-without perspective correction
-
-
-
-All other major features of the shading language should function.
-
-
-
-Implementation Notes
-
-
-Shading language programs are compiled into low-level programs
-very similar to those of GL_ARB_vertex/fragment_program.
-All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full
-float[4] registers.
-Float constants and variables are packed so that up to four floats
-can occupy one program parameter/register.
-All function calls are inlined.
-Shaders which use too many registers will not compile.
-The quality of generated code is pretty good, register usage is fair.
-Shader error detection and reporting of errors (InfoLog) is not
-very good yet.
-The ftransform() function doesn't necessarily match the results of
-fixed-function transformation.
-
-
-
-These issues will be addressed/resolved in the future.
-
-
-
-Programming Hints
-
-
-Use the built-in library functions whenever possible.
-For example, instead of writing this:
-
-float x = 1.0 / sqrt(y);
-
-Write this:
-
-float x = inversesqrt(y);
-
-
-
-
-
 Stand-alone GLSL Compiler
 
 
@@ -211,24 +129,6 @@ without any header or separator
 --version - [Mandatory] define the GLSL version to use
 
 
-
-Compiler Implementation
-
-
-The source code for Mesa's shading language compiler is in the
-src/compiler/glsl/ directory.
-
-
-
-XXX provide some info about the compiler
-
-
-
-The final vertex and fragment programs may be interpreted in software
-(see prog_execute.c) or translated into a specific hardware architecture
-(see drivers/dri/i915/i915_fragprog.c for example).
-
-
 Compiler Validation
 
 
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH] radv: Translate logic ops.

2018-05-13 Thread Nicholas Miell 

On 05/13/2018 06:14 PM, Bas Nieuwenhuizen wrote:

-#define V_028808_X_0X00 0x00
-#define V_028808_X_0X05 0x05
-#define V_028808_X_0X0A 0x0A
-#define V_028808_X_0X0F 0x0F
-#define V_028808_X_0X11 0x11
-#define V_028808_X_0X22 0x22
-#define V_028808_X_0X33 0x33
-#define V_028808_X_0X44 0x44
-#define V_028808_X_0X50 0x50
-#define V_028808_X_0X55 0x55
-#define V_028808_X_0X5A 0x5A
-#define V_028808_X_0X5F 0x5F
-#define V_028808_X_0X66 0x66
-#define V_028808_X_0X77 0x77
-#define V_028808_X_0X88 0x88
-#define V_028808_X_0X99 0x99
-#define V_028808_X_0XA0 0xA0
-#define V_028808_X_0XA5 0xA5
-#define V_028808_X_0XAA 0xAA
-#define V_028808_X_0XAF 0xAF
-#define V_028808_X_0XBB 0xBB
-#define V_028808_X_0XCC 0xCC
-#define V_028808_X_0XDD 0xDD
-#define V_028808_X_0XEE 0xEE
-#define V_028808_X_0XF0 0xF0
-#define V_028808_X_0XF5 0xF5
-#define V_028808_X_0XFA 0xFA
-#define V_028808_X_0XFF 0xFF
+#define V_028808_ROP3_CLEAR 0x00
+#define V_028808_ROP3_NOR   0x11
+#define V_028808_ROP3_AND_INVERTED  0x22
+#define V_028808_ROP3_COPY_INVERTED 0x33
+#define V_028808_ROP3_AND_REVERSE   0x44
+#define V_028808_ROP3_INVERT0x55
+#define V_028808_ROP3_XOR   0x66
+#define V_028808_ROP3_NAND  0x77
+#define V_028808_ROP3_AND   0x88
+#define V_028808_ROP3_EQUIVALENT0x99
+#define V_028808_ROP3_NO_OP 0xaa
+#define V_028808_ROP3_OR_INVERTED   0xbb
+#define V_028808_ROP3_COPY  0xcc
+#define V_028808_ROP3_OR_REVERSE0xdd
+#define V_028808_ROP3_OR0xee
+#define V_028808_ROP3_SET   0xff


This change removes names for some of the ternary raster operations 
supported by the hardware and also invents entirely new names for 
already named raster operations.


Also I think this header is generated?

If it isn't, perhaps the constants should be:

#define V_028808_ROP3_0_BLACKNESS   0x00
#define V_028808_ROP3_DPon  0x05
#define V_028808_ROP3_DPna  0x0A
#define V_028808_ROP3_Pn0x0F
#define V_028808_ROP3_DSon_NOTSRCERASE  0x11
#define V_028808_ROP3_DSna  0x22
#define V_028808_ROP3_Sn_NOTSRCCOPY 0x33
#define V_028808_ROP3_SDna_SRCERASE 0x44
#define V_028808_ROP3_PDna  0x50
#define V_028808_ROP3_Dn_DSTINVERT  0x55
#define V_028808_ROP3_DPx_PATINVERT 0x5A
#define V_028808_ROP3_DPan  0x5F
#define V_028808_ROP3_DSx_SRCINVERT 0x66
#define V_028808_ROP3_DSan  0x77
#define V_028808_ROP3_DSa_SRCAND0x88
#define V_028808_ROP3_DSxn  0x99
#define V_028808_ROP3_DPa   0xA0
#define V_028808_ROP3_PDxn  0xA5
#define V_028808_ROP3_D 0xAA
#define V_028808_ROP3_DPno

Re: [Mesa-dev] [PATCH] radv: Translate logic ops.

2018-05-13 Thread Ilia Mirkin 
On Sun, May 13, 2018 at 9:14 PM, Bas Nieuwenhuizen
 wrote:
> radeonsi could pass them through but the enum changed between
> Gallium and Vulkan, so we have to translate.
>
> In progress I made the register defines a bit more readable.
>
> CC: 18.0 18.1 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100430
> ---
>  src/amd/common/sid.h   | 44 +-
>  src/amd/vulkan/radv_pipeline.c | 43 -
>  2 files changed, 58 insertions(+), 29 deletions(-)
>
> diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
> index 3588d39d62b..e922b38ae3a 100644
> --- a/src/amd/common/sid.h
> +++ b/src/amd/common/sid.h
> @@ -6892,34 +6892,22 @@
>  #define   S_028808_ROP3(x)
> (((unsigned)(x) & 0xFF) << 16)
>  #define   G_028808_ROP3(x)(((x) 
> >> 16) & 0xFF)
>  #define   C_028808_ROP3   
> 0xFF00
> -#define V_028808_X_0X00 0x00
> -#define V_028808_X_0X05 0x05
> -#define V_028808_X_0X0A 0x0A
> -#define V_028808_X_0X0F 0x0F
> -#define V_028808_X_0X11 0x11
> -#define V_028808_X_0X22 0x22
> -#define V_028808_X_0X33 0x33
> -#define V_028808_X_0X44 0x44
> -#define V_028808_X_0X50 0x50
> -#define V_028808_X_0X55 0x55
> -#define V_028808_X_0X5A 0x5A
> -#define V_028808_X_0X5F 0x5F
> -#define V_028808_X_0X66 0x66
> -#define V_028808_X_0X77 0x77
> -#define V_028808_X_0X88 0x88
> -#define V_028808_X_0X99 0x99
> -#define V_028808_X_0XA0 0xA0
> -#define V_028808_X_0XA5 0xA5
> -#define V_028808_X_0XAA 0xAA
> -#define V_028808_X_0XAF 0xAF
> -#define V_028808_X_0XBB 0xBB
> -#define V_028808_X_0XCC 0xCC
> -#define V_028808_X_0XDD 0xDD
> -#define V_028808_X_0XEE 0xEE
> -#define V_028808_X_0XF0 0xF0
> -#define V_028808_X_0XF5 0xF5
> -#define V_028808_X_0XFA 0xFA
> -#define V_028808_X_0XFF 0xFF
> +#define V_028808_ROP3_CLEAR 0x00
> +#define V_028808_ROP3_NOR   0x11
> +#define V_028808_ROP3_AND_INVERTED  0x22
> +#define V_028808_ROP3_COPY_INVERTED 0x33
> +#define V_028808_ROP3_AND_REVERSE   0x44
> +#define V_028808_ROP3_INVERT0x55
> +#define V_028808_ROP3_XOR   0x66
> +#define V_028808_ROP3_NAND  0x77
> +#define V_028808_ROP3_AND   0x88
> +#define V_028808_ROP3_EQUIVALENT0x99
> +#define V_028808_ROP3_NO_OP 0xaa
> +#define V_028808_ROP3_OR_INVERTED   0xbb
> +#define V_028808_ROP3_COPY  0xcc
> +#define V_028808_ROP3_OR_REVERSE0xdd
> +#define V_028808_ROP3_OR0xee
> +#define V_028808_ROP3_SET   0xff
>  #define R_02880C_DB_SHADER_CONTROL  
> 0x02880C
>  #define   S_02880C_Z_EXPORT_ENABLE(x) 
> (((unsigned)(x) & 0x1) << 0)
>  #define   G_02880C_Z_EXPORT_ENABLE(x) (((x) 
> >> 0) & 0x1)
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index 7a9c1faaa87..3481f6b4cb7 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -181,6 +181,47 @@ radv_pipeline_scratch_init(struct radv_device *device,
> return VK_SUCCESS;
>

[Mesa-dev] [Bug 106232] LLVM unit tests have error in random number handling

2018-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=106232

Roland Scheidegger  changed:

   What|Removed |Added

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

--- Comment #5 from Roland Scheidegger  ---
While it's not perfect, fixed by cf3fb42fb5eb6130693a4be0a7b5ea06b184ce2d.

-- 
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 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

2018-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103852

--- Comment #20 from Bas Nieuwenhuizen  ---
Does

https://patchwork.freedesktop.org/patch/222558/

fix the background rendering for you?

-- 
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] [Bug 100430] [radv] graphical glitches on dolphin emulator

2018-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100430

--- Comment #18 from Bas Nieuwenhuizen  ---
This should fix the rectangle in Mario Kart:

https://patchwork.freedesktop.org/patch/222558/

-- 
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] radv: Translate logic ops.

2018-05-13 Thread Bas Nieuwenhuizen 
radeonsi could pass them through but the enum changed between
Gallium and Vulkan, so we have to translate.

In progress I made the register defines a bit more readable.

CC: 18.0 18.1 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100430
---
 src/amd/common/sid.h   | 44 +-
 src/amd/vulkan/radv_pipeline.c | 43 -
 2 files changed, 58 insertions(+), 29 deletions(-)

diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
index 3588d39d62b..e922b38ae3a 100644
--- a/src/amd/common/sid.h
+++ b/src/amd/common/sid.h
@@ -6892,34 +6892,22 @@
 #define   S_028808_ROP3(x)
(((unsigned)(x) & 0xFF) << 16)
 #define   G_028808_ROP3(x)(((x) >> 
16) & 0xFF)
 #define   C_028808_ROP3   
0xFF00
-#define V_028808_X_0X00 0x00
-#define V_028808_X_0X05 0x05
-#define V_028808_X_0X0A 0x0A
-#define V_028808_X_0X0F 0x0F
-#define V_028808_X_0X11 0x11
-#define V_028808_X_0X22 0x22
-#define V_028808_X_0X33 0x33
-#define V_028808_X_0X44 0x44
-#define V_028808_X_0X50 0x50
-#define V_028808_X_0X55 0x55
-#define V_028808_X_0X5A 0x5A
-#define V_028808_X_0X5F 0x5F
-#define V_028808_X_0X66 0x66
-#define V_028808_X_0X77 0x77
-#define V_028808_X_0X88 0x88
-#define V_028808_X_0X99 0x99
-#define V_028808_X_0XA0 0xA0
-#define V_028808_X_0XA5 0xA5
-#define V_028808_X_0XAA 0xAA
-#define V_028808_X_0XAF 0xAF
-#define V_028808_X_0XBB 0xBB
-#define V_028808_X_0XCC 0xCC
-#define V_028808_X_0XDD 0xDD
-#define V_028808_X_0XEE 0xEE
-#define V_028808_X_0XF0 0xF0
-#define V_028808_X_0XF5 0xF5
-#define V_028808_X_0XFA 0xFA
-#define V_028808_X_0XFF 0xFF
+#define V_028808_ROP3_CLEAR 0x00
+#define V_028808_ROP3_NOR   0x11
+#define V_028808_ROP3_AND_INVERTED  0x22
+#define V_028808_ROP3_COPY_INVERTED 0x33
+#define V_028808_ROP3_AND_REVERSE   0x44
+#define V_028808_ROP3_INVERT0x55
+#define V_028808_ROP3_XOR   0x66
+#define V_028808_ROP3_NAND  0x77
+#define V_028808_ROP3_AND   0x88
+#define V_028808_ROP3_EQUIVALENT0x99
+#define V_028808_ROP3_NO_OP 0xaa
+#define V_028808_ROP3_OR_INVERTED   0xbb
+#define V_028808_ROP3_COPY  0xcc
+#define V_028808_ROP3_OR_REVERSE0xdd
+#define V_028808_ROP3_OR0xee
+#define V_028808_ROP3_SET   0xff
 #define R_02880C_DB_SHADER_CONTROL  
0x02880C
 #define   S_02880C_Z_EXPORT_ENABLE(x) 
(((unsigned)(x) & 0x1) << 0)
 #define   G_02880C_Z_EXPORT_ENABLE(x) (((x) >> 
0) & 0x1)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 7a9c1faaa87..3481f6b4cb7 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -181,6 +181,47 @@ radv_pipeline_scratch_init(struct radv_device *device,
return VK_SUCCESS;
 }
 
+static uint32_t si_translate_blend_logic_op(VkLogicOp op)
+{
+   switch (op) {
+   case VK_LOGIC_OP_CLEAR:
+   return V_028808_ROP3_CLEAR;
+   case VK_LOGIC_OP_AND:
+   return V_028808_ROP3_AND;
+

Re: [Mesa-dev] [PATCH v2 16/21] nir/linker: Add nir_build_program_resource_list()

2018-05-13 Thread Timothy Arceri 

On 12/05/18 19:40, Alejandro Piñeiro wrote:

From: Eduardo Lima Mitev 

This function is equivalent to the linker.cpp
build_program_resource_list() but will extract the resources from NIR
shaders instead.

For now, only uniforms and program inputs are implemented.

v2: move from compiler/nir to compiler/glsl (Timothy Arceri)

Signed-off-by: Eduardo Lima 
Signed-off-by: Alejandro Piñeiro 
---
  src/compiler/Makefile.sources |  1 +
  src/compiler/glsl/gl_nir_linker.c | 93 +++
  src/compiler/glsl/gl_nir_linker.h |  3 ++
  src/compiler/glsl/meson.build |  1 +
  4 files changed, 98 insertions(+)
  create mode 100644 src/compiler/glsl/gl_nir_linker.c

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 8104dd32002..409252ee587 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -30,6 +30,7 @@ LIBGLSL_FILES = \
glsl/gl_nir_lower_samplers_as_deref.c \
glsl/gl_nir_link_uniform_initializers.c \
glsl/gl_nir_link_uniforms.c \
+   glsl/gl_nir_linker.c \
glsl/gl_nir_linker.h \
glsl/gl_nir.h \
glsl/glsl_parser_extras.cpp \
diff --git a/src/compiler/glsl/gl_nir_linker.c 
b/src/compiler/glsl/gl_nir_linker.c
new file mode 100644
index 000..155d94ef966
--- /dev/null
+++ b/src/compiler/glsl/gl_nir_linker.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "nir.h"
+#include "gl_nir_linker.h"
+#include "linker_util.h"
+#include "main/mtypes.h"
+#include "ir_uniform.h" /* for gl_uniform_storage */
+
+/* This file included general link methods, using NIR, instead of IR as
+ * the counter-part glsl/linker.cpp
+ *
+ * Also note that this is tailored for ARB_gl_spirv needs and particularities
+ */
+
+void
+nir_build_program_resource_list(struct gl_context *ctx,
+struct gl_shader_program *prog)
+{
+   /* Rebuild resource list. */
+   if (prog->data->ProgramResourceList) {
+  ralloc_free(prog->data->ProgramResourceList);
+  prog->data->ProgramResourceList = NULL;
+  prog->data->NumProgramResourceList = 0;
+   }
+
+   struct set *resource_set = _mesa_set_create(NULL,
+   _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+
+   /* Add uniforms
+*
+* Here, it is expected that nir_link_uniforms() has already been
+* called, so that UniformStorage table is already available.
+*/
+   for (unsigned i = 0; i < prog->data->NumUniformStorage; i++) {
+  struct gl_uniform_storage *uniform = >data->UniformStorage[i];
+
+  if (!link_util_add_program_resource(prog, resource_set, GL_UNIFORM, 
uniform,
+  uniform->active_shader_mask)) {
+ return;
+  }
+   }
+
+   /* Add inputs */
+   struct gl_linked_shader *sh = prog->_LinkedShaders[MESA_SHADER_VERTEX];
+   if (sh) {
+  nir_shader *nir = sh->Program->nir;
+  assert(nir);
+
+  nir_foreach_variable(var, >inputs) {
+ struct gl_shader_variable *sh_var =
+rzalloc(prog, struct gl_shader_variable);
+
+ /* ARB_gl_spirv: names are considered optional debug info, so the 
linker
+  * needs to work without them, and returning them is optional. For
+  * simplicity we ignore names.
+  */
+ sh_var->name = NULL;
+ sh_var->type = var->type;
+ sh_var->location = var->data.location;


This doesn't look right to me. Don't we need to handle structs, ifcs and 
arrays just like in the glsl code?




+
+ /* @TODO: Fill in the rest of gl_shader_variable data. */
+
+ if (!link_util_add_program_resource(prog, resource_set, 
GL_PROGRAM_INPUT,
+

Re: [Mesa-dev] [PATCH v2 15/21] compiler/link: move add_program_resource to linker_util

2018-05-13 Thread Timothy Arceri 

Reviewed-by: Timothy Arceri 

On 12/05/18 19:40, Alejandro Piñeiro wrote:

So it could be used by the GLSL and NIR linker.

v2: (Timothy Arceri)
* Moved from compiler to compiler/glsl
* Method renamed to link_util_add_program_resource
---
  src/compiler/Makefile.sources |  1 +
  src/compiler/glsl/linker.cpp  | 76 +++
  src/compiler/glsl/linker_util.cpp | 64 +
  src/compiler/glsl/linker_util.h   |  5 +++
  src/compiler/glsl/meson.build |  1 +
  5 files changed, 91 insertions(+), 56 deletions(-)
  create mode 100644 src/compiler/glsl/linker_util.cpp

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 27c135e913b..8104dd32002 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -75,6 +75,7 @@ LIBGLSL_FILES = \
glsl/linker.cpp \
glsl/linker.h \
glsl/linker_util.h \
+   glsl/linker_util.cpp \
glsl/link_atomics.cpp \
glsl/link_functions.cpp \
glsl/link_interface_blocks.cpp \
diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index f060c5316fa..f201a566c29 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -3613,42 +3613,6 @@ should_add_buffer_variable(struct gl_shader_program 
*shProg,
 return false;
  }
  
-static bool

-add_program_resource(struct gl_shader_program *prog,
- struct set *resource_set,
- GLenum type, const void *data, uint8_t stages)
-{
-   assert(data);
-
-   /* If resource already exists, do not add it again. */
-   if (_mesa_set_search(resource_set, data))
-  return true;
-
-   prog->data->ProgramResourceList =
-  reralloc(prog->data,
-   prog->data->ProgramResourceList,
-   gl_program_resource,
-   prog->data->NumProgramResourceList + 1);
-
-   if (!prog->data->ProgramResourceList) {
-  linker_error(prog, "Out of memory during linking.\n");
-  return false;
-   }
-
-   struct gl_program_resource *res =
-  >data->ProgramResourceList[prog->data->NumProgramResourceList];
-
-   res->Type = type;
-   res->Data = data;
-   res->StageReferences = stages;
-
-   prog->data->NumProgramResourceList++;
-
-   _mesa_set_add(resource_set, data);
-
-   return true;
-}
-
  /* Function checks if a variable var is a packed varying and
   * if given name is part of packed varying's list.
   *
@@ -3942,8 +3906,8 @@ add_shader_variable(const struct gl_context *ctx,
if (!sha_v)
   return false;
  
-  return add_program_resource(shProg, resource_set,

-  programInterface, sha_v, stage_mask);
+  return link_util_add_program_resource(shProg, resource_set,
+programInterface, sha_v, 
stage_mask);
 }
 }
  }
@@ -4372,9 +4336,9 @@ build_program_resource_list(struct gl_context *ctx,
/* Add transform feedback varyings. */
if (linked_xfb->NumVarying > 0) {
   for (int i = 0; i < linked_xfb->NumVarying; i++) {
-if (!add_program_resource(shProg, resource_set,
-  GL_TRANSFORM_FEEDBACK_VARYING,
-  _xfb->Varyings[i], 0))
+if (!link_util_add_program_resource(shProg, resource_set,
+GL_TRANSFORM_FEEDBACK_VARYING,
+_xfb->Varyings[i], 0))
  return;
   }
}
@@ -4383,9 +4347,9 @@ build_program_resource_list(struct gl_context *ctx,
for (unsigned i = 0; i < ctx->Const.MaxTransformFeedbackBuffers; i++) {
   if ((linked_xfb->ActiveBuffers >> i) & 1) {
  linked_xfb->Buffers[i].Binding = i;
-if (!add_program_resource(shProg, resource_set,
-  GL_TRANSFORM_FEEDBACK_BUFFER,
-  _xfb->Buffers[i], 0))
+if (!link_util_add_program_resource(shProg, resource_set,
+GL_TRANSFORM_FEEDBACK_BUFFER,
+_xfb->Buffers[i], 0))
  return;
   }
}
@@ -4421,29 +4385,29 @@ build_program_resource_list(struct gl_context *ctx,
   >data->UniformStorage[i]);
}
  
-  if (!add_program_resource(shProg, resource_set, type,

->data->UniformStorage[i], stageref))
+  if (!link_util_add_program_resource(shProg, resource_set, type,
+  >data->UniformStorage[i], 
stageref))
   return;
 }
  
 /* Add program uniform blocks. */

 for (unsigned i = 0; i < shProg->data->NumUniformBlocks; i++) {
-  if (!add_program_resource(shProg, resource_set, GL_UNIFORM_BLOCK,
-

Re: [Mesa-dev] [PATCH v2 12/21] compiler/link: add linker_util.h, move linker_error/warning to it

2018-05-13 Thread Timothy Arceri 

Reviewed-by: Timothy Arceri 

On 12/05/18 19:40, Alejandro Piñeiro wrote:

Linker utilities common to the GLSL IR and NIR linker (the latter to
be used for ARB_gl_spirv).

We need to move it to a new header as the NIR linker doesn't need to
know about ir_variable, and others, included at linker.h.

v2: move from src/compiler to src/compiler/glsl (Timothy Arceri)
---
  src/compiler/Makefile.sources  |  1 +
  .../glsl/link_uniform_block_active_visitor.cpp |  1 +
  src/compiler/glsl/linker.h |  8 +---
  src/compiler/glsl/linker_util.h| 43 ++
  src/compiler/glsl/meson.build  |  1 +
  src/compiler/glsl/program.h|  8 
  6 files changed, 48 insertions(+), 14 deletions(-)
  create mode 100644 src/compiler/glsl/linker_util.h

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 3daa2c51334..96af23fcd2c 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -71,6 +71,7 @@ LIBGLSL_FILES = \
glsl/ir_visitor.h \
glsl/linker.cpp \
glsl/linker.h \
+   glsl/linker_util.h \
glsl/link_atomics.cpp \
glsl/link_functions.cpp \
glsl/link_interface_blocks.cpp \
diff --git a/src/compiler/glsl/link_uniform_block_active_visitor.cpp 
b/src/compiler/glsl/link_uniform_block_active_visitor.cpp
index cd1baf78e80..368981852c0 100644
--- a/src/compiler/glsl/link_uniform_block_active_visitor.cpp
+++ b/src/compiler/glsl/link_uniform_block_active_visitor.cpp
@@ -23,6 +23,7 @@
  
  #include "link_uniform_block_active_visitor.h"

  #include "program.h"
+#include "linker_util.h"
  
  static link_uniform_block_active *

  process_block(void *mem_ctx, struct hash_table *ht, ir_variable *var)
diff --git a/src/compiler/glsl/linker.h b/src/compiler/glsl/linker.h
index 454b65aebdf..6e9b4861673 100644
--- a/src/compiler/glsl/linker.h
+++ b/src/compiler/glsl/linker.h
@@ -25,6 +25,8 @@
  #ifndef GLSL_LINKER_H
  #define GLSL_LINKER_H
  
+#include "linker_util.h"

+
  struct gl_shader_program;
  struct gl_shader;
  struct gl_linked_shader;
@@ -192,12 +194,6 @@ private:
const glsl_struct_field *named_ifc_member);
  };
  
-void

-linker_error(gl_shader_program *prog, const char *fmt, ...);
-
-void
-linker_warning(gl_shader_program *prog, const char *fmt, ...);
-
  /**
   * Sometimes there are empty slots left over in UniformRemapTable after we
   * allocate slots to explicit locations. This struct represents a single
diff --git a/src/compiler/glsl/linker_util.h b/src/compiler/glsl/linker_util.h
new file mode 100644
index 000..162db3e532f
--- /dev/null
+++ b/src/compiler/glsl/linker_util.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef GLSL_LINKER_UTIL_H
+#define GLSL_LINKER_UTIL_H
+
+struct gl_shader_program;
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+void
+linker_error(struct gl_shader_program *prog, const char *fmt, ...);
+
+void
+linker_warning(struct gl_shader_program *prog, const char *fmt, ...);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* GLSL_LINKER_UTIL_H */
diff --git a/src/compiler/glsl/meson.build b/src/compiler/glsl/meson.build
index 055a84714c1..686a5a4ac0b 100644
--- a/src/compiler/glsl/meson.build
+++ b/src/compiler/glsl/meson.build
@@ -112,6 +112,7 @@ files_libglsl = files(
'ir_visitor.h',
'linker.cpp',
'linker.h',
+  'linker_util.h',
'link_atomics.cpp',
'link_functions.cpp',
'link_interface_blocks.cpp',
diff --git a/src/compiler/glsl/program.h b/src/compiler/glsl/program.h
index 480379b10b8..9df42ddc1c4 100644
--- a/src/compiler/glsl/program.h
+++ b/src/compiler/glsl/program.h
@@ -48,14 +48,6 @@ extern void
  build_program_resource_list(struct gl_context *ctx,

[Mesa-dev] [Bug 105119] Desktop-wide input freeze when vulkan (radv)

2018-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=105119

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

-- 
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] opencl: autotools: Fix linking order for OpenCL target

2018-05-13 Thread Dieter Nützel 

Hello Jan and Kai,

would be nice if this lands (have T-b from me).

Dieter

Am 13.05.2018 19:10, schrieb Jan Vesely:

Hi,

sorry for the delay. I thought maybe Emil is on holiday. I plan to
push this on Monday evening (EDT) if there is no response by then.

Jan

On Sun, May 13, 2018 at 3:56 AM, Kai Wasserbäch
 wrote:


Ping! Can somebody *please* commit this patch? It fixes an FTBFS,
has two T-b
and one A-b.

Kai Wasserbäch wrote on 07.05.2018 16:48:

Jan Vesely wrote on 02.05.2018 22:38:

On Wed, 2018-05-02 at 18:38 +0200, Kai Wasserbäch wrote:

[...]


Thank for looking into this. We probably need CLANG_LIBS handling
similar to LLVM_LIBS. I agree this is the best fix for now.

Acked-by: Jan Vesely 

libclang.so might be a solkution, but I'm not sure how it

interacts

with older or static build clang. It's also weird that we are

linking

to clang here instead of clover which actually uses clang

symbols.


@Emil, are you OK with this patch?


Gentle ping.


-lclangDriver \
-lclangSerialization \
-   -lclangCodeGen \


Is this change related?


Not really, just a minor clean-up while I was busy a few lines

above.

"clangCodeGen" is already named on the first Clang library

line.


ah, all right, maybe mention it in the commit message?


Do I need to resend the patch for that or can you just add a

line like "This

change also removes the duplicate clangCodeGen line (trivial

change)." before

pushing, considering, that there are two T-b tags to be added

anyway?


I'll add it on my side before pushing the patch.


Thanks a lot!

Cheers,
Kai






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



--

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: k...@dev.carbon-project.org




Links:
--
[1] 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] [Bug 106504] vulkan SPIR-V parsing failed at ../src/compiler/spirv/vtn_cfg.c:381

2018-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=106504

Bug ID: 106504
   Summary: vulkan SPIR-V parsing failed at
../src/compiler/spirv/vtn_cfg.c:381
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/Common
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: xavi...@gmail.com
CC: airl...@freedesktop.org, chadvers...@chromium.org,
dan...@fooishbar.org, ja...@jlekstrand.net

Created attachment 139548
  --> https://bugs.freedesktop.org/attachment.cgi?id=139548=edit
vkrunner file

hello,

I get an error with both radv and intel

SPIR-V parsing FAILED:
In file ../src/compiler/spirv/vtn_cfg.c:381
block->node.link.next == NULL
0 bytes into the SPIR-V binary


when using this hlsl shader (compiled with glslang):

float4 main(float4 fragCoord : SV_POSITION) : SV_Target0
{
float4  Sum = 0;
for (int i=0; i<2; i++) {
for (int j=0; j<2; j++) {
Sum += fragCoord;
}
}
return Sum / 4;
}

(the spirv source file is attached.)


This report is a follow-up to 
https://github.com/KhronosGroup/SPIRV-Tools/issues/1456 
"The outer loop's continue block ends up as the same block as the inner loop's
continue block. I wonder if the Mesa compiler doesn't expect this (assuming
there are no other bugs)."

-- 
You are receiving this mail because:
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] radv: Fix multiview queries.

2018-05-13 Thread Dave Airlie 
On 14 May 2018 at 06:07, Bas Nieuwenhuizen  wrote:
> This moves the extra queries to after the main query ended, instead
> of doing it after the begin and hence doing nesting.
>
> We also emit only (view count - 1) extra queries, as the main query
> is already there for the first view.
>
> This fixes the CTS occasiionally getting stuck in
> dEQP-VK.multiview.queries* waiting on results.
>
> Fixes: 32b4f3c38dc "radv/query: handle multiview queries properly. (v3)"
> C: 18.1 

Seems sane:

Reviewed-by: Dave Airlie 

> ---
>  src/amd/vulkan/radv_query.c | 39 +++--
>  1 file changed, 20 insertions(+), 19 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index 2b2e80f4e5b..3749e2f43d1 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -1204,25 +1204,6 @@ void radv_CmdBeginQuery(
> va += pool->stride * query;
>
> emit_begin_query(cmd_buffer, va, pool->type, flags);
> -
> -   /*
> -* For multiview we have to emit a query for each bit in the mask,
> -* however the first query we emit will get the totals for all the
> -* operations, so we don't want to get a real value in the other
> -* queries. This emits a fake begin/end sequence so the waiting
> -* code gets a completed query value and doesn't hang, but the
> -* query returns 0.
> -*/
> -   if (cmd_buffer->state.subpass && 
> cmd_buffer->state.subpass->view_mask) {
> -   uint64_t avail_va = va + pool->availability_offset + 4 * 
> query;
> -
> -   for (unsigned i = 0; i < 
> util_bitcount(cmd_buffer->state.subpass->view_mask); i++) {
> -   va += pool->stride;
> -   avail_va += 4;
> -   emit_begin_query(cmd_buffer, va, pool->type, flags);
> -   emit_end_query(cmd_buffer, va, avail_va, pool->type);
> -   }
> -   }
>  }
>
>
> @@ -1241,6 +1222,26 @@ void radv_CmdEndQuery(
>  * currently be active, which means the BO is already in the list.
>  */
> emit_end_query(cmd_buffer, va, avail_va, pool->type);
> +
> +   /*
> +* For multiview we have to emit a query for each bit in the mask,
> +* however the first query we emit will get the totals for all the
> +* operations, so we don't want to get a real value in the other
> +* queries. This emits a fake begin/end sequence so the waiting
> +* code gets a completed query value and doesn't hang, but the
> +* query returns 0.
> +*/
> +   if (cmd_buffer->state.subpass && 
> cmd_buffer->state.subpass->view_mask) {
> +   uint64_t avail_va = va + pool->availability_offset + 4 * 
> query;
> +
> +
> +   for (unsigned i = 1; i < 
> util_bitcount(cmd_buffer->state.subpass->view_mask); i++) {
> +   va += pool->stride;
> +   avail_va += 4;
> +   emit_begin_query(cmd_buffer, va, pool->type, 0);
> +   emit_end_query(cmd_buffer, va, avail_va, pool->type);
> +   }
> +   }
>  }
>
>  void radv_CmdWriteTimestamp(
> --
> 2.17.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

[Mesa-dev] [PATCH] radv: Fix multiview queries.

2018-05-13 Thread Bas Nieuwenhuizen 
This moves the extra queries to after the main query ended, instead
of doing it after the begin and hence doing nesting.

We also emit only (view count - 1) extra queries, as the main query
is already there for the first view.

This fixes the CTS occasiionally getting stuck in
dEQP-VK.multiview.queries* waiting on results.

Fixes: 32b4f3c38dc "radv/query: handle multiview queries properly. (v3)"
C: 18.1 
---
 src/amd/vulkan/radv_query.c | 39 +++--
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 2b2e80f4e5b..3749e2f43d1 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1204,25 +1204,6 @@ void radv_CmdBeginQuery(
va += pool->stride * query;
 
emit_begin_query(cmd_buffer, va, pool->type, flags);
-
-   /*
-* For multiview we have to emit a query for each bit in the mask,
-* however the first query we emit will get the totals for all the
-* operations, so we don't want to get a real value in the other
-* queries. This emits a fake begin/end sequence so the waiting
-* code gets a completed query value and doesn't hang, but the
-* query returns 0.
-*/
-   if (cmd_buffer->state.subpass && cmd_buffer->state.subpass->view_mask) {
-   uint64_t avail_va = va + pool->availability_offset + 4 * query;
-
-   for (unsigned i = 0; i < 
util_bitcount(cmd_buffer->state.subpass->view_mask); i++) {
-   va += pool->stride;
-   avail_va += 4;
-   emit_begin_query(cmd_buffer, va, pool->type, flags);
-   emit_end_query(cmd_buffer, va, avail_va, pool->type);
-   }
-   }
 }
 
 
@@ -1241,6 +1222,26 @@ void radv_CmdEndQuery(
 * currently be active, which means the BO is already in the list.
 */
emit_end_query(cmd_buffer, va, avail_va, pool->type);
+
+   /*
+* For multiview we have to emit a query for each bit in the mask,
+* however the first query we emit will get the totals for all the
+* operations, so we don't want to get a real value in the other
+* queries. This emits a fake begin/end sequence so the waiting
+* code gets a completed query value and doesn't hang, but the
+* query returns 0.
+*/
+   if (cmd_buffer->state.subpass && cmd_buffer->state.subpass->view_mask) {
+   uint64_t avail_va = va + pool->availability_offset + 4 * query;
+
+
+   for (unsigned i = 1; i < 
util_bitcount(cmd_buffer->state.subpass->view_mask); i++) {
+   va += pool->stride;
+   avail_va += 4;
+   emit_begin_query(cmd_buffer, va, pool->type, 0);
+   emit_end_query(cmd_buffer, va, avail_va, pool->type);
+   }
+   }
 }
 
 void radv_CmdWriteTimestamp(
-- 
2.17.0

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

[Mesa-dev] [Bug 106502] Running game with wine fullscreen freezes the system when missing xf86-video-amdgpu

2018-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=106502

Fabian Maurer  changed:

   What|Removed |Added

Summary|Running game with wine  |Running game with wine
   |fullscreen freezes the  |fullscreen freezes the
   |system  |system when missing
   ||xf86-video-amdgpu

--- Comment #1 from Fabian Maurer  ---
Okay, I figured out what causes it: It's due to a corrupt installation of
xf86-video-amdgpu. When this package is not installed, I get the freeze.
However, this is nothing that should happen.


I think this package is part of mesa, but I'm not sure. So feel free to point
me to another bugtracker if I'm mistaken.

-- 
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] [PATCH] opencl: autotools: Fix linking order for OpenCL target

2018-05-13 Thread Jan Vesely 
Hi,

sorry for the delay. I thought maybe Emil is on holiday. I plan to push
this on Monday evening (EDT) if there is no response by then.

Jan

On Sun, May 13, 2018 at 3:56 AM, Kai Wasserbäch 
wrote:

> Ping! Can somebody *please* commit this patch? It fixes an FTBFS, has two
> T-b
> and one A-b.
>
>
> Kai Wasserbäch wrote on 07.05.2018 16:48:
> > Jan Vesely wrote on 02.05.2018 22:38:
> >> On Wed, 2018-05-02 at 18:38 +0200, Kai Wasserbäch wrote:
> >>> [...]
> >>
> >> Thank for looking into this. We probably need CLANG_LIBS handling
> >> similar to LLVM_LIBS. I agree this is the best fix for now.
> >>
> >> Acked-by: Jan Vesely 
> >>
> >> libclang.so might be a solkution, but I'm not sure how it interacts
> >> with older or static build clang. It's also weird that we are linking
> >> to clang here instead of clover which actually uses clang symbols.
> >>
> >> @Emil, are you OK with this patch?
> >
> > Gentle ping.
> >
> >>> -lclangDriver \
> >>> -lclangSerialization \
> >>> -   -lclangCodeGen \
> >>
> >> Is this change related?
> >
> > Not really, just a minor clean-up while I was busy a few lines above.
> > "clangCodeGen" is already named on the first Clang library line.
> 
>  ah, all right, maybe mention it in the commit message?
> >>>
> >>> Do I need to resend the patch for that or can you just add a line like
> "This
> >>> change also removes the duplicate clangCodeGen line (trivial change)."
> before
> >>> pushing, considering, that there are two T-b tags to be added anyway?
> >>
> >> I'll add it on my side before pushing the patch.
> >
> > Thanks a lot!
> >
> > Cheers,
> > Kai
> >
> >
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
> --
>
> 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] compiler/spirv: reject invalid shader code properly

2018-05-13 Thread Jason Ekstrand 
Ugh... I know this worked correctly when I did it.  I think the setjmp must 
not have quite survived over of the refactors.  I need to take a serious 
look at out on Monday.


On May 13, 2018 09:02:24 Martin Pelikán  wrote:


After bebe3d626e5, b->fail_jump is prepared after vtn_create_builder
which can longjmp(3) to it through its vtx_assert()s.  This corrupts
the stack and creates confusing core dumps, so we need to avoid it.

While there, I decided to print the offending values for debugability.
---
src/compiler/spirv/spirv_to_nir.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c

index 78437428aa..a05364ba2f 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -4011,19 +4011,35 @@ vtn_create_builder(const uint32_t *words, size_t 
word_count,

   b->entry_point_name = entry_point_name;
   b->options = options;

-   /* Handle the SPIR-V header (first 4 dwords)  */
-   vtn_assert(word_count > 5);
+   /*
+* Handle the SPIR-V header (first 4 dwords).
+* Can't use vtx_assert() as the setjmp(3) target isn't initialized yet.
+*/
+   if (word_count <= 5)
+  goto fail;

-   vtn_assert(words[0] == SpvMagicNumber);
-   vtn_assert(words[1] >= 0x1);
+   if (words[0] != SpvMagicNumber) {
+  vtn_warn("words[0] was 0x%x, want 0x%x", words[0], SpvMagicNumber);
+  goto fail;
+   }
+   if (words[1] < 0x1) {
+  vtn_warn("words[1] was 0x%x, want >= 0x1", words[1]);
+  goto fail;
+   }
   /* words[2] == generator magic */
   unsigned value_id_bound = words[3];
-   vtn_assert(words[4] == 0);
+   if (words[4] != 0) {
+  vtn_warn("words[4] was %u, want 0", words[4]);
+  goto fail;
+   }

   b->value_id_bound = value_id_bound;
   b->values = rzalloc_array(b, struct vtn_value, value_id_bound);

   return b;
+ fail:
+   ralloc_free(b);
+   return NULL;
}

nir_function *
--
2.17.0.441.gb46fe60e1d-goog




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

[Mesa-dev] [Bug 106502] Running game with wine fullscreen freezes the system

2018-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=106502

Bug ID: 106502
   Summary: Running game with wine fullscreen freezes the system
   Product: Mesa
   Version: git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: dark.shad...@web.de
QA Contact: mesa-dev@lists.freedesktop.org

I don't know where to put this bug, because I don't know the category.
When running a specific game with wine in fullscreen, it freezes the system
until I reboot. windowed works, but switching to fullscreen causes a freeze.

It used to work, I tried downgrading mesa, linux and wine, but I can't get it
to work anymore. I really don't know what causes this.

Only relevant output I see in dmesg logs is
> Mai 13 17:08:23 arch kernel: [drm:drm_atomic_helper_wait_for_flip_done 
> [drm_kms_helper]] *ERROR* [CRTC:43:crtc-0] flip_done timed out
But I don't know if that's really the problem here.

What kind of logs/debugging would help figure out the problem?

System info:
- Using Mesa 18.2.0-devel (git-26ddc4f9e1) / 18.0.3
- Linux 4.16.8 / 4.16.3
- plasma-desktop 5.12.5
- Arch Linux x64
- Radeon R9 285

-- 
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] [Bug 105494] UT2004 cube map reflection problem

2018-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=105494

--- Comment #7 from almos  ---
Here's a trace. I tried to capture the switch between showing only the top half
or the bottom half of the reflection, but it ran at 1fps even with minimum
graphics settings and capturing to a ramdisk.

https://drive.google.com/open?id=1Labnt8OuvPVSsxEUHvJaQ6YbAdJicaiD

-- 
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] [Bug 106480] A2B10G10R10_SNORM vertex attribute doesn't work.

2018-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=106480

--- Comment #11 from mais...@archlinux.us ---
The patches seem to have fixed the issue for me :)

-- 
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] [Intel-gfx] [PATCH] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

2018-05-13 Thread Chris Wilson 
Quoting Michel Thierry (2018-05-11 16:07:55)
> On 5/11/2018 5:43 AM, Mika Kuoppala wrote:
> > Chris Wilson  writes:
> > 
> >> Quoting Mika Kuoppala (2018-05-11 10:56:49)
> >>> Michel Thierry  writes:
> >>>
>  Factor in clear values wherever required while updating destination
>  min/max.
> 
>  References: HSDES#160184
>  Signed-off-by: Michel Thierry 
>  Cc: mesa-dev@lists.freedesktop.org
>  Cc: Mika Kuoppala 
>  Cc: Oscar Mateo 
> >>>
> >>> Reviewed-by: Mika Kuoppala 
> >>
> >> Cc: stable?
> > 
> > Yes, we should.
> > 
> 
> I think so too, although stable doesn't have the workaround refactoring 
> yet, the change will be in intel_engine_cs.c instead.

Added the cc for stable, and pushed. We may need to send a fixup patch
later if we want it backported all the way.

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

Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target

2018-05-13 Thread Kai Wasserbäch 
Ping! Can somebody *please* commit this patch? It fixes an FTBFS, has two T-b
and one A-b.


Kai Wasserbäch wrote on 07.05.2018 16:48:
> Jan Vesely wrote on 02.05.2018 22:38:
>> On Wed, 2018-05-02 at 18:38 +0200, Kai Wasserbäch wrote:
>>> [...]
>>
>> Thank for looking into this. We probably need CLANG_LIBS handling
>> similar to LLVM_LIBS. I agree this is the best fix for now.
>>
>> Acked-by: Jan Vesely 
>>
>> libclang.so might be a solkution, but I'm not sure how it interacts
>> with older or static build clang. It's also weird that we are linking
>> to clang here instead of clover which actually uses clang symbols.
>>
>> @Emil, are you OK with this patch?
> 
> Gentle ping.
> 
>>> -lclangDriver \
>>> -lclangSerialization \
>>> -   -lclangCodeGen \
>>
>> Is this change related?
>
> Not really, just a minor clean-up while I was busy a few lines above.
> "clangCodeGen" is already named on the first Clang library line.

 ah, all right, maybe mention it in the commit message?
>>>
>>> Do I need to resend the patch for that or can you just add a line like "This
>>> change also removes the duplicate clangCodeGen line (trivial change)." 
>>> before
>>> pushing, considering, that there are two T-b tags to be added anyway?
>>
>> I'll add it on my side before pushing the patch.
> 
> Thanks a lot!
> 
> Cheers,
> Kai
> 
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: k...@dev.carbon-project.org



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