[Mesa-dev] [PATCH 2/2] i965/tcs: support gl_PatchVerticesIn as a system value from SPIR-V

[Iago Toral Quiroga]

We currently handle this by lowering it to a uniform for gen8+ but
the SPIR-V path generates this as a system value, so handle that
case as well.
---
 src/mesa/drivers/dri/i965/brw_tcs.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c 
b/src/mesa/drivers/dri/i965/brw_tcs.c
index 4424efea4f0..b07b11f485d 100644
--- a/src/mesa/drivers/dri/i965/brw_tcs.c
+++ b/src/mesa/drivers/dri/i965/brw_tcs.c
@@ -296,7 +296,14 @@ brw_tcs_populate_key(struct brw_context *brw,
   per_patch_slots |= prog->info.patch_outputs_written;
}
 
-   if (devinfo->gen < 8 || !tcp)
+   /* For GLSL, gen8+ lowers gl_PatchVerticesIn to a uniform, however
+* the SPIR-V path always lowers it to a system value.
+*/
+   bool reads_patch_vertices_as_system_value =
+  tcp && (tcp->program.nir->info.system_values_read &
+  BITFIELD64_BIT(SYSTEM_VALUE_VERTICES_IN));
+
+   if (devinfo->gen < 8 || !tcp || reads_patch_vertices_as_system_value)
   key->input_vertices = brw->ctx.TessCtrlProgram.patch_vertices;
key->outputs_written = per_vertex_slots;
key->patch_outputs_written = per_patch_slots;
-- 
2.11.0

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

[Mesa-dev] [PATCH 1/2] nir/gather_info: recognize load_patch_vertices_in as a system value

[Iago Toral Quiroga]

This intrinsic is produced to load SYSTEM_VALUE_VERTICES_IN, which is
generated to load gl_PatchVerticesIn in the SPIR-V path for both
Vulkan and OpenGL.
---
 src/compiler/nir/nir_gather_info.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compiler/nir/nir_gather_info.c 
b/src/compiler/nir/nir_gather_info.c
index 13cdae39eca..a322af794e5 100644
--- a/src/compiler/nir/nir_gather_info.c
+++ b/src/compiler/nir/nir_gather_info.c
@@ -246,6 +246,7 @@ gather_intrinsic_info(nir_intrinsic_instr *instr, 
nir_shader *shader)
case nir_intrinsic_load_tess_coord:
case nir_intrinsic_load_tess_level_outer:
case nir_intrinsic_load_tess_level_inner:
+   case nir_intrinsic_load_patch_vertices_in:
   shader->info.system_values_read |=
  (1ull << nir_system_value_from_intrinsic(instr->intrinsic));
   break;
-- 
2.11.0

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

[Mesa-dev] [Bug 103699] Latest mesa breaks firefox on kde plasma with compositing on

[bugzilla-daemon]

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

--- Comment #11 from Tapani Pälli  ---
Created attachment 135512
  --> https://bugs.freedesktop.org/attachment.cgi?id=135512=edit
test case

Could you please compile and run this test application and attach what is
prints? Does it create a visible window? Also please attach your glxinfo
output. Many thanks!

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

[Mesa-dev] [Bug 103757] eglGetDisplay() is broken for Wayland

[bugzilla-daemon]

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

--- Comment #10 from Pekka Paalanen  ---
(In reply to Michael Olbrich from comment #9)
> (In reply to Pekka Paalanen from comment #1)
> > Any reason you cannot use EGL_KHR_platform_wayland?
> 
> It's not my code. It's somewhere in gstreamer-vaapi. I was just debugging
> why my application was crashing.

Ok, while this issue is being worked on in Mesa, I would very much recommend
filing a bug against gstreamer-vaapi to start using the EGL platform extensions
whenever available. It's the only reliable way forward.

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

[Mesa-dev] [Bug 103586] OpenCL/Clover: AMD Turks: corrupt output buffer (depending on dimension order?)

[bugzilla-daemon]

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

--- Comment #14 from Jan Vesely  ---
(In reply to Dave Gilbert from comment #12)
> 
> It doesn't seem to help, if I add:
> --- a/ocl.cpp
> +++ b/ocl.cpp
> @@ -74,6 +74,7 @@ static int got_dev(cl::Platform ,
> std::vector , cl::Dev
>  cl::Event eventBarrier2;
>  queue.enqueueBarrierWithWaitList(NULL,);
>  std::cerr << __func__ << "enqueueMapBuffer gave: " << err << std::endl;
> +event.wait();
>  eventMap.wait();
>  eventBarrier2.wait();
>  
> 
> that doesn't seem to help and I think event is the event triggered by the
> kernel.

can you move it few lines up? (before the call to mapBuffer).

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

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Matt Turner]

On Wed, Nov 15, 2017 at 5:10 PM, Dylan Baker  wrote:
> This patch checks for an and then enables sse4.1 optimizations if the
> host machine will be x86/x86_64.

There's some stack realignment stuff that probably needs to stay, but
depending on what gcc version we require we can just always enable SSE
4.1. It's existed since GCC 4.3 (March 2008).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103128] [softpipe] piglit fs-ldexp regression

[bugzilla-daemon]

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

Nicolai Hähnle  changed:

   What|Removed |Added

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

--- Comment #3 from Nicolai Hähnle  ---
commit f3fa3b0d95c712c00318ca5601433bce1b82432d

-- 
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 103674] u_queue.c:173:7: error: implicit declaration of function 'timespec_get' is invalid in C99

[bugzilla-daemon]

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

Nicolai Hähnle  changed:

   What|Removed |Added

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

--- Comment #3 from Nicolai Hähnle  ---
commit 2e3d0dd6c8f405f27d68b1ac35e928233bf8b89c

-- 
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 4/4] meson: Remove completed or irrelevant TODO comments

[Dylan Baker]

These are all either done already, or are autotools specific. The
misspelled gallium G3DVL is the autotools specific bit, meson is
handling that via build_by_default.

Signed-off-by: Dylan Baker 
---
 meson.build | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/meson.build b/meson.build
index 5ac2ebc9e5d..d0e14b549fc 100644
--- a/meson.build
+++ b/meson.build
@@ -547,13 +547,6 @@ endif
 # TODO: powr8
 # TODO: shared/static? Is this even worth doing?
 
-# I don't think that I need to set any of the debug stuff, I think meson
-# handles that for us
-
-# TODO: ldflags
-
-# TODO: texture-float (gallium/mesa only)
-
 # Building x86 assembly code requires running x86 binaries. It is possible for
 # x86_64 OSes to run x86 binaries, so don't disable asm in those cases
 # TODO: it should be possible to use an exe_wrapper to run the binary durring
@@ -800,12 +793,8 @@ else
   dep_unwind = []
 endif
 
-# TODO: flags for opengl, gles, dri
-
 # TODO: gallium-hud
 
-# TODO: glx provider
-
 if with_osmesa != 'none'
   if with_osmesa == 'classic' and not with_dri_swrast
 error('OSMesa classic requires dri (classic) swrast.')
@@ -898,10 +887,6 @@ if with_platform_x11
   endif
 endif
 
-# TODO: osmesa
-
-# TODO: vallium G3DVL
-
 # TODO: nine
 
 # TODO: clover
-- 
2.15.0

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

[Mesa-dev] [PATCH 3/4] meson: Fix TODO for missing dl_iterate_phdr function

[Dylan Baker]

This function is required for both the Intel "Anvil" vulkan driver and
the i965 GL driver. Error out if either of those is enabled but this
function isn't found.

Signed-off-by: Dylan Baker 
---
 meson.build | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index 261c4753427..5ac2ebc9e5d 100644
--- a/meson.build
+++ b/meson.build
@@ -672,8 +672,10 @@ endif
 
 if cc.has_function('dl_iterate_phdr')
   pre_args += '-DHAVE_DL_ITERATE_PHDR'
-else
-  # TODO: this is required for vulkan
+elif with_intel_vk
+  error('Intel "Anvil" Vulkan driver requires the dl_iterate_phdr function')
+elif with_dri_i965 and get_option('shader-cache')
+  error('Intel i965 GL driver requires dl_iterate_phdr when built with shader 
caching.')
 endif
 
 # Determine whether or not the rt library is needed for time functions
-- 
2.15.0

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

[Mesa-dev] [PATCH 2/4] meson: disable x86 asm in fewer cases.

[Dylan Baker]

This patch allows building asm for x86 on x86_64 platforms, when the
operating system is the same. Previously cross compile always turned off
assembly. This allows using a cross file to cross compile x86 binaries
on x86_64 with asm.

This could probably be relaxed further thanks to meson's "exe_wrapper",
which is way to specify an emulator or compatibility layer (wine) that
can run the foreign binaries on the build system. Since the meson build
at this point only supports building on Linux I can't test this and I
don't want to write/enable code that cannot even be build tested.

Signed-off-by: Dylan Baker 
---
 meson.build | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/meson.build b/meson.build
index 0d201c711a0..261c4753427 100644
--- a/meson.build
+++ b/meson.build
@@ -554,13 +554,16 @@ endif
 
 # TODO: texture-float (gallium/mesa only)
 
-# TODO: cross-compiling. I don't think this is relavent to meson
-
-# FIXME: enable asm when cross compiler
-# This is doable (autotools does it), but it's not of immediate concern
-if meson.is_cross_build() and host_machine.cpu_family().startswith('x86')
-  message('Cross compiling, disabling x86/x86_64 asm')
-  with_asm = false
+# Building x86 assembly code requires running x86 binaries. It is possible for
+# x86_64 OSes to run x86 binaries, so don't disable asm in those cases
+# TODO: it should be possible to use an exe_wrapper to run the binary durring
+# the build. 
+if meson.is_cross_build() 
+  if (not (build_machine.cpu_family() == 'x86_64' and 
host_machine.cpu_family() == 'x86')
+  and build_machine.system() == host_machine.system())
+message('Cross compiling to x86 from non-x86, disabling asm')
+with_asm = false
+  endif
 endif
 
 with_asm_arch = ''
-- 
2.15.0

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

[Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Dylan Baker]

This patch checks for an and then enables sse4.1 optimizations if the
host machine will be x86/x86_64.

Signed-off-by: Dylan Baker 
---
 meson.build  | 27 ++-
 src/mesa/meson.build | 14 +++---
 2 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/meson.build b/meson.build
index 1c4200705f3..0d201c711a0 100644
--- a/meson.build
+++ b/meson.build
@@ -502,7 +502,32 @@ foreach a : ['-Wno-override-init', 
'-Wno-initializer-overrides']
   endif
 endforeach
 
-# TODO: SSE41 (which is only required for core mesa)
+with_sse41 = false
+if host_machine.cpu_family().startswith('x86')
+  sse41_args = ['-msse4.1']
+  # GCC on x86 (not 64) with -msse* assumes a 16 byte aligned stack, but that's
+  # not guaranteed
+  if host_machine.cpu_family() == 'x86'
+sse41_args += '-mstackrealign'
+  endif
+
+  _code = '''
+  #include 
+  int param;
+  int main () {
+  __m128i a = _mm_set1_epi32 (param), b = _mm_set1_epi32 (param + 1), c;
+  c = _mm_max_epu32(a, b);
+  return _mm_cvtsi128_si32(c);
+  }
+  '''
+
+  if cc.compiles(_code, args : sse41_args, name : 'SSE4.1')
+pre_args += '-DHAVE_SSE41'
+with_sse41 = true
+  endif
+else
+  sse41_args = []
+endif
 
 # Check for GCC style atomics
 if cc.compiles('int main() { int n; return __atomic_load_n(, 
__ATOMIC_ACQUIRE); }',
diff --git a/src/mesa/meson.build b/src/mesa/meson.build
index b839fd02981..05a3a9ac55d 100644
--- a/src/mesa/meson.build
+++ b/src/mesa/meson.build
@@ -592,9 +592,6 @@ files_libmesa_gallium = files(
   'state_tracker/st_vdpau.h',
 )
 
-# TODO: sse41
-libmesa_sse41 = []
-
 matypes_h = []
 if with_asm_arch == 'x86' or with_asm_arch == 'x86_64'
   gen_matypes = executable(
@@ -692,6 +689,17 @@ files_libmesa_common += [
   sha1_h,
 ]
 
+if with_sse41
+  libmesa_sse41 = static_library(
+'mesa_sse41',
+files('main/streaming-load-memcpy.c', 'main/sse_minmax.c'),
+c_args : [c_vis_args, c_msvc_compat_args, sse41_args],
+include_directories : inc_common,
+  )
+else
+  libmesa_sse41 = []
+endif
+
 libmesa_classic = static_library(
   'mesa_classic',
   [files_libmesa_common, files_libmesa_classic],
-- 
2.15.0

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

Re: [Mesa-dev] [PATCH] st/glsl_to_nir: don't generate nir twice for gs

[Dylan Baker]

Quoting Timothy Arceri (2017-11-15 16:16:10)
> This was left out of c980a3aa3133
> ---
>  src/mesa/state_tracker/st_program.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_program.c 
> b/src/mesa/state_tracker/st_program.c
> index 97b2e1234b..dc81a17289 100644
> --- a/src/mesa/state_tracker/st_program.c
> +++ b/src/mesa/state_tracker/st_program.c
> @@ -1424,29 +1424,23 @@ st_translate_program_common(struct st_context *st,
>  
>  /**
>   * Translate a geometry program to create a new variant.
>   */
>  bool
>  st_translate_geometry_program(struct st_context *st,
>struct st_common_program *stgp)
>  {
> struct ureg_program *ureg;
>  
> -   if (stgp->shader_program) {
> -  nir_shader *nir = st_glsl_to_nir(st, >Base, stgp->shader_program,
> -   MESA_SHADER_GEOMETRY);
> -
> -  stgp->tgsi.type = PIPE_SHADER_IR_NIR;
> -  stgp->tgsi.ir.nir = nir;
> -
> +   /* We have already compiler to NIR so just return */
 
 compiled
> +   if (stgp->shader_program)
>return true;
> -   }
>  
> ureg = ureg_create_with_screen(PIPE_SHADER_GEOMETRY, st->pipe->screen);
> if (ureg == NULL)
>return false;
>  
> ureg_property(ureg, TGSI_PROPERTY_GS_INPUT_PRIM,
>   stgp->Base.info.gs.input_primitive);
> ureg_property(ureg, TGSI_PROPERTY_GS_OUTPUT_PRIM,
>   stgp->Base.info.gs.output_primitive);
> ureg_property(ureg, TGSI_PROPERTY_GS_MAX_OUTPUT_VERTICES,
> -- 
> 2.14.3
> 
> ___
> 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

[Mesa-dev] [PATCH] st/glsl_to_nir: don't generate nir twice for gs

[Timothy Arceri]

This was left out of c980a3aa3133
---
 src/mesa/state_tracker/st_program.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 97b2e1234b..dc81a17289 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -1424,29 +1424,23 @@ st_translate_program_common(struct st_context *st,
 
 /**
  * Translate a geometry program to create a new variant.
  */
 bool
 st_translate_geometry_program(struct st_context *st,
   struct st_common_program *stgp)
 {
struct ureg_program *ureg;
 
-   if (stgp->shader_program) {
-  nir_shader *nir = st_glsl_to_nir(st, >Base, stgp->shader_program,
-   MESA_SHADER_GEOMETRY);
-
-  stgp->tgsi.type = PIPE_SHADER_IR_NIR;
-  stgp->tgsi.ir.nir = nir;
-
+   /* We have already compiler to NIR so just return */
+   if (stgp->shader_program)
   return true;
-   }
 
ureg = ureg_create_with_screen(PIPE_SHADER_GEOMETRY, st->pipe->screen);
if (ureg == NULL)
   return false;
 
ureg_property(ureg, TGSI_PROPERTY_GS_INPUT_PRIM,
  stgp->Base.info.gs.input_primitive);
ureg_property(ureg, TGSI_PROPERTY_GS_OUTPUT_PRIM,
  stgp->Base.info.gs.output_primitive);
ureg_property(ureg, TGSI_PROPERTY_GS_MAX_OUTPUT_VERTICES,
-- 
2.14.3

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

[Mesa-dev] [PATCH] util: add new ASSERT_BITFIELD_SIZE() macro (v2)

[Brian Paul]

For checking that bitfields are large enough to hold the largest
expected value.

v2: move into existing util/macros.h header where STATIC_ASSERT() lives.
---
 src/util/macros.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/util/macros.h b/src/util/macros.h
index a9a52a1..3fd0ffd 100644
--- a/src/util/macros.h
+++ b/src/util/macros.h
@@ -68,6 +68,22 @@
 
 
 /**
+ * Check that STRUCT::FIELD can hold MAXVAL.  We use a lot of bitfields
+ * in Mesa/gallium.  We have to be sure they're of sufficient size to
+ * hold the largest expected value.
+ * Note that with MSVC, enums are signed and enum bitfields need one extra
+ * high bit (always zero) to ensure the max value is handled correctly.
+ * This macro will detect that with MSVC, but not GCC.
+ */
+#define ASSERT_BITFIELD_SIZE(STRUCT, FIELD, MAXVAL) \
+   do { \
+  STRUCT s; \
+  s.FIELD = (MAXVAL); \
+  assert((int) s.FIELD == (MAXVAL) && "Insufficient bitfield size!"); \
+   } while (0)
+
+
+/**
  * Unreachable macro. Useful for suppressing "control reaches end of non-void
  * function" warnings.
  */
-- 
1.9.1

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

Re: [Mesa-dev] Driver testing system for Steam games

[Karen Ghavam]

Folks,

If you have feedback or questions, you can mail them to i...@lunarg.com

Karen Ghavam
CEO and Engineering Director
LunarG, Inc. - 3D Graphics Software Innovations
ka...@lunarg.com
970-988-9043

On Wed, Nov 15, 2017 at 1:32 PM, Pierre-Loup A. Griffais <
pgriff...@valvesoftware.com> wrote:

> Hi Mesa-Devel,
>
> Today we're happy to announce that we're making the LunarG driver
> testing system available to the Mesa development community. We've been
> using this system internally for quite some time, but we've recently
> done some more work so the results could also be publicly available for
> the community to track regressions, and for developers to be able to
> submit their branches for pre-submit testing.
>
> The LunarG test system is a service that provides regular regression
> testing on Mesa releases for Intel and AMD OpenGL graphics drivers. It
> also enables users to test their own Mesa builds and compare results to
> LunarG baselines, LunarG test runs, or user test runs. The objective of
> the LunarG test system service for Mesa is to identify regressions in
> performance or rendering for Mesa releases and developer's branches that
> would negatively impact the gaming experience.
>
> The test suite is a collection of trace files created from hundreds of
> Linux OpenGL games from Steam. These trace files are used to automate
> testing of rendering correctness as well as game performance. There are
> currently 6 graphics platforms available for test (3 configurations each
> of Intel and AMD graphics). The full suite of games typically runs
> overnight with results posted the next day.
>
> To access the test system and browse results: https://share.lunarg.com
> (click on "Test System") on the left.
>
> Here's an example of a test report that a Mesa bug could possibly be filed
> from after inspection: https://imgur.com/a/cBonz
>
> To learn more about how the test system works, read the short user
> manual: https://share.lunarg.com/test/manual
>
> Let us know if you have any feedback or questions. Vulkan support is
> planned for the future, but not ready quite yet.
>
> Thanks,
>   - Pierre-Loup
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/24] mesa: add gl_shader::SpirVBinary and getter

[Timothy Arceri]

On 16/11/17 00:22, Eduardo Lima Mitev wrote:

From: Nicolai Hähnle 

---
  src/mesa/main/mtypes.h| 1 +
  src/mesa/main/shaderapi.c | 3 +++
  2 files changed, 4 insertions(+)

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 1c953b83155..cfc763f043e 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2579,6 +2579,7 @@ struct gl_shader
 GLchar *Label;   /**< GL_KHR_debug */
 unsigned char sha1[20]; /**< SHA1 hash of pre-processed source */
 GLboolean DeletePending;
+   GLboolean SpirVBinary;


As with my other comment about a special spirv bool. I think you should 
move this patch to later in the series drop the bool and instead query 
whether spirv_data is NULL or not to decide if this is a spriv shader.




 bool IsES;  /**< True if this shader uses GLSL ES */
  
 enum gl_compile_status CompileStatus;

diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 72824355838..5db335b695b 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -960,6 +960,9 @@ get_shaderiv(struct gl_context *ctx, GLuint name, GLenum 
pname, GLint *params)
 case GL_SHADER_SOURCE_LENGTH:
*params = shader->Source ? strlen((char *) shader->Source) + 1 : 0;
break;
+   case GL_SPIR_V_BINARY_ARB:
+  *params = shader->SpirVBinary;
+  break;
 default:
_mesa_error(ctx, GL_INVALID_ENUM, "glGetShaderiv(pname)");
return;


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

[Mesa-dev] [Bug 103412] gallium/wgl: Another fix to context creation without prior SetPixelFormat()

[bugzilla-daemon]

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

Brian Paul  changed:

   What|Removed |Added

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

--- Comment #2 from Brian Paul  ---
Pushed as commit bf41b2b2627aa3790d380092c28c5d3395cc9cde

-- 
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/2] util: fix compatibility of timespec_get() across OSes

[George Kyriazis]

while timespec_get() is supposed to hide OS differences, compatibility doesn't
cover old OSes (like CentOS 6) where timespec_get() does not exist.

Fall back to using os_get_time_nano(), but separate out the functionality
that populates struct timespec, so it can also be called from
_util_queue_fence_wait_timeout(), where timespec_get() was initially called.
---
 src/util/os_time.c | 31 ---
 src/util/os_time.h |  6 ++
 src/util/u_queue.c |  5 -
 3 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/src/util/os_time.c b/src/util/os_time.c
index 1c34bfd..a3cef81 100644
--- a/src/util/os_time.c
+++ b/src/util/os_time.c
@@ -48,37 +48,36 @@
 #  error Unsupported OS
 #endif
 
-
-int64_t
-os_time_get_nano(void)
+void
+os_time_get_sec_nano(int64_t *sec, int64_t *nsec)
 {
 #if defined(__linux__)
 
-   struct timespec tv;
-   clock_gettime(CLOCK_MONOTONIC, );
-   return tv.tv_nsec + tv.tv_sec*INT64_C(10);
+   struct timespec ts;
+   clock_gettime(CLOCK_MONOTONIC, );
+   *sec = ts.tv_sec;
+   *nsec = ts.tv_nsec;
 
 #elif defined(__unix__)
 
struct timeval tv;
gettimeofday(, NULL);
-   return tv.tv_usec*INT64_C(1000) + tv.tv_sec*INT64_C(10);
+   *sec = tv.tv_sec;
+   *nsec = tv.tv_usec * INT64_T(1000);
 
 #elif defined(_MSC_VER)
 
static LARGE_INTEGER frequency;
LARGE_INTEGER counter;
-   int64_t secs, nanosecs;
if(!frequency.QuadPart)
   QueryPerformanceFrequency();
QueryPerformanceCounter();
/* Compute seconds and nanoseconds parts separately to
 * reduce severity of precision loss.
 */
-   secs = counter.QuadPart / frequency.QuadPart;
-   nanosecs = (counter.QuadPart % frequency.QuadPart) * INT64_C(10)
+   *sec = counter.QuadPart / frequency.QuadPart;
+   *nsec = (counter.QuadPart % frequency.QuadPart) * INT64_C(10)
   / frequency.QuadPart;
-   return secs*INT64_C(10) + nanosecs;
 
 #else
 
@@ -87,6 +86,16 @@ os_time_get_nano(void)
 #endif
 }
 
+int64_t
+os_time_get_nano(void)
+{
+   int64_t secs, nanosecs;
+
+   os_time_get_sec_nano(, );
+
+   return secs*INT64_C(10) + nanosecs;
+}
+
 
 
 void
diff --git a/src/util/os_time.h b/src/util/os_time.h
index 049ab11..6169431 100644
--- a/src/util/os_time.h
+++ b/src/util/os_time.h
@@ -46,6 +46,12 @@ extern "C" {
 #define OS_TIMEOUT_INFINITE 0xull
 
 /*
+ * Get the current time in seconds and nanoseconds from an unknown base.
+ */
+void
+os_time_get_sec_nano(int64_t *sec, int64_t *nsec);
+
+/*
  * Get the current time in nanoseconds from an unknown base.
  */
 int64_t
diff --git a/src/util/u_queue.c b/src/util/u_queue.c
index 43c28ac..753d59e 100644
--- a/src/util/u_queue.c
+++ b/src/util/u_queue.c
@@ -168,9 +168,12 @@ _util_queue_fence_wait_timeout(struct util_queue_fence 
*fence,
int64_t rel = abs_timeout - os_time_get_nano();
 
if (rel > 0) {
+  int64_t sec, nsec;
   struct timespec ts;
 
-  timespec_get(, TIME_UTC);
+  os_time_get_sec_nano(, );
+  ts.tv_sec = sec;
+  ts.tv_nsec = nsec;
 
   ts.tv_sec += abs_timeout / (1000*1000*1000);
   ts.tv_nsec += abs_timeout % (1000*1000*1000);
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 17/24] mesa/main: Add a 'spirv' flag to gl_shader_program_data

[Timothy Arceri]

On 16/11/17 00:22, Eduardo Lima Mitev wrote:

This will be used by the linker code to dfferentiate between
programs made out of SPIR-V or GLSL shaders.


So far everywhere this is used it seems you could just do something like:

 if (shProg->_LinkedShaders[stage]->spirv_data)
   ... spriv stuff ...
 else
   ... glsl stuff ...




---
  src/mesa/main/mtypes.h | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index d624f2cbd19..db9c2e1deaa 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2902,6 +2902,12 @@ struct gl_shader_program_data
  
 /* Mask of stages this program was linked against */

 unsigned linked_stages;
+
+   /* Whether the shaders of this program are loaded from SPIR-V binaries
+* (all have the SPIR_V_BINARY_ARB state). This was introduced by the
+* ARB_gl_spirv extension.
+*/
+   bool spirv;
  };
  
  /**



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

Re: [Mesa-dev] [PATCH v2] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

[kallisti5]

On 2017-11-15 08:35, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds

Cc: Jon Turney 
Cc: Rob Herring 
Cc: Alexander von Gluck IV 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11 changes")


I don't have the power to approve (I assume), but both look good to me.

Thanks for doing SCons as well.
We have a few incomplete patches floating around to add autotools 
support...

They should be finished someday :-)

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

[Mesa-dev] [PATCH] radv: get rid of another api bypass in the wsi code.

[Dave Airlie]

From: Dave Airlie 

This just uses the vulkan api to get the fd from the memory.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_wsi.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index e4f7fa7..3cf0cbd 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -277,7 +277,7 @@ radv_wsi_image_create(VkDevice device_h,
VkImage client_image_h = VK_NULL_HANDLE;
struct radeon_surf *surface;
struct radv_image *image;
-   struct radv_device_memory *memory;
+   VkDeviceMemory memory_h;
int fd;
RADV_FROM_HANDLE(radv_device, device, device_h);
 
@@ -297,7 +297,7 @@ radv_wsi_image_create(VkDevice device_h,
if (result != VK_SUCCESS)
goto fail;
image = radv_image_from_handle(client_image_h);
-   memory = radv_device_memory_from_handle(private->client_memory_h);
+   memory_h = private->client_memory_h;
 
if (different_gpu) {
result = radv_wsi_image_create_common(device_h,
@@ -309,7 +309,7 @@ radv_wsi_image_create(VkDevice device_h,
if (result != VK_SUCCESS)
goto fail;
image = radv_image_from_handle(private->wsi_image_h);
-   memory = radv_device_memory_from_handle(private->wsi_memory_h);
+   memory_h = private->wsi_memory_h;
 
for (uint32_t q = 0; q < RADV_MAX_QUEUE_FAMILIES; q++) {
result = wsi_create_blit_cmd_buffer(_cbs, device_h,
@@ -325,10 +325,12 @@ radv_wsi_image_create(VkDevice device_h,
}
}
 
-   if (!radv_get_memory_fd(device, memory, )) {
-   result = vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
+   VkMemoryGetFdInfoKHR getfdinfo;
+   getfdinfo.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR;
+   getfdinfo.memory = memory_h;
+   result = radv_GetMemoryFdKHR(device_h, , );
+   if (result != VK_SUCCESS)
goto fail;
-   }
 
surface = >surface;
 
-- 
2.9.5

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

Re: [Mesa-dev] [PATCH v2] mesa/teximage: add TEXTURE_CUBE_MAP_ARRAY target for CompressedTexImage3D

[Ilia Mirkin]

On Wed, Nov 15, 2017 at 5:49 PM, Nanley Chery  wrote:
> On Wed, Nov 15, 2017 at 12:08:58PM -0500, Ilia Mirkin wrote:
>> On Wed, Nov 15, 2017 at 11:54 AM, Juan A. Suarez Romero
>>  wrote:
>> > From section 8.7, page 179 of OpenGL ES 3.2 spec:
>> >
>> >   An INVALID_OPERATION error is generated by CompressedTexImage3D
>> >   if internalformat is one of the the formats in table 8.17 and target
>> >   is not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
>> >
>> >   An INVALID_OPERATION error is generated by CompressedTexImage3D if
>> >   internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube Map Array”
>> >   column of table 8.17 is not checked, or if internalformat is
>> >   TEXTURE_3D and the “3D Tex.” column of table 8.17 is not checked.
>> >
>> > So far it was only considering TEXTURE_2D_ARRAY as valid target. But as
>> > "Cube Map Array" column is checked for all the cases, in practice we can
>> > consider also TEXTURE_CUBE_MAP_ARRAY.
>> >
>> > This fixes KHR-GLES32.core.texture_cube_map_array.etc2_texture
>> > ---
>> >  src/mesa/main/teximage.c | 25 +
>> >  1 file changed, 17 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
>> > index 4ec6148bf42..174731d0d8a 100644
>> > --- a/src/mesa/main/teximage.c
>> > +++ b/src/mesa/main/teximage.c
>> > @@ -1403,17 +1403,26 @@ _mesa_target_can_be_compressed(const struct 
>> > gl_context *ctx, GLenum target,
>> > * have already been handled by normal ETC2/EAC behavior.
>> > */
>> >
>> > -  /* From section 3.8.6, page 146 of OpenGL ES 3.0 spec:
>> > +  /* From section 8.7, page 179 of OpenGL ES 3.2 spec:
>> > *
>> > -   *"The ETC2/EAC texture compression algorithm supports only
>> > -   * two-dimensional images. If internalformat is an ETC2/EAC 
>> > format,
>> > -   * glCompressedTexImage3D will generate an INVALID_OPERATION 
>> > error if
>> > -   * target is not TEXTURE_2D_ARRAY."
>> > +   *  An INVALID_OPERATION error is generated by 
>> > CompressedTexImage3D
>> > +   *  if internalformat is one of the the formats in table 8.17 
>> > and target is
>> > +   *  not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
>> > *
>> > -   * This should also be applicable for glTexStorage3D(). Other 
>> > available
>> > -   * targets for these functions are: TEXTURE_3D and 
>> > TEXTURE_CUBE_MAP_ARRAY.
>> > +   *  An INVALID_OPERATION error is generated by 
>> > CompressedTexImage3D
>> > +   *  if internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube 
>> > Map
>> > +   *  Array” column of table 8.17 is not checked, or if 
>> > internalformat
>> > +   *  is TEXTURE_- 3D and the “3D Tex.” column of table 8.17 is 
>> > not
>> > +   *  checked.
>> > +   *
>> > +   * The instances of  above should say .
>> > +   *
>> > +   * This should also be applicable for glTexStorage3D().
>> > +   *
>> > +   * Such table 8.17 has checked "Cube Map Array" column for all the
>> > +   * cases. So in practice, TEXTURE_CUBE_MAP_ARRAY is now valid.
>> > */
>
> This deletes the comment describing the old OpenGL ES 3.0 behavior.
>
>> > -  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx))
>> > +  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx) && 
>> > !_mesa_is_gles32(ctx))
>
> Some of these lines look longer than 80 chars.
>
>>
>> Perhaps this should be
>>
>> !_mesa_has_OES_texture_cube_map_array(ctx)?
>>
>
> I think you're right. It looks like OES_texture_cube_map_array was folded
> into ES 3.2. I haven't done the comparison myself to confirm this
> however.
>
>> It's unclear from that spec though... perhaps ES 3.2 goes further and
>> is required to be supported.
>>
>
> If the OpenGL ES Wikipedia page is reliable, we should probably be checking 
> for
> this extension before exposing ES 3.2.

https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/version.c#n547

Anyways, the question is whether OES_texture_cube_map_array is
sufficient, or if ES 3.2 is needed for this change to apply. Not sure.
I didn't dig in deeply enough.

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

[Mesa-dev] [PATCH] radv/wsi: don't use a helper for blit, just call copy image.

[Dave Airlie]

From: Dave Airlie 

We ignore layout currently, not sure what would be correct to pass.

(this is based on Jason's last wsi rfc)

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_meta.h  |  4 
 src/amd/vulkan/radv_meta_copy.c | 20 
 src/amd/vulkan/radv_wsi.c   | 19 ---
 3 files changed, 16 insertions(+), 27 deletions(-)

diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
index d10ec99..0974df0 100644
--- a/src/amd/vulkan/radv_meta.h
+++ b/src/amd/vulkan/radv_meta.h
@@ -187,10 +187,6 @@ void radv_meta_resolve_fragment_image(struct 
radv_cmd_buffer *cmd_buffer,
  uint32_t region_count,
  const VkImageResolve *regions);
 
-void radv_blit_to_prime_linear(struct radv_cmd_buffer *cmd_buffer,
-  struct radv_image *image,
-  struct radv_image *linear_image);
-
 /* common nir builder helpers */
 #include "nir/nir_builder.h"
 
diff --git a/src/amd/vulkan/radv_meta_copy.c b/src/amd/vulkan/radv_meta_copy.c
index a42b15a..c3fe10e 100644
--- a/src/amd/vulkan/radv_meta_copy.c
+++ b/src/amd/vulkan/radv_meta_copy.c
@@ -432,23 +432,3 @@ void radv_CmdCopyImage(
meta_copy_image(cmd_buffer, src_image, dest_image,
regionCount, pRegions);
 }
-
-void radv_blit_to_prime_linear(struct radv_cmd_buffer *cmd_buffer,
-  struct radv_image *image,
-  struct radv_image *linear_image)
-{
-   struct VkImageCopy image_copy = { 0 };
-
-   image_copy.srcSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
-   image_copy.srcSubresource.layerCount = 1;
-
-   image_copy.dstSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
-   image_copy.dstSubresource.layerCount = 1;
-
-   image_copy.extent.width = image->info.width;
-   image_copy.extent.height = image->info.height;
-   image_copy.extent.depth = 1;
-
-   meta_copy_image(cmd_buffer, image, linear_image,
-   1, _copy);
-}
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 0145da6..7515284 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -233,6 +233,7 @@ radv_wsi_create_blit_cmd_buffer(VkDevice device_h,
uint32_t queue_family_index,
VkCommandPool *cmd_pool_p,
VkCommandBuffer *cmd_buffer_p,
+   const VkSwapchainCreateInfoKHR *pCreateInfo,
const VkAllocationCallbacks* pAllocator)
 {
VkResult result = VK_SUCCESS;
@@ -272,9 +273,20 @@ radv_wsi_create_blit_cmd_buffer(VkDevice device_h,
 
radv_BeginCommandBuffer(cmd_buffer_h, _info);
 
-   radv_blit_to_prime_linear(radv_cmd_buffer_from_handle(cmd_buffer_h),
- radv_image_from_handle(client_image_h),
- radv_image_from_handle(wsi_image_h));
+   struct VkImageCopy image_copy = { 0 };
+
+   image_copy.srcSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
+   image_copy.srcSubresource.layerCount = 1;
+
+   image_copy.dstSubresource.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
+   image_copy.dstSubresource.layerCount = 1;
+
+   image_copy.extent.width = pCreateInfo->imageExtent.width;
+   image_copy.extent.height = pCreateInfo->imageExtent.height;
+   image_copy.extent.depth = 1;
+
+   radv_CmdCopyImage(cmd_buffer_h, client_image_h, 0, wsi_image_h, 0,
+ 1, _copy);
 
radv_EndCommandBuffer(cmd_buffer_h);
 
@@ -370,6 +382,7 @@ radv_wsi_image_create(VkDevice device_h,
 q,
 
>blit_cmd_pools[q],
 
>blit_cmd_buffers[q],
+pCreateInfo,
 pAllocator);
if (result != VK_SUCCESS)
goto fail;
-- 
2.9.5

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

Re: [Mesa-dev] [PATCH v2] mesa/teximage: add TEXTURE_CUBE_MAP_ARRAY target for CompressedTexImage3D

[Nanley Chery]

On Wed, Nov 15, 2017 at 12:08:58PM -0500, Ilia Mirkin wrote:
> On Wed, Nov 15, 2017 at 11:54 AM, Juan A. Suarez Romero
>  wrote:
> > From section 8.7, page 179 of OpenGL ES 3.2 spec:
> >
> >   An INVALID_OPERATION error is generated by CompressedTexImage3D
> >   if internalformat is one of the the formats in table 8.17 and target
> >   is not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
> >
> >   An INVALID_OPERATION error is generated by CompressedTexImage3D if
> >   internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube Map Array”
> >   column of table 8.17 is not checked, or if internalformat is
> >   TEXTURE_3D and the “3D Tex.” column of table 8.17 is not checked.
> >
> > So far it was only considering TEXTURE_2D_ARRAY as valid target. But as
> > "Cube Map Array" column is checked for all the cases, in practice we can
> > consider also TEXTURE_CUBE_MAP_ARRAY.
> >
> > This fixes KHR-GLES32.core.texture_cube_map_array.etc2_texture
> > ---
> >  src/mesa/main/teximage.c | 25 +
> >  1 file changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> > index 4ec6148bf42..174731d0d8a 100644
> > --- a/src/mesa/main/teximage.c
> > +++ b/src/mesa/main/teximage.c
> > @@ -1403,17 +1403,26 @@ _mesa_target_can_be_compressed(const struct 
> > gl_context *ctx, GLenum target,
> > * have already been handled by normal ETC2/EAC behavior.
> > */
> >
> > -  /* From section 3.8.6, page 146 of OpenGL ES 3.0 spec:
> > +  /* From section 8.7, page 179 of OpenGL ES 3.2 spec:
> > *
> > -   *"The ETC2/EAC texture compression algorithm supports only
> > -   * two-dimensional images. If internalformat is an ETC2/EAC 
> > format,
> > -   * glCompressedTexImage3D will generate an INVALID_OPERATION 
> > error if
> > -   * target is not TEXTURE_2D_ARRAY."
> > +   *  An INVALID_OPERATION error is generated by 
> > CompressedTexImage3D
> > +   *  if internalformat is one of the the formats in table 8.17 
> > and target is
> > +   *  not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
> > *
> > -   * This should also be applicable for glTexStorage3D(). Other 
> > available
> > -   * targets for these functions are: TEXTURE_3D and 
> > TEXTURE_CUBE_MAP_ARRAY.
> > +   *  An INVALID_OPERATION error is generated by 
> > CompressedTexImage3D
> > +   *  if internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube Map
> > +   *  Array” column of table 8.17 is not checked, or if 
> > internalformat
> > +   *  is TEXTURE_- 3D and the “3D Tex.” column of table 8.17 is not
> > +   *  checked.
> > +   *
> > +   * The instances of  above should say .
> > +   *
> > +   * This should also be applicable for glTexStorage3D().
> > +   *
> > +   * Such table 8.17 has checked "Cube Map Array" column for all the
> > +   * cases. So in practice, TEXTURE_CUBE_MAP_ARRAY is now valid.
> > */

This deletes the comment describing the old OpenGL ES 3.0 behavior.

> > -  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx))
> > +  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx) && 
> > !_mesa_is_gles32(ctx))

Some of these lines look longer than 80 chars.

> 
> Perhaps this should be
> 
> !_mesa_has_OES_texture_cube_map_array(ctx)?
> 

I think you're right. It looks like OES_texture_cube_map_array was folded
into ES 3.2. I haven't done the comparison myself to confirm this
however.

> It's unclear from that spec though... perhaps ES 3.2 goes further and
> is required to be supported.
> 

If the OpenGL ES Wikipedia page is reliable, we should probably be checking for
this extension before exposing ES 3.2.

-Nanley

> >  return write_error(error, GL_INVALID_OPERATION);
> >target_can_be_compresed = _mesa_has_texture_cube_map_array(ctx);
> >break;
> > --
> > 2.13.6
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] vulkan/wsi: use function ptr definitions from the spec.

[Dave Airlie]

From: Dave Airlie 

This just seems cleaner, and we may expand this in future.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_wsi.c   | 3 ++-
 src/intel/vulkan/anv_wsi.c  | 3 ++-
 src/vulkan/wsi/wsi_common.h | 4 +---
 src/vulkan/wsi/wsi_common_wayland.c | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 7a9064b..0145da6 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -29,8 +29,9 @@
 #include "vk_util.h"
 #include "util/macros.h"
 
+#define WSI_CB(x) .x = radv_##x
 MAYBE_UNUSED static const struct wsi_callbacks wsi_cbs = {
-   .get_phys_device_format_properties = radv_GetPhysicalDeviceFormatProperties,
+   WSI_CB(GetPhysicalDeviceFormatProperties),
 };
 
 VkResult
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 363f70f..a8b01dc 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -27,8 +27,9 @@
 #include "vk_util.h"
 
 #ifdef VK_USE_PLATFORM_WAYLAND_KHR
+#define WSI_CB(x) .x = anv_##x
 static const struct wsi_callbacks wsi_cbs = {
-   .get_phys_device_format_properties = anv_GetPhysicalDeviceFormatProperties,
+   WSI_CB(GetPhysicalDeviceFormatProperties),
 };
 #endif
 
diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
index 3fa2631..7171de3 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -122,9 +122,7 @@ struct wsi_device {
 };
 
 struct wsi_callbacks {
-   void (*get_phys_device_format_properties)(VkPhysicalDevice physicalDevice,
- VkFormat format,
- VkFormatProperties 
*pFormatProperties);
+   PFN_vkGetPhysicalDeviceFormatProperties GetPhysicalDeviceFormatProperties;
 };
 
 #define WSI_DEFINE_NONDISP_HANDLE_CASTS(__wsi_type, __VkType)  \
diff --git a/src/vulkan/wsi/wsi_common_wayland.c 
b/src/vulkan/wsi/wsi_common_wayland.c
index 60e72fb..4df5bb8 100644
--- a/src/vulkan/wsi/wsi_common_wayland.c
+++ b/src/vulkan/wsi/wsi_common_wayland.c
@@ -84,7 +84,7 @@ wsi_wl_display_add_vk_format(struct wsi_wl_display *display, 
VkFormat format)
/* Don't add formats that aren't renderable. */
VkFormatProperties props;
 
-   
display->wsi_wl->cbs->get_phys_device_format_properties(display->wsi_wl->physical_device,
+   
display->wsi_wl->cbs->GetPhysicalDeviceFormatProperties(display->wsi_wl->physical_device,
format, );
if (!(props.optimalTilingFeatures & VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT))
   return;
-- 
2.9.5

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

Re: [Mesa-dev] [PATCH 3/3] RFC: vulkan/wsi: Rework the way prime support works

[Dave Airlie]

On 15 November 2017 at 04:40, Jason Ekstrand  wrote:
> This commit significantly reworks the way prime support works and lets
> us pull it even further into radv.  The old mechanism required the
> specific WSI layer to be aware of the linear shadow copy that has to be
> done in order for prime to work.  In the new paradigm, we better define
> what bits of wsi_image go to the client and what bits go off to the
> window system.  It's then the job of the driver to allocate two separate
> images and stash whatever intermediates it needs in driver_private.
> There are a few advantages to this method:
>
>  1) It separates supporting prime from the driver decision as to whether
> it's better to render directly into the window-system-compatible
> image or if it's better to blit.
>
>  2) Because of this separation, it's now possible for a driver to use a
> different scheme for WSI image presentation where it hooks the
> vkCmdPipelineBarrier that transitions the image to
> VK_IMAGE_LAYOUT_PRESENT_SRC_KHR and does the blit there.
>
>  3) It lets us pull more of the details into radv and, in my opinion,
> actually makes the radv code more straightforward.

For the record, PRIME is not radv specific, stop trying to make it so,
anv should support display to other GPUs.

I've tested these patches work and I'm only acking them because nobody
seems to be listening to my objections.

Unhappily-acked-by: Dave Airlie 
Tested-by: Dave Airlie 

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

Re: [Mesa-dev] [PATCH v2 4/5] etnaviv: Flush TS cache before changing TS configuration

[Christian Gmeiner]

2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> This is to make sure that the TS is properly flushed to memory before
> rendering to a new surface starts.
>
> Signed-off-by: Wladimir J. van der Laan 

Reviewed-by: Christian Gmeiner 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_emit.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> index d313af6..b6b06e3 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> @@ -322,6 +322,11 @@ etna_emit_state(struct etna_context *ctx)
>etna_stall(stream, SYNC_RECIPIENT_RA, SYNC_RECIPIENT_PE);
> }
>
> +   /* Flush TS cache before changing TS configuration. */
> +   if (unlikely(dirty & ETNA_DIRTY_TS)) {
> +  etna_set_state(stream, VIVS_TS_FLUSH_CACHE, VIVS_TS_FLUSH_CACHE_FLUSH);
> +   }
> +
> /* If MULTI_SAMPLE_CONFIG.MSAA_SAMPLES changed, clobber affected shader
>  * state to make sure it is always rewritten. */
> if (unlikely(dirty & (ETNA_DIRTY_FRAMEBUFFER))) {
> --
> 2.7.4
>



-- 
greets
--
Christian Gmeiner, MSc

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

Re: [Mesa-dev] [PATCH v2 3/5] etnaviv: Add TS_SAMPLER formats to etnaviv_format

[Christian Gmeiner]

2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> Sampler TS introduces yet another format enumeration for
> renderable+textureable formats. Introduce it into the etnaviv_format
> table as another column.
>
> Signed-off-by: Wladimir J. van der Laan 

Reviewed-by: Christian Gmeiner 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_format.c | 162 
> +++
>  src/gallium/drivers/etnaviv/etnaviv_format.h |   3 +
>  2 files changed, 91 insertions(+), 74 deletions(-)
>
> I changed this to add a new column to the table for the TS format (for all
> texturable formats) instead of a trick based on RS format and name as used
> before, as that didn't cover depth formats correctly.
>
> (did not add Christian Gmeiner's reviewed-by as the patch changed 100%)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.c 
> b/src/gallium/drivers/etnaviv/etnaviv_format.c
> index 3dd212f..7943c81 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_format.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_format.c
> @@ -40,6 +40,7 @@ struct etna_format {
> unsigned vtx;
> unsigned tex;
> unsigned rs;
> +   unsigned ts;
> boolean present;
> const unsigned char tex_swiz[4];
>  };
> @@ -53,6 +54,8 @@ struct etna_format {
>  #define RS_FORMAT_X8B8G8R8(RS_FORMAT_X8R8G8B8 | RS_FORMAT_RB_SWAP)
>  #define RS_FORMAT_A8B8G8R8(RS_FORMAT_A8R8G8B8 | RS_FORMAT_RB_SWAP)
>
> +#define TS_SAMPLER_FORMAT_NONE  ETNA_NO_MATCH
> +
>  #define SWIZ(x,y,z,w) {\
> PIPE_SWIZZLE_##x,   \
> PIPE_SWIZZLE_##y,   \
> @@ -61,21 +64,23 @@ struct etna_format {
>  }
>
>  /* vertex + texture */
> -#define VT(pipe, vtxfmt, texfmt, texswiz, rsfmt)  \
> +#define VT(pipe, vtxfmt, texfmt, texswiz, rsfmt, tsfmt)  \
> [PIPE_FORMAT_##pipe] = {   \
>.vtx = FE_DATA_TYPE_##vtxfmt, \
>.tex = TEXTURE_FORMAT_##texfmt, \
>.rs = RS_FORMAT_##rsfmt,\
> +  .ts = TS_SAMPLER_FORMAT_##tsfmt,\
>.present = 1,   \
>.tex_swiz = texswiz,\
> }
>
>  /* texture-only */
> -#define _T(pipe, fmt, swiz, rsfmt) \
> +#define _T(pipe, fmt, swiz, rsfmt, tsfmt) \
> [PIPE_FORMAT_##pipe] = {\
>.vtx = ETNA_NO_MATCH,\
>.tex = TEXTURE_FORMAT_##fmt, \
>.rs = RS_FORMAT_##rsfmt, \
> +  .ts = TS_SAMPLER_FORMAT_##tsfmt, \
>.present = 1,\
>.tex_swiz = swiz,\
> }
> @@ -91,16 +96,16 @@ struct etna_format {
>
>  static struct etna_format formats[PIPE_FORMAT_COUNT] = {
> /* 8-bit */
> -   VT(R8_UNORM,   UNSIGNED_BYTE, L8, SWIZ(X, 0, 0, 1), NONE),
> +   VT(R8_UNORM,   UNSIGNED_BYTE, L8, SWIZ(X, 0, 0, 1), NONE, NONE),
> V_(R8_SNORM,   BYTE,  NONE),
> V_(R8_UINT,UNSIGNED_BYTE, NONE),
> V_(R8_SINT,BYTE,  NONE),
> V_(R8_USCALED, UNSIGNED_BYTE, NONE),
> V_(R8_SSCALED, BYTE,  NONE),
>
> -   _T(A8_UNORM, A8, SWIZ(X, Y, Z, W), NONE),
> -   _T(L8_UNORM, L8, SWIZ(X, Y, Z, W), NONE),
> -   _T(I8_UNORM, I8, SWIZ(X, Y, Z, W), NONE),
> +   _T(A8_UNORM, A8, SWIZ(X, Y, Z, W), NONE, NONE),
> +   _T(L8_UNORM, L8, SWIZ(X, Y, Z, W), NONE, NONE),
> +   _T(I8_UNORM, I8, SWIZ(X, Y, Z, W), NONE, NONE),
>
> /* 16-bit */
> V_(R16_UNORM,   UNSIGNED_SHORT, NONE),
> @@ -111,17 +116,17 @@ static struct etna_format formats[PIPE_FORMAT_COUNT] = {
> V_(R16_SSCALED, SHORT,  NONE),
> V_(R16_FLOAT,   HALF_FLOAT, NONE),
>
> -   _T(B4G4R4A4_UNORM, A4R4G4B4, SWIZ(X, Y, Z, W), A4R4G4B4),
> -   _T(B4G4R4X4_UNORM, X4R4G4B4, SWIZ(X, Y, Z, W), X4R4G4B4),
> +   _T(B4G4R4A4_UNORM, A4R4G4B4, SWIZ(X, Y, Z, W), A4R4G4B4, A4R4G4B4),
> +   _T(B4G4R4X4_UNORM, X4R4G4B4, SWIZ(X, Y, Z, W), X4R4G4B4, A4R4G4B4),
>
> -   _T(L8A8_UNORM, A8L8, SWIZ(X, Y, Z, W), NONE),
> +   _T(L8A8_UNORM, A8L8, SWIZ(X, Y, Z, W), NONE, NONE),
>
> -   _T(Z16_UNORM,  D16,  SWIZ(X, Y, Z, W), A4R4G4B4),
> -   _T(B5G6R5_UNORM,   R5G6B5,   SWIZ(X, Y, Z, W), R5G6B5),
> -   _T(B5G5R5A1_UNORM, A1R5G5B5, SWIZ(X, Y, Z, W), A1R5G5B5),
> -   _T(B5G5R5X1_UNORM, X1R5G5B5, SWIZ(X, Y, Z, W), X1R5G5B5),
> +   _T(Z16_UNORM,  D16,  SWIZ(X, Y, Z, W), A4R4G4B4, D16),
> +   _T(B5G6R5_UNORM,   R5G6B5,   SWIZ(X, Y, Z, W), R5G6B5, R5G6B5),
> +   _T(B5G5R5A1_UNORM, A1R5G5B5, SWIZ(X, Y, Z, W), A1R5G5B5, A1R5G5B5),
> +   _T(B5G5R5X1_UNORM, X1R5G5B5, SWIZ(X, Y, Z, W), X1R5G5B5, A1R5G5B5),
>
> -   VT(R8G8_UNORM,   UNSIGNED_BYTE,  EXT_G8R8 | EXT_FORMAT, SWIZ(X, Y, 0, 1), 
> NONE),
> +   VT(R8G8_UNORM,   UNSIGNED_BYTE,  EXT_G8R8 | EXT_FORMAT, SWIZ(X, Y, 0, 1), 
> NONE, NONE),
> V_(R8G8_SNORM,   BYTE,   NONE),
> V_(R8G8_UINT,UNSIGNED_BYTE,  NONE),
> V_(R8G8_SINT,BYTE,   NONE),
> @@ -156,26 +161,26 @@ static struct etna_format 

Re: [Mesa-dev] [PATCH v2 2/5] etnaviv: Check that resource has a valid TS in etna_resource_needs_flush

[Christian Gmeiner]

2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> Resources only need a resolve-to-itself if their TS is valid for any
> level, not just if it happens to be allocated.
>
> Signed-off-by: Wladimir J. van der Laan 

Reviewed-by: Christian Gmeiner 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 13 +
>  src/gallium/drivers/etnaviv/etnaviv_resource.h |  6 +-
>  2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 0a82807..1fb73c4 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -629,6 +629,19 @@ etna_resource_used(struct etna_context *ctx, struct 
> pipe_resource *prsc,
> rsc->pending_ctx = ctx;
>  }
>
> +bool
> +etna_resource_has_valid_ts(struct etna_resource *rsc)
> +{
> +   if (!rsc->ts_bo)
> +  return false;
> +
> +   for (int level = 0; level <= rsc->base.last_level; level++)
> +  if (rsc->levels[level].ts_valid)
> + return true;
> +
> +   return false;
> +}
> +
>  void
>  etna_resource_screen_init(struct pipe_screen *pscreen)
>  {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 0b135e2..11ccf8f 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -103,11 +103,15 @@ etna_resource_older(struct etna_resource *a, struct 
> etna_resource *b)
> return (int)(a->seqno - b->seqno) < 0;
>  }
>
> +/* returns TRUE if a resource has a TS, and it is valid for at least one 
> level */
> +bool
> +etna_resource_has_valid_ts(struct etna_resource *res);
> +
>  /* returns TRUE if the resource needs a resolve to itself */
>  static inline bool
>  etna_resource_needs_flush(struct etna_resource *res)
>  {
> -   return res->ts_bo && ((int)(res->seqno - res->flush_seqno) > 0);
> +   return etna_resource_has_valid_ts(res) && ((int)(res->seqno - 
> res->flush_seqno) > 0);
>  }
>
>  /* is the resource only used on the sampler? */
> --
> 2.7.4
>



-- 
greets
--
Christian Gmeiner, MSc

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

[Mesa-dev] [Bug 100151] Front buffer drawing mode shows black window with gallium software rasterizers

[bugzilla-daemon]

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

--- Comment #12 from Pradeep Yadav  ---
As I mentioned while filing this defect that Mesa's classic software rasterizer
has no such black window issue. So we have potential temporary solution for our
customers who are using older Linux versions.

So for a CentOS version, like 6.x, I downloaded Mesa 13.0.5 sources and built
swrast_dri.so (the classic software rasterizer) and it works (Need to set
LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH to swrast_dri.so path).

But our customers/users cannot build Mesa on their systems. They don't have the
expertise and sometimes their IT support are also not willing to do so.

We cannot provide a pre-built swrast_dri.so to them as it might be incompatible
with the other libraries (dependencies) on customer's system. For example a
customer may be facing this issue on their CentOS 7.x system and if we provide
Mesa 13.0.5 swrast_dri.so, then it might not work.

My questions:

- Is there a way (probably like an environment variable) to activate Mesa's
classic software rasterizer?

- Do we have a documentation of which Mesa version is compatible with which
Linux kernel version?

- On installing CentOS version V, a Mesa version M is installed. How and who
decides Mesa version M corresponding to CentOS version V?

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

Re: [Mesa-dev] [PATCH v3] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

[Eric Engestrom]

On Wednesday, 2017-11-15 20:59:18 +, Nicolai Hähnle wrote:
> From: Nicolai Hähnle 
> 
> Tested with Travis and Appveyor.
> 
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
> v3: use check_functions in Scons (Eric)
> 
> Cc: Rob Herring 
> Cc: Alexander von Gluck IV 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
> Fixes: f1a364878431 ("threads: update for late C11 changes")
> Reviewed-by: Eric Engestrom  (v2)

You can update that r-b to apply to this revision too :)

> Reviewed-by: Dylan Baker  (v2)
> Reviewed-by: Jon Turney  (v2)
> ---
>  configure.ac| 1 +
>  include/c11/threads_posix.h | 2 +-
>  meson.build | 2 +-
>  scons/gallium.py| 3 +++
>  4 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 411c4f6b3e0..a7ae920ab9c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -841,20 +841,21 @@ if test "x$enable_asm" = xyes; then
>  AC_MSG_RESULT([no, platform not supported])
>  ;;
>  esac
>  fi
>  
>  AC_HEADER_MAJOR
>  AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
>  AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
>  AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
>  AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
> +AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
>  
>  AC_MSG_CHECKING([whether strtod has locale support])
>  AC_LINK_IFELSE([AC_LANG_SOURCE([[
>  #define _GNU_SOURCE
>  #include 
>  #include 
>  #ifdef HAVE_XLOCALE_H
>  #include 
>  #endif
>  int main() {
> diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
> index 7bf6a0f6ef6..45cb6075e6e 100644
> --- a/include/c11/threads_posix.h
> +++ b/include/c11/threads_posix.h
> @@ -375,21 +375,21 @@ tss_get(tss_t key)
>  // 7.25.6.4
>  static inline int
>  tss_set(tss_t key, void *val)
>  {
>  return (pthread_setspecific(key, val) == 0) ? thrd_success : thrd_error;
>  }
>  
>  
>  /* 7.25.7 Time functions */
>  // 7.25.6.1
> -#if 0
> +#ifndef HAVE_TIMESPEC_GET
>  static inline int
>  timespec_get(struct timespec *ts, int base)
>  {
>  if (!ts) return 0;
>  if (base == TIME_UTC) {
>  clock_gettime(CLOCK_REALTIME, ts);
>  return base;
>  }
>  return 0;
>  }
> diff --git a/meson.build b/meson.build
> index 314d15ac461..25a5cd658d1 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -527,21 +527,21 @@ if cc.has_header_symbol('sys/sysmacros.h', 'major')
>  elif cc.has_header_symbol('sys/mkdev.h', 'major')
>pre_args += '-DMAJOR_IN_MKDEV'
>  endif
>  
>  foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h']
>if cc.has_header(h)
>  pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
>endif
>  endforeach
>  
> -foreach f : ['strtof', 'mkostemp', 'posix_memalign']
> +foreach f : ['strtof', 'mkostemp', 'posix_memalign', 'timespec_get']
>if cc.has_function(f)
>  pre_args += '-DHAVE_@0@'.format(f.to_upper())
>endif
>  endforeach
>  
>  # strtod locale support
>  if cc.links('''
>  #define _GNU_SOURCE
>  #include 
>  #include 
> diff --git a/scons/gallium.py b/scons/gallium.py
> index 94022df1808..ef3b2ee81ae 100755
> --- a/scons/gallium.py
> +++ b/scons/gallium.py
> @@ -348,20 +348,23 @@ def generate(env):
>  'GLX_DIRECT_RENDERING',
>  'GLX_INDIRECT_RENDERING',
>  ]
>  
>  if check_header(env, 'xlocale.h'):
>  cppdefines += ['HAVE_XLOCALE_H']
>  
>  if check_functions(env, ['strtod_l', 'strtof_l']):
>  cppdefines += ['HAVE_STRTOD_L']
>  
> +if check_functions(env, ['timespec_get']):
> +cppdefines += ['HAVE_TIMESPEC_GET']
> +
>  if platform == 'windows':
>  cppdefines += [
>  'WIN32',
>  '_WINDOWS',
>  #'_UNICODE',
>  #'UNICODE',
>  # http://msdn.microsoft.com/en-us/library/aa383745.aspx
>  ('_WIN32_WINNT', '0x0601'),
>  ('WINVER', '0x0601'),
>  ]
> -- 
> 2.11.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: Listen to BRW_NEW_*_PROGRAM in L3 state atom.

[Kenneth Graunke]

This looks at prog->*.  You don't get to do that unless you listen to
BRW_NEW_*_PROGRAM, which is a superset of the cases where
BRW_NEW_*_PROG_DATA is flagged.
---
 src/mesa/drivers/dri/i965/gen7_l3_state.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c 
b/src/mesa/drivers/dri/i965/gen7_l3_state.c
index 8c8f4169e7e..7044d5a8984 100644
--- a/src/mesa/drivers/dri/i965/gen7_l3_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_l3_state.c
@@ -255,11 +255,16 @@ const struct brw_tracked_state gen7_l3_state = {
   .mesa = 0,
   .brw = BRW_NEW_BATCH |
  BRW_NEW_BLORP |
+ BRW_NEW_COMPUTE_PROGRAM |
  BRW_NEW_CS_PROG_DATA |
+ BRW_NEW_FRAGMENT_PROGRAM |
  BRW_NEW_FS_PROG_DATA |
+ BRW_NEW_GEOMETRY_PROGRAM |
  BRW_NEW_GS_PROG_DATA |
+ BRW_NEW_TESS_PROGRAMS |
  BRW_NEW_TCS_PROG_DATA |
  BRW_NEW_TES_PROG_DATA |
+ BRW_NEW_VERTEX_PROGRAM |
  BRW_NEW_VS_PROG_DATA,
},
.emit = emit_l3_state
-- 
2.15.0

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

Re: [Mesa-dev] [PATCH v3] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

[Dylan Baker]

This should make scons work correctly on every platform, so:
Reviewed-by: Dylan Baker 

Quoting Nicolai Hähnle (2017-11-15 12:58:12)
> From: Nicolai Hähnle 
> 
> Tested with Travis and Appveyor.
> 
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
> v3: use check_functions in Scons (Eric)
> 
> Cc: Rob Herring 
> Cc: Alexander von Gluck IV 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
> Fixes: f1a364878431 ("threads: update for late C11 changes")
> Reviewed-by: Eric Engestrom  (v2)
> Reviewed-by: Dylan Baker  (v2)
> Reviewed-by: Jon Turney  (v2)
> ---
>  configure.ac| 1 +
>  include/c11/threads_posix.h | 2 +-
>  meson.build | 2 +-
>  scons/gallium.py| 3 +++
>  4 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 411c4f6b3e0..a7ae920ab9c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -841,20 +841,21 @@ if test "x$enable_asm" = xyes; then
>  AC_MSG_RESULT([no, platform not supported])
>  ;;
>  esac
>  fi
>  
>  AC_HEADER_MAJOR
>  AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
>  AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
>  AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
>  AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
> +AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
>  
>  AC_MSG_CHECKING([whether strtod has locale support])
>  AC_LINK_IFELSE([AC_LANG_SOURCE([[
>  #define _GNU_SOURCE
>  #include 
>  #include 
>  #ifdef HAVE_XLOCALE_H
>  #include 
>  #endif
>  int main() {
> diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
> index 7bf6a0f6ef6..45cb6075e6e 100644
> --- a/include/c11/threads_posix.h
> +++ b/include/c11/threads_posix.h
> @@ -375,21 +375,21 @@ tss_get(tss_t key)
>  // 7.25.6.4
>  static inline int
>  tss_set(tss_t key, void *val)
>  {
>  return (pthread_setspecific(key, val) == 0) ? thrd_success : thrd_error;
>  }
>  
>  
>  /* 7.25.7 Time functions */
>  // 7.25.6.1
> -#if 0
> +#ifndef HAVE_TIMESPEC_GET
>  static inline int
>  timespec_get(struct timespec *ts, int base)
>  {
>  if (!ts) return 0;
>  if (base == TIME_UTC) {
>  clock_gettime(CLOCK_REALTIME, ts);
>  return base;
>  }
>  return 0;
>  }
> diff --git a/meson.build b/meson.build
> index 314d15ac461..25a5cd658d1 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -527,21 +527,21 @@ if cc.has_header_symbol('sys/sysmacros.h', 'major')
>  elif cc.has_header_symbol('sys/mkdev.h', 'major')
>pre_args += '-DMAJOR_IN_MKDEV'
>  endif
>  
>  foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h']
>if cc.has_header(h)
>  pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
>endif
>  endforeach
>  
> -foreach f : ['strtof', 'mkostemp', 'posix_memalign']
> +foreach f : ['strtof', 'mkostemp', 'posix_memalign', 'timespec_get']
>if cc.has_function(f)
>  pre_args += '-DHAVE_@0@'.format(f.to_upper())
>endif
>  endforeach
>  
>  # strtod locale support
>  if cc.links('''
>  #define _GNU_SOURCE
>  #include 
>  #include 
> diff --git a/scons/gallium.py b/scons/gallium.py
> index 94022df1808..ef3b2ee81ae 100755
> --- a/scons/gallium.py
> +++ b/scons/gallium.py
> @@ -348,20 +348,23 @@ def generate(env):
>  'GLX_DIRECT_RENDERING',
>  'GLX_INDIRECT_RENDERING',
>  ]
>  
>  if check_header(env, 'xlocale.h'):
>  cppdefines += ['HAVE_XLOCALE_H']
>  
>  if check_functions(env, ['strtod_l', 'strtof_l']):
>  cppdefines += ['HAVE_STRTOD_L']
>  
> +if check_functions(env, ['timespec_get']):
> +cppdefines += ['HAVE_TIMESPEC_GET']
> +
>  if platform == 'windows':
>  cppdefines += [
>  'WIN32',
>  '_WINDOWS',
>  #'_UNICODE',
>  #'UNICODE',
>  # http://msdn.microsoft.com/en-us/library/aa383745.aspx
>  ('_WIN32_WINNT', '0x0601'),
>  ('WINVER', '0x0601'),
>  ]
> -- 
> 2.11.0
> 
> ___
> 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 2/2] egl: drop EGL driver `name`

[Eric Engestrom]

On Wednesday, 2017-11-15 16:51:29 +, Kai Wasserbäch wrote:
> I'm still good with this, thanks for reapplying!

To be clear, is that an ack, or an r-b? :P

> 
> Eric Engestrom wrote on 14.11.2017 18:26:
> > This is a revert of Marek's 2cb9ab53dd3ae6850a26 revert.
> > It was needed to revert the previous commit, and didn't have any issue
> > itself.
> > --
> > 
> > The "DRI2" name was reported as confusing when printing EGL infos (one
> > user reported thinking DRI3 was not working on his X server), and the
> > only alternative is Haiku, which can only be used on a Haiku machine.
> > 
> > The name therefore doesn't add any information that the user wouldn't
> > know already, so let's just drop it.
> > 
> > Cc: Kai Wasserbäch 
> > Suggested-by: Emil Velikov 
> > Related-to: b174a1ae720cb404738c ("egl: Simplify the "driver" interface")
> > Signed-off-by: Eric Engestrom 
> > ---
> >  src/egl/drivers/dri2/egl_dri2.c | 2 --
> >  src/egl/drivers/haiku/egl_haiku.cpp | 2 --
> >  src/egl/main/eglapi.c   | 3 +--
> >  src/egl/main/egldriver.c| 2 --
> >  src/egl/main/egldriver.h| 2 --
> >  5 files changed, 1 insertion(+), 10 deletions(-)
> > 
> > diff --git a/src/egl/drivers/dri2/egl_dri2.c 
> > b/src/egl/drivers/dri2/egl_dri2.c
> > index 7c63920c54624e0e674e..3dce5f82320b2465037a 100644
> > --- a/src/egl/drivers/dri2/egl_dri2.c
> > +++ b/src/egl/drivers/dri2/egl_dri2.c
> > @@ -3269,6 +3269,4 @@ _eglInitDriver(_EGLDriver *dri2_drv)
> > dri2_drv->API.GLInteropQueryDeviceInfo = dri2_interop_query_device_info;
> > dri2_drv->API.GLInteropExportObject = dri2_interop_export_object;
> > dri2_drv->API.DupNativeFenceFDANDROID = dri2_dup_native_fence_fd;
> > -
> > -   dri2_drv->Name = "DRI2";
> >  }
> > diff --git a/src/egl/drivers/haiku/egl_haiku.cpp 
> > b/src/egl/drivers/haiku/egl_haiku.cpp
> > index 590e43f00fb96b051fb4..0b56653395a94ac1f303 100644
> > --- a/src/egl/drivers/haiku/egl_haiku.cpp
> > +++ b/src/egl/drivers/haiku/egl_haiku.cpp
> > @@ -325,7 +325,5 @@ _eglInitDriver(_EGLDriver *driver)
> >  
> > driver->API.SwapBuffers = haiku_swap_buffers;
> >  
> > -   driver->Name = "Haiku";
> > -
> > TRACE("API Calls defined\n");
> >  }
> > diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> > index c1bf5bbfe19b3172429e..306db209cd94748f048f 100644
> > --- a/src/egl/main/eglapi.c
> > +++ b/src/egl/main/eglapi.c
> > @@ -619,8 +619,7 @@ eglInitialize(EGLDisplay dpy, EGLint *major, EGLint 
> > *minor)
> >_eglCreateExtensionsString(disp);
> >_eglCreateAPIsString(disp);
> >snprintf(disp->VersionString, sizeof(disp->VersionString),
> > -   "%d.%d (%s)", disp->Version / 10, disp->Version % 10,
> > -   disp->Driver->Name);
> > +   "%d.%d", disp->Version / 10, disp->Version % 10);
> > }
> >  
> > /* Update applications version of major and minor if not NULL */
> > diff --git a/src/egl/main/egldriver.c b/src/egl/main/egldriver.c
> > index 71bfca21ed8c6a666c14..f1973bde274ec768c4cf 100644
> > --- a/src/egl/main/egldriver.c
> > +++ b/src/egl/main/egldriver.c
> > @@ -99,8 +99,6 @@ _eglMatchDriver(_EGLDisplay *dpy)
> > }
> >  
> > if (best_drv) {
> > -  _eglLog(_EGL_DEBUG, "the best driver is %s",
> > -best_drv->Name);
> >dpy->Driver = best_drv;
> >dpy->Initialized = EGL_TRUE;
> > }
> > diff --git a/src/egl/main/egldriver.h b/src/egl/main/egldriver.h
> > index ba12a060cab7f7c6c223..5695fc06ffb03102cc64 100644
> > --- a/src/egl/main/egldriver.h
> > +++ b/src/egl/main/egldriver.h
> > @@ -75,8 +75,6 @@ extern "C" {
> >   */
> >  struct _egl_driver
> >  {
> > -   const char *Name;  /**< name of this driver */
> > -
> > _EGLAPI API;  /**< EGL API dispatch table */
> >  };
> >  
> > 
> 
> -- 
> 
> Kai Wasserbäch (Kai Wasserbaech)
> 
> E-Mail: k...@dev.carbon-project.org
> 

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

[Mesa-dev] [PATCH v3] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

[Nicolai Hähnle]

From: Nicolai Hähnle 

Tested with Travis and Appveyor.

v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
v3: use check_functions in Scons (Eric)

Cc: Rob Herring 
Cc: Alexander von Gluck IV 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11 changes")
Reviewed-by: Eric Engestrom  (v2)
Reviewed-by: Dylan Baker  (v2)
Reviewed-by: Jon Turney  (v2)
---
 configure.ac| 1 +
 include/c11/threads_posix.h | 2 +-
 meson.build | 2 +-
 scons/gallium.py| 3 +++
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 411c4f6b3e0..a7ae920ab9c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -841,20 +841,21 @@ if test "x$enable_asm" = xyes; then
 AC_MSG_RESULT([no, platform not supported])
 ;;
 esac
 fi
 
 AC_HEADER_MAJOR
 AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
 AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
 AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
 AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
+AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
 
 AC_MSG_CHECKING([whether strtod has locale support])
 AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #define _GNU_SOURCE
 #include 
 #include 
 #ifdef HAVE_XLOCALE_H
 #include 
 #endif
 int main() {
diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
index 7bf6a0f6ef6..45cb6075e6e 100644
--- a/include/c11/threads_posix.h
+++ b/include/c11/threads_posix.h
@@ -375,21 +375,21 @@ tss_get(tss_t key)
 // 7.25.6.4
 static inline int
 tss_set(tss_t key, void *val)
 {
 return (pthread_setspecific(key, val) == 0) ? thrd_success : thrd_error;
 }
 
 
 /* 7.25.7 Time functions */
 // 7.25.6.1
-#if 0
+#ifndef HAVE_TIMESPEC_GET
 static inline int
 timespec_get(struct timespec *ts, int base)
 {
 if (!ts) return 0;
 if (base == TIME_UTC) {
 clock_gettime(CLOCK_REALTIME, ts);
 return base;
 }
 return 0;
 }
diff --git a/meson.build b/meson.build
index 314d15ac461..25a5cd658d1 100644
--- a/meson.build
+++ b/meson.build
@@ -527,21 +527,21 @@ if cc.has_header_symbol('sys/sysmacros.h', 'major')
 elif cc.has_header_symbol('sys/mkdev.h', 'major')
   pre_args += '-DMAJOR_IN_MKDEV'
 endif
 
 foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h']
   if cc.has_header(h)
 pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
   endif
 endforeach
 
-foreach f : ['strtof', 'mkostemp', 'posix_memalign']
+foreach f : ['strtof', 'mkostemp', 'posix_memalign', 'timespec_get']
   if cc.has_function(f)
 pre_args += '-DHAVE_@0@'.format(f.to_upper())
   endif
 endforeach
 
 # strtod locale support
 if cc.links('''
 #define _GNU_SOURCE
 #include 
 #include 
diff --git a/scons/gallium.py b/scons/gallium.py
index 94022df1808..ef3b2ee81ae 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -348,20 +348,23 @@ def generate(env):
 'GLX_DIRECT_RENDERING',
 'GLX_INDIRECT_RENDERING',
 ]
 
 if check_header(env, 'xlocale.h'):
 cppdefines += ['HAVE_XLOCALE_H']
 
 if check_functions(env, ['strtod_l', 'strtof_l']):
 cppdefines += ['HAVE_STRTOD_L']
 
+if check_functions(env, ['timespec_get']):
+cppdefines += ['HAVE_TIMESPEC_GET']
+
 if platform == 'windows':
 cppdefines += [
 'WIN32',
 '_WINDOWS',
 #'_UNICODE',
 #'UNICODE',
 # http://msdn.microsoft.com/en-us/library/aa383745.aspx
 ('_WIN32_WINNT', '0x0601'),
 ('WINVER', '0x0601'),
 ]
-- 
2.11.0

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

[Mesa-dev] Driver testing system for Steam games

[Pierre-Loup A. Griffais]

Hi Mesa-Devel,

Today we're happy to announce that we're making the LunarG driver
testing system available to the Mesa development community. We've been
using this system internally for quite some time, but we've recently
done some more work so the results could also be publicly available for
the community to track regressions, and for developers to be able to
submit their branches for pre-submit testing.

The LunarG test system is a service that provides regular regression
testing on Mesa releases for Intel and AMD OpenGL graphics drivers. It
also enables users to test their own Mesa builds and compare results to
LunarG baselines, LunarG test runs, or user test runs. The objective of
the LunarG test system service for Mesa is to identify regressions in
performance or rendering for Mesa releases and developer's branches that
would negatively impact the gaming experience.

The test suite is a collection of trace files created from hundreds of
Linux OpenGL games from Steam. These trace files are used to automate
testing of rendering correctness as well as game performance. There are
currently 6 graphics platforms available for test (3 configurations each
of Intel and AMD graphics). The full suite of games typically runs
overnight with results posted the next day.

To access the test system and browse results: https://share.lunarg.com 
(click on "Test System") on the left.


Here's an example of a test report that a Mesa bug could possibly be 
filed from after inspection: https://imgur.com/a/cBonz


To learn more about how the test system works, read the short user
manual: https://share.lunarg.com/test/manual

Let us know if you have any feedback or questions. Vulkan support is
planned for the future, but not ready quite yet.

Thanks,
  - Pierre-Loup

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

Re: [Mesa-dev] [PATCH] amd: build addrlib with C++11

[Dylan Baker]

Quoting Ilia Mirkin (2017-11-15 09:52:06)
> On Wed, Nov 15, 2017 at 12:47 PM, Dylan Baker  wrote:
> > Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
> > cannot be built without it (Because of LLVM). As far as I can tell the GLSL
> > compiler and the Intel Compiler are the only C++ code in mesa not using 
> > C++11.
> 
> Actually C++11 isn't used anywhere except clover and swr, AFAIK. (Look
> for CXX11_CXXFLAGS.)
> 
>   -ilia

I should have added the Nouveau compiler to the list of code that doesn't
require C++11, sorry about that :)

However, LLVM has been built with C++11 since at least 4.0, and anything linking
to it (r300, r600, radeonsi, radv, llvmpipe) have to be built with it even if
they don't use C++11 features, because LLVM does. I think we mostly get around
this because autotools doesn't set a standard (by default), and clang++ and g++
have had C++11 as the default standard for quite a while now (at least back to
gcc 4.8).

For giggles I tried to build just llvmpipe with the C++ standard set to c++03
and I got a massive pile of syntax errors from the compiler.

If you want to try that with meson you could run:
sed -i -e 's@c++11@c++03@g' meson.build
meson build-cpp03 -Dgallium-drivers=swrast -Ddri-drivers= -Dvulkan-drivers=

Dylan


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

Re: [Mesa-dev] [PATCH] tgsi/exec: fix LDEXP in softpipe

[Brian Paul]

Reviewed-by: Brian Paul 


On 11/15/2017 11:35 AM, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

Bugzilla: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D103128=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=xmgFaDIVj7aLD3q4rCR_QYavBqvQH6DsYgtLGUXvpcQ=reW4GkhIDPr33R7C6PMnrgFtF-JCGUQl6oc89AqDDM4=
Fixes: cad959d90145 ("gallium: add LDEXP TGSI instruction and corresponding 
cap")
---
  src/gallium/auxiliary/tgsi/tgsi_exec.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index afed96c9b1d..793c0da39ab 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -5123,21 +5123,21 @@ exec_instruction(

 case TGSI_OPCODE_LG2:
exec_scalar_unary(mach, inst, micro_lg2, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
break;

 case TGSI_OPCODE_POW:
exec_scalar_binary(mach, inst, micro_pow, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
break;

 case TGSI_OPCODE_LDEXP:
-  exec_scalar_binary(mach, inst, micro_ldexp, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_INT);
+  exec_vector_binary(mach, inst, micro_ldexp, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
break;

 case TGSI_OPCODE_COS:
exec_scalar_unary(mach, inst, micro_cos, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
break;

 case TGSI_OPCODE_DDX:
exec_vector_unary(mach, inst, micro_ddx, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
break;




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

Re: [Mesa-dev] [PATCH 02/13] i965: remove ARB_compute_shader extension override

[Emil Velikov]

On 15 November 2017 at 19:30, Jordan Justen  wrote:
> On 2017-11-14 07:37:27, Emil Velikov wrote:
>> On 10 November 2017 at 23:39, Jordan Justen  
>> wrote:
>> > On 2017-11-10 08:19:38, Emil Velikov wrote:
>> >> On 7 November 2017 at 11:54, Emil Velikov  
>> >> wrote:
>> >> > From: Emil Velikov 
>> >> >
>> >> > Checking the override was useful in the early stages of developing the
>> >> > extension.
>> >> >
>> >> > Now that everything is wired, where possible, we can drop the check.
>> >> > Doing so allows us to simplify some of the related code.
>> >> >
>> >> > Cc: Jordan Justen 
>> >> > Signed-off-by: Emil Velikov 
>> >> > ---
>> >> >  src/mesa/drivers/dri/i965/brw_context.c | 3 +--
>> >> >  1 file changed, 1 insertion(+), 2 deletions(-)
>> >> >
>> >> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
>> >> > b/src/mesa/drivers/dri/i965/brw_context.c
>> >> > index 1bf39b07382..3947a71a46a 100644
>> >> > --- a/src/mesa/drivers/dri/i965/brw_context.c
>> >> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
>> >> > @@ -348,8 +348,7 @@ brw_initialize_context_constants(struct brw_context 
>> >> > *brw)
>> >> >   (_mesa_is_desktop_gl(ctx) &&
>> >> >ctx->Const.MaxComputeWorkGroupSize[0] >= 1024) ||
>> >> >   (ctx->API == API_OPENGLES2 &&
>> >> > -  ctx->Const.MaxComputeWorkGroupSize[0] >= 128) ||
>> >> > - _mesa_extension_override_enables.ARB_compute_shader,
>> >> > +  ctx->Const.MaxComputeWorkGroupSize[0] >= 128),
>> >>
>> >> Jordan can you throw an Ack on this patch if it makes sense?
>> >> Brian already reviewed the series, but I'd appreciate input from
>> >> someone familiar with the Intel specifics.
>> >
>> > Regarding patches 2 & 8, the point of those being non-static was so
>> > the driver could take some action if the user requested an extension
>> > override.
>> >
>> > I can't remember, but maybe with SIMD32 being supported, this might no
>> > longer affect any i965 devices.
>> >
>> > I still think it could be good to allow the driver to easily know what
>> > extensions were overridden, but I'll concede that it is not too
>> > important. So, go ahead with the change if you want.
>> >
>> Agreed allowing the driver to query the extension status is useful,
>> esp. during development.
>>
>> Since they're not used I made them static for now, but can add a
>> comment as below to make it clearer.
>> What do you think? Can I get your official blessing (ack/r-b) with that?
>
> For this patch, Reviewed-by: Jordan Justen 
>
> I'm not sure what you are proposing for patch 8. I would prefer to
> just drop 8, but I'm not sure how big of an impact that makes to your
> series.
>
> If you are proposing to drop patch 8, and instead add the comment
> below on the variables... What about this small tweak?
>
I was split between dropping or keeping with the comment squashed.
Let's drop 08 - the dead trivial conflict in 12/13 is fine.

> /* Sometimes the driver wants to query the extension override status before
>  * a context is created. These variables are filled with extension override
>  * information before context creation.
>  *
>  * This can be useful during extension bring-up when an extension is
>  * partially implemented, but cannot yet be advertised as supported.
>  *
>  * Use it with care and keep access read-only.
>  */
>
Nice - it reads a lot easier. I'll whip it into a patch form and send
out (for posterity) tomorrow.

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

Re: [Mesa-dev] [PATCH 02/13] i965: remove ARB_compute_shader extension override

[Jordan Justen]

On 2017-11-14 07:37:27, Emil Velikov wrote:
> On 10 November 2017 at 23:39, Jordan Justen  wrote:
> > On 2017-11-10 08:19:38, Emil Velikov wrote:
> >> On 7 November 2017 at 11:54, Emil Velikov  wrote:
> >> > From: Emil Velikov 
> >> >
> >> > Checking the override was useful in the early stages of developing the
> >> > extension.
> >> >
> >> > Now that everything is wired, where possible, we can drop the check.
> >> > Doing so allows us to simplify some of the related code.
> >> >
> >> > Cc: Jordan Justen 
> >> > Signed-off-by: Emil Velikov 
> >> > ---
> >> >  src/mesa/drivers/dri/i965/brw_context.c | 3 +--
> >> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >> >
> >> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> >> > b/src/mesa/drivers/dri/i965/brw_context.c
> >> > index 1bf39b07382..3947a71a46a 100644
> >> > --- a/src/mesa/drivers/dri/i965/brw_context.c
> >> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
> >> > @@ -348,8 +348,7 @@ brw_initialize_context_constants(struct brw_context 
> >> > *brw)
> >> >   (_mesa_is_desktop_gl(ctx) &&
> >> >ctx->Const.MaxComputeWorkGroupSize[0] >= 1024) ||
> >> >   (ctx->API == API_OPENGLES2 &&
> >> > -  ctx->Const.MaxComputeWorkGroupSize[0] >= 128) ||
> >> > - _mesa_extension_override_enables.ARB_compute_shader,
> >> > +  ctx->Const.MaxComputeWorkGroupSize[0] >= 128),
> >>
> >> Jordan can you throw an Ack on this patch if it makes sense?
> >> Brian already reviewed the series, but I'd appreciate input from
> >> someone familiar with the Intel specifics.
> >
> > Regarding patches 2 & 8, the point of those being non-static was so
> > the driver could take some action if the user requested an extension
> > override.
> >
> > I can't remember, but maybe with SIMD32 being supported, this might no
> > longer affect any i965 devices.
> >
> > I still think it could be good to allow the driver to easily know what
> > extensions were overridden, but I'll concede that it is not too
> > important. So, go ahead with the change if you want.
> >
> Agreed allowing the driver to query the extension status is useful,
> esp. during development.
> 
> Since they're not used I made them static for now, but can add a
> comment as below to make it clearer.
> What do you think? Can I get your official blessing (ack/r-b) with that?

For this patch, Reviewed-by: Jordan Justen 

I'm not sure what you are proposing for patch 8. I would prefer to
just drop 8, but I'm not sure how big of an impact that makes to your
series.

If you are proposing to drop patch 8, and instead add the comment
below on the variables... What about this small tweak?

/* Sometimes the driver wants to query the extension override status before
 * a context is created. These variables are filled with extension override
 * information before context creation.
 *
 * This can be useful during extension bring-up when an extension is
 * partially implemented, but cannot yet be advertised as supported.
 *
 * Use it with care and keep access read-only.
 */


> Thanks
> Emil
> 
> 
> /* Sometimes the driver wants to query the extensions status before a context
>  * is created. To achieve that one should use the following two variables. 
> This
>  * is very useful during extension bring-up, but can be a double-edged sword.
>  *
>  * Use it with care and keep access read-only.
>  */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] mesa 17.3.0-rc4

[Andres Gomez]

On Tue, 2017-11-14 at 11:28 -0800, Matt Turner wrote:
> On Tue, Nov 14, 2017 at 6:37 AM, Emil Velikov  
> wrote:
> > The fourth release candidate for Mesa 17.3.0 is now available.
> > 
> > As per the issue tracker [1] we still have a number of outstanding bugs
> > blocking the release.
> > 
> > [1] https://bugs.freedesktop.org/show_bug.cgi?id=103491
> > 
> > Andreas Boll (3):
> >   broadcom/vc5: Add vc5_drm.h to the release tarball
> >   broadcom/vc5: Remove unused v3d_compiler.c
> >   glsl: Fix typo fragement -> fragment
> > 
> > Dave Airlie (2):
> >   radv: free attachments on end command buffer.
> >   radv: add initial copy descriptor support. (v2)
> > 
> > Dylan Baker (1):
> >   autotools: Set C++ visibility flags on Intel
> > 
> > Emil Velikov (5):
> >   targets/opencl: don't hardcode the icd file install to /etc/...
> >   automake: intel: correctly append to the LIBADD variable
> >   configure.ac: loosen --enable-glvnd check to honour egl
> >   configure.ac: require xcb* for the omx/va/... when using x11 platform
> >   Update version to 17.3.0-rc4
> > 
> > Jason Ekstrand (15):
> >   intel/fs: Use a pure vertical stride for large register strides
> 
> I've reverted this on master and sent an email to mesa-stable@ to
> cherry-pick two other commits instead. Please revert this from 17.3.
> 
> Andres, you probably should do the same for 17.2.

Thanks for the heads up, Matt. Fortunately, we don't need to revert on
17.2, just not cherry-pick it.

I've also included your 2 nominations, in any case.

-- 
Br,

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

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

[Wladimir J. van der Laan]

> Sorry for noticing before, but this breaks glmark2 texture. I didn't
> yet dig into the issue but it's definitely caused by this commit.
> 
> To reproduce, simply run
> glmark2-es2-drm -b texture:texture-filter=mipmap

That's weird, as that neither uses point sprites nor flat shading.

I'll have a look...

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

Re: [Mesa-dev] [PATCH v5 00/10] new series of Mesa for Tizen

[Eric Anholt]

"Mun, Gwan-gyeong"  writes:

> Hi all,
>
> I am sorry that I didn't have enough discussion about why new window
> system code is needed for Tizen on mesa.
>
> This is a brief architecture of Tizen Window System.
>
>   
> +--+
>   | [Tizen Window System Architecture]
>   |
>   |
>   |
>   |
>   |
>   |
>   |
>   |  +---+
> ++  ++  |
>   |  | Enlightenment Display |   |
>|  |   3D UI|  |
>   |  |  Server for Tizen +-->|
> EvasGL   |  |   Toolkit  |  |
>   |  |   |   |
>|  ||  |
>   |  |   |
> +-+--+  +-+--+  |
>   |  +--+-+--+
> |   | |
>   | | |
> v   | |
>   | | |
> ++| |
>   | | |  | GPU
> Vendor || |
>   | | |  |
> GL/EGL|<---+ |
>   | | |  |
> Driver|  |
>   | | |
> +-+--+  |
>   | | |
> | |
>   | v v
> v |
>   |   +---++--+
> ++  |
>   |   | TDM   ||TBM   |  |
>|  |
>   |   |(Tizen Display Manager)+--->|(Tizen Buffer Manager)|<-|
> TPL-EGL  |  |
>   |   |   ||  |  |
>|  |
>   |   +---++--+
> ++  |
>   |
>   |
>   
> +--+
>
>
>
> < display server / wayland-egl client >
>
> +-+
> +---+
> | |   |
>|
> |  +---+  |   |
> +---+   |
> |  | Enlightenment Display +---+  |
> |  wayland-egl client   |   |
> |  |  Server for Tizen |  ||  |
> +--+-+--+   |
> |  +--++  ||  |
>   | |  |
> | |   ||  |
>   | |  |
> | v   ||  |
>   | |  |
> |  +---+  ||  |
>   | |  |
> |  | EVAS GL TBM   |  ||  |
>   | |  |
> |  ++-++  ||  |
>   | |  |
> |   | |   ||  |
>   | |  |
> |   | v   ||  |
>   v v  |
> |   |+-+  ||+--+  |
> +-+   +-+   |
> |   ||   EGL   +---|--->|  GPU Vendor
> |<-+ EGL |   | wayland-egl |   |
> |   |+++  |||  GL Driver   |  |
> +--+--+   +---+-+   |
> |   | |   ||+--+  |
>   |  |  ^  |
> |   v v   ||  |
>   v  v  |  |
> |  +-+   +-+  ||+--+  |
> ++--+   |
> |  |   TBM   |<--+ TPL-EGL +---|--->| wayland-tbm
> |<-+TPL-EGL|   |
> |  +-+   +-+  ||+--+  |
> +---+   |
> | ||^ |
>|
> | ||| |
>|
> +-+++
> 

Re: [Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

[Lucas Stach]

Hi Wladimir,

Am Mittwoch, den 15.11.2017, 18:03 +0100 schrieb Wladimir J. van der Laan:
> A recent commit (see below) fixed flat shading but at the same time
> broke the use of point sprites with multiple varyings. This resulted in
> particle systems rendering wrongly.
> 
> The reason for this is that it set VARYING_COMPONENT_USE_POINTCOORD_[XY]
> for all non-color varyings, causing them to be replaced with the point
> coordinate when rendering points.
> 
> VARYING_COMPONENT_USE_POINTCOORD_[XY] is a misnomer, it should be
> TEXCOORD. Its semantics are: texture coordinates will get replaced with
> the point coordinate when rendering GL_POINTS, for other primitives
> their interpolation is independent of the shading model.
> 
> So use VARYING_COMPONENT_USE_POINTCOORD_[XY] only for texture coordinates.
> This causes them to be interpolated correctly while flat shading, while
> generic varyings are left as-is when rendering point sprites.

Sorry for noticing before, but this breaks glmark2 texture. I didn't
yet dig into the issue but it's definitely caused by this commit.

To reproduce, simply run
glmark2-es2-drm -b texture:texture-filter=mipmap

Regards,
Lucas

> Fixes: cedab87e762aa38997a07bc8a2eb624aed584afd "etnaviv: fix varying 
> interpolation"
> > Signed-off-by: Wladimir J. van der Laan 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_compiler.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
> b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> index 3180646..6569979 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> @@ -2561,7 +2561,11 @@ etna_link_shader(struct etna_shader_link_info *info,
>    const struct etna_shader_inout *fsio = >infile.reg[idx];
>    const struct etna_shader_inout *vsio = etna_shader_vs_lookup(vs, fsio);
>    struct etna_varying *varying;
> -  bool interpolate_always = fsio->semantic.Name != TGSI_SEMANTIC_COLOR;
> +  /* Texture coordinates will get replaced with the point coordinate when
> +   * rendering GL_POINTS, for other primitives their interpolation is
> +   * independent of the shading model. */
> +  bool is_texcoord = fsio->semantic.Name == TGSI_SEMANTIC_TEXCOORD ||
> + fsio->semantic.Name == TGSI_SEMANTIC_PCOORD;
>  
>    assert(fsio->reg > 0 && fsio->reg <= ARRAY_SIZE(info->varyings));
>  
> @@ -2571,13 +2575,14 @@ etna_link_shader(struct etna_shader_link_info *info,
>    varying = >varyings[fsio->reg - 1];
>    varying->num_components = fsio->num_components;
>  
> -  if (!interpolate_always) /* colors affected by flat shading */
> +  /* PA_ATTRIBUTES appears to be unused on HALTI0 and up */
> +  if (!is_texcoord) /* colors affected by flat shading */
>   varying->pa_attributes = 0x200;
>    else /* texture coord or other bypasses flat shading */
>   varying->pa_attributes = 0x2f1;
>  
> -  varying->use[0] = interpolate_always ? 
> VARYING_COMPONENT_USE_POINTCOORD_X : VARYING_COMPONENT_USE_USED;
> -  varying->use[1] = interpolate_always ? 
> VARYING_COMPONENT_USE_POINTCOORD_Y : VARYING_COMPONENT_USE_USED;
> +  varying->use[0] = is_texcoord ? VARYING_COMPONENT_USE_POINTCOORD_X : 
> VARYING_COMPONENT_USE_USED;
> +  varying->use[1] = is_texcoord ? VARYING_COMPONENT_USE_POINTCOORD_Y : 
> VARYING_COMPONENT_USE_USED;
>    varying->use[2] = VARYING_COMPONENT_USE_USED;
>    varying->use[3] = VARYING_COMPONENT_USE_USED;
>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103128] [softpipe] piglit fs-ldexp regression

[bugzilla-daemon]

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

--- Comment #2 from Nicolai Hähnle  ---
https://patchwork.freedesktop.org/patch/188544/ fixes this for me.

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

[Mesa-dev] [PATCH] tgsi/exec: fix LDEXP in softpipe

[Nicolai Hähnle]

From: Nicolai Hähnle 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103128
Fixes: cad959d90145 ("gallium: add LDEXP TGSI instruction and corresponding 
cap")
---
 src/gallium/auxiliary/tgsi/tgsi_exec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index afed96c9b1d..793c0da39ab 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -5123,21 +5123,21 @@ exec_instruction(
 
case TGSI_OPCODE_LG2:
   exec_scalar_unary(mach, inst, micro_lg2, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
   break;
 
case TGSI_OPCODE_POW:
   exec_scalar_binary(mach, inst, micro_pow, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
   break;
 
case TGSI_OPCODE_LDEXP:
-  exec_scalar_binary(mach, inst, micro_ldexp, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_INT);
+  exec_vector_binary(mach, inst, micro_ldexp, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
   break;
 
case TGSI_OPCODE_COS:
   exec_scalar_unary(mach, inst, micro_cos, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
   break;
 
case TGSI_OPCODE_DDX:
   exec_vector_unary(mach, inst, micro_ddx, TGSI_EXEC_DATA_FLOAT, 
TGSI_EXEC_DATA_FLOAT);
   break;
 
-- 
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] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

[Jon Turney]

On 15/11/2017 14:35, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds

Cc: Jon Turney 
Cc: Rob Herring 
Cc: Alexander von Gluck IV 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11 changes")
---
  SConstruct  | 7 +++
  configure.ac| 1 +
  include/c11/threads_posix.h | 2 +-
  meson.build | 2 +-
  4 files changed, 10 insertions(+), 2 deletions(-)


Reviewed-by: Jon Turney 

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

Re: [Mesa-dev] [PATCH v2] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

[Dylan Baker]

Quoting Nicolai Hähnle (2017-11-15 06:35:49)
> From: Nicolai Hähnle 
> 
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
> 
> Cc: Jon Turney 
> Cc: Rob Herring 
> Cc: Alexander von Gluck IV 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
> Fixes: f1a364878431 ("threads: update for late C11 changes")
> ---
>  SConstruct  | 7 +++
>  configure.ac| 1 +
>  include/c11/threads_posix.h | 2 +-
>  meson.build | 2 +-
>  4 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/SConstruct b/SConstruct
> index a59a8ea210e..1ef134af27d 100644
> --- a/SConstruct
> +++ b/SConstruct
> @@ -122,20 +122,27 @@ if env['crosscompile'] and not env['embedded']:
>  Export('env')
>  
>  SConscript(
>  'src/SConscript',
>  variant_dir = host_env['build_dir'],
>  duplicate = 0, # 
> http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
>  )
>  
>  env = target_env
>  
> +if env['platform'] != 'windows':
> +   # This is quite incomplete, but it hopefully covers the platforms that
> +   # people actually use SCons on...
> +   env.Append(CPPDEFINES= [
> +  'HAVE_TIMESPEC_GET',
> +   ])
> +

I think that haiku uses scons, I've added one of (and hopefully an appropriate)
person that works on Haiku.

Otherwise I think this looks good, as long as the Haiku guys think this is fine
for them,
Reviewed-by: Dylan Baker 


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] amd: build addrlib with C++11

[Ilia Mirkin]

On Wed, Nov 15, 2017 at 12:47 PM, Dylan Baker  wrote:
> Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
> cannot be built without it (Because of LLVM). As far as I can tell the GLSL
> compiler and the Intel Compiler are the only C++ code in mesa not using C++11.

Actually C++11 isn't used anywhere except clover and swr, AFAIK. (Look
for CXX11_CXXFLAGS.)

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

Re: [Mesa-dev] [PATCH] amd: build addrlib with C++11

[Nicolai Hähnle]

On 15.11.2017 17:45, Kai Wasserbäch wrote:

Doesn't the meson.build file need the same change?


I don't really know Meson, but the master build file looks to me like 
Meson always builds with C++11.


Cheers,
Nicolai



Nicolai Hähnle wrote on 15.11.2017 12:55:

From: Nicolai Hähnle 

It is required for LLVM anyway.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103658
Fixes: 7f33e94e43a6 ("amd/addrlib: update to latest version")
---
  src/amd/Makefile.addrlib.am | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am
index 46689637f9b..90dfe963445 100644
--- a/src/amd/Makefile.addrlib.am
+++ b/src/amd/Makefile.addrlib.am
@@ -26,15 +26,15 @@ addrlib_libamdgpu_addrlib_la_CPPFLAGS = \
-I$(srcdir)/common \
-I$(srcdir)/addrlib \
-I$(srcdir)/addrlib/core \
-I$(srcdir)/addrlib/inc/chip/gfx9 \
-I$(srcdir)/addrlib/inc/chip/r800 \
-I$(srcdir)/addrlib/gfx9/chip \
-I$(srcdir)/addrlib/r800/chip \
-DBRAHMA_BUILD=1
  
  addrlib_libamdgpu_addrlib_la_CXXFLAGS = \

-   $(VISIBILITY_CXXFLAGS)
+   $(VISIBILITY_CXXFLAGS) $(CXX11_CXXFLAGS)
  
  noinst_LTLIBRARIES += $(ADDRLIB_LIBS)
  
  addrlib_libamdgpu_addrlib_la_SOURCES = $(ADDRLIB_FILES)




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

Re: [Mesa-dev] [PATCH] amd: build addrlib with C++11

[Dylan Baker]

Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
cannot be built without it (Because of LLVM). As far as I can tell the GLSL
compiler and the Intel Compiler are the only C++ code in mesa not using C++11.

Quoting Kai Wasserbäch (2017-11-15 08:45:30)
> Doesn't the meson.build file need the same change?
> 
> Nicolai Hähnle wrote on 15.11.2017 12:55:
> > From: Nicolai Hähnle 
> > 
> > It is required for LLVM anyway.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103658
> > Fixes: 7f33e94e43a6 ("amd/addrlib: update to latest version")
> > ---
> >  src/amd/Makefile.addrlib.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am
> > index 46689637f9b..90dfe963445 100644
> > --- a/src/amd/Makefile.addrlib.am
> > +++ b/src/amd/Makefile.addrlib.am
> > @@ -26,15 +26,15 @@ addrlib_libamdgpu_addrlib_la_CPPFLAGS = \
> >   -I$(srcdir)/common \
> >   -I$(srcdir)/addrlib \
> >   -I$(srcdir)/addrlib/core \
> >   -I$(srcdir)/addrlib/inc/chip/gfx9 \
> >   -I$(srcdir)/addrlib/inc/chip/r800 \
> >   -I$(srcdir)/addrlib/gfx9/chip \
> >   -I$(srcdir)/addrlib/r800/chip \
> >   -DBRAHMA_BUILD=1
> >  
> >  addrlib_libamdgpu_addrlib_la_CXXFLAGS = \
> > - $(VISIBILITY_CXXFLAGS)
> > + $(VISIBILITY_CXXFLAGS) $(CXX11_CXXFLAGS)
> >  
> >  noinst_LTLIBRARIES += $(ADDRLIB_LIBS)
> >  
> >  addrlib_libamdgpu_addrlib_la_SOURCES = $(ADDRLIB_FILES)
> 
> 
> 
> ___
> 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] meson: Don't define HAVE_PTHREAD only on linux

[Dylan Baker]

Quoting Jon Turney (2017-11-15 02:52:29)
> I'm not sure of the reason for this. I don't see anything like this in
> configure.ac

I hadn't had a chance to test other platforms, and I wasn't sure about Windows
and Haiku. Some of the BSD's also stiil use pthread-stubs, and I don't think
those get HAVE_PTHREADS.

I also don't konw what depdnency('threads') returns on windows, but in mean time
this probably fixes some platforms and doesn't break any that previous worked.

Reviewed-by: Dylan Baker 

> 
> In include/c11/threads.h the cases are:
> 
> 1) building for Windows -> threads_win32.h
> 2) HAVE_PTHREAD -> threads_posix.h
> 3) Not supported on this platform
> 
> So not defining HAVE_PTHREAD for anything not Windows just means we can't
> build at all.
> 
> When we are building for Windows, I'm not sure if dependency('threads')
> would ever find anything, or defining HAVE_PTHREAD has any effect, but avoid
> defining it there, just in case.
> 
> Signed-off-by: Jon Turney 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 84c0e102737..a0dd02b1f64 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -668,7 +668,7 @@ endif
>  # TODO: some of these may be conditional
>  dep_zlib = dependency('zlib', version : '>= 1.2.3')
>  dep_thread = dependency('threads')
> -if dep_thread.found() and host_machine.system() == 'linux'
> +if dep_thread.found() and host_machine.system() != 'windows'
>pre_args += '-DHAVE_PTHREAD'
>  endif
>  dep_elf = dependency('libelf', required : false)
> -- 
> 2.15.0
> 
> ___
> 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] meson: Add dridriverdir variable to dri.pc.

[Dylan Baker]

Reviewed-by: Dylan Baker 

Quoting Rafael Antognolli (2017-11-15 09:32:47)
> Xorg (and possibly other things) depend on this variable to find the
> path to DRI drivers.
> 
> Signed-off-by: Rafael Antognolli 
> Cc: Dylan Baker 
> ---
>  src/mesa/drivers/dri/meson.build | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/mesa/drivers/dri/meson.build 
> b/src/mesa/drivers/dri/meson.build
> index a2fc8db8ada..217f1e5c71c 100644
> --- a/src/mesa/drivers/dri/meson.build
> +++ b/src/mesa/drivers/dri/meson.build
> @@ -58,6 +58,7 @@ if dri_drivers != []
>  filebase : 'dri',
>  description : 'Direct Rendering Infrastructure',
>  version : meson.project_version(),
> +variables : ['dridriverdir=${prefix}/' + dri_drivers_path],
>  requires_private : ['libdrm >= 2.4.75'],  # FIXME: don't hardcode this
>)
>  
> -- 
> 2.13.6
> 


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

[Mesa-dev] [PATCH] meson: Add dridriverdir variable to dri.pc.

[Rafael Antognolli]

Xorg (and possibly other things) depend on this variable to find the
path to DRI drivers.

Signed-off-by: Rafael Antognolli 
Cc: Dylan Baker 
---
 src/mesa/drivers/dri/meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/meson.build b/src/mesa/drivers/dri/meson.build
index a2fc8db8ada..217f1e5c71c 100644
--- a/src/mesa/drivers/dri/meson.build
+++ b/src/mesa/drivers/dri/meson.build
@@ -58,6 +58,7 @@ if dri_drivers != []
 filebase : 'dri',
 description : 'Direct Rendering Infrastructure',
 version : meson.project_version(),
+variables : ['dridriverdir=${prefix}/' + dri_drivers_path],
 requires_private : ['libdrm >= 2.4.75'],  # FIXME: don't hardcode this
   )
 
-- 
2.13.6

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

Re: [Mesa-dev] [PATCH] meson: Don't define HAVE_PTHREAD only on linux

[Eric Engestrom]

On Wednesday, 2017-11-15 10:52:29 +, Jon Turney wrote:
> I'm not sure of the reason for this. I don't see anything like this in
> configure.ac
> 
> In include/c11/threads.h the cases are:
> 
> 1) building for Windows -> threads_win32.h
> 2) HAVE_PTHREAD -> threads_posix.h
> 3) Not supported on this platform
> 
> So not defining HAVE_PTHREAD for anything not Windows just means we can't
> build at all.
> 
> When we are building for Windows, I'm not sure if dependency('threads')
> would ever find anything, or defining HAVE_PTHREAD has any effect, but avoid
> defining it there, just in case.

Might be worth checking that to see if we can drop the os check, but in
the mean time this should be fine:
Reviewed-by: Eric Engestrom 

> 
> Signed-off-by: Jon Turney 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 84c0e102737..a0dd02b1f64 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -668,7 +668,7 @@ endif
>  # TODO: some of these may be conditional
>  dep_zlib = dependency('zlib', version : '>= 1.2.3')
>  dep_thread = dependency('threads')
> -if dep_thread.found() and host_machine.system() == 'linux'
> +if dep_thread.found() and host_machine.system() != 'windows'
>pre_args += '-DHAVE_PTHREAD'
>  endif
>  dep_elf = dependency('libelf', required : false)
> -- 
> 2.15.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] mesa/teximage: add TEXTURE_CUBE_MAP_ARRAY target for CompressedTexImage3D

[Ilia Mirkin]

On Wed, Nov 15, 2017 at 11:54 AM, Juan A. Suarez Romero
 wrote:
> From section 8.7, page 179 of OpenGL ES 3.2 spec:
>
>   An INVALID_OPERATION error is generated by CompressedTexImage3D
>   if internalformat is one of the the formats in table 8.17 and target
>   is not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
>
>   An INVALID_OPERATION error is generated by CompressedTexImage3D if
>   internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube Map Array”
>   column of table 8.17 is not checked, or if internalformat is
>   TEXTURE_3D and the “3D Tex.” column of table 8.17 is not checked.
>
> So far it was only considering TEXTURE_2D_ARRAY as valid target. But as
> "Cube Map Array" column is checked for all the cases, in practice we can
> consider also TEXTURE_CUBE_MAP_ARRAY.
>
> This fixes KHR-GLES32.core.texture_cube_map_array.etc2_texture
> ---
>  src/mesa/main/teximage.c | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 4ec6148bf42..174731d0d8a 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -1403,17 +1403,26 @@ _mesa_target_can_be_compressed(const struct 
> gl_context *ctx, GLenum target,
> * have already been handled by normal ETC2/EAC behavior.
> */
>
> -  /* From section 3.8.6, page 146 of OpenGL ES 3.0 spec:
> +  /* From section 8.7, page 179 of OpenGL ES 3.2 spec:
> *
> -   *"The ETC2/EAC texture compression algorithm supports only
> -   * two-dimensional images. If internalformat is an ETC2/EAC format,
> -   * glCompressedTexImage3D will generate an INVALID_OPERATION error 
> if
> -   * target is not TEXTURE_2D_ARRAY."
> +   *  An INVALID_OPERATION error is generated by CompressedTexImage3D
> +   *  if internalformat is one of the the formats in table 8.17 and 
> target is
> +   *  not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
> *
> -   * This should also be applicable for glTexStorage3D(). Other available
> -   * targets for these functions are: TEXTURE_3D and 
> TEXTURE_CUBE_MAP_ARRAY.
> +   *  An INVALID_OPERATION error is generated by CompressedTexImage3D
> +   *  if internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube Map
> +   *  Array” column of table 8.17 is not checked, or if 
> internalformat
> +   *  is TEXTURE_- 3D and the “3D Tex.” column of table 8.17 is not
> +   *  checked.
> +   *
> +   * The instances of  above should say .
> +   *
> +   * This should also be applicable for glTexStorage3D().
> +   *
> +   * Such table 8.17 has checked "Cube Map Array" column for all the
> +   * cases. So in practice, TEXTURE_CUBE_MAP_ARRAY is now valid.
> */
> -  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx))
> +  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx) && 
> !_mesa_is_gles32(ctx))

Perhaps this should be

!_mesa_has_OES_texture_cube_map_array(ctx)?

It's unclear from that spec though... perhaps ES 3.2 goes further and
is required to be supported.

>  return write_error(error, GL_INVALID_OPERATION);
>target_can_be_compresed = _mesa_has_texture_cube_map_array(ctx);
>break;
> --
> 2.13.6
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

[Wladimir J. van der Laan]

A recent commit (see below) fixed flat shading but at the same time
broke the use of point sprites with multiple varyings. This resulted in
particle systems rendering wrongly.

The reason for this is that it set VARYING_COMPONENT_USE_POINTCOORD_[XY]
for all non-color varyings, causing them to be replaced with the point
coordinate when rendering points.

VARYING_COMPONENT_USE_POINTCOORD_[XY] is a misnomer, it should be
TEXCOORD. Its semantics are: texture coordinates will get replaced with
the point coordinate when rendering GL_POINTS, for other primitives
their interpolation is independent of the shading model.

So use VARYING_COMPONENT_USE_POINTCOORD_[XY] only for texture coordinates.
This causes them to be interpolated correctly while flat shading, while
generic varyings are left as-is when rendering point sprites.

Fixes: cedab87e762aa38997a07bc8a2eb624aed584afd "etnaviv: fix varying 
interpolation"
Signed-off-by: Wladimir J. van der Laan 
---
 src/gallium/drivers/etnaviv/etnaviv_compiler.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
index 3180646..6569979 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
@@ -2561,7 +2561,11 @@ etna_link_shader(struct etna_shader_link_info *info,
   const struct etna_shader_inout *fsio = >infile.reg[idx];
   const struct etna_shader_inout *vsio = etna_shader_vs_lookup(vs, fsio);
   struct etna_varying *varying;
-  bool interpolate_always = fsio->semantic.Name != TGSI_SEMANTIC_COLOR;
+  /* Texture coordinates will get replaced with the point coordinate when
+   * rendering GL_POINTS, for other primitives their interpolation is
+   * independent of the shading model. */
+  bool is_texcoord = fsio->semantic.Name == TGSI_SEMANTIC_TEXCOORD ||
+ fsio->semantic.Name == TGSI_SEMANTIC_PCOORD;
 
   assert(fsio->reg > 0 && fsio->reg <= ARRAY_SIZE(info->varyings));
 
@@ -2571,13 +2575,14 @@ etna_link_shader(struct etna_shader_link_info *info,
   varying = >varyings[fsio->reg - 1];
   varying->num_components = fsio->num_components;
 
-  if (!interpolate_always) /* colors affected by flat shading */
+  /* PA_ATTRIBUTES appears to be unused on HALTI0 and up */
+  if (!is_texcoord) /* colors affected by flat shading */
  varying->pa_attributes = 0x200;
   else /* texture coord or other bypasses flat shading */
  varying->pa_attributes = 0x2f1;
 
-  varying->use[0] = interpolate_always ? 
VARYING_COMPONENT_USE_POINTCOORD_X : VARYING_COMPONENT_USE_USED;
-  varying->use[1] = interpolate_always ? 
VARYING_COMPONENT_USE_POINTCOORD_Y : VARYING_COMPONENT_USE_USED;
+  varying->use[0] = is_texcoord ? VARYING_COMPONENT_USE_POINTCOORD_X : 
VARYING_COMPONENT_USE_USED;
+  varying->use[1] = is_texcoord ? VARYING_COMPONENT_USE_POINTCOORD_Y : 
VARYING_COMPONENT_USE_USED;
   varying->use[2] = VARYING_COMPONENT_USE_USED;
   varying->use[3] = VARYING_COMPONENT_USE_USED;
 
-- 
2.7.4

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

[Mesa-dev] [Bug 103757] eglGetDisplay() is broken for Wayland

[bugzilla-daemon]

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

--- Comment #9 from Michael Olbrich  ---
(In reply to Pekka Paalanen from comment #1)
> Any reason you cannot use EGL_KHR_platform_wayland?

It's not my code. It's somewhere in gstreamer-vaapi. I was just debugging why
my application was crashing.

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

[Mesa-dev] [PATCH v2] mesa/teximage: add TEXTURE_CUBE_MAP_ARRAY target for CompressedTexImage3D

[Juan A. Suarez Romero]

From section 8.7, page 179 of OpenGL ES 3.2 spec:

  An INVALID_OPERATION error is generated by CompressedTexImage3D
  if internalformat is one of the the formats in table 8.17 and target
  is not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.

  An INVALID_OPERATION error is generated by CompressedTexImage3D if
  internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube Map Array”
  column of table 8.17 is not checked, or if internalformat is
  TEXTURE_3D and the “3D Tex.” column of table 8.17 is not checked.

So far it was only considering TEXTURE_2D_ARRAY as valid target. But as
"Cube Map Array" column is checked for all the cases, in practice we can
consider also TEXTURE_CUBE_MAP_ARRAY.

This fixes KHR-GLES32.core.texture_cube_map_array.etc2_texture
---
 src/mesa/main/teximage.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 4ec6148bf42..174731d0d8a 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1403,17 +1403,26 @@ _mesa_target_can_be_compressed(const struct gl_context 
*ctx, GLenum target,
* have already been handled by normal ETC2/EAC behavior.
*/
 
-  /* From section 3.8.6, page 146 of OpenGL ES 3.0 spec:
+  /* From section 8.7, page 179 of OpenGL ES 3.2 spec:
*
-   *"The ETC2/EAC texture compression algorithm supports only
-   * two-dimensional images. If internalformat is an ETC2/EAC format,
-   * glCompressedTexImage3D will generate an INVALID_OPERATION error if
-   * target is not TEXTURE_2D_ARRAY."
+   *  An INVALID_OPERATION error is generated by CompressedTexImage3D
+   *  if internalformat is one of the the formats in table 8.17 and 
target is
+   *  not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
*
-   * This should also be applicable for glTexStorage3D(). Other available
-   * targets for these functions are: TEXTURE_3D and 
TEXTURE_CUBE_MAP_ARRAY.
+   *  An INVALID_OPERATION error is generated by CompressedTexImage3D
+   *  if internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube Map
+   *  Array” column of table 8.17 is not checked, or if internalformat
+   *  is TEXTURE_- 3D and the “3D Tex.” column of table 8.17 is not
+   *  checked.
+   *
+   * The instances of  above should say .
+   *
+   * This should also be applicable for glTexStorage3D().
+   *
+   * Such table 8.17 has checked "Cube Map Array" column for all the
+   * cases. So in practice, TEXTURE_CUBE_MAP_ARRAY is now valid.
*/
-  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx))
+  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx) && 
!_mesa_is_gles32(ctx))
 return write_error(error, GL_INVALID_OPERATION);
   target_can_be_compresed = _mesa_has_texture_cube_map_array(ctx);
   break;
-- 
2.13.6

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

[Mesa-dev] [Bug 103757] eglGetDisplay() is broken for Wayland

[bugzilla-daemon]

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

--- Comment #8 from Michael Olbrich  ---
(In reply to Daniel Stone from comment #7)
> Good point - I guess it'd have to be if
> (_eglPointerIsDereferencable(child_pointer) &&
> _eglPointerIsDereferencable(((char *) child_pointer) + strlen("wl_display")
> + 1) && strcmp(interface->name, "wl_display") == 0) ... ugh. Does that work
> for you?

Yes that works.

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

Re: [Mesa-dev] [PATCH] amd: build addrlib with C++11

[Kai Wasserbäch]

Doesn't the meson.build file need the same change?

Nicolai Hähnle wrote on 15.11.2017 12:55:
> From: Nicolai Hähnle 
> 
> It is required for LLVM anyway.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103658
> Fixes: 7f33e94e43a6 ("amd/addrlib: update to latest version")
> ---
>  src/amd/Makefile.addrlib.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am
> index 46689637f9b..90dfe963445 100644
> --- a/src/amd/Makefile.addrlib.am
> +++ b/src/amd/Makefile.addrlib.am
> @@ -26,15 +26,15 @@ addrlib_libamdgpu_addrlib_la_CPPFLAGS = \
>   -I$(srcdir)/common \
>   -I$(srcdir)/addrlib \
>   -I$(srcdir)/addrlib/core \
>   -I$(srcdir)/addrlib/inc/chip/gfx9 \
>   -I$(srcdir)/addrlib/inc/chip/r800 \
>   -I$(srcdir)/addrlib/gfx9/chip \
>   -I$(srcdir)/addrlib/r800/chip \
>   -DBRAHMA_BUILD=1
>  
>  addrlib_libamdgpu_addrlib_la_CXXFLAGS = \
> - $(VISIBILITY_CXXFLAGS)
> + $(VISIBILITY_CXXFLAGS) $(CXX11_CXXFLAGS)
>  
>  noinst_LTLIBRARIES += $(ADDRLIB_LIBS)
>  
>  addrlib_libamdgpu_addrlib_la_SOURCES = $(ADDRLIB_FILES)



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

Re: [Mesa-dev] [PATCH mesa 2/2] egl: drop EGL driver `name`

[Kai Wasserbäch]

I'm still good with this, thanks for reapplying!

Eric Engestrom wrote on 14.11.2017 18:26:
> This is a revert of Marek's 2cb9ab53dd3ae6850a26 revert.
> It was needed to revert the previous commit, and didn't have any issue
> itself.
> --
> 
> The "DRI2" name was reported as confusing when printing EGL infos (one
> user reported thinking DRI3 was not working on his X server), and the
> only alternative is Haiku, which can only be used on a Haiku machine.
> 
> The name therefore doesn't add any information that the user wouldn't
> know already, so let's just drop it.
> 
> Cc: Kai Wasserbäch 
> Suggested-by: Emil Velikov 
> Related-to: b174a1ae720cb404738c ("egl: Simplify the "driver" interface")
> Signed-off-by: Eric Engestrom 
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 2 --
>  src/egl/drivers/haiku/egl_haiku.cpp | 2 --
>  src/egl/main/eglapi.c   | 3 +--
>  src/egl/main/egldriver.c| 2 --
>  src/egl/main/egldriver.h| 2 --
>  5 files changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 7c63920c54624e0e674e..3dce5f82320b2465037a 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -3269,6 +3269,4 @@ _eglInitDriver(_EGLDriver *dri2_drv)
> dri2_drv->API.GLInteropQueryDeviceInfo = dri2_interop_query_device_info;
> dri2_drv->API.GLInteropExportObject = dri2_interop_export_object;
> dri2_drv->API.DupNativeFenceFDANDROID = dri2_dup_native_fence_fd;
> -
> -   dri2_drv->Name = "DRI2";
>  }
> diff --git a/src/egl/drivers/haiku/egl_haiku.cpp 
> b/src/egl/drivers/haiku/egl_haiku.cpp
> index 590e43f00fb96b051fb4..0b56653395a94ac1f303 100644
> --- a/src/egl/drivers/haiku/egl_haiku.cpp
> +++ b/src/egl/drivers/haiku/egl_haiku.cpp
> @@ -325,7 +325,5 @@ _eglInitDriver(_EGLDriver *driver)
>  
>   driver->API.SwapBuffers = haiku_swap_buffers;
>  
> - driver->Name = "Haiku";
> -
>   TRACE("API Calls defined\n");
>  }
> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> index c1bf5bbfe19b3172429e..306db209cd94748f048f 100644
> --- a/src/egl/main/eglapi.c
> +++ b/src/egl/main/eglapi.c
> @@ -619,8 +619,7 @@ eglInitialize(EGLDisplay dpy, EGLint *major, EGLint 
> *minor)
>_eglCreateExtensionsString(disp);
>_eglCreateAPIsString(disp);
>snprintf(disp->VersionString, sizeof(disp->VersionString),
> -   "%d.%d (%s)", disp->Version / 10, disp->Version % 10,
> -   disp->Driver->Name);
> +   "%d.%d", disp->Version / 10, disp->Version % 10);
> }
>  
> /* Update applications version of major and minor if not NULL */
> diff --git a/src/egl/main/egldriver.c b/src/egl/main/egldriver.c
> index 71bfca21ed8c6a666c14..f1973bde274ec768c4cf 100644
> --- a/src/egl/main/egldriver.c
> +++ b/src/egl/main/egldriver.c
> @@ -99,8 +99,6 @@ _eglMatchDriver(_EGLDisplay *dpy)
> }
>  
> if (best_drv) {
> -  _eglLog(_EGL_DEBUG, "the best driver is %s",
> -best_drv->Name);
>dpy->Driver = best_drv;
>dpy->Initialized = EGL_TRUE;
> }
> diff --git a/src/egl/main/egldriver.h b/src/egl/main/egldriver.h
> index ba12a060cab7f7c6c223..5695fc06ffb03102cc64 100644
> --- a/src/egl/main/egldriver.h
> +++ b/src/egl/main/egldriver.h
> @@ -75,8 +75,6 @@ extern "C" {
>   */
>  struct _egl_driver
>  {
> -   const char *Name;  /**< name of this driver */
> -
> _EGLAPI API;  /**< EGL API dispatch table */
>  };
>  
> 

-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: k...@dev.carbon-project.org



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

Re: [Mesa-dev] [PATCH] mesa/teximage: add more targets for CompressedTexImage3D

[Juan A. Suarez Romero]

On Tue, 2017-11-14 at 16:57 -0800, Nanley Chery wrote:
> On Wed, Nov 08, 2017 at 04:52:02PM +0100, Juan A. Suarez Romero wrote:
> > From section 8.7, page 179 of OpenGL ES 3.2 spec:
> > 
> >   An INVALID_OPERATION error is generated by CompressedTexImage3D
> >   if internalformat is one of the the formats in table 8.17 and target
> >   is not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D.
> > 
> > So far it was only considering TEXTURE_2D_ARRAY as valid target. Now it
> > must consider also TEXTURE_CUBE_MAP_ARRAY and TEXTURE_3D.
> > 
> 
> Not necessarily. The next sentence after the one you quoted states:
> 
>An INVALID_OPERATION error is generated by CompressedTexImage3D if
>internalformat is TEXTURE_CUBE_MAP_ARRAY and the “Cube Map Array”
>column of table 8.17 is not checked, or if internalformat is
>TEXTURE_3D and the “3D Tex.” column of table 8.17 is not checked.
> 
> It seems that the OpenGL ES 3.2 spec has moved towards using a table to
> determine valid compressed targets. It hasn't necessarily stated that
> TEXTURE_CUBE_MAP_ARRAY and TEXTURE_3D are now valid. Though, by looking
> at the table, I think we can conclude that TEXTURE_CUBE_MAP_ARRAY is now
> valid.
> 

Right, but as the "Cube Map Array" is checked for all the cases, it is
fine to say that in effect TEXTURE_CUBE_MAP_ARRAY is now valid.

In any case, I can add both paragraphs to improve clarification.


> > This fixes KHR-GLES32.core.texture_cube_map_array.etc2_texture
> > ---
> >  src/mesa/main/teximage.c | 17 ++---
> >  1 file changed, 6 insertions(+), 11 deletions(-)
> > 
> > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> > index 4ec6148bf42..2799669d28a 100644
> > --- a/src/mesa/main/teximage.c
> > +++ b/src/mesa/main/teximage.c
> > @@ -1403,26 +1403,21 @@ _mesa_target_can_be_compressed(const struct 
> > gl_context *ctx, GLenum target,
> > * have already been handled by normal ETC2/EAC behavior.
> > */
> >  
> > -  /* From section 3.8.6, page 146 of OpenGL ES 3.0 spec:
> > +  /* From section 8.7, page 179 of OpenGL ES 3.2 spec:
> > *
> > -   *"The ETC2/EAC texture compression algorithm supports only
> > -   * two-dimensional images. If internalformat is an ETC2/EAC 
> > format,
> > -   * glCompressedTexImage3D will generate an INVALID_OPERATION 
> > error if
> > -   * target is not TEXTURE_2D_ARRAY."
> > +   *"An INVALID_OPERATION error is generated by 
> > CompressedTexImage3D
> > +   * if internalformat is one of the the formats in table 8.17 and 
> > target is
> > +   * not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY or TEXTURE_3D."
> > *
> > -   * This should also be applicable for glTexStorage3D(). Other 
> > available
> > -   * targets for these functions are: TEXTURE_3D and 
> > TEXTURE_CUBE_MAP_ARRAY.
> > +   * This should also be applicable for glTexStorage3D().
> > */
> > -  if (layout == MESA_FORMAT_LAYOUT_ETC2 && _mesa_is_gles3(ctx))
> > -return write_error(error, GL_INVALID_OPERATION);
> 
> The OpenGL ES 3.2 spec seems to be adding support for compressed
> CUBE_MAP_ARRAYs, and not clarifying what the behavior should have been
> in OpenGL ES 3.0. In this case, I think we should have a additional
> condition and not replace the existing one.

Sounds fine.

> 
> >target_can_be_compresed = _mesa_has_texture_cube_map_array(ctx);
> >break;
> > case GL_TEXTURE_3D:
> >switch (layout) {
> >case MESA_FORMAT_LAYOUT_ETC2:
> >   /* See ETC2/EAC comment in case GL_TEXTURE_CUBE_MAP_ARRAY. */
> > - if (_mesa_is_gles3(ctx))
> > -return write_error(error, GL_INVALID_OPERATION);
> > + target_can_be_compresed = GL_TRUE;
> 
> None of the formats listed in table 8.17 have their 3D Tex. entry
> checked.
> 

Uh! Right, this chunk shouldn't be in the patch. I'll remove it.


Thank you!


J.A.

> -Nanley
> 
> >   break;
> >case MESA_FORMAT_LAYOUT_BPTC:
> >   target_can_be_compresed = 
> > ctx->Extensions.ARB_texture_compression_bptc;
> > -- 
> > 2.13.6
> > 
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Has anyone stressed radeonsi memory?

[Kai Wasserbäch]

Hey Matias,
Matias N. Goldberg wrote on 15.11.2017 16:51:
>> Why, doesn't your distro have LLVM development packages?
> They aren't as up to date. Keeping up-to-date with everything mesa needs is 
> exhausting.
> I started compiling LLVM from source when I needed to test an LLVM patch to 
> fix a GLSL shader compiler bug.
> 
> I also compile mesa from source (rather thank using Oibaf or Padoka's PPA for 
> Ubuntu) because as a graphics dev, being able to debug inside Mesa has proven 
> to be an invaluable tool.

you seem to be using Ubuntu or another Debian derivate. In that case you can get
development snapshot packages from Debian's LLVM maintainer at
.

Cheers,
Kai

P.S.@Michel: Maybe it would be helpful to add that URL to the Mesa documentation
somewhere?



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

[Mesa-dev] [Bug 103757] eglGetDisplay() is broken for Wayland

[bugzilla-daemon]

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

--- Comment #7 from Daniel Stone  ---
(In reply to Michael Olbrich from comment #6)
> (In reply to Daniel Stone from comment #2)
> 
> > Michael, I'll attach a compiled but untested patch; can you please let me
> > know if it helps?
> 
> Looks good. It does the right thing for wayland and drm at least.
> is _eglPointerIsDereferencable() sufficient to ensure that the whole string
> is accessible?

Good point - I guess it'd have to be if
(_eglPointerIsDereferencable(child_pointer) &&
_eglPointerIsDereferencable(((char *) child_pointer) + strlen("wl_display") +
1) && strcmp(interface->name, "wl_display") == 0) ... ugh. Does that work for
you?

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

[Mesa-dev] [PATCH] etnaviv: enable full overwrite when no color buffer is present

[Lucas Stach]

The OVERWRITE bit disables destination fetches, which is exactly what
we want when there is no valid color buffer bound.

Signed-off-by: Lucas Stach 
---
 src/gallium/drivers/etnaviv/etnaviv_blend.c | 4 ++--
 src/gallium/drivers/etnaviv/etnaviv_state.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_blend.c 
b/src/gallium/drivers/etnaviv/etnaviv_blend.c
index 1b432bd68715..9c23411d4ff7 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_blend.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_blend.c
@@ -131,8 +131,8 @@ etna_update_blend(struct etna_context *ctx)
 * - The color mask is 
 * - No blending is used
 */
-   bool full_overwrite = (rt0->colormask == 0xf) &&
- blend->fo_allowed;
+   bool full_overwrite = ((rt0->colormask == 0xf) && blend->fo_allowed) ||
+ !pfb->cbufs[0];
blend->PE_COLOR_FORMAT =
 VIVS_PE_COLOR_FORMAT_COMPONENTS(colormask) |
 COND(full_overwrite, VIVS_PE_COLOR_FORMAT_OVERWRITE);
diff --git a/src/gallium/drivers/etnaviv/etnaviv_state.c 
b/src/gallium/drivers/etnaviv/etnaviv_state.c
index fb033507f387..8b044b3ee8d3 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_state.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_state.c
@@ -185,7 +185,7 @@ etna_set_framebuffer_state(struct pipe_context *pctx,
   /* Clearing VIVS_PE_COLOR_FORMAT_COMPONENTS__MASK and
* VIVS_PE_COLOR_FORMAT_OVERWRITE prevents us from overwriting the
* color target */
-  cs->PE_COLOR_FORMAT = 0;
+  cs->PE_COLOR_FORMAT = VIVS_PE_COLOR_FORMAT_OVERWRITE;
   cs->PE_COLOR_STRIDE = 0;
   cs->TS_COLOR_STATUS_BASE.bo = NULL;
   cs->TS_COLOR_SURFACE_BASE.bo = NULL;
-- 
2.11.0

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

[Mesa-dev] [Bug 103757] eglGetDisplay() is broken for Wayland

[bugzilla-daemon]

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

--- Comment #6 from Michael Olbrich  ---
(In reply to Daniel Stone from comment #2)

> Michael, I'll attach a compiled but untested patch; can you please let me
> know if it helps?

Looks good. It does the right thing for wayland and drm at least.
is _eglPointerIsDereferencable() sufficient to ensure that the whole string is
accessible?

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

[Mesa-dev] Fwd: [Mesa-users] Thank you! Keep up the good work for older AMD Cards!

[Brian Paul]

FYI:

 Original Message 
Subject:[Mesa-users] Thank you! Keep up the good work for older AMD 
Cards!
Date:   Wed, 15 Nov 2017 13:56:22 +0100
From:   Thomas Zoller 
To: mesa-us...@lists.freedesktop.org

Hello,

i only want to say THANK YOU to all developers for extending the
livespan of my good old HD6950 (patched to HD6970). I am also impressed
about the trouble-free and powerful funktion of my ProBooks A8-3530MX APU.

I'm really looking forward to the new improvements in 17.3 / 17.4 like
mentioned by Phoronix.com. Keep up the good work!

Thomas

___
mesa-users mailing list
mesa-us...@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Dusers=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=3kv-8iY1Sk0m3l4pK646S6AVgi8JFWbQB0VokO_5YL0=1-CaaDMsnGm1BfT36iRwjKsWkstDGcO7CVsDmyhIlFo=

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

Re: [Mesa-dev] [PATCH v2 3/5] etnaviv: Add TS_SAMPLER formats to etnaviv_format

[Lucas Stach]

Am Dienstag, den 14.11.2017, 10:21 +0100 schrieb Wladimir J. van der
Laan:
> Sampler TS introduces yet another format enumeration for
> renderable+textureable formats. Introduce it into the etnaviv_format
> table as another column.
> 
> Signed-off-by: Wladimir J. van der Laan 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_format.c | 162 +++
> 
>  src/gallium/drivers/etnaviv/etnaviv_format.h |   3 +
>  2 files changed, 91 insertions(+), 74 deletions(-)
> 
> I changed this to add a new column to the table for the TS format
> (for all
> texturable formats) instead of a trick based on RS format and name as
> used
> before, as that didn't cover depth formats correctly.
> 
> (did not add Christian Gmeiner's reviewed-by as the patch changed
> 100%)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.c
> b/src/gallium/drivers/etnaviv/etnaviv_format.c
> index 3dd212f..7943c81 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_format.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_format.c
> @@ -40,6 +40,7 @@ struct etna_format {
> unsigned vtx;
> unsigned tex;
> unsigned rs;
> +   unsigned ts;
> boolean present;
> const unsigned char tex_swiz[4];
>  };
> @@ -53,6 +54,8 @@ struct etna_format {
>  #define RS_FORMAT_X8B8G8R8(RS_FORMAT_X8R8G8B8 |
> RS_FORMAT_RB_SWAP)
>  #define RS_FORMAT_A8B8G8R8(RS_FORMAT_A8R8G8B8 |
> RS_FORMAT_RB_SWAP)
>  
> +#define TS_SAMPLER_FORMAT_NONE  ETNA_NO_MATCH
> +
>  #define SWIZ(x,y,z,w) {\
> PIPE_SWIZZLE_##x,   \
> PIPE_SWIZZLE_##y,   \
> @@ -61,21 +64,23 @@ struct etna_format {
>  }
>  
>  /* vertex + texture */
> -#define VT(pipe, vtxfmt, texfmt, texswiz, rsfmt)  \
> +#define VT(pipe, vtxfmt, texfmt, texswiz, rsfmt, tsfmt)  \
> [PIPE_FORMAT_##pipe] = {   \
>    .vtx = FE_DATA_TYPE_##vtxfmt, \
>    .tex = TEXTURE_FORMAT_##texfmt, \
>    .rs = RS_FORMAT_##rsfmt,\
> +  .ts = TS_SAMPLER_FORMAT_##tsfmt,\
>    .present = 1,   \
>    .tex_swiz = texswiz,\
> }
>  
>  /* texture-only */
> -#define _T(pipe, fmt, swiz, rsfmt) \
> +#define _T(pipe, fmt, swiz, rsfmt, tsfmt) \
> [PIPE_FORMAT_##pipe] = {\
>    .vtx = ETNA_NO_MATCH,\
>    .tex = TEXTURE_FORMAT_##fmt, \
>    .rs = RS_FORMAT_##rsfmt, \
> +  .ts = TS_SAMPLER_FORMAT_##tsfmt, \
>    .present = 1,\
>    .tex_swiz = swiz,\
> }
> @@ -91,16 +96,16 @@ struct etna_format {
>  
>  static struct etna_format formats[PIPE_FORMAT_COUNT] = {
> /* 8-bit */
> -   VT(R8_UNORM,   UNSIGNED_BYTE, L8, SWIZ(X, 0, 0, 1), NONE),
> +   VT(R8_UNORM,   UNSIGNED_BYTE, L8, SWIZ(X, 0, 0, 1), NONE, NONE),
> V_(R8_SNORM,   BYTE,  NONE),
> V_(R8_UINT,UNSIGNED_BYTE, NONE),
> V_(R8_SINT,BYTE,  NONE),
> V_(R8_USCALED, UNSIGNED_BYTE, NONE),
> V_(R8_SSCALED, BYTE,  NONE),
>  
> -   _T(A8_UNORM, A8, SWIZ(X, Y, Z, W), NONE),
> -   _T(L8_UNORM, L8, SWIZ(X, Y, Z, W), NONE),
> -   _T(I8_UNORM, I8, SWIZ(X, Y, Z, W), NONE),
> +   _T(A8_UNORM, A8, SWIZ(X, Y, Z, W), NONE, NONE),
> +   _T(L8_UNORM, L8, SWIZ(X, Y, Z, W), NONE, NONE),
> +   _T(I8_UNORM, I8, SWIZ(X, Y, Z, W), NONE, NONE),
>  
> /* 16-bit */
> V_(R16_UNORM,   UNSIGNED_SHORT, NONE),
> @@ -111,17 +116,17 @@ static struct etna_format
> formats[PIPE_FORMAT_COUNT] = {
> V_(R16_SSCALED, SHORT,  NONE),
> V_(R16_FLOAT,   HALF_FLOAT, NONE),
>  
> -   _T(B4G4R4A4_UNORM, A4R4G4B4, SWIZ(X, Y, Z, W), A4R4G4B4),
> -   _T(B4G4R4X4_UNORM, X4R4G4B4, SWIZ(X, Y, Z, W), X4R4G4B4),
> +   _T(B4G4R4A4_UNORM, A4R4G4B4, SWIZ(X, Y, Z, W), A4R4G4B4,
> A4R4G4B4),
> +   _T(B4G4R4X4_UNORM, X4R4G4B4, SWIZ(X, Y, Z, W), X4R4G4B4,
> A4R4G4B4),
>  
> -   _T(L8A8_UNORM, A8L8, SWIZ(X, Y, Z, W), NONE),
> +   _T(L8A8_UNORM, A8L8, SWIZ(X, Y, Z, W), NONE, NONE),
>  
> -   _T(Z16_UNORM,  D16,  SWIZ(X, Y, Z, W), A4R4G4B4),
> -   _T(B5G6R5_UNORM,   R5G6B5,   SWIZ(X, Y, Z, W), R5G6B5),
> -   _T(B5G5R5A1_UNORM, A1R5G5B5, SWIZ(X, Y, Z, W), A1R5G5B5),
> -   _T(B5G5R5X1_UNORM, X1R5G5B5, SWIZ(X, Y, Z, W), X1R5G5B5),
> +   _T(Z16_UNORM,  D16,  SWIZ(X, Y, Z, W), A4R4G4B4, D16),
> +   _T(B5G6R5_UNORM,   R5G6B5,   SWIZ(X, Y, Z, W), R5G6B5, R5G6B5),
> +   _T(B5G5R5A1_UNORM, A1R5G5B5, SWIZ(X, Y, Z, W), A1R5G5B5,
> A1R5G5B5),
> +   _T(B5G5R5X1_UNORM, X1R5G5B5, SWIZ(X, Y, Z, W), X1R5G5B5,
> A1R5G5B5),
>  
> -   VT(R8G8_UNORM,   UNSIGNED_BYTE,  EXT_G8R8 | EXT_FORMAT, SWIZ(X,
> Y, 0, 1), NONE),
> +   VT(R8G8_UNORM,   UNSIGNED_BYTE,  EXT_G8R8 | EXT_FORMAT, SWIZ(X,
> Y, 0, 1), NONE, NONE),
> V_(R8G8_SNORM,   BYTE,   NONE),
> V_(R8G8_UINT,UNSIGNED_BYTE,  NONE),
> V_(R8G8_SINT,BYTE,   NONE),
> @@ -156,26 +161,26 @@ static 

Re: [Mesa-dev] Has anyone stressed radeonsi memory?

[Matias N. Goldberg]

Hi!

> Are you using the amdgpu kernel driver from an amdgpu-pro release or
> from the upstream Linux kernel? (If you're not sure, provide the dmesg
> output and Xorg log file)

> If the latter, can you try a 4.13 or 4.14 kernel and see if that works
> better?


I'm using upstream Linux kernel (without my distro's patches), with amdgpu (not 
pro).

I could try newer kernels.

> Why, doesn't your distro have LLVM development packages?
They aren't as up to date. Keeping up-to-date with everything mesa needs is 
exhausting.
I started compiling LLVM from source when I needed to test an LLVM patch to fix 
a GLSL shader compiler bug.

I also compile mesa from source (rather thank using Oibaf or Padoka's PPA for 
Ubuntu) because as a graphics dev, being able to debug inside Mesa has proven 
to be an invaluable tool.


So I take it from your questions, that this behavior I saw isn't exactly 
"normal" or "expected" and I should dedicate some time to see if I can repro in 
newer versions, and if possible create a small repro.

Thanks,

Cheers
Matias

De: Michel Dänzer 
Para: Matias N. Goldberg  
CC: ML Mesa-dev 
Enviado: Martes, 14 de noviembre, 2017 14:43:28
Asunto: Re: [Mesa-dev] Has anyone stressed radeonsi memory?



On 13/11/17 04:39 AM, Matias N. Goldberg wrote:
> 
> I am on a Radeon RX 560 2GB; using mesa git-57c8ead0cd (So... not too new not 
> too old), Kernel 4.12.10
> 
> I've been having complaints about our WIP branch of Ogre 2.2 about out of 
> memory crashes, and I fixed them.
> 
> I made a stress test where 495 textures with very different resolutions (most 
> of them not power-of-2), and total memory from those textures is around 700MB 
> (for some reason radentop reports all 2GB of my card are used during this 
> stress test).
> Additionally, 495 cubes (one cube for each texture) are rendered to screen to 
> ensure driver keeps them resident.
> 
> The problem is, we have different strategies:
> 1. In one extreme, we can load every texture to a staging region, one at a 
> time; and then from staging region copy to the final texture.
> 2. In the other extreme, we load all textures to RAM at once, and use one 
> giant staging region.
> 
> Loading everything at once causes a GL_OUT_OF_MEMORY while creating the 
> staging area of 700MB. Ok... sounds sorta reasonable.
> 
> But things get interesting when loading using a staging area of 512MB:
> 1. Loading goes fine.
> 2. For a time, everything works fine.
> 3. If I hide all cubes so that they aren't shown anymore:
> 1. Framerate usually goes way down (not always), like 8 fps or so (should 
> be at 1000 fps while empty, around 200 fps while showing the cubes).
> How slow it becomes is not consistent.2. radeontop shows consumption goes 
> down a lot (like half or more).
> 3. A few seconds later, I almost always get a crash (SIGBUS) while 
> writing to an UBO buffer that had been persistently mapped (non-coherent) 
> since the beginning of the application.
> 4. Running through valgrind, I don't get a crash.
> 5. There are no errors reported by OpenGL.
> 4. I don't get a crash if I never hide the cubes.
> 
> Using a smaller staging area (256MB or lower) everything is always fine.
> 
> So... is this behavior expected?
> Am I uncovering a weird bug in how radeonsi/amdgpu-pro handle memory pages?

Are you using the amdgpu kernel driver from an amdgpu-pro release or
from the upstream Linux kernel? (If you're not sure, provide the dmesg
output and Xorg log file)

If the latter, can you try a 4.13 or 4.14 kernel and see if that works
better?



> I'd normally update to latest git, then create a test if the problem 
> persists; but I've pulled latest git and saw that it required me to recompile 
> llvm as well...

Why, doesn't your distro have LLVM development packages?


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

Re: [Mesa-dev] [PATCH v2 2/5] etnaviv: Check that resource has a valid TS in etna_resource_needs_flush

[Lucas Stach]

Am Dienstag, den 14.11.2017, 10:21 +0100 schrieb Wladimir J. van der
Laan:
> Resources only need a resolve-to-itself if their TS is valid for any
> level, not just if it happens to be allocated.
> 
> Signed-off-by: Wladimir J. van der Laan 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 13 +
>  src/gallium/drivers/etnaviv/etnaviv_resource.h |  6 +-
>  2 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 0a82807..1fb73c4 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -629,6 +629,19 @@ etna_resource_used(struct etna_context *ctx,
> struct pipe_resource *prsc,
> rsc->pending_ctx = ctx;
>  }
>  
> +bool
> +etna_resource_has_valid_ts(struct etna_resource *rsc)
> +{
> +   if (!rsc->ts_bo)
> +  return false;
> +
> +   for (int level = 0; level <= rsc->base.last_level; level++)
> +  if (rsc->levels[level].ts_valid)
> + return true;
> +
> +   return false;
> +}
> +
>  void
>  etna_resource_screen_init(struct pipe_screen *pscreen)
>  {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 0b135e2..11ccf8f 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -103,11 +103,15 @@ etna_resource_older(struct etna_resource *a,
> struct etna_resource *b)
> return (int)(a->seqno - b->seqno) < 0;
>  }
>  
> +/* returns TRUE if a resource has a TS, and it is valid for at least
> one level */
> +bool
> +etna_resource_has_valid_ts(struct etna_resource *res);
> +
>  /* returns TRUE if the resource needs a resolve to itself */
>  static inline bool
>  etna_resource_needs_flush(struct etna_resource *res)
>  {
> -   return res->ts_bo && ((int)(res->seqno - res->flush_seqno) > 0);
> +   return etna_resource_has_valid_ts(res) && ((int)(res->seqno -
> res->flush_seqno) > 0);
>  }
>  
>  /* is the resource only used on the sampler? */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 4/5] etnaviv: Flush TS cache before changing TS configuration

[Lucas Stach]

Am Dienstag, den 14.11.2017, 10:21 +0100 schrieb Wladimir J. van der Laan:
> This is to make sure that the TS is properly flushed to memory before
> rendering to a new surface starts.
> 
> Signed-off-by: Wladimir J. van der Laan 

This seems to work as intended, at least I wasn't able to spot missing
shadow tiles anymore with sampler TS enabled.

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_emit.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> index d313af6..b6b06e3 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> @@ -322,6 +322,11 @@ etna_emit_state(struct etna_context *ctx)
>    etna_stall(stream, SYNC_RECIPIENT_RA, SYNC_RECIPIENT_PE);
> }
>  
> +   /* Flush TS cache before changing TS configuration. */
> +   if (unlikely(dirty & ETNA_DIRTY_TS)) {
> +  etna_set_state(stream, VIVS_TS_FLUSH_CACHE, VIVS_TS_FLUSH_CACHE_FLUSH);
> +   }
> +
> /* If MULTI_SAMPLE_CONFIG.MSAA_SAMPLES changed, clobber affected shader
>  * state to make sure it is always rewritten. */
> if (unlikely(dirty & (ETNA_DIRTY_FRAMEBUFFER))) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103757] eglGetDisplay() is broken for Wayland

[bugzilla-daemon]

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

--- Comment #5 from Daniel Stone  ---
(In reply to Emil Velikov from comment #4)
> 
> I do recall mentioning that exposing the same symbol(s) will lead to bad
> experiences. Followed by some ideas...
> 

Yep, as per the discussion on inlining wayland_drm_buffer_get. :)

It certainly hurts, but then again breaking ABI and forcing every single
Wayland user to rebuild - probably having to change every symbol name in the
API to make sure there was no clash between the two when loaded - would be
uncharted depths of pain.

On the other hand, the solution is the same: look at the interface name, rather
than ever compare pointers equally. Unfortunately, we can't use the same
solution since the wayland-drm one only works for wl_resource in
libwayland-server rather than a plain wl_interface or a wl_proxy ... oh well.

> A better heuristic would be to use dladdr() for eglGetDisplay. See the
> analogous GBM patch [1].

I don't think that would necessarily fix it, particularly if the
wayland-client.so.1 being loaded differed, e.g. due to people linking their own
copies?

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

[Mesa-dev] [PATCH] egl/wayland: add dri2_wl_free_buffers() helper (v3)

[Gwan-gyeong Mun]

This deduplicates free routines of color_buffers array.

v2:
 - Add clear_all argument to check clearing all of color_buffers or not.
 - Fixes from Eric's review:
   a) polish check routine of check_lock and color_buffers[i].locked
   b) move 'native_buffer = NULL' to avoid leaking locked buffers
 - Fixes from Emil's review:
   a) drop the unneeded cast
   b) apply dri2_wl_free_buffers to update_buffers() and swrast_update_buffers()

v3: Use a dri2_surface_free_image() helper

Signed-off-by: Mun Gwan-gyeong 
---
 src/egl/drivers/dri2/platform_wayland.c | 85 +
 1 file changed, 33 insertions(+), 52 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index f03b6dc2ab..975596fc7d 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -252,6 +252,35 @@ dri2_wl_create_pixmap_surface(_EGLDriver *drv, _EGLDisplay 
*disp,
return NULL;
 }
 
+static void
+dri2_wl_free_buffers(struct dri2_egl_surface *dri2_surf, bool check_lock,
+ bool clear_all)
+{
+   for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
+  bool clear_buffer = false;
+
+  if (dri2_surf->color_buffers[i].native_buffer &&
+  (!check_lock || !dri2_surf->color_buffers[i].locked)) {
+ wl_buffer_destroy(dri2_surf->color_buffers[i].native_buffer);
+ dri2_surf->color_buffers[i].native_buffer = NULL;
+ dri2_surf->color_buffers[i].locked = false;
+ clear_buffer = true;
+  }
+
+  if (clear_all || clear_buffer) {
+ dri2_surface_free_image(_surf->base,
+ _surf->color_buffers[i].dri_image);
+ dri2_surface_free_image(_surf->base,
+ _surf->color_buffers[i].linear_copy);
+ if (dri2_surf->color_buffers[i].data)
+munmap(dri2_surf->color_buffers[i].data,
+   dri2_surf->color_buffers[i].data_size);
+
+ dri2_surf->color_buffers[i].data = NULL;
+  }
+   }
+}
+
 /**
  * Called via eglDestroySurface(), drv->API.DestroySurface().
  */
@@ -265,17 +294,7 @@ dri2_wl_destroy_surface(_EGLDriver *drv, _EGLDisplay 
*disp, _EGLSurface *surf)
 
dri2_dpy->core->destroyDrawable(dri2_surf->dri_drawable);
 
-   for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
-  if (dri2_surf->color_buffers[i].native_buffer)
- wl_buffer_destroy(dri2_surf->color_buffers[i].native_buffer);
-  dri2_surface_free_image(_surf->base,
-  _surf->color_buffers[i].dri_image);
-  dri2_surface_free_image(_surf->base,
-  _surf->color_buffers[i].linear_copy);
-  if (dri2_surf->color_buffers[i].data)
- munmap(dri2_surf->color_buffers[i].data,
-dri2_surf->color_buffers[i].data_size);
-   }
+   dri2_wl_free_buffers(dri2_surf, false, true);
 
if (dri2_dpy->dri2)
   dri2_egl_surface_free_local_buffers(dri2_surf);
@@ -307,22 +326,7 @@ dri2_wl_release_buffers(struct dri2_egl_surface *dri2_surf)
struct dri2_egl_display *dri2_dpy =
   dri2_egl_display(dri2_surf->base.Resource.Display);
 
-   for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
-  if (dri2_surf->color_buffers[i].native_buffer &&
-  !dri2_surf->color_buffers[i].locked)
- wl_buffer_destroy(dri2_surf->color_buffers[i].native_buffer);
-  dri2_surface_free_image(_surf->base,
-  _surf->color_buffers[i].dri_image);
-  dri2_surface_free_image(_surf->base,
-  _surf->color_buffers[i].linear_copy);
-  if (dri2_surf->color_buffers[i].data)
- munmap(dri2_surf->color_buffers[i].data,
-dri2_surf->color_buffers[i].data_size);
-
-  dri2_surf->color_buffers[i].native_buffer = NULL;
-  dri2_surf->color_buffers[i].data = NULL;
-  dri2_surf->color_buffers[i].locked = false;
-   }
+   dri2_wl_free_buffers(dri2_surf, true, true);
 
if (dri2_dpy->dri2)
   dri2_egl_surface_free_local_buffers(dri2_surf);
@@ -487,9 +491,6 @@ back_bo_to_dri_buffer(struct dri2_egl_surface *dri2_surf, 
__DRIbuffer *buffer)
 static int
 update_buffers(struct dri2_egl_surface *dri2_surf)
 {
-   struct dri2_egl_display *dri2_dpy =
-  dri2_egl_display(dri2_surf->base.Resource.Display);
-
if (dri2_surf->base.Width != dri2_surf->wl_win->width ||
dri2_surf->base.Height != dri2_surf->wl_win->height) {
 
@@ -509,18 +510,7 @@ update_buffers(struct dri2_egl_surface *dri2_surf)
/* If we have an extra unlocked buffer at this point, we had to do triple
 * buffering for a while, but now can go back to just double buffering.
 * That means we can free any unlocked buffer now. */
-   for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
-  if (!dri2_surf->color_buffers[i].locked &&
-  dri2_surf->color_buffers[i].native_buffer) 

[Mesa-dev] [PATCH] egl: add dri2_surface_free_image() helper (v4)

[Gwan-gyeong Mun]

To share common free DRIimage code.

In preparation to adding of new platform which uses this helper.

v2:
 - Fixes from Eric's review:
   a) Split out series of refactor for helpers to a separate series.
   b) Add the new helper function and use them to replace the old code in the
  same patch.

v3: Fixes from Emil and Gurchetan's review
  - Follow the naming convention which prevents too verbose name of functions.
a) use a dri2_surface_$action_$object naming convention
b) change a first argument type "struct dri2_egl_surface" to "_EGLSurface".

v4: Fixes from Gurchetan's review
  - add dri2_surface_free_image() helper for refactoring of almost identical
functions. [1]

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

Signed-off-by: Mun Gwan-gyeong 
---
 src/egl/drivers/dri2/egl_dri2.c | 11 +++
 src/egl/drivers/dri2/egl_dri2.h |  3 +++
 src/egl/drivers/dri2/platform_android.c | 18 +++---
 src/egl/drivers/dri2/platform_surfaceless.c | 14 +-
 src/egl/drivers/dri2/platform_wayland.c | 26 --
 5 files changed, 30 insertions(+), 42 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 8861742c17..84367e69fd 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1085,6 +1085,17 @@ dri2_egl_surface_free_local_buffers(struct 
dri2_egl_surface *dri2_surf)
}
 }
 
+void
+dri2_surface_free_image(_EGLSurface *surf, __DRIimage **img)
+{
+   struct dri2_egl_display *dri2_dpy = 
dri2_egl_display(surf->Resource.Display);
+
+   if (*img) {
+  dri2_dpy->image->destroyImage(*img);
+  *img = NULL;
+   }
+}
+
 /**
  * Called via eglTerminate(), drv->API.Terminate().
  *
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index cbeedadd4b..dda41117c6 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -452,6 +452,9 @@ dri2_egl_surface_alloc_local_buffer(struct dri2_egl_surface 
*dri2_surf,
 void
 dri2_egl_surface_free_local_buffers(struct dri2_egl_surface *dri2_surf);
 
+void
+dri2_surface_free_image(_EGLSurface *surf, __DRIimage **img);
+
 EGLBoolean
 dri2_init_surface(_EGLSurface *surf, _EGLDisplay *dpy, EGLint type,
 _EGLConfig *conf, const EGLint *attrib_list, EGLBoolean 
enable_out_fence);
diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 24e5ddebf9..3d6dd2e1e7 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -250,10 +250,7 @@ droid_window_enqueue_buffer(_EGLDisplay *disp, struct 
dri2_egl_surface *dri2_sur
 
mtx_lock(>Mutex);
 
-   if (dri2_surf->dri_image_back) {
-  dri2_dpy->image->destroyImage(dri2_surf->dri_image_back);
-  dri2_surf->dri_image_back = NULL;
-   }
+   dri2_surface_free_image(_surf->base, _surf->dri_image_back);
 
return EGL_TRUE;
 }
@@ -377,17 +374,8 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *surf)
   dri2_surf->window->common.decRef(_surf->window->common);
}
 
-   if (dri2_surf->dri_image_back) {
-  _eglLog(_EGL_DEBUG, "%s : %d : destroy dri_image_back", __func__, 
__LINE__);
-  dri2_dpy->image->destroyImage(dri2_surf->dri_image_back);
-  dri2_surf->dri_image_back = NULL;
-   }
-
-   if (dri2_surf->dri_image_front) {
-  _eglLog(_EGL_DEBUG, "%s : %d : destroy dri_image_front", __func__, 
__LINE__);
-  dri2_dpy->image->destroyImage(dri2_surf->dri_image_front);
-  dri2_surf->dri_image_front = NULL;
-   }
+   dri2_surface_free_image(surf, _surf->dri_image_back);
+   dri2_surface_free_image(surf, _surf->dri_image_front);
 
dri2_dpy->core->destroyDrawable(dri2_surf->dri_drawable);
 
diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
b/src/egl/drivers/dri2/platform_surfaceless.c
index 977b046016..959d587c88 100644
--- a/src/egl/drivers/dri2/platform_surfaceless.c
+++ b/src/egl/drivers/dri2/platform_surfaceless.c
@@ -50,18 +50,6 @@ surfaceless_alloc_image(struct dri2_egl_display *dri2_dpy,
 NULL);
 }
 
-static void
-surfaceless_free_images(struct dri2_egl_surface *dri2_surf)
-{
-   struct dri2_egl_display *dri2_dpy =
-  dri2_egl_display(dri2_surf->base.Resource.Display);
-
-   if (dri2_surf->front) {
-  dri2_dpy->image->destroyImage(dri2_surf->front);
-  dri2_surf->front = NULL;
-   }
-}
-
 static int
 surfaceless_image_get_buffers(__DRIdrawable *driDrawable,
 unsigned int format,
@@ -161,7 +149,7 @@ surfaceless_destroy_surface(_EGLDriver *drv, _EGLDisplay 
*disp, _EGLSurface *sur
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf);
 
-   surfaceless_free_images(dri2_surf);
+   dri2_surface_free_image(_surf->base, _surf->front);
 
dri2_dpy->core->destroyDrawable(dri2_surf->dri_drawable);

[Mesa-dev] [PATCH] egl: refactor color_buffers structure for deduplicating (v2)

[Gwan-gyeong Mun]

This is added for preventing adding of new color buffers structure and back*
when new platform backend is added.
This refactoring separates out the common and platform specific bits.
This makes odd casting in the platform_foo.c but it prevents adding of new
ifdef magic.
Because of color_buffers array size is different on android and wayland /drm,
it adds COLOR_BUFFERS_SIZE macro.
 - android's color buffers array size is 3.
   drm & wayland's color buffers array size is 4.

Fixes from Rob's review:
 - refactor to separate out the common and platform specific bits.

Fixes from Emil's review:
 - use suggested color buffers structure shape.
   it makes a buffer pointer of each platform to void pointer type.

v2: Fixes from Emil's review
  a) change ifdef macro of "HAVE_WAYLAND_PLATFORM or HAVE_DRM_PLATFORM" to
 "HAVE_ANDROID_PLATFORM" for COLOR_BUFFERS_SIZE.
  b) drop the unneeded indentation of comment.
  c) drop ifdef macro of HAVE_WAYLAND_PLATFORM from color_buffers structure
 for more generic and widespread helpers.
  d) drop unneeded $native_type -> void * cast and viceversa.
  e) create the local native_buffer of $native_type and cast on assignment.

Signed-off-by: Mun Gwan-gyeong 
---
 src/egl/drivers/dri2/egl_dri2.h | 32 --
 src/egl/drivers/dri2/platform_android.c | 10 +++---
 src/egl/drivers/dri2/platform_drm.c | 60 ++---
 src/egl/drivers/dri2/platform_wayland.c | 41 +++---
 4 files changed, 73 insertions(+), 70 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 0ec8f44dce..cbeedadd4b 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -65,6 +65,15 @@ struct zwp_linux_dmabuf_v1;
 
 #endif /* HAVE_ANDROID_PLATFORM */
 
+#ifdef HAVE_ANDROID_PLATFORM
+/* Usually Android uses at most triple buffers in ANativeWindow so hardcode
+ * the number of color_buffers to 3.
+ */
+#define COLOR_BUFFERS_SIZE 3
+#else
+#define COLOR_BUFFERS_SIZE 4
+#endif
+
 #include "eglconfig.h"
 #include "eglcontext.h"
 #include "egldisplay.h"
@@ -280,39 +289,26 @@ struct dri2_egl_surface
/* EGL-owned buffers */
__DRIbuffer   *local_buffers[__DRI_BUFFER_COUNT];
 
-#if defined(HAVE_WAYLAND_PLATFORM) || defined(HAVE_DRM_PLATFORM)
+   /* Used to record all the buffers created by each platform's native window
+* and their ages.
+*/
struct {
-#ifdef HAVE_WAYLAND_PLATFORM
-  struct wl_buffer   *wl_buffer;
+  void *native_buffer; // aka wl_buffer/gbm_bo/ANativeWindowBuffer
   __DRIimage *dri_image;
   /* for is_different_gpu case. NULL else */
   __DRIimage *linear_copy;
   /* for swrast */
   void *data;
   int data_size;
-#endif
-#ifdef HAVE_DRM_PLATFORM
-  struct gbm_bo   *bo;
-#endif
   boollocked;
   int age;
-   } color_buffers[4], *back, *current;
-#endif
+   } color_buffers[COLOR_BUFFERS_SIZE], *back, *current;
 
 #ifdef HAVE_ANDROID_PLATFORM
struct ANativeWindow *window;
struct ANativeWindowBuffer *buffer;
__DRIimage *dri_image_back;
__DRIimage *dri_image_front;
-
-   /* Used to record all the buffers created by ANativeWindow and their ages.
-* Usually Android uses at most triple buffers in ANativeWindow
-* so hardcode the number of color_buffers to 3.
-*/
-   struct {
-  struct ANativeWindowBuffer *buffer;
-  int age;
-   } color_buffers[3], *back;
 #endif
 
 #if defined(HAVE_SURFACELESS_PLATFORM)
diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 63223e9a69..24e5ddebf9 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -193,10 +193,10 @@ droid_window_dequeue_buffer(struct dri2_egl_surface 
*dri2_surf)
 */
EGLBoolean updated = EGL_FALSE;
for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
-  if (!dri2_surf->color_buffers[i].buffer) {
- dri2_surf->color_buffers[i].buffer = dri2_surf->buffer;
+  if (!dri2_surf->color_buffers[i].native_buffer) {
+ dri2_surf->color_buffers[i].native_buffer = dri2_surf->buffer;
   }
-  if (dri2_surf->color_buffers[i].buffer == dri2_surf->buffer) {
+  if (dri2_surf->color_buffers[i].native_buffer == dri2_surf->buffer) {
  dri2_surf->back = _surf->color_buffers[i];
  updated = EGL_TRUE;
  break;
@@ -208,10 +208,10 @@ droid_window_dequeue_buffer(struct dri2_egl_surface 
*dri2_surf)
* the color_buffers
*/
   for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
- dri2_surf->color_buffers[i].buffer = NULL;
+ dri2_surf->color_buffers[i].native_buffer = NULL;
  dri2_surf->color_buffers[i].age = 0;
   }
-  dri2_surf->color_buffers[0].buffer = dri2_surf->buffer;
+  dri2_surf->color_buffers[0].native_buffer = 

[Mesa-dev] [Bug 103757] eglGetDisplay() is broken for Wayland

[bugzilla-daemon]

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

--- Comment #4 from Emil Velikov  ---

I do recall mentioning that exposing the same symbol(s) will lead to bad
experiences. Followed by some ideas...


WRT eglGetDisplay - I'd recommend moving towards the EGL_*_platform_*
extensions ASAP - EGL_EXT_platform_wayland or EGL_KHR_platform_wayland in this
case.

A better heuristic would be to use dladdr() for eglGetDisplay. See the
analogous GBM patch [1].


https://patchwork.freedesktop.org/patch/187918/

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

Re: [Mesa-dev] [PATCH v2] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

[Eric Engestrom]

On Wednesday, 2017-11-15 15:35:49 +0100, Nicolai Hähnle wrote:
> From: Nicolai Hähnle 
> 
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
> 
> Cc: Jon Turney 
> Cc: Rob Herring 
> Cc: Alexander von Gluck IV 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
> Fixes: f1a364878431 ("threads: update for late C11 changes")
> ---
>  SConstruct  | 7 +++
>  configure.ac| 1 +
>  include/c11/threads_posix.h | 2 +-
>  meson.build | 2 +-
>  4 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/SConstruct b/SConstruct
> index a59a8ea210e..1ef134af27d 100644
> --- a/SConstruct
> +++ b/SConstruct
> @@ -122,20 +122,27 @@ if env['crosscompile'] and not env['embedded']:
>  Export('env')
>  
>  SConscript(
>  'src/SConscript',
>  variant_dir = host_env['build_dir'],
>  duplicate = 0, # 
> http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
>  )
>  
>  env = target_env
>  
> +if env['platform'] != 'windows':
> +   # This is quite incomplete, but it hopefully covers the platforms that
> +   # people actually use SCons on...
> +   env.Append(CPPDEFINES= [
> +  'HAVE_TIMESPEC_GET',
> +   ])

I'm not sure how scons is structured, but maybe you can use
check_functions() from scons/gallium.py, or move it maybe?

Other than that, the rest of the patch looks good to me:
Reviewed-by: Eric Engestrom 

> +
>  Export('env')
>  
>  ###
>  # Invoke SConscripts
>  
>  # TODO: Build several variants at the same time?
>  # http://www.scons.org/wiki/SimultaneousVariantBuilds
>  
>  SConscript(
>   'src/SConscript',
> diff --git a/configure.ac b/configure.ac
> index 411c4f6b3e0..a7ae920ab9c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -841,20 +841,21 @@ if test "x$enable_asm" = xyes; then
>  AC_MSG_RESULT([no, platform not supported])
>  ;;
>  esac
>  fi
>  
>  AC_HEADER_MAJOR
>  AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
>  AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
>  AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
>  AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
> +AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
>  
>  AC_MSG_CHECKING([whether strtod has locale support])
>  AC_LINK_IFELSE([AC_LANG_SOURCE([[
>  #define _GNU_SOURCE
>  #include 
>  #include 
>  #ifdef HAVE_XLOCALE_H
>  #include 
>  #endif
>  int main() {
> diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
> index 2d7ac1326de..45cb6075e6e 100644
> --- a/include/c11/threads_posix.h
> +++ b/include/c11/threads_posix.h
> @@ -375,21 +375,21 @@ tss_get(tss_t key)
>  // 7.25.6.4
>  static inline int
>  tss_set(tss_t key, void *val)
>  {
>  return (pthread_setspecific(key, val) == 0) ? thrd_success : thrd_error;
>  }
>  
>  
>  /* 7.25.7 Time functions */
>  // 7.25.6.1
> -#ifdef __HAIKU__
> +#ifndef HAVE_TIMESPEC_GET
>  static inline int
>  timespec_get(struct timespec *ts, int base)
>  {
>  if (!ts) return 0;
>  if (base == TIME_UTC) {
>  clock_gettime(CLOCK_REALTIME, ts);
>  return base;
>  }
>  return 0;
>  }
> diff --git a/meson.build b/meson.build
> index 1c4200705f3..7fdc3c280e6 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -571,21 +571,21 @@ if cc.has_header_symbol('sys/sysmacros.h', 'major')
>  elif cc.has_header_symbol('sys/mkdev.h', 'major')
>pre_args += '-DMAJOR_IN_MKDEV'
>  endif
>  
>  foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h']
>if cc.has_header(h)
>  pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
>endif
>  endforeach
>  
> -foreach f : ['strtof', 'mkostemp', 'posix_memalign']
> +foreach f : ['strtof', 'mkostemp', 'posix_memalign', 'timespec_get']
>if cc.has_function(f)
>  pre_args += '-DHAVE_@0@'.format(f.to_upper())
>endif
>  endforeach
>  
>  # strtod locale support
>  if cc.links('''
>  #define _GNU_SOURCE
>  #include 
>  #include 
> -- 
> 2.11.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/4] radv: do not add the image BO in radv_set_depth_clear_regs()

[Samuel Pitoiset]

For the fast path, radv_fill_buffer() ensures that the BO is
already in the list. For the slow path, the depth surface is
part of the framebuffer which means the BO is added to the list
when the framebuffer is emitted.

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

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 0502be1a93..131b77f4b4 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1311,8 +1311,6 @@ radv_set_depth_clear_regs(struct radv_cmd_buffer 
*cmd_buffer,
if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
++reg_count;
 
-   radv_cs_add_buffer(cmd_buffer->device->ws, cmd_buffer->cs, image->bo, 
8);
-
radeon_emit(cmd_buffer->cs, PKT3(PKT3_WRITE_DATA, 2 + reg_count, 0));
radeon_emit(cmd_buffer->cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
S_370_WR_CONFIRM(1) |
-- 
2.15.0

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

[Mesa-dev] [PATCH 4/4] radv: only load needed depth clear regs for fast depth clears

[Samuel Pitoiset]

Similar to how the driver sets the depth clear regs after a
fast depth clear. Most of the time, this will copy a 32-bit reg
instead of a 64-bit reg.

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

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 131b77f4b4..56f4cdc12b 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1333,20 +1333,30 @@ static void
 radv_load_depth_clear_regs(struct radv_cmd_buffer *cmd_buffer,
   struct radv_image *image)
 {
+   VkImageAspectFlags aspects = vk_format_aspects(image->vk_format);
uint64_t va = radv_buffer_get_va(image->bo);
va += image->offset + image->clear_value_offset;
+   unsigned reg_offset = 0, reg_count = 0;
 
if (!image->surface.htile_size)
return;
 
+   if (aspects & VK_IMAGE_ASPECT_STENCIL_BIT) {
+   ++reg_count;
+   } else {
+   ++reg_offset;
+   va += 4;
+   }
+   if (aspects & VK_IMAGE_ASPECT_DEPTH_BIT)
+   ++reg_count;
 
radeon_emit(cmd_buffer->cs, PKT3(PKT3_COPY_DATA, 4, 0));
radeon_emit(cmd_buffer->cs, COPY_DATA_SRC_SEL(COPY_DATA_MEM) |
COPY_DATA_DST_SEL(COPY_DATA_REG) |
-   COPY_DATA_COUNT_SEL);
+   (reg_count == 2 ? COPY_DATA_COUNT_SEL : 0));
radeon_emit(cmd_buffer->cs, va);
radeon_emit(cmd_buffer->cs, va >> 32);
-   radeon_emit(cmd_buffer->cs, R_028028_DB_STENCIL_CLEAR >> 2);
+   radeon_emit(cmd_buffer->cs, (R_028028_DB_STENCIL_CLEAR + 4 * 
reg_offset) >> 2);
radeon_emit(cmd_buffer->cs, 0);
 
radeon_emit(cmd_buffer->cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
-- 
2.15.0

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

[Mesa-dev] [PATCH 2/4] radv: remove useless assertion in emit_depthstencil_clear()

[Samuel Pitoiset]

Already checked in emit_clear().

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_meta_clear.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index 7b6ab4a9b7..b42ecedfc9 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -614,10 +614,6 @@ emit_depthstencil_clear(struct radv_cmd_buffer *cmd_buffer,
const uint32_t samples_log2 = ffs(samples) - 1;
VkCommandBuffer cmd_buffer_h = radv_cmd_buffer_to_handle(cmd_buffer);
 
-   assert(aspects == VK_IMAGE_ASPECT_DEPTH_BIT ||
-  aspects == VK_IMAGE_ASPECT_STENCIL_BIT ||
-  aspects == (VK_IMAGE_ASPECT_DEPTH_BIT |
-  VK_IMAGE_ASPECT_STENCIL_BIT));
assert(pass_att != VK_ATTACHMENT_UNUSED);
 
if (!(aspects & VK_IMAGE_ASPECT_DEPTH_BIT))
-- 
2.15.0

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

[Mesa-dev] [PATCH 1/4] radv: remove useless check in radv_set_depth_clear_regs()

[Samuel Pitoiset]

aspects can't be zero and there is an assertion that ensures
it's not in emit_clear().

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

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 146dcf439f..0502be1a93 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1299,7 +1299,7 @@ radv_set_depth_clear_regs(struct radv_cmd_buffer 
*cmd_buffer,
va += image->offset + image->clear_value_offset;
unsigned reg_offset = 0, reg_count = 0;
 
-   if (!image->surface.htile_size || !aspects)
+   if (!image->surface.htile_size)
return;
 
if (aspects & VK_IMAGE_ASPECT_STENCIL_BIT) {
-- 
2.15.0

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

[Mesa-dev] [PATCH] radv: inline radv_upload_{compute, graphics}_shader_descriptors()

[Samuel Pitoiset]

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

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 18503cd513..146dcf439f 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1830,7 +1830,7 @@ radv_cmd_buffer_update_vertex_descriptors(struct 
radv_cmd_buffer *cmd_buffer, bo
return true;
 }
 
-static bool
+static inline bool
 radv_upload_graphics_shader_descriptors(struct radv_cmd_buffer *cmd_buffer, 
bool pipeline_is_dirty)
 {
if (!radv_cmd_buffer_update_vertex_descriptors(cmd_buffer, 
pipeline_is_dirty))
@@ -3584,7 +3584,7 @@ radv_emit_dispatch_packets(struct radv_cmd_buffer 
*cmd_buffer,
assert(cmd_buffer->cs->cdw <= cdw_max);
 }
 
-static void
+static inline void
 radv_upload_compute_shader_descriptors(struct radv_cmd_buffer *cmd_buffer)
 {
radv_flush_descriptors(cmd_buffer, VK_SHADER_STAGE_COMPUTE_BIT);
-- 
2.15.0

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

[Mesa-dev] [PATCH v2] threads, configure.ac, meson.build: define and use HAVE_TIMESPEC_GET

[Nicolai Hähnle]

From: Nicolai Hähnle 

v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds

Cc: Jon Turney 
Cc: Rob Herring 
Cc: Alexander von Gluck IV 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11 changes")
---
 SConstruct  | 7 +++
 configure.ac| 1 +
 include/c11/threads_posix.h | 2 +-
 meson.build | 2 +-
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/SConstruct b/SConstruct
index a59a8ea210e..1ef134af27d 100644
--- a/SConstruct
+++ b/SConstruct
@@ -122,20 +122,27 @@ if env['crosscompile'] and not env['embedded']:
 Export('env')
 
 SConscript(
 'src/SConscript',
 variant_dir = host_env['build_dir'],
 duplicate = 0, # 
http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
 )
 
 env = target_env
 
+if env['platform'] != 'windows':
+   # This is quite incomplete, but it hopefully covers the platforms that
+   # people actually use SCons on...
+   env.Append(CPPDEFINES= [
+  'HAVE_TIMESPEC_GET',
+   ])
+
 Export('env')
 
 ###
 # Invoke SConscripts
 
 # TODO: Build several variants at the same time?
 # http://www.scons.org/wiki/SimultaneousVariantBuilds
 
 SConscript(
'src/SConscript',
diff --git a/configure.ac b/configure.ac
index 411c4f6b3e0..a7ae920ab9c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -841,20 +841,21 @@ if test "x$enable_asm" = xyes; then
 AC_MSG_RESULT([no, platform not supported])
 ;;
 esac
 fi
 
 AC_HEADER_MAJOR
 AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
 AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
 AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
 AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
+AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
 
 AC_MSG_CHECKING([whether strtod has locale support])
 AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #define _GNU_SOURCE
 #include 
 #include 
 #ifdef HAVE_XLOCALE_H
 #include 
 #endif
 int main() {
diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
index 2d7ac1326de..45cb6075e6e 100644
--- a/include/c11/threads_posix.h
+++ b/include/c11/threads_posix.h
@@ -375,21 +375,21 @@ tss_get(tss_t key)
 // 7.25.6.4
 static inline int
 tss_set(tss_t key, void *val)
 {
 return (pthread_setspecific(key, val) == 0) ? thrd_success : thrd_error;
 }
 
 
 /* 7.25.7 Time functions */
 // 7.25.6.1
-#ifdef __HAIKU__
+#ifndef HAVE_TIMESPEC_GET
 static inline int
 timespec_get(struct timespec *ts, int base)
 {
 if (!ts) return 0;
 if (base == TIME_UTC) {
 clock_gettime(CLOCK_REALTIME, ts);
 return base;
 }
 return 0;
 }
diff --git a/meson.build b/meson.build
index 1c4200705f3..7fdc3c280e6 100644
--- a/meson.build
+++ b/meson.build
@@ -571,21 +571,21 @@ if cc.has_header_symbol('sys/sysmacros.h', 'major')
 elif cc.has_header_symbol('sys/mkdev.h', 'major')
   pre_args += '-DMAJOR_IN_MKDEV'
 endif
 
 foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h']
   if cc.has_header(h)
 pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
   endif
 endforeach
 
-foreach f : ['strtof', 'mkostemp', 'posix_memalign']
+foreach f : ['strtof', 'mkostemp', 'posix_memalign', 'timespec_get']
   if cc.has_function(f)
 pre_args += '-DHAVE_@0@'.format(f.to_upper())
   endif
 endforeach
 
 # strtod locale support
 if cc.links('''
 #define _GNU_SOURCE
 #include 
 #include 
-- 
2.11.0

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

[Mesa-dev] [Bug 103732] swr often gets stuck in piglit's glx-multi-context-single-window test

[bugzilla-daemon]

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

--- Comment #5 from Michel Dänzer  ---
(In reply to Andrés Gómez García from comment #4)
> FWIW, with similar conditions, I've not been able to reproduce with
> llvmpipe, softpipe nor i965.

Hmm, then maybe it is related to threading done by SWR and radeonsi.

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

[Mesa-dev] [Bug 103762] [swr] piglit ext_transform_feedback-immediate-reuse-uniform-buffer has a ~5% pass rate

[bugzilla-daemon]

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

Andrés Gómez García  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=90081

--- Comment #1 from Andrés Gómez García  ---
bug 90081 could be related (?)

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

[Mesa-dev] [Bug 90081] [llvmpipe] piglit ext_transform_feedback-immediate-reuse-uniform-buffer regression

[bugzilla-daemon]

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

Andrés Gómez García  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=103762

-- 
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 103762] [swr] piglit ext_transform_feedback-immediate-reuse-uniform-buffer has a ~5% pass rate

[bugzilla-daemon]

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

Bug ID: 103762
   Summary: [swr] piglit
ext_transform_feedback-immediate-reuse-uniform-buffer
has a ~5% pass rate
   Product: Mesa
   Version: 17.2
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: ago...@igalia.com
QA Contact: mesa-dev@lists.freedesktop.org

When running the complete "all" profile in piglit against mesa's swr driver,
ext_transform_feedback-immediate-reuse-uniform-buffer most of the time fails,
but not always.

It seems its pass rate is ~5%.

AFAIK, this is not new for 17.2.x not a recent regression.

A typical piglit report is as follows, although varies from failed run to run:


Detail  |   Value
+---
Returncode  |   1
+---
Time|   0:00:00.211612
+---
Stdout  | Probe color at (224,0)
|   Expected: 223 31 223
|   Observed: 0 0 0
| Probe color at (240,0)
|   Expected: 239 15 239
|   Observed: 0 0 0
+---
Stderr  | WR detected AVX2 
| vert shader  0x7f492c287000
| frag shader  0x7f492c285000
| so shader0x7f492c283000
| fetch shader 0x7f492c281000
| fetch shader 0x7f492c27f000
| SWR destroy screen!
+---
Environment | PIGLIT_PLATFORM="mixed_glx_egl"
PIGLIT_SOURCE_DIR="/home/local/piglit"
+---
Command |
/home/local/piglit/bin/ext_transform_feedback-immediate-reuse-uniform-buffer
-auto -fbo
+---
dmesg   |


Environment is an Ubuntu Xenial with custom LLVM packages installed and locally
compiled mesa and mesa dependencies. If needed, I can provide a docker image
with which to test.

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

[Mesa-dev] [Bug 103699] Latest mesa breaks firefox on kde plasma with compositing on

[bugzilla-daemon]

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

--- Comment #10 from Tapani Pälli  ---
(In reply to sergio.callegari from comment #9)
> Tried right now. Incidentally, I have always been working with SNA, since it
> is fine on haswell and snappier than glamor.
> 
> I still see the issue with mesa as of
> 
> 17.4 git snapshot taken on 17/11/15 07:30 commit id 65123e...
> 
> I'll try again when a newer build of a mesa snapshot is available for
> kubuntu 17.10 (likely tomorrow).

OK thanks, I was able to reproduce this just yesterday but today after update
from oibaf not anymore .. so I'm really confused what this is about :/

My testing has been with older plasma 5.10.5 though as this is what the other
bug 103655 is filed against. I will go through all the components today as I
did replace dri and libGL of my own but later replaced by doing "apt-get
install --reinstall" and menus still worked.

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

Re: [Mesa-dev] [PATCH 11/24] spirv_extensions: add list of extensions and to_string method

[Eric Engestrom]

On Wednesday, 2017-11-15 14:22:14 +0100, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro 
> 
> Ideally this should be generated somehow. One option would be gather
> all the extension dependencies listed on the core grammar, but there
> would be the possibility of not including some of the extensions.
> 
> Note that spirv-tools is doing it just slightly better, as it has a
> hardcoded list of extensions manually took from the registry, that
> they parse to get the enum and the to_string method (see
> generate_grammar_tables.py).
> ---
>  src/compiler/Makefile.sources |  2 +
>  src/compiler/spirv/spirv_extensions.c | 61 +++
>  src/compiler/spirv/spirv_extensions.h | 69 
> +++
>  3 files changed, 132 insertions(+)
>  create mode 100644 src/compiler/spirv/spirv_extensions.c
>  create mode 100644 src/compiler/spirv/spirv_extensions.h
> 
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index 2ab8e163a26..f198456c751 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -293,6 +293,8 @@ SPIRV_FILES = \
>   spirv/GLSL.std.450.h \
>   spirv/nir_spirv.h \
>   spirv/spirv.h \
> + spirv/spirv_extensions.c \
> + spirv/spirv_extensions.h \
>   spirv/spirv_info.h \
>   spirv/spirv_to_nir.c \
>   spirv/vtn_alu.c \

Please add to this patch:

8<
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index e5c8326aa066a580d79e..e7d2e57fa7007115d195 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -176,6 +176,8 @@ files_libnir = files(
   '../spirv/GLSL.std.450.h',
   '../spirv/nir_spirv.h',
   '../spirv/spirv.h',
+  '../spirv/spirv_extensions.c',
+  '../spirv/spirv_extensions.h',
   '../spirv/spirv_info.h',
   '../spirv/spirv_to_nir.c',
   '../spirv/vtn_alu.c',
>8

> diff --git a/src/compiler/spirv/spirv_extensions.c 
> b/src/compiler/spirv/spirv_extensions.c
> new file mode 100644
> index 000..64d61c49d31
> --- /dev/null
> +++ b/src/compiler/spirv/spirv_extensions.c
> @@ -0,0 +1,61 @@
> +/*
> + * 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 AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include "spirv.h"
> +#include "spirv_extensions.h"
> +
> +const char *
> +spirv_extensions_to_string(SpvExtension ext)
> +{
> +   switch (ext) {
> +   case SPV_AMD_shader_explicit_vertex_parameter: return 
> "SPV_AMD_shader_explicit_vertex_parameter";
> +   case SPV_AMD_shader_trinary_minmax: return 
> "SPV_AMD_shader_trinary_minmax";
> +   case SPV_AMD_gcn_shader: return "SPV_AMD_gcn_shader";
> +   case SPV_KHR_shader_ballot: return "SPV_KHR_shader_ballot";
> +   case SPV_AMD_shader_ballot: return "SPV_AMD_shader_ballot";
> +   case SPV_AMD_gpu_shader_half_float: return 
> "SPV_AMD_gpu_shader_half_float";
> +   case SPV_KHR_shader_draw_parameters: return 
> "SPV_KHR_shader_draw_parameters";
> +   case SPV_KHR_subgroup_vote: return "SPV_KHR_subgroup_vote";
> +   case SPV_KHR_16bit_storage: return "SPV_KHR_16bit_storage";
> +   case SPV_KHR_device_group: return "SPV_KHR_device_group";
> +   case SPV_KHR_multiview: return "SPV_KHR_multiview";
> +   case SPV_NVX_multiview_per_view_attributes: return 
> "SPV_NVX_multiview_per_view_attributes";
> +   case SPV_NV_viewport_array2: return "SPV_NV_viewport_array2";
> +   case SPV_NV_stereo_view_rendering: return "SPV_NV_stereo_view_rendering";
> +   case SPV_NV_sample_mask_override_coverage: return 
> "SPV_NV_sample_mask_override_coverage";
> +   case SPV_NV_geometry_shader_passthrough: return 
> "SPV_NV_geometry_shader_passthrough";
> +   case SPV_AMD_texture_gather_bias_lod: return 
> "SPV_AMD_texture_gather_bias_lod";
> +   case SPV_KHR_storage_buffer_storage_class: return 
> "SPV_KHR_storage_buffer_storage_class";
> +   case 

Re: [Mesa-dev] [PATCH 10/24] spirv_extensions: add GL_ARB_spirv_extensions boilerplate

[Eric Engestrom]

On Wednesday, 2017-11-15 14:22:13 +0100, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro 
> 
> ---
>  src/mapi/glapi/gen/ARB_spirv_extensions.xml | 13 
>  src/mapi/glapi/gen/Makefile.am  |  1 +
>  src/mapi/glapi/gen/gl_API.xml   |  2 ++
>  src/mesa/Makefile.sources   |  2 ++
>  src/mesa/main/extensions_table.h|  1 +
>  src/mesa/main/get.c |  6 
>  src/mesa/main/get_hash_params.py|  3 ++
>  src/mesa/main/getstring.c   |  7 +
>  src/mesa/main/mtypes.h  |  1 +
>  src/mesa/main/spirvextensions.c | 42 +
>  src/mesa/main/spirvextensions.h | 49 
> +
>  11 files changed, 127 insertions(+)
>  create mode 100644 src/mapi/glapi/gen/ARB_spirv_extensions.xml
>  create mode 100644 src/mesa/main/spirvextensions.c
>  create mode 100644 src/mesa/main/spirvextensions.h
> 
> diff --git a/src/mapi/glapi/gen/ARB_spirv_extensions.xml 
> b/src/mapi/glapi/gen/ARB_spirv_extensions.xml
> new file mode 100644
> index 000..103393104c2
> --- /dev/null
> +++ b/src/mapi/glapi/gen/ARB_spirv_extensions.xml
> @@ -0,0 +1,13 @@
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
> index 35e37e95a9f..9a7a268adbf 100644
> --- a/src/mapi/glapi/gen/Makefile.am
> +++ b/src/mapi/glapi/gen/Makefile.am
> @@ -167,6 +167,7 @@ API_XML = \
>   ARB_shader_subroutine.xml \
>   ARB_shader_storage_buffer_object.xml \
>   ARB_sparse_buffer.xml \
> + ARB_spirv_extensions.xml \
>   ARB_sync.xml \
>   ARB_tessellation_shader.xml \
>   ARB_texture_barrier.xml \

For this and the other autotools hunk further down, please add to this
patch:

8<
diff --git a/src/mapi/glapi/gen/meson.build b/src/mapi/glapi/gen/meson.build
index 69ef57bc1460e8f92411..54d8d8076221b6c923c0 100644
--- a/src/mapi/glapi/gen/meson.build
+++ b/src/mapi/glapi/gen/meson.build
@@ -74,6 +74,7 @@ api_xml_files = files(
   'ARB_shader_subroutine.xml',
   'ARB_shader_storage_buffer_object.xml',
   'ARB_sparse_buffer.xml',
+  'ARB_spirv_extensions.xml',
   'ARB_sync.xml',
   'ARB_tessellation_shader.xml',
   'ARB_texture_barrier.xml',
diff --git a/src/mesa/meson.build b/src/mesa/meson.build
index b839fd0298189263d632..f20939f94b1e368e799d 100644
--- a/src/mesa/meson.build
+++ b/src/mesa/meson.build
@@ -243,6 +243,8 @@ files_libmesa_common = files(
   'main/shader_query.cpp',
   'main/shared.c',
   'main/shared.h',
+  'main/spirvextensions.c',
+  'main/spirvextensions.h',
   'main/state.c',
   'main/state.h',
   'main/stencil.c',
>8

> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index d3594cfe195..6b81160b5a1 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -8404,6 +8404,8 @@
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>  
> + xmlns:xi="http://www.w3.org/2001/XInclude"/>
> +
>  
>  
>  
> diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
> index e9680bf004c..944c8bcc812 100644
> --- a/src/mesa/Makefile.sources
> +++ b/src/mesa/Makefile.sources
> @@ -203,6 +203,8 @@ MAIN_FILES = \
>   main/shader_query.cpp \
>   main/shared.c \
>   main/shared.h \
> + main/spirvextensions.c \
> + main/spirvextensions.h \
>   main/state.c \
>   main/state.h \
>   main/stencil.c \
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index ab15ceb9414..06deabd0640 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -129,6 +129,7 @@ EXT(ARB_shading_language_420pack, 
> ARB_shading_language_420pack
>  EXT(ARB_shading_language_packing, ARB_shading_language_packing   
> , GLL, GLC,  x ,  x , 2011)
>  EXT(ARB_shadow  , ARB_shadow 
> , GLL,  x ,  x ,  x , 2001)
>  EXT(ARB_sparse_buffer   , ARB_sparse_buffer  
> , GLL, GLC,  x ,  x , 2014)
> +EXT(ARB_spirv_extensions, ARB_spirv_extensions   
> ,  x,  GLC,  x ,  x , 2016)
>  EXT(ARB_stencil_texturing   , ARB_stencil_texturing  
> , GLL, GLC,  x ,  x , 2012)
>  EXT(ARB_sync, ARB_sync   
> , GLL, GLC,  x ,  x , 2003)
>  EXT(ARB_tessellation_shader , ARB_tessellation_shader
> ,  x , GLC,  x ,  x , 2009)
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index ea8d932b182..c97ec9efde9 100644
> --- a/src/mesa/main/get.c
> +++ b/src/mesa/main/get.c
> @@ -34,6 +34,7 @@
>  #include "get.h"
>  #include "macros.h"
>  #include "mtypes.h"
> +#include "spirvextensions.h"
>  #include "state.h"
>  #include "texcompress.h"
>  

[Mesa-dev] [Bug 103699] Latest mesa breaks firefox on kde plasma with compositing on

[bugzilla-daemon]

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

--- Comment #9 from sergio.calleg...@gmail.com ---
Tried right now. Incidentally, I have always been working with SNA, since it is
fine on haswell and snappier than glamor.

I still see the issue with mesa as of

17.4 git snapshot taken on 17/11/15 07:30 commit id 65123e...

I'll try again when a newer build of a mesa snapshot is available for kubuntu
17.10 (likely tomorrow).

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

Re: [Mesa-dev] Difference between Meson and autotools release builds

[Eric Engestrom]

On Wednesday, 2017-11-15 13:17:25 +, Rogovin, Kevin wrote:
> Thanks, I missed that; sorry for the mailing list chatter caused by
> missing the original e-mail on the material.

No worries, there's a lot of traffic, I'm pretty sure nobody read every
single emails of these lists :P

>  -Kevin
> 
> -Original Message-
> From: Eric Engestrom [mailto:eric.engest...@imgtec.com] 
> Sent: Wednesday, November 15, 2017 1:39 PM
> To: Rogovin, Kevin 
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] Difference between Meson and autotools release builds
> 
> On Wednesday, 2017-11-15 09:43:59 +, Rogovin, Kevin wrote:
> > Hi,
> > 
> > I do not know if anyone has noticed or if it is deliberate, but the meson 
> > builds have that assert()'s are active but the autotools release builds 
> > have that assert() is inactive.
> 
> Hi,
> 
> Yep, this is by design, meson decouples the build type (eg. "release") from 
> whether asserts are enabled; you can read more about it in this
> thread:
> https://lists.freedesktop.org/archives/mesa-dev/2017-November/175739.html
> 
> You can already read the not-yet-landed documentation in this patch:
> https://lists.freedesktop.org/archives/mesa-dev/2017-November/175854.html
> 
> (or if it lands before you read this, the up-to-date meson-for-mesa 
> documentation will live at: https://mesa3d.org/meson.html)
> 
> Cheers,
>   Eric
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/24] mesa: add GL_ARB_gl_spirv boilerplate

[Eric Engestrom]

On Wednesday, 2017-11-15 14:22:04 +0100, Eduardo Lima Mitev wrote:
> From: Nicolai Hähnle 
> 
> ---
>  src/mapi/glapi/gen/ARB_gl_spirv.xml | 21 ++
>  src/mapi/glapi/gen/Makefile.am  |  1 +
>  src/mapi/glapi/gen/gl_API.xml   |  4 +++
>  src/mapi/glapi/gen/gl_genexec.py|  1 +
>  src/mesa/Makefile.sources   |  2 ++
>  src/mesa/main/extensions_table.h|  1 +
>  src/mesa/main/glspirv.c | 33 +
>  src/mesa/main/glspirv.h | 51 
> +
>  src/mesa/main/mtypes.h  |  1 +
>  src/mesa/main/tests/dispatch_sanity.cpp |  3 ++
>  10 files changed, 118 insertions(+)
>  create mode 100644 src/mapi/glapi/gen/ARB_gl_spirv.xml
>  create mode 100644 src/mesa/main/glspirv.c
>  create mode 100644 src/mesa/main/glspirv.h
> 
> diff --git a/src/mapi/glapi/gen/ARB_gl_spirv.xml 
> b/src/mapi/glapi/gen/ARB_gl_spirv.xml
> new file mode 100644
> index 000..0dd615480f7
> --- /dev/null
> +++ b/src/mapi/glapi/gen/ARB_gl_spirv.xml
> @@ -0,0 +1,21 @@
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
> index 87d8517b7ba..35e37e95a9f 100644
> --- a/src/mapi/glapi/gen/Makefile.am
> +++ b/src/mapi/glapi/gen/Makefile.am
> @@ -144,6 +144,7 @@ API_XML = \
>   ARB_framebuffer_object.xml \
>   ARB_get_program_binary.xml \
>   ARB_get_texture_sub_image.xml \
> + ARB_gl_spirv.xml \
>   ARB_gpu_shader_fp64.xml \
>   ARB_gpu_shader_int64.xml \
>   ARB_gpu_shader5.xml \

For this and the other autotools hunk further down, please add to this
patch:

8<
diff --git a/src/mapi/glapi/gen/meson.build b/src/mapi/glapi/gen/meson.build
index 69ef57bc1460e8f92411..ddd0e856e3e5f8e89b01 100644
--- a/src/mapi/glapi/gen/meson.build
+++ b/src/mapi/glapi/gen/meson.build
@@ -52,6 +52,7 @@ api_xml_files = files(
   'ARB_framebuffer_object.xml',
   'ARB_get_program_binary.xml',
   'ARB_get_texture_sub_image.xml',
+  'ARB_gl_spirv.xml',
   'ARB_gpu_shader_fp64.xml',
   'ARB_gpu_shader_int64.xml',
   'ARB_gpu_shader5.xml',
diff --git a/src/mesa/meson.build b/src/mesa/meson.build
index b839fd0298189263d632..32135446999b5812a984 100644
--- a/src/mesa/meson.build
+++ b/src/mesa/meson.build
@@ -162,6 +162,8 @@ files_libmesa_common = files(
   'main/getstring.c',
   'main/glformats.c',
   'main/glformats.h',
+  'main/glspirv.c',
+  'main/glspirv.h',
   'main/glthread.c',
   'main/glthread.h',
   'main/glheader.h',
>8

> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index eb1d9b83b27..d3594cfe195 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -8400,6 +8400,10 @@
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>  
> +
> +
> + xmlns:xi="http://www.w3.org/2001/XInclude"/>
> +
>  
>  
>  
> diff --git a/src/mapi/glapi/gen/gl_genexec.py 
> b/src/mapi/glapi/gen/gl_genexec.py
> index b7b22328ff8..aaff9f230b3 100644
> --- a/src/mapi/glapi/gen/gl_genexec.py
> +++ b/src/mapi/glapi/gen/gl_genexec.py
> @@ -77,6 +77,7 @@ header = """/**
>  #include "main/eval.h"
>  #include "main/externalobjects.h"
>  #include "main/get.h"
> +#include "main/glspirv.h"
>  #include "main/feedback.h"
>  #include "main/fog.h"
>  #include "main/fbobject.h"
> diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
> index 6da1e3fef9d..e9680bf004c 100644
> --- a/src/mesa/Makefile.sources
> +++ b/src/mesa/Makefile.sources
> @@ -118,6 +118,8 @@ MAIN_FILES = \
>   main/getstring.c \
>   main/glformats.c \
>   main/glformats.h \
> + main/glspirv.c \
> + main/glspirv.h \
>   main/glthread.c \
>   main/glthread.h \
>   main/glheader.h \
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index 5b66e7d30df..ab15ceb9414 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -72,6 +72,7 @@ EXT(ARB_framebuffer_object  , 
> ARB_framebuffer_object
>  EXT(ARB_framebuffer_sRGB, EXT_framebuffer_sRGB   
> , GLL, GLC,  x ,  x , 1998)
>  EXT(ARB_get_program_binary  , dummy_true 
> , GLL, GLC,  x ,  x , 2010)
>  EXT(ARB_get_texture_sub_image   , dummy_true 
> , GLL, GLC,  x ,  x , 2014)
> +EXT(ARB_gl_spirv, ARB_gl_spirv   
> ,  x,  GLC,  x ,  x , 2016)
>  EXT(ARB_gpu_shader5 , ARB_gpu_shader5
> ,  x , GLC,  x ,  x , 2010)
>  EXT(ARB_gpu_shader_fp64 , ARB_gpu_shader_fp64
> ,  x , GLC,  x ,  x , 2010)
>  EXT(ARB_gpu_shader_int64, ARB_gpu_shader_int64   
>  

[Mesa-dev] [Bug 103732] swr often gets stuck in piglit's glx-multi-context-single-window test

[bugzilla-daemon]

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

--- Comment #4 from Andrés Gómez García  ---
FWIW, with similar conditions, I've not been able to reproduce with llvmpipe,
softpipe nor i965.

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

[Mesa-dev] [Bug 103128] [softpipe] piglit fs-ldexp regression

[bugzilla-daemon]

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

--- Comment #1 from Nicolai Hähnle  ---
I can reproduce this, will take a look now.

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

[Mesa-dev] [Bug 102122] [softpipe] piglit fdo10370 regression

[bugzilla-daemon]

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

--- Comment #1 from Nicolai Hähnle  ---
I cannot reproduce this on Mesa master by running:

$ GALLIUM_DRIVER=softpipe LIBGL_ALWAYS_SOFTWARE=true ./bin/fdo10370 -auto

What am I missing?

-- 
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 103757] eglGetDisplay() is broken for Wayland

[bugzilla-daemon]

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

--- Comment #3 from Daniel Stone  ---
Created attachment 135490
  --> https://bugs.freedesktop.org/attachment.cgi?id=135490=edit
egldisplay-try-interface-name-for-wl-display.patch

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

[Mesa-dev] [Bug 103757] eglGetDisplay() is broken for Wayland

[bugzilla-daemon]

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

--- Comment #2 from Daniel Stone  ---
(In reply to Pekka Paalanen from comment #1)
> eglGetDisplay() is by definition broken on multi-platform implementations,
> yes.

Ugh. It is broken by definition, but Mesa does go to great lengths to try to
make it work by auto-detecting: see _eglNativePlatformDetectNativeDisplay()
inside src/egl/main/egldisplay.c.

Michael, I'll attach a compiled but untested patch; can you please let me know
if it helps?

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