Re: [Mesa-dev] [PATCH] i965/vec4: do not trim dead channels on gen6 for math

[Tapani Pälli]

On 04/02/2014 09:45 AM, Matt Turner wrote:
> On Tue, Apr 1, 2014 at 11:18 PM, Tapani Pälli  wrote:
>> On GEN6 math operations require destination writemask to be WRITEMASK_XYZW.
> That's not really it. Gen6 doesn't support the math in align16 mode,
> which is the mode required for writemasking and swizzling.

Ah yep, I forgot about the align16, Topi also pointed this out for me.

>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76883
>>
>> Signed-off-by: Tapani Pälli 
>> ---
>>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 14 +++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
>> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> index 32a3892..3ed1bad 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> @@ -322,8 +322,10 @@ src_reg::equals(src_reg *r)
>>  }
>>
>>  static bool
>> -try_eliminate_instruction(vec4_instruction *inst, int new_writemask)
>> +try_eliminate_instruction(vec4_instruction *inst, int new_writemask,
>> +  const struct brw_context *brw)
>>  {
>> +
> Extra newline.
>
>> if (new_writemask == 0) {
>>/* Don't dead code eliminate instructions that write to the
>> * accumulator as a side-effect. Instead just set the destination
>> @@ -344,6 +346,7 @@ try_eliminate_instruction(vec4_instruction *inst, int 
>> new_writemask)
>>}
>>return true;
>> } else if (inst->dst.writemask != new_writemask) {
>> +
> Extra newline.
>
>>switch (inst->opcode) {
>>case SHADER_OPCODE_TXF_CMS:
>>case SHADER_OPCODE_GEN4_SCRATCH_READ:
>> @@ -351,6 +354,10 @@ try_eliminate_instruction(vec4_instruction *inst, int 
>> new_writemask)
>>case VS_OPCODE_PULL_CONSTANT_LOAD_GEN7:
>>   break;
>>default:
>> + /* On GEN6, vec4 backend for math requires a full mask. */
> Same comment as the about the commit message.
>
>> + if (brw->gen == 6 && inst->is_math())
> Just fold this into the existing conditional below?

OK, I think it deserves some commenting though and that is why I
separated it.

I'll cleanup the patch and send v2.

>> +return false;
>> +
>>   if (!inst->is_tex()) {
>>  inst->dst.writemask = new_writemask;
>>  return true;
>> @@ -407,7 +414,8 @@ vec4_visitor::dead_code_eliminate()
>>  }
>>   }
>>
>> - progress = try_eliminate_instruction(inst, write_mask) || progress;
>> + progress = try_eliminate_instruction(inst, write_mask, brw) ||
>> +progress;
>>}
>>
>>if (seen_control_flow || inst->predicate || inst->prev == NULL)
>> @@ -456,7 +464,7 @@ vec4_visitor::dead_code_eliminate()
>>   if (inst->dst.reg == scan_inst->dst.reg) {
>>  int new_writemask = scan_inst->dst.writemask & ~dead_channels;
>>
>> -progress = try_eliminate_instruction(scan_inst, new_writemask) 
>> ||
>> +progress = try_eliminate_instruction(scan_inst, new_writemask, 
>> brw) ||
>> progress;
>>   }
>>
>> --
>> 1.8.3.1

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

Re: [Mesa-dev] [PATCH 2/4] xa: remove unneeded args

[Thomas Hellstrom]

On 04/01/2014 05:04 PM, Rob Clark wrote:
> From: Rob Clark 
>
> Signed-off-by: Rob Clark 
> ---
>  src/gallium/state_trackers/xa/xa_composite.c | 3 +--
>  src/gallium/state_trackers/xa/xa_context.c   | 5 +
>  src/gallium/state_trackers/xa/xa_priv.h  | 3 +--
>  src/gallium/state_trackers/xa/xa_renderer.c  | 7 ---
>  src/gallium/state_trackers/xa/xa_yuv.c   | 2 +-
>  5 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/state_trackers/xa/xa_composite.c 
> b/src/gallium/state_trackers/xa/xa_composite.c
> index f63cf49..19e7309 100644
> --- a/src/gallium/state_trackers/xa/xa_composite.c
> +++ b/src/gallium/state_trackers/xa/xa_composite.c
> @@ -482,8 +482,7 @@ xa_composite_prepare(struct xa_context *ctx,
>   return ret;
>  
>  ctx->dst = dst_srf;
> -renderer_bind_destination(ctx, ctx->srf, ctx->srf->width,
> -   ctx->srf->height);
> +renderer_bind_destination(ctx, ctx->srf);
>  
>  ret = bind_composite_blend_state(ctx, comp);
>  if (ret != XA_ERR_NONE)
> diff --git a/src/gallium/state_trackers/xa/xa_context.c 
> b/src/gallium/state_trackers/xa/xa_context.c
> index c2dc53b..ee32676 100644
> --- a/src/gallium/state_trackers/xa/xa_context.c
> +++ b/src/gallium/state_trackers/xa/xa_context.c
> @@ -281,7 +281,6 @@ xa_solid_prepare(struct xa_context *ctx, struct 
> xa_surface *dst,
>  {
>  unsigned vs_traits, fs_traits;
>  struct xa_shader shader;
> -int width, height;
>  int ret;
>  
>  ret = xa_ctx_srf_create(ctx, dst);
> @@ -295,8 +294,6 @@ xa_solid_prepare(struct xa_context *ctx, struct 
> xa_surface *dst,
>  ctx->has_solid_color = 1;
>  
>  ctx->dst = dst;
> -width = ctx->srf->width;
> -height = ctx->srf->height;
>  
>  #if 0
>  debug_printf("Color Pixel=(%d, %d, %d, %d), RGBA=(%f, %f, %f, %f)\n",
> @@ -309,7 +306,7 @@ xa_solid_prepare(struct xa_context *ctx, struct 
> xa_surface *dst,
>  vs_traits = VS_SOLID_FILL;
>  fs_traits = FS_SOLID_FILL;
>  
> -renderer_bind_destination(ctx, ctx->srf, width, height);
> +renderer_bind_destination(ctx, ctx->srf);
>  bind_solid_blend_state(ctx);
>  cso_set_samplers(ctx->cso, PIPE_SHADER_FRAGMENT, 0, NULL);
>  cso_set_sampler_views(ctx->cso, PIPE_SHADER_FRAGMENT, 0, NULL);
> diff --git a/src/gallium/state_trackers/xa/xa_priv.h 
> b/src/gallium/state_trackers/xa/xa_priv.h
> index 348a98e..15aedb5 100644
> --- a/src/gallium/state_trackers/xa/xa_priv.h
> +++ b/src/gallium/state_trackers/xa/xa_priv.h
> @@ -241,8 +241,7 @@ void renderer_draw_yuv(struct xa_context *r,
>  struct xa_surface *srf[]);
>  
>  void renderer_bind_destination(struct xa_context *r,
> -struct pipe_surface *surface, int width,
> -int height);
> +struct pipe_surface *surface);
>  
>  void renderer_init_state(struct xa_context *r);
>  void renderer_copy_prepare(struct xa_context *r,
> diff --git a/src/gallium/state_trackers/xa/xa_renderer.c 
> b/src/gallium/state_trackers/xa/xa_renderer.c
> index 056648a..e1da28c 100644
> --- a/src/gallium/state_trackers/xa/xa_renderer.c
> +++ b/src/gallium/state_trackers/xa/xa_renderer.c
> @@ -351,8 +351,10 @@ setup_vertex_data_yuv(struct xa_context *r,
>   */
>  void
>  renderer_bind_destination(struct xa_context *r,
> -   struct pipe_surface *surface, int width, int height)
> +   struct pipe_surface *surface)
>  {
> +int width = surface->width;
> +int height = surface->height;
>  
>  struct pipe_framebuffer_state fb;
>  struct pipe_viewport_state viewport;
> @@ -461,8 +463,7 @@ renderer_copy_prepare(struct xa_context *r,
>   cso_single_sampler_done(r->cso, PIPE_SHADER_FRAGMENT);
>  }
>  
> -renderer_bind_destination(r, dst_surface,
> -   dst_surface->width, dst_surface->height);
> +renderer_bind_destination(r, dst_surface);
>  
>  /* texture/sampler view */
>  {
> diff --git a/src/gallium/state_trackers/xa/xa_yuv.c 
> b/src/gallium/state_trackers/xa/xa_yuv.c
> index 9c7c4d6..43f56ff 100644
> --- a/src/gallium/state_trackers/xa/xa_yuv.c
> +++ b/src/gallium/state_trackers/xa/xa_yuv.c
> @@ -131,7 +131,7 @@ xa_yuv_planar_blit(struct xa_context *r,
>  if (ret != XA_ERR_NONE)
>   return -XA_ERR_NORES;
>  
> -renderer_bind_destination(r, r->srf, r->srf->width, r->srf->height);
> +renderer_bind_destination(r, r->srf);
>  xa_yuv_bind_blend_state(r);
>  xa_yuv_bind_shaders(r);
>  xa_yuv_bind_samplers(r, yuv);
Reviewed-by: Thomas Hellstrom 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] xa: scissor to help tilers

[Thomas Hellstrom]

Rob,

A minor nitpick below:

On 04/01/2014 05:04 PM, Rob Clark wrote:
> From: Rob Clark 
>
> Keep track of the maximal bounds of all the operations and set scissor
> accordingly.  For tiling GPU's this can be a big win by reducing the
> memory bandwidth spent moving pixels from system memory to tile buffer
> and back.
>
> You could imagine being more sophisticated and splitting up disjoint
> operations.  But this simplistic approach is good enough for the common
> cases.
>
> Signed-off-by: Rob Clark 
> ---
>  src/gallium/state_trackers/xa/xa_composite.c |  2 ++
>  src/gallium/state_trackers/xa/xa_context.c   |  3 +++
>  src/gallium/state_trackers/xa/xa_priv.h  | 29 
> 
>  src/gallium/state_trackers/xa/xa_renderer.c  | 14 ++
>  4 files changed, 48 insertions(+)
>
> diff --git a/src/gallium/state_trackers/xa/xa_composite.c 
> b/src/gallium/state_trackers/xa/xa_composite.c
> index 19e7309..861ec29 100644
> --- a/src/gallium/state_trackers/xa/xa_composite.c
> +++ b/src/gallium/state_trackers/xa/xa_composite.c
> @@ -517,6 +517,8 @@ xa_composite_rect(struct xa_context *ctx,
>   const float *src_matrix = NULL;
>   const float *mask_matrix = NULL;
>  
> + xa_scissor_update(ctx, dstX, dstY, dstX + width, dstY + height);
> +
>   if (comp->src->has_transform)
>   src_matrix = comp->src->transform;
>   if (comp->mask && comp->mask->has_transform)
> diff --git a/src/gallium/state_trackers/xa/xa_context.c 
> b/src/gallium/state_trackers/xa/xa_context.c
> index ee32676..867999a 100644
> --- a/src/gallium/state_trackers/xa/xa_context.c
> +++ b/src/gallium/state_trackers/xa/xa_context.c
> @@ -238,6 +238,8 @@ xa_copy(struct xa_context *ctx,
>  {
>  struct pipe_box src_box;
>  
> +xa_scissor_update(ctx, dx, dy, dx + width, dy + height);
> +
>  if (ctx->simple_copy) {
>   u_box_2d(sx, sy, width, height, &src_box);
>   ctx->pipe->resource_copy_region(ctx->pipe,
> @@ -324,6 +326,7 @@ xa_solid_prepare(struct xa_context *ctx, struct 
> xa_surface *dst,
>  XA_EXPORT void
>  xa_solid(struct xa_context *ctx, int x, int y, int width, int height)
>  {
> +xa_scissor_update(ctx, x, y, x + width, y + height);
>  renderer_solid(ctx, x, y, x + width, y + height, ctx->solid_color);
>  }
>  
> diff --git a/src/gallium/state_trackers/xa/xa_priv.h 
> b/src/gallium/state_trackers/xa/xa_priv.h
> index 15aedb5..7a43386 100644
> --- a/src/gallium/state_trackers/xa/xa_priv.h
> +++ b/src/gallium/state_trackers/xa/xa_priv.h
> @@ -38,6 +38,8 @@
>  #include "pipe/p_context.h"
>  #include "pipe/p_state.h"
>  
> +#include "util/u_math.h"
> +
>  #if defined(__GNUC__) && __GNUC__ >= 4
>  #define XA_EXPORT __attribute__ ((visibility("default")))
>  #else
> @@ -105,6 +107,12 @@ struct xa_context {
>  struct xa_surface *dst;
>  struct pipe_surface *srf;
>  
> +/* destination scissor state.. we scissor out untouched parts
> + * of the dst for the benefit of tilers:
> + */
> +struct pipe_scissor_state scissor;
> +int scissor_valid;
> +
>  int simple_copy;
>  
>  int has_solid_color;
> @@ -118,6 +126,27 @@ struct xa_context {
>  const struct xa_composite *comp;
>  };
>  
> +static INLINE void
> +xa_scissor_reset(struct xa_context *ctx)
> +{
> +ctx->scissor.maxx = 0;
> +ctx->scissor.maxy = 0;
> +ctx->scissor.minx = ~0;
> +ctx->scissor.miny = ~0;
> +ctx->scissor_valid = FALSE;
> +}
> +
> +static INLINE void
> +xa_scissor_update(struct xa_context *ctx, unsigned minx, unsigned miny,
> + unsigned maxx, unsigned maxy)
> +{
> + ctx->scissor.maxx = MAX2(ctx->scissor.maxx, maxx);
> + ctx->scissor.maxy = MAX2(ctx->scissor.maxy, maxy);
> + ctx->scissor.minx = MIN2(ctx->scissor.minx, minx);
> + ctx->scissor.miny = MIN2(ctx->scissor.miny, miny);
> + ctx->scissor_valid = TRUE;
> +}
> +
Indentation.

>  enum xa_vs_traits {
>  VS_COMPOSITE = 1 << 0,
>  VS_MASK = 1 << 1,
> diff --git a/src/gallium/state_trackers/xa/xa_renderer.c 
> b/src/gallium/state_trackers/xa/xa_renderer.c
> index e1da28c..8ebda74 100644
> --- a/src/gallium/state_trackers/xa/xa_renderer.c
> +++ b/src/gallium/state_trackers/xa/xa_renderer.c
> @@ -79,11 +79,22 @@ renderer_draw(struct xa_context *r)
>  if (!r->buffer_size)
>   return;
>  
> +if (!r->scissor_valid) {
> + r->scissor.minx = 0;
> + r->scissor.miny = 0;
> + r->scissor.maxx = r->dst->tex->width0;
> + r->scissor.maxy = r->dst->tex->height0;
> +}
> +
> +r->pipe->set_scissor_states(r->pipe, 0, 1, &r->scissor);
> +
>  cso_set_vertex_elements(r->cso, r->attrs_per_vertex, r->velems);
>  util_draw_user_vertex_buffer(r->cso, r->buffer, PIPE_PRIM_QUADS,
>   num_verts,  /* verts */
>   r->attrs_per_vertex);   /* attribs/vert 
> */
>  r->buffer_size = 0;
> +
> +xa_scissor_reset(r);
>  }
>  
>  static INLINE void
> @@ -111,6 +122,7 @@ renderer_ini

Re: [Mesa-dev] [PATCH 4/4] xa: reuse surfaces

[Thomas Hellstrom]

On 04/01/2014 05:04 PM, Rob Clark wrote:
> From: Rob Clark 
>
> Otherwise it will trick the gallium driver into thinking that the render
> target has actually changed (due to different pipe_surface pointing to
> same underlying pipe_resource).  This is really badness for tiling GPUs
> like adreno.

Rob, if we want to cache gallium surfaces like this, we need to
condition it on the same context being used.
We can't reuse a surface created with one context for rendering with
another context. (I know the mesa state tracker needs to
fix this up as well).

While this can be done easily within XA for non-shared xa_surfaces, I
wonder what happens in the case of
shared xa_surfaces? More specifically, is rendering allowed to be cached
in the gallium surface until explicitly flushed to the texture? (I'm
unsure about gallium surface semantics here).

/Thomas

> Signed-off-by: Rob Clark 
> ---
>  src/gallium/state_trackers/xa/xa_context.c | 35 
> +++---
>  src/gallium/state_trackers/xa/xa_priv.h|  3 ++-
>  src/gallium/state_trackers/xa/xa_tracker.c |  1 +
>  3 files changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/src/gallium/state_trackers/xa/xa_context.c 
> b/src/gallium/state_trackers/xa/xa_context.c
> index 867999a..18f0b85 100644
> --- a/src/gallium/state_trackers/xa/xa_context.c
> +++ b/src/gallium/state_trackers/xa/xa_context.c
> @@ -179,6 +179,25 @@ xa_surface_unmap(struct xa_surface *srf)
>  }
>  }
>  
> +static int
> +xa_srf_create(struct xa_context *ctx, struct xa_surface *srf)
> +{
> +struct pipe_screen *screen = ctx->pipe->screen;
> +struct pipe_surface srf_templ;
> +
> +if (!screen->is_format_supported(screen,  srf->tex->format,
> +  PIPE_TEXTURE_2D, 0,
> +  PIPE_BIND_RENDER_TARGET))
> + return -XA_ERR_INVAL;
> +
> +u_surface_default_template(&srf_templ, srf->tex);
> +srf->srf = ctx->pipe->create_surface(ctx->pipe, srf->tex, &srf_templ);
> +if (!srf->srf)
> + return -XA_ERR_NORES;
> +
> +return XA_ERR_NONE;
> +}
> +
>  int
>  xa_ctx_srf_create(struct xa_context *ctx, struct xa_surface *dst)
>  {
> @@ -188,15 +207,15 @@ xa_ctx_srf_create(struct xa_context *ctx, struct 
> xa_surface *dst)
>  if (ctx->srf)
>   return -XA_ERR_INVAL;
>  
> -if (!screen->is_format_supported(screen,  dst->tex->format,
> -  PIPE_TEXTURE_2D, 0,
> -  PIPE_BIND_RENDER_TARGET))
> - return -XA_ERR_INVAL;
> +if (!dst->srf) {
> + int ret = xa_srf_create(ctx, dst);
> + if (ret != XA_ERR_NONE)
> + return ret;
> +}
>  
> -u_surface_default_template(&srf_templ, dst->tex);
> -ctx->srf = ctx->pipe->create_surface(ctx->pipe, dst->tex, &srf_templ);
> -if (!ctx->srf)
> - return -XA_ERR_NORES;
> +assert(dst->srf);
> +
> +pipe_surface_reference(&ctx->srf, dst->srf);
>  
>  return XA_ERR_NONE;
>  }
> diff --git a/src/gallium/state_trackers/xa/xa_priv.h 
> b/src/gallium/state_trackers/xa/xa_priv.h
> index 7a43386..5ade6c1 100644
> --- a/src/gallium/state_trackers/xa/xa_priv.h
> +++ b/src/gallium/state_trackers/xa/xa_priv.h
> @@ -46,7 +46,7 @@
>  #define XA_EXPORT
>  #endif
>  
> -#define XA_VB_SIZE (100 * 4 * 3 * 4)
> +#define XA_VB_SIZE (170 * 4 * 3 * 4)
>  #define XA_LAST_SURFACE_TYPE (xa_type_yuv_component + 1)
>  #define XA_MAX_SAMPLERS 3
>  
> @@ -65,6 +65,7 @@ struct xa_surface {
>  struct pipe_resource template;
>  struct xa_tracker *xa;
>  struct pipe_resource *tex;
> +struct pipe_surface *srf;
>  struct pipe_transfer *transfer;
>  unsigned int flags;
>  struct xa_format_descriptor fdesc;
> diff --git a/src/gallium/state_trackers/xa/xa_tracker.c 
> b/src/gallium/state_trackers/xa/xa_tracker.c
> index 9add584..7fed20a 100644
> --- a/src/gallium/state_trackers/xa/xa_tracker.c
> +++ b/src/gallium/state_trackers/xa/xa_tracker.c
> @@ -474,6 +474,7 @@ xa_surface_unref(struct xa_surface *srf)
>  if (srf == NULL || --srf->refcount) {
>   return;
>  }
> +pipe_surface_reference(&srf->srf, NULL);
>  pipe_resource_reference(&srf->tex, NULL);
>  free(srf);
>  }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH V3 00/30] ARB_texture_view for i965

[Chris Forbes]

This series adds ARB_texture_view support for i965 Gen7/7.5.

Significant changes from V2:

- All the assorted post-V2 format fixups are moved to the start of the series.
  This gives us consistent memory layout for all the formats between which we
  have to support casting.
- Texture validation changes are simplified (Eric)
- CopyTexSubImage respects view parameters.

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

[Mesa-dev] [PATCH V3 16/30] i965: Don't try to use fast upload path for nontrivial views

[Chris Forbes]

This will eventually be relaxed, but we'll get the fallback path
working first.

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index b65a772..7143ab7 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -588,6 +588,10 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
if (!mem_copy)
   return false;
 
+   /* If this is a nontrivial texture view, let another path handle it 
instead. */
+   if (texImage->TexObject->MinLevel || texImage->TexObject->MinLayer)
+  return false;
+
if (for_glTexImage)
   ctx->Driver.AllocTextureImageBuffer(ctx, texImage);
 
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 22/30] i965: Pull out layer_multiplier in intel_update_renderbuffer_wrapper

[Chris Forbes]

We're about to need this in another place.

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_fbo.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
b/src/mesa/drivers/dri/i965/intel_fbo.c
index 201e06f..5ade9e6 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -519,16 +519,19 @@ intel_renderbuffer_update_wrapper(struct brw_context *brw,
intel_miptree_check_level_layer(mt, level, layer);
irb->mt_level = level;
 
+   int layer_multiplier;
switch (mt->msaa_layout) {
   case INTEL_MSAA_LAYOUT_UMS:
   case INTEL_MSAA_LAYOUT_CMS:
- irb->mt_layer = layer * mt->num_samples;
+ layer_multiplier = mt->num_samples;
  break;
 
   default:
- irb->mt_layer = layer;
+ layer_multiplier = 1;
}
 
+   irb->mt_layer = layer_multiplier * layer;
+
intel_miptree_reference(&irb->mt, mt);
 
intel_renderbuffer_set_draw_offset(irb);
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 10/30] i965: refactor format munging for separate stencil

[Chris Forbes]

We will need this for munging the view's format.

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 31 ---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  3 +++
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 1a7a9e8..9b2e27b 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -211,6 +211,23 @@ intel_is_non_msrt_mcs_buffer_supported(struct brw_context 
*brw,
 
 
 /**
+ * Determine depth format corresponding to a depth+stencil format,
+ * for separate stencil.
+ */
+mesa_format
+intel_depth_format_for_depthstencil_format(mesa_format format) {
+   switch (format) {
+   case MESA_FORMAT_Z24_UNORM_S8_UINT:
+  return MESA_FORMAT_Z24_UNORM_X8_UINT;
+   case MESA_FORMAT_Z32_FLOAT_S8X24_UINT:
+  return MESA_FORMAT_Z_FLOAT32;
+   default:
+  return format;
+   }
+}
+
+
+/**
  * @param for_bo Indicates that the caller is
  *intel_miptree_create_for_bo(). If true, then do not create
  *\c stencil_mt.
@@ -368,14 +385,12 @@ intel_miptree_create_layout(struct brw_context *brw,
   /* Fix up the Z miptree format for how we're splitting out separate
* stencil.  Gen7 expects there to be no stencil bits in its depth 
buffer.
*/
-  if (mt->format == MESA_FORMAT_Z24_UNORM_S8_UINT) {
-mt->format = MESA_FORMAT_Z24_UNORM_X8_UINT;
-  } else if (mt->format == MESA_FORMAT_Z32_FLOAT_S8X24_UINT) {
-mt->format = MESA_FORMAT_Z_FLOAT32;
-mt->cpp = 4;
-  } else {
-_mesa_problem(NULL, "Unknown format %s in separate stencil mt\n",
-  _mesa_get_format_name(mt->format));
+  mt->format = intel_depth_format_for_depthstencil_format(mt->format);
+  mt->cpp = 4;
+
+  if (format == mt->format) {
+ _mesa_problem(NULL, "Unknown format %s in separate stencil mt\n",
+   _mesa_get_format_name(mt->format));
   }
}
 
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 2565db8..de68233 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -500,6 +500,9 @@ intel_miptree_create_for_renderbuffer(struct brw_context 
*brw,
   uint32_t height,
   uint32_t num_samples);
 
+mesa_format
+intel_depth_format_for_depthstencil_format(mesa_format format);
+
 /** \brief Assert that the level and layer are valid for the miptree. */
 static inline void
 intel_miptree_check_level_layer(struct intel_mipmap_tree *mt,
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 03/30] swrast: Add support for fetching from MESA_FORMAT_R10G10B10A2_UNORM

[Chris Forbes]

Signed-off-by: Chris Forbes 
---
 src/mesa/swrast/s_texfetch.c |  6 +++---
 src/mesa/swrast/s_texfetch_tmp.h | 16 
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/mesa/swrast/s_texfetch.c b/src/mesa/swrast/s_texfetch.c
index cd09827..4084bbd 100644
--- a/src/mesa/swrast/s_texfetch.c
+++ b/src/mesa/swrast/s_texfetch.c
@@ -325,9 +325,9 @@ texfetch_funcs[] =
},
{
   MESA_FORMAT_R10G10B10A2_UNORM,
-  NULL,
-  NULL,
-  NULL
+  fetch_texel_1d_f_rgba1010102,
+  fetch_texel_2d_f_rgba1010102,
+  fetch_texel_3d_f_rgba1010102
},
{
   MESA_FORMAT_S8_UINT_Z24_UNORM,
diff --git a/src/mesa/swrast/s_texfetch_tmp.h b/src/mesa/swrast/s_texfetch_tmp.h
index f749b49..39e55c5 100644
--- a/src/mesa/swrast/s_texfetch_tmp.h
+++ b/src/mesa/swrast/s_texfetch_tmp.h
@@ -685,6 +685,22 @@ static void FETCH(f_argb2101010)( const struct 
swrast_texture_image *texImage,
 
 
 
+/* MESA_FORMAT_R10G10B10A2_UNORM 
***/
+
+/* Fetch texel from 1D, 2D or 3D argb2101010 texture, return 4 GLchans */
+static void FETCH(f_rgba1010102)( const struct swrast_texture_image *texImage,
+  GLint i, GLint j, GLint k, GLfloat *texel )
+{
+   const GLuint *src = TEXEL_ADDR(GLuint, texImage, i, j, k, 1);
+   const GLuint s = *src;
+   texel[RCOMP] = ((s >> 00) & 0x3ff) * (1.0F / 1023.0F);
+   texel[GCOMP] = ((s >> 10) & 0x3ff) * (1.0F / 1023.0F);
+   texel[BCOMP] = ((s >> 20) & 0x3ff) * (1.0F / 1023.0F);
+   texel[ACOMP] = ((s >> 30) & 0x03) * (1.0F / 3.0F);
+}
+
+
+
 
 /* MESA_FORMAT_R8G8_UNORM 
**/
 
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 14/30] i965: Add _Format to intel_texobj.

[Chris Forbes]

This is the actual mesa_format to use. In non-view cases this is always
the same as the mt's format.

Signed-off-by: Chris Forbes 
---
 src/mesa/drivers/dri/i965/intel_tex.c  | 8 
 src/mesa/drivers/dri/i965/intel_tex_obj.h  | 5 +
 src/mesa/drivers/dri/i965/intel_tex_validate.c | 1 +
 3 files changed, 14 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_tex.c 
b/src/mesa/drivers/dri/i965/intel_tex.c
index 3b14796..0bbeeb7 100644
--- a/src/mesa/drivers/dri/i965/intel_tex.c
+++ b/src/mesa/drivers/dri/i965/intel_tex.c
@@ -168,6 +168,7 @@ intel_alloc_texture_storage(struct gl_context *ctx,
intel_texobj->needs_validate = false;
intel_texobj->validated_first_level = 0;
intel_texobj->validated_last_level = levels - 1;
+   intel_texobj->_Format = intel_texobj->mt->format;
 
return true;
 }
@@ -242,6 +243,7 @@ intel_texture_view(struct gl_context *ctx,
struct gl_texture_object *texObj,
struct gl_texture_object *origTexObj)
 {
+   struct brw_context *brw = brw_context(ctx);
struct intel_texture_object *intel_tex = intel_texture_object(texObj);
struct intel_texture_object *intel_orig_tex = 
intel_texture_object(origTexObj);
 
@@ -274,6 +276,12 @@ intel_texture_view(struct gl_context *ctx,
intel_tex->validated_first_level = 0;
intel_tex->validated_last_level = numLevels - 1;
 
+   /* Set the validated texture format, with the same adjustments that
+* would have been applied to determine the underlying texture's
+* mt->format. */
+   intel_tex->_Format = intel_depth_format_for_depthstencil_format(
+ intel_lower_compressed_format(brw, texObj->Image[0][0]->TexFormat));
+
return GL_TRUE;
 }
 
diff --git a/src/mesa/drivers/dri/i965/intel_tex_obj.h 
b/src/mesa/drivers/dri/i965/intel_tex_obj.h
index 78a0990..8f20858 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_obj.h
+++ b/src/mesa/drivers/dri/i965/intel_tex_obj.h
@@ -54,6 +54,11 @@ struct intel_texture_object
 * might not all be the mipmap tree above.
 */
bool needs_validate;
+
+   /* Mesa format for the validated texture object. For non-views this
+* will always be the same as mt->format. For views, it may differ
+* since the mt is shared across views with differing formats. */
+   mesa_format _Format;
 };
 
 
diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c 
b/src/mesa/drivers/dri/i965/intel_tex_validate.c
index 48a4158..07f3174 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_validate.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_validate.c
@@ -173,6 +173,7 @@ intel_finalize_mipmap_tree(struct brw_context *brw, GLuint 
unit)
 
intelObj->validated_first_level = validate_first_level;
intelObj->validated_last_level = validate_last_level;
+   intelObj->_Format = intelObj->mt->format;
intelObj->needs_validate = false;
 
return true;
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 07/30] i965: Render R8G8B8X8 as R8G8B8A8

[Chris Forbes]

The sampler can handle R8G8B8X8 (and substitute 1.0 for the fourth
component) but we can't use it as a render target.

Signed-off-by: Chris Forbes 
---
 src/mesa/drivers/dri/i965/brw_surface_formats.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c 
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index f203f52..3f82f80 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -583,6 +583,9 @@ brw_init_surface_formats(struct brw_context *brw)
  */
 render = BRW_SURFACEFORMAT_B8G8R8A8_UNORM;
 break;
+  case BRW_SURFACEFORMAT_R8G8B8X8_UNORM:
+ render = BRW_SURFACEFORMAT_R8G8B8A8_UNORM;
+ break;
   }
 
   rinfo = &surface_formats[render];
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 17/30] i965: Adjust map/unmap code for MinLevel/MinLayer

[Chris Forbes]

This allows core mesa's TexSubImage paths etc to work correctly
with views which have nonzero MinLevel or MinLayer.

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_tex.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex.c 
b/src/mesa/drivers/dri/i965/intel_tex.c
index 0bbeeb7..825d4d3 100644
--- a/src/mesa/drivers/dri/i965/intel_tex.c
+++ b/src/mesa/drivers/dri/i965/intel_tex.c
@@ -220,8 +220,11 @@ intel_map_texture_image(struct gl_context *ctx,
if (tex_image->TexObject->Target == GL_TEXTURE_CUBE_MAP)
   slice = tex_image->Face;
 
-   intel_miptree_map(brw, mt, tex_image->Level, slice, x, y, w, h, mode,
-(void **)map, stride);
+   intel_miptree_map(brw, mt,
+ tex_image->Level + tex_image->TexObject->MinLevel,
+ slice + tex_image->TexObject->MinLayer,
+ x, y, w, h, mode,
+ (void **)map, stride);
 }
 
 static void
@@ -235,7 +238,9 @@ intel_unmap_texture_image(struct gl_context *ctx,
if (tex_image->TexObject->Target == GL_TEXTURE_CUBE_MAP)
   slice = tex_image->Face;
 
-   intel_miptree_unmap(brw, mt, tex_image->Level, slice);
+   intel_miptree_unmap(brw, mt,
+ tex_image->Level + tex_image->TexObject->MinLevel,
+ slice + tex_image->TexObject->MinLayer);
 }
 
 static GLboolean
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 08/30] mesa: Adjust _MaxLevel computation to account for views

[Chris Forbes]

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/main/texobj.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index 8bdbb08..918dd59 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -559,6 +559,13 @@ _mesa_test_texobj_completeness( const struct gl_context 
*ctx,
/* 'q' in the GL spec */
maxLevels - 1);
 
+   if (t->Immutable) {
+  /* Adjust max level for views: the data store may have more levels than
+   * the view exposes.
+   */
+  t->_MaxLevel = MIN2(t->_MaxLevel, t->NumLevels - 1);
+   }
+
/* Compute _MaxLambda = q - p in the spec used during mipmapping */
t->_MaxLambda = (GLfloat) (t->_MaxLevel - baseLevel);
 
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 11/30] i965: refactor format selection for unsupported ETC* formats

[Chris Forbes]

We will need to call this to munge view formats.

Signed-off-by: Chris Forbes 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 76 +++
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  3 ++
 2 files changed, 45 insertions(+), 34 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 9b2e27b..5996a1b 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -496,6 +496,47 @@ intel_miptree_choose_tiling(struct brw_context *brw,
return I915_TILING_Y | I915_TILING_X;
 }
 
+
+/**
+ * Choose an appropriate uncompressed format for a requested
+ * compressed format, if unsupported.
+ */
+mesa_format
+intel_lower_compressed_format(struct brw_context *brw, mesa_format format)
+{
+   /* No need to lower ETC formats on these platforms,
+* they are supported natively.
+*/
+   if (brw->gen >= 8 || brw->is_baytrail)
+  return format;
+
+   switch (format) {
+   case MESA_FORMAT_ETC1_RGB8:
+  return MESA_FORMAT_R8G8B8X8_UNORM;
+   case MESA_FORMAT_ETC2_RGB8:
+  return MESA_FORMAT_R8G8B8X8_UNORM;
+   case MESA_FORMAT_ETC2_SRGB8:
+   case MESA_FORMAT_ETC2_SRGB8_ALPHA8_EAC:
+   case MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1:
+  return MESA_FORMAT_B8G8R8A8_SRGB;
+   case MESA_FORMAT_ETC2_RGBA8_EAC:
+   case MESA_FORMAT_ETC2_RGB8_PUNCHTHROUGH_ALPHA1:
+  return MESA_FORMAT_R8G8B8A8_UNORM;
+   case MESA_FORMAT_ETC2_R11_EAC:
+  return MESA_FORMAT_R_UNORM16;
+   case MESA_FORMAT_ETC2_SIGNED_R11_EAC:
+  return MESA_FORMAT_R_SNORM16;
+   case MESA_FORMAT_ETC2_RG11_EAC:
+  return MESA_FORMAT_R16G16_UNORM;
+   case MESA_FORMAT_ETC2_SIGNED_RG11_EAC:
+  return MESA_FORMAT_R16G16_SNORM;
+   default:
+  /* Non ETC1 / ETC2 format */
+  return format;
+   }
+}
+
+
 struct intel_mipmap_tree *
 intel_miptree_create(struct brw_context *brw,
 GLenum target,
@@ -514,40 +555,7 @@ intel_miptree_create(struct brw_context *brw,
mesa_format etc_format = MESA_FORMAT_NONE;
GLuint total_width, total_height;
 
-   if (brw->gen < 8 && !brw->is_baytrail) {
-  switch (format) {
-  case MESA_FORMAT_ETC1_RGB8:
- format = MESA_FORMAT_R8G8B8X8_UNORM;
- break;
-  case MESA_FORMAT_ETC2_RGB8:
- format = MESA_FORMAT_R8G8B8X8_UNORM;
- break;
-  case MESA_FORMAT_ETC2_SRGB8:
-  case MESA_FORMAT_ETC2_SRGB8_ALPHA8_EAC:
-  case MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1:
- format = MESA_FORMAT_B8G8R8A8_SRGB;
- break;
-  case MESA_FORMAT_ETC2_RGBA8_EAC:
-  case MESA_FORMAT_ETC2_RGB8_PUNCHTHROUGH_ALPHA1:
- format = MESA_FORMAT_R8G8B8A8_UNORM;
- break;
-  case MESA_FORMAT_ETC2_R11_EAC:
- format = MESA_FORMAT_R_UNORM16;
- break;
-  case MESA_FORMAT_ETC2_SIGNED_R11_EAC:
- format = MESA_FORMAT_R_SNORM16;
- break;
-  case MESA_FORMAT_ETC2_RG11_EAC:
- format = MESA_FORMAT_R16G16_UNORM;
- break;
-  case MESA_FORMAT_ETC2_SIGNED_RG11_EAC:
- format = MESA_FORMAT_R16G16_SNORM;
- break;
-  default:
- /* Non ETC1 / ETC2 format */
- break;
-  }
-   }
+   format = intel_lower_compressed_format(brw, format);
 
etc_format = (format != tex_format) ? tex_format : MESA_FORMAT_NONE;
 
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index de68233..78ccfc6 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -503,6 +503,9 @@ intel_miptree_create_for_renderbuffer(struct brw_context 
*brw,
 mesa_format
 intel_depth_format_for_depthstencil_format(mesa_format format);
 
+mesa_format
+intel_lower_compressed_format(struct brw_context *brw, mesa_format format);
+
 /** \brief Assert that the level and layer are valid for the miptree. */
 static inline void
 intel_miptree_check_level_layer(struct intel_mipmap_tree *mt,
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 12/30] i965: Ensure that texture validation is skipped for immutable textures.

[Chris Forbes]

If we were to relayout the miptree, we'd break any views that are
sharing it.

(Simplified based on suggestions from Eric)

Signed-off-by: Chris Forbes 
---
 src/mesa/drivers/dri/i965/intel_tex_validate.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c 
b/src/mesa/drivers/dri/i965/intel_tex_validate.c
index d8497a6..48a4158 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_validate.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_validate.c
@@ -98,6 +98,11 @@ intel_finalize_mipmap_tree(struct brw_context *brw, GLuint 
unit)
   return true;
}
 
+   /* Immutable textures should not get this far -- they should have been
+* created in a validated state, and nothing can invalidate them.
+*/
+   assert(!tObj->Immutable);
+
firstImage = intel_texture_image(tObj->Image[0][tObj->BaseLevel]);
 
/* Check tree can hold all active levels.  Check tree matches
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 02/30] mesa: fix packing of float texels to GL_SHORT/GL_BYTE

[Chris Forbes]

Previously, we would unpack the texels to floats using *_TO_FLOAT_TEX,
and then pack them into the desired format using FLOAT_TO_*. Unfortunately,
this isn't quite the inverse operation, and so some texel values would
end up off-by-one.

This fixes the GL_RGB8_SNORM and GL_RGB16_SNORM subcases in piglit's
arb_texture_view-format-consistency-get test on i965. The similar 1-, 2-
and 4-component cases already worked because they took the memcpy path
rather than repacking.

Signed-off-by: Chris Forbes 
---
 src/mesa/main/pack.c | 116 +--
 1 file changed, 58 insertions(+), 58 deletions(-)

diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index d976e5a..1df6568 100644
--- a/src/mesa/main/pack.c
+++ b/src/mesa/main/pack.c
@@ -1489,72 +1489,72 @@ _mesa_pack_rgba_span_float(struct gl_context *ctx, 
GLuint n, GLfloat rgba[][4],
 switch (dstFormat) {
case GL_RED:
   for (i=0;ihttp://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH V3 15/30] i965: Adjust surface_state emission to account for view parameters

[Chris Forbes]

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
index b9d6c8b..b6f2cff 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@ -288,7 +288,7 @@ gen7_update_texture_surface(struct gl_context *ctx,
memset(surf, 0, 8 * 4);
 
uint32_t tex_format = translate_tex_format(brw,
-  mt->format,
+  intelObj->_Format,
   sampler->sRGBDecode);
 
if (for_gather && tex_format == BRW_SURFACEFORMAT_R32G32_FLOAT)
@@ -310,6 +310,11 @@ gen7_update_texture_surface(struct gl_context *ctx,
if (mt->logical_depth0 > 1 && tObj->Target != GL_TEXTURE_3D)
   surf[0] |= GEN7_SURFACE_IS_ARRAY;
 
+   /* if this is a view with restricted NumLayers, then
+* our effective depth is not just the miptree depth. */
+   uint32_t effective_depth = (tObj->Immutable && tObj->Target != 
GL_TEXTURE_3D)
+  ? tObj->NumLayers : mt->logical_depth0;
+
if (mt->array_spacing_lod0)
   surf[0] |= GEN7_SURFACE_ARYSPC_LOD0;
 
@@ -317,14 +322,17 @@ gen7_update_texture_surface(struct gl_context *ctx,
 
surf[2] = SET_FIELD(mt->logical_width0 - 1, GEN7_SURFACE_WIDTH) |
  SET_FIELD(mt->logical_height0 - 1, GEN7_SURFACE_HEIGHT);
-   surf[3] = SET_FIELD(mt->logical_depth0 - 1, BRW_SURFACE_DEPTH) |
+
+   surf[3] = SET_FIELD(effective_depth - 1, BRW_SURFACE_DEPTH) |
  (mt->region->pitch - 1);
 
-   surf[4] = gen7_surface_msaa_bits(mt->num_samples, mt->msaa_layout);
+   surf[4] = gen7_surface_msaa_bits(mt->num_samples, mt->msaa_layout) |
+ SET_FIELD(tObj->MinLayer, GEN7_SURFACE_MIN_ARRAY_ELEMENT);
+
+   surf[4] |= (effective_depth - 1) << 7;
 
surf[5] = (SET_FIELD(GEN7_MOCS_L3, GEN7_SURFACE_MOCS) |
-  SET_FIELD(tObj->BaseLevel - mt->first_level,
-GEN7_SURFACE_MIN_LOD) |
+  SET_FIELD(tObj->MinLevel + tObj->BaseLevel - mt->first_level, 
GEN7_SURFACE_MIN_LOD) |
   /* mip count */
   (intelObj->_MaxLevel - tObj->BaseLevel));
 
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 04/30] i965: Enable R8G8B8A8_UNORM_SRGB format

[Chris Forbes]

Now this is the preferred format for GL_SRGB8_ALPHA8.

Signed-off-by: Chris Forbes 
---
 src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c 
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 3f64881..b4c694d 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -368,6 +368,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
   [MESA_FORMAT_BGR_SRGB8] = 0,
   [MESA_FORMAT_A8B8G8R8_SRGB] = 0,
   [MESA_FORMAT_B8G8R8A8_SRGB] = BRW_SURFACEFORMAT_B8G8R8A8_UNORM_SRGB,
+  [MESA_FORMAT_R8G8B8A8_SRGB] = BRW_SURFACEFORMAT_R8G8B8A8_UNORM_SRGB,
   [MESA_FORMAT_L_SRGB8] = BRW_SURFACEFORMAT_L8_UNORM_SRGB,
   [MESA_FORMAT_L8A8_SRGB] = BRW_SURFACEFORMAT_L8A8_UNORM_SRGB,
   [MESA_FORMAT_SRGB_DXT1] = BRW_SURFACEFORMAT_DXT1_RGB_SRGB,
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 13/30] i965: Add driver hook for TextureView

[Chris Forbes]

We need to wire the original texture's mt into the view. All the hard
work of setting up an appropriate tree of gl_texture_image structures
has already been done by core mesa.

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_tex.c | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_tex.c 
b/src/mesa/drivers/dri/i965/intel_tex.c
index 0e08aab..3b14796 100644
--- a/src/mesa/drivers/dri/i965/intel_tex.c
+++ b/src/mesa/drivers/dri/i965/intel_tex.c
@@ -237,6 +237,46 @@ intel_unmap_texture_image(struct gl_context *ctx,
intel_miptree_unmap(brw, mt, tex_image->Level, slice);
 }
 
+static GLboolean
+intel_texture_view(struct gl_context *ctx,
+   struct gl_texture_object *texObj,
+   struct gl_texture_object *origTexObj)
+{
+   struct intel_texture_object *intel_tex = intel_texture_object(texObj);
+   struct intel_texture_object *intel_orig_tex = 
intel_texture_object(origTexObj);
+
+   assert(intel_orig_tex->mt);
+   intel_miptree_reference(&intel_tex->mt, intel_orig_tex->mt);
+
+   /* Since we can only make views of immutable-format textures,
+* we can assume that everything is in origTexObj's miptree.
+*
+* Mesa core has already made us a copy of all the teximage objects,
+* except it hasn't copied our mt pointers, etc.
+*/
+   const int numFaces = _mesa_num_tex_faces(texObj->Target);
+   const int numLevels = texObj->NumLevels;
+
+   int face;
+   int level;
+
+   for (face = 0; face < numFaces; face++) {
+  for (level = 0; level < numLevels; level++) {
+ struct gl_texture_image *image = texObj->Image[face][level];
+ struct intel_texture_image *intel_image = intel_texture_image(image);
+
+ intel_miptree_reference(&intel_image->mt, intel_orig_tex->mt);
+  }
+   }
+
+   /* The miptree is in a validated state, so no need to check later. */
+   intel_tex->needs_validate = false;
+   intel_tex->validated_first_level = 0;
+   intel_tex->validated_last_level = numLevels - 1;
+
+   return GL_TRUE;
+}
+
 void
 intelInitTextureFuncs(struct dd_function_table *functions)
 {
@@ -249,4 +289,5 @@ intelInitTextureFuncs(struct dd_function_table *functions)
functions->AllocTextureStorage = intel_alloc_texture_storage;
functions->MapTextureImage = intel_map_texture_image;
functions->UnmapTextureImage = intel_unmap_texture_image;
+   functions->TextureView = intel_texture_view;
 }
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 05/30] i965: Enable R10G10B10A2_UNORM format

[Chris Forbes]

This is supported by all generations, and is required for memory layout
consistency for texture_view.

Signed-off-by: Chris Forbes 
---
 src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c 
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index b4c694d..c029d81 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -503,6 +503,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
   [MESA_FORMAT_Z_FLOAT32] = 0,
   [MESA_FORMAT_Z32_FLOAT_S8X24_UINT] = 0,
 
+  [MESA_FORMAT_R10G10B10A2_UNORM] = BRW_SURFACEFORMAT_R10G10B10A2_UNORM,
   [MESA_FORMAT_B10G10R10A2_UINT] = BRW_SURFACEFORMAT_B10G10R10A2_UINT,
   [MESA_FORMAT_R10G10B10A2_UINT] = BRW_SURFACEFORMAT_R10G10B10A2_UINT,
 
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 21/30] i965: Add `layered` parameter to intel_update_renderbuffer_wrapper

[Chris Forbes]

We're about to need this so we can determine the layer count of the
wrapper.

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_fbo.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
b/src/mesa/drivers/dri/i965/intel_fbo.c
index 98247f2..201e06f 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -501,8 +501,9 @@ intel_new_renderbuffer(struct gl_context * ctx, GLuint name)
 static bool
 intel_renderbuffer_update_wrapper(struct brw_context *brw,
   struct intel_renderbuffer *irb,
- struct gl_texture_image *image,
-  uint32_t layer)
+  struct gl_texture_image *image,
+  uint32_t layer,
+  bool layered)
 {
struct gl_renderbuffer *rb = &irb->Base.Base;
struct intel_texture_image *intel_image = intel_texture_image(image);
@@ -594,7 +595,7 @@ intel_render_texture(struct gl_context * ctx,
 
intel_miptree_check_level_layer(mt, att->TextureLevel, layer);
 
-   if (!intel_renderbuffer_update_wrapper(brw, irb, image, layer)) {
+   if (!intel_renderbuffer_update_wrapper(brw, irb, image, layer, 
att->Layered)) {
_swrast_render_texture(ctx, fb, att);
return;
}
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 25/30] i965/blorp: Account for nonzero MinLayer in layered clears.

[Chris Forbes]

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index c037aa5..6d42dce 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -590,7 +590,7 @@ brw_blorp_clear_color(struct brw_context *brw, struct 
gl_framebuffer *fb,
  unsigned num_layers = irb->layer_count;
  for (unsigned layer = 0; layer < num_layers; layer++) {
 if (!do_single_blorp_clear(brw, fb, rb, buf, partial_clear,
-   layer * layer_multiplier)) {
+   irb->mt_layer + layer * 
layer_multiplier)) {
return false;
 }
  }
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 19/30] i965: Enable texture upload fast path with MinLevel

[Chris Forbes]

We'll still avoid MinLayer here since the fast path doesn't understand
arrays at all, but it's straightforward to do levels.

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index 287b27b..891a46d 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -589,7 +589,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
   return false;
 
/* If this is a nontrivial texture view, let another path handle it 
instead. */
-   if (texImage->TexObject->MinLevel || texImage->TexObject->MinLayer)
+   if (texImage->TexObject->MinLayer)
   return false;
 
if (for_glTexImage)
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 20/30] i965: Adjust renderbuffer wrapper to account for MinLevel/MinLayer

[Chris Forbes]

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_fbo.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
b/src/mesa/drivers/dri/i965/intel_fbo.c
index d0e1349..98247f2 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -511,6 +511,10 @@ intel_renderbuffer_update_wrapper(struct brw_context *brw,
 
rb->AllocStorage = intel_nop_alloc_storage;
 
+   /* adjust for texture view parameters */
+   layer += image->TexObject->MinLayer;
+   level += image->TexObject->MinLevel;
+
intel_miptree_check_level_layer(mt, level, layer);
irb->mt_level = level;
 
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 06/30] i965: Pretend we don't support BRW_SURFACEFORMAT_R16G16B16_FLOAT for textures.

[Chris Forbes]

None of the other 3-component 16bpc formats are directly supported, so
they get promoted to XRGB equivalents. *Not* promoting RGB16F the same
way makes texture views much more fiddly -- we don't want to have to do
crazy copying behind the scenes.

(with my other master + my experimental ARB_texture_view support) fixes
the piglit test: `spec/ARB_texture_view/view compare 48bit formats`

No regressions in gpu.tests on Haswell.

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c 
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index c029d81..f203f52 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -267,7 +267,7 @@ const struct surface_format_info surface_formats[] = {
SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, BRW_SURFACEFORMAT_R64G64B64_FLOAT)
SF( Y,  Y,  x,  x,  x,  x,  x,  x,  x, BRW_SURFACEFORMAT_BC4_SNORM)
SF( Y,  Y,  x,  x,  x,  x,  x,  x,  x, BRW_SURFACEFORMAT_BC5_SNORM)
-   SF(50, 50,  x,  x,  x,  x, 60,  x,  x, BRW_SURFACEFORMAT_R16G16B16_FLOAT)
+   SF( x,  x,  x,  x,  x,  x, 60,  x,  x, BRW_SURFACEFORMAT_R16G16B16_FLOAT)
SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, BRW_SURFACEFORMAT_R16G16B16_UNORM)
SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, BRW_SURFACEFORMAT_R16G16B16_SNORM)
SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, BRW_SURFACEFORMAT_R16G16B16_SSCALED)
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 23/30] i965: Add layer_count to intel_renderbuffer

[Chris Forbes]

This is the effective layer count, for clears etc. This differs from the
depth of the miptree level when views are involved.

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_fbo.c | 10 ++
 src/mesa/drivers/dri/i965/intel_fbo.h |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
b/src/mesa/drivers/dri/i965/intel_fbo.c
index 5ade9e6..c70b1bf 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -319,6 +319,8 @@ intel_alloc_renderbuffer_storage(struct gl_context * ctx, 
struct gl_renderbuffer
if (!irb->mt)
   return false;
 
+   irb->layer_count = 1;
+
return true;
 }
 
@@ -383,6 +385,7 @@ intel_image_target_renderbuffer_storage(struct gl_context 
*ctx,
rb->Format = image->format;
rb->_BaseFormat = _mesa_base_fbo_format(ctx, image->internal_format);
rb->NeedsFinishRenderTexture = true;
+   irb->layer_count = 1;
 }
 
 /**
@@ -435,6 +438,7 @@ intel_create_renderbuffer(mesa_format format, unsigned 
num_samples)
}
 
rb = &irb->Base.Base;
+   irb->layer_count = 1;
 
_mesa_init_renderbuffer(rb, 0);
rb->ClassID = INTEL_RB_CLASS;
@@ -532,6 +536,12 @@ intel_renderbuffer_update_wrapper(struct brw_context *brw,
 
irb->mt_layer = layer_multiplier * layer;
 
+   if (layered) {
+  irb->layer_count = image->TexObject->NumLayers ?: mt->level[level].depth 
/ layer_multiplier;
+   } else {
+  irb->layer_count = 1;
+   }
+
intel_miptree_reference(&irb->mt, mt);
 
intel_renderbuffer_set_draw_offset(irb);
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.h 
b/src/mesa/drivers/dri/i965/intel_fbo.h
index fa457e2..c7cc570 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.h
+++ b/src/mesa/drivers/dri/i965/intel_fbo.h
@@ -90,6 +90,9 @@ struct intel_renderbuffer
 */
unsigned int mt_level;
unsigned int mt_layer;
+
+   /* The number of attached logical layers. */
+   unsigned int layer_count;
/** \} */
 
GLuint draw_x, draw_y; /**< Offset of drawing within the region */
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 01/30] mesa: Prefer non-swizzled formats for most sized internalformats

[Chris Forbes]

These formats can be cast to others (with different component types or
sizes) via ARB_texture_view or ARB_shader_image_load_store. We want
them to be laid out consistently so that we can just reinterpret the
memory with a different format.

In V1, this was done conditionally on a 'prefer_no_swizzle' flag which
was set in TexStorage/TextureView paths, but we need the same behavior
for ARB_shader_image_load_store (which also works with images created
via TexImage, so we don't want it to be conditional.

Signed-off-by: Chris Forbes 
---
 src/mesa/main/texformat.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index 004e7eb..d434804 100644
--- a/src/mesa/main/texformat.c
+++ b/src/mesa/main/texformat.c
@@ -76,11 +76,10 @@ _mesa_choose_tex_format(struct gl_context *ctx, GLenum 
target,
   } else if (type == GL_UNSIGNED_INT_2_10_10_10_REV) {
  RETURN_IF_SUPPORTED(MESA_FORMAT_B10G10R10A2_UNORM);
   }
-  RETURN_IF_SUPPORTED(MESA_FORMAT_A8B8G8R8_UNORM);
-  RETURN_IF_SUPPORTED(MESA_FORMAT_B8G8R8A8_UNORM);
-  break;
+  /* fallthrough */
 
case GL_RGBA8:
+  RETURN_IF_SUPPORTED(MESA_FORMAT_R8G8B8A8_UNORM);
   RETURN_IF_SUPPORTED(MESA_FORMAT_A8B8G8R8_UNORM);
   RETURN_IF_SUPPORTED(MESA_FORMAT_B8G8R8A8_UNORM);
   break;
@@ -97,6 +96,7 @@ _mesa_choose_tex_format(struct gl_context *ctx, GLenum target,
 
/* deep RGBA formats */
case GL_RGB10_A2:
+  RETURN_IF_SUPPORTED(MESA_FORMAT_R10G10B10A2_UNORM);
   RETURN_IF_SUPPORTED(MESA_FORMAT_B10G10R10A2_UNORM);
   RETURN_IF_SUPPORTED(MESA_FORMAT_B8G8R8A8_UNORM);
   break;
@@ -116,6 +116,10 @@ _mesa_choose_tex_format(struct gl_context *ctx, GLenum 
target,
   }
   /* fallthrough */
case GL_RGB8:
+  RETURN_IF_SUPPORTED(MESA_FORMAT_RGB_UNORM8);
+  RETURN_IF_SUPPORTED(MESA_FORMAT_R8G8B8X8_UNORM);
+  RETURN_IF_SUPPORTED(MESA_FORMAT_R8G8B8A8_UNORM);
+
   RETURN_IF_SUPPORTED(MESA_FORMAT_BGR_UNORM8);
   RETURN_IF_SUPPORTED(MESA_FORMAT_B8G8R8X8_UNORM);
   RETURN_IF_SUPPORTED(MESA_FORMAT_B8G8R8A8_UNORM);
@@ -451,10 +455,14 @@ _mesa_choose_tex_format(struct gl_context *ctx, GLenum 
target,
   break;
case GL_RGB_SNORM:
case GL_RGB8_SNORM:
+  RETURN_IF_SUPPORTED(MESA_FORMAT_R8G8B8X8_SNORM);
+  RETURN_IF_SUPPORTED(MESA_FORMAT_R8G8B8A8_SNORM);
   RETURN_IF_SUPPORTED(MESA_FORMAT_X8B8G8R8_SNORM);
-  /* FALLTHROUGH */
+  RETURN_IF_SUPPORTED(MESA_FORMAT_A8B8G8R8_SNORM);
+  break;
case GL_RGBA_SNORM:
case GL_RGBA8_SNORM:
+  RETURN_IF_SUPPORTED(MESA_FORMAT_R8G8B8A8_SNORM);
   RETURN_IF_SUPPORTED(MESA_FORMAT_A8B8G8R8_SNORM);
   RETURN_IF_SUPPORTED(MESA_FORMAT_R8G8B8A8_SNORM);
   break;
@@ -522,11 +530,17 @@ _mesa_choose_tex_format(struct gl_context *ctx, GLenum 
target,
 
case GL_SRGB_EXT:
case GL_SRGB8_EXT:
+  /* there is no MESA_FORMAT_RGB_SRGB8 */
+  RETURN_IF_SUPPORTED(MESA_FORMAT_R8G8B8X8_SRGB);
+  RETURN_IF_SUPPORTED(MESA_FORMAT_R8G8B8A8_SRGB);
+
   RETURN_IF_SUPPORTED(MESA_FORMAT_BGR_SRGB8);
   RETURN_IF_SUPPORTED(MESA_FORMAT_B8G8R8A8_SRGB);
   break;
case GL_SRGB_ALPHA_EXT:
case GL_SRGB8_ALPHA8_EXT:
+  RETURN_IF_SUPPORTED(MESA_FORMAT_R8G8B8A8_SRGB);
+
   RETURN_IF_SUPPORTED(MESA_FORMAT_A8B8G8R8_SRGB);
   RETURN_IF_SUPPORTED(MESA_FORMAT_B8G8R8A8_SRGB);
   break;
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 09/30] i965: Include #slices in miptree debug

[Chris Forbes]

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 9c5623c..1a7a9e8 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -231,10 +231,10 @@ intel_miptree_create_layout(struct brw_context *brw,
if (!mt)
   return NULL;
 
-   DBG("%s target %s format %s level %d..%d <-- %p\n", __FUNCTION__,
+   DBG("%s target %s format %s level %d..%d slices %d <-- %p\n", __FUNCTION__,
_mesa_lookup_enum_by_nr(target),
_mesa_get_format_name(format),
-   first_level, last_level, mt);
+   first_level, last_level, depth0, mt);
 
mt->target = target;
mt->format = format;
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 18/30] i965: Account for MinLevel in texture upload fast path

[Chris Forbes]

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index 7143ab7..287b27b 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -634,9 +634,11 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
packing->Alignment, packing->RowLength, packing->SkipPixels,
packing->SkipRows, for_glTexImage);
 
+   int level = texImage->Level + texImage->TexObject->MinLevel;
+
/* Adjust x and y offset based on miplevel */
-   xoffset += image->mt->level[texImage->Level].level_x;
-   yoffset += image->mt->level[texImage->Level].level_y;
+   xoffset += image->mt->level[level].level_x;
+   yoffset += image->mt->level[level].level_y;
 
linear_to_tiled(
   xoffset * cpp, (xoffset + width) * cpp,
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 28/30] i965: Account for view parameters in blit CTSI path

[Chris Forbes]

Signed-off-by: Chris Forbes 
---
 src/mesa/drivers/dri/i965/intel_tex_copy.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_copy.c 
b/src/mesa/drivers/dri/i965/intel_tex_copy.c
index ca0b5b9..c2b6c35 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_copy.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_copy.c
@@ -74,12 +74,17 @@ intel_copy_texsubimage(struct brw_context *brw,
   return false;
}
 
+   /* account for view parameters and face index */
+   int dst_level = intelImage->base.Base.Level +
+   intelImage->base.Base.TexObject->MinLevel;
+   int dst_slice = slice + intelImage->base.Base.Face +
+   intelImage->base.Base.TexObject->MinLayer;
+
/* blit from src buffer to texture */
if (!intel_miptree_blit(brw,
irb->mt, irb->mt_level, irb->mt_layer,
x, y, irb->Base.Base.Name == 0,
-   intelImage->mt, intelImage->base.Base.Level,
-   intelImage->base.Base.Face + slice,
+   intelImage->mt, dst_level, dst_slice,
dstx, dsty, false,
width, height, GL_COPY)) {
   return false;
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 24/30] i965/blorp: Use irb->layer_count in clear

[Chris Forbes]

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index d16da97..c037aa5 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -587,8 +587,7 @@ brw_blorp_clear_color(struct brw_context *brw, struct 
gl_framebuffer *fb,
 (irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_UMS ||
  irb->mt->msaa_layout == INTEL_MSAA_LAYOUT_CMS) ?
 irb->mt->num_samples : 1;
- unsigned num_layers =
-irb->mt->level[irb->mt_level].depth / layer_multiplier;
+ unsigned num_layers = irb->layer_count;
  for (unsigned layer = 0; layer < num_layers; layer++) {
 if (!do_single_blorp_clear(brw, fb, rb, buf, partial_clear,
layer * layer_multiplier)) {
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 30/30] docs: Mark off ARB_texture_view and add to release notes for 10.2.

[Chris Forbes]

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 docs/GL3.txt| 2 +-
 docs/relnotes/10.2.html | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index b7e4c87..657ac7e 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -162,7 +162,7 @@ GL 4.3:
   GL_ARB_texture_buffer_range  DONE (nv50, nvc0, i965, 
r600, radeonsi)
   GL_ARB_texture_query_levels  DONE (i965)
   GL_ARB_texture_storage_multisample   DONE (all drivers that 
support GL_ARB_texture_multisample)
-  GL_ARB_texture_view  started (Courtney 
Goeltzenleuchter, Chris Forbes)
+  GL_ARB_texture_view  DONE (i965)
   GL_ARB_vertex_attrib_binding DONE (all drivers)
 
 
diff --git a/docs/relnotes/10.2.html b/docs/relnotes/10.2.html
index da79e7d..2d15173 100644
--- a/docs/relnotes/10.2.html
+++ b/docs/relnotes/10.2.html
@@ -46,6 +46,7 @@ Note: some of the new features are only available with 
certain drivers.
 
 GL_ARB_buffer_storage on r300, r600, and radeonsi
 GL_ARB_stencil_texturing on i965/gen8+
+ARB_texture_view on i965/gen7+
 
 
 
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 29/30] i965: Enable ARB_texture_view on Gen7+

[Chris Forbes]

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 15fcd30..b7280671 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -287,6 +287,7 @@ intelInitExtensions(struct gl_context *ctx)
if (brw->gen >= 7) {
   ctx->Extensions.ARB_conservative_depth = true;
   ctx->Extensions.AMD_vertex_shader_layer = true;
+  ctx->Extensions.ARB_texture_view = true;
   if (can_do_pipelined_register_writes(brw)) {
  ctx->Extensions.ARB_transform_feedback2 = true;
  ctx->Extensions.ARB_transform_feedback3 = true;
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 27/30] i965: Account for MinLayer/MinLevel in blorp CTSI path

[Chris Forbes]

Signed-off-by: Chris Forbes 
---
 src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 9e80935..300ff5c 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -402,9 +402,13 @@ brw_blorp_copytexsubimage(struct brw_context *brw,
   mirror_y = true;
}
 
+   /* Account for face selection and texture view MinLayer */
+   int dst_slice = slice + dst_image->TexObject->MinLayer + dst_image->Face;
+   int dst_level = dst_image->Level + dst_image->TexObject->MinLevel;
+
brw_blorp_blit_miptrees(brw,
src_mt, src_irb->mt_level, src_irb->mt_layer,
-   dst_mt, dst_image->Level, dst_image->Face + slice,
+   dst_mt, dst_level, dst_slice,
srcX0, srcY0, srcX1, srcY1,
dstX0, dstY0, dstX1, dstY1,
GL_NEAREST, false, mirror_y);
@@ -427,8 +431,7 @@ brw_blorp_copytexsubimage(struct brw_context *brw,
   if (src_mt != dst_mt) {
  brw_blorp_blit_miptrees(brw,
  src_mt, src_irb->mt_level, src_irb->mt_layer,
- dst_mt, dst_image->Level,
- dst_image->Face + slice,
+ dst_mt, dst_level, dst_slice,
  srcX0, srcY0, srcX1, srcY1,
  dstX0, dstY0, dstX1, dstY1,
  GL_NEAREST, false, mirror_y);
-- 
1.9.1

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

[Mesa-dev] [PATCH V3 26/30] i965: Account for view parameters in fast depth clears

[Chris Forbes]

V2: - No need for layer_multiplier; multisampled depth surfaces are IMS.
- Remove unused num_layers.

Signed-off-by: Chris Forbes 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_clear.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 6571e84..a487a71 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -187,9 +187,9 @@ brw_fast_clear_depth(struct gl_context *ctx)
intel_batchbuffer_emit_mi_flush(brw);
 
if (fb->MaxNumLayers > 0) {
-  unsigned num_layers = depth_irb->mt->level[depth_irb->mt_level].depth;
-  for (unsigned layer = 0; layer < num_layers; layer++) {
- intel_hiz_exec(brw, mt, depth_irb->mt_level, layer,
+  for (unsigned layer = 0; layer < depth_irb->layer_count; layer++) {
+ intel_hiz_exec(brw, mt, depth_irb->mt_level,
+depth_irb->mt_layer + layer,
 GEN6_HIZ_OP_DEPTH_CLEAR);
   }
} else {
-- 
1.9.1

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

[Mesa-dev] [PATCH V2] i965/vec4: do not trim dead channels on gen6 for math

[Tapani Pälli]

Do not set a writemask on Gen6 for math instructions, those are
executed using align1 mode that does not support a destination mask.

v2: cleanups, better comment (Matt)

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

Signed-off-by: Tapani Pälli 
---
 src/mesa/drivers/dri/i965/brw_vec4.cpp | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 32a3892..a86d42c 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -322,7 +322,8 @@ src_reg::equals(src_reg *r)
 }
 
 static bool
-try_eliminate_instruction(vec4_instruction *inst, int new_writemask)
+try_eliminate_instruction(vec4_instruction *inst, int new_writemask,
+  const struct brw_context *brw)
 {
if (new_writemask == 0) {
   /* Don't dead code eliminate instructions that write to the
@@ -351,7 +352,10 @@ try_eliminate_instruction(vec4_instruction *inst, int 
new_writemask)
   case VS_OPCODE_PULL_CONSTANT_LOAD_GEN7:
  break;
   default:
- if (!inst->is_tex()) {
+ /* Do not set a writemask on Gen6 for math instructions, those are
+  * executed using align1 mode that does not support a destination 
mask.
+  */
+ if (!(brw->gen == 6 && inst->is_math()) && !inst->is_tex()) {
 inst->dst.writemask = new_writemask;
 return true;
  }
@@ -407,7 +411,8 @@ vec4_visitor::dead_code_eliminate()
 }
  }
 
- progress = try_eliminate_instruction(inst, write_mask) || progress;
+ progress = try_eliminate_instruction(inst, write_mask, brw) ||
+progress;
   }
 
   if (seen_control_flow || inst->predicate || inst->prev == NULL)
@@ -456,7 +461,7 @@ vec4_visitor::dead_code_eliminate()
  if (inst->dst.reg == scan_inst->dst.reg) {
 int new_writemask = scan_inst->dst.writemask & ~dead_channels;
 
-progress = try_eliminate_instruction(scan_inst, new_writemask) ||
+progress = try_eliminate_instruction(scan_inst, new_writemask, 
brw) ||
progress;
  }
 
-- 
1.8.3.1

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

Re: [Mesa-dev] [PATCH] Revert "radeon: just don't map VRAM buffers at all"

[Christian König]

Am 01.04.2014 15:47, schrieb Leo Liu:

From: Leo Liu 

This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.


The patch itself is ok, but we should probably add an explanation why we 
want to revert this.


Christian.



Signed-off-by: Leo Liu 
---
  src/gallium/drivers/radeon/r600_texture.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index 45a9508..3dfddca 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -928,8 +928,8 @@ static void *r600_texture_transfer_map(struct pipe_context 
*ctx,
if (rtex->surface.level[level].mode >= RADEON_SURF_MODE_1D)
use_staging_texture = TRUE;
  
-	/* Untiled buffers in VRAM, which is slow for CPU reads and writes */

-   if (!(usage & PIPE_TRANSFER_MAP_DIRECTLY) &&
+   /* Untiled buffers in VRAM, which is slow for CPU reads */
+   if ((usage & PIPE_TRANSFER_READ) && !(usage & PIPE_TRANSFER_MAP_DIRECTLY) 
&&
(rtex->resource.domains == RADEON_DOMAIN_VRAM)) {
use_staging_texture = TRUE;
}


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

Re: [Mesa-dev] [PATCH 0/6] Some glapi clean-up releated to GLES

[Jose Fonseca]

- Original Message -
> Tomorrow or Friday I'm going to send out the last of the
> GL_ARB_separate_shader_objects patches.  Shortly after that, I will send
> out patches to enable GL_EXT_separate_shader_objects on GLES.  This EXT
> is the GLES subset of the ARB extension.
> 
> In preparing for this new extension, I noticed the old problem that any
> extension function that aliases a core function (whether it is core in
> GLES or desktop GL) isn't hidden.  This series should fix that.
> 
> Longer term, I'd like to change the generation of libGL*.  Right now all
> the information describing the interfaces and the information selecting
> the exposed interfaces in combined in a single XML database.  As patch 4
> shows, that makes it impossible to have a single function that is
> exposed in one API but hidden in another.  I'd like to pull all the
> "offset", "static_dispatch", "glx_ignore", and "exec" information out
> into separate files.
> 
> This will mean that adding a new extension will require changes to
> multiple files.  The usual XML bits will need to be added.  Entries will
> need to be add to per-libGL* files, an "exec" file, and an "offsets".
> We can probably get rid of the offsets file since no functions will ever
> be added that have static offsets.

ABI details like symbol visibility can vary not only per API but also per 
platform, so having these ABI details seperate from the prototypes (which are 
cross-platform and cross-API) sounds a good idea to me.

On the topic of glapi cleanup, I noticed that a lot of glapi code ends up 
mixing scripted C code generation with C pre-processor macros. I'm sure there 
are historic reasons for it but this combination obfuscates the code. It would 
be better to use only one of the techniques; or more realistically, drop the 
macros and rely on code generation exclusively.  It would be much easier for 
humans to reason about the generated code then.

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

[Mesa-dev] [PATCH] Revert "radeon: just don't map VRAM buffers at all"

[Leo Liu]

From: Leo Liu 

This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
In the case of VCE encoding with raw YUV file, CPU load directly
to VRAM is faster than combination of CPU writing to GTT and
then blit to VRAM with GPU.
---
 src/gallium/drivers/radeon/r600_texture.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index 45a9508..3dfddca 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -928,8 +928,8 @@ static void *r600_texture_transfer_map(struct pipe_context 
*ctx,
if (rtex->surface.level[level].mode >= RADEON_SURF_MODE_1D)
use_staging_texture = TRUE;
 
-   /* Untiled buffers in VRAM, which is slow for CPU reads and writes */
-   if (!(usage & PIPE_TRANSFER_MAP_DIRECTLY) &&
+   /* Untiled buffers in VRAM, which is slow for CPU reads */
+   if ((usage & PIPE_TRANSFER_READ) && !(usage & 
PIPE_TRANSFER_MAP_DIRECTLY) &&
(rtex->resource.domains == RADEON_DOMAIN_VRAM)) {
use_staging_texture = TRUE;
}
-- 
1.8.1.2


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

Re: [Mesa-dev] Guidance in dwelling in the world of GPU driver development.

[Leander Bessa Beernaert]

Thanks!

Not sure yet what I'll be working on yet, but I'll be sure to look into
nouveau.

Would it be possible for me to go about and work on OpenGL features which
are beyond the capabilities of my GPU?


On Mon, Mar 31, 2014 at 7:14 PM, Ilia Mirkin  wrote:

> On Mon, Mar 31, 2014 at 11:17 AM, Leander Bessa Beernaert
>  wrote:
> > Hey,
> >
> > I'm interested in dwelling deeper in the world of GPU driver development
>  in
> > my spare time. Since I'm a fan of OpenSource, Mesa3D sounded like a good
> > place to start :).
> >
> > I have some experience using OpenGL from a programmers perspective, but
> > would like to know more about the gritty details hiding behind an
> > implementation.
> >
> > I was wondering if anyone could give me some guidance as to where to
> start
> > (aside from the content posted on the main page)?
> >
> > I am currently using a Macbook Pro (nvidia 9400m and nvidia 9600m GT)
> with
> > Ubuntu 13.10 alongside OS X. Is this machine enough to start poking
> around
> > any of the current projects or should I wait and get a more recent OpenGL
> > 4.3 capable machine?
>
> If you're looking to specifically contribute to nouveau (nvidia
> open-source drivers), you should take a look at
> https://trello.com/b/ZudRDiTL/nouveau for some things we've identified
> as todo's, and also join us in #nouveau on irc.freenode.net (the
> channel can be quiet at times, so if no one's there, don't despair :)
> ).
>
>   -ilia
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Revert "radeon: just don't map VRAM buffers at all"

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Wed, Apr 2, 2014 at 3:09 PM, Leo Liu  wrote:
> From: Leo Liu 
>
> This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
> In the case of VCE encoding with raw YUV file, CPU load directly
> to VRAM is faster than combination of CPU writing to GTT and
> then blit to VRAM with GPU.
> ---
>  src/gallium/drivers/radeon/r600_texture.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_texture.c 
> b/src/gallium/drivers/radeon/r600_texture.c
> index 45a9508..3dfddca 100644
> --- a/src/gallium/drivers/radeon/r600_texture.c
> +++ b/src/gallium/drivers/radeon/r600_texture.c
> @@ -928,8 +928,8 @@ static void *r600_texture_transfer_map(struct 
> pipe_context *ctx,
> if (rtex->surface.level[level].mode >= RADEON_SURF_MODE_1D)
> use_staging_texture = TRUE;
>
> -   /* Untiled buffers in VRAM, which is slow for CPU reads and writes */
> -   if (!(usage & PIPE_TRANSFER_MAP_DIRECTLY) &&
> +   /* Untiled buffers in VRAM, which is slow for CPU reads */
> +   if ((usage & PIPE_TRANSFER_READ) && !(usage & 
> PIPE_TRANSFER_MAP_DIRECTLY) &&
> (rtex->resource.domains == RADEON_DOMAIN_VRAM)) {
> use_staging_texture = TRUE;
> }
> --
> 1.8.1.2
>
>
> ___
> 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] Revert "radeon: just don't map VRAM buffers at all"

[Alex Deucher]

On Wed, Apr 2, 2014 at 9:09 AM, Leo Liu  wrote:
> From: Leo Liu 
>
> This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
> In the case of VCE encoding with raw YUV file, CPU load directly
> to VRAM is faster than combination of CPU writing to GTT and
> then blit to VRAM with GPU.

Why was the original patch applied?  I just want to make sure it
wasn't a bug fix for avoiding a sigbus or something similar if we ran
out of cpu visible vram.

Alex

> ---
>  src/gallium/drivers/radeon/r600_texture.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_texture.c 
> b/src/gallium/drivers/radeon/r600_texture.c
> index 45a9508..3dfddca 100644
> --- a/src/gallium/drivers/radeon/r600_texture.c
> +++ b/src/gallium/drivers/radeon/r600_texture.c
> @@ -928,8 +928,8 @@ static void *r600_texture_transfer_map(struct 
> pipe_context *ctx,
> if (rtex->surface.level[level].mode >= RADEON_SURF_MODE_1D)
> use_staging_texture = TRUE;
>
> -   /* Untiled buffers in VRAM, which is slow for CPU reads and writes */
> -   if (!(usage & PIPE_TRANSFER_MAP_DIRECTLY) &&
> +   /* Untiled buffers in VRAM, which is slow for CPU reads */
> +   if ((usage & PIPE_TRANSFER_READ) && !(usage & 
> PIPE_TRANSFER_MAP_DIRECTLY) &&
> (rtex->resource.domains == RADEON_DOMAIN_VRAM)) {
> use_staging_texture = TRUE;
> }
> --
> 1.8.1.2
>
>
> ___
> 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] Revert "radeon: just don't map VRAM buffers at all"

[Marek Olšák]

Also, the VCE code could use PIPE_TRANSFER_MAP_DIRECTLY to avoid the
blit and this patch wouldn't be needed.

Marek

On Wed, Apr 2, 2014 at 3:30 PM, Alex Deucher  wrote:
> On Wed, Apr 2, 2014 at 9:09 AM, Leo Liu  wrote:
>> From: Leo Liu 
>>
>> This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
>> In the case of VCE encoding with raw YUV file, CPU load directly
>> to VRAM is faster than combination of CPU writing to GTT and
>> then blit to VRAM with GPU.
>
> Why was the original patch applied?  I just want to make sure it
> wasn't a bug fix for avoiding a sigbus or something similar if we ran
> out of cpu visible vram.
>
> Alex
>
>> ---
>>  src/gallium/drivers/radeon/r600_texture.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/drivers/radeon/r600_texture.c 
>> b/src/gallium/drivers/radeon/r600_texture.c
>> index 45a9508..3dfddca 100644
>> --- a/src/gallium/drivers/radeon/r600_texture.c
>> +++ b/src/gallium/drivers/radeon/r600_texture.c
>> @@ -928,8 +928,8 @@ static void *r600_texture_transfer_map(struct 
>> pipe_context *ctx,
>> if (rtex->surface.level[level].mode >= RADEON_SURF_MODE_1D)
>> use_staging_texture = TRUE;
>>
>> -   /* Untiled buffers in VRAM, which is slow for CPU reads and writes */
>> -   if (!(usage & PIPE_TRANSFER_MAP_DIRECTLY) &&
>> +   /* Untiled buffers in VRAM, which is slow for CPU reads */
>> +   if ((usage & PIPE_TRANSFER_READ) && !(usage & 
>> PIPE_TRANSFER_MAP_DIRECTLY) &&
>> (rtex->resource.domains == RADEON_DOMAIN_VRAM)) {
>> use_staging_texture = TRUE;
>> }
>> --
>> 1.8.1.2
>>
>>
>> ___
>> 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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Revert "radeon: just don't map VRAM buffers at all"

[Christian König]

I've applied the original patch because the same thing for reading 
textures speeded up the decoding case with UVD quite significantly.


For VCE it reduced the CPU load as well, but I didn't checked if the 
encoding time stayed the same (which isn't the case). I think the 
problem is that VCE needs to wait for the DMA or 3D engine to complete 
the upload before it can proceed and because of this becomes idle, gets 
clocked down etc... When the frame has finished uploading we clock VCE 
up and get it running again and this needs time.


Anyway I've added the patch specially for VCE, so just disabling it for 
VCE doesn't make much sense.


Christian.

Am 02.04.2014 15:34, schrieb Marek Olšák:

Also, the VCE code could use PIPE_TRANSFER_MAP_DIRECTLY to avoid the
blit and this patch wouldn't be needed.

Marek

On Wed, Apr 2, 2014 at 3:30 PM, Alex Deucher  wrote:

On Wed, Apr 2, 2014 at 9:09 AM, Leo Liu  wrote:

From: Leo Liu 

This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
In the case of VCE encoding with raw YUV file, CPU load directly
to VRAM is faster than combination of CPU writing to GTT and
then blit to VRAM with GPU.

Why was the original patch applied?  I just want to make sure it
wasn't a bug fix for avoiding a sigbus or something similar if we ran
out of cpu visible vram.

Alex


---
  src/gallium/drivers/radeon/r600_texture.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index 45a9508..3dfddca 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -928,8 +928,8 @@ static void *r600_texture_transfer_map(struct pipe_context 
*ctx,
 if (rtex->surface.level[level].mode >= RADEON_SURF_MODE_1D)
 use_staging_texture = TRUE;

-   /* Untiled buffers in VRAM, which is slow for CPU reads and writes */
-   if (!(usage & PIPE_TRANSFER_MAP_DIRECTLY) &&
+   /* Untiled buffers in VRAM, which is slow for CPU reads */
+   if ((usage & PIPE_TRANSFER_READ) && !(usage & PIPE_TRANSFER_MAP_DIRECTLY) 
&&
 (rtex->resource.domains == RADEON_DOMAIN_VRAM)) {
 use_staging_texture = TRUE;
 }
--
1.8.1.2


___
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 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 0/6] Some glapi clean-up releated to GLES

[Brian Paul]

On 04/02/2014 06:21 AM, Jose Fonseca wrote:

- Original Message -

Tomorrow or Friday I'm going to send out the last of the
GL_ARB_separate_shader_objects patches.  Shortly after that, I will send
out patches to enable GL_EXT_separate_shader_objects on GLES.  This EXT
is the GLES subset of the ARB extension.

In preparing for this new extension, I noticed the old problem that any
extension function that aliases a core function (whether it is core in
GLES or desktop GL) isn't hidden.  This series should fix that.

Longer term, I'd like to change the generation of libGL*.  Right now all
the information describing the interfaces and the information selecting
the exposed interfaces in combined in a single XML database.  As patch 4
shows, that makes it impossible to have a single function that is
exposed in one API but hidden in another.  I'd like to pull all the
"offset", "static_dispatch", "glx_ignore", and "exec" information out
into separate files.

This will mean that adding a new extension will require changes to
multiple files.  The usual XML bits will need to be added.  Entries will
need to be add to per-libGL* files, an "exec" file, and an "offsets".
We can probably get rid of the offsets file since no functions will ever
be added that have static offsets.


ABI details like symbol visibility can vary not only per API but also per 
platform, so having these ABI details seperate from the prototypes (which are 
cross-platform and cross-API) sounds a good idea to me.

On the topic of glapi cleanup, I noticed that a lot of glapi code ends up 
mixing scripted C code generation with C pre-processor macros. I'm sure there 
are historic reasons for it but this combination obfuscates the code. It would 
be better to use only one of the techniques; or more realistically, drop the 
macros and rely on code generation exclusively.  It would be much easier for 
humans to reason about the generated code then.


Definitely.  When I did the first version of the dispatch code in late 
'99 I hand-wrote the glapitable.h and glapitemp.h files.  When the 
python code generators came around (I _think_ I did the first version of 
that too), we (or I) should have immediately dropped the glapitemp.h 
file and just generated the .c files that were #including glapitemp.h 
directly.


I've been wanting to make that change for years but have never gotten 
around to it.


I'm in favor of anything that simplifies the dispatch code!

-Brian


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

Re: [Mesa-dev] [PATCH] Revert "radeon: just don't map VRAM buffers at all"

[Liu, Leo]

Okay. with "PIPE_TRANSFER_MAP_DIRECTLY", the regression can be fixed too.
Going to resend patch for this approach.

Leo


>-Original Message-
>From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of
>Christian König
>Sent: Wednesday, April 02, 2014 9:43 AM
>To: Marek Olšák; Alex Deucher
>Cc: mesa-dev@lists.freedesktop.org
>Subject: Re: [Mesa-dev] [PATCH] Revert "radeon: just don't map VRAM buffers at
>all"
>
>I've applied the original patch because the same thing for reading textures
>speeded up the decoding case with UVD quite significantly.
>
>For VCE it reduced the CPU load as well, but I didn't checked if the encoding 
>time
>stayed the same (which isn't the case). I think the problem is that VCE needs 
>to
>wait for the DMA or 3D engine to complete the upload before it can proceed and
>because of this becomes idle, gets clocked down etc... When the frame has
>finished uploading we clock VCE up and get it running again and this needs 
>time.
>
>Anyway I've added the patch specially for VCE, so just disabling it for VCE 
>doesn't
>make much sense.
>
>Christian.
>
>Am 02.04.2014 15:34, schrieb Marek Olšák:
>> Also, the VCE code could use PIPE_TRANSFER_MAP_DIRECTLY to avoid the
>> blit and this patch wouldn't be needed.
>>
>> Marek
>>
>> On Wed, Apr 2, 2014 at 3:30 PM, Alex Deucher 
>wrote:
>>> On Wed, Apr 2, 2014 at 9:09 AM, Leo Liu  wrote:
 From: Leo Liu 

 This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
 In the case of VCE encoding with raw YUV file, CPU load directly to
 VRAM is faster than combination of CPU writing to GTT and then blit
 to VRAM with GPU.
>>> Why was the original patch applied?  I just want to make sure it
>>> wasn't a bug fix for avoiding a sigbus or something similar if we ran
>>> out of cpu visible vram.
>>>
>>> Alex
>>>
 ---
   src/gallium/drivers/radeon/r600_texture.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/src/gallium/drivers/radeon/r600_texture.c
 b/src/gallium/drivers/radeon/r600_texture.c
 index 45a9508..3dfddca 100644
 --- a/src/gallium/drivers/radeon/r600_texture.c
 +++ b/src/gallium/drivers/radeon/r600_texture.c
 @@ -928,8 +928,8 @@ static void *r600_texture_transfer_map(struct
>pipe_context *ctx,
  if (rtex->surface.level[level].mode >= RADEON_SURF_MODE_1D)
  use_staging_texture = TRUE;

 -   /* Untiled buffers in VRAM, which is slow for CPU reads and writes 
 */
 -   if (!(usage & PIPE_TRANSFER_MAP_DIRECTLY) &&
 +   /* Untiled buffers in VRAM, which is slow for CPU reads */
 +   if ((usage & PIPE_TRANSFER_READ) && !(usage &
 + PIPE_TRANSFER_MAP_DIRECTLY) &&
  (rtex->resource.domains == RADEON_DOMAIN_VRAM)) {
  use_staging_texture = TRUE;
  }
 --
 1.8.1.2


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

Re: [Mesa-dev] [PATCH 4/4] xa: reuse surfaces

[Roland Scheidegger]

Am 02.04.2014 09:47, schrieb Thomas Hellstrom:
> On 04/01/2014 05:04 PM, Rob Clark wrote:
>> From: Rob Clark 
>>
>> Otherwise it will trick the gallium driver into thinking that the render
>> target has actually changed (due to different pipe_surface pointing to
>> same underlying pipe_resource).  This is really badness for tiling GPUs
>> like adreno.
> 
> Rob, if we want to cache gallium surfaces like this, we need to
> condition it on the same context being used.
> We can't reuse a surface created with one context for rendering with
> another context. (I know the mesa state tracker needs to
> fix this up as well).
> 
> While this can be done easily within XA for non-shared xa_surfaces, I
> wonder what happens in the case of
> shared xa_surfaces? More specifically, is rendering allowed to be cached
> in the gallium surface until explicitly flushed to the texture? (I'm
> unsure about gallium surface semantics here).
The surface itself is supposed to be "transparent", think of it as
simply a means to get access (as a render target) to the resource, so
surfaces themselves do not have any pixel content. So I guess they'd be
synchronized (or rather the underlying resources are) if rendering is
synchronized from two contexts. That's at least how I think it should
work...

> /Thomas
> 
>> Signed-off-by: Rob Clark 
>> ---
>>  src/gallium/state_trackers/xa/xa_context.c | 35 
>> +++---
>>  src/gallium/state_trackers/xa/xa_priv.h|  3 ++-
>>  src/gallium/state_trackers/xa/xa_tracker.c |  1 +
>>  3 files changed, 30 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/xa/xa_context.c 
>> b/src/gallium/state_trackers/xa/xa_context.c
>> index 867999a..18f0b85 100644
>> --- a/src/gallium/state_trackers/xa/xa_context.c
>> +++ b/src/gallium/state_trackers/xa/xa_context.c
>> @@ -179,6 +179,25 @@ xa_surface_unmap(struct xa_surface *srf)
>>  }
>>  }
>>  
>> +static int
>> +xa_srf_create(struct xa_context *ctx, struct xa_surface *srf)
>> +{
>> +struct pipe_screen *screen = ctx->pipe->screen;
>> +struct pipe_surface srf_templ;
>> +
>> +if (!screen->is_format_supported(screen,  srf->tex->format,
>> + PIPE_TEXTURE_2D, 0,
>> + PIPE_BIND_RENDER_TARGET))
>> +return -XA_ERR_INVAL;
>> +
>> +u_surface_default_template(&srf_templ, srf->tex);
>> +srf->srf = ctx->pipe->create_surface(ctx->pipe, srf->tex, &srf_templ);
>> +if (!srf->srf)
>> +return -XA_ERR_NORES;
>> +
>> +return XA_ERR_NONE;
>> +}
>> +
>>  int
>>  xa_ctx_srf_create(struct xa_context *ctx, struct xa_surface *dst)
>>  {
>> @@ -188,15 +207,15 @@ xa_ctx_srf_create(struct xa_context *ctx, struct 
>> xa_surface *dst)
>>  if (ctx->srf)
>>  return -XA_ERR_INVAL;
>>  
>> -if (!screen->is_format_supported(screen,  dst->tex->format,
>> - PIPE_TEXTURE_2D, 0,
>> - PIPE_BIND_RENDER_TARGET))
>> -return -XA_ERR_INVAL;
>> +if (!dst->srf) {
>> +int ret = xa_srf_create(ctx, dst);
>> +if (ret != XA_ERR_NONE)
>> +return ret;
>> +}
>>  
>> -u_surface_default_template(&srf_templ, dst->tex);
>> -ctx->srf = ctx->pipe->create_surface(ctx->pipe, dst->tex, &srf_templ);
>> -if (!ctx->srf)
>> -return -XA_ERR_NORES;
>> +assert(dst->srf);
>> +
>> +pipe_surface_reference(&ctx->srf, dst->srf);
>>  
>>  return XA_ERR_NONE;
>>  }
>> diff --git a/src/gallium/state_trackers/xa/xa_priv.h 
>> b/src/gallium/state_trackers/xa/xa_priv.h
>> index 7a43386..5ade6c1 100644
>> --- a/src/gallium/state_trackers/xa/xa_priv.h
>> +++ b/src/gallium/state_trackers/xa/xa_priv.h
>> @@ -46,7 +46,7 @@
>>  #define XA_EXPORT
>>  #endif
>>  
>> -#define XA_VB_SIZE (100 * 4 * 3 * 4)
>> +#define XA_VB_SIZE (170 * 4 * 3 * 4)
>>  #define XA_LAST_SURFACE_TYPE (xa_type_yuv_component + 1)
>>  #define XA_MAX_SAMPLERS 3
>>  
>> @@ -65,6 +65,7 @@ struct xa_surface {
>>  struct pipe_resource template;
>>  struct xa_tracker *xa;
>>  struct pipe_resource *tex;
>> +struct pipe_surface *srf;
>>  struct pipe_transfer *transfer;
>>  unsigned int flags;
>>  struct xa_format_descriptor fdesc;
>> diff --git a/src/gallium/state_trackers/xa/xa_tracker.c 
>> b/src/gallium/state_trackers/xa/xa_tracker.c
>> index 9add584..7fed20a 100644
>> --- a/src/gallium/state_trackers/xa/xa_tracker.c
>> +++ b/src/gallium/state_trackers/xa/xa_tracker.c
>> @@ -474,6 +474,7 @@ xa_surface_unref(struct xa_surface *srf)
>>  if (srf == NULL || --srf->refcount) {
>>  return;
>>  }
>> +pipe_surface_reference(&srf->srf, NULL);
>>  pipe_resource_reference(&srf->tex, NULL);
>>  free(srf);
>>  }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Revert "radeon: just don't map VRAM buffers at all"

[Christian König]

No wait a second. As explained I've added the code in question specially 
for VCE so if we disable it for VCE it won't be used.


I still think that reverting the patch is the right approach.

Christian.

Am 02.04.2014 15:54, schrieb Liu, Leo:

Okay. with "PIPE_TRANSFER_MAP_DIRECTLY", the regression can be fixed too.
Going to resend patch for this approach.

Leo



-Original Message-
From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of
Christian König
Sent: Wednesday, April 02, 2014 9:43 AM
To: Marek Olšák; Alex Deucher
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Revert "radeon: just don't map VRAM buffers at
all"

I've applied the original patch because the same thing for reading textures
speeded up the decoding case with UVD quite significantly.

For VCE it reduced the CPU load as well, but I didn't checked if the encoding 
time
stayed the same (which isn't the case). I think the problem is that VCE needs to
wait for the DMA or 3D engine to complete the upload before it can proceed and
because of this becomes idle, gets clocked down etc... When the frame has
finished uploading we clock VCE up and get it running again and this needs time.

Anyway I've added the patch specially for VCE, so just disabling it for VCE 
doesn't
make much sense.

Christian.

Am 02.04.2014 15:34, schrieb Marek Olšák:

Also, the VCE code could use PIPE_TRANSFER_MAP_DIRECTLY to avoid the
blit and this patch wouldn't be needed.

Marek

On Wed, Apr 2, 2014 at 3:30 PM, Alex Deucher 

wrote:

On Wed, Apr 2, 2014 at 9:09 AM, Leo Liu  wrote:

From: Leo Liu 

This reverts commit 96e8b916a7a39a9ba58e92d1ad77b5501de63ac7.
In the case of VCE encoding with raw YUV file, CPU load directly to
VRAM is faster than combination of CPU writing to GTT and then blit
to VRAM with GPU.

Why was the original patch applied?  I just want to make sure it
wasn't a bug fix for avoiding a sigbus or something similar if we ran
out of cpu visible vram.

Alex


---
   src/gallium/drivers/radeon/r600_texture.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index 45a9508..3dfddca 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -928,8 +928,8 @@ static void *r600_texture_transfer_map(struct

pipe_context *ctx,

  if (rtex->surface.level[level].mode >= RADEON_SURF_MODE_1D)
  use_staging_texture = TRUE;

-   /* Untiled buffers in VRAM, which is slow for CPU reads and writes */
-   if (!(usage & PIPE_TRANSFER_MAP_DIRECTLY) &&
+   /* Untiled buffers in VRAM, which is slow for CPU reads */
+   if ((usage & PIPE_TRANSFER_READ) && !(usage &
+ PIPE_TRANSFER_MAP_DIRECTLY) &&
  (rtex->resource.domains == RADEON_DOMAIN_VRAM)) {
  use_staging_texture = TRUE;
  }
--
1.8.1.2


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

Re: [Mesa-dev] [PATCH V3 03/30] swrast: Add support for fetching from MESA_FORMAT_R10G10B10A2_UNORM

[Brian Paul]

On 04/02/2014 02:04 AM, Chris Forbes wrote:

Signed-off-by: Chris Forbes 
---
  src/mesa/swrast/s_texfetch.c |  6 +++---
  src/mesa/swrast/s_texfetch_tmp.h | 16 
  2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/mesa/swrast/s_texfetch.c b/src/mesa/swrast/s_texfetch.c
index cd09827..4084bbd 100644
--- a/src/mesa/swrast/s_texfetch.c
+++ b/src/mesa/swrast/s_texfetch.c
@@ -325,9 +325,9 @@ texfetch_funcs[] =
 },
 {
MESA_FORMAT_R10G10B10A2_UNORM,
-  NULL,
-  NULL,
-  NULL
+  fetch_texel_1d_f_rgba1010102,
+  fetch_texel_2d_f_rgba1010102,
+  fetch_texel_3d_f_rgba1010102
 },
 {
MESA_FORMAT_S8_UINT_Z24_UNORM,
diff --git a/src/mesa/swrast/s_texfetch_tmp.h b/src/mesa/swrast/s_texfetch_tmp.h
index f749b49..39e55c5 100644
--- a/src/mesa/swrast/s_texfetch_tmp.h
+++ b/src/mesa/swrast/s_texfetch_tmp.h
@@ -685,6 +685,22 @@ static void FETCH(f_argb2101010)( const struct 
swrast_texture_image *texImage,



+/* MESA_FORMAT_R10G10B10A2_UNORM 
***/
+
+/* Fetch texel from 1D, 2D or 3D argb2101010 texture, return 4 GLchans */
+static void FETCH(f_rgba1010102)( const struct swrast_texture_image *texImage,
+  GLint i, GLint j, GLint k, GLfloat *texel )
+{
+   const GLuint *src = TEXEL_ADDR(GLuint, texImage, i, j, k, 1);
+   const GLuint s = *src;
+   texel[RCOMP] = ((s >> 00) & 0x3ff) * (1.0F / 1023.0F);
+   texel[GCOMP] = ((s >> 10) & 0x3ff) * (1.0F / 1023.0F);
+   texel[BCOMP] = ((s >> 20) & 0x3ff) * (1.0F / 1023.0F);
+   texel[ACOMP] = ((s >> 30) & 0x03) * (1.0F / 3.0F);
+}
+
+
+

  /* MESA_FORMAT_R8G8_UNORM 
**/




I'd like to eventually rename all the functions in that file to be 
consistent with the format names.  So, how about renaming that function 
to "R10G10B10A2_UNORM" (dropping the "f_" too)?


Other than that,
Reviewed-by: Brian Paul 


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

Re: [Mesa-dev] [PATCH V3 02/30] mesa: fix packing of float texels to GL_SHORT/GL_BYTE

[Brian Paul]

On 04/02/2014 02:04 AM, Chris Forbes wrote:

Previously, we would unpack the texels to floats using *_TO_FLOAT_TEX,
and then pack them into the desired format using FLOAT_TO_*. Unfortunately,
this isn't quite the inverse operation, and so some texel values would
end up off-by-one.

This fixes the GL_RGB8_SNORM and GL_RGB16_SNORM subcases in piglit's
arb_texture_view-format-consistency-get test on i965. The similar 1-, 2-
and 4-component cases already worked because they took the memcpy path
rather than repacking.

Signed-off-by: Chris Forbes 
---
  src/mesa/main/pack.c | 116 +--
  1 file changed, 58 insertions(+), 58 deletions(-)



Reviewed-by: Brian Paul 

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

Re: [Mesa-dev] [PATCH V3 01/30] mesa: Prefer non-swizzled formats for most sized internalformats

[Brian Paul]

On 04/02/2014 02:04 AM, Chris Forbes wrote:

These formats can be cast to others (with different component types or
sizes) via ARB_texture_view or ARB_shader_image_load_store. We want
them to be laid out consistently so that we can just reinterpret the
memory with a different format.

In V1, this was done conditionally on a 'prefer_no_swizzle' flag which
was set in TexStorage/TextureView paths, but we need the same behavior
for ARB_shader_image_load_store (which also works with images created
via TexImage, so we don't want it to be conditional.

Signed-off-by: Chris Forbes 
---
  src/mesa/main/texformat.c | 22 ++
  1 file changed, 18 insertions(+), 4 deletions(-)



Reviewed-by: Brian Paul 

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

Re: [Mesa-dev] [PATCH 4/4] xa: reuse surfaces

[Rob Clark]

On Wed, Apr 2, 2014 at 3:47 AM, Thomas Hellstrom  wrote:
> On 04/01/2014 05:04 PM, Rob Clark wrote:
>> From: Rob Clark 
>>
>> Otherwise it will trick the gallium driver into thinking that the render
>> target has actually changed (due to different pipe_surface pointing to
>> same underlying pipe_resource).  This is really badness for tiling GPUs
>> like adreno.
>
> Rob, if we want to cache gallium surfaces like this, we need to
> condition it on the same context being used.
> We can't reuse a surface created with one context for rendering with
> another context. (I know the mesa state tracker needs to
> fix this up as well).

oh.. ugg..  do we have any cases where multiple XA contexts are used?
Or could we take the easy way out and somehow forbid that?

> While this can be done easily within XA for non-shared xa_surfaces, I
> wonder what happens in the case of
> shared xa_surfaces? More specifically, is rendering allowed to be cached
> in the gallium surface until explicitly flushed to the texture? (I'm
> unsure about gallium surface semantics here).

I'm not quite sure either.  I need to flush rendering whenever the
render target actually changes (I'm just trying to prevent flushing
when the render target doesn't change, but only the pipe_surface ptr
does).  If you are using that surface as a texture, then presumably
you needed to change the render target.

I'm less sure about other drivers.

I suppose a different approach would simply be to cache the most
recent pipe_surface.  So whenever the render target does actually
change, we create a new pipe_surface.  But we avoid creating a new
surface for the same render target when it doesn't change.

BR,
-R

> /Thomas
>
>> Signed-off-by: Rob Clark 
>> ---
>>  src/gallium/state_trackers/xa/xa_context.c | 35 
>> +++---
>>  src/gallium/state_trackers/xa/xa_priv.h|  3 ++-
>>  src/gallium/state_trackers/xa/xa_tracker.c |  1 +
>>  3 files changed, 30 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/xa/xa_context.c 
>> b/src/gallium/state_trackers/xa/xa_context.c
>> index 867999a..18f0b85 100644
>> --- a/src/gallium/state_trackers/xa/xa_context.c
>> +++ b/src/gallium/state_trackers/xa/xa_context.c
>> @@ -179,6 +179,25 @@ xa_surface_unmap(struct xa_surface *srf)
>>  }
>>  }
>>
>> +static int
>> +xa_srf_create(struct xa_context *ctx, struct xa_surface *srf)
>> +{
>> +struct pipe_screen *screen = ctx->pipe->screen;
>> +struct pipe_surface srf_templ;
>> +
>> +if (!screen->is_format_supported(screen,  srf->tex->format,
>> +  PIPE_TEXTURE_2D, 0,
>> +  PIPE_BIND_RENDER_TARGET))
>> + return -XA_ERR_INVAL;
>> +
>> +u_surface_default_template(&srf_templ, srf->tex);
>> +srf->srf = ctx->pipe->create_surface(ctx->pipe, srf->tex, &srf_templ);
>> +if (!srf->srf)
>> + return -XA_ERR_NORES;
>> +
>> +return XA_ERR_NONE;
>> +}
>> +
>>  int
>>  xa_ctx_srf_create(struct xa_context *ctx, struct xa_surface *dst)
>>  {
>> @@ -188,15 +207,15 @@ xa_ctx_srf_create(struct xa_context *ctx, struct 
>> xa_surface *dst)
>>  if (ctx->srf)
>>   return -XA_ERR_INVAL;
>>
>> -if (!screen->is_format_supported(screen,  dst->tex->format,
>> -  PIPE_TEXTURE_2D, 0,
>> -  PIPE_BIND_RENDER_TARGET))
>> - return -XA_ERR_INVAL;
>> +if (!dst->srf) {
>> + int ret = xa_srf_create(ctx, dst);
>> + if (ret != XA_ERR_NONE)
>> + return ret;
>> +}
>>
>> -u_surface_default_template(&srf_templ, dst->tex);
>> -ctx->srf = ctx->pipe->create_surface(ctx->pipe, dst->tex, &srf_templ);
>> -if (!ctx->srf)
>> - return -XA_ERR_NORES;
>> +assert(dst->srf);
>> +
>> +pipe_surface_reference(&ctx->srf, dst->srf);
>>
>>  return XA_ERR_NONE;
>>  }
>> diff --git a/src/gallium/state_trackers/xa/xa_priv.h 
>> b/src/gallium/state_trackers/xa/xa_priv.h
>> index 7a43386..5ade6c1 100644
>> --- a/src/gallium/state_trackers/xa/xa_priv.h
>> +++ b/src/gallium/state_trackers/xa/xa_priv.h
>> @@ -46,7 +46,7 @@
>>  #define XA_EXPORT
>>  #endif
>>
>> -#define XA_VB_SIZE (100 * 4 * 3 * 4)
>> +#define XA_VB_SIZE (170 * 4 * 3 * 4)
>>  #define XA_LAST_SURFACE_TYPE (xa_type_yuv_component + 1)
>>  #define XA_MAX_SAMPLERS 3
>>
>> @@ -65,6 +65,7 @@ struct xa_surface {
>>  struct pipe_resource template;
>>  struct xa_tracker *xa;
>>  struct pipe_resource *tex;
>> +struct pipe_surface *srf;
>>  struct pipe_transfer *transfer;
>>  unsigned int flags;
>>  struct xa_format_descriptor fdesc;
>> diff --git a/src/gallium/state_trackers/xa/xa_tracker.c 
>> b/src/gallium/state_trackers/xa/xa_tracker.c
>> index 9add584..7fed20a 100644
>> --- a/src/gallium/state_trackers/xa/xa_tracker.c
>> +++ b/src/gallium/state_trackers/xa/xa_tracker.c
>> @@ -474,6 +474,7 @@ xa_surface_unref(struct xa_surface *srf)
>>  if (srf == NULL || --srf->refcount) {
>>   return;

Re: [Mesa-dev] [PATCH] winsys/svga: Replace the query mm buffer pool with a slab pool v3

[Brian Paul]

On 04/01/2014 11:50 PM, Thomas Hellstrom wrote:

This is to avoid running out of query buffer space due to winsys
limitations. Instead of a fixed size per screen pool of query buffers,
use a slab allocator that allocates a new slab if we run out of space
in the first one.

v2: Correct email addresses.
v3: s/8192/VMW_QUERY_POOL_SIZE/. Improve documentation and log message.

Reported-and-tested-by: Brian Paul 
Signed-off-by: Thomas Hellstrom 
Cc: "10.1" 
---
  src/gallium/winsys/svga/drm/vmw_screen_pools.c |   18 +-
  1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/src/gallium/winsys/svga/drm/vmw_screen_pools.c 
b/src/gallium/winsys/svga/drm/vmw_screen_pools.c
index c97b71f..50d2a81 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_pools.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_pools.c
@@ -76,15 +76,23 @@ vmw_pools_cleanup(struct vmw_winsys_screen *vws)
   *
   * Typically this pool should be created on demand when we
   * detect that the app will be using queries. There's nothing
- * special with this pool other than the backing kernel buffer size,
- * which is limited to 8192.
+ * special with this pool other than the backing kernel buffer sizes,
+ * which are limited to 8192.
+ * If there is a performance issue with allocation and freeing of the
+ * query slabs, it should be easily fixable by allocating them out
+ * of a buffer cache.
   */
  boolean
  vmw_query_pools_init(struct vmw_winsys_screen *vws)
  {
-   vws->pools.query_mm = mm_bufmgr_create(vws->pools.gmr,
- VMW_QUERY_POOL_SIZE,
- 3 /* 8 alignment */);
+   struct pb_desc desc;
+
+   desc.alignment = 16;
+   desc.usage = ~(VMW_BUFFER_USAGE_SHARED | VMW_BUFFER_USAGE_SYNC);
+
+   vws->pools.query_mm = pb_slab_range_manager_create(vws->pools.gmr, 16, 128,
+  VMW_QUERY_POOL_SIZE,
+  &desc);
 if (!vws->pools.query_mm)
return FALSE;




Reviewed-by: Brian Paul 

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

Re: [Mesa-dev] Guidance in dwelling in the world of GPU driver development.

[Rob Clark]

On Wed, Apr 2, 2014 at 9:15 AM, Leander Bessa Beernaert
 wrote:
> Thanks!
>
> Not sure yet what I'll be working on yet, but I'll be sure to look into
> nouveau.
>
> Would it be possible for me to go about and work on OpenGL features which
> are beyond the capabilities of my GPU?

short answer, "it depends"..

in some cases you might be able to emulate one feature with another,
emulate it in the shader, etc.  I emulate GL_QUADS support on gles hw
with a driver generated index buffer, for example.  Or, at least a
couple drivers generate shader code to emulate two-sided-color.  But
in a lot of cases there might not be a reasonable way to emulate some
feature.

Btw, if you haven't seen it already:

  http://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf

not complete, but still a pretty useful newbie intro to the linux
graphics stack.  And:

  http://gallium.readthedocs.org/en/latest/

up to date gallium docs (if you prefer the generated html vs reading
the .rst files in src/gallium/docs ;-))

BR,
-R

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

Re: [Mesa-dev] [PATCH V2] i965/vec4: do not trim dead channels on gen6 for math

[Matt Turner]

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

Re: [Mesa-dev] DaibloIII: radeon: mmap failed, errno: 12

[Sven Arvidsson]

On Tue, 2014-04-01 at 17:30 -0500, Mike Mestnik wrote:
> http://bitly.com/1ibsC0y
> 
> What debugging steps are next?
> There is no BT because the application exits cleanly.

Hi,

You should file a bug against Mesa, possibly with Wine too:
https://bugs.freedesktop.org/
http://bugs.winehq.org/

Mention versions of Wine, Mesa, etc. You could also try and check if
this is a new bug or present in older versions of Mesa/Wine. If it's new
it can be bisected.

The shader errors look like a clue though:

EE ../../../../../../src/gallium/drivers/r600/r600_shader.c:1580 
r600_shader_from_tgsi - GPR limit exceeded - shader requires 230 registers
EE ../../../../../../src/gallium/drivers/r600/r600_shader.c:158 
r600_pipe_shader_create - translation from TGSI failed !
EE ../../../../../../src/gallium/drivers/r600/r600_state_common.c:754 
r600_shader_select - Failed to build shader variant (type=1) -12

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22



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

[Mesa-dev] [PATCH] cso: fix sampler view count in cso_set_sampler_views()

[Brian Paul]

We want to call pipe->set_sampler_views() with count being the
maximum of the old number of sampler views and the new number.
This makes sure we null-out any old sampler views.

We already do the same thing for sampler states in single_sampler_done().
Fixes some assertions seen in the VMware driver with XA tracker.

Cc: "10.0" "10.1" 
Reviewed-by: Thomas Hellstrom 
Tested-by: Thomas Hellstrom 
---
 src/gallium/auxiliary/cso_cache/cso_context.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 9146684..dda3c20 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -1187,11 +1187,12 @@ cso_set_sampler_views(struct cso_context *ctx,
   pipe_sampler_view_reference(&info->views[i], NULL);
}
 
-   info->nr_views = count;
-
/* bind the new sampler views */
-   ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0, count,
+   ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0,
+MAX2(info->nr_views, count),
 info->views);
+
+   info->nr_views = count;
 }
 
 
-- 
1.7.10.4

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

Re: [Mesa-dev] [PATCH] mesa: fix check for dummy renderbuffer in _mesa_FramebufferRenderbufferEXT()

[Anuj Phogat]

On Tue, Apr 1, 2014 at 2:37 AM, Samuel Iglesias Gonsalvez
 wrote:
> According to the spec:
>  must be RENDERBUFFER and 
> should be set to the name of the renderbuffer object to be
> attached to the framebuffer.   must be either
> zero or the name of an existing renderbuffer object of type
> , otherwise an INVALID_OPERATION error is
> generated.
>
> This patch changes the previous returned GL_INVALID_VALUE to
> GL_INVALID_OPERATION.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76894
>
> Signed-off-by: Samuel Iglesias Gonsalvez 
I think it should be marked for stable branches using:
Cc: mesa-sta...@lists.freedesktop.org

> ---
>  src/mesa/main/fbobject.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 6c4f1b5..7669a0c 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -2676,8 +2676,7 @@ _mesa_FramebufferRenderbuffer(GLenum target, GLenum 
> attachment,
>  return;
>}
>else if (rb == &DummyRenderbuffer) {
> - /* This is what NVIDIA does */
> -_mesa_error(ctx, GL_INVALID_VALUE,
> +_mesa_error(ctx, GL_INVALID_OPERATION,
>  "glFramebufferRenderbufferEXT(renderbuffer %u)",
>   renderbuffer);
>  return;
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

Re: [Mesa-dev] [PATCH] automake: don't enable -Wl, --no-undefined on OpenBSD

[Emil Velikov]

On 02/04/14 04:55, Jonathan Gray wrote:
> OpenBSD does not have DT_NEEDED entries for libc by design,
> over concerns how the symbols would be referenced after
> changing the major version of the library.
> 
> So avoid -no-undefined checks on OpenBSD as they will fail.
> 
If I understood things correctly only -Wl,--no-undefined needs to be altered,
although I have no objections either way with your current approach.

Can you please update src/gallium/Automake.inc as well ? With that fixed, the
patch is

Reviewed-by: Emil Velikov 

Thanks
Emil

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76856
> Signed-off-by: Jonathan Gray 
> ---
>  configure.ac| 13 +
>  src/egl/main/Makefile.am|  3 +--
>  src/egl/wayland/wayland-egl/Makefile.am |  3 +--
>  src/gallium/targets/egl-static/Makefile.am  |  3 +--
>  src/gallium/targets/gbm/Makefile.am |  3 +--
>  src/gallium/targets/libgl-xlib/Makefile.am  |  3 +--
>  src/gallium/targets/opencl/Makefile.am  |  3 +--
>  src/gallium/targets/osmesa/Makefile.am  |  3 +--
>  src/gallium/targets/pipe-loader/Makefile.am |  3 +--
>  src/gallium/targets/xa/Makefile.am  |  3 +--
>  src/gbm/Makefile.am |  3 +--
>  src/glx/Makefile.am |  3 +--
>  src/mapi/es1api/Makefile.am |  3 +--
>  src/mapi/es2api/Makefile.am |  3 +--
>  src/mapi/shared-glapi/Makefile.am   |  3 +--
>  src/mapi/vgapi/Makefile.am  |  3 +--
>  src/mesa/drivers/osmesa/Makefile.am |  3 +--
>  src/mesa/drivers/x11/Makefile.am|  3 +--
>  18 files changed, 30 insertions(+), 34 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 187006a..c1ce3e9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -332,6 +332,19 @@ LDFLAGS=$save_LDFLAGS
>  AC_SUBST([GC_SECTIONS])
>  
>  dnl
> +dnl OpenBSD does not have DT_NEEDED entries for libc by design
> +dnl so these checks will fail
> +dnl
> +case "$host_os" in
> +openbsd*)
> +LD_NO_UNDEFINED="" ;;
> +*)
> +LD_NO_UNDEFINED="-no-undefined -Wl,--no-undefined" ;;
> +esac
> +
> +AC_SUBST([LD_NO_UNDEFINED])
> +
> +dnl
>  dnl compatibility symlinks
>  dnl
>  case "$host_os" in
> diff --git a/src/egl/main/Makefile.am b/src/egl/main/Makefile.am
> index e4c2539..d7d2581 100644
> --- a/src/egl/main/Makefile.am
> +++ b/src/egl/main/Makefile.am
> @@ -74,11 +74,10 @@ libEGL_la_SOURCES = \
>  libEGL_la_LIBADD = \
>   $(EGL_LIB_DEPS)
>  libEGL_la_LDFLAGS = \
> - -no-undefined \
>   -version-number 1:0 \
>   -Wl,-Bsymbolic \
>   $(GC_SECTIONS) \
> - -Wl,--no-undefined
> + $(LD_NO_UNDEFINED)
>  
>  if HAVE_EGL_PLATFORM_X11
>  AM_CFLAGS += -DHAVE_X11_PLATFORM
> diff --git a/src/egl/wayland/wayland-egl/Makefile.am 
> b/src/egl/wayland/wayland-egl/Makefile.am
> index d3fe117..9a12448 100644
> --- a/src/egl/wayland/wayland-egl/Makefile.am
> +++ b/src/egl/wayland/wayland-egl/Makefile.am
> @@ -9,10 +9,9 @@ lib_LTLIBRARIES = libwayland-egl.la
>  noinst_HEADERS = wayland-egl-priv.h
>  libwayland_egl_la_SOURCES = wayland-egl.c
>  libwayland_egl_la_LDFLAGS = \
> - -no-undefined \
>   -version-info 1 \
>   $(GC_SECTIONS) \
> - -Wl,--no-undefined
> + $(LD_NO_UNDEFINED)
>  
>  TESTS = wayland-egl-symbols-check
>  
> diff --git a/src/gallium/targets/egl-static/Makefile.am 
> b/src/gallium/targets/egl-static/Makefile.am
> index 58ecf69..fb2b4a8 100644
> --- a/src/gallium/targets/egl-static/Makefile.am
> +++ b/src/gallium/targets/egl-static/Makefile.am
> @@ -46,10 +46,9 @@ AM_CPPFLAGS = \
>  
>  AM_LDFLAGS = \
>   -module \
> - -no-undefined \
>   -avoid-version \
>   $(GC_SECTIONS) \
> - -Wl,--no-undefined \
> + $(LD_NO_UNDEFINED) \
>   
> -Wl,--version-script=$(top_srcdir)/src/gallium/targets/egl-static/egl.link
>  
>  egldir = $(EGL_DRIVER_INSTALL_DIR)
> diff --git a/src/gallium/targets/gbm/Makefile.am 
> b/src/gallium/targets/gbm/Makefile.am
> index 22b4826..956802a 100644
> --- a/src/gallium/targets/gbm/Makefile.am
> +++ b/src/gallium/targets/gbm/Makefile.am
> @@ -68,10 +68,9 @@ endif
>  
>  gbm_gallium_drm_la_LDFLAGS = \
>   -module \
> - -no-undefined \
>   -avoid-version \
>   $(GC_SECTIONS) \
> - -Wl,--no-undefined
> + $(LD_NO_UNDEFINED)
>  
>  if HAVE_MESA_LLVM
>  gbm_gallium_drm_la_LIBADD += $(LLVM_LIBS)
> diff --git a/src/gallium/targets/libgl-xlib/Makefile.am 
> b/src/gallium/targets/libgl-xlib/Makefile.am
> index ef3d23e..a45fc7b 100644
> --- a/src/gallium/targets/libgl-xlib/Makefile.am
> +++ b/src/gallium/targets/libgl-xlib/Makefile.am
> @@ -45,10 +45,9 @@ lib_LTLIBRARIES = libGL.la
>  nodist_EXTRA_libGL_la_SOURCES = dummy.cpp
>  libGL_la_SOURCES = xlib.c
>  libGL_la_LDFLAGS = \
> - -no-undefined \
>   -version-number $(GL_MAJOR):$(GL_MINOR):$(GL_TINY) \
>   $(GC_SECTIONS) \
> - -Wl,--no-undefined
> + $(LD_NO_UNDEFINED)
>  
>  libGL_la_LIBA

Re: [Mesa-dev] [PATCH] cso: fix sampler view count in cso_set_sampler_views()

[Roland Scheidegger]

Am 02.04.2014 18:34, schrieb Brian Paul:
> We want to call pipe->set_sampler_views() with count being the
> maximum of the old number of sampler views and the new number.
> This makes sure we null-out any old sampler views.
> 
> We already do the same thing for sampler states in single_sampler_done().
> Fixes some assertions seen in the VMware driver with XA tracker.
> 
> Cc: "10.0" "10.1" 
> Reviewed-by: Thomas Hellstrom 
> Tested-by: Thomas Hellstrom 
> ---
>  src/gallium/auxiliary/cso_cache/cso_context.c |7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
> b/src/gallium/auxiliary/cso_cache/cso_context.c
> index 9146684..dda3c20 100644
> --- a/src/gallium/auxiliary/cso_cache/cso_context.c
> +++ b/src/gallium/auxiliary/cso_cache/cso_context.c
> @@ -1187,11 +1187,12 @@ cso_set_sampler_views(struct cso_context *ctx,
>pipe_sampler_view_reference(&info->views[i], NULL);
> }
>  
> -   info->nr_views = count;
> -
> /* bind the new sampler views */
> -   ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0, count,
> +   ctx->pipe->set_sampler_views(ctx->pipe, shader_stage, 0,
> +MAX2(info->nr_views, count),
>  info->views);
> +
> +   info->nr_views = count;
>  }
>  
>  
> 

Looks good to me.

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

Re: [Mesa-dev] [PATCH 4/4] xa: reuse surfaces

[Thomas Hellstrom]

On 04/02/2014 04:40 PM, Rob Clark wrote:
> On Wed, Apr 2, 2014 at 3:47 AM, Thomas Hellstrom  
> wrote:
>> On 04/01/2014 05:04 PM, Rob Clark wrote:
>>> From: Rob Clark 
>>>
>>> Otherwise it will trick the gallium driver into thinking that the render
>>> target has actually changed (due to different pipe_surface pointing to
>>> same underlying pipe_resource).  This is really badness for tiling GPUs
>>> like adreno.
>> Rob, if we want to cache gallium surfaces like this, we need to
>> condition it on the same context being used.
>> We can't reuse a surface created with one context for rendering with
>> another context. (I know the mesa state tracker needs to
>> fix this up as well).
> oh.. ugg..  do we have any cases where multiple XA contexts are used?
> Or could we take the easy way out and somehow forbid that?

Hmm. It was designed around the idea of multiple XA contexts so if at
all possible I think we should
continue to allow that..

>
>> While this can be done easily within XA for non-shared xa_surfaces, I
>> wonder what happens in the case of
>> shared xa_surfaces? More specifically, is rendering allowed to be cached
>> in the gallium surface until explicitly flushed to the texture? (I'm
>> unsure about gallium surface semantics here).
> I'm not quite sure either.  I need to flush rendering whenever the
> render target actually changes (I'm just trying to prevent flushing
> when the render target doesn't change, but only the pipe_surface ptr
> does).  If you are using that surface as a texture, then presumably
> you needed to change the render target.
>
> I'm less sure about other drivers.
>
> I suppose a different approach would simply be to cache the most
> recent pipe_surface.  So whenever the render target does actually
> change, we create a new pipe_surface.  But we avoid creating a new
> surface for the same render target when it doesn't change.
>
> BR,
> -R
>
>

Something along the line of the attached patch? That would keep a
reference on the destination surface until context destruction, but I
guess the driver would do that anyway, since it's a render target...

/Thomas




>From 26cb8fc9b19c023b5666d1c105888263b0b14d23 Mon Sep 17 00:00:00 2001
From: Thomas Hellstrom 
Date: Wed, 2 Apr 2014 19:50:09 +0200
Subject: [PATCH 4/4] st/xa: Cache render target surface

Otherwise it will trick the gallium driver into thinking that the render
target has actually changed (due to different pipe_surface pointing to
same underlying pipe_resource).  This is really badness for tiling GPUs
like adreno.

Signed-off-by: Thomas Hellstrom 
---
 src/gallium/state_trackers/xa/xa_context.c |   18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/xa/xa_context.c b/src/gallium/state_trackers/xa/xa_context.c
index 867999a..37de45b 100644
--- a/src/gallium/state_trackers/xa/xa_context.c
+++ b/src/gallium/state_trackers/xa/xa_context.c
@@ -78,6 +78,8 @@ xa_context_destroy(struct xa_context *r)
 }
 
 xa_ctx_sampler_views_destroy(r);
+if (r->srf)
+pipe_surface_reference(&r->srf, NULL);
 
 if (r->cso) {
 	cso_release_all(r->cso);
@@ -185,8 +187,15 @@ xa_ctx_srf_create(struct xa_context *ctx, struct xa_surface *dst)
 struct pipe_screen *screen = ctx->pipe->screen;
 struct pipe_surface srf_templ;
 
-if (ctx->srf)
-	return -XA_ERR_INVAL;
+/*
+ * Cache surfaces unless we change render target
+ */
+if (ctx->srf) {
+if (ctx->srf->texture == dst->tex)
+return XA_ERR_NONE;
+
+pipe_surface_reference(&ctx->srf, NULL);
+}
 
 if (!screen->is_format_supported(screen,  dst->tex->format,
  PIPE_TEXTURE_2D, 0,
@@ -204,7 +213,10 @@ xa_ctx_srf_create(struct xa_context *ctx, struct xa_surface *dst)
 void
 xa_ctx_srf_destroy(struct xa_context *ctx)
 {
-pipe_surface_reference(&ctx->srf, NULL);
+/*
+ * Cache surfaces unless we change render target.
+ * Final destruction on context destroy.
+ */
 }
 
 XA_EXPORT int
-- 
1.7.10.4

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

Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds

[Ian Romanick]

On 04/01/2014 02:25 PM, Timothy Arceri wrote:
> Thanks Ian,
> 
> Reviewed-by: Timothy Arceri 
> 
> I wasn't aware of this test. I guess the other KHR_debug functions
> should be added here also? If so I can create a patch for this later
> today unless you just want to do it.

Some of the tests in src/mapi/glapi/tests are only run in some
configurations.  I believe this test is only run in the non-shared-glapi
configuration.  I encountered some problem making it work on both shared
and non-shared, but I don't recall the exact details.  I only noticed it
was broken because I was fixing another issue with the non-shared
configuration.

> When I get some time I might also add another dot point to the 'Adding
> Extensions' heading in the developer notes about updating
> dispatch_sanity and check_table. Just for clarity is my understanding of
> the difference between the check table and the dispatch sanity test
> correct? 
> check table test - makes sure an extension that is expected to be
> available is actually available?
> dispatch sanity - only extensions that a expected be available are
> available (nothing extra)?
> 
> Tim
> 
> 
> On Tue, 2014-04-01 at 13:15 -0700, Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> Commit fb78fa58 made the GL_ARB_debug_output functions aliases of the
>> GL_KHR_debug output functions.  As a result, the function names in
>> struct _glapi_table also changed.  The table in check_table.cpp used the
>> ARB names.
>>
>> Signed-off-by: Ian Romanick 
>> Cc: Vinson Lee 
>> Cc: Timothy Arceri 
>> ---
>>  src/mapi/glapi/tests/check_table.cpp | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/mapi/glapi/tests/check_table.cpp 
>> b/src/mapi/glapi/tests/check_table.cpp
>> index 375645b..89d9073 100644
>> --- a/src/mapi/glapi/tests/check_table.cpp
>> +++ b/src/mapi/glapi/tests/check_table.cpp
>> @@ -1227,10 +1227,10 @@ const struct name_offset known_dispatch[] = {
>> { "glGetShaderPrecisionFormat", _O(GetShaderPrecisionFormat) },
>> { "glReleaseShaderCompiler", _O(ReleaseShaderCompiler) },
>> { "glShaderBinary", _O(ShaderBinary) },
>> -   { "glDebugMessageCallbackARB", _O(DebugMessageCallbackARB) },
>> -   { "glDebugMessageControlARB", _O(DebugMessageControlARB) },
>> -   { "glDebugMessageInsertARB", _O(DebugMessageInsertARB) },
>> -   { "glGetDebugMessageLogARB", _O(GetDebugMessageLogARB) },
>> +   { "glDebugMessageCallback", _O(DebugMessageCallback) },
>> +   { "glDebugMessageControl", _O(DebugMessageControl) },
>> +   { "glDebugMessageInsert", _O(DebugMessageInsert) },
>> +   { "glGetDebugMessageLog", _O(GetDebugMessageLog) },
>> { "glGetGraphicsResetStatusARB", _O(GetGraphicsResetStatusARB) },
>> { "glGetnColorTableARB", _O(GetnColorTableARB) },
>> { "glGetnCompressedTexImageARB", _O(GetnCompressedTexImageARB) },
> 

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

Re: [Mesa-dev] [PATCH 4/4] xa: reuse surfaces

[Rob Clark]

On Wed, Apr 2, 2014 at 2:05 PM, Thomas Hellstrom  wrote:
> On 04/02/2014 04:40 PM, Rob Clark wrote:
>> On Wed, Apr 2, 2014 at 3:47 AM, Thomas Hellstrom  
>> wrote:
>>> On 04/01/2014 05:04 PM, Rob Clark wrote:
 From: Rob Clark 

 Otherwise it will trick the gallium driver into thinking that the render
 target has actually changed (due to different pipe_surface pointing to
 same underlying pipe_resource).  This is really badness for tiling GPUs
 like adreno.
>>> Rob, if we want to cache gallium surfaces like this, we need to
>>> condition it on the same context being used.
>>> We can't reuse a surface created with one context for rendering with
>>> another context. (I know the mesa state tracker needs to
>>> fix this up as well).
>> oh.. ugg..  do we have any cases where multiple XA contexts are used?
>> Or could we take the easy way out and somehow forbid that?
>
> Hmm. It was designed around the idea of multiple XA contexts so if at
> all possible I think we should
> continue to allow that..
>
>>
>>> While this can be done easily within XA for non-shared xa_surfaces, I
>>> wonder what happens in the case of
>>> shared xa_surfaces? More specifically, is rendering allowed to be cached
>>> in the gallium surface until explicitly flushed to the texture? (I'm
>>> unsure about gallium surface semantics here).
>> I'm not quite sure either.  I need to flush rendering whenever the
>> render target actually changes (I'm just trying to prevent flushing
>> when the render target doesn't change, but only the pipe_surface ptr
>> does).  If you are using that surface as a texture, then presumably
>> you needed to change the render target.
>>
>> I'm less sure about other drivers.
>>
>> I suppose a different approach would simply be to cache the most
>> recent pipe_surface.  So whenever the render target does actually
>> change, we create a new pipe_surface.  But we avoid creating a new
>> surface for the same render target when it doesn't change.
>>
>> BR,
>> -R
>>
>>
>
> Something along the line of the attached patch? That would keep a
> reference on the destination surface until context destruction, but I
> guess the driver would do that anyway, since it's a render target...

yup, that looks like it should do the trick.. I'll give it a try shortly..

BR,
-R

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

Re: [Mesa-dev] [PATCH 2/4] loader: don't limit the non-udev path to only android

[Emil Velikov]

On 22/03/14 00:10, Emil Velikov wrote:
> On 19/03/14 01:06, Jonathan Gray wrote:
>> On Tue, Mar 18, 2014 at 07:56:21PM +, Emil Velikov wrote:
>>> On 18/03/14 14:59, Jonathan Gray wrote:
 Signed-off-by: Jonathan Gray 
 ---
>>> Hi Jonathan
>>>
>>> While the summary covers what the patch does, the *ahem* commit message
>>> fails to explain why it's needed. AFAICS this will cause some very nasty
>>> breakage in some cases, which we want to avoid without a valid reason.
>>>
>>> -Emil
>>
>> The summary is the commit message though?
>>
>> Anyway without this I can't load dri drivers at all on OpenBSD
>> with mesa 10.x.  FreeBSD/NetBSD/Solaris/etc would also be broken
>> which strikes me as rather serious breakage...
>>
> Kind of expecting to see a fraction of the above in the commit message,
> maybe I was expecting too much.
> 
> Wrt "will cause some very nasty breakage" I take that back, as I've
> missed the commit that enforces libudev on linux, which handles those
> lovely scenarios.
> 
> FWIW For patches 1, 2 and 4.
> Reviewed-by: Emil Velikov 
> 
> Btw, if you're looking for egl, wayland, opencl etc. similar fixes to
> patch 3 may be needed.
> 
> Will slap Cc: mesa-stable on all three commits + the fix for fdo#76377,
> before pushing to master, although I would prefer to wait for a few days
> in case other people are interested in reviewing/testing.
> 
Planning to commit patches 1, 2 and 4 over the weekend. So if anyone has
strong feelings about them please speak up.

Cheers
-Emil

> Cheers
> -Emil
> 
>> udev is only available on Linux so every other platform
>> that uses dri is currently broken.
>>
> 

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

Re: [Mesa-dev] [PATCH 0/6] Some glapi clean-up releated to GLES

[Ian Romanick]

On 04/02/2014 05:21 AM, Jose Fonseca wrote:
> - Original Message -
>> Tomorrow or Friday I'm going to send out the last of the
>> GL_ARB_separate_shader_objects patches.  Shortly after that, I will send
>> out patches to enable GL_EXT_separate_shader_objects on GLES.  This EXT
>> is the GLES subset of the ARB extension.
>>
>> In preparing for this new extension, I noticed the old problem that any
>> extension function that aliases a core function (whether it is core in
>> GLES or desktop GL) isn't hidden.  This series should fix that.
>>
>> Longer term, I'd like to change the generation of libGL*.  Right now all
>> the information describing the interfaces and the information selecting
>> the exposed interfaces in combined in a single XML database.  As patch 4
>> shows, that makes it impossible to have a single function that is
>> exposed in one API but hidden in another.  I'd like to pull all the
>> "offset", "static_dispatch", "glx_ignore", and "exec" information out
>> into separate files.
>>
>> This will mean that adding a new extension will require changes to
>> multiple files.  The usual XML bits will need to be added.  Entries will
>> need to be add to per-libGL* files, an "exec" file, and an "offsets".
>> We can probably get rid of the offsets file since no functions will ever
>> be added that have static offsets.
> 
> ABI details like symbol visibility can vary not only per API but also per 
> platform, so having these ABI details seperate from the prototypes (which are 
> cross-platform and cross-API) sounds a good idea to me.
> 
> On the topic of glapi cleanup, I noticed that a lot of glapi code
> ends up mixing scripted C code generation with C pre-processor
> macros. I'm sure there are historic reasons for it but this
> combination obfuscates the code. It would be better to use only one
> of the techniques; or more realistically, drop the macros and rely on
> code generation exclusively.  It would be much easier for humans to
> reason about the generated code then.

I agree.  I hate all the C pre-processor madness.  We used to commit the
generated files to CVS, so the generated file had to work in all
configurations.  Now that the files are gererated during the build, that
should be tractible.

Dylan Baker suggested to me that we use Mako (Python template library
used in piglit) to help clean up the code generators.  This also seems
like a good idea.  Would adding a Mako dependency in Mesa be okay?

> Jose

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

[Mesa-dev] [Bug 76960] New: NameError: name 'src' is not defined

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 76960
  Keywords: regression
CC: bri...@vmware.com, huax...@intel.com,
i...@freedesktop.org
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: NameError: name 'src' is not defined
  Severity: blocker
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: 5a68f731029258ddede4bd5d578cee203f4a80b3 (master 10.2.0-devel)

$ scons
[...]
  Generating build/linux-x86_64-debug/mapi/glapi/glprocs.h ...
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'src' is not defined

cecffa08d191615b59751dc84fe33d051e4a4b67 is the first bad commit
commit cecffa08d191615b59751dc84fe33d051e4a4b67
Author: Ian Romanick 
Date:   Tue Apr 1 13:04:17 2014 -0700

glapi: Enable ES compatibility mode

Ages ago Chia-I added an ES compatibility flag to several of the various
generator scripts.  The intention was to bridge differences between ES
and desktop in Mesa builds without ES.  It doesn't appear that it has
ever been used.  Recent changes to static_dispatch status of several ES1
functions caused problems in desktop-only, non-shared-glapi builds.
Enabling the ES compatibility mode appears to fix these build problems.

This is kind of a duct tape solution to this problem.  As I mentioned in
the cover letter for the series that triggered the build problem, I
would like to make some major changes to the generator architecture and
the XML.  The whole point of the proposed architecture changes is to
better handle the differences between desktop GL and ES.  I think duct
tape is okay for now.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76869
Tested-by: Brian Paul 
Tested-by: Lu Hua 
Cc: Vinson Lee 
Cc: Chia-I Wu 

:04 04 49d832f3a17a5e1df34ebc1fcfa1604456a66f03
e1f9b761ab1c0183699f261e7830e3dcd1a5bf2a Msrc
bisect run success

-- 
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 4/4] xa: reuse surfaces

[Rob Clark]

On Wed, Apr 2, 2014 at 2:05 PM, Thomas Hellstrom  wrote:
> On 04/02/2014 04:40 PM, Rob Clark wrote:
>> On Wed, Apr 2, 2014 at 3:47 AM, Thomas Hellstrom  
>> wrote:
>>> On 04/01/2014 05:04 PM, Rob Clark wrote:
 From: Rob Clark 

 Otherwise it will trick the gallium driver into thinking that the render
 target has actually changed (due to different pipe_surface pointing to
 same underlying pipe_resource).  This is really badness for tiling GPUs
 like adreno.
>>> Rob, if we want to cache gallium surfaces like this, we need to
>>> condition it on the same context being used.
>>> We can't reuse a surface created with one context for rendering with
>>> another context. (I know the mesa state tracker needs to
>>> fix this up as well).
>> oh.. ugg..  do we have any cases where multiple XA contexts are used?
>> Or could we take the easy way out and somehow forbid that?
>
> Hmm. It was designed around the idea of multiple XA contexts so if at
> all possible I think we should
> continue to allow that..
>
>>
>>> While this can be done easily within XA for non-shared xa_surfaces, I
>>> wonder what happens in the case of
>>> shared xa_surfaces? More specifically, is rendering allowed to be cached
>>> in the gallium surface until explicitly flushed to the texture? (I'm
>>> unsure about gallium surface semantics here).
>> I'm not quite sure either.  I need to flush rendering whenever the
>> render target actually changes (I'm just trying to prevent flushing
>> when the render target doesn't change, but only the pipe_surface ptr
>> does).  If you are using that surface as a texture, then presumably
>> you needed to change the render target.
>>
>> I'm less sure about other drivers.
>>
>> I suppose a different approach would simply be to cache the most
>> recent pipe_surface.  So whenever the render target does actually
>> change, we create a new pipe_surface.  But we avoid creating a new
>> surface for the same render target when it doesn't change.
>>
>> BR,
>> -R
>>
>>
>
> Something along the line of the attached patch? That would keep a
> reference on the destination surface until context destruction, but I
> guess the driver would do that anyway, since it's a render target...

Seems to do the job.. I got one segfault in my emit_textures() code
(which I've not managed to reproduce yet).. but I guess that is
unrelated, the refcnt'ing in this patch looks correct.

BR,
-R


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

[Mesa-dev] [Bug 76960] NameError: name 'src' is not defined

[bugzilla-daemon]

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

Ian Romanick  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #1 from Ian Romanick  ---
Ugh... I CC'ed Vinson on that patch in hopes that he would test it before it
landed.

Are you able to reproduce this without scons?  Can you give me instructions?

-- 
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

[Mesa-dev] [Bug 76960] NameError: name 'src' is not defined

[bugzilla-daemon]

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

--- Comment #2 from Vinson Lee  ---
$ /usr/bin/python -c src/mapi/glapi/gen/gl_procs.py -f
src/mapi/glapi/gen/gl_and_es_API.xml
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'src' is not defined

-- 
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

[Mesa-dev] [Bug 76960] NameError: name 'src' is not defined

[bugzilla-daemon]

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

--- Comment #3 from Brian Paul  ---
Looks like this fixes it for me:

diff --git a/src/mapi/glapi/gen/SConscript b/src/mapi/glapi/gen/SConscript
index 4d827b0..e4abe90 100644
--- a/src/mapi/glapi/gen/SConscript
+++ b/src/mapi/glapi/gen/SConscript
@@ -38,7 +38,7 @@ env.CodeGenerate(
 target = '../../../mapi/glapi/glprocs.h',
 script = 'gl_procs.py',
 source = sources,
-command = python_cmd + ' -c $SCRIPT -f $SOURCE > $TARGET'
+command = python_cmd + ' $SCRIPT -f $SOURCE > $TARGET'
 )


None of the other env.CodeGenerate() calls in that file use the -c option.

PS: I didn't test the Linux scons build yesterday.

-- 
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 0/6] Some glapi clean-up releated to GLES

[Ian Romanick]

On 03/31/2014 02:48 PM, Ian Romanick wrote:
> On 03/27/2014 04:10 PM, Eric Anholt wrote:
>> Ian Romanick  writes:
>>
>>> Tomorrow or Friday I'm going to send out the last of the
>>> GL_ARB_separate_shader_objects patches.  Shortly after that, I will send
>>> out patches to enable GL_EXT_separate_shader_objects on GLES.  This EXT
>>> is the GLES subset of the ARB extension.
>>>
>>> In preparing for this new extension, I noticed the old problem that any
>>> extension function that aliases a core function (whether it is core in
>>> GLES or desktop GL) isn't hidden.  This series should fix that.
>>>
>>> Longer term, I'd like to change the generation of libGL*.  Right now all
>>> the information describing the interfaces and the information selecting
>>> the exposed interfaces in combined in a single XML database.  As patch 4
>>> shows, that makes it impossible to have a single function that is
>>> exposed in one API but hidden in another.  I'd like to pull all the
>>> "offset", "static_dispatch", "glx_ignore", and "exec" information out
>>> into separate files.
>>>
>>> This will mean that adding a new extension will require changes to
>>> multiple files.  The usual XML bits will need to be added.  Entries will
>>> need to be add to per-libGL* files, an "exec" file, and an "offsets".
>>> We can probably get rid of the offsets file since no functions will ever
>>> be added that have static offsets.
>>
>> If we're going to be doing major rework of the XML, I'd *really* like to
>> see us move to using the upstream XML for as much as possible.
> 
> Yeah, me too.  I think once we get a bunch of the Mesa-specific
> information out of the existing XML, that will be possible.

There may be one (at least temporary) roadblock to this plan.  There is
a LOT of information in our XML that is necessary to generate GLX
protocol code.  For example, our enums are decorated with information
about which Get functions can use them and how much data they return.






We have similar information for enums that are used for setter functions.








The information about the setter and getter functions is indirectly
encoded in the Khronos XML.  The enums are put in named groups (e.g.,
"GetTextureParameter"), and function parameters are tagged with a group
name.

There's a bunch of other GLX information (image protocol) that is also
missing from the Khronos XML.  It's also missing information about which
render functions can use render_large.

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




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

[Mesa-dev] [Bug 76960] NameError: name 'src' is not defined

[bugzilla-daemon]

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

--- Comment #4 from Ian Romanick  ---
Oh dear.  The -c is in the wrong place.  It should go on the other side of
$SCRIPT.

-- 
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

[Mesa-dev] [PATCH] glapi: Fix scons build

[Ian Romanick]

From: Ian Romanick 

Put the -c in the correct place (and match Makefile.am).

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76960
Cc: Vinson Lee 
---
 src/mapi/glapi/gen/SConscript | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mapi/glapi/gen/SConscript b/src/mapi/glapi/gen/SConscript
index 4d827b0..b9cdbbf 100644
--- a/src/mapi/glapi/gen/SConscript
+++ b/src/mapi/glapi/gen/SConscript
@@ -38,7 +38,7 @@ env.CodeGenerate(
 target = '../../../mapi/glapi/glprocs.h',
 script = 'gl_procs.py',
 source = sources,
-command = python_cmd + ' -c $SCRIPT -f $SOURCE > $TARGET'
+command = python_cmd + ' $SCRIPT -c -f $SOURCE > $TARGET'
 )
 
 env.CodeGenerate(
-- 
1.8.1.4

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

Re: [Mesa-dev] [PATCH] glx: Do not advertise buffer_age on dri2

[Ian Romanick]

On 03/30/2014 02:36 PM, Adel Gadllah wrote:
> Previously GLX_EXT_buffer_age has always been advertised as supported because
> both client_glx_support and client_glx_only where set. So it did not matter
> that direct_support is only set when running dri3 and we ended up always
> advertising it.
> 
> Fix that by not setting client_glx_only for buffer_age in 
> known_glx_extensions.

I believe this is correct.  And it should still be advertised on DRI3
because the extension is marked direct_only.

> Signed-off-by: Adel Gadllah 

Reviewed-by: Ian Romanick 

> ---
>  src/glx/glxextensions.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/glx/glxextensions.c b/src/glx/glxextensions.c
> index ac1b4a7..ce5d66d 100644
> --- a/src/glx/glxextensions.c
> +++ b/src/glx/glxextensions.c
> @@ -103,7 +103,7 @@ static const struct extension_info known_glx_extensions[] 
> = {
> { GLX(SGIX_visual_select_group),VER(0,0), Y, Y, N, N },
> { GLX(EXT_texture_from_pixmap), VER(0,0), Y, N, N, N },
> { GLX(INTEL_swap_event),VER(0,0), Y, N, N, N },
> -   { GLX(EXT_buffer_age),  VER(0,0), Y, N, Y, Y },
> +   { GLX(EXT_buffer_age),  VER(0,0), Y, N, N, Y },
> { NULL }
>  };
>  
> 

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

Re: [Mesa-dev] [PATCH] glapi: Fix scons build

[Brian Paul]

On 04/02/2014 01:30 PM, Ian Romanick wrote:

From: Ian Romanick 

Put the -c in the correct place (and match Makefile.am).

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76960
Cc: Vinson Lee 
---
  src/mapi/glapi/gen/SConscript | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mapi/glapi/gen/SConscript b/src/mapi/glapi/gen/SConscript
index 4d827b0..b9cdbbf 100644
--- a/src/mapi/glapi/gen/SConscript
+++ b/src/mapi/glapi/gen/SConscript
@@ -38,7 +38,7 @@ env.CodeGenerate(
  target = '../../../mapi/glapi/glprocs.h',
  script = 'gl_procs.py',
  source = sources,
-command = python_cmd + ' -c $SCRIPT -f $SOURCE > $TARGET'
+command = python_cmd + ' $SCRIPT -c -f $SOURCE > $TARGET'
  )

  env.CodeGenerate(



Plain scons build seems OK with this.

Tested-by: Brian Paul 

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

Re: [Mesa-dev] DaibloIII: radeon: mmap failed, errno: 12

[Marek Olšák]

This is a known bug. See:

https://bugs.freedesktop.org/show_bug.cgi?id=74868#c14

Marek

On Wed, Apr 2, 2014 at 12:30 AM, Mike Mestnik  wrote:
> http://bitly.com/1ibsC0y
>
> What debugging steps are next?
> There is no BT because the application exits cleanly.
>
>
> ___
> 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] docs: Add note about updating tests to dev info

[Matt Turner]

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

[Mesa-dev] [PATCH] glapi: Fix make check

[Ian Romanick]

From: Ian Romanick 

/me puts a paper bag on his head and sits in the corner.

This was supposed to be included in 5a68f731, which added
glPointSizePointerOES back to the list of functions exposed by
libGLESv1_CM.  It looks like it was an uncommitted change in my tree
when I sent the patch out.

Signed-off-by: Ian Romanick 
---
 src/mapi/es1api/ABI-check | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mapi/es1api/ABI-check b/src/mapi/es1api/ABI-check
index aecad5a..44654cd 100755
--- a/src/mapi/es1api/ABI-check
+++ b/src/mapi/es1api/ABI-check
@@ -122,6 +122,7 @@ glPointParameterfv
 glPointParameterx
 glPointParameterxv
 glPointSize
+glPointSizePointerOES
 glPointSizex
 glPolygonOffset
 glPolygonOffsetx
-- 
1.8.1.4

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

Re: [Mesa-dev] Gallium docs online builds

[Ilia Mirkin]

On Mon, Mar 31, 2014 at 12:43 PM, Ilia Mirkin  wrote:
> Hi everyone,
>
> I've set up a readthedocs.org build to point at the gallium docs:
>
> http://gallium.readthedocs.org/en/latest/
>
> I didn't find any publicly available built docs otherwise (except some
> rather outdated ones[1]), and this is able to build against the latest
> git and auto-updates without us doing anything (might need to set up a
> commit hook to get that to work, I'll investigate later). There are
> also versioned builds (tailing the respective branches) for 9.0 and
> later.
>
> I don't really like their default scheme, I'm more used to the
> "regular" one, it's selectable somehow (I think by making conf.py
> changes). But I thought I'd give it a shot, perhaps I'm just used to
> the other one but this one's fine too.
>
> If anyone is interested in being added as a maintainer, email me your
> readthedocs.org username. Conversely, if you hate the idea and think I
> should take this down, let me know, and I'll be happy to comply (if
> there's consensus).

Well, there hasn't been any response, which hopefully means that no
one outright hates it. Also no one has asked to be added as a
maintainer... hopefully I could recruit one or two volunteers, in case
I'm not around and a change needs to be made.

In order for it to rebuild stuff automatically, we need to do

curl -X POST http://readthedocs.org/build/gallium

in a post-commit hook. I guess that has to be added directly in the
mesa repo... who would I talk to about doing that?

Also, if someone in charge of mesa3d.org wants to add a
gallium-docs.mesa3d.org or something, here is how:

http://read-the-docs.readthedocs.org/en/latest/alternate_domains.html

(short version: adding a CNAME is enough.) At which point I can set
that up as a canonical URL. But that's completely optional.

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

Re: [Mesa-dev] [PATCH] glapi: Fix make check

[Matt Turner]

I should have caught it too.

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/4] glapi: Fix build break in 'make check' on non-shared-glapi builds

[Dieter Nützel]

Am 02.04.2014 08:12, schrieb Timothy Arceri:

On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote:

Hello Ian, hello Timothy,

does this fix the regression introduced with commit fb78fa58?

[Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION):
initTexture2D (bisected)
http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html

Thanks,
   Dieter


Hi Dieter,

I just ran ./build/Release/gl-320-primitive-sprite on Mesa 10.2.0-devel
(git-76ba50a) on Intel graphics and it ran fine with no error. Have you
tried running it again with the latest code from git?
Tim


Hello Tim,

thank you very much for your direct reply!
I've retested it with Mesa git daily on my _32bit_ system.
All with same result.
I even recompiled ogl-samples after recheckout several times NO go.
Last try last night 8-(

But,

...argh,
after your request I've cloned ogl-samples this evening again and can't 
compile it anylonger. Someone changed the code to compile on 64 bit 
system only now, I think:


[ 13%] Building CXX object 
framework/CMakeFiles/framework.dir/compiler.cpp.o

Linking CXX static library libframework.a
[ 13%] Built target framework
Scanning dependencies of target es-200-draw-elements
[ 13%] Building CXX object 
tests/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o

Linking CXX executable ../build/Release/es-200-draw-elements
/usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld: 
skipping incompatible 
/opt/ogl-samples/external/FreeImage-3.15.4/linux64/libfreeimage.a when 
searching for -lfreeimage
/usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld: 
cannot find -lfreeimage

collect2: error: ld returned 1 exit status
make[2]: *** [build/Release/es-200-draw-elements] Fehler 1
make[1]: *** [tests/CMakeFiles/es-200-draw-elements.dir/all] Fehler 2
make: *** [all] Fehler 2
69.267u 4.505s 1:27.26 84.5%0+0k 12368+11176io 44pf+0w

I'll try to go back some days in ogl-samples repository and try to get 
it running (with Mesa 10.1.0), again as starting point.


Any hints?

-Dieter


Am 01.04.2014 22:15, schrieb Ian Romanick:
> From: Ian Romanick 
>
> Commit fb78fa58 made the GL_ARB_debug_output functions aliases of the
> GL_KHR_debug output functions.  As a result, the function names in
> struct _glapi_table also changed.  The table in check_table.cpp used
> the
> ARB names.
>
> Signed-off-by: Ian Romanick 
> Cc: Vinson Lee 
> Cc: Timothy Arceri 
> ---
>  src/mapi/glapi/tests/check_table.cpp | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mapi/glapi/tests/check_table.cpp
> b/src/mapi/glapi/tests/check_table.cpp
> index 375645b..89d9073 100644
> --- a/src/mapi/glapi/tests/check_table.cpp
> +++ b/src/mapi/glapi/tests/check_table.cpp
> @@ -1227,10 +1227,10 @@ const struct name_offset known_dispatch[] = {
> { "glGetShaderPrecisionFormat", _O(GetShaderPrecisionFormat) },
> { "glReleaseShaderCompiler", _O(ReleaseShaderCompiler) },
> { "glShaderBinary", _O(ShaderBinary) },
> -   { "glDebugMessageCallbackARB", _O(DebugMessageCallbackARB) },
> -   { "glDebugMessageControlARB", _O(DebugMessageControlARB) },
> -   { "glDebugMessageInsertARB", _O(DebugMessageInsertARB) },
> -   { "glGetDebugMessageLogARB", _O(GetDebugMessageLogARB) },
> +   { "glDebugMessageCallback", _O(DebugMessageCallback) },
> +   { "glDebugMessageControl", _O(DebugMessageControl) },
> +   { "glDebugMessageInsert", _O(DebugMessageInsert) },
> +   { "glGetDebugMessageLog", _O(GetDebugMessageLog) },
> { "glGetGraphicsResetStatusARB", _O(GetGraphicsResetStatusARB) },
> { "glGetnColorTableARB", _O(GetnColorTableARB) },
> { "glGetnCompressedTexImageARB", _O(GetnCompressedTexImageARB) },

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

Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds

[Ian Romanick]

On 04/02/2014 03:43 PM, Dieter Nützel wrote:
> Am 02.04.2014 08:12, schrieb Timothy Arceri:
>> On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote:
>>> Hello Ian, hello Timothy,
>>>
>>> does this fix the regression introduced with commit fb78fa58?
>>>
>>> [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION):
>>> initTexture2D (bisected)
>>> http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html
>>>
>>> Thanks,
>>>Dieter
>>
>> Hi Dieter,
>>
>> I just ran ./build/Release/gl-320-primitive-sprite on Mesa 10.2.0-devel
>> (git-76ba50a) on Intel graphics and it ran fine with no error. Have you
>> tried running it again with the latest code from git?
>> Tim
> 
> Hello Tim,
> 
> thank you very much for your direct reply!
> I've retested it with Mesa git daily on my _32bit_ system.
> All with same result.
> I even recompiled ogl-samples after recheckout several times NO go.
> Last try last night 8-(
> 
> But,
> 
> ...argh,
> after your request I've cloned ogl-samples this evening again and can't
> compile it anylonger. Someone changed the code to compile on 64 bit
> system only now, I think:
> 
> [ 13%] Building CXX object
> framework/CMakeFiles/framework.dir/compiler.cpp.o
> Linking CXX static library libframework.a
> [ 13%] Built target framework
> Scanning dependencies of target es-200-draw-elements
> [ 13%] Building CXX object
> tests/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o
> Linking CXX executable ../build/Release/es-200-draw-elements
> /usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld:
> skipping incompatible
> /opt/ogl-samples/external/FreeImage-3.15.4/linux64/libfreeimage.a when
> searching for -lfreeimage

He's shipping a prebuilt .a???  Madness!  Is there source code for
FreeImage included?  Can you just build a 32-bit version?  It seems like
he has a crazy build system...

> /usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld:
> cannot find -lfreeimage
> collect2: error: ld returned 1 exit status
> make[2]: *** [build/Release/es-200-draw-elements] Fehler 1
> make[1]: *** [tests/CMakeFiles/es-200-draw-elements.dir/all] Fehler 2
> make: *** [all] Fehler 2
> 69.267u 4.505s 1:27.26 84.5%0+0k 12368+11176io 44pf+0w
> 
> I'll try to go back some days in ogl-samples repository and try to get
> it running (with Mesa 10.1.0), again as starting point.
> 
> Any hints?
> 
> -Dieter
> 
>>> Am 01.04.2014 22:15, schrieb Ian Romanick:
>>> > From: Ian Romanick 
>>> >
>>> > Commit fb78fa58 made the GL_ARB_debug_output functions aliases of the
>>> > GL_KHR_debug output functions.  As a result, the function names in
>>> > struct _glapi_table also changed.  The table in check_table.cpp used
>>> > the
>>> > ARB names.
>>> >
>>> > Signed-off-by: Ian Romanick 
>>> > Cc: Vinson Lee 
>>> > Cc: Timothy Arceri 
>>> > ---
>>> >  src/mapi/glapi/tests/check_table.cpp | 8 
>>> >  1 file changed, 4 insertions(+), 4 deletions(-)
>>> >
>>> > diff --git a/src/mapi/glapi/tests/check_table.cpp
>>> > b/src/mapi/glapi/tests/check_table.cpp
>>> > index 375645b..89d9073 100644
>>> > --- a/src/mapi/glapi/tests/check_table.cpp
>>> > +++ b/src/mapi/glapi/tests/check_table.cpp
>>> > @@ -1227,10 +1227,10 @@ const struct name_offset known_dispatch[] = {
>>> > { "glGetShaderPrecisionFormat", _O(GetShaderPrecisionFormat) },
>>> > { "glReleaseShaderCompiler", _O(ReleaseShaderCompiler) },
>>> > { "glShaderBinary", _O(ShaderBinary) },
>>> > -   { "glDebugMessageCallbackARB", _O(DebugMessageCallbackARB) },
>>> > -   { "glDebugMessageControlARB", _O(DebugMessageControlARB) },
>>> > -   { "glDebugMessageInsertARB", _O(DebugMessageInsertARB) },
>>> > -   { "glGetDebugMessageLogARB", _O(GetDebugMessageLogARB) },
>>> > +   { "glDebugMessageCallback", _O(DebugMessageCallback) },
>>> > +   { "glDebugMessageControl", _O(DebugMessageControl) },
>>> > +   { "glDebugMessageInsert", _O(DebugMessageInsert) },
>>> > +   { "glGetDebugMessageLog", _O(GetDebugMessageLog) },
>>> > { "glGetGraphicsResetStatusARB", _O(GetGraphicsResetStatusARB) },
>>> > { "glGetnColorTableARB", _O(GetnColorTableARB) },
>>> > { "glGetnCompressedTexImageARB", _O(GetnCompressedTexImageARB) },
> ___
> 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/4] glapi: Fix build break in 'make check' on non-shared-glapi builds

[Dieter Nützel]

Am 03.04.2014 01:19, schrieb Ian Romanick:

On 04/02/2014 03:43 PM, Dieter Nützel wrote:

Am 02.04.2014 08:12, schrieb Timothy Arceri:

On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote:

Hello Ian, hello Timothy,

does this fix the regression introduced with commit fb78fa58?

[Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION):
initTexture2D (bisected)
http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html

Thanks,
   Dieter


Hi Dieter,

I just ran ./build/Release/gl-320-primitive-sprite on Mesa 
10.2.0-devel
(git-76ba50a) on Intel graphics and it ran fine with no error. Have 
you

tried running it again with the latest code from git?
Tim


Hello Tim,

thank you very much for your direct reply!
I've retested it with Mesa git daily on my _32bit_ system.
All with same result.
I even recompiled ogl-samples after recheckout several times NO go.
Last try last night 8-(

But,

...argh,
after your request I've cloned ogl-samples this evening again and 
can't

compile it anylonger. Someone changed the code to compile on 64 bit
system only now, I think:

[ 13%] Building CXX object
framework/CMakeFiles/framework.dir/compiler.cpp.o
Linking CXX static library libframework.a
[ 13%] Built target framework
Scanning dependencies of target es-200-draw-elements
[ 13%] Building CXX object
tests/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o
Linking CXX executable ../build/Release/es-200-draw-elements
/usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld:
skipping incompatible
/opt/ogl-samples/external/FreeImage-3.15.4/linux64/libfreeimage.a when
searching for -lfreeimage


He's shipping a prebuilt .a???  Madness!


It seems so ;-(


Is there source code for FreeImage included?


Can't find any.


Can you just build a 32-bit version?


I see only linux64.


It seems like he has a crazy build system...


/opt/ogl-samples> l external/FreeImage-3.15.4/*
-rw-r--r-- 1 dieter users 53617  3. Apr 00:25 
external/FreeImage-3.15.4/FreeImage.h


external/FreeImage-3.15.4/linux64:
insgesamt 6424
drwxr-xr-x 2 dieter users4096  3. Apr 01:16 .
drwxr-xr-x 6 dieter users4096  3. Apr 01:16 ..
-rw-r--r-- 1 dieter users 6877852  3. Apr 01:16 libfreeimage.a

external/FreeImage-3.15.4/macosx:
insgesamt 9592
drwxr-xr-x 2 dieter users 4096  3. Apr 01:16 .
drwxr-xr-x 6 dieter users 4096  3. Apr 01:16 ..
-rw-r--r-- 1 dieter users 10397040  3. Apr 01:16 libfreeimage.a

external/FreeImage-3.15.4/win32:
insgesamt 2452
drwxr-xr-x 2 dieter users4096  3. Apr 00:25 .
drwxr-xr-x 6 dieter users4096  3. Apr 01:16 ..
-rw-r--r-- 1 dieter users 2732032  3. Apr 00:25 FreeImage.dll
-rw-r--r-- 1 dieter users   64482  3. Apr 00:25 FreeImage.lib

external/FreeImage-3.15.4/win64:
insgesamt 3208
drwxr-xr-x 2 dieter users4096  3. Apr 00:25 .
drwxr-xr-x 6 dieter users4096  3. Apr 01:16 ..
-rw-r--r-- 1 dieter users 3508736  3. Apr 00:25 FreeImage.dll
-rw-r--r-- 1 dieter users   60368  3. Apr 00:25 FreeImage.lib

Worked all OK before 18. March 2014.
Tried several older versions but no success at the moment.
git checkout `git rev-list -n 1 --before="2014-03-18" master`

-Dieter


/usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld:
cannot find -lfreeimage
collect2: error: ld returned 1 exit status
make[2]: *** [build/Release/es-200-draw-elements] Fehler 1
make[1]: *** [tests/CMakeFiles/es-200-draw-elements.dir/all] Fehler 2
make: *** [all] Fehler 2
69.267u 4.505s 1:27.26 84.5%0+0k 12368+11176io 44pf+0w

I'll try to go back some days in ogl-samples repository and try to get
it running (with Mesa 10.1.0), again as starting point.

Any hints?

-Dieter


Am 01.04.2014 22:15, schrieb Ian Romanick:
> From: Ian Romanick 
>
> Commit fb78fa58 made the GL_ARB_debug_output functions aliases of the
> GL_KHR_debug output functions.  As a result, the function names in
> struct _glapi_table also changed.  The table in check_table.cpp used
> the
> ARB names.
>
> Signed-off-by: Ian Romanick 
> Cc: Vinson Lee 
> Cc: Timothy Arceri 
> ---
>  src/mapi/glapi/tests/check_table.cpp | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mapi/glapi/tests/check_table.cpp
> b/src/mapi/glapi/tests/check_table.cpp
> index 375645b..89d9073 100644
> --- a/src/mapi/glapi/tests/check_table.cpp
> +++ b/src/mapi/glapi/tests/check_table.cpp
> @@ -1227,10 +1227,10 @@ const struct name_offset known_dispatch[] = {
> { "glGetShaderPrecisionFormat", _O(GetShaderPrecisionFormat) },
> { "glReleaseShaderCompiler", _O(ReleaseShaderCompiler) },
> { "glShaderBinary", _O(ShaderBinary) },
> -   { "glDebugMessageCallbackARB", _O(DebugMessageCallbackARB) },
> -   { "glDebugMessageControlARB", _O(DebugMessageControlARB) },
> -   { "glDebugMessageInsertARB", _O(DebugMessageInsertARB) },
> -   { "glGetDebugMessageLogARB", _O(GetDebugMessageLogARB) },
> +   { "glDebugMessageCallback", _O(DebugMessageCallback) },
> +   { "glDebugMessageControl", _O(DebugMessageControl) },
>

Re: [Mesa-dev] [PATCH 13/19] linker: Modify cross_validate_outputs_to_inputs to match using explicit locations

[Cody Northrop]

I applied a fix locally for the problem Olv pointed out and tested the
patches.

Running into a problem with the linker code when a geometry shader has
location layout qualifiers for both inputs and outputs.

It falls into the assign_varying_locations() scenario that has a producer
but no consumer, which prevents the input locations from being processed.
This leads to backend instructions like these, which have negative
attribute registers:

3: mov vgrf11.0.xyz:F, attr-1.59.xyzx:F
4: mov vgrf12.0.xyz:F, attr-1.118.xyzx:F

Those trigger the following debug assert when a negative register indexes
the attribute_map:

int grf = attribute_map[inst->src[i].reg + inst->src[i].reg_offset];

/* All attributes used in the shader need to have been assigned a
* hardware register by the caller
*/
assert(grf != 0);

Does assign_varying_locations() need to be updated to handle when a single
shader is both a consumer and producer?  Or maybe call it twice on the same
separate shader, once as producer, once as consumer?

The below patch to an existing piglit test demonstrates the assert,
although it doesn't render to verify the locations get matched up
correctly.  Adding a geometry shader to rendezvous_by_location.c is a
better long term test, unless it is already tested somewhere I haven't
found.

Thanks,

-C

diff --git a/tests/spec/arb_separate_shader_objects/GetProgramPipelineiv.c
b/tests/spec/arb_separate_shader_objects/GetProgramPipelineiv.c
index d95d7b8..93e3fd9 100644
--- a/tests/spec/arb_separate_shader_objects/GetProgramPipelineiv.c
+++ b/tests/spec/arb_separate_shader_objects/GetProgramPipelineiv.c
@@ -145,9 +145,12 @@ piglit_init(int argc, char **argv)
"\n"
"layout(triangles) in;\n"
"layout(triangle_strip, max_vertices = 3) out;\n"
+   "layout(location = 0) in vec4 foo[3];\n"
+   "layout(location = 0) out vec4 bar[3];\n"
"void main() {\n"
"for(int i = 0; i < gl_in.length(); i++) {\n"
-   "gl_Position = gl_in[i].gl_Position;\n"
+   "gl_Position = gl_in[i].gl_Position + foo[1];\n"
+   "bar[2] = foo[2];\n"
"EmitVertex();\n"
"}\n"
"EndPrimitive();\n"



On Fri, Mar 28, 2014 at 12:36 AM, Chia-I Wu  wrote:

> On Fri, Mar 28, 2014 at 5:40 AM, Ian Romanick  wrote:
> > From: Ian Romanick 
> >
> > This will be used for GL_ARB_separate_shader_objects.  That extension
> > not only allows separable shaders to rendezvous by location, but it also
> > allows traditionally linked shaders to rendezvous by location.  The spec
> > says:
> >
> > 36. How does the behavior of input/output interface matching differ
> > between separable programs and non-separable programs?
> >
> > RESOLVED: The rules for matching individual variables or block
> > members between stages are identical for separable and
> > non-separable programs, with one exception -- matching variables
> > of different type with the same location, as discussed in issue
> > 34, applies only to separable programs.
> >
> > However, the ability to enforce matching requirements differs
> > between program types.  In non-separable programs, both sides of
> > an interface are contained in the same linked program.  In this
> > case, if the linker detects a mismatch, it will generate a link
> > error.
> >
> > Signed-off-by: Ian Romanick 
> > ---
> >  src/glsl/link_varyings.cpp   | 73
> +++-
> >  src/glsl/tests/varyings_test.cpp | 35 ---
> >  2 files changed, 88 insertions(+), 20 deletions(-)
> >
> > diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
> > index 3d9516c..3f80dbd 100644
> > --- a/src/glsl/link_varyings.cpp
> > +++ b/src/glsl/link_varyings.cpp
> > @@ -172,6 +172,7 @@ cross_validate_outputs_to_inputs(struct
> gl_shader_program *prog,
> >  gl_shader *producer, gl_shader
> *consumer)
> >  {
> > glsl_symbol_table parameters;
> > +   ir_variable *explicit_locations[MAX_VARYING] = { NULL, };
> >
> > /* Find all shader outputs in the "producer" stage.
> >  */
> > @@ -181,7 +182,26 @@ cross_validate_outputs_to_inputs(struct
> gl_shader_program *prog,
> >if ((var == NULL) || (var->data.mode != ir_var_shader_out))
> >  continue;
> >
> > -  parameters.add_variable(var);
> > +  if (!var->data.explicit_location
> > +  || var->data.location < VARYING_SLOT_VAR0)
> > + parameters.add_variable(var);
> > +  else {
> > + /* User-defined varyings with explicit locations are handled
> > +  * differently because they do not need to have matching names.
> > +  */
> > + const unsigned idx = var->data.location - VARYING_SLOT_VAR0;
> > +
> > + if (

Re: [Mesa-dev] [PATCH 1/7] i965: Mark is_tex() and friends as const.

[Anuj Phogat]

On Mon, Mar 31, 2014 at 10:16 AM, Matt Turner  wrote:
> ---
>  src/mesa/drivers/dri/i965/brw_shader.cpp | 10 +-
>  src/mesa/drivers/dri/i965/brw_shader.h   | 10 +-
>  2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp 
> b/src/mesa/drivers/dri/i965/brw_shader.cpp
> index bbc5f3d..ca448d0 100644
> --- a/src/mesa/drivers/dri/i965/brw_shader.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
> @@ -552,7 +552,7 @@ backend_visitor::backend_visitor(struct brw_context *brw,
>  }
>
>  bool
> -backend_instruction::is_tex()
> +backend_instruction::is_tex() const
>  {
> return (opcode == SHADER_OPCODE_TEX ||
> opcode == FS_OPCODE_TXB ||
> @@ -569,7 +569,7 @@ backend_instruction::is_tex()
>  }
>
>  bool
> -backend_instruction::is_math()
> +backend_instruction::is_math() const
>  {
> return (opcode == SHADER_OPCODE_RCP ||
> opcode == SHADER_OPCODE_RSQ ||
> @@ -584,7 +584,7 @@ backend_instruction::is_math()
>  }
>
>  bool
> -backend_instruction::is_control_flow()
> +backend_instruction::is_control_flow() const
>  {
> switch (opcode) {
> case BRW_OPCODE_DO:
> @@ -601,7 +601,7 @@ backend_instruction::is_control_flow()
>  }
>
>  bool
> -backend_instruction::can_do_source_mods()
> +backend_instruction::can_do_source_mods() const
>  {
> switch (opcode) {
> case BRW_OPCODE_ADDC:
> @@ -620,7 +620,7 @@ backend_instruction::can_do_source_mods()
>  }
>
>  bool
> -backend_instruction::can_do_saturate()
> +backend_instruction::can_do_saturate() const
>  {
> switch (opcode) {
> case BRW_OPCODE_ADD:
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.h 
> b/src/mesa/drivers/dri/i965/brw_shader.h
> index 086d042..6bd7dc8 100644
> --- a/src/mesa/drivers/dri/i965/brw_shader.h
> +++ b/src/mesa/drivers/dri/i965/brw_shader.h
> @@ -42,11 +42,11 @@ enum PACKED register_file {
>
>  class backend_instruction : public exec_node {
>  public:
> -   bool is_tex();
> -   bool is_math();
> -   bool is_control_flow();
> -   bool can_do_source_mods();
> -   bool can_do_saturate();
> +   bool is_tex() const;
> +   bool is_math() const;
> +   bool is_control_flow() const;
> +   bool can_do_source_mods() const;
> +   bool can_do_saturate() const;
>
> /**
>  * True if the instruction has side effects other than writing to
> --
> 1.8.3.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Patches 1-5 are:
Reviewed-by: Anuj Phogat 

I'm not familiar enough with this code. So, not planning to review
patches 6 and 7.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds

[Timothy Arceri]

On Thursday, 3 April 2014 10:33 AM, Dieter Nützel  wrote:
 

>> He's shipping a prebuilt .a???  Madness!

>It seems so ;-(

>> Is there source code for FreeImage included?

>Can't find any.

hmmm... its an external library so you need to look outside the project ;) 
Anyway looks like you can grab the source here: 
http://sourceforge.net/projects/freeimage/files/Source%20Distribution/

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

Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds

[Dieter Nützel]

Am 03.04.2014 01:19, schrieb Ian Romanick:

On 04/02/2014 03:43 PM, Dieter Nützel wrote:

Am 02.04.2014 08:12, schrieb Timothy Arceri:

On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote:

Hello Ian, hello Timothy,

does this fix the regression introduced with commit fb78fa58?

[Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION):
initTexture2D (bisected)
http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html

Thanks,
   Dieter


Hi Dieter,

I just ran ./build/Release/gl-320-primitive-sprite on Mesa 
10.2.0-devel
(git-76ba50a) on Intel graphics and it ran fine with no error. Have 
you

tried running it again with the latest code from git?
Tim


Hello Tim,

thank you very much for your direct reply!
I've retested it with Mesa git daily on my _32bit_ system.
All with same result.
I even recompiled ogl-samples after recheckout several times NO go.
Last try last night 8-(

But,

...argh,
after your request I've cloned ogl-samples this evening again and 
can't

compile it anylonger. Someone changed the code to compile on 64 bit
system only now, I think:

[ 13%] Building CXX object
framework/CMakeFiles/framework.dir/compiler.cpp.o
Linking CXX static library libframework.a
[ 13%] Built target framework
Scanning dependencies of target es-200-draw-elements
[ 13%] Building CXX object
tests/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o
Linking CXX executable ../build/Release/es-200-draw-elements
/usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld:
skipping incompatible
/opt/ogl-samples/external/FreeImage-3.15.4/linux64/libfreeimage.a when
searching for -lfreeimage


He's shipping a prebuilt .a???  Madness!  Is there source code for
FreeImage included?  Can you just build a 32-bit version?  It seems 
like

he has a crazy build system...


Thank you guys for your patience...


I'll try to go back some days in ogl-samples repository and try to get
it running (with Mesa 10.1.0), again as starting point.


Due to
git clone -b 4.4.0 https://github.com/g-truc/ogl-samples
I'm back to ogl-samples 4.4.0 (without FreeImage-3.15.4)
and set, now.

Mesa 10.1.0: OK

/opt/ogl-samples> glxinfo | grep OpenGL
libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed 
(/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No 
such file or directory)

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV730
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.0
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.1.0
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:

/opt/ogl-samples> ./build/release/gl-320-primitive-sprite
libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed 
(/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No 
such file or directory)

OpenGL Version Needed 3.2 ( 3.3 Found )
Compiling shader
gl-320/primitive-sprite.vert...

Compiling shader
gl-320/primitive-sprite.frag...

Linking program

Running Test
Test Ended
Test Began Correctly.


Mesa 10.2.0-devel (git-d120506): BAD

/opt/ogl-samples> glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV730
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel 
(git-d120506)

OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.2.0-devel (git-d120506)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:

/opt/ogl-samples> ./build/release/gl-320-primitive-sprite
OpenGL Version Needed 3.2 ( 3.3 Found )
OpenGL Error(GL_INVALID_OPERATION): initTexture2D
Running Test
Test Ended

Any ideas?

BTW
gl-320-primitive-shading
sigfault with Mesa 10.1.0
and show
OpenGL Error(GL_INVALID_OPERATION): initProgram
with Mesa 10.2.0-devel (git-d120506) on r600g.
What does (should) it look like on Intel?

Dieter


Am 01.04.2014 22:15, schrieb Ian Romanick:
> From: Ian Romanick 
>
> Commit fb78fa58 made the GL_ARB_debug_output functions aliases of the
> GL_KHR_debug output functions.  As a result, the function names in
> struct _glapi_table also changed.  The table in check_table.cpp used
> the
> ARB names.
>
> Signed-off-by: Ian Romanick 
> Cc: Vinson Lee 
> Cc: Timothy Arceri 
> ---
>  src/mapi/glapi/tests/check_table.cpp | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mapi/glapi/tests/check_table.cpp
> b/src/mapi/glapi/tests/check_table.cpp
> index 375645b..89d9073 100644
> --- a/src/mapi/glapi/tests/check_table.cpp
> +++ b/src/mapi/glapi/tests/check_table.cpp
> @@ -1227,10 +1227,10 @@ const struct name_offset known_dispatch[] = {
> { "glGetShaderPrecisionFormat", _O(Ge

Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds

[Ian Romanick]

On 04/02/2014 06:13 PM, Dieter Nützel wrote:
> Am 03.04.2014 01:19, schrieb Ian Romanick:
>> On 04/02/2014 03:43 PM, Dieter Nützel wrote:
>>> Am 02.04.2014 08:12, schrieb Timothy Arceri:
 On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote:
> Hello Ian, hello Timothy,
>
> does this fix the regression introduced with commit fb78fa58?
>
> [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION):
> initTexture2D (bisected)
> http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html
>
> Thanks,
>Dieter

 Hi Dieter,

 I just ran ./build/Release/gl-320-primitive-sprite on Mesa 10.2.0-devel
 (git-76ba50a) on Intel graphics and it ran fine with no error. Have you
 tried running it again with the latest code from git?
 Tim
>>>
>>> Hello Tim,
>>>
>>> thank you very much for your direct reply!
>>> I've retested it with Mesa git daily on my _32bit_ system.
>>> All with same result.
>>> I even recompiled ogl-samples after recheckout several times NO go.
>>> Last try last night 8-(
>>>
>>> But,
>>>
>>> ...argh,
>>> after your request I've cloned ogl-samples this evening again and can't
>>> compile it anylonger. Someone changed the code to compile on 64 bit
>>> system only now, I think:
>>>
>>> [ 13%] Building CXX object
>>> framework/CMakeFiles/framework.dir/compiler.cpp.o
>>> Linking CXX static library libframework.a
>>> [ 13%] Built target framework
>>> Scanning dependencies of target es-200-draw-elements
>>> [ 13%] Building CXX object
>>> tests/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o
>>> Linking CXX executable ../build/Release/es-200-draw-elements
>>> /usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld:
>>> skipping incompatible
>>> /opt/ogl-samples/external/FreeImage-3.15.4/linux64/libfreeimage.a when
>>> searching for -lfreeimage
>>
>> He's shipping a prebuilt .a???  Madness!  Is there source code for
>> FreeImage included?  Can you just build a 32-bit version?  It seems like
>> he has a crazy build system...
> 
> Thank you guys for your patience...
> 
>>> I'll try to go back some days in ogl-samples repository and try to get
>>> it running (with Mesa 10.1.0), again as starting point.
> 
> Due to
> git clone -b 4.4.0 https://github.com/g-truc/ogl-samples
> I'm back to ogl-samples 4.4.0 (without FreeImage-3.15.4)
> and set, now.
> 
> Mesa 10.1.0: OK
> 
> /opt/ogl-samples> glxinfo | grep OpenGL
> libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed
> (/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No
> such file or directory)
> OpenGL vendor string: X.Org
> OpenGL renderer string: Gallium 0.4 on AMD RV730
> OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.0
> OpenGL core profile shading language version string: 3.30
> OpenGL core profile context flags: (none)
> OpenGL core profile profile mask: core profile
> OpenGL core profile extensions:
> OpenGL version string: 3.0 Mesa 10.1.0
> OpenGL shading language version string: 1.30
> OpenGL context flags: (none)
> OpenGL extensions:
> 
> /opt/ogl-samples> ./build/release/gl-320-primitive-sprite
> libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed
> (/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No
> such file or directory)
> OpenGL Version Needed 3.2 ( 3.3 Found )
> Compiling shader
> gl-320/primitive-sprite.vert...
> 
> Compiling shader
> gl-320/primitive-sprite.frag...
> 
> Linking program
> 
> Running Test
> Test Ended
> Test Began Correctly.
> 
> 
> Mesa 10.2.0-devel (git-d120506): BAD
> 
> /opt/ogl-samples> glxinfo | grep OpenGL
> OpenGL vendor string: X.Org
> OpenGL renderer string: Gallium 0.4 on AMD RV730
> OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel
> (git-d120506)
> OpenGL core profile shading language version string: 3.30
> OpenGL core profile context flags: (none)
> OpenGL core profile profile mask: core profile
> OpenGL core profile extensions:
> OpenGL version string: 3.0 Mesa 10.2.0-devel (git-d120506)
> OpenGL shading language version string: 1.30
> OpenGL context flags: (none)
> OpenGL extensions:
> 
> /opt/ogl-samples> ./build/release/gl-320-primitive-sprite
> OpenGL Version Needed 3.2 ( 3.3 Found )
> OpenGL Error(GL_INVALID_OPERATION): initTexture2D

I'm guessing that initTexture2D is in the application.  Can you set a
breakpoint at _mesa_error to see where exactly Mesa is throwing
GL_INVALID_OPERATION.  That should shed some light on things.

> Running Test
> Test Ended
> 
> Any ideas?
> 
> BTW
> gl-320-primitive-shading
> sigfault with Mesa 10.1.0
> and show
> OpenGL Error(GL_INVALID_OPERATION): initProgram
> with Mesa 10.2.0-devel (git-d120506) on r600g.
> What does (should) it look like on Intel?
> 
> Dieter
> 
> Am 01.04.2014 22:15, schrieb Ian Romanick:
> > From: Ian Romanick 
> >
> > Commit fb78fa58 made the GL_ARB_debug_output functions aliases of
> the
> > GL_KHR_debug output functions.  

[Mesa-dev] [PATCH] Added Diag Handler to receive LLVM Error messages

[Tom Stellard]

From: Darren Powell 

---
 src/gallium/drivers/radeon/radeon_llvm_emit.c | 34 ---
 src/gallium/drivers/radeonsi/si_shader.c  | 12 +++---
 src/gallium/drivers/radeonsi/si_state.c   |  2 ++
 3 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c 
b/src/gallium/drivers/radeon/radeon_llvm_emit.c
index 7bcdc27..4704225 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_emit.c
+++ b/src/gallium/drivers/radeon/radeon_llvm_emit.c
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -38,6 +39,8 @@
 #define FS_STRING_LEN 30
 #define TRIPLE_STRING_LEN 7
 
+// file global flag to signal Diagnostic Error Handler was called
+
 /**
  * Set the shader type we want to compile
  *
@@ -79,6 +82,13 @@ static LLVMTargetRef get_r600_target() {
return target;
 }
 
+static void radeonDiagnosticHandler(LLVMDiagnosticInfoRef di, void *context) {
+   unsigned int *diagnosticflag;
+   fprintf(stderr,"LLVM triggered Diagnostic Handler: %s\n", 
LLVMPrintDiagInfoToString(di));
+   diagnosticflag = (unsigned int *)context;
+   *diagnosticflag = 1;
+}
+
 /**
  * Compile an LLVM module to machine code.
  *
@@ -92,12 +102,15 @@ unsigned radeon_llvm_compile(LLVMModuleRef M, struct 
radeon_shader_binary *binar
char cpu[CPU_STRING_LEN];
char fs[FS_STRING_LEN];
char *err;
+   LLVMContextRef llvm_ctx;
+   unsigned rval = 0;
LLVMMemoryBufferRef out_buffer;
unsigned buffer_size;
const char *buffer_data;
char triple[TRIPLE_STRING_LEN];
LLVMBool r;
 
+   /* initialise */
init_r600_target();
 
target = get_r600_target();
@@ -112,24 +125,39 @@ unsigned radeon_llvm_compile(LLVMModuleRef M, struct 
radeon_shader_binary *binar
strncpy(fs, "+DumpCode", FS_STRING_LEN);
}
strncpy(triple, "r600--", TRIPLE_STRING_LEN);
+
+   /* Setup Diagnostic Handler*/
+   llvm_ctx = LLVMGetModuleContext(M);
+   LLVMContextSetDiagnosticHandler(llvm_ctx, radeonDiagnosticHandler, 
&rval);
+   rval = 0;
+
+   /* Compile IR*/
tm = LLVMCreateTargetMachine(target, triple, cpu, fs,
  LLVMCodeGenLevelDefault, LLVMRelocDefault,
  LLVMCodeModelDefault);
-
r = LLVMTargetMachineEmitToMemoryBuffer(tm, M, LLVMObjectFile, &err,
 &out_buffer);
+
+   /* Process Errors/Warnings */
if (r) {
-   fprintf(stderr, "%s", err);
+   fprintf(stderr, "%s: %s", __FUNCTION__, err);
FREE(err);
+   LLVMDisposeTargetMachine(tm);
return 1;
}
 
+   if (0 != rval) {
+   fprintf(stderr, "%s: Processing Diag Flag\n", __FUNCTION__);
+   }
+
+   /* Extract Shader Code*/
buffer_size = LLVMGetBufferSize(out_buffer);
buffer_data = LLVMGetBufferStart(out_buffer);
 
radeon_elf_read(buffer_data, buffer_size, binary, dump);
 
+   /* Clean up */
LLVMDisposeMemoryBuffer(out_buffer);
LLVMDisposeTargetMachine(tm);
-   return 0;
+   return rval;
 }
diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index e4390ee..0d070d3 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2293,14 +2293,19 @@ static void preload_streamout_buffers(struct 
si_shader_context *si_shader_ctx)
 int si_compile_llvm(struct si_context *sctx, struct si_pipe_shader *shader,
LLVMModuleRef mod)
 {
+   unsigned r; /* llvm_compile result */
unsigned i;
uint32_t *ptr;
struct radeon_shader_binary binary;
bool dump = r600_can_dump_shader(&sctx->screen->b,
shader->selector ? shader->selector->tokens : NULL);
+   const char * gpu_family = 
r600_get_llvm_processor_name(sctx->screen->b.family);
+
+   /* Use LLVM to compile shader */
memset(&binary, 0, sizeof(binary));
-   radeon_llvm_compile(mod, &binary,
-   r600_get_llvm_processor_name(sctx->screen->b.family), dump);
+   r = radeon_llvm_compile(mod, &binary, gpu_family, dump);
+
+   /* Output binary dump if rscreen->debug_flags are set */
if (dump && ! binary.disassembled) {
fprintf(stderr, "SI CODE:\n");
for (i = 0; i < binary.code_size; i+=4 ) {
@@ -2313,6 +2318,7 @@ int si_compile_llvm(struct si_context *sctx, struct 
si_pipe_shader *shader,
/* XXX: We may be able to emit some of these values directly rather than
 * extracting fields to be emitted later.
 */
+   /* Parse config data in compiled binary */
for (i = 0; i < binary.config_size; i+= 8) {
unsigned reg = util_

Re: [Mesa-dev] [PATCH] glapi: Fix scons build

[Vinson Lee]

On Wed, Apr 2, 2014 at 12:30 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> Put the -c in the correct place (and match Makefile.am).
>
> Signed-off-by: Ian Romanick 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76960
> Cc: Vinson Lee 
> ---
>  src/mapi/glapi/gen/SConscript | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mapi/glapi/gen/SConscript b/src/mapi/glapi/gen/SConscript
> index 4d827b0..b9cdbbf 100644
> --- a/src/mapi/glapi/gen/SConscript
> +++ b/src/mapi/glapi/gen/SConscript
> @@ -38,7 +38,7 @@ env.CodeGenerate(
>  target = '../../../mapi/glapi/glprocs.h',
>  script = 'gl_procs.py',
>  source = sources,
> -command = python_cmd + ' -c $SCRIPT -f $SOURCE > $TARGET'
> +command = python_cmd + ' $SCRIPT -c -f $SOURCE > $TARGET'
>  )
>
>  env.CodeGenerate(
> --
> 1.8.1.4
>

This patch fixes the Linux SCons build.

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

[Mesa-dev] [Bug 76976] New: [llvmpipe] lp_rast.c:165:lp_rast_clear_color: Assertion `util_format_is_pure_uint(format)' failed.

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 76976
CC: bri...@vmware.com, jfons...@vmware.com,
srol...@vmware.com
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [llvmpipe] lp_rast.c:165:lp_rast_clear_color:
Assertion `util_format_is_pure_uint(format)' failed.
  Severity: critical
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: d120506e158e58b7a532c31427fe0a056ea270d8 (master 10.2.0-devel)

$ ./bin/clearbuffer-mixed-format -auto
src/gallium/drivers/llvmpipe/lp_rast.c:165:lp_rast_clear_color: Assertion
`util_format_is_pure_uint(format)' failed.
Trace/breakpoint trap (core dumped)

(gdb) bt
#0  0x7fb9e91c09f1 in _debug_assert_fail (expr=0x7fb9e9c3adf0
"util_format_is_pure_uint(format)", file=0x7fb9e9c3adc8
"src/gallium/drivers/llvmpipe/lp_rast.c", 
line=165, function=0x7fb9e9c3afa0 <__func__.15884> "lp_rast_clear_color")
at src/gallium/auxiliary/util/u_debug.c:278
#1  0x7fb9e8ddb406 in lp_rast_clear_color (task=0x2417f08, arg=...) at
src/gallium/drivers/llvmpipe/lp_rast.c:165
#2  0x7fb9e8ddc702 in do_rasterize_bin (task=0x2417f08, bin=0x7fb9ec8f91e8,
x=0, y=0) at src/gallium/drivers/llvmpipe/lp_rast.c:653
#3  0x7fb9e8ddc76f in rasterize_bin (task=0x2417f08, bin=0x7fb9ec8f91e8,
x=0, y=0) at src/gallium/drivers/llvmpipe/lp_rast.c:672
#4  0x7fb9e8ddc87f in rasterize_scene (task=0x2417f08,
scene=0x7fb9ec8f9010) at src/gallium/drivers/llvmpipe/lp_rast.c:721
#5  0x7fb9e8ddcb4b in thread_function (init_data=0x2417f08) at
src/gallium/drivers/llvmpipe/lp_rast.c:842
#6  0x7fb9e8dda412 in impl_thrd_routine (p=0x2408060) at
include/c11/threads_posix.h:87
#7  0x7fb9e7d66f6e in start_thread (arg=0x7fb9e06fc700) at
pthread_create.c:311
#8  0x7fb9ec0429cd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:113
(gdb) frame 1
#1  0x7fb9e8ddb406 in lp_rast_clear_color (task=0x2417f08, arg=...) at
src/gallium/drivers/llvmpipe/lp_rast.c:165
165   assert(util_format_is_pure_uint(format));
(gdb) print format
$1 = PIPE_FORMAT_R8G8B8A8_UNORM

-- 
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

[Mesa-dev] [PATCH v2] automake: don't enable -Wl, --no-undefined on OpenBSD

[Jonathan Gray]

OpenBSD does not have DT_NEEDED entries for libc by design,
over concerns how the symbols would be referenced after
changing the major version of the library.

So avoid -no-undefined checks on OpenBSD as they will fail.

v2: don't include the -no-undefined libtool option in the variable
and change -Wl,--no-undefined references in Automake.inc as well.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76856
Signed-off-by: Jonathan Gray 
---
 configure.ac| 13 +
 src/egl/main/Makefile.am|  2 +-
 src/egl/wayland/wayland-egl/Makefile.am |  2 +-
 src/gallium/Automake.inc|  6 +++---
 src/gallium/targets/egl-static/Makefile.am  |  2 +-
 src/gallium/targets/gbm/Makefile.am |  2 +-
 src/gallium/targets/libgl-xlib/Makefile.am  |  2 +-
 src/gallium/targets/opencl/Makefile.am  |  2 +-
 src/gallium/targets/osmesa/Makefile.am  |  2 +-
 src/gallium/targets/pipe-loader/Makefile.am |  2 +-
 src/gallium/targets/xa/Makefile.am  |  2 +-
 src/gbm/Makefile.am |  2 +-
 src/glx/Makefile.am |  2 +-
 src/mapi/es1api/Makefile.am |  2 +-
 src/mapi/es2api/Makefile.am |  2 +-
 src/mapi/shared-glapi/Makefile.am   |  2 +-
 src/mapi/vgapi/Makefile.am  |  2 +-
 src/mesa/drivers/osmesa/Makefile.am |  2 +-
 src/mesa/drivers/x11/Makefile.am|  2 +-
 19 files changed, 33 insertions(+), 20 deletions(-)

diff --git a/configure.ac b/configure.ac
index 187006a..94b6dc2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -332,6 +332,19 @@ LDFLAGS=$save_LDFLAGS
 AC_SUBST([GC_SECTIONS])
 
 dnl
+dnl OpenBSD does not have DT_NEEDED entries for libc by design
+dnl so when these flags are passed to ld via libtool the checks will fail
+dnl
+case "$host_os" in
+openbsd*)
+LD_NO_UNDEFINED="" ;;
+*)
+LD_NO_UNDEFINED="-Wl,--no-undefined" ;;
+esac
+
+AC_SUBST([LD_NO_UNDEFINED])
+
+dnl
 dnl compatibility symlinks
 dnl
 case "$host_os" in
diff --git a/src/egl/main/Makefile.am b/src/egl/main/Makefile.am
index e4c2539..4b42bd6 100644
--- a/src/egl/main/Makefile.am
+++ b/src/egl/main/Makefile.am
@@ -78,7 +78,7 @@ libEGL_la_LDFLAGS = \
-version-number 1:0 \
-Wl,-Bsymbolic \
$(GC_SECTIONS) \
-   -Wl,--no-undefined
+   $(LD_NO_UNDEFINED)
 
 if HAVE_EGL_PLATFORM_X11
 AM_CFLAGS += -DHAVE_X11_PLATFORM
diff --git a/src/egl/wayland/wayland-egl/Makefile.am 
b/src/egl/wayland/wayland-egl/Makefile.am
index d3fe117..a03a7bf 100644
--- a/src/egl/wayland/wayland-egl/Makefile.am
+++ b/src/egl/wayland/wayland-egl/Makefile.am
@@ -12,7 +12,7 @@ libwayland_egl_la_LDFLAGS = \
-no-undefined \
-version-info 1 \
$(GC_SECTIONS) \
-   -Wl,--no-undefined
+   $(LD_NO_UNDEFINED)
 
 TESTS = wayland-egl-symbols-check
 
diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc
index 56f1433..beec755 100644
--- a/src/gallium/Automake.inc
+++ b/src/gallium/Automake.inc
@@ -67,7 +67,7 @@ GALLIUM_VDPAU_LINKER_FLAGS = \
-version-number $(VDPAU_MAJOR):$(VDPAU_MINOR) \
-export-symbols-regex $(VDPAU_EXPORTS) \
$(GC_SECTIONS) \
-   -Wl,--no-undefined
+   $(LD_NO_UNDEFINED)
 
 GALLIUM_XVMC_LINKER_FLAGS = \
-shared \
@@ -76,7 +76,7 @@ GALLIUM_XVMC_LINKER_FLAGS = \
-version-number $(XVMC_MAJOR):$(XVMC_MINOR) \
-export-symbols-regex '^XvMC' \
$(GC_SECTIONS) \
-   -Wl,--no-undefined
+   $(LD_NO_UNDEFINED)
 
 GALLIUM_OMX_LINKER_FLAGS = \
-shared \
@@ -84,7 +84,7 @@ GALLIUM_OMX_LINKER_FLAGS = \
-no-undefined \
-export-symbols-regex $(EXPORTS) \
$(GC_SECTIONS) \
-   -Wl,--no-undefined
+   $(LD_NO_UNDEFINED)
 
 GALLIUM_VDPAU_LIB_DEPS = \
$(top_builddir)/src/gallium/auxiliary/libgallium.la \
diff --git a/src/gallium/targets/egl-static/Makefile.am 
b/src/gallium/targets/egl-static/Makefile.am
index 58ecf69..40e7a96 100644
--- a/src/gallium/targets/egl-static/Makefile.am
+++ b/src/gallium/targets/egl-static/Makefile.am
@@ -49,7 +49,7 @@ AM_LDFLAGS = \
-no-undefined \
-avoid-version \
$(GC_SECTIONS) \
-   -Wl,--no-undefined \
+   $(LD_NO_UNDEFINED) \

-Wl,--version-script=$(top_srcdir)/src/gallium/targets/egl-static/egl.link
 
 egldir = $(EGL_DRIVER_INSTALL_DIR)
diff --git a/src/gallium/targets/gbm/Makefile.am 
b/src/gallium/targets/gbm/Makefile.am
index 22b4826..2b54e3c 100644
--- a/src/gallium/targets/gbm/Makefile.am
+++ b/src/gallium/targets/gbm/Makefile.am
@@ -71,7 +71,7 @@ gbm_gallium_drm_la_LDFLAGS = \
-no-undefined \
-avoid-version \
$(GC_SECTIONS) \
-   -Wl,--no-undefined
+   $(LD_NO_UNDEFINED)
 
 if HAVE_MESA_LLVM
 gbm_gallium_drm_la_LIBADD += $(LLVM_LIBS)
diff --git a/src/gallium/targets/libgl-xlib/Makefile.am 
b/src/gallium/targets/libgl-xlib/Makefile.am
index ef3d23e..4ee364e 100644
--- a/src/gallium/tar

Re: [Mesa-dev] [PATCH 1/4] xa: handle solid-fill src/mask

[Thomas Hellstrom]

On 04/01/2014 05:04 PM, Rob Clark wrote:
> From: Rob Clark 
>
> Add support to property handle solid-fill src and/or mask.  Without this
> we fallback to sw a lot for common things like text rendering.
>
> Signed-off-by: Rob Clark 
> ---
>  src/gallium/state_trackers/xa/xa_composite.c |  88 
>  src/gallium/state_trackers/xa/xa_priv.h  |   7 +-
>  src/gallium/state_trackers/xa/xa_renderer.c  | 289 
> ---
>  src/gallium/state_trackers/xa/xa_tgsi.c  |  31 ++-
>  4 files changed, 242 insertions(+), 173 deletions(-)

Rob,
While testing this patch it looks like we sometimes set two samplers,
and the first one is NULL.
The SVGA driver asserts on that condition.
We might need to move the active sampler to the first entry in that
case, and adjust tex coords and shader accordingly.

I'll discuss with BrianP.

/Thomas

> diff --git a/src/gallium/state_trackers/xa/xa_composite.c 
> b/src/gallium/state_trackers/xa/xa_composite.c
> index abe5be2..f63cf49 100644
> --- a/src/gallium/state_trackers/xa/xa_composite.c
> +++ b/src/gallium/state_trackers/xa/xa_composite.c
> @@ -111,12 +111,6 @@ blend_for_op(struct xa_composite_blend *blend,
>  boolean supported = FALSE;
>  
>  /*
> - * Temporarily disable component alpha since it appears buggy.
> - */
> -if (mask_pic && mask_pic->component_alpha)
> - return FALSE;
> -
> -/*
>   * our default in case something goes wrong
>   */
>  *blend = xa_blends[XA_BLEND_OP_OVER];
> @@ -125,6 +119,7 @@ blend_for_op(struct xa_composite_blend *blend,
>   if (xa_blends[i].op == op) {
>   *blend = xa_blends[i];
>   supported = TRUE;
> + break;
>   }
>  }
>  
> @@ -227,14 +222,6 @@ xa_composite_check_accelerated(const struct xa_composite 
> *comp)
>  if (src_pic->src_pict) {
>   if (src_pic->src_pict->type != xa_src_pict_solid_fill)
>   return -XA_ERR_INVAL;
> -
> - /*
> -  * Currently we don't support solid fill with a mask.
> -  * We can easily do that, but that would require shader,
> -  * sampler view setup and vertex setup modification.
> -  */
> - if (comp->mask)
> - return -XA_ERR_INVAL;
>  }
>  
>  if (blend_for_op(&blend, comp->op, comp->src, comp->mask, comp->dst)) {
> @@ -322,6 +309,12 @@ picture_format_fixups(struct xa_picture *src_pic,
>  }
>  
>  static int
> +is_solid_fill(struct xa_picture *pic)
> +{
> +return pic->src_pict && (pic->src_pict->type == xa_src_pict_solid_fill);
> +}
> +
> +static int
>  bind_shaders(struct xa_context *ctx, const struct xa_composite *comp)
>  {
>  unsigned vs_traits = 0, fs_traits = 0;
> @@ -336,8 +329,8 @@ bind_shaders(struct xa_context *ctx, const struct 
> xa_composite *comp)
>   fs_traits |= FS_SRC_REPEAT_NONE;
>  
>   if (src_pic->src_pict) {
> - if (src_pic->src_pict->type == xa_src_pict_solid_fill) {
> - fs_traits |= FS_SOLID_FILL | FS_FILL;
> + if (is_solid_fill(src_pic)) {
> + fs_traits |= FS_SOLID_FILL;
>   vs_traits |= VS_SOLID_FILL;
>   xa_pixel_to_float4(src_pic->src_pict->solid_fill.color,
>  ctx->solid_color);
> @@ -358,9 +351,17 @@ bind_shaders(struct xa_context *ctx, const struct 
> xa_composite *comp)
>   mask_pic->has_transform)
>   fs_traits |= FS_MASK_REPEAT_NONE;
>  
> + if (is_solid_fill(mask_pic)) {
> + fs_traits |= FS_SOLID_MASK;
> + vs_traits |= VS_SOLID_MASK;
> + xa_pixel_to_float4(mask_pic->src_pict->solid_fill.color,
> +ctx->solid_mask);
> + ctx->has_solid_mask = TRUE;
> + }
> +
>   if (mask_pic->component_alpha) {
>   struct xa_composite_blend blend;
> - if (!blend_for_op(&blend, comp->op, src_pic, mask_pic, NULL))
> + if (!blend_for_op(&blend, comp->op, src_pic, mask_pic, comp->dst))
>   return -XA_ERR_INVAL;
>  
>   if (blend.alpha_src) {
> @@ -399,7 +400,7 @@ bind_samplers(struct xa_context *ctx,
>  memset(&mask_sampler, 0, sizeof(struct pipe_sampler_state));
>  
>  if (src_pic) {
> - if (ctx->has_solid_color) {
> + if (is_solid_fill(src_pic)) {
>   samplers[0] = NULL;
>   pipe_sampler_view_reference(&ctx->bound_sampler_views[0], NULL);
>   } else {
> @@ -427,27 +428,31 @@ bind_samplers(struct xa_context *ctx,
>  }
>  
>  if (mask_pic) {
> - unsigned mask_wrap = xa_repeat_to_gallium(mask_pic->wrap);
> - int filter;
> -
> - (void) xa_filter_to_gallium(mask_pic->filter, &filter);
> -
> - mask_sampler.wrap_s = mask_wrap;
> - mask_sampler.wrap_t = mask_wrap;
> - mask_sampler.min_img_filter = filter;
> - mask_sampler.mag_img_filter = filter;
> - src_sampler.min_mip_filter = PIPE_TEX_MIPFILTER_NEAREST;
> - mask_sampler.normalized_coords = 1;
> - samplers[1] = &mask_sampler;
> - ctx->num_bound_samplers = 2;

[Mesa-dev] [PATCH v3] egl/dri2: use drm macros to construct device name

[Jonathan Gray]

Don't hardcode /dev/dri/card0 but instead use the drm
macros which allows the correct /dev/drm0 device to be
opened on OpenBSD.

v2: use snprintf and fallback to /dev/dri/card0
v3: check for snprintf truncation

Signed-off-by: Jonathan Gray 
---
 src/egl/drivers/dri2/platform_drm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index 2f7edb9..9a7633a 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -492,7 +492,12 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
 
gbm = disp->PlatformDisplay;
if (gbm == NULL) {
-  fd = open("/dev/dri/card0", O_RDWR);
+  char buf[64];
+  int n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, 0);
+  if (n != -1 && n < sizeof(buf))
+ fd = open(buf, O_RDWR);
+  if (fd < 0)
+ fd = open("/dev/dri/card0", O_RDWR);
   dri2_dpy->own_device = 1;
   gbm = gbm_create_device(fd);
   if (gbm == NULL)
-- 
1.9.0

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

[Mesa-dev] [PATCH] st/xa: Fix advertized version number and try to avoid future discrepancies

[Thomas Hellstrom]

The xa version number had to be set in two places. In configure.ac and in
xa_tracker.h. Furthermore, xa_tracker.h is an installed header so we can't
use mesa internal defines. So therefore, at configure time, modify the
xa_tracker.h header to use the version given by configure.ac

Signed-off-by: Thomas Hellstrom 
---
 configure.ac  |1 +
 src/gallium/state_trackers/xa/xa_tracker.h|  200 -
 src/gallium/state_trackers/xa/xa_tracker.h.in |  200 +
 3 files changed, 201 insertions(+), 200 deletions(-)
 delete mode 100644 src/gallium/state_trackers/xa/xa_tracker.h
 create mode 100644 src/gallium/state_trackers/xa/xa_tracker.h.in

diff --git a/configure.ac b/configure.ac
index af1b0d1..9b665b0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2055,6 +2055,7 @@ AC_CONFIG_FILES([Makefile
src/gallium/state_trackers/vdpau/Makefile
src/gallium/state_trackers/vega/Makefile
src/gallium/state_trackers/xa/Makefile
+src/gallium/state_trackers/xa/xa_tracker.h
src/gallium/state_trackers/xvmc/Makefile
src/gallium/targets/Makefile
src/gallium/targets/dri-freedreno/Makefile
diff --git a/src/gallium/state_trackers/xa/xa_tracker.h 
b/src/gallium/state_trackers/xa/xa_tracker.h
deleted file mode 100644
index 43e56ff..000
--- a/src/gallium/state_trackers/xa/xa_tracker.h
+++ /dev/null
@@ -1,200 +0,0 @@
-/**
- * Copyright 2009-2011 VMware, Inc. All rights reserved.
- *
- * Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use, copy,
- * modify, merge, publish, distribute, sublicense, and/or sell copies
- * of the Software, and to permit persons to whom the Software is
- * furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
- * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- * SOFTWARE.
- *
- * The format encoding idea is partially borrowed from libpixman, but it is not
- * considered a "substantial part of the software", so the pixman copyright
- * is left out for simplicity, and acknowledgment is instead given in this way.
- *
- *
- * Authors:
- * Zack Rusin 
- * Thomas Hellstrom 
- */
-
-#ifndef _XA_TRACKER_H_
-#define _XA_TRACKER_H_
-
-#include 
-
-#define XA_TRACKER_VERSION_MAJOR 2
-#define XA_TRACKER_VERSION_MINOR 1
-#define XA_TRACKER_VERSION_PATCH 0
-
-#define XA_FLAG_SHARED (1 << 0)
-#define XA_FLAG_RENDER_TARGET  (1 << 1)
-#define XA_FLAG_SCANOUT(1 << 2)
-
-#define XA_MAP_READ (1 << 0)
-#define XA_MAP_WRITE(1 << 1)
-#define XA_MAP_MAP_DIRECTLY (1 << 2)
-#define XA_MAP_UNSYNCHRONIZED   (1 << 3)
-#define XA_MAP_DONTBLOCK(1 << 4)
-#define XA_MAP_DISCARD_WHOLE_RESOURCE   (1 << 5)
-
-#define XA_ERR_NONE0
-#define XA_ERR_NORES   1
-#define XA_ERR_INVAL   2
-#define XA_ERR_BUSY3
-
-enum xa_surface_type {
-xa_type_other,
-xa_type_a,
-xa_type_argb,
-xa_type_abgr,
-xa_type_bgra,
-xa_type_z,
-xa_type_zs,
-xa_type_sz,
-xa_type_yuv_component
-};
-
-/*
- * Note that these formats should not be assumed to be binary compatible with
- * pixman formats, but with the below macros and a format type map,
- * conversion should be simple. Macros for now. We might replace with
- * inline functions.
- */
-
-#define xa_format(bpp,type,a,r,g,b)(((bpp) << 24) |  \
-((type) << 16) | \
-((a) << 12) |\
-((r) << 8) | \
-((g) << 4) | \
-((b)))
-/*
- *  Non-RGBA one- and two component formats.
- */
-
-#define xa_format_c(bpp,type,c1,c2) (((bpp) << 24) | \
-((type) << 16) | \
-((c1) << 8) |\
-((c2)))
-#define xa_format_bpp(f)   (((f) >> 24)   )
-#define xa_format_type(f)  (((f) >> 16

Re: [Mesa-dev] [PATCH v3] egl/dri2: use drm macros to construct device name

[Matt Turner]

On Wed, Apr 2, 2014 at 10:22 PM, Jonathan Gray  wrote:
> Don't hardcode /dev/dri/card0 but instead use the drm
> macros which allows the correct /dev/drm0 device to be
> opened on OpenBSD.
>
> v2: use snprintf and fallback to /dev/dri/card0
> v3: check for snprintf truncation
>
> Signed-off-by: Jonathan Gray 
> ---
>  src/egl/drivers/dri2/platform_drm.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/egl/drivers/dri2/platform_drm.c 
> b/src/egl/drivers/dri2/platform_drm.c
> index 2f7edb9..9a7633a 100644
> --- a/src/egl/drivers/dri2/platform_drm.c
> +++ b/src/egl/drivers/dri2/platform_drm.c
> @@ -492,7 +492,12 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
>
> gbm = disp->PlatformDisplay;
> if (gbm == NULL) {
> -  fd = open("/dev/dri/card0", O_RDWR);
> +  char buf[64];
> +  int n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, 0);
> +  if (n != -1 && n < sizeof(buf))

n <= sizeof(buf), right? snprintf writes up to sizeof(buf) bytes,
including the nul character.

With that fixed,

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 v2] automake: don't enable -Wl, --no-undefined on OpenBSD

[Matt Turner]

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 v3] egl/dri2: use drm macros to construct device name

[Jonathan Gray]

On Wed, Apr 02, 2014 at 11:09:09PM -0700, Matt Turner wrote:
> On Wed, Apr 2, 2014 at 10:22 PM, Jonathan Gray  wrote:
> > Don't hardcode /dev/dri/card0 but instead use the drm
> > macros which allows the correct /dev/drm0 device to be
> > opened on OpenBSD.
> >
> > v2: use snprintf and fallback to /dev/dri/card0
> > v3: check for snprintf truncation
> >
> > Signed-off-by: Jonathan Gray 
> > ---
> >  src/egl/drivers/dri2/platform_drm.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/egl/drivers/dri2/platform_drm.c 
> > b/src/egl/drivers/dri2/platform_drm.c
> > index 2f7edb9..9a7633a 100644
> > --- a/src/egl/drivers/dri2/platform_drm.c
> > +++ b/src/egl/drivers/dri2/platform_drm.c
> > @@ -492,7 +492,12 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp)
> >
> > gbm = disp->PlatformDisplay;
> > if (gbm == NULL) {
> > -  fd = open("/dev/dri/card0", O_RDWR);
> > +  char buf[64];
> > +  int n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, 0);
> > +  if (n != -1 && n < sizeof(buf))
> 
> n <= sizeof(buf), right? snprintf writes up to sizeof(buf) bytes,
> including the nul character.
> 
> With that fixed,
> 
> Reviewed-by: Matt Turner 

No, see the description from the manual page:

http://www.openbsd.org/cgi-bin/man.cgi?query=snprintf&sektion=3&format=html

 snprintf() and vsnprintf() will write at most size-1 of the characters
 printed into the output string (the size'th character then gets the
 terminating `\0'); if the return value is greater than or equal to the
 size argument, the string was too short and some of the printed
 characters were discarded.

So n == sizeof(buf) is a truncation.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: fix check for dummy renderbuffer in _mesa_FramebufferRenderbufferEXT()

[Samuel Iglesias Gonsalvez]

According to the spec:
 must be RENDERBUFFER and 
should be set to the name of the renderbuffer object to be
attached to the framebuffer.   must be either
zero or the name of an existing renderbuffer object of type
, otherwise an INVALID_OPERATION error is
generated.

This patch changes the previous returned GL_INVALID_VALUE to
GL_INVALID_OPERATION.

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

Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Anuj Phogat 
Signed-off-by: Samuel Iglesias Gonsalvez 
---
 src/mesa/main/fbobject.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 6c4f1b5..7669a0c 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2676,8 +2676,7 @@ _mesa_FramebufferRenderbuffer(GLenum target, GLenum 
attachment,
 return;
   }
   else if (rb == &DummyRenderbuffer) {
- /* This is what NVIDIA does */
-_mesa_error(ctx, GL_INVALID_VALUE,
+_mesa_error(ctx, GL_INVALID_OPERATION,
 "glFramebufferRenderbufferEXT(renderbuffer %u)",
  renderbuffer);
 return;
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] mesa: fix check for dummy renderbuffer in _mesa_FramebufferRenderbufferEXT()

[Samuel Iglesias Gonsálvez]

On Wed, 2014-04-02 at 09:45 -0700, Anuj Phogat wrote:
> On Tue, Apr 1, 2014 at 2:37 AM, Samuel Iglesias Gonsalvez
>  wrote:
> > According to the spec:
> >  must be RENDERBUFFER and 
> > should be set to the name of the renderbuffer object to be
> > attached to the framebuffer.   must be either
> > zero or the name of an existing renderbuffer object of type
> > , otherwise an INVALID_OPERATION error is
> > generated.
> >
> > This patch changes the previous returned GL_INVALID_VALUE to
> > GL_INVALID_OPERATION.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76894
> >
> > Signed-off-by: Samuel Iglesias Gonsalvez 
> I think it should be marked for stable branches using:
> Cc: mesa-sta...@lists.freedesktop.org
> 

OK, I'll resend it. 

Thanks,

Sam


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