[Mesa-dev] [PATCH v5] i965: Fix ETC2/EAC GetCompressed* functions on Gen7 GPUs

[Eleni Maria Stea]

Gen 7 GPUs store the compressed EAC/ETC2 images in other non-compressed
formats that can render. When GetCompressed* functions are called, the
pixels are returned in the non-compressed format that is used for the
rendering.

With this patch we store both the compressed and non-compressed versions
of the image, so that both rendering commands and GetCompressed*
commands work.

Also, the assertions for GL_MAP_WRITE_BIT and GL_MAP_INVALIDATE_RANGE_BIT
in intel_miptree_map_etc function have been removed because when the
miptree is mapped for reading (for example from a GetCompress*
function) the GL_MAP_WRITE_BIT won't be set (and shouldn't be set).

Fixes: the following test in CTS for gen7:
KHR-GL45.direct_state_access.textures_compressed_subimage test

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

v2: fixes issues:
   a) initialized uninitialized variables (Juan A. Suarez, Andres Gomez)
   b) fixed race condition where mt and cmt were mapped at the same time
   c) fixed indentation issues (Andres Gomez)
v3: adds bugzilla bug with id: 104272
v4: adds bugzilla bug with id: 81843
v5: replaced the flags with a bitfield, refactoring (Kenneth Graunke)
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c |  10 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  10 ++
 src/mesa/drivers/dri/i965/intel_tex.c | 106 +++---
 src/mesa/drivers/dri/i965/intel_tex.h |   1 -
 src/mesa/drivers/dri/i965/intel_tex_image.c   |  46 +++-
 src/mesa/drivers/dri/i965/intel_tex_obj.h |   8 ++
 src/mesa/main/texstore.c  |  51 ++---
 src/mesa/main/texstore.h  |   8 +-
 8 files changed, 197 insertions(+), 43 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 7d1fa96b91..cc807977de 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -733,9 +733,10 @@ miptree_create(struct brw_context *brw,
mesa_format etc_format = MESA_FORMAT_NONE;
uint32_t alloc_flags = 0;
 
-   format = intel_lower_compressed_format(brw, format);
-
-   etc_format = (format != tex_format) ? tex_format : MESA_FORMAT_NONE;
+   if (!(flags & MIPTREE_CREATE_ETC)) {
+  format = intel_lower_compressed_format(brw, format);
+  etc_format = (format != tex_format) ? tex_format : MESA_FORMAT_NONE;
+   }
 
if (flags & MIPTREE_CREATE_BUSY)
   alloc_flags |= BO_ALLOC_BUSY;
@@ -3372,9 +3373,6 @@ intel_miptree_map_etc(struct brw_context *brw,
   assert(mt->format == MESA_FORMAT_R8G8B8X8_UNORM);
}
 
-   assert(map->mode & GL_MAP_WRITE_BIT);
-   assert(map->mode & GL_MAP_INVALIDATE_RANGE_BIT);
-
intel_miptree_access_raw(brw, mt, level, slice, true);
 
map->stride = _mesa_format_row_stride(mt->etc_format, map->w);
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 42f73ba1f9..9e7a401229 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -74,6 +74,7 @@ struct intel_texture_image;
  * without transcoding back.  This flag to intel_miptree_map() gets you that.
  */
 #define BRW_MAP_DIRECT_BIT 0x8000
+#define BRW_MAP_ETC_BIT0x4000
 
 struct intel_miptree_map {
/** Bitfield of GL_MAP_*_BIT and BRW_MAP_*_BIT. */
@@ -380,6 +381,15 @@ enum intel_miptree_create_flags {
 * that the miptree will be created with mt->aux_usage == NONE.
 */
MIPTREE_CREATE_NO_AUX   = 1 << 2,
+
+   /** Create a second miptree for the compressed pixels (Gen7 only)
+*
+* On Gen7, we need to store 2 miptrees for some compressed
+* formats so we can handle rendering as well as getting the
+* compressed image data. This flag indicates that the miptree
+* is expected to hold compressed data for the latter case.
+*/
+   MIPTREE_CREATE_ETC  = 1 << 3,
 };
 
 struct intel_mipmap_tree *intel_miptree_create(struct brw_context *brw,
diff --git a/src/mesa/drivers/dri/i965/intel_tex.c 
b/src/mesa/drivers/dri/i965/intel_tex.c
index 0650b6e629..3a94fa7477 100644
--- a/src/mesa/drivers/dri/i965/intel_tex.c
+++ b/src/mesa/drivers/dri/i965/intel_tex.c
@@ -66,6 +66,8 @@ intel_alloc_texture_image_buffer(struct gl_context *ctx,
struct intel_texture_image *intel_image = intel_texture_image(image);
struct gl_texture_object *texobj = image->TexObject;
struct intel_texture_object *intel_texobj = intel_texture_object(texobj);
+   struct gen_device_info *devinfo = &brw->screen->devinfo;
+   mesa_format fmt = image->TexFormat;
 
assert(image->Border == 0);
 
@@ -110,6 +112,33 @@ intel_alloc_texture_image_buffer(struct gl_context *ctx,
   image->Width, image->Height, image->Depth, intel_image->mt);
}
 
+   if (devinfo->gen < 8 && _mesa_is_format_etc2(fmt)) {
+  if (intel_texobj->cmt &&
+  intel_mipt

Re: [Mesa-dev] [PATCH 4/8] intel/compiler: More peephole select

[Ian Romanick]

On 06/06/2018 05:39 PM, Ian Romanick wrote:
> On 06/06/2018 04:26 PM, Matt Turner wrote:
>> On Wed, Jun 6, 2018 at 2:33 PM, Ian Romanick  wrote:
>>> From: Ian Romanick 
>>>
>>> Shader-db results:
>>>
>>> Skylake and Broadwell had similar results. (Skylake shown)
>>> total instructions in shared programs: 14371513 -> 14346174 (-0.18%)
>>> instructions in affected programs: 890389 -> 865050 (-2.85%)
>>> helped: 3601
>>> HURT: 1
>>> helped stats (abs) min: 1 max: 92 x̄: 7.05 x̃: 4
>>> helped stats (rel) min: 0.10% max: 25.00% x̄: 3.95% x̃: 3.23%
>>> HURT stats (abs)   min: 43 max: 43 x̄: 43.00 x̃: 43
>>> HURT stats (rel)   min: 0.90% max: 0.90% x̄: 0.90% x̃: 0.90%
>>> 95% mean confidence interval for instructions value: -7.27 -6.80
>>> 95% mean confidence interval for instructions %-change: -4.05% -3.84%
>>> Instructions are helped.
>>>
>>> total cycles in shared programs: 532435951 -> 532154282 (-0.05%)
>>> cycles in affected programs: 69203137 -> 68921468 (-0.41%)
>>> helped: 2654
>>> HURT: 981
>>> helped stats (abs) min: 1 max: 4496 x̄: 177.17 x̃: 76
>>> helped stats (rel) min: <.01% max: 71.34% x̄: 9.16% x̃: 5.42%
>>> HURT stats (abs)   min: 1 max: 8 x̄: 192.20 x̃: 19
>>> HURT stats (rel)   min: <.01% max: 36.36% x̄: 2.95% x̃: 1.46%
>>> 95% mean confidence interval for cycles value: -113.38 -41.60
>>> 95% mean confidence interval for cycles %-change: -6.24% -5.53%
>>> Cycles are helped.
>>>
>>> total spills in shared programs: 8114 -> 8122 (0.10%)
>>> spills in affected programs: 152 -> 160 (5.26%)
>>> helped: 0
>>> HURT: 2
>>>
>>> total fills in shared programs: 11082 -> 11100 (0.16%)
>>> fills in affected programs: 375 -> 393 (4.80%)
>>> helped: 1
>>> HURT: 1
>>>
>>> Haswell, Ivy Bridge, and Sandy Bridge had similar results. (Ivy Bridge 
>>> shown)
>>> total instructions in shared programs: 9897654 -> 9890341 (-0.07%)
>>> instructions in affected programs: 213092 -> 205779 (-3.43%)
>>> helped: 775
>>> HURT: 18
>>> helped stats (abs) min: 1 max: 65 x̄: 9.62 x̃: 6
>>> helped stats (rel) min: 0.11% max: 25.00% x̄: 4.85% x̃: 3.70%
>>> HURT stats (abs)   min: 2 max: 20 x̄: 7.89 x̃: 6
>>> HURT stats (rel)   min: 0.70% max: 2.59% x̄: 1.63% x̃: 1.70%
>>> 95% mean confidence interval for instructions value: -9.93 -8.51
>>> 95% mean confidence interval for instructions %-change: -5.01% -4.40%
>>> Instructions are helped.
>>>
>>> total cycles in shared programs: 87653348 -> 87562421 (-0.10%)
>>> cycles in affected programs: 2411339 -> 2320412 (-3.77%)
>>> helped: 612
>>> HURT: 227
>>> helped stats (abs) min: 1 max: 2103 x̄: 162.83 x̃: 53
>>> helped stats (rel) min: 0.05% max: 58.41% x̄: 6.50% x̃: 2.65%
>>> HURT stats (abs)   min: 1 max: 772 x̄: 38.43 x̃: 10
>>> HURT stats (rel)   min: 0.04% max: 36.36% x̄: 3.60% x̃: 0.92%
>>> 95% mean confidence interval for cycles value: -128.53 -88.22
>>> 95% mean confidence interval for cycles %-change: -4.39% -3.14%
>>> Cycles are helped.
>>>
>>> No change on Iron Lake or GM45.
>>>
>>> Signed-off-by: Ian Romanick 
>>> ---
>>>  src/intel/compiler/brw_nir.c | 14 ++
>>>  1 file changed, 14 insertions(+)
>>>
>>> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
>>> index 67c062d91f5..ca9b021767f 100644
>>> --- a/src/intel/compiler/brw_nir.c
>>> +++ b/src/intel/compiler/brw_nir.c
>>> @@ -557,7 +557,21 @@ brw_nir_optimize(nir_shader *nir, const struct 
>>> brw_compiler *compiler,
>>>OPT(nir_copy_prop);
>>>OPT(nir_opt_dce);
>>>OPT(nir_opt_cse);
>>> +
>>> +  /* Passing 0 to the peephole select pass causes it to convert
>>> +   * if-statements that contain only move instructions in the branches
>>> +   * regardless of the count.
>>> +   *
>>> +   * Passing 0 to the peephole select pass causes it to convert
> 
>  Passing 1
> 
> I thought I already fixed that. :(
> 
>>> +   * if-statements that contain at most a single ALU instruction 
>>> (total)
>>> +   * in both branches.  The select instruction works somewhat 
>>> differently
>>> +   * on Gen5 and earlier, and adding this pass on those platforms was
>>
>> It does? Something about min/max requiring the CMP?
> 
> I remember thinking the problem was obvious when I looked at the first
> shader that was hurt, but I don't recall exactly what it was now.  I'll
> try it again.

Here are the ILK results:

total instructions in shared programs: 7774514 -> 7773708 (-0.01%)
instructions in affected programs: 89355 -> 88549 (-0.90%)
helped: 162
HURT: 26
helped stats (abs) min: 2 max: 18 x̄: 6.46 x̃: 6
helped stats (rel) min: 0.17% max: 13.04% x̄: 2.29% x̃: 1.09%
HURT stats (abs)   min: 2 max: 20 x̄: 9.23 x̃: 8
HURT stats (rel)   min: 0.70% max: 2.48% x̄: 1.66% x̃: 1.61%
95% mean confidence interval for instructions value: -5.25 -3.32
95% mean confidence interval for instructions %-change: -2.14% -1.35%
Instructions are helped.

total cycles in shared programs: 177899700 -> 177958996 (0.03%)
cycles in affected programs: 753424 -> 812720 (7.87

[Mesa-dev] [PATCH v2 02/22] i965/fs: Implement float64/int64 to float16 conversion

[Samuel Iglesias Gonsálvez]

It is not supported directly in the HW, we need to convert to a 32-bit
type first as intermediate step.

v2 (Iago): handle conversions from 64-bit integers as well

Signed-off-by: Samuel Iglesias Gonsálvez 
---

Added missing (u)int64 -> fp16 conversion and fixed issues with the
fallthroughs.

 src/intel/compiler/brw_fs_nir.cpp | 47 ---
 1 file changed, 43 insertions(+), 4 deletions(-)

diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index 3f13dafaac4..26312ce82e3 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -755,6 +755,19 @@ fs_visitor::nir_emit_alu(const fs_builder &bld, 
nir_alu_instr *instr)
*/
 
case nir_op_f2f16_undef:
+  /* BDW PRM, vol02, Command Reference Instructions, mov - MOVE:
+   *
+   *   "There is no direct conversion from HF to DF or DF to HF.
+   *Use two instructions and F (Float) as an intermediate type.
+   */
+  if (nir_src_bit_size(instr->src[0].src) == 64) {
+ fs_reg tmp = bld.vgrf(BRW_REGISTER_TYPE_F, 1);
+ inst = bld.MOV(tmp, op[0]);
+ inst->saturate = instr->dest.saturate;
+ inst = bld.MOV(result, tmp);
+ inst->saturate = instr->dest.saturate;
+ break;
+  }
   inst = bld.MOV(result, op[0]);
   inst->saturate = instr->dest.saturate;
   break;
@@ -793,7 +806,10 @@ fs_visitor::nir_emit_alu(const fs_builder &bld, 
nir_alu_instr *instr)
  inst->saturate = instr->dest.saturate;
  break;
   }
-  /* fallthrough */
+  inst = bld.MOV(result, op[0]);
+  inst->saturate = instr->dest.saturate;
+  break;
+
case nir_op_i2f64:
case nir_op_i2i64:
case nir_op_u2f64:
@@ -821,7 +837,32 @@ fs_visitor::nir_emit_alu(const fs_builder &bld, 
nir_alu_instr *instr)
  inst->saturate = instr->dest.saturate;
  break;
   }
-  /* fallthrough */
+  inst = bld.MOV(result, op[0]);
+  inst->saturate = instr->dest.saturate;
+  break;
+
+   case nir_op_i2f16:
+   case nir_op_u2f16:
+  /* BDW PRM, vol02, Command Reference Instructions, mov - MOVE:
+   *
+   *"There is no direct conversion from HF to Q/UQ or Q/UQ to HF.
+   * Use two instructions and F (Float) or a word integer type or a
+   * DWord integer type as an intermediate type."
+   */
+  if (nir_src_bit_size(instr->src[0].src) == 64) {
+ brw_reg_type reg_type = instr->op == nir_op_i2f16 ?
+BRW_REGISTER_TYPE_D : BRW_REGISTER_TYPE_UD;
+ fs_reg tmp = bld.vgrf(reg_type, 1);
+ inst = bld.MOV(tmp, op[0]);
+ inst->saturate = instr->dest.saturate;
+ inst = bld.MOV(result, tmp);
+ inst->saturate = instr->dest.saturate;
+ break;
+  }
+  inst = bld.MOV(result, op[0]);
+  inst->saturate = instr->dest.saturate;
+  break;
+
case nir_op_f2f32:
case nir_op_f2i32:
case nir_op_f2u32:
@@ -831,8 +872,6 @@ fs_visitor::nir_emit_alu(const fs_builder &bld, 
nir_alu_instr *instr)
case nir_op_u2u32:
case nir_op_i2i16:
case nir_op_u2u16:
-   case nir_op_i2f16:
-   case nir_op_u2f16:
   inst = bld.MOV(result, op[0]);
   inst->saturate = instr->dest.saturate;
   break;
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

[Stuart Young]

I see that the theme and logo is now on the test site! All looks good.

As a test, I threw the site at WebSiteTest, Pingdom, GTMetrix and Google
PageSpeed Insights and all came back with great results.

There's a few things like client caching times of static resources like
css/js/tff/woff/etc and Vary: Accept Encoding, but that's usually all
server setup (existing mesa site isn't much better).

Things missing that probably should be addressed:
1. favicon.ico - I can see it in the v2 repo, but looks like it's still not
loading. Not sure what's going on there. Permissions issue (world readable)?
2. _static/fonts/fontawesome-webfont.woff2?v=4.6.3 seems to fail to load.
Definitely not there at
https://gitlab.freedesktop.org/ldeks/mesa/tree/website1_75_v2/docs/ which
I'm assuming is the latest update out there?

FWIW: Both of those 404.

Beyond that, I can't see anything that's a showstopper IMO (major or minor).

Guess the main thing now is sorting out the archives/ directory.


On 3 June 2018 at 09:49, Jason Ekstrand  wrote:

> With all this talk of fancy looking new websites, I decided to take a
> crack at being artsy and coming up with a fancy-looking logo to put on it.
> Here's a first rough draft:
>
> https://people.freedesktop.org/~jekstrand/gears-logo-bold.png
>
> It's not great but it turned out better than I expected.  That version
> looks good on a light background but it could probably be tweaked to look
> good on dark/black if we want.
>
> --Jason
>
>
>
> On Fri, Jun 1, 2018 at 2:46 AM, Eric Engestrom 
> wrote:
>
>> On Thursday, 2018-05-31 21:33:16 -0400, mesa-dev-bounces@lists.freedes
>> ktop.org wrote:
>> > On Thu, May 31, 2018 at 8:31 PM, Jordan Justen
>> >  wrote:
>> > > On 2018-05-31 16:06:13, Laura Ekstrand wrote:
>> > >> A little bit of messing around this afternoon, led to this:
>> > >> https://drive.google.com/file/d/1rteTv9415XEMN1E11fyN0l3hTUC
>> Cbgwz/view?usp=sharing
>> > >
>> > > Nice. That confirms we can easily get back to a something closer to
>> > > the older look in short order. (Unless the consensus is to actually
>> > > stay with the generic look.)
>> > >
>> > >> The gears are from Font Awesome, which comes with the RTD format.
>> > >
>> > > It'd be nice to get the icon back, but the gear glyph is an
>> > > improvement compared to the house glyph.
>> > >
>> > > Anyway, I stick by what I said below too in reply to Eric about
>> > > withdrawing my feedback.
>> >
>> > my $0.02 (which is probably worth even less when it comes to the topic
>> > of aesthetics), Laura's new proposal looks much nicer than generic rtd
>> > which looks better than current site..
>> >
>> > I mostly don't want to get a much needed infrastructure/process
>> > improvement derailed with a bikeshed discussion about themes.  Nothing
>> > against playing with theme options and seeing what people (with better
>> > taste than me) like, just don't want that to be something that derails
>> > the bigger picture ;-)
>>
>> Entirely agreed. I also think the old style was distinctive and had
>> become part of the "personality" of our website, and I would like the
>> new website to look similar, but this is a minor detail that we can
>> trivially alter later.
>>
>> For now let's focus on the infrastructure changes, discussing the style
>> can be done in parallel or later, but shouldn't block this.
>>
>> >
>> > BR,
>> > -R
>> >
>> >
>> > >
>> > > Thanks,
>> > >
>> > > -Jordan
>> > >
>> > >> On Thu, May 31, 2018 at 1:55 PM, Jordan Justen <
>> jordan.l.jus...@intel.com>
>> > >> wrote:
>> > >>
>> > >> > On 2018-05-31 12:27:04, Eric Anholt wrote:
>> > >> > > Jordan Justen  writes:
>> > >> > >
>> > >> > > > On 2018-05-24 17:37:09, Laura Ekstrand wrote:
>> > >> > > >> A few of the commits are quite large and awaiting list
>> approval.  I
>> > >> > suggest
>> > >> > > >> that you take a look at the code here:
>> > >> > > >> https://gitlab.freedesktop.org/ldeks/mesa/tree/website1_75,
>> > >> > > >> and the new website here: https://mesa-test.freedesktop.
>> > >> > org/index.html
>> > >> > > >
>> > >> > > > I think the theme should be changed to look somewhat close to
>> the
>> > >> > > > current mesa3d.org website before changing the main site.
>> (Color
>> > >> > > > scheme and missing icons.)
>> > >> > > >
>> > >> > > > Right now the test website looks like a million other sphinx
>> websites,
>> > >> > > > including every readthedocs book.
>> > >> > > >
>> > >> > > > Based on http://www.sphinx-doc.org/en/master/ and
>> > >> > > > https://www.python.org/, I would say sphinx gives a lot of
>> > >> > > > opportunities for a custom look.
>> > >> > >
>> > >> > > I think looking like a generic other sphinx website is a step
>> forward,
>> > >> > > and I look forward to this series landing.  No need for
>> continuity with
>> > >> > > the old theme.
>> > >> >
>> > >> > I think it is 1 step forward, 1 step back. As no else appears to
>> > >> > agree, I'll withdraw my feedback.
>> > >> >
>> > >> > -Jordan
>> > >> >
>> > > ___

Re: [Mesa-dev] [PATCH v2] intel/blorp: Emit VF cache invalidates for 48-bit bugs with softpin.

[Kenneth Graunke]

On Wednesday, June 6, 2018 6:39:19 PM PDT Kenneth Graunke wrote:
> +/**
> + * See vf_invalidate_for_vb_48b_transitions in genX_state_upload.c.
> + */
> +static void
> +blorp_vf_invalidate_for_vb_48b_transitions(struct blorp_batch *batch,
> +   const struct blorp_address *addrs,
> +   unsigned num_vbs)
> +{
> +#if GEN_GEN >= 8
> +   struct brw_context *brw = batch->driver_batch;
> +   bool need_invalidate = false;
> +
> +   for (unsigned i = 0; i < num_vbs; i++) {
> +  struct brw_bo *bo = addrs[i].buffer;
> +  uint16_t high_bits =
> + bo && (bo->kflags & EXEC_OBJECT_PINNED) ? bo->gtt_offset >> 32u : 0;
> +
> +  if (high_bits != brw->vb.last_bo_high_bits[i]) {

Jason noticed that I botched this again...I added need_invalidate = true
here so it actually does something.

I've gone ahead and pushed this a bit early, since it enabled me to push
the rest of my softpin series and Jordan was blocked on that happening.

> + brw->vb.last_bo_high_bits[i] = high_bits;
> +  }
> +   }
> +
> +   if (need_invalidate) {
> +  brw_emit_pipe_control_flush(brw, PIPE_CONTROL_VF_CACHE_INVALIDATE);
> +   }
> +#endif
> +}
> +
>  #if GEN_GEN >= 8
>  static struct blorp_address
>  blorp_get_workaround_page(struct blorp_batch *batch)
> 



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

Re: [Mesa-dev] [PATCH mesa] vma/tests: cast away implementation detail of using strtoul()

[Dylan Baker]

Yeah, Scott and I thought that went to the list before I did an offer the 
shoulder review, then realized it didn't after pushing.

On June 6, 2018 10:31:38 AM PDT, Eric Anholt  wrote:
>Eric Engestrom  writes:
>
>> On MacOS, the build fails because of a compiler complaint about
>> a downcast:
>>
>>   vma_random_test.cpp:239:18: error: non-constant-expression cannot
>be narrowed from type 'unsigned long' to 'uint_fast32_t' (aka 'unsigned
>int') in initializer list [-Wc++11-narrowing]
>>  random_test r{seed};
>>^~~~
>>   vma_random_test.cpp:239:18: note: insert an explicit cast to
>silence this issue
>>  random_test r{seed};
>>^~~~
>>static_cast( )
>>
>> Let's take the compiler's suggestion, as we only needed a long here
>to
>> use strtoul().
>>
>> Cc: Scott D Phillips 
>> Signed-off-by: Eric Engestrom 
>
>This commit seems to have resolved the issue:
>
>commit 08535dd8860951ce4572cd2590e417a1f3d96b3d
>Author: Scott D Phillips 
>Date:   Tue Jun 5 09:29:43 2018 -0700
>
>util/tests/vma: Fix warning c++11-narrowing
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] intel/blorp: Emit VF cache invalidates for 48-bit bugs with softpin.

[Jason Ekstrand]

On Wed, Jun 6, 2018 at 6:39 PM, Kenneth Graunke 
wrote:

> commit 92f01fc5f914fd500497d0c3aed75f3ac8dc054d made i965 start emitting
> VF cache invalidates when the high bits of vertex buffers change.  But
> we were not tracking vertex buffers emitted by BLORP.  This was papered
> over by a mistake where I emitted VF cache invalidates all the time,
> which Chris fixed in commit 3ac5fbadfd8644d30fce9ff267cb811ad157996a.
>
> This patch adds a new hook which allows the driver to track addresses
> and request a VF cache invalidate as appropriate.
>
> v2: Make the driver do the PIPE_CONTROL so it can apply workarounds
> (caught by Jason Ekstrand).  Rebase on anv bug fix.
>
> Fixes: 92f01fc5f914 ("i965: Emit VF cache invalidates for 48-bit
> addressing bugs with softpin.")
> ---
>  src/intel/blorp/blorp_genX_exec.h   | 17 +
>  src/intel/vulkan/genX_blorp_exec.c  | 10 
>  src/mesa/drivers/dri/i965/genX_blorp_exec.c | 28 +
>  3 files changed, 50 insertions(+), 5 deletions(-)
>
> diff --git a/src/intel/blorp/blorp_genX_exec.h
> b/src/intel/blorp/blorp_genX_exec.h
> index bcaef4f367c..4800c7dcaaf 100644
> --- a/src/intel/blorp/blorp_genX_exec.h
> +++ b/src/intel/blorp/blorp_genX_exec.h
> @@ -59,6 +59,10 @@ blorp_alloc_dynamic_state(struct blorp_batch *batch,
>  static void *
>  blorp_alloc_vertex_buffer(struct blorp_batch *batch, uint32_t size,
>struct blorp_address *addr);
> +static void
> +blorp_vf_invalidate_for_vb_48b_transitions(struct blorp_batch *batch,
> +   const struct blorp_address
> *addrs,
> +   unsigned num_vbs);
>
>  #if GEN_GEN >= 8
>  static struct blorp_address
> @@ -334,19 +338,22 @@ blorp_emit_vertex_buffers(struct blorp_batch *batch,
> uint32_t num_vbs = 2;
> memset(vb, 0, sizeof(vb));
>
> -   struct blorp_address addr;
> +   struct blorp_address addrs[2] = {};
> uint32_t size;
> -   blorp_emit_vertex_data(batch, params, &addr, &size);
> -   blorp_fill_vertex_buffer_state(batch, vb, 0, addr, size, 3 *
> sizeof(float));
> +   blorp_emit_vertex_data(batch, params, &addrs[0], &size);
> +   blorp_fill_vertex_buffer_state(batch, vb, 0, addrs[0], size,
> +  3 * sizeof(float));
>
> -   blorp_emit_input_varying_data(batch, params, &addr, &size);
> -   blorp_fill_vertex_buffer_state(batch, vb, 1, addr, size, 0);
> +   blorp_emit_input_varying_data(batch, params, &addrs[1], &size);
> +   blorp_fill_vertex_buffer_state(batch, vb, 1, addrs[1], size, 0);
>
> const unsigned num_dwords = 1 + num_vbs * GENX(VERTEX_BUFFER_STATE_
> length);
> uint32_t *dw = blorp_emitn(batch, GENX(3DSTATE_VERTEX_BUFFERS),
> num_dwords);
> if (!dw)
>return;
>
> +   blorp_vf_invalidate_for_vb_48b_transitions(batch, addrs, num_vbs);
> +
> for (unsigned i = 0; i < num_vbs; i++) {
>GENX(VERTEX_BUFFER_STATE_pack)(batch, dw, &vb[i]);
>dw += GENX(VERTEX_BUFFER_STATE_length);
> diff --git a/src/intel/vulkan/genX_blorp_exec.c
> b/src/intel/vulkan/genX_blorp_exec.c
> index ecca3928de5..2035017ce0e 100644
> --- a/src/intel/vulkan/genX_blorp_exec.c
> +++ b/src/intel/vulkan/genX_blorp_exec.c
> @@ -158,6 +158,16 @@ blorp_alloc_vertex_buffer(struct blorp_batch *batch,
> uint32_t size,
> return vb_state.map;
>  }
>
> +static void
> +blorp_vf_invalidate_for_vb_48b_transitions(struct blorp_batch *batch,
> +   const struct blorp_address
> *addrs,
> +   unsigned num_vbs)
> +{
> +   /* anv forces all vertex buffers into the low 4GB so there are never
> any
> +* transitions that require a VF invalidation.
> +*/
> +}
> +
>  #if GEN_GEN >= 8
>  static struct blorp_address
>  blorp_get_workaround_page(struct blorp_batch *batch)
> diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> index 808bff0db85..13f8abebb47 100644
> --- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> +++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> @@ -189,6 +189,34 @@ blorp_alloc_vertex_buffer(struct blorp_batch *batch,
> uint32_t size,
> return data;
>  }
>
> +/**
> + * See vf_invalidate_for_vb_48b_transitions in genX_state_upload.c.
> + */
> +static void
> +blorp_vf_invalidate_for_vb_48b_transitions(struct blorp_batch *batch,
> +   const struct blorp_address
> *addrs,
> +   unsigned num_vbs)
> +{
> +#if GEN_GEN >= 8
> +   struct brw_context *brw = batch->driver_batch;
> +   bool need_invalidate = false;
> +
> +   for (unsigned i = 0; i < num_vbs; i++) {
> +  struct brw_bo *bo = addrs[i].buffer;
> +  uint16_t high_bits =
> + bo && (bo->kflags & EXEC_OBJECT_PINNED) ? bo->gtt_offset >> 32u
> : 0;
> +
> +  if (high_bits != brw->vb.last_bo_high_bits[i]) {
> + brw->vb.last_bo_high_bit

[Mesa-dev] [PATCH v2] intel/blorp: Emit VF cache invalidates for 48-bit bugs with softpin.

[Kenneth Graunke]

commit 92f01fc5f914fd500497d0c3aed75f3ac8dc054d made i965 start emitting
VF cache invalidates when the high bits of vertex buffers change.  But
we were not tracking vertex buffers emitted by BLORP.  This was papered
over by a mistake where I emitted VF cache invalidates all the time,
which Chris fixed in commit 3ac5fbadfd8644d30fce9ff267cb811ad157996a.

This patch adds a new hook which allows the driver to track addresses
and request a VF cache invalidate as appropriate.

v2: Make the driver do the PIPE_CONTROL so it can apply workarounds
(caught by Jason Ekstrand).  Rebase on anv bug fix.

Fixes: 92f01fc5f914 ("i965: Emit VF cache invalidates for 48-bit addressing 
bugs with softpin.")
---
 src/intel/blorp/blorp_genX_exec.h   | 17 +
 src/intel/vulkan/genX_blorp_exec.c  | 10 
 src/mesa/drivers/dri/i965/genX_blorp_exec.c | 28 +
 3 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/src/intel/blorp/blorp_genX_exec.h 
b/src/intel/blorp/blorp_genX_exec.h
index bcaef4f367c..4800c7dcaaf 100644
--- a/src/intel/blorp/blorp_genX_exec.h
+++ b/src/intel/blorp/blorp_genX_exec.h
@@ -59,6 +59,10 @@ blorp_alloc_dynamic_state(struct blorp_batch *batch,
 static void *
 blorp_alloc_vertex_buffer(struct blorp_batch *batch, uint32_t size,
   struct blorp_address *addr);
+static void
+blorp_vf_invalidate_for_vb_48b_transitions(struct blorp_batch *batch,
+   const struct blorp_address *addrs,
+   unsigned num_vbs);
 
 #if GEN_GEN >= 8
 static struct blorp_address
@@ -334,19 +338,22 @@ blorp_emit_vertex_buffers(struct blorp_batch *batch,
uint32_t num_vbs = 2;
memset(vb, 0, sizeof(vb));
 
-   struct blorp_address addr;
+   struct blorp_address addrs[2] = {};
uint32_t size;
-   blorp_emit_vertex_data(batch, params, &addr, &size);
-   blorp_fill_vertex_buffer_state(batch, vb, 0, addr, size, 3 * sizeof(float));
+   blorp_emit_vertex_data(batch, params, &addrs[0], &size);
+   blorp_fill_vertex_buffer_state(batch, vb, 0, addrs[0], size,
+  3 * sizeof(float));
 
-   blorp_emit_input_varying_data(batch, params, &addr, &size);
-   blorp_fill_vertex_buffer_state(batch, vb, 1, addr, size, 0);
+   blorp_emit_input_varying_data(batch, params, &addrs[1], &size);
+   blorp_fill_vertex_buffer_state(batch, vb, 1, addrs[1], size, 0);
 
const unsigned num_dwords = 1 + num_vbs * GENX(VERTEX_BUFFER_STATE_length);
uint32_t *dw = blorp_emitn(batch, GENX(3DSTATE_VERTEX_BUFFERS), num_dwords);
if (!dw)
   return;
 
+   blorp_vf_invalidate_for_vb_48b_transitions(batch, addrs, num_vbs);
+
for (unsigned i = 0; i < num_vbs; i++) {
   GENX(VERTEX_BUFFER_STATE_pack)(batch, dw, &vb[i]);
   dw += GENX(VERTEX_BUFFER_STATE_length);
diff --git a/src/intel/vulkan/genX_blorp_exec.c 
b/src/intel/vulkan/genX_blorp_exec.c
index ecca3928de5..2035017ce0e 100644
--- a/src/intel/vulkan/genX_blorp_exec.c
+++ b/src/intel/vulkan/genX_blorp_exec.c
@@ -158,6 +158,16 @@ blorp_alloc_vertex_buffer(struct blorp_batch *batch, 
uint32_t size,
return vb_state.map;
 }
 
+static void
+blorp_vf_invalidate_for_vb_48b_transitions(struct blorp_batch *batch,
+   const struct blorp_address *addrs,
+   unsigned num_vbs)
+{
+   /* anv forces all vertex buffers into the low 4GB so there are never any
+* transitions that require a VF invalidation.
+*/
+}
+
 #if GEN_GEN >= 8
 static struct blorp_address
 blorp_get_workaround_page(struct blorp_batch *batch)
diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c 
b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
index 808bff0db85..13f8abebb47 100644
--- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
+++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
@@ -189,6 +189,34 @@ blorp_alloc_vertex_buffer(struct blorp_batch *batch, 
uint32_t size,
return data;
 }
 
+/**
+ * See vf_invalidate_for_vb_48b_transitions in genX_state_upload.c.
+ */
+static void
+blorp_vf_invalidate_for_vb_48b_transitions(struct blorp_batch *batch,
+   const struct blorp_address *addrs,
+   unsigned num_vbs)
+{
+#if GEN_GEN >= 8
+   struct brw_context *brw = batch->driver_batch;
+   bool need_invalidate = false;
+
+   for (unsigned i = 0; i < num_vbs; i++) {
+  struct brw_bo *bo = addrs[i].buffer;
+  uint16_t high_bits =
+ bo && (bo->kflags & EXEC_OBJECT_PINNED) ? bo->gtt_offset >> 32u : 0;
+
+  if (high_bits != brw->vb.last_bo_high_bits[i]) {
+ brw->vb.last_bo_high_bits[i] = high_bits;
+  }
+   }
+
+   if (need_invalidate) {
+  brw_emit_pipe_control_flush(brw, PIPE_CONTROL_VF_CACHE_INVALIDATE);
+   }
+#endif
+}
+
 #if GEN_GEN >= 8
 static struct blorp_address
 blorp_get_workaround_page(struct blorp_batch *batch)
-- 
2.17.0

_

Re: [Mesa-dev] [PATCH 1/2] nir: add pass to move load_const

[Rob Clark]

On Wed, Jun 6, 2018 at 8:34 PM, Ian Romanick  wrote:
> On 06/06/2018 04:47 PM, Rob Clark wrote:
>> On Wed, Jun 6, 2018 at 6:51 PM, Ian Romanick  wrote:
>>> On 06/06/2018 07:43 AM, Rob Clark wrote:
 Run this pass late (after opt loop) to move load_const instructions back
 into the basic blocks which use the result, in cases where a load_const
 is only consumed in a single block.
>>>
>>> If the load_const is used in more than one block, you could use it to
>>> the block that dominates all of the block that contain a use.  I suspect
>>> in many cases that will just be the first block, but it's probably worth
>>> trying.
>>
>> hmm, good point.. I was mostly going for the super-obvious wins with
>> now downside cases (ie. low hanging fruit), but I guess the block that
>> dominates all the uses isn't going to be worse than the first block..
>>
>> I can play around w/ the common denominator case.. although in at
>> least some cases I think it might be better to split the load_const.
>> Idk, the low hanging fruit approach cuts register usage by 1/3rd in
>> some of these edge case shaders, which by itself seems like a big
>> enough win, but I guess nir_shader_compiler_options config params is
>> an option for more aggressive approaches that may or may not be a win
>> for different drivers.
>
> True.  We could land this and incrementally improve it later.  If we
> want to do that, I'd suggest
>
>  - Put all of our ideas for improving the pass, including the one
>already documented in the code, to the file header comment.
>
>  - Remove the suggestions for future work from the "if consumed in more
>than one block, ignore." comment.

sgtm, I'll respin tomorrow.. maybe after playing around a bit w/ the
common denominator block thing (since I see some cases that seems like
it would benefit)

>
 This helps reduce register usage in cases where the backend driver
 cannot lower the load_const to a uniform.
>>>
>>> The trade off is that now you might not be able to hide the latency of
>>> the load.  I tried this on i965, and the results (below) support this
>>> idea a bit.  If you have a structured backend IR, this seems like a
>>> thing better done there... like, if you can't register allocate without
>>> spilling, try moving the load.  But that's really just a scheduling
>>> heuristic.  Hmm...
>>
>> iirc, i965 had some clever load_const lower passes so all the threads
>> in a warp could share the same load_const (iirc?  I might not have
>> that description quite right)..  so I wasn't expecting this to be
>> useful to i965 (but if it is, then, bonus!).  For me I can *almost*
>> always lower load_const to uniform, so in the common cases it hasn't
>> been a problem.  The exceptions are cases where an alu instruction
>> consume >1 const (but those get optimized away) or a const plus
>> uniform, or things like ssbo/image store.  (I noticed the register
>> usage blowing up thing looking at some deqp tests like
>> dEQP-GLES31.functional.ssbo.layout.2_level_array.shared.vec4 ;-))
>
> There are some optimizations for loading constants in the vec4 backend.
> There is some code to lower arrays of constants to uniforms.  Uniforms
> are already shared within the SIMD group.  I don't know of anything
> other than that, but that's doesn't mean such a thing doesn't exist.
>
> Also... at what point do you call this pass?  Here's what I did for
> i965... basically called it as late as I thought was possible:
>
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index dfeea73b06a..2209d6142b3 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -795,6 +795,8 @@ brw_postprocess_nir(nir_shader *nir, const struct
> brw_compiler *compiler,
> if (devinfo->gen <= 5)
>brw_nir_analyze_boolean_resolves(nir);
>
> +   nir_move_load_const(nir);
> +

fwiw, this is basically we I called it for ir3, it is intended to be
after opt loop (or really anything that might move load_const back to
the top of the first block)..

but tbh I didn't play with it that much yet, other than seeing that it
was a big with for the pedantic cases (like the deqp test I
mentioned).  I think about the only thing I do after the
nir_move_load_const() pass is nir_lower_locals_to_regs +
nir_convert_from_ssa(phi_webs_only=true)


> nir_sweep(nir);
>
> if (unlikely(debug_enabled)) {
>
> Now that the full shader-db run is done, it seems to have some odd
> effects on vec4 shaders, so I'll probably tweak this a bit.
>
>> If latency of the load is an issue, perhaps a configuration option
>> about the minimum size of destination use_block, with the rough theory
>> that if the block is bigger than some threshold the instruction
>> scheduling could probably hide the latency?
>
> I thought about this a bit more... I think the driver's scheduler should
> fix this case.  If it can't hide the latency of a load immediate, the
> scheduler should move it to the earlier block.  That might even hel

Re: [Mesa-dev] [PATCH 2/2] nir: add opt_if_loop_terminator()

[Ian Romanick]

On 06/03/2018 11:30 PM, Timothy Arceri wrote:
> On 02/06/18 04:34, Ian Romanick wrote:
> 
>> On 05/31/2018 10:37 PM, Timothy Arceri wrote:
>>> This pass detects potential loop terminators and moves intructions
>>> from the non breaking branch after the if.
>>>
>>> This enables both the new opt_if_simplification() pass and loop
>>> unrolling to potentially progress further.
>>>
>>> Unexpectedly this change speed up shader-db run times by ~3%
>>>
>>> Ivy Bridge shader-db results (all changes in dolphin/ubershaders):
>> I was going to look at the changes in the generated code, but the
>> smallest of these shaders is > 2300 instructions.
>>
>> Do you have any idea if any piglit or CTS tests hit this optimization
>> path?
> 
> Ok I've sent a loop unrolling piglit test for this:
> 
> https://patchwork.freedesktop.org/patch/227292/

Cool.  This series is

Reviewed-by: Ian Romanick 

> Which also found a loop unrolling bug which requires the following mesa
> patch to pass:
> 
> https://patchwork.freedesktop.org/patch/227299/
> 
>>
>> One tiny nit below...
>>
>>> total instructions in shared programs: 9995662 -> 9995338 (-0.00%)
>>> instructions in affected programs: 87845 -> 87521 (-0.37%)
>>> helped: 27
>>> HURT: 0
>>>
>>> total cycles in shared programs: 230931495 -> 230925015 (-0.00%)
>>> cycles in affected programs: 56391385 -> 56384905 (-0.01%)
>>> helped: 27
>>> HURT: 0
>>> ---
>>>   src/compiler/nir/nir_opt_if.c | 68 +++
>>>   1 file changed, 68 insertions(+)
>>>
>>> diff --git a/src/compiler/nir/nir_opt_if.c
>>> b/src/compiler/nir/nir_opt_if.c
>>> index b03657a4244..1edeefdd5d1 100644
>>> --- a/src/compiler/nir/nir_opt_if.c
>>> +++ b/src/compiler/nir/nir_opt_if.c
>>> @@ -24,6 +24,7 @@
>>>   #include "nir.h"
>>>   #include "nir/nir_builder.h"
>>>   #include "nir_control_flow.h"
>>> +#include "nir_loop_analyze.h"
>>>     /**
>>>    * This optimization detects if statements at the tops of loops
>>> where the
>>> @@ -283,6 +284,72 @@ opt_if_simplification(nir_builder *b, nir_if *nif)
>>>  return true;
>>>   }
>>>   +/**
>>> + * This optimization simplifies potential loop terminators which
>>> then allows
>>> + * other passes such as opt_if_simplification() and loop unrolling
>>> to progress
>>> + * further:
>>> + *
>>> + * if (cond) {
>>> + *    ... then block instructions ...
>>> + * } else {
>>> + * ...
>>> + *    break;
>>> + * }
>>> + *
>>> + * into:
>>> + *
>>> + * if (cond) {
>>> + * } else {
>>> + * ...
>>> + *    break;
>>> + * }
>>> + * ... then block instructions ...
>>> + */
>>> +static bool
>>> +opt_if_loop_terminator(nir_if *nif)
>>> +{
>>> +   nir_block *break_blk = NULL;
>>> +   nir_block *continue_from_blk = NULL;
>>> +   bool continue_from_then = true;
>>> +
>>> +   nir_block *last_then = nir_if_last_then_block(nif);
>>> +   nir_block *last_else = nir_if_last_else_block(nif);
>>> +
>>> +   if (nir_block_ends_in_break(last_then)) {
>>> +  break_blk = last_then;
>>> +  continue_from_blk = last_else;
>>> +  continue_from_then = false;
>>> +   } else if (nir_block_ends_in_break(last_else)) {
>>> +  break_blk = last_else;
>>> +  continue_from_blk = last_then;
>>> +   }
>>> +
>>> +   /* Continue if the if contained no jumps at all */
>> In prose, I like to use if-statement because I think it reads more
>> easily.  "Continue if the if-statement..."
>>
>>> +   if (!break_blk)
>>> +  return false;
>>> +
>>> +   /* If the continue from block is empty then return as there is
>>> nothing to
>>> +    * move.
>>> +    */
>>> +   nir_block *first_continue_from_blk = continue_from_then ?
>>> +  nir_if_first_then_block(nif) :
>>> +  nir_if_first_else_block(nif);
>>> +   if (is_block_empty(first_continue_from_blk))
>>> +  return false;
>>> +
>>> +   if (!nir_is_trivial_loop_if(nif, break_blk))
>>> +  return false;
>>> +
>>> +   /* Finally, move the continue from branch after the if. */
>>> +   nir_cf_list tmp;
>>> +   nir_cf_extract(&tmp, nir_before_block(first_continue_from_blk),
>>> +    nir_after_block(continue_from_blk));
>>> +   nir_cf_reinsert(&tmp, nir_after_cf_node(&nif->cf_node));
>>> +   nir_cf_delete(&tmp);
>>> +
>>> +   return true;
>>> +}
>>> +
>>>   static bool
>>>   opt_if_cf_list(nir_builder *b, struct exec_list *cf_list)
>>>   {
>>> @@ -296,6 +363,7 @@ opt_if_cf_list(nir_builder *b, struct exec_list
>>> *cf_list)
>>>    nir_if *nif = nir_cf_node_as_if(cf_node);
>>>    progress |= opt_if_cf_list(b, &nif->then_list);
>>>    progress |= opt_if_cf_list(b, &nif->else_list);
>>> + progress |= opt_if_loop_terminator(nif);
>>>    progress |= opt_if_simplification(b, nif);
>>>    break;
>>>     }
>>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: fix possible truncation on renderer string

[Timothy Arceri]

Fixes truncation warning in gcc 8.1

Fixes: 8539c9bf3158 ("gallium/radeon: add the kernel version into the renderer 
string")
---
 src/gallium/drivers/radeonsi/si_pipe.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index 5d1671fb87f..cf9b124fe5a 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -409,7 +409,7 @@ struct si_screen {
 
struct radeon_info  info;
uint64_tdebug_flags;
-   charrenderer_string[100];
+   charrenderer_string[183];
 
unsignedgs_table_depth;
unsignedtess_offchip_block_dw_size;
-- 
2.17.1

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

[Mesa-dev] [PATCH] anv: Set fence/semaphore types to NONE in impl_cleanup

[Jason Ekstrand]

There were some places that were calling anv_semaphore_impl_cleanup and
neither deleting the semaphore nor setting the type back to NONE.  Just
set it to NONE in impl_cleanup to avoid these issues.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106643
Fixes: 031f57eba "anv: Add a basic implementation of VK_KHX_external..."
---
 src/intel/vulkan/anv_queue.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index e8bdaf14f91..5272ff4a8e0 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -314,18 +314,21 @@ anv_fence_impl_cleanup(struct anv_device *device,
switch (impl->type) {
case ANV_FENCE_TYPE_NONE:
   /* Dummy.  Nothing to do */
-  return;
+  break;
 
case ANV_FENCE_TYPE_BO:
   anv_bo_pool_free(&device->batch_bo_pool, &impl->bo.bo);
-  return;
+  break;
 
case ANV_FENCE_TYPE_SYNCOBJ:
   anv_gem_syncobj_destroy(device, impl->syncobj);
-  return;
+  break;
+
+   default:
+  unreachable("Invalid fence type");
}
 
-   unreachable("Invalid fence type");
+   impl->type = ANV_FENCE_TYPE_NONE;
 }
 
 void anv_DestroyFence(
@@ -362,10 +365,8 @@ VkResult anv_ResetFences(
*first restored. The remaining operations described therefore
*operate on the restored payload.
*/
-  if (fence->temporary.type != ANV_FENCE_TYPE_NONE) {
+  if (fence->temporary.type != ANV_FENCE_TYPE_NONE)
  anv_fence_impl_cleanup(device, &fence->temporary);
- fence->temporary.type = ANV_FENCE_TYPE_NONE;
-  }
 
   struct anv_fence_impl *impl = &fence->permanent;
 
@@ -918,22 +919,25 @@ anv_semaphore_impl_cleanup(struct anv_device *device,
case ANV_SEMAPHORE_TYPE_NONE:
case ANV_SEMAPHORE_TYPE_DUMMY:
   /* Dummy.  Nothing to do */
-  return;
+  break;
 
case ANV_SEMAPHORE_TYPE_BO:
   anv_bo_cache_release(device, &device->bo_cache, impl->bo);
-  return;
+  break;
 
case ANV_SEMAPHORE_TYPE_SYNC_FILE:
   close(impl->fd);
-  return;
+  break;
 
case ANV_SEMAPHORE_TYPE_DRM_SYNCOBJ:
   anv_gem_syncobj_destroy(device, impl->syncobj);
-  return;
+  break;
+
+   default:
+  unreachable("Invalid semaphore type");
}
 
-   unreachable("Invalid semaphore type");
+   impl->type = ANV_SEMAPHORE_TYPE_NONE;
 }
 
 void
@@ -944,7 +948,6 @@ anv_semaphore_reset_temporary(struct anv_device *device,
   return;
 
anv_semaphore_impl_cleanup(device, &semaphore->temporary);
-   semaphore->temporary.type = ANV_SEMAPHORE_TYPE_NONE;
 }
 
 void anv_DestroySemaphore(
-- 
2.17.1

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

[Mesa-dev] [PATCH] features: add virgl to the GL features list

[Dave Airlie]

From: Dave Airlie 

This hopefully adds virgl to the correct places and current statuses
of various extensions.

virgl of course relies on two external things
a) host driver that can support the features
b) up to date host virglrenderer library that can support the features.

This list will be maintained as latest (a) + (b) + mesa.
---
 docs/features.txt | 80 +++
 1 file changed, 40 insertions(+), 40 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ed4050cf98a..6e5cbc8b11e 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -36,7 +36,7 @@ context as extensions.
 Feature Status
 --- 

 
-GL 3.0, GLSL 1.30 --- all DONE: freedreno, i965, nv50, nvc0, r600, radeonsi, 
llvmpipe, softpipe, swr
+GL 3.0, GLSL 1.30 --- all DONE: freedreno, i965, nv50, nvc0, r600, radeonsi, 
llvmpipe, softpipe, swr, virgl
 
   glBindFragDataLocation, glGetFragDataLocation DONE
   GL_NV_conditional_render (Conditional rendering)  DONE ()
@@ -68,7 +68,7 @@ GL 3.0, GLSL 1.30 --- all DONE: freedreno, i965, nv50, nvc0, 
r600, radeonsi, llv
 (*) freedreno, llvmpipe, softpipe, and swr have fake Multisample anti-aliasing 
support
 
 
-GL 3.1, GLSL 1.40 --- all DONE: freedreno, i965, nv50, nvc0, r600, radeonsi, 
llvmpipe, softpipe, swr
+GL 3.1, GLSL 1.40 --- all DONE: freedreno, i965, nv50, nvc0, r600, radeonsi, 
llvmpipe, softpipe, swr, virgl
 
   Forward compatible context support/deprecations   DONE ()
   GL_ARB_draw_instanced (Instanced drawing) DONE ()
@@ -81,7 +81,7 @@ GL 3.1, GLSL 1.40 --- all DONE: freedreno, i965, nv50, nvc0, 
r600, radeonsi, llv
   GL_EXT_texture_snorm (Signed normalized textures) DONE ()
 
 
-GL 3.2, GLSL 1.50 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, 
softpipe, swr
+GL 3.2, GLSL 1.50 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, 
softpipe, swr, virgl
 
   Core/compatibility profiles   DONE
   Geometry shaders  DONE ()
@@ -96,7 +96,7 @@ GL 3.2, GLSL 1.50 --- all DONE: i965, nv50, nvc0, r600, 
radeonsi, llvmpipe, soft
   GLX_ARB_create_context_profileDONE
 
 
-GL 3.3, GLSL 3.30 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, 
softpipe
+GL 3.3, GLSL 3.30 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, 
softpipe, virgl
 
   GL_ARB_blend_func_extendedDONE (freedreno/a3xx, 
swr)
   GL_ARB_explicit_attrib_location   DONE (all drivers that 
support GLSL)
@@ -112,9 +112,9 @@ GL 3.3, GLSL 3.30 --- all DONE: i965, nv50, nvc0, r600, 
radeonsi, llvmpipe, soft
 
 GL 4.0, GLSL 4.00 --- all DONE: i965/gen7+, nvc0, r600, radeonsi
 
-  GL_ARB_draw_buffers_blend DONE (freedreno, 
i965/gen6+, nv50, llvmpipe, softpipe, swr)
-  GL_ARB_draw_indirect  DONE (freedreno, 
i965/gen7+, llvmpipe, softpipe, swr)
-  GL_ARB_gpu_shader5DONE (i965/gen7+)
+  GL_ARB_draw_buffers_blend DONE (freedreno, 
i965/gen6+, nv50, llvmpipe, softpipe, swr, virgl)
+  GL_ARB_draw_indirect  DONE (freedreno, 
i965/gen7+, llvmpipe, softpipe, swr, virgl)
+  GL_ARB_gpu_shader5DONE (i965/gen7+, 
virgl)
   - 'precise' qualifier DONE
   - Dynamically uniform sampler array indices   DONE (softpipe)
   - Dynamically uniform UBO array indices   DONE ()
@@ -128,40 +128,40 @@ GL 4.0, GLSL 4.00 --- all DONE: i965/gen7+, nvc0, r600, 
radeonsi
   - Interpolation functions DONE ()
   - New overload resolution rules   DONE
   GL_ARB_gpu_shader_fp64DONE (i965/gen7+, 
llvmpipe, softpipe)
-  GL_ARB_sample_shading DONE (i965/gen6+, nv50)
-  GL_ARB_shader_subroutine  DONE (freedreno, 
i965/gen6+, nv50, llvmpipe, softpipe, swr)
+  GL_ARB_sample_shading DONE (i965/gen6+, 
nv50, virgl)
+  GL_ARB_shader_subroutine  DONE (freedreno, 
i965/gen6+, nv50, llvmpipe, softpipe, swr, virgl)
   GL_ARB_tessellation_shaderDONE (i965/gen7+)
-  GL_ARB_texture_buffer_object_rgb32DONE (freedreno, 
i965/gen6+, llvmpipe, softpipe, swr)
-  GL_ARB_texture_cube_map_array DONE (i965/gen6+, 
nv50, llvmpipe, softpipe)
-  GL_ARB_texture_gather DONE (freedreno, 
i965/gen6+, nv50, llvmpipe, softpipe, swr)
-  GL_ARB_texture_query_lod  DONE (freedreno, i965, 
nv50, llvmpipe, softpipe)
-  GL_ARB_transform_feedback2DONE (i965/ge

Re: [Mesa-dev] [PATCH 4/8] intel/compiler: More peephole select

[Ian Romanick]

On 06/06/2018 04:26 PM, Matt Turner wrote:
> On Wed, Jun 6, 2018 at 2:33 PM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> Shader-db results:
>>
>> Skylake and Broadwell had similar results. (Skylake shown)
>> total instructions in shared programs: 14371513 -> 14346174 (-0.18%)
>> instructions in affected programs: 890389 -> 865050 (-2.85%)
>> helped: 3601
>> HURT: 1
>> helped stats (abs) min: 1 max: 92 x̄: 7.05 x̃: 4
>> helped stats (rel) min: 0.10% max: 25.00% x̄: 3.95% x̃: 3.23%
>> HURT stats (abs)   min: 43 max: 43 x̄: 43.00 x̃: 43
>> HURT stats (rel)   min: 0.90% max: 0.90% x̄: 0.90% x̃: 0.90%
>> 95% mean confidence interval for instructions value: -7.27 -6.80
>> 95% mean confidence interval for instructions %-change: -4.05% -3.84%
>> Instructions are helped.
>>
>> total cycles in shared programs: 532435951 -> 532154282 (-0.05%)
>> cycles in affected programs: 69203137 -> 68921468 (-0.41%)
>> helped: 2654
>> HURT: 981
>> helped stats (abs) min: 1 max: 4496 x̄: 177.17 x̃: 76
>> helped stats (rel) min: <.01% max: 71.34% x̄: 9.16% x̃: 5.42%
>> HURT stats (abs)   min: 1 max: 8 x̄: 192.20 x̃: 19
>> HURT stats (rel)   min: <.01% max: 36.36% x̄: 2.95% x̃: 1.46%
>> 95% mean confidence interval for cycles value: -113.38 -41.60
>> 95% mean confidence interval for cycles %-change: -6.24% -5.53%
>> Cycles are helped.
>>
>> total spills in shared programs: 8114 -> 8122 (0.10%)
>> spills in affected programs: 152 -> 160 (5.26%)
>> helped: 0
>> HURT: 2
>>
>> total fills in shared programs: 11082 -> 11100 (0.16%)
>> fills in affected programs: 375 -> 393 (4.80%)
>> helped: 1
>> HURT: 1
>>
>> Haswell, Ivy Bridge, and Sandy Bridge had similar results. (Ivy Bridge shown)
>> total instructions in shared programs: 9897654 -> 9890341 (-0.07%)
>> instructions in affected programs: 213092 -> 205779 (-3.43%)
>> helped: 775
>> HURT: 18
>> helped stats (abs) min: 1 max: 65 x̄: 9.62 x̃: 6
>> helped stats (rel) min: 0.11% max: 25.00% x̄: 4.85% x̃: 3.70%
>> HURT stats (abs)   min: 2 max: 20 x̄: 7.89 x̃: 6
>> HURT stats (rel)   min: 0.70% max: 2.59% x̄: 1.63% x̃: 1.70%
>> 95% mean confidence interval for instructions value: -9.93 -8.51
>> 95% mean confidence interval for instructions %-change: -5.01% -4.40%
>> Instructions are helped.
>>
>> total cycles in shared programs: 87653348 -> 87562421 (-0.10%)
>> cycles in affected programs: 2411339 -> 2320412 (-3.77%)
>> helped: 612
>> HURT: 227
>> helped stats (abs) min: 1 max: 2103 x̄: 162.83 x̃: 53
>> helped stats (rel) min: 0.05% max: 58.41% x̄: 6.50% x̃: 2.65%
>> HURT stats (abs)   min: 1 max: 772 x̄: 38.43 x̃: 10
>> HURT stats (rel)   min: 0.04% max: 36.36% x̄: 3.60% x̃: 0.92%
>> 95% mean confidence interval for cycles value: -128.53 -88.22
>> 95% mean confidence interval for cycles %-change: -4.39% -3.14%
>> Cycles are helped.
>>
>> No change on Iron Lake or GM45.
>>
>> Signed-off-by: Ian Romanick 
>> ---
>>  src/intel/compiler/brw_nir.c | 14 ++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
>> index 67c062d91f5..ca9b021767f 100644
>> --- a/src/intel/compiler/brw_nir.c
>> +++ b/src/intel/compiler/brw_nir.c
>> @@ -557,7 +557,21 @@ brw_nir_optimize(nir_shader *nir, const struct 
>> brw_compiler *compiler,
>>OPT(nir_copy_prop);
>>OPT(nir_opt_dce);
>>OPT(nir_opt_cse);
>> +
>> +  /* Passing 0 to the peephole select pass causes it to convert
>> +   * if-statements that contain only move instructions in the branches
>> +   * regardless of the count.
>> +   *
>> +   * Passing 0 to the peephole select pass causes it to convert

 Passing 1

I thought I already fixed that. :(

>> +   * if-statements that contain at most a single ALU instruction (total)
>> +   * in both branches.  The select instruction works somewhat 
>> differently
>> +   * on Gen5 and earlier, and adding this pass on those platforms was
> 
> It does? Something about min/max requiring the CMP?

I remember thinking the problem was obvious when I looked at the first
shader that was hurt, but I don't recall exactly what it was now.  I'll
try it again.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] nir: add pass to move load_const

[Ian Romanick]

On 06/06/2018 04:47 PM, Rob Clark wrote:
> On Wed, Jun 6, 2018 at 6:51 PM, Ian Romanick  wrote:
>> On 06/06/2018 07:43 AM, Rob Clark wrote:
>>> Run this pass late (after opt loop) to move load_const instructions back
>>> into the basic blocks which use the result, in cases where a load_const
>>> is only consumed in a single block.
>>
>> If the load_const is used in more than one block, you could use it to
>> the block that dominates all of the block that contain a use.  I suspect
>> in many cases that will just be the first block, but it's probably worth
>> trying.
> 
> hmm, good point.. I was mostly going for the super-obvious wins with
> now downside cases (ie. low hanging fruit), but I guess the block that
> dominates all the uses isn't going to be worse than the first block..
> 
> I can play around w/ the common denominator case.. although in at
> least some cases I think it might be better to split the load_const.
> Idk, the low hanging fruit approach cuts register usage by 1/3rd in
> some of these edge case shaders, which by itself seems like a big
> enough win, but I guess nir_shader_compiler_options config params is
> an option for more aggressive approaches that may or may not be a win
> for different drivers.

True.  We could land this and incrementally improve it later.  If we
want to do that, I'd suggest

 - Put all of our ideas for improving the pass, including the one
   already documented in the code, to the file header comment.

 - Remove the suggestions for future work from the "if consumed in more
   than one block, ignore." comment.

>>> This helps reduce register usage in cases where the backend driver
>>> cannot lower the load_const to a uniform.
>>
>> The trade off is that now you might not be able to hide the latency of
>> the load.  I tried this on i965, and the results (below) support this
>> idea a bit.  If you have a structured backend IR, this seems like a
>> thing better done there... like, if you can't register allocate without
>> spilling, try moving the load.  But that's really just a scheduling
>> heuristic.  Hmm...
> 
> iirc, i965 had some clever load_const lower passes so all the threads
> in a warp could share the same load_const (iirc?  I might not have
> that description quite right)..  so I wasn't expecting this to be
> useful to i965 (but if it is, then, bonus!).  For me I can *almost*
> always lower load_const to uniform, so in the common cases it hasn't
> been a problem.  The exceptions are cases where an alu instruction
> consume >1 const (but those get optimized away) or a const plus
> uniform, or things like ssbo/image store.  (I noticed the register
> usage blowing up thing looking at some deqp tests like
> dEQP-GLES31.functional.ssbo.layout.2_level_array.shared.vec4 ;-))

There are some optimizations for loading constants in the vec4 backend.
There is some code to lower arrays of constants to uniforms.  Uniforms
are already shared within the SIMD group.  I don't know of anything
other than that, but that's doesn't mean such a thing doesn't exist.

Also... at what point do you call this pass?  Here's what I did for
i965... basically called it as late as I thought was possible:

diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index dfeea73b06a..2209d6142b3 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -795,6 +795,8 @@ brw_postprocess_nir(nir_shader *nir, const struct
brw_compiler *compiler,
if (devinfo->gen <= 5)
   brw_nir_analyze_boolean_resolves(nir);

+   nir_move_load_const(nir);
+
nir_sweep(nir);

if (unlikely(debug_enabled)) {

Now that the full shader-db run is done, it seems to have some odd
effects on vec4 shaders, so I'll probably tweak this a bit.

> If latency of the load is an issue, perhaps a configuration option
> about the minimum size of destination use_block, with the rough theory
> that if the block is bigger than some threshold the instruction
> scheduling could probably hide the latency?

I thought about this a bit more... I think the driver's scheduler should
fix this case.  If it can't hide the latency of a load immediate, the
scheduler should move it to the earlier block.  That might even help
hide the latency of a compare.  Something like

cmp.g.f0(16)nullg2<8,8,1>F  -g9.4<0,1,0>F
(+f0) if(16)JIP: 40 UIP: 40
   END B0 ->B1 ->B2
   START B1 <-B0 (40 cycles)
mov(16) g77<1>F 1F

should become

cmp.g.f0(16)nullg2<8,8,1>F  -g9.4<0,1,0>F
mov(16) g77<1>F 1F
(+f0) if(16)JIP: 40 UIP: 40
   END B0 ->B1 ->B2
   START B1 <-B0 (40 cycles)

> BR,
> -R
> 
> 
>> total instructions in shared programs: 14398410 -> 14397918 (<.01%)
>> instructions in affected programs: 134856 -> 134364 (-0.36%)
>> helped: 53
>> HURT: 10
>> helped stats (abs) min: 1 max: 30 x̄: 9.47 x̃: 7
>> helped stats (rel) min: 0.16% max: 2.74% x̄: 0.64% x̃: 0.40%
>> HURT stats (abs)   min: 1 max: 1 x̄: 1.00 x̃: 1
>> 

[Mesa-dev] [PATCH] ac: fix possible truncation of intrinsic name

[Timothy Arceri]

Fixes the gcc warning:
snprintf’ output between 26 and 33 bytes into a destination of size 32

Fixes: d5f7ebda3ec0 ("ac: add LLVM build functions for subgroup instrinsics")
---
 src/amd/common/ac_llvm_build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index a686b72287b..681b4fcbcb9 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -2980,7 +2980,7 @@ static LLVMValueRef
 ac_build_set_inactive(struct ac_llvm_context *ctx, LLVMValueRef src,
  LLVMValueRef inactive)
 {
-   char name[32], type[8];
+   char name[33], type[8];
LLVMTypeRef src_type = LLVMTypeOf(src);
src = ac_to_integer(ctx, src);
inactive = ac_to_integer(ctx, inactive);
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH v2 11/15] docs: Toctree for systems.rst as in jhertel docs.

[Laura Ekstrand]

So actually, Nanley Chery noticed that this puts the xlib driver in the
menu under "Deprecated systems."  Xlib driver is in active development!

Since xlib was not in the navigation menu on the old website, let's just
delete this patch.

nack'd by Laura Ekstrand (la...@jlekstrand.net)

On Wed, May 30, 2018 at 3:53 PM, Laura Ekstrand 
wrote:

> Toctree directives create automatically generated navigation sidebars.
> This is the new deprecated systems sidebar.
> ---
>  docs/systems.rst | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/docs/systems.rst b/docs/systems.rst
> index 707abeeed9..b05aff0621 100644
> --- a/docs/systems.rst
> +++ b/docs/systems.rst
> @@ -52,3 +52,9 @@ the git repo. The list includes:
>  -  DOS
>  -  fbdev
>  -  DEC/VMS
> +
> +.. toctree::
> +   :maxdepth:  1
> +   :hidden:
> +
> +   xlibdriver
> --
> 2.14.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: fix Coverity no effect control flow issue

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Thu, Jun 7, 2018 at 1:49 AM, Timothy Arceri  wrote:
> swizzle is unsigned so "desc->swizzle[c] < 0" is never true.
> ---
>  src/amd/vulkan/radv_formats.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
> index 50ec904d514..958f2a2c821 100644
> --- a/src/amd/vulkan/radv_formats.c
> +++ b/src/amd/vulkan/radv_formats.c
> @@ -921,7 +921,7 @@ bool radv_format_pack_clear_color(VkFormat format,
> uint64_t clear_val = 0;
>
> for (unsigned c = 0; c < 4; ++c) {
> -   if (desc->swizzle[c] < 0 || desc->swizzle[c] >= 4)
> +   if (desc->swizzle[c] >= 4)
> continue;
>
> const struct vk_format_channel_description *channel = 
> &desc->channel[desc->swizzle[c]];
> --
> 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] [PATCH] radv: fix Coverity no effect control flow issue

[Timothy Arceri]

swizzle is unsigned so "desc->swizzle[c] < 0" is never true.
---
 src/amd/vulkan/radv_formats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index 50ec904d514..958f2a2c821 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -921,7 +921,7 @@ bool radv_format_pack_clear_color(VkFormat format,
uint64_t clear_val = 0;
 
for (unsigned c = 0; c < 4; ++c) {
-   if (desc->swizzle[c] < 0 || desc->swizzle[c] >= 4)
+   if (desc->swizzle[c] >= 4)
continue;
 
const struct vk_format_channel_description *channel = 
&desc->channel[desc->swizzle[c]];
-- 
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] nir: add pass to move load_const

[Rob Clark]

On Wed, Jun 6, 2018 at 6:51 PM, Ian Romanick  wrote:
> On 06/06/2018 07:43 AM, Rob Clark wrote:
>> Run this pass late (after opt loop) to move load_const instructions back
>> into the basic blocks which use the result, in cases where a load_const
>> is only consumed in a single block.
>
> If the load_const is used in more than one block, you could use it to
> the block that dominates all of the block that contain a use.  I suspect
> in many cases that will just be the first block, but it's probably worth
> trying.

hmm, good point.. I was mostly going for the super-obvious wins with
now downside cases (ie. low hanging fruit), but I guess the block that
dominates all the uses isn't going to be worse than the first block..

I can play around w/ the common denominator case.. although in at
least some cases I think it might be better to split the load_const.
Idk, the low hanging fruit approach cuts register usage by 1/3rd in
some of these edge case shaders, which by itself seems like a big
enough win, but I guess nir_shader_compiler_options config params is
an option for more aggressive approaches that may or may not be a win
for different drivers.

>
>> This helps reduce register usage in cases where the backend driver
>> cannot lower the load_const to a uniform.
>
> The trade off is that now you might not be able to hide the latency of
> the load.  I tried this on i965, and the results (below) support this
> idea a bit.  If you have a structured backend IR, this seems like a
> thing better done there... like, if you can't register allocate without
> spilling, try moving the load.  But that's really just a scheduling
> heuristic.  Hmm...
>

iirc, i965 had some clever load_const lower passes so all the threads
in a warp could share the same load_const (iirc?  I might not have
that description quite right)..  so I wasn't expecting this to be
useful to i965 (but if it is, then, bonus!).  For me I can *almost*
always lower load_const to uniform, so in the common cases it hasn't
been a problem.  The exceptions are cases where an alu instruction
consume >1 const (but those get optimized away) or a const plus
uniform, or things like ssbo/image store.  (I noticed the register
usage blowing up thing looking at some deqp tests like
dEQP-GLES31.functional.ssbo.layout.2_level_array.shared.vec4 ;-))

If latency of the load is an issue, perhaps a configuration option
about the minimum size of destination use_block, with the rough theory
that if the block is bigger than some threshold the instruction
scheduling could probably hide the latency?

BR,
-R


> total instructions in shared programs: 14398410 -> 14397918 (<.01%)
> instructions in affected programs: 134856 -> 134364 (-0.36%)
> helped: 53
> HURT: 10
> helped stats (abs) min: 1 max: 30 x̄: 9.47 x̃: 7
> helped stats (rel) min: 0.16% max: 2.74% x̄: 0.64% x̃: 0.40%
> HURT stats (abs)   min: 1 max: 1 x̄: 1.00 x̃: 1
> HURT stats (rel)   min: 0.03% max: 0.21% x̄: 0.05% x̃: 0.03%
> 95% mean confidence interval for instructions value: -9.61 -6.01
> 95% mean confidence interval for instructions %-change: -0.68% -0.38%
> Instructions are helped.
>
> total cycles in shared programs: 532949823 -> 532851352 (-0.02%)
> cycles in affected programs: 260693023 -> 260594552 (-0.04%)
> helped: 122
> HURT: 88
> helped stats (abs) min: 1 max: 24933 x̄: 1080.30 x̃: 20
> helped stats (rel) min: <.01% max: 34.94% x̄: 2.20% x̃: 0.32%
> HURT stats (abs)   min: 1 max: 1884 x̄: 378.69 x̃: 29
> HURT stats (rel)   min: <.01% max: 10.23% x̄: 0.64% x̃: 0.09%
> 95% mean confidence interval for cycles value: -943.71 5.89
> 95% mean confidence interval for cycles %-change: -1.71% -0.32%
> Inconclusive result (value mean confidence interval includes 0).
>
> total spills in shared programs: 8044 -> 7975 (-0.86%)
> spills in affected programs: 2391 -> 2322 (-2.89%)
> helped: 42
> HURT: 0
>
> total fills in shared programs: 10950 -> 10884 (-0.60%)
> fills in affected programs: 2999 -> 2933 (-2.20%)
> helped: 42
> HURT: 0
>
> LOST:   4
> GAINED: 7
>
>> Signed-off-by: Rob Clark 
>> ---
>>  src/compiler/Makefile.sources  |   1 +
>>  src/compiler/nir/meson.build   |   1 +
>>  src/compiler/nir/nir.h |   1 +
>>  src/compiler/nir/nir_move_load_const.c | 131 +
>>  4 files changed, 134 insertions(+)
>>  create mode 100644 src/compiler/nir/nir_move_load_const.c
>>
>> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
>> index 3daa2c51334..cb8a2875a84 100644
>> --- a/src/compiler/Makefile.sources
>> +++ b/src/compiler/Makefile.sources
>> @@ -253,6 +253,7 @@ NIR_FILES = \
>>   nir/nir_lower_wpos_center.c \
>>   nir/nir_lower_wpos_ytransform.c \
>>   nir/nir_metadata.c \
>> + nir/nir_move_load_const.c \
>>   nir/nir_move_vec_src_uses_to_dest.c \
>>   nir/nir_normalize_cubemap_coords.c \
>>   nir/nir_opt_conditional_discard.c \
>> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
>> index 3

[Mesa-dev] [Bug 106774] GLSL IR copy propagates loads of SSBOs

[bugzilla-daemon]

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

--- Comment #12 from almos  ---
(In reply to Michel Dänzer from comment #10)
> Please don't add piglit tests which are expected to hang the GPU, or at
> least don't set them up to be run by default. Not all drivers can reliably
> recover from GPU hangs.

IMHO those drivers should be fixed.

-- 
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 4/8] intel/compiler: More peephole select

[Matt Turner]

On Wed, Jun 6, 2018 at 2:33 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> Shader-db results:
>
> Skylake and Broadwell had similar results. (Skylake shown)
> total instructions in shared programs: 14371513 -> 14346174 (-0.18%)
> instructions in affected programs: 890389 -> 865050 (-2.85%)
> helped: 3601
> HURT: 1
> helped stats (abs) min: 1 max: 92 x̄: 7.05 x̃: 4
> helped stats (rel) min: 0.10% max: 25.00% x̄: 3.95% x̃: 3.23%
> HURT stats (abs)   min: 43 max: 43 x̄: 43.00 x̃: 43
> HURT stats (rel)   min: 0.90% max: 0.90% x̄: 0.90% x̃: 0.90%
> 95% mean confidence interval for instructions value: -7.27 -6.80
> 95% mean confidence interval for instructions %-change: -4.05% -3.84%
> Instructions are helped.
>
> total cycles in shared programs: 532435951 -> 532154282 (-0.05%)
> cycles in affected programs: 69203137 -> 68921468 (-0.41%)
> helped: 2654
> HURT: 981
> helped stats (abs) min: 1 max: 4496 x̄: 177.17 x̃: 76
> helped stats (rel) min: <.01% max: 71.34% x̄: 9.16% x̃: 5.42%
> HURT stats (abs)   min: 1 max: 8 x̄: 192.20 x̃: 19
> HURT stats (rel)   min: <.01% max: 36.36% x̄: 2.95% x̃: 1.46%
> 95% mean confidence interval for cycles value: -113.38 -41.60
> 95% mean confidence interval for cycles %-change: -6.24% -5.53%
> Cycles are helped.
>
> total spills in shared programs: 8114 -> 8122 (0.10%)
> spills in affected programs: 152 -> 160 (5.26%)
> helped: 0
> HURT: 2
>
> total fills in shared programs: 11082 -> 11100 (0.16%)
> fills in affected programs: 375 -> 393 (4.80%)
> helped: 1
> HURT: 1
>
> Haswell, Ivy Bridge, and Sandy Bridge had similar results. (Ivy Bridge shown)
> total instructions in shared programs: 9897654 -> 9890341 (-0.07%)
> instructions in affected programs: 213092 -> 205779 (-3.43%)
> helped: 775
> HURT: 18
> helped stats (abs) min: 1 max: 65 x̄: 9.62 x̃: 6
> helped stats (rel) min: 0.11% max: 25.00% x̄: 4.85% x̃: 3.70%
> HURT stats (abs)   min: 2 max: 20 x̄: 7.89 x̃: 6
> HURT stats (rel)   min: 0.70% max: 2.59% x̄: 1.63% x̃: 1.70%
> 95% mean confidence interval for instructions value: -9.93 -8.51
> 95% mean confidence interval for instructions %-change: -5.01% -4.40%
> Instructions are helped.
>
> total cycles in shared programs: 87653348 -> 87562421 (-0.10%)
> cycles in affected programs: 2411339 -> 2320412 (-3.77%)
> helped: 612
> HURT: 227
> helped stats (abs) min: 1 max: 2103 x̄: 162.83 x̃: 53
> helped stats (rel) min: 0.05% max: 58.41% x̄: 6.50% x̃: 2.65%
> HURT stats (abs)   min: 1 max: 772 x̄: 38.43 x̃: 10
> HURT stats (rel)   min: 0.04% max: 36.36% x̄: 3.60% x̃: 0.92%
> 95% mean confidence interval for cycles value: -128.53 -88.22
> 95% mean confidence interval for cycles %-change: -4.39% -3.14%
> Cycles are helped.
>
> No change on Iron Lake or GM45.
>
> Signed-off-by: Ian Romanick 
> ---
>  src/intel/compiler/brw_nir.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index 67c062d91f5..ca9b021767f 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -557,7 +557,21 @@ brw_nir_optimize(nir_shader *nir, const struct 
> brw_compiler *compiler,
>OPT(nir_copy_prop);
>OPT(nir_opt_dce);
>OPT(nir_opt_cse);
> +
> +  /* Passing 0 to the peephole select pass causes it to convert
> +   * if-statements that contain only move instructions in the branches
> +   * regardless of the count.
> +   *
> +   * Passing 0 to the peephole select pass causes it to convert
> +   * if-statements that contain at most a single ALU instruction (total)
> +   * in both branches.  The select instruction works somewhat differently
> +   * on Gen5 and earlier, and adding this pass on those platforms was

It does? Something about min/max requiring the CMP?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/6] Fix Various Compilation Issues With Bindless

[Rhys Perry]

Oops, I meant r-values, not l-values.
Seems to meaning of the word in my head changed at some point.

On Wed, Jun 6, 2018 at 8:55 PM, Rhys Perry  wrote:
> Previously, there were some errors in the compiler's implementation of
> ARB_bindless_texture, mostly related to usage of bound image or sampler
> handles allowed by ARB_bindless_texture, resulting in assertions or
> compilation errors. This series fixes following issues found in mesa:
> - Assertions when casting bound handles to uvec2
> - Compilation errors when using the ?: operator with bound handles
> - Assertions creating a constant image/sampler handle
>- For example: image2D(uvec2(5, 6))
> - Inlining of function calls with rvalues other than dereferences to
>   handle uniforms passed into them creates assertion failures
> - Usage of bound handles as l-values
>
> In order to create bindless handles from bound images or samplers, two new
> TGSI opcodes needed to be added: SAMP2HND and IMG2HND. These are used when
> casting bound handles or when using them as l-values (e.g. using them with
> the ?: operator).
>
> This series has the following limitations because I don't have the
> hardware needed to test the needed changes:
> - radeonsi and gallivm do not handle SAMP2HND and IMG2HND
> - similar instructions/intrinsics for nir have not been added
> - the tgsi to nir conversion code does not handle SAMP2HND and IMG2HND
> - IMG2HND with Kepler is not implemented
> Usage of bound handles as l-values and casting them is handled better than
> before though.
>
> Some tests for these changes have been posted on the piglit mailing list.
>
> Rhys Perry (6):
>   gallium: add new SAMP2HND and IMG2HND opcodes
>   nv50/ir: add support for SAMP2HND on gk104+ and IMG2HND on gm107+
>   glsl_to_tgsi: allow bound samplers and images to be used as l-values
>   glsl: allow ?: operator with images and samplers when bindless is enabled
>   glsl,glsl_to_tgsi: fix sampler/image constants
>   glsl: fix function inlining with opaque parameters
>
>  src/compiler/glsl/ast_to_hir.cpp   |  8 ++-
>  src/compiler/glsl/ir.cpp   | 32 +-
>  src/compiler/glsl/opt_function_inlining.cpp| 52 +---
>  src/gallium/auxiliary/tgsi/tgsi_info.c |  2 +
>  src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h |  4 +-
>  src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h   |  3 +
>  src/gallium/docs/source/tgsi.rst   | 25 
>  src/gallium/drivers/nouveau/codegen/nv50_ir.cpp|  2 +
>  src/gallium/drivers/nouveau/codegen/nv50_ir.h  |  2 +
>  .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  | 22 +++
>  .../drivers/nouveau/codegen/nv50_ir_inlines.h  |  4 +-
>  .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp  | 25 
>  .../nouveau/codegen/nv50_ir_lowering_nvc0.h|  1 +
>  .../drivers/nouveau/codegen/nv50_ir_print.cpp  |  2 +
>  .../drivers/nouveau/codegen/nv50_ir_target.cpp |  7 ++-
>  src/gallium/include/pipe/p_shader_tokens.h |  2 +
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 69 
> --
>  src/mesa/state_tracker/st_glsl_to_tgsi_private.h   |  1 +
>  18 files changed, 239 insertions(+), 24 deletions(-)
>
> --
> 2.14.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] dri: add missing 16bits formats mapping

[Lionel Landwerlin]

Thanks, pushed with your comment added.

-
Lionel

On 06/06/18 23:17, Jason Ekstrand wrote:
It might be good to add some additional commentary in the commit 
message such as:


i965 advertises the 16-bit R and RG formats through 
eglQueryDmaBufFormatsEXT but falls over when a client tries to use or 
asks more information about such a format because 
driImageFormatToGLFormat returns MESA_FORMAT_NONE.


Reviewed-by: Jason Ekstrand >


Let's use this instead of patch 5/7 from the series I sent earlier.  
I'm still not sure I believe Daniel but advertising them shouldn't hurt.


On Wed, Jun 6, 2018 at 10:36 AM, Lionel Landwerlin 
mailto:lionel.g.landwer...@intel.com>> 
wrote:


Found by Eero.

v2: Add G16R16 formats (Lionel)

v3: Fix G16R16 mapping to mesa format (Jason)

Signed-off-by: Lionel Landwerlin mailto:lionel.g.landwer...@intel.com>>
Reviewed-by: Plamena Manolova mailto:plamena.manol...@intel.com>> (v2)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106642

---
 src/mesa/drivers/dri/common/dri_util.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index a591dfcd7d2..d257cb644c8 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -936,6 +936,22 @@ static const struct {
       .image_format = __DRI_IMAGE_FORMAT_SARGB8,
       .mesa_format  =        MESA_FORMAT_B8G8R8A8_SRGB,
    },
+   {
+      .image_format = __DRI_IMAGE_FORMAT_R16,
+      .mesa_format  =        MESA_FORMAT_R_UNORM16,
+   },
+   {
+      .image_format = __DRI_IMAGE_FORMAT_R16,
+      .mesa_format  =        MESA_FORMAT_L_UNORM16,
+   },
+   {
+      .image_format = __DRI_IMAGE_FORMAT_GR1616,
+      .mesa_format  = MESA_FORMAT_R16G16_UNORM,
+   },
+   {
+      .image_format = __DRI_IMAGE_FORMAT_GR1616,
+      .mesa_format  =        MESA_FORMAT_L16A16_UNORM,
+   },
 };

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

Re: [Mesa-dev] [PATCH 2/6] nv50/ir: add support for SAMP2HND on gk104+ and IMG2HND on gm107+

[Ilia Mirkin]

On Wed, Jun 6, 2018 at 3:55 PM, Rhys Perry  wrote:
> Signed-off-by: Rhys Perry 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir.cpp|  2 ++
>  src/gallium/drivers/nouveau/codegen/nv50_ir.h  |  2 ++
>  .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  | 22 +++
>  .../drivers/nouveau/codegen/nv50_ir_inlines.h  |  4 ++--
>  .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp  | 25 
> ++
>  .../nouveau/codegen/nv50_ir_lowering_nvc0.h|  1 +
>  .../drivers/nouveau/codegen/nv50_ir_print.cpp  |  2 ++
>  .../drivers/nouveau/codegen/nv50_ir_target.cpp |  7 +++---
>  8 files changed, 60 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> index c987da9908..7c1c76a912 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> @@ -903,6 +903,8 @@ TexInstruction::TexInstruction(Function *fn, operation op)
>
> if (op == OP_TXF)
>sType = TYPE_U32;
> +   if (op == OP_SAMP2HND || op == OP_IMG2HND)
> +  setType(TYPE_U32);
>  }
>
>  TexInstruction::~TexInstruction()
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> index f4f3c70888..97aa8d1109 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> @@ -134,6 +134,8 @@ enum operation
> OP_SUCLAMP, // clamp surface coordinates
> OP_SUEAU,   // surface effective address
> OP_SUQ, // surface query
> +   OP_SAMP2HND, // convert bound texture to bindless handle
> +   OP_IMG2HND, // convert bound image to bindless handle
> OP_MADSP,   // special integer multiply-add
> OP_TEXBAR, // texture dependency barrier
> OP_DFDX,
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> index 3c5bad05fe..8149c72dd1 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
> @@ -3570,6 +3570,28 @@ Converter::handleInstruction(const struct 
> tgsi_full_instruction *insn)
>handleTXQ(dst0, TXQ_TYPE, 0);
>std::swap(dst0[0], dst0[2]);
>break;
> +   case TGSI_OPCODE_IMG2HND:
> +   case TGSI_OPCODE_SAMP2HND:
> +  if (!tgsi.getDst(0).isMasked(1))
> + mkOp1(OP_MOV, TYPE_U32, dst0[1], mkImm(0));

Not that it really matters, but I think I set the low bit of the high
word when generating these.

> +
> +  if (!tgsi.getDst(0).isMasked(0)) {
> + bool is_image = tgsi.getOpcode() == TGSI_OPCODE_IMG2HND;
> +
> + TexInstruction *texi = new_TexInstruction(
> +func, is_image ? OP_IMG2HND : OP_SAMP2HND);
> + texi->setDef(0, dst0[0]);
> + if (is_image)
> +texi->tex.target = tgsi.getImageTarget();
> + else
> +texi->tex.target = tgsi.getTexture(code, 0);
> + texi->tex.r = tgsi.getSrc(0).getIndex(0);
> + if (tgsi.getSrc(0).isIndirect(0))
> +texi->setIndirectR(fetchSrc(tgsi.getSrc(0).getIndirect(0), 0, 
> NULL));

texi->tex.mask = 1

> +
> + bb->insertTail(texi);
> +  }
> +  break;
> case TGSI_OPCODE_FBFETCH:
>handleFBFETCH(dst0);
>break;
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h
> index 4cb53ab42e..0262ae9d1f 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h
> @@ -311,14 +311,14 @@ const FlowInstruction *Instruction::asFlow() const
>
>  TexInstruction *Instruction::asTex()
>  {
> -   if ((op >= OP_TEX && op <= OP_SULEA) || op == OP_SUQ)
> +   if ((op >= OP_TEX && op <= OP_SULEA) || (op >= OP_SUQ && op <= 
> OP_IMG2HND))
>return static_cast(this);
> return NULL;
>  }
>
>  const TexInstruction *Instruction::asTex() const
>  {
> -   if ((op >= OP_TEX && op <= OP_SULEA) || op == OP_SUQ)
> +   if ((op >= OP_TEX && op <= OP_SULEA) || (op >= OP_SUQ && op <= 
> OP_IMG2HND))
>return static_cast(this);
> return NULL;
>  }
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index 29f674b451..c2cc120147 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -1347,6 +1347,27 @@ NVC0LoweringPass::handleBUFQ(Instruction *bufq)
> return true;
>  }
>
> +bool
> +NVC0LoweringPass::handle2HND(TexInstruction *i)
> +{
> +   assert(targ->getChipset() >= NVISA_GK104_CHIPSET);
> +   assert(!i->tex.bindless);
> +   bool is_sampler = i->op == OP_SAMP2HND;
> +
> +   if (is_sampler || targ->getChipset() >= NVISA_GM107_CHIPSET) {
> +  //Sampler 

Re: [Mesa-dev] [PATCH 1/2] nir: add pass to move load_const

[Ian Romanick]

On 06/06/2018 03:51 PM, Ian Romanick wrote:
> On 06/06/2018 07:43 AM, Rob Clark wrote:
>> Run this pass late (after opt loop) to move load_const instructions back
>> into the basic blocks which use the result, in cases where a load_const
>> is only consumed in a single block.
> 
> If the load_const is used in more than one block, you could use it to
> the block that dominates all of the block that contain a use.  I suspect
> in many cases that will just be the first block, but it's probably worth
> trying.
> 
>> This helps reduce register usage in cases where the backend driver
>> cannot lower the load_const to a uniform.
> 
> The trade off is that now you might not be able to hide the latency of
> the load.  I tried this on i965, and the results (below) support this
> idea a bit.  If you have a structured backend IR, this seems like a
> thing better done there... like, if you can't register allocate without
> spilling, try moving the load.  But that's really just a scheduling
> heuristic.  Hmm...
> 
> total instructions in shared programs: 14398410 -> 14397918 (<.01%)
> instructions in affected programs: 134856 -> 134364 (-0.36%)
> helped: 53
> HURT: 10
> helped stats (abs) min: 1 max: 30 x̄: 9.47 x̃: 7
> helped stats (rel) min: 0.16% max: 2.74% x̄: 0.64% x̃: 0.40%
> HURT stats (abs)   min: 1 max: 1 x̄: 1.00 x̃: 1
> HURT stats (rel)   min: 0.03% max: 0.21% x̄: 0.05% x̃: 0.03%
> 95% mean confidence interval for instructions value: -9.61 -6.01
> 95% mean confidence interval for instructions %-change: -0.68% -0.38%
> Instructions are helped.
> 
> total cycles in shared programs: 532949823 -> 532851352 (-0.02%)
> cycles in affected programs: 260693023 -> 260594552 (-0.04%)
> helped: 122
> HURT: 88
> helped stats (abs) min: 1 max: 24933 x̄: 1080.30 x̃: 20
> helped stats (rel) min: <.01% max: 34.94% x̄: 2.20% x̃: 0.32%
> HURT stats (abs)   min: 1 max: 1884 x̄: 378.69 x̃: 29
> HURT stats (rel)   min: <.01% max: 10.23% x̄: 0.64% x̃: 0.09%
> 95% mean confidence interval for cycles value: -943.71 5.89
> 95% mean confidence interval for cycles %-change: -1.71% -0.32%
> Inconclusive result (value mean confidence interval includes 0).
> 
> total spills in shared programs: 8044 -> 7975 (-0.86%)
> spills in affected programs: 2391 -> 2322 (-2.89%)
> helped: 42
> HURT: 0
> 
> total fills in shared programs: 10950 -> 10884 (-0.60%)
> fills in affected programs: 2999 -> 2933 (-2.20%)
> helped: 42
> HURT: 0
> 
> LOST:   4
> GAINED: 7

This lost result is *really* misleading.  The 4 lost shaders are compute
shaders that went from SIMD8 to SIMD16.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] nir: add pass to move load_const

[Ian Romanick]

On 06/06/2018 07:43 AM, Rob Clark wrote:
> Run this pass late (after opt loop) to move load_const instructions back
> into the basic blocks which use the result, in cases where a load_const
> is only consumed in a single block.

If the load_const is used in more than one block, you could use it to
the block that dominates all of the block that contain a use.  I suspect
in many cases that will just be the first block, but it's probably worth
trying.

> This helps reduce register usage in cases where the backend driver
> cannot lower the load_const to a uniform.

The trade off is that now you might not be able to hide the latency of
the load.  I tried this on i965, and the results (below) support this
idea a bit.  If you have a structured backend IR, this seems like a
thing better done there... like, if you can't register allocate without
spilling, try moving the load.  But that's really just a scheduling
heuristic.  Hmm...

total instructions in shared programs: 14398410 -> 14397918 (<.01%)
instructions in affected programs: 134856 -> 134364 (-0.36%)
helped: 53
HURT: 10
helped stats (abs) min: 1 max: 30 x̄: 9.47 x̃: 7
helped stats (rel) min: 0.16% max: 2.74% x̄: 0.64% x̃: 0.40%
HURT stats (abs)   min: 1 max: 1 x̄: 1.00 x̃: 1
HURT stats (rel)   min: 0.03% max: 0.21% x̄: 0.05% x̃: 0.03%
95% mean confidence interval for instructions value: -9.61 -6.01
95% mean confidence interval for instructions %-change: -0.68% -0.38%
Instructions are helped.

total cycles in shared programs: 532949823 -> 532851352 (-0.02%)
cycles in affected programs: 260693023 -> 260594552 (-0.04%)
helped: 122
HURT: 88
helped stats (abs) min: 1 max: 24933 x̄: 1080.30 x̃: 20
helped stats (rel) min: <.01% max: 34.94% x̄: 2.20% x̃: 0.32%
HURT stats (abs)   min: 1 max: 1884 x̄: 378.69 x̃: 29
HURT stats (rel)   min: <.01% max: 10.23% x̄: 0.64% x̃: 0.09%
95% mean confidence interval for cycles value: -943.71 5.89
95% mean confidence interval for cycles %-change: -1.71% -0.32%
Inconclusive result (value mean confidence interval includes 0).

total spills in shared programs: 8044 -> 7975 (-0.86%)
spills in affected programs: 2391 -> 2322 (-2.89%)
helped: 42
HURT: 0

total fills in shared programs: 10950 -> 10884 (-0.60%)
fills in affected programs: 2999 -> 2933 (-2.20%)
helped: 42
HURT: 0

LOST:   4
GAINED: 7

> Signed-off-by: Rob Clark 
> ---
>  src/compiler/Makefile.sources  |   1 +
>  src/compiler/nir/meson.build   |   1 +
>  src/compiler/nir/nir.h |   1 +
>  src/compiler/nir/nir_move_load_const.c | 131 +
>  4 files changed, 134 insertions(+)
>  create mode 100644 src/compiler/nir/nir_move_load_const.c
> 
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index 3daa2c51334..cb8a2875a84 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -253,6 +253,7 @@ NIR_FILES = \
>   nir/nir_lower_wpos_center.c \
>   nir/nir_lower_wpos_ytransform.c \
>   nir/nir_metadata.c \
> + nir/nir_move_load_const.c \
>   nir/nir_move_vec_src_uses_to_dest.c \
>   nir/nir_normalize_cubemap_coords.c \
>   nir/nir_opt_conditional_discard.c \
> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> index 3fec363691d..373a47fd155 100644
> --- a/src/compiler/nir/meson.build
> +++ b/src/compiler/nir/meson.build
> @@ -144,6 +144,7 @@ files_libnir = files(
>'nir_lower_wpos_ytransform.c',
>'nir_lower_bit_size.c',
>'nir_metadata.c',
> +  'nir_move_load_const.c',
>'nir_move_vec_src_uses_to_dest.c',
>'nir_normalize_cubemap_coords.c',
>'nir_opt_conditional_discard.c',
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 5a1f79515ad..073ab4e82ea 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2612,6 +2612,7 @@ bool nir_remove_dead_variables(nir_shader *shader, 
> nir_variable_mode modes);
>  bool nir_lower_constant_initializers(nir_shader *shader,
>   nir_variable_mode modes);
>  
> +bool nir_move_load_const(nir_shader *shader);
>  bool nir_move_vec_src_uses_to_dest(nir_shader *shader);
>  bool nir_lower_vec_to_movs(nir_shader *shader);
>  void nir_lower_alpha_test(nir_shader *shader, enum compare_func func,
> diff --git a/src/compiler/nir/nir_move_load_const.c 
> b/src/compiler/nir/nir_move_load_const.c
> new file mode 100644
> index 000..c0750035fbb
> --- /dev/null
> +++ b/src/compiler/nir/nir_move_load_const.c
> @@ -0,0 +1,131 @@
> +/*
> + * Copyright © 2018 Red Hat
> + *
> + * 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 t

Re: [Mesa-dev] [PATCH 1/6] gallium: add new SAMP2HND and IMG2HND opcodes

[Ilia Mirkin]

On Wed, Jun 6, 2018 at 3:55 PM, Rhys Perry  wrote:
> This commit does not add support for the opcodes in gallivm or tgsi_to_nir.c
>
> Signed-off-by: Rhys Perry 
> ---
>  src/gallium/auxiliary/tgsi/tgsi_info.c |  2 ++
>  src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h |  4 ++--
>  src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h   |  3 +++
>  src/gallium/docs/source/tgsi.rst   | 25 +
>  src/gallium/include/pipe/p_shader_tokens.h |  2 ++
>  5 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c 
> b/src/gallium/auxiliary/tgsi/tgsi_info.c
> index 4aa658785c..bbe1a21e43 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_info.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
> @@ -153,6 +153,8 @@ tgsi_opcode_infer_type(enum tgsi_opcode opcode)
> case TGSI_OPCODE_POPC:
> case TGSI_OPCODE_LSB:
> case TGSI_OPCODE_UMSB:
> +   case TGSI_OPCODE_IMG2HND:
> +   case TGSI_OPCODE_SAMP2HND:
>return TGSI_TYPE_UNSIGNED;
> case TGSI_OPCODE_ARL:
> case TGSI_OPCODE_ARR:
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h 
> b/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h
> index 1b2803cf3f..c3787c2fbb 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h
> @@ -162,8 +162,8 @@ OPCODE(1, 1, COMP, IABS)
>  OPCODE(1, 1, COMP, ISSG)
>  OPCODE(1, 2, OTHR, LOAD)
>  OPCODE(1, 2, OTHR, STORE, .is_store = 1)
> -OPCODE_GAP(163) /* removed */
> -OPCODE_GAP(164) /* removed */
> +OPCODE(1, 1, OTHR, IMG2HND)
> +OPCODE(1, 1, OTHR, SAMP2HND, .is_tex = 1)
>  OPCODE_GAP(165) /* removed */
>  OPCODE(0, 0, OTHR, BARRIER)
>
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h 
> b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
> index 9a13fa6684..54a1ee15b6 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
> @@ -160,6 +160,9 @@ OP13(UCMP)
>  OP11(IABS)
>  OP11(ISSG)
>
> +OP11(IMG2HND)
> +OP11(SAMP2HND)
> +
>  OP12(IMUL_HI)
>  OP12(UMUL_HI)
>
> diff --git a/src/gallium/docs/source/tgsi.rst 
> b/src/gallium/docs/source/tgsi.rst
> index 9e956586c4..a4a78e6267 100644
> --- a/src/gallium/docs/source/tgsi.rst
> +++ b/src/gallium/docs/source/tgsi.rst
> @@ -2592,6 +2592,31 @@ For these opcodes, the resource can be a BUFFER, 
> IMAGE, or MEMORY.
>barrier in between.
>
>
> +.. _bindlessopcodes:
> +
> +Bindless Opcodes
> +
> +
> +These opcodes are for working with bindless sampler or image handles and
> +require PIPE_CAP_BINDLESS_TEXTURE.
> +
> +.. opcode:: IMG2HND - Get a bindless handle for a image
> +
> +  Syntax: ``IMG2HND dst, image``
> +
> +  Example: ``IMG2HND TEMP[0], IMAGE[0]``
> +
> +  Sets 'dst' to a bindless handle for 'image'.
> +
> +.. opcode:: SAMP2HND - Get a bindless handle for a sampler view
> +
> +  Syntax: ``SAMP2HND dst, sampler``
> +
> +  Example: ``SAMP2HND TEMP[0], SVIEW[0]``
> +
> +  Sets 'dst' to a bindless handle for 'sampler'.

You want SAMP[0] here, not SVIEW[0].

Handles are defined to be 64-bit, so you should mention that only the
first 2 channels are set, the yw channels are set to zero. (Or
undefined ... although I prefer less undefined stuff.)

> +
> +
>  .. _threadsyncopcodes:
>
>  Inter-thread synchronization opcodes
> diff --git a/src/gallium/include/pipe/p_shader_tokens.h 
> b/src/gallium/include/pipe/p_shader_tokens.h
> index f4e45c2560..08ed08156e 100644
> --- a/src/gallium/include/pipe/p_shader_tokens.h
> +++ b/src/gallium/include/pipe/p_shader_tokens.h
> @@ -506,6 +506,8 @@ enum tgsi_opcode {
>
> TGSI_OPCODE_LOAD   = 161,
> TGSI_OPCODE_STORE  = 162,
> +   TGSI_OPCODE_IMG2HND= 163,
> +   TGSI_OPCODE_SAMP2HND   = 164,
> /* gap */
> TGSI_OPCODE_BARRIER= 166,
>
> --
> 2.14.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa/program_binary: add implicit UseProgram after successful ProgramBinary

[Timothy Arceri]

On 07/06/18 03:44, Jordan Justen wrote:

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106810
Fixes: b4c37ce2140 "i965: Add ARB_get_program_binary support using 
nir_serialization"
Ref: 3fe8d04a6d6 "mesa: don't always set _NEW_PROGRAM when linking"
Ref: c505d6d8522 "mesa: use gl_program for CurrentProgram rather than 
gl_shader_program"
Cc: Timothy Arceri 
Cc: 
Signed-off-by: Jordan Justen 
---
  src/mesa/main/program_binary.c | 33 +
  1 file changed, 33 insertions(+)

diff --git a/src/mesa/main/program_binary.c b/src/mesa/main/program_binary.c
index 021f6315e72..f4aa57821c8 100644
--- a/src/mesa/main/program_binary.c
+++ b/src/mesa/main/program_binary.c
@@ -33,6 +33,8 @@
  #include "compiler/glsl/serialize.h"
  #include "main/errors.h"
  #include "main/mtypes.h"
+#include "main/shaderapi.h"
+#include "util/bitscan.h"
  #include "util/crc32.h"
  #include "program_binary.h"
  #include "program/prog_parameter.h"
@@ -282,10 +284,41 @@ _mesa_program_binary(struct gl_context *ctx, struct 
gl_shader_program *sh_prog,
 struct blob_reader blob;
 blob_reader_init(&blob, payload, length - header_size);
  
+   unsigned programs_in_use = 0;

+   if (ctx->_Shader)
+  for (unsigned stage = 0; stage < MESA_SHADER_STAGES; stage++) {
+ if (ctx->_Shader->CurrentProgram[stage] &&
+ ctx->_Shader->CurrentProgram[stage]->Id == sh_prog->Name) {
+programs_in_use |= 1 << stage;
+ }
+   }
+
 if (!read_program_payload(ctx, &blob, binary_format, sh_prog)) {
sh_prog->data->LinkStatus = LINKING_FAILURE;
return;
 }
  
+   /* From section 7.3 (Program Objects) of the OpenGL 4.5 spec:

+*
+*"If LinkProgram or ProgramBinary successfully re-links a program
+* object that is active for any shader stage, then the newly generated
+* executable code will be installed as part of the current rendering
+* state for all shader stages where the program is active.
+* Additionally, the newly generated executable code is made part of
+* the state of any program pipeline for all stages where the program
+* is attached."
+*/
+   if (programs_in_use) {


I realise the same is true for the original code but we can drop the 
outer if as its already covered by the while.


With that this patch is:

Reviewed-by: Timothy Arceri 

Although I'd really encourage you to create a piglit test for this.


+  while (programs_in_use) {
+ const int stage = u_bit_scan(&programs_in_use);
+
+ struct gl_program *prog = NULL;
+ if (sh_prog->_LinkedShaders[stage])
+prog = sh_prog->_LinkedShaders[stage]->Program;
+
+ _mesa_use_program(ctx, stage, sh_prog, prog, ctx->_Shader);
+  }
+   }
+
 sh_prog->data->LinkStatus = LINKING_SKIPPED;
  }


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

Re: [Mesa-dev] [PATCH] dri: add missing 16bits formats mapping

[Jason Ekstrand]

It might be good to add some additional commentary in the commit message
such as:

i965 advertises the 16-bit R and RG formats through
eglQueryDmaBufFormatsEXT but falls over when a client tries to use or asks
more information about such a format because driImageFormatToGLFormat
returns MESA_FORMAT_NONE.

Reviewed-by: Jason Ekstrand 

Let's use this instead of patch 5/7 from the series I sent earlier.  I'm
still not sure I believe Daniel but advertising them shouldn't hurt.

On Wed, Jun 6, 2018 at 10:36 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Found by Eero.
>
> v2: Add G16R16 formats (Lionel)
>
> v3: Fix G16R16 mapping to mesa format (Jason)
>
> Signed-off-by: Lionel Landwerlin 
> Reviewed-by: Plamena Manolova  (v2)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106642
> ---
>  src/mesa/drivers/dri/common/dri_util.c | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/common/dri_util.c
> b/src/mesa/drivers/dri/common/dri_util.c
> index a591dfcd7d2..d257cb644c8 100644
> --- a/src/mesa/drivers/dri/common/dri_util.c
> +++ b/src/mesa/drivers/dri/common/dri_util.c
> @@ -936,6 +936,22 @@ static const struct {
>.image_format = __DRI_IMAGE_FORMAT_SARGB8,
>.mesa_format  =MESA_FORMAT_B8G8R8A8_SRGB,
> },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_R16,
> +  .mesa_format  =MESA_FORMAT_R_UNORM16,
> +   },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_R16,
> +  .mesa_format  =MESA_FORMAT_L_UNORM16,
> +   },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_GR1616,
> +  .mesa_format  =MESA_FORMAT_R16G16_UNORM,
> +   },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_GR1616,
> +  .mesa_format  =MESA_FORMAT_L16A16_UNORM,
> +   },
>  };
>
>  uint32_t
> --
> 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

Re: [Mesa-dev] [PATCH 1/2] intel/isl: Add bounds-checking assertions in isl_format_get_layout

[Jason Ekstrand]

On Wed, Jun 6, 2018 at 10:25 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> On 06/06/18 18:17, Jason Ekstrand wrote:
>
>> We add two assertions instead of one because the first assertion that
>> format != ISL_FORMAT_UNSUPPORTED is more descriptive and checks for a
>> real but unsupported enumerant while the second ensures that they don't
>> pass in garbage values.  We also update some other helpers to use
>> isl_format_get_layout instead of using the table directly so that they
>> get bounds checking too.
>>
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>   src/intel/isl/isl.h | 32 +---
>>   1 file changed, 21 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
>> index 00cfe31fc04..6800b1d76a6 100644
>> --- a/src/intel/isl/isl.h
>> +++ b/src/intel/isl/isl.h
>> @@ -389,6 +389,9 @@ enum isl_format {
>>  ISL_FORMAT_GEN9_CCS_64BPP,
>>  ISL_FORMAT_GEN9_CCS_128BPP,
>>   +   /* An upper bound on the supported format enumerations */
>> +   ISL_NUM_FORMATS,
>> +
>>  /* Hardware doesn't understand this out-of-band value */
>>  ISL_FORMAT_UNSUPPORTED = UINT16_MAX,
>>   };
>> @@ -1423,6 +1426,8 @@ isl_device_get_sample_counts(struct isl_device
>> *dev);
>>   static inline const struct isl_format_layout * ATTRIBUTE_CONST
>>   isl_format_get_layout(enum isl_format fmt)
>>   {
>> +   assert(fmt != ISL_FORMAT_UNSUPPORTED);
>> +   assert(fmt < ISL_NUM_FORMATS);
>>  return &isl_format_layouts[fmt];
>>   }
>>   @@ -1431,7 +1436,7 @@ bool isl_format_is_valid(enum isl_format);
>>   static inline const char * ATTRIBUTE_CONST
>>   isl_format_get_name(enum isl_format fmt)
>>   {
>> -   return isl_format_layouts[fmt].name;
>> +   return isl_format_get_layout(fmt)->name;
>>   }
>> bool isl_format_supports_rendering(const struct gen_device_info
>> *devinfo,
>> @@ -1546,7 +1551,7 @@ isl_format_block_is_1x1x1(enum isl_format fmt)
>>   static inline bool
>>   isl_format_is_srgb(enum isl_format fmt)
>>   {
>> -   return isl_format_layouts[fmt].colorspace == ISL_COLORSPACE_SRGB;
>> +   return isl_format_get_layout(fmt)->colorspace == ISL_COLORSPACE_SRGB;
>>   }
>> enum isl_format isl_format_srgb_to_linear(enum isl_format fmt);
>> @@ -1556,20 +1561,25 @@ isl_format_is_rgb(enum isl_format fmt)
>>   {
>>  if (isl_format_is_yuv(fmt))
>> return false;
>> -   return isl_format_layouts[fmt].channels.r.bits > 0 &&
>> -  isl_format_layouts[fmt].channels.g.bits > 0 &&
>> -  isl_format_layouts[fmt].channels.b.bits > 0 &&
>> -  isl_format_layouts[fmt].channels.a.bits == 0;
>> +
>> +   const struct isl_format_layout *fmtl = isl_format_get_layout(fmt);
>> +
>> +   return fmtl->channels.r.bits > 0 &&
>> +  fmtl->channels.g.bits > 0 &&
>> +  fmtl->channels.b.bits > 0 &&
>> +  fmtl->channels.a.bits == 0;
>>   }
>> static inline bool
>>   isl_format_is_rgbx(enum isl_format fmt)
>>   {
>> -   return isl_format_layouts[fmt].channels.r.bits > 0 &&
>> -  isl_format_layouts[fmt].channels.g.bits > 0 &&
>> -  isl_format_layouts[fmt].channels.b.bits > 0 &&
>> -  isl_format_layouts[fmt].channels.a.bits > 0 &&
>> -  isl_format_layouts[fmt].channels.a.type == ISL_VOID;
>> +   const struct isl_format_layout *fmtl = isl_format_get_layout(fmt);
>> +
>> +   return fmtl->channels.r.bits > 0 &&
>> +  fmtl->channels.g.bits > 0 &&
>> +  fmtl->channels.b.bits > 0 &&
>> +  fmtl->channels.a.bits > 0 &&
>> +  fmtl->channels.a.type == ISL_VOID;
>>   }
>> enum isl_format isl_format_rgb_to_rgba(enum isl_format rgb)
>> ATTRIBUTE_CONST;
>>
> Do you want to use it in isl_buffer_fill_image_param() too?
>

Good call.  I've made that change locally.


> Reviewed-by: Lionel Landwerlin 
>

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

Re: [Mesa-dev] [PATCH 1/8] nir: Document a couple instances of parent_instr

[Jason Ekstrand]

On Wed, Jun 6, 2018 at 2:33 PM, Ian Romanick  wrote:

> From: Ian Romanick 
>
> nir_ssa_def::parent_instr and nir_src::parent_instr have the same name,
> but they mean really different things.  I choose to save the next person
> the hour+ that I just spent figuring that out.  Even now that I know, I
> doubt I'd notice in code review that someone typed foo->parent_instr
> when they actually meant foo->ssa->parent_instr.
>
> Signed-off-by: Ian Romanick 
> ---
>  src/compiler/nir/nir.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 5a1f79515ad..ba2a7142aa0 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -490,6 +490,7 @@ typedef struct nir_ssa_def {
> /** Index into the live_in and live_out bitfields */
> unsigned live_index;
>
> +   /** Instruction whose result is this SSA value. */
>

Maybe "which produces this SSA value"?  I don't know if that's better.
Either way, documentation is good. :)

Reviewed-by: Jason Ekstrand 


> nir_instr *parent_instr;
>
> /** set of nir_instrs where this register is used (read from) */
> @@ -529,6 +530,7 @@ struct nir_if;
>
>  typedef struct nir_src {
> union {
> +  /** Instruction that consumes this value as a source. */
>nir_instr *parent_instr;
>struct nir_if *parent_if;
> };
> --
> 2.14.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/8] nir: Add nir_const_value_negative_equal

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/compiler/nir/meson.build|  12 +
 src/compiler/nir/nir.h  |   6 +
 src/compiler/nir/nir_instr_set.c|  98 +
 src/compiler/nir/tests/negative_equal_tests.cpp | 278 
 4 files changed, 394 insertions(+)
 create mode 100644 src/compiler/nir/tests/negative_equal_tests.cpp

diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index 3fec363691d..18dea5eeb2b 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -236,4 +236,16 @@ if with_tests
   link_with : libmesa_util,
 )
   )
+
+  test(
+'negative_equal',
+executable(
+  'negative_equal',
+  files('tests/negative_equal_tests.cpp'),
+  c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
+  include_directories : [inc_common],
+  dependencies : [dep_thread, idep_gtest, idep_nir],
+  link_with : libmesa_util,
+)
+  )
 endif
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 1ce7bcb9df1..fee2c1c150b 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -887,6 +887,12 @@ nir_ssa_alu_instr_src_components(const nir_alu_instr 
*instr, unsigned src)
return instr->dest.dest.ssa.num_components;
 }
 
+bool nir_const_value_negative_equal(const nir_const_value *c1,
+const nir_const_value *c2,
+unsigned components,
+nir_alu_type base_type,
+unsigned bits);
+
 bool nir_alu_srcs_equal(const nir_alu_instr *alu1, const nir_alu_instr *alu2,
 unsigned src1, unsigned src2);
 
diff --git a/src/compiler/nir/nir_instr_set.c b/src/compiler/nir/nir_instr_set.c
index 9cb9ed43e8b..a8e47ff874a 100644
--- a/src/compiler/nir/nir_instr_set.c
+++ b/src/compiler/nir/nir_instr_set.c
@@ -23,6 +23,7 @@
 
 #include "nir_instr_set.h"
 #include "nir_vla.h"
+#include "util/half_float.h"
 
 #define HASH(hash, data) _mesa_fnv32_1a_accumulate((hash), (data))
 
@@ -228,6 +229,103 @@ nir_srcs_equal(nir_src src1, nir_src src2)
}
 }
 
+bool
+nir_const_value_negative_equal(const nir_const_value *c1,
+   const nir_const_value *c2,
+   unsigned components,
+   nir_alu_type base_type,
+   unsigned bits)
+{
+   assert(base_type == nir_alu_type_get_base_type(base_type));
+   assert(base_type != nir_type_invalid);
+
+   switch (base_type) {
+   case nir_type_float:
+  switch (bits) {
+  case 16:
+ for (unsigned i = 0; i < components; i++) {
+if (_mesa_half_to_float(c1->u16[i]) !=
+-_mesa_half_to_float(c2->u16[i])) {
+   return false;
+}
+ }
+
+ return true;
+
+  case 32:
+ for (unsigned i = 0; i < components; i++) {
+if (c1->f32[i] != -c2->f32[i])
+   return false;
+ }
+
+ return true;
+
+  case 64:
+ for (unsigned i = 0; i < components; i++) {
+if (c1->f64[i] != -c2->f64[i])
+   return false;
+ }
+
+ return true;
+
+  default:
+ unreachable("unknown bit size");
+  }
+
+  break;
+
+   case nir_type_int:
+   case nir_type_uint:
+  switch (bits) {
+  case 8:
+ for (unsigned i = 0; i < components; i++) {
+if (c1->i8[i] != -c2->i8[i])
+   return false;
+ }
+
+ return true;
+
+  case 16:
+ for (unsigned i = 0; i < components; i++) {
+if (c1->i16[i] != -c2->i16[i])
+   return false;
+ }
+
+ return true;
+ break;
+
+  case 32:
+ for (unsigned i = 0; i < components; i++) {
+if (c1->i32[i] != -c2->i32[i])
+   return false;
+ }
+
+ return true;
+
+  case 64:
+ for (unsigned i = 0; i < components; i++) {
+if (c1->i64[i] != -c2->i64[i])
+   return false;
+ }
+
+ return true;
+
+  default:
+ unreachable("unknown bit size");
+  }
+
+  break;
+
+   case nir_type_bool:
+  return false;
+
+   default:
+  break;
+   }
+
+   return false;
+}
+
 bool
 nir_alu_srcs_equal(const nir_alu_instr *alu1, const nir_alu_instr *alu2,
unsigned src1, unsigned src2)
diff --git a/src/compiler/nir/tests/negative_equal_tests.cpp 
b/src/compiler/nir/tests/negative_equal_tests.cpp
new file mode 100644
index 000..e450a8172db
--- /dev/null
+++ b/src/compiler/nir/tests/negative_equal_tests.cpp
@@ -0,0 +1,278 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in

[Mesa-dev] [PATCH 7/8] nir: Add partial redundancy elimination for compares

[Ian Romanick]

From: Ian Romanick 

This pass attempts to dectect code sequences like

if (x < y) {
z = y - z;
...
}

and replace them with sequences like

t = x - y;
if (t < 0) {
z = t;
...
}

On architectures where the subtract can generate the flags used by the
if-statement, this saves an instruction.  It's also possible that moving
an instruction out of the if-statement will allow
nir_opt_peephole_select to convert the whole thing to a bcsel.

Currently only floating point compares and adds are supported.  Adding
support for integer will be a challenge due to integer overflow.  There
are a couple possible solutions, but they may not apply to all
architectures.

Signed-off-by: Ian Romanick 
---
 src/compiler/Makefile.sources |   1 +
 src/compiler/nir/meson.build  |   1 +
 src/compiler/nir/nir.h|   2 +
 src/compiler/nir/nir_instr_set.c  |   3 +-
 src/compiler/nir/nir_opt_comparison_pre.c | 354 ++
 src/compiler/nir/nir_search_helpers.h |  29 +++
 6 files changed, 389 insertions(+), 1 deletion(-)
 create mode 100644 src/compiler/nir/nir_opt_comparison_pre.c

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 3daa2c51334..5bd8b1dbd43 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -255,6 +255,7 @@ NIR_FILES = \
nir/nir_metadata.c \
nir/nir_move_vec_src_uses_to_dest.c \
nir/nir_normalize_cubemap_coords.c \
+   nir/nir_opt_comparison_pre.c \
nir/nir_opt_conditional_discard.c \
nir/nir_opt_constant_folding.c \
nir/nir_opt_copy_prop_vars.c \
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index 18dea5eeb2b..0549516f824 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -146,6 +146,7 @@ files_libnir = files(
   'nir_metadata.c',
   'nir_move_vec_src_uses_to_dest.c',
   'nir_normalize_cubemap_coords.c',
+  'nir_opt_comparison_pre.c',
   'nir_opt_conditional_discard.c',
   'nir_opt_constant_folding.c',
   'nir_opt_copy_prop_vars.c',
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 3643d3c5f35..12ee9bca707 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2873,6 +2873,8 @@ bool nir_convert_from_ssa(nir_shader *shader, bool 
phi_webs_only);
 bool nir_lower_phis_to_regs_block(nir_block *block);
 bool nir_lower_ssa_defs_to_regs_block(nir_block *block);
 
+bool nir_opt_comparison_pre(nir_shader *shader);
+
 bool nir_opt_algebraic(nir_shader *shader);
 bool nir_opt_algebraic_before_ffma(nir_shader *shader);
 bool nir_opt_algebraic_late(nir_shader *shader);
diff --git a/src/compiler/nir/nir_instr_set.c b/src/compiler/nir/nir_instr_set.c
index 1a491f46ff4..e9371af230a 100644
--- a/src/compiler/nir/nir_instr_set.c
+++ b/src/compiler/nir/nir_instr_set.c
@@ -239,7 +239,8 @@ get_neg_instr(const nir_src *s)
 {
const struct nir_alu_instr *const alu = nir_src_as_alu_instr_const(s);
 
-   return alu->op == nir_op_fneg || alu->op == nir_op_ineg ? alu : NULL;
+   return alu != NULL && (alu->op == nir_op_fneg || alu->op == nir_op_ineg)
+  ? alu : NULL;
 }
 
 bool
diff --git a/src/compiler/nir/nir_opt_comparison_pre.c 
b/src/compiler/nir/nir_opt_comparison_pre.c
new file mode 100644
index 000..86a35f78e02
--- /dev/null
+++ b/src/compiler/nir/nir_opt_comparison_pre.c
@@ -0,0 +1,354 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "nir_instr_set.h"
+#include "nir_search_helpers.h"
+#include "nir_builder.h"
+#include "util/u_vector.h"
+
+/* Partial redundancy elimination of compares
+ *
+ * Seaches for comparisons of the form 'a cmp b' that dominate arithmetic
+ * instructions like 'b - a'.  The comparison is replaced by the arithmetic
+ * instruction, and the result is comp

[Mesa-dev] [PATCH 3/8] intel/compiler: Silence unused parameter warnings brw_nir.c

[Ian Romanick]

From: Ian Romanick 

src/intel/compiler/brw_nir.c: In function ‘brw_nir_lower_vue_outputs’:
src/intel/compiler/brw_nir.c:464:32: warning: unused parameter ‘is_scalar’ 
[-Wunused-parameter]
   bool is_scalar)
^
src/intel/compiler/brw_nir.c: In function ‘lower_bit_size_callback’:
src/intel/compiler/brw_nir.c:610:57: warning: unused parameter ‘data’ 
[-Wunused-parameter]
 lower_bit_size_callback(const nir_alu_instr *alu, void *data)
 ^~~~

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_nir.c   | 5 ++---
 src/intel/compiler/brw_nir.h   | 2 +-
 src/intel/compiler/brw_shader.cpp  | 2 +-
 src/intel/compiler/brw_vec4.cpp| 2 +-
 src/intel/compiler/brw_vec4_gs_visitor.cpp | 2 +-
 5 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index dfeea73b06a..67c062d91f5 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -460,8 +460,7 @@ brw_nir_lower_fs_inputs(nir_shader *nir,
 }
 
 void
-brw_nir_lower_vue_outputs(nir_shader *nir,
-  bool is_scalar)
+brw_nir_lower_vue_outputs(nir_shader *nir)
 {
nir_foreach_variable(var, &nir->outputs) {
   var->data.driver_location = var->data.location;
@@ -593,7 +592,7 @@ brw_nir_optimize(nir_shader *nir, const struct brw_compiler 
*compiler,
 }
 
 static unsigned
-lower_bit_size_callback(const nir_alu_instr *alu, void *data)
+lower_bit_size_callback(const nir_alu_instr *alu, UNUSED void *data)
 {
assert(alu->dest.dest.is_ssa);
if (alu->dest.dest.ssa.bit_size != 16)
diff --git a/src/intel/compiler/brw_nir.h b/src/intel/compiler/brw_nir.h
index 03f52da08e5..19442b47eae 100644
--- a/src/intel/compiler/brw_nir.h
+++ b/src/intel/compiler/brw_nir.h
@@ -109,7 +109,7 @@ void brw_nir_lower_tes_inputs(nir_shader *nir, const struct 
brw_vue_map *vue);
 void brw_nir_lower_fs_inputs(nir_shader *nir,
  const struct gen_device_info *devinfo,
  const struct brw_wm_prog_key *key);
-void brw_nir_lower_vue_outputs(nir_shader *nir, bool is_scalar);
+void brw_nir_lower_vue_outputs(nir_shader *nir);
 void brw_nir_lower_tcs_outputs(nir_shader *nir, const struct brw_vue_map *vue,
GLenum tes_primitive_mode);
 void brw_nir_lower_fs_outputs(nir_shader *nir);
diff --git a/src/intel/compiler/brw_shader.cpp 
b/src/intel/compiler/brw_shader.cpp
index b7fb06ddbd9..812a19aed29 100644
--- a/src/intel/compiler/brw_shader.cpp
+++ b/src/intel/compiler/brw_shader.cpp
@@ -1194,7 +1194,7 @@ brw_compile_tes(const struct brw_compiler *compiler,
 
nir = brw_nir_apply_sampler_key(nir, compiler, &key->tex, is_scalar);
brw_nir_lower_tes_inputs(nir, input_vue_map);
-   brw_nir_lower_vue_outputs(nir, is_scalar);
+   brw_nir_lower_vue_outputs(nir);
nir = brw_postprocess_nir(nir, compiler, is_scalar);
 
brw_compute_vue_map(devinfo, &prog_data->base.vue_map,
diff --git a/src/intel/compiler/brw_vec4.cpp b/src/intel/compiler/brw_vec4.cpp
index 4464a913988..cf300efe2a6 100644
--- a/src/intel/compiler/brw_vec4.cpp
+++ b/src/intel/compiler/brw_vec4.cpp
@@ -2810,7 +2810,7 @@ brw_compile_vs(const struct brw_compiler *compiler, void 
*log_data,
prog_data->double_inputs_read = shader->info.vs.double_inputs;
 
brw_nir_lower_vs_inputs(shader, key->gl_attrib_wa_flags);
-   brw_nir_lower_vue_outputs(shader, is_scalar);
+   brw_nir_lower_vue_outputs(shader);
shader = brw_postprocess_nir(shader, compiler, is_scalar);
 
prog_data->base.clip_distance_mask =
diff --git a/src/intel/compiler/brw_vec4_gs_visitor.cpp 
b/src/intel/compiler/brw_vec4_gs_visitor.cpp
index fb4c1259948..e03e75f91f3 100644
--- a/src/intel/compiler/brw_vec4_gs_visitor.cpp
+++ b/src/intel/compiler/brw_vec4_gs_visitor.cpp
@@ -642,7 +642,7 @@ brw_compile_gs(const struct brw_compiler *compiler, void 
*log_data,
 
shader = brw_nir_apply_sampler_key(shader, compiler, &key->tex, is_scalar);
brw_nir_lower_vue_inputs(shader, &c.input_vue_map);
-   brw_nir_lower_vue_outputs(shader, is_scalar);
+   brw_nir_lower_vue_outputs(shader);
shader = brw_postprocess_nir(shader, compiler, is_scalar);
 
prog_data->base.clip_distance_mask =
-- 
2.14.4

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

[Mesa-dev] [PATCH 4/8] intel/compiler: More peephole select

[Ian Romanick]

From: Ian Romanick 

Shader-db results:

Skylake and Broadwell had similar results. (Skylake shown)
total instructions in shared programs: 14371513 -> 14346174 (-0.18%)
instructions in affected programs: 890389 -> 865050 (-2.85%)
helped: 3601
HURT: 1
helped stats (abs) min: 1 max: 92 x̄: 7.05 x̃: 4
helped stats (rel) min: 0.10% max: 25.00% x̄: 3.95% x̃: 3.23%
HURT stats (abs)   min: 43 max: 43 x̄: 43.00 x̃: 43
HURT stats (rel)   min: 0.90% max: 0.90% x̄: 0.90% x̃: 0.90%
95% mean confidence interval for instructions value: -7.27 -6.80
95% mean confidence interval for instructions %-change: -4.05% -3.84%
Instructions are helped.

total cycles in shared programs: 532435951 -> 532154282 (-0.05%)
cycles in affected programs: 69203137 -> 68921468 (-0.41%)
helped: 2654
HURT: 981
helped stats (abs) min: 1 max: 4496 x̄: 177.17 x̃: 76
helped stats (rel) min: <.01% max: 71.34% x̄: 9.16% x̃: 5.42%
HURT stats (abs)   min: 1 max: 8 x̄: 192.20 x̃: 19
HURT stats (rel)   min: <.01% max: 36.36% x̄: 2.95% x̃: 1.46%
95% mean confidence interval for cycles value: -113.38 -41.60
95% mean confidence interval for cycles %-change: -6.24% -5.53%
Cycles are helped.

total spills in shared programs: 8114 -> 8122 (0.10%)
spills in affected programs: 152 -> 160 (5.26%)
helped: 0
HURT: 2

total fills in shared programs: 11082 -> 11100 (0.16%)
fills in affected programs: 375 -> 393 (4.80%)
helped: 1
HURT: 1

Haswell, Ivy Bridge, and Sandy Bridge had similar results. (Ivy Bridge shown)
total instructions in shared programs: 9897654 -> 9890341 (-0.07%)
instructions in affected programs: 213092 -> 205779 (-3.43%)
helped: 775
HURT: 18
helped stats (abs) min: 1 max: 65 x̄: 9.62 x̃: 6
helped stats (rel) min: 0.11% max: 25.00% x̄: 4.85% x̃: 3.70%
HURT stats (abs)   min: 2 max: 20 x̄: 7.89 x̃: 6
HURT stats (rel)   min: 0.70% max: 2.59% x̄: 1.63% x̃: 1.70%
95% mean confidence interval for instructions value: -9.93 -8.51
95% mean confidence interval for instructions %-change: -5.01% -4.40%
Instructions are helped.

total cycles in shared programs: 87653348 -> 87562421 (-0.10%)
cycles in affected programs: 2411339 -> 2320412 (-3.77%)
helped: 612
HURT: 227
helped stats (abs) min: 1 max: 2103 x̄: 162.83 x̃: 53
helped stats (rel) min: 0.05% max: 58.41% x̄: 6.50% x̃: 2.65%
HURT stats (abs)   min: 1 max: 772 x̄: 38.43 x̃: 10
HURT stats (rel)   min: 0.04% max: 36.36% x̄: 3.60% x̃: 0.92%
95% mean confidence interval for cycles value: -128.53 -88.22
95% mean confidence interval for cycles %-change: -4.39% -3.14%
Cycles are helped.

No change on Iron Lake or GM45.

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_nir.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 67c062d91f5..ca9b021767f 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -557,7 +557,21 @@ brw_nir_optimize(nir_shader *nir, const struct 
brw_compiler *compiler,
   OPT(nir_copy_prop);
   OPT(nir_opt_dce);
   OPT(nir_opt_cse);
+
+  /* Passing 0 to the peephole select pass causes it to convert
+   * if-statements that contain only move instructions in the branches
+   * regardless of the count.
+   *
+   * Passing 0 to the peephole select pass causes it to convert
+   * if-statements that contain at most a single ALU instruction (total)
+   * in both branches.  The select instruction works somewhat differently
+   * on Gen5 and earlier, and adding this pass on those platforms was
+   * found to be generally harmful.
+   */
   OPT(nir_opt_peephole_select, 0);
+  if (compiler->devinfo->gen >= 6)
+ OPT(nir_opt_peephole_select, 1);
+
   OPT(nir_opt_intrinsics);
   OPT(nir_opt_algebraic);
   OPT(nir_opt_constant_folding);
-- 
2.14.4

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

[Mesa-dev] [PATCH 2/8] nir: Add helper functions to get the instruction that generated a nir_src

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/compiler/nir/nir.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index ba2a7142aa0..1ce7bcb9df1 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2355,6 +2355,29 @@ bool nir_foreach_dest(nir_instr *instr, 
nir_foreach_dest_cb cb, void *state);
 bool nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, void *state);
 
 nir_const_value *nir_src_as_const_value(nir_src src);
+
+static inline struct nir_instr *
+nir_src_instr(const struct nir_src *src)
+{
+   return src->is_ssa ? src->ssa->parent_instr : NULL;
+}
+
+#define NIR_SRC_AS_(name, c_type, type_enum, cast_macro)\
+static inline c_type *  \
+nir_src_as_ ## name (struct nir_src *src)   \
+{   \
+return src->is_ssa && src->ssa->parent_instr->type == type_enum \
+   ? cast_macro(src->ssa->parent_instr) : NULL; \
+}   \
+static inline const c_type *\
+nir_src_as_ ## name ## _const(const struct nir_src *src)\
+{   \
+return src->is_ssa && src->ssa->parent_instr->type == type_enum \
+   ? cast_macro(src->ssa->parent_instr) : NULL; \
+}
+
+NIR_SRC_AS_(alu_instr, nir_alu_instr, nir_instr_type_alu, nir_instr_as_alu)
+
 bool nir_src_is_dynamically_uniform(nir_src src);
 bool nir_srcs_equal(nir_src src1, nir_src src2);
 void nir_instr_rewrite_src(nir_instr *instr, nir_src *src, nir_src new_src);
-- 
2.14.4

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

[Mesa-dev] [PATCH 6/8] nir: Add nir_alu_srcs_negative_equal

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/compiler/nir/nir.h  |   4 +
 src/compiler/nir/nir_instr_set.c| 103 
 src/compiler/nir/tests/negative_equal_tests.cpp |  84 +++
 3 files changed, 191 insertions(+)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index fee2c1c150b..3643d3c5f35 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -896,6 +896,10 @@ bool nir_const_value_negative_equal(const nir_const_value 
*c1,
 bool nir_alu_srcs_equal(const nir_alu_instr *alu1, const nir_alu_instr *alu2,
 unsigned src1, unsigned src2);
 
+bool nir_alu_srcs_negative_equal(const nir_alu_instr *alu1,
+ const nir_alu_instr *alu2,
+ unsigned src1, unsigned src2);
+
 typedef enum {
nir_deref_type_var,
nir_deref_type_array,
diff --git a/src/compiler/nir/nir_instr_set.c b/src/compiler/nir/nir_instr_set.c
index a8e47ff874a..1a491f46ff4 100644
--- a/src/compiler/nir/nir_instr_set.c
+++ b/src/compiler/nir/nir_instr_set.c
@@ -229,6 +229,19 @@ nir_srcs_equal(nir_src src1, nir_src src2)
}
 }
 
+/**
+ * If the \p s is an SSA value that was generated by a negation instruction,
+ * that instruction is returned as a \c nir_alu_instr.  Otherwise \c NULL is
+ * returned.
+ */
+static const struct nir_alu_instr *
+get_neg_instr(const nir_src *s)
+{
+   const struct nir_alu_instr *const alu = nir_src_as_alu_instr_const(s);
+
+   return alu->op == nir_op_fneg || alu->op == nir_op_ineg ? alu : NULL;
+}
+
 bool
 nir_const_value_negative_equal(const nir_const_value *c1,
const nir_const_value *c2,
@@ -326,6 +339,96 @@ nir_const_value_negative_equal(const nir_const_value *c1,
return false;
 }
 
+/**
+ * Shallow compare of ALU srcs to determine if one is the negation of the other
+ *
+ * This function detects cases where \p alu1 is a constant and \p alu2 is a
+ * constant that is its negation.  It will also detect cases where \p alu2 is
+ * an SSA value that is a \c nir_op_fneg applied to \p alu1 (and vice versa).
+ *
+ * This function does not detect the general case when \p alu1 and \p alu2 are
+ * SSA values that are the negations of each other (e.g., \p alu1 represents
+ * (a * b) and \p alu2 represents (-a * b)).
+ */
+bool
+nir_alu_srcs_negative_equal(const nir_alu_instr *alu1,
+const nir_alu_instr *alu2,
+unsigned src1, unsigned src2)
+{
+   if (alu1->src[src1].abs != alu2->src[src2].abs)
+  return false;
+
+   bool parity = alu1->src[src1].negate != alu2->src[src2].negate;
+
+   /* Handling load_const instructions is tricky. */
+
+   const nir_const_value *const const1 =
+  nir_src_as_const_value(alu1->src[src1].src);
+
+   if (const1 != NULL) {
+  /* Assume that constant folding will eliminate source mods and unary
+   * ops.
+   */
+  if (parity)
+ return false;
+
+  const nir_const_value *const const2 =
+ nir_src_as_const_value(alu2->src[src2].src);
+
+  if (const2 == NULL)
+ return false;
+
+  /* FINISHME: Apply the swizzle? */
+  return nir_const_value_negative_equal(const1,
+const2,
+
nir_ssa_alu_instr_src_components(alu1, src1),
+
nir_op_infos[alu1->op].input_types[src1],
+alu1->dest.dest.ssa.bit_size);
+   }
+
+   uint8_t alu1_swizzle[4] = {};
+   nir_src alu1_actual_src;
+   const struct nir_alu_instr *const neg1 = 
get_neg_instr(&alu1->src[src1].src);
+
+   if (neg1) {
+  parity = !parity;
+  alu1_actual_src = neg1->src[0].src;
+
+  for (unsigned i = 0; i < nir_ssa_alu_instr_src_components(neg1, 0); i++)
+ alu1_swizzle[i] = neg1->src[0].swizzle[i];
+   } else {
+  alu1_actual_src = alu1->src[src1].src;
+
+  for (unsigned i = 0; i < nir_ssa_alu_instr_src_components(alu1, src1); 
i++)
+ alu1_swizzle[i] = i;
+   }
+
+   uint8_t alu2_swizzle[4] = {};
+   nir_src alu2_actual_src;
+   const struct nir_alu_instr *const neg2 = 
get_neg_instr(&alu2->src[src2].src);
+
+   if (neg2) {
+  parity = !parity;
+  alu2_actual_src = neg2->src[0].src;
+
+  for (unsigned i = 0; i < nir_ssa_alu_instr_src_components(neg2, 0); i++)
+ alu2_swizzle[i] = neg2->src[0].swizzle[i];
+   } else {
+  alu2_actual_src = alu2->src[src2].src;
+
+  for (unsigned i = 0; i < nir_ssa_alu_instr_src_components(alu2, src2); 
i++)
+ alu2_swizzle[i] = i;
+   }
+
+   for (unsigned i = 0; i < nir_ssa_alu_instr_src_components(alu1, src1); i++) 
{
+  if (alu1_swizzle[alu1->src[src1].swizzle[i]] !=
+  alu2_swizzle[alu2->src[src2].swizzle[i]])
+ return false;
+   }
+
+   return parity && nir_srcs_equal(alu1_actual_src, alu2_actual_src);
+}
+

[Mesa-dev] [PATCH 8/8] intel/compiler: Use partial redundancy elimination for compares

[Ian Romanick]

From: Ian Romanick 

Almost all of the hurt shaders are repeated instances of the same shader
in synmark's compilation speed tests.

shader-db results:

All Gen7+ platforms had similar results. (Haswell shown)
total instructions in shared programs: 12944679 -> 12943956 (<.01%)
instructions in affected programs: 59749 -> 59026 (-1.21%)
helped: 329
HURT: 0
helped stats (abs) min: 1 max: 9 x̄: 2.20 x̃: 1
helped stats (rel) min: 0.11% max: 23.53% x̄: 1.85% x̃: 1.27%
95% mean confidence interval for instructions value: -2.37 -2.03
95% mean confidence interval for instructions %-change: -2.15% -1.56%
Instructions are helped.

total cycles in shared programs: 410012259 -> 409991735 (<.01%)
cycles in affected programs: 786938 -> 766414 (-2.61%)
helped: 243
HURT: 50
helped stats (abs) min: 1 max: 417 x̄: 86.98 x̃: 18
helped stats (rel) min: <.01% max: 29.16% x̄: 5.69% x̃: 1.04%
HURT stats (abs)   min: 2 max: 130 x̄: 12.22 x̃: 5
HURT stats (rel)   min: <.01% max: 14.67% x̄: 0.83% x̃: 0.09%
95% mean confidence interval for cycles value: -85.80 -54.30
95% mean confidence interval for cycles %-change: -5.62% -3.54%
Cycles are helped.

Sandy Bridge
total instructions in shared programs: 10421031 -> 10420472 (<.01%)
instructions in affected programs: 5 -> 59440 (-0.93%)
helped: 297
HURT: 0
helped stats (abs) min: 1 max: 9 x̄: 1.88 x̃: 1
helped stats (rel) min: 0.11% max: 22.22% x̄: 1.59% x̃: 0.88%
95% mean confidence interval for instructions value: -2.04 -1.72
95% mean confidence interval for instructions %-change: -1.88% -1.30%
Instructions are helped.

total cycles in shared programs: 146060196 -> 146054402 (<.01%)
cycles in affected programs: 1009543 -> 1003749 (-0.57%)
helped: 281
HURT: 9
helped stats (abs) min: 1 max: 76 x̄: 21.88 x̃: 12
helped stats (rel) min: 0.04% max: 6.43% x̄: 0.85% x̃: 0.66%
HURT stats (abs)   min: 1 max: 161 x̄: 39.22 x̃: 6
HURT stats (rel)   min: 0.04% max: 14.64% x̄: 3.91% x̃: 0.69%
95% mean confidence interval for cycles value: -23.15 -16.81
95% mean confidence interval for cycles %-change: -0.88% -0.52%
Cycles are helped.

Iron Lake
total instructions in shared programs: 7780915 -> 7780598 (<.01%)
instructions in affected programs: 36518 -> 36201 (-0.87%)
helped: 116
HURT: 0
helped stats (abs) min: 1 max: 9 x̄: 2.73 x̃: 2
helped stats (rel) min: 0.27% max: 14.29% x̄: 1.97% x̃: 0.75%
95% mean confidence interval for instructions value: -3.01 -2.45
95% mean confidence interval for instructions %-change: -2.55% -1.39%
Instructions are helped.

total cycles in shared programs: 177876108 -> 177874792 (<.01%)
cycles in affected programs: 636218 -> 634902 (-0.21%)
helped: 113
HURT: 2
helped stats (abs) min: 2 max: 36 x̄: 11.68 x̃: 12
helped stats (rel) min: 0.04% max: 3.19% x̄: 0.47% x̃: 0.23%
HURT stats (abs)   min: 2 max: 2 x̄: 2.00 x̃: 2
HURT stats (rel)   min: 0.04% max: 0.09% x̄: 0.06% x̃: 0.06%
95% mean confidence interval for cycles value: -12.51 -10.38
95% mean confidence interval for cycles %-change: -0.57% -0.36%
Cycles are helped.

GM45
total instructions in shared programs: 4799152 -> 4798939 (<.01%)
instructions in affected programs: 22520 -> 22307 (-0.95%)
helped: 71
HURT: 0
helped stats (abs) min: 1 max: 9 x̄: 3.00 x̃: 2
helped stats (rel) min: 0.27% max: 13.73% x̄: 2.01% x̃: 1.09%
95% mean confidence interval for instructions value: -3.37 -2.63
95% mean confidence interval for instructions %-change: -2.76% -1.26%
Instructions are helped.

total cycles in shared programs: 122052654 -> 122051658 (<.01%)
cycles in affected programs: 387236 -> 386240 (-0.26%)
helped: 70
HURT: 1
helped stats (abs) min: 4 max: 36 x̄: 14.26 x̃: 12
helped stats (rel) min: 0.06% max: 3.19% x̄: 0.58% x̃: 0.52%
HURT stats (abs)   min: 2 max: 2 x̄: 2.00 x̃: 2
HURT stats (rel)   min: 0.09% max: 0.09% x̄: 0.09% x̃: 0.09%
95% mean confidence interval for cycles value: -15.36 -12.69
95% mean confidence interval for cycles %-change: -0.72% -0.42%
Cycles are helped.

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_nir.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index ca9b021767f..22b24f36d0e 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -772,6 +772,21 @@ brw_postprocess_nir(nir_shader *nir, const struct 
brw_compiler *compiler,
   OPT(brw_nir_opt_peephole_ffma);
}
 
+   if (OPT(nir_opt_comparison_pre)) {
+  OPT(nir_copy_prop);
+  OPT(nir_opt_dce);
+  OPT(nir_opt_cse);
+
+  /* Do the select peepehole again.  nir_opt_comparison_pre (combined with
+   * the other optimization passes) will have removed at least one
+   * instruction from one of the branches of the if-statement, so now it
+   * might be under the threshold of conversion to bcsel.
+   */
+  OPT(nir_opt_peephole_select, 0);
+  if (devinfo->gen >= 6)
+ OPT(nir_opt_peephole_select, 1);
+   }
+
OPT(nir_opt_algebraic_late);
 
OPT(nir_lower_to_source_mods);
-- 
2.

[Mesa-dev] [PATCH 1/8] nir: Document a couple instances of parent_instr

[Ian Romanick]

From: Ian Romanick 

nir_ssa_def::parent_instr and nir_src::parent_instr have the same name,
but they mean really different things.  I choose to save the next person
the hour+ that I just spent figuring that out.  Even now that I know, I
doubt I'd notice in code review that someone typed foo->parent_instr
when they actually meant foo->ssa->parent_instr.

Signed-off-by: Ian Romanick 
---
 src/compiler/nir/nir.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 5a1f79515ad..ba2a7142aa0 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -490,6 +490,7 @@ typedef struct nir_ssa_def {
/** Index into the live_in and live_out bitfields */
unsigned live_index;
 
+   /** Instruction whose result is this SSA value. */
nir_instr *parent_instr;
 
/** set of nir_instrs where this register is used (read from) */
@@ -529,6 +530,7 @@ struct nir_if;
 
 typedef struct nir_src {
union {
+  /** Instruction that consumes this value as a source. */
   nir_instr *parent_instr;
   struct nir_if *parent_if;
};
-- 
2.14.4

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

[Mesa-dev] [Bug 106774] GLSL IR copy propagates loads of SSBOs

[bugzilla-daemon]

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

--- Comment #11 from Caio Marcelo de Oliveira Filho  
---
Even with the fixes to the GLSL copy propagation (and other passes) logic, the
shader was still hanging. After a debugging session with Jason, he figured that
the helper invocations were not making progress, getting into an infinite loop.

While the reads of value give correct values, the result from atomicCompareSwap
is undefined for helper invocations, and comparing two was always failing.

The alternative version of the test in the report (the one that works), avoids
this issue since the return value for atomicCompareSwap seems to be always the
same (although not something we should rely on, I guess), allowing the loop to
end.

Early returning based on gl_HelperInvocation makes things work with the
original loop, but depends on newer GL version.

-- 
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 5/7] i965/screen: Don't advertise support for RG formats

[Jason Ekstrand]

On Wed, Jun 6, 2018 at 1:25 PM, Daniel Stone  wrote:

> We definitely do, but I assume it's not been tested recently ...


Ok, Lionel's patch it is then. :)


> (Sorry about mangled formatting)
>

Wow, you managed to mangle it bad... No worries though; I have to talk to
plenty of Outlook users every day. :P

--Jason



> On Wed, 6 Jun 2018, 8:42 pm Jason Ekstrand,  wrote:
>
>> On June 6, 2018 12:37:58 Daniel Stone  wrote:
>>
>>> Right, it's a feature we use, because we do all import them as separate
>>> EGLImages ... and we won't if it's not advertised.
>>
>>
>> I'm a bit skeptical given that it doesn't actually work today because the
>> DRI format to Mesa format conversation function doesn't handle R it RG
>> formats today.  Maybe it goes through some other path?
>>
>> In any case, I'm happy to drop this patch in favor of Lionel's patch to
>> make the DRI format to Mesa format conversation function actually work for
>> these formats.
>>
>> --Jason
>>
>>
>>
>>> On Wed, 6 Jun 2018, 7:05 pm Jason Ekstrand, 
>>> wrote:
>>>
 On Wed, Jun 6, 2018 at 11:03 AM, Jason Ekstrand 
 wrote:

> On Wed, Jun 6, 2018 at 11:00 AM, Daniel Stone 
> wrote:
>
>> Sorry, but as written this will regress ability to import NV12 images
>> as separately-addressed planes with shader conversion to RGB; Kodi, 
>> Mutter
>> and Weston all use this.
>>
>
> I don't believe it will.  It only makes it so that we don't advertise
> R and RG formats through eglQueryDmaBufFormatsEXT.  This means that you
> can't import the planes each as separate images but you can still import a
> planar image.
>

 Arguably, though, importing the planes as separate images does sound
 like a feature...



> --Jason
>
>
>
>> On Wed, 6 Jun 2018, 6:48 pm Jason Ekstrand, 
>> wrote:
>>
>>> Cc: mesa-sta...@lists.freedesktop.org
>>> ---
>>>  src/mesa/drivers/dri/i965/intel_screen.c | 12 
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>>> b/src/mesa/drivers/dri/i965/intel_screen.c
>>> index 5f0eeb41779..f681b221e7b 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>>> @@ -1269,6 +1269,18 @@ intel_image_format_is_supported(const struct
>>> intel_image_format *fmt)
>>> fmt->fourcc == __DRI_IMAGE_FOURCC_SABGR)
>>>return false;
>>>
>>> +   /* The dri_interface.h file says:
>>> +*
>>> +*"R8, GR88 and NONE should not be used with
>>> createImageFromName or
>>> +*createImage, and are returned by query from sub images
>>> created with
>>> +*createImageFromNames (NONE, see above) and fromPlane (R8 &
>>> GR88)."
>>> +*
>>> +* Let's not advertise support for R or RG formats.
>>> +*/
>>> +   if (fmt->components == __DRI_IMAGE_COMPONENTS_R ||
>>> +   fmt->components == __DRI_IMAGE_COMPONENTS_RG)
>>> +  return false;
>>> +
>>> return true;
>>>  }
>>>
>>> --
>>> 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 106843] GLES support and osmesa cannot be built together using Scons and MSVC

[bugzilla-daemon]

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

--- Comment #1 from Alex Granni  ---
I was able to replicate this with Mesa master too.

-- 
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 5/7] i965/screen: Don't advertise support for RG formats

[Daniel Stone]

We definitely do, but I assume it's not been tested recently ...

(Sorry about mangled formatting)

On Wed, 6 Jun 2018, 8:42 pm Jason Ekstrand,  wrote:

> On June 6, 2018 12:37:58 Daniel Stone  wrote:
>
>> Right, it's a feature we use, because we do all import them as separate
>> EGLImages ... and we won't if it's not advertised.
>
>
> I'm a bit skeptical given that it doesn't actually work today because the
> DRI format to Mesa format conversation function doesn't handle R it RG
> formats today.  Maybe it goes through some other path?
>
> In any case, I'm happy to drop this patch in favor of Lionel's patch to
> make the DRI format to Mesa format conversation function actually work for
> these formats.
>
> --Jason
>
>
>
>> On Wed, 6 Jun 2018, 7:05 pm Jason Ekstrand,  wrote:
>>
>>> On Wed, Jun 6, 2018 at 11:03 AM, Jason Ekstrand 
>>> wrote:
>>>
 On Wed, Jun 6, 2018 at 11:00 AM, Daniel Stone 
 wrote:

> Sorry, but as written this will regress ability to import NV12 images
> as separately-addressed planes with shader conversion to RGB; Kodi, Mutter
> and Weston all use this.
>

 I don't believe it will.  It only makes it so that we don't advertise R
 and RG formats through eglQueryDmaBufFormatsEXT.  This means that you can't
 import the planes each as separate images but you can still import a planar
 image.

>>>
>>> Arguably, though, importing the planes as separate images does sound
>>> like a feature...
>>>
>>>
>>>
 --Jason



> On Wed, 6 Jun 2018, 6:48 pm Jason Ekstrand, 
> wrote:
>
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>  src/mesa/drivers/dri/i965/intel_screen.c | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>> b/src/mesa/drivers/dri/i965/intel_screen.c
>> index 5f0eeb41779..f681b221e7b 100644
>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>> @@ -1269,6 +1269,18 @@ intel_image_format_is_supported(const struct
>> intel_image_format *fmt)
>> fmt->fourcc == __DRI_IMAGE_FOURCC_SABGR)
>>return false;
>>
>> +   /* The dri_interface.h file says:
>> +*
>> +*"R8, GR88 and NONE should not be used with
>> createImageFromName or
>> +*createImage, and are returned by query from sub images
>> created with
>> +*createImageFromNames (NONE, see above) and fromPlane (R8 &
>> GR88)."
>> +*
>> +* Let's not advertise support for R or RG formats.
>> +*/
>> +   if (fmt->components == __DRI_IMAGE_COMPONENTS_R ||
>> +   fmt->components == __DRI_IMAGE_COMPONENTS_RG)
>> +  return false;
>> +
>> return true;
>>  }
>>
>> --
>> 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

Re: [Mesa-dev] [PATCH v4 00/15] TGSI: improved live range tracking, also including arrays

[Benedikt Schemmer]

Hi Gert, Hi Nicolai,

I did play around with this quite a lot (mostly with the previous version) and 
found it to be
stable (doesn't crash deus ex on start up from cold shader cache like NIR) or 
leak memory
like llvm 7 (at least used to leak ~100MB with piglit shaders,
haven't given it another try in the last two weeks).

The arrays-of-arrays piglit shaders I sent you still crash though Gert.

On radeonsi it is mostly (or probably entirely) useless ;)
But it does have an interesting property when I tweak it (see below), results 
of today with v4 and llvm 6:

 BIGGEST IMPROVEMENTS - Max Waves
 Before After Delta Percentage
  3 8 5  166.67 %   
../shader-db/shaders/piglit/988eefdf4bb05e5a3ecc4a5c0b4c4ef54047a5a9_4.shader_test
 [1]
  5 7 2   40.00 %   
../shader-db/shaders/ruiner/0967c5fce7fc456496b1cfa25fbb1d1c4dcf9bed_2958.shader_test
 [0]
  5 7 2   40.00 %   ../shader-db/shaders/cat/1847.shader_test 
[0]
  6 7 1   16.67 %   
../shader-db/shaders/serioussam2017/2160.shader_test [0]
  6 7 1   16.67 %   
../shader-db/shaders/serioussam2017/f1e9a7f8bb8be17b8231116cf68bc10677769709_2149.shader_test
 [0]
  1 2 1  100.00 %   
../shader-db/shaders/deusex_mankind/5b1006a267c95f5c245266d82699d53cad704aab_4008.shader_test
 [0]
  1 2 1  100.00 %   
../shader-db/shaders/deusex_mankind/14060e8c592408bb9b6059b27a72eeb1e66c7480_8288.shader_test
 [0]
  1 2 1  100.00 %   
../shader-db/shaders/deusex_mankind/cb6356f4da76e5a82d6036e811c680ae00249c68_994.shader_test
 [0]

PERCENTAGE DELTASShaders SGPRs VGPRs SpillSGPR SpillVGPR  PrivVGPR  
 Scratch  CodeSize  MaxWaves Waits
All affected 630   -6.28 %   -1.19 %   -0.07 % . .  
   .0.02 %0.42 % .

No regressions with max waves otherwise (but of course I don't own every game 
and
even from those I don't have a shaderdump of every one of them).

But still, from the values I found there may be an opportunity for an 
'intermediate range'
optimization somewhere.

Cheers,
Benedikt


---

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -5533,21 +5533,22 @@ glsl_to_tgsi_visitor::merge_registers(void)
}


-   if (get_temp_registers_required_live_ranges(reg_live_ranges, 
&this->instructions,
+//   if (get_temp_registers_required_live_ranges(reg_live_ranges, 
&this->instructions,
+ get_temp_registers_required_live_ranges(reg_live_ranges, 
&this->instructions,
this->next_temp, 
reg_live_ranges,
-   this->next_array, 
arr_live_ranges)) {
+   this->next_array, 
arr_live_ranges);//) {
   struct rename_reg_pair *renames =
 rzalloc_array(reg_live_ranges, struct rename_reg_pair, 
this->next_temp);
   get_temp_registers_remapping(reg_live_ranges, this->next_temp,
reg_live_ranges, renames);
   rename_temp_registers(renames);

-  this->next_array =  merge_arrays(this->next_array, this->array_sizes,
-   &this->instructions, arr_live_ranges);
+//  this->next_array =  merge_arrays(this->next_array, this->array_sizes,
+//   &this->instructions, arr_live_ranges);

   if (arr_live_ranges)
  delete[] arr_live_ranges;
-   }
+//   }
ralloc_free(reg_live_ranges);
 }

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
--- a/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
@@ -1330,6 +1330,24 @@ static int register_merge_record_compare (const void *a, 
const void *b) {
 }
 #endif

+/* these magic numbers are determined by looking at the results of shader-db */
+bool should_merge (int distance)
+{
+   switch (distance) {
+   case 12 ... 126: //lower bound interfering with llvm?, upper bound here
+   case 244 ... 768: // and lower bound here determined by one regressing 
tombraider shader
+// nothing to see here
+   case 2432 ... 2496: // purely empiricily determined
+   case 2497 ... 2623: // Deus Ex
+   case 2624 ... 2688:
+// case 2689 ... 2943: // causes regressions in ubershaders
+   case 2944 ... 3072: // above isnt used
+  return true;
+   default:
+  return false;
+   }
+}
+
 /* This functions evaluates the register merges by using a binary
  * search to find suitable merge candidates. */
 void get_temp_registers_remapping(void *mem_ctx, int ntemps,
@@ -1361,10 +1379,18 @@ void get_temp_registers_remapping(void *mem_ctx, int 
ntemps,
register_merge_record *first_erase = reg_access_en

[Mesa-dev] [PATCH 6/6] glsl: fix function inlining with opaque parameters

[Rhys Perry]

Signed-off-by: Rhys Perry 
---
 src/compiler/glsl/opt_function_inlining.cpp | 52 -
 1 file changed, 44 insertions(+), 8 deletions(-)

diff --git a/src/compiler/glsl/opt_function_inlining.cpp 
b/src/compiler/glsl/opt_function_inlining.cpp
index 04690b6cf4..52f57da936 100644
--- a/src/compiler/glsl/opt_function_inlining.cpp
+++ b/src/compiler/glsl/opt_function_inlining.cpp
@@ -131,6 +131,18 @@ ir_save_lvalue_visitor::visit_enter(ir_dereference_array 
*deref)
return visit_stop;
 }
 
+static bool
+should_replace_variable(ir_variable *sig_param, ir_rvalue *param) {
+   /* For opaque types, we want the inlined variable references
+* referencing the passed in variable, since that will have
+* the location information, which an assignment of an opaque
+* variable wouldn't.
+*/
+   return sig_param->type->contains_opaque() &&
+  param->is_dereference() &&
+  sig_param->data.mode == ir_var_function_in;
+}
+
 void
 ir_call::generate_inline(ir_instruction *next_ir)
 {
@@ -155,12 +167,8 @@ ir_call::generate_inline(ir_instruction *next_ir)
   ir_rvalue *param = (ir_rvalue *) actual_node;
 
   /* Generate a new variable for the parameter. */
-  if (sig_param->type->contains_opaque()) {
-/* For opaque types, we want the inlined variable references
- * referencing the passed in variable, since that will have
- * the location information, which an assignment of an opaque
- * variable wouldn't.  Fix it up below.
- */
+  if (should_replace_variable(sig_param, param)) {
+ /* Actual replacement happens below */
 parameters[i] = NULL;
   } else {
 parameters[i] = sig_param->clone(ctx, ht);
@@ -242,10 +250,9 @@ ir_call::generate_inline(ir_instruction *next_ir)
   ir_rvalue *const param = (ir_rvalue *) actual_node;
   ir_variable *sig_param = (ir_variable *) formal_node;
 
-  if (sig_param->type->contains_opaque()) {
+  if (should_replace_variable(sig_param, param)) {
 ir_dereference *deref = param->as_dereference();
 
-assert(deref);
 do_variable_replacement(&new_instructions, sig_param, deref);
   }
}
@@ -351,6 +358,9 @@ public:
virtual ir_visitor_status visit_leave(ir_dereference_array *);
virtual ir_visitor_status visit_leave(ir_dereference_record *);
virtual ir_visitor_status visit_leave(ir_texture *);
+   virtual ir_visitor_status visit_leave(ir_assignment *);
+   virtual ir_visitor_status visit_leave(ir_expression *);
+   virtual ir_visitor_status visit_leave(ir_return *);
 
void replace_deref(ir_dereference **deref);
void replace_rvalue(ir_rvalue **rvalue);
@@ -391,6 +401,32 @@ ir_variable_replacement_visitor::visit_leave(ir_texture 
*ir)
return visit_continue;
 }
 
+ir_visitor_status
+ir_variable_replacement_visitor::visit_leave(ir_assignment *ir)
+{
+   replace_deref(&ir->lhs);
+   replace_rvalue(&ir->rhs);
+
+   return visit_continue;
+}
+
+ir_visitor_status
+ir_variable_replacement_visitor::visit_leave(ir_expression *ir)
+{
+   for (uint8_t i = 0; i < ir->num_operands; i++)
+  replace_rvalue(&ir->operands[i]);
+
+   return visit_continue;
+}
+
+ir_visitor_status
+ir_variable_replacement_visitor::visit_leave(ir_return *ir)
+{
+   replace_rvalue(&ir->value);
+
+   return visit_continue;
+}
+
 ir_visitor_status
 ir_variable_replacement_visitor::visit_leave(ir_dereference_array *ir)
 {
-- 
2.14.4

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

[Mesa-dev] [PATCH 4/6] glsl: allow ?: operator with images and samplers when bindless is enabled

[Rhys Perry]

Signed-off-by: Rhys Perry 
---
 src/compiler/glsl/ast_to_hir.cpp | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 3bf581571e..8a7dd62506 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -1850,9 +1850,11 @@ ast_expression::do_hir(exec_list *instructions,
*   expressions; such use results in a compile-time error."
*/
   if (type->contains_opaque()) {
- _mesa_glsl_error(&loc, state, "opaque variables cannot be operands "
-  "of the ?: operator");
- error_emitted = true;
+ if (!(state->has_bindless() && (type->is_image() || 
type->is_sampler( {
+_mesa_glsl_error(&loc, state, "variables of type %s cannot be "
+ "operands of the ?: operator", type->name);
+error_emitted = true;
+ }
   }
 
   ir_constant *cond_val = op[0]->constant_expression_value(ctx);
-- 
2.14.4

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

[Mesa-dev] [PATCH 2/6] nv50/ir: add support for SAMP2HND on gk104+ and IMG2HND on gm107+

[Rhys Perry]

Signed-off-by: Rhys Perry 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir.cpp|  2 ++
 src/gallium/drivers/nouveau/codegen/nv50_ir.h  |  2 ++
 .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  | 22 +++
 .../drivers/nouveau/codegen/nv50_ir_inlines.h  |  4 ++--
 .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp  | 25 ++
 .../nouveau/codegen/nv50_ir_lowering_nvc0.h|  1 +
 .../drivers/nouveau/codegen/nv50_ir_print.cpp  |  2 ++
 .../drivers/nouveau/codegen/nv50_ir_target.cpp |  7 +++---
 8 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
index c987da9908..7c1c76a912 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
@@ -903,6 +903,8 @@ TexInstruction::TexInstruction(Function *fn, operation op)
 
if (op == OP_TXF)
   sType = TYPE_U32;
+   if (op == OP_SAMP2HND || op == OP_IMG2HND)
+  setType(TYPE_U32);
 }
 
 TexInstruction::~TexInstruction()
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h 
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index f4f3c70888..97aa8d1109 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -134,6 +134,8 @@ enum operation
OP_SUCLAMP, // clamp surface coordinates
OP_SUEAU,   // surface effective address
OP_SUQ, // surface query
+   OP_SAMP2HND, // convert bound texture to bindless handle
+   OP_IMG2HND, // convert bound image to bindless handle
OP_MADSP,   // special integer multiply-add
OP_TEXBAR, // texture dependency barrier
OP_DFDX,
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index 3c5bad05fe..8149c72dd1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -3570,6 +3570,28 @@ Converter::handleInstruction(const struct 
tgsi_full_instruction *insn)
   handleTXQ(dst0, TXQ_TYPE, 0);
   std::swap(dst0[0], dst0[2]);
   break;
+   case TGSI_OPCODE_IMG2HND:
+   case TGSI_OPCODE_SAMP2HND:
+  if (!tgsi.getDst(0).isMasked(1))
+ mkOp1(OP_MOV, TYPE_U32, dst0[1], mkImm(0));
+
+  if (!tgsi.getDst(0).isMasked(0)) {
+ bool is_image = tgsi.getOpcode() == TGSI_OPCODE_IMG2HND;
+
+ TexInstruction *texi = new_TexInstruction(
+func, is_image ? OP_IMG2HND : OP_SAMP2HND);
+ texi->setDef(0, dst0[0]);
+ if (is_image)
+texi->tex.target = tgsi.getImageTarget();
+ else
+texi->tex.target = tgsi.getTexture(code, 0);
+ texi->tex.r = tgsi.getSrc(0).getIndex(0);
+ if (tgsi.getSrc(0).isIndirect(0))
+texi->setIndirectR(fetchSrc(tgsi.getSrc(0).getIndirect(0), 0, 
NULL));
+
+ bb->insertTail(texi);
+  }
+  break;
case TGSI_OPCODE_FBFETCH:
   handleFBFETCH(dst0);
   break;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h
index 4cb53ab42e..0262ae9d1f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h
@@ -311,14 +311,14 @@ const FlowInstruction *Instruction::asFlow() const
 
 TexInstruction *Instruction::asTex()
 {
-   if ((op >= OP_TEX && op <= OP_SULEA) || op == OP_SUQ)
+   if ((op >= OP_TEX && op <= OP_SULEA) || (op >= OP_SUQ && op <= OP_IMG2HND))
   return static_cast(this);
return NULL;
 }
 
 const TexInstruction *Instruction::asTex() const
 {
-   if ((op >= OP_TEX && op <= OP_SULEA) || op == OP_SUQ)
+   if ((op >= OP_TEX && op <= OP_SULEA) || (op >= OP_SUQ && op <= OP_IMG2HND))
   return static_cast(this);
return NULL;
 }
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 29f674b451..c2cc120147 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -1347,6 +1347,27 @@ NVC0LoweringPass::handleBUFQ(Instruction *bufq)
return true;
 }
 
+bool
+NVC0LoweringPass::handle2HND(TexInstruction *i)
+{
+   assert(targ->getChipset() >= NVISA_GK104_CHIPSET);
+   assert(!i->tex.bindless);
+   bool is_sampler = i->op == OP_SAMP2HND;
+
+   if (is_sampler || targ->getChipset() >= NVISA_GM107_CHIPSET) {
+  //Sampler or image on GM107+
+  uint16_t slot = (is_sampler ? 0 : 32) + i->tex.r;
+  Value *hnd = loadTexHandle(i->getIndirectR(), slot);
+  bld.mkOp1(OP_MOV, TYPE_U32, i->getDef(0), hnd);
+   } else {
+  //Image on NVE4/GK104
+  assert(!"not implemented"); // TODO: Implement for NVE4
+   }
+
+   bld.getBB()->remove(i);
+   return true;
+}
+
 void
 NVC0LoweringPass::handleSharedATOMNVE4(In

[Mesa-dev] [PATCH 5/6] glsl, glsl_to_tgsi: fix sampler/image constants

[Rhys Perry]

Signed-off-by: Rhys Perry 
---
 src/compiler/glsl/ir.cpp   | 32 --
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 14 ++---
 2 files changed, 41 insertions(+), 5 deletions(-)

diff --git a/src/compiler/glsl/ir.cpp b/src/compiler/glsl/ir.cpp
index e3134eaa1c..1d1a56ae9a 100644
--- a/src/compiler/glsl/ir.cpp
+++ b/src/compiler/glsl/ir.cpp
@@ -820,6 +820,10 @@ ir_constant::ir_constant(const struct glsl_type *type, 
exec_list *value_list)
for (unsigned i = 0; i < type->components(); i++)
   this->value.b[i] = value->value.b[0];
break;
+case GLSL_TYPE_SAMPLER:
+case GLSL_TYPE_IMAGE:
+   this->value.u64[0] = value->value.u64[0];
+   break;
 default:
assert(!"Should not get here.");
break;
@@ -939,6 +943,8 @@ ir_constant::get_bool_component(unsigned i) const
case GLSL_TYPE_FLOAT: return ((int)this->value.f[i]) != 0;
case GLSL_TYPE_BOOL:  return this->value.b[i];
case GLSL_TYPE_DOUBLE: return this->value.d[i] != 0.0;
+   case GLSL_TYPE_SAMPLER:
+   case GLSL_TYPE_IMAGE:
case GLSL_TYPE_UINT64: return this->value.u64[i] != 0;
case GLSL_TYPE_INT64:  return this->value.i64[i] != 0;
default:  assert(!"Should not get here."); break;
@@ -959,6 +965,8 @@ ir_constant::get_float_component(unsigned i) const
case GLSL_TYPE_FLOAT: return this->value.f[i];
case GLSL_TYPE_BOOL:  return this->value.b[i] ? 1.0f : 0.0f;
case GLSL_TYPE_DOUBLE: return (float) this->value.d[i];
+   case GLSL_TYPE_SAMPLER:
+   case GLSL_TYPE_IMAGE:
case GLSL_TYPE_UINT64: return (float) this->value.u64[i];
case GLSL_TYPE_INT64:  return (float) this->value.i64[i];
default:  assert(!"Should not get here."); break;
@@ -979,6 +987,8 @@ ir_constant::get_double_component(unsigned i) const
case GLSL_TYPE_FLOAT: return (double) this->value.f[i];
case GLSL_TYPE_BOOL:  return this->value.b[i] ? 1.0 : 0.0;
case GLSL_TYPE_DOUBLE: return this->value.d[i];
+   case GLSL_TYPE_SAMPLER:
+   case GLSL_TYPE_IMAGE:
case GLSL_TYPE_UINT64: return (double) this->value.u64[i];
case GLSL_TYPE_INT64:  return (double) this->value.i64[i];
default:  assert(!"Should not get here."); break;
@@ -999,6 +1009,8 @@ ir_constant::get_int_component(unsigned i) const
case GLSL_TYPE_FLOAT: return (int) this->value.f[i];
case GLSL_TYPE_BOOL:  return this->value.b[i] ? 1 : 0;
case GLSL_TYPE_DOUBLE: return (int) this->value.d[i];
+   case GLSL_TYPE_SAMPLER:
+   case GLSL_TYPE_IMAGE:
case GLSL_TYPE_UINT64: return (int) this->value.u64[i];
case GLSL_TYPE_INT64:  return (int) this->value.i64[i];
default:  assert(!"Should not get here."); break;
@@ -1019,6 +1031,8 @@ ir_constant::get_uint_component(unsigned i) const
case GLSL_TYPE_FLOAT: return (unsigned) this->value.f[i];
case GLSL_TYPE_BOOL:  return this->value.b[i] ? 1 : 0;
case GLSL_TYPE_DOUBLE: return (unsigned) this->value.d[i];
+   case GLSL_TYPE_SAMPLER:
+   case GLSL_TYPE_IMAGE:
case GLSL_TYPE_UINT64: return (unsigned) this->value.u64[i];
case GLSL_TYPE_INT64:  return (unsigned) this->value.i64[i];
default:  assert(!"Should not get here."); break;
@@ -1039,6 +1053,8 @@ ir_constant::get_int64_component(unsigned i) const
case GLSL_TYPE_FLOAT: return (int64_t) this->value.f[i];
case GLSL_TYPE_BOOL:  return this->value.b[i] ? 1 : 0;
case GLSL_TYPE_DOUBLE: return (int64_t) this->value.d[i];
+   case GLSL_TYPE_SAMPLER:
+   case GLSL_TYPE_IMAGE:
case GLSL_TYPE_UINT64: return (int64_t) this->value.u64[i];
case GLSL_TYPE_INT64:  return this->value.i64[i];
default:  assert(!"Should not get here."); break;
@@ -1059,6 +1075,8 @@ ir_constant::get_uint64_component(unsigned i) const
case GLSL_TYPE_FLOAT: return (uint64_t) this->value.f[i];
case GLSL_TYPE_BOOL:  return this->value.b[i] ? 1 : 0;
case GLSL_TYPE_DOUBLE: return (uint64_t) this->value.d[i];
+   case GLSL_TYPE_SAMPLER:
+   case GLSL_TYPE_IMAGE:
case GLSL_TYPE_UINT64: return this->value.u64[i];
case GLSL_TYPE_INT64:  return (uint64_t) this->value.i64[i];
default:  assert(!"Should not get here."); break;
@@ -1110,6 +1128,8 @@ ir_constant::copy_offset(ir_constant *src, int offset)
case GLSL_TYPE_INT:
case GLSL_TYPE_FLOAT:
case GLSL_TYPE_DOUBLE:
+   case GLSL_TYPE_SAMPLER:
+   case GLSL_TYPE_IMAGE:
case GLSL_TYPE_UINT64:
case GLSL_TYPE_INT64:
case GLSL_TYPE_BOOL: {
@@ -1132,7 +1152,9 @@ ir_constant::copy_offset(ir_constant *src, int offset)
 case GLSL_TYPE_DOUBLE:
value.d[i+offset] = src->get_double_component(i);
break;
- case GLSL_TYPE_UINT64:
+case GLSL_TYPE_SAMPLER:
+case GLSL_TYPE_IMAGE:
+case GLSL_TYPE_UINT64:
value.u64[i+offset] = src->get_uint64_component(i);
break;
 case GLSL_TYP

[Mesa-dev] [PATCH 3/6] glsl_to_tgsi: allow bound samplers and images to be used as l-values

[Rhys Perry]

Signed-off-by: Rhys Perry 
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp   | 55 +++-
 src/mesa/state_tracker/st_glsl_to_tgsi_private.h |  1 +
 2 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index b321112cf8..7938753453 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -316,6 +316,7 @@ public:
   st_src_reg *indirect,
   unsigned *location);
st_src_reg canonicalize_gather_offset(st_src_reg offset);
+   bool handle_bound_deref(ir_dereference *ir);
 
bool try_emit_mad(ir_expression *ir,
   int mul_operand);
@@ -2439,10 +2440,15 @@ st_translate_interp_loc(ir_variable *var)
 void
 glsl_to_tgsi_visitor::visit(ir_dereference_variable *ir)
 {
-   variable_storage *entry = find_variable_storage(ir->var);
+   variable_storage *entry;
ir_variable *var = ir->var;
bool remove_array;
 
+   if (handle_bound_deref(ir->as_dereference()))
+  return;
+
+   entry = find_variable_storage(ir->var);
+
if (!entry) {
   switch (var->data.mode) {
   case ir_var_uniform:
@@ -2669,6 +2675,9 @@ glsl_to_tgsi_visitor::visit(ir_dereference_array *ir)
bool is_2D = false;
ir_variable *var = ir->variable_referenced();
 
+   if (handle_bound_deref(ir->as_dereference()))
+  return;
+
/* We only need the logic provided by st_glsl_storage_type_size()
 * for arrays of structs. Indirect sampler and image indexing is handled
 * elsewhere.
@@ -2768,6 +2777,9 @@ glsl_to_tgsi_visitor::visit(ir_dereference_record *ir)
ir_variable *var = ir->record->variable_referenced();
int offset = 0;
 
+   if (handle_bound_deref(ir->as_dereference()))
+  return;
+
ir->record->accept(this);
 
assert(ir->field_idx >= 0);
@@ -4110,6 +4122,45 @@ 
glsl_to_tgsi_visitor::canonicalize_gather_offset(st_src_reg offset)
 
return offset;
 }
+ 
+bool
+glsl_to_tgsi_visitor::handle_bound_deref(ir_dereference *ir)
+{
+   ir_variable *var = ir->variable_referenced();
+
+   if (!var || var->data.mode != ir_var_uniform || var->data.bindless ||
+   !(ir->type->is_image() || ir->type->is_sampler()))
+  return false;
+
+   //Convert from bound sampler/image to bindless handle
+   bool is_image = ir->type->is_image();
+   st_src_reg resource(is_image ? PROGRAM_IMAGE : PROGRAM_SAMPLER, 0, 
GLSL_TYPE_UINT);
+   uint16_t index = 0;
+   unsigned array_size = 1, base = 0;
+   st_src_reg reladdr;
+   get_deref_offsets(ir, &array_size, &base, &index, &reladdr, true);
+
+   resource.index = index;
+   if (reladdr.file != PROGRAM_UNDEFINED) {
+  resource.reladdr = ralloc(mem_ctx, st_src_reg);
+  *resource.reladdr = reladdr;
+  emit_arl(ir, sampler_reladdr, reladdr);
+   }
+
+   this->result = get_temp(glsl_type::uvec2_type);
+   st_dst_reg dst(this->result);
+   dst.writemask = WRITEMASK_XY;
+
+   glsl_to_tgsi_instruction *inst = emit_asm(
+  ir, is_image ? TGSI_OPCODE_IMG2HND : TGSI_OPCODE_SAMP2HND, dst);
+
+   inst->tex_target = ir->type->sampler_index();
+   inst->resource = resource;
+   inst->sampler_array_size = array_size;
+   inst->sampler_base = base;
+
+   return true;
+}
 
 void
 glsl_to_tgsi_visitor::visit(ir_texture *ir)
@@ -5904,6 +5955,7 @@ compile_tgsi_instruction(struct st_translate *t,
case TGSI_OPCODE_TXL2:
case TGSI_OPCODE_TG4:
case TGSI_OPCODE_LODQ:
+   case TGSI_OPCODE_SAMP2HND:
   if (inst->resource.file == PROGRAM_SAMPLER) {
  src[num_src] = t->samplers[inst->resource.index];
   } else {
@@ -5942,6 +5994,7 @@ compile_tgsi_instruction(struct st_translate *t,
case TGSI_OPCODE_ATOMUMAX:
case TGSI_OPCODE_ATOMIMIN:
case TGSI_OPCODE_ATOMIMAX:
+   case TGSI_OPCODE_IMG2HND:
   for (i = num_src - 1; i >= 0; i--)
  src[i + 1] = src[i];
   num_src++;
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_private.h 
b/src/mesa/state_tracker/st_glsl_to_tgsi_private.h
index c482828edd..fccb7041cf 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi_private.h
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi_private.h
@@ -179,6 +179,7 @@ is_resource_instruction(unsigned opcode)
case TGSI_OPCODE_ATOMUMAX:
case TGSI_OPCODE_ATOMIMIN:
case TGSI_OPCODE_ATOMIMAX:
+   case TGSI_OPCODE_IMG2HND:
   return true;
default:
   return false;
-- 
2.14.4

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

[Mesa-dev] [PATCH 1/6] gallium: add new SAMP2HND and IMG2HND opcodes

[Rhys Perry]

This commit does not add support for the opcodes in gallivm or tgsi_to_nir.c

Signed-off-by: Rhys Perry 
---
 src/gallium/auxiliary/tgsi/tgsi_info.c |  2 ++
 src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h |  4 ++--
 src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h   |  3 +++
 src/gallium/docs/source/tgsi.rst   | 25 +
 src/gallium/include/pipe/p_shader_tokens.h |  2 ++
 5 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c 
b/src/gallium/auxiliary/tgsi/tgsi_info.c
index 4aa658785c..bbe1a21e43 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_info.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
@@ -153,6 +153,8 @@ tgsi_opcode_infer_type(enum tgsi_opcode opcode)
case TGSI_OPCODE_POPC:
case TGSI_OPCODE_LSB:
case TGSI_OPCODE_UMSB:
+   case TGSI_OPCODE_IMG2HND:
+   case TGSI_OPCODE_SAMP2HND:
   return TGSI_TYPE_UNSIGNED;
case TGSI_OPCODE_ARL:
case TGSI_OPCODE_ARR:
diff --git a/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h 
b/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h
index 1b2803cf3f..c3787c2fbb 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h
@@ -162,8 +162,8 @@ OPCODE(1, 1, COMP, IABS)
 OPCODE(1, 1, COMP, ISSG)
 OPCODE(1, 2, OTHR, LOAD)
 OPCODE(1, 2, OTHR, STORE, .is_store = 1)
-OPCODE_GAP(163) /* removed */
-OPCODE_GAP(164) /* removed */
+OPCODE(1, 1, OTHR, IMG2HND)
+OPCODE(1, 1, OTHR, SAMP2HND, .is_tex = 1)
 OPCODE_GAP(165) /* removed */
 OPCODE(0, 0, OTHR, BARRIER)
 
diff --git a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h 
b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
index 9a13fa6684..54a1ee15b6 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
@@ -160,6 +160,9 @@ OP13(UCMP)
 OP11(IABS)
 OP11(ISSG)
 
+OP11(IMG2HND)
+OP11(SAMP2HND)
+
 OP12(IMUL_HI)
 OP12(UMUL_HI)
 
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 9e956586c4..a4a78e6267 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -2592,6 +2592,31 @@ For these opcodes, the resource can be a BUFFER, IMAGE, 
or MEMORY.
   barrier in between.
 
 
+.. _bindlessopcodes:
+
+Bindless Opcodes
+
+
+These opcodes are for working with bindless sampler or image handles and
+require PIPE_CAP_BINDLESS_TEXTURE.
+
+.. opcode:: IMG2HND - Get a bindless handle for a image
+
+  Syntax: ``IMG2HND dst, image``
+
+  Example: ``IMG2HND TEMP[0], IMAGE[0]``
+
+  Sets 'dst' to a bindless handle for 'image'.
+
+.. opcode:: SAMP2HND - Get a bindless handle for a sampler view
+
+  Syntax: ``SAMP2HND dst, sampler``
+
+  Example: ``SAMP2HND TEMP[0], SVIEW[0]``
+
+  Sets 'dst' to a bindless handle for 'sampler'.
+
+
 .. _threadsyncopcodes:
 
 Inter-thread synchronization opcodes
diff --git a/src/gallium/include/pipe/p_shader_tokens.h 
b/src/gallium/include/pipe/p_shader_tokens.h
index f4e45c2560..08ed08156e 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -506,6 +506,8 @@ enum tgsi_opcode {
 
TGSI_OPCODE_LOAD   = 161,
TGSI_OPCODE_STORE  = 162,
+   TGSI_OPCODE_IMG2HND= 163,
+   TGSI_OPCODE_SAMP2HND   = 164,
/* gap */
TGSI_OPCODE_BARRIER= 166,
 
-- 
2.14.4

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

[Mesa-dev] [PATCH 0/6] Fix Various Compilation Issues With Bindless

[Rhys Perry]

Previously, there were some errors in the compiler's implementation of
ARB_bindless_texture, mostly related to usage of bound image or sampler
handles allowed by ARB_bindless_texture, resulting in assertions or
compilation errors. This series fixes following issues found in mesa:
- Assertions when casting bound handles to uvec2
- Compilation errors when using the ?: operator with bound handles
- Assertions creating a constant image/sampler handle
   - For example: image2D(uvec2(5, 6))
- Inlining of function calls with rvalues other than dereferences to
  handle uniforms passed into them creates assertion failures
- Usage of bound handles as l-values

In order to create bindless handles from bound images or samplers, two new
TGSI opcodes needed to be added: SAMP2HND and IMG2HND. These are used when
casting bound handles or when using them as l-values (e.g. using them with
the ?: operator).

This series has the following limitations because I don't have the
hardware needed to test the needed changes:
- radeonsi and gallivm do not handle SAMP2HND and IMG2HND
- similar instructions/intrinsics for nir have not been added
- the tgsi to nir conversion code does not handle SAMP2HND and IMG2HND
- IMG2HND with Kepler is not implemented
Usage of bound handles as l-values and casting them is handled better than
before though.

Some tests for these changes have been posted on the piglit mailing list.

Rhys Perry (6):
  gallium: add new SAMP2HND and IMG2HND opcodes
  nv50/ir: add support for SAMP2HND on gk104+ and IMG2HND on gm107+
  glsl_to_tgsi: allow bound samplers and images to be used as l-values
  glsl: allow ?: operator with images and samplers when bindless is enabled
  glsl,glsl_to_tgsi: fix sampler/image constants
  glsl: fix function inlining with opaque parameters

 src/compiler/glsl/ast_to_hir.cpp   |  8 ++-
 src/compiler/glsl/ir.cpp   | 32 +-
 src/compiler/glsl/opt_function_inlining.cpp| 52 +---
 src/gallium/auxiliary/tgsi/tgsi_info.c |  2 +
 src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h |  4 +-
 src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h   |  3 +
 src/gallium/docs/source/tgsi.rst   | 25 
 src/gallium/drivers/nouveau/codegen/nv50_ir.cpp|  2 +
 src/gallium/drivers/nouveau/codegen/nv50_ir.h  |  2 +
 .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  | 22 +++
 .../drivers/nouveau/codegen/nv50_ir_inlines.h  |  4 +-
 .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp  | 25 
 .../nouveau/codegen/nv50_ir_lowering_nvc0.h|  1 +
 .../drivers/nouveau/codegen/nv50_ir_print.cpp  |  2 +
 .../drivers/nouveau/codegen/nv50_ir_target.cpp |  7 ++-
 src/gallium/include/pipe/p_shader_tokens.h |  2 +
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 69 --
 src/mesa/state_tracker/st_glsl_to_tgsi_private.h   |  1 +
 18 files changed, 239 insertions(+), 24 deletions(-)

-- 
2.14.4

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

Re: [Mesa-dev] [PATCH 5/7] i965/screen: Don't advertise support for RG formats

[Jason Ekstrand]

On June 6, 2018 12:37:58 Daniel Stone  wrote:
Right, it's a feature we use, because we do all import them as separate 
EGLImages ... and we won't if it's not advertised.



I'm a bit skeptical given that it doesn't actually work today because the 
DRI format to Mesa format conversation function doesn't handle R it RG 
formats today.  Maybe it goes through some other path?


In any case, I'm happy to drop this patch in favor of Lionel's patch to 
make the DRI format to Mesa format conversation function actually work for 
these formats.


--Jason




On Wed, 6 Jun 2018, 7:05 pm Jason Ekstrand,  wrote:
On Wed, Jun 6, 2018 at 11:03 AM, Jason Ekstrand  wrote:
On Wed, Jun 6, 2018 at 11:00 AM, Daniel Stone  wrote:
Sorry, but as written this will regress ability to import NV12 images as 
separately-addressed planes with shader conversion to RGB; Kodi, Mutter and 
Weston all use this.


I don't believe it will.  It only makes it so that we don't advertise R and 
RG formats through eglQueryDmaBufFormatsEXT.  This means that you can't 
import the planes each as separate images but you can still import a planar 
image.


Arguably, though, importing the planes as separate images does sound like a 
feature...



--Jason


On Wed, 6 Jun 2018, 6:48 pm Jason Ekstrand,  wrote:
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/intel_screen.c | 12 
1 file changed, 12 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c

index 5f0eeb41779..f681b221e7b 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1269,6 +1269,18 @@ intel_image_format_is_supported(const struct 
intel_image_format *fmt)

   fmt->fourcc == __DRI_IMAGE_FOURCC_SABGR)
  return false;

+   /* The dri_interface.h file says:
+*
+*"R8, GR88 and NONE should not be used with createImageFromName or
+*createImage, and are returned by query from sub images created with
+*createImageFromNames (NONE, see above) and fromPlane (R8 & GR88)."
+*
+* Let's not advertise support for R or RG formats.
+*/
+   if (fmt->components == __DRI_IMAGE_COMPONENTS_R ||
+   fmt->components == __DRI_IMAGE_COMPONENTS_RG)
+  return false;
+
   return true;
}

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

Re: [Mesa-dev] [PATCH 5/7] i965/screen: Don't advertise support for RG formats

[Daniel Stone]

Right, it's a feature we use, because we do all import them as separate
EGLImages ... and we won't if it's not advertised.

On Wed, 6 Jun 2018, 7:05 pm Jason Ekstrand,  wrote:

> On Wed, Jun 6, 2018 at 11:03 AM, Jason Ekstrand 
> wrote:
>
>> On Wed, Jun 6, 2018 at 11:00 AM, Daniel Stone 
>> wrote:
>>
>>> Sorry, but as written this will regress ability to import NV12 images as
>>> separately-addressed planes with shader conversion to RGB; Kodi, Mutter and
>>> Weston all use this.
>>>
>>
>> I don't believe it will.  It only makes it so that we don't advertise R
>> and RG formats through eglQueryDmaBufFormatsEXT.  This means that you can't
>> import the planes each as separate images but you can still import a planar
>> image.
>>
>
> Arguably, though, importing the planes as separate images does sound like
> a feature...
>
>
>
>> --Jason
>>
>>
>>
>>> On Wed, 6 Jun 2018, 6:48 pm Jason Ekstrand, 
>>> wrote:
>>>
 Cc: mesa-sta...@lists.freedesktop.org
 ---
  src/mesa/drivers/dri/i965/intel_screen.c | 12 
  1 file changed, 12 insertions(+)

 diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
 b/src/mesa/drivers/dri/i965/intel_screen.c
 index 5f0eeb41779..f681b221e7b 100644
 --- a/src/mesa/drivers/dri/i965/intel_screen.c
 +++ b/src/mesa/drivers/dri/i965/intel_screen.c
 @@ -1269,6 +1269,18 @@ intel_image_format_is_supported(const struct
 intel_image_format *fmt)
 fmt->fourcc == __DRI_IMAGE_FOURCC_SABGR)
return false;

 +   /* The dri_interface.h file says:
 +*
 +*"R8, GR88 and NONE should not be used with
 createImageFromName or
 +*createImage, and are returned by query from sub images
 created with
 +*createImageFromNames (NONE, see above) and fromPlane (R8 &
 GR88)."
 +*
 +* Let's not advertise support for R or RG formats.
 +*/
 +   if (fmt->components == __DRI_IMAGE_COMPONENTS_R ||
 +   fmt->components == __DRI_IMAGE_COMPONENTS_RG)
 +  return false;
 +
 return true;
  }

 --
 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 106842] Error de prueba

[bugzilla-daemon]

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

Adam Jackson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Adam Jackson  ---
This bug has no data.

-- 
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 mesa 1/3] egl: rewire the build systems to use libwayland-egl

[Matt Turner]

On Tue, May 29, 2018 at 7:41 AM, Eric Engestrom
 wrote:
> Cc: Emil Velikov 
> Cc: Daniel Stone 
> Signed-off-by: Eric Engestrom 
> ---

I just pushed this series. Thanks!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106843] GLES support and osmesa cannot be built together using Scons and MSVC

[bugzilla-daemon]

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

Bug ID: 106843
   Summary: GLES support and osmesa cannot be built together using
Scons and MSVC
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: liviupro...@yahoo.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 140056
  --> https://bugs.freedesktop.org/attachment.cgi?id=140056&action=edit
Build attempt log (64-bit)

If I try to build osmesa and GLES support is enabled, Mesa build fails with
unresolved symbols. It doesn't matter if I add extra targets like libg-gdi,
graw-gdi or swr or not. RQeproduced with both 32-bit and 64-bit builds on Mesa
18.1.1 with Visual Studio 15.7,3 and Windows SDK 10.0.17134.12

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

[Mesa-dev] [Bug 106842] Error de prueba

[bugzilla-daemon]

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

Bug ID: 106842
   Summary: Error de prueba
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Demos
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: parak_noti...@hotmail.com
QA Contact: mesa-dev@lists.freedesktop.org

-- 
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] mesa/program_binary: add implicit UseProgram after successful ProgramBinary

[Plamena Manolova]

This looks good to me :)

Reviewed-by: Plamena Manolova 

On Wed, 6 Jun 2018 at 18:51, Jordan Justen 
wrote:

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106810
> Fixes: b4c37ce2140 "i965: Add ARB_get_program_binary support using
> nir_serialization"
> Ref: 3fe8d04a6d6 "mesa: don't always set _NEW_PROGRAM when linking"
> Ref: c505d6d8522 "mesa: use gl_program for CurrentProgram rather than
> gl_shader_program"
> Cc: Timothy Arceri 
> Cc: 
> Signed-off-by: Jordan Justen 
> ---
>  src/mesa/main/program_binary.c | 33 +
>  1 file changed, 33 insertions(+)
>
> diff --git a/src/mesa/main/program_binary.c
> b/src/mesa/main/program_binary.c
> index 021f6315e72..f4aa57821c8 100644
> --- a/src/mesa/main/program_binary.c
> +++ b/src/mesa/main/program_binary.c
> @@ -33,6 +33,8 @@
>  #include "compiler/glsl/serialize.h"
>  #include "main/errors.h"
>  #include "main/mtypes.h"
> +#include "main/shaderapi.h"
> +#include "util/bitscan.h"
>  #include "util/crc32.h"
>  #include "program_binary.h"
>  #include "program/prog_parameter.h"
> @@ -282,10 +284,41 @@ _mesa_program_binary(struct gl_context *ctx, struct
> gl_shader_program *sh_prog,
> struct blob_reader blob;
> blob_reader_init(&blob, payload, length - header_size);
>
> +   unsigned programs_in_use = 0;
> +   if (ctx->_Shader)
> +  for (unsigned stage = 0; stage < MESA_SHADER_STAGES; stage++) {
> + if (ctx->_Shader->CurrentProgram[stage] &&
> + ctx->_Shader->CurrentProgram[stage]->Id == sh_prog->Name) {
> +programs_in_use |= 1 << stage;
> + }
> +   }
> +
> if (!read_program_payload(ctx, &blob, binary_format, sh_prog)) {
>sh_prog->data->LinkStatus = LINKING_FAILURE;
>return;
> }
>
> +   /* From section 7.3 (Program Objects) of the OpenGL 4.5 spec:
> +*
> +*"If LinkProgram or ProgramBinary successfully re-links a program
> +* object that is active for any shader stage, then the newly
> generated
> +* executable code will be installed as part of the current
> rendering
> +* state for all shader stages where the program is active.
> +* Additionally, the newly generated executable code is made part
> of
> +* the state of any program pipeline for all stages where the
> program
> +* is attached."
> +*/
> +   if (programs_in_use) {
> +  while (programs_in_use) {
> + const int stage = u_bit_scan(&programs_in_use);
> +
> + struct gl_program *prog = NULL;
> + if (sh_prog->_LinkedShaders[stage])
> +prog = sh_prog->_LinkedShaders[stage]->Program;
> +
> + _mesa_use_program(ctx, stage, sh_prog, prog, ctx->_Shader);
> +  }
> +   }
> +
> sh_prog->data->LinkStatus = LINKING_SKIPPED;
>  }
> --
> 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

Re: [Mesa-dev] [PATCH 5/7] i965/screen: Don't advertise support for RG formats

[Jason Ekstrand]

On Wed, Jun 6, 2018 at 11:03 AM, Jason Ekstrand 
wrote:

> On Wed, Jun 6, 2018 at 11:00 AM, Daniel Stone 
> wrote:
>
>> Sorry, but as written this will regress ability to import NV12 images as
>> separately-addressed planes with shader conversion to RGB; Kodi, Mutter and
>> Weston all use this.
>>
>
> I don't believe it will.  It only makes it so that we don't advertise R
> and RG formats through eglQueryDmaBufFormatsEXT.  This means that you can't
> import the planes each as separate images but you can still import a planar
> image.
>

Arguably, though, importing the planes as separate images does sound like a
feature...



> --Jason
>
>
>
>> On Wed, 6 Jun 2018, 6:48 pm Jason Ekstrand,  wrote:
>>
>>> Cc: mesa-sta...@lists.freedesktop.org
>>> ---
>>>  src/mesa/drivers/dri/i965/intel_screen.c | 12 
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>>> b/src/mesa/drivers/dri/i965/intel_screen.c
>>> index 5f0eeb41779..f681b221e7b 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>>> @@ -1269,6 +1269,18 @@ intel_image_format_is_supported(const struct
>>> intel_image_format *fmt)
>>> fmt->fourcc == __DRI_IMAGE_FOURCC_SABGR)
>>>return false;
>>>
>>> +   /* The dri_interface.h file says:
>>> +*
>>> +*"R8, GR88 and NONE should not be used with createImageFromName
>>> or
>>> +*createImage, and are returned by query from sub images created
>>> with
>>> +*createImageFromNames (NONE, see above) and fromPlane (R8 &
>>> GR88)."
>>> +*
>>> +* Let's not advertise support for R or RG formats.
>>> +*/
>>> +   if (fmt->components == __DRI_IMAGE_COMPONENTS_R ||
>>> +   fmt->components == __DRI_IMAGE_COMPONENTS_RG)
>>> +  return false;
>>> +
>>> return true;
>>>  }
>>>
>>> --
>>> 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

Re: [Mesa-dev] [PATCH 5/7] i965/screen: Don't advertise support for RG formats

[Jason Ekstrand]

On Wed, Jun 6, 2018 at 11:00 AM, Daniel Stone  wrote:

> Sorry, but as written this will regress ability to import NV12 images as
> separately-addressed planes with shader conversion to RGB; Kodi, Mutter and
> Weston all use this.
>

I don't believe it will.  It only makes it so that we don't advertise R and
RG formats through eglQueryDmaBufFormatsEXT.  This means that you can't
import the planes each as separate images but you can still import a planar
image.

--Jason



> On Wed, 6 Jun 2018, 6:48 pm Jason Ekstrand,  wrote:
>
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>  src/mesa/drivers/dri/i965/intel_screen.c | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>> b/src/mesa/drivers/dri/i965/intel_screen.c
>> index 5f0eeb41779..f681b221e7b 100644
>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>> @@ -1269,6 +1269,18 @@ intel_image_format_is_supported(const struct
>> intel_image_format *fmt)
>> fmt->fourcc == __DRI_IMAGE_FOURCC_SABGR)
>>return false;
>>
>> +   /* The dri_interface.h file says:
>> +*
>> +*"R8, GR88 and NONE should not be used with createImageFromName
>> or
>> +*createImage, and are returned by query from sub images created
>> with
>> +*createImageFromNames (NONE, see above) and fromPlane (R8 &
>> GR88)."
>> +*
>> +* Let's not advertise support for R or RG formats.
>> +*/
>> +   if (fmt->components == __DRI_IMAGE_COMPONENTS_R ||
>> +   fmt->components == __DRI_IMAGE_COMPONENTS_RG)
>> +  return false;
>> +
>> return true;
>>  }
>>
>> --
>> 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

Re: [Mesa-dev] [PATCH 5/7] i965/screen: Don't advertise support for RG formats

[Daniel Stone]

Sorry, but as written this will regress ability to import NV12 images as
separately-addressed planes with shader conversion to RGB; Kodi, Mutter and
Weston all use this.

On Wed, 6 Jun 2018, 6:48 pm Jason Ekstrand,  wrote:

> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/mesa/drivers/dri/i965/intel_screen.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index 5f0eeb41779..f681b221e7b 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -1269,6 +1269,18 @@ intel_image_format_is_supported(const struct
> intel_image_format *fmt)
> fmt->fourcc == __DRI_IMAGE_FOURCC_SABGR)
>return false;
>
> +   /* The dri_interface.h file says:
> +*
> +*"R8, GR88 and NONE should not be used with createImageFromName or
> +*createImage, and are returned by query from sub images created
> with
> +*createImageFromNames (NONE, see above) and fromPlane (R8 &
> GR88)."
> +*
> +* Let's not advertise support for R or RG formats.
> +*/
> +   if (fmt->components == __DRI_IMAGE_COMPONENTS_R ||
> +   fmt->components == __DRI_IMAGE_COMPONENTS_RG)
> +  return false;
> +
> return true;
>  }
>
> --
> 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] [PATCH 7/7] i965/screen: Sanity check that all formats we advertise are useable

[Jason Ekstrand]

---
 src/mesa/drivers/dri/i965/intel_screen.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index dbf0009cb02..d4818435bac 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1272,7 +1272,8 @@ intel_create_image_from_dma_bufs(__DRIscreen *dri_screen,
 }
 
 static bool
-intel_image_format_is_supported(const struct intel_image_format *fmt)
+intel_image_format_is_supported(const struct gen_device_info *devinfo,
+const struct intel_image_format *fmt)
 {
if (fmt->fourcc == __DRI_IMAGE_FOURCC_SARGB ||
fmt->fourcc == __DRI_IMAGE_FOURCC_SABGR)
@@ -1290,17 +1291,32 @@ intel_image_format_is_supported(const struct 
intel_image_format *fmt)
fmt->components == __DRI_IMAGE_COMPONENTS_RG)
   return false;
 
+#ifndef NDEBUG
+   if (fmt->nplanes == 1) {
+  mesa_format format = driImageFormatToGLFormat(fmt->planes[0].dri_format);
+  /* The images we will create are actually based on the RGBA non-sRGB
+   * version of the format.
+   */
+  format = _mesa_format_fallback_rgbx_to_rgba(format);
+  format = _mesa_get_srgb_format_linear(format);
+  enum isl_format isl_format = brw_isl_format_for_mesa_format(format);
+  assert(isl_format_supports_rendering(devinfo, isl_format));
+   }
+#endif
+
return true;
 }
 
 static GLboolean
-intel_query_dma_buf_formats(__DRIscreen *screen, int max,
+intel_query_dma_buf_formats(__DRIscreen *_screen, int max,
 int *formats, int *count)
 {
+   struct intel_screen *screen = _screen->driverPrivate;
int num_formats = 0, i;
 
for (i = 0; i < ARRAY_SIZE(intel_image_formats); i++) {
-  if (!intel_image_format_is_supported(&intel_image_formats[i]))
+  if (!intel_image_format_is_supported(&screen->devinfo,
+   &intel_image_formats[i]))
  continue;
 
   num_formats++;
@@ -1330,7 +1346,7 @@ intel_query_dma_buf_modifiers(__DRIscreen *_screen, int 
fourcc, int max,
if (f == NULL)
   return false;
 
-   if (!intel_image_format_is_supported(f))
+   if (!intel_image_format_is_supported(&screen->devinfo, f))
   return false;
 
for (i = 0; i < ARRAY_SIZE(supported_modifiers); i++) {
-- 
2.17.1

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

[Mesa-dev] [PATCH 6/7] i965/screen: Use RGBA non-sRGB formats for images

[Jason Ekstrand]

Not all of the MESA_FORMAT and ISL_FORMAT helpers we use can properly
handle RGBX formats.  Also, we don't want to make decisions based on
those in the first place because we can't render to RGBA and we use the
non-sRGB version to determine whether or not to allow CCS_E.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/intel_screen.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index f681b221e7b..dbf0009cb02 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -341,6 +341,10 @@ modifier_is_supported(const struct gen_device_info 
*devinfo,
   }
 
   mesa_format format = driImageFormatToGLFormat(dri_format);
+  /* Whether or not we support compression is based on the RGBA non-sRGB
+   * version of the format.
+   */
+  format = _mesa_format_fallback_rgbx_to_rgba(format);
   format = _mesa_get_srgb_format_linear(format);
   if (!isl_format_supports_ccs_e(devinfo,
  brw_isl_format_for_mesa_format(format)))
@@ -1095,6 +1099,11 @@ intel_create_image_from_fds_common(__DRIscreen 
*dri_screen,
   image->strides[index] = strides[index];
 
   mesa_format format = driImageFormatToGLFormat(f->planes[i].dri_format);
+  /* The images we will create are actually based on the RGBA non-sRGB
+   * version of the format.
+   */
+  format = _mesa_format_fallback_rgbx_to_rgba(format);
+  format = _mesa_get_srgb_format_linear(format);
 
   ok = isl_surf_init(&screen->isl_dev, &surf,
  .dim = ISL_SURF_DIM_2D,
-- 
2.17.1

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

[Mesa-dev] [PATCH 4/7] i965/screen: Return false for unsupported formats in query_modifiers

[Jason Ekstrand]

Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/intel_screen.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 2c783591202..5f0eeb41779 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1262,6 +1262,16 @@ intel_create_image_from_dma_bufs(__DRIscreen *dri_screen,
 loaderPrivate);
 }
 
+static bool
+intel_image_format_is_supported(const struct intel_image_format *fmt)
+{
+   if (fmt->fourcc == __DRI_IMAGE_FOURCC_SARGB ||
+   fmt->fourcc == __DRI_IMAGE_FOURCC_SABGR)
+  return false;
+
+   return true;
+}
+
 static GLboolean
 intel_query_dma_buf_formats(__DRIscreen *screen, int max,
 int *formats, int *count)
@@ -1269,8 +1279,7 @@ intel_query_dma_buf_formats(__DRIscreen *screen, int max,
int num_formats = 0, i;
 
for (i = 0; i < ARRAY_SIZE(intel_image_formats); i++) {
-  if (intel_image_formats[i].fourcc == __DRI_IMAGE_FOURCC_SARGB ||
-  intel_image_formats[i].fourcc == __DRI_IMAGE_FOURCC_SABGR)
+  if (!intel_image_format_is_supported(&intel_image_formats[i]))
  continue;
 
   num_formats++;
@@ -1300,6 +1309,9 @@ intel_query_dma_buf_modifiers(__DRIscreen *_screen, int 
fourcc, int max,
if (f == NULL)
   return false;
 
+   if (!intel_image_format_is_supported(f))
+  return false;
+
for (i = 0; i < ARRAY_SIZE(supported_modifiers); i++) {
   uint64_t modifier = supported_modifiers[i].modifier;
   if (!modifier_is_supported(&screen->devinfo, f, 0, modifier))
-- 
2.17.1

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

[Mesa-dev] [PATCH 3/7] i965/screen: Refactor query_dma_buf_formats

[Jason Ekstrand]

This reworks it to work like query_dma_buf_modifiers and, in particular,
makes it more flexible so that we can disallow a non-static set of
formats.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/intel_screen.c | 25 
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 935711106c0..2c783591202 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1266,22 +1266,23 @@ static GLboolean
 intel_query_dma_buf_formats(__DRIscreen *screen, int max,
 int *formats, int *count)
 {
-   int i, j = 0;
+   int num_formats = 0, i;
 
-   if (max == 0) {
-  /* Note, sRGB formats not included. */
-  *count = ARRAY_SIZE(intel_image_formats) - 2;
-  return true;
-   }
+   for (i = 0; i < ARRAY_SIZE(intel_image_formats); i++) {
+  if (intel_image_formats[i].fourcc == __DRI_IMAGE_FOURCC_SARGB ||
+  intel_image_formats[i].fourcc == __DRI_IMAGE_FOURCC_SABGR)
+ continue;
 
-   for (i = 0; i < (ARRAY_SIZE(intel_image_formats)) && j < max; i++) {
- if (intel_image_formats[i].fourcc == __DRI_IMAGE_FOURCC_SARGB ||
- intel_image_formats[i].fourcc == __DRI_IMAGE_FOURCC_SABGR)
-   continue;
- formats[j++] = intel_image_formats[i].fourcc;
+  num_formats++;
+  if (max == 0)
+ continue;
+
+  formats[num_formats - 1] = intel_image_formats[i].fourcc;
+  if (num_formats >= max)
+ break;
}
 
-   *count = j;
+   *count = num_formats;
return true;
 }
 
-- 
2.17.1

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

[Mesa-dev] [PATCH 5/7] i965/screen: Don't advertise support for RG formats

[Jason Ekstrand]

Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/intel_screen.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 5f0eeb41779..f681b221e7b 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1269,6 +1269,18 @@ intel_image_format_is_supported(const struct 
intel_image_format *fmt)
fmt->fourcc == __DRI_IMAGE_FOURCC_SABGR)
   return false;
 
+   /* The dri_interface.h file says:
+*
+*"R8, GR88 and NONE should not be used with createImageFromName or
+*createImage, and are returned by query from sub images created with
+*createImageFromNames (NONE, see above) and fromPlane (R8 & GR88)."
+*
+* Let's not advertise support for R or RG formats.
+*/
+   if (fmt->components == __DRI_IMAGE_COMPONENTS_R ||
+   fmt->components == __DRI_IMAGE_COMPONENTS_RG)
+  return false;
+
return true;
 }
 
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/7] intel/isl: Add bounds-checking assertions for the format_info table

[Jason Ekstrand]

We follow the same convention as isl_format_get_layout in having two
assertions to ensure that only valid formats are passed in.  We also
check against the array size of the table because some valid formats
such as CCS formats will may be past the end of the table.  This fixes
some potential out-of-bounds array access even in valid cases.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/isl/isl_format.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/src/intel/isl/isl_format.c b/src/intel/isl/isl_format.c
index 52997cf2ebb..968f981cdee 100644
--- a/src/intel/isl/isl_format.c
+++ b/src/intel/isl/isl_format.c
@@ -374,11 +374,19 @@ format_gen(const struct gen_device_info *devinfo)
return devinfo->gen * 10 + (devinfo->is_g4x || devinfo->is_haswell) * 5;
 }
 
+static bool
+format_info_exists(enum isl_format format)
+{
+   assert(format != ISL_FORMAT_UNSUPPORTED);
+   assert(format < ISL_NUM_FORMATS);
+   return format < ARRAY_SIZE(format_info) && format_info[format].exists;
+}
+
 bool
 isl_format_supports_rendering(const struct gen_device_info *devinfo,
   enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
return format_gen(devinfo) >= format_info[format].render_target;
@@ -388,7 +396,7 @@ bool
 isl_format_supports_alpha_blending(const struct gen_device_info *devinfo,
enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
return format_gen(devinfo) >= format_info[format].alpha_blend;
@@ -398,7 +406,7 @@ bool
 isl_format_supports_sampling(const struct gen_device_info *devinfo,
  enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
if (devinfo->is_baytrail) {
@@ -431,7 +439,7 @@ bool
 isl_format_supports_filtering(const struct gen_device_info *devinfo,
   enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
if (devinfo->is_baytrail) {
@@ -464,7 +472,7 @@ bool
 isl_format_supports_vertex_fetch(const struct gen_device_info *devinfo,
  enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
/* For vertex fetch, Bay Trail supports the same set of formats as Haswell
@@ -483,7 +491,7 @@ bool
 isl_format_supports_typed_writes(const struct gen_device_info *devinfo,
  enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
return format_gen(devinfo) >= format_info[format].typed_write;
@@ -504,7 +512,7 @@ bool
 isl_format_supports_typed_reads(const struct gen_device_info *devinfo,
 enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
return format_gen(devinfo) >= format_info[format].typed_read;
@@ -542,7 +550,7 @@ bool
 isl_format_supports_ccs_e(const struct gen_device_info *devinfo,
   enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
/* For simplicity, only report that a format supports CCS_E if blorp can
-- 
2.17.1

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

[Mesa-dev] [PATCH 0/7] i965: Be more careful about advertising formats and

[Jason Ekstrand]

When we originally added modifiers support we were, apparently, way more
sloppy with our implementations of the core queries than anyone realized.
We just dumped out the intel_image_formats table with very little thought
to whether or not we actually wanted to support them all.  We also didn't
bother to really check that the format the client specified in the
modifiers query was actually supported.  We also, apparently, didn't bother
to write any tests whatsoever.

The end result was that a very casual and obvious usage of the queries
where you query for supported formats and then walk the list and query for
supported modifers would end up doing piles of OOB array reads in ISL and
may or may not crash.  In the case of Eero's build in his CI system, it
instantly crashes the X server when a DRI3 app starts and asks for
modifiers.

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

Jason Ekstrand (7):
  intel/isl: Add bounds-checking assertions in isl_format_get_layout
  intel/isl: Add bounds-checking assertions for the format_info table
  i965/screen: Refactor query_dma_buf_formats
  i965/screen: Return false for unsupported formats in query_modifiers
  i965/screen: Don't advertise support for RG formats
  i965/screen: Use RGBA non-sRGB formats for images
  i965/screen: Sanity check that all formats we advertise are useable

 src/intel/isl/isl.h  | 32 ++
 src/intel/isl/isl_format.c   | 24 +---
 src/mesa/drivers/dri/i965/intel_screen.c | 76 
 3 files changed, 100 insertions(+), 32 deletions(-)

-- 
2.17.1

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

[Mesa-dev] [PATCH 1/7] intel/isl: Add bounds-checking assertions in isl_format_get_layout

[Jason Ekstrand]

We add two assertions instead of one because the first assertion that
format != ISL_FORMAT_UNSUPPORTED is more descriptive and checks for a
real but unsupported enumerant while the second ensures that they don't
pass in garbage values.  We also update some other helpers to use
isl_format_get_layout instead of using the table directly so that they
get bounds checking too.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/isl/isl.h | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index 00cfe31fc04..6800b1d76a6 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -389,6 +389,9 @@ enum isl_format {
ISL_FORMAT_GEN9_CCS_64BPP,
ISL_FORMAT_GEN9_CCS_128BPP,
 
+   /* An upper bound on the supported format enumerations */
+   ISL_NUM_FORMATS,
+
/* Hardware doesn't understand this out-of-band value */
ISL_FORMAT_UNSUPPORTED = UINT16_MAX,
 };
@@ -1423,6 +1426,8 @@ isl_device_get_sample_counts(struct isl_device *dev);
 static inline const struct isl_format_layout * ATTRIBUTE_CONST
 isl_format_get_layout(enum isl_format fmt)
 {
+   assert(fmt != ISL_FORMAT_UNSUPPORTED);
+   assert(fmt < ISL_NUM_FORMATS);
return &isl_format_layouts[fmt];
 }
 
@@ -1431,7 +1436,7 @@ bool isl_format_is_valid(enum isl_format);
 static inline const char * ATTRIBUTE_CONST
 isl_format_get_name(enum isl_format fmt)
 {
-   return isl_format_layouts[fmt].name;
+   return isl_format_get_layout(fmt)->name;
 }
 
 bool isl_format_supports_rendering(const struct gen_device_info *devinfo,
@@ -1546,7 +1551,7 @@ isl_format_block_is_1x1x1(enum isl_format fmt)
 static inline bool
 isl_format_is_srgb(enum isl_format fmt)
 {
-   return isl_format_layouts[fmt].colorspace == ISL_COLORSPACE_SRGB;
+   return isl_format_get_layout(fmt)->colorspace == ISL_COLORSPACE_SRGB;
 }
 
 enum isl_format isl_format_srgb_to_linear(enum isl_format fmt);
@@ -1556,20 +1561,25 @@ isl_format_is_rgb(enum isl_format fmt)
 {
if (isl_format_is_yuv(fmt))
   return false;
-   return isl_format_layouts[fmt].channels.r.bits > 0 &&
-  isl_format_layouts[fmt].channels.g.bits > 0 &&
-  isl_format_layouts[fmt].channels.b.bits > 0 &&
-  isl_format_layouts[fmt].channels.a.bits == 0;
+
+   const struct isl_format_layout *fmtl = isl_format_get_layout(fmt);
+
+   return fmtl->channels.r.bits > 0 &&
+  fmtl->channels.g.bits > 0 &&
+  fmtl->channels.b.bits > 0 &&
+  fmtl->channels.a.bits == 0;
 }
 
 static inline bool
 isl_format_is_rgbx(enum isl_format fmt)
 {
-   return isl_format_layouts[fmt].channels.r.bits > 0 &&
-  isl_format_layouts[fmt].channels.g.bits > 0 &&
-  isl_format_layouts[fmt].channels.b.bits > 0 &&
-  isl_format_layouts[fmt].channels.a.bits > 0 &&
-  isl_format_layouts[fmt].channels.a.type == ISL_VOID;
+   const struct isl_format_layout *fmtl = isl_format_get_layout(fmt);
+
+   return fmtl->channels.r.bits > 0 &&
+  fmtl->channels.g.bits > 0 &&
+  fmtl->channels.b.bits > 0 &&
+  fmtl->channels.a.bits > 0 &&
+  fmtl->channels.a.type == ISL_VOID;
 }
 
 enum isl_format isl_format_rgb_to_rgba(enum isl_format rgb) ATTRIBUTE_CONST;
-- 
2.17.1

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

[Mesa-dev] [PATCH] mesa/program_binary: add implicit UseProgram after successful ProgramBinary

[Jordan Justen]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106810
Fixes: b4c37ce2140 "i965: Add ARB_get_program_binary support using 
nir_serialization"
Ref: 3fe8d04a6d6 "mesa: don't always set _NEW_PROGRAM when linking"
Ref: c505d6d8522 "mesa: use gl_program for CurrentProgram rather than 
gl_shader_program"
Cc: Timothy Arceri 
Cc: 
Signed-off-by: Jordan Justen 
---
 src/mesa/main/program_binary.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/src/mesa/main/program_binary.c b/src/mesa/main/program_binary.c
index 021f6315e72..f4aa57821c8 100644
--- a/src/mesa/main/program_binary.c
+++ b/src/mesa/main/program_binary.c
@@ -33,6 +33,8 @@
 #include "compiler/glsl/serialize.h"
 #include "main/errors.h"
 #include "main/mtypes.h"
+#include "main/shaderapi.h"
+#include "util/bitscan.h"
 #include "util/crc32.h"
 #include "program_binary.h"
 #include "program/prog_parameter.h"
@@ -282,10 +284,41 @@ _mesa_program_binary(struct gl_context *ctx, struct 
gl_shader_program *sh_prog,
struct blob_reader blob;
blob_reader_init(&blob, payload, length - header_size);
 
+   unsigned programs_in_use = 0;
+   if (ctx->_Shader)
+  for (unsigned stage = 0; stage < MESA_SHADER_STAGES; stage++) {
+ if (ctx->_Shader->CurrentProgram[stage] &&
+ ctx->_Shader->CurrentProgram[stage]->Id == sh_prog->Name) {
+programs_in_use |= 1 << stage;
+ }
+   }
+
if (!read_program_payload(ctx, &blob, binary_format, sh_prog)) {
   sh_prog->data->LinkStatus = LINKING_FAILURE;
   return;
}
 
+   /* From section 7.3 (Program Objects) of the OpenGL 4.5 spec:
+*
+*"If LinkProgram or ProgramBinary successfully re-links a program
+* object that is active for any shader stage, then the newly generated
+* executable code will be installed as part of the current rendering
+* state for all shader stages where the program is active.
+* Additionally, the newly generated executable code is made part of
+* the state of any program pipeline for all stages where the program
+* is attached."
+*/
+   if (programs_in_use) {
+  while (programs_in_use) {
+ const int stage = u_bit_scan(&programs_in_use);
+
+ struct gl_program *prog = NULL;
+ if (sh_prog->_LinkedShaders[stage])
+prog = sh_prog->_LinkedShaders[stage]->Program;
+
+ _mesa_use_program(ctx, stage, sh_prog, prog, ctx->_Shader);
+  }
+   }
+
sh_prog->data->LinkStatus = LINKING_SKIPPED;
 }
-- 
2.17.1

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

[Mesa-dev] [PATCH] dri: add missing 16bits formats mapping

[Lionel Landwerlin]

Found by Eero.

v2: Add G16R16 formats (Lionel)

v3: Fix G16R16 mapping to mesa format (Jason)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Plamena Manolova  (v2)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106642
---
 src/mesa/drivers/dri/common/dri_util.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c
index a591dfcd7d2..d257cb644c8 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -936,6 +936,22 @@ static const struct {
   .image_format = __DRI_IMAGE_FORMAT_SARGB8,
   .mesa_format  =MESA_FORMAT_B8G8R8A8_SRGB,
},
+   {
+  .image_format = __DRI_IMAGE_FORMAT_R16,
+  .mesa_format  =MESA_FORMAT_R_UNORM16,
+   },
+   {
+  .image_format = __DRI_IMAGE_FORMAT_R16,
+  .mesa_format  =MESA_FORMAT_L_UNORM16,
+   },
+   {
+  .image_format = __DRI_IMAGE_FORMAT_GR1616,
+  .mesa_format  =MESA_FORMAT_R16G16_UNORM,
+   },
+   {
+  .image_format = __DRI_IMAGE_FORMAT_GR1616,
+  .mesa_format  =MESA_FORMAT_L16A16_UNORM,
+   },
 };
 
 uint32_t
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH v2] dri: add missing 16bits formats mapping

[Lionel Landwerlin]

On 06/06/18 18:27, Jason Ekstrand wrote:
On Wed, Jun 6, 2018 at 7:57 AM, Lionel Landwerlin 
mailto:lionel.g.landwer...@intel.com>> 
wrote:


Found by Eero.

v2: Add G16R16 formats (Lionel)

Signed-off-by: Lionel Landwerlin mailto:lionel.g.landwer...@intel.com>>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106642

---
 src/mesa/drivers/dri/common/dri_util.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index a591dfcd7d2..bc861d066d1 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -936,6 +936,22 @@ static const struct {
       .image_format = __DRI_IMAGE_FORMAT_SARGB8,
       .mesa_format  =        MESA_FORMAT_B8G8R8A8_SRGB,
    },
+   {
+      .image_format = __DRI_IMAGE_FORMAT_R16,
+      .mesa_format  =        MESA_FORMAT_R_UNORM16,
+   },
+   {
+      .image_format = __DRI_IMAGE_FORMAT_R16,
+      .mesa_format  =        MESA_FORMAT_L_UNORM16,
+   },
+   {
+      .image_format = __DRI_IMAGE_FORMAT_GR1616,
+      .mesa_format  =        MESA_FORMAT_G16R16_UNORM,


I think the MESA_FORMAT here is backwards.  Hooray for endianness...


Dammit! Thanks!


+   },
+   {
+      .image_format = __DRI_IMAGE_FORMAT_GR1616,
+      .mesa_format  =        MESA_FORMAT_L16A16_UNORM,
+   },
 };

 uint32_t
-- 
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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] vma/tests: cast away implementation detail of using strtoul()

[Eric Anholt]

Eric Engestrom  writes:

> On MacOS, the build fails because of a compiler complaint about
> a downcast:
>
>   vma_random_test.cpp:239:18: error: non-constant-expression cannot be 
> narrowed from type 'unsigned long' to 'uint_fast32_t' (aka 'unsigned int') in 
> initializer list [-Wc++11-narrowing]
>  random_test r{seed};
>^~~~
>   vma_random_test.cpp:239:18: note: insert an explicit cast to silence this 
> issue
>  random_test r{seed};
>^~~~
>static_cast( )
>
> Let's take the compiler's suggestion, as we only needed a long here to
> use strtoul().
>
> Cc: Scott D Phillips 
> Signed-off-by: Eric Engestrom 

This commit seems to have resolved the issue:

commit 08535dd8860951ce4572cd2590e417a1f3d96b3d
Author: Scott D Phillips 
Date:   Tue Jun 5 09:29:43 2018 -0700

util/tests/vma: Fix warning c++11-narrowing


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

Re: [Mesa-dev] [PATCH v2] dri: add missing 16bits formats mapping

[Jason Ekstrand]

On Wed, Jun 6, 2018 at 7:57 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Found by Eero.
>
> v2: Add G16R16 formats (Lionel)
>
> Signed-off-by: Lionel Landwerlin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106642
> ---
>  src/mesa/drivers/dri/common/dri_util.c | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/common/dri_util.c
> b/src/mesa/drivers/dri/common/dri_util.c
> index a591dfcd7d2..bc861d066d1 100644
> --- a/src/mesa/drivers/dri/common/dri_util.c
> +++ b/src/mesa/drivers/dri/common/dri_util.c
> @@ -936,6 +936,22 @@ static const struct {
>.image_format = __DRI_IMAGE_FORMAT_SARGB8,
>.mesa_format  =MESA_FORMAT_B8G8R8A8_SRGB,
> },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_R16,
> +  .mesa_format  =MESA_FORMAT_R_UNORM16,
> +   },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_R16,
> +  .mesa_format  =MESA_FORMAT_L_UNORM16,
> +   },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_GR1616,
> +  .mesa_format  =MESA_FORMAT_G16R16_UNORM,
>

I think the MESA_FORMAT here is backwards.  Hooray for endianness...


> +   },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_GR1616,
> +  .mesa_format  =MESA_FORMAT_L16A16_UNORM,
> +   },
>  };
>
>  uint32_t
> --
> 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

Re: [Mesa-dev] [PATCH 2/2] intel/isl: Add bounds-checking assertions for the format_info table

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 06/06/18 18:17, Jason Ekstrand wrote:

We follow the same convention as isl_format_get_layout in having two
assertions to ensure that only valid formats are passed in.  We also
check against the array size of the table because some valid formats
such as CCS formats will may be past the end of the table.  This fixes
some potential out-of-bounds array access even in valid cases.

Cc: mesa-sta...@lists.freedesktop.org
---
  src/intel/isl/isl_format.c | 24 
  1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/src/intel/isl/isl_format.c b/src/intel/isl/isl_format.c
index 52997cf2ebb..968f981cdee 100644
--- a/src/intel/isl/isl_format.c
+++ b/src/intel/isl/isl_format.c
@@ -374,11 +374,19 @@ format_gen(const struct gen_device_info *devinfo)
 return devinfo->gen * 10 + (devinfo->is_g4x || devinfo->is_haswell) * 5;
  }
  
+static bool

+format_info_exists(enum isl_format format)
+{
+   assert(format != ISL_FORMAT_UNSUPPORTED);
+   assert(format < ISL_NUM_FORMATS);
+   return format < ARRAY_SIZE(format_info) && format_info[format].exists;
+}
+
  bool
  isl_format_supports_rendering(const struct gen_device_info *devinfo,
enum isl_format format)
  {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
return false;
  
 return format_gen(devinfo) >= format_info[format].render_target;

@@ -388,7 +396,7 @@ bool
  isl_format_supports_alpha_blending(const struct gen_device_info *devinfo,
 enum isl_format format)
  {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
return false;
  
 return format_gen(devinfo) >= format_info[format].alpha_blend;

@@ -398,7 +406,7 @@ bool
  isl_format_supports_sampling(const struct gen_device_info *devinfo,
   enum isl_format format)
  {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
return false;
  
 if (devinfo->is_baytrail) {

@@ -431,7 +439,7 @@ bool
  isl_format_supports_filtering(const struct gen_device_info *devinfo,
enum isl_format format)
  {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
return false;
  
 if (devinfo->is_baytrail) {

@@ -464,7 +472,7 @@ bool
  isl_format_supports_vertex_fetch(const struct gen_device_info *devinfo,
   enum isl_format format)
  {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
return false;
  
 /* For vertex fetch, Bay Trail supports the same set of formats as Haswell

@@ -483,7 +491,7 @@ bool
  isl_format_supports_typed_writes(const struct gen_device_info *devinfo,
   enum isl_format format)
  {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
return false;
  
 return format_gen(devinfo) >= format_info[format].typed_write;

@@ -504,7 +512,7 @@ bool
  isl_format_supports_typed_reads(const struct gen_device_info *devinfo,
  enum isl_format format)
  {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
return false;
  
 return format_gen(devinfo) >= format_info[format].typed_read;

@@ -542,7 +550,7 @@ bool
  isl_format_supports_ccs_e(const struct gen_device_info *devinfo,
enum isl_format format)
  {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
return false;
  
 /* For simplicity, only report that a format supports CCS_E if blorp can



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

Re: [Mesa-dev] [PATCH 1/2] intel/isl: Add bounds-checking assertions in isl_format_get_layout

[Lionel Landwerlin]

On 06/06/18 18:17, Jason Ekstrand wrote:

We add two assertions instead of one because the first assertion that
format != ISL_FORMAT_UNSUPPORTED is more descriptive and checks for a
real but unsupported enumerant while the second ensures that they don't
pass in garbage values.  We also update some other helpers to use
isl_format_get_layout instead of using the table directly so that they
get bounds checking too.

Cc: mesa-sta...@lists.freedesktop.org
---
  src/intel/isl/isl.h | 32 +---
  1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index 00cfe31fc04..6800b1d76a6 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -389,6 +389,9 @@ enum isl_format {
 ISL_FORMAT_GEN9_CCS_64BPP,
 ISL_FORMAT_GEN9_CCS_128BPP,
  
+   /* An upper bound on the supported format enumerations */

+   ISL_NUM_FORMATS,
+
 /* Hardware doesn't understand this out-of-band value */
 ISL_FORMAT_UNSUPPORTED = UINT16_MAX,
  };
@@ -1423,6 +1426,8 @@ isl_device_get_sample_counts(struct isl_device *dev);
  static inline const struct isl_format_layout * ATTRIBUTE_CONST
  isl_format_get_layout(enum isl_format fmt)
  {
+   assert(fmt != ISL_FORMAT_UNSUPPORTED);
+   assert(fmt < ISL_NUM_FORMATS);
 return &isl_format_layouts[fmt];
  }
  
@@ -1431,7 +1436,7 @@ bool isl_format_is_valid(enum isl_format);

  static inline const char * ATTRIBUTE_CONST
  isl_format_get_name(enum isl_format fmt)
  {
-   return isl_format_layouts[fmt].name;
+   return isl_format_get_layout(fmt)->name;
  }
  
  bool isl_format_supports_rendering(const struct gen_device_info *devinfo,

@@ -1546,7 +1551,7 @@ isl_format_block_is_1x1x1(enum isl_format fmt)
  static inline bool
  isl_format_is_srgb(enum isl_format fmt)
  {
-   return isl_format_layouts[fmt].colorspace == ISL_COLORSPACE_SRGB;
+   return isl_format_get_layout(fmt)->colorspace == ISL_COLORSPACE_SRGB;
  }
  
  enum isl_format isl_format_srgb_to_linear(enum isl_format fmt);

@@ -1556,20 +1561,25 @@ isl_format_is_rgb(enum isl_format fmt)
  {
 if (isl_format_is_yuv(fmt))
return false;
-   return isl_format_layouts[fmt].channels.r.bits > 0 &&
-  isl_format_layouts[fmt].channels.g.bits > 0 &&
-  isl_format_layouts[fmt].channels.b.bits > 0 &&
-  isl_format_layouts[fmt].channels.a.bits == 0;
+
+   const struct isl_format_layout *fmtl = isl_format_get_layout(fmt);
+
+   return fmtl->channels.r.bits > 0 &&
+  fmtl->channels.g.bits > 0 &&
+  fmtl->channels.b.bits > 0 &&
+  fmtl->channels.a.bits == 0;
  }
  
  static inline bool

  isl_format_is_rgbx(enum isl_format fmt)
  {
-   return isl_format_layouts[fmt].channels.r.bits > 0 &&
-  isl_format_layouts[fmt].channels.g.bits > 0 &&
-  isl_format_layouts[fmt].channels.b.bits > 0 &&
-  isl_format_layouts[fmt].channels.a.bits > 0 &&
-  isl_format_layouts[fmt].channels.a.type == ISL_VOID;
+   const struct isl_format_layout *fmtl = isl_format_get_layout(fmt);
+
+   return fmtl->channels.r.bits > 0 &&
+  fmtl->channels.g.bits > 0 &&
+  fmtl->channels.b.bits > 0 &&
+  fmtl->channels.a.bits > 0 &&
+  fmtl->channels.a.type == ISL_VOID;
  }
  
  enum isl_format isl_format_rgb_to_rgba(enum isl_format rgb) ATTRIBUTE_CONST;

Do you want to use it in isl_buffer_fill_image_param() too?

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

[Mesa-dev] [PATCH 1/2] intel/isl: Add bounds-checking assertions in isl_format_get_layout

[Jason Ekstrand]

We add two assertions instead of one because the first assertion that
format != ISL_FORMAT_UNSUPPORTED is more descriptive and checks for a
real but unsupported enumerant while the second ensures that they don't
pass in garbage values.  We also update some other helpers to use
isl_format_get_layout instead of using the table directly so that they
get bounds checking too.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/isl/isl.h | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index 00cfe31fc04..6800b1d76a6 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -389,6 +389,9 @@ enum isl_format {
ISL_FORMAT_GEN9_CCS_64BPP,
ISL_FORMAT_GEN9_CCS_128BPP,
 
+   /* An upper bound on the supported format enumerations */
+   ISL_NUM_FORMATS,
+
/* Hardware doesn't understand this out-of-band value */
ISL_FORMAT_UNSUPPORTED = UINT16_MAX,
 };
@@ -1423,6 +1426,8 @@ isl_device_get_sample_counts(struct isl_device *dev);
 static inline const struct isl_format_layout * ATTRIBUTE_CONST
 isl_format_get_layout(enum isl_format fmt)
 {
+   assert(fmt != ISL_FORMAT_UNSUPPORTED);
+   assert(fmt < ISL_NUM_FORMATS);
return &isl_format_layouts[fmt];
 }
 
@@ -1431,7 +1436,7 @@ bool isl_format_is_valid(enum isl_format);
 static inline const char * ATTRIBUTE_CONST
 isl_format_get_name(enum isl_format fmt)
 {
-   return isl_format_layouts[fmt].name;
+   return isl_format_get_layout(fmt)->name;
 }
 
 bool isl_format_supports_rendering(const struct gen_device_info *devinfo,
@@ -1546,7 +1551,7 @@ isl_format_block_is_1x1x1(enum isl_format fmt)
 static inline bool
 isl_format_is_srgb(enum isl_format fmt)
 {
-   return isl_format_layouts[fmt].colorspace == ISL_COLORSPACE_SRGB;
+   return isl_format_get_layout(fmt)->colorspace == ISL_COLORSPACE_SRGB;
 }
 
 enum isl_format isl_format_srgb_to_linear(enum isl_format fmt);
@@ -1556,20 +1561,25 @@ isl_format_is_rgb(enum isl_format fmt)
 {
if (isl_format_is_yuv(fmt))
   return false;
-   return isl_format_layouts[fmt].channels.r.bits > 0 &&
-  isl_format_layouts[fmt].channels.g.bits > 0 &&
-  isl_format_layouts[fmt].channels.b.bits > 0 &&
-  isl_format_layouts[fmt].channels.a.bits == 0;
+
+   const struct isl_format_layout *fmtl = isl_format_get_layout(fmt);
+
+   return fmtl->channels.r.bits > 0 &&
+  fmtl->channels.g.bits > 0 &&
+  fmtl->channels.b.bits > 0 &&
+  fmtl->channels.a.bits == 0;
 }
 
 static inline bool
 isl_format_is_rgbx(enum isl_format fmt)
 {
-   return isl_format_layouts[fmt].channels.r.bits > 0 &&
-  isl_format_layouts[fmt].channels.g.bits > 0 &&
-  isl_format_layouts[fmt].channels.b.bits > 0 &&
-  isl_format_layouts[fmt].channels.a.bits > 0 &&
-  isl_format_layouts[fmt].channels.a.type == ISL_VOID;
+   const struct isl_format_layout *fmtl = isl_format_get_layout(fmt);
+
+   return fmtl->channels.r.bits > 0 &&
+  fmtl->channels.g.bits > 0 &&
+  fmtl->channels.b.bits > 0 &&
+  fmtl->channels.a.bits > 0 &&
+  fmtl->channels.a.type == ISL_VOID;
 }
 
 enum isl_format isl_format_rgb_to_rgba(enum isl_format rgb) ATTRIBUTE_CONST;
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/2] intel/isl: Add bounds-checking assertions for the format_info table

[Jason Ekstrand]

We follow the same convention as isl_format_get_layout in having two
assertions to ensure that only valid formats are passed in.  We also
check against the array size of the table because some valid formats
such as CCS formats will may be past the end of the table.  This fixes
some potential out-of-bounds array access even in valid cases.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/isl/isl_format.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/src/intel/isl/isl_format.c b/src/intel/isl/isl_format.c
index 52997cf2ebb..968f981cdee 100644
--- a/src/intel/isl/isl_format.c
+++ b/src/intel/isl/isl_format.c
@@ -374,11 +374,19 @@ format_gen(const struct gen_device_info *devinfo)
return devinfo->gen * 10 + (devinfo->is_g4x || devinfo->is_haswell) * 5;
 }
 
+static bool
+format_info_exists(enum isl_format format)
+{
+   assert(format != ISL_FORMAT_UNSUPPORTED);
+   assert(format < ISL_NUM_FORMATS);
+   return format < ARRAY_SIZE(format_info) && format_info[format].exists;
+}
+
 bool
 isl_format_supports_rendering(const struct gen_device_info *devinfo,
   enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
return format_gen(devinfo) >= format_info[format].render_target;
@@ -388,7 +396,7 @@ bool
 isl_format_supports_alpha_blending(const struct gen_device_info *devinfo,
enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
return format_gen(devinfo) >= format_info[format].alpha_blend;
@@ -398,7 +406,7 @@ bool
 isl_format_supports_sampling(const struct gen_device_info *devinfo,
  enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
if (devinfo->is_baytrail) {
@@ -431,7 +439,7 @@ bool
 isl_format_supports_filtering(const struct gen_device_info *devinfo,
   enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
if (devinfo->is_baytrail) {
@@ -464,7 +472,7 @@ bool
 isl_format_supports_vertex_fetch(const struct gen_device_info *devinfo,
  enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
/* For vertex fetch, Bay Trail supports the same set of formats as Haswell
@@ -483,7 +491,7 @@ bool
 isl_format_supports_typed_writes(const struct gen_device_info *devinfo,
  enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
return format_gen(devinfo) >= format_info[format].typed_write;
@@ -504,7 +512,7 @@ bool
 isl_format_supports_typed_reads(const struct gen_device_info *devinfo,
 enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
return format_gen(devinfo) >= format_info[format].typed_read;
@@ -542,7 +550,7 @@ bool
 isl_format_supports_ccs_e(const struct gen_device_info *devinfo,
   enum isl_format format)
 {
-   if (!format_info[format].exists)
+   if (!format_info_exists(format))
   return false;
 
/* For simplicity, only report that a format supports CCS_E if blorp can
-- 
2.17.1

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

Re: [Mesa-dev] [Fwd: Gitlab migration]

[Jason Ekstrand]

Could you please send that unencrypted?  I'm happy if you want to sign it
but sending encrypted mail to public list is a bit weird.

2018-06-06 6:56 GMT-07:00 Alejandro Piñeiro :

> -BEGIN PGP MESSAGE-
>
> hQIMAxofeYe0BHiSARAAi5AXyHgpmhQ9wIAfFtpGfqnHbThXHRymLy4WzRjLpBb8
> PxW3luMzvEbh7QoBdGcZrq88zVD5Mno9UeiQNlpZlzKxpU6UYFIjDnyvKCAQzeFs
> kgQJjxB9s52Cx1XnAM74zSfAKhFYukPZOjJMAiod/kI28RCVjO5EUHwkAGS542gT
> uSmvkpIKnqJrM3yTZA9oly484zPpuIrRC3dtx2f0X4pcwa408VIT33XDtVK/a9L2
> pmm0lac1++iazmJMYwzo5AhGmYPb2HfAtPEkkn8dFPtW/FH6he54bVpQ4JPzPend
> EhwVjg4/Fs4CvmagEEx60YMzAAQI5eg1oFNZbhWyGv4x3imhIvJzlCSYXaywrqOH
> XWHB4inNnbLdR6qIVdJ1ZIyLr7lE8Y93GDRcSTliZyDqMCz8ponaUonp1WMYCPDG
> dYIqiNVr7uuEcVQR01kIEaOuWfxttJjgtyAI/o2UDQ9LIkeV48rPFvI/ae6dkck7
> iZ7K729XXLNwDRZmlP19b8nq0HhEKBkR7sPuYjxuJn2uj2mizSHrVO8VXLgdwsP5
> egYEigmM/sa6w40PTp7CLx4wfnlzOOEsyhf31ElN1kU2K2tTqMd3N2jeM8jAZ4YH
> uBFYGxQovovQCyjwepPxANiNTIGfyEg7nCEGFpsCEmlTBHGOPXPO6WcyFI/8aa+F
> AQ4DweIfPQSnh4kQA/42mSE5OpfQ6XjI7sNjQ3JP4N8riHAtQGhEXWd+cPX1kH61
> 1JyFTzMRVGHvAPTVKxYeZzvYiNKqPq9BpRm39MxdQRBHhmsx5FVujsqUolZf5z47
> rIpZQVXtunnKdcc+EMRF1uJECrAf7z18FN/G2vZbRhhKlOGIjPxTZn/xkmXeugP+
> PJpHgSkXX/35cXlbLrH8Gj7VpN+096Q76S0nH7XaU3A0U39mAx/E5h9cdMoYJUyM
> RhCRSuD43L6u4ndIdSxfzOQenUKQDcDISdJSvdh5dlFq1s+KE8eDTQTVpKgA/igy
> 7oElba54V7H30UkBGv65Tu7tgc9S+EfzwkG5C6MfMuXS6gELjEoKHcBkWR/P4a8a
> BLfXkwyqg1b29/OR7Iy1VN6mjhDulcPOnGnZwmbABZzrxOXUcpr0tsLB8BcqVMpx
> myOuTWkXXYpVfVuL5a7lg5Hh4f0DgmMO4aVedornSTqM0ylAENcnXdw4sHxAkeE/
> 8yB8X9mNtIndeN45i5Hml3zOkRbhvhTI5xJnMUNBG+KH931c93AFutjMp0nRcqqi
> tOOY+1SoU3CDPXncAhB3ScXZOb7aA1IKdRbVI5LZOhyWrHV8EX8J355mL8qPy19R
> 2zv0IxMp5oTwXN/FgbGWfbjBaTTs9qcF+g+V7Ik10cgruvNT5LozCC/dg9VcJIbn
> HNBDALYyqiYdV8pF22Wd8afumG66ybzfueWZD6xC+KsRo70xLWHdZsIbQYfE60yp
> QESW1kFaPRmI5cu06qjoMvSm+CVbSH2QyxR0+rmvcTGDnkEePUXXuPfEN0sAlZzn
> K2v/JxzsKN/T4iV7VQxruoGJiDmSKIx8CiGzXNAafAhX2kkQRIwqK5loHOa4SrIL
> 3pVBeEVwZvgaL6q6hqVlu2uOYYgZbXk7c1BTAnD2IFqLxFWBBM4DzPiKTwJcKB+z
> rpqfzA1eYxF/y3ZkT8HsnEy+ZcsT8SfC5bm99LFuCZtvBPCLI4wdjyewQeimZ/o7
> T5tpJcjOQoYVh7NPWqxkO9hoidHjS4Axkkh05pdnSubg+JK7p7wYN0hho1i8Fl9e
> 3wBBa6e4XaQKbOK+mUSkRUbbyaMBCfR5/NsdGDgtUgwnUiN5YdWAYnj/FFSbw8/4
> gwUtlwCh3YvlvOM4n+7AlUmHy9QkVj0XDZeWltvkHt1joKlSI5Rv7OP01XHtsfVo
> +Z+2EbBt9LL1Mu+66JHABMq8keDsLliBBqu7EUJnqrickU0rQ1bb2bTZ6TtqDSrj
> mDpKyhH/XfeZqgD5tDuJsPRHvJuIFROTDaU9UwgOzGA9BBJS8NyciMPXDb/W/Cdu
> vq2+F+OvzRkra8YTJtMG+iNDyrqVYygBhEQIwa1OBJLQ6Px3gD39W+CTRniHkffy
> 4eYiieIpjZBKyHlSTZ3aY0nqJqeo6/nfl/RifvVORdFjrV3KSvohc9ZbJA5KdAIs
> xF+ueMXmBVSPdFAQ7ZBAtGWrv5OAthMoazqKrr1VtC0MpbIinv5pubtNAxKqYmM+
> Iu4++CE/PHAS1wlINgMS1RC2cF23wm4AiwZ9dj4kRd9JgE8rZ0r49kxMQgBSecsi
> iTeRC7rUheulRIZB7LR+UrpGtmoC7Bb4MKWJvESf98DhcqoNxqjX2GsKeakJKoG/
> Gn+DrUrmE+Rqn5nLMjpuOOMxXiKURbMNDRQ/koVjp83TjQILnkmseoKtkAAUBGAK
> 0wPARSpkNq/UiDq/42KeAozi8z6vamsd935Uw+5ichraOZBX3gMADa0/UFLF3oPr
> oro3D+LRGM2Q1ZENEKPmzMdKKL8kRrVQeXjLm7Ax7vmj3VaEHEh8vK+K/RxVPaq0
> vUNQlXbbJS6bzFEETx4vhdYNAwndTNIquoL02sUKxXpqee+aeh4jzvv5/g+q6bA3
> LJ1AEAxFfSs0FHGVEMbMH4Hy4wXEFwzVg/BT9IHa8HzS2qLwORnwhne0X9XyRv3x
> w8mouSvPMgfiJmVae5NfqSejQb9oBkoUlsaSae5lkJiskB4EHQPE+GWN6MxGVNO/
> lvc0Q4pRmpDDIYzmscsm4Krkzw6SvYiwAg==
> =D+m4
> -END PGP MESSAGE-
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] dri: add missing 16bits formats mapping

[Plamena Manolova]

v2 is Reviewed-by: Plamena Manolova 

On Wed, 6 Jun 2018 at 15:59, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Found by Eero.
>
> v2: Add G16R16 formats (Lionel)
>
> Signed-off-by: Lionel Landwerlin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106642
> ---
>  src/mesa/drivers/dri/common/dri_util.c | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/common/dri_util.c
> b/src/mesa/drivers/dri/common/dri_util.c
> index a591dfcd7d2..bc861d066d1 100644
> --- a/src/mesa/drivers/dri/common/dri_util.c
> +++ b/src/mesa/drivers/dri/common/dri_util.c
> @@ -936,6 +936,22 @@ static const struct {
>.image_format = __DRI_IMAGE_FORMAT_SARGB8,
>.mesa_format  =MESA_FORMAT_B8G8R8A8_SRGB,
> },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_R16,
> +  .mesa_format  =MESA_FORMAT_R_UNORM16,
> +   },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_R16,
> +  .mesa_format  =MESA_FORMAT_L_UNORM16,
> +   },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_GR1616,
> +  .mesa_format  =MESA_FORMAT_G16R16_UNORM,
> +   },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_GR1616,
> +  .mesa_format  =MESA_FORMAT_L16A16_UNORM,
> +   },
>  };
>
>  uint32_t
> --
> 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] [PATCH] egl/glvnd: Fix a segfault in eglGetProcAddress.

[Kyle Brenneman]

If FindProcIndex in egldispatchstubs.c is called with a name that's less than
the first entry in the array, it would end up trying to store an index of -1 in
an unsigned integer, wrap around to 2^32, and then crash when it tries to look
that up.

Change FindProcIndex so that it uses bsearch(3) instead of implementing its own
binary search, like the GLX equivalent FindGLXFunction does.
---
 src/egl/main/egldispatchstubs.c | 30 +-
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/src/egl/main/egldispatchstubs.c b/src/egl/main/egldispatchstubs.c
index e02abd7..bfc3195 100644
--- a/src/egl/main/egldispatchstubs.c
+++ b/src/egl/main/egldispatchstubs.c
@@ -2,6 +2,7 @@
 #include "g_egldispatchstubs.h"
 
 #include 
+#include 
 
 #include "eglcurrent.h"
 
@@ -10,26 +11,21 @@ static const __EGLapiExports *exports;
 const int __EGL_DISPATCH_FUNC_COUNT = __EGL_DISPATCH_COUNT;
 int __EGL_DISPATCH_FUNC_INDICES[__EGL_DISPATCH_COUNT + 1];
 
+static int Compare(const void *l, const void *r)
+{
+const char *s = *(const char **)r;
+return strcmp(l, s);
+}
+
 static int FindProcIndex(const char *name)
 {
-unsigned first = 0;
-unsigned last = __EGL_DISPATCH_COUNT - 1;
-
-while (first <= last) {
-unsigned middle = (first + last) / 2;
-int comp = strcmp(name,
-  __EGL_DISPATCH_FUNC_NAMES[middle]);
-
-if (comp > 0)
-first = middle + 1;
-else if (comp < 0)
-last = middle - 1;
-else
-return middle;
-}
+const char **match = bsearch(name, __EGL_DISPATCH_FUNC_NAMES,
+__EGL_DISPATCH_COUNT, sizeof(const char *), Compare);
+
+if (match == NULL)
+return __EGL_DISPATCH_COUNT;
 
-/* Just point to the dummy entry at the end of the respective table */
-return __EGL_DISPATCH_COUNT;
+return match - __EGL_DISPATCH_FUNC_NAMES;
 }
 
 void __eglInitDispatchStubs(const __EGLapiExports *exportsTable)
-- 
2.7.4

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

[Mesa-dev] [Bug 106833] glLinkProgram is expected to fail when vertex attribute aliasing happens on ES3.0 context or later

[bugzilla-daemon]

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

--- Comment #5 from Tapani Pälli  ---
(In reply to Tapani Pälli from comment #4)
> Created attachment 140052 [details] [review]
> possible fix
> 
> This should fix the issue but will investigate if there is a cleaner way.

*Warning, this fixes the issue but introduces problems.*

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

[Mesa-dev] [PATCH v2] dri: add missing 16bits formats mapping

[Lionel Landwerlin]

Found by Eero.

v2: Add G16R16 formats (Lionel)

Signed-off-by: Lionel Landwerlin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106642
---
 src/mesa/drivers/dri/common/dri_util.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c
index a591dfcd7d2..bc861d066d1 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -936,6 +936,22 @@ static const struct {
   .image_format = __DRI_IMAGE_FORMAT_SARGB8,
   .mesa_format  =MESA_FORMAT_B8G8R8A8_SRGB,
},
+   {
+  .image_format = __DRI_IMAGE_FORMAT_R16,
+  .mesa_format  =MESA_FORMAT_R_UNORM16,
+   },
+   {
+  .image_format = __DRI_IMAGE_FORMAT_R16,
+  .mesa_format  =MESA_FORMAT_L_UNORM16,
+   },
+   {
+  .image_format = __DRI_IMAGE_FORMAT_GR1616,
+  .mesa_format  =MESA_FORMAT_G16R16_UNORM,
+   },
+   {
+  .image_format = __DRI_IMAGE_FORMAT_GR1616,
+  .mesa_format  =MESA_FORMAT_L16A16_UNORM,
+   },
 };
 
 uint32_t
-- 
2.17.1

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

Re: [Mesa-dev] [Fwd: Gitlab migration]

[Alejandro Piñeiro]

Please ignore those two emails. Were intended to a internal mailing
list. Sorry for the noise.


On 06/06/18 16:43, Alejandro Piñeiro wrote:
>
>
> ___
> 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 1/2] nir: add pass to move load_const

[Rob Clark]

Run this pass late (after opt loop) to move load_const instructions back
into the basic blocks which use the result, in cases where a load_const
is only consumed in a single block.

This helps reduce register usage in cases where the backend driver
cannot lower the load_const to a uniform.

Signed-off-by: Rob Clark 
---
 src/compiler/Makefile.sources  |   1 +
 src/compiler/nir/meson.build   |   1 +
 src/compiler/nir/nir.h |   1 +
 src/compiler/nir/nir_move_load_const.c | 131 +
 4 files changed, 134 insertions(+)
 create mode 100644 src/compiler/nir/nir_move_load_const.c

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 3daa2c51334..cb8a2875a84 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -253,6 +253,7 @@ NIR_FILES = \
nir/nir_lower_wpos_center.c \
nir/nir_lower_wpos_ytransform.c \
nir/nir_metadata.c \
+   nir/nir_move_load_const.c \
nir/nir_move_vec_src_uses_to_dest.c \
nir/nir_normalize_cubemap_coords.c \
nir/nir_opt_conditional_discard.c \
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index 3fec363691d..373a47fd155 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -144,6 +144,7 @@ files_libnir = files(
   'nir_lower_wpos_ytransform.c',
   'nir_lower_bit_size.c',
   'nir_metadata.c',
+  'nir_move_load_const.c',
   'nir_move_vec_src_uses_to_dest.c',
   'nir_normalize_cubemap_coords.c',
   'nir_opt_conditional_discard.c',
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 5a1f79515ad..073ab4e82ea 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2612,6 +2612,7 @@ bool nir_remove_dead_variables(nir_shader *shader, 
nir_variable_mode modes);
 bool nir_lower_constant_initializers(nir_shader *shader,
  nir_variable_mode modes);
 
+bool nir_move_load_const(nir_shader *shader);
 bool nir_move_vec_src_uses_to_dest(nir_shader *shader);
 bool nir_lower_vec_to_movs(nir_shader *shader);
 void nir_lower_alpha_test(nir_shader *shader, enum compare_func func,
diff --git a/src/compiler/nir/nir_move_load_const.c 
b/src/compiler/nir/nir_move_load_const.c
new file mode 100644
index 000..c0750035fbb
--- /dev/null
+++ b/src/compiler/nir/nir_move_load_const.c
@@ -0,0 +1,131 @@
+/*
+ * Copyright © 2018 Red Hat
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Rob Clark (robdcl...@gmail.com>
+ *
+ */
+
+#include "nir.h"
+
+
+/*
+ * A simple pass that moves load_const's into consuming block if
+ * they are only consumed in a single block, to try to counter-
+ * act nir's tendency to move all load_const to the top of the
+ * first block.
+ */
+
+/* iterate a ssa def's use's and if all uses are within a single
+ * block, return it, otherwise return null.
+ */
+static nir_block *
+get_single_block(nir_ssa_def *def)
+{
+   nir_block *b = NULL;
+
+   /* hmm, probably ignore if-uses: */
+   if (!list_empty(&def->if_uses))
+  return NULL;
+
+   nir_foreach_use(use, def) {
+  nir_instr *instr = use->parent_instr;
+
+  /*
+   * Kind of an ugly special-case, but phi instructions
+   * need to appear first in the block, so by definition
+   * we can't move a load_immed into a block where it is
+   * consumed by a phi instruction.  We could conceivably
+   * move it into a dominator block.
+   */
+  if (instr->type == nir_instr_type_phi)
+ return NULL;
+
+  nir_block *use_block = instr->block;
+
+  if (!b) {
+ b = use_block;
+  } else if (b != use_block) {
+ return NULL;
+  }
+   }
+
+   return b;
+}
+
+bool
+nir_move_load_const(nir_shader *shader)
+{
+   bool progress = false;
+
+   nir_foreach_function(function, shader) {
+  if (!function->impl)
+ continue;
+
+ 

[Mesa-dev] [PATCH 2/2] nir: add lowering for gl_HelperInvocation

[Rob Clark]

Signed-off-by: Rob Clark 
---
I can't say for sure that this will work on all drivers, but it is
what the blob driver does, and it seems to make deqp happy.  I could
move this to it's own pass inside ir3, but that seemed like overkill

 src/compiler/nir/nir.h  | 10 ++
 src/compiler/nir/nir_lower_system_values.c  | 17 +
 src/gallium/drivers/freedreno/ir3/ir3_nir.c |  1 +
 3 files changed, 28 insertions(+)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 073ab4e82ea..de3d55d83af 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -1963,6 +1963,16 @@ typedef struct nir_shader_compiler_options {
 */
bool lower_base_vertex;
 
+   /**
+* If enabled, gl_HelperInvocation will be lowered as:
+*
+*   !((1 << gl_SampleID) & gl_SampleMaskIN[0]))
+*
+* TODO any hw w/ more than 32 samples?  For them (if they
+* used this option), a bit more math would be involved.
+*/
+   bool lower_helper_invocation;
+
bool lower_cs_local_index_from_id;
 
bool lower_device_index_to_zero;
diff --git a/src/compiler/nir/nir_lower_system_values.c 
b/src/compiler/nir/nir_lower_system_values.c
index 487da042620..6668cbb5dcd 100644
--- a/src/compiler/nir/nir_lower_system_values.c
+++ b/src/compiler/nir/nir_lower_system_values.c
@@ -136,6 +136,23 @@ convert_block(nir_block *block, nir_builder *b)
   nir_load_first_vertex(b));
  break;
 
+  case SYSTEM_VALUE_HELPER_INVOCATION:
+ if (b->shader->options->lower_helper_invocation) {
+nir_ssa_def *tmp;
+
+tmp = nir_ushr(b,
+   nir_imm_int(b, 1),
+   nir_load_sample_id(b));
+
+tmp = nir_iand(b,
+   nir_load_sample_mask_in(b),
+   tmp);
+
+sysval = nir_inot(b, nir_i2b(b, tmp));
+ }
+
+ break;
+
   case SYSTEM_VALUE_INSTANCE_INDEX:
  sysval = nir_iadd(b,
nir_load_instance_id(b),
diff --git a/src/gallium/drivers/freedreno/ir3/ir3_nir.c 
b/src/gallium/drivers/freedreno/ir3/ir3_nir.c
index cd1f9c526f2..341d990b269 100644
--- a/src/gallium/drivers/freedreno/ir3/ir3_nir.c
+++ b/src/gallium/drivers/freedreno/ir3/ir3_nir.c
@@ -51,6 +51,7 @@ static const nir_shader_compiler_options options = {
.lower_extract_byte = true,
.lower_extract_word = true,
.lower_all_io_to_temps = true,
+   .lower_helper_invocation = true,
 };
 
 struct nir_shader *
-- 
2.17.0

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

Re: [Mesa-dev] [Fwd: Gitlab migration]

[Alejandro Piñeiro]

bin1bz8_m0JgN.bin
Description: PGP/MIME version identification


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

Re: [Mesa-dev] [PATCH] dri: add missing 16bits formats mapping

[Plamena Manolova]

Reviewed-by: Plamena Manolova 

On Wed, 6 Jun 2018 at 13:53, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Signed-off-by: Lionel Landwerlin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106642
> ---
>  src/mesa/drivers/dri/common/dri_util.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/common/dri_util.c
> b/src/mesa/drivers/dri/common/dri_util.c
> index a591dfcd7d2..f634609c90f 100644
> --- a/src/mesa/drivers/dri/common/dri_util.c
> +++ b/src/mesa/drivers/dri/common/dri_util.c
> @@ -936,6 +936,14 @@ static const struct {
>.image_format = __DRI_IMAGE_FORMAT_SARGB8,
>.mesa_format  =MESA_FORMAT_B8G8R8A8_SRGB,
> },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_R16,
> +  .mesa_format = MESA_FORMAT_R_UNORM16,
> +   },
> +   {
> +  .image_format = __DRI_IMAGE_FORMAT_R16,
> +  .mesa_format = MESA_FORMAT_L_UNORM16,
> +   },
>  };
>
>  uint32_t
> --
> 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

Re: [Mesa-dev] [Fwd: Gitlab migration]

[Alejandro Piñeiro]

binHRfGIbLv5F.bin
Description: PGP/MIME version identification


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

[Mesa-dev] [PATCH] dri: add missing 16bits formats mapping

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106642
---
 src/mesa/drivers/dri/common/dri_util.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c
index a591dfcd7d2..f634609c90f 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -936,6 +936,14 @@ static const struct {
   .image_format = __DRI_IMAGE_FORMAT_SARGB8,
   .mesa_format  =MESA_FORMAT_B8G8R8A8_SRGB,
},
+   {
+  .image_format = __DRI_IMAGE_FORMAT_R16,
+  .mesa_format = MESA_FORMAT_R_UNORM16,
+   },
+   {
+  .image_format = __DRI_IMAGE_FORMAT_R16,
+  .mesa_format = MESA_FORMAT_L_UNORM16,
+   },
 };
 
 uint32_t
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] glsl: Take 'double' as reserved after GLSL ES 1.0

[Ilia Mirkin]

On Wed, Jun 6, 2018 at 4:11 AM, Kenneth Graunke  wrote:
> On Monday, June 4, 2018 2:33:59 PM PDT zhaowei yuan wrote:
>> GLSL ES 1.0.17 specifies that "double" is a keyword reserved
>>
>> Signed-off-by: zhaowei yuan 
>> ---
>>  src/compiler/glsl/glsl_lexer.ll | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/compiler/glsl/glsl_lexer.ll 
>> b/src/compiler/glsl/glsl_lexer.ll
>> index b7cf100..de6dc64 100644
>> --- a/src/compiler/glsl/glsl_lexer.ll
>> +++ b/src/compiler/glsl/glsl_lexer.ll
>> @@ -600,7 +600,7 @@ external  KEYWORD(110, 100, 0, 0, EXTERNAL);
>>  interfaceKEYWORD(110, 100, 0, 0, INTERFACE);
>>  long KEYWORD(110, 100, 0, 0, LONG_TOK);
>>  shortKEYWORD(110, 100, 0, 0, SHORT_TOK);
>> -double   TYPE_WITH_ALT(130, 300, 130, 300, 
>> yyextra->ARB_gpu_shader_fp64_enable, glsl_type::double_type);
>> +double   TYPE_WITH_ALT(130, 100, 130, 300, 
>> yyextra->ARB_gpu_shader_fp64_enable, glsl_type::double_type);

That should probably be TYPE_WITH_ALT(110, 100, 400, 0, ...) no?

>>  half KEYWORD(110, 100, 0, 0, HALF);
>>  fixedKEYWORD(110, 100, 0, 0, FIXED_TOK);
>>  unsigned KEYWORD(110, 100, 0, 0, UNSIGNED);
>>
>
> Reviewed-by: Kenneth Graunke 
>
> Pushed:
>
> To ssh://git.freedesktop.org/git/mesa/mesa
>17a42062ccd..67f7a16b598  master -> master
>
> Thanks for the patch!
>
> ___
> 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 106833] glLinkProgram is expected to fail when vertex attribute aliasing happens on ES3.0 context or later

[bugzilla-daemon]

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

--- Comment #4 from Tapani Pälli  ---
Created attachment 140052
  --> https://bugs.freedesktop.org/attachment.cgi?id=140052&action=edit
possible fix

This should fix the issue but will investigate if there is a cleaner way.

-- 
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 00/21] Towards NIR support for etnaviv

[Philipp Zabel]

Hi Christian,

On Tue, 2018-06-05 at 17:43 +0200, Christian Gmeiner wrote:
> Am Di., 5. Juni 2018 um 16:40 Uhr schrieb Philipp Zabel
> :
> Thanks for this nice patch series. I have been working for too long on
> the nir topic
> for etnaviv and never pushed any patches (which is quite sad). I have taken
> another route to tackle it. I have started with a low level library to
> generate valid
> Vivante binaries and to be able to disassemble them. On top of this, I
> have an eir
> library which is a simple block based ir which makes use of the low-level lib.

With your bottom-up vs our top-down approach it sounds like our efforts
might well complement each other. We haven't touched low level code
emission at all on purpose.

> And the last thing is the actual compiler which is nir based. All life outside
> of the gallium driver and have some gtest based unit tests. My main goal was 
> to
> start from a green field without looking at the current tgsi based compiler.
> 
> I will have a deeper look at your patches and review them.

Thanks, I'm looking forward to your review.

> I am quite unsure what I will do with my current code.
> I think the best would be to clean it up and push it.

I would appreciate being able to have a look.

> Hopefully, we can incorporate each work into a really nice new compiler.

Agreed!

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

Re: [Mesa-dev] [PATCH 06/21] etnaviv: nir: hardwire position location

[Philipp Zabel]

On Tue, 2018-06-05 at 11:50 -0400, Rob Clark wrote:
> On Tue, Jun 5, 2018 at 10:38 AM, Philipp Zabel  wrote:
> > The temporary input/output register 0 is reserved for position in the
> > fragment shader. Hardwire it to 0 and start other input/output variables
> > at 1. The intrinsic input load and output store base corresponds to the
> > temporary register number.
> 
> I didn't look at this very closely, but at RA time you can pre-color
> (pre-assign) specific registers, see ra_set_node_reg().. not sure if
> this would be a better approach.  I do this for a few frag shader
> registers, mostly because at the time I hadn't found the cmdstream
> register/bitfield to configure it to something other than r0.x..

Yes, thank you. We already pre-color, but with the output of this pass.
I'll have a look into whether this can be simplified by doing the pre-
color first and then afterwards fixing up the load/store intrinsics.
We keep around the intrinsics as we use them to configure the shader
inputs/outputs later.

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

Re: [Mesa-dev] [PATCH 08/21] etnaviv: nir: add virtual register classes

[Philipp Zabel]

On Tue, 2018-06-05 at 11:39 -0400, Rob Clark wrote:
> On Tue, Jun 5, 2018 at 10:38 AM, Philipp Zabel  wrote:
> > Since all threads share a global temporary vec4 register file, it is
> > important to reduce temporary register use of shaders.
> > Using source swizzles and destination write mask of ALU operations we
> > can layer smaller virtual registers on top of the physical base
> > registers that overlap with their base register and partially with each
> > other:
> > 
> >  ++-+-+-+
> >  |VEC4|  VEC3   |VEC2 | SCALAR  |
> >  ++-+-+-+
> >  |  X | X X X   | X X X   | X   |
> >  |  Y | Y Y   Y | Y Y Y   |   Y |
> >  |  Z | Z   Z Z |   Z   Z   Z | Z   |
> >  |  W |   W W W | W   W W |   W |
> >  ++-+-+-+
> > 
> > There are four possible virtual vec3 registers that leave the remaining
> > component usable as a scalar virtual register, six possible vec2
> > registers, and four possible scalar registers that only use a single
> > component.
> > 
> > This patch adds an interference graph for virtual registers to the
> > register allocator, using information about SSA interference and virtual
> > register overlap. If possible, SSAs with smaller num_components are
> > allocated from the unused components of already partially used temporary
> > registers.
> > 
> > Signed-off-by: Philipp Zabel 
> > Signed-off-by: Michael Tretter 
> > ---
> 
> so one quick note, constructing the register classes can be
> expensive.. you probably only want to do this once and then re-use for
> each shader

Thank you. Yes, that should be easily fixable.

The main reason we haven't already done this is that I hadn't added the
dummy RA node that grabs the forbidden register 0 in fragment shaders
until the last minute. Previously we had left out the register from the
graph altogether.

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

[Mesa-dev] [Bug 106833] glLinkProgram is expected to fail when vertex attribute aliasing happens on ES3.0 context or later

[bugzilla-daemon]

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

--- Comment #3 from Tapani Pälli  ---
(In reply to xinghua from comment #2)
> (In reply to Tapani Pälli from comment #1)
> > FYI I noticed this test prints out following before failing tests:
> > 
> > "Testing with shader that has entirely unused attributes".
> > 
> > IMO the issue here is that Mesa does not assign a location to entirely
> > unused attributes (their location will be -1) and therefore checks for
> > overlapping/aliasing locations are not done. I've proven this by skipping
> > opt_dead_code for certain variables in the test and that makes it pass as we
> > run the appropriate check in linker.
> > 
> > I'm not sure if this testing overlapping locations of unused attributes
> > makes actually sense or how to fix the situation.
> 
> The  original target of these cases are surely testing with shader that has
> entirely unused attributes. These cases are used to verify whether GLES
> implementation follows the spec, and spec defines that "The existence of
> aliasing is determined by declarations present after preprocessing", "not
> depend on compiler optimizations which might be implementation-dependent".

One thing making this problematic is that there are 3 ways to assign location.
Either explicitly in the shader, using glBindAttribLocation or automatic
assignment by the linker. This test calls glBindAttribLocation, so we don't
know the location aliasing after preprocessing, we will know it only at linking
phase.

However it should be possible to fix this since removing those dead variables
and assigning locations both happen in the linker, however it does not look
very straightforward :/ We do remove dead code before assigning locations since
that makes a lot of sense.

> I do also know nothing why spec defines aliasing like above. Does OpenGL 4.5
> defines aliasing the same as OpenGL ES 3.0?(I had not found related
> information in OpenGL spec) And Do other OpenGL ES 3.0 implementations(intel
> or non-intel) of attribute aliasing also depend on compiler optimizations?
> Thank you.

Location aliasing is permitted by desktop GL so ES 3.0 is being different here.
I don't now how other implementations do this or if they pass the test.

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

[Mesa-dev] [PATCH v3 2/2] wayland/egl: update surface size on window resize

[Juan A. Suarez Romero]

According to EGL 1.5 spec, section 3.10.1.1 ("Native Window Resizing"):

  "If the native window corresponding to _surface_ has been resized
   prior to the swap, _surface_ must be resized to match. _surface_ will
   normally be resized by the EGL implementation at the time the native
   window is resized. If the implementation cannot do this transparently
   to the client, then *eglSwapBuffers* must detect the change and
   resize surface prior to copying its pixels to the native window."

So far, resizing a native window in Wayland/EGL was interpreted in Mesa
as a request to resize, which is not executed until the first draw call.
And hence, surface size is not updated until executing it. Thus,
querying the surface size with eglQuerySurface() after a window resize
still returns the old values.

This commit updates the surface size values as soon as the resize is
done, even when the real resize is done in the draw call. This makes the
semantics that any native window resize request take effect inmediately,
and if user calls eglQuerySurface() it will return the new resized
values.

CC: Daniel Stone 
---
 src/egl/drivers/dri2/platform_wayland.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index f62cbbc5c02..279f8addc49 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -198,6 +198,15 @@ resize_callback(struct wl_egl_window *wl_win, void *data)
struct dri2_egl_display *dri2_dpy =
   dri2_egl_display(dri2_surf->base.Resource.Display);
 
+   /* Update the surface size as soon as native window is resized; from user
+* pov, this makes the effect that resize is done inmediately after native
+* window resize, without requiring to wait until the first draw.
+*
+* A more detailed and lengthy explanation can be found at
+* https://lists.freedesktop.org/archives/mesa-dev/2018-June/196474.html
+*/
+   dri2_surf->base.Width = wl_win->width;
+   dri2_surf->base.Height = wl_win->height;
dri2_dpy->flush->invalidate(dri2_surf->dri_drawable);
 }
 
@@ -577,8 +586,8 @@ update_buffers(struct dri2_egl_surface *dri2_surf)
struct dri2_egl_display *dri2_dpy =
   dri2_egl_display(dri2_surf->base.Resource.Display);
 
-   if (dri2_surf->base.Width != dri2_surf->wl_win->width ||
-   dri2_surf->base.Height != dri2_surf->wl_win->height) {
+   if (dri2_surf->base.Width != dri2_surf->wl_win->attached_width ||
+   dri2_surf->base.Height != dri2_surf->wl_win->attached_height) {
 
   dri2_wl_release_buffers(dri2_surf);
 
@@ -1632,8 +1641,8 @@ swrast_update_buffers(struct dri2_egl_surface *dri2_surf)
if (dri2_surf->back)
   return 0;
 
-   if (dri2_surf->base.Width != dri2_surf->wl_win->width ||
-   dri2_surf->base.Height != dri2_surf->wl_win->height) {
+   if (dri2_surf->base.Width != dri2_surf->wl_win->attached_width ||
+   dri2_surf->base.Height != dri2_surf->wl_win->attached_height) {
 
   dri2_wl_release_buffers(dri2_surf);
 
-- 
2.17.1

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

[Mesa-dev] [PATCH v3 1/2] wayland/egl: initialize window surface size to window size

[Juan A. Suarez Romero]

When creating a windows surface with eglCreateWindowSurface(), the
width and height returned by eglQuerySurface(EGL_{WIDTH,HEIGHT}) is
invalid until buffers are updated (like calling glClear()).

But according to EGL 1.5 spec, section 3.5.6 ("Surface Attributes"):

  "Querying EGL_WIDTH and EGL_HEIGHT returns respectively the width and
   height, in pixels, of the surface. For a window or pixmap surface,
   these values are initially equal to the width and height of the
   native window or pixmap with respect to which the surface was
   created"

This fixes dEQP-EGL.functional.color_clears.* CTS tests

v2:
- Do not modify attached_{width,height} (Daniel)
- Do not update size on resizing window (Brendan)

CC: Daniel Stone 
CC: Brendan King 
---
 src/egl/drivers/dri2/platform_wayland.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 63da21cdf55..f62cbbc5c02 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -255,6 +255,9 @@ dri2_wl_create_window_surface(_EGLDriver *drv, _EGLDisplay 
*disp,
   goto cleanup_surf;
}
 
+   dri2_surf->base.Width = window->width;
+   dri2_surf->base.Height = window->height;
+
visual_idx = dri2_wl_visual_idx_from_config(dri2_dpy, config);
assert(visual_idx != -1);
 
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH v2 18/21] i965: Update TexturesUsed after linking the shaders

[Timothy Arceri]

Reviewed-by: Timothy Arceri 

On 12/05/18 19:40, Alejandro Piñeiro wrote:

From: Neil Roberts 

Otherwise if the shader is SPIR-V then SamplerUsed won’t have been
initialised yet so it will end up thinking no textures are used. This
was causing a crash later on if nothing causes it to regenerate
TexturesUsed before the next render.
---
  src/mesa/drivers/dri/i965/brw_link.cpp | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
b/src/mesa/drivers/dri/i965/brw_link.cpp
index 996465f305a..0203c44f1cb 100644
--- a/src/mesa/drivers/dri/i965/brw_link.cpp
+++ b/src/mesa/drivers/dri/i965/brw_link.cpp
@@ -246,7 +246,6 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg)
_mesa_copy_linked_program_data(shProg, shader);
  
prog->ShadowSamplers = shader->shadow_samplers;

-  _mesa_update_shader_textures_used(shProg, prog);
  
bool debug_enabled =

   (INTEL_DEBUG & intel_debug_flag_for_shader_stage(shader->Stage));
@@ -300,6 +299,9 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg)
   continue;
  
struct gl_program *prog = shader->Program;

+
+  _mesa_update_shader_textures_used(shProg, prog);
+
brw_shader_gather_info(prog->nir, prog);
  
NIR_PASS_V(prog->nir, gl_nir_lower_samplers, shProg);



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