[Mesa-dev] [PATCH 1/2] i965: Fix value of _3DPRIM_TRIFAN_NOSTIPPLE.

2015-09-07 Thread Kenneth Graunke
TRIFAN_NOSTIPPLE has always been 0x16 - 0x15 is marked "Reserved" on all
platforms.  See the 965 PRM, Volume 2, Table 3-1, "3D Primitive Topology
Type Encoding" for a list.

We don't currently use this, and I don't expect we will, but we may as
well not leave the bogus value around.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_defines.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 0f7feb3..411a97d 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -77,7 +77,7 @@
 #define _3DPRIM_LINESTRIP_CONT0x12
 #define _3DPRIM_LINESTRIP_BF  0x13
 #define _3DPRIM_LINESTRIP_CONT_BF 0x14
-#define _3DPRIM_TRIFAN_NOSTIPPLE  0x15
+#define _3DPRIM_TRIFAN_NOSTIPPLE  0x16
 
 /* We use this offset to be able to pass native primitive types in struct
  * _mesa_prim::mode.  Native primitive types are BRW_PRIM_OFFSET +
-- 
2.5.1

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


[Mesa-dev] [PATCH 2/2] i965: Mark topologies with adjacency information as G45+.

2015-09-07 Thread Kenneth Graunke
These didn't exist on the original 965.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_defines.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 411a97d..a8594af 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -65,10 +65,10 @@
 #define _3DPRIM_TRIFAN0x06
 #define _3DPRIM_QUADLIST  0x07
 #define _3DPRIM_QUADSTRIP 0x08
-#define _3DPRIM_LINELIST_ADJ  0x09
-#define _3DPRIM_LINESTRIP_ADJ 0x0A
-#define _3DPRIM_TRILIST_ADJ   0x0B
-#define _3DPRIM_TRISTRIP_ADJ  0x0C
+#define _3DPRIM_LINELIST_ADJ  0x09 /* G45+ */
+#define _3DPRIM_LINESTRIP_ADJ 0x0A /* G45+ */
+#define _3DPRIM_TRILIST_ADJ   0x0B /* G45+ */
+#define _3DPRIM_TRISTRIP_ADJ  0x0C /* G45+ */
 #define _3DPRIM_TRISTRIP_REVERSE  0x0D
 #define _3DPRIM_POLYGON   0x0E
 #define _3DPRIM_RECTLIST  0x0F
-- 
2.5.1

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


[Mesa-dev] [PATCH] i965: Add defines for tessellation stages

2015-09-07 Thread Kenneth Graunke
From: Chris Forbes 

v2 (Ken):
- Squash together commits for HS, DS, and TE, as well as fixes.
- Add INTEL_MASK variants so we can use SET_FIELD if we want.
- Rename GEN7_HS_INSTANCE_CONTROL to GEN7_HS_INSTANCE_COUNT to match
  the documentation.
- Add some more fields from the PRMs.
- Add Broadwell variants.

Signed-off-by: Chris Forbes 
Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_defines.h | 72 +
 1 file changed, 72 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index a8594af..4e3168e 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1788,6 +1788,8 @@ enum brw_message_target {
 /* DW3: PS */
 
 #define _3DSTATE_SAMPLER_STATE_POINTERS_VS 0x782B /* GEN7+ */
+#define _3DSTATE_SAMPLER_STATE_POINTERS_HS 0x782C /* GEN7+ */
+#define _3DSTATE_SAMPLER_STATE_POINTERS_DS 0x782D /* GEN7+ */
 #define _3DSTATE_SAMPLER_STATE_POINTERS_GS 0x782E /* GEN7+ */
 #define _3DSTATE_SAMPLER_STATE_POINTERS_PS 0x782F /* GEN7+ */
 
@@ -1871,6 +1873,8 @@ enum brw_message_target {
 #define GEN6_MAX_GS_URB_ENTRY_SIZE_BYTES(5*128)
 
 #define _3DSTATE_PUSH_CONSTANT_ALLOC_VS 0x7912 /* GEN7+ */
+#define _3DSTATE_PUSH_CONSTANT_ALLOC_HS 0x7913 /* GEN7+ */
+#define _3DSTATE_PUSH_CONSTANT_ALLOC_DS 0x7914 /* GEN7+ */
 #define _3DSTATE_PUSH_CONSTANT_ALLOC_GS 0x7915 /* GEN7+ */
 #define _3DSTATE_PUSH_CONSTANT_ALLOC_PS 0x7916 /* GEN7+ */
 # define GEN7_PUSH_CONSTANT_BUFFER_OFFSET_SHIFT 16
@@ -1973,8 +1977,76 @@ enum brw_message_target {
 #define GEN7_MAX_GS_OUTPUT_VERTEX_SIZE_BYTES   (62*16)
 
 #define _3DSTATE_HS 0x781B /* GEN7+ */
+/* DW1 */
+# define GEN7_HS_SAMPLER_COUNT_MASK INTEL_MASK(29, 27)
+# define GEN7_HS_SAMPLER_COUNT_SHIFT27
+# define GEN7_HS_BINDING_TABLE_ENTRY_COUNT_MASK INTEL_MASK(25, 18)
+# define GEN7_HS_BINDING_TABLE_ENTRY_COUNT_SHIFT18
+# define GEN7_HS_FLOATING_POINT_MODE_IEEE_754   (0 << 16)
+# define GEN7_HS_FLOATING_POINT_MODE_ALT(1 << 16)
+# define GEN7_HS_MAX_THREADS_SHIFT  0
+/* DW2 */
+# define GEN7_HS_ENABLE (1 << 31)
+# define GEN7_HS_STATISTICS_ENABLE  (1 << 29)
+# define GEN8_HS_MAX_THREADS_SHIFT  8
+# define GEN7_HS_INSTANCE_COUNT_MASKINTEL_MASK(3, 0)
+# define GEN7_HS_INSTANCE_COUNT_SHIFT   0
+/* DW5 */
+# define GEN7_HS_SINGLE_PROGRAM_FLOW(1 << 27)
+# define GEN7_HS_VECTOR_MASK_ENABLE (1 << 26)
+# define HSW_HS_ACCESSES_UAV(1 << 25)
+# define GEN7_HS_INCLUDE_VERTEX_HANDLES (1 << 24)
+# define GEN7_HS_DISPATCH_START_GRF_MASKINTEL_MASK(23, 19)
+# define GEN7_HS_DISPATCH_START_GRF_SHIFT   19
+# define GEN7_HS_URB_READ_LENGTH_MASK   INTEL_MASK(16, 11)
+# define GEN7_HS_URB_READ_LENGTH_SHIFT  11
+# define GEN7_HS_URB_ENTRY_READ_OFFSET_MASK INTEL_MASK(9, 4)
+# define GEN7_HS_URB_ENTRY_READ_OFFSET_SHIFT4
+
 #define _3DSTATE_TE 0x781C /* GEN7+ */
+/* DW1 */
+# define GEN7_TE_PARTITIONING_SHIFT 12
+# define GEN7_TE_OUTPUT_TOPOLOGY_SHIFT  8
+# define GEN7_TE_DOMAIN_SHIFT   4
+//# define GEN7_TE_MODE_SW(1 << 1)
+# define GEN7_TE_ENABLE (1 << 0)
+
 #define _3DSTATE_DS 0x781D /* GEN7+ */
+/* DW2 */
+# define GEN7_DS_SINGLE_DOMAIN_POINT_DISPATCH   (1 << 31)
+# define GEN7_DS_VECTOR_MASK_ENABLE (1 << 30)
+# define GEN7_DS_SAMPLER_COUNT_MASK INTEL_MASK(29, 27)
+# define GEN7_DS_SAMPLER_COUNT_SHIFT27
+# define GEN7_DS_BINDING_TABLE_ENTRY_COUNT_MASK INTEL_MASK(25, 18)
+# define GEN7_DS_BINDING_TABLE_ENTRY_COUNT_SHIFT18
+# define GEN7_DS_FLOATING_POINT_MODE_IEEE_754   (0 << 16)
+# define GEN7_DS_FLOATING_POINT_MODE_ALT(1 << 16)
+# define HSW_DS_ACCESSES_UAV(1 << 14)
+/* DW4 */
+# define GEN7_DS_DISPATCH_START_GRF_MASKINTEL_MASK(24, 20)
+# define GEN7_DS_DISPATCH_START_GRF_SHIFT   20
+# define GEN7_DS_URB_READ_LENGTH_MASK   INTEL_MASK(17, 11)
+# define GEN7_DS_URB_READ_LENGTH_SHIFT  11
+# define GEN7_DS_URB_ENTRY_READ_OFFSET_MASK INTEL_MASK(9, 4)
+# define GEN7_DS_URB_ENTRY_READ_OFFSET_SHIFT4
+/* DW5 */
+# define GEN7_DS_MAX_THREADS_SHIFT  25
+# define HSW_DS_MAX_THREADS_SHIFT   21
+# define GEN7_DS_STATISTICS_ENABLE  (1 << 1

[Mesa-dev] [PATCH 1/2] nir: Add a nir_system_value_from_intrinsic() function.

2015-09-07 Thread Kenneth Graunke
This converts NIR intrinsics that load system values into Mesa's
SYSTEM_VALUE_* enumerations.

Signed-off-by: Kenneth Graunke 
---
 src/glsl/nir/nir.c | 34 ++
 src/glsl/nir/nir.h |  2 ++
 2 files changed, 36 insertions(+)

diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index 3f4bec4..ab06ea2 100644
--- a/src/glsl/nir/nir.c
+++ b/src/glsl/nir/nir.c
@@ -1404,3 +1404,37 @@ nir_index_ssa_defs(nir_function_impl *impl)
nir_foreach_block(impl, index_ssa_block, &index);
impl->ssa_alloc = index;
 }
+
+gl_system_value
+nir_system_value_from_intrinsic(nir_intrinsic_op intrin)
+{
+   switch (intrin) {
+   case nir_intrinsic_load_vertex_id:
+  return SYSTEM_VALUE_VERTEX_ID;
+   case nir_intrinsic_load_instance_id:
+  return SYSTEM_VALUE_INSTANCE_ID;
+   case nir_intrinsic_load_vertex_id_zero_base:
+  return SYSTEM_VALUE_VERTEX_ID_ZERO_BASE;
+   case nir_intrinsic_load_base_vertex:
+  return SYSTEM_VALUE_BASE_VERTEX;
+   case nir_intrinsic_load_invocation_id:
+  return SYSTEM_VALUE_INVOCATION_ID;
+   case nir_intrinsic_load_front_face:
+  return SYSTEM_VALUE_FRONT_FACE;
+   case nir_intrinsic_load_sample_id:
+  return SYSTEM_VALUE_SAMPLE_ID;
+   case nir_intrinsic_load_sample_pos:
+  return SYSTEM_VALUE_SAMPLE_POS;
+   case nir_intrinsic_load_sample_mask_in:
+  return SYSTEM_VALUE_SAMPLE_MASK_IN;
+   /* FINISHME: Add tessellation intrinsics.
+  return SYSTEM_VALUE_TESS_COORD;
+  return SYSTEM_VALUE_VERTICES_IN;
+  return SYSTEM_VALUE_PRIMITIVE_ID;
+  return SYSTEM_VALUE_TESS_LEVEL_OUTER;
+  return SYSTEM_VALUE_TESS_LEVEL_INNER;
+*/
+   default:
+  unreachable("intrinsic doesn't produce a system value");
+   }
+}
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 53e883e..b13e92d 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -1843,6 +1843,8 @@ bool nir_opt_undef(nir_shader *shader);
 
 void nir_sweep(nir_shader *shader);
 
+gl_system_value nir_system_value_from_intrinsic(nir_intrinsic_op intrin);
+
 #ifdef __cplusplus
 } /* extern "C" */
 #endif
-- 
2.5.1

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


[Mesa-dev] [PATCH 2/2] i965/nir: Use nir_system_value_from_intrinsic to reduce duplication.

2015-09-07 Thread Kenneth Graunke
This code is all pretty much identical.  We just needed the translation
from one enum value to the other.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp   | 47 +++---
 src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 30 +--
 2 files changed, 17 insertions(+), 60 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 419ab6d..dbf10d6 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -1408,35 +1408,16 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, 
nir_intrinsic_instr *instr
case nir_intrinsic_load_vertex_id:
   unreachable("should be lowered by lower_vertex_id()");
 
-   case nir_intrinsic_load_vertex_id_zero_base: {
-  fs_reg vertex_id = nir_system_values[SYSTEM_VALUE_VERTEX_ID_ZERO_BASE];
-  assert(vertex_id.file != BAD_FILE);
-  dest.type = vertex_id.type;
-  bld.MOV(dest, vertex_id);
-  break;
-   }
-
-   case nir_intrinsic_load_base_vertex: {
-  fs_reg base_vertex = nir_system_values[SYSTEM_VALUE_BASE_VERTEX];
-  assert(base_vertex.file != BAD_FILE);
-  dest.type = base_vertex.type;
-  bld.MOV(dest, base_vertex);
-  break;
-   }
-
-   case nir_intrinsic_load_instance_id: {
-  fs_reg instance_id = nir_system_values[SYSTEM_VALUE_INSTANCE_ID];
-  assert(instance_id.file != BAD_FILE);
-  dest.type = instance_id.type;
-  bld.MOV(dest, instance_id);
-  break;
-   }
-
-   case nir_intrinsic_load_sample_mask_in: {
-  fs_reg sample_mask_in = nir_system_values[SYSTEM_VALUE_SAMPLE_MASK_IN];
-  assert(sample_mask_in.file != BAD_FILE);
-  dest.type = sample_mask_in.type;
-  bld.MOV(dest, sample_mask_in);
+   case nir_intrinsic_load_vertex_id_zero_base:
+   case nir_intrinsic_load_base_vertex:
+   case nir_intrinsic_load_instance_id:
+   case nir_intrinsic_load_sample_mask_in:
+   case nir_intrinsic_load_sample_id: {
+  gl_system_value sv = nir_system_value_from_intrinsic(instr->intrinsic);
+  fs_reg val = nir_system_values[sv];
+  assert(val.file != BAD_FILE);
+  dest.type = val.type;
+  bld.MOV(dest, val);
   break;
}
 
@@ -1449,14 +1430,6 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, 
nir_intrinsic_instr *instr
   break;
}
 
-   case nir_intrinsic_load_sample_id: {
-  fs_reg sample_id = nir_system_values[SYSTEM_VALUE_SAMPLE_ID];
-  assert(sample_id.file != BAD_FILE);
-  dest.type = sample_id.type;
-  bld.MOV(dest, sample_id);
-  break;
-   }
-
case nir_intrinsic_load_uniform_indirect:
   has_indirect = true;
   /* fallthrough */
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
index f3dc112..751ec73 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
@@ -533,30 +533,14 @@ vec4_visitor::nir_emit_intrinsic(nir_intrinsic_instr 
*instr)
case nir_intrinsic_load_vertex_id:
   unreachable("should be lowered by lower_vertex_id()");
 
-   case nir_intrinsic_load_vertex_id_zero_base: {
-  src_reg vertex_id =
- src_reg(nir_system_values[SYSTEM_VALUE_VERTEX_ID_ZERO_BASE]);
-  assert(vertex_id.file != BAD_FILE);
-  dest = get_nir_dest(instr->dest, vertex_id.type);
-  emit(MOV(dest, vertex_id));
-  break;
-   }
-
-   case nir_intrinsic_load_base_vertex: {
-  src_reg base_vertex =
- src_reg(nir_system_values[SYSTEM_VALUE_BASE_VERTEX]);
-  assert(base_vertex.file != BAD_FILE);
-  dest = get_nir_dest(instr->dest, base_vertex.type);
-  emit(MOV(dest, base_vertex));
-  break;
-   }
-
+   case nir_intrinsic_load_vertex_id_zero_base:
+   case nir_intrinsic_load_base_vertex:
case nir_intrinsic_load_instance_id: {
-  src_reg instance_id =
- src_reg(nir_system_values[SYSTEM_VALUE_INSTANCE_ID]);
-  assert(instance_id.file != BAD_FILE);
-  dest = get_nir_dest(instr->dest, instance_id.type);
-  emit(MOV(dest, instance_id));
+  gl_system_value sv = nir_system_value_from_intrinsic(instr->intrinsic);
+  src_reg val = src_reg(nir_system_values[sv]);
+  assert(val.file != BAD_FILE);
+  dest = get_nir_dest(instr->dest, val.type);
+  emit(MOV(dest, val));
   break;
}
 
-- 
2.5.1

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


Re: [Mesa-dev] [PATCH 1/2] i965: Fix value of _3DPRIM_TRIFAN_NOSTIPPLE.

2015-09-07 Thread Chris Forbes
These two are:

Reviewed-by: Chris Forbes 

On Mon, Sep 7, 2015 at 7:03 PM, Kenneth Graunke  wrote:
> TRIFAN_NOSTIPPLE has always been 0x16 - 0x15 is marked "Reserved" on all
> platforms.  See the 965 PRM, Volume 2, Table 3-1, "3D Primitive Topology
> Type Encoding" for a list.
>
> We don't currently use this, and I don't expect we will, but we may as
> well not leave the bogus value around.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_defines.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
> b/src/mesa/drivers/dri/i965/brw_defines.h
> index 0f7feb3..411a97d 100644
> --- a/src/mesa/drivers/dri/i965/brw_defines.h
> +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> @@ -77,7 +77,7 @@
>  #define _3DPRIM_LINESTRIP_CONT0x12
>  #define _3DPRIM_LINESTRIP_BF  0x13
>  #define _3DPRIM_LINESTRIP_CONT_BF 0x14
> -#define _3DPRIM_TRIFAN_NOSTIPPLE  0x15
> +#define _3DPRIM_TRIFAN_NOSTIPPLE  0x16
>
>  /* We use this offset to be able to pass native primitive types in struct
>   * _mesa_prim::mode.  Native primitive types are BRW_PRIM_OFFSET +
> --
> 2.5.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Adaptive Vsync

2015-09-07 Thread Emil Velikov
On 7 September 2015 at 05:59, Albert Freeman  wrote:
> Correction, we just need someone to mark all the comitted patches in
> patchwork...
This is already done automatically.

Sigh top posting :'(.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Adaptive Vsync

2015-09-07 Thread Martin Peres

On 07/09/15 11:22, Emil Velikov wrote:

On 7 September 2015 at 05:59, Albert Freeman  wrote:

Correction, we just need someone to mark all the comitted patches in
patchwork...

This is already done automatically.

Sigh top posting :'(.
-Emil


I often have to help patchwork a lot when I push my patches :s
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 91793] the "bin" directory is not created

2015-09-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91793

--- Comment #3 from Emil Velikov  ---
Nope, I mean that the requirements are not being met :)

It should be a matter of making sure the relevant .pc are around at configure
time and the headers + libs (.dll, .dll.a and/or .lib) are there at build/link
time.

That said I don't recall when was the last time I've tried building mesa-demos
for windows, but I do recall that at least some programs were around (built).

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


[Mesa-dev] [PATCH v2 1/2] egl/dri2: Close file descriptor on error.

2015-09-07 Thread Emil Velikov
From: Matt Turner 

v2: [Emil Velikov]
Rework the error path to a common goto, close only if we own the fd.

Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_drm.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index eda5087..e8fe7ea 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -623,26 +623,20 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
   dri2_dpy->own_device = 1;
   gbm = gbm_create_device(fd);
   if (gbm == NULL)
- return EGL_FALSE;
+ goto cleanup;
}
 
-   if (strcmp(gbm_device_get_backend_name(gbm), "drm") != 0) {
-  free(dri2_dpy);
-  return EGL_FALSE;
-   }
+   if (strcmp(gbm_device_get_backend_name(gbm), "drm") != 0)
+  goto cleanup;
 
dri2_dpy->gbm_dri = gbm_dri_device(gbm);
-   if (dri2_dpy->gbm_dri->base.type != GBM_DRM_DRIVER_TYPE_DRI) {
-  free(dri2_dpy);
-  return EGL_FALSE;
-   }
+   if (dri2_dpy->gbm_dri->base.type != GBM_DRM_DRIVER_TYPE_DRI)
+  goto cleanup;
 
if (fd < 0) {
   fd = fcntl(gbm_device_get_fd(gbm), F_DUPFD_CLOEXEC, 3);
-  if (fd < 0) {
- free(dri2_dpy);
- return EGL_FALSE;
-  }
+  if (fd < 0)
+ goto cleanup;
}
 
dri2_dpy->fd = fd;
@@ -727,4 +721,11 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
dri2_dpy->vtbl = &dri2_drm_display_vtbl;
 
return EGL_TRUE;
+
+cleanup:
+   if (dri2_dpy->own_device)
+  close(fd);
+
+   free(dri2_dpy);
+   return EGL_FALSE;
 }
-- 
2.5.0

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


[Mesa-dev] [PATCH 2/2] egl/dri2/drm: compact existing device mgmt

2015-09-07 Thread Emil Velikov
Move the fcntl(dupfd_cloexec) to the else branch where it belongs.
Otherwise it's not immediately obvious that the code is hit, only when
an existing device is used.

Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_drm.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index e8fe7ea..cccde12 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -624,6 +624,10 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
   gbm = gbm_create_device(fd);
   if (gbm == NULL)
  goto cleanup;
+   } else {
+  fd = fcntl(gbm_device_get_fd(gbm), F_DUPFD_CLOEXEC, 3);
+  if (fd < 0)
+ goto cleanup;
}
 
if (strcmp(gbm_device_get_backend_name(gbm), "drm") != 0)
@@ -633,12 +637,6 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
if (dri2_dpy->gbm_dri->base.type != GBM_DRM_DRIVER_TYPE_DRI)
   goto cleanup;
 
-   if (fd < 0) {
-  fd = fcntl(gbm_device_get_fd(gbm), F_DUPFD_CLOEXEC, 3);
-  if (fd < 0)
- goto cleanup;
-   }
-
dri2_dpy->fd = fd;
dri2_dpy->device_name = loader_get_device_name_for_fd(dri2_dpy->fd);
dri2_dpy->driver_name = strdup(dri2_dpy->gbm_dri->base.driver_name);
-- 
2.5.0

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


[Mesa-dev] [Bug 91888] EGL Wayland software rendering no longer work after regression

2015-09-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91888

--- Comment #2 from Daniel Stone  ---
I think that commit is a a red herring. 0x3098 is EGL_CONTEXT_CLIENT_VERSION,
and Mesa has recently gained more strictness:
 if ((api != EGL_OPENGL_ES_API &&
 (!dpy->Extensions.KHR_create_context || api != EGL_OPENGL_API))) {
   err = EGL_BAD_ATTRIBUTE;
   break;
 }

I suspect QWaylandGLContext is missing eglBindAPI(EGL_OPENGL_ES_API) before
context creation.

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


[Mesa-dev] [Bug 91869] [PATCH] ralloc: atexit(3) handlers used in dlopened libraries

2015-09-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91869

Jean-Sébastien Pédron  changed:

   What|Removed |Added

 Attachment #118072|0   |1
is obsolete||

--- Comment #1 from Jean-Sébastien Pédron  ---
Created attachment 118120
  --> https://bugs.freedesktop.org/attachment.cgi?id=118120&action=edit
Patch to use __attribute__((destructor)) in ralloc.c

This new patch adds a test for __attribute__((destructor)) in the configure
script and hides this attribute behind a "DESTRUCTOR" macro in
src/util/macros.h.

This is requested by Matt Turner on the mesa-dev@ mailing-list.

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


Re: [Mesa-dev] [PATCH] Use IMP_LIB_EXT when checking for LLVM shared libraries

2015-09-07 Thread Emil Velikov
Hi Jon,

On 4 September 2015 at 14:00, Jon TURNEY  wrote:
> When checking for LLVM shared libraries, use IMP_LIB_EXT for the extension for
> shared libraries appropriate to the target, rather than hardcoding '.so'
>
> Also add some comments to explain why we have this circus of pain.
>
> Signed-off-by: Jon TURNEY 
> ---
>  configure.ac | 33 +++--
>  1 file changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 90ba4fe..9960dd0 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -533,15 +533,32 @@ AM_CONDITIONAL(HAVE_COMPAT_SYMLINKS, test 
> "x$HAVE_COMPAT_SYMLINKS" = xyes)
>  dnl
>  dnl library names
>  dnl
> +dnl Unfortunately we need to do a few things that libtool can't help us with,
> +dnl so we need some knowledge of shared library filenames:
> +dnl
> +dnl LIB_EXT is the extension used when creating symlinks for alternate
> +dnl filenames for a shared library which will be dynamically loaded
> +dnl
> +dnl IMP_LIB_EXT is the extension used when checking for the presence of a
> +dnl the file for a shared library we wish to link with
> +dnl
>  case "$host_os" in
>  darwin* )
> -LIB_EXT='dylib' ;;
> +LIB_EXT='dylib'
> +IMP_LIB_EXT=$LIB_EXT
> +;;
>  cygwin* )
> -LIB_EXT='dll' ;;
> +LIB_EXT='dll'
> +IMP_LIB_EXT='dll.a'
> +;;
>  aix* )
> -LIB_EXT='a' ;;
> +LIB_EXT='a'
> +IMP_LIB_EXT=$LIB_EXT
> +;;
>  * )
> -LIB_EXT='so' ;;
> +LIB_EXT='so'
> +IMP_LIB_EXT=$LIB_EXT
> +;;
>  esac
>
>  AC_SUBST([LIB_EXT])
> @@ -2163,10 +2180,14 @@ if test "x$MESA_LLVM" != x0; then
>
>  LLVM_LIBS="`$LLVM_CONFIG --libs ${LLVM_COMPONENTS}`"
>
> +dnl llvm-config may not give the right answer when llvm is a built as a
> +dnl single shared library, so we must work the library name out for
> +dnl ourselves.
> +dnl (See https://llvm.org/bugs/show_bug.cgi?id=6823)
>  if test "x$enable_llvm_shared_libs" = xyes; then
>  dnl We can't use $LLVM_VERSION because it has 'svn' stripped out,
>  LLVM_SO_NAME=LLVM-`$LLVM_CONFIG --version`
> -AS_IF([test -f "$LLVM_LIBDIR/lib$LLVM_SO_NAME.so"], 
> [llvm_have_one_so=yes])
> +AS_IF([test -f "$LLVM_LIBDIR/lib$LLVM_SO_NAME.$IMP_LIB_EXT"], 
> [llvm_have_one_so=yes])
>
>  if test "x$llvm_have_one_so" = xyes; then
>  dnl LLVM was built using auto*, so there is only one shared 
> object.
> @@ -2174,7 +2195,7 @@ if test "x$MESA_LLVM" != x0; then
>  else
>  dnl If LLVM was built with CMake, there will be one shared 
> object per
>  dnl component.
> -AS_IF([test ! -f "$LLVM_LIBDIR/libLLVMTarget.so"],
> +AS_IF([test ! -f "$LLVM_LIBDIR/libLLVMTarget.$IMP_LIB_EXT"],
Fwiw I would prefer if we drop support for non have_one_so file LLVM
builds and just fail miserably, rather than having this around :-)
I suspect that either a) llvm people may have dropped support for it,
b) it's tested/used extremely rarely or c) busted with latest
llvm/mesa.

Tom how do you feel on the subject ? Can we drop this workaround,
pretty please (/me does the puppy eyes)

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


Re: [Mesa-dev] [Mesa-stable] [PATCH] ralloc: Use __attribute__((destructor)) instead of atexit(3)

2015-09-07 Thread Jean-Sébastien Pédron
On 06.09.2015 23:40, Emil Velikov wrote:
> Hi Jean-Sébastien,

Hi!

> On 3 September 2015 at 19:07, Jean-Sébastien Pédron
> We have 4(5) users of atexit() - EGL, gallium trace driver, core mesa
> and util/ralloc. The latter of which is used almost everywhere in
> mesa. So a bit I'm confused how you hit this only with OpenCL :-\
> Perhaps the others should be updated as well ?

That's what I'm wondering too.

I didn't read the code thoroughly; my guess is that in the case of the
OpenCL ICD loader, the loader explicitely dlclose() the backend. This
must not be the case with OpenGL applications.

I can update the patch to change all uses of atexit(3) if you are ok
with it.

>> __attribute__((destructor)) fixes the problem because such handlers are
>> called when a library is unloaded and when the program exits.
> Considering that atexit() (reportedly) works for Linux/Glibc, Solaris,
> Android and Windows perhaps we should consider this as a workaround
> for FreeBSD (and other *BSD) systems ?

On one hand, my concern is this behavior is an extension to the standard
and it could break for someone else. On the other hand, I don't like the
standard behavior and would be glad to see FreeBSD implement this extension.

I still think relying on this atexit(3) extension is fragile and I don't
consider the use of the attribute a workaround.

> Considering the multiple users (mentioned above) should one set
> priority for the destructors ?

You are right, I didn't think of the calling order of the destructors.

-- 
Jean-Sébastien Pédron



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


Re: [Mesa-dev] [PATCH] ralloc: Use __attribute__((destructor)) instead of atexit(3)

2015-09-07 Thread Jean-Sébastien Pédron
On 04.09.2015 01:37, Matt Turner wrote:
> You need to test for this support in configure.ac. It's as simple as
> adding a call to AX_GCC_FUNC_ATTRIBUTE in the existing alphabetized
> list and then a little bit of preprocessor in src/util/macros.h.

Should the code fallbacks on atexit(3) if the attribute is not
supported? Can I use the HAVE_FUNC_ATTRIBUTE_DESTRUCTOR macro in
ralloc.c for this purpose?

-- 
Jean-Sébastien Pédron



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


Re: [Mesa-dev] [PATCH v4 (part2) 19/59] i965/wm: surfaces should have the API buffer size, not the drm buffer size

2015-09-07 Thread Samuel Iglesias Gonsálvez


On 29/08/15 00:59, Jordan Justen wrote:
> On 2015-08-05 01:30:16, Iago Toral Quiroga wrote:
>> From: Samuel Iglesias Gonsalvez 
>>
>> The returned drm buffer object has a size multiple of 4096 but that should 
>> not
>> be exposed to the API user, which is working with a different size.
> 
> Would the only API where this would be visible be unsized array
> length? If so, maybe you could just mention it directly in the commit
> message.
> 

Yeah, it is only visible when getting the buffer size from the HW. The
other APIs are not affected.

We will add it to the commit log.

> Reviewed-by: Jordan Justen 
> 

Thanks,

Sam

>> Signed-off-by: Samuel Iglesias Gonsalvez 
>> ---
>>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
>> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
>> index 08ad8e8..ac820af 100644
>> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
>> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
>> @@ -941,7 +941,7 @@ brw_upload_ubo_surfaces(struct brw_context *brw,
>>binding->Offset,
>>binding->BufferObject->Size - 
>> binding->Offset);
>>  brw_create_constant_surface(brw, bo, binding->Offset,
>> -bo->size - binding->Offset,
>> +binding->BufferObject->Size - 
>> binding->Offset,
>>  &surf_offsets[i],
>>  dword_pitch);
>>   }
>> @@ -958,7 +958,7 @@ brw_upload_ubo_surfaces(struct brw_context *brw,
>>binding->Offset,
>>binding->BufferObject->Size - 
>> binding->Offset);
>>  brw_create_buffer_surface(brw, bo, binding->Offset,
>> -  bo->size - binding->Offset,
>> +  binding->BufferObject->Size - 
>> binding->Offset,
>>&surf_offsets[i],
>>dword_pitch);
>>   }
>> -- 
>> 1.9.1
>>
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 (part2) 19/59] i965/wm: surfaces should have the API buffer size, not the drm buffer size

2015-09-07 Thread Samuel Iglesias Gonsálvez


On 07/09/15 11:32, Samuel Iglesias Gonsálvez wrote:
> 
> 
> On 29/08/15 00:59, Jordan Justen wrote:
>> On 2015-08-05 01:30:16, Iago Toral Quiroga wrote:
>>> From: Samuel Iglesias Gonsalvez 
>>>
>>> The returned drm buffer object has a size multiple of 4096 but that should 
>>> not
>>> be exposed to the API user, which is working with a different size.
>>
>> Would the only API where this would be visible be unsized array
>> length? If so, maybe you could just mention it directly in the commit
>> message.
>>
> 
> Yeah, it is only visible when getting the buffer size from the HW. The
> other APIs are not affected.
> 
> We will add it to the commit log.
> 

It seems this email was not sent before. I have just sent it to have it
in the mailing list archive.

Thanks,

Sam

>> Reviewed-by: Jordan Justen 
>>
> 
> Thanks,
> 
> Sam
> 
>>> Signed-off-by: Samuel Iglesias Gonsalvez 
>>> ---
>>>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
>>> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
>>> index 08ad8e8..ac820af 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
>>> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
>>> @@ -941,7 +941,7 @@ brw_upload_ubo_surfaces(struct brw_context *brw,
>>>binding->Offset,
>>>binding->BufferObject->Size - 
>>> binding->Offset);
>>>  brw_create_constant_surface(brw, bo, binding->Offset,
>>> -bo->size - binding->Offset,
>>> +binding->BufferObject->Size - 
>>> binding->Offset,
>>>  &surf_offsets[i],
>>>  dword_pitch);
>>>   }
>>> @@ -958,7 +958,7 @@ brw_upload_ubo_surfaces(struct brw_context *brw,
>>>binding->Offset,
>>>binding->BufferObject->Size - 
>>> binding->Offset);
>>>  brw_create_buffer_surface(brw, bo, binding->Offset,
>>> -  bo->size - binding->Offset,
>>> +  binding->BufferObject->Size - 
>>> binding->Offset,
>>>&surf_offsets[i],
>>>dword_pitch);
>>>   }
>>> -- 
>>> 1.9.1
>>>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] ralloc: Use __attribute__((destructor)) instead of atexit(3)

2015-09-07 Thread Jean-Sébastien Pédron
On 04.09.2015 01:37, Matt Turner wrote:
>> +__attribute__((destructor))
> 
> You need to test for this support in configure.ac. It's as simple as
> adding a call to AX_GCC_FUNC_ATTRIBUTE in the existing alphabetized
> list and then a little bit of preprocessor in src/util/macros.h. (I
> think you should put "DESTRUCTOR" or whatever macro name you choose on
> the same line with "static void" like is done in intel_tiled_memcpy.c
> for FLATTEN)

Thanks, I modified the patch.

I first sent the patch using Git, but probably due to some grey-listing
somewhere, it took a while to reach the mailing-list. Meanwhile, I filed
a bug in Bugzilla [1]. To avoid confusion, do you prefer I send the new
patch to the list too or should I continue with Bugzilla?

[1] https://bugs.freedesktop.org/show_bug.cgi?id=91869

-- 
Jean-Sébastien Pédron



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


Re: [Mesa-dev] [PATCH 0/2] Fix remaining uses of X11_CFLAGS

2015-09-07 Thread Emil Velikov
Hi Jon,

On 4 September 2015 at 12:43, Jon TURNEY  wrote:
> X11_CFLAGS isn't defined by configure.ac since commmit 35189d76 removed 
> PKG_CHECK_MODULES([X11],[x11])
>
> Fix the remaining uses of X11_CFLAGS.  There are no uses of X11_LIBS
>
> Jon TURNEY (2):
>   Use X11_INCLUDES instead of X11_CFLAGS
>   Remove unneeded X11_CFLAGS
>
Thanks for this. I've been meaning to do it for quite some time.

I've added a prefix/topic for each patch and pushed them to master.

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


Re: [Mesa-dev] [PATCH] nir: UBO loads no longer use const_index[1]

2015-09-07 Thread Iago Toral
Jason, since that commit is yours, could you review this change? it is a
one liner.

Thanks,
Iago

On Tue, 2015-09-01 at 11:32 +0200, Iago Toral Quiroga wrote:
> Commit 2126c68e5cba killed the array elements parameter on load/store
> intrinsics that was stored in const_index[1]. It looks like that
> patch missed to remove this assignment in the UBO path.
> ---
>  src/glsl/nir/glsl_to_nir.cpp | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
> index 5fb4ee2..0712908 100644
> --- a/src/glsl/nir/glsl_to_nir.cpp
> +++ b/src/glsl/nir/glsl_to_nir.cpp
> @@ -1001,7 +1001,6 @@ nir_visitor::visit(ir_expression *ir)
>nir_intrinsic_instr *load = nir_intrinsic_instr_create(this->shader, 
> op);
>load->num_components = ir->type->vector_elements;
>load->const_index[0] = const_index ? const_index->value.u[0] : 0; /* 
> base offset */
> -  load->const_index[1] = 1; /* number of vec4's */
>load->src[0] = evaluate_rvalue(ir->operands[0]);
>if (!const_index)
>   load->src[1] = evaluate_rvalue(ir->operands[1]);


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


Re: [Mesa-dev] [PATCH] i965: Disallow fast blit paths for CopyTexImage with PixelTransfer ops

2015-09-07 Thread Iago Toral
Looks correct, based on the previous discussion about the same fix for
ReadPixels and TexImage. CopyTexImage has the same requirements.

Reviewed-by: Iago Toral Quiroga 

On Sun, 2015-09-06 at 17:37 +0100, Chris Wilson wrote:
> glCopyTexImage behaves similarly to glReadPixels with respect to the
> pixel transfer operations. Therefore if any are set we cannot use the
> simply blit fast paths.
> 
> Signed-off-by: Chris Wilson 
> Cc: Jason Ekstrand 
> Cc: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 4 
>  src/mesa/drivers/dri/i965/intel_tex_copy.c   | 4 
>  2 files changed, 8 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
> b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> index 205c905..ba11d3d 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> @@ -215,6 +215,10 @@ brw_blorp_copytexsubimage(struct brw_context *brw,
> struct intel_renderbuffer *src_irb = intel_renderbuffer(src_rb);
> struct intel_texture_image *intel_image = intel_texture_image(dst_image);
>  
> +   /* No pixel transfer operations (zoom, bias, mapping), just a blit */
> +   if (brw->ctx._ImageTransferState)
> +  return false;
> +
> /* Sync up the state of window system buffers.  We need to do this before
>  * we go looking at the src renderbuffer's miptree.
>  */
> diff --git a/src/mesa/drivers/dri/i965/intel_tex_copy.c 
> b/src/mesa/drivers/dri/i965/intel_tex_copy.c
> index 4d8c82e..ecdd052 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_copy.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_copy.c
> @@ -55,6 +55,10 @@ intel_copy_texsubimage(struct brw_context *brw,
> const GLenum internalFormat = intelImage->base.Base.InternalFormat;
> bool ret;
>  
> +   /* No pixel transfer operations (zoom, bias, mapping), just a blit */
> +   if (brw->ctx._ImageTransferState)
> +  return false;
> +
> intel_prepare_render(brw);
>  
> /* glCopyTexSubImage() can be called on a multisampled renderbuffer (if


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


Re: [Mesa-dev] [PATCH] ralloc: Use __attribute__((destructor)) instead of atexit(3)

2015-09-07 Thread Jose Fonseca

On 07/09/15 10:17, Jean-Sébastien Pédron wrote:

On 04.09.2015 01:37, Matt Turner wrote:

You need to test for this support in configure.ac. It's as simple as
adding a call to AX_GCC_FUNC_ATTRIBUTE in the existing alphabetized
list and then a little bit of preprocessor in src/util/macros.h.


Should the code fallbacks on atexit(3) if the attribute is not
supported?


At least on Windows, with MSVC,  atexit should be the right thing to do, 
since we statically link MSVC RunTime,



> Can I use the HAVE_FUNC_ATTRIBUTE_DESTRUCTOR macro in

ralloc.c for this purpose?





For the record, another alternative (way more portable), is you have a 
simple .cpp file with a static destructior:



  class AtExit
  {
  public:
 ~AtExit() {
 // do what must be done
  }
  };

  AtExit atExit();


After all, it seems wrong to use non-standard C to replicate what 
standard C++ can do.



Jose

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


Re: [Mesa-dev] [PATCH 1/2] nir: Add a nir_system_value_from_intrinsic() function.

2015-09-07 Thread Iago Toral
Reviewed-by: Iago Toral Quiroga 

On Mon, 2015-09-07 at 00:30 -0700, Kenneth Graunke wrote:
> This converts NIR intrinsics that load system values into Mesa's
> SYSTEM_VALUE_* enumerations.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/glsl/nir/nir.c | 34 ++
>  src/glsl/nir/nir.h |  2 ++
>  2 files changed, 36 insertions(+)
> 
> diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
> index 3f4bec4..ab06ea2 100644
> --- a/src/glsl/nir/nir.c
> +++ b/src/glsl/nir/nir.c
> @@ -1404,3 +1404,37 @@ nir_index_ssa_defs(nir_function_impl *impl)
> nir_foreach_block(impl, index_ssa_block, &index);
> impl->ssa_alloc = index;
>  }
> +
> +gl_system_value
> +nir_system_value_from_intrinsic(nir_intrinsic_op intrin)
> +{
> +   switch (intrin) {
> +   case nir_intrinsic_load_vertex_id:
> +  return SYSTEM_VALUE_VERTEX_ID;
> +   case nir_intrinsic_load_instance_id:
> +  return SYSTEM_VALUE_INSTANCE_ID;
> +   case nir_intrinsic_load_vertex_id_zero_base:
> +  return SYSTEM_VALUE_VERTEX_ID_ZERO_BASE;
> +   case nir_intrinsic_load_base_vertex:
> +  return SYSTEM_VALUE_BASE_VERTEX;
> +   case nir_intrinsic_load_invocation_id:
> +  return SYSTEM_VALUE_INVOCATION_ID;
> +   case nir_intrinsic_load_front_face:
> +  return SYSTEM_VALUE_FRONT_FACE;
> +   case nir_intrinsic_load_sample_id:
> +  return SYSTEM_VALUE_SAMPLE_ID;
> +   case nir_intrinsic_load_sample_pos:
> +  return SYSTEM_VALUE_SAMPLE_POS;
> +   case nir_intrinsic_load_sample_mask_in:
> +  return SYSTEM_VALUE_SAMPLE_MASK_IN;
> +   /* FINISHME: Add tessellation intrinsics.
> +  return SYSTEM_VALUE_TESS_COORD;
> +  return SYSTEM_VALUE_VERTICES_IN;
> +  return SYSTEM_VALUE_PRIMITIVE_ID;
> +  return SYSTEM_VALUE_TESS_LEVEL_OUTER;
> +  return SYSTEM_VALUE_TESS_LEVEL_INNER;
> +*/
> +   default:
> +  unreachable("intrinsic doesn't produce a system value");
> +   }
> +}
> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> index 53e883e..b13e92d 100644
> --- a/src/glsl/nir/nir.h
> +++ b/src/glsl/nir/nir.h
> @@ -1843,6 +1843,8 @@ bool nir_opt_undef(nir_shader *shader);
>  
>  void nir_sweep(nir_shader *shader);
>  
> +gl_system_value nir_system_value_from_intrinsic(nir_intrinsic_op intrin);
> +
>  #ifdef __cplusplus
>  } /* extern "C" */
>  #endif


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


Re: [Mesa-dev] [PATCH 2/2] i965/nir: Use nir_system_value_from_intrinsic to reduce duplication.

2015-09-07 Thread Iago Toral
Reviewed-by: Iago Toral Quiroga 

On Mon, 2015-09-07 at 00:30 -0700, Kenneth Graunke wrote:
> This code is all pretty much identical.  We just needed the translation
> from one enum value to the other.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp   | 47 
> +++---
>  src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 30 +--
>  2 files changed, 17 insertions(+), 60 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> index 419ab6d..dbf10d6 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> @@ -1408,35 +1408,16 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, 
> nir_intrinsic_instr *instr
> case nir_intrinsic_load_vertex_id:
>unreachable("should be lowered by lower_vertex_id()");
>  
> -   case nir_intrinsic_load_vertex_id_zero_base: {
> -  fs_reg vertex_id = nir_system_values[SYSTEM_VALUE_VERTEX_ID_ZERO_BASE];
> -  assert(vertex_id.file != BAD_FILE);
> -  dest.type = vertex_id.type;
> -  bld.MOV(dest, vertex_id);
> -  break;
> -   }
> -
> -   case nir_intrinsic_load_base_vertex: {
> -  fs_reg base_vertex = nir_system_values[SYSTEM_VALUE_BASE_VERTEX];
> -  assert(base_vertex.file != BAD_FILE);
> -  dest.type = base_vertex.type;
> -  bld.MOV(dest, base_vertex);
> -  break;
> -   }
> -
> -   case nir_intrinsic_load_instance_id: {
> -  fs_reg instance_id = nir_system_values[SYSTEM_VALUE_INSTANCE_ID];
> -  assert(instance_id.file != BAD_FILE);
> -  dest.type = instance_id.type;
> -  bld.MOV(dest, instance_id);
> -  break;
> -   }
> -
> -   case nir_intrinsic_load_sample_mask_in: {
> -  fs_reg sample_mask_in = nir_system_values[SYSTEM_VALUE_SAMPLE_MASK_IN];
> -  assert(sample_mask_in.file != BAD_FILE);
> -  dest.type = sample_mask_in.type;
> -  bld.MOV(dest, sample_mask_in);
> +   case nir_intrinsic_load_vertex_id_zero_base:
> +   case nir_intrinsic_load_base_vertex:
> +   case nir_intrinsic_load_instance_id:
> +   case nir_intrinsic_load_sample_mask_in:
> +   case nir_intrinsic_load_sample_id: {
> +  gl_system_value sv = nir_system_value_from_intrinsic(instr->intrinsic);
> +  fs_reg val = nir_system_values[sv];
> +  assert(val.file != BAD_FILE);
> +  dest.type = val.type;
> +  bld.MOV(dest, val);
>break;
> }
>  
> @@ -1449,14 +1430,6 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, 
> nir_intrinsic_instr *instr
>break;
> }
>  
> -   case nir_intrinsic_load_sample_id: {
> -  fs_reg sample_id = nir_system_values[SYSTEM_VALUE_SAMPLE_ID];
> -  assert(sample_id.file != BAD_FILE);
> -  dest.type = sample_id.type;
> -  bld.MOV(dest, sample_id);
> -  break;
> -   }
> -
> case nir_intrinsic_load_uniform_indirect:
>has_indirect = true;
>/* fallthrough */
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> index f3dc112..751ec73 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> @@ -533,30 +533,14 @@ vec4_visitor::nir_emit_intrinsic(nir_intrinsic_instr 
> *instr)
> case nir_intrinsic_load_vertex_id:
>unreachable("should be lowered by lower_vertex_id()");
>  
> -   case nir_intrinsic_load_vertex_id_zero_base: {
> -  src_reg vertex_id =
> - src_reg(nir_system_values[SYSTEM_VALUE_VERTEX_ID_ZERO_BASE]);
> -  assert(vertex_id.file != BAD_FILE);
> -  dest = get_nir_dest(instr->dest, vertex_id.type);
> -  emit(MOV(dest, vertex_id));
> -  break;
> -   }
> -
> -   case nir_intrinsic_load_base_vertex: {
> -  src_reg base_vertex =
> - src_reg(nir_system_values[SYSTEM_VALUE_BASE_VERTEX]);
> -  assert(base_vertex.file != BAD_FILE);
> -  dest = get_nir_dest(instr->dest, base_vertex.type);
> -  emit(MOV(dest, base_vertex));
> -  break;
> -   }
> -
> +   case nir_intrinsic_load_vertex_id_zero_base:
> +   case nir_intrinsic_load_base_vertex:
> case nir_intrinsic_load_instance_id: {
> -  src_reg instance_id =
> - src_reg(nir_system_values[SYSTEM_VALUE_INSTANCE_ID]);
> -  assert(instance_id.file != BAD_FILE);
> -  dest = get_nir_dest(instr->dest, instance_id.type);
> -  emit(MOV(dest, instance_id));
> +  gl_system_value sv = nir_system_value_from_intrinsic(instr->intrinsic);
> +  src_reg val = src_reg(nir_system_values[sv]);
> +  assert(val.file != BAD_FILE);
> +  dest = get_nir_dest(instr->dest, val.type);
> +  emit(MOV(dest, val));
>break;
> }
>  


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


Re: [Mesa-dev] [PATCH 02/13] i965: Keep track of whether LRI is allowed in the context struct.

2015-09-07 Thread Francisco Jerez
Chris Wilson  writes:

> On Sun, Sep 06, 2015 at 07:48:40PM +0300, Francisco Jerez wrote:
>> Chris Wilson  writes:
>> 
>> > On Sun, Sep 06, 2015 at 07:28:12PM +0300, Francisco Jerez wrote:
>> >> Chris Wilson  writes:
>> >> 
>> >> > On Sun, Sep 06, 2015 at 06:12:40PM +0200, Francisco Jerez wrote:
>> >> >> This stores the result of can_do_pipelined_register_writes() in the
>> >> >> context struct so we can find out later whether LRI can be used to
>> >> >> program the L3 configuration.
>> >> >
>> >> > LRI are whitelisted by their register. To be generic you must explicitly
>> >> > test access to the register you want to modify.
>> >> > -Chris
>> >> >
>> >> AFAIK except for the chicken bits used to enable L3 atomics on HSW
>> >> (which is tested explicitly elsewhere, see PATCH 07), all other
>> >> registers written to are whitelisted since command parser revision 1 --
>> >> I don't think that any released kernel version had the command parser
>> >> enabled on Gen7 but any of the required registers blacklisted.
>> >
>> > At the moment you are not even checking that param. The test is written
>> > to be independent of knowledge of  cmdparser internals and by virtue a
>> > much stronger test. Use it to your advantage.
>> > -Chris
>> >
>> What advantage do you mean?
>
> Kernel indepencence:
>
>> If the test passes the command parser is
>> either enabled (in which case L3 programming will work) or there is no
>> actual hardware security (in which case L3 programming will work).  If
>> it fails the command parser is disabled and hardware security enabled
>> (in which case L3 programming will not work either).
>
> Exactly. Which is why I suggest writing the test in that manner.

I'm sure you had some specific practical advantage in mind?  Bashing the
rather sensitive L3 configuration registers to see if something sticks
is a hack with potential implications.  I'd prefer to avoid that unless
there is a reason why it could be useful.

> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre


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


Re: [Mesa-dev] [PATCH 02/13] i965: Keep track of whether LRI is allowed in the context struct.

2015-09-07 Thread Chris Wilson
On Mon, Sep 07, 2015 at 05:21:53PM +0300, Francisco Jerez wrote:
> I'm sure you had some specific practical advantage in mind?  Bashing the
> rather sensitive L3 configuration registers to see if something sticks
> is a hack with potential implications.  I'd prefer to avoid that unless
> there is a reason why it could be useful.

It prevents an incorrect assumption about kernel ABI. The cost of which
is seeing whether you know how to program registers correctly from the
ring.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/13] i965: Keep track of whether LRI is allowed in the context struct.

2015-09-07 Thread Francisco Jerez
Chris Wilson  writes:

> On Mon, Sep 07, 2015 at 05:21:53PM +0300, Francisco Jerez wrote:
>> I'm sure you had some specific practical advantage in mind?  Bashing the
>> rather sensitive L3 configuration registers to see if something sticks
>> is a hack with potential implications.  I'd prefer to avoid that unless
>> there is a reason why it could be useful.
>
> It prevents an incorrect assumption about kernel ABI. The cost of which
> is seeing whether you know how to program registers correctly from the
> ring.
> -Chris

All other codepaths that need to use LRI to write registers share the
same can_do_pipelined_register_writes() test and make assumptions about
the kernel ABI from there.  Ideally there would be a kernel param
userspace could use to query whether the command parser is active, but
there is not, so it doesn't look like we can do better than pick some
harmless register (the L3 config registers are not), write it from a
batch, and infer whether the command parser is active or not from the
result.

If you have any evidence that the assumption about the kernel ABI made
here is wrong, please share it, we should probably just blacklist the
specific command parser revisions for which the assumption doesn't hold.

>
> -- 
> Chris Wilson, Intel Open Source Technology Centre


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


Re: [Mesa-dev] [PATCH] i965: Disallow fast blit paths for CopyTexImage with PixelTransfer ops

2015-09-07 Thread Kenneth Graunke
On Sunday, September 06, 2015 05:37:18 PM Chris Wilson wrote:
> glCopyTexImage behaves similarly to glReadPixels with respect to the
> pixel transfer operations. Therefore if any are set we cannot use the
> simply blit fast paths.
> 
> Signed-off-by: Chris Wilson 
> Cc: Jason Ekstrand 
> Cc: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 4 
>  src/mesa/drivers/dri/i965/intel_tex_copy.c   | 4 
>  2 files changed, 8 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
> b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> index 205c905..ba11d3d 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> @@ -215,6 +215,10 @@ brw_blorp_copytexsubimage(struct brw_context *brw,
> struct intel_renderbuffer *src_irb = intel_renderbuffer(src_rb);
> struct intel_texture_image *intel_image = intel_texture_image(dst_image);
>  
> +   /* No pixel transfer operations (zoom, bias, mapping), just a blit */
> +   if (brw->ctx._ImageTransferState)
> +  return false;
> +
> /* Sync up the state of window system buffers.  We need to do this before
>  * we go looking at the src renderbuffer's miptree.
>  */
> diff --git a/src/mesa/drivers/dri/i965/intel_tex_copy.c 
> b/src/mesa/drivers/dri/i965/intel_tex_copy.c
> index 4d8c82e..ecdd052 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_copy.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_copy.c
> @@ -55,6 +55,10 @@ intel_copy_texsubimage(struct brw_context *brw,
> const GLenum internalFormat = intelImage->base.Base.InternalFormat;
> bool ret;
>  
> +   /* No pixel transfer operations (zoom, bias, mapping), just a blit */
> +   if (brw->ctx._ImageTransferState)
> +  return false;
> +
> intel_prepare_render(brw);
>  
> /* glCopyTexSubImage() can be called on a multisampled renderbuffer (if
> 

Looks right to me; we could probably easily support zoom if we wanted -
blorp already can handle scaled blits.  This seems good in the meantime.

Reviewed-by: Kenneth Graunke 


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


Re: [Mesa-dev] [RFC] i965: Resolve color for all active shader images in intel_update_state().

2015-09-07 Thread Kenneth Graunke
On Saturday, September 05, 2015 08:58:07 PM Chris Wilson wrote:
> On Sat, Sep 05, 2015 at 11:30:44AM -0700, Jordan Justen wrote:
> > From: Francisco Jerez 
> > 
> > Fixes 
> > arb_shader_image_load_store/execution/load-from-cleared-image.shader_test
> > 
> > Cc: Chris Wilson 
> > Cc: Jason Ekstrand 
> > Tested-by: Jordan Justen 
> > ---
> >  RE: i965: Perform an explicit flush after doing _mesa_meta_pbo_TexSubImage
> > 
> >  curro has some concerns about potential perf impact by this and
> >  wanted it to be checked on small-core w/CPU bound apps.
> >  Unfortunately, he is on vacation now.
> 
> One thing that may help (other than having a bitfield of valid
> ImageUnits being more cache friendly) is that intel_update_state() need
> only invalidate state. Moving the heavyweight resolves/flushes to just
> prior to running the pipeline should help reduce the profile of the
> fairly frequently called mesa_update_state().
> -Chris

 _ 
< welcome to recursive meta hell! >
 - 
  \/ \  //\
   \|\___/|  /   \//  \\
/0  0  \__  ///  | \ \
   / /  \/_///   |  \  \  
   @_^_@'/   \/_   //|   \   \ 
   //_^_/ \/_ // |\\
( //) |\///  | \ \
  ( / /) _|_ /   )  //   |  \ _\
( // /) '/,_ _ _/  ( ; -.|_ _\.-~.-~~~^-.
  (( / / )) ,-{_  `-.|.-~-.   .~ `.
 (( // / ))  '/\  / ~-. _ .-~  .-~^-.  \
 (( /// ))  `.   {}   /  \  \
  (( / )) .~-.\\-' .~ \  `. \^-.
 ///...>\ _ -~ `.  ^-`  ^-_
   ///-._ _ _ _ _ _ _}^ - - - - ~ ~-- ,.-~
  /.-~

That sounds reasonable, but fair warning: Kristian spent literally a month
trying to figure out how to make this work, and we tried a wide variety of
reasonable sounding plans that ended up falling apart.  Awkward resolve
timings make for a world of nasty corner cases.

--Ken


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


Re: [Mesa-dev] [PATCH] nir: UBO loads no longer use const_index[1]

2015-09-07 Thread Jason Ekstrand
LGTM:

Reviewed-by: Jason Ekstrand 

On Mon, Sep 7, 2015 at 4:52 AM, Iago Toral  wrote:
> Jason, since that commit is yours, could you review this change? it is a
> one liner.
>
> Thanks,
> Iago
>
> On Tue, 2015-09-01 at 11:32 +0200, Iago Toral Quiroga wrote:
>> Commit 2126c68e5cba killed the array elements parameter on load/store
>> intrinsics that was stored in const_index[1]. It looks like that
>> patch missed to remove this assignment in the UBO path.
>> ---
>>  src/glsl/nir/glsl_to_nir.cpp | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
>> index 5fb4ee2..0712908 100644
>> --- a/src/glsl/nir/glsl_to_nir.cpp
>> +++ b/src/glsl/nir/glsl_to_nir.cpp
>> @@ -1001,7 +1001,6 @@ nir_visitor::visit(ir_expression *ir)
>>nir_intrinsic_instr *load = nir_intrinsic_instr_create(this->shader, 
>> op);
>>load->num_components = ir->type->vector_elements;
>>load->const_index[0] = const_index ? const_index->value.u[0] : 0; /* 
>> base offset */
>> -  load->const_index[1] = 1; /* number of vec4's */
>>load->src[0] = evaluate_rvalue(ir->operands[0]);
>>if (!const_index)
>>   load->src[1] = evaluate_rvalue(ir->operands[1]);
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [RFC] i965: Resolve color for all active shader images in intel_update_state().

2015-09-07 Thread Chris Wilson
On Mon, Sep 07, 2015 at 10:15:56AM -0700, Kenneth Graunke wrote:
> On Saturday, September 05, 2015 08:58:07 PM Chris Wilson wrote:
> > On Sat, Sep 05, 2015 at 11:30:44AM -0700, Jordan Justen wrote:
> > > From: Francisco Jerez 
> > > 
> > > Fixes 
> > > arb_shader_image_load_store/execution/load-from-cleared-image.shader_test
> > > 
> > > Cc: Chris Wilson 
> > > Cc: Jason Ekstrand 
> > > Tested-by: Jordan Justen 
> > > ---
> > >  RE: i965: Perform an explicit flush after doing 
> > > _mesa_meta_pbo_TexSubImage
> > > 
> > >  curro has some concerns about potential perf impact by this and
> > >  wanted it to be checked on small-core w/CPU bound apps.
> > >  Unfortunately, he is on vacation now.
> > 
> > One thing that may help (other than having a bitfield of valid
> > ImageUnits being more cache friendly) is that intel_update_state() need
> > only invalidate state. Moving the heavyweight resolves/flushes to just
> > prior to running the pipeline should help reduce the profile of the
> > fairly frequently called mesa_update_state().
> > -Chris
> 
>  _ 
> < welcome to recursive meta hell! >
>  - 
>   \/ \  //\
>\|\___/|  /   \//  \\
> /0  0  \__  ///  | \ \
>/ /  \/_///   |  \  \  
>@_^_@'/   \/_   //|   \   \ 
>//_^_/ \/_ // |\\
> ( //) |\///  | \ \
>   ( / /) _|_ /   )  //   |  \ _\
> ( // /) '/,_ _ _/  ( ; -.|_ _\.-~.-~~~^-.
>   (( / / )) ,-{_  `-.|.-~-.   .~ `.
>  (( // / ))  '/\  / ~-. _ .-~  .-~^-.  \
>  (( /// ))  `.   {}   /  \  \
>   (( / )) .~-.\\-' .~ \  `. \^-.
>  ///...>\ _ -~ `.  ^-`  ^-_
>///-._ _ _ _ _ _ _}^ - - - - ~ ~-- ,.-~
>   /.-~
> 
> That sounds reasonable, but fair warning: Kristian spent literally a month
> trying to figure out how to make this work, and we tried a wide variety of
> reasonable sounding plans that ended up falling apart.  Awkward resolve
> timings make for a world of nasty corner cases.

Solution I have is to add a new callback from vbo before vbo->draw_prims
to avoid the recursion. Looking at it, I am pretty sure the current code
will also recurse and fail miserable along some meta paths.

Haven't checked non-i965 for sanity, so wip:

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 78cd269..580131d 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -160,37 +160,12 @@ static void
 intel_update_state(struct gl_context * ctx, GLuint new_state)
 {
struct brw_context *brw = brw_context(ctx);
-   struct intel_texture_object *tex_obj;
-   struct intel_renderbuffer *depth_irb;
 
if (ctx->swrast_context)
   _swrast_InvalidateState(ctx, new_state);
_vbo_InvalidateState(ctx, new_state);
 
brw->NewGLState |= new_state;
-
-   _mesa_unlock_context_textures(ctx);
-
-   /* Resolve the depth buffer's HiZ buffer. */
-   depth_irb = intel_get_renderbuffer(ctx->DrawBuffer, BUFFER_DEPTH);
-   if (depth_irb)
-  intel_renderbuffer_resolve_hiz(brw, depth_irb);
-
-   /* Resolve depth buffer and render cache of each enabled texture. */
-   int maxEnabledUnit = ctx->Texture._MaxEnabledTexImageUnit;
-   for (int i = 0; i <= maxEnabledUnit; i++) {
-  if (!ctx->Texture.Unit[i]._Current)
-continue;
-  tex_obj = intel_texture_object(ctx->Texture.Unit[i]._Current);
-  if (!tex_obj || !tex_obj->mt)
-continue;
-  intel_miptree_all_slices_resolve_depth(brw, tex_obj->mt);
-  intel_miptree_resolve_color(brw, tex_obj->mt);
-  if (brw_check_dirty(tex_obj->mt->bo))
- brw->ctx.NewDriverState |= BRW_NEW_CACHE_FLUSH;
-   }
-
-   _mesa_lock_context_textures(ctx);
 }
 
 #define flushFront(screen)  ((screen)->image.loader ? 
(screen)->image.loader->flushFrontBuffer : 
(screen)->dri2.loader->flushFrontBuffer)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 7a42403..bda251f 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -339,6 +339,38 @@ brw_merge_inputs(struct brw_context *brw,
}
 }
 
+static void
+brw_draw_resolve(struct gl_context *ctx)
+{
+   struct brw_context *brw = brw_context(ctx);
+   struct intel_texture_object *tex_obj;
+   struct intel_renderbuffer *depth_irb;
+
+   /* Resolve the depth buffer's HiZ buffer. */
+   depth_irb = intel_get_renderbuffer(brw->ctx.DrawBuffer, BUFFER_DEPTH);
+   if (depth_irb)
+  intel_renderbuffer_resolve_hiz(brw, depth_irb);
+
+   /* Resolve depth buffer and render cache of each 

Re: [Mesa-dev] [PATCH 3/5] nir: Add new GS intrinsics that maintain a count of emitted vertices.

2015-09-07 Thread Jason Ekstrand
On Sep 3, 2015 1:49 AM, "Kenneth Graunke"  wrote:
>
> This patch also introduces a lowering pass to convert the simple GS
> intrinsics to the new ones.  See the comments above that for the
> rationale behind the new intrinsics.
>
> This should be useful for i965; it's a generic enough mechanism that I
> could see other drivers potentially using it as well, so I don't feel
> too bad about putting it in the generic code.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/glsl/Makefile.sources  |   1 +
>  src/glsl/nir/nir.h |   2 +
>  src/glsl/nir/nir_intrinsics.h  |  21 
>  src/glsl/nir/nir_lower_gs_intrinsics.c | 214
+
>  4 files changed, 238 insertions(+)
>  create mode 100644 src/glsl/nir/nir_lower_gs_intrinsics.c
>
> diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
> index c422303..ae2e3e1 100644
> --- a/src/glsl/Makefile.sources
> +++ b/src/glsl/Makefile.sources
> @@ -36,6 +36,7 @@ NIR_FILES = \
> nir/nir_lower_alu_to_scalar.c \
> nir/nir_lower_atomics.c \
> nir/nir_lower_global_vars_to_local.c \
> +   nir/nir_lower_gs_intrinsics.c \
> nir/nir_lower_load_const_to_scalar.c \
> nir/nir_lower_locals_to_regs.c \
> nir/nir_lower_idiv.c \
> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> index 570a33c..13f123f 100644
> --- a/src/glsl/nir/nir.h
> +++ b/src/glsl/nir/nir.h
> @@ -1809,6 +1809,8 @@ void nir_lower_idiv(nir_shader *shader);
>  void nir_lower_atomics(nir_shader *shader);
>  void nir_lower_to_source_mods(nir_shader *shader);
>
> +void nir_lower_gs_intrinsics(nir_shader *shader);
> +
>  void nir_normalize_cubemap_coords(nir_shader *shader);
>
>  void nir_live_variables_impl(nir_function_impl *impl);
> diff --git a/src/glsl/nir/nir_intrinsics.h b/src/glsl/nir/nir_intrinsics.h
> index ed309b6..bcfe70d 100644
> --- a/src/glsl/nir/nir_intrinsics.h
> +++ b/src/glsl/nir/nir_intrinsics.h
> @@ -79,9 +79,30 @@ BARRIER(memory_barrier)
>  /** A conditional discard, with a single boolean source. */
>  INTRINSIC(discard_if, 1, ARR(1), false, 0, 0, 0, 0)
>
> +/**
> + * Basic Geometry Shader intrinsics.
> + *
> + * emit_vertex implements GLSL's EmitStreamVertex() built-in.  It takes
a single
> + * index, which is the stream ID to write to.
> + *
> + * end_primitive implements GLSL's EndPrimitive() built-in.
> + */
>  INTRINSIC(emit_vertex,   0, ARR(), false, 0, 0, 1, 0)
>  INTRINSIC(end_primitive, 0, ARR(), false, 0, 0, 1, 0)
>
> +/**
> + * Geometry Shader intrinsics with a vertex count.
> + *
> + * Alternatively, drivers may implement these intrinsics, and use
> + * nir_lower_gs_intrinsics() to convert from the basic intrinsics.
> + *
> + * These maintain a count of the number of vertices emitted, as an
additional
> + * unsigned integer source.
> + */
> +INTRINSIC(emit_vertex_with_counter, 1, ARR(1), false, 0, 0, 1, 0)
> +INTRINSIC(end_primitive_with_counter, 1, ARR(1), false, 0, 0, 1, 0)
> +INTRINSIC(set_vertex_count, 1, ARR(1), false, 0, 0, 0, 0)
> +
>  /*
>   * Atomic counters
>   *
> diff --git a/src/glsl/nir/nir_lower_gs_intrinsics.c
b/src/glsl/nir/nir_lower_gs_intrinsics.c
> new file mode 100644
> index 000..b866d87
> --- /dev/null
> +++ b/src/glsl/nir/nir_lower_gs_intrinsics.c
> @@ -0,0 +1,214 @@
> +/*
> + * Copyright © 2015 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.
> + *
> + * Authors:
> + *Kenneth Graunke 
> + */
> +
> +#include "nir.h"
> +#include "nir_builder.h"
> +
> +/**
> + * \file nir_lower_gs_intrinsics.c
> + *
> + * Geometry Shaders can call EmitVertex()/EmitStreamVertex() to output an
> + * arbitrary number of vertices.  However, the shader must declare the
maximum
> + * number of vertices that it will ever output - further attempts to emit
> + * vertices result in undefined behavior according to the GLSL
specification.
>

Re: [Mesa-dev] [PATCH 4/5] i965/gs: Use new NIR intrinsics.

2015-09-07 Thread Jason Ekstrand
On Thu, Sep 3, 2015 at 1:48 AM, Kenneth Graunke  wrote:
> By performing the vertex counting in NIR, we're able to elide a ton of
> useless safety checks around every EmitVertex() call:
>
> total instructions in shared programs: 3952 -> 3720 (-5.87%)
> instructions in affected programs: 3491 -> 3259 (-6.65%)
> helped:11
> HURT:  0
>
> Improves performance in Gl32GSCloth by 0.671742% +/- 0.142202% (n=621)
> on Haswell GT3e at 1024x768.
>
> This should also make it easier to implement Broadwell's "Static Vertex
> Count" feature someday.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_nir.c   |  5 
>  src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp | 13 +--
>  src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 28 
> ---
>  src/mesa/drivers/dri/i965/gen6_gs_visitor.cpp | 28 
> ++-
>  4 files changed, 48 insertions(+), 26 deletions(-)
>
> There are a couple regressions left with this patch, which are actually bugs
> in the NIR control flow graph modification code.  I wrote a fix, which IIRC
> got this to zero regressions.  But I've found even more bugs in the NIR CFG
> code, so I'm working on yet more fixes.  I'll sort that out before landing
> this, but figured I may as well send it out for review in the meantime - I've
> had these patches a long time.
>
> diff --git a/src/mesa/drivers/dri/i965/brw_nir.c 
> b/src/mesa/drivers/dri/i965/brw_nir.c
> index 8f3edc5..15e79ba 100644
> --- a/src/mesa/drivers/dri/i965/brw_nir.c
> +++ b/src/mesa/drivers/dri/i965/brw_nir.c
> @@ -93,6 +93,11 @@ brw_create_nir(struct brw_context *brw,
> }
> nir_validate_shader(nir);
>
> +   if (stage == MESA_SHADER_GEOMETRY) {
> +  nir_lower_gs_intrinsics(nir);
> +  nir_validate_shader(nir);
> +   }
> +
> nir_lower_global_vars_to_local(nir);
> nir_validate_shader(nir);
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp
> index 8a8dd57..4f4e1e1 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp
> @@ -92,16 +92,25 @@ vec4_gs_visitor::nir_emit_intrinsic(nir_intrinsic_instr 
> *instr)
> src_reg src;
>
> switch (instr->intrinsic) {
> -   case nir_intrinsic_emit_vertex: {
> +   case nir_intrinsic_emit_vertex_with_counter: {
> +  this->vertex_count =
> + retype(get_nir_src(instr->src[0], 1), BRW_REGISTER_TYPE_UD);
>int stream_id = instr->const_index[0];
>gs_emit_vertex(stream_id);
>break;
> }
>
> -   case nir_intrinsic_end_primitive:
> +   case nir_intrinsic_end_primitive_with_counter:
> +  this->vertex_count =
> + retype(get_nir_src(instr->src[0], 1), BRW_REGISTER_TYPE_UD);

It seems kind of odd to me that we are seetting a vertex_count state
variable in this case and in the one above.  Wouldn't it be better to
pass the vertex count in to end_primitive() and emit_vertex()?  That
can be a refactor for another day though; after we delete the old
vec4_visitor code.

Modulo getting the CF bugs fixed, this series is

Reviewed-by: Jason Ekstrand 

>gs_end_primitive();
>break;
>
> +   case nir_intrinsic_set_vertex_count:
> +  this->vertex_count =
> + retype(get_nir_src(instr->src[0], 1), BRW_REGISTER_TYPE_UD);
> +  break;
> +
> case nir_intrinsic_load_invocation_id: {
>src_reg invocation_id =
>   src_reg(nir_system_values[SYSTEM_VALUE_INVOCATION_ID]);
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
> index 019efec..70c0f8e 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
> @@ -484,14 +484,6 @@ vec4_gs_visitor::gs_emit_vertex(int stream_id)
> if (stream_id > 0 && shader_prog->TransformFeedback.NumVarying == 0)
>return;
>
> -   /* To ensure that we don't output more vertices than the shader specified
> -* using max_vertices, do the logic inside a conditional of the form "if
> -* (vertex_count < MAX)"
> -*/
> -   unsigned num_output_vertices = c->gp->program.VerticesOut;
> -   emit(CMP(dst_null_d(), this->vertex_count,
> -src_reg(num_output_vertices), BRW_CONDITIONAL_L));
> -   emit(IF(BRW_PREDICATE_NORMAL));
> {
>/* If we're outputting 32 control data bits or less, then we can wait
> * until the shader is over to output them all.  Otherwise we need to
> @@ -562,12 +554,7 @@ vec4_gs_visitor::gs_emit_vertex(int stream_id)
>this->current_annotation = "emit vertex: Stream control data bits";
>set_stream_control_data_bits(stream_id);
>}
> -
> -  this->current_annotation = "emit vertex: increment vertex count";
> -  emit(ADD(dst_reg(this->vertex_count), this->vertex_count,
> -   src_reg(1u))

Re: [Mesa-dev] [PATCH 4/5] i965/gs: Use new NIR intrinsics.

2015-09-07 Thread Jason Ekstrand
On Mon, Sep 7, 2015 at 11:06 AM, Jason Ekstrand  wrote:
> On Thu, Sep 3, 2015 at 1:48 AM, Kenneth Graunke  wrote:
>> By performing the vertex counting in NIR, we're able to elide a ton of
>> useless safety checks around every EmitVertex() call:
>>
>> total instructions in shared programs: 3952 -> 3720 (-5.87%)
>> instructions in affected programs: 3491 -> 3259 (-6.65%)
>> helped:11
>> HURT:  0
>>
>> Improves performance in Gl32GSCloth by 0.671742% +/- 0.142202% (n=621)
>> on Haswell GT3e at 1024x768.
>>
>> This should also make it easier to implement Broadwell's "Static Vertex
>> Count" feature someday.
>>
>> Signed-off-by: Kenneth Graunke 
>> ---
>>  src/mesa/drivers/dri/i965/brw_nir.c   |  5 
>>  src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp | 13 +--
>>  src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 28 
>> ---
>>  src/mesa/drivers/dri/i965/gen6_gs_visitor.cpp | 28 
>> ++-
>>  4 files changed, 48 insertions(+), 26 deletions(-)
>>
>> There are a couple regressions left with this patch, which are actually bugs
>> in the NIR control flow graph modification code.  I wrote a fix, which IIRC
>> got this to zero regressions.  But I've found even more bugs in the NIR CFG
>> code, so I'm working on yet more fixes.  I'll sort that out before landing
>> this, but figured I may as well send it out for review in the meantime - I've
>> had these patches a long time.
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_nir.c 
>> b/src/mesa/drivers/dri/i965/brw_nir.c
>> index 8f3edc5..15e79ba 100644
>> --- a/src/mesa/drivers/dri/i965/brw_nir.c
>> +++ b/src/mesa/drivers/dri/i965/brw_nir.c
>> @@ -93,6 +93,11 @@ brw_create_nir(struct brw_context *brw,
>> }
>> nir_validate_shader(nir);
>>
>> +   if (stage == MESA_SHADER_GEOMETRY) {
>> +  nir_lower_gs_intrinsics(nir);
>> +  nir_validate_shader(nir);
>> +   }
>> +
>> nir_lower_global_vars_to_local(nir);
>> nir_validate_shader(nir);
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp 
>> b/src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp
>> index 8a8dd57..4f4e1e1 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_nir.cpp
>> @@ -92,16 +92,25 @@ vec4_gs_visitor::nir_emit_intrinsic(nir_intrinsic_instr 
>> *instr)
>> src_reg src;
>>
>> switch (instr->intrinsic) {
>> -   case nir_intrinsic_emit_vertex: {
>> +   case nir_intrinsic_emit_vertex_with_counter: {
>> +  this->vertex_count =
>> + retype(get_nir_src(instr->src[0], 1), BRW_REGISTER_TYPE_UD);
>>int stream_id = instr->const_index[0];
>>gs_emit_vertex(stream_id);
>>break;
>> }
>>
>> -   case nir_intrinsic_end_primitive:
>> +   case nir_intrinsic_end_primitive_with_counter:
>> +  this->vertex_count =
>> + retype(get_nir_src(instr->src[0], 1), BRW_REGISTER_TYPE_UD);
>
> It seems kind of odd to me that we are seetting a vertex_count state
> variable in this case and in the one above.  Wouldn't it be better to
> pass the vertex count in to end_primitive() and emit_vertex()?  That
> can be a refactor for another day though; after we delete the old
> vec4_visitor code.
>
> Modulo getting the CF bugs fixed, this series is

And the comments on patch 3 of course.

> Reviewed-by: Jason Ekstrand 
>
>>gs_end_primitive();
>>break;
>>
>> +   case nir_intrinsic_set_vertex_count:
>> +  this->vertex_count =
>> + retype(get_nir_src(instr->src[0], 1), BRW_REGISTER_TYPE_UD);
>> +  break;
>> +
>> case nir_intrinsic_load_invocation_id: {
>>src_reg invocation_id =
>>   src_reg(nir_system_values[SYSTEM_VALUE_INVOCATION_ID]);
>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
>> b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
>> index 019efec..70c0f8e 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
>> @@ -484,14 +484,6 @@ vec4_gs_visitor::gs_emit_vertex(int stream_id)
>> if (stream_id > 0 && shader_prog->TransformFeedback.NumVarying == 0)
>>return;
>>
>> -   /* To ensure that we don't output more vertices than the shader specified
>> -* using max_vertices, do the logic inside a conditional of the form "if
>> -* (vertex_count < MAX)"
>> -*/
>> -   unsigned num_output_vertices = c->gp->program.VerticesOut;
>> -   emit(CMP(dst_null_d(), this->vertex_count,
>> -src_reg(num_output_vertices), BRW_CONDITIONAL_L));
>> -   emit(IF(BRW_PREDICATE_NORMAL));
>> {
>>/* If we're outputting 32 control data bits or less, then we can wait
>> * until the shader is over to output them all.  Otherwise we need to
>> @@ -562,12 +554,7 @@ vec4_gs_visitor::gs_emit_vertex(int stream_id)
>>this->current_annotation = "emit vertex: Stream control data 
>> bits";
>>set_

Re: [Mesa-dev] [PATCH V3 1/6] glsl: order indices for samplers inside a struct array

2015-09-07 Thread Jason Ekstrand
On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri  wrote:
> This allows the correct offset to be easily calculated for indirect
> indexing when a struct array contains multiple samplers, or any crazy
> nesting.
>
> The indices for the folling struct will now look like this:
> Sampler index: 0 Name: s[0].tex
> Sampler index: 1 Name: s[1].tex
> Sampler index: 2 Name: s[0].si.tex
> Sampler index: 3 Name: s[1].si.tex
> Sampler index: 4 Name: s[0].si.tex2
> Sampler index: 5 Name: s[1].si.tex2
>
> Before this change it looked like this:
> Sampler index: 0 Name: s[0].tex
> Sampler index: 3 Name: s[1].tex
> Sampler index: 1 Name: s[0].si.tex
> Sampler index: 4 Name: s[1].si.tex
> Sampler index: 2 Name: s[0].si.tex2
> Sampler index: 5 Name: s[1].si.tex2
>
> struct S_inner {
>sampler2D tex;
>sampler2D tex2;
> };
>
> struct S {
>sampler2D tex;
>S_inner si;
> };
>
> uniform S s[2];
>
> V2: rename struct array counter to have better name
> ---
>  src/glsl/link_uniforms.cpp | 112 
> ++---
>  src/glsl/linker.h  |   4 +-
>  2 files changed, 98 insertions(+), 18 deletions(-)
>
> diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
> index 254086d..5402c99 100644
> --- a/src/glsl/link_uniforms.cpp
> +++ b/src/glsl/link_uniforms.cpp
> @@ -28,6 +28,7 @@
>  #include "glsl_symbol_table.h"
>  #include "program/hash_table.h"
>  #include "program.h"
> +#include "util/hash_table.h"
>
>  /**
>   * \file link_uniforms.cpp
> @@ -63,14 +64,17 @@ program_resource_visitor::process(const glsl_type *type, 
> const char *name)
> assert(type->without_array()->is_record()
>|| type->without_array()->is_interface());
>
> +   unsigned record_array_count = 1;
> char *name_copy = ralloc_strdup(NULL, name);
> -   recursion(type, &name_copy, strlen(name), false, NULL, false);
> +   recursion(type, &name_copy, strlen(name), false, NULL, false,
> + record_array_count);
> ralloc_free(name_copy);
>  }
>
>  void
>  program_resource_visitor::process(ir_variable *var)
>  {
> +   unsigned record_array_count = 1;
> const glsl_type *t = var->type;
> const bool row_major =
>var->data.matrix_layout == GLSL_MATRIX_LAYOUT_ROW_MAJOR;
> @@ -111,7 +115,8 @@ program_resource_visitor::process(ir_variable *var)
>* lowering is only applied to non-uniform interface blocks, so we
>* can safely pass false for row_major.
>*/
> - recursion(var->type, &name, new_length, row_major, NULL, false);
> + recursion(var->type, &name, new_length, row_major, NULL, false,
> +   record_array_count);
>}
>ralloc_free(name);
> } else if (var->data.from_named_ifc_block_nonarray) {
> @@ -135,19 +140,23 @@ program_resource_visitor::process(ir_variable *var)
> * is only applied to non-uniform interface blocks, so we can safely
> * pass false for row_major.
> */
> -  recursion(var->type, &name, strlen(name), row_major, NULL, false);
> +  recursion(var->type, &name, strlen(name), row_major, NULL, false,
> +record_array_count);
>ralloc_free(name);
> } else if (t->without_array()->is_record()) {
>char *name = ralloc_strdup(NULL, var->name);
> -  recursion(var->type, &name, strlen(name), row_major, NULL, false);
> +  recursion(var->type, &name, strlen(name), row_major, NULL, false,
> +record_array_count);
>ralloc_free(name);
> } else if (t->is_interface()) {
>char *name = ralloc_strdup(NULL, var->type->name);
> -  recursion(var->type, &name, strlen(name), row_major, NULL, false);
> +  recursion(var->type, &name, strlen(name), row_major, NULL, false,
> +record_array_count);
>ralloc_free(name);
> } else if (t->is_array() && t->fields.array->is_interface()) {
>char *name = ralloc_strdup(NULL, var->type->fields.array->name);
> -  recursion(var->type, &name, strlen(name), row_major, NULL, false);
> +  recursion(var->type, &name, strlen(name), row_major, NULL, false,
> +record_array_count);
>ralloc_free(name);
> } else {
>this->visit_field(t, var->name, row_major, NULL, false);
> @@ -158,7 +167,8 @@ void
>  program_resource_visitor::recursion(const glsl_type *t, char **name,
>  size_t name_length, bool row_major,
>  const glsl_type *record_type,
> -bool last_field)
> +bool last_field,
> +unsigned record_array_count)
>  {
> /* Records need to have each field processed individually.
>  *
> @@ -205,7 +215,7 @@ program_resource_visitor::recursion(const glsl_type *t, 
> char **name,
>   recursion(t->fields.structure[i].type, name, new_length,
> field_row_major,
> record

Re: [Mesa-dev] [PATCH V3 2/6] glsl: assign hidden uniforms their slot id earlier

2015-09-07 Thread Jason Ekstrand
On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri  wrote:
> This is required so that the next patch can safely assign the slot id
> to the var.
>
> The ids are now assigned in the order we want before allocating storage
> so there is no need to sort the storage array and move things around.
> ---
>  src/glsl/link_uniforms.cpp | 90 
> +-
>  1 file changed, 41 insertions(+), 49 deletions(-)
>
> diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
> index 5402c99..da8f2f7 100644
> --- a/src/glsl/link_uniforms.cpp
> +++ b/src/glsl/link_uniforms.cpp
> @@ -300,11 +300,12 @@ namespace {
>   */
>  class count_uniform_size : public program_resource_visitor {
>  public:
> -   count_uniform_size(struct string_to_uint_map *map)
> -  : num_active_uniforms(0), num_values(0), num_shader_samplers(0),
> -num_shader_images(0), num_shader_uniform_components(0),
> -num_shader_subroutines(0),
> -is_ubo_var(false), map(map)
> +   count_uniform_size(struct string_to_uint_map *map,
> +  struct string_to_uint_map *hidden_map)
> +  : num_active_uniforms(0), num_hidden_uniforms(0), num_values(0),
> +num_shader_samplers(0), num_shader_images(0),
> +num_shader_uniform_components(0), num_shader_subroutines(0),
> +is_ubo_var(false), map(map), hidden_map(hidden_map)
> {
>/* empty */
> }
> @@ -319,6 +320,7 @@ public:
>
> void process(ir_variable *var)
> {
> +  this->current_var = var;
>this->is_ubo_var = var->is_in_buffer_block();
>if (var->is_interface_instance())
>   program_resource_visitor::process(var->get_interface_type(),
> @@ -332,6 +334,8 @@ public:
>  */
> unsigned num_active_uniforms;
>
> +   unsigned num_hidden_uniforms;
> +
> /**
>  * Number of data values required to back the storage for the active 
> uniforms
>  */
> @@ -359,6 +363,8 @@ public:
>
> bool is_ubo_var;
>
> +   struct string_to_uint_map *map;
> +
>  private:
> virtual void visit_field(const glsl_type *type, const char *name,
>  bool row_major)
> @@ -402,7 +408,13 @@ private:
>if (this->map->get(id, name))
>  return;
>
> -  this->map->put(this->num_active_uniforms, name);
> +  if (this->current_var->data.how_declared == ir_var_hidden) {
> + this->hidden_map->put(this->num_hidden_uniforms, name);
> + this->num_hidden_uniforms++;
> +  } else {
> + this->map->put(this->num_active_uniforms - 
> this->num_hidden_uniforms,
> +name);
> +  }
>
>/* Each leaf uniform occupies one entry in the list of active
> * uniforms.
> @@ -411,7 +423,12 @@ private:
>this->num_values += values;
> }
>
> -   struct string_to_uint_map *map;
> +   struct string_to_uint_map *hidden_map;
> +
> +   /**
> +* Current variable being processed.
> +*/
> +   ir_variable *current_var;
>  };
>
>  } /* anonymous namespace */
> @@ -961,47 +978,19 @@ link_set_image_access_qualifiers(struct 
> gl_shader_program *prog)
>  }
>
>  /**
> - * Sort the array of uniform storage so that the non-hidden uniforms are 
> first
> - *
> - * This function sorts the list "in place."  This is important because some 
> of
> - * the storage accessible from \c uniforms has \c uniforms as its \c ralloc
> - * context.  If \c uniforms is freed, some other storage will also be freed.
> + * Combine the hidden uniform hash map with the uniform hash map so that the
> + * hidden uniforms will be given indicies at the end of the uniform storage
> + * array.
>   */
> -static unsigned
> -move_hidden_uniforms_to_end(struct gl_shader_program *prog,
> -struct gl_uniform_storage *uniforms,
> -unsigned num_elements)
> +static void
> +assign_hidden_uniform_slot_id(const char *name, unsigned hidden_id,
> +  void *closure)
>  {
> -   struct gl_uniform_storage *sorted_uniforms =
> -  ralloc_array(prog, struct gl_uniform_storage, num_elements);
> -   unsigned hidden_uniforms = 0;
> -   unsigned j = 0;
> -
> -   /* Add the non-hidden uniforms. */
> -   for (unsigned i = 0; i < num_elements; i++) {
> -  if (!uniforms[i].hidden)
> - sorted_uniforms[j++] = uniforms[i];
> -   }
> -
> -   /* Add and count the hidden uniforms. */
> -   for (unsigned i = 0; i < num_elements; i++) {
> -  if (uniforms[i].hidden) {
> - sorted_uniforms[j++] = uniforms[i];
> - hidden_uniforms++;
> -  }
> -   }
> +   count_uniform_size *uniform_size = (count_uniform_size *) closure;
> +   unsigned hidden_slot_id = uniform_size->num_active_uniforms -
> +  uniform_size->num_hidden_uniforms + hidden_id;

Very minor nit-pick, but would you mind making this
"hidden_uniform_start" and then making the line below
"hidden_uniform_start + hidden_id"?  IMHO, that's easier to read.  If
you really like what you'v

Re: [Mesa-dev] [PATCH V3 3/6] glsl: store uniform slot id in var location field

2015-09-07 Thread Jason Ekstrand
On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri  wrote:
> This will allow us to access the uniform later on without resorting to
> building a name string and looking it up in UniformHash.
>
> V2: store slot number for all non-UBO uniforms to make code more
> consitent, renamed explicit_binding to explicit_location and added
> comment about what it does. Store the location at every shader stage.
> Updated data.location comments in ir/nir.h.
> ---
>  src/glsl/ir.h  |  2 ++
>  src/glsl/link_uniforms.cpp | 27 +++
>  src/glsl/nir/nir.h |  1 +
>  3 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/src/glsl/ir.h b/src/glsl/ir.h
> index ede8caa..d06abaf 100644
> --- a/src/glsl/ir.h
> +++ b/src/glsl/ir.h
> @@ -819,6 +819,8 @@ public:
> *   - Fragment shader output: one of the values from \c 
> gl_frag_result.
> *   - Uniforms: Per-stage uniform slot number for default uniform 
> block.
> *   - Uniforms: Index within the uniform block definition for UBO 
> members.
> +   *   - Non-UBO Uniforms: explicit binding until linking then reused to
> +   * store uniform slot number.
> *   - Other: This field is not currently used.
> *
> * If the variable is a uniform, shader input, or shader output, and 
> the
> diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
> index da8f2f7..f68ea9d 100644
> --- a/src/glsl/link_uniforms.cpp
> +++ b/src/glsl/link_uniforms.cpp
> @@ -528,7 +528,13 @@ public:
>  var->get_interface_type()->name);
>   else
>  process(var);
> -  } else
> +  } else {
> + /* Store any explicit location and reset data location so we can
> +  * reuse this variable for storing the uniform slot number.
> +  */
> + this->explicit_location = current_var->data.location;
> + current_var->data.location = -1;
> +
>   process(var);
>}
>delete this->record_next_sampler;
> @@ -706,6 +712,13 @@ private:
>handle_images(base_type, &this->uniforms[id]);
>handle_subroutines(base_type, &this->uniforms[id]);
>
> +  /* For array of arrays or struct arrays the base location may have
> +   * already been set so dont set it again.
> +   */
> +  if (ubo_block_index == -1 && current_var->data.location == -1) {
> + current_var->data.location = id;
> +  }
> +
>/* If there is already storage associated with this uniform or if the
> * uniform is set as builtin, it means that it was set while processing
> * an earlier shader stage.  For example, we may be processing the
> @@ -720,12 +733,13 @@ private:
>if (current_var->data.explicit_location) {
>   /* Set sequential locations for struct fields. */
>   if (record_type != NULL) {
> -const unsigned entries = MAX2(1, 
> this->uniforms[id].array_elements);
> +const unsigned entries =
> +   MAX2(1, this->uniforms[id].array_elements);

Spurious change?  I'm all for line-wrapping but if that's all this is,
it should be separate.  Other than that,

Reviewed-by: Jason Ekstrand 

>  this->uniforms[id].remap_location =
> -   current_var->data.location + field_counter;
> +   this->explicit_location + field_counter;
>  field_counter += entries;
>   } else {
> -this->uniforms[id].remap_location = current_var->data.location;
> + this->uniforms[id].remap_location = this->explicit_location;
>   }
>} else {
>   /* Initialize to to indicate that no location is set */
> @@ -791,6 +805,11 @@ private:
> unsigned next_image;
> unsigned next_subroutine;
>
> +   /* Used to store the explicit location from current_var so that we can
> +* reuse the location field for storing the uniform slot id.
> +*/
> +   int explicit_location;
> +
> /* Stores total struct array elements including nested structs */
> unsigned record_array_count;
>
> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> index 9703372..36fbf5c 100644
> --- a/src/glsl/nir/nir.h
> +++ b/src/glsl/nir/nir.h
> @@ -278,6 +278,7 @@ typedef struct {
> *   - Fragment shader output: one of the values from \c 
> gl_frag_result.
> *   - Uniforms: Per-stage uniform slot number for default uniform 
> block.
> *   - Uniforms: Index within the uniform block definition for UBO 
> members.
> +   *   - Non-UBO Uniforms: uniform slot number.
> *   - Other: This field is not currently used.
> *
> * If the variable is a uniform, shader input, or shader output, and 
> the
> --
> 2.4.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.fr

Re: [Mesa-dev] [PATCH V3 4/6] glsl: make variables private

2015-09-07 Thread Jason Ekstrand
Reviewed-by: Jason Ekstrand 

On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri  wrote:
> ---
>  src/glsl/link_uniforms.cpp | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
> index f68ea9d..c28ac52 100644
> --- a/src/glsl/link_uniforms.cpp
> +++ b/src/glsl/link_uniforms.cpp
> @@ -805,6 +805,17 @@ private:
> unsigned next_image;
> unsigned next_subroutine;
>
> +   /**
> +* Field counter is used to take care that uniform structures
> +* with explicit locations get sequential locations.
> +*/
> +   unsigned field_counter;
> +
> +   /**
> +* Current variable being processed.
> +*/
> +   ir_variable *current_var;
> +
> /* Used to store the explicit location from current_var so that we can
>  * reuse the location field for storing the uniform slot id.
>  */
> @@ -824,17 +835,6 @@ public:
> gl_texture_index targets[MAX_SAMPLERS];
>
> /**
> -* Current variable being processed.
> -*/
> -   ir_variable *current_var;
> -
> -   /**
> -* Field counter is used to take care that uniform structures
> -* with explicit locations get sequential locations.
> -*/
> -   unsigned field_counter;
> -
> -   /**
>  * Mask of samplers used by the current shader stage.
>  */
> unsigned shader_samplers_used;
> --
> 2.4.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [Mesa-stable] [PATCH v2 2/2] gallium/hud: display the Celsius temperature unit

2015-09-07 Thread Benjamin Bellec
Le 05/09/2015 10:19, Samuel Pitoiset a écrit :
>
> On 09/04/2015 08:57 PM, Benjamin Bellec wrote:
>> Currently, the temperature is displayed with a "%" symbol in
>> gallium/hud, which is quite odd.
>> Marek suggested to only change the value "100" to another value so
>> that this symbol is no more displayed. That works very well. This is
>> the patch #1. I choose "125" because it can be divided nicely by 5,
>> then the threshold displayed on the hud graph are 25/50/75/100/etc.
>> And also because with this, the actual temperature value is generally
>> in the middle of the graph.
>>
>> This second patch is totally optional. It "catch" the value "125" in
>> order to display a "C" instead of nothing.
>>
>> Ref. your suggestion on PIPE_DRIVER_QUERY_TYPE_TEMPERATURE, I'm not
>> skilled enough to answer.
>>
> Your first attempt at writing this patch introduced this
> PIPE_DRIVER_QUERY_TYPE_TEMPERATURE.
> Please, re-introduce it correctly. :)

I don't think to have the skills to do that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH mesa 2/3] nv30: Fix color resolving for nv3x cards

2015-09-07 Thread Hans de Goede
We do not have a generic blitter on nv3x cards, so we must use the
sifm object for color resolving.

This commit divides the sources and dest surfaces in to tiles which
match the constraints of the sifm object, so that color resolving
will work properly on nv3x cards.

Signed-off-by: Hans de Goede 
---
 src/gallium/drivers/nouveau/nv30/nv30_miptree.c | 55 -
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c 
b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
index 76bb8b8..c240030 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
@@ -149,6 +149,56 @@ static void
 nv30_resource_resolve(struct nv30_context *nv30,
   const struct pipe_blit_info *info)
 {
+   struct nv30_miptree *src_mt = nv30_miptree(info->src.resource);
+   struct nv30_rect src, dst;
+   unsigned x, x0, x1, y, y1, w, h;
+
+   define_rect(info->src.resource, 0, info->src.box.z, info->src.box.x,
+  info->src.box.y, info->src.box.width, info->src.box.height, &src);
+   define_rect(info->dst.resource, 0, info->dst.box.z, info->dst.box.x,
+  info->dst.box.y, info->dst.box.width, info->dst.box.height, &dst);
+
+   x0 = src.x0;
+   x1 = src.x1;
+   y1 = src.y1;
+
+   /* On nv3x we must use sifm which is restricted to 512x512 tiles */
+   for (y = src.y0; y < y1; y += h) {
+  h = y1 - y;
+  if (h > 512)
+ h = 512;
+
+  src.y0 = 0;
+  src.y1 = h;
+  src.h = h;
+
+  dst.y1 = dst.y0 + (h >> src_mt->ms_y);
+  dst.h = h >> src_mt->ms_y;
+
+  for (x = x0; x < x1; x += w) {
+ w = x1 - x;
+ if (w > 512)
+w = 512;
+
+ src.offset = y * src.pitch + x * src.cpp;
+ src.x0 = 0;
+ src.x1 = w;
+ src.w = w;
+
+ dst.offset = (y >> src_mt->ms_y) * dst.pitch +
+  (x >> src_mt->ms_x) * dst.cpp;
+ dst.x1 = dst.x0 + (w >> src_mt->ms_x);
+ dst.w = w >> src_mt->ms_x;
+
+ nv30_transfer_rect(nv30, BILINEAR, &src, &dst);
+  }
+   }
+}
+
+static void
+nv40_resource_resolve(struct nv30_context *nv30,
+  const struct pipe_blit_info *info)
+{
struct nv30_rect src, dst;
 
define_rect(info->src.resource, 0, info->src.box.z, info->src.box.x,
@@ -170,7 +220,10 @@ nv30_blit(struct pipe_context *pipe,
info.dst.resource->nr_samples <= 1 &&
!util_format_is_depth_or_stencil(info.src.resource->format) &&
!util_format_is_pure_integer(info.src.resource->format)) {
-  nv30_resource_resolve(nv30, blit_info);
+  if (nv30->screen->eng3d->oclass >= NV40_3D_CLASS)
+ nv40_resource_resolve(nv30, blit_info);
+  else
+ nv30_resource_resolve(nv30, blit_info);
   return;
}
 
-- 
2.4.3

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


[Mesa-dev] [PATCH mesa 1/3] nv30: Fix max width / height checks in nv30 sifm code

2015-09-07 Thread Hans de Goede
The sifm object has a limit of 1024x1024 for its input size and 2048x2048
for its output. The code checking this was trying to be clever resulting
in it seeing a surface of e.g 1024x256 being outside of the input size
limit.

This commit fixes this.

Signed-off-by: Hans de Goede 
---
 src/gallium/drivers/nouveau/nv30/nv30_transfer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_transfer.c 
b/src/gallium/drivers/nouveau/nv30/nv30_transfer.c
index 214da65..2452071 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_transfer.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_transfer.c
@@ -371,7 +371,7 @@ nv30_transfer_rect_blit(XFER_ARGS)
 static bool
 nv30_transfer_sifm(XFER_ARGS)
 {
-   if (!src->pitch || (src->w | src->h) > 1024 || src->w < 2 || src->h < 2)
+   if (!src->pitch || src->w > 1024 || src->h > 1024 || src->w < 2 || src->h < 
2)
   return false;
 
if (src->d > 1 || dst->d > 1)
@@ -381,7 +381,7 @@ nv30_transfer_sifm(XFER_ARGS)
   return false;
 
if (!dst->pitch) {
-  if ((dst->w | dst->h) > 2048 || dst->w < 2 || dst->h < 2)
+  if (dst->w > 2048 || dst->h > 2048 || dst->w < 2 || dst->h < 2)
  return false;
} else {
   if (dst->domain != NOUVEAU_BO_VRAM)
-- 
2.4.3

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


[Mesa-dev] [PATCH mesa 3/3] nv30: Disable msaa for now because it causes lockups

2015-09-07 Thread Hans de Goede
msaa use on nv30 may trigger a (mesa?) bug where dmesg says:
 [ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
 [ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list
 [ 1197.850654] nouveau E[soffice.bin[3785]] validate: -12
 [ 1201.766955] nouveau E[soffice.bin[3785]] fail ttm_validate
 [ 1201.766961] nouveau E[soffice.bin[3785]] validating bo list
 [ 1201.766968] nouveau E[soffice.bin[3785]] validate: -12

After which the program using the msaa visual freezes, and eventually
the entire system freezes. Disable msaa until this is fixed.

This happens on both nv3x and nv4x cards.

Signed-off-by: Hans de Goede 
---
 src/gallium/drivers/nouveau/nv30/nv30_screen.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 7aad26b..7a16e72 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -319,8 +319,25 @@ nv30_screen_is_format_supported(struct pipe_screen 
*pscreen,
 unsigned sample_count,
 unsigned bindings)
 {
+   /*
+* msaa use on nv30 may trigger a (mesa?) bug where dmesg says:
+* [ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
+* [ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list
+* [ 1197.850654] nouveau E[soffice.bin[3785]] validate: -12
+* [ 1201.766955] nouveau E[soffice.bin[3785]] fail ttm_validate
+* [ 1201.766961] nouveau E[soffice.bin[3785]] validating bo list
+* [ 1201.766968] nouveau E[soffice.bin[3785]] validate: -12
+*
+* After which the program using the msaa visual freezes, and eventually
+* the entire system freezes. Disable msaa until this is fixed.
+*/
+#if 1
+   if (sample_count > 0)
+#else
if (sample_count > 4)
+#endif
   return false;
+
if (!(0x0017 & (1 << sample_count)))
   return false;
 
-- 
2.4.3

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


Re: [Mesa-dev] [PATCH mesa 1/3] nv30: Fix max width / height checks in nv30 sifm code

2015-09-07 Thread Ilia Mirkin
Yeah, I noticed this was odd too when looking over the code earlier.
Glad you picked up on that as well.

Reviewed-by: Ilia Mirkin 
Cc: "10.6 11.0" 

On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede  wrote:
> The sifm object has a limit of 1024x1024 for its input size and 2048x2048
> for its output. The code checking this was trying to be clever resulting
> in it seeing a surface of e.g 1024x256 being outside of the input size
> limit.
>
> This commit fixes this.
>
> Signed-off-by: Hans de Goede 
> ---
>  src/gallium/drivers/nouveau/nv30/nv30_transfer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_transfer.c 
> b/src/gallium/drivers/nouveau/nv30/nv30_transfer.c
> index 214da65..2452071 100644
> --- a/src/gallium/drivers/nouveau/nv30/nv30_transfer.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_transfer.c
> @@ -371,7 +371,7 @@ nv30_transfer_rect_blit(XFER_ARGS)
>  static bool
>  nv30_transfer_sifm(XFER_ARGS)
>  {
> -   if (!src->pitch || (src->w | src->h) > 1024 || src->w < 2 || src->h < 2)
> +   if (!src->pitch || src->w > 1024 || src->h > 1024 || src->w < 2 || src->h 
> < 2)
>return false;
>
> if (src->d > 1 || dst->d > 1)
> @@ -381,7 +381,7 @@ nv30_transfer_sifm(XFER_ARGS)
>return false;
>
> if (!dst->pitch) {
> -  if ((dst->w | dst->h) > 2048 || dst->w < 2 || dst->h < 2)
> +  if (dst->w > 2048 || dst->h > 2048 || dst->w < 2 || dst->h < 2)
>   return false;
> } else {
>if (dst->domain != NOUVEAU_BO_VRAM)
> --
> 2.4.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH mesa 2/3] nv30: Fix color resolving for nv3x cards

2015-09-07 Thread Ilia Mirkin
May I ask why you're doing 512x512 instead of 1024x1024? These are
already scaled up coordinates, so 1024x1024 should work no? Or is it
because of the seams on the edges? Do those not also appear with
512x512 or does it sample outside of the box?

Separately, why not use this approach on nv40 as well? I can't imagine
the blitter would be faster... does this result in lower quality?

On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede  wrote:
> We do not have a generic blitter on nv3x cards, so we must use the
> sifm object for color resolving.
>
> This commit divides the sources and dest surfaces in to tiles which
> match the constraints of the sifm object, so that color resolving
> will work properly on nv3x cards.
>
> Signed-off-by: Hans de Goede 
> ---
>  src/gallium/drivers/nouveau/nv30/nv30_miptree.c | 55 
> -
>  1 file changed, 54 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c 
> b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
> index 76bb8b8..c240030 100644
> --- a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
> @@ -149,6 +149,56 @@ static void
>  nv30_resource_resolve(struct nv30_context *nv30,
>const struct pipe_blit_info *info)
>  {
> +   struct nv30_miptree *src_mt = nv30_miptree(info->src.resource);
> +   struct nv30_rect src, dst;
> +   unsigned x, x0, x1, y, y1, w, h;
> +
> +   define_rect(info->src.resource, 0, info->src.box.z, info->src.box.x,
> +  info->src.box.y, info->src.box.width, info->src.box.height, &src);
> +   define_rect(info->dst.resource, 0, info->dst.box.z, info->dst.box.x,
> +  info->dst.box.y, info->dst.box.width, info->dst.box.height, &dst);
> +
> +   x0 = src.x0;
> +   x1 = src.x1;
> +   y1 = src.y1;
> +
> +   /* On nv3x we must use sifm which is restricted to 512x512 tiles */
> +   for (y = src.y0; y < y1; y += h) {
> +  h = y1 - y;
> +  if (h > 512)
> + h = 512;
> +
> +  src.y0 = 0;
> +  src.y1 = h;
> +  src.h = h;
> +
> +  dst.y1 = dst.y0 + (h >> src_mt->ms_y);
> +  dst.h = h >> src_mt->ms_y;
> +
> +  for (x = x0; x < x1; x += w) {
> + w = x1 - x;
> + if (w > 512)
> +w = 512;
> +
> + src.offset = y * src.pitch + x * src.cpp;
> + src.x0 = 0;
> + src.x1 = w;
> + src.w = w;
> +
> + dst.offset = (y >> src_mt->ms_y) * dst.pitch +
> +  (x >> src_mt->ms_x) * dst.cpp;
> + dst.x1 = dst.x0 + (w >> src_mt->ms_x);
> + dst.w = w >> src_mt->ms_x;
> +
> + nv30_transfer_rect(nv30, BILINEAR, &src, &dst);
> +  }
> +   }
> +}
> +
> +static void
> +nv40_resource_resolve(struct nv30_context *nv30,
> +  const struct pipe_blit_info *info)
> +{
> struct nv30_rect src, dst;
>
> define_rect(info->src.resource, 0, info->src.box.z, info->src.box.x,
> @@ -170,7 +220,10 @@ nv30_blit(struct pipe_context *pipe,
> info.dst.resource->nr_samples <= 1 &&
> !util_format_is_depth_or_stencil(info.src.resource->format) &&
> !util_format_is_pure_integer(info.src.resource->format)) {
> -  nv30_resource_resolve(nv30, blit_info);
> +  if (nv30->screen->eng3d->oclass >= NV40_3D_CLASS)
> + nv40_resource_resolve(nv30, blit_info);
> +  else
> + nv30_resource_resolve(nv30, blit_info);
>return;
> }
>
> --
> 2.4.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH mesa 3/3] nv30: Disable msaa for now because it causes lockups

2015-09-07 Thread Ilia Mirkin
On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede  wrote:
> msaa use on nv30 may trigger a (mesa?) bug where dmesg says:
>  [ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
>  [ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list
>  [ 1197.850654] nouveau E[soffice.bin[3785]] validate: -12
>  [ 1201.766955] nouveau E[soffice.bin[3785]] fail ttm_validate
>  [ 1201.766961] nouveau E[soffice.bin[3785]] validating bo list
>  [ 1201.766968] nouveau E[soffice.bin[3785]] validate: -12
>
> After which the program using the msaa visual freezes, and eventually
> the entire system freezes. Disable msaa until this is fixed.
>
> This happens on both nv3x and nv4x cards.

Ugh. This is aka "you ran out of vram, goodbye". We don't really
handle that case extremely well. I feel really bad doing this :( The
issue is anachronistic applications like soffice that don't keep with
the limitations of GPUs of the days of yore. So we end up penalizing
people who do use applications of the day.

But the practical issue is that people do upgrade, and people do run
these applications, and so it makes sense to keep it off by default.
Could I convince you to use debug_get_int_option (or something along
those lines, forget the function name) to still allow an env var
override? Like NV30_MAX_MSAA or something (and clamp it to 4 so people
don't get ideas).

>
> Signed-off-by: Hans de Goede 
> ---
>  src/gallium/drivers/nouveau/nv30/nv30_screen.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
> b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> index 7aad26b..7a16e72 100644
> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> @@ -319,8 +319,25 @@ nv30_screen_is_format_supported(struct pipe_screen 
> *pscreen,
>  unsigned sample_count,
>  unsigned bindings)
>  {
> +   /*
> +* msaa use on nv30 may trigger a (mesa?) bug where dmesg says:
> +* [ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
> +* [ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list
> +* [ 1197.850654] nouveau E[soffice.bin[3785]] validate: -12
> +* [ 1201.766955] nouveau E[soffice.bin[3785]] fail ttm_validate
> +* [ 1201.766961] nouveau E[soffice.bin[3785]] validating bo list
> +* [ 1201.766968] nouveau E[soffice.bin[3785]] validate: -12
> +*
> +* After which the program using the msaa visual freezes, and eventually
> +* the entire system freezes. Disable msaa until this is fixed.
> +*/
> +#if 1
> +   if (sample_count > 0)
> +#else
> if (sample_count > 4)
> +#endif
>return false;
> +
> if (!(0x0017 & (1 << sample_count)))
>return false;
>
> --
> 2.4.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH V3 1/6] glsl: order indices for samplers inside a struct array

2015-09-07 Thread Timothy Arceri
On Mon, 2015-09-07 at 11:24 -0700, Jason Ekstrand wrote:
> On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri 
> wrote:
> > This allows the correct offset to be easily calculated for indirect
> > indexing when a struct array contains multiple samplers, or any crazy
> > nesting.
> > 
> > The indices for the folling struct will now look like this:
> > Sampler index: 0 Name: s[0].tex
> > Sampler index: 1 Name: s[1].tex
> > Sampler index: 2 Name: s[0].si.tex
> > Sampler index: 3 Name: s[1].si.tex
> > Sampler index: 4 Name: s[0].si.tex2
> > Sampler index: 5 Name: s[1].si.tex2
> > 
> > Before this change it looked like this:
> > Sampler index: 0 Name: s[0].tex
> > Sampler index: 3 Name: s[1].tex
> > Sampler index: 1 Name: s[0].si.tex
> > Sampler index: 4 Name: s[1].si.tex
> > Sampler index: 2 Name: s[0].si.tex2
> > Sampler index: 5 Name: s[1].si.tex2
> > 
> > struct S_inner {
> >sampler2D tex;
> >sampler2D tex2;
> > };
> > 
> > struct S {
> >sampler2D tex;
> >S_inner si;
> > };
> > 
> > uniform S s[2];
> > 
> > V2: rename struct array counter to have better name
> > ---
> >  src/glsl/link_uniforms.cpp | 112 ++--
> > -
> >  src/glsl/linker.h  |   4 +-
> >  2 files changed, 98 insertions(+), 18 deletions(-)
> > 
> > diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
> > index 254086d..5402c99 100644
> > --- a/src/glsl/link_uniforms.cpp
> > +++ b/src/glsl/link_uniforms.cpp
> > @@ -28,6 +28,7 @@
> >  #include "glsl_symbol_table.h"
> >  #include "program/hash_table.h"
> >  #include "program.h"
> > +#include "util/hash_table.h"
> > 
> >  /**
> >   * \file link_uniforms.cpp
> > @@ -63,14 +64,17 @@ program_resource_visitor::process(const glsl_type
> > *type, const char *name)
> > assert(type->without_array()->is_record()
> >|| type->without_array()->is_interface());
> > 
> > +   unsigned record_array_count = 1;
> > char *name_copy = ralloc_strdup(NULL, name);
> > -   recursion(type, &name_copy, strlen(name), false, NULL, false);
> > +   recursion(type, &name_copy, strlen(name), false, NULL, false,
> > + record_array_count);
> > ralloc_free(name_copy);
> >  }
> > 
> >  void
> >  program_resource_visitor::process(ir_variable *var)
> >  {
> > +   unsigned record_array_count = 1;
> > const glsl_type *t = var->type;
> > const bool row_major =
> >var->data.matrix_layout == GLSL_MATRIX_LAYOUT_ROW_MAJOR;
> > @@ -111,7 +115,8 @@ program_resource_visitor::process(ir_variable *var)
> >* lowering is only applied to non-uniform interface blocks, so
> > we
> >* can safely pass false for row_major.
> >*/
> > - recursion(var->type, &name, new_length, row_major, NULL, false);
> > + recursion(var->type, &name, new_length, row_major, NULL, false,
> > +   record_array_count);
> >}
> >ralloc_free(name);
> > } else if (var->data.from_named_ifc_block_nonarray) {
> > @@ -135,19 +140,23 @@ program_resource_visitor::process(ir_variable *var)
> > * is only applied to non-uniform interface blocks, so we can
> > safely
> > * pass false for row_major.
> > */
> > -  recursion(var->type, &name, strlen(name), row_major, NULL, false);
> > +  recursion(var->type, &name, strlen(name), row_major, NULL, false,
> > +record_array_count);
> >ralloc_free(name);
> > } else if (t->without_array()->is_record()) {
> >char *name = ralloc_strdup(NULL, var->name);
> > -  recursion(var->type, &name, strlen(name), row_major, NULL, false);
> > +  recursion(var->type, &name, strlen(name), row_major, NULL, false,
> > +record_array_count);
> >ralloc_free(name);
> > } else if (t->is_interface()) {
> >char *name = ralloc_strdup(NULL, var->type->name);
> > -  recursion(var->type, &name, strlen(name), row_major, NULL, false);
> > +  recursion(var->type, &name, strlen(name), row_major, NULL, false,
> > +record_array_count);
> >ralloc_free(name);
> > } else if (t->is_array() && t->fields.array->is_interface()) {
> >char *name = ralloc_strdup(NULL, var->type->fields.array->name);
> > -  recursion(var->type, &name, strlen(name), row_major, NULL, false);
> > +  recursion(var->type, &name, strlen(name), row_major, NULL, false,
> > +record_array_count);
> >ralloc_free(name);
> > } else {
> >this->visit_field(t, var->name, row_major, NULL, false);
> > @@ -158,7 +167,8 @@ void
> >  program_resource_visitor::recursion(const glsl_type *t, char **name,
> >  size_t name_length, bool row_major,
> >  const glsl_type *record_type,
> > -bool last_field)
> > +bool last_field,
> > +unsigned record_array_count)

[Mesa-dev] [PATCH] r600: don't use shader key without verifying shader type

2015-09-07 Thread Dave Airlie
From: Dave Airlie 

Since 7a32652231f96eac14c4bfce02afe77b4132fb77
r600: Turn 'r600_shader_key' struct into union

we were accessing key fields that might be aliased in the union
with other fields, so we should check what shader type we are
compiling for before using key values from it.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_shader.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 666e021..c027848 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -143,7 +143,7 @@ int r600_pipe_shader_create(struct pipe_context *ctx,
bool dump = r600_can_dump_shader(&rctx->screen->b, sel->tokens);
unsigned use_sb = !(rctx->screen->b.debug_flags & DBG_NO_SB);
unsigned sb_disasm = use_sb || (rctx->screen->b.debug_flags & 
DBG_SB_DISASM);
-   unsigned export_shader = key.vs.as_es;
+   unsigned export_shader;
 
shader->shader.bc.isa = rctx->isa;
 
@@ -224,6 +224,7 @@ int r600_pipe_shader_create(struct pipe_context *ctx,
}
break;
case TGSI_PROCESSOR_VERTEX:
+   export_shader = key.vs.as_es;
if (rctx->b.chip_class >= EVERGREEN) {
if (export_shader)
evergreen_update_es_state(ctx, shader);
@@ -1901,8 +1902,10 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
ctx.shader = shader;
ctx.native_integers = true;
 
-   shader->vs_as_gs_a = key.vs.as_gs_a;
-   shader->vs_as_es = key.vs.as_es;
+   if (ctx.type == TGSI_PROCESSOR_VERTEX) {
+   shader->vs_as_gs_a = key.vs.as_gs_a;
+   shader->vs_as_es = key.vs.as_es;
+   }
 
r600_bytecode_init(ctx.bc, rscreen->b.chip_class, rscreen->b.family,
   rscreen->has_compressed_msaa_texturing);
@@ -1918,9 +1921,9 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
shader->processor_type = ctx.type;
ctx.bc->type = shader->processor_type;
 
-   ring_outputs = key.vs.as_es || (ctx.type == TGSI_PROCESSOR_GEOMETRY);
+   ring_outputs = shader->vs_as_es || ctx.type == TGSI_PROCESSOR_GEOMETRY);
 
-   if (key.vs.as_es) {
+   if (shader->vs.as_es) {
ctx.gs_for_vs = &rctx->gs_shader->current->shader;
} else {
ctx.gs_for_vs = NULL;
@@ -1941,7 +1944,8 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
shader->nr_ps_color_exports = 0;
shader->nr_ps_max_color_exports = 0;
 
-   shader->two_side = key.ps.color_two_side;
+   if (ctx.type == TGSI_PROCESSOR_FRAGMENT)
+   shader->two_side = key.ps.color_two_side;
 
/* register allocations */
/* Values [0,127] correspond to GPR[0..127].
@@ -2327,7 +2331,7 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
convert_edgeflag_to_int(&ctx);
 
if (ring_outputs) {
-   if (key.vs.as_es) {
+   if (shader->vs_as_es) {
ctx.gs_export_gpr_tregs[0] = r600_get_temp(&ctx);
ctx.gs_export_gpr_tregs[1] = -1;
ctx.gs_export_gpr_tregs[2] = -1;
-- 
2.4.3

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


Re: [Mesa-dev] [PATCH] r600: don't use shader key without verifying shader type

2015-09-07 Thread Dave Airlie
On 8 September 2015 at 08:38, Dave Airlie  wrote:
> From: Dave Airlie 
>
> Since 7a32652231f96eac14c4bfce02afe77b4132fb77
> r600: Turn 'r600_shader_key' struct into union
>
> we were accessing key fields that might be aliased in the union
> with other fields, so we should check what shader type we are
> compiling for before using key values from it.
>

This version contains two little bugs extra brace got left over and a
. should be a _

Doh, but otherwise it'll be the version that compiles I push :)

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


Re: [Mesa-dev] [PATCH] r600: don't use shader key without verifying shader type

2015-09-07 Thread Dave Airlie
On 8 September 2015 at 08:46, Dave Airlie  wrote:
> On 8 September 2015 at 08:38, Dave Airlie  wrote:
>> From: Dave Airlie 
>>
>> Since 7a32652231f96eac14c4bfce02afe77b4132fb77
>> r600: Turn 'r600_shader_key' struct into union
>>
>> we were accessing key fields that might be aliased in the union
>> with other fields, so we should check what shader type we are
>> compiling for before using key values from it.
>>
>
> This version contains two little bugs extra brace got left over and a
> . should be a _
>
> Doh, but otherwise it'll be the version that compiles I push :)
>

Okay this doesn't work for more reasons, I'm going to wake up a bit,
and maybe try again!

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


[Mesa-dev] [PATCH] r600: don't use shader key without verifying shader type (v2)

2015-09-07 Thread Dave Airlie
From: Dave Airlie 

Since 7a32652231f96eac14c4bfce02afe77b4132fb77
r600: Turn 'r600_shader_key' struct into union

we were accessing key fields that might be aliased in the union
with other fields, so we should check what shader type we are
compiling for before using key values from it.

v1.1: make it compile
v2: have caffiene, make it work - we don't set type
until later, so don't reference it until we've set it.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_shader.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 78904da..f2c9e16 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -143,7 +143,7 @@ int r600_pipe_shader_create(struct pipe_context *ctx,
bool dump = r600_can_dump_shader(&rctx->screen->b, sel->tokens);
unsigned use_sb = !(rctx->screen->b.debug_flags & DBG_NO_SB);
unsigned sb_disasm = use_sb || (rctx->screen->b.debug_flags & 
DBG_SB_DISASM);
-   unsigned export_shader = key.vs.as_es;
+   unsigned export_shader;
 
shader->shader.bc.isa = rctx->isa;
 
@@ -224,6 +224,7 @@ int r600_pipe_shader_create(struct pipe_context *ctx,
}
break;
case TGSI_PROCESSOR_VERTEX:
+   export_shader = key.vs.as_es;
if (rctx->b.chip_class >= EVERGREEN) {
if (export_shader)
evergreen_update_es_state(ctx, shader);
@@ -1901,8 +1902,6 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
ctx.shader = shader;
ctx.native_integers = true;
 
-   shader->vs_as_gs_a = key.vs.as_gs_a;
-   shader->vs_as_es = key.vs.as_es;
 
r600_bytecode_init(ctx.bc, rscreen->b.chip_class, rscreen->b.family,
   rscreen->has_compressed_msaa_texturing);
@@ -1918,9 +1917,14 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
shader->processor_type = ctx.type;
ctx.bc->type = shader->processor_type;
 
-   ring_outputs = key.vs.as_es || (ctx.type == TGSI_PROCESSOR_GEOMETRY);
+   if (ctx.type == TGSI_PROCESSOR_VERTEX) {
+   shader->vs_as_gs_a = key.vs.as_gs_a;
+   shader->vs_as_es = key.vs.as_es;
+   }
+
+   ring_outputs = shader->vs_as_es || ctx.type == TGSI_PROCESSOR_GEOMETRY;
 
-   if (key.vs.as_es) {
+   if (shader->vs_as_es) {
ctx.gs_for_vs = &rctx->gs_shader->current->shader;
} else {
ctx.gs_for_vs = NULL;
@@ -1941,7 +1945,8 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
shader->nr_ps_color_exports = 0;
shader->nr_ps_max_color_exports = 0;
 
-   shader->two_side = key.ps.color_two_side;
+   if (ctx.type == TGSI_PROCESSOR_FRAGMENT)
+   shader->two_side = key.ps.color_two_side;
 
/* register allocations */
/* Values [0,127] correspond to GPR[0..127].
@@ -2327,7 +2332,7 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
convert_edgeflag_to_int(&ctx);
 
if (ring_outputs) {
-   if (key.vs.as_es) {
+   if (shader->vs_as_es) {
ctx.gs_export_gpr_tregs[0] = r600_get_temp(&ctx);
ctx.gs_export_gpr_tregs[1] = -1;
ctx.gs_export_gpr_tregs[2] = -1;
-- 
2.4.3

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


[Mesa-dev] [PATCH v3 1/4] nouveau: split nouveau_vp3_bsp in begin/next/end

2015-09-07 Thread Julien Isorce
It allows to call nouveau_vp3_bsp_next multiple times
between one begin/end.

It is required to support st/va.

https://bugs.freedesktop.org/show_bug.cgi?id=89969

Signed-off-by: Julien Isorce 
---
 src/gallium/drivers/nouveau/nouveau_vp3_video.h| 16 +++-
 .../drivers/nouveau/nouveau_vp3_video_bsp.c| 96 ++
 src/gallium/drivers/nouveau/nv50/nv98_video_bsp.c  |  5 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c  |  5 +-
 4 files changed, 78 insertions(+), 44 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.h 
b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
index 33e3bef..70d8501 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
@@ -114,6 +114,10 @@ struct nouveau_vp3_decoder {
unsigned fence_seq, fw_sizes, last_frame_num, tmp_stride, ref_stride;
 
unsigned bsp_idx, vp_idx, ppp_idx;
+
+   /* End of the bsp bo where new data should be appended between one begin/end
+* frame. */
+   char *bsp_ptr;
 };
 
 struct comm {
@@ -208,11 +212,15 @@ nouveau_vp3_load_firmware(struct nouveau_vp3_decoder *dec,
   enum pipe_video_profile profile,
   unsigned chipset);
 
+void
+nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec);
+
+void
+nouveau_vp3_bsp_next(struct nouveau_vp3_decoder *dec, unsigned num_buffers,
+ const void *const *data, const unsigned *num_bytes);
+
 uint32_t
-nouveau_vp3_bsp(struct nouveau_vp3_decoder *dec,  union pipe_desc desc,
-struct nouveau_vp3_video_buffer *target,
-unsigned comm_seq, unsigned num_buffers,
-const void *const *data, const unsigned *num_bytes);
+nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec, union pipe_desc desc);
 
 void
 nouveau_vp3_vp_caps(struct nouveau_vp3_decoder *dec, union pipe_desc desc,
diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c 
b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
index 6d968c1..b7045c9 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
@@ -230,20 +230,61 @@ nouveau_vp3_fill_picparm_h264_bsp(struct 
nouveau_vp3_decoder *dec,
return caps | 3;
 }
 
+void
+nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec)
+{
+   uint32_t comm_seq = dec->fence_seq;
+   struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq % 
NOUVEAU_VP3_VIDEO_QDEPTH];
+   struct strparm_bsp *str_bsp = NULL;
+
+   dec->bsp_ptr = bsp_bo->map;
+
+   dec->bsp_ptr += 0x100;
+
+   str_bsp = (struct strparm_bsp *)dec->bsp_ptr;
+   memset(str_bsp, 0, 0x80);
+   str_bsp->w0[0] = 16;
+   str_bsp->w1[0] = 0x1;
+   dec->bsp_ptr += 0x100;
+   /* Reserved for picparm_vp */
+   dec->bsp_ptr += 0x300;
+   /* Reserved for comm */
+   #if !NOUVEAU_VP3_DEBUG_FENCE
+   memset(dec->bsp_ptr, 0, 0x200);
+   #endif
+   dec->bsp_ptr += 0x200;
+}
+
+void
+nouveau_vp3_bsp_next(struct nouveau_vp3_decoder *dec, unsigned num_buffers,
+ const void *const *data, const unsigned *num_bytes)
+{
+   uint32_t comm_seq = dec->fence_seq;
+   struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq % 
NOUVEAU_VP3_VIDEO_QDEPTH];
+   char *bsp_origin = bsp_bo->map;
+   struct strparm_bsp *str_bsp = NULL;
+   int i = 0;
+
+   bsp_origin += 0x100;
+   str_bsp = (struct strparm_bsp *)bsp_origin;
+
+   for (i = 0; i < num_buffers; ++i) {
+  memcpy(dec->bsp_ptr, data[i], num_bytes[i]);
+  dec->bsp_ptr += num_bytes[i];
+  str_bsp->w0[0] += num_bytes[i];
+   }
+}
+
 uint32_t
-nouveau_vp3_bsp(struct nouveau_vp3_decoder *dec,  union pipe_desc desc,
-struct nouveau_vp3_video_buffer *target,
-unsigned comm_seq, unsigned num_buffers,
-const void *const *data, const unsigned *num_bytes)
+nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec, union pipe_desc desc)
 {
-   enum pipe_video_format codec = u_reduce_video_profile(dec->base.profile);
+   uint32_t comm_seq = dec->fence_seq;
struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq % 
NOUVEAU_VP3_VIDEO_QDEPTH];
-   char *bsp;
-   uint32_t endmarker, caps;
-   struct strparm_bsp *str_bsp;
-   int i;
+   enum pipe_video_format codec = u_reduce_video_profile(dec->base.profile);
+   uint32_t caps = 0;
+   uint32_t endmarker = 0;
+   char *bsp = bsp_bo->map;
 
-   bsp = bsp_bo->map;
/*
 * 0x000..0x100: picparm_bsp
 * 0x200..0x500: picparm_vp
@@ -277,34 +318,17 @@ nouveau_vp3_bsp(struct nouveau_vp3_decoder *dec,  union 
pipe_desc desc,
caps |= 1 << 17; // enable watchdog
caps |= 0 << 18; // do not report error to VP, so it can continue decoding 
what we have
caps |= 0 << 19; // if enabled, use crypto crap?
-   bsp += 0x100;
-
-   str_bsp = (struct strparm_bsp *)bsp;
-   memset(str_bsp, 0, 0x80);
-   str_bsp->w0[0] = 16;
-   str_bsp->w1[0] = 0x1;
-   bsp += 0x100;
-   /* Reserved for picparm_vp */
-   bsp += 0x300;
-   /* Reserved for comm */
-#if !NOUV

[Mesa-dev] [PATCH v3 0/4] nouveau: add support for vaapi

2015-09-07 Thread Julien Isorce
Currently nouveau does not support chunk decoding
which is required to support st/va.

The low level code is already there since it supports
vpau. But it is missing the possibility to feed
the nouveau_bo buffers gradually.
Resizing is already there too. But it also requires
to preserve the content after resizing.

The following patches refactor nouveau_vp3_bsp
and nvc0_decoder_bsp in order to implement
pipe_video_codec::begin_frame/decode_bitstream/end_frame.
So that decode_bitstream can be call multiple times
between each begin/end.

There is nothing really new in these patches.
All the low level code relative to nouveau was already there.
The patches are moving code in order to call nouveau_vp3_bsp and
nvc0_decoder_bsp multiple times between each begin/end frame. 

I made sure that vdpau was still working. Actually it was more than that,
without vdpau I think I would not have been able to do this refactoring.
I also compared that for one begin/end frame the nouveau_bo buffer contains
the same data for vdpau and vaapi. I dumped them for the same stream and
for several seconds. There were all the same.

Regression tests:
I made sure mpeg2, mpeg4, h264 and vc1 are still working with vdpau.

Issues:
I can observe some visual artificats with vaapi on mpeg4 and h264.
It looks 90% ok, color too. But you can feel that something is wrong.
Though it looks good on mpeg2 and vc1. And when dumping the full nouveau_bo
they are the same as those dumped while using vdpau.
I wonder if it could be a bug in st/va itself.

TODO: apply same logic for nv98 but I do not have the
material to test it.

https://bugs.freedesktop.org/show_bug.cgi?id=89969

Julien Isorce (4):
  nouveau: split nouveau_vp3_bsp in begin/next/end
  nvc0: add support for st/va
  nouveau: fix chunk decoding by updating number of slices
  build: enable st/va with nouveau driver

 src/gallium/drivers/nouveau/nouveau_vp3_video.h|  22 +++-
 .../drivers/nouveau/nouveau_vp3_video_bsp.c| 106 ++--
 src/gallium/drivers/nouveau/nv50/nv98_video_bsp.c  |   5 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_video.c  |  44 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_video.h  |  18 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c  | 141 ++---
 src/gallium/targets/va/Makefile.am |   2 +
 7 files changed, 240 insertions(+), 98 deletions(-)

-- 
1.9.1

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


[Mesa-dev] [PATCH v3 4/4] build: enable st/va with nouveau driver

2015-09-07 Thread Julien Isorce
vainfo fails in vaDriverInit because "dd_create_screen"
does not reach strcmp(driver_name, "nouveau") code.
Indeed when compiling the va target.c, the macro GALLIUM_NOUVEAU
is not defined.
This patch define the macro the same it is done for dri and
vdpau targets.

Tested with:
./autogen.sh --enable-glx --enable-gles2 --enable-egl --enable-vdpau 
--enable-glx-tls=yes --enable-va
--with-gallium-drivers=swrast,nouveau --with-dri-drivers=swrast,nouveau 
--with-egl-platforms=x11

LIBVA_DRIVER_NAME=gallium vainfo
Output:
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileMPEG4Simple: VAEntrypointVLD
  VAProfileMPEG4AdvancedSimple: VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264Baseline   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointVLD

Signed-off-by: Julien Isorce 
---
 src/gallium/targets/va/Makefile.am | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/targets/va/Makefile.am 
b/src/gallium/targets/va/Makefile.am
index 9613f04..c8bb6fe 100644
--- a/src/gallium/targets/va/Makefile.am
+++ b/src/gallium/targets/va/Makefile.am
@@ -42,6 +42,8 @@ TARGET_DRIVERS =
 TARGET_CPPFLAGS =
 TARGET_LIB_DEPS = $(top_builddir)/src/loader/libloader.la
 
+include $(top_srcdir)/src/gallium/drivers/nouveau/Automake.inc
+
 include $(top_srcdir)/src/gallium/drivers/r600/Automake.inc
 include $(top_srcdir)/src/gallium/drivers/radeonsi/Automake.inc
 
-- 
1.9.1

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


[Mesa-dev] [PATCH v3 2/4] nvc0: add support for st/va

2015-09-07 Thread Julien Isorce
- split nvc0_decoder_bsp in begin/next/end
- preserve content buffer when calling nvc0_decoder_bsp_next
- implement pipe_video_codec::begin_frame/end_frame

https://bugs.freedesktop.org/show_bug.cgi?id=89969

Signed-off-by: Julien Isorce 
---
 src/gallium/drivers/nouveau/nouveau_vp3_video.h|   3 +
 .../drivers/nouveau/nouveau_vp3_video_bsp.c|   2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_video.c  |  44 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_video.h  |  18 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c  | 138 ++---
 5 files changed, 150 insertions(+), 55 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.h 
b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
index 70d8501..43b9556 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
@@ -118,6 +118,9 @@ struct nouveau_vp3_decoder {
/* End of the bsp bo where new data should be appended between one begin/end
 * frame. */
char *bsp_ptr;
+
+   /* Total data appended so far after last begin frame. */
+   unsigned bsp_size;
 };
 
 struct comm {
diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c 
b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
index b7045c9..c1d70ea 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
@@ -238,6 +238,7 @@ nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec)
struct strparm_bsp *str_bsp = NULL;
 
dec->bsp_ptr = bsp_bo->map;
+   dec->bsp_size = NOUVEAU_VP3_BSP_RESERVED_SIZE;
 
dec->bsp_ptr += 0x100;
 
@@ -329,6 +330,7 @@ nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec, union 
pipe_desc desc)
*(uint32_t *)dec->bsp_ptr = 0x;
 
dec->bsp_ptr = NULL;
+   dec->bsp_size = 0;
 
return caps;
 }
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
index 48ffac1..7c085e4 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_video.c
@@ -26,6 +26,24 @@
 #include "util/u_format.h"
 
 static void
+nvc0_decoder_begin_frame(struct pipe_video_codec *decoder,
+ struct pipe_video_buffer *target,
+ struct pipe_picture_desc *picture)
+{
+   struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder *)decoder;
+   uint32_t comm_seq = ++dec->fence_seq;
+   unsigned ret = 0;
+
+   assert(dec);
+   assert(target);
+   assert(target->base.buffer_format == PIPE_FORMAT_NV12);
+
+   ret = nvc0_decoder_bsp_begin(dec, comm_seq);
+
+   assert(ret == 2);
+}
+
+static void
 nvc0_decoder_decode_bitstream(struct pipe_video_codec *decoder,
   struct pipe_video_buffer *video_target,
   struct pipe_picture_desc *picture,
@@ -34,8 +52,24 @@ nvc0_decoder_decode_bitstream(struct pipe_video_codec 
*decoder,
   const unsigned *num_bytes)
 {
struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder *)decoder;
+   uint32_t comm_seq = dec->fence_seq;
+   unsigned ret = 0;
+
+   assert(decoder);
+
+   ret = nvc0_decoder_bsp_next(dec, comm_seq, num_buffers, data, num_bytes);
+
+   assert(ret == 2);
+}
+
+static void
+nvc0_decoder_end_frame(struct pipe_video_codec *decoder,
+   struct pipe_video_buffer *video_target,
+   struct pipe_picture_desc *picture)
+{
+   struct nouveau_vp3_decoder *dec = (struct nouveau_vp3_decoder *)decoder;
struct nouveau_vp3_video_buffer *target = (struct nouveau_vp3_video_buffer 
*)video_target;
-   uint32_t comm_seq = ++dec->fence_seq;
+   uint32_t comm_seq = dec->fence_seq;
union pipe_desc desc;
 
unsigned vp_caps, is_ref, ret;
@@ -43,11 +77,7 @@ nvc0_decoder_decode_bitstream(struct pipe_video_codec 
*decoder,
 
desc.base = picture;
 
-   assert(target->base.buffer_format == PIPE_FORMAT_NV12);
-
-   ret = nvc0_decoder_bsp(dec, desc, target, comm_seq,
-  num_buffers, data, num_bytes,
-  &vp_caps, &is_ref, refs);
+   ret = nvc0_decoder_bsp_end(dec, desc, target, comm_seq, &vp_caps, &is_ref, 
refs);
 
/* did we decode bitstream correctly? */
assert(ret == 2);
@@ -164,7 +194,9 @@ nvc0_create_decoder(struct pipe_context *context,
PUSH_DATA (push[2], dec->ppp->handle);
 
dec->base.context = context;
+   dec->base.begin_frame = nvc0_decoder_begin_frame;
dec->base.decode_bitstream = nvc0_decoder_decode_bitstream;
+   dec->base.end_frame = nvc0_decoder_end_frame;
 
for (i = 0; i < NOUVEAU_VP3_VIDEO_QDEPTH && !ret; ++i)
   ret = nouveau_bo_new(screen->device, NOUVEAU_BO_VRAM,
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_video.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_video.h
index 9ee0280..cf3c942 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_video.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_video.h
@@ -30,12 +

[Mesa-dev] [PATCH v3 0/4] nouveau: add support for vaapi

2015-09-07 Thread Julien Isorce
v3:
Indent to 3 spaces.
Move "unsigned bsp_size" and unsigned int nb_slices" in
commits that use it.

v2:
Squash some commits as requested.

Currently nouveau does not support chunk decoding
which is required to support st/va.

The low level code is already there since it supports
vpau. But it is missing the possibility to feed
the nouveau_bo buffers gradually.
Resizing is already there too. But it also requires
to preserve the content after resizing.

The following patches refactor nouveau_vp3_bsp
and nvc0_decoder_bsp in order to implement
pipe_video_codec::begin_frame/decode_bitstream/end_frame.
So that decode_bitstream can be call multiple times
between each begin/end.

There is nothing really new in these patches.
All the low level code relative to nouveau was already there.
The patches are moving code in order to call nouveau_vp3_bsp and
nvc0_decoder_bsp multiple times between each begin/end frame. 

I made sure that vdpau was still working. Actually it was more than that,
without vdpau I think I would not have been able to do this refactoring.
I also compared that for one begin/end frame the nouveau_bo buffer contains
the same data for vdpau and vaapi. I dumped them for the same stream and
for several seconds. There were all the same.

Regression tests:
I made sure mpeg2, mpeg4, h264 and vc1 are still working with vdpau.

Issues:
I can observe some visual artificats with vaapi on mpeg4 and h264.
It looks 90% ok, color too. But you can feel that something is wrong.
Though it looks good on mpeg2 and vc1. And when dumping the full nouveau_bo
they are the same as those dumped while using vdpau.
I wonder if it could be a bug in st/va itself.

TODO: apply same logic for nv98 but I do not have the
material to test it.

https://bugs.freedesktop.org/show_bug.cgi?id=89969

Julien Isorce (4):
  nouveau: split nouveau_vp3_bsp in begin/next/end
  nvc0: add support for st/va
  nouveau: fix chunk decoding by updating number of slices
  build: enable st/va with nouveau driver

 src/gallium/drivers/nouveau/nouveau_vp3_video.h|  22 +++-
 .../drivers/nouveau/nouveau_vp3_video_bsp.c| 106 ++--
 src/gallium/drivers/nouveau/nv50/nv98_video_bsp.c  |   5 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_video.c  |  44 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_video.h  |  18 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c  | 141 ++---
 src/gallium/targets/va/Makefile.am |   2 +
 7 files changed, 240 insertions(+), 98 deletions(-)

-- 
1.9.1

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


[Mesa-dev] [PATCH v3 3/4] nouveau: fix chunk decoding by updating number of slices

2015-09-07 Thread Julien Isorce
https://bugs.freedesktop.org/show_bug.cgi?id=89969

Signed-off-by: Julien Isorce 
---
 src/gallium/drivers/nouveau/nouveau_vp3_video.h | 3 +++
 src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c | 8 
 2 files changed, 11 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video.h 
b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
index 43b9556..87ae012 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video.h
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video.h
@@ -121,6 +121,9 @@ struct nouveau_vp3_decoder {
 
/* Total data appended so far after last begin frame. */
unsigned bsp_size;
+
+   /* Number of slices so far since last begin frame */
+   unsigned int nb_slices;
 };
 
 struct comm {
diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c 
b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
index c1d70ea..7776e4e 100644
--- a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
+++ b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
@@ -128,6 +128,8 @@ nouveau_vp3_fill_picparm_mpeg12_bsp(struct 
nouveau_vp3_decoder *dec,
for (i = 0; i < 4; ++i)
   pic_bsp->f_code[i/2][i%2] = desc->f_code[i/2][i%2] + 1; // FU
 
+   desc->num_slices = dec->nb_slices;
+
return (desc->num_slices << 4) | (dec->base.profile != 
PIPE_VIDEO_PROFILE_MPEG1);
 }
 
@@ -196,6 +198,8 @@ nouveau_vp3_fill_picparm_h264_bsp(struct 
nouveau_vp3_decoder *dec,
struct h264_picparm_bsp stub_h = {}, *h = &stub_h;
uint32_t caps = (d->slice_count << 4)&0xfff0;
 
+   d->slice_count = dec->nb_slices;
+
assert(!(d->slice_count & ~0xfff));
if (d->slice_count & 0x1000)
   caps |= 1 << 20;
@@ -239,6 +243,7 @@ nouveau_vp3_bsp_begin(struct nouveau_vp3_decoder *dec)
 
dec->bsp_ptr = bsp_bo->map;
dec->bsp_size = NOUVEAU_VP3_BSP_RESERVED_SIZE;
+   dec->nb_slices = 0;
 
dec->bsp_ptr += 0x100;
 
@@ -266,6 +271,8 @@ nouveau_vp3_bsp_next(struct nouveau_vp3_decoder *dec, 
unsigned num_buffers,
struct strparm_bsp *str_bsp = NULL;
int i = 0;
 
+   ++dec->nb_slices;
+
bsp_origin += 0x100;
str_bsp = (struct strparm_bsp *)bsp_origin;
 
@@ -331,6 +338,7 @@ nouveau_vp3_bsp_end(struct nouveau_vp3_decoder *dec, union 
pipe_desc desc)
 
dec->bsp_ptr = NULL;
dec->bsp_size = 0;
+   dec->nb_slices = 0;
 
return caps;
 }
-- 
1.9.1

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


Re: [Mesa-dev] Adaptive Vsync

2015-09-07 Thread Albert Freeman
On 7 September 2015 at 08:22, Emil Velikov  wrote:
> On 7 September 2015 at 05:59, Albert Freeman  
> wrote:
>> Correction, we just need someone to mark all the comitted patches in
>> patchwork...
> This is already done automatically.
>
> Sigh top posting :'(.
> -Emil
Sorry, I didn't realise I was top posting since gmail automatically
hides that. patchwork was not when I stated that, but it is now (there
was a discussion on irc).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] r600: don't use shader key without verifying shader type (v2)

2015-09-07 Thread Edward O'Callaghan
LGTM, thanks for catching this!

-- 
  Edward O'Callaghan
  edward.ocallag...@koparo.com

On Tue, Sep 8, 2015, at 09:32 AM, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Since 7a32652231f96eac14c4bfce02afe77b4132fb77
> r600: Turn 'r600_shader_key' struct into union
> 
> we were accessing key fields that might be aliased in the union
> with other fields, so we should check what shader type we are
> compiling for before using key values from it.
> 
> v1.1: make it compile
> v2: have caffiene, make it work - we don't set type
> until later, so don't reference it until we've set it.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/drivers/r600/r600_shader.c | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/r600_shader.c
> b/src/gallium/drivers/r600/r600_shader.c
> index 78904da..f2c9e16 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -143,7 +143,7 @@ int r600_pipe_shader_create(struct pipe_context *ctx,
>   bool dump = r600_can_dump_shader(&rctx->screen->b, sel->tokens);
>   unsigned use_sb = !(rctx->screen->b.debug_flags & DBG_NO_SB);
>   unsigned sb_disasm = use_sb || (rctx->screen->b.debug_flags & 
> DBG_SB_DISASM);
> -   unsigned export_shader = key.vs.as_es;
> +   unsigned export_shader;
>  
>   shader->shader.bc.isa = rctx->isa;
>  
> @@ -224,6 +224,7 @@ int r600_pipe_shader_create(struct pipe_context *ctx,
>   }
>   break;
>   case TGSI_PROCESSOR_VERTEX:
> +   export_shader = key.vs.as_es;
>   if (rctx->b.chip_class >= EVERGREEN) {
>   if (export_shader)
>   evergreen_update_es_state(ctx, shader);
> @@ -1901,8 +1902,6 @@ static int r600_shader_from_tgsi(struct
> r600_context *rctx,
>   ctx.shader = shader;
>   ctx.native_integers = true;
>  
> -   shader->vs_as_gs_a = key.vs.as_gs_a;
> -   shader->vs_as_es = key.vs.as_es;
>  
>   r600_bytecode_init(ctx.bc, rscreen->b.chip_class, rscreen->b.family,
>  rscreen->has_compressed_msaa_texturing);
> @@ -1918,9 +1917,14 @@ static int r600_shader_from_tgsi(struct
> r600_context *rctx,
>   shader->processor_type = ctx.type;
>   ctx.bc->type = shader->processor_type;
>  
> -   ring_outputs = key.vs.as_es || (ctx.type ==
> TGSI_PROCESSOR_GEOMETRY);
> +   if (ctx.type == TGSI_PROCESSOR_VERTEX) {
> +   shader->vs_as_gs_a = key.vs.as_gs_a;
> +   shader->vs_as_es = key.vs.as_es;
> +   }
> +
> +   ring_outputs = shader->vs_as_es || ctx.type ==
> TGSI_PROCESSOR_GEOMETRY;
>  
> -   if (key.vs.as_es) {
> +   if (shader->vs_as_es) {
>   ctx.gs_for_vs = &rctx->gs_shader->current->shader;
>   } else {
>   ctx.gs_for_vs = NULL;
> @@ -1941,7 +1945,8 @@ static int r600_shader_from_tgsi(struct
> r600_context *rctx,
>   shader->nr_ps_color_exports = 0;
>   shader->nr_ps_max_color_exports = 0;
>  
> -   shader->two_side = key.ps.color_two_side;
> +   if (ctx.type == TGSI_PROCESSOR_FRAGMENT)
> +   shader->two_side = key.ps.color_two_side;
>  
>   /* register allocations */
>   /* Values [0,127] correspond to GPR[0..127].
> @@ -2327,7 +2332,7 @@ static int r600_shader_from_tgsi(struct
> r600_context *rctx,
>   convert_edgeflag_to_int(&ctx);
>  
>   if (ring_outputs) {
> -   if (key.vs.as_es) {
> +   if (shader->vs_as_es) {
>   ctx.gs_export_gpr_tregs[0] = r600_get_temp(&ctx);
>   ctx.gs_export_gpr_tregs[1] = -1;
>   ctx.gs_export_gpr_tregs[2] = -1;
> -- 
> 2.4.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] r600/llvm: remove dead code for LLVM 3.3

2015-09-07 Thread Edward O'Callaghan
Kill it !

-- 
  Edward O'Callaghan
  edward.ocallag...@koparo.com

On Mon, Sep 7, 2015, at 08:14 AM, Marek Olšák wrote:
> From: Marek Olšák 
> 
> LLVM 3.3 has been unsupported for quite a while.
> ---
>  src/gallium/drivers/r600/r600_llvm.c | 106
>  ---
>  1 file changed, 106 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/r600_llvm.c
> b/src/gallium/drivers/r600/r600_llvm.c
> index faf538c..3362fd0 100644
> --- a/src/gallium/drivers/r600/r600_llvm.c
> +++ b/src/gallium/drivers/r600/r600_llvm.c
> @@ -77,22 +77,11 @@ static void llvm_load_system_value(
>   default: assert(!"unknown system value");
>   }
>  
> -#if HAVE_LLVM >= 0x0304
>   ctx->system_values[index] = 
> LLVMBuildExtractElement(ctx->gallivm.builder,
>   LLVMGetParam(ctx->main_fn, 0), 
> lp_build_const_int32(&(ctx->gallivm), chan),
>   "");
> -#else
> -   LLVMValueRef reg = lp_build_const_int32(
> -   ctx->soa.bld_base.base.gallivm, chan);
> -   ctx->system_values[index] = lp_build_intrinsic(
> -   ctx->soa.bld_base.base.gallivm->builder,
> -   "llvm.R600.load.input",
> -   ctx->soa.bld_base.base.elem_type, ®, 1,
> -   LLVMReadNoneAttribute);
> -#endif
>  }
>  
> -#if HAVE_LLVM >= 0x0304
>  static LLVMValueRef
>  llvm_load_input_vector(
>   struct radeon_llvm_context * ctx, unsigned location, unsigned ijregs,
> @@ -131,34 +120,7 @@ llvm_load_input_vector(
>   VecType, Args, ArgCount, LLVMReadNoneAttribute);
>   }
>  }
> -#else
> -static LLVMValueRef
> -llvm_load_input_helper(
> -   struct radeon_llvm_context * ctx,
> -   unsigned idx, int interp, int ij_index)
> -{
> -   const struct lp_build_context * bb = &ctx->soa.bld_base.base;
> -   LLVMValueRef arg[2];
> -   int arg_count;
> -   const char * intrinsic;
> -
> -   arg[0] = lp_build_const_int32(bb->gallivm, idx);
> -
> -   if (interp) {
> -   intrinsic = "llvm.R600.interp.input";
> -   arg[1] = lp_build_const_int32(bb->gallivm, ij_index);
> -   arg_count = 2;
> -   } else {
> -   intrinsic = "llvm.R600.load.input";
> -   arg_count = 1;
> -   }
> -
> -   return lp_build_intrinsic(bb->gallivm->builder, intrinsic,
> -   bb->elem_type, &arg[0], arg_count,
> LLVMReadNoneAttribute);
> -}
> -#endif
>  
> -#if HAVE_LLVM >= 0x0304
>  static LLVMValueRef
>  llvm_face_select_helper(
>   struct radeon_llvm_context * ctx,
> @@ -171,21 +133,6 @@ llvm_face_select_helper(
>   return LLVMBuildSelect(bb->gallivm->builder, is_front,
>   front_color, back_color, "");
>  }
> -#else
> -static LLVMValueRef
> -llvm_face_select_helper(
> -   struct radeon_llvm_context * ctx,
> -   unsigned face_loc, LLVMValueRef front_color, LLVMValueRef
> back_color)
> -{
> -   const struct lp_build_context * bb = &ctx->soa.bld_base.base;
> -   LLVMValueRef face = llvm_load_input_helper(ctx, face_loc, 0, 0);
> -   LLVMValueRef is_front = LLVMBuildFCmp(
> -   bb->gallivm->builder, LLVMRealUGT, face,
> -   lp_build_const_float(bb->gallivm, 0.0f),"");
> -   return LLVMBuildSelect(bb->gallivm->builder, is_front,
> -   front_color, back_color, "");
> -}
> -#endif
>  
>  static void llvm_load_input(
>   struct radeon_llvm_context * ctx,
> @@ -194,18 +141,11 @@ static void llvm_load_input(
>  {
>   const struct r600_shader_io * input = &ctx->r600_inputs[input_index];
>   unsigned chan;
> -#if HAVE_LLVM < 0x0304
> -   unsigned interp = 0;
> -   int ij_index;
> -#endif
>   int two_side = (ctx->two_side && input->name == TGSI_SEMANTIC_COLOR);
>   LLVMValueRef v;
> -#if HAVE_LLVM >= 0x0304
>   boolean require_interp_intrinsic = ctx->chip_class >= EVERGREEN &&
>   ctx->type == TGSI_PROCESSOR_FRAGMENT;
> -#endif
>  
> -#if HAVE_LLVM >= 0x0304
>   if (require_interp_intrinsic && input->spi_sid) {
>   v = llvm_load_input_vector(ctx, input->lds_pos, input->ij_index,
>   (input->interpolate > 0));
> @@ -241,49 +181,7 @@ static void llvm_load_input(
>   lp_build_const_float(&(ctx->gallivm), 1.0f),
>   ctx->inputs[soa_index], "");
>   }
> -}
> -#else
> -   if (ctx->chip_class >= EVERGREEN && ctx->type ==
> TGSI_PROCESSOR_FRAGMENT &&
> -   input->spi_sid) {
> -   interp = 1;
> -   ij_index = (input->interpolate > 0) ? input->ij_index :
> -1;
>   }
> -
> -   for (chan = 0; chan < 4; chan++) {
> -   unsigned soa_index =
> radeon_llvm_reg_index_soa(input_index, chan);
> -   int loc;
> -
> -   if (interp) {
> -   loc = 4 * input->lds_pos + chan;
> -   } else {
> -

Re: [Mesa-dev] [PATCH 2/2] gallium/radeon: drop support for LLVM 3.4

2015-09-07 Thread Edward O'Callaghan
Kill it!

-- 
  Edward O'Callaghan
  edward.ocallag...@koparo.com

On Mon, Sep 7, 2015, at 08:14 AM, Marek Olšák wrote:
> From: Marek Olšák 
> 
> This allows using the new tex instrinsics unconditionally.
> ---
>  configure.ac| 2 +-
>  src/gallium/drivers/radeon/r600_pipe_common.c   | 4 
>  src/gallium/drivers/radeon/radeon_llvm_emit.c   | 6 --
>  src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 3 +--
>  src/gallium/drivers/radeonsi/si_compute.c   | 5 +
>  src/gallium/drivers/radeonsi/si_pipe.c  | 9 +++--
>  src/gallium/drivers/radeonsi/si_shader.c| 5 ++---
>  7 files changed, 8 insertions(+), 26 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 0fed26e..8abb933 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2056,7 +2056,7 @@ radeon_llvm_check() {
>  if test "x$enable_gallium_llvm" != "xyes"; then
>  AC_MSG_ERROR([--enable-gallium-llvm is required when building
>  $1])
>  fi
> -llvm_check_version_for "3" "4" "2" $1 
> +llvm_check_version_for "3" "5" "0" $1
>  if test true && $LLVM_CONFIG --targets-built | grep -iqvw
>  $amdgpu_llvm_target_name ; then
>  AC_MSG_ERROR([LLVM $amdgpu_llvm_target_name not enabled in your
>  LLVM build.])
>  fi
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index ed5d1da..1302b5a 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -531,11 +531,7 @@ const char *r600_get_llvm_processor_name(enum
> radeon_family family)
>   case CHIP_KAVERI: return "kaveri";
>   case CHIP_HAWAII: return "hawaii";
>   case CHIP_MULLINS:
> -#if HAVE_LLVM >= 0x0305
>   return "mullins";
> -#else
> -   return "kabini";
> -#endif
>   case CHIP_TONGA: return "tonga";
>   case CHIP_ICELAND: return "iceland";
>   case CHIP_CARRIZO: return "carrizo";
> diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c
> b/src/gallium/drivers/radeon/radeon_llvm_emit.c
> index 0002559..3acbd02 100644
> --- a/src/gallium/drivers/radeon/radeon_llvm_emit.c
> +++ b/src/gallium/drivers/radeon/radeon_llvm_emit.c
> @@ -122,8 +122,6 @@ LLVMTargetRef radeon_llvm_get_r600_target(const char
> *triple)
>   return target;
>  }
>  
> -#if HAVE_LLVM >= 0x0305
> -
>  static void radeonDiagnosticHandler(LLVMDiagnosticInfoRef di, void
>  *context)
>  {
>   if (LLVMGetDiagInfoSeverity(di) == LLVMDSError) {
> @@ -136,8 +134,6 @@ static void
> radeonDiagnosticHandler(LLVMDiagnosticInfoRef di, void *context)
>   }
>  }
>  
> -#endif
> -
>  /**
>   * Compile an LLVM module to machine code.
>   *
> @@ -180,9 +176,7 @@ unsigned radeon_llvm_compile(LLVMModuleRef M, struct
> radeon_shader_binary *binar
>   /* Setup Diagnostic Handler*/
>   llvm_ctx = LLVMGetModuleContext(M);
>  
> -#if HAVE_LLVM >= 0x0305
>   LLVMContextSetDiagnosticHandler(llvm_ctx, radeonDiagnosticHandler, 
> &rval);
> -#endif
>   rval = 0;
>  
>   /* Compile IR*/
> diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> index 5669470..2e9a013 100644
> --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> @@ -1520,8 +1520,7 @@ void radeon_llvm_context_init(struct
> radeon_llvm_context * ctx)
>   bld_base->op_actions[TGSI_OPCODE_POW].intr_name = "llvm.pow.f32";
>   bld_base->op_actions[TGSI_OPCODE_ROUND].emit = 
> build_tgsi_intrinsic_nomem;
>   bld_base->op_actions[TGSI_OPCODE_ROUND].intr_name = 
> "llvm.AMDIL.round.nearest.";
> -   bld_base->op_actions[TGSI_OPCODE_RSQ].intr_name =
> -   HAVE_LLVM >= 0x0305 ? "llvm.AMDGPU.rsq.clamped.f32" :
> "llvm.AMDGPU.rsq";
> +   bld_base->op_actions[TGSI_OPCODE_RSQ].intr_name =
> "llvm.AMDGPU.rsq.clamped.f32";
>   bld_base->op_actions[TGSI_OPCODE_RSQ].emit = build_tgsi_intrinsic_nomem;
>   bld_base->op_actions[TGSI_OPCODE_SGE].emit = emit_cmp;
>   bld_base->op_actions[TGSI_OPCODE_SEQ].emit = emit_cmp;
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> index e3caf5e..ed9147c 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -33,14 +33,11 @@
>  #include "sid.h"
>  
>  #define MAX_GLOBAL_BUFFERS 20
> -#if HAVE_LLVM < 0x0305
> -#define NUM_USER_SGPRS 2
> -#else
> +
>  /* XXX: Even though we don't pass the scratch buffer via user sgprs any
>  more
>   * LLVM still expects that we specify 4 USER_SGPRS so it can remain
>   compatible
>   * with older mesa. */
>  #define NUM_USER_SGPRS 4
> -#endif
>  
>  struct si_compute {
>   struct si_context *ctx;
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 7dbb2e

[Mesa-dev] [Bug 91888] EGL Wayland software rendering no longer work after regression

2015-09-07 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91888

--- Comment #3 from nerdopol...@verizon.net ---
So, should I report this against qtwayland instead?

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


Re: [Mesa-dev] Adaptive Vsync

2015-09-07 Thread Albert Freeman
On 8 September 2015 at 01:16, Albert Freeman  wrote:
> On 7 September 2015 at 08:22, Emil Velikov  wrote:
>> On 7 September 2015 at 05:59, Albert Freeman  
>> wrote:
>>> Correction, we just need someone to mark all the comitted patches in
>>> patchwork...
>> This is already done automatically.
>>
>> Sigh top posting :'(.
>> -Emil
You are correct, I was mistaken.
> patchwork was not when I stated that, but it is now (there
> was a discussion on irc).
This is wrong.

The correct conclusion is: All reviewers should use patchwork to track
patches that need attention if they were not already doing so. Sorry
for all the confusion.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] clover: Avoid using typename to allow compilation of clover by clang

2015-09-07 Thread Albert Freeman
When parsing an variable declaration qualified with the typename
keyword, clang attempted to declare a variable with the type of non
type member "enum type type" of module::argument (within the header
file clover/core/module.hpp) instead of the typed member of
module::argument "enum type".

Replaced "typename" with "enum" to force clang to declare the variable
marg_type with type "enum type" of module::argument.

CC: "11.0" 
Reviewed-by: Francisco Jerez 
Signed-off-by: Albert Freeman 
---
 src/gallium/state_trackers/clover/llvm/invocation.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp 
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 7c23a27..d74b50d 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -465,7 +465,7 @@ namespace {
 const bool is_write_only = access_qual == "write_only";
 const bool is_read_only = access_qual == "read_only";
 
-typename module::argument::type marg_type;
+enum module::argument::type marg_type;
 if (is_image2d && is_read_only) {
marg_type = module::argument::image2d_rd;
 } else if (is_image2d && is_write_only) {
-- 
2.5.1

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


Re: [Mesa-dev] [PATCH v2 1/2] egl/dri2: Close file descriptor on error.

2015-09-07 Thread Boyan Ding
2015-09-07 16:58 GMT+08:00 Emil Velikov :
> From: Matt Turner 
>
> v2: [Emil Velikov]
> Rework the error path to a common goto, close only if we own the fd.
>
> Signed-off-by: Emil Velikov 

Reviewed-by: Boyan Ding 

> ---
>  src/egl/drivers/dri2/platform_drm.c | 27 ++-
>  1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_drm.c 
> b/src/egl/drivers/dri2/platform_drm.c
> index eda5087..e8fe7ea 100644
> --- a/src/egl/drivers/dri2/platform_drm.c
> +++ b/src/egl/drivers/dri2/platform_drm.c
> @@ -623,26 +623,20 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
>dri2_dpy->own_device = 1;
>gbm = gbm_create_device(fd);
>if (gbm == NULL)
> - return EGL_FALSE;
> + goto cleanup;
> }
>
> -   if (strcmp(gbm_device_get_backend_name(gbm), "drm") != 0) {
> -  free(dri2_dpy);
> -  return EGL_FALSE;
> -   }
> +   if (strcmp(gbm_device_get_backend_name(gbm), "drm") != 0)
> +  goto cleanup;
>
> dri2_dpy->gbm_dri = gbm_dri_device(gbm);
> -   if (dri2_dpy->gbm_dri->base.type != GBM_DRM_DRIVER_TYPE_DRI) {
> -  free(dri2_dpy);
> -  return EGL_FALSE;
> -   }
> +   if (dri2_dpy->gbm_dri->base.type != GBM_DRM_DRIVER_TYPE_DRI)
> +  goto cleanup;
>
> if (fd < 0) {
>fd = fcntl(gbm_device_get_fd(gbm), F_DUPFD_CLOEXEC, 3);
> -  if (fd < 0) {
> - free(dri2_dpy);
> - return EGL_FALSE;
> -  }
> +  if (fd < 0)
> + goto cleanup;
> }
>
> dri2_dpy->fd = fd;
> @@ -727,4 +721,11 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
> dri2_dpy->vtbl = &dri2_drm_display_vtbl;
>
> return EGL_TRUE;
> +
> +cleanup:
> +   if (dri2_dpy->own_device)
> +  close(fd);
> +
> +   free(dri2_dpy);
> +   return EGL_FALSE;
>  }
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH V3 1/6] glsl: order indices for samplers inside a struct array

2015-09-07 Thread Timothy Arceri
On Tue, 2015-09-08 at 08:09 +1000, Timothy Arceri wrote:
> On Mon, 2015-09-07 at 11:24 -0700, Jason Ekstrand wrote:
> > On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri <
> > t_arc...@yahoo.com.au>
> > wrote:
> > > This allows the correct offset to be easily calculated for
> > > indirect
> > > indexing when a struct array contains multiple samplers, or any
> > > crazy
> > > nesting.
> > > 
> > > The indices for the folling struct will now look like this:
> > > Sampler index: 0 Name: s[0].tex
> > > Sampler index: 1 Name: s[1].tex
> > > Sampler index: 2 Name: s[0].si.tex
> > > Sampler index: 3 Name: s[1].si.tex
> > > Sampler index: 4 Name: s[0].si.tex2
> > > Sampler index: 5 Name: s[1].si.tex2
> > > 
> > > Before this change it looked like this:
> > > Sampler index: 0 Name: s[0].tex
> > > Sampler index: 3 Name: s[1].tex
> > > Sampler index: 1 Name: s[0].si.tex
> > > Sampler index: 4 Name: s[1].si.tex
> > > Sampler index: 2 Name: s[0].si.tex2
> > > Sampler index: 5 Name: s[1].si.tex2
> > > 
> > > struct S_inner {
> > >sampler2D tex;
> > >sampler2D tex2;
> > > };
> > > 
> > > struct S {
> > >sampler2D tex;
> > >S_inner si;
> > > };
> > > 
> > > uniform S s[2];
> > > 
> > > V2: rename struct array counter to have better name
> > > ---
> > >  src/glsl/link_uniforms.cpp | 112
> > > ++--
> > > -
> > >  src/glsl/linker.h  |   4 +-
> > >  2 files changed, 98 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/src/glsl/link_uniforms.cpp
> > > b/src/glsl/link_uniforms.cpp
> > > index 254086d..5402c99 100644
> > > --- a/src/glsl/link_uniforms.cpp
> > > +++ b/src/glsl/link_uniforms.cpp
> > > @@ -28,6 +28,7 @@
> > >  #include "glsl_symbol_table.h"
> > >  #include "program/hash_table.h"
> > >  #include "program.h"
> > > +#include "util/hash_table.h"
> > > 
> > >  /**
> > >   * \file link_uniforms.cpp
> > > @@ -63,14 +64,17 @@ program_resource_visitor::process(const
> > > glsl_type
> > > *type, const char *name)
> > > assert(type->without_array()->is_record()
> > >|| type->without_array()->is_interface());
> > > 
> > > +   unsigned record_array_count = 1;
> > > char *name_copy = ralloc_strdup(NULL, name);
> > > -   recursion(type, &name_copy, strlen(name), false, NULL,
> > > false);
> > > +   recursion(type, &name_copy, strlen(name), false, NULL, false,
> > > + record_array_count);
> > > ralloc_free(name_copy);
> > >  }
> > > 
> > >  void
> > >  program_resource_visitor::process(ir_variable *var)
> > >  {
> > > +   unsigned record_array_count = 1;
> > > const glsl_type *t = var->type;
> > > const bool row_major =
> > >var->data.matrix_layout == GLSL_MATRIX_LAYOUT_ROW_MAJOR;
> > > @@ -111,7 +115,8 @@ program_resource_visitor::process(ir_variable
> > > *var)
> > >* lowering is only applied to non-uniform interface
> > > blocks, so
> > > we
> > >* can safely pass false for row_major.
> > >*/
> > > - recursion(var->type, &name, new_length, row_major,
> > > NULL, false);
> > > + recursion(var->type, &name, new_length, row_major,
> > > NULL, false,
> > > +   record_array_count);
> > >}
> > >ralloc_free(name);
> > > } else if (var->data.from_named_ifc_block_nonarray) {
> > > @@ -135,19 +140,23 @@
> > > program_resource_visitor::process(ir_variable *var)
> > > * is only applied to non-uniform interface blocks, so we
> > > can
> > > safely
> > > * pass false for row_major.
> > > */
> > > -  recursion(var->type, &name, strlen(name), row_major, NULL,
> > > false);
> > > +  recursion(var->type, &name, strlen(name), row_major, NULL,
> > > false,
> > > +record_array_count);
> > >ralloc_free(name);
> > > } else if (t->without_array()->is_record()) {
> > >char *name = ralloc_strdup(NULL, var->name);
> > > -  recursion(var->type, &name, strlen(name), row_major, NULL,
> > > false);
> > > +  recursion(var->type, &name, strlen(name), row_major, NULL,
> > > false,
> > > +record_array_count);
> > >ralloc_free(name);
> > > } else if (t->is_interface()) {
> > >char *name = ralloc_strdup(NULL, var->type->name);
> > > -  recursion(var->type, &name, strlen(name), row_major, NULL,
> > > false);
> > > +  recursion(var->type, &name, strlen(name), row_major, NULL,
> > > false,
> > > +record_array_count);
> > >ralloc_free(name);
> > > } else if (t->is_array() && t->fields.array->is_interface())
> > > {
> > >char *name = ralloc_strdup(NULL, var->type->fields.array
> > > ->name);
> > > -  recursion(var->type, &name, strlen(name), row_major, NULL,
> > > false);
> > > +  recursion(var->type, &name, strlen(name), row_major, NULL,
> > > false,
> > > +record_array_count);
> > >ralloc_free(name);
> > > } else {
> > >this->visit_field(t, var->name, row_major, NULL

Re: [Mesa-dev] [PATCH 2/2] egl/dri2/drm: compact existing device mgmt

2015-09-07 Thread Boyan Ding
2015-09-07 16:58 GMT+08:00 Emil Velikov :
> Move the fcntl(dupfd_cloexec) to the else branch where it belongs.
> Otherwise it's not immediately obvious that the code is hit, only when
> an existing device is used.

A potential problem here. The fd acquired from gbm device provided as
platform display has been dup'ed, so it should also be closed if we hit
the error condition below, regardless of own_device.

The first patch itself happened to be right because acquiring fd from
platform gbm device is the last place place where error can occur.

If we really want this one, we'd better close fd according to its
validity (you can change it in the first patch), i.e.

cleanup:
   if (dri2_dpy->fd >= 0)
  close(fd);

   free(dri2_dpy);
   return EGL_FALSE;

With that fixed, this patch is
Reviewed-by: Boyan Ding 

>
> Signed-off-by: Emil Velikov 
> ---
>  src/egl/drivers/dri2/platform_drm.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_drm.c 
> b/src/egl/drivers/dri2/platform_drm.c
> index e8fe7ea..cccde12 100644
> --- a/src/egl/drivers/dri2/platform_drm.c
> +++ b/src/egl/drivers/dri2/platform_drm.c
> @@ -624,6 +624,10 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
>gbm = gbm_create_device(fd);
>if (gbm == NULL)
>   goto cleanup;
> +   } else {
> +  fd = fcntl(gbm_device_get_fd(gbm), F_DUPFD_CLOEXEC, 3);
> +  if (fd < 0)
> + goto cleanup;
> }
>
> if (strcmp(gbm_device_get_backend_name(gbm), "drm") != 0)
> @@ -633,12 +637,6 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
> if (dri2_dpy->gbm_dri->base.type != GBM_DRM_DRIVER_TYPE_DRI)
>goto cleanup;
>
> -   if (fd < 0) {
> -  fd = fcntl(gbm_device_get_fd(gbm), F_DUPFD_CLOEXEC, 3);
> -  if (fd < 0)
> - goto cleanup;
> -   }
> -
> dri2_dpy->fd = fd;
> dri2_dpy->device_name = loader_get_device_name_for_fd(dri2_dpy->fd);
> dri2_dpy->driver_name = strdup(dri2_dpy->gbm_dri->base.driver_name);
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/3] glsl: Use hash tables in opt_constant_variable().

2015-09-07 Thread Tapani Pälli
I did not get as impressive results with these 3 patches (how did you 
measure?) but on my machine (HSW GT2) complete shader_runner time goes 
from ~83 secs to ~70secs so it is definitely improving.


I simply do 'time bin/shader_runner' for the measurement.

Tested-by: Tapani Pälli 

On 09/05/2015 12:21 PM, Kenneth Graunke wrote:

Cuts compile/link time of the fragment shader in bug #91857 by 31%
(31.79 -> 21.64).  It has over 8,000 variables so linked lists are
terrible.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91857
Signed-off-by: Kenneth Graunke 
---
  src/glsl/opt_constant_variable.cpp | 39 --
  1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/src/glsl/opt_constant_variable.cpp 
b/src/glsl/opt_constant_variable.cpp
index 7aaaeed..cdfbc34 100644
--- a/src/glsl/opt_constant_variable.cpp
+++ b/src/glsl/opt_constant_variable.cpp
@@ -36,11 +36,11 @@
  #include "ir_visitor.h"
  #include "ir_optimization.h"
  #include "glsl_types.h"
+#include "util/hash_table.h"

  namespace {

  struct assignment_entry {
-   exec_node link;
 int assignment_count;
 ir_variable *var;
 ir_constant *constval;
@@ -54,31 +54,32 @@ public:
 virtual ir_visitor_status visit_enter(ir_assignment *);
 virtual ir_visitor_status visit_enter(ir_call *);

-   exec_list list;
+   struct hash_table *ht;
  };

  } /* unnamed namespace */

  static struct assignment_entry *
-get_assignment_entry(ir_variable *var, exec_list *list)
+get_assignment_entry(ir_variable *var, struct hash_table *ht)
  {
+   struct hash_entry *hte = _mesa_hash_table_search(ht, var);
 struct assignment_entry *entry;

-   foreach_list_typed(struct assignment_entry, entry, link, list) {
-  if (entry->var == var)
-return entry;
+   if (hte) {
+  entry = (struct assignment_entry *) hte->data;
+   } else {
+  entry = (struct assignment_entry *) calloc(1, sizeof(*entry));
+  entry->var = var;
+  _mesa_hash_table_insert(ht, var, entry);
 }

-   entry = (struct assignment_entry *)calloc(1, sizeof(*entry));
-   entry->var = var;
-   list->push_head(&entry->link);
 return entry;
  }

  ir_visitor_status
  ir_constant_variable_visitor::visit(ir_variable *ir)
  {
-   struct assignment_entry *entry = get_assignment_entry(ir, &this->list);
+   struct assignment_entry *entry = get_assignment_entry(ir, this->ht);
 entry->our_scope = true;
 return visit_continue;
  }
@@ -97,7 +98,7 @@ ir_constant_variable_visitor::visit_enter(ir_assignment *ir)
 ir_constant *constval;
 struct assignment_entry *entry;

-   entry = get_assignment_entry(ir->lhs->variable_referenced(), &this->list);
+   entry = get_assignment_entry(ir->lhs->variable_referenced(), this->ht);
 assert(entry);
 entry->assignment_count++;

@@ -150,7 +151,7 @@ ir_constant_variable_visitor::visit_enter(ir_call *ir)
 struct assignment_entry *entry;

 assert(var);
-entry = get_assignment_entry(var, &this->list);
+entry = get_assignment_entry(var, this->ht);
 entry->assignment_count++;
}
 }
@@ -161,7 +162,7 @@ ir_constant_variable_visitor::visit_enter(ir_call *ir)
struct assignment_entry *entry;

assert(var);
-  entry = get_assignment_entry(var, &this->list);
+  entry = get_assignment_entry(var, this->ht);
entry->assignment_count++;
 }

@@ -177,20 +178,22 @@ do_constant_variable(exec_list *instructions)
 bool progress = false;
 ir_constant_variable_visitor v;

+   v.ht = _mesa_hash_table_create(NULL, _mesa_hash_pointer,
+  _mesa_key_pointer_equal);
 v.run(instructions);

-   while (!v.list.is_empty()) {
-
-  struct assignment_entry *entry;
-  entry = exec_node_data(struct assignment_entry, v.list.head, link);
+   struct hash_entry *hte;
+   hash_table_foreach(v.ht, hte) {
+  struct assignment_entry *entry = (struct assignment_entry *) hte->data;

if (entry->assignment_count == 1 && entry->constval && 
entry->our_scope) {
 entry->var->constant_value = entry->constval;
 progress = true;
}
-  entry->link.remove();
+  hte->data = NULL;
free(entry);
 }
+   _mesa_hash_table_destroy(v.ht, NULL);

 return progress;
  }


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