[Mesa-dev] [Bug 80821] When LIBGL_ALWAYS_SOFTWARE is set, KHR_create_context is not supported

[bugzilla-daemon]

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

Charles Huber  changed:

   What|Removed |Added

 CC||genpfa...@gmail.com

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

Re: [Mesa-dev] [PATCH 1/2] egl/dri2: implement platform_null (v2).

[Chad Versace]

On Wed 08 Apr 2015, Frank Henigman wrote:

On Wed, Apr 8, 2015 at 1:28 AM, Chad Versace  wrote:

On Tue 07 Apr 2015, Kristian Høgsberg wrote:


On Tue, Apr 7, 2015 at 6:46 PM, Frank Henigman 
wrote:


The name "surfaceless" suits me.

Does this platform need to provide a hint to the user about buffer
format?
Platform drm does this via the EGL_NATIVE_VISUAL_ID query of
eglGetConfigAttrib(), returning a gbm format value.  Unless we do the
same or similar here, how does the user robustly find the right format
for allocating buffers?



GBM provides

int gbm_device_is_format_supported(struct gbm_device *gbm, uint32_t
format, uint32_t usage);

and you can use that to find a format that works with
GBM_BO_USE_RENDERING.



I don't think it makes sense to use EGL_NATIVE_VISUAL_ID here, so
Kristian's suggestion sounds good to me. The EGL_NATIVE_VISUAL_ID, of
course, has the same type as the native format of
EGLNativeWindowSurface. But this platform has no EGLNativeWindowSurface,
so therefore it has no EGL_NATIVE_VISUAL_ID.

On first thought, it seems like re-purposing EGL_NATIVE_VISUAL_ID for
this platform setting it to a gbm format, might be a good idea. But
ultimately I think it's a bad idea because the platform isn't tied to
gbm in any way. Today we use gbm_bo_create() to create the dma_buf
storage, but tomorrow we might use a different API that doesn't
understand gbm formats.


That's why I said "or similar."  It doesn't have to be a gbm format,
it could be a fourcc or something that the user translates to whatever
api they're using.



Am I correct in thinking the alternative is to sift through all the
gbm formats (if using gbm) to find one which satisfies
gbm_device_is_format_supported() and has the right number of alpha and
color bits?  So eglChooseConfig() does nothing for us anymore?  Will
we in fact have to be careful to find an egl config that exactly
matches the gbm format we choose?  Or should I not be calling
eglChooseConfig() at all?  I see an extension
EGL_MESA_configless_context...


Internally, this platform never uses the EGLConfig's color attributes.
So, two EGLConfigs which differ only in color attributes are effectively
identical. (It's possible that this platform never uses *any* of the
EGLConfig's attributes, but I'm not 100% sure).

Therefore it's not the EGLConfig that determines which gbm formats are
legal. Instead, it's the implementation details of the EGLImage code in
libEGL and i965_dri.so. So searching for a gbm format that matches the
EGLConfig is pointless. Instead, you need to search for gbm formats
supported by the gbm/KMS/EGLImage/GLRenderbuffer/GLTexture dance that the
gbm_bo will be used for. And I'm aware of no API to query for
those formats, unless you consider git-grep to be an API ;)

If I understand correctly, the user never needs to choose an EGLConfig
when using this platform.  See lines 291 to 295 of my Chrome OS patch
[1] that ported dEQP to this platform.

[1] 
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/649becd1761d377d9714af58f55ecc2b0d3821a2/media-gfx/deqp/files/targets-drm-Add-new-target-to-support-Chrome-OS-s-EGL-null-platform.patch


Surfaceless and configless - next step is egl-less.  (^:


EGL-less is on its way with Vulkan and its cousins :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] gallium/ttn: add TXQ support

[Rob Clark]

On Thu, Apr 9, 2015 at 3:43 PM, Rob Clark  wrote:
> From: Rob Clark 
>
> Split out from ttn_tex() since it is kind of a weird instruction that
> maps to two NIR opcodes, and it was cleaner this way.
>

as Ilia pointed out on IRC, query_levels should have no src args..
I've fixed that locally (but figured I'd wait a bit to see if there
are any other comments before I resend)

BR,
-R

> Signed-off-by: Rob Clark 
> ---
>  src/gallium/auxiliary/nir/tgsi_to_nir.c | 61 
> -
>  1 file changed, 53 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c 
> b/src/gallium/auxiliary/nir/tgsi_to_nir.c
> index c2b823c..9e0ffc2 100644
> --- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
> +++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
> @@ -1018,13 +1018,11 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest, 
> nir_ssa_def **src)
>
> unsigned src_number = 0;
>
> -   if (tgsi_inst->Instruction.Opcode != TGSI_OPCODE_TXQ) {
> -  instr->src[src_number].src =
> - nir_src_for_ssa(nir_swizzle(b, src[0], SWIZ(X, Y, Z, W),
> - instr->coord_components, false));
> -  instr->src[src_number].src_type = nir_tex_src_coord;
> -  src_number++;
> -   }
> +   instr->src[src_number].src =
> +  nir_src_for_ssa(nir_swizzle(b, src[0], SWIZ(X, Y, Z, W),
> +  instr->coord_components, false));
> +   instr->src[src_number].src_type = nir_tex_src_coord;
> +   src_number++;
>
> if (tgsi_inst->Instruction.Opcode == TGSI_OPCODE_TXP) {
>instr->src[src_number].src = nir_src_for_ssa(ttn_channel(b, src[0], 
> W));
> @@ -1063,6 +1061,50 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest, 
> nir_ssa_def **src)
> ttn_move_dest(b, dest, &instr->dest.ssa);
>  }
>
> +/* TGSI_OPCODE_TXQ is actually two distinct operations:
> + *
> + * dst.x = texture\_width(unit, lod)
> + * dst.y = texture\_height(unit, lod)
> + * dst.z = texture\_depth(unit, lod)
> + * dst.w = texture\_levels(unit)
> + *
> + * dst.xyz map to NIR txs opcode, and dst.w maps to query_levels
> + */
> +static void
> +ttn_txq(struct ttn_compile *c, nir_alu_dest dest, nir_ssa_def **src)
> +{
> +   nir_builder *b = &c->build;
> +   struct tgsi_full_instruction *tgsi_inst = &c->token->FullInstruction;
> +   nir_tex_instr *txs, *qlv;
> +
> +   txs = nir_tex_instr_create(b->shader, 1);
> +   txs->op = nir_texop_txs;
> +   setup_texture_info(txs, tgsi_inst->Texture.Texture);
> +
> +   qlv = nir_tex_instr_create(b->shader, 1);
> +   qlv->op = nir_texop_query_levels;
> +   setup_texture_info(qlv, tgsi_inst->Texture.Texture);
> +
> +   assert(tgsi_inst->Src[1].Register.File == TGSI_FILE_SAMPLER);
> +   txs->sampler_index = tgsi_inst->Src[1].Register.Index;
> +   qlv->sampler_index = tgsi_inst->Src[1].Register.Index;
> +
> +   /* only single src, the lod: */
> +   txs->src[0].src = nir_src_for_ssa(ttn_channel(b, src[0], X));
> +   txs->src[0].src_type = nir_tex_src_lod;
> +   qlv->src[0].src = nir_src_for_ssa(ttn_channel(b, src[0], X));
> +   qlv->src[0].src_type = nir_tex_src_lod;
> +
> +   nir_ssa_dest_init(&txs->instr, &txs->dest, 3, NULL);
> +   nir_instr_insert_after_cf_list(b->cf_node_list, &txs->instr);
> +
> +   nir_ssa_dest_init(&qlv->instr, &qlv->dest, 1, NULL);
> +   nir_instr_insert_after_cf_list(b->cf_node_list, &qlv->instr);
> +
> +   ttn_move_dest_masked(b, dest, &txs->dest.ssa, TGSI_WRITEMASK_XYZ);
> +   ttn_move_dest_masked(b, dest, &qlv->dest.ssa, TGSI_WRITEMASK_W);
> +}
> +
>  static const nir_op op_trans[TGSI_OPCODE_LAST] = {
> [TGSI_OPCODE_ARL] = 0,
> [TGSI_OPCODE_MOV] = nir_op_fmov,
> @@ -1386,7 +1428,6 @@ ttn_emit_instruction(struct ttn_compile *c)
> case TGSI_OPCODE_TXL:
> case TGSI_OPCODE_TXB:
> case TGSI_OPCODE_TXD:
> -   case TGSI_OPCODE_TXQ:
> case TGSI_OPCODE_TXL2:
> case TGSI_OPCODE_TXB2:
> case TGSI_OPCODE_TXQ_LZ:
> @@ -1395,6 +1436,10 @@ ttn_emit_instruction(struct ttn_compile *c)
>ttn_tex(c, dest, src);
>break;
>
> +   case TGSI_OPCODE_TXQ:
> +  ttn_txq(c, dest, src);
> +  break;
> +
> case TGSI_OPCODE_NOP:
>break;
>
> --
> 2.1.0
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 06/38] main: Removed tabs in framebuffer_texture.

[Fredrik Höglund]

Reviewed-by: Fredrik Höglund 

On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
>  src/mesa/main/fbobject.c | 49 
> 
>  1 file changed, 25 insertions(+), 24 deletions(-)
> 
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 3895328..5062033 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -2565,34 +2565,35 @@ framebuffer_texture(struct gl_context *ctx, const 
> char *caller, GLenum target,
>_mesa_tex_target_to_face(textarget) ==
>fb->Attachment[BUFFER_STENCIL].CubeMapFace &&
>zoffset == fb->Attachment[BUFFER_STENCIL].Zoffset) {
> -  /* The texture object is already attached to the stencil attachment
> -   * point. Don't create a new renderbuffer; just reuse the stencil
> -   * attachment's. This is required to prevent a GL error in
> -   * glGetFramebufferAttachmentParameteriv(GL_DEPTH_STENCIL).
> -   */
> -  reuse_framebuffer_texture_attachment(fb, BUFFER_DEPTH,
> -   BUFFER_STENCIL);
> + /* The texture object is already attached to the stencil attachment
> +  * point. Don't create a new renderbuffer; just reuse the stencil
> +  * attachment's. This is required to prevent a GL error in
> +  * glGetFramebufferAttachmentParameteriv(GL_DEPTH_STENCIL).
> +  */
> + reuse_framebuffer_texture_attachment(fb, BUFFER_DEPTH,
> +  BUFFER_STENCIL);
>} else if (attachment == GL_STENCIL_ATTACHMENT &&
> -  texObj == fb->Attachment[BUFFER_DEPTH].Texture &&
> + texObj == fb->Attachment[BUFFER_DEPTH].Texture &&
>   level == fb->Attachment[BUFFER_DEPTH].TextureLevel &&
>   _mesa_tex_target_to_face(textarget) ==
>   fb->Attachment[BUFFER_DEPTH].CubeMapFace &&
>   zoffset == fb->Attachment[BUFFER_DEPTH].Zoffset) {
> -  /* As above, but with depth and stencil transposed. */
> -  reuse_framebuffer_texture_attachment(fb, BUFFER_STENCIL,
> -   BUFFER_DEPTH);
> + /* As above, but with depth and stencil transposed. */
> + reuse_framebuffer_texture_attachment(fb, BUFFER_STENCIL,
> +  BUFFER_DEPTH);
>} else {
> -  set_texture_attachment(ctx, fb, att, texObj, textarget,
> -   level, zoffset, layered);
> -  if (attachment == GL_DEPTH_STENCIL_ATTACHMENT) {
> - /* Above we created a new renderbuffer and attached it to the
> -  * depth attachment point. Now attach it to the stencil attachment
> -  * point too.
> -  */
> - assert(att == &fb->Attachment[BUFFER_DEPTH]);
> - reuse_framebuffer_texture_attachment(fb,BUFFER_STENCIL,
> -  BUFFER_DEPTH);
> -  }
> + set_texture_attachment(ctx, fb, att, texObj, textarget,
> +level, zoffset, layered);
> +
> + if (attachment == GL_DEPTH_STENCIL_ATTACHMENT) {
> +/* Above we created a new renderbuffer and attached it to the
> + * depth attachment point. Now attach it to the stencil 
> attachment
> + * point too.
> + */
> +assert(att == &fb->Attachment[BUFFER_DEPTH]);
> +reuse_framebuffer_texture_attachment(fb,BUFFER_STENCIL,
> +BUFFER_DEPTH);
> + }
>}
>  
>/* Set the render-to-texture flag.  We'll check this flag in
> @@ -2608,8 +2609,8 @@ framebuffer_texture(struct gl_context *ctx, const char 
> *caller, GLenum target,
> else {
>remove_attachment(ctx, att);
>if (attachment == GL_DEPTH_STENCIL_ATTACHMENT) {
> -  assert(att == &fb->Attachment[BUFFER_DEPTH]);
> -  remove_attachment(ctx, &fb->Attachment[BUFFER_STENCIL]);
> + assert(att == &fb->Attachment[BUFFER_DEPTH]);
> + remove_attachment(ctx, &fb->Attachment[BUFFER_STENCIL]);
>}
> }
>  
> 

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

Re: [Mesa-dev] [PATCH 04/38] main: Rename framebuffer renderbuffer software fallback.

[Fredrik Höglund]

I don't know if we reached a consensus on the naming of fallback
functions, but I would prefer _mesa_framebuffer_renderbuffer_fallback.

With either name, this patch is:

Reviewed-by: Fredrik Höglund 

On Wednesday 04 March 2015, Laura Ekstrand wrote:
> Rename _mesa_framebuffer_renderbuffer to _mesa_FramebufferRenderbuffer_sw in
> preparation for adding the ARB_direct_state_access backend function for
> FramebufferRenderbuffer and NamedFramebufferRenderbuffer to share.
> ---
>  src/mesa/drivers/common/driverfuncs.c  | 2 +-
>  src/mesa/drivers/dri/i915/intel_fbo.c  | 2 +-
>  src/mesa/drivers/dri/nouveau/nouveau_fbo.c | 2 +-
>  src/mesa/drivers/dri/radeon/radeon_fbo.c   | 2 +-
>  src/mesa/main/fbobject.c   | 7 ---
>  src/mesa/main/fbobject.h   | 7 ---
>  src/mesa/state_tracker/st_cb_fbo.c | 2 +-
>  src/mesa/swrast/s_texrender.c  | 2 +-
>  8 files changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/src/mesa/drivers/common/driverfuncs.c 
> b/src/mesa/drivers/common/driverfuncs.c
> index 0d094dd..71c1a76 100644
> --- a/src/mesa/drivers/common/driverfuncs.c
> +++ b/src/mesa/drivers/common/driverfuncs.c
> @@ -172,7 +172,7 @@ _mesa_init_driver_functions(struct dd_function_table 
> *driver)
> driver->UnmapRenderbuffer = _swrast_unmap_soft_renderbuffer;
> driver->RenderTexture = _swrast_render_texture;
> driver->FinishRenderTexture = _swrast_finish_render_texture;
> -   driver->FramebufferRenderbuffer = _mesa_framebuffer_renderbuffer;
> +   driver->FramebufferRenderbuffer = _mesa_FramebufferRenderbuffer_sw;
> driver->ValidateFramebuffer = _mesa_validate_framebuffer;
>  
> driver->BlitFramebuffer = _swrast_BlitFramebuffer;
> diff --git a/src/mesa/drivers/dri/i915/intel_fbo.c 
> b/src/mesa/drivers/dri/i915/intel_fbo.c
> index 8ce1dbf..5b02508 100644
> --- a/src/mesa/drivers/dri/i915/intel_fbo.c
> +++ b/src/mesa/drivers/dri/i915/intel_fbo.c
> @@ -427,7 +427,7 @@ intel_framebuffer_renderbuffer(struct gl_context * ctx,
>  {
> DBG("Intel FramebufferRenderbuffer %u %u\n", fb->Name, rb ? rb->Name : 0);
>  
> -   _mesa_framebuffer_renderbuffer(ctx, fb, attachment, rb);
> +   _mesa_FramebufferRenderbuffer_sw(ctx, fb, attachment, rb);
> intel_draw_buffer(ctx);
>  }
>  
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c 
> b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> index 6c479f5..c78d4ba 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> @@ -242,7 +242,7 @@ static void
>  nouveau_framebuffer_renderbuffer(struct gl_context *ctx, struct 
> gl_framebuffer *fb,
>GLenum attachment, struct gl_renderbuffer *rb)
>  {
> - _mesa_framebuffer_renderbuffer(ctx, fb, attachment, rb);
> + _mesa_FramebufferRenderbuffer_sw(ctx, fb, attachment, rb);
>  
>   context_dirty(ctx, FRAMEBUFFER);
>  }
> diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c 
> b/src/mesa/drivers/dri/radeon/radeon_fbo.c
> index 110b030..27fa851 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_fbo.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_fbo.c
> @@ -723,7 +723,7 @@ radeon_framebuffer_renderbuffer(struct gl_context * ctx,
>   "%s(%p, fb %p, rb %p) \n",
>   __func__, ctx, fb, rb);
>  
> -   _mesa_framebuffer_renderbuffer(ctx, fb, attachment, rb);
> +   _mesa_FramebufferRenderbuffer_sw(ctx, fb, attachment, rb);
> radeon_draw_buffer(ctx, fb);
>  }
>  
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 8bc7ec7..948ac91 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -515,9 +515,10 @@ set_renderbuffer_attachment(struct gl_context *ctx,
>   * Attach a renderbuffer object to a framebuffer object.
>   */
>  void
> -_mesa_framebuffer_renderbuffer(struct gl_context *ctx,
> -   struct gl_framebuffer *fb,
> -   GLenum attachment, struct gl_renderbuffer *rb)
> +_mesa_FramebufferRenderbuffer_sw(struct gl_context *ctx,
> + struct gl_framebuffer *fb,
> + GLenum attachment,
> + struct gl_renderbuffer *rb)
>  {
> struct gl_renderbuffer_attachment *att;
>  
> diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
> index 5143743..10ae242 100644
> --- a/src/mesa/main/fbobject.h
> +++ b/src/mesa/main/fbobject.h
> @@ -82,9 +82,10 @@ _mesa_update_texture_renderbuffer(struct gl_context *ctx,
>struct gl_renderbuffer_attachment *att);
>  
>  extern void
> -_mesa_framebuffer_renderbuffer(struct gl_context *ctx,
> -   struct gl_framebuffer *fb,
> -   GLenum attachment, struct gl_renderbuffer 
> *rb);
> +_mesa_FramebufferRenderbuffer_sw(struct gl_context *ctx,
> + struct gl_framebuffer *fb,
> +   

[Mesa-dev] [PATCH 2/2] gallium/ttn: add TXQ support

[Rob Clark]

From: Rob Clark 

Split out from ttn_tex() since it is kind of a weird instruction that
maps to two NIR opcodes, and it was cleaner this way.

Signed-off-by: Rob Clark 
---
 src/gallium/auxiliary/nir/tgsi_to_nir.c | 61 -
 1 file changed, 53 insertions(+), 8 deletions(-)

diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c 
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index c2b823c..9e0ffc2 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -1018,13 +1018,11 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest, 
nir_ssa_def **src)
 
unsigned src_number = 0;
 
-   if (tgsi_inst->Instruction.Opcode != TGSI_OPCODE_TXQ) {
-  instr->src[src_number].src =
- nir_src_for_ssa(nir_swizzle(b, src[0], SWIZ(X, Y, Z, W),
- instr->coord_components, false));
-  instr->src[src_number].src_type = nir_tex_src_coord;
-  src_number++;
-   }
+   instr->src[src_number].src =
+  nir_src_for_ssa(nir_swizzle(b, src[0], SWIZ(X, Y, Z, W),
+  instr->coord_components, false));
+   instr->src[src_number].src_type = nir_tex_src_coord;
+   src_number++;
 
if (tgsi_inst->Instruction.Opcode == TGSI_OPCODE_TXP) {
   instr->src[src_number].src = nir_src_for_ssa(ttn_channel(b, src[0], W));
@@ -1063,6 +1061,50 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest, 
nir_ssa_def **src)
ttn_move_dest(b, dest, &instr->dest.ssa);
 }
 
+/* TGSI_OPCODE_TXQ is actually two distinct operations:
+ *
+ * dst.x = texture\_width(unit, lod)
+ * dst.y = texture\_height(unit, lod)
+ * dst.z = texture\_depth(unit, lod)
+ * dst.w = texture\_levels(unit)
+ *
+ * dst.xyz map to NIR txs opcode, and dst.w maps to query_levels
+ */
+static void
+ttn_txq(struct ttn_compile *c, nir_alu_dest dest, nir_ssa_def **src)
+{
+   nir_builder *b = &c->build;
+   struct tgsi_full_instruction *tgsi_inst = &c->token->FullInstruction;
+   nir_tex_instr *txs, *qlv;
+
+   txs = nir_tex_instr_create(b->shader, 1);
+   txs->op = nir_texop_txs;
+   setup_texture_info(txs, tgsi_inst->Texture.Texture);
+
+   qlv = nir_tex_instr_create(b->shader, 1);
+   qlv->op = nir_texop_query_levels;
+   setup_texture_info(qlv, tgsi_inst->Texture.Texture);
+
+   assert(tgsi_inst->Src[1].Register.File == TGSI_FILE_SAMPLER);
+   txs->sampler_index = tgsi_inst->Src[1].Register.Index;
+   qlv->sampler_index = tgsi_inst->Src[1].Register.Index;
+
+   /* only single src, the lod: */
+   txs->src[0].src = nir_src_for_ssa(ttn_channel(b, src[0], X));
+   txs->src[0].src_type = nir_tex_src_lod;
+   qlv->src[0].src = nir_src_for_ssa(ttn_channel(b, src[0], X));
+   qlv->src[0].src_type = nir_tex_src_lod;
+
+   nir_ssa_dest_init(&txs->instr, &txs->dest, 3, NULL);
+   nir_instr_insert_after_cf_list(b->cf_node_list, &txs->instr);
+
+   nir_ssa_dest_init(&qlv->instr, &qlv->dest, 1, NULL);
+   nir_instr_insert_after_cf_list(b->cf_node_list, &qlv->instr);
+
+   ttn_move_dest_masked(b, dest, &txs->dest.ssa, TGSI_WRITEMASK_XYZ);
+   ttn_move_dest_masked(b, dest, &qlv->dest.ssa, TGSI_WRITEMASK_W);
+}
+
 static const nir_op op_trans[TGSI_OPCODE_LAST] = {
[TGSI_OPCODE_ARL] = 0,
[TGSI_OPCODE_MOV] = nir_op_fmov,
@@ -1386,7 +1428,6 @@ ttn_emit_instruction(struct ttn_compile *c)
case TGSI_OPCODE_TXL:
case TGSI_OPCODE_TXB:
case TGSI_OPCODE_TXD:
-   case TGSI_OPCODE_TXQ:
case TGSI_OPCODE_TXL2:
case TGSI_OPCODE_TXB2:
case TGSI_OPCODE_TXQ_LZ:
@@ -1395,6 +1436,10 @@ ttn_emit_instruction(struct ttn_compile *c)
   ttn_tex(c, dest, src);
   break;
 
+   case TGSI_OPCODE_TXQ:
+  ttn_txq(c, dest, src);
+  break;
+
case TGSI_OPCODE_NOP:
   break;
 
-- 
2.1.0

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

[Mesa-dev] [PATCH 1/2] gallium/ttn: split out helper to get texture info

[Rob Clark]

From: Rob Clark 

We'll need this as well for TXQ.  Split this out first to reduce noise
in the next patch.

Signed-off-by: Rob Clark 
---
 src/gallium/auxiliary/nir/tgsi_to_nir.c | 112 +---
 1 file changed, 59 insertions(+), 53 deletions(-)

diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c 
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 648ac6f..c2b823c 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -864,58 +864,9 @@ ttn_endloop(struct ttn_compile *c)
 }
 
 static void
-ttn_tex(struct ttn_compile *c, nir_alu_dest dest, nir_ssa_def **src)
+setup_texture_info(nir_tex_instr *instr, unsigned texture)
 {
-   nir_builder *b = &c->build;
-   struct tgsi_full_instruction *tgsi_inst = &c->token->FullInstruction;
-   nir_tex_instr *instr;
-   nir_texop op;
-   unsigned num_srcs;
-
-   switch (tgsi_inst->Instruction.Opcode) {
-   case TGSI_OPCODE_TEX:
-  op = nir_texop_tex;
-  num_srcs = 1;
-  break;
-   case TGSI_OPCODE_TXP:
-  op = nir_texop_tex;
-  num_srcs = 2;
-  break;
-   case TGSI_OPCODE_TXB:
-  op = nir_texop_txb;
-  num_srcs = 2;
-  break;
-   case TGSI_OPCODE_TXL:
-  op = nir_texop_txl;
-  num_srcs = 2;
-  break;
-   case TGSI_OPCODE_TXF:
-  op = nir_texop_txf;
-  num_srcs = 1;
-  break;
-   case TGSI_OPCODE_TXD:
-  op = nir_texop_txd;
-  num_srcs = 3;
-  break;
-   default:
-  fprintf(stderr, "unknown TGSI tex op %d\n", 
tgsi_inst->Instruction.Opcode);
-  abort();
-   }
-
-   if (tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOW1D ||
-   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOW1D_ARRAY ||
-   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOW2D ||
-   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOW2D_ARRAY ||
-   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOWRECT ||
-   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOWCUBE ||
-   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOWCUBE_ARRAY) {
-  num_srcs++;
-   }
-
-   instr = nir_tex_instr_create(b->shader, num_srcs);
-   instr->op = op;
-
-   switch (tgsi_inst->Texture.Texture) {
+   switch (texture) {
case TGSI_TEXTURE_1D:
   instr->sampler_dim = GLSL_SAMPLER_DIM_1D;
   break;
@@ -982,10 +933,65 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest, 
nir_ssa_def **src)
   instr->is_shadow = true;
   break;
default:
-  fprintf(stderr, "Unknown TGSI texture target %d\n",
-  tgsi_inst->Texture.Texture);
+  fprintf(stderr, "Unknown TGSI texture target %d\n", texture);
   abort();
}
+}
+
+static void
+ttn_tex(struct ttn_compile *c, nir_alu_dest dest, nir_ssa_def **src)
+{
+   nir_builder *b = &c->build;
+   struct tgsi_full_instruction *tgsi_inst = &c->token->FullInstruction;
+   nir_tex_instr *instr;
+   nir_texop op;
+   unsigned num_srcs;
+
+   switch (tgsi_inst->Instruction.Opcode) {
+   case TGSI_OPCODE_TEX:
+  op = nir_texop_tex;
+  num_srcs = 1;
+  break;
+   case TGSI_OPCODE_TXP:
+  op = nir_texop_tex;
+  num_srcs = 2;
+  break;
+   case TGSI_OPCODE_TXB:
+  op = nir_texop_txb;
+  num_srcs = 2;
+  break;
+   case TGSI_OPCODE_TXL:
+  op = nir_texop_txl;
+  num_srcs = 2;
+  break;
+   case TGSI_OPCODE_TXF:
+  op = nir_texop_txf;
+  num_srcs = 1;
+  break;
+   case TGSI_OPCODE_TXD:
+  op = nir_texop_txd;
+  num_srcs = 3;
+  break;
+
+   default:
+  fprintf(stderr, "unknown TGSI tex op %d\n", 
tgsi_inst->Instruction.Opcode);
+  abort();
+   }
+
+   if (tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOW1D ||
+   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOW1D_ARRAY ||
+   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOW2D ||
+   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOW2D_ARRAY ||
+   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOWRECT ||
+   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOWCUBE ||
+   tgsi_inst->Texture.Texture == TGSI_TEXTURE_SHADOWCUBE_ARRAY) {
+  num_srcs++;
+   }
+
+   instr = nir_tex_instr_create(b->shader, num_srcs);
+   instr->op = op;
+
+   setup_texture_info(instr, tgsi_inst->Texture.Texture);
 
switch (instr->sampler_dim) {
case GLSL_SAMPLER_DIM_1D:
-- 
2.1.0

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

Re: [Mesa-dev] [PATCH 05/38] main: Add entry point for NamedFramebufferRenderbuffer.

[Fredrik Höglund]

On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
>  src/mapi/glapi/gen/ARB_direct_state_access.xml |   7 ++
>  src/mesa/main/fbobject.c   | 139 
> +
>  src/mesa/main/fbobject.h   |  12 +++
>  src/mesa/main/tests/dispatch_sanity.cpp|   1 +
>  4 files changed, 115 insertions(+), 44 deletions(-)
> 
> diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml 
> b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> index 85ef1f6..b954343 100644
> --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> @@ -118,6 +118,13 @@
>
> 
>  
> +   
> +  
> +  
> +  
> +  
> +   
> +
> 
>  
> 
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 948ac91..3895328 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -2748,71 +2748,37 @@ _mesa_FramebufferTexture(GLenum target, GLenum 
> attachment,
>  }
>  
>  
> -void GLAPIENTRY
> -_mesa_FramebufferRenderbuffer(GLenum target, GLenum attachment,
> -  GLenum renderbufferTarget,
> -  GLuint renderbuffer)
> +void
> +_mesa_framebuffer_renderbuffer(struct gl_context *ctx,
> +   struct gl_framebuffer *fb,
> +   GLenum attachment,
> +   struct gl_renderbuffer *rb,
> +   const char *func)
>  {
> struct gl_renderbuffer_attachment *att;
> -   struct gl_framebuffer *fb;
> -   struct gl_renderbuffer *rb;
> -   GET_CURRENT_CONTEXT(ctx);
> -
> -   fb = get_framebuffer_target(ctx, target);
> -   if (!fb) {
> -  _mesa_error(ctx, GL_INVALID_ENUM,
> -  "glFramebufferRenderbuffer(target)");
> -  return;
> -   }
> -
> -   if (renderbufferTarget != GL_RENDERBUFFER_EXT) {
> -  _mesa_error(ctx, GL_INVALID_ENUM,
> -  "glFramebufferRenderbuffer(renderbufferTarget)");
> -  return;
> -   }
>  
> if (_mesa_is_winsys_fbo(fb)) {
>/* Can't attach new renderbuffers to a window system framebuffer */
> -  _mesa_error(ctx, GL_INVALID_OPERATION, "glFramebufferRenderbuffer");
> +  _mesa_error(ctx, GL_INVALID_OPERATION,
> +  "%s(default framebuffer bound)", func);
>return;
> }
>  
> att = get_attachment(ctx, fb, attachment);
> if (att == NULL) {
>_mesa_error(ctx, GL_INVALID_ENUM,
> -  "glFramebufferRenderbuffer(invalid attachment %s)",
> +  "%s(invalid attachment %s)", func,
>_mesa_lookup_enum_by_nr(attachment));
>return;
> }
>  
> -   if (renderbuffer) {
> -  rb = _mesa_lookup_renderbuffer(ctx, renderbuffer);
> -  if (!rb) {
> -  _mesa_error(ctx, GL_INVALID_OPERATION,
> -  "glFramebufferRenderbuffer(non-existant"
> - " renderbuffer %u)", renderbuffer);
> -  return;
> -  }
> -  else if (rb == &DummyRenderbuffer) {
> -  _mesa_error(ctx, GL_INVALID_OPERATION,
> -  "glFramebufferRenderbuffer(renderbuffer %u)",
> - renderbuffer);
> -  return;
> -  }
> -   }
> -   else {
> -  /* remove renderbuffer attachment */
> -  rb = NULL;
> -   }
> -
> if (attachment == GL_DEPTH_STENCIL_ATTACHMENT &&
> rb && rb->Format != MESA_FORMAT_NONE) {
>/* make sure the renderbuffer is a depth/stencil format */
>const GLenum baseFormat = _mesa_get_format_base_format(rb->Format);
>if (baseFormat != GL_DEPTH_STENCIL) {
>   _mesa_error(ctx, GL_INVALID_OPERATION,
> - "glFramebufferRenderbuffer(renderbuffer"
> - " is not DEPTH_STENCIL format)");
> + "%s(renderbuffer is not DEPTH_STENCIL format)", func);
>   return;
>}
> }
> @@ -2828,6 +2794,91 @@ _mesa_FramebufferRenderbuffer(GLenum target, GLenum 
> attachment,
> _mesa_update_framebuffer_visual(ctx, fb);
>  }
>  
> +void GLAPIENTRY
> +_mesa_FramebufferRenderbuffer(GLenum target, GLenum attachment,
> +  GLenum renderbuffertarget,
> +  GLuint renderbuffer)
> +{
> +   struct gl_framebuffer *fb;
> +   struct gl_renderbuffer *rb;
> +   GET_CURRENT_CONTEXT(ctx);
> +
> +   fb = get_framebuffer_target(ctx, target);
> +   if (!fb) {
> +  _mesa_error(ctx, GL_INVALID_ENUM,
> +  "glFramebufferRenderbuffer(invalid target %s)",
> +  _mesa_lookup_enum_by_nr(target));
> +  return;
> +   }
> +
> +   if (renderbuffertarget != GL_RENDERBUFFER_EXT) {
> +  _mesa_error(ctx, GL_INVALID_ENUM,
> +  "glFramebufferRenderbuffer(renderbuffer target is not "
> +  "GL_RENDERBUFFER)");
> +  return;
> +   }
> +
> +   if (renderbuffer) {
> +  rb = _mesa_lookup_renderbuffer_err(ctx, renderbuffer,
> 

Re: [Mesa-dev] [PATCH 02/38] main: Add glCreateFramebuffers.

[Fredrik Höglund]

There should probably be two empty lines between the functions, but
aside from that nitpick, this patch is:

Reviewed-by: Fredrik Höglund 

On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
>  src/mapi/glapi/gen/ARB_direct_state_access.xml |  7 +
>  src/mesa/main/fbobject.c   | 40 
> ++
>  src/mesa/main/fbobject.h   |  3 ++
>  src/mesa/main/tests/dispatch_sanity.cpp|  1 +
>  4 files changed, 46 insertions(+), 5 deletions(-)
> 
> diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml 
> b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> index 641e68f..85ef1f6 100644
> --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> @@ -111,6 +111,13 @@
>
> 
>  
> +   
> +
> +   
> +  
> +  
> +   
> +
> 
>  
> 
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 8c2eb25..b361967 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -2274,15 +2274,23 @@ _mesa_DeleteFramebuffers(GLsizei n, const GLuint 
> *framebuffers)
>  }
>  
>  
> -void GLAPIENTRY
> -_mesa_GenFramebuffers(GLsizei n, GLuint *framebuffers)
> +/**
> + * This is the implementation for glGenFramebuffers and glCreateFramebuffers.
> + * It is not exposed to the rest of Mesa to encourage the use of
> + * nameless buffers in driver internals.
> + */
> +static void
> +create_framebuffers(GLsizei n, GLuint *framebuffers, bool dsa)
>  {
> GET_CURRENT_CONTEXT(ctx);
> GLuint first;
> GLint i;
> +   struct gl_framebuffer *fb;
> +
> +   const char *func = dsa ? "glCreateFramebuffers" : "glGenFramebuffers";
>  
> if (n < 0) {
> -  _mesa_error(ctx, GL_INVALID_VALUE, "glGenFramebuffersEXT(n)");
> +  _mesa_error(ctx, GL_INVALID_VALUE, "%s(n < 0)", func);
>return;
> }
>  
> @@ -2294,13 +2302,35 @@ _mesa_GenFramebuffers(GLsizei n, GLuint *framebuffers)
> for (i = 0; i < n; i++) {
>GLuint name = first + i;
>framebuffers[i] = name;
> -  /* insert dummy placeholder into hash table */
> +
> +  if (dsa) {
> + fb = ctx->Driver.NewFramebuffer(ctx, framebuffers[i]);
> + if (!fb) {
> +_mesa_error(ctx, GL_OUT_OF_MEMORY, "%s", func);
> +return;
> + }
> +  }
> +  else
> + fb = &DummyFramebuffer;
> +
>mtx_lock(&ctx->Shared->Mutex);
> -  _mesa_HashInsert(ctx->Shared->FrameBuffers, name, &DummyFramebuffer);
> +  _mesa_HashInsert(ctx->Shared->FrameBuffers, name, fb);
>mtx_unlock(&ctx->Shared->Mutex);
> }
>  }
>  
> +void GLAPIENTRY
> +_mesa_GenFramebuffers(GLsizei n, GLuint *framebuffers)
> +{
> +   create_framebuffers(n, framebuffers, false);
> +}
> +
> +void GLAPIENTRY
> +_mesa_CreateFramebuffers(GLsizei n, GLuint *framebuffers)
> +{
> +   create_framebuffers(n, framebuffers, true);
> +}
> +
>  
>  GLenum GLAPIENTRY
>  _mesa_CheckFramebufferStatus(GLenum target)
> diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
> index 7aa5205..6bd8968 100644
> --- a/src/mesa/main/fbobject.h
> +++ b/src/mesa/main/fbobject.h
> @@ -153,6 +153,9 @@ _mesa_DeleteFramebuffers(GLsizei n, const GLuint 
> *framebuffers);
>  extern void GLAPIENTRY
>  _mesa_GenFramebuffers(GLsizei n, GLuint *framebuffers);
>  
> +extern void GLAPIENTRY
> +_mesa_CreateFramebuffers(GLsizei n, GLuint *framebuffers);
> +
>  extern GLenum GLAPIENTRY
>  _mesa_CheckFramebufferStatus(GLenum target);
>  
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index 69fb8d0..ee8b20f 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -970,6 +970,7 @@ const struct function gl_core_functions_possible[] = {
> { "glGetNamedBufferParameteri64v", 45, -1 },
> { "glGetNamedBufferPointerv", 45, -1 },
> { "glGetNamedBufferSubData", 45, -1 },
> +   { "glCreateFramebuffers", 45, -1 },
> { "glCreateTextures", 45, -1 },
> { "glTextureStorage1D", 45, -1 },
> { "glTextureStorage2D", 45, -1 },
> 

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

Re: [Mesa-dev] [PATCH 01/38] main: Add utility function _mesa_lookup_framebuffer_err.

[Fredrik Höglund]

On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
>  src/mesa/main/fbobject.c | 18 ++
>  src/mesa/main/fbobject.h |  4 
>  2 files changed, 22 insertions(+)
> 
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index f8d0d92..8c2eb25 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -136,6 +136,24 @@ _mesa_lookup_framebuffer(struct gl_context *ctx, GLuint 
> id)
> return fb;
>  }
>  
> +/**
> + * A convenience function for direct state access that throws
> + * GL_INVALID_OPERATION if the framebuffer id is not found in the hash table.
> + */
> +struct gl_framebuffer *
> +_mesa_lookup_framebuffer_err(struct gl_context *ctx, GLuint id,
> + const char *func)
> +{
> +   struct gl_framebuffer *fb;
> +
> +   fb = _mesa_lookup_framebuffer(ctx, id);
> +   if (!fb)
> +  _mesa_error(ctx, GL_INVALID_OPERATION,
> +  "%s(non-generated framebuffer name=%u)", func, id);
> +
> +   return fb;
> +}
> +

I think this function should also generate GL_INVALID_OPERATION when
the looked-up framebuffer is DummyFramebuffer.

All the DSA entry points require that the framebuffer exists.

>  /**
>   * Mark the given framebuffer as invalid.  This will force the
> diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
> index 77fdef4..7aa5205 100644
> --- a/src/mesa/main/fbobject.h
> +++ b/src/mesa/main/fbobject.h
> @@ -67,6 +67,10 @@ _mesa_lookup_renderbuffer(struct gl_context *ctx, GLuint 
> id);
>  extern struct gl_framebuffer *
>  _mesa_lookup_framebuffer(struct gl_context *ctx, GLuint id);
>  
> +extern struct gl_framebuffer *
> +_mesa_lookup_framebuffer_err(struct gl_context *ctx, GLuint id,
> + const char *func);
> +
>  
>  void
>  _mesa_update_texture_renderbuffer(struct gl_context *ctx,
> 

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

Re: [Mesa-dev] Problem with LLVM on Windows with MSVC

[Jose Fonseca]

Please read http://mesa3d.org/llvmpipe.html , "Requirements" sections. 
It's explained there how to tell which runtime to use when building LLVM.



That said, you probably want to pass build=release to scons command. As 
SCons defaults to debug build.



  scons build=release ...

Jose

On 09/04/15 00:56, Shervin Sharifi wrote:

Hi,

  I'm trying to build mesa on windows (MSVC) with gles support and with
llvm.
  Here are the keys I'm using:
scons.py gles=yes llvm=yes platform=windows libgl-gd






  I'm getting a bunch of errors like this:

LLVMCore.lib(ValueSymbolTable.obj) : error LNK2038: mismatch detected
for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value
'MTd_StaticDebug' in mesa.lib(uniform_query.obj)

I understand that this is due to mismatch between the runtime libraries,
but I don't know how to fix it.
Should I change the CRT in llvm or in mesa? How should I do that?

  Thanks,
  Shervin






___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=KTTb8Ykw0ja-wsBAAPvp7jv_sppo7ThcnDLxHaXB7s8&s=oc-YGazUbTj3OrCR3n8zLns2F3oa2KLKHl-G7ocuu6U&e=



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

Re: [Mesa-dev] [PATCH 10/12] nir: Store num_direct_uniforms in the nir_shader.

[Jason Ekstrand]

On Wed, Apr 8, 2015 at 12:48 PM, Ian Romanick  wrote:
> On 04/08/2015 12:06 AM, Kenneth Graunke wrote:
>> Storing this here is pretty sketchy - I don't know if any driver other
>> than i965 will want to use it.  But this will make it a lot easier to
>> generate NIR code at link time.  We'll probably rework it anyway.
>>
>> Signed-off-by: Kenneth Graunke 
>> ---
>>  src/glsl/nir/nir.h   | 3 +++
>>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 5 +++--
>>  2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
>> index e844e4d..7d11996 100644
>> --- a/src/glsl/nir/nir.h
>> +++ b/src/glsl/nir/nir.h
>> @@ -1429,6 +1429,9 @@ typedef struct nir_shader {
>>  * access plus one
>>  */
>> unsigned num_inputs, num_uniforms, num_outputs;
>> +
>> +   /** the number of uniforms that are only accessed directly */
>> +   unsigned num_direct_uniforms;
>>  } nir_shader;
>>
>>  #define nir_foreach_overload(shader, overload)\
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
>> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> index 145a447..034b79a 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> @@ -120,7 +120,7 @@ fs_visitor::emit_nir_code()
>>
>> if (shader_prog) {
>>nir_assign_var_locations_scalar_direct_first(nir, &nir->uniforms,
>> -   &num_direct_uniforms,
>> +   
>> &nir->num_direct_uniforms,
>> &nir->num_uniforms);
>
> Why not just have nir_assign_var_locations_scalar_direct_first modify
> the nir_shader passed in?  That seems more concise.

We could, but I'm not a huge fan of storing it in the nir_shader to
begin with.  As I said in my review, it's a hack I'm willing to go
with for now.  However, since we made variable location assignment
separate from lowering, they are no longer a universal thing.  We
could also potentially have backend-specific assignment passes and I
really don't want to set a precedent of storing this data in
nir_shader.  I'm hoping (maybe foolishly) that we'll come up with a
better place to store them soon.
--Jason

>> } else {
>>/* ARB programs generally create a giant array of "uniform" data, and 
>> allow
>> @@ -128,7 +128,7 @@ fs_visitor::emit_nir_code()
>> * analysis, it's all or nothing.  num_direct_uniforms is only useful 
>> when
>> * we have some direct and some indirect access; it doesn't matter 
>> here.
>> */
>> -  num_direct_uniforms = 0;
>> +  nir->num_direct_uniforms = 0;
>> }
>> nir_assign_var_locations_scalar(&nir->inputs, &nir->num_inputs);
>> nir_assign_var_locations_scalar(&nir->outputs, &nir->num_outputs);
>> @@ -343,6 +343,7 @@ void
>>  fs_visitor::nir_setup_uniforms(nir_shader *shader)
>>  {
>> uniforms = shader->num_uniforms;
>> +   num_direct_uniforms = shader->num_direct_uniforms;
>>
>> /* We split the uniform register file in half.  The first half is
>>  * entirely direct uniforms.  The second half is indirect.
>>
>
> ___
> 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 03/23] i965/fs: Use MOV.nz instead of AND.nz to generate flag on GEN6+

[Ian Romanick]

On 04/06/2015 11:35 AM, Matt Turner wrote:
> On Fri, Mar 20, 2015 at 1:58 PM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> On SNB+, the Boolean result is always 0 or ~0, so MOV.nz produces the
>> same effect as AND.nz.  However, later cmod propagation passes can
>> handle the MOV.nz, but they cannot handle the AND.nz because the source
>> is not generated by a CMP.
>>
>> It's worth noting that this commit was a lot more effective before
>> commit bb22aa0 (i965/fs: Ignore type in cmod prop if scan_inst is CMP.).
>> Without that commit, this commit improved ~2,500 shaders on each
>> affected platform, including Sandy Bridge.
>>
>> Ivy Bridge (0x0166):
>> total instructions in shared programs: 6291794 -> 6291668 (-0.00%)
>> instructions in affected programs: 41207 -> 41081 (-0.31%)
>> helped:154
>> HURT:  28
>>
>> Haswell (0x0426):
>> total instructions in shared programs: 5779180 -> 5779054 (-0.00%)
>> instructions in affected programs: 37210 -> 37084 (-0.34%)
>> helped:154
>> HURT:  28
>>
>> Broadwell (0x162E):
>> total instructions in shared programs: 6823014 -> 6822848 (-0.00%)
>> instructions in affected programs: 40195 -> 40029 (-0.41%)
>> helped:164
>> HURT:  28
>>
>> No change on GM45, Iron Lake, Sandy Bridge, Ivy Bridge with NIR, or
>> Haswell with NIR.
>>
>> Signed-off-by: Ian Romanick 
>> ---
> 
> I looked at some helped shaders. They seem to be doing this:
> 
> const vec4 ps_c0 = vec4(1.0, -1.0, 0.0, -0.0);
> ...
> t0_ps.x = (gl_FrontFacing ? ps_c0.x : ps_c0.y);
> t0_ps.y = (gl_FrontFacing ? ps_c0.w : ps_c0.y);
> t0_ps.x = ((-t0_ps.x >= 0.0) ? ps_c0.z : ps_c0.x);
> 
> so before this patch we hit the
> fs_visitor::try_opt_frontfacing_ternary path for t0_ps.x and not for
> t0_ps.y, generating:
> 
> asr(8)  g26<1>D -g0<0,1,0>W 15D
> or(8)   g36.1<2>W   g0<0,1,0>W  0x3f80UW
> mov(1)  g25<1>F [0F, 0F, 0F, 0F]VF
> and.nz.f0(8)nullg26<8,8,1>D 1D<--- this gets
> removed with this patch
> and(8)  g35<1>D g36<8,8,1>D 0xbf80UD
> mov(8)  g38<1>F -g25<0,1,0>F
> mov(8)  g40<1>F g25<0,1,0>F
> (+f0) sel(8)g37<1>F g38<8,8,1>F -1F
> cmp.ge.f0(8)null-g35<8,8,1>Fg25<0,1,0>F
> (+f0) sel(8)g39<1>F g40<8,8,1>F 1F
> 
> After this patch we generate
> asr.nz.f0(8)null-g0<0,1,0>W 15D
> or(8)   g35.1<2>W   g0<0,1,0>W  0x3f80UW
> mov(1)  g25<1>F [0F, 0F, 0F, 0F]VF
> and(8)  g34<1>D g35<8,8,1>D 0xbf80UD
> mov(8)  g37<1>F -g25<0,1,0>F
> mov(8)  g39<1>F g25<0,1,0>F
> (+f0) sel(8)g36<1>F g37<8,8,1>F -1F
> cmp.ge.f0(8)null-g34<8,8,1>Fg25<0,1,0>F
> (+f0) sel(8)g38<1>F g39<8,8,1>F 1F
> 
> 10 instructions to 9. That's an annoying amount of assembly to digest,
> but basically we're just benefiting because of the order the uses of
> the flag. If we could simply rearrange the flag writes and reads, we
> would generate better code, and...

Removing this at the end of the series affects quite a few shaders in
all GEN6+, non-NIR runs:

total instructions in shared programs: 7268653 -> 7270887 (0.03%)
instructions in affected programs: 408532 -> 410766 (0.55%)
helped:31
HURT:  2265

My current guess is that "glsl: Optimize certain if-statements to
ir_triop_csel" makes a boatload more opportunities for this accidental
optimization.

> If we could recognize that there are multiple gl_FrontFacing ? ... :
> ... expressions, we probably would have just emitted asr.nz.f0 and a
> couple of SELs.

The weird thing is that both uses of gl_FrontFacing don't get the asr
treatment...  It's also weird that this code doesn't change after
"i965/fs: Optimize gl_FrontFacing used alone as a condition"

> So I don't really think this patch is helping anything except by accident. :)


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

Re: [Mesa-dev] Problem with LLVM on Windows with MSVC

[Shervin Sharifi]

Thank you.
I have compiled llvm with /MDd options, but Mesa doesn't accept that and
asks for /MTd.
So I compiled llvm with /MTd and it worked.
However, I prefer to change Mesa to dynamic option, but I don't know how to
do that. I tried the following, but got another error:

The only thing I found is this in the scons\gallium.py:
if env['platform'] == 'windows' and msvc:
# Choose the appropriate MSVC CRT
# http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
if env['build'] in ('debug', 'checked'):
env.Append(CCFLAGS = ['/MTd'])
env.Append(SHCCFLAGS = ['/LDd'])
else:
env.Append(CCFLAGS = ['/MT'])
env.Append(SHCCFLAGS = ['/LD'])

I changed the /MTd to /MDd and compiled. I got the following error, so I'm
not sure if this is the right way of doing it.

src\glsl\ir_constant_expression.cpp(57) : error C2491: 'copysign' :
definition of dllimport function not allowed

Thanks,
Shervin

P.S. You're right Marius. It was a typo. I missed the i at the end when
copying the command line ("gd" instead of "gdi").


On Thu, Apr 9, 2015 at 9:42 AM, Predut, Marius 
wrote:

>  Indeed seems you have some incompatible libraries (one build static and
> other dynamic –dll)
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=732124
>
> but what suppose `libgl-gd' target? Is this a typo mismatch?
>
> Try to build llvm in a dynamic mode , may be it will solve your problems
>
>
>
> marius
>
>
>
>
>
> *From:* mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] *On
> Behalf Of *Shervin Sharifi
> *Sent:* Thursday, April 09, 2015 2:57 AM
> *To:* mesa-dev@lists.freedesktop.org
> *Subject:* [Mesa-dev] Problem with LLVM on Windows with MSVC
>
>
>
> Hi,
>
>
>
>  I'm trying to build mesa on windows (MSVC) with gles support and with
> llvm.
>
>  Here are the keys I'm using:
>
> scons.py gles=yes llvm=yes platform=windows libgl-gd
>
>
>
>  I'm getting a bunch of errors like this:
>
>
>
> LLVMCore.lib(ValueSymbolTable.obj) : error LNK2038: mismatch detected for
> 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value
> 'MTd_StaticDebug' in mesa.lib(uniform_query.obj)
>
>
>
> I understand that this is due to mismatch between the runtime libraries,
> but I don't know how to fix it.
>
> Should I change the CRT in llvm or in mesa? How should I do that?
>
>
>
>  Thanks,
>
>  Shervin
>
>
>
>
>
>
>
>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] i965/vs: Allow CSE to handle MULs with negated arguments.

[Ian Romanick]

On 04/09/2015 09:37 AM, Matt Turner wrote:
> On Wed, Apr 8, 2015 at 4:38 PM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> This is similar to commit (47c4b38: i965/fs: Allow CSE to handle MULs
>> with negated arguments.), but it uses a slightly different approach.
> 
> Just repeating myself... I don't know why this is different if it
> doesn't do something more. Anyway,

Readability and extensibility.  Keeping the "are these negated
operations" and "do negated operands produce the same result" logic
separate, it's easier to see what's going on, and it's easier to add to
it later.

It also matched the way I did the (currently NAK'ed) changes at the GLSL
level, so my brain was already in that space.

> Reviewed-by: Matt Turner 

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

[Mesa-dev] [Bug 89963] lp_bld_debug.cpp:100:31: error: no matching function for call to ‘llvm?=::raw ostream::raw ostream()=?UTF-8?Q?’

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

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

--- Comment #2 from Vinson Lee  ---
commit 50e9fa2ed69cb5f76f66231976ea789c0091a64d
Author: Vinson Lee 
Date:   Wed Apr 8 22:51:57 2015 -0700

gallivm: Fix build since llvm-3.7.0svn r234460.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89963
Signed-off-by: Vinson Lee 
Reviewed-by: Tom Stellard 

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

Re: [Mesa-dev] [PATCH 3/5] i965/vs: Add src_reg::negative_equals method

[Ian Romanick]

On 04/09/2015 09:31 AM, Matt Turner wrote:
> On Wed, Apr 8, 2015 at 4:38 PM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> This method is similar to the existing ::equals method.  Instead of
>> testing that two src_regs are equal to each other, it tests that one is
>> the negation of the other.
>>
>> Signed-off-by: Ian Romanick 
>> ---
>>  src/mesa/drivers/dri/i965/brw_ir_vec4.h |  1 +
>>  src/mesa/drivers/dri/i965/brw_vec4.cpp  | 43 
>> +
>>  2 files changed, 44 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_ir_vec4.h 
>> b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
>> index d3bd64d..449795a 100644
>> --- a/src/mesa/drivers/dri/i965/brw_ir_vec4.h
>> +++ b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
>> @@ -49,6 +49,7 @@ public:
>> src_reg(struct brw_reg reg);
>>
>> bool equals(const src_reg &r) const;
>> +   bool negative_equals(const src_reg &r) const;
>>
>> src_reg(class vec4_visitor *v, const struct glsl_type *type);
>> src_reg(class vec4_visitor *v, const struct glsl_type *type, int size);
>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
>> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> index ef2fd40..d5286c2 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> @@ -328,6 +328,49 @@ src_reg::equals(const src_reg &r) const
>>  }
>>
>>  bool
>> +src_reg::negative_equals(const src_reg &r) const
>> +{
>> +   if (file != r.file)
>> +  return false;
>> +
>> +   if (file == IMM) {
>> +  if (!(reg == r.reg &&
>> +reg_offset == r.reg_offset &&
>> +type == r.type &&
>> +negate == r.negate &&
>> +abs == r.abs &&
>> +swizzle == r.swizzle &&
>> +!reladdr && !r.reladdr))
> 
> I would have applied DeMorgan's Law and made this a series of ORs.

I used copy-and-paste w/minimal changes. :)  I can change it easily enough.

>> + return false;
>> +
>> +  switch (fixed_hw_reg.type) {
> 
> I don't think we keep fixed_hw_reg.type in sync with src_reg's type.
> (Another reason to move towards a brw_reg-based register model)

Yes... that aspect was pretty confusing.  It looked like the same
information was tracked in several places just for fun.  I don't know
whether it's good news or bad news, but jenkins was still happy with
this change.

> Looking at the constructors for immediate, this appears to be the
> case. Just changing this to switch (type) should do the trick.
> 
>> +  case BRW_REGISTER_TYPE_F:
>> + return memcmp(&fixed_hw_reg, &r.fixed_hw_reg,
>> +   sizeof(fixed_hw_reg) - sizeof(fixed_hw_reg.dw1)) == 
>> 0 &&
>> +fixed_hw_reg.dw1.f == -r.fixed_hw_reg.dw1.f;
> 
> I don't think you need the memcmp. For immediates, we really just use
> the fixed_hw_reg for the immediate storage itself and none of the
> other metadata.

Okay.  That wasn't 100% clear in the rest of the code.  I was also
basing this on the src_reg::equals method which does a memcmp of the
whole thing.

Note that this doesn't handle VF constants.  I assume I just need to add
a BRW_REGISTER_TYPE_VF case and compare like

swizzle == r.swizzle &&
fixed_hw_reg.dw1.u == (r.fixed_hw_reg.dw1.ud ^ 0x80808080)

Yeah?  I'll add that as a follow-on patch.

Also... are BRW_REGISTER_TYPE_V constants something I need to worry about?

>> +
>> +  case BRW_REGISTER_TYPE_D:
>> + return memcmp(&fixed_hw_reg, &r.fixed_hw_reg,
>> +   sizeof(fixed_hw_reg) - sizeof(fixed_hw_reg.dw1)) == 
>> 0 &&
>> +fixed_hw_reg.dw1.d == -r.fixed_hw_reg.dw1.d;
>> +
>> +  default:
>> + return false;
>> +  }
>> +   } else {
>> +  return reg == r.reg &&
>> + reg_offset == r.reg_offset &&
>> + type == r.type &&
>> + negate != r.negate &&
>> + abs == r.abs &&
>> + swizzle == r.swizzle &&
>> + !reladdr && !r.reladdr &&
>> + memcmp(&fixed_hw_reg, &r.fixed_hw_reg,
>> +sizeof(fixed_hw_reg)) == 0;
> 
> Indent these to match reg == ...

Wait... I'd swear on a previous patch you wanted something indented like
this, and I commented that emacs is annoying for not being able to do
that by default.  The default emacs indentation would be:

  return reg == r.reg &&
 reg_offset == r.reg_offset &&
 type == r.type &&
 negate != r.negate &&
 abs == r.abs &&
 swizzle == r.swizzle &&
 !reladdr && !r.reladdr &&
 memcmp(&fixed_hw_reg, &r.fixed_hw_reg,
sizeof(fixed_hw_reg)) == 0;

Is that what you wanted, or did you mean something else?

This block was also a copy-and-paste from src_reg::equals.  If that
indentation is wrong, I can submit a clean-up patch for that too... just
to save the next copy-and-paster. :)

> I think the function does what it advertises. I just don't think that
> happens to be the thing you rea

[Mesa-dev] Valve games for Mesa/DRI developers

[Daniel Stone]

Hi,
At Collabora (my lovely dayjob), we've been working with Valve on
SteamOS. Valve are keen to give back to the community, and we've been
discussing ways they can help do that, including providing free access
to Valve games on Steam to Debian developers last year.

We're happy to say that this has been extended to Mesa developers as
well, to say thanks for all the great work. If you have 25 commits or
more (an arbitrary number) to Mesa[0] in the past five years, please
drop me an email (with 'Steam' in the subject) with your freedesktop
username and Steam username. We can then get you access to all past
and future Valve-produced games available on Steam[1].

Thanks for all the great work, and enjoy.

Cheers,
Daniel

[0]: Or DRI-type stuff in the kernel too.
[1]: Currently this looks like
https://store.steampowered.com/search/?snr=1_4_4__12&term=#category1=998&publisher=Valve&sort_order=ASC&page=1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Problem with LLVM on Windows with MSVC

[Predut, Marius]

Indeed seems you have some incompatible libraries (one build static and other 
dynamic –dll)

https://bugzilla.mozilla.org/show_bug.cgi?id=732124

but what suppose `libgl-gd' target? Is this a typo mismatch?

Try to build llvm in a dynamic mode , may be it will solve your problems


marius


From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of 
Shervin Sharifi
Sent: Thursday, April 09, 2015 2:57 AM
To: mesa-dev@lists.freedesktop.org
Subject: [Mesa-dev] Problem with LLVM on Windows with MSVC

Hi,

 I'm trying to build mesa on windows (MSVC) with gles support and with llvm.
 Here are the keys I'm using:
scons.py gles=yes llvm=yes platform=windows libgl-gd

 I'm getting a bunch of errors like this:

LLVMCore.lib(ValueSymbolTable.obj) : error LNK2038: mismatch detected for 
'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 
'MTd_StaticDebug' in mesa.lib(uniform_query.obj)

I understand that this is due to mismatch between the runtime libraries, but I 
don't know how to fix it.
Should I change the CRT in llvm or in mesa? How should I do that?

 Thanks,
 Shervin





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

Re: [Mesa-dev] [PATCH 4/5] i965/vs: Allow CSE to handle MULs with negated arguments.

[Matt Turner]

On Wed, Apr 8, 2015 at 4:38 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> This is similar to commit (47c4b38: i965/fs: Allow CSE to handle MULs
> with negated arguments.), but it uses a slightly different approach.

Just repeating myself... I don't know why this is different if it
doesn't do something more. Anyway,

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 3/5] i965/vs: Add src_reg::negative_equals method

[Matt Turner]

On Thu, Apr 9, 2015 at 9:31 AM, Matt Turner  wrote:
> I think the function does what it advertises. I just don't think that
> happens to be the thing you really want. See next patch's reply.

Oh, never mind. I missed the non-immediate case.

Even still, I guess I expected your more general case to do more than
mine, like recognize -a + -b and a + b are negations of one another,
but that's not possible with a src_reg method.

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 3/5] i965/vs: Add src_reg::negative_equals method

[Matt Turner]

On Wed, Apr 8, 2015 at 4:38 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> This method is similar to the existing ::equals method.  Instead of
> testing that two src_regs are equal to each other, it tests that one is
> the negation of the other.
>
> Signed-off-by: Ian Romanick 
> ---
>  src/mesa/drivers/dri/i965/brw_ir_vec4.h |  1 +
>  src/mesa/drivers/dri/i965/brw_vec4.cpp  | 43 
> +
>  2 files changed, 44 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_ir_vec4.h 
> b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> index d3bd64d..449795a 100644
> --- a/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> +++ b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> @@ -49,6 +49,7 @@ public:
> src_reg(struct brw_reg reg);
>
> bool equals(const src_reg &r) const;
> +   bool negative_equals(const src_reg &r) const;
>
> src_reg(class vec4_visitor *v, const struct glsl_type *type);
> src_reg(class vec4_visitor *v, const struct glsl_type *type, int size);
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index ef2fd40..d5286c2 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -328,6 +328,49 @@ src_reg::equals(const src_reg &r) const
>  }
>
>  bool
> +src_reg::negative_equals(const src_reg &r) const
> +{
> +   if (file != r.file)
> +  return false;
> +
> +   if (file == IMM) {
> +  if (!(reg == r.reg &&
> +reg_offset == r.reg_offset &&
> +type == r.type &&
> +negate == r.negate &&
> +abs == r.abs &&
> +swizzle == r.swizzle &&
> +!reladdr && !r.reladdr))

I would have applied DeMorgan's Law and made this a series of ORs.

> + return false;
> +
> +  switch (fixed_hw_reg.type) {

I don't think we keep fixed_hw_reg.type in sync with src_reg's type.
(Another reason to move towards a brw_reg-based register model)

Looking at the constructors for immediate, this appears to be the
case. Just changing this to switch (type) should do the trick.

> +  case BRW_REGISTER_TYPE_F:
> + return memcmp(&fixed_hw_reg, &r.fixed_hw_reg,
> +   sizeof(fixed_hw_reg) - sizeof(fixed_hw_reg.dw1)) == 0 
> &&
> +fixed_hw_reg.dw1.f == -r.fixed_hw_reg.dw1.f;

I don't think you need the memcmp. For immediates, we really just use
the fixed_hw_reg for the immediate storage itself and none of the
other metadata.

> +
> +  case BRW_REGISTER_TYPE_D:
> + return memcmp(&fixed_hw_reg, &r.fixed_hw_reg,
> +   sizeof(fixed_hw_reg) - sizeof(fixed_hw_reg.dw1)) == 0 
> &&
> +fixed_hw_reg.dw1.d == -r.fixed_hw_reg.dw1.d;
> +
> +  default:
> + return false;
> +  }
> +   } else {
> +  return reg == r.reg &&
> + reg_offset == r.reg_offset &&
> + type == r.type &&
> + negate != r.negate &&
> + abs == r.abs &&
> + swizzle == r.swizzle &&
> + !reladdr && !r.reladdr &&
> + memcmp(&fixed_hw_reg, &r.fixed_hw_reg,
> +sizeof(fixed_hw_reg)) == 0;

Indent these to match reg == ...

I think the function does what it advertises. I just don't think that
happens to be the thing you really want. See next patch's reply.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] glsl: Propagate negates through multiplication chains.

[Matt Turner]

On Wed, Apr 8, 2015 at 4:38 PM, Ian Romanick  wrote:
> From: Matt Turner 
>
> We propagate negations to the right-most leaves of the multiplication
> expression trees:
>
>  - mul(neg(x), neg(y)) -> mul(x, y)
>  - mul(neg(x), y) -> neg(mul(x, y))
>  - mul(x, neg(y)) -> neg(mul(x, y))

I've had an updated version of this patch that propagates negates up
multiplication trees. I've thought that would be better, but I've
never gotten the changes to be profitable with NIR.

This is an improvement as-is though, so let's do it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] i965: Add XRGB8888 format to intel_screen_make_configs

[Kristian Høgsberg]

On Wed, Apr 8, 2015 at 11:37 AM, Emil Velikov  wrote:
> Hi all,
>
> Can we get a pair of eyes on this patch please ?

Reviewed-by: Kristian Høgsberg 

Thanks for the reminder.

Kristian

>
> Boyan
> For the future can you please include the CC mesa-stable line in the
> commit message. It will make things a bit more obvious as I'm pursing
> through the list :-)
>
> Thanks
> Emil
>
> On 25 March 2015 at 11:36, Boyan Ding  wrote:
>> Some application, such as drm backend of weston, uses XRGB config as
>> default. i965 doesn't provide this format, but before commit 65c8965d,
>> the drm platform of EGL takes ARGB as XRGB. Now that commit
>> 65c8965d makes EGL recognize format correctly so weston won't start
>> because it can't find XRGB. Add XRGB format to i965 just as
>> other drivers do.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
>> Signed-off-by: Boyan Ding 
>> ---
>>  src/mesa/drivers/dri/i965/intel_screen.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
>> b/src/mesa/drivers/dri/i965/intel_screen.c
>> index 3640b67..2b82c33 100644
>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>> @@ -1126,7 +1126,8 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
>>  {
>> static const mesa_format formats[] = {
>>MESA_FORMAT_B5G6R5_UNORM,
>> -  MESA_FORMAT_B8G8R8A8_UNORM
>> +  MESA_FORMAT_B8G8R8A8_UNORM,
>> +  MESA_FORMAT_B8G8R8X8_UNORM
>> };
>>
>> /* GLX_SWAP_COPY_OML is not supported due to page flipping. */
>> --
>> 2.3.3
>>
>> ___
>> mesa-stable mailing list
>> mesa-sta...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-stable
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] glsl/cse: Use ir_rvalue_enter_visitor instead of ir_rvalue_visitor

[Matt Turner]

On Wed, Apr 8, 2015 at 4:38 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> ir_rvalue_visitor visits each rvalue on exit.  When visiting a large
> expression, the leaf expressions will be visited and eliminated first.
> Once one leaf expression was replaced, it would no longer match a
> potentially much larger tree.  This means that code like:
>
> x = a + (b * c);
> y = -(a + (b * c));
>
> would effectively be replaced by
>
> tmp = b * c;
> x = a + tmp;
> y = -(a + tmp);
>
> As a result both opportunities for generating a MAD would be lost, and
> we would generate worse code.
>
> Using ir_rvalue_enter_visitor means that larger expression trees will be
> checked first, and we have the potential to eliminate much larger
> expressions.
>
> I believe that opt_cse.cpp predates the existence of
> ir_rvalue_enter_visitor.

Nope, git disagrees.

Reviewed-by: Matt Turner 

>
> Shader-db results:
>
> GM45:
> total instructions in shared programs: 4063165 -> 4061744 (-0.03%)
> instructions in affected programs: 21664 -> 20243 (-6.56%)
> helped:259
>
> GM45 NIR:
> total instructions in shared programs: 4082044 -> 4080646 (-0.03%)
> instructions in affected programs: 21091 -> 19693 (-6.63%)
> helped:255
> HURT:  1
>
> Iron Lake:
> total instructions in shared programs: 5480334 -> 5478897 (-0.03%)
> instructions in affected programs: 25798 -> 24361 (-5.57%)
> helped:273
> HURT:  1
>
> Iron Lake NIR:
> total instructions in shared programs: 5678776 -> 5677395 (-0.02%)
> instructions in affected programs: 21744 -> 20363 (-6.35%)
> helped:263
> HURT:  2
>
> Sandy Bridge:
> total instructions in shared programs: 7318903 -> 7316983 (-0.03%)
> instructions in affected programs: 37937 -> 36017 (-5.06%)
> helped:398
> HURT:  26
>
> Sandy Bridge NIR:
> total instructions in shared programs: 7329995 -> 7328069 (-0.03%)
> instructions in affected programs: 32487 -> 30561 (-5.93%)
> helped:384
> HURT:  6
>
> Ivy Bridge:
> total instructions in shared programs: 6766579 -> 6765409 (-0.02%)
> instructions in affected programs: 18110 -> 16940 (-6.46%)
> helped:288
> HURT:  16
> GAINED:1
>
> Ivy Bridge NIR:
> total instructions in shared programs: 6769314 -> 6768159 (-0.02%)
> instructions in affected programs: 11063 -> 9908 (-10.44%)
> helped:264
> HURT:  6
>
> Haswell:
> total instructions in shared programs: 6226294 -> 6225102 (-0.02%)
> instructions in affected programs: 17555 -> 16363 (-6.79%)
> helped:297
> HURT:  10
> GAINED:1
>
> Haswell NIR:
> total instructions in shared programs: 6183693 -> 6182538 (-0.02%)
> instructions in affected programs: 10990 -> 9835 (-10.51%)
> helped:264
> HURT:  6
>
> Broadwell:
> total instructions in shared programs: 7285895 -> 7284537 (-0.02%)
> instructions in affected programs: 31977 -> 30619 (-4.25%)
> helped:357
> HURT:  6
>
> Broadwell NIR:
> total instructions in shared programs: 7501711 -> 7501544 (-0.00%)
> instructions in affected programs: 7174 -> 7007 (-2.33%)
> helped:87
> HURT:  2
>
> Signed-off-by: Ian Romanick 
> ---
>  src/glsl/opt_cse.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/glsl/opt_cse.cpp b/src/glsl/opt_cse.cpp
> index 4b8e9a0..425eebc 100644
> --- a/src/glsl/opt_cse.cpp
> +++ b/src/glsl/opt_cse.cpp
> @@ -99,7 +99,7 @@ public:
> ir_variable *var;
>  };
>
> -class cse_visitor : public ir_rvalue_visitor {
> +class cse_visitor : public ir_rvalue_enter_visitor {
>  public:
> cse_visitor(exec_list *validate_instructions)
>: validate_instructions(validate_instructions)
> --
> 2.1.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Problem with LLVM on Windows with MSVC

[Olivier PENA]

Hi,
Try use llvm cmake options :
LLVM_USE_CRT_DEBUG=MTd
LLVM_USE_CRT_RELEASE =MT


De : mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] De la part de 
Shervin Sharifi
Envoyé : jeudi 9 avril 2015 01:57
À : mesa-dev@lists.freedesktop.org
Objet : [Mesa-dev] Problem with LLVM on Windows with MSVC

Hi,

 I'm trying to build mesa on windows (MSVC) with gles support and with llvm.
 Here are the keys I'm using:
scons.py gles=yes llvm=yes platform=windows libgl-gd

 I'm getting a bunch of errors like this:

LLVMCore.lib(ValueSymbolTable.obj) : error LNK2038: mismatch detected for 
'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 
'MTd_StaticDebug' in mesa.lib(uniform_query.obj)

I understand that this is due to mismatch between the runtime libraries, but I 
don't know how to fix it.
Should I change the CRT in llvm or in mesa? How should I do that?

 Thanks,
 Shervin







Click here to report 
this email as spam.


-
Ce message a été traité contre les virus par quatre outils différents 
(Kaspersky, McAfee, Symantec et ThreatSeeker). 
This message has been scanned for viruses (by Kaspersky, McAfee, Symantec and 
ThreatSeeker).
-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] i915: Add XRGB8888 format to intel_screen_make_configs

[Emil Velikov]

Hi Boyan,

On 9 April 2015 at 16:08, Boyan Ding  wrote:
> For the same reason as the i965 one, as suggested by Chih-Wei Huang.
>
> Cc: "10.4 10.5" 
> Signed-off-by: Boyan Ding 
> ---

Did you run this and the i965 patch through piglit ? Considering how
quiet things are having the information that if fixes/breaks test X
and Y would be great to have.

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

[Mesa-dev] [PATCH] i915: Add XRGB8888 format to intel_screen_make_configs

[Boyan Ding]

For the same reason as the i965 one, as suggested by Chih-Wei Huang.

Cc: "10.4 10.5" 
Signed-off-by: Boyan Ding 
---
 src/mesa/drivers/dri/i915/intel_screen.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
b/src/mesa/drivers/dri/i915/intel_screen.c
index 77af328..a1fd791 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -1042,7 +1042,8 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
 {
static const mesa_format formats[] = {
   MESA_FORMAT_B5G6R5_UNORM,
-  MESA_FORMAT_B8G8R8A8_UNORM
+  MESA_FORMAT_B8G8R8A8_UNORM,
+  MESA_FORMAT_B8G8R8X8_UNORM
};
 
/* GLX_SWAP_COPY_OML is not supported due to page flipping. */
-- 
2.3.3

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

Re: [Mesa-dev] [PATCH 4/5] i965/vs: Allow CSE to handle MULs with negated arguments.

[Jason Ekstrand]

On Apr 8, 2015 4:38 PM, "Ian Romanick"  wrote:
>
> From: Ian Romanick 
>
> This is similar to commit (47c4b38: i965/fs: Allow CSE to handle MULs
> with negated arguments.), but it uses a slightly different approach.
>
> Shader-db results:
>
> GM45:
> total instructions in shared programs: 4060813 -> 4060151 (-0.02%)
> instructions in affected programs: 13448 -> 12786 (-4.92%)
> helped:62
> HURT:  9
>
> All other results, except Broadwell, were identical to GM45 w/o NIR.
> Since NIR isn't used for VEC4, this makes sense.
>
> Broadwell:
> total instructions in shared programs: 7284561 -> 7284540 (-0.00%)
> instructions in affected programs: 1272 -> 1251 (-1.65%)
> helped:12
>
> Broadwell NIR:
> total instructions in shared programs: 7500487 -> 7500487 (0.00%)
> instructions in affected programs: 0 -> 0

The Broadwell numbers aren't interesting. The only reason they are
different is that we use scalar for GLSL programs and vec4 for ARB.  With
NIR use scalar for everything so it doesn't even touch this patch.

I don't know much about the vec4 backend so take this with a grain of salt,
but you can call it

Reviewed-by: Jason Ekstrand 

> Signed-off-by: Ian Romanick 
> ---
>  src/mesa/drivers/dri/i965/brw_vec4_cse.cpp | 32
+-
>  1 file changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_cse.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_cse.cpp
> index 100e511..49b50a7 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_cse.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_cse.cpp
> @@ -90,15 +90,34 @@ is_expression(const vec4_instruction *const inst)
>  }
>
>  static bool
> -operands_match(const vec4_instruction *a, const vec4_instruction *b)
> +operands_match(const vec4_instruction *a, const vec4_instruction *b,
> +   bool *negate)
>  {
> const src_reg *xs = a->src;
> const src_reg *ys = b->src;
>
> +   *negate = false;
> +
> if (a->opcode == BRW_OPCODE_MAD) {
>return xs[0].equals(ys[0]) &&
>   ((xs[1].equals(ys[1]) && xs[2].equals(ys[2])) ||
>(xs[2].equals(ys[1]) && xs[1].equals(ys[2])));
> +   } else if (a->opcode == BRW_OPCODE_MUL) {
> +  if ((xs[0].equals(ys[0]) && xs[1].equals(ys[1])) ||
> +  (xs[1].equals(ys[0]) && xs[0].equals(ys[1])) ||
> +  (xs[0].negative_equals(ys[0]) && xs[1].negative_equals(ys[1]))
||
> +  (xs[1].negative_equals(ys[0]) && xs[0].negative_equals(ys[1])))
> + return true;
> +
> +  if ((xs[0].equals(ys[0]) && xs[1].negative_equals(ys[1])) ||
> +  (xs[1].equals(ys[0]) && xs[0].negative_equals(ys[1])) ||
> +  (xs[0].negative_equals(ys[0]) && xs[1].equals(ys[1])) ||
> +  (xs[1].negative_equals(ys[0]) && xs[0].equals(ys[1]))) {
> + *negate = true;
> + return true;
> +  }
> +
> +  return false;
> } else if (!a->is_commutative()) {
>return xs[0].equals(ys[0]) && xs[1].equals(ys[1]) &&
xs[2].equals(ys[2]);
> } else {
> @@ -108,7 +127,7 @@ operands_match(const vec4_instruction *a, const
vec4_instruction *b)
>  }
>
>  static bool
> -instructions_match(vec4_instruction *a, vec4_instruction *b)
> +instructions_match(vec4_instruction *a, vec4_instruction *b, bool
*negate)
>  {
> return a->opcode == b->opcode &&
>a->saturate == b->saturate &&
> @@ -117,7 +136,7 @@ instructions_match(vec4_instruction *a,
vec4_instruction *b)
>a->dst.writemask == b->dst.writemask &&
>a->force_writemask_all == b->force_writemask_all &&
>a->regs_written == b->regs_written &&
> -  operands_match(a, b);
> +  operands_match(a, b, negate);
>  }
>
>  bool
> @@ -135,11 +154,12 @@ vec4_visitor::opt_cse_local(bblock_t *block)
>(inst->dst.file != HW_REG || inst->dst.is_null()))
>{
>   bool found = false;
> + bool negate;
>
>   foreach_in_list_use_after(aeb_entry, entry, &aeb) {
>  /* Match current instruction's expression against those in
AEB. */
>  if (!(entry->generator->dst.is_null() &&
!inst->dst.is_null()) &&
> -instructions_match(inst, entry->generator)) {
> +instructions_match(inst, entry->generator, &negate)) {
> found = true;
> progress = true;
> break;
> @@ -186,6 +206,7 @@ vec4_visitor::opt_cse_local(bblock_t *block)
>vec4_instruction *copy = MOV(offset(inst->dst, i),
> offset(entry->tmp, i));
>copy->force_writemask_all = inst->force_writemask_all;
> +  copy->src[0].negate = negate;
>inst->insert_before(block, copy);
> }
>  }
> @@ -206,9 +227,10 @@ vec4_visitor::opt_cse_local(bblock_t *block)
>* the flag register if we

Re: [Mesa-dev] [PATCH] gallivm: Fix build since llvm-3.7.0svn r234460.

[Tom Stellard]

On Wed, Apr 08, 2015 at 10:56:37PM -0700, Vinson Lee wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89963
> Signed-off-by: Vinson Lee 
Reviewed-by: Tom Stellard 
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp 
> b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
> index 65d2896..b712915 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
> @@ -97,7 +97,11 @@ private:
> uint64_t pos;
>  
>  public:
> +#if HAVE_LLVM >= 0x0307
> +   raw_debug_ostream() : raw_ostream(SK_FD), pos(0) { }
> +#else
> raw_debug_ostream() : pos(0) { }
> +#endif
>  
> void write_impl(const char *Ptr, size_t Size);
>  
> -- 
> 2.3.5
> 
> ___
> 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] st/mesa: convert sub image for cube map arrays to 2d arrays for upload

[Marek Olšák]

Reviewed-by: Marek Olšák 

I'd like to have both fixes in master. Either or both can be
candidates for stable.

Marek

On Wed, Apr 8, 2015 at 3:00 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> Since we can subimage upload a number of cube map array layers,
> that aren't a complete cube map array, we should specify things
> as a 2D array and blit from that.
>
> Suggested by Ilia Mirkin as an alternate fix for texsubimage
> cube map array issues.
>
> seems to work just as well.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/mesa/state_tracker/st_cb_texture.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c 
> b/src/mesa/state_tracker/st_cb_texture.c
> index 5631361..40c6677 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -738,6 +738,11 @@ st_TexSubImage(struct gl_context *ctx, GLuint dims,
> if (gl_target == GL_TEXTURE_CUBE_MAP) {
>gl_target = GL_TEXTURE_2D;
> }
> +   /* TexSubImage can specify subsets of cube map array faces
> +* so we need to upload via 2D array instead */
> +   if (gl_target == GL_TEXTURE_CUBE_MAP_ARRAY) {
> +  gl_target = GL_TEXTURE_2D_ARRAY;
> +   }
>
> /* Initialize the source texture description. */
> memset(&src_templ, 0, sizeof(src_templ));
> --
> 2.1.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: align cube map arrays layers

[Marek Olšák]

This will prevent similar bugs in the future. It should be a candidate
for stable.

Whether the alignment is done unconditionally (like Ilia suggested) or not:

Reviewed-by: Marek Olšák 

Marek

On Wed, Apr 8, 2015 at 2:02 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> We create textures internally for texsubimage, and we use
> the values from sub image to create a new texture, however
> we don't align these to valid sizes, and cube map arrays
> must have an array size aligned to 6.
>
> This fixes texsubimage cube_map_array on CAYMAN at least,
> (it was causing  GPU hang and bad values), it probably
> also fixes it on radeonsi and evergreen.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/mesa/state_tracker/st_texture.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_texture.c 
> b/src/mesa/state_tracker/st_texture.c
> index ca7c83c..5c9a09c 100644
> --- a/src/mesa/state_tracker/st_texture.c
> +++ b/src/mesa/state_tracker/st_texture.c
> @@ -177,6 +177,8 @@ st_gl_texture_dims_to_pipe_dims(GLenum texture,
>*widthOut = widthIn;
>*heightOut = heightIn;
>*depthOut = 1;
> +  if (depthIn % 6)
> + depthIn = util_align_npot(depthIn, 6);
>*layersOut = depthIn;
>break;
> default:
> --
> 2.1.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: align cube map arrays layers

[Marek Olšák]

On Wed, Apr 8, 2015 at 2:43 AM, Ilia Mirkin  wrote:
> On Tue, Apr 7, 2015 at 8:02 PM, Dave Airlie  wrote:
>> From: Dave Airlie 
>>
>> We create textures internally for texsubimage, and we use
>> the values from sub image to create a new texture, however
>> we don't align these to valid sizes, and cube map arrays
>> must have an array size aligned to 6.
>>
>> This fixes texsubimage cube_map_array on CAYMAN at least,
>> (it was causing  GPU hang and bad values), it probably
>> also fixes it on radeonsi and evergreen.
>>
>> Signed-off-by: Dave Airlie 
>> ---
>>  src/mesa/state_tracker/st_texture.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/src/mesa/state_tracker/st_texture.c 
>> b/src/mesa/state_tracker/st_texture.c
>> index ca7c83c..5c9a09c 100644
>> --- a/src/mesa/state_tracker/st_texture.c
>> +++ b/src/mesa/state_tracker/st_texture.c
>> @@ -177,6 +177,8 @@ st_gl_texture_dims_to_pipe_dims(GLenum texture,
>>*widthOut = widthIn;
>>*heightOut = heightIn;
>>*depthOut = 1;
>> +  if (depthIn % 6)
>> + depthIn = util_align_npot(depthIn, 6);
>>*layersOut = depthIn;
>
> I'd just do this as
>
> *layersOut = util_align_npot(depthIn, 6)
>
> But I assume this is the st_TexSubImage caller? Then I bet that instead
>
>/* TexSubImage only sets a single cubemap face. */
>if (gl_target == GL_TEXTURE_CUBE_MAP) {
>   gl_target = GL_TEXTURE_2D;
>}
>
> Should be changed to account for cube map arrays...

No, cube maps use TexSubImage2D, but cube map arrays use TexSubImage3D.

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

[Mesa-dev] New stable-branch 10.5 candidate pushed

[Emil Velikov]

Hello list,

The candidate for the Mesa 10.5.3 is now available. The current patch queue
is as follows:
 - 18 queued
 - 13 nominated (outstanding)
 - and 2 rejected (obsolete) patches

This release addresses bugs in our OpenCL state-tracker (clover) and nearly
every dri driver. The compilation process should finally be python/mako free :)

Take a look at section "Mesa stable queue" for more information.

Testing
---
The following results are against piglit 305ecc3ac89.


Changes - classic i965(snb)
---
None.


Changes - swrast classic

None.


Changes - gallium softpipe, llvmpipe (LLVM 3.5.1)
-
None.


Testing reports/general approval

Any testing reports (or general approval of the state of the branch)
will be greatly appreciated.


Trivial merge conflicts
---
Here are the commits where I manually merged conflicts, so these might
merit additional review:

commit 64d0f0e3b24c7d3ffd7bde921aadfccf3f12df0c
Author: Michel Dänzer 

radeonsi: Cache LLVMTargetMachineRef in context instead of in screen

(cherry picked from commit d64adc3a79e419062432cfa8d1cbc437676a3fbd)



The plan is to have 10.5.3 this Friday(10th April).

If you have any questions or comments that you would like to share
before the release, please go ahead.


Cheers,
Emil


Mesa stable queue
-

Nominated (13)
==

Boyan Ding (1):
  i965: Add XRGB format to intel_screen_make_configs

Brian Paul (1):
  configure: don't try to build gallium DRI drivers if --disable-dri is set

Emil Velikov (9):
  android: use LOCAL_SHARED_LIBRARIES over TARGET_OUT_HEADERS
  android: add $(mesa_top)/src include to the whole of mesa
  android: egl: add libsync_cflags to the build
  android: dri/common: conditionally include drm_cflags/set __NOT_HAVE_DRM_H
  android: add HAVE__BUILTIN_* and HAVE_FUNC_ATTRIBUTE_* defines
  android: add $(mesa_top)/src/mesa/main to the includes list
  android: dri: link against libmesa_util
  android: mesa: fix the path of the SSE4_1 optimisations
  dist: add the VG depedencies into the tarball

Mauro Rossi (2):
  android: mesa: generate the format_{un,}pack.[ch] sources
  android: add inital NIR build


Rejected/Obsolete (2)
=

Tom Stellard (2):
  clover: Return CL_BUILD_ERROR for CL_PROGRAM_BUILD_STATUS when 
compilation fails
  clover: Update the wait_count of the correct event when chaining events


Queued (18)
===

Dave Airlie (1):
  st_glsl_to_tgsi: only do mov copy propagation on temps (v2)

Emil Velikov (3):
  docs: Add sha256 sums for the 10.5.2 release
  xmlpool: don't forget to ship the MOS
  configure.ac: error out if python/mako is not found when required

Iago Toral Quiroga (1):
  i965: Do not render primitives in non-zero streams then TF is disabled

Ilia Mirkin (7):
  st/mesa: update arrays when the current attrib has been updated
  nv50/ir: take postFactor into account when doing peephole optimizations
  nv50/ir/gk110: fix offset flag position for TXD opcode
  freedreno/a3xx: fix 3d texture layout
  freedreno/a3xx: point size should not be divided by 2
  nv50: allocate more offset space for occlusion queries
  nv50,nvc0: limit the y-tiling of 3d textures to the first level's tiling

Kenneth Graunke (2):
  i965: Fix instanced geometry shaders on Gen8+.
  i965: Add forgotten multi-stream code to Gen8 SOL state.

Marcin Ślusarz (1):
  nouveau: synchronize "scratch runout" destruction with the command stream

Michel Dänzer (1):
  radeonsi: Cache LLVMTargetMachineRef in context instead of in screen

Tom Stellard (1):
  clover: Return CL_BUILD_ERROR for CL_PROGRAM_BUILD_STATUS when 
compilation fails v2

Ville Syrjälä (1):
  i965: Fix URB size for CHV
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] st_TexSubImage: unaligned memcpy performance

[Vasilis Liaskovitis]

Hi,

On Wed, Apr 8, 2015 at 1:24 PM, Daniel Stone  wrote:

> Hi,
>
> On 8 April 2015 at 10:57, Vasilis Liaskovitis  wrote:
> > I have an issue where st_TexSubImage causes very high CPU load in
> > __memcpy_sse2_unaligned (Mesa 10.1.3, Xorg 1.15.1, radeon driver, HD
> 7870).
> >
> > Any obvious causes / tips for this? e.g. align textures or use different
> > format/type? I 've tried using GL_BGRA/GL_UNSIGNED_BYTE and
> > GL_BGRA/GL_UNSIGNED_INT_8_8_8_8_REV
> >
> > __memcpy_sse2_unaligned () at
> > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:85
> > 85../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file
> or
> > directory.
> > (gdb) bt
> > #0  __memcpy_sse2_unaligned () at
> > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:85
> > #1  0x7fffb572f154 in memcpy (__len=7680, __src=,
> > __dest=0x7fff5835f800) at /usr/include/x86_64-linux-gnu/bits/string3.h:51
> > #2  st_TexSubImage (ctx=0x1b91420, dims=,
> texImage=0x1f81710,
> > xoffset=0, yoffset=0, zoffset=0, width=1920, height=1080, depth=1,
> > format=32993, type=5121, pixels=0xdacf90, unpack=0x1bad590)
> > at ../../../../src/mesa/state_tracker/st_cb_texture.c:752
>
> Your source (0xdacf90) is only aligned to a 16-byte boundary, not 32.
> This will cause issues particularly on ARM, where natural alignment is
> required (i.e. 32-byte load/stores must be on 32-byte boundaries). By
> contrast, the destination is already aligned to a 128-byte boundary.
> So fixing the caller, rather than Mesa, should take care of the
> problem.
>

thanks for the reply and the observation. I aligned source on 32-byte
boundary (or even 128-byte boundary) but there was no difference.
By the way, I am only using x86_64, not ARM. I believe intel sse2 only
requires 16-byte boundary alignment, but perhaps i am missing something.

Is this code path in st_TexSubImage using PBOs? I guess it depends on
driver (radeon in my case) implementation?

Related: pboUnpack http://www.songho.ca/opengl/files/pboUnpack.zip
gives: Transfer Rate: 236.5 MB/s. (59.1 FPS)
Does this sounds reasonably ok for uploading with PBO?

Same bottleneck __memcpy_sse2_unaligned is observed.
sample perf report output:

 28,20%  pboUnpack  libc-2.19.so[.] __memcpy_sse2_unaligned
 16,63%  pboUnpack  pboUnpack   [.] 0x6542
  6,96%  pboUnpack  [kernel.kallsyms]   [k] clear_page_c_e
  2,52%  pboUnpack  [drm]   [k]
drm_mm_insert_node_in_range_generic
  2,10%  pboUnpack  [kernel.kallsyms]   [k] get_page_from_freelist


backtrace:

__memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:86
86../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or
directory.
(gdb) bt
#0  __memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:86
#1  0x72bddbbd in memcpy (__len=4194304, __src=,
__dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:51
#2  memcpy_texture (dimensions=dimensions@entry=2,
dstFormat=dstFormat@entry=MESA_FORMAT_B8G8R8A8_UNORM,
dstRowStride=dstRowStride@entry=4096, dstSlices=dstSlices@entry=0x7fffd6e8,

srcWidth=srcWidth@entry=1024, srcHeight=srcHeight@entry=1024,
srcDepth=srcDepth@entry=1, srcFormat=srcFormat@entry=32993,
srcType=srcType@entry=5121, srcAddr=srcAddr@entry=0x7fffeeecd000,
srcPacking=srcPacking@entry=0x77f69180, ctx=) at
../../../../src/mesa/main/texstore.c:949
#3  0x72be353d in _mesa_texstore_memcpy (srcPacking=0x77f69180,
srcAddr=, srcType=5121, srcFormat=32993, srcDepth=, srcHeight=,
srcWidth=, dstSlices=,
dstRowStride=, dstFormat=MESA_FORMAT_B8G8R8A8_UNORM,
baseInternalFormat=6408, dims=, ctx=0x77f4d010)
at ../../../../src/mesa/main/texstore.c:3938
#4  _mesa_texstore (ctx=0x77f4d010, dims=2, baseInternalFormat=6408,
dstFormat=MESA_FORMAT_B8G8R8A8_UNORM, dstRowStride=4096,
dstSlices=0x7fffd6e8, srcWidth=1024, srcHeight=1024, srcDepth=1,
srcFormat=32993, srcType=5121, srcAddr=0x7fffeeecd000,
srcPacking=0x77f69180) at ../../../../src/mesa/main/texstore.c:3958
#5  0x72be3812 in store_texsubimage (ctx=ctx@entry=0x77f4d010,
texImage=texImage@entry=0x7c8690, xoffset=xoffset@entry=0,
yoffset=yoffset@entry=0, zoffset=zoffset@entry=0, width=1024,
height=1024, depth=1, format=32993, type=5121, pixels=0x0,
packing=0x77f69180, caller=0x72d609c7 "glTexSubImage") at
../../../../src/mesa/main/texstore.c:4107
#6  0x72be3aa5 in _mesa_store_texsubimage
(ctx=ctx@entry=0x77f4d010,
dims=, texImage=texImage@entry=0x7c8690,
xoffset=xoffset@entry=0, yoffset=yoffset@entry=0,
zoffset=zoffset@entry=0, width=, width@entry=1024,
height=, height@entry=1024, depth=,
depth@entry=1, format=, format@entry=32993,
type=, type@entry=5121, pixels=,
pixels@entry=0x0, packing=, packing@entry=0x77f69180) at
../../../../src/mesa/main/texstore.c:4171
#7  0x72c3acaa in st_TexSubImage (ctx=0x77f4d010,
dims=, texImage=0x7c8690, xoffset=0, yoffset=0, zoffset=0