Re: [Mesa-dev] [PATCH 1/3] cso: don't release sampler states that are bound

[Michel Dänzer]

On 06/12/16 10:24 PM, Marek Olšák wrote:
> On Mon, Dec 5, 2016 at 10:05 AM, Michel Dänzer  wrote:
>> On 03/12/16 05:38 AM, Marek Olšák wrote:
>>> From: Marek Olšák 
>>>
>>> This fixes random radeonsi GPU hangs in Batman Arkham: Origins (Wine) and
>>> probably many other games too.
>>>
>>> cso_cache deletes sampler states when the cache size is too big and doesn't
>>> check which sampler states are bound, causing use-after-free in drivers.
>>> Because of that, radeonsi uploaded garbage sampler states and the hardware
>>> went bananas. Other drivers may have experienced similar issues.
>>>
>>> Cc: 13.0 12.0 
>>> ---
>>>  src/gallium/auxiliary/cso_cache/cso_cache.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/auxiliary/cso_cache/cso_cache.c 
>>> b/src/gallium/auxiliary/cso_cache/cso_cache.c
>>> index b240c93..1f3be4b 100644
>>> --- a/src/gallium/auxiliary/cso_cache/cso_cache.c
>>> +++ b/src/gallium/auxiliary/cso_cache/cso_cache.c
>>> @@ -181,21 +181,23 @@ static inline void sanitize_cb(struct cso_hash *hash, 
>>> enum cso_cache_type type,
>>>--to_remove;
>>> }
>>>  }
>>>
>>>  struct cso_hash_iter
>>>  cso_insert_state(struct cso_cache *sc,
>>>   unsigned hash_key, enum cso_cache_type type,
>>>   void *state)
>>>  {
>>> struct cso_hash *hash = _cso_hash_for_type(sc, type);
>>> -   sanitize_hash(sc, hash, type, sc->max_size);
>>> +
>>> +   if (type != CSO_SAMPLER)
>>> +  sanitize_hash(sc, hash, type, sc->max_size);
>>>
>>> return cso_hash_insert(hash, hash_key, state);
>>>  }
>>>
>>>  struct cso_hash_iter
>>>  cso_find_state(struct cso_cache *sc,
>>> unsigned hash_key, enum cso_cache_type type)
>>>  {
>>> struct cso_hash *hash = _cso_hash_for_type(sc, type);
>>>
>>>
>>
>> If I understand correctly, this means that the maximum cache size
>> effectively isn't enforced for sampler states? Wouldn't it be better
>> instead to add code which prevents currently bound states from being
>> deleted from here?
> 
> Not in this patch. Maybe later and if CPU profiling results show that
> it matters.
> 
> Currently, if the cache size is exceeded, the GPU usually hangs. If
> pruning the cache was important, most apps would hang.
> 
> Thus, I'd like to push this as-is.

Fair enough, but this will require some follow-up work:

Why are sampler states singled out? The same problem can at least
theoretically happen with other CSOs as well, right?

The maximum cache size needs to be addressed, either something like
above or by just removing the maximum cache size.


BTW, if varying the LOD bias is common, maybe the LOD bias value should
be tracked separately from the remaining sampler state?


P.S. The bug has been there forever, so I don't see the justification
for bypassing the normal stable branch process.

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

[Mesa-dev] [Bug 99014] clover is broken in 12.0.4

[bugzilla-daemon]

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

--- Comment #3 from Igor Gnatenko  ---
(In reply to Michel Dänzer from comment #2)
> Can you bisect which commit broke it?
Unfortunately it's not my bugreport. In theory, I could build RPMs for
reporter, but it would take some time. Does it worth 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

[Mesa-dev] [Bug 99014] clover is broken in 12.0.4

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer  ---
Can you bisect which commit broke 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

[Mesa-dev] [Bug 99014] clover is broken in 12.0.4

[bugzilla-daemon]

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

--- Comment #1 from Igor Gnatenko  ---
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen
Core Processor Integrated Graphics Controller (rev 06)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland
GL [FirePro W2100]

The machine is using the Intel integrated graphics for video output.

The AMD card has no monitors attached to it. It's only used for GPGPU computing
via OpenCL.

-- 
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] [Bug 99014] clover is broken in 12.0.4

[bugzilla-daemon]

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

Igor Gnatenko  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1402259

-- 
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] [Bug 99014] clover is broken in 12.0.4

[bugzilla-daemon]

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

Bug ID: 99014
   Summary: clover is broken in 12.0.4
   Product: Mesa
   Version: 12.0
  Hardware: Other
OS: All
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: i.gnatenko.br...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

https://bugzilla.redhat.com/show_bug.cgi?id=1402259

clpeak when mesa 12.0.4 is installed:
Platform: Clover
  Device: AMD OLAND (DRM 2.46.0 / 4.8.11-300.fc25.x86_64, LLVM 3.8.0)
Driver version  : 12.0.4 (Linux x64)
Compute units   : 5
Clock frequency : 680 MHz

Global memory bandwidth (GBPS)
  float   : radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
(messages repeated)

dmesg has garbage like this:
[ 1444.937817] [drm:si_vm_reg_valid.part.24 [radeon]] *ERROR* Invalid register
0x950c in CS
[ 1444.937818]  0xc0012800
[ 1444.937819]  0x8000
[ 1444.937819]  0x8000
[ 1444.937819]  0xc0026900
...

Expected results:

clpeak after downgrading to mesa 12.0.3:

Platform: Clover
  Device: AMD OLAND (DRM 2.46.0 / 4.8.11-300.fc25.x86_64, LLVM 3.8.0)
Driver version  : 12.0.3 (Linux x64)
Compute units   : 5
Clock frequency : 680 MHz

Global memory bandwidth (GBPS)
  float   : 23.72
  float2  : 24.14
  ...

-- 
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 v2] EGL/android: Enhance pbuffer implementation

[Tomasz Figa]

On Tue, Dec 6, 2016 at 5:49 PM, Liu Zhiquan  wrote:
> Some dri drivers will pass multiple bits in buffer_mask parameter
> to droid_image_get_buffer(), more than the actual supported buffer
> type combination. For such case, will go through all the bits, and
> will not return error when unsupported buffer is requested, only
> return error when the allocation for supported buffer failed.
>

Missing changelog. Please see http://www.mesa3d.org/devinfo.html#submitting.

+ few more minor issues inline. Otherwise the behavior seems fine now.

> Signed-off-by: Liu Zhiquan 
> Signed-off-by: Long, Zhifang 
> ---
>  src/egl/drivers/dri2/platform_android.c | 180 
> ++--
>  1 file changed, 101 insertions(+), 79 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index 373e2c0..46c6efa 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -434,81 +434,92 @@ update_buffers(struct dri2_egl_surface *dri2_surf)
>  }
>
>  static int
> -get_back_bo(struct dri2_egl_surface *dri2_surf)
> +get_front_bo(struct dri2_egl_surface *dri2_surf, unsigned int format)
>  {
> struct dri2_egl_display *dri2_dpy =
>dri2_egl_display(dri2_surf->base.Resource.Display);
> -   int fourcc, pitch;
> -   int offset = 0, fd;
>
> -   if (dri2_surf->dri_image_back)
> +   if (dri2_surf->dri_image_front) {

Style: No need for braces.

>return 0;
> -
> -   if (!dri2_surf->buffer)
> -  return -1;
> -
> -   fd = get_native_buffer_fd(dri2_surf->buffer);
> -   if (fd < 0) {
> -  _eglLog(_EGL_WARNING, "Could not get native buffer FD");
> -  return -1;
> }
>
> -   fourcc = get_fourcc(dri2_surf->buffer->format);
> +   if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
> +  /* According current EGL spec, front buffer rendering
> +   * for window surface is not supported now.
> +   * and mesa doesn't have the implementation of this case.
> +   * Add warning message, but not treat it as error.
> +   */
> +  _eglLog(_EGL_DEBUG, "DRI driver requested unsupported front buffer for 
> window surface");
>

Style: Unnecessary blank line.

> -   pitch = dri2_surf->buffer->stride *
> -  get_format_bpp(dri2_surf->buffer->format);
> +   } else if (dri2_surf->base.Type == EGL_PBUFFER_BIT) {
>

Style: Unnecessary blank line.

> -   if (fourcc == -1 || pitch == 0) {
> -  _eglLog(_EGL_WARNING, "Invalid buffer fourcc(%x) or pitch(%d)",
> -  fourcc, pitch);
> -  return -1;
> +  dri2_surf->dri_image_front =
> +  dri2_dpy->image->createImage(dri2_dpy->dri_screen,
> +  dri2_surf->base.Width,
> +  dri2_surf->base.Height,
> +  format,
> +  0,
> +  dri2_surf);
> +  if (!dri2_surf->dri_image_front) {
> + _eglLog(_EGL_WARNING, "dri2_image_front allocation failed");
> + return -1;
> +  }
> }
>
> -   dri2_surf->dri_image_back =
> -  dri2_dpy->image->createImageFromFds(dri2_dpy->dri_screen,
> -  dri2_surf->base.Width,
> -  dri2_surf->base.Height,
> -  fourcc,
> -  ,
> -  1,
> -  ,
> -  ,
> -  dri2_surf);
> -   if (!dri2_surf->dri_image_back)
> -  return -1;
> -
> return 0;
>  }
>
>  static int
> -droid_image_get_buffers(__DRIdrawable *driDrawable,
> -  unsigned int format,
> -  uint32_t *stamp,
> -  void *loaderPrivate,
> -  uint32_t buffer_mask,
> -  struct __DRIimageList *images)
> +get_back_bo(struct dri2_egl_surface *dri2_surf, unsigned int format)
>  {
> -   struct dri2_egl_surface *dri2_surf = loaderPrivate;
> struct dri2_egl_display *dri2_dpy =
>dri2_egl_display(dri2_surf->base.Resource.Display);
> +   int fourcc, pitch;
> +   int offset = 0, fd;
>
> -   images->image_mask = 0;
> -   images->front = NULL;
> -   images->back = NULL;
> -
> -   if (update_buffers(dri2_surf) < 0)
> +   if (dri2_surf->dri_image_back) {
>return 0;
> +   }

Style: Unnecessary braces.

>
> -   if (buffer_mask & __DRI_IMAGE_BUFFER_FRONT) {
> -  if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
> - /* According current EGL spec,
> -  * front buffer rendering for window surface is not supported now */
> - _eglLog(_EGL_WARNING,
> - "%s:%d front buffer rendering for window surface is not 
> supported!",
> - 

Re: [Mesa-dev] [PATCH] glsl: fix ldexp lowering if bitfield insert lowering is also requested

[Michel Dänzer]

On 07/12/16 01:50 AM, Roland Scheidegger wrote:
> Oops sorry for that. Looks like I changed the type of a constant
> accidentally - I probably copied that bit from the original code
> instead, which might have had it wrong at that time without
> consequences... Should hopefully be fixed now.

Yep, it's fixed, thanks!


-- 
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] radeonsi: fix an off-by-one error in the bounds check for max_vertices

[Michel Dänzer]

On 07/12/16 05:06 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle 
> 
> The spec actually says that calling EmitStreamVertex is undefined when
> you exceed max_vertices. But we do need to avoid trampling over memory
> outside the GSVS ring.

Why "but"? It still works up to max_vertices with your fix, right? Anyway,

Reviewed-by: Michel Dänzer 


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

[Mesa-dev] [Bug 98563] Xorg segfaults with displaylink attached and mesa version >= 13.0

[bugzilla-daemon]

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

--- Comment #12 from Mark Janes  ---
David:  please reopen this bug if it is not fixed by libdrm 2.4.74

-- 
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 98563] Xorg segfaults with displaylink attached and mesa version >= 13.0

[bugzilla-daemon]

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

--- Comment #11 from David Rosenstrauch  ---
Can you please clarify?  If this is resolved, then what new package release
provides the fixed behavior?  I'm still seeing this issue today (also on Arch
Linux) and had to downgrade back to Mesa 12 to work around.

-- 
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 v3 3/3] vulkan: use STATIC_ASSERT instead of static_assert

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Tue, Dec 6, 2016 at 3:30 PM, Edward O'Callaghan <
funfunc...@folklore1984.net> wrote:

> Following the spirit of commit 23d1799f, fixes compilation
> warnings on Android build due to lack of C11 features.
>
> Signed-off-by: Edward O'Callaghan 
> ---
>  src/amd/vulkan/radv_private.h   | 2 +-
>  src/vulkan/wsi/wsi_common_wayland.c | 2 +-
>  src/vulkan/wsi/wsi_common_x11.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
> index def0af2..4b72017 100644
> --- a/src/amd/vulkan/radv_private.h
> +++ b/src/amd/vulkan/radv_private.h
> @@ -173,7 +173,7 @@ radv_clear_mask(uint32_t *inout_mask, uint32_t
> clear_mask)
>  __dword &= ~(1 << (b)))
>
>  #define typed_memcpy(dest, src, count) ({  \
> -   static_assert(sizeof(*src) == sizeof(*dest), ""); \
> +   STATIC_ASSERT(sizeof(*src) == sizeof(*dest)); \
> memcpy((dest), (src), (count) * sizeof(*(src))); \
> })
>
> diff --git a/src/vulkan/wsi/wsi_common_wayland.c
> b/src/vulkan/wsi/wsi_common_wayland.c
> index f6c218b..2fe889e 100644
> --- a/src/vulkan/wsi/wsi_common_wayland.c
> +++ b/src/vulkan/wsi/wsi_common_wayland.c
> @@ -38,7 +38,7 @@
>  #include 
>
>  #define typed_memcpy(dest, src, count) ({ \
> -   static_assert(sizeof(*src) == sizeof(*dest), ""); \
> +   STATIC_ASSERT(sizeof(*src) == sizeof(*dest)); \
> memcpy((dest), (src), (count) * sizeof(*(src))); \
>  })
>
> diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_
> x11.c
> index 56398ce..25ba0c1 100644
> --- a/src/vulkan/wsi/wsi_common_x11.c
> +++ b/src/vulkan/wsi/wsi_common_x11.c
> @@ -42,7 +42,7 @@
>  #include "wsi_common_queue.h"
>
>  #define typed_memcpy(dest, src, count) ({ \
> -   static_assert(sizeof(*src) == sizeof(*dest), ""); \
> +   STATIC_ASSERT(sizeof(*src) == sizeof(*dest)); \
> memcpy((dest), (src), (count) * sizeof(*(src))); \
>  })
>
> --
> 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] [PATCH] nir: Only float and double types can be matrices

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

Might be worth adding something to nir_validate at some point.  Doesn't
have to be today though.

--Jason

On Tue, Dec 6, 2016 at 5:32 PM, Ian Romanick  wrote:

> From: Ian Romanick 
>
> In 19a541f (nir: Get rid of nir_constant_data) a number of places that
> operated on nir_constant::values were mechanically converted to operate
> on the whole array without regard for the base type.  Only
> GLSL_TYPE_FLOAT and GLSL_TYPE_DOUBLE can be matrices, so only those
> types can have data in the non-0 array element.
>
> See also b870394.
>
> Signed-off-by: Ian Romanick 
> Cc: Jason Ekstrand 
> Cc: Iago Toral Quiroga 
> ---
>  src/compiler/glsl/glsl_to_nir.cpp | 32 ++--
>  src/compiler/nir/nir_print.c  | 11 ++-
>  2 files changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/src/compiler/glsl/glsl_to_nir.cpp
> b/src/compiler/glsl/glsl_to_nir.cpp
> index 4debc37..18a53b6 100644
> --- a/src/compiler/glsl/glsl_to_nir.cpp
> +++ b/src/compiler/glsl/glsl_to_nir.cpp
> @@ -207,17 +207,21 @@ constant_copy(ir_constant *ir, void *mem_ctx)
> ret->num_elements = 0;
> switch (ir->type->base_type) {
> case GLSL_TYPE_UINT:
> -  for (unsigned c = 0; c < cols; c++) {
> - for (unsigned r = 0; r < rows; r++)
> -ret->values[c].u32[r] = ir->value.u[c * rows + r];
> -  }
> +  /* Only float base types can be matrices. */
> +  assert(cols == 1);
> +
> +  for (unsigned r = 0; r < rows; r++)
> + ret->values[0].u32[r] = ir->value.u[r];
> +
>break;
>
> case GLSL_TYPE_INT:
> -  for (unsigned c = 0; c < cols; c++) {
> - for (unsigned r = 0; r < rows; r++)
> -ret->values[c].i32[r] = ir->value.i[c * rows + r];
> -  }
> +  /* Only float base types can be matrices. */
> +  assert(cols == 1);
> +
> +  for (unsigned r = 0; r < rows; r++)
> + ret->values[0].i32[r] = ir->value.i[r];
> +
>break;
>
> case GLSL_TYPE_FLOAT:
> @@ -235,12 +239,12 @@ constant_copy(ir_constant *ir, void *mem_ctx)
>break;
>
> case GLSL_TYPE_BOOL:
> -  for (unsigned c = 0; c < cols; c++) {
> - for (unsigned r = 0; r < rows; r++) {
> -ret->values[c].u32[r] = ir->value.b[c * rows + r] ?
> -NIR_TRUE : NIR_FALSE;
> - }
> -  }
> +  /* Only float base types can be matrices. */
> +  assert(cols == 1);
> +
> +  for (unsigned r = 0; r < rows; r++)
> + ret->values[0].u32[r] = ir->value.b[r] ? NIR_TRUE : NIR_FALSE;
> +
>break;
>
> case GLSL_TYPE_STRUCT:
> diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
> index eb5f57f..e51b6f5 100644
> --- a/src/compiler/nir/nir_print.c
> +++ b/src/compiler/nir/nir_print.c
> @@ -303,11 +303,12 @@ print_constant(nir_constant *c, const struct
> glsl_type *type, print_state *state
> case GLSL_TYPE_UINT:
> case GLSL_TYPE_INT:
> case GLSL_TYPE_BOOL:
> -  for (i = 0; i < cols; i++) {
> - for (j = 0; j < rows; j++) {
> -if (i + j > 0) fprintf(fp, ", ");
> -fprintf(fp, "0x%08x", c->values[i].u32[j]);
> - }
> +  /* Only float base types can be matrices. */
> +  assert(cols == 1);
> +
> +  for (i = 0; i < rows; i++) {
> + if (i > 0) fprintf(fp, ", ");
> + fprintf(fp, "0x%08x", c->values[0].u32[i]);
>}
>break;
>
> --
> 2.7.4
>
> ___
> 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] nir: Only float and double types can be matrices

[Ian Romanick]

From: Ian Romanick 

In 19a541f (nir: Get rid of nir_constant_data) a number of places that
operated on nir_constant::values were mechanically converted to operate
on the whole array without regard for the base type.  Only
GLSL_TYPE_FLOAT and GLSL_TYPE_DOUBLE can be matrices, so only those
types can have data in the non-0 array element.

See also b870394.

Signed-off-by: Ian Romanick 
Cc: Jason Ekstrand 
Cc: Iago Toral Quiroga 
---
 src/compiler/glsl/glsl_to_nir.cpp | 32 ++--
 src/compiler/nir/nir_print.c  | 11 ++-
 2 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index 4debc37..18a53b6 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -207,17 +207,21 @@ constant_copy(ir_constant *ir, void *mem_ctx)
ret->num_elements = 0;
switch (ir->type->base_type) {
case GLSL_TYPE_UINT:
-  for (unsigned c = 0; c < cols; c++) {
- for (unsigned r = 0; r < rows; r++)
-ret->values[c].u32[r] = ir->value.u[c * rows + r];
-  }
+  /* Only float base types can be matrices. */
+  assert(cols == 1);
+
+  for (unsigned r = 0; r < rows; r++)
+ ret->values[0].u32[r] = ir->value.u[r];
+
   break;
 
case GLSL_TYPE_INT:
-  for (unsigned c = 0; c < cols; c++) {
- for (unsigned r = 0; r < rows; r++)
-ret->values[c].i32[r] = ir->value.i[c * rows + r];
-  }
+  /* Only float base types can be matrices. */
+  assert(cols == 1);
+
+  for (unsigned r = 0; r < rows; r++)
+ ret->values[0].i32[r] = ir->value.i[r];
+
   break;
 
case GLSL_TYPE_FLOAT:
@@ -235,12 +239,12 @@ constant_copy(ir_constant *ir, void *mem_ctx)
   break;
 
case GLSL_TYPE_BOOL:
-  for (unsigned c = 0; c < cols; c++) {
- for (unsigned r = 0; r < rows; r++) {
-ret->values[c].u32[r] = ir->value.b[c * rows + r] ?
-NIR_TRUE : NIR_FALSE;
- }
-  }
+  /* Only float base types can be matrices. */
+  assert(cols == 1);
+
+  for (unsigned r = 0; r < rows; r++)
+ ret->values[0].u32[r] = ir->value.b[r] ? NIR_TRUE : NIR_FALSE;
+
   break;
 
case GLSL_TYPE_STRUCT:
diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
index eb5f57f..e51b6f5 100644
--- a/src/compiler/nir/nir_print.c
+++ b/src/compiler/nir/nir_print.c
@@ -303,11 +303,12 @@ print_constant(nir_constant *c, const struct glsl_type 
*type, print_state *state
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT:
case GLSL_TYPE_BOOL:
-  for (i = 0; i < cols; i++) {
- for (j = 0; j < rows; j++) {
-if (i + j > 0) fprintf(fp, ", ");
-fprintf(fp, "0x%08x", c->values[i].u32[j]);
- }
+  /* Only float base types can be matrices. */
+  assert(cols == 1);
+
+  for (i = 0; i < rows; i++) {
+ if (i > 0) fprintf(fp, ", ");
+ fprintf(fp, "0x%08x", c->values[0].u32[i]);
   }
   break;
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH v2 02/25] tgsi: add Stream{X, Y, Z, W} fields to tgsi_declaration_semantic

[Marek Olšák]

On Tue, Dec 6, 2016 at 11:48 AM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> This is for geometry shader outputs. Without it, drivers have no way of
> knowing which stream each output is intended for, and have to
> conservatively write all outputs to all streams.
>
> Separate stream numbers for each component are required due to output
> packing.
> ---
>  src/compiler/glsl/ir_print_visitor.cpp |  4 +--
>  src/gallium/auxiliary/tgsi/tgsi_build.c| 18 +--
>  src/gallium/auxiliary/tgsi/tgsi_dump.c | 13 
>  src/gallium/auxiliary/tgsi/tgsi_text.c | 48 
> ++
>  src/gallium/include/pipe/p_shader_tokens.h |  5 +++-
>  5 files changed, 83 insertions(+), 5 deletions(-)
>
> diff --git a/src/compiler/glsl/ir_print_visitor.cpp 
> b/src/compiler/glsl/ir_print_visitor.cpp
> index 2b77c14..d401426 100644
> --- a/src/compiler/glsl/ir_print_visitor.cpp
> +++ b/src/compiler/glsl/ir_print_visitor.cpp
> @@ -173,26 +173,26 @@ void ir_print_visitor::visit(ir_variable *ir)
> if (ir->data.location != -1)
>snprintf(loc, sizeof(loc), "location=%i ", ir->data.location);
>
> char component[32] = {0};
> if (ir->data.explicit_component)
>snprintf(component, sizeof(component), "component=%i ", 
> ir->data.location_frac);
>
> char stream[32] = {0};
> if (ir->data.stream & (1u << 31)) {
>if (ir->data.stream & ~(1u << 31)) {
> - snprintf(stream, sizeof(stream), "stream(%u,%u,%u,%u)",
> + snprintf(stream, sizeof(stream), "stream(%u,%u,%u,%u) ",
>ir->data.stream & 3, (ir->data.stream >> 2) & 3,
>(ir->data.stream >> 4) & 3, (ir->data.stream >> 6) & 3);
>}
> } else if (ir->data.stream) {
> -  snprintf(stream, sizeof(stream), "stream%u", ir->data.stream);
> +  snprintf(stream, sizeof(stream), "stream%u ", ir->data.stream);
> }
>
> const char *const cent = (ir->data.centroid) ? "centroid " : "";
> const char *const samp = (ir->data.sample) ? "sample " : "";
> const char *const patc = (ir->data.patch) ? "patch " : "";
> const char *const inv = (ir->data.invariant) ? "invariant " : "";
> const char *const prec = (ir->data.precise) ? "precise " : "";
> const char *const mode[] = { "", "uniform ", "shader_storage ",
>  "shader_shared ", "shader_in ", "shader_out 
> ",
>  "in ", "out ", "inout ",

Unrelated GLSL changes.

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

Re: [Mesa-dev] [PATCH] i965/blit: Remove Yf/Ys tiled check under a FIXME at can_fast_copy_blit

[Anuj Phogat]

On Tue, Dec 6, 2016 at 4:26 PM, Anuj Phogat  wrote:
> On Tue, Dec 6, 2016 at 10:58 AM, Alejandro Piñeiro  
> wrote:
>> The FIXME suggest that the check should be removed.
>>
> Only if we see any performance or feature benefits in doing that.
> Last I checked I didn't see any performance benefits on Skylake.
and that was more than 6 months back. Things might be different now.

> I also couldn't figure out the cause of random failure in a piglit test:
>  ./bin/texelFetch fs sampler2DMSArray 4 98x1x9-98x129x9 -auto -fbo
>
> I'm still seeing this failure when I tested your patch with Jenkins CI system.
> Test passes when I run it locally on my system.
>
>> This change helps the following test:
>> GL45-CTS.texture_cube_map_array.color_depth_attachments
>>
>> to pass consistently on Skylake GT3e. Without this patch, on
>> Skylake GT3e that test has a ~76% pass rate, with some random
>> intel_do_flush_locked errors now and then.
>>
> By removing this check you're actually enabling fast copy blit on SKL+
> for all the tiling formats. So, now the driver will use XY_FAST_COPY_BLT
> in place of XY_SRC_COPY_BLT. If this change is fixing a test case for
> you, that's not because this is the right fix, but that's because you're
> avoiding to use XY_SRC_COPY_BLT.
> XY_SRC_COPY_BLT might be causing intel_do_flush_locked errors
> and the test failure. We need to dig in there to find the real cause.
>
>> It works fine on Skylake GT2, though.
>> ---
>>
>> I didn't analyze too much the code. It was more git history analysis.
>>
>> When I started to work to solve that test, I remembered that there was
>> a time in the past that worked, so I just did a git bisect. The more
>> recent bad commit I found was df210f. In any case, that one just fixed
>> that check, as became broken with commit 0c02d7. The one that added
>> the check (and the FIXME) was commit 412c8c.
>>
>> As the commit message says, that FIXME seems to suggest that is a
>> provisional change. Although I recognize that the failure is really
>> specific (for a Skylake model, not failing always), removing the check
>> gets the test pass consistently, and as far as I see, it didn't
>> introduce any regression.
>>
>>  src/mesa/drivers/dri/i965/intel_blit.c | 8 
>>  1 file changed, 8 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_blit.c 
>> b/src/mesa/drivers/dri/i965/intel_blit.c
>> index 03a35ee..9f3b4d1 100644
>> --- a/src/mesa/drivers/dri/i965/intel_blit.c
>> +++ b/src/mesa/drivers/dri/i965/intel_blit.c
>> @@ -487,14 +487,6 @@ can_fast_copy_blit(struct brw_context *brw,
>> if (brw->gen < 9)
>>return false;
>>
>> -   /* Enable fast copy blit only if the surfaces are Yf/Ys tiled.
>> -* FIXME: Based on performance data, remove this condition later to
>> -* enable for all types of surfaces.
>> -*/
>> -   if (src_tr_mode == INTEL_MIPTREE_TRMODE_NONE &&
>> -   dst_tr_mode == INTEL_MIPTREE_TRMODE_NONE)
>> -  return false;
>> -
>> if (logic_op != GL_COPY)
>>return false;
>>
>> --
>> 2.9.3
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/blit: Remove Yf/Ys tiled check under a FIXME at can_fast_copy_blit

[Anuj Phogat]

On Tue, Dec 6, 2016 at 10:58 AM, Alejandro Piñeiro  wrote:
> The FIXME suggest that the check should be removed.
>
Only if we see any performance or feature benefits in doing that.
Last I checked I didn't see any performance benefits on Skylake.
I also couldn't figure out the cause of random failure in a piglit test:
 ./bin/texelFetch fs sampler2DMSArray 4 98x1x9-98x129x9 -auto -fbo

I'm still seeing this failure when I tested your patch with Jenkins CI system.
Test passes when I run it locally on my system.

> This change helps the following test:
> GL45-CTS.texture_cube_map_array.color_depth_attachments
>
> to pass consistently on Skylake GT3e. Without this patch, on
> Skylake GT3e that test has a ~76% pass rate, with some random
> intel_do_flush_locked errors now and then.
>
By removing this check you're actually enabling fast copy blit on SKL+
for all the tiling formats. So, now the driver will use XY_FAST_COPY_BLT
in place of XY_SRC_COPY_BLT. If this change is fixing a test case for
you, that's not because this is the right fix, but that's because you're
avoiding to use XY_SRC_COPY_BLT.
XY_SRC_COPY_BLT might be causing intel_do_flush_locked errors
and the test failure. We need to dig in there to find the real cause.

> It works fine on Skylake GT2, though.
> ---
>
> I didn't analyze too much the code. It was more git history analysis.
>
> When I started to work to solve that test, I remembered that there was
> a time in the past that worked, so I just did a git bisect. The more
> recent bad commit I found was df210f. In any case, that one just fixed
> that check, as became broken with commit 0c02d7. The one that added
> the check (and the FIXME) was commit 412c8c.
>
> As the commit message says, that FIXME seems to suggest that is a
> provisional change. Although I recognize that the failure is really
> specific (for a Skylake model, not failing always), removing the check
> gets the test pass consistently, and as far as I see, it didn't
> introduce any regression.
>
>  src/mesa/drivers/dri/i965/intel_blit.c | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_blit.c 
> b/src/mesa/drivers/dri/i965/intel_blit.c
> index 03a35ee..9f3b4d1 100644
> --- a/src/mesa/drivers/dri/i965/intel_blit.c
> +++ b/src/mesa/drivers/dri/i965/intel_blit.c
> @@ -487,14 +487,6 @@ can_fast_copy_blit(struct brw_context *brw,
> if (brw->gen < 9)
>return false;
>
> -   /* Enable fast copy blit only if the surfaces are Yf/Ys tiled.
> -* FIXME: Based on performance data, remove this condition later to
> -* enable for all types of surfaces.
> -*/
> -   if (src_tr_mode == INTEL_MIPTREE_TRMODE_NONE &&
> -   dst_tr_mode == INTEL_MIPTREE_TRMODE_NONE)
> -  return false;
> -
> if (logic_op != GL_COPY)
>return false;
>
> --
> 2.9.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

--- Comment #11 from Tobias Droste  ---
Ok, I take a look at this tomorrow (it's late here). 
Sorry for the problems.

For a quick workaround:
Set the env variable LLVM_CONFIG to "no".

e.g.: LLVM_CONFIG=no ./autogen.sh ...

-- 
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] [Bug 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

--- Comment #10 from Vinson Lee  ---
(In reply to Tobias Droste from comment #9)
> Ok now I get it.
> 
> It says "llvm: yes" as soon as it finds LLVM that does not automatically
> mean it is used by something. So this works as expected. 
> Maybe the output can be improved.
> 
> What LLVM version generates error?

Ubuntu 12.04 llvm-2.9

-- 
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] [Bug 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

--- Comment #9 from Tobias Droste  ---
Ok now I get it.

It says "llvm: yes" as soon as it finds LLVM that does not automatically mean
it is used by something. So this works as expected. 
Maybe the output can be improved.

What LLVM version generates error?

-- 
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 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

--- Comment #8 from Vinson Lee  ---
(In reply to Tobias Droste from comment #7)
> What component? Auxiliary?
> 
> If I look at src/gallium/auxiliary/Makefile I see this:
> 
> #am__append_3 = \
> # $(LLVM_CFLAGS)
> 
> #am__append_4 = \
> # $(GALLIUM_CFLAGS) \
> # $(LLVM_CXXFLAGS)
> 
> #am__append_5 = \
> # $(GALLIVM_SOURCES)
> 
> Is it the same for you?

It is always picking up llvm. On recent distros the configure report shows
"llvm: yes". On distros with older llvm, configure fails with "configure:
error: Could not find llvm shared libraries:".

-- 
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 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

--- Comment #7 from Tobias Droste  ---
What component? Auxiliary?

If I look at src/gallium/auxiliary/Makefile I see this:

#am__append_3 = \
#   $(LLVM_CFLAGS)

#am__append_4 = \
#   $(GALLIUM_CFLAGS) \
#   $(LLVM_CXXFLAGS)

#am__append_5 = \
#   $(GALLIVM_SOURCES)

Is it the same for you?

-- 
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] [Bug 98563] Xorg segfaults with displaylink attached and mesa version >= 13.0

[bugzilla-daemon]

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

David Rosenstrauch  changed:

   What|Removed |Added

 CC||dar...@darose.net

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

[Mesa-dev] [PATCH v3 2/3] svga: Fix a strict-aliasing violation in shader dumper

[Edward O'Callaghan]

As per the C spec, it is illegal to alias pointers to different
types. This results in undefined behaviour after optimization
passes, resulting in very subtle bugs that happen only on a
full moon..

Use a memcpy() as a well defined coercion between the isomorphic
bit-field interpretations of memory.

V.2: Use C99 compat STATIC_ASSERT() over C11 static_assert().

Signed-off-by: Edward O'Callaghan 
---
 src/gallium/drivers/svga/svgadump/svga_shader_dump.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/svga/svgadump/svga_shader_dump.c 
b/src/gallium/drivers/svga/svgadump/svga_shader_dump.c
index 4ee1bf2..46126a5 100644
--- a/src/gallium/drivers/svga/svgadump/svga_shader_dump.c
+++ b/src/gallium/drivers/svga/svgadump/svga_shader_dump.c
@@ -30,6 +30,9 @@
  * @author Michal Krol 
  */
 
+#include 
+#include 
+
 #include "svga_shader.h"
 #include "svga_shader_dump.h"
 #include "svga_shader_op.h"
@@ -413,6 +416,11 @@ dump_dstreg(struct sh_dstreg dstreg,
 
 static void dump_srcreg( struct sh_srcreg srcreg, struct sh_srcreg *indreg, 
const struct dump_info *di )
 {
+   struct sh_reg srcreg_sh = {0};
+   /* bit-fields carefully aligned, ensure they stay that way. */
+   STATIC_ASSERT(sizeof(struct sh_reg) == sizeof(struct sh_srcreg));
+   memcpy(_sh, , sizeof(srcreg_sh));
+
switch (srcreg.modifier) {
case SVGA3DSRCMOD_NEG:
case SVGA3DSRCMOD_BIASNEG:
@@ -427,7 +435,7 @@ static void dump_srcreg( struct sh_srcreg srcreg, struct 
sh_srcreg *indreg, cons
case SVGA3DSRCMOD_NOT:
   _debug_printf( "!" );
}
-   dump_reg( *(struct sh_reg *) , indreg, di );
+   dump_reg(srcreg_sh, indreg, di );
switch (srcreg.modifier) {
case SVGA3DSRCMOD_NONE:
case SVGA3DSRCMOD_NEG:
-- 
2.9.3

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

[Mesa-dev] [PATCH v3 3/3] vulkan: use STATIC_ASSERT instead of static_assert

[Edward O'Callaghan]

Following the spirit of commit 23d1799f, fixes compilation
warnings on Android build due to lack of C11 features.

Signed-off-by: Edward O'Callaghan 
---
 src/amd/vulkan/radv_private.h   | 2 +-
 src/vulkan/wsi/wsi_common_wayland.c | 2 +-
 src/vulkan/wsi/wsi_common_x11.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index def0af2..4b72017 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -173,7 +173,7 @@ radv_clear_mask(uint32_t *inout_mask, uint32_t clear_mask)
 __dword &= ~(1 << (b)))
 
 #define typed_memcpy(dest, src, count) ({  \
-   static_assert(sizeof(*src) == sizeof(*dest), ""); \
+   STATIC_ASSERT(sizeof(*src) == sizeof(*dest)); \
memcpy((dest), (src), (count) * sizeof(*(src))); \
})
 
diff --git a/src/vulkan/wsi/wsi_common_wayland.c 
b/src/vulkan/wsi/wsi_common_wayland.c
index f6c218b..2fe889e 100644
--- a/src/vulkan/wsi/wsi_common_wayland.c
+++ b/src/vulkan/wsi/wsi_common_wayland.c
@@ -38,7 +38,7 @@
 #include 
 
 #define typed_memcpy(dest, src, count) ({ \
-   static_assert(sizeof(*src) == sizeof(*dest), ""); \
+   STATIC_ASSERT(sizeof(*src) == sizeof(*dest)); \
memcpy((dest), (src), (count) * sizeof(*(src))); \
 })
 
diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index 56398ce..25ba0c1 100644
--- a/src/vulkan/wsi/wsi_common_x11.c
+++ b/src/vulkan/wsi/wsi_common_x11.c
@@ -42,7 +42,7 @@
 #include "wsi_common_queue.h"
 
 #define typed_memcpy(dest, src, count) ({ \
-   static_assert(sizeof(*src) == sizeof(*dest), ""); \
+   STATIC_ASSERT(sizeof(*src) == sizeof(*dest)); \
memcpy((dest), (src), (count) * sizeof(*(src))); \
 })
 
-- 
2.9.3

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

[Mesa-dev] [PATCH v3 1/3] virgl: Fix a strict-aliasing violation in the encoder

[Edward O'Callaghan]

As per the C spec, it is illegal to alias pointers to different
types. This results in undefined behaviour after optimization
passes, resulting in very subtle bugs that happen only on a
full moon..

Use a memcpy() as a well defined coercion between the double
to uint64_t interpretations of the memory.

V.2: Use static_assert() instead of assert().
V.3: Use C99 compat STATIC_ASSERT() over C11 static_assert().

Signed-off-by: Edward O'Callaghan 
---
 src/gallium/drivers/virgl/virgl_encode.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_encode.c 
b/src/gallium/drivers/virgl/virgl_encode.c
index be72f70..85843b7 100644
--- a/src/gallium/drivers/virgl/virgl_encode.c
+++ b/src/gallium/drivers/virgl/virgl_encode.c
@@ -21,6 +21,8 @@
  * USE OR OTHER DEALINGS IN THE SOFTWARE.
  */
 #include 
+#include 
+#include 
 
 #include "util/u_format.h"
 #include "util/u_memory.h"
@@ -315,12 +317,16 @@ int virgl_encode_clear(struct virgl_context *ctx,
   double depth, unsigned stencil)
 {
int i;
+   uint64_t qword;
+
+   STATIC_ASSERT(sizeof(qword) == sizeof(depth));
+   memcpy(, , sizeof(qword));
 
virgl_encoder_write_cmd_dword(ctx, VIRGL_CMD0(VIRGL_CCMD_CLEAR, 0, 
VIRGL_OBJ_CLEAR_SIZE));
virgl_encoder_write_dword(ctx->cbuf, buffers);
for (i = 0; i < 4; i++)
   virgl_encoder_write_dword(ctx->cbuf, color->ui[i]);
-   virgl_encoder_write_qword(ctx->cbuf, *(uint64_t *));
+   virgl_encoder_write_qword(ctx->cbuf, qword);
virgl_encoder_write_dword(ctx->cbuf, stencil);
return 0;
 }
-- 
2.9.3

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

[Mesa-dev] [Bug 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

--- Comment #6 from Vinson Lee  ---
(In reply to Tobias Droste from comment #4)
> 
> What error do you see?

It builds with llvm.

-- 
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] [Bug 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

--- Comment #5 from Tobias Droste  ---
Does 'git clean -fdx' fix it? Maybe a stale Makefile.

-- 
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] [Bug 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

--- Comment #4 from Tobias Droste  ---
Seems to work fine here. Odd.

It builds a lot of non gallium drivers and src/gallium/drivers/softpipe without
any errors.

What error do you see?

-- 
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 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

--- Comment #3 from Vinson Lee  ---
(In reply to Tobias Droste from comment #2)
> 
> could you tell me what configure options you're using?
> 

./autogen.sh --disable-gallium-llvm --with-gallium-drivers=swrast

-- 
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] [Bug 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

--- Comment #2 from Tobias Droste  ---
Hi Vinson,

could you tell me what configure options you're using?

Thanks,
Tobias

-- 
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 v2 1/2] virgl: Fix a strict-aliasing violation in the encoder

[Dave Airlie]

On 7 December 2016 at 08:34, Edward O'Callaghan
 wrote:
>
>
> On 12/07/2016 12:36 AM, Emil Velikov wrote:
>> On 6 December 2016 at 11:30, Edward O'Callaghan
>>  wrote:
>>> As per the C spec, it is illegal to alias pointers to different
>>> types. This results in undefined behaviour after optimization
>>> passes, resulting in very subtle bugs that happen only on a
>>> full moon..
>>>
>>> Use a memcpy() as a well defined coercion between the double
>>> to uint64_t interpretations of the memory.
>>>
>>> V.2: Use static_assert() instead of assert().
>>>
>> The lowercase static_assert is a c11 feature. You want to use the all
>> caps version.
>> See commit 23d1799f7dd5f8d1e8aa9f4efa6b1a4ed45faaa0
>
> Hi Emil,
>
> Why? I from that commit it seems only Android would have trouble however
> virgl nor svga would want to be enabled on that platform?
>
> Or is there something else I probably missed?

That virgl is enabled on android?

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

Re: [Mesa-dev] [PATCH v2 1/2] virgl: Fix a strict-aliasing violation in the encoder

[Edward O'Callaghan]

On 12/07/2016 12:36 AM, Emil Velikov wrote:
> On 6 December 2016 at 11:30, Edward O'Callaghan
>  wrote:
>> As per the C spec, it is illegal to alias pointers to different
>> types. This results in undefined behaviour after optimization
>> passes, resulting in very subtle bugs that happen only on a
>> full moon..
>>
>> Use a memcpy() as a well defined coercion between the double
>> to uint64_t interpretations of the memory.
>>
>> V.2: Use static_assert() instead of assert().
>>
> The lowercase static_assert is a c11 feature. You want to use the all
> caps version.
> See commit 23d1799f7dd5f8d1e8aa9f4efa6b1a4ed45faaa0

Hi Emil,

Why? I from that commit it seems only Android would have trouble however
virgl nor svga would want to be enabled on that platform?

Or is there something else I probably missed?

Kind Regards,
Edward.

> 
> We might want to use update the final vulkan [codebase] references, as well.
> 
> Thanks
> Emil
> 



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

Re: [Mesa-dev] [PATCH] radeonsi: fix an off-by-one error in the bounds check for max_vertices

[Edward O'Callaghan]

Reviewed-by: Edward O'Callaghan 

On 12/07/2016 07:06 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle 
> 
> The spec actually says that calling EmitStreamVertex is undefined when
> you exceed max_vertices. But we do need to avoid trampling over memory
> outside the GSVS ring.
> 
> Cc: mesa-sta...@lists.freedesktop.org
> --
> One more thing I noticed on top of all the other GS changes...
> ---
>  src/gallium/drivers/radeonsi/si_shader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index dee2a17..749823d 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -5181,21 +5181,21 @@ static void si_llvm_emit_vertex(
>  "");
>  
>   /* If this thread has already emitted the declared maximum number of
>* vertices, skip the write: excessive vertex emissions are not
>* supposed to have any effect.
>*
>* If the shader has no writes to memory, kill it instead. This skips
>* further memory loads and may allow LLVM to skip to the end
>* altogether.
>*/
> - can_emit = LLVMBuildICmp(gallivm->builder, LLVMIntULE, gs_next_vertex,
> + can_emit = LLVMBuildICmp(gallivm->builder, LLVMIntULT, gs_next_vertex,
>lp_build_const_int32(gallivm,
> 
> shader->selector->gs_max_out_vertices), "");
>  
>   bool use_kill = !info->writes_memory;
>   if (use_kill) {
>   kill = lp_build_select(_base->base, can_emit,
>  lp_build_const_float(gallivm, 1.0f),
>  lp_build_const_float(gallivm, -1.0f));
>  
>   lp_build_intrinsic(gallivm->builder, "llvm.AMDGPU.kill",
> 



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

[Mesa-dev] [Bug 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

   Keywords||bisected
 CC||tdro...@gmx.de

--- Comment #1 from Vinson Lee  ---
9d14a25bee0f1457a82f3e42b3baf3db1806faea is the first bad commit
commit 9d14a25bee0f1457a82f3e42b3baf3db1806faea
Author: Tobias Droste 
Date:   Sat Nov 19 02:39:04 2016 +0100

configure.ac: Move llvm_set_environment_variables higher.

This moves the function to get the LLVM environment variables higher
in the file. It still needs to be below the "--enable-opencl" because
it uses $enable_opencl.
It can be called without condition now as it only throws errors if
openCL is enabled.

v5:
HAVE_MESA_LLVM is only used for gallium. Rename it to HAVE_GALLIUM_LLVM.
In order to only link LLVM when it is needed, HAVE_GALLIUM_LLVM is only
set if "$enable-gallium-llvm" is yes.

Signed-off-by: Tobias Droste 
Reviewed-by: Emil Velikov 

:100644 100644 1de6b7e905d33dfa4c69aa2f188db890aba23354
3e9972c7e3204f64bcdc3a4046954e64d5d3cb48 M  configure.ac
:04 04 0aff1bbf50001090806ed625865f42b97ba789a8
8812620b919a6a0c64118896ebe124c199a61685 M  src
bisect run success

-- 
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] [Bug 99010] --disable-gallium-llvm no longer recognized

[bugzilla-daemon]

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

Bug ID: 99010
   Summary: --disable-gallium-llvm no longer recognized
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: emil.l.veli...@gmail.com

-- 
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 v2 3/7] intel/blorp_blit: Adjust blorp surface parameters for split blits

[Jason Ekstrand]

On Wed, Nov 30, 2016 at 8:12 PM, Jordan Justen 
wrote:

> If try_blorp_blit() previously returned that a blit was too large,
> shrink_surface_params() will be used to update the surface parameters
> for the smaller blit so the blit operation can proceed.
>
> v2:
>  * Use double instead of float. (Jason)
>
> Signed-off-by: Jordan Justen 
> ---
>  src/intel/blorp/blorp_blit.c | 108 ++
> +++--
>  1 file changed, 105 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> index b12a4ec..5ca3190 100644
> --- a/src/intel/blorp/blorp_blit.c
> +++ b/src/intel/blorp/blorp_blit.c
> @@ -1486,6 +1486,12 @@ surf_retile_w_to_y(const struct isl_device *isl_dev,
> info->tile_y_sa /= 2;
>  }
>
> +static bool
> +can_shrink_surfaces(const struct blorp_params *params)
> +{
> +   return false;
> +}
> +
>  struct blt_axis {
> double src0, src1, dst0, dst1;
> bool mirror;
> @@ -1732,12 +1738,98 @@ adjust_split_coords(const struct blt_axis *orig,
> split_coords->src1 = orig->src1 + (scale >= 0.0 ? delta1 : delta0);
>  }
>
> +static const struct isl_extent2d
> +get_px_size_sa(const struct isl_surf *surf)
> +{
> +   static const struct isl_extent2d one_to_one = { .w = 1, .h = 1 };
> +
> +   if (surf->msaa_layout != ISL_MSAA_LAYOUT_INTERLEAVED)
> +  return one_to_one;
> +   else
> +  return isl_get_interleaved_msaa_px_size_sa(surf->samples);
> +}
> +
> +static void
> +shrink_surface_params(const struct isl_device *dev,
> +  struct brw_blorp_surface_info *info,
> +  double *x0, double *x1, double *y0, double *y1)
> +{
> +   uint32_t byte_offset, x_offset_sa, y_offset_sa, size;
> +   struct isl_extent2d px_size_sa;
> +   int adjust;
> +
> +   surf_convert_to_single_slice(dev, info);
> +
> +   px_size_sa = get_px_size_sa(>surf);
> +
>

/* Because this gets called after we lower compressed images, the tile
offsets may be non-zero and we need to incorporate them in our
calculations. */


> +   x_offset_sa = (uint32_t)*x0 * px_size_sa.w + info->tile_x_sa;
> +   y_offset_sa = (uint32_t)*y0 * px_size_sa.h + info->tile_y_sa;
> +   isl_tiling_get_intratile_offset_sa(dev, info->surf.tiling,
> +  info->surf.format,
> info->surf.row_pitch,
> +  x_offset_sa, y_offset_sa,
> +  _offset,
> +  >tile_x_sa, >tile_y_sa);
> +
> +   info->addr.offset += byte_offset;
> +
> +   adjust = (int)info->tile_x_sa / px_size_sa.w - (int)*x0;
> +   *x0 += adjust;
> +   *x1 += adjust;
> +   info->tile_x_sa = 0;
> +
> +   adjust = (int)info->tile_y_sa / px_size_sa.h - (int)*y0;
> +   *y0 += adjust;
> +   *y1 += adjust;
> +   info->tile_y_sa = 0;
> +
> +   size = MIN2((uint32_t)ceilf(*x1), info->surf.logical_level0_px.width);
> +   double phys_scale =
> +  info->surf.phys_level0_sa.width / info->surf.logical_level0_px.
> width;
> +   info->surf.logical_level0_px.width = size;
> +   info->surf.phys_level0_sa.width =
> +  (uint32_t)ceilf(phys_scale * size);
> +
> +   size = MIN2((uint32_t)ceilf(*y1), info->surf.logical_level0_px.
> height);
> +   phys_scale =
> +  info->surf.phys_level0_sa.height / info->surf.logical_level0_px.
> height;
> +   info->surf.logical_level0_px.height = (uint32_t)ceilf(size);
> +   info->surf.phys_level0_sa.height =
> +  (uint32_t)ceilf(phys_scale * size);
>

I made a comment in an earlier e-mail about the scaling here.  I think I'd
rather we just use px_size_sa than this double.

I made one other comment on another patch.  With that and these addressed,
the series is

Reviewed-by: Jason Ekstrand 


> +}
> +
> +static void
> +shrink_surfaces(const struct isl_device *dev,
> +struct blorp_params *params,
> +struct brw_blorp_blit_prog_key *wm_prog_key,
> +struct blt_coords *coords)
> +{
> +   /* Shrink source surface */
> +   shrink_surface_params(dev,
> + >src,
> + >x.src0,
> + >x.src1,
> + >y.src0,
> + >y.src1);
> +   wm_prog_key->need_src_offset = false;
> +
> +   /* Shrink destination surface */
> +   shrink_surface_params(dev,
> + >dst,
> + >x.dst0,
> + >x.dst1,
> + >y.dst0,
> + >y.dst1);
> +   wm_prog_key->need_dst_offset = wm_prog_key->dst_rgb;
> +}
> +
>  static void
>  do_blorp_blit(struct blorp_batch *batch,
> -  struct blorp_params *params,
> +  const struct blorp_params *orig_params,
>struct brw_blorp_blit_prog_key *wm_prog_key,
>const struct blt_coords *orig)
>  {
> +   struct blorp_params params;
> +   struct 

Re: [Mesa-dev] [PATCH v2 5/7] intel/blorp_blit: Enable splitting large blorp blits

[Jason Ekstrand]

On Wed, Nov 30, 2016 at 8:12 PM, Jordan Justen 
wrote:

> Detect when the surface sizes are too large for a blorp blit. When it
> is too large, the blorp blit will be split into a smaller operation
> and attempted again.
>
> For gen7, this fixes the cts test:
>
> ES3-CTS.gtf.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_
> multisampled_to_singlesampled_blit
>
> It will also enable us to increase our renderable size from 8k x 8k to
> 16k x 16k.
>
> Signed-off-by: Jordan Justen 
> ---
>  src/intel/blorp/blorp_blit.c | 37 -
>  1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> index 782144a..58e9e0c 100644
> --- a/src/intel/blorp/blorp_blit.c
> +++ b/src/intel/blorp/blorp_blit.c
> @@ -1487,9 +1487,37 @@ surf_retile_w_to_y(const struct isl_device *isl_dev,
>  }
>
>  static bool
> +can_shrink_surface(const struct brw_blorp_surface_info *surf)
> +{
> +   return
> +  /* The current code doesn't support offsets into the aux buffers.
> This
> +   * should be possible, but we need to make sure the offset is page
> +   * aligned for both the surface and the aux buffer surface.
> Generally
> +   * this mean using the page aligned offset for the aux buffer.
> +   *
> +   * Currently the cases where we must split the blit are limited to
> cases
> +   * where we don't have a aux buffer.
> +   */
> +  surf->aux_addr.buffer == NULL &&
> +  /* We can't support splitting the blit for gen <= 7, because the
> qpitch
> +   * size is calculated by the hardware based on the surface height
> for
> +   * gen <= 7. In gen >= 8, the qpitch is controlled by the driver.
> +   */
> +  surf->surf.msaa_layout != ISL_MSAA_LAYOUT_ARRAY;
>

This might be a bit clearer as

if (surf->aux_addr.buffer != NULL)
   return false;

if (surf->surf.msaa_layout == ISL_MSAA_LAYOUT_ARRAY)
   return false;

return true;

But I don't care too much about it.


> +}
> +
> +static bool
>  can_shrink_surfaces(const struct blorp_params *params)
>  {
> -   return false;
> +   return
> +  can_shrink_surface(>src) &&
> +  can_shrink_surface(>dst);
> +}
> +
> +static unsigned
> +get_max_surface_size()
> +{
> +   return 16384;
>  }
>
>  struct blt_axis {
> @@ -1716,6 +1744,13 @@ try_blorp_blit(struct blorp_batch *batch,
> brw_blorp_get_blit_kernel(batch->blorp, params, wm_prog_key);
>
> unsigned result = 0;
> +   unsigned max_surface_size = get_max_surface_size(devinfo, params);
> +   if (params->src.surf.logical_level0_px.width > max_surface_size ||
> +   params->dst.surf.logical_level0_px.width > max_surface_size)
> +  result |= BLIT_WIDTH_TOO_LARGE;
> +   if (params->src.surf.logical_level0_px.height > max_surface_size ||
> +   params->dst.surf.logical_level0_px.height > max_surface_size)
> +  result |= BLIT_HEIGHT_TOO_LARGE;
>
> if (result == 0) {
>batch->blorp->exec(batch, params);
> --
> 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

Re: [Mesa-dev] [PATCH v2 5/7] intel/blorp_blit: Enable splitting large blorp blits

[Jason Ekstrand]

On Wed, Nov 30, 2016 at 8:12 PM, Jordan Justen 
wrote:

> Detect when the surface sizes are too large for a blorp blit. When it
> is too large, the blorp blit will be split into a smaller operation
> and attempted again.
>
> For gen7, this fixes the cts test:
>
> ES3-CTS.gtf.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_
> multisampled_to_singlesampled_blit
>
> It will also enable us to increase our renderable size from 8k x 8k to
> 16k x 16k.
>
> Signed-off-by: Jordan Justen 
> ---
>  src/intel/blorp/blorp_blit.c | 37 -
>  1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> index 782144a..58e9e0c 100644
> --- a/src/intel/blorp/blorp_blit.c
> +++ b/src/intel/blorp/blorp_blit.c
> @@ -1487,9 +1487,37 @@ surf_retile_w_to_y(const struct isl_device *isl_dev,
>  }
>
>  static bool
> +can_shrink_surface(const struct brw_blorp_surface_info *surf)
> +{
> +   return
> +  /* The current code doesn't support offsets into the aux buffers.
> This
> +   * should be possible, but we need to make sure the offset is page
> +   * aligned for both the surface and the aux buffer surface.
> Generally
> +   * this mean using the page aligned offset for the aux buffer.
> +   *
> +   * Currently the cases where we must split the blit are limited to
> cases
> +   * where we don't have a aux buffer.
> +   */
> +  surf->aux_addr.buffer == NULL &&
> +  /* We can't support splitting the blit for gen <= 7, because the
> qpitch
> +   * size is calculated by the hardware based on the surface height
> for
> +   * gen <= 7. In gen >= 8, the qpitch is controlled by the driver.
> +   */
> +  surf->surf.msaa_layout != ISL_MSAA_LAYOUT_ARRAY;
>

This might be a bit clearer as

if (surf->aux_addr.buffer != NULL)



> +}
> +
> +static bool
>  can_shrink_surfaces(const struct blorp_params *params)
>  {
> -   return false;
> +   return
> +  can_shrink_surface(>src) &&
> +  can_shrink_surface(>dst);
> +}
> +
> +static unsigned
> +get_max_surface_size()
> +{
> +   return 16384;
>  }
>
>  struct blt_axis {
> @@ -1716,6 +1744,13 @@ try_blorp_blit(struct blorp_batch *batch,
> brw_blorp_get_blit_kernel(batch->blorp, params, wm_prog_key);
>
> unsigned result = 0;
> +   unsigned max_surface_size = get_max_surface_size(devinfo, params);
> +   if (params->src.surf.logical_level0_px.width > max_surface_size ||
> +   params->dst.surf.logical_level0_px.width > max_surface_size)
> +  result |= BLIT_WIDTH_TOO_LARGE;
> +   if (params->src.surf.logical_level0_px.height > max_surface_size ||
> +   params->dst.surf.logical_level0_px.height > max_surface_size)
> +  result |= BLIT_HEIGHT_TOO_LARGE;
>
> if (result == 0) {
>batch->blorp->exec(batch, params);
> --
> 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

Re: [Mesa-dev] [PATCH] i965: Drop redundant key->outputs_written initialization.

[Matt Turner]

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

Re: [Mesa-dev] [PATCH] i965: Initialize "separate" flag in VUE maps.

[Matt Turner]

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

[Mesa-dev] [PATCH] i965: Drop redundant key->outputs_written initialization.

[Kenneth Graunke]

This was already set to the same value earlier.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_tcs.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c 
b/src/mesa/drivers/dri/i965/brw_tcs.c
index 95926db..76cd0a5 100644
--- a/src/mesa/drivers/dri/i965/brw_tcs.c
+++ b/src/mesa/drivers/dri/i965/brw_tcs.c
@@ -317,62 +317,60 @@ brw_tcs_populate_key(struct brw_context *brw,
 
uint64_t per_vertex_slots = tes_prog->info.inputs_read;
uint32_t per_patch_slots = tes_prog->info.patch_inputs_read;
 
memset(key, 0, sizeof(*key));
 
if (tcp) {
   struct gl_program *prog = >program;
   per_vertex_slots |= prog->info.outputs_written;
   per_patch_slots |= prog->info.patch_outputs_written;
}
 
if (brw->gen < 8 || !tcp)
   key->input_vertices = brw->ctx.TessCtrlProgram.patch_vertices;
key->outputs_written = per_vertex_slots;
key->patch_outputs_written = per_patch_slots;
 
/* We need to specialize our code generation for tessellation levels
 * based on the domain the DS is expecting to tessellate.
 */
key->tes_primitive_mode = tep->program.info.tes.primitive_mode;
key->quads_workaround = brw->gen < 9 &&
tep->program.info.tes.primitive_mode == GL_QUADS &&
tep->program.info.tes.spacing == GL_EQUAL;
 
if (tcp) {
   key->program_string_id = tcp->id;
 
   /* _NEW_TEXTURE */
   brw_populate_sampler_prog_key_data(>ctx, >program, >tex);
-   } else {
-  key->outputs_written = tes_prog->info.inputs_read;
}
 }
 
 void
 brw_upload_tcs_prog(struct brw_context *brw)
 {
struct gl_shader_program **current = brw->ctx._Shader->CurrentProgram;
struct brw_stage_state *stage_state = >tcs.base;
struct brw_tcs_prog_key key;
/* BRW_NEW_TESS_PROGRAMS */
struct brw_program *tcp = (struct brw_program *) brw->tess_ctrl_program;
MAYBE_UNUSED struct brw_program *tep =
   (struct brw_program *) brw->tess_eval_program;
assert(tep);
 
if (!brw_state_dirty(brw,
 _NEW_TEXTURE,
 BRW_NEW_PATCH_PRIMITIVE |
 BRW_NEW_TESS_PROGRAMS))
   return;
 
brw_tcs_populate_key(brw, );
 
if (!brw_search_cache(>cache, BRW_CACHE_TCS_PROG,
  , sizeof(key),
  _state->prog_offset,
  >tcs.base.prog_data)) {
   bool success = brw_codegen_tcs_prog(brw, current[MESA_SHADER_TESS_CTRL],
   tcp, );
   assert(success);
-- 
2.10.2

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

[Mesa-dev] [PATCH] i965: Initialize "separate" flag in VUE maps.

[Kenneth Graunke]

This was uninitialized, which resulted in weird looking printouts where
it appeared that the TCS output and TES input patch URB entries differed
in SSO/non-SSO layout.  There is no "separable" layout for both, as
they're tied together.

It should have no other actual effect.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_vue_map.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_vue_map.c 
b/src/mesa/drivers/dri/i965/brw_vue_map.c
index 4d509d3..982a31f 100644
--- a/src/mesa/drivers/dri/i965/brw_vue_map.c
+++ b/src/mesa/drivers/dri/i965/brw_vue_map.c
@@ -205,6 +205,9 @@ brw_compute_tess_vue_map(struct brw_vue_map *vue_map,
/* I don't think anything actually uses this... */
vue_map->slots_valid = vertex_slots;
 
+   /* separate isn't really meaningful, but make sure it's initialized */
+   vue_map->separate = false;
+
vertex_slots &= ~(VARYING_BIT_TESS_LEVEL_OUTER |
  VARYING_BIT_TESS_LEVEL_INNER);
 
-- 
2.10.2

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

Re: [Mesa-dev] [PATCH 15/18] i965: Validate "General Restrictions on Regioning Parameters"

[Matt Turner]

Ken reviewed all the easy patches, up to this point in the series.
Does anyone else want to review the rest?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] i965/miptree: Use intel_miptree_copy for maps

[Jason Ekstrand]

What we're really doing is copying a texture not blitting it in the sense
of glBlitFramebuffers.  Also, the intel_miptree_copy function is capable of
properly handling compressed textures which intel_miptree_blit is not.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97473
Cc: "13.0" 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 7cda019..ba9b03b 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -2581,12 +2581,10 @@ intel_miptree_map_blit(struct brw_context *brw,
 * temporary buffer back out.
 */
if (!(map->mode & GL_MAP_INVALIDATE_RANGE_BIT)) {
-  if (!intel_miptree_blit(brw,
-  mt, level, slice,
-  map->x, map->y, false,
-  map->linear_mt, 0, 0,
-  0, 0, false,
-  map->w, map->h, GL_COPY)) {
+  if (!intel_miptree_copy(brw,
+  mt, level, slice, map->x, map->y,
+  map->linear_mt, 0, 0, 0, 0,
+  map->w, map->h)) {
  fprintf(stderr, "Failed to blit\n");
  goto fail;
   }
@@ -2619,12 +2617,10 @@ intel_miptree_unmap_blit(struct brw_context *brw,
intel_miptree_unmap_raw(map->linear_mt);
 
if (map->mode & GL_MAP_WRITE_BIT) {
-  bool ok = intel_miptree_blit(brw,
-   map->linear_mt, 0, 0,
-   0, 0, false,
-   mt, level, slice,
-   map->x, map->y, false,
-   map->w, map->h, GL_COPY);
+  bool ok = intel_miptree_copy(brw,
+   map->linear_mt, 0, 0, 0, 0,
+   mt, level, slice, map->x, map->y,
+   map->w, map->h);
   WARN_ONCE(!ok, "Failed to blit from linear temporary mapping");
}
 
-- 
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 1/4] i965/fs: Rename opt_copy_propagate -> opt_copy_propagation.

[Matt Turner]

Ping. This series fixes a real bug that affects multiple games.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] i965/blit: Fix the src dimension sanity check in miptree_copy

[Jason Ekstrand]

Cc: "13.0" 
---
 src/mesa/drivers/dri/i965/intel_blit.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_blit.c 
b/src/mesa/drivers/dri/i965/intel_blit.c
index 03a35ee..5f0cf74 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -421,8 +421,10 @@ intel_miptree_copy(struct brw_context *brw,
 
   assert(src_x % bw == 0);
   assert(src_y % bh == 0);
-  assert(src_width % bw == 0);
-  assert(src_height % bh == 0);
+  assert(src_width % bw == 0 ||
+ src_x + src_width == minify(src_mt->logical_width0, src_level));
+  assert(src_height % bh == 0 ||
+ src_y + src_height == minify(src_mt->logical_height0, src_level));
 
   src_x /= (int)bw;
   src_y /= (int)bh;
-- 
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] Potentially EOL ilo gallium driver

[Ilia Mirkin]

On Tue, Dec 6, 2016 at 3:00 PM, Rob Clark  wrote:
> On Tue, Dec 6, 2016 at 2:11 PM, Jason Ekstrand  wrote:
>> On Tue, Dec 6, 2016 at 8:39 AM, Rob Clark  wrote:
>>>
>>> On Tue, Dec 6, 2016 at 8:42 AM, Emil Velikov 
>>> wrote:
>>> > On 6 December 2016 at 03:16, Edward O'Callaghan
>>> >  wrote:
>>> >> This patch is to potentially remove ourself from the maintaince
>>> >> burden of the ilo driver that appears to now be essentially
>>> >> unmaintained?
>>> >>
>>> >> I am not sure of our policy here or if there are too many
>>> >> users so this patch is really only to gauge a response of
>>> >> how folks feel?
>>> >>
>>> > Surely you want to CC the core/sole developer of the driver when
>>> > considering its removal.
>>> > Maybe mailman was "nice" and hid his email in the header ;-)
>>> >
>>> > Either way adding Chia-I Wu to the list.
>>> >
>>> > -Emil
>>> > P.S. Not sure/sold how much of an actual burden the driver is, yet I
>>> > don't make serious gallium infra changes.
>>>
>>> really hasn't been a problem for me..
>>>
>>> That said, it would be nice if someday someone wired this up to use
>>> glsl_to_nir path in gallium and re-used i965's nir backend.  I think
>>> that would make ilo somewhat more interesting..
>>
>>
>> We had a bit of a chat about this on IRC and what I told Ilia there was that
>> the more interesting thing to do, if someone really wanted to do Intel on
>> gallium, would probably be to build a new driver based on ISL, blorp, the
>> i965 compiler, NIR, and genxml.  We've made a pretty good driver-building
>> toolbox.  Having an almost unmaintained driver that has it's own hand-rolled
>> and inferrior compiler, surface layout, etc. isn't doing much good.
>>
>
> yeah, reusing the other bits would be nice too, and hopefully would be
> the long term goal if someone where to spend time on this.. I guess
> I'd prefer a more incremental approach of converting parts one by one
> if I were doing it myself.  It's kind of a moot point either way until
> someone has time/motivation to spend on it.
>
> But I've no real objection to dropping ilo until then if others feel
> strongly.. it's still there in git history so it can be resurrected if
> someone wants to convert to reuse other i965 bits incrementally rather
> than starting from scratch.

As mentioned on IRC, I think the real use-case that ilo could cover
that i965/anv can't (easily) handle is acting as a gallium-nine
backend. (I know someone's working on DX9 over vulkan, but that's
hardly ready, and will never be available on gen6.)

However at this time, it's not sufficiently functional to handle
gallium-nine, so I don't see any serious downside to dropping it.

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

[Mesa-dev] [PATCH] radeonsi: fix an off-by-one error in the bounds check for max_vertices

[Nicolai Hähnle]

From: Nicolai Hähnle 

The spec actually says that calling EmitStreamVertex is undefined when
you exceed max_vertices. But we do need to avoid trampling over memory
outside the GSVS ring.

Cc: mesa-sta...@lists.freedesktop.org
--
One more thing I noticed on top of all the other GS changes...
---
 src/gallium/drivers/radeonsi/si_shader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index dee2a17..749823d 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -5181,21 +5181,21 @@ static void si_llvm_emit_vertex(
   "");
 
/* If this thread has already emitted the declared maximum number of
 * vertices, skip the write: excessive vertex emissions are not
 * supposed to have any effect.
 *
 * If the shader has no writes to memory, kill it instead. This skips
 * further memory loads and may allow LLVM to skip to the end
 * altogether.
 */
-   can_emit = LLVMBuildICmp(gallivm->builder, LLVMIntULE, gs_next_vertex,
+   can_emit = LLVMBuildICmp(gallivm->builder, LLVMIntULT, gs_next_vertex,
 lp_build_const_int32(gallivm,
  
shader->selector->gs_max_out_vertices), "");
 
bool use_kill = !info->writes_memory;
if (use_kill) {
kill = lp_build_select(_base->base, can_emit,
   lp_build_const_float(gallivm, 1.0f),
   lp_build_const_float(gallivm, -1.0f));
 
lp_build_intrinsic(gallivm->builder, "llvm.AMDGPU.kill",
-- 
2.7.4

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

Re: [Mesa-dev] Potentially EOL ilo gallium driver

[Rob Clark]

On Tue, Dec 6, 2016 at 2:11 PM, Jason Ekstrand  wrote:
> On Tue, Dec 6, 2016 at 8:39 AM, Rob Clark  wrote:
>>
>> On Tue, Dec 6, 2016 at 8:42 AM, Emil Velikov 
>> wrote:
>> > On 6 December 2016 at 03:16, Edward O'Callaghan
>> >  wrote:
>> >> This patch is to potentially remove ourself from the maintaince
>> >> burden of the ilo driver that appears to now be essentially
>> >> unmaintained?
>> >>
>> >> I am not sure of our policy here or if there are too many
>> >> users so this patch is really only to gauge a response of
>> >> how folks feel?
>> >>
>> > Surely you want to CC the core/sole developer of the driver when
>> > considering its removal.
>> > Maybe mailman was "nice" and hid his email in the header ;-)
>> >
>> > Either way adding Chia-I Wu to the list.
>> >
>> > -Emil
>> > P.S. Not sure/sold how much of an actual burden the driver is, yet I
>> > don't make serious gallium infra changes.
>>
>> really hasn't been a problem for me..
>>
>> That said, it would be nice if someday someone wired this up to use
>> glsl_to_nir path in gallium and re-used i965's nir backend.  I think
>> that would make ilo somewhat more interesting..
>
>
> We had a bit of a chat about this on IRC and what I told Ilia there was that
> the more interesting thing to do, if someone really wanted to do Intel on
> gallium, would probably be to build a new driver based on ISL, blorp, the
> i965 compiler, NIR, and genxml.  We've made a pretty good driver-building
> toolbox.  Having an almost unmaintained driver that has it's own hand-rolled
> and inferrior compiler, surface layout, etc. isn't doing much good.
>

yeah, reusing the other bits would be nice too, and hopefully would be
the long term goal if someone where to spend time on this.. I guess
I'd prefer a more incremental approach of converting parts one by one
if I were doing it myself.  It's kind of a moot point either way until
someone has time/motivation to spend on it.

But I've no real objection to dropping ilo until then if others feel
strongly.. it's still there in git history so it can be resurrected if
someone wants to convert to reuse other i965 bits incrementally rather
than starting from scratch.

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

[Mesa-dev] [PATCH 2/2] i965: Add i965 plumbing for ARB_post_depth_coverage for i965 (gen9+).

[Plamena Manolova]

This extension allows the fragment shader to control whether values in
gl_SampleMaskIn[] reflect the coverage after application of the early
depth and stencil tests.

Signed-off-by: Plamena Manolova 
---
 docs/features.txt|  2 +-
 docs/relnotes/13.1.0.html|  1 +
 src/mesa/drivers/dri/i965/brw_compiler.h |  1 +
 src/mesa/drivers/dri/i965/brw_fs.cpp |  1 +
 src/mesa/drivers/dri/i965/gen8_ps_state.c| 13 ++---
 src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
 6 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index 2c6691f..c27d521 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -287,7 +287,7 @@ Khronos, ARB, and OES extensions that are not part of any 
OpenGL or OpenGL ES ve
   GL_ARB_indirect_parametersDONE (nvc0, radeonsi)
   GL_ARB_parallel_shader_compilenot started, but 
Chia-I Wu did some related work in 2014
   GL_ARB_pipeline_statistics_query  DONE (i965, nvc0, 
radeonsi, softpipe, swr)
-  GL_ARB_post_depth_coveragenot started
+  GL_ARB_post_depth_coverageDONE (i965)
   GL_ARB_robustness_isolation   not started
   GL_ARB_sample_locations   not started
   GL_ARB_seamless_cubemap_per_texture   DONE (i965, nvc0, 
radeonsi, r600, softpipe, swr)
diff --git a/docs/relnotes/13.1.0.html b/docs/relnotes/13.1.0.html
index 4f76cc2..5b8b016 100644
--- a/docs/relnotes/13.1.0.html
+++ b/docs/relnotes/13.1.0.html
@@ -44,6 +44,7 @@ Note: some of the new features are only available with 
certain drivers.
 
 
 
+GL_ARB_post_depth_coverage on i965/gen9+
 GL_NV_image_formats on any driver supporting 
GL_ARB_shader_image_load_store (i965, nvc0, radeonsi, softpipe)
 
 
diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index 65a7478..410641f 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -397,6 +397,7 @@ struct brw_wm_prog_data {
bool computed_stencil;
 
bool early_fragment_tests;
+   bool post_depth_coverage;
bool dispatch_8;
bool dispatch_16;
bool dual_src_blend;
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index c218f56..ce0c07e 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -6454,6 +6454,7 @@ brw_compile_fs(const struct brw_compiler *compiler, void 
*log_data,
shader->info->outputs_read);
 
prog_data->early_fragment_tests = shader->info->fs.early_fragment_tests;
+   prog_data->post_depth_coverage = shader->info->fs.post_depth_coverage;
 
prog_data->barycentric_interp_modes =
   brw_compute_barycentric_interp_modes(compiler->devinfo, shader);
diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c 
b/src/mesa/drivers/dri/i965/gen8_ps_state.c
index a4eb962..33ef023 100644
--- a/src/mesa/drivers/dri/i965/gen8_ps_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_ps_state.c
@@ -53,10 +53,17 @@ gen8_upload_ps_extra(struct brw_context *brw,
   dw1 |= GEN8_PSX_SHADER_IS_PER_SAMPLE;
 
if (prog_data->uses_sample_mask) {
-  if (brw->gen >= 9)
- dw1 |= BRW_PSICMS_INNER << GEN9_PSX_SHADER_NORMAL_COVERAGE_MASK_SHIFT;
-  else
+  if (brw->gen >= 9) {
+ if (prog_data->post_depth_coverage) {
+dw1 |= BRW_PCICMS_DEPTH << 
GEN9_PSX_SHADER_NORMAL_COVERAGE_MASK_SHIFT;
+ }
+ else {
+dw1 |= BRW_PSICMS_INNER << 
GEN9_PSX_SHADER_NORMAL_COVERAGE_MASK_SHIFT;
+ }
+  }
+  else {
  dw1 |= GEN8_PSX_SHADER_USES_INPUT_COVERAGE_MASK;
+  }
}
 
if (prog_data->uses_omask)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 66079b5..19f4684 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -415,6 +415,7 @@ intelInitExtensions(struct gl_context *ctx)
   ctx->Extensions.KHR_texture_compression_astc_ldr = true;
   ctx->Extensions.KHR_texture_compression_astc_sliced_3d = true;
   ctx->Extensions.MESA_shader_framebuffer_fetch = true;
+  ctx->Extensions.ARB_post_depth_coverage = true;
}
 
if (ctx->API == API_OPENGL_CORE)
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/2] mesa: Add GL and GLSL plumbing for ARB_post_depth_coverage for i965 (gen9+).

[Plamena Manolova]

This extension allows the fragment shader to control whether values in
gl_SampleMaskIn[] reflect the coverage after application of the early
depth and stencil tests.

Signed-off-by: Plamena Manolova 
---
 src/compiler/glsl/ast.h  |  5 +
 src/compiler/glsl/ast_to_hir.cpp |  5 +
 src/compiler/glsl/ast_type.cpp   |  9 -
 src/compiler/glsl/glsl_parser.yy | 18 ++
 src/compiler/glsl/glsl_parser_extras.cpp |  4 
 src/compiler/glsl/glsl_parser_extras.h   |  4 
 src/compiler/glsl/linker.cpp |  4 
 src/compiler/shader_info.h   |  1 +
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/mtypes.h   |  2 ++
 10 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
index afe91ea..df3a744 100644
--- a/src/compiler/glsl/ast.h
+++ b/src/compiler/glsl/ast.h
@@ -605,6 +605,11 @@ struct ast_type_qualifier {
  /** \{ */
  unsigned blend_support:1; /**< Are there any blend_support_ 
qualifiers */
  /** \} */
+
+ /**
+  * Flag set if GL_ARB_post_depth_coverage layout qualifier is used.
+  */
+ unsigned post_depth_coverage:1;
   }
   /** \brief Set of flags, accessed by name. */
   q;
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index c2ce389..2434ce5 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -3632,6 +3632,11 @@ apply_layout_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
   _mesa_glsl_error(loc, state, "early_fragment_tests layout qualifier only 
"
"valid in fragment shader input layout declaration.");
}
+
+   if (qual->flags.q.post_depth_coverage) {
+  _mesa_glsl_error(loc, state, "post_depth_coverage layout qualifier only "
+   "valid in fragment shader input layout declaration.");
+   }
 }
 
 static void
diff --git a/src/compiler/glsl/ast_type.cpp b/src/compiler/glsl/ast_type.cpp
index 3431e24..aa1ae7e 100644
--- a/src/compiler/glsl/ast_type.cpp
+++ b/src/compiler/glsl/ast_type.cpp
@@ -579,6 +579,7 @@ ast_type_qualifier::validate_in_qualifier(YYLTYPE *loc,
   break;
case MESA_SHADER_FRAGMENT:
   valid_in_mask.flags.q.early_fragment_tests = 1;
+  valid_in_mask.flags.q.post_depth_coverage = 1;
   break;
case MESA_SHADER_COMPUTE:
   valid_in_mask.flags.q.local_size = 7;
@@ -633,6 +634,11 @@ ast_type_qualifier::merge_into_in_qualifier(YYLTYPE *loc,
   state->in_qualifier->flags.q.early_fragment_tests = false;
}
 
+   if (state->in_qualifier->flags.q.post_depth_coverage) {
+  state->fs_post_depth_coverage = true;
+  state->in_qualifier->flags.q.post_depth_coverage = false;
+   }
+
/* We allow the creation of multiple cs_input_layout nodes. Coherence among
 * all existing nodes is checked later, when the AST node is transformed
 * into HIR.
@@ -761,7 +767,8 @@ ast_type_qualifier::validate_flags(YYLTYPE *loc,
 bad.flags.q.point_mode ? " point_mode" : "",
 bad.flags.q.vertices ? " vertices" : "",
 bad.flags.q.subroutine ? " subroutine" : "",
-bad.flags.q.subroutine_def ? " subroutine_def" : "");
+bad.flags.q.subroutine_def ? " subroutine_def" : "",
+bad.flags.q.post_depth_coverage ? " post_depth_coverage" : 
"");
return false;
 }
 
diff --git a/src/compiler/glsl/glsl_parser.yy b/src/compiler/glsl/glsl_parser.yy
index 0c3781c..09b7e79 100644
--- a/src/compiler/glsl/glsl_parser.yy
+++ b/src/compiler/glsl/glsl_parser.yy
@@ -1392,6 +1392,24 @@ layout_qualifier_id:
 
 $$.flags.q.early_fragment_tests = 1;
  }
+
+ if (!$$.flags.i &&
+ match_layout_qualifier($1, "post_depth_coverage", state) == 0) {
+if (state->stage != MESA_SHADER_FRAGMENT) {
+   _mesa_glsl_error(& @1, state,
+"post_depth_coverage layout qualifier only "
+"valid in fragment shaders");
+}
+
+if (state->ARB_post_depth_coverage_enable) {
+   $$.flags.q.post_depth_coverage = 1;
+} else {
+   _mesa_glsl_error(& @1, state,
+"post_depth_coverage layout qualifier present, 
"
+"but the GL_ARB_post_depth_coverage extension "
+"is not enabled.");
+}
+ }
   }
 
   /* Layout qualifiers for tessellation evaluation shaders. */
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index 1e0298e..d1fc98d 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -293,6 +293,7 @@ 

Re: [Mesa-dev] [PATCH] radeonsi: fix isolines tess factor writes to control ring

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, Dec 6, 2016 at 2:45 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> Fixes piglit arb_tessellation_shader/execution/isoline{_no_tcs}.shader_test.
>
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/gallium/drivers/radeonsi/si_shader.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index 44a4dd2..271b8d0 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -2561,24 +2561,32 @@ static void si_write_tess_factors(struct 
> lp_build_tgsi_context *bld_base,
> tess_outer_index = 
> si_shader_io_get_unique_index(TGSI_SEMANTIC_TESSOUTER, 0);
>
> lds_base = tcs_out_current_patch_data_offset;
> lds_inner = LLVMBuildAdd(gallivm->builder, lds_base,
>  lp_build_const_int32(gallivm,
>   tess_inner_index * 4), 
> "");
> lds_outer = LLVMBuildAdd(gallivm->builder, lds_base,
>  lp_build_const_int32(gallivm,
>   tess_outer_index * 4), 
> "");
>
> -   for (i = 0; i < outer_comps; i++)
> -   out[i] = lds_load(bld_base, TGSI_TYPE_SIGNED, i, lds_outer);
> -   for (i = 0; i < inner_comps; i++)
> -   out[outer_comps+i] = lds_load(bld_base, TGSI_TYPE_SIGNED, i, 
> lds_inner);
> +   if (shader->key.part.tcs.epilog.prim_mode == PIPE_PRIM_LINES) {
> +   /* For isolines, the hardware expects tess factors in the
> +* reverse order from what GLSL / TGSI specify.
> +*/
> +   out[0] = lds_load(bld_base, TGSI_TYPE_SIGNED, 1, lds_outer);
> +   out[1] = lds_load(bld_base, TGSI_TYPE_SIGNED, 0, lds_outer);
> +   } else {
> +   for (i = 0; i < outer_comps; i++)
> +   out[i] = lds_load(bld_base, TGSI_TYPE_SIGNED, i, 
> lds_outer);
> +   for (i = 0; i < inner_comps; i++)
> +   out[outer_comps+i] = lds_load(bld_base, 
> TGSI_TYPE_SIGNED, i, lds_inner);
> +   }
>
> /* Convert the outputs to vectors for stores. */
> vec0 = lp_build_gather_values(gallivm, out, MIN2(stride, 4));
> vec1 = NULL;
>
> if (stride > 4)
> vec1 = lp_build_gather_values(gallivm, out+4, stride - 4);
>
> /* Get the buffer. */
> rw_buffers = LLVMGetParam(ctx->main_fn,
> --
> 2.7.4
>
> ___
> 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] Potentially EOL ilo gallium driver

[Jason Ekstrand]

On Tue, Dec 6, 2016 at 8:39 AM, Rob Clark  wrote:

> On Tue, Dec 6, 2016 at 8:42 AM, Emil Velikov 
> wrote:
> > On 6 December 2016 at 03:16, Edward O'Callaghan
> >  wrote:
> >> This patch is to potentially remove ourself from the maintaince
> >> burden of the ilo driver that appears to now be essentially
> >> unmaintained?
> >>
> >> I am not sure of our policy here or if there are too many
> >> users so this patch is really only to gauge a response of
> >> how folks feel?
> >>
> > Surely you want to CC the core/sole developer of the driver when
> > considering its removal.
> > Maybe mailman was "nice" and hid his email in the header ;-)
> >
> > Either way adding Chia-I Wu to the list.
> >
> > -Emil
> > P.S. Not sure/sold how much of an actual burden the driver is, yet I
> > don't make serious gallium infra changes.
>
> really hasn't been a problem for me..
>
> That said, it would be nice if someday someone wired this up to use
> glsl_to_nir path in gallium and re-used i965's nir backend.  I think
> that would make ilo somewhat more interesting..
>

We had a bit of a chat about this on IRC and what I told Ilia there was
that the more interesting thing to do, if someone really wanted to do Intel
on gallium, would probably be to build a new driver based on ISL, blorp,
the i965 compiler, NIR, and genxml.  We've made a pretty good
driver-building toolbox.  Having an almost unmaintained driver that has
it's own hand-rolled and inferrior compiler, surface layout, etc. isn't
doing much good.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965/blit: Remove Yf/Ys tiled check under a FIXME at can_fast_copy_blit

[Alejandro Piñeiro]

The FIXME suggest that the check should be removed.

This change helps the following test:
GL45-CTS.texture_cube_map_array.color_depth_attachments

to pass consistently on Skylake GT3e. Without this patch, on
Skylake GT3e that test has a ~76% pass rate, with some random
intel_do_flush_locked errors now and then.

It works fine on Skylake GT2, though.
---

I didn't analyze too much the code. It was more git history analysis.

When I started to work to solve that test, I remembered that there was
a time in the past that worked, so I just did a git bisect. The more
recent bad commit I found was df210f. In any case, that one just fixed
that check, as became broken with commit 0c02d7. The one that added
the check (and the FIXME) was commit 412c8c.

As the commit message says, that FIXME seems to suggest that is a
provisional change. Although I recognize that the failure is really
specific (for a Skylake model, not failing always), removing the check
gets the test pass consistently, and as far as I see, it didn't
introduce any regression.

 src/mesa/drivers/dri/i965/intel_blit.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_blit.c 
b/src/mesa/drivers/dri/i965/intel_blit.c
index 03a35ee..9f3b4d1 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -487,14 +487,6 @@ can_fast_copy_blit(struct brw_context *brw,
if (brw->gen < 9)
   return false;
 
-   /* Enable fast copy blit only if the surfaces are Yf/Ys tiled.
-* FIXME: Based on performance data, remove this condition later to
-* enable for all types of surfaces.
-*/
-   if (src_tr_mode == INTEL_MIPTREE_TRMODE_NONE &&
-   dst_tr_mode == INTEL_MIPTREE_TRMODE_NONE)
-  return false;
-
if (logic_op != GL_COPY)
   return false;
 
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH 1/2] configure: enable glx-tls by default

[Emil Velikov]

On 6 December 2016 at 14:36, Andreas Boll  wrote:
> 2016-12-05 20:02 GMT+01:00 Emil Velikov :
>> From: Emil Velikov 
>>
>> In the (not too) distant future we'd want to remove this option and
>> effectively drop the other codepath(s) we have in our dispatch.
>>
>> Linux distributions have been using --enable-glx-tls for a number of
>> years. Some/most BSD platforms still don't support this, yet this should
>> serve as an encouragement to move things forwards.
>>
>> Cc: Jean-Sébastien Pédron 
>> Cc: Jonathan Gray 
>> Cc: mesa-maintain...@lists.freedesktop.org
>> Signed-off-by: Emil Velikov 
>> ---
>> Gents, please forward to the respective lists and fellow maintainers. Be
>> that on your or brother/sister distro.
>>
>> Joining up on mesa-maintainers will be appreciated.
>> ---
>>  configure.ac | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index adca49d..52bd9a6 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -1707,7 +1707,7 @@ AC_ARG_ENABLE([glx-tls],
>>  [AS_HELP_STRING([--enable-glx-tls],
>>  [enable TLS support in GLX @<:@default=disabled@:>@])],
>
> Please update the help string to reflect the new default behavior.
>
I always forget these. Thanks Andreas !
Barring any objections I'll push this (and the 2/2 cleanup) in a couple of days.

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

Re: [Mesa-dev] [PATCH 7/7] glx: unify GLX_SGIX_pbuffer aliased declarations

[Emil Velikov]

On 6 December 2016 at 18:08, Jeremy Huddleston Sequoia
 wrote:
>
>> On Dec 6, 2016, at 06:04, Emil Velikov  wrote:
>>
>> On 5 December 2016 at 22:50, Jeremy Huddleston Sequoia
>>  wrote:
>>>
 On Dec 5, 2016, at 11:52 AM, Emil Velikov  wrote:

 From: Emil Velikov 

 No point in having an identical code in two places.

 Not to mention that the Apple one incorrectly uses GLXDrawable as pbuf
 type. This change is both API and ABI safe since the header uses the
 correct GLXPbufferSGIX and both types are a typedef of the same
 primitive XID.

 Cc: Jeremy Huddleston Sequoia 
 Signed-off-by: Emil Velikov 
>>>
>>> Reviewed-by: Jeremy Sequoia 
>>> (not tested yet, though)
>>>
>> Thanks.
>>
 ---
 Jeremy, humble poke to send any/all Macports patches to the list ;-)
>>>
>>> What patches are you referring to?  AFAIK, all the patches we have in 
>>> MacPorts are hacks that have been rejected by mesa or are things I don't 
>>> think should be in mesa due to lack of polish/hack status.  See:
>>>https://github.com/macports/macports-ports/tree/master/x11/mesa/files
>>>
>> Almost, but not quite ;-)
>>
>> - 0001-mesa-Deal-with-size-differences-between-GLuint-and-G.patch
>> Should not longer be needed with the BUILDING_MESA workaround.
>
> Thanks, I'll give that a try.
>
>> - 0002-applegl-Provide-requirements-of-_SET_DrawBuffers.patch
>> Some serious work needed.
>
> Yep.  That's why I haven't resent it.  Need time to make it better.
>
>> - 0003-glext.h-Add-missing-include-of-stddef.h-for-ptrdiff_.patch
>> Should not be needed since the header is included further up in the
>> file. Alternatively poke Khronos and upstream it.
>
> Yep, that was the result of the conversation on the list.  I filed a khronos 
> bug and don't think they've acted on it.  I'll check the status when I get 
> some time.
>
The only way I see this being an issue is by something (glcorearb.h ?)
is setting the GL_VERSION_1_5 define before including glext.h, thus
the #include  [in the #ifndef GL_VERSION_1_5 section] gets
omitted.

Then again we should get all the includes at the top or at least
outside the "extern C" guard. I'll see if we can get these sorted.

>> - no-missing-prototypes-error.patch
>> No traces of it on the list and no commit message describing why it's
>> needed :'-(
>
> https://trac.macports.org/ticket/46827
>
> IMO, this is a hack and doesn't meet the bar of upstreaming at this quality 
> level as it's not a real fix.
>
Hmm nasty indeed. Fwiw it looks like a nice candidate to address in
the toolchain.

>> - patch-include-GL-mesa_glinterop_h.diff
>> No longer needed - fixed upstream
>
> Thanks.  I'll test removing it when I get a chance.
>
>> - static-strndup.patch
>> We have WIN32(?) strndup in src/util/strndup.[ch]. Static inline into
>> include/posix_string.h alongside strnlen. Or better yet add a patch
>> for the build toolchain, thus one doesn't need to fix these in every
>> project ;-)
>
> Yeah, that's why I haven't upstreamed this.  It's not the correct fix.
>
> The build toolchain can't be patched.  It is the gcc-4.2 that shipped with 
> Xcode 3 about 10 years ago.  We try to support the Apple-provided toolchain 
> for building ports for as long as possible.  When it becomes too unwieldy, we 
> blacklist it in individual ports.  That causes a newer toolchain to be used 
> (my preferred ones being clang-3.4 or clang-3.7; clang-3.8 has some bad 
> codegen issues, so I don't trust it, and 3.9+ currently don't build on Snow 
> Leopard).
>
Thinking out loud (sort of):

If permissions to the header(s) is not an issue one can add static
inline implementations (and missing declarations ?). Alternatively
having a "cc" wrapper which always includes the local (fixed)
header(s) prior to anything else should get you going.
At the same time: not sure how many other projects depend on such
fixes, so it may be that doing this will be more work than what its
worth.

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

Re: [Mesa-dev] [PATCH] gallivm: use getHostCPUFeatures on x86/llvm-4.0+.

[Roland Scheidegger]

Ok, here is the bug:
https://llvm.org/bugs/show_bug.cgi?id=31296

Roland

Am 06.12.2016 um 18:47 schrieb Roland Scheidegger:
> Actually I've verified this quickly with llc.
> With -mattr=xop, it produces
> 
> fetch_r32_float_float:  # @fetch_r32_float_float
> .cfi_startproc
> # BB#0: # %entry
> vpermilps   $65, .LCPI0_0(%rip), %xmm0 # xmm0 = mem[1,0,0,1]
> vmovaps %xmm0, (%rdi)
> retq
> 
> which is very obviously garbage (it even managed to optimize out the
> actual load, just the constants are left...). So this is a llvm bug with
> xop indeed. I'm going to a file a bug, but in the interim I don't know
> what mesa should do - this is one reason why we didn't want to enable
> features which we didn't actually test previously (that said, if we
> don't enable them, the llvm bugs we hit will probably never get
> fixed...). We could of course force-disable xop (albeit in theory it's
> nice - we really can make use of that damn missing vector shift which
> otherwise requires avx2).
> 
> Roland
> 
> 
> Am 06.12.2016 um 17:34 schrieb Roland Scheidegger:
>> Interesting. Can you show the IR / assembly? I don't get any failures here.
>> I'm wondering if it's trying to use XOP and there's some bug there (or
>> we're relying on undefined behavior which doesn't happen to work with
>> it). Albeit since there's not actually any conversion involved in this
>> case (float 1 channel -> float 4 channel) the assembly here looks
>> trivial and I can't see how it could go wrong.
>>
>> I get (with a couple days old llvm):
>> define void @fetch_r32_float_float(<4 x float>*, i8*, i32, i32, { [2048
>> x i32], [128 x i64] }*) {
>> entry:
>>   %5 = getelementptr i8, i8* %1, i32 0
>>   %6 = bitcast i8* %5 to i32*
>>   %7 = load i32, i32* %6
>>   %8 = zext i32 %7 to i128
>>   %9 = bitcast i128 %8 to <4 x float>
>>   %10 = shufflevector <4 x float> %9, <4 x float> > float 1.00e+00, float undef, float undef>, <4 x i32> > i32 4, i32 5>
>>   store <4 x float> %10, <4 x float>* %0
>>   ret void
>> }
>>
>> fetch_r32_float_float:
>>  0: pushq   %rbp
>>  1: movq%rsp, %rbp
>>  4: movl(%rsi), %eax
>>  6: vmovq   %rax, %xmm0
>> 11: movabsq $140375561531392, %rax
>> 21: vmovaps (%rax), %xmm1
>> 25: vshufps $0, %xmm1, %xmm0, %xmm0
>> 30: vshufps $72, %xmm1, %xmm0, %xmm0
>> 35: vmovaps %xmm0, (%rdi)
>> 39: popq%rbp
>> 40: retq
>>
>> The only thing I can think of is maybe the load/zext in combination with
>> the shuffle going wrong - the shuffle combiner in llvm has a couple xop
>> cases.
>>
>> fwiw printing of the values is a bit suboptimal, the "packed" 00 00 80
>> bf value really is a float 0xbf80 and you don't see the other
>> channels at all albeit in this case there aren't any...
>>
>> Roland
>>
>> Am 06.12.2016 um 07:27 schrieb Michel Dänzer:
>>> On 06/12/16 02:39 AM, Tim Rowley wrote:
 Use llvm provided API based on cpuid rather than our own
 manually mantained list of mattr enabling/disabling.
>>>
>>> This change broke the llvmpipe unit test lp_test_format for me:
>>>
>>> Testing PIPE_FORMAT_R32_FLOAT (float) ...
>>> FAILED
>>>   Packed: 00 00 00 00
>>>   Unpacked (0,0): 1 0 0 1 obtained
>>>   0 0 0 1 expected
>>> FAILED
>>>   Packed: 00 00 80 bf
>>>   Unpacked (0,0): 1 0 0 1 obtained
>>>   -1 0 0 1 expected
>>>
>>>
>>> This is on:
>>>
>>> processor   : 0
>>> vendor_id   : AuthenticAMD
>>> cpu family  : 21
>>> model   : 48
>>> model name  : AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G
>>> stepping: 1
>>> microcode   : 0x6003106
>>> cpu MHz : 4100.000
>>> cache size  : 2048 KB
>>> physical id : 0
>>> siblings: 4
>>> core id : 0
>>> cpu cores   : 2
>>> apicid  : 16
>>> initial apicid  : 0
>>> fpu : yes
>>> fpu_exception   : yes
>>> cpuid level : 13
>>> wp  : yes
>>> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
>>> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
>>> pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid 
>>> aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 
>>> popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm 
>>> sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce 
>>> nodeid_msr tbm topoext perfctr_core perfctr_nb bpext ptsc cpb hw_pstate 
>>> vmmcall fsgsbase bmi1 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale 
>>> vmcb_clean flushbyasid decodeassists pausefilter pfthreshold overflow_recov
>>> bugs: fxsave_leak sysret_ss_attrs null_seg
>>> bogomips: 8200.42
>>> TLB size: 1536 4K pages
>>> clflush size: 64
>>> cache_alignment : 64
>>> address sizes   : 48 bits physical, 48 bits virtual
>>> power 

Re: [Mesa-dev] [PATCH 7/7] glx: unify GLX_SGIX_pbuffer aliased declarations

[Jeremy Huddleston Sequoia]

> On Dec 6, 2016, at 06:04, Emil Velikov  wrote:
> 
> On 5 December 2016 at 22:50, Jeremy Huddleston Sequoia
>  wrote:
>> 
>>> On Dec 5, 2016, at 11:52 AM, Emil Velikov  wrote:
>>> 
>>> From: Emil Velikov 
>>> 
>>> No point in having an identical code in two places.
>>> 
>>> Not to mention that the Apple one incorrectly uses GLXDrawable as pbuf
>>> type. This change is both API and ABI safe since the header uses the
>>> correct GLXPbufferSGIX and both types are a typedef of the same
>>> primitive XID.
>>> 
>>> Cc: Jeremy Huddleston Sequoia 
>>> Signed-off-by: Emil Velikov 
>> 
>> Reviewed-by: Jeremy Sequoia 
>> (not tested yet, though)
>> 
> Thanks.
> 
>>> ---
>>> Jeremy, humble poke to send any/all Macports patches to the list ;-)
>> 
>> What patches are you referring to?  AFAIK, all the patches we have in 
>> MacPorts are hacks that have been rejected by mesa or are things I don't 
>> think should be in mesa due to lack of polish/hack status.  See:
>>https://github.com/macports/macports-ports/tree/master/x11/mesa/files
>> 
> Almost, but not quite ;-)
> 
> - 0001-mesa-Deal-with-size-differences-between-GLuint-and-G.patch
> Should not longer be needed with the BUILDING_MESA workaround.

Thanks, I'll give that a try.

> - 0002-applegl-Provide-requirements-of-_SET_DrawBuffers.patch
> Some serious work needed.

Yep.  That's why I haven't resent it.  Need time to make it better.

> - 0003-glext.h-Add-missing-include-of-stddef.h-for-ptrdiff_.patch
> Should not be needed since the header is included further up in the
> file. Alternatively poke Khronos and upstream it.

Yep, that was the result of the conversation on the list.  I filed a khronos 
bug and don't think they've acted on it.  I'll check the status when I get some 
time.

> - no-missing-prototypes-error.patch
> No traces of it on the list and no commit message describing why it's
> needed :'-(

https://trac.macports.org/ticket/46827

IMO, this is a hack and doesn't meet the bar of upstreaming at this quality 
level as it's not a real fix.

> - patch-include-GL-mesa_glinterop_h.diff
> No longer needed - fixed upstream

Thanks.  I'll test removing it when I get a chance.

> - static-strndup.patch
> We have WIN32(?) strndup in src/util/strndup.[ch]. Static inline into
> include/posix_string.h alongside strnlen. Or better yet add a patch
> for the build toolchain, thus one doesn't need to fix these in every
> project ;-)

Yeah, that's why I haven't upstreamed this.  It's not the correct fix.

The build toolchain can't be patched.  It is the gcc-4.2 that shipped with 
Xcode 3 about 10 years ago.  We try to support the Apple-provided toolchain for 
building ports for as long as possible.  When it becomes too unwieldy, we 
blacklist it in individual ports.  That causes a newer toolchain to be used (my 
preferred ones being clang-3.4 or clang-3.7; clang-3.8 has some bad codegen 
issues, so I don't trust it, and 3.9+ currently don't build on Snow Leopard).

> Thanks
> Emil



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/6] nir/lower_tex: add lowering for texture gradient on shadow samplers

[Eric Anholt]

Kenneth Graunke  writes:

> [ Unknown signature status ]
> On Thursday, December 1, 2016 8:53:19 AM PST Iago Toral Quiroga wrote:
>> This is ported from the Intel lowering pass that we use with GLSL IR.
>> This takes care of lowering texture gradients on shadow samplers other
>> than cube maps. Intel hardware requires this for gen < 8.
>> ---
>>  src/compiler/nir/nir.h   |  7 +++
>>  src/compiler/nir/nir_lower_tex.c | 40 
>> 
>>  2 files changed, 47 insertions(+)
>> 
>> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>> index ed388c6..d494d5f 100644
>> --- a/src/compiler/nir/nir.h
>> +++ b/src/compiler/nir/nir.h
>> @@ -2437,6 +2437,13 @@ typedef struct nir_lower_tex_options {
>>  * If true, lower nir_texop_txd on cube maps with nir_texop_txl.
>>  */
>> bool lower_txd_cube_map;
>> +
>> +   /**
>> +* If true, lower nir_texop_txd on shadow samplers (except cube maps)
>> +* with nir_texop_txl. Notice that cube map shadow samplers are lowered
>> +* with lower_txd_cube_map.
>> +*/
>> +   bool lower_txd_shadow;
>>  } nir_lower_tex_options;
>>  
>>  bool nir_lower_tex(nir_shader *shader,
>> diff --git a/src/compiler/nir/nir_lower_tex.c 
>> b/src/compiler/nir/nir_lower_tex.c
>> index c7c3db2..d5ea509 100644
>> --- a/src/compiler/nir/nir_lower_tex.c
>> +++ b/src/compiler/nir/nir_lower_tex.c
>> @@ -556,6 +556,40 @@ lower_gradient_cube_map(nir_builder *b, nir_tex_instr 
>> *tex)
>>  }
>>  
>>  static void
>> +lower_gradient_shadow(nir_builder *b, nir_tex_instr *tex)
>> +{
>> +   assert(tex->sampler_dim != GLSL_SAMPLER_DIM_CUBE);
>> +   assert(tex->is_shadow);
>> +   assert(tex->op == nir_texop_txd);
>> +   assert(tex->dest.is_ssa);
>> +
>> +   /* Use textureSize() to get the width and height of LOD 0 */
>> +   nir_ssa_def *size = get_texture_size(b, tex);
>> +
>> +   /* Scale the gradients by width and height.  Effectively, the incoming
>> +* gradients are s'(x,y), t'(x,y), and r'(x,y) from equation 3.19 in the
>> +* GL 3.0 spec; we want u'(x,y), which is w_t * s'(x,y).
>> +*/
>> +   nir_ssa_def *dPdx = nir_fmul(b, tex->src[2].src.ssa, size);
>> +   nir_ssa_def *dPdy = nir_fmul(b, tex->src[3].src.ssa, size);
>
> NIR texture sources aren't guaranteed to be in any particular order
> (it's kind of annoying)...you should instead do:
>
> nir_ssa_def *dPdx;
> nir_ssa_def *dPdy;
>
> for (unsigned i = 0; i < tex->num_srcs; i++) {
>switch (tex->src[i].src_type) {
>case nir_tex_src_ddx:
>   dPdx = nir_fmul(b, tex->src[i].src.ssa, size);
>   break;
>case nir_tex_src_ddy:
>   dPdy = nir_fmul(b, tex->src[i].src.ssa, size);
>   break;
>default:
>   break;
>}
> }
>
> Same comment on patch two.  Maybe make a get_ddx_ddy() helper?

nir_tex_instr_src_index() helps with this.


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] [PATCH 3/3] gallivm: optimize gather a bit, by using supplied destination type

[Jose Fonseca]

On 03/12/16 16:12, srol...@vmware.com wrote:

From: Roland Scheidegger 

By using a dst_type in the the gather interface, gather has some more
knowledge about how values should be fetched.
E.g. if this is a 3x32bit fetch and dst_type is 4x32bit vector gather
will no longer do a ZExt with a 96bit scalar value to 128bit, but
just fetch the 96bit as 3x32bit vector (this is still going to be
2 loads of course, but the loads can be done directly to simd vector
that way).
Also, we can now do some try to use the right int/float type. This should
make no difference really since there's typically no domain transition
penalties for such simd loads, however it actually makes a difference
since llvm will use different shuffle lowering afterwards so the caller
can use this to trick llvm into using sane shuffle afterwards (and yes
llvm is really stupid there - nothing against using the shuffle
instruction from the correct domain, but not at the cost of doing 3 times
more shuffles, the case which actually matters is refusal to use shufps
for integer values).
Also do some attempt to avoid things which look great on paper but llvm
doesn't really handle (e.g. fetching 3-element 8 bit and 16 bit vectors
which is simply disastrous - I suspect type legalizer is to blame trying
to extend these vectors to 128bit types somehow, so fetching these with
scalars like before which is suboptimal due to the ZExt).

Remove the ability for truncation (no point, this is gather, not conversion)
as it is complex enough already.

While here also implement not just the float, but also the 64bit avx2
gathers (disabled though since based on the theoretical numbers the benefit
just isn't there at all until Skylake at least).
---
 src/gallium/auxiliary/gallivm/lp_bld_gather.c | 42 +--
 1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_gather.c 
b/src/gallium/auxiliary/gallivm/lp_bld_gather.c
index 439bbb6..1f7ba92 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_gather.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_gather.c
@@ -33,6 +33,7 @@
 #include "lp_bld_format.h"
 #include "lp_bld_gather.h"
 #include "lp_bld_swizzle.h"
+#include "lp_bld_type.h"
 #include "lp_bld_init.h"
 #include "lp_bld_intr.h"

@@ -270,17 +271,52 @@ lp_build_gather(struct gallivm_state *gallivm,

   LLVMTypeRef dst_elem_type = LLVMIntTypeInContext(gallivm->context, 
dst_width);
   LLVMTypeRef dst_vec_type = LLVMVectorType(dst_elem_type, length);
+  LLVMTypeRef gather_vec_type = dst_vec_type;
   unsigned i;
-
-  res = LLVMGetUndef(dst_vec_type);
+  boolean vec_zext = FALSE;
+  unsigned gather_width = dst_width;
+
+
+  if (src_width == 16 && dst_width == 32) {
+ LLVMTypeRef g_elem_type = LLVMIntTypeInContext(gallivm->context, 
dst_width / 2);
+ gather_vec_type = LLVMVectorType(g_elem_type, length);
+ /*
+  * Note that llvm is never able to optimize zext/insert combos
+  * directly (i.e. zero the simd reg, then place the elements into
+  * the appropriate place directly). And 16->32bit zext simd loads
+  * aren't possible (instead loading to scalar reg first).
+  * (I think this has to do with scalar/vector transition.)
+  * No idea about other archs...
+  * We could do this manually, but instead we just use a vector
+  * zext, which is simple enough (and, in fact, llvm might optimize
+  * this away).
+  * (We're not trying that with other bit widths as that might not be
+  * easier, in particular with 8 bit values at least with only sse2.)
+  */
+ vec_zext = TRUE;
+ gather_width = 16;
+  }
+  res = LLVMGetUndef(gather_vec_type);
   for (i = 0; i < length; ++i) {
  LLVMValueRef index = lp_build_const_int32(gallivm, i);
  LLVMValueRef elem;
  elem = lp_build_gather_elem(gallivm, length,
- src_width, dst_width, aligned,
+ src_width, gather_width, aligned,
  base_ptr, offsets, i, vector_justify);
  res = LLVMBuildInsertElement(gallivm->builder, res, elem, index, "");
   }
+  if (vec_zext) {
+ res = LLVMBuildZExt(gallivm->builder, res, dst_vec_type, "");
+ if (vector_justify) {
+#if PIPE_ARCH_BIG_ENDIAN
+struct lp_type dst_type;
+unsigned sv = dst_width - src_width;
+dst_type = lp_type_uint_vec(dst_width, dst_width * length);
+res = LLVMBuildShl(gallivm->builder, res,
+   lp_build_const_int_vec(gallivm, dst_type, sv), 
"");
+#endif
+ }
+  }
}

return res;



Series looks good to me.

Reviewed-by: Jose Fonseca 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [PATCH] gallivm: use getHostCPUFeatures on x86/llvm-4.0+.

[Roland Scheidegger]

Actually I've verified this quickly with llc.
With -mattr=xop, it produces

fetch_r32_float_float:  # @fetch_r32_float_float
.cfi_startproc
# BB#0: # %entry
vpermilps   $65, .LCPI0_0(%rip), %xmm0 # xmm0 = mem[1,0,0,1]
vmovaps %xmm0, (%rdi)
retq

which is very obviously garbage (it even managed to optimize out the
actual load, just the constants are left...). So this is a llvm bug with
xop indeed. I'm going to a file a bug, but in the interim I don't know
what mesa should do - this is one reason why we didn't want to enable
features which we didn't actually test previously (that said, if we
don't enable them, the llvm bugs we hit will probably never get
fixed...). We could of course force-disable xop (albeit in theory it's
nice - we really can make use of that damn missing vector shift which
otherwise requires avx2).

Roland


Am 06.12.2016 um 17:34 schrieb Roland Scheidegger:
> Interesting. Can you show the IR / assembly? I don't get any failures here.
> I'm wondering if it's trying to use XOP and there's some bug there (or
> we're relying on undefined behavior which doesn't happen to work with
> it). Albeit since there's not actually any conversion involved in this
> case (float 1 channel -> float 4 channel) the assembly here looks
> trivial and I can't see how it could go wrong.
> 
> I get (with a couple days old llvm):
> define void @fetch_r32_float_float(<4 x float>*, i8*, i32, i32, { [2048
> x i32], [128 x i64] }*) {
> entry:
>   %5 = getelementptr i8, i8* %1, i32 0
>   %6 = bitcast i8* %5 to i32*
>   %7 = load i32, i32* %6
>   %8 = zext i32 %7 to i128
>   %9 = bitcast i128 %8 to <4 x float>
>   %10 = shufflevector <4 x float> %9, <4 x float>  float 1.00e+00, float undef, float undef>, <4 x i32>  i32 4, i32 5>
>   store <4 x float> %10, <4 x float>* %0
>   ret void
> }
> 
> fetch_r32_float_float:
>  0: pushq   %rbp
>  1: movq%rsp, %rbp
>  4: movl(%rsi), %eax
>  6: vmovq   %rax, %xmm0
> 11: movabsq $140375561531392, %rax
> 21: vmovaps (%rax), %xmm1
> 25: vshufps $0, %xmm1, %xmm0, %xmm0
> 30: vshufps $72, %xmm1, %xmm0, %xmm0
> 35: vmovaps %xmm0, (%rdi)
> 39: popq%rbp
> 40: retq
> 
> The only thing I can think of is maybe the load/zext in combination with
> the shuffle going wrong - the shuffle combiner in llvm has a couple xop
> cases.
> 
> fwiw printing of the values is a bit suboptimal, the "packed" 00 00 80
> bf value really is a float 0xbf80 and you don't see the other
> channels at all albeit in this case there aren't any...
> 
> Roland
> 
> Am 06.12.2016 um 07:27 schrieb Michel Dänzer:
>> On 06/12/16 02:39 AM, Tim Rowley wrote:
>>> Use llvm provided API based on cpuid rather than our own
>>> manually mantained list of mattr enabling/disabling.
>>
>> This change broke the llvmpipe unit test lp_test_format for me:
>>
>> Testing PIPE_FORMAT_R32_FLOAT (float) ...
>> FAILED
>>   Packed: 00 00 00 00
>>   Unpacked (0,0): 1 0 0 1 obtained
>>   0 0 0 1 expected
>> FAILED
>>   Packed: 00 00 80 bf
>>   Unpacked (0,0): 1 0 0 1 obtained
>>   -1 0 0 1 expected
>>
>>
>> This is on:
>>
>> processor: 0
>> vendor_id: AuthenticAMD
>> cpu family   : 21
>> model: 48
>> model name   : AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G
>> stepping : 1
>> microcode: 0x6003106
>> cpu MHz  : 4100.000
>> cache size   : 2048 KB
>> physical id  : 0
>> siblings : 4
>> core id  : 0
>> cpu cores: 2
>> apicid   : 16
>> initial apicid   : 0
>> fpu  : yes
>> fpu_exception: yes
>> cpuid level  : 13
>> wp   : yes
>> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
>> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
>> pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid 
>> aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 
>> popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm 
>> sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce 
>> nodeid_msr tbm topoext perfctr_core perfctr_nb bpext ptsc cpb hw_pstate 
>> vmmcall fsgsbase bmi1 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale 
>> vmcb_clean flushbyasid decodeassists pausefilter pfthreshold overflow_recov
>> bugs : fxsave_leak sysret_ss_attrs null_seg
>> bogomips : 8200.42
>> TLB size : 1536 4K pages
>> clflush size : 64
>> cache_alignment  : 64
>> address sizes: 48 bits physical, 48 bits virtual
>> power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro [13]
>>
>>
>>
> 

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

Re: [Mesa-dev] Potentially EOL ilo gallium driver

[Eric Anholt]

Alex Deucher  writes:

> On Tue, Dec 6, 2016 at 8:42 AM, Emil Velikov  wrote:
>> On 6 December 2016 at 03:16, Edward O'Callaghan
>>  wrote:
>>> This patch is to potentially remove ourself from the maintaince
>>> burden of the ilo driver that appears to now be essentially
>>> unmaintained?
>>>
>>> I am not sure of our policy here or if there are too many
>>> users so this patch is really only to gauge a response of
>>> how folks feel?
>>>
>> Surely you want to CC the core/sole developer of the driver when
>> considering its removal.
>> Maybe mailman was "nice" and hid his email in the header ;-)
>>
>> Either way adding Chia-I Wu to the list.
>>
>> -Emil
>> P.S. Not sure/sold how much of an actual burden the driver is, yet I
>> don't make serious gallium infra changes.
>
> I don't know that there is that much burden.  One could argue that
> pretty much all drivers for old hw are largely unmaintained.  Consider
> the r300 or i915 on the gallium side or radeon or r200 or i915 on the
> classic mesa side.  That said, I don't do that much work in mesa so I
> defer to those that do.

I see users on #dri-devel confused by it regularly.  The driver does
come at a cost, not just to us developers.

It should have never landed, and it should be removed.


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] [PATCH 2/2] anv: image: report correct depthPicth for 3d images

[Jason Ekstrand]

On Tue, Dec 6, 2016 at 3:05 AM, Lionel Landwerlin 
wrote:

> With a 3d image of 2x2x3, vkGetImageSubresourceLayout currently reports :
> VkSubresourceLayout = { offset = 0,
> size = 160,
> rowPitch = 16,
> arrayPitch = 96,
> depthPitch = 96 }
>
> depthPitch should be 32.
> Use the newly introduce isl function to query the depth.
>
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/intel/vulkan/anv_image.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> index e60373a151..af5e3c4974 100644
> --- a/src/intel/vulkan/anv_image.c
> +++ b/src/intel/vulkan/anv_image.c
> @@ -363,7 +363,8 @@ VkResult anv_BindImageMemory(
>  }
>
>  static void
> -anv_surface_get_subresource_layout(struct anv_image *image,
> +anv_surface_get_subresource_layout(struct anv_device *device,
> +   struct anv_image *image,
> struct anv_surface *surface,
> const VkImageSubresource *subresource,
> VkSubresourceLayout *layout)
> @@ -376,32 +377,34 @@ anv_surface_get_subresource_layout(struct anv_image
> *image,
>
> layout->offset = surface->offset;
> layout->rowPitch = surface->isl.row_pitch;
> -   layout->depthPitch = isl_surf_get_array_pitch(>isl);
> +   layout->depthPitch = isl_surf_get_depth_pitch(>isl_dev,
> + >isl);
>

We want this to be 0 for lod > 0 on Broadwell and older.  Let's not lie
with a number that looks like it could be valid.


> layout->arrayPitch = isl_surf_get_array_pitch(>isl);
>

I think we want this to be 0 for 3D


> layout->size = surface->isl.size;
>  }
>
>  void anv_GetImageSubresourceLayout(
> -VkDevicedevice,
> +VkDevice_device,
>  VkImage _image,
>  const VkImageSubresource*   pSubresource,
>  VkSubresourceLayout*pLayout)
>  {
> +   ANV_FROM_HANDLE(anv_device, device, _device);
> ANV_FROM_HANDLE(anv_image, image, _image);
>
> assert(__builtin_popcount(pSubresource->aspectMask) == 1);
>
> switch (pSubresource->aspectMask) {
> case VK_IMAGE_ASPECT_COLOR_BIT:
> -  anv_surface_get_subresource_layout(image, >color_surface,
> +  anv_surface_get_subresource_layout(device, image,
> >color_surface,
>   pSubresource, pLayout);
>break;
> case VK_IMAGE_ASPECT_DEPTH_BIT:
> -  anv_surface_get_subresource_layout(image, >depth_surface,
> +  anv_surface_get_subresource_layout(device, image,
> >depth_surface,
>   pSubresource, pLayout);
>break;
> case VK_IMAGE_ASPECT_STENCIL_BIT:
> -  anv_surface_get_subresource_layout(image, >stencil_surface,
> +  anv_surface_get_subresource_layout(device, image,
> >stencil_surface,
>   pSubresource, pLayout);
>break;
> default:
> --
> 2.11.0
>
> ___
> 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 1/2] isl: introduce depth pitch query function

[Jason Ekstrand]

On Tue, Dec 6, 2016 at 3:05 AM, Lionel Landwerlin 
wrote:

> Signed-off-by: Lionel Landwerlin 
> ---
>  src/intel/Makefile.isl.am  |  10 +-
>  src/intel/isl/isl.c|  25 +++
>  src/intel/isl/isl.h|   8 +
>  src/intel/isl/tests/.gitignore |   1 +
>  .../tests/isl_surf_get_image_depth_pitch_test.c| 248
> +
>  5 files changed, 291 insertions(+), 1 deletion(-)
>  create mode 100644 src/intel/isl/tests/isl_surf_
> get_image_depth_pitch_test.c
>
> diff --git a/src/intel/Makefile.isl.am b/src/intel/Makefile.isl.am
> index 5a317f522b..eb788f4a13 100644
> --- a/src/intel/Makefile.isl.am
> +++ b/src/intel/Makefile.isl.am
> @@ -67,10 +67,18 @@ isl/isl_format_layout.c: isl/gen_format_layout.py \
>  #  Tests
>  # 
> 
>
> -check_PROGRAMS += isl/tests/isl_surf_get_image_offset_test
> +check_PROGRAMS += \
> +   isl/tests/isl_surf_get_image_depth_pitch_test \
> +   isl/tests/isl_surf_get_image_offset_test
>
>  TESTS += $(check_PROGRAMS)
>
> +isl_tests_isl_surf_get_image_depth_pitch_test_LDADD = \
> +   common/libintel_common.la \
> +   isl/libisl.la \
> +   $(top_builddir)/src/mesa/drivers/dri/i965/libi965_compiler.la \
> +   -lm
> +
>  isl_tests_isl_surf_get_image_offset_test_LDADD = \
> common/libintel_common.la \
> isl/libisl.la \
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index 82ab68dc65..8c3aed92ac 100644
> --- a/src/intel/isl/isl.c
> +++ b/src/intel/isl/isl.c
> @@ -1874,3 +1874,28 @@ isl_surf_get_depth_format(const struct isl_device
> *dev,
>return 5; /* D16_UNORM */
> }
>  }
> +
> +uint32_t
> +isl_surf_get_depth_pitch(const struct isl_device *device,
> + const struct isl_surf *surf)
> +{
> +   switch (surf->dim_layout) {
> +   case ISL_DIM_LAYOUT_GEN9_1D:
> +   case ISL_DIM_LAYOUT_GEN4_2D:
> +  return isl_surf_get_array_pitch(surf);
> +   case ISL_DIM_LAYOUT_GEN4_3D: {
> +  if (surf->tiling == ISL_TILING_LINEAR)
> + return surf->row_pitch * surf->phys_level0_sa.h;
> +
> +  struct isl_tile_info tile_info;
> +  isl_surf_get_tile_info(device, surf, _info);
> +
> +  return isl_align(surf->row_pitch * surf->phys_level0_sa.h,
> +   tile_info.phys_extent_B.width *
> +   tile_info.phys_extent_B.height);
> +  }
>

Sorry, but this still isn't correct :/  What you really want is to align it
to the surf->image_align_el.h

What is the motivation for this query?  To claim to have a useful depth
pitch is 80% a lie on Broadwell and earlier so I'd prefer to not encourage
apps with one.  At the very least, this function should take a LOD and
assert that it's 0 for GEN4_3D surfaces so that users of ISL don't think
that it returns a useful value on older hardware.


> +   default:
> +  unreachable("bad isl_dim_layout");
> +  break;
> +   }
> +}
> diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> index 07368f9bcf..3ec76fabc9 100644
> --- a/src/intel/isl/isl.h
> +++ b/src/intel/isl/isl.h
> @@ -1392,6 +1392,14 @@ isl_surf_get_array_pitch(const struct isl_surf
> *surf)
>  }
>
>  /**
> + * Pitch between depth slices, in bytes (for 2D images, this should be
> + * equivalent to isl_surf_get_array_pitch()).
> + */
> +uint32_t
> +isl_surf_get_depth_pitch(const struct isl_device *device,
> + const struct isl_surf *surf);
> +
> +/**
>   * Calculate the offset, in units of surface samples, to a subimage in the
>   * surface.
>   *
> diff --git a/src/intel/isl/tests/.gitignore b/src/intel/isl/tests/.
> gitignore
> index ba70ecfbee..e90b4a4a97 100644
> --- a/src/intel/isl/tests/.gitignore
> +++ b/src/intel/isl/tests/.gitignore
> @@ -1 +1,2 @@
> +/isl_surf_get_image_depth_pitch_test
>  /isl_surf_get_image_offset_test
> diff --git a/src/intel/isl/tests/isl_surf_get_image_depth_pitch_test.c
> b/src/intel/isl/tests/isl_surf_get_image_depth_pitch_test.c
> new file mode 100644
> index 00..725d1e2b48
> --- /dev/null
> +++ b/src/intel/isl/tests/isl_surf_get_image_depth_pitch_test.c
> @@ -0,0 +1,248 @@
> +/*
> + * Copyright 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * 

Re: [Mesa-dev] [PATCH] glsl: fix ldexp lowering if bitfield insert lowering is also requested

[Roland Scheidegger]

Oops sorry for that. Looks like I changed the type of a constant
accidentally - I probably copied that bit from the original code
instead, which might have had it wrong at that time without
consequences... Should hopefully be fixed now.

Roland

Am 06.12.2016 um 08:51 schrieb Michel Dänzer:
> On 04/12/16 01:09 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger 
>>
>> Trivial, this just resurrects the code which was there once upon a time
>> (the code can't lower instructions generated in the lowering pass there,
>> and even if it could it would probably be suboptimal).
>> This fixes piglit mesa_shader_integer_functions fs-ldexp.shader_test and
>> vs-ldexp.shader_test with llvmpipe.
> 
> ... and in exchange broke the same tests with radeonsi. :}
> 
> shader_runner: ../../../src/compiler/glsl/ir_validate.cpp:662: virtual 
> ir_visitor_status {anonymous}::ir_validate::visit_leave(ir_expression*): 
> Assertion `ir->operands[3]->type == ir->type' failed.
> 
> Thread 1 "shader_runner" received signal SIGABRT, Aborted.
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
> 58../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
> #1  0x74b9940a in __GI_abort () at abort.c:89
> #2  0x74b90e47 in __assert_fail_base (fmt=, 
> assertion=assertion@entry=0x70fe7208 "ir->operands[3]->type == ir->type", 
> file=file@entry=0x70fe6618 "../../../src/compiler/glsl/ir_validate.cpp", 
> line=line@entry=662, 
> function=function@entry=0x70fe7e00 <(anonymous 
> namespace)::ir_validate::visit_leave(ir_expression*)::__PRETTY_FUNCTION__> 
> "virtual ir_visitor_status 
> {anonymous}::ir_validate::visit_leave(ir_expression*)") at assert.c:92
> #3  0x74b90ef2 in __GI___assert_fail 
> (assertion=assertion@entry=0x70fe7208 "ir->operands[3]->type == 
> ir->type", file=file@entry=0x70fe6618 
> "../../../src/compiler/glsl/ir_validate.cpp", line=line@entry=662, 
> function=function@entry=0x70fe7e00 <(anonymous 
> namespace)::ir_validate::visit_leave(ir_expression*)::__PRETTY_FUNCTION__> 
> "virtual ir_visitor_status 
> {anonymous}::ir_validate::visit_leave(ir_expression*)") at assert.c:101
> #4  0x70a42e21 in (anonymous namespace)::ir_validate::visit_leave 
> (this=, ir=) at 
> ../../../src/compiler/glsl/ir_validate.cpp:662
> #5  0x70a3e2bb in ir_expression::accept (this=0x55958340, 
> v=0x7fffd120) at ../../../src/compiler/glsl/ir_hv_accept.cpp:141
> #6  0x70a3e2bb in ir_expression::accept (this=0x559583d0, 
> v=0x7fffd120) at ../../../src/compiler/glsl/ir_hv_accept.cpp:141
> #7  0x70a3e2bb in ir_expression::accept (this=0x559585c0, 
> v=0x7fffd120) at ../../../src/compiler/glsl/ir_hv_accept.cpp:141
> #8  0x70a3e5ef in ir_assignment::accept (this=0x5594b9f0, 
> v=0x7fffd120) at ../../../src/compiler/glsl/ir_hv_accept.cpp:309
> #9  0x70a3e11d in visit_list_elements (statement_list=true, 
> l=0x55951410, v=0x7fffd120) at 
> ../../../src/compiler/glsl/ir_hv_accept.cpp:55
> #10 ir_function_signature::accept (this=0x559513c0, v=0x7fffd120) at 
> ../../../src/compiler/glsl/ir_hv_accept.cpp:115
> #11 0x70a3e209 in visit_list_elements (statement_list=false, 
> l=0x55951348, v=0x7fffd120) at 
> ../../../src/compiler/glsl/ir_hv_accept.cpp:55
> #12 ir_function::accept (this=0x55951320, v=0x7fffd120) at 
> ../../../src/compiler/glsl/ir_hv_accept.cpp:127
> #13 0x70a3dede in visit_list_elements (v=v@entry=0x7fffd120, 
> l=l@entry=0x55953180, statement_list=statement_list@entry=true) at 
> ../../../src/compiler/glsl/ir_hv_accept.cpp:55
> #14 0x70a3dd1f in ir_hierarchical_visitor::run 
> (this=this@entry=0x7fffd120, 
> instructions=instructions@entry=0x55953180) at 
> ../../../src/compiler/glsl/ir_hierarchical_visitor.cpp:364
> #15 0x70a45c7a in validate_ir_tree 
> (instructions=instructions@entry=0x55953180) at 
> ../../../src/compiler/glsl/ir_validate.cpp:932
> #16 0x70960da9 in st_link_shader (ctx=0x559014c0, 
> prog=0x55953920) at 
> ../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:6879
> #17 0x7098cb15 in _mesa_glsl_link_shader 
> (ctx=ctx@entry=0x559014c0, prog=prog@entry=0x55953920) at 
> ../../../src/mesa/program/ir_to_mesa.cpp:3066
> #18 0x7082c60d in _mesa_link_program (ctx=0x559014c0, 
> shProg=0x55953920) at ../../../src/mesa/main/shaderapi.c:1089
> #19 0x77ac8795 in stub_glLinkProgram (program=3) at 
> /home/daenzer/src/piglit-git/piglit/tests/util/piglit-dispatch-gen.c:33005
> #20 0xce9c in link_and_use_shaders () at 
> /home/daenzer/src/piglit-git/piglit/tests/shaders/shader_runner.c:1040
> #21 0x555656fb in init_test (file=0x7fffe9ec 
> 

Re: [Mesa-dev] Potentially EOL ilo gallium driver

[Rob Clark]

On Tue, Dec 6, 2016 at 8:42 AM, Emil Velikov  wrote:
> On 6 December 2016 at 03:16, Edward O'Callaghan
>  wrote:
>> This patch is to potentially remove ourself from the maintaince
>> burden of the ilo driver that appears to now be essentially
>> unmaintained?
>>
>> I am not sure of our policy here or if there are too many
>> users so this patch is really only to gauge a response of
>> how folks feel?
>>
> Surely you want to CC the core/sole developer of the driver when
> considering its removal.
> Maybe mailman was "nice" and hid his email in the header ;-)
>
> Either way adding Chia-I Wu to the list.
>
> -Emil
> P.S. Not sure/sold how much of an actual burden the driver is, yet I
> don't make serious gallium infra changes.

really hasn't been a problem for me..

That said, it would be nice if someday someone wired this up to use
glsl_to_nir path in gallium and re-used i965's nir backend.  I think
that would make ilo somewhat more interesting..

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

Re: [Mesa-dev] [PATCH] gallivm: use getHostCPUFeatures on x86/llvm-4.0+.

[Roland Scheidegger]

Interesting. Can you show the IR / assembly? I don't get any failures here.
I'm wondering if it's trying to use XOP and there's some bug there (or
we're relying on undefined behavior which doesn't happen to work with
it). Albeit since there's not actually any conversion involved in this
case (float 1 channel -> float 4 channel) the assembly here looks
trivial and I can't see how it could go wrong.

I get (with a couple days old llvm):
define void @fetch_r32_float_float(<4 x float>*, i8*, i32, i32, { [2048
x i32], [128 x i64] }*) {
entry:
  %5 = getelementptr i8, i8* %1, i32 0
  %6 = bitcast i8* %5 to i32*
  %7 = load i32, i32* %6
  %8 = zext i32 %7 to i128
  %9 = bitcast i128 %8 to <4 x float>
  %10 = shufflevector <4 x float> %9, <4 x float> , <4 x i32> 
  store <4 x float> %10, <4 x float>* %0
  ret void
}

fetch_r32_float_float:
 0: pushq   %rbp
 1: movq%rsp, %rbp
 4: movl(%rsi), %eax
 6: vmovq   %rax, %xmm0
11: movabsq $140375561531392, %rax
21: vmovaps (%rax), %xmm1
25: vshufps $0, %xmm1, %xmm0, %xmm0
30: vshufps $72, %xmm1, %xmm0, %xmm0
35: vmovaps %xmm0, (%rdi)
39: popq%rbp
40: retq

The only thing I can think of is maybe the load/zext in combination with
the shuffle going wrong - the shuffle combiner in llvm has a couple xop
cases.

fwiw printing of the values is a bit suboptimal, the "packed" 00 00 80
bf value really is a float 0xbf80 and you don't see the other
channels at all albeit in this case there aren't any...

Roland

Am 06.12.2016 um 07:27 schrieb Michel Dänzer:
> On 06/12/16 02:39 AM, Tim Rowley wrote:
>> Use llvm provided API based on cpuid rather than our own
>> manually mantained list of mattr enabling/disabling.
> 
> This change broke the llvmpipe unit test lp_test_format for me:
> 
> Testing PIPE_FORMAT_R32_FLOAT (float) ...
> FAILED
>   Packed: 00 00 00 00
>   Unpacked (0,0): 1 0 0 1 obtained
>   0 0 0 1 expected
> FAILED
>   Packed: 00 00 80 bf
>   Unpacked (0,0): 1 0 0 1 obtained
>   -1 0 0 1 expected
> 
> 
> This is on:
> 
> processor : 0
> vendor_id : AuthenticAMD
> cpu family: 21
> model : 48
> model name: AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G
> stepping  : 1
> microcode : 0x6003106
> cpu MHz   : 4100.000
> cache size: 2048 KB
> physical id   : 0
> siblings  : 4
> core id   : 0
> cpu cores : 2
> apicid: 16
> initial apicid: 0
> fpu   : yes
> fpu_exception : yes
> cpuid level   : 13
> wp: yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
> rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf 
> eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave 
> avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 
> 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext 
> perfctr_core perfctr_nb bpext ptsc cpb hw_pstate vmmcall fsgsbase bmi1 
> xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid 
> decodeassists pausefilter pfthreshold overflow_recov
> bugs  : fxsave_leak sysret_ss_attrs null_seg
> bogomips  : 8200.42
> TLB size  : 1536 4K pages
> clflush size  : 64
> cache_alignment   : 64
> address sizes : 48 bits physical, 48 bits virtual
> power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro [13]
> 
> 
> 

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

[Mesa-dev] [PATCH v4 7/7] gallium: add pipe_screen::resource_changed callback wrappers

[Philipp Zabel]

Add resource_changed to the ddebug, rbug, and trace wrappers. Since it
is optional, there is no need to add it to noop.

Signed-off-by: Philipp Zabel 
Suggested-by: Nicolai Hähnle 
---
 src/gallium/drivers/ddebug/dd_screen.c | 10 ++
 src/gallium/drivers/rbug/rbug_screen.c | 11 +++
 src/gallium/drivers/trace/tr_screen.c  | 20 
 3 files changed, 41 insertions(+)

diff --git a/src/gallium/drivers/ddebug/dd_screen.c 
b/src/gallium/drivers/ddebug/dd_screen.c
index a0c0dd0..3e20abe 100644
--- a/src/gallium/drivers/ddebug/dd_screen.c
+++ b/src/gallium/drivers/ddebug/dd_screen.c
@@ -227,6 +227,15 @@ dd_screen_resource_from_user_memory(struct pipe_screen 
*_screen,
 }
 
 static void
+dd_screen_resource_changed(struct pipe_screen *_screen,
+   struct pipe_resource *res)
+{
+   struct pipe_screen *screen = dd_screen(_screen)->screen;
+
+   screen->resource_changed(screen, res);
+}
+
+static void
 dd_screen_resource_destroy(struct pipe_screen *_screen,
struct pipe_resource *res)
 {
@@ -385,6 +394,7 @@ ddebug_screen_create(struct pipe_screen *screen)
dscreen->base.resource_from_handle = dd_screen_resource_from_handle;
SCR_INIT(resource_from_user_memory);
dscreen->base.resource_get_handle = dd_screen_resource_get_handle;
+   dscreen->base.resource_changed = dd_screen_resource_changed;
dscreen->base.resource_destroy = dd_screen_resource_destroy;
SCR_INIT(flush_frontbuffer);
SCR_INIT(fence_reference);
diff --git a/src/gallium/drivers/rbug/rbug_screen.c 
b/src/gallium/drivers/rbug/rbug_screen.c
index 3742c10..4889366 100644
--- a/src/gallium/drivers/rbug/rbug_screen.c
+++ b/src/gallium/drivers/rbug/rbug_screen.c
@@ -191,7 +191,17 @@ rbug_screen_resource_get_handle(struct pipe_screen 
*_screen,
   resource, handle, usage);
 }
 
+static void
+rbug_screen_resource_changed(struct pipe_screen *_screen,
+ struct pipe_resource *_resource)
+{
+   struct rbug_screen *rb_screen = rbug_screen(_screen);
+   struct rbug_resource *rb_resource = rbug_resource(_resource);
+   struct pipe_screen *screen = rb_screen->screen;
+   struct pipe_resource *resource = rb_resource->resource;
 
+   return screen->resource_changed(screen, resource);
+}
 
 static void
 rbug_screen_resource_destroy(struct pipe_screen *screen,
@@ -279,6 +289,7 @@ rbug_screen_create(struct pipe_screen *screen)
rb_screen->base.resource_create = rbug_screen_resource_create;
rb_screen->base.resource_from_handle = rbug_screen_resource_from_handle;
rb_screen->base.resource_get_handle = rbug_screen_resource_get_handle;
+   rb_screen->base.resource_changed = rbug_screen_resource_changed;
rb_screen->base.resource_destroy = rbug_screen_resource_destroy;
rb_screen->base.flush_frontbuffer = rbug_screen_flush_frontbuffer;
rb_screen->base.fence_reference = rbug_screen_fence_reference;
diff --git a/src/gallium/drivers/trace/tr_screen.c 
b/src/gallium/drivers/trace/tr_screen.c
index 493725c..062e131 100644
--- a/src/gallium/drivers/trace/tr_screen.c
+++ b/src/gallium/drivers/trace/tr_screen.c
@@ -350,7 +350,26 @@ trace_screen_resource_get_handle(struct pipe_screen 
*_screen,
   resource, handle, usage);
 }
 
+static void
+trace_screen_resource_changed(struct pipe_screen *_screen,
+  struct pipe_resource *_resource)
+{
+   struct trace_screen *tr_scr = trace_screen(_screen);
+   struct trace_resource *tr_res = trace_resource(_resource);
+   struct pipe_screen *screen = tr_scr->screen;
+   struct pipe_resource *resource = tr_res->resource;
+
+   assert(resource->screen == screen);
 
+   trace_dump_call_begin("pipe_screen", "resource_changed");
+
+   trace_dump_arg(ptr, screen);
+   trace_dump_arg(ptr, resource);
+
+   screen->resource_changed(screen, resource);
+
+   trace_dump_call_end();
+}
 
 static void
 trace_screen_resource_destroy(struct pipe_screen *_screen,
@@ -513,6 +532,7 @@ trace_screen_create(struct pipe_screen *screen)
tr_scr->base.resource_create = trace_screen_resource_create;
tr_scr->base.resource_from_handle = trace_screen_resource_from_handle;
tr_scr->base.resource_get_handle = trace_screen_resource_get_handle;
+   tr_scr->base.resource_changed = trace_screen_resource_changed;
tr_scr->base.resource_destroy = trace_screen_resource_destroy;
tr_scr->base.fence_reference = trace_screen_fence_reference;
tr_scr->base.fence_finish = trace_screen_fence_finish;
-- 
2.10.2

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

[Mesa-dev] [PATCH v4 2/7] st/dri: ask the driver to update its internal copies on reimport

[Philipp Zabel]

For imported buffers that can't be used directly as a source to the
texture samplers, the pipe driver might need to create an internal
copy, for example in a different tiling layout. When buffers are
reimported they may contain new image data, so the driver internal
copies need to be recreated.

Signed-off-by: Philipp Zabel 
---
 src/gallium/state_trackers/dri/dri2.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index 9ec069b..a216e83 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1168,6 +1168,10 @@ dri2_from_planar(__DRIimage *image, int plane, void 
*loaderPrivate)
if (img == NULL)
   return NULL;
 
+   if (img->texture->screen->resource_changed)
+  img->texture->screen->resource_changed(img->texture->screen,
+ img->texture);
+
/* set this to 0 for sub images. */
img->dri_components = 0;
return img;
-- 
2.10.2

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

[Mesa-dev] [PATCH v4 4/7] etnaviv: implement resource_changed to invalidate internal resources derived from imported buffers

[Philipp Zabel]

Implement the resource_changed pipe callback to invalidate internal
resources derived from imported buffers. This is needed to update the
texture for re-imported renderables.

Signed-off-by: Philipp Zabel 
---
 src/gallium/drivers/etnaviv/etnaviv_resource.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index a8858c5..20ec8f8 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -275,6 +275,18 @@ etna_resource_create(struct pipe_screen *pscreen,
 }
 
 static void
+etna_resource_changed(struct pipe_screen *pscreen, struct pipe_resource *prsc)
+{
+   struct etna_resource *res = etna_resource(prsc);
+
+   /* Make sure texture is older than the imported renderable buffer,
+* so etna_update_sampler_source will copy the pixel data again.
+*/
+   if (res->texture)
+  etna_resource(res->texture)->seqno = res->seqno - 1;
+}
+
+static void
 etna_resource_destroy(struct pipe_screen *pscreen, struct pipe_resource *prsc)
 {
struct etna_resource *rsc = etna_resource(prsc);
@@ -436,5 +448,6 @@ etna_resource_screen_init(struct pipe_screen *pscreen)
pscreen->resource_create = etna_resource_create;
pscreen->resource_from_handle = etna_resource_from_handle;
pscreen->resource_get_handle = etna_resource_get_handle;
+   pscreen->resource_changed = etna_resource_changed;
pscreen->resource_destroy = etna_resource_destroy;
 }
-- 
2.10.2

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

[Mesa-dev] [PATCH v4 0/7] etnaviv: update derived texture resources of (re)imported buffers

[Philipp Zabel]

Hi,

to get weston / wayland_egl working on etnaviv, we need to update the texture
resources derived from imported buffers every time they are re-imported.

This patchset is based on the github-etnaviv/for_mainline_v1 branch and adds
a new pipe_screen::resource_changed callback that is called inside
dri2_from_planar and instructs the pipe driver to invalidate the internal
(texture) resources that are derived from the re-imported resource.

I've also added an updated version of the earlier GL_OES_EGL_image_external
patches that now use resource_changed to invalidate internal derived resources
when an external texture is (re-)bound, to comply with the specification.

The etnaviv implementation of resource_changed just sets the texture seqno
to the resource seqno - 1. The initial seqno of imported resources is set to 1
so that texture resources created from them are actually older and trigger the
resolve on first use.

Changes since v3:
 - Added resource_changed to ddebug, rbug, and trace wrapper drivers

regards
Philipp

Philipp Zabel (7):
  gallium: add pipe_screen::resource_changed
  st/dri: ask the driver to update its internal copies on reimport
  etnaviv: initialize seqno of imported resources
  etnaviv: implement resource_changed to invalidate internal resources
derived from imported buffers
  mesa: update external textures when (re-)binding
  st/mesa: ask pipe driver to recreate derived internal resources when
(re-)binding external textures
  gallium: add pipe_screen::resource_changed callback wrappers

 src/gallium/docs/source/screen.rst | 14 ++
 src/gallium/drivers/ddebug/dd_screen.c | 10 ++
 src/gallium/drivers/etnaviv/etnaviv_resource.c | 15 +++
 src/gallium/drivers/rbug/rbug_screen.c | 11 +++
 src/gallium/drivers/trace/tr_screen.c  | 20 
 src/gallium/include/pipe/p_screen.h|  8 
 src/gallium/state_trackers/dri/dri2.c  |  4 
 src/mesa/main/texobj.c |  5 +++--
 src/mesa/state_tracker/st_atom_texture.c   |  4 
 9 files changed, 89 insertions(+), 2 deletions(-)

-- 
2.10.2

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

[Mesa-dev] [PATCH v4 6/7] st/mesa: ask pipe driver to recreate derived internal resources when (re-)binding external textures

[Philipp Zabel]

Use the resource_changed callback to invalidate internal resources
derived from external textures when they are (re-)bound. This is needed
to comply with the requirement from the GL_OES_EGL_image_external
extension that a call to glBindTexture guarantees that all further
sampling will return values that correspond to the values in the
external texture at or after the time that glBindTexture was called.

Signed-off-by: Philipp Zabel 
---
 src/mesa/state_tracker/st_atom_texture.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index a1b1b88..32d0201 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -91,6 +91,10 @@ update_single_texture(struct st_context *st,
   stObj->prev_sRGBDecode = samp->sRGBDecode;
}
 
+   if (texObj->TargetIndex == TEXTURE_EXTERNAL_INDEX &&
+   stObj->pt->screen->resource_changed)
+ stObj->pt->screen->resource_changed(stObj->pt->screen, stObj->pt);
+
*sampler_view =
   st_get_texture_sampler_view_from_stobj(st, stObj, samp, glsl_version);
return GL_TRUE;
-- 
2.10.2

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

[Mesa-dev] [PATCH v4 1/7] gallium: add pipe_screen::resource_changed

[Philipp Zabel]

Add a hook to tell drivers that an imported resource may have changed
and they need to update their internal derived resources.

Signed-off-by: Philipp Zabel 
Reviewed-by: Roland Scheidegger 
---
 src/gallium/docs/source/screen.rst  | 14 ++
 src/gallium/include/pipe/p_screen.h |  8 
 2 files changed, 22 insertions(+)

diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index 33f233a..209b97c 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -700,6 +700,20 @@ which isn't multisampled.
 
 
 
+resource_changed
+
+
+Mark a resource as changed so derived internal resources will be recreated
+on next use.
+
+When importing external images that can't be directly used as texture sampler
+source, internal copies may have to be created that the hardware can sample
+from. When those resources are reimported, the image data may have changed, and
+the previously derived internal resources must be invalidated to avoid sampling
+from old copies.
+
+
+
 resource_destroy
 
 
diff --git a/src/gallium/include/pipe/p_screen.h 
b/src/gallium/include/pipe/p_screen.h
index 255647e..0d3e4b6 100644
--- a/src/gallium/include/pipe/p_screen.h
+++ b/src/gallium/include/pipe/p_screen.h
@@ -224,6 +224,14 @@ struct pipe_screen {
  struct winsys_handle *handle,
  unsigned usage);
 
+   /**
+* Mark the resource as changed so derived internal resources will be
+* recreated on next use.
+*
+* This is necessary when reimporting external images that can't be directly
+* used as texture sampler source, to avoid sampling from old copies.
+*/
+   void (*resource_changed)(struct pipe_screen *, struct pipe_resource *pt);
 
void (*resource_destroy)(struct pipe_screen *,
struct pipe_resource *pt);
-- 
2.10.2

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

[Mesa-dev] [PATCH v4 3/7] etnaviv: initialize seqno of imported resources

[Philipp Zabel]

Imported resources already have contents that we want to be copied to
texture resources derived from them. Set initial seqno of imported
resources to 1, just as if it had already been rendered to.

Signed-off-by: Philipp Zabel 
---
 src/gallium/drivers/etnaviv/etnaviv_resource.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index aefe65b..a8858c5 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -325,6 +325,8 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
if (!rsc->bo)
   goto fail;
 
+   rsc->seqno = 1;
+
level->width = tmpl->width0;
level->height = tmpl->height0;
 
-- 
2.10.2

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

[Mesa-dev] [PATCH v4 5/7] mesa: update external textures when (re-)binding

[Philipp Zabel]

To comply with the requirement from the GL_OES_EGL_image_external
extension that a call to glBindTexture guarantees that all further
sampling will return values that correspond to the values in the
external texture at or after the time that glBindTexture was called,
do not bail out early from mesa_BindTextures if the target is
external.
This will later allow the state tracker to instruct the pipe driver
to invalidate internal resources derived from the external texture.

Signed-off-by: Philipp Zabel 
---
 src/mesa/main/texobj.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index e5b7070..25b959d 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -1619,9 +1619,10 @@ bind_texture(struct gl_context *ctx,
assert(targetIndex < NUM_TEXTURE_TARGETS);
 
/* Check if this texture is only used by this context and is already bound.
-* If so, just return.
+* If so, just return. For GL_OES_image_external, rebinding the texture
+* always must invalidate cached resources.
 */
-   {
+   if (targetIndex != TEXTURE_EXTERNAL_INDEX) {
   bool early_out;
   mtx_lock(>Shared->Mutex);
   early_out = ((ctx->Shared->RefCount == 1)
-- 
2.10.2

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

Re: [Mesa-dev] [PATCH v3 1/6] gallium: add pipe_screen::resource_changed

[Roland Scheidegger]

Thanks for fixing docs.

Reviewed-by: Roland Scheidegger 

Am 06.12.2016 um 14:57 schrieb Philipp Zabel:
> Add a hook to tell drivers that an imported resource may have changed
> and they need to update their internal derived resources.
> 
> Signed-off-by: Philipp Zabel 
> ---
> Changes since v2:
>  - Added resource_changed paragraph to screen.rst
> ---
>  src/gallium/docs/source/screen.rst  | 14 ++
>  src/gallium/include/pipe/p_screen.h |  8 
>  2 files changed, 22 insertions(+)
> 
> diff --git a/src/gallium/docs/source/screen.rst 
> b/src/gallium/docs/source/screen.rst
> index 33f233a..209b97c 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -700,6 +700,20 @@ which isn't multisampled.
>  
>  
>  
> +resource_changed
> +
> +
> +Mark a resource as changed so derived internal resources will be recreated
> +on next use.
> +
> +When importing external images that can't be directly used as texture sampler
> +source, internal copies may have to be created that the hardware can sample
> +from. When those resources are reimported, the image data may have changed, 
> and
> +the previously derived internal resources must be invalidated to avoid 
> sampling
> +from old copies.
> +
> +
> +
>  resource_destroy
>  
>  
> diff --git a/src/gallium/include/pipe/p_screen.h 
> b/src/gallium/include/pipe/p_screen.h
> index 255647e..0d3e4b6 100644
> --- a/src/gallium/include/pipe/p_screen.h
> +++ b/src/gallium/include/pipe/p_screen.h
> @@ -224,6 +224,14 @@ struct pipe_screen {
> struct winsys_handle *handle,
> unsigned usage);
>  
> +   /**
> +* Mark the resource as changed so derived internal resources will be
> +* recreated on next use.
> +*
> +* This is necessary when reimporting external images that can't be 
> directly
> +* used as texture sampler source, to avoid sampling from old copies.
> +*/
> +   void (*resource_changed)(struct pipe_screen *, struct pipe_resource *pt);
>  
> void (*resource_destroy)(struct pipe_screen *,
>   struct pipe_resource *pt);
> 

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

Re: [Mesa-dev] [PATCH 00/27] Renderbuffer Decompression (and GBM modifiers)

[Paulo Zanoni]

2016-12-01 20:09 GMT-02:00 Ben Widawsky :
> From: Ben Widawsky 
>
> This patch series ultimately adds support within the i965 driver for
> Renderbuffer Decompression with GBM. In short, this feature reduces memory
> bandwidth by allowing the GPU to work with losslessly compressed data and 
> having
> that compression scheme understood by the display engine for decompression. 
> The
> display engine will decompress on the fly and scanout the image.
>
> Quoting from the final patch, the bandwidth savings on a SKL GT4 with a 19x10
> display running kmscube:
>
> Without compression:
> Read bandwidth: 603.91 MiB/s
> Write bandwidth: 615.28 MiB/s
>
> With compression:
> Read bandwidth: 259.34 MiB/s
> Write bandwidth: 337.83 MiB/s
>
>
> The hardware achieves this savings by maintaining an auxiliary buffer
> containing "opaque" compression information. It's opaque in the sense that the
> low level compression scheme is not needed, but, knowledge of the overall
> layout of the compressed data is required. The auxiliary buffer is created by
> the driver on behalf of the client when requested. That buffer needs to be
> passed along wherever the main image's buffer goes.
>
> The overall strategy is that the buffer/surface is created with a list of
> modifiers. The list of modifiers the hardware is capable of using will come 
> from
> a new kernel API that is aware of the hardware and general constraints. A 
> client
> will request the list of modifiers and pass it directly back in during buffer
> creation (potentially the client can prune the list, but as of now there is no
> reason to.) This new API is being developed by Kristian. I did not get far
> enough to play with that.
>
> For EGL, a similar mechanism would exist whereby when importing a buffer into
> EGL, one would provide a modifier and probably a pointer to the auxiliary data
> upon import. (Import therefore might require multiple dma-buf fds), but for 
> i965
> and Intel, this wouldn't be necessary.
>
> Here is a brief description of the series:
> 1-6 Adds support in GBM for per plane functions where necessary. This is
> required because the kernel expects the auxiliary buffer to be passed along 
> as a
> plane. It has its own offset, and stride, and the client shouldn't need to
> calculate those.
>
> 7-9 Adds support in GBM to understand modifiers. When creating a buffer or
> surface, the client is expected to pass in a list of modifiers that the driver
> will optimally choose from. As a result of this, the GBM APIs need to support
> modifiers.
>
> 10-12 Support Y-tiled modifier. Y-tiling was already a modifier exposed by the
> kernel. With the previous patches in place, it's easy to support this too.
>
> 13-26 Plumbing to support sending CCS buffers to display. Leveraging much of 
> the
> existing code for MCS buffers, these patches creating an MCS for the scanout
> buffer. The trickery here is that a single BO contains both the main surface 
> and
> the auxiliary data. Previously, auxiliary data always lived in its own BO.
>
> 27 Support CCS-modifier. Finally, the code can parse the CCS fb modifier(s) 
> and
> realize the bandwidth savings that come with it.
>
> This was tested using kmscube
> (https://github.com/bwidawsk/kmscube/tree/modifiers). The kmscube 
> implementation
> is missing support for GET_PLANE2 - which is currently being worked on by
> Kristian.
>
> Upstream plan:

First of all, I'd like to point that I haven't really been following
this feature closely, so maybe my questions are irrelevant to this
series. But still, I feel I have to poitn these things since maybe
they are relevant. Please tell me if I'm not talking about the same
thing as you are.

The main question is: where's the matching i915.ko series? Shouldn't
that be step 0 in your upstream plan?

I do recall seeing BSpec text containing "do this thing if render
decompression is enabled" and, at that time, our code wasn't
implementing those instructions. AFAIU, the Kernel didn't really had
support for render decompression, so its specific bits were just
ignored. I was assuming that whoever implemented the feature would add
all the necessary bits, especially since we didn't seem to have any
sort of "if (has_render_decompression(dev_priv))" to call. I am 100%
sure there's such an example in the Gen 9 Watermarks instructions, but
I'm sure I saw more somewhere else (Display WA page?). And reember:
missing watermarks workarounds equals flickering screens.

Is this relevant to your series? How will Mesa be able to detect that
the Kernel it's running on contains the necessary Render Decompression
checks/WAs/code it needs? How can the Kernel detect that Render
Decompression is in use and start doing the things it should do?

Thanks,
Paulo


> 1. All of the patches up through 26 should be mergeable today after review.
> 2. After 1-12 land, client support of Y-tiling should be achievable. 
> Modesetting
> driver can probably 

Re: [Mesa-dev] Potentially EOL ilo gallium driver

[Alex Deucher]

On Tue, Dec 6, 2016 at 8:42 AM, Emil Velikov  wrote:
> On 6 December 2016 at 03:16, Edward O'Callaghan
>  wrote:
>> This patch is to potentially remove ourself from the maintaince
>> burden of the ilo driver that appears to now be essentially
>> unmaintained?
>>
>> I am not sure of our policy here or if there are too many
>> users so this patch is really only to gauge a response of
>> how folks feel?
>>
> Surely you want to CC the core/sole developer of the driver when
> considering its removal.
> Maybe mailman was "nice" and hid his email in the header ;-)
>
> Either way adding Chia-I Wu to the list.
>
> -Emil
> P.S. Not sure/sold how much of an actual burden the driver is, yet I
> don't make serious gallium infra changes.

I don't know that there is that much burden.  One could argue that
pretty much all drivers for old hw are largely unmaintained.  Consider
the r300 or i915 on the gallium side or radeon or r200 or i915 on the
classic mesa side.  That said, I don't do that much work in mesa so I
defer to those that do.

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

Re: [Mesa-dev] [ANNOUNCE] mesa 12.0.5

[Marek Olšák]

Hi,

I'd like to announce that this release doesn't fix the worst GPU
hangs/freezes it has. I'm talking about all Gallium drivers here.
There was a bug recently discovered in shared code that leads to
random GPU hangs with radeonsi, but all other Gallium drivers are also
affected in "some negative way", which may include freezes. The fix
was available prior to 12.0.5, but wasn't applied due to a process
issue.

It is still the best 12.0.x release, but users and distributions
wanting better stability for non-Intel drivers should wait for 12.0.6.

Thanks,
Marek

On Mon, Dec 5, 2016 at 5:27 PM, Emil Velikov  wrote:
> Mesa 12.0.5 is now available.
>
> Note: this is the final anticipated release in the 12.0 series. Users are
> encouraged to migrate to the 13.0 series in order to obtain future fixes.
>
> In this release we have:
>
> The SWR driver builds correctly with LLVM 3.7 up-to 3.9. The i965 and radeon
> (r600, radeonsi) drivers have a number of GPU hang and rendering fixes.
>
> The GLVND GLX implementation returns the correct GLX entry points, while the
> Intel Vulkan driver advertises the api_version.
>
>
> Adam Jackson (2):
>   glx/glvnd: Don't modify the dummy slot in the dispatch table
>   glx/glvnd: Fix dispatch function names and indices
>
> Anuj Phogat (1):
>   i965: Fix GPU hang related to multiple render targets and alpha testing
>
> Emil Velikov (5):
>   docs: add release notes for 12.0.4
>   docs: add sha256 checksums for 12.0.4
>   cherry-ignore: add reverted LLVM_LIBDIR patch
>   Update version to 12.0.5
>   docs: add release notes for 12.0.5
>
> Haixia Shi (1):
>   mesa: change state query return value for RGB565
>
> Jason Ekstrand (3):
>   i965/fs/generator: Don't use the address immediate for MOV_INDIRECT
>   anv/cmd_buffer: Take a command buffer instead of a batch in two helpers
>   anv/cmd_buffer: Enable a CS stall workaround for Sky Lake gt4
>
> Kenneth Graunke (1):
>   intel: Fix pixel shader scratch space allocation on Gen9+ platforms.
>
> Marek Olšák (13):
>   gallium/radeon: fix behavior of GLSL findLSB(0)
>   gallium/radeon: make sure HTILE address is aligned properly
>   radeonsi: fix an assertion failure in 
> si_decompress_sampler_color_textures
>   gallium/radeon: unify viewport emission code
>   gallium/radeon: set VPORT_ZMIN/MAX registers correctly
>   radeonsi: fix gl_PatchVerticesIn for tessellation evaluation shader
>   radeonsi: fix a crash in imageSize for cubemap arrays
>   radeonsi: emit TA_CS_BC_BASE_ADDR on SI only if the kernel allows it
>   gallium/radeon: add support for sharing textures with DCC
> between processes
>   radeonsi: always set all blend registers
>   radeonsi: set CB_BLEND1_CONTROL.ENABLE for dual source blending
>   radeonsi: disable RB+ blend optimizations for dual source blending
>   radeonsi: silence runtime warnings with LLVM 3.9
>
> Matt Turner (1):
>   anv: Replace "abi_versions" with correct "api_version".
>
> Nanley Chery (1):
>   mesa/fbobject: Update CubeMapFace when reusing textures
>
> Steinar H. Gunderson (1):
>   Fix races during _mesa_HashWalk().
>
> Tim Rowley (3):
>   swr: [rasterizer jitter] cleanup supporting different llvm versions
>   swr: [rasterizer jitter] fix llvm-3.7 compile
>   swr: [rasterizer] add support for llvm-3.9
>
> git tag: mesa-12.0.5
>
> https://mesa.freedesktop.org/archive/12.0.5/mesa-12.0.5.tar.gz
> MD5:  2f9f7b1618f8edb768aade894f997139  mesa-12.0.5.tar.gz
> SHA1: 4438ae977027f9dc23866c85660263adccb9f386  mesa-12.0.5.tar.gz
> SHA256: 44d08a27d98bfeacd864381189e434d98afbf451689d01f80380dc1d66450e5b
>  mesa-12.0.5.tar.gz
> PGP:  https://mesa.freedesktop.org/archive/12.0.5/mesa-12.0.5.tar.gz.sig
>
> https://mesa.freedesktop.org/archive/12.0.5/mesa-12.0.5.tar.xz
> MD5:  7012526b35e589fd3acf7e07939e5915  mesa-12.0.5.tar.xz
> SHA1: 383e876d8e3a14d5eb7e3c2b236254844b297ba6  mesa-12.0.5.tar.xz
> SHA256: 2b0a972d8282860a11291c09c3ef01ac45171405951eb21a83c45ed2b4321924
>  mesa-12.0.5.tar.xz
> PGP:  https://mesa.freedesktop.org/archive/12.0.5/mesa-12.0.5.tar.xz.sig
> ___
> 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 1/2] configure: enable glx-tls by default

[Andreas Boll]

2016-12-05 20:02 GMT+01:00 Emil Velikov :
> From: Emil Velikov 
>
> In the (not too) distant future we'd want to remove this option and
> effectively drop the other codepath(s) we have in our dispatch.
>
> Linux distributions have been using --enable-glx-tls for a number of
> years. Some/most BSD platforms still don't support this, yet this should
> serve as an encouragement to move things forwards.
>
> Cc: Jean-Sébastien Pédron 
> Cc: Jonathan Gray 
> Cc: mesa-maintain...@lists.freedesktop.org
> Signed-off-by: Emil Velikov 
> ---
> Gents, please forward to the respective lists and fellow maintainers. Be
> that on your or brother/sister distro.
>
> Joining up on mesa-maintainers will be appreciated.
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index adca49d..52bd9a6 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1707,7 +1707,7 @@ AC_ARG_ENABLE([glx-tls],
>  [AS_HELP_STRING([--enable-glx-tls],
>  [enable TLS support in GLX @<:@default=disabled@:>@])],

Please update the help string to reflect the new default behavior.

With that fixed:

Reviewed-by: Andreas Boll 

>  [GLX_USE_TLS="$enableval"],
> -[GLX_USE_TLS=no])
> +[GLX_USE_TLS=yes])
>  AC_SUBST(GLX_TLS, ${GLX_USE_TLS})
>
>  AS_IF([test "x$GLX_USE_TLS" = xyes -a "x$ax_pthread_ok" = xyes],
> --
> 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

Re: [Mesa-dev] [PATCH] EGL/android: Enhance pbuffer implementation

[Liu, Zhiquan]

I upload v2 version, please review.
https://patchwork.freedesktop.org/patch/125787/

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

Re: [Mesa-dev] [PATCH v2 1/6] gallium: add pipe_screen::resource_changed

[Nicolai Hähnle]

On 05.12.2016 16:49, Philipp Zabel wrote:

Add a hook to tell drivers that an imported resource may have changed
and they need to update their internal derived resources.


You should probably add this to the various wrapper drivers, like trace, 
ddebug, etc.


Nicolai


Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Clarified intended of pipe_screen::resource_changed
---
 src/gallium/include/pipe/p_screen.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/gallium/include/pipe/p_screen.h 
b/src/gallium/include/pipe/p_screen.h
index 255647e..0d3e4b6 100644
--- a/src/gallium/include/pipe/p_screen.h
+++ b/src/gallium/include/pipe/p_screen.h
@@ -224,6 +224,14 @@ struct pipe_screen {
  struct winsys_handle *handle,
  unsigned usage);

+   /**
+* Mark the resource as changed so derived internal resources will be
+* recreated on next use.
+*
+* This is necessary when reimporting external images that can't be directly
+* used as texture sampler source, to avoid sampling from old copies.
+*/
+   void (*resource_changed)(struct pipe_screen *, struct pipe_resource *pt);

void (*resource_destroy)(struct pipe_screen *,
struct pipe_resource *pt);


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

Re: [Mesa-dev] [PATCH 7/7] glx: unify GLX_SGIX_pbuffer aliased declarations

[Emil Velikov]

On 5 December 2016 at 22:50, Jeremy Huddleston Sequoia
 wrote:
>
>> On Dec 5, 2016, at 11:52 AM, Emil Velikov  wrote:
>>
>> From: Emil Velikov 
>>
>> No point in having an identical code in two places.
>>
>> Not to mention that the Apple one incorrectly uses GLXDrawable as pbuf
>> type. This change is both API and ABI safe since the header uses the
>> correct GLXPbufferSGIX and both types are a typedef of the same
>> primitive XID.
>>
>> Cc: Jeremy Huddleston Sequoia 
>> Signed-off-by: Emil Velikov 
>
> Reviewed-by: Jeremy Sequoia 
> (not tested yet, though)
>
Thanks.

>> ---
>> Jeremy, humble poke to send any/all Macports patches to the list ;-)
>
> What patches are you referring to?  AFAIK, all the patches we have in 
> MacPorts are hacks that have been rejected by mesa or are things I don't 
> think should be in mesa due to lack of polish/hack status.  See:
> https://github.com/macports/macports-ports/tree/master/x11/mesa/files
>
Almost, but not quite ;-)

 - 0001-mesa-Deal-with-size-differences-between-GLuint-and-G.patch
Should not longer be needed with the BUILDING_MESA workaround.
 - 0002-applegl-Provide-requirements-of-_SET_DrawBuffers.patch
Some serious work needed.
 - 0003-glext.h-Add-missing-include-of-stddef.h-for-ptrdiff_.patch
Should not be needed since the header is included further up in the
file. Alternatively poke Khronos and upstream it.
 - no-missing-prototypes-error.patch
No traces of it on the list and no commit message describing why it's
needed :'-(
 - patch-include-GL-mesa_glinterop_h.diff
No longer needed - fixed upstream
 - static-strndup.patch
We have WIN32(?) strndup in src/util/strndup.[ch]. Static inline into
include/posix_string.h alongside strnlen. Or better yet add a patch
for the build toolchain, thus one doesn't need to fix these in every
project ;-)

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

[Mesa-dev] [PATCH v3 2/6] st/dri: ask the driver to update its internal copies on reimport

[Philipp Zabel]

For imported buffers that can't be used directly as a source to the
texture samplers, the pipe driver might need to create an internal
copy, for example in a different tiling layout. When buffers are
reimported they may contain new image data, so the driver internal
copies need to be recreated.

Signed-off-by: Philipp Zabel 
---
 src/gallium/state_trackers/dri/dri2.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index 9ec069b..a216e83 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1168,6 +1168,10 @@ dri2_from_planar(__DRIimage *image, int plane, void 
*loaderPrivate)
if (img == NULL)
   return NULL;
 
+   if (img->texture->screen->resource_changed)
+  img->texture->screen->resource_changed(img->texture->screen,
+ img->texture);
+
/* set this to 0 for sub images. */
img->dri_components = 0;
return img;
-- 
2.10.2

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

[Mesa-dev] [PATCH v3 6/6] st/mesa: ask pipe driver to recreate derived internal resources when (re-)binding external textures

[Philipp Zabel]

Use the resource_changed callback to invalidate internal resources
derived from external textures when they are (re-)bound. This is needed
to comply with the requirement from the GL_OES_EGL_image_external
extension that a call to glBindTexture guarantees that all further
sampling will return values that correspond to the values in the
external texture at or after the time that glBindTexture was called.

Signed-off-by: Philipp Zabel 
---
 src/mesa/state_tracker/st_atom_texture.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index a1b1b88..32d0201 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -91,6 +91,10 @@ update_single_texture(struct st_context *st,
   stObj->prev_sRGBDecode = samp->sRGBDecode;
}
 
+   if (texObj->TargetIndex == TEXTURE_EXTERNAL_INDEX &&
+   stObj->pt->screen->resource_changed)
+ stObj->pt->screen->resource_changed(stObj->pt->screen, stObj->pt);
+
*sampler_view =
   st_get_texture_sampler_view_from_stobj(st, stObj, samp, glsl_version);
return GL_TRUE;
-- 
2.10.2

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

[Mesa-dev] [PATCH v3 3/6] etnaviv: initialize seqno of imported resources

[Philipp Zabel]

Imported resources already have contents that we want to be copied to
texture resources derived from them. Set initial seqno of imported
resources to 1, just as if it had already been rendered to.

Signed-off-by: Philipp Zabel 
---
 src/gallium/drivers/etnaviv/etnaviv_resource.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index aefe65b..a8858c5 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -325,6 +325,8 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
if (!rsc->bo)
   goto fail;
 
+   rsc->seqno = 1;
+
level->width = tmpl->width0;
level->height = tmpl->height0;
 
-- 
2.10.2

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

[Mesa-dev] [PATCH v3 4/6] etnaviv: implement resource_changed to invalidate internal resources derived from imported buffers

[Philipp Zabel]

Implement the resource_changed pipe callback to invalidate internal
resources derived from imported buffers. This is needed to update the
texture for re-imported renderables.

Signed-off-by: Philipp Zabel 
---
 src/gallium/drivers/etnaviv/etnaviv_resource.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index a8858c5..20ec8f8 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -275,6 +275,18 @@ etna_resource_create(struct pipe_screen *pscreen,
 }
 
 static void
+etna_resource_changed(struct pipe_screen *pscreen, struct pipe_resource *prsc)
+{
+   struct etna_resource *res = etna_resource(prsc);
+
+   /* Make sure texture is older than the imported renderable buffer,
+* so etna_update_sampler_source will copy the pixel data again.
+*/
+   if (res->texture)
+  etna_resource(res->texture)->seqno = res->seqno - 1;
+}
+
+static void
 etna_resource_destroy(struct pipe_screen *pscreen, struct pipe_resource *prsc)
 {
struct etna_resource *rsc = etna_resource(prsc);
@@ -436,5 +448,6 @@ etna_resource_screen_init(struct pipe_screen *pscreen)
pscreen->resource_create = etna_resource_create;
pscreen->resource_from_handle = etna_resource_from_handle;
pscreen->resource_get_handle = etna_resource_get_handle;
+   pscreen->resource_changed = etna_resource_changed;
pscreen->resource_destroy = etna_resource_destroy;
 }
-- 
2.10.2

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

[Mesa-dev] [PATCH v3 5/6] mesa: update external textures when (re-)binding

[Philipp Zabel]

To comply with the requirement from the GL_OES_EGL_image_external
extension that a call to glBindTexture guarantees that all further
sampling will return values that correspond to the values in the
external texture at or after the time that glBindTexture was called,
do not bail out early from mesa_BindTextures if the target is
external.
This will later allow the state tracker to instruct the pipe driver
to invalidate internal resources derived from the external texture.

Signed-off-by: Philipp Zabel 
---
 src/mesa/main/texobj.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index e5b7070..25b959d 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -1619,9 +1619,10 @@ bind_texture(struct gl_context *ctx,
assert(targetIndex < NUM_TEXTURE_TARGETS);
 
/* Check if this texture is only used by this context and is already bound.
-* If so, just return.
+* If so, just return. For GL_OES_image_external, rebinding the texture
+* always must invalidate cached resources.
 */
-   {
+   if (targetIndex != TEXTURE_EXTERNAL_INDEX) {
   bool early_out;
   mtx_lock(>Shared->Mutex);
   early_out = ((ctx->Shared->RefCount == 1)
-- 
2.10.2

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

[Mesa-dev] [PATCH v3 0/6] etnaviv: update derived texture resources of (re)imported buffers

[Philipp Zabel]

Hi,

to get weston / wayland_egl working on etnaviv, we need to update the texture
resources derived from imported buffers every time they are re-imported.

This patchset is based on the github-etnaviv/for_mainline_v1 branch and adds
a new pipe_screen::resource_changed callback that is called inside
dri2_from_planar and instructs the pipe driver to invalidate the internal
(texture) resources that are derived from the re-imported resource.

I've also added an updated version of the earlier GL_OES_EGL_image_external
patches that now use resource_changed to invalidate internal derived resources
when an external texture is (re-)bound, to comply with the specification.

The etnaviv implementation of resource_changed just sets the texture seqno
to the resource seqno - 1. The initial seqno of imported resources is set to 1
so that texture resources created from them are actually older and trigger the
resolve on first use.

Changes since v2:
 - Added resource_changed paragraph to screen.rst

regards
Philipp

Philipp Zabel (6):
  gallium: add pipe_screen::resource_changed
  st/dri: ask the driver to update its internal copies on reimport
  etnaviv: initialize seqno of imported resources
  etnaviv: implement resource_changed to invalidate internal resources
derived from imported buffers
  mesa: update external textures when (re-)binding
  st/mesa: ask pipe driver to recreate derived internal resources when
(re-)binding external textures

 src/gallium/docs/source/screen.rst | 14 ++
 src/gallium/drivers/etnaviv/etnaviv_resource.c | 15 +++
 src/gallium/include/pipe/p_screen.h|  8 
 src/gallium/state_trackers/dri/dri2.c  |  4 
 src/mesa/main/texobj.c |  5 +++--
 src/mesa/state_tracker/st_atom_texture.c   |  4 
 6 files changed, 48 insertions(+), 2 deletions(-)

-- 
2.10.2

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

[Mesa-dev] [PATCH v3 1/6] gallium: add pipe_screen::resource_changed

[Philipp Zabel]

Add a hook to tell drivers that an imported resource may have changed
and they need to update their internal derived resources.

Signed-off-by: Philipp Zabel 
---
Changes since v2:
 - Added resource_changed paragraph to screen.rst
---
 src/gallium/docs/source/screen.rst  | 14 ++
 src/gallium/include/pipe/p_screen.h |  8 
 2 files changed, 22 insertions(+)

diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index 33f233a..209b97c 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -700,6 +700,20 @@ which isn't multisampled.
 
 
 
+resource_changed
+
+
+Mark a resource as changed so derived internal resources will be recreated
+on next use.
+
+When importing external images that can't be directly used as texture sampler
+source, internal copies may have to be created that the hardware can sample
+from. When those resources are reimported, the image data may have changed, and
+the previously derived internal resources must be invalidated to avoid sampling
+from old copies.
+
+
+
 resource_destroy
 
 
diff --git a/src/gallium/include/pipe/p_screen.h 
b/src/gallium/include/pipe/p_screen.h
index 255647e..0d3e4b6 100644
--- a/src/gallium/include/pipe/p_screen.h
+++ b/src/gallium/include/pipe/p_screen.h
@@ -224,6 +224,14 @@ struct pipe_screen {
  struct winsys_handle *handle,
  unsigned usage);
 
+   /**
+* Mark the resource as changed so derived internal resources will be
+* recreated on next use.
+*
+* This is necessary when reimporting external images that can't be directly
+* used as texture sampler source, to avoid sampling from old copies.
+*/
+   void (*resource_changed)(struct pipe_screen *, struct pipe_resource *pt);
 
void (*resource_destroy)(struct pipe_screen *,
struct pipe_resource *pt);
-- 
2.10.2

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

[Mesa-dev] [PATCH] radeonsi: fix isolines tess factor writes to control ring

[Nicolai Hähnle]

From: Nicolai Hähnle 

Fixes piglit arb_tessellation_shader/execution/isoline{_no_tcs}.shader_test.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/radeonsi/si_shader.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 44a4dd2..271b8d0 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2561,24 +2561,32 @@ static void si_write_tess_factors(struct 
lp_build_tgsi_context *bld_base,
tess_outer_index = 
si_shader_io_get_unique_index(TGSI_SEMANTIC_TESSOUTER, 0);
 
lds_base = tcs_out_current_patch_data_offset;
lds_inner = LLVMBuildAdd(gallivm->builder, lds_base,
 lp_build_const_int32(gallivm,
  tess_inner_index * 4), 
"");
lds_outer = LLVMBuildAdd(gallivm->builder, lds_base,
 lp_build_const_int32(gallivm,
  tess_outer_index * 4), 
"");
 
-   for (i = 0; i < outer_comps; i++)
-   out[i] = lds_load(bld_base, TGSI_TYPE_SIGNED, i, lds_outer);
-   for (i = 0; i < inner_comps; i++)
-   out[outer_comps+i] = lds_load(bld_base, TGSI_TYPE_SIGNED, i, 
lds_inner);
+   if (shader->key.part.tcs.epilog.prim_mode == PIPE_PRIM_LINES) {
+   /* For isolines, the hardware expects tess factors in the
+* reverse order from what GLSL / TGSI specify.
+*/
+   out[0] = lds_load(bld_base, TGSI_TYPE_SIGNED, 1, lds_outer);
+   out[1] = lds_load(bld_base, TGSI_TYPE_SIGNED, 0, lds_outer);
+   } else {
+   for (i = 0; i < outer_comps; i++)
+   out[i] = lds_load(bld_base, TGSI_TYPE_SIGNED, i, 
lds_outer);
+   for (i = 0; i < inner_comps; i++)
+   out[outer_comps+i] = lds_load(bld_base, 
TGSI_TYPE_SIGNED, i, lds_inner);
+   }
 
/* Convert the outputs to vectors for stores. */
vec0 = lp_build_gather_values(gallivm, out, MIN2(stride, 4));
vec1 = NULL;
 
if (stride > 4)
vec1 = lp_build_gather_values(gallivm, out+4, stride - 4);
 
/* Get the buffer. */
rw_buffers = LLVMGetParam(ctx->main_fn,
-- 
2.7.4

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

Re: [Mesa-dev] Potentially EOL ilo gallium driver

[Emil Velikov]

On 6 December 2016 at 03:16, Edward O'Callaghan
 wrote:
> This patch is to potentially remove ourself from the maintaince
> burden of the ilo driver that appears to now be essentially
> unmaintained?
>
> I am not sure of our policy here or if there are too many
> users so this patch is really only to gauge a response of
> how folks feel?
>
Surely you want to CC the core/sole developer of the driver when
considering its removal.
Maybe mailman was "nice" and hid his email in the header ;-)

Either way adding Chia-I Wu to the list.

-Emil
P.S. Not sure/sold how much of an actual burden the driver is, yet I
don't make serious gallium infra changes.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: use getHostCPUFeatures on x86/llvm-4.0+.

[Rowley, Timothy O]

Interesting.  My testing was done using piglit on an avx512 capable processor, 
where I didn’t see any regressions.

llvmpipe’s “make check” also passes for me with this change on avx2 and avx512 
machines.

Was this the only regression you saw?

-Tim

> On Dec 6, 2016, at 12:27 AM, Michel Dänzer  wrote:
> 
> On 06/12/16 02:39 AM, Tim Rowley wrote:
>> Use llvm provided API based on cpuid rather than our own
>> manually mantained list of mattr enabling/disabling.
> 
> This change broke the llvmpipe unit test lp_test_format for me:
> 
> Testing PIPE_FORMAT_R32_FLOAT (float) ...
> FAILED
>  Packed: 00 00 00 00
>  Unpacked (0,0): 1 0 0 1 obtained
>  0 0 0 1 expected
> FAILED
>  Packed: 00 00 80 bf
>  Unpacked (0,0): 1 0 0 1 obtained
>  -1 0 0 1 expected
> 
> 
> This is on:
> 
> processor : 0
> vendor_id : AuthenticAMD
> cpu family: 21
> model : 48
> model name: AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G
> stepping  : 1
> microcode : 0x6003106
> cpu MHz   : 4100.000
> cache size: 2048 KB
> physical id   : 0
> siblings  : 4
> core id   : 0
> cpu cores : 2
> apicid: 16
> initial apicid: 0
> fpu   : yes
> fpu_exception : yes
> cpuid level   : 13
> wp: yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
> rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf 
> eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave 
> avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 
> 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext 
> perfctr_core perfctr_nb bpext ptsc cpb hw_pstate vmmcall fsgsbase bmi1 
> xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid 
> decodeassists pausefilter pfthreshold overflow_recov
> bugs  : fxsave_leak sysret_ss_attrs null_seg
> bogomips  : 8200.42
> TLB size  : 1536 4K pages
> clflush size  : 64
> cache_alignment   : 64
> address sizes : 48 bits physical, 48 bits virtual
> power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro [13]
> 
> 
> 
> -- 
> 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 v2 1/2] virgl: Fix a strict-aliasing violation in the encoder

[Emil Velikov]

On 6 December 2016 at 11:30, Edward O'Callaghan
 wrote:
> As per the C spec, it is illegal to alias pointers to different
> types. This results in undefined behaviour after optimization
> passes, resulting in very subtle bugs that happen only on a
> full moon..
>
> Use a memcpy() as a well defined coercion between the double
> to uint64_t interpretations of the memory.
>
> V.2: Use static_assert() instead of assert().
>
The lowercase static_assert is a c11 feature. You want to use the all
caps version.
See commit 23d1799f7dd5f8d1e8aa9f4efa6b1a4ed45faaa0

We might want to use update the final vulkan [codebase] references, as well.

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

Re: [Mesa-dev] [Mesa-announce] Mesa 12.0.5 release candidate

[Emil Velikov]

On 6 December 2016 at 13:01, Marek Olšák  wrote:
> On Mon, Dec 5, 2016 at 4:48 PM, Emil Velikov  wrote:
>> On 2 December 2016 at 21:49, Marek Olšák  wrote:
>>> Hi Emil,
>>>
>>> 7 additional nominations for 12.0 are attached:
>>> - the CSO fix is very important
>>> - the 4th patch fixes dual-source blending on Stoney
>>> - the last one silences printf messages with LLVM 3.9.
>>>
>>> Patches 1, 5, 6 are on mesa-dev, not reviewed yet. Patch 7 is not on
>>> any list and will not be sent separately.
>>>
>> I've picked up 2, 3, 4 and 7. Adding a reference to the original
>> commit in the last one.
>>
>> The other three were omitted since neither of them has landed in master yet.
>> For the future you can save yourself time (and follow what's been
>> suggested multiple times) by listing the SHAs that you're interested.
>
> The intent was that they wouldn't land in master (in time). That's why
> I sent them to you directly, and resolved all merge conflicts *for you*.
>
Thank you for the gesture. Please send backports the normal, documented way.

> Can we do another release that includes the CSO patch and the other 2 patches?
>
If we get at least a couple other [driver] developers how are in
favour, sure thing.

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

Re: [Mesa-dev] [PATCH 1/3] cso: don't release sampler states that are bound

[Marek Olšák]

On Mon, Dec 5, 2016 at 10:05 AM, Michel Dänzer  wrote:
> On 03/12/16 05:38 AM, Marek Olšák wrote:
>> From: Marek Olšák 
>>
>> This fixes random radeonsi GPU hangs in Batman Arkham: Origins (Wine) and
>> probably many other games too.
>>
>> cso_cache deletes sampler states when the cache size is too big and doesn't
>> check which sampler states are bound, causing use-after-free in drivers.
>> Because of that, radeonsi uploaded garbage sampler states and the hardware
>> went bananas. Other drivers may have experienced similar issues.
>>
>> Cc: 13.0 12.0 
>> ---
>>  src/gallium/auxiliary/cso_cache/cso_cache.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/auxiliary/cso_cache/cso_cache.c 
>> b/src/gallium/auxiliary/cso_cache/cso_cache.c
>> index b240c93..1f3be4b 100644
>> --- a/src/gallium/auxiliary/cso_cache/cso_cache.c
>> +++ b/src/gallium/auxiliary/cso_cache/cso_cache.c
>> @@ -181,21 +181,23 @@ static inline void sanitize_cb(struct cso_hash *hash, 
>> enum cso_cache_type type,
>>--to_remove;
>> }
>>  }
>>
>>  struct cso_hash_iter
>>  cso_insert_state(struct cso_cache *sc,
>>   unsigned hash_key, enum cso_cache_type type,
>>   void *state)
>>  {
>> struct cso_hash *hash = _cso_hash_for_type(sc, type);
>> -   sanitize_hash(sc, hash, type, sc->max_size);
>> +
>> +   if (type != CSO_SAMPLER)
>> +  sanitize_hash(sc, hash, type, sc->max_size);
>>
>> return cso_hash_insert(hash, hash_key, state);
>>  }
>>
>>  struct cso_hash_iter
>>  cso_find_state(struct cso_cache *sc,
>> unsigned hash_key, enum cso_cache_type type)
>>  {
>> struct cso_hash *hash = _cso_hash_for_type(sc, type);
>>
>>
>
> If I understand correctly, this means that the maximum cache size
> effectively isn't enforced for sampler states? Wouldn't it be better
> instead to add code which prevents currently bound states from being
> deleted from here?

Not in this patch. Maybe later and if CPU profiling results show that
it matters.

Currently, if the cache size is exceeded, the GPU usually hangs. If
pruning the cache was important, most apps would hang.

Thus, I'd like to push this as-is.

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

Re: [Mesa-dev] [Mesa-announce] Mesa 12.0.5 release candidate

[Nicolai Hähnle]

On 06.12.2016 14:01, Marek Olšák wrote:

On Mon, Dec 5, 2016 at 4:48 PM, Emil Velikov  wrote:

On 2 December 2016 at 21:49, Marek Olšák  wrote:

Hi Emil,

7 additional nominations for 12.0 are attached:
- the CSO fix is very important
- the 4th patch fixes dual-source blending on Stoney
- the last one silences printf messages with LLVM 3.9.

Patches 1, 5, 6 are on mesa-dev, not reviewed yet. Patch 7 is not on
any list and will not be sent separately.


I've picked up 2, 3, 4 and 7. Adding a reference to the original
commit in the last one.

The other three were omitted since neither of them has landed in master yet.
For the future you can save yourself time (and follow what's been
suggested multiple times) by listing the SHAs that you're interested.


The intent was that they wouldn't land in master (in time). That's why
I sent them to you directly, and resolved all merge conflicts *for you*.

Can we do another release that includes the CSO patch and the other 2 patches?


I concur, that CSO fix is pretty crucial.

Nicolai


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] [Mesa-announce] Mesa 12.0.5 release candidate

[Marek Olšák]

On Mon, Dec 5, 2016 at 4:48 PM, Emil Velikov  wrote:
> On 2 December 2016 at 21:49, Marek Olšák  wrote:
>> Hi Emil,
>>
>> 7 additional nominations for 12.0 are attached:
>> - the CSO fix is very important
>> - the 4th patch fixes dual-source blending on Stoney
>> - the last one silences printf messages with LLVM 3.9.
>>
>> Patches 1, 5, 6 are on mesa-dev, not reviewed yet. Patch 7 is not on
>> any list and will not be sent separately.
>>
> I've picked up 2, 3, 4 and 7. Adding a reference to the original
> commit in the last one.
>
> The other three were omitted since neither of them has landed in master yet.
> For the future you can save yourself time (and follow what's been
> suggested multiple times) by listing the SHAs that you're interested.

The intent was that they wouldn't land in master (in time). That's why
I sent them to you directly, and resolved all merge conflicts *for you*.

Can we do another release that includes the CSO patch and the other 2 patches?

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

Re: [Mesa-dev] [PATCH v2 1/2] virgl: Fix a strict-aliasing violation in the encoder

[Eric Engestrom]

On Tuesday, 2016-12-06 22:56:54 +1100, Edward O'Callaghan wrote:
> 
> 
> On 12/06/2016 10:48 PM, Eric Engestrom wrote:
> > On Tuesday, 2016-12-06 22:30:58 +1100, Edward O'Callaghan wrote:
> >> As per the C spec, it is illegal to alias pointers to different
> >> types. This results in undefined behaviour after optimization
> >> passes, resulting in very subtle bugs that happen only on a
> >> full moon..
> >>
> >> Use a memcpy() as a well defined coercion between the double
> >> to uint64_t interpretations of the memory.
> >>
> >> V.2: Use static_assert() instead of assert().
> >>
> >> Reviewed-by: Eric Engestrom 
> >> Signed-off-by: Edward O'Callaghan 
> >> ---
> >>  src/gallium/drivers/virgl/virgl_encode.c | 8 +++-
> >>  1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/gallium/drivers/virgl/virgl_encode.c 
> >> b/src/gallium/drivers/virgl/virgl_encode.c
> >> index be72f70..58890df 100644
> >> --- a/src/gallium/drivers/virgl/virgl_encode.c
> >> +++ b/src/gallium/drivers/virgl/virgl_encode.c
> >> @@ -21,6 +21,8 @@
> >>   * USE OR OTHER DEALINGS IN THE SOFTWARE.
> >>   */
> >>  #include 
> >> +#include 
> >> +#include 
> >>  
> >>  #include "util/u_format.h"
> >>  #include "util/u_memory.h"
> >> @@ -315,12 +317,16 @@ int virgl_encode_clear(struct virgl_context *ctx,
> >>double depth, unsigned stencil)
> >>  {
> >> int i;
> >> +   uint64_t qword;
> >> +
> >> +   static_assert(sizeof(qword) == sizeof(depth), "");
> > 
> > Please fill in the string :)
> > eg.: "`depth` needs to be a 64-bit floating point type"
> 
> ACK, done locally.
> 
> You can check my branch rather than sending another version:
> 
> https://cgit.freedesktop.org/~funfunctor/mesa/log/?h=strict-aliasing-vioations
> 
> Good to go? I'll push once the svga one gets Rb'ed also.

All good on the virgl patch :)

svga is essentially the same, but you're using structs and bit-fields
I don't know, so I'll let someone else r-b it.
You wouldn't be introducing any *new* bug anyway, as the behaviour
wouldn't change (bar the static_assert).

Cheers,
  Eric

> 
> Thanks for the review.
> Kind Regards,
> Edward.
> 
> > 
> >> +   memcpy(, , sizeof(qword));
> >>  
> >> virgl_encoder_write_cmd_dword(ctx, VIRGL_CMD0(VIRGL_CCMD_CLEAR, 0, 
> >> VIRGL_OBJ_CLEAR_SIZE));
> >> virgl_encoder_write_dword(ctx->cbuf, buffers);
> >> for (i = 0; i < 4; i++)
> >>virgl_encoder_write_dword(ctx->cbuf, color->ui[i]);
> >> -   virgl_encoder_write_qword(ctx->cbuf, *(uint64_t *));
> >> +   virgl_encoder_write_qword(ctx->cbuf, qword);
> >> virgl_encoder_write_dword(ctx->cbuf, stencil);
> >> return 0;
> >>  }
> >> -- 
> >> 2.9.3
> >>
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev