Re: [Mesa-dev] Mesa 17.2.0 release plan

[Jason Ekstrand]

n Fri, Jul 7, 2017 at 11:07 AM, Emil Velikov 
wrote:

> Hi all,
>
> As you may have noticed, for a little while now we've had the release
> plan on the mesa3d.org website [1].
>
> Here is the current tentative schedule.
>
>  Jul 21 2017 - Feature freeze/Release candidate 1
>  Jul 28 2017 - Release candidate 2
>  Aug 04 2017 - Release candidate 3
>  Aug 11 2017 - Release candidate 4/final release
>
> This gives us approximately 2 weeks to get new features in.
>
> As always, please let me know of must have features that you'll like
> to merge before the branch point.
>

Here's my wishlist:

 1) I'd like to land the rest of Topi's work to convert the i965 driver
over to ISL.  I really don't want to have a release where it's half old
miptree code and half ISL.  That's going to make back-porting a real pain.

 2) I've got a bunch of fixes to the miptree code that are currently WIP
that I'd like to see go in.  If they don't make the branch point, I'll
probably just CC the lot to stable so it's not a huge deal.

 3) As many of the new Vulkan extensions as we can land.  But don't block
the release on any of those.

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

Re: [Mesa-dev] [PATCH 1/7] intel: Move clflush helpers from anv to common/gen_clflush.h.

[Kenneth Graunke]

On Friday, July 14, 2017 10:09:10 AM PDT Rob Herring wrote:
> On Wed, Jul 5, 2017 at 3:56 PM, Kenneth Graunke  wrote:
> > I want to use these in the OpenGL driver as well.
> 
> FYI, this breaks building the i965 driver on non-x86 builds. Maybe my
> Android CI job should just stop doing that, but it did work before
> this.
> 
> Rob
> 
> >
> > Cc: Jason Ekstrand 
> > ---
> >  src/intel/common/gen_clflush.h | 56 
> > ++
> >  src/intel/vulkan/anv_batch_chain.c |  2 +-
> >  src/intel/vulkan/anv_device.c  |  2 +-
> >  src/intel/vulkan/anv_private.h | 32 ++
> >  src/intel/vulkan/anv_queue.c   |  2 +-
> >  src/intel/vulkan/genX_blorp_exec.c |  2 +-
> >  6 files changed, 62 insertions(+), 34 deletions(-)
> >  create mode 100644 src/intel/common/gen_clflush.h
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

Sorry about that...I hadn't realized it would be a problem :(

We fixed this for the automake build in commits 6b05c080f202c25531f5 and
5ffe0c9e1be0257de19431 by adding -msse2 to CFLAGS.  (All CPUs that can be
paired with G965 GPUs support SSE2, apparently, so this shouldn't be a
problem.)

We probably need to add that to Android.mk as well...

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

[Mesa-dev] [PATCH v2] st/va: Fix scaling list ordering for H.265

[Mark Thompson]

Mesa here requires the scaling lists in diagonal scan order, but
VAAPI passes them in raster scan order.  Therefore, rearrange the
elements when copying.

v2: Move scan tables to vl_zscan.c.
Fix type in size assertion.

Signed-off-by: Mark Thompson 
---
On 14/07/17 11:01, Christian König wrote:
> That just looks like the inversed Z-scan order we already have in 
> vl_zscan.[hc].
> 
> Please use that one instead and/or add new defines into that file if 
> necessary.

They are not the same as any of the existing orders, so I've added new tables.

Thanks,

- Mark


 src/gallium/auxiliary/vl/vl_zscan.c  | 21 ++
 src/gallium/auxiliary/vl/vl_zscan.h  |  2 ++
 src/gallium/state_trackers/va/picture_hevc.c | 33 ++--
 3 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_zscan.c 
b/src/gallium/auxiliary/vl/vl_zscan.c
index 24d64525b7..75013c42bf 100644
--- a/src/gallium/auxiliary/vl/vl_zscan.c
+++ b/src/gallium/auxiliary/vl/vl_zscan.c
@@ -95,6 +95,27 @@ const int vl_zscan_alternate[] =
38,46,54,62,39,47,55,63
 };
 
+const int vl_zscan_h265_up_right_diagonal_16[] =
+{
+   /* Up-right diagonal scan order for 4x4 blocks - see H.265 section 6.5.3. */
+0,  4,  1,  8,  5,  2, 12,  9,
+6,  3, 13, 10,  7, 14, 11, 15,
+};
+
+const int vl_zscan_h265_up_right_diagonal[] =
+{
+   /* Up-right diagonal scan order for 8x8 blocks - see H.265 section 6.5.3. */
+0,  8,  1, 16,  9,  2, 24, 17,
+   10,  3, 32, 25, 18, 11,  4, 40,
+   33, 26, 19, 12,  5, 48, 41, 34,
+   27, 20, 13,  6, 56, 49, 42, 35,
+   28, 21, 14,  7, 57, 50, 43, 36,
+   29, 22, 15, 58, 51, 44, 37, 30,
+   23, 59, 52, 45, 38, 31, 60, 53,
+   46, 39, 61, 54, 47, 62, 55, 63,
+};
+
+
 static void *
 create_vert_shader(struct vl_zscan *zscan)
 {
diff --git a/src/gallium/auxiliary/vl/vl_zscan.h 
b/src/gallium/auxiliary/vl/vl_zscan.h
index 268cf0a6e3..292152e873 100644
--- a/src/gallium/auxiliary/vl/vl_zscan.h
+++ b/src/gallium/auxiliary/vl/vl_zscan.h
@@ -68,6 +68,8 @@ extern const int vl_zscan_normal_16[];
 extern const int vl_zscan_linear[];
 extern const int vl_zscan_normal[];
 extern const int vl_zscan_alternate[];
+extern const int vl_zscan_h265_up_right_diagonal_16[];
+extern const int vl_zscan_h265_up_right_diagonal[];
 
 struct pipe_sampler_view *
 vl_zscan_layout(struct pipe_context *pipe, const int layout[64], unsigned 
blocks_per_line);
diff --git a/src/gallium/state_trackers/va/picture_hevc.c 
b/src/gallium/state_trackers/va/picture_hevc.c
index 28743ee7aa..e879259ae1 100644
--- a/src/gallium/state_trackers/va/picture_hevc.c
+++ b/src/gallium/state_trackers/va/picture_hevc.c
@@ -25,6 +25,7 @@
  *
  **/
 
+#include "vl/vl_zscan.h"
 #include "va_private.h"
 
 void vlVaHandlePictureParameterBufferHEVC(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf)
@@ -179,14 +180,32 @@ void vlVaHandlePictureParameterBufferHEVC(vlVaDriver 
*drv, vlVaContext *context,
 void vlVaHandleIQMatrixBufferHEVC(vlVaContext *context, vlVaBuffer *buf)
 {
VAIQMatrixBufferHEVC *h265 = buf->data;
+   int i, j;
 
-   assert(buf->size >= sizeof(VAIQMatrixBufferH264) && buf->num_elements == 1);
-   memcpy(>desc.h265.pps->sps->ScalingList4x4, h265->ScalingList4x4, 
6 * 16);
-   memcpy(>desc.h265.pps->sps->ScalingList8x8, h265->ScalingList8x8, 
6 * 64);
-   memcpy(>desc.h265.pps->sps->ScalingList16x16, 
h265->ScalingList16x16, 6 * 64);
-   memcpy(>desc.h265.pps->sps->ScalingList32x32, 
h265->ScalingList32x32, 2 * 64);
-   memcpy(>desc.h265.pps->sps->ScalingListDCCoeff16x16, 
h265->ScalingListDC16x16, 6);
-   memcpy(>desc.h265.pps->sps->ScalingListDCCoeff32x32, 
h265->ScalingListDC32x32, 2);
+   assert(buf->size >= sizeof(VAIQMatrixBufferHEVC) && buf->num_elements == 1);
+
+   for (i = 0; i < 6; i++) {
+  for (j = 0; j < 16; j++)
+ context->desc.h265.pps->sps->ScalingList4x4[i][j] =
+
h265->ScalingList4x4[i][vl_zscan_h265_up_right_diagonal_16[j]];
+
+  for (j = 0; j < 64; j++) {
+ context->desc.h265.pps->sps->ScalingList8x8[i][j] =
+
h265->ScalingList8x8[i][vl_zscan_h265_up_right_diagonal[j]];
+ context->desc.h265.pps->sps->ScalingList16x16[i][j] =
+
h265->ScalingList16x16[i][vl_zscan_h265_up_right_diagonal[j]];
+
+ if (i < 2)
+context->desc.h265.pps->sps->ScalingList32x32[i][j] =
+   
h265->ScalingList32x32[i][vl_zscan_h265_up_right_diagonal[j]];
+  }
+
+  context->desc.h265.pps->sps->ScalingListDCCoeff16x16[i] =
+ h265->ScalingListDC16x16[i];
+  if (i < 2)
+ context->desc.h265.pps->sps->ScalingListDCCoeff32x32[i] =
+h265->ScalingListDC32x32[i];
+   }
 }
 
 void vlVaHandleSliceParameterBufferHEVC(vlVaContext *context, vlVaBuffer 

Re: [Mesa-dev] [PATCH 1/2] radv: Use the KHR dedicated alloc for the WSI.

[Luke A. Guest]

can confirm this fixes the current radv rendering rubbish.

Luke.



On 15/07/17 18:56, Bas Nieuwenhuizen wrote:
> NV isn't valid for external images anymore.
>
> Signed-off-by: Bas Nieuwenhuizen 
> Fixes: 6ddc64b93ea "radv: Add support for VK_KHR_dedicated_allocation."
> ---
>  src/amd/vulkan/radv_wsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
> index cdb04ca9628..ab3dcd67d5f 100644
> --- a/src/amd/vulkan/radv_wsi.c
> +++ b/src/amd/vulkan/radv_wsi.c
> @@ -185,8 +185,8 @@ radv_wsi_image_create(VkDevice device_h,
>  
>   VkDeviceMemory memory_h;
>  
> - const VkDedicatedAllocationMemoryAllocateInfoNV ded_alloc = {
> - .sType = 
> VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV,
> + const VkMemoryDedicatedAllocateInfoKHR ded_alloc = {
> + .sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR,
>   .pNext = NULL,
>   .buffer = VK_NULL_HANDLE,
>   .image = image_h

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

Re: [Mesa-dev] [PATCH 2/2] radv: Remove NV dedicated alloc extension.

[Jason Ekstrand]

+1.  The NV extension can be very misleading.

On Sat, Jul 15, 2017 at 10:56 AM, Bas Nieuwenhuizen  wrote:

> To not confuse apps in thinking it might be faster.
>
> Signed-off-by: Bas Nieuwenhuizen 
> ---
>  src/amd/vulkan/radv_device.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 630f35ff7a8..2670d47fdb8 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -138,10 +138,6 @@ static const VkExtensionProperties
> common_device_extensions[] = {
> .specVersion = 1,
> },
> {
> -   .extensionName = VK_NV_DEDICATED_ALLOCATION_
> EXTENSION_NAME,
> -   .specVersion = 1,
> -   },
> -   {
> .extensionName = VK_KHR_GET_MEMORY_
> REQUIREMENTS_2_EXTENSION_NAME,
> .specVersion = 1,
> },
> --
> 2.13.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 2/2] radv: Remove NV dedicated alloc extension.

[Bas Nieuwenhuizen]

To not confuse apps in thinking it might be faster.

Signed-off-by: Bas Nieuwenhuizen 
---
 src/amd/vulkan/radv_device.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 630f35ff7a8..2670d47fdb8 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -138,10 +138,6 @@ static const VkExtensionProperties 
common_device_extensions[] = {
.specVersion = 1,
},
{
-   .extensionName = VK_NV_DEDICATED_ALLOCATION_EXTENSION_NAME,
-   .specVersion = 1,
-   },
-   {
.extensionName = 
VK_KHR_GET_MEMORY_REQUIREMENTS_2_EXTENSION_NAME,
.specVersion = 1,
},
-- 
2.13.2

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

[Mesa-dev] [PATCH 1/2] radv: Use the KHR dedicated alloc for the WSI.

[Bas Nieuwenhuizen]

NV isn't valid for external images anymore.

Signed-off-by: Bas Nieuwenhuizen 
Fixes: 6ddc64b93ea "radv: Add support for VK_KHR_dedicated_allocation."
---
 src/amd/vulkan/radv_wsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index cdb04ca9628..ab3dcd67d5f 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -185,8 +185,8 @@ radv_wsi_image_create(VkDevice device_h,
 
VkDeviceMemory memory_h;
 
-   const VkDedicatedAllocationMemoryAllocateInfoNV ded_alloc = {
-   .sType = 
VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV,
+   const VkMemoryDedicatedAllocateInfoKHR ded_alloc = {
+   .sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR,
.pNext = NULL,
.buffer = VK_NULL_HANDLE,
.image = image_h
-- 
2.13.2

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

Re: [Mesa-dev] [PATCH] i965/surface_state: Remove the mcs_buf->offset == 0 restriction

[Pohjolainen, Topi]

On Fri, Jul 14, 2017 at 10:43:08PM -0700, Kenneth Graunke wrote:
> On Friday, July 14, 2017 3:38:30 PM PDT Jason Ekstrand wrote:
> > This assert was removed in b0cc55f29831638069407a4c1a5c809b26902ab6 but
> > got added back in 1a43d774b613d0b00e26b28cc752d944ce8049aa, probably by
> > accident.
> > ---
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > 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 9ef5076..c252f40 100644
> > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > @@ -147,7 +147,6 @@ brw_emit_surface_state(struct brw_context *brw,
> >if (mt->mcs_buf) {
> >   aux_surf = >mcs_buf->surf;
> >  
> > - assert(mt->mcs_buf->offset == 0);
> >   aux_bo = mt->mcs_buf->bo;
> >   aux_offset = mt->mcs_buf->bo->offset64 + mt->mcs_buf->offset;
> >} else {
> > 
> 
> Reviewed-by: Kenneth Graunke 

Yep, sorry about that, looks like a rebase mistake:

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

Re: [Mesa-dev] [PATCH v3 06/14] i965/miptree: Use BO_ALLOC_ZEROED for CCS_E buffers

[Pohjolainen, Topi]

On Wed, Jul 12, 2017 at 09:23:17PM -0700, Jason Ekstrand wrote:
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 36 
> ++-
>  1 file changed, 13 insertions(+), 23 deletions(-)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index fc7b48f..fea19a8 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -1837,13 +1837,20 @@ intel_miptree_alloc_ccs(struct brw_context *brw,
> if (!aux_state)
>return false;
>  
> -   /* In case of compression mcs buffer needs to be initialised requiring the
> -* buffer to be immediately mapped to cpu space for writing. Therefore do
> -* not use the gpu access flag which can cause an unnecessary delay if the
> -* backing pages happened to be just used by the GPU.
> +   /* When CCS_E is used, we need to ensure that the CCS starts off in a 
> valid
> +* state.  From the Sky Lake PRM, "MCS Buffer for Render Target(s)":
> +*
> +*"If Software wants to enable Color Compression without Fast clear,
> +*Software needs to initialize MCS with zeros."
> +*
> +* A CCS value of 0 indicates that the corresponding block is in the
> +* pass-through state which is what we want.
> +*
> +* For CCS_D, on the other hand, we don't care as we're about to perform a
> +* fast-clear operation.  In that case, being hot in caches more useful.
>  */
> -   const uint32_t alloc_flags =
> -  mt->aux_usage == ISL_AUX_USAGE_CCS_E ? 0 : BO_ALLOC_FOR_RENDER;
> +   const uint32_t alloc_flags = mt->aux_usage == ISL_AUX_USAGE_CCS_E ?
> +BO_ALLOC_ZEROED : BO_ALLOC_FOR_RENDER;
> mt->mcs_buf = intel_alloc_aux_buffer(brw, "ccs-miptree",
>  _ccs_surf, alloc_flags, mt);
> if (!mt->mcs_buf) {
> @@ -1853,23 +1860,6 @@ intel_miptree_alloc_ccs(struct brw_context *brw,
>
> mt->aux_state = aux_state;
>  
> -   /* From Gen9 onwards single-sampled (non-msrt) auxiliary buffers are
> -* used for lossless compression which requires similar initialisation
> -* as multi-sample compression.
> -*/
> -   if (mt->aux_usage == ISL_AUX_USAGE_CCS_E) {
> -  /* Hardware sets the auxiliary buffer to all zeroes when it does full
> -   * resolve. Initialize it accordingly in case the first renderer is
> -   * cpu (or other none compression aware party).
> -   *
> -   * This is also explicitly stated in the spec (MCS Buffer for Render
> -   * Target(s)):
> -   *   "If Software wants to enable Color Compression without Fast clear,
> -   *Software needs to initialize MCS with zeros."
> -   */
> -  intel_miptree_init_mcs(brw, mt, 0);
> -   }
> -
> return true;
>  }
>  
> -- 
> 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] [PATCH v3 01/14] i965/miptree: Gather initial aux allocation into a single function

[Pohjolainen, Topi]

On Fri, Jul 14, 2017 at 03:17:59PM -0700, Chad Versace wrote:
> On Wed 12 Jul 2017, Jason Ekstrand wrote:
> > ---
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 83 
> > +--
> >  1 file changed, 53 insertions(+), 30 deletions(-)
> 
> 
> > +static bool
> > +intel_miptree_alloc_aux(struct brw_context *brw,
> > +struct intel_mipmap_tree *mt)
> 
> This is much nicer.
> Reviewed-by: Chad Versace 

Indeed:

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

Re: [Mesa-dev] [PATCH v3 03/14] i965/miptree: Replace is_lossless_compressed with mt->aux_usage checks

[Pohjolainen, Topi]

On Fri, Jul 14, 2017 at 03:26:17PM -0700, Chad Versace wrote:
> On Wed 12 Jul 2017, Jason Ekstrand wrote:
> > Now that we have an actual aux_usage field, we no longer need the
> > complex logic of is_lossless_compressed in order to figure out if a
> > miptree is CCS_E compressed.  As a side-effect, there is not longer any
> > need to overload MSAA_LAYOUT_CMS for CCS_E and we can stop doing so.
> > ---
> >  src/mesa/drivers/dri/i965/brw_blorp.c|  2 +-
> >  src/mesa/drivers/dri/i965/brw_draw.c |  2 +-
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  4 +--
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 39 
> > 
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  4 ---
> >  5 files changed, 10 insertions(+), 41 deletions(-)
> 
> Yes. This patch makes me feel more confident that this miptree code is
> correct.
> 
> Reviewed-by: Chad Versace 

I had separate patches for starting to use aux_usage and dropping
INTEL_MSAA_LAYOUT_CMS for single sampled. This looks even clearer, thanks:

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

[Mesa-dev] [PATCH 2/3] docs: avoid overwrite of LD_LIBRARY_PATH during basic testing

[Andres Gomez]

The LD_LIBRARY_PATH environment variable could be already defined so
we extend it and restore it rather than just overwriting it.

v2:
 - Unset the __old_ld helper variable when we are done with it.
 - Corrected test for and escaping of variables (Eric).

Signed-off-by: Andres Gomez 
Reviewed-by: Emil Velikov 
---
 docs/releasing.html | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/docs/releasing.html b/docs/releasing.html
index 85ab6ae8cb..47137f57e6 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -472,7 +472,8 @@ Here is one solution that I've been using.
__glxgears_cmd='glxgears 2>1 | grep -v "configuration file"'
__es2info_cmd='es2_info 2>1 | egrep 
"GL_VERSION|GL_RENDERER|.*dri\.so"'
__es2gears_cmd='es2gears_x11 2>1 | grep -v "configuration file"'
-   export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/
+   test "x$LD_LIBRARY_PATH" != 'x'  __old_ld="$LD_LIBRARY_PATH" 
 __token=':'
+   export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/"${__token}${__old_ld}"
export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
export LIBGL_DEBUG=verbose
eval $__glxinfo_cmd
@@ -492,6 +493,7 @@ Here is one solution that I've been using.
eval $__es2gears_cmd
# Smoke test DOTA2
unset LD_LIBRARY_PATH
+   test "x$__old_ld" != 'x'  export LD_LIBRARY_PATH="$__old_ld" 
 unset __old_ld  unset __token
unset LIBGL_DRIVERS_PATH
unset LIBGL_DEBUG
unset LIBGL_ALWAYS_SOFTWARE
-- 
2.13.2

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

[Mesa-dev] [PATCH 3/3] docs: update master's release notes, news and calendar commit

[Andres Gomez]

This reflects closer what we are actually doing.

Signed-off-by: Andres Gomez 
Reviewed-by: Eric Engestrom 
Reviewed-by: Emil Velikov 
---
 docs/releasing.html | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/docs/releasing.html b/docs/releasing.html
index 47137f57e6..4f36dded76 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -24,7 +24,6 @@
 Making a branchpoint
 Pre-release announcement
 Making a new release
-Update the calendar
 Announce the release
 Update the mesa3d.org website
 Update Bugzilla
@@ -576,23 +575,17 @@ Something like the following steps will do the trick:
 
 
 
-Also, edit docs/relnotes.html to add a link to the new release notes, and edit
-docs/index.html to add a news entry. Then commit and push:
+Also, edit docs/relnotes.html to add a link to the new release notes,
+edit docs/index.html to add a news entry, and remove the version from
+docs/release-calendar.html. Then commit and push:
 
 
 
-   git commit -as -m "docs: add news item and link release notes for X.Y.Z"
+   git commit -as -m "docs: update calendar, add news item and link 
release notes for X.Y.Z"
git push origin master X.Y
 
 
 
-Update the calendar
-
-
-Remove the version from the calendar.
-
-
-
 Announce the release
 
 
-- 
2.13.2

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

[Mesa-dev] [PATCH 1/3] docs: add instructions to specify LLVM version for basic testing

[Andres Gomez]

The "Perform basic testing" and "Use the release.sh script from xorg
util-modular" sections provide some instructions to do so. We add now
some comments in order to use a recent enough LLVM version to run
dist/distcheck and the automake generated binaries.

v2: Suggested the need to define LLVM_CONFIG also before running the
release.sh script.

Signed-off-by: Andres Gomez 
Reviewed-by: Eric Engestrom 
Reviewed-by: Emil Velikov 
---
 docs/releasing.html | 8 
 1 file changed, 8 insertions(+)

diff --git a/docs/releasing.html b/docs/releasing.html
index 99707bee3f..85ab6ae8cb 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -437,6 +437,8 @@ Here is one solution that I've been using.
chmod 755 -fR $__build_root; rm -rf $__build_root
mkdir -p $__build_root  cd $__build_root
 
+   # For the distcheck, you may want to specify which LLVM to use:
+   # export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
$__mesa_root/autogen.sh  make -j2 distcheck
 
# Build check the tarballs (scons, linux)
@@ -445,18 +447,22 @@ Here is one solution that I've been using.
cd ..  rm -rf mesa-$__version
 
# Build check the tarballs (scons, windows/mingw)
+   # You may need to unset LLVM if you set it before:
+   # unset LLVM_CONFIG
tar -xaf mesa-$__version.tar.xz  cd mesa-$__version
scons platform=windows toolchain=crossmingw
cd ..  rm -rf mesa-$__version
 
# Test the automake binaries
tar -xaf mesa-$__version.tar.xz  cd mesa-$__version
+   # You may want to specify which LLVM to use:
./configure \
--with-dri-drivers=i965,swrast \
--with-gallium-drivers=swrast \
--with-vulkan-drivers=intel \
--enable-llvm-shared-libs \
--enable-llvm \
+   --with-llvm-prefix=/usr/lib/llvm-3.9 \
--enable-glx-tls \
--enable-gbm \
--enable-egl \
@@ -540,6 +546,8 @@ Start the release process.
 
 
 
+   # For the dist/distcheck, you may want to specify which LLVM to use:
+   # export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
../relative/path/to/release.sh . # append --dist if you've already done 
distcheck above
 
 
-- 
2.13.2

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

[Mesa-dev] [PATCH 0/3] docs: update basic testing on the releasing instructions (v2)

[Andres Gomez]

Some small update on the "Making a new release" section of the
releasing instructions.

Patches 1 and 2 add some small modifications for performing the basic
testing and releasing.

Patch 3 merges the section for updating the calendar into the previous
one to reflect closer what we are actually doing.

Andres Gomez (3):
  docs: add instructions to specify LLVM version for basic testing
  docs: avoid overwrite of LD_LIBRARY_PATH during basic testing
  docs: update master's release notes, news and calendar commit

 docs/releasing.html | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

-- 
2.13.2

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

Re: [Mesa-dev] [PATCH 2/4] docs: remove redundant parameter for scons build basic testing

[Andres Gomez]

On Mon, 2017-07-10 at 12:22 +0100, Emil Velikov wrote:
> On 8 July 2017 at 20:59, Andres Gomez  wrote:
> > toolchain=crossmingw is the default option for platform=windows when
> > invoking scons.
> > 
> 
> It may be a bit redundant, but I'd rather keep it. I doubt it's so
> interesting to track when it became the default and if/when that will
> change ;-)

OK, I'll drop this patch.

-- 
Br,

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

Re: [Mesa-dev] [PATCH 3/4] docs: avoid overwrite of LD_LIBRARY_PATH during basic testing

[Andres Gomez]

On Mon, 2017-07-10 at 12:19 +0100, Emil Velikov wrote:
> On 8 July 2017 at 20:59, Andres Gomez  wrote:
> > The LD_LIBRARY_PATH environment variable could be already defined so
> > we extend it and restore it rather than just overwriting it.
> > 
> 
> Hmm, what are you doing to actually require LD_LIBRARY_PATH in the first 
> place?
> It makes it somewhat uneasy that one will have that in their setup.

My everyday's work is done in a JHBuild env that already uses this
variable for mesa dependencies. I would have assumed that this is
actually quite normal for most of mesa developers, although maybe I'm
wrong ...

> 
> > Signed-off-by: Andres Gomez 
> > ---
> >  docs/releasing.html | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/docs/releasing.html b/docs/releasing.html
> > index 8e6e4d1a6d..99235d8412 100644
> > --- a/docs/releasing.html
> > +++ b/docs/releasing.html
> > @@ -472,7 +472,8 @@ Here is one solution that I've been using.
> > __glxgears_cmd='glxgears 2>1 | grep -v "configuration file"'
> > __es2info_cmd='es2_info 2>1 | egrep 
> > "GL_VERSION|GL_RENDERER|.*dri\.so"'
> > __es2gears_cmd='es2gears_x11 2>1 | grep -v "configuration 
> > file"'
> > -   export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/
> > +   'x$LD_LIBRARY_PATH' -ne 'x'  __old_ld='$LD_LIBRARY_PATH' 
> >  __token=':'
> > +   export 
> > LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/'${__token}${__old_ld}'
> 
> AFAICT you don't need __token.

You do if you want to avoid adding ":" at the end when LD_LIBRARY_PATH
is not defined previously. It can be done in other ways but I thought
this to be the simplest/easiest to read.

-- 
Br,

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

Re: [Mesa-dev] [PATCH 3/4] docs: avoid overwrite of LD_LIBRARY_PATH during basic testing

[Andres Gomez]

On Mon, 2017-07-10 at 12:15 +0100, Eric Engestrom wrote:
> On Saturday, 2017-07-08 22:59:40 +0300, Andres Gomez wrote:
> > The LD_LIBRARY_PATH environment variable could be already defined so
> > we extend it and restore it rather than just overwriting it.
> > 
> > Signed-off-by: Andres Gomez 
> > ---
> >  docs/releasing.html | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/docs/releasing.html b/docs/releasing.html
> > index 8e6e4d1a6d..99235d8412 100644
> > --- a/docs/releasing.html
> > +++ b/docs/releasing.html
> > @@ -472,7 +472,8 @@ Here is one solution that I've been using.
> > __glxgears_cmd='glxgears 2>1 | grep -v "configuration file"'
> > __es2info_cmd='es2_info 2>1 | egrep 
> > "GL_VERSION|GL_RENDERER|.*dri\.so"'
> > __es2gears_cmd='es2gears_x11 2>1 | grep -v "configuration file"'
> > -   export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/
> > +   'x$LD_LIBRARY_PATH' -ne 'x'  __old_ld='$LD_LIBRARY_PATH' 
> >  __token=':'
> 
> s/'/"/g across the patch
> 
> and you need `[ ]` around the tests

Ugh! I messed this patch big time. I intended to use "test" but quotes
and the test itself is wrong ... and I'd swear I checked copying and
pasting from the web page. Oh well ...

Thanks a lot for catching all this ☺

-- 
Br,

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

[Mesa-dev] [Bug 101668] Counter-Strike: Global Offense - Everything is purple

[bugzilla-daemon]

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

Ernst Sjöstrand  changed:

   What|Removed |Added

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

--- Comment #5 from Ernst Sjöstrand  ---
Fix in Padoka now.

-- 
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 v3 04/14] i965/bufmgr: Add a BO_ALLOC_ZEROED flag

[Chris Wilson]

Quoting Chad Versace (2017-07-14 23:36:43)
> On Wed 12 Jul 2017, Jason Ekstrand wrote:
> > Cc: Kenneth Graunke 
> > 
> > ---
> >  src/mesa/drivers/dri/i965/brw_bufmgr.c | 28 ++--
> >  src/mesa/drivers/dri/i965/brw_bufmgr.h |  1 +
> >  2 files changed, 27 insertions(+), 2 deletions(-)
> 
> 
> > +  /* All new BOs we get from the kernel are zeroed, so we don't need to
> > +   * worry about that here.
> > +   */
> 
> Assuming the above comment is true, then

It is. Strict policy that all new buffers handed back are zeroed. We've
proposed new interfaces that relax this policy when the user requests
private buffers returned, i.e. just moving the userspace bo cache into
the kernel as a page cache (primarily to keep WC pages around). There is
little incentive for gl/vk(client) as the caching there is pretty
effective, but not everything is as smart. There's also the issue that
most WC pages are shared and therefore not suitable for the private
pool, which kind of rules out the Android problem where it would pass a
stream of buffers from clients to the display server with no recycling.
Or it used to at least.

TLDR; all new buffers are zero and may still reside in the CPU cache.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 3/3] glsl: disable array splitting for AoA

[Timothy Arceri]

On Mon, Jul 3, 2017, at 10:16 AM, Jason Ekstrand wrote:
> I'd like the chance to look at these, please.  I'm on vacation today and 
> tomorrow though.

Ping! 

> 
> 
> On July 3, 2017 7:19:04 AM funfunc...@folklore1984.net wrote:
> 
> > On 2017-07-03 08:47, Timothy Arceri wrote:
> >> While it produces functioning code the pass creates worse code
> >> for arrays of arrays. See the comment added in this patch for more
> >> detail.
> >>
> >> V2: skip splitting of AoA of matrices too.
> >
> > Reviewed-by: Edward O'Callaghan 
> >
> >> ---
> >>  src/compiler/glsl/opt_array_splitting.cpp | 23 +++
> >>  1 file changed, 23 insertions(+)
> >>
> >> diff --git a/src/compiler/glsl/opt_array_splitting.cpp
> >> b/src/compiler/glsl/opt_array_splitting.cpp
> >> index fb6d77b..d2e81665 100644
> >> --- a/src/compiler/glsl/opt_array_splitting.cpp
> >> +++ b/src/compiler/glsl/opt_array_splitting.cpp
> >> @@ -140,6 +140,29 @@
> >> ir_array_reference_visitor::get_variable_entry(ir_variable *var)
> >> if (var->type->is_unsized_array())
> >>return NULL;
> >>
> >> +   /* FIXME: arrays of arrays are not handled correctly by this pass
> >> so we
> >> +* skip it for now. While the pass will create functioning code it
> >> actually
> >> +* produces worse code.
> >> +*
> >> +* For example the array:
> >> +*
> >> +*int[3][2] a;
> >> +*
> >> +* ends up being split up into:
> >> +*
> >> +*int[3][2] a_0;
> >> +*int[3][2] a_1;
> >> +*int[3][2] a_2;
> >> +*
> >> +* And we end up referencing each of these new arrays for example:
> >> +*
> >> +*a[0][1] will be turned into a_0[0][1]
> >> +*a[1][0] will be turned into a_1[1][0]
> >> +*a[2][0] will be turned into a_2[2][0]
> >> +*/
> >> +   if (var->type->is_array() && var->type->fields.array->is_array())
> >> +  return NULL;
> >> +
> >> foreach_in_list(variable_entry, entry, >variable_list) {
> >>if (entry->var == var)
> >>   return entry;
> >
> > ___
> > 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 5/6] radeonsi: use slot indexes for bindless handles

[Nicolai Hähnle]

On 15.07.2017 02:54, Marek Olšák wrote:

On Wed, Jul 5, 2017 at 1:42 PM, Nicolai Hähnle  wrote:

On 04.07.2017 15:05, Samuel Pitoiset wrote:


Using VRAM address as bindless handles is not a good idea because
we have to use LLVMIntToPTr and the LLVM CSE pass can't optimize
because it has no information about the pointer.

Instead, use slots indexes like the existing descriptors.

This improves performance with DOW3 by +7%.



Wow.

The thing is, burning a pair of user SGPRs for this seems a bit overkill,
especially since it also hurts apps that don't use bindless at all.

Do you have some examples of how LLVM fails here? Could we perhaps avoid
most of the performance issues by casting 0 to an appropriate pointer type
once, and then using the bindless handle as an index relative to that
pointer?


The problem is inttoptr doesn't support noalias and LLVM passes assume
it's a generic pointer and therefore don't optimize it. radeonsi loads
descriptors before each use and relies on CSE to unify all equivalent
loads that are close to each other. Without CSE, the resulting code is very bad.


I was thinking that it should be possible to achieve the same effect 
with noalias metadata, but it seems there is some magic about the 
noalias attribute which is stronger than anything achievable with 
metadata. I haven't dug deeper into what that is, exactly.


Cheers,
Nicolai



Another interesting aspect of having the bindless descriptor array in
user SGPRs is that we can do buffer invalidations easily by
reuploading the whole array. That, however, adds a lot of overhead,
because the array is usually huge (64 bytes * 1000 slots), so it's
usually worse than the current solution (partial flushes +
WRITE_DATA). The bindless array could be packed better though.
Textures need 12 dwords, images need 8 dwords, and buffers need 4
dwords. Right now, all slots have 16 dwords.

Samuel, sorry I haven't had time to look at these patches yet.

Marek




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev