Re: [Mesa-dev] [PATCH] ac/nir: set lod to 0 when it's unused

[Marek Olšák]

Ignore that. Nicolai's point is correct.

Marek

On Fri, Apr 27, 2018 at 1:51 AM, Marek Olšák  wrote:

> Reviewed-by: Marek Olšák 
>
> Marek
>
> On Thu, Apr 26, 2018 at 6:17 AM, Samuel Pitoiset <
> samuel.pitoi...@gmail.com> wrote:
>
>> Otherwise we hit an assertion in ac_build_image_opcode()
>> for ac_image_load_mip.
>>
>> Fixes: 24fb3e6aa16 ("ac/nir: use ac_build_image_opcode for image
>> intrinsics")
>> Cc: 18.1 
>> Signed-off-by: Samuel Pitoiset 
>> ---
>>  src/amd/common/ac_nir_to_llvm.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/src/amd/common/ac_nir_to_llvm.c
>> b/src/amd/common/ac_nir_to_llvm.c
>> index e4ae6ef49ad..08ee81611e3 100644
>> --- a/src/amd/common/ac_nir_to_llvm.c
>> +++ b/src/amd/common/ac_nir_to_llvm.c
>> @@ -1276,6 +1276,8 @@ static LLVMValueRef build_tex_intrinsic(struct
>> ac_nir_context *ctx,
>> args->opcode = args->level_zero ||
>>instr->sampler_dim == GLSL_SAMPLER_DIM_MS ?
>> ac_image_load : ac_image_load_mip;
>> +   if (!args->lod)
>> +   args->lod = ctx->ac.i32_0;
>> args->level_zero = false;
>> break;
>> case nir_texop_txs:
>> --
>> 2.17.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] ac/nir: set lod to 0 when it's unused

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Thu, Apr 26, 2018 at 6:17 AM, Samuel Pitoiset 
wrote:

> Otherwise we hit an assertion in ac_build_image_opcode()
> for ac_image_load_mip.
>
> Fixes: 24fb3e6aa16 ("ac/nir: use ac_build_image_opcode for image
> intrinsics")
> Cc: 18.1 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_
> llvm.c
> index e4ae6ef49ad..08ee81611e3 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1276,6 +1276,8 @@ static LLVMValueRef build_tex_intrinsic(struct
> ac_nir_context *ctx,
> args->opcode = args->level_zero ||
>instr->sampler_dim == GLSL_SAMPLER_DIM_MS ?
> ac_image_load : ac_image_load_mip;
> +   if (!args->lod)
> +   args->lod = ctx->ac.i32_0;
> args->level_zero = false;
> break;
> case nir_texop_txs:
> --
> 2.17.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

[Mesa-dev] [Bug 104928] libglvnd_1.0.0 disables amdgpu direct rendering

[bugzilla-daemon]

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

--- Comment #5 from Jose P.  ---
Just in case someone comes from Google looking for "(EE) AMDGPU(0):
eglGetDisplay() failed, followed by (EE) AMDGPU(0): glamor detected, failed to
initialize EGL.", "AMDGPU(0): 2D and 3D acceleration disabled" or "AMDGPU(0):
Direct rendering disabled": I upgraded from Ubuntu 17.10 to 18.04, and for some
reason, two nvidia packages, libnvidia-gl-390 and libnvidia-common-390, had
been installed in my system. Removing those packages fixed the problem...

-- 
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] egl/android: remove flink name support

[Tomasz Figa]

Hi Rob,
On Fri, Apr 27, 2018 at 12:43 PM Chih-Wei Huang 
wrote:

> 2018-04-27 2:19 GMT+08:00 Robert Foss :
> >
> > I've spent some time today preparing a #ifdef version of what robher
> > submitted.
> >
> > It's fine, but there is no way automatically enable the HAVE_DRM_GRALLOC
> > #define through the build tools. So a small simple patch adding the
shared
> > library dependency, and adding the -DHAVE_DRM_GRALLOC cflag is needed.

> I can add BOARD_USES_DRM_GRALLOC=true
> (like BOARD_USES_DRM_HWCOMPOSER=true)
> in our BoardConfig.mk.
> Then you can add these in Android.mk of mesa:

> ifeq ($(BOARD_USES_DRM_GRALLOC),true)
> LOCAL_CFLAGS += -DHAVE_DRM_GRALLOC
> endif

+1 to as Chih-Wei says for Android.mk.

For autotools or meson builds we don't need to define it at all, so no need
for any changes.

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

Re: [Mesa-dev] [PATCH 1/1] main: return 0 length when the queried program object's not linked

[Timothy Arceri]

Reviewed-by: Timothy Arceri 

It would also be nice to have a piglit test for this case. I assume mesa 
probably crashes without this patch?


On 27/04/18 11:39, James Xiong wrote:

From: "Xiong, James" 

Signed-off-by: Xiong, James 
---
  src/mesa/main/shaderapi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 44b18af..caa4254 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -837,7 +837,7 @@ get_programiv(struct gl_context *ctx, GLuint program, 
GLenum pname,
*params = shProg->BinaryRetreivableHint;
return;
 case GL_PROGRAM_BINARY_LENGTH:
-  if (ctx->Const.NumProgramBinaryFormats == 0) {
+  if (ctx->Const.NumProgramBinaryFormats == 0 || 
!shProg->data->LinkStatus) {
   *params = 0;
} else {
   _mesa_get_program_binary_length(ctx, shProg, params);


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

[Mesa-dev] [PATCH 2/2] Replace deperacated include header "cutils/log.h" to "log/log.h" from Android 8

[jenny.q.cao]

There is a compile warning from Android 8 (API version 26) from "include 
cutils/log.h"
warning: "Deprecated: don't include cutils/log.h, use either android/log.h or 
log/log.h"-W#warnings,
Change to include "log/log.h" on Android 8 or later major version to avoid this 
warning

Tests: compilation with warning clean
Signed-off-by: jenny.q.cao 
---
 src/broadcom/common/v3d_debug.h   | 4 
 src/egl/main/egllog.c | 4 
 src/intel/common/gen_debug.h  | 4 
 src/mesa/drivers/dri/i915/intel_context.h | 4 
 4 files changed, 16 insertions(+)

diff --git a/src/broadcom/common/v3d_debug.h b/src/broadcom/common/v3d_debug.h
index bdb9518548cc..75eb2718f30c 100644
--- a/src/broadcom/common/v3d_debug.h
+++ b/src/broadcom/common/v3d_debug.h
@@ -57,7 +57,11 @@ extern uint32_t V3D_DEBUG;
 
 #ifdef HAVE_ANDROID_PLATFORM
 #define LOG_TAG "BROADCOM-MESA"
+#if ANDROID_API_LEVEL >= 26
+#include 
+#else
 #include 
+#endif /* use log/log.h start from android 8 major version */
 #ifndef ALOGW
 #define ALOGW LOGW
 #endif
diff --git a/src/egl/main/egllog.c b/src/egl/main/egllog.c
index 64ff474c65c4..c223f49b0fed 100644
--- a/src/egl/main/egllog.c
+++ b/src/egl/main/egllog.c
@@ -47,7 +47,11 @@
 
 #ifdef HAVE_ANDROID_PLATFORM
 #define LOG_TAG "EGL-MAIN"
+#if ANDROID_API_LEVEL >= 26
+#include 
+#else
 #include 
+#endif /* use log/log.h start from android 8 major version */
 
 #endif /* HAVE_ANDROID_PLATFORM */
 
diff --git a/src/intel/common/gen_debug.h b/src/intel/common/gen_debug.h
index da5b5a569d19..f6c44eeb9121 100644
--- a/src/intel/common/gen_debug.h
+++ b/src/intel/common/gen_debug.h
@@ -86,7 +86,11 @@ extern uint64_t INTEL_DEBUG;
 
 #ifdef HAVE_ANDROID_PLATFORM
 #define LOG_TAG "INTEL-MESA"
+#if ANDROID_API_LEVEL >= 26
+#include 
+#else
 #include 
+#endif /* use log/log.h start from android 8 major version */
 #ifndef ALOGW
 #define ALOGW LOGW
 #endif
diff --git a/src/mesa/drivers/dri/i915/intel_context.h 
b/src/mesa/drivers/dri/i915/intel_context.h
index 5361dcf5e34e..a46ef9b94719 100644
--- a/src/mesa/drivers/dri/i915/intel_context.h
+++ b/src/mesa/drivers/dri/i915/intel_context.h
@@ -283,7 +283,11 @@ extern int INTEL_DEBUG;
 
 #ifdef HAVE_ANDROID_PLATFORM
 #define LOG_TAG "INTEL-MESA"
+#if ANDROID_API_LEVEL >= 26
+#include 
+#else
 #include 
+#endif /* use log/log.h start from android 8 major version */
 #ifndef ALOGW
 #define ALOGW LOGW
 #endif
-- 
1.9.1

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

[Mesa-dev] [PATCH 1/2] Update for fix or ignore the compile warning on android

[jenny.q.cao]

force cast the I to GLint to avoid the compile warning when type is GLenum16, in
vendor/intel/external/mesa3d-intel/src/mesa/main/get.c:3005:19: warning: 
comparison of constant -32768 with
expression of type 'GLenum16' (aka 'unsigned short') is always false 
-Wtautologicalia-constant-out-of-range-compare,

ignore the compile warning 
vendor/intel/external/mesa3d-intel/src/intel/dev/gen_device_info.c:938:43: 
warning:
field 'base' with variable sized type 'struct drm_i915_query_topology_info' not 
at the end of a struct or class
is a GNU extension -Wgnu-variable-sized-type-not-at-end,

ignore the compile warning 
vendor/intel/external/mesa3d-intel/src/intel/compiler/spirv/spirv_to_nir.c  
warning:
suggest braces around initialization of subobject -Wmissing-braces

Tests: compilation with warning clean
Signed-off-by: jenny.q.cao 
---
 src/compiler/Android.nir.mk | 3 +++
 src/intel/Android.dev.mk| 3 +++
 src/mesa/main/get.c | 2 +-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/compiler/Android.nir.mk b/src/compiler/Android.nir.mk
index 75a247a245df..59da5dbdc1ca 100644
--- a/src/compiler/Android.nir.mk
+++ b/src/compiler/Android.nir.mk
@@ -41,6 +41,9 @@ LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/gallium/include \
$(MESA_TOP)/src/gallium/auxiliary
 
+LOCAL_CFLAGS := \
+-Wno-missing-braces
+
 LOCAL_STATIC_LIBRARIES := libmesa_compiler
 
 LOCAL_MODULE := libmesa_nir
diff --git a/src/intel/Android.dev.mk b/src/intel/Android.dev.mk
index cd2ed66a1768..3011ee232ed1 100644
--- a/src/intel/Android.dev.mk
+++ b/src/intel/Android.dev.mk
@@ -33,5 +33,8 @@ LOCAL_C_INCLUDES := $(MESA_TOP)/include/drm-uapi
 
 LOCAL_SRC_FILES := $(DEV_FILES)
 
+LOCAL_CFLAGS := \
+   -Wno-gnu-variable-sized-type-not-at-end
+
 include $(MESA_COMMON_MK)
 include $(BUILD_STATIC_LIBRARY)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 90ab7ca60f8b..5f9a60b0801c 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -3002,7 +3002,7 @@ _mesa_GetFixedv(GLenum pname, GLfixed *params)
   break;
 
case TYPE_ENUM16:
-  params[0] = INT_TO_FIXED(((GLenum16 *) p)[0]);
+  params[0] = INT_TO_FIXED((GLint)(((GLenum16 *) p)[0]));
   break;
 
case TYPE_INT_N:
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Marek Olšák]

Ping. Thanks.

On Tue, Apr 24, 2018 at 3:56 PM, Marek Olšák  wrote:

> From: Marek Olšák 
>
> v2: require the previous level to be clearable for determining whether
> the last unaligned level is clearable
> ---
>  src/amd/common/ac_surface.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index a23952717e3..487f6c6431b 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -336,36 +336,52 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
> surf->u.legacy.tiling_index[level] =
> AddrSurfInfoOut->tileIndex;
>
> surf->surf_size = surf_level->offset + AddrSurfInfoOut->surfSize;
>
> /* Clear DCC fields at the beginning. */
> surf_level->dcc_offset = 0;
>
> /* The previous level's flag tells us if we can use DCC for this
> level. */
> if (AddrSurfInfoIn->flags.dccCompatible &&
> (level == 0 || AddrDccOut->subLvlCompressible)) {
> +   bool prev_level_clearable = level == 0 ||
> +   AddrDccOut->dccRamSizeAligned;
> +
> AddrDccIn->colorSurfSize = AddrSurfInfoOut->surfSize;
> AddrDccIn->tileMode = AddrSurfInfoOut->tileMode;
> AddrDccIn->tileInfo = *AddrSurfInfoOut->pTileInfo;
> AddrDccIn->tileIndex = AddrSurfInfoOut->tileIndex;
> AddrDccIn->macroModeIndex = AddrSurfInfoOut->
> macroModeIndex;
>
> ret = AddrComputeDccInfo(addrlib,
>  AddrDccIn,
>  AddrDccOut);
>
> if (ret == ADDR_OK) {
> surf_level->dcc_offset = surf->dcc_size;
> -   surf_level->dcc_fast_clear_size =
> AddrDccOut->dccFastClearSize;
> surf->num_dcc_levels = level + 1;
> surf->dcc_size = surf_level->dcc_offset +
> AddrDccOut->dccRamSize;
> surf->dcc_alignment = MAX2(surf->dcc_alignment,
> AddrDccOut->dccRamBaseAlign);
> +
> +   /* If the DCC size of a subresource (1 mip level
> or 1 slice)
> +* is not aligned, the DCC memory layout is not
> contiguous for
> +* that subresource, which means we can't use fast
> clear.
> +*
> +* We only do fast clears for whole mipmap levels.
> If we did
> +* per-slice fast clears, the same restriction
> would apply.
> +* (i.e. only compute the slice size and see if
> it's aligned)
> +*/
> +   if (AddrDccOut->dccRamSizeAligned ||
> +   (prev_level_clearable && level ==
> config->info.levels - 1))
> +   surf_level->dcc_fast_clear_size =
> AddrDccOut->dccFastClearSize;
> +   else
> +   surf_level->dcc_fast_clear_size = 0;
> }
> }
>
> /* TC-compatible HTILE. */
> if (!is_stencil &&
> AddrSurfInfoIn->flags.depth &&
> surf_level->mode == RADEON_SURF_MODE_2D &&
> level == 0) {
> AddrHtileIn->flags.tcCompatible = AddrSurfInfoIn->flags.
> tcCompatible;
> AddrHtileIn->pitch = AddrSurfInfoOut->pitch;
> --
> 2.17.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/10] DRI interface, gallium: User-specified transfer stride

[Marek Olšák]

Please ignore this series.

Marek

On Wed, Apr 25, 2018 at 5:16 PM, Marek Olšák  wrote:

> Hi,
>
> This feature is for gralloc, which requires drivers to be able to map
> an image with a stride of its own choosing, which is usually the same
> as the image stride. This is a very silly feature that probably comes
> from designing around mobile GPUs, and must be emulated on everything
> else.
>
> GCN is pretty limited here. A 16x16 tiled image can have a stride of 16
> because it's tiled, but the stride of a linear mapping of that image
> will be 64 on <= Polaris, or 256 on >= Vega.
>
> The hardware doesn't have the capability to give you a stride that is
> not a multiple of 64 or 256, so gralloc will have to deal with it.
>
> Nicolai wrote the first 6 commits. I added the last 4.
> (so I'll put my Rb on the first 6)
>
> Please review,
>
> Thanks,
> Marek
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/1] main: return 0 length when the queried program object's not linked

[James Xiong]

From: "Xiong, James" 

Signed-off-by: Xiong, James 
---
 src/mesa/main/shaderapi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 44b18af..caa4254 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -837,7 +837,7 @@ get_programiv(struct gl_context *ctx, GLuint program, 
GLenum pname,
   *params = shProg->BinaryRetreivableHint;
   return;
case GL_PROGRAM_BINARY_LENGTH:
-  if (ctx->Const.NumProgramBinaryFormats == 0) {
+  if (ctx->Const.NumProgramBinaryFormats == 0 || 
!shProg->data->LinkStatus) {
  *params = 0;
   } else {
  _mesa_get_program_binary_length(ctx, shProg, params);
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 1/3] mesa: merge the driver functions DrawBuffers and DrawBuffer

[Timothy Arceri]

On 26/04/18 23:41, Ian Romanick wrote:

On 04/24/2018 07:00 PM, Timothy Arceri wrote:



On 25/04/18 07:34, Ian Romanick wrote:

On 04/24/2018 09:28 AM, Ian Romanick wrote:

On 04/23/2018 08:23 PM, Timothy Arceri wrote:

On 24/04/18 10:13, Dieter Nützel wrote:

Hello Timo,

what about 2 and 3, #1 landed.


It turns out the old radeon classic drivers do make use of the param
dropped in patch 2 so I've decided to drop that patch, although the use
of that param might be a bug as the intel drivers changed their
behavior
to fix a bug (however it's not a simple change).


This sounds familiar, and I might have a patch for that.  Let me root
around in my git branches to see if I can find it...  I'm definitely in
favor of cleaning up a bunch of the dd interfaces.


I sent these to the list in September 2015:

https://patchwork.freedesktop.org/patch/60786/
https://patchwork.freedesktop.org/patch/60794/


For those two patches:

Acked-by: Timothy Arceri 


Pushed.  That should unblock these patches. :)


Thanks. I've pushed the api clean-up patch.




I don't recall what testing I did exactly, and I didn't put anything
useful in the commit message. :(


I'd still like to push patch 3 but it's tripping up some old
hardware in
Intels CI system. I'm not sure whats going on yet.


Dieter

___
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 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

[Gurchetan Singh]

On Thu, Apr 26, 2018 at 3:08 PM, Marek Olšák  wrote:
> On Thu, Apr 26, 2018 at 2:40 PM, Gurchetan Singh
>  wrote:
>>
>> On Thu, Apr 26, 2018 at 10:23 AM, Marek Olšák  wrote:
>> > Gurchetan, can you confirm that the stride returned at alloc() is only
>> > used
>> > for CPU access and not for display programming?
>>
>> It really depends on how you couple your HWComposer and gralloc HALs
>> together.  For example, drm_hwcomposer calls drmModeAddFB2 from with
>> the allocation time stride:
>>
>> https://anongit.freedesktop.org/git/drm_hwcomposer.git
>>
>> For the minigbm + wayland_hwcomposer use case, we have a
>> GRALLOC_DRM_GET_STRIDE call that returns the allocation time pixel
>> stride to the Wayland client.
>>
>> We could:
>>   - Return the stride that works for display with
>> GRALLOC_DRM_GET_STRIDE
>>   - Return the stride that works for CPU access with the alloc() call.
>>
>> Just curious -- which Android app and/or test case is running into this
>> issue?
>
>
> There is some cros_gralloc test case that is failing, but nobody told me
> which one.

I can't find any bugs filed on the subject either (I've searched our
issue trackers).

> Can you have a look at the attached minigbm patch?

It looks fine.  If it fixes whatever bugs you're seeing, we'll
definitely land this.

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

[Mesa-dev] [PATCH] egl/x11: Send invalidate to driver on copy_region path in swap_buffer

[Deepak Rawat]

Similar to swap_available path send invalidate to the driver because
egl/X11 is not watching for for server's invalidate events. The
dri2_copy_region path is trigered when server supports DRI2 version
minor 1.

Tested with piglit egl tests for regression.

V2: Move invalidate from dri2_copy_region to swap_buffer common.

Cc: 
Signed-off-by: Deepak Rawat 
Reviewed-by: Thomas Hellstrom 
---
 src/egl/drivers/dri2/platform_x11.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index 6c287b4d06..60330b33df 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -864,19 +864,22 @@ dri2_x11_swap_buffers_msc(_EGLDriver *drv, _EGLDisplay 
*disp, _EGLSurface *draw,
if (draw->Type == EGL_PIXMAP_BIT || draw->Type == EGL_PBUFFER_BIT)
   return 0;
 
-   if (draw->SwapBehavior == EGL_BUFFER_PRESERVED || !dri2_dpy->swap_available)
-  return dri2_copy_region(drv, disp, draw, dri2_surf->region) ? 0 : -1;
-
-   dri2_flush_drawable_for_swapbuffers(disp, draw);
+   if (draw->SwapBehavior == EGL_BUFFER_PRESERVED || 
!dri2_dpy->swap_available) {
+  swap_count = dri2_copy_region(drv, disp, draw, dri2_surf->region) ? 0 : 
-1;
+   } else {
+  dri2_flush_drawable_for_swapbuffers(disp, draw);
 
-   cookie = xcb_dri2_swap_buffers_unchecked(dri2_dpy->conn, 
dri2_surf->drawable,
-  msc_hi, msc_lo, divisor_hi, divisor_lo, remainder_hi, 
remainder_lo);
+  cookie = xcb_dri2_swap_buffers_unchecked(dri2_dpy->conn,
+   dri2_surf->drawable, msc_hi,
+   msc_lo, divisor_hi, divisor_lo,
+   remainder_hi, remainder_lo);
 
-   reply = xcb_dri2_swap_buffers_reply(dri2_dpy->conn, cookie, NULL);
+  reply = xcb_dri2_swap_buffers_reply(dri2_dpy->conn, cookie, NULL);
 
-   if (reply) {
-  swap_count = (((int64_t)reply->swap_hi) << 32) | reply->swap_lo;
-  free(reply);
+  if (reply) {
+ swap_count = (((int64_t)reply->swap_hi) << 32) | reply->swap_lo;
+ free(reply);
+  }
}
 
/* Since we aren't watching for the server's invalidate events like we're
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH 1/5] mesa: Silence an unused parameter warning

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 26/04/18 22:28, Ian Romanick wrote:

From: Ian Romanick 

main/framebuffer.c: In function ‘update_color_draw_buffers’:
main/framebuffer.c:629:46: warning: unused parameter ‘ctx’ [-Wunused-parameter]
  update_color_draw_buffers(struct gl_context *ctx, struct gl_framebuffer *fb)
   ^~~

Signed-off-by: Ian Romanick 
---
  src/mesa/main/framebuffer.c | 9 -
  1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 4ea18f6858e..8e751b453b7 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -549,7 +549,7 @@ _mesa_update_framebuffer_visual(struct gl_context *ctx,
   * writing colors.
   */
  static void
-update_color_draw_buffers(struct gl_context *ctx, struct gl_framebuffer *fb)
+update_color_draw_buffers(struct gl_framebuffer *fb)
  {
 GLuint output;
  
@@ -573,9 +573,8 @@ update_color_draw_buffers(struct gl_context *ctx, struct gl_framebuffer *fb)

   * Unlike the DrawBuffer, we can only read from one (or zero) color buffers.
   */
  static void
-update_color_read_buffer(struct gl_context *ctx, struct gl_framebuffer *fb)
+update_color_read_buffer(struct gl_framebuffer *fb)
  {
-   (void) ctx;
 if (fb->_ColorReadBufferIndex == BUFFER_NONE ||
 fb->DeletePending ||
 fb->Width == 0 ||
@@ -638,8 +637,8 @@ update_framebuffer(struct gl_context *ctx, struct 
gl_framebuffer *fb)
  * read-state if this FB is bound as ctx->DrawBuffer), but no
  * harm.
  */
-   update_color_draw_buffers(ctx, fb);
-   update_color_read_buffer(ctx, fb);
+   update_color_draw_buffers(fb);
+   update_color_read_buffer(fb);
  
 compute_depth_max(fb);

  }



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

[Mesa-dev] [PATCH v5 1/4] mesa: add support for nvidia conservative rasterization extensions

[Rhys Perry]

For Brian Paul:
Since you seemed to have looked over v3 of this patch, you were Cc'd. 
Compared to v3, it fixes the style problems (including the CLAMP() thing) and 
adds ALWAYS_INLINE to conservative_raster_parameter().
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

[Marek Olšák]

On Thu, Apr 26, 2018 at 2:40 PM, Gurchetan Singh <
gurchetansi...@chromium.org> wrote:

> On Thu, Apr 26, 2018 at 10:23 AM, Marek Olšák  wrote:
> > Gurchetan, can you confirm that the stride returned at alloc() is only
> used
> > for CPU access and not for display programming?
>
> It really depends on how you couple your HWComposer and gralloc HALs
> together.  For example, drm_hwcomposer calls drmModeAddFB2 from with
> the allocation time stride:
>
> https://anongit.freedesktop.org/git/drm_hwcomposer.git
>
> For the minigbm + wayland_hwcomposer use case, we have a
> GRALLOC_DRM_GET_STRIDE call that returns the allocation time pixel
> stride to the Wayland client.
>
> We could:
>   - Return the stride that works for display with
> GRALLOC_DRM_GET_STRIDE
>   - Return the stride that works for CPU access with the alloc() call.
>
> Just curious -- which Android app and/or test case is running into this
> issue?
>

There is some cros_gralloc test case that is failing, but nobody told me
which one. Can you have a look at the attached minigbm patch?

Marek
From 64865522a2fb41d338a34ee5aa79ffee059b071b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Thu, 26 Apr 2018 17:58:15 -0400
Subject: [PATCH] amdgpu: always set the CPU stride as the BO stride

---
 amdgpu.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/amdgpu.c b/amdgpu.c
index 3bf5eb2..600572b 100644
--- a/amdgpu.c
+++ b/amdgpu.c
@@ -139,15 +139,33 @@ static int amdgpu_create_bo(struct bo *bo, uint32_t width, uint32_t height, uint
 	if (!combo)
 		return -EINVAL;
 
-	if (combo->metadata.tiling == TILE_TYPE_DRI)
-		return dri_bo_create(bo, width, height, format, use_flags);
-
+	/* Compute the linear stride that's also use for CPU mappings. */
 	stride = drv_stride_from_format(format, width, 0);
 	if (format == DRM_FORMAT_YVU420_ANDROID)
 		stride = ALIGN(stride, 128);
 	else
 		stride = ALIGN(stride, 64);
 
+	if (combo->metadata.tiling == TILE_TYPE_DRI) {
+		int r = dri_bo_create(bo, width, height, format, use_flags);
+		if (r)
+			return r;
+
+		/* __DRI_IMAGE_ATTRIB_STRIDE is the display stride (tiled stride) and is used
+		 * for programming the display.
+		 *
+		 * For CPU mappings, we have to use the CPU stride (linear stride).
+		 *
+		 * In practice, we only have to make sure that the display and CPU strides are
+		 * the same for display resolutions that we support. In all other cases, we
+		 * don't need the display stride.
+		 *
+		 * Set the CPU stride so that CPU mappings work.
+		 */
+		bo->strides[0] = stride;
+		return 0;
+	}
+
 	drv_bo_from_format(bo, stride, height, format);
 
 	memset(_create, 0, sizeof(gem_create));
-- 
2.17.0

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

[Mesa-dev] [PATCH 5/5] r200: Enable NV_fog_distance

[Ian Romanick]

From: Ian Romanick 

With the previous fixes in place, it appears to just work.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/r200/r200_context.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/r200/r200_context.c 
b/src/mesa/drivers/dri/r200/r200_context.c
index 4524f06d10c..9417dfc8a7b 100644
--- a/src/mesa/drivers/dri/r200/r200_context.c
+++ b/src/mesa/drivers/dri/r200/r200_context.c
@@ -353,6 +353,7 @@ GLboolean r200CreateContext( gl_api api,
ctx->Extensions.EXT_texture_filter_anisotropic = true;
ctx->Extensions.EXT_texture_mirror_clamp = true;
ctx->Extensions.MESA_pack_invert = true;
+   ctx->Extensions.NV_fog_distance = true;
ctx->Extensions.NV_texture_rectangle = true;
ctx->Extensions.OES_EGL_image = true;
 
-- 
2.14.3

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

[Mesa-dev] [PATCH 3/5] ffvertex: Don't try to read output registers in fog calculation

[Ian Romanick]

From: Ian Romanick 

This code was clearly never tested.  It's a good thing that no driver
ever tried to enable this path.

Signed-off-by: Ian Romanick 
---
 src/mesa/main/ffvertex_prog.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index 1c755592bd9..dfb494bd8c1 100644
--- a/src/mesa/main/ffvertex_prog.c
+++ b/src/mesa/main/ffvertex_prog.c
@@ -1297,12 +1297,14 @@ static void build_fog( struct tnl_program *p )
struct ureg input;
 
switch (p->state->fog_distance_mode) {
-   case FDM_EYE_RADIAL: /* Z = sqrt(Xe*Xe + Ye*Ye + Ze*Ze) */
+   case FDM_EYE_RADIAL: { /* Z = sqrt(Xe*Xe + Ye*Ye + Ze*Ze) */
+  struct ureg tmp = get_temp(p);
   input = get_eye_position(p);
-  emit_op2(p, OPCODE_DP3, fog, WRITEMASK_X, input, input);
-  emit_op1(p, OPCODE_RSQ, fog, WRITEMASK_X, fog);
-  emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, fog);
+  emit_op2(p, OPCODE_DP3, tmp, WRITEMASK_X, input, input);
+  emit_op1(p, OPCODE_RSQ, tmp, WRITEMASK_X, tmp);
+  emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, tmp);
   break;
+   }
case FDM_EYE_PLANE: /* Z = Ze */
   input = get_eye_position_z(p);
   emit_op1(p, OPCODE_MOV, fog, WRITEMASK_X, input);
-- 
2.14.3

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

[Mesa-dev] [PATCH 1/5] mesa: Silence an unused parameter warning

[Ian Romanick]

From: Ian Romanick 

main/framebuffer.c: In function ‘update_color_draw_buffers’:
main/framebuffer.c:629:46: warning: unused parameter ‘ctx’ [-Wunused-parameter]
 update_color_draw_buffers(struct gl_context *ctx, struct gl_framebuffer *fb)
  ^~~

Signed-off-by: Ian Romanick 
---
 src/mesa/main/framebuffer.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 4ea18f6858e..8e751b453b7 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -549,7 +549,7 @@ _mesa_update_framebuffer_visual(struct gl_context *ctx,
  * writing colors.
  */
 static void
-update_color_draw_buffers(struct gl_context *ctx, struct gl_framebuffer *fb)
+update_color_draw_buffers(struct gl_framebuffer *fb)
 {
GLuint output;
 
@@ -573,9 +573,8 @@ update_color_draw_buffers(struct gl_context *ctx, struct 
gl_framebuffer *fb)
  * Unlike the DrawBuffer, we can only read from one (or zero) color buffers.
  */
 static void
-update_color_read_buffer(struct gl_context *ctx, struct gl_framebuffer *fb)
+update_color_read_buffer(struct gl_framebuffer *fb)
 {
-   (void) ctx;
if (fb->_ColorReadBufferIndex == BUFFER_NONE ||
fb->DeletePending ||
fb->Width == 0 ||
@@ -638,8 +637,8 @@ update_framebuffer(struct gl_context *ctx, struct 
gl_framebuffer *fb)
 * read-state if this FB is bound as ctx->DrawBuffer), but no
 * harm.
 */
-   update_color_draw_buffers(ctx, fb);
-   update_color_read_buffer(ctx, fb);
+   update_color_draw_buffers(fb);
+   update_color_read_buffer(fb);
 
compute_depth_max(fb);
 }
-- 
2.14.3

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

[Mesa-dev] [PATCH 4/5] i965: Enable NV_fog_distance

[Ian Romanick]

From: Ian Romanick 

With the previous fixes in place, it appears to just work.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 73a6c73f537..e1e19217bc9 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -122,6 +122,7 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.ATI_texture_env_combine3 = true;
ctx->Extensions.MESA_pack_invert = true;
ctx->Extensions.NV_conditional_render = true;
+   ctx->Extensions.NV_fog_distance = true;
ctx->Extensions.NV_primitive_restart = true;
ctx->Extensions.NV_texture_barrier = true;
ctx->Extensions.NV_texture_env_combine4 = true;
-- 
2.14.3

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

[Mesa-dev] [PATCH 2/5] mesa: Add missing support for glFogiv(GL_FOG_DISTANCE_MODE_NV)

[Ian Romanick]

From: Ian Romanick 

Found by inspection, so I made a piglit test too.

Signed-off-by: Ian Romanick 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/main/fog.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/main/fog.c b/src/mesa/main/fog.c
index c051aaddedc..0decf762a99 100644
--- a/src/mesa/main/fog.c
+++ b/src/mesa/main/fog.c
@@ -62,6 +62,7 @@ _mesa_Fogiv(GLenum pname, const GLint *params )
   case GL_FOG_END:
   case GL_FOG_INDEX:
   case GL_FOG_COORDINATE_SOURCE_EXT:
+  case GL_FOG_DISTANCE_MODE_NV:
 p[0] = (GLfloat) *params;
 break;
   case GL_FOG_COLOR:
-- 
2.14.3

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

[Mesa-dev] (no subject)

[Ian Romanick]

I had some discussions with Timothy Arceri earlier in the week about
some old r100 patches that I had written.  That led me to re-discover
this series that enables NV_fog_distance on platforms that have vertex
shader hardware.  Tests will be out on the piglit list momentarily.

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

Re: [Mesa-dev] [PATCH] meson: fix race condition revealed by using 0.44

[Scott D Phillips]

Dylan Baker  writes:

> It turns out that the blocking target we had was hiding some race
> conditions in the anv driver with anv_extensions.h generation, we should
> fix those.
>
> CC: Scott D Phillips 
> CC: Mark Janes 
> Fixes: 92550d9b16d2b295bdac087f31b1fd6d0f808e02
>("meson: remove workaround for custom target creating .h and .c files")
> Signed-off-by: Dylan Baker 

Reviewed-by: Scott D Phillips 

> ---
>  src/intel/vulkan/meson.build | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
> index 06acc78391f..f20a8a54c9b 100644
> --- a/src/intel/vulkan/meson.build
> +++ b/src/intel/vulkan/meson.build
> @@ -1,4 +1,4 @@
> -# Copyright © 2017 Intel Corporation
> +# Copyright © 2017-2018 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
> @@ -96,7 +96,7 @@ foreach g : [['70', ['gen7_cmd_buffer.c']], ['75', 
> ['gen7_cmd_buffer.c']],
>_gen = g[0]
>libanv_gen_libs += static_library(
>  'libanv_gen@0@'.format(_gen),
> -[anv_gen_files, g[1], anv_entrypoints[0]],
> +[anv_gen_files, g[1], anv_entrypoints[0], anv_extensions_h],
>  include_directories : [
>inc_common, inc_compiler, inc_drm_uapi, inc_intel, inc_vulkan_util,
>inc_vulkan_wsi,
> @@ -220,7 +220,7 @@ if with_tests
>'anv_@0@'.format(t),
>executable(
>  t,
> -['tests/@0@.c'.format(t), anv_entrypoints[0]],
> +['tests/@0@.c'.format(t), anv_entrypoints[0], anv_extensions_h],
>  link_with : libvulkan_intel_test,
>  dependencies : [dep_libdrm, dep_thread, dep_m, dep_valgrind],
>  include_directories : [
> -- 
> 2.17.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 v2] anv: enable VK_EXT_shader_viewport_index_layer

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Thu, Apr 26, 2018 at 12:11 PM, Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:

> Reviewed-by: Iago Toral Quiroga 
> ---
>  src/intel/vulkan/anv_extensions.py | 1 +
>  src/intel/vulkan/anv_pipeline.c| 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_extensions.py b/src/intel/vulkan/anv_
> extensions.py
> index d0b70a0405..b5bee0881c 100644
> --- a/src/intel/vulkan/anv_extensions.py
> +++ b/src/intel/vulkan/anv_extensions.py
> @@ -111,6 +111,7 @@ EXTENSIONS = [
>  Extension('VK_EXT_external_memory_dma_buf',   1, True),
>  Extension('VK_EXT_global_priority',   1,
>'device->has_context_priority'),
> +Extension('VK_EXT_shader_viewport_index_layer',   1, True),
>  ]
>
>  class VkVersion:
> diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_
> pipeline.c
> index e64602d284..56bea7bf0d 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -144,6 +144,7 @@ anv_shader_compile_to_nir(struct anv_pipeline
> *pipeline,
>   .multiview = true,
>   .variable_pointers = true,
>   .storage_16bit = device->instance->physicalDevice.info.gen >= 8,
> + .shader_viewport_index_layer = true,
>   .subgroup_arithmetic = true,
>   .subgroup_basic = true,
>   .subgroup_ballot = true,
> --
> 2.17.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

[Mesa-dev] [PATCH v2] anv: enable VK_EXT_shader_viewport_index_layer

[Caio Marcelo de Oliveira Filho]

Reviewed-by: Iago Toral Quiroga 
---
 src/intel/vulkan/anv_extensions.py | 1 +
 src/intel/vulkan/anv_pipeline.c| 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index d0b70a0405..b5bee0881c 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -111,6 +111,7 @@ EXTENSIONS = [
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
 Extension('VK_EXT_global_priority',   1,
   'device->has_context_priority'),
+Extension('VK_EXT_shader_viewport_index_layer',   1, True),
 ]
 
 class VkVersion:
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index e64602d284..56bea7bf0d 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -144,6 +144,7 @@ anv_shader_compile_to_nir(struct anv_pipeline *pipeline,
  .multiview = true,
  .variable_pointers = true,
  .storage_16bit = device->instance->physicalDevice.info.gen >= 8,
+ .shader_viewport_index_layer = true,
  .subgroup_arithmetic = true,
  .subgroup_basic = true,
  .subgroup_ballot = true,
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH v2 4/5] i965/clear: Simplify updating the indirect depth value

[Nanley Chery]

On Thu, Apr 26, 2018 at 11:27:00AM -0700, Jason Ekstrand wrote:
> On Thu, Apr 26, 2018 at 11:19 AM, Rafael Antognolli <
> rafael.antogno...@intel.com> wrote:
> 
> > On Thu, Apr 26, 2018 at 10:41:37AM -0700, Nanley Chery wrote:
> > > On Wed, Apr 25, 2018 at 08:53:36PM -0400, Jason Ekstrand wrote:
> > > >
> > > >
> > > > On April 25, 2018 20:25:16 Nanley Chery  wrote:
> > > >
> > > > On Wed, Apr 25, 2018 at 04:50:11PM -0700, Jason Ekstrand wrote:
> > > > On Tue, Apr 24, 2018 at 5:48 PM, Nanley Chery 
> > wrote:
> > > >
> > >
> > > Your email client dropped the quotes :/ Thankfully, gmail can pick out
> > > the diff.
> > >
> > > > Determine the predicate for updating the indirect depth value in the
> > > > loop which inspects whether or not we need to resolve any slices.
> > > > ---
> > > > src/mesa/drivers/dri/i965/brw_clear.c | 43
> > +-
> > > > -
> > > > 1 file changed, 16 insertions(+), 27 deletions(-)
> > > >
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
> > > > b/src/mesa/drivers/dri/i965/brw_clear.c
> > > > index 6521141d7f6..e372d28926e 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_clear.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_clear.c
> > > > @@ -108,7 +108,6 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > > > struct intel_mipmap_tree *mt = depth_irb->mt;
> > > > struct gl_renderbuffer_attachment *depth_att =
> > > > >Attachment[BUFFER_DEPTH];
> > > > const struct gen_device_info *devinfo = >screen->devinfo;
> > > > -   bool same_clear_value = true;
> > > >
> > > > if (devinfo->gen < 6)
> > > > return false;
> > > > @@ -174,9 +173,16 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > > > const uint32_t num_layers = depth_att->Layered ?
> > > > depth_irb->layer_count : 1;
> > > >
> > > > /* If we're clearing to a new clear value, then we need to resolve any
> > > > clear
> > > > -* flags out of the HiZ buffer into the real depth buffer.
> > > > +* flags out of the HiZ buffer into the real depth buffer and
> > update
> > > > the
> > > > +* miptree's clear value.
> > > > */
> > > > if (mt->fast_clear_color.f32[0] != clear_value) {
> > > > +  /* BLORP updates the indirect clear color buffer when we do fast
> > > > clears.
> > > > +   * If we won't do a fast clear, we'll have to update it
> > ourselves.
> > > > Start
> > > > +   * off assuming we won't perform a fast clear.
> > > > +   */
> > > > +  bool blorp_will_update_indirect_color = false;
> > > >
> > > > This boolean is rather awkward.
> > > >
> > > > Why's that?
> > > >
> > > > It does have a clear meaning and it does what it says it does.
> > However,
> > > > it's not that obvious of a thing to work with compared to "did we do a
> > > > clear?"
> > > >
> > > >
> > > > +
> > > > for (uint32_t level = mt->first_level; level <= mt->last_level;
> > > > level++) {
> > > > if (!intel_miptree_level_has_hiz(mt, level))
> > > > continue;
> > > > @@ -184,16 +190,20 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > > > const unsigned level_layers = brw_get_num_logical_layers(mt,
> > > > level);
> > > >
> > > > for (uint32_t layer = 0; layer < level_layers; layer++) {
> > > > +const enum isl_aux_state aux_state =
> > > > +   intel_miptree_get_aux_state(mt, level, layer);
> > > > +
> > > > if (level == depth_irb->mt_level &&
> > > > layer >= depth_irb->mt_layer &&
> > > > layer < depth_irb->mt_layer + num_layers) {
> > > > +
> > > > +   if (aux_state != ISL_AUX_STATE_CLEAR)
> > > > +  blorp_will_update_indirect_color = true;
> > > >
> > > > Putting this here separates the detection of whether or not we are
> > doing a
> > > > fast clear (and therefore don't need to set the clear color) even
> > further
> > > > from where we do the clear and use this value than it was previously.
> > > >
> > > >
> > >
> > > Sure.
> > >
> > > > +
> > > > /* We're going to clear this layer anyway.  Leave it
> > > > alone. */
> > > > continue;
> > > > }
> > > >
> > > > -enum isl_aux_state aux_state =
> > > > -   intel_miptree_get_aux_state(mt, level, layer);
> > > > -
> > > > if (aux_state != ISL_AUX_STATE_CLEAR &&
> > > > aux_state != ISL_AUX_STATE_COMPRESSED_CLEAR) {
> > > > /* This slice doesn't have any fast-cleared bits. */
> > > > @@ -214,29 +224,8 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > > > }
> > > >
> > > > intel_miptree_set_depth_clear_value(brw, mt, clear_value);
> > > > -  same_clear_value = false;
> > > > -   }
> > > > -
> > > > -   bool need_clear = false;
> > > > -   for (unsigned a = 0; a < num_layers; a++) {
> > > > -  enum isl_aux_state aux_state =
> > > > - intel_miptree_get_aux_state(mt, depth_irb->mt_level,
> > > > - depth_irb->mt_layer + a);
> > > > -
> > > > -  if (aux_state != ISL_AUX_STATE_CLEAR) {
> > > > - need_clear = true;
> > > > - break;
> > > > -  }

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

[Gurchetan Singh]

On Thu, Apr 26, 2018 at 10:23 AM, Marek Olšák  wrote:
> Gurchetan, can you confirm that the stride returned at alloc() is only used
> for CPU access and not for display programming?

It really depends on how you couple your HWComposer and gralloc HALs
together.  For example, drm_hwcomposer calls drmModeAddFB2 from with
the allocation time stride:

https://anongit.freedesktop.org/git/drm_hwcomposer.git

For the minigbm + wayland_hwcomposer use case, we have a
GRALLOC_DRM_GET_STRIDE call that returns the allocation time pixel
stride to the Wayland client.

We could:
  - Return the stride that works for display with GRALLOC_DRM_GET_STRIDE
  - Return the stride that works for CPU access with the alloc() call.

Just curious -- which Android app and/or test case is running into this issue?

> Thanks,
> Marek
>
> On Wed, Apr 25, 2018 at 11:23 PM, Marek Olšák  wrote:
>>
>> Why would you want to modify it? It's exactly what you get when you map
>> it, but that stride can't be used for modesetting.
>>
>> Marek
>>
>>
>> On Wed, Apr 25, 2018 at 11:14 PM, Gurchetan Singh
>>  wrote:
>>>
>>> That sounds fine to me.  We can just modify the stride after
>>> dri_bo_create(..).
>>>
>>> On Wed, Apr 25, 2018 at 7:30 PM, Marek Olšák  wrote:
>>> > On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh
>>> >  wrote:
>>> >>
>>> >> On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák  wrote:
>>> >> > From: Nicolai Hähnle 
>>> >> >
>>> >> > Allow the caller to specify the row stride (in bytes) with which an
>>> >> > image
>>> >> > should be mapped. Note that completely ignoring USER_STRIDE is a
>>> >> > valid
>>> >> > implementation of mapImage.
>>> >> >
>>> >> > This is horrible API design. Unfortunately, cros_gralloc does indeed
>>> >> > have
>>> >> > a horrible API design -- in that arbitrary images should be allowed
>>> >> > to
>>> >> > be
>>> >> > mapped with the stride that a linear image of the same width would
>>> >> > have.
>>> >>
>>> >> Yes, unfortunately the gralloc API doesn't return the stride when
>>> >> (*lock) is called.  However, the stride is returned during (*alloc).
>>> >> Currently, for the dri backend, minigbm uses
>>> >> __DRI_IMAGE_ATTRIB_STRIDE to compute the pixel stride given to
>>> >> Android.
>>> >>
>>> >> Is AMD seeing problems with the current approach (I haven't seen any
>>> >> bugs filed for this issue)?
>>> >>
>>> >> Another possible solution is to call mapImage()/unmapImage right after
>>> >> allocating the image, and use the stride returned by mapImage() to
>>> >> compute the pixel stride.  That could also fix whatever bugs AMD is
>>> >> seeing.
>>> >
>>> >
>>> > Thanks. You cleared it up to me. It looks like that everything we've
>>> > been
>>> > told so far is BS. This series isn't needed.
>>> >
>>> > The solution is to do this in the amdgpu minigbm backend at alloc time:
>>> >stride = align(width * Bpp, 64);
>>> >
>>> > Later chips should change that to:
>>> >stride = align(width * Bpp, 256);
>>> >
>>> > No querying needed. What do you think?
>>> >
>>> > Marek
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 4/5] i965/clear: Simplify updating the indirect depth value

[Jason Ekstrand]

On Thu, Apr 26, 2018 at 11:19 AM, Rafael Antognolli <
rafael.antogno...@intel.com> wrote:

> On Thu, Apr 26, 2018 at 10:41:37AM -0700, Nanley Chery wrote:
> > On Wed, Apr 25, 2018 at 08:53:36PM -0400, Jason Ekstrand wrote:
> > >
> > >
> > > On April 25, 2018 20:25:16 Nanley Chery  wrote:
> > >
> > > On Wed, Apr 25, 2018 at 04:50:11PM -0700, Jason Ekstrand wrote:
> > > On Tue, Apr 24, 2018 at 5:48 PM, Nanley Chery 
> wrote:
> > >
> >
> > Your email client dropped the quotes :/ Thankfully, gmail can pick out
> > the diff.
> >
> > > Determine the predicate for updating the indirect depth value in the
> > > loop which inspects whether or not we need to resolve any slices.
> > > ---
> > > src/mesa/drivers/dri/i965/brw_clear.c | 43
> +-
> > > -
> > > 1 file changed, 16 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
> > > b/src/mesa/drivers/dri/i965/brw_clear.c
> > > index 6521141d7f6..e372d28926e 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_clear.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_clear.c
> > > @@ -108,7 +108,6 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > > struct intel_mipmap_tree *mt = depth_irb->mt;
> > > struct gl_renderbuffer_attachment *depth_att =
> > > >Attachment[BUFFER_DEPTH];
> > > const struct gen_device_info *devinfo = >screen->devinfo;
> > > -   bool same_clear_value = true;
> > >
> > > if (devinfo->gen < 6)
> > > return false;
> > > @@ -174,9 +173,16 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > > const uint32_t num_layers = depth_att->Layered ?
> > > depth_irb->layer_count : 1;
> > >
> > > /* If we're clearing to a new clear value, then we need to resolve any
> > > clear
> > > -* flags out of the HiZ buffer into the real depth buffer.
> > > +* flags out of the HiZ buffer into the real depth buffer and
> update
> > > the
> > > +* miptree's clear value.
> > > */
> > > if (mt->fast_clear_color.f32[0] != clear_value) {
> > > +  /* BLORP updates the indirect clear color buffer when we do fast
> > > clears.
> > > +   * If we won't do a fast clear, we'll have to update it
> ourselves.
> > > Start
> > > +   * off assuming we won't perform a fast clear.
> > > +   */
> > > +  bool blorp_will_update_indirect_color = false;
> > >
> > > This boolean is rather awkward.
> > >
> > > Why's that?
> > >
> > > It does have a clear meaning and it does what it says it does.
> However,
> > > it's not that obvious of a thing to work with compared to "did we do a
> > > clear?"
> > >
> > >
> > > +
> > > for (uint32_t level = mt->first_level; level <= mt->last_level;
> > > level++) {
> > > if (!intel_miptree_level_has_hiz(mt, level))
> > > continue;
> > > @@ -184,16 +190,20 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > > const unsigned level_layers = brw_get_num_logical_layers(mt,
> > > level);
> > >
> > > for (uint32_t layer = 0; layer < level_layers; layer++) {
> > > +const enum isl_aux_state aux_state =
> > > +   intel_miptree_get_aux_state(mt, level, layer);
> > > +
> > > if (level == depth_irb->mt_level &&
> > > layer >= depth_irb->mt_layer &&
> > > layer < depth_irb->mt_layer + num_layers) {
> > > +
> > > +   if (aux_state != ISL_AUX_STATE_CLEAR)
> > > +  blorp_will_update_indirect_color = true;
> > >
> > > Putting this here separates the detection of whether or not we are
> doing a
> > > fast clear (and therefore don't need to set the clear color) even
> further
> > > from where we do the clear and use this value than it was previously.
> > >
> > >
> >
> > Sure.
> >
> > > +
> > > /* We're going to clear this layer anyway.  Leave it
> > > alone. */
> > > continue;
> > > }
> > >
> > > -enum isl_aux_state aux_state =
> > > -   intel_miptree_get_aux_state(mt, level, layer);
> > > -
> > > if (aux_state != ISL_AUX_STATE_CLEAR &&
> > > aux_state != ISL_AUX_STATE_COMPRESSED_CLEAR) {
> > > /* This slice doesn't have any fast-cleared bits. */
> > > @@ -214,29 +224,8 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > > }
> > >
> > > intel_miptree_set_depth_clear_value(brw, mt, clear_value);
> > > -  same_clear_value = false;
> > > -   }
> > > -
> > > -   bool need_clear = false;
> > > -   for (unsigned a = 0; a < num_layers; a++) {
> > > -  enum isl_aux_state aux_state =
> > > - intel_miptree_get_aux_state(mt, depth_irb->mt_level,
> > > - depth_irb->mt_layer + a);
> > > -
> > > -  if (aux_state != ISL_AUX_STATE_CLEAR) {
> > > - need_clear = true;
> > > - break;
> > > -  }
> > > -   }
> > > -
> > > -   if (!need_clear) {
> > > -  if (!same_clear_value) {
> > > - /* BLORP updates the indirect clear color buffer when
> performing
> > > a
> > > -  * fast clear. Since we are skipping the fast clear here, we
> > > need to
> > > -  * do the update ourselves.
> > > - 

Re: [Mesa-dev] [PATCH 02/10] glsl: add missing include to ir_optimization.h

[Matt Turner]

On Mon, Apr 9, 2018 at 9:34 PM, Timothy Arceri  wrote:
> ---
>  src/compiler/glsl/ir_optimization.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/compiler/glsl/ir_optimization.h 
> b/src/compiler/glsl/ir_optimization.h
> index 81049a479e8..f5d2bea0cd5 100644
> --- a/src/compiler/glsl/ir_optimization.h
> +++ b/src/compiler/glsl/ir_optimization.h
> @@ -30,6 +30,8 @@
>  #ifndef GLSL_IR_OPTIMIZATION_H
>  #define GLSL_IR_OPTIMIZATION_H
>
> +#include "ir.h"
> +

Would be nice to say what this fixed. This file has existed for years
without ever including anything else, so I suspect that the expected
way to use it is to always include it after including ir.h. But that's
admittedly weird, so

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 01/10] glsl: replace some asserts with unreachable when processing the ast

[Matt Turner]

On Mon, Apr 9, 2018 at 9:34 PM, Timothy Arceri  wrote:
> ---
>  src/compiler/glsl/ast_to_hir.cpp | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/compiler/glsl/ast_to_hir.cpp 
> b/src/compiler/glsl/ast_to_hir.cpp
> index 168ab7eec2f..4d7383c580f 100644
> --- a/src/compiler/glsl/ast_to_hir.cpp
> +++ b/src/compiler/glsl/ast_to_hir.cpp
> @@ -1396,7 +1396,7 @@ ast_expression::do_hir(exec_list *instructions,
>
> switch (this->oper) {
> case ast_aggregate:
> -  assert(!"ast_aggregate: Should never get here.");
> +  unreachable("ast_aggregate: Should never get here.");
>break;
>
> case ast_assign: {
> @@ -1973,14 +1973,14 @@ ast_expression::do_hir(exec_list *instructions,
> }
>
> case ast_unsized_array_dim:
> -  assert(!"ast_unsized_array_dim: Should never get here.");
> +  unreachable("ast_unsized_array_dim: Should never get here.");
>break;
>
> case ast_function_call:
>/* Should *NEVER* get here.  ast_function_call should always be handled
> * by ast_function_expression::hir.
> */
> -  assert(0);
> +  unreachable("ast_function_call: handled elsewhere ");
>break;
>
> case ast_identifier: {
> --
> 2.17.0

Remove the now unnecessary breaks and have a

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] egl/android: remove flink name support

[Robert Foss]

On 04/26/2018 07:43 PM, Emil Velikov wrote:

On 26 April 2018 at 18:34, Rob Herring  wrote:

On Thu, Apr 26, 2018 at 11:56 AM, Emil Velikov  wrote:

On 26 April 2018 at 03:30, Chih-Wei Huang  wrote:

2018-04-25 19:55 GMT+08:00 Robert Foss :

Hey Emil & Chih-Wei,

On 04/24/2018 01:59 PM, Emil Velikov wrote:


On 24 April 2018 at 12:28, Emil Velikov  wrote:


On the topic of keeping the old code behind a #define or just removing
it, it'll be great if interested parties can reach a consensus.


Actually one can simply drop this code and drm_gralloc users can add a
drm_ioctl_permit() hack.
Namely: loosen the restrictions to consider render nodes identical to
primary/card ones.

Yes, it's a nasty hack, yet no worse than the existing one that
removes the auth :-\


I'm fine with adding a #define.
Chih-Wei: Do you have any objections?


"keeping the old code behind a #define"?
Sounds good to me. Thank you!


Having a look at the Android-x86 kernel:
The current hack in the permission check (see drm_ioctl_permit in [1])
effectively threats render nodes and primary nodes as the same thing.

Thus, on top of the current patch the !dri2_dpy->is_render_node check
should be removed, for Android-x86.
There's no need to keep the flink code around ;-)


Except I don't think drm_gralloc fills in a dma-buf fd in it's
handle... There was an AOSP version that did IIRC.

Or maybe I'm missing something.


You're probably right - I haven't looked closely at drm_gralloc in ages.
Yet again, considering the hacked auth, there should be no blockers to
tweaking drm_gralloc.

Either way, I'm just overly hyped looking for ways to remove the flink code.
Feel free to ignore my suggestions.


I've spent some time today preparing a #ifdef version of what robher submitted.

It's fine, but there is no way automatically enable the HAVE_DRM_GRALLOC #define 
through the build tools. So a small simple patch adding the shared library 
dependency, and adding the -DHAVE_DRM_GRALLOC cflag is needed.


I'll send it out tomorrow, a bit late in the day for sending out patches now ;)


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

Re: [Mesa-dev] [PATCH v2 4/5] i965/clear: Simplify updating the indirect depth value

[Rafael Antognolli]

On Thu, Apr 26, 2018 at 10:41:37AM -0700, Nanley Chery wrote:
> On Wed, Apr 25, 2018 at 08:53:36PM -0400, Jason Ekstrand wrote:
> > 
> > 
> > On April 25, 2018 20:25:16 Nanley Chery  wrote:
> > 
> > On Wed, Apr 25, 2018 at 04:50:11PM -0700, Jason Ekstrand wrote:
> > On Tue, Apr 24, 2018 at 5:48 PM, Nanley Chery  wrote:
> > 
> 
> Your email client dropped the quotes :/ Thankfully, gmail can pick out
> the diff.
> 
> > Determine the predicate for updating the indirect depth value in the
> > loop which inspects whether or not we need to resolve any slices.
> > ---
> > src/mesa/drivers/dri/i965/brw_clear.c | 43 +-
> > -
> > 1 file changed, 16 insertions(+), 27 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
> > b/src/mesa/drivers/dri/i965/brw_clear.c
> > index 6521141d7f6..e372d28926e 100644
> > --- a/src/mesa/drivers/dri/i965/brw_clear.c
> > +++ b/src/mesa/drivers/dri/i965/brw_clear.c
> > @@ -108,7 +108,6 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > struct intel_mipmap_tree *mt = depth_irb->mt;
> > struct gl_renderbuffer_attachment *depth_att =
> > >Attachment[BUFFER_DEPTH];
> > const struct gen_device_info *devinfo = >screen->devinfo;
> > -   bool same_clear_value = true;
> > 
> > if (devinfo->gen < 6)
> > return false;
> > @@ -174,9 +173,16 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > const uint32_t num_layers = depth_att->Layered ?
> > depth_irb->layer_count : 1;
> > 
> > /* If we're clearing to a new clear value, then we need to resolve any
> > clear
> > -* flags out of the HiZ buffer into the real depth buffer.
> > +* flags out of the HiZ buffer into the real depth buffer and update
> > the
> > +* miptree's clear value.
> > */
> > if (mt->fast_clear_color.f32[0] != clear_value) {
> > +  /* BLORP updates the indirect clear color buffer when we do fast
> > clears.
> > +   * If we won't do a fast clear, we'll have to update it ourselves.
> > Start
> > +   * off assuming we won't perform a fast clear.
> > +   */
> > +  bool blorp_will_update_indirect_color = false;
> > 
> > This boolean is rather awkward.
> > 
> > Why's that?
> > 
> > It does have a clear meaning and it does what it says it does.  However,
> > it's not that obvious of a thing to work with compared to "did we do a
> > clear?"
> > 
> > 
> > +
> > for (uint32_t level = mt->first_level; level <= mt->last_level;
> > level++) {
> > if (!intel_miptree_level_has_hiz(mt, level))
> > continue;
> > @@ -184,16 +190,20 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > const unsigned level_layers = brw_get_num_logical_layers(mt,
> > level);
> > 
> > for (uint32_t layer = 0; layer < level_layers; layer++) {
> > +const enum isl_aux_state aux_state =
> > +   intel_miptree_get_aux_state(mt, level, layer);
> > +
> > if (level == depth_irb->mt_level &&
> > layer >= depth_irb->mt_layer &&
> > layer < depth_irb->mt_layer + num_layers) {
> > +
> > +   if (aux_state != ISL_AUX_STATE_CLEAR)
> > +  blorp_will_update_indirect_color = true;
> > 
> > Putting this here separates the detection of whether or not we are doing a
> > fast clear (and therefore don't need to set the clear color) even further
> > from where we do the clear and use this value than it was previously.
> > 
> > 
> 
> Sure.
> 
> > +
> > /* We're going to clear this layer anyway.  Leave it
> > alone. */
> > continue;
> > }
> > 
> > -enum isl_aux_state aux_state =
> > -   intel_miptree_get_aux_state(mt, level, layer);
> > -
> > if (aux_state != ISL_AUX_STATE_CLEAR &&
> > aux_state != ISL_AUX_STATE_COMPRESSED_CLEAR) {
> > /* This slice doesn't have any fast-cleared bits. */
> > @@ -214,29 +224,8 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > }
> > 
> > intel_miptree_set_depth_clear_value(brw, mt, clear_value);
> > -  same_clear_value = false;
> > -   }
> > -
> > -   bool need_clear = false;
> > -   for (unsigned a = 0; a < num_layers; a++) {
> > -  enum isl_aux_state aux_state =
> > - intel_miptree_get_aux_state(mt, depth_irb->mt_level,
> > - depth_irb->mt_layer + a);
> > -
> > -  if (aux_state != ISL_AUX_STATE_CLEAR) {
> > - need_clear = true;
> > - break;
> > -  }
> > -   }
> > -
> > -   if (!need_clear) {
> > -  if (!same_clear_value) {
> > - /* BLORP updates the indirect clear color buffer when performing
> > a
> > -  * fast clear. Since we are skipping the fast clear here, we
> > need to
> > -  * do the update ourselves.
> > -  */
> > +  if (!blorp_will_update_indirect_color)
> > intel_miptree_update_indirect_color(brw, mt);
> > -  }
> > 
> > I think we can do this even better.  We could do
> > 
> > bool blorp_updated_indirect_clear_color = false;
> > 
> > and then set it to true if we call intel_hiz_exec below.  Then, after the
> > loop below we would 

Re: [Mesa-dev] [PATCH] bin: force git show to use default pretty setting

[Dylan Baker]

Quoting Emil Velikov (2018-04-26 11:04:01)
> On 26 April 2018 at 18:45, Dylan Baker  wrote:
> > I have pretty default to short, which breaks this script.
> >
> Out of curiosity: why would you do this to yourself ;-)

Because I use tig, so all I have to do is press enter to see the entire commit,
log and patch :)

Dylan

> 
> > cc: Emil Velikov 
> > cc: Andres Gomez 
> > cc: Juan A. Suarez 
> > Signed-off-by: Dylan Baker 
> > ---
> >  bin/get-fixes-pick-list.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/bin/get-fixes-pick-list.sh b/bin/get-fixes-pick-list.sh
> > index fb7ef223820..983af0983dd 100755
> > --- a/bin/get-fixes-pick-list.sh
> > +++ b/bin/get-fixes-pick-list.sh
> > @@ -38,7 +38,7 @@ do
> >
> > # Place every "fixes:" tag on its own line and join with the next 
> > word
> > # on its line or a later one.
> > -   fixes=`git show -s $sha | tr -d "\n" | sed -e 
> > 's/fixes:[[:space:]]*/\nfixes:/Ig' | grep "fixes:" | sed -e 
> > 's/\(fixes:[a-zA-Z0-9]*\).*$/\1/'`
> > +   fixes=`git show --pretty=medium -s $sha | tr -d "\n" | sed -e 
> > 's/fixes:[[:space:]]*/\nfixes:/Ig' | grep "fixes:" | sed -e 
> > 's/\(fixes:[a-zA-Z0-9]*\).*$/\1/'`
> >
> An on a serious note - there are plenty of places that will need this
> kind of fix.
> Pretty much any git show/log instances that do not specify --pretty.
> 
> -Emil


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

Re: [Mesa-dev] [PATCH] bin: force git show to use default pretty setting

[Emil Velikov]

On 26 April 2018 at 18:45, Dylan Baker  wrote:
> I have pretty default to short, which breaks this script.
>
Out of curiosity: why would you do this to yourself ;-)

> cc: Emil Velikov 
> cc: Andres Gomez 
> cc: Juan A. Suarez 
> Signed-off-by: Dylan Baker 
> ---
>  bin/get-fixes-pick-list.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bin/get-fixes-pick-list.sh b/bin/get-fixes-pick-list.sh
> index fb7ef223820..983af0983dd 100755
> --- a/bin/get-fixes-pick-list.sh
> +++ b/bin/get-fixes-pick-list.sh
> @@ -38,7 +38,7 @@ do
>
> # Place every "fixes:" tag on its own line and join with the next word
> # on its line or a later one.
> -   fixes=`git show -s $sha | tr -d "\n" | sed -e 
> 's/fixes:[[:space:]]*/\nfixes:/Ig' | grep "fixes:" | sed -e 
> 's/\(fixes:[a-zA-Z0-9]*\).*$/\1/'`
> +   fixes=`git show --pretty=medium -s $sha | tr -d "\n" | sed -e 
> 's/fixes:[[:space:]]*/\nfixes:/Ig' | grep "fixes:" | sed -e 
> 's/\(fixes:[a-zA-Z0-9]*\).*$/\1/'`
>
An on a serious note - there are plenty of places that will need this
kind of fix.
Pretty much any git show/log instances that do not specify --pretty.

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

Re: [Mesa-dev] [PATCH] meson: fix race condition revealed by using 0.44

[Dylan Baker]

Quoting Emil Velikov (2018-04-26 10:35:50)
> On 26 April 2018 at 18:24, Dylan Baker  wrote:
> > It turns out that the blocking target we had was hiding some race
> > conditions in the anv driver with anv_extensions.h generation, we should
> > fix those.
> >
> anv_entrypoints[0] is the first output of the anv_entrypoints custom_target.
> Aka it's effectively the same as anv_extensions_h, isn't it?

Actually, there is anv_entrypoints.[ch], and anv_extensions.[ch], and it's the
latter that we're missing as an explicit dependency (I got confused about that
too). The thing that happened here is that the blocking target created a proper
dependency chain, but when we removed it that was broken, and we got a race.

Dylan


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

[Mesa-dev] [PATCH] bin: force git show to use default pretty setting

[Dylan Baker]

I have pretty default to short, which breaks this script.

cc: Emil Velikov 
cc: Andres Gomez 
cc: Juan A. Suarez 
Signed-off-by: Dylan Baker 
---
 bin/get-fixes-pick-list.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/get-fixes-pick-list.sh b/bin/get-fixes-pick-list.sh
index fb7ef223820..983af0983dd 100755
--- a/bin/get-fixes-pick-list.sh
+++ b/bin/get-fixes-pick-list.sh
@@ -38,7 +38,7 @@ do
 
# Place every "fixes:" tag on its own line and join with the next word
# on its line or a later one.
-   fixes=`git show -s $sha | tr -d "\n" | sed -e 
's/fixes:[[:space:]]*/\nfixes:/Ig' | grep "fixes:" | sed -e 
's/\(fixes:[a-zA-Z0-9]*\).*$/\1/'`
+   fixes=`git show --pretty=medium -s $sha | tr -d "\n" | sed -e 
's/fixes:[[:space:]]*/\nfixes:/Ig' | grep "fixes:" | sed -e 
's/\(fixes:[a-zA-Z0-9]*\).*$/\1/'`
 
# For each one try to extract the tag
fixes_count=`echo "$fixes" | wc -l`
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH] egl/android: remove flink name support

[Emil Velikov]

On 26 April 2018 at 18:34, Rob Herring  wrote:
> On Thu, Apr 26, 2018 at 11:56 AM, Emil Velikov  
> wrote:
>> On 26 April 2018 at 03:30, Chih-Wei Huang  wrote:
>>> 2018-04-25 19:55 GMT+08:00 Robert Foss :
 Hey Emil & Chih-Wei,

 On 04/24/2018 01:59 PM, Emil Velikov wrote:
>
> On 24 April 2018 at 12:28, Emil Velikov  wrote:
>
>> On the topic of keeping the old code behind a #define or just removing
>> it, it'll be great if interested parties can reach a consensus.
>>
> Actually one can simply drop this code and drm_gralloc users can add a
> drm_ioctl_permit() hack.
> Namely: loosen the restrictions to consider render nodes identical to
> primary/card ones.
>
> Yes, it's a nasty hack, yet no worse than the existing one that
> removes the auth :-\

 I'm fine with adding a #define.
 Chih-Wei: Do you have any objections?
>>>
>>> "keeping the old code behind a #define"?
>>> Sounds good to me. Thank you!
>>
>> Having a look at the Android-x86 kernel:
>> The current hack in the permission check (see drm_ioctl_permit in [1])
>> effectively threats render nodes and primary nodes as the same thing.
>>
>> Thus, on top of the current patch the !dri2_dpy->is_render_node check
>> should be removed, for Android-x86.
>> There's no need to keep the flink code around ;-)
>
> Except I don't think drm_gralloc fills in a dma-buf fd in it's
> handle... There was an AOSP version that did IIRC.
>
> Or maybe I'm missing something.
>
You're probably right - I haven't looked closely at drm_gralloc in ages.
Yet again, considering the hacked auth, there should be no blockers to
tweaking drm_gralloc.

Either way, I'm just overly hyped looking for ways to remove the flink code.
Feel free to ignore my suggestions.

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

Re: [Mesa-dev] [PATCH v2 4/5] i965/clear: Simplify updating the indirect depth value

[Nanley Chery]

+ Rafael

On Thu, Apr 26, 2018 at 10:41:37AM -0700, Nanley Chery wrote:
> On Wed, Apr 25, 2018 at 08:53:36PM -0400, Jason Ekstrand wrote:
> > 
> > 
> > On April 25, 2018 20:25:16 Nanley Chery  wrote:
> > 
> > On Wed, Apr 25, 2018 at 04:50:11PM -0700, Jason Ekstrand wrote:
> > On Tue, Apr 24, 2018 at 5:48 PM, Nanley Chery  wrote:
> > 
> 
> Your email client dropped the quotes :/ Thankfully, gmail can pick out
> the diff.
> 
> > Determine the predicate for updating the indirect depth value in the
> > loop which inspects whether or not we need to resolve any slices.
> > ---
> > src/mesa/drivers/dri/i965/brw_clear.c | 43 +-
> > -
> > 1 file changed, 16 insertions(+), 27 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
> > b/src/mesa/drivers/dri/i965/brw_clear.c
> > index 6521141d7f6..e372d28926e 100644
> > --- a/src/mesa/drivers/dri/i965/brw_clear.c
> > +++ b/src/mesa/drivers/dri/i965/brw_clear.c
> > @@ -108,7 +108,6 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > struct intel_mipmap_tree *mt = depth_irb->mt;
> > struct gl_renderbuffer_attachment *depth_att =
> > >Attachment[BUFFER_DEPTH];
> > const struct gen_device_info *devinfo = >screen->devinfo;
> > -   bool same_clear_value = true;
> > 
> > if (devinfo->gen < 6)
> > return false;
> > @@ -174,9 +173,16 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > const uint32_t num_layers = depth_att->Layered ?
> > depth_irb->layer_count : 1;
> > 
> > /* If we're clearing to a new clear value, then we need to resolve any
> > clear
> > -* flags out of the HiZ buffer into the real depth buffer.
> > +* flags out of the HiZ buffer into the real depth buffer and update
> > the
> > +* miptree's clear value.
> > */
> > if (mt->fast_clear_color.f32[0] != clear_value) {
> > +  /* BLORP updates the indirect clear color buffer when we do fast
> > clears.
> > +   * If we won't do a fast clear, we'll have to update it ourselves.
> > Start
> > +   * off assuming we won't perform a fast clear.
> > +   */
> > +  bool blorp_will_update_indirect_color = false;
> > 
> > This boolean is rather awkward.
> > 
> > Why's that?
> > 
> > It does have a clear meaning and it does what it says it does.  However,
> > it's not that obvious of a thing to work with compared to "did we do a
> > clear?"
> > 
> > 
> > +
> > for (uint32_t level = mt->first_level; level <= mt->last_level;
> > level++) {
> > if (!intel_miptree_level_has_hiz(mt, level))
> > continue;
> > @@ -184,16 +190,20 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > const unsigned level_layers = brw_get_num_logical_layers(mt,
> > level);
> > 
> > for (uint32_t layer = 0; layer < level_layers; layer++) {
> > +const enum isl_aux_state aux_state =
> > +   intel_miptree_get_aux_state(mt, level, layer);
> > +
> > if (level == depth_irb->mt_level &&
> > layer >= depth_irb->mt_layer &&
> > layer < depth_irb->mt_layer + num_layers) {
> > +
> > +   if (aux_state != ISL_AUX_STATE_CLEAR)
> > +  blorp_will_update_indirect_color = true;
> > 
> > Putting this here separates the detection of whether or not we are doing a
> > fast clear (and therefore don't need to set the clear color) even further
> > from where we do the clear and use this value than it was previously.
> > 
> > 
> 
> Sure.
> 
> > +
> > /* We're going to clear this layer anyway.  Leave it
> > alone. */
> > continue;
> > }
> > 
> > -enum isl_aux_state aux_state =
> > -   intel_miptree_get_aux_state(mt, level, layer);
> > -
> > if (aux_state != ISL_AUX_STATE_CLEAR &&
> > aux_state != ISL_AUX_STATE_COMPRESSED_CLEAR) {
> > /* This slice doesn't have any fast-cleared bits. */
> > @@ -214,29 +224,8 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > }
> > 
> > intel_miptree_set_depth_clear_value(brw, mt, clear_value);
> > -  same_clear_value = false;
> > -   }
> > -
> > -   bool need_clear = false;
> > -   for (unsigned a = 0; a < num_layers; a++) {
> > -  enum isl_aux_state aux_state =
> > - intel_miptree_get_aux_state(mt, depth_irb->mt_level,
> > - depth_irb->mt_layer + a);
> > -
> > -  if (aux_state != ISL_AUX_STATE_CLEAR) {
> > - need_clear = true;
> > - break;
> > -  }
> > -   }
> > -
> > -   if (!need_clear) {
> > -  if (!same_clear_value) {
> > - /* BLORP updates the indirect clear color buffer when performing
> > a
> > -  * fast clear. Since we are skipping the fast clear here, we
> > need to
> > -  * do the update ourselves.
> > -  */
> > +  if (!blorp_will_update_indirect_color)
> > intel_miptree_update_indirect_color(brw, mt);
> > -  }
> > 
> > I think we can do this even better.  We could do
> > 
> > bool blorp_updated_indirect_clear_color = false;
> > 
> > and then set it to true if we call intel_hiz_exec below.  Then, after the
> > loop 

Re: [Mesa-dev] [PATCH v2 4/5] i965/clear: Simplify updating the indirect depth value

[Nanley Chery]

On Wed, Apr 25, 2018 at 08:53:36PM -0400, Jason Ekstrand wrote:
> 
> 
> On April 25, 2018 20:25:16 Nanley Chery  wrote:
> 
> On Wed, Apr 25, 2018 at 04:50:11PM -0700, Jason Ekstrand wrote:
> On Tue, Apr 24, 2018 at 5:48 PM, Nanley Chery  wrote:
> 

Your email client dropped the quotes :/ Thankfully, gmail can pick out
the diff.

> Determine the predicate for updating the indirect depth value in the
> loop which inspects whether or not we need to resolve any slices.
> ---
> src/mesa/drivers/dri/i965/brw_clear.c | 43 +-
> -
> 1 file changed, 16 insertions(+), 27 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
> b/src/mesa/drivers/dri/i965/brw_clear.c
> index 6521141d7f6..e372d28926e 100644
> --- a/src/mesa/drivers/dri/i965/brw_clear.c
> +++ b/src/mesa/drivers/dri/i965/brw_clear.c
> @@ -108,7 +108,6 @@ brw_fast_clear_depth(struct gl_context *ctx)
> struct intel_mipmap_tree *mt = depth_irb->mt;
> struct gl_renderbuffer_attachment *depth_att =
> >Attachment[BUFFER_DEPTH];
> const struct gen_device_info *devinfo = >screen->devinfo;
> -   bool same_clear_value = true;
> 
> if (devinfo->gen < 6)
> return false;
> @@ -174,9 +173,16 @@ brw_fast_clear_depth(struct gl_context *ctx)
> const uint32_t num_layers = depth_att->Layered ?
> depth_irb->layer_count : 1;
> 
> /* If we're clearing to a new clear value, then we need to resolve any
> clear
> -* flags out of the HiZ buffer into the real depth buffer.
> +* flags out of the HiZ buffer into the real depth buffer and update
> the
> +* miptree's clear value.
> */
> if (mt->fast_clear_color.f32[0] != clear_value) {
> +  /* BLORP updates the indirect clear color buffer when we do fast
> clears.
> +   * If we won't do a fast clear, we'll have to update it ourselves.
> Start
> +   * off assuming we won't perform a fast clear.
> +   */
> +  bool blorp_will_update_indirect_color = false;
> 
> This boolean is rather awkward.
> 
> Why's that?
> 
> It does have a clear meaning and it does what it says it does.  However,
> it's not that obvious of a thing to work with compared to "did we do a
> clear?"
> 
> 
> +
> for (uint32_t level = mt->first_level; level <= mt->last_level;
> level++) {
> if (!intel_miptree_level_has_hiz(mt, level))
> continue;
> @@ -184,16 +190,20 @@ brw_fast_clear_depth(struct gl_context *ctx)
> const unsigned level_layers = brw_get_num_logical_layers(mt,
> level);
> 
> for (uint32_t layer = 0; layer < level_layers; layer++) {
> +const enum isl_aux_state aux_state =
> +   intel_miptree_get_aux_state(mt, level, layer);
> +
> if (level == depth_irb->mt_level &&
> layer >= depth_irb->mt_layer &&
> layer < depth_irb->mt_layer + num_layers) {
> +
> +   if (aux_state != ISL_AUX_STATE_CLEAR)
> +  blorp_will_update_indirect_color = true;
> 
> Putting this here separates the detection of whether or not we are doing a
> fast clear (and therefore don't need to set the clear color) even further
> from where we do the clear and use this value than it was previously.
> 
> 

Sure.

> +
> /* We're going to clear this layer anyway.  Leave it
> alone. */
> continue;
> }
> 
> -enum isl_aux_state aux_state =
> -   intel_miptree_get_aux_state(mt, level, layer);
> -
> if (aux_state != ISL_AUX_STATE_CLEAR &&
> aux_state != ISL_AUX_STATE_COMPRESSED_CLEAR) {
> /* This slice doesn't have any fast-cleared bits. */
> @@ -214,29 +224,8 @@ brw_fast_clear_depth(struct gl_context *ctx)
> }
> 
> intel_miptree_set_depth_clear_value(brw, mt, clear_value);
> -  same_clear_value = false;
> -   }
> -
> -   bool need_clear = false;
> -   for (unsigned a = 0; a < num_layers; a++) {
> -  enum isl_aux_state aux_state =
> - intel_miptree_get_aux_state(mt, depth_irb->mt_level,
> - depth_irb->mt_layer + a);
> -
> -  if (aux_state != ISL_AUX_STATE_CLEAR) {
> - need_clear = true;
> - break;
> -  }
> -   }
> -
> -   if (!need_clear) {
> -  if (!same_clear_value) {
> - /* BLORP updates the indirect clear color buffer when performing
> a
> -  * fast clear. Since we are skipping the fast clear here, we
> need to
> -  * do the update ourselves.
> -  */
> +  if (!blorp_will_update_indirect_color)
> intel_miptree_update_indirect_color(brw, mt);
> -  }
> 
> I think we can do this even better.  We could do
> 
> bool blorp_updated_indirect_clear_color = false;
> 
> and then set it to true if we call intel_hiz_exec below.  Then, after the
> loop below we would do
> 
> if (!blorp_updated_indirect_clear_color)
> intel_miptree_update_indirect_color(brw, mt);
> 
> after we've done the clears.
> 
> I had something like that originally and I think that solution would
> have marginally better performance. I went with doing it this way
> because it allows us to:
> 
> * Do all the clear color updates 

Re: [Mesa-dev] [PATCH] meson: fix race condition revealed by using 0.44

[Emil Velikov]

On 26 April 2018 at 18:24, Dylan Baker  wrote:
> It turns out that the blocking target we had was hiding some race
> conditions in the anv driver with anv_extensions.h generation, we should
> fix those.
>
anv_entrypoints[0] is the first output of the anv_entrypoints custom_target.
Aka it's effectively the same as anv_extensions_h, isn't it?

Please add a brief description of the race. Can we have a meson bug
number inline?

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

Re: [Mesa-dev] [PATCH] egl/android: remove flink name support

[Rob Herring]

On Thu, Apr 26, 2018 at 11:56 AM, Emil Velikov  wrote:
> On 26 April 2018 at 03:30, Chih-Wei Huang  wrote:
>> 2018-04-25 19:55 GMT+08:00 Robert Foss :
>>> Hey Emil & Chih-Wei,
>>>
>>> On 04/24/2018 01:59 PM, Emil Velikov wrote:

 On 24 April 2018 at 12:28, Emil Velikov  wrote:

> On the topic of keeping the old code behind a #define or just removing
> it, it'll be great if interested parties can reach a consensus.
>
 Actually one can simply drop this code and drm_gralloc users can add a
 drm_ioctl_permit() hack.
 Namely: loosen the restrictions to consider render nodes identical to
 primary/card ones.

 Yes, it's a nasty hack, yet no worse than the existing one that
 removes the auth :-\
>>>
>>> I'm fine with adding a #define.
>>> Chih-Wei: Do you have any objections?
>>
>> "keeping the old code behind a #define"?
>> Sounds good to me. Thank you!
>
> Having a look at the Android-x86 kernel:
> The current hack in the permission check (see drm_ioctl_permit in [1])
> effectively threats render nodes and primary nodes as the same thing.
>
> Thus, on top of the current patch the !dri2_dpy->is_render_node check
> should be removed, for Android-x86.
> There's no need to keep the flink code around ;-)

Except I don't think drm_gralloc fills in a dma-buf fd in it's
handle... There was an AOSP version that did IIRC.

Or maybe I'm missing something.

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

[Mesa-dev] [PATCH] meson: fix race condition revealed by using 0.44

[Dylan Baker]

It turns out that the blocking target we had was hiding some race
conditions in the anv driver with anv_extensions.h generation, we should
fix those.

CC: Scott D Phillips 
CC: Mark Janes 
Fixes: 92550d9b16d2b295bdac087f31b1fd6d0f808e02
   ("meson: remove workaround for custom target creating .h and .c files")
Signed-off-by: Dylan Baker 
---
 src/intel/vulkan/meson.build | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index 06acc78391f..f20a8a54c9b 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -1,4 +1,4 @@
-# Copyright © 2017 Intel Corporation
+# Copyright © 2017-2018 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
@@ -96,7 +96,7 @@ foreach g : [['70', ['gen7_cmd_buffer.c']], ['75', 
['gen7_cmd_buffer.c']],
   _gen = g[0]
   libanv_gen_libs += static_library(
 'libanv_gen@0@'.format(_gen),
-[anv_gen_files, g[1], anv_entrypoints[0]],
+[anv_gen_files, g[1], anv_entrypoints[0], anv_extensions_h],
 include_directories : [
   inc_common, inc_compiler, inc_drm_uapi, inc_intel, inc_vulkan_util,
   inc_vulkan_wsi,
@@ -220,7 +220,7 @@ if with_tests
   'anv_@0@'.format(t),
   executable(
 t,
-['tests/@0@.c'.format(t), anv_entrypoints[0]],
+['tests/@0@.c'.format(t), anv_entrypoints[0], anv_extensions_h],
 link_with : libvulkan_intel_test,
 dependencies : [dep_libdrm, dep_thread, dep_m, dep_valgrind],
 include_directories : [
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH 02/10] dri_interface: add __DRI_IMAGE_TRANSFER_USER_STRIDE

[Marek Olšák]

Gurchetan, can you confirm that the stride returned at alloc() is only used
for CPU access and not for display programming?

Thanks,
Marek

On Wed, Apr 25, 2018 at 11:23 PM, Marek Olšák  wrote:

> Why would you want to modify it? It's exactly what you get when you map
> it, but that stride can't be used for modesetting.
>
> Marek
>
>
> On Wed, Apr 25, 2018 at 11:14 PM, Gurchetan Singh <
> gurchetansi...@chromium.org> wrote:
>
>> That sounds fine to me.  We can just modify the stride after
>> dri_bo_create(..).
>>
>> On Wed, Apr 25, 2018 at 7:30 PM, Marek Olšák  wrote:
>> > On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh
>> >  wrote:
>> >>
>> >> On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák  wrote:
>> >> > From: Nicolai Hähnle 
>> >> >
>> >> > Allow the caller to specify the row stride (in bytes) with which an
>> >> > image
>> >> > should be mapped. Note that completely ignoring USER_STRIDE is a
>> valid
>> >> > implementation of mapImage.
>> >> >
>> >> > This is horrible API design. Unfortunately, cros_gralloc does indeed
>> >> > have
>> >> > a horrible API design -- in that arbitrary images should be allowed
>> to
>> >> > be
>> >> > mapped with the stride that a linear image of the same width would
>> have.
>> >>
>> >> Yes, unfortunately the gralloc API doesn't return the stride when
>> >> (*lock) is called.  However, the stride is returned during (*alloc).
>> >> Currently, for the dri backend, minigbm uses
>> >> __DRI_IMAGE_ATTRIB_STRIDE to compute the pixel stride given to
>> >> Android.
>> >>
>> >> Is AMD seeing problems with the current approach (I haven't seen any
>> >> bugs filed for this issue)?
>> >>
>> >> Another possible solution is to call mapImage()/unmapImage right after
>> >> allocating the image, and use the stride returned by mapImage() to
>> >> compute the pixel stride.  That could also fix whatever bugs AMD is
>> >> seeing.
>> >
>> >
>> > Thanks. You cleared it up to me. It looks like that everything we've
>> been
>> > told so far is BS. This series isn't needed.
>> >
>> > The solution is to do this in the amdgpu minigbm backend at alloc time:
>> >stride = align(width * Bpp, 64);
>> >
>> > Later chips should change that to:
>> >stride = align(width * Bpp, 256);
>> >
>> > No querying needed. What do you think?
>> >
>> > Marek
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106157] [Tracker] Mesa 18.1 release tracker

[bugzilla-daemon]

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

Mark Janes  changed:

   What|Removed |Added

 Depends on||105906


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=105906
[Bug 105906] [DRI3] Compiz segfaults in intel_destroy_image()
-- 
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 09/10] gallium: add PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT

[Marek Olšák]

On Thu, Apr 26, 2018 at 6:27 AM, Nicolai Hähnle  wrote:

> On 25.04.2018 23:29, Roland Scheidegger wrote:
>
>> Am 25.04.2018 um 23:16 schrieb Marek Olšák:
>>
>>> From: Marek Olšák 
>>>
>>> ---
>>>   src/gallium/docs/source/screen.rst   | 3 +++
>>>   src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
>>>   src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
>>>   src/gallium/drivers/i915/i915_screen.c   | 1 +
>>>   src/gallium/drivers/llvmpipe/lp_screen.c | 1 +
>>>   src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 1 +
>>>   src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 1 +
>>>   src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 1 +
>>>   src/gallium/drivers/r300/r300_screen.c   | 1 +
>>>   src/gallium/drivers/r600/r600_pipe.c | 1 +
>>>   src/gallium/drivers/radeonsi/si_get.c| 3 +++
>>>   src/gallium/drivers/softpipe/sp_screen.c | 1 +
>>>   src/gallium/drivers/svga/svga_screen.c   | 1 +
>>>   src/gallium/drivers/swr/swr_screen.cpp   | 1 +
>>>   src/gallium/drivers/vc4/vc4_screen.c | 1 +
>>>   src/gallium/drivers/vc5/vc5_screen.c | 1 +
>>>   src/gallium/drivers/virgl/virgl_screen.c | 1 +
>>>   src/gallium/include/pipe/p_defines.h | 1 +
>>>   18 files changed, 22 insertions(+)
>>>
>>> diff --git a/src/gallium/docs/source/screen.rst
>>> b/src/gallium/docs/source/screen.rst
>>> index 3837360fb40..7cc6d378306 100644
>>> --- a/src/gallium/docs/source/screen.rst
>>> +++ b/src/gallium/docs/source/screen.rst
>>> @@ -413,20 +413,23 @@ The integer capabilities:
>>> supported priority levels.  A driver that does not support
>>> prioritized
>>> contexts can return 0.
>>>   * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling
>>> semaphores
>>> using fence_server_signal().
>>>   * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that
>>> must be
>>> set when binding that buffer as constant buffer 0. If the buffer
>>> doesn't have
>>> those bits set, pipe_context::set_constant_buffer(.., 0, ..) is
>>> ignored
>>> by the driver, and the driver can throw assertion failures.
>>>   * ``PIPE_CAP_PACKED_UNIFORMS``: True if the driver supports packed
>>> uniforms
>>> as opposed to padding to vec4s.
>>> +* ``PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT``: The minimum supported
>>> alignment of
>>> +  the user_stride parameter of transfer_map. If 0, the user-specified
>>> stride
>>> +  is unsupported and the user_stride parameter is ignored.
>>>
>> Does this really make a whole lot of sense? What if the minimum stride
>> natively supported isn't always the same? What happens if the stride
>> requested is larger than what the hw usually would do, does that need to
>> be honored as well - it certainly looks like the cap query here wouldn't
>> answer that?
>>
>
> It really doesn't make much sense, but unfortunately the ChromeOS gralloc
> is just completely braindead. It basically assumes that tilings don't
> exist. You have to give it a stride when a texture is allocated, and that
> is the stride that has to be there whenever the texture is mapped for a
> transfer.
>
So we give it the right stride at allocation: aligned to 64 or 256.

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

Re: [Mesa-dev] [PATCH] st/mesa: fix missing setting of _ElementSize in new_draw_rasterpos_stage

[Brian Paul]

Reviewed-by: Brian Paul 

On 04/26/2018 10:29 AM, Charmaine Lee wrote:

With this patch, _ElementSize is initialized along with the rest
of the vertex array attributes in new_draw_rasterpos_stage().
This fixes a crash in st_pipe_vertex_format() when running
topogun-1.06-orc-84k-resize trace file with VMware svga driver.
---
  src/mesa/state_tracker/st_cb_rasterpos.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/src/mesa/state_tracker/st_cb_rasterpos.c 
b/src/mesa/state_tracker/st_cb_rasterpos.c
index 4e5417b..b73d543 100644
--- a/src/mesa/state_tracker/st_cb_rasterpos.c
+++ b/src/mesa/state_tracker/st_cb_rasterpos.c
@@ -40,6 +40,7 @@
  #include "main/macros.h"
  #include "main/feedback.h"
  #include "main/rastpos.h"
+#include "glformats.h"
  
  #include "st_context.h"

  #include "st_atom.h"
@@ -182,6 +183,7 @@ new_draw_rastpos_stage(struct gl_context *ctx, struct 
draw_context *draw)
  {
 struct rastpos_stage *rs = ST_CALLOC_STRUCT(rastpos_stage);
 GLuint i;
+   GLuint elementSize;
  
 rs->stage.draw = draw;

 rs->stage.next = NULL;
@@ -196,12 +198,15 @@ new_draw_rastpos_stage(struct gl_context *ctx, struct 
draw_context *draw)
  
 rs->binding.Stride = 0;

 rs->binding.BufferObj = NULL;
+
+   elementSize = _mesa_bytes_per_vertex_attrib(4, GL_FLOAT);
 for (i = 0; i < ARRAY_SIZE(rs->array); i++) {
rs->attrib[i].Size = 4;
rs->attrib[i].Type = GL_FLOAT;
rs->attrib[i].Format = GL_RGBA;
rs->attrib[i].Ptr = (GLubyte *) ctx->Current.Attrib[i];
rs->attrib[i].Normalized = GL_TRUE;
+  rs->attrib[i]._ElementSize = elementSize;
rs->array[i].BufferBinding = >binding;
rs->array[i].VertexAttrib = >attrib[i];
 }



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

Re: [Mesa-dev] [Mesa-stable] [PATCH v2] travis: update libva required version

[Emil Velikov]

On 25 April 2018 at 14:44, Juan A. Suarez Romero  wrote:
> On Wed, 2018-04-25 at 13:54 +0100, Emil Velikov wrote:
>> On 24 April 2018 at 08:49, Juan A. Suarez Romero  wrote:
>> > On Fri, 2018-04-20 at 16:42 +0200, Juan A. Suarez Romero wrote:
>> > > Commit fa328456e8f29 added VP9 config support, but this needs a newer
>> > > libva version, 1.7.0 or above.
>> > >
>> > > Fixes: fa328456e8f ("st/va: add VP9 config to enable profile2")
>> >
>> > Besides requesting R-B, CCing to @stable, as this fixes 18.1 build in 
>> > Travis CI.
>> >
>>
>> The Fixes should be enough but stable@ won't hurt.
>>
>> Seems like we should also bump the versions in configure.ac
>> (LIBVA_REQUIRED) and meson.build, right?
>> Can be done as a follow-up, though. As-is patch is
>
> Thing is, I did in a first version, but then I reverted that change. The 
> reason
> is that LIBVA_REQUIRED contains the expected VA API version to interact with 
> the
> library, but in this case we are not changing the functions we use, and thus 
> we
> are fine with keeping the same API version.
>
Not sure I parse this.

Obviously the difference between the tarball version and the one
advertised in the pkg-config file is a bit confusing but they both
effectively indicate the same thing.

As illustrated with this patch - we need the newer version, otherwise
it simply wont build.

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

[Mesa-dev] [PATCH] st/mesa: fix missing setting of _ElementSize in new_draw_rasterpos_stage

[Charmaine Lee]

With this patch, _ElementSize is initialized along with the rest
of the vertex array attributes in new_draw_rasterpos_stage().
This fixes a crash in st_pipe_vertex_format() when running
topogun-1.06-orc-84k-resize trace file with VMware svga driver.
---
 src/mesa/state_tracker/st_cb_rasterpos.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/state_tracker/st_cb_rasterpos.c 
b/src/mesa/state_tracker/st_cb_rasterpos.c
index 4e5417b..b73d543 100644
--- a/src/mesa/state_tracker/st_cb_rasterpos.c
+++ b/src/mesa/state_tracker/st_cb_rasterpos.c
@@ -40,6 +40,7 @@
 #include "main/macros.h"
 #include "main/feedback.h"
 #include "main/rastpos.h"
+#include "glformats.h"
 
 #include "st_context.h"
 #include "st_atom.h"
@@ -182,6 +183,7 @@ new_draw_rastpos_stage(struct gl_context *ctx, struct 
draw_context *draw)
 {
struct rastpos_stage *rs = ST_CALLOC_STRUCT(rastpos_stage);
GLuint i;
+   GLuint elementSize;
 
rs->stage.draw = draw;
rs->stage.next = NULL;
@@ -196,12 +198,15 @@ new_draw_rastpos_stage(struct gl_context *ctx, struct 
draw_context *draw)
 
rs->binding.Stride = 0;
rs->binding.BufferObj = NULL;
+
+   elementSize = _mesa_bytes_per_vertex_attrib(4, GL_FLOAT);
for (i = 0; i < ARRAY_SIZE(rs->array); i++) {
   rs->attrib[i].Size = 4;
   rs->attrib[i].Type = GL_FLOAT;
   rs->attrib[i].Format = GL_RGBA;
   rs->attrib[i].Ptr = (GLubyte *) ctx->Current.Attrib[i];
   rs->attrib[i].Normalized = GL_TRUE;
+  rs->attrib[i]._ElementSize = elementSize;
   rs->array[i].BufferBinding = >binding;
   rs->array[i].VertexAttrib = >attrib[i];
}
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] egl/android: remove flink name support

[Emil Velikov]

On 26 April 2018 at 03:30, Chih-Wei Huang  wrote:
> 2018-04-25 19:55 GMT+08:00 Robert Foss :
>> Hey Emil & Chih-Wei,
>>
>> On 04/24/2018 01:59 PM, Emil Velikov wrote:
>>>
>>> On 24 April 2018 at 12:28, Emil Velikov  wrote:
>>>
 On the topic of keeping the old code behind a #define or just removing
 it, it'll be great if interested parties can reach a consensus.

>>> Actually one can simply drop this code and drm_gralloc users can add a
>>> drm_ioctl_permit() hack.
>>> Namely: loosen the restrictions to consider render nodes identical to
>>> primary/card ones.
>>>
>>> Yes, it's a nasty hack, yet no worse than the existing one that
>>> removes the auth :-\
>>
>> I'm fine with adding a #define.
>> Chih-Wei: Do you have any objections?
>
> "keeping the old code behind a #define"?
> Sounds good to me. Thank you!

Having a look at the Android-x86 kernel:
The current hack in the permission check (see drm_ioctl_permit in [1])
effectively threats render nodes and primary nodes as the same thing.

Thus, on top of the current patch the !dri2_dpy->is_render_node check
should be removed, for Android-x86.
There's no need to keep the flink code around ;-)

-Emil

[1] 
https://osdn.net/projects/android-x86/scm/git/kernel/blobs/kernel-4.14/drivers/gpu/drm/drm_ioctl.c
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] dri3: Prevent multiple freeing of buffers.

[Michel Dänzer]

On 2018-04-10 09:44 AM, Sergii Romantsov wrote:
> Commit 3160cb86aa92 adds optimization with flag 'reallocate'.
> Processing of flag causes buffers freeing while pointer
> is still hold in caller stack and than again used to be freed.
> 
> Fixes: 3160cb86aa92 "egl/x11: Re-allocate buffers if format is suboptimal"
> 
> v2:
>  used flag 'busy' instead of introducing new one.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105906
> Signed-off-by: Sergii Romantsov 
> Tested-by: Andriy Khulap 
> ---
>  src/loader/loader_dri3_helper.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
> index fe17df1..a934db1 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -1688,6 +1688,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> (buffer_type == loader_dri3_buffer_front && 
> draw->have_fake_front))
>&& buffer) {
>  
> + buffer->busy = true;
>   /* Fill the new buffer with data from an old buffer */
>   dri3_fence_await(draw->conn, draw, buffer);
>   if (!loader_dri3_blit_image(draw,

This seems a bit of a hack. Will this always be cleared again, in
particular if it's the fake front buffer?


> @@ -1731,6 +1732,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
>draw->buffers[buf_id] = buffer;
> }
> dri3_fence_await(draw->conn, draw, buffer);
> +   buffer = draw->buffers[buf_id];

This should be something like

   if (buffer_type == loader_dri3_buffer_back) {
  buf_id = dri3_find_back(draw);

  if (buf_id < 0)
 return NULL;
   }
   buffer = draw->buffers[buf_id];

to get the now-current back buffer.


> @@ -1744,7 +1746,8 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> if (buffer_type == loader_dri3_buffer_back &&
> draw->cur_blit_source != -1 &&
> draw->buffers[draw->cur_blit_source] &&
> -   buffer != draw->buffers[draw->cur_blit_source]) {
> +   buffer != draw->buffers[draw->cur_blit_source] &&
> +   buffer != NULL) {
>  
>struct loader_dri3_buffer *source = 
> draw->buffers[draw->cur_blit_source];
>  
> 

With the above, this NULL guard isn't needed.


-- 
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 99987] Mesa 13+ breaks Xvnc (and similar X servers)

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #23 from Emil Velikov  ---
It's a distribution policy to manage the symlink - the same way they did
libGL.so in the past.

Perhaps one day we'll get a truly vendor agnostic libGLX_indirect.so, but until
then one has to tweak it based on their needs.

As alluded before - this isn't really a Mesa bug :-\

-- 
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] [ANNOUNCE] Mesa 18.0.2 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 18.0.2 is now available. Currently we have:
 - 18 queued
 - 1 nominated (outstanding)
 - and 0 rejected patches

The current queue consists of:

A couple of fixes for Meson that solves some problems regarding building tests 
and installation.

A couple of fixes in state tracker / DRI that was causing crashes in QtCreator 
and Firefox, among other problems.

A couple of fixes for GFX9, that solves a hang in the driver, and a problem 
with buffer views.

SVGA gets also a patch to fix incorrect advertizing of EGL_KHR_gl_colorspace 
extension.

Etnaviv gets a fix for swizzled texture formats.

Intel drivers get also several patches.

RADV gets a patch to solve a problem of lot of games complaining about not 
having enough memory.

Take a look at section "Mesa stable queue" for more information.


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 18.0.2 this Saturday (28th April), around or shortly after 
16:00
GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit 5edd3192e7f3388ff36236010995401569e9250f
Author: Bas Nieuwenhuizen 

ac/nir: Make the GFX9 buffer size fix apply to image loads/atomics too.

(cherry picked from commit b0e3a9b19f16ed1ce4c1f150718b0c0f0e6111f6)



Cheers,

J.A.


Mesa stable queue
-

Nominated (1)
==

Boyuan Zhang(1):
   deba56accf radeon/vcn: fix mpeg4 msg buffer settings


Queued (18)
===

Bas Nieuwenhuizen (2):
  ac/nir: Make the GFX9 buffer size fix apply to image loads/atomics too.
  radv: Mark GTT memory as device local for APUs.

Dylan Baker (2):
  bin/install_megadrivers: fix DESTDIR and -D*-path
  meson: don't build classic mesa tests without dri_drivers

Ian Romanick (1):
  intel/compiler: Add scheduler deps for instructions that implicitly read 
g0

Jason Ekstrand (1):
  i965/fs: Return mlen * 8 for size_read() for INTERPOLATE_AT_*

Johan Klokkhammer Helsing (1):
  st/dri: Fix dangling pointer to a destroyed dri_drawable

Juan A. Suarez Romero (1):
  travis: radv needs LLVM 4.0

Kenneth Graunke (1):
  i965: Fix shadow batches to be the same size as the real BO.

Lionel Landwerlin (1):
  anv: fix number of planes for depth & stencil

Lucas Stach (1):
  etnaviv: fix texture_format_needs_swiz

Marek Olšák (3):
  radeonsi/gfx9: fix a hang with an empty first IB
  glsl_to_tgsi: try harder to lower unsupported ir_binop_vector_extract
  Revert "st/dri: Fix dangling pointer to a destroyed dri_drawable"

Samuel Pitoiset (2):
  radv: fix scissor computation when using half-pixel viewport offset
  radv/winsys: allow to submit up to 4 IBs for chips without chaining

Thomas Hellstrom (1):
  svga: Fix incorrect advertizing of EGL_KHR_gl_colorspace

Timothy Arceri (1):
  mesa: free debug messages when destroying the debug state


Rejected (0)
=


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

Re: [Mesa-dev] [PATCH 2/2] spirv: convert the offset and count operands for bitfield ops to uint32

[Jason Ekstrand]

On Thu, Apr 26, 2018 at 2:24 AM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:

> SPIR-V allows to define the shift operand for shift opcodes with
> a bit-size different than 32 bits, but in NIR the opcodes have
> that limitation. As agreed in the mailing list, this patch adds
> a conversion to 32 bits to fix this.
>
> For more info, see:
>
> https://lists.freedesktop.org/archives/mesa-dev/2018-April/193026.html
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/compiler/spirv/vtn_alu.c | 48 ++
> ++
>  1 file changed, 48 insertions(+)
>
> diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
> index 6f3b82cd5c3..a1654b20273 100644
> --- a/src/compiler/spirv/vtn_alu.c
> +++ b/src/compiler/spirv/vtn_alu.c
> @@ -640,6 +640,54 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
>break;
> }
>
> +   case SpvOpBitFieldInsert: {
> +  if (src[2]->bit_size != 32) {
> + /* Convert the Shift operand to 32 bits, which is the bitsize
> +  * supported by the NIR instruction. See discussion here:
> +  *
> +  * https://lists.freedesktop.org/archives/mesa-dev/2018-April/
> 193026.html
> +  */
> + src[2] = nir_build_alu(>nb, nir_op_u2u32, src[2], NULL, NULL,
> NULL);
> +  }
> +  if (src[3]->bit_size != 32) {
> + /* Convert the Shift operand to 32 bits, which is the bitsize
> +  * supported by the NIR instruction. See discussion here:
> +  *
> +  * https://lists.freedesktop.org/archives/mesa-dev/2018-April/
> 193026.html
> +  */
> + src[3] = nir_build_alu(>nb, nir_op_u2u32, src[3], NULL, NULL,
> NULL);
> +  }
> +  val->ssa->def = nir_build_alu(>nb, nir_op_bitfield_insert,
> src[0], src[1], src[2], src[3]);
>

Just use nir_bitfield_insert here


> +  break;
> +   }
> +
> +   case SpvOpBitFieldSExtract:
> +   case SpvOpBitFieldUExtract: {
> +  bool swap;
> +  unsigned src_bit_size = glsl_get_bit_size(vtn_src[0]->type);
> +  unsigned dst_bit_size = glsl_get_bit_size(type);
> +  nir_op op = vtn_nir_alu_op_for_spirv_opcode(b, opcode, ,
> +  src_bit_size,
> dst_bit_size);
> +  if (src[1]->bit_size != 32) {
> + /* Convert the Shift operand to 32 bits, which is the bitsize
> +  * supported by the NIR instruction. See discussion here:
> +  *
> +  * https://lists.freedesktop.org/archives/mesa-dev/2018-April/
> 193026.html
> +  */
> + src[1] = nir_build_alu(>nb, nir_op_u2u32, src[1], NULL, NULL,
> NULL);
> +  }
> +  if (src[2]->bit_size != 32) {
> + /* Convert the Shift operand to 32 bits, which is the bitsize
> +  * supported by the NIR instruction. See discussion here:
> +  *
> +  * https://lists.freedesktop.org/archives/mesa-dev/2018-April/
> 193026.html
> +  */
> + src[2] = nir_build_alu(>nb, nir_op_u2u32, src[2], NULL, NULL,
> NULL);
> +  }
> +  val->ssa->def = nir_build_alu(>nb, op, src[0], src[1], src[2],
> src[3]);
> +  break;
>

I'm wondering if we don't want to just do something such as

for (unsigned i = 0; i < nir_op_infos[op].num_inputs; i++) {
   src_bit_size =
nir_alu_type_get_get_type_size(nir_op_infos[op].input_types[i]);
   if (src_bit_size && src_bit_size != src[i]->bit_size) {
  /* Comment goes here */
  assert(src_bit_size == 32);
  assert(op == nir_op_ushr || op == ...);
  src[i] = nir_u2u32(>nb, src[i]);
   }
}

And then we can cover all of these cases in one go.


> +   }
> +
> case SpvOpShiftLeftLogical:
> case SpvOpShiftRightArithmetic:
> case SpvOpShiftRightLogical: {
> --
> 2.14.1
>
> ___
> 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] [Bug 106232] LLVM unit tests have error in random number handling

[bugzilla-daemon]

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

--- Comment #4 from Roland Scheidegger  ---
Created attachment 139140
  --> https://bugs.freedesktop.org/attachment.cgi?id=139140=edit
patch to fix bogus random numbers

Ok this patch should fix it.
Non-normalized signed ints had completely bogus ref values, which I fixed as
well. (As a side note, for things like si32x4 -> si16x8 or the unsigned
equivalent, the probability that we hit something which _isn't_ clamped is very
low - for si32x4 -> si8x16 it's not even in part-per-million range.)

But we can't apply it until we fix the remaining failures. They don't actually
look too bad, all involving signed normalized numbers - all look like rounding
issues, we expect a max error of 1 but can get an error of 2. Might be due to
the snorm conversion formulas we (have to) use even as indeed it looks like we
get these errors only for negative numbers < -0.5 or so, but I'm not entirely
sure what happens.

-- 
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] st/va: Fix typos

[Leo Liu]

Hi Drew,

This patch along with your other patch are pushed.

Thanks for the help.

Leo


On 04/25/2018 11:55 AM, Leo Liu wrote:

Reviewed-by: Leo Liu 


On 2018-04-25 11:32 AM, Drew Davenport wrote:

s/attibute/attribute/
s/suface/surface/
---
  src/gallium/state_trackers/va/surface.c | 48 -
  1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c

index 8604136944..1dc4466560 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -525,9 +525,9 @@ vlVaQuerySurfaceAttributes(VADriverContextP ctx, 
VAConfigID config_id,

  }
    static VAStatus
-suface_from_external_memory(VADriverContextP ctx, vlVaSurface *surface,
-    VASurfaceAttribExternalBuffers 
*memory_attibute,
-    unsigned index, struct pipe_video_buffer 
*templat)
+surface_from_external_memory(VADriverContextP ctx, vlVaSurface 
*surface,
+ VASurfaceAttribExternalBuffers 
*memory_attribute,
+ unsigned index, struct 
pipe_video_buffer *templat)

  {
 vlVaDriver *drv;
 struct pipe_screen *pscreen;
@@ -539,21 +539,21 @@ suface_from_external_memory(VADriverContextP 
ctx, vlVaSurface *surface,

 pscreen = VL_VA_PSCREEN(ctx);
 drv = VL_VA_DRIVER(ctx);
  -   if (!memory_attibute || !memory_attibute->buffers ||
-   index > memory_attibute->num_buffers)
+   if (!memory_attribute || !memory_attribute->buffers ||
+   index > memory_attribute->num_buffers)
    return VA_STATUS_ERROR_INVALID_PARAMETER;
  -   if (surface->templat.width != memory_attibute->width ||
-   surface->templat.height != memory_attibute->height ||
-   memory_attibute->num_planes < 1)
+   if (surface->templat.width != memory_attribute->width ||
+   surface->templat.height != memory_attribute->height ||
+   memory_attribute->num_planes < 1)
    return VA_STATUS_ERROR_INVALID_PARAMETER;
  -   switch (memory_attibute->pixel_format) {
+   switch (memory_attribute->pixel_format) {
 case VA_FOURCC_RGBA:
 case VA_FOURCC_RGBX:
 case VA_FOURCC_BGRA:
 case VA_FOURCC_BGRX:
-  if (memory_attibute->num_planes != 1)
+  if (memory_attribute->num_planes != 1)
   return VA_STATUS_ERROR_INVALID_PARAMETER;
    break;
 default:
@@ -565,16 +565,16 @@ suface_from_external_memory(VADriverContextP 
ctx, vlVaSurface *surface,

 res_templ.last_level = 0;
 res_templ.depth0 = 1;
 res_templ.array_size = 1;
-   res_templ.width0 = memory_attibute->width;
-   res_templ.height0 = memory_attibute->height;
+   res_templ.width0 = memory_attribute->width;
+   res_templ.height0 = memory_attribute->height;
 res_templ.format = surface->templat.buffer_format;
 res_templ.bind = PIPE_BIND_SAMPLER_VIEW;
 res_templ.usage = PIPE_USAGE_DEFAULT;
   memset(, 0, sizeof(struct winsys_handle));
 whandle.type = DRM_API_HANDLE_TYPE_FD;
-   whandle.handle = memory_attibute->buffers[index];
-   whandle.stride = memory_attibute->pitches[index];
+   whandle.handle = memory_attribute->buffers[index];
+   whandle.stride = memory_attribute->pitches[index];
   resource = pscreen->resource_from_handle(pscreen, _templ, 
,

PIPE_HANDLE_USAGE_READ_WRITE);
@@ -629,7 +629,7 @@ vlVaCreateSurfaces2(VADriverContextP ctx, 
unsigned int format,
  VASurfaceAttrib *attrib_list, unsigned int 
num_attribs)

  {
 vlVaDriver *drv;
-   VASurfaceAttribExternalBuffers *memory_attibute;
+   VASurfaceAttribExternalBuffers *memory_attribute;
 struct pipe_video_buffer templat;
 struct pipe_screen *pscreen;
 int i;
@@ -655,7 +655,7 @@ vlVaCreateSurfaces2(VADriverContextP ctx, 
unsigned int format,

    return VA_STATUS_ERROR_INVALID_CONTEXT;
   /* Default. */
-   memory_attibute = NULL;
+   memory_attribute = NULL;
 memory_type = VA_SURFACE_ATTRIB_MEM_TYPE_VA;
 expected_fourcc = 0;
  @@ -687,7 +687,7 @@ vlVaCreateSurfaces2(VADriverContextP ctx, 
unsigned int format,

    (attrib_list[i].flags == VA_SURFACE_ATTRIB_SETTABLE)) {
   if (attrib_list[i].value.type != VAGenericValueTypePointer)
  return VA_STATUS_ERROR_INVALID_PARAMETER;
- memory_attibute = (VASurfaceAttribExternalBuffers 
*)attrib_list[i].value.value.p;
+ memory_attribute = (VASurfaceAttribExternalBuffers 
*)attrib_list[i].value.value.p;

    }
 }
  @@ -703,10 +703,10 @@ vlVaCreateSurfaces2(VADriverContextP ctx, 
unsigned int format,

 case VA_SURFACE_ATTRIB_MEM_TYPE_VA:
    break;
 case VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME:
-  if (!memory_attibute)
+  if (!memory_attribute)
   return VA_STATUS_ERROR_INVALID_PARAMETER;
  -  expected_fourcc = memory_attibute->pixel_format;
+  expected_fourcc = memory_attribute->pixel_format;
    break;
 default:
    assert(0);

[Mesa-dev] [Bug 106232] LLVM unit tests have error in random number handling

[bugzilla-daemon]

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

--- Comment #3 from Roland Scheidegger  ---
(In reply to Jose Fonseca from comment #2)
> It's been a long time, but I think Tom's right.  This was a thinko, and my
> intent was the opposite.
Ok that makes sense. With this code only reversing sign with signed type, we'd
still not test full unsigned range though for uint32 types (but not smaller
types), looking at this again.

> 
> 
> > And float range is only from 0 to 2.0f?
> 
> That's correct.  That's sufficient to exercise the clamping.
> 
> Remember that if we generated a range between 0 and a VERY_LARGE_NUMBER,
> then only 1/VERY_LARGE_NUMBER of the cases would actually be in the most
> interesting range of 0..1
Ok, I think the problem is we don't know what we're going to convert to. If we
actually want to test float->int then we'd definitely want very large numbers
(in fact we'd wanted numbers which overflow the target type too) - values
between 0..2 aren't particularly interesting in this case. But for converting
to normalized this is right.
This code of course also does cases which are not really interesting and
probably not hit in practice, like unorm->unsigned (everything is 0 or 1 after
conversion).

-- 
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 99987] Mesa 13+ breaks Xvnc (and similar X servers)

[bugzilla-daemon]

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

--- Comment #22 from Pierre Ossman  ---
Is there a symlink in place by default now? If so then I'd say the issue is
resolved.

-- 
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 106232] LLVM unit tests have error in random number handling

[bugzilla-daemon]

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

--- Comment #2 from Jose Fonseca  ---
It's been a long time, but I think Tom's right.  This was a thinko, and my
intent was the opposite.


> And float range is only from 0 to 2.0f?

That's correct.  That's sufficient to exercise the clamping.

Remember that if we generated a range between 0 and a VERY_LARGE_NUMBER, then
only 1/VERY_LARGE_NUMBER of the cases would actually be in the most interesting
range of 0..1

-- 
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 1/3] mesa: merge the driver functions DrawBuffers and DrawBuffer

[Ian Romanick]

On 04/24/2018 07:00 PM, Timothy Arceri wrote:
> 
> 
> On 25/04/18 07:34, Ian Romanick wrote:
>> On 04/24/2018 09:28 AM, Ian Romanick wrote:
>>> On 04/23/2018 08:23 PM, Timothy Arceri wrote:
 On 24/04/18 10:13, Dieter Nützel wrote:
> Hello Timo,
>
> what about 2 and 3, #1 landed.

 It turns out the old radeon classic drivers do make use of the param
 dropped in patch 2 so I've decided to drop that patch, although the use
 of that param might be a bug as the intel drivers changed their
 behavior
 to fix a bug (however it's not a simple change).
>>>
>>> This sounds familiar, and I might have a patch for that.  Let me root
>>> around in my git branches to see if I can find it...  I'm definitely in
>>> favor of cleaning up a bunch of the dd interfaces.
>>
>> I sent these to the list in September 2015:
>>
>> https://patchwork.freedesktop.org/patch/60786/
>> https://patchwork.freedesktop.org/patch/60794/
> 
> For those two patches:
> 
> Acked-by: Timothy Arceri 

Pushed.  That should unblock these patches. :)

>> I don't recall what testing I did exactly, and I didn't put anything
>> useful in the commit message. :(
>>
 I'd still like to push patch 3 but it's tripping up some old
 hardware in
 Intels CI system. I'm not sure whats going on yet.

> Dieter
>>> ___
>>> 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] [RFC 3/3] clover+gallium+freedreno: caps to reduce kernel recompiles

[Rob Clark]

On Thu, Apr 26, 2018 at 5:40 AM, Pierre Moreau  wrote:
> The cap would need to be added to the documentation as well, in
> “src/gallium/docs/source/screen.rst”.
>
> I might be wrong, but I think you are going to break all existing drivers in
> clover, that do not yet support the new cap: for unsupported caps, drivers
> return a value of 0, which means they would never recompile if
> req_(local|private|input)_mem change, even if they should.
> Otherwise, the cap seems like a good idea.
>

I was toying with the idea of inverting the meaning of the bits but a
DOES_NOT_DEPEND bitmask seemed awkward to say.

Either way, I would add the cap to existing drivers (either 0 or ~0
depending on the meaning of the cap) before it was ready to push.  I
don't always do that from the start since it makes rebasing a pita ;-)


> I have one comment further down.
>
> Pierre
>
> On 2018-04-24 — 08:29, Rob Clark wrote:
>> Not all drivers care when cs.reg_*_mem change.  (ir3 only cares about
>> req_input_mem and removing that dependency should be easy.)  Add some
>> caps to let clover make better decisions about when it needs to re-
>> create the compute-state CSO.
>>
>> This way, if the kernel is compiled early for clGetKernelWorkGroupInfo()
>> it doesn't end up getting compiled a second time when the kernel is
>> launched for the first time (clEnqueueNDRangeKernel(), etc).
>>
>> Signed-off-by: Rob Clark 
>> ---
>> If we pre-compile the kernel then we pretty much end up compiling it
>> at least twice, since we don't know the size of the input/local mem
>> yet.  But if driver doesn't care about these, that is a bit silly.
>> Maybe a bit pre-mature optimization, but figured I'd see what others
>> think of the idea.
>>
>>  src/gallium/drivers/freedreno/a5xx/fd5_compute.c  | 3 +++
>>  src/gallium/include/pipe/p_defines.h  | 5 +
>>  src/gallium/state_trackers/clover/core/device.cpp | 7 +++
>>  src/gallium/state_trackers/clover/core/device.hpp | 7 +++
>>  src/gallium/state_trackers/clover/core/kernel.cpp | 4 ++--
>>  5 files changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/drivers/freedreno/a5xx/fd5_compute.c 
>> b/src/gallium/drivers/freedreno/a5xx/fd5_compute.c
>> index 52b60e0c5e2..85efe7ca120 100644
>> --- a/src/gallium/drivers/freedreno/a5xx/fd5_compute.c
>> +++ b/src/gallium/drivers/freedreno/a5xx/fd5_compute.c
>> @@ -137,6 +137,9 @@ fd5_get_compute_param(struct fd_screen *screen, enum 
>> pipe_compute_cap param,
>>  //   RET((uint32_t []){ 64 });
>>   RET((uint32_t []){ 32 });
>>
>> + case PIPE_COMPUTE_CAP_SHADER_DEPS:
>> + RET((uint32_t []){ PIPE_SHADER_DEP_INPUT_MEM });
>> +
>>   case PIPE_COMPUTE_CAP_IR_TARGET:
>>   if (ret)
>>   sprintf(ret, ir);
>> diff --git a/src/gallium/include/pipe/p_defines.h 
>> b/src/gallium/include/pipe/p_defines.h
>> index 0fa96c0d412..f890f99bf01 100644
>> --- a/src/gallium/include/pipe/p_defines.h
>> +++ b/src/gallium/include/pipe/p_defines.h
>> @@ -897,6 +897,10 @@ enum pipe_shader_ir
>> PIPE_SHADER_IR_SPIRV
>>  };
>>
>> +#define PIPE_SHADER_DEP_LOCAL_MEM   0x1  /* recompile if req_local_mem 
>> changes */
>> +#define PIPE_SHADER_DEP_PRIVATE_MEM 0x2  /* recompile if req_private_mem 
>> changes */
>> +#define PIPE_SHADER_DEP_INPUT_MEM   0x4  /* recompile if req_input_mem 
>> changes */
>> +
>>  /**
>>   * Compute-specific implementation capability.  They can be queried
>>   * using pipe_screen::get_compute_param or pipe_screen::get_kernel_param.
>> @@ -919,6 +923,7 @@ enum pipe_compute_cap
>> PIPE_COMPUTE_CAP_IMAGES_SUPPORTED,
>> PIPE_COMPUTE_CAP_SUBGROUP_SIZE,
>> PIPE_COMPUTE_CAP_MAX_VARIABLE_THREADS_PER_BLOCK,
>> +   PIPE_COMPUTE_CAP_SHADER_DEPS,  /* bitmask of PIPE_SHADER_DEP_x */
>>  };
>>
>>  /**
>> diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
>> b/src/gallium/state_trackers/clover/core/device.cpp
>> index 97e098f65de..e7037afa354 100644
>> --- a/src/gallium/state_trackers/clover/core/device.cpp
>> +++ b/src/gallium/state_trackers/clover/core/device.cpp
>> @@ -51,6 +51,13 @@ device::device(clover::platform , 
>> pipe_loader_device *ldev) :
>>throw error(CL_INVALID_DEVICE);
>> }
>>
>> +   uint32_t shader_deps =
>> +  get_compute_param(pipe, ir_format(),
>> +  PIPE_COMPUTE_CAP_SHADER_DEPS)[0];
>> +   dep_local_mem =   !!(shader_deps & PIPE_SHADER_DEP_LOCAL_MEM);
>> +   dep_private_mem = !!(shader_deps & PIPE_SHADER_DEP_PRIVATE_MEM);
>> +   dep_input_mem =   !!(shader_deps & PIPE_SHADER_DEP_INPUT_MEM);
>> +
>> uint32_t shareable_shaders =
>>pipe->get_param(pipe, PIPE_CAP_SHAREABLE_SHADERS);
>>
>> diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
>> b/src/gallium/state_trackers/clover/core/device.hpp
>> index 63cf3abccc4..8de38201777 100644
>> --- a/src/gallium/state_trackers/clover/core/device.hpp
>> +++ 

Re: [Mesa-dev] [PATCH 08/11] intel/compiler: fix brw_negate_immediate for 16-bit types

[Chema Casanova]

El 24/04/18 a las 23:55, Jason Ekstrand escribió:
> On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga  > wrote:
> 
> From: Jose Maria Casanova Crespo  >
> 
> 16-bit immediates are replicated in each word of a 32-bit value
> so we need to negate both.
> ---
>  src/intel/compiler/brw_shader.cpp | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_shader.cpp
> b/src/intel/compiler/brw_shader.cpp
> index 9cdf9fcb23d..c7edc60b63d 100644
> --- a/src/intel/compiler/brw_shader.cpp
> +++ b/src/intel/compiler/brw_shader.cpp
> @@ -581,7 +581,8 @@ brw_negate_immediate(enum brw_reg_type type,
> struct brw_reg *reg)
>        return true;
>     case BRW_REGISTER_TYPE_W:
>     case BRW_REGISTER_TYPE_UW:
> -      reg->d = -(int16_t)reg->ud;
> +   case BRW_REGISTER_TYPE_HF:
> +      reg->ud ^= 0x80008000;
> 
> 
> This is not correct for integers.  We need to keep two separate cases.

That's true, I've forgotten about two's complement representation. For
this series v2 I will send:

case BRW_REGISTER_TYPE_UW:
-  reg->d = -(int16_t)reg->ud;
+  uint16_t value = -(int16_t)reg->ud;
+  reg->ud = value | value << 16;
+  return true;
+   case BRW_REGISTER_TYPE_HF:
+  reg->ud ^= 0x80008000;

I'm including for v2 also a new patch for solving a problem with
negative values at brw_imm_w that is replicating the 16-bit value
wrongly because of sign extension.

>  
> 
>        return true;
>     case BRW_REGISTER_TYPE_F:
>        reg->f = -reg->f;
> @@ -602,8 +603,6 @@ brw_negate_immediate(enum brw_reg_type type,
> struct brw_reg *reg)
>     case BRW_REGISTER_TYPE_UV:
>     case BRW_REGISTER_TYPE_V:
>        assert(!"unimplemented: negate UV/V immediate");
> -   case BRW_REGISTER_TYPE_HF:
> -      assert(!"unimplemented: negate HF immediate");
>     case BRW_REGISTER_TYPE_NF:
>        unreachable("no NF immediates");
>     }
> -- 
> 2.14.1
> 
> ___
> 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 14/22] nir/linker: add some cross stage uniform validation

[Alejandro Piñeiro]

We found some issues with this patch, so we are dropping it. No need to
review it. We will send a new patch when we finish that, but it is not
needed to stop the review of the rest of the patches of the series for
that. This patch was already independent enough.

If someone is interested on the details: this patch was trying to cross
stage a incoming nir variable uniform, and discard it if it was already
processed. But processed as a gl_uniform_storage entry. As this dropped
patch shows, comparing both was already complicating things on the
simple cases, and we found that was not working at all with structs. So
the new approach would be do a previous cross-stage validation,
comparing a nir variable against another nir variable.

BR


On 17/04/18 16:36, Alejandro Piñeiro wrote:
> For now it checks that the type and array size of the uniforms is the
> same, as right now only this and uniform->opaque is filled (and this
> is specific for each stage). More checks will be added as more
> features get added.
>
> We are not checking for the same explicit location as we are basing
> the linking on the location.
>
> We are also avoiding name-checks. As they are just debug info, nothing
> prevents to have one SPIR-V module with the names and other without
> it. It also seems reasonable to think that it is not even needed to
> keep the same names on different modules/stages.
>
> As mentioned on the comment included with this patch, on GLSL linker
> there are some full cross-stage validation methods, taking into
> account more than just the uniforms. It is likely that this gets moved
> later to a bigger method like that.
> ---
>  src/compiler/nir/nir_link_uniforms.c | 68 
> +++-
>  1 file changed, 60 insertions(+), 8 deletions(-)
>
> diff --git a/src/compiler/nir/nir_link_uniforms.c 
> b/src/compiler/nir/nir_link_uniforms.c
> index af01a83a8e3..754385967f6 100644
> --- a/src/compiler/nir/nir_link_uniforms.c
> +++ b/src/compiler/nir/nir_link_uniforms.c
> @@ -215,6 +215,21 @@ get_next_index(struct nir_link_uniforms_state *state,
> return index;
>  }
>  
> +static void
> +handle_type_for_uniform_storage(const struct glsl_type *original_type,
> +const struct glsl_type **storage_type,
> +unsigned *array_elements)
> +{
> +
> +   const struct glsl_type *type_no_array = glsl_without_array(original_type);
> +   if (glsl_type_is_array(original_type)) {
> +  *storage_type = type_no_array;
> +  *array_elements = glsl_get_length(original_type);
> +   } else {
> +  *storage_type = original_type;
> +  *array_elements = 0;
> +   }
> +}
>  
>  /**
>   * Creates the neccessary entries in UniformStorage for the uniform. Returns
> @@ -292,14 +307,8 @@ nir_link_uniform(struct gl_context *ctx,
> */
>uniform->name = NULL;
>  
> -  const struct glsl_type *type_no_array = glsl_without_array(type);
> -  if (glsl_type_is_array(type)) {
> - uniform->type = type_no_array;
> - uniform->array_elements = glsl_get_length(type);
> -  } else {
> - uniform->type = type;
> - uniform->array_elements = 0;
> -  }
> +  handle_type_for_uniform_storage(type, >type,
> +  >array_elements);
>uniform->active_shader_mask |= 1 << stage;
>  
>/* Uniform has an explicit location */
> @@ -327,6 +336,7 @@ nir_link_uniform(struct gl_context *ctx,
>  
>unsigned entries = MAX2(1, uniform->array_elements);
>  
> +  const struct glsl_type *type_no_array = glsl_without_array(type);
>if (glsl_type_is_sampler(type_no_array)) {
>   int sampler_index =
>  get_next_index(state, uniform, >next_sampler_index);
> @@ -383,6 +393,45 @@ nir_link_uniform(struct gl_context *ctx,
> }
>  }
>  
> +/*
> + * Validate if the uniform already linked before on @existing is compatible
> + * with the new usage of it on another stage at @current.
> + *
> + * GLSL linker has specific methods for validation after the linkage, so
> + * probably this bit will be moved later to a more general one.
> + */
> +static bool
> +cross_validate_uniform(struct gl_shader_program *prog,
> +   struct gl_uniform_storage* existing,
> +   nir_variable *current)
> +{
> +   const struct glsl_type *type = current->type;
> +   unsigned array_elements = 0;
> +
> +   handle_type_for_uniform_storage(current->type, , _elements);
> +
> +   if (existing->type != type) {
> +  linker_error(prog, "uniform with location %i declared as "
> +   "type `%s' and type `%s'\n", current->data.location,
> +   glsl_get_type_name(type),
> +   glsl_get_type_name(existing->type));
> +
> +  return false;
> +   }
> +
> +   if (existing->array_elements != array_elements) {
> +  linker_error(prog, "uniform with location %i declared as "
> +   "type `%s[%i]' and 

Re: [Mesa-dev] [PATCH v2] ac/nir: set lod to 0 for ac_image_load_mip

[Nicolai Hähnle]

Is there any reason why we can't just use ac_image_load in such cases?

On 26.04.2018 13:18, Samuel Pitoiset wrote:

Otherwise we hit an assertion in ac_build_image_opcode()
for ac_image_load_mip.

v2: - set only for ac_image_load_mip

Fixes: 24fb3e6aa16 ("ac/nir: use ac_build_image_opcode for image intrinsics")
Cc: 18.1 
Signed-off-by: Samuel Pitoiset 
---
  src/amd/common/ac_nir_to_llvm.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index e4ae6ef49ad..fb8e44509e9 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1276,6 +1276,8 @@ static LLVMValueRef build_tex_intrinsic(struct 
ac_nir_context *ctx,
args->opcode = args->level_zero ||
   instr->sampler_dim == GLSL_SAMPLER_DIM_MS ?
ac_image_load : ac_image_load_mip;
+   if (args->opcode == ac_image_load_mip && !args->lod)
+   args->lod = ctx->ac.i32_0;
args->level_zero = false;
break;
case nir_texop_txs:




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

[Mesa-dev] [PATCH v2] ac/nir: set lod to 0 for ac_image_load_mip

[Samuel Pitoiset]

Otherwise we hit an assertion in ac_build_image_opcode()
for ac_image_load_mip.

v2: - set only for ac_image_load_mip

Fixes: 24fb3e6aa16 ("ac/nir: use ac_build_image_opcode for image intrinsics")
Cc: 18.1 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_nir_to_llvm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index e4ae6ef49ad..fb8e44509e9 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1276,6 +1276,8 @@ static LLVMValueRef build_tex_intrinsic(struct 
ac_nir_context *ctx,
args->opcode = args->level_zero ||
   instr->sampler_dim == GLSL_SAMPLER_DIM_MS ?
ac_image_load : ac_image_load_mip;
+   if (args->opcode == ac_image_load_mip && !args->lod)
+   args->lod = ctx->ac.i32_0;
args->level_zero = false;
break;
case nir_texop_txs:
-- 
2.17.0

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

[Mesa-dev] [Bug 106251] [PATCH] SWR driver doesn't compile with LLVM 7.0 snapshots

[bugzilla-daemon]

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

Bug ID: 106251
   Summary: [PATCH] SWR driver doesn't compile with LLVM 7.0
snapshots
   Product: Mesa
   Version: git
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: b...@lindev.ch
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 139126
  --> https://bugs.freedesktop.org/attachment.cgi?id=139126=edit
Proposed fix

SWR in Mesa 18.1.0-rc1 doesn't compile with post-6.0 LLVM because of API
changes.

-- 
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 09/10] gallium: add PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT

[Nicolai Hähnle]

On 25.04.2018 23:29, Roland Scheidegger wrote:

Am 25.04.2018 um 23:16 schrieb Marek Olšák:

From: Marek Olšák 

---
  src/gallium/docs/source/screen.rst   | 3 +++
  src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
  src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
  src/gallium/drivers/i915/i915_screen.c   | 1 +
  src/gallium/drivers/llvmpipe/lp_screen.c | 1 +
  src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 1 +
  src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 1 +
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 1 +
  src/gallium/drivers/r300/r300_screen.c   | 1 +
  src/gallium/drivers/r600/r600_pipe.c | 1 +
  src/gallium/drivers/radeonsi/si_get.c| 3 +++
  src/gallium/drivers/softpipe/sp_screen.c | 1 +
  src/gallium/drivers/svga/svga_screen.c   | 1 +
  src/gallium/drivers/swr/swr_screen.cpp   | 1 +
  src/gallium/drivers/vc4/vc4_screen.c | 1 +
  src/gallium/drivers/vc5/vc5_screen.c | 1 +
  src/gallium/drivers/virgl/virgl_screen.c | 1 +
  src/gallium/include/pipe/p_defines.h | 1 +
  18 files changed, 22 insertions(+)

diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index 3837360fb40..7cc6d378306 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -413,20 +413,23 @@ The integer capabilities:
supported priority levels.  A driver that does not support prioritized
contexts can return 0.
  * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling semaphores
using fence_server_signal().
  * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that must be
set when binding that buffer as constant buffer 0. If the buffer doesn't 
have
those bits set, pipe_context::set_constant_buffer(.., 0, ..) is ignored
by the driver, and the driver can throw assertion failures.
  * ``PIPE_CAP_PACKED_UNIFORMS``: True if the driver supports packed uniforms
as opposed to padding to vec4s.
+* ``PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT``: The minimum supported alignment 
of
+  the user_stride parameter of transfer_map. If 0, the user-specified stride
+  is unsupported and the user_stride parameter is ignored.

Does this really make a whole lot of sense? What if the minimum stride
natively supported isn't always the same? What happens if the stride
requested is larger than what the hw usually would do, does that need to
be honored as well - it certainly looks like the cap query here wouldn't
answer that?


It really doesn't make much sense, but unfortunately the ChromeOS 
gralloc is just completely braindead. It basically assumes that tilings 
don't exist. You have to give it a stride when a texture is allocated, 
and that is the stride that has to be there whenever the texture is 
mapped for a transfer.


Cheers,
Nicolai






Roland




  
  
  .. _pipe_capf:
  
  PIPE_CAPF_*

  
  
  The floating-point capabilities are:
  
  * ``PIPE_CAPF_MAX_LINE_WIDTH``: The maximum width of a regular line.

diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index b0f8b4bebe3..915e7d7da7d 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -267,20 +267,21 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_MEMOBJ:
 case PIPE_CAP_LOAD_CONSTBUF:
 case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS:
 case PIPE_CAP_TILE_RASTER_ORDER:
 case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES:
 case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET:
 case PIPE_CAP_CONTEXT_PRIORITY_MASK:
 case PIPE_CAP_FENCE_SIGNAL:
 case PIPE_CAP_CONSTBUF0_FLAGS:
 case PIPE_CAP_PACKED_UNIFORMS:
+   case PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT:
return 0;
  
 /* Stream output. */

 case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS:
 case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
 case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
 case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
return 0;
  
 /* Geometry shader output, unsupported. */

diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/src/gallium/drivers/freedreno/freedreno_screen.c
index f338d756dfe..dd052a22f25 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -333,20 +333,21 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_NIR_SAMPLERS_AS_DEREF:
case PIPE_CAP_QUERY_SO_OVERFLOW:
case PIPE_CAP_MEMOBJ:
case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS:
case PIPE_CAP_TILE_RASTER_ORDER:
case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES:
case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET:
case PIPE_CAP_FENCE_SIGNAL:
case PIPE_CAP_CONSTBUF0_FLAGS:
 

[Mesa-dev] [PATCH] ac/nir: set lod to 0 when it's unused

[Samuel Pitoiset]

Otherwise we hit an assertion in ac_build_image_opcode()
for ac_image_load_mip.

Fixes: 24fb3e6aa16 ("ac/nir: use ac_build_image_opcode for image intrinsics")
Cc: 18.1 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_nir_to_llvm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index e4ae6ef49ad..08ee81611e3 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1276,6 +1276,8 @@ static LLVMValueRef build_tex_intrinsic(struct 
ac_nir_context *ctx,
args->opcode = args->level_zero ||
   instr->sampler_dim == GLSL_SAMPLER_DIM_MS ?
ac_image_load : ac_image_load_mip;
+   if (!args->lod)
+   args->lod = ctx->ac.i32_0;
args->level_zero = false;
break;
case nir_texop_txs:
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH] radv: fix multisample image copies

[Samuel Pitoiset]

On 04/25/2018 11:25 AM, Alex Smith wrote:
Any more thoughts on this? Any objections to it going to stable as well 
(it fixes bugs, but is quite a large change)?


I will take care of this after running CTS on Polaris/Vega.



Thanks,
Alex

On 19 April 2018 at 09:27, Matthew Nicholls 
> 
wrote:


On 18/04/18 22:56, Dave Airlie wrote:

On 18 April 2018 at 00:31, Matthew Nicholls
> wrote:

Previously before fb077b0728, the LOD parameter was being
used in place of the
sample index, which would only copy the first sample to all
samples in the
destination image. After that multisample image copies
wouldn't copy anything
from my observations.

Fix this properly by copying each sample in a separate
radv_CmdDraw and using a
pipeline with the correct rasterizationSamples for the
destination image.

Have you run CTS on this?

I ran the CTS tests under dEQP-VK.api.copy_and_blit.core.* and
didn't see any
changes. There were 6 failures both with and without this patch however:


dEQP-VK.api.copy_and_blit.core.resolve_image.{whole_array_image,whole_copy_before_resolving}.{2,4,8}_bit

This is on an RX 460.

Matthew.


I wrote something similiar (I'm on holidays at the moment so can't
confirm how similiar)
but it failed some CTS tests for me.

Dave.

---
   src/amd/vulkan/radv_meta_blit2d.c | 279
--
   src/amd/vulkan/radv_private.h     |  18 +--
   2 files changed, 189 insertions(+), 108 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_blit2d.c
b/src/amd/vulkan/radv_meta_blit2d.c
index e163056257..d953241b55 100644
--- a/src/amd/vulkan/radv_meta_blit2d.c
+++ b/src/amd/vulkan/radv_meta_blit2d.c
@@ -100,7 +100,8 @@ blit2d_bind_src(struct radv_cmd_buffer
*cmd_buffer,
                   struct radv_meta_blit2d_buffer *src_buf,
                   struct blit2d_src_temps *tmp,
                   enum blit2d_src_type src_type, VkFormat
depth_format,
-                VkImageAspectFlagBits aspects)
+                VkImageAspectFlagBits aspects,
+                uint32_t log2_samples)
   {
          struct radv_device *device = cmd_buffer->device;

@@ -108,7 +109,7 @@ blit2d_bind_src(struct radv_cmd_buffer
*cmd_buffer,
                  create_bview(cmd_buffer, src_buf,
>bview, depth_format);

                  radv_meta_push_descriptor_set(cmd_buffer,
VK_PIPELINE_BIND_POINT_GRAPHICS,
-   
  device->meta_state.blit2d.p_layouts[src_type],
+   
  device->meta_state.blit2d[log2_samples].p_layouts[src_type],

                                                0, /* set */
                                                1, /*
descriptorWriteCount */
  
  (VkWriteDescriptorSet[]) {

@@ -123,7 +124,7 @@ blit2d_bind_src(struct radv_cmd_buffer
*cmd_buffer,
                                                });


  radv_CmdPushConstants(radv_cmd_buffer_to_handle(cmd_buffer),
-   
  device->meta_state.blit2d.p_layouts[src_type],
+   
  device->meta_state.blit2d[log2_samples].p_layouts[src_type],
  
  VK_SHADER_STAGE_FRAGMENT_BIT, 16, 4,

                                        _buf->pitch);
          } else {
@@ -131,12 +132,12 @@ blit2d_bind_src(struct radv_cmd_buffer
*cmd_buffer,

                  if (src_type == BLIT2D_SRC_TYPE_IMAGE_3D)

  radv_CmdPushConstants(radv_cmd_buffer_to_handle(cmd_buffer),
-   
  device->meta_state.blit2d.p_layouts[src_type],
+   
  device->meta_state.blit2d[log2_samples].p_layouts[src_type],
  
  VK_SHADER_STAGE_FRAGMENT_BIT, 16, 4,
  
  _img->layer);


 

Re: [Mesa-dev] [PATCH] egl/x11: Send invalidate to the driver on dri2_copy_region

[Thomas Hellstrom]

On 04/26/2018 11:56 AM, Michel Dänzer wrote:

On 2018-04-26 11:33 AM, Thomas Hellstrom wrote:

On 04/26/2018 10:30 AM, Michel Dänzer wrote:

On 2018-04-25 07:49 PM, Deepak Rawat wrote:

Similar to what is done in dri2_x11_swap_buffers_msc send invalidate
to the driver because egl/X11 is not watching for for server's
invalidate events. The dri2_copy_region path is trigerred when
server supports DRI2 version minor 1.

Tested with piglit egl tests for regression.

Cc: 
Signed-off-by: Deepak Rawat 
Reviewed-by: Thomas Hellstrom 
---
   src/egl/drivers/dri2/platform_x11.c | 7 +++
   1 file changed, 7 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_x11.c
b/src/egl/drivers/dri2/platform_x11.c
index 6c287b4d06..e99434ea3a 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -841,6 +841,13 @@ dri2_copy_region(_EGLDriver *drv, _EGLDisplay
*disp,
  render_attachment);
  free(xcb_dri2_copy_region_reply(dri2_dpy->conn, cookie, NULL));
   +   /*
+    * Just like as done in dri2_x11_swap_buffers_msc we aren't
watching for
+    * server's invalidate events, so just send invalidate to driver.
+    */
+   if (dri2_dpy->flush->base.version >= 3 &&
dri2_dpy->flush->invalidate)
+  dri2_dpy->flush->invalidate(dri2_surf->dri_drawable);
+
  return EGL_TRUE;
   }

Why is invalidate needed after copy_region? That's surprising, I suspect
it just papers over the real problem.



I had a quick look into the platform_x11 code. dri2_copy_region is
called only from the various swap_buffers() paths,
dri2_x11_swap_buffers() and dri2_x11_swap_buffers_region(). Explicit
invalidation is, before this patch, done only if the server supports
dri2 swaps. Probably because most drivers do, vmware does not, so we can
hit swapbuffers without doing explicit invalidation.

In comparison, GLX does explicit invalidation on swapbuffers,
bind_context and bind_texture for the same protocol version, so this
patch should only bring the EGL swapbuffer paths closer to what GLX is
doing, while still not addressing bind_context and bind_texture.

FWIW, EGL platform_x11 (dri2) seems to not parse server invalidate
events for the higher protocol versions, relying solely on explicit
invalidation.

The purpose of the invalidate callback is to trigger updating the DRI2
buffers before drawing the next frame. This isn't necessary after a
copy_region operation, so you seem to be relying on some kind of side
effect of the invalidate callback. Which may be okay, but I think it
would be clearer not to put this code in dri2_copy_region itself.


The purpose in this case is to update the dri2 buffers after a 
swapbuffer operation, which *is* needed, but I agree that there might be 
cases where the dri2_copy_region could theoretically be used without 
requiring an invalidation.


So we could of course move out the invalidation to the swapbuffer functions.

/Thomas


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

Re: [Mesa-dev] [PATCH] egl/x11: Send invalidate to the driver on dri2_copy_region

[Michel Dänzer]

On 2018-04-26 11:33 AM, Thomas Hellstrom wrote:
> On 04/26/2018 10:30 AM, Michel Dänzer wrote:
>> On 2018-04-25 07:49 PM, Deepak Rawat wrote:
>>> Similar to what is done in dri2_x11_swap_buffers_msc send invalidate
>>> to the driver because egl/X11 is not watching for for server's
>>> invalidate events. The dri2_copy_region path is trigerred when
>>> server supports DRI2 version minor 1.
>>>
>>> Tested with piglit egl tests for regression.
>>>
>>> Cc: 
>>> Signed-off-by: Deepak Rawat 
>>> Reviewed-by: Thomas Hellstrom 
>>> ---
>>>   src/egl/drivers/dri2/platform_x11.c | 7 +++
>>>   1 file changed, 7 insertions(+)
>>>
>>> diff --git a/src/egl/drivers/dri2/platform_x11.c
>>> b/src/egl/drivers/dri2/platform_x11.c
>>> index 6c287b4d06..e99434ea3a 100644
>>> --- a/src/egl/drivers/dri2/platform_x11.c
>>> +++ b/src/egl/drivers/dri2/platform_x11.c
>>> @@ -841,6 +841,13 @@ dri2_copy_region(_EGLDriver *drv, _EGLDisplay
>>> *disp,
>>>  render_attachment);
>>>  free(xcb_dri2_copy_region_reply(dri2_dpy->conn, cookie, NULL));
>>>   +   /*
>>> +    * Just like as done in dri2_x11_swap_buffers_msc we aren't
>>> watching for
>>> +    * server's invalidate events, so just send invalidate to driver.
>>> +    */
>>> +   if (dri2_dpy->flush->base.version >= 3 &&
>>> dri2_dpy->flush->invalidate)
>>> +  dri2_dpy->flush->invalidate(dri2_surf->dri_drawable);
>>> +
>>>  return EGL_TRUE;
>>>   }
>> Why is invalidate needed after copy_region? That's surprising, I suspect
>> it just papers over the real problem.
>>
>>
> I had a quick look into the platform_x11 code. dri2_copy_region is
> called only from the various swap_buffers() paths,
> dri2_x11_swap_buffers() and dri2_x11_swap_buffers_region(). Explicit
> invalidation is, before this patch, done only if the server supports
> dri2 swaps. Probably because most drivers do, vmware does not, so we can
> hit swapbuffers without doing explicit invalidation.
> 
> In comparison, GLX does explicit invalidation on swapbuffers,
> bind_context and bind_texture for the same protocol version, so this
> patch should only bring the EGL swapbuffer paths closer to what GLX is
> doing, while still not addressing bind_context and bind_texture.
> 
> FWIW, EGL platform_x11 (dri2) seems to not parse server invalidate
> events for the higher protocol versions, relying solely on explicit
> invalidation.

The purpose of the invalidate callback is to trigger updating the DRI2
buffers before drawing the next frame. This isn't necessary after a
copy_region operation, so you seem to be relying on some kind of side
effect of the invalidate callback. Which may be okay, but I think it
would be clearer not to put this code in dri2_copy_region itself.


-- 
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] [RFC 3/3] clover+gallium+freedreno: caps to reduce kernel recompiles

[Pierre Moreau]

The cap would need to be added to the documentation as well, in
“src/gallium/docs/source/screen.rst”.

I might be wrong, but I think you are going to break all existing drivers in
clover, that do not yet support the new cap: for unsupported caps, drivers
return a value of 0, which means they would never recompile if
req_(local|private|input)_mem change, even if they should.
Otherwise, the cap seems like a good idea.

I have one comment further down.

Pierre

On 2018-04-24 — 08:29, Rob Clark wrote:
> Not all drivers care when cs.reg_*_mem change.  (ir3 only cares about
> req_input_mem and removing that dependency should be easy.)  Add some
> caps to let clover make better decisions about when it needs to re-
> create the compute-state CSO.
> 
> This way, if the kernel is compiled early for clGetKernelWorkGroupInfo()
> it doesn't end up getting compiled a second time when the kernel is
> launched for the first time (clEnqueueNDRangeKernel(), etc).
> 
> Signed-off-by: Rob Clark 
> ---
> If we pre-compile the kernel then we pretty much end up compiling it
> at least twice, since we don't know the size of the input/local mem
> yet.  But if driver doesn't care about these, that is a bit silly.
> Maybe a bit pre-mature optimization, but figured I'd see what others
> think of the idea.
> 
>  src/gallium/drivers/freedreno/a5xx/fd5_compute.c  | 3 +++
>  src/gallium/include/pipe/p_defines.h  | 5 +
>  src/gallium/state_trackers/clover/core/device.cpp | 7 +++
>  src/gallium/state_trackers/clover/core/device.hpp | 7 +++
>  src/gallium/state_trackers/clover/core/kernel.cpp | 4 ++--
>  5 files changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/freedreno/a5xx/fd5_compute.c 
> b/src/gallium/drivers/freedreno/a5xx/fd5_compute.c
> index 52b60e0c5e2..85efe7ca120 100644
> --- a/src/gallium/drivers/freedreno/a5xx/fd5_compute.c
> +++ b/src/gallium/drivers/freedreno/a5xx/fd5_compute.c
> @@ -137,6 +137,9 @@ fd5_get_compute_param(struct fd_screen *screen, enum 
> pipe_compute_cap param,
>  //   RET((uint32_t []){ 64 });
>   RET((uint32_t []){ 32 });
>  
> + case PIPE_COMPUTE_CAP_SHADER_DEPS:
> + RET((uint32_t []){ PIPE_SHADER_DEP_INPUT_MEM });
> +
>   case PIPE_COMPUTE_CAP_IR_TARGET:
>   if (ret)
>   sprintf(ret, ir);
> diff --git a/src/gallium/include/pipe/p_defines.h 
> b/src/gallium/include/pipe/p_defines.h
> index 0fa96c0d412..f890f99bf01 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -897,6 +897,10 @@ enum pipe_shader_ir
> PIPE_SHADER_IR_SPIRV
>  };
>  
> +#define PIPE_SHADER_DEP_LOCAL_MEM   0x1  /* recompile if req_local_mem 
> changes */
> +#define PIPE_SHADER_DEP_PRIVATE_MEM 0x2  /* recompile if req_private_mem 
> changes */
> +#define PIPE_SHADER_DEP_INPUT_MEM   0x4  /* recompile if req_input_mem 
> changes */
> +
>  /**
>   * Compute-specific implementation capability.  They can be queried
>   * using pipe_screen::get_compute_param or pipe_screen::get_kernel_param.
> @@ -919,6 +923,7 @@ enum pipe_compute_cap
> PIPE_COMPUTE_CAP_IMAGES_SUPPORTED,
> PIPE_COMPUTE_CAP_SUBGROUP_SIZE,
> PIPE_COMPUTE_CAP_MAX_VARIABLE_THREADS_PER_BLOCK,
> +   PIPE_COMPUTE_CAP_SHADER_DEPS,  /* bitmask of PIPE_SHADER_DEP_x */
>  };
>  
>  /**
> diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
> b/src/gallium/state_trackers/clover/core/device.cpp
> index 97e098f65de..e7037afa354 100644
> --- a/src/gallium/state_trackers/clover/core/device.cpp
> +++ b/src/gallium/state_trackers/clover/core/device.cpp
> @@ -51,6 +51,13 @@ device::device(clover::platform , 
> pipe_loader_device *ldev) :
>throw error(CL_INVALID_DEVICE);
> }
>  
> +   uint32_t shader_deps =
> +  get_compute_param(pipe, ir_format(),
> +  PIPE_COMPUTE_CAP_SHADER_DEPS)[0];
> +   dep_local_mem =   !!(shader_deps & PIPE_SHADER_DEP_LOCAL_MEM);
> +   dep_private_mem = !!(shader_deps & PIPE_SHADER_DEP_PRIVATE_MEM);
> +   dep_input_mem =   !!(shader_deps & PIPE_SHADER_DEP_INPUT_MEM);
> +
> uint32_t shareable_shaders =
>pipe->get_param(pipe, PIPE_CAP_SHAREABLE_SHADERS);
>  
> diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
> b/src/gallium/state_trackers/clover/core/device.hpp
> index 63cf3abccc4..8de38201777 100644
> --- a/src/gallium/state_trackers/clover/core/device.hpp
> +++ b/src/gallium/state_trackers/clover/core/device.hpp
> @@ -99,6 +99,13 @@ namespace clover {
> */
>pipe_context *pctx;
>  
> +  /* things that the compute-state CSO depends on, which determines
> +   * what triggers recreating the CSO.
> +   */
> +  bool dep_local_mem;
> +  bool dep_private_mem;

You do not seem to be using “dep_private_mem”, is that oversight?

> +  bool dep_input_mem;
> +
> private:
>pipe_loader_device *ldev;
> };
> diff --git 

Re: [Mesa-dev] [PATCH] egl/x11: Send invalidate to the driver on dri2_copy_region

[Thomas Hellstrom]

On 04/26/2018 10:30 AM, Michel Dänzer wrote:

On 2018-04-25 07:49 PM, Deepak Rawat wrote:

Similar to what is done in dri2_x11_swap_buffers_msc send invalidate
to the driver because egl/X11 is not watching for for server's
invalidate events. The dri2_copy_region path is trigerred when
server supports DRI2 version minor 1.

Tested with piglit egl tests for regression.

Cc: 
Signed-off-by: Deepak Rawat 
Reviewed-by: Thomas Hellstrom 
---
  src/egl/drivers/dri2/platform_x11.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index 6c287b4d06..e99434ea3a 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -841,6 +841,13 @@ dri2_copy_region(_EGLDriver *drv, _EGLDisplay *disp,
   render_attachment);
 free(xcb_dri2_copy_region_reply(dri2_dpy->conn, cookie, NULL));
  
+   /*

+* Just like as done in dri2_x11_swap_buffers_msc we aren't watching for
+* server's invalidate events, so just send invalidate to driver.
+*/
+   if (dri2_dpy->flush->base.version >= 3 && dri2_dpy->flush->invalidate)
+  dri2_dpy->flush->invalidate(dri2_surf->dri_drawable);
+
 return EGL_TRUE;
  }

Why is invalidate needed after copy_region? That's surprising, I suspect
it just papers over the real problem.


I had a quick look into the platform_x11 code. dri2_copy_region is 
called only from the various swap_buffers() paths, 
dri2_x11_swap_buffers() and dri2_x11_swap_buffers_region(). Explicit 
invalidation is, before this patch, done only if the server supports 
dri2 swaps. Probably because most drivers do, vmware does not, so we can 
hit swapbuffers without doing explicit invalidation.


In comparison, GLX does explicit invalidation on swapbuffers, 
bind_context and bind_texture for the same protocol version, so this 
patch should only bring the EGL swapbuffer paths closer to what GLX is 
doing, while still not addressing bind_context and bind_texture.


FWIW, EGL platform_x11 (dri2) seems to not parse server invalidate 
events for the higher protocol versions, relying solely on explicit 
invalidation.


/Thomas


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

[Mesa-dev] [Bug 106246] radv: VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BIT and bringing down initial pipeline compile times

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |t_arc...@yahoo.com.au
   |org |

--- Comment #2 from Timothy Arceri  ---
I'll take a look into this. We could probably turn off/limit a number of NIR
passes without to much problem (such as the link time opts), it is also
something we can likely improve incrementally. I'm not too sure how much we can
dial down LLVM this will take some investigation.

One concern (besides what Samuel has already mentioned) is that turning off
some optimisations passes may trigger bugs that would normally be hidden.

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

[Mesa-dev] [PATCH 2/2] spirv: convert the offset and count operands for bitfield ops to uint32

[Samuel Iglesias Gonsálvez]

SPIR-V allows to define the shift operand for shift opcodes with
a bit-size different than 32 bits, but in NIR the opcodes have
that limitation. As agreed in the mailing list, this patch adds
a conversion to 32 bits to fix this.

For more info, see:

https://lists.freedesktop.org/archives/mesa-dev/2018-April/193026.html

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/spirv/vtn_alu.c | 48 
 1 file changed, 48 insertions(+)

diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index 6f3b82cd5c3..a1654b20273 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -640,6 +640,54 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
   break;
}
 
+   case SpvOpBitFieldInsert: {
+  if (src[2]->bit_size != 32) {
+ /* Convert the Shift operand to 32 bits, which is the bitsize
+  * supported by the NIR instruction. See discussion here:
+  *
+  * 
https://lists.freedesktop.org/archives/mesa-dev/2018-April/193026.html
+  */
+ src[2] = nir_build_alu(>nb, nir_op_u2u32, src[2], NULL, NULL, 
NULL);
+  }
+  if (src[3]->bit_size != 32) {
+ /* Convert the Shift operand to 32 bits, which is the bitsize
+  * supported by the NIR instruction. See discussion here:
+  *
+  * 
https://lists.freedesktop.org/archives/mesa-dev/2018-April/193026.html
+  */
+ src[3] = nir_build_alu(>nb, nir_op_u2u32, src[3], NULL, NULL, 
NULL);
+  }
+  val->ssa->def = nir_build_alu(>nb, nir_op_bitfield_insert, src[0], 
src[1], src[2], src[3]);
+  break;
+   }
+
+   case SpvOpBitFieldSExtract:
+   case SpvOpBitFieldUExtract: {
+  bool swap;
+  unsigned src_bit_size = glsl_get_bit_size(vtn_src[0]->type);
+  unsigned dst_bit_size = glsl_get_bit_size(type);
+  nir_op op = vtn_nir_alu_op_for_spirv_opcode(b, opcode, ,
+  src_bit_size, dst_bit_size);
+  if (src[1]->bit_size != 32) {
+ /* Convert the Shift operand to 32 bits, which is the bitsize
+  * supported by the NIR instruction. See discussion here:
+  *
+  * 
https://lists.freedesktop.org/archives/mesa-dev/2018-April/193026.html
+  */
+ src[1] = nir_build_alu(>nb, nir_op_u2u32, src[1], NULL, NULL, 
NULL);
+  }
+  if (src[2]->bit_size != 32) {
+ /* Convert the Shift operand to 32 bits, which is the bitsize
+  * supported by the NIR instruction. See discussion here:
+  *
+  * 
https://lists.freedesktop.org/archives/mesa-dev/2018-April/193026.html
+  */
+ src[2] = nir_build_alu(>nb, nir_op_u2u32, src[2], NULL, NULL, 
NULL);
+  }
+  val->ssa->def = nir_build_alu(>nb, op, src[0], src[1], src[2], 
src[3]);
+  break;
+   }
+
case SpvOpShiftLeftLogical:
case SpvOpShiftRightArithmetic:
case SpvOpShiftRightLogical: {
-- 
2.14.1

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

[Mesa-dev] [PATCH 1/2] spirv: convert the shift operand for bitwise shift ops to uint32

[Samuel Iglesias Gonsálvez]

SPIR-V allows to define the shift operand for shift opcodes with
a bit-size different than 32 bits, but in NIR the opcodes have
that limitation. As agreed in the mailing list, this patch adds
a conversion to 32 bits to fix this.

For more info, see:

https://lists.freedesktop.org/archives/mesa-dev/2018-April/193026.html

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/spirv/vtn_alu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index 71e743cdd1e..6f3b82cd5c3 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -640,6 +640,26 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
   break;
}
 
+   case SpvOpShiftLeftLogical:
+   case SpvOpShiftRightArithmetic:
+   case SpvOpShiftRightLogical: {
+  bool swap;
+  unsigned src_bit_size = glsl_get_bit_size(vtn_src[0]->type);
+  unsigned dst_bit_size = glsl_get_bit_size(type);
+  nir_op op = vtn_nir_alu_op_for_spirv_opcode(b, opcode, ,
+  src_bit_size, dst_bit_size);
+  if (src[1]->bit_size != 32) {
+ /* Convert the Shift operand to 32 bits, which is the bitsize
+  * supported by the NIR instruction. See discussion here:
+  *
+  * 
https://lists.freedesktop.org/archives/mesa-dev/2018-April/193026.html
+  */
+ src[1] = nir_build_alu(>nb, nir_op_u2u32, src[1], NULL, NULL, 
NULL);
+  }
+  val->ssa->def = nir_build_alu(>nb, op, src[0], src[1], src[2], 
src[3]);
+  break;
+   }
+
default: {
   bool swap;
   unsigned src_bit_size = glsl_get_bit_size(vtn_src[0]->type);
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] spirv: convert the shift operand for bitwise shift ops to uint32

[Samuel Iglesias Gonsálvez]

Please ignore this patch, I'm about to send a patch series that includes
this patch and another one for bitfield ops.

Sam


On 25/04/18 14:07, Samuel Iglesias Gonsálvez wrote:
> SPIR-V allows to define the shift operand for shift opcodes with
> a bit-size different than 32 bits, but in NIR the opcodes have
> that limitation. As agreed in the mailing list, this patch adds
> a conversion to 32 bits to fix this.
>
> For more info, see:
>
> https://lists.freedesktop.org/archives/mesa-dev/2018-April/193026.html
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/compiler/spirv/vtn_alu.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
> index 71e743cdd1e..1d33ae28273 100644
> --- a/src/compiler/spirv/vtn_alu.c
> +++ b/src/compiler/spirv/vtn_alu.c
> @@ -640,6 +640,19 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
>break;
> }
>  
> +   case SpvOpShiftLeftLogical:
> +   case SpvOpShiftRightArithmetic:
> +   case SpvOpShiftRightLogical: {
> +  if (src[1]->bit_size != 32) {
> + /* Convert the Shift operand to 32 bits, which is the bitsize
> +  * supported by the NIR instruction. See discussion here:
> +  *
> +  * 
> https://lists.freedesktop.org/archives/mesa-dev/2018-April/193026.html
> +  */
> + src[1] = nir_build_alu(>nb, nir_op_u2u32, src[1], NULL, NULL, 
> NULL);
> +  }
> +   }
> +   /* fall-through */
> default: {
>bool swap;
>unsigned src_bit_size = glsl_get_bit_size(vtn_src[0]->type);




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 106151] [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of the Tomb Raider)

[bugzilla-daemon]

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

--- Comment #10 from Samuel Pitoiset  ---
I have been able to reproduce the hang one or two times. Unfortunately it's
really hard to reproduce, so really hard to fix but we are working on!

-- 
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 106246] radv: VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BIT and bringing down initial pipeline compile times

[bugzilla-daemon]

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

--- Comment #1 from Samuel Pitoiset  ---
Hi Phillip,

It's doable but it would require a non-trivial amount of work. And I'm not sure
if the gain will be significant, especially if most of the time is spent in
LLVM.

Also, disabling optimizations will reduce CPU usage, of course, but this will
increase GPU usage (until the optimized pipeline is ready), so not sure again.

I'm open for discussions though. :)

-- 
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 106246] radv: VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BIT and bringing down initial pipeline compile times

[bugzilla-daemon]

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

Bug ID: 106246
   Summary: radv: VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BIT and
bringing down initial pipeline compile times
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: philip.rebo...@tu-dortmund.de
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 139124
  --> https://bugs.freedesktop.org/attachment.cgi?id=139124=edit
volund-benchmark.sh

Hello,

a general issue encountered in DXVK is that pipelines have to be compiled at
draw time, as the pipeline state and the combination of shaders used for
rendering are not known in advance. This leads to noticable stutter in a lot of
games when the shader cache is cold.

The attached script measures the pipeline compile times of the Unity Blacksmith
demo, which can be downloaded here:
https://blogs.unity3d.com/2015/06/24/releasing-the-blacksmith/

I picked this demo because it warms the shader cache as part of its loading
process, making for a reproducible test case. On my Ryzen 2700X setup, all the
vkCreateGraphicsPipelines calls combined take about four minutes using the
"Higher" preset on mesa 18.0.1, llvm 6.0 and latest dxvk-master, where about
2/3rds of the total CPU time is spent inside LLVM, and 1/6th inside
libvulkan-radeon.

An optimization I have in mind for DXVK would be to use
VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BIT in order to reduce the initial
compile times, and to compile an optimized version of the pipeline
asynchronously in the background. However, this requires driver support for
VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BIT.

Please let me know if this is a viable option and if significant gains are to
be expected when implementing support for this flag in the driver.

-- 
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] egl/x11: Send invalidate to the driver on dri2_copy_region

[Michel Dänzer]

On 2018-04-25 07:49 PM, Deepak Rawat wrote:
> Similar to what is done in dri2_x11_swap_buffers_msc send invalidate
> to the driver because egl/X11 is not watching for for server's
> invalidate events. The dri2_copy_region path is trigerred when
> server supports DRI2 version minor 1.
> 
> Tested with piglit egl tests for regression.
> 
> Cc: 
> Signed-off-by: Deepak Rawat 
> Reviewed-by: Thomas Hellstrom 
> ---
>  src/egl/drivers/dri2/platform_x11.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/egl/drivers/dri2/platform_x11.c 
> b/src/egl/drivers/dri2/platform_x11.c
> index 6c287b4d06..e99434ea3a 100644
> --- a/src/egl/drivers/dri2/platform_x11.c
> +++ b/src/egl/drivers/dri2/platform_x11.c
> @@ -841,6 +841,13 @@ dri2_copy_region(_EGLDriver *drv, _EGLDisplay *disp,
>  render_attachment);
> free(xcb_dri2_copy_region_reply(dri2_dpy->conn, cookie, NULL));
>  
> +   /*
> +* Just like as done in dri2_x11_swap_buffers_msc we aren't watching for
> +* server's invalidate events, so just send invalidate to driver.
> +*/
> +   if (dri2_dpy->flush->base.version >= 3 && dri2_dpy->flush->invalidate)
> +  dri2_dpy->flush->invalidate(dri2_surf->dri_drawable);
> +
> return EGL_TRUE;
>  }

Why is invalidate needed after copy_region? That's surprising, I suspect
it just papers over the real problem.


-- 
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] egl/android: remove flink name support

[Chih-Wei Huang]

2018-04-25 19:55 GMT+08:00 Robert Foss :
> Hey Emil & Chih-Wei,
>
> On 04/24/2018 01:59 PM, Emil Velikov wrote:
>>
>> On 24 April 2018 at 12:28, Emil Velikov  wrote:
>>
>>> On the topic of keeping the old code behind a #define or just removing
>>> it, it'll be great if interested parties can reach a consensus.
>>>
>> Actually one can simply drop this code and drm_gralloc users can add a
>> drm_ioctl_permit() hack.
>> Namely: loosen the restrictions to consider render nodes identical to
>> primary/card ones.
>>
>> Yes, it's a nasty hack, yet no worse than the existing one that
>> removes the auth :-\
>
> I'm fine with adding a #define.
> Chih-Wei: Do you have any objections?

"keeping the old code behind a #define"?
Sounds good to me. Thank you!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] DriConf replacement

[Aruna Maurya]

Hey!

I wish to contribute to this project. I have substantial experience in C
and C++. It would be great if someone could help me in building the
environment.

Thankyou for your time!
-- 
Regards,
Aruna Maurya,
CSE,B.tech,
Github  | Medium

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

Re: [Mesa-dev] [PATCH 01/11] intel/compiler: lower 16-bit integer extended math instructions

[Iago Toral]

On Wed, 2018-04-25 at 07:05 -0700, Jason Ekstrand wrote:
> Some of these comments may be duplicates of ones I made the first
> time through.
> 
> On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga  om> wrote:
> > The hardware doesn't support 16-bit integer types, so we need to
> > implement
> > 
> > these using 32-bit integer instructions and then convert the result
> > back
> > 
> > to 16-bit.
> > 
> > ---
> > 
> >  src/intel/Makefile.sources|   1 +
> > 
> >  src/intel/compiler/brw_nir.c  |   2 +
> > 
> >  src/intel/compiler/brw_nir.h  |   2 +
> > 
> >  src/intel/compiler/brw_nir_lower_16bit_int_math.c | 108
> > ++
> > 
> >  src/intel/compiler/meson.build|   1 +
> > 
> >  5 files changed, 114 insertions(+)
> > 
> >  create mode 100644
> > src/intel/compiler/brw_nir_lower_16bit_int_math.c
> > 
> > 
> > 
> > diff --git a/src/intel/Makefile.sources
> > b/src/intel/Makefile.sources
> > 
> > index 91c71a8dfaf..2cd76961ea4 100644
> > 
> > --- a/src/intel/Makefile.sources
> > 
> > +++ b/src/intel/Makefile.sources
> > 
> > @@ -79,6 +79,7 @@ COMPILER_FILES = \
> > 
> > compiler/brw_nir_analyze_boolean_resolves.c \
> > 
> > compiler/brw_nir_analyze_ubo_ranges.c \
> > 
> > compiler/brw_nir_attribute_workarounds.c \
> > 
> > +   compiler/brw_nir_lower_16bit_int_math.c \
> > 
> > compiler/brw_nir_lower_cs_intrinsics.c \
> > 
> > compiler/brw_nir_opt_peephole_ffma.c \
> > 
> > compiler/brw_nir_tcs_workarounds.c \
> > 
> > diff --git a/src/intel/compiler/brw_nir.c
> > b/src/intel/compiler/brw_nir.c
> > 
> > index 69ab162f888..2e5754076ed 100644
> > 
> > --- a/src/intel/compiler/brw_nir.c
> > 
> > +++ b/src/intel/compiler/brw_nir.c
> > 
> > @@ -638,6 +638,8 @@ brw_preprocess_nir(const struct brw_compiler
> > *compiler, nir_shader *nir)
> > 
> >  nir_lower_isign64 |
> > 
> >  nir_lower_divmod64);
> > 
> > 
> > 
> > +   brw_nir_lower_16bit_int_math(nir);
> > 
> > +
> > 
> > nir = brw_nir_optimize(nir, compiler, is_scalar);
> > 
> > 
> > 
> > if (is_scalar) {
> > 
> > diff --git a/src/intel/compiler/brw_nir.h
> > b/src/intel/compiler/brw_nir.h
> > 
> > index 03f52da08e5..6ba1a8bc654 100644
> > 
> > --- a/src/intel/compiler/brw_nir.h
> > 
> > +++ b/src/intel/compiler/brw_nir.h
> > 
> > @@ -152,6 +152,8 @@ void brw_nir_analyze_ubo_ranges(const struct
> > brw_compiler *compiler,
> > 
> > 
> > 
> >  bool brw_nir_opt_peephole_ffma(nir_shader *shader);
> > 
> > 
> > 
> > +bool brw_nir_lower_16bit_int_math(nir_shader *shader);
> > 
> > +
> > 
> >  nir_shader *brw_nir_optimize(nir_shader *nir,
> > 
> >   const struct brw_compiler *compiler,
> > 
> >   bool is_scalar);
> > 
> > diff --git a/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> > b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> > 
> > new file mode 100644
> > 
> > index 000..6876309a822
> > 
> > --- /dev/null
> > 
> > +++ b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> > 
> > @@ -0,0 +1,108 @@
> > 
> > +/*
> > 
> > + * Copyright © 2018 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
> > 
> > + * Software.
> > 
> > + *
> > 
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > EXPRESS OR
> > 
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > MERCHANTABILITY,
> > 
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> > EVENT SHALL
> > 
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > DAMAGES OR OTHER
> > 
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > ARISING
> > 
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > OTHER DEALINGS
> > 
> > + * IN THE SOFTWARE.
> > 
> > + */
> > 
> > +
> > 
> > +#include "brw_nir.h"
> > 
> > +#include "nir_builder.h"
> > 
> > +
> > 
> > +/**
> > 
> > + * Intel hardware doesn't support 16-bit integer Math instructions
> > so this
> > 
> > + * pass implements them in 32-bit and then converts the result
> > back to 16-bit.
> > 
> > + */
> > 
> > +static void
> > 
> > +lower_math_instr(nir_builder *bld,