Re: [Mesa-dev] [PATCH] i965: Fix missing _NEW_SCISSOR in Broadwell SF_CLIP_VIEWPORT state.

[Timo Aaltonen]

Yep, fixed!

Tested-by: Timo Aaltonen 

On 10.04.2014 08:54, Kenneth Graunke wrote:
> The _Xmin/_Xmax/_Ymin/_Ymax values need to be guarded by _NEW_SCISSOR.
> 
> Fixes Piglit's scissor-many, and rendering in GNOME Shell.
> Hopefully fixes similar issues with Unity and ChromeOS.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75879
> Signed-off-by: Kenneth Graunke 
> Cc: Timo Aaltonen 
> Cc: James Ausmus 
> ---
>  src/mesa/drivers/dri/i965/gen8_viewport_state.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/gen8_viewport_state.c 
> b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
> index 344310e..b366246 100644
> --- a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
> +++ b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
> @@ -86,7 +86,7 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
>vp[10] = -gby; /* y-min */
>vp[11] =  gby; /* y-max */
>  
> -  /* Screen Space Viewport */
> +  /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space Viewport 
> */
>if (render_to_fbo) {
>   vp[12] = ctx->DrawBuffer->_Xmin;
>   vp[13] = ctx->DrawBuffer->_Xmax - 1;
> @@ -110,7 +110,7 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
>  
>  const struct brw_tracked_state gen8_sf_clip_viewport = {
> .dirty = {
> -  .mesa = _NEW_VIEWPORT | _NEW_BUFFERS,
> +  .mesa = _NEW_BUFFERS | _NEW_SCISSOR | _NEW_VIEWPORT,
>.brw = BRW_NEW_BATCH,
>.cache = 0,
> },
> 


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

[Mesa-dev] [PATCH] gallium/targets: #include radeon_winsys.h in a couple of more places

[Michel Dänzer]

From: Michel Dänzer 

Fixes the build since Marek's recent radeon winsys reorganization.

Signed-off-by: Michel Dänzer 
---
 src/gallium/targets/egl-static/egl_pipe.c   | 1 +
 src/gallium/targets/pipe-loader/pipe_r300.c | 1 +
 src/gallium/targets/pipe-loader/pipe_r600.c | 1 +
 src/gallium/targets/pipe-loader/pipe_radeonsi.c | 1 +
 4 files changed, 4 insertions(+)

diff --git a/src/gallium/targets/egl-static/egl_pipe.c 
b/src/gallium/targets/egl-static/egl_pipe.c
index ce734fb..7e6f711 100644
--- a/src/gallium/targets/egl-static/egl_pipe.c
+++ b/src/gallium/targets/egl-static/egl_pipe.c
@@ -39,6 +39,7 @@
 #include "nouveau/drm/nouveau_drm_public.h"
 /* for r300 */
 #include "radeon/drm/radeon_drm_public.h"
+#include "radeon/drm/radeon_winsys.h"
 #include "r300/r300_public.h"
 /* for r600 */
 #include "r600/r600_public.h"
diff --git a/src/gallium/targets/pipe-loader/pipe_r300.c 
b/src/gallium/targets/pipe-loader/pipe_r300.c
index 388b091..b436ce2 100644
--- a/src/gallium/targets/pipe-loader/pipe_r300.c
+++ b/src/gallium/targets/pipe-loader/pipe_r300.c
@@ -2,6 +2,7 @@
 #include "target-helpers/inline_debug_helper.h"
 #include "state_tracker/drm_driver.h"
 #include "radeon/drm/radeon_drm_public.h"
+#include "radeon/drm/radeon_winsys.h"
 #include "r300/r300_public.h"
 
 static struct pipe_screen *
diff --git a/src/gallium/targets/pipe-loader/pipe_r600.c 
b/src/gallium/targets/pipe-loader/pipe_r600.c
index 0c59087..2e6bd42 100644
--- a/src/gallium/targets/pipe-loader/pipe_r600.c
+++ b/src/gallium/targets/pipe-loader/pipe_r600.c
@@ -1,6 +1,7 @@
 #include "state_tracker/drm_driver.h"
 #include "target-helpers/inline_debug_helper.h"
 #include "radeon/drm/radeon_drm_public.h"
+#include "radeon/drm/radeon_winsys.h"
 #include "r600/r600_public.h"
 
 static struct pipe_screen *
diff --git a/src/gallium/targets/pipe-loader/pipe_radeonsi.c 
b/src/gallium/targets/pipe-loader/pipe_radeonsi.c
index 406ba1e..9a8feae 100644
--- a/src/gallium/targets/pipe-loader/pipe_radeonsi.c
+++ b/src/gallium/targets/pipe-loader/pipe_radeonsi.c
@@ -1,6 +1,7 @@
 #include "state_tracker/drm_driver.h"
 #include "target-helpers/inline_debug_helper.h"
 #include "radeon/drm/radeon_drm_public.h"
+#include "radeon/drm/radeon_winsys.h"
 #include "radeonsi/si_public.h"
 
 static struct pipe_screen *
-- 
1.9.0

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

Re: [Mesa-dev] [PATCH] i965: fix MakeCurrent when switching a context between multiple drawables.

[Michel Dänzer]

On Don, 2014-04-10 at 12:22 -0700, Ian Romanick wrote:
> On 04/10/2014 03:39 AM, Iago Toral wrote:
> > On Thu, 2014-04-10 at 10:31 +0200, Iago Toral wrote:
> >> Hi Kristian,
> >>
> >> On Tue, 2014-04-08 at 10:14 -0700, Kristian Høgsberg wrote:
> >>> On Mon, Apr 7, 2014 at 9:24 AM, Eric Anholt  wrote:
>  Iago Toral Quiroga  writes:
> 
> > Commit 11baad35088dfd4bdabc1710df650dbfb413e7a3 produces a regression 
> > when
> > switching a single context between multiple drawables.
> >
> > The problem is that we check whether we have a viewport set to decide 
> > if we
> > need to generate buffers for the drawble, but the viewport is 
> > initialized
> > with the first call to MakeCurrent for that context, so calling 
> > MakeCurrent on
> > the same context with a different drawable will have the viewport 
> > already
> > initialized and will not generate buffers for the new drawable.
> >
> > This patch fixes the problem by reverting to the previous solution 
> > implemented
> > in commit 05da4a7a5e7d5bd988cb31f94ed8e1f053d9ee39 with a small fix to 
> > suppport
> > single buffer drawables too. This solution checks if we have a 
> > renderbuffer for
> > the drawable to decide if we need to generate a buffer or not. The 
> > original
> > implementation, however, did this by checking the BACK_LEFT buffer, 
> > which is
> > not a valid solution for single buffer drawables. This patch modifies 
> > this
> > to check the FRONT_LEFT buffer instead, which should work in both 
> > scenarios.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74005
> > ---
> >  src/mesa/drivers/dri/i965/brw_context.c | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> > b/src/mesa/drivers/dri/i965/brw_context.c
> > index c9719f5..c593286 100644
> > --- a/src/mesa/drivers/dri/i965/brw_context.c
> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
> > @@ -926,6 +926,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> >  {
> > struct brw_context *brw;
> > GET_CURRENT_CONTEXT(curCtx);
> > +   struct intel_renderbuffer *rb = NULL;
> >
> > if (driContextPriv)
> >brw = (struct brw_context *) driContextPriv->driverPrivate;
> > @@ -950,6 +951,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> >} else {
> >   fb = driDrawPriv->driverPrivate;
> >   readFb = driReadPriv->driverPrivate;
> > + rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> >   driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1;
> >   driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1;
> >}
> > @@ -961,10 +963,9 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> >intel_gles3_srgb_workaround(brw, fb);
> >intel_gles3_srgb_workaround(brw, readFb);
> >
> > -  /* If the context viewport hasn't been initialized, force a call 
> > out to
> > -   * the loader to get buffers so we have a drawable size for the 
> > initial
> > -   * viewport. */
> > -  if (!brw->ctx.ViewportInitialized)
> > +  /* If we don't have buffers for the drawable yet, force a call to
> > +   * getbuffers here so we can have a default drawable size. */
> > +  if (rb && !rb->mt)
> >   intel_prepare_render(brw);
> 
>  We won't have an rb->mt for the front unless you're doing front buffer
>  rendering, so I think you're basically just backing out krh's change.
>  Which I think is good -- it looks like he was papering over a bug
>  elsewhere, and I think we *should* just prepare_render in makecurrent.
>  But if we're going to revert, let's just actually revert.
> >>>
> >>> Here's what I wrote in https://bugs.freedesktop.org/show_bug.cgi?id=74005:
> >>> We don't want to revert the behaviour.  The initial patch removed a
> >>> call to intel_prepare_render() in intelMakeCurrent().  We're supposed
> >>> to call intel_prepare_render() any time we're about to touch the
> >>> buffers, but the up-front call to intel_prepare_render() in
> >>> intelMakeCurrent covered up a few places where we forgot.  The fix now
> >>> isn't to put back the up-front intel_prepare_render() call but to add
> >>> it in the rendering paths that are missing it.
> >>
> >> Thanks for explaining. I will try to find the place where we are missing
> >> the intel_prepare_render() call in this particular bug.
> > 
> > Actually, as far as I can see, we are already calling
> > intel_prepare_render() in the render path that is causing this problem,
> > but it turns out that by the time we have the chance to do that it is
> > already too late. I explain:
> > 
> > The test case is pretty much this:
> > 
> > glXMakeCurre

Re: [Mesa-dev] [PATCH 3/4] mesa: use _mesa_get_srgb_format_linear() in sRGB texstore functions

[Chris Forbes]

I was about to get to this, really! :P

This patch is:

Reviewed-by: Chris Forbes 


On Fri, Apr 11, 2014 at 1:04 PM, Brian Paul  wrote:
> Instead of switch statements.
> ---
>  src/mesa/main/texstore.c |   30 +-
>  1 file changed, 5 insertions(+), 25 deletions(-)
>
> diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
> index fe3b072..d9096ab 100644
> --- a/src/mesa/main/texstore.c
> +++ b/src/mesa/main/texstore.c
> @@ -3263,20 +3263,7 @@ _mesa_texstore_srgba8(TEXSTORE_PARAMS)
>dstFormat == MESA_FORMAT_R8G8B8X8_SRGB ||
>dstFormat == MESA_FORMAT_R8G8B8A8_SRGB);
>
> -   /* reuse normal rgba texstore code */
> -   if (dstFormat == MESA_FORMAT_A8B8G8R8_SRGB) {
> -  newDstFormat = MESA_FORMAT_A8B8G8R8_UNORM;
> -   }
> -   else if (dstFormat == MESA_FORMAT_R8G8B8A8_SRGB) {
> -  newDstFormat = MESA_FORMAT_R8G8B8A8_UNORM;
> -   }
> -   else if (dstFormat == MESA_FORMAT_R8G8B8X8_SRGB) {
> -  newDstFormat = MESA_FORMAT_R8G8B8X8_UNORM;
> -   }
> -   else {
> -  ASSERT(0);
> -  return GL_TRUE;
> -   }
> +   newDstFormat = _mesa_get_srgb_format_linear(dstFormat);
>
> k = _mesa_texstore_rgba(ctx, dims, baseInternalFormat,
> newDstFormat,
> @@ -3294,17 +3281,10 @@ _mesa_texstore_sargb8(TEXSTORE_PARAMS)
> mesa_format newDstFormat;
> GLboolean k;
>
> -   switch (dstFormat) {
> -   case MESA_FORMAT_B8G8R8A8_SRGB:
> -  newDstFormat = MESA_FORMAT_B8G8R8A8_UNORM;
> -  break;
> -   case MESA_FORMAT_B8G8R8X8_SRGB:
> -  newDstFormat = MESA_FORMAT_B8G8R8X8_UNORM;
> -  break;
> -   default:
> -  ASSERT(0);
> -  return GL_FALSE;
> -   }
> +   assert(dstFormat == MESA_FORMAT_B8G8R8A8_SRGB ||
> +  dstFormat == MESA_FORMAT_B8G8R8X8_SRGB);
> +
> +   newDstFormat = _mesa_get_srgb_format_linear(dstFormat);
>
> k = _mesa_texstore_argb(ctx, dims, baseInternalFormat,
> newDstFormat,
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] softpipe: add PIPE_CAP_MIN/MAX_TEXTURE_GATHER_OFFSET query cases

[Ilia Mirkin]

On Thu, Apr 10, 2014 at 9:04 PM, Brian Paul  wrote:
> To silence compiler warnings.

Reviewed-by: Ilia Mirkin 

Sorry I missed sp_screen.c :( I thought I had gotten everything.

> ---
>  src/gallium/drivers/softpipe/sp_screen.c |3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/drivers/softpipe/sp_screen.c 
> b/src/gallium/drivers/softpipe/sp_screen.c
> index ce04fb8..b4ca728 100644
> --- a/src/gallium/drivers/softpipe/sp_screen.c
> +++ b/src/gallium/drivers/softpipe/sp_screen.c
> @@ -192,6 +192,9 @@ softpipe_get_param(struct pipe_screen *screen, enum 
> pipe_cap param)
>return 0;
> case PIPE_CAP_FAKE_SW_MSAA:
>return 1;
> +   case PIPE_CAP_MIN_TEXTURE_GATHER_OFFSET:
> +   case PIPE_CAP_MAX_TEXTURE_GATHER_OFFSET:
> +  return 0;
> }
> /* should only get here on unhandled cases */
> debug_printf("Unexpected PIPE_CAP %d query\n", param);
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] swrast: use macros to initialize texfetch_funcs[] table

[Brian Paul]

---
 src/mesa/swrast/s_texfetch.c | 1109 +++---
 1 file changed, 172 insertions(+), 937 deletions(-)

diff --git a/src/mesa/swrast/s_texfetch.c b/src/mesa/swrast/s_texfetch.c
index 2a6eee0..90a514c 100644
--- a/src/mesa/swrast/s_texfetch.c
+++ b/src/mesa/swrast/s_texfetch.c
@@ -129,9 +129,24 @@ static void fetch_null_texelf( const struct 
swrast_texture_image *texImage,
 }
 
 
+#define FETCH_FUNCS(NAME)   \
+   {\
+  MESA_FORMAT_ ## NAME, \
+  fetch_texel_1d_ ## NAME,  \
+  fetch_texel_2d_ ## NAME,  \
+  fetch_texel_3d_ ## NAME,  \
+   }
+
+#define FETCH_NULL(NAME)\
+   {\
+  MESA_FORMAT_ ## NAME, \
+  NULL, \
+  NULL, \
+  NULL  \
+   }
+
 /**
  * Table to map MESA_FORMAT_ to texel fetch/store funcs.
- * XXX this is somewhat temporary.
  */
 static struct {
mesa_format Name;
@@ -149,632 +164,132 @@ texfetch_funcs[] =
},
 
/* Packed unorm formats */
-   {
-  MESA_FORMAT_A8B8G8R8_UNORM,
-  fetch_texel_1d_A8B8G8R8_UNORM,
-  fetch_texel_2d_A8B8G8R8_UNORM,
-  fetch_texel_3d_A8B8G8R8_UNORM
-   },
-   {
-  MESA_FORMAT_X8B8G8R8_UNORM,
-  fetch_texel_1d_X8B8G8R8_UNORM,
-  fetch_texel_2d_X8B8G8R8_UNORM,
-  fetch_texel_3d_X8B8G8R8_UNORM
-   },
-   {
-  MESA_FORMAT_R8G8B8A8_UNORM,
-  fetch_texel_1d_R8G8B8A8_UNORM,
-  fetch_texel_2d_R8G8B8A8_UNORM,
-  fetch_texel_3d_R8G8B8A8_UNORM
-   },
-   {
-  MESA_FORMAT_R8G8B8X8_UNORM,
-  fetch_texel_1d_R8G8B8X8_UNORM,
-  fetch_texel_2d_R8G8B8X8_UNORM,
-  fetch_texel_3d_R8G8B8X8_UNORM
-   },
-   {
-  MESA_FORMAT_B8G8R8A8_UNORM,
-  fetch_texel_1d_B8G8R8A8_UNORM,
-  fetch_texel_2d_B8G8R8A8_UNORM,
-  fetch_texel_3d_B8G8R8A8_UNORM
-   },
-   {
-  MESA_FORMAT_B8G8R8X8_UNORM,
-  fetch_texel_1d_B8G8R8X8_UNORM,
-  fetch_texel_2d_B8G8R8X8_UNORM,
-  fetch_texel_3d_B8G8R8X8_UNORM
-   },
-   {
-  MESA_FORMAT_A8R8G8B8_UNORM,
-  fetch_texel_1d_A8R8G8B8_UNORM,
-  fetch_texel_2d_A8R8G8B8_UNORM,
-  fetch_texel_3d_A8R8G8B8_UNORM
-   },
-   {
-  MESA_FORMAT_X8R8G8B8_UNORM,
-  fetch_texel_1d_X8R8G8B8_UNORM,
-  fetch_texel_2d_X8R8G8B8_UNORM,
-  fetch_texel_3d_X8R8G8B8_UNORM
-   },
-   {
-  MESA_FORMAT_L16A16_UNORM,
-  fetch_texel_1d_L16A16_UNORM,
-  fetch_texel_2d_L16A16_UNORM,
-  fetch_texel_3d_L16A16_UNORM
-   },
-   {
-  MESA_FORMAT_A16L16_UNORM,
-  fetch_texel_1d_A16L16_UNORM,
-  fetch_texel_2d_A16L16_UNORM,
-  fetch_texel_3d_A16L16_UNORM
-   },
-   {
-  MESA_FORMAT_B5G6R5_UNORM,
-  fetch_texel_1d_B5G6R5_UNORM,
-  fetch_texel_2d_B5G6R5_UNORM,
-  fetch_texel_3d_B5G6R5_UNORM
-   },
-   {
-  MESA_FORMAT_R5G6B5_UNORM,
-  fetch_texel_1d_R5G6B5_UNORM,
-  fetch_texel_2d_R5G6B5_UNORM,
-  fetch_texel_3d_R5G6B5_UNORM
-   },
-   {
-  MESA_FORMAT_B4G4R4A4_UNORM,
-  fetch_texel_1d_B4G4R4A4_UNORM,
-  fetch_texel_2d_B4G4R4A4_UNORM,
-  fetch_texel_3d_B4G4R4A4_UNORM
-   },
-   {
-  MESA_FORMAT_B4G4R4X4_UNORM,
-  NULL,
-  NULL,
-  NULL
-   },
-   {
-  MESA_FORMAT_A4R4G4B4_UNORM,
-  fetch_texel_1d_A4R4G4B4_UNORM,
-  fetch_texel_2d_A4R4G4B4_UNORM,
-  fetch_texel_3d_A4R4G4B4_UNORM
-   },
-   {
-  MESA_FORMAT_A1B5G5R5_UNORM,
-  fetch_texel_1d_A1B5G5R5_UNORM,
-  fetch_texel_2d_A1B5G5R5_UNORM,
-  fetch_texel_3d_A1B5G5R5_UNORM
-   },
-   {
-  MESA_FORMAT_B5G5R5A1_UNORM,
-  fetch_texel_1d_B5G5R5A1_UNORM,
-  fetch_texel_2d_B5G5R5A1_UNORM,
-  fetch_texel_3d_B5G5R5A1_UNORM
-   },
-   {
-  MESA_FORMAT_B5G5R5X1_UNORM,
-  NULL,
-  NULL,
-  NULL
-   },
-   {
-  MESA_FORMAT_A1R5G5B5_UNORM,
-  fetch_texel_1d_A1R5G5B5_UNORM,
-  fetch_texel_2d_A1R5G5B5_UNORM,
-  fetch_texel_3d_A1R5G5B5_UNORM
-   },
-   {
-  MESA_FORMAT_L8A8_UNORM,
-  fetch_texel_1d_L8A8_UNORM,
-  fetch_texel_2d_L8A8_UNORM,
-  fetch_texel_3d_L8A8_UNORM
-   },
-   {
-  MESA_FORMAT_A8L8_UNORM,
-  fetch_texel_1d_A8L8_UNORM,
-  fetch_texel_2d_A8L8_UNORM,
-  fetch_texel_3d_A8L8_UNORM
-   },
-   {
-  MESA_FORMAT_R8G8_UNORM,
-  fetch_texel_1d_R8G8_UNORM,
-  fetch_texel_2d_R8G8_UNORM,
-  fetch_texel_3d_R8G8_UNORM
-   },
-   {
-  MESA_FORMAT_G8R8_UNORM,
-  fetch_texel_1d_G8R8_UNORM,
-  fetch_texel_2d_G8R8_UNORM,
-  fetch_texel_3d_G8R8_UNORM
-   },
-   {
-  MESA_FORMAT_L4A4_UNORM,
-  fetch_texel_1d_L4A4_UNORM,
-  fetch_texel_2d_L4A4_UNORM,
-  fetch_texel_3d_L4A4_UNORM
-   },
-   {
-  MESA_FORMAT_B2G3R3_UNORM,
-  fetch_texel_1d_B2G3R3_UNORM,
-  fetch_texel_2d_B2G3R3_UNORM,
-  fetch_texel_3d_B2G3R3_UNORM
-   },
-   {
-  MESA_FORMAT_R16G16_UNORM,
-  fetch_texel_1d_R16G16_UNORM,
-  fetch_texel_2d_R16G16_UNORM,
-  fetch_texel_3d_R16G16_UNORM
-   },
-   {
-  

[Mesa-dev] [PATCH 4/4] softpipe: add PIPE_CAP_MIN/MAX_TEXTURE_GATHER_OFFSET query cases

[Brian Paul]

To silence compiler warnings.
---
 src/gallium/drivers/softpipe/sp_screen.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/softpipe/sp_screen.c 
b/src/gallium/drivers/softpipe/sp_screen.c
index ce04fb8..b4ca728 100644
--- a/src/gallium/drivers/softpipe/sp_screen.c
+++ b/src/gallium/drivers/softpipe/sp_screen.c
@@ -192,6 +192,9 @@ softpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
   return 0;
case PIPE_CAP_FAKE_SW_MSAA:
   return 1;
+   case PIPE_CAP_MIN_TEXTURE_GATHER_OFFSET:
+   case PIPE_CAP_MAX_TEXTURE_GATHER_OFFSET:
+  return 0;
}
/* should only get here on unhandled cases */
debug_printf("Unexpected PIPE_CAP %d query\n", param);
-- 
1.7.10.4

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

[Mesa-dev] [PATCH 1/4] swrast: fix more fetch_texel function names

[Brian Paul]

These were missed/typo'd in the previous patch series:
s/R8G8B8A/R8G8B8A8/
s/rgba_16/RGBA_UNORM16/
s/rgba_uint/RGBA_UINT/
s/rgba_int/RGBA_SINT/
---
 src/mesa/swrast/s_texfetch.c |   48 +++---
 src/mesa/swrast/s_texfetch_tmp.h |   26 ++---
 2 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/src/mesa/swrast/s_texfetch.c b/src/mesa/swrast/s_texfetch.c
index 098a32f..2a6eee0 100644
--- a/src/mesa/swrast/s_texfetch.c
+++ b/src/mesa/swrast/s_texfetch.c
@@ -163,9 +163,9 @@ texfetch_funcs[] =
},
{
   MESA_FORMAT_R8G8B8A8_UNORM,
-  fetch_texel_1d_R8G8B8A_UNORM,
-  fetch_texel_2d_R8G8B8A_UNORM,
-  fetch_texel_3d_R8G8B8A_UNORM
+  fetch_texel_1d_R8G8B8A8_UNORM,
+  fetch_texel_2d_R8G8B8A8_UNORM,
+  fetch_texel_3d_R8G8B8A8_UNORM
},
{
   MESA_FORMAT_R8G8B8X8_UNORM,
@@ -435,9 +435,9 @@ texfetch_funcs[] =
},
{
   MESA_FORMAT_RGBA_UNORM16,
-  fetch_texel_1d_rgba_16,
-  fetch_texel_2d_rgba_16,
-  fetch_texel_3d_rgba_16
+  fetch_texel_1d_RGBA_UNORM16,
+  fetch_texel_2d_RGBA_UNORM16,
+  fetch_texel_3d_RGBA_UNORM16
},
{
   MESA_FORMAT_RGBX_UNORM16,
@@ -1051,39 +1051,39 @@ texfetch_funcs[] =
},
{
   MESA_FORMAT_RGBA_UINT8,
-  fetch_texel_1d_rgba_uint8,
-  fetch_texel_2d_rgba_uint8,
-  fetch_texel_3d_rgba_uint8
+  fetch_texel_1d_RGBA_UINT8,
+  fetch_texel_2d_RGBA_UINT8,
+  fetch_texel_3d_RGBA_UINT8
},
{
   MESA_FORMAT_RGBA_UINT16,
-  fetch_texel_1d_rgba_uint16,
-  fetch_texel_2d_rgba_uint16,
-  fetch_texel_3d_rgba_uint16
+  fetch_texel_1d_RGBA_UINT16,
+  fetch_texel_2d_RGBA_UINT16,
+  fetch_texel_3d_RGBA_UINT16
},
{
   MESA_FORMAT_RGBA_UINT32,
-  fetch_texel_1d_rgba_uint32,
-  fetch_texel_2d_rgba_uint32,
-  fetch_texel_3d_rgba_uint32
+  fetch_texel_1d_RGBA_UINT32,
+  fetch_texel_2d_RGBA_UINT32,
+  fetch_texel_3d_RGBA_UINT32
},
{
   MESA_FORMAT_RGBA_SINT8,
-  fetch_texel_1d_rgba_int8,
-  fetch_texel_2d_rgba_int8,
-  fetch_texel_3d_rgba_int8
+  fetch_texel_1d_RGBA_SINT8,
+  fetch_texel_2d_RGBA_SINT8,
+  fetch_texel_3d_RGBA_SINT8
},
{
   MESA_FORMAT_RGBA_SINT16,
-  fetch_texel_1d_rgba_int16,
-  fetch_texel_2d_rgba_int16,
-  fetch_texel_3d_rgba_int16
+  fetch_texel_1d_RGBA_SINT16,
+  fetch_texel_2d_RGBA_SINT16,
+  fetch_texel_3d_RGBA_SINT16
},
{
   MESA_FORMAT_RGBA_SINT32,
-  fetch_texel_1d_rgba_int32,
-  fetch_texel_2d_rgba_int32,
-  fetch_texel_3d_rgba_int32
+  fetch_texel_1d_RGBA_SINT32,
+  fetch_texel_2d_RGBA_SINT32,
+  fetch_texel_3d_RGBA_SINT32
},
{
   MESA_FORMAT_RGBX_UINT8,
diff --git a/src/mesa/swrast/s_texfetch_tmp.h b/src/mesa/swrast/s_texfetch_tmp.h
index c783ae3..d48e39b 100644
--- a/src/mesa/swrast/s_texfetch_tmp.h
+++ b/src/mesa/swrast/s_texfetch_tmp.h
@@ -292,8 +292,8 @@ FETCH(A8B8G8R8_UNORM)(const struct swrast_texture_image 
*texImage,
 
 
 static void
-FETCH(R8G8B8A_UNORM)(const struct swrast_texture_image *texImage,
- GLint i, GLint j, GLint k, GLfloat *texel)
+FETCH(R8G8B8A8_UNORM)(const struct swrast_texture_image *texImage,
+  GLint i, GLint j, GLint k, GLfloat *texel)
 {
const GLuint s = *TEXEL_ADDR(GLuint, texImage, i, j, k, 1);
texel[RCOMP] = UBYTE_TO_FLOAT( (s  ) & 0xff );
@@ -817,8 +817,8 @@ FETCH(L8A8_SRGB)(const struct swrast_texture_image 
*texImage,
 
 
 static void
-FETCH(rgba_int8)(const struct swrast_texture_image *texImage,
- GLint i, GLint j, GLint k, GLfloat *texel)
+FETCH(RGBA_SINT8)(const struct swrast_texture_image *texImage,
+  GLint i, GLint j, GLint k, GLfloat *texel)
 {
const GLbyte *src = TEXEL_ADDR(GLbyte, texImage, i, j, k, 4);
texel[RCOMP] = (GLfloat) src[0];
@@ -829,8 +829,8 @@ FETCH(rgba_int8)(const struct swrast_texture_image 
*texImage,
 
 
 static void
-FETCH(rgba_int16)(const struct swrast_texture_image *texImage,
-  GLint i, GLint j, GLint k, GLfloat *texel)
+FETCH(RGBA_SINT16)(const struct swrast_texture_image *texImage,
+   GLint i, GLint j, GLint k, GLfloat *texel)
 {
const GLshort *src = TEXEL_ADDR(GLshort, texImage, i, j, k, 4);
texel[RCOMP] = (GLfloat) src[0];
@@ -841,8 +841,8 @@ FETCH(rgba_int16)(const struct swrast_texture_image 
*texImage,
 
 
 static void
-FETCH(rgba_int32)(const struct swrast_texture_image *texImage,
-  GLint i, GLint j, GLint k, GLfloat *texel)
+FETCH(RGBA_SINT32)(const struct swrast_texture_image *texImage,
+   GLint i, GLint j, GLint k, GLfloat *texel)
 {
const GLint *src = TEXEL_ADDR(GLint, texImage, i, j, k, 4);
texel[RCOMP] = (GLfloat) src[0];
@@ -853,7 +853,7 @@ FETCH(rgba_int32)(const struct swrast_texture_image 
*texImage,
 
 
 static void
-FETCH(rgba_uint8)(const struct swrast_texture_image

[Mesa-dev] [PATCH 3/4] mesa: use _mesa_get_srgb_format_linear() in sRGB texstore functions

[Brian Paul]

Instead of switch statements.
---
 src/mesa/main/texstore.c |   30 +-
 1 file changed, 5 insertions(+), 25 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index fe3b072..d9096ab 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -3263,20 +3263,7 @@ _mesa_texstore_srgba8(TEXSTORE_PARAMS)
   dstFormat == MESA_FORMAT_R8G8B8X8_SRGB ||
   dstFormat == MESA_FORMAT_R8G8B8A8_SRGB);
 
-   /* reuse normal rgba texstore code */
-   if (dstFormat == MESA_FORMAT_A8B8G8R8_SRGB) {
-  newDstFormat = MESA_FORMAT_A8B8G8R8_UNORM;
-   }
-   else if (dstFormat == MESA_FORMAT_R8G8B8A8_SRGB) {
-  newDstFormat = MESA_FORMAT_R8G8B8A8_UNORM;
-   }
-   else if (dstFormat == MESA_FORMAT_R8G8B8X8_SRGB) {
-  newDstFormat = MESA_FORMAT_R8G8B8X8_UNORM;
-   }
-   else {
-  ASSERT(0);
-  return GL_TRUE;
-   }
+   newDstFormat = _mesa_get_srgb_format_linear(dstFormat);
 
k = _mesa_texstore_rgba(ctx, dims, baseInternalFormat,
newDstFormat,
@@ -3294,17 +3281,10 @@ _mesa_texstore_sargb8(TEXSTORE_PARAMS)
mesa_format newDstFormat;
GLboolean k;
 
-   switch (dstFormat) {
-   case MESA_FORMAT_B8G8R8A8_SRGB:
-  newDstFormat = MESA_FORMAT_B8G8R8A8_UNORM;
-  break;
-   case MESA_FORMAT_B8G8R8X8_SRGB:
-  newDstFormat = MESA_FORMAT_B8G8R8X8_UNORM;
-  break;
-   default:
-  ASSERT(0);
-  return GL_FALSE;
-   }
+   assert(dstFormat == MESA_FORMAT_B8G8R8A8_SRGB ||
+  dstFormat == MESA_FORMAT_B8G8R8X8_SRGB);
+
+   newDstFormat = _mesa_get_srgb_format_linear(dstFormat);
 
k = _mesa_texstore_argb(ctx, dims, baseInternalFormat,
newDstFormat,
-- 
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 3/7] linker: Fold set_uniform_binding into call site

[Kenneth Graunke]

On 04/10/2014 11:42 AM, Ian Romanick wrote:
> On 04/09/2014 08:02 AM, Kenneth Graunke wrote:
>> On 04/04/2014 02:01 PM, Ian Romanick wrote:
>>> From: Ian Romanick 
>>>
>>> In the next patch, we'll see that using
>>> gl_shader_program::UniformStorage is not correct for uniform blocks.
>>> That means we can't use ::UniformStorage to select between the sampler
>>> path and the block path.  Instead we want to just use the type of the
>>> variable.  That's never passed to set_uniform_binding, and it's easier
>>
>> Ehhhmm.then
> 
> "That" in this instance the variable, not the variable's type.  I'll
> update the commit message.  More reply below.
> 
>>> to just remove the function (especially for later patches in the series)
>>> than to add another parameter.
>>>
>>> Signed-off-by: Ian Romanick 
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
>>> Cc: "10.1" 
>>> Cc: git...@socker.lepus.uberspace.de
>>> ---
>>>  src/glsl/link_uniform_initializers.cpp | 33 
>>> -
>>>  1 file changed, 12 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/src/glsl/link_uniform_initializers.cpp 
>>> b/src/glsl/link_uniform_initializers.cpp
>>> index 6f15e69..bbdeec9 100644
>>> --- a/src/glsl/link_uniform_initializers.cpp
>>> +++ b/src/glsl/link_uniform_initializers.cpp
>>> @@ -151,25 +151,6 @@ set_block_binding(void *mem_ctx, gl_shader_program 
>>> *prog,
>>>  }
>>>  
>>>  void
>>> -set_uniform_binding(void *mem_ctx, gl_shader_program *prog,
>>> -const char *name, const glsl_type *type, int binding)
>>
>> ...what exactly is this? ^
>>
>>> -{
>>> -   struct gl_uniform_storage *const storage =
>>> -  get_storage(prog->UniformStorage, prog->NumUserUniformStorage, name);
>>> -
>>> -   if (storage == NULL) {
>>> -  assert(storage != NULL);
>>> -  return;
>>> -   }
>>> -
>>> -   if (storage->type->is_sampler()) {
>>> -  set_sampler_binding(mem_ctx, prog, name, type, binding);
>>> -   } else if (storage->block_index != -1) {
>>> -  set_block_binding(mem_ctx, prog, name, type, binding);
>>> -   }
>>> -}
>>> -
>>> -void
>>>  set_uniform_initializer(void *mem_ctx, gl_shader_program *prog,
>>> const char *name, const glsl_type *type,
>>> ir_constant *val)
>>> @@ -268,8 +249,18 @@ link_set_uniform_initializers(struct gl_shader_program 
>>> *prog)
>>> mem_ctx = ralloc_context(NULL);
>>>  
>>>   if (var->data.explicit_binding) {
>>> -linker::set_uniform_binding(mem_ctx, prog, var->name,
>>> -var->type, var->data.binding);
>>> +const glsl_type *const type = var->type;
>>
>> Here you're using type, which is var->type, which is exactly what we
>> were already passing.
>>
>> AFAICT all you needed to do was change:
>>
>>if (storage->type->is_sampler())
>>
>> to
>>
>> if (type->is_sampler() || (type->is_array() &&
>> type->fields.array->is_sampler()))
>>
>> in set_uniform_binding.
> 
> That would resolve this issue, but patch 5 needs the interface type and
> not the variable's type.  The only way to get the interface type is from
> the variable.  Splitting it out here, then passing the interface type
> instead of the variable's type in a later patch resulted in what I
> believed to be better code.
> 
> Sound reasonable?

Definitely.  Sorry I wasn't clear - although I thought these changes
were unnecessary, I wasn't opposed to them.  They seem worth doing
regardless.

I believe you have my R-b for the whole series.

Thanks Ian!



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

Re: [Mesa-dev] [PATCH] i965: Fill in a bunch of gen7/hsw data cache-related disasm.

[Matt Turner]

On Mon, Mar 31, 2014 at 1:48 PM, Eric Anholt  wrote:
> This gets us disasm of atomic ops.
> ---
>  src/mesa/drivers/dri/i965/brw_disasm.c | 113 
> +++--
>  1 file changed, 106 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c 
> b/src/mesa/drivers/dri/i965/brw_disasm.c
> index 8cd8a40..5222d53 100644
> --- a/src/mesa/drivers/dri/i965/brw_disasm.c
> +++ b/src/mesa/drivers/dri/i965/brw_disasm.c
> @@ -309,7 +309,8 @@ static const char * const target_function[16] = {
>  [BRW_SFID_DATAPORT_READ] = "read",
>  [BRW_SFID_DATAPORT_WRITE] = "write",
>  [BRW_SFID_URB] = "urb",
> -[BRW_SFID_THREAD_SPAWNER] = "thread_spawner"
> +[BRW_SFID_THREAD_SPAWNER] = "thread_spawner",
> +[BRW_SFID_VME] = "vme",
>  };
>
>  static const char * const target_function_gen6[16] = {
> @@ -322,7 +323,10 @@ static const char * const target_function_gen6[16] = {
>  [GEN6_SFID_DATAPORT_SAMPLER_CACHE] = "sampler",
>  [GEN6_SFID_DATAPORT_RENDER_CACHE] = "render",
>  [GEN6_SFID_DATAPORT_CONSTANT_CACHE] = "const",
> -[GEN7_SFID_DATAPORT_DATA_CACHE] = "data"
> +[GEN7_SFID_DATAPORT_DATA_CACHE] = "data",
> +[GEN7_SFID_PIXEL_INTERPOLATOR] = "pixel interp",
> +[HSW_SFID_DATAPORT_DATA_CACHE_1] = "dp data 1",
> +[HSW_SFID_CRE] = "cre",
>  };
>
>  static const char * const dp_rc_msg_type_gen6[16] = {
> @@ -342,6 +346,54 @@ static const char * const dp_rc_msg_type_gen6[16] = {
>  [GEN6_DATAPORT_WRITE_MESSAGE_RENDER_TARGET_UNORM_WRITE] = "RT UNORMc 
> write",
>  };
>
> +static const char *const dp_dc0_msg_type_gen7[16] = {
> +[GEN7_DATAPORT_DC_OWORD_BLOCK_READ] = "DC OWORD block read",
> +[GEN7_DATAPORT_DC_UNALIGNED_OWORD_BLOCK_READ] = "DC unaligned OWORD 
> block read",
> +[GEN7_DATAPORT_DC_OWORD_DUAL_BLOCK_READ] = "DC OWORD dual block read",
> +[GEN7_DATAPORT_DC_DWORD_SCATTERED_READ] = "DC DWORD scattered read",
> +[GEN7_DATAPORT_DC_BYTE_SCATTERED_READ] = "DC byte scattered read",
> +[GEN7_DATAPORT_DC_UNTYPED_ATOMIC_OP] = "DC untyped atomic",
> +[GEN7_DATAPORT_DC_MEMORY_FENCE] = "DC mfence",
> +[GEN7_DATAPORT_DC_OWORD_BLOCK_WRITE] = "DC OWORD block write",
> +[GEN7_DATAPORT_DC_OWORD_DUAL_BLOCK_WRITE] = "DC OWORD dual block write",
> +[GEN7_DATAPORT_DC_DWORD_SCATTERED_WRITE] = "DC DWORD scatterd write",
> +[GEN7_DATAPORT_DC_BYTE_SCATTERED_WRITE] = "DC byte scattered write",
> +[GEN7_DATAPORT_DC_UNTYPED_SURFACE_WRITE] = "DC untyped surface write",
> +};
> +
> +static const char *const dp_dc1_msg_type_hsw[16] = {
> +[HSW_DATAPORT_DC_PORT1_UNTYPED_SURFACE_READ] = "untyped surface read",
> +[HSW_DATAPORT_DC_PORT1_UNTYPED_ATOMIC_OP] = "DC untyped atomic op",
> +[HSW_DATAPORT_DC_PORT1_UNTYPED_ATOMIC_OP_SIMD4X2] = "DC untyped 4x2 
> atomic op",
> +[HSW_DATAPORT_DC_PORT1_MEDIA_BLOCK_READ] = "DC media block read",
> +[HSW_DATAPORT_DC_PORT1_TYPED_SURFACE_READ] = "DC typed surface read",
> +[HSW_DATAPORT_DC_PORT1_TYPED_ATOMIC_OP] = "DC typed atomic",
> +[HSW_DATAPORT_DC_PORT1_TYPED_ATOMIC_OP_SIMD4X2] = "DC typed 4x2 atomic 
> op",
> +[HSW_DATAPORT_DC_PORT1_UNTYPED_SURFACE_WRITE] = "DC untyped surface 
> write",
> +[HSW_DATAPORT_DC_PORT1_MEDIA_BLOCK_WRITE] = "DC media block write",
> +[HSW_DATAPORT_DC_PORT1_ATOMIC_COUNTER_OP] = "DC atomic counter op",
> +[HSW_DATAPORT_DC_PORT1_ATOMIC_COUNTER_OP_SIMD4X2] = "DC 4x2 atomic 
> counter op",
> +[HSW_DATAPORT_DC_PORT1_TYPED_SURFACE_WRITE] = "DC typed surface write",
> +};
> +
> +static const char * const aop[16] = {
> +   [BRW_AOP_AND] = "and",
> +   [BRW_AOP_OR] = "or",
> +   [BRW_AOP_XOR] = "xoo",
> +   [BRW_AOP_MOV] = "mov",
> +   [BRW_AOP_INC] = "inc",
> +   [BRW_AOP_DEC] = "dec",
> +   [BRW_AOP_ADD] = "add",
> +   [BRW_AOP_SUB] = "sub",
> +   [BRW_AOP_REVSUB] = "revsub",
> +   [BRW_AOP_IMAX] = "imax",
> +   [BRW_AOP_IMIN] = "imin",
> +   [BRW_AOP_UMAX] = "umax",
> +   [BRW_AOP_UMIN] = "umin",
> +   [BRW_AOP_CMPWR] = "cmpwr",
> +   [BRW_AOP_PREDEC] = "predec",
> +};
> +
>  static const char * const math_function[16] = {
>  [BRW_MATH_FUNCTION_INV] = "inv",
>  [BRW_MATH_FUNCTION_LOG] = "log",
> @@ -1312,12 +1364,59 @@ int brw_disasm (FILE *file, struct brw_instruction 
> *inst, int gen)
> case BRW_SFID_THREAD_SPAWNER:
> break;
> case GEN7_SFID_DATAPORT_DATA_CACHE:
> -   format (file, " (%d, %d, %d)",
> -   inst->bits3.gen7_dp.binding_table_index,
> -   inst->bits3.gen7_dp.msg_control,
> -   inst->bits3.gen7_dp.msg_type);
> -   break;
> +   if (gen >= 7) {
> +  format (file, " (");
> +
> +  err |= control (file, "DP DC0 message type",
> +  dp_dc0_msg_type_gen7,
> +  inst->bits3.gen7_dp.msg_type, &space);
> +
> +  format (file, ", %d, ", 
> inst->bits3.gen7_dp.binding_table_index);
> +
> +  switch 

[Mesa-dev] [Bug 77288] New: [swrast] piglit glean glsl1 regression

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 77288
  Keywords: have-backtrace, regression
CC: e...@anholt.net, kenn...@whitecape.org
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [swrast] piglit glean glsl1 regression
  Severity: critical
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Mesa core
   Product: Mesa

mesa: 8291f6d5c5db2dba6bd9a8d94a5e269a90d255eb (master 10.2.0-devel)

piglit glean glsl1 now crashes.

$ ./bin/glean -t glsl1 --quick
FAILURE:
  Shader test: function prototype
  Expected color: 0.25, 0.25, 0.25, 0.25
  Observed color: 0.25098, 0.25098, 0.25098, 0
glean: program/ir_to_mesa.cpp:1800: virtual void
{anonymous}::ir_to_mesa_visitor::visit(ir_assignment*): Assertion
`ir->lhs->type->is_vector()' failed.
Aborted (core dumped)

(gdb) bt
#0  0x7fc9e02baf77 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x7fc9e02be5e8 in __GI_abort () at abort.c:90
#2  0x7fc9e02b3d43 in __assert_fail_base (fmt=0x7fc9e040af58 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", 
assertion=assertion@entry=0x7fc9dd4633db "ir->lhs->type->is_vector()", 
file=file@entry=0x7fc9dd462d6c "program/ir_to_mesa.cpp",
line=line@entry=1800, 
function=function@entry=0x7fc9dd464060 <(anonymous
namespace)::ir_to_mesa_visitor::visit(ir_assignment*)::__PRETTY_FUNCTION__>
"virtual void {anonymous}::ir_to_mesa_visitor::visit(ir_assignment*)") at
assert.c:92
#3  0x7fc9e02b3df2 in __GI___assert_fail (assertion=0x7fc9dd4633db
"ir->lhs->type->is_vector()", 
file=0x7fc9dd462d6c "program/ir_to_mesa.cpp", line=1800, 
function=0x7fc9dd464060 <(anonymous
namespace)::ir_to_mesa_visitor::visit(ir_assignment*)::__PRETTY_FUNCTION__>
"virtual void {anonymous}::ir_to_mesa_visitor::visit(ir_assignment*)") at
assert.c:101
#4  0x7fc9dd31f6b8 in (anonymous namespace)::ir_to_mesa_visitor::visit
(this=0x7fffd40ddf50, ir=0x19a9f00)
at program/ir_to_mesa.cpp:1800
#5  0x7fc9dd3d7698 in ir_assignment::accept (this=0x19a9f00,
v=0x7fffd40ddf50) at ../../src/glsl/ir.h:1060
#6  0x7fc9dd31b63c in (anonymous namespace)::ir_to_mesa_visitor::visit
(this=0x7fffd40ddf50, ir=0x1c5dec0)
at program/ir_to_mesa.cpp:807
#7  0x7fc9dd3d75e8 in ir_function::accept (this=0x1c5dec0,
v=0x7fffd40ddf50) at ../../src/glsl/ir.h:927
#8  0x7fc9dd3d4713 in visit_exec_list (list=0x1643860,
visitor=0x7fffd40ddf50) at ../../src/glsl/ir.cpp:1734
#9  0x7fc9dd322e75 in get_mesa_program (ctx=0x7fc9e1bdc010,
shader_program=0x19ab0e0, shader=0x162e120)
at program/ir_to_mesa.cpp:2823
#10 0x7fc9dd323a93 in _mesa_ir_link_shader (ctx=0x7fc9e1bdc010,
prog=0x19ab0e0) at program/ir_to_mesa.cpp:3050
#11 0x7fc9dd323c21 in _mesa_glsl_link_shader (ctx=0x7fc9e1bdc010,
prog=0x19ab0e0) at program/ir_to_mesa.cpp:3093
#12 0x7fc9dd1bf44c in link_program (ctx=0x7fc9e1bdc010, program=329) at
main/shaderapi.c:918
#13 0x7fc9dd1c05cd in _mesa_LinkProgram (programObj=329) at
main/shaderapi.c:1386
#14 0x004948ed in GLEAN::GLSLTest::testProgram (this=0x732d80
, p=...)
at piglit/tests/glean/tglsl1.cpp:4460
#15 0x004954ea in GLEAN::GLSLTest::runOne (this=0x732d80
, r=..., w=...)
at piglit/tests/glean/tglsl1.cpp:4672
#16 0x00476c43 in GLEAN::BaseTest::run
(this=0x732d80 , environment=...)
at piglit/tests/glean/tbase.h:331
#17 0x0046f4cf in main (argc=4, argv=0x7fffd40de978) at
piglit/tests/glean/main.cpp:125
(gdb) frame 4
#4  0x7fc9dd31f6b8 in (anonymous namespace)::ir_to_mesa_visitor::visit
(this=0x7fffd40ddf50, ir=0x19a9f00)
at program/ir_to_mesa.cpp:1800
1800  assert(ir->lhs->type->is_vector());
(gdb) print ir->lhs->type->vector_elements
$1 = 4
(gdb) print ir->lhs->type->matrix_columns
$2 = 4
(gdb) print ir->lhs->type->base_type
$3 = GLSL_TYPE_FLOAT

e9822f77a9cc024f528d30382fd5ad21c73a173b is the first bad commit
commit e9822f77a9cc024f528d30382fd5ad21c73a173b
Author: Eric Anholt 
Date:   Wed Mar 5 17:05:54 2014 -0800

glsl: Skip making a temporary for assignments when we don't need one.

While we wish our optimization passes could identify all the cases where
we can coalesce our variables, we miss out on a lot of opportunities.

total instructions in shared programs: 1673849 -> 1673166 (-0.04%)
instructions in affected programs: 299521 -> 298838 (-0.23%)
GAINED:7
LOST:  0

Note that many programs are "hurt".  The notable ones are where we produce
unrolling in cases we didn't before (presumably just because of the lower
instruction count).  But there are also some cases where pushing things
right into the variables prevents copy propagation and tree grafting,

Re: [Mesa-dev] [PATCH 1/7] linker: Split set_uniform_binding into separate functions for blocks and samplers

[Ian Romanick]

On 04/10/2014 12:04 PM, Ian Romanick wrote:
> On 04/09/2014 09:10 AM, Kenneth Graunke wrote:
>> On 04/04/2014 02:01 PM, Ian Romanick wrote:
>>> From: Ian Romanick 
>>>
>>> The two code paths are quite different, and there are some problems in
>>> the handling of uniform blocks.  Future changes will cause these paths
>>> to diverge further.  Ultimately, selecting between the two functions
>>> will happen at the set_uniform_binding call site, and
>>> set_uniform_binding will be deleted.
>>>
>>> NOTE: This patch just moves code around.
>>>
>>> Signed-off-by: Ian Romanick 
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
>>> Cc: "10.1" 
>>> Cc: git...@socker.lepus.uberspace.de
>>> ---
>>>  src/glsl/link_uniform_initializers.cpp | 42 
>>> +++---
>>>  1 file changed, 39 insertions(+), 3 deletions(-)
>>
>> Assuming you have a reasonable response to my comment on patch 5, this
>> series is:
>>
>> Reviewed-by: Kenneth Graunke 
>>
>> though, I'm not sure how much that's worth - I had to re-read the GLSL
>> rules and re-discover how our compiler IR for this stuff works.  The
>> code seems right, but I could be totally missing something obvious.
>>
>> On that note...is it just me, or is the compiler IR for uniform blocks
>> rather ugly and messy?
> 
> Yes.  Part of the problem is that we implemented things one "easy" way
> for GL_ARB_uniform_buffer_objects / OpenGL 3.1, but the addition of 3.2
> and OpenGL ES 3.0 features made the easy implementation not work.
> Rather that completely gut everything, I refactored a bunch of stuff
> and, basically, added a parallel implementation for the new bits.

A possible method of rectifying all of this just occured to me.  The
original problem was uniform blocks without an instance name put their
field names in global scope.  Applications do things like:

uniform U { vec4 v; };

void main()
{
gl_Position = v;
}

We handle this by putting a 'vec4 v' variable at global scope.  This
variable contains additional information so that the uniform block
information can be found.

Blocks with instance names operate differently.

uniform U { vec4 v; } u;

void main()
{
gl_Position = u.v;
}

In this case we put a 'U u' variable at global scope, and the u.v
dereference acts like a structure dereference.

What if we implemented something like the "using" keyword, and treat the
first case as if it were:

uniform U { vec4 v; } __U;

using __U;

void main()
{
gl_Position = v;
}

If a varible look-up fails, try each of the UBOs specified by using.  In
the IR, replace the dereference of v with __U.v.  When a new block is
added with using, there would need to be a check that none of its fields
conflict with globals or other blocks named with using.  Hmm... we'd
also have to check later globals for conflicts with using blocks.

I think that would solve a lot of the madness in the compiler and
linker.  There would still be some nonsense, IIRC, in the API side.  I
seem to recall that the API names vary depending on instance-name versus
non-instance-name.  That might actually be based on whether or not it's
a block array.  Hmm...

There's a couple possible warts, but it /seems/ like it may be cleaner
overall.  It should also localize the differences between the kinds of
blocks to the front end.

Thoughts?

>> Anyway, thanks a ton for doing this, Ian.  Sorry for dropping the ball
>> when we first implemented 420pack.
>>
>>> diff --git a/src/glsl/link_uniform_initializers.cpp 
>>> b/src/glsl/link_uniform_initializers.cpp
>>> index 9d6977d..9a10350 100644
>>> --- a/src/glsl/link_uniform_initializers.cpp
>>> +++ b/src/glsl/link_uniform_initializers.cpp
>>> @@ -84,7 +84,7 @@ copy_constant_to_storage(union gl_constant_value *storage,
>>>  }
>>>  
>>>  void
>>> -set_uniform_binding(void *mem_ctx, gl_shader_program *prog,
>>> +set_sampler_binding(void *mem_ctx, gl_shader_program *prog,
>>>  const char *name, const glsl_type *type, int binding)
>>>  {
>>> struct gl_uniform_storage *const storage =
>>> @@ -95,7 +95,7 @@ set_uniform_binding(void *mem_ctx, gl_shader_program 
>>> *prog,
>>>return;
>>> }
>>>  
>>> -   if (storage->type->is_sampler()) {
>>> +   {
>>>unsigned elements = MAX2(storage->array_elements, 1);
>>>  
>>>/* From section 4.4.4 of the GLSL 4.20 specification:
>>> @@ -118,7 +118,24 @@ set_uniform_binding(void *mem_ctx, gl_shader_program 
>>> *prog,
>>>  }
>>>   }
>>>}
>>> -   } else if (storage->block_index != -1) {
>>> +   }
>>> +
>>> +   storage->initialized = true;
>>> +}
>>> +
>>> +void
>>> +set_block_binding(void *mem_ctx, gl_shader_program *prog,
>>> +  const char *name, const glsl_type *type, int binding)
>>> +{
>>> +   struct gl_uniform_storage *const storage =
>>> +  get_storage(prog->UniformStorage, prog->NumUserUniformStorage, name);
>>> +
>>> +   if (storage == NULL) {

[Mesa-dev] [Bug 77286] Missing GLES 1.x symbols

[bugzilla-daemon]

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

Dylan  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org
   |org |

-- 
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 77286] Missing GLES 1.x symbols

[bugzilla-daemon]

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

Dylan  changed:

   What|Removed |Added

 CC||baker.dyla...@gmail.com,
   ||jljus...@gmail.com

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

[Mesa-dev] [Bug 77286] New: Missing GLES 1.x symbols

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 77286
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: Missing GLES 1.x symbols
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: baker.dyla...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Mesa core
   Product: Mesa

Piglit now fails to build against Mesa/i965 with gles1 tests enabled with a
linker error complaining about missing symbols:

/piglit/tests/spec/ext_image_dma_buf_import/intel_external_sampler_only.c:89:
undefined reference to `glDeleteRenderbuffersOES'

-- 
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] i965: fix MakeCurrent when switching a context between multiple drawables.

[Ian Romanick]

On 04/10/2014 03:39 AM, Iago Toral wrote:
> On Thu, 2014-04-10 at 10:31 +0200, Iago Toral wrote:
>> Hi Kristian,
>>
>> On Tue, 2014-04-08 at 10:14 -0700, Kristian Høgsberg wrote:
>>> On Mon, Apr 7, 2014 at 9:24 AM, Eric Anholt  wrote:
 Iago Toral Quiroga  writes:

> Commit 11baad35088dfd4bdabc1710df650dbfb413e7a3 produces a regression when
> switching a single context between multiple drawables.
>
> The problem is that we check whether we have a viewport set to decide if 
> we
> need to generate buffers for the drawble, but the viewport is initialized
> with the first call to MakeCurrent for that context, so calling 
> MakeCurrent on
> the same context with a different drawable will have the viewport already
> initialized and will not generate buffers for the new drawable.
>
> This patch fixes the problem by reverting to the previous solution 
> implemented
> in commit 05da4a7a5e7d5bd988cb31f94ed8e1f053d9ee39 with a small fix to 
> suppport
> single buffer drawables too. This solution checks if we have a 
> renderbuffer for
> the drawable to decide if we need to generate a buffer or not. The 
> original
> implementation, however, did this by checking the BACK_LEFT buffer, which 
> is
> not a valid solution for single buffer drawables. This patch modifies this
> to check the FRONT_LEFT buffer instead, which should work in both 
> scenarios.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74005
> ---
>  src/mesa/drivers/dri/i965/brw_context.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index c9719f5..c593286 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -926,6 +926,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
>  {
> struct brw_context *brw;
> GET_CURRENT_CONTEXT(curCtx);
> +   struct intel_renderbuffer *rb = NULL;
>
> if (driContextPriv)
>brw = (struct brw_context *) driContextPriv->driverPrivate;
> @@ -950,6 +951,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
>} else {
>   fb = driDrawPriv->driverPrivate;
>   readFb = driReadPriv->driverPrivate;
> + rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
>   driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1;
>   driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1;
>}
> @@ -961,10 +963,9 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
>intel_gles3_srgb_workaround(brw, fb);
>intel_gles3_srgb_workaround(brw, readFb);
>
> -  /* If the context viewport hasn't been initialized, force a call 
> out to
> -   * the loader to get buffers so we have a drawable size for the 
> initial
> -   * viewport. */
> -  if (!brw->ctx.ViewportInitialized)
> +  /* If we don't have buffers for the drawable yet, force a call to
> +   * getbuffers here so we can have a default drawable size. */
> +  if (rb && !rb->mt)
>   intel_prepare_render(brw);

 We won't have an rb->mt for the front unless you're doing front buffer
 rendering, so I think you're basically just backing out krh's change.
 Which I think is good -- it looks like he was papering over a bug
 elsewhere, and I think we *should* just prepare_render in makecurrent.
 But if we're going to revert, let's just actually revert.
>>>
>>> Here's what I wrote in https://bugs.freedesktop.org/show_bug.cgi?id=74005:
>>> We don't want to revert the behaviour.  The initial patch removed a
>>> call to intel_prepare_render() in intelMakeCurrent().  We're supposed
>>> to call intel_prepare_render() any time we're about to touch the
>>> buffers, but the up-front call to intel_prepare_render() in
>>> intelMakeCurrent covered up a few places where we forgot.  The fix now
>>> isn't to put back the up-front intel_prepare_render() call but to add
>>> it in the rendering paths that are missing it.
>>
>> Thanks for explaining. I will try to find the place where we are missing
>> the intel_prepare_render() call in this particular bug.
> 
> Actually, as far as I can see, we are already calling
> intel_prepare_render() in the render path that is causing this problem,
> but it turns out that by the time we have the chance to do that it is
> already too late. I explain:
> 
> The test case is pretty much this:
> 
> glXMakeCurrent(dpy, win1, ctx);
> glClear(GL_COLOR_BUFFER_BIT);
> 
> glXMakeCurrent(dpy, win2, ctx);
> glClear(GL_COLOR_BUFFER_BIT);
> 
> If we don't generate buffers for the second drawable when we do the
> second make current then we have to do it at some point during
> glClear(). glClear() is implem

Re: [Mesa-dev] [PATCH] i965: Fix missing _NEW_SCISSOR in Broadwell SF_CLIP_VIEWPORT state.

[Eric Anholt]

Kenneth Graunke  writes:

> The _Xmin/_Xmax/_Ymin/_Ymax values need to be guarded by _NEW_SCISSOR.
>
> Fixes Piglit's scissor-many, and rendering in GNOME Shell.
> Hopefully fixes similar issues with Unity and ChromeOS.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75879
> Signed-off-by: Kenneth Graunke 
> Cc: Timo Aaltonen 
> Cc: James Ausmus 

Reviewed-by: Eric Anholt 


pgpxunx3P8OPe.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 1/7] linker: Split set_uniform_binding into separate functions for blocks and samplers

[Ian Romanick]

On 04/09/2014 09:10 AM, Kenneth Graunke wrote:
> On 04/04/2014 02:01 PM, Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> The two code paths are quite different, and there are some problems in
>> the handling of uniform blocks.  Future changes will cause these paths
>> to diverge further.  Ultimately, selecting between the two functions
>> will happen at the set_uniform_binding call site, and
>> set_uniform_binding will be deleted.
>>
>> NOTE: This patch just moves code around.
>>
>> Signed-off-by: Ian Romanick 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
>> Cc: "10.1" 
>> Cc: git...@socker.lepus.uberspace.de
>> ---
>>  src/glsl/link_uniform_initializers.cpp | 42 
>> +++---
>>  1 file changed, 39 insertions(+), 3 deletions(-)
> 
> Assuming you have a reasonable response to my comment on patch 5, this
> series is:
> 
> Reviewed-by: Kenneth Graunke 
> 
> though, I'm not sure how much that's worth - I had to re-read the GLSL
> rules and re-discover how our compiler IR for this stuff works.  The
> code seems right, but I could be totally missing something obvious.
> 
> On that note...is it just me, or is the compiler IR for uniform blocks
> rather ugly and messy?

Yes.  Part of the problem is that we implemented things one "easy" way
for GL_ARB_uniform_buffer_objects / OpenGL 3.1, but the addition of 3.2
and OpenGL ES 3.0 features made the easy implementation not work.
Rather that completely gut everything, I refactored a bunch of stuff
and, basically, added a parallel implementation for the new bits.

> Anyway, thanks a ton for doing this, Ian.  Sorry for dropping the ball
> when we first implemented 420pack.
> 
>> diff --git a/src/glsl/link_uniform_initializers.cpp 
>> b/src/glsl/link_uniform_initializers.cpp
>> index 9d6977d..9a10350 100644
>> --- a/src/glsl/link_uniform_initializers.cpp
>> +++ b/src/glsl/link_uniform_initializers.cpp
>> @@ -84,7 +84,7 @@ copy_constant_to_storage(union gl_constant_value *storage,
>>  }
>>  
>>  void
>> -set_uniform_binding(void *mem_ctx, gl_shader_program *prog,
>> +set_sampler_binding(void *mem_ctx, gl_shader_program *prog,
>>  const char *name, const glsl_type *type, int binding)
>>  {
>> struct gl_uniform_storage *const storage =
>> @@ -95,7 +95,7 @@ set_uniform_binding(void *mem_ctx, gl_shader_program *prog,
>>return;
>> }
>>  
>> -   if (storage->type->is_sampler()) {
>> +   {
>>unsigned elements = MAX2(storage->array_elements, 1);
>>  
>>/* From section 4.4.4 of the GLSL 4.20 specification:
>> @@ -118,7 +118,24 @@ set_uniform_binding(void *mem_ctx, gl_shader_program 
>> *prog,
>>  }
>>   }
>>}
>> -   } else if (storage->block_index != -1) {
>> +   }
>> +
>> +   storage->initialized = true;
>> +}
>> +
>> +void
>> +set_block_binding(void *mem_ctx, gl_shader_program *prog,
>> +  const char *name, const glsl_type *type, int binding)
>> +{
>> +   struct gl_uniform_storage *const storage =
>> +  get_storage(prog->UniformStorage, prog->NumUserUniformStorage, name);
>> +
>> +   if (storage == NULL) {
>> +  assert(storage != NULL);
>> +  return;
>> +   }
>> +
>> +   if (storage->block_index != -1) {
>>/* This is a field of a UBO.  val is the binding index. */
>>for (int i = 0; i < MESA_SHADER_STAGES; i++) {
>>   int stage_index = 
>> prog->UniformBlockStageIndex[i][storage->block_index];
>> @@ -134,6 +151,25 @@ set_uniform_binding(void *mem_ctx, gl_shader_program 
>> *prog,
>>  }
>>  
>>  void
>> +set_uniform_binding(void *mem_ctx, gl_shader_program *prog,
>> +const char *name, const glsl_type *type, int binding)
>> +{
>> +   struct gl_uniform_storage *const storage =
>> +  get_storage(prog->UniformStorage, prog->NumUserUniformStorage, name);
>> +
>> +   if (storage == NULL) {
>> +  assert(storage != NULL);
>> +  return;
>> +   }
>> +
>> +   if (storage->type->is_sampler()) {
>> +  set_sampler_binding(mem_ctx, prog, name, type, binding);
>> +   } else if (storage->block_index != -1) {
>> +  set_block_binding(mem_ctx, prog, name, type, binding);
>> +   }
>> +}
>> +
>> +void
>>  set_uniform_initializer(void *mem_ctx, gl_shader_program *prog,
>>  const char *name, const glsl_type *type,
>>  ir_constant *val)
>>




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

Re: [Mesa-dev] [PATCH 3/7] linker: Fold set_uniform_binding into call site

[Ian Romanick]

On 04/09/2014 08:02 AM, Kenneth Graunke wrote:
> On 04/04/2014 02:01 PM, Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> In the next patch, we'll see that using
>> gl_shader_program::UniformStorage is not correct for uniform blocks.
>> That means we can't use ::UniformStorage to select between the sampler
>> path and the block path.  Instead we want to just use the type of the
>> variable.  That's never passed to set_uniform_binding, and it's easier
> 
> Ehhhmm.then

"That" in this instance the variable, not the variable's type.  I'll
update the commit message.  More reply below.

>> to just remove the function (especially for later patches in the series)
>> than to add another parameter.
>>
>> Signed-off-by: Ian Romanick 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
>> Cc: "10.1" 
>> Cc: git...@socker.lepus.uberspace.de
>> ---
>>  src/glsl/link_uniform_initializers.cpp | 33 
>> -
>>  1 file changed, 12 insertions(+), 21 deletions(-)
>>
>> diff --git a/src/glsl/link_uniform_initializers.cpp 
>> b/src/glsl/link_uniform_initializers.cpp
>> index 6f15e69..bbdeec9 100644
>> --- a/src/glsl/link_uniform_initializers.cpp
>> +++ b/src/glsl/link_uniform_initializers.cpp
>> @@ -151,25 +151,6 @@ set_block_binding(void *mem_ctx, gl_shader_program 
>> *prog,
>>  }
>>  
>>  void
>> -set_uniform_binding(void *mem_ctx, gl_shader_program *prog,
>> -const char *name, const glsl_type *type, int binding)
> 
> ...what exactly is this? ^
> 
>> -{
>> -   struct gl_uniform_storage *const storage =
>> -  get_storage(prog->UniformStorage, prog->NumUserUniformStorage, name);
>> -
>> -   if (storage == NULL) {
>> -  assert(storage != NULL);
>> -  return;
>> -   }
>> -
>> -   if (storage->type->is_sampler()) {
>> -  set_sampler_binding(mem_ctx, prog, name, type, binding);
>> -   } else if (storage->block_index != -1) {
>> -  set_block_binding(mem_ctx, prog, name, type, binding);
>> -   }
>> -}
>> -
>> -void
>>  set_uniform_initializer(void *mem_ctx, gl_shader_program *prog,
>>  const char *name, const glsl_type *type,
>>  ir_constant *val)
>> @@ -268,8 +249,18 @@ link_set_uniform_initializers(struct gl_shader_program 
>> *prog)
>>  mem_ctx = ralloc_context(NULL);
>>  
>>   if (var->data.explicit_binding) {
>> -linker::set_uniform_binding(mem_ctx, prog, var->name,
>> -var->type, var->data.binding);
>> +const glsl_type *const type = var->type;
> 
> Here you're using type, which is var->type, which is exactly what we
> were already passing.
> 
> AFAICT all you needed to do was change:
> 
>if (storage->type->is_sampler())
> 
> to
> 
> if (type->is_sampler() || (type->is_array() &&
> type->fields.array->is_sampler()))
> 
> in set_uniform_binding.

That would resolve this issue, but patch 5 needs the interface type and
not the variable's type.  The only way to get the interface type is from
the variable.  Splitting it out here, then passing the interface type
instead of the variable's type in a later patch resulted in what I
believed to be better code.

Sound reasonable?

>> +
>> +if (type->is_sampler()
>> +|| (type->is_array() && type->fields.array->is_sampler())) {
>> +   linker::set_sampler_binding(mem_ctx, prog, var->name,
>> +   type, var->data.binding);
>> +} else if (var->is_in_uniform_block()) {
>> +   linker::set_block_binding(mem_ctx, prog, var->name,
>> + type, var->data.binding);
>> +} else {
>> +   assert(!"Explicit binding not on a sampler or UBO.");
>> +}
>>   } else if (var->constant_value) {
>>  linker::set_uniform_initializer(mem_ctx, prog, var->name,
>>  var->type, var->constant_value);
>>
> 
> 




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

Re: [Mesa-dev] [PATCH 5/7] linker: Set block bindings based on UniformBlocks rather than UniformStorage

[Ian Romanick]

On 04/09/2014 08:09 AM, Kenneth Graunke wrote:
> On 04/04/2014 02:01 PM, Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> For blocks, gl_shader_program::UniformStorage isn't very useful.  The
>> names stored there are the names of the elements of the block, so
>> finding blocks with an instance name is hard.  There is also only one
>> entry in ::UniformStorage for each element of a block array, and that is
>> a deal breaker.
>>
>> Using ::UniformBlocks is what _mesa_GetUniformBlockIndex does.  I
>> contemplated sharing code between set_block_binding and
>> _mesa_GetUniformBlockIndex, but building the stand-alone compiler and
>> the unit tests make this hard.  I plan to return to this effort shortly.
>>
>> Signed-off-by: Ian Romanick 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
>> Cc: "10.1" 
>> Cc: git...@socker.lepus.uberspace.de
>> ---
>>  src/glsl/link_uniform_initializers.cpp | 32 +---
>>  1 file changed, 21 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/glsl/link_uniform_initializers.cpp 
>> b/src/glsl/link_uniform_initializers.cpp
>> index c633850..491eb69 100644
>> --- a/src/glsl/link_uniform_initializers.cpp
>> +++ b/src/glsl/link_uniform_initializers.cpp
>> @@ -46,6 +46,18 @@ get_storage(gl_uniform_storage *storage, unsigned 
>> num_storage,
>> return NULL;
>>  }
>>  
>> +static unsigned
>> +get_uniform_block_index(const gl_shader_program *shProg,
>> +const char *uniformBlockName)
>> +{
>> +   for (unsigned i = 0; i < shProg->NumUniformBlocks; i++) {
>> +  if (!strcmp(shProg->UniformBlocks[i].Name, uniformBlockName))
>> + return i;
>> +   }
>> +
>> +   return GL_INVALID_INDEX;
>> +}
>> +
>>  void
>>  copy_constant_to_storage(union gl_constant_value *storage,
>>   const ir_constant *val,
>> @@ -123,29 +135,24 @@ set_sampler_binding(gl_shader_program *prog, const 
>> char *name, int binding)
>>  }
>>  
>>  void
>> -set_block_binding(gl_shader_program *prog, const char *name, int binding)
>> +set_block_binding(gl_shader_program *prog, const char *block_name, int 
>> binding)
>>  {
>> -   struct gl_uniform_storage *const storage =
>> -  get_storage(prog->UniformStorage, prog->NumUserUniformStorage, name);
>> +   const unsigned block_index = get_uniform_block_index(prog, block_name);
>>  
>> -   if (storage == NULL) {
>> -  assert(storage != NULL);
>> +   if (block_index == GL_INVALID_INDEX) {
>> +  assert(block_index != GL_INVALID_INDEX);
>>return;
>> }
>>  
>> -   if (storage->block_index != -1) {
>>/* This is a field of a UBO.  val is the binding index. */
>>for (int i = 0; i < MESA_SHADER_STAGES; i++) {
>> - int stage_index = 
>> prog->UniformBlockStageIndex[i][storage->block_index];
>> + int stage_index = prog->UniformBlockStageIndex[i][block_index];
>>  
>>   if (stage_index != -1) {
>>  struct gl_shader *sh = prog->_LinkedShaders[i];
>>  sh->UniformBlocks[stage_index].Binding = binding;
>>   }
>>}
>> -   }
>> -
>> -   storage->initialized = true;
> 
> Why is it not necessary to set storage->initialized = true?  It goes
> away here and never seems to come back.

The meaning of gl_uniform_storage::initialized is: Has this uniform ever
been given a value?  Setting the binding of a block doesn't give
anything a value, but it does for samplers.  I hadn't fully worked
through the logic when I wrote the patch, and I forgot to come back to
it to document it.

>>  }
>>  
>>  void
>> @@ -253,7 +260,10 @@ link_set_uniform_initializers(struct gl_shader_program 
>> *prog)
>>  || (type->is_array() && type->fields.array->is_sampler())) {
>> linker::set_sampler_binding(prog, var->name, 
>> var->data.binding);
>>  } else if (var->is_in_uniform_block()) {
>> -   linker::set_block_binding(prog, var->name, 
>> var->data.binding);
>> +   const glsl_type *const iface_type = 
>> var->get_interface_type();
>> +
>> +   linker::set_block_binding(prog, iface_type->name,
>> + var->data.binding);
>>  } else {
>> assert(!"Explicit binding not on a sampler or UBO.");
>>  }
>>




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

Re: [Mesa-dev] [PATCH 4/4] glxinfo: Remove the ARB suffixes from core enums

[Ian Romanick]

On 04/09/2014 06:51 PM, Fredrik Höglund wrote:
> The suffix is only removed from the printed names in case someone
> wants to build glxinfo against an old implementation.

Isn't that already impossible due to GL_MAX_VERTEX_OUTPUT_COMPONENTS?

To be honest... I'd like to see all of the '#ifdef extension_name' stuff
go away.  We can just put a build-time dependency on a recent enough
version of glext.h.  The version is available as a #define in glext.h.

> ---
>  src/xdemos/glxinfo.c | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/src/xdemos/glxinfo.c b/src/xdemos/glxinfo.c
> index f8a4e51..6e00dd3 100644
> --- a/src/xdemos/glxinfo.c
> +++ b/src/xdemos/glxinfo.c
> @@ -538,20 +538,20 @@ static void
>  print_shader_limits(GLenum target)
>  {
> static const struct token_name vertex_limits[] = {
> -  { GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB, 
> "GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB" },
> -  { GL_MAX_VARYING_FLOATS_ARB, "GL_MAX_VARYING_FLOATS_ARB" },
> -  { GL_MAX_VERTEX_ATTRIBS_ARB, "GL_MAX_VERTEX_ATTRIBS_ARB" },
> -  { GL_MAX_TEXTURE_IMAGE_UNITS_ARB, "GL_MAX_TEXTURE_IMAGE_UNITS_ARB" },
> -  { GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB, 
> "GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB" },
> -  { GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB, 
> "GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB" },
> -  { GL_MAX_TEXTURE_COORDS_ARB, "GL_MAX_TEXTURE_COORDS_ARB" },
> +  { GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB, 
> "GL_MAX_VERTEX_UNIFORM_COMPONENTS" },
> +  { GL_MAX_VARYING_FLOATS_ARB, "GL_MAX_VARYING_FLOATS" },
> +  { GL_MAX_VERTEX_ATTRIBS_ARB, "GL_MAX_VERTEX_ATTRIBS" },
> +  { GL_MAX_TEXTURE_IMAGE_UNITS_ARB, "GL_MAX_TEXTURE_IMAGE_UNITS" },
> +  { GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB, 
> "GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS" },
> +  { GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB, 
> "GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS" },
> +  { GL_MAX_TEXTURE_COORDS_ARB, "GL_MAX_TEXTURE_COORDS" },
>{ GL_MAX_VERTEX_OUTPUT_COMPONENTS  , "GL_MAX_VERTEX_OUTPUT_COMPONENTS  
> " },
>{ (GLenum) 0, NULL }
> };
> static const struct token_name fragment_limits[] = {
> -  { GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB, 
> "GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB" },
> -  { GL_MAX_TEXTURE_COORDS_ARB, "GL_MAX_TEXTURE_COORDS_ARB" },
> -  { GL_MAX_TEXTURE_IMAGE_UNITS_ARB, "GL_MAX_TEXTURE_IMAGE_UNITS_ARB" },
> +  { GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB, 
> "GL_MAX_FRAGMENT_UNIFORM_COMPONENTS" },
> +  { GL_MAX_TEXTURE_COORDS_ARB, "GL_MAX_TEXTURE_COORDS" },
> +  { GL_MAX_TEXTURE_IMAGE_UNITS_ARB, "GL_MAX_TEXTURE_IMAGE_UNITS" },
>{ GL_MAX_FRAGMENT_INPUT_COMPONENTS , "GL_MAX_FRAGMENT_INPUT_COMPONENTS 
> " },
>{ (GLenum) 0, NULL }
> };
> @@ -567,12 +567,12 @@ print_shader_limits(GLenum target)
>  
> switch (target) {
> case GL_VERTEX_SHADER:
> -  printf("GL_VERTEX_SHADER_ARB:\n");
> +  printf("GL_VERTEX_SHADER:\n");
>print_shader_limit_list(vertex_limits);
>break;
>  
> case GL_FRAGMENT_SHADER:
> -  printf("GL_FRAGMENT_SHADER_ARB:\n");
> +  printf("GL_FRAGMENT_SHADER:\n");
>print_shader_limit_list(fragment_limits);
>break;
>  
> @@ -637,22 +637,22 @@ print_limits(const char *extensions, const char 
> *oglstring)
>{ 2, GL_ALIASED_POINT_SIZE_RANGE, "GL_ALIASED_POINT_SIZE_RANGE", NULL 
> },
>{ 2, GL_SMOOTH_POINT_SIZE_RANGE, "GL_SMOOTH_POINT_SIZE_RANGE", NULL },
>  #if defined(GL_ARB_texture_cube_map)
> -  { 1, GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB, 
> "GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB", "GL_ARB_texture_cube_map" },
> +  { 1, GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB, "GL_MAX_CUBE_MAP_TEXTURE_SIZE", 
> "GL_ARB_texture_cube_map" },
>  #endif
>  #if defined(GL_NV_texture_rectangle)
> -  { 1, GL_MAX_RECTANGLE_TEXTURE_SIZE_NV, 
> "GL_MAX_RECTANGLE_TEXTURE_SIZE_NV", "GL_NV_texture_rectangle" },
> +  { 1, GL_MAX_RECTANGLE_TEXTURE_SIZE_NV, 
> "GL_MAX_RECTANGLE_TEXTURE_SIZE", "GL_NV_texture_rectangle" },
>  #endif
>  #if defined(GL_ARB_multitexture)
> -  { 1, GL_MAX_TEXTURE_UNITS_ARB, "GL_MAX_TEXTURE_UNITS_ARB", 
> "GL_ARB_multitexture" },
> +  { 1, GL_MAX_TEXTURE_UNITS_ARB, "GL_MAX_TEXTURE_UNITS", 
> "GL_ARB_multitexture" },
>  #endif
>  #if defined(GL_EXT_texture_lod_bias)
> -  { 1, GL_MAX_TEXTURE_LOD_BIAS_EXT, "GL_MAX_TEXTURE_LOD_BIAS_EXT", 
> "GL_EXT_texture_lod_bias" },
> +  { 1, GL_MAX_TEXTURE_LOD_BIAS_EXT, "GL_MAX_TEXTURE_LOD_BIAS", 
> "GL_EXT_texture_lod_bias" },
>  #endif
>  #if defined(GL_EXT_texture_filter_anisotropic)
>{ 1, GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT, 
> "GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT", "GL_EXT_texture_filter_anisotropic" },
>  #endif
>  #if defined(GL_ARB_draw_buffers)
> -  { 1, GL_MAX_DRAW_BUFFERS_ARB, "GL_MAX_DRAW_BUFFERS_ARB", 
> "GL_ARB_draw_buffers" },
> +  { 1, GL_MAX_DRAW_BUFFERS_ARB, "GL_MAX_DRAW_BUFFERS", 
> "GL_ARB_draw_buffers" },
>  #endif
>  #if defined(GL_AR

[Mesa-dev] [PATCH] i965: Fix missing _NEW_SCISSOR in Broadwell SF_CLIP_VIEWPORT state.

[Kenneth Graunke]

The _Xmin/_Xmax/_Ymin/_Ymax values need to be guarded by _NEW_SCISSOR.

Fixes Piglit's scissor-many, and rendering in GNOME Shell.
Hopefully fixes similar issues with Unity and ChromeOS.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75879
Signed-off-by: Kenneth Graunke 
Cc: Timo Aaltonen 
Cc: James Ausmus 
---
 src/mesa/drivers/dri/i965/gen8_viewport_state.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen8_viewport_state.c 
b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
index 344310e..b366246 100644
--- a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
@@ -86,7 +86,7 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
   vp[10] = -gby; /* y-min */
   vp[11] =  gby; /* y-max */
 
-  /* Screen Space Viewport */
+  /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space Viewport */
   if (render_to_fbo) {
  vp[12] = ctx->DrawBuffer->_Xmin;
  vp[13] = ctx->DrawBuffer->_Xmax - 1;
@@ -110,7 +110,7 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
 
 const struct brw_tracked_state gen8_sf_clip_viewport = {
.dirty = {
-  .mesa = _NEW_VIEWPORT | _NEW_BUFFERS,
+  .mesa = _NEW_BUFFERS | _NEW_SCISSOR | _NEW_VIEWPORT,
   .brw = BRW_NEW_BATCH,
   .cache = 0,
},
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] st/mesa: fix sampler_view REALLOC/FREE macro mix-up

[Jakob Bornecrantz]

On 10 Apr 2014 15:56, "Brian Paul"  wrote:
>
> On 04/10/2014 01:43 AM, Jakob Bornecrantz wrote:
>>
>> On Thu, Apr 10, 2014 at 3:26 AM, Brian Paul  wrote:
>>>
>>> We were using REALLOC() from u_memory.h but FREE() from imports.h.
>>> This mismatch caused us to trash the heap on Windows after we
>>> deleted a texture object.
>>>
>>> This fixes a regression from commit 6c59be7776e4d.
>>> ---
>>>   src/mesa/state_tracker/st_cb_texture.c |2 +-
>>>   src/mesa/state_tracker/st_texture.c|   12 
>>>   src/mesa/state_tracker/st_texture.h|3 +++
>>>   3 files changed, 16 insertions(+), 1 deletion(-)
>>
>>
>> Is this patch obsoleted by the FREE/MALLOC remove series?
>
>
> Not exactly.  If I try to use FREE(stObj->sampler_views) in
st_cb_texture.c I need to include "u_memory.h".  But then I get
preprocessor warnings about MALLOC_STRUCT() and CALLOC_STRUCT() being
redefined.  So then I need to insert some #undef MALLOC_STRUCT lines.
> It's just messy.

Ah fair enough.

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

[Mesa-dev] R600/OpenCL - kernel_param resource

[Dorrington, Albert]

I am having an issue with a memory leak in an OpenCL program I am testing.
In the program I call the same kernel repeatedly, for every pixel in an image. 
(Probably not the most efficient code, but it is a learning/testing thing.)

One thing in particular I have not yet been able to figure out, is what 
releases the reference counts for the shader->kernel_param resource created in 
evergreen_compute_upload_input().

Tracing through the calls:
evergreen_compute_upload_input()
evergreen_cs_set_constant_buffer()
r600_set_constant_buffer()

I can see that if r600_set_constant_buffer() is passed a null 
pipe_constant_buffer input, that it would reset the stat masks and make the 
call to pipe_resource_reference() with a NULL, to decrement the count.

But I don't see where that would happen.

I am thinking that perhaps there should be something to release the reference 
count for that buffer, either after the evergreen_launch_grid() call, or 
perhaps as the last thing within that call, after the compute_emit_cs() call.

Or, is this call happening somewhere else that I haven't found?

Thanks,
Al Dorrington
Software Engineer Sr
Lockheed Martin, Mission Systems and Training

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

Re: [Mesa-dev] [PATCH 1/4] glxinfo: Print XFB, TBO, and UBO limits

[Brian Paul]

On 04/09/2014 07:51 PM, Fredrik Höglund wrote:

---
  src/xdemos/glxinfo.c | 22 ++
  1 file changed, 22 insertions(+)



For the series:
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] st/mesa: fix sampler_view REALLOC/FREE macro mix-up

[Brian Paul]

On 04/10/2014 01:43 AM, Jakob Bornecrantz wrote:

On Thu, Apr 10, 2014 at 3:26 AM, Brian Paul  wrote:

We were using REALLOC() from u_memory.h but FREE() from imports.h.
This mismatch caused us to trash the heap on Windows after we
deleted a texture object.

This fixes a regression from commit 6c59be7776e4d.
---
  src/mesa/state_tracker/st_cb_texture.c |2 +-
  src/mesa/state_tracker/st_texture.c|   12 
  src/mesa/state_tracker/st_texture.h|3 +++
  3 files changed, 16 insertions(+), 1 deletion(-)


Is this patch obsoleted by the FREE/MALLOC remove series?


Not exactly.  If I try to use FREE(stObj->sampler_views) in 
st_cb_texture.c I need to include "u_memory.h".  But then I get 
preprocessor warnings about MALLOC_STRUCT() and CALLOC_STRUCT() being 
redefined.  So then I need to insert some #undef MALLOC_STRUCT lines.

It's just messy.

-Brian


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

Re: [Mesa-dev] [PATCH 0/8] Native GBM backends and map/unmap support

[Jammy Zhou]

2014-03-24 19:55 GMT+08:00 Ander Conselvan de Oliveira :

> On 03/17/2014 11:05 AM, Jammy Zhou wrote:
>
>> Hi Ander,
>>
>> Some comments inline.
>>
>> And I have some further thinking about current GBM support, which is
>> tied to specific implementation closely, although the GBM APIs are quite
>> independent from mesa. I have some idea below to make GBM a generic
>> solution. I'm not sure if anybody else in the community raised this
>> before. What's your opinion?
>>
>
> Even though the APIs are independent from mesa, they were designed with
> the idea that GBM would be bundled with an EGL implementation. The logic
> for allocating buffers for a gbm_surface is in the EGL platform by the
> design. If GBM were to be split, that API would have to be changed, but in
> a way that would still let the EGL platform to be in control of the buffer
> allocation for surfaces.


Shouldn't EGL related logic be handled by different GBM backends (i.e, DRI
backend and Gallium backend)? And the GBM main library can be decoupled
cleanly, although it should be used together with EGL. Besides, I think the
split is also beneficial for binary EGL/ES2.0 drivers, which are quite
popular on ARM platforms.


>
>
>  - Decouple the GBM main library as standard API from mesa, and a
>> separate repository can be maintained for this library, which defines
>> callbacks for backend to implement. It can be packaged separately from
>> mesa by distros.
>> - Build the DRI backend as a separate library (i.e, gbm_dri.so) just as
>> the gallium backend, and it should still be part of mesa.
>> - New native backend can be implemented (i.e, gbm_intel.so), and the GBM
>> backend can be specified in some configuration file (i.e, /etc/gbm.conf)
>> if several backends can be used.
>>
>
> Choosing the backend automatically would be better, but otherwise that
> would be a reasonable approach if a split were to be made.
>
>
>  2014-03-13 22:02 GMT+08:00 Ander Conselvan de Oliveira
>> mailto:conselv...@gmail.com>>:
>>
>>
>> From: Ander Conselvan de Oliveira
>> > >
>>
>>
>> Hi,
>>
>> This patch series implements an API for mapping an unapping GBM buffer
>> objects. The native intel backend was implemented so that the map and
>> unmap functionality wouldn't have to be implemented in the DRI image
>>
>>
>> Can you elaborate more about why the map/unmap functionality cannot be
>> implemented in the DRI image extension?
>>
>
> There is no technical limitation, but that functionality falls out of the
> scope of the extension, which is to allow the implementation of EGLimage
> and associated extensions and some level of buffer sharing. It has grown
> quite a bit lately and, IMHO, a bit out of control too.
>
>
>
>> extension. A new EGL platform is necessary, since platform_drm.c
>> assumes it is run on top of a gbm device with the dri backend.
>>
>>
>> The new gbm platform is quite similar as the existing drm platform, why
>> not improve the drm platform to satisfy the new requirements? For
>> example, some abstraction can be done to decouple gbm_dri backend
>> dependency.
>>
>
> My approach was to duplicate first. You're right that there are code we
> can share between them, but I rather try to find the proper abstraction
> later and leave this out of the way for now.
>
> Thanks,
> Ander
>
>
>  This new platform is written so that it could support other native
>> backends, not only intel.
>>
>> Comments are really welcome.
>>
>> Thanks,
>> Ander
>>
>> Ander Conselvan de Oliveira (8):
>>egl/drm: Rename dri2_egl_surface field gbm_surf to gbm_dri_surf
>>egl: Protect use of gbm_dri with ifdef HAVE_DRM_PLATFORM
>>gbm: Add a native intel backend
>>gbm_drm: Keep a reference to drm native objects
>>dri, i965: Add an extension for sharing the drm bufmgr
>>dri, i965: Add entry point for creating image from native handle
>>egl/dri: Add gbm platform
>>gbm: Add entry points for mapping and unmapping bos
>>
>> configure.ac   |
>> 7 +-
>>
>>   include/GL/internal/dri_interface.h   |  24 +-
>>   src/egl/drivers/dri2/Makefile.am  |   5 +
>>   src/egl/drivers/dri2/egl_dri2.c   |   8 +
>>   src/egl/drivers/dri2/egl_dri2.h   |  16 +-
>>   src/egl/drivers/dri2/platform_drm.c   |   6 +-
>>   src/egl/drivers/dri2/platform_gbm.c   | 486
>> ++
>>   src/egl/main/Makefile.am  |   5 +
>>   src/egl/main/egldisplay.c |   3 +-
>>   src/egl/main/egldisplay.h |   1 +
>>   src/gbm/Makefile.am   |  14 +-
>>   src/gbm/backends/dri/gbm_dri.c|   3 +
>>   src/gbm/backends/intel/gbm_intel.c| 270 +
>>   src/gbm/backends/intel/gbm_intel.h|  76 +
>>  

Re: [Mesa-dev] [PATCH] st/mesa: fix sampler_view REALLOC/FREE macro mix-up

[Jose Fonseca]

To prevent this to ocurr again in the future we should be probably using 
os_malloc/os_free and friends instead of the overloaded MALLOC/FREE/etc macros.

We should probably kill MALLOC/FREE completely.

Jose

- Original Message -
> We were using REALLOC() from u_memory.h but FREE() from imports.h.
> This mismatch caused us to trash the heap on Windows after we
> deleted a texture object.
> 
> This fixes a regression from commit 6c59be7776e4d.
> ---
>  src/mesa/state_tracker/st_cb_texture.c |2 +-
>  src/mesa/state_tracker/st_texture.c|   12 
>  src/mesa/state_tracker/st_texture.h|3 +++
>  3 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/state_tracker/st_cb_texture.c
> b/src/mesa/state_tracker/st_cb_texture.c
> index 353415b..304dc91 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -155,7 +155,7 @@ st_DeleteTextureObject(struct gl_context *ctx,
>  
> pipe_resource_reference(&stObj->pt, NULL);
> st_texture_release_all_sampler_views(stObj);
> -   FREE(stObj->sampler_views);
> +   st_texture_free_sampler_views(stObj);
> _mesa_delete_texture_object(ctx, texObj);
>  }
>  
> diff --git a/src/mesa/state_tracker/st_texture.c
> b/src/mesa/state_tracker/st_texture.c
> index 8d559df..cfa0605 100644
> --- a/src/mesa/state_tracker/st_texture.c
> +++ b/src/mesa/state_tracker/st_texture.c
> @@ -483,3 +483,15 @@ st_texture_release_all_sampler_views(struct
> st_texture_object *stObj)
> for (i = 0; i < stObj->num_sampler_views; ++i)
>pipe_sampler_view_reference(&stObj->sampler_views[i], NULL);
>  }
> +
> +
> +void
> +st_texture_free_sampler_views(struct st_texture_object *stObj)
> +{
> +   /* NOTE:
> +* We use FREE() here to match REALLOC() above.  Both come from
> +* u_memory.h, not imports.h.  If we mis-match MALLOC/FREE from
> +* those two headers we can trash the heap.
> +*/
> +   FREE(stObj->sampler_views);
> +}
> diff --git a/src/mesa/state_tracker/st_texture.h
> b/src/mesa/state_tracker/st_texture.h
> index 87de9f9..f2afaf1 100644
> --- a/src/mesa/state_tracker/st_texture.h
> +++ b/src/mesa/state_tracker/st_texture.h
> @@ -241,4 +241,7 @@ st_texture_release_sampler_view(struct st_context *st,
>  extern void
>  st_texture_release_all_sampler_views(struct st_texture_object *stObj);
>  
> +void
> +st_texture_free_sampler_views(struct st_texture_object *stObj);
> +
>  #endif
> --
> 1.7.10.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=1olO9xu3XgincgJXOzgMZ%2F%2FOJ20%2FdB2ex7mU8kHIAi0%3D%0A&s=31ccb1bdd6a7109d026f0078b2a4777af1982e91714c765af6f4ab57ebb6
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] i965: Add writes_accumulator flag

[Juha-Pekka Heikkilä]

On Thu, Apr 10, 2014 at 1:18 AM, Kenneth Graunke  wrote:
> On 04/09/2014 01:47 PM, Matt Turner wrote:
>> From: Juha-Pekka Heikkila 
>>
>> Our hardware has an "accumulator" register, which can be used to store
>> intermediate results across multiple instructions.  Many instructions
>> can implicitly write a value to the accumulator in addition to their
>> normal destination register.  This is enabled by the "AccWrEn" flag.
>>
>> This patch introduces a new flag, inst->writes_accumulator, which
>> allows us to express the AccWrEn notion in the IR.  It also creates a
>> n ALU2_ACC macro to easily define emitters for instructions that
>> implicitly write the accumulator.
>>
>> Previously, we only supported implicit accumulator writes from the
>> ADDC, SUBB, and MACH instructions.  We always enabled them on those
>> instructions, and left them disabled for other instructions.
>>
>> To take advantage of the MAC (multiply-accumulate) instruction, we
>> need to be able to set AccWrEn on other types of instructions.
>>
>> Reviewed-by: Matt Turner 
>> Signed-off-by: Juha-Pekka Heikkila 
>> ---
>> I split out is_accumulator() into a separate patch, and made some
>> fixes to the scheduling code. Let me know if these changes look good
>> to you, JP. (Patch formatted with -U15 as to see other sections of
>> the scheduling code during review)
>>
>>  src/mesa/drivers/dri/i965/brw_fs.cpp   | 26 ++
>>  src/mesa/drivers/dri/i965/brw_fs_generator.cpp |  7 +--
>>  .../drivers/dri/i965/brw_schedule_instructions.cpp | 58 
>> ++
>>  src/mesa/drivers/dri/i965/brw_shader.h |  1 +
>>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 15 ++
>>  src/mesa/drivers/dri/i965/brw_vec4_generator.cpp   |  7 +--
>>  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 17 +--
>>  7 files changed, 95 insertions(+), 36 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
>> b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> index e576545..0eece60 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> [snip]
>> @@ -2113,40 +2124,35 @@ fs_visitor::dead_code_eliminate()
>>
>>   for (int i = 0; i < inst->regs_written; i++) {
>>  int var = live_intervals->var_from_vgrf[inst->dst.reg];
>>  assert(live_intervals->end[var + inst->dst.reg_offset + i] >= 
>> pc);
>>  if (live_intervals->end[var + inst->dst.reg_offset + i] != pc) {
>> dead = false;
>> break;
>>  }
>>   }
>>
>>   if (dead) {
>>  /* Don't dead code eliminate instructions that write to the
>>   * accumulator as a side-effect. Instead just set the 
>> destination
>>   * to the null register to free it.
>>   */
>> -switch (inst->opcode) {
>> -case BRW_OPCODE_ADDC:
>> -case BRW_OPCODE_SUBB:
>> -case BRW_OPCODE_MACH:
>> +if (inst->writes_accumulator) {
>> inst->dst = fs_reg(retype(brw_null_reg(), inst->dst.type));
>> -   break;
>
> Pre-existing bug: we ought to set progress = true in this case.

I am still wondering if the content of "if (inst->writes_accumulator)
{}" should be removed totally? Instead of above one would in the code
lines which emit opcodes where inst->writes_accumulator will be set
true also set the destination to brw_null_reg() if needed. I'm not
super familiar yet with all possible opcodes but at least for MACH
this should go horribly wrong here because MACH writes different
results in accumulator than destination -- and MACH will always have
writes_accumulator set to true.

>
>> -default:
>> +} else {
>> inst->remove();
>> progress = true;
>> -   break;
>>  }
>>   }
>>}
>>
>>pc++;
>> }
>>
>> if (progress)
>>invalidate_live_intervals();
>>
>> return progress;
>>  }
>>
>>  struct dead_code_hash_key
>>  {
>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] i965: Add writes_accumulator flag

[Juha-Pekka Heikkilä]

Hi Matt,

the changed set looks good to me, I did side by side comparison on
what had changed but did not try to run it today. I realized
immediately when seeing your comment I had not understood to consider
the "WAR" vs. "RAW" comments in the scheduler. I was thinking when I
made the latest set the first patch had grown a bit big but did not go
braking it yet into pieces.

On Wed, Apr 9, 2014 at 11:58 PM, Matt Turner  wrote:
> On Fri, Apr 4, 2014 at 6:51 AM, Juha-Pekka Heikkila
>  wrote:
>> diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp 
>> b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
>> index a951459..92f82fd 100644
>> --- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
>> @@ -758,6 +758,7 @@ fs_instruction_scheduler::calculate_deps()
>> schedule_node *last_fixed_grf_write = NULL;
>> int reg_width = v->dispatch_width / 8;
>>
>> +   schedule_node *last_accumulator_write = NULL;
>> /* The last instruction always needs to still be the last
>>  * instruction.  Either it's flow control (IF, ELSE, ENDIF, DO,
>>  * WHILE) and scheduling other things after it would disturb the
>> @@ -822,6 +823,10 @@ fs_instruction_scheduler::calculate_deps()
>
> The line before this was
>   if (inst->reads_flag()) {
>>  add_dep(last_conditional_mod[inst->flag_subreg], n);
>>}
>>
>> +  if (inst->writes_accumulator || inst->dst.is_accumulator()) {
>> + add_dep(last_accumulator_write, n);
>> +  }
>
> But we're checking if we're writing the accumulator here, instead of reading 
> it.
>
> We're also not giving the scheduler any benefits from it's new
> knowledge of accumulator dependencies, because we're still calling
> add_barrier_deps() above when we don't recognize the destination. I
> hope you don't mind, but I split the is_accumulator() additions into a
> separate patch, fixed up the scheduler hunks and sent the revised
> patch. Let me know if it looks right to you.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] r600g/radeonsi: Use caching buffer manager for textures as well

[Grigori Goronzy]

On 10.04.2014 11:23, Michel Dänzer wrote:

From: Michel Dänzer 

---

This is just an RFC; if other developers approve of this approach, I can
make a more extensive patch removing the use_reusable_pool parameters.

The x11perf numbers below compare ShmGet/PutImage before and after this
change with glamor from keithp's glamor-server xserver branch on a Kaveri
APU. The change also reduces the total runtime of the gtkperf tests from
about 3.5s to about 3s.



I have done some similar experiments. I also see a noticeable speedup 
with glamor. AFAIR Marek had some objections because texture buffers can 
be quite large and too many and too big buffers might end up congesting 
the cache for a long time.


Maybe it makes sense to only use caching for texture BOs smaller than a 
certain threshold? I have such a change in my Mesa tree and it seems to 
work well. I cache all texture BOs <= 512KB.


Best regards
Grigori


1: x11perf-baseline.txt
2: x11perf-caching.txt

 1  2   Operation
   -   -
   9070.048500.0 (  5.35)   ShmPutImage 10x10 square
   5670.027700.0 (  4.89)   ShmPutImage 100x100 square
758.0 2350.0 (  3.10)   ShmPutImage 500x500 square
   3600.0 5360.0 (  1.49)   ShmGetImage 10x10 square
   2960.0 5720.0 (  1.93)   ShmGetImage 100x100 square
346.0 1140.0 (  3.29)   ShmGetImage 500x500 square

  src/gallium/drivers/radeon/r600_texture.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index e39b9ec..293eeaa 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -633,7 +633,7 @@ r600_texture_create_object(struct pipe_screen *screen,
/* Now create the backing buffer. */
if (!buf) {
if (!r600_init_resource(rscreen, resource, rtex->size,
-   rtex->surface.bo_alignment, FALSE)) {
+   rtex->surface.bo_alignment, TRUE)) {
FREE(rtex);
return NULL;
}



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

Re: [Mesa-dev] [PATCH 2/2] mesa/st: set min/max texture gather offset to driver-reported value

[Marek Olšák]

For the series: Reviewed-by: Marek Olšák 

Marek

On Thu, Apr 10, 2014 at 5:30 AM, Ilia Mirkin  wrote:
> It was always getting set to -8/7 unconditionally.  Use the
> driver-reported value instead.
>
> Signed-off-by: Ilia Mirkin 
> ---
>  src/mesa/state_tracker/st_extensions.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index 845d29c..673a855 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -275,6 +275,9 @@ void st_init_limits(struct st_context *st)
> c->MaxProgramTexelOffset = screen->get_param(screen, 
> PIPE_CAP_MAX_TEXEL_OFFSET);
>
> c->MaxProgramTextureGatherComponents = screen->get_param(screen, 
> PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS);
> +   c->MinProgramTextureGatherOffset = screen->get_param(screen, 
> PIPE_CAP_MIN_TEXTURE_GATHER_OFFSET);
> +   c->MaxProgramTextureGatherOffset = screen->get_param(screen, 
> PIPE_CAP_MAX_TEXTURE_GATHER_OFFSET);
> +
> c->UniformBooleanTrue = ~0;
>
> c->MaxTransformFeedbackBuffers =
> --
> 1.8.3.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] st/mesa: fix sampler_view REALLOC/FREE macro mix-up

[Christian König]

Am 10.04.2014 03:26, schrieb Brian Paul:

We were using REALLOC() from u_memory.h but FREE() from imports.h.
This mismatch caused us to trash the heap on Windows after we
deleted a texture object.

This fixes a regression from commit 6c59be7776e4d.


Reviewed-by: Christian König 


---
  src/mesa/state_tracker/st_cb_texture.c |2 +-
  src/mesa/state_tracker/st_texture.c|   12 
  src/mesa/state_tracker/st_texture.h|3 +++
  3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_cb_texture.c 
b/src/mesa/state_tracker/st_cb_texture.c
index 353415b..304dc91 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -155,7 +155,7 @@ st_DeleteTextureObject(struct gl_context *ctx,
  
 pipe_resource_reference(&stObj->pt, NULL);

 st_texture_release_all_sampler_views(stObj);
-   FREE(stObj->sampler_views);
+   st_texture_free_sampler_views(stObj);
 _mesa_delete_texture_object(ctx, texObj);
  }
  
diff --git a/src/mesa/state_tracker/st_texture.c b/src/mesa/state_tracker/st_texture.c

index 8d559df..cfa0605 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -483,3 +483,15 @@ st_texture_release_all_sampler_views(struct 
st_texture_object *stObj)
 for (i = 0; i < stObj->num_sampler_views; ++i)
pipe_sampler_view_reference(&stObj->sampler_views[i], NULL);
  }
+
+
+void
+st_texture_free_sampler_views(struct st_texture_object *stObj)
+{
+   /* NOTE:
+* We use FREE() here to match REALLOC() above.  Both come from
+* u_memory.h, not imports.h.  If we mis-match MALLOC/FREE from
+* those two headers we can trash the heap.
+*/
+   FREE(stObj->sampler_views);
+}
diff --git a/src/mesa/state_tracker/st_texture.h 
b/src/mesa/state_tracker/st_texture.h
index 87de9f9..f2afaf1 100644
--- a/src/mesa/state_tracker/st_texture.h
+++ b/src/mesa/state_tracker/st_texture.h
@@ -241,4 +241,7 @@ st_texture_release_sampler_view(struct st_context *st,
  extern void
  st_texture_release_all_sampler_views(struct st_texture_object *stObj);
  
+void

+st_texture_free_sampler_views(struct st_texture_object *stObj);
+
  #endif


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

Re: [Mesa-dev] [RFC] r600g/radeonsi: Use caching buffer manager for textures as well

[Marek Olšák]

Hi Michel,

I was thinking of doing this for transfers only, because Glamor does a
lot of transfers. What do you think?

Marek

On Thu, Apr 10, 2014 at 11:23 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> ---
>
> This is just an RFC; if other developers approve of this approach, I can
> make a more extensive patch removing the use_reusable_pool parameters.
>
> The x11perf numbers below compare ShmGet/PutImage before and after this
> change with glamor from keithp's glamor-server xserver branch on a Kaveri
> APU. The change also reduces the total runtime of the gtkperf tests from
> about 3.5s to about 3s.
>
> 1: x11perf-baseline.txt
> 2: x11perf-caching.txt
>
> 1  2   Operation
>    -   -
>   9070.048500.0 (  5.35)   ShmPutImage 10x10 square
>   5670.027700.0 (  4.89)   ShmPutImage 100x100 square
>758.0 2350.0 (  3.10)   ShmPutImage 500x500 square
>   3600.0 5360.0 (  1.49)   ShmGetImage 10x10 square
>   2960.0 5720.0 (  1.93)   ShmGetImage 100x100 square
>346.0 1140.0 (  3.29)   ShmGetImage 500x500 square
>
>  src/gallium/drivers/radeon/r600_texture.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_texture.c 
> b/src/gallium/drivers/radeon/r600_texture.c
> index e39b9ec..293eeaa 100644
> --- a/src/gallium/drivers/radeon/r600_texture.c
> +++ b/src/gallium/drivers/radeon/r600_texture.c
> @@ -633,7 +633,7 @@ r600_texture_create_object(struct pipe_screen *screen,
> /* Now create the backing buffer. */
> if (!buf) {
> if (!r600_init_resource(rscreen, resource, rtex->size,
> -   rtex->surface.bo_alignment, FALSE)) {
> +   rtex->surface.bo_alignment, TRUE)) {
> FREE(rtex);
> return NULL;
> }
> --
> 1.9.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: fix MakeCurrent when switching a context between multiple drawables.

[Iago Toral]

On Thu, 2014-04-10 at 10:31 +0200, Iago Toral wrote:
> Hi Kristian,
> 
> On Tue, 2014-04-08 at 10:14 -0700, Kristian Høgsberg wrote:
> > On Mon, Apr 7, 2014 at 9:24 AM, Eric Anholt  wrote:
> > > Iago Toral Quiroga  writes:
> > >
> > >> Commit 11baad35088dfd4bdabc1710df650dbfb413e7a3 produces a regression 
> > >> when
> > >> switching a single context between multiple drawables.
> > >>
> > >> The problem is that we check whether we have a viewport set to decide if 
> > >> we
> > >> need to generate buffers for the drawble, but the viewport is initialized
> > >> with the first call to MakeCurrent for that context, so calling 
> > >> MakeCurrent on
> > >> the same context with a different drawable will have the viewport already
> > >> initialized and will not generate buffers for the new drawable.
> > >>
> > >> This patch fixes the problem by reverting to the previous solution 
> > >> implemented
> > >> in commit 05da4a7a5e7d5bd988cb31f94ed8e1f053d9ee39 with a small fix to 
> > >> suppport
> > >> single buffer drawables too. This solution checks if we have a 
> > >> renderbuffer for
> > >> the drawable to decide if we need to generate a buffer or not. The 
> > >> original
> > >> implementation, however, did this by checking the BACK_LEFT buffer, 
> > >> which is
> > >> not a valid solution for single buffer drawables. This patch modifies 
> > >> this
> > >> to check the FRONT_LEFT buffer instead, which should work in both 
> > >> scenarios.
> > >>
> > >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74005
> > >> ---
> > >>  src/mesa/drivers/dri/i965/brw_context.c | 9 +
> > >>  1 file changed, 5 insertions(+), 4 deletions(-)
> > >>
> > >> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> > >> b/src/mesa/drivers/dri/i965/brw_context.c
> > >> index c9719f5..c593286 100644
> > >> --- a/src/mesa/drivers/dri/i965/brw_context.c
> > >> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> > >> @@ -926,6 +926,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> > >>  {
> > >> struct brw_context *brw;
> > >> GET_CURRENT_CONTEXT(curCtx);
> > >> +   struct intel_renderbuffer *rb = NULL;
> > >>
> > >> if (driContextPriv)
> > >>brw = (struct brw_context *) driContextPriv->driverPrivate;
> > >> @@ -950,6 +951,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> > >>} else {
> > >>   fb = driDrawPriv->driverPrivate;
> > >>   readFb = driReadPriv->driverPrivate;
> > >> + rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> > >>   driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1;
> > >>   driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1;
> > >>}
> > >> @@ -961,10 +963,9 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> > >>intel_gles3_srgb_workaround(brw, fb);
> > >>intel_gles3_srgb_workaround(brw, readFb);
> > >>
> > >> -  /* If the context viewport hasn't been initialized, force a call 
> > >> out to
> > >> -   * the loader to get buffers so we have a drawable size for the 
> > >> initial
> > >> -   * viewport. */
> > >> -  if (!brw->ctx.ViewportInitialized)
> > >> +  /* If we don't have buffers for the drawable yet, force a call to
> > >> +   * getbuffers here so we can have a default drawable size. */
> > >> +  if (rb && !rb->mt)
> > >>   intel_prepare_render(brw);
> > >
> > > We won't have an rb->mt for the front unless you're doing front buffer
> > > rendering, so I think you're basically just backing out krh's change.
> > > Which I think is good -- it looks like he was papering over a bug
> > > elsewhere, and I think we *should* just prepare_render in makecurrent.
> > > But if we're going to revert, let's just actually revert.
> > 
> > Here's what I wrote in https://bugs.freedesktop.org/show_bug.cgi?id=74005:
> > We don't want to revert the behaviour.  The initial patch removed a
> > call to intel_prepare_render() in intelMakeCurrent().  We're supposed
> > to call intel_prepare_render() any time we're about to touch the
> > buffers, but the up-front call to intel_prepare_render() in
> > intelMakeCurrent covered up a few places where we forgot.  The fix now
> > isn't to put back the up-front intel_prepare_render() call but to add
> > it in the rendering paths that are missing it.
> 
> Thanks for explaining. I will try to find the place where we are missing
> the intel_prepare_render() call in this particular bug.

Actually, as far as I can see, we are already calling
intel_prepare_render() in the render path that is causing this problem,
but it turns out that by the time we have the chance to do that it is
already too late. I explain:

The test case is pretty much this:

glXMakeCurrent(dpy, win1, ctx);
glClear(GL_COLOR_BUFFER_BIT);

glXMakeCurrent(dpy, win2, ctx);
glClear(GL_COLOR_BUFFER_BIT);

If we don't generate buffers for the second drawable when we do the
second make current then we have to do it at some point during
glClear(). glClear() i

Re: [Mesa-dev] [PATCH 3/5] mesa: s/FREE/free/ in vdpau code

[Christian König]

Am 10.04.2014 03:39, schrieb Brian Paul:

---
  src/mesa/main/vdpau.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/vdpau.c b/src/mesa/main/vdpau.c
index c2cf206..d974593 100644
--- a/src/mesa/main/vdpau.c
+++ b/src/mesa/main/vdpau.c
@@ -88,7 +88,7 @@ unregister_surface(struct set_entry *entry)
 }
  
 _mesa_set_remove(ctx->vdpSurfaces, entry);

-   FREE(surf);
+   free(surf);
  }
  
  void GLAPIENTRY

@@ -145,7 +145,7 @@ register_surface(struct gl_context *ctx, GLboolean isOutput,
  
if (tex->Immutable) {

   _mesa_unlock_texture(ctx, tex);
- FREE(surf);
+ free(surf);
   _mesa_error(ctx, GL_INVALID_OPERATION,
   "VDPAURegisterSurfaceNV(texture is immutable)");
   return (GLintptr)NULL;
@@ -155,7 +155,7 @@ register_surface(struct gl_context *ctx, GLboolean isOutput,
   tex->Target = target;
else if (tex->Target != target) {
   _mesa_unlock_texture(ctx, tex);
- FREE(surf);
+ free(surf);
   _mesa_error(ctx, GL_INVALID_OPERATION,
   "VDPAURegisterSurfaceNV(target mismatch)");
   return (GLintptr)NULL;
@@ -254,7 +254,7 @@ _mesa_VDPAUUnregisterSurfaceNV(GLintptr surface)
 }
  
 _mesa_set_remove(ctx->vdpSurfaces, entry);

-   FREE(surf);
+   free(surf);
  }
  
  void GLAPIENTRY


Reviewed-by: Christian König 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [RFC] r600g/radeonsi: Use caching buffer manager for textures as well

[Michel Dänzer]

From: Michel Dänzer 

---

This is just an RFC; if other developers approve of this approach, I can
make a more extensive patch removing the use_reusable_pool parameters.

The x11perf numbers below compare ShmGet/PutImage before and after this
change with glamor from keithp's glamor-server xserver branch on a Kaveri
APU. The change also reduces the total runtime of the gtkperf tests from
about 3.5s to about 3s.

1: x11perf-baseline.txt
2: x11perf-caching.txt

1  2   Operation
   -   -
  9070.048500.0 (  5.35)   ShmPutImage 10x10 square 
  5670.027700.0 (  4.89)   ShmPutImage 100x100 square 
   758.0 2350.0 (  3.10)   ShmPutImage 500x500 square 
  3600.0 5360.0 (  1.49)   ShmGetImage 10x10 square 
  2960.0 5720.0 (  1.93)   ShmGetImage 100x100 square 
   346.0 1140.0 (  3.29)   ShmGetImage 500x500 square 

 src/gallium/drivers/radeon/r600_texture.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index e39b9ec..293eeaa 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -633,7 +633,7 @@ r600_texture_create_object(struct pipe_screen *screen,
/* Now create the backing buffer. */
if (!buf) {
if (!r600_init_resource(rscreen, resource, rtex->size,
-   rtex->surface.bo_alignment, FALSE)) {
+   rtex->surface.bo_alignment, TRUE)) {
FREE(rtex);
return NULL;
}
-- 
1.9.0

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

Re: [Mesa-dev] [PATCH] i965: fix MakeCurrent when switching a context between multiple drawables.

[Iago Toral]

Hi Kristian,

On Tue, 2014-04-08 at 10:14 -0700, Kristian Høgsberg wrote:
> On Mon, Apr 7, 2014 at 9:24 AM, Eric Anholt  wrote:
> > Iago Toral Quiroga  writes:
> >
> >> Commit 11baad35088dfd4bdabc1710df650dbfb413e7a3 produces a regression when
> >> switching a single context between multiple drawables.
> >>
> >> The problem is that we check whether we have a viewport set to decide if we
> >> need to generate buffers for the drawble, but the viewport is initialized
> >> with the first call to MakeCurrent for that context, so calling 
> >> MakeCurrent on
> >> the same context with a different drawable will have the viewport already
> >> initialized and will not generate buffers for the new drawable.
> >>
> >> This patch fixes the problem by reverting to the previous solution 
> >> implemented
> >> in commit 05da4a7a5e7d5bd988cb31f94ed8e1f053d9ee39 with a small fix to 
> >> suppport
> >> single buffer drawables too. This solution checks if we have a 
> >> renderbuffer for
> >> the drawable to decide if we need to generate a buffer or not. The original
> >> implementation, however, did this by checking the BACK_LEFT buffer, which 
> >> is
> >> not a valid solution for single buffer drawables. This patch modifies this
> >> to check the FRONT_LEFT buffer instead, which should work in both 
> >> scenarios.
> >>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74005
> >> ---
> >>  src/mesa/drivers/dri/i965/brw_context.c | 9 +
> >>  1 file changed, 5 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> >> b/src/mesa/drivers/dri/i965/brw_context.c
> >> index c9719f5..c593286 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_context.c
> >> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> >> @@ -926,6 +926,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> >>  {
> >> struct brw_context *brw;
> >> GET_CURRENT_CONTEXT(curCtx);
> >> +   struct intel_renderbuffer *rb = NULL;
> >>
> >> if (driContextPriv)
> >>brw = (struct brw_context *) driContextPriv->driverPrivate;
> >> @@ -950,6 +951,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> >>} else {
> >>   fb = driDrawPriv->driverPrivate;
> >>   readFb = driReadPriv->driverPrivate;
> >> + rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> >>   driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1;
> >>   driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1;
> >>}
> >> @@ -961,10 +963,9 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
> >>intel_gles3_srgb_workaround(brw, fb);
> >>intel_gles3_srgb_workaround(brw, readFb);
> >>
> >> -  /* If the context viewport hasn't been initialized, force a call 
> >> out to
> >> -   * the loader to get buffers so we have a drawable size for the 
> >> initial
> >> -   * viewport. */
> >> -  if (!brw->ctx.ViewportInitialized)
> >> +  /* If we don't have buffers for the drawable yet, force a call to
> >> +   * getbuffers here so we can have a default drawable size. */
> >> +  if (rb && !rb->mt)
> >>   intel_prepare_render(brw);
> >
> > We won't have an rb->mt for the front unless you're doing front buffer
> > rendering, so I think you're basically just backing out krh's change.
> > Which I think is good -- it looks like he was papering over a bug
> > elsewhere, and I think we *should* just prepare_render in makecurrent.
> > But if we're going to revert, let's just actually revert.
> 
> Here's what I wrote in https://bugs.freedesktop.org/show_bug.cgi?id=74005:
> We don't want to revert the behaviour.  The initial patch removed a
> call to intel_prepare_render() in intelMakeCurrent().  We're supposed
> to call intel_prepare_render() any time we're about to touch the
> buffers, but the up-front call to intel_prepare_render() in
> intelMakeCurrent covered up a few places where we forgot.  The fix now
> isn't to put back the up-front intel_prepare_render() call but to add
> it in the rendering paths that are missing it.

Thanks for explaining. I will try to find the place where we are missing
the intel_prepare_render() call in this particular bug.

I have a question though: Reading your initial commit I understand this
is not  because of performance reasons but mostly because always calling
intel_prepare_render() in MakeCurrent was was creating a problem in
other places... but should that happen? I guess what I mean to ask is if
calling intel_prepare_render() in MaKeCurrent is simply unnecessary or
an actual mistake that will create problems in some scenarios.

> Also, for reference, we need the buffer size for the initial value of
> the context viewport.  So the first time a context is made current, we
> call intel_prepare_render() to get the buffers so we can see what size
> they are.  When the same context is later made current with a
> different drawable, we have a value for the viewport and we're not
> supposed to change it, so 

Re: [Mesa-dev] [PATCH 03/10] mesa: add new enum MAX_UNIFORM_LOCATIONS

[Tapani Pälli]

On 04/09/2014 02:17 PM, Petri Latvala wrote:
> On 04/09/2014 12:56 PM, Tapani Pälli wrote:
>> diff --git a/src/mesa/main/get_hash_params.py 
>> b/src/mesa/main/get_hash_params.py
>> index 06d0bba..5709d42 100644
>> --- a/src/mesa/main/get_hash_params.py
>> +++ b/src/mesa/main/get_hash_params.py
>> @@ -474,6 +474,7 @@ descriptor=[
>> [ "MAX_LIST_NESTING", "CONST(MAX_LIST_NESTING), NO_EXTRA" ],
>> [ "MAX_NAME_STACK_DEPTH", "CONST(MAX_NAME_STACK_DEPTH), NO_EXTRA" ],
>> [ "MAX_PIXEL_MAP_TABLE", "CONST(MAX_PIXEL_MAP_TABLE), NO_EXTRA" ],
>> +  [ "MAX_UNIFORM_LOCATIONS", 
>> "CONTEXT_INT(Const.MaxUserAssignableUniformLocations), NO_EXTRA" ],
>> [ "NAME_STACK_DEPTH", "CONTEXT_INT(Select.NameStackDepth), NO_EXTRA" ],
>> [ "PACK_LSB_FIRST", "CONTEXT_BOOL(Pack.LsbFirst), NO_EXTRA" ],
>> [ "PACK_SWAP_BYTES", "CONTEXT_BOOL(Pack.SwapBytes), NO_EXTRA" ],
>>
> Should that NO_EXTRA be extra_ARB_explicit_uniform_location?

Yes, otherwise there will be no extension check when getting this enum.
Thanks, I'll fix this.

// Tapani

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

Re: [Mesa-dev] [PATCH] st/mesa: fix sampler_view REALLOC/FREE macro mix-up

[Jakob Bornecrantz]

On Thu, Apr 10, 2014 at 3:26 AM, Brian Paul  wrote:
> We were using REALLOC() from u_memory.h but FREE() from imports.h.
> This mismatch caused us to trash the heap on Windows after we
> deleted a texture object.
>
> This fixes a regression from commit 6c59be7776e4d.
> ---
>  src/mesa/state_tracker/st_cb_texture.c |2 +-
>  src/mesa/state_tracker/st_texture.c|   12 
>  src/mesa/state_tracker/st_texture.h|3 +++
>  3 files changed, 16 insertions(+), 1 deletion(-)

Is this patch obsoleted by the FREE/MALLOC remove series? Otherwise
this patch is:
Reviewed-by: Jakob Bornecrantz 

Cheers, Jakob.

>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c 
> b/src/mesa/state_tracker/st_cb_texture.c
> index 353415b..304dc91 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -155,7 +155,7 @@ st_DeleteTextureObject(struct gl_context *ctx,
>
> pipe_resource_reference(&stObj->pt, NULL);
> st_texture_release_all_sampler_views(stObj);
> -   FREE(stObj->sampler_views);
> +   st_texture_free_sampler_views(stObj);
> _mesa_delete_texture_object(ctx, texObj);
>  }
>
> diff --git a/src/mesa/state_tracker/st_texture.c 
> b/src/mesa/state_tracker/st_texture.c
> index 8d559df..cfa0605 100644
> --- a/src/mesa/state_tracker/st_texture.c
> +++ b/src/mesa/state_tracker/st_texture.c
> @@ -483,3 +483,15 @@ st_texture_release_all_sampler_views(struct 
> st_texture_object *stObj)
> for (i = 0; i < stObj->num_sampler_views; ++i)
>pipe_sampler_view_reference(&stObj->sampler_views[i], NULL);
>  }
> +
> +
> +void
> +st_texture_free_sampler_views(struct st_texture_object *stObj)
> +{
> +   /* NOTE:
> +* We use FREE() here to match REALLOC() above.  Both come from
> +* u_memory.h, not imports.h.  If we mis-match MALLOC/FREE from
> +* those two headers we can trash the heap.
> +*/
> +   FREE(stObj->sampler_views);
> +}
> diff --git a/src/mesa/state_tracker/st_texture.h 
> b/src/mesa/state_tracker/st_texture.h
> index 87de9f9..f2afaf1 100644
> --- a/src/mesa/state_tracker/st_texture.h
> +++ b/src/mesa/state_tracker/st_texture.h
> @@ -241,4 +241,7 @@ st_texture_release_sampler_view(struct st_context *st,
>  extern void
>  st_texture_release_all_sampler_views(struct st_texture_object *stObj);
>
> +void
> +st_texture_free_sampler_views(struct st_texture_object *stObj);
> +
>  #endif
> --
> 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 1/5] mesa: use malloc/free instead of MALLOC/FREE in attrib stack code

[Jakob Bornecrantz]

On Thu, Apr 10, 2014 at 4:41 AM, Kenneth Graunke  wrote:
> On 04/09/2014 06:39 PM, Brian Paul wrote:
>> We moved away from MALLOC/FREE in the rest of core Mesa a while ago.
>> ---
>>  src/mesa/main/attrib.c |   20 ++--
>>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> Series is:
> Reviewed-by: Kenneth Graunke 

Was looking trough the series but couldn't find the first patch, but
now I have and also the series is:
Reviewed-by: Jakob Bornecrantz 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 77263] [BDW GT3]System hangs while running glxgear with SNA

[bugzilla-daemon]

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

Guo Jinxian  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |ch...@chris-wilson.co.uk
   |org |

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