Re: [Mesa-dev] [PATCH] mesa: define nir_spirv_supported_capabilities

[Alejandro Piñeiro]

On 07/12/17 06:23, Jason Ekstrand wrote:
> On Wed, Dec 6, 2017 at 8:48 PM, Timothy Arceri  > wrote:
>
> On 07/12/17 00:23, Alejandro Piñeiro wrote:
>
> On 06/12/17 13:29, Pierre Moreau wrote:
>
> Hello Alejandro,
>
> As far as I understand, nir_spirv_supported_capabilities
> is being filled in by
> the driver and then fetched by the API entrypoint to check
> the capabilities
> required by the SPIR-V binary given as input. And this is
> done regardless of
> the input IR used by the driver, be it NIR, LLVM IR, TGSI
> or others. So
> couldn’t it be just named spirv_supported_capabilities?
> Unless it also reflects
> the capabilities supported by the IR being used.
>
>
> Good point. spirv_supported_capabilities is probably a better
> name,
> although right now, it would be only used on the spirv to nir
> pass. I
> will not send a new version of the patch with just the
> renaming, but for
> anyone interested on review the commit, I will use that name.
>
>
> I would be much happier with this being in mtypes.h with that
> name. So if renamed:
>
>
> Ugh... I just now got around to looking at this and saw that it went
> in mtypes.h.  Can we please move it?  We've worked very hard to keep
> the Vulkan driver from having to pull in any GL headers and data
> structures and now a fairly core piece lives in mtypes.h.

Hmm, sorry for not waiting for more feedback. This is the second
reviewed patch that modify mtypes.h, so I assumed that it was fine.

Additionally, I didn't rename it as Ian's review didn't ask to, but both
Timothy and Pierre prefer a more general "spirv_supported_capabilities".
So how about this?:
   * Rename it to spirv_supported_capabilities
   * Move it to compiler/spirv/spirv.h (would need to add #include
 due the booleans on the struct there)
   * Add a "compiler/spirv/spirv.h" include on mtypes.h

I already have the patches locally, so if you agree with this, it is
just about sending them.

>
> --Jason
>  
>
> Reviewed-by: Timothy Arceri  >
>
>
>
> I guess nir_spirv_supported_capabilities could be extended
> later on to also add
> capabilities specific to OpenCL when clover reaches OpenCL
> 1.2 support (and can
> start accepting SPIR-V binaries as input through the
> cl_khr_il_program
> extension), or would it be better to have a separate one
> for OpenCL?
>
>
> Probably it would be re-used, but I don't know the specifics
> of OpenCL
> to ensure 100% that.
>
>
> I haven’t had time to look at the whole gl_spirv series
> yet, so I am sorry if
> this is something that has already been brought and
> answered in that thread.
>
>
> No sorries, your feedback was good and welcomed.
>
>
> Regards,
> Pierre
>
> On 2017-12-06 — 09 :57,
> Alejandro Piñeiro wrote:
>
> Until now it was part of spirv_to_nir_options. But it
> will be used on
> the implementation of ARB_gl_spirv and
> ARB_spirv_extensions, and added
> to the OpenGL context, as a way to save what SPIR-V
> capabilities the
> current OpenGL implementation supports.
> ---
>
> We are sending this commit in advance of a v3 of the
> initial gl_spirv
> and spirv_extensions support series. The issue is that
> lately there
> were a lot of activity on the spirv/spir_to_nir code
> base, and we are
> being fixing rebase conflicts constantly. Getting this
> commit on
> master would make things easier.
>
> FWIW, this patch is similar to one that Ian Romanick
> already granted
> Rb, but that was dropped after all the mentioned changes:
> 
> https://lists.freedesktop.org/archives/mesa-dev/2017-November/178261.html
> 
> 
>
>   src/compiler/spirv/nir_spirv.h | 16 +++-
>   src/mesa/main/mtypes.h         | 12 
>   2 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/src/compiler/spirv/nir_spirv.h
> b/src/compiler/spirv/nir_spirv.h
> index 43ec19d5a50..113bd710a00 100644
> --- a/src/compiler/spirv/nir_spirv.h
> +++ b/src/compiler/spirv/nir_spirv.h
> @@ -28,7 +28,8 @@
>  

[Mesa-dev] [PATCH] mesa/spirv: move and rename nir_spirv_supported_capabilities

[Alejandro Piñeiro]

To avoid any vulkan driver to include the GL mtypes.h. Renamed as
eventually this could be used by drivers not using nir.
---

Sending the proposed alternative in advance, so if Jason agrees, it is
just about Rb it.

 src/compiler/spirv/nir_spirv.h |  4 ++--
 src/compiler/spirv/spirv.h | 15 +++
 src/mesa/main/mtypes.h | 14 +-
 3 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/src/compiler/spirv/nir_spirv.h b/src/compiler/spirv/nir_spirv.h
index 113bd710a00..71f44e07dba 100644
--- a/src/compiler/spirv/nir_spirv.h
+++ b/src/compiler/spirv/nir_spirv.h
@@ -29,7 +29,7 @@
 #define _NIR_SPIRV_H_
 
 #include "compiler/nir/nir.h"
-#include "main/mtypes.h"
+#include "compiler/spirv/spirv.h"
 
 #ifdef __cplusplus
 extern "C" {
@@ -58,7 +58,7 @@ struct spirv_to_nir_options {
 */
bool lower_workgroup_access_to_offsets;
 
-   struct nir_spirv_supported_capabilities caps;
+   struct spirv_supported_capabilities caps;
 
struct {
   void (*func)(void *private_data,
diff --git a/src/compiler/spirv/spirv.h b/src/compiler/spirv/spirv.h
index 61559a1c9ca..ce2dcf7657f 100644
--- a/src/compiler/spirv/spirv.h
+++ b/src/compiler/spirv/spirv.h
@@ -48,6 +48,8 @@
 #ifndef spirv_H
 #define spirv_H
 
+#include 
+
 typedef unsigned int SpvId;
 
 #define SPV_VERSION 0x10200
@@ -994,5 +996,18 @@ typedef enum SpvOp_ {
 SpvOpMax = 0x7fff,
 } SpvOp;
 
+struct spirv_supported_capabilities {
+   bool float64;
+   bool image_ms_array;
+   bool tessellation;
+   bool draw_parameters;
+   bool image_read_without_format;
+   bool image_write_without_format;
+   bool int64;
+   bool multiview;
+   bool variable_pointers;
+   bool storage_16bit;
+};
+
 #endif  // #ifndef spirv_H
 
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 7b7137624c7..0f1a0f70827 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -49,6 +49,7 @@
 #include "util/bitscan.h"
 #include "util/simple_mtx.h"
 #include "util/u_dynarray.h"
+#include "compiler/spirv/spirv.h"
 
 
 #ifdef __cplusplus
@@ -3578,19 +3579,6 @@ struct gl_program_constants
GLuint MaxShaderStorageBlocks;
 };
 
-struct nir_spirv_supported_capabilities {
-   bool float64;
-   bool image_ms_array;
-   bool tessellation;
-   bool draw_parameters;
-   bool image_read_without_format;
-   bool image_write_without_format;
-   bool int64;
-   bool multiview;
-   bool variable_pointers;
-   bool storage_16bit;
-};
-
 /**
  * Constants which may be overridden by device driver during context creation
  * but are never changed after that.
-- 
2.11.0

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

[Mesa-dev] [PATCH v2] mesa/spirv: move and rename nir_spirv_supported_capabilities

[Alejandro Piñeiro]

To avoid any vulkan driver to include the GL mtypes.h. Renamed as
eventually this could be used by drivers not using nir.

v2: remove compiler/spirv/spirv.h from mtypes (Alejandro)
---

The include on v1 was a leftover, when I tested if adding the
SpirVCapabilities on gl_constant was working fine, but it is not
needed on this patch, but on a following one.

Sorry for the noise.

 src/compiler/spirv/nir_spirv.h |  4 ++--
 src/compiler/spirv/spirv.h | 15 +++
 src/mesa/main/mtypes.h | 13 -
 3 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/src/compiler/spirv/nir_spirv.h b/src/compiler/spirv/nir_spirv.h
index 113bd710a00..71f44e07dba 100644
--- a/src/compiler/spirv/nir_spirv.h
+++ b/src/compiler/spirv/nir_spirv.h
@@ -29,7 +29,7 @@
 #define _NIR_SPIRV_H_
 
 #include "compiler/nir/nir.h"
-#include "main/mtypes.h"
+#include "compiler/spirv/spirv.h"
 
 #ifdef __cplusplus
 extern "C" {
@@ -58,7 +58,7 @@ struct spirv_to_nir_options {
 */
bool lower_workgroup_access_to_offsets;
 
-   struct nir_spirv_supported_capabilities caps;
+   struct spirv_supported_capabilities caps;
 
struct {
   void (*func)(void *private_data,
diff --git a/src/compiler/spirv/spirv.h b/src/compiler/spirv/spirv.h
index 61559a1c9ca..ce2dcf7657f 100644
--- a/src/compiler/spirv/spirv.h
+++ b/src/compiler/spirv/spirv.h
@@ -48,6 +48,8 @@
 #ifndef spirv_H
 #define spirv_H
 
+#include 
+
 typedef unsigned int SpvId;
 
 #define SPV_VERSION 0x10200
@@ -994,5 +996,18 @@ typedef enum SpvOp_ {
 SpvOpMax = 0x7fff,
 } SpvOp;
 
+struct spirv_supported_capabilities {
+   bool float64;
+   bool image_ms_array;
+   bool tessellation;
+   bool draw_parameters;
+   bool image_read_without_format;
+   bool image_write_without_format;
+   bool int64;
+   bool multiview;
+   bool variable_pointers;
+   bool storage_16bit;
+};
+
 #endif  // #ifndef spirv_H
 
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 7b7137624c7..397b113dfbc 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3578,19 +3578,6 @@ struct gl_program_constants
GLuint MaxShaderStorageBlocks;
 };
 
-struct nir_spirv_supported_capabilities {
-   bool float64;
-   bool image_ms_array;
-   bool tessellation;
-   bool draw_parameters;
-   bool image_read_without_format;
-   bool image_write_without_format;
-   bool int64;
-   bool multiview;
-   bool variable_pointers;
-   bool storage_16bit;
-};
-
 /**
  * Constants which may be overridden by device driver during context creation
  * but are never changed after that.
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH] nir/opcodes: Fix constant-folding of bitfield_insert

[Alex Smith]

Pushed.

On 6 December 2017 at 17:35, Matt Turner  wrote:

> On Wed, Dec 6, 2017 at 3:55 AM, James Legg 
> wrote:
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104119
> > CC: 
> > CC: Samuel Pitoiset 
> > ---
> >  src/compiler/nir/nir_opcodes.py | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_
> opcodes.py
> > index ac7333fe78..278562b2bd 100644
> > --- a/src/compiler/nir/nir_opcodes.py
> > +++ b/src/compiler/nir/nir_opcodes.py
> > @@ -724,12 +724,12 @@ opcode("bitfield_insert", 0, tuint32, [0, 0, 0, 0],
> >  unsigned base = src0, insert = src1;
> >  int offset = src2, bits = src3;
> >  if (bits == 0) {
> > -   dst = 0;
> > +   dst = base;
> >  } else if (offset < 0 || bits < 0 || bits + offset > 32) {
> > dst = 0;
> >  } else {
> > unsigned mask = ((1ull << bits) - 1) << offset;
> > -   dst = (base & ~mask) | ((insert << bits) & mask);
> > +   dst = (base & ~mask) | ((insert << offset) & mask);
> >  }
> >  """)
>
> Reviewed-by: Matt Turner 
> ___
> 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 104119] radv: OpBitFieldInsert produces 0 with a loop counter for Insert

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #7 from Samuel Pitoiset  ---
Fixed.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=947470d10ba5ab11a75f0e19e124b189ff3fd8b2

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

Re: [Mesa-dev] [PATCH v2 19/25] mesa/glspirv: Add a _mesa_spirv_link_shaders() placeholder

[Eduardo Lima Mitev]

On 12/07/2017 05:51 AM, Timothy Arceri wrote:
> Please squash this with patch 22 tis is just code churn.
>

Ok, this makes sense, though I will have to re-order a bit the patches
to keep each single one building fine.

I the squashed result would keep your R-b from patch 22, right?

thnaks,
Eduardo

> On 01/12/17 04:28, Eduardo Lima Mitev wrote:
>> This will be the equivalent to link_shaders() from
>> src/compiler/glsl/linker.cpp, but for SPIR-V programs.
>> ---
>>   src/mesa/main/glspirv.c | 10 ++
>>   src/mesa/main/glspirv.h |  4 
>>   2 files changed, 14 insertions(+)
>>
>> diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
>> index 18710c0d8fc..e533853f7fa 100644
>> --- a/src/mesa/main/glspirv.c
>> +++ b/src/mesa/main/glspirv.c
>> @@ -104,6 +104,16 @@ _mesa_spirv_shader_binary(struct gl_context *ctx,
>>  }
>>   }
>>   +void
>> +_mesa_spirv_link_shaders(struct gl_context *ctx, struct
>> gl_shader_program *prog)
>> +{
>> +   /* @TODO: This is a placeholder for the equivalent of
>> +    * compiler/glsl/linker.cpp::link_shaders() but for SPIR-V.
>> +    */
>> +   prog->data->LinkStatus = linking_success;
>> +   prog->data->Validated = false;
>> +}
>> +
>>   void GLAPIENTRY
>>   _mesa_SpecializeShaderARB(GLuint shader,
>>     const GLchar *pEntryPoint,
>> diff --git a/src/mesa/main/glspirv.h b/src/mesa/main/glspirv.h
>> index ba281f68bef..0f03b75c111 100644
>> --- a/src/mesa/main/glspirv.h
>> +++ b/src/mesa/main/glspirv.h
>> @@ -76,6 +76,10 @@ _mesa_spirv_shader_binary(struct gl_context *ctx,
>>     unsigned n, struct gl_shader **shaders,
>>     const void* binary, size_t length);
>>   +void
>> +_mesa_spirv_link_shaders(struct gl_context *ctx,
>> + struct gl_shader_program *prog);
>> +
>>   /**
>>    * \name API functions
>>    */
>>
>

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

Re: [Mesa-dev] [RFC] r600/evergreen compute shader + glsl 4.30 support

[Gert Wollny]

Am Donnerstag, den 07.12.2017, 09:35 +1000 schrieb Dave Airlie:
> 
> 
> I've pushed a bunch of the code, except for the final enables,
> 
> Care to give my r600-gl-4.3 branch a spin?

It shows quite some regressions w.r.t the WIP branch:

 WIP   gl-4.3

  execution/atomic-counter:  pass fail
  execution/basic-global-id: pass fail
  execution/basic-group-id:  pass fail
  execution/basic-group-id-x:pass fail
  execution/basic-group-id-z:pass fail
  execution/basic-local-id-atomic:   pass fail
  execution/basic-local-index:   pass fail
  execution/basic-ssbo:  pass fail
  execution/basic-texelfetch:pass fail
  execution/basic-uniform-access-atomic: pass fail
  execution/border-color: pass fail
  execution/multiple-texture-reading: pass fail
  execution/separate-global-id:   pass fail
  execution/separate-global-id-2: pass fail
  execution/shared-atomics:   pass fail
  execution/simple-barrier-atomics:   pass fail

(all other shader piglits equal)
> 
> It has the workaround I think I need to stabilise stuff for now.
> 
Best, 
Gert 

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

Re: [Mesa-dev] testing for certain compiler options does not work

[Marc Dietrich]

Hi Ian,

Am Mittwoch, 6. Dezember 2017, 21:21:53 CET schrieb Ian Romanick:
> On 11/29/2017 08:16 AM, Marc Dietrich wrote:
> > Hi,
> > 
> > just found that my gcc 'gcc (SUSE Linux) 7.2.1 20171020 [gcc-7-branch
> > revision 253932]' does not warn when using the negative form of
> > unsupported warning options. So all the configure tests for such options
> > erroneously succeed, e.g:
> > 
> > gcc -Wno-bob test.c # works fine
> > 
> > gcc -Walice test.c # warns for unsupported compiler option
> > 
> > Maybe gcc bug or intended behaviour, maybe only unique to my version?
> 
> At least 6.4.1 does not have this problem, but our checks must be broken
> in a different way.  I see piles of

I just found that this is not a gcc bug but a feature (since 4.4), so this 
should also happen with your compiler:

https://gcc.gnu.org/wiki/FAQ#wnowarning

> 
> cc1: warning: unrecognized command line option ‘-Wno-initializer-
overrides’

this should not happen, because this is the clang option which fails with gcc. 
Is this with meson or autotools? Are you sure you applied the patch? I tested 
it with both, gcc and clang and it works file here.


> This probably explains why I see piles of
> 
> cc1: warning: unrecognized command line option ‘-Wno-initializer-
overrides’
> 
> in my builds.


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

[Mesa-dev] [PATCH] radv: fix TC-compat HTILE with VK_FORMAT_D32_SFLOAT_S8_UINT on Vega

[Samuel Pitoiset]

Copied from RadeonSI.

This fixes all CTS
dEQP-VK.renderpass.dedicated_allocation.formats.d32_sfloat_s8_uint.clear.*

And some other ones which use the same format.

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

diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 5c53e81637..efd17e4889 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -416,6 +416,12 @@ si_make_texture_descriptor(struct radv_device *device,
data_format = 0;
}
 
+   /* S8 with Z32 HTILE needs a special format. */
+   if (device->physical_device->rad_info.chip_class >= GFX9 &&
+   vk_format == VK_FORMAT_S8_UINT &&
+   image->tc_compatible_htile)
+   data_format = V_008F14_IMG_DATA_FORMAT_S8_32;
+
type = radv_tex_dim(image->type, view_type, image->info.array_size, 
image->info.samples,
is_storage_image, 
device->physical_device->rad_info.chip_class >= GFX9);
if (type == V_008F1C_SQ_RSRC_IMG_1D_ARRAY) {
-- 
2.15.1

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

[Mesa-dev] [PATCH mesa v2] meson: fix pl111 dependency on vc4

[Eric Engestrom]

src/gallium/winsys/pl111/drm/libpl111winsys.a(pl111_drm_winsys.c.o): In 
function `pl111_drm_screen_create':
pl111_drm_winsys.c:(.text+0x33): undefined reference to 
`vc4_drm_screen_create_renderonly'

Signed-off-by: Eric Engestrom 
Reviewed-by: Dylan Baker  (v1)
---
(sent a v2 because the rebase wasn't completely trivial)
v2: move error message with the imx/etnaviv one and reword it to match
---
 meson.build  |  3 +++
 src/gallium/meson.build  | 10 +-
 src/gallium/winsys/pl111/drm/meson.build |  1 +
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/meson.build b/meson.build
index 3e8ea7d17e06e9ededb0..1ea63fb12915c93a67d5 100644
--- a/meson.build
+++ b/meson.build
@@ -190,6 +190,9 @@ endif
 if with_gallium_imx and not with_gallium_etnaviv
   error('IMX driver requires etnaviv driver')
 endif
+if with_gallium_pl111 and not with_gallium_vc4
+  error('pl111 driver requires vc4 driver')
+endif
 
 dep_libdrm_intel = []
 if with_dri_i915 or with_gallium_i915
diff --git a/src/gallium/meson.build b/src/gallium/meson.build
index 7e841633a9c837658370..2baca8a97ca3cfe36ff1 100644
--- a/src/gallium/meson.build
+++ b/src/gallium/meson.build
@@ -72,17 +72,17 @@ if with_gallium_freedreno
 else
   driver_freedreno = declare_dependency()
 endif
-if with_gallium_pl111
-  subdir('winsys/pl111/drm')
-else
-  driver_pl111 = declare_dependency()
-endif
 if with_gallium_vc4
   subdir('winsys/vc4/drm')
   subdir('drivers/vc4')
 else
   driver_vc4 = declare_dependency()
 endif
+if with_gallium_pl111
+  subdir('winsys/pl111/drm')
+else
+  driver_pl111 = declare_dependency()
+endif
 if with_gallium_vc5
   subdir('winsys/vc5/drm')
   subdir('drivers/vc5')
diff --git a/src/gallium/winsys/pl111/drm/meson.build 
b/src/gallium/winsys/pl111/drm/meson.build
index 8ba03e3f9795009c725d..9cb6faf31e21e57bd6ab 100644
--- a/src/gallium/winsys/pl111/drm/meson.build
+++ b/src/gallium/winsys/pl111/drm/meson.build
@@ -27,6 +27,7 @@ libpl111winsys = static_library(
   ],
   c_args : [c_vis_args],
   dependencies: dep_libdrm,
+  link_with : libvc4winsys,
 )
 
 driver_pl111 = declare_dependency(
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [PATCH] util/disk_cache: Remove unneeded free() on always null string

[Eric Engestrom]

On Monday, 2017-12-04 11:47:33 +0200, vadim.shovkopl...@gmail.com wrote:
> From: Vadym Shovkoplias 
> 
> At this point dc_job->cache_item_metadata.keys always equals
> NULL, so call to free() is useless
> 
> Fixes: b86ecea3446 ("util/disk_cache: write cache item metadata to disk")
> Signed-off-by: Vadym Shovkoplias 

R-b and pushed, thanks :)

> 
> ---
>  src/util/disk_cache.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
> index e954065..7ebfa8c 100644
> --- a/src/util/disk_cache.c
> +++ b/src/util/disk_cache.c
> @@ -811,7 +811,6 @@ create_put_job(struct disk_cache *cache, const cache_key 
> key,
> return dc_job;
>  
>  fail:
> -   free(dc_job->cache_item_metadata.keys);
> free(dc_job);
>  
> return NULL;
> -- 
> 2.7.4
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] V3 i965/Gallium ARB_get_program_binary support

[Tapani Pälli]

Hi;

I've been testing this functionality with little app I have and I 
noticed one thing by accident.


If I call link twice for a regular program like this:

glLinkProgram(program);
glLinkProgram(program);

everything's fine, sequential calls do not generate errors. However for 
program loaded via glProgramBinaryOES it seems not ok for some reason. 
Should it be? It throws error on glUseProgram() saying that program not 
linked.


Thanks;

On 11/29/2017 03:24 AM, Timothy Arceri wrote:

V3:
This is basically the V2 that Jordan sent with feedback addressed,
gallium support added, some minor functional changes such as only
storing the default uniforms to either disk or program binary cache
(rather than fixing them up later) and some refactoring to allow
greater code sharing between gallium and i965.

This series adds i965/gallium support for ARB_get_program_binary
with greater than 0 supported formats. Today we support this extension,
but advertise support for 0 formats. This series allows i965/gallium
to advertise support for 1 format.

This series defines a common Mesa format for ARB_get_program_binary,
along with helper functions to read and write the format. The binary
saved can only be reloaded on the exact same Mesa build using the
exact same hardware.

The i965/gallium implementation saves out a serialized nir/tgsi
represenation of the program. For i965 we can later add support for
saving the gen binary program as well. (We will still need the nir
program for state based recompiles.)

This implementation passes piglit, deqp and glcts functions. It also
works with (and fixes a crash in) Dead Island with makes use of the
extension.

___
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] V3 i965/Gallium ARB_get_program_binary support

[Tapani Pälli]

On 12/07/2017 01:47 PM, Tapani Pälli wrote:

Hi;

I've been testing this functionality with little app I have and I 
noticed one thing by accident.


If I call link twice for a regular program like this:

glLinkProgram(program);
glLinkProgram(program);

everything's fine, sequential calls do not generate errors. However for 
program loaded via glProgramBinaryOES it seems not ok for some reason. 
Should it be? It throws error on glUseProgram() saying that program not 
linked.


Studying specs a bit more it is supposed to fail, there are no shaders 
to link. If I attach new shaders after glProgramBinaryOES and then call 
glLinkProgram() it links succesfully and works fine. So no worries!




Thanks;

On 11/29/2017 03:24 AM, Timothy Arceri wrote:

V3:
This is basically the V2 that Jordan sent with feedback addressed,
gallium support added, some minor functional changes such as only
storing the default uniforms to either disk or program binary cache
(rather than fixing them up later) and some refactoring to allow
greater code sharing between gallium and i965.

This series adds i965/gallium support for ARB_get_program_binary
with greater than 0 supported formats. Today we support this extension,
but advertise support for 0 formats. This series allows i965/gallium
to advertise support for 1 format.

This series defines a common Mesa format for ARB_get_program_binary,
along with helper functions to read and write the format. The binary
saved can only be reloaded on the exact same Mesa build using the
exact same hardware.

The i965/gallium implementation saves out a serialized nir/tgsi
represenation of the program. For i965 we can later add support for
saving the gen binary program as well. (We will still need the nir
program for state based recompiles.)

This implementation passes piglit, deqp and glcts functions. It also
works with (and fixes a crash in) Dead Island with makes use of the
extension.

___
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 04/23] main, glsl: Add UniformDataDefaults which stores uniform defaults

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 11/29/2017 03:24 AM, Timothy Arceri wrote:

From: Jordan Justen 

The ARB_get_program_binary extension requires that uniform values in a
program be restored to their initial value just after linking.

This patch saves off the initial values just after linking. When the
program is restored by glProgramBinary, we can use this to copy the
initial value of uniforms into UniformDataSlots.

V2 (Timothy Arceri):
  - Store UniformDataDefaults only when serializing GLSL as this
is what we want for both disk cache and ARB_get_program_binary.
This saves us having to come back later and reset the Uniforms
on program binary restores.

Signed-off-by: Timothy Arceri 
Signed-off-by: Jordan Justen  (v1)
---
  src/compiler/glsl/link_uniform_initializers.cpp |  2 ++
  src/compiler/glsl/link_uniforms.cpp |  3 +++
  src/compiler/glsl/serialize.cpp | 16 ++--
  src/mesa/main/mtypes.h  | 11 +++
  4 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/link_uniform_initializers.cpp 
b/src/compiler/glsl/link_uniform_initializers.cpp
index f70d9100e12..2395f5cf695 100644
--- a/src/compiler/glsl/link_uniform_initializers.cpp
+++ b/src/compiler/glsl/link_uniform_initializers.cpp
@@ -347,12 +347,14 @@ link_set_uniform_initializers(struct gl_shader_program 
*prog,
 assert(!"Explicit binding not on a sampler, UBO or atomic.");
  }
   } else if (var->constant_initializer) {
  linker::set_uniform_initializer(mem_ctx, prog, var->name,
  var->type, 
var->constant_initializer,
  boolean_true);
   }
}
 }
  
+   memcpy(prog->data->UniformDataDefaults, prog->data->UniformDataSlots,

+  sizeof(union gl_constant_value) * prog->data->NumUniformDataSlots);
 ralloc_free(mem_ctx);
  }
diff --git a/src/compiler/glsl/link_uniforms.cpp 
b/src/compiler/glsl/link_uniforms.cpp
index 46c746bc701..15813cb0aed 100644
--- a/src/compiler/glsl/link_uniforms.cpp
+++ b/src/compiler/glsl/link_uniforms.cpp
@@ -1358,20 +1358,23 @@ link_assign_uniform_storage(struct gl_context *ctx,
  
 unsigned int boolean_true = ctx->Const.UniformBooleanTrue;
  
 union gl_constant_value *data;

 if (prog->data->UniformStorage == NULL) {
prog->data->UniformStorage = rzalloc_array(prog->data,
   struct gl_uniform_storage,
   
prog->data->NumUniformStorage);
data = rzalloc_array(prog->data->UniformStorage,
 union gl_constant_value, num_data_slots);
+  prog->data->UniformDataDefaults =
+ rzalloc_array(prog->data->UniformStorage,
+   union gl_constant_value, num_data_slots);
 } else {
data = prog->data->UniformDataSlots;
 }
  
  #ifndef NDEBUG

 union gl_constant_value *data_end = &data[num_data_slots];
  #endif
  
 parcel_out_uniform_storage parcel(prog, prog->UniformHash,

   prog->data->UniformStorage, data,
diff --git a/src/compiler/glsl/serialize.cpp b/src/compiler/glsl/serialize.cpp
index 81781f32dfd..529b74e2002 100644
--- a/src/compiler/glsl/serialize.cpp
+++ b/src/compiler/glsl/serialize.cpp
@@ -442,21 +442,24 @@ write_uniforms(struct blob *metadata, struct 
gl_shader_program *prog)
  * uniforms with initialisers and also hidden uniforms that may be lowered
  * constant arrays. We could possibly just store the values we need but for
  * now we just store everything.
  */
 blob_write_uint32(metadata, prog->data->NumHiddenUniforms);
 for (unsigned i = 0; i < prog->data->NumUniformStorage; i++) {
if (has_uniform_storage(prog, i)) {
   unsigned vec_size =
  prog->data->UniformStorage[i].type->component_slots() *
  MAX2(prog->data->UniformStorage[i].array_elements, 1);
- blob_write_bytes(metadata, prog->data->UniformStorage[i].storage,
+ unsigned slot =
+prog->data->UniformStorage[i].storage -
+prog->data->UniformDataSlots;
+ blob_write_bytes(metadata, &prog->data->UniformDataDefaults[slot],
sizeof(union gl_constant_value) * vec_size);
}
 }
  }
  
  static void

  read_uniforms(struct blob_reader *metadata, struct gl_shader_program *prog)
  {
 struct gl_uniform_storage *uniforms;
 union gl_constant_value *data;
@@ -465,20 +468,23 @@ read_uniforms(struct blob_reader *metadata, struct 
gl_shader_program *prog)
 prog->data->NumUniformStorage = blob_read_uint32(metadata);
 prog->data->NumUniformDataSlots = blob_read_uint32(metadata);
  
 uniforms = rzalloc_array(prog->data, struct gl_uniform_storage,

  prog->data->NumUniformStorage);
 prog->dat

Re: [Mesa-dev] [PATCH] meson: Fix building gallium media targets with gallium-xlib glx

[Eric Engestrom]

On Tuesday, 2017-12-05 09:40:53 -0800, Dylan Baker wrote:
> Signed-off-by: Dylan Baker 
> ---
>  meson.build | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 3e8ea7d17e0..bf6bd551f08 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1107,9 +1107,9 @@ if with_platform_x11
>  dep_xcb_glx = dependency('xcb-glx', version : '>= 1.8.1')
>  dep_xxf86vm = dependency('xxf86vm', required : false)
>endif
> -  if with_any_vk or with_glx == 'dri' or
> -  (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx or
> -   with_gallium_xa)
> +  if (with_any_vk or with_glx == 'dri' or
> +   (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx or
> +with_gallium_xa))

Hmm, works for me without this, on both meson 43 and 44; I'm guessing
meson 42 fails to parse this?

Either way, it doesn't hurt, so:
Reviewed-by: Eric Engestrom 

>  dep_xcb = dependency('xcb')
>  dep_x11_xcb = dependency('x11-xcb')
>endif
> -- 
> 2.15.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] egl/android: Provide an option for the backend to expose KHR_image

[Harish Krupo]

From android cts 8.0_r4, a new test case checks if all the required egl
extensions are exposed. In the current implementation we expose KHR_image
if KHR_image_base and KHR_image_pixmap are supported but KHR_image spec
does not mandate the existence of both the extensions.
This patch preserves the current check and also provides the backend
with an option to expose the KHR_image extension.

Test: run cts -m CtsOpenGLTestCases -t \
android.opengl.cts.OpenGlEsVersionTest#testRequiredEglExtensions

Signed-off-by: Harish Krupo 
---
 src/egl/drivers/dri2/platform_android.c | 1 +
 src/egl/main/eglapi.c   | 3 ++-
 src/egl/main/egldisplay.h   | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 63223e9a69..0459cc8be2 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1212,6 +1212,7 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay *dpy)
 #if ANDROID_API_LEVEL >= 23
dpy->Extensions.KHR_partial_update = EGL_TRUE;
 #endif
+   dpy->Extensions.KHR_image = EGL_TRUE;
 
/* Fill vtbl last to prevent accidentally calling virtual function during
 * initialization.
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index cec67425e1..5110688f2d 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -504,7 +504,8 @@ _eglCreateExtensionsString(_EGLDisplay *dpy)
_EGL_CHECK_EXTENSION(KHR_gl_texture_3D_image);
_EGL_CHECK_EXTENSION(KHR_gl_texture_cubemap_image);
if (dpy->Extensions.KHR_image_base && dpy->Extensions.KHR_image_pixmap)
-  _eglAppendExtension(&exts, "EGL_KHR_image");
+  dpy->Extensions.KHR_image = EGL_TRUE;
+   _EGL_CHECK_EXTENSION(KHR_image);
_EGL_CHECK_EXTENSION(KHR_image_base);
_EGL_CHECK_EXTENSION(KHR_image_pixmap);
_EGL_CHECK_EXTENSION(KHR_no_config_context);
diff --git a/src/egl/main/egldisplay.h b/src/egl/main/egldisplay.h
index 52fb4ce21b..0005c81836 100644
--- a/src/egl/main/egldisplay.h
+++ b/src/egl/main/egldisplay.h
@@ -122,6 +122,7 @@ struct _egl_extensions
EGLBoolean KHR_gl_texture_2D_image;
EGLBoolean KHR_gl_texture_3D_image;
EGLBoolean KHR_gl_texture_cubemap_image;
+   EGLBoolean KHR_image;
EGLBoolean KHR_image_base;
EGLBoolean KHR_image_pixmap;
EGLBoolean KHR_no_config_context;
-- 
2.15.1

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

Re: [Mesa-dev] [PATCH v4] egl/wayland: Support for KHR_partial_update

[Harish Krupo]

Harish Krupo  writes:

> This passes 33/37 deqp tests related to partial_update, 4 are not
> supported. Tests not supported:
> dEQP-EGL.functional.negative_partial_update.not_postable_surface
> dEQP-EGL.functional.negative_partial_update.not_current_surface
> dEQP-EGL.functional.negative_partial_update.buffer_preserved
> dEQP-EGL.functional.negative_partial_update.not_current_surface2
> Reason: No matching egl config found.
>
> v2: Remove unnecessary return statement. Keep function names
> consistent.  (Emil Velikov)
> Add not supported list to commit message. (Eric Engestrom)
>
> v3: Remove explicit with_damage variable and swap_buffers_common
> function. Make SwapBuffers and SwapBuffersWithDamage(NULL,0)
> equivalent in behavior. Fix called via comment for
> swap_buffers_with_damage. (Eric Engestrom)
> Rework try_buffer_damage into set_damage_region as it is being
> called only from set_damage_region.
>
> v4: Undo the rework done in v3. Fix code indentation (Emil Velikov)
>
> Signed-off-by: Harish Krupo 
> ---
>  src/egl/drivers/dri2/platform_wayland.c | 36 
> -
>  1 file changed, 31 insertions(+), 5 deletions(-)
>

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

Re: [Mesa-dev] [PATCH 12/23] mesa: Add Mesa ARB_get_program_binary helper functions

[Tapani Pälli]

This looks good as well, I've spent also some quality debugger time 
today with these bits and my EGL_ANDROID_blob_cache branch. I'll be 
using these functions and probably do some minor refactors so that 
glGetProgramBinary() errors won't get printed when Android cache calls this.


Reviewed-by: Tapani Pälli 

On 29.11.2017 03:24, Timothy Arceri wrote:

From: Jordan Justen 

V2 (Timothy Arceri):
  - add extra code comment
  - stop passing around void *binary and just pass
program_binary_header *hdr instead.
  - move to src/mesa/main rather than src/util

V3 (Timothy Arceri):
  - Move more code out of the backend and into the common
helpers.

Signed-off-by: Jordan Justen 
---
  src/mesa/Makefile.sources  |   2 +
  src/mesa/main/program_binary.c | 291 +
  src/mesa/main/program_binary.h |  56 
  src/mesa/meson.build   |   2 +
  4 files changed, 351 insertions(+)
  create mode 100644 src/mesa/main/program_binary.c
  create mode 100644 src/mesa/main/program_binary.h

diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 6da1e3fef9d..d8b1eb1f995 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -166,20 +166,22 @@ MAIN_FILES = \
main/pixel.c \
main/pixel.h \
main/pixelstore.c \
main/pixelstore.h \
main/pixeltransfer.c \
main/pixeltransfer.h \
main/points.c \
main/points.h \
main/polygon.c \
main/polygon.h \
+   main/program_binary.c \
+   main/program_binary.h \
main/program_resource.c \
main/program_resource.h \
main/querymatrix.c \
main/querymatrix.h \
main/queryobj.c \
main/queryobj.h \
main/rastpos.c \
main/rastpos.h \
main/readpix.c \
main/readpix.h \
diff --git a/src/mesa/main/program_binary.c b/src/mesa/main/program_binary.c
new file mode 100644
index 000..2786487362f
--- /dev/null
+++ b/src/mesa/main/program_binary.c
@@ -0,0 +1,291 @@
+/*
+ * Mesa 3-D graphics library
+ *
+ * Copyright (c) 2017 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 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.
+ */
+
+/**
+ * \file program_binary.c
+ *
+ * Helper functions for serializing a binary program.
+ */
+
+
+#include "compiler/blob.h"
+#include "compiler/glsl/serialize.h"
+#include "main/errors.h"
+#include "main/mtypes.h"
+#include "util/crc32.h"
+#include "program_binary.h"
+#include "program/prog_parameter.h"
+
+/**
+ * Mesa supports one binary format, but it must differentiate between formats
+ * produced by different drivers and different Mesa versions.
+ *
+ * Mesa uses a uint32_t value to specify an internal format. The only format
+ * defined has one uint32_t value of 0, followed by 20 bytes specifying a sha1
+ * that uniquely identifies the Mesa driver type and version.
+ */
+
+struct program_binary_header {
+   /* If internal_format is 0, it must be followed by the 20 byte sha1 that
+* identifies the Mesa driver and version supported. If we want to support
+* something besides a sha1, then a new internal_format value can be added.
+*/
+   uint32_t internal_format;
+   uint8_t sha1[20];
+   /* Fields following sha1 can be changed since the sha1 will guarantee that
+* the binary only works with the same Mesa version.
+*/
+   uint32_t size;
+   uint32_t crc32;
+};
+
+/**
+ * Returns the header size needed for a binary
+ */
+static unsigned
+get_program_binary_header_size(void)
+{
+   return sizeof(struct program_binary_header);
+}
+
+static bool
+write_program_binary(const void *payload, unsigned payload_size,
+ const void *sha1, void *binary, unsigned binary_size,
+ GLenum *binary_format)
+{
+   struct program_binary_header *hdr = binary;
+
+   if (binary_size < sizeof(*hdr))
+  return false;
+
+   /* binary_size is the size of the buffer provided by the application.
+ 

Re: [Mesa-dev] [PATCH] egl/android: Provide an option for the backend to expose KHR_image

[Tapani Pälli]

Looks good, indeed KHR_image spec does not require KHR_image_pixmap or 
KHR_image_base. Wayland might also be able to enable this but not sure 
if makes sense there or not.


Reviewed-by: Tapani Pälli 

On 07.12.2017 15:34, Harish Krupo wrote:

 From android cts 8.0_r4, a new test case checks if all the required egl
extensions are exposed. In the current implementation we expose KHR_image
if KHR_image_base and KHR_image_pixmap are supported but KHR_image spec
does not mandate the existence of both the extensions.
This patch preserves the current check and also provides the backend
with an option to expose the KHR_image extension.

Test: run cts -m CtsOpenGLTestCases -t \
android.opengl.cts.OpenGlEsVersionTest#testRequiredEglExtensions

Signed-off-by: Harish Krupo 
---
  src/egl/drivers/dri2/platform_android.c | 1 +
  src/egl/main/eglapi.c   | 3 ++-
  src/egl/main/egldisplay.h   | 1 +
  3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 63223e9a69..0459cc8be2 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1212,6 +1212,7 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay *dpy)
  #if ANDROID_API_LEVEL >= 23
 dpy->Extensions.KHR_partial_update = EGL_TRUE;
  #endif
+   dpy->Extensions.KHR_image = EGL_TRUE;
  
 /* Fill vtbl last to prevent accidentally calling virtual function during

  * initialization.
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index cec67425e1..5110688f2d 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -504,7 +504,8 @@ _eglCreateExtensionsString(_EGLDisplay *dpy)
 _EGL_CHECK_EXTENSION(KHR_gl_texture_3D_image);
 _EGL_CHECK_EXTENSION(KHR_gl_texture_cubemap_image);
 if (dpy->Extensions.KHR_image_base && dpy->Extensions.KHR_image_pixmap)
-  _eglAppendExtension(&exts, "EGL_KHR_image");
+  dpy->Extensions.KHR_image = EGL_TRUE;
+   _EGL_CHECK_EXTENSION(KHR_image);
 _EGL_CHECK_EXTENSION(KHR_image_base);
 _EGL_CHECK_EXTENSION(KHR_image_pixmap);
 _EGL_CHECK_EXTENSION(KHR_no_config_context);
diff --git a/src/egl/main/egldisplay.h b/src/egl/main/egldisplay.h
index 52fb4ce21b..0005c81836 100644
--- a/src/egl/main/egldisplay.h
+++ b/src/egl/main/egldisplay.h
@@ -122,6 +122,7 @@ struct _egl_extensions
 EGLBoolean KHR_gl_texture_2D_image;
 EGLBoolean KHR_gl_texture_3D_image;
 EGLBoolean KHR_gl_texture_cubemap_image;
+   EGLBoolean KHR_image;
 EGLBoolean KHR_image_base;
 EGLBoolean KHR_image_pixmap;
 EGLBoolean KHR_no_config_context;


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

Re: [Mesa-dev] [PATCH] egl/android: Provide an option for the backend to expose KHR_image

[Eric Engestrom]

On Thursday, 2017-12-07 19:04:41 +0530, Harish Krupo wrote:
> From android cts 8.0_r4, a new test case checks if all the required egl
> extensions are exposed. In the current implementation we expose KHR_image
> if KHR_image_base and KHR_image_pixmap are supported but KHR_image spec
> does not mandate the existence of both the extensions.

Indeed, the spec even explicitly states so:
>   The specifications of EGL_KHR_image_base and EGL_KHR_image_pixmap are
>   required to determine the specification of this extension, although
>   those extentions may not be supported.

Reviewed-by: Eric Engestrom 

> This patch preserves the current check and also provides the backend
> with an option to expose the KHR_image extension.
> 
> Test: run cts -m CtsOpenGLTestCases -t \
> android.opengl.cts.OpenGlEsVersionTest#testRequiredEglExtensions
> 
> Signed-off-by: Harish Krupo 
> ---
>  src/egl/drivers/dri2/platform_android.c | 1 +
>  src/egl/main/eglapi.c   | 3 ++-
>  src/egl/main/egldisplay.h   | 1 +
>  3 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index 63223e9a69..0459cc8be2 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -1212,6 +1212,7 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay 
> *dpy)
>  #if ANDROID_API_LEVEL >= 23
> dpy->Extensions.KHR_partial_update = EGL_TRUE;
>  #endif
> +   dpy->Extensions.KHR_image = EGL_TRUE;
>  
> /* Fill vtbl last to prevent accidentally calling virtual function during
>  * initialization.
> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> index cec67425e1..5110688f2d 100644
> --- a/src/egl/main/eglapi.c
> +++ b/src/egl/main/eglapi.c
> @@ -504,7 +504,8 @@ _eglCreateExtensionsString(_EGLDisplay *dpy)
> _EGL_CHECK_EXTENSION(KHR_gl_texture_3D_image);
> _EGL_CHECK_EXTENSION(KHR_gl_texture_cubemap_image);
> if (dpy->Extensions.KHR_image_base && dpy->Extensions.KHR_image_pixmap)
> -  _eglAppendExtension(&exts, "EGL_KHR_image");
> +  dpy->Extensions.KHR_image = EGL_TRUE;

I feel like this doesn't belong here anymore though; should we move it
to platform_*.c, where KHR_image_pixmap is enabled?

This would be a separate patch though, feel free to land this one already.

> +   _EGL_CHECK_EXTENSION(KHR_image);
> _EGL_CHECK_EXTENSION(KHR_image_base);
> _EGL_CHECK_EXTENSION(KHR_image_pixmap);
> _EGL_CHECK_EXTENSION(KHR_no_config_context);
> diff --git a/src/egl/main/egldisplay.h b/src/egl/main/egldisplay.h
> index 52fb4ce21b..0005c81836 100644
> --- a/src/egl/main/egldisplay.h
> +++ b/src/egl/main/egldisplay.h
> @@ -122,6 +122,7 @@ struct _egl_extensions
> EGLBoolean KHR_gl_texture_2D_image;
> EGLBoolean KHR_gl_texture_3D_image;
> EGLBoolean KHR_gl_texture_cubemap_image;
> +   EGLBoolean KHR_image;
> EGLBoolean KHR_image_base;
> EGLBoolean KHR_image_pixmap;
> EGLBoolean KHR_no_config_context;
> -- 
> 2.15.1
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa] meson: add dep_thread to every lib that includes threads.h

[Eric Engestrom]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104141
Signed-off-by: Eric Engestrom 
---
 src/broadcom/meson.build| 2 +-
 src/gallium/auxiliary/meson.build   | 2 +-
 src/gallium/state_trackers/nine/meson.build | 1 +
 src/gallium/targets/xa/meson.build  | 2 +-
 src/gallium/targets/xvmc/meson.build| 2 +-
 src/gbm/meson.build | 2 +-
 src/intel/common/meson.build| 2 +-
 src/loader/meson.build  | 2 +-
 src/util/meson.build| 2 +-
 9 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/src/broadcom/meson.build b/src/broadcom/meson.build
index dbeee091139dcd05ec5a..6072fd1b997bb29b307a 100644
--- a/src/broadcom/meson.build
+++ b/src/broadcom/meson.build
@@ -39,6 +39,6 @@ if with_gallium_vc5
 c_args : [c_vis_args, no_override_init_args],
 link_whole : [libbroadcom_compiler, libbroadcom_qpu],
 build_by_default : false,
-dependencies: dep_valgrind,
+dependencies: [dep_valgrind, dep_thread],
   )
 endif
diff --git a/src/gallium/auxiliary/meson.build 
b/src/gallium/auxiliary/meson.build
index 3e623fd099fe4b60a5de..4d59f07fd31f3a154934 100644
--- a/src/gallium/auxiliary/meson.build
+++ b/src/gallium/auxiliary/meson.build
@@ -495,7 +495,7 @@ libgallium = static_library(
   ],
   c_args : [c_vis_args, c_msvc_compat_args],
   cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
-  dependencies : [dep_libdrm, dep_llvm, dep_unwind, dep_dl, dep_m],
+  dependencies : [dep_libdrm, dep_llvm, dep_unwind, dep_dl, dep_m, dep_thread],
   build_by_default : false,
 )
 
diff --git a/src/gallium/state_trackers/nine/meson.build 
b/src/gallium/state_trackers/nine/meson.build
index 797ef389a69f164d7440..491b7937ab19d754e498 100644
--- a/src/gallium/state_trackers/nine/meson.build
+++ b/src/gallium/state_trackers/nine/meson.build
@@ -66,4 +66,5 @@ libnine_st = static_library(
   include_directories : [
 inc_d3d9, inc_gallium, inc_include, inc_src, inc_gallium_aux,
   ],
+  dependencies : dep_thread,
 )
diff --git a/src/gallium/targets/xa/meson.build 
b/src/gallium/targets/xa/meson.build
index f16921dfc9c443a166b4..f25999d1603c2873897a 100644
--- a/src/gallium/targets/xa/meson.build
+++ b/src/gallium/targets/xa/meson.build
@@ -45,7 +45,7 @@ libxatracker = shared_library(
   ],
   link_depends : xa_link_depends,
   dependencies : [
-dep_xcb, dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, dep_libdrm,
+dep_xcb, dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, dep_libdrm, dep_thread,
 driver_nouveau, driver_i915, driver_svga, driver_freedreno,
   ],
   install : true,
diff --git a/src/gallium/targets/xvmc/meson.build 
b/src/gallium/targets/xvmc/meson.build
index 76de816efed7559602a3..48759de910f88e66b82b 100644
--- a/src/gallium/targets/xvmc/meson.build
+++ b/src/gallium/targets/xvmc/meson.build
@@ -45,7 +45,7 @@ libxvmc_gallium = shared_library(
 libpipe_loader_static, libws_null, libwsw,
   ],
   dependencies : [
-dep_xcb, dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, dep_libdrm,
+dep_xcb, dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, dep_libdrm, dep_thread,
 driver_r600, driver_nouveau,
   ],
   link_depends : xvmc_link_depends,
diff --git a/src/gbm/meson.build b/src/gbm/meson.build
index 4b550e06f2790ae9a13d..6e512996add1cfadd189 100644
--- a/src/gbm/meson.build
+++ b/src/gbm/meson.build
@@ -54,7 +54,7 @@ libgbm = shared_library(
   c_args : [c_vis_args, args_gbm],
   link_args : [ld_args_gc_sections],
   link_with : [libloader, libmesa_util, libxmlconfig],
-  dependencies : [deps_gbm, dep_dl],
+  dependencies : [deps_gbm, dep_dl, dep_thread],
   version : '1.0.0',
   install : true,
 )
diff --git a/src/intel/common/meson.build b/src/intel/common/meson.build
index cbcf6647531193142cd5..19472e306f4577ebc231 100644
--- a/src/intel/common/meson.build
+++ b/src/intel/common/meson.build
@@ -40,5 +40,5 @@ libintel_common = static_library(
   files_libintel_common,
   include_directories : [inc_common, inc_intel],
   c_args : [c_vis_args, no_override_init_args],
-  dependencies : [dep_expat, dep_libdrm],
+  dependencies : [dep_expat, dep_libdrm, dep_thread],
 )
diff --git a/src/loader/meson.build b/src/loader/meson.build
index 05268f58f3f138fe0eb0..e4455e9a72b24891f58b 100644
--- a/src/loader/meson.build
+++ b/src/loader/meson.build
@@ -41,6 +41,6 @@ libloader = static_library(
xmlpool_options_h],
   c_args : [c_vis_args, '-DUSE_DRICONF'],
   include_directories : [inc_include, inc_src, inc_util],
-  dependencies : dep_libdrm,
+  dependencies : [dep_libdrm, dep_thread],
   build_by_default : false,
 )
diff --git a/src/util/meson.build b/src/util/meson.build
index b54c20796ff01012759b..225593f5d381b486bdb2 100644
--- a/src/util/meson.build
+++ b/src/util/meson.build
@@ -102,7 +102,7 @@ libmesa_util = static_library(
   'mesa_util',
   [files_mesa_util, format_srgb],
   include_directories : inc_common,
-  dependencies : [dep_zlib, dep_clock],
+  dependencies : [dep_zlib, dep_cloc

[Mesa-dev] [Bug 104141] include/c11/threads_posix.h:96: undefined reference to `pthread_once'

[bugzilla-daemon]

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

--- Comment #1 from Eric Engestrom  ---
Yup, I noticed the same issue, but there are more libs missing dep_thread.
Sent a patch to the ML that fixes all of them:
https://lists.freedesktop.org/archives/mesa-dev/2017-December/179562.html

-- 
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] [PATCH 2/3] broadcom/vc4: Add support for extended CL submission

[Boris Brezillon]

Recent versions of the VC4 driver support CL extensions, which allows one
to pass extra attributes to the CL submission.
In order to make this feature backward compatible with the existing
SUBMIT_CL ioctl, we had to add a new flag and re-use the optional
bin_cl fields. Binner CL are now passed as an extra chunk.

Signed-off-by: Boris Brezillon 
---
 src/gallium/drivers/vc4/vc4_job.c| 23 +--
 src/gallium/drivers/vc4/vc4_screen.c |  2 ++
 src/gallium/drivers/vc4/vc4_screen.h |  1 +
 3 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/vc4/vc4_job.c 
b/src/gallium/drivers/vc4/vc4_job.c
index 7fe20c16bad9..fb0c5bbc78cf 100644
--- a/src/gallium/drivers/vc4/vc4_job.c
+++ b/src/gallium/drivers/vc4/vc4_job.c
@@ -362,12 +362,18 @@ vc4_submit_setup_rcl_msaa_surface(struct vc4_job *job,
 rsc->writes++;
 }
 
+#define MAX_CHUNKS 1
+
 /**
  * Submits the job to the kernel and then reinitializes it.
  */
 void
 vc4_job_submit(struct vc4_context *vc4, struct vc4_job *job)
 {
+struct vc4_screen *screen = vc4_screen(vc4->base.screen);
+union drm_vc4_submit_cl_chunk chunks[MAX_CHUNKS] = { };
+uint32_t nchunks = 0;
+
 if (!job->needs_flush)
 goto done;
 
@@ -446,14 +452,27 @@ vc4_job_submit(struct vc4_context *vc4, struct vc4_job 
*job)
 
 submit.bo_handles = (uintptr_t)job->bo_handles.base;
 submit.bo_handle_count = cl_offset(&job->bo_handles) / 4;
-submit.bin_cl = (uintptr_t)job->bcl.base;
-submit.bin_cl_size = cl_offset(&job->bcl);
+if (!screen->has_extended_cl) {
+submit.bin_cl = (uintptr_t)job->bcl.base;
+submit.bin_cl_size = cl_offset(&job->bcl);
+} else if (cl_offset(&job->bcl)) {
+chunks[nchunks].bin.type = VC4_BIN_CL_CHUNK;
+chunks[nchunks].bin.size = cl_offset(&job->bcl);
+chunks[nchunks].bin.ptr = (uintptr_t)job->bcl.base;
+nchunks++;
+}
 submit.shader_rec = (uintptr_t)job->shader_rec.base;
 submit.shader_rec_size = cl_offset(&job->shader_rec);
 submit.shader_rec_count = job->shader_rec_count;
 submit.uniforms = (uintptr_t)job->uniforms.base;
 submit.uniforms_size = cl_offset(&job->uniforms);
 
+if (nchunks) {
+submit.flags |= VC4_SUBMIT_CL_EXTENDED;
+submit.cl_chunks = (uintptr_t)chunks;
+submit.num_cl_chunks = nchunks;
+}
+
 assert(job->draw_min_x != ~0 && job->draw_min_y != ~0);
 submit.min_x_tile = job->draw_min_x / job->tile_width;
 submit.min_y_tile = job->draw_min_y / job->tile_height;
diff --git a/src/gallium/drivers/vc4/vc4_screen.c 
b/src/gallium/drivers/vc4/vc4_screen.c
index a42ba675c130..4b63e940822d 100644
--- a/src/gallium/drivers/vc4/vc4_screen.c
+++ b/src/gallium/drivers/vc4/vc4_screen.c
@@ -696,6 +696,8 @@ vc4_screen_create(int fd, struct renderonly *ro)
 vc4_has_feature(screen, DRM_VC4_PARAM_SUPPORTS_THREADED_FS);
 screen->has_madvise =
 vc4_has_feature(screen, DRM_VC4_PARAM_SUPPORTS_MADVISE);
+screen->has_extended_cl =
+vc4_has_feature(screen, DRM_VC4_PARAM_SUPPORTS_EXTENDED_CL);
 
 if (!vc4_get_chip_info(screen))
 goto fail;
diff --git a/src/gallium/drivers/vc4/vc4_screen.h 
b/src/gallium/drivers/vc4/vc4_screen.h
index 09d1c342ed19..83719d88baf0 100644
--- a/src/gallium/drivers/vc4/vc4_screen.h
+++ b/src/gallium/drivers/vc4/vc4_screen.h
@@ -97,6 +97,7 @@ struct vc4_screen {
 bool has_threaded_fs;
 bool has_madvise;
 bool has_tiling_ioctl;
+bool has_extended_cl;
 
 struct vc4_simulator_file *sim_file;
 };
-- 
2.11.0

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

[Mesa-dev] [PATCH 1/3] drm-uapi: Update vc4 header with CL chunks and perfmon related definitions

[Boris Brezillon]

Signed-off-by: Boris Brezillon 
---
 include/drm-uapi/vc4_drm.h | 156 ++---
 1 file changed, 146 insertions(+), 10 deletions(-)

diff --git a/include/drm-uapi/vc4_drm.h b/include/drm-uapi/vc4_drm.h
index 3415a4b71884..ca0220257f05 100644
--- a/include/drm-uapi/vc4_drm.h
+++ b/include/drm-uapi/vc4_drm.h
@@ -42,6 +42,9 @@ extern "C" {
 #define DRM_VC4_GET_TILING0x09
 #define DRM_VC4_LABEL_BO  0x0a
 #define DRM_VC4_GEM_MADVISE   0x0b
+#define DRM_VC4_PERFMON_CREATE0x0c
+#define DRM_VC4_PERFMON_DESTROY   0x0d
+#define DRM_VC4_PERFMON_GET_VALUES0x0e
 
 #define DRM_IOCTL_VC4_SUBMIT_CL   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_SUBMIT_CL, struct drm_vc4_submit_cl)
 #define DRM_IOCTL_VC4_WAIT_SEQNO  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_WAIT_SEQNO, struct drm_vc4_wait_seqno)
@@ -55,6 +58,9 @@ extern "C" {
 #define DRM_IOCTL_VC4_GET_TILING  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GET_TILING, struct drm_vc4_get_tiling)
 #define DRM_IOCTL_VC4_LABEL_BODRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_LABEL_BO, struct drm_vc4_label_bo)
 #define DRM_IOCTL_VC4_GEM_MADVISE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GEM_MADVISE, struct drm_vc4_gem_madvise)
+#define DRM_IOCTL_VC4_PERFMON_CREATE  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_PERFMON_CREATE, struct drm_vc4_perfmon_create)
+#define DRM_IOCTL_VC4_PERFMON_DESTROY DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_PERFMON_DESTROY, struct drm_vc4_perfmon_destroy)
+#define DRM_IOCTL_VC4_PERFMON_GET_VALUES  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_PERFMON_GET_VALUES, struct drm_vc4_perfmon_get_values)
 
 struct drm_vc4_submit_rcl_surface {
__u32 hindex; /* Handle index, or ~0 if not present. */
@@ -70,6 +76,67 @@ struct drm_vc4_submit_rcl_surface {
 };
 
 /**
+ * @VC4_BIN_CL_CHUNK: binner CL chunk
+ * @VC4_PERFMON_CHUNK: performance monitor chunk
+ */
+enum {
+   VC4_BIN_CL_CHUNK,
+   VC4_PERFMON_CHUNK,
+};
+
+/**
+ * struct drm_vc4_submit_cl_chunk - dummy chunk
+ * @type: extension type
+ * @pad: unused, should be set to zero
+ *
+ * Meant to be used for chunks that do not require extra parameters.
+ */
+struct drm_vc4_submit_cl_dummy_chunk {
+   __u32 type;
+   __u32 pad[3];
+};
+
+/**
+ * struct drm_vc4_submit_cl_bin_chunk - binner CL chunk
+ *
+ * @type: extention type, should be set to %VC4_BIN_CL_CHUNK
+ * @size: size in bytes of the binner CL
+ * @ptr: userspace pointer to the binner CL
+ */
+struct drm_vc4_submit_cl_bin_chunk {
+   __u32 type;
+   __u32 size;
+   __u64 ptr;
+};
+
+/**
+ * struct drm_vc4_submit_cl_perfmon_chunk - performance monitor extension
+ *
+ * @type: extention type, should be set to %VC4_PERFMON_CHUNK
+ * @id: id of the perfmance monitor previously allocated with
+ * %DRM_IOCTL_VC4_PERFMON_CREATE
+ * @pad: unused, should be set to zero
+ */
+struct drm_vc4_submit_cl_perfmon_chunk {
+   __u32 type;
+   __u32 id;
+   __u64 pad;
+};
+
+/**
+ * union drm_vc4_submit_cl_chunk - CL chunk
+ *
+ * CL chunks allow us to easily extend the set of arguments one can pass
+ * to the submit CL ioctl without having to add new ioctls/struct everytime
+ * we run out of free fields in the drm_vc4_submit_cl struct.
+ */
+union drm_vc4_submit_cl_chunk {
+   struct drm_vc4_submit_cl_dummy_chunk dummy;
+   struct drm_vc4_submit_cl_bin_chunk bin;
+   struct drm_vc4_submit_cl_perfmon_chunk perfmon;
+};
+
+/**
  * struct drm_vc4_submit_cl - ioctl argument for submitting commands to the 3D
  * engine.
  *
@@ -83,14 +150,23 @@ struct drm_vc4_submit_rcl_surface {
  * BO.
  */
 struct drm_vc4_submit_cl {
-   /* Pointer to the binner command list.
-*
-* This is the first set of commands executed, which runs the
-* coordinate shader to determine where primitives land on the screen,
-* then writes out the state updates and draw calls necessary per tile
-* to the tile allocation BO.
-*/
-   __u64 bin_cl;
+   union {
+   /* Pointer to the binner command list.
+*
+* This is the first set of commands executed, which runs the
+* coordinate shader to determine where primitives land on
+* the screen, then writes out the state updates and draw calls
+* necessary per tile to the tile allocation BO.
+*/
+   __u64 bin_cl;
+
+   /* Pointer to an array of CL chunks.
+*
+* This is now the preferred way of passing optional attributes
+* when submitting a job.
+*/
+   __u64 cl_chunks;
+   };
 
/* Pointer to the shader records.
 *
@@ -120,8 +196,14 @@ struct drm_vc4_submit_cl {
__u64 uniforms;
__u64 bo_handles;
 
-   /* Size in bytes of the binner command list. */
-

[Mesa-dev] [PATCH 3/3] broadcom/vc4: Add support for HW perfmon

[Boris Brezillon]

The V3D engine provides several perf counters.
Implement ->get_driver_query_[group_]info() so that these counters are
exposed through the GL_AMD_performance_monitor extension.

Signed-off-by: Boris Brezillon 
---
 src/gallium/drivers/vc4/vc4_context.h |  13 +++
 src/gallium/drivers/vc4/vc4_job.c |   9 +-
 src/gallium/drivers/vc4/vc4_query.c   | 197 --
 src/gallium/drivers/vc4/vc4_screen.c  |   7 ++
 src/gallium/drivers/vc4/vc4_screen.h  |   1 +
 5 files changed, 215 insertions(+), 12 deletions(-)

diff --git a/src/gallium/drivers/vc4/vc4_context.h 
b/src/gallium/drivers/vc4/vc4_context.h
index 4a1e4093f1a0..b6d9f041efc7 100644
--- a/src/gallium/drivers/vc4/vc4_context.h
+++ b/src/gallium/drivers/vc4/vc4_context.h
@@ -309,6 +309,11 @@ struct vc4_job {
 struct vc4_job_key key;
 };
 
+struct vc4_hwperfmon {
+uint32_t id;
+uint64_t counters[DRM_VC4_MAX_PERF_COUNTERS];
+};
+
 struct vc4_context {
 struct pipe_context base;
 
@@ -387,6 +392,8 @@ struct vc4_context {
 struct pipe_viewport_state viewport;
 struct vc4_constbuf_stateobj constbuf[PIPE_SHADER_TYPES];
 struct vc4_vertexbuf_stateobj vertexbuf;
+
+struct vc4_hwperfmon *perfmon;
 /** @} */
 };
 
@@ -444,6 +451,12 @@ vc4_sampler_state(struct pipe_sampler_state *psampler)
 return (struct vc4_sampler_state *)psampler;
 }
 
+int vc4_get_driver_query_group_info(struct pipe_screen *pscreen,
+unsigned index,
+struct pipe_driver_query_group_info *info);
+int vc4_get_driver_query_info(struct pipe_screen *pscreen, unsigned index,
+  struct pipe_driver_query_info *info);
+
 struct pipe_context *vc4_context_create(struct pipe_screen *pscreen,
 void *priv, unsigned flags);
 void vc4_draw_init(struct pipe_context *pctx);
diff --git a/src/gallium/drivers/vc4/vc4_job.c 
b/src/gallium/drivers/vc4/vc4_job.c
index fb0c5bbc78cf..f75a32565603 100644
--- a/src/gallium/drivers/vc4/vc4_job.c
+++ b/src/gallium/drivers/vc4/vc4_job.c
@@ -362,7 +362,7 @@ vc4_submit_setup_rcl_msaa_surface(struct vc4_job *job,
 rsc->writes++;
 }
 
-#define MAX_CHUNKS 1
+#define MAX_CHUNKS 2
 
 /**
  * Submits the job to the kernel and then reinitializes it.
@@ -467,6 +467,13 @@ vc4_job_submit(struct vc4_context *vc4, struct vc4_job 
*job)
 submit.uniforms = (uintptr_t)job->uniforms.base;
 submit.uniforms_size = cl_offset(&job->uniforms);
 
+if (vc4->perfmon && screen->has_extended_cl) {
+chunks[nchunks].perfmon.type = VC4_PERFMON_CHUNK;
+chunks[nchunks].perfmon.id = vc4->perfmon->id;
+chunks[nchunks].perfmon.pad = 0;
+nchunks++;
+}
+
 if (nchunks) {
 submit.flags |= VC4_SUBMIT_CL_EXTENDED;
 submit.cl_chunks = (uintptr_t)chunks;
diff --git a/src/gallium/drivers/vc4/vc4_query.c 
b/src/gallium/drivers/vc4/vc4_query.c
index ddf8f8fb0c2c..d6b081bb15d7 100644
--- a/src/gallium/drivers/vc4/vc4_query.c
+++ b/src/gallium/drivers/vc4/vc4_query.c
@@ -32,49 +32,224 @@
 
 struct vc4_query
 {
-uint8_t pad;
+unsigned num_queries;
+struct vc4_hwperfmon *hwperfmon;
 };
 
+static const char *v3d_counter_names[] = {
+"FEP-valid-primitives-no-rendered-pixels",
+"FEP-valid-primitives-rendered-pixels",
+"FEP-clipped-quads",
+"FEP-valid-quads",
+"TLB-quads-not-passing-stencil-test",
+"TLB-quads-not-passing-z-and-stencil-test",
+"TLB-quads-with-zero-coverage",
+"TLB-quads-with-non-zero-coverage",
+"TLB-quads-written-to-color-buffer",
+"PTB-primitives-discarded-outside-viewport",
+"PTB-primitives-need-clipping",
+"PTB-primitives-discared-reversed",
+"QPU-total-idle-clk-cycles",
+"QPU-total-clk-cycles-vertex-coord-shading",
+"QPU-total-clk-cycles-fragment-shading",
+"QPU-total-clk-cycles-executing-valid-instr",
+"QPU-total-clk-cycles-waiting-TMU",
+"QPU-total-clk-cycles-waiting-scoreboard",
+"QPU-total-clk-cycles-waiting-varyings",
+"QPU-total-instr-cache-hit",
+"QPU-total-instr-cache-miss",
+"QPU-total-uniform-cache-hit",
+"QPU-total-uniform-cache-miss",
+"TMU-total-text-quads-processed",
+"TMU-total-text-cache-miss",
+"VPM-total-clk-cycles-VDW-stalled",
+"VPM-total-clk-cycles-VCD-stalled",
+"L2C-total-cache-hit",
+"L2C-total-cache-miss",
+};
+
+int vc4_get_driver_query_group_info(struct pipe_screen *pscreen,
+unsigned index,
+struct pipe_driver_query_group_info *info)
+{
+struct vc4_screen *screen = vc4_screen(pscreen);
+
+if (!screen->has_perfmon_ioctl)
+

[Mesa-dev] [PATCH 0/3] broadcom/v4: Expose VC4 HW perf counters

[Boris Brezillon]

Hello,

This series makes use of the VC4 perfmon ioctls to expose HW perf
counters through the GL_AMD_performance_monitor interface.

This patches depends on their kernel counterparts and should not be
applied until the kernel patches have reached the drm tree.

Regards,

Boris

Boris Brezillon (3):
  drm-uapi: Update vc4 header with CL chunks and perfmon related
definitions
  broadcom/vc4: Add support for extended CL submission
  broadcom/vc4: Add support for HW perfmon

 include/drm-uapi/vc4_drm.h| 156 +--
 src/gallium/drivers/vc4/vc4_context.h |  13 +++
 src/gallium/drivers/vc4/vc4_job.c |  30 +-
 src/gallium/drivers/vc4/vc4_query.c   | 197 --
 src/gallium/drivers/vc4/vc4_screen.c  |   9 ++
 src/gallium/drivers/vc4/vc4_screen.h  |   2 +
 6 files changed, 384 insertions(+), 23 deletions(-)

-- 
2.11.0

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

Re: [Mesa-dev] [PATCH v2] mesa/spirv: move and rename nir_spirv_supported_capabilities

[Jason Ekstrand]

On Thu, Dec 7, 2017 at 12:38 AM, Alejandro Piñeiro 
wrote:

> To avoid any vulkan driver to include the GL mtypes.h. Renamed as
> eventually this could be used by drivers not using nir.
>
> v2: remove compiler/spirv/spirv.h from mtypes (Alejandro)
> ---
>
> The include on v1 was a leftover, when I tested if adding the
> SpirVCapabilities on gl_constant was working fine, but it is not
> needed on this patch, but on a following one.
>
> Sorry for the noise.
>
>  src/compiler/spirv/nir_spirv.h |  4 ++--
>  src/compiler/spirv/spirv.h | 15 +++
>  src/mesa/main/mtypes.h | 13 -
>  3 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/src/compiler/spirv/nir_spirv.h b/src/compiler/spirv/nir_
> spirv.h
> index 113bd710a00..71f44e07dba 100644
> --- a/src/compiler/spirv/nir_spirv.h
> +++ b/src/compiler/spirv/nir_spirv.h
> @@ -29,7 +29,7 @@
>  #define _NIR_SPIRV_H_
>
>  #include "compiler/nir/nir.h"
> -#include "main/mtypes.h"
> +#include "compiler/spirv/spirv.h"
>
>  #ifdef __cplusplus
>  extern "C" {
> @@ -58,7 +58,7 @@ struct spirv_to_nir_options {
>  */
> bool lower_workgroup_access_to_offsets;
>
> -   struct nir_spirv_supported_capabilities caps;
> +   struct spirv_supported_capabilities caps;
>
> struct {
>void (*func)(void *private_data,
> diff --git a/src/compiler/spirv/spirv.h b/src/compiler/spirv/spirv.h
> index 61559a1c9ca..ce2dcf7657f 100644
> --- a/src/compiler/spirv/spirv.h
> +++ b/src/compiler/spirv/spirv.h
> @@ -48,6 +48,8 @@
>  #ifndef spirv_H
>  #define spirv_H
>
> +#include 
> +
>  typedef unsigned int SpvId;
>
>  #define SPV_VERSION 0x10200
> @@ -994,5 +996,18 @@ typedef enum SpvOp_ {
>  SpvOpMax = 0x7fff,
>  } SpvOp;
>
> +struct spirv_supported_capabilities {
> +   bool float64;
> +   bool image_ms_array;
> +   bool tessellation;
> +   bool draw_parameters;
> +   bool image_read_without_format;
> +   bool image_write_without_format;
> +   bool int64;
> +   bool multiview;
> +   bool variable_pointers;
> +   bool storage_16bit;
> +};
> +
>

We shouldn't add things to spirv/spirv.h.  That's a header we pull in from
Khronos so we really shouldn't be touching it.  Other possibly reasonable
options include:

 1) compiler/shader_info.h
 2) A new spirv/spirv_capabilities.h header
 3) Add a couple of predeclarations to spirv/nir_spirv.h, drop the nir.h
include, and put it there.

I think option 1 is probably the most sane.  It's not really shader_info
but it's kind-of like that.


>  #endif  // #ifndef spirv_H
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 7b7137624c7..397b113dfbc 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3578,19 +3578,6 @@ struct gl_program_constants
> GLuint MaxShaderStorageBlocks;
>  };
>
> -struct nir_spirv_supported_capabilities {
> -   bool float64;
> -   bool image_ms_array;
> -   bool tessellation;
> -   bool draw_parameters;
> -   bool image_read_without_format;
> -   bool image_write_without_format;
> -   bool int64;
> -   bool multiview;
> -   bool variable_pointers;
> -   bool storage_16bit;
> -};
> -
>  /**
>   * Constants which may be overridden by device driver during context
> creation
>   * but are never changed after that.
> --
> 2.11.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] gallium/u_blitter: replace tabs with spaces

[Brian Paul]

---
 src/gallium/auxiliary/util/u_blitter.c | 36 +-
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_blitter.c 
b/src/gallium/auxiliary/util/u_blitter.c
index 2a2fd17..5e8800e 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -1579,7 +1579,7 @@ bool util_blitter_is_copy_supported(struct 
blitter_context *blitter,
 }
 
 bool util_blitter_is_blit_supported(struct blitter_context *blitter,
-   const struct pipe_blit_info *info)
+const struct pipe_blit_info *info)
 {
return is_blit_generic_supported(blitter,
 info->dst.resource, info->dst.format,
@@ -1988,7 +1988,7 @@ void util_blitter_blit_generic(struct blitter_context 
*blitter,
 
 void
 util_blitter_blit(struct blitter_context *blitter,
- const struct pipe_blit_info *info)
+  const struct pipe_blit_info *info)
 {
struct pipe_resource *dst = info->dst.resource;
struct pipe_resource *src = info->src.resource;
@@ -2020,7 +2020,7 @@ util_blitter_blit(struct blitter_context *blitter,
 }
 
 void util_blitter_generate_mipmap(struct blitter_context *blitter,
- struct pipe_resource *tex,
+  struct pipe_resource *tex,
   enum pipe_format format,
   unsigned base_level, unsigned last_level,
   unsigned first_layer, unsigned last_layer)
@@ -2268,10 +2268,10 @@ void util_blitter_clear_depth_stencil(struct 
blitter_context *blitter,
 
 /* draw a rectangle across a region using a custom dsa stage - for r600g */
 void util_blitter_custom_depth_stencil(struct blitter_context *blitter,
-  struct pipe_surface *zsurf,
-  struct pipe_surface *cbsurf,
-  unsigned sample_mask,
-  void *dsa_stage, float depth)
+   struct pipe_surface *zsurf,
+   struct pipe_surface *cbsurf,
+   unsigned sample_mask,
+   void *dsa_stage, float depth)
 {
struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
struct pipe_context *pipe = ctx->base.pipe;
@@ -2302,11 +2302,11 @@ void util_blitter_custom_depth_stencil(struct 
blitter_context *blitter,
fb_state.height = zsurf->height;
fb_state.nr_cbufs = 1;
if (cbsurf) {
-  fb_state.cbufs[0] = cbsurf;
-  fb_state.nr_cbufs = 1;
+  fb_state.cbufs[0] = cbsurf;
+  fb_state.nr_cbufs = 1;
} else {
-  fb_state.cbufs[0] = NULL;
-  fb_state.nr_cbufs = 0;
+  fb_state.cbufs[0] = NULL;
+  fb_state.nr_cbufs = 0;
}
fb_state.zsbuf = zsurf;
pipe->set_framebuffer_state(pipe, &fb_state);
@@ -2464,13 +2464,13 @@ out:
 
 /* probably radeon specific */
 void util_blitter_custom_resolve_color(struct blitter_context *blitter,
-  struct pipe_resource *dst,
-  unsigned dst_level,
-  unsigned dst_layer,
-  struct pipe_resource *src,
-  unsigned src_layer,
-  unsigned sample_mask,
-  void *custom_blend,
+   struct pipe_resource *dst,
+   unsigned dst_level,
+   unsigned dst_layer,
+   struct pipe_resource *src,
+   unsigned src_layer,
+   unsigned sample_mask,
+   void *custom_blend,
enum pipe_format format)
 {
struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
-- 
1.9.1

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

[Mesa-dev] [PATCH 1/2] gallium/u_blitter: enable MSAA when blitting to MSAA surfaces

[Brian Paul]

If we're doing a Z -> Z MSAA blit (for example) we need to enable
msaa rasterization when drawing the quads so that we can properly
write the per-sample values.

This fixes a number of Piglit ext_framebuffer_multisample blit tests
such as ext_framebuffer_multisample/no-color 2 depth combined with
the VMware driver.

---

Marek, I'm not sure how this could have worked without MSAA enabled.
Perhaps you can comment.
---
 src/gallium/auxiliary/util/u_blitter.c | 54 +-
 1 file changed, 33 insertions(+), 21 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_blitter.c 
b/src/gallium/auxiliary/util/u_blitter.c
index 476ef08..2a2fd17 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -123,7 +123,8 @@ struct blitter_context_priv
void *sampler_state_rect_linear;
 
/* Rasterizer state. */
-   void *rs_state, *rs_state_scissor, *rs_discard_state;
+   void *rs_state[2][2];  /**< [scissor][msaa] */
+   void *rs_discard_state;
 
/* Destination surface dimensions. */
unsigned dst_width;
@@ -275,13 +276,19 @@ struct blitter_context *util_blitter_create(struct 
pipe_context *pipe)
rs_state.bottom_edge_rule = 1;
rs_state.flatshade = 1;
rs_state.depth_clip = 1;
-   ctx->rs_state = pipe->create_rasterizer_state(pipe, &rs_state);
 
-   rs_state.scissor = 1;
-   ctx->rs_state_scissor = pipe->create_rasterizer_state(pipe, &rs_state);
+   unsigned scissor, msaa;
+   for (scissor = 0; scissor < 2; scissor++) {
+  for (msaa = 0; msaa < 2; msaa++) {
+ rs_state.scissor = scissor;
+ rs_state.multisample = msaa;
+ ctx->rs_state[scissor][msaa] =
+pipe->create_rasterizer_state(pipe, &rs_state);
+  }
+   }
 
if (ctx->has_stream_out) {
-  rs_state.scissor = 0;
+  rs_state.scissor = rs_state.multisample = 0;
   rs_state.rasterizer_discard = 1;
   ctx->rs_discard_state = pipe->create_rasterizer_state(pipe, &rs_state);
}
@@ -454,8 +461,13 @@ void util_blitter_destroy(struct blitter_context *blitter)
pipe->delete_depth_stencil_alpha_state(pipe, ctx->dsa_write_depth_stencil);
pipe->delete_depth_stencil_alpha_state(pipe, 
ctx->dsa_keep_depth_write_stencil);
 
-   pipe->delete_rasterizer_state(pipe, ctx->rs_state);
-   pipe->delete_rasterizer_state(pipe, ctx->rs_state_scissor);
+   unsigned scissor, msaa;
+   for (scissor = 0; scissor < 2; scissor++) {
+  for (msaa = 0; msaa < 2; msaa++) {
+ pipe->delete_rasterizer_state(pipe, ctx->rs_state[scissor][msaa]);
+  }
+   }
+
if (ctx->rs_discard_state)
   pipe->delete_rasterizer_state(pipe, ctx->rs_discard_state);
if (ctx->vs)
@@ -1216,12 +1228,12 @@ void util_blitter_cache_all_shaders(struct 
blitter_context *blitter)
 }
 
 static void blitter_set_common_draw_rect_state(struct blitter_context_priv 
*ctx,
-   bool scissor)
+   bool scissor, bool msaa)
 {
struct pipe_context *pipe = ctx->base.pipe;
 
-   pipe->bind_rasterizer_state(pipe, scissor ? ctx->rs_state_scissor
- : ctx->rs_state);
+   pipe->bind_rasterizer_state(pipe, ctx->rs_state[scissor][msaa]);
+
if (ctx->has_geometry_shader)
   pipe->bind_gs_state(pipe, NULL);
if (ctx->has_tessellation) {
@@ -1395,7 +1407,7 @@ static void util_blitter_clear_custom(struct 
blitter_context *blitter,
if (num_layers > 1 && ctx->has_layered) {
   blitter_get_vs_func get_vs = get_vs_layered;
 
-  blitter_set_common_draw_rect_state(ctx, false);
+  blitter_set_common_draw_rect_state(ctx, false, false);
   blitter->draw_rectangle(blitter, ctx->velem_state, get_vs,
   0, 0, width, height,
   (float) depth, num_layers, type, &attrib);
@@ -1407,7 +1419,7 @@ static void util_blitter_clear_custom(struct 
blitter_context *blitter,
   else
  get_vs = get_vs_passthrough_pos;
 
-  blitter_set_common_draw_rect_state(ctx, false);
+  blitter_set_common_draw_rect_state(ctx, false, false);
   blitter->draw_rectangle(blitter, ctx->velem_state, get_vs,
   0, 0, width, height,
   (float) depth, 1, type, &attrib);
@@ -1958,7 +1970,7 @@ void util_blitter_blit_generic(struct blitter_context 
*blitter,
   pipe->set_scissor_states(pipe, 0, 1, scissor);
}
 
-   blitter_set_common_draw_rect_state(ctx, scissor != NULL);
+   blitter_set_common_draw_rect_state(ctx, scissor != NULL, dst_samples > 1);
 
do_blits(ctx, dst, dstbox, src, src_width0, src_height0,
 srcbox, blit_depth || blit_stencil, use_txf);
@@ -2064,7 +2076,7 @@ void util_blitter_generate_mipmap(struct blitter_context 
*blitter,
pipe->bind_sampler_states(pipe, PIPE_SHADER_FRAGMENT,
  0, 1, &sampler_state);
 
-   blitter_set_common_draw_rect_state(ctx, false);
+   b

[Mesa-dev] [PATCH 2/8] spirv: Add a prepass to set types on vtn_values

[Jason Ekstrand]

This autogenerated pass will automatically find and set the type field
on all vtn_values.  This way we always have the type and can use it for
validation and other checks.
---
 src/compiler/Makefile.nir.am |   4 +
 src/compiler/nir/meson.build |  11 ++-
 src/compiler/spirv/spirv_to_nir.c|   6 +-
 src/compiler/spirv/vtn_gather_types_c.py | 125 +++
 src/compiler/spirv/vtn_private.h |   4 +
 5 files changed, 148 insertions(+), 2 deletions(-)
 create mode 100644 src/compiler/spirv/vtn_gather_types_c.py

diff --git a/src/compiler/Makefile.nir.am b/src/compiler/Makefile.nir.am
index 1533ee5..dd38c45 100644
--- a/src/compiler/Makefile.nir.am
+++ b/src/compiler/Makefile.nir.am
@@ -56,6 +56,10 @@ spirv/spirv_info.c: spirv/spirv_info_c.py 
spirv/spirv.core.grammar.json
$(MKDIR_GEN)
$(PYTHON_GEN) $(srcdir)/spirv/spirv_info_c.py 
$(srcdir)/spirv/spirv.core.grammar.json $@ || ($(RM) $@; false)
 
+spirv/vtn_gather_types.c: spirv/vtn_gather_types_c.py 
spirv/spirv.core.grammar.json
+   $(MKDIR_GEN)
+   $(PYTHON_GEN) $(srcdir)/spirv/vtn_gather_types_c.py 
$(srcdir)/spirv/spirv.core.grammar.json $@ || ($(RM) $@; false)
+
 noinst_PROGRAMS += spirv2nir
 
 spirv2nir_SOURCES = \
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index b61a077..5dd21e6 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -72,6 +72,14 @@ spirv_info_c = custom_target(
   command : [prog_python2, '@INPUT0@', '@INPUT1@', '@OUTPUT@'],
 )
 
+vtn_gather_types_c = custom_target(
+  'vtn_gather_types.c',
+  input : files('../spirv/vtn_gather_types_c.py',
+'../spirv/spirv.core.grammar.json'),
+  output : 'vtn_gather_types.c',
+  command : [prog_python2, '@INPUT0@', '@INPUT1@', '@OUTPUT@'],
+)
+
 files_libnir = files(
   'nir.c',
   'nir.h',
@@ -189,7 +197,8 @@ files_libnir = files(
 libnir = static_library(
   'nir',
   [files_libnir, spirv_info_c, nir_opt_algebraic_c, nir_opcodes_c,
-   nir_opcodes_h, nir_constant_expressions_c, nir_builder_opcodes_h],
+   nir_opcodes_h, nir_constant_expressions_c, nir_builder_opcodes_h,
+   vtn_gather_types_c],
   include_directories : [inc_common, inc_compiler, 
include_directories('../spirv')],
   c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
   link_with : libcompiler,
diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index a50b14d..a2426bc 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1261,7 +1261,6 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
 const uint32_t *w, unsigned count)
 {
struct vtn_value *val = vtn_push_value(b, w[2], vtn_value_type_constant);
-   val->type = vtn_value(b, w[1], vtn_value_type_type)->type;
val->constant = rzalloc(b, nir_constant);
switch (opcode) {
case SpvOpConstantTrue:
@@ -3268,6 +3267,8 @@ static bool
 vtn_handle_variable_or_type_instruction(struct vtn_builder *b, SpvOp opcode,
 const uint32_t *w, unsigned count)
 {
+   vtn_set_instruction_result_type(b, opcode, w, count);
+
switch (opcode) {
case SpvOpSource:
case SpvOpSourceContinued:
@@ -3658,6 +3659,9 @@ spirv_to_nir(const uint32_t *words, size_t word_count,
words = vtn_foreach_instruction(b, words, word_end,
vtn_handle_variable_or_type_instruction);
 
+   /* Set types on all vtn_values */
+   vtn_foreach_instruction(b, words, word_end, 
vtn_set_instruction_result_type);
+
vtn_build_cfg(b, words, word_end);
 
assert(b->entry_point->value_type == vtn_value_type_function);
diff --git a/src/compiler/spirv/vtn_gather_types_c.py 
b/src/compiler/spirv/vtn_gather_types_c.py
new file mode 100644
index 000..8cd8d9f
--- /dev/null
+++ b/src/compiler/spirv/vtn_gather_types_c.py
@@ -0,0 +1,125 @@
+COPYRIGHT = """\
+/*
+ * Copyright (C) 2017 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, T

[Mesa-dev] [PATCH 1/8] spirv: Add a vtn_type field to all vtn_values

[Jason Ekstrand]

At the moment, this just lets us drop the const_type for constants and
unify things a bit.  Eventually, we will use this to store the types of
all SPIR-V SSA values.
---
 src/compiler/spirv/spirv_to_nir.c | 63 +--
 src/compiler/spirv/vtn_private.h  |  7 ++---
 2 files changed, 29 insertions(+), 41 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index d321d1a..a50b14d 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -257,7 +257,7 @@ vtn_ssa_value(struct vtn_builder *b, uint32_t value_id)
   return vtn_undef_ssa_value(b, val->type->type);
 
case vtn_value_type_constant:
-  return vtn_const_ssa_value(b, val->constant, val->const_type);
+  return vtn_const_ssa_value(b, val->constant, val->type->type);
 
case vtn_value_type_ssa:
   return val->ssa;
@@ -1249,7 +1249,7 @@ handle_workgroup_size_decoration_cb(struct vtn_builder *b,
dec->literals[0] != SpvBuiltInWorkgroupSize)
   return;
 
-   vtn_assert(val->const_type == glsl_vector_type(GLSL_TYPE_UINT, 3));
+   vtn_assert(val->type->type == glsl_vector_type(GLSL_TYPE_UINT, 3));
 
b->shader->info.cs.local_size[0] = val->constant->values[0].u32[0];
b->shader->info.cs.local_size[1] = val->constant->values[0].u32[1];
@@ -1261,21 +1261,21 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
 const uint32_t *w, unsigned count)
 {
struct vtn_value *val = vtn_push_value(b, w[2], vtn_value_type_constant);
-   val->const_type = vtn_value(b, w[1], vtn_value_type_type)->type->type;
+   val->type = vtn_value(b, w[1], vtn_value_type_type)->type;
val->constant = rzalloc(b, nir_constant);
switch (opcode) {
case SpvOpConstantTrue:
-  vtn_assert(val->const_type == glsl_bool_type());
+  vtn_assert(val->type->type == glsl_bool_type());
   val->constant->values[0].u32[0] = NIR_TRUE;
   break;
case SpvOpConstantFalse:
-  vtn_assert(val->const_type == glsl_bool_type());
+  vtn_assert(val->type->type == glsl_bool_type());
   val->constant->values[0].u32[0] = NIR_FALSE;
   break;
 
case SpvOpSpecConstantTrue:
case SpvOpSpecConstantFalse: {
-  vtn_assert(val->const_type == glsl_bool_type());
+  vtn_assert(val->type->type == glsl_bool_type());
   uint32_t int_val =
  get_specialization(b, val, (opcode == SpvOpSpecConstantTrue));
   val->constant->values[0].u32[0] = int_val ? NIR_TRUE : NIR_FALSE;
@@ -1283,8 +1283,8 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
}
 
case SpvOpConstant: {
-  vtn_assert(glsl_type_is_scalar(val->const_type));
-  int bit_size = glsl_get_bit_size(val->const_type);
+  vtn_assert(glsl_type_is_scalar(val->type->type));
+  int bit_size = glsl_get_bit_size(val->type->type);
   switch (bit_size) {
   case 64:
  val->constant->values->u64[0] = vtn_u64_literal(&w[3]);
@@ -1301,9 +1301,9 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
   break;
}
case SpvOpSpecConstant: {
-  vtn_assert(glsl_type_is_scalar(val->const_type));
+  vtn_assert(glsl_type_is_scalar(val->type->type));
   val->constant->values[0].u32[0] = get_specialization(b, val, w[3]);
-  int bit_size = glsl_get_bit_size(val->const_type);
+  int bit_size = glsl_get_bit_size(val->type->type);
   switch (bit_size) {
   case 64:
  val->constant->values[0].u64[0] =
@@ -1327,7 +1327,7 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
   for (unsigned i = 0; i < elem_count; i++)
  elems[i] = vtn_value(b, w[i + 3], vtn_value_type_constant)->constant;
 
-  switch (glsl_get_base_type(val->const_type)) {
+  switch (glsl_get_base_type(val->type->type)) {
   case GLSL_TYPE_UINT:
   case GLSL_TYPE_INT:
   case GLSL_TYPE_UINT16:
@@ -1338,14 +1338,14 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
   case GLSL_TYPE_FLOAT16:
   case GLSL_TYPE_BOOL:
   case GLSL_TYPE_DOUBLE: {
- int bit_size = glsl_get_bit_size(val->const_type);
- if (glsl_type_is_matrix(val->const_type)) {
-vtn_assert(glsl_get_matrix_columns(val->const_type) == elem_count);
+ int bit_size = glsl_get_bit_size(val->type->type);
+ if (glsl_type_is_matrix(val->type->type)) {
+vtn_assert(glsl_get_matrix_columns(val->type->type) == elem_count);
 for (unsigned i = 0; i < elem_count; i++)
val->constant->values[i] = elems[i]->values[0];
  } else {
-vtn_assert(glsl_type_is_vector(val->const_type));
-vtn_assert(glsl_get_vector_elements(val->const_type) == 
elem_count);
+vtn_assert(glsl_type_is_vector(val->type->type));
+vtn_assert(glsl_get_vector_elements(val->type->type) == 
elem_count);
 for (unsigned i = 0; i < elem_count; i++) {
switch (bit_size) {
 

[Mesa-dev] [PATCH 3/8] spirv: Add basic type validation for OpLoad, OpStore, and OpCopyMemory

[Jason Ekstrand]

---
 src/compiler/spirv/vtn_variables.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index cf44ed3..8ce19ff 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1969,6 +1969,9 @@ vtn_handle_variables(struct vtn_builder *b, SpvOp opcode,
   struct vtn_value *dest = vtn_value(b, w[1], vtn_value_type_pointer);
   struct vtn_value *src = vtn_value(b, w[2], vtn_value_type_pointer);
 
+  vtn_fail_if(dest->type->deref != src->type->deref,
+  "Result and pointer types of OpLoad do not match");
+
   vtn_variable_copy(b, dest->pointer, src->pointer);
   break;
}
@@ -1976,8 +1979,11 @@ vtn_handle_variables(struct vtn_builder *b, SpvOp opcode,
case SpvOpLoad: {
   struct vtn_type *res_type =
  vtn_value(b, w[1], vtn_value_type_type)->type;
-  struct vtn_pointer *src =
- vtn_value(b, w[3], vtn_value_type_pointer)->pointer;
+  struct vtn_value *src_val = vtn_value(b, w[3], vtn_value_type_pointer);
+  struct vtn_pointer *src = src_val->pointer;
+
+  vtn_fail_if(res_type != src_val->type->deref,
+  "Result and pointer types of OpLoad do not match");
 
   if (src->mode == vtn_variable_mode_image ||
   src->mode == vtn_variable_mode_sampler) {
@@ -1990,8 +1996,12 @@ vtn_handle_variables(struct vtn_builder *b, SpvOp opcode,
}
 
case SpvOpStore: {
-  struct vtn_pointer *dest =
- vtn_value(b, w[1], vtn_value_type_pointer)->pointer;
+  struct vtn_value *dest_val = vtn_value(b, w[1], vtn_value_type_pointer);
+  struct vtn_pointer *dest = dest_val->pointer;
+  struct vtn_value *src_val = vtn_untyped_value(b, w[2]);
+
+  vtn_fail_if(dest_val->type->deref != src_val->type,
+  "Value and pointer types of OpStore do not match");
 
   if (glsl_type_is_sampler(dest->type->type)) {
  vtn_warn("OpStore of a sampler detected.  Doing on-the-fly copy "
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 6/8] spirv: Add better parameter validation for vector and matrix types

[Jason Ekstrand]

---
 src/compiler/spirv/spirv_to_nir.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 11c8c2a..4b93b11 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -934,7 +934,11 @@ vtn_handle_type(struct vtn_builder *b, SpvOp opcode,
   struct vtn_type *base = vtn_value(b, w[2], vtn_value_type_type)->type;
   unsigned elems = w[3];
 
-  vtn_assert(glsl_type_is_scalar(base->type));
+  vtn_fail_if(base->base_type != vtn_base_type_scalar,
+  "Base type for OpTypeVector must be a scalar");
+  vtn_fail_if(elems < 2 || elems > 4,
+  "Invalid component count for OpTypeVector");
+
   val->type->base_type = vtn_base_type_vector;
   val->type->type = glsl_vector_type(glsl_get_base_type(base->type), 
elems);
   val->type->length = elems;
@@ -947,12 +951,16 @@ vtn_handle_type(struct vtn_builder *b, SpvOp opcode,
   struct vtn_type *base = vtn_value(b, w[2], vtn_value_type_type)->type;
   unsigned columns = w[3];
 
-  vtn_assert(glsl_type_is_vector(base->type));
+  vtn_fail_if(columns < 2 || columns > 4,
+  "Invalid column count for OpTypeMatrix");
+
   val->type->base_type = vtn_base_type_matrix;
   val->type->type = glsl_matrix_type(glsl_get_base_type(base->type),
  glsl_get_vector_elements(base->type),
  columns);
-  vtn_assert(!glsl_type_is_error(val->type->type));
+  vtn_fail_if(glsl_type_is_error(val->type->type),
+  "Unsupported base type for OpTypeMatrix");
+  assert(!glsl_type_is_error(val->type->type));
   val->type->length = columns;
   val->type->array_element = base;
   val->type->row_major = false;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 7/8] spirv: Restructure the case loop in OpSwitch handling

[Jason Ekstrand]

Instead of calling vtn_add_case for the default case and then looping,
add an is_default variable and do everything inside the loop.  This will
make the next commit easier.
---
 src/compiler/spirv/vtn_cfg.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 25140ff..9d1ca84 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -425,9 +425,20 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct 
list_head *cf_list,
  const uint32_t *branch_end =
 block->branch + (block->branch[0] >> SpvWordCountShift);
 
- vtn_add_case(b, swtch, break_block, block->branch[2], 0, true);
- for (const uint32_t *w = block->branch + 3; w < branch_end; w += 2)
-vtn_add_case(b, swtch, break_block, w[1], w[0], false);
+ bool is_default = true;
+ for (const uint32_t *w = block->branch + 2; w < branch_end;) {
+uint32_t literal = 0;
+if (!is_default) {
+   literal = *w;
+   w++;
+}
+
+uint32_t block_id = *w;
+w++;
+
+vtn_add_case(b, swtch, break_block, block_id, literal, is_default);
+is_default = false;
+ }
 
  /* Now, we go through and walk the blocks.  While we walk through
   * the blocks, we also gather the much-needed fall-through
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 5/8] spirv: Add type validation for OpSelect

[Jason Ekstrand]

---
 src/compiler/spirv/spirv_to_nir.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 253a012..11c8c2a 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3460,6 +3460,38 @@ vtn_handle_body_instruction(struct vtn_builder *b, SpvOp 
opcode,
   /* Handle OpSelect up-front here because it needs to be able to handle
* pointers and not just regular vectors and scalars.
*/
+  struct vtn_value *res_val = vtn_untyped_value(b, w[2]);
+  struct vtn_value *sel_val = vtn_untyped_value(b, w[3]);
+  struct vtn_value *obj1_val = vtn_untyped_value(b, w[4]);
+  struct vtn_value *obj2_val = vtn_untyped_value(b, w[5]);
+
+  const struct glsl_type *sel_type;
+  switch (res_val->type->base_type) {
+  case vtn_base_type_scalar:
+ sel_type = glsl_bool_type();
+ break;
+  case vtn_base_type_vector:
+ sel_type = glsl_vector_type(GLSL_TYPE_BOOL, res_val->type->length);
+ break;
+  case vtn_base_type_pointer:
+ /* We need to have actual storage for pointer types */
+ vtn_fail_if(res_val->type->type == NULL,
+ "Invalid pointer result type for OpSelect");
+ sel_type = glsl_bool_type();
+ break;
+  default:
+ vtn_fail("Result type of OpSelect must be a scalar, vector, or 
pointer");
+  }
+
+  vtn_fail_if(sel_val->type->type != sel_type,
+  "Condition type of ObSelect must be a scalar or vector of "
+  "Boolean type. It must have the same number of components "
+  "as Result Type");
+
+  vtn_fail_if(obj1_val->type != res_val->type ||
+  obj2_val->type != res_val->type,
+  "Object types must match the result type in OpSelect");
+
   struct vtn_type *res_type = vtn_value(b, w[1], 
vtn_value_type_type)->type;
   struct vtn_ssa_value *ssa = vtn_create_ssa_value(b, res_type->type);
   ssa->def = nir_bcsel(&b->nb, vtn_ssa_value(b, w[3])->def,
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 0/8] spirv: Types, types, and OpSwitch

[Jason Ekstrand]

When I started working on switching spirv_to_nir from having piles of
assert() to vtn_assert/fail, Ian and I both agreed that we should start
moving in a direction where we had vtn_fail with reasonable error messages
rather than vtn_assert() with some compiler-internal garbage message.
However some error checking is better than none, so we let it through with
the plan to come back and improve things.  This series starts us down that
road.

The first two patches add an autogenerated pre-pass which records the types
of all SPIR-V values.  Previously, we only really recorded types for
OpType*, OpConstant*, and OpSpecConstant*.  Now, we have types for
everything.

The next four add some very basic parameter validation for OpTypeVector and
OpTypeMatrix and type validation for OpLoad, OpStore, OpCopyMemory, and
OpSelect.  Now that we have the types recorded everywhere, it's fairly easy
to provide validation that looks a lot more like the SPIR-V spec than our
asserts and provides reasonable error messages.  The reason for choosing to
start with those four is that they (along with OpPhi) are the hot-spots for
variable pointers and type mismatches are death there.

The last two patches fix a long-standing bug where we didn't properly
implement switch statements with 64-bit selectors.  Given the infrequency
of 64-bit integers in shaders combined with the infrequency of switch
statements, the chances of hitting this in the wild are low (hence no CC to
stable) but we should make it work correctly.  I haven't done this until
now because it relies on the type pre-pass because we need to know the type
of the OpSwitch selector while we're in the CFG pre-pass which happens
before we emit actual instructions.

Cc: Ian Romanick 

Jason Ekstrand (8):
  spirv: Add a vtn_type field to all vtn_values
  spirv: Add a prepass to set types on vtn_values
  spirv: Add basic type validation for OpLoad, OpStore, and OpCopyMemory
  spirv: Set lengths on scalar and vector types
  spirv: Add type validation for OpSelect
  spirv: Add better parameter validation for vector and matrix types
  spirv: Restructure the case loop in OpSwitch handling
  spirv: Add support for all bit sizes in OpSwitch

 src/compiler/Makefile.nir.am |   4 +
 src/compiler/nir/meson.build |  11 ++-
 src/compiler/spirv/spirv_to_nir.c| 117 +++--
 src/compiler/spirv/vtn_cfg.c |  44 +--
 src/compiler/spirv/vtn_gather_types_c.py | 125 +++
 src/compiler/spirv/vtn_private.h |  11 +--
 src/compiler/spirv/vtn_variables.c   |  18 -
 7 files changed, 273 insertions(+), 57 deletions(-)
 create mode 100644 src/compiler/spirv/vtn_gather_types_c.py

-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 8/8] spirv: Add support for all bit sizes in OpSwitch

[Jason Ekstrand]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101560
Cc: Juan A. Suarez Romero 
---
 src/compiler/spirv/vtn_cfg.c | 33 +
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 9d1ca84..3befc1f 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -170,7 +170,7 @@ vtn_cfg_handle_prepass_instruction(struct vtn_builder *b, 
SpvOp opcode,
 static void
 vtn_add_case(struct vtn_builder *b, struct vtn_switch *swtch,
  struct vtn_block *break_block,
- uint32_t block_id, uint32_t val, bool is_default)
+ uint32_t block_id, uint64_t val, bool is_default)
 {
struct vtn_block *case_block =
   vtn_value(b, block_id, vtn_value_type_block)->block;
@@ -197,7 +197,7 @@ vtn_add_case(struct vtn_builder *b, struct vtn_switch 
*swtch,
if (is_default) {
   case_block->switch_case->is_default = true;
} else {
-  util_dynarray_append(&case_block->switch_case->values, uint32_t, val);
+  util_dynarray_append(&case_block->switch_case->values, uint64_t, val);
}
 }
 
@@ -425,12 +425,29 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct 
list_head *cf_list,
  const uint32_t *branch_end =
 block->branch + (block->branch[0] >> SpvWordCountShift);
 
+ struct vtn_value *cond_val = vtn_untyped_value(b, block->branch[1]);
+ vtn_fail_if(!cond_val->type ||
+ cond_val->type->base_type != vtn_base_type_scalar,
+ "Selector of OpSelect must have a type of OpTypeInt");
+
+ nir_alu_type cond_type =
+nir_get_nir_type_for_glsl_type(cond_val->type->type);
+ vtn_fail_if(nir_alu_type_get_base_type(cond_type) != nir_type_int &&
+ nir_alu_type_get_base_type(cond_type) != nir_type_uint,
+ "Selector of OpSelect must have a type of OpTypeInt");
+
  bool is_default = true;
  for (const uint32_t *w = block->branch + 2; w < branch_end;) {
-uint32_t literal = 0;
+uint64_t literal = 0;
 if (!is_default) {
-   literal = *w;
-   w++;
+   if (nir_alu_type_get_type_size(cond_type) <= 32) {
+  literal = *w;
+  w++;
+   } else {
+  assert(nir_alu_type_get_type_size(cond_type) == 64);
+  literal = vtn_u64_literal(w);
+  w += 2;
+   }
 }
 
 uint32_t block_id = *w;
@@ -730,9 +747,9 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head 
*cf_list,
 }
 
 nir_ssa_def *cond = NULL;
-util_dynarray_foreach(&cse->values, uint32_t, val) {
-   nir_ssa_def *is_val =
-  nir_ieq(&b->nb, sel, nir_imm_int(&b->nb, *val));
+util_dynarray_foreach(&cse->values, uint64_t, val) {
+   nir_ssa_def *imm = nir_imm_intN_t(&b->nb, *val, sel->bit_size);
+   nir_ssa_def *is_val = nir_ieq(&b->nb, sel, imm);
 
cond = cond ? nir_ior(&b->nb, cond, is_val) : is_val;
 }
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 4/8] spirv: Set lengths on scalar and vector types

[Jason Ekstrand]

---
 src/compiler/spirv/spirv_to_nir.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index a2426bc..253a012 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -887,6 +887,7 @@ vtn_handle_type(struct vtn_builder *b, SpvOp opcode,
case SpvOpTypeBool:
   val->type->base_type = vtn_base_type_scalar;
   val->type->type = glsl_bool_type();
+  val->type->length = 1;
   break;
case SpvOpTypeInt: {
   int bit_size = w[2];
@@ -905,6 +906,7 @@ vtn_handle_type(struct vtn_builder *b, SpvOp opcode,
   default:
  vtn_fail("Invalid int bit size");
   }
+  val->type->length = 1;
   break;
}
 
@@ -924,6 +926,7 @@ vtn_handle_type(struct vtn_builder *b, SpvOp opcode,
   default:
  vtn_fail("Invalid float bit size");
   }
+  val->type->length = 1;
   break;
}
 
@@ -934,6 +937,7 @@ vtn_handle_type(struct vtn_builder *b, SpvOp opcode,
   vtn_assert(glsl_type_is_scalar(base->type));
   val->type->base_type = vtn_base_type_vector;
   val->type->type = glsl_vector_type(glsl_get_base_type(base->type), 
elems);
+  val->type->length = elems;
   val->type->stride = glsl_get_bit_size(base->type) / 8;
   val->type->array_element = base;
   break;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH v3] mesa/spirv: move and rename nir_spirv_supported_capabilities

[Alejandro Piñeiro]

To avoid any vulkan driver to include the GL mtypes.h. Renamed as
eventually this could be used by drivers not using nir.

v2: remove compiler/spirv/spirv.h from mtypes (Alejandro)
v3: added the definition at compiler/shader_info.h (Jason Ekstrand)
---

Sorry for not realizing that spirv.h was a generated file. I also
preferred to add it to shader_info.h. Both options 2 and 3 seemed
somewhat an overkill

 src/compiler/shader_info.h | 13 +
 src/compiler/spirv/nir_spirv.h |  4 ++--
 src/mesa/main/mtypes.h | 13 -
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index bcb3f0fffac..c9140ba9752 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -31,6 +31,19 @@
 extern "C" {
 #endif
 
+struct spirv_supported_capabilities {
+   bool float64;
+   bool image_ms_array;
+   bool tessellation;
+   bool draw_parameters;
+   bool image_read_without_format;
+   bool image_write_without_format;
+   bool int64;
+   bool multiview;
+   bool variable_pointers;
+   bool storage_16bit;
+};
+
 typedef struct shader_info {
const char *name;
 
diff --git a/src/compiler/spirv/nir_spirv.h b/src/compiler/spirv/nir_spirv.h
index 113bd710a00..a2c40e57d18 100644
--- a/src/compiler/spirv/nir_spirv.h
+++ b/src/compiler/spirv/nir_spirv.h
@@ -29,7 +29,7 @@
 #define _NIR_SPIRV_H_
 
 #include "compiler/nir/nir.h"
-#include "main/mtypes.h"
+#include "compiler/shader_info.h"
 
 #ifdef __cplusplus
 extern "C" {
@@ -58,7 +58,7 @@ struct spirv_to_nir_options {
 */
bool lower_workgroup_access_to_offsets;
 
-   struct nir_spirv_supported_capabilities caps;
+   struct spirv_supported_capabilities caps;
 
struct {
   void (*func)(void *private_data,
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 7b7137624c7..397b113dfbc 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3578,19 +3578,6 @@ struct gl_program_constants
GLuint MaxShaderStorageBlocks;
 };
 
-struct nir_spirv_supported_capabilities {
-   bool float64;
-   bool image_ms_array;
-   bool tessellation;
-   bool draw_parameters;
-   bool image_read_without_format;
-   bool image_write_without_format;
-   bool int64;
-   bool multiview;
-   bool variable_pointers;
-   bool storage_16bit;
-};
-
 /**
  * Constants which may be overridden by device driver during context creation
  * but are never changed after that.
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH v3] mesa/spirv: move and rename nir_spirv_supported_capabilities

[Jason Ekstrand]

Thanks!

Reviewed-by: Jason Ekstrand 

On Thu, Dec 7, 2017 at 8:12 AM, Alejandro Piñeiro 
wrote:

> To avoid any vulkan driver to include the GL mtypes.h. Renamed as
> eventually this could be used by drivers not using nir.
>
> v2: remove compiler/spirv/spirv.h from mtypes (Alejandro)
> v3: added the definition at compiler/shader_info.h (Jason Ekstrand)
> ---
>
> Sorry for not realizing that spirv.h was a generated file. I also
> preferred to add it to shader_info.h. Both options 2 and 3 seemed
> somewhat an overkill
>
>  src/compiler/shader_info.h | 13 +
>  src/compiler/spirv/nir_spirv.h |  4 ++--
>  src/mesa/main/mtypes.h | 13 -
>  3 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
> index bcb3f0fffac..c9140ba9752 100644
> --- a/src/compiler/shader_info.h
> +++ b/src/compiler/shader_info.h
> @@ -31,6 +31,19 @@
>  extern "C" {
>  #endif
>
> +struct spirv_supported_capabilities {
> +   bool float64;
> +   bool image_ms_array;
> +   bool tessellation;
> +   bool draw_parameters;
> +   bool image_read_without_format;
> +   bool image_write_without_format;
> +   bool int64;
> +   bool multiview;
> +   bool variable_pointers;
> +   bool storage_16bit;
> +};
> +
>  typedef struct shader_info {
> const char *name;
>
> diff --git a/src/compiler/spirv/nir_spirv.h b/src/compiler/spirv/nir_
> spirv.h
> index 113bd710a00..a2c40e57d18 100644
> --- a/src/compiler/spirv/nir_spirv.h
> +++ b/src/compiler/spirv/nir_spirv.h
> @@ -29,7 +29,7 @@
>  #define _NIR_SPIRV_H_
>
>  #include "compiler/nir/nir.h"
> -#include "main/mtypes.h"
> +#include "compiler/shader_info.h"
>
>  #ifdef __cplusplus
>  extern "C" {
> @@ -58,7 +58,7 @@ struct spirv_to_nir_options {
>  */
> bool lower_workgroup_access_to_offsets;
>
> -   struct nir_spirv_supported_capabilities caps;
> +   struct spirv_supported_capabilities caps;
>
> struct {
>void (*func)(void *private_data,
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 7b7137624c7..397b113dfbc 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3578,19 +3578,6 @@ struct gl_program_constants
> GLuint MaxShaderStorageBlocks;
>  };
>
> -struct nir_spirv_supported_capabilities {
> -   bool float64;
> -   bool image_ms_array;
> -   bool tessellation;
> -   bool draw_parameters;
> -   bool image_read_without_format;
> -   bool image_write_without_format;
> -   bool int64;
> -   bool multiview;
> -   bool variable_pointers;
> -   bool storage_16bit;
> -};
> -
>  /**
>   * Constants which may be overridden by device driver during context
> creation
>   * but are never changed after that.
> --
> 2.11.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] meson: add dep_thread to every lib that includes threads.h

[Emil Velikov]

On 7 December 2017 at 14:51, Eric Engestrom  wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104141
> Signed-off-by: Eric Engestrom 
> ---
>  src/broadcom/meson.build| 2 +-
>  src/gallium/auxiliary/meson.build   | 2 +-
>  src/gallium/state_trackers/nine/meson.build | 1 +
>  src/gallium/targets/xa/meson.build  | 2 +-
>  src/gallium/targets/xvmc/meson.build| 2 +-
>  src/gbm/meson.build | 2 +-
>  src/intel/common/meson.build| 2 +-
>  src/loader/meson.build  | 2 +-
>  src/util/meson.build| 2 +-
>  9 files changed, 9 insertions(+), 8 deletions(-)
>
I doubt we can continue and pretend to be libpthread.so free.
To make it even funnier, depending on moon cycle or other fun factors,
we could get the pthread dependency implicitly satisfied as one of the
other shared libraries already pulls the library.

So how about we simply append -pthread to CC/CXX with at global scope
and drop the all the individual dependencies?
It will safe us a few characters to type, plus will ensure that newly
added binaries don't fall victim of the same issue.

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

[Mesa-dev] [PATCH mesa 4/6] meson: dedup gallium-va logic

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 meson.build | 40 +++-
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/meson.build b/meson.build
index 1917b474b1ff4505651a..5a957ad13d1b39b5f709 100644
--- a/meson.build
+++ b/meson.build
@@ -498,34 +498,32 @@ if with_gallium_omx
   )
 endif
 
-dep_va = []
 _va = get_option('gallium-va')
-if _va == 'auto'
-  if not ['linux', 'bsd'].contains(host_machine.system())
-with_gallium_va = false
-  elif not with_platform_x11
-with_gallium_va = false
-  elif not (with_gallium_r600 or with_gallium_radeonsi or with_gallium_nouveau)
-with_gallium_va = false
-  else
-dep_va = dependency('libva', version : '>= 0.38.0', required : false)
-with_gallium_va = dep_va.found()
-  endif
-elif _va == 'true'
-  if not ['linux', 'bsd'].contains(host_machine.system())
+if not ['linux', 'bsd'].contains(host_machine.system())
+  if _va == 'true'
 error('VA state tracker can only be built on unix-like OSes.')
-  elif not (with_platform_x11 or with_platform_drm)
+  else
+_va = 'false'
+  endif
+elif not (with_platform_x11 or with_platform_drm)
+  if _va == 'true'
 error('VA state tracker requires X11 or drm or wayland platform support.')
-with_gallium_va = false
-  elif not (with_gallium_r600 or with_gallium_radeonsi or with_gallium_nouveau)
+  else
+_va = 'false'
+  endif
+elif not (with_gallium_r600 or with_gallium_radeonsi or with_gallium_nouveau)
+  if _va == 'true'
 error('VA state tracker requires at least one of the following gallium 
drivers: r600, radeonsi, nouveau.')
+  else
+_va = 'false'
   endif
-  dep_va = dependency('libva', version : '>= 0.38.0')
-  with_gallium_va = true
-else
-  with_gallium_va = false
+elif _va == 'auto'
+  _va = 'true'
 endif
+with_gallium_va = _va == 'true'
+dep_va = []
 if with_gallium_va
+  dep_va = dependency('libva', version : '>= 0.38.0')
   dep_va = declare_dependency(
 compile_args : dep_va.get_pkgconfig_variable('cflags').split()
   )
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH mesa 5/6] meson: dedup gallium-xa logic

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 meson.build | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/meson.build b/meson.build
index 5a957ad13d1b39b5f709..04e2fdd19d7274aa5ecf 100644
--- a/meson.build
+++ b/meson.build
@@ -535,26 +535,21 @@ if va_drivers_path == ''
 endif
 
 _xa = get_option('gallium-xa')
-if _xa == 'auto'
-  if not ['linux', 'bsd'].contains(host_machine.system())
-with_gallium_xa = false
-  elif not (with_gallium_nouveau or with_gallium_freedreno or with_gallium_i915
-or with_gallium_svga)
-with_gallium_xa = false
-  else
-with_gallium_xa = true
-  endif
-elif _xa == 'true'
-  if not ['linux', 'bsd'].contains(host_machine.system())
+if not ['linux', 'bsd'].contains(host_machine.system())
+  if _xa == 'true'
 error('XA state tracker can only be built on unix-like OSes.')
-  elif not (with_gallium_nouveau or with_gallium_freedreno or with_gallium_i915
-or with_gallium_svga)
+  else
+_xa = 'false'
+  endif
+elif not (with_gallium_nouveau or with_gallium_freedreno or with_gallium_i915
+  or with_gallium_svga)
+  if _xa == 'true'
 error('XA state tracker requires at least one of the following gallium 
drivers: nouveau, freedreno, i915, svga.')
+  else
+_xa = 'false'
   endif
-  with_gallium_xa = true
-else
-  with_gallium_xa = false
 endif
+with_gallium_xa = _xa != 'false'
 
 d3d_drivers_path = get_option('d3d-drivers-path')
 if d3d_drivers_path == ''
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH mesa 6/6] meson: simplify dri3 logic

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 meson.build | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/meson.build b/meson.build
index 04e2fdd19d7274aa5ecf..1ab790462daeef8b56e0 100644
--- a/meson.build
+++ b/meson.build
@@ -344,15 +344,9 @@ endif
 with_dri2 = (with_dri or with_any_vk) and with_dri_platform == 'drm'
 with_dri3 = get_option('dri3')
 if with_dri3 == 'auto'
-  if host_machine.system() == 'linux' and with_dri2
-with_dri3 = true
-  else
-with_dri3 = false
- endif
-elif with_dri3 == 'true'
-  with_dri3 = true
+  with_dri3 = (host_machine.system() == 'linux' and with_dri2)
 else
-  with_dri3 = false
+  with_dri3 = with_dri3 == 'true'
 endif
 
 if with_any_vk and (with_platform_x11 and not with_dri3)
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH mesa 3/6] meson: dedup gallium-omx logic

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 meson.build | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/meson.build b/meson.build
index 08c9c4b92313e97f0eb1..1917b474b1ff4505651a 100644
--- a/meson.build
+++ b/meson.build
@@ -440,32 +440,32 @@ if xvmc_drivers_path == ''
   xvmc_drivers_path = get_option('libdir')
 endif
 
-dep_omx = []
 _omx = get_option('gallium-omx')
-if _omx == 'auto'
-  if not ['linux', 'bsd'].contains(host_machine.system())
-with_gallium_omx = false
-  elif not with_platform_x11
-with_gallium_omx = false
-  elif not (with_gallium_r600 or with_gallium_radeonsi or with_gallium_nouveau)
-with_gallium_omx = false
-  else
-dep_omx = dependency('libomxil-bellagio', required : false)
-with_gallium_omx = dep_omx.found()
-  endif
-elif _omx == 'true'
-  if not ['linux', 'bsd'].contains(host_machine.system())
+if not ['linux', 'bsd'].contains(host_machine.system())
+  if _omx == 'true'
 error('OMX state tracker can only be built on unix-like OSes.')
-  elif not (with_platform_x11 or with_platform_drm)
+  else
+_omx = 'false'
+  endif
+elif not (with_platform_x11 or with_platform_drm)
+  if _omx == 'true'
 error('OMX state tracker requires X11 or drm platform support.')
-with_gallium_omx = false
-  elif not (with_gallium_r600 or with_gallium_radeonsi or with_gallium_nouveau)
+  else
+_omx = 'false'
+  endif
+elif not (with_gallium_r600 or with_gallium_radeonsi or with_gallium_nouveau)
+  if _omx == 'true'
 error('OMX state tracker requires at least one of the following gallium 
drivers: r600, radeonsi, nouveau.')
+  else
+_omx = 'false'
   endif
+elif _omx == 'auto'
+  _omx = 'true'
+endif
+with_gallium_omx = _omx == 'true'
+dep_omx = []
+if with_gallium_omx
   dep_omx = dependency('libomxil-bellagio')
-  with_gallium_omx = true
-else
-  with_gallium_omx = false
 endif
 
 omx_drivers_path = get_option('omx-libs-path')
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH mesa 2/6] meson: dedup gallium-xvmc logic

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 meson.build | 40 +++-
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/meson.build b/meson.build
index d8f317e1aaf350c26687..08c9c4b92313e97f0eb1 100644
--- a/meson.build
+++ b/meson.build
@@ -404,34 +404,32 @@ if vdpau_drivers_path == ''
   vdpau_drivers_path = join_paths(get_option('libdir'), 'vdpau')
 endif
 
-dep_xvmc = []
 _xvmc = get_option('gallium-xvmc')
-if _xvmc == 'auto'
-  if not ['linux', 'bsd'].contains(host_machine.system())
-with_gallium_xvmc = false
-  elif not with_platform_x11
-with_gallium_xvmc = false
-  elif not (with_gallium_r600 or with_gallium_nouveau)
-with_gallium_xvmc = false
-  else
-dep_xvmc = dependency('xvmc', version : '>= 1.0.6', required : false)
-with_gallium_xvmc = dep_xvmc.found()
-  endif
-elif _xvmc == 'true'
-  if not ['linux', 'bsd'].contains(host_machine.system())
+if not ['linux', 'bsd'].contains(host_machine.system())
+  if _xvmc == 'true'
 error('XVMC state tracker can only be build on unix-like OSes.')
-  elif not with_platform_x11
+  else
+_xvmc = 'false'
+  endif
+elif not with_platform_x11
+  if _xvmc == 'true'
 error('XVMC state tracker requires X11 support.')
-with_gallium_xvmc = false
-  elif not (with_gallium_r600 or with_gallium_nouveau)
+  else
+_xvmc = 'false'
+  endif
+elif not (with_gallium_r600 or with_gallium_nouveau)
+  if _xvmc == 'true'
 error('XVMC state tracker requires at least one of the following gallium 
drivers: r600, nouveau.')
+  else
+_xvmc = 'false'
   endif
-  dep_xvmc = dependency('xvmc', version : '>= 1.0.6')
-  with_gallium_xvmc = true
-else
-  with_gallium_xvmc = false
+elif _xvmc == 'auto'
+  _xvmc = 'true'
 endif
+with_gallium_xvmc = _xvmc == 'true'
+dep_xvmc = []
 if with_gallium_xvmc
+  dep_xvmc = dependency('xvmc', version : '>= 1.0.6')
   dep_xvmc = declare_dependency(
 compile_args : dep_xvmc.get_pkgconfig_variable('cflags').split()
   )
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH mesa 1/6] meson: dedup gallium-vdpau logic

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 meson.build | 45 +
 1 file changed, 21 insertions(+), 24 deletions(-)

diff --git a/meson.build b/meson.build
index 1ea63fb12915c93a67d5..d8f317e1aaf350c26687 100644
--- a/meson.build
+++ b/meson.build
@@ -364,36 +364,33 @@ if with_dri or with_gallium
   endif
 endif
 
-dep_vdpau = []
 _vdpau = get_option('gallium-vdpau')
-if _vdpau == 'auto'
-  if not ['linux', 'bsd'].contains(host_machine.system())
-with_gallium_vdpau = false
-  elif not with_platform_x11
-with_gallium_vdpau = false
-  elif not (with_gallium_r300 or with_gallium_r600 or with_gallium_radeonsi or
-with_gallium_nouveau)
-with_gallium_vdpau = false
-  else
-dep_vdpau = dependency('vdpau', version : '>= 1.1', required : false)
-with_gallium_vdpau = dep_vdpau.found()
-  endif
-elif _vdpau == 'true'
-  if not ['linux', 'bsd'].contains(host_machine.system())
+if not ['linux', 'bsd'].contains(host_machine.system())
+  if _vdpau == 'true'
 error('VDPAU state tracker can only be build on unix-like OSes.')
-  elif not with_platform_x11
+  else
+_vdpau = 'false'
+  endif
+elif not with_platform_x11
+  if _vdpau == 'true'
 error('VDPAU state tracker requires X11 support.')
-with_gallium_vdpau = false
-  elif not (with_gallium_r300 or with_gallium_r600 or with_gallium_radeonsi or
-with_gallium_nouveau)
+  else
+_vdpau = 'false'
+  endif
+elif not (with_gallium_r300 or with_gallium_r600 or with_gallium_radeonsi or
+  with_gallium_nouveau)
+  if _vdpau == 'true'
 error('VDPAU state tracker requires at least one of the following gallium 
drivers: r300, r600, radeonsi, nouveau.')
+  else
+_vdpau = 'false'
   endif
+elif _vdpau == 'auto'
+  _vdpau = 'true'
+endif
+with_gallium_vdpau = _vdpau == 'true'
+dep_vdpau = []
+if with_gallium_vdpau
   dep_vdpau = dependency('vdpau', version : '>= 1.1')
-  with_gallium_vdpau = true
-else
-  with_gallium_vdpau = false
-endif
-if with_gallium_vdpau
   dep_vdpau = declare_dependency(
 compile_args : dep_vdpau.get_pkgconfig_variable('cflags').split()
   )
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH 01/10] mapi: autotools: remove unused MAPI_FILES file list

[Emil Velikov]

From: Emil Velikov 

The sole user was OpenVG, which was removed couple of years ago.

Signed-off-by: Emil Velikov 
---
 src/mapi/Makefile.sources | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/src/mapi/Makefile.sources b/src/mapi/Makefile.sources
index 5647158e3da..4b83caa8ed2 100644
--- a/src/mapi/Makefile.sources
+++ b/src/mapi/Makefile.sources
@@ -2,9 +2,6 @@
 #
 # mapi may be used in several ways
 #
-#  - In default mode, mapi implements the interface defined by mapi.h.  To use
-#this mode, compile MAPI_FILES.
-#
 #  - In util mode, mapi provides utility functions for use with glapi.  To use
 #this mode, compile MAPI_UTIL_FILES with MAPI_MODE_UTIL defined.
 #
@@ -30,14 +27,6 @@ MAPI_BRIDGE_FILES = \
entry_ppc64le_tsd.h \
mapi_tmp.h
 
-MAPI_FILES = \
-   entry.c \
-   stub.c \
-   stub.h \
-   table.c \
-   table.h \
-   $(MAPI_UTIL_FILES)
-
 MAPI_GLAPI_FILES = \
entry.c \
mapi_glapi.c \
-- 
2.15.0

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

[Mesa-dev] [PATCH 02/10] mapi: remove non applicable HAVE_DIX_CONFIG_H hunk

[Emil Velikov]

From: Emil Velikov 

Seeming artefact from when the xserver build was diving directly into
mesa's tree.

Signed-off-by: Emil Velikov 
---
 src/mapi/glapi/glapi_priv.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/src/mapi/glapi/glapi_priv.h b/src/mapi/glapi/glapi_priv.h
index 8f2c6775dc9..0e584f4be96 100644
--- a/src/mapi/glapi/glapi_priv.h
+++ b/src/mapi/glapi/glapi_priv.h
@@ -27,10 +27,6 @@
 #define _GLAPI_PRIV_H
 
 
-#ifdef HAVE_DIX_CONFIG_H
-#include 
-#include "glapi/mesa.h"
-#else /* HAVE_DIX_CONFIG_H */
 #define GL_GLEXT_PROTOTYPES
 #include "GL/gl.h"
 #include "GL/glext.h"
@@ -44,8 +40,6 @@ typedef int GLclampx;
 typedef void *GLeglImageOES;
 #endif
 
-#endif /* HAVE_DIX_CONFIG_H */
-
 #include "glapi/glapi.h"
 
 
-- 
2.15.0

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

[Mesa-dev] [PATCH 04/10] swrast: remove non-applicable GLX_SWAP_COPY_OML comment

[Emil Velikov]

From: Emil Velikov 

Noticed while skimming for GLX_ instances i the dri codebase.
Comment is completely off and was in such a state since day 1.

Signed-off-by: Emil Velikov 
---
 src/mesa/drivers/dri/swrast/swrast.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/mesa/drivers/dri/swrast/swrast.c 
b/src/mesa/drivers/dri/swrast/swrast.c
index 4bee01ad308..8084be64393 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++ b/src/mesa/drivers/dri/swrast/swrast.c
@@ -223,9 +223,6 @@ swrastFillInModes(__DRIscreen *psp,
 unsigned back_buffer_factor;
 mesa_format format;
 
-/* GLX_SWAP_COPY_OML is only supported because the Intel driver doesn't
- * support pageflipping at all.
- */
 static const GLenum back_buffer_modes[] = {
__DRI_ATTRIB_SWAP_NONE, __DRI_ATTRIB_SWAP_UNDEFINED
 };
-- 
2.15.0

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

Re: [Mesa-dev] [PATCH mesa v2] meson: fix pl111 dependency on vc4

[Dylan Baker]

Reviewed-by: Dylan Baker 

Thanks for making those changes.

Quoting Eric Engestrom (2017-12-07 03:25:58)
> src/gallium/winsys/pl111/drm/libpl111winsys.a(pl111_drm_winsys.c.o): In 
> function `pl111_drm_screen_create':
> pl111_drm_winsys.c:(.text+0x33): undefined reference to 
> `vc4_drm_screen_create_renderonly'
> 
> Signed-off-by: Eric Engestrom 
> Reviewed-by: Dylan Baker  (v1)
> ---
> (sent a v2 because the rebase wasn't completely trivial)
> v2: move error message with the imx/etnaviv one and reword it to match
> ---
>  meson.build  |  3 +++
>  src/gallium/meson.build  | 10 +-
>  src/gallium/winsys/pl111/drm/meson.build |  1 +
>  3 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 3e8ea7d17e06e9ededb0..1ea63fb12915c93a67d5 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -190,6 +190,9 @@ endif
>  if with_gallium_imx and not with_gallium_etnaviv
>error('IMX driver requires etnaviv driver')
>  endif
> +if with_gallium_pl111 and not with_gallium_vc4
> +  error('pl111 driver requires vc4 driver')
> +endif
>  
>  dep_libdrm_intel = []
>  if with_dri_i915 or with_gallium_i915
> diff --git a/src/gallium/meson.build b/src/gallium/meson.build
> index 7e841633a9c837658370..2baca8a97ca3cfe36ff1 100644
> --- a/src/gallium/meson.build
> +++ b/src/gallium/meson.build
> @@ -72,17 +72,17 @@ if with_gallium_freedreno
>  else
>driver_freedreno = declare_dependency()
>  endif
> -if with_gallium_pl111
> -  subdir('winsys/pl111/drm')
> -else
> -  driver_pl111 = declare_dependency()
> -endif
>  if with_gallium_vc4
>subdir('winsys/vc4/drm')
>subdir('drivers/vc4')
>  else
>driver_vc4 = declare_dependency()
>  endif
> +if with_gallium_pl111
> +  subdir('winsys/pl111/drm')
> +else
> +  driver_pl111 = declare_dependency()
> +endif
>  if with_gallium_vc5
>subdir('winsys/vc5/drm')
>subdir('drivers/vc5')
> diff --git a/src/gallium/winsys/pl111/drm/meson.build 
> b/src/gallium/winsys/pl111/drm/meson.build
> index 8ba03e3f9795009c725d..9cb6faf31e21e57bd6ab 100644
> --- a/src/gallium/winsys/pl111/drm/meson.build
> +++ b/src/gallium/winsys/pl111/drm/meson.build
> @@ -27,6 +27,7 @@ libpl111winsys = static_library(
>],
>c_args : [c_vis_args],
>dependencies: dep_libdrm,
> +  link_with : libvc4winsys,
>  )
>  
>  driver_pl111 = declare_dependency(
> -- 
> Cheers,
>   Eric
> 


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

[Mesa-dev] [PATCH 06/10] dri/common: move the required GLX_* token definitions locally

[Emil Velikov]

From: Emil Velikov 

Will allow us to remove even bigger hack elsewhere. But more
importantly, we should not be using _any_ GLX tokens in DRI.

Document the gory details about the current side-effects.

Signed-off-by: Emil Velikov 
---
 src/mesa/drivers/dri/common/utils.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/mesa/drivers/dri/common/utils.c 
b/src/mesa/drivers/dri/common/utils.c
index 31b0c517723..63c0f8ba7dc 100644
--- a/src/mesa/drivers/dri/common/utils.c
+++ b/src/mesa/drivers/dri/common/utils.c
@@ -41,6 +41,20 @@
 #include "utils.h"
 #include "dri_util.h"
 
+/* WARNING: HACK: Local defines to avoid pulling glx.h.
+ *
+ * Any parts of this file that use the following defines are either partial or
+ * entirely broken indicate, wrt EGL.
+ *
+ * For example any getConfigAttrib() or indexConfigAttrib() query from EGL for
+ * SLOW or NON_CONFORMANT_CONFIG will not work as expected since the EGL tokens
+ * are different from the GLX ones.
+ */
+#define GLX_NONE0x8000
+#define GLX_SLOW_CONFIG 0x8001
+#define GLX_NON_CONFORMANT_CONFIG   0x800D
+#define GLX_DONT_CARE   0x
+
 /**
  * Create the \c GL_RENDERER string for DRI drivers.
  * 
-- 
2.15.0

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

[Mesa-dev] [PATCH 03/10] mapi: remove duplicate GL typedefs

[Emil Velikov]

From: Emil Velikov 

Remove the instances already available in gl.h or glext.h.
Sadly GLclampx is only available in GLES(1) so we need to keep that one.

Signed-off-by: Emil Velikov 
---
 src/mapi/glapi/glapi_priv.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/src/mapi/glapi/glapi_priv.h b/src/mapi/glapi/glapi_priv.h
index 0e584f4be96..ddfc594a979 100644
--- a/src/mapi/glapi/glapi_priv.h
+++ b/src/mapi/glapi/glapi_priv.h
@@ -31,15 +31,8 @@
 #include "GL/gl.h"
 #include "GL/glext.h"
 
-#ifndef GL_OES_fixed_point
-typedef int GLfixed;
-#endif
 typedef int GLclampx;
 
-#ifndef GL_OES_EGL_image
-typedef void *GLeglImageOES;
-#endif
-
 #include "glapi/glapi.h"
 
 
-- 
2.15.0

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

[Mesa-dev] [PATCH 08/10] i965: reference __DRI_ATTRIB_SWAP_COPY token over the GLX one

[Emil Velikov]

From: Emil Velikov 

Earlier commit updated the code to use the DRI tokens, yet forgot to
update the comment.

Signed-off-by: Emil Velikov 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 0c17b4050c4..91759382e59 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -2028,7 +2028,7 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
   MESA_FORMAT_R8G8B8X8_UNORM,
};
 
-   /* GLX_SWAP_COPY_OML is not supported due to page flipping. */
+   /* __DRI_ATTRIB_SWAP_COPY is not supported due to page flipping. */
static const GLenum back_buffer_modes[] = {
   __DRI_ATTRIB_SWAP_UNDEFINED, __DRI_ATTRIB_SWAP_NONE
};
-- 
2.15.0

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

[Mesa-dev] [PATCH 09/10] mesa: remove duplicate declarations from glheader.h

[Emil Velikov]

From: Emil Velikov 

Remove all the desktop GL and GLX entries from the list.
Former are pulled by the gl.h and glext.h includes at the top while the
latter are not longer needed.

Signed-off-by: Emil Velikov 
---
 src/mesa/main/glheader.h | 54 
 1 file changed, 54 deletions(-)

diff --git a/src/mesa/main/glheader.h b/src/mesa/main/glheader.h
index 3f2a923782c..6d651b88c82 100644
--- a/src/mesa/main/glheader.h
+++ b/src/mesa/main/glheader.h
@@ -45,12 +45,6 @@ extern "C" {
 
 typedef int GLclampx;
 
-
-#ifndef GL_OES_EGL_image
-typedef void *GLeglImageOES;
-#endif
-
-
 #ifndef GL_OES_EGL_image_external
 #define GL_TEXTURE_EXTERNAL_OES 0x8D65
 #define GL_SAMPLER_EXTERNAL_OES 0x8D66
@@ -58,7 +52,6 @@ typedef void *GLeglImageOES;
 #define GL_REQUIRED_TEXTURE_IMAGE_UNITS_OES 0x8D68
 #endif
 
-
 #ifndef GL_OES_point_size_array
 #define GL_POINT_SIZE_ARRAY_OES 0x8B9C
 #define GL_POINT_SIZE_ARRAY_TYPE_OES0x898A
@@ -78,27 +71,11 @@ typedef void *GLeglImageOES;
 #endif
 
 /* GLES 2.0 tokens */
-#ifndef GL_RGB565
-#define GL_RGB565   0x8D62
-#endif
 
 #ifndef GL_TEXTURE_GEN_STR_OES
 #define GL_TEXTURE_GEN_STR_OES  0x8D60
 #endif
 
-#ifndef GL_OES_compressed_paletted_texture
-#define GL_PALETTE4_RGB8_OES0x8B90
-#define GL_PALETTE4_RGBA8_OES   0x8B91
-#define GL_PALETTE4_R5_G6_B5_OES0x8B92
-#define GL_PALETTE4_RGBA4_OES   0x8B93
-#define GL_PALETTE4_RGB5_A1_OES 0x8B94
-#define GL_PALETTE8_RGB8_OES0x8B95
-#define GL_PALETTE8_RGBA8_OES   0x8B96
-#define GL_PALETTE8_R5_G6_B5_OES0x8B97
-#define GL_PALETTE8_RGBA4_OES   0x8B98
-#define GL_PALETTE8_RGB5_A1_OES 0x8B99
-#endif
-
 #ifndef GL_OES_texture_compression_astc
 #define GL_COMPRESSED_RGBA_ASTC_3x3x3_OES   0x93C0
 #define GL_COMPRESSED_RGBA_ASTC_4x3x3_OES   0x93C1
@@ -122,15 +99,6 @@ typedef void *GLeglImageOES;
 #define GL_COMPRESSED_SRGB8_ALPHA8_ASTC_6x6x6_OES   0x93E9
 #endif
 
-#ifndef GL_ES_VERSION_2_0
-#define GL_SHADER_BINARY_FORMATS0x8DF8
-#define GL_NUM_SHADER_BINARY_FORMATS0x8DF9
-#define GL_SHADER_COMPILER  0x8DFA
-#define GL_MAX_VERTEX_UNIFORM_VECTORS   0x8DFB
-#define GL_MAX_VARYING_VECTORS  0x8DFC
-#define GL_MAX_FRAGMENT_UNIFORM_VECTORS 0x8DFD
-#endif
-
 #ifndef GL_ATI_texture_compression_3dc
 #define GL_ATI_texture_compression_3dc  1
 #define GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI   0x8837
@@ -161,28 +129,6 @@ typedef void *GLeglImageOES;
 #define GL_SHADER_PROGRAM_MESA  0x
 
 
-/* Several fields of struct gl_config can take these as values.  Since
- * GLX header files may not be available everywhere they need to be used,
- * redefine them here.
- */
-#define GLX_NONE0x8000
-#define GLX_SLOW_CONFIG 0x8001
-#define GLX_TRUE_COLOR  0x8002
-#define GLX_DIRECT_COLOR0x8003
-#define GLX_PSEUDO_COLOR0x8004
-#define GLX_STATIC_COLOR0x8005
-#define GLX_GRAY_SCALE  0x8006
-#define GLX_STATIC_GRAY 0x8007
-#define GLX_TRANSPARENT_RGB 0x8008
-#define GLX_TRANSPARENT_INDEX   0x8009
-#define GLX_NON_CONFORMANT_CONFIG   0x800D
-#define GLX_SWAP_EXCHANGE_OML   0x8061
-#define GLX_SWAP_COPY_OML   0x8062
-#define GLX_SWAP_UNDEFINED_OML  0x8063
-
-#define GLX_DONT_CARE   0x
-
-
 #ifdef __cplusplus
 }
 #endif
-- 
2.15.0

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

[Mesa-dev] [PATCH 10/10] mesa: reorder and document the tokens in glheader.h

[Emil Velikov]

From: Emil Velikov 

Split into different sections, document each one as well as strange
cases like GL_ATI_texture_compression_3dc.

Signed-off-by: Emil Velikov 
---
 src/mesa/main/glheader.h | 39 +++
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/src/mesa/main/glheader.h b/src/mesa/main/glheader.h
index 6d651b88c82..d4f2ecdf7fa 100644
--- a/src/mesa/main/glheader.h
+++ b/src/mesa/main/glheader.h
@@ -43,7 +43,7 @@ extern "C" {
 #endif
 
 
-typedef int GLclampx;
+/* Common GLES 1.0 and 2.0 tokens */
 
 #ifndef GL_OES_EGL_image_external
 #define GL_TEXTURE_EXTERNAL_OES 0x8D65
@@ -52,6 +52,15 @@ typedef int GLclampx;
 #define GL_REQUIRED_TEXTURE_IMAGE_UNITS_OES 0x8D68
 #endif
 
+#ifndef GL_OES_compressed_ETC1_RGB8_texture
+#define GL_ETC1_RGB8_OES0x8D64
+#endif
+
+
+/* GLES 1.0 only tokens */
+
+typedef int GLclampx;
+
 #ifndef GL_OES_point_size_array
 #define GL_POINT_SIZE_ARRAY_OES 0x8B9C
 #define GL_POINT_SIZE_ARRAY_TYPE_OES0x898A
@@ -65,15 +74,15 @@ typedef int GLclampx;
 #define GL_TEXTURE_CROP_RECT_OES0x8B9D
 #endif
 
-
-#ifndef GL_PROGRAM_BINARY_LENGTH_OES
-#define GL_PROGRAM_BINARY_LENGTH_OES0x8741
+#ifndef GL_TEXTURE_GEN_STR_OES
+#define GL_TEXTURE_GEN_STR_OES  0x8D60
 #endif
 
-/* GLES 2.0 tokens */
 
-#ifndef GL_TEXTURE_GEN_STR_OES
-#define GL_TEXTURE_GEN_STR_OES  0x8D60
+/* GLES 2.0 only tokens */
+
+#ifndef GL_PROGRAM_BINARY_LENGTH_OES
+#define GL_PROGRAM_BINARY_LENGTH_OES0x8741
 #endif
 
 #ifndef GL_OES_texture_compression_astc
@@ -99,15 +108,6 @@ typedef int GLclampx;
 #define GL_COMPRESSED_SRGB8_ALPHA8_ASTC_6x6x6_OES   0x93E9
 #endif
 
-#ifndef GL_ATI_texture_compression_3dc
-#define GL_ATI_texture_compression_3dc  1
-#define GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI   0x8837
-#endif
-
-#ifndef GL_OES_compressed_ETC1_RGB8_texture
-#define GL_ETC1_RGB8_OES0x8D64
-#endif
-
 #ifndef GL_EXT_shader_framebuffer_fetch
 #define GL_FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT 0x8A52
 #endif
@@ -119,6 +119,13 @@ typedef int GLclampx;
 #endif
 
 
+/* There is no formal spec for the following extension. */
+#ifndef GL_ATI_texture_compression_3dc
+#define GL_ATI_texture_compression_3dc  1
+#define GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI   0x8837
+#endif
+
+
 /**
  * Internal token to represent a GLSL shader program (a collection of
  * one or more shaders that get linked together).  Note that GLSL
-- 
2.15.0

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

[Mesa-dev] [PATCH 07/10] i915: reference __DRI_ATTRIB_SWAP_COPY token over the GLX one

[Emil Velikov]

From: Emil Velikov 

Earlier commit updated the code to use the DRI tokens, yet forgot to
update the comment.

Signed-off-by: Emil Velikov 
---
 src/mesa/drivers/dri/i915/intel_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
b/src/mesa/drivers/dri/i915/intel_screen.c
index 5024a69bd41..06c4e95ce8e 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -1058,7 +1058,7 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
   MESA_FORMAT_B8G8R8X8_UNORM
};
 
-   /* GLX_SWAP_COPY_OML is not supported due to page flipping. */
+   /* __DRI_ATTRIB_SWAP_COPY is not supported due to page flipping. */
static const GLenum back_buffer_modes[] = {
   __DRI_ATTRIB_SWAP_UNDEFINED, __DRI_ATTRIB_SWAP_NONE
};
-- 
2.15.0

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

[Mesa-dev] [PATCH 05/10] dri/common: use __DRI_ATTRIB_SWAP* instances when describing db_modes

[Emil Velikov]

From: Emil Velikov 

Somewhat recently Thomas Hellstrom added the respective DRI tokens
and updated the drivers. Update the documentation to match reality.

Signed-off-by: Emil Velikov 
---
 src/mesa/drivers/dri/common/utils.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/common/utils.c 
b/src/mesa/drivers/dri/common/utils.c
index e944754a424..31b0c517723 100644
--- a/src/mesa/drivers/dri/common/utils.c
+++ b/src/mesa/drivers/dri/common/utils.c
@@ -134,11 +134,12 @@ driGetRendererString( char * buffer, const char * 
hardware_name,
  * \param num_depth_stencil_bits  Number of entries in both \c depth_bits and
  *  \c stencil_bits.
  * \param db_modes  Array of buffer swap modes.  If an element has a
- *  value of \c GLX_NONE, then it represents a
- *  single-buffered mode.  Other valid values are
- *  \c GLX_SWAP_EXCHANGE_OML, \c GLX_SWAP_COPY_OML, and
- *  \c GLX_SWAP_UNDEFINED_OML.  See the
- *  GLX_OML_swap_method extension spec for more details.
+ *  value of \c __DRI_ATTRIB_SWAP_NONE, then it
+ *  represents a single-buffered mode.  Other valid
+ *  values are \c __DRI_ATTRIB_SWAP_EXCHANGE,
+ *  \c __DRI_ATTRIB_SWAP_COPY, and \c 
__DRI_ATTRIB_SWAP_UNDEFINED.
+ *  They represent the respective GLX values as in
+ *  the GLX_OML_swap_method extension spec.
  * \param num_db_modes  Number of entries in \c db_modes.
  * \param msaa_samples  Array of msaa sample count. 0 represents a visual
  *  without a multisample buffer.
-- 
2.15.0

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

Re: [Mesa-dev] [PATCH 1/9] i965/fs: Rewrite assign_constant_locations

[Pohjolainen, Topi]

On Wed, Dec 06, 2017 at 08:34:19PM -0800, Jason Ekstrand wrote:
> This rewires the logic for assigning uniform locations to work in terms
> of "complex alignments".  The basic idea is that, as we walk the list of
> instructions, we keep track of the alignment and continuity requirements
> of each slot and assert that the alignments all match up.  We then use
> those alignments in the compaction stage to ensure that everything gets
> placed at a properly aligned register.  The old mechanism handled
> alignments by special-casing each of the bit sizes and placing 64-bit
> values first followed by 32-bit values.
> 
> The old scheme had the advantage of never leaving a hole since all the
> 64-bit values could be tightly packed and so could the 32-bit values.
> However, the new scheme has no type size special cases so it handles not
> only 32 and 64-bit types but should gracefully extend to 16 and 8-bit
> types as the need arises.
> 
> Tested-by: Jose Maria Casanova Crespo 
> ---
>  src/intel/compiler/brw_fs.cpp | 307 
> --
>  1 file changed, 174 insertions(+), 133 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 93bb6b4..41260b4 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -1906,62 +1906,6 @@ fs_visitor::compact_virtual_grfs()
> return progress;
>  }
>  
> -static void
> -set_push_pull_constant_loc(unsigned uniform, int *chunk_start,
> -   unsigned *max_chunk_bitsize,
> -   bool contiguous, unsigned bitsize,
> -   const unsigned target_bitsize,
> -   int *push_constant_loc, int *pull_constant_loc,
> -   unsigned *num_push_constants,
> -   unsigned *num_pull_constants,
> -   const unsigned max_push_components,
> -   const unsigned max_chunk_size,
> -   bool allow_pull_constants,
> -   struct brw_stage_prog_data *stage_prog_data)
> -{
> -   /* This is the first live uniform in the chunk */
> -   if (*chunk_start < 0)
> -  *chunk_start = uniform;
> -
> -   /* Keep track of the maximum bit size access in contiguous uniforms */
> -   *max_chunk_bitsize = MAX2(*max_chunk_bitsize, bitsize);
> -
> -   /* If this element does not need to be contiguous with the next, we
> -* split at this point and everything between chunk_start and u forms a
> -* single chunk.
> -*/
> -   if (!contiguous) {
> -  /* If bitsize doesn't match the target one, skip it */
> -  if (*max_chunk_bitsize != target_bitsize) {
> - /* FIXME: right now we only support 32 and 64-bit accesses */
> - assert(*max_chunk_bitsize == 4 || *max_chunk_bitsize == 8);
> - *max_chunk_bitsize = 0;
> - *chunk_start = -1;
> - return;
> -  }
> -
> -  unsigned chunk_size = uniform - *chunk_start + 1;
> -
> -  /* Decide whether we should push or pull this parameter.  In the
> -   * Vulkan driver, push constants are explicitly exposed via the API
> -   * so we push everything.  In GL, we only push small arrays.
> -   */
> -  if (!allow_pull_constants ||
> -  (*num_push_constants + chunk_size <= max_push_components &&
> -   chunk_size <= max_chunk_size)) {
> - assert(*num_push_constants + chunk_size <= max_push_components);
> - for (unsigned j = *chunk_start; j <= uniform; j++)
> -push_constant_loc[j] = (*num_push_constants)++;
> -  } else {
> - for (unsigned j = *chunk_start; j <= uniform; j++)
> -pull_constant_loc[j] = (*num_pull_constants)++;
> -  }
> -
> -  *max_chunk_bitsize = 0;
> -  *chunk_start = -1;
> -   }
> -}
> -
>  static int
>  get_subgroup_id_param_index(const brw_stage_prog_data *prog_data)
>  {
> @@ -1977,6 +1921,98 @@ get_subgroup_id_param_index(const brw_stage_prog_data 
> *prog_data)
>  }
>  
>  /**
> + * Struct for handling complex alignments.
> + *
> + * A complex alignment is stored as multiplier and an offset.  A value is
> + * considered to be aligned if it is congruent to the offset modulo the
> + * multiplier.
> + */
> +struct cplx_align {
> +   unsigned mul:4;
> +   unsigned offset:4;
> +};
> +
> +#define CPLX_ALIGN_MAX_MUL 8
> +
> +static void
> +cplx_align_assert_sane(struct cplx_align a)
> +{
> +   assert(a.mul > 0 && util_is_power_of_two(a.mul));
> +   assert(a.offset < a.mul);
> +}
> +
> +/**
> + * Combines two alignments to produce a least multiple of sorts.
> + *
> + * The returned alignment is the smallest (in terms of multiplier) such that
> + * anything aligned to both a and b will be aligned to the new alignment.
> + * This function will assert-fail if a and b are not compatible, i.e. if the
> + * offset parameters are such that no common alignment is possible.
> + */
> +static struct cplx_al

Re: [Mesa-dev] [PATCH] meson: Fix building gallium media targets with gallium-xlib glx

[Dylan Baker]

Quoting Eric Engestrom (2017-12-07 04:17:58)
> On Tuesday, 2017-12-05 09:40:53 -0800, Dylan Baker wrote:
> > Signed-off-by: Dylan Baker 
> > ---
> >  meson.build | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index 3e8ea7d17e0..bf6bd551f08 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1107,9 +1107,9 @@ if with_platform_x11
> >  dep_xcb_glx = dependency('xcb-glx', version : '>= 1.8.1')
> >  dep_xxf86vm = dependency('xxf86vm', required : false)
> >endif
> > -  if with_any_vk or with_glx == 'dri' or
> > -  (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx or
> > -   with_gallium_xa)
> > +  if (with_any_vk or with_glx == 'dri' or
> > +   (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx or
> > +with_gallium_xa))
> 
> Hmm, works for me without this, on both meson 43 and 44; I'm guessing
> meson 42 fails to parse this?
> 
> Either way, it doesn't hurt, so:
> Reviewed-by: Eric Engestrom 
> 
> >  dep_xcb = dependency('xcb')
> >  dep_x11_xcb = dependency('x11-xcb')
> >endif
> > -- 
> > 2.15.0
> > 

You need to run meson like this to exercise the bug (I'll add this to the commit
message):
meson builddir -Dglx=gallium-xlib -Ddri-drivers= -Dvulkan-drivers=

The problem is that meson's parser just stops parsing the if statement as soon
as it decides that the expression so far is true and the next token is 'or' and
there is no way for the whole expression to be false even if the next sub
expression is false. Basically laziness is biting us.

I started working on a linter yesterday but I'm doing it the hard way (aka
writing my own parser).


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

Re: [Mesa-dev] [PATCH 1/9] i965/fs: Rewrite assign_constant_locations

[Jason Ekstrand]

On Thu, Dec 7, 2017 at 9:10 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Wed, Dec 06, 2017 at 08:34:19PM -0800, Jason Ekstrand wrote:
> > This rewires the logic for assigning uniform locations to work in terms
> > of "complex alignments".  The basic idea is that, as we walk the list of
> > instructions, we keep track of the alignment and continuity requirements
> > of each slot and assert that the alignments all match up.  We then use
> > those alignments in the compaction stage to ensure that everything gets
> > placed at a properly aligned register.  The old mechanism handled
> > alignments by special-casing each of the bit sizes and placing 64-bit
> > values first followed by 32-bit values.
> >
> > The old scheme had the advantage of never leaving a hole since all the
> > 64-bit values could be tightly packed and so could the 32-bit values.
> > However, the new scheme has no type size special cases so it handles not
> > only 32 and 64-bit types but should gracefully extend to 16 and 8-bit
> > types as the need arises.
> >
> > Tested-by: Jose Maria Casanova Crespo 
> > ---
> >  src/intel/compiler/brw_fs.cpp | 307 --
> 
> >  1 file changed, 174 insertions(+), 133 deletions(-)
> >
> > diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.
> cpp
> > index 93bb6b4..41260b4 100644
> > --- a/src/intel/compiler/brw_fs.cpp
> > +++ b/src/intel/compiler/brw_fs.cpp
> > @@ -1906,62 +1906,6 @@ fs_visitor::compact_virtual_grfs()
> > return progress;
> >  }
> >
> > -static void
> > -set_push_pull_constant_loc(unsigned uniform, int *chunk_start,
> > -   unsigned *max_chunk_bitsize,
> > -   bool contiguous, unsigned bitsize,
> > -   const unsigned target_bitsize,
> > -   int *push_constant_loc, int
> *pull_constant_loc,
> > -   unsigned *num_push_constants,
> > -   unsigned *num_pull_constants,
> > -   const unsigned max_push_components,
> > -   const unsigned max_chunk_size,
> > -   bool allow_pull_constants,
> > -   struct brw_stage_prog_data *stage_prog_data)
> > -{
> > -   /* This is the first live uniform in the chunk */
> > -   if (*chunk_start < 0)
> > -  *chunk_start = uniform;
> > -
> > -   /* Keep track of the maximum bit size access in contiguous uniforms
> */
> > -   *max_chunk_bitsize = MAX2(*max_chunk_bitsize, bitsize);
> > -
> > -   /* If this element does not need to be contiguous with the next, we
> > -* split at this point and everything between chunk_start and u
> forms a
> > -* single chunk.
> > -*/
> > -   if (!contiguous) {
> > -  /* If bitsize doesn't match the target one, skip it */
> > -  if (*max_chunk_bitsize != target_bitsize) {
> > - /* FIXME: right now we only support 32 and 64-bit accesses */
> > - assert(*max_chunk_bitsize == 4 || *max_chunk_bitsize == 8);
> > - *max_chunk_bitsize = 0;
> > - *chunk_start = -1;
> > - return;
> > -  }
> > -
> > -  unsigned chunk_size = uniform - *chunk_start + 1;
> > -
> > -  /* Decide whether we should push or pull this parameter.  In the
> > -   * Vulkan driver, push constants are explicitly exposed via the
> API
> > -   * so we push everything.  In GL, we only push small arrays.
> > -   */
> > -  if (!allow_pull_constants ||
> > -  (*num_push_constants + chunk_size <= max_push_components &&
> > -   chunk_size <= max_chunk_size)) {
> > - assert(*num_push_constants + chunk_size <=
> max_push_components);
> > - for (unsigned j = *chunk_start; j <= uniform; j++)
> > -push_constant_loc[j] = (*num_push_constants)++;
> > -  } else {
> > - for (unsigned j = *chunk_start; j <= uniform; j++)
> > -pull_constant_loc[j] = (*num_pull_constants)++;
> > -  }
> > -
> > -  *max_chunk_bitsize = 0;
> > -  *chunk_start = -1;
> > -   }
> > -}
> > -
> >  static int
> >  get_subgroup_id_param_index(const brw_stage_prog_data *prog_data)
> >  {
> > @@ -1977,6 +1921,98 @@ get_subgroup_id_param_index(const
> brw_stage_prog_data *prog_data)
> >  }
> >
> >  /**
> > + * Struct for handling complex alignments.
> > + *
> > + * A complex alignment is stored as multiplier and an offset.  A value
> is
> > + * considered to be aligned if it is congruent to the offset modulo the
> > + * multiplier.
> > + */
> > +struct cplx_align {
> > +   unsigned mul:4;
> > +   unsigned offset:4;
> > +};
> > +
> > +#define CPLX_ALIGN_MAX_MUL 8
> > +
> > +static void
> > +cplx_align_assert_sane(struct cplx_align a)
> > +{
> > +   assert(a.mul > 0 && util_is_power_of_two(a.mul));
> > +   assert(a.offset < a.mul);
> > +}
> > +
> > +/**
> > + * Combines two alignments to produce a least multiple of sorts.
> > + *
> > + * The re

Re: [Mesa-dev] [PATCH mesa] meson: add dep_thread to every lib that includes threads.h

[Dylan Baker]

Quoting Emil Velikov (2017-12-07 08:40:27)
> On 7 December 2017 at 14:51, Eric Engestrom  wrote:
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104141
> > Signed-off-by: Eric Engestrom 
> > ---
> >  src/broadcom/meson.build| 2 +-
> >  src/gallium/auxiliary/meson.build   | 2 +-
> >  src/gallium/state_trackers/nine/meson.build | 1 +
> >  src/gallium/targets/xa/meson.build  | 2 +-
> >  src/gallium/targets/xvmc/meson.build| 2 +-
> >  src/gbm/meson.build | 2 +-
> >  src/intel/common/meson.build| 2 +-
> >  src/loader/meson.build  | 2 +-
> >  src/util/meson.build| 2 +-
> >  9 files changed, 9 insertions(+), 8 deletions(-)
> >
> I doubt we can continue and pretend to be libpthread.so free.
> To make it even funnier, depending on moon cycle or other fun factors,
> we could get the pthread dependency implicitly satisfied as one of the
> other shared libraries already pulls the library.
> 
> So how about we simply append -pthread to CC/CXX with at global scope
> and drop the all the individual dependencies?
> It will safe us a few characters to type, plus will ensure that newly
> added binaries don't fall victim of the same issue.

Absolutely not. The meson build has dep_thread for a reason, because meson
guarantees that calling `dependency('threads')` will always return the right
value for your platform, even if that platform is windows and doesn't have
pthreads at all (but does the right thing for cygwin).

The reason that we're running into this problem is as you guessed that some
dependencies pull in pthreads implicitly, for example LLVM, which is why we're
seeing this so often in gallium.

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


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

Re: [Mesa-dev] [PATCH mesa] meson: add dep_thread to every lib that includes threads.h

[Dylan Baker]

Reviewed-by: Dylan Baker 

Quoting Eric Engestrom (2017-12-07 06:51:41)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104141
> Signed-off-by: Eric Engestrom 
> ---
>  src/broadcom/meson.build| 2 +-
>  src/gallium/auxiliary/meson.build   | 2 +-
>  src/gallium/state_trackers/nine/meson.build | 1 +
>  src/gallium/targets/xa/meson.build  | 2 +-
>  src/gallium/targets/xvmc/meson.build| 2 +-
>  src/gbm/meson.build | 2 +-
>  src/intel/common/meson.build| 2 +-
>  src/loader/meson.build  | 2 +-
>  src/util/meson.build| 2 +-
>  9 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/src/broadcom/meson.build b/src/broadcom/meson.build
> index dbeee091139dcd05ec5a..6072fd1b997bb29b307a 100644
> --- a/src/broadcom/meson.build
> +++ b/src/broadcom/meson.build
> @@ -39,6 +39,6 @@ if with_gallium_vc5
>  c_args : [c_vis_args, no_override_init_args],
>  link_whole : [libbroadcom_compiler, libbroadcom_qpu],
>  build_by_default : false,
> -dependencies: dep_valgrind,
> +dependencies: [dep_valgrind, dep_thread],
>)
>  endif
> diff --git a/src/gallium/auxiliary/meson.build 
> b/src/gallium/auxiliary/meson.build
> index 3e623fd099fe4b60a5de..4d59f07fd31f3a154934 100644
> --- a/src/gallium/auxiliary/meson.build
> +++ b/src/gallium/auxiliary/meson.build
> @@ -495,7 +495,7 @@ libgallium = static_library(
>],
>c_args : [c_vis_args, c_msvc_compat_args],
>cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
> -  dependencies : [dep_libdrm, dep_llvm, dep_unwind, dep_dl, dep_m],
> +  dependencies : [dep_libdrm, dep_llvm, dep_unwind, dep_dl, dep_m, 
> dep_thread],
>build_by_default : false,
>  )
>  
> diff --git a/src/gallium/state_trackers/nine/meson.build 
> b/src/gallium/state_trackers/nine/meson.build
> index 797ef389a69f164d7440..491b7937ab19d754e498 100644
> --- a/src/gallium/state_trackers/nine/meson.build
> +++ b/src/gallium/state_trackers/nine/meson.build
> @@ -66,4 +66,5 @@ libnine_st = static_library(
>include_directories : [
>  inc_d3d9, inc_gallium, inc_include, inc_src, inc_gallium_aux,
>],
> +  dependencies : dep_thread,
>  )
> diff --git a/src/gallium/targets/xa/meson.build 
> b/src/gallium/targets/xa/meson.build
> index f16921dfc9c443a166b4..f25999d1603c2873897a 100644
> --- a/src/gallium/targets/xa/meson.build
> +++ b/src/gallium/targets/xa/meson.build
> @@ -45,7 +45,7 @@ libxatracker = shared_library(
>],
>link_depends : xa_link_depends,
>dependencies : [
> -dep_xcb, dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, dep_libdrm,
> +dep_xcb, dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, dep_libdrm, dep_thread,
>  driver_nouveau, driver_i915, driver_svga, driver_freedreno,
>],
>install : true,
> diff --git a/src/gallium/targets/xvmc/meson.build 
> b/src/gallium/targets/xvmc/meson.build
> index 76de816efed7559602a3..48759de910f88e66b82b 100644
> --- a/src/gallium/targets/xvmc/meson.build
> +++ b/src/gallium/targets/xvmc/meson.build
> @@ -45,7 +45,7 @@ libxvmc_gallium = shared_library(
>  libpipe_loader_static, libws_null, libwsw,
>],
>dependencies : [
> -dep_xcb, dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, dep_libdrm,
> +dep_xcb, dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, dep_libdrm, dep_thread,
>  driver_r600, driver_nouveau,
>],
>link_depends : xvmc_link_depends,
> diff --git a/src/gbm/meson.build b/src/gbm/meson.build
> index 4b550e06f2790ae9a13d..6e512996add1cfadd189 100644
> --- a/src/gbm/meson.build
> +++ b/src/gbm/meson.build
> @@ -54,7 +54,7 @@ libgbm = shared_library(
>c_args : [c_vis_args, args_gbm],
>link_args : [ld_args_gc_sections],
>link_with : [libloader, libmesa_util, libxmlconfig],
> -  dependencies : [deps_gbm, dep_dl],
> +  dependencies : [deps_gbm, dep_dl, dep_thread],
>version : '1.0.0',
>install : true,
>  )
> diff --git a/src/intel/common/meson.build b/src/intel/common/meson.build
> index cbcf6647531193142cd5..19472e306f4577ebc231 100644
> --- a/src/intel/common/meson.build
> +++ b/src/intel/common/meson.build
> @@ -40,5 +40,5 @@ libintel_common = static_library(
>files_libintel_common,
>include_directories : [inc_common, inc_intel],
>c_args : [c_vis_args, no_override_init_args],
> -  dependencies : [dep_expat, dep_libdrm],
> +  dependencies : [dep_expat, dep_libdrm, dep_thread],
>  )
> diff --git a/src/loader/meson.build b/src/loader/meson.build
> index 05268f58f3f138fe0eb0..e4455e9a72b24891f58b 100644
> --- a/src/loader/meson.build
> +++ b/src/loader/meson.build
> @@ -41,6 +41,6 @@ libloader = static_library(
> xmlpool_options_h],
>c_args : [c_vis_args, '-DUSE_DRICONF'],
>include_directories : [inc_include, inc_src, inc_util],
> -  dependencies : dep_libdrm,
> +  dependencies : [dep_libdrm, dep_thread],
>build_by_default : false,
>  )
> diff --git a/src/util/meson.build b/src/util/meson.build
> index b54c20796ff0

Re: [Mesa-dev] [PATCH mesa 1/6] meson: dedup gallium-vdpau logic

[Dylan Baker]

I didn't look at these super closely after the vdpau one, but we use this logic
elsewhere in the meson build,

For the series,
Reviewed-by: Dylan Baker 

Quoting Eric Engestrom (2017-12-07 08:52:17)
> Signed-off-by: Eric Engestrom 
> ---
>  meson.build | 45 +
>  1 file changed, 21 insertions(+), 24 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 1ea63fb12915c93a67d5..d8f317e1aaf350c26687 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -364,36 +364,33 @@ if with_dri or with_gallium
>endif
>  endif
>  
> -dep_vdpau = []
>  _vdpau = get_option('gallium-vdpau')
> -if _vdpau == 'auto'
> -  if not ['linux', 'bsd'].contains(host_machine.system())
> -with_gallium_vdpau = false
> -  elif not with_platform_x11
> -with_gallium_vdpau = false
> -  elif not (with_gallium_r300 or with_gallium_r600 or with_gallium_radeonsi 
> or
> -with_gallium_nouveau)
> -with_gallium_vdpau = false
> -  else
> -dep_vdpau = dependency('vdpau', version : '>= 1.1', required : false)
> -with_gallium_vdpau = dep_vdpau.found()
> -  endif
> -elif _vdpau == 'true'
> -  if not ['linux', 'bsd'].contains(host_machine.system())
> +if not ['linux', 'bsd'].contains(host_machine.system())
> +  if _vdpau == 'true'
>  error('VDPAU state tracker can only be build on unix-like OSes.')
> -  elif not with_platform_x11
> +  else
> +_vdpau = 'false'
> +  endif
> +elif not with_platform_x11
> +  if _vdpau == 'true'
>  error('VDPAU state tracker requires X11 support.')
> -with_gallium_vdpau = false
> -  elif not (with_gallium_r300 or with_gallium_r600 or with_gallium_radeonsi 
> or
> -with_gallium_nouveau)
> +  else
> +_vdpau = 'false'
> +  endif
> +elif not (with_gallium_r300 or with_gallium_r600 or with_gallium_radeonsi or
> +  with_gallium_nouveau)
> +  if _vdpau == 'true'
>  error('VDPAU state tracker requires at least one of the following 
> gallium drivers: r300, r600, radeonsi, nouveau.')
> +  else
> +_vdpau = 'false'
>endif
> +elif _vdpau == 'auto'
> +  _vdpau = 'true'
> +endif
> +with_gallium_vdpau = _vdpau == 'true'
> +dep_vdpau = []
> +if with_gallium_vdpau
>dep_vdpau = dependency('vdpau', version : '>= 1.1')
> -  with_gallium_vdpau = true
> -else
> -  with_gallium_vdpau = false
> -endif
> -if with_gallium_vdpau
>dep_vdpau = declare_dependency(
>  compile_args : dep_vdpau.get_pkgconfig_variable('cflags').split()
>)
> -- 
> Cheers,
>   Eric
> 


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

Re: [Mesa-dev] [PATCH] meson: Add lmsensors to gallium libgl-xlib target.

[Dylan Baker]

I don't suppose someone would like to ack this?

Quoting Dylan Baker (2017-12-04 14:05:12)
> Fixes: 5e71efef44b992b5d70b ("meson: Add lmsensors support")
> Signed-off-by: Dylan Baker 
> ---
>  src/gallium/targets/libgl-xlib/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/targets/libgl-xlib/meson.build 
> b/src/gallium/targets/libgl-xlib/meson.build
> index 825b7b4a0f1..d0241a59ebe 100644
> --- a/src/gallium/targets/libgl-xlib/meson.build
> +++ b/src/gallium/targets/libgl-xlib/meson.build
> @@ -62,7 +62,7 @@ libgl = shared_library(
>  libxlib, libws_xlib, libsoftpipe, libtrace, librbug, libglapi_static,
>  libgallium, libmesa_util, libmesa_gallium, gallium_xlib_link_with,
>],
> -  dependencies : [dep_clock, dep_unwind, gallium_xlib_depends],
> +  dependencies : [dep_clock, dep_unwind, dep_lmsensors, 
> gallium_xlib_depends],
>install : true,
>version : '1.5.0',
>  )
> -- 
> 2.15.0
> 


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

[Mesa-dev] [PATCH] radeon/vce: move destroy command before feedback command

[Leo Liu]

VCE processing IBs starts from session and task info at first level,
other commands processed subsequently. The task info for destroy is
embedded to destroy command, resulting that feedback command is not
properly procoessed. This is causing kernel spin VM fault messages on
Polaris and Vega10 card when running ends at encode application.

The fix is also verified on VCE physical mode card.
 
Signed-off-by: Leo Liu 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/radeon/radeon_vce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 69e602210b..427bf01ed8 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -246,8 +246,8 @@ static void rvce_destroy(struct pipe_video_codec *encoder)
si_vid_create_buffer(enc->screen, &fb, 512, PIPE_USAGE_STAGING);
enc->fb = &fb;
enc->session(enc);
-   enc->feedback(enc);
enc->destroy(enc);
+   enc->feedback(enc);
flush(enc);
si_vid_destroy_buffer(&fb);
}
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] meson: Fix building gallium media targets with gallium-xlib glx

[Eric Engestrom]

On Thursday, 2017-12-07 09:16:24 -0800, Dylan Baker wrote:
> Quoting Eric Engestrom (2017-12-07 04:17:58)
> > On Tuesday, 2017-12-05 09:40:53 -0800, Dylan Baker wrote:
> > > Signed-off-by: Dylan Baker 
> > > ---
> > >  meson.build | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/meson.build b/meson.build
> > > index 3e8ea7d17e0..bf6bd551f08 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -1107,9 +1107,9 @@ if with_platform_x11
> > >  dep_xcb_glx = dependency('xcb-glx', version : '>= 1.8.1')
> > >  dep_xxf86vm = dependency('xxf86vm', required : false)
> > >endif
> > > -  if with_any_vk or with_glx == 'dri' or
> > > -  (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx or
> > > -   with_gallium_xa)
> > > +  if (with_any_vk or with_glx == 'dri' or
> > > +   (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx or
> > > +with_gallium_xa))
> > 
> > Hmm, works for me without this, on both meson 43 and 44; I'm guessing
> > meson 42 fails to parse this?
> > 
> > Either way, it doesn't hurt, so:
> > Reviewed-by: Eric Engestrom 
> > 
> > >  dep_xcb = dependency('xcb')
> > >  dep_x11_xcb = dependency('x11-xcb')
> > >endif
> > > -- 
> > > 2.15.0
> > > 
> 
> You need to run meson like this to exercise the bug (I'll add this to the 
> commit
> message):
> meson builddir -Dglx=gallium-xlib -Ddri-drivers= -Dvulkan-drivers=
> 
> The problem is that meson's parser just stops parsing the if statement as soon
> as it decides that the expression so far is true and the next token is 'or' 
> and
> there is no way for the whole expression to be false even if the next sub
> expression is false. Basically laziness is biting us.
> 
> I started working on a linter yesterday but I'm doing it the hard way (aka
> writing my own parser).

I'm assuming going to route of adding an mlint.py in meson would allow
you to reuse a ton of code (esp. parsing)? I kinda like the idea of
simply typing `meson lint` to validate all the meson code.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 1/6] meson: dedup gallium-vdpau logic

[Eric Engestrom]

On Thursday, 2017-12-07 09:29:26 -0800, Dylan Baker wrote:
> I didn't look at these super closely after the vdpau one, but we use this 
> logic
> elsewhere in the meson build,
> 
> For the series,
> Reviewed-by: Dylan Baker 

Thanks; I've actually found a few more bits of code that can be removed,
but I think I'll send a single patch with all of them.
I'll push the lot later, once you've seen that final patch too.

> 
> Quoting Eric Engestrom (2017-12-07 08:52:17)
> > Signed-off-by: Eric Engestrom 
> > ---
> >  meson.build | 45 +
> >  1 file changed, 21 insertions(+), 24 deletions(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index 1ea63fb12915c93a67d5..d8f317e1aaf350c26687 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -364,36 +364,33 @@ if with_dri or with_gallium
> >endif
> >  endif
> >  
> > -dep_vdpau = []
> >  _vdpau = get_option('gallium-vdpau')
> > -if _vdpau == 'auto'
> > -  if not ['linux', 'bsd'].contains(host_machine.system())
> > -with_gallium_vdpau = false
> > -  elif not with_platform_x11
> > -with_gallium_vdpau = false
> > -  elif not (with_gallium_r300 or with_gallium_r600 or 
> > with_gallium_radeonsi or
> > -with_gallium_nouveau)
> > -with_gallium_vdpau = false
> > -  else
> > -dep_vdpau = dependency('vdpau', version : '>= 1.1', required : false)
> > -with_gallium_vdpau = dep_vdpau.found()
> > -  endif
> > -elif _vdpau == 'true'
> > -  if not ['linux', 'bsd'].contains(host_machine.system())
> > +if not ['linux', 'bsd'].contains(host_machine.system())
> > +  if _vdpau == 'true'
> >  error('VDPAU state tracker can only be build on unix-like OSes.')
> > -  elif not with_platform_x11
> > +  else
> > +_vdpau = 'false'
> > +  endif
> > +elif not with_platform_x11
> > +  if _vdpau == 'true'
> >  error('VDPAU state tracker requires X11 support.')
> > -with_gallium_vdpau = false
> > -  elif not (with_gallium_r300 or with_gallium_r600 or 
> > with_gallium_radeonsi or
> > -with_gallium_nouveau)
> > +  else
> > +_vdpau = 'false'
> > +  endif
> > +elif not (with_gallium_r300 or with_gallium_r600 or with_gallium_radeonsi 
> > or
> > +  with_gallium_nouveau)
> > +  if _vdpau == 'true'
> >  error('VDPAU state tracker requires at least one of the following 
> > gallium drivers: r300, r600, radeonsi, nouveau.')
> > +  else
> > +_vdpau = 'false'
> >endif
> > +elif _vdpau == 'auto'
> > +  _vdpau = 'true'
> > +endif
> > +with_gallium_vdpau = _vdpau == 'true'
> > +dep_vdpau = []
> > +if with_gallium_vdpau
> >dep_vdpau = dependency('vdpau', version : '>= 1.1')
> > -  with_gallium_vdpau = true
> > -else
> > -  with_gallium_vdpau = false
> > -endif
> > -if with_gallium_vdpau
> >dep_vdpau = declare_dependency(
> >  compile_args : dep_vdpau.get_pkgconfig_variable('cflags').split()
> >)
> > -- 
> > Cheers,
> >   Eric
> > 


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

Re: [Mesa-dev] [PATCH] meson: Add lmsensors to gallium libgl-xlib target.

[Eric Engestrom]

On Thursday, 2017-12-07 09:32:39 -0800, Dylan Baker wrote:
> I don't suppose someone would like to ack this?
> 
> Quoting Dylan Baker (2017-12-04 14:05:12)
> > Fixes: 5e71efef44b992b5d70b ("meson: Add lmsensors support")
> > Signed-off-by: Dylan Baker 
> > ---
> >  src/gallium/targets/libgl-xlib/meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/gallium/targets/libgl-xlib/meson.build 
> > b/src/gallium/targets/libgl-xlib/meson.build
> > index 825b7b4a0f1..d0241a59ebe 100644
> > --- a/src/gallium/targets/libgl-xlib/meson.build
> > +++ b/src/gallium/targets/libgl-xlib/meson.build
> > @@ -62,7 +62,7 @@ libgl = shared_library(
> >  libxlib, libws_xlib, libsoftpipe, libtrace, librbug, libglapi_static,
> >  libgallium, libmesa_util, libmesa_gallium, gallium_xlib_link_with,
> >],
> > -  dependencies : [dep_clock, dep_unwind, gallium_xlib_depends],
> > +  dependencies : [dep_clock, dep_unwind, dep_lmsensors, 
> > gallium_xlib_depends],

needed because `link_with: libgallium`

Reviewed-by: Eric Engestrom 

I'm not clear on `link_with:` though: shouldn't that track deps so that
we don't need to do this manually?

> >install : true,
> >version : '1.5.0',
> >  )
> > -- 
> > 2.15.0
> > 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/9] i965/fs: Rewrite assign_constant_locations

[Pohjolainen, Topi]

On Thu, Dec 07, 2017 at 09:25:08AM -0800, Jason Ekstrand wrote:
> On Thu, Dec 7, 2017 at 9:10 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
> 
> > On Wed, Dec 06, 2017 at 08:34:19PM -0800, Jason Ekstrand wrote:
> > > This rewires the logic for assigning uniform locations to work in terms
> > > of "complex alignments".  The basic idea is that, as we walk the list of
> > > instructions, we keep track of the alignment and continuity requirements
> > > of each slot and assert that the alignments all match up.  We then use
> > > those alignments in the compaction stage to ensure that everything gets
> > > placed at a properly aligned register.  The old mechanism handled
> > > alignments by special-casing each of the bit sizes and placing 64-bit
> > > values first followed by 32-bit values.
> > >
> > > The old scheme had the advantage of never leaving a hole since all the
> > > 64-bit values could be tightly packed and so could the 32-bit values.
> > > However, the new scheme has no type size special cases so it handles not
> > > only 32 and 64-bit types but should gracefully extend to 16 and 8-bit
> > > types as the need arises.
> > >
> > > Tested-by: Jose Maria Casanova Crespo 
> > > ---
> > >  src/intel/compiler/brw_fs.cpp | 307 --
> > 
> > >  1 file changed, 174 insertions(+), 133 deletions(-)
> > >
> > > diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.
> > cpp
> > > index 93bb6b4..41260b4 100644
> > > --- a/src/intel/compiler/brw_fs.cpp
> > > +++ b/src/intel/compiler/brw_fs.cpp
> > > @@ -1906,62 +1906,6 @@ fs_visitor::compact_virtual_grfs()
> > > return progress;
> > >  }
> > >
> > > -static void
> > > -set_push_pull_constant_loc(unsigned uniform, int *chunk_start,
> > > -   unsigned *max_chunk_bitsize,
> > > -   bool contiguous, unsigned bitsize,
> > > -   const unsigned target_bitsize,
> > > -   int *push_constant_loc, int
> > *pull_constant_loc,
> > > -   unsigned *num_push_constants,
> > > -   unsigned *num_pull_constants,
> > > -   const unsigned max_push_components,
> > > -   const unsigned max_chunk_size,
> > > -   bool allow_pull_constants,
> > > -   struct brw_stage_prog_data *stage_prog_data)
> > > -{
> > > -   /* This is the first live uniform in the chunk */
> > > -   if (*chunk_start < 0)
> > > -  *chunk_start = uniform;
> > > -
> > > -   /* Keep track of the maximum bit size access in contiguous uniforms
> > */
> > > -   *max_chunk_bitsize = MAX2(*max_chunk_bitsize, bitsize);
> > > -
> > > -   /* If this element does not need to be contiguous with the next, we
> > > -* split at this point and everything between chunk_start and u
> > forms a
> > > -* single chunk.
> > > -*/
> > > -   if (!contiguous) {
> > > -  /* If bitsize doesn't match the target one, skip it */
> > > -  if (*max_chunk_bitsize != target_bitsize) {
> > > - /* FIXME: right now we only support 32 and 64-bit accesses */
> > > - assert(*max_chunk_bitsize == 4 || *max_chunk_bitsize == 8);
> > > - *max_chunk_bitsize = 0;
> > > - *chunk_start = -1;
> > > - return;
> > > -  }
> > > -
> > > -  unsigned chunk_size = uniform - *chunk_start + 1;
> > > -
> > > -  /* Decide whether we should push or pull this parameter.  In the
> > > -   * Vulkan driver, push constants are explicitly exposed via the
> > API
> > > -   * so we push everything.  In GL, we only push small arrays.
> > > -   */
> > > -  if (!allow_pull_constants ||
> > > -  (*num_push_constants + chunk_size <= max_push_components &&
> > > -   chunk_size <= max_chunk_size)) {
> > > - assert(*num_push_constants + chunk_size <=
> > max_push_components);
> > > - for (unsigned j = *chunk_start; j <= uniform; j++)
> > > -push_constant_loc[j] = (*num_push_constants)++;
> > > -  } else {
> > > - for (unsigned j = *chunk_start; j <= uniform; j++)
> > > -pull_constant_loc[j] = (*num_pull_constants)++;
> > > -  }
> > > -
> > > -  *max_chunk_bitsize = 0;
> > > -  *chunk_start = -1;
> > > -   }
> > > -}
> > > -
> > >  static int
> > >  get_subgroup_id_param_index(const brw_stage_prog_data *prog_data)
> > >  {
> > > @@ -1977,6 +1921,98 @@ get_subgroup_id_param_index(const
> > brw_stage_prog_data *prog_data)
> > >  }
> > >
> > >  /**
> > > + * Struct for handling complex alignments.
> > > + *
> > > + * A complex alignment is stored as multiplier and an offset.  A value
> > is
> > > + * considered to be aligned if it is congruent to the offset modulo the
> > > + * multiplier.
> > > + */
> > > +struct cplx_align {
> > > +   unsigned mul:4;
> > > +   unsigned offset:4;
> > > +};
> > > +
> > > +#define CPLX_ALIGN

Re: [Mesa-dev] [PATCH] meson: Fix building gallium media targets with gallium-xlib glx

[Dylan Baker]

Quoting Eric Engestrom (2017-12-07 09:37:47)
> On Thursday, 2017-12-07 09:16:24 -0800, Dylan Baker wrote:
> > Quoting Eric Engestrom (2017-12-07 04:17:58)
> > > On Tuesday, 2017-12-05 09:40:53 -0800, Dylan Baker wrote:
> > > > Signed-off-by: Dylan Baker 
> > > > ---
> > > >  meson.build | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/meson.build b/meson.build
> > > > index 3e8ea7d17e0..bf6bd551f08 100644
> > > > --- a/meson.build
> > > > +++ b/meson.build
> > > > @@ -1107,9 +1107,9 @@ if with_platform_x11
> > > >  dep_xcb_glx = dependency('xcb-glx', version : '>= 1.8.1')
> > > >  dep_xxf86vm = dependency('xxf86vm', required : false)
> > > >endif
> > > > -  if with_any_vk or with_glx == 'dri' or
> > > > -  (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx or
> > > > -   with_gallium_xa)
> > > > +  if (with_any_vk or with_glx == 'dri' or
> > > > +   (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx or
> > > > +with_gallium_xa))
> > > 
> > > Hmm, works for me without this, on both meson 43 and 44; I'm guessing
> > > meson 42 fails to parse this?
> > > 
> > > Either way, it doesn't hurt, so:
> > > Reviewed-by: Eric Engestrom 
> > > 
> > > >  dep_xcb = dependency('xcb')
> > > >  dep_x11_xcb = dependency('x11-xcb')
> > > >endif
> > > > -- 
> > > > 2.15.0
> > > > 
> > 
> > You need to run meson like this to exercise the bug (I'll add this to the 
> > commit
> > message):
> > meson builddir -Dglx=gallium-xlib -Ddri-drivers= -Dvulkan-drivers=
> > 
> > The problem is that meson's parser just stops parsing the if statement as 
> > soon
> > as it decides that the expression so far is true and the next token is 'or' 
> > and
> > there is no way for the whole expression to be false even if the next sub
> > expression is false. Basically laziness is biting us.
> > 
> > I started working on a linter yesterday but I'm doing it the hard way (aka
> > writing my own parser).
> 
> I'm assuming going to route of adding an mlint.py in meson would allow
> you to reuse a ton of code (esp. parsing)? I kinda like the idea of
> simply typing `meson lint` to validate all the meson code.

The problem is that meson's parser is lazy and doesn't exhaust expressions, so
it wouldn't have caught any of the issue's I would want a linter to catch (like
the glx=gallium-xlib bug). I also think having a second parser that is not
recursive descent is useful in it's own right, in part since it proves the claim
that meson could be rewritten if needed.


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

Re: [Mesa-dev] [PATCH] i965: Enable disk shader cache by default

[Matt Turner]

On Tue, Dec 5, 2017 at 3:40 PM, Jordan Justen  wrote:
> On 2017-12-05 14:49:28, Mark Janes wrote:
>> Jordan Justen  writes:
>>
>> > On 2017-12-05 09:13:11, Mark Janes wrote:
>> >> Jordan Justen  writes:
>> >>
>> >> > On 2017-11-08 17:26:47, Timothy Arceri wrote:
>> >> >> Reviewed-by: Timothy Arceri 
>> >> >>
>> >> >> Mark may want to consider adding some of the once a day type CI runs 
>> >> >> for
>> >> >> this. For example running the test suite for two consecutive runs on 
>> >> >> the
>> >> >> same build so that the second run uses the shader cache and also a
>> >> >> second run the uses MESA_GLSL=cache_fb to force testing of the cache
>> >> >> fallback path.
>> >> >
>> >> > Yeah. We discussed this previously, but I don't think it's been
>> >> > implemented yet. My opinion is that it could perhaps be a weekly test.
>> >>
>> >> This automation is implemented now. It found the issues reported in
>> >> https://bugs.freedesktop.org/show_bug.cgi?id=103988
>> >>
>> >> My opinion is that this test strategy is inadequate.
>> >
>> > Meaning you think we cannot enable i965 shader cache for the 18.0
>> > release?
>>
>> I haven't heard anyone express confidence that this feature is bug-free,
>> and I don't know on what basis that claim could be made.  I appreciate
>> that a lot of have manual testing has been done.  Do you feel confident
>> that the cache can be enabled for all mesa customers without disruption?
>
> If we had enabled it two months ago, then yes, we would have worked
> through the niche issues, or discovered the so-far-hidden major land
> mine. At this point, it's getting risky. In a month, I will say no.
>
>> > We are already ~1.5 months away from the next stable branch point. If
>> > we want to enable this in 18.0, we should be using this time to see if
>> > enabling the cache by default has some large unexpected side effect in
>> > our graphics stack, or breaks real-world apps.
>>
>> I agree.  We should encourage as many users as possible to enable the
>> shader cache in their environments.  At least one stable release should
>> be out with a working cache, where the feature can be enabled by those
>> who are eager to benefit from it.  I assume there will be a lot of them,
>> and they could flush out issues for everyone who has no idea what a
>> shader cache is.
>>
>> >> Adding a dimension to the test matrix has high cost, especially when
>> >> combined with other dimensions of the test matrix (does shader cache
>> >> need to be tested for 32/64 bit builds? For hswgt1/hswgt2/hswgt3e?).
>> >
>> > Are you saying this is too high cost to run per check-in? Do you need
>> > to disable it for the health of CI? I think I proposed that daily, or
>> > perhaps even weekly would be adequate.
>>
>> Certainly, the test time per line of shader cache code is massively
>> higher than any other feature, even if you run it just once a month.
>> Other features have tests that run in milliseconds, not 30min * 20
>> machines.
>
> The scope of this feature is nearly the entire API. It is justified to
> throw the entire GL suite of tests at it on a regular basis. The cost
> of running this once per week ought to be reasonable.

But the entire API boils down to a comparatively small set of
non-orthogonal state. The configuration of those nobs seems to me like
the place things are most likely to break.

I think there's value in testing that we're hitting the cache, but if
we're not it's not a functional regression. I'm more concerned about
ensuring we don't have bugs that affect functionality and cause things
to break.

The program key for fragment shaders looks like:

/** The program key for Fragment/Pixel Shaders. */
struct brw_wm_prog_key {
   /* Some collection of BRW_WM_IZ_* */
   uint8_t iz_lookup;
   bool stats_wm:1;
   bool flat_shade:1;
   unsigned nr_color_regions:5;
   bool replicate_alpha:1;
   bool clamp_fragment_color:1;
   bool persample_interp:1;
   bool multisample_fbo:1;
   bool frag_coord_adds_sample_pos:1;
   enum brw_wm_aa_enable line_aa:2;
   bool high_quality_derivatives:1;
   bool force_dual_color_blend:1;
   bool coherent_fb_fetch:1;

   uint64_t input_slots_valid;
   unsigned program_string_id;
   GLenum alpha_test_func;  /* < For Gen4/5 MRT alpha test */
   float alpha_test_ref;

   struct brw_sampler_prog_key_data tex;
};

and it's the most complex of the shader stages. Wouldn't you feel a
lot safer if we just had a piglit test for each of those nobs that
compiled a shader, then changed some non-orthogonal state, and then
rendered with it, thus confirming that it didn't get the wrong shader
program out of the cache?

I know I've run into cases numerous times where piglit doesn't
actually test something, or only one seemingly unrelated test in all
50 thousand tickles a real bug in my code. I feel uncomfortable
assuming that piglit's existing coverage is good enough.

In general, I'm still bothered by the idea of just running piglit
twice. That's a very untargeted approach that doesn't 

Re: [Mesa-dev] [PATCH 1/2] intel/fs: Implement GRF bank conflict mitigation pass.

[Matt Turner]

On Thu, Jun 22, 2017 at 12:20 PM, Francisco Jerez  wrote:
> Unnecessary GRF bank conflicts increase the issue time of ternary
> instructions (the overwhelmingly most common of which is MAD) by
> roughly 50%, leading to reduced ALU throughput.  This pass attempts to
> minimize the number of bank conflicts by rearranging the layout of the
> GRF space post-register allocation.  It's in general not possible to
> eliminate all of them without introducing extra copies, which are
> typically more expensive than the bank conflict itself.
>
> In a shader-db run on SKL this helps roughly 46k shaders:
>
>total conflicts in shared programs: 1008981 -> 600461 (-40.49%)
>conflicts in affected programs: 816222 -> 407702 (-50.05%)
>helped: 46234
>HURT: 72
>
> The running time of shader-db itself on SKL seems to be increased by
> roughly 2.52%±1.13% with n=20 due to the additional work done by the
> compiler back-end.
>
> On earlier generations the pass is somewhat less effective in relative
> terms because the hardware incurs a bank conflict anytime the last two
> sources of the instruction are duplicate (e.g. while trying to square
> a value using MAD), which is impossible to avoid without introducing
> copies.  E.g. for a shader-db run on SNB:
>
>total conflicts in shared programs: 944636 -> 623185 (-34.03%)
>conflicts in affected programs: 853258 -> 531807 (-37.67%)
>helped: 31052
>HURT: 19
>
> And on BDW:
>
>total conflicts in shared programs: 1418393 -> 987539 (-30.38%)
>conflicts in affected programs: 1179787 -> 748933 (-36.52%)
>helped: 47592
>HURT: 70
>
> On SKL GT4e this improves performance of GpuTest Volplosion by 3.64%
> ±0.33% with n=16.
>
> NOTE: This patch intentionally disregards some i965 coding conventions
>   for the sake of reviewability.  This is addressed by the next
>   squash patch which introduces an amount of (for the most part
>   boring) boilerplate that might distract reviewers from the
>   non-trivial algorithmic details of the pass.
> ---
>  src/intel/Makefile.sources   |   1 +
>  src/intel/compiler/brw_fs.cpp|   2 +
>  src/intel/compiler/brw_fs.h  |   1 +
>  src/intel/compiler/brw_fs_bank_conflicts.cpp | 791 
> +++
>  4 files changed, 795 insertions(+)
>  create mode 100644 src/intel/compiler/brw_fs_bank_conflicts.cpp
>
> diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
> index a877ff2..1b9799a 100644
> --- a/src/intel/Makefile.sources
> +++ b/src/intel/Makefile.sources
> @@ -44,6 +44,7 @@ COMPILER_FILES = \
> compiler/brw_eu_util.c \
> compiler/brw_eu_validate.c \
> compiler/brw_fs_builder.h \
> +compiler/brw_fs_bank_conflicts.cpp \

Use tabs in Makefiles

> compiler/brw_fs_cmod_propagation.cpp \
> compiler/brw_fs_combine_constants.cpp \
> compiler/brw_fs_copy_propagation.cpp \
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 43b6e34..0a85c0c 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -5858,6 +5858,8 @@ fs_visitor::allocate_registers(bool allow_spilling)
> if (failed)
>return;
>
> +   opt_bank_conflicts();
> +
> schedule_instructions(SCHEDULE_POST);
>
> if (last_scratch > 0) {
> diff --git a/src/intel/compiler/brw_fs.h b/src/intel/compiler/brw_fs.h
> index 6c8c027..b1fc7b3 100644
> --- a/src/intel/compiler/brw_fs.h
> +++ b/src/intel/compiler/brw_fs.h
> @@ -141,6 +141,7 @@ public:
> exec_list *acp);
> bool opt_drop_redundant_mov_to_flags();
> bool opt_register_renaming();
> +   bool opt_bank_conflicts();
> bool register_coalesce();
> bool compute_to_mrf();
> bool eliminate_find_live_channel();
> diff --git a/src/intel/compiler/brw_fs_bank_conflicts.cpp 
> b/src/intel/compiler/brw_fs_bank_conflicts.cpp
> new file mode 100644
> index 000..0225c70
> --- /dev/null
> +++ b/src/intel/compiler/brw_fs_bank_conflicts.cpp
> @@ -0,0 +1,791 @@
> +/*
> + * Copyright © 2017 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 A

Re: [Mesa-dev] [PATCH] radeon/vce: move destroy command before feedback command

[Christian König]

Am 07.12.2017 um 18:37 schrieb Leo Liu:

VCE processing IBs starts from session and task info at first level,
other commands processed subsequently. The task info for destroy is
embedded to destroy command, resulting that feedback command is not
properly procoessed. This is causing kernel spin VM fault messages on
Polaris and Vega10 card when running ends at encode application.

The fix is also verified on VCE physical mode card.
  
Signed-off-by: Leo Liu 

Cc: mesa-sta...@lists.freedesktop.org


Acked-by: Christian König 


---
  src/gallium/drivers/radeon/radeon_vce.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 69e602210b..427bf01ed8 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -246,8 +246,8 @@ static void rvce_destroy(struct pipe_video_codec *encoder)
si_vid_create_buffer(enc->screen, &fb, 512, PIPE_USAGE_STAGING);
enc->fb = &fb;
enc->session(enc);
-   enc->feedback(enc);
enc->destroy(enc);
+   enc->feedback(enc);
flush(enc);
si_vid_destroy_buffer(&fb);
}


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

Re: [Mesa-dev] [PATCH] meson: Fix building gallium media targets with gallium-xlib glx

[Eric Engestrom]

On Thursday, 2017-12-07 09:57:19 -0800, Dylan Baker wrote:
> Quoting Eric Engestrom (2017-12-07 09:37:47)
> > On Thursday, 2017-12-07 09:16:24 -0800, Dylan Baker wrote:
> > > Quoting Eric Engestrom (2017-12-07 04:17:58)
> > > > On Tuesday, 2017-12-05 09:40:53 -0800, Dylan Baker wrote:
> > > > > Signed-off-by: Dylan Baker 
> > > > > ---
> > > > >  meson.build | 6 +++---
> > > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/meson.build b/meson.build
> > > > > index 3e8ea7d17e0..bf6bd551f08 100644
> > > > > --- a/meson.build
> > > > > +++ b/meson.build
> > > > > @@ -1107,9 +1107,9 @@ if with_platform_x11
> > > > >  dep_xcb_glx = dependency('xcb-glx', version : '>= 1.8.1')
> > > > >  dep_xxf86vm = dependency('xxf86vm', required : false)
> > > > >endif
> > > > > -  if with_any_vk or with_glx == 'dri' or
> > > > > -  (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx or
> > > > > -   with_gallium_xa)
> > > > > +  if (with_any_vk or with_glx == 'dri' or
> > > > > +   (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx 
> > > > > or
> > > > > +with_gallium_xa))
> > > > 
> > > > Hmm, works for me without this, on both meson 43 and 44; I'm guessing
> > > > meson 42 fails to parse this?
> > > > 
> > > > Either way, it doesn't hurt, so:
> > > > Reviewed-by: Eric Engestrom 
> > > > 
> > > > >  dep_xcb = dependency('xcb')
> > > > >  dep_x11_xcb = dependency('x11-xcb')
> > > > >endif
> > > > > -- 
> > > > > 2.15.0
> > > > > 
> > > 
> > > You need to run meson like this to exercise the bug (I'll add this to the 
> > > commit
> > > message):
> > > meson builddir -Dglx=gallium-xlib -Ddri-drivers= -Dvulkan-drivers=
> > > 
> > > The problem is that meson's parser just stops parsing the if statement as 
> > > soon
> > > as it decides that the expression so far is true and the next token is 
> > > 'or' and
> > > there is no way for the whole expression to be false even if the next sub
> > > expression is false. Basically laziness is biting us.
> > > 
> > > I started working on a linter yesterday but I'm doing it the hard way (aka
> > > writing my own parser).
> > 
> > I'm assuming going to route of adding an mlint.py in meson would allow
> > you to reuse a ton of code (esp. parsing)? I kinda like the idea of
> > simply typing `meson lint` to validate all the meson code.
> 
> The problem is that meson's parser is lazy and doesn't exhaust expressions, so
> it wouldn't have caught any of the issue's I would want a linter to catch 
> (like
> the glx=gallium-xlib bug). I also think having a second parser that is not
> recursive descent is useful in it's own right, in part since it proves the 
> claim
> that meson could be rewritten if needed.

Yup, makes sense to rewrite the parser then.

What about the suggestion of doing it as a meson module though, so that
the linter can be part of the project? Main benefits I'm seeing are that
it will always be up to date with meson features, and it will be
maintained by the community, which won't necessarily be you :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] intel/fs: Implement GRF bank conflict mitigation pass.

[Matt Turner]

On Wed, Dec 6, 2017 at 12:38 PM, Francisco Jerez  wrote:
> This series (which is ready for production and improves the cycle count
> of over 46k shaders) has been sitting here for nearly half a year.  I'm
> planning to self-review it and land it (along with PATCH 3/2 I just sent
> to make sure we keep regressions under control) if nobody else does in
> the next two weeks.

I'm really sorry I wasn't ever able to give this the proper review it
deserved. It's a really impressive piece of work.

You should feel free to commit it with my

Acked-by: Matt Turner 

Please do poke potential reviewers in the future if something of yours
is languishing on the mailing list. You shouldn't have to wait six
months for review.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Add lmsensors to gallium libgl-xlib target.

[Dylan Baker]

Quoting Eric Engestrom (2017-12-07 09:49:30)
> On Thursday, 2017-12-07 09:32:39 -0800, Dylan Baker wrote:
> > I don't suppose someone would like to ack this?
> > 
> > Quoting Dylan Baker (2017-12-04 14:05:12)
> > > Fixes: 5e71efef44b992b5d70b ("meson: Add lmsensors support")
> > > Signed-off-by: Dylan Baker 
> > > ---
> > >  src/gallium/targets/libgl-xlib/meson.build | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/src/gallium/targets/libgl-xlib/meson.build 
> > > b/src/gallium/targets/libgl-xlib/meson.build
> > > index 825b7b4a0f1..d0241a59ebe 100644
> > > --- a/src/gallium/targets/libgl-xlib/meson.build
> > > +++ b/src/gallium/targets/libgl-xlib/meson.build
> > > @@ -62,7 +62,7 @@ libgl = shared_library(
> > >  libxlib, libws_xlib, libsoftpipe, libtrace, librbug, libglapi_static,
> > >  libgallium, libmesa_util, libmesa_gallium, gallium_xlib_link_with,
> > >],
> > > -  dependencies : [dep_clock, dep_unwind, gallium_xlib_depends],
> > > +  dependencies : [dep_clock, dep_unwind, dep_lmsensors, 
> > > gallium_xlib_depends],
> 
> needed because `link_with: libgallium`
> 
> Reviewed-by: Eric Engestrom 
> 
> I'm not clear on `link_with:` though: shouldn't that track deps so that
> we don't need to do this manually?
> 
> > >install : true,
> > >version : '1.5.0',
> > >  )
> > > -- 
> > > 2.15.0
> > > 

It would if lmsensors was added to libgallium. Maybe it makes more sense to just
remove the dependencies from the targets that include libgallium and add it to
libgallium instead? Emil suggested that.


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

Re: [Mesa-dev] [PATCH] meson: Add lmsensors to gallium libgl-xlib target.

[Eric Engestrom]

On Thursday, 2017-12-07 10:16:01 -0800, Dylan Baker wrote:
> Quoting Eric Engestrom (2017-12-07 09:49:30)
> > On Thursday, 2017-12-07 09:32:39 -0800, Dylan Baker wrote:
> > > I don't suppose someone would like to ack this?
> > > 
> > > Quoting Dylan Baker (2017-12-04 14:05:12)
> > > > Fixes: 5e71efef44b992b5d70b ("meson: Add lmsensors support")
> > > > Signed-off-by: Dylan Baker 
> > > > ---
> > > >  src/gallium/targets/libgl-xlib/meson.build | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/src/gallium/targets/libgl-xlib/meson.build 
> > > > b/src/gallium/targets/libgl-xlib/meson.build
> > > > index 825b7b4a0f1..d0241a59ebe 100644
> > > > --- a/src/gallium/targets/libgl-xlib/meson.build
> > > > +++ b/src/gallium/targets/libgl-xlib/meson.build
> > > > @@ -62,7 +62,7 @@ libgl = shared_library(
> > > >  libxlib, libws_xlib, libsoftpipe, libtrace, librbug, 
> > > > libglapi_static,
> > > >  libgallium, libmesa_util, libmesa_gallium, gallium_xlib_link_with,
> > > >],
> > > > -  dependencies : [dep_clock, dep_unwind, gallium_xlib_depends],
> > > > +  dependencies : [dep_clock, dep_unwind, dep_lmsensors, 
> > > > gallium_xlib_depends],
> > 
> > needed because `link_with: libgallium`
> > 
> > Reviewed-by: Eric Engestrom 
> > 
> > I'm not clear on `link_with:` though: shouldn't that track deps so that
> > we don't need to do this manually?
> > 
> > > >install : true,
> > > >version : '1.5.0',
> > > >  )
> > > > -- 
> > > > 2.15.0
> > > > 
> 
> It would if lmsensors was added to libgallium. Maybe it makes more sense to 
> just
> remove the dependencies from the targets that include libgallium and add it to
> libgallium instead? Emil suggested that.

Yeah, I agree. I'd say land this for now, but you can do another patch
to remove all of them and add the dep once in libgallium.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Fix building gallium media targets with gallium-xlib glx

[Dylan Baker]

Quoting Eric Engestrom (2017-12-07 10:13:27)
> On Thursday, 2017-12-07 09:57:19 -0800, Dylan Baker wrote:
> > Quoting Eric Engestrom (2017-12-07 09:37:47)
> > > On Thursday, 2017-12-07 09:16:24 -0800, Dylan Baker wrote:
> > > > Quoting Eric Engestrom (2017-12-07 04:17:58)
> > > > > On Tuesday, 2017-12-05 09:40:53 -0800, Dylan Baker wrote:
> > > > > > Signed-off-by: Dylan Baker 
> > > > > > ---
> > > > > >  meson.build | 6 +++---
> > > > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > > 
> > > > > > diff --git a/meson.build b/meson.build
> > > > > > index 3e8ea7d17e0..bf6bd551f08 100644
> > > > > > --- a/meson.build
> > > > > > +++ b/meson.build
> > > > > > @@ -1107,9 +1107,9 @@ if with_platform_x11
> > > > > >  dep_xcb_glx = dependency('xcb-glx', version : '>= 1.8.1')
> > > > > >  dep_xxf86vm = dependency('xxf86vm', required : false)
> > > > > >endif
> > > > > > -  if with_any_vk or with_glx == 'dri' or
> > > > > > -  (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx 
> > > > > > or
> > > > > > -   with_gallium_xa)
> > > > > > +  if (with_any_vk or with_glx == 'dri' or
> > > > > > +   (with_gallium_vdpau or with_gallium_xvmc or 
> > > > > > with_gallium_omx or
> > > > > > +with_gallium_xa))
> > > > > 
> > > > > Hmm, works for me without this, on both meson 43 and 44; I'm guessing
> > > > > meson 42 fails to parse this?
> > > > > 
> > > > > Either way, it doesn't hurt, so:
> > > > > Reviewed-by: Eric Engestrom 
> > > > > 
> > > > > >  dep_xcb = dependency('xcb')
> > > > > >  dep_x11_xcb = dependency('x11-xcb')
> > > > > >endif
> > > > > > -- 
> > > > > > 2.15.0
> > > > > > 
> > > > 
> > > > You need to run meson like this to exercise the bug (I'll add this to 
> > > > the commit
> > > > message):
> > > > meson builddir -Dglx=gallium-xlib -Ddri-drivers= -Dvulkan-drivers=
> > > > 
> > > > The problem is that meson's parser just stops parsing the if statement 
> > > > as soon
> > > > as it decides that the expression so far is true and the next token is 
> > > > 'or' and
> > > > there is no way for the whole expression to be false even if the next 
> > > > sub
> > > > expression is false. Basically laziness is biting us.
> > > > 
> > > > I started working on a linter yesterday but I'm doing it the hard way 
> > > > (aka
> > > > writing my own parser).
> > > 
> > > I'm assuming going to route of adding an mlint.py in meson would allow
> > > you to reuse a ton of code (esp. parsing)? I kinda like the idea of
> > > simply typing `meson lint` to validate all the meson code.
> > 
> > The problem is that meson's parser is lazy and doesn't exhaust expressions, 
> > so
> > it wouldn't have caught any of the issue's I would want a linter to catch 
> > (like
> > the glx=gallium-xlib bug). I also think having a second parser that is not
> > recursive descent is useful in it's own right, in part since it proves the 
> > claim
> > that meson could be rewritten if needed.
> 
> Yup, makes sense to rewrite the parser then.
> 
> What about the suggestion of doing it as a meson module though, so that
> the linter can be part of the project? Main benefits I'm seeing are that
> it will always be up to date with meson features, and it will be
> maintained by the community, which won't necessarily be you :)

hmmm, I hadn't really thought about it. I guess I'll get it working and then see
if there's interest in merging it into the project. It doesn't really work at
the moment, so it's not useful for anything really :)


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

Re: [Mesa-dev] [PATCH] egl/android: Provide an option for the backend to expose KHR_image

[Emil Velikov]

Hi Harish,

On 7 December 2017 at 13:34, Harish Krupo  wrote:
> From android cts 8.0_r4, a new test case checks if all the required egl
> extensions are exposed. In the current implementation we expose KHR_image
> if KHR_image_base and KHR_image_pixmap are supported but KHR_image spec
> does not mandate the existence of both the extensions.
> This patch preserves the current check and also provides the backend
> with an option to expose the KHR_image extension.
>
> Test: run cts -m CtsOpenGLTestCases -t \
> android.opengl.cts.OpenGlEsVersionTest#testRequiredEglExtensions
>

A couple of things that come to mind. Hope that I'm not loosing my
marbles ... too badly.

The KHR_image_pixmap extension lists the following as dependency:

The EGL implementation must define an EGLNativePixmapType (although it
is not required either to export any EGLConfigs supporting rendering to
native pixmaps, or to support eglCreatePixmapSurface).

At the same time 'implementations' define the type even ones that lack
native pixmaps - Wayland, GBM, ...

(A) If one is to ignore that 'detail' we could simply toggle all of
KHR_image_pixmap across the board and simplify things a bit.
(B) if native pixmaps is a must - we have a bug in GBM as it
advertises KHR_image_pixmap.


> Signed-off-by: Harish Krupo 
> ---
>  src/egl/drivers/dri2/platform_android.c | 1 +
>  src/egl/main/eglapi.c   | 3 ++-
>  src/egl/main/egldisplay.h   | 1 +
>  3 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index 63223e9a69..0459cc8be2 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -1212,6 +1212,7 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay 
> *dpy)
>  #if ANDROID_API_LEVEL >= 23
> dpy->Extensions.KHR_partial_update = EGL_TRUE;
>  #endif
> +   dpy->Extensions.KHR_image = EGL_TRUE;

A: all of KHR_image* can will be a single boot
B: add _EGLDisplay::has_native_pixmap (or alike) and toggle KHR_image
and KHR_image_pixmap as applicable in egl_dri2.c
One can go without ::has_native_pixmap - we have platform type in
::Platform so we can deduce it locally.

Change the guards in _eglCreate/DestroyImageCommon as both KHR_image
and not KHR_image_base provide the entry points.
Personally I'd add an assert(...KHR_image) since it's close to
impossible to trigger.

>
> /* Fill vtbl last to prevent accidentally calling virtual function during
>  * initialization.
> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> index cec67425e1..5110688f2d 100644
> --- a/src/egl/main/eglapi.c
> +++ b/src/egl/main/eglapi.c
> @@ -504,7 +504,8 @@ _eglCreateExtensionsString(_EGLDisplay *dpy)
> _EGL_CHECK_EXTENSION(KHR_gl_texture_3D_image);
> _EGL_CHECK_EXTENSION(KHR_gl_texture_cubemap_image);
> if (dpy->Extensions.KHR_image_base && dpy->Extensions.KHR_image_pixmap)
> -  _eglAppendExtension(&exts, "EGL_KHR_image");
> +  dpy->Extensions.KHR_image = EGL_TRUE;
It's very misleading to set the extension bool in a function called
CreateExtensionString :-\

Depending on how A/B goes we can move that to dri2_setup_screen or the
specific platform*.c.

With the assert() (rest can be done as follow-up) the patch is
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH 1/9] i965/fs: Rewrite assign_constant_locations

[Jason Ekstrand]

On Thu, Dec 7, 2017 at 9:57 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Thu, Dec 07, 2017 at 09:25:08AM -0800, Jason Ekstrand wrote:
> > On Thu, Dec 7, 2017 at 9:10 AM, Pohjolainen, Topi <
> > topi.pohjolai...@gmail.com> wrote:
> >
> > > On Wed, Dec 06, 2017 at 08:34:19PM -0800, Jason Ekstrand wrote:
> > > > This rewires the logic for assigning uniform locations to work in
> terms
> > > > of "complex alignments".  The basic idea is that, as we walk the
> list of
> > > > instructions, we keep track of the alignment and continuity
> requirements
> > > > of each slot and assert that the alignments all match up.  We then
> use
> > > > those alignments in the compaction stage to ensure that everything
> gets
> > > > placed at a properly aligned register.  The old mechanism handled
> > > > alignments by special-casing each of the bit sizes and placing 64-bit
> > > > values first followed by 32-bit values.
> > > >
> > > > The old scheme had the advantage of never leaving a hole since all
> the
> > > > 64-bit values could be tightly packed and so could the 32-bit values.
> > > > However, the new scheme has no type size special cases so it handles
> not
> > > > only 32 and 64-bit types but should gracefully extend to 16 and 8-bit
> > > > types as the need arises.
> > > >
> > > > Tested-by: Jose Maria Casanova Crespo 
> > > > ---
> > > >  src/intel/compiler/brw_fs.cpp | 307 --
> > > 
> > > >  1 file changed, 174 insertions(+), 133 deletions(-)
> > > >
> > > > diff --git a/src/intel/compiler/brw_fs.cpp
> b/src/intel/compiler/brw_fs.
> > > cpp
> > > > index 93bb6b4..41260b4 100644
> > > > --- a/src/intel/compiler/brw_fs.cpp
> > > > +++ b/src/intel/compiler/brw_fs.cpp
> > > > @@ -1906,62 +1906,6 @@ fs_visitor::compact_virtual_grfs()
> > > > return progress;
> > > >  }
> > > >
> > > > -static void
> > > > -set_push_pull_constant_loc(unsigned uniform, int *chunk_start,
> > > > -   unsigned *max_chunk_bitsize,
> > > > -   bool contiguous, unsigned bitsize,
> > > > -   const unsigned target_bitsize,
> > > > -   int *push_constant_loc, int
> > > *pull_constant_loc,
> > > > -   unsigned *num_push_constants,
> > > > -   unsigned *num_pull_constants,
> > > > -   const unsigned max_push_components,
> > > > -   const unsigned max_chunk_size,
> > > > -   bool allow_pull_constants,
> > > > -   struct brw_stage_prog_data
> *stage_prog_data)
> > > > -{
> > > > -   /* This is the first live uniform in the chunk */
> > > > -   if (*chunk_start < 0)
> > > > -  *chunk_start = uniform;
> > > > -
> > > > -   /* Keep track of the maximum bit size access in contiguous
> uniforms
> > > */
> > > > -   *max_chunk_bitsize = MAX2(*max_chunk_bitsize, bitsize);
> > > > -
> > > > -   /* If this element does not need to be contiguous with the next,
> we
> > > > -* split at this point and everything between chunk_start and u
> > > forms a
> > > > -* single chunk.
> > > > -*/
> > > > -   if (!contiguous) {
> > > > -  /* If bitsize doesn't match the target one, skip it */
> > > > -  if (*max_chunk_bitsize != target_bitsize) {
> > > > - /* FIXME: right now we only support 32 and 64-bit accesses
> */
> > > > - assert(*max_chunk_bitsize == 4 || *max_chunk_bitsize == 8);
> > > > - *max_chunk_bitsize = 0;
> > > > - *chunk_start = -1;
> > > > - return;
> > > > -  }
> > > > -
> > > > -  unsigned chunk_size = uniform - *chunk_start + 1;
> > > > -
> > > > -  /* Decide whether we should push or pull this parameter.  In
> the
> > > > -   * Vulkan driver, push constants are explicitly exposed via
> the
> > > API
> > > > -   * so we push everything.  In GL, we only push small arrays.
> > > > -   */
> > > > -  if (!allow_pull_constants ||
> > > > -  (*num_push_constants + chunk_size <= max_push_components
> &&
> > > > -   chunk_size <= max_chunk_size)) {
> > > > - assert(*num_push_constants + chunk_size <=
> > > max_push_components);
> > > > - for (unsigned j = *chunk_start; j <= uniform; j++)
> > > > -push_constant_loc[j] = (*num_push_constants)++;
> > > > -  } else {
> > > > - for (unsigned j = *chunk_start; j <= uniform; j++)
> > > > -pull_constant_loc[j] = (*num_pull_constants)++;
> > > > -  }
> > > > -
> > > > -  *max_chunk_bitsize = 0;
> > > > -  *chunk_start = -1;
> > > > -   }
> > > > -}
> > > > -
> > > >  static int
> > > >  get_subgroup_id_param_index(const brw_stage_prog_data *prog_data)
> > > >  {
> > > > @@ -1977,6 +1921,98 @@ get_subgroup_id_param_index(const
> > > brw_stage_prog_data *prog_data)
> > > >  }
> > > >
> > > >  /**
> > > > + * Struct for handling complex alignments.
> > >

Re: [Mesa-dev] [PATCH 3/3] intel/cfg: Represent divergent control flow paths caused by non-uniform loop execution.

[Jason Ekstrand]

Ugh, I just remembered we still haven't landed anything for this...

On Fri, Oct 27, 2017 at 5:05 PM, Francisco Jerez 
wrote:

> This addresses a long-standing back-end compiler bug that could lead
> to cross-channel data corruption in loops executed non-uniformly.  In
> some cases live variables extending through a loop divergence point
> (e.g. a non-uniform break) into a convergence point (e.g. the end of
> the loop) wouldn't be considered live along all physical control flow
> paths the SIMD thread could possibly have taken in between due to some
> channels remaining in the loop for additional iterations.
>
> This patch fixes the problem by extending the CFG with physical edges
> that don't exist in the idealized non-vectorized program, but
> represent valid control flow paths the SIMD EU may take due to the
> divergence of logical threads.  This makes sense because the i965 IR
> is explicitly SIMD, and it's not uncommon for instructions to have an
> influence on neighboring channels (e.g. a force_writemask_all header
> setup), so the behavior of the SIMD thread as a whole needs to be
> considered.
>

I've read all three patches and are convinced that the first two are
correct and that this one does solve the problem.  That said, I'm still not
sure what I think of this approach.  It does solve the problem but it's
correctness relies on even more subtle interactions between the way we
build the CFG and liveness analysis than we had before.  I don't like
subtle interactions.  That said, I'm a bit on the fence as to how much
longer I want to go around in circles trying to fix this...


> No changes in shader-db.
> ---
>  src/intel/compiler/brw_cfg.cpp | 75 ++
> 
>  1 file changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/src/intel/compiler/brw_cfg.cpp b/src/intel/compiler/brw_cfg.c
> pp
> index fad12eec588..600b428a492 100644
> --- a/src/intel/compiler/brw_cfg.cpp
> +++ b/src/intel/compiler/brw_cfg.cpp
> @@ -98,6 +98,7 @@ ends_block(const backend_instruction *inst)
>op == BRW_OPCODE_ELSE ||
>op == BRW_OPCODE_CONTINUE ||
>op == BRW_OPCODE_BREAK ||
> +  op == BRW_OPCODE_DO ||
>op == BRW_OPCODE_WHILE;
>  }
>
> @@ -268,13 +269,57 @@ cfg_t::cfg_t(exec_list *instructions)
>   }
>
>   cur->instructions.push_tail(inst);
> +
> + /* Represent divergent execution of the loop as a pair of
> alternative
> +  * edges coming out of the DO instruction: For any physical
> iteration
> +  * of the loop a given logical thread can either start off
> enabled
> +  * (which is represented as the "next" successor), or disabled
> (if it
> +  * has reached a non-uniform exit of the loop during a previous
> +  * iteration, which is represented as the "cur_while" successor).
> +  *
> +  * The disabled edge will be taken by the logical thread anytime
> we
> +  * arrive at the DO instruction through a back-edge coming from a
> +  * conditional exit of the loop where divergent control flow
> started.
> +  *
> +  * This guarantees that there is a control-flow path from any
> +  * divergence point of the loop into the convergence point
> +  * (immediately past the WHILE instruction) such that it
> overlaps the
> +  * whole IP region of divergent control flow (potentially the
> whole
> +  * loop) *and* doesn't imply the execution of any instructions
> part
> +  * of the loop (since the corresponding execution mask bit will
> be
> +  * disabled for a diverging thread).
> +  *
> +  * This way we make sure that any variables that are live
> throughout
> +  * the region of divergence for an inactive logical thread are
> also
> +  * considered to interfere with any other variables assigned by
> +  * active logical threads within the same physical region of the
> +  * program, since otherwise we would risk cross-channel data
> +  * corruption.
> +  */
> + next = new_block();
> + cur->add_successor(mem_ctx, next);
> + cur->add_successor(mem_ctx, cur_while);
> + set_next_block(&cur, next, ip);
>  break;
>
>case BRW_OPCODE_CONTINUE:
>   cur->instructions.push_tail(inst);
>
> + /* A conditional CONTINUE may start a region of divergent control
> +  * flow until the start of the next loop iteration (*not* until
> the
> +  * end of the loop which is why the successor is not the
> top-level
> +  * divergence point at cur_do).  The live interval of any
> variable
> +  * extending through a CONTINUE edge is guaranteed to overlap the
> +  * whole region of divergent execution, because any variable
> live-out
> +  * at the CONTINUE instruction will also be live-in at the top
> of the
> +  * loop, and therefore also li

Re: [Mesa-dev] [PATCH v3] mesa/spirv: move and rename nir_spirv_supported_capabilities

[Pierre Moreau]

Thank you for the changes!

Reviewed-by: Pierre Moreau 

On 2017-12-07 — 17:12, Alejandro Piñeiro wrote:
> To avoid any vulkan driver to include the GL mtypes.h. Renamed as
> eventually this could be used by drivers not using nir.
> 
> v2: remove compiler/spirv/spirv.h from mtypes (Alejandro)
> v3: added the definition at compiler/shader_info.h (Jason Ekstrand)
> ---
> 
> Sorry for not realizing that spirv.h was a generated file. I also
> preferred to add it to shader_info.h. Both options 2 and 3 seemed
> somewhat an overkill
> 
>  src/compiler/shader_info.h | 13 +
>  src/compiler/spirv/nir_spirv.h |  4 ++--
>  src/mesa/main/mtypes.h | 13 -
>  3 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
> index bcb3f0fffac..c9140ba9752 100644
> --- a/src/compiler/shader_info.h
> +++ b/src/compiler/shader_info.h
> @@ -31,6 +31,19 @@
>  extern "C" {
>  #endif
>  
> +struct spirv_supported_capabilities {
> +   bool float64;
> +   bool image_ms_array;
> +   bool tessellation;
> +   bool draw_parameters;
> +   bool image_read_without_format;
> +   bool image_write_without_format;
> +   bool int64;
> +   bool multiview;
> +   bool variable_pointers;
> +   bool storage_16bit;
> +};
> +
>  typedef struct shader_info {
> const char *name;
>  
> diff --git a/src/compiler/spirv/nir_spirv.h b/src/compiler/spirv/nir_spirv.h
> index 113bd710a00..a2c40e57d18 100644
> --- a/src/compiler/spirv/nir_spirv.h
> +++ b/src/compiler/spirv/nir_spirv.h
> @@ -29,7 +29,7 @@
>  #define _NIR_SPIRV_H_
>  
>  #include "compiler/nir/nir.h"
> -#include "main/mtypes.h"
> +#include "compiler/shader_info.h"
>  
>  #ifdef __cplusplus
>  extern "C" {
> @@ -58,7 +58,7 @@ struct spirv_to_nir_options {
>  */
> bool lower_workgroup_access_to_offsets;
>  
> -   struct nir_spirv_supported_capabilities caps;
> +   struct spirv_supported_capabilities caps;
>  
> struct {
>void (*func)(void *private_data,
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 7b7137624c7..397b113dfbc 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3578,19 +3578,6 @@ struct gl_program_constants
> GLuint MaxShaderStorageBlocks;
>  };
>  
> -struct nir_spirv_supported_capabilities {
> -   bool float64;
> -   bool image_ms_array;
> -   bool tessellation;
> -   bool draw_parameters;
> -   bool image_read_without_format;
> -   bool image_write_without_format;
> -   bool int64;
> -   bool multiview;
> -   bool variable_pointers;
> -   bool storage_16bit;
> -};
> -
>  /**
>   * Constants which may be overridden by device driver during context creation
>   * but are never changed after that.
> -- 
> 2.11.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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] [Mesa-stable] [PATCH v3 14/48] i965/fs: Extend the live ranges of VGRFs which leave loops

[Jason Ekstrand]

On Fri, Oct 27, 2017 at 5:24 PM, Francisco Jerez 
wrote:

> I've submitted an alternative to this approach here [1], more along the
> lines of the v1 patch you borrowed from my jenkins branch.  Most of the
> reasons for that we have discussed already in the office (except for the
> last point), but FTR:
>
>  - This patch only works around the problem by tweaking the live
>intervals, which makes the live intervals inconsistent with the block
>live sets (the latter are used by some back-end passes that this
>patch isn't going to help with, like DCE and scheduling).
>

I'm not sure that's strictly true.  It changes the mapping function from
the live sets to the liveness intervals but it's still directly computable
from live sets + cfg.  That said, there is something to be said for
treating back-edges specially when computing the live sets.


>  - This patch doesn't fix the same bug on the VEC4 back-end.
>
>  - I feel that the alternative approach [1] admits more straightforward
>extension to more exotic control-flow constructs.
>
>  - It doesn't actually fix the problem for all possible patterns of
>divergent loop execution.  Consider the following GLSL pseudocode:
>
>| b = 0;
>| do {
>|use(b);
>|b = non_uniform_condition();
>|if (b)
>|   continue;
>|
>|stomp_neighboring_channels();
>|break;
>|
>| } while(true);
>
>With this series applied, the live interval of 'b' will be calculated
>to be between the 'b = 0' and 'continue' statements, which allows
>stomp_neighboring_channels() to overwrite the contents of 'b'
>depending on how the register allocator lays things out in the
>register file.  OTOH with [1] applied the live interval calculated
>for 'b' will be the region between the 'b = 0' and 'break'
>statements, which overlaps the whole region of divergent control flow
>as expected.
>

It does handle that case correctly before your patch to add defin/out but
not after. :-)  This is because we always propagate livein from the top of
the loop into the liveout of the while so anything livein at the top
automatically gets extended down.  We do not, however, propagate defout
that way (since the while is not reachable) so your patch breaks it.


> Cheers.
>
> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-
> October/174591.html
>
> Jason Ekstrand  writes:
>
> > No Shader-db changes.
> >
> > Cc: mesa-sta...@lists.freedesktop.org
> > ---
> >  src/intel/compiler/brw_fs_live_variables.cpp | 55
> 
> >  1 file changed, 55 insertions(+)
> >
> > diff --git a/src/intel/compiler/brw_fs_live_variables.cpp
> b/src/intel/compiler/brw_fs_live_variables.cpp
> > index c449672..380060d 100644
> > --- a/src/intel/compiler/brw_fs_live_variables.cpp
> > +++ b/src/intel/compiler/brw_fs_live_variables.cpp
> > @@ -223,6 +223,61 @@ fs_live_variables::compute_start_end()
> >   }
> >}
> > }
> > +
> > +   /* Due to the explicit way the SIMD data is handled on GEN, we need
> to be a
> > +* bit more careful with live ranges and loops.  Consider the
> following
> > +* example:
> > +*
> > +*vec4 color2;
> > +*while (1) {
> > +*   vec4 color = texture();
> > +*   if (...) {
> > +*  color2 = color * 2;
> > +*  break;
> > +*   }
> > +*}
> > +*gl_FragColor = color2;
> > +*
> > +* In this case, the definition of color2 dominates the use because
> the
> > +* loop only has the one exit.  This means that the live range
> interval for
> > +* color2 goes from the statement in the if to it's use below the
> loop.
> > +* Now suppose that the texture operation has a header register that
> gets
> > +* assigned one of the registers used for color2.  If the loop
> condition is
> > +* non-uniform and some of the threads will take the and others will
> > +* continue.  In this case, the next pass through the loop, the
> WE_all
> > +* setup of the header register will stomp the disabled channels of
> color2
> > +* and corrupt the value.
> > +*
> > +* This same problem can occur if you have a mix of 64, 32, and
> 16-bit
> > +* registers because the channels do not line up or if you have a
> SIMD16
> > +* program and the first half of one value overlaps the second half
> of the
> > +* other.
> > +*
> > +* To solve this problem, we take any VGRFs whose live ranges cross
> the
> > +* while instruction of a loop and extend their live ranges to the
> top of
> > +* the loop.  This more accurately models the hardware because the
> value in
> > +* the VGRF needs to be carried through subsequent loop iterations
> in order
> > +* to remain valid when we finally do break.
> > +*/
> > +   foreach_block (block, cfg) {
> > +  if (block->end()->opcode != BRW_OPCODE_WHILE)
> > + continue;
> > +
> > +  /* This is a 

Re: [Mesa-dev] [PATCH 3/3] intel/cfg: Represent divergent control flow paths caused by non-uniform loop execution.

[Jason Ekstrand]

On December 7, 2017 11:23:09 Jason Ekstrand  wrote:


Ugh, I just remembered we still haven't landed anything for this...

On Fri, Oct 27, 2017 at 5:05 PM, Francisco Jerez 
wrote:


This addresses a long-standing back-end compiler bug that could lead
to cross-channel data corruption in loops executed non-uniformly.  In
some cases live variables extending through a loop divergence point
(e.g. a non-uniform break) into a convergence point (e.g. the end of
the loop) wouldn't be considered live along all physical control flow
paths the SIMD thread could possibly have taken in between due to some
channels remaining in the loop for additional iterations.

This patch fixes the problem by extending the CFG with physical edges
that don't exist in the idealized non-vectorized program, but
represent valid control flow paths the SIMD EU may take due to the
divergence of logical threads.  This makes sense because the i965 IR
is explicitly SIMD, and it's not uncommon for instructions to have an
influence on neighboring channels (e.g. a force_writemask_all header
setup), so the behavior of the SIMD thread as a whole needs to be
considered.



I've read all three patches and are convinced that the first two are
correct and that this one does solve the problem.  That said, I'm still not
sure what I think of this approach.  It does solve the problem but it's
correctness relies on even more subtle interactions between the way we
build the CFG and liveness analysis than we had before.  I don't like
subtle interactions.  That said, I'm a bit on the fence as to how much
longer I want to go around in circles trying to fix this...


After some time on a whiteboard, I've come to the conclusion that this is a 
reasonable mental model.  In particular it has two nice properties:


1) Every instruction in the loop is reachable from every other instruction 
in the loop.


2) Once you enter the loop, you cannot leave without going through a BREAK.

Reviewed-by: Jason Ekstrand 


No changes in shader-db.
---
 src/intel/compiler/brw_cfg.cpp | 75 ++

 1 file changed, 69 insertions(+), 6 deletions(-)

diff --git a/src/intel/compiler/brw_cfg.cpp b/src/intel/compiler/brw_cfg.c
pp
index fad12eec588..600b428a492 100644
--- a/src/intel/compiler/brw_cfg.cpp
+++ b/src/intel/compiler/brw_cfg.cpp
@@ -98,6 +98,7 @@ ends_block(const backend_instruction *inst)
   op == BRW_OPCODE_ELSE ||
   op == BRW_OPCODE_CONTINUE ||
   op == BRW_OPCODE_BREAK ||
+  op == BRW_OPCODE_DO ||
   op == BRW_OPCODE_WHILE;
 }

@@ -268,13 +269,57 @@ cfg_t::cfg_t(exec_list *instructions)
  }

  cur->instructions.push_tail(inst);
+
+ /* Represent divergent execution of the loop as a pair of
alternative
+  * edges coming out of the DO instruction: For any physical
iteration
+  * of the loop a given logical thread can either start off
enabled
+  * (which is represented as the "next" successor), or disabled
(if it
+  * has reached a non-uniform exit of the loop during a previous
+  * iteration, which is represented as the "cur_while" successor).
+  *
+  * The disabled edge will be taken by the logical thread anytime
we
+  * arrive at the DO instruction through a back-edge coming from a
+  * conditional exit of the loop where divergent control flow
started.
+  *
+  * This guarantees that there is a control-flow path from any
+  * divergence point of the loop into the convergence point
+  * (immediately past the WHILE instruction) such that it
overlaps the
+  * whole IP region of divergent control flow (potentially the
whole
+  * loop) *and* doesn't imply the execution of any instructions
part
+  * of the loop (since the corresponding execution mask bit will
be
+  * disabled for a diverging thread).
+  *
+  * This way we make sure that any variables that are live
throughout
+  * the region of divergence for an inactive logical thread are
also
+  * considered to interfere with any other variables assigned by
+  * active logical threads within the same physical region of the
+  * program, since otherwise we would risk cross-channel data
+  * corruption.
+  */
+ next = new_block();
+ cur->add_successor(mem_ctx, next);
+ cur->add_successor(mem_ctx, cur_while);
+ set_next_block(&cur, next, ip);
 break;

   case BRW_OPCODE_CONTINUE:
  cur->instructions.push_tail(inst);

+ /* A conditional CONTINUE may start a region of divergent control
+  * flow until the start of the next loop iteration (*not* until
the
+  * end of the loop which is why the successor is not the
top-level
+  * divergence point at cur_do).  The live interval of any
variable
+  * extending through a CONTINUE edge is guaranteed to over

[Mesa-dev] [Bug 104166] swr: Scons build - Add support for AVX512

[bugzilla-daemon]

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

Bug ID: 104166
   Summary: swr: Scons build - Add support for AVX512
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: liviupro...@yahoo.com
QA Contact: mesa-dev@lists.freedesktop.org

I got a request to make swr AVX512 builds on Windows:
https://github.com/pal1000/mesa-dist-win/issues/2

After digging into this enough I think it is very hard (cross compilation mess
with autotools) or outright unsupported at the moment.

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

[Mesa-dev] [Bug 104166] swr: Scons build - Add support for AVX512 configuration

[bugzilla-daemon]

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

Alex Granni  changed:

   What|Removed |Added

Summary|swr: Scons build - Add  |swr: Scons build - Add
   |support for AVX512  |support for AVX512
   ||configuration

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

[Mesa-dev] [Bug 100708] Trine 2 doesn't start on radeonsi on mesa 17

[bugzilla-daemon]

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

Alexander Tsoy  changed:

   What|Removed |Added

 CC||alexan...@tsoy.me

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

[Mesa-dev] [PATCH 1/2] gallium/aux: include nr_samples in util_resource_size() computation

[Brian Paul]

This function is only used in two places:
1. VMware driver, but only for HUD reporting
2. st/nine state tracker, used for texture memory accounting
---
 src/gallium/auxiliary/util/u_resource.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/util/u_resource.c 
b/src/gallium/auxiliary/util/u_resource.c
index 66caaae..ed6c150 100644
--- a/src/gallium/auxiliary/util/u_resource.c
+++ b/src/gallium/auxiliary/util/u_resource.c
@@ -42,6 +42,7 @@ util_resource_size(const struct pipe_resource *res)
unsigned depth = res->depth0;
unsigned size = 0;
unsigned level;
+   unsigned samples = MAX2(1, res->nr_samples);
 
for (level = 0; level <= res->last_level; level++) {
   unsigned slices;
@@ -54,7 +55,7 @@ util_resource_size(const struct pipe_resource *res)
  slices = res->array_size;
 
   size += (util_format_get_nblocksy(res->format, height) *
-   util_format_get_stride(res->format, width) * slices);
+   util_format_get_stride(res->format, width) * slices * samples);
 
   width  = u_minify(width, 1);
   height = u_minify(height, 1);
-- 
1.9.1

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

[Mesa-dev] [PATCH 2/2] gallium/util: don't pass a pipe_resource to util_resource_is_array_texture()

[Brian Paul]

No need to pass a pipe_resource when we can just pass the target.
This makes the function potentially more usable.  Rename it too.
---
 src/gallium/auxiliary/util/u_resource.h   | 6 +++---
 src/gallium/drivers/radeon/r600_texture.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_resource.h 
b/src/gallium/auxiliary/util/u_resource.h
index 6736476..3c6194b 100644
--- a/src/gallium/auxiliary/util/u_resource.h
+++ b/src/gallium/auxiliary/util/u_resource.h
@@ -32,14 +32,14 @@ unsigned
 util_resource_size(const struct pipe_resource *res);
 
 /**
- * Return true if the resource is an array texture.
+ * Return true if the texture target is an array type.
  *
  * Note that this function returns true for single-layered array textures.
  */
 static inline boolean
-util_resource_is_array_texture(const struct pipe_resource *res)
+util_texture_is_array(enum pipe_texture_target target)
 {
-   switch (res->target) {
+   switch (target) {
case PIPE_TEXTURE_1D_ARRAY:
case PIPE_TEXTURE_2D_ARRAY:
case PIPE_TEXTURE_CUBE_ARRAY:
diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index cb69398..66d4f02 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -582,7 +582,7 @@ static void si_query_opaque_metadata(struct si_screen 
*sscreen,
PIPE_SWIZZLE_W
};
uint32_t desc[8], i;
-   bool is_array = util_resource_is_array_texture(res);
+   bool is_array = util_texture_is_array(res->target);
 
/* DRM 2.x.x doesn't support this. */
if (sscreen->info.drm_major != 3)
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH 3/8] spirv: Add basic type validation for OpLoad, OpStore, and OpCopyMemory

[Jason Ekstrand]

On Thu, Dec 7, 2017 at 11:54 AM, Michael Schellenberger Costa <
mschellenbergerco...@googlemail.com> wrote:

> Hi Jason,
>
>
> Am 07.12.2017 um 17:12 schrieb Jason Ekstrand:
>
>> ---
>>   src/compiler/spirv/vtn_variables.c | 18 ++
>>   1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/compiler/spirv/vtn_variables.c
>> b/src/compiler/spirv/vtn_variables.c
>> index cf44ed3..8ce19ff 100644
>> --- a/src/compiler/spirv/vtn_variables.c
>> +++ b/src/compiler/spirv/vtn_variables.c
>> @@ -1969,6 +1969,9 @@ vtn_handle_variables(struct vtn_builder *b, SpvOp
>> opcode,
>> struct vtn_value *dest = vtn_value(b, w[1],
>> vtn_value_type_pointer);
>> struct vtn_value *src = vtn_value(b, w[2],
>> vtn_value_type_pointer);
>>   +  vtn_fail_if(dest->type->deref != src->type->deref,
>> +  "Result and pointer types of OpLoad do not match");
>>
> This should be OpCopyMemory?


Oops.  Fixed locally.


> On a more general side: As you want to cover every OpCode, why not
> overload vtn_fail_if() so that it takes the OpCode and then prepends it to
> the error message, e.g.:
>
> vtn_fail_if(dest->type->deref != src->type->deref, opcode,"Result and
> pointer types of do not match");
>
> Would extend to
>
> "OpCodeMemory: Result and pointer types of do not match"
>
> That way there is no chance to really mess op the opcodes.
>

I'm not sure what I think about that.  There may be cases where we want to
use vtn_fail_if where we don't have ready access to the opcode.  One option
would be to use spirv_opcode_to_string instead of putting it in the string
but it may be hard to make that happen in such a way that we only call that
function if the vtn_fail condition is true.


> All the best
> Michael
>
>
> +
>> vtn_variable_copy(b, dest->pointer, src->pointer);
>> break;
>>  }
>> @@ -1976,8 +1979,11 @@ vtn_handle_variables(struct vtn_builder *b, SpvOp
>> opcode,
>>  case SpvOpLoad: {
>> struct vtn_type *res_type =
>>vtn_value(b, w[1], vtn_value_type_type)->type;
>> -  struct vtn_pointer *src =
>> - vtn_value(b, w[3], vtn_value_type_pointer)->pointer;
>> +  struct vtn_value *src_val = vtn_value(b, w[3],
>> vtn_value_type_pointer);
>> +  struct vtn_pointer *src = src_val->pointer;
>> +
>> +  vtn_fail_if(res_type != src_val->type->deref,
>> +  "Result and pointer types of OpLoad do not match");
>>   if (src->mode == vtn_variable_mode_image ||
>> src->mode == vtn_variable_mode_sampler) {
>> @@ -1990,8 +1996,12 @@ vtn_handle_variables(struct vtn_builder *b, SpvOp
>> opcode,
>>  }
>>case SpvOpStore: {
>> -  struct vtn_pointer *dest =
>> - vtn_value(b, w[1], vtn_value_type_pointer)->pointer;
>> +  struct vtn_value *dest_val = vtn_value(b, w[1],
>> vtn_value_type_pointer);
>> +  struct vtn_pointer *dest = dest_val->pointer;
>> +  struct vtn_value *src_val = vtn_untyped_value(b, w[2]);
>> +
>> +  vtn_fail_if(dest_val->type->deref != src_val->type,
>> +  "Value and pointer types of OpStore do not match");
>>   if (glsl_type_is_sampler(dest->type->type)) {
>>vtn_warn("OpStore of a sampler detected.  Doing on-the-fly
>> copy "
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH v3 14/48] i965/fs: Extend the live ranges of VGRFs which leave loops

[Francisco Jerez]

Jason Ekstrand  writes:

> On Fri, Oct 27, 2017 at 5:24 PM, Francisco Jerez 
> wrote:
>
>> I've submitted an alternative to this approach here [1], more along the
>> lines of the v1 patch you borrowed from my jenkins branch.  Most of the
>> reasons for that we have discussed already in the office (except for the
>> last point), but FTR:
>>
>>  - This patch only works around the problem by tweaking the live
>>intervals, which makes the live intervals inconsistent with the block
>>live sets (the latter are used by some back-end passes that this
>>patch isn't going to help with, like DCE and scheduling).
>>
>
> I'm not sure that's strictly true.  It changes the mapping function from
> the live sets to the liveness intervals but it's still directly computable
> from live sets + cfg.  That said, there is something to be said for
> treating back-edges specially when computing the live sets.
>

The thing is a number of back-end passes derive their liveness
information based on the live sets rather than the live intervals.  Take
the scheduler as an example -- After this change variables whose live
range exits a loop increase the register pressure at the beginning of
the loop, but the scheduler won't know because it obtains that
information out of the live sets, so its register pressure decisions
become inaccurate with this patch (unless a similar hack is implemented
as we have right now in the scheduler to extend live sets for variables
whose live range crosses through an else block).

>
>>  - This patch doesn't fix the same bug on the VEC4 back-end.
>>
>>  - I feel that the alternative approach [1] admits more straightforward
>>extension to more exotic control-flow constructs.
>>
>>  - It doesn't actually fix the problem for all possible patterns of
>>divergent loop execution.  Consider the following GLSL pseudocode:
>>
>>| b = 0;
>>| do {
>>|use(b);
>>|b = non_uniform_condition();
>>|if (b)
>>|   continue;
>>|
>>|stomp_neighboring_channels();
>>|break;
>>|
>>| } while(true);
>>
>>With this series applied, the live interval of 'b' will be calculated
>>to be between the 'b = 0' and 'continue' statements, which allows
>>stomp_neighboring_channels() to overwrite the contents of 'b'
>>depending on how the register allocator lays things out in the
>>register file.  OTOH with [1] applied the live interval calculated
>>for 'b' will be the region between the 'b = 0' and 'break'
>>statements, which overlaps the whole region of divergent control flow
>>as expected.
>>
>
> It does handle that case correctly before your patch to add defin/out but
> not after. :-)  This is because we always propagate livein from the top of
> the loop into the liveout of the while so anything livein at the top
> automatically gets extended down.  We do not, however, propagate defout
> that way (since the while is not reachable) so your patch breaks it.
>

Probably, but the main use of this patch is fixing a bug that comes out
to surface as a side effect of my PATCH 15 of this series, so it better
work correctly in combination with the patch it's preparing the compiler
for ;)

>
>> Cheers.
>>
>> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-
>> October/174591.html
>>
>> Jason Ekstrand  writes:
>>
>> > No Shader-db changes.
>> >
>> > Cc: mesa-sta...@lists.freedesktop.org
>> > ---
>> >  src/intel/compiler/brw_fs_live_variables.cpp | 55
>> 
>> >  1 file changed, 55 insertions(+)
>> >
>> > diff --git a/src/intel/compiler/brw_fs_live_variables.cpp
>> b/src/intel/compiler/brw_fs_live_variables.cpp
>> > index c449672..380060d 100644
>> > --- a/src/intel/compiler/brw_fs_live_variables.cpp
>> > +++ b/src/intel/compiler/brw_fs_live_variables.cpp
>> > @@ -223,6 +223,61 @@ fs_live_variables::compute_start_end()
>> >   }
>> >}
>> > }
>> > +
>> > +   /* Due to the explicit way the SIMD data is handled on GEN, we need
>> to be a
>> > +* bit more careful with live ranges and loops.  Consider the
>> following
>> > +* example:
>> > +*
>> > +*vec4 color2;
>> > +*while (1) {
>> > +*   vec4 color = texture();
>> > +*   if (...) {
>> > +*  color2 = color * 2;
>> > +*  break;
>> > +*   }
>> > +*}
>> > +*gl_FragColor = color2;
>> > +*
>> > +* In this case, the definition of color2 dominates the use because
>> the
>> > +* loop only has the one exit.  This means that the live range
>> interval for
>> > +* color2 goes from the statement in the if to it's use below the
>> loop.
>> > +* Now suppose that the texture operation has a header register that
>> gets
>> > +* assigned one of the registers used for color2.  If the loop
>> condition is
>> > +* non-uniform and some of the threads will take the and others will
>> > +* continue.  In this case, the next pass through the loo

Re: [Mesa-dev] [Mesa-stable] [PATCH v3 14/48] i965/fs: Extend the live ranges of VGRFs which leave loops

[Connor Abbott]

On Thu, Dec 7, 2017 at 5:30 PM, Francisco Jerez  wrote:
> Jason Ekstrand  writes:
>
>> On Fri, Oct 27, 2017 at 5:24 PM, Francisco Jerez 
>> wrote:
>>
>>> I've submitted an alternative to this approach here [1], more along the
>>> lines of the v1 patch you borrowed from my jenkins branch.  Most of the
>>> reasons for that we have discussed already in the office (except for the
>>> last point), but FTR:
>>>
>>>  - This patch only works around the problem by tweaking the live
>>>intervals, which makes the live intervals inconsistent with the block
>>>live sets (the latter are used by some back-end passes that this
>>>patch isn't going to help with, like DCE and scheduling).
>>>
>>
>> I'm not sure that's strictly true.  It changes the mapping function from
>> the live sets to the liveness intervals but it's still directly computable
>> from live sets + cfg.  That said, there is something to be said for
>> treating back-edges specially when computing the live sets.
>>
>
> The thing is a number of back-end passes derive their liveness
> information based on the live sets rather than the live intervals.  Take
> the scheduler as an example -- After this change variables whose live
> range exits a loop increase the register pressure at the beginning of
> the loop, but the scheduler won't know because it obtains that
> information out of the live sets, so its register pressure decisions
> become inaccurate with this patch (unless a similar hack is implemented
> as we have right now in the scheduler to extend live sets for variables
> whose live range crosses through an else block).

Actually, this isn't true -- I made the scheduler "fill in" its
liveness sets to match the liveness intervals used by the register
allocator, i.e. it already does your "hack":

https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/compiler/brw_schedule_instructions.cpp#n646

If it didn't do that, its results would be inaccurate, which would
defeat the purpose of tracking register pressure in the first place.
Not that it matters much now, though, since my patches to do limit
scheduling never got merged.

>
>>
>>>  - This patch doesn't fix the same bug on the VEC4 back-end.
>>>
>>>  - I feel that the alternative approach [1] admits more straightforward
>>>extension to more exotic control-flow constructs.
>>>
>>>  - It doesn't actually fix the problem for all possible patterns of
>>>divergent loop execution.  Consider the following GLSL pseudocode:
>>>
>>>| b = 0;
>>>| do {
>>>|use(b);
>>>|b = non_uniform_condition();
>>>|if (b)
>>>|   continue;
>>>|
>>>|stomp_neighboring_channels();
>>>|break;
>>>|
>>>| } while(true);
>>>
>>>With this series applied, the live interval of 'b' will be calculated
>>>to be between the 'b = 0' and 'continue' statements, which allows
>>>stomp_neighboring_channels() to overwrite the contents of 'b'
>>>depending on how the register allocator lays things out in the
>>>register file.  OTOH with [1] applied the live interval calculated
>>>for 'b' will be the region between the 'b = 0' and 'break'
>>>statements, which overlaps the whole region of divergent control flow
>>>as expected.
>>>
>>
>> It does handle that case correctly before your patch to add defin/out but
>> not after. :-)  This is because we always propagate livein from the top of
>> the loop into the liveout of the while so anything livein at the top
>> automatically gets extended down.  We do not, however, propagate defout
>> that way (since the while is not reachable) so your patch breaks it.
>>
>
> Probably, but the main use of this patch is fixing a bug that comes out
> to surface as a side effect of my PATCH 15 of this series, so it better
> work correctly in combination with the patch it's preparing the compiler
> for ;)
>
>>
>>> Cheers.
>>>
>>> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-
>>> October/174591.html
>>>
>>> Jason Ekstrand  writes:
>>>
>>> > No Shader-db changes.
>>> >
>>> > Cc: mesa-sta...@lists.freedesktop.org
>>> > ---
>>> >  src/intel/compiler/brw_fs_live_variables.cpp | 55
>>> 
>>> >  1 file changed, 55 insertions(+)
>>> >
>>> > diff --git a/src/intel/compiler/brw_fs_live_variables.cpp
>>> b/src/intel/compiler/brw_fs_live_variables.cpp
>>> > index c449672..380060d 100644
>>> > --- a/src/intel/compiler/brw_fs_live_variables.cpp
>>> > +++ b/src/intel/compiler/brw_fs_live_variables.cpp
>>> > @@ -223,6 +223,61 @@ fs_live_variables::compute_start_end()
>>> >   }
>>> >}
>>> > }
>>> > +
>>> > +   /* Due to the explicit way the SIMD data is handled on GEN, we need
>>> to be a
>>> > +* bit more careful with live ranges and loops.  Consider the
>>> following
>>> > +* example:
>>> > +*
>>> > +*vec4 color2;
>>> > +*while (1) {
>>> > +*   vec4 color = texture();
>>> > +*   if (...) {
>>> > +*  color2 = color * 

Re: [Mesa-dev] [PATCH 2/2] gallium/util: don't pass a pipe_resource to util_resource_is_array_texture()

[Roland Scheidegger]

For the series:
Reviewed-by: Roland Scheidegger 

Am 07.12.2017 um 23:25 schrieb Brian Paul:
> No need to pass a pipe_resource when we can just pass the target.
> This makes the function potentially more usable.  Rename it too.
> ---
>  src/gallium/auxiliary/util/u_resource.h   | 6 +++---
>  src/gallium/drivers/radeon/r600_texture.c | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/util/u_resource.h 
> b/src/gallium/auxiliary/util/u_resource.h
> index 6736476..3c6194b 100644
> --- a/src/gallium/auxiliary/util/u_resource.h
> +++ b/src/gallium/auxiliary/util/u_resource.h
> @@ -32,14 +32,14 @@ unsigned
>  util_resource_size(const struct pipe_resource *res);
>  
>  /**
> - * Return true if the resource is an array texture.
> + * Return true if the texture target is an array type.
>   *
>   * Note that this function returns true for single-layered array textures.
>   */
>  static inline boolean
> -util_resource_is_array_texture(const struct pipe_resource *res)
> +util_texture_is_array(enum pipe_texture_target target)
>  {
> -   switch (res->target) {
> +   switch (target) {
> case PIPE_TEXTURE_1D_ARRAY:
> case PIPE_TEXTURE_2D_ARRAY:
> case PIPE_TEXTURE_CUBE_ARRAY:
> diff --git a/src/gallium/drivers/radeon/r600_texture.c 
> b/src/gallium/drivers/radeon/r600_texture.c
> index cb69398..66d4f02 100644
> --- a/src/gallium/drivers/radeon/r600_texture.c
> +++ b/src/gallium/drivers/radeon/r600_texture.c
> @@ -582,7 +582,7 @@ static void si_query_opaque_metadata(struct si_screen 
> *sscreen,
>   PIPE_SWIZZLE_W
>   };
>   uint32_t desc[8], i;
> - bool is_array = util_resource_is_array_texture(res);
> + bool is_array = util_texture_is_array(res->target);
>  
>   /* DRM 2.x.x doesn't support this. */
>   if (sscreen->info.drm_major != 3)
> 

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

Re: [Mesa-dev] [Mesa-stable] [PATCH v3 14/48] i965/fs: Extend the live ranges of VGRFs which leave loops

[Francisco Jerez]

Connor Abbott  writes:

> On Thu, Dec 7, 2017 at 5:30 PM, Francisco Jerez  wrote:
>> Jason Ekstrand  writes:
>>
>>> On Fri, Oct 27, 2017 at 5:24 PM, Francisco Jerez 
>>> wrote:
>>>
 I've submitted an alternative to this approach here [1], more along the
 lines of the v1 patch you borrowed from my jenkins branch.  Most of the
 reasons for that we have discussed already in the office (except for the
 last point), but FTR:

  - This patch only works around the problem by tweaking the live
intervals, which makes the live intervals inconsistent with the block
live sets (the latter are used by some back-end passes that this
patch isn't going to help with, like DCE and scheduling).

>>>
>>> I'm not sure that's strictly true.  It changes the mapping function from
>>> the live sets to the liveness intervals but it's still directly computable
>>> from live sets + cfg.  That said, there is something to be said for
>>> treating back-edges specially when computing the live sets.
>>>
>>
>> The thing is a number of back-end passes derive their liveness
>> information based on the live sets rather than the live intervals.  Take
>> the scheduler as an example -- After this change variables whose live
>> range exits a loop increase the register pressure at the beginning of
>> the loop, but the scheduler won't know because it obtains that
>> information out of the live sets, so its register pressure decisions
>> become inaccurate with this patch (unless a similar hack is implemented
>> as we have right now in the scheduler to extend live sets for variables
>> whose live range crosses through an else block).
>
> Actually, this isn't true -- I made the scheduler "fill in" its
> liveness sets to match the liveness intervals used by the register
> allocator, i.e. it already does your "hack":
>
> https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/compiler/brw_schedule_instructions.cpp#n646
>
> If it didn't do that, its results would be inaccurate, which would
> defeat the purpose of tracking register pressure in the first place.
> Not that it matters much now, though, since my patches to do limit
> scheduling never got merged.
>

Yes, I'm aware that such a thing exists, but I don't think it will be
sufficient to get the scheduler's live sets in sync with the live
intervals calculated here with this patch in place, that's what I meant
to say earlier.  The reason for that is that the live intervals extended
by this patch won't overlap the end IP of the block immediately before
the loop, so the scheduler's workaround will probably not kick in at the
top block of the loop.

>>
>>>
  - This patch doesn't fix the same bug on the VEC4 back-end.

  - I feel that the alternative approach [1] admits more straightforward
extension to more exotic control-flow constructs.

  - It doesn't actually fix the problem for all possible patterns of
divergent loop execution.  Consider the following GLSL pseudocode:

| b = 0;
| do {
|use(b);
|b = non_uniform_condition();
|if (b)
|   continue;
|
|stomp_neighboring_channels();
|break;
|
| } while(true);

With this series applied, the live interval of 'b' will be calculated
to be between the 'b = 0' and 'continue' statements, which allows
stomp_neighboring_channels() to overwrite the contents of 'b'
depending on how the register allocator lays things out in the
register file.  OTOH with [1] applied the live interval calculated
for 'b' will be the region between the 'b = 0' and 'break'
statements, which overlaps the whole region of divergent control flow
as expected.

>>>
>>> It does handle that case correctly before your patch to add defin/out but
>>> not after. :-)  This is because we always propagate livein from the top of
>>> the loop into the liveout of the while so anything livein at the top
>>> automatically gets extended down.  We do not, however, propagate defout
>>> that way (since the while is not reachable) so your patch breaks it.
>>>
>>
>> Probably, but the main use of this patch is fixing a bug that comes out
>> to surface as a side effect of my PATCH 15 of this series, so it better
>> work correctly in combination with the patch it's preparing the compiler
>> for ;)
>>
>>>
 Cheers.

 [1] https://lists.freedesktop.org/archives/mesa-dev/2017-
 October/174591.html

 Jason Ekstrand  writes:

 > No Shader-db changes.
 >
 > Cc: mesa-sta...@lists.freedesktop.org
 > ---
 >  src/intel/compiler/brw_fs_live_variables.cpp | 55
 
 >  1 file changed, 55 insertions(+)
 >
 > diff --git a/src/intel/compiler/brw_fs_live_variables.cpp
 b/src/intel/compiler/brw_fs_live_variables.cpp
 > index c449672..380060d 100644
 > --- a/src/intel/

Re: [Mesa-dev] [PATCH] i965: Enable disk shader cache by default

[Timothy Arceri]

On 08/12/17 04:57, Matt Turner wrote:

On Tue, Dec 5, 2017 at 3:40 PM, Jordan Justen  wrote:

On 2017-12-05 14:49:28, Mark Janes wrote:

Jordan Justen  writes:


On 2017-12-05 09:13:11, Mark Janes wrote:

Jordan Justen  writes:


On 2017-11-08 17:26:47, Timothy Arceri wrote:

Reviewed-by: Timothy Arceri 

Mark may want to consider adding some of the once a day type CI runs for
this. For example running the test suite for two consecutive runs on the
same build so that the second run uses the shader cache and also a
second run the uses MESA_GLSL=cache_fb to force testing of the cache
fallback path.


Yeah. We discussed this previously, but I don't think it's been
implemented yet. My opinion is that it could perhaps be a weekly test.


This automation is implemented now. It found the issues reported in
https://bugs.freedesktop.org/show_bug.cgi?id=103988

My opinion is that this test strategy is inadequate.


Meaning you think we cannot enable i965 shader cache for the 18.0
release?


I haven't heard anyone express confidence that this feature is bug-free,
and I don't know on what basis that claim could be made.  I appreciate
that a lot of have manual testing has been done.  Do you feel confident
that the cache can be enabled for all mesa customers without disruption?


If we had enabled it two months ago, then yes, we would have worked
through the niche issues, or discovered the so-far-hidden major land
mine. At this point, it's getting risky. In a month, I will say no.


We are already ~1.5 months away from the next stable branch point. If
we want to enable this in 18.0, we should be using this time to see if
enabling the cache by default has some large unexpected side effect in
our graphics stack, or breaks real-world apps.


I agree.  We should encourage as many users as possible to enable the
shader cache in their environments.  At least one stable release should
be out with a working cache, where the feature can be enabled by those
who are eager to benefit from it.  I assume there will be a lot of them,
and they could flush out issues for everyone who has no idea what a
shader cache is.


Adding a dimension to the test matrix has high cost, especially when
combined with other dimensions of the test matrix (does shader cache
need to be tested for 32/64 bit builds? For hswgt1/hswgt2/hswgt3e?).


Are you saying this is too high cost to run per check-in? Do you need
to disable it for the health of CI? I think I proposed that daily, or
perhaps even weekly would be adequate.


Certainly, the test time per line of shader cache code is massively
higher than any other feature, even if you run it just once a month.
Other features have tests that run in milliseconds, not 30min * 20
machines.


The scope of this feature is nearly the entire API. It is justified to
throw the entire GL suite of tests at it on a regular basis. The cost
of running this once per week ought to be reasonable.


But the entire API boils down to a comparatively small set of
non-orthogonal state. The configuration of those nobs seems to me like
the place things are most likely to break.

I think there's value in testing that we're hitting the cache, but if
we're not it's not a functional regression. I'm more concerned about
ensuring we don't have bugs that affect functionality and cause things
to break.

The program key for fragment shaders looks like:

/** The program key for Fragment/Pixel Shaders. */
struct brw_wm_prog_key {
/* Some collection of BRW_WM_IZ_* */
uint8_t iz_lookup;
bool stats_wm:1;
bool flat_shade:1;
unsigned nr_color_regions:5;
bool replicate_alpha:1;
bool clamp_fragment_color:1;
bool persample_interp:1;
bool multisample_fbo:1;
bool frag_coord_adds_sample_pos:1;
enum brw_wm_aa_enable line_aa:2;
bool high_quality_derivatives:1;
bool force_dual_color_blend:1;
bool coherent_fb_fetch:1;

uint64_t input_slots_valid;
unsigned program_string_id;
GLenum alpha_test_func;  /* < For Gen4/5 MRT alpha test */
float alpha_test_ref;

struct brw_sampler_prog_key_data tex;
};

and it's the most complex of the shader stages. Wouldn't you feel a
lot safer if we just had a piglit test for each of those nobs that
compiled a shader, then changed some non-orthogonal state, and then
rendered with it, thus confirming that it didn't get the wrong shader
program out of the cache?


Those are just the keys for i965s gen program. You also should be 
testing the serialization and deserialization of the GL state and the IR 
(in i965s case NIR). For NIR you could turn on an ENV var to do a 
serialization/deserialization for every shader, I think something like 
that is done for nir clone.




I know I've run into cases numerous times where piglit doesn't
actually test something, or only one seemingly unrelated test in all
50 thousand tickles a real bug in my code. I feel uncomfortable
assuming that piglit's existing coverage is good enough.


I don't see how this is relat

Re: [Mesa-dev] [PATCH] i965: Enable disk shader cache by default

[Jordan Justen]

On 2017-12-07 09:57:48, Matt Turner wrote:
> On Tue, Dec 5, 2017 at 3:40 PM, Jordan Justen  
> wrote:
> > On 2017-12-05 14:49:28, Mark Janes wrote:
> >> Jordan Justen  writes:
> >> > On 2017-12-05 09:13:11, Mark Janes wrote:
> >> >> Adding a dimension to the test matrix has high cost, especially when
> >> >> combined with other dimensions of the test matrix (does shader cache
> >> >> need to be tested for 32/64 bit builds? For hswgt1/hswgt2/hswgt3e?).
> >> >
> >> > Are you saying this is too high cost to run per check-in? Do you need
> >> > to disable it for the health of CI? I think I proposed that daily, or
> >> > perhaps even weekly would be adequate.
> >>
> >> Certainly, the test time per line of shader cache code is massively
> >> higher than any other feature, even if you run it just once a month.
> >> Other features have tests that run in milliseconds, not 30min * 20
> >> machines.
> >
> > The scope of this feature is nearly the entire API. It is justified to
> > throw the entire GL suite of tests at it on a regular basis. The cost
> > of running this once per week ought to be reasonable.
> 
> But the entire API boils down to a comparatively small set of
> non-orthogonal state. The configuration of those nobs seems to me like
> the place things are most likely to break.
> 
> I think there's value in testing that we're hitting the cache, but if
> we're not it's not a functional regression. I'm more concerned about
> ensuring we don't have bugs that affect functionality and cause things
> to break.
> 
> The program key for fragment shaders looks like:
> 
> /** The program key for Fragment/Pixel Shaders. */
> struct brw_wm_prog_key {
>/* Some collection of BRW_WM_IZ_* */
>uint8_t iz_lookup;
>bool stats_wm:1;
>bool flat_shade:1;
>unsigned nr_color_regions:5;
>bool replicate_alpha:1;
>bool clamp_fragment_color:1;
>bool persample_interp:1;
>bool multisample_fbo:1;
>bool frag_coord_adds_sample_pos:1;
>enum brw_wm_aa_enable line_aa:2;
>bool high_quality_derivatives:1;
>bool force_dual_color_blend:1;
>bool coherent_fb_fetch:1;
> 
>uint64_t input_slots_valid;
>unsigned program_string_id;
>GLenum alpha_test_func;  /* < For Gen4/5 MRT alpha test */
>float alpha_test_ref;
> 
>struct brw_sampler_prog_key_data tex;
> };
> 
> and it's the most complex of the shader stages. Wouldn't you feel a
> lot safer if we just had a piglit test for each of those nobs that
> compiled a shader, then changed some non-orthogonal state, and then
> rendered with it, thus confirming that it didn't get the wrong shader
> program out of the cache?

What would that be testing? That the disk_cache returns the same
program if we give it the same hash? Shouldn't disk_cache unit tests
cover this?

The scope is also more than just covering the various GL states that
might change the i965 program keys. We also need one or more programs
that are actually affected by that key change. We also need to test
that glsl program serialization works. We also need to test that nir
serialization works.

How about maintainability? Once we develop these 50~100 tests, how do
we make sure we update them if we change the i965 program keys?

> I know I've run into cases numerous times where piglit doesn't
> actually test something, or only one seemingly unrelated test in all
> 50 thousand tickles a real bug in my code. I feel uncomfortable
> assuming that piglit's existing coverage is good enough.

This is a reasonable point. Piglit has coverage holes. The CTS has
coverage holes. dEQP has coverage holes. I think the union of all 3
probably still has coverage holes. (But hopefully a fairly small set.)

> In general, I'm still bothered by the idea of just running piglit
> twice. That's a very untargeted approach that doesn't fit well with
> our existing testing model, as Mark has described.

Are you saying that running all of our CI tests twice is a waste of
time? I think that the 'dumb run everything twice' plan actually gets
us much more coverage than we'll likely get if we try to write 50~100
tests focusing on the i965 program keys. So, I don't agree that it is
a waste of time.

I think that the 'dumb run everything twice' plan gets us almost
everything we need, and is more maintainable. If it misses something,
then I think means we don't have good test coverage of the GL feature,
and we should add that test to one of our 3 possible GL test suites.

If you are arguing that the 'dumb run everything twice' plan is
valuable, but inadequate. Fine. I concede that maybe we could try to
add more specific focused tests. I'm not sure that these tests will
actually be added anytime soon, which means that we don't have a plan
for getting the i965 shader cache enabled.

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

Re: [Mesa-dev] [PATCH] i965: Enable disk shader cache by default

[Kenneth Graunke]

On Thursday, December 7, 2017 9:57:48 AM PST Matt Turner wrote:
[snip]
> But the entire API boils down to a comparatively small set of
> non-orthogonal state. The configuration of those nobs seems to me like
> the place things are most likely to break.

I do like Matt's idea of adding Piglit tests specifically for NOS items.
Even if we don't add tests for every item in a key, adding tests that
hit two variants of an item in the key would ensure that we're using the
right key, and not pulling the wrong one from the cache.

Yes, it's a problem with the existing in-memory cache, but it would also
be nice to have additional coverage of that.

Another idea I had was to extend the ARB_program_interface_query tasks
to have a mode (command line argument) that causes them to compile the
shader twice.  For example:

1. Compile the shader
2. Check program interface query properties
3. Delete the shader
4. Compile the shader again - which should be a cache hit
5. Check program interface query properties again

Most of these properties come from the IR and associated metadata.
That would be a way to verify that we get that right.  I think it would
have caught the VUE map bug relating to unify_interfaces() not getting
called when restoring from the cache.

It also sounds relatively easy on paper.

If we validated NOS, and validated PIQ, then I'd feel pretty good about
the cache working with only a single run.  The run-the-whole-suite-twice
idea is nice, but most people aren't going to do that on every single
patch (maybe daily?).  I'd like to have better coverage within a single
run.


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 2/2] gallium/util: don't pass a pipe_resource to util_resource_is_array_texture()

[Charmaine Lee]

Series looks good.

Reviewed-by: Charmaine Lee 


From: Brian Paul 
Sent: Thursday, December 7, 2017 2:25:05 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende; Roland Scheidegger
Subject: [PATCH 2/2] gallium/util: don't pass a pipe_resource to 
util_resource_is_array_texture()

No need to pass a pipe_resource when we can just pass the target.
This makes the function potentially more usable.  Rename it too.
---
 src/gallium/auxiliary/util/u_resource.h   | 6 +++---
 src/gallium/drivers/radeon/r600_texture.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_resource.h 
b/src/gallium/auxiliary/util/u_resource.h
index 6736476..3c6194b 100644
--- a/src/gallium/auxiliary/util/u_resource.h
+++ b/src/gallium/auxiliary/util/u_resource.h
@@ -32,14 +32,14 @@ unsigned
 util_resource_size(const struct pipe_resource *res);

 /**
- * Return true if the resource is an array texture.
+ * Return true if the texture target is an array type.
  *
  * Note that this function returns true for single-layered array textures.
  */
 static inline boolean
-util_resource_is_array_texture(const struct pipe_resource *res)
+util_texture_is_array(enum pipe_texture_target target)
 {
-   switch (res->target) {
+   switch (target) {
case PIPE_TEXTURE_1D_ARRAY:
case PIPE_TEXTURE_2D_ARRAY:
case PIPE_TEXTURE_CUBE_ARRAY:
diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index cb69398..66d4f02 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -582,7 +582,7 @@ static void si_query_opaque_metadata(struct si_screen 
*sscreen,
PIPE_SWIZZLE_W
};
uint32_t desc[8], i;
-   bool is_array = util_resource_is_array_texture(res);
+   bool is_array = util_texture_is_array(res->target);

/* DRM 2.x.x doesn't support this. */
if (sscreen->info.drm_major != 3)
--
1.9.1

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

Re: [Mesa-dev] [PATCH 15/23] main: add binary support to ProgramBinary

[Tapani Pälli]

13,14,15

Reviewed-by: Tapani Pälli 

On 11/29/2017 03:24 AM, Timothy Arceri wrote:

From: Jordan Justen 

V2: call generic mesa_program_binary() helper rather than driver
 function directly to allow greater code sharing.

Signed-off-by: Timothy Arceri 
Signed-off-by: Jordan Justen  (v1)
Reviewed-by: Nicolai Hähnle  (v1)
---
  src/mesa/main/shaderapi.c | 36 +++-
  1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index b728b320ac4..51031e12ec9 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -2214,47 +2214,49 @@ void GLAPIENTRY
  _mesa_ProgramBinary(GLuint program, GLenum binaryFormat,
  const GLvoid *binary, GLsizei length)
  {
 struct gl_shader_program *shProg;
 GET_CURRENT_CONTEXT(ctx);
  
 shProg = _mesa_lookup_shader_program_err(ctx, program, "glProgramBinary");

 if (!shProg)
return;
  
-   (void) binaryFormat;

-   (void) binary;
-
 /* Section 2.3.1 (Errors) of the OpenGL 4.5 spec says:
  *
  * "If a negative number is provided where an argument of type sizei or
  * sizeiptr is specified, an INVALID_VALUE error is generated."
  */
 if (length < 0) {
_mesa_error(ctx, GL_INVALID_VALUE, "glProgramBinary(length < 0)");
return;
 }
  
-   /* The ARB_get_program_binary spec says:

-*
-* " and  must be those returned by a previous
-* call to GetProgramBinary, and  must be the length of the
-* program binary as returned by GetProgramBinary or GetProgramiv with
-*  PROGRAM_BINARY_LENGTH. Loading the program binary will fail,
-* setting the LINK_STATUS of  to FALSE, if these conditions
-* are not met."
-*
-* Since any value of binaryFormat passed "is not one of those specified as
-* allowable for [this] command, an INVALID_ENUM error is generated."
-*/
-   shProg->data->LinkStatus = linking_failure;
-   _mesa_error(ctx, GL_INVALID_ENUM, "glProgramBinary");
+   if (ctx->Const.NumProgramBinaryFormats == 0 ||
+   binaryFormat != GL_PROGRAM_BINARY_FORMAT_MESA) {
+  /* The ARB_get_program_binary spec says:
+   *
+   * " and  must be those returned by a previous
+   * call to GetProgramBinary, and  must be the length of the
+   * program binary as returned by GetProgramBinary or GetProgramiv 
with
+   *  PROGRAM_BINARY_LENGTH. Loading the program binary will 
fail,
+   * setting the LINK_STATUS of  to FALSE, if these conditions
+   * are not met."
+   *
+   * Since any value of binaryFormat passed "is not one of those specified 
as
+   * allowable for [this] command, an INVALID_ENUM error is generated."
+   */
+  shProg->data->LinkStatus = linking_failure;
+  _mesa_error(ctx, GL_INVALID_ENUM, "glProgramBinary");
+   } else {
+  _mesa_program_binary(ctx, shProg, binaryFormat, binary, length);
+   }
  }
  
  
  static ALWAYS_INLINE void

  program_parameteri(struct gl_context *ctx, struct gl_shader_program *shProg,
 GLuint pname, GLint value, bool no_error)
  {
 switch (pname) {
 case GL_PROGRAM_BINARY_RETRIEVABLE_HINT:
/* This enum isn't part of the OES extension for OpenGL ES 2.0, but it


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