Re: [Mesa-dev] [PATCH] gallivm: abort when trying to use non-existing intrinsic

[Jose Fonseca]

On 21/12/2018 01:42, srol...@vmware.com wrote:

From: Roland Scheidegger 

Whenever llvm removes an intrinsic (we're using), we're hitting segfaults
due to llvm doing calls to address 0 in the jitted code instead.
However, Jose figured out we can actually detect this with
LLVMGetIntrinsicID(), so use this to abort, so we don't have to wonder
what got broken. (Of course, someone still needs to fix the code to
no longer use this intrinsic.)
---
  src/gallium/auxiliary/gallivm/lp_bld_intr.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_intr.c 
b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
index 74ed16f33f0..c9df136b103 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
@@ -241,6 +241,16 @@ lp_build_intrinsic(LLVMBuilderRef builder,
  
function = lp_declare_intrinsic(module, name, ret_type, arg_types, num_args);
  
+  /*

+   * If llvm removes an intrinsic we use, we'll hit this abort (rather
+   * than a call to address zero in the jited code).
+   */
+  if (LLVMGetIntrinsicID(function) == 0) {
+ printf("llvm (version 0x%x) found no intrinsic for %s, going to 
crash...\n",
+HAVE_LLVM, name);


Better to use _debug_printf() so it's redirected to stderr (or 
OutpuDebug on Windows.)



+ abort();
+  }
+
if (!set_callsite_attrs)
   lp_add_func_attributes(function, attr_mask);
  



I think it's worth auditing we don't use lp_build_intrinsic() helper for 
LLVM functions we built ourselves.  I took a look, and didn't found any.


Otherwise

Reviewed-by: Jose Fonseca 

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

Re: [Mesa-dev] [PATCH] gallivm: don't use pavg.b intrinsic on llvm >= 6.0

[Jose Fonseca]

On 21/12/2018 00:25, srol...@vmware.com wrote:

From: Roland Scheidegger 

This intrinsic disppeared with llvm 6.0, using it ends up in segfaults
(due to llvm issuing call to NULL address in the jited shaders).
Add code doing the same thing as the autoupgrade code in llvm so it
can be matched and replaced back with a pavgb.

While here, also improve lp_test_format, so it tests both with and without
cache (as it was, it tested the cache versions only, whereas cache is
actually disabled in llvmpipe, and in any case even with it enabled
vertex and geometry shaders wouldn't use it). (Although at least for
the unorm8 uncached fetch, the code is still quite different to what
llvmpipe is using, since that would use unorm8x16 type, whereas
the test code is using unorm8x4 type, hence disabling some intrinsic
paths.)

Fixes: 6f4083143bb8c478ccfcaef034d183d89b471993
---
  .../auxiliary/gallivm/lp_bld_format_s3tc.c| 55 +--
  src/gallium/drivers/llvmpipe/lp_test_format.c | 91 ++-
  2 files changed, 95 insertions(+), 51 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c 
b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
index 2b143566f24..9561c349dad 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
@@ -457,6 +457,50 @@ color_expand_565_to_(struct gallivm_state *gallivm,
  }
  
  
+/*

+ * Average two byte vectors. (Will always round up.)
+ */
+static LLVMValueRef
+lp_build_pavgb(struct lp_build_context *bld8,
+   LLVMValueRef v0,
+   LLVMValueRef v1)
+{
+   struct gallivm_state *gallivm = bld8->gallivm;
+   LLVMBuilderRef builder = gallivm->builder;
+   assert(bld8->type.width == 8);
+   assert(bld8->type.length == 16 || bld8->type.length == 32);
+   if (HAVE_LLVM < 0x0600) {
+  LLVMValueRef intrargs[2];
+  char *intr_name = bld8->type.length == 32 ? "llvm.x86.avx2.pavg.b" :
+  "llvm.x86.sse2.pavg.b";
+  intrargs[0] = v0;
+  intrargs[1] = v1;
+  return lp_build_intrinsic(builder, intr_name,
+bld8->vec_type, intrargs, 2, 0);
+   } else {
+  /*
+   * Must match llvm's autoupgrade of pavg.b intrinsic to be useful.
+   * You better hope the backend code manages to detect the pattern, and
+   * the pattern doesn't change there...
+   */
+  struct lp_type type_ext = bld8->type;
+  LLVMTypeRef vec_type_ext;
+  LLVMValueRef res;
+  LLVMValueRef ext_one;
+  type_ext.width = 16;
+  vec_type_ext = lp_build_vec_type(gallivm, type_ext);
+  ext_one = lp_build_const_vec(gallivm, type_ext, 1);
+
+  v0 = LLVMBuildZExt(builder, v0, vec_type_ext, "");
+  v1 = LLVMBuildZExt(builder, v1, vec_type_ext, "");
+  res = LLVMBuildAdd(builder, v0, v1, "");
+  res = LLVMBuildAdd(builder, res, ext_one, "");
+  res = LLVMBuildLShr(builder, res, ext_one, "");
+  res = LLVMBuildTrunc(builder, res, bld8->vec_type, "");
+  return res;
+   }
+}
+
  /**
   * Calculate 1/3(v1-v0) + v0
   * and 2*1/3(v1-v0) + v0
@@ -602,13 +646,7 @@ s3tc_dxt1_full_to_rgba_aos(struct gallivm_state *gallivm,
 */
if ((util_cpu_caps.has_sse2 && n == 4) ||
(util_cpu_caps.has_avx2 && n == 8)) {
- LLVMValueRef intrargs[2];
- char *intr_name = n == 8 ? "llvm.x86.avx2.pavg.b" :
-"llvm.x86.sse2.pavg.b";
- intrargs[0] = colors0;
- intrargs[1] = colors1;
- color2_2 = lp_build_intrinsic(builder, intr_name,
-   bld8.vec_type, intrargs, 2, 0);
+ color2_2 = lp_build_pavgb(, colors0, colors1);
   color2_2 = LLVMBuildBitCast(builder, color2_2, bld32.vec_type, "");
}
else {
@@ -1278,8 +1316,7 @@ s3tc_decode_block_dxt1(struct gallivm_state *gallivm,
   /* same interleave as for lerp23 - correct result in 2nd element */
   intrargs[1] = lp_build_interleave2(gallivm, type32, color01, 
color01, 0);
   intrargs[1] = LLVMBuildBitCast(builder, intrargs[1], bld8.vec_type, 
"");
- color2_2 = lp_build_intrinsic(builder, "llvm.x86.sse2.pavg.b",
-   bld8.vec_type, intrargs, 2, 0);
+ color2_2 = lp_build_pavgb(, intrargs[0], intrargs[1]);
}
else {
   LLVMValueRef v01, v0, v1, vhalf;
diff --git a/src/gallium/drivers/llvmpipe/lp_test_format.c 
b/src/gallium/drivers/llvmpipe/lp_test_format.c
index a8aa33d8ae9..885d886cfa9 100644
--- a/src/gallium/drivers/llvmpipe/lp_test_format.c
+++ b/src/gallium/drivers/llvmpipe/lp_test_format.c
@@ -44,8 +44,6 @@
  
  #include "lp_test.h"
  
-#define USE_TEXTURE_CACHE 1

-
  static struct lp_build_format_cache *cache_ptr;
  
  void

@@ -80,7 +78,8 @@ typedef void
  static LLVMValueRef
  add_fetch_rgba_test(struct gallivm_state *gallivm, unsigned verbose,
  

Re: [Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush (v2)

[Tomasz Figa]

Hi everyone,

On Fri, Dec 14, 2018 at 5:17 PM Tomasz Figa  wrote:
>
> If there is no last fence, due to no rendering happening yet, just
> create a new signaled fence and return it, to match the expectations of
> the EGL sync fence API.
>
> Fixes random "Could not create sync fence 0x3003" assertion failures from
> Skia on Android, coming from the following code:
>
> https://android.googlesource.com/platform/frameworks/base/+/master/libs/hwui/pipeline/skia/SkiaOpenGLPipeline.cpp#427
>
> Reproducible especially with thread count >= 4.
>
> One could make the driver always keep the reference to the last fence,
> but:
>
>  - the driver seems to explicitly destroy the fence whenever a rendering
>pass completes and changing that would require a significant functional
>change to the code. (Specifically, in lp_scene_end_rasterization().)
>
>  - it still wouldn't solve the problem of an EGL sync fence being created
>and waited on without any rendering happening at all, which is
>also likely to happen with Android code pointed to in the commit.
>
> Therefore, the simple approach of always creating a fence is taken,
> similarly to other drivers, such as radeonsi.
>
> Tested with piglit llvmpipe suite with no regressions and following
> tests fixed:
>
> egl_khr_fence_sync
>  conformance
>   eglclientwaitsynckhr_flag_sync_flush
>   eglclientwaitsynckhr_nonzero_timeout
>   eglclientwaitsynckhr_zero_timeout
>   eglcreatesynckhr_default_attributes
>   eglgetsyncattribkhr_invalid_attrib
>   eglgetsyncattribkhr_sync_status
>
> v2:
>  - remove the useless lp_fence_reference() dance (Nicolai),
>  - explain why creating the dummy fence is the right approach.
>
> Signed-off-by: Tomasz Figa 
> ---
>  src/gallium/drivers/llvmpipe/lp_setup.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
> b/src/gallium/drivers/llvmpipe/lp_setup.c
> index b087369473..e72e119c8a 100644
> --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> @@ -361,6 +361,8 @@ lp_setup_flush( struct lp_setup_context *setup,
>
> if (fence) {
>lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
> +  if (!*fence)
> + *fence = (struct pipe_fence_handle *)lp_fence_create(0);
> }
>  }
>
> --
> 2.20.0.405.gbc1bbc6f85-goog
>

Gentle ping. :)

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

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Stuart Young]

Sorry. Copy-paste decided to send a msg rather than paste into it.

On Fri, 21 Dec 2018 at 17:36, Stuart Young  wrote:

> On Fri, 21 Dec 2018 at 04:18, Eero Tamminen 
> wrote:
>
>> On 20.12.2018 4.40, Stuart Young wrote:
>> > Could this be reduced this from an error to a warning, with the
>> > command-line option suppressing the warning?
>> >
>> > Perhaps as well as producing the warning, the build could sleep for say
>> > 30 seconds after producing the warning message. This would be
>> noticeable
>> > if you're building it yourself (which would definitely get the message
>> > out there), but wouldn't stop automated build processes (as it's not
>> > stopping, just sleeping).
>> >
>> > At a later date (when meson has more exposure) then perhaps we could
>> > move from a warning to an error.
>> >
>> > Thoughts?
>>
>> So it would take 2 releases i.e. about 1/2 year?
>>
>
> Not necessarily. IMO if there's enough consensus between 19.0 and 19.1,
> then changing it to an error could happen then. I'm basing this on the fact
> that every .0 release specifically says something like this:
>

 Mesa 18.3.0 is a new development release. People who are concerned with
stability and reliability should stick with a previous release or wait for
Mesa 18.3.1.

Of course, this isn't my call. I'm just trying to suggest ways to break the
deadlock.

* In next release autotools build is going to warn that meson should be
>> used instead, as autotools support will be eventually removed.
>>
>> * Next release from that:
>>- errors out if specific option isn't used for doing building with
>> autotools
>>- tells that autotools support will be removed in following release
>>
>> * Release after that removes autotools support.
>>
>>
>> (I assume Emil would be the person supporting Autotools during this as
>> he had already volunteered for it.)
>>
>>
>> While I think above is closer to how other large projects do deprecation
>> in general (= have clear deprecation period/releases), build system
>> changes are probably more often done just with flag day (early in the
>> release cycle, as maintaining multiple build systems can be pretty large
>> pain).
>>
>
> Yes, but at the moment we have no consensus and a deadlock on the issue.
>

-- 
Stuart Young (aka Cefiar)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Stuart Young]

On Fri, 21 Dec 2018 at 04:18, Eero Tamminen 
wrote:

> On 20.12.2018 4.40, Stuart Young wrote:
> > Could this be reduced this from an error to a warning, with the
> > command-line option suppressing the warning?
> >
> > Perhaps as well as producing the warning, the build could sleep for say
> > 30 seconds after producing the warning message. This would be noticeable
> > if you're building it yourself (which would definitely get the message
> > out there), but wouldn't stop automated build processes (as it's not
> > stopping, just sleeping).
> >
> > At a later date (when meson has more exposure) then perhaps we could
> > move from a warning to an error.
> >
> > Thoughts?
>
> So it would take 2 releases i.e. about 1/2 year?
>

Not necessarily. IMO if there's enough consensus between 19.0 and 19.1,
then changing it to an error could happen then. I'm basing this on the fact
that every .0 release specifically says something like this:



>
> * In next release autotools build is going to warn that meson should be
> used instead, as autotools support will be eventually removed.
>
> * Next release from that:
>- errors out if specific option isn't used for doing building with
> autotools
>- tells that autotools support will be removed in following release
>
> * Release after that removes autotools support.
>
>
> (I assume Emil would be the person supporting Autotools during this as
> he had already volunteered for it.)
>
>
> While I think above is closer to how other large projects do deprecation
> in general (= have clear deprecation period/releases), build system
> changes are probably more often done just with flag day (early in the
> release cycle, as maintaining multiple build systems can be pretty large
> pain).
>

Yes, but at the moment we have no consensus and a deadlock on the issue.



-- 
Stuart Young (aka Cefiar)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallivm: abort when trying to use non-existing intrinsic

[sroland]

From: Roland Scheidegger 

Whenever llvm removes an intrinsic (we're using), we're hitting segfaults
due to llvm doing calls to address 0 in the jitted code instead.
However, Jose figured out we can actually detect this with
LLVMGetIntrinsicID(), so use this to abort, so we don't have to wonder
what got broken. (Of course, someone still needs to fix the code to
no longer use this intrinsic.)
---
 src/gallium/auxiliary/gallivm/lp_bld_intr.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_intr.c 
b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
index 74ed16f33f0..c9df136b103 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
@@ -241,6 +241,16 @@ lp_build_intrinsic(LLVMBuilderRef builder,
 
   function = lp_declare_intrinsic(module, name, ret_type, arg_types, 
num_args);
 
+  /*
+   * If llvm removes an intrinsic we use, we'll hit this abort (rather
+   * than a call to address zero in the jited code).
+   */
+  if (LLVMGetIntrinsicID(function) == 0) {
+ printf("llvm (version 0x%x) found no intrinsic for %s, going to 
crash...\n",
+HAVE_LLVM, name);
+ abort();
+  }
+
   if (!set_callsite_attrs)
  lp_add_func_attributes(function, attr_mask);
 
-- 
2.17.1

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

[Mesa-dev] [Bug 109107] gallium/st/va: change va max_profiles when using Radeon VCN Hardware

[bugzilla-daemon]

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

--- Comment #1 from zhoulei  ---
More details:

In function VASupportedProfiles::GetSupportedVAProfiles,
https://github.com/chromium/chromium/blob/master/media/gpu/vaapi/vaapi_wrapper.cc#L571

const int max_profiles = vaMaxNumProfiles(va_display_);
vaMaxNumProfiles will return (PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH -
PIPE_VIDEO_PROFILE_UNKNOWN) in mesa.

 int num_supported_profiles;
  VAStatus va_res = vaQueryConfigProfiles(va_display_, _profiles[0],
  _supported_profiles);
  VA_SUCCESS_OR_RETURN(va_res, "vaQueryConfigProfiles failed", false);
  if (num_supported_profiles < 0 || num_supported_profiles > max_profiles) {
LOG(ERROR) << "vaQueryConfigProfiles returned: " << num_supported_profiles;
return false;
  }

(num_supported_profiles > max_profiles) is true when using RAVEN APU, so
hardware decoder is failed.

-- 
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] gallivm: use llvm jit code for decoding s3tc

[Roland Scheidegger]

Ahh great find!
I tried it out and it works, if it's not an intrinsic it will return 0,
otherwise some number (no idea how they are enumerated, but who cares).

Roland


Am 21.12.18 um 00:56 schrieb Jose Fonseca:
> There's an function -- LLVMGetIntrinsicID -- I wonder if we can use it
> to trap unsupported intrinsics?
> 
> Jose
> 
> On 20/12/2018 22:09, Roland Scheidegger wrote:
>> Am 20.12.18 um 16:56 schrieb Michel Dänzer:
>>> On 2018-12-19 4:51 a.m., srol...@vmware.com wrote:
 From: Roland Scheidegger 

 This is (much) faster than using the util fallback.
 (Note that there's two methods here, one would use a cache, similar to
 the existing code (although the cache was disabled), except the block
 decode is done with jit code, the other directly decodes the required
 pixels. For now don't use the cache (being direct-mapped is suboptimal,
 but it's difficult to come up with something better which doesn't have
 too much overhead.)
>>>
>>> This change made lp_test_format segfault on my Ryzen 7 1700, both using
>>> LLVM 7 and current SVN HEAD. Not much information in the backtrace
>>> unfortunately:
>>>
>>
>> Ahh I failed to test with newer llvm versions (it works with llvm 5.0 at
>> least).
>> It is (once again...) due to intrinsics disappearing from llvm.
>> I especially hate it that there's seemingly no way to detect if an
>> intrinsic has disappeared, since llvm will just replace it will calls to
>> address 0 if the intrinsic doesn't exist nowadays...
>> Probably it's the llvm.x86.sse2.pavg.b intrinsic, I'll fix it...
>>
>> Roland
>>
>>
>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x in ?? ()
>>> (gdb) bt
>>> #0  0x in ?? ()
>>> #1  0x77fcd16a in ?? ()
>>> #2  0x2c2c2c2caeaeaeae in ?? ()
>>> #3  0x979797976f6f6f6f in ?? ()
>>> #4  0x20b0d7f2 in ?? ()
>>> #5  0x976f2cae in ?? ()
>>> #6  0x0089625d008eb099 in ?? ()
>>> #7  0x7b8487218483a821 in ?? ()
>>> #8  0x008414210094ffd6 in ?? ()
>>> #9  0x007bef9400739629 in ?? ()
>>> #10 0x0069 in ?? ()
>>> #11 0x06d0 in ?? ()
>>> #12 0x7fffe490 in ?? ()
>>> #13 0x5593f040 in ?? ()
>>> #14 0x7fffe430 in ?? ()
>>> #15 0x77fcd053 in ?? ()
>>> #16 0x77fcd000 in ?? ()
>>> #17 0x556fd618 in util_format_test_cases ()
>>> #18 0x558c0780 in ?? ()
>>> #19 0x7fffe490 in ?? ()
>>> #20 0x556fd618 in util_format_test_cases ()
>>> #21 0x555667cc in test_format_float (verbose=,
>>> desc=0x7fffe4a0, fp=0x0) at
>>> ../src/gallium/drivers/llvmpipe/lp_test_format.c:184
>>> #22 test_one (verbose=, format_desc=0x7fffe4a0,
>>> fp=0x0) at ../src/gallium/drivers/llvmpipe/lp_test_format.c:342
>>> #23 test_all (verbose=, fp=0x0) at
>>> ../src/gallium/drivers/llvmpipe/lp_test_format.c:395
>>> #24 0x5556621f in main (argc=1, argv=0x7fffe628) at
>>> ../src/gallium/drivers/llvmpipe/lp_test_main.c:419
>>>
>>>
>>
> 

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

[Mesa-dev] [PATCH] gallivm: don't use pavg.b intrinsic on llvm >= 6.0

[sroland]

From: Roland Scheidegger 

This intrinsic disppeared with llvm 6.0, using it ends up in segfaults
(due to llvm issuing call to NULL address in the jited shaders).
Add code doing the same thing as the autoupgrade code in llvm so it
can be matched and replaced back with a pavgb.

While here, also improve lp_test_format, so it tests both with and without
cache (as it was, it tested the cache versions only, whereas cache is
actually disabled in llvmpipe, and in any case even with it enabled
vertex and geometry shaders wouldn't use it). (Although at least for
the unorm8 uncached fetch, the code is still quite different to what
llvmpipe is using, since that would use unorm8x16 type, whereas
the test code is using unorm8x4 type, hence disabling some intrinsic
paths.)

Fixes: 6f4083143bb8c478ccfcaef034d183d89b471993
---
 .../auxiliary/gallivm/lp_bld_format_s3tc.c| 55 +--
 src/gallium/drivers/llvmpipe/lp_test_format.c | 91 ++-
 2 files changed, 95 insertions(+), 51 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c 
b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
index 2b143566f24..9561c349dad 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
@@ -457,6 +457,50 @@ color_expand_565_to_(struct gallivm_state *gallivm,
 }
 
 
+/*
+ * Average two byte vectors. (Will always round up.)
+ */
+static LLVMValueRef
+lp_build_pavgb(struct lp_build_context *bld8,
+   LLVMValueRef v0,
+   LLVMValueRef v1)
+{
+   struct gallivm_state *gallivm = bld8->gallivm;
+   LLVMBuilderRef builder = gallivm->builder;
+   assert(bld8->type.width == 8);
+   assert(bld8->type.length == 16 || bld8->type.length == 32);
+   if (HAVE_LLVM < 0x0600) {
+  LLVMValueRef intrargs[2];
+  char *intr_name = bld8->type.length == 32 ? "llvm.x86.avx2.pavg.b" :
+  "llvm.x86.sse2.pavg.b";
+  intrargs[0] = v0;
+  intrargs[1] = v1;
+  return lp_build_intrinsic(builder, intr_name,
+bld8->vec_type, intrargs, 2, 0);
+   } else {
+  /*
+   * Must match llvm's autoupgrade of pavg.b intrinsic to be useful.
+   * You better hope the backend code manages to detect the pattern, and
+   * the pattern doesn't change there...
+   */
+  struct lp_type type_ext = bld8->type;
+  LLVMTypeRef vec_type_ext;
+  LLVMValueRef res;
+  LLVMValueRef ext_one;
+  type_ext.width = 16;
+  vec_type_ext = lp_build_vec_type(gallivm, type_ext);
+  ext_one = lp_build_const_vec(gallivm, type_ext, 1);
+
+  v0 = LLVMBuildZExt(builder, v0, vec_type_ext, "");
+  v1 = LLVMBuildZExt(builder, v1, vec_type_ext, "");
+  res = LLVMBuildAdd(builder, v0, v1, "");
+  res = LLVMBuildAdd(builder, res, ext_one, "");
+  res = LLVMBuildLShr(builder, res, ext_one, "");
+  res = LLVMBuildTrunc(builder, res, bld8->vec_type, "");
+  return res;
+   }
+}
+
 /**
  * Calculate 1/3(v1-v0) + v0
  * and 2*1/3(v1-v0) + v0
@@ -602,13 +646,7 @@ s3tc_dxt1_full_to_rgba_aos(struct gallivm_state *gallivm,
*/
   if ((util_cpu_caps.has_sse2 && n == 4) ||
   (util_cpu_caps.has_avx2 && n == 8)) {
- LLVMValueRef intrargs[2];
- char *intr_name = n == 8 ? "llvm.x86.avx2.pavg.b" :
-"llvm.x86.sse2.pavg.b";
- intrargs[0] = colors0;
- intrargs[1] = colors1;
- color2_2 = lp_build_intrinsic(builder, intr_name,
-   bld8.vec_type, intrargs, 2, 0);
+ color2_2 = lp_build_pavgb(, colors0, colors1);
  color2_2 = LLVMBuildBitCast(builder, color2_2, bld32.vec_type, "");
   }
   else {
@@ -1278,8 +1316,7 @@ s3tc_decode_block_dxt1(struct gallivm_state *gallivm,
  /* same interleave as for lerp23 - correct result in 2nd element */
  intrargs[1] = lp_build_interleave2(gallivm, type32, color01, color01, 
0);
  intrargs[1] = LLVMBuildBitCast(builder, intrargs[1], bld8.vec_type, 
"");
- color2_2 = lp_build_intrinsic(builder, "llvm.x86.sse2.pavg.b",
-   bld8.vec_type, intrargs, 2, 0);
+ color2_2 = lp_build_pavgb(, intrargs[0], intrargs[1]);
   }
   else {
  LLVMValueRef v01, v0, v1, vhalf;
diff --git a/src/gallium/drivers/llvmpipe/lp_test_format.c 
b/src/gallium/drivers/llvmpipe/lp_test_format.c
index a8aa33d8ae9..885d886cfa9 100644
--- a/src/gallium/drivers/llvmpipe/lp_test_format.c
+++ b/src/gallium/drivers/llvmpipe/lp_test_format.c
@@ -44,8 +44,6 @@
 
 #include "lp_test.h"
 
-#define USE_TEXTURE_CACHE 1
-
 static struct lp_build_format_cache *cache_ptr;
 
 void
@@ -80,7 +78,8 @@ typedef void
 static LLVMValueRef
 add_fetch_rgba_test(struct gallivm_state *gallivm, unsigned verbose,
 const struct util_format_description *desc,
-struct lp_type 

Re: [Mesa-dev] [PATCH] gallivm: use llvm jit code for decoding s3tc

[Jose Fonseca]

There's an function -- LLVMGetIntrinsicID -- I wonder if we can use it 
to trap unsupported intrinsics?


Jose

On 20/12/2018 22:09, Roland Scheidegger wrote:

Am 20.12.18 um 16:56 schrieb Michel Dänzer:

On 2018-12-19 4:51 a.m., srol...@vmware.com wrote:

From: Roland Scheidegger 

This is (much) faster than using the util fallback.
(Note that there's two methods here, one would use a cache, similar to
the existing code (although the cache was disabled), except the block
decode is done with jit code, the other directly decodes the required
pixels. For now don't use the cache (being direct-mapped is suboptimal,
but it's difficult to come up with something better which doesn't have
too much overhead.)


This change made lp_test_format segfault on my Ryzen 7 1700, both using
LLVM 7 and current SVN HEAD. Not much information in the backtrace
unfortunately:



Ahh I failed to test with newer llvm versions (it works with llvm 5.0 at
least).
It is (once again...) due to intrinsics disappearing from llvm.
I especially hate it that there's seemingly no way to detect if an
intrinsic has disappeared, since llvm will just replace it will calls to
address 0 if the intrinsic doesn't exist nowadays...
Probably it's the llvm.x86.sse2.pavg.b intrinsic, I'll fix it...

Roland




Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x77fcd16a in ?? ()
#2  0x2c2c2c2caeaeaeae in ?? ()
#3  0x979797976f6f6f6f in ?? ()
#4  0x20b0d7f2 in ?? ()
#5  0x976f2cae in ?? ()
#6  0x0089625d008eb099 in ?? ()
#7  0x7b8487218483a821 in ?? ()
#8  0x008414210094ffd6 in ?? ()
#9  0x007bef9400739629 in ?? ()
#10 0x0069 in ?? ()
#11 0x06d0 in ?? ()
#12 0x7fffe490 in ?? ()
#13 0x5593f040 in ?? ()
#14 0x7fffe430 in ?? ()
#15 0x77fcd053 in ?? ()
#16 0x77fcd000 in ?? ()
#17 0x556fd618 in util_format_test_cases ()
#18 0x558c0780 in ?? ()
#19 0x7fffe490 in ?? ()
#20 0x556fd618 in util_format_test_cases ()
#21 0x555667cc in test_format_float (verbose=, 
desc=0x7fffe4a0, fp=0x0) at ../src/gallium/drivers/llvmpipe/lp_test_format.c:184
#22 test_one (verbose=, format_desc=0x7fffe4a0, fp=0x0) at 
../src/gallium/drivers/llvmpipe/lp_test_format.c:342
#23 test_all (verbose=, fp=0x0) at 
../src/gallium/drivers/llvmpipe/lp_test_format.c:395
#24 0x5556621f in main (argc=1, argv=0x7fffe628) at 
../src/gallium/drivers/llvmpipe/lp_test_main.c:419






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

[Mesa-dev] MR: anv: don't do partial resolve on layer > 0

[Lionel Landwerlin]

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/40

A couple of bugs have been reported on multisampled & multilayered 
surfaces in Anv.
After having found what I thought was a workaround, it turned out to be 
an actual fix.


Please visit the URL above for a full explanation.

I also wrote a crucible test for this : 
https://patchwork.freedesktop.org/patch/265741/
It's really straight forward, so if you consider reviewing this, please 
look at the test too :)


Cheers,

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

[Mesa-dev] MR: i965: Enable software support for ARB_gpu_shader_fp64/ARB_gpu_shader_int64

[Matt Turner]

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/39

Some upcoming Intel platforms do not have 64-bit type support. This
series implements support for ARB_gpu_shader_fp64 and
ARB_gpu_shader_int64 via software implementations.

To do this we add a .glsl file containing GLSL implementations of
various 64-bit operations (e.g., double-precision addition) and
compile them to NIR when we see that the "user shader" uses some
64-bit operations. Lowering is done in nir_lower_doubles() but a
little differently than normal: we convert the to-be-lowered
operations into function calls of the software routines and ultimately
inline the code. In the future we may wish to use real function calls.

I have a few known test failures (seem to be mostly about
ARB_enhanced_layouts -- which makes since given that we're faking
64-bit types) but I think this is good enough to merge. I hope after
review you will agree!

 src/compiler/Makefile.glsl.am  |7 +
 src/compiler/glsl/ast_function.cpp |5 +-
 src/compiler/glsl/float64.glsl | 1744 
 src/compiler/glsl/glsl_to_nir.cpp  |  125 +-
 src/compiler/glsl/meson.build  |   10 +-
 src/compiler/glsl/xxd.py   |  109 ++
 src/compiler/nir/nir.c |1 +
 src/compiler/nir/nir.h |   34 +-
 src/compiler/nir/nir_algebraic.py  |7 +-
 src/compiler/nir/nir_builder.h |1 +
 src/compiler/nir/nir_clone.c   |1 +
 src/compiler/nir/nir_gather_info.c |5 +
 src/compiler/nir/nir_inline_functions.c|4 +
 src/compiler/nir/nir_lower_constant_initializers.c |   32 +-
 src/compiler/nir/nir_lower_double_ops.c|  208 ++-
 src/compiler/nir/nir_lower_global_vars_to_local.c  |8 +
 src/compiler/nir/nir_lower_int64.c |  471 +-
 src/compiler/nir/nir_lower_load_const_to_scalar.c  |7 +-
 src/compiler/nir/nir_lower_returns.c   |4 +
 src/compiler/nir/nir_lower_var_copies.c|7 +-
 src/compiler/nir/nir_lower_vars_to_ssa.c   |6 +-
 src/compiler/nir/nir_opt_constant_folding.c|7 +-
 src/compiler/nir/nir_opt_copy_prop_vars.c  |4 +
 src/compiler/nir/nir_opt_copy_propagate.c  |4 +
 src/compiler/nir/nir_opt_cse.c |7 +-
 src/compiler/nir/nir_opt_dce.c |7 +-
 src/compiler/nir/nir_opt_dead_cf.c |7 +-
 src/compiler/nir/nir_opt_if.c  |4 +
 src/compiler/nir/nir_opt_peephole_select.c |7 +-
 src/compiler/nir/nir_opt_remove_phis.c |4 +
 src/compiler/nir/nir_opt_undef.c   |7 +-
 src/compiler/nir/nir_serialize.c   |4 +
 src/compiler/nir/nir_split_var_copies.c|4 +
 src/compiler/shader_info.h |5 +
 src/compiler/spirv/spirv_to_nir.c  |1 +
 src/intel/compiler/brw_eu_emit.c   |   12 +-
 src/intel/compiler/brw_fs.cpp  |   68 +-
 src/intel/compiler/brw_fs.h|2 +-
 src/intel/compiler/brw_fs_combine_constants.cpp|7 +-
 src/intel/compiler/brw_fs_generator.cpp|3 +-
 src/intel/compiler/brw_fs_nir.cpp  |4 +-
 src/intel/compiler/brw_fs_reg_allocate.cpp |2 +-
 src/intel/compiler/brw_fs_register_coalesce.cpp|8 +-
 src/intel/compiler/brw_nir.c   |   91 +-
 src/intel/compiler/brw_reg.h   |7 +-
 src/intel/compiler/brw_schedule_instructions.cpp   |   14 +-
 src/intel/compiler/brw_vec4.cpp|   12 +-
 src/intel/compiler/brw_vec4.h  |2 +-
 src/intel/compiler/brw_vec4_reg_allocate.cpp   |   12 +-
 src/intel/compiler/brw_vec4_visitor.cpp|4 +-
 src/intel/compiler/gen6_gs_visitor.cpp |4 +-
 src/mesa/drivers/dri/i965/Makefile.am  |1 +
 src/mesa/drivers/dri/i965/brw_program.c|   61 +
 src/mesa/drivers/dri/i965/intel_extensions.c   |8 +-
 src/mesa/drivers/dri/i965/meson.build  |2 +-
 55 files changed, 3061 insertions(+), 131 deletions(-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: use llvm jit code for decoding s3tc

[Roland Scheidegger]

Am 20.12.18 um 16:56 schrieb Michel Dänzer:
> On 2018-12-19 4:51 a.m., srol...@vmware.com wrote:
>> From: Roland Scheidegger 
>>
>> This is (much) faster than using the util fallback.
>> (Note that there's two methods here, one would use a cache, similar to
>> the existing code (although the cache was disabled), except the block
>> decode is done with jit code, the other directly decodes the required
>> pixels. For now don't use the cache (being direct-mapped is suboptimal,
>> but it's difficult to come up with something better which doesn't have
>> too much overhead.)
> 
> This change made lp_test_format segfault on my Ryzen 7 1700, both using
> LLVM 7 and current SVN HEAD. Not much information in the backtrace
> unfortunately:
> 

Ahh I failed to test with newer llvm versions (it works with llvm 5.0 at
least).
It is (once again...) due to intrinsics disappearing from llvm.
I especially hate it that there's seemingly no way to detect if an
intrinsic has disappeared, since llvm will just replace it will calls to
address 0 if the intrinsic doesn't exist nowadays...
Probably it's the llvm.x86.sse2.pavg.b intrinsic, I'll fix it...

Roland



> Program received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()
> (gdb) bt
> #0  0x in ?? ()
> #1  0x77fcd16a in ?? ()
> #2  0x2c2c2c2caeaeaeae in ?? ()
> #3  0x979797976f6f6f6f in ?? ()
> #4  0x20b0d7f2 in ?? ()
> #5  0x976f2cae in ?? ()
> #6  0x0089625d008eb099 in ?? ()
> #7  0x7b8487218483a821 in ?? ()
> #8  0x008414210094ffd6 in ?? ()
> #9  0x007bef9400739629 in ?? ()
> #10 0x0069 in ?? ()
> #11 0x06d0 in ?? ()
> #12 0x7fffe490 in ?? ()
> #13 0x5593f040 in ?? ()
> #14 0x7fffe430 in ?? ()
> #15 0x77fcd053 in ?? ()
> #16 0x77fcd000 in ?? ()
> #17 0x556fd618 in util_format_test_cases ()
> #18 0x558c0780 in ?? ()
> #19 0x7fffe490 in ?? ()
> #20 0x556fd618 in util_format_test_cases ()
> #21 0x555667cc in test_format_float (verbose=, 
> desc=0x7fffe4a0, fp=0x0) at 
> ../src/gallium/drivers/llvmpipe/lp_test_format.c:184
> #22 test_one (verbose=, format_desc=0x7fffe4a0, fp=0x0) at 
> ../src/gallium/drivers/llvmpipe/lp_test_format.c:342
> #23 test_all (verbose=, fp=0x0) at 
> ../src/gallium/drivers/llvmpipe/lp_test_format.c:395
> #24 0x5556621f in main (argc=1, argv=0x7fffe628) at 
> ../src/gallium/drivers/llvmpipe/lp_test_main.c:419
> 
> 

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

[Mesa-dev] [PATCH] st/nine: Enable debug info if NDEBUG is not set

[Axel Davy]

We want to have debug info as well if using
meson's debugoptimized when ndebug is off.

Signed-off-by: Axel Davy 
---
 src/gallium/state_trackers/nine/basetexture9.c |  6 +++---
 src/gallium/state_trackers/nine/basetexture9.h |  2 +-
 src/gallium/state_trackers/nine/nine_debug.h   | 10 +-
 src/gallium/state_trackers/nine/nine_dump.c|  4 ++--
 src/gallium/state_trackers/nine/nine_dump.h|  6 +++---
 src/gallium/state_trackers/nine/nine_ff.c  |  2 +-
 src/gallium/state_trackers/nine/nine_state.c   |  2 +-
 src/gallium/state_trackers/nine/surface9.c |  4 ++--
 src/gallium/state_trackers/nine/surface9.h |  2 +-
 src/gallium/state_trackers/nine/volume9.c  |  2 +-
 10 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/src/gallium/state_trackers/nine/basetexture9.c 
b/src/gallium/state_trackers/nine/basetexture9.c
index 911eee6da20..441a0817461 100644
--- a/src/gallium/state_trackers/nine/basetexture9.c
+++ b/src/gallium/state_trackers/nine/basetexture9.c
@@ -28,7 +28,7 @@
 #include "cubetexture9.h"
 #include "volumetexture9.h"
 
-#ifdef DEBUG
+#if defined(DEBUG) || !defined(NDEBUG)
 #include "nine_pipe.h"
 #include "nine_dump.h"
 #endif
@@ -605,7 +605,7 @@ NineBaseTexture9_UnLoad( struct NineBaseTexture9 *This )
 BASETEX_REGISTER_UPDATE(This);
 }
 
-#ifdef DEBUG
+#if defined(DEBUG) || !defined(NDEBUG)
 void
 NineBaseTexture9_Dump( struct NineBaseTexture9 *This )
 {
@@ -620,4 +620,4 @@ NineBaseTexture9_Dump( struct NineBaseTexture9 *This )
 This->base.info.array_size, This->base.info.last_level,
 This->managed.lod, This->managed.lod_resident);
 }
-#endif /* DEBUG */
+#endif /* DEBUG || !NDEBUG */
diff --git a/src/gallium/state_trackers/nine/basetexture9.h 
b/src/gallium/state_trackers/nine/basetexture9.h
index 10a7cea46da..19899c65825 100644
--- a/src/gallium/state_trackers/nine/basetexture9.h
+++ b/src/gallium/state_trackers/nine/basetexture9.h
@@ -150,7 +150,7 @@ NineBindTextureToDevice( struct NineDevice9 *device,
 nine_bind(slot, tex);
 }
 
-#ifdef DEBUG
+#if defined(DEBUG) || !defined(NDEBUG)
 void
 NineBaseTexture9_Dump( struct NineBaseTexture9 *This );
 #else
diff --git a/src/gallium/state_trackers/nine/nine_debug.h 
b/src/gallium/state_trackers/nine/nine_debug.h
index 841438a66f8..2bbb73ef96a 100644
--- a/src/gallium/state_trackers/nine/nine_debug.h
+++ b/src/gallium/state_trackers/nine/nine_debug.h
@@ -33,7 +33,7 @@ _nine_debug_printf( unsigned long flag,
 
 #define ERR(fmt, ...) _nine_debug_printf(DBG_ERROR, __FUNCTION__, fmt, ## 
__VA_ARGS__)
 
-#ifdef DEBUG
+#if defined(DEBUG) || !defined(NDEBUG)
 #define WARN(fmt, ...) _nine_debug_printf(DBG_WARN, __FUNCTION__, fmt, ## 
__VA_ARGS__)
 #define WARN_ONCE(fmt, ...) \
 do { \
@@ -48,7 +48,7 @@ _nine_debug_printf( unsigned long flag,
 #define WARN_ONCE(fmt, ...)
 #endif
 
-#ifdef DEBUG
+#if defined(DEBUG) || !defined(NDEBUG)
 #define DBG_FLAG(flag, fmt, ...) \
 _nine_debug_printf(flag, __FUNCTION__, fmt, ## __VA_ARGS__)
 #else
@@ -90,7 +90,7 @@ _nine_stub( const char *file,
 const char *func,
 unsigned line );
 
-#ifdef DEBUG
+#if defined(DEBUG) || !defined(NDEBUG)
 #define STUB(ret) \
 do { \
 _nine_stub(__FILE__, __FUNCTION__, __LINE__); \
@@ -104,7 +104,7 @@ _nine_stub( const char *file,
  * macro is designed to be used in conditionals ala
  * if (user_error(required condition)) { assertion failed }
  * It also prints debug message if the assertion fails. */
-#ifdef DEBUG
+#if defined(DEBUG) || !defined(NDEBUG)
 #define user_error(x) \
 (!(x) ? (DBG_FLAG(DBG_USER, "User assertion failed: `%s'\n", #x), TRUE) \
   : FALSE)
@@ -112,7 +112,7 @@ _nine_stub( const char *file,
 #define user_error(x) (!(x) ? TRUE : FALSE)
 #endif
 
-#ifdef DEBUG
+#if defined(DEBUG) || !defined(NDEBUG)
 #define user_warn(x) \
 if ((x)) { DBG_FLAG(DBG_USER, "User warning: `%s'\n", #x); }
 #else
diff --git a/src/gallium/state_trackers/nine/nine_dump.c 
b/src/gallium/state_trackers/nine/nine_dump.c
index 1ca550586e4..85ee266defb 100644
--- a/src/gallium/state_trackers/nine/nine_dump.c
+++ b/src/gallium/state_trackers/nine/nine_dump.c
@@ -8,7 +8,7 @@
 
 #include "nine_dump.h"
 
-#ifdef DEBUG
+#if defined(DEBUG) || !defined(NDEBUG)
 
 static char __thread tls[128];
 
@@ -810,4 +810,4 @@ nine_dump_D3DCAPS9(unsigned ch, const D3DCAPS9 *caps)
 FREE(s);
 }
 
-#endif /* DEBUG */
+#endif /* DEBUG || !NDEBUG */
diff --git a/src/gallium/state_trackers/nine/nine_dump.h 
b/src/gallium/state_trackers/nine/nine_dump.h
index a0ffe7bf6ab..72342557d77 100644
--- a/src/gallium/state_trackers/nine/nine_dump.h
+++ b/src/gallium/state_trackers/nine/nine_dump.h
@@ -16,7 +16,7 @@ const char *nine_D3DPRESENTFLAG_to_str(DWORD);
 const char *nine_D3DLOCK_to_str(DWORD);
 const char *nine_D3DSAMP_to_str(DWORD);
 
-#ifdef DEBUG
+#if defined(DEBUG) || !defined(NDEBUG)
 
 void
 nine_dump_D3DADAPTER_IDENTIFIER9(unsigned, const D3DADAPTER_IDENTIFIER9 *);
@@ -29,7 +29,7 @@ 

Re: [Mesa-dev] [PATCH 1/2] vc4: Wire up core pipe_debug_callback

[Rhys Kidd]

Awesome, thanks! Apologies that I was unable to get around to looking at
your feedback in the intervening period of time.

On Thu, Dec 20, 2018 at 2:34 PM Eric Anholt  wrote:

> Eric Anholt  writes:
>
> > [ Unknown signature status ]
> > Rhys Kidd  writes:
> >
> >> Signed-off-by: Rhys Kidd 
> >
> > Does this actually do anything for us, though?  Shouldn't we be hooking
> > up our perf_debug() calls to it?
>
> I hooked up perf_debug(), extended the commit messages, and pushed.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] EGL/mesa: Initial write up fot MESA_query_driver

[Rob Clark]

On Sat, Dec 15, 2018 at 12:27 PM Veluri Mithun  wrote:
>
> Hi Everyone,
>
> we can obtain DRM device file from eglQueryDeviceStringEXT fun of 
> EGL_EXT_device_query extension. But, how to retrieve name, configs from that?
>
> Can we get the name of the matched driver for a particular display from any 
> of the EGLDriver->API ?? (EGL API dispatch table)
>
> And looking at x11 implementation of getDrvierConfig, I finally reached this 
> file 
> https://gitlab.freedesktop.org/mesa/mesa/blob/master/include/GL/internal/dri_interface.h#L1828
>  and unable to find the implementation of that getXml function. Can we use 
> the same function here?
>

from the looks of it, that is pipe_loader_get_driinfo_xml() for
gallium drivers.. and I guess you could reuse it

BR,
-R

> Please let me know what do you think about this.
>
> Thanks,
> Veluri.
>
> On Sat, Dec 15, 2018 at 10:25 PM Veluri Mithun  
> wrote:
>>
>> Signed-off-by: Veluri Mithun 
>> ---
>>  docs/specs/EGL_MESA_query_driver.txt | 54 
>>  1 file changed, 54 insertions(+)
>>  create mode 100644 docs/specs/EGL_MESA_query_driver.txt
>>
>> diff --git a/docs/specs/EGL_MESA_query_driver.txt 
>> b/docs/specs/EGL_MESA_query_driver.txt
>> new file mode 100644
>> index 00..315f02920f
>> --- /dev/null
>> +++ b/docs/specs/EGL_MESA_query_driver.txt
>> @@ -0,0 +1,54 @@
>> +Name
>> +
>> +MESA_query_driver
>> +
>> +Name Strings
>> +
>> +EGL_MESA_query_driver
>> +
>> +Contact
>> +
>> +Rob Clark  
>> +Nicolai Hähnle 
>> +
>> +Contibutors
>> +
>> +Veluri Mithun 
>> +
>> +Status
>> +
>> +XXX - Not complete yet!!! (draft)
>> +
>> +Version
>> +
>> +Version 1, 2018-11-05
>> +
>> +Number
>> +
>> +EGL Extension ###
>> +
>> +Dependencies
>> +
>> +EGL 1.4 is required.
>> +
>> +Overview
>> +
>> +When an application had to query the name of a DRI driver and for
>> +obtaining driver's option list (UTF-8 encoded XML) of a DRI
>> +driver the below functions are useful.
>> +
>> +New Procedures and Functions
>> +
>> +const char* eglGetDriverConfig(EGLDisplay *dpy, EGLDeviceEXT device,
>> +   const char *driverName);
>> +const char* eglGetDisplayDriverName(EGLDisplay *dpy, EGLDeviceEXT 
>> device);
>> +
>> +New Tokens
>> +
>> +
>> +
>> +Issues
>> +
>> +
>> +
>> +Revision History
>> --
>> 2.17.1
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] vc4: Wire up core pipe_debug_callback

[Eric Anholt]

Eric Anholt  writes:

> [ Unknown signature status ]
> Rhys Kidd  writes:
>
>> Signed-off-by: Rhys Kidd 
>
> Does this actually do anything for us, though?  Shouldn't we be hooking
> up our perf_debug() calls to it?

I hooked up perf_debug(), extended the commit messages, and pushed.


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

[Mesa-dev] [PATCH] radv: allow secondary command buffers to inherit unknown framebuffers

[Rhys Perry]

Fixes: f4e499ec79 ('radv: add initial non-conformant radv vulkan driver')
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107986
Signed-off-by: Rhys Perry 
---
 src/amd/vulkan/radv_cmd_buffer.c | 59 ++--
 src/amd/vulkan/radv_meta_clear.c |  8 +
 src/amd/vulkan/radv_private.h|  2 ++
 3 files changed, 50 insertions(+), 19 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index c61310f3fc9..96fe5acb3bf 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -730,6 +730,9 @@ radv_emit_rbplus_state(struct radv_cmd_buffer *cmd_buffer)
struct radv_framebuffer *framebuffer = cmd_buffer->state.framebuffer;
const struct radv_subpass *subpass = cmd_buffer->state.subpass;
 
+   /* FIXME: handle when the framebuffer is unknown in secondary 
framebuffers */
+   assert(!cmd_buffer->inherit_unknown_fb);
+
unsigned sx_ps_downconvert = 0;
unsigned sx_blend_opt_epsilon = 0;
unsigned sx_blend_opt_control = 0;
@@ -1189,19 +1192,22 @@ radv_update_bound_fast_clear_ds(struct radv_cmd_buffer 
*cmd_buffer,
struct radv_framebuffer *framebuffer = cmd_buffer->state.framebuffer;
const struct radv_subpass *subpass = cmd_buffer->state.subpass;
struct radeon_cmdbuf *cs = cmd_buffer->cs;
-   struct radv_attachment_info *att;
-   uint32_t att_idx;
+   struct radv_attachment_info *att = NULL;
 
-   if (!framebuffer || !subpass)
+   if (!subpass)
return;
-
-   att_idx = subpass->depth_stencil_attachment.attachment;
-   if (att_idx == VK_ATTACHMENT_UNUSED)
+   if (!framebuffer && !cmd_buffer->inherit_unknown_fb)
return;
 
-   att = >attachments[att_idx];
-   if (att->attachment->image != image)
-   return;
+   if (framebuffer) {
+   uint32_t att_idx = subpass->depth_stencil_attachment.attachment;
+   if (att_idx == VK_ATTACHMENT_UNUSED)
+   return;
+
+   att = >attachments[att_idx];
+   if (att->attachment->image != image)
+   return;
+   }
 
radeon_set_context_reg_seq(cs, R_028028_DB_STENCIL_CLEAR, 2);
radeon_emit(cs, ds_clear_value.stencil);
@@ -1212,6 +1218,8 @@ radv_update_bound_fast_clear_ds(struct radv_cmd_buffer 
*cmd_buffer,
 */
if ((aspects & VK_IMAGE_ASPECT_DEPTH_BIT) &&
ds_clear_value.depth == 0.0) {
+   assert(att);
+
VkImageLayout layout = subpass->depth_stencil_attachment.layout;
 
radv_update_zrange_precision(cmd_buffer, >ds, image,
@@ -1426,19 +1434,22 @@ radv_update_bound_fast_clear_color(struct 
radv_cmd_buffer *cmd_buffer,
struct radv_framebuffer *framebuffer = cmd_buffer->state.framebuffer;
const struct radv_subpass *subpass = cmd_buffer->state.subpass;
struct radeon_cmdbuf *cs = cmd_buffer->cs;
-   struct radv_attachment_info *att;
-   uint32_t att_idx;
 
-   if (!framebuffer || !subpass)
+   if (!subpass)
return;
-
-   att_idx = subpass->color_attachments[cb_idx].attachment;
-   if (att_idx == VK_ATTACHMENT_UNUSED)
+   if (!framebuffer && !cmd_buffer->inherit_unknown_fb)
return;
 
-   att = >attachments[att_idx];
-   if (att->attachment->image != image)
-   return;
+   if (framebuffer) {
+   struct radv_attachment_info *att;
+   uint32_t att_idx = 
subpass->color_attachments[cb_idx].attachment;
+   if (att_idx == VK_ATTACHMENT_UNUSED)
+   return;
+
+   att = >attachments[att_idx];
+   if (att->attachment->image != image)
+   return;
+   }
 
radeon_set_context_reg_seq(cs, R_028C8C_CB_COLOR0_CLEAR_WORD0 + cb_idx 
* 0x3c, 2);
radeon_emit(cs, color_values[0]);
@@ -2528,6 +2539,7 @@ VkResult radv_BeginCommandBuffer(
cmd_buffer->state.last_first_instance = -1;
cmd_buffer->state.predication_type = -1;
cmd_buffer->usage_flags = pBeginInfo->flags;
+   cmd_buffer->inherit_unknown_fb = false;
 
if (cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_SECONDARY &&
(pBeginInfo->flags & 
VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT)) {
@@ -2535,6 +2547,9 @@ VkResult radv_BeginCommandBuffer(
cmd_buffer->state.framebuffer = 
radv_framebuffer_from_handle(pBeginInfo->pInheritanceInfo->framebuffer);
cmd_buffer->state.pass = 
radv_render_pass_from_handle(pBeginInfo->pInheritanceInfo->renderPass);
 
+   if (cmd_buffer->state.pass && 
!pBeginInfo->pInheritanceInfo->framebuffer)
+   cmd_buffer->inherit_unknown_fb = true;
+
struct radv_subpass *subpass =

_buffer->state.pass->subpasses[pBeginInfo->pInheritanceInfo->subpass];

[Mesa-dev] [Bug 107594] [PATCH] fix crosscompilling with meson

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #4 from Dylan Baker  ---
I'm going to mark this as resolved, please reopen if it's still effecting you.

-- 
You are receiving this mail because:
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 109071] meson --wipe results in Exception: "FileNotFoundError: [Errno 2] No such file or directory"

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

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

--- Comment #6 from Dylan Baker  ---
Upstream patch has landed, this should be resolved for 0.49.1.

-- 
You are receiving this mail because:
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] WIP: meson: allow building DRI loaders without a DRI driver

[Dylan Baker]

Quoting Emil Velikov (2018-12-20 03:07:43)
> On Tue, 18 Dec 2018 at 21:53, Dylan Baker  wrote:
> >
> > Quoting Emil Velikov (2018-12-18 03:09:55)
> > > On Mon, 17 Dec 2018 at 22:27, Matt Turner  wrote:
> > > >
> > > > On Mon, Dec 17, 2018 at 2:12 PM Emil Velikov  
> > > > wrote:
> > > > > Additionally, distributions build latest loader and use it with DRI1
> > > > > era drivers.
> > > >
> > > > I'm curious if there are distributions that still ships the DRI1
> > > > drivers. Do you know which, if any, do?
> > >
> > > Archlinux comes off the top of my head. We had a few others but I've
> > > not looked in 6+ months.
> > >
> > > -Emil
> >
> > pacman says arch still does, but I'm not sure why considering they only 
> > support
> > x86_64 now and half of those GPUs only came with x86 cpus.
> >
> Today one could trivially plug a PCI card into their x86_64 system -
> say a mga or r128 one :-)
> For integrated solutions powered by i810 or unichrome that is less likely.
> 
> -Emil

Yeah, I have a few systems like that. But I don't expect 3d to work with them,
that card is just there to put a linux console on a display :) I guess to each
their own.

Dylan


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] autotools: Deprecate the use of autotools

[Eero Tamminen]

Hi,

On 20.12.2018 4.40, Stuart Young wrote:
Could this be reduced this from an error to a warning, with the 
command-line option suppressing the warning?


Perhaps as well as producing the warning, the build could sleep for say 
30 seconds after producing the warning message. This would be noticeable 
if you're building it yourself (which would definitely get the message 
out there), but wouldn't stop automated build processes (as it's not 
stopping, just sleeping).


At a later date (when meson has more exposure) then perhaps we could 
move from a warning to an error.


Thoughts?


So it would take 2 releases i.e. about 1/2 year?

* In next release autotools build is going to warn that meson should be 
used instead, as autotools support will be eventually removed.


* Next release from that:
  - errors out if specific option isn't used for doing building with 
autotools

  - tells that autotools support will be removed in following release

* Release after that removes autotools support.


(I assume Emil would be the person supporting Autotools during this as 
he had already volunteered for it.)



While I think above is closer to how other large projects do deprecation 
in general (= have clear deprecation period/releases), build system 
changes are probably more often done just with flag day (early in the 
release cycle, as maintaining multiple build systems can be pretty large 
pain).



- Eero




On Thu, 20 Dec 2018 at 07:37, Gert Wollny > wrote:


Am Mittwoch, den 19.12.2018, 12:19 -0500 schrieb Ilia Mirkin:
 > On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny mailto:gw.foss...@gmail.com>>
 > wrote:
 > >
 > > Since Meson will eventually be the only build system deprecate
 > > autotools
 > > now. It can still be used by invoking configure with the flag
 > >   --enable-autotools
 > >
 > > Signed-off-by: Gert Wollny mailto:gw.foss...@gmail.com>>
 >
 > In case it's not clear from the later discussion:
 >
 > Strongly NAKed-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
 > This should not be applied to the repository.

You should probably add this to the patch proposals that want to remove
autotools then.

I'm certainly not going to push this patch with your NAK, but I'd like
to ask you to reconsider: All this patch does is require to add  --
enable-autotools to the configure call once - a little hickup in the
workflow of those who do not yet use exclusively meson, but it gets the
message out to the others that things are going to change.

Best,
Gert

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



--
Stuart Young (aka Cefiar)

___
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] radv: compute optimal VM alignment for imported buffers

[Samuel Pitoiset]

On 12/20/18 3:30 PM, Bas Nieuwenhuizen wrote:

Happy to have this patch, but all descriptions and comments say this
is an optimization 

Can we get some comment that this avoids hangs?


Pushed with a comment.
Thanks!



Otherwise

Reviewed-by: Bas Nieuwenhuizen 

On Thu, Dec 20, 2018 at 3:23 PM Samuel Pitoiset
 wrote:


This fixes GPU hangs on GFX9 with
dEQP-VK.memory.external_memory_host.bind_image_memory_and_render.with_zero_offset.*

Copied from RadeonSI.

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 28 ++-
  1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
index ec126bfc7c..0b0e8850c1 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
@@ -410,6 +410,28 @@ radv_amdgpu_winsys_bo_unmap(struct radeon_winsys_bo *_bo)
 amdgpu_bo_cpu_unmap(bo->bo);
  }

+static uint64_t
+radv_amdgpu_get_optimal_vm_alignment(struct radv_amdgpu_winsys *ws,
+uint64_t size, unsigned alignment)
+{
+   uint64_t vm_alignment = alignment;
+
+   /* Increase the VM alignment for faster address translation. */
+   if (size >= ws->info.pte_fragment_size)
+   vm_alignment = MAX2(vm_alignment, ws->info.pte_fragment_size);
+
+   /* Gfx9: Increase the VM alignment to the most significant bit set
+* in the size for faster address translation.
+*/
+   if (ws->info.chip_class >= GFX9) {
+   unsigned msb = util_last_bit64(size); /* 0 = no bit is set */
+   uint64_t msb_alignment = msb ? 1ull << (msb - 1) : 0;
+
+   vm_alignment = MAX2(vm_alignment, msb_alignment);
+   }
+   return vm_alignment;
+}
+
  static struct radeon_winsys_bo *
  radv_amdgpu_winsys_bo_from_ptr(struct radeon_winsys *_ws,
 void *pointer,
@@ -420,16 +442,20 @@ radv_amdgpu_winsys_bo_from_ptr(struct radeon_winsys *_ws,
 struct radv_amdgpu_winsys_bo *bo;
 uint64_t va;
 amdgpu_va_handle va_handle;
+   uint64_t vm_alignment;

 bo = CALLOC_STRUCT(radv_amdgpu_winsys_bo);
 if (!bo)
 return NULL;

+   vm_alignment = radv_amdgpu_get_optimal_vm_alignment(ws, size,
+   
ws->info.gart_page_size);
+
 if (amdgpu_create_bo_from_user_mem(ws->dev, pointer, size, 
_handle))
 goto error;

 if (amdgpu_va_range_alloc(ws->dev, amdgpu_gpu_va_range_general,
- size, 1 << 12, 0, , _handle,
+ size, vm_alignment, 0, , _handle,
   AMDGPU_VA_RANGE_HIGH))
 goto error_va_alloc;

--
2.20.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 35268] initial-exec TLS model breaks dlopen'ed libGL

[bugzilla-daemon]

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

--- Comment #30 from Rich Felker  ---
Given the lack of response on this issue, I think when I get some time to focus
on it again I'll just prepare a patch removing all of the asm dispatch stubs.

As noted before, they have no benefits at all on x86_64. On other archs only
the runtime-generated dispatch stubs possibly benefit from generating them by
hand, and the same benefit should be obtainable just by building with textrels
(omitting -fPIC), if the user is willing to accept what that entails.

As a bonus, if it turns out that upstream is unwilling to merge a fix for this
issue, a patch that just removes the problematic code is easier to maintain
out-of-tree than one that makes lots of small changes to the code.

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

Re: [Mesa-dev] [PATCH] gallivm: use llvm jit code for decoding s3tc

[Michel Dänzer]

On 2018-12-19 4:51 a.m., srol...@vmware.com wrote:
> From: Roland Scheidegger 
> 
> This is (much) faster than using the util fallback.
> (Note that there's two methods here, one would use a cache, similar to
> the existing code (although the cache was disabled), except the block
> decode is done with jit code, the other directly decodes the required
> pixels. For now don't use the cache (being direct-mapped is suboptimal,
> but it's difficult to come up with something better which doesn't have
> too much overhead.)

This change made lp_test_format segfault on my Ryzen 7 1700, both using
LLVM 7 and current SVN HEAD. Not much information in the backtrace
unfortunately:

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x77fcd16a in ?? ()
#2  0x2c2c2c2caeaeaeae in ?? ()
#3  0x979797976f6f6f6f in ?? ()
#4  0x20b0d7f2 in ?? ()
#5  0x976f2cae in ?? ()
#6  0x0089625d008eb099 in ?? ()
#7  0x7b8487218483a821 in ?? ()
#8  0x008414210094ffd6 in ?? ()
#9  0x007bef9400739629 in ?? ()
#10 0x0069 in ?? ()
#11 0x06d0 in ?? ()
#12 0x7fffe490 in ?? ()
#13 0x5593f040 in ?? ()
#14 0x7fffe430 in ?? ()
#15 0x77fcd053 in ?? ()
#16 0x77fcd000 in ?? ()
#17 0x556fd618 in util_format_test_cases ()
#18 0x558c0780 in ?? ()
#19 0x7fffe490 in ?? ()
#20 0x556fd618 in util_format_test_cases ()
#21 0x555667cc in test_format_float (verbose=, 
desc=0x7fffe4a0, fp=0x0) at 
../src/gallium/drivers/llvmpipe/lp_test_format.c:184
#22 test_one (verbose=, format_desc=0x7fffe4a0, fp=0x0) at 
../src/gallium/drivers/llvmpipe/lp_test_format.c:342
#23 test_all (verbose=, fp=0x0) at 
../src/gallium/drivers/llvmpipe/lp_test_format.c:395
#24 0x5556621f in main (argc=1, argv=0x7fffe628) at 
../src/gallium/drivers/llvmpipe/lp_test_main.c:419


-- 
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] [Mesa-stable] [PATCH] intel/compiler: move nir_lower_bool_to_int32 before nir_lower_locals_to_regs

[Juan A. Suarez Romero]

On Wed, 2018-12-19 at 09:15 +0100, Iago Toral Quiroga wrote:
> The former expects to see SSA-only things, but the latter injects registers.
> 
> The assertions in the lowering where not seeing this because they asserted
> on the bit_size values only, not on the is_ssa field, so add that assertion
> too.
> 
> Fixes: 11dc1307794e "nir: Add a bool to int32 lowering pass"
> CC: mesa-sta...@lists.freedesktop.org

While this patch has been nominated for stable, I'm rejecting it in 18.2 because
the commit it fixes, 11dc1307794e, is not part of the 18.2 stable branch.


J.A.

> ---
>  src/compiler/nir/nir_lower_bool_to_int32.c | 2 ++
>  src/intel/compiler/brw_nir.c   | 4 ++--
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/src/compiler/nir/nir_lower_bool_to_int32.c 
> b/src/compiler/nir/nir_lower_bool_to_int32.c
> index 064b27b9025..fdd2f55175d 100644
> --- a/src/compiler/nir/nir_lower_bool_to_int32.c
> +++ b/src/compiler/nir/nir_lower_bool_to_int32.c
> @@ -46,6 +46,8 @@ lower_alu_instr(nir_alu_instr *alu)
>  {
> const nir_op_info *op_info = _op_infos[alu->op];
>  
> +   assert(alu->dest.dest.is_ssa);
> +
> switch (alu->op) {
> case nir_op_imov:
> case nir_op_vec2:
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index ab88a5f1fc7..4fdc98b6cf4 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -832,6 +832,8 @@ brw_postprocess_nir(nir_shader *nir, const struct 
> brw_compiler *compiler,
> OPT(nir_opt_dce);
> OPT(nir_opt_move_comparisons);
>  
> +   OPT(nir_lower_bool_to_int32);
> +
> OPT(nir_lower_locals_to_regs);
>  
> if (unlikely(debug_enabled)) {
> @@ -846,8 +848,6 @@ brw_postprocess_nir(nir_shader *nir, const struct 
> brw_compiler *compiler,
>nir_print_shader(nir, stderr);
> }
>  
> -   OPT(nir_lower_bool_to_int32);
> -
> OPT(nir_convert_from_ssa, true);
>  
> if (!is_scalar) {

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

[Mesa-dev] [PATCH] pci_ids: add new VegaM pci id

[Alex Deucher]

Signed-off-by: Alex Deucher 
Cc: mesa-sta...@lists.freedesktop.org
---
 include/pci_ids/radeonsi_pci_ids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/pci_ids/radeonsi_pci_ids.h 
b/include/pci_ids/radeonsi_pci_ids.h
index a2bc9213207..75ac7761bb4 100644
--- a/include/pci_ids/radeonsi_pci_ids.h
+++ b/include/pci_ids/radeonsi_pci_ids.h
@@ -219,6 +219,7 @@ CHIPSET(0x699F, POLARIS12)
 
 CHIPSET(0x694C, VEGAM)
 CHIPSET(0x694E, VEGAM)
+CHIPSET(0x694F, VEGAM)
 
 CHIPSET(0x6860, VEGA10)
 CHIPSET(0x6861, VEGA10)
-- 
2.13.6

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

Re: [Mesa-dev] [PATCH] radv: compute optimal VM alignment for imported buffers

[Bas Nieuwenhuizen]

Happy to have this patch, but all descriptions and comments say this
is an optimization 

Can we get some comment that this avoids hangs?

Otherwise

Reviewed-by: Bas Nieuwenhuizen 

On Thu, Dec 20, 2018 at 3:23 PM Samuel Pitoiset
 wrote:
>
> This fixes GPU hangs on GFX9 with
> dEQP-VK.memory.external_memory_host.bind_image_memory_and_render.with_zero_offset.*
>
> Copied from RadeonSI.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 28 ++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c 
> b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
> index ec126bfc7c..0b0e8850c1 100644
> --- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
> +++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
> @@ -410,6 +410,28 @@ radv_amdgpu_winsys_bo_unmap(struct radeon_winsys_bo *_bo)
> amdgpu_bo_cpu_unmap(bo->bo);
>  }
>
> +static uint64_t
> +radv_amdgpu_get_optimal_vm_alignment(struct radv_amdgpu_winsys *ws,
> +uint64_t size, unsigned alignment)
> +{
> +   uint64_t vm_alignment = alignment;
> +
> +   /* Increase the VM alignment for faster address translation. */
> +   if (size >= ws->info.pte_fragment_size)
> +   vm_alignment = MAX2(vm_alignment, ws->info.pte_fragment_size);
> +
> +   /* Gfx9: Increase the VM alignment to the most significant bit set
> +* in the size for faster address translation.
> +*/
> +   if (ws->info.chip_class >= GFX9) {
> +   unsigned msb = util_last_bit64(size); /* 0 = no bit is set */
> +   uint64_t msb_alignment = msb ? 1ull << (msb - 1) : 0;
> +
> +   vm_alignment = MAX2(vm_alignment, msb_alignment);
> +   }
> +   return vm_alignment;
> +}
> +
>  static struct radeon_winsys_bo *
>  radv_amdgpu_winsys_bo_from_ptr(struct radeon_winsys *_ws,
> void *pointer,
> @@ -420,16 +442,20 @@ radv_amdgpu_winsys_bo_from_ptr(struct radeon_winsys 
> *_ws,
> struct radv_amdgpu_winsys_bo *bo;
> uint64_t va;
> amdgpu_va_handle va_handle;
> +   uint64_t vm_alignment;
>
> bo = CALLOC_STRUCT(radv_amdgpu_winsys_bo);
> if (!bo)
> return NULL;
>
> +   vm_alignment = radv_amdgpu_get_optimal_vm_alignment(ws, size,
> +   
> ws->info.gart_page_size);
> +
> if (amdgpu_create_bo_from_user_mem(ws->dev, pointer, size, 
> _handle))
> goto error;
>
> if (amdgpu_va_range_alloc(ws->dev, amdgpu_gpu_va_range_general,
> - size, 1 << 12, 0, , _handle,
> + size, vm_alignment, 0, , _handle,
>   AMDGPU_VA_RANGE_HIGH))
> goto error_va_alloc;
>
> --
> 2.20.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] [PATCH] radv: compute optimal VM alignment for imported buffers

[Samuel Pitoiset]

This fixes GPU hangs on GFX9 with
dEQP-VK.memory.external_memory_host.bind_image_memory_and_render.with_zero_offset.*

Copied from RadeonSI.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 28 ++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
index ec126bfc7c..0b0e8850c1 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
@@ -410,6 +410,28 @@ radv_amdgpu_winsys_bo_unmap(struct radeon_winsys_bo *_bo)
amdgpu_bo_cpu_unmap(bo->bo);
 }
 
+static uint64_t
+radv_amdgpu_get_optimal_vm_alignment(struct radv_amdgpu_winsys *ws,
+uint64_t size, unsigned alignment)
+{
+   uint64_t vm_alignment = alignment;
+
+   /* Increase the VM alignment for faster address translation. */
+   if (size >= ws->info.pte_fragment_size)
+   vm_alignment = MAX2(vm_alignment, ws->info.pte_fragment_size);
+
+   /* Gfx9: Increase the VM alignment to the most significant bit set
+* in the size for faster address translation.
+*/
+   if (ws->info.chip_class >= GFX9) {
+   unsigned msb = util_last_bit64(size); /* 0 = no bit is set */
+   uint64_t msb_alignment = msb ? 1ull << (msb - 1) : 0;
+
+   vm_alignment = MAX2(vm_alignment, msb_alignment);
+   }
+   return vm_alignment;
+}
+
 static struct radeon_winsys_bo *
 radv_amdgpu_winsys_bo_from_ptr(struct radeon_winsys *_ws,
void *pointer,
@@ -420,16 +442,20 @@ radv_amdgpu_winsys_bo_from_ptr(struct radeon_winsys *_ws,
struct radv_amdgpu_winsys_bo *bo;
uint64_t va;
amdgpu_va_handle va_handle;
+   uint64_t vm_alignment;
 
bo = CALLOC_STRUCT(radv_amdgpu_winsys_bo);
if (!bo)
return NULL;
 
+   vm_alignment = radv_amdgpu_get_optimal_vm_alignment(ws, size,
+   
ws->info.gart_page_size);
+
if (amdgpu_create_bo_from_user_mem(ws->dev, pointer, size, _handle))
goto error;
 
if (amdgpu_va_range_alloc(ws->dev, amdgpu_gpu_va_range_general,
- size, 1 << 12, 0, , _handle,
+ size, vm_alignment, 0, , _handle,
  AMDGPU_VA_RANGE_HIGH))
goto error_va_alloc;
 
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH v2] radv: Work around non-renderable 128bpp compressed 3d textures on GFX9.

[Samuel Pitoiset]

On 12/20/18 10:13 AM, Bas Nieuwenhuizen wrote:

Exactly what title says, the new addrlib does not allow the above with
certain dimensions that the CTS seems to hit. Work around it by not
allowing the app to render to it via compat with  other 128bpp formats
and do not render to it ourselves during copies.

Fixes: 776b9113656 "amd/addrlib: update Mesa's copy of addrlib"
Reviewed-by: Nicolai Hähnle 
---
  src/amd/common/ac_surface.c |  6 --
  src/amd/common/ac_surface.h |  1 +
  src/amd/vulkan/radv_formats.c   | 12 
  src/amd/vulkan/radv_image.c |  6 ++
  src/amd/vulkan/radv_meta_copy.c | 24 ++--
  5 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index d8d927ee1c5..8661731e66f 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -1412,11 +1412,13 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
AddrSurfInfoIn.bpp = surf->bpe * 8;
}
  
-	AddrSurfInfoIn.flags.color = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);

+   bool is_color_surface = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
+   AddrSurfInfoIn.flags.color = is_color_surface &&
+!(surf->flags & 
RADEON_SURF_NO_RENDER_TARGET);
AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) != 0;
AddrSurfInfoIn.flags.display = get_display_flag(config, surf);
/* flags.texture currently refers to TC-compatible HTILE */
-   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
+   AddrSurfInfoIn.flags.texture = is_color_surface ||
   surf->flags & 
RADEON_SURF_TC_COMPATIBLE_HTILE;
AddrSurfInfoIn.flags.opt4space = 1;
  
diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h

index 8ba964e64ec..7ae166c70a3 100644
--- a/src/amd/common/ac_surface.h
+++ b/src/amd/common/ac_surface.h
@@ -68,6 +68,7 @@ enum radeon_micro_mode {
  #define RADEON_SURF_IMPORTED(1 << 24)
  #define RADEON_SURF_OPTIMIZE_FOR_SPACE  (1 << 25)
  #define RADEON_SURF_SHAREABLE   (1 << 26)
+#define RADEON_SURF_NO_RENDER_TARGET(1 << 27)
  
  struct legacy_surf_level {

  uint64_toffset;
diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index 59bc46d2fc8..48727817d32 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -1112,6 +1112,18 @@ static VkResult radv_get_image_format_properties(struct 
radv_physical_device *ph
maxMipLevels = 1;
}
  
+

+   /* We can't create 3d compressed 128bpp images that can be rendered to 
on GFX9 */
+   if (physical_device->rad_info.chip_class >= GFX9 &&
+   info->type == VK_IMAGE_TYPE_3D &&
+   vk_format_get_blocksizebits(info->format) == 128 &&
+   vk_format_is_compressed(info->format) &&
+   (info->flags & VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT) &&
+   ((info->flags &  VK_IMAGE_CREATE_EXTENDED_USAGE_BIT) ||


Extra space.

Apart that, patch is:

Reviewed-by: Samuel Pitoiset 


+(info->usage & VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT))) {
+   goto unsupported;
+   }
+
if (info->usage & VK_IMAGE_USAGE_SAMPLED_BIT) {
if (!(format_feature_flags & 
VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT)) {
goto unsupported;
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 2bd74e202fe..69bbcdcf645 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -249,6 +249,12 @@ radv_init_surface(struct radv_device *device,
if (is_stencil)
surface->flags |= RADEON_SURF_SBUFFER;
  
+	if (device->physical_device->rad_info.chip_class >= GFX9 &&

+   pCreateInfo->imageType == VK_IMAGE_TYPE_3D &&
+   vk_format_get_blocksizebits(pCreateInfo->format) == 128 &&
+   vk_format_is_compressed(pCreateInfo->format))
+   surface->flags |= RADEON_SURF_NO_RENDER_TARGET;
+
surface->flags |= RADEON_SURF_OPTIMIZE_FOR_SPACE;
  
  	if (!radv_use_dcc_for_image(device, image, create_info, pCreateInfo))

diff --git a/src/amd/vulkan/radv_meta_copy.c b/src/amd/vulkan/radv_meta_copy.c
index ddfb5c54673..647a167ab4c 100644
--- a/src/amd/vulkan/radv_meta_copy.c
+++ b/src/amd/vulkan/radv_meta_copy.c
@@ -107,6 +107,22 @@ blit_surf_for_image_level_layer(struct radv_image *image,
};
  }
  
+static bool

+image_is_renderable(struct radv_device *device, struct radv_image *image)
+{
+   if (image->vk_format == VK_FORMAT_R32G32B32_UINT ||
+   image->vk_format == VK_FORMAT_R32G32B32_SINT ||
+   image->vk_format == VK_FORMAT_R32G32B32_SFLOAT)
+   return false;
+
+   if (device->physical_device->rad_info.chip_class >= GFX9 &&
+   image->type == VK_IMAGE_TYPE_3D &&
+  

Re: [Mesa-dev] [PATCH 06/16] nir: improve convert_yuv_to_rgb when fuse_ffma=true

[Jonathan marek]

On 12/20/2018 01:28 AM, Nils Wallménius wrote:

Den ons 19 dec. 2018 17:44 skrev Jonathan Marek :


When ffma is available, we can use a different arrangement of constants to
get a better result. On freedreno/ir3, this reduces the YUV->RGB to 7
scalar ffma. On freedreno/a2xx, it will allow YUV->RGB to be 3 vec4 ffma.

Signed-off-by: Jonathan Marek 
---
  src/compiler/nir/nir_lower_tex.c | 62 ++--
  1 file changed, 43 insertions(+), 19 deletions(-)

diff --git a/src/compiler/nir/nir_lower_tex.c
b/src/compiler/nir/nir_lower_tex.c
index 6a6b6c41a7..f7c821bb34 100644
--- a/src/compiler/nir/nir_lower_tex.c
+++ b/src/compiler/nir/nir_lower_tex.c
@@ -342,25 +342,49 @@ convert_yuv_to_rgb(nir_builder *b, nir_tex_instr
*tex,
 nir_ssa_def *y, nir_ssa_def *u, nir_ssa_def *v,
 nir_ssa_def *a)
  {
-   nir_const_value m[3] = {
-  { .f32 = { 1.0f,  0.0f, 1.59602678f, 0.0f } },
-  { .f32 = { 1.0f, -0.39176229f, -0.81296764f, 0.0f } },
-  { .f32 = { 1.0f,  2.01723214f,  0.0f,0.0f } }
-   };
-
-   nir_ssa_def *yuv =
-  nir_vec4(b,
-   nir_fmul(b, nir_imm_float(b, 1.16438356f),
-nir_fadd(b, y, nir_imm_float(b, -16.0f /
255.0f))),
-   nir_channel(b, nir_fadd(b, u, nir_imm_float(b, -128.0f /
255.0f)), 0),
-   nir_channel(b, nir_fadd(b, v, nir_imm_float(b, -128.0f /
255.0f)), 0),
-   nir_imm_float(b, 0.0));
-
-   nir_ssa_def *red = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[0]));
-   nir_ssa_def *green = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[1]));
-   nir_ssa_def *blue = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[2]));
-
-   nir_ssa_def *result = nir_vec4(b, red, green, blue, a);
+   nir_ssa_def *result;
+
+
+   if (b->shader->options->fuse_ffma) {
+  nir_const_value m[4] = {



Drive-by comment, but shouldn't this^ be m[3]?

Regards
Nils



Yes, it should be m[3]. It was originally 4 before alpha was added.


+ { .f32 = { 1.16438356f, 1.16438356f, 1.16438356f, 0.0f } },
+ { .f32 = { 0.0f,   -0.39176229f, 2.01723214f, 0.0f } },
+ { .f32 = { 1.59602678f,-0.81296764f, 0.0f,0.0f } },
+  };
+  static const float y_off = -16.0f * 1.16438356f / 255.0f;
+  static const float sc = 128.0f / 255.0f;
+
+  nir_ssa_def *offset =
+ nir_vec4(b,
+  nir_imm_float(b, y_off - sc * 1.59602678f),
+  nir_imm_float(b, y_off + sc * (0.81296764f +
0.39176229f)),
+  nir_imm_float(b, y_off - sc * 2.01723214f),
+  a);
+
+  result = nir_ffma(b, y, nir_build_imm(b, 4, 32, m[0]),
+   nir_ffma(b, u, nir_build_imm(b, 4, 32, m[1]),
+nir_ffma(b, v, nir_build_imm(b, 4, 32,
m[2]), offset)));
+   } else {
+  nir_const_value m[3] = {
+ { .f32 = { 1.0f,  0.0f, 1.59602678f, 0.0f } },
+ { .f32 = { 1.0f, -0.39176229f, -0.81296764f, 0.0f } },
+ { .f32 = { 1.0f,  2.01723214f,  0.0f,0.0f } }
+  };
+
+  nir_ssa_def *yuv =
+ nir_vec4(b,
+  nir_fmul(b, nir_imm_float(b, 1.16438356f),
+   nir_fadd(b, y, nir_imm_float(b, -16.0f /
255.0f))),
+  nir_channel(b, nir_fadd(b, u, nir_imm_float(b, -128.0f
/ 255.0f)), 0),
+  nir_channel(b, nir_fadd(b, v, nir_imm_float(b, -128.0f
/ 255.0f)), 0),
+  nir_imm_float(b, 0.0));
+
+  nir_ssa_def *red = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32, m[0]));
+  nir_ssa_def *green = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32,
m[1]));
+  nir_ssa_def *blue = nir_fdot4(b, yuv, nir_build_imm(b, 4, 32,
m[2]));
+
+  result = nir_vec4(b, red, green, blue, a);
+   }

 nir_ssa_def_rewrite_uses(>dest.ssa, nir_src_for_ssa(result));
  }
--
2.17.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 108967] DRM : eglCreatePbufferSurface failed with error EGL_BAD_MATCH

[bugzilla-daemon]

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

--- Comment #7 from Vishwanath Chandapur  ---
Hi,

Qtwebegine has already has support of EGL_KHR_surfaceless_context.

And also when we enabled more debug logs we found mesa driver is failing with
below error.when this error occurs we see black square-box on screen  

Note:Same application is working with disabled gpu.

Logs:
*ERROR* BO at index 117 already on submit list.

-- 
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 03/18] glx: meson: build src/glx only with -Dglx=dri

[Emil Velikov]

On Tue, 18 Dec 2018 at 21:52, Dylan Baker  wrote:
>
> Quoting Emil Velikov (2018-12-18 02:33:56)
> > On Mon, 17 Dec 2018 at 19:44, Dylan Baker  wrote:
> > >
> > > Quoting Emil Velikov (2018-12-17 10:58:11)
> > > > On Fri, 14 Dec 2018 at 17:13, Dylan Baker  wrote:
> > > > >
> > > > > Quoting Emil Velikov (2018-12-13 08:05:52)
> > > > > > From: Emil Velikov 
> > > > > >
> > > > > > The library is the dri capable one, push the check src/meson.build,
> > > > > > instead of the current partial handling in src/glx/meson.build.
> > > > > >
> > > > > > Fixes: a47c525f328 ("meson: build glx")
> > > > >
> > > > > This is just a refactor, the Fixes: is unnecessary. More on that below
> > > > >
> > > > If I'm reading things correctly, building with -Dglx=xlib/gallium-xlib
> > > > -Dshared-glapi -Denable-tests - will attempt to build the tests in
> > > > src/glx/tests/.
> > > > Which is something that shouldn't happen IMHO.
> > >
> > > Wait, why shouldn't they run? The tests pass (at least with the 
> > > gallium-xlib
> > > glx), and running tests seems useful.
> > >
> > Fully agree running tests is useful and welcome.
> >
> > The tests flex the -Dglx=dri code in src/glx/. As-is it's rather
> > confusing, misleading even, to request one thing then run tests for
> > something that looks the same but isn't.
> > Silly analogy - running ANV tests, when -Dvulkan-drivers=amd is used.
> >
> > Hope this is clear - not sure if the coffee has kicked in ;-)
> > -Emil
>
> Sorry, I meant to respond yesterday. Ian explained why these tests are only
> useful if building DRI based GLX.
>
> Maybe make the commit message something like:
> "meson: Ensure tests for dri based glx are only built when dri based glx is 
> enabled"
> or something like that? I'll leave it up to you what you think is best. As 
> long
> as you note that the real functional change is not building tests when we 
> don't
> want/need them.
>
> Reviewed-by: Dylan Baker 

Ack will do. Thanks.

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

Re: [Mesa-dev] [PATCH] radv: fix subpass image transitions with multiviews

[Samuel Pitoiset]

On 12/20/18 12:18 PM, Bas Nieuwenhuizen wrote:

Is not ideal but will have to do for now


Yes, this can be improved.



Reviewed-by: Bas Nieuwenhuizen 

On Thu, Dec 20, 2018 at 12:01 PM Samuel Pitoiset
 wrote:


The driver needs to decompress all image layers if a fast
depth/color clear has been performed.

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_cmd_buffer.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index aebf93b447f..c61310f3fc9 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2315,6 +2315,17 @@ static void radv_handle_subpass_image_transition(struct 
radv_cmd_buffer *cmd_buf
 range.baseArrayLayer = view->base_layer;
 range.layerCount = cmd_buffer->state.framebuffer->layers;

+   if (cmd_buffer->state.subpass && cmd_buffer->state.subpass->view_mask) {
+   /* If the current subpass uses multiview, the driver might have
+* performed a fast color/depth clear to the whole image
+* (including all layers). To make sure the driver will
+* decompress the image correctly (if needed), we have to
+* account for the "real" number of layers. If the view mask is
+* sparse, this will decompress more layers than needed.
+*/
+   range.layerCount = 
util_last_bit(cmd_buffer->state.subpass->view_mask);
+   }
+
 radv_handle_image_transition(cmd_buffer,
  view->image,
  
cmd_buffer->state.attachments[idx].current_layout,
--
2.20.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

Re: [Mesa-dev] [PATCH] radv: fix subpass image transitions with multiviews

[Bas Nieuwenhuizen]

Is not ideal but will have to do for now

Reviewed-by: Bas Nieuwenhuizen 

On Thu, Dec 20, 2018 at 12:01 PM Samuel Pitoiset
 wrote:
>
> The driver needs to decompress all image layers if a fast
> depth/color clear has been performed.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index aebf93b447f..c61310f3fc9 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -2315,6 +2315,17 @@ static void 
> radv_handle_subpass_image_transition(struct radv_cmd_buffer *cmd_buf
> range.baseArrayLayer = view->base_layer;
> range.layerCount = cmd_buffer->state.framebuffer->layers;
>
> +   if (cmd_buffer->state.subpass && 
> cmd_buffer->state.subpass->view_mask) {
> +   /* If the current subpass uses multiview, the driver might 
> have
> +* performed a fast color/depth clear to the whole image
> +* (including all layers). To make sure the driver will
> +* decompress the image correctly (if needed), we have to
> +* account for the "real" number of layers. If the view mask 
> is
> +* sparse, this will decompress more layers than needed.
> +*/
> +   range.layerCount = 
> util_last_bit(cmd_buffer->state.subpass->view_mask);
> +   }
> +
> radv_handle_image_transition(cmd_buffer,
>  view->image,
>  
> cmd_buffer->state.attachments[idx].current_layout,
> --
> 2.20.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

Re: [Mesa-dev] [PATCH] WIP: meson: allow building DRI loaders without a DRI driver

[Emil Velikov]

On Tue, 18 Dec 2018 at 21:53, Dylan Baker  wrote:
>
> Quoting Emil Velikov (2018-12-18 03:09:55)
> > On Mon, 17 Dec 2018 at 22:27, Matt Turner  wrote:
> > >
> > > On Mon, Dec 17, 2018 at 2:12 PM Emil Velikov  
> > > wrote:
> > > > Additionally, distributions build latest loader and use it with DRI1
> > > > era drivers.
> > >
> > > I'm curious if there are distributions that still ships the DRI1
> > > drivers. Do you know which, if any, do?
> >
> > Archlinux comes off the top of my head. We had a few others but I've
> > not looked in 6+ months.
> >
> > -Emil
>
> pacman says arch still does, but I'm not sure why considering they only 
> support
> x86_64 now and half of those GPUs only came with x86 cpus.
>
Today one could trivially plug a PCI card into their x86_64 system -
say a mga or r128 one :-)
For integrated solutions powered by i810 or unichrome that is less likely.

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

Re: [Mesa-dev] [PATCH v2 13/24] mapi/new: don't print info we don't need for ES1/ES2

[Emil Velikov]

On Tue, 18 Dec 2018 at 14:23, Kyle Brenneman  wrote:
> On 12/14/2018 07:04 AM, Emil Velikov wrote:

> > -print(generate_public_stubs(functions))
> > +if target in "gldispatch":
> This should be an "==", not "in". The in operator would do a substring
> search.

Thanks Kyle, fixed locally. If there's other comments I'll
respin/resend the series.
Considering the overall silence (modulo Erik's review), I'm inclined
to merge this tomorrow around lunch time.

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

[Mesa-dev] [PATCH] radv: fix subpass image transitions with multiviews

[Samuel Pitoiset]

The driver needs to decompress all image layers if a fast
depth/color clear has been performed.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index aebf93b447f..c61310f3fc9 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2315,6 +2315,17 @@ static void radv_handle_subpass_image_transition(struct 
radv_cmd_buffer *cmd_buf
range.baseArrayLayer = view->base_layer;
range.layerCount = cmd_buffer->state.framebuffer->layers;
 
+   if (cmd_buffer->state.subpass && cmd_buffer->state.subpass->view_mask) {
+   /* If the current subpass uses multiview, the driver might have
+* performed a fast color/depth clear to the whole image
+* (including all layers). To make sure the driver will
+* decompress the image correctly (if needed), we have to
+* account for the "real" number of layers. If the view mask is
+* sparse, this will decompress more layers than needed.
+*/
+   range.layerCount = 
util_last_bit(cmd_buffer->state.subpass->view_mask);
+   }
+
radv_handle_image_transition(cmd_buffer,
 view->image,
 
cmd_buffer->state.attachments[idx].current_layout,
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] amd/surface: fix setting of ADDR2_SURFACE_FLAGS::color

[Marek Olšák]

On Thu, Dec 20, 2018, 4:05 AM Bas Nieuwenhuizen  On Thu, Dec 20, 2018 at 9:00 AM Marek Olšák  wrote:
> >
> > I prefer Nicolai's patch because it's shorter and doesn't need driver
> changes.
> >
> > Reviewed-by: Marek Olšák 
>
> This patch still needs driver changes because radv will render to a
> compressed surface as r32g32b32a32, so allocating a non-renderable
> surface without driver changes goes against actual usage?
>

Ok. I just meant the ac_surface interface change.

Marek

>
> > Marek
> >
> > On Tue, Dec 18, 2018 at 12:50 PM Haehnle, Nicolai <
> nicolai.haeh...@amd.com> wrote:
> >>
> >> On 18.12.18 18:36, Bas Nieuwenhuizen wrote:
> >> > Hi Nicolai,
> >> >
> >> > I happened to be writing something similar which also fixes up radv to
> >> > never render to those surfaces as r32g32b32a32:
> >> > https://patchwork.freedesktop.org/series/54172/ I can split out the
> >> > radv specific stuff and this one is r-b after than.
> >>
> >> Oh, I missed that, sorry. I don't particularly care about which approach
> >> to this is taken.
> >>
> >> Cheers,
> >> Nicolai
> >>
> >>
> >>
> >> >
> >> > Thanks,
> >> > Bas
> >> >
> >> > On Tue, Dec 18, 2018 at 5:37 PM Nicolai Hähnle 
> wrote:
> >> >>
> >> >> From: Nicolai Hähnle 
> >> >>
> >> >> In the gfx9 addrlib, this bit has been clarified as meaning that
> >> >> the surface can be used as a color buffer (render target).
> >> >>
> >> >> Setting this for compressed surfaces triggers a workaround that
> >> >> is only required for surfaces that can be render targets, and ends
> >> >> up breaking the 16-byte-per-block case.
> >> >>
> >> >> Fixes
> dEQP-VK.pipeline.image.suballocation.sampling_type.combined.view_type.3d.format.etc2_r8g8b8a8_srgb_block.count_1.size.11x11x11
> and others
> >> >>
> >> >> Note that there are other related bits which we don't set as intended
> >> >> by the interface, notably the 'unordered' bit, which is meant to
> >> >> indicate use as a shader image. It may be worth cleaning that up at
> some
> >> >> point after proper testing.
> >> >>
> >> >> Reported-by: Samuel Pitoiset 
> >> >> Fixes: 776b9113656 ("amd/addrlib: update Mesa's copy of addrlib")
> >> >> ---
> >> >>   src/amd/common/ac_surface.c | 5 ++---
> >> >>   1 file changed, 2 insertions(+), 3 deletions(-)
> >> >>
> >> >> diff --git a/src/amd/common/ac_surface.c
> b/src/amd/common/ac_surface.c
> >> >> index d8d927ee1c5..d647bd523f9 100644
> >> >> --- a/src/amd/common/ac_surface.c
> >> >> +++ b/src/amd/common/ac_surface.c
> >> >> @@ -1405,25 +1405,24 @@ static int gfx9_compute_surface(ADDR_HANDLE
> addrlib,
> >> >>  case 16:
> >> >>  assert(!(surf->flags &
> RADEON_SURF_Z_OR_SBUFFER));
> >> >>  AddrSurfInfoIn.format =
> ADDR_FMT_32_32_32_32;
> >> >>  break;
> >> >>  default:
> >> >>  assert(0);
> >> >>  }
> >> >>  AddrSurfInfoIn.bpp = surf->bpe * 8;
> >> >>  }
> >> >>
> >> >> -   AddrSurfInfoIn.flags.color = !(surf->flags &
> RADEON_SURF_Z_OR_SBUFFER);
> >> >> +   AddrSurfInfoIn.flags.color = !compressed && !(surf->flags &
> RADEON_SURF_Z_OR_SBUFFER);
> >> >>  AddrSurfInfoIn.flags.depth = (surf->flags &
> RADEON_SURF_ZBUFFER) != 0;
> >> >>  AddrSurfInfoIn.flags.display = get_display_flag(config,
> surf);
> >> >> -   /* flags.texture currently refers to TC-compatible HTILE */
> >> >> -   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
> >> >> +   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
> compressed ||
> >> >> surf->flags &
> RADEON_SURF_TC_COMPATIBLE_HTILE;
> >> >>  AddrSurfInfoIn.flags.opt4space = 1;
> >> >>
> >> >>  AddrSurfInfoIn.numMipLevels = config->info.levels;
> >> >>  AddrSurfInfoIn.numSamples = MAX2(1, config->info.samples);
> >> >>  AddrSurfInfoIn.numFrags = AddrSurfInfoIn.numSamples;
> >> >>
> >> >>  if (!(surf->flags & RADEON_SURF_Z_OR_SBUFFER))
> >> >>  AddrSurfInfoIn.numFrags = MAX2(1,
> config->info.storage_samples);
> >> >>
> >> >> --
> >> >> 2.19.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
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 2/3] egl: introduce a log level getter function

[Silvestrs Timofejevs]

Being able to retrieve the log level can be useful to enable/disable
debug code. The alternative, which is calling 'getenv' function every
time to retrieve the log level, is more "expensive".

Signed-off-by: Silvestrs Timofejevs 
---
 src/egl/main/egllog.c | 9 +
 src/egl/main/egllog.h | 4 
 2 files changed, 13 insertions(+)

diff --git a/src/egl/main/egllog.c b/src/egl/main/egllog.c
index c223f49..42bae01 100644
--- a/src/egl/main/egllog.c
+++ b/src/egl/main/egllog.c
@@ -133,6 +133,15 @@ _eglInitLogger(void)
}
 }
 
+/**
+ * Return the log level.
+ */
+EGLint
+_eglGetLogLevel(void)
+{
+   return logging.level;
+}
+
 
 /**
  * Log a message with message logger.
diff --git a/src/egl/main/egllog.h b/src/egl/main/egllog.h
index 2a06a34..a1cf977 100644
--- a/src/egl/main/egllog.h
+++ b/src/egl/main/egllog.h
@@ -44,6 +44,10 @@ extern "C" {
 #define _EGL_DEBUG   3   /* useful info for debugging */
 
 
+extern EGLint
+_eglGetLogLevel(void);
+
+
 extern void
 _eglLog(EGLint level, const char *fmtStr, ...);
 
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 3/3] egl: add config debug printout (v2)

[Silvestrs Timofejevs]

Feature to print out EGL returned configs for debug purposes.

'eglChooseConfig' and 'eglGetConfigs' debug information printout is
enabled when the log level equals '_EGL_DEBUG'. The configs are
printed, and if any of them are "chosen" they are marked with their
index in the chosen configs array.

v2:
   a) refactor the code in line with Eric's comments
   b) rename function _snprintfStrcat, split it out and put into the
  src/util/u_string.h, make it a separate patch.

Signed-off-by: Silvestrs Timofejevs 
---
 src/egl/Makefile.sources  |   4 +-
 src/egl/main/eglconfig.c  |  20 +++-
 src/egl/main/eglconfigdebug.c | 265 ++
 src/egl/main/eglconfigdebug.h |  55 +
 src/egl/meson.build   |   2 +
 5 files changed, 341 insertions(+), 5 deletions(-)
 create mode 100644 src/egl/main/eglconfigdebug.c
 create mode 100644 src/egl/main/eglconfigdebug.h

diff --git a/src/egl/Makefile.sources b/src/egl/Makefile.sources
index 0cc5f1b..353a848 100644
--- a/src/egl/Makefile.sources
+++ b/src/egl/Makefile.sources
@@ -28,7 +28,9 @@ LIBEGL_C_FILES := \
main/eglsync.c \
main/eglsync.h \
main/eglentrypoint.h \
-   main/egltypedefs.h
+   main/egltypedefs.h \
+   main/eglconfigdebug.h \
+   main/eglconfigdebug.c
 
 dri2_backend_core_FILES := \
drivers/dri2/egl_dri2.c \
diff --git a/src/egl/main/eglconfig.c b/src/egl/main/eglconfig.c
index a346f93..0095dc2 100644
--- a/src/egl/main/eglconfig.c
+++ b/src/egl/main/eglconfig.c
@@ -40,6 +40,7 @@
 #include "util/macros.h"
 
 #include "eglconfig.h"
+#include "eglconfigdebug.h"
 #include "egldisplay.h"
 #include "eglcurrent.h"
 #include "egllog.h"
@@ -797,14 +798,21 @@ _eglChooseConfig(_EGLDriver *drv, _EGLDisplay *disp, 
const EGLint *attrib_list,
  EGLConfig *configs, EGLint config_size, EGLint *num_configs)
 {
_EGLConfig criteria;
+   EGLBoolean result;
 
if (!_eglParseConfigAttribList(, disp, attrib_list))
   return _eglError(EGL_BAD_ATTRIBUTE, "eglChooseConfig");
 
-   return _eglFilterConfigArray(disp->Configs,
- configs, config_size, num_configs,
- _eglFallbackMatch, _eglFallbackCompare,
- (void *) );
+   result = _eglFilterConfigArray(disp->Configs,
+  configs, config_size, num_configs,
+  _eglFallbackMatch, _eglFallbackCompare,
+  (void *) );
+
+   if (result && (_eglGetLogLevel() == _EGL_DEBUG))
+  eglPrintConfigDebug(drv, disp, configs, *num_configs,
+  EGL_CONFIG_DEBUG_CHOOSE);
+
+   return result;
 }
 
 
@@ -857,5 +865,9 @@ _eglGetConfigs(_EGLDriver *drv, _EGLDisplay *disp, 
EGLConfig *configs,
*num_config = _eglFlattenArray(disp->Configs, (void *) configs,
  sizeof(configs[0]), config_size, _eglFlattenConfig);
 
+   if (_eglGetLogLevel() == _EGL_DEBUG)
+  eglPrintConfigDebug(drv, disp, configs, *num_config,
+  EGL_CONFIG_DEBUG_GET);
+
return EGL_TRUE;
 }
diff --git a/src/egl/main/eglconfigdebug.c b/src/egl/main/eglconfigdebug.c
new file mode 100644
index 000..0617c99
--- /dev/null
+++ b/src/egl/main/eglconfigdebug.c
@@ -0,0 +1,265 @@
+/*
+ * Copyright 2017 Imagination Technologies.
+ * All Rights Reserved.
+ *
+ * Based on eglinfo, which has copyright:
+ * Copyright (C) 2005  Brian Paul   All Rights Reserved.
+ *
+ * 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 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
+ * BRIAN PAUL 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 
+#include 
+#include 
+#include 
+
+#include "eglarray.h"
+#include "eglconfig.h"
+#include "eglconfigdebug.h"
+#include "egldisplay.h"
+#include "egllog.h"
+#include "egltypedefs.h"
+#include "util/macros.h"
+#include "util/u_string.h"
+
+/* Max debug message length */
+#define CONFIG_DEBUG_MSG_MAX 1000
+
+/*
+ * These are X visual types, so if you're running eglinfo under
+ * something not X, they probably don't make sense.
+ */
+static const char *const vnames[] = { 

[Mesa-dev] debug feature to dump "get configs" and "chosen configs" (v2)

[Silvestrs Timofejevs]

This patch series provides an easy way to see what configs
have been returned by the 'eglGetConfigs' and 'eglChooseConfig'
functions, and give an overview of config attributes.

v2:
   a) refactor the code in line with Eric's comments
   b) rename function _snprintfStrcat, split it out and put into
  src/util/u_string.h, make it a separate patch.

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

[Mesa-dev] [PATCH v2 1/3] util: introduce the util_strnappend function

[Silvestrs Timofejevs]

This function is similar to strncat, but unlike strncat it allows to
concatenate the buffer with a formatted string. The alternative would
be to have an intermediate string that is formated first, and then
appended via strncat.

Signed-off-by: Silvestrs Timofejevs 
---
 src/util/u_string.h | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/src/util/u_string.h b/src/util/u_string.h
index e408146..abf4598 100644
--- a/src/util/u_string.h
+++ b/src/util/u_string.h
@@ -202,7 +202,6 @@ util_strstr(const char *haystack, const char *needle)
return NULL;
 }
 
-
 #define util_strcasecmp stricmp
 #define util_strdup _strdup
 
@@ -223,6 +222,21 @@ util_strstr(const char *haystack, const char *needle)
 
 #endif
 
+/* Append a formatted string to the buffer, up to the buffer size */
+static inline void
+util_strnappend(char *const buf, const int buf_size, const char *fmt, ...)
+{
+   int max_allowed;
+   va_list args;
+   size_t buf_len = strlen(buf);
+
+   max_allowed = buf_size - buf_len;
+   assert(max_allowed >= 0);
+
+   va_start(args, fmt);
+   (void) util_vsnprintf([buf_len], max_allowed, fmt, args);
+   va_end(args);
+}
 
 #ifdef __cplusplus
 }
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 2/2] egl: add config debug printout

[Eric Engestrom]

On Thursday, 2018-12-20 08:30:53 +, Silvestrs Timofejevs wrote:
> Eric, thank you for reviewing my patch. I have expanded little bit
> on some of your comments bellow. I will be sending fallow up V2 of the patch
> shortly.

> On Thu, Dec 06, 2018 at 11:00:25AM +, Eric Engestrom wrote:
[...]
> > STATIC_ASSERT(sizeof(attr.surfString) <= sizeof("win,pb,pix,str,prsv"));
> I guess you meant ">="?

Indeed ^^'

[...]
> > > +/**
> > > + * Print the list of configs and the associated attributes.
> > > + */
> > > +void eglPrintConfigDebug(_EGLDriver *const drv, _EGLDisplay *const dpy,
> > > + EGLConfig *const configs, const EGLint 
> > > numConfigs,
> > > + const enum EGL_CONFIG_DEBUG_OPTION printOption);
> > 
> > `const` on non-pointers (ie. all the `const` here) in prototypes has
> > no effect, and I'm pretty sure the compiler will print a warning about it.
> > 
> > Thanks for thinking about using `const` on pointers though :)
> > Please move them to the left of the `*` so that they can const the data
> > they point to ;)
> The reason why I didn't make data "const" is because eventually these
> parameters are passed into the existing MESA EGL functions outside of this
> change. The parameters for those functions are not constified - so it will
> result in a compiler warning that const is dropped. And I think it makes more
> sense to make them non-const from the beginning rather than cast the const 
> away
> further down the pipe, as it is misleading.

That's a good point, I didn't realise we were lacking so many `const`
throughout src/egl/. I'll add them at some point, and I guess I'll add
them to your functions at the same time.

Point still stands about the compiler warning for the const in the
prototype above though ;)

Try compiling your code with a recent version of gcc (8 or above) and
clang, there might be other warnings as well.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] ac/nir: restrict fmask lookup to image load intrinsics

[Bas Nieuwenhuizen]

On Tue, Dec 18, 2018, 9:57 PM Samuel Pitoiset  We don't ever want to do the fmask lookup on a atomic or
> store, the fmask should have been decompressed if the
> surface has been moved to IMAGE_LAYOUT.
>

Clarify the description to be a *storage* image layout?

>
> Original patch by Dave Airlie.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 225c930d896..0f57dc7eeb4 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -2243,7 +2243,7 @@ static void get_image_coords(struct ac_nir_context
> *ctx,
> bool gfx9_1d = ctx->ac.chip_class >= GFX9 && dim ==
> GLSL_SAMPLER_DIM_1D;
> count = image_type_to_components_count(dim, is_array);
>
> -   if (is_ms) {
> +   if (is_ms && instr->intrinsic == nir_intrinsic_image_deref_load) {
> LLVMValueRef fmask_load_address[3];
> int chan;
>
> --
> 2.20.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] MR: Add extension EXT_sRGB_write_control (v7)

[Gert Wollny]

Hello all, 

With the last (minor) update I moved the series to an MR: 
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/14

There are only one minor change from the series last posted here

v7: use _mesa_has_EXT_framebuffer_sRGB instead of testing the extension
flag directly.

v6: - rename the new CAP
- reorder the patches that no double checking of
  EXT_sRGB and EXT_framebuffer_sRGB is needed.

RFC: Complete overhaul of what was posted before, so that it doesn't
make sense to log the older history

Best, 
Gert


 



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

Re: [Mesa-dev] [PATCH] radv: drop the amdgpu-skip-threshold=1 workaround for LLVM 8

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Wed, Dec 19, 2018, 6:13 PM Samuel Pitoiset  This workaround has been introduced by 135e4d434f6 for fixing
> DXVK GPU hangs with many games. It is no longer needed since
> LLVM r345718.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_shader.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> index 2eb5164ac97..5c72890aa8e 100644
> --- a/src/amd/vulkan/radv_shader.c
> +++ b/src/amd/vulkan/radv_shader.c
> @@ -548,9 +548,15 @@ static void radv_init_llvm_target()
>  *
>  * "mesa" is the prefix for error messages.
>  */
> -   const char *argv[3] = { "mesa", "-simplifycfg-sink-common=false",
> -   "-amdgpu-skip-threshold=1" };
> -   LLVMParseCommandLineOptions(3, argv, NULL);
> +   if (HAVE_LLVM >= 0x0800) {
> +   const char *argv[2] = { "mesa",
> "-simplifycfg-sink-common=false" };
> +   LLVMParseCommandLineOptions(2, argv, NULL);
> +
> +   } else {
> +   const char *argv[3] = { "mesa",
> "-simplifycfg-sink-common=false",
> +   "-amdgpu-skip-threshold=1" };
> +   LLVMParseCommandLineOptions(3, argv, NULL);
> +   }
>  }
>
>  static once_flag radv_init_llvm_target_once_flag = ONCE_FLAG_INIT;
> --
> 2.20.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] [PATCH v2] radv: Work around non-renderable 128bpp compressed 3d textures on GFX9.

[Bas Nieuwenhuizen]

Exactly what title says, the new addrlib does not allow the above with
certain dimensions that the CTS seems to hit. Work around it by not
allowing the app to render to it via compat with  other 128bpp formats
and do not render to it ourselves during copies.

Fixes: 776b9113656 "amd/addrlib: update Mesa's copy of addrlib"
Reviewed-by: Nicolai Hähnle 
---
 src/amd/common/ac_surface.c |  6 --
 src/amd/common/ac_surface.h |  1 +
 src/amd/vulkan/radv_formats.c   | 12 
 src/amd/vulkan/radv_image.c |  6 ++
 src/amd/vulkan/radv_meta_copy.c | 24 ++--
 5 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index d8d927ee1c5..8661731e66f 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -1412,11 +1412,13 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
AddrSurfInfoIn.bpp = surf->bpe * 8;
}
 
-   AddrSurfInfoIn.flags.color = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
+   bool is_color_surface = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
+   AddrSurfInfoIn.flags.color = is_color_surface &&
+!(surf->flags & 
RADEON_SURF_NO_RENDER_TARGET);
AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) != 0;
AddrSurfInfoIn.flags.display = get_display_flag(config, surf);
/* flags.texture currently refers to TC-compatible HTILE */
-   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
+   AddrSurfInfoIn.flags.texture = is_color_surface ||
   surf->flags & 
RADEON_SURF_TC_COMPATIBLE_HTILE;
AddrSurfInfoIn.flags.opt4space = 1;
 
diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
index 8ba964e64ec..7ae166c70a3 100644
--- a/src/amd/common/ac_surface.h
+++ b/src/amd/common/ac_surface.h
@@ -68,6 +68,7 @@ enum radeon_micro_mode {
 #define RADEON_SURF_IMPORTED(1 << 24)
 #define RADEON_SURF_OPTIMIZE_FOR_SPACE  (1 << 25)
 #define RADEON_SURF_SHAREABLE   (1 << 26)
+#define RADEON_SURF_NO_RENDER_TARGET(1 << 27)
 
 struct legacy_surf_level {
 uint64_toffset;
diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index 59bc46d2fc8..48727817d32 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -1112,6 +1112,18 @@ static VkResult radv_get_image_format_properties(struct 
radv_physical_device *ph
maxMipLevels = 1;
}
 
+
+   /* We can't create 3d compressed 128bpp images that can be rendered to 
on GFX9 */
+   if (physical_device->rad_info.chip_class >= GFX9 &&
+   info->type == VK_IMAGE_TYPE_3D &&
+   vk_format_get_blocksizebits(info->format) == 128 &&
+   vk_format_is_compressed(info->format) &&
+   (info->flags & VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT) &&
+   ((info->flags &  VK_IMAGE_CREATE_EXTENDED_USAGE_BIT) ||
+(info->usage & VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT))) {
+   goto unsupported;
+   }
+
if (info->usage & VK_IMAGE_USAGE_SAMPLED_BIT) {
if (!(format_feature_flags & 
VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT)) {
goto unsupported;
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 2bd74e202fe..69bbcdcf645 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -249,6 +249,12 @@ radv_init_surface(struct radv_device *device,
if (is_stencil)
surface->flags |= RADEON_SURF_SBUFFER;
 
+   if (device->physical_device->rad_info.chip_class >= GFX9 &&
+   pCreateInfo->imageType == VK_IMAGE_TYPE_3D &&
+   vk_format_get_blocksizebits(pCreateInfo->format) == 128 &&
+   vk_format_is_compressed(pCreateInfo->format))
+   surface->flags |= RADEON_SURF_NO_RENDER_TARGET;
+
surface->flags |= RADEON_SURF_OPTIMIZE_FOR_SPACE;
 
if (!radv_use_dcc_for_image(device, image, create_info, pCreateInfo))
diff --git a/src/amd/vulkan/radv_meta_copy.c b/src/amd/vulkan/radv_meta_copy.c
index ddfb5c54673..647a167ab4c 100644
--- a/src/amd/vulkan/radv_meta_copy.c
+++ b/src/amd/vulkan/radv_meta_copy.c
@@ -107,6 +107,22 @@ blit_surf_for_image_level_layer(struct radv_image *image,
};
 }
 
+static bool
+image_is_renderable(struct radv_device *device, struct radv_image *image)
+{
+   if (image->vk_format == VK_FORMAT_R32G32B32_UINT ||
+   image->vk_format == VK_FORMAT_R32G32B32_SINT ||
+   image->vk_format == VK_FORMAT_R32G32B32_SFLOAT)
+   return false;
+
+   if (device->physical_device->rad_info.chip_class >= GFX9 &&
+   image->type == VK_IMAGE_TYPE_3D &&
+   vk_format_get_blocksizebits(image->vk_format == 128) &&
+   vk_format_is_compressed(image->vk_format))
+  

Re: [Mesa-dev] [PATCH] amd/surface: fix setting of ADDR2_SURFACE_FLAGS::color

[Bas Nieuwenhuizen]

On Thu, Dec 20, 2018 at 9:00 AM Marek Olšák  wrote:
>
> I prefer Nicolai's patch because it's shorter and doesn't need driver changes.
>
> Reviewed-by: Marek Olšák 

This patch still needs driver changes because radv will render to a
compressed surface as r32g32b32a32, so allocating a non-renderable
surface without driver changes goes against actual usage?
>
> Marek
>
> On Tue, Dec 18, 2018 at 12:50 PM Haehnle, Nicolai  
> wrote:
>>
>> On 18.12.18 18:36, Bas Nieuwenhuizen wrote:
>> > Hi Nicolai,
>> >
>> > I happened to be writing something similar which also fixes up radv to
>> > never render to those surfaces as r32g32b32a32:
>> > https://patchwork.freedesktop.org/series/54172/ I can split out the
>> > radv specific stuff and this one is r-b after than.
>>
>> Oh, I missed that, sorry. I don't particularly care about which approach
>> to this is taken.
>>
>> Cheers,
>> Nicolai
>>
>>
>>
>> >
>> > Thanks,
>> > Bas
>> >
>> > On Tue, Dec 18, 2018 at 5:37 PM Nicolai Hähnle  wrote:
>> >>
>> >> From: Nicolai Hähnle 
>> >>
>> >> In the gfx9 addrlib, this bit has been clarified as meaning that
>> >> the surface can be used as a color buffer (render target).
>> >>
>> >> Setting this for compressed surfaces triggers a workaround that
>> >> is only required for surfaces that can be render targets, and ends
>> >> up breaking the 16-byte-per-block case.
>> >>
>> >> Fixes 
>> >> dEQP-VK.pipeline.image.suballocation.sampling_type.combined.view_type.3d.format.etc2_r8g8b8a8_srgb_block.count_1.size.11x11x11
>> >>  and others
>> >>
>> >> Note that there are other related bits which we don't set as intended
>> >> by the interface, notably the 'unordered' bit, which is meant to
>> >> indicate use as a shader image. It may be worth cleaning that up at some
>> >> point after proper testing.
>> >>
>> >> Reported-by: Samuel Pitoiset 
>> >> Fixes: 776b9113656 ("amd/addrlib: update Mesa's copy of addrlib")
>> >> ---
>> >>   src/amd/common/ac_surface.c | 5 ++---
>> >>   1 file changed, 2 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
>> >> index d8d927ee1c5..d647bd523f9 100644
>> >> --- a/src/amd/common/ac_surface.c
>> >> +++ b/src/amd/common/ac_surface.c
>> >> @@ -1405,25 +1405,24 @@ static int gfx9_compute_surface(ADDR_HANDLE 
>> >> addrlib,
>> >>  case 16:
>> >>  assert(!(surf->flags & 
>> >> RADEON_SURF_Z_OR_SBUFFER));
>> >>  AddrSurfInfoIn.format = ADDR_FMT_32_32_32_32;
>> >>  break;
>> >>  default:
>> >>  assert(0);
>> >>  }
>> >>  AddrSurfInfoIn.bpp = surf->bpe * 8;
>> >>  }
>> >>
>> >> -   AddrSurfInfoIn.flags.color = !(surf->flags & 
>> >> RADEON_SURF_Z_OR_SBUFFER);
>> >> +   AddrSurfInfoIn.flags.color = !compressed && !(surf->flags & 
>> >> RADEON_SURF_Z_OR_SBUFFER);
>> >>  AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) 
>> >> != 0;
>> >>  AddrSurfInfoIn.flags.display = get_display_flag(config, surf);
>> >> -   /* flags.texture currently refers to TC-compatible HTILE */
>> >> -   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
>> >> +   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color || 
>> >> compressed ||
>> >> surf->flags & 
>> >> RADEON_SURF_TC_COMPATIBLE_HTILE;
>> >>  AddrSurfInfoIn.flags.opt4space = 1;
>> >>
>> >>  AddrSurfInfoIn.numMipLevels = config->info.levels;
>> >>  AddrSurfInfoIn.numSamples = MAX2(1, config->info.samples);
>> >>  AddrSurfInfoIn.numFrags = AddrSurfInfoIn.numSamples;
>> >>
>> >>  if (!(surf->flags & RADEON_SURF_Z_OR_SBUFFER))
>> >>  AddrSurfInfoIn.numFrags = MAX2(1, 
>> >> config->info.storage_samples);
>> >>
>> >> --
>> >> 2.19.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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] egl: add config debug printout

[Silvestrs Timofejevs]

Eric, thank you for reviewing my patch. I have expanded little bit
on some of your comments bellow. I will be sending fallow up V2 of the patch
shortly.
On Thu, Dec 06, 2018 at 11:00:25AM +, Eric Engestrom wrote:
> On Friday, 2018-11-09 18:04:12 +, Silvestrs Timofejevs wrote:
> > Feature to print out EGL returned configs for debug purposes.
> > 
> > 'eglChooseConfig' and 'eglGetConfigs' debug information printout is
> > enabled when the log level equals '_EGL_DEBUG'. The configs are
> > printed, and if any of them are "chosen" they are marked with their
> > index in the chosen configs array.
> > 
> > Signed-off-by: Silvestrs Timofejevs 
> 
> Sorry it took forever for me to finish reading through this.
> I have a few nits below, but overall it looks all reasonable to me :)
> 
> > ---
> >  src/egl/Makefile.sources  |   4 +-
> >  src/egl/main/eglconfig.c  |  20 ++-
> >  src/egl/main/eglconfigdebug.c | 277 
> > ++
> >  src/egl/main/eglconfigdebug.h |  55 +
> >  src/egl/meson.build   |   2 +
> >  5 files changed, 353 insertions(+), 5 deletions(-)
> >  create mode 100644 src/egl/main/eglconfigdebug.c
> >  create mode 100644 src/egl/main/eglconfigdebug.h
> > 
> > diff --git a/src/egl/Makefile.sources b/src/egl/Makefile.sources
> > index 0cc5f1b..353a848 100644
> > --- a/src/egl/Makefile.sources
> > +++ b/src/egl/Makefile.sources
> > @@ -28,7 +28,9 @@ LIBEGL_C_FILES := \
> > main/eglsync.c \
> > main/eglsync.h \
> > main/eglentrypoint.h \
> > -   main/egltypedefs.h
> > +   main/egltypedefs.h \
> > +   main/eglconfigdebug.h \
> > +   main/eglconfigdebug.c
> >  
> >  dri2_backend_core_FILES := \
> > drivers/dri2/egl_dri2.c \
> > diff --git a/src/egl/main/eglconfig.c b/src/egl/main/eglconfig.c
> > index a346f93..0095dc2 100644
> > --- a/src/egl/main/eglconfig.c
> > +++ b/src/egl/main/eglconfig.c
> > @@ -40,6 +40,7 @@
> >  #include "util/macros.h"
> >  
> >  #include "eglconfig.h"
> > +#include "eglconfigdebug.h"
> >  #include "egldisplay.h"
> >  #include "eglcurrent.h"
> >  #include "egllog.h"
> > @@ -797,14 +798,21 @@ _eglChooseConfig(_EGLDriver *drv, _EGLDisplay *disp, 
> > const EGLint *attrib_list,
> >   EGLConfig *configs, EGLint config_size, EGLint 
> > *num_configs)
> >  {
> > _EGLConfig criteria;
> > +   EGLBoolean result;
> >  
> > if (!_eglParseConfigAttribList(, disp, attrib_list))
> >return _eglError(EGL_BAD_ATTRIBUTE, "eglChooseConfig");
> >  
> > -   return _eglFilterConfigArray(disp->Configs,
> > - configs, config_size, num_configs,
> > - _eglFallbackMatch, _eglFallbackCompare,
> > - (void *) );
> > +   result = _eglFilterConfigArray(disp->Configs,
> > +  configs, config_size, num_configs,
> > +  _eglFallbackMatch, _eglFallbackCompare,
> > +  (void *) );
> > +
> > +   if (result && (_eglGetLogLevel() == _EGL_DEBUG))
> > +  eglPrintConfigDebug(drv, disp, configs, *num_configs,
> > +  EGL_CONFIG_DEBUG_CHOOSE);
> > +
> > +   return result;
> >  }
> >  
> >  
> > @@ -857,5 +865,9 @@ _eglGetConfigs(_EGLDriver *drv, _EGLDisplay *disp, 
> > EGLConfig *configs,
> > *num_config = _eglFlattenArray(disp->Configs, (void *) configs,
> >   sizeof(configs[0]), config_size, _eglFlattenConfig);
> >  
> > +   if (_eglGetLogLevel() == _EGL_DEBUG)
> > +  eglPrintConfigDebug(drv, disp, configs, *num_config,
> > +  EGL_CONFIG_DEBUG_GET);
> > +
> > return EGL_TRUE;
> >  }
> > diff --git a/src/egl/main/eglconfigdebug.c b/src/egl/main/eglconfigdebug.c
> > new file mode 100644
> > index 000..67d6b22
> > --- /dev/null
> > +++ b/src/egl/main/eglconfigdebug.c
> > @@ -0,0 +1,277 @@
> > +/*
> > + * Copyright 2017 Imagination Technologies.
> > + * All Rights Reserved.
> > + *
> > + * Based on eglinfo, which has copyright:
> > + * Copyright (C) 2005  Brian Paul   All Rights Reserved.
> > + *
> > + * 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 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
> > + * BRIAN PAUL BE LIABLE FOR ANY CLAIM, 

Re: [Mesa-dev] [PATCH] ac/nir: remove the bitfield_extract workaround for LLVM 8

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Wed, Dec 19, 2018 at 11:50 AM Samuel Pitoiset 
wrote:

> This workaround has been introduced by 3d41757788a and it
> is no longer needed since LLVM r346422.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 225c930d896..81b76f65b82 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -429,16 +429,22 @@ static LLVMValueRef emit_bitfield_extract(struct
> ac_llvm_context *ctx,
>  {
> LLVMValueRef result;
>
> -   /* FIXME: LLVM 7+ returns incorrect result when count is 0.
> -* https://bugs.freedesktop.org/show_bug.cgi?id=107276
> -*/
> -   LLVMValueRef zero = ctx->i32_0;
> -   LLVMValueRef icond1 = LLVMBuildICmp(ctx->builder, LLVMIntEQ,
> srcs[2], LLVMConstInt(ctx->i32, 32, false), "");
> -   LLVMValueRef icond2 = LLVMBuildICmp(ctx->builder, LLVMIntEQ,
> srcs[2], zero, "");
> +   if (HAVE_LLVM >= 0x0800) {
> +   LLVMValueRef icond = LLVMBuildICmp(ctx->builder,
> LLVMIntEQ, srcs[2], LLVMConstInt(ctx->i32, 32, false), "");
> +   result = ac_build_bfe(ctx, srcs[0], srcs[1], srcs[2],
> is_signed);
> +   result = LLVMBuildSelect(ctx->builder, icond, srcs[0],
> result, "");
> +   } else {
> +   /* FIXME: LLVM 7+ returns incorrect result when count is 0.
> +* https://bugs.freedesktop.org/show_bug.cgi?id=107276
> +*/
> +   LLVMValueRef zero = ctx->i32_0;
> +   LLVMValueRef icond1 = LLVMBuildICmp(ctx->builder,
> LLVMIntEQ, srcs[2], LLVMConstInt(ctx->i32, 32, false), "");
> +   LLVMValueRef icond2 = LLVMBuildICmp(ctx->builder,
> LLVMIntEQ, srcs[2], zero, "");
>
> -   result = ac_build_bfe(ctx, srcs[0], srcs[1], srcs[2], is_signed);
> -   result = LLVMBuildSelect(ctx->builder, icond1, srcs[0], result,
> "");
> -   result = LLVMBuildSelect(ctx->builder, icond2, zero, result, "");
> +   result = ac_build_bfe(ctx, srcs[0], srcs[1], srcs[2],
> is_signed);
> +   result = LLVMBuildSelect(ctx->builder, icond1, srcs[0],
> result, "");
> +   result = LLVMBuildSelect(ctx->builder, icond2, zero,
> result, "");
> +   }
>
> return result;
>  }
> --
> 2.20.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

Re: [Mesa-dev] [PATCH] amd/surface: fix setting of ADDR2_SURFACE_FLAGS::color

[Marek Olšák]

I prefer Nicolai's patch because it's shorter and doesn't need driver
changes.

Reviewed-by: Marek Olšák 

Marek

On Tue, Dec 18, 2018 at 12:50 PM Haehnle, Nicolai 
wrote:

> On 18.12.18 18:36, Bas Nieuwenhuizen wrote:
> > Hi Nicolai,
> >
> > I happened to be writing something similar which also fixes up radv to
> > never render to those surfaces as r32g32b32a32:
> > https://patchwork.freedesktop.org/series/54172/ I can split out the
> > radv specific stuff and this one is r-b after than.
>
> Oh, I missed that, sorry. I don't particularly care about which approach
> to this is taken.
>
> Cheers,
> Nicolai
>
>
>
> >
> > Thanks,
> > Bas
> >
> > On Tue, Dec 18, 2018 at 5:37 PM Nicolai Hähnle 
> wrote:
> >>
> >> From: Nicolai Hähnle 
> >>
> >> In the gfx9 addrlib, this bit has been clarified as meaning that
> >> the surface can be used as a color buffer (render target).
> >>
> >> Setting this for compressed surfaces triggers a workaround that
> >> is only required for surfaces that can be render targets, and ends
> >> up breaking the 16-byte-per-block case.
> >>
> >> Fixes
> dEQP-VK.pipeline.image.suballocation.sampling_type.combined.view_type.3d.format.etc2_r8g8b8a8_srgb_block.count_1.size.11x11x11
> and others
> >>
> >> Note that there are other related bits which we don't set as intended
> >> by the interface, notably the 'unordered' bit, which is meant to
> >> indicate use as a shader image. It may be worth cleaning that up at some
> >> point after proper testing.
> >>
> >> Reported-by: Samuel Pitoiset 
> >> Fixes: 776b9113656 ("amd/addrlib: update Mesa's copy of addrlib")
> >> ---
> >>   src/amd/common/ac_surface.c | 5 ++---
> >>   1 file changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> >> index d8d927ee1c5..d647bd523f9 100644
> >> --- a/src/amd/common/ac_surface.c
> >> +++ b/src/amd/common/ac_surface.c
> >> @@ -1405,25 +1405,24 @@ static int gfx9_compute_surface(ADDR_HANDLE
> addrlib,
> >>  case 16:
> >>  assert(!(surf->flags &
> RADEON_SURF_Z_OR_SBUFFER));
> >>  AddrSurfInfoIn.format = ADDR_FMT_32_32_32_32;
> >>  break;
> >>  default:
> >>  assert(0);
> >>  }
> >>  AddrSurfInfoIn.bpp = surf->bpe * 8;
> >>  }
> >>
> >> -   AddrSurfInfoIn.flags.color = !(surf->flags &
> RADEON_SURF_Z_OR_SBUFFER);
> >> +   AddrSurfInfoIn.flags.color = !compressed && !(surf->flags &
> RADEON_SURF_Z_OR_SBUFFER);
> >>  AddrSurfInfoIn.flags.depth = (surf->flags &
> RADEON_SURF_ZBUFFER) != 0;
> >>  AddrSurfInfoIn.flags.display = get_display_flag(config, surf);
> >> -   /* flags.texture currently refers to TC-compatible HTILE */
> >> -   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
> >> +   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
> compressed ||
> >> surf->flags &
> RADEON_SURF_TC_COMPATIBLE_HTILE;
> >>  AddrSurfInfoIn.flags.opt4space = 1;
> >>
> >>  AddrSurfInfoIn.numMipLevels = config->info.levels;
> >>  AddrSurfInfoIn.numSamples = MAX2(1, config->info.samples);
> >>  AddrSurfInfoIn.numFrags = AddrSurfInfoIn.numSamples;
> >>
> >>  if (!(surf->flags & RADEON_SURF_Z_OR_SBUFFER))
> >>  AddrSurfInfoIn.numFrags = MAX2(1,
> config->info.storage_samples);
> >>
> >> --
> >> 2.19.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