Re: [Mesa-dev] [PATCH 0/3] i965: Let driconf clamp_max_samples affect context version

[Kenneth Graunke]

On 11/20/2013 02:10 PM, Chad Versace wrote:
> This series makes clamp_max_samples actually useful enabling/disabling MSAA on
> Chromium. Without this series, clamp_max_samples=0 makes WebGL context 
> creation
> fail on Chromium.
> 
> Eric complained that brw_clamp_max_samples() too closely resembled
> intel_quantize_num_samples(), so this series removes the conceptual 
> duplication
> between the two functions.  It moves the list of supported MSAA modes to
> a shared function.
> 
> Chad Versace (3):
>   i965: Terminate brw_supported_msaa_modes() list with -1, not 0
>   i965: Share code between intel_quantize_num_samples and
> clamp_max_samples
>   i965: Let driconf clamp_max_samples affect context version
> 
>  src/mesa/drivers/dri/i965/brw_context.c  | 77 
> +---
>  src/mesa/drivers/dri/i965/intel_fbo.c| 28 +---
>  src/mesa/drivers/dri/i965/intel_screen.c | 20 +
>  src/mesa/drivers/dri/i965/intel_screen.h |  3 ++
>  4 files changed, 53 insertions(+), 75 deletions(-)
> 

This series is:
Reviewed-by: Kenneth Graunke 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 9/9] svga/winsys: Implement surface sharing using prime fd handles

[Thomas Hellstrom]

On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote:

From: Thomas Hellstrom 

This needs a prime-aware vmwgfx kernel module to work properly.

(With additions by Christopher James Halse Rogers )


Signed-off-by: Thomas Hellstrom 


---
  src/gallium/targets/dri-vmwgfx/target.c  | 13 +
  src/gallium/winsys/svga/drm/vmw_screen_dri.c | 79 +---
  2 files changed, 74 insertions(+), 18 deletions(-)

diff --git a/src/gallium/targets/dri-vmwgfx/target.c 
b/src/gallium/targets/dri-vmwgfx/target.c
index e01e465..aaf37b0 100644
--- a/src/gallium/targets/dri-vmwgfx/target.c
+++ b/src/gallium/targets/dri-vmwgfx/target.c
@@ -31,11 +31,24 @@ static const struct drm_conf_ret throttle_ret = {
 .val.val_int = 2,
  };
  
+/* Technically this requires kernel support that is not yet

+ * widespread.
+ *
+ * We could check for support in create_screen and return the correct
+ * value, but for now just return true in all cases.
+ */
Good point. I will bump the drm vmwgfx driver minor to advertise prime 
support,

but this is fine for now.


+static const struct drm_conf_ret share_fd_ret = {
+   .type = DRM_CONF_BOOL,
+   .val.val_int = true,
+};
+
  static const struct drm_conf_ret *drm_configuration(enum drm_conf conf)
  {
 switch (conf) {
 case DRM_CONF_THROTTLE:
return &throttle_ret;
+   case DRM_CONF_SHARE_FD:
+  return &share_fd_ret;
 default:
break;
 }
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_dri.c 
b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
index 6323a8a..a17cdf7 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
@@ -40,6 +40,7 @@
  #include 
  
  #include 

+#include 
  
  struct dri1_api_version {

 int major;
@@ -160,37 +161,57 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen 
*sws,
  union drm_vmw_surface_reference_arg arg;
  struct drm_vmw_surface_arg *req = &arg.req;
  struct drm_vmw_surface_create_req *rep = &arg.rep;
+uint32_t handle = 0;
  int ret;
  int i;
  
-if (whandle->type != DRM_API_HANDLE_TYPE_SHARED) {

-vmw_error("Attempt to import unknown handle type %d\n",
-  whandle->type);
-return NULL;
+switch (whandle->type) {
+case DRM_API_HANDLE_TYPE_SHARED:
+case DRM_API_HANDLE_TYPE_KMS:
+   handle = whandle->handle;
+   break;
+case DRM_API_HANDLE_TYPE_FD:
+   ret = drmPrimeFDToHandle(vws->ioctl.drm_fd, whandle->handle,
+&handle);
+   if (ret) {
+ vmw_error("Failed to get handle from prime fd %d.\n",
+   (int) whandle->handle);
+ return NULL;
+   }
+   break;
+default:
+   vmw_error("Attempt to import unsupported handle type %d.\n",
+ whandle->type);
+   return NULL;
  }
  
-/**

- * The vmware device specific handle is the hardware SID.
- * FIXME: We probably want to move this to the ioctl implementations.
- */
-
  memset(&arg, 0, sizeof(arg));
-req->sid = whandle->handle;
+req->sid = handle;
  
  ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_REF_SURFACE,

  &arg, sizeof(arg));
  
+/*

+ * Need to close the handle we got from prime.
+ */
+if (whandle->type == DRM_API_HANDLE_TYPE_FD)
+   vmw_ioctl_surface_destroy(vws, handle);
+
  if (ret) {
-vmw_error("Failed referencing shared surface. SID %d.\n"
-  "Error %d (%s).\n",
-  whandle->handle, ret, strerror(-ret));
-   return NULL;
+   /*
+* Any attempt to share something other than a surface, like a dumb
+* kms buffer, should fail here.
+*/
+   vmw_error("Failed referencing shared surface. SID %d.\n"
+ "Error %d (%s).\n",
+ handle, ret, strerror(-ret));
+   return NULL;
  }
  
  if (rep->mip_levels[0] != 1) {

  vmw_error("Incorrect number of mipmap levels on shared surface."
" SID %d, levels %d\n",
-  whandle->handle, rep->mip_levels[0]);
+  handle, rep->mip_levels[0]);
goto out_mip;
  }
  
@@ -198,7 +219,7 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,

if (rep->mip_levels[i] != 0) {
  vmw_error("Incorrect number of faces levels on shared surface."
" SID %d, face %d present.\n",
-  whandle->handle, i);
+  handle, i);
goto out_mip;
}
 }
@@ -210,14 +231,15 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen 
*sws,
  pipe_reference_init(&vsrf->refcnt, 1);
  p_atomic_set(&vsrf->validated, 0);
  vsrf->screen = vws;
-vsrf->sid = whandle->handle;
+vsrf->sid = handle;
  ssrf = svga_winsys_surface(vsrf);
  *format = rep->format;
  
  return ssrf;
  
  out_mip:

-vm

Re: [Mesa-dev] [PATCH] mesa: Update MESA_INFO to eliminate error

[Kenneth Graunke]

On 10/24/2013 12:13 PM, Courtney Goeltzenleuchter wrote:
> If a user set MESA_INFO and the OpenGL application uses a
> 3.0 or later context then the MESA_INFO debug output will have
> an error when it queries for extensions using the deprecated
> enum GL_EXTENSIONS. Passing context argument allows code
> to return extension list directly regardless of profile.
> Commit title updated as recommended by Kenneth Graunke.
> ---
>  src/mesa/main/context.c |  2 +-
>  src/mesa/main/debug.c   | 10 +++---
>  src/mesa/main/debug.h   |  2 +-
>  3 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> index 0d1f71c..8218153 100644
> --- a/src/mesa/main/context.c
> +++ b/src/mesa/main/context.c
> @@ -1522,7 +1522,7 @@ _mesa_make_current( struct gl_context *newCtx,
>* information.
>*/
>if (_mesa_getenv("MESA_INFO")) {
> - _mesa_print_info();
> + _mesa_print_info(newCtx);
>}
>  
>newCtx->FirstTimeCurrent = GL_FALSE;
> diff --git a/src/mesa/main/debug.c b/src/mesa/main/debug.c
> index 9434c1e..99b2147 100644
> --- a/src/mesa/main/debug.c
> +++ b/src/mesa/main/debug.c
> @@ -103,7 +103,7 @@ _mesa_print_state( const char *msg, GLuint state )
>  /**
>   * Print information about this Mesa version and build options.
>   */
> -void _mesa_print_info( void )
> +void _mesa_print_info( struct gl_context *ctx )
>  {
> _mesa_debug(NULL, "Mesa GL_VERSION = %s\n",
>  (char *) _mesa_GetString(GL_VERSION));
> @@ -111,8 +111,12 @@ void _mesa_print_info( void )
>  (char *) _mesa_GetString(GL_RENDERER));
> _mesa_debug(NULL, "Mesa GL_VENDOR = %s\n",
>  (char *) _mesa_GetString(GL_VENDOR));
> -   _mesa_debug(NULL, "Mesa GL_EXTENSIONS = %s\n",
> -(char *) _mesa_GetString(GL_EXTENSIONS));
> +
> +   /* use ctx as GL_EXTENSIONS will not work on 3.0 or higher
> +* core contexts.
> +*/
> +   _mesa_debug(NULL, "Mesa GL_EXTENSIONS = %s\n", ctx->Extensions.String);
> +
>  #if defined(THREADS)
> _mesa_debug(NULL, "Mesa thread-safe: YES\n");
>  #else
> diff --git a/src/mesa/main/debug.h b/src/mesa/main/debug.h
> index 8414c5e..902f595 100644
> --- a/src/mesa/main/debug.h
> +++ b/src/mesa/main/debug.h
> @@ -43,7 +43,7 @@ struct gl_texture_image;
>  
>  extern void _mesa_print_enable_flags( const char *msg, GLuint flags );
>  extern void _mesa_print_state( const char *msg, GLuint state );
> -extern void _mesa_print_info( void );
> +extern void _mesa_print_info( struct gl_context *ctx );
>  extern void _mesa_init_debug( struct gl_context *ctx );
>  
>  extern void
> 

I just realized this never went upstream.

Reviewed-by: Kenneth Graunke 

Also pushed.


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

Re: [Mesa-dev] [PATCH] Don't use gbm_dri_device when its not there

[Kenneth Graunke]

On 10/23/2013 01:41 AM, Jørgen Lind wrote:
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index b29eb1c..b143a95 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1843,10 +1843,12 @@ dri2_bind_wayland_display_wl(_EGLDriver *drv, 
> _EGLDisplay *disp,
> if (!dri2_dpy->wl_server_drm)
>  return EGL_FALSE;
>  
> +#ifdef HAVE_DRM_PLATFORM
> /* We have to share the wl_drm instance with gbm, so gbm can convert
>  * wl_buffers to gbm bos. */
> if (dri2_dpy->gbm_dri)
>dri2_dpy->gbm_dri->wl_drm = dri2_dpy->wl_server_drm;
> +#endif
>  
> return EGL_TRUE;
>  }
> 

Kristian,

I noticed this patch never received any review of any sort, and isn't
upstream.  Could you take a look?

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

[Mesa-dev] [Bug 50754] Building 32 bit mesa on 64 bit OS fails since change for automake

[bugzilla-daemon]

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

Eero Tamminen  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
 CC||eero.t.tammi...@intel.com,
   ||petri.latv...@intel.com

--- Comment #23 from Eero Tamminen  ---
(In reply to comment #22)
> I'm closing this bug because I'm able to crosscompile anytime with the help
> of some variables.

This is Mesa bug.  You being able to work around Mesa bug doesn't mean that
it's fixed in Mesa.  Re-opening.

IMHO either --enable-32-bit should be removed as misleading[1], or Mesa should
be fixed.

[1] as discussed, it sets CFLAGS/CXXFLAGS too late, so they don't have the
required effect.


Regarding Tapani's patch fixing this, there would need to be also a comment in
configure.ac about the libtool initialization dependency on C/XXFLAGS values.

-- 
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 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate

[bugzilla-daemon]

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

Bug 45466 depends on bug 50754, which changed state.

Bug 50754 Summary: Building 32 bit mesa on 64 bit OS fails since change for 
automake
https://bugs.freedesktop.org/show_bug.cgi?id=50754

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

-- 
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 41700] Gallium won't build with --enable-32-bit on a 64-bit system

[bugzilla-daemon]

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

Bug 41700 depends on bug 50754, which changed state.

Bug 50754 Summary: Building 32 bit mesa on 64 bit OS fails since change for 
automake
https://bugs.freedesktop.org/show_bug.cgi?id=50754

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

-- 
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] llvmpipe: support 8bit subpixel precision

[Roland Scheidegger]

Great!

Couple of comments inline.

On 11/21/2013 12:02 AM, Zack Rusin wrote:

8 bit precision is required by d3d10 but unfortunately
requires 64 bit rasterizer. This commit implements
64 bit rasterization with full support for 8bit subpixel
precision. It's a combination of all individual commits
from the llvmpipe-rast-64 branch.

Signed-off-by: Zack Rusin 
---
  src/gallium/drivers/llvmpipe/lp_rast.c |  11 ++
  src/gallium/drivers/llvmpipe/lp_rast.h |  47 +--
  src/gallium/drivers/llvmpipe/lp_rast_debug.c   |   6 +-
  src/gallium/drivers/llvmpipe/lp_rast_priv.h|  27 
  src/gallium/drivers/llvmpipe/lp_rast_tri.c | 173 +
  src/gallium/drivers/llvmpipe/lp_rast_tri_tmp.h |  56 
  src/gallium/drivers/llvmpipe/lp_setup_line.c   |   2 +-
  src/gallium/drivers/llvmpipe/lp_setup_tri.c| 155 ++
  src/gallium/tests/graw/SConscript  |   1 +
  src/gallium/tests/graw/tri-large.c | 173 +
  10 files changed, 500 insertions(+), 151 deletions(-)
  create mode 100644 src/gallium/tests/graw/tri-large.c

diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c 
b/src/gallium/drivers/llvmpipe/lp_rast.c
index af661e9..0cd62c2 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -589,6 +589,17 @@ static lp_rast_cmd_func dispatch[LP_RAST_OP_MAX] =
 lp_rast_begin_query,
 lp_rast_end_query,
 lp_rast_set_state,
+   lp_rast_triangle_32_1,
+   lp_rast_triangle_32_2,
+   lp_rast_triangle_32_3,
+   lp_rast_triangle_32_4,
+   lp_rast_triangle_32_5,
+   lp_rast_triangle_32_6,
+   lp_rast_triangle_32_7,
+   lp_rast_triangle_32_8,
+   lp_rast_triangle_32_3_4,
+   lp_rast_triangle_32_3_16,
+   lp_rast_triangle_32_4_16
  };


diff --git a/src/gallium/drivers/llvmpipe/lp_rast.h 
b/src/gallium/drivers/llvmpipe/lp_rast.h
index 43c598d..b81d94f 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.h
+++ b/src/gallium/drivers/llvmpipe/lp_rast.h
@@ -46,10 +46,11 @@ struct lp_scene;
  struct lp_fence;
  struct cmd_bin;

-#define FIXED_TYPE_WIDTH 32
+#define FIXED_TYPE_WIDTH 64
  /** For sub-pixel positioning */
-#define FIXED_ORDER 4
+#define FIXED_ORDER 8
  #define FIXED_ONE (1c, (int32_t)plane->dcdx,
+ (int32_t)plane->dcdy, (int32_t)plane->eo);
+}
+
+#endif
+
  #endif
diff --git a/src/gallium/drivers/llvmpipe/lp_rast_debug.c 
b/src/gallium/drivers/llvmpipe/lp_rast_debug.c
index 3bc75aa..587c793 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast_debug.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast_debug.c
@@ -195,8 +195,8 @@ debug_triangle(int tilex, int tiley,
 while (plane_mask) {
plane[nr_planes] = tri_plane[u_bit_scan(&plane_mask)];
plane[nr_planes].c = (plane[nr_planes].c +
-plane[nr_planes].dcdy * tiley -
-plane[nr_planes].dcdx * tilex);
+IMUL64(plane[nr_planes].dcdy, tiley) -
+IMUL64(plane[nr_planes].dcdx, tilex));
nr_planes++;
 }

@@ -217,7 +217,7 @@ debug_triangle(int tilex, int tiley,
}

for (i = 0; i < nr_planes; i++) {
- plane[i].c += plane[i].dcdx * TILE_SIZE;
+ plane[i].c += IMUL64(plane[i].dcdx, TILE_SIZE);
   plane[i].c +=

[Mesa-dev] [PATCH 1/2] st/mesa: simplify writemask for emitting fog result

[Brian Paul]

---
 src/mesa/state_tracker/st_mesa_to_tgsi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c 
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index 7d79c62..1c2abc1 100644
--- a/src/mesa/state_tracker/st_mesa_to_tgsi.c
+++ b/src/mesa/state_tracker/st_mesa_to_tgsi.c
@@ -1124,7 +1124,7 @@ st_translate_mesa_program(
  if (outputSemanticName[i] == TGSI_SEMANTIC_FOG) {
 /* force register to contain a fog coordinate in the form (F, 0, 
0, 1). */
 ureg_MOV(ureg,
- ureg_writemask(t->outputs[i], TGSI_WRITEMASK_XYZW & 
~TGSI_WRITEMASK_X),
+ ureg_writemask(t->outputs[i], TGSI_WRITEMASK_YZW),
  ureg_imm4f(ureg, 0.0f, 0.0f, 0.0f, 1.0f));
 t->outputs[i] = ureg_writemask(t->outputs[i], TGSI_WRITEMASK_X);
 }
-- 
1.7.10.4

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

[Mesa-dev] [PATCH 2/2] mesa: fix indentation in ffvertex_prog.c

[Brian Paul]

And use a better assertion.
---
 src/mesa/main/ffvertex_prog.c |   26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index be6ac0f..074fbf9 100644
--- a/src/mesa/main/ffvertex_prog.c
+++ b/src/mesa/main/ffvertex_prog.c
@@ -1306,20 +1306,22 @@ static void build_fog( struct tnl_program *p )
 
   switch (p->state->fog_distance_mode) {
   case FDM_EYE_RADIAL: /* Z = sqrt(Xe*Xe + Ye*Ye + Ze*Ze) */
-   input = get_eye_position(p);
-   emit_op2(p, OPCODE_DP3, fog, WRITEMASK_X, input, input);
-   emit_op1(p, OPCODE_RSQ, fog, WRITEMASK_X, fog);
-   emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, fog);
-   break;
+ input = get_eye_position(p);
+ emit_op2(p, OPCODE_DP3, fog, WRITEMASK_X, input, input);
+ emit_op1(p, OPCODE_RSQ, fog, WRITEMASK_X, fog);
+ emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, fog);
+ break;
   case FDM_EYE_PLANE: /* Z = Ze */
-   input = get_eye_position_z(p);
-   emit_op1(p, OPCODE_MOV, fog, WRITEMASK_X, input);
-   break;
+ input = get_eye_position_z(p);
+ emit_op1(p, OPCODE_MOV, fog, WRITEMASK_X, input);
+ break;
   case FDM_EYE_PLANE_ABS: /* Z = abs(Ze) */
-   input = get_eye_position_z(p);
-   emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
-   break;
-  default: assert(0); break; /* can't happen */
+ input = get_eye_position_z(p);
+ emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
+ break;
+  default:
+ assert(!"Bad fog mode in build_fog()");
+ break;
   }
 
}
-- 
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 v2 1/5] mesa: Track number of layers in layered framebuffers.

[Jordan Justen]

On Wed, 2013-11-20 at 14:29 -0800, Paul Berry wrote:
> In order to properly clear layered framebuffers, we need to know how
> many layers they have.  The easiest way to do this is to record it in
> the gl_framebuffer struct when we check framebuffer completeness.
> 
> This patch replaces the gl_framebuffer::Layered boolean with a
> gl_framebuffer::NumLayers integer, which is 0 if the framebuffer is
> not layered, and equal to the number of layers otherwise.
> 
> v2: Remove gl_framebuffer::Layered and make gl_framebuffer::NumLayers
> always have a defined value.  Fix factor of 6 error in the number of
> layers in a cube map array.
> 
> Cc: "10.0" 
> 
> Reviewed-by: Chris Forbes 
> ---
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  2 +-
>  src/mesa/drivers/dri/i965/gen6_clip_state.c  |  2 +-
>  src/mesa/drivers/dri/i965/gen7_misc_state.c  |  2 +-
>  src/mesa/main/fbobject.c | 13 +++--
>  src/mesa/main/mtypes.h   |  8 +++-
>  5 files changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index 662c975..fd6954b 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -701,7 +701,7 @@ brw_update_renderbuffer_surfaces(struct brw_context *brw)
>for (i = 0; i < ctx->DrawBuffer->_NumColorDrawBuffers; i++) {
>if (intel_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[i])) {
>   brw->vtbl.update_renderbuffer_surface(brw, 
> ctx->DrawBuffer->_ColorDrawBuffers[i],
> -  ctx->DrawBuffer->Layered, 
> i);
> +  ctx->DrawBuffer->NumLayers 
> > 0, i);
>} else {
>   brw->vtbl.update_null_renderbuffer_surface(brw, i);
>}
> diff --git a/src/mesa/drivers/dri/i965/gen6_clip_state.c 
> b/src/mesa/drivers/dri/i965/gen6_clip_state.c
> index 03d0f90..37a39b8 100644
> --- a/src/mesa/drivers/dri/i965/gen6_clip_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_clip_state.c
> @@ -121,7 +121,7 @@ upload_clip_state(struct brw_context *brw)
>dw2);
> OUT_BATCH(U_FIXED(0.125, 3) << GEN6_CLIP_MIN_POINT_WIDTH_SHIFT |
>   U_FIXED(255.875, 3) << GEN6_CLIP_MAX_POINT_WIDTH_SHIFT |
> - (fb->Layered ? 0 : GEN6_CLIP_FORCE_ZERO_RTAINDEX));
> + (fb->NumLayers > 0 ? 0 : GEN6_CLIP_FORCE_ZERO_RTAINDEX));
> ADVANCE_BATCH();
>  }
>  
> diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c 
> b/src/mesa/drivers/dri/i965/gen7_misc_state.c
> index 3f3833e..4251949 100644
> --- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
> @@ -81,7 +81,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
>break;
> }
>  
> -   if (fb->Layered || !irb) {
> +   if (fb->NumLayers > 0 || !irb) {
>min_array_element = 0;
> } else if (irb->mt->num_samples > 1) {
>/* Convert physical layer to logical layer. */
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 9dd7161..e8cf274 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -905,6 +905,7 @@ _mesa_test_framebuffer_completeness(struct gl_context 
> *ctx,
>struct gl_renderbuffer_attachment *att;
>GLenum f;
>gl_format attFormat;
> +  GLenum att_tex_target = GL_NONE;
>  
>/*
> * XXX for ARB_fbo, only check color buffers that are named by
> @@ -945,6 +946,7 @@ _mesa_test_framebuffer_completeness(struct gl_context 
> *ctx,
> */
>if (att->Type == GL_TEXTURE) {
>   const struct gl_texture_image *texImg = att->Renderbuffer->TexImage;
> + att_tex_target = att->Texture->Target;
>   minWidth = MIN2(minWidth, texImg->Width);
>   maxWidth = MAX2(maxWidth, texImg->Width);
>   minHeight = MIN2(minHeight, texImg->Height);
> @@ -1057,7 +1059,14 @@ _mesa_test_framebuffer_completeness(struct gl_context 
> *ctx,
>}
>  
>/* Check that layered rendering is consistent. */
> -  att_layer_count = att->Layered ? att->Renderbuffer->Depth : 0;
> +  if (att->Layered) {
> + if (att_tex_target == GL_TEXTURE_CUBE_MAP)
> +att_layer_count = 6;
> + else
> +att_layer_count = att->Renderbuffer->Depth;
> +  } else {
> + att_layer_count = 0;
> +  }

This seems like a separate change. I'll leave it up to you
whether you bother moving it out or not.

Reviewed-by: Jordan Justen 


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

Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing

[Courtney Goeltzenleuchter]

Hi Chris,

Where are you getting your defines?
I copied them from include/GL/gl.h
#define GL_VIEWPORT 0x0BA2
/* Scissor box */
#define GL_SCISSOR_BOX 0x0C10
#define GL_SCISSOR_TEST 0x0C11
#define GL_SCISSOR_TEST 0x0C11
#define GL_DEPTH_RANGE 0x0B70

Ah, FIRST_VERTEX looks different.
#define GL_FIRST_VERTEX_CONVENTION0x8E4D

I'll add PROVOKING_VERTEX

Looks like UNDEFINED_VERTEX was wrong as well.
(include/GL/glext.h) #define GL_UNDEFINED_VERTEX   0x8260

I was modelling one of the other extension xml files and they had similar
defines, though I could see no effect including or excluding them.

Should I just get rid of the definitions for values that already exist in
gl.h or glext.h?

Courtney

On Thu, Nov 21, 2013 at 1:00 PM, Chris Forbes  wrote:

> I'm surprised the build system accepts the conflicting second definition
> of SCISSOR_BOX at all, actually -- that's weird.
>
>
> On Fri, Nov 22, 2013 at 8:55 AM, Chris Forbes  wrote:
>
>> I mean some of the values don't match the spec :)
>>
>>
>> On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter <
>> court...@lunarg.com> wrote:
>>
>>>
>>>
>>> On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes  wrote:
>>>
 Oops -- the 8E4E is obviously correct. Artifact of me switching how I
 was commenting halfway through.

 On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes  wrote:
 > These are bogus:
 >
 > +
 > +
 > +
 > +
 > +

>>>
>>> What do you mean by "bogus"?
>>> I was emulating other extension xml files. Are these not needed because
>>> they are already defined in gl_ext.h?
>>>
>>>
 >
 > 0x8E4D
 >
 > +
 >
 > 0x8E4E
 >
 > add: 
 >
 > +
 >
 > 0x8260

>>>
>>>
>>>
>>> --
>>> Courtney Goeltzenleuchter
>>> LunarG
>>>
>>>
>>
>


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

Re: [Mesa-dev] [PATCH 2/5] meta: fix meta clear of layered framebuffers

[Marek Olšák]

I currently work on a simpler solution for Gallium. I'm using
AMD_vertex_shader_layer and this vertex shader (I wrote it in TGSI
though):

void main()
{
gl_Position = gl_Vertex;
gl_TexCoord[0] = MultiTexCoord0; // clear color
gl_Layer = gl_InstanceID;
}

Then I render the quad with DrawArraysInstanced and set the instance
count = NumLayers. That way each instance (each quad) is sent to a
different layer and everything is cleared in one draw call.

Drivers not supporting AMD_vertex_shader_layer will have to use a GS though.

Marek


On Wed, Nov 20, 2013 at 5:47 AM, Paul Berry  wrote:
> From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
>
> When the Clear or ClearBuffer* commands are used to clear a
> layered framebuffer attachment, all layers of the attachment are
> cleared.
>
> This patch fixes meta clears to properly clear all layers of a layered
> framebuffer attachment.  We accomplish this by adding a geometry
> shader to the meta clear program which sets gl_Layer to a uniform
> value.  When clearing a layered framebuffer, we execute in a loop,
> setting the uniform to point to each layer in turn.
>
> Cc: "10.0" 
> ---
>  src/mesa/drivers/common/meta.c | 51 
> +++---
>  1 file changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
> index 99b02ba..a6d5098 100644
> --- a/src/mesa/drivers/common/meta.c
> +++ b/src/mesa/drivers/common/meta.c
> @@ -241,9 +241,11 @@ struct clear_state
> GLuint VBO;
> GLuint ShaderProg;
> GLint ColorLocation;
> +   GLint LayerLocation;
>
> GLuint IntegerShaderProg;
> GLint IntegerColorLocation;
> +   GLint IntegerLayerLocation;
>  };
>
>
> @@ -2145,6 +2147,19 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
> clear_state *clear)
>"{\n"
>"   gl_Position = position;\n"
>"}\n";
> +   const char *gs_source =
> +  "#version 150\n"
> +  "layout(triangles) in;\n"
> +  "layout(triangle_strip, max_vertices = 4) out;\n"
> +  "uniform int layer;\n"
> +  "void main()\n"
> +  "{\n"
> +  "  for (int i = 0; i < 3; i++) {\n"
> +  "gl_Layer = layer;\n"
> +  "gl_Position = gl_in[i].gl_Position;\n"
> +  "EmitVertex();\n"
> +  "  }\n"
> +  "}\n";
> const char *fs_source =
>"#ifdef GL_ES\n"
>"precision highp float;\n"
> @@ -2154,7 +2169,7 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
> clear_state *clear)
>"{\n"
>"   gl_FragColor = color;\n"
>"}\n";
> -   GLuint vs, fs;
> +   GLuint vs, gs = 0, fs;
> bool has_integer_textures;
>
> if (clear->ArrayObj != 0)
> @@ -2176,6 +2191,12 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
> clear_state *clear)
> _mesa_ShaderSource(vs, 1, &vs_source, NULL);
> _mesa_CompileShader(vs);
>
> +   if (_mesa_has_geometry_shaders(ctx)) {
> +  gs = _mesa_CreateShaderObjectARB(GL_GEOMETRY_SHADER);
> +  _mesa_ShaderSource(gs, 1, &gs_source, NULL);
> +  _mesa_CompileShader(gs);
> +   }
> +
> fs = _mesa_CreateShaderObjectARB(GL_FRAGMENT_SHADER);
> _mesa_ShaderSource(fs, 1, &fs_source, NULL);
> _mesa_CompileShader(fs);
> @@ -2183,6 +2204,8 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
> clear_state *clear)
> clear->ShaderProg = _mesa_CreateProgramObjectARB();
> _mesa_AttachShader(clear->ShaderProg, fs);
> _mesa_DeleteObjectARB(fs);
> +   if (gs != 0)
> +  _mesa_AttachShader(clear->ShaderProg, gs);
> _mesa_AttachShader(clear->ShaderProg, vs);
> _mesa_DeleteObjectARB(vs);
> _mesa_BindAttribLocation(clear->ShaderProg, 0, "position");
> @@ -2190,6 +2213,10 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
> clear_state *clear)
>
> clear->ColorLocation = _mesa_GetUniformLocation(clear->ShaderProg,
>   "color");
> +   if (gs != 0) {
> +  clear->LayerLocation = _mesa_GetUniformLocation(clear->ShaderProg,
> + "layer");
> +   }
>
> has_integer_textures = _mesa_is_gles3(ctx) ||
>(_mesa_is_desktop_gl(ctx) && ctx->Const.GLSLVersion >= 130);
> @@ -2227,6 +2254,8 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
> clear_state *clear)
>clear->IntegerShaderProg = _mesa_CreateProgramObjectARB();
>_mesa_AttachShader(clear->IntegerShaderProg, fs);
>_mesa_DeleteObjectARB(fs);
> +  if (gs != 0)
> + _mesa_AttachShader(clear->IntegerShaderProg, gs);
>_mesa_AttachShader(clear->IntegerShaderProg, vs);
>_mesa_DeleteObjectARB(vs);
>_mesa_BindAttribLocation(clear->IntegerShaderProg, 0, "position");
> @@ -2240,7 +2269,13 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
> clear_state *clear)
>
>clear->IntegerColorLocation =
>  _mesa_GetUniformLocation(clear->IntegerShaderProg, "color");
> +  if (gs !=

Re: [Mesa-dev] [PATCH v2 5/5] i965: Fix fast clear of depth buffers.

[Jordan Justen]

I sent one suggestion on patch 1.

Series: Reviewed-by: Jordan Justen 

On Wed, Nov 20, 2013 at 2:29 PM, Paul Berry  wrote:
> From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
>
> When the Clear or ClearBuffer* commands are used to clear a
> layered framebuffer attachment, all layers of the attachment are
> cleared.
>
> This patch fixes the fast depth clear path.
>
> Fixes piglit test "spec/!OpenGL 3.2/layered-rendering/clear-depth".
>
> Cc: "10.0" 
> ---
>  src/mesa/drivers/dri/i965/brw_clear.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
> b/src/mesa/drivers/dri/i965/brw_clear.c
> index a727e6e..95a6490 100644
> --- a/src/mesa/drivers/dri/i965/brw_clear.c
> +++ b/src/mesa/drivers/dri/i965/brw_clear.c
> @@ -181,8 +181,16 @@ brw_fast_clear_depth(struct gl_context *ctx)
>  */
> intel_batchbuffer_emit_mi_flush(brw);
>
> -   intel_hiz_exec(brw, mt, depth_irb->mt_level, depth_irb->mt_layer,
> - GEN6_HIZ_OP_DEPTH_CLEAR);
> +   if (fb->NumLayers > 0) {
> +  assert(fb->NumLayers == 
> depth_irb->mt->level[depth_irb->mt_level].depth);
> +  for (unsigned layer = 0; layer < fb->NumLayers; layer++) {
> + intel_hiz_exec(brw, mt, depth_irb->mt_level, layer,
> +GEN6_HIZ_OP_DEPTH_CLEAR);
> +  }
> +   } else {
> +  intel_hiz_exec(brw, mt, depth_irb->mt_level, depth_irb->mt_layer,
> + GEN6_HIZ_OP_DEPTH_CLEAR);
> +   }
>
> if (brw->gen == 6) {
>/* From the Sandy Bridge PRM, volume 2 part 1, page 314:
> --
> 1.8.4.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 1/2] tgsi_ureg: Refactor the ureg_* inline so that all variables are pre-declared.

[Brian Paul]

The patch looks fine, but I'm not sure I understand the comment with 
respect to the code change.  I'd probably just call it something like 
"tgsi: rework calls to ureg_emit_insn()"


But not a big deal.

Reviewed-by: Brian Paul 


On 11/21/2013 07:01 AM, jfons...@vmware.com wrote:

From: José Fonseca 

Mere syntactical change.
---
  src/gallium/auxiliary/tgsi/tgsi_ureg.h | 200 +
  1 file changed, 104 insertions(+), 96 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index e104cd9..cf0c75e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -564,18 +564,19 @@ ureg_fixup_insn_size(struct ureg_program *ureg,
  static INLINE void ureg_##op( struct ureg_program *ureg )   \
  {   \
 unsigned opcode = TGSI_OPCODE_##op;  \
-   unsigned insn = ureg_emit_insn(ureg, \
-  opcode,   \
-  FALSE,\
-  FALSE,\
-  FALSE,\
-  TGSI_SWIZZLE_X,   \
-  TGSI_SWIZZLE_Y,   \
-  TGSI_SWIZZLE_Z,   \
-  TGSI_SWIZZLE_W,   \
-  0,\
-  0).insn_token;\
-   ureg_fixup_insn_size( ureg, insn );  \
+   struct ureg_emit_insn_result insn;   \
+   insn = ureg_emit_insn(ureg,  \
+ opcode,\
+ FALSE, \
+ FALSE, \
+ FALSE, \
+ TGSI_SWIZZLE_X,\
+ TGSI_SWIZZLE_Y,\
+ TGSI_SWIZZLE_Z,\
+ TGSI_SWIZZLE_W,\
+ 0, \
+ 0);\
+   ureg_fixup_insn_size( ureg, insn.insn_token );   \
  }

  #define OP01( op )  \
@@ -583,19 +584,20 @@ static INLINE void ureg_##op( struct ureg_program *ureg,  
  \
struct ureg_src src ) \
  {   \
 unsigned opcode = TGSI_OPCODE_##op;  \
-   unsigned insn = ureg_emit_insn(ureg, \
-  opcode,   \
-  FALSE,\
-  FALSE,\
-  FALSE,\
-  TGSI_SWIZZLE_X,   \
-  TGSI_SWIZZLE_Y,   \
-  TGSI_SWIZZLE_Z,   \
-  TGSI_SWIZZLE_W,   \
-  0,\
-  1).insn_token;\
+   struct ureg_emit_insn_result insn;   \
+   insn = ureg_emit_insn(ureg,  \
+ opcode,\
+ FALSE, \
+ FALSE, \
+ FALSE, \
+ TGSI_SWIZZLE_X,\
+ TGSI_SWIZZLE_Y,\
+ TGSI_SWIZZLE_Z,\
+ TGSI_SWIZZLE_W,\
+ 0, \
+ 1);\
 ureg_emit_src( ureg, src );  \
-   ureg_fixup_insn_size( ureg, insn );  \
+   ureg_fixup_insn_size( ureg, insn.insn_token );   \
  }

  #define OP00_LBL( op )  \
@@ -647,19 +649,20 @@ static INLINE void ureg_##op( struct ureg_program *ureg,  
  \
struct ureg_dst dst ) \
  { 

Re: [Mesa-dev] [PATCH v2 2/5] meta: fix meta clear of layered framebuffers

[Eric Anholt]

Paul Berry  writes:

> From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
>
> When the Clear or ClearBuffer* commands are used to clear a
> layered framebuffer attachment, all layers of the attachment are
> cleared.
>
> This patch fixes meta clears to properly clear all layers of a layered
> framebuffer attachment.  We accomplish this by adding a geometry
> shader to the meta clear program which sets gl_Layer to a uniform
> value.  When clearing a layered framebuffer, we execute in a loop,
> setting the uniform to point to each layer in turn.

I don't think we should be running a gs in the !NumLayers case.  The
other patches are:

Reviewed-by: Eric Anholt 


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

[Mesa-dev] Anonymous structure in uniform question

[f.josef]

Hello,
just recently I encountered a problem when linking shaders, containing 
uniform consisting of anonymous structure.
Here is the code of shaders, triggering the problem:
//vertex shader
uniform struct {vec3 a; vec3 b;} a;
void main()
{
  gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}

//fragment shader
uniform struct {vec3 a; vec3 b;} a;
void main()
{
  gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}

The error message pops up when linking is performed:
error: uniform `a' declared as type `#anon_struct_0002' and type `#anon_
struct_0001'

The problem is, that each anonymous structure gets its own unique type, 
without checking if such type already exists. It seems to me, that such code
is somewhat in the gray area - the rest of OpenGL implementations doesn't 
seem to have a problem with this code (Intel on Win, OSX, Nvidia and AMD 
drivers in Win, OSX and Linux), which of course doesn't mean such a behavior
is correct.

I'd like to ask you, what is your take on this? Should anonymous structs be 
checked against ones seen already and the type name reused when suitable one
is found?
Thank you,

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

Re: [Mesa-dev] [PATCH] docs: Add a section with recommended reading for llvmpipe development.

[Brian Paul]

On 11/21/2013 11:03 AM, jfons...@vmware.com wrote:

From: José Fonseca 

Several links contributed by Keith Whitwell and Roland Scheidegger.
---


Nice.

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 2/2] tgsi: Prevent emission of instructions with empty writemask.

[Roland Scheidegger]

On 11/21/2013 02:01 PM, jfons...@vmware.com wrote:

From: José Fonseca 

These degenerate instructions can often be emitted by state trackers
when the semantics of instructions don't match precisely.
---
  src/gallium/auxiliary/tgsi/tgsi_ureg.c |  8 
  src/gallium/auxiliary/tgsi/tgsi_ureg.h | 22 ++
  2 files changed, 30 insertions(+)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 432ed00..f06858e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1113,6 +1113,10 @@ ureg_insn(struct ureg_program *ureg,
 boolean negate = FALSE;
 unsigned swizzle[4] = { 0 };

+   if (nr_dst && ureg_dst_is_empty(dst[0])) {
+  return;
+   }

This is technically not really correct, as the instruction may have 
multiple destinations.
Not saying we really have any such instructions (or even that we should 
have them), but this helper (and the one below) has code to deal with 
multiple destinations, so that's a bit inconsistent.
Also, there are instructions which have just one dst reg but side 
effects, though it may be restricted to OPCODE_POPA (and I wouldn't mind 
seeing it disappear) (I think the fence/atomic instructions might be 
fine and at first glance I don't see anything else).



 saturate = nr_dst ? dst[0].Saturate : FALSE;
 predicate = nr_dst ? dst[0].Predicate : FALSE;
 if (predicate) {
@@ -1162,6 +1166,10 @@ ureg_tex_insn(struct ureg_program *ureg,
 boolean negate = FALSE;
 unsigned swizzle[4] = { 0 };

+   if (nr_dst && ureg_dst_is_empty(dst[0])) {
+  return;
+   }

Same as above.


 saturate = nr_dst ? dst[0].Saturate : FALSE;
 predicate = nr_dst ? dst[0].Predicate : FALSE;
 if (predicate) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index cf0c75e..d973edb 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -454,6 +454,16 @@ ureg_imm1i( struct ureg_program *ureg,
 return ureg_DECL_immediate_int( ureg, &a, 1 );
  }

+/* Where the destination register has a valid file, but an empty
+ * writemask.
+ */
+static INLINE boolean
+ureg_dst_is_empty( struct ureg_dst dst )
+{
+   return dst.File != TGSI_FILE_NULL &&
+  dst.WriteMask == 0;
+}
+
  /***
   * Functions for patching up labels
   */
@@ -650,6 +660,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
  {   \
 unsigned opcode = TGSI_OPCODE_##op;  \
 struct ureg_emit_insn_result insn;   \
+   if (ureg_dst_is_empty(dst)) return;  \
 insn = ureg_emit_insn(ureg,  \
   opcode,\
   dst.Saturate,  \
@@ -673,6 +684,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
  {   \
 unsigned opcode = TGSI_OPCODE_##op;  \
 struct ureg_emit_insn_result insn;   \
+   if (ureg_dst_is_empty(dst)) return;  \
 insn = ureg_emit_insn(ureg,  \
   opcode,\
   dst.Saturate,  \
@@ -697,6 +709,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
  {   \
 unsigned opcode = TGSI_OPCODE_##op;  \
 struct ureg_emit_insn_result insn;   \
+   if (ureg_dst_is_empty(dst)) return;  \
 insn = ureg_emit_insn(ureg,  \
   opcode,\
   dst.Saturate,  \
@@ -723,6 +736,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
  {   \
 unsigned opcode = TGSI_OPCODE_##op;  \
 struct ureg_emit_insn_result insn;   \
+   if (ureg_dst_is_empty(dst)) return;  \
 insn = ureg_emit_insn(ureg,  \
   opcode,\
   dst.Saturate,  \
@@ -750,6 +764,7 @@ sta

Re: [Mesa-dev] [PATCH 2/2] mesa: fix indentation in ffvertex_prog.c

[Roland Scheidegger]

On 11/21/2013 10:12 PM, Brian Paul wrote:

And use a better assertion.
---
  src/mesa/main/ffvertex_prog.c |   26 ++
  1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index be6ac0f..074fbf9 100644
--- a/src/mesa/main/ffvertex_prog.c
+++ b/src/mesa/main/ffvertex_prog.c
@@ -1306,20 +1306,22 @@ static void build_fog( struct tnl_program *p )

switch (p->state->fog_distance_mode) {
case FDM_EYE_RADIAL: /* Z = sqrt(Xe*Xe + Ye*Ye + Ze*Ze) */
-   input = get_eye_position(p);
-   emit_op2(p, OPCODE_DP3, fog, WRITEMASK_X, input, input);
-   emit_op1(p, OPCODE_RSQ, fog, WRITEMASK_X, fog);
-   emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, fog);
-   break;
+ input = get_eye_position(p);
+ emit_op2(p, OPCODE_DP3, fog, WRITEMASK_X, input, input);
+ emit_op1(p, OPCODE_RSQ, fog, WRITEMASK_X, fog);
+ emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, fog);
+ break;
case FDM_EYE_PLANE: /* Z = Ze */
-   input = get_eye_position_z(p);
-   emit_op1(p, OPCODE_MOV, fog, WRITEMASK_X, input);
-   break;
+ input = get_eye_position_z(p);
+ emit_op1(p, OPCODE_MOV, fog, WRITEMASK_X, input);
+ break;
case FDM_EYE_PLANE_ABS: /* Z = abs(Ze) */
-   input = get_eye_position_z(p);
-   emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
-   break;
-  default: assert(0); break; /* can't happen */
+ input = get_eye_position_z(p);
+ emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
+ break;
+  default:
+ assert(!"Bad fog mode in build_fog()");
+ break;
}

 }



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

Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing

[Chris Forbes]

I was just comparing to the list in the ARB_viewport_array spec.


On Fri, Nov 22, 2013 at 11:33 AM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:

> Hi Chris,
>
> Where are you getting your defines?
> I copied them from include/GL/gl.h
> #define GL_VIEWPORT 0x0BA2
> /* Scissor box */
> #define GL_SCISSOR_BOX 0x0C10
> #define GL_SCISSOR_TEST 0x0C11
> #define GL_SCISSOR_TEST 0x0C11
> #define GL_DEPTH_RANGE 0x0B70
>
> Ah, FIRST_VERTEX looks different.
> #define GL_FIRST_VERTEX_CONVENTION0x8E4D
>
> I'll add PROVOKING_VERTEX
>
> Looks like UNDEFINED_VERTEX was wrong as well.
> (include/GL/glext.h) #define GL_UNDEFINED_VERTEX   0x8260
>
> I was modelling one of the other extension xml files and they had similar
> defines, though I could see no effect including or excluding them.
>
> Should I just get rid of the definitions for values that already exist in
> gl.h or glext.h?
>
> Courtney
>
>
> On Thu, Nov 21, 2013 at 1:00 PM, Chris Forbes  wrote:
>
>> I'm surprised the build system accepts the conflicting second definition
>> of SCISSOR_BOX at all, actually -- that's weird.
>>
>>
>> On Fri, Nov 22, 2013 at 8:55 AM, Chris Forbes  wrote:
>>
>>> I mean some of the values don't match the spec :)
>>>
>>>
>>> On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter <
>>> court...@lunarg.com> wrote:
>>>


 On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes  wrote:

> Oops -- the 8E4E is obviously correct. Artifact of me switching how I
> was commenting halfway through.
>
> On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes 
> wrote:
> > These are bogus:
> >
> > +
> > +
> > +
> > +
> > +
>

 What do you mean by "bogus"?
 I was emulating other extension xml files. Are these not needed because
 they are already defined in gl_ext.h?


> >
> > 0x8E4D
> >
> > +
> >
> > 0x8E4E
> >
> > add: 
> >
> > +
> >
> > 0x8260
>



 --
 Courtney Goeltzenleuchter
 LunarG


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

Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing

[Chris Forbes]

I mean some of the values don't match the spec :)


On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:

>
>
> On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes  wrote:
>
>> Oops -- the 8E4E is obviously correct. Artifact of me switching how I
>> was commenting halfway through.
>>
>> On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes  wrote:
>> > These are bogus:
>> >
>> > +
>> > +
>> > +
>> > +
>> > +
>>
>
> What do you mean by "bogus"?
> I was emulating other extension xml files. Are these not needed because
> they are already defined in gl_ext.h?
>
>
>> >
>> > 0x8E4D
>> >
>> > +
>> >
>> > 0x8E4E
>> >
>> > add: 
>> >
>> > +
>> >
>> > 0x8260
>>
>
>
>
> --
> Courtney Goeltzenleuchter
> LunarG
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing

[Chris Forbes]

I'm surprised the build system accepts the conflicting second definition of
SCISSOR_BOX at all, actually -- that's weird.


On Fri, Nov 22, 2013 at 8:55 AM, Chris Forbes  wrote:

> I mean some of the values don't match the spec :)
>
>
> On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter <
> court...@lunarg.com> wrote:
>
>>
>>
>> On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes  wrote:
>>
>>> Oops -- the 8E4E is obviously correct. Artifact of me switching how I
>>> was commenting halfway through.
>>>
>>> On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes  wrote:
>>> > These are bogus:
>>> >
>>> > +
>>> > +
>>> > +
>>> > +
>>> > +
>>>
>>
>> What do you mean by "bogus"?
>> I was emulating other extension xml files. Are these not needed because
>> they are already defined in gl_ext.h?
>>
>>
>>> >
>>> > 0x8E4D
>>> >
>>> > +
>>> >
>>> > 0x8E4E
>>> >
>>> > add: 
>>> >
>>> > +
>>> >
>>> > 0x8260
>>>
>>
>>
>>
>> --
>> Courtney Goeltzenleuchter
>> LunarG
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/9] gallium/dri2: Set winsys_handle type to KMS for stride query.

[Christopher James Halse Rogers]

On Thu, 2013-11-21 at 14:12 +0100, Thomas Hellstrom wrote:
> On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote:
> > From: Christopher James Halse Rogers 
> >
> > Otherwise the default is TYPE_SHARED, which will flink the bo. This seems
> > rather unnecessary for a simple stride query.
> 
> Is there no way we can cache this stuff in a __DRIimage? Changing the 
> calling conventions to adapt to poor implementations seems like
> the wrong way to go. What if other drivers use a slow approach to get 
> the KMS handle?
> 

It's not really an issue of poor driver implementation - the semantics
of requesting a DRM_API_HANDLE_TYPE_SHARED require that the target be
flinked.

Only the driver actually knows the stride, and AFAIK resource_get_handle
is the only API to get that out of the driver at the moment. So we could
cache it in __DRIimage, but we'd still need to call resource_get_handle
at least once, so the problem remains.

I'm not sure if this is on any critical paths, either, so I'm unsure
whether this being slow matters. Unless asking for a KMS handle causes
the driver to reallocate or something similarly awkward.


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

Re: [Mesa-dev] [PATCH 1/3] Move the code to open the graphic device. Support for render-nodes.

[Kristian Høgsberg]

On Thu, Nov 07, 2013 at 05:13:36PM +0100, Axel Davy wrote:
> This patch moves the code to open the graphic device in the Wayland backend,
> removes the authentication request when we are on a render-node,
> and has a few fixes.
> 
> Signed-off-by: Axel Davy 
> ---
>  src/egl/drivers/dri2/egl_dri2.h |  1 +
>  src/egl/drivers/dri2/platform_wayland.c | 93 
> ++---
>  2 files changed, 63 insertions(+), 31 deletions(-)
> 
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
> index c7d6484..350a626 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -133,6 +133,7 @@ struct dri2_egl_display
> intauthenticated;
> intformats;
> uint32_t  capabilities;
> +   intenable_tiling;
>  #endif
>  
> int (*authenticate) (_EGLDisplay *disp, uint32_t id);
> diff --git a/src/egl/drivers/dri2/platform_wayland.c 
> b/src/egl/drivers/dri2/platform_wayland.c
> index c0de16b..709df36 100644
> --- a/src/egl/drivers/dri2/platform_wayland.c
> +++ b/src/egl/drivers/dri2/platform_wayland.c
> @@ -622,8 +622,8 @@ dri2_terminate(_EGLDriver *drv, _EGLDisplay *disp)
> _eglCleanupDisplay(disp);
>  
> dri2_dpy->core->destroyScreen(dri2_dpy->dri_screen);
> -   close(dri2_dpy->fd);
> dlclose(dri2_dpy->driver);
> +   close(dri2_dpy->fd);

Why is this necessary?  If it's a fix not a typo, it should be in its
own patch.

> free(dri2_dpy->driver_name);
> free(dri2_dpy->device_name);
> wl_drm_destroy(dri2_dpy->wl_drm);
> @@ -635,34 +635,28 @@ dri2_terminate(_EGLDriver *drv, _EGLDisplay *disp)
> return EGL_TRUE;
>  }
>  
> +static char
> +is_fd_render_node(int fd)
> +{
> +  struct stat render;
> +
> +  if (fstat(fd, &render))
> +return 0;
> +
> +  if (!S_ISCHR(render.st_mode))
> +return 0;
> +
> +  if (render.st_rdev & 0x80)
> +return 1;
> +  return 0;
> +}

mesa (and in particular this file) uses 3 space indents, please follow
the convention.

>  static void
>  drm_handle_device(void *data, struct wl_drm *drm, const char *device)
>  {
> struct dri2_egl_display *dri2_dpy = data;
> -   drm_magic_t magic;
>  
> dri2_dpy->device_name = strdup(device);
> -   if (!dri2_dpy->device_name)
> -  return;
> -
> -#ifdef O_CLOEXEC
> -   dri2_dpy->fd = open(dri2_dpy->device_name, O_RDWR | O_CLOEXEC);
> -   if (dri2_dpy->fd == -1 && errno == EINVAL)
> -#endif
> -   {
> -  dri2_dpy->fd = open(dri2_dpy->device_name, O_RDWR);
> -  if (dri2_dpy->fd != -1)
> - fcntl(dri2_dpy->fd, F_SETFD, fcntl(dri2_dpy->fd, F_GETFD) |
> -FD_CLOEXEC);
> -   }
> -   if (dri2_dpy->fd == -1) {
> -  _eglLog(_EGL_WARNING, "wayland-egl: could not open %s (%s)",
> -   dri2_dpy->device_name, strerror(errno));
> -  return;
> -   }
> -
> -   drmGetMagic(dri2_dpy->fd, &magic);
> -   wl_drm_authenticate(dri2_dpy->wl_drm, magic);
>  }
>  
>  static void
> @@ -738,7 +732,8 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay 
> *disp)
> struct dri2_egl_display *dri2_dpy;
> const __DRIconfig *config;
> uint32_t types;
> -   int i;
> +   int i, is_render_node;
> +   drm_magic_t magic;
> static const unsigned int argb_masks[4] =
>{ 0xff, 0xff00, 0xff, 0xff00 };
> static const unsigned int rgb_masks[4] = { 0xff, 0xff00, 0xff, 0 };
> @@ -778,9 +773,39 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay 
> *disp)
> if (roundtrip(dri2_dpy) < 0 || dri2_dpy->wl_drm == NULL)
>goto cleanup_dpy;
>  
> -   if (roundtrip(dri2_dpy) < 0 || dri2_dpy->fd == -1)
> +   if (roundtrip(dri2_dpy) < 0 || dri2_dpy->device_name == NULL)
>goto cleanup_drm;
>  
> +#ifdef O_CLOEXEC
> +   dri2_dpy->fd = open(dri2_dpy->device_name, O_RDWR | O_CLOEXEC);
> +   if (dri2_dpy->fd == -1 && errno == EINVAL)
> +#endif
> +   {
> +  dri2_dpy->fd = open(dri2_dpy->device_name, O_RDWR);
> +  if (dri2_dpy->fd != -1)
> + fcntl(dri2_dpy->fd, F_SETFD, fcntl(dri2_dpy->fd, F_GETFD) |
> +FD_CLOEXEC);
> +   }

Let's start out with a patch to split this O_CLOEXEC helper out into
its own function, open_cloexec() or something.  Having this compat
logic here makes the interesting code harder to follow and your 3/3
patch duplicates it.

> +   if (dri2_dpy->fd == -1) {
> +  _eglLog(_EGL_WARNING, "wayland-egl: could not open %s (%s)",
> +   dri2_dpy->device_name, strerror(errno));
> +  goto cleanup_drm;
> +   }
> +
> +   if (is_fd_render_node(dri2_dpy->fd))

I would like the compositor to still send the classic drm device in
the wl_drm.device event.  The client can then use stat(2) to stat it
and defer the corresponding render node from that by adding 128 to the
minor.  This way we don't break older mesa versions by sending them a
render node that they'll then fail to authenticate.

> +   {

The open brace '{' goes on the same line as the if

Re: [Mesa-dev] [PATCH 2/3] Create untiled buffers in get_back_bo when needed.

[Kristian Høgsberg]

On Thu, Nov 07, 2013 at 05:13:37PM +0100, Axel Davy wrote:
> We must send to the compositor buffer it is able to read.
> 
> Since tiling modes are different on graphic cards, we have
> to disable tiling when creating the buffers if we render
> with a different graphic card than the compositor.
> 
> Signed-off-by: Axel Davy 

This looks fine.

Kristian

> ---
>  src/egl/drivers/dri2/platform_wayland.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/src/egl/drivers/dri2/platform_wayland.c 
> b/src/egl/drivers/dri2/platform_wayland.c
> index 709df36..b922ff5 100644
> --- a/src/egl/drivers/dri2/platform_wayland.c
> +++ b/src/egl/drivers/dri2/platform_wayland.c
> @@ -283,12 +283,17 @@ get_back_bo(struct dri2_egl_surface *dri2_surf, 
> __DRIbuffer *buffer)
> if (dri2_surf->back == NULL)
>return -1;
> if (dri2_surf->back->dri_image == NULL) {
> -  dri2_surf->back->dri_image = 
> - dri2_dpy->image->createImage(dri2_dpy->dri_screen,
> -  dri2_surf->base.Width,
> -  dri2_surf->base.Height,
> -  __DRI_IMAGE_FORMAT_ARGB,
> -  __DRI_IMAGE_USE_SHARE,
> +  unsigned int use_flags = __DRI_IMAGE_USE_SHARE;
> +
> +  if (!dri2_dpy->enable_tiling)
> + use_flags |= __DRI_IMAGE_USE_LINEAR;
> +
> +   dri2_surf->back->dri_image = 
> +  dri2_dpy->image->createImage(dri2_dpy->dri_screen,
> +   dri2_surf->base.Width,
> +   dri2_surf->base.Height,
> +   __DRI_IMAGE_FORMAT_ARGB,
> +  use_flags,
>NULL);
>dri2_surf->back->age = 0;
> }
> -- 
> 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 0/3] Implement DRI_PRIME support for Wayland

[Kristian Høgsberg]

On Thu, Nov 07, 2013 at 05:13:35PM +0100, Axel Davy wrote:
> These patches enable using DRI_PRIME to use a different card
> than the compositor card (with render-nodes).
> 
> At the time of writing, Mesa Wayland egl backend doesn't
> support render-nodes, because it uses the dri2 backend, which
> require using GEM names (render-nodes aren't allowed to use GEM
> names). But I'm confident this week or next week, the __DRIimage
> remplacement will be ready, thanks to Keith Packard, Kristian Hosberg
> and Christopher James Halse Rogers.
> That's why I'm publishing these patches now, so they have the time
> to be reviewed.
> 
> Initially, I wanted to use driconf too, as a complement of DRI_PRIME,
> but driconf doesn't support string parameters yet, so it'll come later.
> 
> To choose a specific device, the user has to specify the id_path_tag of
> the device he wants to use. We get the id_path_tag with udev. Systemd
> didn't fill this field for render-nodes, so it has to be set as an additional
> rule. David Herrmann has sent a patch for that for Systemd, but I don't know 
> if
> it is already pushed.
> 
> The choice to use id_path_tag comes to the fact that the id_path is stable,
> and that it describes non-pci graphic devices too (usb devices, etc). 
> 
> An alternative to choose the device to use is to set DRI_PRIME to "1",
> which means "choose any other card than the one used by the compositor".
> 
> If Mesa doesn't find the device asked by the user, it will use the same
> card than the Wayland compositor.
> 
> The Wayland Prime support implemented with these patches is different
> from X Prime support.
> 
> A client using an other card than the compositor will allocate buffers
> with no-tiling to render to, and share them with the compositor, unlike
> on X, where it would render to a tiled buffer, not shared with the other card,
> and a copy mechanism will make the main card receive an untiled buffer.
> 
> That means that these (Wayland) clients will perform slowly, compared to
> if they weren't using Prime.
> In fact it is not how the user is supposed to run a game, for example,
> on its dedicated card.
> 
> Using a shared, untiled-buffer, but avoiding any copy, is better for 
> application which wouldn't do much rendering.
> 
> An example of such an application is an embedded Wayland compositor.
> 
> To use an heavy application, the user is supposed to launch an
> embedded Wayland compositor on the dedicated card, and run the game
> inside. The compositor will render into the shared, untiled buffer,
> and will copy the content of the game buffers.
> 
> Note that the game know it is using the same cards than its compositor,
> that's why it enables tiling.
> 
> I'm planning to write a Weston shell, designed to run embedded fullscreen 
> games,
> that would make Weston resize to the game size, and close when it closes.

I'm not sold on the nested compositor for this use case.  It
introduces another context switch between the game and the main
compositor and more input and output lag.  Instead I think we need to
consider whether we want a new __DRIimage entry point like:

  (*blitImage)(__DRIcontext *ctx, __DRIimage *src, __DRIimage *ctx)

and then do the copy in platform_wayland.c when we have non-matching
tile-formats.

Kristian

> Pros:
> .If you launch a fullscreen Wayland compositor on the dedicated card,
> inside a compositor supporting composite bypass, you'll render the whole
> desktop on the dedicated card. The integrated card would only display
> the buffer generated, without doing any copy.
> .More flexibility
> 
> 
> Cons: 
> .The user has to use a script to launch a game on the dedicated card.
> 
> Pros over X dri2 Prime support:
> .Vsync works, whatever the cards used by the client 
> .You can understand easily how prime support works
> 
> 
> As a last note, this Prime support suffers too from the
> lack of dma-buf fences (glitches when the client is still writing
> on the buffer when the compositor's card reads it).
> Using an embedded compositor suppress all the glitches when
> it doesn't take (1/refresh_rate) seconds for it to render a frame,
> that is when you don't have an input lag.
> 
> 
> 
> Axel Davy (3):
>   Move the code to open the graphic device. Support for
> render-nodes.
>   Create untiled buffers in get_back_bo when needed.
>   Implement choosing the device to use with DRI_PRIME
> 
>  src/egl/drivers/dri2/egl_dri2.h |   1 +
>  src/egl/drivers/dri2/platform_wayland.c | 262 
> +++-
>  2 files changed, 226 insertions(+), 37 deletions(-)
> 
> -- 
> 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] [PATCH] docs: Add a section with recommended reading for llvmpipe development.

[jfonseca]

From: José Fonseca 

Several links contributed by Keith Whitwell and Roland Scheidegger.
---
 docs/llvmpipe.html | 58 --
 1 file changed, 56 insertions(+), 2 deletions(-)

diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html
index 80f8a01..d695907 100644
--- a/docs/llvmpipe.html
+++ b/docs/llvmpipe.html
@@ -203,11 +203,65 @@ for posterior analysis, e.g.:
   We use LLVM-C bindings for now. They are not documented, but follow the C++
   interfaces very closely, and appear to be complete enough for code
   generation. See 
-  http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html
-  for a stand-alone example.  See the llvm-c/Core.h file for reference.
+  http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html";>
+  this stand-alone example.  See the llvm-c/Core.h file for reference.
 
 
 
+Recommended Reading
+
+
+  
+Rasterization
+
+  http://www.cs.unc.edu/~olano/papers/2dh-tri/";>Triangle Scan 
Conversion using 2D Homogeneous Coordinates
+  http://www.drdobbs.com/parallel/rasterization-on-larrabee/217200602";>Rasterization
 on Larrabee (http://devmaster.net/posts/2887/rasterization-on-larrabee";>DevMaster 
copy)
+  http://devmaster.net/posts/6133/rasterization-using-half-space-functions";>Rasterization
 using half-space functions
+  http://devmaster.net/posts/6145/advanced-rasterization";>Advanced 
Rasterization
+  http://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlusion-culling-index/";>Optimizing
 Software Occlusion Culling
+
+  
+  
+Texture sampling
+
+  http://chrishecker.com/Miscellaneous_Technical_Articles#Perspective_Texture_Mapping";>Perspective
 Texture Mapping
+  http://www.flipcode.com/archives/Texturing_As_In_Unreal.shtml";>Texturing 
As In Unreal
+  http://www.gamasutra.com/view/feature/3301/runtime_mipmap_filtering.php";>Run-Time
 MIP-Map Filtering
+  http://alt.3dcenter.org/artikel/2003/10-26_a_english.php";>Will 
"brilinear" filtering persist?
+  http://ixbtlabs.com/articles2/gffx/nv40-rx800-3.html";>Trilinear 
filtering
+  http://devmaster.net/posts/12785/texture-swizzling";>Texture 
Swizzling
+
+  
+  
+SIMD
+
+  http://www.cdl.uni-saarland.de/projects/wfv/#header4";>Whole-Function 
Vectorization
+
+  
+  
+Optimization
+
+  http://www.drdobbs.com/optimizing-pixomatic-for-modern-x86-proc/184405807";>Optimizing
 Pixomatic For Modern x86 Processors
+  http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html";>Intel
 64 and IA-32 Architectures Optimization Reference Manual
+  http://www.agner.org/optimize/";>Software optimization 
resources
+  http://software.intel.com/en-us/articles/intel-intrinsics-guide";>Intel 
Intrinsics Guide
+
+  
+  
+LLVM
+
+  http://llvm.org/docs/LangRef.html";>LLVM Language Reference 
Manual
+  http://npcontemplation.blogspot.co.uk/2008/06/secret-of-llvm-c-bindings.html";>The
 secret of LLVM C bindings
+
+  
+  
+Misc
+
+  http://msdn.microsoft.com/en-us/library/gg615082.aspx#architecture";>WARP 
Architecture and Performance
+
+  
+
+
 
 
 
-- 
1.8.3.2

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

Re: [Mesa-dev] [PATCH 2/2] tgsi: Prevent emission of instructions with empty writemask.

[Brian Paul]

On 11/21/2013 07:01 AM, jfons...@vmware.com wrote:

From: José Fonseca 

These degenerate instructions can often be emitted by state trackers
when the semantics of instructions don't match precisely.
---
  src/gallium/auxiliary/tgsi/tgsi_ureg.c |  8 
  src/gallium/auxiliary/tgsi/tgsi_ureg.h | 22 ++
  2 files changed, 30 insertions(+)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 432ed00..f06858e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1113,6 +1113,10 @@ ureg_insn(struct ureg_program *ureg,
 boolean negate = FALSE;
 unsigned swizzle[4] = { 0 };

+   if (nr_dst && ureg_dst_is_empty(dst[0])) {
+  return;
+   }
+
 saturate = nr_dst ? dst[0].Saturate : FALSE;
 predicate = nr_dst ? dst[0].Predicate : FALSE;
 if (predicate) {
@@ -1162,6 +1166,10 @@ ureg_tex_insn(struct ureg_program *ureg,
 boolean negate = FALSE;
 unsigned swizzle[4] = { 0 };

+   if (nr_dst && ureg_dst_is_empty(dst[0])) {
+  return;
+   }
+
 saturate = nr_dst ? dst[0].Saturate : FALSE;
 predicate = nr_dst ? dst[0].Predicate : FALSE;
 if (predicate) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index cf0c75e..d973edb 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -454,6 +454,16 @@ ureg_imm1i( struct ureg_program *ureg,
 return ureg_DECL_immediate_int( ureg, &a, 1 );
  }

+/* Where the destination register has a valid file, but an empty
+ * writemask.
+ */
+static INLINE boolean
+ureg_dst_is_empty( struct ureg_dst dst )
+{
+   return dst.File != TGSI_FILE_NULL &&
+  dst.WriteMask == 0;
+}
+
  /***
   * Functions for patching up labels
   */
@@ -650,6 +660,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
  {   \
 unsigned opcode = TGSI_OPCODE_##op;  \
 struct ureg_emit_insn_result insn;   \
+   if (ureg_dst_is_empty(dst)) return;  \


If it were me, I'd put the return stmt on the next line in case someone 
wanted to put a breakpoint on that event.


Reviewed-by: Brian Paul 

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

[Mesa-dev] [PATCH 1/2] tgsi_ureg: Refactor the ureg_* inline so that all variables are pre-declared.

[jfonseca]

From: José Fonseca 

Mere syntactical change.
---
 src/gallium/auxiliary/tgsi/tgsi_ureg.h | 200 +
 1 file changed, 104 insertions(+), 96 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index e104cd9..cf0c75e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -564,18 +564,19 @@ ureg_fixup_insn_size(struct ureg_program *ureg,
 static INLINE void ureg_##op( struct ureg_program *ureg )   \
 {   \
unsigned opcode = TGSI_OPCODE_##op;  \
-   unsigned insn = ureg_emit_insn(ureg, \
-  opcode,   \
-  FALSE,\
-  FALSE,\
-  FALSE,\
-  TGSI_SWIZZLE_X,   \
-  TGSI_SWIZZLE_Y,   \
-  TGSI_SWIZZLE_Z,   \
-  TGSI_SWIZZLE_W,   \
-  0,\
-  0).insn_token;\
-   ureg_fixup_insn_size( ureg, insn );  \
+   struct ureg_emit_insn_result insn;   \
+   insn = ureg_emit_insn(ureg,  \
+ opcode,\
+ FALSE, \
+ FALSE, \
+ FALSE, \
+ TGSI_SWIZZLE_X,\
+ TGSI_SWIZZLE_Y,\
+ TGSI_SWIZZLE_Z,\
+ TGSI_SWIZZLE_W,\
+ 0, \
+ 0);\
+   ureg_fixup_insn_size( ureg, insn.insn_token );   \
 }
 
 #define OP01( op )  \
@@ -583,19 +584,20 @@ static INLINE void ureg_##op( struct ureg_program *ureg,  
  \
   struct ureg_src src ) \
 {   \
unsigned opcode = TGSI_OPCODE_##op;  \
-   unsigned insn = ureg_emit_insn(ureg, \
-  opcode,   \
-  FALSE,\
-  FALSE,\
-  FALSE,\
-  TGSI_SWIZZLE_X,   \
-  TGSI_SWIZZLE_Y,   \
-  TGSI_SWIZZLE_Z,   \
-  TGSI_SWIZZLE_W,   \
-  0,\
-  1).insn_token;\
+   struct ureg_emit_insn_result insn;   \
+   insn = ureg_emit_insn(ureg,  \
+ opcode,\
+ FALSE, \
+ FALSE, \
+ FALSE, \
+ TGSI_SWIZZLE_X,\
+ TGSI_SWIZZLE_Y,\
+ TGSI_SWIZZLE_Z,\
+ TGSI_SWIZZLE_W,\
+ 0, \
+ 1);\
ureg_emit_src( ureg, src );  \
-   ureg_fixup_insn_size( ureg, insn );  \
+   ureg_fixup_insn_size( ureg, insn.insn_token );   \
 }
 
 #define OP00_LBL( op )  \
@@ -647,19 +649,20 @@ static INLINE void ureg_##op( struct ureg_program *ureg,  
  \
   struct ureg_dst dst ) \
 {   \
unsigned opcode = TGSI_OPCODE_##op;  \
-   unsigned insn = ureg_emit_insn(ureg, \
-  opcode,   \
-   

Re: [Mesa-dev] [PATCH 3/9] gallium/dri2: Set winsys_handle type to KMS for stride query.

[Thomas Hellstrom]

On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote:

From: Christopher James Halse Rogers 

Otherwise the default is TYPE_SHARED, which will flink the bo. This seems
rather unnecessary for a simple stride query.


Is there no way we can cache this stuff in a __DRIimage? Changing the 
calling conventions to adapt to poor implementations seems like
the wrong way to go. What if other drivers use a slow approach to get 
the KMS handle?


/Thomas



---
  src/gallium/state_trackers/dri/drm/dri2.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index 42c863b..db034bd 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -691,6 +691,7 @@ dri2_query_image(__DRIimage *image, int attrib, int *value)
  
 switch (attrib) {

 case __DRI_IMAGE_ATTRIB_STRIDE:
+  whandle.type = DRM_API_HANDLE_TYPE_KMS;
image->texture->screen->resource_get_handle(image->texture->screen,
  image->texture, &whandle);
*value = whandle.stride;

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

Re: [Mesa-dev] [v3 0/8] Add ARB_texture_view

[Brian Paul]

On 11/19/2013 04:16 PM, Courtney Goeltzenleuchter wrote:

The following patches add the necessary functions to Mesa
to support ARB_texture_view. These patches do not include
the actual driver elements, just the device independent portion.
This extension requires ARB_texture_storage.

The extension supports one new API call, glTextureView and
a handful of enums that have been added as queriable texture
parameters.

Adds one new driver entry point for the driver to
map the view specified onto the origtexture given.

Includes review feedback and a bug fix in compatible_format.

Passes non-rendering ARB_texture_view piglit tests.

Courtney Goeltzenleuchter (8):
   mesa: Add API definitions for ARB_texture_view
   mesa: Tracking for ARB_texture_view extension
   mesa: update texture object for ARB_texture_view
   mesa: ARB_texture_view get parameters
   mesa: Add driver entry point for ARB_texture_view
   mesa: Fill out ARB_texture_view entry points
   mesa: add texture_view helper function for TexStorage
   mesa: Update TexStorage to support ARB_texture_view

  src/mapi/glapi/gen/ARB_texture_view.xml |  23 ++
  src/mapi/glapi/gen/Makefile.am  |   1 +
  src/mapi/glapi/gen/gl_API.xml   |   4 +-
  src/mapi/glapi/gen/gl_genexec.py|   1 +
  src/mesa/Makefile.sources   |   1 +
  src/mesa/SConscript |   1 +
  src/mesa/drivers/common/driverfuncs.c   |   3 +
  src/mesa/main/dd.h  |   5 +
  src/mesa/main/extensions.c  |   1 +
  src/mesa/main/mtypes.h  |   6 +
  src/mesa/main/tests/dispatch_sanity.cpp |   2 +-
  src/mesa/main/teximage.c|   6 +
  src/mesa/main/texparam.c|  60 ++-
  src/mesa/main/texstorage.c  |   5 +-
  src/mesa/main/textureview.c | 684 
  src/mesa/main/textureview.h |  43 ++
  16 files changed, 838 insertions(+), 8 deletions(-)
  create mode 100644 src/mapi/glapi/gen/ARB_texture_view.xml
  create mode 100644 src/mesa/main/textureview.c
  create mode 100644 src/mesa/main/textureview.h



For patches 1-4, 8:  Reviewed-by: Brian Paul 
For patches 5-7: minor comments

Nice work.

-Brian

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

Re: [Mesa-dev] [v3 5/8] mesa: Add driver entry point for ARB_texture_view

[Brian Paul]

On 11/19/2013 04:16 PM, Courtney Goeltzenleuchter wrote:


Signed-off-by: Courtney Goeltzenleuchter 
---
  src/mesa/drivers/common/driverfuncs.c | 3 +++
  src/mesa/main/dd.h| 5 +
  2 files changed, 8 insertions(+)

diff --git a/src/mesa/drivers/common/driverfuncs.c 
b/src/mesa/drivers/common/driverfuncs.c
index 5faa98a..f185688 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -211,6 +211,9 @@ _mesa_init_driver_functions(struct dd_function_table 
*driver)
 /* GL_ARB_texture_storage */
 driver->AllocTextureStorage = _mesa_alloc_texture_storage;

+   /* GL_ARB_texture_view */
+   driver->TextureView = NULL;
+
 /* GL_ARB_texture_multisample */
 driver->GetSamplePosition = NULL;
  }
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index b5b874f..3e263f4 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -375,6 +375,11 @@ struct dd_function_table {
  GLsizei levels, GLsizei width,
  GLsizei height, GLsizei depth);

+   /** Called as part of glTextureView to add views to origTexObj */
+   GLboolean (*TextureView)(struct gl_context *ctx,
+struct gl_texture_object *texObj,
+struct gl_texture_object *origTexObj);


Either the comment on this function, or the place where it's called from 
should probably be beefed up with more info about what's expected of the 
driver.  Is it possible to return FALSE for any reason beyond out-of-memory?





+
 /**
  * Map a renderbuffer into user space.
  * \param mode  bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT and



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

Re: [Mesa-dev] [v3 7/8] mesa: add texture_view helper function for TexStorage

[Brian Paul]

On 11/19/2013 04:16 PM, Courtney Goeltzenleuchter wrote:

Add helper function to set texture_view state from TexStorage calls.

Signed-off-by: Courtney Goeltzenleuchter 
---
  src/mesa/main/textureview.c | 59 +
  src/mesa/main/textureview.h |  4 +++
  2 files changed, 63 insertions(+)

diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
index 1858465..a25b928 100644
--- a/src/mesa/main/textureview.c
+++ b/src/mesa/main/textureview.c
@@ -379,6 +379,65 @@ compatible_format(struct gl_context *ctx, struct 
gl_texture_object *origTexObj,
 _mesa_lookup_enum_by_nr(origInternalFormat));
 return GL_FALSE;
  }
+/**
+ * Helper function for TexStorage to set TextureView state
+ */


Could you put a bit more info into that comment?


+void
+set_texture_view_state(struct gl_context *ctx, struct gl_texture_object 
*texObj,
+   GLenum target, GLuint levels)


non-static functions should be prefixed with "_mesa_".



+{
+   struct gl_texture_image *texImage;
+
+   /* Get a reference to what will become this View's base level */
+   texImage = _mesa_select_tex_image(ctx, texObj, target, 0);


Early return if texImage is NULL (out of memory, etc?)?



+
+   /* If the command is successful,


If what command is successful?  glTexStorage()?



+* TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
+* TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become levels.
+* If the texture target is TEXTURE_1D_ARRAY then
+* TEXTURE_VIEW_NUM_LAYERS becomes height.
+* If the texture target is TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY,
+* or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS becomes 
depth.
+* If the texture target is TEXTURE_CUBE_MAP, then
+* TEXTURE_VIEW_NUM_LAYERS becomes 6.
+* For any other texture target, TEXTURE_VIEW_NUM_LAYERS becomes 1.
+*
+* ARB_texture_multisample: Multisample textures do
+* not have multiple image levels.
+*/
+
+   texObj->Immutable = GL_TRUE;
+   texObj->ImmutableLevels = levels;
+   texObj->MinLevel = 0;
+   texObj->NumLevels = levels;
+   texObj->MinLayer = 0;
+   texObj->NumLayers = 1;
+   switch (target) {
+   case GL_TEXTURE_1D_ARRAY:
+  texObj->NumLayers = texImage->Height;
+  break;
+
+   case GL_TEXTURE_2D_MULTISAMPLE:
+  texObj->NumLevels = 1;
+  texObj->ImmutableLevels = 1;
+  break;
+
+   case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
+  texObj->NumLevels = 1;
+  texObj->ImmutableLevels = 1;
+  /* fall through to set NumLayers */
+
+   case GL_TEXTURE_2D_ARRAY:
+   case GL_TEXTURE_CUBE_MAP_ARRAY:
+  texObj->NumLayers = texImage->Depth;
+  break;
+
+   case GL_TEXTURE_CUBE_MAP:
+  texObj->NumLayers = 6;
+  break;
+
+   }
+}

  /**
   * glTextureView (ARB_texture_view)
diff --git a/src/mesa/main/textureview.h b/src/mesa/main/textureview.h
index c2f0f32..36a8ed3 100644
--- a/src/mesa/main/textureview.h
+++ b/src/mesa/main/textureview.h
@@ -36,4 +36,8 @@ _mesa_TextureView(GLuint texture, GLenum target, GLuint 
origtexture,
GLuint minlevel, GLuint numlevels,
GLuint minlayer, GLuint numlayers);

+extern void
+set_texture_view_state(struct gl_context *ctx, struct gl_texture_object 
*texObj,
+   GLenum target, GLuint levels);
+
  #endif /* TEXTUREVIEW_H */



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

[Mesa-dev] [PATCH 2/2] tgsi: Prevent emission of instructions with empty writemask.

[jfonseca]

From: José Fonseca 

These degenerate instructions can often be emitted by state trackers
when the semantics of instructions don't match precisely.
---
 src/gallium/auxiliary/tgsi/tgsi_ureg.c |  8 
 src/gallium/auxiliary/tgsi/tgsi_ureg.h | 22 ++
 2 files changed, 30 insertions(+)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 432ed00..f06858e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1113,6 +1113,10 @@ ureg_insn(struct ureg_program *ureg,
boolean negate = FALSE;
unsigned swizzle[4] = { 0 };
 
+   if (nr_dst && ureg_dst_is_empty(dst[0])) {
+  return;
+   }
+
saturate = nr_dst ? dst[0].Saturate : FALSE;
predicate = nr_dst ? dst[0].Predicate : FALSE;
if (predicate) {
@@ -1162,6 +1166,10 @@ ureg_tex_insn(struct ureg_program *ureg,
boolean negate = FALSE;
unsigned swizzle[4] = { 0 };
 
+   if (nr_dst && ureg_dst_is_empty(dst[0])) {
+  return;
+   }
+
saturate = nr_dst ? dst[0].Saturate : FALSE;
predicate = nr_dst ? dst[0].Predicate : FALSE;
if (predicate) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index cf0c75e..d973edb 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -454,6 +454,16 @@ ureg_imm1i( struct ureg_program *ureg,
return ureg_DECL_immediate_int( ureg, &a, 1 );
 }
 
+/* Where the destination register has a valid file, but an empty
+ * writemask.
+ */
+static INLINE boolean
+ureg_dst_is_empty( struct ureg_dst dst )
+{
+   return dst.File != TGSI_FILE_NULL &&
+  dst.WriteMask == 0;
+}
+
 /***
  * Functions for patching up labels
  */
@@ -650,6 +660,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
 {   \
unsigned opcode = TGSI_OPCODE_##op;  \
struct ureg_emit_insn_result insn;   \
+   if (ureg_dst_is_empty(dst)) return;  \
insn = ureg_emit_insn(ureg,  \
  opcode,\
  dst.Saturate,  \
@@ -673,6 +684,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
 {   \
unsigned opcode = TGSI_OPCODE_##op;  \
struct ureg_emit_insn_result insn;   \
+   if (ureg_dst_is_empty(dst)) return;  \
insn = ureg_emit_insn(ureg,  \
  opcode,\
  dst.Saturate,  \
@@ -697,6 +709,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
 {   \
unsigned opcode = TGSI_OPCODE_##op;  \
struct ureg_emit_insn_result insn;   \
+   if (ureg_dst_is_empty(dst)) return;  \
insn = ureg_emit_insn(ureg,  \
  opcode,\
  dst.Saturate,  \
@@ -723,6 +736,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
 {   \
unsigned opcode = TGSI_OPCODE_##op;  \
struct ureg_emit_insn_result insn;   \
+   if (ureg_dst_is_empty(dst)) return;  \
insn = ureg_emit_insn(ureg,  \
  opcode,\
  dst.Saturate,  \
@@ -750,6 +764,7 @@ static INLINE void ureg_##op( struct ureg_program *ureg,
\
unsigned opcode = TGSI_OPCODE_##op;  \
unsigned target = TGSI_TEXTURE_UNKNOWN;  \
struct ureg_emit_insn_result insn;   \
+   if (ureg_dst_is_empty(dst)) return;  \
insn = ureg_emit_insn(ureg,  \
  opcode,\
  dst.Saturate,  \
@@ -777,6 +792,7 @@ static INLINE void ureg_##op( struct ureg_prog

Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing

[Courtney Goeltzenleuchter]

On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes  wrote:

> Oops -- the 8E4E is obviously correct. Artifact of me switching how I
> was commenting halfway through.
>
> On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes  wrote:
> > These are bogus:
> >
> > +
> > +
> > +
> > +
> > +
>

What do you mean by "bogus"?
I was emulating other extension xml files. Are these not needed because
they are already defined in gl_ext.h?


> >
> > 0x8E4D
> >
> > +
> >
> > 0x8E4E
> >
> > add: 
> >
> > +
> >
> > 0x8260
>



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

Re: [Mesa-dev] [PATCH 2/5] meta: fix meta clear of layered framebuffers

[Paul Berry]

On 21 November 2013 05:21, Marek Olšák  wrote:

> I currently work on a simpler solution for Gallium. I'm using
> AMD_vertex_shader_layer and this vertex shader (I wrote it in TGSI
> though):
>
> void main()
> {
> gl_Position = gl_Vertex;
> gl_TexCoord[0] = MultiTexCoord0; // clear color
> gl_Layer = gl_InstanceID;
> }
>
> Then I render the quad with DrawArraysInstanced and set the instance
> count = NumLayers. That way each instance (each quad) is sent to a
> different layer and everything is cleared in one draw call.
>
> Drivers not supporting AMD_vertex_shader_layer will have to use a GS
> though.
>

Your approach potentially has better performance, but I'm concerned about
risk, because I'm hoping to get this patch cherry-picked into 10.0 (which
is due to be released in a week).  Currently GLSL clear uses 4 different
shaders:

1. A vertex shader that just sets gl_Position (compilable for either
desktop GLSL 1.10 or GLSL ES 1.00)
2. A vertex shader that just sets gl_Position (compilable for either
desktop GLSL 1.30 or GLSL ES 3.00)
3. A fragment shader that outputs floating point color (compilable for
either desktop GLSL or GLSL ES)
4. A fragment shader that outputs integer color (compilable for either
desktop GLSL 1.30 or GLSL ES 3.00)

My proposal adds a fifth:

5. A geometry shader that sets gl_Position and gl_Layer

If we want to use gl_InstanceID and AMD_vertex_shader_layer, we would have
to add two more:

6. A vertex shader that sets gl_Position and gl_Layer (for drivers that
support AMD_vertex_shader_layer)
7. A vertex shader that sets gl_Position and passes through gl_InstanceID
to the GS (for drivers that support GS but not AMD_vertex_shader_layer)

Testing on the Meta clear path is already pretty thin (at least for i965)
because most i965 clears can be done by faster mechanisms (fast color
clear, fast depth clear, or the "blorp" color clear).  I'm worried about
introducing 3 new shaders to a poorly-tested Meta path this late in the
release process.

Anyone want to weigh in on this subject from a risk perspective?

I'm also wondering how important performance really is in this patch.  I
suspect it's not a big issue for i965, since i965 usually does clears using
faster mechanisms.  It's not an issue for i915, since i915 doesn't support
geometry shaders.  Are there other drivers that use Meta other than those
two?  If not, I'm tempted to leave this patch as is, based on the reasoning
that since Meta is a fallback mechanism, correctness is more important than
performance.



>
> Marek
>
>
> On Wed, Nov 20, 2013 at 5:47 AM, Paul Berry 
> wrote:
> > From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
> >
> > When the Clear or ClearBuffer* commands are used to clear a
> > layered framebuffer attachment, all layers of the attachment are
> > cleared.
> >
> > This patch fixes meta clears to properly clear all layers of a layered
> > framebuffer attachment.  We accomplish this by adding a geometry
> > shader to the meta clear program which sets gl_Layer to a uniform
> > value.  When clearing a layered framebuffer, we execute in a loop,
> > setting the uniform to point to each layer in turn.
> >
> > Cc: "10.0" 
> > ---
> >  src/mesa/drivers/common/meta.c | 51
> +++---
> >  1 file changed, 48 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/mesa/drivers/common/meta.c
> b/src/mesa/drivers/common/meta.c
> > index 99b02ba..a6d5098 100644
> > --- a/src/mesa/drivers/common/meta.c
> > +++ b/src/mesa/drivers/common/meta.c
> > @@ -241,9 +241,11 @@ struct clear_state
> > GLuint VBO;
> > GLuint ShaderProg;
> > GLint ColorLocation;
> > +   GLint LayerLocation;
> >
> > GLuint IntegerShaderProg;
> > GLint IntegerColorLocation;
> > +   GLint IntegerLayerLocation;
> >  };
> >
> >
> > @@ -2145,6 +2147,19 @@ meta_glsl_clear_init(struct gl_context *ctx,
> struct clear_state *clear)
> >"{\n"
> >"   gl_Position = position;\n"
> >"}\n";
> > +   const char *gs_source =
> > +  "#version 150\n"
> > +  "layout(triangles) in;\n"
> > +  "layout(triangle_strip, max_vertices = 4) out;\n"
> > +  "uniform int layer;\n"
> > +  "void main()\n"
> > +  "{\n"
> > +  "  for (int i = 0; i < 3; i++) {\n"
> > +  "gl_Layer = layer;\n"
> > +  "gl_Position = gl_in[i].gl_Position;\n"
> > +  "EmitVertex();\n"
> > +  "  }\n"
> > +  "}\n";
> > const char *fs_source =
> >"#ifdef GL_ES\n"
> >"precision highp float;\n"
> > @@ -2154,7 +2169,7 @@ meta_glsl_clear_init(struct gl_context *ctx,
> struct clear_state *clear)
> >"{\n"
> >"   gl_FragColor = color;\n"
> >"}\n";
> > -   GLuint vs, fs;
> > +   GLuint vs, gs = 0, fs;
> > bool has_integer_textures;
> >
> > if (clear->ArrayObj != 0)
> > @@ -2176,6 +2191,12 @@ meta_glsl_clear_init(struct gl_context *ctx,
> struct clear_state *clear)
> > _mesa_ShaderSource(vs, 1, &vs_source

Re: [Mesa-dev] [PATCH 0/9] DRI Image 7 support for gallium

[Thomas Hellstrom]

On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote:

Now includes support for Image 6 as a bonus feature, and 7 is only exposed
on the gallium drivers which support dma-buf import/export.

Still useful for Wayland-Prime and Mir, now also useful for DRI3000

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


For the series (but some driver guys should check the driver prime 
implementations, particularly gem handle closing),

and perhaps if there's a better fix for patch 3

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

[Mesa-dev] [Bug 71591] Second Life shaders fail to compile

[bugzilla-daemon]

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

--- Comment #6 from Eero Tamminen  ---
Giving an error when the extension changes behavior of existing functionality
can be useful for developers, as such things may cause grief for them.  For
anything else, it's the error itself that causes grief.

Options for fixing this issue are:
- changing all errors about this to warnings
- making the error extension specific: outputting it only for behavior changing
extensions
- adding a config option for whether this gives an error or not.  Default
config could then disable this error for binaries that are known to use
extension declarations in wrong place.

How common this issue is, what other programs have this issue besides Second
life client, photoshop, and Unigine Heaven benchmark?  And what extensions
those declare in wrong place?

-- 
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 2/5] meta: fix meta clear of layered framebuffers

[Marek Olšák]

Considering you're the only user of meta_clear who cares about it,
it's all up to you. If your hardware can do AMD_vertex_shader_layer,
you won't ever have to implement any other code path.

It's silly to have multiple GLSL shaders for different versions of the
API. I think this should be API-independent and the GLSL compiler
should allow you to compile any shader for internal purposes. If we
adopted the GLSL IR as the main IR in Gallium, we would make it
API-agnostic and allow compilation of all shaders the GLSL compiler
knows how to compile.

I don't think you need a separate shader for outputting a float vs
integer color. What we do in Gallium is that we set the clear color as
a vertex input which is R32G32B32A32_FLOAT, which is passed to the
fragment shader as a flat varying and written to gl_FragColor. If it's
an integer clear, it doesn't matter. The bits of the clear color are
not changed anywhere, so integer clears work too.

Marek

On Thu, Nov 21, 2013 at 4:52 PM, Paul Berry  wrote:
> On 21 November 2013 05:21, Marek Olšák  wrote:
>>
>> I currently work on a simpler solution for Gallium. I'm using
>> AMD_vertex_shader_layer and this vertex shader (I wrote it in TGSI
>> though):
>>
>> void main()
>> {
>> gl_Position = gl_Vertex;
>> gl_TexCoord[0] = MultiTexCoord0; // clear color
>> gl_Layer = gl_InstanceID;
>> }
>>
>> Then I render the quad with DrawArraysInstanced and set the instance
>> count = NumLayers. That way each instance (each quad) is sent to a
>> different layer and everything is cleared in one draw call.
>>
>> Drivers not supporting AMD_vertex_shader_layer will have to use a GS
>> though.
>
>
> Your approach potentially has better performance, but I'm concerned about
> risk, because I'm hoping to get this patch cherry-picked into 10.0 (which is
> due to be released in a week).  Currently GLSL clear uses 4 different
> shaders:
>
> 1. A vertex shader that just sets gl_Position (compilable for either desktop
> GLSL 1.10 or GLSL ES 1.00)
> 2. A vertex shader that just sets gl_Position (compilable for either desktop
> GLSL 1.30 or GLSL ES 3.00)
> 3. A fragment shader that outputs floating point color (compilable for
> either desktop GLSL or GLSL ES)
> 4. A fragment shader that outputs integer color (compilable for either
> desktop GLSL 1.30 or GLSL ES 3.00)
>
> My proposal adds a fifth:
>
> 5. A geometry shader that sets gl_Position and gl_Layer
>
> If we want to use gl_InstanceID and AMD_vertex_shader_layer, we would have
> to add two more:
>
> 6. A vertex shader that sets gl_Position and gl_Layer (for drivers that
> support AMD_vertex_shader_layer)
> 7. A vertex shader that sets gl_Position and passes through gl_InstanceID to
> the GS (for drivers that support GS but not AMD_vertex_shader_layer)
>
> Testing on the Meta clear path is already pretty thin (at least for i965)
> because most i965 clears can be done by faster mechanisms (fast color clear,
> fast depth clear, or the "blorp" color clear).  I'm worried about
> introducing 3 new shaders to a poorly-tested Meta path this late in the
> release process.
>
> Anyone want to weigh in on this subject from a risk perspective?
>
> I'm also wondering how important performance really is in this patch.  I
> suspect it's not a big issue for i965, since i965 usually does clears using
> faster mechanisms.  It's not an issue for i915, since i915 doesn't support
> geometry shaders.  Are there other drivers that use Meta other than those
> two?  If not, I'm tempted to leave this patch as is, based on the reasoning
> that since Meta is a fallback mechanism, correctness is more important than
> performance.
>
>
>>
>>
>> Marek
>>
>>
>> On Wed, Nov 20, 2013 at 5:47 AM, Paul Berry 
>> wrote:
>> > From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
>> >
>> > When the Clear or ClearBuffer* commands are used to clear a
>> > layered framebuffer attachment, all layers of the attachment are
>> > cleared.
>> >
>> > This patch fixes meta clears to properly clear all layers of a layered
>> > framebuffer attachment.  We accomplish this by adding a geometry
>> > shader to the meta clear program which sets gl_Layer to a uniform
>> > value.  When clearing a layered framebuffer, we execute in a loop,
>> > setting the uniform to point to each layer in turn.
>> >
>> > Cc: "10.0" 
>> > ---
>> >  src/mesa/drivers/common/meta.c | 51
>> > +++---
>> >  1 file changed, 48 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/mesa/drivers/common/meta.c
>> > b/src/mesa/drivers/common/meta.c
>> > index 99b02ba..a6d5098 100644
>> > --- a/src/mesa/drivers/common/meta.c
>> > +++ b/src/mesa/drivers/common/meta.c
>> > @@ -241,9 +241,11 @@ struct clear_state
>> > GLuint VBO;
>> > GLuint ShaderProg;
>> > GLint ColorLocation;
>> > +   GLint LayerLocation;
>> >
>> > GLuint IntegerShaderProg;
>> > GLint IntegerColorLocation;
>> > +   GLint IntegerLayerLocation;
>> >  };
>> >
>> >
>> > @@ -2145,6 +

Re: [Mesa-dev] [PATCH] llvmpipe: support 8bit subpixel precision

[Jose Fonseca]

- Original Message -
> Great!
> 
> Couple of comments inline.
> 
> On 11/21/2013 12:02 AM, Zack Rusin wrote:
> > 8 bit precision is required by d3d10 but unfortunately
> > requires 64 bit rasterizer. This commit implements
> > 64 bit rasterization with full support for 8bit subpixel
> > precision. It's a combination of all individual commits
> > from the llvmpipe-rast-64 branch.
> >
> > Signed-off-by: Zack Rusin 
> > ---
> >   src/gallium/drivers/llvmpipe/lp_rast.c |  11 ++
> >   src/gallium/drivers/llvmpipe/lp_rast.h |  47 +--
> >   src/gallium/drivers/llvmpipe/lp_rast_debug.c   |   6 +-
> >   src/gallium/drivers/llvmpipe/lp_rast_priv.h|  27 
> >   src/gallium/drivers/llvmpipe/lp_rast_tri.c | 173
> >   +
> >   src/gallium/drivers/llvmpipe/lp_rast_tri_tmp.h |  56 
> >   src/gallium/drivers/llvmpipe/lp_setup_line.c   |   2 +-
> >   src/gallium/drivers/llvmpipe/lp_setup_tri.c| 155
> >   ++
> >   src/gallium/tests/graw/SConscript  |   1 +
> >   src/gallium/tests/graw/tri-large.c | 173
> >   +
> >   10 files changed, 500 insertions(+), 151 deletions(-)
> >   create mode 100644 src/gallium/tests/graw/tri-large.c
> >
> > diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
> > b/src/gallium/drivers/llvmpipe/lp_rast.c
> > index af661e9..0cd62c2 100644
> > --- a/src/gallium/drivers/llvmpipe/lp_rast.c
> > +++ b/src/gallium/drivers/llvmpipe/lp_rast.c
> > @@ -589,6 +589,17 @@ static lp_rast_cmd_func dispatch[LP_RAST_OP_MAX] =
> >  lp_rast_begin_query,
> >  lp_rast_end_query,
> >  lp_rast_set_state,
> > +   lp_rast_triangle_32_1,
> > +   lp_rast_triangle_32_2,
> > +   lp_rast_triangle_32_3,
> > +   lp_rast_triangle_32_4,
> > +   lp_rast_triangle_32_5,
> > +   lp_rast_triangle_32_6,
> > +   lp_rast_triangle_32_7,
> > +   lp_rast_triangle_32_8,
> > +   lp_rast_triangle_32_3_4,
> > +   lp_rast_triangle_32_3_16,
> > +   lp_rast_triangle_32_4_16
> >   };
> >
> >
> > diff --git a/src/gallium/drivers/llvmpipe/lp_rast.h
> > b/src/gallium/drivers/llvmpipe/lp_rast.h
> > index 43c598d..b81d94f 100644
> > --- a/src/gallium/drivers/llvmpipe/lp_rast.h
> > +++ b/src/gallium/drivers/llvmpipe/lp_rast.h
> > @@ -46,10 +46,11 @@ struct lp_scene;
> >   struct lp_fence;
> >   struct cmd_bin;
> >
> > -#define FIXED_TYPE_WIDTH 32
> > +#define FIXED_TYPE_WIDTH 64
> >   /** For sub-pixel positioning */
> > -#define FIXED_ORDER 4
> > +#define FIXED_ORDER 8
> >   #define FIXED_ONE (1< > +#define FIXED_SHIFT (FIXED_TYPE_WIDTH - 1)
> >   /** Maximum length of an edge in a primitive in pixels.
> >*  If the framebuffer is large we have to think about fixed-point
> >*  integer overflow. Coordinates need ((FIXED_TYPE_WIDTH/2) - 1) bits
> > @@ -59,11 +60,14 @@ struct cmd_bin;
> >*/
> >   #define MAX_FIXED_LENGTH (1 << (((FIXED_TYPE_WIDTH/2) - 1) -
> >   FIXED_ORDER))
> >
> > +#define MAX_FIXED_LENGTH32 (1 << (((32/2) - 1) - FIXED_ORDER))
> > +
> >   /* Rasterizer output size going to jit fs, width/height */
> >   #define LP_RASTER_BLOCK_SIZE 4
> >
> >   #define LP_MAX_ACTIVE_BINNED_QUERIES 16
> >
> > +#define IMUL64(a, b) (((int64_t)(a)) * ((int64_t)(b)))
> >
> >   struct lp_rasterizer_task;
> >
> > @@ -102,18 +106,15 @@ struct lp_rast_shader_inputs {
> >  /* followed by a0, dadx, dady and planes[] */
> >   };
> >
> > -/* Note: the order of these values is important as they are loaded by
> > - * sse code in rasterization:
> > - */
> >   struct lp_rast_plane {
> >  /* edge function values at minx,miny ?? */
> > -   int c;
> > +   int64_t c;
> >
> > -   int dcdx;
> > -   int dcdy;
> > +   int32_t dcdx;
> > +   int32_t dcdy;
> >
> >  /* one-pixel sized trivial reject offsets for each plane */
> > -   int eo;
> > +   int64_t eo;
> >   };
> I'm still not entirely happy that even for rasterization we need 64bits.
> And even more unhappy that we have to deal with pseudo-64bit values even
> when we can use the 32bit versions so we get a metric crapload of scalar
> loads. But then again I'm not happy about other things in
> rasterization... It may be avoidable by doing some per-tile fixup (the
> 64bit rasterization, the need for having 64bit structs for 32bit
> rasterization could be avoided by using separate plane arg for 32bit).
> But we can always fix that later. I bet that if you're on a 32bit arch
> it will be very slow.

I'm not happy about rain neither, but there's not much that can be done about 
it.  64bit arithmetic at setup/binning stage is impossible except for tiny 
(128x128) rendertargets that nobody cares about.  We can manage with 32bit 
arithmetic at tile rasterization, if triangles are small (again 128x128).

> >
> >   /**
> > @@ -277,8 +278,19 @@ lp_rast_arg_null( void )
> >   #define LP_RAST_OP_BEGIN_QUERY   0xf
> >   #define LP_RAST_OP_END_QUERY 0x10
> >   #define LP_RAST_OP_SET_STATE 0x11
> > -
> > -#define LP_RAST_OP_MAX   0x12
> >

Re: [Mesa-dev] [v3 6/8] mesa: Fill out ARB_texture_view entry points

[Brian Paul]

I'd rename this summary as something like "mesa: implement the 
_mesa_TextureView() function"



On 11/19/2013 04:16 PM, Courtney Goeltzenleuchter wrote:

Add Mesa TextureView logic.
Incorporate feedback on ARB_texture_view

Signed-off-by: Courtney Goeltzenleuchter 
---
  src/mesa/main/textureview.c | 562 +++-
  1 file changed, 561 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
index 4a6bd62..1858465 100644
--- a/src/mesa/main/textureview.c
+++ b/src/mesa/main/textureview.c
@@ -40,8 +40,346 @@
  #include "texobj.h"
  #include "texstorage.h"
  #include "textureview.h"
+#include "stdbool.h"
  #include "mtypes.h"

+/* Table 3.X.2 (Compatible internal formats for TextureView)
+---
+| Class | Internal formats|
+---
+| VIEW_CLASS_128_BITS   | RGBA32F, RGBA32UI, RGBA32I  |
+---
+| VIEW_CLASS_96_BITS| RGB32F, RGB32UI, RGB32I |
+---
+| VIEW_CLASS_64_BITS| RGBA16F, RG32F, RGBA16UI, RG32UI, RGBA16I,  |
+|   | RG32I, RGBA16, RGBA16_SNORM |
+---
+| VIEW_CLASS_48_BITS| RGB16, RGB16_SNORM, RGB16F, RGB16UI, RGB16I |
+---
+| VIEW_CLASS_32_BITS| RG16F, R11F_G11F_B10F, R32F,|
+|   | RGB10_A2UI, RGBA8UI, RG16UI, R32UI, |
+|   | RGBA8I, RG16I, R32I, RGB10_A2, RGBA8, RG16, |
+|   | RGBA8_SNORM, RG16_SNORM, SRGB8_ALPHA8, RGB9_E5  |
+---
+| VIEW_CLASS_24_BITS| RGB8, RGB8_SNORM, SRGB8, RGB8UI, RGB8I  |
+---
+| VIEW_CLASS_16_BITS| R16F, RG8UI, R16UI, RG8I, R16I, RG8, R16,   |
+|   | RG8_SNORM, R16_SNORM|
+---
+| VIEW_CLASS_8_BITS | R8UI, R8I, R8, R8_SNORM |
+---
+| VIEW_CLASS_RGTC1_RED  | COMPRESSED_RED_RGTC1,   |
+|   | COMPRESSED_SIGNED_RED_RGTC1 |
+---
+| VIEW_CLASS_RGTC2_RG   | COMPRESSED_RG_RGTC2,|
+|   | COMPRESSED_SIGNED_RG_RGTC2  |
+---
+| VIEW_CLASS_BPTC_UNORM | COMPRESSED_RGBA_BPTC_UNORM, |
+|   | COMPRESSED_SRGB_ALPHA_BPTC_UNORM|
+---
+| VIEW_CLASS_BPTC_FLOAT | COMPRESSED_RGB_BPTC_SIGNED_FLOAT,   |
+|   | COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT  |
+---
+ */
+struct internal_format_class_info {
+   GLenum view_class;
+   GLenum internal_format;
+};
+#define INFO(c,f) {GL_##c, GL_##f}
+static const struct internal_format_class_info _compatible_internal_formats[] 
= {
+   INFO(VIEW_CLASS_128_BITS, RGBA32F),


If the point of the macro is just to save typing GL_ prefixes, I don't 
think it's worth it.


The leading underscore on _compatible_internal_formats isn't really 
necessary.




+   INFO(VIEW_CLASS_128_BITS, RGBA32UI),
+   INFO(VIEW_CLASS_128_BITS, RGBA32I),
+   INFO(VIEW_CLASS_96_BITS, RGB32F),
+   INFO(VIEW_CLASS_96_BITS, RGB32UI),
+   INFO(VIEW_CLASS_96_BITS, RGB32I),
+   INFO(VIEW_CLASS_64_BITS, RGBA16F),
+   INFO(VIEW_CLASS_64_BITS, RG32F),
+   INFO(VIEW_CLASS_64_BITS, RGBA16UI),
+   INFO(VIEW_CLASS_64_BITS, RG32UI),
+   INFO(VIEW_CLASS_64_BITS, RGBA16I),
+   INFO(VIEW_CLASS_64_BITS, RG32I),
+   INFO(VIEW_CLASS_64_BITS, RGBA16),
+   INFO(VIEW_CLASS_64_BITS, RGBA16_SNORM),
+   INFO(VIEW_CLASS_48_BITS, RGB16),
+   INFO(VIEW_CLASS_48_BITS, RGB16_SNORM),
+   INFO(VIEW_CLASS_48_BITS, RGB16F),
+   INFO(VIEW_CLASS_48_BITS, RGB16UI),
+   INFO(VIEW_CLASS_48_BITS, RGB16I),
+   INFO(VIEW_CLASS_32_BITS, RG16F),
+   INFO(VIEW_CLASS_32_BITS, R11F_G11F_B10F),
+   INFO(VIEW_CLASS_32_BITS, R32F),
+   INFO(VIEW_CLASS_32_BITS, RGB10_A2UI),
+   IN

Re: [Mesa-dev] [PATCH v2 2/5] meta: fix meta clear of layered framebuffers

[Eric Anholt]

Eric Anholt  writes:

> Paul Berry  writes:
>
>> From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
>>
>> When the Clear or ClearBuffer* commands are used to clear a
>> layered framebuffer attachment, all layers of the attachment are
>> cleared.
>>
>> This patch fixes meta clears to properly clear all layers of a layered
>> framebuffer attachment.  We accomplish this by adding a geometry
>> shader to the meta clear program which sets gl_Layer to a uniform
>> value.  When clearing a layered framebuffer, we execute in a loop,
>> setting the uniform to point to each layer in turn.
>
> I don't think we should be running a gs in the !NumLayers case.  The
> other patches are:
>
> Reviewed-by: Eric Anholt 

Paul reminded that thanks to the simd16 repdata clear, we're basically
never calling glsl clear on gen6+, and we only enable GS on gen7+.

As such, I'm not really concerned about the performance any more, and by
the time anyone else can care about it we should have ARB_sso, at which
point optionally slotting in a GS to do this work on a layered FB is
easy.  I think.

Reviewed-by: Eric Anholt 


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

Re: [Mesa-dev] [PATCH] docs: Add a section with recommended reading for llvmpipe development.

[Roland Scheidegger]

On 11/21/2013 06:03 PM, jfons...@vmware.com wrote:

From: José Fonseca 

Several links contributed by Keith Whitwell and Roland Scheidegger.
---
  docs/llvmpipe.html | 58 --
  1 file changed, 56 insertions(+), 2 deletions(-)

diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html
index 80f8a01..d695907 100644
--- a/docs/llvmpipe.html
+++ b/docs/llvmpipe.html
@@ -203,11 +203,65 @@ for posterior analysis, e.g.:
We use LLVM-C bindings for now. They are not documented, but follow the C++
interfaces very closely, and appear to be complete enough for code
generation. See
-  http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html
-  for a stand-alone example.  See the llvm-c/Core.h file for reference.
+  http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html";>
+  this stand-alone example.  See the llvm-c/Core.h file for reference.
  
  

+Recommended Reading
+
+
+  
+Rasterization
+
+  http://www.cs.unc.edu/~olano/papers/2dh-tri/";>Triangle Scan Conversion 
using 2D Homogeneous Coordinates
+  http://www.drdobbs.com/parallel/rasterization-on-larrabee/217200602";>Rasterization on 
Larrabee (http://devmaster.net/posts/2887/rasterization-on-larrabee";>DevMaster 
copy)
+  http://devmaster.net/posts/6133/rasterization-using-half-space-functions";>Rasterization using 
half-space functions
+  http://devmaster.net/posts/6145/advanced-rasterization";>Advanced 
Rasterization
+  http://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlusion-culling-index/";>Optimizing 
Software Occlusion Culling
+
+  
+  
+Texture sampling
+
+  http://chrishecker.com/Miscellaneous_Technical_Articles#Perspective_Texture_Mapping";>Perspective
 Texture Mapping
+  http://www.flipcode.com/archives/Texturing_As_In_Unreal.shtml";>Texturing As In 
Unreal
+  http://www.gamasutra.com/view/feature/3301/runtime_mipmap_filtering.php";>Run-Time MIP-Map 
Filtering
+  http://alt.3dcenter.org/artikel/2003/10-26_a_english.php";>Will 
"brilinear" filtering persist?
+  http://ixbtlabs.com/articles2/gffx/nv40-rx800-3.html";>Trilinear 
filtering
+  http://devmaster.net/posts/12785/texture-swizzling";>Texture 
Swizzling
+
+  
+  
+SIMD
+
+  http://www.cdl.uni-saarland.de/projects/wfv/#header4";>Whole-Function 
Vectorization
+
+  
+  
+Optimization
+
+  http://www.drdobbs.com/optimizing-pixomatic-for-modern-x86-proc/184405807";>Optimizing 
Pixomatic For Modern x86 Processors
+  http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html";>Intel
 64 and IA-32 Architectures Optimization Reference Manual
+  http://www.agner.org/optimize/";>Software optimization 
resources
+  http://software.intel.com/en-us/articles/intel-intrinsics-guide";>Intel 
Intrinsics Guide
+
+  
+  
+LLVM
+
+  http://llvm.org/docs/LangRef.html";>LLVM Language Reference 
Manual
+  http://npcontemplation.blogspot.co.uk/2008/06/secret-of-llvm-c-bindings.html";>The secret of 
LLVM C bindings
+
+  
+  
+Misc
+
+  http://msdn.microsoft.com/en-us/library/gg615082.aspx#architecture";>WARP Architecture and 
Performance
+
+  
+
+
  
  
  



Loods good to me. Thought that would be just one link from me :-).

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

[Mesa-dev] [PATCH 1/5] i965: Keep pointers to IF/ELSE/ENDIF instructions in the cfg.

[Matt Turner]

Useful for finding the associated control flow instructions, given a
block ending in one.
---
v2: Handle nested control flow properly. When we reach the ENDIF, we have
still have the pointers to the IF and ELSE (if it exists).

The confusing bit of this code is that while bblock_t *cur_if is the
block that ends in the IF, but cur_else and cur_endif are the blocks
immediately after the ELSE and ENDIF instructions.

 src/mesa/drivers/dri/i965/brw_cfg.cpp | 33 +
 src/mesa/drivers/dri/i965/brw_cfg.h   | 10 ++
 2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp 
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index e9d2bb8..e1a3662 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
+++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
@@ -28,7 +28,7 @@
 #include "brw_fs.h"
 #include "brw_cfg.h"
 
-/** @file brw_cfg_t.cpp
+/** @file brw_cfg.cpp
  *
  * Walks the shader instructions generated and creates a set of basic
  * blocks with successor/predecessor edges connecting them.
@@ -52,6 +52,10 @@ bblock_t::bblock_t() :
 
parents.make_empty();
children.make_empty();
+
+   if_inst = NULL;
+   else_inst = NULL;
+   endif_inst = NULL;
 }
 
 void
@@ -142,20 +146,41 @@ cfg_t::create(void *parent_mem_ctx, exec_list 
*instructions)
 set_next_block(next);
 break;
 
-  case BRW_OPCODE_ENDIF:
+  case BRW_OPCODE_ENDIF: {
 cur_endif->start = (backend_instruction *)inst->next;
 cur->add_successor(mem_ctx, cur_endif);
+
 set_next_block(cur_endif);
 
-if (!cur_else)
+ backend_instruction *else_inst = cur_else ?
+(backend_instruction *) cur_else->start->prev : NULL;
+
+ assert(cur_if->end->opcode == BRW_OPCODE_IF);
+ assert(!else_inst || else_inst->opcode == BRW_OPCODE_ELSE);
+ assert(inst->opcode == BRW_OPCODE_ENDIF);
+
+ cur_if->if_inst = cur_if->end;
+ cur_if->else_inst = else_inst;
+ cur_if->endif_inst = inst;
+
+if (!cur_else) {
cur_if->add_successor(mem_ctx, cur_endif);
+ } else {
+cur_else->if_inst = cur_if->end;
+cur_else->else_inst = else_inst;
+cur_else->endif_inst = inst;
+ }
+
+ cur->if_inst = cur_if->end;
+ cur->else_inst = else_inst;
+ cur->endif_inst = inst;
 
 /* Pop the stack so we're in the previous if/else/endif */
 cur_if = pop_stack(&if_stack);
 cur_else = pop_stack(&else_stack);
 cur_endif = pop_stack(&endif_stack);
 break;
-
+  }
   case BRW_OPCODE_DO:
 /* Push our information onto a stack so we can recover from
  * nested loops.
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h 
b/src/mesa/drivers/dri/i965/brw_cfg.h
index ec5a3a0..2f5e3f9 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -56,6 +56,16 @@ public:
exec_list parents;
exec_list children;
int block_num;
+
+   /* If the current basic block ends in an IF, ELSE, or ENDIF instruction,
+* these pointers will hold the locations of the other associated control
+* flow instructions.
+*
+* Otherwise they are NULL.
+*/
+   backend_instruction *if_inst;
+   backend_instruction *else_inst;
+   backend_instruction *endif_inst;
 };
 
 class cfg_t {
-- 
1.8.3.2

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

[Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

[Keith Packard]

The __DRIimage createImageFromFds function takes a fourcc code, but there was
no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
__DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to
__IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers.

I'll refrain from comments on whether I think having two separate sets of
format defines in dri_interface.h is a good idea or not...

Signed-off-by: Keith Packard 
---

This gets iceweasel running with the GL compositor enabled.

 include/GL/internal/dri_interface.h  | 1 +
 src/glx/dri3_glx.c   | 1 +
 src/mesa/drivers/dri/i915/intel_screen.c | 3 +++
 src/mesa/drivers/dri/i965/intel_screen.c | 3 +++
 4 files changed, 8 insertions(+)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index b012570..a4387c4 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1034,6 +1034,7 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_FOURCC_XRGB0x34325258
 #define __DRI_IMAGE_FOURCC_ABGR0x34324241
 #define __DRI_IMAGE_FOURCC_XBGR0x34324258
+#define __DRI_IMAGE_FOURCC_SARGB0x83324258
 #define __DRI_IMAGE_FOURCC_YUV410  0x39565559
 #define __DRI_IMAGE_FOURCC_YUV411  0x31315559
 #define __DRI_IMAGE_FOURCC_YUV420  0x32315559
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index b047cc8..5861317 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -890,6 +890,7 @@ image_format_to_fourcc(int format)
 
/* Convert from __DRI_IMAGE_FORMAT to __DRI_IMAGE_FOURCC (sigh) */
switch (format) {
+   case __DRI_IMAGE_FORMAT_SARGB8: return __DRI_IMAGE_FOURCC_SARGB;
case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565;
case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
b/src/mesa/drivers/dri/i915/intel_screen.c
index 7f1fc6b..2dd2bc7 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -184,6 +184,9 @@ static struct intel_image_format intel_image_formats[] = {
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
 
+   { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
+
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
 
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index e44d0f6..cf8c3e2 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -220,6 +220,9 @@ static struct intel_image_format intel_image_formats[] = {
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
 
+   { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
+
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
 
-- 
1.8.4.2

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

[Mesa-dev] [PATCH] gallium: Use base.stamp for all drawable invalidation checks.

[Keith Packard]

Upper levels of the stack use base.stamp to tell when a drawable needs to be
revalidated, but the dri state tracker was using dPriv->lastStamp. Those two,
along with dri2.stamp, all get simultaneously incremented when a dri2
invalidate event was delivered, and so end up containing precisely the same
value.

This patch doesn't change the fact that there are three variables, rather it
switches all of the tests to use only base.stamp, which is functionally
equivalent to the previous code.

Then, it passes base.stamp to the image loader getBuffers function so that the
one which is checked will get updated by the XCB special event queue used by 
DRI3.

Signed-off-by: Keith Packard 
---

This patch makes sure that drawables get invalidated when the window
changes size or when SwapBuffers is called; dri3 has only a single
location to smite when things change, so we need to make sure the
upper levels all share that location.

This should permit the elimination of the dri2.stamp and lastStamp
variables, which would be a nice further cleanup.

 src/gallium/state_trackers/dri/common/dri_drawable.c | 4 ++--
 src/gallium/state_trackers/dri/drm/dri2.c| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c 
b/src/gallium/state_trackers/dri/common/dri_drawable.c
index f255108..734bca2 100644
--- a/src/gallium/state_trackers/dri/common/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/common/dri_drawable.c
@@ -73,7 +73,7 @@ dri_st_framebuffer_validate(struct st_context_iface *stctx,
 * checked.
 */
do {
-  lastStamp = drawable->dPriv->lastStamp;
+  lastStamp = drawable->base.stamp;
   new_stamp = (drawable->texture_stamp != lastStamp);
 
   if (new_stamp || new_mask || screen->broken_invalidate) {
@@ -91,7 +91,7 @@ dri_st_framebuffer_validate(struct st_context_iface *stctx,
  drawable->texture_stamp = lastStamp;
  drawable->texture_mask = statt_mask;
   }
-   } while (lastStamp != drawable->dPriv->lastStamp);
+   } while (lastStamp != drawable->base.stamp);
 
if (!out)
   return TRUE;
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index 6a56cd4..c7e4151 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -545,7 +545,7 @@ dri_image_allocate_textures(struct dri_context *ctx,
 
(*sPriv->image.loader->getBuffers) (dPriv,
image_format,
-   &dPriv->dri2.stamp,
+   (uint32_t *) &drawable->base.stamp,
dPriv->loaderPrivate,
buffer_mask,
&images);
-- 
1.8.4.2

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

[Mesa-dev] [PATCH] dri3: Prepare for API change in libxshmfence

[Keith Packard]

libxshmfence foolishly advertises the type of a fence as 'int32_t *', which
works when the fence is a linux futex. However, that library is going to
change the exported datatype to 'struct xshmfence *', which will provide some
nice typechecking. Anticipate the change by just using 'void *' in mesa, which
works with both the int32_t* and struct xshmfence* versions.

Signed-off-by: Keith Packard 
---

libxshmfence will also be providing a HAVE_STRUCT_XSHMFENCE define, so
we could actually check for that and use struct xshmfence when
available. Just using 'void *' avoids a bunch of clutter, but if
people think they'd rather have extra type checking, I can do the
other version instead.

 src/glx/dri3_glx.c  | 4 ++--
 src/glx/dri3_priv.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 5861317..239d58b 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -676,7 +676,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
xcb_connection_t *c = XGetXCBConnection(dpy);
xcb_pixmap_t pixmap;
xcb_sync_fence_t sync_fence;
-   int32_t *shm_fence;
+   void *shm_fence;
int buffer_fd, fence_fd;
int stride;
 
@@ -922,7 +922,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
struct dri3_screen   *psc;
xcb_connection_t *c;
xcb_sync_fence_t sync_fence;
-   int32_t  *shm_fence;
+   void *shm_fence;
int  fence_fd;
__DRIimage   *image_planar;
int  stride, offset;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index c892800..0d21e67 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -87,7 +87,7 @@ struct dri3_buffer {
 */
 
uint32_t sync_fence; /* XID of X SyncFence object */
-   int32_t  *shm_fence; /* pointer to xshmfence object */
+   void *shm_fence; /* pointer to xshmfence object */
GLbooleanbusy;   /* Set on swap, cleared on IdleNotify */
void *driverPrivate;
 
-- 
1.8.4.2

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

[Mesa-dev] [Bug 71903] New: [swrast] piglit hiz-depth-read-window-stencil0 regression

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 71903
  Keywords: regression
CC: airl...@freedesktop.org
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [swrast] piglit hiz-depth-read-window-stencil0
regression
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: bb354c6c279031dafc08029a62cd3e76a6c1ca71 (master)

$ ./bin/hiz-depth-read-window-stencil0 -auto
Probe color at (16,16)
  Expected: 0.00 1.00 0.00
  Observed: 0.501961 0.501961 0.501961
Probe color at (66,16)
  Expected: 0.00 1.00 0.00
  Observed: 0.00 0.00 1.00
Probe color at (116,16)
  Expected: 0.50 0.50 0.50
  Observed: 0.00 0.00 1.00
Probe color at (16,116)
  Expected: 0.50 0.50 0.50
  Observed: 0.00 1.00 0.00
Probe color at (66,116)
  Expected: 0.00 0.00 1.00
  Observed: 0.00 1.00 0.00
Probe color at (116,116)
  Expected: 0.00 0.00 1.00
  Observed: 0.501961 0.501961 0.501961
PIGLIT: {'result': 'fail' }

a43b49dfb13dc7e6d2d6d7ceee892077038d7102 is the first bad commit
commit a43b49dfb13dc7e6d2d6d7ceee892077038d7102
Author: Dave Airlie 
Date:   Wed Nov 13 12:53:52 2013 +1000

mesa/swrast: fix inverted front buffer rendering with old-school swrast

I've no idea when this broke, but we have some people who wanted it fixed,
so here's my attempt.

reproducer, run readpix with swrast hit f, or run trival tri -sb things are
upside down, after this patch they aren't.

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

Cc: "
Signed-off-by: Dave Airlie 

:04 04 70e437e84fa67556a6469a8bf75277a6ec07e8a6
a307a4bc1dcb80aae42897ce27b7771dd8760f4f 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

[Mesa-dev] [Bug 71904] New: [swrast] piglit glsl-reload-source regression

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 71904
  Keywords: regression
CC: airl...@freedesktop.org
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [swrast] piglit glsl-reload-source regression
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: bb354c6c279031dafc08029a62cd3e76a6c1ca71 (master)

$ ./bin/glsl-reload-source -auto
Probe color at (37,37)
  Expected: 0.00 0.40 0.00
  Observed: 0.00 0.00 0.00
Probe color at (112,37)
  Expected: 0.40 0.40 0.40
  Observed: 0.00 0.00 0.00
Probe color at (37,112)
  Expected: 0.40 0.40 0.00
  Observed: 0.00 0.40 0.00
Probe color at (112,112)
  Expected: 0.80 0.40 0.40
  Observed: 0.40 0.40 0.40
PIGLIT: {'result': 'fail' }

a43b49dfb13dc7e6d2d6d7ceee892077038d7102 is the first bad commit
commit a43b49dfb13dc7e6d2d6d7ceee892077038d7102
Author: Dave Airlie 
Date:   Wed Nov 13 12:53:52 2013 +1000

mesa/swrast: fix inverted front buffer rendering with old-school swrast

I've no idea when this broke, but we have some people who wanted it fixed,
so here's my attempt.

reproducer, run readpix with swrast hit f, or run trival tri -sb things are
upside down, after this patch they aren't.

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

Cc: "
Signed-off-by: Dave Airlie 

:04 04 70e437e84fa67556a6469a8bf75277a6ec07e8a6
a307a4bc1dcb80aae42897ce27b7771dd8760f4f 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] llvmpipe: support 8bit subpixel precision

[Zack Rusin]

> For me too, other than the fixed_position members, looks good.  Thanks for
> your perseverance on this Zack!

Thanks! ok, attached is a version that makes position and dx/dy 32bit again, it 
seems to work great. I have a question for you guys if you run the piglits:
./bin/triangle-rasterization-overdraw -max_size -seed 0xA8402F24 -count 1 -auto
on master does it fail for you? It fails for me on master, with and without the 
patch. I'm not sure what to make of it, I might have been looking at 
rasterization for too long. Looking at the rendering it looks correct.

zFrom 55c9a288c7ebc37b32bc75526e6de71a838ccaef Mon Sep 17 00:00:00 2001
From: Zack Rusin 
Date: Thu, 24 Oct 2013 22:05:22 -0400
Subject: [PATCH] llvmpipe: support 8bit subpixel precision

8 bit precision is required by d3d10 but unfortunately
requires 64 bit rasterizer. This commit implements
64 bit rasterization with full support for 8bit subpixel
precision. It's a combination of all individual commits
from the llvmpipe-rast-64 branch.
---
 src/gallium/drivers/llvmpipe/lp_rast.c |  11 ++
 src/gallium/drivers/llvmpipe/lp_rast.h |  47 +--
 src/gallium/drivers/llvmpipe/lp_rast_debug.c   |   6 +-
 src/gallium/drivers/llvmpipe/lp_rast_priv.h|  27 
 src/gallium/drivers/llvmpipe/lp_rast_tri.c | 173 
 src/gallium/drivers/llvmpipe/lp_rast_tri_tmp.h |  56 
 src/gallium/drivers/llvmpipe/lp_setup_line.c   |   2 +-
 src/gallium/drivers/llvmpipe/lp_setup_tri.c| 147 +
 src/gallium/tests/graw/SConscript  |   1 +
 src/gallium/tests/graw/tri-large.c | 174 +
 10 files changed, 496 insertions(+), 148 deletions(-)
 create mode 100644 src/gallium/tests/graw/tri-large.c

diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c b/src/gallium/drivers/llvmpipe/lp_rast.c
index af661e9..0cd62c2 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -589,6 +589,17 @@ static lp_rast_cmd_func dispatch[LP_RAST_OP_MAX] =
lp_rast_begin_query,
lp_rast_end_query,
lp_rast_set_state,
+   lp_rast_triangle_32_1,
+   lp_rast_triangle_32_2,
+   lp_rast_triangle_32_3,
+   lp_rast_triangle_32_4,
+   lp_rast_triangle_32_5,
+   lp_rast_triangle_32_6,
+   lp_rast_triangle_32_7,
+   lp_rast_triangle_32_8,
+   lp_rast_triangle_32_3_4,
+   lp_rast_triangle_32_3_16,
+   lp_rast_triangle_32_4_16
 };
 
 
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.h b/src/gallium/drivers/llvmpipe/lp_rast.h
index 43c598d..b81d94f 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.h
+++ b/src/gallium/drivers/llvmpipe/lp_rast.h
@@ -46,10 +46,11 @@ struct lp_scene;
 struct lp_fence;
 struct cmd_bin;
 
-#define FIXED_TYPE_WIDTH 32
+#define FIXED_TYPE_WIDTH 64
 /** For sub-pixel positioning */
-#define FIXED_ORDER 4
+#define FIXED_ORDER 8
 #define FIXED_ONE (1<
+#include "util/u_sse.h"
+
+static INLINE __m128i
+lp_plane_to_m128i(const struct lp_rast_plane *plane)
+{
+   return _mm_setr_epi32((int32_t)plane->c, (int32_t)plane->dcdx,
+ (int32_t)plane->dcdy, (int32_t)plane->eo);
+}
+
+#endif
+
 #endif
diff --git a/src/gallium/drivers/llvmpipe/lp_rast_debug.c b/src/gallium/drivers/llvmpipe/lp_rast_debug.c
index 3bc75aa..587c793 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast_debug.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast_debug.c
@@ -195,8 +195,8 @@ debug_triangle(int tilex, int tiley,
while (plane_mask) {
   plane[nr_planes] = tri_plane[u_bit_scan(&plane_mask)];
   plane[nr_planes].c = (plane[nr_planes].c +
-plane[nr_planes].dcdy * tiley -
-plane[nr_planes].dcdx * tilex);
+IMUL64(plane[nr_planes].dcdy, tiley) -
+IMUL64(plane[nr_planes].dcdx, tilex));
   nr_planes++;
}
 
@@ -217,7 +217,7 @@ debug_triangle(int tilex, int tiley,
   }
 
   for (i = 0; i < nr_planes; i++) {
- plane[i].c += plane[i].dcdx * TILE_SIZE;
+ plane[i].c += IMUL64(plane[i].dcdx, TILE_SIZE);
  plane[i].c += plane[i].dcdy;
   }
}
diff --git a/src/gallium/drivers/llvmpipe/lp_rast_priv.h b/src/gallium/drivers/llvmpipe/lp_rast_priv.h
index 41fe097..77ec329 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast_priv.h
+++ b/src/gallium/drivers/llvmpipe/lp_rast_priv.h
@@ -355,6 +355,33 @@ void lp_rast_triangle_3_16( struct lp_rasterizer_task *,
 void lp_rast_triangle_4_16( struct lp_rasterizer_task *, 
 const union lp_rast_cmd_arg );
 
+
+void lp_rast_triangle_32_1( struct lp_rasterizer_task *, 
+ const union lp_rast_cmd_arg );
+void lp_rast_triangle_32_2( struct lp_rasterizer_task *, 
+ const union lp_rast_cmd_arg );
+void lp_rast_triangle_32_3( struct lp_rasterizer_task *, 
+ const union lp_rast_cmd_arg );
+void lp_rast_triangle_32_4( struct lp_rasterizer_task *, 
+

[Mesa-dev] [PATCH] dri3: Free resources when drawable is destroyed.

[Keith Packard]

Always nice to clean up after ourselves.

Signed-off-by: Keith Packard 
---

Ok, so not having this in the dri3 code led to a bit of extra memory
usage in apps and the X server.

 src/glx/dri3_glx.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 239d58b..669f0bb 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -266,13 +266,25 @@ dri3_create_context(struct glx_screen *base,
 }
 
 static void
+dri3_free_render_buffer(struct dri3_drawable *pdraw, struct dri3_buffer 
*buffer);
+
+static void
 dri3_destroy_drawable(__GLXDRIdrawable *base)
 {
struct dri3_screen *psc = (struct dri3_screen *) base->psc;
struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
+   xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
+   int i;
 
(*psc->core->destroyDrawable) (pdraw->driDrawable);
 
+   for (i = 0; i < DRI3_NUM_BUFFERS; i++) {
+  if (pdraw->buffers[i])
+ dri3_free_render_buffer(pdraw, pdraw->buffers[i]);
+   }
+
+   if (pdraw->special_event)
+  xcb_unregister_for_special_event(c, pdraw->special_event);
free(pdraw);
 }
 
@@ -736,6 +748,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
   fence_fd);
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = true;
buffer->sync_fence = sync_fence;
buffer->shm_fence = shm_fence;
buffer->width = width;
@@ -769,7 +782,8 @@ dri3_free_render_buffer(struct dri3_drawable *pdraw, struct 
dri3_buffer *buffer)
struct dri3_screen   *psc = (struct dri3_screen *) pdraw->base.psc;
xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
 
-   xcb_free_pixmap(c, buffer->pixmap);
+   if (buffer->own_pixmap)
+  xcb_free_pixmap(c, buffer->pixmap);
xcb_sync_destroy_fence(c, buffer->sync_fence);
xshmfence_unmap_shm(buffer->shm_fence);
(*psc->image->destroyImage)(buffer->image);
@@ -988,6 +1002,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
   goto no_image;
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = false;
buffer->width = bp_reply->width;
buffer->height = bp_reply->height;
buffer->buffer_type = buffer_type;
-- 
1.8.4.2

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

[Mesa-dev] [PATCH] v2: dri3: Free resources when drawable is destroyed.

[Keith Packard]

Always nice to clean up after ourselves.

Signed-off-by: Keith Packard 
---

v2: Include changes to dri3_priv.h as well

 src/glx/dri3_glx.c  | 17 -
 src/glx/dri3_priv.h |  5 -
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 239d58b..669f0bb 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -266,13 +266,25 @@ dri3_create_context(struct glx_screen *base,
 }
 
 static void
+dri3_free_render_buffer(struct dri3_drawable *pdraw, struct dri3_buffer 
*buffer);
+
+static void
 dri3_destroy_drawable(__GLXDRIdrawable *base)
 {
struct dri3_screen *psc = (struct dri3_screen *) base->psc;
struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
+   xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
+   int i;
 
(*psc->core->destroyDrawable) (pdraw->driDrawable);
 
+   for (i = 0; i < DRI3_NUM_BUFFERS; i++) {
+  if (pdraw->buffers[i])
+ dri3_free_render_buffer(pdraw, pdraw->buffers[i]);
+   }
+
+   if (pdraw->special_event)
+  xcb_unregister_for_special_event(c, pdraw->special_event);
free(pdraw);
 }
 
@@ -736,6 +748,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
   fence_fd);
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = true;
buffer->sync_fence = sync_fence;
buffer->shm_fence = shm_fence;
buffer->width = width;
@@ -769,7 +782,8 @@ dri3_free_render_buffer(struct dri3_drawable *pdraw, struct 
dri3_buffer *buffer)
struct dri3_screen   *psc = (struct dri3_screen *) pdraw->base.psc;
xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
 
-   xcb_free_pixmap(c, buffer->pixmap);
+   if (buffer->own_pixmap)
+  xcb_free_pixmap(c, buffer->pixmap);
xcb_sync_destroy_fence(c, buffer->sync_fence);
xshmfence_unmap_shm(buffer->shm_fence);
(*psc->image->destroyImage)(buffer->image);
@@ -988,6 +1002,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
   goto no_image;
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = false;
buffer->width = bp_reply->width;
buffer->height = bp_reply->height;
buffer->buffer_type = buffer_type;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 0d21e67..05f66cf 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -89,6 +89,7 @@ struct dri3_buffer {
uint32_t sync_fence; /* XID of X SyncFence object */
void *shm_fence; /* pointer to xshmfence object */
GLbooleanbusy;   /* Set on swap, cleared on IdleNotify */
+   GLbooleanown_pixmap; /* We allocated the pixmap ID, free on destroy 
*/
void *driverPrivate;
 
uint32_t size;
@@ -171,6 +172,8 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
   return DRI3_FRONT_ID;
 }
 
+#define DRI3_NUM_BUFFERS(1 + DRI3_MAX_BACK)
+
 struct dri3_drawable {
__GLXDRIdrawable base;
__DRIdrawable *driDrawable;
@@ -194,7 +197,7 @@ struct dri3_drawable {
uint64_t previous_time;
unsigned frames;
 
-   struct dri3_buffer *buffers[1 + DRI3_MAX_BACK];
+   struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;
int depth;
 
-- 
1.8.4.2

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

Re: [Mesa-dev] [PATCH 2/2] radeonsi: implement MSAA for CIK

[Michel Dänzer]

On Mit, 2013-11-20 at 15:20 +0100, Marek Olšák wrote:
> From: Marek Olšák 
> 
> There are also some changes to the printfs.

This series is

Reviewed-and-Tested-by: Michel Dänzer 


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

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

[Mesa-dev] [Bug 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate

[bugzilla-daemon]

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

--- Comment #3 from Alexandre Demers  ---
Comment on attachment 56473
  --> https://bugs.freedesktop.org/attachment.cgi?id=56473
Improved version of the patch that touches mklib as well

Review of attachment 56473:
-

::: configure.ac
@@ +1776,1 @@
>  

Since this bug as been reopened.

I may be wrong here, but according to the following patch
(http://cgit.freedesktop.org/beignet/commit/?id=25bfb6ca3b22fc8f439ebd58ee03e33bfceeb927),
using llvm-config-32 is not the same as llvm-config32. The former points to
llvm-config version 3.2 on some distributions (or it could be on concurrent
llvm installations), while the second points to a 32bit version of llvm-config.
However, on other distributions, I've seen the form you are proposing being
used to identify 32 and 64bit versions.

-- 
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 50754] Building 32 bit mesa on 64 bit OS fails since change for automake

[bugzilla-daemon]

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

--- Comment #24 from Alexandre Demers  ---
(In reply to comment #23)
> (In reply to comment #22)
> > I'm closing this bug because I'm able to crosscompile anytime with the help
> > of some variables.
> 
> This is Mesa bug.  You being able to work around Mesa bug doesn't mean that
> it's fixed in Mesa.  Re-opening.
> 
> IMHO either --enable-32-bit should be removed as misleading[1], or Mesa
> should be fixed.
> 
> [1] as discussed, it sets CFLAGS/CXXFLAGS too late, so they don't have the
> required effect.
> 
> 
> Regarding Tapani's patch fixing this, there would need to be also a comment
> in configure.ac about the libtool initialization dependency on C/XXFLAGS
> values.

The problem has been flagged many times. No decision has ever been taken.
Having a recurring bug like this one where it is a matter of either fixing it
or removing it shouldn't stay forever opened. When I closed it, because I had a
workaround, I was considering the silence on this bug and the other similar
ones as "WONTBEFIXED".

I'd be glad to either see it being fixed or dumped. As you say, if
--enable-32-bit is not working as intended for anybody, then it is misleading
and useless, thus it should be removed. In the Doc, we could indicate the
"workaround" (which is not a workaround per-se because it is actually the
detailed way of doing it instead of relying on an automated flag like
"--enable-32-bit").

We even have an almost (yet simple) patch proposed that only needs a little fix
as it seems.

-- 
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] present: Send GLX_BufferSwapComplete events from present extension

[Keith Packard]

This allows GL to support the GLX_INTEL_swap_event extension

Signed-off-by: Keith Packard 
---

This is the X server side; the mesa patch will be sent shortly (it's tiny)

 glx/Makefile.am |  3 ++-
 glx/glxcmds.c   | 69 +
 glx/glxdri2.c   | 26 +--
 glx/glxext.c|  3 +++
 glx/glxserver.h |  9 +++
 present/present.h   |  9 +++
 present/present_event.c | 10 +++
 7 files changed, 109 insertions(+), 20 deletions(-)

diff --git a/glx/Makefile.am b/glx/Makefile.am
index 5f28e87..44d3a7d 100644
--- a/glx/Makefile.am
+++ b/glx/Makefile.am
@@ -20,7 +20,8 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/hw/xfree86/os-support/bus \
-I$(top_srcdir)/hw/xfree86/common \
-I$(top_srcdir)/hw/xfree86/dri \
-   -I$(top_srcdir)/mi
+   -I$(top_srcdir)/mi \
+   -I$(top_srcdir)/present
 
 if DRI2_AIGLX
 AM_CPPFLAGS += -I$(top_srcdir)/hw/xfree86/dri2
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index efa4aec..2c5de70 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -2468,3 +2468,72 @@ __glXDisp_ClientInfo(__GLXclientState * cl, GLbyte * pc)
 
 return Success;
 }
+
+#include 
+
+void
+__glXsendSwapEvent(__GLXdrawable *drawable, int type, CARD64 ust,
+   CARD64 msc, CARD32 sbc)
+{
+ClientPtr client = clients[CLIENT_ID(drawable->drawId)];
+
+xGLXBufferSwapComplete2 wire =  {
+.type = __glXEventBase + GLX_BufferSwapComplete
+};
+
+if (!client)
+return;
+
+if (!(drawable->eventMask & GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK))
+return;
+
+wire.event_type = type;
+wire.drawable = drawable->drawId;
+wire.ust_hi = ust >> 32;
+wire.ust_lo = ust & 0x;
+wire.msc_hi = msc >> 32;
+wire.msc_lo = msc & 0x;
+wire.sbc = sbc;
+
+WriteEventsToClient(client, 1, (xEvent *) &wire);
+}
+
+#if PRESENT
+static void
+__glXpresentCompleteNotify(WindowPtr window, CARD8 present_mode, CARD32 serial,
+   uint64_t ust, uint64_t msc)
+{
+__GLXdrawable *drawable;
+int error;
+int glx_type;
+int rc;
+
+rc = dixLookupResourceByType((pointer *) &drawable, window->drawable.id,
+ __glXDrawableRes, serverClient, 
DixGetAttrAccess);
+
+if (rc != Success)
+return;
+
+switch(present_mode) {
+case PresentCompleteModeFlip:
+glx_type = GLX_FLIP_COMPLETE_INTEL;
+break;
+case PresentCompleteModeCopy:
+glx_type = GLX_BLIT_COMPLETE_INTEL;
+break;
+default:
+glx_type = 0;
+break;
+}
+
+__glXsendSwapEvent(drawable, glx_type, ust, msc, serial);
+}
+
+#include 
+
+void
+__glXregisterPresentCompleteNotify(void)
+{
+present_register_complete_notify(__glXpresentCompleteNotify);
+}
+#endif
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 1d74c8f..9d3f3c3 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -177,36 +177,24 @@ __glXdriSwapEvent(ClientPtr client, void *data, int type, 
CARD64 ust,
   CARD64 msc, CARD32 sbc)
 {
 __GLXdrawable *drawable = data;
-xGLXBufferSwapComplete2 wire =  {
-.type = __glXEventBase + GLX_BufferSwapComplete
-};
-
-if (!(drawable->eventMask & GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK))
-return;
-
+int glx_type;
 switch (type) {
 case DRI2_EXCHANGE_COMPLETE:
-wire.event_type = GLX_EXCHANGE_COMPLETE_INTEL;
+glx_type = GLX_EXCHANGE_COMPLETE_INTEL;
 break;
 case DRI2_BLIT_COMPLETE:
-wire.event_type = GLX_BLIT_COMPLETE_INTEL;
+glx_type = GLX_BLIT_COMPLETE_INTEL;
 break;
 case DRI2_FLIP_COMPLETE:
-wire.event_type = GLX_FLIP_COMPLETE_INTEL;
+glx_type = GLX_FLIP_COMPLETE_INTEL;
 break;
 default:
 /* unknown swap completion type */
-wire.event_type = 0;
+glx_type = 0;
 break;
 }
-wire.drawable = drawable->drawId;
-wire.ust_hi = ust >> 32;
-wire.ust_lo = ust & 0x;
-wire.msc_hi = msc >> 32;
-wire.msc_lo = msc & 0x;
-wire.sbc = sbc;
-
-WriteEventsToClient(client, 1, (xEvent *) &wire);
+
+__glXsendSwapEvent(drawable, glx_type, ust, msc, sbc);
 }
 
 /*
diff --git a/glx/glxext.c b/glx/glxext.c
index 3a7de28..601d08a 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -399,6 +399,9 @@ GlxExtensionInit(void)
 
 __glXErrorBase = extEntry->errorBase;
 __glXEventBase = extEntry->eventBase;
+#if PRESENT
+__glXregisterPresentCompleteNotify();
+#endif
 }
 
 //
diff --git a/glx/glxserver.h b/glx/glxserver.h
index 5e29abb..f862b63 100644
--- a/glx/glxserver.h
+++ b/glx/glxserver.h
@@ -120,6 +120,15 @@ void glxResumeClients(void);
 void __glXsetGetProcAddress(void (*(*get_proc_address) (const char *)) (void));
 void *__glGetProcAddress(const char *);
 
+void
+__glXsendSw

[Mesa-dev] [PATCH] dri3: Support GLX_INTEL_swap_event

[Keith Packard]

The easy part is turning on the extension, now that the X server has a patch
to send the events.

The only trick was making sure the Present extension reliably provided the
right 'sbc' count back in the event, and that's done by making sure the sbc
count is always the same as the sequence number that we send in the
PresentPixmap requests, and that's done by using the same variable for both
roles.

Signed-off-by: Keith Packard 
---

This passes the piglet glx-swap-event test.

 src/glx/dri3_glx.c  | 27 ++-
 src/glx/dri3_priv.h |  3 +--
 2 files changed, 7 insertions(+), 23 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 669f0bb..a7bf318 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -423,7 +423,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
 
*ust = priv->ust;
*msc = priv->msc;
-   *sbc = priv->sbc;
+   *sbc = priv->present_count;
 
return 1;
 }
@@ -450,7 +450,7 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t 
target_sbc, int64_t *ust,
 {
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
 
-   while (priv->sbc < target_sbc) {
+   while (priv->present_count < target_sbc) {
   sleep(1);
}
return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
@@ -1282,7 +1282,8 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
   /* Compute when we want the frame shown by taking the last known 
successful
* MSC and adding in a swap interval for each outstanding swap request
*/
-  ++priv->present_request_serial;
+  ++priv->present_count;
+  priv->present_request_serial = (uint32_t) priv->present_count;
   if (target_msc == 0)
  target_msc = priv->msc + priv->swap_interval * 
(priv->present_request_serial - priv->present_event_serial);
 
@@ -1302,7 +1303,7 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
  target_msc,
  divisor,
  remainder, 0, NULL);
-  ret = ++priv->sbc;
+  ret = priv->present_count;
 
   /* If there's a fake front, then copy the source back buffer
* to the fake front to keep it up to date. This needs
@@ -1494,23 +1495,7 @@ dri3_bind_extensions(struct dri3_screen *psc, struct 
glx_display * priv,
__glXEnableDirectExtension(&psc->base, "GLX_SGI_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_MESA_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_SGI_make_current_read");
-
-   /*
-* GLX_INTEL_swap_event is broken on the server side, where it's
-* currently unconditionally enabled. This completely breaks
-* systems running on drivers which don't support that extension.
-* There's no way to test for its presence on this side, so instead
-* of disabling it unconditionally, just disable it for drivers
-* which are known to not support it, or for DDX drivers supporting
-* only an older (pre-ScheduleSwap) version of DRI2.
-*
-* This is a hack which is required until:
-* http://lists.x.org/archives/xorg-devel/2013-February/035449.html
-* is merged and updated xserver makes it's way into distros:
-*/
-//   if (pdp->swapAvailable && strcmp(driverName, "vmwgfx") != 0) {
-//  __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
-//   }
+   __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
 
mask = psc->image_driver->getAPIMask(psc->driScreen);
 
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 05f66cf..cdf986d 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -183,11 +183,10 @@ struct dri3_drawable {
uint8_t have_fake_front;
uint8_t is_pixmap;
 
+   uint64_t present_count;
uint32_t present_request_serial;
uint32_t present_event_serial;
 
-   uint64_t sbc;
-
uint64_t ust, msc;
 
/* For WaitMSC */
-- 
1.8.4.2

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

[Mesa-dev] [Bug 50754] Building 32 bit mesa on 64 bit OS fails since change for automake

[bugzilla-daemon]

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

Alexandre Demers  changed:

   What|Removed |Added

  Attachment #65690|0   |1
is obsolete||

--- Comment #25 from Alexandre Demers  ---
Created attachment 89621
  --> https://bugs.freedesktop.org/attachment.cgi?id=89621&action=edit
Move LT_INIT where it should so it can test correctly (AM_)C(XX)FLAGS and
others

Updated patch against latest git code.
Based on previous patch with further explanations.

LT_INIT needs to work with the final content of variables to be able to
correctly run some tests and determine the host type. So it must be called
after setting anything we want to set in (AM_)C(XX)FLAGS or (AM_)LDFLAGS.

Fixing LT_INIT must be done independently from modifying environment variables
or build variables since LT_INIT will check both variables and shadow variables
if they are set.

Tested on my setup and it works. I'd like someone else to also test it.

Another patch should be made to fix llvm-config, which is another topic.

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