[Mesa-dev] [PATCH] radeonsi: add ETC1 support for Stoney

[Marek Olšák]

From: Marek Olšák 

It's a subset of ETC2. Tested.

For more information, see page 42 and onward:
http://www.graphicshardware.org/previous/www_2007/presentations/strom-etc2-gh07.pdf
---
 src/gallium/drivers/radeonsi/si_state.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 1be260d..9c30c39 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1487,6 +1487,7 @@ static uint32_t si_translate_texformat(struct pipe_screen 
*screen,
if (desc->layout == UTIL_FORMAT_LAYOUT_ETC &&
sscreen->b.family >= CHIP_STONEY) {
switch (format) {
+   case PIPE_FORMAT_ETC1_RGB8:
case PIPE_FORMAT_ETC2_RGB8:
case PIPE_FORMAT_ETC2_SRGB8:
return V_008F14_IMG_DATA_FORMAT_ETC2_RGB;
-- 
2.1.4

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

Re: [Mesa-dev] [android-x86-devel] Re: need-help: how to change to newest mesa in android-x86?

[Rob Herring]

On Mon, Jan 18, 2016 at 4:46 PM, Rob Clark  wrote:
> On Mon, Jan 18, 2016 at 5:18 PM, Rob Herring  wrote:
>> On Fri, Jan 15, 2016 at 3:10 PM, Dave Airlie  wrote:

 well, nothing specific, but for example early on we had some confusion
 in drm_gralloc (when adding dmabuf fd support) about who close()d the
 fd's.  Resulting in same fd getting closed twice (although some
 completely unrelated file handle might have snuck into that slot
 between the two close()s).

 Or you could end up w/ the same sort of thing for gem handles (which
 are unique to the drm device fd, so if you open() the device multiple
 times..).  I did initially have some confusion about this, w/ multiple
 fd_bo's (or pipe_resource's) being created for a given gem handle, and
 first one that gets deleted takes away the backing store that both
 userspace references where using.

 You might want to look at freedreno_drm_winsys.c and the crazy things
 it does..  I suspect virgl might need similar hacks.  That is really
 one part of two, that ensures that we share the same pipe_screen, and
 therefore (from libdrm) fd_device, for a given drm device fd.  The
 other part is that fd_device has hashtables to deal w/ double import
 of gem buffers.
>>>
>>> I think Rob Clark might be on the right track here.
>>>
>>> it sounds like the host is sending double deletes for some objects, which
>>> sounds like a possible reference counting bug in the host.
>>>
>>> So possibly something drm_gralloc, but it could be a bug in mesa, though
>>> I haven't triggered anything like this yet.
>>
>> Some more details. If I comment out the freeing of imported buffers in
>> gralloc_drm_handle_unregister, things work a lot better. I think there
>> is a missing reference taken on an alloc with an existing dmabuf FD.
>> I've been comparing freedreno vs. pipe alloc/free implementations for
>> gralloc. The freedreno alloc function will call drmPrimeFDToHandle and
>> increment the BO ref count (in lookup_bo). The equivalent for virgl is
>> in virgl_drm_winsys_resource_create_handle. It calls
>> drmPrimeFDToHandle, but there is no reference taken. The shared handle
>> case in that function does take a reference with a
>> virgl_drm_resource_reference call. I may be off as my attempted fix
>> doesn't work...
>
> Hmm, so I guess I should have removed gralloc_drm_freedreno, but by
> the time I actually got things working properly on ifc6410 I was using
> gralloc_drm_pipe.c..  sorry if you had been looking at the wrong code.

I was and should have realized that. Still, it got me looking at the
right area. The virgl driver is missing a BO handle hash table for
prime fd handles. It is only doing handle lookups for shared handles.
I've fixed that, but have broken the shared handle hashing in the
process. Looking at other drivers, it appears I need to have 2 hash
tables. I'm guessing shared handles and prime handles are from
different number spaces?

> I originally abandoned gralloc_drm_freedreno once I realized that for
> the refcnt'ing to work out I needed gralloc to share the same
> fd_device ptr as mesa/gl.  And by using gralloc_drm_pipe (plus that
> freedreno winsys code I pointed to earlier) both gralloc and the gl
> context share the same pipe_screen (and fd_device).

Looks like this was the main problem. With screen ref counting and
prime handle lookups, virgl seems to be working now.

The radeon driver also does the same ref counting. Shouldn't this be
common code rather than duplicated in each driver?

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

Re: [Mesa-dev] [PATCH 4/4] radeonsi: change LLVM intrinsics for BREV, CLAMP, EX2

[Tom Stellard]

On Fri, Jan 22, 2016 at 03:18:13PM +0100, Marek Olšák wrote:
> From: Marek Olšák 
> 

Reviewed-by: Tom Stellard 

> Requested by Matt Arsenault.
> ---
>  src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c 
> b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> index c94f109..76be376 100644
> --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> @@ -1511,12 +1511,14 @@ void radeon_llvm_context_init(struct 
> radeon_llvm_context * ctx)
>   bld_base->op_actions[TGSI_OPCODE_BFI].emit = emit_bfi;
>   bld_base->op_actions[TGSI_OPCODE_BGNLOOP].emit = bgnloop_emit;
>   bld_base->op_actions[TGSI_OPCODE_BREV].emit = 
> build_tgsi_intrinsic_nomem;
> - bld_base->op_actions[TGSI_OPCODE_BREV].intr_name = "llvm.AMDGPU.brev";
> + bld_base->op_actions[TGSI_OPCODE_BREV].intr_name =
> + HAVE_LLVM >= 0x0308 ? "llvm.bitreverse.i32" : 
> "llvm.AMDGPU.brev";
>   bld_base->op_actions[TGSI_OPCODE_BRK].emit = brk_emit;
>   bld_base->op_actions[TGSI_OPCODE_CEIL].emit = 
> build_tgsi_intrinsic_nomem;
>   bld_base->op_actions[TGSI_OPCODE_CEIL].intr_name = "llvm.ceil.f32";
>   bld_base->op_actions[TGSI_OPCODE_CLAMP].emit = 
> build_tgsi_intrinsic_nomem;
> - bld_base->op_actions[TGSI_OPCODE_CLAMP].intr_name = "llvm.AMDIL.clamp.";
> + bld_base->op_actions[TGSI_OPCODE_CLAMP].intr_name =
> + HAVE_LLVM >= 0x0308 ? "llvm.AMDGPU.clamp." : 
> "llvm.AMDIL.clamp.";
>   bld_base->op_actions[TGSI_OPCODE_CMP].emit = emit_cmp;
>   bld_base->op_actions[TGSI_OPCODE_CONT].emit = cont_emit;
>   bld_base->op_actions[TGSI_OPCODE_COS].emit = build_tgsi_intrinsic_nomem;
> @@ -1539,7 +1541,8 @@ void radeon_llvm_context_init(struct 
> radeon_llvm_context * ctx)
>   bld_base->op_actions[TGSI_OPCODE_ENDIF].emit = endif_emit;
>   bld_base->op_actions[TGSI_OPCODE_ENDLOOP].emit = endloop_emit;
>   bld_base->op_actions[TGSI_OPCODE_EX2].emit = build_tgsi_intrinsic_nomem;
> - bld_base->op_actions[TGSI_OPCODE_EX2].intr_name = "llvm.AMDIL.exp.";
> + bld_base->op_actions[TGSI_OPCODE_EX2].intr_name =
> + HAVE_LLVM >= 0x0308 ? "llvm.exp2.f32" : "llvm.AMDIL.exp.";
>   bld_base->op_actions[TGSI_OPCODE_FLR].emit = build_tgsi_intrinsic_nomem;
>   bld_base->op_actions[TGSI_OPCODE_FLR].intr_name = "llvm.floor.f32";
>   bld_base->op_actions[TGSI_OPCODE_FMA].emit = build_tgsi_intrinsic_nomem;
> -- 
> 2.1.4
> 
> ___
> 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 2/2] st/mesa: enable OES_geometry_shader if GLSL 1.50 is supported

[Ian Romanick]

On 01/22/2016 10:21 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin 
> ---
>  src/mesa/state_tracker/st_extensions.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index 01ba015..af99f5b 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -764,6 +764,9 @@ void st_init_extensions(struct pipe_screen *screen,
>extensions->AMD_vertex_shader_layer = GL_TRUE;
> }
>  
> +   if (consts->GLSLVersion >= 150)
> +  extensions->OES_geometry_shader = GL_TRUE;
> +

Should this also depend on GLES 3.1 being enabled?  I think this will
cause any GLES 3.0 driver to start advertising an extension that won't
actually work.

Also... GL_OES_shader_io_blocks?

> if (consts->GLSLVersion >= 130) {
>consts->NativeIntegers = GL_TRUE;
>consts->MaxClipPlanes = 8;
> 

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

[Mesa-dev] [PATCH v2] glsl: add GL_OES_geometry_point_size and conditionalize gl_PointSize

[Ilia Mirkin]

For now this will be enabled in tandem with GL_OES_geometry_shader.
Should a driver come along that wants to separate them out, another
enable can be added.

Also adds the missed GL_OES_geometry_shader define in glcpp.

Signed-off-by: Ilia Mirkin 
---

v1 -> v2: add glcpp defines for both exts

 src/glsl/builtin_variables.cpp   | 7 ++-
 src/glsl/glcpp/glcpp-parse.y | 7 +++
 src/glsl/glsl_parser_extras.cpp  | 1 +
 src/glsl/glsl_parser_extras.h| 2 ++
 src/mesa/main/extensions_table.h | 1 +
 5 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index ccc04c0..25d92cc 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -1201,7 +1201,12 @@ builtin_variable_generator::generate_varyings()
/* gl_Position and gl_PointSize are not visible from fragment shaders. */
if (state->stage != MESA_SHADER_FRAGMENT) {
   add_varying(VARYING_SLOT_POS, vec4_t, "gl_Position");
-  add_varying(VARYING_SLOT_PSIZ, float_t, "gl_PointSize");
+  if (!state->es_shader ||
+  state->stage == MESA_SHADER_VERTEX ||
+  (state->stage == MESA_SHADER_GEOMETRY &&
+   state->OES_geometry_point_size_enable)) {
+ add_varying(VARYING_SLOT_PSIZ, float_t, "gl_PointSize");
+  }
}
 
if (state->is_version(130, 0)) {
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index ef1a657..43a1aa9 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -2386,6 +2386,13 @@ _glcpp_parser_handle_version_declaration(glcpp_parser_t 
*parser, intmax_t versio
  add_builtin_define(parser, 
"GL_OES_texture_storage_multisample_2d_array", 1);
   if (extensions->ARB_blend_func_extended)
  add_builtin_define(parser, "GL_EXT_blend_func_extended", 1);
+
+  if (version >= 310) {
+ if (extensions->OES_geometry_shader) {
+add_builtin_define(parser, "GL_OES_geometry_point_size", 
1);
+add_builtin_define(parser, "GL_OES_geometry_shader", 1);
+ }
+  }
   }
} else {
   add_builtin_define(parser, "GL_ARB_draw_buffers", 1);
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 6038954..7dad466 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -598,6 +598,7 @@ static const _mesa_glsl_extension 
_mesa_glsl_supported_extensions[] = {
/* OES extensions go here, sorted alphabetically.
 */
EXT(OES_EGL_image_external, false, true,  
OES_EGL_image_external),
+   EXT(OES_geometry_point_size,false, true,  OES_geometry_shader),
EXT(OES_geometry_shader,false, true,  OES_geometry_shader),
EXT(OES_standard_derivatives,   false, true,  
OES_standard_derivatives),
EXT(OES_texture_3D, false, true,  dummy_true),
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 3f88e01..a905b56 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -591,6 +591,8 @@ struct _mesa_glsl_parse_state {
 */
bool OES_EGL_image_external_enable;
bool OES_EGL_image_external_warn;
+   bool OES_geometry_point_size_enable;
+   bool OES_geometry_point_size_warn;
bool OES_geometry_shader_enable;
bool OES_geometry_shader_warn;
bool OES_standard_derivatives_enable;
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 7a4b8a2..7fb4de2 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -312,6 +312,7 @@ EXT(OES_element_index_uint  , dummy_true
 EXT(OES_fbo_render_mipmap   , dummy_true   
  ,  x ,  x , ES1, ES2, 2005)
 EXT(OES_fixed_point , dummy_true   
  ,  x ,  x , ES1,  x , 2002)
 EXT(OES_framebuffer_object  , dummy_true   
  ,  x ,  x , ES1,  x , 2005)
+EXT(OES_geometry_point_size , OES_geometry_shader  
  ,  x ,  x ,  x ,  31, 2015)
 EXT(OES_geometry_shader , OES_geometry_shader  
  ,  x ,  x ,  x ,  31, 2015)
 EXT(OES_get_program_binary  , dummy_true   
  ,  x ,  x ,  x , ES2, 2008)
 EXT(OES_mapbuffer   , dummy_true   
  ,  x ,  x , ES1, ES2, 2005)
-- 
2.4.10

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

Re: [Mesa-dev] [PATCH] winsys/amdgpu: optionally use buffer lists with all allocated buffers

[Alex Deucher]

On Fri, Jan 22, 2016 at 3:19 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> Set RADEON_ALL_BOS=1 to use it.

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 21 +
>  src/gallium/winsys/amdgpu/drm/amdgpu_bo.h |  2 ++
>  src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 33 
> ---
>  src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c |  3 +++
>  src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h |  5 
>  5 files changed, 61 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c 
> b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
> index 82c803b..30a1aa8 100644
> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
> @@ -128,6 +128,11 @@ void amdgpu_bo_destroy(struct pb_buffer *_buf)
> struct amdgpu_winsys_bo *bo = amdgpu_winsys_bo(_buf);
> int i;
>
> +   pipe_mutex_lock(bo->ws->global_bo_list_lock);
> +   LIST_DEL(>global_list_item);
> +   bo->ws->num_buffers--;
> +   pipe_mutex_unlock(bo->ws->global_bo_list_lock);
> +
> amdgpu_bo_va_op(bo->bo, 0, bo->base.size, bo->va, 0, AMDGPU_VA_OP_UNMAP);
> amdgpu_va_range_free(bo->va_handle);
> amdgpu_bo_free(bo->bo);
> @@ -249,6 +254,16 @@ static const struct pb_vtbl amdgpu_winsys_bo_vtbl = {
> /* other functions are never called */
>  };
>
> +static void amdgpu_add_buffer_to_global_list(struct amdgpu_winsys_bo *bo)
> +{
> +   struct amdgpu_winsys *ws = bo->ws;
> +
> +   pipe_mutex_lock(ws->global_bo_list_lock);
> +   LIST_ADDTAIL(>global_list_item, >global_bo_list);
> +   ws->num_buffers++;
> +   pipe_mutex_unlock(ws->global_bo_list_lock);
> +}
> +
>  static struct amdgpu_winsys_bo *amdgpu_create_bo(struct amdgpu_winsys *ws,
>   unsigned size,
>   unsigned alignment,
> @@ -319,6 +334,8 @@ static struct amdgpu_winsys_bo *amdgpu_create_bo(struct 
> amdgpu_winsys *ws,
> else if (initial_domain & RADEON_DOMAIN_GTT)
>ws->allocated_gtt += align(size, ws->gart_page_size);
>
> +   amdgpu_add_buffer_to_global_list(bo);
> +
> return bo;
>
>  error_va_map:
> @@ -588,6 +605,8 @@ static struct pb_buffer *amdgpu_bo_from_handle(struct 
> radeon_winsys *rws,
> else if (bo->initial_domain & RADEON_DOMAIN_GTT)
>ws->allocated_gtt += align(bo->base.size, ws->gart_page_size);
>
> +   amdgpu_add_buffer_to_global_list(bo);
> +
> return >base;
>
>  error_va_map:
> @@ -673,6 +692,8 @@ static struct pb_buffer *amdgpu_bo_from_ptr(struct 
> radeon_winsys *rws,
>
>  ws->allocated_gtt += align(bo->base.size, ws->gart_page_size);
>
> +amdgpu_add_buffer_to_global_list(bo);
> +
>  return (struct pb_buffer*)bo;
>
>  error_va_map:
> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h 
> b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h
> index 12cb920..54f5dbd 100644
> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h
> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h
> @@ -60,6 +60,8 @@ struct amdgpu_winsys_bo {
>
> /* Fences for buffer synchronization. */
> struct pipe_fence_handle *fence[RING_LAST];
> +
> +   struct list_head global_list_item;
>  };
>
>  bool amdgpu_bo_can_reclaim(struct pb_buffer *_buf);
> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
> b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
> index 10f112d..83da740 100644
> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
> @@ -605,6 +605,7 @@ static void amdgpu_cs_sync_flush(struct radeon_winsys_cs 
> *rcs)
>  }
>
>  DEBUG_GET_ONCE_BOOL_OPTION(noop, "RADEON_NOOP", FALSE)
> +DEBUG_GET_ONCE_BOOL_OPTION(all_bos, "RADEON_ALL_BOS", FALSE)
>
>  static void amdgpu_cs_flush(struct radeon_winsys_cs *rcs,
>  unsigned flags,
> @@ -644,9 +645,35 @@ static void amdgpu_cs_flush(struct radeon_winsys_cs *rcs,
> if (cs->base.cdw && cs->base.cdw <= cs->base.max_dw && 
> !debug_get_option_noop()) {
>int r;
>
> -  r = amdgpu_bo_list_create(ws->dev, cs->num_buffers,
> -cs->handles, cs->flags,
> ->request.resources);
> +  /* Use a buffer list containing all allocated buffers if requested. */
> +  if (debug_get_option_all_bos()) {
> + struct amdgpu_winsys_bo *bo;
> + amdgpu_bo_handle *handles;
> + unsigned num = 0;
> +
> + pipe_mutex_lock(ws->global_bo_list_lock);
> +
> + handles = malloc(sizeof(handles[0]) * ws->num_buffers);
> + if (!handles) {
> +pipe_mutex_unlock(ws->global_bo_list_lock);
> +goto cleanup;
> + }
> +
> + LIST_FOR_EACH_ENTRY(bo, >global_bo_list, global_list_item) {
> +assert(num < ws->num_buffers);
> +handles[num++] = bo->bo;
> + }
> +
> + r = amdgpu_bo_list_create(ws->dev, 

Re: [Mesa-dev] [PATCH 5/4] mesa: Refactor error checking for GL_TEXTURE_BASE_LEVEL vs texture targets

[Jason Ekstrand]

On Fri, Jan 22, 2016 at 10:49 AM, Ian Romanick  wrote:

> On 01/21/2016 12:15 PM, Jason Ekstrand wrote:
> >
> > On Jan 21, 2016 10:30 AM, "Ian Romanick"  > > wrote:
> >>
> >> On 01/20/2016 08:29 PM, Jason Ekstrand wrote:
> >> >
> >> > On Jan 20, 2016 6:20 PM, "Ian Romanick"  > 
> >> > >> wrote:
> >> >>
> >> >> From: Ian Romanick  > 
> >> > >>
> >> >>
> >> >> Add a big spec quotation justifying the error generated, which has
> >> >> changed over the GL versions.
> >> >>
> >> >> Signed-off-by: Ian Romanick  > 
> >> > >>
> >> >> ---
> >> >>
> >> >> I intended to send this out with the other four, but I selected the
> >> >> wrong SHA from the list.
> >> >>
> >> >>  src/mesa/main/texparam.c | 31 ---
> >> >>  1 file changed, 24 insertions(+), 7 deletions(-)
> >> >>
> >> >> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
> >> >> index 89f286c..ee50b5a 100644
> >> >> --- a/src/mesa/main/texparam.c
> >> >> +++ b/src/mesa/main/texparam.c
> >> >> @@ -369,8 +369,31 @@ set_tex_parameteri(struct gl_context *ctx,
> >> >>if (texObj->BaseLevel == params[0])
> >> >>   return GL_FALSE;
> >> >>
> >> >> +  /* Section 8.10 (Texture Parameters) of the OpenGL 4.5 Core
> >> > Profile spec
> >> >> +   * says:
> >> >> +   *
> >> >> +   * "An INVALID_OPERATION error is generated if the
> >> > effective target
> >> >> +   * is either TEXTURE_2D_MULTISAMPLE or
> >> > TEXTURE_2D_MULTISAMPLE_ARRAY,
> >> >> +   * and pname TEXTURE_BASE_LEVEL is set to a value other
> >> > than zero.
> >> >> +   *
> >> >> +   * ...
> >> >> +   *
> >> >> +   * An INVALID_OPERATION error is generated if the
> effective
> >> > target
> >> >> +   * is TEXTURE_RECTANGLE and pname TEXTURE_BASE_LEVEL is
> set
> >> > to any
> >> >> +   * value other than zero."
> >> >
> >> > Do we really need the "pname"s?  IMHO, they make it harder to read.
> >>
> >> I'm not sure what you mean.  The pnames in the spec quote or ... ?
> >
> > Yes. Some versions of the spec have them and some don't.  The quote
> > below, for instance, doesn't.
>
> From 4.1 to 4.2 the format of the spec was completely changed.  In 4.1
> an earlier, the errors were mixed with the prose.  There was a lot of
> inconsistency and missing errors as a result.  In 4.2 and later, the
> errors are listed in a break-out box at the end of the section.  Having
> had to scrape through the spec countless times to find all the possible
> error cases for a new command over the years, this is a very welcome
> change.
>
> In truth, I should have quoted a bit more text below because it doesn't
> qualify the conditions in which the old error code were generated.  It's
> just some text buried in the paragraph about TEXTURE_RECTANGLE.  For
> clarity, I probably should have quoted more context.
>
> "When target is TEXTURE_RECTANGLE, certain texture parameter
> values may not be specified The error INVALID_VALUE is
> generated if TEXTURE_BASE_LEVEL is set to any value other than
> zero."
>
> TEXTURE_2D_MULTISAMPLE and TEXTURE_2D_MULTISAMPLE_ARRAY did not exist in
> 3.3, so they are not mentioned.  I didn't quote additional context only
> because I was only trying to highlight that the error had changed from
> INVALID_VALUE to INVALID_OPERATION since 3.3.
>
> What I think makes the 4.5 quotation unfortunate is that the two nearly
> identical errors are listed in separate bullets.  This is compounded by
> the slight differences in language ("a value" vs "any value").  I have
> submitted a Khronos bug with a patch for this issue.  My compacted
> wording is:
>
> An INVALID_OPERATION error is generated if the effective target
> is TEXTURE_2D_MULTISAMPLE, TEXTURE_2D_MULTISAMPLE_ARRAY, or
> TEXTURE_RECTANGLE, and pname TEXTURE_BASE_LEVEL is set to a value
> other than zero.
>
> The existing TEXTURE_RECTANGLE bullet is removed.
>
> The whole point of quoting the spec is to justify the code. For that to
> be effective, the quotation has to have enough context.  I'm not sure
> what we'd trim without weakening that justification.  If we remove one
> of the bullets, why is the error generated for the other cases?  If we
> remove the pnames from the bullets, why aren't we generating the error
> for other cases?
>
> We're trying to reduce the amount of time our future selves have to look
> back through the specs when a bug is submitted for a buggy application
> or conformance test. :)
>
> I'm not in a big hurry on this patch, so I'm willing 

Re: [Mesa-dev] [PATCH 2/2] st/mesa: enable OES_geometry_shader if GLSL 1.50 is supported

[Ilia Mirkin]

On Fri, Jan 22, 2016 at 3:00 PM, Ian Romanick  wrote:
> On 01/22/2016 10:21 AM, Ilia Mirkin wrote:
>> Signed-off-by: Ilia Mirkin 
>> ---
>>  src/mesa/state_tracker/st_extensions.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/src/mesa/state_tracker/st_extensions.c 
>> b/src/mesa/state_tracker/st_extensions.c
>> index 01ba015..af99f5b 100644
>> --- a/src/mesa/state_tracker/st_extensions.c
>> +++ b/src/mesa/state_tracker/st_extensions.c
>> @@ -764,6 +764,9 @@ void st_init_extensions(struct pipe_screen *screen,
>>extensions->AMD_vertex_shader_layer = GL_TRUE;
>> }
>>
>> +   if (consts->GLSLVersion >= 150)
>> +  extensions->OES_geometry_shader = GL_TRUE;
>> +
>
> Should this also depend on GLES 3.1 being enabled?  I think this will
> cause any GLES 3.0 driver to start advertising an extension that won't
> actually work.

The ext in extensions.c actually specifies GLES 3.1 as a minimum so in
practice it wouldn't be advertised. (And actually GLSL 1.50 isn't
enough, because we need instancing, so I'll have to switch this to
something more selective.)

>
> Also... GL_OES_shader_io_blocks?

Erm, I thought we had that :) I guess not? I just saw the
OES_geometry_shader stuff getting pushed.

Either way, please consider this patch dropped.

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

Re: [Mesa-dev] [PATCH 23/28] glsl: add pack varying to resource list for vertex input / fragment output

[Anuj Phogat]

On Thu, Jan 21, 2016 at 3:49 PM, Timothy Arceri
 wrote:
> On Thu, 2016-01-21 at 15:28 -0800, Anuj Phogat wrote:
>> On Thu, Jan 21, 2016 at 1:47 PM, Timothy Arceri
>>  wrote:
>> > On Thu, 2016-01-21 at 09:23 -0800, Anuj Phogat wrote:
>> > > On Wed, Jan 20, 2016 at 4:28 PM, Timothy Arceri
>> > >  wrote:
>> > > > On Wed, 2016-01-20 at 15:38 -0800, Anuj Phogat wrote:
>> > > > > On Wed, Jan 20, 2016 at 1:39 PM, Timothy Arceri
>> > > > >  wrote:
>> > > > > > On Wed, 2016-01-20 at 10:06 -0800, Anuj Phogat wrote:
>> > > > > > > On Mon, Dec 28, 2015 at 9:00 PM, Timothy Arceri
>> > > > > > >  wrote:
>> > > > > > > > This is needed now that we pack these type of varyings
>> > > > > > > > when
>> > > > > > > > they
>> > > > > > > > have a
>> > > > > > > > component layout qualifier.
>> > > > > > > > ---
>> > > > > > > >  src/glsl/linker.cpp | 15 ---
>> > > > > > > >  1 file changed, 8 insertions(+), 7 deletions(-)
>> > > > > > > >
>> > > > > > > > diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
>> > > > > > > > index 44dd7f0..52a326a 100644
>> > > > > > > > --- a/src/glsl/linker.cpp
>> > > > > > > > +++ b/src/glsl/linker.cpp
>> > > > > > > > @@ -3763,13 +3763,14 @@
>> > > > > > > > build_program_resource_list(struct
>> > > > > > > > gl_shader_program *shProg)
>> > > > > > > > if (input_stage == MESA_SHADER_STAGES &&
>> > > > > > > > output_stage
>> > > > > > > > == 0)
>> > > > > > > >return;
>> > > > > > > >
>> > > > > > > > -   /* Program interface needs to expose varyings in
>> > > > > > > > case
>> > > > > > > > of
>> > > > > > > > SSO.
>> > > > > > > > */
>> > > > > > > > -   if (shProg->SeparateShader) {
>> > > > > > > > -  if (!add_packed_varyings(shProg, input_stage,
>> > > > > > > > GL_PROGRAM_INPUT))
>> > > > > > > > - return;
>> > > > > > > > -  if (!add_packed_varyings(shProg, output_stage,
>> > > > > > > > GL_PROGRAM_OUTPUT))
>> > > > > > > > - return;
>> > > > > > > > -   }
>> > > > > > > > +   /* Program interface needs to expose varyings in
>> > > > > > > > case
>> > > > > > > > of
>> > > > > > > > SSO,
>> > > > > > > > or in case of
>> > > > > > > > +* vertex inputs/fragement outputs that are packed
>> > > > > > > > unsing
>> > > > > > > > the
>> > > > > > > > component
>> > > > > > > > +* layout qualifier.
>> > > > > > > > +*/
>> > > > > > > > +   if (!add_packed_varyings(shProg, input_stage,
>> > > > > > > > GL_PROGRAM_INPUT))
>> > > > > > > > +  return;
>> > > > > > > > +   if (!add_packed_varyings(shProg, output_stage,
>> > > > > > > > GL_PROGRAM_OUTPUT))
>> > > > > > > > +  return;
>> > > > > > > >
>> > > > > > > > if (!add_fragdata_arrays(shProg))
>> > > > > > > >return;
>> > > > > > > > --
>> > > > > > > > 2.4.3
>> > > > > > > >
>> > > > > > > > ___
>> > > > > > > > mesa-dev mailing list
>> > > > > > > > mesa-dev@lists.freedesktop.org
>> > > > > > > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> > > > > > >
>> > > > > > > I will give you my r-b on this if you can help me
>> > > > > > > understand
>> > > > > > > the
>> > > > > > > concept of
>> > > > > > > exposing varyings and how it's utilized during linking.
>> > > > > >
>> > > > > > Sure. The inputs and outputs to a program need to be added
>> > > > > > to
>> > > > > > the
>> > > > > > resource list so that they can be queried by
>> > > > > > ARB_program_interface_query via
>> > > > > > PROGRAM_INPUT/PROGRAM_OUTPUT.
>> > > > > Right. Aren't the input/output variables added by
>> > > > >  add_interface_variables() ?
>> > > > > add_packed_varyings() is used just for SSO with below
>> > > > > explanation
>> > > > > from
>> > > > > commit : 4e7fd66:
>> > > > > "Varyings can be considered inputs or outputs of a program
>> > > > > only
>> > > > > when
>> > > > >  SSO is in use. With multi-stage programs, inputs contain
>> > > > > only
>> > > > > inputs
>> > > > >   for first stage and outputs contains outputs of the final
>> > > > > shader
>> > > > > stage."
>> > > > >
>> > > > > Can you explain why do we need to add packed varyings to the
>> > > > > resource
>> > > > > list even with non-SSO?
>> > > >
>> > > > That commit message looks incorrect to me. I don't see anything
>> > > > in
>> > > > the
>> > > > ARB_program_interface_query spec saying that only SSO programs
>> > > > can
>> > > > be
>> > > > queried.
>> > > Commit message just says varyings are also considered program
>> > > inputs/
>> > > outputs in case of SSO. So, add them to to the resource list in
>> > > addition to
>> > > the vertex inputs and fragment outputs.
>> > >
>> > > I meant to ask why do we need to always add "varyings" to the
>> > > resource list
>> > > to support querying vertex inputs and fragment outputs via
>> > > PROGRAM_INPUT/
>> > > PROGRAM_OUTPUT? "varyings" are not supposed 

[Mesa-dev] [PATCH] winsys/amdgpu: optionally use buffer lists with all allocated buffers

[Marek Olšák]

From: Marek Olšák 

Set RADEON_ALL_BOS=1 to use it.
---
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 21 +
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.h |  2 ++
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 33 ---
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c |  3 +++
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h |  5 
 5 files changed, 61 insertions(+), 3 deletions(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index 82c803b..30a1aa8 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
@@ -128,6 +128,11 @@ void amdgpu_bo_destroy(struct pb_buffer *_buf)
struct amdgpu_winsys_bo *bo = amdgpu_winsys_bo(_buf);
int i;
 
+   pipe_mutex_lock(bo->ws->global_bo_list_lock);
+   LIST_DEL(>global_list_item);
+   bo->ws->num_buffers--;
+   pipe_mutex_unlock(bo->ws->global_bo_list_lock);
+
amdgpu_bo_va_op(bo->bo, 0, bo->base.size, bo->va, 0, AMDGPU_VA_OP_UNMAP);
amdgpu_va_range_free(bo->va_handle);
amdgpu_bo_free(bo->bo);
@@ -249,6 +254,16 @@ static const struct pb_vtbl amdgpu_winsys_bo_vtbl = {
/* other functions are never called */
 };
 
+static void amdgpu_add_buffer_to_global_list(struct amdgpu_winsys_bo *bo)
+{
+   struct amdgpu_winsys *ws = bo->ws;
+
+   pipe_mutex_lock(ws->global_bo_list_lock);
+   LIST_ADDTAIL(>global_list_item, >global_bo_list);
+   ws->num_buffers++;
+   pipe_mutex_unlock(ws->global_bo_list_lock);
+}
+
 static struct amdgpu_winsys_bo *amdgpu_create_bo(struct amdgpu_winsys *ws,
  unsigned size,
  unsigned alignment,
@@ -319,6 +334,8 @@ static struct amdgpu_winsys_bo *amdgpu_create_bo(struct 
amdgpu_winsys *ws,
else if (initial_domain & RADEON_DOMAIN_GTT)
   ws->allocated_gtt += align(size, ws->gart_page_size);
 
+   amdgpu_add_buffer_to_global_list(bo);
+
return bo;
 
 error_va_map:
@@ -588,6 +605,8 @@ static struct pb_buffer *amdgpu_bo_from_handle(struct 
radeon_winsys *rws,
else if (bo->initial_domain & RADEON_DOMAIN_GTT)
   ws->allocated_gtt += align(bo->base.size, ws->gart_page_size);
 
+   amdgpu_add_buffer_to_global_list(bo);
+
return >base;
 
 error_va_map:
@@ -673,6 +692,8 @@ static struct pb_buffer *amdgpu_bo_from_ptr(struct 
radeon_winsys *rws,
 
 ws->allocated_gtt += align(bo->base.size, ws->gart_page_size);
 
+amdgpu_add_buffer_to_global_list(bo);
+
 return (struct pb_buffer*)bo;
 
 error_va_map:
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h 
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h
index 12cb920..54f5dbd 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h
@@ -60,6 +60,8 @@ struct amdgpu_winsys_bo {
 
/* Fences for buffer synchronization. */
struct pipe_fence_handle *fence[RING_LAST];
+
+   struct list_head global_list_item;
 };
 
 bool amdgpu_bo_can_reclaim(struct pb_buffer *_buf);
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
index 10f112d..83da740 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
@@ -605,6 +605,7 @@ static void amdgpu_cs_sync_flush(struct radeon_winsys_cs 
*rcs)
 }
 
 DEBUG_GET_ONCE_BOOL_OPTION(noop, "RADEON_NOOP", FALSE)
+DEBUG_GET_ONCE_BOOL_OPTION(all_bos, "RADEON_ALL_BOS", FALSE)
 
 static void amdgpu_cs_flush(struct radeon_winsys_cs *rcs,
 unsigned flags,
@@ -644,9 +645,35 @@ static void amdgpu_cs_flush(struct radeon_winsys_cs *rcs,
if (cs->base.cdw && cs->base.cdw <= cs->base.max_dw && 
!debug_get_option_noop()) {
   int r;
 
-  r = amdgpu_bo_list_create(ws->dev, cs->num_buffers,
-cs->handles, cs->flags,
->request.resources);
+  /* Use a buffer list containing all allocated buffers if requested. */
+  if (debug_get_option_all_bos()) {
+ struct amdgpu_winsys_bo *bo;
+ amdgpu_bo_handle *handles;
+ unsigned num = 0;
+
+ pipe_mutex_lock(ws->global_bo_list_lock);
+
+ handles = malloc(sizeof(handles[0]) * ws->num_buffers);
+ if (!handles) {
+pipe_mutex_unlock(ws->global_bo_list_lock);
+goto cleanup;
+ }
+
+ LIST_FOR_EACH_ENTRY(bo, >global_bo_list, global_list_item) {
+assert(num < ws->num_buffers);
+handles[num++] = bo->bo;
+ }
+
+ r = amdgpu_bo_list_create(ws->dev, ws->num_buffers,
+   handles, NULL,
+   >request.resources);
+ free(handles);
+ pipe_mutex_unlock(ws->global_bo_list_lock);
+  } else {
+ r = amdgpu_bo_list_create(ws->dev, cs->num_buffers,
+   cs->handles, cs->flags,
+ 

Re: [Mesa-dev] [PATCH 00/10] vbo: introduce a minmax_index cache (v3)

[Marek Olšák]

On Fri, Jan 22, 2016 at 6:17 PM, Nicolai Hähnle  wrote:
> On 11.01.2016 21:32, Nicolai Hähnle wrote:
>>
>> here is a new version of the series. I'm calling it v3 even though I never
>> sent v2 because it contains v3 of the main patch. Changes relative to v1:
>>
>> - disable cache on USAGE_TEXTURE_BUFFER and bool/GLboolean nit
>> - disable cache only temporarily when a persistent writable mapping exists
>> - add a MESA_NO_MINMAX_CACHE environment variable that disables caches
>>completely
>> - track hits and misses and disable the cache on a per-BO basis if the
>>hit rate is low
>>
>> The last point is on a per-BO basis because applications don't always have
>> the same usage pattern for all BOs.
>>
>> There is also a new util/hash_table patch which I added for an idea that I
>> ultimately rejected, but it turns out to be useful elsewhere, so I'm
>> sending it along while I'm at it.
>>
>> I benchmarked this series with a couple of tests from PTS, using low
>> resolutions in an attempt to emphasize CPU usage. Their performance is
>> unaffected, with averages with/without this series within the measurement
>> tolerance of each other. That there's no regression is good news, and that
>> there's no improvement is to be expected - if one of these tests had been
>> affected by the problem this series addresses, someone else would probably
>> have done it much earlier ;)
>>
>> Please review!
>
>
> Ping... any opinions on this series? Other than Matt's coding style comment,
> I haven't received anything.

I'm looking at your FDO repo and some patches have my Rbs. These that don't:

util/hash_table: add _mesa_hash_table_num_entries
mesa: add USAGE_DISABLE_MINMAX_CACHE flag to buffer UsageHistory
vbo: disable the minmax cache when the hit rate is low
mesa: add MESA_NO_MINMAX_CACHE environment variable

are:
Reviewed-by: Marek Olšák 

Anything else?

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

[Mesa-dev] [PATCH 1/2] glsl: add GL_OES_geometry_point_size and conditionalize gl_PointSize

[Ilia Mirkin]

For now this will be enabled in tandem with GL_OES_geometry_shader.
Should a driver come along that wants to separate them out, another
enable can be added.

Signed-off-by: Ilia Mirkin 
---
 src/glsl/builtin_variables.cpp   | 7 ++-
 src/glsl/glsl_parser_extras.cpp  | 1 +
 src/glsl/glsl_parser_extras.h| 2 ++
 src/mesa/main/extensions_table.h | 1 +
 4 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index ccc04c0..25d92cc 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -1201,7 +1201,12 @@ builtin_variable_generator::generate_varyings()
/* gl_Position and gl_PointSize are not visible from fragment shaders. */
if (state->stage != MESA_SHADER_FRAGMENT) {
   add_varying(VARYING_SLOT_POS, vec4_t, "gl_Position");
-  add_varying(VARYING_SLOT_PSIZ, float_t, "gl_PointSize");
+  if (!state->es_shader ||
+  state->stage == MESA_SHADER_VERTEX ||
+  (state->stage == MESA_SHADER_GEOMETRY &&
+   state->OES_geometry_point_size_enable)) {
+ add_varying(VARYING_SLOT_PSIZ, float_t, "gl_PointSize");
+  }
}
 
if (state->is_version(130, 0)) {
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 6038954..7dad466 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -598,6 +598,7 @@ static const _mesa_glsl_extension 
_mesa_glsl_supported_extensions[] = {
/* OES extensions go here, sorted alphabetically.
 */
EXT(OES_EGL_image_external, false, true,  
OES_EGL_image_external),
+   EXT(OES_geometry_point_size,false, true,  OES_geometry_shader),
EXT(OES_geometry_shader,false, true,  OES_geometry_shader),
EXT(OES_standard_derivatives,   false, true,  
OES_standard_derivatives),
EXT(OES_texture_3D, false, true,  dummy_true),
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 3f88e01..a905b56 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -591,6 +591,8 @@ struct _mesa_glsl_parse_state {
 */
bool OES_EGL_image_external_enable;
bool OES_EGL_image_external_warn;
+   bool OES_geometry_point_size_enable;
+   bool OES_geometry_point_size_warn;
bool OES_geometry_shader_enable;
bool OES_geometry_shader_warn;
bool OES_standard_derivatives_enable;
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 7a4b8a2..7fb4de2 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -312,6 +312,7 @@ EXT(OES_element_index_uint  , dummy_true
 EXT(OES_fbo_render_mipmap   , dummy_true   
  ,  x ,  x , ES1, ES2, 2005)
 EXT(OES_fixed_point , dummy_true   
  ,  x ,  x , ES1,  x , 2002)
 EXT(OES_framebuffer_object  , dummy_true   
  ,  x ,  x , ES1,  x , 2005)
+EXT(OES_geometry_point_size , OES_geometry_shader  
  ,  x ,  x ,  x ,  31, 2015)
 EXT(OES_geometry_shader , OES_geometry_shader  
  ,  x ,  x ,  x ,  31, 2015)
 EXT(OES_get_program_binary  , dummy_true   
  ,  x ,  x ,  x , ES2, 2008)
 EXT(OES_mapbuffer   , dummy_true   
  ,  x ,  x , ES1, ES2, 2005)
-- 
2.4.10

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

[Mesa-dev] [PATCH 2/2] st/mesa: enable OES_geometry_shader if GLSL 1.50 is supported

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 src/mesa/state_tracker/st_extensions.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 01ba015..af99f5b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -764,6 +764,9 @@ void st_init_extensions(struct pipe_screen *screen,
   extensions->AMD_vertex_shader_layer = GL_TRUE;
}
 
+   if (consts->GLSLVersion >= 150)
+  extensions->OES_geometry_shader = GL_TRUE;
+
if (consts->GLSLVersion >= 130) {
   consts->NativeIntegers = GL_TRUE;
   consts->MaxClipPlanes = 8;
-- 
2.4.10

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

Re: [Mesa-dev] [PATCH] st/mesa: conditionally enable GL_NV_vdpau_interop

[Ilia Mirkin]

On Fri, Jan 22, 2016 at 1:15 PM, Christian König
 wrote:
>> Form autofoo perspective things look great.
>
> Thanks, that exactly what I wanted to know.
>
>> Although I second Ilia's concern - we need a form of runtime detection
>> here. Pretty much all distros ship the vdpau(+ other video driver
>> backend) in a separate library. Thus this will likely get us nowhere
>> we want - as I'm suspecting this is to assist the unsuspecting user,
>> which hasn't installed package X or Y in the first place ?
>
> As I said, Mesa should NOT check what vdpau backend libraries are installed
> or used before advertising NV_vdpau_interop.
>
> Take a look at how the interop works, NV_vdpau_interop should be advertised
> if the OpenGL implementation provides the necessary functions. What and if a
> VDPAU backend gets loaded to work with that is completely independent of
> this.
>
> We want to switch over to a DMABuf based interop implementation so that we
> can get away from using the Mesa internal structures.
>
> This not only has the advantage of fixing this ugly hack, but also would
> allow an application to decode on one driver (radeonsi) and display with
> another one (r600).

If the purpose is not to conditionally not advertise based on
availability, what is the purpose of this patch?

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

[Mesa-dev] [Bug 93820] Change from Mesa 10 to 11 made remote opengl stop working

[bugzilla-daemon]

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

Ian Romanick  changed:

   What|Removed |Added

 CC||i...@freedesktop.org
 Status|NEW |NEEDINFO

--- Comment #1 from Ian Romanick  ---
Two questions:

1. Did anything else (i.e., the X server) change?

2. Are you able to bisect?

I recently noticed that after some Fedora system update a bunch of the piglit
GLX tests began to fail.  On my system, the failure occur with Mesa 10 and 11. 
I haven't had a chance to investigate it, but it's possible that the failure
you have observed is related.

-- 
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] st/mesa: conditionally enable GL_NV_vdpau_interop

[Christian König]

Form autofoo perspective things look great.

Thanks, that exactly what I wanted to know.


Although I second Ilia's concern - we need a form of runtime detection
here. Pretty much all distros ship the vdpau(+ other video driver
backend) in a separate library. Thus this will likely get us nowhere
we want - as I'm suspecting this is to assist the unsuspecting user,
which hasn't installed package X or Y in the first place ?
As I said, Mesa should NOT check what vdpau backend libraries are 
installed or used before advertising NV_vdpau_interop.


Take a look at how the interop works, NV_vdpau_interop should be 
advertised if the OpenGL implementation provides the necessary 
functions. What and if a VDPAU backend gets loaded to work with that is 
completely independent of this.


We want to switch over to a DMABuf based interop implementation so that 
we can get away from using the Mesa internal structures.


This not only has the advantage of fixing this ugly hack, but also would 
allow an application to decode on one driver (radeonsi) and display with 
another one (r600).


Regards,
Christian.

Am 22.01.2016 um 17:15 schrieb Emil Velikov:

Form autofoo perspective things look great.

Although I second Ilia's concern - we need a form of runtime detection
here. Pretty much all distros ship the vdpau(+ other video driver
backend) in a separate library. Thus this will likely get us nowhere
we want - as I'm suspecting this is to assist the unsuspecting user,
which hasn't installed package X or Y in the first place ?

I won't object against it but please can we get a big fat warning/note
- anything vaguely alike "this is a hack until we get a runtime
detection of the presence/interop of the partner library/module" will
be great.

Thanks
Emil

On 21 January 2016 at 21:02, Christian König  wrote:

Advertising NV_vdpau_interop while the backend for the driver isn't
installed is fine, cause this only means that the OpenGL side has support
for it.

Mesa doesn't have a runtime dependency on libvdpau and to initialize
NV_vdpau_interop the application must open libvdpau first.

So if libvdpau isn't installed this will fail way even before Mesa into the
picture.

My question is rather if that's the right approach? I'm not really an expert
on autohell.

Regards,
Christian.


Am 21.01.2016 um 17:09 schrieb Ilia Mirkin:

I wonder if something more robust is needed. Let's say a distro builds
with vdpau and everything else enabled, but then ships the libraries
separately...

On Thu, Jan 21, 2016 at 11:05 AM, Christian König
 wrote:

From: Christian König 

Only enable it when we compile the state tracker as well.

Signed-off-by: Christian König 
---
   configure.ac   | 1 +
   src/mesa/state_tracker/st_extensions.c | 2 ++
   src/mesa/state_tracker/st_vdpau.c  | 6 ++
   3 files changed, 9 insertions(+)

diff --git a/configure.ac b/configure.ac
index 8d19dab..a92f707 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1741,6 +1741,7 @@ AM_CONDITIONAL(HAVE_ST_XVMC, test "x$enable_xvmc" =
xyes)
   if test "x$enable_vdpau" = xyes; then
   PKG_CHECK_MODULES([VDPAU], [vdpau >= $VDPAU_REQUIRED])
   gallium_st="$gallium_st vdpau"
+DEFINES="$DEFINES -DHAVE_ST_VDPAU"
   fi
   AM_CONDITIONAL(HAVE_ST_VDPAU, test "x$enable_vdpau" = xyes)

diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 2a3e523..25e88ea 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -959,12 +959,14 @@ void st_init_extensions(struct pipe_screen *screen,
 extensions->ARB_ES3_compatibility = GL_TRUE;
  }

+#ifdef HAVE_ST_VDPAU
  if (screen->get_video_param &&
  screen->get_video_param(screen, PIPE_VIDEO_PROFILE_UNKNOWN,
  PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
  PIPE_VIDEO_CAP_SUPPORTS_INTERLACED)) {
 extensions->NV_vdpau_interop = GL_TRUE;
  }
+#endif

  if (screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
   PIPE_SHADER_CAP_DOUBLES) &&
diff --git a/src/mesa/state_tracker/st_vdpau.c
b/src/mesa/state_tracker/st_vdpau.c
index 63af119..71dd15b 100644
--- a/src/mesa/state_tracker/st_vdpau.c
+++ b/src/mesa/state_tracker/st_vdpau.c
@@ -49,6 +49,8 @@
   #include "st_format.h"
   #include "st_cb_flush.h"

+#ifdef HAVE_ST_VDPAU
+
   static void
   st_vdpau_map_surface(struct gl_context *ctx, GLenum target, GLenum
access,
GLboolean output, struct gl_texture_object
*texObj,
@@ -180,9 +182,13 @@ st_vdpau_unmap_surface(struct gl_context *ctx,
GLenum target, GLenum access,
  st_flush(st, NULL, 0);
   }

+#endif
+
   void
   st_init_vdpau_functions(struct dd_function_table *functions)
   {
+#ifdef HAVE_ST_VDPAU
  functions->VDPAUMapSurface = st_vdpau_map_surface;
  

Re: [Mesa-dev] [PATCH v2] glx: update to updated version of EXT_create_context_es2_profile

[Ilia Mirkin]

On Thu, Jan 21, 2016 at 11:58 AM, Ilia Mirkin  wrote:
> The EXT spec has been updated to:
>  - logically combine the es2_profile and es_profile exts
>  - allow any legal version to be requested
>
> dEQP tests request a specific ES version when using GLX, so this allows
> dEQP upstream to run against GLX with the appropriate X server patch
> (which had similar disabling logic).
>
> Signed-off-by: Ilia Mirkin 
> Reviewed-by: Matt Turner  (v1)
>
> v1 -> v2:
>  - distinguish between DRI_API_GLES{,2,3}
>  - add GLX_EXT_create_context_es_profile client-side support
> ---
>  src/glx/dri2_glx.c  | 11 ---
>  src/glx/dri3_glx.c  |  7 ++-
>  src/glx/dri_common.c| 28 
>  src/glx/drisw_glx.c |  4 +++-
>  src/glx/glxextensions.c |  1 +
>  src/glx/glxextensions.h |  1 +
>  6 files changed, 31 insertions(+), 21 deletions(-)
>
> diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
> index 651915a..97bf49c 100644
> --- a/src/glx/dri2_glx.c
> +++ b/src/glx/dri2_glx.c
> @@ -1102,9 +1102,14 @@ dri2BindExtensions(struct dri2_screen *psc, struct 
> glx_display * priv,
>__glXEnableDirectExtension(>base, "GLX_ARB_create_context");
>__glXEnableDirectExtension(>base, 
> "GLX_ARB_create_context_profile");
>
> -  if ((mask & (1 << __DRI_API_GLES2)) != 0)
> -__glXEnableDirectExtension(>base,
> -   "GLX_EXT_create_context_es2_profile");
> +  if ((mask & (1 << (__DRI_API_GLES |
> + __DRI_API_GLES2 |
> + __DRI_API_GLES3))) != 0) {

Of course both here and below, this should be

(1 << __DRI_API_GLES ) |
(1 << __DRI_API_GLES2) |
(1 << __DRI_API_GLES3)

oops :)

> + __glXEnableDirectExtension(>base,
> +"GLX_EXT_create_context_es_profile");
> + __glXEnableDirectExtension(>base,
> +"GLX_EXT_create_context_es2_profile");
> +  }
> }
>
> for (i = 0; extensions[i]; i++) {
> diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
> index 8bdbb9c..9952e7e 100644
> --- a/src/glx/dri3_glx.c
> +++ b/src/glx/dri3_glx.c
> @@ -665,9 +665,14 @@ dri3_bind_extensions(struct dri3_screen *psc, struct 
> glx_display * priv,
> __glXEnableDirectExtension(>base, "GLX_ARB_create_context");
> __glXEnableDirectExtension(>base, "GLX_ARB_create_context_profile");
>
> -   if ((mask & (1 << __DRI_API_GLES2)) != 0)
> +   if ((mask & (1 << (__DRI_API_GLES |
> +  __DRI_API_GLES2 |
> +  __DRI_API_GLES3))) != 0) {
> +  __glXEnableDirectExtension(>base,
> + "GLX_EXT_create_context_es_profile");
>__glXEnableDirectExtension(>base,
>   "GLX_EXT_create_context_es2_profile");
> +   }
>
> for (i = 0; extensions[i]; i++) {
>/* when on a different gpu than the server, the server pixmaps
> diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
> index 8a56385..6728d38 100644
> --- a/src/glx/dri_common.c
> +++ b/src/glx/dri_common.c
> @@ -547,9 +547,18 @@ dri2_convert_glx_attribs(unsigned num_attribs, const 
> uint32_t *attribs,
>case GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB:
>  *api = __DRI_API_OPENGL;
>  break;
> -  case GLX_CONTEXT_ES2_PROFILE_BIT_EXT:
> -*api = __DRI_API_GLES2;
> -break;
> +  case GLX_CONTEXT_ES_PROFILE_BIT_EXT:
> + if (*major_ver >= 3)
> +*api = __DRI_API_GLES3;
> + else if (*major_ver == 2 && *minor_ver == 0)
> +*api = __DRI_API_GLES2;
> + else if (*major_ver == 1 && *minor_ver < 2)
> +*api = __DRI_API_GLES;
> + else {
> +*error = __DRI_CTX_ERROR_BAD_API;
> +return false;
> + }
> + break;
>default:
>  *error = __DRI_CTX_ERROR_BAD_API;
>  return false;
> @@ -580,19 +589,6 @@ dri2_convert_glx_attribs(unsigned num_attribs, const 
> uint32_t *attribs,
>return false;
> }
>
> -   /* The GLX_EXT_create_context_es2_profile spec says:
> -*
> -* "... If the version requested is 2.0, and the
> -* GLX_CONTEXT_ES2_PROFILE_BIT_EXT bit is set in the
> -* GLX_CONTEXT_PROFILE_MASK_ARB attribute (see below), then the 
> context
> -* returned will implement OpenGL ES 2.0. This is the only way in 
> which
> -* an implementation may request an OpenGL ES 2.0 context."
> -*/
> -   if (*api == __DRI_API_GLES2 && (*major_ver != 2 || *minor_ver != 0)) {
> -  *error = __DRI_CTX_ERROR_BAD_API;
> -  return false;
> -   }
> -
> *error = __DRI_CTX_ERROR_SUCCESS;
> return true;
>  }
> diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
> index 76cc321..241ac7f 100644
> --- a/src/glx/drisw_glx.c
> +++ b/src/glx/drisw_glx.c
> @@ -623,9 +623,11 @@ driswBindExtensions(struct 

Re: [Mesa-dev] [PATCH v2] mesa: Deal with size differences between GLuint and GLhandleARB in GetAttachedObjectsARB

[Jeremy Sequoia]

Sent from my iPhone...

> On Jan 22, 2016, at 11:05, Ian Romanick  wrote:
> 
> Please revert the version of this patch that has already landed.
> 
>> On 01/21/2016 08:48 AM, Jeremy Huddleston Sequoia wrote:
>> Signed-off-by: Jeremy Huddleston Sequoia 
>> CC: Nicolai Hähnle 
>> CC: Matt Turner 
>> ---
>> src/mesa/main/shaderapi.c | 18 +-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>> 
>> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
>> index a988f41..7a0d19a 100644
>> --- a/src/mesa/main/shaderapi.c
>> +++ b/src/mesa/main/shaderapi.c
>> @@ -1374,10 +1374,26 @@ _mesa_DetachShader(GLuint program, GLuint shader)
>> 
>> void GLAPIENTRY
>> _mesa_GetAttachedObjectsARB(GLhandleARB container, GLsizei maxCount,
>> -GLsizei * count, GLhandleARB * obj)
>> +GLsizei * count, GLhandleARB * objARB)
>> {
>> +   int i;
>> +   GLuint *obj;
>> +
>>GET_CURRENT_CONTEXT(ctx);
>> +
>> +   obj = calloc(maxCount, sizeof(GLuint));
> 
> calloc is allowed to return NULL when passed 0.  glGetAttachedObjectsARB
> is not supposed to generate an error in that condition.
> 
> If passed a negative value, glGetAttachedObjectsARB is supposed to
> generate GL_INVALID_VALUE.  In this case, since calloc will treat the
> negative value as a very large positive value, it will generate
> GL_OUT_OF_MEMORY.
> 
>> +   if (!obj) {
>> +  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glShaderSourceARB");
>> +  return;
>> +   }
>> +
>>get_attached_shaders(ctx, container, maxCount, count, obj);
>> +
>> +   for (i = 0 ; i < *count; i++) {
> 
> count can be NULL, so this is completely bogus.
> 
> I will submit piglit tests for all three issues.
> 
> In addition to the bugs, this patch adds almost as much code to
> _mesa_GetAttachedObjectsARB as just open-coding get_attached_shaders
> would.  If we have to do anything, I feel like that's a much better option.

Ok.  I'll revert and send a follow up that does that then.

Thanks.

> 
>> +  objARB[i] = (GLhandleARB)obj[i];
>> +   }
>> +
>> +   free(obj);
>> }
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: conditionally enable GL_NV_vdpau_interop

[Emil Velikov]

On 22 January 2016 at 18:15, Christian König  wrote:
>> Form autofoo perspective things look great.
>
> Thanks, that exactly what I wanted to know.
>
>> Although I second Ilia's concern - we need a form of runtime detection
>> here. Pretty much all distros ship the vdpau(+ other video driver
>> backend) in a separate library. Thus this will likely get us nowhere
>> we want - as I'm suspecting this is to assist the unsuspecting user,
>> which hasn't installed package X or Y in the first place ?
>
> As I said, Mesa should NOT check what vdpau backend libraries are installed
> or used before advertising NV_vdpau_interop.
>
> Take a look at how the interop works, NV_vdpau_interop should be advertised
> if the OpenGL implementation provides the necessary functions. What and if a
> VDPAU backend gets loaded to work with that is completely independent of
> this.
>
I never said that one should check for vdpau ;-) I was thinking more
of "does the backend driver provides a way for vdpau to work" - i.e.
radeon/amdgpus and nouveau export the extra entrypoint that allows you
to share the winsys but others do not. There is also the, as you know
better than me, version (miss)-match of dri and vdapu modules, which
also should be checked at runtime ?

> We want to switch over to a DMABuf based interop implementation so that we
> can get away from using the Mesa internal structures.
>
> This not only has the advantage of fixing this ugly hack, but also would
> allow an application to decode on one driver (radeonsi) and display with
> another one (r600).
>
Moving towards dmabuf is a great thing. I was suggesting that we add a
comment/reference about the current state of things.
Seems like my example set your blood boiling - sorry about that.

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

Re: [Mesa-dev] [PATCH] st/mesa: conditionally enable GL_NV_vdpau_interop

[Christian König]

Am 22.01.2016 um 19:24 schrieb Ilia Mirkin:

On Fri, Jan 22, 2016 at 1:15 PM, Christian König
 wrote:

Form autofoo perspective things look great.

Thanks, that exactly what I wanted to know.


Although I second Ilia's concern - we need a form of runtime detection
here. Pretty much all distros ship the vdpau(+ other video driver
backend) in a separate library. Thus this will likely get us nowhere
we want - as I'm suspecting this is to assist the unsuspecting user,
which hasn't installed package X or Y in the first place ?

As I said, Mesa should NOT check what vdpau backend libraries are installed
or used before advertising NV_vdpau_interop.

Take a look at how the interop works, NV_vdpau_interop should be advertised
if the OpenGL implementation provides the necessary functions. What and if a
VDPAU backend gets loaded to work with that is completely independent of
this.

We want to switch over to a DMABuf based interop implementation so that we
can get away from using the Mesa internal structures.

This not only has the advantage of fixing this ugly hack, but also would
allow an application to decode on one driver (radeonsi) and display with
another one (r600).

If the purpose is not to conditionally not advertise based on
availability, what is the purpose of this patch?


To check if we compile the state tracker as well and so fulfill the 
dependencies of the state tracker.


E.g. for example for a DMABuf based interop I might need some defines 
from the VDPAU headers.


The alternative is to make the OpenGL implementation depend on the 
presence of libvdpau directly, but I had the feeling that this approach 
would be more convenient.


Sorry for the confusion, I never intended to make any this an extra 
check for the unsuspecting user. But rather just solve the dependencies 
without checking for libvdpau twice.


I should have probably better explained that in the first place.

Regards,
Christian.



   -ilia


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

[Mesa-dev] Mesa 11.0.9

[Emil Velikov]

[Resend with mesa-announce email fixed]

Mesa 11.0.9 is now available.

The present release addresses some important driver issues - nouveau
(sluggish 4K decoding, pushbuf/bufctx management), i965 (EGL crash),
r600 (severge glitches in Soma), amongst others and plugs a few
memory leaks.

NOTE: It is anticipated that 11.0.9 will be the final release in the 11.0
series. Users of 11.0 are encouraged to migrate to the 11.1 series in order
to obtain future fixes.


Emil Velikov (7):
  docs: add sha256 checksums for 11.0.8
  cherry-ignore: add patch already in branch
  cherry-ignore: add the dri3 glx null check patch
  i915: correctly parse/set the context flags
  egl/dri2: expose srgb configs when KHR_gl_colorspace is available
  Update version to 11.0.9
  docs: add release notes for 11.0.9

Grazvydas Ignotas (1):
  r600: fix constant buffer size programming

Ilia Mirkin (5):
  nvc0: don't forget to reset VTX_TMP bufctx slot after blit completion
  nv50/ir: float(s32 & 0xff) = float(u8), not s8
  nv50,nvc0: make sure there's pushbuf space and that we ref the bo early
  nv50,nvc0: fix crash when increasing bsp bo size for h264
  nvc0: scale up inter_bo size so that it's 16M for a 4K video

Kenneth Graunke (2):
  ralloc: Fix ralloc_adopt() to the old context's last child's parent.
  nvc0: Set winding order regardless of domain.

Marek Olšák (1):
  radeonsi: don't miss changes to SPI_TMPRING_SIZE

Miklós Máté (1):
  mesa: Don't leak ATIfs instructions in DeleteFragmentShader

Neil Roberts (1):
  i965: Fix crash when calling glViewport with no surface bound

Nicolai Hähnle (6):
  gallium/radeon: only dispose locally created target machine in 
radeon_llvm_compile
  mesa/bufferobj: make _mesa_delete_buffer_object externally accessible
  st/mesa: use _mesa_delete_buffer_object
  radeon: use _mesa_delete_buffer_object
  i915: use _mesa_delete_buffer_object
  i965: use _mesa_delete_buffer_object

Oded Gabbay (1):
  llvmpipe: use vpkswss when dst is signed

Rob Herring (1):
  freedreno/ir3: fix 32-bit builds with pointer-to-int-cast error enabled


git tag: mesa-11.0.9

ftp://ftp.freedesktop.org/pub/mesa/11.0.9/mesa-11.0.9.tar.gz
MD5: 872cf1c1d922c7b34021e7135aed3062  mesa-11.0.9.tar.gz
SHA1: fc7045d49ef5fdda5f4efa8464e24ccdce36a9be  mesa-11.0.9.tar.gz
SHA256: 1597c2e983f476f98efdd6cd58b5298896d18479ff542bdeff28b98b129ede05  
mesa-11.0.9.tar.gz
PGP: ftp://ftp.freedesktop.org/pub/mesa/11.0.9/mesa-11.0.9.tar.gz.sig

ftp://ftp.freedesktop.org/pub/mesa/11.0.9/mesa-11.0.9.tar.xz
MD5: b8937e834d0113f18ae83c32dd0adca7  mesa-11.0.9.tar.xz
SHA1: be9605b087f60adaaa3d3cd26ddba341e683  mesa-11.0.9.tar.xz
SHA256: a1262ff1c66a16ccf341186cf0e57b306b8589eb2cc5ce92ffb6788ab01d2b01  
mesa-11.0.9.tar.xz
PGP: ftp://ftp.freedesktop.org/pub/mesa/11.0.9/mesa-11.0.9.tar.xz.sig

--
Emil



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 v2] mesa: Deal with size differences between GLuint and GLhandleARB in GetAttachedObjectsARB

[Ian Romanick]

Please revert the version of this patch that has already landed.

On 01/21/2016 08:48 AM, Jeremy Huddleston Sequoia wrote:
> Signed-off-by: Jeremy Huddleston Sequoia 
> CC: Nicolai Hähnle 
> CC: Matt Turner 
> ---
>  src/mesa/main/shaderapi.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index a988f41..7a0d19a 100644
> --- a/src/mesa/main/shaderapi.c
> +++ b/src/mesa/main/shaderapi.c
> @@ -1374,10 +1374,26 @@ _mesa_DetachShader(GLuint program, GLuint shader)
>  
>  void GLAPIENTRY
>  _mesa_GetAttachedObjectsARB(GLhandleARB container, GLsizei maxCount,
> -GLsizei * count, GLhandleARB * obj)
> +GLsizei * count, GLhandleARB * objARB)
>  {
> +   int i;
> +   GLuint *obj;
> +
> GET_CURRENT_CONTEXT(ctx);
> +
> +   obj = calloc(maxCount, sizeof(GLuint));

calloc is allowed to return NULL when passed 0.  glGetAttachedObjectsARB
is not supposed to generate an error in that condition.

If passed a negative value, glGetAttachedObjectsARB is supposed to
generate GL_INVALID_VALUE.  In this case, since calloc will treat the
negative value as a very large positive value, it will generate
GL_OUT_OF_MEMORY.

> +   if (!obj) {
> +  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glShaderSourceARB");
> +  return;
> +   }
> +
> get_attached_shaders(ctx, container, maxCount, count, obj);
> +
> +   for (i = 0 ; i < *count; i++) {

count can be NULL, so this is completely bogus.

I will submit piglit tests for all three issues.

In addition to the bugs, this patch adds almost as much code to
_mesa_GetAttachedObjectsARB as just open-coding get_attached_shaders
would.  If we have to do anything, I feel like that's a much better option.

> +  objARB[i] = (GLhandleARB)obj[i];
> +   }
> +
> +   free(obj);
>  }
>  
>  

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

[Mesa-dev] Mesa 11.0.9

[Emil Velikov]

Mesa 11.0.9 is now available.

The present release addresses some important driver issues - nouveau
(sluggish 4K decoding, pushbuf/bufctx management), i965 (EGL crash),
r600 (severge glitches in Soma), amongst others and plugs a few
memory leaks.

NOTE: It is anticipated that 11.0.9 will be the final release in the 11.0
series. Users of 11.0 are encouraged to migrate to the 11.1 series in order
to obtain future fixes.


Emil Velikov (7):
  docs: add sha256 checksums for 11.0.8
  cherry-ignore: add patch already in branch
  cherry-ignore: add the dri3 glx null check patch
  i915: correctly parse/set the context flags
  egl/dri2: expose srgb configs when KHR_gl_colorspace is available
  Update version to 11.0.9
  docs: add release notes for 11.0.9

Grazvydas Ignotas (1):
  r600: fix constant buffer size programming

Ilia Mirkin (5):
  nvc0: don't forget to reset VTX_TMP bufctx slot after blit completion
  nv50/ir: float(s32 & 0xff) = float(u8), not s8
  nv50,nvc0: make sure there's pushbuf space and that we ref the bo early
  nv50,nvc0: fix crash when increasing bsp bo size for h264
  nvc0: scale up inter_bo size so that it's 16M for a 4K video

Kenneth Graunke (2):
  ralloc: Fix ralloc_adopt() to the old context's last child's parent.
  nvc0: Set winding order regardless of domain.

Marek Olšák (1):
  radeonsi: don't miss changes to SPI_TMPRING_SIZE

Miklós Máté (1):
  mesa: Don't leak ATIfs instructions in DeleteFragmentShader

Neil Roberts (1):
  i965: Fix crash when calling glViewport with no surface bound

Nicolai Hähnle (6):
  gallium/radeon: only dispose locally created target machine in 
radeon_llvm_compile
  mesa/bufferobj: make _mesa_delete_buffer_object externally accessible
  st/mesa: use _mesa_delete_buffer_object
  radeon: use _mesa_delete_buffer_object
  i915: use _mesa_delete_buffer_object
  i965: use _mesa_delete_buffer_object

Oded Gabbay (1):
  llvmpipe: use vpkswss when dst is signed

Rob Herring (1):
  freedreno/ir3: fix 32-bit builds with pointer-to-int-cast error enabled


git tag: mesa-11.0.9

ftp://ftp.freedesktop.org/pub/mesa/11.0.9/mesa-11.0.9.tar.gz
MD5: 872cf1c1d922c7b34021e7135aed3062  mesa-11.0.9.tar.gz
SHA1: fc7045d49ef5fdda5f4efa8464e24ccdce36a9be  mesa-11.0.9.tar.gz
SHA256: 1597c2e983f476f98efdd6cd58b5298896d18479ff542bdeff28b98b129ede05  
mesa-11.0.9.tar.gz
PGP: ftp://ftp.freedesktop.org/pub/mesa/11.0.9/mesa-11.0.9.tar.gz.sig

ftp://ftp.freedesktop.org/pub/mesa/11.0.9/mesa-11.0.9.tar.xz
MD5: b8937e834d0113f18ae83c32dd0adca7  mesa-11.0.9.tar.xz
SHA1: be9605b087f60adaaa3d3cd26ddba341e683  mesa-11.0.9.tar.xz
SHA256: a1262ff1c66a16ccf341186cf0e57b306b8589eb2cc5ce92ffb6788ab01d2b01  
mesa-11.0.9.tar.xz
PGP: ftp://ftp.freedesktop.org/pub/mesa/11.0.9/mesa-11.0.9.tar.xz.sig

--
Emil



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 5/4] mesa: Refactor error checking for GL_TEXTURE_BASE_LEVEL vs texture targets

[Ian Romanick]

On 01/21/2016 12:15 PM, Jason Ekstrand wrote:
> 
> On Jan 21, 2016 10:30 AM, "Ian Romanick"  > wrote:
>>
>> On 01/20/2016 08:29 PM, Jason Ekstrand wrote:
>> >
>> > On Jan 20, 2016 6:20 PM, "Ian Romanick"  
>> > >> wrote:
>> >>
>> >> From: Ian Romanick  
>> > >>
>> >>
>> >> Add a big spec quotation justifying the error generated, which has
>> >> changed over the GL versions.
>> >>
>> >> Signed-off-by: Ian Romanick  
>> > >>
>> >> ---
>> >>
>> >> I intended to send this out with the other four, but I selected the
>> >> wrong SHA from the list.
>> >>
>> >>  src/mesa/main/texparam.c | 31 ---
>> >>  1 file changed, 24 insertions(+), 7 deletions(-)
>> >>
>> >> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
>> >> index 89f286c..ee50b5a 100644
>> >> --- a/src/mesa/main/texparam.c
>> >> +++ b/src/mesa/main/texparam.c
>> >> @@ -369,8 +369,31 @@ set_tex_parameteri(struct gl_context *ctx,
>> >>if (texObj->BaseLevel == params[0])
>> >>   return GL_FALSE;
>> >>
>> >> +  /* Section 8.10 (Texture Parameters) of the OpenGL 4.5 Core
>> > Profile spec
>> >> +   * says:
>> >> +   *
>> >> +   * "An INVALID_OPERATION error is generated if the
>> > effective target
>> >> +   * is either TEXTURE_2D_MULTISAMPLE or
>> > TEXTURE_2D_MULTISAMPLE_ARRAY,
>> >> +   * and pname TEXTURE_BASE_LEVEL is set to a value other
>> > than zero.
>> >> +   *
>> >> +   * ...
>> >> +   *
>> >> +   * An INVALID_OPERATION error is generated if the effective
>> > target
>> >> +   * is TEXTURE_RECTANGLE and pname TEXTURE_BASE_LEVEL is set
>> > to any
>> >> +   * value other than zero."
>> >
>> > Do we really need the "pname"s?  IMHO, they make it harder to read.
>>
>> I'm not sure what you mean.  The pnames in the spec quote or ... ?
> 
> Yes. Some versions of the spec have them and some don't.  The quote
> below, for instance, doesn't.

From 4.1 to 4.2 the format of the spec was completely changed.  In 4.1
an earlier, the errors were mixed with the prose.  There was a lot of
inconsistency and missing errors as a result.  In 4.2 and later, the
errors are listed in a break-out box at the end of the section.  Having
had to scrape through the spec countless times to find all the possible
error cases for a new command over the years, this is a very welcome change.

In truth, I should have quoted a bit more text below because it doesn't
qualify the conditions in which the old error code were generated.  It's
just some text buried in the paragraph about TEXTURE_RECTANGLE.  For
clarity, I probably should have quoted more context.

"When target is TEXTURE_RECTANGLE, certain texture parameter
values may not be specified The error INVALID_VALUE is
generated if TEXTURE_BASE_LEVEL is set to any value other than
zero."

TEXTURE_2D_MULTISAMPLE and TEXTURE_2D_MULTISAMPLE_ARRAY did not exist in
3.3, so they are not mentioned.  I didn't quote additional context only
because I was only trying to highlight that the error had changed from
INVALID_VALUE to INVALID_OPERATION since 3.3.

What I think makes the 4.5 quotation unfortunate is that the two nearly
identical errors are listed in separate bullets.  This is compounded by
the slight differences in language ("a value" vs "any value").  I have
submitted a Khronos bug with a patch for this issue.  My compacted
wording is:

An INVALID_OPERATION error is generated if the effective target
is TEXTURE_2D_MULTISAMPLE, TEXTURE_2D_MULTISAMPLE_ARRAY, or
TEXTURE_RECTANGLE, and pname TEXTURE_BASE_LEVEL is set to a value
other than zero.

The existing TEXTURE_RECTANGLE bullet is removed.

The whole point of quoting the spec is to justify the code. For that to
be effective, the quotation has to have enough context.  I'm not sure
what we'd trim without weakening that justification.  If we remove one
of the bullets, why is the error generated for the other cases?  If we
remove the pnames from the bullets, why aren't we generating the error
for other cases?

We're trying to reduce the amount of time our future selves have to look
back through the specs when a bug is submitted for a buggy application
or conformance test. :)

I'm not in a big hurry on this patch, so I'm willing to wait until
there's some response on the spec bug.  Assuming the response is
positive, is using the amended wording in the quotation a good compromise?

>> > Other than that, the series looks good.
>> >
>> > Reviewed-by: Jason Ekstrand  

Re: [Mesa-dev] [PATCH 2/2] st/mesa: enable OES_geometry_shader if GLSL 1.50 is supported

[Ilia Mirkin]

Actually I'm sorry, I just realized this patch is bogus.
OES_geometry_shader includes GS instancing, for which there isn't a
separate PIPE_CAP. Probably just make it conditional on
ARB_gpu_shader5 being enabled then.

First patch still makes sense though.

  -ilia

On Fri, Jan 22, 2016 at 1:21 PM, Ilia Mirkin  wrote:
> Signed-off-by: Ilia Mirkin 
> ---
>  src/mesa/state_tracker/st_extensions.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index 01ba015..af99f5b 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -764,6 +764,9 @@ void st_init_extensions(struct pipe_screen *screen,
>extensions->AMD_vertex_shader_layer = GL_TRUE;
> }
>
> +   if (consts->GLSLVersion >= 150)
> +  extensions->OES_geometry_shader = GL_TRUE;
> +
> if (consts->GLSLVersion >= 130) {
>consts->NativeIntegers = GL_TRUE;
>consts->MaxClipPlanes = 8;
> --
> 2.4.10
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: conditionally enable GL_NV_vdpau_interop

[Ilia Mirkin]

On Fri, Jan 22, 2016 at 2:11 PM, Christian König
 wrote:
> Am 22.01.2016 um 19:24 schrieb Ilia Mirkin:
>>
>> On Fri, Jan 22, 2016 at 1:15 PM, Christian König
>>  wrote:

 Form autofoo perspective things look great.
>>>
>>> Thanks, that exactly what I wanted to know.
>>>
 Although I second Ilia's concern - we need a form of runtime detection
 here. Pretty much all distros ship the vdpau(+ other video driver
 backend) in a separate library. Thus this will likely get us nowhere
 we want - as I'm suspecting this is to assist the unsuspecting user,
 which hasn't installed package X or Y in the first place ?
>>>
>>> As I said, Mesa should NOT check what vdpau backend libraries are
>>> installed
>>> or used before advertising NV_vdpau_interop.
>>>
>>> Take a look at how the interop works, NV_vdpau_interop should be
>>> advertised
>>> if the OpenGL implementation provides the necessary functions. What and
>>> if a
>>> VDPAU backend gets loaded to work with that is completely independent of
>>> this.
>>>
>>> We want to switch over to a DMABuf based interop implementation so that
>>> we
>>> can get away from using the Mesa internal structures.
>>>
>>> This not only has the advantage of fixing this ugly hack, but also would
>>> allow an application to decode on one driver (radeonsi) and display with
>>> another one (r600).
>>
>> If the purpose is not to conditionally not advertise based on
>> availability, what is the purpose of this patch?
>
>
> To check if we compile the state tracker as well and so fulfill the
> dependencies of the state tracker.
>
> E.g. for example for a DMABuf based interop I might need some defines from
> the VDPAU headers.
>
> The alternative is to make the OpenGL implementation depend on the presence
> of libvdpau directly, but I had the feeling that this approach would be more
> convenient.
>
> Sorry for the confusion, I never intended to make any this an extra check
> for the unsuspecting user. But rather just solve the dependencies without
> checking for libvdpau twice.
>
> I should have probably better explained that in the first place.

Aha I see, so this is a prelude to some changes you'd like to make
that would cause various breakage if you didn't also have all the
vdpau stuff being built.

In that case, this is Reviewed-by: Ilia Mirkin 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] configure.ac: don't require EGL/DRM ang GBM if OpenGL is disabled

[Marek Olšák]

Hi Emil,

Do you have any comment on this series?

Marek

On Tue, Jan 12, 2016 at 8:46 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> This allows building VDPAU/OMX/VA drivers without OpenGL and its
> dependencies.
> ---
>  configure.ac | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 8d19dab..04b5fd8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2159,7 +2159,12 @@ gallium_require_drm_loader() {
>  fi
>  }
>
> +dnl This is for Glamor. Skip this if OpenGL is disabled.
>  require_egl_drm() {
> +if test "x$enable_opengl" = xno; then
> +return 0
> +fi
> +
>  case "$with_egl_platforms" in
>  *drm*)
>  ;;
> --
> 2.1.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: fix discard-only fragment shaders (v2)

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Thu, Jan 21, 2016 at 4:06 AM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> When a fragment shader is used that has no outputs but does conditional
> discard (KILL_IF), all fragments are killed without this patch.
>
> By comparing various register settings, my conclusion is that the exec mask
> is either not properly forwarded to the DB by NULL exports or ends up being
> unused, at least when there is _only_ a NULL export (the ISA documentation
> claims that NULL exports can be used to override a previously exported exec
> mask).
>
> Of the various approaches I have tried to work around the problem, this one
> seems to be the least invasive one.
>
> v2: take discard by alpha test into account as well
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93761
> ---
>  src/gallium/drivers/radeonsi/si_state_shaders.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
> b/src/gallium/drivers/radeonsi/si_state_shaders.c
> index 8ff70b4..807c9e2 100644
> --- a/src/gallium/drivers/radeonsi/si_state_shaders.c
> +++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
> @@ -393,6 +393,7 @@ static void si_shader_ps(struct si_shader *shader)
> unsigned spi_baryc_cntl = S_0286E0_FRONT_FACE_ALL_BITS(1);
> uint64_t va;
> bool has_centroid;
> +   bool writes_execmask;
>
> pm4 = shader->pm4 = CALLOC_STRUCT(si_pm4_state);
>
> @@ -452,10 +453,13 @@ static void si_shader_ps(struct si_shader *shader)
> si_pm4_set_reg(pm4, R_0286E0_SPI_BARYC_CNTL, spi_baryc_cntl);
> si_pm4_set_reg(pm4, R_0286D8_SPI_PS_IN_CONTROL, spi_ps_in_control);
>
> +   writes_execmask = info->uses_kill ||
> + shader->key.ps.alpha_func != PIPE_FUNC_ALWAYS;
> si_pm4_set_reg(pm4, R_028710_SPI_SHADER_Z_FORMAT,
>info->writes_samplemask ? V_028710_SPI_SHADER_32_ABGR :
>info->writes_stencil ? V_028710_SPI_SHADER_32_GR :
>info->writes_z ? V_028710_SPI_SHADER_32_R :
> +  (writes_execmask && !info->num_outputs) ? 
> V_028710_SPI_SHADER_32_R :
>V_028710_SPI_SHADER_ZERO);
>
> si_pm4_set_reg(pm4, R_028714_SPI_SHADER_COL_FORMAT, 
> spi_shader_col_format);
> --
> 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 v2] glsl: Enable debug prints for do_common_optimization

[Timothy Arceri]

On Thu, 2016-01-21 at 23:35 -0800, Jordan Justen wrote:
> Signed-off-by: Jordan Justen 
> ---
> 
>  I tested a release build. I think v1 produced comparable code to
>  before the patch, but it was a bit larger. I found that this v2 code
>  would produce identical code to our current code for release builds.
> 
>  Timothy, should I add your r-b for v2?

Yes, looks good to me.

> 
>  src/glsl/glsl_parser_extras.cpp | 81 +--
> --
>  1 file changed, 49 insertions(+), 32 deletions(-)
> 
> diff --git a/src/glsl/glsl_parser_extras.cpp
> b/src/glsl/glsl_parser_extras.cpp
> index 1d74db5..1c1bf78 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -1864,59 +1864,76 @@ do_common_optimization(exec_list *ir, bool
> linked,
> const struct gl_shader_compiler_options
> *options,
> bool native_integers)
>  {
> +   const bool debug = false;
> GLboolean progress = GL_FALSE;
>  
> -   progress = lower_instructions(ir, SUB_TO_ADD_NEG) || progress;
> +#define OPT(PASS, ...) do { \
> +  if (debug) {  \
> + printf("START GLSL optimization %s\n", #PASS); \
> + const bool opt_progress = PASS(__VA_ARGS__);   \
> + progress = opt_progress || progress;   \
> + if (opt_progress)  \
> +_mesa_print_ir(stdout, ir, NULL);   \
> + printf("GLSL optimization %s: %s progress\n",  \
> +#PASS, opt_progress ? "made" : "no");   \
> +  } else {  \
> + progress = PASS(__VA_ARGS__) || progress;  \
> +  } \
> +   } while (false)
> +
> +   OPT(lower_instructions, ir, SUB_TO_ADD_NEG);
>  
> if (linked) {
> -  progress = do_function_inlining(ir) || progress;
> -  progress = do_dead_functions(ir) || progress;
> -  progress = do_structure_splitting(ir) || progress;
> +  OPT(do_function_inlining, ir);
> +  OPT(do_dead_functions, ir);
> +  OPT(do_structure_splitting, ir);
> }
> -   progress = do_if_simplification(ir) || progress;
> -   progress = opt_flatten_nested_if_blocks(ir) || progress;
> -   progress = opt_conditional_discard(ir) || progress;
> -   progress = do_copy_propagation(ir) || progress;
> -   progress = do_copy_propagation_elements(ir) || progress;
> +   OPT(do_if_simplification, ir);
> +   OPT(opt_flatten_nested_if_blocks, ir);
> +   OPT(opt_conditional_discard, ir);
> +   OPT(do_copy_propagation, ir);
> +   OPT(do_copy_propagation_elements, ir);
>  
> if (options->OptimizeForAOS && !linked)
> -  progress = opt_flip_matrices(ir) || progress;
> +  OPT(opt_flip_matrices, ir);
>  
> if (linked && options->OptimizeForAOS) {
> -  progress = do_vectorize(ir) || progress;
> +  OPT(do_vectorize, ir);
> }
>  
> if (linked)
> -  progress = do_dead_code(ir, uniform_locations_assigned) ||
> progress;
> +  OPT(do_dead_code, ir, uniform_locations_assigned);
> else
> -  progress = do_dead_code_unlinked(ir) || progress;
> -   progress = do_dead_code_local(ir) || progress;
> -   progress = do_tree_grafting(ir) || progress;
> -   progress = do_constant_propagation(ir) || progress;
> +  OPT(do_dead_code_unlinked, ir);
> +   OPT(do_dead_code_local, ir);
> +   OPT(do_tree_grafting, ir);
> +   OPT(do_constant_propagation, ir);
> if (linked)
> -  progress = do_constant_variable(ir) || progress;
> +  OPT(do_constant_variable, ir);
> else
> -  progress = do_constant_variable_unlinked(ir) || progress;
> -   progress = do_constant_folding(ir) || progress;
> -   progress = do_minmax_prune(ir) || progress;
> -   progress = do_rebalance_tree(ir) || progress;
> -   progress = do_algebraic(ir, native_integers, options) ||
> progress;
> -   progress = do_lower_jumps(ir) || progress;
> -   progress = do_vec_index_to_swizzle(ir) || progress;
> -   progress = lower_vector_insert(ir, false) || progress;
> -   progress = do_swizzle_swizzle(ir) || progress;
> -   progress = do_noop_swizzle(ir) || progress;
> -
> -   progress = optimize_split_arrays(ir, linked) || progress;
> -   progress = optimize_redundant_jumps(ir) || progress;
> +  OPT(do_constant_variable_unlinked, ir);
> +   OPT(do_constant_folding, ir);
> +   OPT(do_minmax_prune, ir);
> +   OPT(do_rebalance_tree, ir);
> +   OPT(do_algebraic, ir, native_integers, options);
> +   OPT(do_lower_jumps, ir);
> +   OPT(do_vec_index_to_swizzle, ir);
> +   OPT(lower_vector_insert, ir, false);
> +   OPT(do_swizzle_swizzle, ir);
> +   OPT(do_noop_swizzle, ir);
> +
> +   OPT(optimize_split_arrays, ir, linked);
> +   OPT(optimize_redundant_jumps, ir);
>  
> loop_state *ls = 

Re: [Mesa-dev] [PATCH] st/mesa: conditionally enable GL_NV_vdpau_interop

[Marek Olšák]

Reviewed-by: Marek Olšák 

Emil might want to comment on the configure.ac change.

Marek

On Thu, Jan 21, 2016 at 5:05 PM, Christian König
 wrote:
> From: Christian König 
>
> Only enable it when we compile the state tracker as well.
>
> Signed-off-by: Christian König 
> ---
>  configure.ac   | 1 +
>  src/mesa/state_tracker/st_extensions.c | 2 ++
>  src/mesa/state_tracker/st_vdpau.c  | 6 ++
>  3 files changed, 9 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 8d19dab..a92f707 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1741,6 +1741,7 @@ AM_CONDITIONAL(HAVE_ST_XVMC, test "x$enable_xvmc" = 
> xyes)
>  if test "x$enable_vdpau" = xyes; then
>  PKG_CHECK_MODULES([VDPAU], [vdpau >= $VDPAU_REQUIRED])
>  gallium_st="$gallium_st vdpau"
> +DEFINES="$DEFINES -DHAVE_ST_VDPAU"
>  fi
>  AM_CONDITIONAL(HAVE_ST_VDPAU, test "x$enable_vdpau" = xyes)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index 2a3e523..25e88ea 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -959,12 +959,14 @@ void st_init_extensions(struct pipe_screen *screen,
>extensions->ARB_ES3_compatibility = GL_TRUE;
> }
>
> +#ifdef HAVE_ST_VDPAU
> if (screen->get_video_param &&
> screen->get_video_param(screen, PIPE_VIDEO_PROFILE_UNKNOWN,
> PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
> PIPE_VIDEO_CAP_SUPPORTS_INTERLACED)) {
>extensions->NV_vdpau_interop = GL_TRUE;
> }
> +#endif
>
> if (screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
>  PIPE_SHADER_CAP_DOUBLES) &&
> diff --git a/src/mesa/state_tracker/st_vdpau.c 
> b/src/mesa/state_tracker/st_vdpau.c
> index 63af119..71dd15b 100644
> --- a/src/mesa/state_tracker/st_vdpau.c
> +++ b/src/mesa/state_tracker/st_vdpau.c
> @@ -49,6 +49,8 @@
>  #include "st_format.h"
>  #include "st_cb_flush.h"
>
> +#ifdef HAVE_ST_VDPAU
> +
>  static void
>  st_vdpau_map_surface(struct gl_context *ctx, GLenum target, GLenum access,
>   GLboolean output, struct gl_texture_object *texObj,
> @@ -180,9 +182,13 @@ st_vdpau_unmap_surface(struct gl_context *ctx, GLenum 
> target, GLenum access,
> st_flush(st, NULL, 0);
>  }
>
> +#endif
> +
>  void
>  st_init_vdpau_functions(struct dd_function_table *functions)
>  {
> +#ifdef HAVE_ST_VDPAU
> functions->VDPAUMapSurface = st_vdpau_map_surface;
> functions->VDPAUUnmapSurface = st_vdpau_unmap_surface;
> +#endif
>  }
> --
> 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] glsl: Disable tree grafting optimization for shared variables

[Iago Toral]

Right, we had to do the same for buffer variables to prevent losing
writes to the underlying buffer.

Reviewed-by: Iago Toral Quiroga 

On Thu, 2016-01-21 at 16:47 -0800, Jordan Justen wrote:
> Fixes: dEQP-GLES31.functional.compute.basic.shared_atomic_op_multiple_groups
> 
> From: https://android.googlesource.com/platform/external/deqp
> 
> Reported-by: Ilia Mirkin 
> Signed-off-by: Jordan Justen 
> ---
>  src/glsl/opt_tree_grafting.cpp | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/src/glsl/opt_tree_grafting.cpp b/src/glsl/opt_tree_grafting.cpp
> index cd58213..e4b72b6 100644
> --- a/src/glsl/opt_tree_grafting.cpp
> +++ b/src/glsl/opt_tree_grafting.cpp
> @@ -361,11 +361,12 @@ tree_grafting_basic_block(ir_instruction *bb_first,
>if (!lhs_var)
>continue;
>  
> -   if (lhs_var->data.mode == ir_var_function_out ||
> -   lhs_var->data.mode == ir_var_function_inout ||
> -   lhs_var->data.mode == ir_var_shader_out ||
> -   lhs_var->data.mode == ir_var_shader_storage)
> -  continue;
> +  if (lhs_var->data.mode == ir_var_function_out ||
> +  lhs_var->data.mode == ir_var_function_inout ||
> +  lhs_var->data.mode == ir_var_shader_out ||
> +  lhs_var->data.mode == ir_var_shader_storage ||
> +  lhs_var->data.mode == ir_var_shader_shared)
> + continue;
>  
>ir_variable_refcount_entry *entry = 
> info->refs->get_variable_entry(lhs_var);
>  


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

Re: [Mesa-dev] [PATCH v2] glsl: Enable debug prints for do_common_optimization

[Iago Toral]

Reviewed-by: Iago Toral Quiroga 

On Thu, 2016-01-21 at 23:35 -0800, Jordan Justen wrote:
> Signed-off-by: Jordan Justen 
> ---
> 
>  I tested a release build. I think v1 produced comparable code to
>  before the patch, but it was a bit larger. I found that this v2 code
>  would produce identical code to our current code for release builds.
> 
>  Timothy, should I add your r-b for v2?
> 
>  src/glsl/glsl_parser_extras.cpp | 81 
> +
>  1 file changed, 49 insertions(+), 32 deletions(-)
> 
> diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
> index 1d74db5..1c1bf78 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -1864,59 +1864,76 @@ do_common_optimization(exec_list *ir, bool linked,
> const struct gl_shader_compiler_options *options,
> bool native_integers)
>  {
> +   const bool debug = false;
> GLboolean progress = GL_FALSE;
>  
> -   progress = lower_instructions(ir, SUB_TO_ADD_NEG) || progress;
> +#define OPT(PASS, ...) do { \
> +  if (debug) {  \
> + printf("START GLSL optimization %s\n", #PASS); \
> + const bool opt_progress = PASS(__VA_ARGS__);   \
> + progress = opt_progress || progress;   \
> + if (opt_progress)  \
> +_mesa_print_ir(stdout, ir, NULL);   \
> + printf("GLSL optimization %s: %s progress\n",  \
> +#PASS, opt_progress ? "made" : "no");   \
> +  } else {  \
> + progress = PASS(__VA_ARGS__) || progress;  \
> +  } \
> +   } while (false)
> +
> +   OPT(lower_instructions, ir, SUB_TO_ADD_NEG);
>  
> if (linked) {
> -  progress = do_function_inlining(ir) || progress;
> -  progress = do_dead_functions(ir) || progress;
> -  progress = do_structure_splitting(ir) || progress;
> +  OPT(do_function_inlining, ir);
> +  OPT(do_dead_functions, ir);
> +  OPT(do_structure_splitting, ir);
> }
> -   progress = do_if_simplification(ir) || progress;
> -   progress = opt_flatten_nested_if_blocks(ir) || progress;
> -   progress = opt_conditional_discard(ir) || progress;
> -   progress = do_copy_propagation(ir) || progress;
> -   progress = do_copy_propagation_elements(ir) || progress;
> +   OPT(do_if_simplification, ir);
> +   OPT(opt_flatten_nested_if_blocks, ir);
> +   OPT(opt_conditional_discard, ir);
> +   OPT(do_copy_propagation, ir);
> +   OPT(do_copy_propagation_elements, ir);
>  
> if (options->OptimizeForAOS && !linked)
> -  progress = opt_flip_matrices(ir) || progress;
> +  OPT(opt_flip_matrices, ir);
>  
> if (linked && options->OptimizeForAOS) {
> -  progress = do_vectorize(ir) || progress;
> +  OPT(do_vectorize, ir);
> }
>  
> if (linked)
> -  progress = do_dead_code(ir, uniform_locations_assigned) || progress;
> +  OPT(do_dead_code, ir, uniform_locations_assigned);
> else
> -  progress = do_dead_code_unlinked(ir) || progress;
> -   progress = do_dead_code_local(ir) || progress;
> -   progress = do_tree_grafting(ir) || progress;
> -   progress = do_constant_propagation(ir) || progress;
> +  OPT(do_dead_code_unlinked, ir);
> +   OPT(do_dead_code_local, ir);
> +   OPT(do_tree_grafting, ir);
> +   OPT(do_constant_propagation, ir);
> if (linked)
> -  progress = do_constant_variable(ir) || progress;
> +  OPT(do_constant_variable, ir);
> else
> -  progress = do_constant_variable_unlinked(ir) || progress;
> -   progress = do_constant_folding(ir) || progress;
> -   progress = do_minmax_prune(ir) || progress;
> -   progress = do_rebalance_tree(ir) || progress;
> -   progress = do_algebraic(ir, native_integers, options) || progress;
> -   progress = do_lower_jumps(ir) || progress;
> -   progress = do_vec_index_to_swizzle(ir) || progress;
> -   progress = lower_vector_insert(ir, false) || progress;
> -   progress = do_swizzle_swizzle(ir) || progress;
> -   progress = do_noop_swizzle(ir) || progress;
> -
> -   progress = optimize_split_arrays(ir, linked) || progress;
> -   progress = optimize_redundant_jumps(ir) || progress;
> +  OPT(do_constant_variable_unlinked, ir);
> +   OPT(do_constant_folding, ir);
> +   OPT(do_minmax_prune, ir);
> +   OPT(do_rebalance_tree, ir);
> +   OPT(do_algebraic, ir, native_integers, options);
> +   OPT(do_lower_jumps, ir);
> +   OPT(do_vec_index_to_swizzle, ir);
> +   OPT(lower_vector_insert, ir, false);
> +   OPT(do_swizzle_swizzle, ir);
> +   OPT(do_noop_swizzle, ir);
> +
> +   OPT(optimize_split_arrays, ir, linked);
> +   OPT(optimize_redundant_jumps, ir);
>  
> loop_state *ls = 

[Mesa-dev] [Bug 93820] Change from Mesa 10 to 11 made remote opengl stop working

[bugzilla-daemon]

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

Bug ID: 93820
   Summary: Change from Mesa 10 to 11 made remote opengl stop
working
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: GLX
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: we...@wsoptics.de
QA Contact: mesa-dev@lists.freedesktop.org

We have thin clients that run on Intel NUCs.  With Mesa 10, remote opengl
rendering works fine (see glxinfo output below).

With Mesa 11, calling glxinfo results in a GLXBadContext.

Is there something I can do to provide more debug information?

Thanks


glxinfo output:

name of display: 192.168.3.117:7
display: 192.168.3.117:7  screen: 0
direct rendering: No (LIBGL_ALWAYS_INDIRECT set)
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_OML_swap_method, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) 
OpenGL version string: 1.4 (3.0 Mesa 10.3.7)
OpenGL extensions:
GL_3DFX_texture_compression_FXT1, GL_APPLE_packed_pixels, 
GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, 
GL_ARB_fragment_program_shadow, GL_ARB_multisample, GL_ARB_multitexture, 
GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, 
GL_ARB_shadow, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, 
GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, 
GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, 
GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_window_pos, 
GL_ATIX_texture_env_combine3, GL_ATI_draw_buffers, 
GL_ATI_texture_env_combine3, GL_EXT_abgr, GL_EXT_bgra, 
GL_EXT_blend_color, GL_EXT_blend_equation_separate, 
GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, 
GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, 
GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, 
GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, 
GL_EXT_secondary_color, GL_EXT_separate_specular_color, 
GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, 
GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, 
GL_EXT_texture_compression_dxt1, GL_EXT_texture_edge_clamp, 
GL_EXT_texture_env_add, GL_EXT_texture_env_combine, 
GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, 
GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle, 
GL_EXT_vertex_array, GL_IBM_texture_mirrored_repeat, 
GL_INGR_blend_func_separate, 

[Mesa-dev] [PATCH 3/7] radeonsi: replace use of is_gs_copy_shader in si_shader_vs

[Nicolai Hähnle]

From: Nicolai Hähnle 

We now have an explicit parameter that contains the same information, and
this will allow us to get rid of is_gs_copy_shader in the si_shader struct.
---
 src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index a7259a7..36174eb 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -339,7 +339,7 @@ static void si_shader_vs(struct si_shader *shader, struct 
si_shader *gs)
va = shader->bo->gpu_address;
si_pm4_add_bo(pm4, shader->bo, RADEON_USAGE_READ, 
RADEON_PRIO_USER_SHADER);
 
-   if (shader->is_gs_copy_shader) {
+   if (gs) {
vgpr_comp_cnt = 0; /* only VertexID is needed for GS-COPY. */
num_user_sgprs = SI_GSCOPY_NUM_USER_SGPR;
} else if (shader->selector->type == PIPE_SHADER_VERTEX) {
-- 
2.5.0

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

[Mesa-dev] [PATCH 7/7] radeonsi: emit rw_buffers for tes_shader only if tes_shader present

[Nicolai Hähnle]

From: Nicolai Hähnle 

---
 src/gallium/drivers/radeonsi/si_descriptors.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index d157a9f..aad836d 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -978,9 +978,11 @@ void si_emit_shader_userdata(struct si_context *sctx, 
struct r600_atom *atom)
si_emit_shader_pointer(sctx, >const_buffers[i].desc, 
vs_base, true);
si_emit_shader_pointer(sctx, >rw_buffers[i].desc, 
vs_base, true);
 
-   /* The TESSEVAL shader needs this for the ESGS ring buffer. */
-   si_emit_shader_pointer(sctx, >rw_buffers[i].desc,
-  R_00B330_SPI_SHADER_USER_DATA_ES_0, 
true);
+   if (sctx->tes_shader.cso) {
+   /* The TESSEVAL shader needs this for the ESGS ring 
buffer. */
+   si_emit_shader_pointer(sctx, >rw_buffers[i].desc,
+  
R_00B330_SPI_SHADER_USER_DATA_ES_0, true);
+   }
} else if (sctx->tes_shader.cso) {
/* The TESSEVAL shader needs this for streamout. */
si_emit_shader_pointer(sctx, 
>rw_buffers[PIPE_SHADER_VERTEX].desc,
-- 
2.5.0

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

[Mesa-dev] [PATCH 0/7] radeonsi: geometry shader bug fix and cleanup

[Nicolai Hähnle]

Hi,

this series was prompted by a rendering bug reported for Dolphin. The bug is
fixed in the first two patches, and the remainder is assorted cleanups that
I noticed while working on the fix. Please review.

Thanks,
Nicolai
--
 .../drivers/radeonsi/si_descriptors.c|  8 +-
 src/gallium/drivers/radeonsi/si_shader.c | 14 ++--
 src/gallium/drivers/radeonsi/si_shader.h |  1 -
 .../drivers/radeonsi/si_state_shaders.c  | 78 +++---
 4 files changed, 62 insertions(+), 39 deletions(-)

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

[Mesa-dev] [PATCH 2/7] radeonsi: ensure that VGT_GS_MODE is sent when necessary

[Nicolai Hähnle]

From: Nicolai Hähnle 

Specifically, when the API switches from using a GS to not using a GS and then
back to using the same GS again, we do not have to re-send all the GS state,
but we do have to send VGT_GS_MODE. So make VGT_GS_MODE consistently be a part
of the VS state.

This fixes a rendering bug in Dolphin, but surely other applications are
affected as well.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93648
Cc: "11.0 11.1" 
---
 src/gallium/drivers/radeonsi/si_state_shaders.c | 29 ++---
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 096f152..a7259a7 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -298,7 +298,14 @@ static void si_shader_gs(struct si_shader *shader)
   
S_00B22C_SCRATCH_EN(shader->config.scratch_bytes_per_wave > 0));
 }
 
-static void si_shader_vs(struct si_shader *shader)
+/**
+ * Compute the state for \p shader, which will run as a vertex shader on the
+ * hardware.
+ *
+ * If \p gs is non-NULL, it points to the geometry shader for which this shader
+ * is the copy shader.
+ */
+static void si_shader_vs(struct si_shader *shader, struct si_shader *gs)
 {
struct si_pm4_state *pm4;
unsigned num_sgprs, num_user_sgprs;
@@ -313,15 +320,21 @@ static void si_shader_vs(struct si_shader *shader)
if (!pm4)
return;
 
-   /* If this is the GS copy shader, the GS state writes this register.
-* Otherwise, the VS state writes it.
+   /* We always write VGT_GS_MODE in the VS state, because every switch
+* between different shader pipelines involving a different GS or no
+* GS at all involves a switch of the VS (different GS use different
+* copy shaders). On the other hand, when the API switches from a GS to
+* no GS and then back to the same GS used originally, the GS state is
+* not sent again.
 */
-   if (!shader->is_gs_copy_shader) {
+   if (!gs) {
si_pm4_set_reg(pm4, R_028A40_VGT_GS_MODE,
   S_028A40_MODE(enable_prim_id ? 
V_028A40_GS_SCENARIO_A : 0));
si_pm4_set_reg(pm4, R_028A84_VGT_PRIMITIVEID_EN, 
enable_prim_id);
-   } else
+   } else {
+   si_pm4_set_reg(pm4, R_028A40_VGT_GS_MODE, si_vgt_gs_mode(gs));
si_pm4_set_reg(pm4, R_028A84_VGT_PRIMITIVEID_EN, 0);
+   }
 
va = shader->bo->gpu_address;
si_pm4_add_bo(pm4, shader->bo, RADEON_USAGE_READ, 
RADEON_PRIO_USER_SHADER);
@@ -547,7 +560,7 @@ static void si_shader_init_pm4_state(struct si_shader 
*shader)
else if (shader->key.vs.as_es)
si_shader_es(shader);
else
-   si_shader_vs(shader);
+   si_shader_vs(shader, NULL);
break;
case PIPE_SHADER_TESS_CTRL:
si_shader_hs(shader);
@@ -556,11 +569,11 @@ static void si_shader_init_pm4_state(struct si_shader 
*shader)
if (shader->key.tes.as_es)
si_shader_es(shader);
else
-   si_shader_vs(shader);
+   si_shader_vs(shader, NULL);
break;
case PIPE_SHADER_GEOMETRY:
si_shader_gs(shader);
-   si_shader_vs(shader->gs_copy_shader);
+   si_shader_vs(shader->gs_copy_shader, shader);
break;
case PIPE_SHADER_FRAGMENT:
si_shader_ps(shader);
-- 
2.5.0

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

[Mesa-dev] [PATCH 1/7] radeonsi: extract the VGT_GS_MODE calculation into its own function

[Nicolai Hähnle]

From: Nicolai Hähnle 

Cc: "11.0 11.1" 
---
 src/gallium/drivers/radeonsi/si_state_shaders.c | 47 +++--
 1 file changed, 28 insertions(+), 19 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 79f2335..096f152 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -212,13 +212,37 @@ static void si_shader_es(struct si_shader *shader)
si_set_tesseval_regs(shader, pm4);
 }
 
+/**
+ * Calculate the appropriate setting of VGT_GS_MODE when \p shader is a
+ * geometry shader.
+ */
+static uint32_t si_vgt_gs_mode(struct si_shader *shader)
+{
+   unsigned gs_max_vert_out = shader->selector->gs_max_out_vertices;
+   unsigned cut_mode;
+
+   if (gs_max_vert_out <= 128) {
+   cut_mode = V_028A40_GS_CUT_128;
+   } else if (gs_max_vert_out <= 256) {
+   cut_mode = V_028A40_GS_CUT_256;
+   } else if (gs_max_vert_out <= 512) {
+   cut_mode = V_028A40_GS_CUT_512;
+   } else {
+   assert(gs_max_vert_out <= 1024);
+   cut_mode = V_028A40_GS_CUT_1024;
+   }
+
+   return S_028A40_MODE(V_028A40_GS_SCENARIO_G) |
+  S_028A40_CUT_MODE(cut_mode)|
+  S_028A40_ES_WRITE_OPTIMIZE(1) |
+  S_028A40_GS_WRITE_OPTIMIZE(1);
+}
+
 static void si_shader_gs(struct si_shader *shader)
 {
unsigned gs_vert_itemsize = shader->selector->gsvs_vertex_size;
-   unsigned gs_max_vert_out = shader->selector->gs_max_out_vertices;
unsigned gsvs_itemsize = shader->selector->max_gsvs_emit_size >> 2;
unsigned gs_num_invocations = shader->selector->gs_num_invocations;
-   unsigned cut_mode;
struct si_pm4_state *pm4;
unsigned num_sgprs, num_user_sgprs;
uint64_t va;
@@ -232,22 +256,7 @@ static void si_shader_gs(struct si_shader *shader)
if (!pm4)
return;
 
-   if (gs_max_vert_out <= 128) {
-   cut_mode = V_028A40_GS_CUT_128;
-   } else if (gs_max_vert_out <= 256) {
-   cut_mode = V_028A40_GS_CUT_256;
-   } else if (gs_max_vert_out <= 512) {
-   cut_mode = V_028A40_GS_CUT_512;
-   } else {
-   assert(gs_max_vert_out <= 1024);
-   cut_mode = V_028A40_GS_CUT_1024;
-   }
-
-   si_pm4_set_reg(pm4, R_028A40_VGT_GS_MODE,
-  S_028A40_MODE(V_028A40_GS_SCENARIO_G) |
-  S_028A40_CUT_MODE(cut_mode)|
-  S_028A40_ES_WRITE_OPTIMIZE(1) |
-  S_028A40_GS_WRITE_OPTIMIZE(1));
+   si_pm4_set_reg(pm4, R_028A40_VGT_GS_MODE, si_vgt_gs_mode(shader));
 
si_pm4_set_reg(pm4, R_028A60_VGT_GSVS_RING_OFFSET_1, gsvs_itemsize);
si_pm4_set_reg(pm4, R_028A64_VGT_GSVS_RING_OFFSET_2, gsvs_itemsize * 
((max_stream >= 2) ? 2 : 1));
@@ -255,7 +264,7 @@ static void si_shader_gs(struct si_shader *shader)
 
si_pm4_set_reg(pm4, R_028AB0_VGT_GSVS_RING_ITEMSIZE, gsvs_itemsize * 
(max_stream + 1));
 
-   si_pm4_set_reg(pm4, R_028B38_VGT_GS_MAX_VERT_OUT, gs_max_vert_out);
+   si_pm4_set_reg(pm4, R_028B38_VGT_GS_MAX_VERT_OUT, 
shader->selector->gs_max_out_vertices);
 
si_pm4_set_reg(pm4, R_028B5C_VGT_GS_VERT_ITEMSIZE, gs_vert_itemsize >> 
2);
si_pm4_set_reg(pm4, R_028B60_VGT_GS_VERT_ITEMSIZE_1, (max_stream >= 1) 
? gs_vert_itemsize >> 2 : 0);
-- 
2.5.0

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

[Mesa-dev] [PATCH 6/7] radeonsi: do not set the shader->key for gs copy shaders

[Nicolai Hähnle]

From: Nicolai Hähnle 

The key for a geometry shader would be interpreted as the key for a vertex
shader further down the line, which really doesn't make sense.

This does not affect the contents of shader->key because geometry shaders
don't have any key entries anyway.
---
 src/gallium/drivers/radeonsi/si_shader.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index a4bc1de..5e0c2a8 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -4360,7 +4360,6 @@ int si_shader_create(struct si_screen *sscreen, 
LLVMTargetMachineRef tm,
if (si_shader_ctx.type == TGSI_PROCESSOR_GEOMETRY) {
shader->gs_copy_shader = CALLOC_STRUCT(si_shader);
shader->gs_copy_shader->selector = shader->selector;
-   shader->gs_copy_shader->key = shader->key;
si_shader_ctx.shader = shader->gs_copy_shader;
if ((r = si_generate_gs_copy_shader(sscreen, _shader_ctx,
shader, dump, debug))) {
-- 
2.5.0

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

[Mesa-dev] [PATCH 5/7] radeonsi: si_llvm_emit_vs_epilogue is never used with gs copy shaders

[Nicolai Hähnle]

From: Nicolai Hähnle 

Hence remove the misleading branch on is_gs_copy_shader.
---
 src/gallium/drivers/radeonsi/si_shader.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 6cc435c..a4bc1de 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2152,6 +2152,8 @@ static void si_llvm_emit_vs_epilogue(struct 
lp_build_tgsi_context * bld_base)
struct si_shader_output_values *outputs = NULL;
int i,j;
 
+   assert(!si_shader_ctx->is_gs_copy_shader);
+
outputs = MALLOC((info->num_outputs + 1) * sizeof(outputs[0]));
 
/* Vertex color clamping.
@@ -2160,8 +2162,7 @@ static void si_llvm_emit_vs_epilogue(struct 
lp_build_tgsi_context * bld_base)
 * an IF statement is added that clamps all colors if the constant
 * is true.
 */
-   if (si_shader_ctx->type == TGSI_PROCESSOR_VERTEX &&
-   !si_shader_ctx->is_gs_copy_shader) {
+   if (si_shader_ctx->type == TGSI_PROCESSOR_VERTEX) {
struct lp_build_if_state if_ctx;
LLVMValueRef cond = NULL;
LLVMValueRef addr, val;
-- 
2.5.0

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

[Mesa-dev] [PATCH 4/7] radeonsi: move is_gs_copy_shader to si_shader_context

[Nicolai Hähnle]

From: Nicolai Hähnle 

It is only used during shader creation now, so no need to keep it around
afterwards.
---
 src/gallium/drivers/radeonsi/si_shader.c | 10 +-
 src/gallium/drivers/radeonsi/si_shader.h |  1 -
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 1bd617f..6cc435c 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -68,6 +68,7 @@ struct si_shader_context
struct si_shader *shader;
struct si_screen *screen;
unsigned type; /* TGSI_PROCESSOR_* specifies the type of shader. */
+   bool is_gs_copy_shader;
int param_streamout_config;
int param_streamout_write_index;
int param_streamout_offset[4];
@@ -2160,7 +2161,7 @@ static void si_llvm_emit_vs_epilogue(struct 
lp_build_tgsi_context * bld_base)
 * is true.
 */
if (si_shader_ctx->type == TGSI_PROCESSOR_VERTEX &&
-   !si_shader_ctx->shader->is_gs_copy_shader) {
+   !si_shader_ctx->is_gs_copy_shader) {
struct lp_build_if_state if_ctx;
LLVMValueRef cond = NULL;
LLVMValueRef addr, val;
@@ -3554,7 +3555,7 @@ static void create_function(struct si_shader_context 
*si_shader_ctx)
params[SI_PARAM_LS_OUT_LAYOUT] = i32;
num_params = SI_PARAM_LS_OUT_LAYOUT+1;
} else {
-   if (shader->is_gs_copy_shader) {
+   if (si_shader_ctx->is_gs_copy_shader) {
last_array_pointer = SI_PARAM_CONST_BUFFERS;
num_params = SI_PARAM_CONST_BUFFERS+1;
} else {
@@ -3827,7 +3828,7 @@ static void preload_ring_buffers(struct si_shader_context 
*si_shader_ctx)
build_indexed_load_const(si_shader_ctx, buf_ptr, 
offset);
}
 
-   if (si_shader_ctx->shader->is_gs_copy_shader) {
+   if (si_shader_ctx->is_gs_copy_shader) {
LLVMValueRef offset = lp_build_const_int32(gallivm, 
SI_RING_GSVS);
 
si_shader_ctx->gsvs_ring[0] =
@@ -4075,7 +4076,6 @@ static int si_generate_gs_copy_shader(struct si_screen 
*sscreen,
struct lp_build_tgsi_context *bld_base = 
_shader_ctx->radeon_bld.soa.bld_base;
struct lp_build_context *base = _base->base;
struct lp_build_context *uint = _base->uint_bld;
-   struct si_shader *shader = si_shader_ctx->shader;
struct si_shader_output_values *outputs;
struct tgsi_shader_info *gsinfo = >selector->info;
LLVMValueRef args[9];
@@ -4084,7 +4084,7 @@ static int si_generate_gs_copy_shader(struct si_screen 
*sscreen,
outputs = MALLOC(gsinfo->num_outputs * sizeof(outputs[0]));
 
si_shader_ctx->type = TGSI_PROCESSOR_VERTEX;
-   shader->is_gs_copy_shader = true;
+   si_shader_ctx->is_gs_copy_shader = true;
 
radeon_llvm_context_init(_shader_ctx->radeon_bld);
 
diff --git a/src/gallium/drivers/radeonsi/si_shader.h 
b/src/gallium/drivers/radeonsi/si_shader.h
index 50375e2..c151207 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -297,7 +297,6 @@ struct si_shader {
booluses_instanceid;
unsignednr_pos_exports;
unsignednr_param_exports;
-   boolis_gs_copy_shader;
booldx10_clamp_mode; /* convert NaNs to 0 */
 };
 
-- 
2.5.0

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

Re: [Mesa-dev] [PATCH 2/4] mesa: enable enums for OES_geometry_shader

[Ilia Mirkin]

On Thu, Jan 21, 2016 at 10:17 AM, Marta Lofstedt
 wrote:
> From: Marta Lofstedt 
>
> Enable GL_OES_geometry_shader enums for OpenGL ES 3.1.
>
> V4: EXTRA tokens updated according to comments from Ilia Mirkin.
>
> Signed-off-by: Marta Lofstedt 
> Reviewed-by: Tapani Pälli 
> ---
>  src/mesa/main/get.c  | 65 
> ++--
>  src/mesa/main/get_hash_params.py | 52 +++-
>  2 files changed, 87 insertions(+), 30 deletions(-)
>
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index 95cb18c..d8f9e25a 100644
> --- a/src/mesa/main/get.c
> +++ b/src/mesa/main/get.c
> @@ -147,11 +147,14 @@ enum value_extra {
> EXTRA_VALID_CLIP_DISTANCE,
> EXTRA_FLUSH_CURRENT,
> EXTRA_GLSL_130,
> -   EXTRA_EXT_UBO_GS4,
> -   EXTRA_EXT_ATOMICS_GS4,
> -   EXTRA_EXT_SHADER_IMAGE_GS4,
> +   EXTRA_EXT_UBO_GS,
> +   EXTRA_EXT_ATOMICS_GS,
> +   EXTRA_EXT_SHADER_IMAGE_GS,
> EXTRA_EXT_ATOMICS_TESS,
> EXTRA_EXT_SHADER_IMAGE_TESS,
> +   EXTRA_EXT_SSBO_GS,
> +   EXTRA_EXT_FB_NO_ATTACH_GS,
> +   EXTRA_EXT_ES_GS,
>  };
>
>  #define NO_EXTRA NULL
> @@ -308,7 +311,7 @@ static const int extra_ARB_transform_feedback2_api_es3[] 
> = {
>  };
>
>  static const int extra_ARB_uniform_buffer_object_and_geometry_shader[] = {
> -   EXTRA_EXT_UBO_GS4,
> +   EXTRA_EXT_UBO_GS,
> EXTRA_END
>  };
>
> @@ -343,12 +346,12 @@ static const int extra_EXT_texture_array_es3[] = {
>  };
>
>  static const int extra_ARB_shader_atomic_counters_and_geometry_shader[] = {
> -   EXTRA_EXT_ATOMICS_GS4,
> +   EXTRA_EXT_ATOMICS_GS,
> EXTRA_END
>  };
>
>  static const int extra_ARB_shader_image_load_store_and_geometry_shader[] = {
> -   EXTRA_EXT_SHADER_IMAGE_GS4,
> +   EXTRA_EXT_SHADER_IMAGE_GS,
> EXTRA_END
>  };
>
> @@ -375,6 +378,29 @@ static const int 
> extra_ARB_shader_storage_buffer_object_es31[] = {
> EXTRA_END
>  };
>
> +static const int 
> extra_ARB_shader_storage_buffer_object_and_geometry_shader[] = {
> +   EXTRA_EXT_SSBO_GS,
> +   EXTRA_END
> +};
> +
> +
> +static const int extra_ARB_framebuffer_no_attachments_and_geometry_shader[] 
> = {
> +   EXTRA_EXT_FB_NO_ATTACH_GS,
> +   EXTRA_END
> +};
> +
> +static const int extra_ARB_viewport_array_or_oes_geometry_shader[] = {
> +   EXT(ARB_viewport_array),
> +   EXTRA_EXT_ES_GS,
> +   EXTRA_END
> +};
> +
> +static const int extra_ARB_gpu_shader5_or_oes_geometry_shader[] = {
> +   EXT(ARB_gpu_shader5),
> +   EXTRA_EXT_ES_GS,
> +   EXTRA_END
> +};
> +
>  EXTRA_EXT(ARB_texture_cube_map);
>  EXTRA_EXT(EXT_texture_array);
>  EXTRA_EXT(NV_fog_distance);
> @@ -424,6 +450,7 @@ EXTRA_EXT(ARB_tessellation_shader);
>  EXTRA_EXT(ARB_shader_subroutine);
>  EXTRA_EXT(ARB_shader_storage_buffer_object);
>  EXTRA_EXT(ARB_indirect_parameters);
> +EXTRA_EXT(OES_geometry_shader);
>
>  static const int
>  extra_ARB_color_buffer_float_or_glcore[] = {
> @@ -455,6 +482,12 @@ static const int extra_gl32_es3[] = {
>  EXTRA_END,
>  };
>
> +static const int extra_version_32_OES_geometry_shader[] = {
> +EXTRA_VERSION_32,
> +EXT(OES_geometry_shader),
> +EXTRA_END
> +};
> +
>  static const int extra_gl40_ARB_sample_shading[] = {
> EXTRA_VERSION_40,
> EXT(ARB_sample_shading),
> @@ -1154,17 +1187,17 @@ check_extra(struct gl_context *ctx, const char *func, 
> const struct value_desc *d
>   if (ctx->Const.GLSLVersion >= 130)
>  api_found = GL_TRUE;
>  break;
> -  case EXTRA_EXT_UBO_GS4:
> +  case EXTRA_EXT_UBO_GS:
>   api_check = GL_TRUE;
>   api_found = (ctx->Extensions.ARB_uniform_buffer_object &&
>_mesa_has_geometry_shaders(ctx));
>   break;
> -  case EXTRA_EXT_ATOMICS_GS4:
> +  case EXTRA_EXT_ATOMICS_GS:
>   api_check = GL_TRUE;
>   api_found = (ctx->Extensions.ARB_shader_atomic_counters &&
>_mesa_has_geometry_shaders(ctx));
>   break;
> -  case EXTRA_EXT_SHADER_IMAGE_GS4:
> +  case EXTRA_EXT_SHADER_IMAGE_GS:
>   api_check = GL_TRUE;
>   api_found = (ctx->Extensions.ARB_shader_image_load_store &&
>_mesa_has_geometry_shaders(ctx));
> @@ -1179,6 +1212,20 @@ check_extra(struct gl_context *ctx, const char *func, 
> const struct value_desc *d
>   api_found = ctx->Extensions.ARB_shader_image_load_store &&
>   _mesa_has_tessellation(ctx);
>   break;
> +  case EXTRA_EXT_SSBO_GS:
> + api_check = GL_TRUE;
> + api_found = (ctx->Extensions.ARB_shader_storage_buffer_object &&
> +  _mesa_has_geometry_shaders(ctx));
> + break;
> +  case EXTRA_EXT_FB_NO_ATTACH_GS:
> + api_check = GL_TRUE;
> + api_found = (ctx->Extensions.ARB_framebuffer_no_attachments &&
> +  _mesa_has_geometry_shaders(ctx));
> + break;
> +  

Re: [Mesa-dev] [PATCH] util/ralloc: Remove double zero'ing of rzalloc buffers

[Nicolai Hähnle]

On 22.01.2016 16:02, Kenneth Graunke wrote:

On Friday, January 22, 2016 12:09:18 PM PST Nicolai Hähnle wrote:

On 22.01.2016 02:53, Jordan Justen wrote:

Juha-Pekka found this back in May 2015:
<1430915727-28677-1-git-send-email-juhapekka.heikk...@gmail.com>

  From the discussion, obviously it would be preferable to make
ralloc_size no longer return zeroed memory, but Juha-Pekka found that
it would break Mesa.

For now, let's point out the flaw, and stop doing the double zeroing
of rzalloc buffers.

Signed-off-by: Jordan Justen 
Cc: Juha-Pekka Heikkila 
Cc: Kenneth Graunke 
---

   For a release build, I saw the code size shrink by 64 bytes.

   src/util/ralloc.c | 15 +--
   1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/src/util/ralloc.c b/src/util/ralloc.c
index 6d4032b..24c1eee 100644
--- a/src/util/ralloc.c
+++ b/src/util/ralloc.c
@@ -49,6 +49,14 @@ _CRTIMP int _vscprintf(const char *format, va_list

argptr);

   #endif
   #endif

+/* ralloc_size has always used calloc to allocate memory. This has

allowed

+ * code using ralloc_size to depend on always receiving a cleared buffer.
+ *
+ * FIXME: Clean up the code base to allow this to be set to false, and

then

+ * remove it altogether.
+ */
+static const bool always_allocate_zeroed_memory = true;
+
   #define CANARY 0x5A1106

   struct ralloc_header
@@ -110,7 +118,10 @@ ralloc_context(const void *ctx)
   void *
   ralloc_size(const void *ctx, size_t size)
   {
-   void *block = calloc(1, size + sizeof(ralloc_header));
+   void *block =
+  always_allocate_zeroed_memory ?
+  calloc(1, size + sizeof(ralloc_header)) :
+  malloc(size + sizeof(ralloc_header));


There's an integer overflow here which would be good to fix.


Please explain?  ralloc_header is 40-44 bytes - the only way this will
overflow is if you asked for an absurd amount of memory (already near
the max value of size_t).  And, if you did, I'm not sure what we're
supposed to do about it...


A common method of triggering buffer overflows leading to security 
exploits is that the attacker sets an absurdly large buffer size 
somewhere - so large that additional calculations that increase the 
buffer size wrap around and result in a very small successful 
allocation. The code will then write memory based on the original, 
absurdly large buffer size. This means writing beyond the end of the 
allocated buffer.


The people who look for security exploits for a living are really good 
at finding ways in which such a situation can then be used to hijack the 
control flow of the program somehow (for example, targeted overwriting 
of the internal metadata of the heap... sounds crazy, but it's used) to 
do more or less whatever they want.


I think a decent way to protect against it is something like:

   /* Overflow of unsigned integer types is well defined */
   if (size + sizeof(ralloc_header) < size)
  return NULL;

or perhaps

   if (size > SIZE_MAX - sizeof(ralloc_header))
  return NULL;

Newer versions of gcc have nicer builtins for arithmetic with overflow 
check, but I don't know if we want to depend on those being available.


The hope is that the calling code properly handles allocation failure. 
Even if it doesn't, the result is much more likely to just be a segfault 
before anything dangerous can happen.


One may say that all of this depends on an attacker gaining access to 
Mesa, but WebGL is a thing, so...


Cheers,
Nicolai




Since it was there already in the older version, the patch is

Reviewed-by: Nicolai Hähnle 

as is.


  ralloc_header *info;
  ralloc_header *parent;

@@ -132,7 +143,7 @@ void *
   rzalloc_size(const void *ctx, size_t size)
   {
  void *ptr = ralloc_size(ctx, size);
-   if (likely(ptr != NULL))
+   if (!always_allocate_zeroed_memory && likely(ptr != NULL))
 memset(ptr, 0, size);
  return ptr;
   }





Dropping the memset seems reasonable.  I would prefer it if we simply
moved the contents of ralloc_size into rzalloc_size, and made
ralloc_size call rzalloc_size with a comment.


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

Re: [Mesa-dev] [PATCH 2/2] virgl: enable building on Android

[Rob Herring]

On Fri, Dec 18, 2015 at 11:01 AM, Emil Velikov  wrote:
> Thank you Rob !
>
> On 17 December 2015 at 15:45, Rob Herring  wrote:
>> This is just a copy-n-paste and rename of vc4 Android makefiles.
>>
> Looks great.
>
> Rob, I take it that you've at least compile tested this patch ?
>
> Cc: "11.1" 
> Reviewed-by: Emil Velikov 
>
> I'll apply this some time next week.

It looks like these 2 patches never got applied.

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

Re: [Mesa-dev] [PATCH 1/2] i965: Use nir_lower_load_const_to_scalar().

[Matt Turner]

On Thu, Jan 21, 2016 at 4:37 PM, Kenneth Graunke  wrote:
> I don't know why, but we never hooked up this pass Eric wrote.
> Otherwise, you can end up with stupid scalarized code such as:
>
>vec4 ssa_7 = load_const (0.0, 0.0, 0.0, 0.0)
>vec4 ssa_8 = ...
>vec1 ssa_9 = feq ssa_8, ssa_7
>vec1 ssa_10 = feq ssa_8.y, ssa_7.y
>vec1 ssa_11 = feq ssa_8, ssa_7.z
>vec1 ssa_12 = feq ssa_8.y, ssa_7.w
>
> ssa_8.xyxy == <0, 0, 0, 0> should only take two feq instructions.
>
> shader-db on Skylake:
>
> total instructions in shared programs: 9111788 -> 9111384 (-0.00%)
> instructions in affected programs: 32421 -> 32017 (-1.25%)
> helped: 277
> HURT: 69

All the hurt programs seem to have an extra instruction because of
interactions with multiply-add fusing. What we have with this patch
might even be better.

>
> total cycles in shared programs: 69221226 -> 69219394 (-0.00%)
> cycles in affected programs: 917796 -> 915964 (-0.20%)
> helped: 317
> HURT: 408

One weird thing here... ETQW/fp-259.shader_test goes from 54 -> 53
instructions (another multiply-add interaction) in both the SIMD8 and
SIMD16 programs, but the cycle estimate goes from 422 -> 432 in SIMD8
and 392 -> 570 in SIMD16.

There are four texture operations, and they're scheduled together in
SIMD8. In SIMD16, for some reason the one that reads surface 2 is
scheduled basically at the end of the program...

Also, how in the world could the SIMD16 cycle estimate be *lower* than
the SIMD8 cycle estimate?

>
> This also prevents regressions when disabling channel expressions.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_nir.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_nir.c 
> b/src/mesa/drivers/dri/i965/brw_nir.c
> index 935529a..ce9b9db 100644
> --- a/src/mesa/drivers/dri/i965/brw_nir.c
> +++ b/src/mesa/drivers/dri/i965/brw_nir.c
> @@ -482,6 +482,11 @@ brw_preprocess_nir(nir_shader *nir, bool is_scalar)
>
> nir = nir_optimize(nir, is_scalar);
>
> +   if (is_scalar) {
> +  OPT_V(nir_lower_load_const_to_scalar);
> +  OPT(nir_opt_cse);

Did you find the call to nir_opt_cse to be necessary? Removing it, I
only see the cycle estimate for trine-2/fp-2 go from 696 -> 704. I'd
probably leave it out.

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

Re: [Mesa-dev] [PATCH 2/2] i965: Do channel expressions on significantly fewer opcodes.

[Matt Turner]

On Fri, Jan 22, 2016 at 8:42 PM, Jason Ekstrand  wrote:
> On Fri, Jan 22, 2016 at 5:35 PM, Matt Turner  wrote:
>> On Thu, Jan 21, 2016 at 4:37 PM, Kenneth Graunke 
>> wrote:
>> > nir_lower_alu_to_scalar() and nir_lower_load_const_to_scalar()
>> > handle most cases quite well.  They also create nir_ssa_defs rather
>> > than ir_variables, which are much less memory intensive.
>> >
>> > This can mean losing out on a few GLSL IR optimizations, however.
>> > In most cases, this is fine.  But a few cases still benefit:
>> >
>> > - add/mul/dot still benefit from opt_algebraic()'s constant
>> >   reassociation capabilities.
>> >
>> > - min/max still benefit from opt_minmax().
>> >
>> > - comparisons seem to still benefit from opt_algebraic(), even
>> >   though we also do most of them in nir_opt_algebraic_late().
>> >
>> > With this change, shader-db statistics on Skylake are:
>> >
>> > total instructions in shared programs: 9107924 -> 9107347 (-0.01%)
>> > instructions in affected programs: 188830 -> 188253 (-0.31%)
>> > helped: 572
>> > HURT: 154
>>
>> I tried looking at the hurt programs. The first was
>> guacamelee/368.shader_test, which went from 40 -> 43 instructions. It
>> has a multiplication tree of (x * (y * 0.2) * 15.0), which we are able
>> to convert into x * y * 3.0 after channel expressions.
>>
>> The shader looks like
>>
>> star_1 = (thing0 * 0.2) * thing1
>> star_1 = star_1 * 15.0
>>
>> star_2 = (thing2 * 0.2) * thing3
>> star_2 = star_2 * 15.0
>>
>> star_3 = (thing4 * 0.2) * thing5
>> star_3 = star_3 * 15.0
>>
>> stars = sat(star_1) + sat(star_2) + sat(stars_3)
>>
>> Before linking and channel expressions, we don't have appropriate
>> trees to see that we can reassociate constants. Tree grafting won't do
>> its job on, for instance, star_1, because it sees that star_1 is
>> assigned more than once -- even though it's just reassigning itself.
>>
>> Adding ir_unop_saturate back to channel_expressions solves the issue.
>> I continued looking at the regressions and adding things back until I
>> was down to 25 hurt programs (but also down to only 10 helped) after
>> I'd readded sign, lrp, neg, f2i, i2f, exp2, log2, f2u, u2f.
>
>
> Adding those back in gets rid of hurt programs, but does adding them back in
> get rid of helped programs?

Yes, adding them back both helps and hurts programs.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965: Use nir_lower_load_const_to_scalar().

[Jason Ekstrand]

On Jan 21, 2016 4:37 PM, "Kenneth Graunke"  wrote:
>
> I don't know why, but we never hooked up this pass Eric wrote.
> Otherwise, you can end up with stupid scalarized code such as:
>
>vec4 ssa_7 = load_const (0.0, 0.0, 0.0, 0.0)
>vec4 ssa_8 = ...
>vec1 ssa_9 = feq ssa_8, ssa_7
>vec1 ssa_10 = feq ssa_8.y, ssa_7.y
>vec1 ssa_11 = feq ssa_8, ssa_7.z
>vec1 ssa_12 = feq ssa_8.y, ssa_7.w
>
> ssa_8.xyxy == <0, 0, 0, 0> should only take two feq instructions.
>
> shader-db on Skylake:
>
> total instructions in shared programs: 9111788 -> 9111384 (-0.00%)
> instructions in affected programs: 32421 -> 32017 (-1.25%)
> helped: 277
> HURT: 69
>
> total cycles in shared programs: 69221226 -> 69219394 (-0.00%)
> cycles in affected programs: 917796 -> 915964 (-0.20%)
> helped: 317
> HURT: 408
>
> This also prevents regressions when disabling channel expressions.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_nir.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_nir.c
b/src/mesa/drivers/dri/i965/brw_nir.c
> index 935529a..ce9b9db 100644
> --- a/src/mesa/drivers/dri/i965/brw_nir.c
> +++ b/src/mesa/drivers/dri/i965/brw_nir.c
> @@ -482,6 +482,11 @@ brw_preprocess_nir(nir_shader *nir, bool is_scalar)
>
> nir = nir_optimize(nir, is_scalar);
>
> +   if (is_scalar) {
> +  OPT_V(nir_lower_load_const_to_scalar);
> +  OPT(nir_opt_cse);
> +   }

Why did you choose to put this *after* the opt loop?  It seems like we
would want it before so that we can use better.  As long as alu_to_scalar
is run before constant folding (so we don't end up re-vectorizing them),
before should be fine.

> +
> /* Lower a bunch of stuff */
> OPT_V(nir_lower_var_copies);
>
> --
> 2.7.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/2] configure.ac: don't require EGL/DRM ang GBM if OpenGL is disabled

[Emil Velikov]

On 22 January 2016 at 16:50, Marek Olšák  wrote:
> On Fri, Jan 22, 2016 at 5:32 PM, Emil Velikov  
> wrote:
>> Hi Marek,
>>
>> On 22 January 2016 at 12:24, Marek Olšák  wrote:
>>> Hi Emil,
>>>
>>> Do you have any comment on this series?
>>>
>> I was secretly hoping that you'll forget about this patch because...
>>
>>> Marek
>>>
>>> On Tue, Jan 12, 2016 at 8:46 PM, Marek Olšák  wrote:
 From: Marek Olšák 

 This allows building VDPAU/OMX/VA drivers without OpenGL and its
 dependencies.
 ---
  configure.ac | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/configure.ac b/configure.ac
 index 8d19dab..04b5fd8 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -2159,7 +2159,12 @@ gallium_require_drm_loader() {
  fi
  }

 +dnl This is for Glamor. Skip this if OpenGL is disabled.
  require_egl_drm() {
 +if test "x$enable_opengl" = xno; then
 +return 0
 +fi
 +
  case "$with_egl_platforms" in
  *drm*)
  ;;
>> ... the hole idea of having this error out is a gross workaround imho.
>> While I could not find anything concrete to point out initially seems
>> like you have found it. And now we add a workaround on top of the
>> workaround :-\
>>
>> Yes it is (very) unlikely that radeonsi GPUs will have 2d accel
>> without glamor and yes it is required in those cases. But that does
>> not mean that we must mandate egl+drm but recommend it ? After all one
>> can have egl+wayland+radeonsi mesa (without egl+drm) on a xserver-less
>> setup, can't they ?
>
> I don't know what Wayland uses, but if it doesn't use egl+drm, that's fine.
>
> We still have to require egl+drm for GLX/DRI support, so we can loosen
> the requirement a little bit, but we can't remove it completely.
> That's how I see it.
>
The point I'm making is that one cannot forsee what the user will do
(run) at build time. Thus sticking with a big fan warning is a
sensible thing to do. If no-one pays attention to the warnings (I've
been guilty a few times as well) then it's their own fault - it's not
like we print (m)any and things get lost amidst the noise ?

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

Re: [Mesa-dev] [PATCH 1/4] radeonsi: allow using all CUs for tessellation and on-chip GS (v2)

[Nicolai Hähnle]

This series is

Reviewed-by: Nicolai Hähnle 

On 22.01.2016 09:18, Marek Olšák wrote:

From: Marek Olšák 

v2: After more discussion with hw teams, the kernel already contains the
 optimal settings allowing us to use all CUs.
---
  src/gallium/drivers/radeonsi/si_state.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index a3ddee8..67b2835 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3701,9 +3701,9 @@ static void si_init_config(struct si_context *sctx)
si_pm4_set_reg(pm4, R_028408_VGT_INDX_OFFSET, 0);

if (sctx->b.chip_class >= CIK) {
-   si_pm4_set_reg(pm4, R_00B51C_SPI_SHADER_PGM_RSRC3_LS, 
S_00B51C_CU_EN(0xfffc));
+   si_pm4_set_reg(pm4, R_00B51C_SPI_SHADER_PGM_RSRC3_LS, 
S_00B51C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B41C_SPI_SHADER_PGM_RSRC3_HS, 0);
-   si_pm4_set_reg(pm4, R_00B31C_SPI_SHADER_PGM_RSRC3_ES, 
S_00B31C_CU_EN(0xfffe));
+   si_pm4_set_reg(pm4, R_00B31C_SPI_SHADER_PGM_RSRC3_ES, 
S_00B31C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B21C_SPI_SHADER_PGM_RSRC3_GS, 
S_00B21C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B118_SPI_SHADER_PGM_RSRC3_VS, 
S_00B118_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B11C_SPI_SHADER_LATE_ALLOC_VS, 
S_00B11C_LIMIT(0));


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

Re: [Mesa-dev] [PATCH] util/ralloc: Remove double zero'ing of rzalloc buffers

[Nicolai Hähnle]

On 22.01.2016 02:53, Jordan Justen wrote:

Juha-Pekka found this back in May 2015:
<1430915727-28677-1-git-send-email-juhapekka.heikk...@gmail.com>

 From the discussion, obviously it would be preferable to make
ralloc_size no longer return zeroed memory, but Juha-Pekka found that
it would break Mesa.

For now, let's point out the flaw, and stop doing the double zeroing
of rzalloc buffers.

Signed-off-by: Jordan Justen 
Cc: Juha-Pekka Heikkila 
Cc: Kenneth Graunke 
---

  For a release build, I saw the code size shrink by 64 bytes.

  src/util/ralloc.c | 15 +--
  1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/src/util/ralloc.c b/src/util/ralloc.c
index 6d4032b..24c1eee 100644
--- a/src/util/ralloc.c
+++ b/src/util/ralloc.c
@@ -49,6 +49,14 @@ _CRTIMP int _vscprintf(const char *format, va_list argptr);
  #endif
  #endif

+/* ralloc_size has always used calloc to allocate memory. This has allowed
+ * code using ralloc_size to depend on always receiving a cleared buffer.
+ *
+ * FIXME: Clean up the code base to allow this to be set to false, and then
+ * remove it altogether.
+ */
+static const bool always_allocate_zeroed_memory = true;
+
  #define CANARY 0x5A1106

  struct ralloc_header
@@ -110,7 +118,10 @@ ralloc_context(const void *ctx)
  void *
  ralloc_size(const void *ctx, size_t size)
  {
-   void *block = calloc(1, size + sizeof(ralloc_header));
+   void *block =
+  always_allocate_zeroed_memory ?
+  calloc(1, size + sizeof(ralloc_header)) :
+  malloc(size + sizeof(ralloc_header));


There's an integer overflow here which would be good to fix. Since it 
was there already in the older version, the patch is


Reviewed-by: Nicolai Hähnle 

as is.


 ralloc_header *info;
 ralloc_header *parent;

@@ -132,7 +143,7 @@ void *
  rzalloc_size(const void *ctx, size_t size)
  {
 void *ptr = ralloc_size(ctx, size);
-   if (likely(ptr != NULL))
+   if (!always_allocate_zeroed_memory && likely(ptr != NULL))
memset(ptr, 0, size);
 return ptr;
  }


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

Re: [Mesa-dev] [android-x86-devel] Re: need-help: how to change to newest mesa in android-x86?

[Rob Clark]

On Fri, Jan 22, 2016 at 10:29 AM, Rob Herring  wrote:
> On Mon, Jan 18, 2016 at 4:46 PM, Rob Clark  wrote:
>> On Mon, Jan 18, 2016 at 5:18 PM, Rob Herring  wrote:
>>> On Fri, Jan 15, 2016 at 3:10 PM, Dave Airlie  wrote:
>
> well, nothing specific, but for example early on we had some confusion
> in drm_gralloc (when adding dmabuf fd support) about who close()d the
> fd's.  Resulting in same fd getting closed twice (although some
> completely unrelated file handle might have snuck into that slot
> between the two close()s).
>
> Or you could end up w/ the same sort of thing for gem handles (which
> are unique to the drm device fd, so if you open() the device multiple
> times..).  I did initially have some confusion about this, w/ multiple
> fd_bo's (or pipe_resource's) being created for a given gem handle, and
> first one that gets deleted takes away the backing store that both
> userspace references where using.
>
> You might want to look at freedreno_drm_winsys.c and the crazy things
> it does..  I suspect virgl might need similar hacks.  That is really
> one part of two, that ensures that we share the same pipe_screen, and
> therefore (from libdrm) fd_device, for a given drm device fd.  The
> other part is that fd_device has hashtables to deal w/ double import
> of gem buffers.

 I think Rob Clark might be on the right track here.

 it sounds like the host is sending double deletes for some objects, which
 sounds like a possible reference counting bug in the host.

 So possibly something drm_gralloc, but it could be a bug in mesa, though
 I haven't triggered anything like this yet.
>>>
>>> Some more details. If I comment out the freeing of imported buffers in
>>> gralloc_drm_handle_unregister, things work a lot better. I think there
>>> is a missing reference taken on an alloc with an existing dmabuf FD.
>>> I've been comparing freedreno vs. pipe alloc/free implementations for
>>> gralloc. The freedreno alloc function will call drmPrimeFDToHandle and
>>> increment the BO ref count (in lookup_bo). The equivalent for virgl is
>>> in virgl_drm_winsys_resource_create_handle. It calls
>>> drmPrimeFDToHandle, but there is no reference taken. The shared handle
>>> case in that function does take a reference with a
>>> virgl_drm_resource_reference call. I may be off as my attempted fix
>>> doesn't work...
>>
>> Hmm, so I guess I should have removed gralloc_drm_freedreno, but by
>> the time I actually got things working properly on ifc6410 I was using
>> gralloc_drm_pipe.c..  sorry if you had been looking at the wrong code.
>
> I was and should have realized that. Still, it got me looking at the
> right area. The virgl driver is missing a BO handle hash table for
> prime fd handles. It is only doing handle lookups for shared handles.
> I've fixed that, but have broken the shared handle hashing in the
> process. Looking at other drivers, it appears I need to have 2 hash
> tables. I'm guessing shared handles and prime handles are from
> different number spaces?

I suppose there are actually three name-spaces (handles, flink names,
and dmabuf/prime fd's)..

IIRC, you end up needing an extra table for flink name importing,
otherwise the kernel will happily hand you back multiple gem handles
for the same bo, which causes similar sorts of confusion.

>> I originally abandoned gralloc_drm_freedreno once I realized that for
>> the refcnt'ing to work out I needed gralloc to share the same
>> fd_device ptr as mesa/gl.  And by using gralloc_drm_pipe (plus that
>> freedreno winsys code I pointed to earlier) both gralloc and the gl
>> context share the same pipe_screen (and fd_device).
>
> Looks like this was the main problem. With screen ref counting and
> prime handle lookups, virgl seems to be working now.
>
> The radeon driver also does the same ref counting. Shouldn't this be
> common code rather than duplicated in each driver?

Yeah, probably.  I think radeon and nouveau ended up implementing
similar sort of code for buffer sharing between gl and vdpau, where
basically the same sort of issue comes up.  And I copied from one of
the two once I realized what was going on.

Might even be some room for some re-use on the libdrm side, but things
kinda grew organically there too.  In both cases it is just a little
bit of code you more or less write / copypaste once and then never
look at again, so I guess by the time things work people forget to go
back and refactor.. at least that's my excuse ;-)

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

[Mesa-dev] [Bug 92687] Add support for ARB_internalformat_query2

[bugzilla-daemon]

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

--- Comment #5 from Alejandro Piñeiro (freenode IRC: apinheiro) 
 ---
(In reply to Eduardo Lima Mitev from comment #1)
> About time for an update! The "we" below refers to Antía, Alejandro and I,
> as the team working primarily on this extension for almost 2 months now.
> 
> From a high level point of view, we have completed more or less all the
> implementation bits. This means that all the code-flow and plumbery is
> already in place, but we still need to iterate on the implementation of
> specific queries. There are some queries for which we have doubts related to
> the wording in the spec, others about what the correct answer from Mesa
> should be, etc. We will post these issues/questions separately, in another
> update.
> 
> The current code can be checked at:
> 
> Mesa: https://github.com/Igalia/mesa/tree/internalformat-query2-rfc
> Piglit: https://github.com/Igalia/piglit/tree/internalformat-query2-rfc

A ready to review (no RFC) piglit series was sent to the mailing list:
http://lists.freedesktop.org/archives/piglit/2016-January/018777.html

In case you want to download all the patches from a repository, instead of the
rfc branch, you can use this one:
https://github.com/Igalia/piglit/tree/internalformat-query2

-- 
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] [PATCH 1/2] configure.ac: don't require EGL/DRM ang GBM if OpenGL is disabled

[Marek Olšák]

On Fri, Jan 22, 2016 at 6:02 PM, Emil Velikov  wrote:
> On 22 January 2016 at 16:50, Marek Olšák  wrote:
>> On Fri, Jan 22, 2016 at 5:32 PM, Emil Velikov  
>> wrote:
>>> Hi Marek,
>>>
>>> On 22 January 2016 at 12:24, Marek Olšák  wrote:
 Hi Emil,

 Do you have any comment on this series?

>>> I was secretly hoping that you'll forget about this patch because...
>>>
 Marek

 On Tue, Jan 12, 2016 at 8:46 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> This allows building VDPAU/OMX/VA drivers without OpenGL and its
> dependencies.
> ---
>  configure.ac | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 8d19dab..04b5fd8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2159,7 +2159,12 @@ gallium_require_drm_loader() {
>  fi
>  }
>
> +dnl This is for Glamor. Skip this if OpenGL is disabled.
>  require_egl_drm() {
> +if test "x$enable_opengl" = xno; then
> +return 0
> +fi
> +
>  case "$with_egl_platforms" in
>  *drm*)
>  ;;
>>> ... the hole idea of having this error out is a gross workaround imho.
>>> While I could not find anything concrete to point out initially seems
>>> like you have found it. And now we add a workaround on top of the
>>> workaround :-\
>>>
>>> Yes it is (very) unlikely that radeonsi GPUs will have 2d accel
>>> without glamor and yes it is required in those cases. But that does
>>> not mean that we must mandate egl+drm but recommend it ? After all one
>>> can have egl+wayland+radeonsi mesa (without egl+drm) on a xserver-less
>>> setup, can't they ?
>>
>> I don't know what Wayland uses, but if it doesn't use egl+drm, that's fine.
>>
>> We still have to require egl+drm for GLX/DRI support, so we can loosen
>> the requirement a little bit, but we can't remove it completely.
>> That's how I see it.
>>
> The point I'm making is that one cannot forsee what the user will do
> (run) at build time. Thus sticking with a big fan warning is a
> sensible thing to do. If no-one pays attention to the warnings (I've
> been guilty a few times as well) then it's their own fault - it's not
> like we print (m)any and things get lost amidst the noise ?

Michel, any opinion on removing require_egl_drm from configure.ac?

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

Re: [Mesa-dev] [PATCH 00/10] vbo: introduce a minmax_index cache (v3)

[Nicolai Hähnle]

On 11.01.2016 21:32, Nicolai Hähnle wrote:

here is a new version of the series. I'm calling it v3 even though I never
sent v2 because it contains v3 of the main patch. Changes relative to v1:

- disable cache on USAGE_TEXTURE_BUFFER and bool/GLboolean nit
- disable cache only temporarily when a persistent writable mapping exists
- add a MESA_NO_MINMAX_CACHE environment variable that disables caches
   completely
- track hits and misses and disable the cache on a per-BO basis if the
   hit rate is low

The last point is on a per-BO basis because applications don't always have
the same usage pattern for all BOs.

There is also a new util/hash_table patch which I added for an idea that I
ultimately rejected, but it turns out to be useful elsewhere, so I'm
sending it along while I'm at it.

I benchmarked this series with a couple of tests from PTS, using low
resolutions in an attempt to emphasize CPU usage. Their performance is
unaffected, with averages with/without this series within the measurement
tolerance of each other. That there's no regression is good news, and that
there's no improvement is to be expected - if one of these tests had been
affected by the problem this series addresses, someone else would probably
have done it much earlier ;)

Please review!


Ping... any opinions on this series? Other than Matt's coding style 
comment, I haven't received anything.


Nicolai


Thanks,
Nicolai
--
  docs/envvars.html |   1 +
  src/mesa/Makefile.sources |   1 +
  src/mesa/main/bufferobj.c |  59 +++-
  src/mesa/main/hash.c  |   4 +-
  src/mesa/main/mtypes.h|   9 +
  src/mesa/main/transformfeedback.h |   3 +
  src/mesa/vbo/vbo.h|   3 +
  src/mesa/vbo/vbo_exec_array.c | 148 --
  src/mesa/vbo/vbo_minmax_index.c   | 378 
  src/util/hash_table.c |  25 ++
  src/util/hash_table.h |   7 +
  src/util/tests/hash_table/Makefile.am |   1 +
  src/util/tests/hash_table/clear.c |  91 ++
  13 files changed, 570 insertions(+), 160 deletions(-)


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

[Mesa-dev] [Bug 93813] Incorrect viewport range when GL_CLIP_ORIGIN is GL_UPPER_LEFT

[bugzilla-daemon]

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

--- Comment #3 from Ilia Mirkin  ---
A bit of potentially-relevant spec quote from ARB_clip_control:

12) Does setting the clip control origin to GL_UPPER_LEFT change the
origin of the window coordinate system use for commands such as
glViewport, glScissor, glWindowPos2i, and glReadPixels?

RESOLVED:  No.

The (x,y) window space location passed to these commands have the
(0,0) origin at the lower left corner of the window, independent
of the state of the clip control origin.

Still unsure whether that rules in favor of Mesa or of the test case :)
Hopefully someone more knowledgeable can weigh in.

-- 
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 4/4] radeonsi: change LLVM intrinsics for BREV, CLAMP, EX2

[Marek Olšák]

From: Marek Olšák 

Requested by Matt Arsenault.
---
 src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c 
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index c94f109..76be376 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -1511,12 +1511,14 @@ void radeon_llvm_context_init(struct 
radeon_llvm_context * ctx)
bld_base->op_actions[TGSI_OPCODE_BFI].emit = emit_bfi;
bld_base->op_actions[TGSI_OPCODE_BGNLOOP].emit = bgnloop_emit;
bld_base->op_actions[TGSI_OPCODE_BREV].emit = 
build_tgsi_intrinsic_nomem;
-   bld_base->op_actions[TGSI_OPCODE_BREV].intr_name = "llvm.AMDGPU.brev";
+   bld_base->op_actions[TGSI_OPCODE_BREV].intr_name =
+   HAVE_LLVM >= 0x0308 ? "llvm.bitreverse.i32" : 
"llvm.AMDGPU.brev";
bld_base->op_actions[TGSI_OPCODE_BRK].emit = brk_emit;
bld_base->op_actions[TGSI_OPCODE_CEIL].emit = 
build_tgsi_intrinsic_nomem;
bld_base->op_actions[TGSI_OPCODE_CEIL].intr_name = "llvm.ceil.f32";
bld_base->op_actions[TGSI_OPCODE_CLAMP].emit = 
build_tgsi_intrinsic_nomem;
-   bld_base->op_actions[TGSI_OPCODE_CLAMP].intr_name = "llvm.AMDIL.clamp.";
+   bld_base->op_actions[TGSI_OPCODE_CLAMP].intr_name =
+   HAVE_LLVM >= 0x0308 ? "llvm.AMDGPU.clamp." : 
"llvm.AMDIL.clamp.";
bld_base->op_actions[TGSI_OPCODE_CMP].emit = emit_cmp;
bld_base->op_actions[TGSI_OPCODE_CONT].emit = cont_emit;
bld_base->op_actions[TGSI_OPCODE_COS].emit = build_tgsi_intrinsic_nomem;
@@ -1539,7 +1541,8 @@ void radeon_llvm_context_init(struct radeon_llvm_context 
* ctx)
bld_base->op_actions[TGSI_OPCODE_ENDIF].emit = endif_emit;
bld_base->op_actions[TGSI_OPCODE_ENDLOOP].emit = endloop_emit;
bld_base->op_actions[TGSI_OPCODE_EX2].emit = build_tgsi_intrinsic_nomem;
-   bld_base->op_actions[TGSI_OPCODE_EX2].intr_name = "llvm.AMDIL.exp.";
+   bld_base->op_actions[TGSI_OPCODE_EX2].intr_name =
+   HAVE_LLVM >= 0x0308 ? "llvm.exp2.f32" : "llvm.AMDIL.exp.";
bld_base->op_actions[TGSI_OPCODE_FLR].emit = build_tgsi_intrinsic_nomem;
bld_base->op_actions[TGSI_OPCODE_FLR].intr_name = "llvm.floor.f32";
bld_base->op_actions[TGSI_OPCODE_FMA].emit = build_tgsi_intrinsic_nomem;
-- 
2.1.4

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

[Mesa-dev] [PATCH 2/4] radeonsi: enable late VS allocation (v3)

[Marek Olšák]

From: Marek Olšák 

v2: take the number of CUs into account
v3: change in LS allocation
---
 src/gallium/drivers/radeonsi/si_state.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 67b2835..ef709ee 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3701,12 +3701,32 @@ static void si_init_config(struct si_context *sctx)
si_pm4_set_reg(pm4, R_028408_VGT_INDX_OFFSET, 0);
 
if (sctx->b.chip_class >= CIK) {
-   si_pm4_set_reg(pm4, R_00B51C_SPI_SHADER_PGM_RSRC3_LS, 
S_00B51C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B41C_SPI_SHADER_PGM_RSRC3_HS, 0);
si_pm4_set_reg(pm4, R_00B31C_SPI_SHADER_PGM_RSRC3_ES, 
S_00B31C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B21C_SPI_SHADER_PGM_RSRC3_GS, 
S_00B21C_CU_EN(0x));
-   si_pm4_set_reg(pm4, R_00B118_SPI_SHADER_PGM_RSRC3_VS, 
S_00B118_CU_EN(0x));
-   si_pm4_set_reg(pm4, R_00B11C_SPI_SHADER_LATE_ALLOC_VS, 
S_00B11C_LIMIT(0));
+
+   if (sscreen->b.info.num_good_compute_units /
+   (sscreen->b.info.max_se * sscreen->b.info.max_sh_per_se) <= 
4) {
+   /* Too few available compute units per SH. Disallowing
+* VS to run on CU0 could hurt us more than late VS
+* allocation would help.
+*
+* LATE_ALLOC_VS = 2 is the highest safe number.
+*/
+   si_pm4_set_reg(pm4, R_00B51C_SPI_SHADER_PGM_RSRC3_LS, 
S_00B51C_CU_EN(0x));
+   si_pm4_set_reg(pm4, R_00B118_SPI_SHADER_PGM_RSRC3_VS, 
S_00B118_CU_EN(0x));
+   si_pm4_set_reg(pm4, R_00B11C_SPI_SHADER_LATE_ALLOC_VS, 
S_00B11C_LIMIT(2));
+   } else {
+   /* Set LATE_ALLOC_VS == 31. It should be less than
+* the number of scratch waves. Limitations:
+* - VS can't execute on CU0.
+* - If HS writes outputs to LDS, LS can't execute on 
CU0.
+*/
+   si_pm4_set_reg(pm4, R_00B51C_SPI_SHADER_PGM_RSRC3_LS, 
S_00B51C_CU_EN(0xfffe));
+   si_pm4_set_reg(pm4, R_00B118_SPI_SHADER_PGM_RSRC3_VS, 
S_00B118_CU_EN(0xfffe));
+   si_pm4_set_reg(pm4, R_00B11C_SPI_SHADER_LATE_ALLOC_VS, 
S_00B11C_LIMIT(31));
+   }
+
si_pm4_set_reg(pm4, R_00B01C_SPI_SHADER_PGM_RSRC3_PS, 
S_00B01C_CU_EN(0x));
}
 
-- 
2.1.4

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

[Mesa-dev] [PATCH 1/4] radeonsi: allow using all CUs for tessellation and on-chip GS (v2)

[Marek Olšák]

From: Marek Olšák 

v2: After more discussion with hw teams, the kernel already contains the
optimal settings allowing us to use all CUs.
---
 src/gallium/drivers/radeonsi/si_state.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index a3ddee8..67b2835 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3701,9 +3701,9 @@ static void si_init_config(struct si_context *sctx)
si_pm4_set_reg(pm4, R_028408_VGT_INDX_OFFSET, 0);
 
if (sctx->b.chip_class >= CIK) {
-   si_pm4_set_reg(pm4, R_00B51C_SPI_SHADER_PGM_RSRC3_LS, 
S_00B51C_CU_EN(0xfffc));
+   si_pm4_set_reg(pm4, R_00B51C_SPI_SHADER_PGM_RSRC3_LS, 
S_00B51C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B41C_SPI_SHADER_PGM_RSRC3_HS, 0);
-   si_pm4_set_reg(pm4, R_00B31C_SPI_SHADER_PGM_RSRC3_ES, 
S_00B31C_CU_EN(0xfffe));
+   si_pm4_set_reg(pm4, R_00B31C_SPI_SHADER_PGM_RSRC3_ES, 
S_00B31C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B21C_SPI_SHADER_PGM_RSRC3_GS, 
S_00B21C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B118_SPI_SHADER_PGM_RSRC3_VS, 
S_00B118_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B11C_SPI_SHADER_LATE_ALLOC_VS, 
S_00B11C_LIMIT(0));
-- 
2.1.4

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

[Mesa-dev] [PATCH 3/4] radeonsi: add max waves / SIMD to shader stats (v2)

[Marek Olšák]

From: Marek Olšák 

v2: account for LDS usage in PS
the limit is per SIMD, not per CU
---
 src/gallium/drivers/radeonsi/si_shader.c | 54 +---
 1 file changed, 49 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 1bd617f..33c0db6 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -4001,22 +4001,65 @@ static void si_shader_dump_disassembly(const struct 
radeon_shader_binary *binary
 
 static void si_shader_dump_stats(struct si_screen *sscreen,
 struct si_shader_config *conf,
+unsigned num_inputs,
 unsigned code_size,
 struct pipe_debug_callback *debug,
 unsigned processor)
 {
+   unsigned lds_increment = sscreen->b.chip_class >= CIK ? 512 : 256;
+   unsigned lds_per_wave = 0;
+   unsigned max_simd_waves = 10;
+
+   /* Compute LDS usage for PS. */
+   if (processor == TGSI_PROCESSOR_FRAGMENT) {
+   /* The minimum usage per wave is (num_inputs * 36). The maximum
+* usage is (num_inputs * 36 * 16).
+* We can get anything in between and it varies between waves.
+*
+* Other stages don't know the size at compile time or don't
+* allocate LDS per wave, but instead they do it per thread 
group.
+*/
+   lds_per_wave = conf->lds_size * lds_increment +
+  align(num_inputs * 36, lds_increment);
+   }
+
+   /* Compute the per-SIMD wave counts. */
+   if (conf->num_sgprs) {
+   if (sscreen->b.chip_class >= VI)
+   max_simd_waves = MIN2(max_simd_waves, 800 / 
conf->num_sgprs);
+   else
+   max_simd_waves = MIN2(max_simd_waves, 512 / 
conf->num_sgprs);
+   }
+
+   if (conf->num_vgprs)
+   max_simd_waves = MIN2(max_simd_waves, 256 / conf->num_vgprs);
+
+   /* LDS is 64KB per CU (4 SIMDs), divided into 16KB blocks per SIMD
+* that PS can use.
+*/
+   if (lds_per_wave)
+   max_simd_waves = MIN2(max_simd_waves, 16384 / lds_per_wave);
+
if (r600_can_dump_shader(>b, processor)) {
fprintf(stderr, "*** SHADER STATS ***\n"
-   "SGPRS: %d\nVGPRS: %d\nCode Size: %d bytes\nLDS: %d 
blocks\n"
-   "Scratch: %d bytes per wave\n\n",
+   "SGPRS: %d\n"
+   "VGPRS: %d\n"
+   "Code Size: %d bytes\n"
+   "LDS: %d blocks\n"
+   "Scratch: %d bytes per wave\n"
+   "Max Waves: %d\n"
+   "\n",
conf->num_sgprs, conf->num_vgprs, code_size,
-   conf->lds_size, conf->scratch_bytes_per_wave);
+   conf->lds_size, conf->scratch_bytes_per_wave,
+   max_simd_waves);
}
 
pipe_debug_message(debug, SHADER_INFO,
-  "Shader Stats: SGPRS: %d VGPRS: %d Code Size: %d 
LDS: %d Scratch: %d",
+  "Shader Stats: SGPRS: %d VGPRS: %d Code Size: %d "
+  "LDS: %d Scratch: %d Max Waves: %d",
   conf->num_sgprs, conf->num_vgprs, code_size,
-  conf->lds_size, conf->scratch_bytes_per_wave);
+  conf->lds_size, conf->scratch_bytes_per_wave,
+  max_simd_waves);
 }
 
 void si_shader_dump(struct si_screen *sscreen, struct si_shader *shader,
@@ -4027,6 +4070,7 @@ void si_shader_dump(struct si_screen *sscreen, struct 
si_shader *shader,
si_shader_dump_disassembly(>binary, debug);
 
si_shader_dump_stats(sscreen, >config,
+shader->selector->info.num_inputs,
 shader->binary.code_size, debug, processor);
 }
 
-- 
2.1.4

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

Re: [Mesa-dev] [PATCH 2/2] gallium: always build glsl for gallium

[Emil Velikov]

On 12 January 2016 at 21:46, Marek Olšák  wrote:
> From: Jammy Zhou 
>
> It is needed if the GL/ES build is disabled. Otherwise, there will
> be an error that nir_opcodes.h is missing. The motivation is to allow
> building Gallium VDPAU/OMX/VA without OpenGL.
>
Unless I'm mistaken NIR is required by the aux/ttn module which is
used only by a few gallium drivers ? I'm leaning that a better option
would be to have a "NEED_NIR" conditional.

Regardless I'll kindly request that we hold his off for a couple more
days, as it will have a nasty interaction with my "move glsl/nir to
compiler" series. With that one in place we'll be building glsl/nir
even in the above mentioned case (to be tweaked as needed).

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

[Mesa-dev] [Bug 93820] Change from Mesa 10 to 11 made remote opengl stop working

[bugzilla-daemon]

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

Mark Janes  changed:

   What|Removed |Added

 CC||mark.a.ja...@intel.com

-- 
You are receiving this mail because:
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 1/2] configure.ac: don't require EGL/DRM ang GBM if OpenGL is disabled

[Marek Olšák]

On Fri, Jan 22, 2016 at 5:32 PM, Emil Velikov  wrote:
> Hi Marek,
>
> On 22 January 2016 at 12:24, Marek Olšák  wrote:
>> Hi Emil,
>>
>> Do you have any comment on this series?
>>
> I was secretly hoping that you'll forget about this patch because...
>
>> Marek
>>
>> On Tue, Jan 12, 2016 at 8:46 PM, Marek Olšák  wrote:
>>> From: Marek Olšák 
>>>
>>> This allows building VDPAU/OMX/VA drivers without OpenGL and its
>>> dependencies.
>>> ---
>>>  configure.ac | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 8d19dab..04b5fd8 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -2159,7 +2159,12 @@ gallium_require_drm_loader() {
>>>  fi
>>>  }
>>>
>>> +dnl This is for Glamor. Skip this if OpenGL is disabled.
>>>  require_egl_drm() {
>>> +if test "x$enable_opengl" = xno; then
>>> +return 0
>>> +fi
>>> +
>>>  case "$with_egl_platforms" in
>>>  *drm*)
>>>  ;;
> ... the hole idea of having this error out is a gross workaround imho.
> While I could not find anything concrete to point out initially seems
> like you have found it. And now we add a workaround on top of the
> workaround :-\
>
> Yes it is (very) unlikely that radeonsi GPUs will have 2d accel
> without glamor and yes it is required in those cases. But that does
> not mean that we must mandate egl+drm but recommend it ? After all one
> can have egl+wayland+radeonsi mesa (without egl+drm) on a xserver-less
> setup, can't they ?

I don't know what Wayland uses, but if it doesn't use egl+drm, that's fine.

We still have to require egl+drm for GLX/DRI support, so we can loosen
the requirement a little bit, but we can't remove it completely.
That's how I see it.

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

[Mesa-dev] [PATCH 2/2] draw: use util_pstipple_* function for stipple pattern textures and samplers

[Nicolai Hähnle]

From: Nicolai Hähnle 

This reduces code duplication.

Suggested-by: Jose Fonseca 
---
 src/gallium/auxiliary/draw/draw_pipe_pstipple.c | 121 +++-
 src/gallium/auxiliary/util/u_pstipple.c |   4 +-
 src/gallium/auxiliary/util/u_pstipple.h |   5 +
 3 files changed, 18 insertions(+), 112 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c 
b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
index e468cc3..0298334 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
@@ -153,113 +153,6 @@ generate_pstip_fs(struct pstip_stage *pstip)
 
 
 /**
- * Load texture image with current stipple pattern.
- */
-static void
-pstip_update_texture(struct pstip_stage *pstip)
-{
-   static const uint bit31 = 1 << 31;
-   struct pipe_context *pipe = pstip->pipe;
-   struct pipe_transfer *transfer;
-   const uint *stipple = pstip->state.stipple->stipple;
-   uint i, j;
-   ubyte *data;
-
-   data = pipe_transfer_map(pipe, pstip->texture, 0, 0,
-PIPE_TRANSFER_WRITE, 0, 0, 32, 32, );
-
-   /*
-* Load alpha texture.
-* Note: 0 means keep the fragment, 255 means kill it.
-* We'll negate the texel value and use KILL_IF which kills if value
-* is negative.
-*/
-   for (i = 0; i < 32; i++) {
-  for (j = 0; j < 32; j++) {
- if (stipple[i] & (bit31 >> j)) {
-/* fragment "on" */
-data[i * transfer->stride + j] = 0;
- }
- else {
-/* fragment "off" */
-data[i * transfer->stride + j] = 255;
- }
-  }
-   }
-
-   /* unmap */
-   pipe_transfer_unmap(pipe, transfer);
-}
-
-
-/**
- * Create the texture map we'll use for stippling.
- */
-static boolean
-pstip_create_texture(struct pstip_stage *pstip)
-{
-   struct pipe_context *pipe = pstip->pipe;
-   struct pipe_screen *screen = pipe->screen;
-   struct pipe_resource texTemp;
-   struct pipe_sampler_view viewTempl;
-
-   memset(, 0, sizeof(texTemp));
-   texTemp.target = PIPE_TEXTURE_2D;
-   texTemp.format = PIPE_FORMAT_A8_UNORM; /* XXX verify supported by driver! */
-   texTemp.last_level = 0;
-   texTemp.width0 = 32;
-   texTemp.height0 = 32;
-   texTemp.depth0 = 1;
-   texTemp.array_size = 1;
-   texTemp.bind = PIPE_BIND_SAMPLER_VIEW;
-
-   pstip->texture = screen->resource_create(screen, );
-   if (pstip->texture == NULL)
-  return FALSE;
-
-   u_sampler_view_default_template(,
-   pstip->texture,
-   pstip->texture->format);
-   pstip->sampler_view = pipe->create_sampler_view(pipe,
-   pstip->texture,
-   );
-   if (!pstip->sampler_view) {
-  return FALSE;
-   }
-
-   return TRUE;
-}
-
-
-/**
- * Create the sampler CSO that'll be used for stippling.
- */
-static boolean
-pstip_create_sampler(struct pstip_stage *pstip)
-{
-   struct pipe_sampler_state sampler;
-   struct pipe_context *pipe = pstip->pipe;
-
-   memset(, 0, sizeof(sampler));
-   sampler.wrap_s = PIPE_TEX_WRAP_REPEAT;
-   sampler.wrap_t = PIPE_TEX_WRAP_REPEAT;
-   sampler.wrap_r = PIPE_TEX_WRAP_REPEAT;
-   sampler.min_mip_filter = PIPE_TEX_MIPFILTER_NONE;
-   sampler.min_img_filter = PIPE_TEX_FILTER_NEAREST;
-   sampler.mag_img_filter = PIPE_TEX_FILTER_NEAREST;
-   sampler.normalized_coords = 1;
-   sampler.min_lod = 0.0f;
-   sampler.max_lod = 0.0f;
-
-   pstip->sampler_cso = pipe->create_sampler_state(pipe, );
-   if (pstip->sampler_cso == NULL)
-  return FALSE;
-   
-   return TRUE;
-}
-
-
-/**
  * When we're about to draw our first stipple polygon in a batch, this function
  * is called to tell the driver to bind our modified fragment shader.
  */
@@ -537,7 +430,8 @@ pstip_set_polygon_stipple(struct pipe_context *pipe,
/* pass-through */
pstip->driver_set_polygon_stipple(pstip->pipe, stipple);
 
-   pstip_update_texture(pstip);
+   util_pstipple_update_stipple_texture(pstip->pipe, pstip->texture,
+pstip->state.stipple->stipple);
 }
 
 
@@ -573,10 +467,17 @@ draw_install_pstipple_stage(struct draw_context *draw,
pstip->driver_set_polygon_stipple = pipe->set_polygon_stipple;
 
/* create special texture, sampler state */
-   if (!pstip_create_texture(pstip))
+   pstip->texture = util_pstipple_create_stipple_texture(pipe, NULL);
+   if (!pstip->texture)
+  goto fail;
+
+   pstip->sampler_view = util_pstipple_create_sampler_view(pipe,
+   pstip->texture);
+   if (!pstip->sampler_view)
   goto fail;
 
-   if (!pstip_create_sampler(pstip))
+   pstip->sampler_cso = util_pstipple_create_sampler(pipe);
+   if (!pstip->sampler_cso)
   goto fail;
 
/* override the driver's functions */
diff --git a/src/gallium/auxiliary/util/u_pstipple.c 

[Mesa-dev] [PATCH 1/2] draw: use util_pstipple_create_fragment_shader

[Nicolai Hähnle]

From: Nicolai Hähnle 

This reduces code duplication. It also adds support for drivers where the
fragment position is a system value.

Suggested-by: Jose Fonseca 
---
A basic polygon stippling test shows no regression on llvmpipe, but that's
the extent of my testing.

 src/gallium/auxiliary/draw/draw_pipe_pstipple.c | 209 ++--
 1 file changed, 12 insertions(+), 197 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c 
b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
index cf52ca4..e468cc3 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
@@ -43,10 +43,10 @@
 #include "util/u_format.h"
 #include "util/u_math.h"
 #include "util/u_memory.h"
+#include "util/u_pstipple.h"
 #include "util/u_sampler.h"
 
 #include "tgsi/tgsi_transform.h"
-#include "tgsi/tgsi_dump.h"
 
 #include "draw_context.h"
 #include "draw_pipe.h"
@@ -114,178 +114,6 @@ struct pstip_stage
 };
 
 
-
-/**
- * Subclass of tgsi_transform_context, used for transforming the
- * user's fragment shader to add the extra texture sample and fragment kill
- * instructions.
- */
-struct pstip_transform_context {
-   struct tgsi_transform_context base;
-   uint tempsUsed;  /**< bitmask */
-   int wincoordInput;
-   int maxInput;
-   uint samplersUsed;  /**< bitfield of samplers used */
-   bool hasSview;
-   int freeSampler;  /** an available sampler for the pstipple */
-   int texTemp;  /**< temp registers */
-   int numImmed;
-};
-
-
-/**
- * TGSI declaration transform callback.
- * Look for a free sampler, a free input attrib, and two free temp regs.
- */
-static void
-pstip_transform_decl(struct tgsi_transform_context *ctx,
- struct tgsi_full_declaration *decl)
-{
-   struct pstip_transform_context *pctx = (struct pstip_transform_context *) 
ctx;
-
-   if (decl->Declaration.File == TGSI_FILE_SAMPLER) {
-  uint i;
-  for (i = decl->Range.First;
-   i <= decl->Range.Last; i++) {
- pctx->samplersUsed |= 1 << i;
-  }
-   }
-   else if (decl->Declaration.File == TGSI_FILE_SAMPLER_VIEW) {
-  pctx->hasSview = true;
-   }
-   else if (decl->Declaration.File == TGSI_FILE_INPUT) {
-  pctx->maxInput = MAX2(pctx->maxInput, (int) decl->Range.Last);
-  if (decl->Semantic.Name == TGSI_SEMANTIC_POSITION)
- pctx->wincoordInput = (int) decl->Range.First;
-   }
-   else if (decl->Declaration.File == TGSI_FILE_TEMPORARY) {
-  uint i;
-  for (i = decl->Range.First;
-   i <= decl->Range.Last; i++) {
- pctx->tempsUsed |= (1 << i);
-  }
-   }
-
-   ctx->emit_declaration(ctx, decl);
-}
-
-
-/**
- * TGSI immediate declaration transform callback.
- * We're just counting the number of immediates here.
- */
-static void
-pstip_transform_immed(struct tgsi_transform_context *ctx,
-  struct tgsi_full_immediate *immed)
-{
-   struct pstip_transform_context *pctx = (struct pstip_transform_context *) 
ctx;
-   ctx->emit_immediate(ctx, immed); /* emit to output shader */
-   pctx->numImmed++;
-}
-
-
-/**
- * Find the lowest zero bit in the given word, or -1 if bitfield is all ones.
- */
-static int
-free_bit(uint bitfield)
-{
-   return ffs(~bitfield) - 1;
-}
-
-
-/**
- * TGSI transform prolog callback.
- */
-static void
-pstip_transform_prolog(struct tgsi_transform_context *ctx)
-{
-   struct pstip_transform_context *pctx = (struct pstip_transform_context *) 
ctx;
-   uint i;
-   int wincoordInput;
-
-   /* find free sampler */
-   pctx->freeSampler = free_bit(pctx->samplersUsed);
-   if (pctx->freeSampler >= PIPE_MAX_SAMPLERS)
-  pctx->freeSampler = PIPE_MAX_SAMPLERS - 1;
-
-   if (pctx->wincoordInput < 0)
-  wincoordInput = pctx->maxInput + 1;
-   else
-  wincoordInput = pctx->wincoordInput;
-
-   /* find one free temp reg */
-   for (i = 0; i < 32; i++) {
-  if ((pctx->tempsUsed & (1 << i)) == 0) {
-  /* found a free temp */
-  if (pctx->texTemp < 0)
- pctx->texTemp  = i;
-  else
- break;
-  }
-   }
-   assert(pctx->texTemp >= 0);
-
-   if (pctx->wincoordInput < 0) {
-  /* declare new position input reg */
-  tgsi_transform_input_decl(ctx, wincoordInput,
-TGSI_SEMANTIC_POSITION, 1,
-TGSI_INTERPOLATE_LINEAR);
-   }
-
-   /* declare new sampler */
-   tgsi_transform_sampler_decl(ctx, pctx->freeSampler);
-
-   /* if the src shader has SVIEW decl's for each SAMP decl, we
-* need to continue the trend and ensure there is a matching
-* SVIEW for the new SAMP we just created
-*/
-   if (pctx->hasSview) {
-  tgsi_transform_sampler_view_decl(ctx,
-   pctx->freeSampler,
-   TGSI_TEXTURE_2D,
-   TGSI_RETURN_TYPE_FLOAT);
-   }
-
-   /* declare new temp regs */
-   

Re: [Mesa-dev] [PATCH] st/mesa: conditionally enable GL_NV_vdpau_interop

[Emil Velikov]

Form autofoo perspective things look great.

Although I second Ilia's concern - we need a form of runtime detection
here. Pretty much all distros ship the vdpau(+ other video driver
backend) in a separate library. Thus this will likely get us nowhere
we want - as I'm suspecting this is to assist the unsuspecting user,
which hasn't installed package X or Y in the first place ?

I won't object against it but please can we get a big fat warning/note
- anything vaguely alike "this is a hack until we get a runtime
detection of the presence/interop of the partner library/module" will
be great.

Thanks
Emil

On 21 January 2016 at 21:02, Christian König  wrote:
> Advertising NV_vdpau_interop while the backend for the driver isn't
> installed is fine, cause this only means that the OpenGL side has support
> for it.
>
> Mesa doesn't have a runtime dependency on libvdpau and to initialize
> NV_vdpau_interop the application must open libvdpau first.
>
> So if libvdpau isn't installed this will fail way even before Mesa into the
> picture.
>
> My question is rather if that's the right approach? I'm not really an expert
> on autohell.
>
> Regards,
> Christian.
>
>
> Am 21.01.2016 um 17:09 schrieb Ilia Mirkin:
>>
>> I wonder if something more robust is needed. Let's say a distro builds
>> with vdpau and everything else enabled, but then ships the libraries
>> separately...
>>
>> On Thu, Jan 21, 2016 at 11:05 AM, Christian König
>>  wrote:
>>>
>>> From: Christian König 
>>>
>>> Only enable it when we compile the state tracker as well.
>>>
>>> Signed-off-by: Christian König 
>>> ---
>>>   configure.ac   | 1 +
>>>   src/mesa/state_tracker/st_extensions.c | 2 ++
>>>   src/mesa/state_tracker/st_vdpau.c  | 6 ++
>>>   3 files changed, 9 insertions(+)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 8d19dab..a92f707 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -1741,6 +1741,7 @@ AM_CONDITIONAL(HAVE_ST_XVMC, test "x$enable_xvmc" =
>>> xyes)
>>>   if test "x$enable_vdpau" = xyes; then
>>>   PKG_CHECK_MODULES([VDPAU], [vdpau >= $VDPAU_REQUIRED])
>>>   gallium_st="$gallium_st vdpau"
>>> +DEFINES="$DEFINES -DHAVE_ST_VDPAU"
>>>   fi
>>>   AM_CONDITIONAL(HAVE_ST_VDPAU, test "x$enable_vdpau" = xyes)
>>>
>>> diff --git a/src/mesa/state_tracker/st_extensions.c
>>> b/src/mesa/state_tracker/st_extensions.c
>>> index 2a3e523..25e88ea 100644
>>> --- a/src/mesa/state_tracker/st_extensions.c
>>> +++ b/src/mesa/state_tracker/st_extensions.c
>>> @@ -959,12 +959,14 @@ void st_init_extensions(struct pipe_screen *screen,
>>> extensions->ARB_ES3_compatibility = GL_TRUE;
>>>  }
>>>
>>> +#ifdef HAVE_ST_VDPAU
>>>  if (screen->get_video_param &&
>>>  screen->get_video_param(screen, PIPE_VIDEO_PROFILE_UNKNOWN,
>>>  PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
>>>  PIPE_VIDEO_CAP_SUPPORTS_INTERLACED)) {
>>> extensions->NV_vdpau_interop = GL_TRUE;
>>>  }
>>> +#endif
>>>
>>>  if (screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
>>>   PIPE_SHADER_CAP_DOUBLES) &&
>>> diff --git a/src/mesa/state_tracker/st_vdpau.c
>>> b/src/mesa/state_tracker/st_vdpau.c
>>> index 63af119..71dd15b 100644
>>> --- a/src/mesa/state_tracker/st_vdpau.c
>>> +++ b/src/mesa/state_tracker/st_vdpau.c
>>> @@ -49,6 +49,8 @@
>>>   #include "st_format.h"
>>>   #include "st_cb_flush.h"
>>>
>>> +#ifdef HAVE_ST_VDPAU
>>> +
>>>   static void
>>>   st_vdpau_map_surface(struct gl_context *ctx, GLenum target, GLenum
>>> access,
>>>GLboolean output, struct gl_texture_object
>>> *texObj,
>>> @@ -180,9 +182,13 @@ st_vdpau_unmap_surface(struct gl_context *ctx,
>>> GLenum target, GLenum access,
>>>  st_flush(st, NULL, 0);
>>>   }
>>>
>>> +#endif
>>> +
>>>   void
>>>   st_init_vdpau_functions(struct dd_function_table *functions)
>>>   {
>>> +#ifdef HAVE_ST_VDPAU
>>>  functions->VDPAUMapSurface = st_vdpau_map_surface;
>>>  functions->VDPAUUnmapSurface = st_vdpau_unmap_surface;
>>> +#endif
>>>   }
>>> --
>>> 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

[Mesa-dev] [Bug 93628] Exception: attempt to use unavailable module DRM when building MesaGL 11.1.0 on windows

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

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

--- Comment #3 from Emil Velikov  ---
Looks like the we also need commit 4befd82a649 "pipe-loader: Fix PATH_MAX
define on MSVC.". I've scooped both for 11.1.2 which should be out in a few
days.

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

Re: [Mesa-dev] [PATCH 3/4] glsl: add support for GL_OES_geometry_shader

[Lofstedt, Marta]

> -Original Message-
> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia
> Mirkin
> Sent: Thursday, January 21, 2016 4:33 PM
> To: Marta Lofstedt
> Cc: mesa-dev@lists.freedesktop.org; Lofstedt, Marta
> Subject: Re: [PATCH 3/4] glsl: add support for GL_OES_geometry_shader
> 
> On Thu, Jan 21, 2016 at 10:17 AM, Marta Lofstedt
>  wrote:
> > From: Marta Lofstedt 
> >
> > This adds glsl support of GL_OES_geometry_shader for OpenGL ES 3.1.
> >
> > Signed-off-by: Marta Lofstedt 
> > Reviewed-by: Ian Romanick 
> > ---
> >  src/glsl/builtin_variables.cpp  | 25 +
> >  src/glsl/glsl_parser.yy |  4 ++--
> >  src/glsl/glsl_parser_extras.cpp |  1 +
> >  src/glsl/glsl_parser_extras.h   |  7 +++
> >  4 files changed, 23 insertions(+), 14 deletions(-)
> >
> > diff --git a/src/glsl/builtin_variables.cpp
> > b/src/glsl/builtin_variables.cpp index 221aab0..ccc04c0 100644
> > --- a/src/glsl/builtin_variables.cpp
> > +++ b/src/glsl/builtin_variables.cpp
> > @@ -667,7 +667,7 @@ builtin_variable_generator::generate_constants()
> >add_const("gl_MaxVaryingComponents", state->ctx-
> >Const.MaxVarying * 4);
> > }
> >
> > -   if (state->is_version(150, 0)) {
> > +   if (state->has_geometry_shader()) {
> >add_const("gl_MaxVertexOutputComponents",
> >  state->Const.MaxVertexOutputComponents);
> >add_const("gl_MaxGeometryInputComponents",
> > @@ -730,12 +730,11 @@ builtin_variable_generator::generate_constants()
> >add_const("gl_MaxAtomicCounterBindings",
> >  state->Const.MaxAtomicBufferBindings);
> >
> > -  /* When Mesa adds support for GL_OES_geometry_shader and
> > -   * GL_OES_tessellation_shader, this will need to change.
> > -   */
> > -  if (!state->es_shader) {
> > +  if (state->has_geometry_shader()) {
> >   add_const("gl_MaxGeometryAtomicCounters",
> > state->Const.MaxGeometryAtomicCounters);
> > +  }
> > +  if (!state->es_shader) {
> >   add_const("gl_MaxTessControlAtomicCounters",
> > state->Const.MaxTessControlAtomicCounters);
> >   add_const("gl_MaxTessEvaluationAtomicCounters",
> > @@ -753,12 +752,11 @@ builtin_variable_generator::generate_constants()
> >add_const("gl_MaxAtomicCounterBufferSize",
> >  state->Const.MaxAtomicCounterBufferSize);
> >
> > -  /* When Mesa adds support for GL_OES_geometry_shader and
> > -   * GL_OES_tessellation_shader, this will need to change.
> > -   */
> > -  if (!state->es_shader) {
> > +  if (state->has_geometry_shader()) {
> >   add_const("gl_MaxGeometryAtomicCounterBuffers",
> > state->Const.MaxGeometryAtomicCounterBuffers);
> > +  }
> > +  if (!state->es_shader) {
> >   add_const("gl_MaxTessControlAtomicCounterBuffers",
> > state->Const.MaxTessControlAtomicCounterBuffers);
> >   add_const("gl_MaxTessEvaluationAtomicCounterBuffers",
> > @@ -814,13 +812,16 @@ builtin_variable_generator::generate_constants()
> >add_const("gl_MaxCombinedImageUniforms",
> >  state->Const.MaxCombinedImageUniforms);
> >
> > +  if (state->has_geometry_shader()) {
> > + add_const("gl_MaxGeometryImageUniforms",
> > +   state->Const.MaxGeometryImageUniforms);
> > +  }
> 
> So this is *really* pedantic, and I think you can disregard my comment.
> However, I'd like to say it for posterity anyways:
> 
> ARB_shader_image_load_store defines a bunch of interactions, and none of
> them talk about removing gl_MaxGeometryImageUniforms when you don't
> have GL 3.2. I suspect similar is true of atomic counters but I didn't check
> explicitly.
> 
> If you want to be super-accurate, you'd make the formerly "if (!state-
> >es_shader)" blocks read something like
> 
> if (!state->es_shader || state->has_geometry_shader())
> 
> I also vaguely recall Ian talking about this. I forget what he said.
> If he said anything that conflicts with what I said, trust him, not me.
> 
> Either way, this is
> 
> Reviewed-by: Ilia Mirkin 

Thanks for the review and the comments. Since Ian already reviewed this patch 
and didn't comment on your comments. I will go for what I already had.

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

Re: [Mesa-dev] [PATCH 1/2] configure.ac: don't require EGL/DRM ang GBM if OpenGL is disabled

[Emil Velikov]

Hi Marek,

On 22 January 2016 at 12:24, Marek Olšák  wrote:
> Hi Emil,
>
> Do you have any comment on this series?
>
I was secretly hoping that you'll forget about this patch because...

> Marek
>
> On Tue, Jan 12, 2016 at 8:46 PM, Marek Olšák  wrote:
>> From: Marek Olšák 
>>
>> This allows building VDPAU/OMX/VA drivers without OpenGL and its
>> dependencies.
>> ---
>>  configure.ac | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 8d19dab..04b5fd8 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -2159,7 +2159,12 @@ gallium_require_drm_loader() {
>>  fi
>>  }
>>
>> +dnl This is for Glamor. Skip this if OpenGL is disabled.
>>  require_egl_drm() {
>> +if test "x$enable_opengl" = xno; then
>> +return 0
>> +fi
>> +
>>  case "$with_egl_platforms" in
>>  *drm*)
>>  ;;
... the hole idea of having this error out is a gross workaround imho.
While I could not find anything concrete to point out initially seems
like you have found it. And now we add a workaround on top of the
workaround :-\

Yes it is (very) unlikely that radeonsi GPUs will have 2d accel
without glamor and yes it is required in those cases. But that does
not mean that we must mandate egl+drm but recommend it ? After all one
can have egl+wayland+radeonsi mesa (without egl+drm) on a xserver-less
setup, can't they ?

So what I'm proposing here is that we change the AC_MSG_ERROR to
AC_MSG_WARN and drop this patch.

-Emil
P.S. Pardon for the wall of text.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: add ETC1 support for Stoney

[Alex Deucher]

On Fri, Jan 22, 2016 at 10:22 AM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> It's a subset of ETC2. Tested.
>
> For more information, see page 42 and onward:
> http://www.graphicshardware.org/previous/www_2007/presentations/strom-etc2-gh07.pdf

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/radeonsi/si_state.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c 
> b/src/gallium/drivers/radeonsi/si_state.c
> index 1be260d..9c30c39 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -1487,6 +1487,7 @@ static uint32_t si_translate_texformat(struct 
> pipe_screen *screen,
> if (desc->layout == UTIL_FORMAT_LAYOUT_ETC &&
> sscreen->b.family >= CHIP_STONEY) {
> switch (format) {
> +   case PIPE_FORMAT_ETC1_RGB8:
> case PIPE_FORMAT_ETC2_RGB8:
> case PIPE_FORMAT_ETC2_SRGB8:
> return V_008F14_IMG_DATA_FORMAT_ETC2_RGB;
> --
> 2.1.4
>
> ___
> 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] i965: Use nir_lower_load_const_to_scalar().

[Eduardo Lima Mitev]

On 01/22/2016 01:37 AM, Kenneth Graunke wrote:
> I don't know why, but we never hooked up this pass Eric wrote.
> Otherwise, you can end up with stupid scalarized code such as:
> 
>vec4 ssa_7 = load_const (0.0, 0.0, 0.0, 0.0)
>vec4 ssa_8 = ...
>vec1 ssa_9 = feq ssa_8, ssa_7
>vec1 ssa_10 = feq ssa_8.y, ssa_7.y
>vec1 ssa_11 = feq ssa_8, ssa_7.z
>vec1 ssa_12 = feq ssa_8.y, ssa_7.w
> 
> ssa_8.xyxy == <0, 0, 0, 0> should only take two feq instructions.
> 
> shader-db on Skylake:
> 
> total instructions in shared programs: 9111788 -> 9111384 (-0.00%)
> instructions in affected programs: 32421 -> 32017 (-1.25%)
> helped: 277
> HURT: 69
> 
> total cycles in shared programs: 69221226 -> 69219394 (-0.00%)
> cycles in affected programs: 917796 -> 915964 (-0.20%)
> helped: 317
> HURT: 408
> 

I get similar results in HSW:

total instructions in shared programs: 6256788 -> 6256504 (-0.00%)
instructions in affected programs: 26424 -> 26140 (-1.07%)
helped: 240
HURT: 0

total cycles in shared programs: 56009352 -> 56010506 (0.00%)
cycles in affected programs: 807916 -> 809070 (0.14%)
helped: 245
HURT: 325

I wonder why the pass was not enabled before.

Patch is:

Reviewed-by: Eduardo Lima Mitev 

> This also prevents regressions when disabling channel expressions.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_nir.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_nir.c 
> b/src/mesa/drivers/dri/i965/brw_nir.c
> index 935529a..ce9b9db 100644
> --- a/src/mesa/drivers/dri/i965/brw_nir.c
> +++ b/src/mesa/drivers/dri/i965/brw_nir.c
> @@ -482,6 +482,11 @@ brw_preprocess_nir(nir_shader *nir, bool is_scalar)
>  
> nir = nir_optimize(nir, is_scalar);
>  
> +   if (is_scalar) {
> +  OPT_V(nir_lower_load_const_to_scalar);
> +  OPT(nir_opt_cse);
> +   }
> +
> /* Lower a bunch of stuff */
> OPT_V(nir_lower_var_copies);
>  
> 

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

Re: [Mesa-dev] [RFC 16/63] mesa: Add dispatch and extension XML for GL_ARB_internalformat_query2

[Emil Velikov]

Hi all,

On 19 January 2016 at 16:41, Eduardo Lima Mitev  wrote:
> From: Alejandro Piñeiro 
>
> Equivalent to commit bda540 (that added GL_ARB_internalformat_query)
> ---
>  src/mapi/glapi/gen/ARB_internalformat_query2.xml | 119 
> +++
>  src/mapi/glapi/gen/gl_API.xml|   2 +-
>  src/mesa/main/tests/dispatch_sanity.cpp  |   4 +
>  3 files changed, 124 insertions(+), 1 deletion(-)
>  create mode 100644 src/mapi/glapi/gen/ARB_internalformat_query2.xml
>
Please add the new file to the API_XML list in src/mapi/glapi/gen/Makefile.am

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

Re: [Mesa-dev] [RFC 16/63] mesa: Add dispatch and extension XML for GL_ARB_internalformat_query2

[Alejandro Piñeiro]

On 22/01/16 18:34, Emil Velikov wrote:
> Hi all,
>
> On 19 January 2016 at 16:41, Eduardo Lima Mitev  wrote:
>> From: Alejandro Piñeiro 
>>
>> Equivalent to commit bda540 (that added GL_ARB_internalformat_query)
>> ---
>>  src/mapi/glapi/gen/ARB_internalformat_query2.xml | 119 
>> +++
>>  src/mapi/glapi/gen/gl_API.xml|   2 +-
>>  src/mesa/main/tests/dispatch_sanity.cpp  |   4 +
>>  3 files changed, 124 insertions(+), 1 deletion(-)
>>  create mode 100644 src/mapi/glapi/gen/ARB_internalformat_query2.xml
>>
> Please add the new file to the API_XML list in src/mapi/glapi/gen/Makefile.am

Ok. Will be included on the v2. Thanks for pointing it.

BR

-- 
Alejandro Piñeiro (apinhe...@igalia.com)

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

Re: [Mesa-dev] [PATCH 2/2] i965: Do channel expressions on significantly fewer opcodes.

[Jason Ekstrand]

On Fri, Jan 22, 2016 at 5:35 PM, Matt Turner  wrote:

> On Thu, Jan 21, 2016 at 4:37 PM, Kenneth Graunke 
> wrote:
> > nir_lower_alu_to_scalar() and nir_lower_load_const_to_scalar()
> > handle most cases quite well.  They also create nir_ssa_defs rather
> > than ir_variables, which are much less memory intensive.
> >
> > This can mean losing out on a few GLSL IR optimizations, however.
> > In most cases, this is fine.  But a few cases still benefit:
> >
> > - add/mul/dot still benefit from opt_algebraic()'s constant
> >   reassociation capabilities.
> >
> > - min/max still benefit from opt_minmax().
> >
> > - comparisons seem to still benefit from opt_algebraic(), even
> >   though we also do most of them in nir_opt_algebraic_late().
> >
> > With this change, shader-db statistics on Skylake are:
> >
> > total instructions in shared programs: 9107924 -> 9107347 (-0.01%)
> > instructions in affected programs: 188830 -> 188253 (-0.31%)
> > helped: 572
> > HURT: 154
>
> I tried looking at the hurt programs. The first was
> guacamelee/368.shader_test, which went from 40 -> 43 instructions. It
> has a multiplication tree of (x * (y * 0.2) * 15.0), which we are able
> to convert into x * y * 3.0 after channel expressions.
>
> The shader looks like
>
> star_1 = (thing0 * 0.2) * thing1
> star_1 = star_1 * 15.0
>
> star_2 = (thing2 * 0.2) * thing3
> star_2 = star_2 * 15.0
>
> star_3 = (thing4 * 0.2) * thing5
> star_3 = star_3 * 15.0
>
> stars = sat(star_1) + sat(star_2) + sat(stars_3)
>
> Before linking and channel expressions, we don't have appropriate
> trees to see that we can reassociate constants. Tree grafting won't do
> its job on, for instance, star_1, because it sees that star_1 is
> assigned more than once -- even though it's just reassigning itself.
>
> Adding ir_unop_saturate back to channel_expressions solves the issue.
> I continued looking at the regressions and adding things back until I
> was down to 25 hurt programs (but also down to only 10 helped) after
> I'd readded sign, lrp, neg, f2i, i2f, exp2, log2, f2u, u2f.
>

Adding those back in gets rid of hurt programs, but does adding them back
in get rid of helped programs?
--Jason


>
> I think that by the time I was down to zero regressions, the only
> things I would have not readded would be opcodes unused in shader-db.
>
> I think I want to hold off on this patch.
> ___
> 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 00/10] vbo: introduce a minmax_index cache (v3)

[Nicolai Hähnle]

On 22.01.2016 15:17, Marek Olšák wrote:

On Fri, Jan 22, 2016 at 6:17 PM, Nicolai Hähnle  wrote:

On 11.01.2016 21:32, Nicolai Hähnle wrote:


here is a new version of the series. I'm calling it v3 even though I never
sent v2 because it contains v3 of the main patch. Changes relative to v1:

- disable cache on USAGE_TEXTURE_BUFFER and bool/GLboolean nit
- disable cache only temporarily when a persistent writable mapping exists
- add a MESA_NO_MINMAX_CACHE environment variable that disables caches
completely
- track hits and misses and disable the cache on a per-BO basis if the
hit rate is low

The last point is on a per-BO basis because applications don't always have
the same usage pattern for all BOs.

There is also a new util/hash_table patch which I added for an idea that I
ultimately rejected, but it turns out to be useful elsewhere, so I'm
sending it along while I'm at it.

I benchmarked this series with a couple of tests from PTS, using low
resolutions in an attempt to emphasize CPU usage. Their performance is
unaffected, with averages with/without this series within the measurement
tolerance of each other. That there's no regression is good news, and that
there's no improvement is to be expected - if one of these tests had been
affected by the problem this series addresses, someone else would probably
have done it much earlier ;)

Please review!



Ping... any opinions on this series? Other than Matt's coding style comment,
I haven't received anything.


I'm looking at your FDO repo and some patches have my Rbs. These that don't:

util/hash_table: add _mesa_hash_table_num_entries
mesa: add USAGE_DISABLE_MINMAX_CACHE flag to buffer UsageHistory
vbo: disable the minmax cache when the hit rate is low
mesa: add MESA_NO_MINMAX_CACHE environment variable

are:
Reviewed-by: Marek Olšák 

Anything else?


Thanks. I'll wait to see if Ian has anything else to say after his 
comments on the first version of the series, so I'll give it until some 
time next week.


Cheers,
Nicolai



Marek


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

Re: [Mesa-dev] [PATCH] winsys/amdgpu: optionally use buffer lists with all allocated buffers

[Nicolai Hähnle]

On 22.01.2016 15:19, Marek Olšák wrote:

From: Marek Olšák 

Set RADEON_ALL_BOS=1 to use it.


Reviewed-by: Nicolai Hähnle 


---
  src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 21 +
  src/gallium/winsys/amdgpu/drm/amdgpu_bo.h |  2 ++
  src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 33 ---
  src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c |  3 +++
  src/gallium/winsys/amdgpu/drm/amdgpu_winsys.h |  5 
  5 files changed, 61 insertions(+), 3 deletions(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index 82c803b..30a1aa8 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
@@ -128,6 +128,11 @@ void amdgpu_bo_destroy(struct pb_buffer *_buf)
 struct amdgpu_winsys_bo *bo = amdgpu_winsys_bo(_buf);
 int i;

+   pipe_mutex_lock(bo->ws->global_bo_list_lock);
+   LIST_DEL(>global_list_item);
+   bo->ws->num_buffers--;
+   pipe_mutex_unlock(bo->ws->global_bo_list_lock);
+
 amdgpu_bo_va_op(bo->bo, 0, bo->base.size, bo->va, 0, AMDGPU_VA_OP_UNMAP);
 amdgpu_va_range_free(bo->va_handle);
 amdgpu_bo_free(bo->bo);
@@ -249,6 +254,16 @@ static const struct pb_vtbl amdgpu_winsys_bo_vtbl = {
 /* other functions are never called */
  };

+static void amdgpu_add_buffer_to_global_list(struct amdgpu_winsys_bo *bo)
+{
+   struct amdgpu_winsys *ws = bo->ws;
+
+   pipe_mutex_lock(ws->global_bo_list_lock);
+   LIST_ADDTAIL(>global_list_item, >global_bo_list);
+   ws->num_buffers++;
+   pipe_mutex_unlock(ws->global_bo_list_lock);
+}
+
  static struct amdgpu_winsys_bo *amdgpu_create_bo(struct amdgpu_winsys *ws,
   unsigned size,
   unsigned alignment,
@@ -319,6 +334,8 @@ static struct amdgpu_winsys_bo *amdgpu_create_bo(struct 
amdgpu_winsys *ws,
 else if (initial_domain & RADEON_DOMAIN_GTT)
ws->allocated_gtt += align(size, ws->gart_page_size);

+   amdgpu_add_buffer_to_global_list(bo);
+
 return bo;

  error_va_map:
@@ -588,6 +605,8 @@ static struct pb_buffer *amdgpu_bo_from_handle(struct 
radeon_winsys *rws,
 else if (bo->initial_domain & RADEON_DOMAIN_GTT)
ws->allocated_gtt += align(bo->base.size, ws->gart_page_size);

+   amdgpu_add_buffer_to_global_list(bo);
+
 return >base;

  error_va_map:
@@ -673,6 +692,8 @@ static struct pb_buffer *amdgpu_bo_from_ptr(struct 
radeon_winsys *rws,

  ws->allocated_gtt += align(bo->base.size, ws->gart_page_size);

+amdgpu_add_buffer_to_global_list(bo);
+
  return (struct pb_buffer*)bo;

  error_va_map:
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h 
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h
index 12cb920..54f5dbd 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.h
@@ -60,6 +60,8 @@ struct amdgpu_winsys_bo {

 /* Fences for buffer synchronization. */
 struct pipe_fence_handle *fence[RING_LAST];
+
+   struct list_head global_list_item;
  };

  bool amdgpu_bo_can_reclaim(struct pb_buffer *_buf);
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
index 10f112d..83da740 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
@@ -605,6 +605,7 @@ static void amdgpu_cs_sync_flush(struct radeon_winsys_cs 
*rcs)
  }

  DEBUG_GET_ONCE_BOOL_OPTION(noop, "RADEON_NOOP", FALSE)
+DEBUG_GET_ONCE_BOOL_OPTION(all_bos, "RADEON_ALL_BOS", FALSE)

  static void amdgpu_cs_flush(struct radeon_winsys_cs *rcs,
  unsigned flags,
@@ -644,9 +645,35 @@ static void amdgpu_cs_flush(struct radeon_winsys_cs *rcs,
 if (cs->base.cdw && cs->base.cdw <= cs->base.max_dw && 
!debug_get_option_noop()) {
int r;

-  r = amdgpu_bo_list_create(ws->dev, cs->num_buffers,
-cs->handles, cs->flags,
->request.resources);
+  /* Use a buffer list containing all allocated buffers if requested. */
+  if (debug_get_option_all_bos()) {
+ struct amdgpu_winsys_bo *bo;
+ amdgpu_bo_handle *handles;
+ unsigned num = 0;
+
+ pipe_mutex_lock(ws->global_bo_list_lock);
+
+ handles = malloc(sizeof(handles[0]) * ws->num_buffers);
+ if (!handles) {
+pipe_mutex_unlock(ws->global_bo_list_lock);
+goto cleanup;
+ }
+
+ LIST_FOR_EACH_ENTRY(bo, >global_bo_list, global_list_item) {
+assert(num < ws->num_buffers);
+handles[num++] = bo->bo;
+ }
+
+ r = amdgpu_bo_list_create(ws->dev, ws->num_buffers,
+   handles, NULL,
+   >request.resources);
+ free(handles);
+ pipe_mutex_unlock(ws->global_bo_list_lock);
+  } else {
+ r = 

Re: [Mesa-dev] [PATCH 0/7] radeonsi: geometry shader bug fix and cleanup

[eocallaghan]

This series is,

Reviewed-by: Edward O'Callaghan 

On 2016-01-23 10:59, Nicolai Hähnle wrote:

Hi,

this series was prompted by a rendering bug reported for Dolphin. The 
bug is
fixed in the first two patches, and the remainder is assorted cleanups 
that

I noticed while working on the fix. Please review.

Thanks,
Nicolai
--
 .../drivers/radeonsi/si_descriptors.c|  8 +-
 src/gallium/drivers/radeonsi/si_shader.c | 14 ++--
 src/gallium/drivers/radeonsi/si_shader.h |  1 -
 .../drivers/radeonsi/si_state_shaders.c  | 78 +++---
 4 files changed, 62 insertions(+), 39 deletions(-)

___
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/4] radeonsi: allow using all CUs for tessellation and on-chip GS (v2)

[eocallaghan]

This series is,

Reviewed-by: Edward O'Callaghan 

On 2016-01-23 01:18, Marek Olšák wrote:

From: Marek Olšák 

v2: After more discussion with hw teams, the kernel already contains 
the

optimal settings allowing us to use all CUs.
---
 src/gallium/drivers/radeonsi/si_state.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index a3ddee8..67b2835 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3701,9 +3701,9 @@ static void si_init_config(struct si_context 
*sctx)

si_pm4_set_reg(pm4, R_028408_VGT_INDX_OFFSET, 0);

if (sctx->b.chip_class >= CIK) {
-   si_pm4_set_reg(pm4, R_00B51C_SPI_SHADER_PGM_RSRC3_LS,
S_00B51C_CU_EN(0xfffc));
+   si_pm4_set_reg(pm4, R_00B51C_SPI_SHADER_PGM_RSRC3_LS,
S_00B51C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B41C_SPI_SHADER_PGM_RSRC3_HS, 0);
-   si_pm4_set_reg(pm4, R_00B31C_SPI_SHADER_PGM_RSRC3_ES,
S_00B31C_CU_EN(0xfffe));
+   si_pm4_set_reg(pm4, R_00B31C_SPI_SHADER_PGM_RSRC3_ES,
S_00B31C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B21C_SPI_SHADER_PGM_RSRC3_GS,
S_00B21C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B118_SPI_SHADER_PGM_RSRC3_VS,
S_00B118_CU_EN(0x));
 		si_pm4_set_reg(pm4, R_00B11C_SPI_SHADER_LATE_ALLOC_VS, 
S_00B11C_LIMIT(0));


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

Re: [Mesa-dev] [PATCH 2/2] virgl: enable building on Android

[Dave Airlie]

On 23 January 2016 at 12:35, Dave Airlie  wrote:
> On 23 January 2016 at 09:22, Rob Herring  wrote:
>> On Fri, Dec 18, 2015 at 11:01 AM, Emil Velikov  
>> wrote:
>>> Thank you Rob !
>>>
>>> On 17 December 2015 at 15:45, Rob Herring  wrote:
 This is just a copy-n-paste and rename of vc4 Android makefiles.

>>> Looks great.
>>>
>>> Rob, I take it that you've at least compile tested this patch ?
>>>
>>> Cc: "11.1" 
>>> Reviewed-by: Emil Velikov 
>>>
>>> I'll apply this some time next week.
>>
>> It looks like these 2 patches never got applied.

I've pushed them now.

though I think I forgot the stable tags.

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

Re: [Mesa-dev] [PATCH 2/2] virgl: enable building on Android

[Dave Airlie]

On 23 January 2016 at 09:22, Rob Herring  wrote:
> On Fri, Dec 18, 2015 at 11:01 AM, Emil Velikov  
> wrote:
>> Thank you Rob !
>>
>> On 17 December 2015 at 15:45, Rob Herring  wrote:
>>> This is just a copy-n-paste and rename of vc4 Android makefiles.
>>>
>> Looks great.
>>
>> Rob, I take it that you've at least compile tested this patch ?
>>
>> Cc: "11.1" 
>> Reviewed-by: Emil Velikov 
>>
>> I'll apply this some time next week.
>
> It looks like these 2 patches never got applied.
>
> Rob
> ___
> 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 2/2] i965: Do channel expressions on significantly fewer opcodes.

[Matt Turner]

On Thu, Jan 21, 2016 at 4:37 PM, Kenneth Graunke  wrote:
> nir_lower_alu_to_scalar() and nir_lower_load_const_to_scalar()
> handle most cases quite well.  They also create nir_ssa_defs rather
> than ir_variables, which are much less memory intensive.
>
> This can mean losing out on a few GLSL IR optimizations, however.
> In most cases, this is fine.  But a few cases still benefit:
>
> - add/mul/dot still benefit from opt_algebraic()'s constant
>   reassociation capabilities.
>
> - min/max still benefit from opt_minmax().
>
> - comparisons seem to still benefit from opt_algebraic(), even
>   though we also do most of them in nir_opt_algebraic_late().
>
> With this change, shader-db statistics on Skylake are:
>
> total instructions in shared programs: 9107924 -> 9107347 (-0.01%)
> instructions in affected programs: 188830 -> 188253 (-0.31%)
> helped: 572
> HURT: 154

I tried looking at the hurt programs. The first was
guacamelee/368.shader_test, which went from 40 -> 43 instructions. It
has a multiplication tree of (x * (y * 0.2) * 15.0), which we are able
to convert into x * y * 3.0 after channel expressions.

The shader looks like

star_1 = (thing0 * 0.2) * thing1
star_1 = star_1 * 15.0

star_2 = (thing2 * 0.2) * thing3
star_2 = star_2 * 15.0

star_3 = (thing4 * 0.2) * thing5
star_3 = star_3 * 15.0

stars = sat(star_1) + sat(star_2) + sat(stars_3)

Before linking and channel expressions, we don't have appropriate
trees to see that we can reassociate constants. Tree grafting won't do
its job on, for instance, star_1, because it sees that star_1 is
assigned more than once -- even though it's just reassigning itself.

Adding ir_unop_saturate back to channel_expressions solves the issue.
I continued looking at the regressions and adding things back until I
was down to 25 hurt programs (but also down to only 10 helped) after
I'd readded sign, lrp, neg, f2i, i2f, exp2, log2, f2u, u2f.

I think that by the time I was down to zero regressions, the only
things I would have not readded would be opcodes unused in shader-db.

I think I want to hold off on this patch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev