Re: [Mesa-dev] [PATCH 3/5] travis: correct libdrm required regex to also track libdrm itself

[Andres Gomez]

LGTM

Reviewed-by: Andres Gomez 

On Wed, 2017-02-01 at 22:30 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> The current regex was tracking only the libdrm_foo packages, while with
> recent changed we bumped only (and rightfully so) libdrm.
> 
> Fix the regex to track any libdrm package.
> 
> Cc: Rhys Kidd 
> Cc: Eric Anholt 
> Signed-off-by: Emil Velikov 
> ---
>  .travis.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index dfbc052a7d..e8426e96a2 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -47,7 +47,7 @@ install:
>  
># Since libdrm gets updated in configure.ac regularly, try to pick up the
># latest version from there.
> -  - for line in `grep "^LIBDRM_.*_REQUIRED=" configure.ac`; do
> +  - for line in `grep "^LIBDRM.*_REQUIRED=" configure.ac`; do
>old_ver=`echo $LIBDRM_VERSION | sed 's/libdrm-//'`;
>new_ver=`echo $line | sed 's/.*REQUIRED=//'`;
>if `echo "$old_ver,$new_ver" | tr ',' '\n' | sort -Vc 2> /dev/null`; 
> then
-- 
Br,

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

Re: [Mesa-dev] [PATCH 4/5] travis: add nearly all gallium drivers to the list

[Andres Gomez]

LGTM

Reviewed-by: Andres Gomez 

On Wed, 2017-02-01 at 22:30 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Note: we need the explicit --enable-freedreno for libdrm since the
> latter is 'smart' and disables it if building on !arm platforms.
> 
> The ilo, radeonsi and swr are explicitly left out since the former is on
> its way out, while the latter two require 'too-recent' LLVM - 3.6
> 
> Signed-off-by: Emil Velikov 
> ---
> Sadly we cannot toggle either ANV or RADV since the former requires
> memfd and the latter LLVM 3.9. Both of which are missing in the VM.
> ---
>  .travis.yml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index e8426e96a2..b5dad7f3ea 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -92,7 +92,7 @@ install:
>  
>- wget http://dri.freedesktop.org/libdrm/$LIBDRM_VERSION.tar.bz2
>- tar -jxvf $LIBDRM_VERSION.tar.bz2
> -  - (cd $LIBDRM_VERSION && ./configure --prefix=$HOME/prefix --enable-vc4 
> --enable-etnaviv-experimental-api && make install)
> +  - (cd $LIBDRM_VERSION && ./configure --prefix=$HOME/prefix --enable-vc4 
> --enable-freedreno --enable-etnaviv-experimental-api && make install)
>  
>- wget $XORG_RELEASES/lib/$LIBXSHMFENCE_VERSION.tar.bz2
>- tar -jxvf $LIBXSHMFENCE_VERSION.tar.bz2
> @@ -103,7 +103,7 @@ script:
>./autogen.sh --enable-debug
>  --with-egl-platforms=x11,drm
>  --with-dri-drivers=i915,i965,radeon,r200,swrast,nouveau
> ---with-gallium-drivers=svga,swrast,vc4,virgl,r300,r600,etnaviv,imx
> +
> --with-gallium-drivers=i915,nouveau,r300,r600,freedreno,svga,swrast,vc4,virgl,etnaviv,imx
>  --disable-llvm-shared-libs
>  ;
>make && make check;
-- 
Br,

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

Re: [Mesa-dev] [PATCH 2/5] configure.ac: add swr to the gallium drivers list.

[Andres Gomez]

LGTM

Reviewed-by: Andres Gomez 

On Wed, 2017-02-01 at 22:30 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 93e4a1a8a9..0aec5326ba 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1240,7 +1240,7 @@ GALLIUM_DRIVERS_DEFAULT="r300,r600,svga,swrast"
>  AC_ARG_WITH([gallium-drivers],
>  [AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@],
>  [comma delimited Gallium drivers list, e.g.
> -
> "i915,ilo,nouveau,r300,r600,radeonsi,freedreno,svga,swrast,vc4,virgl,etnaviv,imx"
> +
> "i915,ilo,nouveau,r300,r600,radeonsi,freedreno,svga,swrast,swr,vc4,virgl,etnaviv,imx"
>  @<:@default=r300,r600,svga,swrast@:>@])],
>  [with_gallium_drivers="$withval"],
>  [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
-- 
Br,

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

Re: [Mesa-dev] [PATCH 1/5] configure.ac: list all the dri-drivers in the help string

[Andres Gomez]

On Wed, 2017-02-01 at 22:30 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> It's unlikely that any of the additions come as a suprise to anyone
> i915, nouveau, radeon, r200). Regardless, state clearly what's
Opening parenthesis? ^

Otherwise, LGTM.

Reviewed-by: Andres Gomez 

> available.
>
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index b1fb2c3c54..93e4a1a8a9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1623,7 +1623,7 @@ dnl Which drivers to build - default is chosen by 
> platform
>  AC_ARG_WITH([dri-drivers],
>  [AS_HELP_STRING([--with-dri-drivers@<:@=DIRS...@:>@],
>  [comma delimited classic DRI drivers list, e.g.
> -"swrast,i965,radeon" @<:@default=auto@:>@])],
> +"i915,i965,nouveau,radeon,r200,swrast" @<:@default=auto@:>@])],
>  [with_dri_drivers="$withval"],
>  [with_dri_drivers=auto])
>  
-- 
Br,

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

Re: [Mesa-dev] [PATCH] mesa: disable on-disk shader cache unless supported by the driver

[Timothy Arceri]

On Thu,  2 Feb 2017 16:17:02 +1100
Timothy Arceri  wrote:

> This will stop people enabling the shader cache on drivers that
> don't support it via the env vars. Also this will be required once
> support is enabled by default to stop drivers without support from
> breaking.
> ---
>  src/mesa/main/context.c | 3 ++-
>  src/mesa/main/mtypes.h  | 3 +++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> index 7ecd241..085cec9 100644
> --- a/src/mesa/main/context.c
> +++ b/src/mesa/main/context.c
> @@ -1230,7 +1230,8 @@ _mesa_initialize_context(struct gl_context *ctx,
> memset(>TextureFormatSupported, GL_TRUE,
> sizeof(ctx->TextureFormatSupported));
>  
> -   ctx->Cache = disk_cache_create();
> +   if (ctx->Const.DiskShaderCache)

Actually I think this gets set too late from the driver. I need to think
about this some more.


> +  ctx->Cache = disk_cache_create();
>  
> switch (ctx->API) {
> case API_OPENGL_COMPAT:
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 3dcc23d..8a0c180 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3762,6 +3762,9 @@ struct gl_constants
>  
> /** GL_OES_primitive_bounding_box */
> bool NoPrimitiveBoundingBoxOutput;
> +
> +   /** Does this driver support an on-disk shader cache */
> +   bool DiskShaderCache;
>  };
>  
>  

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

[Mesa-dev] [PATCH 1/2] genxml: Add the CACHE_MODE_0 register on gen9

[Jason Ekstrand]

---
 src/intel/genxml/gen9.xml | 28 
 1 file changed, 28 insertions(+)

diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index 671322b..ec29d13 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -3471,4 +3471,32 @@
 
   
 
+  
+
+
+
+
+
+
+  
+  
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 2/2] anv: Implement the Sky Lake stencil PMA optimization

[Jason Ekstrand]

This improves the performance of Dota 2 on my Sky Lake Skull Canyon
machine by about 2-3%.
---
 src/intel/vulkan/anv_private.h |   1 +
 src/intel/vulkan/gen8_cmd_buffer.c | 155 -
 src/intel/vulkan/genX_pipeline.c   |   6 +-
 3 files changed, 156 insertions(+), 6 deletions(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 5fe4dd8..e7ad351 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1475,6 +1475,7 @@ struct anv_pipeline {
bool writes_depth;
bool depth_test_enable;
bool writes_stencil;
+   bool stencil_test_enable;
bool depth_clamp_enable;
bool kill_pixel;
 
diff --git a/src/intel/vulkan/gen8_cmd_buffer.c 
b/src/intel/vulkan/gen8_cmd_buffer.c
index b877e27..553f0c3 100644
--- a/src/intel/vulkan/gen8_cmd_buffer.c
+++ b/src/intel/vulkan/gen8_cmd_buffer.c
@@ -157,16 +157,39 @@ __emit_sf_state(struct anv_cmd_buffer *cmd_buffer)
 void
 genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer *cmd_buffer, bool enable)
 {
-#if GEN_GEN == 8
if (cmd_buffer->state.pma_fix_enabled == enable)
   return;
 
+   cmd_buffer->state.pma_fix_enabled = enable;
+
+   /* According to the Broadwell PIPE_CONTROL documentation, software should
+* emit a PIPE_CONTROL with the CS Stall and Depth Cache Flush bits set
+* prior to the LRI.  If stencil buffer writes are enabled, then a Render
+* Cache Flush is also necessary.
+*
+* The Sky Lake docs say to use a depth stall rather than a command
+* streamer stall.  However, the hardware seems to violently disagree.
+* A full command streamer stall seems to be needed in both cases.
+*/
anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
   pc.DepthCacheFlushEnable = true;
   pc.CommandStreamerStallEnable = true;
   pc.RenderTargetCacheFlushEnable = true;
}
 
+#if GEN_GEN == 9
+
+   uint32_t cache_mode;
+   anv_pack_struct(_mode, GENX(CACHE_MODE_0),
+   .STCPMAOptimizationEnable = enable,
+   .STCPMAOptimizationEnableMask = true);
+   anv_batch_emit(_buffer->batch, GENX(MI_LOAD_REGISTER_IMM), lri) {
+  lri.RegisterOffset   = GENX(CACHE_MODE_0_num);
+  lri.DataDWord= cache_mode;
+   }
+
+#elif GEN_GEN == 8
+
uint32_t cache_mode;
anv_pack_struct(_mode, GENX(CACHE_MODE_1),
.NPPMAFixEnable = enable,
@@ -178,18 +201,20 @@ genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer 
*cmd_buffer, bool enable)
   lri.DataDWord= cache_mode;
}
 
+#endif /* GEN_GEN == 8 */
+
/* After the LRI, a PIPE_CONTROL with both the Depth Stall and Depth Cache
 * Flush bits is often necessary.  We do it regardless because it's easier.
 * The render cache flush is also necessary if stencil writes are enabled.
+*
+* Again, the Sky Lake docs give a different set of flushes but the BDW
+* flushes seem to work just as well.
 */
anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
   pc.DepthStallEnable = true;
   pc.DepthCacheFlushEnable = true;
   pc.RenderTargetCacheFlushEnable = true;
}
-
-   cmd_buffer->state.pma_fix_enabled = enable;
-#endif /* GEN_GEN == 8 */
 }
 
 static inline bool
@@ -289,6 +314,124 @@ want_depth_pma_fix(struct anv_cmd_buffer *cmd_buffer)
   wm_prog_data->computed_depth_mode != PSCDEPTH_OFF;
 }
 
+static inline bool
+want_stencil_pma_fix(struct anv_cmd_buffer *cmd_buffer)
+{
+   assert(GEN_GEN == 9);
+
+   /* From the Sky Lake PRM Vol. 2c CACHE_MODE_1::STC PMA Optimization Enable:
+*
+*Clearing this bit will force the STC cache to wait for pending
+*retirement of pixels at the HZ-read stage and do the STC-test for
+*Non-promoted, R-computed and Computed depth modes instead of
+*postponing the STC-test to RCPFE.
+*
+*STC_TEST_EN = 3DSTATE_STENCIL_BUFFER::STENCIL_BUFFER_ENABLE &&
+*  3DSTATE_WM_DEPTH_STENCIL::StencilTestEnable
+*
+*STC_WRITE_EN = 3DSTATE_STENCIL_BUFFER::STENCIL_BUFFER_ENABLE &&
+*   (3DSTATE_WM_DEPTH_STENCIL::Stencil Buffer Write Enable 
&&
+*3DSTATE_DEPTH_BUFFER::STENCIL_WRITE_ENABLE)
+*
+*COMP_STC_EN = STC_TEST_EN &&
+*  3DSTATE_PS_EXTRA::PixelShaderComputesStencil
+*
+*SW parses the pipeline states to generate the following logical
+*signal indicating if PMA FIX can be enabled.
+*
+*STC_PMA_OPT =
+*   3DSTATE_WM::ForceThreadDispatch != 1 &&
+*   !(3DSTATE_RASTER::ForceSampleCount != NUMRASTSAMPLES_0) &&
+*   3DSTATE_DEPTH_BUFFER::SURFACE_TYPE != NULL &&
+*   3DSTATE_DEPTH_BUFFER::HIZ 

[Mesa-dev] [PATCH] mesa: disable on-disk shader cache unless supported by the driver

[Timothy Arceri]

This will stop people enabling the shader cache on drivers that
don't support it via the env vars. Also this will be required once
support is enabled by default to stop drivers without support from
breaking.
---
 src/mesa/main/context.c | 3 ++-
 src/mesa/main/mtypes.h  | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 7ecd241..085cec9 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1230,7 +1230,8 @@ _mesa_initialize_context(struct gl_context *ctx,
memset(>TextureFormatSupported, GL_TRUE,
  sizeof(ctx->TextureFormatSupported));
 
-   ctx->Cache = disk_cache_create();
+   if (ctx->Const.DiskShaderCache)
+  ctx->Cache = disk_cache_create();
 
switch (ctx->API) {
case API_OPENGL_COMPAT:
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 3dcc23d..8a0c180 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3762,6 +3762,9 @@ struct gl_constants
 
/** GL_OES_primitive_bounding_box */
bool NoPrimitiveBoundingBoxOutput;
+
+   /** Does this driver support an on-disk shader cache */
+   bool DiskShaderCache;
 };
 
 
-- 
2.9.3

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

[Mesa-dev] [PATCH] configure.ac: explicitly require libdrm for dri classic drivers.

[Dave Airlie]

From: Dave Airlie 

Although this might come from somewhere else require it explicitly.

Signed-off-by: Dave Airlie 
---
 configure.ac | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configure.ac b/configure.ac
index d4302bf..73a0fda 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1700,22 +1700,27 @@ if test -n "$with_dri_drivers"; then
 DRI_DIRS="$DRI_DIRS $driver"
 case "x$driver" in
 xi915)
+require_libdrm "i915"
 HAVE_I915_DRI=yes;
 PKG_CHECK_MODULES([INTEL], [libdrm_intel >= 
$LIBDRM_INTEL_REQUIRED])
 ;;
 xi965)
+require_libdrm "i965"
 HAVE_I965_DRI=yes;
 PKG_CHECK_MODULES([INTEL], [libdrm_intel >= 
$LIBDRM_INTEL_REQUIRED])
 ;;
 xnouveau)
+require_libdrm "nouveau"
 HAVE_NOUVEAU_DRI=yes;
 PKG_CHECK_MODULES([NVVIEUX], [libdrm_nouveau >= 
$LIBDRM_NVVIEUX_REQUIRED])
 ;;
 xradeon)
+require_libdrm "radeon"
 HAVE_RADEON_DRI=yes;
 PKG_CHECK_MODULES([RADEON], [libdrm_radeon >= 
$LIBDRM_RADEON_REQUIRED])
 ;;
 xr200)
+require_libdrm "r200"
 HAVE_R200_DRI=yes;
 PKG_CHECK_MODULES([RADEON], [libdrm_radeon >= 
$LIBDRM_RADEON_REQUIRED])
 ;;
-- 
2.9.3

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

[Mesa-dev] [PATCH 3/5] anv: Add support for the PMA fix on Broadwell

[Jason Ekstrand]

In order to get good performance numbers for this, I had to hack up the
driver to whack wm_prog_data::uses_kill to true to emulate a discard and
used the Sascha "shadowmapping" demo.  Setting uses_kill to true dropped
the framerate on the demo by 25-30%.  Enabling the PMA fix brought it
back up to around 90% of the original framerate.  This doesn't seem to
really impact Dota 2;  probably because it doesn't use 16-bit depth.

v2 (Jason Ekstrand): Always initialize the new pipeline variables
---
 src/intel/vulkan/TODO  |   1 -
 src/intel/vulkan/anv_cmd_buffer.c  |   1 +
 src/intel/vulkan/anv_genX.h|   3 +
 src/intel/vulkan/anv_private.h |  10 +++
 src/intel/vulkan/gen7_cmd_buffer.c |   7 ++
 src/intel/vulkan/gen8_cmd_buffer.c | 139 +
 src/intel/vulkan/genX_blorp_exec.c |   5 ++
 src/intel/vulkan/genX_cmd_buffer.c |  10 +++
 src/intel/vulkan/genX_pipeline.c   |  38 ++
 9 files changed, 213 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/TODO b/src/intel/vulkan/TODO
index 38acc0d..f8b73a1 100644
--- a/src/intel/vulkan/TODO
+++ b/src/intel/vulkan/TODO
@@ -12,5 +12,4 @@ Performance:
  - Compressed multisample support
  - Pushing pieces of UBOs?
  - Enable guardband clipping
- - pma stall workaround
  - Use soft-pin to avoid relocations
diff --git a/src/intel/vulkan/anv_cmd_buffer.c 
b/src/intel/vulkan/anv_cmd_buffer.c
index 5886fa6..a762476 100644
--- a/src/intel/vulkan/anv_cmd_buffer.c
+++ b/src/intel/vulkan/anv_cmd_buffer.c
@@ -135,6 +135,7 @@ anv_cmd_state_reset(struct anv_cmd_buffer *cmd_buffer)
state->restart_index = UINT32_MAX;
state->dynamic = default_dynamic_state;
state->need_query_wa = true;
+   state->pma_fix_enabled = false;
 
if (state->attachments != NULL) {
   vk_free(_buffer->pool->alloc, state->attachments);
diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
index d04fe38..67147b0 100644
--- a/src/intel/vulkan/anv_genX.h
+++ b/src/intel/vulkan/anv_genX.h
@@ -55,6 +55,9 @@ void genX(cmd_buffer_flush_dynamic_state)(struct 
anv_cmd_buffer *cmd_buffer);
 
 void genX(cmd_buffer_flush_compute_state)(struct anv_cmd_buffer *cmd_buffer);
 
+void genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer *cmd_buffer,
+ bool enable);
+
 void
 genX(emit_urb_setup)(struct anv_device *device, struct anv_batch *batch,
  const struct gen_l3_config *l3_config,
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 4fe3ebc..5fe4dd8 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1163,6 +1163,13 @@ struct anv_cmd_state {
bool need_query_wa;
 
/**
+* Whether or not the gen8 PMA fix is enabled.  We ensure that, at the top
+* of any command buffer it disabled by disabling it in EndCommandBuffer
+* and before invoking the secondary in ExecuteCommands.
+*/
+   bool pma_fix_enabled;
+
+   /**
 * Array length is anv_cmd_state::pass::attachment_count. Array content is
 * valid only when recording a render pass instance.
 */
@@ -1465,8 +1472,11 @@ struct anv_pipeline {
 
uint32_t cs_right_mask;
 
+   bool writes_depth;
+   bool depth_test_enable;
bool writes_stencil;
bool depth_clamp_enable;
+   bool kill_pixel;
 
struct {
   uint32_t  sf[7];
diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
b/src/intel/vulkan/gen7_cmd_buffer.c
index 013ed87..c1a25e8 100644
--- a/src/intel/vulkan/gen7_cmd_buffer.c
+++ b/src/intel/vulkan/gen7_cmd_buffer.c
@@ -260,6 +260,13 @@ genX(cmd_buffer_flush_dynamic_state)(struct anv_cmd_buffer 
*cmd_buffer)
cmd_buffer->state.dirty = 0;
 }
 
+void
+genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer *cmd_buffer,
+bool enable)
+{
+   /* The NP PMA fix doesn't exist on gen7 */
+}
+
 void genX(CmdSetEvent)(
 VkCommandBuffer commandBuffer,
 VkEvent event,
diff --git a/src/intel/vulkan/gen8_cmd_buffer.c 
b/src/intel/vulkan/gen8_cmd_buffer.c
index 8c8de62..b877e27 100644
--- a/src/intel/vulkan/gen8_cmd_buffer.c
+++ b/src/intel/vulkan/gen8_cmd_buffer.c
@@ -155,6 +155,141 @@ __emit_sf_state(struct anv_cmd_buffer *cmd_buffer)
 #endif
 
 void
+genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer *cmd_buffer, bool enable)
+{
+#if GEN_GEN == 8
+   if (cmd_buffer->state.pma_fix_enabled == enable)
+  return;
+
+   anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
+  pc.DepthCacheFlushEnable = true;
+  pc.CommandStreamerStallEnable = true;
+  

[Mesa-dev] [PATCH 1/5] anv: Disable stencil writes when both write masks are zero

[Jason Ekstrand]

The only mechanism Vulkan provides for disabling stencil writes is to set
the stencil write mask to 0.  Since that is dynamic state, we have to move
handle it late during command buffer builder.  This helps Dota2 by a couple
percent because it allows the hardware to move the depth and stencil writes
to early in more cases.

v2 (Jason Ekstrand): Always initialize the new pipeline variable
---
 src/intel/vulkan/anv_private.h | 1 +
 src/intel/vulkan/gen7_cmd_buffer.c | 4 
 src/intel/vulkan/gen8_cmd_buffer.c | 8 
 src/intel/vulkan/genX_pipeline.c   | 4 +++-
 4 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index a0cb35c..4fe3ebc 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1465,6 +1465,7 @@ struct anv_pipeline {
 
uint32_t cs_right_mask;
 
+   bool writes_stencil;
bool depth_clamp_enable;
 
struct {
diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
b/src/intel/vulkan/gen7_cmd_buffer.c
index 8d68aba..013ed87 100644
--- a/src/intel/vulkan/gen7_cmd_buffer.c
+++ b/src/intel/vulkan/gen7_cmd_buffer.c
@@ -212,6 +212,10 @@ genX(cmd_buffer_flush_dynamic_state)(struct anv_cmd_buffer 
*cmd_buffer)
 
  .BackfaceStencilTestMask = d->stencil_compare_mask.back & 0xff,
  .BackfaceStencilWriteMask = d->stencil_write_mask.back & 0xff,
+
+ .StencilBufferWriteEnable =
+(d->stencil_write_mask.front || d->stencil_write_mask.back) &&
+pipeline->writes_stencil,
   };
   GENX(DEPTH_STENCIL_STATE_pack)(NULL, depth_stencil_dw, _stencil);
 
diff --git a/src/intel/vulkan/gen8_cmd_buffer.c 
b/src/intel/vulkan/gen8_cmd_buffer.c
index ab68872..8c8de62 100644
--- a/src/intel/vulkan/gen8_cmd_buffer.c
+++ b/src/intel/vulkan/gen8_cmd_buffer.c
@@ -224,6 +224,10 @@ genX(cmd_buffer_flush_dynamic_state)(struct anv_cmd_buffer 
*cmd_buffer)
 
  .BackfaceStencilTestMask = d->stencil_compare_mask.back & 0xff,
  .BackfaceStencilWriteMask = d->stencil_write_mask.back & 0xff,
+
+ .StencilBufferWriteEnable =
+(d->stencil_write_mask.front || d->stencil_write_mask.back) &&
+pipeline->writes_stencil,
   };
   GENX(3DSTATE_WM_DEPTH_STENCIL_pack)(NULL, wm_depth_stencil_dw,
   _depth_stencil);
@@ -271,6 +275,10 @@ genX(cmd_buffer_flush_dynamic_state)(struct anv_cmd_buffer 
*cmd_buffer)
 
  .StencilReferenceValue = d->stencil_reference.front & 0xff,
  .BackfaceStencilReferenceValue = d->stencil_reference.back & 0xff,
+
+ .StencilBufferWriteEnable =
+(d->stencil_write_mask.front || d->stencil_write_mask.back) &&
+pipeline->writes_stencil,
   };
   GEN9_3DSTATE_WM_DEPTH_STENCIL_pack(NULL, dwords, _depth_stencil);
 
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 9d28466..18fe48c 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -652,12 +652,15 @@ emit_ds_state(struct anv_pipeline *pipeline,
   /* We're going to OR this together with the dynamic state.  We need
* to make sure it's initialized to something useful.
*/
+  pipeline->writes_stencil = false;
   memset(depth_stencil_dw, 0, sizeof(depth_stencil_dw));
   return;
}
 
/* VkBool32 depthBoundsTestEnable; // optional (depth_bounds_test) */
 
+   pipeline->writes_stencil = info->stencilTestEnable;
+
 #if GEN_GEN <= 7
struct GENX(DEPTH_STENCIL_STATE) depth_stencil = {
 #else
@@ -669,7 +672,6 @@ emit_ds_state(struct anv_pipeline *pipeline,
   .DoubleSidedStencilEnable = true,
 
   .StencilTestEnable = info->stencilTestEnable,
-  .StencilBufferWriteEnable = info->stencilTestEnable,
   .StencilFailOp = vk_to_gen_stencil_op[info->front.failOp],
   .StencilPassDepthPassOp = vk_to_gen_stencil_op[info->front.passOp],
   .StencilPassDepthFailOp = vk_to_gen_stencil_op[info->front.depthFailOp],
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH] configure: Only require libdrm 2.4.75 for intel.

[Dave Airlie]

On 2 February 2017 at 13:09, Emil Velikov  wrote:
> On 2 February 2017 at 02:58, Michel Dänzer  wrote:
>> On 02/02/17 09:10 AM, Emil Velikov wrote:
>>> On 1 February 2017 at 23:28, Vinson Lee  wrote:
 Fixes: b8acb6b17981 ("configure: Require libdrm >= 2.4.75")
 Signed-off-by: Vinson Lee 
>>> Are you sure that's correct ?
>>>
>>> Afaict the follow-up commits make use of updated i915_drm.h which
>>> should be provided by your distro's libdrm-dev package.
>>
>> This seems to be at the heart of the confusion here: Is i915_drm.h part
>> of libdrm or of libdrm_intel? I'd argue it's the latter, and the fact
>> that some or even all downstreams ship a single package with all libdrm*
>> headers is irrelevant. That package also contains all the libdrm_*.pc
>> files, so Vinson's patch works as intended either way.
>>
> Are you saying that there's a single -dev package [libdrm-dev] for
> everything libdrm* related ?
> That sounds like a broken distro package... which would explain some
> of the assumptions/discussions on #dri-devel :-)

That is how all distros ship it.

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

Re: [Mesa-dev] [PATCH] configure: Only require libdrm 2.4.75 for intel.

[Emil Velikov]

On 2 February 2017 at 02:58, Michel Dänzer  wrote:
> On 02/02/17 09:10 AM, Emil Velikov wrote:
>> On 1 February 2017 at 23:28, Vinson Lee  wrote:
>>> Fixes: b8acb6b17981 ("configure: Require libdrm >= 2.4.75")
>>> Signed-off-by: Vinson Lee 
>> Are you sure that's correct ?
>>
>> Afaict the follow-up commits make use of updated i915_drm.h which
>> should be provided by your distro's libdrm-dev package.
>
> This seems to be at the heart of the confusion here: Is i915_drm.h part
> of libdrm or of libdrm_intel? I'd argue it's the latter, and the fact
> that some or even all downstreams ship a single package with all libdrm*
> headers is irrelevant. That package also contains all the libdrm_*.pc
> files, so Vinson's patch works as intended either way.
>
Are you saying that there's a single -dev package [libdrm-dev] for
everything libdrm* related ?
That sounds like a broken distro package... which would explain some
of the assumptions/discussions on #dri-devel :-)

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

Re: [Mesa-dev] [PATCH] configure: Only require libdrm 2.4.75 for intel.

[Michel Dänzer]

On 02/02/17 09:10 AM, Emil Velikov wrote:
> On 1 February 2017 at 23:28, Vinson Lee  wrote:
>> Fixes: b8acb6b17981 ("configure: Require libdrm >= 2.4.75")
>> Signed-off-by: Vinson Lee 
> Are you sure that's correct ?
> 
> Afaict the follow-up commits make use of updated i915_drm.h which
> should be provided by your distro's libdrm-dev package.

This seems to be at the heart of the confusion here: Is i915_drm.h part
of libdrm or of libdrm_intel? I'd argue it's the latter, and the fact
that some or even all downstreams ship a single package with all libdrm*
headers is irrelevant. That package also contains all the libdrm_*.pc
files, so Vinson's patch works as intended either way.


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

Re: [Mesa-dev] [PATCH 5/5] travis: use both cores for make/make check

[Emil Velikov]

On 2 February 2017 at 01:27, Eric Anholt  wrote:
> Emil Velikov  writes:
>
>> From: Emil Velikov 
>>
>> The instance offers 2 cores, so use them to speed things up.
>>
>> Signed-off-by: Emil Velikov 
>
> They don't just set MAKEFLAGS in the environment?  That's weird.
>
From what I've read they don't, plus they do not provide a accurate
way to get the information.

> Looks like an alternative would be to set - MAKEFLAGS=-j2 in the "env:"
> section, but this also works.  Series is:
>
MAKEFLAGS would be better indeed. If it works I'll just go ahead with it.

> Reviewed-by: Eric Anholt 

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

Re: [Mesa-dev] [PATCH 2/2] configure: make intel require the new libdrm version, not all drivers

[Emil Velikov]

On 2 February 2017 at 02:35, Dave Airlie  wrote:
> On 2 February 2017 at 12:33, Ilia Mirkin  wrote:
>> Signed-off-by: Ilia Mirkin 
>
> For the series.
>
> Reviewed-by: Dave Airlie 
>
Guys I'm getting tired of this.

If you are to make changes in the build you _must_ ensure that things
work as expected.
Doing the nasty - "works for me and it it doesn't for you your script
is broken" is rather immature.

NACK !
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] configure: libdrm is a single package, no split different versions

[Emil Velikov]

On 2 February 2017 at 02:33, Ilia Mirkin  wrote:
> The intent of the libdrm_driver version limits has always been to not
> burden the "other" drivers with updating their libdrm unless really
> necessary. Unfortunately the configure script erroneously only checked
> the driver-specific bit and not the generic bit of libdrm as well. Fix
> this.
>
Haven't checked this explicitly, but I'm leaning that at least one
piece is broken.
If you are to change this, you must ensure that things build with the
numbers provided.

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

Re: [Mesa-dev] [PATCH 2/2] configure: make intel require the new libdrm version, not all drivers

[Dave Airlie]

On 2 February 2017 at 12:33, Ilia Mirkin  wrote:
> Signed-off-by: Ilia Mirkin 

For the series.

Reviewed-by: Dave Airlie 

> ---
>  configure.ac | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 59053a5..a648b79 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -67,10 +67,10 @@ OPENCL_VERSION=1
>  AC_SUBST([OPENCL_VERSION])
>
>  dnl Versions for external dependencies
> -LIBDRM_REQUIRED=2.4.75
> +LIBDRM_REQUIRED=2.4.66
>  LIBDRM_RADEON_REQUIRED=2.4.56
>  LIBDRM_AMDGPU_REQUIRED=2.4.63
> -LIBDRM_INTEL_REQUIRED=2.4.61
> +LIBDRM_INTEL_REQUIRED=2.4.75
>  LIBDRM_NVVIEUX_REQUIRED=2.4.66
>  LIBDRM_NOUVEAU_REQUIRED=2.4.66
>  LIBDRM_FREEDRENO_REQUIRED=2.4.74
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] configure.ac: describe what all the LIBDRM_*REQUIRED macros mean

[Emil Velikov]

From: Emil Velikov 

They are versions of the respective libdrm package. They are _not_ the
version of libdrm[.so] required for driver X.

Doing the latter will lead to combinatoric explosion and in all fairness
things will likely be broken most of the time.

To make things even more confusing the kernel UAPI is provided by libdrm
itself.

Cc: Vinson Lee 
Cc: Kenneth Graunke 
Signed-off-by: Emil Velikov 
---
Ken, you/Chad have things spot on. Yet semes like other people struggle
deeply with these.
---
 configure.ac | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/configure.ac b/configure.ac
index 92339b4a3f..e8e154b412 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,6 +67,13 @@ OPENCL_VERSION=1
 AC_SUBST([OPENCL_VERSION])
 
 dnl Versions for external dependencies
+dnl
+dnl The LIBDRM instances reference either the generic libdrm or the specific
+dnl specific libdrm-$hw.
+dnl They are _not_ "the min. libdrm required for dri/gallium/other driver 
$foo."
+dnl
+dnl Note that the "basic" ABI for $hw -> $hw_drm.h is provided by libdrm 
itself.
+dnl
 LIBDRM_REQUIRED=2.4.75
 LIBDRM_RADEON_REQUIRED=2.4.56
 LIBDRM_AMDGPU_REQUIRED=2.4.63
-- 
2.11.0

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

[Mesa-dev] [PATCH 1/2] configure: libdrm is a single package, no split different versions

[Ilia Mirkin]

The intent of the libdrm_driver version limits has always been to not
burden the "other" drivers with updating their libdrm unless really
necessary. Unfortunately the configure script erroneously only checked
the driver-specific bit and not the generic bit of libdrm as well. Fix
this.

Signed-off-by: Ilia Mirkin 
---
 configure.ac | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/configure.ac b/configure.ac
index 92339b4..59053a5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1701,23 +1701,23 @@ if test -n "$with_dri_drivers"; then
 case "x$driver" in
 xi915)
 HAVE_I915_DRI=yes;
-PKG_CHECK_MODULES([INTEL], [libdrm_intel >= 
$LIBDRM_INTEL_REQUIRED])
+PKG_CHECK_MODULES([INTEL], [libdrm >= $LIBDRM_INTEL_REQUIRED 
libdrm_intel >= $LIBDRM_INTEL_REQUIRED])
 ;;
 xi965)
 HAVE_I965_DRI=yes;
-PKG_CHECK_MODULES([INTEL], [libdrm_intel >= 
$LIBDRM_INTEL_REQUIRED])
+PKG_CHECK_MODULES([INTEL], [libdrm >= $LIBDRM_INTEL_REQUIRED 
libdrm_intel >= $LIBDRM_INTEL_REQUIRED])
 ;;
 xnouveau)
 HAVE_NOUVEAU_DRI=yes;
-PKG_CHECK_MODULES([NVVIEUX], [libdrm_nouveau >= 
$LIBDRM_NVVIEUX_REQUIRED])
+PKG_CHECK_MODULES([NVVIEUX], [libdrm >= $LIBDRM_NVVIEUX_REQUIRED 
libdrm_nouveau >= $LIBDRM_NVVIEUX_REQUIRED])
 ;;
 xradeon)
 HAVE_RADEON_DRI=yes;
-PKG_CHECK_MODULES([RADEON], [libdrm_radeon >= 
$LIBDRM_RADEON_REQUIRED])
+PKG_CHECK_MODULES([RADEON], [libdrm >= $LIBDRM_RADEON_REQUIRED 
libdrm_radeon >= $LIBDRM_RADEON_REQUIRED])
 ;;
 xr200)
 HAVE_R200_DRI=yes;
-PKG_CHECK_MODULES([RADEON], [libdrm_radeon >= 
$LIBDRM_RADEON_REQUIRED])
+PKG_CHECK_MODULES([RADEON], [libdrm >= $LIBDRM_RADEON_REQUIRED 
libdrm_radeon >= $LIBDRM_RADEON_REQUIRED])
 ;;
 xswrast)
 HAVE_SWRAST_DRI=yes;
@@ -1769,7 +1769,7 @@ if test -n "$with_vulkan_drivers"; then
 
 ;;
 xradeon)
-PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >= 
$LIBDRM_AMDGPU_REQUIRED])
+PKG_CHECK_MODULES([AMDGPU], [libdrm >= $LIBDRM_AMDGPU_REQUIRED 
libdrm_amdgpu >= $LIBDRM_AMDGPU_REQUIRED])
 radeon_llvm_check $LLVM_REQUIRED_RADV "radv"
 HAVE_RADEON_VULKAN=yes;
 ;;
@@ -2299,23 +2299,23 @@ if test -n "$with_gallium_drivers"; then
 ;;
 xi915)
 HAVE_GALLIUM_I915=yes
-PKG_CHECK_MODULES([INTEL], [libdrm_intel >= 
$LIBDRM_INTEL_REQUIRED])
+PKG_CHECK_MODULES([INTEL], [libdrm >= $LIBDRM_INTEL_REQUIRED 
libdrm_intel >= $LIBDRM_INTEL_REQUIRED])
 require_libdrm "Gallium i915"
 ;;
 xilo)
 HAVE_GALLIUM_ILO=yes
-PKG_CHECK_MODULES([INTEL], [libdrm_intel >= 
$LIBDRM_INTEL_REQUIRED])
+PKG_CHECK_MODULES([INTEL], [libdrm >= $LIBDRM_INTEL_REQUIRED 
libdrm_intel >= $LIBDRM_INTEL_REQUIRED])
 require_libdrm "Gallium i965/ilo"
 ;;
 xr300)
 HAVE_GALLIUM_R300=yes
-PKG_CHECK_MODULES([RADEON], [libdrm_radeon >= 
$LIBDRM_RADEON_REQUIRED])
+PKG_CHECK_MODULES([RADEON], [libdrm >= $LIBDRM_RADEON_REQUIRED 
libdrm_radeon >= $LIBDRM_RADEON_REQUIRED])
 require_libdrm "r300"
 r300_require_llvm "r300"
 ;;
 xr600)
 HAVE_GALLIUM_R600=yes
-PKG_CHECK_MODULES([RADEON], [libdrm_radeon >= 
$LIBDRM_RADEON_REQUIRED])
+PKG_CHECK_MODULES([RADEON], [libdrm >= $LIBDRM_RADEON_REQUIRED 
libdrm_radeon >= $LIBDRM_RADEON_REQUIRED])
 require_libdrm "r600"
 if test "x$enable_opencl" = xyes; then
 radeon_gallium_llvm_check $LLVM_REQUIRED_R600 "r600"
@@ -2326,25 +2326,25 @@ if test -n "$with_gallium_drivers"; then
 ;;
 xradeonsi)
 HAVE_GALLIUM_RADEONSI=yes
-PKG_CHECK_MODULES([RADEON], [libdrm_radeon >= 
$LIBDRM_RADEON_REQUIRED])
-PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >= 
$LIBDRM_AMDGPU_REQUIRED])
+PKG_CHECK_MODULES([RADEON], [libdrm >= $LIBDRM_RADEON_REQUIRED 
libdrm_radeon >= $LIBDRM_RADEON_REQUIRED])
+PKG_CHECK_MODULES([AMDGPU], [libdrm >= $LIBDRM_AMDGPU_REQUIRED 
libdrm_amdgpu >= $LIBDRM_AMDGPU_REQUIRED])
 require_libdrm "radeonsi"
 radeon_gallium_llvm_check $LLVM_REQUIRED_RADEONSI "radeonsi"
 require_basic_egl "radeonsi"
 ;;
 xnouveau)
 HAVE_GALLIUM_NOUVEAU=yes
-PKG_CHECK_MODULES([NOUVEAU], [libdrm_nouveau >= 
$LIBDRM_NOUVEAU_REQUIRED])
+PKG_CHECK_MODULES([NOUVEAU], [libdrm >= $LIBDRM_NOUVEAU_REQUIRED 
libdrm_nouveau >= $LIBDRM_NOUVEAU_REQUIRED])
 require_libdrm "nouveau"
 ;;
 xfreedreno)
   

[Mesa-dev] [PATCH 2/2] configure: make intel require the new libdrm version, not all drivers

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 59053a5..a648b79 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,10 +67,10 @@ OPENCL_VERSION=1
 AC_SUBST([OPENCL_VERSION])
 
 dnl Versions for external dependencies
-LIBDRM_REQUIRED=2.4.75
+LIBDRM_REQUIRED=2.4.66
 LIBDRM_RADEON_REQUIRED=2.4.56
 LIBDRM_AMDGPU_REQUIRED=2.4.63
-LIBDRM_INTEL_REQUIRED=2.4.61
+LIBDRM_INTEL_REQUIRED=2.4.75
 LIBDRM_NVVIEUX_REQUIRED=2.4.66
 LIBDRM_NOUVEAU_REQUIRED=2.4.66
 LIBDRM_FREEDRENO_REQUIRED=2.4.74
-- 
2.10.2

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

[Mesa-dev] [PATCH 5/5] anv/pipeline: Be smarter about depth/stencil state

[Jason Ekstrand]

This seemed to help Dota 2 by a percent or two.
---
 src/intel/vulkan/genX_pipeline.c | 133 +--
 1 file changed, 99 insertions(+), 34 deletions(-)

diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index f6940d2..1961874 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -634,6 +634,95 @@ static const uint32_t vk_to_gen_stencil_op[] = {
[VK_STENCIL_OP_DECREMENT_AND_WRAP]   = STENCILOP_DECR,
 };
 
+static bool
+may_write_stencil_face(const VkStencilOpState *face,
+   VkCompareOp depthCompareOp)
+{
+   return (face->compareOp != VK_COMPARE_OP_ALWAYS &&
+   face->failOp != VK_STENCIL_OP_KEEP) ||
+  (face->compareOp != VK_COMPARE_OP_NEVER &&
+   ((depthCompareOp != VK_COMPARE_OP_NEVER &&
+ face->passOp != VK_STENCIL_OP_KEEP) ||
+(depthCompareOp != VK_COMPARE_OP_ALWAYS &&
+ face->depthFailOp != VK_STENCIL_OP_KEEP)));
+}
+
+/* Intel hardware is fairly sensitive to whether or not depth/stencil writes
+ * are enabled.  In the presence of discards, disabling writes means that the
+ * depth/stencil testing can get moved earlier in the pipeline which allows it
+ * to avoid executing the fragment shader of the depth or stencil test fails.
+ *
+ * Unfortunately, the way depth and stencil testing is specified, there are
+ * many case where, regardless of depth/stencil writes being enabled, nothing
+ * actually gets written due to some other bit of state being set.  This
+ * function attempts to "sanitize" the depth stencil state and disable writes
+ * and sometimes even testing whenever possible.
+ */
+static void
+sanitize_ds_state(VkPipelineDepthStencilStateCreateInfo *state,
+  bool *stencilWriteEnable,
+  VkImageAspectFlags ds_aspects)
+{
+   *stencilWriteEnable = state->stencilTestEnable;
+
+   /* If the depth test is disabled, we won't be writing anything. */
+   if (!state->depthTestEnable)
+  state->depthWriteEnable = false;
+
+   /* The Vulkan spec requires that if either depth or stencil is not present,
+* the pipeline is to act as if the test silently passes.
+*/
+   if (!(ds_aspects & VK_IMAGE_ASPECT_DEPTH_BIT)) {
+  state->depthWriteEnable = false;
+  state->depthCompareOp = VK_COMPARE_OP_ALWAYS;
+   }
+
+   if (!(ds_aspects & VK_IMAGE_ASPECT_STENCIL_BIT)) {
+  *stencilWriteEnable = false;
+  state->front.compareOp = VK_COMPARE_OP_ALWAYS;
+  state->back.compareOp = VK_COMPARE_OP_ALWAYS;
+   }
+
+   /* If the stencil test is enabled and always fails, then we will never get
+* to the depth test so we can just disable the depth test entirely.
+*/
+   if (state->stencilTestEnable &&
+   state->front.compareOp == VK_COMPARE_OP_NEVER &&
+   state->back.compareOp == VK_COMPARE_OP_NEVER) {
+  state->depthTestEnable = false;
+  state->depthWriteEnable = false;
+   }
+
+   /* If depthCompareOp is EQUAL then the value we would be writing to the
+* depth buffer is the same as the value that's already there so there's no
+* point in writing it.
+*/
+   if (state->depthCompareOp == VK_COMPARE_OP_EQUAL)
+  state->depthWriteEnable = false;
+
+   /* If the stencil ops are such that we don't actually ever modify the
+* stencil buffer, we should disable writes.
+*/
+   if (!may_write_stencil_face(>front, state->depthCompareOp) &&
+   !may_write_stencil_face(>back, state->depthCompareOp))
+  *stencilWriteEnable = false;
+
+   /* If the depth test always passes and we never write out depth, that's the
+* same as if the depth test is disabled entirely.
+*/
+   if (state->depthCompareOp == VK_COMPARE_OP_ALWAYS &&
+   !state->depthWriteEnable)
+  state->depthTestEnable = false;
+
+   /* If the stencil test always passes and we never write out stencil, that's
+* the same as if the stencil test is disabled entirely.
+*/
+   if (state->front.compareOp == VK_COMPARE_OP_ALWAYS &&
+   state->back.compareOp == VK_COMPARE_OP_ALWAYS &&
+   !*stencilWriteEnable)
+  state->stencilTestEnable = false;
+}
+
 static void
 emit_ds_state(struct anv_pipeline *pipeline,
   const VkPipelineDepthStencilStateCreateInfo *pCreateInfo,
@@ -656,12 +745,20 @@ emit_ds_state(struct anv_pipeline *pipeline,
   return;
}
 
+   VkImageAspectFlags ds_aspects = 0;
+   if (subpass->depth_stencil_attachment != VK_ATTACHMENT_UNUSED) {
+  VkFormat depth_stencil_format =
+ pass->attachments[subpass->depth_stencil_attachment].format;
+  ds_aspects = vk_format_aspects(depth_stencil_format);
+   }
+
VkPipelineDepthStencilStateCreateInfo info = *pCreateInfo;
+   sanitize_ds_state(, >writes_stencil, ds_aspects);
+   pipeline->writes_depth = info.depthWriteEnable;
+   pipeline->depth_test_enable = info.depthTestEnable;
 
/* VkBool32 depthBoundsTestEnable; // optional (depth_bounds_test) 

[Mesa-dev] [PATCH 3/5] anv: Add support for the PMA fix on Broadwell

[Jason Ekstrand]

In order to get good performance numbers for this, I had to hack up the
driver to whack wm_prog_data::uses_kill to true to emulate a discard and
used the Sascha "shadowmapping" demo.  Setting uses_kill to true dropped
the framerate on the demo by 25-30%.  Enabling the PMA fix brought it
back up to around 90% of the original framerate.  This doesn't seem to
really impact Dota 2;  probably because it doesn't use 16-bit depth.
---
 src/intel/vulkan/TODO  |   1 -
 src/intel/vulkan/anv_cmd_buffer.c  |   1 +
 src/intel/vulkan/anv_genX.h|   3 +
 src/intel/vulkan/anv_private.h |  10 +++
 src/intel/vulkan/gen7_cmd_buffer.c |   7 ++
 src/intel/vulkan/gen8_cmd_buffer.c | 139 +
 src/intel/vulkan/genX_blorp_exec.c |   5 ++
 src/intel/vulkan/genX_cmd_buffer.c |  10 +++
 src/intel/vulkan/genX_pipeline.c   |  36 ++
 9 files changed, 211 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/TODO b/src/intel/vulkan/TODO
index 38acc0d..f8b73a1 100644
--- a/src/intel/vulkan/TODO
+++ b/src/intel/vulkan/TODO
@@ -12,5 +12,4 @@ Performance:
  - Compressed multisample support
  - Pushing pieces of UBOs?
  - Enable guardband clipping
- - pma stall workaround
  - Use soft-pin to avoid relocations
diff --git a/src/intel/vulkan/anv_cmd_buffer.c 
b/src/intel/vulkan/anv_cmd_buffer.c
index 5886fa6..a762476 100644
--- a/src/intel/vulkan/anv_cmd_buffer.c
+++ b/src/intel/vulkan/anv_cmd_buffer.c
@@ -135,6 +135,7 @@ anv_cmd_state_reset(struct anv_cmd_buffer *cmd_buffer)
state->restart_index = UINT32_MAX;
state->dynamic = default_dynamic_state;
state->need_query_wa = true;
+   state->pma_fix_enabled = false;
 
if (state->attachments != NULL) {
   vk_free(_buffer->pool->alloc, state->attachments);
diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
index d04fe38..67147b0 100644
--- a/src/intel/vulkan/anv_genX.h
+++ b/src/intel/vulkan/anv_genX.h
@@ -55,6 +55,9 @@ void genX(cmd_buffer_flush_dynamic_state)(struct 
anv_cmd_buffer *cmd_buffer);
 
 void genX(cmd_buffer_flush_compute_state)(struct anv_cmd_buffer *cmd_buffer);
 
+void genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer *cmd_buffer,
+ bool enable);
+
 void
 genX(emit_urb_setup)(struct anv_device *device, struct anv_batch *batch,
  const struct gen_l3_config *l3_config,
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 4fe3ebc..5fe4dd8 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1163,6 +1163,13 @@ struct anv_cmd_state {
bool need_query_wa;
 
/**
+* Whether or not the gen8 PMA fix is enabled.  We ensure that, at the top
+* of any command buffer it disabled by disabling it in EndCommandBuffer
+* and before invoking the secondary in ExecuteCommands.
+*/
+   bool pma_fix_enabled;
+
+   /**
 * Array length is anv_cmd_state::pass::attachment_count. Array content is
 * valid only when recording a render pass instance.
 */
@@ -1465,8 +1472,11 @@ struct anv_pipeline {
 
uint32_t cs_right_mask;
 
+   bool writes_depth;
+   bool depth_test_enable;
bool writes_stencil;
bool depth_clamp_enable;
+   bool kill_pixel;
 
struct {
   uint32_t  sf[7];
diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
b/src/intel/vulkan/gen7_cmd_buffer.c
index 013ed87..c1a25e8 100644
--- a/src/intel/vulkan/gen7_cmd_buffer.c
+++ b/src/intel/vulkan/gen7_cmd_buffer.c
@@ -260,6 +260,13 @@ genX(cmd_buffer_flush_dynamic_state)(struct anv_cmd_buffer 
*cmd_buffer)
cmd_buffer->state.dirty = 0;
 }
 
+void
+genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer *cmd_buffer,
+bool enable)
+{
+   /* The NP PMA fix doesn't exist on gen7 */
+}
+
 void genX(CmdSetEvent)(
 VkCommandBuffer commandBuffer,
 VkEvent event,
diff --git a/src/intel/vulkan/gen8_cmd_buffer.c 
b/src/intel/vulkan/gen8_cmd_buffer.c
index 8c8de62..b877e27 100644
--- a/src/intel/vulkan/gen8_cmd_buffer.c
+++ b/src/intel/vulkan/gen8_cmd_buffer.c
@@ -155,6 +155,141 @@ __emit_sf_state(struct anv_cmd_buffer *cmd_buffer)
 #endif
 
 void
+genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer *cmd_buffer, bool enable)
+{
+#if GEN_GEN == 8
+   if (cmd_buffer->state.pma_fix_enabled == enable)
+  return;
+
+   anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
+  pc.DepthCacheFlushEnable = true;
+  pc.CommandStreamerStallEnable = true;
+  pc.RenderTargetCacheFlushEnable = true;
+   }
+
+   uint32_t cache_mode;
+   

[Mesa-dev] [PATCH 0/5] anv: Implement the depth PMA fix on Broadwell

[Jason Ekstrand]

This little series does a few little cleanups as well as implements the PMA
fix on Broadwell.  The cleanups are focussed around letting us not set
3DSTATE_WM_DEPTH_STENCIL::Depth/StencilBufferWriteEnable unless we
absolutely need to.  It turns out that Intel hardware makes early/late
depth test decisions based on these bits and enabling depth or stencil
writes when not needed can cause performance problems.

I also have patches for the Sky Lake stencil PMA fix but I'm seeing hangs
in Dota 2 so I won't send those out until we figure out why.

Jason Ekstrand (5):
  anv: Disable stencil writes when both write masks are zero
  genxml: Add the CACHE_MODE_1 register on gen8
  anv: Add support for the PMA fix on Broadwell
  anv/pipeline: Make a copy of VkPipelineDepthStencilStateCreateinfo
  anv/pipeline: Be smarter about depth/stencil state

 src/intel/genxml/gen8.xml  |  21 
 src/intel/vulkan/TODO  |   1 -
 src/intel/vulkan/anv_cmd_buffer.c  |   1 +
 src/intel/vulkan/anv_genX.h|   3 +
 src/intel/vulkan/anv_private.h |  11 +++
 src/intel/vulkan/gen7_cmd_buffer.c |  11 +++
 src/intel/vulkan/gen8_cmd_buffer.c | 147 
 src/intel/vulkan/genX_blorp_exec.c |   5 +
 src/intel/vulkan/genX_cmd_buffer.c |  10 ++
 src/intel/vulkan/genX_pipeline.c   | 192 -
 10 files changed, 357 insertions(+), 45 deletions(-)

-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 2/5] genxml: Add the CACHE_MODE_1 register on gen8

[Jason Ekstrand]

---
 src/intel/genxml/gen8.xml | 21 +
 1 file changed, 21 insertions(+)

diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 970e637..32ed764 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -3200,4 +3200,25 @@
 
   
 
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 1/5] anv: Disable stencil writes when both write masks are zero

[Jason Ekstrand]

The only mechanism Vulkan provides for disabling stencil writes is to set
the stencil write mask to 0.  Since that is dynamic state, we have to move
handle it late during command buffer builder.  This helps Dota2 by a couple
percent because it allows the hardware to move the depth and stencil writes
to early in more cases.
---
 src/intel/vulkan/anv_private.h | 1 +
 src/intel/vulkan/gen7_cmd_buffer.c | 4 
 src/intel/vulkan/gen8_cmd_buffer.c | 8 
 src/intel/vulkan/genX_pipeline.c   | 3 ++-
 4 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index a0cb35c..4fe3ebc 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1465,6 +1465,7 @@ struct anv_pipeline {
 
uint32_t cs_right_mask;
 
+   bool writes_stencil;
bool depth_clamp_enable;
 
struct {
diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
b/src/intel/vulkan/gen7_cmd_buffer.c
index 8d68aba..013ed87 100644
--- a/src/intel/vulkan/gen7_cmd_buffer.c
+++ b/src/intel/vulkan/gen7_cmd_buffer.c
@@ -212,6 +212,10 @@ genX(cmd_buffer_flush_dynamic_state)(struct anv_cmd_buffer 
*cmd_buffer)
 
  .BackfaceStencilTestMask = d->stencil_compare_mask.back & 0xff,
  .BackfaceStencilWriteMask = d->stencil_write_mask.back & 0xff,
+
+ .StencilBufferWriteEnable =
+(d->stencil_write_mask.front || d->stencil_write_mask.back) &&
+pipeline->writes_stencil,
   };
   GENX(DEPTH_STENCIL_STATE_pack)(NULL, depth_stencil_dw, _stencil);
 
diff --git a/src/intel/vulkan/gen8_cmd_buffer.c 
b/src/intel/vulkan/gen8_cmd_buffer.c
index ab68872..8c8de62 100644
--- a/src/intel/vulkan/gen8_cmd_buffer.c
+++ b/src/intel/vulkan/gen8_cmd_buffer.c
@@ -224,6 +224,10 @@ genX(cmd_buffer_flush_dynamic_state)(struct anv_cmd_buffer 
*cmd_buffer)
 
  .BackfaceStencilTestMask = d->stencil_compare_mask.back & 0xff,
  .BackfaceStencilWriteMask = d->stencil_write_mask.back & 0xff,
+
+ .StencilBufferWriteEnable =
+(d->stencil_write_mask.front || d->stencil_write_mask.back) &&
+pipeline->writes_stencil,
   };
   GENX(3DSTATE_WM_DEPTH_STENCIL_pack)(NULL, wm_depth_stencil_dw,
   _depth_stencil);
@@ -271,6 +275,10 @@ genX(cmd_buffer_flush_dynamic_state)(struct anv_cmd_buffer 
*cmd_buffer)
 
  .StencilReferenceValue = d->stencil_reference.front & 0xff,
  .BackfaceStencilReferenceValue = d->stencil_reference.back & 0xff,
+
+ .StencilBufferWriteEnable =
+(d->stencil_write_mask.front || d->stencil_write_mask.back) &&
+pipeline->writes_stencil,
   };
   GEN9_3DSTATE_WM_DEPTH_STENCIL_pack(NULL, dwords, _depth_stencil);
 
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 9d28466..32be151 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -658,6 +658,8 @@ emit_ds_state(struct anv_pipeline *pipeline,
 
/* VkBool32 depthBoundsTestEnable; // optional (depth_bounds_test) */
 
+   pipeline->writes_stencil = info->stencilTestEnable;
+
 #if GEN_GEN <= 7
struct GENX(DEPTH_STENCIL_STATE) depth_stencil = {
 #else
@@ -669,7 +671,6 @@ emit_ds_state(struct anv_pipeline *pipeline,
   .DoubleSidedStencilEnable = true,
 
   .StencilTestEnable = info->stencilTestEnable,
-  .StencilBufferWriteEnable = info->stencilTestEnable,
   .StencilFailOp = vk_to_gen_stencil_op[info->front.failOp],
   .StencilPassDepthPassOp = vk_to_gen_stencil_op[info->front.passOp],
   .StencilPassDepthFailOp = vk_to_gen_stencil_op[info->front.depthFailOp],
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 4/5] anv/pipeline: Make a copy of VkPipelineDepthStencilStateCreateinfo

[Jason Ekstrand]

---
 src/intel/vulkan/genX_pipeline.c | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index a7b294f..f6940d2 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -636,7 +636,7 @@ static const uint32_t vk_to_gen_stencil_op[] = {
 
 static void
 emit_ds_state(struct anv_pipeline *pipeline,
-  const VkPipelineDepthStencilStateCreateInfo *info,
+  const VkPipelineDepthStencilStateCreateInfo *pCreateInfo,
   const struct anv_render_pass *pass,
   const struct anv_subpass *subpass)
 {
@@ -648,7 +648,7 @@ emit_ds_state(struct anv_pipeline *pipeline,
 #  define depth_stencil_dw pipeline->gen9.wm_depth_stencil
 #endif
 
-   if (info == NULL) {
+   if (pCreateInfo == NULL) {
   /* We're going to OR this together with the dynamic state.  We need
* to make sure it's initialized to something useful.
*/
@@ -656,29 +656,31 @@ emit_ds_state(struct anv_pipeline *pipeline,
   return;
}
 
+   VkPipelineDepthStencilStateCreateInfo info = *pCreateInfo;
+
/* VkBool32 depthBoundsTestEnable; // optional (depth_bounds_test) */
 
-   pipeline->writes_stencil = info->stencilTestEnable;
+   pipeline->writes_stencil = info.stencilTestEnable;
 
 #if GEN_GEN <= 7
struct GENX(DEPTH_STENCIL_STATE) depth_stencil = {
 #else
struct GENX(3DSTATE_WM_DEPTH_STENCIL) depth_stencil = {
 #endif
-  .DepthTestEnable = info->depthTestEnable,
-  .DepthBufferWriteEnable = info->depthWriteEnable,
-  .DepthTestFunction = vk_to_gen_compare_op[info->depthCompareOp],
+  .DepthTestEnable = info.depthTestEnable,
+  .DepthBufferWriteEnable = info.depthWriteEnable,
+  .DepthTestFunction = vk_to_gen_compare_op[info.depthCompareOp],
   .DoubleSidedStencilEnable = true,
 
-  .StencilTestEnable = info->stencilTestEnable,
-  .StencilFailOp = vk_to_gen_stencil_op[info->front.failOp],
-  .StencilPassDepthPassOp = vk_to_gen_stencil_op[info->front.passOp],
-  .StencilPassDepthFailOp = vk_to_gen_stencil_op[info->front.depthFailOp],
-  .StencilTestFunction = vk_to_gen_compare_op[info->front.compareOp],
-  .BackfaceStencilFailOp = vk_to_gen_stencil_op[info->back.failOp],
-  .BackfaceStencilPassDepthPassOp = 
vk_to_gen_stencil_op[info->back.passOp],
-  .BackfaceStencilPassDepthFailOp 
=vk_to_gen_stencil_op[info->back.depthFailOp],
-  .BackfaceStencilTestFunction = 
vk_to_gen_compare_op[info->back.compareOp],
+  .StencilTestEnable = info.stencilTestEnable,
+  .StencilFailOp = vk_to_gen_stencil_op[info.front.failOp],
+  .StencilPassDepthPassOp = vk_to_gen_stencil_op[info.front.passOp],
+  .StencilPassDepthFailOp = vk_to_gen_stencil_op[info.front.depthFailOp],
+  .StencilTestFunction = vk_to_gen_compare_op[info.front.compareOp],
+  .BackfaceStencilFailOp = vk_to_gen_stencil_op[info.back.failOp],
+  .BackfaceStencilPassDepthPassOp = vk_to_gen_stencil_op[info.back.passOp],
+  .BackfaceStencilPassDepthFailOp 
=vk_to_gen_stencil_op[info.back.depthFailOp],
+  .BackfaceStencilTestFunction = vk_to_gen_compare_op[info.back.compareOp],
};
 
VkImageAspectFlags aspects = 0;
@@ -707,7 +709,7 @@ emit_ds_state(struct anv_pipeline *pipeline,
 *"If Depth_Test_Enable = 1 AND Depth_Test_func = EQUAL, the
 *Depth_Write_Enable must be set to 0."
 */
-   if (info->depthTestEnable && info->depthCompareOp == VK_COMPARE_OP_EQUAL)
+   if (info.depthTestEnable && info.depthCompareOp == VK_COMPARE_OP_EQUAL)
   depth_stencil.DepthBufferWriteEnable = false;
 
pipeline->writes_depth = depth_stencil.DepthBufferWriteEnable;
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] Samping GL_R32UI?

[Roland Scheidegger]

Am 01.02.2017 um 05:32 schrieb Andrew A.:
> Are there any known issues with using usampler2D on a GL_R32UI texture
> in llvmpipe from within a VS/FS? I'm getting expected results on
> Nvidia drivers (proprietary), but not with mesa llvmpipe (always get
> zero).

Not that I know of. There should be plenty of tests testing this.
My best guess is your texture is incomplete - nvidia is known to ignore
this for some cases but mesa would not.
This would affect all mesa drivers presumably, not just llvmpipe.
(This silent "non-error condition" is quite nasty and non-obvious in
some cases - for instance if you use texelFetch which ignores all
ordinary texture parameters such as wrap modes or filtering, however
according to OpenGL rules the texture would still be incomplete
depending on min/mag filter - and I know nvidia would ignore this
particular case.)

Roland

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

Re: [Mesa-dev] [PATCH 5/5] travis: use both cores for make/make check

[Eric Anholt]

Emil Velikov  writes:

> From: Emil Velikov 
>
> The instance offers 2 cores, so use them to speed things up.
>
> Signed-off-by: Emil Velikov 

They don't just set MAKEFLAGS in the environment?  That's weird.

Looks like an alternative would be to set - MAKEFLAGS=-j2 in the "env:"
section, but this also works.  Series is:

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] anv/pass: Store the depth-stencil attachment's last subpass index

[Nanley Chery]

Commit 968ffd6c868af7226e8f889573eef709888151cb stored the last subpass
index of all the attachments but that of the depth-stencil attachment.
This could cause depth buffers used in multiple subpasses not to be in
the requested final layout. Fix this error.

Cc: "17.0" 
Signed-off-by: Nanley Chery 
---
 src/intel/vulkan/anv_pass.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/vulkan/anv_pass.c b/src/intel/vulkan/anv_pass.c
index 5df6330c6a..2df18260d3 100644
--- a/src/intel/vulkan/anv_pass.c
+++ b/src/intel/vulkan/anv_pass.c
@@ -172,6 +172,7 @@ VkResult anv_CreateRenderPass(
 pass->attachments[a].usage |=
VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT;
 pass->attachments[a].subpass_usage[i] |= ANV_SUBPASS_USAGE_DRAW;
+pass->attachments[a].last_subpass_idx = i;
  }
   } else {
  subpass->depth_stencil_attachment = VK_ATTACHMENT_UNUSED;
-- 
2.11.0

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

Re: [Mesa-dev] [PATCHv2 3/4] configure.ac: Separate HAVE_LLVM defines for gallium and radv

[Emil Velikov]

On 2 February 2017 at 00:36, Dave Airlie  wrote:
> On 2 February 2017 at 10:06, Emil Velikov  wrote:
>> On 2 February 2017 at 00:00, Dave Airlie  wrote:
>>> On 2 February 2017 at 09:58, Emil Velikov  wrote:
 On 1 February 2017 at 22:19, Dave Airlie  wrote:
> Just make radv depend on enable-gallium-llvm.
>
> I really don't want to make the #defines into the spaghetti this 
> introduces.
>
 Not a huge fan of it either.

 We need these for 17.0 and flipping things in a feature freeze period
 is iffy. For 17.1.x we'll remove this and a lot more nasty code by
 superseding --enable-gallium-llvm in favour of --enable-llvm.
>>>
>>> Why do we need it, just make radv not build if enable-gallium-llvm
>>> isn't specified.
>>>
>> Because that's the way things worked since day 1 - maybe it was an
>> oversight, maybe a bug, other.
>> All I'm asking is for a week or so of patience after which this messy
>> code, plus more, will be gone. Please ?
>
> It's going to make backporting stable fixes to 17.0 more error prone,
> lots more error prone
I can put some beers on the line that if there's anything error prone
in the backports it won't related to any of these ;-)

Atm _every_ mesa branch has the LLVM bits broken in one way or
another. Pulling --enable-gallium-llvm won't magically fix things.
I've already addressed 'everything' and although trivial the on their
own, the patches depend on these.
Not to mention I've been spinning like crazy nearly a dozen different
build combinations.

> and I don't want that. Anything that touches
> HAVE_LLVM vs MESA_HAVE_LLVM in the codebase, Not nice.
>
Agreed it's _not_ pretty. In the [very unlikely] case of this causing
issues, I'll be the person looking into it ;-)

> Who care what used to work, just make the reality sane for release.
>
"Who care what used to work" is not nice either :-\

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

Re: [Mesa-dev] [PATCH] docs: add link to http://mesamatrix.net/

[Timothy Arceri]

On Wed, 2017-02-01 at 14:36 -0700, Brian Paul wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95460
> ---
>  docs/features.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/docs/features.txt b/docs/features.txt
> index 55b1fbb..300442b 100644
> --- a/docs/features.txt
> +++ b/docs/features.txt
> @@ -335,3 +335,6 @@ we DO NOT WANT implementations of these
> extensions for Mesa.
>  
>  More info about these features and the work involved can be found at
>  http://dri.freedesktop.org/wiki/MissingFunctionality

Shouldn't we remove the above link? It hasn't been updated in years.
IMO that whole wiki page should probably be deleted.


> +
> +Also, a graphical representation of this information can be found at
> +http://mesamatrix.net/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Samping GL_R32UI?

[Andrew A.]

Are there any known issues with using usampler2D on a GL_R32UI texture
in llvmpipe from within a VS/FS? I'm getting expected results on
Nvidia drivers (proprietary), but not with mesa llvmpipe (always get
zero).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Only require libdrm 2.4.75 for intel.

[Emil Velikov]

On 2 February 2017 at 00:38, Vinson Lee  wrote:
> On Wed, Feb 1, 2017 at 4:10 PM, Emil Velikov  wrote:
>> On 1 February 2017 at 23:28, Vinson Lee  wrote:
>>> Fixes: b8acb6b17981 ("configure: Require libdrm >= 2.4.75")
>>> Signed-off-by: Vinson Lee 
>> Are you sure that's correct ?
>>
>> Afaict the follow-up commits make use of updated i915_drm.h which
>> should be provided by your distro's libdrm-dev package.
>> Or perhaps it used some new libdrm_intel functionality - can you list
>> what flags up on your end ?
>>
>> -Emil
>
> Yes, this allows me to build non-Intel drivers again with older
> libdrm. Do any drivers other than Intel drivers need libdrm 2.4.75?

Sounds like you misread what I said.

As of
commit 358661c794573b9a361309d477fe09880773ef73
Author: Chad Versace 
Date:   Fri Jan 13 10:46:48 2017 -0800

i965: Add intel_screen::has_fence_fd

This bool maps to I915_PARAM_HAS_EXEC_FENCE_FD.

we use the i915_drm.h define I915_PARAM_HAS_EXEC_FENCE. The latter is
provided by libdrm commit

commit a3d715ee14b29d2680ceaf44955679205795140c
Author: Chris Wilson 
Date:   Fri Jan 27 10:39:10 2017 +

Import uapi/i915_drm.h from v4.10-rc5-950-g152d5750dda9

To sync with "drm/i915: Support explicit fencing for execbuf"

i915_drm.h _must_ be part of your libdrm-dev package. If not, it's
broken and you should report to your distro.

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

Re: [Mesa-dev] [PATCH 2/2] radv/ac: move to using shared emit_ddxy code.

[Bas Nieuwenhuizen]

For the series:

Reviewed-by: Bas Nieuwenhuizen 

On Thu, Feb 2, 2017, at 00:56, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 75
>  -
>  1 file changed, 7 insertions(+), 68 deletions(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 45aeaf7..e8dc752 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1171,44 +1171,13 @@ static LLVMValueRef emit_unpack_half_2x16(struct
> nir_to_llvm_context *ctx,
>   return result;
>  }
>  
> -/*
> - * SI implements derivatives using the local data store (LDS)
> - * All writes to the LDS happen in all executing threads at
> - * the same time. TID is the Thread ID for the current
> - * thread and is a value between 0 and 63, representing
> - * the thread's position in the wavefront.
> - *
> - * For the pixel shader threads are grouped into quads of four pixels.
> - * The TIDs of the pixels of a quad are:
> - *
> - *  +--+--+
> - *  |4n + 0|4n + 1|
> - *  +--+--+
> - *  |4n + 2|4n + 3|
> - *  +--+--+
> - *
> - * So, masking the TID with 0xfffc yields the TID of the top left
> pixel
> - * of the quad, masking with 0xfffd yields the TID of the top pixel
> of
> - * the current pixel's column, and masking with 0xfffe yields the
> TID
> - * of the left pixel of the current pixel's row.
> - *
> - * Adding 1 yields the TID of the pixel to the right of the left pixel,
> and
> - * adding 2 yields the TID of the pixel below the top pixel.
> - */
> -/* masks for thread ID. */
> -#define TID_MASK_TOP_LEFT 0xfffc
> -#define TID_MASK_TOP  0xfffd
> -#define TID_MASK_LEFT 0xfffe
>  static LLVMValueRef emit_ddxy(struct nir_to_llvm_context *ctx,
> nir_op op,
> LLVMValueRef src0)
>  {
> -   LLVMValueRef tl, trbl, result;
> -   LLVMValueRef tl_tid, trbl_tid;
> -   LLVMValueRef args[2];
> -   LLVMValueRef thread_id;
>   unsigned mask;
>   int idx;
> +   LLVMValueRef result;
>   ctx->has_ddxy = true;
>  
>   if (!ctx->lds && !ctx->has_ds_bpermute)
> @@ -1216,16 +1185,13 @@ static LLVMValueRef emit_ddxy(struct
> nir_to_llvm_context *ctx,
>  LLVMArrayType(ctx->i32, 
> 64),
>  "ddxy_lds", 
> LOCAL_ADDR_SPACE);
>  
> -   thread_id = ac_get_thread_id(>ac);
>   if (op == nir_op_fddx_fine || op == nir_op_fddx)
> -   mask = TID_MASK_LEFT;
> +   mask = AC_TID_MASK_LEFT;
>   else if (op == nir_op_fddy_fine || op == nir_op_fddy)
> -   mask = TID_MASK_TOP;
> +   mask = AC_TID_MASK_TOP;
>   else
> -   mask = TID_MASK_TOP_LEFT;
> +   mask = AC_TID_MASK_TOP_LEFT;
>  
> -   tl_tid = LLVMBuildAnd(ctx->builder, thread_id,
> - LLVMConstInt(ctx->i32, mask, false), "");
>   /* for DDX we want to next X pixel, DDY next Y pixel. */
>   if (op == nir_op_fddx_fine ||
>   op == nir_op_fddx_coarse ||
> @@ -1234,36 +1200,9 @@ static LLVMValueRef emit_ddxy(struct
> nir_to_llvm_context *ctx,
>   else
>   idx = 2;
>  
> -   trbl_tid = LLVMBuildAdd(ctx->builder, tl_tid,
> -   LLVMConstInt(ctx->i32, idx, false), "");
> -
> -   if (ctx->has_ds_bpermute) {
> -   args[0] = LLVMBuildMul(ctx->builder, tl_tid,
> -  LLVMConstInt(ctx->i32, 4, false),
> "");
> -   args[1] = src0;
> -   tl = ac_emit_llvm_intrinsic(>ac,
> "llvm.amdgcn.ds.bpermute",
> -ctx->i32, args, 2,
> -AC_FUNC_ATTR_READNONE);
> -
> -   args[0] = LLVMBuildMul(ctx->builder, trbl_tid,
> -  LLVMConstInt(ctx->i32, 4, false),
> "");
> -   trbl = ac_emit_llvm_intrinsic(>ac,
> "llvm.amdgcn.ds.bpermute",
> -  ctx->i32, args, 2,
> -  AC_FUNC_ATTR_READNONE);
> -   } else {
> -   LLVMValueRef store_ptr, load_ptr0, load_ptr1;
> -
> -   store_ptr = ac_build_gep0(>ac, ctx->lds, thread_id);
> -   load_ptr0 = ac_build_gep0(>ac, ctx->lds, tl_tid);
> -   load_ptr1 = ac_build_gep0(>ac, ctx->lds, trbl_tid);
> -
> -   LLVMBuildStore(ctx->builder, src0, store_ptr);
> -   tl = LLVMBuildLoad(ctx->builder, load_ptr0, "");
> -   trbl = LLVMBuildLoad(ctx->builder, load_ptr1, "");
> -   }
> -   tl = LLVMBuildBitCast(ctx->builder, tl, ctx->f32, "");
> -   trbl = LLVMBuildBitCast(ctx->builder, trbl, ctx->f32, "");
> -   

[Mesa-dev] [Bug 99633] rasterizer/core/clip.h:279:49: error: ‘const struct API_STATE’ has no member named ‘linkageCount’

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

   Keywords||bisected
Version|git |13.0

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

Re: [Mesa-dev] [PATCH] configure: Only require libdrm 2.4.75 for intel.

[Vinson Lee]

On Wed, Feb 1, 2017 at 4:10 PM, Emil Velikov  wrote:
> On 1 February 2017 at 23:28, Vinson Lee  wrote:
>> Fixes: b8acb6b17981 ("configure: Require libdrm >= 2.4.75")
>> Signed-off-by: Vinson Lee 
> Are you sure that's correct ?
>
> Afaict the follow-up commits make use of updated i915_drm.h which
> should be provided by your distro's libdrm-dev package.
> Or perhaps it used some new libdrm_intel functionality - can you list
> what flags up on your end ?
>
> -Emil

Yes, this allows me to build non-Intel drivers again with older
libdrm. Do any drivers other than Intel drivers need libdrm 2.4.75?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radv/ac: use shared thread id code

[Bas Nieuwenhuizen]

For the series:

Reviewed-by: Bas Nieuwenhuizen 

On Thu, Feb 2, 2017, at 00:41, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 44
>  ++---
>  1 file changed, 2 insertions(+), 42 deletions(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 7a26333..45aeaf7 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -135,7 +135,6 @@ struct nir_to_llvm_context {
>   LLVMValueRef f32one;
>   LLVMValueRef v4f32empty;
>  
> -   unsigned range_md_kind;
>   unsigned uniform_md_kind;
>   LLVMValueRef empty_md;
>   gl_shader_stage stage;
> @@ -703,8 +702,6 @@ static void setup_types(struct nir_to_llvm_context
> *ctx)
>   args[3] = ctx->f32one;
>   ctx->v4f32empty = LLVMConstVector(args, 4);
>  
> -   ctx->range_md_kind = LLVMGetMDKindIDInContext(ctx->context,
> - "range", 5);
>   ctx->uniform_md_kind =
>   LLVMGetMDKindIDInContext(ctx->context, "amdgpu.uniform", 14);
>   ctx->empty_md = LLVMMDNodeInContext(ctx->context, NULL, 0);
> @@ -1174,43 +1171,6 @@ static LLVMValueRef emit_unpack_half_2x16(struct
> nir_to_llvm_context *ctx,
>   return result;
>  }
>  
> -/**
> - * Set range metadata on an instruction.  This can only be used on load
> and
> - * call instructions.  If you know an instruction can only produce the
> values
> - * 0, 1, 2, you would do set_range_metadata(value, 0, 3);
> - * \p lo is the minimum value inclusive.
> - * \p hi is the maximum value exclusive.
> - */
> -static void set_range_metadata(struct nir_to_llvm_context *ctx,
> -  LLVMValueRef value, unsigned lo, unsigned
> hi)
> -{
> -   LLVMValueRef range_md, md_args[2];
> -   LLVMTypeRef type = LLVMTypeOf(value);
> -   LLVMContextRef context = LLVMGetTypeContext(type);
> -
> -   md_args[0] = LLVMConstInt(type, lo, false);
> -   md_args[1] = LLVMConstInt(type, hi, false);
> -   range_md = LLVMMDNodeInContext(context, md_args, 2);
> -   LLVMSetMetadata(value, ctx->range_md_kind, range_md);
> -}
> -
> -static LLVMValueRef get_thread_id(struct nir_to_llvm_context *ctx)
> -{
> -   LLVMValueRef tid;
> -   LLVMValueRef tid_args[2];
> -   tid_args[0] = LLVMConstInt(ctx->i32, 0x, false);
> -   tid_args[1] = ctx->i32zero;
> -   tid_args[1] = ac_emit_llvm_intrinsic(>ac,
> - "llvm.amdgcn.mbcnt.lo",
> ctx->i32,
> - tid_args, 2,
> AC_FUNC_ATTR_READNONE);
> -
> -   tid = ac_emit_llvm_intrinsic(>ac,
> - "llvm.amdgcn.mbcnt.hi", ctx->i32,
> - tid_args, 2, AC_FUNC_ATTR_READNONE);
> -   set_range_metadata(ctx, tid, 0, 64);
> -   return tid;
> -}
> -
>  /*
>   * SI implements derivatives using the local data store (LDS)
>   * All writes to the LDS happen in all executing threads at
> @@ -1256,7 +1216,7 @@ static LLVMValueRef emit_ddxy(struct
> nir_to_llvm_context *ctx,
>  LLVMArrayType(ctx->i32, 
> 64),
>  "ddxy_lds", 
> LOCAL_ADDR_SPACE);
>  
> -   thread_id = get_thread_id(ctx);
> +   thread_id = ac_get_thread_id(>ac);
>   if (op == nir_op_fddx_fine || op == nir_op_fddx)
>   mask = TID_MASK_LEFT;
>   else if (op == nir_op_fddy_fine || op == nir_op_fddy)
> @@ -2876,7 +2836,7 @@ static LLVMValueRef
>  visit_load_local_invocation_index(struct nir_to_llvm_context *ctx)
>  {
>   LLVMValueRef result;
> -   LLVMValueRef thread_id = get_thread_id(ctx);
> +   LLVMValueRef thread_id = ac_get_thread_id(>ac);
>   result = LLVMBuildAnd(ctx->builder, ctx->tg_size,
> LLVMConstInt(ctx->i32, 0xfc0, false), "");
>  
> -- 
> 2.9.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCHv2 3/4] configure.ac: Separate HAVE_LLVM defines for gallium and radv

[Dave Airlie]

On 2 February 2017 at 10:06, Emil Velikov  wrote:
> On 2 February 2017 at 00:00, Dave Airlie  wrote:
>> On 2 February 2017 at 09:58, Emil Velikov  wrote:
>>> On 1 February 2017 at 22:19, Dave Airlie  wrote:
 Just make radv depend on enable-gallium-llvm.

 I really don't want to make the #defines into the spaghetti this 
 introduces.

>>> Not a huge fan of it either.
>>>
>>> We need these for 17.0 and flipping things in a feature freeze period
>>> is iffy. For 17.1.x we'll remove this and a lot more nasty code by
>>> superseding --enable-gallium-llvm in favour of --enable-llvm.
>>
>> Why do we need it, just make radv not build if enable-gallium-llvm
>> isn't specified.
>>
> Because that's the way things worked since day 1 - maybe it was an
> oversight, maybe a bug, other.
> All I'm asking is for a week or so of patience after which this messy
> code, plus more, will be gone. Please ?

It's going to make backporting stable fixes to 17.0 more error prone,
lots more error prone and I don't want that. Anything that touches
HAVE_LLVM vs MESA_HAVE_LLVM in the codebase, Not nice.

Who care what used to work, just make the reality sane for release.

If there is a bug report, close it saying just fix your build scripts.

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

Re: [Mesa-dev] [PATCH] radv/ac: migrate to using shared code for some load/store stuff.

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Thu, Feb 2, 2017, at 00:19, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This migrates to the code shared with radeonsi.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 128
>  +---
>  1 file changed, 28 insertions(+), 100 deletions(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 11a8490..6882674 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -407,78 +407,6 @@ static LLVMValueRef unpack_param(struct
> nir_to_llvm_context *ctx,
>   return value;
>  }
>  
> -static LLVMValueRef build_gep0(struct nir_to_llvm_context *ctx,
> -  LLVMValueRef base_ptr, LLVMValueRef index)
> -{
> -   LLVMValueRef indices[2] = {
> -   ctx->i32zero,
> -   index,
> -   };
> -   return LLVMBuildGEP(ctx->builder, base_ptr,
> -   indices, 2, "");
> -}
> -
> -static LLVMValueRef build_indexed_load(struct nir_to_llvm_context *ctx,
> -  LLVMValueRef base_ptr,
> LLVMValueRef index,
> -  bool uniform)
> -{
> -   LLVMValueRef pointer;
> -   pointer = build_gep0(ctx, base_ptr, index);
> -   if (uniform)
> -   LLVMSetMetadata(pointer, ctx->uniform_md_kind,
> ctx->empty_md);
> -   return LLVMBuildLoad(ctx->builder, pointer, "");
> -}
> -
> -static LLVMValueRef build_indexed_load_const(struct nir_to_llvm_context
> *ctx,
> -LLVMValueRef base_ptr,
> LLVMValueRef index)
> -{
> -   LLVMValueRef result = build_indexed_load(ctx, base_ptr, index,
> true);
> -   LLVMSetMetadata(result, ctx->invariant_load_md_kind,
> ctx->empty_md);
> -   return result;
> -}
> -
> -static void build_tbuffer_store(struct nir_to_llvm_context *ctx,
> -   LLVMValueRef rsrc,
> -   LLVMValueRef vdata,
> -   unsigned num_channels,
> -   LLVMValueRef vaddr,
> -   LLVMValueRef soffset,
> -   unsigned inst_offset,
> -   unsigned dfmt,
> -   unsigned nfmt,
> -   unsigned offen,
> -   unsigned idxen,
> -   unsigned glc,
> -   unsigned slc,
> -   unsigned tfe)
> -{
> -   LLVMValueRef args[] = {
> -   rsrc,
> -   vdata,
> -   LLVMConstInt(ctx->i32, num_channels, 0),
> -   vaddr,
> -   soffset,
> -   LLVMConstInt(ctx->i32, inst_offset, 0),
> -   LLVMConstInt(ctx->i32, dfmt, 0),
> -   LLVMConstInt(ctx->i32, nfmt, 0),
> -   LLVMConstInt(ctx->i32, offen, 0),
> -   LLVMConstInt(ctx->i32, idxen, 0),
> -   LLVMConstInt(ctx->i32, glc, 0),
> -   LLVMConstInt(ctx->i32, slc, 0),
> -   LLVMConstInt(ctx->i32, tfe, 0)
> -   };
> -
> -   /* The intrinsic is overloaded, we need to add a type suffix for
> overloading to work. */
> -   unsigned func = CLAMP(num_channels, 1, 3) - 1;
> -   const char *types[] = {"i32", "v2i32", "v4i32"};
> -   char name[256];
> -   snprintf(name, sizeof(name), "llvm.SI.tbuffer.store.%s",
> types[func]);
> -
> -   ac_emit_llvm_intrinsic(>ac, name, ctx->voidt,
> -   args, ARRAY_SIZE(args), 0);
> -
> -}
> -
>  static void set_userdata_location(struct ac_userdata_info *ud_info,
>  uint8_t sgpr_idx, uint8_t num_sgprs)
>  {
>   ud_info->sgpr_idx = sgpr_idx;
> @@ -1368,9 +1296,9 @@ static LLVMValueRef emit_ddxy(struct
> nir_to_llvm_context *ctx,
>   } else {
>   LLVMValueRef store_ptr, load_ptr0, load_ptr1;
>  
> -   store_ptr = build_gep0(ctx, ctx->lds, thread_id);
> -   load_ptr0 = build_gep0(ctx, ctx->lds, tl_tid);
> -   load_ptr1 = build_gep0(ctx, ctx->lds, trbl_tid);
> +   store_ptr = ac_build_gep0(>ac, ctx->lds, thread_id);
> +   load_ptr0 = ac_build_gep0(>ac, ctx->lds, tl_tid);
> +   load_ptr1 = ac_build_gep0(>ac, ctx->lds, trbl_tid);
>  
>   LLVMBuildStore(ctx->builder, src0, store_ptr);
>   tl = LLVMBuildLoad(ctx->builder, load_ptr0, "");
> @@ -1980,7 +1908,7 @@ static LLVMValueRef
> visit_vulkan_resource_index(struct nir_to_llvm_context *ctx,
>   index = LLVMBuildMul(ctx->builder, index, stride, "");
>   offset = LLVMBuildAdd(ctx->builder, offset, index, "");
>   
> -   desc_ptr = build_gep0(ctx, desc_ptr, offset);
> +   desc_ptr = ac_build_gep0(>ac, desc_ptr, offset);
>  

Re: [Mesa-dev] [PATCH 2/2] radeonsi/ac: move tbuffer store and buffer load to shared code.

[Bas Nieuwenhuizen]

For the series:

Reviewed-by: Bas Nieuwenhuizen 

On Thu, Feb 2, 2017, at 00:15, Dave Airlie wrote:
> From: Dave Airlie 
> 
> These are all reuseable by radv.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_llvm_util.c| 154 +
>  src/amd/common/ac_llvm_util.h|  44 +-
>  src/gallium/drivers/radeonsi/si_shader.c | 225
>  ++-
>  3 files changed, 237 insertions(+), 186 deletions(-)
> 
> diff --git a/src/amd/common/ac_llvm_util.c
> b/src/amd/common/ac_llvm_util.c
> index 43eeaac..36ecbb1 100644
> --- a/src/amd/common/ac_llvm_util.c
> +++ b/src/amd/common/ac_llvm_util.c
> @@ -35,6 +35,8 @@
>  #include "util/bitscan.h"
>  #include "util/macros.h"
>  
> +#include "sid.h"
> +
>  static void ac_init_llvm_target()
>  {
>  #if HAVE_LLVM < 0x0307
> @@ -157,8 +159,14 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
> LLVMContextRef context)
>   ctx->module = NULL;
>   ctx->builder = NULL;
>  
> +   ctx->voidt = LLVMVoidTypeInContext(ctx->context);
> +   ctx->i1 = LLVMInt1TypeInContext(ctx->context);
> +   ctx->i8 = LLVMInt8TypeInContext(ctx->context);
>   ctx->i32 = LLVMIntTypeInContext(ctx->context, 32);
>   ctx->f32 = LLVMFloatTypeInContext(ctx->context);
> +   ctx->v4i32 = LLVMVectorType(ctx->i32, 4);
> +   ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
> +   ctx->v16i8 = LLVMVectorType(ctx->i8, 16);
>  
>   ctx->invariant_load_md_kind = LLVMGetMDKindIDInContext(ctx->context,
>  
> "invariant.load", 14);
> @@ -648,3 +656,149 @@ ac_build_indexed_load_const(struct ac_llvm_context
> *ctx,
>   LLVMSetMetadata(result, ctx->invariant_load_md_kind, ctx->empty_md);
>   return result;
>  }
> +
> +/* TBUFFER_STORE_FORMAT_{X,XY,XYZ,XYZW} <- the suffix is selected by
> num_channels=1..4.
> + * The type of vdata must be one of i32 (num_channels=1), v2i32
> (num_channels=2),
> + * or v4i32 (num_channels=3,4). */
> +void
> +ac_build_tbuffer_store(struct ac_llvm_context *ctx,
> +  LLVMValueRef rsrc,
> +  LLVMValueRef vdata,
> +  unsigned num_channels,
> +  LLVMValueRef vaddr,
> +  LLVMValueRef soffset,
> +  unsigned inst_offset,
> +  unsigned dfmt,
> +  unsigned nfmt,
> +  unsigned offen,
> +  unsigned idxen,
> +  unsigned glc,
> +  unsigned slc,
> +  unsigned tfe)
> +{
> +   LLVMValueRef args[] = {
> +   rsrc,
> +   vdata,
> +   LLVMConstInt(ctx->i32, num_channels, 0),
> +   vaddr,
> +   soffset,
> +   LLVMConstInt(ctx->i32, inst_offset, 0),
> +   LLVMConstInt(ctx->i32, dfmt, 0),
> +   LLVMConstInt(ctx->i32, nfmt, 0),
> +   LLVMConstInt(ctx->i32, offen, 0),
> +   LLVMConstInt(ctx->i32, idxen, 0),
> +   LLVMConstInt(ctx->i32, glc, 0),
> +   LLVMConstInt(ctx->i32, slc, 0),
> +   LLVMConstInt(ctx->i32, tfe, 0)
> +   };
> +
> +   /* The instruction offset field has 12 bits */
> +   assert(offen || inst_offset < (1 << 12));
> +
> +   /* The intrinsic is overloaded, we need to add a type suffix for
> overloading to work. */
> +   unsigned func = CLAMP(num_channels, 1, 3) - 1;
> +   const char *types[] = {"i32", "v2i32", "v4i32"};
> +   char name[256];
> +   snprintf(name, sizeof(name), "llvm.SI.tbuffer.store.%s",
> types[func]);
> +
> +   ac_emit_llvm_intrinsic(ctx, name, ctx->voidt,
> +  args, ARRAY_SIZE(args), 0);
> +}
> +
> +void
> +ac_build_tbuffer_store_dwords(struct ac_llvm_context *ctx,
> + LLVMValueRef rsrc,
> + LLVMValueRef vdata,
> + unsigned num_channels,
> + LLVMValueRef vaddr,
> + LLVMValueRef soffset,
> + unsigned inst_offset)
> +{
> +   static unsigned dfmt[] = {
> +   V_008F0C_BUF_DATA_FORMAT_32,
> +   V_008F0C_BUF_DATA_FORMAT_32_32,
> +   V_008F0C_BUF_DATA_FORMAT_32_32_32,
> +   V_008F0C_BUF_DATA_FORMAT_32_32_32_32
> +   };
> +   assert(num_channels >= 1 && num_channels <= 4);
> +
> +   ac_build_tbuffer_store(ctx, rsrc, vdata, num_channels, vaddr,
> soffset,
> +  inst_offset, dfmt[num_channels-1],
> +  V_008F0C_BUF_NUM_FORMAT_UINT, 1, 0, 1, 1,
> 0);
> +}
> +
> +LLVMValueRef
> +ac_build_buffer_load(struct ac_llvm_context *ctx,
> +LLVMValueRef rsrc,
> +int 

[Mesa-dev] [Bug 99633] rasterizer/core/clip.h:279:49: error: ‘const struct API_STATE’ has no member named ‘linkageCount’

[bugzilla-daemon]

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

--- Comment #3 from Emil Velikov  ---
The member in question was removed with

commit efdaf5fa3e74ca4f3d9217dc6955aef6dc698a68
Author: Tim Rowley 
Date:   Tue Jul 12 15:03:42 2016 -0600

swr: [rasterizer] attribute swizzling and linkage

Add support for enhanced attribute swizzling. Currently supports constant
source overrides to handle PrimitiveID support. No support yet for input
select swizzling or wrap shortest. Removes obsoleted linkageMask and
associated code.


It have gone unnoticed, most likely, since the function Clipper::ClipScalar()
[which references the member] is unused, so the optimiser would have dropped it
all together without even attempting to compile it.

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

Re: [Mesa-dev] [PATCH] configure: Only require libdrm 2.4.75 for intel.

[Emil Velikov]

On 1 February 2017 at 23:28, Vinson Lee  wrote:
> Fixes: b8acb6b17981 ("configure: Require libdrm >= 2.4.75")
> Signed-off-by: Vinson Lee 
Are you sure that's correct ?

Afaict the follow-up commits make use of updated i915_drm.h which
should be provided by your distro's libdrm-dev package.
Or perhaps it used some new libdrm_intel functionality - can you list
what flags up on your end ?

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

Re: [Mesa-dev] [PATCH 2/5] intel/isl: Add a supports_ccs_d helper

[Anuj Phogat]

On Wed, Feb 1, 2017 at 2:40 PM, Jason Ekstrand  wrote:
> Nothing uses this yet but it serves as a nice bit of documentation
> that's relatively easy to find.
> ---
>  src/intel/isl/isl.h|  2 ++
>  src/intel/isl/isl_format.c | 15 +++
>  2 files changed, 17 insertions(+)
>
> diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> index bdc5ebf..47e4a1e 100644
> --- a/src/intel/isl/isl.h
> +++ b/src/intel/isl/isl.h
> @@ -1040,6 +1040,8 @@ bool isl_format_supports_filtering(const struct 
> gen_device_info *devinfo,
> enum isl_format format);
>  bool isl_format_supports_vertex_fetch(const struct gen_device_info *devinfo,
>enum isl_format format);
> +bool isl_format_supports_ccs_d(const struct gen_device_info *devinfo,
> +   enum isl_format format);
>  bool isl_format_supports_ccs_e(const struct gen_device_info *devinfo,
> enum isl_format format);
>  bool isl_format_supports_multisampling(const struct gen_device_info *devinfo,
> diff --git a/src/intel/isl/isl_format.c b/src/intel/isl/isl_format.c
> index ebc8ec9..2705595 100644
> --- a/src/intel/isl/isl_format.c
> +++ b/src/intel/isl/isl_format.c
> @@ -437,6 +437,21 @@ isl_format_supports_vertex_fetch(const struct 
> gen_device_info *devinfo,
> return format_gen(devinfo) >= format_info[format].input_vb;
>  }
>
> +/**
> + * Returns true if the given format can support single-sample fast clears.
> + */
> +bool
> +isl_format_supports_ccs_d(const struct gen_device_info *devinfo,
> +  enum isl_format format)
> +{
> +   if (!isl_format_supports_rendering(devinfo, format))
> +  return false;
> +
Add a check for non-MSRT?

> +   const struct isl_format_layout *fmtl = isl_format_get_layout(format);
> +
> +   return fmtl->bpb == 32 || fmtl->bpb == 64 || fmtl->bpb == 128;
> +}
> +
>  bool
>  isl_format_supports_ccs_e(const struct gen_device_info *devinfo,
>enum isl_format format)
> --
> 2.5.0.400.gff86faf
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCHv2 3/4] configure.ac: Separate HAVE_LLVM defines for gallium and radv

[Emil Velikov]

On 2 February 2017 at 00:00, Dave Airlie  wrote:
> On 2 February 2017 at 09:58, Emil Velikov  wrote:
>> On 1 February 2017 at 22:19, Dave Airlie  wrote:
>>> Just make radv depend on enable-gallium-llvm.
>>>
>>> I really don't want to make the #defines into the spaghetti this introduces.
>>>
>> Not a huge fan of it either.
>>
>> We need these for 17.0 and flipping things in a feature freeze period
>> is iffy. For 17.1.x we'll remove this and a lot more nasty code by
>> superseding --enable-gallium-llvm in favour of --enable-llvm.
>
> Why do we need it, just make radv not build if enable-gallium-llvm
> isn't specified.
>
Because that's the way things worked since day 1 - maybe it was an
oversight, maybe a bug, other.
All I'm asking is for a week or so of patience after which this messy
code, plus more, will be gone. Please ?

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

Re: [Mesa-dev] [PATCHv2 3/4] configure.ac: Separate HAVE_LLVM defines for gallium and radv

[Dave Airlie]

On 2 February 2017 at 09:58, Emil Velikov  wrote:
> On 1 February 2017 at 22:19, Dave Airlie  wrote:
>> Just make radv depend on enable-gallium-llvm.
>>
>> I really don't want to make the #defines into the spaghetti this introduces.
>>
> Not a huge fan of it either.
>
> We need these for 17.0 and flipping things in a feature freeze period
> is iffy. For 17.1.x we'll remove this and a lot more nasty code by
> superseding --enable-gallium-llvm in favour of --enable-llvm.

Why do we need it, just make radv not build if enable-gallium-llvm
isn't specified.

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

Re: [Mesa-dev] [PATCHv2 3/4] configure.ac: Separate HAVE_LLVM defines for gallium and radv

[Emil Velikov]

On 1 February 2017 at 22:19, Dave Airlie  wrote:
> Just make radv depend on enable-gallium-llvm.
>
> I really don't want to make the #defines into the spaghetti this introduces.
>
Not a huge fan of it either.

We need these for 17.0 and flipping things in a feature freeze period
is iffy. For 17.1.x we'll remove this and a lot more nasty code by
superseding --enable-gallium-llvm in favour of --enable-llvm.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: call DrawBuffer(s) driver hook in update_framebuffer for windows-system FB

[Brian Paul]

On 01/20/2017 07:18 AM, Manolova, Plamena wrote:

This looks good to me :)
Reviewed-by: Plamena Manolova >

On Fri, Jan 20, 2017 at 9:38 AM, Boyan Ding > wrote:

When draw buffers are changed on a bound framebuffer, DrawBuffer(s) hook
should be called. However, it is missing in update_framebuffer with
window-system framebuffer, in which FB's draw buffer state should match
context state, potentially resulting in a change.

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


Signed-off-by: Boyan Ding >
---
  src/mesa/main/framebuffer.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index c06130dc8d..55a6d5c004 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -670,6 +670,16 @@ update_framebuffer(struct gl_context *ctx,
struct gl_framebuffer *fb)
if (fb->ColorDrawBuffer[0] != ctx->Color.DrawBuffer[0]) {
   _mesa_drawbuffers(ctx, fb, ctx->Const.MaxDrawBuffers,
 ctx->Color.DrawBuffer, NULL);
+
+ /* Call device driver function if fb is the bound draw
buffer. */
+ if (fb == ctx->DrawBuffer) {
+if (ctx->Driver.DrawBuffers) {
+   ctx->Driver.DrawBuffers(ctx, ctx->Const.MaxDrawBuffers,
+  ctx->Color.DrawBuffer);
+} else if (ctx->Driver.DrawBuffer) {
+   ctx->Driver.DrawBuffer(ctx, ctx->Color.DrawBuffer[0]);
+}
+ }
}
 }
 else {


This makes three places in the code where we call 
ctx->Driver.DrawBuffers() or ctx->Driver.DrawBuffer() like this.  I 
think some refactoring would be good.


Perhaps these calls can go into _mesa_drawbuffers().  I'll try to look 
into that in a few days.


-Brian


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

[Mesa-dev] [Bug 99633] rasterizer/core/clip.h:279:49: error: ‘const struct API_STATE’ has no member named ‘linkageCount’

[bugzilla-daemon]

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

--- Comment #2 from Vinson Lee  ---
Fedora 26

$ gcc --version
gcc (GCC) 7.0.1 20170128 (Red Hat 7.0.1-0.3)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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

[Mesa-dev] [PATCH 2/2] radv/ac: move to using shared emit_ddxy code.

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 75 -
 1 file changed, 7 insertions(+), 68 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 45aeaf7..e8dc752 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1171,44 +1171,13 @@ static LLVMValueRef emit_unpack_half_2x16(struct 
nir_to_llvm_context *ctx,
return result;
 }
 
-/*
- * SI implements derivatives using the local data store (LDS)
- * All writes to the LDS happen in all executing threads at
- * the same time. TID is the Thread ID for the current
- * thread and is a value between 0 and 63, representing
- * the thread's position in the wavefront.
- *
- * For the pixel shader threads are grouped into quads of four pixels.
- * The TIDs of the pixels of a quad are:
- *
- *  +--+--+
- *  |4n + 0|4n + 1|
- *  +--+--+
- *  |4n + 2|4n + 3|
- *  +--+--+
- *
- * So, masking the TID with 0xfffc yields the TID of the top left pixel
- * of the quad, masking with 0xfffd yields the TID of the top pixel of
- * the current pixel's column, and masking with 0xfffe yields the TID
- * of the left pixel of the current pixel's row.
- *
- * Adding 1 yields the TID of the pixel to the right of the left pixel, and
- * adding 2 yields the TID of the pixel below the top pixel.
- */
-/* masks for thread ID. */
-#define TID_MASK_TOP_LEFT 0xfffc
-#define TID_MASK_TOP  0xfffd
-#define TID_MASK_LEFT 0xfffe
 static LLVMValueRef emit_ddxy(struct nir_to_llvm_context *ctx,
  nir_op op,
  LLVMValueRef src0)
 {
-   LLVMValueRef tl, trbl, result;
-   LLVMValueRef tl_tid, trbl_tid;
-   LLVMValueRef args[2];
-   LLVMValueRef thread_id;
unsigned mask;
int idx;
+   LLVMValueRef result;
ctx->has_ddxy = true;
 
if (!ctx->lds && !ctx->has_ds_bpermute)
@@ -1216,16 +1185,13 @@ static LLVMValueRef emit_ddxy(struct 
nir_to_llvm_context *ctx,
   LLVMArrayType(ctx->i32, 
64),
   "ddxy_lds", 
LOCAL_ADDR_SPACE);
 
-   thread_id = ac_get_thread_id(>ac);
if (op == nir_op_fddx_fine || op == nir_op_fddx)
-   mask = TID_MASK_LEFT;
+   mask = AC_TID_MASK_LEFT;
else if (op == nir_op_fddy_fine || op == nir_op_fddy)
-   mask = TID_MASK_TOP;
+   mask = AC_TID_MASK_TOP;
else
-   mask = TID_MASK_TOP_LEFT;
+   mask = AC_TID_MASK_TOP_LEFT;
 
-   tl_tid = LLVMBuildAnd(ctx->builder, thread_id,
- LLVMConstInt(ctx->i32, mask, false), "");
/* for DDX we want to next X pixel, DDY next Y pixel. */
if (op == nir_op_fddx_fine ||
op == nir_op_fddx_coarse ||
@@ -1234,36 +1200,9 @@ static LLVMValueRef emit_ddxy(struct nir_to_llvm_context 
*ctx,
else
idx = 2;
 
-   trbl_tid = LLVMBuildAdd(ctx->builder, tl_tid,
-   LLVMConstInt(ctx->i32, idx, false), "");
-
-   if (ctx->has_ds_bpermute) {
-   args[0] = LLVMBuildMul(ctx->builder, tl_tid,
-  LLVMConstInt(ctx->i32, 4, false), "");
-   args[1] = src0;
-   tl = ac_emit_llvm_intrinsic(>ac, "llvm.amdgcn.ds.bpermute",
-ctx->i32, args, 2,
-AC_FUNC_ATTR_READNONE);
-
-   args[0] = LLVMBuildMul(ctx->builder, trbl_tid,
-  LLVMConstInt(ctx->i32, 4, false), "");
-   trbl = ac_emit_llvm_intrinsic(>ac, 
"llvm.amdgcn.ds.bpermute",
-  ctx->i32, args, 2,
-  AC_FUNC_ATTR_READNONE);
-   } else {
-   LLVMValueRef store_ptr, load_ptr0, load_ptr1;
-
-   store_ptr = ac_build_gep0(>ac, ctx->lds, thread_id);
-   load_ptr0 = ac_build_gep0(>ac, ctx->lds, tl_tid);
-   load_ptr1 = ac_build_gep0(>ac, ctx->lds, trbl_tid);
-
-   LLVMBuildStore(ctx->builder, src0, store_ptr);
-   tl = LLVMBuildLoad(ctx->builder, load_ptr0, "");
-   trbl = LLVMBuildLoad(ctx->builder, load_ptr1, "");
-   }
-   tl = LLVMBuildBitCast(ctx->builder, tl, ctx->f32, "");
-   trbl = LLVMBuildBitCast(ctx->builder, trbl, ctx->f32, "");
-   result = LLVMBuildFSub(ctx->builder, trbl, tl, "");
+   result = ac_emit_ddxy(>ac, ctx->has_ds_bpermute,
+ mask, idx, ctx->lds,
+ src0);
return result;
 }
 
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

[Mesa-dev] [PATCH 1/2] radeonsi/ac: move most of emit_ddxy to shared code.

[Dave Airlie]

From: Dave Airlie 

We can reuse this in radv.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_llvm_util.c| 74 ++
 src/amd/common/ac_llvm_util.h| 12 +
 src/gallium/drivers/radeonsi/si_shader.c | 78 +++-
 3 files changed, 93 insertions(+), 71 deletions(-)

diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 9e23305..d53537d 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -850,3 +850,77 @@ ac_get_thread_id(struct ac_llvm_context *ctx)
set_range_metadata(ctx, tid, 0, 64);
return tid;
 }
+
+/*
+ * SI implements derivatives using the local data store (LDS)
+ * All writes to the LDS happen in all executing threads at
+ * the same time. TID is the Thread ID for the current
+ * thread and is a value between 0 and 63, representing
+ * the thread's position in the wavefront.
+ *
+ * For the pixel shader threads are grouped into quads of four pixels.
+ * The TIDs of the pixels of a quad are:
+ *
+ *  +--+--+
+ *  |4n + 0|4n + 1|
+ *  +--+--+
+ *  |4n + 2|4n + 3|
+ *  +--+--+
+ *
+ * So, masking the TID with 0xfffc yields the TID of the top left pixel
+ * of the quad, masking with 0xfffd yields the TID of the top pixel of
+ * the current pixel's column, and masking with 0xfffe yields the TID
+ * of the left pixel of the current pixel's row.
+ *
+ * Adding 1 yields the TID of the pixel to the right of the left pixel, and
+ * adding 2 yields the TID of the pixel below the top pixel.
+ */
+LLVMValueRef
+ac_emit_ddxy(struct ac_llvm_context *ctx,
+bool has_ds_bpermute,
+uint32_t mask,
+int idx,
+LLVMValueRef lds,
+LLVMValueRef val)
+{
+   LLVMValueRef thread_id, tl, trbl, tl_tid, trbl_tid, args[2];
+   LLVMValueRef result;
+
+   thread_id = ac_get_thread_id(ctx);
+
+   tl_tid = LLVMBuildAnd(ctx->builder, thread_id,
+ LLVMConstInt(ctx->i32, mask, false), "");
+
+   trbl_tid = LLVMBuildAdd(ctx->builder, tl_tid,
+   LLVMConstInt(ctx->i32, idx, false), "");
+
+   if (has_ds_bpermute) {
+   args[0] = LLVMBuildMul(ctx->builder, tl_tid,
+  LLVMConstInt(ctx->i32, 4, false), "");
+   args[1] = val;
+   tl = ac_emit_llvm_intrinsic(ctx,
+   "llvm.amdgcn.ds.bpermute", ctx->i32,
+   args, 2, AC_FUNC_ATTR_READNONE);
+
+   args[0] = LLVMBuildMul(ctx->builder, trbl_tid,
+  LLVMConstInt(ctx->i32, 4, false), "");
+   trbl = ac_emit_llvm_intrinsic(ctx,
+ "llvm.amdgcn.ds.bpermute", 
ctx->i32,
+ args, 2, AC_FUNC_ATTR_READNONE);
+   } else {
+   LLVMValueRef store_ptr, load_ptr0, load_ptr1;
+
+   store_ptr = ac_build_gep0(ctx, lds, thread_id);
+   load_ptr0 = ac_build_gep0(ctx, lds, tl_tid);
+   load_ptr1 = ac_build_gep0(ctx, lds, trbl_tid);
+
+   LLVMBuildStore(ctx->builder, val, store_ptr);
+   tl = LLVMBuildLoad(ctx->builder, load_ptr0, "");
+   trbl = LLVMBuildLoad(ctx->builder, load_ptr1, "");
+   }
+
+   tl = LLVMBuildBitCast(ctx->builder, tl, ctx->f32, "");
+   trbl = LLVMBuildBitCast(ctx->builder, trbl, ctx->f32, "");
+   result = LLVMBuildFSub(ctx->builder, trbl, tl, "");
+   return result;
+}
diff --git a/src/amd/common/ac_llvm_util.h b/src/amd/common/ac_llvm_util.h
index 0244dc4..a457714 100644
--- a/src/amd/common/ac_llvm_util.h
+++ b/src/amd/common/ac_llvm_util.h
@@ -180,6 +180,18 @@ ac_build_buffer_load(struct ac_llvm_context *ctx,
 
 LLVMValueRef
 ac_get_thread_id(struct ac_llvm_context *ctx);
+
+#define AC_TID_MASK_TOP_LEFT 0xfffc
+#define AC_TID_MASK_TOP  0xfffd
+#define AC_TID_MASK_LEFT 0xfffe
+
+LLVMValueRef
+ac_emit_ddxy(struct ac_llvm_context *ctx,
+bool has_ds_bpermute,
+uint32_t mask,
+int idx,
+LLVMValueRef lds,
+LLVMValueRef val);
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index e483fe4..89229ee 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -4722,35 +4722,6 @@ static void si_llvm_emit_txqs(
emit_data->output[emit_data->chan] = samples;
 }
 
-/*
- * SI implements derivatives using the local data store (LDS)
- * All writes to the LDS happen in all executing threads at
- * the same time. TID is the Thread ID for the current
- * thread and is a value between 0 and 63, representing
- * the thread's position in the 

[Mesa-dev] [Bug 99633] rasterizer/core/clip.h:279:49: error: ‘const struct API_STATE’ has no member named ‘linkageCount’

[bugzilla-daemon]

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

--- Comment #1 from Bruce Cherniak  ---
What environment are you compiling under (os, compiler (gcc, icc, clang), and
version)?

Clip::ClipScalar() looks like it might be dead code and should be removed.

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

[Mesa-dev] [PATCH 2/2] radv/ac: use shared thread id code

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 44 ++---
 1 file changed, 2 insertions(+), 42 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 7a26333..45aeaf7 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -135,7 +135,6 @@ struct nir_to_llvm_context {
LLVMValueRef f32one;
LLVMValueRef v4f32empty;
 
-   unsigned range_md_kind;
unsigned uniform_md_kind;
LLVMValueRef empty_md;
gl_shader_stage stage;
@@ -703,8 +702,6 @@ static void setup_types(struct nir_to_llvm_context *ctx)
args[3] = ctx->f32one;
ctx->v4f32empty = LLVMConstVector(args, 4);
 
-   ctx->range_md_kind = LLVMGetMDKindIDInContext(ctx->context,
- "range", 5);
ctx->uniform_md_kind =
LLVMGetMDKindIDInContext(ctx->context, "amdgpu.uniform", 14);
ctx->empty_md = LLVMMDNodeInContext(ctx->context, NULL, 0);
@@ -1174,43 +1171,6 @@ static LLVMValueRef emit_unpack_half_2x16(struct 
nir_to_llvm_context *ctx,
return result;
 }
 
-/**
- * Set range metadata on an instruction.  This can only be used on load and
- * call instructions.  If you know an instruction can only produce the values
- * 0, 1, 2, you would do set_range_metadata(value, 0, 3);
- * \p lo is the minimum value inclusive.
- * \p hi is the maximum value exclusive.
- */
-static void set_range_metadata(struct nir_to_llvm_context *ctx,
-  LLVMValueRef value, unsigned lo, unsigned hi)
-{
-   LLVMValueRef range_md, md_args[2];
-   LLVMTypeRef type = LLVMTypeOf(value);
-   LLVMContextRef context = LLVMGetTypeContext(type);
-
-   md_args[0] = LLVMConstInt(type, lo, false);
-   md_args[1] = LLVMConstInt(type, hi, false);
-   range_md = LLVMMDNodeInContext(context, md_args, 2);
-   LLVMSetMetadata(value, ctx->range_md_kind, range_md);
-}
-
-static LLVMValueRef get_thread_id(struct nir_to_llvm_context *ctx)
-{
-   LLVMValueRef tid;
-   LLVMValueRef tid_args[2];
-   tid_args[0] = LLVMConstInt(ctx->i32, 0x, false);
-   tid_args[1] = ctx->i32zero;
-   tid_args[1] = ac_emit_llvm_intrinsic(>ac,
- "llvm.amdgcn.mbcnt.lo", ctx->i32,
- tid_args, 2, AC_FUNC_ATTR_READNONE);
-
-   tid = ac_emit_llvm_intrinsic(>ac,
- "llvm.amdgcn.mbcnt.hi", ctx->i32,
- tid_args, 2, AC_FUNC_ATTR_READNONE);
-   set_range_metadata(ctx, tid, 0, 64);
-   return tid;
-}
-
 /*
  * SI implements derivatives using the local data store (LDS)
  * All writes to the LDS happen in all executing threads at
@@ -1256,7 +1216,7 @@ static LLVMValueRef emit_ddxy(struct nir_to_llvm_context 
*ctx,
   LLVMArrayType(ctx->i32, 
64),
   "ddxy_lds", 
LOCAL_ADDR_SPACE);
 
-   thread_id = get_thread_id(ctx);
+   thread_id = ac_get_thread_id(>ac);
if (op == nir_op_fddx_fine || op == nir_op_fddx)
mask = TID_MASK_LEFT;
else if (op == nir_op_fddy_fine || op == nir_op_fddy)
@@ -2876,7 +2836,7 @@ static LLVMValueRef
 visit_load_local_invocation_index(struct nir_to_llvm_context *ctx)
 {
LLVMValueRef result;
-   LLVMValueRef thread_id = get_thread_id(ctx);
+   LLVMValueRef thread_id = ac_get_thread_id(>ac);
result = LLVMBuildAnd(ctx->builder, ctx->tg_size,
  LLVMConstInt(ctx->i32, 0xfc0, false), "");
 
-- 
2.9.3

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

[Mesa-dev] [PATCH 1/2] radeonsi/ac: move get thread id to shared code.

[Dave Airlie]

From: Dave Airlie 

radv will use this.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_llvm_util.c| 48 +++
 src/amd/common/ac_llvm_util.h|  6 +++-
 src/gallium/drivers/radeonsi/si_shader.c | 57 ++--
 3 files changed, 55 insertions(+), 56 deletions(-)

diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 36ecbb1..9e23305 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -168,6 +168,9 @@ ac_llvm_context_init(struct ac_llvm_context *ctx, 
LLVMContextRef context)
ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
ctx->v16i8 = LLVMVectorType(ctx->i8, 16);
 
+   ctx->range_md_kind = LLVMGetMDKindIDInContext(ctx->context,
+"range", 5);
+
ctx->invariant_load_md_kind = LLVMGetMDKindIDInContext(ctx->context,
   
"invariant.load", 14);
 
@@ -802,3 +805,48 @@ ac_build_buffer_load(struct ac_llvm_context *ctx,
   ARRAY_SIZE(args), 
AC_FUNC_ATTR_READONLY);
}
 }
+
+/**
+ * Set range metadata on an instruction.  This can only be used on load and
+ * call instructions.  If you know an instruction can only produce the values
+ * 0, 1, 2, you would do set_range_metadata(value, 0, 3);
+ * \p lo is the minimum value inclusive.
+ * \p hi is the maximum value exclusive.
+ */
+static void set_range_metadata(struct ac_llvm_context *ctx,
+  LLVMValueRef value, unsigned lo, unsigned hi)
+{
+   LLVMValueRef range_md, md_args[2];
+   LLVMTypeRef type = LLVMTypeOf(value);
+   LLVMContextRef context = LLVMGetTypeContext(type);
+
+   md_args[0] = LLVMConstInt(type, lo, false);
+   md_args[1] = LLVMConstInt(type, hi, false);
+   range_md = LLVMMDNodeInContext(context, md_args, 2);
+   LLVMSetMetadata(value, ctx->range_md_kind, range_md);
+}
+
+LLVMValueRef
+ac_get_thread_id(struct ac_llvm_context *ctx)
+{
+   LLVMValueRef tid;
+
+   if (HAVE_LLVM < 0x0308) {
+   tid = ac_emit_llvm_intrinsic(ctx, "llvm.SI.tid",
+ctx->i32,
+NULL, 0, AC_FUNC_ATTR_READNONE);
+   } else {
+   LLVMValueRef tid_args[2];
+   tid_args[0] = LLVMConstInt(ctx->i32, 0x, false);
+   tid_args[1] = LLVMConstInt(ctx->i32, 0, false);
+   tid_args[1] = ac_emit_llvm_intrinsic(ctx,
+"llvm.amdgcn.mbcnt.lo", 
ctx->i32,
+tid_args, 2, 
AC_FUNC_ATTR_READNONE);
+
+   tid = ac_emit_llvm_intrinsic(ctx, "llvm.amdgcn.mbcnt.hi",
+ctx->i32, tid_args,
+2, AC_FUNC_ATTR_READNONE);
+   }
+   set_range_metadata(ctx, tid, 0, 64);
+   return tid;
+}
diff --git a/src/amd/common/ac_llvm_util.h b/src/amd/common/ac_llvm_util.h
index 7b08a26..0244dc4 100644
--- a/src/amd/common/ac_llvm_util.h
+++ b/src/amd/common/ac_llvm_util.h
@@ -57,7 +57,8 @@ struct ac_llvm_context {
LLVMTypeRef v4i32;
LLVMTypeRef v4f32;
LLVMTypeRef v16i8;
-  
+
+   unsigned range_md_kind;
unsigned invariant_load_md_kind;
unsigned uniform_md_kind;
unsigned fpmath_md_kind;
@@ -176,6 +177,9 @@ ac_build_buffer_load(struct ac_llvm_context *ctx,
 unsigned inst_offset,
 unsigned glc,
 unsigned slc);
+
+LLVMValueRef
+ac_get_thread_id(struct ac_llvm_context *ctx);
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index e4ed40e..e483fe4 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1266,49 +1266,6 @@ static LLVMValueRef get_sample_id(struct 
si_shader_context *radeon_bld)
SI_PARAM_ANCILLARY, 8, 4);
 }
 
-/**
- * Set range metadata on an instruction.  This can only be used on load and
- * call instructions.  If you know an instruction can only produce the values
- * 0, 1, 2, you would do set_range_metadata(value, 0, 3);
- * \p lo is the minimum value inclusive.
- * \p hi is the maximum value exclusive.
- */
-static void set_range_metadata(struct si_shader_context *ctx,
-  LLVMValueRef value, unsigned lo, unsigned hi)
-{
-   LLVMValueRef range_md, md_args[2];
-   LLVMTypeRef type = LLVMTypeOf(value);
-   LLVMContextRef context = LLVMGetTypeContext(type);
-
-   md_args[0] = LLVMConstInt(type, lo, false);
-   md_args[1] = LLVMConstInt(type, hi, false);
-   range_md = LLVMMDNodeInContext(context, md_args, 2);
-   

[Mesa-dev] [Bug 99633] rasterizer/core/clip.h:279:49: error: ‘const struct API_STATE’ has no member named ‘linkageCount’

[bugzilla-daemon]

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

Bug ID: 99633
   Summary: rasterizer/core/clip.h:279:49: error: ‘const struct
API_STATE’ has no member named ‘linkageCount’
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org

mesa: 9c45bb731c97d1f02f83b872c67b2c1b04ec3a41 (master 17.1.0-devel)

  CXX  rasterizer/core/libswrAVX_la-api.lo
In file included from rasterizer/core/api.cpp:43:0:
./rasterizer/core/clip.h: In member function ‘int
Clipper::ClipScalar(PA_STATE&, uint32_t, float*, float*)’:
./rasterizer/core/clip.h:279:49: error: ‘const struct API_STATE’ has no member
named ‘linkageCount’
 uint32_t numScalarAttribs = this->state.linkageCount * 4;
 ^~~~
./rasterizer/core/clip.h:284:52: error: ‘const struct API_STATE’ has no member
named ‘linkageMask’
 uint32_t tmpLinkage = uint32_t(this->state.linkageMask);
^~~
./rasterizer/core/clip.h:289:73: error: ‘const struct API_STATE’ has no member
named ‘linkageMap’
 uint32_t inputSlot = VERTEX_ATTRIB_START_SLOT +
this->state.linkageMap[mapIdx++];

^~

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

[Mesa-dev] [PATCH] configure: Only require libdrm 2.4.75 for intel.

[Vinson Lee]

Fixes: b8acb6b17981 ("configure: Require libdrm >= 2.4.75")
Signed-off-by: Vinson Lee 
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 92339b4..d4302bf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,10 +67,10 @@ OPENCL_VERSION=1
 AC_SUBST([OPENCL_VERSION])
 
 dnl Versions for external dependencies
-LIBDRM_REQUIRED=2.4.75
+LIBDRM_REQUIRED=2.4.66
 LIBDRM_RADEON_REQUIRED=2.4.56
 LIBDRM_AMDGPU_REQUIRED=2.4.63
-LIBDRM_INTEL_REQUIRED=2.4.61
+LIBDRM_INTEL_REQUIRED=2.4.75
 LIBDRM_NVVIEUX_REQUIRED=2.4.66
 LIBDRM_NOUVEAU_REQUIRED=2.4.66
 LIBDRM_FREEDRENO_REQUIRED=2.4.74
-- 
2.10.2

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

[Mesa-dev] [PATCH] radv/ac: migrate to using shared code for some load/store stuff.

[Dave Airlie]

From: Dave Airlie 

This migrates to the code shared with radeonsi.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 128 +---
 1 file changed, 28 insertions(+), 100 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 11a8490..6882674 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -407,78 +407,6 @@ static LLVMValueRef unpack_param(struct 
nir_to_llvm_context *ctx,
return value;
 }
 
-static LLVMValueRef build_gep0(struct nir_to_llvm_context *ctx,
-  LLVMValueRef base_ptr, LLVMValueRef index)
-{
-   LLVMValueRef indices[2] = {
-   ctx->i32zero,
-   index,
-   };
-   return LLVMBuildGEP(ctx->builder, base_ptr,
-   indices, 2, "");
-}
-
-static LLVMValueRef build_indexed_load(struct nir_to_llvm_context *ctx,
-  LLVMValueRef base_ptr, LLVMValueRef 
index,
-  bool uniform)
-{
-   LLVMValueRef pointer;
-   pointer = build_gep0(ctx, base_ptr, index);
-   if (uniform)
-   LLVMSetMetadata(pointer, ctx->uniform_md_kind, ctx->empty_md);
-   return LLVMBuildLoad(ctx->builder, pointer, "");
-}
-
-static LLVMValueRef build_indexed_load_const(struct nir_to_llvm_context *ctx,
-LLVMValueRef base_ptr, 
LLVMValueRef index)
-{
-   LLVMValueRef result = build_indexed_load(ctx, base_ptr, index, true);
-   LLVMSetMetadata(result, ctx->invariant_load_md_kind, ctx->empty_md);
-   return result;
-}
-
-static void build_tbuffer_store(struct nir_to_llvm_context *ctx,
-   LLVMValueRef rsrc,
-   LLVMValueRef vdata,
-   unsigned num_channels,
-   LLVMValueRef vaddr,
-   LLVMValueRef soffset,
-   unsigned inst_offset,
-   unsigned dfmt,
-   unsigned nfmt,
-   unsigned offen,
-   unsigned idxen,
-   unsigned glc,
-   unsigned slc,
-   unsigned tfe)
-{
-   LLVMValueRef args[] = {
-   rsrc,
-   vdata,
-   LLVMConstInt(ctx->i32, num_channels, 0),
-   vaddr,
-   soffset,
-   LLVMConstInt(ctx->i32, inst_offset, 0),
-   LLVMConstInt(ctx->i32, dfmt, 0),
-   LLVMConstInt(ctx->i32, nfmt, 0),
-   LLVMConstInt(ctx->i32, offen, 0),
-   LLVMConstInt(ctx->i32, idxen, 0),
-   LLVMConstInt(ctx->i32, glc, 0),
-   LLVMConstInt(ctx->i32, slc, 0),
-   LLVMConstInt(ctx->i32, tfe, 0)
-   };
-
-   /* The intrinsic is overloaded, we need to add a type suffix for 
overloading to work. */
-   unsigned func = CLAMP(num_channels, 1, 3) - 1;
-   const char *types[] = {"i32", "v2i32", "v4i32"};
-   char name[256];
-   snprintf(name, sizeof(name), "llvm.SI.tbuffer.store.%s", types[func]);
-
-   ac_emit_llvm_intrinsic(>ac, name, ctx->voidt,
-   args, ARRAY_SIZE(args), 0);
-
-}
-
 static void set_userdata_location(struct ac_userdata_info *ud_info, uint8_t 
sgpr_idx, uint8_t num_sgprs)
 {
ud_info->sgpr_idx = sgpr_idx;
@@ -1368,9 +1296,9 @@ static LLVMValueRef emit_ddxy(struct nir_to_llvm_context 
*ctx,
} else {
LLVMValueRef store_ptr, load_ptr0, load_ptr1;
 
-   store_ptr = build_gep0(ctx, ctx->lds, thread_id);
-   load_ptr0 = build_gep0(ctx, ctx->lds, tl_tid);
-   load_ptr1 = build_gep0(ctx, ctx->lds, trbl_tid);
+   store_ptr = ac_build_gep0(>ac, ctx->lds, thread_id);
+   load_ptr0 = ac_build_gep0(>ac, ctx->lds, tl_tid);
+   load_ptr1 = ac_build_gep0(>ac, ctx->lds, trbl_tid);
 
LLVMBuildStore(ctx->builder, src0, store_ptr);
tl = LLVMBuildLoad(ctx->builder, load_ptr0, "");
@@ -1980,7 +1908,7 @@ static LLVMValueRef visit_vulkan_resource_index(struct 
nir_to_llvm_context *ctx,
index = LLVMBuildMul(ctx->builder, index, stride, "");
offset = LLVMBuildAdd(ctx->builder, offset, index, "");

-   desc_ptr = build_gep0(ctx, desc_ptr, offset);
+   desc_ptr = ac_build_gep0(>ac, desc_ptr, offset);
desc_ptr = cast_ptr(ctx, desc_ptr, ctx->v4i32);
LLVMSetMetadata(desc_ptr, ctx->uniform_md_kind, ctx->empty_md);
 
@@ -1995,7 +1923,7 @@ static LLVMValueRef visit_load_push_constant(struct 
nir_to_llvm_context *ctx,
addr = LLVMConstInt(ctx->i32, nir_intrinsic_base(instr), 0);
addr = 

[Mesa-dev] [PATCH 2/2] radeonsi/ac: move tbuffer store and buffer load to shared code.

[Dave Airlie]

From: Dave Airlie 

These are all reuseable by radv.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_llvm_util.c| 154 +
 src/amd/common/ac_llvm_util.h|  44 +-
 src/gallium/drivers/radeonsi/si_shader.c | 225 ++-
 3 files changed, 237 insertions(+), 186 deletions(-)

diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 43eeaac..36ecbb1 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -35,6 +35,8 @@
 #include "util/bitscan.h"
 #include "util/macros.h"
 
+#include "sid.h"
+
 static void ac_init_llvm_target()
 {
 #if HAVE_LLVM < 0x0307
@@ -157,8 +159,14 @@ ac_llvm_context_init(struct ac_llvm_context *ctx, 
LLVMContextRef context)
ctx->module = NULL;
ctx->builder = NULL;
 
+   ctx->voidt = LLVMVoidTypeInContext(ctx->context);
+   ctx->i1 = LLVMInt1TypeInContext(ctx->context);
+   ctx->i8 = LLVMInt8TypeInContext(ctx->context);
ctx->i32 = LLVMIntTypeInContext(ctx->context, 32);
ctx->f32 = LLVMFloatTypeInContext(ctx->context);
+   ctx->v4i32 = LLVMVectorType(ctx->i32, 4);
+   ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
+   ctx->v16i8 = LLVMVectorType(ctx->i8, 16);
 
ctx->invariant_load_md_kind = LLVMGetMDKindIDInContext(ctx->context,
   
"invariant.load", 14);
@@ -648,3 +656,149 @@ ac_build_indexed_load_const(struct ac_llvm_context *ctx,
LLVMSetMetadata(result, ctx->invariant_load_md_kind, ctx->empty_md);
return result;
 }
+
+/* TBUFFER_STORE_FORMAT_{X,XY,XYZ,XYZW} <- the suffix is selected by 
num_channels=1..4.
+ * The type of vdata must be one of i32 (num_channels=1), v2i32 
(num_channels=2),
+ * or v4i32 (num_channels=3,4). */
+void
+ac_build_tbuffer_store(struct ac_llvm_context *ctx,
+  LLVMValueRef rsrc,
+  LLVMValueRef vdata,
+  unsigned num_channels,
+  LLVMValueRef vaddr,
+  LLVMValueRef soffset,
+  unsigned inst_offset,
+  unsigned dfmt,
+  unsigned nfmt,
+  unsigned offen,
+  unsigned idxen,
+  unsigned glc,
+  unsigned slc,
+  unsigned tfe)
+{
+   LLVMValueRef args[] = {
+   rsrc,
+   vdata,
+   LLVMConstInt(ctx->i32, num_channels, 0),
+   vaddr,
+   soffset,
+   LLVMConstInt(ctx->i32, inst_offset, 0),
+   LLVMConstInt(ctx->i32, dfmt, 0),
+   LLVMConstInt(ctx->i32, nfmt, 0),
+   LLVMConstInt(ctx->i32, offen, 0),
+   LLVMConstInt(ctx->i32, idxen, 0),
+   LLVMConstInt(ctx->i32, glc, 0),
+   LLVMConstInt(ctx->i32, slc, 0),
+   LLVMConstInt(ctx->i32, tfe, 0)
+   };
+
+   /* The instruction offset field has 12 bits */
+   assert(offen || inst_offset < (1 << 12));
+
+   /* The intrinsic is overloaded, we need to add a type suffix for 
overloading to work. */
+   unsigned func = CLAMP(num_channels, 1, 3) - 1;
+   const char *types[] = {"i32", "v2i32", "v4i32"};
+   char name[256];
+   snprintf(name, sizeof(name), "llvm.SI.tbuffer.store.%s", types[func]);
+
+   ac_emit_llvm_intrinsic(ctx, name, ctx->voidt,
+  args, ARRAY_SIZE(args), 0);
+}
+
+void
+ac_build_tbuffer_store_dwords(struct ac_llvm_context *ctx,
+ LLVMValueRef rsrc,
+ LLVMValueRef vdata,
+ unsigned num_channels,
+ LLVMValueRef vaddr,
+ LLVMValueRef soffset,
+ unsigned inst_offset)
+{
+   static unsigned dfmt[] = {
+   V_008F0C_BUF_DATA_FORMAT_32,
+   V_008F0C_BUF_DATA_FORMAT_32_32,
+   V_008F0C_BUF_DATA_FORMAT_32_32_32,
+   V_008F0C_BUF_DATA_FORMAT_32_32_32_32
+   };
+   assert(num_channels >= 1 && num_channels <= 4);
+
+   ac_build_tbuffer_store(ctx, rsrc, vdata, num_channels, vaddr, soffset,
+  inst_offset, dfmt[num_channels-1],
+  V_008F0C_BUF_NUM_FORMAT_UINT, 1, 0, 1, 1, 0);
+}
+
+LLVMValueRef
+ac_build_buffer_load(struct ac_llvm_context *ctx,
+LLVMValueRef rsrc,
+int num_channels,
+LLVMValueRef vindex,
+LLVMValueRef voffset,
+LLVMValueRef soffset,
+unsigned inst_offset,
+unsigned glc,
+unsigned slc)
+{
+   unsigned func = CLAMP(num_channels, 1, 3) - 1;
+
+   if (HAVE_LLVM >= 0x309) {
+   

[Mesa-dev] [PATCH 1/2] radeonsi/ac: move a bunch of load/store related things to common code.

[Dave Airlie]

From: Dave Airlie 

These are all shareable with radv, so start migrating them to the
common code.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_llvm_util.c |  65 
 src/amd/common/ac_llvm_util.h |  22 
 src/gallium/drivers/radeonsi/si_shader.c  | 118 +-
 src/gallium/drivers/radeonsi/si_shader_internal.h |   3 -
 4 files changed, 114 insertions(+), 94 deletions(-)

diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 8c87a13..43eeaac 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -160,10 +160,18 @@ ac_llvm_context_init(struct ac_llvm_context *ctx, 
LLVMContextRef context)
ctx->i32 = LLVMIntTypeInContext(ctx->context, 32);
ctx->f32 = LLVMFloatTypeInContext(ctx->context);
 
+   ctx->invariant_load_md_kind = LLVMGetMDKindIDInContext(ctx->context,
+  
"invariant.load", 14);
+
ctx->fpmath_md_kind = LLVMGetMDKindIDInContext(ctx->context, "fpmath", 
6);
 
args[0] = LLVMConstReal(ctx->f32, 2.5);
ctx->fpmath_md_2p5_ulp = LLVMMDNodeInContext(ctx->context, args, 1);
+
+   ctx->uniform_md_kind = LLVMGetMDKindIDInContext(ctx->context,
+   "amdgpu.uniform", 14);
+
+   ctx->empty_md = LLVMMDNodeInContext(ctx->context, NULL, 0);
 }
 
 #if HAVE_LLVM < 0x0400
@@ -583,3 +591,60 @@ ac_build_fs_interp_mov(struct ac_llvm_context *ctx,
return ac_emit_llvm_intrinsic(ctx, "llvm.amdgcn.interp.mov",
  ctx->f32, args, 4, AC_FUNC_ATTR_READNONE);
 }
+
+LLVMValueRef
+ac_build_gep0(struct ac_llvm_context *ctx,
+ LLVMValueRef base_ptr,
+ LLVMValueRef index)
+{
+   LLVMValueRef indices[2] = {
+   LLVMConstInt(ctx->i32, 0, 0),
+   index,
+   };
+   return LLVMBuildGEP(ctx->builder, base_ptr,
+   indices, 2, "");
+}
+
+void
+ac_build_indexed_store(struct ac_llvm_context *ctx,
+  LLVMValueRef base_ptr, LLVMValueRef index,
+  LLVMValueRef value)
+{
+   LLVMBuildStore(ctx->builder, value,
+  ac_build_gep0(ctx, base_ptr, index));
+}
+
+/**
+ * Build an LLVM bytecode indexed load using LLVMBuildGEP + LLVMBuildLoad.
+ * It's equivalent to doing a load from _ptr[index].
+ *
+ * \param base_ptr  Where the array starts.
+ * \param index The element index into the array.
+ * \param uniform   Whether the base_ptr and index can be assumed to be
+ *  dynamically uniform
+ */
+LLVMValueRef
+ac_build_indexed_load(struct ac_llvm_context *ctx,
+ LLVMValueRef base_ptr, LLVMValueRef index,
+ bool uniform)
+{
+   LLVMValueRef pointer;
+
+   pointer = ac_build_gep0(ctx, base_ptr, index);
+   if (uniform)
+   LLVMSetMetadata(pointer, ctx->uniform_md_kind, ctx->empty_md);
+   return LLVMBuildLoad(ctx->builder, pointer, "");
+}
+
+/**
+ * Do a load from _ptr[index], but also add a flag that it's loading
+ * a constant from a dynamically uniform index.
+ */
+LLVMValueRef
+ac_build_indexed_load_const(struct ac_llvm_context *ctx,
+   LLVMValueRef base_ptr, LLVMValueRef index)
+{
+   LLVMValueRef result = ac_build_indexed_load(ctx, base_ptr, index, true);
+   LLVMSetMetadata(result, ctx->invariant_load_md_kind, ctx->empty_md);
+   return result;
+}
diff --git a/src/amd/common/ac_llvm_util.h b/src/amd/common/ac_llvm_util.h
index 2a33765..c2193d1 100644
--- a/src/amd/common/ac_llvm_util.h
+++ b/src/amd/common/ac_llvm_util.h
@@ -52,8 +52,11 @@ struct ac_llvm_context {
LLVMTypeRef i32;
LLVMTypeRef f32;
 
+   unsigned invariant_load_md_kind;
+   unsigned uniform_md_kind;
unsigned fpmath_md_kind;
LLVMValueRef fpmath_md_2p5_ulp;
+   LLVMValueRef empty_md;
 };
 
 LLVMTargetMachineRef ac_create_target_machine(enum radeon_family family, bool 
supports_spill);
@@ -112,6 +115,25 @@ ac_build_fs_interp_mov(struct ac_llvm_context *ctx,
   LLVMValueRef llvm_chan,
   LLVMValueRef attr_number,
   LLVMValueRef params);
+
+LLVMValueRef
+ac_build_gep0(struct ac_llvm_context *ctx,
+ LLVMValueRef base_ptr,
+ LLVMValueRef index);
+
+void
+ac_build_indexed_store(struct ac_llvm_context *ctx,
+  LLVMValueRef base_ptr, LLVMValueRef index,
+  LLVMValueRef value);
+
+LLVMValueRef
+ac_build_indexed_load(struct ac_llvm_context *ctx,
+ LLVMValueRef base_ptr, LLVMValueRef index,
+ bool uniform);
+
+LLVMValueRef
+ac_build_indexed_load_const(struct ac_llvm_context *ctx,
+   LLVMValueRef base_ptr, LLVMValueRef index);

Re: [Mesa-dev] [Mesa-stable] [PATCH] android: fix llvm, elf dependencies for M, N releases

[Emil Velikov]

On 30 January 2017 at 19:57, Mauro Rossi  wrote:
> These changes set the correct llvm version and elf include path
> which differ for Marshmallow and Nougat
> ---
>  Android.common.mk | 14 --
>  src/amd/Android.common.mk |  2 +-
>  src/gallium/Android.common.mk |  2 +-
>  3 files changed, 14 insertions(+), 4 deletions(-)
>
Thanks Mauro !

Reviewed and pushed to master. Will pick it for 17.0 in a bit.

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

Re: [Mesa-dev] [PATCH 01/10] gallium: add a common uploader to pipe_context

[Brian Paul]

On 01/30/2017 10:06 AM, Nicolai Hähnle wrote:

On 27.01.2017 16:02, Marek Olšák wrote:

On Fri, Jan 27, 2017 at 3:38 PM, Roland Scheidegger
 wrote:

Am 27.01.2017 um 12:02 schrieb Marek Olšák:

From: Marek Olšák 

For lower memory usage and more efficient updates of the buffer
residency
list. (e.g. if drivers keep seeing the same buffer for many consecutive
"add" calls, the calls can be turned into no-ops trivially)
---
 src/gallium/include/pipe/p_context.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index 45098c9..5876968 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -69,33 +69,40 @@ struct pipe_stream_output_target;
 struct pipe_surface;
 struct pipe_transfer;
 struct pipe_vertex_buffer;
 struct pipe_vertex_element;
 struct pipe_video_buffer;
 struct pipe_video_codec;
 struct pipe_viewport_state;
 struct pipe_compute_state;
 union pipe_color_union;
 union pipe_query_result;
+struct u_upload_mgr;

 /**
  * Gallium rendering context.  Basically:
  *  - state setting functions
  *  - VBO drawing functions
  *  - surface functions
  */
 struct pipe_context {
struct pipe_screen *screen;

void *priv;  /**< context private data (for DRI for example) */
void *draw;  /**< private, for draw module (temporary?) */

+   /**
+* Stream uploader created by the driver. All drivers, state
trackers, and
+* modules should use it.
+*/
+   struct u_upload_mgr *stream_uploader;
+
void (*destroy)( struct pipe_context * );

/**
 * VBO drawing
 */
/*@{*/
void (*draw_vbo)( struct pipe_context *pipe,
  const struct pipe_draw_info *info );
/*@}*/




I suppose this makes sense. However, this makes util interfaces
effectively part of the gallium interface, not sure how I feel about
that as this seems to violate the contract that util code is optional.


To be honest, I don't care much. Putting the uploader into
pipe_context has an obvious practical advantage and we want exactly
one instance between drivers and state trackers.

Also, all utilities that had to use pipe_buffer_create just to upload
something for one use can now use this.

If somebody wants a proper formal interface, feel free.

I do see a small decrease in CPU overhead with legacy GL apps thanks
to amdgpu_cs_add_buffer getting the same buffer over and over again.


I agree that this is a nice cleanup and improvement at the same time.

Roland has a point, of course, and in theory one could add an
upload_alloc function to the pipe_context, but in practice, that just
adds an indirect call for no benefit. I think we should go ahead with this.

I have some comments on patch #3, but apart from that, the series is

Reviewed-by: Nicolai Hähnle 


I've been off-line for a while and am catching up on things.  I'd like 
to look more closely at this when I get time, but I don't want to hold 
things up.


Marek, could you at least add some documentation for this in 
src/gallium/docs/source/context.rst to explain how it should be used?


-Brian

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

[Mesa-dev] [PATCH 1/5] intel/isl: Rename supports_lossless_compression to supports_ccs_e

[Jason Ekstrand]

The term "lossless compression" could potentially mean multisample
color compression, single-sample color compression or HiZ because they
are all lossless.  The term CCS_E, however, has a very precise meaning;
in ISL and is only used to refer to single-sample color compression.
It's also much shorter which is nice.
---
 src/intel/isl/isl.h  | 4 ++--
 src/intel/isl/isl_format.c   | 8 
 src/intel/vulkan/anv_image.c | 2 +-
 src/intel/vulkan/genX_cmd_buffer.c   | 3 +--
 src/mesa/drivers/dri/i965/brw_context.c  | 3 +--
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 3 +--
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 3 +--
 7 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index 07368f9..bdc5ebf 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -1040,8 +1040,8 @@ bool isl_format_supports_filtering(const struct 
gen_device_info *devinfo,
enum isl_format format);
 bool isl_format_supports_vertex_fetch(const struct gen_device_info *devinfo,
   enum isl_format format);
-bool isl_format_supports_lossless_compression(const struct gen_device_info 
*devinfo,
-  enum isl_format format);
+bool isl_format_supports_ccs_e(const struct gen_device_info *devinfo,
+   enum isl_format format);
 bool isl_format_supports_multisampling(const struct gen_device_info *devinfo,
enum isl_format format);
 
diff --git a/src/intel/isl/isl_format.c b/src/intel/isl/isl_format.c
index bc157d5..ebc8ec9 100644
--- a/src/intel/isl/isl_format.c
+++ b/src/intel/isl/isl_format.c
@@ -37,7 +37,7 @@ struct surface_format_info {
uint8_t input_vb;
uint8_t streamed_output_vb;
uint8_t color_processing;
-   uint8_t lossless_compression;
+   uint8_t ccs_e;
 };
 
 /* This macro allows us to write the table almost as it appears in the PRM,
@@ -438,13 +438,13 @@ isl_format_supports_vertex_fetch(const struct 
gen_device_info *devinfo,
 }
 
 bool
-isl_format_supports_lossless_compression(const struct gen_device_info *devinfo,
- enum isl_format format)
+isl_format_supports_ccs_e(const struct gen_device_info *devinfo,
+  enum isl_format format)
 {
if (!format_info[format].exists)
   return false;
 
-   return format_gen(devinfo) >= format_info[format].lossless_compression;
+   return format_gen(devinfo) >= format_info[format].ccs_e;
 }
 
 bool
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 1c42821..94436ca 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -229,7 +229,7 @@ make_surface(const struct anv_device *dev,
  * leave compression on at all times for these formats.
  */
 if (!(vk_info->flags & VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT) &&
-isl_format_supports_lossless_compression(>info, format)) {
+isl_format_supports_ccs_e(>info, format)) {
if (vk_info->usage & VK_IMAGE_USAGE_STORAGE_BIT) {
   /*
* For now, we leave compression off for anything that may
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index b6b7f74..505012a 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -266,8 +266,7 @@ color_attachment_compute_aux_usage(struct anv_device 
*device,
   att_state->fast_clear = false;
}
 
-   if (isl_format_supports_lossless_compression(>info,
-iview->isl.format)) {
+   if (isl_format_supports_ccs_e(>info, iview->isl.format)) {
   att_state->aux_usage = ISL_AUX_USAGE_CCS_E;
   att_state->input_aux_usage = ISL_AUX_USAGE_CCS_E;
} else if (att_state->fast_clear) {
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 071de11..7240b1f 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -208,8 +208,7 @@ intel_texture_view_requires_resolve(struct brw_context *brw,
 
const uint32_t brw_format = brw_format_for_mesa_format(intel_tex->_Format);
 
-   if (isl_format_supports_lossless_compression(>screen->devinfo,
-brw_format))
+   if (isl_format_supports_ccs_e(>screen->devinfo, brw_format))
   return false;
 
perf_debug("Incompatible sampling format (%s) for rbc (%s)\n",
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index a6fadf9..177b530 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -447,8 +447,7 @@ 

[Mesa-dev] [PATCH 2/5] intel/isl: Add a supports_ccs_d helper

[Jason Ekstrand]

Nothing uses this yet but it serves as a nice bit of documentation
that's relatively easy to find.
---
 src/intel/isl/isl.h|  2 ++
 src/intel/isl/isl_format.c | 15 +++
 2 files changed, 17 insertions(+)

diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index bdc5ebf..47e4a1e 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -1040,6 +1040,8 @@ bool isl_format_supports_filtering(const struct 
gen_device_info *devinfo,
enum isl_format format);
 bool isl_format_supports_vertex_fetch(const struct gen_device_info *devinfo,
   enum isl_format format);
+bool isl_format_supports_ccs_d(const struct gen_device_info *devinfo,
+   enum isl_format format);
 bool isl_format_supports_ccs_e(const struct gen_device_info *devinfo,
enum isl_format format);
 bool isl_format_supports_multisampling(const struct gen_device_info *devinfo,
diff --git a/src/intel/isl/isl_format.c b/src/intel/isl/isl_format.c
index ebc8ec9..2705595 100644
--- a/src/intel/isl/isl_format.c
+++ b/src/intel/isl/isl_format.c
@@ -437,6 +437,21 @@ isl_format_supports_vertex_fetch(const struct 
gen_device_info *devinfo,
return format_gen(devinfo) >= format_info[format].input_vb;
 }
 
+/**
+ * Returns true if the given format can support single-sample fast clears.
+ */
+bool
+isl_format_supports_ccs_d(const struct gen_device_info *devinfo,
+  enum isl_format format)
+{
+   if (!isl_format_supports_rendering(devinfo, format))
+  return false;
+
+   const struct isl_format_layout *fmtl = isl_format_get_layout(format);
+
+   return fmtl->bpb == 32 || fmtl->bpb == 64 || fmtl->bpb == 128;
+}
+
 bool
 isl_format_supports_ccs_e(const struct gen_device_info *devinfo,
   enum isl_format format)
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 4/5] intel/isl: Assert that we don't use CCS for storage images

[Jason Ekstrand]

I enabled CCS for storage images in the Vulkan driver and ran it through
the CTS.  It didn't result in any hangs but it demonstrated that the data
port cannot handle CCS.
---
 src/intel/isl/isl_surface_state.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/intel/isl/isl_surface_state.c 
b/src/intel/isl/isl_surface_state.c
index c7b220b..29ec289 100644
--- a/src/intel/isl/isl_surface_state.c
+++ b/src/intel/isl/isl_surface_state.c
@@ -537,6 +537,12 @@ isl_genX(surf_fill_state_s)(const struct isl_device *dev, 
void *state,
 
 #if GEN_GEN >= 7
if (info->aux_surf && info->aux_usage != ISL_AUX_USAGE_NONE) {
+  /* The docs don't appear to say anything whatsoever about compression
+   * and the data port.  Testing seems to indicate that the data port
+   * completely ignores the AuxiliarySurfaceMode field.
+   */
+  assert(!(info->view->usage & ISL_SURF_USAGE_STORAGE_BIT));
+
   struct isl_tile_info tile_info;
   isl_surf_get_tile_info(dev, info->aux_surf, _info);
   uint32_t pitch_in_tiles =
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 3/5] intel/isl: Add a formats_are_ccs_e_compatible helper

[Jason Ekstrand]

---
 src/intel/blorp/blorp_blit.c |  6 ++
 src/intel/isl/isl.h  |  4 
 src/intel/isl/isl_format.c   | 31 +++
 3 files changed, 41 insertions(+)

diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
index 8a944fb..b89a112 100644
--- a/src/intel/blorp/blorp_blit.c
+++ b/src/intel/blorp/blorp_blit.c
@@ -2395,11 +2395,17 @@ blorp_copy(struct blorp_batch *batch,
}
 
if (params.src.aux_usage == ISL_AUX_USAGE_CCS_E) {
+  assert(isl_formats_are_ccs_e_compatible(batch->blorp->isl_dev->info,
+  src_surf->surf->format,
+  params.src.view.format));
   params.src.clear_color =
  bitcast_color_value_to_uint(params.src.clear_color, src_fmtl);
}
 
if (params.dst.aux_usage == ISL_AUX_USAGE_CCS_E) {
+  assert(isl_formats_are_ccs_e_compatible(batch->blorp->isl_dev->info,
+  dst_surf->surf->format,
+  params.dst.view.format));
   params.dst.clear_color =
  bitcast_color_value_to_uint(params.dst.clear_color, dst_fmtl);
}
diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index 47e4a1e..eff7218 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -1047,6 +1047,10 @@ bool isl_format_supports_ccs_e(const struct 
gen_device_info *devinfo,
 bool isl_format_supports_multisampling(const struct gen_device_info *devinfo,
enum isl_format format);
 
+bool isl_formats_are_ccs_e_compatible(const struct gen_device_info *devinfo,
+  enum isl_format format1,
+  enum isl_format format2);
+
 bool isl_format_has_unorm_channel(enum isl_format fmt) ATTRIBUTE_CONST;
 bool isl_format_has_snorm_channel(enum isl_format fmt) ATTRIBUTE_CONST;
 bool isl_format_has_ufloat_channel(enum isl_format fmt) ATTRIBUTE_CONST;
diff --git a/src/intel/isl/isl_format.c b/src/intel/isl/isl_format.c
index 2705595..5e2d796 100644
--- a/src/intel/isl/isl_format.c
+++ b/src/intel/isl/isl_format.c
@@ -497,6 +497,37 @@ isl_format_supports_multisampling(const struct 
gen_device_info *devinfo,
}
 }
 
+/**
+ * Returns true if the two formats are "CCS_E compatible" meaning that you can
+ * render in one format with CCS_E enabled and then texture using the other
+ * format without needing a resolve.
+ *
+ * Note: Even if the formats are compatible, special care must be taken if a
+ * clear color is involved because the encoding of the clear color is heavily
+ * format-dependent.
+ */
+bool
+isl_formats_are_ccs_e_compatible(const struct gen_device_info *devinfo,
+ enum isl_format format1,
+ enum isl_format format2)
+{
+   /* They must support CCS_E */
+   if (!isl_format_supports_ccs_e(devinfo, format1) ||
+   !isl_format_supports_ccs_e(devinfo, format1))
+  return false;
+
+   const struct isl_format_layout *fmtl1 = isl_format_get_layout(format1);
+   const struct isl_format_layout *fmtl2 = isl_format_get_layout(format2);
+
+   /* The compression used by CCS is not dependent on the actual data encoding
+* of the format but only depends on the bit-layout of the channels.
+*/
+   return fmtl1->channels.r.bits == fmtl2->channels.r.bits &&
+  fmtl1->channels.g.bits == fmtl2->channels.g.bits &&
+  fmtl1->channels.b.bits == fmtl2->channels.b.bits &&
+  fmtl1->channels.a.bits == fmtl2->channels.a.bits;
+}
+
 static inline bool
 isl_format_has_channel_type(enum isl_format fmt, enum isl_base_type type)
 {
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 5/5] anv: Remove the finishme for CCS_E with storage images

[Jason Ekstrand]

The data port can't handle CCS at all so replace the finishme with
better comments.
---
 src/intel/vulkan/anv_image.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 94436ca..e59ef4d 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -225,22 +225,15 @@ make_surface(const struct anv_device *dev,
 /* For images created without MUTABLE_FORMAT_BIT set, we know that
  * they will always be used with the original format.  In
  * particular, they will always be used with a format that
- * supports color compression.  This means that it's safe to just
- * leave compression on at all times for these formats.
+ * supports color compression.  If it's never used as a storage
+ * image, then it will only be used through the sampler or the as
+ * a render target.  This means that it's safe to just leave
+ * compression on at all times for these formats.
  */
-if (!(vk_info->flags & VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT) &&
+if (!(vk_info->usage & VK_IMAGE_USAGE_STORAGE_BIT) &&
+!(vk_info->flags & VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT) &&
 isl_format_supports_ccs_e(>info, format)) {
-   if (vk_info->usage & VK_IMAGE_USAGE_STORAGE_BIT) {
-  /*
-   * For now, we leave compression off for anything that may
-   * be used as a storage image.  This is because accessing
-   * storage images may involve ccs-incompatible views or even
-   * untyped messages which don't support compression at all.
-   */
-  anv_finishme("Enable CCS for storage images");
-   } else {
-  image->aux_usage = ISL_AUX_USAGE_CCS_E;
-   }
+   image->aux_usage = ISL_AUX_USAGE_CCS_E;
 }
  }
   }
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 2/5] configure.ac: add swr to the gallium drivers list.

[Emil Velikov]

From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 93e4a1a8a9..0aec5326ba 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1240,7 +1240,7 @@ GALLIUM_DRIVERS_DEFAULT="r300,r600,svga,swrast"
 AC_ARG_WITH([gallium-drivers],
 [AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@],
 [comma delimited Gallium drivers list, e.g.
-
"i915,ilo,nouveau,r300,r600,radeonsi,freedreno,svga,swrast,vc4,virgl,etnaviv,imx"
+
"i915,ilo,nouveau,r300,r600,radeonsi,freedreno,svga,swrast,swr,vc4,virgl,etnaviv,imx"
 @<:@default=r300,r600,svga,swrast@:>@])],
 [with_gallium_drivers="$withval"],
 [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
-- 
2.11.0

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

[Mesa-dev] [PATCH 5/5] travis: use both cores for make/make check

[Emil Velikov]

From: Emil Velikov 

The instance offers 2 cores, so use them to speed things up.

Signed-off-by: Emil Velikov 
---
 .travis.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index b5dad7f3ea..e7f23409a0 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -106,7 +106,7 @@ script:
 
--with-gallium-drivers=i915,nouveau,r300,r600,freedreno,svga,swrast,vc4,virgl,etnaviv,imx
 --disable-llvm-shared-libs
 ;
-  make && make check;
+  make -j2 && make -j2 check;
 elif test x$BUILD = xscons; then
   scons;
 fi
-- 
2.11.0

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

[Mesa-dev] [PATCH 3/5] travis: correct libdrm required regex to also track libdrm itself

[Emil Velikov]

From: Emil Velikov 

The current regex was tracking only the libdrm_foo packages, while with
recent changed we bumped only (and rightfully so) libdrm.

Fix the regex to track any libdrm package.

Cc: Rhys Kidd 
Cc: Eric Anholt 
Signed-off-by: Emil Velikov 
---
 .travis.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index dfbc052a7d..e8426e96a2 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -47,7 +47,7 @@ install:
 
   # Since libdrm gets updated in configure.ac regularly, try to pick up the
   # latest version from there.
-  - for line in `grep "^LIBDRM_.*_REQUIRED=" configure.ac`; do
+  - for line in `grep "^LIBDRM.*_REQUIRED=" configure.ac`; do
   old_ver=`echo $LIBDRM_VERSION | sed 's/libdrm-//'`;
   new_ver=`echo $line | sed 's/.*REQUIRED=//'`;
   if `echo "$old_ver,$new_ver" | tr ',' '\n' | sort -Vc 2> /dev/null`; then
-- 
2.11.0

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

[Mesa-dev] [PATCH 1/5] configure.ac: list all the dri-drivers in the help string

[Emil Velikov]

From: Emil Velikov 

It's unlikely that any of the additions come as a suprise to anyone
i915, nouveau, radeon, r200). Regardless, state clearly what's
available.

Signed-off-by: Emil Velikov 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index b1fb2c3c54..93e4a1a8a9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1623,7 +1623,7 @@ dnl Which drivers to build - default is chosen by platform
 AC_ARG_WITH([dri-drivers],
 [AS_HELP_STRING([--with-dri-drivers@<:@=DIRS...@:>@],
 [comma delimited classic DRI drivers list, e.g.
-"swrast,i965,radeon" @<:@default=auto@:>@])],
+"i915,i965,nouveau,radeon,r200,swrast" @<:@default=auto@:>@])],
 [with_dri_drivers="$withval"],
 [with_dri_drivers=auto])
 
-- 
2.11.0

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

[Mesa-dev] [PATCH 4/5] travis: add nearly all gallium drivers to the list

[Emil Velikov]

From: Emil Velikov 

Note: we need the explicit --enable-freedreno for libdrm since the
latter is 'smart' and disables it if building on !arm platforms.

The ilo, radeonsi and swr are explicitly left out since the former is on
its way out, while the latter two require 'too-recent' LLVM - 3.6

Signed-off-by: Emil Velikov 
---
Sadly we cannot toggle either ANV or RADV since the former requires
memfd and the latter LLVM 3.9. Both of which are missing in the VM.
---
 .travis.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index e8426e96a2..b5dad7f3ea 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -92,7 +92,7 @@ install:
 
   - wget http://dri.freedesktop.org/libdrm/$LIBDRM_VERSION.tar.bz2
   - tar -jxvf $LIBDRM_VERSION.tar.bz2
-  - (cd $LIBDRM_VERSION && ./configure --prefix=$HOME/prefix --enable-vc4 
--enable-etnaviv-experimental-api && make install)
+  - (cd $LIBDRM_VERSION && ./configure --prefix=$HOME/prefix --enable-vc4 
--enable-freedreno --enable-etnaviv-experimental-api && make install)
 
   - wget $XORG_RELEASES/lib/$LIBXSHMFENCE_VERSION.tar.bz2
   - tar -jxvf $LIBXSHMFENCE_VERSION.tar.bz2
@@ -103,7 +103,7 @@ script:
   ./autogen.sh --enable-debug
 --with-egl-platforms=x11,drm
 --with-dri-drivers=i915,i965,radeon,r200,swrast,nouveau
---with-gallium-drivers=svga,swrast,vc4,virgl,r300,r600,etnaviv,imx
+
--with-gallium-drivers=i915,nouveau,r300,r600,freedreno,svga,swrast,vc4,virgl,etnaviv,imx
 --disable-llvm-shared-libs
 ;
   make && make check;
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH] Revert "i915: Always enable GL 2.0 support."

[Kenneth Graunke]

On Wednesday, February 1, 2017 12:35:15 PM PST Eero Tamminen wrote:
> Hi,
> 
> On 31.01.2017 21:12, Matt Turner wrote:
> > On Sun, Jan 29, 2017 at 8:29 PM, Kenneth Graunke  
> > wrote:
> >> On Sunday, January 29, 2017 6:20:10 PM PST Matt Turner wrote:
> >>> This partially reverts commit 97217a40f97cdeae0304798b607f704deb0c3558.
> >>> It leaves ES 2.0 support in place per Ian's suggestion, because ES 2.0
> >>> is designed to work on hardware like i915.
> >>
> >> Your commit message should mention why dropping from OpenGL 2.1 to 1.4
> >> is a good thing.
> >>
> >> (IIRC it's because Chrome (and other apps?) use really slow paths with
> >> 2.1, and so the general usability of the system is likely to be worse.)
>  >
> > Yeah, I'll add
> 
> Has that been profiled?  I assume the issue is the constant uploads 
> Chrome does for the Browser's CPU rendered page content updates.  There 
> are not many other workloads that utilize GPU as inefficiently as 
> current browsers.
> 
> 
>   - Eero

I figured it was just software rendering everything, given that there's
no vertex shading support and only 64 fragment shader instructions...

prog_execute isn't exactly a state-of-the-art interpreter, either.

--Ken


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

Re: [Mesa-dev] [PATCH] docs: add link to http://mesamatrix.net/

[Kenneth Graunke]

On Wednesday, February 1, 2017 2:36:02 PM PST Brian Paul wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95460
> ---
>  docs/features.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/docs/features.txt b/docs/features.txt
> index 55b1fbb..300442b 100644
> --- a/docs/features.txt
> +++ b/docs/features.txt
> @@ -335,3 +335,6 @@ we DO NOT WANT implementations of these extensions for 
> Mesa.
>  
>  More info about these features and the work involved can be found at
>  http://dri.freedesktop.org/wiki/MissingFunctionality
> +
> +Also, a graphical representation of this information can be found at
> +http://mesamatrix.net/
> 

Sounds good to me.


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

Re: [Mesa-dev] [PATCHv2 3/4] configure.ac: Separate HAVE_LLVM defines for gallium and radv

[Dave Airlie]

Just make radv depend on enable-gallium-llvm.

I really don't want to make the #defines into the spaghetti this introduces.

Dave.

> diff --git a/configure.ac b/configure.ac
> index f956df5120..5101e3bb0b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1001,7 +1001,6 @@ llvm_set_environment_variables() {
>  LLVM_VERSION_INT="${LLVM_VERSION_MAJOR}${LLVM_VERSION_MINOR}"
>  fi
>
> -DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT 
> -DMESA_LLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
>  FOUND_LLVM=yes
>  USE_LLVM=no
>  else
> @@ -1775,6 +1774,7 @@ if test -n "$with_vulkan_drivers"; then
>  PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >= 
> $LIBDRM_AMDGPU_REQUIRED])
>  radeon_llvm_check $LLVM_REQUIRED_RADV "radv"
>  HAVE_RADEON_VULKAN=yes;
> +DEFINES="${DEFINES} -DHAVE_LLVM_RADV=0x0$LLVM_VERSION_INT 
> -DMESA_LLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
>  ;;
>  *)
>  AC_MSG_ERROR([Vulkan driver '$driver' does not exist])
> @@ -2407,6 +2407,7 @@ if test "x$enable_gallium_llvm" == "xyes"; then
>  llvm_add_default_components "gallium"
>
>  USE_LLVM_GALLIUM=yes
> +DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT 
> -DMESA_LLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
>  else
>  USE_LLVM_GALLIUM=no
>  fi
> diff --git a/src/amd/common/ac_llvm_helper.cpp 
> b/src/amd/common/ac_llvm_helper.cpp
> index 594339ee8c..154156b8a3 100644
> --- a/src/amd/common/ac_llvm_helper.cpp
> +++ b/src/amd/common/ac_llvm_helper.cpp
> @@ -26,7 +26,7 @@
>  /* based on Marek's patch to lp_bld_misc.cpp */
>
>  // Workaround http://llvm.org/PR23628
> -#if HAVE_LLVM >= 0x0307
> +#if MESA_LLVM_VERSION >= 0x0307
>  #  pragma push_macro("DEBUG")
>  #  undef DEBUG
>  #endif
> diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
> index f3cab921ba..7060a2f003 100644
> --- a/src/amd/common/ac_llvm_util.c
> +++ b/src/amd/common/ac_llvm_util.c
> @@ -22,6 +22,7 @@
>   * of the Software.
>   *
>   */
> +
>  /* based on pieces from si_pipe.c and radeon_llvm_emit.c */
>  #include "ac_llvm_util.h"
>
> @@ -37,7 +38,7 @@
>
>  static void ac_init_llvm_target()
>  {
> -#if HAVE_LLVM < 0x0307
> +#if MESA_LLVM_VERSION < 0x0307
> LLVMInitializeR600TargetInfo();
> LLVMInitializeR600Target();
> LLVMInitializeR600TargetMC();
> @@ -99,7 +100,7 @@ static const char *ac_get_llvm_processor_name(enum 
> radeon_family family)
> return "iceland";
> case CHIP_CARRIZO:
> return "carrizo";
> -#if HAVE_LLVM <= 0x0307
> +#if MESA_LLVM_VERSION <= 0x0307
> case CHIP_FIJI:
> return "tonga";
> case CHIP_STONEY:
> @@ -110,7 +111,7 @@ static const char *ac_get_llvm_processor_name(enum 
> radeon_family family)
> case CHIP_STONEY:
> return "stoney";
>  #endif
> -#if HAVE_LLVM <= 0x0308
> +#if MESA_LLVM_VERSION <= 0x0308
> case CHIP_POLARIS10:
> return "tonga";
> case CHIP_POLARIS11:
> @@ -166,7 +167,7 @@ ac_llvm_context_init(struct ac_llvm_context *ctx, 
> LLVMContextRef context)
> ctx->fpmath_md_2p5_ulp = LLVMMDNodeInContext(ctx->context, args, 1);
>  }
>
> -#if HAVE_LLVM < 0x0400
> +#if MESA_LLVM_VERSION < 0x0400
>  static LLVMAttribute ac_attr_to_llvm_attr(enum ac_func_attr attr)
>  {
> switch (attr) {
> @@ -209,7 +210,7 @@ ac_add_function_attr(LLVMValueRef function,
>   enum ac_func_attr attr)
>  {
>
> -#if HAVE_LLVM < 0x0400
> +#if MESA_LLVM_VERSION < 0x0400
> LLVMAttribute llvm_attr = ac_attr_to_llvm_attr(attr);
> if (attr_idx == -1) {
>LLVMAddFunctionAttr(function, llvm_attr);
> @@ -329,7 +330,7 @@ build_cube_intrinsic(struct ac_llvm_context *ctx,
>  {
> LLVMBuilderRef builder = ctx->builder;
>
> -   if (HAVE_LLVM >= 0x0309) {
> +   if (MESA_LLVM_VERSION >= 0x0309) {
> LLVMTypeRef f32 = ctx->f32;
>
> out->stc[1] = ac_emit_llvm_intrinsic(ctx, 
> "llvm.amdgcn.cubetc",
> diff --git a/src/amd/common/ac_llvm_util.h b/src/amd/common/ac_llvm_util.h
> index c07f67ab8b..64af30228d 100644
> --- a/src/amd/common/ac_llvm_util.h
> +++ b/src/amd/common/ac_llvm_util.h
> @@ -24,6 +24,20 @@
>   */
>  #pragma once
>
> +/*
> + * Since HAVE_LLVM means --enable-gallium-llvm and we cannot change that we
> + * need to indicate/track the LLVM version in a separate way 
> (HAVE_LLVM_RADV).
> + *
> + * Strictly speaking we could get away with HAVE_LLVM_RADV alone, but things
> + * are quite fragile and on their way out since this work is mostly -stable
> + * fixes to get all the crazy permutations building again.
> + */
> +#if defined(HAVE_LLVM)
> +#  define MESA_LLVM_VERSION HAVE_LLVM
> +#elif defined(HAVE_LLVM_RADV)
> +#  define MESA_LLVM_VERSION HAVE_LLVM_RADV
> +#endif
> +
>  #include 
>  #include 
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 

Re: [Mesa-dev] [PATCH 1/2] gallivm: add no-signed-zeros-fp-math option to lp_create_builder

[Brian Paul]

On 01/30/2017 11:44 AM, Marek Olšák wrote:

From: Marek Olšák 

---
  src/gallium/auxiliary/gallivm/lp_bld_misc.cpp   | 15 ---
  src/gallium/auxiliary/gallivm/lp_bld_misc.h |  8 +++-
  src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c |  6 +-
  3 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp 
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 498bbd7..3063a3c 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -735,24 +735,33 @@ extern "C" bool
  lp_is_function(LLVMValueRef v)
  {
  #if HAVE_LLVM >= 0x0309
return LLVMGetValueKind(v) == LLVMFunctionValueKind;
  #else
return llvm::isa(llvm::unwrap(v));
  #endif
  }

  extern "C" LLVMBuilderRef
-lp_create_builder(LLVMContextRef ctx, bool unsafe_fpmath)
+lp_create_builder(LLVMContextRef ctx, enum lp_builder_type type)
  {
 LLVMBuilderRef builder = LLVMCreateBuilderInContext(ctx);

  #if HAVE_LLVM >= 0x0308
-   if (unsafe_fpmath) {
-  llvm::FastMathFlags flags;
+   llvm::FastMathFlags flags;
+
+   switch (type) {
+   case LP_BUILDER_DEFAULT:
+  break;
+   case LP_BUILDER_NO_SIGNED_ZEROS_FP_MATH:
+  flags.setNoSignedZeros();
+  llvm::unwrap(builder)->setFastMathFlags(flags);
+  break;
+   case LP_BUILDER_UNSAFE_FP_MATH:
flags.setUnsafeAlgebra();
llvm::unwrap(builder)->setFastMathFlags(flags);
+  break;
 }
  #endif

 return builder;
  }
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.h 
b/src/gallium/auxiliary/gallivm/lp_bld_misc.h
index c499a6f..736a916 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.h
@@ -75,19 +75,25 @@ lp_free_memory_manager(LLVMMCJITMemoryManagerRef memorymgr);

  extern void
  lp_add_attr_dereferenceable(LLVMValueRef val, uint64_t bytes);

  extern LLVMValueRef
  lp_get_called_value(LLVMValueRef call);

  extern bool
  lp_is_function(LLVMValueRef v);

+enum lp_builder_type {
+   LP_BUILDER_DEFAULT,
+   LP_BUILDER_NO_SIGNED_ZEROS_FP_MATH,
+   LP_BUILDER_UNSAFE_FP_MATH,
+};


lp_builder_type seems a little generic.  How about something like 
lp_float_behavior?


-Brian



+
  extern LLVMBuilderRef
-lp_create_builder(LLVMContextRef ctx, bool unsafe_fpmath);
+lp_create_builder(LLVMContextRef ctx, enum lp_builder_type type);

  #ifdef __cplusplus
  }
  #endif


  #endif /* !LP_BLD_MISC_H */
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
index 4f355e5..68153af 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
@@ -1267,22 +1267,26 @@ void si_llvm_context_init(struct si_shader_context *ctx,
ctx->screen = sscreen;
ctx->tm = tm;
ctx->type = info ? info->processor : -1;

ctx->gallivm.context = LLVMContextCreate();
ctx->gallivm.module = LLVMModuleCreateWithNameInContext("tgsi",
ctx->gallivm.context);
LLVMSetTarget(ctx->gallivm.module, "amdgcn--");

bool unsafe_fpmath = (sscreen->b.debug_flags & DBG_UNSAFE_MATH) != 0;
+   enum lp_builder_type builder_type =
+   unsafe_fpmath ? LP_BUILDER_UNSAFE_FP_MATH :
+   LP_BUILDER_DEFAULT;
+
ctx->gallivm.builder = lp_create_builder(ctx->gallivm.context,
-unsafe_fpmath);
+builder_type);

ac_llvm_context_init(>ac, ctx->gallivm.context);
ctx->ac.module = ctx->gallivm.module;
ctx->ac.builder = ctx->gallivm.builder;

struct lp_build_tgsi_context *bld_base = >bld_base;

bld_base->info = info;

if (info && info->array_max[TGSI_FILE_TEMPORARY] > 0) {



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

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

Captain Crutches  changed:

   What|Removed |Added

 CC||captaincrutc...@gmail.com

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

Re: [Mesa-dev] [PATCH 2/3] vc4: fix arm64 build with Neon

[Eric Anholt]

Emil Velikov  writes:

> On 30 January 2017 at 22:54, Rob Herring  wrote:
>> The addition of Neon assembly breaks on arm64 builds because the assembly
>> syntax is different. For now, restrict Neon to ARMv7 builds.
>>
>> Signed-off-by: Rob Herring 
>> ---
>>  src/gallium/drivers/vc4/vc4_tiling.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/drivers/vc4/vc4_tiling.h 
>> b/src/gallium/drivers/vc4/vc4_tiling.h
>> index 218130b2007c..ba1ad6fb3f7d 100644
>> --- a/src/gallium/drivers/vc4/vc4_tiling.h
>> +++ b/src/gallium/drivers/vc4/vc4_tiling.h
>> @@ -87,7 +87,7 @@ void vc4_store_tiled_image(void *dst, uint32_t dst_stride,
>>   * should extend this to have some runtime detection of being built for 
>> ARMv6
>>   * on a Pi 2+.
>>   */
>> -#if defined(__ARM_ARCH) && __ARM_ARCH >= 7
>> +#if defined(__ARM_ARCH) && __ARM_ARCH == 7
>>  #define NEON_SUFFIX(x) x ## _neon
>>  #else
>>  #define NEON_SUFFIX(x) x ## _base
> Things seem quite inconsistent in the area. Not sure if they are
> left-overs from dev stage or I'm missing something subtle.

This is left over from me landing the branch before writing the runtime
CPU detection that we need, as noted in the comment.

> Thanks
> Emil
> P.S. Did you have some ideas to have separate winsys (similar to
> virgl) - one for HW and another for SIM ?
> Is there any progress in the area ?

I took a serious look at it, but it appeared to be less capable than
what I have (it does sim under a swrast driver, rather than attaching to
GEM and appearing like a full HW driver that you could use for, say,
Xorg's backend).


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] gallium: add a common uploader to pipe_context

[Brian Paul]

On 01/27/2017 04:00 AM, Marek Olšák wrote:

On Fri, Jan 27, 2017 at 10:05 AM, Nicolai Hähnle  wrote:

On 27.01.2017 00:51, Marek Olšák wrote:


From: Marek Olšák 

For lower memory usage and more efficient updates of the buffer residency
list. (e.g. if drivers keep seeing the same buffer for many consecutive
"add" calls, the calls can be turned into no-ops trivially)



This makes sense to me, but how are you planning to deal with the bind
flags? They are currently set differently for different upload mgrs. We
should probably do away with them entirely anyway.


Drivers can set the bind flags they need. Some drivers will set all 3
bind flags. Other drivers don't have to set any.


I need to look into this part more closely.  I think we may have trouble 
mixing constants with index/vertex data in our VMware driver...


-Brian

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

[Mesa-dev] [Bug 95460] Please add more drivers (freedreno, virgl) to features.txt status document

[bugzilla-daemon]

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

--- Comment #5 from Brian Paul  ---
I'll try to add a link in the docs to point to https://mesamatrix.net

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

[Mesa-dev] [PATCH] docs: add link to http://mesamatrix.net/

[Brian Paul]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95460
---
 docs/features.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/docs/features.txt b/docs/features.txt
index 55b1fbb..300442b 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -335,3 +335,6 @@ we DO NOT WANT implementations of these extensions for Mesa.
 
 More info about these features and the work involved can be found at
 http://dri.freedesktop.org/wiki/MissingFunctionality
+
+Also, a graphical representation of this information can be found at
+http://mesamatrix.net/
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] anv: Don't use bogus alpha swizzles

[Anuj Phogat]

On Wed, Feb 1, 2017 at 12:39 PM, Jason Ekstrand  wrote:
>
> For RGB formats in Vulkan, we use the corresponding RGBA format with a
> swizzle of RGB1.  While this swizzle is exactly what we want for
> texturing, it's not allowed for rendering according to the docs.  While
> we haven't been getting hangs or anything, we should probably obey the
> docs.  This commit just sanitizes all render swizzles so that the alpha
> channel maps to ALPHA.
>
> Cc: Anuj Phogat 
> ---
>  src/intel/vulkan/anv_blorp.c   |  9 ++---
>  src/intel/vulkan/anv_private.h | 15 +++
>  src/intel/vulkan/genX_cmd_buffer.c |  1 +
>  3 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index 2edd071..2cf972b 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -503,7 +503,8 @@ void anv_CmdBlitImage(
>   blorp_blit(, , src_res->mipLevel, src_z,
>  src_format.isl_format, src_format.swizzle,
>  , dst_res->mipLevel, dst_z,
> -dst_format.isl_format, dst_format.swizzle,
> +dst_format.isl_format,
> +anv_swizzle_for_render(dst_format.swizzle),
>  src_x0, src_y0, src_x1, src_y1,
>  dst_x0, dst_y0, dst_x1, dst_y1,
>  gl_filter, flip_x, flip_y);
> @@ -831,7 +832,8 @@ void anv_CmdClearColorImage(
>   }
>
>   blorp_clear(, ,
> - src_format.isl_format, src_format.swizzle,
> + src_format.isl_format,
> + anv_swizzle_for_render(src_format.swizzle),
>   level, base_layer, layer_count,
>   0, 0, level_width, level_height,
>   vk_to_isl_color(*pColor), color_write_disable);
> @@ -1216,7 +1218,8 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
> *cmd_buffer)
>   cmd_buffer->state.pending_pipe_bits |=
>  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
>} else {
> - blorp_clear(, , iview->isl.format, iview->isl.swizzle,
> + blorp_clear(, , iview->isl.format,
> + anv_swizzle_for_render(iview->isl.swizzle),
>   iview->isl.base_level,
>   iview->isl.base_array_layer, fb->layers,
>   render_area.offset.x, render_area.offset.y,
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
> index 0cc6550..a0cb35c 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -1552,6 +1552,21 @@ anv_get_isl_format(const struct gen_device_info 
> *devinfo, VkFormat vk_format,
> return anv_get_format(devinfo, vk_format, aspect, tiling).isl_format;
>  }
>
> +static inline struct isl_swizzle
> +anv_swizzle_for_render(struct isl_swizzle swizzle)
> +{
> +   /* Sometimes the swizzle will have alpha map to one.  We do this to fake
> +* RGB as RGBA for texturing
> +*/
> +   assert(swizzle.a == ISL_CHANNEL_SELECT_ONE ||
> +  swizzle.a == ISL_CHANNEL_SELECT_ALPHA);
> +
> +   /* But it doesn't matter what we render to that channel */
> +   swizzle.a = ISL_CHANNEL_SELECT_ALPHA;
> +
> +   return swizzle;
> +}
> +
>  void
>  anv_pipeline_setup_l3_config(struct anv_pipeline *pipeline, bool needs_slm);
>
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 0ad7cd5..b6b7f74 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -528,6 +528,7 @@ genX(cmd_buffer_setup_attachments)(struct anv_cmd_buffer 
> *cmd_buffer,
>
>  struct isl_view view = iview->isl;
>  view.usage |= ISL_SURF_USAGE_RENDER_TARGET_BIT;
> +view.swizzle = anv_swizzle_for_render(view.swizzle);
>  isl_surf_fill_state(isl_dev,
>  state->attachments[i].color_rt_state.map,
>  .surf = >image->color_surface.isl,
> --
> 2.5.0.400.gff86faf
>
Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99631] segfault with OSVRTrackerView and openscenegraph git master

[bugzilla-daemon]

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

--- Comment #3 from Ilia Mirkin  ---
Candidate patch sent as https://patchwork.freedesktop.org/patch/136383/

Not sure if it's too heavy.

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

[Mesa-dev] [PATCH] vbo: process buffer binding state changes on draw when recording

[Ilia Mirkin]

The VBO module keeps track of any vbo buffers. It updates this list when
receiving an InvalidateState call, however this never happens when
recording draws right now. Make sure that we do all the usual state
updates when recording draws so that the VBO list may be kept up to
date.

Signed-off-by: Ilia Mirkin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99631
---
 src/mesa/vbo/vbo_save_api.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index f648ccc..f8dab0c 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -78,6 +78,7 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
 #include "main/api_arrayelt.h"
 #include "main/vtxfmt.h"
 #include "main/dispatch.h"
+#include "main/state.h"
 #include "util/bitscan.h"
 
 #include "vbo_context.h"
@@ -1159,6 +1160,9 @@ _save_OBE_DrawArrays(GLenum mode, GLint start, GLsizei 
count)
if (save->out_of_memory)
   return;
 
+   /* Make sure to process any VBO binding changes */
+   _mesa_update_state(ctx);
+
_ae_map_vbos(ctx);
 
vbo_save_NotifyBegin(ctx, (mode | VBO_SAVE_PRIM_WEAK
@@ -1202,6 +1206,9 @@ _save_OBE_DrawElementsBaseVertex(GLenum mode, GLsizei 
count, GLenum type,
if (save->out_of_memory)
   return;
 
+   /* Make sure to process any VBO binding changes */
+   _mesa_update_state(ctx);
+
_ae_map_vbos(ctx);
 
if (_mesa_is_bufferobj(indexbuf))
-- 
2.10.2

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

[Mesa-dev] [Bug 99631] segfault with OSVRTrackerView and openscenegraph git master

[bugzilla-daemon]

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

--- Comment #2 from Brian Paul  ---
Thanks for looking into this, Ilia.  If you get stuck, I'll try to look at it
in a few days.

BTW, we should probably create a piglit test for this issue.

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

[Mesa-dev] [Bug 99631] segfault with OSVRTrackerView and openscenegraph git master

[bugzilla-daemon]

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

--- Comment #1 from Ilia Mirkin  ---
The issue appears that the right buffer object isn't mapped. The fact that the
ARRAY_BUFFER is modified doesn't appear to make it into the actx->NewState bit.
The following "fixes" the trace:

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 46175e4..fa78edb 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1707,7 +1707,7 @@ _ae_map_vbos(struct gl_context *ctx)
if (actx->mapped_vbos)
   return;

-   if (actx->NewState)
+   if (actx->NewState || 1)
   _ae_update_state(ctx);

for (i = 0; i < actx->nr_vbos; i++)

Now just need to figure out where NewState is not being updated when it should
be.

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

[Mesa-dev] [PATCH] anv: Don't use bogus alpha swizzles

[Jason Ekstrand]

For RGB formats in Vulkan, we use the corresponding RGBA format with a
swizzle of RGB1.  While this swizzle is exactly what we want for
texturing, it's not allowed for rendering according to the docs.  While
we haven't been getting hangs or anything, we should probably obey the
docs.  This commit just sanitizes all render swizzles so that the alpha
channel maps to ALPHA.

Cc: Anuj Phogat 
---
 src/intel/vulkan/anv_blorp.c   |  9 ++---
 src/intel/vulkan/anv_private.h | 15 +++
 src/intel/vulkan/genX_cmd_buffer.c |  1 +
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 2edd071..2cf972b 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -503,7 +503,8 @@ void anv_CmdBlitImage(
  blorp_blit(, , src_res->mipLevel, src_z,
 src_format.isl_format, src_format.swizzle,
 , dst_res->mipLevel, dst_z,
-dst_format.isl_format, dst_format.swizzle,
+dst_format.isl_format,
+anv_swizzle_for_render(dst_format.swizzle),
 src_x0, src_y0, src_x1, src_y1,
 dst_x0, dst_y0, dst_x1, dst_y1,
 gl_filter, flip_x, flip_y);
@@ -831,7 +832,8 @@ void anv_CmdClearColorImage(
  }
 
  blorp_clear(, ,
- src_format.isl_format, src_format.swizzle,
+ src_format.isl_format,
+ anv_swizzle_for_render(src_format.swizzle),
  level, base_layer, layer_count,
  0, 0, level_width, level_height,
  vk_to_isl_color(*pColor), color_write_disable);
@@ -1216,7 +1218,8 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
*cmd_buffer)
  cmd_buffer->state.pending_pipe_bits |=
 ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
   } else {
- blorp_clear(, , iview->isl.format, iview->isl.swizzle,
+ blorp_clear(, , iview->isl.format,
+ anv_swizzle_for_render(iview->isl.swizzle),
  iview->isl.base_level,
  iview->isl.base_array_layer, fb->layers,
  render_area.offset.x, render_area.offset.y,
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 0cc6550..a0cb35c 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1552,6 +1552,21 @@ anv_get_isl_format(const struct gen_device_info 
*devinfo, VkFormat vk_format,
return anv_get_format(devinfo, vk_format, aspect, tiling).isl_format;
 }
 
+static inline struct isl_swizzle
+anv_swizzle_for_render(struct isl_swizzle swizzle)
+{
+   /* Sometimes the swizzle will have alpha map to one.  We do this to fake
+* RGB as RGBA for texturing
+*/
+   assert(swizzle.a == ISL_CHANNEL_SELECT_ONE ||
+  swizzle.a == ISL_CHANNEL_SELECT_ALPHA);
+
+   /* But it doesn't matter what we render to that channel */
+   swizzle.a = ISL_CHANNEL_SELECT_ALPHA;
+
+   return swizzle;
+}
+
 void
 anv_pipeline_setup_l3_config(struct anv_pipeline *pipeline, bool needs_slm);
 
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 0ad7cd5..b6b7f74 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -528,6 +528,7 @@ genX(cmd_buffer_setup_attachments)(struct anv_cmd_buffer 
*cmd_buffer,
 
 struct isl_view view = iview->isl;
 view.usage |= ISL_SURF_USAGE_RENDER_TARGET_BIT;
+view.swizzle = anv_swizzle_for_render(view.swizzle);
 isl_surf_fill_state(isl_dev,
 state->attachments[i].color_rt_state.map,
 .surf = >image->color_surface.isl,
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH] gallium: Reduce trace_dump_box_bytes size by box->x.

[Bruce Cherniak]

If stride is supplied (as either stride or slice_stride),
trace_dump_box_bytes will try to read stride bytes, regardless whether
start address is offset by box->x.  This causes access outside mapped
region, and possible segv. (transfer_map stride and layer_stride are not
adjusted for box dimensions)

Note:  trace_dump_box_bytes only dumps PIPE_BUFFER resources, so there
shouldn't be any complicated boxes.  trace_dump_bytes doesn't handle them
anyway.
---
 src/gallium/drivers/trace/tr_dump.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/trace/tr_dump.c 
b/src/gallium/drivers/trace/tr_dump.c
index b173b8a..591e273 100644
--- a/src/gallium/drivers/trace/tr_dump.c
+++ b/src/gallium/drivers/trace/tr_dump.c
@@ -510,11 +510,13 @@ void trace_dump_box_bytes(const void *data,
   size = 0;
} else {
   enum pipe_format format = resource->format;
-  if (slice_stride)
+  if (slice_stride) {
+ slice_stride -= util_format_get_blockwidth(format) * box->x;
  size = box->depth * slice_stride;
-  else if (stride)
+  } else if (stride) {
+ stride -= util_format_get_blockwidth(format) * box->x;
  size = util_format_get_nblocksy(format, box->height) * stride;
-  else {
+  } else {
  size = util_format_get_nblocksx(format, box->width) * 
util_format_get_blocksize(format);
   }
}
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 2/3] vc4: fix arm64 build with Neon

[Emil Velikov]

On 30 January 2017 at 22:54, Rob Herring  wrote:
> The addition of Neon assembly breaks on arm64 builds because the assembly
> syntax is different. For now, restrict Neon to ARMv7 builds.
>
> Signed-off-by: Rob Herring 
> ---
>  src/gallium/drivers/vc4/vc4_tiling.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/vc4/vc4_tiling.h 
> b/src/gallium/drivers/vc4/vc4_tiling.h
> index 218130b2007c..ba1ad6fb3f7d 100644
> --- a/src/gallium/drivers/vc4/vc4_tiling.h
> +++ b/src/gallium/drivers/vc4/vc4_tiling.h
> @@ -87,7 +87,7 @@ void vc4_store_tiled_image(void *dst, uint32_t dst_stride,
>   * should extend this to have some runtime detection of being built for ARMv6
>   * on a Pi 2+.
>   */
> -#if defined(__ARM_ARCH) && __ARM_ARCH >= 7
> +#if defined(__ARM_ARCH) && __ARM_ARCH == 7
>  #define NEON_SUFFIX(x) x ## _neon
>  #else
>  #define NEON_SUFFIX(x) x ## _base
Things seem quite inconsistent in the area. Not sure if they are
left-overs from dev stage or I'm missing something subtle.

The functions are declared via NEON_TAG macro and used via
NEON_SUFFIX. Both macros seem identical, but... former is guarded by
defined(VC4_BUILD_NEON) alone, and the latter with defined(__ARM_ARCH)
&& __ARM_ARCH == 7. Additionally we have some assembly which is
guarded by defined(VC4_BUILD_NEON) && defined(__ARM_ARCH).
There's a comment about the latter, which is to keep the x86 simulator running.

Wouldn't it be better to have single heuristic used throughout,
something like the following may be reasonable.
#if defined(__ARM_ARCH) && __ARM_ARCH == 7
#define VC4_BUILD_NEON
#endif

One could even have a _base + _neon parts of vc4_load_utile and
vc4_store_utile (not 100% sure here) and then use a single NEON_SUFFIX
(maybe as below) to tag things throughout.

#ifdef VC4_BUILD_NEON
#define NEON_SUFFIX(x) x ## _neon
#else
#define NEON_SUFFIX(x) x ## _base
#endif


As a nice side effect you can then get rid of the libvc4_neon.la static library.

Thanks
Emil
P.S. Did you have some ideas to have separate winsys (similar to
virgl) - one for HW and another for SIM ?
Is there any progress in the area ?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99631] segfault with OSVRTrackerView and openscenegraph git master

[bugzilla-daemon]

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

Bug ID: 99631
   Summary: segfault with OSVRTrackerView and openscenegraph git
master
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: haa...@frickel.club
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 129276
  --> https://bugs.freedesktop.org/attachment.cgi?id=129276=edit
trace that segfaults

It's a very small demo application: https://github.com/OSVR/OSVR-Tracker-Viewer

If you want to reproduce it for debugging, you don't need any OSVR hardware,
just openscenegraph from git (currently
2a7d72c203104275462a5c0871257383ffbcf6a5) and then starting OSVRTrackerView.

What works:

OSVRTrackerView with openscenegraph 3.4
osgviewer that comes with openscenegraph git master

OSVRTrackerView with openscenegraph git master however segfaults immediately:

0xb5652bf4 in _save_Vertex3fv (v=0x0) at vbo/vbo_attrib_tmp.h:275
275ATTR3FV(VBO_ATTRIB_POS, v);
(gdb) bt full
#0  0xb5652bf4 in _save_Vertex3fv (v=0x0) at vbo/vbo_attrib_tmp.h:275
dest = 0x930cc
save = 0x92490
ctx = 0x95b08
#1  0xb53fc8a0 in _ae_ArrayElement (elt=0) at main/api_arrayelt.c:1796
src = 0x0
ctx = 0x95b08
actx = 0x93e50
aa = 0x93e50
at = 0x93fd0
disp = 0x8c070
do_map = 0 '\000'
#2  0xb566edf8 in _save_OBE_DrawArrays (mode=1, start=0, count=16) at
vbo/vbo_save_api.c:1168
ctx = 0x95b08
save = 0x92490
i = 0
#3  0xb6352c50 in glDrawArrays (mode=1, first=0, count=16) at
glapi/glapi_mapi_tmp.h:3847
_tbl = 0x8c070
_func = 0xb566ece8 <_save_OBE_DrawArrays>

trace attached.

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

Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl

[Marek Olšák]

On Tue, Jan 31, 2017 at 11:23 PM, Alex Deucher  wrote:
> On Tue, Jan 31, 2017 at 5:06 PM, Emil Velikov  
> wrote:
>> On 31 January 2017 at 15:43, Deucher, Alexander
>>  wrote:
 -Original Message-
 From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
 Of Dieter Nützel
 Sent: Tuesday, January 31, 2017 6:25 AM
 To: Michel Dänzer
 Cc: Alex Deucher; mesa-dev@lists.freedesktop.org; amd-
 g...@lists.freedesktop.org
 Subject: Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible values in
 DRM_RADEON_GEM_INFO ioctl

 Hello Michel,

 as this is for radeon, do you think this could/should fix
 the wrong reported VRAM size with Unigine_Heaven/-Valley, too?
 Maybe speed things up? ;-)

 Unigine_Valley-1.0

 GPU: Unknown GPU x1
 System memory: 24102 MB
 Video memory:  256 MB
 Sync threads:  7
 Async threads: 8

 I'll try patching openSUSE Kernel:stable 4.9.6-2 with this
 and maybe this could then go into 4.10-rc7 'cause it is a
 bugfix. - Alex?
>>>
>>> This patch just fixes the case of the HUD reporting the wrong amount of 
>>> visible vram.  Most 3D apps just default to 256MB if they don't know how 
>>> much vram is.  The problem is GL never provided a core way to determine how 
>>> much vram is available on a GPU so lots of vendor specific extensions and 
>>> driver specific methods popped up to address this.
>>>
>> vram_size is used for available_texture_mem in st/nine and
>> GLX_RENDERER_VIDEO_MEMORY_MESA via GLX_MESA_query_renderer.
>> So maybe we want this in older/stable kernel and mesa releases ? Not
>> sure how many apps use/honour these though ;-)
>
> vram_size was always correct.  it was just visible vram size that was wrong.

Just to clarify this more: the reported visible vram size currently
has no effect on anything other than scaling the Gallium HUD, which
you can simply suppress if you set the ".d" option to resize it
automatically I think.

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

Re: [Mesa-dev] [PATCH 01/10] gallium: add a common uploader to pipe_context

[Marek Olšák]

FYI, if there are no other comments, I'll push this series.

Marek

On Mon, Jan 30, 2017 at 6:06 PM, Nicolai Hähnle  wrote:
> On 27.01.2017 16:02, Marek Olšák wrote:
>>
>> On Fri, Jan 27, 2017 at 3:38 PM, Roland Scheidegger 
>> wrote:
>>>
>>> Am 27.01.2017 um 12:02 schrieb Marek Olšák:

 From: Marek Olšák 

 For lower memory usage and more efficient updates of the buffer
 residency
 list. (e.g. if drivers keep seeing the same buffer for many consecutive
 "add" calls, the calls can be turned into no-ops trivially)
 ---
  src/gallium/include/pipe/p_context.h | 7 +++
  1 file changed, 7 insertions(+)

 diff --git a/src/gallium/include/pipe/p_context.h
 b/src/gallium/include/pipe/p_context.h
 index 45098c9..5876968 100644
 --- a/src/gallium/include/pipe/p_context.h
 +++ b/src/gallium/include/pipe/p_context.h
 @@ -69,33 +69,40 @@ struct pipe_stream_output_target;
  struct pipe_surface;
  struct pipe_transfer;
  struct pipe_vertex_buffer;
  struct pipe_vertex_element;
  struct pipe_video_buffer;
  struct pipe_video_codec;
  struct pipe_viewport_state;
  struct pipe_compute_state;
  union pipe_color_union;
  union pipe_query_result;
 +struct u_upload_mgr;

  /**
   * Gallium rendering context.  Basically:
   *  - state setting functions
   *  - VBO drawing functions
   *  - surface functions
   */
  struct pipe_context {
 struct pipe_screen *screen;

 void *priv;  /**< context private data (for DRI for example) */
 void *draw;  /**< private, for draw module (temporary?) */

 +   /**
 +* Stream uploader created by the driver. All drivers, state
 trackers, and
 +* modules should use it.
 +*/
 +   struct u_upload_mgr *stream_uploader;
 +
 void (*destroy)( struct pipe_context * );

 /**
  * VBO drawing
  */
 /*@{*/
 void (*draw_vbo)( struct pipe_context *pipe,
   const struct pipe_draw_info *info );
 /*@}*/


>>>
>>> I suppose this makes sense. However, this makes util interfaces
>>> effectively part of the gallium interface, not sure how I feel about
>>> that as this seems to violate the contract that util code is optional.
>>
>>
>> To be honest, I don't care much. Putting the uploader into
>> pipe_context has an obvious practical advantage and we want exactly
>> one instance between drivers and state trackers.
>>
>> Also, all utilities that had to use pipe_buffer_create just to upload
>> something for one use can now use this.
>>
>> If somebody wants a proper formal interface, feel free.
>>
>> I do see a small decrease in CPU overhead with legacy GL apps thanks
>> to amdgpu_cs_add_buffer getting the same buffer over and over again.
>
>
> I agree that this is a nice cleanup and improvement at the same time.
>
> Roland has a point, of course, and in theory one could add an upload_alloc
> function to the pipe_context, but in practice, that just adds an indirect
> call for no benefit. I think we should go ahead with this.
>
> I have some comments on patch #3, but apart from that, the series is
>
> Reviewed-by: Nicolai Hähnle 
>
>>
>> Marek
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/4] configure.ac: LLVM again!

[Marek Olšák]

On Wed, Feb 1, 2017 at 7:52 PM, Emil Velikov  wrote:
> On 1 February 2017 at 17:32, Marek Olšák  wrote:
>> On Wed, Feb 1, 2017 at 3:04 PM, Emil Velikov  
>> wrote:
>>> On 29 January 2017 at 23:13, Marek Olšák  wrote:
 On Sun, Jan 29, 2017 at 11:14 PM, Tobias Droste  wrote:
> Am Sonntag, 29. Januar 2017, 22:31:55 CET schrieb Marek Olšák:
>> On Sat, Jan 28, 2017 at 9:29 PM, Tobias Droste  wrote:
>> > Am Samstag, 28. Januar 2017, 16:09:29 CET schrieb Marek Olšák:
>> >> On Sat, Jan 28, 2017 at 3:31 PM, Ilia Mirkin 
> wrote:
>> >> > Can you explain why it's a desirable goal to be able to build radv
>> >> > without
>> >> > --enable-gallium-llvm? Perhaps it's obvious, but I'm not seeing it.
>> >> >
>> >> > On Jan 28, 2017 8:57 AM, "Tobias Droste"  wrote:
>> >> >
>> >> > This is a reworked series of the previous LLVM related changes to
>> >> > configure.ac that were reverted due to breaking scons.
>> >> >
>> >> > This takes a different approach to the previous series and adds an
>> >> > extra define for LLVM version checks if RADV is build.
>> >> >
>> >> > This allows to build RADV with "--disable-gallium-llvm".
>> >> >
>> >> > Patch 1, 2 and 3 are the same as in the previous series, just 
>> >> > rebased.
>> >> > The new stuff is in patch 3.
>> >> >
>> >> > Tobias Droste (4):
>> >> >   configure.ac: Rename MESA_LLVM to FOUND_LLVM
>> >> >   configure.ac: Only set LLVM_LIBS if LLVM is used
>> >> >   configure.ac: Separate HAVE_LLVM defines for gallium and radv
>> >> >   configure.ac: Don't check LLVM version in gallium_require_llvm
>> >>
>> >> I fail to see how 2 HAVE_LLVM definitions can be a good idea.
>> >>
>> >> Enabling LLVM by default and allowing people to use --disable-llvm
>> >> should be enough for everybody.
>> >
>> > I don't want this too and there's an obvious easier and better 
>> > solution to
>> > this, but it was NAKed by Jose, because it changed 6 lines in draw (the
>> > scons fix is easy):
>> > https://lists.freedesktop.org/archives/mesa-dev/2017-January/141263.html
>>
>> The link doesn't contain Jose's NAK. He only said that it had broken
>> the scons build, and asked you to wait for his review next time.
>
> It's just the start of the thread. It's over multiple mails.
>
> https://lists.freedesktop.org/archives/mesa-dev/2017-January/141897.html
> "2) you're keeping things nice and neat for yourselves by shoving the
> ugly bits (like this weird USE_LLVM_FOR_DRAW/HAVE_GALLIUM_LLVM) into
> draw/gallivm/llvmpipe, which I simply cannot and will never accept."

 I don't really care about this stuff too much, but I think adding more
 HAVE definitions for LLVM sounds like a bad idea, and allowing
 building radv (with llvm) + softpipe (without llvm) is a use case that
 won't have any users IMO.

>>> Having a generic --enable-llvm was suggested by Tobias and Ilia (et al) 
>>> iirc.
>>> Doing that leads to a small functionality change - building gallium
>>> w/o LLVM + radv anyone ?
>>>
>>> Regardless we might give it a try for 17.1 and see if/for how many
>>> people that is an issue.
>>> For the moment we'll just resolve all the [quirky] combinations to build.
>>
>> Why do you wanna build Gallium without LLVM + radv?
>>
> I was wondering about the same thing.
>
> Then again it's allowed atm, plus is/was working like a charm (with
> the bug addressed).
> We can change/fix that for 17.1.x, but I'd keep expectations
> consistent within the feature freeze.

I think that the option to build Gallium without LLVM + radv with LLVM
should be dropped. If it works now, whatever, but it's a useless
combination to me. Other than that, softpipe should never be used by
ordinary users.

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

Re: [Mesa-dev] [PATCH v2] anv: emit DrawID if needed

[Jason Ekstrand]

Thanks!  Series is

Reviewed-by: Jason Ekstrand 

On Wed, Feb 1, 2017 at 3:09 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> v2: use define for buffer ID (Jason)
>
> Signed-off-by: Lionel Landwerlin 
> Reviewed-by: Anuj Phogat 
> ---
>  src/intel/vulkan/anv_private.h |  3 ++-
>  src/intel/vulkan/genX_cmd_buffer.c | 42 ++
> +++-
>  src/intel/vulkan/genX_pipeline.c   | 25 ++-
>  3 files changed, 63 insertions(+), 7 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> private.h
> index a0d97ac595..70c68ea609 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -97,6 +97,7 @@ extern "C" {
>  #define MAX_IMAGES 8
>
>  #define ANV_SVGS_VB_INDEXMAX_VBS
> +#define ANV_DRAWID_VB_INDEX (MAX_VBS + 1)
>
>  #define anv_printflike(a, b) __attribute__((__format__(__printf__, a,
> b)))
>
> @@ -1615,7 +1616,7 @@ struct anv_image {
> /**
>  * For color images, this is the aux usage for this image when not
> used as a
>  * color attachment.
> -*
> +*
>  * For depth/stencil images, this is set to ISL_AUX_USAGE_HIZ if the
> image
>  * has a HiZ buffer.
>  */
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> index a7c3b4380a..d74f37b01b 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -1585,30 +1585,38 @@ genX(cmd_buffer_flush_state)(struct
> anv_cmd_buffer *cmd_buffer)
>  }
>
>  static void
> -emit_base_vertex_instance_bo(struct anv_cmd_buffer *cmd_buffer,
> - struct anv_bo *bo, uint32_t offset)
> +emit_vertex_bo(struct anv_cmd_buffer *cmd_buffer,
> +   struct anv_bo *bo, uint32_t offset,
> +   uint32_t size, uint32_t index)
>  {
> uint32_t *p = anv_batch_emitn(_buffer->batch, 5,
>   GENX(3DSTATE_VERTEX_BUFFERS));
>
> GENX(VERTEX_BUFFER_STATE_pack)(_buffer->batch, p + 1,
>&(struct GENX(VERTEX_BUFFER_STATE)) {
> - .VertexBufferIndex = ANV_SVGS_VB_INDEX, /* Reserved for this */
> + .VertexBufferIndex = index,
>   .AddressModifyEnable = true,
>   .BufferPitch = 0,
>  #if (GEN_GEN >= 8)
>   .MemoryObjectControlState = GENX(MOCS),
>   .BufferStartingAddress = { bo, offset },
> - .BufferSize = 8
> + .BufferSize = size
>  #else
>   .VertexBufferMemoryObjectControlState = GENX(MOCS),
>   .BufferStartingAddress = { bo, offset },
> - .EndAddress = { bo, offset + 8 },
> + .EndAddress = { bo, offset + size },
>  #endif
>});
>  }
>
>  static void
> +emit_base_vertex_instance_bo(struct anv_cmd_buffer *cmd_buffer,
> + struct anv_bo *bo, uint32_t offset)
> +{
> +   emit_vertex_bo(cmd_buffer, bo, offset, 8, ANV_SVGS_VB_INDEX);
> +}
> +
> +static void
>  emit_base_vertex_instance(struct anv_cmd_buffer *cmd_buffer,
>uint32_t base_vertex, uint32_t base_instance)
>  {
> @@ -1625,6 +1633,22 @@ emit_base_vertex_instance(struct anv_cmd_buffer
> *cmd_buffer,
>_buffer->device->dynamic_state_block_pool.bo, id_state.offset);
>  }
>
> +static void
> +emit_draw_index(struct anv_cmd_buffer *cmd_buffer, uint32_t draw_index)
> +{
> +   struct anv_state state =
> +  anv_cmd_buffer_alloc_dynamic_state(cmd_buffer, 4, 4);
> +
> +   ((uint32_t *)state.map)[0] = draw_index;
> +
> +   if (!cmd_buffer->device->info.has_llc)
> +  anv_state_clflush(state);
> +
> +   emit_vertex_bo(cmd_buffer,
> +  _buffer->device->dynamic_state_block_pool.bo,
> +  state.offset, 4, ANV_DRAWID_VB_INDEX);
> +}
> +
>  void genX(CmdDraw)(
>  VkCommandBuffer commandBuffer,
>  uint32_tvertexCount,
> @@ -1640,6 +1664,8 @@ void genX(CmdDraw)(
>
> if (vs_prog_data->uses_basevertex || vs_prog_data->uses_baseinstance)
>emit_base_vertex_instance(cmd_buffer, firstVertex, firstInstance);
> +   if (vs_prog_data->uses_drawid)
> +  emit_draw_index(cmd_buffer, 0);
>
> anv_batch_emit(_buffer->batch, GENX(3DPRIMITIVE), prim) {
>prim.VertexAccessType = SEQUENTIAL;
> @@ -1668,6 +1694,8 @@ void genX(CmdDrawIndexed)(
>
> if (vs_prog_data->uses_basevertex || vs_prog_data->uses_baseinstance)
>emit_base_vertex_instance(cmd_buffer, vertexOffset, firstInstance);
> +   if (vs_prog_data->uses_drawid)
> +  emit_draw_index(cmd_buffer, 0);
>
> anv_batch_emit(_buffer->batch, GENX(3DPRIMITIVE), prim) {
>prim.VertexAccessType = RANDOM;
> @@ -1706,6 +1734,8 @@ void genX(CmdDrawIndirect)(
>
> if (vs_prog_data->uses_basevertex || vs_prog_data->uses_baseinstance)
>emit_base_vertex_instance_bo(cmd_buffer, bo, bo_offset + 8);
> +   

[Mesa-dev] [PATCHv2 3/4] configure.ac: Separate HAVE_LLVM defines for gallium and radv

[Emil Velikov]

From: Tobias Droste 

Currently --enable-gallium-llvm is equivalent to HAVE_LLVM. At the same
time, non-gallium users such as radv do not require anything from
gallium (let alone the llvm code), thus they do not depend on it. One
option is to rename the gallium define to HAVE_GALLIUM_LLVM but that was
deemed too fragile/other [1] so lets use another define for radv.

Correct earlier mistake and define HAVE_LLVM only if
--enable-gallium-llvm is provided. If radv is built add HAVE_LLVM_RADV
define with the same value as HAVE_LLVM.

In the future we might rework --enable-gallium-llvm to --enable-llvm as
a generic guard/toggle. That can lead to small changes in some extremely
corner cases (like --disable-gallium-llvm --with-vulkan-drivers=radeon)
so let's keep it out for now.

[1] https://lists.freedesktop.org/archives/mesa-dev/2017-January/141897.html

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99010
Signed-off-by: Tobias Droste 

v2: [Emil Velikov]
 - Consolidate MESA_LLVM_VERSION definition to a single place.
 - Add beefy comment describing the new macro.
 - Update all HAVE_LLVM references in src/amd.
 - Beef-up commit message.

Cc: Tobias Droste 
Cc: 17.0 
Signed-off-by: Emil Velikov 
---
Ftr the whole series should be in -stable, plus some of my earlier fixes 
which apply on top.

With the updated patch the following build combinations work as expected
 - scons + linux
 - scons + mingw64
 - scons + msvc (appveyor)
 - autoconf - disable-gallium-llvm + vulkan-drivers=radeon
 - autoconf - enable-gallium-llvm + vulkan-drivers=radeon
 - autoconf - enable-gallium-llvm + vulkan-drivers=
---
 configure.ac  |  3 ++-
 src/amd/common/ac_llvm_helper.cpp |  2 +-
 src/amd/common/ac_llvm_util.c | 13 +++--
 src/amd/common/ac_llvm_util.h | 14 ++
 src/amd/common/ac_nir_to_llvm.c   |  6 +++---
 src/amd/vulkan/radv_device.c  |  2 +-
 6 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index f956df5120..5101e3bb0b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1001,7 +1001,6 @@ llvm_set_environment_variables() {
 LLVM_VERSION_INT="${LLVM_VERSION_MAJOR}${LLVM_VERSION_MINOR}"
 fi
 
-DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT 
-DMESA_LLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
 FOUND_LLVM=yes
 USE_LLVM=no
 else
@@ -1775,6 +1774,7 @@ if test -n "$with_vulkan_drivers"; then
 PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >= 
$LIBDRM_AMDGPU_REQUIRED])
 radeon_llvm_check $LLVM_REQUIRED_RADV "radv"
 HAVE_RADEON_VULKAN=yes;
+DEFINES="${DEFINES} -DHAVE_LLVM_RADV=0x0$LLVM_VERSION_INT 
-DMESA_LLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
 ;;
 *)
 AC_MSG_ERROR([Vulkan driver '$driver' does not exist])
@@ -2407,6 +2407,7 @@ if test "x$enable_gallium_llvm" == "xyes"; then
 llvm_add_default_components "gallium"
 
 USE_LLVM_GALLIUM=yes
+DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT 
-DMESA_LLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
 else
 USE_LLVM_GALLIUM=no
 fi
diff --git a/src/amd/common/ac_llvm_helper.cpp 
b/src/amd/common/ac_llvm_helper.cpp
index 594339ee8c..154156b8a3 100644
--- a/src/amd/common/ac_llvm_helper.cpp
+++ b/src/amd/common/ac_llvm_helper.cpp
@@ -26,7 +26,7 @@
 /* based on Marek's patch to lp_bld_misc.cpp */
 
 // Workaround http://llvm.org/PR23628
-#if HAVE_LLVM >= 0x0307
+#if MESA_LLVM_VERSION >= 0x0307
 #  pragma push_macro("DEBUG")
 #  undef DEBUG
 #endif
diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index f3cab921ba..7060a2f003 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -22,6 +22,7 @@
  * of the Software.
  *
  */
+
 /* based on pieces from si_pipe.c and radeon_llvm_emit.c */
 #include "ac_llvm_util.h"
 
@@ -37,7 +38,7 @@
 
 static void ac_init_llvm_target()
 {
-#if HAVE_LLVM < 0x0307
+#if MESA_LLVM_VERSION < 0x0307
LLVMInitializeR600TargetInfo();
LLVMInitializeR600Target();
LLVMInitializeR600TargetMC();
@@ -99,7 +100,7 @@ static const char *ac_get_llvm_processor_name(enum 
radeon_family family)
return "iceland";
case CHIP_CARRIZO:
return "carrizo";
-#if HAVE_LLVM <= 0x0307
+#if MESA_LLVM_VERSION <= 0x0307
case CHIP_FIJI:
return "tonga";
case CHIP_STONEY:
@@ -110,7 +111,7 @@ static const char *ac_get_llvm_processor_name(enum 
radeon_family family)
case CHIP_STONEY:
return "stoney";
 #endif
-#if HAVE_LLVM <= 0x0308
+#if MESA_LLVM_VERSION <= 0x0308
case CHIP_POLARIS10:
return "tonga";
case CHIP_POLARIS11:
@@ -166,7 +167,7 @@ ac_llvm_context_init(struct ac_llvm_context *ctx, 
LLVMContextRef context)
ctx->fpmath_md_2p5_ulp = 

Re: [Mesa-dev] [PATCH 2/2] blorp: Embed a wm_prog_data in blorp_prog_data

[Jason Ekstrand]

Turns out these were already in-tree and I forgot I pushed them... Sorry
for the noise.

On Wed, Feb 1, 2017 at 12:01 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Tue, Jan 31, 2017 at 11:05:28AM -0800, Jason Ekstrand wrote:
> > While we're at it, we rename it to remove the brw_ prefix
>
> Nice! Both patches:
>
> Reviewed-by: Topi Pohjolainen 
>
> >
> > Signed-off-by: Jason Ekstrand 
> > ---
> >  src/intel/blorp/blorp.c   | 26 +-
> >  src/intel/blorp/blorp_blit.c  |  2 +-
> >  src/intel/blorp/blorp_clear.c |  2 +-
> >  src/intel/blorp/blorp_genX_exec.h | 72 +++---
> -
> >  src/intel/blorp/blorp_priv.h  | 30 
> >  5 files changed, 52 insertions(+), 80 deletions(-)
> >
> > diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
> > index 2f27274..8a90c3b 100644
> > --- a/src/intel/blorp/blorp.c
> > +++ b/src/intel/blorp/blorp.c
> > @@ -145,7 +145,7 @@ const unsigned *
> >  brw_blorp_compile_nir_shader(struct blorp_context *blorp, struct
> nir_shader *nir,
> >   const struct brw_wm_prog_key *wm_key,
> >   bool use_repclear,
> > - struct brw_blorp_prog_data *prog_data,
> > + struct blorp_prog_data *prog_data,
> >   unsigned *program_size)
> >  {
> > const struct brw_compiler *compiler = blorp->compiler;
> > @@ -160,15 +160,14 @@ brw_blorp_compile_nir_shader(struct blorp_context
> *blorp, struct nir_shader *nir
> > nir->options =
> >compiler->glsl_compiler_options[MESA_SHADER_FRAGMENT].NirOptions;
> >
> > -   struct brw_wm_prog_data wm_prog_data;
> > -   memset(_prog_data, 0, sizeof(wm_prog_data));
> > +   memset(prog_data, 0, sizeof(*prog_data));
> >
> > -   wm_prog_data.base.nr_params = 0;
> > -   wm_prog_data.base.param = NULL;
> > +   prog_data->wm.base.nr_params = 0;
> > +   prog_data->wm.base.param = NULL;
> >
> > /* BLORP always just uses the first two binding table entries */
> > -   wm_prog_data.binding_table.render_target_start =
> BLORP_RENDERBUFFER_BT_INDEX;
> > -   wm_prog_data.base.binding_table.texture_start =
> BLORP_TEXTURE_BT_INDEX;
> > +   prog_data->wm.binding_table.render_target_start =
> BLORP_RENDERBUFFER_BT_INDEX;
> > +   prog_data->wm.base.binding_table.texture_start =
> BLORP_TEXTURE_BT_INDEX;
> >
> > nir = brw_preprocess_nir(compiler, nir);
> > nir_remove_dead_variables(nir, nir_var_shader_in);
> > @@ -176,21 +175,12 @@ brw_blorp_compile_nir_shader(struct blorp_context
> *blorp, struct nir_shader *nir
> >
> > const unsigned *program =
> >brw_compile_fs(compiler, blorp->driver_ctx, mem_ctx,
> > - wm_key, _prog_data, nir,
> > + wm_key, _data->wm, nir,
> >   NULL, -1, -1, false, use_repclear, program_size,
> NULL);
> >
> > -   /* Copy the relavent bits of wm_prog_data over into the blorp prog
> data */
> > -   prog_data->dispatch_8 = wm_prog_data.dispatch_8;
> > -   prog_data->dispatch_16 = wm_prog_data.dispatch_16;
> > -   prog_data->first_curbe_grf_0 = wm_prog_data.base.dispatch_
> grf_start_reg;
> > -   prog_data->first_curbe_grf_2 = wm_prog_data.dispatch_grf_
> start_reg_2;
> > -   prog_data->ksp_offset_2 = wm_prog_data.prog_offset_2;
> > -   prog_data->persample_msaa_dispatch = wm_prog_data.persample_
> dispatch;
> > -   prog_data->flat_inputs = wm_prog_data.flat_inputs;
> > -   prog_data->num_varying_inputs = wm_prog_data.num_varying_inputs;
> > prog_data->inputs_read = nir->info.inputs_read;
> >
> > -   assert(wm_prog_data.base.nr_params == 0);
> > +   assert(prog_data->wm.base.nr_params == 0);
> >
> > return program;
> >  }
> > diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> > index af46389..fc9e737 100644
> > --- a/src/intel/blorp/blorp_blit.c
> > +++ b/src/intel/blorp/blorp_blit.c
> > @@ -1235,7 +1235,7 @@ brw_blorp_get_blit_kernel(struct blorp_context
> *blorp,
> >
> > const unsigned *program;
> > unsigned program_size;
> > -   struct brw_blorp_prog_data prog_data;
> > +   struct blorp_prog_data prog_data;
> >
> > /* Try and compile with NIR first.  If that fails, fall back to the
> old
> >  * method of building shaders manually.
> > diff --git a/src/intel/blorp/blorp_clear.c
> b/src/intel/blorp/blorp_clear.c
> > index ce9b292..01889b8 100644
> > --- a/src/intel/blorp/blorp_clear.c
> > +++ b/src/intel/blorp/blorp_clear.c
> > @@ -73,7 +73,7 @@ blorp_params_get_clear_kernel(struct blorp_context
> *blorp,
> > struct brw_wm_prog_key wm_key;
> > brw_blorp_init_wm_prog_key(_key);
> >
> > -   struct brw_blorp_prog_data prog_data;
> > +   struct blorp_prog_data prog_data;
> > unsigned program_size;
> > const unsigned *program =
> >brw_blorp_compile_nir_shader(blorp, b.shader, _key,
> use_replicated_data,
> > diff --git 

Re: [Mesa-dev] [PATCH 0/4] configure.ac: LLVM again!

[Emil Velikov]

On 1 February 2017 at 17:32, Marek Olšák  wrote:
> On Wed, Feb 1, 2017 at 3:04 PM, Emil Velikov  wrote:
>> On 29 January 2017 at 23:13, Marek Olšák  wrote:
>>> On Sun, Jan 29, 2017 at 11:14 PM, Tobias Droste  wrote:
 Am Sonntag, 29. Januar 2017, 22:31:55 CET schrieb Marek Olšák:
> On Sat, Jan 28, 2017 at 9:29 PM, Tobias Droste  wrote:
> > Am Samstag, 28. Januar 2017, 16:09:29 CET schrieb Marek Olšák:
> >> On Sat, Jan 28, 2017 at 3:31 PM, Ilia Mirkin 
 wrote:
> >> > Can you explain why it's a desirable goal to be able to build radv
> >> > without
> >> > --enable-gallium-llvm? Perhaps it's obvious, but I'm not seeing it.
> >> >
> >> > On Jan 28, 2017 8:57 AM, "Tobias Droste"  wrote:
> >> >
> >> > This is a reworked series of the previous LLVM related changes to
> >> > configure.ac that were reverted due to breaking scons.
> >> >
> >> > This takes a different approach to the previous series and adds an
> >> > extra define for LLVM version checks if RADV is build.
> >> >
> >> > This allows to build RADV with "--disable-gallium-llvm".
> >> >
> >> > Patch 1, 2 and 3 are the same as in the previous series, just 
> >> > rebased.
> >> > The new stuff is in patch 3.
> >> >
> >> > Tobias Droste (4):
> >> >   configure.ac: Rename MESA_LLVM to FOUND_LLVM
> >> >   configure.ac: Only set LLVM_LIBS if LLVM is used
> >> >   configure.ac: Separate HAVE_LLVM defines for gallium and radv
> >> >   configure.ac: Don't check LLVM version in gallium_require_llvm
> >>
> >> I fail to see how 2 HAVE_LLVM definitions can be a good idea.
> >>
> >> Enabling LLVM by default and allowing people to use --disable-llvm
> >> should be enough for everybody.
> >
> > I don't want this too and there's an obvious easier and better solution 
> > to
> > this, but it was NAKed by Jose, because it changed 6 lines in draw (the
> > scons fix is easy):
> > https://lists.freedesktop.org/archives/mesa-dev/2017-January/141263.html
>
> The link doesn't contain Jose's NAK. He only said that it had broken
> the scons build, and asked you to wait for his review next time.

 It's just the start of the thread. It's over multiple mails.

 https://lists.freedesktop.org/archives/mesa-dev/2017-January/141897.html
 "2) you're keeping things nice and neat for yourselves by shoving the
 ugly bits (like this weird USE_LLVM_FOR_DRAW/HAVE_GALLIUM_LLVM) into
 draw/gallivm/llvmpipe, which I simply cannot and will never accept."
>>>
>>> I don't really care about this stuff too much, but I think adding more
>>> HAVE definitions for LLVM sounds like a bad idea, and allowing
>>> building radv (with llvm) + softpipe (without llvm) is a use case that
>>> won't have any users IMO.
>>>
>> Having a generic --enable-llvm was suggested by Tobias and Ilia (et al) iirc.
>> Doing that leads to a small functionality change - building gallium
>> w/o LLVM + radv anyone ?
>>
>> Regardless we might give it a try for 17.1 and see if/for how many
>> people that is an issue.
>> For the moment we'll just resolve all the [quirky] combinations to build.
>
> Why do you wanna build Gallium without LLVM + radv?
>
I was wondering about the same thing.

Then again it's allowed atm, plus is/was working like a charm (with
the bug addressed).
We can change/fix that for 17.1.x, but I'd keep expectations
consistent within the feature freeze.

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

Re: [Mesa-dev] [PATCH] isl: Add assertions for render target swizzle restrictions

[Anuj Phogat]

On Tue, Jan 31, 2017 at 6:51 PM, Jason Ekstrand  wrote:
> ---
>  src/intel/isl/isl_surface_state.c | 32 
>  1 file changed, 32 insertions(+)
>
> diff --git a/src/intel/isl/isl_surface_state.c 
> b/src/intel/isl/isl_surface_state.c
> index b735478..c7b220b 100644
> --- a/src/intel/isl/isl_surface_state.c
> +++ b/src/intel/isl/isl_surface_state.c
> @@ -453,6 +453,38 @@ isl_genX(surf_fill_state_s)(const struct isl_device 
> *dev, void *state,
>  #endif
>
>  #if (GEN_GEN >= 8 || GEN_IS_HASWELL)
> +   if (info->view->usage & ISL_SURF_USAGE_RENDER_TARGET_BIT) {
> +  /* From the Sky Lake PRM Vol. 2d,
> +   * RENDER_SURFACE_STATE::Shader Channel Select Red
> +   *
> +   *"For Render Target, Red, Green and Blue Shader Channel Selects
> +   *MUST be such that only valid components can be swapped i.e. only
> +   *change the order of components in the pixel. Any other values for
> +   *these Shader Channel Select fields are not valid for Render
> +   *Targets. This also means that there MUST not be multiple shader
> +   *channels mapped to the same RT channel."
> +   */
> +  assert(info->view->swizzle.r == ISL_CHANNEL_SELECT_RED ||
> + info->view->swizzle.r == ISL_CHANNEL_SELECT_GREEN ||
> + info->view->swizzle.r == ISL_CHANNEL_SELECT_BLUE);
> +  assert(info->view->swizzle.g == ISL_CHANNEL_SELECT_RED ||
> + info->view->swizzle.g == ISL_CHANNEL_SELECT_GREEN ||
> + info->view->swizzle.g == ISL_CHANNEL_SELECT_BLUE);
> +  assert(info->view->swizzle.b == ISL_CHANNEL_SELECT_RED ||
> + info->view->swizzle.b == ISL_CHANNEL_SELECT_GREEN ||
> + info->view->swizzle.b == ISL_CHANNEL_SELECT_BLUE);
> +  assert(info->view->swizzle.r != info->view->swizzle.g);
> +  assert(info->view->swizzle.r != info->view->swizzle.b);
> +  assert(info->view->swizzle.g != info->view->swizzle.b);
> +
> +  /* From the Sky Lake PRM Vol. 2d,
> +   * RENDER_SURFACE_STATE::Shader Channel Select Alpha
> +   *
> +   *"For Render Target, this field MUST be programmed to
> +   *value = SCS_ALPHA."
> +   */
> +  assert(info->view->swizzle.a == ISL_CHANNEL_SELECT_ALPHA);
> +   }
> s.ShaderChannelSelectRed = info->view->swizzle.r;
> s.ShaderChannelSelectGreen = info->view->swizzle.g;
> s.ShaderChannelSelectBlue = info->view->swizzle.b;
> --
> 2.5.0.400.gff86faf
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

Re: [Mesa-dev] [PATCH v2 1/2] mesa: make glFramebuffer* check immutable texture level bounds

[Ilia Mirkin]

On Wed, Feb 1, 2017 at 1:18 PM, Antía Puentes  wrote:
> Hi Ilia,
>
> On mié, 2017-02-01 at 00:37 -0500, Ilia Mirkin wrote:
>> On Tue, Jan 31, 2017 at 2:55 PM, Antía Puentes  wrote:
>> >
>> > There was an update in the OpenGL ES 3.2 specification (November 3,
>> > 2016) addressing this:
>> >
>> > - In section "9.2.8 Attaching Texture Images to a Framebuffer",
>> > FramebufferTexture2D (page 241) and FramebufferTextureLayer (page 242)
>> > descriptions:
>> >
>> > " specifies the mipmap level of the texture image to be attached
>> > to the framebuffer, and must satisfy the following conditions:
>> >
>> > • If texture refers to an immutable-format texture, level must be
>> > greater than or equal to zero and smaller than the value of
>> > TEXTURE_IMMUTABLE_LEVELS for texture."
>> >
>> > https://cvs.khronos.org/bugzilla/show_bug.cgi?id=15946
>> Interesting, OK. And the test that's failing is a "glesext" test, even
>> though it's being run in a GL context. Does that bug indicate whether
>> such a change also applies to desktop GL? (I don't have access to the
>> bug tracker.)
>
> It does not mention anything about desktop GL. I have filled a new bug
> in OpenGL 4.5 asking for clarification:
> https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16214
>
> For what it is worth, I have a patch similar to yours but using
> ImmutableLevels in the condition check instead of NumLevels:
>
> (texObj->Immutable && level >= texObj->ImmutableLevels)

I didn't even know about that one... I think you want NumLevels
though, as ImmutableLevels is copied through from the original texture
object when creating a view, while NumLevels is set to the expected
value.

It does seem like ImmutableLevels should be done away with - the
usages of it likely predate NumLevels's existence.

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

Re: [Mesa-dev] [PATCH v2 1/2] mesa: make glFramebuffer* check immutable texture level bounds

[Antía Puentes]

Hi Ilia,

On mié, 2017-02-01 at 00:37 -0500, Ilia Mirkin wrote:
> On Tue, Jan 31, 2017 at 2:55 PM, Antía Puentes  wrote:
> > 
> > There was an update in the OpenGL ES 3.2 specification (November 3,
> > 2016) addressing this:
> > 
> > - In section "9.2.8 Attaching Texture Images to a Framebuffer",
> > FramebufferTexture2D (page 241) and FramebufferTextureLayer (page 242)
> > descriptions:
> > 
> > " specifies the mipmap level of the texture image to be attached
> > to the framebuffer, and must satisfy the following conditions:
> > 
> > • If texture refers to an immutable-format texture, level must be
> > greater than or equal to zero and smaller than the value of
> > TEXTURE_IMMUTABLE_LEVELS for texture."
> > 
> > https://cvs.khronos.org/bugzilla/show_bug.cgi?id=15946
> Interesting, OK. And the test that's failing is a "glesext" test, even
> though it's being run in a GL context. Does that bug indicate whether
> such a change also applies to desktop GL? (I don't have access to the
> bug tracker.)

It does not mention anything about desktop GL. I have filled a new bug
in OpenGL 4.5 asking for clarification:
https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16214

For what it is worth, I have a patch similar to yours but using
ImmutableLevels in the condition check instead of NumLevels:

(texObj->Immutable && level >= texObj->ImmutableLevels)


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

Re: [Mesa-dev] [PATCH] mesa: Enable EXT_compressed_ETC1_RGB8_sub_texture

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

On Tue, Jan 24, 2017 at 7:39 AM, Plamena Manolova
 wrote:
> Since we already have the functionality in place and games
> like Game of Thrones seem to depend on this extension, I
> think it makes sense to enable it by making it part of
> the extension string even though it's still a draft:
>
> https://www.khronos.org/registry/gles/extensions/EXT/EXT_compressed_ETC1_RGB8_sub_texture.txt
>
> Note: OES_compressed_ETC1_RGB8_sub_texture seems to be listed
> in gl2ext.h, but there's no documentation for it in the KHR
> registry
>
> Signed-off-by: Plamena Manolova 
> ---
>  src/mesa/main/extensions_table.h | 1 +
>  src/mesa/main/teximage.c | 1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index 91918c2..c06f784 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -199,6 +199,7 @@ EXT(EXT_buffer_storage  , 
> ARB_buffer_storage
>  EXT(EXT_clip_cull_distance  , ARB_cull_distance  
> ,  x ,  x ,  x ,  30, 2016)
>  EXT(EXT_color_buffer_float  , dummy_true 
> ,  x ,  x ,  x ,  30, 2013)
>  EXT(EXT_compiled_vertex_array   , dummy_true 
> , GLL,  x ,  x ,  x , 1996)
> +EXT(EXT_compressed_ETC1_RGB8_sub_texture, 
> OES_compressed_ETC1_RGB8_texture   ,  x ,  x , ES1, ES2, 2014)
>  EXT(EXT_copy_image  , OES_copy_image 
> ,  x ,  x ,  x ,  30, 2014)
>  EXT(EXT_copy_texture, dummy_true 
> , GLL,  x ,  x ,  x , 1995)
>  EXT(EXT_depth_bounds_test   , EXT_depth_bounds_test  
> , GLL, GLC,  x ,  x , 2002)
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index bc3b76a..69f4107 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -1322,7 +1322,6 @@ static bool
>  compressedteximage_only_format(const struct gl_context *ctx, GLenum format)
>  {
> switch (format) {
> -   case GL_ETC1_RGB8_OES:
> case GL_PALETTE4_RGB8_OES:
> case GL_PALETTE4_RGBA8_OES:
> case GL_PALETTE4_R5_G6_B5_OES:
> --
> 2.4.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev