[Mesa-dev] [PATCH] i965: Set miptree target field when creating from a BO.

[Kenneth Graunke]

Prior to commit 8435b60a3577d2d905eae189cd7e770500177e99, the region
equivalent of this function called intel_miptree_create_layout, which
set mt->target to target.  With that commit, it no longer copied target.

Piglit's ext_image_dma_buf_import-sample_[xa]rgb tests would then
hit an assertion failure, where image->TexObject->Target was
GL_TEXTURE_EXTERNAL_OES, and mt->target was GL_TEXTURE_2D.

Copying the target fixes this assertion failure.

Cc: Eric Anholt 
Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/intel_tex_image.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c 
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index fbb799b..4eb024f 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -234,6 +234,7 @@ intel_set_texture_image_bo(struct gl_context *ctx,
  0, width, height, pitch);
if (intel_image->mt == NULL)
return;
+   intel_image->mt->target = target;
intel_image->mt->total_width = width;
intel_image->mt->total_height = height;
intel_image->mt->level[0].slice[0].x_offset = tile_x;
-- 
1.9.2

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

[Mesa-dev] [Bug 77966] Trails / Tracks when rendering OpenGL ES 2 moving objects (Android-x86 / Mesa 10.0.4/5)

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/r600|EGL

--- Comment #9 from Michel Dänzer  ---
Might it be better to handle this in android_surface_enqueue_buffer() instead?

Anyway, please submit the patch to the mesa-dev mailing list for review.
Preferably using git send-email, but at least using git format-patch.

-- 
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] [PATCHES 0/9] Draw Indirect and Cube Map Arrays for RadeonSI

[Ilia Mirkin]

On Thu, May 1, 2014 at 10:56 PM, Michel Dänzer  wrote:
> On 26.04.2014 22:27, Marek Olšák wrote:
>>
>> This series adds support for ARB_texture_cube_map_array and
>> ARB_draw_indirect to the radeonsi driver. There is also Gallium
>> infrastructure support for ARB_draw_indirect. As usual, the first
>> patch is unrelated to the rest of the series. ;)
>
> While that's funny :), please submit such patches separately in the
> future. Actually, the same applies to patch 2? Anyway, those two patches are
>
> Reviewed-by: Michel Dänzer 
>
>
> I'm holding off on the later patches, as the best approach for handling
> the necessary changes between LLVM and radeonsi doesn't seem settled yet.

Might be nice to get the mesa/st patches out too so that the nvc0 impl
can be added... (Christoph also has patches for those, I tested them
out briefly, seemed to work...)

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

Re: [Mesa-dev] [PATCHES 0/9] Draw Indirect and Cube Map Arrays for RadeonSI

[Michel Dänzer]

On 26.04.2014 22:27, Marek Olšák wrote:
> 
> This series adds support for ARB_texture_cube_map_array and
> ARB_draw_indirect to the radeonsi driver. There is also Gallium
> infrastructure support for ARB_draw_indirect. As usual, the first
> patch is unrelated to the rest of the series. ;)

While that's funny :), please submit such patches separately in the
future. Actually, the same applies to patch 2? Anyway, those two patches are

Reviewed-by: Michel Dänzer 


I'm holding off on the later patches, as the best approach for handling
the necessary changes between LLVM and radeonsi doesn't seem settled yet.


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH1/2] radeonsi: add support for Mullins asics.

[Samuel Li]

v2: name defaults to kabini for older llvm

Signed-off-by: Samuel Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Leo Liu 
Reviewed-by: Marek Olšák 

---
 src/gallium/drivers/radeon/r600_pipe_common.c | 7 +++
 src/gallium/drivers/radeonsi/si_state.c   | 2 ++
 src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
 src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
 4 files changed, 11 insertions(+)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 7508865..607521d 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -293,6 +293,7 @@ static const char* r600_get_name(struct pipe_screen* 
pscreen)
case CHIP_KAVERI: return "AMD KAVERI";
case CHIP_KABINI: return "AMD KABINI";
case CHIP_HAWAII: return "AMD HAWAII";
+   case CHIP_MULLINS: return "AMD MULLINS";
default: return "AMD unknown";
}
 }
@@ -410,6 +411,12 @@ const char *r600_get_llvm_processor_name(enum 
radeon_family family)
case CHIP_KABINI: return "kabini";
case CHIP_KAVERI: return "kaveri";
case CHIP_HAWAII: return "hawaii";
+   case CHIP_MULLINS:
+#if HAVE_LLVM >= 0x305
+   return "mullins";
+#else
+   return "kabini";
+#endif
default: return "";
 #endif
}
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 80f54e2..6d5408b 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3101,6 +3101,8 @@ void si_init_config(struct si_context *sctx)
/* XXX todo */
case CHIP_KABINI:
/* XXX todo */
+   case CHIP_MULLINS:
+   /* XXX todo */
default:
si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG, 
0x);
si_pm4_set_reg(pm4, R_028354_PA_SC_RASTER_CONFIG_1, 
0x);
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index b53beba..ca34359 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -276,6 +276,7 @@ static boolean do_winsys_init(struct radeon_drm_winsys *ws)
 case CHIP_KAVERI:
 case CHIP_KABINI:
 case CHIP_HAWAII:
+case CHIP_MULLINS:
 ws->info.chip_class = CIK;
 break;
 }
diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
b/src/gallium/winsys/radeon/drm/radeon_winsys.h
index fe0617b..1c0c825 100644
--- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
@@ -130,6 +130,7 @@ enum radeon_family {
 CHIP_KAVERI,
 CHIP_KABINI,
 CHIP_HAWAII,
+CHIP_MULLINS,
 CHIP_LAST,
 };
 
-- 
1.9.1

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

[Mesa-dev] XDC2014: Call for paper

[Martin Peres]

Hello,

I have the pleasure to announce that the X.org Developer Conference 2014 
will

be held in Bordeaux, France from October 8th to October 10th. The venue is
located in the campus of the University of Bordeaux 1, in the computer 
science

research lab called LaBRI.

The official page for the event is http://www.x.org/wiki/Events/XDC2014
while the call for paper is at http://www.x.org/wiki/Other/Press/CFP2014/

As usual, we are open to talks across the layers of the graphics stack, from
the kernel to desktop environments / graphical applications and about how
to make things better for the developers who build them. If you're not sure
if something might fit, mail me or add it to the ideas list found in the
program page.

The conference is free of charge and opened to the general public. If 
you plan

on coming, please add yourself to the attendees list. We'll use this list to
make badges and plan for the catering.

I am looking forward to seeing you there, if you have any 
inquiries/questions,

please send them to me (please also CC: bo...@foundation.x.org).

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

Re: [Mesa-dev] [PATCH 05/21 v3] meta: Fix saving the program pipeline state

[Chia-I Wu]

On Fri, May 2, 2014 at 7:38 AM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> This code was broken in some odd ways before.  Too much state was being
> saved, it was being restored in the wrong order, and in the wrong way.
> The biggest problem was that the pipeline object was restored before
> restoring the programs attached to the default pipeline.
>
> Fixes a regression in the glean texgen test.
>
> v3: Fairly significant re-write.  I think it's much cleaner now, and it
> avoids a bug with some meta ops that use shaders (reported by Chia-I).
Thanks, it fixes the bug.  The patch looks good to me.  A few minor
comments/questions below.

> Signed-off-by: Ian Romanick 
> Cc: Chia-I Wu 
> ---
>  src/mesa/drivers/common/meta.c | 86 
> ++
>  src/mesa/drivers/common/meta.h |  1 -
>  2 files changed, 53 insertions(+), 34 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
> index ab86f9c..42b67ec 100644
> --- a/src/mesa/drivers/common/meta.c
> +++ b/src/mesa/drivers/common/meta.c
> @@ -577,19 +577,21 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield 
> state)
>}
>
>if (ctx->Extensions.ARB_separate_shader_objects) {
> - /* Warning it must be done before _mesa_UseProgram call */
> - _mesa_reference_pipeline_object(ctx, &save->_Shader, ctx->_Shader);
> - _mesa_reference_pipeline_object(ctx, &save->Pipeline,
> - ctx->Pipeline.Current);
> - _mesa_BindProgramPipeline(0);
> + if (ctx->Pipeline.Current != ctx->Pipeline.Default) {
It seems ctx->Pipeline.Current is never equal to
ctx->Pipeline.Default.  You may check against NULL instead.

> +_mesa_reference_pipeline_object(ctx, &save->Pipeline,
> +ctx->Pipeline.Current);
> +_mesa_BindProgramPipeline(0);
>}
>
> -  for (i = 0; i < MESA_SHADER_STAGES; i++) {
> +  /* Save the shader state from ctx->Shader (instead of ctx->_Shader) so
> +   * that we don't have to worry about the current pipeline state.
> +   */
> +  for (i = 0; i <= MESA_SHADER_FRAGMENT; i++) {
I am not familiar with MESA_SHADER_COMPUTE.  If this will not give us
headaches in the future, I am fine with it.

>   _mesa_reference_shader_program(ctx, &save->Shader[i],
> - ctx->_Shader->CurrentProgram[i]);
> +ctx->Shader.CurrentProgram[i]);
>}
>_mesa_reference_shader_program(ctx, &save->ActiveShader,
> - ctx->_Shader->ActiveProgram);
> + ctx->Shader.ActiveProgram);
>
>_mesa_UseProgram(0);
> }
> @@ -908,6 +910,14 @@ _mesa_meta_end(struct gl_context *ctx)
> }
>
> if (state & MESA_META_SHADER) {
> +  static const GLenum targets[] = {
> + GL_VERTEX_SHADER,
> + GL_GEOMETRY_SHADER,
> + GL_FRAGMENT_SHADER,
> +  };
> +
> +  bool any_shader;
> +
>if (ctx->Extensions.ARB_vertex_program) {
>   _mesa_set_enable(ctx, GL_VERTEX_PROGRAM_ARB,
>save->VertexProgramEnabled);
> @@ -929,37 +939,47 @@ _mesa_meta_end(struct gl_context *ctx)
>save->ATIFragmentShaderEnabled);
>}
>
> -  /* Warning it must be done before _mesa_use_shader_program call */
> -  if (ctx->Extensions.ARB_separate_shader_objects) {
> - _mesa_reference_pipeline_object(ctx, &ctx->_Shader, save->_Shader);
> - _mesa_reference_pipeline_object(ctx, &ctx->Pipeline.Current,
> - save->Pipeline);
> - _mesa_reference_pipeline_object(ctx, &save->Pipeline, NULL);
> -  }
> +  any_shader = false;
> +  for (i = 0; i <= MESA_SHADER_FRAGMENT; i++) {
> + /* It is safe to call _mesa_use_shader_program even if the extension
> +  * necessary for that program state is not supported.  In that case,
> +  * the saved program object must be NULL and the currently bound
> +  * program object must be NULL.  _mesa_use_shader_program is a no-op
> +  * in that case.
> +  */
> + _mesa_use_shader_program(ctx, targets[i],
> +  save->Shader[i],
> +  &ctx->Shader);
> +
> + /* Do this *before* killing the reference. :)
> +  */
> + if (save->Shader[i] != NULL)
> +any_shader = true;
>
> -  if (ctx->Extensions.ARB_vertex_shader) {
> -_mesa_use_shader_program(ctx, GL_VERTEX_SHADER,
> -  save->Shader[MESA_SHADER_VERTEX],
> -  ctx->_Shader);
> + _mesa_reference_shader_program(ctx, &save->Shader[i], NULL);
>}
>
> -  if (_mesa_has_geometry_shaders(ctx))
> -_mesa_use_shader_program(ctx, GL_GEOME

Re: [Mesa-dev] [Mesa-stable] A candidate branch for the next stable release

[Carl Worth]

Carl Worth  writes:
> At this point, I'm just waiting for Anuj to backport two patches, then
> I'll test and push out the latest state as reflected here:

Anuj gave me the updated patches, and testing looks good. I've pushed
out this state now:

http://cworth.org/~cworth/mesa-stable-queue/

with only 5 nominated patches not in (not yet on master).

This looks pretty good to me, and I'll release it tomorrow unless I hear
some reason not to.

-Carl

-- 
carl.d.wo...@intel.com


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

Re: [Mesa-dev] [Mesa-stable] A candidate branch for the next stable release

[Anuj Phogat]

On Thu, May 1, 2014 at 3:05 PM, Carl Worth  wrote:
> Carl Worth  writes:
>>   * There are 23 patches that have been sent to the mesa-stable mailing
>> list, but have not yet been merged to master. The oldest of these is
>> from February 20 (10 weeks ago!).
>
> With the recent updates, I'm happy to say that this list is now down to
> only 8 patches, (though still as far back as February 20 for one). If
> nothing else, I'm happy to see the majority of the proposed fixes on the
> stable branch now (about 48 patches now).
>
>> suggests that the test itself is at fault here. If that's correct,
>> and the test can be updated, then this patch can be merged before
>> the release.
>
> Anuj informed me that the test has now been updated, so I've pulled this
> patch in.
>
> At this point, I'm just waiting for Anuj to backport two patches, then
> I'll test and push out the latest state as reflected here:
>
Sent out the backported patches to mesa-stable. Let me know if
you face any issues.

> http://cworth.org/~cworth/mesa-stable-queue/
>
> Thanks again,
>
> -Carl
>
> --
> carl.d.wo...@intel.com
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swrast: Fix vertex color in _swsetup_Translate()

[Carl Worth]

Ville Syrjälä  writes:
>  but I guess 10.1 is the only still active stable branch?

Yes. I'm performing releases based on the preceding major release. And I
continue these through one overlap of a stable release on the new major
release.

That is, the last release I'll perform in the 10.1.x series will be
concurrent with 10.2.1, (the first stable-release update after the major
10.2 release).

Obviously, if anybody is interested in performing additional stable
releases on older branches, they are free to do so. I haven't heard of
anybody volunteering for that, (nor anybody asking for it). But maybe
people just haven't spoken up?

-Carl

-- 
carl.d.wo...@intel.com


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

[Mesa-dev] [PATCH 05/21 v3] meta: Fix saving the program pipeline state

[Ian Romanick]

From: Ian Romanick 

This code was broken in some odd ways before.  Too much state was being
saved, it was being restored in the wrong order, and in the wrong way.
The biggest problem was that the pipeline object was restored before
restoring the programs attached to the default pipeline.

Fixes a regression in the glean texgen test.

v3: Fairly significant re-write.  I think it's much cleaner now, and it
avoids a bug with some meta ops that use shaders (reported by Chia-I).

Signed-off-by: Ian Romanick 
Cc: Chia-I Wu 
---
 src/mesa/drivers/common/meta.c | 86 ++
 src/mesa/drivers/common/meta.h |  1 -
 2 files changed, 53 insertions(+), 34 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index ab86f9c..42b67ec 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -577,19 +577,21 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
   }
 
   if (ctx->Extensions.ARB_separate_shader_objects) {
- /* Warning it must be done before _mesa_UseProgram call */
- _mesa_reference_pipeline_object(ctx, &save->_Shader, ctx->_Shader);
- _mesa_reference_pipeline_object(ctx, &save->Pipeline,
- ctx->Pipeline.Current);
- _mesa_BindProgramPipeline(0);
+ if (ctx->Pipeline.Current != ctx->Pipeline.Default) {
+_mesa_reference_pipeline_object(ctx, &save->Pipeline,
+ctx->Pipeline.Current);
+_mesa_BindProgramPipeline(0);
   }
 
-  for (i = 0; i < MESA_SHADER_STAGES; i++) {
+  /* Save the shader state from ctx->Shader (instead of ctx->_Shader) so
+   * that we don't have to worry about the current pipeline state.
+   */
+  for (i = 0; i <= MESA_SHADER_FRAGMENT; i++) {
  _mesa_reference_shader_program(ctx, &save->Shader[i],
- ctx->_Shader->CurrentProgram[i]);
+ctx->Shader.CurrentProgram[i]);
   }
   _mesa_reference_shader_program(ctx, &save->ActiveShader,
- ctx->_Shader->ActiveProgram);
+ ctx->Shader.ActiveProgram);
 
   _mesa_UseProgram(0);
}
@@ -908,6 +910,14 @@ _mesa_meta_end(struct gl_context *ctx)
}
 
if (state & MESA_META_SHADER) {
+  static const GLenum targets[] = {
+ GL_VERTEX_SHADER,
+ GL_GEOMETRY_SHADER,
+ GL_FRAGMENT_SHADER,
+  };
+
+  bool any_shader;
+
   if (ctx->Extensions.ARB_vertex_program) {
  _mesa_set_enable(ctx, GL_VERTEX_PROGRAM_ARB,
   save->VertexProgramEnabled);
@@ -929,37 +939,47 @@ _mesa_meta_end(struct gl_context *ctx)
   save->ATIFragmentShaderEnabled);
   }
 
-  /* Warning it must be done before _mesa_use_shader_program call */
-  if (ctx->Extensions.ARB_separate_shader_objects) {
- _mesa_reference_pipeline_object(ctx, &ctx->_Shader, save->_Shader);
- _mesa_reference_pipeline_object(ctx, &ctx->Pipeline.Current,
- save->Pipeline);
- _mesa_reference_pipeline_object(ctx, &save->Pipeline, NULL);
-  }
+  any_shader = false;
+  for (i = 0; i <= MESA_SHADER_FRAGMENT; i++) {
+ /* It is safe to call _mesa_use_shader_program even if the extension
+  * necessary for that program state is not supported.  In that case,
+  * the saved program object must be NULL and the currently bound
+  * program object must be NULL.  _mesa_use_shader_program is a no-op
+  * in that case.
+  */
+ _mesa_use_shader_program(ctx, targets[i],
+  save->Shader[i],
+  &ctx->Shader);
+
+ /* Do this *before* killing the reference. :)
+  */
+ if (save->Shader[i] != NULL)
+any_shader = true;
 
-  if (ctx->Extensions.ARB_vertex_shader) {
-_mesa_use_shader_program(ctx, GL_VERTEX_SHADER,
-  save->Shader[MESA_SHADER_VERTEX],
-  ctx->_Shader);
+ _mesa_reference_shader_program(ctx, &save->Shader[i], NULL);
   }
 
-  if (_mesa_has_geometry_shaders(ctx))
-_mesa_use_shader_program(ctx, GL_GEOMETRY_SHADER_ARB,
-  save->Shader[MESA_SHADER_GEOMETRY],
-  ctx->_Shader);
+  _mesa_reference_shader_program(ctx, &ctx->Shader.ActiveProgram,
+ save->ActiveShader);
+  _mesa_reference_shader_program(ctx, &save->ActiveShader, NULL);
 
-  if (ctx->Extensions.ARB_fragment_shader)
-_mesa_use_shader_program(ctx, GL_FRAGMENT_SHADER,
-  save->Shader[MESA_SHADER_FRAGMENT],
-  ctx->_Shader);

Re: [Mesa-dev] [PATCH 15/18] i965: Drop region usage from DRI2 winsys-allocated buffers.

[Chad Versace]

On Thu, May 01, 2014 at 02:10:39PM -0700, Eric Anholt wrote:
> Chad Versace  writes:
> 
> >> On Tue, Apr 29, 2014 at 4:34 PM, Eric Anholt  wrote:
> >
> >> > -   intel_region_release(&intelBuffer->region);
> >> > +   drm_intel_bo_unreference(&intelBuffer->bo);
> >> > free(intelBuffer);
> >
> > This hunk passes garbage to drm_intel_bo_unreference(). Here's the GCC 
> > warning.
> >
> > intel_screen.c: In function 'intelReleaseBuffer':
> > intel_screen.c:1428:4: warning: passing argument 1 of 
> > 'drm_intel_bo_unreference' from incompatible pointer type [enabled by 
> > default]
> > drm_intel_bo_unreference(&intelBuffer->bo);
> > ^
> > In file included from brw_context.h:51:0,
> >  from intel_batchbuffer.h:6,
> >  from intel_screen.c:95:
> > /usr/include/libdrm/intel_bufmgr.h:123:6: note: expected 'struct 
> > drm_intel_bo *' but argument is of type 'struct drm_intel_bo **'
> >  void drm_intel_bo_unreference(drm_intel_bo *bo);
> >
> > Fix that and this patch is
> > Reviewed-by: Chad Versace 
> 
> Thanks.  I have a really weird problem where (as far as I've found), 2
> files don't produce compiler warnings for me (intel_mipmap_tree.c and
> intel_screen.c).  I have no idea what's going on with it, and I've
> prodded at a bunch of command lines trying to figure it out.

If it helps, here is my `V=1 make -j4 -C src/mesa/drivers/dri/i965 |& grep -E 
'intel_mipmap_tree|intel_screen'`.

/bin/sh ../../../../../libtool  --tag=CC   --mode=compile gcc 
-DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" 
-DPACKAGE_VERSION=\"10.2.0-devel\" -DPACKAGE_STRING=\"Mesa\ 10.2.0-devel\" 
-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi\?product=Mesa\";
 -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"10.2.0-devel\" 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1 -DHAVE_DLADDR=1 
-DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD=1 -I.-I../../../../../include 
-I../../../../../src/ -I../../../../../src/mapi -I../../../../../src/mesa/ 
-I../../../../../src/mesa/drivers/dri/common 
-I../../../../../src/mesa/drivers/dri/intel/server 
-I../../../../../src/gtest/include -I../../../../../src/mesa/drivers/dri/common 
-D_GNU_SOURCE -DHAVE_PTHREAD -DTEXTURE_FLOAT
 _ENABLED -DUSE_X86_64_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM 
-DHAVE_LIBUDEV -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS 
-DHAVE_PTHREAD -DUSE_EXTERNAL_DXTN_LIB=1 -DHAVE_ALIAS -DHAVE_MINCORE 
-fvisibility=hidden -I/usr/include/libdrm  -g -O2 -Wall -std=c99 
-Werror=implicit-function-declaration -Werror=missing-prototypes 
-fno-strict-aliasing -fno-builtin-memcmp  -MT intel_mipmap_tree.lo -MD -MP -MF 
.deps/intel_mipmap_tree.Tpo -c -o intel_mipmap_tree.lo intel_mipmap_tree.c
/bin/sh ../../../../../libtool  --tag=CC   --mode=compile gcc 
-DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" 
-DPACKAGE_VERSION=\"10.2.0-devel\" -DPACKAGE_STRING=\"Mesa\ 10.2.0-devel\" 
-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi\?product=Mesa\";
 -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"10.2.0-devel\" 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1 -DHAVE_DLADDR=1 
-DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD=1 -I.-I../../../../../include 
-I../../../../../src/ -I../../../../../src/mapi -I../../../../../src/mesa/ 
-I../../../../../src/mesa/drivers/dri/common 
-I../../../../../src/mesa/drivers/dri/intel/server 
-I../../../../../src/gtest/include -I../../../../../src/mesa/drivers/dri/common 
-D_GNU_SOURCE -DHAVE_PTHREAD -DTEXTURE_FLOAT
 _ENABLED -DUSE_X86_64_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM 
-DHAVE_LIBUDEV -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS 
-DHAVE_PTHREAD -DUSE_EXTERNAL_DXTN_LIB=1 -DHAVE_ALIAS -DHAVE_MINCORE 
-fvisibility=hidden -I/usr/include/libdrm  -g -O2 -Wall -std=c99 
-Werror=implicit-function-declaration -Werror=missing-prototypes 
-fno-strict-aliasing -fno-builtin-memcmp  -MT intel_screen.lo -MD -MP -MF 
.deps/intel_screen.Tpo -c -o intel_screen.lo intel_screen.c
libtool: compile:  gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" 
-DPACKAGE_VERSION=\"10.2.0-devel\" "-DPACKAGE_STRING=\"Mesa 10.2.0-devel\"" 
"-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\"";
 -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"10.2.0-devel\" 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNIS

Re: [Mesa-dev] [PATCH 05/21] meta: Fix saving the program pipeline state

[Ian Romanick]

On 04/30/2014 06:59 PM, Chia-I Wu wrote:
> On Thu, May 1, 2014 at 12:11 AM, Ian Romanick  wrote:
>> On 04/29/2014 08:43 PM, Chia-I Wu wrote:
>>> On Wed, Apr 30, 2014 at 8:52 AM, Ian Romanick  wrote:
 From: Ian Romanick 

 This code was broken in some odd ways before.  Too much state was being
 saved, it was being restored in the wrong order, and in the wrong way.
 The biggest problem was that the pipeline object was restored before
 restoring the programs attached to the default pipeline.

 Fixes a regression in the glean texgen test.

 Signed-off-by: Ian Romanick 
 Reviewed-by: Kenneth Graunke 
 Reviewed-by: Eric Anholt 
 ---
  src/mesa/drivers/common/meta.c | 34 --
  src/mesa/drivers/common/meta.h |  1 -
  2 files changed, 20 insertions(+), 15 deletions(-)

 diff --git a/src/mesa/drivers/common/meta.c 
 b/src/mesa/drivers/common/meta.c
 index ac27abb..92bc185 100644
 --- a/src/mesa/drivers/common/meta.c
 +++ b/src/mesa/drivers/common/meta.c
 @@ -577,11 +577,15 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield 
 state)
}

if (ctx->Extensions.ARB_separate_shader_objects) {
 - /* Warning it must be done before _mesa_UseProgram call */
 - _mesa_reference_pipeline_object(ctx, &save->_Shader, 
 ctx->_Shader);
 - _mesa_reference_pipeline_object(ctx, &save->Pipeline,
 - ctx->Pipeline.Current);
 - _mesa_BindProgramPipeline(0);
 + /* Warning: This must be done before saving the current programs.
 +  * Otherwise the programs attached to the pipeline will be saved
 +  * instead of the programs attached to the default pipeline.
 +  */
 + if (ctx->Pipeline.Current != ctx->Pipeline.Default) {
 +_mesa_reference_pipeline_object(ctx, &save->Pipeline,
 +ctx->Pipeline.Current);
 +_mesa_BindProgramPipeline(0);
 + }
}

for (i = 0; i < MESA_SHADER_STAGES; i++) {
 @@ -929,14 +933,6 @@ _mesa_meta_end(struct gl_context *ctx)
save->ATIFragmentShaderEnabled);
}

 -  /* Warning it must be done before _mesa_use_shader_program call */
 -  if (ctx->Extensions.ARB_separate_shader_objects) {
 - _mesa_reference_pipeline_object(ctx, &ctx->_Shader, 
 save->_Shader);
 - _mesa_reference_pipeline_object(ctx, &ctx->Pipeline.Current,
 - save->Pipeline);
 - _mesa_reference_pipeline_object(ctx, &save->Pipeline, NULL);
 -  }
 -
if (ctx->Extensions.ARB_vertex_shader) {
  _mesa_use_shader_program(ctx, GL_VERTEX_SHADER,
save->Shader[MESA_SHADER_VERTEX],
 @@ -956,10 +952,20 @@ _mesa_meta_end(struct gl_context *ctx)
_mesa_reference_shader_program(ctx, &ctx->_Shader->ActiveProgram,
  save->ActiveShader);

 +  /* Warning: This must be done after _mesa_use_shader_program call.
 +   * Otherwise the programs will be restored to the pipeline object
 +   * instead of to the default pipeline.
 +   */
 +  if (save->Pipeline) {
 + assert(ctx->Extensions.ARB_separate_shader_objects);
 + _mesa_bind_pipeline(ctx, save->Pipeline);
>>> This issue does not appear to be fixed
>>>
>>>   http://lists.freedesktop.org/archives/mesa-dev/2014-April/057999.html
>>>
>>> The attached change to piglit triggers it.
>>
>> What should the result have been with that patch?  I tried that with my
>> current sso6 branch, and
>> arb_separate_shader_objects-rendezvous_by_location passes with or
>> without this patch.
> The patch should not affect the result, but I got this error after applying it
> 
> $ ./bin/arb_separate_shader_object-rendezvous_by_location -auto
> Probe color at (0,0)
>   Expected: 0.00 1.00 0.00 1.00
>   Observed: 1.00 1.00 1.00 1.00
> PIGLIT: {'result': 'fail' }
> 
> I am also on sso6 (except that I merged it to master).

I wasn't hitting because I wasn't hitting meta for the clear path.  With
meta blocked out, I get the same failure.  I should have a fix out
momentarilly... just one last piglit run...

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

Re: [Mesa-dev] [PATCH 03/11] i965: Move has_hiz from the slice to the level.

[Kenneth Graunke]

On 05/01/2014 02:21 PM, Eric Anholt wrote:
> The value depends only on the level, so no need to store the bool per slice.
> Shrinks intel_mipmap_slice from 24 bytes to 16, while slotting into an
> existing hole in intel_mipmap_level.

Huh.  I thought that we needed to disable HiZ for array slices that fell
on bad boundaries, due to the 11*j thing.

But you're right, the existing code sure doesn't seem to use it.

I'd like to see Chad's ack on this.

> ---
>  src/mesa/drivers/dri/i965/brw_blorp.cpp   |  2 +-
>  src/mesa/drivers/dri/i965/brw_misc_state.c|  2 +-
>  src/mesa/drivers/dri/i965/intel_fbo.c |  2 +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 27 
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 22 ++
>  5 files changed, 25 insertions(+), 30 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp 
> b/src/mesa/drivers/dri/i965/brw_blorp.cpp
> index 57ff30a..52ddaa6 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
> @@ -327,7 +327,7 @@ brw_hiz_op_params::brw_hiz_op_params(struct 
> intel_mipmap_tree *mt,
> x1 = depth.width;
> y1 = depth.height;
>  
> -   assert(intel_miptree_slice_has_hiz(mt, level, layer));
> +   assert(intel_miptree_level_has_hiz(mt, level));
>  
> switch (mt->format) {
> case MESA_FORMAT_Z_UNORM16:   depth_format = 
> BRW_DEPTHFORMAT_D16_UNORM; break;
> diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
> b/src/mesa/drivers/dri/i965/brw_misc_state.c
> index a6b108b..e1c2bb1 100644
> --- a/src/mesa/drivers/dri/i965/brw_misc_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
> @@ -182,7 +182,7 @@ brw_get_depthstencil_tile_masks(struct intel_mipmap_tree 
> *depth_mt,
>intel_region_get_tile_masks(depth_mt->region,
>&tile_mask_x, &tile_mask_y, false);
>  
> -  if (intel_miptree_slice_has_hiz(depth_mt, depth_level, depth_layer)) {
> +  if (intel_miptree_level_has_hiz(depth_mt, depth_level)) {
>   uint32_t hiz_tile_mask_x, hiz_tile_mask_y;
>   intel_region_get_tile_masks(depth_mt->hiz_mt->region,
>   &hiz_tile_mask_x, &hiz_tile_mask_y, 
> false);
> diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
> b/src/mesa/drivers/dri/i965/intel_fbo.c
> index f58d7c8..ea46f1d 100644
> --- a/src/mesa/drivers/dri/i965/intel_fbo.c
> +++ b/src/mesa/drivers/dri/i965/intel_fbo.c
> @@ -887,7 +887,7 @@ intel_blit_framebuffer(struct gl_context *ctx,
>  bool
>  intel_renderbuffer_has_hiz(struct intel_renderbuffer *irb)
>  {
> -   return intel_miptree_slice_has_hiz(irb->mt, irb->mt_level, irb->mt_layer);
> +   return intel_miptree_level_has_hiz(irb->mt, irb->mt_level);
>  }
>  
>  bool
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index c24cfce..2d30606 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -1271,14 +1271,13 @@ intel_miptree_alloc_non_msrt_mcs(struct brw_context 
> *brw,
>  
>  /**
>   * Helper for intel_miptree_alloc_hiz() that sets
> - * \c mt->level[level].slice[layer].has_hiz. Return true if and only if
> + * \c mt->level[level].has_hiz. Return true if and only if
>   * \c has_hiz was set.
>   */
>  static bool
> -intel_miptree_slice_enable_hiz(struct brw_context *brw,
> +intel_miptree_level_enable_hiz(struct brw_context *brw,
> struct intel_mipmap_tree *mt,
> -   uint32_t level,
> -   uint32_t layer)
> +   uint32_t level)
>  {
> assert(mt->hiz_mt);
>  
> @@ -1297,7 +1296,7 @@ intel_miptree_slice_enable_hiz(struct brw_context *brw,
>}
> }
>  
> -   mt->level[level].slice[layer].has_hiz = true;
> +   mt->level[level].has_hiz = true;
> return true;
>  }
>  
> @@ -1326,10 +1325,10 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
> /* Mark that all slices need a HiZ resolve. */
> struct intel_resolve_map *head = &mt->hiz_map;
> for (int level = mt->first_level; level <= mt->last_level; ++level) {
> -  for (int layer = 0; layer < mt->level[level].depth; ++layer) {
> - if (!intel_miptree_slice_enable_hiz(brw, mt, level, layer))
> -continue;
> +  if (!intel_miptree_level_enable_hiz(brw, mt, level))
> + continue;
>  
> +  for (int layer = 0; layer < mt->level[level].depth; ++layer) {
>head->next = malloc(sizeof(*head->next));
>head->next->prev = head;
>head->next->next = NULL;
> @@ -1348,12 +1347,10 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
>   * Does the miptree slice have hiz enabled?
>   */
>  bool
> -intel_miptree_slice_has_hiz(struct intel_mipmap_tree *mt,
> -uint32_t level,
> -uint32_t layer)
> +intel_miptre

Re: [Mesa-dev] [PATCH 07/11] i965/gen7+: Move sampler state packets to the stage sampler state table update.

[Kenneth Graunke]

On 05/01/2014 02:21 PM, Eric Anholt wrote:
> Now that we have the stage state coming into our setup of sampler states,
> it's easy to drop an identifier into it of which stage the stage_state is,
> and then look up which packet to emit in a little table.
> 
> No performance difference on cairo on glamor (n=492).
> ---
>  src/mesa/drivers/dri/i965/brw_context.c|  3 +++
>  src/mesa/drivers/dri/i965/brw_context.h|  1 +
>  src/mesa/drivers/dri/i965/gen7_gs_state.c  |  8 +---
>  src/mesa/drivers/dri/i965/gen7_sampler_state.c | 10 +-
>  src/mesa/drivers/dri/i965/gen7_vs_state.c  |  8 +---
>  src/mesa/drivers/dri/i965/gen7_wm_state.c  |  9 +
>  src/mesa/drivers/dri/i965/gen8_gs_state.c  |  8 +---
>  src/mesa/drivers/dri/i965/gen8_ps_state.c  |  8 +---
>  src/mesa/drivers/dri/i965/gen8_vs_state.c  |  8 +---
>  9 files changed, 19 insertions(+), 44 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index cad83e2..478d05a 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -628,6 +628,9 @@ brwCreateContext(gl_api api,
> brw->must_use_separate_stencil = screen->hw_must_use_separate_stencil;
> brw->has_swizzling = screen->hw_has_swizzling;
>  
> +   brw->vs.base.stage = MESA_SHADER_VERTEX;
> +   brw->gs.base.stage = MESA_SHADER_GEOMETRY;
> +   brw->wm.base.stage = MESA_SHADER_FRAGMENT;
> if (brw->gen >= 8) {
>gen8_init_vtable_surface_functions(brw);
>gen7_init_vtable_sampler_functions(brw);
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 379af38..92e1592 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -925,6 +925,7 @@ struct brw_transform_feedback_object {
>   */
>  struct brw_stage_state
>  {
> +   gl_shader_stage stage;
> struct brw_stage_prog_data *prog_data;
>  
> /**
> diff --git a/src/mesa/drivers/dri/i965/gen7_gs_state.c 
> b/src/mesa/drivers/dri/i965/gen7_gs_state.c
> index d18ae15..06e6cf7 100644
> --- a/src/mesa/drivers/dri/i965/gen7_gs_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_gs_state.c
> @@ -66,12 +66,6 @@ upload_gs_state(struct brw_context *brw)
> /* CACHE_NEW_GS_PROG */
> const struct brw_vec4_prog_data *prog_data = &brw->gs.prog_data->base;
>  
> -   /* CACHE_NEW_SAMPLER */
> -   BEGIN_BATCH(2);
> -   OUT_BATCH(_3DSTATE_SAMPLER_STATE_POINTERS_GS << 16 | (2 - 2));
> -   OUT_BATCH(stage_state->sampler_offset);
> -   ADVANCE_BATCH();
> -
> gen7_upload_constant_state(brw, stage_state, active, 
> _3DSTATE_CONSTANT_GS);
>  
> /**
> @@ -198,7 +192,7 @@ const struct brw_tracked_state gen7_gs_state = {
>  BRW_NEW_GS_BINDING_TABLE |
>  BRW_NEW_BATCH |
>  BRW_NEW_PUSH_CONSTANT_ALLOCATION),
> -  .cache = CACHE_NEW_GS_PROG | CACHE_NEW_SAMPLER
> +  .cache = CACHE_NEW_GS_PROG
> },
> .emit = upload_gs_state,
>  };
> diff --git a/src/mesa/drivers/dri/i965/gen7_sampler_state.c 
> b/src/mesa/drivers/dri/i965/gen7_sampler_state.c
> index 8eb337d..72acd3c 100644
> --- a/src/mesa/drivers/dri/i965/gen7_sampler_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_sampler_state.c
> @@ -187,6 +187,11 @@ gen7_upload_sampler_state_table(struct brw_context *brw,
> struct gl_context *ctx = &brw->ctx;
> struct gen7_sampler_state *samplers;
> uint32_t sampler_count = stage_state->sampler_count;
> +   static const uint16_t packet_headers[] = {
> +  [MESA_SHADER_VERTEX] = _3DSTATE_SAMPLER_STATE_POINTERS_VS,
> +  [MESA_SHADER_GEOMETRY] = _3DSTATE_SAMPLER_STATE_POINTERS_GS,
> +  [MESA_SHADER_FRAGMENT] = _3DSTATE_SAMPLER_STATE_POINTERS_PS,
> +   };
>  
> GLbitfield SamplersUsed = prog->SamplersUsed;
>  
> @@ -207,7 +212,10 @@ gen7_upload_sampler_state_table(struct brw_context *brw,
>}
> }
> 

This moves 3DSTATE_SAMPLER_STATE_POINTERS_VS beyond the protection of
the workaround flush.  I think you need to add:

if (brw->gen == 7 && !brw->is_haswell &&
stage_state->stage == MESA_SHADER_VERTEX) {
gen7_emit_vs_workaround_flush(brw);
}

> -   brw->state.dirty.cache |= CACHE_NEW_SAMPLER;
> +   BEGIN_BATCH(2);
> +   OUT_BATCH(packet_headers[stage_state->stage] << 16 | (2 - 2));
> +   OUT_BATCH(stage_state->sampler_offset);
> +   ADVANCE_BATCH();
>  }
>  
>  void

With that change, all patches except 3 are:
Reviewed-by: Kenneth Graunke 



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] i965: no more regions!

[Chad Versace]

On Thu, May 01, 2014 at 02:12:00PM -0700, Eric Anholt wrote:
> Chad Versace  writes:
> 
> > On Tue, Apr 29, 2014 at 04:34:25PM -0700, Eric Anholt wrote:
> >> Here's the series for removing struct intel_region from the i965 driver.
> >> I think it's worth it for the code savings and reduced steps in allocating
> >> a miptree.  Plus, it gave me a chance to rewrite some comments about the
> >> driver.
> >> 
> >> It's a longer series than I wanted, but there are some nice little
> >> cleanups in it that hopefully make it easier to review than 18 patches
> >> would usually be.
> >
> > The series was very easy to review in the bite-sized patches. Thanks for
> > breaking it up that way.
> >
> > Miptrees and regions and bo's are hot data structures. Now that the
> > region is gone, do you expect any reduction in cache misses? Any
> > measurable gain in CPU-bound workloads?
> 
> That was the motivation, but I haven't done the performance testing on
> it -- lunch was long enough to barely detect a .5% change, and I expect
> this to be <.5%.

1.005^20 = 1.105, so 1.005x is real progress imo.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [00/21] Last of SSO, take 47

[Eric Anholt]

Ian Romanick  writes:

> On 04/30/2014 05:13 PM, Eric Anholt wrote:
>> Ian Romanick  writes:
>> 
>>> On 04/30/2014 12:41 PM, Eric Anholt wrote:
 Ian Romanick  writes:

> A lot the patches in this series were slightly reworked to incorporate
> Eric's feedback (remove ir_variable::user_location) on the previous
> attempt.  Other than that change, I patch 1 is new, and patch 16 adds
> previously missing display list support.

 Patch 2, 3, 13, 16, 17, 18, 20, 21 are:

 Reviewed-by: Eric Anholt 

 I think my patch 15 comments were minor, and if you agree with them
 (meaning I actually understood what was going on), then apply the r-b
 there too.

 Patch 19 is:

 Acked-by: Eric Anholt 

 Patch 14 I don't think is needed (since we've got explicit locations
 being assigned to corresponding varying slots).
>>>
>>> The sorting is so that a vertex shader that does
>>>
>>> out vec4 a;
>>> out vec4 b;
>>>
>>> and a fragment shader that does
>>>
>>> in vec4 b;
>>> in vec4 a;
>>>
>>> will assign the same locations for a and b.  If both shaders have the
>>> same set of varyings, they'll all get the same locations.  Without
>>> sorting, we assign the locations based on the order in which variables
>>> appear in the shader text.
>> 
>> In SSO, we aren't assigning locations, because we have explicit
>> locations for everything.  In non-SSO, we either have explicit
>> locations, or we're matching ir_variables up by name and assigning the
>> dynamic locations to the same name across both producer and consumer.
>
> Ah, but we are.  Rendezvous by name still works, even with separable
> programs.  Rendezvous by location works even with explicitly linked
> programs.
>
> Applications are even allowed to use explicit locations for some
> varyings and rendezvous by name for others.
>
> Relevant spec text:
>
> With separable program objects, interfaces between shader stages may
> involve the outputs from one program object and the inputs from a
> second program object.  For such interfaces, it is not possible to
> detect mismatches at link time, because the programs are linked
> separately.  When each such program is linked, all inputs or outputs
> interfacing with another program stage are treated as active.  The
> linker will generate an executable that assumes the presence of a
> compatible program on the other side of the interface.  If a mismatch
> between programs occurs, no GL error will be generated, but some or all
> of the inputs on the interface will be undefined.
>
> At an interface between program objects, the set of inputs and outputs are
> considered to match exactly if and only if:
>
>   * The built-in input and output blocks used on the interface
> ("gl_PerVertex" or "gl_PerFragment") match, as described below.
>
>   * Every declared input block or variable must have a matching output, as
> described above.
>
>   * There are no output blocks or user-defined output variables
> declared without a matching input block or variable declaration.
>
> When the set of inputs and outputs on an interface between programs
> matches exactly, all inputs are well-defined unless the corresponding
> outputs were not written in the previous shader.  However, any mismatch
> between inputs and outputs results in all inputs being undefined except
> for cases noted below.  Even if an input has a corresponding output
> that matches exactly, mismatches on other inputs or outputs may
> adversely affect the executable code generated to read or write the
> matching variable.
>
> The important part is "...the set of inputs and outputs on an interface
> between programs matches exactly..." from the last paragraph. If the
> declared inputs to the fragment shader exactly match the declared
> outputs of the vertex shader, it "just works."  The implication being
> that locations are assigned by the linker in a deterministic way.

OK, that really surprised me.  I never expected the spec to allow that.
Patch 14, then, is also:

Reviewed-by: Eric Anholt 


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

Re: [Mesa-dev] [Mesa-stable] A candidate branch for the next stable release

[Carl Worth]

Carl Worth  writes:
>   * There are 23 patches that have been sent to the mesa-stable mailing
> list, but have not yet been merged to master. The oldest of these is
> from February 20 (10 weeks ago!).

With the recent updates, I'm happy to say that this list is now down to
only 8 patches, (though still as far back as February 20 for one). If
nothing else, I'm happy to see the majority of the proposed fixes on the
stable branch now (about 48 patches now).

> suggests that the test itself is at fault here. If that's correct,
> and the test can be updated, then this patch can be merged before
> the release.

Anuj informed me that the test has now been updated, so I've pulled this
patch in.

At this point, I'm just waiting for Anuj to backport two patches, then
I'll test and push out the latest state as reflected here:

http://cworth.org/~cworth/mesa-stable-queue/

Thanks again,

-Carl

-- 
carl.d.wo...@intel.com


pgppE7hw1mrW2.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] clover: Add a stub implementation of clCreateImage() v3

[Francisco Jerez]

Tom Stellard  writes:

> Now that we are uisng the OpenCL 1.2 headers, applications expect all
> the OpenCL 1.2 functions to be implemented.
>
> This fixes linking errors with the piglit CL tests.
>
> v2:
>   - Use c++ features
>   - Fix error code handling
>
> v3:
>   - Move  into api/util.hpp
>   - Fix indentation

Thanks,

Reviewed-by: Francisco Jerez 

> ---
>  src/gallium/state_trackers/clover/api/dispatch.cpp |  2 +-
>  src/gallium/state_trackers/clover/api/dispatch.hpp |  8 +++-
>  src/gallium/state_trackers/clover/api/memory.cpp   | 12 
>  src/gallium/state_trackers/clover/api/util.hpp |  1 +
>  4 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp 
> b/src/gallium/state_trackers/clover/api/dispatch.cpp
> index 2ee6208..488e654 100644
> --- a/src/gallium/state_trackers/clover/api/dispatch.cpp
> +++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
> @@ -120,7 +120,7 @@ namespace clover {
>clCreateSubDevices,
>clRetainDevice,
>clReleaseDevice,
> -  NULL, // clCreateImage
> +  clCreateImage,
>NULL, // clCreateProgramWithBuiltInKernels
>NULL, // clCompileProgram
>NULL, // clLinkProgram
> diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp 
> b/src/gallium/state_trackers/clover/api/dispatch.hpp
> index 833fb0e..ffae1ae 100644
> --- a/src/gallium/state_trackers/clover/api/dispatch.hpp
> +++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
> @@ -653,7 +653,13 @@ struct _cl_icd_dispatch {
> CL_API_ENTRY cl_int (CL_API_CALL *clReleaseDevice)(
>cl_device_id device);
>  
> -   void *clCreateImage;
> +   CL_API_ENTRY cl_mem (CL_API_CALL *clCreateImage)(
> +  cl_context context,
> +  cl_mem_flags flags,
> +  const cl_image_format *image_format,
> +  const cl_image_desc *image_desc,
> +  void *host_ptr,
> +  cl_int *errcode_ret);
>  
> CL_API_ENTRY cl_program (CL_API_CALL *clCreateProgramWithBuiltInKernels)(
>cl_context context,
> diff --git a/src/gallium/state_trackers/clover/api/memory.cpp 
> b/src/gallium/state_trackers/clover/api/memory.cpp
> index 7ed2191..d26b1c6 100644
> --- a/src/gallium/state_trackers/clover/api/memory.cpp
> +++ b/src/gallium/state_trackers/clover/api/memory.cpp
> @@ -334,3 +334,15 @@ clSetMemObjectDestructorCallback(cl_mem d_mem,
>  } catch (error &e) {
> return e.get();
>  }
> +
> +CLOVER_API cl_mem
> +clCreateImage(cl_context d_ctx, cl_mem_flags flags,
> +  const cl_image_format *format,
> +  const cl_image_desc *image_desc,
> +  void *host_ptr, cl_int *r_errcode) {
> +   // This function was added in OpenCL 1.2
> +   std::cerr << "CL user error: clCreateImage() not supported by OpenCL 
> 1.1." <<
> +std::endl;
> +   ret_error(r_errcode, CL_INVALID_OPERATION);
> +   return NULL;
> +}
> diff --git a/src/gallium/state_trackers/clover/api/util.hpp 
> b/src/gallium/state_trackers/clover/api/util.hpp
> index c2b216e..918df61 100644
> --- a/src/gallium/state_trackers/clover/api/util.hpp
> +++ b/src/gallium/state_trackers/clover/api/util.hpp
> @@ -24,6 +24,7 @@
>  #define CLOVER_API_UTIL_HPP
>  
>  #include 
> +#include 
>  
>  #include "core/error.hpp"
>  #include "core/property.hpp"
> -- 
> 1.8.1.4


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

Re: [Mesa-dev] [00/21] Last of SSO, take 47

[Ian Romanick]

On 04/30/2014 05:13 PM, Eric Anholt wrote:
> Ian Romanick  writes:
> 
>> On 04/30/2014 12:41 PM, Eric Anholt wrote:
>>> Ian Romanick  writes:
>>>
 A lot the patches in this series were slightly reworked to incorporate
 Eric's feedback (remove ir_variable::user_location) on the previous
 attempt.  Other than that change, I patch 1 is new, and patch 16 adds
 previously missing display list support.
>>>
>>> Patch 2, 3, 13, 16, 17, 18, 20, 21 are:
>>>
>>> Reviewed-by: Eric Anholt 
>>>
>>> I think my patch 15 comments were minor, and if you agree with them
>>> (meaning I actually understood what was going on), then apply the r-b
>>> there too.
>>>
>>> Patch 19 is:
>>>
>>> Acked-by: Eric Anholt 
>>>
>>> Patch 14 I don't think is needed (since we've got explicit locations
>>> being assigned to corresponding varying slots).
>>
>> The sorting is so that a vertex shader that does
>>
>> out vec4 a;
>> out vec4 b;
>>
>> and a fragment shader that does
>>
>> in vec4 b;
>> in vec4 a;
>>
>> will assign the same locations for a and b.  If both shaders have the
>> same set of varyings, they'll all get the same locations.  Without
>> sorting, we assign the locations based on the order in which variables
>> appear in the shader text.
> 
> In SSO, we aren't assigning locations, because we have explicit
> locations for everything.  In non-SSO, we either have explicit
> locations, or we're matching ir_variables up by name and assigning the
> dynamic locations to the same name across both producer and consumer.

Ah, but we are.  Rendezvous by name still works, even with separable
programs.  Rendezvous by location works even with explicitly linked
programs.

Applications are even allowed to use explicit locations for some
varyings and rendezvous by name for others.

Relevant spec text:

With separable program objects, interfaces between shader stages may
involve the outputs from one program object and the inputs from a
second program object.  For such interfaces, it is not possible to
detect mismatches at link time, because the programs are linked
separately.  When each such program is linked, all inputs or outputs
interfacing with another program stage are treated as active.  The
linker will generate an executable that assumes the presence of a
compatible program on the other side of the interface.  If a mismatch
between programs occurs, no GL error will be generated, but some or all
of the inputs on the interface will be undefined.

At an interface between program objects, the set of inputs and outputs are
considered to match exactly if and only if:

  * The built-in input and output blocks used on the interface
("gl_PerVertex" or "gl_PerFragment") match, as described below.

  * Every declared input block or variable must have a matching output, as
described above.

  * There are no output blocks or user-defined output variables
declared without a matching input block or variable declaration.

When the set of inputs and outputs on an interface between programs
matches exactly, all inputs are well-defined unless the corresponding
outputs were not written in the previous shader.  However, any mismatch
between inputs and outputs results in all inputs being undefined except
for cases noted below.  Even if an input has a corresponding output
that matches exactly, mismatches on other inputs or outputs may
adversely affect the executable code generated to read or write the
matching variable.

The important part is "...the set of inputs and outputs on an interface
between programs matches exactly..." from the last paragraph. If the
declared inputs to the fragment shader exactly match the declared
outputs of the vertex shader, it "just works."  The implication being
that locations are assigned by the linker in a deterministic way.

This combination of use modes is a big part of the reason this has
taken so long to finish.  Gregory's initial patches had *no* support
for rendezvous by location, and it was working with his shaders that
also worked with AMD and NVIDIA.  Also, if I recall correctly, all of
the shaders in Serious Sam use rendezvous by name, but I could be
mistaken.  I believe use the exact same shader code in linked and
separable modes.




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 15/18] i965: Drop region usage from DRI2 winsys-allocated buffers.

[Eric Anholt]

Chad Versace  writes:

>> On Tue, Apr 29, 2014 at 4:34 PM, Eric Anholt  wrote:
>
>> > -   intel_region_release(&intelBuffer->region);
>> > +   drm_intel_bo_unreference(&intelBuffer->bo);
>> > free(intelBuffer);
>
> This hunk passes garbage to drm_intel_bo_unreference(). Here's the GCC 
> warning.
>
> intel_screen.c: In function 'intelReleaseBuffer':
> intel_screen.c:1428:4: warning: passing argument 1 of 
> 'drm_intel_bo_unreference' from incompatible pointer type [enabled by default]
> drm_intel_bo_unreference(&intelBuffer->bo);
> ^
> In file included from brw_context.h:51:0,
>  from intel_batchbuffer.h:6,
>  from intel_screen.c:95:
> /usr/include/libdrm/intel_bufmgr.h:123:6: note: expected 'struct 
> drm_intel_bo *' but argument is of type 'struct drm_intel_bo **'
>  void drm_intel_bo_unreference(drm_intel_bo *bo);
>
> Fix that and this patch is
> Reviewed-by: Chad Versace 

Thanks.  I have a really weird problem where (as far as I've found), 2
files don't produce compiler warnings for me (intel_mipmap_tree.c and
intel_screen.c).  I have no idea what's going on with it, and I've
prodded at a bunch of command lines trying to figure it out.


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

[Mesa-dev] [PATCH 11/11] i965: Move push constant state packets to push constant update time.

[Eric Anholt]

-0.553779% +/- 0.423394% effect on cairo-perf-trace runtime on glamor
(n=612)
---
 src/mesa/drivers/dri/i965/gen6_vs_state.c | 11 ++-
 src/mesa/drivers/dri/i965/gen6_wm_state.c |  8 +++-
 src/mesa/drivers/dri/i965/gen7_gs_state.c | 29 +++--
 src/mesa/drivers/dri/i965/gen7_vs_state.c |  8 ++--
 src/mesa/drivers/dri/i965/gen7_wm_state.c |  9 ++---
 src/mesa/drivers/dri/i965/gen8_gs_state.c |  7 ++-
 src/mesa/drivers/dri/i965/gen8_ps_state.c |  8 ++--
 src/mesa/drivers/dri/i965/gen8_vs_state.c |  8 ++--
 8 files changed, 42 insertions(+), 46 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen6_vs_state.c 
b/src/mesa/drivers/dri/i965/gen6_vs_state.c
index 25f55c4..9764645 100644
--- a/src/mesa/drivers/dri/i965/gen6_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_vs_state.c
@@ -98,13 +98,22 @@ gen6_upload_vs_push_constants(struct brw_context *brw)
 
gen6_upload_vec4_push_constants(brw, &vp->program.Base, prog_data,
stage_state, AUB_TRACE_VS_CONSTANTS);
+
+   if (brw->gen >= 7) {
+  if (brw->gen == 7 && !brw->is_haswell)
+ gen7_emit_vs_workaround_flush(brw);
+
+  gen7_upload_constant_state(brw, stage_state, true /* active */,
+ _3DSTATE_CONSTANT_VS);
+   }
 }
 
 const struct brw_tracked_state gen6_vs_push_constants = {
.dirty = {
   .mesa  = _NEW_TRANSFORM | _NEW_PROGRAM_CONSTANTS,
   .brw   = (BRW_NEW_BATCH |
-   BRW_NEW_VERTEX_PROGRAM),
+BRW_NEW_VERTEX_PROGRAM |
+BRW_NEW_PUSH_CONSTANT_ALLOCATION),
   .cache = CACHE_NEW_VS_PROG,
},
.emit = gen6_upload_vs_push_constants,
diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c 
b/src/mesa/drivers/dri/i965/gen6_wm_state.c
index 3f5dd29..402d9c3 100644
--- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
@@ -81,13 +81,19 @@ gen6_upload_wm_push_constants(struct brw_context *brw)
 
   brw->wm.base.push_const_size = ALIGN(prog_data->base.nr_params, 8) / 8;
}
+
+   if (brw->gen >= 7) {
+  gen7_upload_constant_state(brw, &brw->wm.base, true,
+ _3DSTATE_CONSTANT_PS);
+   }
 }
 
 const struct brw_tracked_state gen6_wm_push_constants = {
.dirty = {
   .mesa  = _NEW_PROGRAM_CONSTANTS,
   .brw   = (BRW_NEW_BATCH |
-   BRW_NEW_FRAGMENT_PROGRAM),
+BRW_NEW_FRAGMENT_PROGRAM |
+BRW_NEW_PUSH_CONSTANT_ALLOCATION),
   .cache = CACHE_NEW_WM_PROG,
},
.emit = gen6_upload_wm_push_constants,
diff --git a/src/mesa/drivers/dri/i965/gen7_gs_state.c 
b/src/mesa/drivers/dri/i965/gen7_gs_state.c
index 57d..30dfa6b 100644
--- a/src/mesa/drivers/dri/i965/gen7_gs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_gs_state.c
@@ -30,25 +30,29 @@
 static void
 gen7_upload_gs_push_constants(struct brw_context *brw)
 {
+   const struct brw_stage_state *stage_state = &brw->gs.base;
/* BRW_NEW_GEOMETRY_PROGRAM */
-   const struct brw_geometry_program *vp =
+   const struct brw_geometry_program *gp =
   (struct brw_geometry_program *) brw->geometry_program;
-   if (!vp)
-  return;
 
-   /* CACHE_NEW_GS_PROG */
-   const struct brw_vec4_prog_data *prog_data = &brw->gs.prog_data->base;
-   struct brw_stage_state *stage_state = &brw->gs.base;
+   if (gp) {
+  /* CACHE_NEW_GS_PROG */
+  const struct brw_vec4_prog_data *prog_data = &brw->gs.prog_data->base;
+  struct brw_stage_state *stage_state = &brw->gs.base;
+
+  gen6_upload_vec4_push_constants(brw, &gp->program.Base, prog_data,
+  stage_state, AUB_TRACE_VS_CONSTANTS);
+   }
 
-   gen6_upload_vec4_push_constants(brw, &vp->program.Base, prog_data,
-   stage_state, AUB_TRACE_VS_CONSTANTS);
+   gen7_upload_constant_state(brw, stage_state, gp, _3DSTATE_CONSTANT_GS);
 }
 
 const struct brw_tracked_state gen7_gs_push_constants = {
.dirty = {
   .mesa  = _NEW_TRANSFORM | _NEW_PROGRAM_CONSTANTS,
   .brw   = (BRW_NEW_BATCH |
-   BRW_NEW_GEOMETRY_PROGRAM),
+BRW_NEW_GEOMETRY_PROGRAM |
+BRW_NEW_PUSH_CONSTANT_ALLOCATION),
   .cache = CACHE_NEW_GS_PROG,
},
.emit = gen7_upload_gs_push_constants,
@@ -66,8 +70,6 @@ upload_gs_state(struct brw_context *brw)
/* CACHE_NEW_GS_PROG */
const struct brw_vec4_prog_data *prog_data = &brw->gs.prog_data->base;
 
-   gen7_upload_constant_state(brw, stage_state, active, _3DSTATE_CONSTANT_GS);
-
/**
 * From Graphics BSpec: 3D-Media-GPGPU Engine > 3D Pipeline Stages >
 * Geometry > Geometry Shader > State:
@@ -186,11 +188,10 @@ upload_gs_state(struct brw_context *brw)
 
 const struct brw_tracked_state gen7_gs_state = {
.dirty = {
-  .mesa  = _NEW_TRANSFORM | _NEW_PROGRAM_CONSTANTS,
+  .mesa  = _NEW_TRANSFORM,
   .brw   = (BRW_NEW_CONTEXT |
 BRW_NEW_GEOMETRY_PROGRA

[Mesa-dev] [PATCH 07/11] i965/gen7+: Move sampler state packets to the stage sampler state table update.

[Eric Anholt]

Now that we have the stage state coming into our setup of sampler states,
it's easy to drop an identifier into it of which stage the stage_state is,
and then look up which packet to emit in a little table.

No performance difference on cairo on glamor (n=492).
---
 src/mesa/drivers/dri/i965/brw_context.c|  3 +++
 src/mesa/drivers/dri/i965/brw_context.h|  1 +
 src/mesa/drivers/dri/i965/gen7_gs_state.c  |  8 +---
 src/mesa/drivers/dri/i965/gen7_sampler_state.c | 10 +-
 src/mesa/drivers/dri/i965/gen7_vs_state.c  |  8 +---
 src/mesa/drivers/dri/i965/gen7_wm_state.c  |  9 +
 src/mesa/drivers/dri/i965/gen8_gs_state.c  |  8 +---
 src/mesa/drivers/dri/i965/gen8_ps_state.c  |  8 +---
 src/mesa/drivers/dri/i965/gen8_vs_state.c  |  8 +---
 9 files changed, 19 insertions(+), 44 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index cad83e2..478d05a 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -628,6 +628,9 @@ brwCreateContext(gl_api api,
brw->must_use_separate_stencil = screen->hw_must_use_separate_stencil;
brw->has_swizzling = screen->hw_has_swizzling;
 
+   brw->vs.base.stage = MESA_SHADER_VERTEX;
+   brw->gs.base.stage = MESA_SHADER_GEOMETRY;
+   brw->wm.base.stage = MESA_SHADER_FRAGMENT;
if (brw->gen >= 8) {
   gen8_init_vtable_surface_functions(brw);
   gen7_init_vtable_sampler_functions(brw);
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 379af38..92e1592 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -925,6 +925,7 @@ struct brw_transform_feedback_object {
  */
 struct brw_stage_state
 {
+   gl_shader_stage stage;
struct brw_stage_prog_data *prog_data;
 
/**
diff --git a/src/mesa/drivers/dri/i965/gen7_gs_state.c 
b/src/mesa/drivers/dri/i965/gen7_gs_state.c
index d18ae15..06e6cf7 100644
--- a/src/mesa/drivers/dri/i965/gen7_gs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_gs_state.c
@@ -66,12 +66,6 @@ upload_gs_state(struct brw_context *brw)
/* CACHE_NEW_GS_PROG */
const struct brw_vec4_prog_data *prog_data = &brw->gs.prog_data->base;
 
-   /* CACHE_NEW_SAMPLER */
-   BEGIN_BATCH(2);
-   OUT_BATCH(_3DSTATE_SAMPLER_STATE_POINTERS_GS << 16 | (2 - 2));
-   OUT_BATCH(stage_state->sampler_offset);
-   ADVANCE_BATCH();
-
gen7_upload_constant_state(brw, stage_state, active, _3DSTATE_CONSTANT_GS);
 
/**
@@ -198,7 +192,7 @@ const struct brw_tracked_state gen7_gs_state = {
 BRW_NEW_GS_BINDING_TABLE |
 BRW_NEW_BATCH |
 BRW_NEW_PUSH_CONSTANT_ALLOCATION),
-  .cache = CACHE_NEW_GS_PROG | CACHE_NEW_SAMPLER
+  .cache = CACHE_NEW_GS_PROG
},
.emit = upload_gs_state,
 };
diff --git a/src/mesa/drivers/dri/i965/gen7_sampler_state.c 
b/src/mesa/drivers/dri/i965/gen7_sampler_state.c
index 8eb337d..72acd3c 100644
--- a/src/mesa/drivers/dri/i965/gen7_sampler_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_sampler_state.c
@@ -187,6 +187,11 @@ gen7_upload_sampler_state_table(struct brw_context *brw,
struct gl_context *ctx = &brw->ctx;
struct gen7_sampler_state *samplers;
uint32_t sampler_count = stage_state->sampler_count;
+   static const uint16_t packet_headers[] = {
+  [MESA_SHADER_VERTEX] = _3DSTATE_SAMPLER_STATE_POINTERS_VS,
+  [MESA_SHADER_GEOMETRY] = _3DSTATE_SAMPLER_STATE_POINTERS_GS,
+  [MESA_SHADER_FRAGMENT] = _3DSTATE_SAMPLER_STATE_POINTERS_PS,
+   };
 
GLbitfield SamplersUsed = prog->SamplersUsed;
 
@@ -207,7 +212,10 @@ gen7_upload_sampler_state_table(struct brw_context *brw,
   }
}
 
-   brw->state.dirty.cache |= CACHE_NEW_SAMPLER;
+   BEGIN_BATCH(2);
+   OUT_BATCH(packet_headers[stage_state->stage] << 16 | (2 - 2));
+   OUT_BATCH(stage_state->sampler_offset);
+   ADVANCE_BATCH();
 }
 
 void
diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c 
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index b5fc871..6b1f680 100644
--- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
@@ -75,12 +75,6 @@ upload_vs_state(struct brw_context *brw)
if (!brw->is_haswell)
   gen7_emit_vs_workaround_flush(brw);
 
-   /* CACHE_NEW_SAMPLER */
-   BEGIN_BATCH(2);
-   OUT_BATCH(_3DSTATE_SAMPLER_STATE_POINTERS_VS << 16 | (2 - 2));
-   OUT_BATCH(stage_state->sampler_offset);
-   ADVANCE_BATCH();
-
gen7_upload_constant_state(brw, stage_state, true /* active */,
   _3DSTATE_CONSTANT_VS);
 
@@ -126,7 +120,7 @@ const struct brw_tracked_state gen7_vs_state = {
BRW_NEW_VS_BINDING_TABLE |
BRW_NEW_BATCH |
 BRW_NEW_PUSH_CONSTANT_ALLOCATION),
-  .cache = CACHE_NEW_VS_PROG | CACHE_NEW_SAMPLER
+  .cache = CACHE_NEW_VS_PROG
},
.emit = upload_vs_state,
 };
diff --git a/src/mesa/drivers/dri

[Mesa-dev] glamor-fixes cleanups

[Eric Anholt]

Here's what's left of my glamor-fixes branch of mesa, which is a bunch of
little changes that were motivated by digging through sysprof of cairo on
glamor.  No individual thing here is big, but I think they're all at least
non-harmful, and it's +123, -210 lines anyway.

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

Re: [Mesa-dev] i965: no more regions!

[Eric Anholt]

Chad Versace  writes:

> On Tue, Apr 29, 2014 at 04:34:25PM -0700, Eric Anholt wrote:
>> Here's the series for removing struct intel_region from the i965 driver.
>> I think it's worth it for the code savings and reduced steps in allocating
>> a miptree.  Plus, it gave me a chance to rewrite some comments about the
>> driver.
>> 
>> It's a longer series than I wanted, but there are some nice little
>> cleanups in it that hopefully make it easier to review than 18 patches
>> would usually be.
>
> The series was very easy to review in the bite-sized patches. Thanks for
> breaking it up that way.
>
> Miptrees and regions and bo's are hot data structures. Now that the
> region is gone, do you expect any reduction in cache misses? Any
> measurable gain in CPU-bound workloads?

That was the motivation, but I haven't done the performance testing on
it -- lunch was long enough to barely detect a .5% change, and I expect
this to be <.5%.


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

[Mesa-dev] [PATCH 09/11] i965: Refactor gen7_upload_constant_state to look more like gen8.

[Eric Anholt]

---
 src/mesa/drivers/dri/i965/gen7_vs_state.c | 40 ---
 1 file changed, 15 insertions(+), 25 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c 
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index e7fd4b5..ba4a36e 100644
--- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
@@ -35,31 +35,21 @@ gen7_upload_constant_state(struct brw_context *brw,
const struct brw_stage_state *stage_state,
bool active, unsigned opcode)
 {
-   if (!active || stage_state->push_const_size == 0) {
-  /* Disable the push constant buffers. */
-  BEGIN_BATCH(7);
-  OUT_BATCH(opcode << 16 | (7 - 2));
-  OUT_BATCH(0);
-  OUT_BATCH(0);
-  OUT_BATCH(0);
-  OUT_BATCH(0);
-  OUT_BATCH(0);
-  OUT_BATCH(0);
-  ADVANCE_BATCH();
-   } else {
-  BEGIN_BATCH(7);
-  OUT_BATCH(opcode << 16 | (7 - 2));
-  OUT_BATCH(stage_state->push_const_size);
-  OUT_BATCH(0);
-  /* Pointer to the constant buffer.  Covered by the set of state flags
-   * from gen6_prepare_wm_contants
-   */
-  OUT_BATCH(stage_state->push_const_offset | GEN7_MOCS_L3);
-  OUT_BATCH(0);
-  OUT_BATCH(0);
-  OUT_BATCH(0);
-  ADVANCE_BATCH();
-   }
+   /* Disable if the shader stage is inactive or there are no push constants. 
*/
+   active = active && stage_state->push_const_size != 0;
+
+   BEGIN_BATCH(7);
+   OUT_BATCH(opcode << 16 | (7 - 2));
+   OUT_BATCH(active ? stage_state->push_const_size : 0);
+   OUT_BATCH(0);
+   /* Pointer to the constant buffer.  Covered by the set of state flags
+* from gen6_prepare_wm_contants
+*/
+   OUT_BATCH(active ? (stage_state->push_const_offset | GEN7_MOCS_L3) : 0);
+   OUT_BATCH(0);
+   OUT_BATCH(0);
+   OUT_BATCH(0);
+   ADVANCE_BATCH();
 }
 
 
-- 
1.9.2

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

[Mesa-dev] [PATCH 06/11] i965/gen6: Don't update unit state when samplers change.

[Eric Anholt]

There's no remaining dependency between these two packets that I can find.
---
 src/mesa/drivers/dri/i965/gen6_vs_state.c | 2 +-
 src/mesa/drivers/dri/i965/gen6_wm_state.c | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen6_vs_state.c 
b/src/mesa/drivers/dri/i965/gen6_vs_state.c
index 0af87d1..25f55c4 100644
--- a/src/mesa/drivers/dri/i965/gen6_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_vs_state.c
@@ -218,7 +218,7 @@ const struct brw_tracked_state gen6_vs_state = {
BRW_NEW_VERTEX_PROGRAM |
BRW_NEW_BATCH |
 BRW_NEW_PUSH_CONSTANT_ALLOCATION),
-  .cache = CACHE_NEW_VS_PROG | CACHE_NEW_SAMPLER
+  .cache = CACHE_NEW_VS_PROG
},
.emit = upload_vs_state,
 };
diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c 
b/src/mesa/drivers/dri/i965/gen6_wm_state.c
index 742a52e..3f5dd29 100644
--- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
@@ -330,8 +330,7 @@ const struct brw_tracked_state gen6_wm_state = {
   .brw   = (BRW_NEW_FRAGMENT_PROGRAM |
BRW_NEW_BATCH |
 BRW_NEW_PUSH_CONSTANT_ALLOCATION),
-  .cache = (CACHE_NEW_SAMPLER |
-   CACHE_NEW_WM_PROG)
+  .cache = (CACHE_NEW_WM_PROG)
},
.emit = upload_wm_state,
 };
-- 
1.9.2

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

[Mesa-dev] [PATCH 04/11] i965: Simplify sampler setup by passing the stage state.

[Eric Anholt]

---
 src/mesa/drivers/dri/i965/brw_context.h  |  4 +---
 src/mesa/drivers/dri/i965/brw_wm_sampler_state.c | 29 +++-
 src/mesa/drivers/dri/i965/gen7_sampler_state.c   |  9 
 3 files changed, 13 insertions(+), 29 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index f30d42c..379af38 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -994,9 +994,7 @@ struct brw_context
   /** Upload a SAMPLER_STATE table. */
   void (*upload_sampler_state_table)(struct brw_context *brw,
  struct gl_program *prog,
- uint32_t sampler_count,
- uint32_t *sst_offset,
- uint32_t *sdc_offset);
+ struct brw_stage_state *stage_state);
 
   /**
* Send the appropriate state packets to configure depth, stencil, and
diff --git a/src/mesa/drivers/dri/i965/brw_wm_sampler_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_sampler_state.c
index afe952a..bbfd9e0 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_sampler_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_sampler_state.c
@@ -375,12 +375,11 @@ static void brw_update_sampler_state(struct brw_context 
*brw,
 static void
 brw_upload_sampler_state_table(struct brw_context *brw,
struct gl_program *prog,
-   uint32_t sampler_count,
-   uint32_t *sst_offset,
-   uint32_t *sdc_offset)
+   struct brw_stage_state *stage_state)
 {
struct gl_context *ctx = &brw->ctx;
struct brw_sampler_state *samplers;
+   uint32_t sampler_count = stage_state->sampler_count;
 
GLbitfield SamplersUsed = prog->SamplersUsed;
 
@@ -389,7 +388,7 @@ brw_upload_sampler_state_table(struct brw_context *brw,
 
samplers = brw_state_batch(brw, AUB_TRACE_SAMPLER_STATE,
  sampler_count * sizeof(*samplers),
- 32, sst_offset);
+ 32, &stage_state->sampler_offset);
memset(samplers, 0, sampler_count * sizeof(*samplers));
 
for (unsigned s = 0; s < sampler_count; s++) {
@@ -397,7 +396,8 @@ brw_upload_sampler_state_table(struct brw_context *brw,
  const unsigned unit = prog->SamplerUnits[s];
  if (ctx->Texture.Unit[unit]._Current)
 brw_update_sampler_state(brw, unit, s, &samplers[s],
- *sst_offset, &sdc_offset[s]);
+ stage_state->sampler_offset,
+ &stage_state->sdc_offset[s]);
   }
}
 
@@ -409,10 +409,7 @@ brw_upload_fs_samplers(struct brw_context *brw)
 {
/* BRW_NEW_FRAGMENT_PROGRAM */
struct gl_program *fs = (struct gl_program *) brw->fragment_program;
-   brw->vtbl.upload_sampler_state_table(brw, fs,
-brw->wm.base.sampler_count,
-&brw->wm.base.sampler_offset,
-brw->wm.base.sdc_offset);
+   brw->vtbl.upload_sampler_state_table(brw, fs, &brw->wm.base);
 }
 
 const struct brw_tracked_state brw_fs_samplers = {
@@ -428,14 +425,9 @@ const struct brw_tracked_state brw_fs_samplers = {
 static void
 brw_upload_vs_samplers(struct brw_context *brw)
 {
-   struct brw_stage_state *stage_state = &brw->vs.base;
-
/* BRW_NEW_VERTEX_PROGRAM */
struct gl_program *vs = (struct gl_program *) brw->vertex_program;
-   brw->vtbl.upload_sampler_state_table(brw, vs,
-stage_state->sampler_count,
-&stage_state->sampler_offset,
-stage_state->sdc_offset);
+   brw->vtbl.upload_sampler_state_table(brw, vs, &brw->vs.base);
 }
 
 
@@ -453,17 +445,12 @@ const struct brw_tracked_state brw_vs_samplers = {
 static void
 brw_upload_gs_samplers(struct brw_context *brw)
 {
-   struct brw_stage_state *stage_state = &brw->gs.base;
-
/* BRW_NEW_GEOMETRY_PROGRAM */
struct gl_program *gs = (struct gl_program *) brw->geometry_program;
if (!gs)
   return;
 
-   brw->vtbl.upload_sampler_state_table(brw, gs,
-stage_state->sampler_count,
-&stage_state->sampler_offset,
-stage_state->sdc_offset);
+   brw->vtbl.upload_sampler_state_table(brw, gs, &brw->gs.base);
 }
 
 
diff --git a/src/mesa/drivers/dri/i965/gen7_sampler_state.c 
b/src/mesa/drivers/dri/i965/gen7_sampler_state.c
index 94091d8..8eb337d 100644
--- a/src/mesa/drivers/dri/i965/gen7_sampler_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_sampler_state.c
@@ -182,12 +182,11 @@ gen7_update_sampler_state(s

[Mesa-dev] [PATCH 01/11] i965: Fix a stale comment reference

[Eric Anholt]

---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 78ccfc6..c46df17 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -279,7 +279,7 @@ struct intel_mipmap_tree
 * MESA_FORMAT_Z24_UNORM_X8_UINT.
 *
 * For ETC1/ETC2 textures, this is one of the uncompressed mesa texture
-* formats if the hardware lacks support for ETC1/ETC2. See @ref wraps_etc.
+* formats if the hardware lacks support for ETC1/ETC2. See @ref etc_format.
 */
mesa_format format;
 
-- 
1.9.2

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

[Mesa-dev] [PATCH 02/11] i965: Make batch dumping go to stderr, too.

[Eric Anholt]

All our other debug goes there.
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 5a7cfcb..818ac61 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -143,6 +143,7 @@ do_batch_dump(struct brw_context *brw)
 batch->used);
}
 
+   drm_intel_decode_set_output_file(decode, stderr);
drm_intel_decode(decode);
 
drm_intel_decode_context_free(decode);
-- 
1.9.2

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

[Mesa-dev] [PATCH 08/11] i965: Drop unnecessary state flag for units on NEW_BINDING_TABLE.

[Eric Anholt]

Commit 30259856a8a82a55c030df1ad052e505c61144bc moved the state packets to
table generation time, but forgot to make this change.  Apparently the
performance win there was about not reemitting the table pointers on
unrelated state changes.

No performance difference on cairo on glamor (n=118).
---
 src/mesa/drivers/dri/i965/gen7_gs_state.c | 1 -
 src/mesa/drivers/dri/i965/gen7_vs_state.c | 1 -
 src/mesa/drivers/dri/i965/gen7_wm_state.c | 1 -
 src/mesa/drivers/dri/i965/gen8_gs_state.c | 1 -
 src/mesa/drivers/dri/i965/gen8_ps_state.c | 1 -
 src/mesa/drivers/dri/i965/gen8_vs_state.c | 1 -
 6 files changed, 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen7_gs_state.c 
b/src/mesa/drivers/dri/i965/gen7_gs_state.c
index 06e6cf7..57d 100644
--- a/src/mesa/drivers/dri/i965/gen7_gs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_gs_state.c
@@ -189,7 +189,6 @@ const struct brw_tracked_state gen7_gs_state = {
   .mesa  = _NEW_TRANSFORM | _NEW_PROGRAM_CONSTANTS,
   .brw   = (BRW_NEW_CONTEXT |
 BRW_NEW_GEOMETRY_PROGRAM |
-BRW_NEW_GS_BINDING_TABLE |
 BRW_NEW_BATCH |
 BRW_NEW_PUSH_CONSTANT_ALLOCATION),
   .cache = CACHE_NEW_GS_PROG
diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c 
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index 6b1f680..e7fd4b5 100644
--- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
@@ -117,7 +117,6 @@ const struct brw_tracked_state gen7_vs_state = {
   .mesa  = _NEW_TRANSFORM | _NEW_PROGRAM_CONSTANTS,
   .brw   = (BRW_NEW_CONTEXT |
BRW_NEW_VERTEX_PROGRAM |
-   BRW_NEW_VS_BINDING_TABLE |
BRW_NEW_BATCH |
 BRW_NEW_PUSH_CONSTANT_ALLOCATION),
   .cache = CACHE_NEW_VS_PROG
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c 
b/src/mesa/drivers/dri/i965/gen7_wm_state.c
index 2b95ef1..972ee00 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
@@ -272,7 +272,6 @@ const struct brw_tracked_state gen7_ps_state = {
 _NEW_BUFFERS |
 _NEW_MULTISAMPLE),
   .brw   = (BRW_NEW_FRAGMENT_PROGRAM |
-   BRW_NEW_PS_BINDING_TABLE |
BRW_NEW_BATCH |
 BRW_NEW_PUSH_CONSTANT_ALLOCATION),
   .cache = (CACHE_NEW_WM_PROG)
diff --git a/src/mesa/drivers/dri/i965/gen8_gs_state.c 
b/src/mesa/drivers/dri/i965/gen8_gs_state.c
index 6baada3..6774d86 100644
--- a/src/mesa/drivers/dri/i965/gen8_gs_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_gs_state.c
@@ -126,7 +126,6 @@ const struct brw_tracked_state gen8_gs_state = {
   .mesa  = _NEW_TRANSFORM | _NEW_PROGRAM_CONSTANTS,
   .brw   = (BRW_NEW_CONTEXT |
 BRW_NEW_GEOMETRY_PROGRAM |
-BRW_NEW_GS_BINDING_TABLE |
 BRW_NEW_BATCH |
 BRW_NEW_PUSH_CONSTANT_ALLOCATION),
   .cache = CACHE_NEW_GS_PROG
diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c 
b/src/mesa/drivers/dri/i965/gen8_ps_state.c
index aa7183b..80091e8 100644
--- a/src/mesa/drivers/dri/i965/gen8_ps_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_ps_state.c
@@ -245,7 +245,6 @@ const struct brw_tracked_state gen8_ps_state = {
.dirty = {
   .mesa  = _NEW_PROGRAM_CONSTANTS | _NEW_MULTISAMPLE,
   .brw   = BRW_NEW_FRAGMENT_PROGRAM |
-   BRW_NEW_PS_BINDING_TABLE |
BRW_NEW_BATCH |
BRW_NEW_PUSH_CONSTANT_ALLOCATION,
   .cache = CACHE_NEW_WM_PROG
diff --git a/src/mesa/drivers/dri/i965/gen8_vs_state.c 
b/src/mesa/drivers/dri/i965/gen8_vs_state.c
index e7634ee..87854a3 100644
--- a/src/mesa/drivers/dri/i965/gen8_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_vs_state.c
@@ -110,7 +110,6 @@ const struct brw_tracked_state gen8_vs_state = {
   .mesa  = _NEW_TRANSFORM | _NEW_PROGRAM_CONSTANTS,
   .brw   = BRW_NEW_CONTEXT |
BRW_NEW_VERTEX_PROGRAM |
-   BRW_NEW_VS_BINDING_TABLE |
BRW_NEW_BATCH |
BRW_NEW_PUSH_CONSTANT_ALLOCATION,
   .cache = CACHE_NEW_VS_PROG
-- 
1.9.2

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

[Mesa-dev] [PATCH 03/11] i965: Move has_hiz from the slice to the level.

[Eric Anholt]

The value depends only on the level, so no need to store the bool per slice.
Shrinks intel_mipmap_slice from 24 bytes to 16, while slotting into an
existing hole in intel_mipmap_level.
---
 src/mesa/drivers/dri/i965/brw_blorp.cpp   |  2 +-
 src/mesa/drivers/dri/i965/brw_misc_state.c|  2 +-
 src/mesa/drivers/dri/i965/intel_fbo.c |  2 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 27 ---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 22 ++
 5 files changed, 25 insertions(+), 30 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp.cpp
index 57ff30a..52ddaa6 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
@@ -327,7 +327,7 @@ brw_hiz_op_params::brw_hiz_op_params(struct 
intel_mipmap_tree *mt,
x1 = depth.width;
y1 = depth.height;
 
-   assert(intel_miptree_slice_has_hiz(mt, level, layer));
+   assert(intel_miptree_level_has_hiz(mt, level));
 
switch (mt->format) {
case MESA_FORMAT_Z_UNORM16:   depth_format = BRW_DEPTHFORMAT_D16_UNORM; 
break;
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index a6b108b..e1c2bb1 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -182,7 +182,7 @@ brw_get_depthstencil_tile_masks(struct intel_mipmap_tree 
*depth_mt,
   intel_region_get_tile_masks(depth_mt->region,
   &tile_mask_x, &tile_mask_y, false);
 
-  if (intel_miptree_slice_has_hiz(depth_mt, depth_level, depth_layer)) {
+  if (intel_miptree_level_has_hiz(depth_mt, depth_level)) {
  uint32_t hiz_tile_mask_x, hiz_tile_mask_y;
  intel_region_get_tile_masks(depth_mt->hiz_mt->region,
  &hiz_tile_mask_x, &hiz_tile_mask_y, 
false);
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
b/src/mesa/drivers/dri/i965/intel_fbo.c
index f58d7c8..ea46f1d 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -887,7 +887,7 @@ intel_blit_framebuffer(struct gl_context *ctx,
 bool
 intel_renderbuffer_has_hiz(struct intel_renderbuffer *irb)
 {
-   return intel_miptree_slice_has_hiz(irb->mt, irb->mt_level, irb->mt_layer);
+   return intel_miptree_level_has_hiz(irb->mt, irb->mt_level);
 }
 
 bool
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index c24cfce..2d30606 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1271,14 +1271,13 @@ intel_miptree_alloc_non_msrt_mcs(struct brw_context 
*brw,
 
 /**
  * Helper for intel_miptree_alloc_hiz() that sets
- * \c mt->level[level].slice[layer].has_hiz. Return true if and only if
+ * \c mt->level[level].has_hiz. Return true if and only if
  * \c has_hiz was set.
  */
 static bool
-intel_miptree_slice_enable_hiz(struct brw_context *brw,
+intel_miptree_level_enable_hiz(struct brw_context *brw,
struct intel_mipmap_tree *mt,
-   uint32_t level,
-   uint32_t layer)
+   uint32_t level)
 {
assert(mt->hiz_mt);
 
@@ -1297,7 +1296,7 @@ intel_miptree_slice_enable_hiz(struct brw_context *brw,
   }
}
 
-   mt->level[level].slice[layer].has_hiz = true;
+   mt->level[level].has_hiz = true;
return true;
 }
 
@@ -1326,10 +1325,10 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
/* Mark that all slices need a HiZ resolve. */
struct intel_resolve_map *head = &mt->hiz_map;
for (int level = mt->first_level; level <= mt->last_level; ++level) {
-  for (int layer = 0; layer < mt->level[level].depth; ++layer) {
- if (!intel_miptree_slice_enable_hiz(brw, mt, level, layer))
-continue;
+  if (!intel_miptree_level_enable_hiz(brw, mt, level))
+ continue;
 
+  for (int layer = 0; layer < mt->level[level].depth; ++layer) {
 head->next = malloc(sizeof(*head->next));
 head->next->prev = head;
 head->next->next = NULL;
@@ -1348,12 +1347,10 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
  * Does the miptree slice have hiz enabled?
  */
 bool
-intel_miptree_slice_has_hiz(struct intel_mipmap_tree *mt,
-uint32_t level,
-uint32_t layer)
+intel_miptree_level_has_hiz(struct intel_mipmap_tree *mt, uint32_t level)
 {
-   intel_miptree_check_level_layer(mt, level, layer);
-   return mt->level[level].slice[layer].has_hiz;
+   intel_miptree_check_level_layer(mt, level, 0);
+   return mt->level[level].has_hiz;
 }
 
 void
@@ -1361,7 +1358,7 @@ intel_miptree_slice_set_needs_hiz_resolve(struct 
intel_mipmap_tree *mt,
  uint32_t level,
  uint32_t layer)
 {
-

[Mesa-dev] [PATCH 10/11] i965: Merge gen8_upload_constant_state into gen7_upload_constant_state.

[Eric Anholt]

The two paths are really similar, and the extra conditionals will be
dwarfed by the cost of the actual upload.
---
 src/mesa/drivers/dri/i965/brw_state.h |  5 -
 src/mesa/drivers/dri/i965/gen7_vs_state.c | 16 +---
 src/mesa/drivers/dri/i965/gen8_gs_state.c |  2 +-
 src/mesa/drivers/dri/i965/gen8_ps_state.c |  2 +-
 src/mesa/drivers/dri/i965/gen8_vs_state.c | 25 +
 5 files changed, 16 insertions(+), 34 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
b/src/mesa/drivers/dri/i965/brw_state.h
index 72478ba..b8e8520 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -269,11 +269,6 @@ gen7_upload_constant_state(struct brw_context *brw,
const struct brw_stage_state *stage_state,
bool active, unsigned opcode);
 
-/* gen8_vs_state.c */
-void
-gen8_upload_constant_state(struct brw_context *brw,
-   const struct brw_stage_state *stage_state,
-   bool active, unsigned opcode);
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c 
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index ba4a36e..a030310 100644
--- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
@@ -35,20 +35,30 @@ gen7_upload_constant_state(struct brw_context *brw,
const struct brw_stage_state *stage_state,
bool active, unsigned opcode)
 {
+   uint32_t mocs = brw->gen < 8 ? GEN7_MOCS_L3 : 0;
+
/* Disable if the shader stage is inactive or there are no push constants. 
*/
active = active && stage_state->push_const_size != 0;
 
-   BEGIN_BATCH(7);
-   OUT_BATCH(opcode << 16 | (7 - 2));
+   int dwords = brw->gen >= 8 ? 11 : 7;
+   BEGIN_BATCH(dwords);
+   OUT_BATCH(opcode << 16 | (dwords - 2));
OUT_BATCH(active ? stage_state->push_const_size : 0);
OUT_BATCH(0);
/* Pointer to the constant buffer.  Covered by the set of state flags
 * from gen6_prepare_wm_contants
 */
-   OUT_BATCH(active ? (stage_state->push_const_offset | GEN7_MOCS_L3) : 0);
+   OUT_BATCH(active ? (stage_state->push_const_offset | mocs) : 0);
OUT_BATCH(0);
OUT_BATCH(0);
OUT_BATCH(0);
+   if (brw->gen >= 8) {
+  OUT_BATCH(0);
+  OUT_BATCH(0);
+  OUT_BATCH(0);
+  OUT_BATCH(0);
+   }
+
ADVANCE_BATCH();
 }
 
diff --git a/src/mesa/drivers/dri/i965/gen8_gs_state.c 
b/src/mesa/drivers/dri/i965/gen8_gs_state.c
index 6774d86..ef25115 100644
--- a/src/mesa/drivers/dri/i965/gen8_gs_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_gs_state.c
@@ -36,7 +36,7 @@ gen8_upload_gs_state(struct brw_context *brw)
/* CACHE_NEW_GS_PROG */
const struct brw_vec4_prog_data *prog_data = &brw->gs.prog_data->base;
 
-   gen8_upload_constant_state(brw, stage_state, active, _3DSTATE_CONSTANT_GS);
+   gen7_upload_constant_state(brw, stage_state, active, _3DSTATE_CONSTANT_GS);
 
if (active) {
   int urb_entry_write_offset = 1;
diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c 
b/src/mesa/drivers/dri/i965/gen8_ps_state.c
index 80091e8..f0362a2 100644
--- a/src/mesa/drivers/dri/i965/gen8_ps_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_ps_state.c
@@ -137,7 +137,7 @@ upload_ps_state(struct brw_context *brw)
uint32_t dw3 = 0, dw6 = 0, dw7 = 0;
 
/* CACHE_NEW_WM_PROG */
-   gen8_upload_constant_state(brw, &brw->wm.base, true, _3DSTATE_CONSTANT_PS);
+   gen7_upload_constant_state(brw, &brw->wm.base, true, _3DSTATE_CONSTANT_PS);
 
/* Initialize the execution mask with VMask.  Otherwise, derivatives are
 * incorrect for subspans where some of the pixels are unlit.  We believe
diff --git a/src/mesa/drivers/dri/i965/gen8_vs_state.c 
b/src/mesa/drivers/dri/i965/gen8_vs_state.c
index 87854a3..9ac681f 100644
--- a/src/mesa/drivers/dri/i965/gen8_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_vs_state.c
@@ -29,29 +29,6 @@
 #include "program/prog_statevars.h"
 #include "intel_batchbuffer.h"
 
-void
-gen8_upload_constant_state(struct brw_context *brw,
-   const struct brw_stage_state *stage_state,
-   bool active, unsigned opcode)
-{
-   /* Disable if the shader stage is inactive or there are no push constants. 
*/
-   active = active && stage_state->push_const_size != 0;
-
-   BEGIN_BATCH(11);
-   OUT_BATCH(opcode << 16 | (11 - 2));
-   OUT_BATCH(active ? stage_state->push_const_size : 0);
-   OUT_BATCH(0);
-   OUT_BATCH(active ? stage_state->push_const_offset : 0);
-   OUT_BATCH(0);
-   OUT_BATCH(0);
-   OUT_BATCH(0);
-   OUT_BATCH(0);
-   OUT_BATCH(0);
-   OUT_BATCH(0);
-   OUT_BATCH(0);
-   ADVANCE_BATCH();
-}
-
 static void
 upload_vs_state(struct brw_context *brw)
 {
@@ -62,7 +39,7 @@ upload_vs_state(struct brw_context *brw)
/* CACHE_NEW_VS_PROG */
const struct brw_vec4_prog_data *prog_data = &brw->vs.prog_data->base;
 
-   gen8_upload_constant_state(brw

[Mesa-dev] [PATCH 05/11] i965: Drop a NEW_SAMPLER annotation for use of sampler_count.

[Eric Anholt]

The sampler count is set up from the gl_program at draw time, not at
sampler change time.
---
 src/mesa/drivers/dri/i965/gen6_wm_state.c | 1 -
 src/mesa/drivers/dri/i965/gen7_wm_state.c | 1 -
 src/mesa/drivers/dri/i965/gen8_ps_state.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c 
b/src/mesa/drivers/dri/i965/gen6_wm_state.c
index b85c146..742a52e 100644
--- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
@@ -143,7 +143,6 @@ upload_wm_state(struct brw_context *brw)
if (ctx->_Shader->CurrentProgram[MESA_SHADER_FRAGMENT] == NULL)
   dw2 |= GEN6_WM_FLOATING_POINT_MODE_ALT;
 
-   /* CACHE_NEW_SAMPLER */
dw2 |= (ALIGN(brw->wm.base.sampler_count, 4) / 4) <<
GEN6_WM_SAMPLER_COUNT_SHIFT;
 
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c 
b/src/mesa/drivers/dri/i965/gen7_wm_state.c
index 97831df..eabadee 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
@@ -154,7 +154,6 @@ upload_ps_state(struct brw_context *brw)
 
dw2 = dw4 = dw5 = 0;
 
-   /* CACHE_NEW_SAMPLER */
dw2 |=
   (ALIGN(brw->wm.base.sampler_count, 4) / 4) << 
GEN7_PS_SAMPLER_COUNT_SHIFT;
 
diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c 
b/src/mesa/drivers/dri/i965/gen8_ps_state.c
index 8d9ad64..0856060 100644
--- a/src/mesa/drivers/dri/i965/gen8_ps_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_ps_state.c
@@ -151,7 +151,6 @@ upload_ps_state(struct brw_context *brw)
 */
dw3 |= GEN7_PS_VECTOR_MASK_ENABLE;
 
-   /* CACHE_NEW_SAMPLER */
dw3 |=
   (ALIGN(brw->wm.base.sampler_count, 4) / 4) << 
GEN7_PS_SAMPLER_COUNT_SHIFT;
 
-- 
1.9.2

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

Re: [Mesa-dev] [PATCH] mesa: move declarations before code in texstore.c

[Anuj Phogat]

On Thu, May 1, 2014 at 12:05 PM, Brian Paul  wrote:
> To fix MSVC build.
> ---
>  src/mesa/main/texstore.c |   15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
> index 436e5a8..7642146 100644
> --- a/src/mesa/main/texstore.c
> +++ b/src/mesa/main/texstore.c
> @@ -2473,6 +2473,8 @@ _mesa_texstore_z24_s8(TEXSTORE_PARAMS)
> const GLint srcRowStride
>= _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType);
> GLint img, row;
> +   GLuint *depth = malloc(srcWidth * sizeof(GLuint));
> +   GLubyte *stencil = malloc(srcWidth * sizeof(GLubyte));
>
> ASSERT(dstFormat == MESA_FORMAT_S8_UINT_Z24_UNORM);
> ASSERT(srcFormat == GL_DEPTH_STENCIL_EXT ||
> @@ -2482,9 +2484,6 @@ _mesa_texstore_z24_s8(TEXSTORE_PARAMS)
>srcType == GL_UNSIGNED_INT_24_8_EXT ||
>srcType == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
>
> -   GLuint *depth = malloc(srcWidth * sizeof(GLuint));
> -   GLubyte *stencil = malloc(srcWidth * sizeof(GLubyte));
> -
> if (!depth || !stencil) {
>free(depth);
>free(stencil);
> @@ -3416,6 +3415,11 @@ _mesa_texstore_r11_g11_b10f(TEXSTORE_PARAMS)
>  static GLboolean
>  _mesa_texstore_z32f_x24s8(TEXSTORE_PARAMS)
>  {
> +   GLint img, row;
> +   const GLint srcRowStride
> +  = _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType)
> +  / sizeof(uint64_t);
> +
> ASSERT(dstFormat == MESA_FORMAT_Z32_FLOAT_S8X24_UINT);
> ASSERT(srcFormat == GL_DEPTH_STENCIL ||
>srcFormat == GL_DEPTH_COMPONENT ||
> @@ -3424,11 +3428,6 @@ _mesa_texstore_z32f_x24s8(TEXSTORE_PARAMS)
>srcType == GL_UNSIGNED_INT_24_8 ||
>srcType == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
>
> -   GLint img, row;
> -   const GLint srcRowStride
> -  = _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType)
> -  / sizeof(uint64_t);
> -
> /* In case we only upload depth we need to preserve the stencil */
> for (img = 0; img < srcDepth; img++) {
>uint64_t *dstRow = (uint64_t *) dstSlices[img];
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

Re: [Mesa-dev] [Mesa-stable] [PATCH V4 3/4] glsl: Link error if fs defines conflicting qualifiers for gl_FragCoord

[Carl Worth]

Anuj Phogat  writes:
> This patch causes the shader link to fail if we have multiple fragment
> shaders with conflicting layout qualifiers for gl_FragCoord.

Anuj,

This one has a non-trivial conflict on the 10.1 branch. Can you either
recommend skipping this one or else provide a backported patch that will
apply to the 10.1 branch?

Thanks,

-Carl


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

Re: [Mesa-dev] A candidate branch for the next stable release

[Carl Worth]

Anuj Phogat  writes:
> Today morning, I've pushed a series of patches marked for stable releases.
> It would be nice to pick them as well. Sorry for the last minute
> commits.

No problem. I'll pick these all and push as quick as I can so we can
still have 24 hours before I cut the actual release. Thanks for all the
updates.

> Fix for the test case is pushed to piglit master.

Perfect. I'll get that fix in then as well.

-Carl


pgpFTL8fCpABy.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/2] glsl: Fix redeclaration rules for gl_FragCoord.

[Chris Forbes]

OK, sounds good to me.

On Fri, May 2, 2014 at 5:55 AM, Anuj Phogat  wrote:
> On Thu, Apr 17, 2014 at 1:05 AM, Chris Forbes  wrote:
>> Correct, this doesn't try to tackle the link-time cases at all.
>>
>> After sending these out, Anuj told me that he had similar patches
>> pending review. Unfortunate to duplicate effort, but it's what I get
>> for doing a bunch of random bug-stomping, I guess :)
>>
>> Hopefully we can pick the best ideas from both series.
>>
> Chris, my series got r-b Ian. It'll be extra work to decouple compiler and
> linker patches in the series and then testing. So, I'm inclined towards
> landing my series as it is. Hope that is fine with you. We can always
> improve the compiler code later if required.
>
>> On Thu, Apr 17, 2014 at 6:29 PM, Kenneth Graunke  
>> wrote:
>>> On 04/12/2014 10:30 PM, Chris Forbes wrote:
 The ARB_fragment_coord_conventions spec, section 4.3.x (Input Layout
 Qualifiers) says:

   "All redeclarations of gl_FragCoord in all fragment shaders in a
   single program must have the same set of qualifiers. Within any
   shader, the first redeclarations of gl_FragCoord must appear before
   any use of gl_FragCoord."

 Fixes piglit's tests:
arb_fragment_coord_conventions/compiler/redeclaration-after-use
arb_fragment_coord_conventions/compiler/redeclaration-around-use

 glsl-1.50/compiler/fragment_coord_conventions/layout-qualifiers-conflicting-case-1

 glsl-1.50/compiler/fragment_coord_conventions/layout-qualifiers-conflicting-case-2

 Signed-off-by: Chris Forbes 
 ---
  src/glsl/ast_to_hir.cpp | 20 
  1 file changed, 20 insertions(+)

 diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
 index 9b9d511..d1eb3e2 100644
 --- a/src/glsl/ast_to_hir.cpp
 +++ b/src/glsl/ast_to_hir.cpp
 @@ -2715,9 +2715,29 @@ get_variable_being_redeclared(ir_variable *var, 
 YYLTYPE loc,
/* Allow redeclaration of gl_FragCoord for ARB_fcc layout
 * qualifiers.
 */
 +
 +  if (earlier->data.how_declared != ir_var_declared_implicitly
 +  && (earlier->data.origin_upper_left != 
 var->data.origin_upper_left
 + || earlier->data.pixel_center_integer != 
 var->data.pixel_center_integer)) {
 + _mesa_glsl_error(&loc, state,
 +  "Inconsistent redeclarations of gl_FragCoord");
 +  }
 +
earlier->data.origin_upper_left = var->data.origin_upper_left;
earlier->data.pixel_center_integer = var->data.pixel_center_integer;

 +  if (earlier->data.used &&
 +  earlier->data.how_declared == ir_var_declared_implicitly) {
 + /* ARB_fragment_coord_conventions spec Section 4.3.x.1
 +  * (Input Layout Qualifier) says:
 +  *
 +  * "Within any shader, the first redeclarations of gl_FragCoord
 +  * must appear before any use of gl_FragCoord."
 +  */
 + _mesa_glsl_error(&loc, state,
 +  "First redeclaration of gl_FragCoord must 
 appear before any use");
 +  }
 +
/* According to section 4.3.7 of the GLSL 1.30 spec,
 * the following built-in varaibles can be redeclared with an
 * interpolation qualifier:

>>>
>>> It seems like this will catch multiple, inconsistent redeclarations
>>> within a single fragment shader...but the spec text quoted indicates
>>> that redeclarations in all fragment shaders being linked together into a
>>> single program need to be consistent.
>>>
>>> I don't see any code to handle that in linker*.cpp, so presumably we
>>> ought to add that as well.  Regardless, this is a good improvement!
>>>
>>> Both patches are:
>>> Reviewed-by: Kenneth Graunke 
>>>
>>> Thanks, Chris.
>>>
>> ___
>> 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] mesa: move declarations before code in texstore.c

[Brian Paul]

To fix MSVC build.
---
 src/mesa/main/texstore.c |   15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 436e5a8..7642146 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -2473,6 +2473,8 @@ _mesa_texstore_z24_s8(TEXSTORE_PARAMS)
const GLint srcRowStride
   = _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType);
GLint img, row;
+   GLuint *depth = malloc(srcWidth * sizeof(GLuint));
+   GLubyte *stencil = malloc(srcWidth * sizeof(GLubyte));
 
ASSERT(dstFormat == MESA_FORMAT_S8_UINT_Z24_UNORM);
ASSERT(srcFormat == GL_DEPTH_STENCIL_EXT ||
@@ -2482,9 +2484,6 @@ _mesa_texstore_z24_s8(TEXSTORE_PARAMS)
   srcType == GL_UNSIGNED_INT_24_8_EXT ||
   srcType == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
 
-   GLuint *depth = malloc(srcWidth * sizeof(GLuint));
-   GLubyte *stencil = malloc(srcWidth * sizeof(GLubyte));
-
if (!depth || !stencil) {
   free(depth);
   free(stencil);
@@ -3416,6 +3415,11 @@ _mesa_texstore_r11_g11_b10f(TEXSTORE_PARAMS)
 static GLboolean
 _mesa_texstore_z32f_x24s8(TEXSTORE_PARAMS)
 {
+   GLint img, row;
+   const GLint srcRowStride
+  = _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType)
+  / sizeof(uint64_t);
+
ASSERT(dstFormat == MESA_FORMAT_Z32_FLOAT_S8X24_UINT);
ASSERT(srcFormat == GL_DEPTH_STENCIL ||
   srcFormat == GL_DEPTH_COMPONENT ||
@@ -3424,11 +3428,6 @@ _mesa_texstore_z32f_x24s8(TEXSTORE_PARAMS)
   srcType == GL_UNSIGNED_INT_24_8 ||
   srcType == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
 
-   GLint img, row;
-   const GLint srcRowStride
-  = _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType)
-  / sizeof(uint64_t);
-
/* In case we only upload depth we need to preserve the stencil */
for (img = 0; img < srcDepth; img++) {
   uint64_t *dstRow = (uint64_t *) dstSlices[img];
-- 
1.7.10.4

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

Re: [Mesa-dev] A candidate branch for the next stable release

[Anuj Phogat]

On Thu, May 1, 2014 at 10:44 AM, Carl Worth  wrote:
> I've recently pushed an update to the 10.1 branch. I anticipate making a
> release from this branch tomorrow. The state of this branch is
> summarized here:
>
>
> http://cworth.org/~cworth/mesa-stable-queue/
>
> As always, please let me know if I have missed something that should be
> picked over to the stable branch.
>
Today morning, I've pushed a series of patches marked for stable releases.
It would be nice to pick them as well. Sorry for the last minute commits.

> The code on this branch includes 32 commits since 10.1.1 and introduces
> no regressions as tested with piglit on my Haswell laptop. I would, of
> course, welcome any additional testing reports from users of other
> drivers.
>
> There are a couple of points of concern which, if addressed, could lead
> to some changes between now and the release:
>
>   * There are 23 patches that have been sent to the mesa-stable mailing
> list, but have not yet been merged to master. The oldest of these is
> from February 20 (10 weeks ago!).
>
> Presumably, we could use some help reviewing these patches. Please
> see the list of "Nominated, awaiting review" patches at the URL
> above.
Most of my patches in this list have now landed in to mesa master.

>
>   * I rejected one patch, (i965: Add glBlitFramebuffer to commands
> affected by conditional rendering), based on a piglit regression it
> caused. The relevant bug report:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=77702
>
> suggests that the test itself is at fault here. If that's correct,
> and the test can be updated, then this patch can be merged before
> the release.
Fix for the test case is pushed to piglit master.
>
> Thanks everyone,
>
> -Carl
>
> --
> carl.d.wo...@intel.com
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] glsl: Fix redeclaration rules for gl_FragCoord.

[Anuj Phogat]

On Thu, Apr 17, 2014 at 1:05 AM, Chris Forbes  wrote:
> Correct, this doesn't try to tackle the link-time cases at all.
>
> After sending these out, Anuj told me that he had similar patches
> pending review. Unfortunate to duplicate effort, but it's what I get
> for doing a bunch of random bug-stomping, I guess :)
>
> Hopefully we can pick the best ideas from both series.
>
Chris, my series got r-b Ian. It'll be extra work to decouple compiler and
linker patches in the series and then testing. So, I'm inclined towards
landing my series as it is. Hope that is fine with you. We can always
improve the compiler code later if required.

> On Thu, Apr 17, 2014 at 6:29 PM, Kenneth Graunke  
> wrote:
>> On 04/12/2014 10:30 PM, Chris Forbes wrote:
>>> The ARB_fragment_coord_conventions spec, section 4.3.x (Input Layout
>>> Qualifiers) says:
>>>
>>>   "All redeclarations of gl_FragCoord in all fragment shaders in a
>>>   single program must have the same set of qualifiers. Within any
>>>   shader, the first redeclarations of gl_FragCoord must appear before
>>>   any use of gl_FragCoord."
>>>
>>> Fixes piglit's tests:
>>>arb_fragment_coord_conventions/compiler/redeclaration-after-use
>>>arb_fragment_coord_conventions/compiler/redeclaration-around-use
>>>
>>> glsl-1.50/compiler/fragment_coord_conventions/layout-qualifiers-conflicting-case-1
>>>
>>> glsl-1.50/compiler/fragment_coord_conventions/layout-qualifiers-conflicting-case-2
>>>
>>> Signed-off-by: Chris Forbes 
>>> ---
>>>  src/glsl/ast_to_hir.cpp | 20 
>>>  1 file changed, 20 insertions(+)
>>>
>>> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
>>> index 9b9d511..d1eb3e2 100644
>>> --- a/src/glsl/ast_to_hir.cpp
>>> +++ b/src/glsl/ast_to_hir.cpp
>>> @@ -2715,9 +2715,29 @@ get_variable_being_redeclared(ir_variable *var, 
>>> YYLTYPE loc,
>>>/* Allow redeclaration of gl_FragCoord for ARB_fcc layout
>>> * qualifiers.
>>> */
>>> +
>>> +  if (earlier->data.how_declared != ir_var_declared_implicitly
>>> +  && (earlier->data.origin_upper_left != 
>>> var->data.origin_upper_left
>>> + || earlier->data.pixel_center_integer != 
>>> var->data.pixel_center_integer)) {
>>> + _mesa_glsl_error(&loc, state,
>>> +  "Inconsistent redeclarations of gl_FragCoord");
>>> +  }
>>> +
>>>earlier->data.origin_upper_left = var->data.origin_upper_left;
>>>earlier->data.pixel_center_integer = var->data.pixel_center_integer;
>>>
>>> +  if (earlier->data.used &&
>>> +  earlier->data.how_declared == ir_var_declared_implicitly) {
>>> + /* ARB_fragment_coord_conventions spec Section 4.3.x.1
>>> +  * (Input Layout Qualifier) says:
>>> +  *
>>> +  * "Within any shader, the first redeclarations of gl_FragCoord
>>> +  * must appear before any use of gl_FragCoord."
>>> +  */
>>> + _mesa_glsl_error(&loc, state,
>>> +  "First redeclaration of gl_FragCoord must appear 
>>> before any use");
>>> +  }
>>> +
>>>/* According to section 4.3.7 of the GLSL 1.30 spec,
>>> * the following built-in varaibles can be redeclared with an
>>> * interpolation qualifier:
>>>
>>
>> It seems like this will catch multiple, inconsistent redeclarations
>> within a single fragment shader...but the spec text quoted indicates
>> that redeclarations in all fragment shaders being linked together into a
>> single program need to be consistent.
>>
>> I don't see any code to handle that in linker*.cpp, so presumably we
>> ought to add that as well.  Regardless, this is a good improvement!
>>
>> Both patches are:
>> Reviewed-by: Kenneth Graunke 
>>
>> Thanks, Chris.
>>
> ___
> 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] i965: no more regions!

[Chad Versace]

On Tue, Apr 29, 2014 at 04:34:25PM -0700, Eric Anholt wrote:
> Here's the series for removing struct intel_region from the i965 driver.
> I think it's worth it for the code savings and reduced steps in allocating
> a miptree.  Plus, it gave me a chance to rewrite some comments about the
> driver.
> 
> It's a longer series than I wanted, but there are some nice little
> cleanups in it that hopefully make it easier to review than 18 patches
> would usually be.

The series was very easy to review in the bite-sized patches. Thanks for
breaking it up that way.

Miptrees and regions and bo's are hot data structures. Now that the
region is gone, do you expect any reduction in cache misses? Any
measurable gain in CPU-bound workloads?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 18/18] i965: Fix the file comment for intel_image.h

[Chad Versace]

On Tue, Apr 29, 2014 at 04:34:43PM -0700, Eric Anholt wrote:
> ---
>  src/mesa/drivers/dri/i965/intel_image.h | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_image.h 
> b/src/mesa/drivers/dri/i965/intel_image.h
> index ba3ed27..0cae711 100644
> --- a/src/mesa/drivers/dri/i965/intel_image.h
> +++ b/src/mesa/drivers/dri/i965/intel_image.h
> @@ -25,14 +25,17 @@
>   *
>   **/
>  
> -#ifndef INTEL_REGIONS_H
> -#define INTEL_REGIONS_H
> +#ifndef INTEL_IMAGE_H
> +#define INTEL_IMAGE_H
>  
>  /** @file intel_image.h
>   *
> - * Structure definitions and prototypes for intel_region handling,
> - * which is the basic structure for rectangular collections of pixels
> - * stored in a drm_intel_bo.
> + * Structure definitions and prototypes for __DRIimage, the driver-private
> + * structure backing EGLImage or a drawable in DRI3.
> + *
> + * The __DRIimage is passed around the loader code (src/glx and src/egl), but
> + * it's opaque to that code and may only be accessed by loader extensions
> + * (mostly located in intel_screen.c).
>   */

Oops... I should've finished reading the series before replying to patch
17.

Patch 17 and 18 are now
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 17/18] i965: Rename intel_regions.h to something more appropriate now.

[Chad Versace]

On Tue, Apr 29, 2014 at 04:34:42PM -0700, Eric Anholt wrote:

> +/** @file intel_image.h
> + *
> + * Structure definitions and prototypes for intel_region handling,
> + * which is the basic structure for rectangular collections of pixels
> + * stored in a drm_intel_bo.
> + */

The @file comment is now bogus. Kill it or replace it, and this patch is
Reviewed-by: Chad Versace  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 15/18] i965: Drop region usage from DRI2 winsys-allocated buffers.

[Chad Versace]

> On Tue, Apr 29, 2014 at 4:34 PM, Eric Anholt  wrote:

> > -   intel_region_release(&intelBuffer->region);
> > +   drm_intel_bo_unreference(&intelBuffer->bo);
> > free(intelBuffer);

This hunk passes garbage to drm_intel_bo_unreference(). Here's the GCC warning.

intel_screen.c: In function 'intelReleaseBuffer':
intel_screen.c:1428:4: warning: passing argument 1 of 
'drm_intel_bo_unreference' from incompatible pointer type [enabled by default]
drm_intel_bo_unreference(&intelBuffer->bo);
^
In file included from brw_context.h:51:0,
 from intel_batchbuffer.h:6,
 from intel_screen.c:95:
/usr/include/libdrm/intel_bufmgr.h:123:6: note: expected 'struct 
drm_intel_bo *' but argument is of type 'struct drm_intel_bo **'
 void drm_intel_bo_unreference(drm_intel_bo *bo);

Fix that and this patch is
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] A candidate branch for the next stable release

[Carl Worth]

I've recently pushed an update to the 10.1 branch. I anticipate making a
release from this branch tomorrow. The state of this branch is
summarized here:


http://cworth.org/~cworth/mesa-stable-queue/

As always, please let me know if I have missed something that should be
picked over to the stable branch.

The code on this branch includes 32 commits since 10.1.1 and introduces
no regressions as tested with piglit on my Haswell laptop. I would, of
course, welcome any additional testing reports from users of other
drivers.

There are a couple of points of concern which, if addressed, could lead
to some changes between now and the release:

  * There are 23 patches that have been sent to the mesa-stable mailing
list, but have not yet been merged to master. The oldest of these is
from February 20 (10 weeks ago!).

Presumably, we could use some help reviewing these patches. Please
see the list of "Nominated, awaiting review" patches at the URL
above.

  * I rejected one patch, (i965: Add glBlitFramebuffer to commands
affected by conditional rendering), based on a piglit regression it
caused. The relevant bug report:

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

suggests that the test itself is at fault here. If that's correct,
and the test can be updated, then this patch can be merged before
the release.

Thanks everyone,

-Carl

-- 
carl.d.wo...@intel.com


pgpf4y5Y6i6ti.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 16/18] i965: Delete the intel_regions.c code.

[Chad Versace]

On Tue, Apr 29, 2014 at 04:34:41PM -0700, Eric Anholt wrote:

>  src/mesa/drivers/dri/i965/intel_regions.c | 198 
> --

Whoo! Patches up to here are
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/18] i965: Drop use of intel_region from miptrees.

[Chad Versace]

On Tue, Apr 29, 2014 at 04:34:37PM -0700, Eric Anholt wrote:
> Note: region->width used to reflect the total_width/height padding of
> separate stencil, and mt->total_width doesn't.

The note scares me. It tells me the patch has a known, potential bug
regarding stencil buffers...  but after some digging I convinced myself
that there's no stencil bug.

Please provide some assurance in the commit message that there is no
bug. I think it's sufficient to explain that, in the patch, each
substitution of region->width with rb->Width is safe because the
renderbuffer is never a stencil buffer nor multisampled in those
functions.

Add some assurance to the commit message and this patch is
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] clover: Add a stub implementation of clCreateImage() v3

[Tom Stellard]

Now that we are uisng the OpenCL 1.2 headers, applications expect all
the OpenCL 1.2 functions to be implemented.

This fixes linking errors with the piglit CL tests.

v2:
  - Use c++ features
  - Fix error code handling

v3:
  - Move  into api/util.hpp
  - Fix indentation
---
 src/gallium/state_trackers/clover/api/dispatch.cpp |  2 +-
 src/gallium/state_trackers/clover/api/dispatch.hpp |  8 +++-
 src/gallium/state_trackers/clover/api/memory.cpp   | 12 
 src/gallium/state_trackers/clover/api/util.hpp |  1 +
 4 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp 
b/src/gallium/state_trackers/clover/api/dispatch.cpp
index 2ee6208..488e654 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.cpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
@@ -120,7 +120,7 @@ namespace clover {
   clCreateSubDevices,
   clRetainDevice,
   clReleaseDevice,
-  NULL, // clCreateImage
+  clCreateImage,
   NULL, // clCreateProgramWithBuiltInKernels
   NULL, // clCompileProgram
   NULL, // clLinkProgram
diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp 
b/src/gallium/state_trackers/clover/api/dispatch.hpp
index 833fb0e..ffae1ae 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.hpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
@@ -653,7 +653,13 @@ struct _cl_icd_dispatch {
CL_API_ENTRY cl_int (CL_API_CALL *clReleaseDevice)(
   cl_device_id device);
 
-   void *clCreateImage;
+   CL_API_ENTRY cl_mem (CL_API_CALL *clCreateImage)(
+  cl_context context,
+  cl_mem_flags flags,
+  const cl_image_format *image_format,
+  const cl_image_desc *image_desc,
+  void *host_ptr,
+  cl_int *errcode_ret);
 
CL_API_ENTRY cl_program (CL_API_CALL *clCreateProgramWithBuiltInKernels)(
   cl_context context,
diff --git a/src/gallium/state_trackers/clover/api/memory.cpp 
b/src/gallium/state_trackers/clover/api/memory.cpp
index 7ed2191..d26b1c6 100644
--- a/src/gallium/state_trackers/clover/api/memory.cpp
+++ b/src/gallium/state_trackers/clover/api/memory.cpp
@@ -334,3 +334,15 @@ clSetMemObjectDestructorCallback(cl_mem d_mem,
 } catch (error &e) {
return e.get();
 }
+
+CLOVER_API cl_mem
+clCreateImage(cl_context d_ctx, cl_mem_flags flags,
+  const cl_image_format *format,
+  const cl_image_desc *image_desc,
+  void *host_ptr, cl_int *r_errcode) {
+   // This function was added in OpenCL 1.2
+   std::cerr << "CL user error: clCreateImage() not supported by OpenCL 1.1." 
<<
+std::endl;
+   ret_error(r_errcode, CL_INVALID_OPERATION);
+   return NULL;
+}
diff --git a/src/gallium/state_trackers/clover/api/util.hpp 
b/src/gallium/state_trackers/clover/api/util.hpp
index c2b216e..918df61 100644
--- a/src/gallium/state_trackers/clover/api/util.hpp
+++ b/src/gallium/state_trackers/clover/api/util.hpp
@@ -24,6 +24,7 @@
 #define CLOVER_API_UTIL_HPP
 
 #include 
+#include 
 
 #include "core/error.hpp"
 #include "core/property.hpp"
-- 
1.8.1.4

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

[Mesa-dev] [PATCH] clover: Add a stub implementation of clCreateImage() v2

[Tom Stellard]

Now that we are uisng the OpenCL 1.2 headers, applications expect all
the OpenCL 1.2 functions to be implemented.

This fixes linking errors with the piglit CL tests.

v2:
  - Use c++ features
  - Fix error code handling
---
 src/gallium/state_trackers/clover/api/dispatch.cpp |  2 +-
 src/gallium/state_trackers/clover/api/dispatch.hpp |  8 +++-
 src/gallium/state_trackers/clover/api/memory.cpp   | 14 ++
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp 
b/src/gallium/state_trackers/clover/api/dispatch.cpp
index 2ee6208..488e654 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.cpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
@@ -120,7 +120,7 @@ namespace clover {
   clCreateSubDevices,
   clRetainDevice,
   clReleaseDevice,
-  NULL, // clCreateImage
+  clCreateImage,
   NULL, // clCreateProgramWithBuiltInKernels
   NULL, // clCompileProgram
   NULL, // clLinkProgram
diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp 
b/src/gallium/state_trackers/clover/api/dispatch.hpp
index 833fb0e..ffae1ae 100644
--- a/src/gallium/state_trackers/clover/api/dispatch.hpp
+++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
@@ -653,7 +653,13 @@ struct _cl_icd_dispatch {
CL_API_ENTRY cl_int (CL_API_CALL *clReleaseDevice)(
   cl_device_id device);
 
-   void *clCreateImage;
+   CL_API_ENTRY cl_mem (CL_API_CALL *clCreateImage)(
+  cl_context context,
+  cl_mem_flags flags,
+  const cl_image_format *image_format,
+  const cl_image_desc *image_desc,
+  void *host_ptr,
+  cl_int *errcode_ret);
 
CL_API_ENTRY cl_program (CL_API_CALL *clCreateProgramWithBuiltInKernels)(
   cl_context context,
diff --git a/src/gallium/state_trackers/clover/api/memory.cpp 
b/src/gallium/state_trackers/clover/api/memory.cpp
index 7ed2191..7619168 100644
--- a/src/gallium/state_trackers/clover/api/memory.cpp
+++ b/src/gallium/state_trackers/clover/api/memory.cpp
@@ -20,6 +20,8 @@
 // OTHER DEALINGS IN THE SOFTWARE.
 //
 
+#include 
+
 #include "util/u_math.h"
 #include "api/util.hpp"
 #include "core/memory.hpp"
@@ -334,3 +336,15 @@ clSetMemObjectDestructorCallback(cl_mem d_mem,
 } catch (error &e) {
return e.get();
 }
+
+CLOVER_API cl_mem
+clCreateImage(cl_context d_ctx, cl_mem_flags flags,
+  const cl_image_format *format,
+  const cl_image_desc *image_desc,
+  void *host_ptr, cl_int *r_errcode) {
+  // This function was added in OpenCL 1.2
+  std::cerr << "CL user error: clCreateImage() not supported by OpenCL 1.1." <<
+   std::endl;
+  ret_error(r_errcode, CL_INVALID_OPERATION);
+  return NULL;
+}
-- 
1.8.1.4

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

Re: [Mesa-dev] [PATCH 1/2] radeonsi: add support for Mullins asics.

[Tom Stellard]

On Wed, Apr 30, 2014 at 07:30:15PM -0400, Alex Deucher wrote:
> From: Samuel Li 
> 
> Signed-off-by: Samuel Li 
> Signed-off-by: Alex Deucher 
> ---
>  src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
>  src/gallium/drivers/radeonsi/si_state.c   | 2 ++
>  src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
>  src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
>  4 files changed, 6 insertions(+)
> 
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index 957186a..600f89b 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -293,6 +293,7 @@ static const char* r600_get_name(struct pipe_screen* 
> pscreen)
>   case CHIP_KAVERI: return "AMD KAVERI";
>   case CHIP_KABINI: return "AMD KABINI";
>   case CHIP_HAWAII: return "AMD HAWAII";
> + case CHIP_MULLINS: return "AMD MULLINS";
>   default: return "AMD unknown";
>   }
>  }
> @@ -410,6 +411,7 @@ const char *r600_get_llvm_processor_name(enum 
> radeon_family family)
>   case CHIP_KABINI: return "kabini";
>   case CHIP_KAVERI: return "kaveri";
>   case CHIP_HAWAII: return "hawaii";
> + case CHIP_MULLINS: return "mullins";

There will only be a mullins GPU defined in LLVM 3.5 and newer, so we
need to wrap this in:

#if HAVE_LLVM >= 0x0305
return "mullins";
#else
return "kabini";  // Or whatever already supported Sea Islands
  // chip is the closest match for mullins.
#endif

-Tom
>   default: return "";
>  #endif
>   }
> diff --git a/src/gallium/drivers/radeonsi/si_state.c 
> b/src/gallium/drivers/radeonsi/si_state.c
> index 80f54e2..6d5408b 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -3101,6 +3101,8 @@ void si_init_config(struct si_context *sctx)
>   /* XXX todo */
>   case CHIP_KABINI:
>   /* XXX todo */
> + case CHIP_MULLINS:
> + /* XXX todo */
>   default:
>   si_pm4_set_reg(pm4, R_028350_PA_SC_RASTER_CONFIG, 
> 0x);
>   si_pm4_set_reg(pm4, R_028354_PA_SC_RASTER_CONFIG_1, 
> 0x);
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c 
> b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> index 7618316..e54e79e 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> @@ -276,6 +276,7 @@ static boolean do_winsys_init(struct radeon_drm_winsys 
> *ws)
>  case CHIP_KAVERI:
>  case CHIP_KABINI:
>  case CHIP_HAWAII:
> +case CHIP_MULLINS:
>  ws->info.chip_class = CIK;
>  break;
>  }
> diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
> b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> index 1cb17bb..2d13550 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
> +++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> @@ -130,6 +130,7 @@ enum radeon_family {
>  CHIP_KAVERI,
>  CHIP_KABINI,
>  CHIP_HAWAII,
> +CHIP_MULLINS,
>  CHIP_LAST,
>  };
>  
> -- 
> 1.8.3.1
> 
> ___
> 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] clover: Add a stub implementation of clCreateImage()

[Francisco Jerez]

Francisco Jerez  writes:

> Tom Stellard  writes:
>
>> Now that we are uisng the OpenCL 1.2 headers, applications expect all
>> the OpenCL 1.2 functions to be implemented.
>>
>> This fixes linking errors with the piglit CL tests.
>> ---
>>  src/gallium/state_trackers/clover/api/dispatch.cpp |  2 +-
>>  src/gallium/state_trackers/clover/api/dispatch.hpp |  8 +++-
>>  src/gallium/state_trackers/clover/api/memory.cpp   | 11 +++
>>  3 files changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp 
>> b/src/gallium/state_trackers/clover/api/dispatch.cpp
>> index 2ee6208..488e654 100644
>> --- a/src/gallium/state_trackers/clover/api/dispatch.cpp
>> +++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
>> @@ -120,7 +120,7 @@ namespace clover {
>>clCreateSubDevices,
>>clRetainDevice,
>>clReleaseDevice,
>> -  NULL, // clCreateImage
>> +  clCreateImage,
>>NULL, // clCreateProgramWithBuiltInKernels
>>NULL, // clCompileProgram
>>NULL, // clLinkProgram
>> diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp 
>> b/src/gallium/state_trackers/clover/api/dispatch.hpp
>> index 833fb0e..ffae1ae 100644
>> --- a/src/gallium/state_trackers/clover/api/dispatch.hpp
>> +++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
>> @@ -653,7 +653,13 @@ struct _cl_icd_dispatch {
>> CL_API_ENTRY cl_int (CL_API_CALL *clReleaseDevice)(
>>cl_device_id device);
>>  
>> -   void *clCreateImage;
>> +   CL_API_ENTRY cl_mem (CL_API_CALL *clCreateImage)(
>> +  cl_context context,
>> +  cl_mem_flags flags,
>> +  const cl_image_format *image_format,
>> +  const cl_image_desc *image_desc,
>> +  void *host_ptr,
>> +  cl_int *errcode_ret);
>>  
>> CL_API_ENTRY cl_program (CL_API_CALL *clCreateProgramWithBuiltInKernels)(
>>cl_context context,
>> diff --git a/src/gallium/state_trackers/clover/api/memory.cpp 
>> b/src/gallium/state_trackers/clover/api/memory.cpp
>> index 7ed2191..977e06c 100644
>> --- a/src/gallium/state_trackers/clover/api/memory.cpp
>> +++ b/src/gallium/state_trackers/clover/api/memory.cpp
>> @@ -334,3 +334,14 @@ clSetMemObjectDestructorCallback(cl_mem d_mem,
>>  } catch (error &e) {
>> return e.get();
>>  }
>> +
>> +/* This function was added in OpenCL 1.2 */
>
> Can you put this comment inside the function and use C++-style comments
> for consistency?
>
>> +CLOVER_API cl_mem
>> +clCreateImage(cl_context d_ctx, cl_mem_flags flags,
>> +  const cl_image_format *format,
>> +  const cl_image_desc *image_desc,
>> +  void *host_ptr, cl_int *r_errcode) {
>> +  fprintf(stderr, "clCreateImage() not implemented\n");
>
> How about using the C++ standard library?
>
> |   std::cerr << "clCreateImage() not implemented." << std::endl;
>

And how about rephrasing the error message to make it clear that the
user is at fault for calling a CL 1.2 function on a CL 1.1
implementation?  E.g. "CL user error: clCreateImage() not supported by
OpenCL 1.1."

> (you'll probably have to include  e.g. from api/util.hpp)
>
>> +  *r_errcode = CL_IMAGE_FORMAT_NOT_SUPPORTED;
>
> This will cause a segfault if r_errcode is NULL.  You could call
> 'ret_error(r_errcode, CL_IMAGE_FORMAT_NOT_SUPPORTED)', but how about
> returning CL_INVALID_OPERATION instead in all cases where the user calls
> an unsupported entry-point?  That would match what the spec says when
> e.g. an image operation is called and the implementation doesn't support
> images.
>
>> +  return NULL;
>
> I think the indentation of the whole block is inconsistent?
>
> Thanks.
>
>> +}
>> -- 
>> 1.8.1.4


pgp3gNDHRmvKc.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] clover: Add a stub implementation of clCreateImage()

[Francisco Jerez]

Tom Stellard  writes:

> Now that we are uisng the OpenCL 1.2 headers, applications expect all
> the OpenCL 1.2 functions to be implemented.
>
> This fixes linking errors with the piglit CL tests.
> ---
>  src/gallium/state_trackers/clover/api/dispatch.cpp |  2 +-
>  src/gallium/state_trackers/clover/api/dispatch.hpp |  8 +++-
>  src/gallium/state_trackers/clover/api/memory.cpp   | 11 +++
>  3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp 
> b/src/gallium/state_trackers/clover/api/dispatch.cpp
> index 2ee6208..488e654 100644
> --- a/src/gallium/state_trackers/clover/api/dispatch.cpp
> +++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
> @@ -120,7 +120,7 @@ namespace clover {
>clCreateSubDevices,
>clRetainDevice,
>clReleaseDevice,
> -  NULL, // clCreateImage
> +  clCreateImage,
>NULL, // clCreateProgramWithBuiltInKernels
>NULL, // clCompileProgram
>NULL, // clLinkProgram
> diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp 
> b/src/gallium/state_trackers/clover/api/dispatch.hpp
> index 833fb0e..ffae1ae 100644
> --- a/src/gallium/state_trackers/clover/api/dispatch.hpp
> +++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
> @@ -653,7 +653,13 @@ struct _cl_icd_dispatch {
> CL_API_ENTRY cl_int (CL_API_CALL *clReleaseDevice)(
>cl_device_id device);
>  
> -   void *clCreateImage;
> +   CL_API_ENTRY cl_mem (CL_API_CALL *clCreateImage)(
> +  cl_context context,
> +  cl_mem_flags flags,
> +  const cl_image_format *image_format,
> +  const cl_image_desc *image_desc,
> +  void *host_ptr,
> +  cl_int *errcode_ret);
>  
> CL_API_ENTRY cl_program (CL_API_CALL *clCreateProgramWithBuiltInKernels)(
>cl_context context,
> diff --git a/src/gallium/state_trackers/clover/api/memory.cpp 
> b/src/gallium/state_trackers/clover/api/memory.cpp
> index 7ed2191..977e06c 100644
> --- a/src/gallium/state_trackers/clover/api/memory.cpp
> +++ b/src/gallium/state_trackers/clover/api/memory.cpp
> @@ -334,3 +334,14 @@ clSetMemObjectDestructorCallback(cl_mem d_mem,
>  } catch (error &e) {
> return e.get();
>  }
> +
> +/* This function was added in OpenCL 1.2 */

Can you put this comment inside the function and use C++-style comments
for consistency?

> +CLOVER_API cl_mem
> +clCreateImage(cl_context d_ctx, cl_mem_flags flags,
> +  const cl_image_format *format,
> +  const cl_image_desc *image_desc,
> +  void *host_ptr, cl_int *r_errcode) {
> +  fprintf(stderr, "clCreateImage() not implemented\n");

How about using the C++ standard library?

|   std::cerr << "clCreateImage() not implemented." << std::endl;

(you'll probably have to include  e.g. from api/util.hpp)

> +  *r_errcode = CL_IMAGE_FORMAT_NOT_SUPPORTED;

This will cause a segfault if r_errcode is NULL.  You could call
'ret_error(r_errcode, CL_IMAGE_FORMAT_NOT_SUPPORTED)', but how about
returning CL_INVALID_OPERATION instead in all cases where the user calls
an unsupported entry-point?  That would match what the spec says when
e.g. an image operation is called and the implementation doesn't support
images.

> +  return NULL;

I think the indentation of the whole block is inconsistent?

Thanks.

> +}
> -- 
> 1.8.1.4


pgpxsEGXCujB0.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/9] i965/fs: Add support for fs_inst::force_writemask_all on Broadwell.

[Kenneth Graunke]

On 04/30/2014 01:37 PM, Eric Anholt wrote:
> Kenneth Graunke  writes:
> 
>> This must not have existed when I wrote the original code.  The atomic
>> operation header setup code uses this.
> 
> Other than the tiny comments I had, this series is:
> 
> Reviewed-by: Eric Anholt 

As usual, you were right.  I made your recommended changes and pushed
the code.  Thanks for the review!



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