Re: [Mesa-dev] [PATCH] RFC: Workaround for gen9 hw astc5x5 sampler bug

[Rogovin, Kevin]

Hi,

 The patch series I have submitted handles the case of needing to resolve 
texture surfaces when a draw (or compute) accesses a texture which is astc5x5. 
As it is quite clear you understand the issue and know the code of i965 the 
patch centers on, you are an excellent person to review the code.

Here are my comments of the patch posted:

 1.  it is essentially replication and moving around of the code of the patch 
series posted earlier but missing various
  important bits: preventing the sampler from using the auxiliary buffer 
(this requires to modify surface state
  sent in brw_wm_surfaces.c). It also does not cover blorp sufficiently 
(blorp might read from an ASTC5x5
  and there are more paths in blorp than blorp_surf_for_miptree() that 
sample from surfaces.

 2.  using the check that the GPU is gen9 (and for that matter, using the name 
gen9_ astc5x5_sampler_wa())
  is not ideal; I would not be surprised that the bug might not be present 
on various re-spins of Gen9 and/or
  it might linger on to future Gens. I do NOT know; using a Boolean 
assigned earlier makes the code more
  future-ish proof.

 3.  the nature of GPU fragment dispatch is going to require a texture 
invalidate even if the sampler only
  have the bug in one direction; this is because a subslice is not 
guaranteed to process fragments in any
  order. The crux is that a single sampler serves an entire sub-slice which 
has more than 1 EU. It is quite
  possible that one EU has threads of a draw call ahead of the other and 
depending on the timing, portions
  of those fragments' coming after might be processed by the sampler of 
those before of those fragments
  coming before in batchbuffer order. Indeed a single EU might have threads 
from separate draws as well.
  A texture invalidate places a barrier in the pipeline preventing the 
mixing (and means that efficiency of 
 GPU drops quite a bit with every texture invalidate sadly). 

 4. With 3 in mind, using the bit-masks is not a good idea as we want to then 
enforce at the code level
  that only one of the two is possible without texture invalidates.

-Kevin


-Original Message-
From: Topi Pohjolainen [mailto:topi.pohjolai...@gmail.com] 
Sent: Monday, December 4, 2017 12:49 PM
To: mesa-dev@lists.freedesktop.org
Cc: Rogovin, Kevin 
Subject: [PATCH] RFC: Workaround for gen9 hw astc5x5 sampler bug

This is just drafting some thoughts and only compile tested.

CC: "Rogovin, Kevin" 
---
 src/mesa/drivers/dri/i965/brw_blorp.c   |  8 +
 src/mesa/drivers/dri/i965/brw_context.h | 10 ++
 src/mesa/drivers/dri/i965/brw_draw.c| 54 -
 3 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 680121b6ab..b3f84ab8ca 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -186,11 +186,19 @@ blorp_surf_for_miptree(struct brw_context *brw,
  surf->aux_addr.buffer = mt->hiz_buf->bo;
  surf->aux_addr.offset = mt->hiz_buf->offset;
   }
+
+  if (!is_render_target && brw->screen->devinfo.gen == 9)
+ gen9_astc5x5_sampler_wa(brw, GEN9_ASTC5X5_WA_TEX_TYPE_AUX);
} else {
   surf->aux_addr = (struct blorp_address) {
  .buffer = NULL,
   };
   memset(>clear_color, 0, sizeof(surf->clear_color));
+
+  if (!is_render_target && brw->screen->devinfo.gen == 9 &&
+  (mt->format == MESA_FORMAT_RGBA_ASTC_5x5 ||
+   mt->format == MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5))
+ gen9_astc5x5_sampler_wa(brw, 
+ GEN9_ASTC5X5_WA_TEX_TYPE_ASTC5x5);
}
assert((surf->aux_usage == ISL_AUX_USAGE_NONE) ==
   (surf->aux_addr.buffer == NULL)); diff --git 
a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 0670483806..44602c23c0 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -165,6 +165,11 @@ enum brw_cache_id {
BRW_MAX_CACHE
 };
 
+enum gen9_astc5x5_wa_tex_type {
+   GEN9_ASTC5X5_WA_TEX_TYPE_ASTC5x5 = 1 << 0,
+   GEN9_ASTC5X5_WA_TEX_TYPE_AUX = 1 << 1,
+};
+
 enum brw_state_id {
/* brw_cache_ids must come first - see brw_program_cache.c */
BRW_STATE_URB_FENCE = BRW_MAX_CACHE, @@ -1262,6 +1267,8 @@ struct 
brw_context
 */
bool draw_aux_buffer_disabled[MAX_DRAW_BUFFERS];
 
+   enum gen9_astc5x5_wa_tex_type gen9_sampler_wa_tex_mask;
+
__DRIcontext *driContext;
struct intel_screen *screen;
 };
@@ -1286,6 +1293,9 @@ void intel_update_renderbuffers(__DRIcontext *context,
 __DRIdrawable *drawable);  void 
intel_prepare_render(struct brw_context *brw);
 
+void gen9_astc5x5_sampler_wa(struct brw_context *brw,
+ enum gen9_astc5x5_wa_tex_type curr_mask);
+
 void 

Re: [Mesa-dev] [PATCH v4 22/25] mesa/glspirv: Create gl_linked_shader objects for a SPIR-V program

[Timothy Arceri]

On 04/12/17 20:21, Eduardo Lima Mitev wrote:

v2: Bail out if we see more that one shader for the same stage, and add
a corresponding comment. (Timothy Arceri)

v3: Adds also a linker error log to the condition above. (Timothy Arceri)
---
  src/mesa/main/glspirv.c | 64 ++---
  1 file changed, 61 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
index f90b4f054a6..ad5b467169e 100644
--- a/src/mesa/main/glspirv.c
+++ b/src/mesa/main/glspirv.c
@@ -29,6 +29,8 @@
  #include "compiler/nir/nir.h"
  #include "compiler/spirv/nir_spirv.h"
  
+#include "program/program.h"

+
  #include "util/u_atomic.h"
  
  void

@@ -104,14 +106,70 @@ _mesa_spirv_shader_binary(struct gl_context *ctx,
 }
  }
  
+/**

+ * This is the equivalent to compiler/glsl/linker.cpp::link_shaders()
+ * but for SPIR-V programs.
+ *
+ * This method just creates the gl_linked_shader structs with a reference to
+ * the SPIR-V data collected during previous steps.
+ *
+ * The real linking happens later in the driver-specifc call LinkShader().
+ * This is so backends can implement different linking strategies for
+ * SPIR-V programs.
+ */
  void
  _mesa_spirv_link_shaders(struct gl_context *ctx, struct gl_shader_program 
*prog)
  {
-   /* @TODO: This is a placeholder for the equivalent of
-* compiler/glsl/linker.cpp::link_shaders() but for SPIR-V.
-*/
 prog->data->LinkStatus = linking_success;
 prog->data->Validated = false;
+
+   for (unsigned i = 0; i < prog->NumShaders; i++) {
+  struct gl_shader *shader = prog->Shaders[i];
+  gl_shader_stage shader_type = shader->Stage;
+
+  /* We only support one shader per stage. The gl_spirv spec doesn't seem
+   * to prevent this, but the way the API is designed, requiring all 
shaders
+   * to be specialized with an entry point, makes supporting this quite
+   * undefined.
+   */
+  if (prog->_LinkedShaders[shader_type]) {


Have you guys reported this as a spec bug? Can you add something like:

/* TODO: Turn this into a proper error once the spec bug 
---link/refeence to bug here--- is resolved

 */

With that this is:

Reviewed-by: Timothy Arceri 

Thanks!


+ ralloc_strcat(>data->InfoLog,
+   "\nError trying to link more than one SPIR-V shader "
+   "per stage.\n");
+ prog->data->LinkStatus = linking_failure;
+ return;
+  }
+
+  assert(shader->spirv_data);
+
+  struct gl_linked_shader *linked = rzalloc(NULL, struct gl_linked_shader);
+  linked->Stage = shader_type;
+
+  /* Create program and attach it to the linked shader */
+  struct gl_program *gl_prog =
+ ctx->Driver.NewProgram(ctx,
+_mesa_shader_stage_to_program(shader_type),
+prog->Name, false);
+  if (!gl_prog) {
+ prog->data->LinkStatus = linking_failure;
+ _mesa_delete_linked_shader(ctx, linked);
+ return;
+  }
+
+  _mesa_reference_shader_program_data(ctx,
+  _prog->sh.data,
+  prog->data);
+
+  /* Don't use _mesa_reference_program() just take ownership */
+  linked->Program = gl_prog;
+
+  /* Reference the SPIR-V data from shader to the linked shader */
+  _mesa_shader_spirv_data_reference(>spirv_data,
+shader->spirv_data);
+
+  prog->_LinkedShaders[shader_type] = linked;
+  prog->data->linked_stages |= 1 << shader_type;
+   }
  }
  
  void GLAPIENTRY



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

Re: [Mesa-dev] [PATCH v4 00/44] anv: SPV_KHR_16bit_storage/VK_KHR_16bit_storage for gen8+

[Jason Ekstrand]

A couple of notes:

 1) I *think* I gave you enough reviews to land the UBO/SSBO part and the
optimizations in 26-28.  If reviews are still missing anywhere, please let
me know.  If not, let's try and get that part landed.

 2) I send out a patch to rewrite assign_constant_locations which I think
should make it automatically handle 8 and 16-bit values as well.  I'd
rather do that than more special casing if everything works out ok.

 3) I sent out a series of patches to enable pushing of UBOs in Vulkan.  If
we're not careful, these will clash with 16bit storage as UBO support
suddenly has to imply push constant support.  That said, I"m willing to
wait at least a little while before landing them to let us get 16bit push
constant support sorted out.  The UBO pushing patches give us a nice little
performance boost but we're nowhere near a release and I don't want it
blocking you.

--Jason



On Wed, Nov 29, 2017 at 6:07 PM, Jose Maria Casanova Crespo <
jmcasan...@igalia.com> wrote:

> Hello,
>
> this is the V4 series for the implementation of the SPV_KHR_16bit_storage
> and VK_KHR_16bit_storage extensions on the anv vulkan driver, in addition
> to the GLSL and NIR support needed.
>
> The original series can be found here [1], the following v2 [2]
> and v3 [3].
>
> In short V4 includes the following:
>
>  * Reorder the series to enable features as they are implemented, the
> series
>now enables first UBO and SSBO support, and then inputs/outputs and
>finally push constants.
>  * Support the byte scattered read/write messages with different bit sizes
>byte/word/dword.
>  * Refactor of the store_ssbo code and also fix stores when writemask was
> .yz
>  * Uses the sampler for load_ubo avoiding the initial implementation of
>the series using byte_scattered_read.
>  * Addressed all the feedback provided by Jason and Topi on v3 review.
>
> This series is also available at:
>
> https://github.com/Igalia/mesa/tree/wip/VK_KHR_16bit_storage-rc4
>
> The objective is to start landing part of this series, all feedback has
> been
> addressed for SSBO and UBO. But for input/outputs features it will probably
> need another iteration as was not completely reviewed. It is also needed
> to define the approach for push constants issues before of after landing
> the support with this implementation.
>
> Patches 1-5 and 8-17 have already been reviewed. Patch 7 was already
> reviewed but as it has changed too much i would appreciate another
> review. When patches until 25 or 28 are reviewed we could land UBOs and
> SSBOs support.
>
> Finally an updated overview of the patches:
>
> Patches 1-2 add 16-bit float, int and uint types to GLSL. This is
> needed because NIR uses GLSL types internally. We use the enums
> already defined at AMD_gpu_shader_half_float and NV_gpu_shader
> extensions. Patch 2 updates mesa/st, in order to avoid warnings for
> types not handled on a switch.
>
> Patches 3-6 add NIR support for those new GLSL 16-bit types,
> conversion opcodes, and rounding modes for float to half-float
> conversions.
>
> Patches 7-9 add the SPIR-V (SPV_KHR_16bit_storage) to NIR support.
>
> Patches 10-12 add general 16-bit support for i965. This includes
> handling of new types on several general purpose methods,
> update/remove some asserts.
>
> Patches 14-17 add support for 32 to 16-bit conversions for i965,
> including rounding mode opcodes (needed for float to half-float
> conversions), and an optimization that removes superfluous rounding
> mode sets.
>
> Patches 18-21 add and use two new messages: byte scattered read and
> write. Those were needed because untyped surface message has a fixed
> 32-bit write size. Those messages are used on the 16-bit support of
> store SSBO, load SSBO and load shared.
>
> Patch 22 adds helpers to allow un/shuffle 16-bit components in 32-bit
> ones. This would be needed for following optimizations on load/store
> ssbo. This huck was originally in the input/outputs support, but needed
> a relocation because of the new order of the series.
>
> Patch 23 Enables load_ubo support for 16-bit using the sampler un-shuffling
> pairs 16-bit components from 32-bit.
>
> Patches 24-25 enable SPV_KHR_16bit_storage and VK_KHR_16bit_storage but
> only
> the support for SSBO and UBO on anv vulkan driver.
>
> Patches 26-28 were new patches included in V2 to improve performance
> reducing the use of multiple scattered messages for untyped read/write
> opreations. 16bit CTS tests passes without them. The other one would
> fix a real problem using predication (patch 27), but unfourtunately no CTS
> test yet catching it.
>
> Patches 29-33 implement 16-bit vertex attribute inputs support on
> i965. These include changes on anv. This was needed because 16-bit
> surface formats do implicit conversion to 32-bit. To workaround this,
> we override the 16-bit surface format, and use 32-bit ones. Issues related
> to robust buffer access have been addressed.
>
> Patch 34 implements load input and load store 

Re: [Mesa-dev] [PATCH v3 24/25] i965: Call spirv_to_nir() instead of glsl_to_nir() for SPIR-V shaders

[Timothy Arceri]

Reviewed-by: Timothy Arceri 

On 04/12/17 20:21, Eduardo Lima Mitev wrote:

This is the main fork of the shader compilation code-path, where a NIR
shader is obtained by calling spirv_to_nir() or glsl_to_nir(),
depending on its nature..

v2: Use 'spirv_data' member from gl_linked_shader to know which method
to call. (Timothy Arceri)
---
  src/mesa/drivers/dri/i965/brw_program.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index 755d4973cc0..4043253a653 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -31,6 +31,7 @@
  
  #include 

  #include "main/imports.h"
+#include "main/glspirv.h"
  #include "program/prog_parameter.h"
  #include "program/prog_print.h"
  #include "program/prog_to_nir.h"
@@ -73,9 +74,14 @@ brw_create_nir(struct brw_context *brw,
ctx->Const.ShaderCompilerOptions[stage].NirOptions;
 nir_shader *nir;
  
-   /* First, lower the GLSL IR or Mesa IR to NIR */

+   /* First, lower the GLSL/Mesa IR or SPIR-V to NIR */
 if (shader_prog) {
-  nir = glsl_to_nir(shader_prog, stage, options);
+  if (shader_prog->_LinkedShaders[stage]->spirv_data)
+ nir = _mesa_spirv_to_nir(ctx, shader_prog, stage, options);
+  else
+ nir = glsl_to_nir(shader_prog, stage, options);
+  assert (nir);
+
nir_remove_dead_variables(nir, nir_var_shader_in | nir_var_shader_out);
nir_lower_returns(nir);
nir_validate_shader(nir);


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

Re: [Mesa-dev] [PATCH 6/6] anv: Enable UBO pushing

[Jason Ekstrand]

On Mon, Dec 4, 2017 at 9:07 PM, Jason Ekstrand  wrote:

> On Mon, Dec 4, 2017 at 8:53 PM, Jordan Justen 
> wrote:
>
>> On 2017-12-01 17:20:09, Jason Ekstrand wrote:
>> > ---
>> >  src/intel/vulkan/anv_device.c   | 1 +
>> >  src/intel/vulkan/anv_pipeline.c | 6 ++
>> >  2 files changed, 7 insertions(+)
>> >
>> > diff --git a/src/intel/vulkan/anv_device.c
>> b/src/intel/vulkan/anv_device.c
>> > index 937efb9..43781bd 100644
>> > --- a/src/intel/vulkan/anv_device.c
>> > +++ b/src/intel/vulkan/anv_device.c
>> > @@ -405,6 +405,7 @@ anv_physical_device_init(struct
>> anv_physical_device *device,
>> > device->compiler->shader_debug_log = compiler_debug_log;
>> > device->compiler->shader_perf_log = compiler_perf_log;
>> > device->compiler->supports_pull_constants = false;
>> > +   device->compiler->constant_buffer_0_is_relative = true;
>> >
>> > isl_device_init(>isl_dev, >info, swizzled);
>> >
>> > diff --git a/src/intel/vulkan/anv_pipeline.c
>> b/src/intel/vulkan/anv_pipeline.c
>> > index 907b24a..3bb19ff 100644
>> > --- a/src/intel/vulkan/anv_pipeline.c
>> > +++ b/src/intel/vulkan/anv_pipeline.c
>> > @@ -385,6 +385,9 @@ anv_pipeline_compile(struct anv_pipeline *pipeline,
>> >   struct brw_stage_prog_data *prog_data,
>> >   struct anv_pipeline_bind_map *map)
>> >  {
>> > +   const struct brw_compiler *compiler =
>> > +  pipeline->device->instance->physicalDevice.compiler;
>> > +
>> > nir_shader *nir = anv_shader_compile_to_nir(pipeline, mem_ctx,
>> > module, entrypoint,
>> stage,
>> > spec_info);
>> > @@ -436,6 +439,9 @@ anv_pipeline_compile(struct anv_pipeline *pipeline,
>> > if (pipeline->layout)
>> >anv_nir_apply_pipeline_layout(pipeline, nir, prog_data, map);
>> >
>> > +   if (stage != MESA_SHADER_COMPUTE)
>> > +  brw_nir_analyze_ubo_ranges(compiler, nir,
>> prog_data->ubo_ranges);
>>
>> I guess the results of this analyze pass won't be used on Ivy Bridge?
>>
>
> Yikes!  Those poor Ivy Bridge users were about to stop getting sane
> uniforms.  I'll add a devinfo->gen > 7 || devinfo->is_haswell to that.
>

Actually... The nir_analize_ubo_ranges function already knows to bail for
that so we're good.


> Anyway, series Reviewed-by: Jordan Justen 
>>
>
> Thanks!
>
>
>> > assert(nir->num_uniforms == prog_data->nr_params * 4);
>> >
>> > return nir;
>> > --
>> > 2.5.0.400.gff86faf
>> >
>> > ___
>> > 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 6/6] anv: Enable UBO pushing

[Jason Ekstrand]

On Mon, Dec 4, 2017 at 8:53 PM, Jordan Justen 
wrote:

> On 2017-12-01 17:20:09, Jason Ekstrand wrote:
> > ---
> >  src/intel/vulkan/anv_device.c   | 1 +
> >  src/intel/vulkan/anv_pipeline.c | 6 ++
> >  2 files changed, 7 insertions(+)
> >
> > diff --git a/src/intel/vulkan/anv_device.c
> b/src/intel/vulkan/anv_device.c
> > index 937efb9..43781bd 100644
> > --- a/src/intel/vulkan/anv_device.c
> > +++ b/src/intel/vulkan/anv_device.c
> > @@ -405,6 +405,7 @@ anv_physical_device_init(struct anv_physical_device
> *device,
> > device->compiler->shader_debug_log = compiler_debug_log;
> > device->compiler->shader_perf_log = compiler_perf_log;
> > device->compiler->supports_pull_constants = false;
> > +   device->compiler->constant_buffer_0_is_relative = true;
> >
> > isl_device_init(>isl_dev, >info, swizzled);
> >
> > diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_
> pipeline.c
> > index 907b24a..3bb19ff 100644
> > --- a/src/intel/vulkan/anv_pipeline.c
> > +++ b/src/intel/vulkan/anv_pipeline.c
> > @@ -385,6 +385,9 @@ anv_pipeline_compile(struct anv_pipeline *pipeline,
> >   struct brw_stage_prog_data *prog_data,
> >   struct anv_pipeline_bind_map *map)
> >  {
> > +   const struct brw_compiler *compiler =
> > +  pipeline->device->instance->physicalDevice.compiler;
> > +
> > nir_shader *nir = anv_shader_compile_to_nir(pipeline, mem_ctx,
> > module, entrypoint,
> stage,
> > spec_info);
> > @@ -436,6 +439,9 @@ anv_pipeline_compile(struct anv_pipeline *pipeline,
> > if (pipeline->layout)
> >anv_nir_apply_pipeline_layout(pipeline, nir, prog_data, map);
> >
> > +   if (stage != MESA_SHADER_COMPUTE)
> > +  brw_nir_analyze_ubo_ranges(compiler, nir, prog_data->ubo_ranges);
>
> I guess the results of this analyze pass won't be used on Ivy Bridge?
>

Yikes!  Those poor Ivy Bridge users were about to stop getting sane
uniforms.  I'll add a devinfo->gen > 7 || devinfo->is_haswell to that.


> Anyway, series Reviewed-by: Jordan Justen 
>

Thanks!


> > assert(nir->num_uniforms == prog_data->nr_params * 4);
> >
> > return nir;
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Timothy Arceri]

Ping! The outstanding patches for review are:

4, 12, 22, 23

Gallium specific patches:

17-21

The following have a v1 r-b Nicolai but have changed since:

13, 14, 15

Branch available here:

https://github.com/tarceri/Mesa.git gallium-program-binary

On 29/11/17 12:24, Timothy Arceri wrote:

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

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

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

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

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

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


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

Re: [Mesa-dev] [PATCH 6/6] anv: Enable UBO pushing

[Jordan Justen]

On 2017-12-01 17:20:09, Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/anv_device.c   | 1 +
>  src/intel/vulkan/anv_pipeline.c | 6 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 937efb9..43781bd 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -405,6 +405,7 @@ anv_physical_device_init(struct anv_physical_device 
> *device,
> device->compiler->shader_debug_log = compiler_debug_log;
> device->compiler->shader_perf_log = compiler_perf_log;
> device->compiler->supports_pull_constants = false;
> +   device->compiler->constant_buffer_0_is_relative = true;
>  
> isl_device_init(>isl_dev, >info, swizzled);
>  
> diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
> index 907b24a..3bb19ff 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -385,6 +385,9 @@ anv_pipeline_compile(struct anv_pipeline *pipeline,
>   struct brw_stage_prog_data *prog_data,
>   struct anv_pipeline_bind_map *map)
>  {
> +   const struct brw_compiler *compiler =
> +  pipeline->device->instance->physicalDevice.compiler;
> +
> nir_shader *nir = anv_shader_compile_to_nir(pipeline, mem_ctx,
> module, entrypoint, stage,
> spec_info);
> @@ -436,6 +439,9 @@ anv_pipeline_compile(struct anv_pipeline *pipeline,
> if (pipeline->layout)
>anv_nir_apply_pipeline_layout(pipeline, nir, prog_data, map);
>  
> +   if (stage != MESA_SHADER_COMPUTE)
> +  brw_nir_analyze_ubo_ranges(compiler, nir, prog_data->ubo_ranges);

I guess the results of this analyze pass won't be used on Ivy Bridge?

Anyway, series Reviewed-by: Jordan Justen 

> assert(nir->num_uniforms == prog_data->nr_params * 4);
>  
> return nir;
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 104084] Vulkan doesnt work at all

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEEDINFO|RESOLVED

--- Comment #5 from Timothy Arceri  ---
(In reply to gamedev1909 from comment #4)
> Created attachment 135961 [details]
> attachment-21803-0.html
> 
> Thanks it worked but the entire thing was a bit silly just for vulkan maybe
> Mesa can add a better way 

The amdgpu kernel driver isn't in as good a state for that hardware as the
radeon kernel driver (the driver for older hardware), the fix is to get it up
to scratch then use it by default. Closing this issue.

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

[Mesa-dev] [PATCH v2] st/mesa: swizzle argument when there's a vector size mismatch

[Ilia Mirkin]

GLSL IR operation arguments can sometimes have an implicit swizzle as a
result of a vector arg and a scalar arg, where the scalar argument is
implicitly expanded to the size of the vector argument.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103955
Signed-off-by: Ilia Mirkin 
---

v1 -> v2:
 - fix typo that caused compilation failure
 - remove ir_binop_interpolate_at_* from getting the resizing treatment

I went through all the ir_binops and ir_triops, and those two seem like the
only ones with weird arguments. I think.

 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 8eeae86dabb..740c197c74b 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -1341,10 +1341,33 @@ glsl_to_tgsi_visitor::visit_expression(ir_expression* 
ir, st_src_reg *op)
st_dst_reg result_dst;
 
int vector_elements = ir->operands[0]->type->vector_elements;
-   if (ir->operands[1]) {
+   if (ir->operands[1] &&
+   ir->operation != ir_binop_interpolate_at_offset &&
+   ir->operation != ir_binop_interpolate_at_sample) {
+  st_src_reg *swz_op = NULL;
+  if (vector_elements > ir->operands[1]->type->vector_elements) {
+ assert(ir->operands[1]->type->vector_elements == 1);
+ swz_op = [1];
+  } else if (vector_elements < ir->operands[1]->type->vector_elements) {
+ assert(ir->operands[0]->type->vector_elements == 1);
+ swz_op = [0];
+  }
+  if (swz_op) {
+ uint16_t swizzle_x = GET_SWZ(swz_op->swizzle, 0);
+ swz_op->swizzle = MAKE_SWIZZLE4(swizzle_x, swizzle_x,
+ swizzle_x, swizzle_x);
+  }
   vector_elements = MAX2(vector_elements,
  ir->operands[1]->type->vector_elements);
}
+   if (ir->operands[2] &&
+   ir->operands[2]->type->vector_elements != vector_elements) {
+  /* This can happen with ir_triop_lrp, i.e. glsl mix */
+  assert(ir->operands[2]->type->vector_elements == 1);
+  uint16_t swizzle_x = GET_SWZ(op[2].swizzle, 0);
+  op[2].swizzle = MAKE_SWIZZLE4(swizzle_x, swizzle_x,
+swizzle_x, swizzle_x);
+   }
 
this->result.file = PROGRAM_UNDEFINED;
 
-- 
2.13.6

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

[Mesa-dev] [Bug 104084] Vulkan doesnt work at all

[bugzilla-daemon]

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

--- Comment #4 from gamedev1...@gmail.com ---
Thanks it worked but the entire thing was a bit silly just for vulkan maybe
Mesa can add a better way 

Sent from my iPhone

> On Dec 4, 2017, at 7:37 PM, bugzilla-dae...@freedesktop.org wrote:
> 
> Comment # 3 on bug 104084 from Dylan Baker
> The archwiki has good documentation on this here:
> https://wiki.archlinux.org/index.php/AMDGPU#Enable_Southern_Islands_.28SI.29_and_Sea_Islands_.28CIK.29_support
> 
> Basically the problem is that by default the radeon driver is used by the
> r290/r290X, but the amdgpu driver is needed by radv.
> You are receiving this mail because:
> You reported the bug.

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

Re: [Mesa-dev] screen blurred and glxgears segment fault on ubuntu17.10 for arm architecture server with amdgpu(AMD RADEON PRO WX7100)

[Lvzhihong (ReJohn)]

Thanks for your reply.

The attachment is the Xorg log. 
If you need other information, pls let me know.

Thanks.


-邮件原件-
发件人: Michel Dänzer [mailto:mic...@daenzer.net] 
发送时间: 2017年12月5日 1:02
收件人: Lvzhihong (ReJohn) 
抄送: mesa-dev@lists.freedesktop.org; Liuchen (Greentea) 
; sunnanyong 
主题: Re: [Mesa-dev] screen blurred and glxgears segment fault on ubuntu17.10 for 
arm architecture server with amdgpu(AMD RADEON PRO WX7100)

On 2017-12-04 03:49 AM, Lvzhihong (ReJohn) wrote:
> Hi,all,
> 
>  We met a problem on ubuntu17.10 for arm server with 
> amdgpu(AMD RADEON PRO WX7100),  we use open source driver which are 
> integrated in ubuntu17.10. And the architecture is AArch64-linux-gnu.
> 
>  
> 
>  we install :
> 
>      apt-get install xserver-xorg xinit xfce4 and mesa-utils 
> glmark2
> 
>  we start x server :
> 
>   startx
> 
>  and then the monitor shows the screen and the screen is blurred.

Can you share the corresponding Xorg log file?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer


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

[Mesa-dev] [Bug 103955] Using array in structure results in wrong GLSL compilation output

[bugzilla-daemon]

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

--- Comment #9 from Younghun Jang  ---
(In reply to Ilia Mirkin from comment #8)
> This patch fixes the sample case for me:
> 
> https://patchwork.freedesktop.org/patch/191532/

I concur. The patch fixes the bug.

And I believe this was a typo:

   uint16_t swizzle_x = GET_SWZ(op[2]->swizzle, 0);
   uint16_t swizzle_x = GET_SWZ(op[2].swizzle, 0);

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

Re: [Mesa-dev] [PATCH] Android: enable noreturn and returns_nonnull attributes

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Mon, Dec 4, 2017 at 6:21 PM, Rob Herring  wrote:

> Commit 94ca8e04adf6 ("spirv: Add vtn_fail and vtn_assert helpers") broke
> Android builds which have -Werror enabled with the following errors:
>
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:272:1: error: control
> may reach end of non-void function [-Werror,-Wreturn-type]
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:810:1: error: control
> may reach end of non-void function [-Werror,-Wreturn-type]
> ...
>
> The problem is the noreturn attribute is not enabled and we to define
> HAVE_FUNC_ATTRIBUTE_NORETURN.
>
> Auditing src/util/macros.h, we're also missing
> HAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL, so add it too.
>
> Fixes: 94ca8e04adf6 ("spirv: Add vtn_fail and vtn_assert helpers")
> Cc: Jason Ekstrand 
> Signed-off-by: Rob Herring 
> ---
>  Android.common.mk | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Android.common.mk b/Android.common.mk
> index f080d996a7d9..f905c5e697d0 100644
> --- a/Android.common.mk
> +++ b/Android.common.mk
> @@ -57,6 +57,8 @@ LOCAL_CFLAGS += \
> -DHAVE_FUNC_ATTRIBUTE_FORMAT \
> -DHAVE_FUNC_ATTRIBUTE_PACKED \
> -DHAVE_FUNC_ATTRIBUTE_ALIAS \
> +   -DHAVE_FUNC_ATTRIBUTE_NORETURN \
> +   -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL \
> -DHAVE___BUILTIN_CTZ \
> -DHAVE___BUILTIN_POPCOUNT \
> -DHAVE___BUILTIN_POPCOUNTLL \
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] Android: enable noreturn and returns_nonnull attributes

[Rob Herring]

Commit 94ca8e04adf6 ("spirv: Add vtn_fail and vtn_assert helpers") broke
Android builds which have -Werror enabled with the following errors:

external/mesa3d/src/compiler/spirv/spirv_to_nir.c:272:1: error: control may 
reach end of non-void function [-Werror,-Wreturn-type]
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:810:1: error: control may 
reach end of non-void function [-Werror,-Wreturn-type]
...

The problem is the noreturn attribute is not enabled and we to define
HAVE_FUNC_ATTRIBUTE_NORETURN.

Auditing src/util/macros.h, we're also missing
HAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL, so add it too.

Fixes: 94ca8e04adf6 ("spirv: Add vtn_fail and vtn_assert helpers")
Cc: Jason Ekstrand 
Signed-off-by: Rob Herring 
---
 Android.common.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Android.common.mk b/Android.common.mk
index f080d996a7d9..f905c5e697d0 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -57,6 +57,8 @@ LOCAL_CFLAGS += \
-DHAVE_FUNC_ATTRIBUTE_FORMAT \
-DHAVE_FUNC_ATTRIBUTE_PACKED \
-DHAVE_FUNC_ATTRIBUTE_ALIAS \
+   -DHAVE_FUNC_ATTRIBUTE_NORETURN \
+   -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL \
-DHAVE___BUILTIN_CTZ \
-DHAVE___BUILTIN_POPCOUNT \
-DHAVE___BUILTIN_POPCOUNTLL \
-- 
2.14.1

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

Re: [Mesa-dev] Please implement the vaapi-egl for vaapi hardware decoding, vdpau can't handle HEVC 10bit video.

[Mark Thompson]

On 04/12/17 16:33, Leo Liu wrote:
> On 12/04/2017 04:32 AM, Emil Velikov wrote:
>> On 2 December 2017 at 15:26, Julian Lai  wrote:
>>> Since the crappy vaapi-glx was dropped off by mpv-git player, there is no
>>> way to play HEVC 10bit video with zero-copy hardware acceleration, vdpau
>>> can't do it either, please implement it to make it work.
>>>
>> Both Mesa and libva changes are required. Mark sent patches few months
>> ago, yet libva does not include them in 2.0 :-(
>> The Mesa parts couldn't land until the libva ones are in.
> Mark had a patch "[PATCH] st/va: Enable vaExportSurfaceHandle() "in the list 
> to enable it with VA version 1.1.0
> 
> I think he probably can point out where to get that VA.
It's in libva master now, will be in 2.1.  The API version isn't bumped yet, 
though, so you still need to edit that to 1.1.0 for other projects (that is, 
mpv and mesa) to detect it.

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

Re: [Mesa-dev] [PATCH v4 20/44] i965/fs: Add byte scattered read message and fs support

[Jason Ekstrand]

On Mon, Dec 4, 2017 at 4:50 PM, Chema Casanova 
wrote:

> On 30/11/17 21:45, Jason Ekstrand wrote:
> > On Wed, Nov 29, 2017 at 6:50 PM, Jose Maria Casanova Crespo
> > > wrote:
> >
> > v2: Fix alignment style (Topi Pohjolainen)
> > (Jason Ekstrand)
> > - Enable bit_size parameter to scattered messages to enable
> > different
> >   bitsizes byte/word/dword.
> > - Remove use of brw_send_indirect_scattered_message in favor of
> >   brw_send_indirect_surface_message.
> > - Move scattered messages to surface messages namespace.
> > - Assert align1 for scattered messages and assume Gen8+.
> > - Inline brw_set_dp_byte_scattered_read.
> > ---
> >  src/intel/compiler/brw_eu.h|  8 +++
> >  src/intel/compiler/brw_eu_defines.h|  2 ++
> >  src/intel/compiler/brw_eu_emit.c   | 30
> > ++
> >  src/intel/compiler/brw_fs.cpp  | 19
> 
> >  src/intel/compiler/brw_fs_copy_propagation.cpp |  2 ++
> >  src/intel/compiler/brw_fs_generator.cpp|  6 ++
> >  src/intel/compiler/brw_fs_surface_builder.cpp  | 11 +-
> >  src/intel/compiler/brw_fs_surface_builder.h|  7 ++
> >  src/intel/compiler/brw_shader.cpp  |  6 ++
> >  9 files changed, 90 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/compiler/brw_eu.h
> b/src/intel/compiler/brw_eu.h
> > index 3ac3b4342a..2d0f56f793 100644
> > --- a/src/intel/compiler/brw_eu.h
> > +++ b/src/intel/compiler/brw_eu.h
> > @@ -485,6 +485,14 @@ brw_typed_surface_write(struct brw_codegen *p,
> >  unsigned msg_length,
> >  unsigned num_channels);
> >
> > +void
> > +brw_byte_scattered_read(struct brw_codegen *p,
> > +struct brw_reg dst,
> > +struct brw_reg payload,
> > +struct brw_reg surface,
> > +unsigned msg_length,
> > +unsigned bit_size);
> > +
> >  void
> >  brw_byte_scattered_write(struct brw_codegen *p,
> >   struct brw_reg payload,
> > diff --git a/src/intel/compiler/brw_eu_defines.h
> > b/src/intel/compiler/brw_eu_defines.h
> > index de6330ee54..aa510ebfa4 100644
> > --- a/src/intel/compiler/brw_eu_defines.h
> > +++ b/src/intel/compiler/brw_eu_defines.h
> > @@ -409,6 +409,8 @@ enum opcode {
> >  * opcode, but instead of taking a single payload blog they
> > expect their
> >  * arguments separately as individual sources, like untyped
> > write/read.
> >  */
> > +   SHADER_OPCODE_BYTE_SCATTERED_READ,
> > +   SHADER_OPCODE_BYTE_SCATTERED_READ_LOGICAL,
> > SHADER_OPCODE_BYTE_SCATTERED_WRITE,
> > SHADER_OPCODE_BYTE_SCATTERED_WRITE_LOGICAL,
> >
> > diff --git a/src/intel/compiler/brw_eu_emit.c
> > b/src/intel/compiler/brw_eu_emit.c
> > index ded7e228cf..bdc516848a 100644
> > --- a/src/intel/compiler/brw_eu_emit.c
> > +++ b/src/intel/compiler/brw_eu_emit.c
> > @@ -2998,6 +2998,36 @@ static enum brw_data_size
> > brw_data_size_from_bit_size(unsigned bit_size)
> > }
> >  }
> >
> > +
> > +void
> > +brw_byte_scattered_read(struct brw_codegen *p,
> > +struct brw_reg dst,
> > +struct brw_reg payload,
> > +struct brw_reg surface,
> > +unsigned msg_length,
> > +unsigned bit_size)
> > +{
> > +   assert(brw_inst_access_mode(p->devinfo, p->current) ==
> BRW_ALIGN_1);
> > +   const struct gen_device_info *devinfo = p->devinfo;
> > +   const unsigned sfid =  GEN7_SFID_DATAPORT_DATA_CACHE;
> > +
> > +   struct brw_inst *insn = brw_send_indirect_surface_message(
> > +  p, sfid, dst, payload, surface, msg_length,
> > +  brw_surface_payload_size(p, 1, true, true),
> > +  false);
> > +
> > +   unsigned msg_control = brw_data_size_from_bit_size(bit_size) <<
> 2;
> > +
> > +   if (brw_inst_exec_size(devinfo, p->current) == BRW_EXECUTE_16)
> > +  msg_control |= 1; /* SIMD16 mode */
> > +   else
> > +  msg_control |= 0; /* SIMD8 mode */
> > +
> > +   brw_inst_set_dp_msg_type(devinfo, insn,
> > +HSW_DATAPORT_DC_PORT0_BYTE_
> SCATTERED_READ);
> > +   brw_inst_set_dp_msg_control(devinfo, insn, msg_control);
> > +}
> > +
> >  void
> >  brw_byte_scattered_write(struct brw_codegen *p,
> >   struct brw_reg payload,
> > diff --git a/src/intel/compiler/brw_fs.cpp
> > 

Re: [Mesa-dev] [PATCH 0/6] anv: Add support for pushing ranges of UBOs

[Jason Ekstrand]

On Fri, Dec 1, 2017 at 5:20 PM, Jason Ekstrand  wrote:

> We've had this optimization in the GL driver since July but never got
> around to hooking it up in Vulkan.  This lets us turn UBOs into push
> constants which are significantly faster since they read the UBO data
> once and the shader dispatch shoves it into the shader prior to program
> execution.
>
> I have zero benchmark numbers at the moment but I expect this to help
> anything which uses UBOs and has constant offsets into them which is
> basically everything.  Unfortunately, I'm at home and not near any
> hardware with stable enough performance characteristics to get decent
> numbers today.
>

I have numbers now (which I have added to the commit message on the last
patch:

On my SKL GT4e, this improves the performance of Dota 2 and Talos by
around 2.5% and improves Aztec Ruins by around 2%.


> Cc: Kenneth Graunke 
> Cc: Eero Tamminen 
>
> Jason Ekstrand (6):
>   anv/pipeline: Translate vulkan_resource_index to a constant when
> possible
>   anv/cmd_buffer: Add some helpers for working with descriptor sets
>   anv/cmd_buffer: Add some stage asserts
>   anv/cmd_buffer: Add support for pushing UBO ranges
>   anv/device: Increase the UBO alignment requirement to 32
>   anv: Enable UBO pushing
>
>  src/intel/vulkan/anv_device.c|  13 +-
>  src/intel/vulkan/anv_nir_apply_pipeline_layout.c |  15 +-
>  src/intel/vulkan/anv_pipeline.c  |   6 +
>  src/intel/vulkan/genX_cmd_buffer.c   | 191
> ++-
>  src/intel/vulkan/genX_pipeline.c |   3 +-
>  5 files changed, 179 insertions(+), 49 deletions(-)
>
> --
> 2.5.0.400.gff86faf
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 20/44] i965/fs: Add byte scattered read message and fs support

[Chema Casanova]

On 30/11/17 21:45, Jason Ekstrand wrote:
> On Wed, Nov 29, 2017 at 6:50 PM, Jose Maria Casanova Crespo
> > wrote:
> 
> v2: Fix alignment style (Topi Pohjolainen)
>     (Jason Ekstrand)
>     - Enable bit_size parameter to scattered messages to enable
> different
>       bitsizes byte/word/dword.
>     - Remove use of brw_send_indirect_scattered_message in favor of
>       brw_send_indirect_surface_message.
>     - Move scattered messages to surface messages namespace.
>     - Assert align1 for scattered messages and assume Gen8+.
>     - Inline brw_set_dp_byte_scattered_read.
> ---
>  src/intel/compiler/brw_eu.h                    |  8 +++
>  src/intel/compiler/brw_eu_defines.h            |  2 ++
>  src/intel/compiler/brw_eu_emit.c               | 30
> ++
>  src/intel/compiler/brw_fs.cpp                  | 19 
>  src/intel/compiler/brw_fs_copy_propagation.cpp |  2 ++
>  src/intel/compiler/brw_fs_generator.cpp        |  6 ++
>  src/intel/compiler/brw_fs_surface_builder.cpp  | 11 +-
>  src/intel/compiler/brw_fs_surface_builder.h    |  7 ++
>  src/intel/compiler/brw_shader.cpp              |  6 ++
>  9 files changed, 90 insertions(+), 1 deletion(-)
> 
> diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
> index 3ac3b4342a..2d0f56f793 100644
> --- a/src/intel/compiler/brw_eu.h
> +++ b/src/intel/compiler/brw_eu.h
> @@ -485,6 +485,14 @@ brw_typed_surface_write(struct brw_codegen *p,
>                          unsigned msg_length,
>                          unsigned num_channels);
> 
> +void
> +brw_byte_scattered_read(struct brw_codegen *p,
> +                        struct brw_reg dst,
> +                        struct brw_reg payload,
> +                        struct brw_reg surface,
> +                        unsigned msg_length,
> +                        unsigned bit_size);
> +
>  void
>  brw_byte_scattered_write(struct brw_codegen *p,
>                           struct brw_reg payload,
> diff --git a/src/intel/compiler/brw_eu_defines.h
> b/src/intel/compiler/brw_eu_defines.h
> index de6330ee54..aa510ebfa4 100644
> --- a/src/intel/compiler/brw_eu_defines.h
> +++ b/src/intel/compiler/brw_eu_defines.h
> @@ -409,6 +409,8 @@ enum opcode {
>      * opcode, but instead of taking a single payload blog they
> expect their
>      * arguments separately as individual sources, like untyped
> write/read.
>      */
> +   SHADER_OPCODE_BYTE_SCATTERED_READ,
> +   SHADER_OPCODE_BYTE_SCATTERED_READ_LOGICAL,
>     SHADER_OPCODE_BYTE_SCATTERED_WRITE,
>     SHADER_OPCODE_BYTE_SCATTERED_WRITE_LOGICAL,
> 
> diff --git a/src/intel/compiler/brw_eu_emit.c
> b/src/intel/compiler/brw_eu_emit.c
> index ded7e228cf..bdc516848a 100644
> --- a/src/intel/compiler/brw_eu_emit.c
> +++ b/src/intel/compiler/brw_eu_emit.c
> @@ -2998,6 +2998,36 @@ static enum brw_data_size
> brw_data_size_from_bit_size(unsigned bit_size)
>     }
>  }
> 
> +
> +void
> +brw_byte_scattered_read(struct brw_codegen *p,
> +                        struct brw_reg dst,
> +                        struct brw_reg payload,
> +                        struct brw_reg surface,
> +                        unsigned msg_length,
> +                        unsigned bit_size)
> +{
> +   assert(brw_inst_access_mode(p->devinfo, p->current) == BRW_ALIGN_1);
> +   const struct gen_device_info *devinfo = p->devinfo;
> +   const unsigned sfid =  GEN7_SFID_DATAPORT_DATA_CACHE;
> +
> +   struct brw_inst *insn = brw_send_indirect_surface_message(
> +      p, sfid, dst, payload, surface, msg_length,
> +      brw_surface_payload_size(p, 1, true, true),
> +      false);
> +
> +   unsigned msg_control = brw_data_size_from_bit_size(bit_size) << 2;
> +
> +   if (brw_inst_exec_size(devinfo, p->current) == BRW_EXECUTE_16)
> +      msg_control |= 1; /* SIMD16 mode */
> +   else
> +      msg_control |= 0; /* SIMD8 mode */
> +
> +   brw_inst_set_dp_msg_type(devinfo, insn,
> +                            HSW_DATAPORT_DC_PORT0_BYTE_SCATTERED_READ);
> +   brw_inst_set_dp_msg_control(devinfo, insn, msg_control);
> +}
> +
>  void
>  brw_byte_scattered_write(struct brw_codegen *p,
>                           struct brw_reg payload,
> diff --git a/src/intel/compiler/brw_fs.cpp
> b/src/intel/compiler/brw_fs.cpp
> index 32f1d757f0..1ca4d416b2 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -251,6 +251,7 @@ fs_inst::is_send_from_grf() const
>     case SHADER_OPCODE_UNTYPED_SURFACE_READ:
>     case 

Re: [Mesa-dev] [PATCH 01/29] intel/isl: Codify AUX operations in an enum

[Nanley Chery]

On Mon, Nov 27, 2017 at 07:05:51PM -0800, Jason Ekstrand wrote:
> Right now, we have different entrypoints and enums in blorp for these
> different operations.  This provides us a central enum which we can
> begin to transition to.
> ---
>  src/intel/isl/isl.h | 74 
> +++--
>  1 file changed, 49 insertions(+), 25 deletions(-)
> 

This patch is
Reviewed-by: Nanley Chery 

> diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> index e3acb0e..fda2411 100644
> --- a/src/intel/isl/isl.h
> +++ b/src/intel/isl/isl.h
> @@ -661,31 +661,8 @@ enum isl_aux_usage {
>   *
>   * Drawing with or without aux enabled may implicitly cause the surface to
>   * transition between these states.  There are also four types of auxiliary
> - * compression operations which cause an explicit transition:
> - *
> - *1) Fast Clear:  This operation writes the magic "clear" value to the
> - *   auxiliary surface.  This operation will safely transition any slice
> - *   of a surface from any state to the clear state so long as the entire
> - *   slice is fast cleared at once.  A fast clear that only covers part 
> of
> - *   a slice of a surface is called a partial fast clear.
> - *
> - *2) Full Resolve:  This operation combines the auxiliary surface data
> - *   with the primary surface data and writes the result to the primary.
> - *   For HiZ, the docs call this a depth resolve.  For CCS, the hardware
> - *   full resolve operation does both a full resolve and an ambiguate so
> - *   it actually takes you all the way to the pass-through state.
> - *
> - *3) Partial Resolve:  This operation considers blocks which are in the
> - *   "clear" state and writes the clear value directly into the primary 
> or
> - *   auxiliary surface.  Once this operation completes, the surface is
> - *   still compressed but no longer references the clear color.  This
> - *   operation is only available for CCS.
> - *
> - *4) Ambiguate:  This operation throws away the current auxiliary data 
> and
> - *   replaces it with the magic pass-through value.  If an ambiguate
> - *   operation is performed when the primary surface does not contain 
> 100%
> - *   of the data, data will be lost.  This operation is only implemented
> - *   in hardware for depth where it is called a HiZ resolve.
> + * compression operations which cause an explicit transition which are
> + * described by the isl_aux_op enum below.
>   *
>   * Not all operations are valid or useful in all states.  The diagram below
>   * contains a complete description of the states and all valid and useful
> @@ -787,6 +764,53 @@ enum isl_aux_state {
> ISL_AUX_STATE_AUX_INVALID,
>  };
>  
> +/**
> + * Enum which describes explicit aux transition operations.
> + */
> +enum isl_aux_op {
> +   ISL_AUX_OP_NONE,
> +
> +   /** Fast Clear
> +*
> +* This operation writes the magic "clear" value to the auxiliary surface.
> +* This operation will safely transition any slice of a surface from any
> +* state to the clear state so long as the entire slice is fast cleared at
> +* once.  A fast clear that only covers part of a slice of a surface is
> +* called a partial fast clear.
> +*/
> +   ISL_AUX_OP_FAST_CLEAR,
> +
> +   /** Full Resolve
> +*
> +* This operation combines the auxiliary surface data with the primary
> +* surface data and writes the result to the primary.  For HiZ, the docs
> +* call this a depth resolve.  For CCS, the hardware full resolve 
> operation
> +* does both a full resolve and an ambiguate so it actually takes you all
> +* the way to the pass-through state.
> +*/
> +   ISL_AUX_OP_FULL_RESOLVE,
> +
> +   /** Partial Resolve
> +*
> +* This operation considers blocks which are in the "clear" state and
> +* writes the clear value directly into the primary or auxiliary surface.
> +* Once this operation completes, the surface is still compressed but no
> +* longer references the clear color.  This operation is only available
> +* for CCS_E.
> +*/
> +   ISL_AUX_OP_PARTIAL_RESOLVE,
> +
> +   /** Ambiguate
> +*
> +* This operation throws away the current auxiliary data and replaces it
> +* with the magic pass-through value.  If an ambiguate operation is
> +* performed when the primary surface does not contain 100% of the data,
> +* data will be lost.  This operation is only implemented in hardware for
> +* depth where it is called a HiZ resolve.
> +*/
> +   ISL_AUX_OP_AMBIGUATE,
> +};
> +
>  /* TODO(chadv): Explain */
>  enum isl_array_pitch_span {
> ISL_ARRAY_PITCH_SPAN_FULL,
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev 

Re: [Mesa-dev] [PATCH 2/3] st/va: use designated initialisers for VA driver functions

[Mark Thompson]

On 04/12/17 20:52, Leo Liu wrote:
> Signed-off-by: Leo Liu 
> ---
>  src/gallium/state_trackers/va/context.c | 99 
> -
>  1 file changed, 49 insertions(+), 50 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/va/context.c 
> b/src/gallium/state_trackers/va/context.c
> index 0ad4309568..8c624d05c1 100644
> --- a/src/gallium/state_trackers/va/context.c
> +++ b/src/gallium/state_trackers/va/context.c
> @@ -40,57 +40,56 @@
>  
>  static struct VADriverVTable vtable =
>  {
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   ,
> -   NULL, /* DEPRECATED VaGetSurfaceAttributes */
> -   ,
> -   ,
> -   ,
> -   ,
> +   .vaTerminate = ,
> +   .vaQueryConfigProfiles = ,
> +   .vaQueryConfigEntrypoints = ,
> +   .vaGetConfigAttributes = ,
> +   .vaCreateConfig = ,
> +   .vaDestroyConfig = ,
> +   .vaQueryConfigAttributes = ,
> +   .vaCreateSurfaces = ,
> +   .vaDestroySurfaces = ,
> +   .vaCreateContext = ,
> +   .vaDestroyContext = ,
> +   .vaCreateBuffer = ,
> +   .vaBufferSetNumElements = ,
> +   .vaMapBuffer = ,
> +   .vaUnmapBuffer = ,
> +   .vaDestroyBuffer = ,
> +   .vaBeginPicture = ,
> +   .vaRenderPicture = ,
> +   .vaEndPicture = ,
> +   .vaSyncSurface = ,
> +   .vaQuerySurfaceStatus = ,
> +   .vaQuerySurfaceError = ,
> +   .vaPutSurface = ,
> +   .vaQueryImageFormats = ,
> +   .vaCreateImage = ,
> +   .vaDeriveImage = ,
> +   .vaDestroyImage = ,
> +   .vaSetImagePalette = ,
> +   .vaGetImage = ,
> +   .vaPutImage = ,
> +   .vaQuerySubpictureFormats = ,
> +   .vaCreateSubpicture = ,
> +   .vaDestroySubpicture = ,
> +   .vaSetSubpictureImage = ,
> +   .vaSetSubpictureChromakey = ,
> +   .vaSetSubpictureGlobalAlpha = ,
> +   .vaAssociateSubpicture = ,
> +   .vaDeassociateSubpicture = ,
> +   .vaQueryDisplayAttributes = ,
> +   .vaGetDisplayAttributes = ,
> +   .vaSetDisplayAttributes = ,
> +   .vaBufferInfo = ,
> +   .vaLockSurface = ,
> +   .vaUnlockSurface = ,
> +   .vaCreateSurfaces2 = ,
> +   .vaQuerySurfaceAttributes = ,
> +   .vaAcquireBufferHandle = ,
> +   .vaReleaseBufferHandle = ,
>  #if 0
> -   ,
> +   .vaExportSurfaceHandle = ,
>  #endif
>  };

Tbh I think I prefer how it is currently - the names aren't duplicated, and the 
gaps are clearly marked so that it is obvious which functions haven't been 
implemented.

Thanks,

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

Re: [Mesa-dev] [PATCH 3/8] glapi/check_table: Remove 'extern "C"' block

[Dylan Baker]

Quoting Emil Velikov (2017-11-23 11:04:34)
> On 20 November 2017 at 23:12, Dylan Baker  wrote:
> > This doesn't actually accomplish what it's meant to do, as extern C
> > doesn't undefine __cplusplus, so the included headers define a template
> > (because __cplusplus is defined), but then that code is in an 'extern
> > "C"' block, and explosion.
> >
> The commit does sound a bit off, admittedly I don't fully grok what
> you're trying to say.
> 
> The extern "C" { } construct annotates anything within as if it were a
> normal C code. Thus functions will have the C linkage (otherwise
> they'll have the C++ mangling) and structs are using the C rules.
> So if you have a C++ header further down the chain it will be
> considered as C and hell will break loose.
> 
> This patch is correct, just sent a fix for glapitable.h, while glapi.h
> was handled with d38839a498b38b745f5bdf6b96fbafa2792670be.
> 
> As-is "struct _glapi_table" will be interpret as C++ one, which may
> not have the same guarantees about sizeof and pointer arithmetic that
> we're using in the test.
> 
> Hope the above provides some inspiration towards a better commit message.
> 
> Thanks
> Emil

So here's the problem I run into:

In file included from ../include/c99_compat.h:28:0,
 from ../src/util/macros.h:29,
 from ../src/mapi/glapi/glapi.h:47,
 from ../src/mapi/glapi/tests/check_table.cpp:28:
../include/no_extern_c.h:47:1: error: template with C linkage
 template class _IncludeInsideExternCNotPortable;
 ^~~~
[54/93] Compiling C++ object 'src/gtest/gtest@sta/src_gtest-all.cc.o'.

So, my commit message still makes sense to me, since you can't put a template in
an extern "C" block, and that template is guarded by __cplusplus, which is still
defined even in an extern "C" block.

Do you have a commit message in mind that is better?


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

Re: [Mesa-dev] Fwd: errors for mesa master Android build 1698

[Jason Ekstrand]

On Mon, Dec 4, 2017 at 3:12 PM, Rob Herring  wrote:

> Looks like Jason is the actual culprit here. Unfortunately, the build
> can't keep up with every commit. Looks to me like these should be
> fixed.
>

The problem is that you need to define HAVE_FUNC_ATTRIBUTE_NORETURN


> I wonder how long until I give up and just set Android back to
> -Wno-error...
>

Yeah, -Werror may not be such a good idea.  The code I committed isn't
really buggy.  It just doesn't have the #define needed to shut up the
compiler.

--Jason


> Rob
>
>
> -- Forwarded message --
> From:  
> Date: Mon, Dec 4, 2017 at 2:47 PM
> Subject: errors for mesa master Android build 1698
> To: rob.herr...@linaro.org, samuel.pitoi...@gmail.com
>
>
> Build URL: https://ci.linaro.org/job/robher-aosp/1698/
> Full log: https://ci.linaro.org/job/robher-aosp/1698/consoleText
> Parsed warnings/errors:
> https://ci.linaro.org/job/robher-aosp/1698/parsed_console
>
> branch: origin/master
> commit: 5de7c782fbb30dc49d6b48f797db8f551dada50a
>
> ERRORS:
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:272:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:810:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2182:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2208:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2714:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2734:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2755:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/vtn_alu.c:372:1: error: control may
> reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/vtn_glsl450.c:106:1: error: control
> may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/vtn_glsl450.c:469:1: error: control
> may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:272:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:810:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2182:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2208:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2714:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2734:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2755:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/vtn_alu.c:372:1: error: control may
> reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/vtn_glsl450.c:106:1: error: control
> may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/vtn_glsl450.c:469:1: error: control
> may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:272:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:810:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2182:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2208:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2714:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2734:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2755:1: error:
> control may reach end of non-void function [-Werror,-Wreturn-type]
> }
> ^
> external/mesa3d/src/compiler/spirv/vtn_alu.c:372:1: error: 

[Mesa-dev] [PATCH] nvir: Always split 64-bit IMAD/IMUL operations

[Pierre Moreau]

Those operations do not map to actual hardware instructions, therefore
those should always be lowered to 32-bit instructions.

Fixes: 009c54aa7af "nv50/ir: Split 64-bit integer MAD/MUL operations"
Signed-off-by: Pierre Moreau 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 61d4e6a2d0..14bdcea2ca 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -3794,7 +3794,7 @@ Program::optimizeSSA(int level)
RUN_PASS(2, AlgebraicOpt, run);
RUN_PASS(2, ModifierFolding, run); // before load propagation -> less checks
RUN_PASS(1, ConstantFolding, foldAll);
-   RUN_PASS(1, Split64BitOpPreRA, run);
+   RUN_PASS(0, Split64BitOpPreRA, run);
RUN_PASS(1, LoadPropagation, run);
RUN_PASS(1, IndirectPropagation, run);
RUN_PASS(2, MemoryOpt, run);
-- 
2.15.0

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

[Mesa-dev] [Bug 104084] Vulkan doesnt work at all

[bugzilla-daemon]

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

--- Comment #3 from Dylan Baker  ---


The archwiki has good documentation on this here:
https://wiki.archlinux.org/index.php/AMDGPU#Enable_Southern_Islands_.28SI.29_and_Sea_Islands_.28CIK.29_support

Basically the problem is that by default the radeon driver is used by the
r290/r290X, but the amdgpu driver is needed by radv.

-- 
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] Fwd: errors for mesa master Android build 1698

[Rob Herring]

Looks like Jason is the actual culprit here. Unfortunately, the build
can't keep up with every commit. Looks to me like these should be
fixed.

I wonder how long until I give up and just set Android back to -Wno-error...

Rob


-- Forwarded message --
From:  
Date: Mon, Dec 4, 2017 at 2:47 PM
Subject: errors for mesa master Android build 1698
To: rob.herr...@linaro.org, samuel.pitoi...@gmail.com


Build URL: https://ci.linaro.org/job/robher-aosp/1698/
Full log: https://ci.linaro.org/job/robher-aosp/1698/consoleText
Parsed warnings/errors:
https://ci.linaro.org/job/robher-aosp/1698/parsed_console

branch: origin/master
commit: 5de7c782fbb30dc49d6b48f797db8f551dada50a

ERRORS:
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:272:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:810:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2182:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2208:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2714:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2734:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2755:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/vtn_alu.c:372:1: error: control may
reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/vtn_glsl450.c:106:1: error: control
may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/vtn_glsl450.c:469:1: error: control
may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:272:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:810:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2182:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2208:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2714:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2734:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2755:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/vtn_alu.c:372:1: error: control may
reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/vtn_glsl450.c:106:1: error: control
may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/vtn_glsl450.c:469:1: error: control
may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:272:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:810:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2182:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2208:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2714:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2734:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:2755:1: error:
control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/vtn_alu.c:372:1: error: control may
reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/vtn_glsl450.c:106:1: error: control
may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/vtn_glsl450.c:469:1: error: control
may reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/vtn_alu.c:372:1: error: control may
reach end of non-void function [-Werror,-Wreturn-type]
}
^
external/mesa3d/src/compiler/spirv/spirv_to_nir.c:272:1: error:
control may reach end of non-void 

[Mesa-dev] [PATCH] libdrm: Fix QNX build by including 'sys/ioctl.h'

[Miguel A. Vico]

drm.h header includes 'sys/ioccom.h' for ioctl
definitions on non-linux Unix platforms, but QNX
seems to define those in 'sys/ioctl.h' instead.

Signed-off-by: Miguel A Vico Moya 
---
 include/drm/drm.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index f0bd91de..ec0e1fd7 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -44,7 +44,12 @@ typedef unsigned int drm_handle_t;
 
 #else /* One of the BSDs */
 
+#if (defined(__QNX__) || defined(__QNXNTO__))
+#include 
+#else
 #include 
+#endif
+
 #include 
 typedef int8_t   __s8;
 typedef uint8_t  __u8;
-- 
2.15.0

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

Re: [Mesa-dev] [PATCH 00/14] meson: most of gallium

[Dylan Baker]

Quoting Eric Engestrom (2017-12-04 07:38:04)
> On Thursday, 2017-11-30 10:34:06 -0800, Dylan Baker wrote:
> > Quoting Eric Engestrom (2017-11-29 07:44:08)
> > > On Tuesday, 2017-11-28 15:30:21 -0800, Dylan Baker wrote:
> > > > This series is the gallium media state trackers, the "nine" Direct3D 
> > > > state
> > > > tracker, and an architectural change in the way gallium drivers are 
> > > > linked into
> > > > the final targets.
> > > > 
> > > > This architectural change results in a good deal of code savings, as 
> > > > well as
> > > > ensuring that generated targets are generated before the targets that 
> > > > depend on
> > > > them are built. It makes use of meson's `declare_dependency` construct 
> > > > to pass
> > > > bundled arguments, and the result is somewhat similar to the way that 
> > > > autotools
> > > > uses the Automake.inc files.
> > > > 
> > > > The returning state trackers are the same as the v5 of the remaining
> > > > drivers + media series, but now making use of the internal 
> > > > dependencies, and are
> > > > joined by the D3D "nine" state tracker.
> > > > 
> > > > Dylan Baker (14):
> > > >   meson: Combine gallium target subdirs
> > > >   meson: sort gallium drivers after winsys
> > > >   meson: define driver dependencies
> > > >   meson: use the driver dependencies for the gallium dri target
> > > 
> > > Nice cleanups! ^
> > > I much prefer the code after your patches.
> > > 
> > > I had a quick look, and it all looks fine to me; series is:
> > > Acked-by: Eric Engestrom 
> > > 
> > > (except the patches I actually reviewed, obviously :)
> > 
> > Any comments on v2? I'm ready to start landing this stuff and get on to less
> > interesting work like macOS :)
> 
> Just looked through v2; I guess patch 12/15 (omx) will need changing;
> not sure if you want to wait for the tizonia patches to land first, or
> land 12/15 first and amend it when tizonia lands.
> I'll leave that up to you.

Maybe change the choices to ['auto', 'bellagio', 'disabled'], for most people
that wouldn't really change how they work, but it would make adding the tizonia
patches easier?

I'm ready to get this landed, so I think I'm going to land this now and we can
cross the tizonia bridge when get there.

> I'm not completely sure about patches 5/15 and 6/15, but they look
> reasonable:
> Acked-by: Eric Engestrom 
> 
> Everything else in v2 is:
> Reviewed-by: Eric Engestrom 


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

Re: [Mesa-dev] [PATCH] i965/cnl: Avoid fast-clearing sRGB render buffers

[Nanley Chery]

On Fri, Dec 01, 2017 at 04:42:22PM -0800, Jason Ekstrand wrote:
> On Fri, Dec 1, 2017 at 2:44 PM, Nanley Chery  wrote:
> 
> > Gen10 doesn't automatically decode the clear color of sRGB buffers. To
> > get correct rendering, avoid fast-clearing such buffers for now.
> >
> > The driver now passes the following piglit tests:
> > * spec@arb_framebuffer_srgb@msaa-fast-clear
> > * spec@ext_texture_srgb@multisample-fast-clear gl_ext_texture_srgb
> >
> > Suggested-by: Kenneth Graunke 
> > Suggested-by: Jason Ekstrand 
> > Signed-off-by: Nanley Chery 
> > ---
> >
> > This patch is currently going through the jenkins pipeline.
> >
> >  src/mesa/drivers/dri/i965/brw_meta_util.c | 14 --
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c
> > b/src/mesa/drivers/dri/i965/brw_meta_util.c
> > index ba92168934..54dc6a5ff9 100644
> > --- a/src/mesa/drivers/dri/i965/brw_meta_util.c
> > +++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
> > @@ -298,13 +298,23 @@ brw_is_color_fast_clear_compatible(struct
> > brw_context *brw,
> >  * resolved in intel_update_state. In that case it's pointless to do a
> >  * fast clear because it's very likely to be immediately resolved.
> >  */
> > +   const bool srgb_rb = _mesa_get_srgb_format_linear(mt->format) !=
> > mt->format;
> > if (devinfo->gen >= 9 &&
> > mt->surf.samples == 1 &&
> > -   ctx->Color.sRGBEnabled &&
> > -   _mesa_get_srgb_format_linear(mt->format) != mt->format)
> > +   ctx->Color.sRGBEnabled && srgb_rb)
> >return false;
> >
> > +  /* Gen10 doesn't automatically decode the clear color of sRGB buffers.
> > Since
> > +   * we currently don't perform this decode in software, avoid a
> > fast-clear
> > +   * altogether. TODO: Do this in software.
> > +   */
> > const mesa_format format = _mesa_get_render_format(ctx, mt->format);
> > +   if (devinfo->gen >= 10 && srgb_rb) {
> >
> 
> We could be a bit more precise and only disable it for non-0/1.  Either way,
> 
> Reviewed-by: Jason Ekstrand 
> 
> 


Thanks! I'm gonna push this and hopefully we'll get around to using the
packed clear method to solve all the corner cases.

> > +  perf_debug("sRGB fast clear not enabled for (%s)",
> > + _mesa_get_format_name(format));
> >
> 
> Thanks for leaving a perf_debug!
> 
> 

Np, I was inspired by the one nearby :)

-Nanley

> > +  return false;
> > +   }
> > +
> > if (_mesa_is_format_integer_color(format)) {
> >if (devinfo->gen >= 8) {
> >   perf_debug("Integer fast clear not enabled for (%s)",
> > --
> > 2.15.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 104084] Vulkan doesnt work at all

[bugzilla-daemon]

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

--- Comment #2 from gamedev1...@gmail.com ---
I’m very confused since when do we need a special kernel loaded to use vulkan
that seems a bit silly doesn’t it  anyway to get this kernel loaded what
should I do on arch 

Sent from my iPhone

> On Dec 4, 2017, at 5:32 PM, bugzilla-dae...@freedesktop.org wrote:
> 
> Bas Nieuwenhuizen changed bug 104084 
> What  Removed Added
> Component Other   Drivers/Vulkan/radeon
> StatusNEW NEEDINFO
> Comment # 1 on bug 104084 from Bas Nieuwenhuizen
> This sounds like the amdgpu kernel driver is not loaded? could you check if 
> the
> radeon or amdgpu kernel driver is loaded?
> You are receiving this mail because:
> You reported the bug.

-- 
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] meson: Add lmsensors to gallium libgl-xlib target.

[Dylan Baker]

Fixes: 5e71efef44b992b5d70b ("meson: Add lmsensors support")
Signed-off-by: Dylan Baker 
---
 src/gallium/targets/libgl-xlib/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/targets/libgl-xlib/meson.build 
b/src/gallium/targets/libgl-xlib/meson.build
index 825b7b4a0f1..d0241a59ebe 100644
--- a/src/gallium/targets/libgl-xlib/meson.build
+++ b/src/gallium/targets/libgl-xlib/meson.build
@@ -62,7 +62,7 @@ libgl = shared_library(
 libxlib, libws_xlib, libsoftpipe, libtrace, librbug, libglapi_static,
 libgallium, libmesa_util, libmesa_gallium, gallium_xlib_link_with,
   ],
-  dependencies : [dep_clock, dep_unwind, gallium_xlib_depends],
+  dependencies : [dep_clock, dep_unwind, dep_lmsensors, gallium_xlib_depends],
   install : true,
   version : '1.5.0',
 )
-- 
2.15.0

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

[Mesa-dev] [Bug 104084] Vulkan doesnt work at all

[bugzilla-daemon]

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

  Component|Other   |Drivers/Vulkan/radeon
 Status|NEW |NEEDINFO

--- Comment #1 from Bas Nieuwenhuizen  ---
This sounds like the amdgpu kernel driver is not loaded? could you check if the
radeon or amdgpu kernel driver is loaded?

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

[Mesa-dev] [PATCH 2/3] st/va: use designated initialisers for VA driver functions

[Leo Liu]

Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/context.c | 99 -
 1 file changed, 49 insertions(+), 50 deletions(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 0ad4309568..8c624d05c1 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -40,57 +40,56 @@
 
 static struct VADriverVTable vtable =
 {
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   ,
-   NULL, /* DEPRECATED VaGetSurfaceAttributes */
-   ,
-   ,
-   ,
-   ,
+   .vaTerminate = ,
+   .vaQueryConfigProfiles = ,
+   .vaQueryConfigEntrypoints = ,
+   .vaGetConfigAttributes = ,
+   .vaCreateConfig = ,
+   .vaDestroyConfig = ,
+   .vaQueryConfigAttributes = ,
+   .vaCreateSurfaces = ,
+   .vaDestroySurfaces = ,
+   .vaCreateContext = ,
+   .vaDestroyContext = ,
+   .vaCreateBuffer = ,
+   .vaBufferSetNumElements = ,
+   .vaMapBuffer = ,
+   .vaUnmapBuffer = ,
+   .vaDestroyBuffer = ,
+   .vaBeginPicture = ,
+   .vaRenderPicture = ,
+   .vaEndPicture = ,
+   .vaSyncSurface = ,
+   .vaQuerySurfaceStatus = ,
+   .vaQuerySurfaceError = ,
+   .vaPutSurface = ,
+   .vaQueryImageFormats = ,
+   .vaCreateImage = ,
+   .vaDeriveImage = ,
+   .vaDestroyImage = ,
+   .vaSetImagePalette = ,
+   .vaGetImage = ,
+   .vaPutImage = ,
+   .vaQuerySubpictureFormats = ,
+   .vaCreateSubpicture = ,
+   .vaDestroySubpicture = ,
+   .vaSetSubpictureImage = ,
+   .vaSetSubpictureChromakey = ,
+   .vaSetSubpictureGlobalAlpha = ,
+   .vaAssociateSubpicture = ,
+   .vaDeassociateSubpicture = ,
+   .vaQueryDisplayAttributes = ,
+   .vaGetDisplayAttributes = ,
+   .vaSetDisplayAttributes = ,
+   .vaBufferInfo = ,
+   .vaLockSurface = ,
+   .vaUnlockSurface = ,
+   .vaCreateSurfaces2 = ,
+   .vaQuerySurfaceAttributes = ,
+   .vaAcquireBufferHandle = ,
+   .vaReleaseBufferHandle = ,
 #if 0
-   ,
+   .vaExportSurfaceHandle = ,
 #endif
 };
 
-- 
2.14.1

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

[Mesa-dev] [PATCH 3/3] st/va: Enable vaExportSurfaceHandle()

[Leo Liu]

From: Mark Thompson 

It will be present from libva 2.1 (VAAPI 1.1.0 or higher).

v2: rebase to previous patches(Leo)

Signed-off-by: Mark Thompson 
Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/context.c | 2 +-
 src/gallium/state_trackers/va/surface.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 8c624d05c1..ad59294010 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -88,7 +88,7 @@ static struct VADriverVTable vtable =
.vaQuerySurfaceAttributes = ,
.vaAcquireBufferHandle = ,
.vaReleaseBufferHandle = ,
-#if 0
+#if VA_CHECK_VERSION(1, 1, 0)
.vaExportSurfaceHandle = ,
 #endif
 };
diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 636505b720..f9412ce52e 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -923,7 +923,7 @@ vlVaQueryVideoProcPipelineCaps(VADriverContextP ctx, 
VAContextID context,
return VA_STATUS_SUCCESS;
 }
 
-#if 0
+#if VA_CHECK_VERSION(1, 1, 0)
 VAStatus
 vlVaExportSurfaceHandle(VADriverContextP ctx,
 VASurfaceID surface_id,
-- 
2.14.1

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

[Mesa-dev] [PATCH 1/3] st/va: rename vlVaSubpictureImage to vlVaSetSubpictureImage

[Leo Liu]

Following VA spec

Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/context.c| 2 +-
 src/gallium/state_trackers/va/subpicture.c | 2 +-
 src/gallium/state_trackers/va/va_private.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 78e1f19ab7..0ad4309568 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -73,7 +73,7 @@ static struct VADriverVTable vtable =
,
,
,
-   ,
+   ,
,
,
,
diff --git a/src/gallium/state_trackers/va/subpicture.c 
b/src/gallium/state_trackers/va/subpicture.c
index 981a99cec5..f531b61dec 100644
--- a/src/gallium/state_trackers/va/subpicture.c
+++ b/src/gallium/state_trackers/va/subpicture.c
@@ -119,7 +119,7 @@ vlVaDestroySubpicture(VADriverContextP ctx, VASubpictureID 
subpicture)
 }
 
 VAStatus
-vlVaSubpictureImage(VADriverContextP ctx, VASubpictureID subpicture, VAImageID 
image)
+vlVaSetSubpictureImage(VADriverContextP ctx, VASubpictureID subpicture, 
VAImageID image)
 {
vlVaDriver *drv;
vlVaSubpicture *sub;
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 46f6ba66f2..be38c0b88a 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -364,7 +364,7 @@ VAStatus vlVaQuerySubpictureFormats(VADriverContextP ctx, 
VAImageFormat *format_
 unsigned int *flags, unsigned int 
*num_formats);
 VAStatus vlVaCreateSubpicture(VADriverContextP ctx, VAImageID image, 
VASubpictureID *subpicture);
 VAStatus vlVaDestroySubpicture(VADriverContextP ctx, VASubpictureID 
subpicture);
-VAStatus vlVaSubpictureImage(VADriverContextP ctx, VASubpictureID subpicture, 
VAImageID image);
+VAStatus vlVaSetSubpictureImage(VADriverContextP ctx, VASubpictureID 
subpicture, VAImageID image);
 VAStatus vlVaSetSubpictureChromakey(VADriverContextP ctx, VASubpictureID 
subpicture,
 unsigned int chromakey_min, unsigned int 
chromakey_max,
 unsigned int chromakey_mask);
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH 1/9] compiler: Add new system value SYSTEM_VALUE_BASE_VERTEX_ID

[Antia Puentes]

Hi,

On 30/11/17 21:43, Neil Roberts wrote:


Kenneth Graunke  writes:


We have a number of similar names now:

SYSTEM_VALUE_BASE_VERTEX
SYSTEM_VALUE_BASE_VERTEX_ID
SYSTEM_VALUE_VERTEX_ID
SYSTEM_VALUE_VERTEX_ID_ZERO_BASE

BASE_VERTEX and BASE_VERTEX_ID are really similar names, and honestly
either one seems like it could be the name for gl_BaseVertex.  I'm
afraid it would be easy to mix them up by mistake.  IMHO, it would be
nice to pick a different word, just to keep some distinction between
the two fairly related concepts...

Perhaps SYSTEM_VALUE_FIRST_VERTEX...?  That's only half the meaning,
but it at least uses a different word, and makes you think "do I want
BASE_VERTEX or FIRST_VERTEX?"

Yes, naming this thing is really difficult. I’m not sure if you noticed,
but for Vulkan, the BaseVertex builtin should actually have the value of
BASE_VERTEX_ID unlike GL. So if we rename BASE_VERTEX to something
without “base vertex” in it then it will still be confusing for Vulkan.
So effectively the descriptive names are like:

SYSTEM_VALUE_BASE_VERTEX_ON_GL_BUT_NOT_VULKAN
SYSTEM_VALUE_BASE_VERTEX_ON_VULKAN_OR_OFFSET_FOR_VERTEX_ID_ON_GL

I’m not sure whether that’s enough of an argument against FIRST_VERTEX
though, so personally I don’t really mind either way.

Antia, what do you think?

I am fine renaming it to FIRST_VERTEX. I have sent a second version of 
the series with the renaming and addressing other feedback given by Kenneth.

Thanks.

Regards.

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

[Mesa-dev] [PATCH v2 1/7] compiler: Add SYSTEM_VALUE_FIRST_VERTEX and instrinsics

[Antia Puentes]

This VS system value will contain the value passed as 
for indexed draw calls or the value passed as  for non-indexed
draw calls. It will be used to calculate the gl_VertexID as
SYSTEM_VALUE_VERTEX_ID_ZERO_BASE plus SYSTEM_VALUE_FIRST_VERTEX.
Note that the current calculation which uses SYSTEM_VALUE_BASE_VERTEX
is not right, as gl_BaseVertex should be zero for non-indexed calls.

v2: use SYSTEM_VALUE_FIRST_VERTEX as name for the value, instead of
SYSTEM_VALUE_BASE_VERTEX_ID (Kenneth).

Reviewed-by: Neil Roberts 
Reviewed-by: Kenneth Graunke 
---
 src/compiler/nir/nir.c |  4 
 src/compiler/nir/nir_gather_info.c |  1 +
 src/compiler/nir/nir_intrinsics.h  |  1 +
 src/compiler/shader_enums.c|  1 +
 src/compiler/shader_enums.h| 15 +++
 5 files changed, 22 insertions(+)

diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index 7380bf436a8..29730f5fa86 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -1913,6 +1913,8 @@ nir_intrinsic_from_system_value(gl_system_value val)
   return nir_intrinsic_load_base_instance;
case SYSTEM_VALUE_VERTEX_ID_ZERO_BASE:
   return nir_intrinsic_load_vertex_id_zero_base;
+   case SYSTEM_VALUE_FIRST_VERTEX:
+  return nir_intrinsic_load_first_vertex;
case SYSTEM_VALUE_BASE_VERTEX:
   return nir_intrinsic_load_base_vertex;
case SYSTEM_VALUE_INVOCATION_ID:
@@ -1982,6 +1984,8 @@ nir_system_value_from_intrinsic(nir_intrinsic_op intrin)
   return SYSTEM_VALUE_BASE_INSTANCE;
case nir_intrinsic_load_vertex_id_zero_base:
   return SYSTEM_VALUE_VERTEX_ID_ZERO_BASE;
+   case nir_intrinsic_load_first_vertex:
+  return SYSTEM_VALUE_FIRST_VERTEX;
case nir_intrinsic_load_base_vertex:
   return SYSTEM_VALUE_BASE_VERTEX;
case nir_intrinsic_load_invocation_id:
diff --git a/src/compiler/nir/nir_gather_info.c 
b/src/compiler/nir/nir_gather_info.c
index 946939657ec..555ae77b1d3 100644
--- a/src/compiler/nir/nir_gather_info.c
+++ b/src/compiler/nir/nir_gather_info.c
@@ -247,6 +247,7 @@ gather_intrinsic_info(nir_intrinsic_instr *instr, 
nir_shader *shader)
case nir_intrinsic_load_vertex_id:
case nir_intrinsic_load_vertex_id_zero_base:
case nir_intrinsic_load_base_vertex:
+   case nir_intrinsic_load_first_vertex:
case nir_intrinsic_load_base_instance:
case nir_intrinsic_load_instance_id:
case nir_intrinsic_load_sample_id:
diff --git a/src/compiler/nir/nir_intrinsics.h 
b/src/compiler/nir/nir_intrinsics.h
index 20bef339ac4..a7770bf6a85 100644
--- a/src/compiler/nir/nir_intrinsics.h
+++ b/src/compiler/nir/nir_intrinsics.h
@@ -326,6 +326,7 @@ SYSTEM_VALUE(frag_coord, 4, 0, xx, xx, xx)
 SYSTEM_VALUE(front_face, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(vertex_id, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(vertex_id_zero_base, 1, 0, xx, xx, xx)
+SYSTEM_VALUE(first_vertex, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(base_vertex, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(instance_id, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(base_instance, 1, 0, xx, xx, xx)
diff --git a/src/compiler/shader_enums.c b/src/compiler/shader_enums.c
index 2179c475abd..5e123f29f37 100644
--- a/src/compiler/shader_enums.c
+++ b/src/compiler/shader_enums.c
@@ -214,6 +214,7 @@ gl_system_value_name(gl_system_value sysval)
  ENUM(SYSTEM_VALUE_INSTANCE_ID),
  ENUM(SYSTEM_VALUE_INSTANCE_INDEX),
  ENUM(SYSTEM_VALUE_VERTEX_ID_ZERO_BASE),
+ ENUM(SYSTEM_VALUE_FIRST_VERTEX),
  ENUM(SYSTEM_VALUE_BASE_VERTEX),
  ENUM(SYSTEM_VALUE_BASE_INSTANCE),
  ENUM(SYSTEM_VALUE_DRAW_ID),
diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
index ffe551ab20f..76bb2cc4203 100644
--- a/src/compiler/shader_enums.h
+++ b/src/compiler/shader_enums.h
@@ -472,6 +472,21 @@ typedef enum
 */
SYSTEM_VALUE_BASE_VERTEX,
 
+
+   /**
+* Depending on the type of the draw call (indexed or non-indexed),
+* is the value of \c basevertex passed to \c glDrawElementsBaseVertex and
+* similar, or is the value of \c first passed to \c glDrawArrays and
+* similar.
+*
+* \note
+* It can be used to calculate the \c SYSTEM_VALUE_VERTEX_ID as
+* \c SYSTEM_VALUE_VERTEX_ID_ZERO_BASE plus \c SYSTEM_VALUE_FIRST_VERTEX.
+*
+* \sa SYSTEM_VALUE_VERTEX_ID_ZERO_BASE, SYSTEM_VALUE_VERTEX_ID
+*/
+   SYSTEM_VALUE_FIRST_VERTEX,
+
/**
 * Value of \c baseinstance passed to instanced draw entry points
 *
-- 
2.14.1

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

[Mesa-dev] [PATCH v2 4/7] i965: Let nir lower gl_VertexID instead of the linker

[Antia Puentes]

From: Neil Roberts 

---
 src/mesa/drivers/dri/i965/brw_context.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index b62852d90c8..249f62847b9 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -585,7 +585,8 @@ brw_initialize_context_constants(struct brw_context *brw)
   ctx->Const.QuadsFollowProvokingVertexConvention = false;
 
ctx->Const.NativeIntegers = true;
-   ctx->Const.VertexID_is_zero_based = true;
+   /* This is lowered by NIR instead */
+   ctx->Const.VertexID_is_zero_based = false;
 
/* Regarding the CMP instruction, the Ivybridge PRM says:
 *
-- 
2.14.1

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

[Mesa-dev] [PATCH v2 5/7] nir: Offset vertex_id by first_vertex instead of base_vertex

[Antia Puentes]

From: Neil Roberts 

base_vertex will be zero for non-indexed calls, but we need it to
include the ‘first’ parameter. This is true for both GL and Vulkan.

I think this patch will also affect freedreno and radeonsi. I believe
if they are relying on this lowering then they are currently already
broken because they will have the wrong values for gl_BaseVertex.
However this patch will also make them break for gl_VertexID and they
will need to be fixed to use firt_vertex instead.
---
 src/compiler/nir/nir_lower_system_values.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_lower_system_values.c 
b/src/compiler/nir/nir_lower_system_values.c
index 3594f4ae5ce..6f4fb8233ab 100644
--- a/src/compiler/nir/nir_lower_system_values.c
+++ b/src/compiler/nir/nir_lower_system_values.c
@@ -105,7 +105,7 @@ convert_block(nir_block *block, nir_builder *b)
  if (b->shader->options->vertex_id_zero_based) {
 sysval = nir_iadd(b,
   nir_load_vertex_id_zero_base(b),
-  nir_load_base_vertex(b));
+  nir_load_first_vertex(b));
  } else {
 sysval = nir_load_vertex_id(b);
  }
-- 
2.14.1

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

[Mesa-dev] [PATCH v2 7/7] i965: gl_BaseVertex must be zero for non-indexed draw calls

[Antia Puentes]

- From the OpenGL 4.6 (11.1.3.9 Shader Inputs) specification:

"gl_BaseVertex holds the integer value passed to the baseVertex parameter to the
command that resulted in the current shader invocation. In the case where the
command has no baseVertex parameter, the value of gl_BaseVertex is zero."

- Fixes CTS tests:

* KHR-GL45.shader_draw_parameters_tests.ShaderDrawArraysParameters
* KHR-GL45.shader_draw_parameters_tests.ShaderDrawArraysInstancedParameters
* KHR-GL45.shader_draw_parameters_tests.ShaderMultiDrawArraysParameters
* KHR-GL45.shader_draw_parameters_tests.ShaderMultiDrawArraysIndirectParameters
* KHR-GL45.shader_draw_parameters_tests.MultiDrawArraysIndirectCountParameters

Reviewed-by: Neil Roberts 
---
 src/mesa/drivers/dri/i965/brw_draw.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 18d26cfafca..3d831e7d866 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -239,6 +239,13 @@ brw_emit_prim(struct brw_context *brw,
prim->indirect_offset + 12);
  brw_load_register_mem(brw, GEN7_3DPRIM_START_INSTANCE, bo,
prim->indirect_offset + 16);
+
+ if (brw->draw.derived_draw_params_bo != NULL) {
+brw_store_register_mem32(brw, brw->draw.derived_draw_params_bo,
+ GEN7_3DPRIM_BASE_VERTEX,
+ brw->draw.derived_draw_params_offset + 4);
+brw_emit_mi_flush(brw);
+ }
   } else {
  brw_load_register_mem(brw, GEN7_3DPRIM_START_INSTANCE, bo,
prim->indirect_offset + 12);
@@ -803,7 +810,7 @@ brw_draw_single_prim(struct gl_context *ctx,
 * valid vs_prog_data, but we always flag BRW_NEW_VERTICES before
 * the loop.
 */
-   const int new_basevertex = prim->indexed ? prim->basevertex : prim->start;
+   const int new_basevertex = prim->indexed ? prim->basevertex : 0;
 
if (prim_id > 0 &&
(vs_prog_data->uses_drawid ||
-- 
2.14.1

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

[Mesa-dev] [PATCH v2 6/7] spirv: Lower BaseVertex to FIRST_VERTEX instead of BASE_VERTEX

[Antia Puentes]

From: Neil Roberts 

The base vertex in Vulkan is different from GL in that for non-indexed
primitives the value is taken from the firstVertex parameter instead
of being set to zero. This coincides with the new SYSTEM_VALUE_FIRST_VERTEX
instead of BASE_VERTEX.
---
 src/compiler/spirv/vtn_variables.c | 2 +-
 src/intel/vulkan/genX_cmd_buffer.c | 8 
 src/intel/vulkan/genX_pipeline.c   | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index c57f5541319..67833a4c134 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1155,7 +1155,7 @@ vtn_get_builtin_location(struct vtn_builder *b,
   set_mode_system_value(mode);
   break;
case SpvBuiltInBaseVertex:
-  *location = SYSTEM_VALUE_BASE_VERTEX;
+  *location = SYSTEM_VALUE_FIRST_VERTEX;
   set_mode_system_value(mode);
   break;
case SpvBuiltInBaseInstance:
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index ab5590d7cee..ac4882494be 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -2085,7 +2085,7 @@ void genX(CmdDraw)(
 
genX(cmd_buffer_flush_state)(cmd_buffer);
 
-   if (vs_prog_data->uses_basevertex || vs_prog_data->uses_baseinstance)
+   if (vs_prog_data->uses_firstvertex || vs_prog_data->uses_baseinstance)
   emit_base_vertex_instance(cmd_buffer, firstVertex, firstInstance);
if (vs_prog_data->uses_drawid)
   emit_draw_index(cmd_buffer, 0);
@@ -2123,7 +2123,7 @@ void genX(CmdDrawIndexed)(
 
genX(cmd_buffer_flush_state)(cmd_buffer);
 
-   if (vs_prog_data->uses_basevertex || vs_prog_data->uses_baseinstance)
+   if (vs_prog_data->uses_firstvertex || vs_prog_data->uses_baseinstance)
   emit_base_vertex_instance(cmd_buffer, vertexOffset, firstInstance);
if (vs_prog_data->uses_drawid)
   emit_draw_index(cmd_buffer, 0);
@@ -2279,7 +2279,7 @@ void genX(CmdDrawIndirect)(
   struct anv_bo *bo = buffer->bo;
   uint32_t bo_offset = buffer->offset + offset;
 
-  if (vs_prog_data->uses_basevertex || vs_prog_data->uses_baseinstance)
+  if (vs_prog_data->uses_firstvertex || vs_prog_data->uses_baseinstance)
  emit_base_vertex_instance_bo(cmd_buffer, bo, bo_offset + 8);
   if (vs_prog_data->uses_drawid)
  emit_draw_index(cmd_buffer, i);
@@ -2318,7 +2318,7 @@ void genX(CmdDrawIndexedIndirect)(
   uint32_t bo_offset = buffer->offset + offset;
 
   /* TODO: We need to stomp base vertex to 0 somehow */
-  if (vs_prog_data->uses_basevertex || vs_prog_data->uses_baseinstance)
+  if (vs_prog_data->uses_firstvertex || vs_prog_data->uses_baseinstance)
  emit_base_vertex_instance_bo(cmd_buffer, bo, bo_offset + 12);
   if (vs_prog_data->uses_drawid)
  emit_draw_index(cmd_buffer, i);
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 7e3a785c584..4f88fbaf656 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -97,7 +97,7 @@ emit_vertex_input(struct anv_pipeline *pipeline,
const uint32_t elements_double = double_inputs_read >> VERT_ATTRIB_GENERIC0;
const bool needs_svgs_elem = vs_prog_data->uses_vertexid ||
 vs_prog_data->uses_instanceid ||
-vs_prog_data->uses_basevertex ||
+vs_prog_data->uses_firstvertex ||
 vs_prog_data->uses_baseinstance;
 
uint32_t elem_count = __builtin_popcount(elements) -
@@ -177,7 +177,7 @@ emit_vertex_input(struct anv_pipeline *pipeline,
* This means, that if we have BaseInstance, we need BaseVertex as
* well.  Just do all or nothing.
*/
-  uint32_t base_ctrl = (vs_prog_data->uses_basevertex ||
+  uint32_t base_ctrl = (vs_prog_data->uses_firstvertex ||
 vs_prog_data->uses_baseinstance) ?
VFCOMP_STORE_SRC : VFCOMP_STORE_0;
 
-- 
2.14.1

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

[Mesa-dev] [PATCH v2 3/7] intel: emit first_vertex and reorder the VE' components

[Antia Puentes]

The new order is:
* VE 1: 
* VE 2: 

Previously it was:
* VE 1: 
* VE 2: 

The gl_BaseVertex is in a new location now, and firstvertex occupies
the old gl_BaseVertex place. This way we can keep pointing to the
indirect buffer for indirect draw calls.

Reviewed-by: Neil Roberts 
---
 src/intel/compiler/brw_nir.c  | 11 +---
 src/intel/compiler/brw_vec4.cpp   | 13 +
 src/mesa/drivers/dri/i965/brw_context.h   | 36 ++---
 src/mesa/drivers/dri/i965/brw_draw.c  | 26 +++---
 src/mesa/drivers/dri/i965/brw_draw_upload.c   | 13 -
 src/mesa/drivers/dri/i965/genX_state_upload.c | 39 +++
 6 files changed, 88 insertions(+), 50 deletions(-)

diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 8f3f77f89ae..f702f5b8534 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -240,7 +240,7 @@ brw_nir_lower_vs_inputs(nir_shader *nir,
 */
const bool has_sgvs =
   nir->info.system_values_read &
-  (BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX) |
+  (BITFIELD64_BIT(SYSTEM_VALUE_FIRST_VERTEX) |
BITFIELD64_BIT(SYSTEM_VALUE_BASE_INSTANCE) |
BITFIELD64_BIT(SYSTEM_VALUE_VERTEX_ID_ZERO_BASE) |
BITFIELD64_BIT(SYSTEM_VALUE_INSTANCE_ID));
@@ -262,6 +262,7 @@ brw_nir_lower_vs_inputs(nir_shader *nir,
 nir_intrinsic_instr *intrin = nir_instr_as_intrinsic(instr);
 
 switch (intrin->intrinsic) {
+case nir_intrinsic_load_first_vertex:
 case nir_intrinsic_load_base_vertex:
 case nir_intrinsic_load_base_instance:
 case nir_intrinsic_load_vertex_id_zero_base:
@@ -279,7 +280,7 @@ brw_nir_lower_vs_inputs(nir_shader *nir,
 
nir_intrinsic_set_base(load, num_inputs);
switch (intrin->intrinsic) {
-   case nir_intrinsic_load_base_vertex:
+   case nir_intrinsic_load_first_vertex:
   nir_intrinsic_set_component(load, 0);
   break;
case nir_intrinsic_load_base_instance:
@@ -292,11 +293,15 @@ brw_nir_lower_vs_inputs(nir_shader *nir,
   nir_intrinsic_set_component(load, 3);
   break;
case nir_intrinsic_load_draw_id:
+   case nir_intrinsic_load_base_vertex:
   /* gl_DrawID is stored right after gl_VertexID and friends
* if any of them exist.
*/
   nir_intrinsic_set_base(load, num_inputs + has_sgvs);
-  nir_intrinsic_set_component(load, 0);
+  if (intrin->intrinsic ==  nir_intrinsic_load_draw_id)
+ nir_intrinsic_set_component(load, 0);
+  else
+ nir_intrinsic_set_component(load, 1);
   break;
default:
   unreachable("Invalid system value intrinsic");
diff --git a/src/intel/compiler/brw_vec4.cpp b/src/intel/compiler/brw_vec4.cpp
index 14f930e0264..70a197a9fa0 100644
--- a/src/intel/compiler/brw_vec4.cpp
+++ b/src/intel/compiler/brw_vec4.cpp
@@ -2789,13 +2789,19 @@ brw_compile_vs(const struct brw_compiler *compiler, 
void *log_data,
 * incoming vertex attribute.  So, add an extra slot.
 */
if (shader->info.system_values_read &
-   (BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX) |
+   (BITFIELD64_BIT(SYSTEM_VALUE_FIRST_VERTEX) |
 BITFIELD64_BIT(SYSTEM_VALUE_BASE_INSTANCE) |
 BITFIELD64_BIT(SYSTEM_VALUE_VERTEX_ID_ZERO_BASE) |
 BITFIELD64_BIT(SYSTEM_VALUE_INSTANCE_ID))) {
   nr_attribute_slots++;
}
 
+   if (shader->info.system_values_read &
+   (BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX) |
+BITFIELD64_BIT(SYSTEM_VALUE_DRAW_ID))) {
+  nr_attribute_slots++;
+   }
+
if (shader->info.system_values_read &
BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX))
   prog_data->uses_basevertex = true;
@@ -2816,12 +2822,9 @@ brw_compile_vs(const struct brw_compiler *compiler, void 
*log_data,
BITFIELD64_BIT(SYSTEM_VALUE_INSTANCE_ID))
   prog_data->uses_instanceid = true;
 
-   /* gl_DrawID has its very own vec4 */
if (shader->info.system_values_read &
-   BITFIELD64_BIT(SYSTEM_VALUE_DRAW_ID)) {
+   BITFIELD64_BIT(SYSTEM_VALUE_DRAW_ID))
   prog_data->uses_drawid = true;
-  nr_attribute_slots++;
-   }
 
/* The 3DSTATE_VS documentation lists the lower bound on "Vertex URB Entry
 * Read Length" as 1 in vec4 mode, and 0 in SIMD8 mode.  Empirically, in
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 06704838061..c6d176bc243 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -843,28 +843,44 @@ struct brw_context
 
struct 

[Mesa-dev] [PATCH v2 2/7] intel/compiler: Add a uses_firstvertex flag

[Antia Puentes]

From: Neil Roberts 

Reviewed-by: Kenneth Graunke 
---
 src/intel/compiler/brw_compiler.h | 1 +
 src/intel/compiler/brw_vec4.cpp   | 4 
 2 files changed, 5 insertions(+)

diff --git a/src/intel/compiler/brw_compiler.h 
b/src/intel/compiler/brw_compiler.h
index 28aed833245..6661427e982 100644
--- a/src/intel/compiler/brw_compiler.h
+++ b/src/intel/compiler/brw_compiler.h
@@ -967,6 +967,7 @@ struct brw_vs_prog_data {
bool uses_vertexid;
bool uses_instanceid;
bool uses_basevertex;
+   bool uses_firstvertex;
bool uses_baseinstance;
bool uses_drawid;
 };
diff --git a/src/intel/compiler/brw_vec4.cpp b/src/intel/compiler/brw_vec4.cpp
index 73c40ad6009..14f930e0264 100644
--- a/src/intel/compiler/brw_vec4.cpp
+++ b/src/intel/compiler/brw_vec4.cpp
@@ -2800,6 +2800,10 @@ brw_compile_vs(const struct brw_compiler *compiler, void 
*log_data,
BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX))
   prog_data->uses_basevertex = true;
 
+   if (shader->info.system_values_read &
+   BITFIELD64_BIT(SYSTEM_VALUE_FIRST_VERTEX))
+  prog_data->uses_firstvertex = true;
+
if (shader->info.system_values_read &
BITFIELD64_BIT(SYSTEM_VALUE_BASE_INSTANCE))
   prog_data->uses_baseinstance = true;
-- 
2.14.1

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

[Mesa-dev] [PATCH v2 0/7] Fix shader_draw_parameters CTS tests

[Antia Puentes]

This patch series is a v2 of the one we sent some weeks ago to fix
gl_BaseVertex in i965. The original patch series can be found on here:
https://patchwork.freedesktop.org/series/33623/

* Rationale:

gl_BaseVertex must be zero for non-indexed draw comands. However,
for this kind of draw comands, we were setting it to the value passed
as  argument of the command.

The series fixes this bug for i965. Notice that we still need the value of
the  argument of the non-indexed draw call to calculate gl_VertexID,
as for those gl_VertexID must be equal to: gl_VertexIDBaseZero + .

The Vertex Elements' composition will be now as follows:
* VE 1: 
* VE 2: 

- BaseVertex will be the  passed to indexed draw calls,
zero otherwise.
- firstvertex will be the  vertex passed to non-indexed draw calls,
and will be the  for indexed draw commands. Setting firstvertex
to  for indexed draw commands is convinient for two reasons:
 1) In case of indirect draw calls, we can keep pointing to the indirect buffer
 when emitting the vertices.
 2) We can calculate gl_VertexID as VertexID(basezero) + firstindex for both
 types of draw commands and these two values will be in the same Vertex Element.
 We will only emit VE2 if gl_DrawID or gl_BaseVertex are referenced in the
 shader.

* Changes in v2:

- Rename the new system value as SYSTEM_VALUE_FIRST_VERTEX and
  the related variables through the series.
- Squash patches 1-2 of the original series, and 4 and 6.
- Move patch 5 to the end of the patch series.
- Swap the order of patches 7 and 8.

* OpenGL 4.6 specification bits:

- 11.1.3.9 Shader Inputs

"gl_BaseVertex holds the integer value passed to the baseVertex parameter to the
command that resulted in the current shader invocation. In the case where the
command has no baseVertex parameter, the value of gl_BaseVertex is zero."

"gl_VertexID holds the integer index i implicitly passed by DrawArrays or
one of the other drawing commands defined in section 10.4."

- 10.4. Drawing Commands Using Vertex Arrays:

  -> Page 352:
"The index of any element transferred to the GL by DrawArraysOneInstance is
referred to as its vertex ID, and may be read by a vertex shader as gl_VertexID.
The vertex ID of the ith element transferred is first + i."

  -> Page 355:
"The index of any element transferred to the GL by DrawElementsOneInstance is
referred to as its vertex ID, and may be read by a vertex shader as gl_VertexID.
The vertex ID of the ith element transferred is the sum of basevertex and the
value stored in the currently bound element array buffer at offset indices + i."

Antia Puentes (3):
  compiler: Add SYSTEM_VALUE_FIRST_VERTEX and instrinsics
  intel: emit first_vertex and reorder the VE' components
  i965: gl_BaseVertex must be zero for non-indexed draw calls

Neil Roberts (4):
  intel/compiler: Add a uses_firstvertex flag
  i965: Let nir lower gl_VertexID instead of the linker
  nir: Offset vertex_id by first_vertex instead of base_vertex
  spirv: Lower BaseVertex to FIRST_VERTEX instead of BASE_VERTEX

 src/compiler/nir/nir.c|  4 +++
 src/compiler/nir/nir_gather_info.c|  1 +
 src/compiler/nir/nir_intrinsics.h |  1 +
 src/compiler/nir/nir_lower_system_values.c|  2 +-
 src/compiler/shader_enums.c   |  1 +
 src/compiler/shader_enums.h   | 15 +++
 src/compiler/spirv/vtn_variables.c|  2 +-
 src/intel/compiler/brw_compiler.h |  1 +
 src/intel/compiler/brw_nir.c  | 11 +---
 src/intel/compiler/brw_vec4.cpp   | 17 
 src/intel/vulkan/genX_cmd_buffer.c|  8 +++---
 src/intel/vulkan/genX_pipeline.c  |  4 +--
 src/mesa/drivers/dri/i965/brw_context.c   |  3 ++-
 src/mesa/drivers/dri/i965/brw_context.h   | 36 ++---
 src/mesa/drivers/dri/i965/brw_draw.c  | 33 ---
 src/mesa/drivers/dri/i965/brw_draw_upload.c   | 13 -
 src/mesa/drivers/dri/i965/genX_state_upload.c | 39 +++
 17 files changed, 132 insertions(+), 59 deletions(-)

-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] radeon/vcn: determine idr by pic type

[Zhang, Boyuan]

> Am 30.11.2017 um 22:18 schrieb Leo Liu:
>>
>>
>> On 11/30/2017 04:12 PM, boyuan.zh...@amd.com wrote:
>>> From: Boyuan Zhang 
>>>
>>> Vaapi encode interface provides idr frame flags, where omx interface 
>>> doesn't.
>>> Therefore, change to use picture type to determine idr frame, which 
>>> will work for both interfaces.
>>>
>>> Signed-off-by: Boyuan Zhang 
>> Reviewed-by: Leo Liu 
>
> Reviewed-by: Christian König 
>
> As a consequence could you remove the is_idr flag from the picture structure 
> or is that used somewhere else as well?
>
> Regards,
> Christian.

Since Vaapi interface provides the idr flag directly, it's better to have a 1:1 
mapping in driver side and use it directly. And actually, we are using this 
"is_idr" flag in some functions in st/va now. So I think it's better to keep it 
for now.

Regards,
Boyuan

>
>>
>>> ---
>>>   src/gallium/drivers/radeon/radeon_vcn_enc.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c
>>> b/src/gallium/drivers/radeon/radeon_vcn_enc.c
>>> index 9806a69..5fc9fc7 100644
>>> --- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
>>> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
>>> @@ -47,7 +47,7 @@ static void radeon_vcn_enc_get_param(struct 
>>> radeon_encoder *enc, struct pipe_h26
>>>   enc->enc_pic.ref_idx_l0 = pic->ref_idx_l0;
>>>   enc->enc_pic.ref_idx_l1 = pic->ref_idx_l1;
>>>   enc->enc_pic.not_referenced = pic->not_referenced;
>>> -    enc->enc_pic.is_idr = pic->is_idr;
>>> +    enc->enc_pic.is_idr = (pic->picture_type ==
>>> PIPE_H264_ENC_PICTURE_TYPE_IDR);
>>>   enc->enc_pic.crop_left = 0;
>>>   enc->enc_pic.crop_right = (align(enc->base.width, 16) -
>>> enc->base.width) / 2;
>>>   enc->enc_pic.crop_top = 0;
>>

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

Re: [Mesa-dev] [PATCH] st/mesa: swizzle argument when there's a vector size mismatch

[Ilia Mirkin]

Yeah, the typo was a last second edit, as always. Thanks for making a
sample failing case, will investigate. I hate all these interpolateat tests
:( so many edge cases...

On Dec 4, 2017 2:51 PM, "Marek Olšák"  wrote:

> There is a typo, so it doesn't build.
>
> It breaks these CTS tests:
> gl45-cts@shader_multisample_interpolation@render@interpolate_at_offset*
>
> Error:
> state_tracker/st_glsl_to_tgsi.cpp:1347: void
> glsl_to_tgsi_visitor::visit_expression(ir_expression*, st_src_reg*):
> Assertion `ir->operands[1]->type->vector_elements == 1' failed.
>
> The CTS shader is attached. (to be run with shader-db)
>
> Marek
>
>
> On Sat, Dec 2, 2017 at 5:35 PM, Ilia Mirkin  wrote:
> > GLSL IR operation arguments can sometimes have an implicit swizzle as a
> > result of a vector arg and a scalar arg, where the scalar argument is
> > implicitly expanded to the size of the vector argument.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103955
> > Signed-off-by: Ilia Mirkin 
> > ---
> >
> > I'm *pretty* sure I looked at all of ir_validate to make sure that this
> will
> > be fine, but I wouldn't exclude the possibility that I missed some
> extremely
> > odd case. Could use a piglit run.
> >
> >  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 21 +
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> > index 0772b736275..8ca337d16ec 100644
> > --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> > +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> > @@ -1342,9 +1342,30 @@ glsl_to_tgsi_visitor::visit_expression(ir_expression*
> ir, st_src_reg *op)
> >
> > int vector_elements = ir->operands[0]->type->vector_elements;
> > if (ir->operands[1]) {
> > +  st_src_reg *swz_op = NULL;
> > +  if (vector_elements > ir->operands[1]->type->vector_elements) {
> > + assert(ir->operands[1]->type->vector_elements == 1);
> > + swz_op = [1];
> > +  } else if (vector_elements < ir->operands[1]->type->vector_elements)
> {
> > + assert(ir->operands[0]->type->vector_elements == 1);
> > + swz_op = [0];
> > +  }
> > +  if (swz_op) {
> > + uint16_t swizzle_x = GET_SWZ(swz_op->swizzle, 0);
> > + swz_op->swizzle = MAKE_SWIZZLE4(swizzle_x, swizzle_x,
> > + swizzle_x, swizzle_x);
> > +  }
> >vector_elements = MAX2(vector_elements,
> >   ir->operands[1]->type->vector_elements);
> > }
> > +   if (ir->operands[2] &&
> > +   ir->operands[2]->type->vector_elements != vector_elements) {
> > +  /* This can happen with ir_triop_lrp, i.e. glsl mix */
> > +  assert(ir->operands[2]->type->vector_elements == 1);
> > +  uint16_t swizzle_x = GET_SWZ(op[2]->swizzle, 0);
> > +  op[2].swizzle = MAKE_SWIZZLE4(swizzle_x, swizzle_x,
> > +swizzle_x, swizzle_x);
> > +   }
> >
> > this->result.file = PROGRAM_UNDEFINED;
> >
> > --
> > 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

Re: [Mesa-dev] [PATCH] st/mesa: swizzle argument when there's a vector size mismatch

[Marek Olšák]

There is a typo, so it doesn't build.

It breaks these CTS tests:
gl45-cts@shader_multisample_interpolation@render@interpolate_at_offset*

Error:
state_tracker/st_glsl_to_tgsi.cpp:1347: void
glsl_to_tgsi_visitor::visit_expression(ir_expression*, st_src_reg*):
Assertion `ir->operands[1]->type->vector_elements == 1' failed.

The CTS shader is attached. (to be run with shader-db)

Marek


On Sat, Dec 2, 2017 at 5:35 PM, Ilia Mirkin  wrote:
> GLSL IR operation arguments can sometimes have an implicit swizzle as a
> result of a vector arg and a scalar arg, where the scalar argument is
> implicitly expanded to the size of the vector argument.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103955
> Signed-off-by: Ilia Mirkin 
> ---
>
> I'm *pretty* sure I looked at all of ir_validate to make sure that this will
> be fine, but I wouldn't exclude the possibility that I missed some extremely
> odd case. Could use a piglit run.
>
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index 0772b736275..8ca337d16ec 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -1342,9 +1342,30 @@ glsl_to_tgsi_visitor::visit_expression(ir_expression* 
> ir, st_src_reg *op)
>
> int vector_elements = ir->operands[0]->type->vector_elements;
> if (ir->operands[1]) {
> +  st_src_reg *swz_op = NULL;
> +  if (vector_elements > ir->operands[1]->type->vector_elements) {
> + assert(ir->operands[1]->type->vector_elements == 1);
> + swz_op = [1];
> +  } else if (vector_elements < ir->operands[1]->type->vector_elements) {
> + assert(ir->operands[0]->type->vector_elements == 1);
> + swz_op = [0];
> +  }
> +  if (swz_op) {
> + uint16_t swizzle_x = GET_SWZ(swz_op->swizzle, 0);
> + swz_op->swizzle = MAKE_SWIZZLE4(swizzle_x, swizzle_x,
> + swizzle_x, swizzle_x);
> +  }
>vector_elements = MAX2(vector_elements,
>   ir->operands[1]->type->vector_elements);
> }
> +   if (ir->operands[2] &&
> +   ir->operands[2]->type->vector_elements != vector_elements) {
> +  /* This can happen with ir_triop_lrp, i.e. glsl mix */
> +  assert(ir->operands[2]->type->vector_elements == 1);
> +  uint16_t swizzle_x = GET_SWZ(op[2]->swizzle, 0);
> +  op[2].swizzle = MAKE_SWIZZLE4(swizzle_x, swizzle_x,
> +swizzle_x, swizzle_x);
> +   }
>
> this->result.file = PROGRAM_UNDEFINED;
>
> --
> 2.13.6
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


3.shader_test
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 104084] Vulkan doesnt work at all

[bugzilla-daemon]

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

Bug ID: 104084
   Summary: Vulkan doesnt work at all
   Product: Mesa
   Version: 17.2
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: gamedev1...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

So to sum things up vulkan will not funtion at all i added the vulkan debug
below if you find any errors let me know 

i have R9 290x 

im using Arch linux i have both radeon vulkan driver and icd loader installed 


===
VULKAN INFO
===

Vulkan API Version: 1.0.61

DEBUG: Searching the following paths for manifest files:
/etc/xdg/vulkan/explicit_layer.d:/etc/vulkan/explicit_layer.d:/home/wardoc/.local/share/flatpak/exports/share/vulkan/explicit_layer.d:/var/lib/flatpak/exports/share/vulkan/explicit_layer.d:/usr/local/share/vulkan/explicit_layer.d:/usr/share/vulkan/explicit_layer.d

DEBUG: Searching the following path for manifest files:
/home/wardoc/.local/share/vulkan/explicit_layer.d

DEBUG: Searching the following paths for manifest files:
/etc/xdg/vulkan/implicit_layer.d:/etc/vulkan/implicit_layer.d:/home/wardoc/.local/share/flatpak/exports/share/vulkan/implicit_layer.d:/var/lib/flatpak/exports/share/vulkan/implicit_layer.d:/usr/local/share/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d

DEBUG: Searching the following path for manifest files:
/home/wardoc/.local/share/vulkan/implicit_layer.d

INFO: Found manifest file
/usr/share/vulkan/explicit_layer.d/VkLayer_threading.json, version "1.1.0"
INFO: Found manifest file
/usr/share/vulkan/explicit_layer.d/VkLayer_standard_validation.json, version
"1.1.1"
INFO: Encountered meta-layer VK_LAYER_LUNARG_standard_validation
INFO: Found manifest file
/usr/share/vulkan/explicit_layer.d/VkLayer_core_validation.json, version
"1.1.0"
INFO: Found manifest file
/usr/share/vulkan/explicit_layer.d/VkLayer_unique_objects.json, version "1.1.0"
INFO: Found manifest file
/usr/share/vulkan/explicit_layer.d/VkLayer_parameter_validation.json, version
"1.1.0"
INFO: Found manifest file
/usr/share/vulkan/explicit_layer.d/VkLayer_object_tracker.json, version "1.1.0"
DEBUG: Meta-layer VK_LAYER_LUNARG_standard_validation component layer
VK_LAYER_GOOGLE_threading adding instance extension VK_EXT_debug_report
DEBUG: Meta-layer VK_LAYER_LUNARG_standard_validation component layer
VK_LAYER_LUNARG_parameter_validation adding instance extension
VK_EXT_debug_report
DEBUG: Meta-layer VK_LAYER_LUNARG_standard_validation component layer
VK_LAYER_LUNARG_parameter_validation adding device extension
VK_EXT_debug_marker
DEBUG: Meta-layer VK_LAYER_LUNARG_standard_validation component layer
VK_LAYER_LUNARG_object_tracker adding instance extension VK_EXT_debug_report
DEBUG: Meta-layer VK_LAYER_LUNARG_standard_validation component layer
VK_LAYER_LUNARG_object_tracker adding device extension VK_EXT_debug_marker
DEBUG: Meta-layer VK_LAYER_LUNARG_standard_validation component layer
VK_LAYER_LUNARG_core_validation adding instance extension VK_EXT_debug_report
DEBUG: Meta-layer VK_LAYER_LUNARG_standard_validation component layer
VK_LAYER_LUNARG_core_validation adding device extension VK_EXT_debug_marker
INFO: Meta-layer VK_LAYER_LUNARG_standard_validation all 5 component layers
appear to be valid.
DEBUG: Searching the following paths for manifest files:
/etc/xdg/vulkan/explicit_layer.d:/etc/vulkan/explicit_layer.d:/home/wardoc/.local/share/flatpak/exports/share/vulkan/explicit_layer.d:/var/lib/flatpak/exports/share/vulkan/explicit_layer.d:/usr/local/share/vulkan/explicit_layer.d:/usr/share/vulkan/explicit_layer.d

DEBUG: Searching the following path for manifest files:
/home/wardoc/.local/share/vulkan/explicit_layer.d

DEBUG: Searching the following paths for manifest files:
/etc/xdg/vulkan/implicit_layer.d:/etc/vulkan/implicit_layer.d:/home/wardoc/.local/share/flatpak/exports/share/vulkan/implicit_layer.d:/var/lib/flatpak/exports/share/vulkan/implicit_layer.d:/usr/local/share/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d

DEBUG: Searching the following path for manifest files:
/home/wardoc/.local/share/vulkan/implicit_layer.d

INFO: Found manifest file
/usr/share/vulkan/explicit_layer.d/VkLayer_threading.json, version "1.1.0"
INFO: Found manifest file
/usr/share/vulkan/explicit_layer.d/VkLayer_standard_validation.json, version
"1.1.1"
INFO: Encountered meta-layer VK_LAYER_LUNARG_standard_validation
INFO: Found manifest file
/usr/share/vulkan/explicit_layer.d/VkLayer_core_validation.json, version
"1.1.0"
INFO: Found manifest file
/usr/share/vulkan/explicit_layer.d/VkLayer_unique_objects.json, version "1.1.0"
INFO: Found manifest file
/usr/share/vulkan/explicit_layer.d/VkLayer_parameter_validation.json, version
"1.1.0"
INFO: Found manifest file

Re: [Mesa-dev] [PATCH 09/22] mesa: Add GL_RGBA + GL_UNSIGNED_INT_2_10_10_10_REV for OES read type.

[Tapani Pälli]

On 04.12.2017 20:45, Marek Olšák wrote:

Do we need to handle B10G10R10X2 as well?


Good catch, that is missing indeed. Also noticed that dEQP wide color 
test does not test BGRX.



Marek

On Wed, Nov 29, 2017 at 5:20 AM, Mario Kleiner
 wrote:

This format + type combo is good for BGRA1010102 framebuffers
for use with glReadPixels() under GLES, so add it for the
GL_IMPLEMENTATION_COLOR_READ_TYPE_OES query.

Allows successful testing of 10 bpc / depth 30 rendering with dEQP test
case dEQP-EGL.functional.wide_color.window_1010102_colorspace_default.

Signed-off-by: Mario Kleiner 
---
  src/mesa/main/framebuffer.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index b17d7cb..a0de669 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -889,6 +889,9 @@ _mesa_get_color_read_type(struct gl_context *ctx,
if (format == MESA_FORMAT_B5G6R5_UNORM)
   return GL_UNSIGNED_SHORT_5_6_5;

+  if (format == MESA_FORMAT_B10G10R10A2_UNORM)
+ return GL_UNSIGNED_INT_2_10_10_10_REV;
+
switch (data_type) {
case GL_SIGNED_NORMALIZED:
   return GL_BYTE;
--
2.7.4

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

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


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

Re: [Mesa-dev] [PATCH 22/22] st/dri: Add option to control exposure of 10 bpc color configs.

[Marek Olšák]

For patches 4-5, 7, 9-19, 21-22:

Reviewed-by: Marek Olšák 

Marek

On Wed, Nov 29, 2017 at 5:21 AM, Mario Kleiner
 wrote:
> Some clients may not like rgb10 fbconfigs and visuals.
> Support driconf option 'allow_rgb10_configs' on gallium
> to allow per application enable/disable.
>
> The option defaults to enabled.
>
> Signed-off-by: Mario Kleiner 
> ---
>  src/gallium/auxiliary/pipe-loader/driinfo_gallium.h | 1 +
>  src/gallium/state_trackers/dri/dri_screen.c | 8 
>  2 files changed, 9 insertions(+)
>
> diff --git a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h 
> b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
> index d2d2c9d..db0d633 100644
> --- a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
> +++ b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
> @@ -31,4 +31,5 @@ DRI_CONF_SECTION_END
>  DRI_CONF_SECTION_MISCELLANEOUS
> DRI_CONF_ALWAYS_HAVE_DEPTH_BUFFER("false")
> DRI_CONF_GLSL_ZERO_INIT("false")
> +   DRI_CONF_ALLOW_RGB10_CONFIGS("true")
>  DRI_CONF_SECTION_END
> diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
> b/src/gallium/state_trackers/dri/dri_screen.c
> index 04afe71..d307b4f 100644
> --- a/src/gallium/state_trackers/dri/dri_screen.c
> +++ b/src/gallium/state_trackers/dri/dri_screen.c
> @@ -156,6 +156,7 @@ dri_fill_in_modes(struct dri_screen *screen)
> struct pipe_screen *p_screen = screen->base.screen;
> boolean pf_z16, pf_x8z24, pf_z24x8, pf_s8z24, pf_z24s8, pf_z32;
> boolean mixed_color_depth;
> +   boolean allow_rgb10;
>
> static const GLenum back_buffer_modes[] = {
>__DRI_ATTRIB_SWAP_NONE, __DRI_ATTRIB_SWAP_UNDEFINED,
> @@ -172,6 +173,8 @@ dri_fill_in_modes(struct dri_screen *screen)
>depth_buffer_factor = 1;
> }
>
> +   allow_rgb10 = driQueryOptionb(>dev->option_cache, 
> "allow_rgb10_configs");
> +
> msaa_samples_max = (screen->st_api->feature_mask & 
> ST_API_FEATURE_MS_VISUALS_MASK)
>? MSAA_VISUAL_MAX_SAMPLES : 1;
>
> @@ -231,6 +234,11 @@ dri_fill_in_modes(struct dri_screen *screen)
>unsigned num_msaa_modes = 0; /* includes a single-sample mode */
>uint8_t msaa_modes[MSAA_VISUAL_MAX_SAMPLES];
>
> +  if (!allow_rgb10 &&
> +  (mesa_formats[format] == MESA_FORMAT_B10G10R10A2_UNORM ||
> +   mesa_formats[format] == MESA_FORMAT_B10G10R10X2_UNORM))
> + continue;
> +
>if (!p_screen->is_format_supported(p_screen, pipe_formats[format],
>   PIPE_TEXTURE_2D, 0,
>   PIPE_BIND_RENDER_TARGET))
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/22] mesa: Add GL_RGBA + GL_UNSIGNED_INT_2_10_10_10_REV for OES read type.

[Marek Olšák]

Do we need to handle B10G10R10X2 as well?

Marek

On Wed, Nov 29, 2017 at 5:20 AM, Mario Kleiner
 wrote:
> This format + type combo is good for BGRA1010102 framebuffers
> for use with glReadPixels() under GLES, so add it for the
> GL_IMPLEMENTATION_COLOR_READ_TYPE_OES query.
>
> Allows successful testing of 10 bpc / depth 30 rendering with dEQP test
> case dEQP-EGL.functional.wide_color.window_1010102_colorspace_default.
>
> Signed-off-by: Mario Kleiner 
> ---
>  src/mesa/main/framebuffer.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index b17d7cb..a0de669 100644
> --- a/src/mesa/main/framebuffer.c
> +++ b/src/mesa/main/framebuffer.c
> @@ -889,6 +889,9 @@ _mesa_get_color_read_type(struct gl_context *ctx,
>if (format == MESA_FORMAT_B5G6R5_UNORM)
>   return GL_UNSIGNED_SHORT_5_6_5;
>
> +  if (format == MESA_FORMAT_B10G10R10A2_UNORM)
> + return GL_UNSIGNED_INT_2_10_10_10_REV;
> +
>switch (data_type) {
>case GL_SIGNED_NORMALIZED:
>   return GL_BYTE;
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] meson: fix underlinkage without dri3

[Dylan Baker]

Quoting Emil Velikov (2017-12-04 09:28:19)
> On 1 December 2017 at 23:06, Dylan Baker  wrote:
> > There are some case where the dri3 loader is covering for underlinkage
> > for GLX and EGL, provide the linkage that they actually need.
> >
> > Signed-off-by: Dylan Baker 
> > ---
> >  src/egl/meson.build | 2 +-
> >  src/glx/meson.build | 3 ++-
> >  2 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/egl/meson.build b/src/egl/meson.build
> > index f32715265ce..df6e8b49dac 100644
> > --- a/src/egl/meson.build
> > +++ b/src/egl/meson.build
> > @@ -106,7 +106,7 @@ if with_platform_x11
> >  files_egl += files('drivers/dri2/platform_x11_dri3.c')
> >  link_for_egl += libloader_dri3_helper
> >endif
> > -  deps_for_egl += [dep_xcb_dri2, dep_xcb_xfixes]
> > +  deps_for_egl += [dep_x11_xcb, dep_xcb_dri2, dep_xcb_xfixes]
> >  endif
> >  if with_platform_drm
> >files_egl += files('drivers/dri2/platform_drm.c')
> > diff --git a/src/glx/meson.build b/src/glx/meson.build
> > index 02bd79082fc..a73cf859666 100644
> > --- a/src/glx/meson.build
> > +++ b/src/glx/meson.build
> > @@ -171,7 +171,8 @@ if with_glx == 'dri'
> >  link_args : [ld_args_bsymbolic, ld_args_gc_sections, 
> > extra_ld_args_libgl],
> >  dependencies : [
> >dep_libdrm, dep_dl, dep_m, dep_thread, dep_x11, dep_xcb_glx, dep_xcb,
> > -  dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, extra_deps_libgl,
> > +  dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, dep_xext, dep_xfixes,
> > +  dep_xdamage, extra_deps_libgl,
> Slightly confused do we need dep_xcb_dri3? IIRC all that is part of 
> loader_dri3.

I don't think we do need it, I think I just forgot to remove that.

I'm double checking now, but I'm pretty sure I just forgot to remove it.

> With some confirmation on ^^ + the nitpick in 3/3 the series is
> Reviewed-by: Emil Velikov 
> 
> -Emil


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

Re: [Mesa-dev] [PATCH 2/3] meson: Add lmsensors support

[Emil Velikov]

On 4 December 2017 at 18:25, Dylan Baker  wrote:
> Quoting Emil Velikov (2017-12-04 10:14:15)
>> On 4 December 2017 at 18:06, Dylan Baker  wrote:
>> > Quoting Emil Velikov (2017-12-04 05:20:03)
>> >> On 29 November 2017 at 00:56, Dylan Baker  wrote:
>> >> > Signed-off-by: Dylan Baker 
>> >> > ---
>> >> >  meson.build   | 11 +++
>> >> >  meson_options.txt |  7 +++
>> >> >  src/gallium/drivers/etnaviv/meson.build   |  2 +-
>> >> >  src/gallium/drivers/freedreno/meson.build |  1 +
>> >> >  src/gallium/drivers/nouveau/meson.build   |  2 +-
>> >> >  src/gallium/drivers/r300/meson.build  |  4 +++-
>> >> >  src/gallium/targets/dri/meson.build   |  2 +-
>> >> I'd stick with the autotools approach and add the link to the
>> >> gallium/aux module.
>> >> There are simply too many combinations where lmsensors can be utilised.
>> >>
>> >> -Emil
>> >
>> > lmsensors is in one of the variables in src/gallium/Automake.inc, I copied 
>> > the
>> > location from there, if it would be better to link just to aux we can do 
>> > that
>> > instead.
>> >
>> Memory is failing - forgot I moved that one.
>>
>> If possible I'd recommend having something like
>> GALLIUM_COMMON_LIB_DEPS - a group of shared libraries that all final
>> binaries link against.
>> Alternatively moving it to src/gallium/auxiliary/meson.build should also 
>> work.
>>
>> Thanks
>> Emil
>
> One of the things that Eric suggested and I'm liking more now that we getting
> closer to having everything building (and the complexity is going up), is just
> replacing the individual `dep_foo` with bigger `deq_egl` sort of groups that
> just have all of the egl deps in them already. Alternatively meson is working 
> on
> caching dependency lookups, so in the future it may be possible to stop 
> passing
> around dependencies at all and just have `dependency('foo')` in each target 
> with
> zero overhead.

Yes having a small (ideally single) 'include' and 'library" was one of
the reasons behind the Automake.inc files.
Even if we ignore the speed for a moment, keeping things short keeps
it simple and more robust ;-)

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

Re: [Mesa-dev] [PATCH v2] radv: fix a crash in radv_can_dump_shader()

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Mon, Dec 4, 2017 at 3:32 PM, Samuel Pitoiset
 wrote:
> module can be NULL, oops.
>
> v2: really check that module is not NULL
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_shader.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_shader.h b/src/amd/vulkan/radv_shader.h
> index 91f2e7f2a1..f6486863f8 100644
> --- a/src/amd/vulkan/radv_shader.h
> +++ b/src/amd/vulkan/radv_shader.h
> @@ -118,8 +118,8 @@ radv_can_dump_shader(struct radv_device *device,
>  struct radv_shader_module *module)
>  {
> /* Only dump non-meta shaders, useful for debugging purposes. */
> -   return !module->nir &&
> -  device->instance->debug_flags & RADV_DEBUG_DUMP_SHADERS;
> +   return device->instance->debug_flags & RADV_DEBUG_DUMP_SHADERS &&
> +  module && !module->nir;
>  }
>
>  #endif
> --
> 2.15.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] meson: Add lmsensors support

[Dylan Baker]

Quoting Emil Velikov (2017-12-04 10:14:15)
> On 4 December 2017 at 18:06, Dylan Baker  wrote:
> > Quoting Emil Velikov (2017-12-04 05:20:03)
> >> On 29 November 2017 at 00:56, Dylan Baker  wrote:
> >> > Signed-off-by: Dylan Baker 
> >> > ---
> >> >  meson.build   | 11 +++
> >> >  meson_options.txt |  7 +++
> >> >  src/gallium/drivers/etnaviv/meson.build   |  2 +-
> >> >  src/gallium/drivers/freedreno/meson.build |  1 +
> >> >  src/gallium/drivers/nouveau/meson.build   |  2 +-
> >> >  src/gallium/drivers/r300/meson.build  |  4 +++-
> >> >  src/gallium/targets/dri/meson.build   |  2 +-
> >> I'd stick with the autotools approach and add the link to the
> >> gallium/aux module.
> >> There are simply too many combinations where lmsensors can be utilised.
> >>
> >> -Emil
> >
> > lmsensors is in one of the variables in src/gallium/Automake.inc, I copied 
> > the
> > location from there, if it would be better to link just to aux we can do 
> > that
> > instead.
> >
> Memory is failing - forgot I moved that one.
> 
> If possible I'd recommend having something like
> GALLIUM_COMMON_LIB_DEPS - a group of shared libraries that all final
> binaries link against.
> Alternatively moving it to src/gallium/auxiliary/meson.build should also work.
> 
> Thanks
> Emil

One of the things that Eric suggested and I'm liking more now that we getting
closer to having everything building (and the complexity is going up), is just
replacing the individual `dep_foo` with bigger `deq_egl` sort of groups that
just have all of the egl deps in them already. Alternatively meson is working on
caching dependency lookups, so in the future it may be possible to stop passing
around dependencies at all and just have `dependency('foo')` in each target with
zero overhead.


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

[Mesa-dev] [PATCH v2] egl/android: Partially handle HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED

[Robert Foss]

From: Tomasz Figa 

There is no API available to properly query the IMPLEMENTATION_DEFINED
format. As a workaround we rely here on gralloc allocating either
an arbitrary YCbCr 4:2:0 or RGBX_, with the latter being recognized
by lock_ycbcr failing.

Reviewed-on: https://chromium-review.googlesource.com/566793

Signed-off-by: Tomasz Figa 
Reviewed-by: Chad Versace 
Signed-off-by: Robert Foss 
---
Changes since v1:
 - Replaced bug id with full link

 src/egl/drivers/dri2/platform_android.c | 41 +++--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 63223e9a69..2320fb6f21 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -59,6 +59,11 @@ static const struct droid_yuv_format droid_yuv_formats[] = {
{ HAL_PIXEL_FORMAT_YCbCr_420_888,   0, 1, __DRI_IMAGE_FOURCC_YUV420 },
{ HAL_PIXEL_FORMAT_YCbCr_420_888,   1, 1, __DRI_IMAGE_FOURCC_YVU420 },
{ HAL_PIXEL_FORMAT_YV12,1, 1, __DRI_IMAGE_FOURCC_YVU420 },
+   /* HACK: See droid_create_image_from_prime_fd() and
+* https://issuetracker.google.com/32077885. */
+   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 2, __DRI_IMAGE_FOURCC_NV12 
},
+   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 1, 
__DRI_IMAGE_FOURCC_YUV420 },
+   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   1, 1, 
__DRI_IMAGE_FOURCC_YVU420 },
 };
 
 static int
@@ -90,6 +95,11 @@ get_format_bpp(int native)
 
switch (native) {
case HAL_PIXEL_FORMAT_RGBA_:
+   case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED:
+  /*
+   * HACK: Hardcode this to RGBX_ as per cros_gralloc hack.
+   * TODO: Remove this once https://issuetracker.google.com/32077885 is 
fixed.
+   */
case HAL_PIXEL_FORMAT_RGBX_:
case HAL_PIXEL_FORMAT_BGRA_:
   bpp = 4;
@@ -112,6 +122,11 @@ static int get_fourcc(int native)
case HAL_PIXEL_FORMAT_RGB_565:   return __DRI_IMAGE_FOURCC_RGB565;
case HAL_PIXEL_FORMAT_BGRA_: return __DRI_IMAGE_FOURCC_ARGB;
case HAL_PIXEL_FORMAT_RGBA_: return __DRI_IMAGE_FOURCC_ABGR;
+   case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED:
+  /*
+   * HACK: Hardcode this to RGBX_ as per cros_gralloc hack.
+   * TODO: Remove this once https://issuetracker.google.com/32077885 is 
fixed.
+   */
case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR;
default:
   _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", native);
@@ -125,6 +140,11 @@ static int get_format(int format)
case HAL_PIXEL_FORMAT_BGRA_: return __DRI_IMAGE_FORMAT_ARGB;
case HAL_PIXEL_FORMAT_RGB_565:   return __DRI_IMAGE_FORMAT_RGB565;
case HAL_PIXEL_FORMAT_RGBA_: return __DRI_IMAGE_FORMAT_ABGR;
+   case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED:
+  /*
+   * HACK: Hardcode this to RGBX_ as per cros_gralloc hack.
+   * TODO: Revert this once https://issuetracker.google.com/32077885 is 
fixed.
+   */
case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FORMAT_XBGR;
default:
   _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", format);
@@ -678,6 +698,11 @@ droid_create_image_from_prime_fd_yuv(_EGLDisplay *disp, 
_EGLContext *ctx,
ret = dri2_dpy->gralloc->lock_ycbcr(dri2_dpy->gralloc, buf->handle,
0, 0, 0, 0, 0, );
if (ret) {
+  /* HACK: See droid_create_image_from_prime_fd() and
+   * https://issuetracker.google.com/32077885.*/
+  if (buf->format == HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED)
+ return NULL;
+
   _eglLog(_EGL_WARNING, "gralloc->lock_ycbcr failed: %d", ret);
   return NULL;
}
@@ -757,8 +782,20 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp, 
_EGLContext *ctx,
 {
unsigned int pitch;
 
-   if (is_yuv(buf->format))
-  return droid_create_image_from_prime_fd_yuv(disp, ctx, buf, fd);
+   if (is_yuv(buf->format)) {
+  _EGLImage *image;
+
+  image = droid_create_image_from_prime_fd_yuv(disp, ctx, buf, fd);
+  /*
+   * HACK: https://issuetracker.google.com/32077885
+   * There is no API available to properly query the IMPLEMENTATION_DEFINED
+   * format. As a workaround we rely here on gralloc allocating either
+   * an arbitrary YCbCr 4:2:0 or RGBX_, with the latter being 
recognized
+   * by lock_ycbcr failing.
+   */
+  if (image || buf->format != HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED)
+ return image;
+   }
 
const int fourcc = get_fourcc(buf->format);
if (fourcc == -1) {
-- 
2.14.1

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

Re: [Mesa-dev] Please implement the vaapi-egl for vaapi hardware decoding, vdpau can't handle HEVC 10bit video.

[Leo Liu]

On 12/04/2017 12:47 PM, Emil Velikov wrote:

On 4 December 2017 at 16:33, Leo Liu  wrote:


On 12/04/2017 04:32 AM, Emil Velikov wrote:

On 2 December 2017 at 15:26, Julian Lai  wrote:

Since the crappy vaapi-glx was dropped off by mpv-git player, there is no
way to play HEVC 10bit video with zero-copy hardware acceleration, vdpau
can't do it either, please implement it to make it work.


Both Mesa and libva changes are required. Mark sent patches few months
ago, yet libva does not include them in 2.0 :-(
The Mesa parts couldn't land until the libva ones are in.

Mark had a patch "[PATCH] st/va: Enable vaExportSurfaceHandle() "in the list
to enable it with VA version 1.1.0

I think he probably can point out where to get that VA.

@Mark, if you got chance, please add rb/ab to your patch, and send to me, I
will push it for you.


There's a pending nitpick for it.
Side note: the ML should send you a copy, does it not?

Yes. Just saw that.

Thanks for the reminder, but don't be worry, normally before I commit 
any patches, I even would like to browse either patchwork or mailing 
list achieve to check if any mails that missed from my mail client.


Leo


If Thunderbird
"does not like you" ;-) one could pull it from the Patchwork [1].

Although he might as well request an account [2] [3]

HTH
Emil

[1] https://patchwork.freedesktop.org/patch/191288/
[2] https://www.freedesktop.org/wiki/AccountRequests/ -- instructions
[3] https://bugs.freedesktop.org/show_bug.cgi?id=99601 -- example


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

Re: [Mesa-dev] [PATCH 2/3] meson: Add lmsensors support

[Emil Velikov]

On 4 December 2017 at 18:06, Dylan Baker  wrote:
> Quoting Emil Velikov (2017-12-04 05:20:03)
>> On 29 November 2017 at 00:56, Dylan Baker  wrote:
>> > Signed-off-by: Dylan Baker 
>> > ---
>> >  meson.build   | 11 +++
>> >  meson_options.txt |  7 +++
>> >  src/gallium/drivers/etnaviv/meson.build   |  2 +-
>> >  src/gallium/drivers/freedreno/meson.build |  1 +
>> >  src/gallium/drivers/nouveau/meson.build   |  2 +-
>> >  src/gallium/drivers/r300/meson.build  |  4 +++-
>> >  src/gallium/targets/dri/meson.build   |  2 +-
>> I'd stick with the autotools approach and add the link to the
>> gallium/aux module.
>> There are simply too many combinations where lmsensors can be utilised.
>>
>> -Emil
>
> lmsensors is in one of the variables in src/gallium/Automake.inc, I copied the
> location from there, if it would be better to link just to aux we can do that
> instead.
>
Memory is failing - forgot I moved that one.

If possible I'd recommend having something like
GALLIUM_COMMON_LIB_DEPS - a group of shared libraries that all final
binaries link against.
Alternatively moving it to src/gallium/auxiliary/meson.build should also work.

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

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

[Dylan Baker]

Quoting Eric Engestrom (2017-12-04 07:08:01)
> src/gallium/winsys/pl111/drm/libpl111winsys.a(pl111_drm_winsys.c.o): In 
> function `pl111_drm_screen_create':
> pl111_drm_winsys.c:(.text+0x33): undefined reference to 
> `vc4_drm_screen_create_renderonly'
> 
> Signed-off-by: Eric Engestrom 
> ---
>  meson.build  | 4 
>  src/gallium/meson.build  | 6 +++---
>  src/gallium/winsys/pl111/drm/meson.build | 1 +
>  3 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index f227bc3e018dc39f9f79..f134ede15ce72dda7df6 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -158,6 +158,10 @@ if _drivers != ''
>with_gallium = true
>  endif
>  
> +if with_gallium_pl111 and not with_gallium_vc4
> +  error('Gallium pl111 depends on vc4')
> +endif

There's a similar check for imx and etnaviv in the root meson.build, I think we
should either move that one or put this check in the root. I don't have a
preference either way, if you'd rather move the imx/etnaviv check that should be
it's own patch, so with one of those changes:

Reviewed-by: Dylan Baker 

> +
>  with_intel_vk = false
>  with_amd_vk = false
>  with_any_vk = false
> diff --git a/src/gallium/meson.build b/src/gallium/meson.build
> index 8e60c7f328856017fc35..563905478d4d4f6e9fb4 100644
> --- a/src/gallium/meson.build
> +++ b/src/gallium/meson.build
> @@ -60,13 +60,13 @@ if with_gallium_freedreno
>subdir('drivers/freedreno')
>subdir('winsys/freedreno/drm')
>  endif
> -if with_gallium_pl111
> -  subdir('winsys/pl111/drm')
> -endif
>  if with_gallium_vc4
>subdir('drivers/vc4')
>subdir('winsys/vc4/drm')
>  endif
> +if with_gallium_pl111
> +  subdir('winsys/pl111/drm')
> +endif
>  if with_gallium_vc5
>subdir('drivers/vc5')
>subdir('winsys/vc5/drm')
> diff --git a/src/gallium/winsys/pl111/drm/meson.build 
> b/src/gallium/winsys/pl111/drm/meson.build
> index 952c0b46700f5ddcf7e9..02b176a5c85ee67ff94a 100644
> --- a/src/gallium/winsys/pl111/drm/meson.build
> +++ b/src/gallium/winsys/pl111/drm/meson.build
> @@ -27,4 +27,5 @@ libpl111winsys = static_library(
>],
>c_args : [c_vis_args],
>dependencies: dep_libdrm,
> +  link_with : libvc4winsys,
>  )
> -- 
> Cheers,
>   Eric
> 


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

Re: [Mesa-dev] [PATCH] freedreno: add -Wno-packed-bitfield-compat for meson build

[Dylan Baker]

Reviewed-by: Dylan Baker 

Quoting Rob Clark (2017-12-04 05:44:59)
> Otherwise huge amount of spam from instr-a2xx.h.. gcc has no way to know
> that freedreno was never built with such an old gcc version to care
> about the bugs in old gcc ;-)
> 
> Patch is really Eric Engestrom's, he showed me how to do this in meson.
> 
> Cc: Eric Engestrom 
> Signed-off-by: Rob Clark 
> ---
>  src/gallium/drivers/freedreno/meson.build | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/freedreno/meson.build 
> b/src/gallium/drivers/freedreno/meson.build
> index 909e16b9ed8..444e6234f38 100644
> --- a/src/gallium/drivers/freedreno/meson.build
> +++ b/src/gallium/drivers/freedreno/meson.build
> @@ -201,12 +201,22 @@ freedreno_includes = [
>include_directories('ir3')
>  ]
>  
> +freedreno_c_args = []
> +if cc.has_argument('-Wpacked-bitfield-compat')
> +  freedreno_c_args += '-Wno-packed-bitfield-compat'
> +endif
> +
> +freedreno_cpp_args = []
> +if cpp.has_argument('-Wpacked-bitfield-compat')
> +  freedreno_cpp_args += '-Wno-packed-bitfield-compat'
> +endif
> +
>  libfreedreno = static_library(
>'freedreno',
>[files_libfreedreno, ir3_nir_trig_c, nir_opcodes_h],
>include_directories : freedreno_includes,
> -  c_args : [c_vis_args],
> -  cpp_args : [cpp_vis_args],
> +  c_args : [freedreno_c_args, c_vis_args],
> +  cpp_args : [freedreno_cpp_args, cpp_vis_args],
>dependencies : [dep_libdrm, dep_libdrm_freedreno],
>  )
>  
> -- 
> 2.13.6
> 


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 2/3] meson: Add lmsensors support

[Dylan Baker]

Quoting Emil Velikov (2017-12-04 05:20:03)
> On 29 November 2017 at 00:56, Dylan Baker  wrote:
> > Signed-off-by: Dylan Baker 
> > ---
> >  meson.build   | 11 +++
> >  meson_options.txt |  7 +++
> >  src/gallium/drivers/etnaviv/meson.build   |  2 +-
> >  src/gallium/drivers/freedreno/meson.build |  1 +
> >  src/gallium/drivers/nouveau/meson.build   |  2 +-
> >  src/gallium/drivers/r300/meson.build  |  4 +++-
> >  src/gallium/targets/dri/meson.build   |  2 +-
> I'd stick with the autotools approach and add the link to the
> gallium/aux module.
> There are simply too many combinations where lmsensors can be utilised.
> 
> -Emil

lmsensors is in one of the variables in src/gallium/Automake.inc, I copied the
location from there, if it would be better to link just to aux we can do that
instead.

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] Please implement the vaapi-egl for vaapi hardware decoding, vdpau can't handle HEVC 10bit video.

[Leo Liu]

On 12/04/2017 04:32 AM, Emil Velikov wrote:

On 2 December 2017 at 15:26, Julian Lai  wrote:

Since the crappy vaapi-glx was dropped off by mpv-git player, there is no
way to play HEVC 10bit video with zero-copy hardware acceleration, vdpau
can't do it either, please implement it to make it work.


Both Mesa and libva changes are required. Mark sent patches few months
ago, yet libva does not include them in 2.0 :-(
The Mesa parts couldn't land until the libva ones are in.
Mark had a patch "[PATCH] st/va: Enable vaExportSurfaceHandle() "in the 
list to enable it with VA version 1.1.0


I think he probably can point out where to get that VA.

@Mark, if you got chance, please add rb/ab to your patch, and send to 
me, I will push it for you.


Thanks,
Leo



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

-Emil
___
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] Please implement the vaapi-egl for vaapi hardware decoding, vdpau can't handle HEVC 10bit video.

[Emil Velikov]

On 4 December 2017 at 16:33, Leo Liu  wrote:
>
>
> On 12/04/2017 04:32 AM, Emil Velikov wrote:
>>
>> On 2 December 2017 at 15:26, Julian Lai  wrote:
>>>
>>> Since the crappy vaapi-glx was dropped off by mpv-git player, there is no
>>> way to play HEVC 10bit video with zero-copy hardware acceleration, vdpau
>>> can't do it either, please implement it to make it work.
>>>
>> Both Mesa and libva changes are required. Mark sent patches few months
>> ago, yet libva does not include them in 2.0 :-(
>> The Mesa parts couldn't land until the libva ones are in.
>
> Mark had a patch "[PATCH] st/va: Enable vaExportSurfaceHandle() "in the list
> to enable it with VA version 1.1.0
>
> I think he probably can point out where to get that VA.
>
> @Mark, if you got chance, please add rb/ab to your patch, and send to me, I
> will push it for you.
>
There's a pending nitpick for it.
Side note: the ML should send you a copy, does it not? If Thunderbird
"does not like you" ;-) one could pull it from the Patchwork [1].

Although he might as well request an account [2] [3]

HTH
Emil

[1] https://patchwork.freedesktop.org/patch/191288/
[2] https://www.freedesktop.org/wiki/AccountRequests/ -- instructions
[3] https://bugs.freedesktop.org/show_bug.cgi?id=99601 -- example
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Install dri.pc file when building gallium dri drivers

[Emil Velikov]

On 1 December 2017 at 22:03, Dylan Baker  wrote:
> Currently this pkg-config file is only installed if a classic dri driver
> is built. This is wrong, it should be installed if any dri driver is
> installed, which includes the gallium dri target.
>
> Reported-by: Marc Dietrich 
> Signed-off-by: Dylan Baker 

Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH 0/3] anv/i965: account timestamp correctly on Gen10

[Rafael Antognolli]

This series is

Reviewed-by: Rafael Antognolli 

On Mon, Dec 04, 2017 at 04:21:26PM +, Lionel Landwerlin wrote:
> Hi all,
> 
> We've had some timestamp related issues on Gen10. Those are mostly
> related to the fact that the frequency of the timestamps is variable
> depending on the part you get. There is no way to tell from the
> PCI-id, you can only get that information by reading a couple of
> registers.
> 
> We introduced a new parameter to query in the kernel to expose that
> information. This seems like it's going to land in 4.16. Here are the
> userspace patches making use of that new param.
> 
> Cheers,
> 
> Lionel Landwerlin (3):
>   drm-uapi: Update drm/i915 headers from drm-next
>   i965: read CS timestamp frequency from the kernel on Gen10+
>   anv: query CS timestamp frequency from the kernel
> 
>  include/drm-uapi/README  |  8 ++--
>  include/drm-uapi/drm.h   | 41 +++
>  include/drm-uapi/drm_mode.h  | 70 
> +++-
>  include/drm-uapi/i915_drm.h  | 38 +
>  src/intel/vulkan/anv_device.c| 13 ++
>  src/mesa/drivers/dri/i965/intel_screen.c | 24 +++
>  6 files changed, 188 insertions(+), 6 deletions(-)
> 
> --
> 2.15.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] meson: fix underlinkage without dri3

[Emil Velikov]

On 1 December 2017 at 23:06, Dylan Baker  wrote:
> There are some case where the dri3 loader is covering for underlinkage
> for GLX and EGL, provide the linkage that they actually need.
>
> Signed-off-by: Dylan Baker 
> ---
>  src/egl/meson.build | 2 +-
>  src/glx/meson.build | 3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/egl/meson.build b/src/egl/meson.build
> index f32715265ce..df6e8b49dac 100644
> --- a/src/egl/meson.build
> +++ b/src/egl/meson.build
> @@ -106,7 +106,7 @@ if with_platform_x11
>  files_egl += files('drivers/dri2/platform_x11_dri3.c')
>  link_for_egl += libloader_dri3_helper
>endif
> -  deps_for_egl += [dep_xcb_dri2, dep_xcb_xfixes]
> +  deps_for_egl += [dep_x11_xcb, dep_xcb_dri2, dep_xcb_xfixes]
>  endif
>  if with_platform_drm
>files_egl += files('drivers/dri2/platform_drm.c')
> diff --git a/src/glx/meson.build b/src/glx/meson.build
> index 02bd79082fc..a73cf859666 100644
> --- a/src/glx/meson.build
> +++ b/src/glx/meson.build
> @@ -171,7 +171,8 @@ if with_glx == 'dri'
>  link_args : [ld_args_bsymbolic, ld_args_gc_sections, 
> extra_ld_args_libgl],
>  dependencies : [
>dep_libdrm, dep_dl, dep_m, dep_thread, dep_x11, dep_xcb_glx, dep_xcb,
> -  dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, extra_deps_libgl,
> +  dep_x11_xcb, dep_xcb_dri2, dep_xcb_dri3, dep_xext, dep_xfixes,
> +  dep_xdamage, extra_deps_libgl,
Slightly confused do we need dep_xcb_dri3? IIRC all that is part of loader_dri3.

With some confirmation on ^^ + the nitpick in 3/3 the series is
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH 3/3] meson: Fix overlinkage of dri3 loader

[Emil Velikov]

On 1 December 2017 at 23:06, Dylan Baker  wrote:
> This was covering for underinkage elsewhere. With that fixed these can
> be removed.
>
> Signed-off-by: Dylan Baker 
> ---
>  src/loader/meson.build | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/loader/meson.build b/src/loader/meson.build
> index 2f97cdc83bf..ce7e13c3542 100644
> --- a/src/loader/meson.build
> +++ b/src/loader/meson.build
> @@ -27,8 +27,7 @@ if with_platform_x11 and with_dri3
>  c_args : c_vis_args,
>  include_directories : inc_include,
>  dependencies : [
> -  dep_xshmfence, dep_xcb_present, dep_xcb_dri3, dep_xcb_sync, 
> dep_x11_xcb,
> -  dep_xext, dep_xdamage, dep_xcb_glx, dep_libdrm,
> +  dep_xshmfence, dep_xcb_present, dep_xcb_dri3, dep_xcb_sync, dep_libdrm,
Please sort these:
   dep_xcb_dri3, , dep_xcb_present, dep_xcb_sync, dep_xshmfence, dep_libdrm,

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

[Mesa-dev] [PATCH 1/2] gallium/util: add u_transfer_helper

[Rob Clark]

Add a new helper that drivers can use to emulate various things that
need special handling in particular in transfer_map:

 1) z32_s8x24.. gl/gallium treats this as a single buffer with depth
and stencil interleaved but hardware frequently treats this as
separate z32 and s8 buffers.  Special pack/unpack handling is
needed in transfer_map/unmap to pack/unpack the exposed buffer

 2) fake RGTC.. GPUs designed with GLES in mind, but which can other-
wise do GL3, if native RGTC is not supported it can be emulated
by converting to uncompressed internally, but needs pack/unpack
in transfer_map/unmap

 3) MSAA resolves in the transfer_map() case

v2: add MSAA resolve based on Eric's "gallium: Add helpers for MSAA
resolves in pipe_transfer_map()/unmap()." patch; avoid wrapping
pipe_resource, to make it possible for drivers to use both this
and threaded_context.

Signed-off-by: Rob Clark 
---
 src/gallium/auxiliary/Makefile.sources |   2 +
 src/gallium/auxiliary/meson.build  |   2 +
 src/gallium/auxiliary/util/u_transfer_helper.c | 486 +
 src/gallium/auxiliary/util/u_transfer_helper.h | 132 +++
 src/gallium/include/pipe/p_screen.h|   8 +-
 5 files changed, 629 insertions(+), 1 deletion(-)
 create mode 100644 src/gallium/auxiliary/util/u_transfer_helper.c
 create mode 100644 src/gallium/auxiliary/util/u_transfer_helper.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index f40c4723fae..a2dae04698c 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -304,6 +304,8 @@ C_SOURCES := \
util/u_tile.h \
util/u_transfer.c \
util/u_transfer.h \
+   util/u_transfer_helper.c \
+   util/u_transfer_helper.h \
util/u_threaded_context.c \
util/u_threaded_context.h \
util/u_threaded_context_calls.h \
diff --git a/src/gallium/auxiliary/meson.build 
b/src/gallium/auxiliary/meson.build
index 3e623fd099f..8c242ec1a05 100644
--- a/src/gallium/auxiliary/meson.build
+++ b/src/gallium/auxiliary/meson.build
@@ -324,6 +324,8 @@ files_libgallium = files(
   'util/u_tile.h',
   'util/u_transfer.c',
   'util/u_transfer.h',
+  'util/u_transfer_helper.c',
+  'util/u_transfer_helper.h',
   'util/u_threaded_context.c',
   'util/u_threaded_context.h',
   'util/u_threaded_context_calls.h',
diff --git a/src/gallium/auxiliary/util/u_transfer_helper.c 
b/src/gallium/auxiliary/util/u_transfer_helper.c
new file mode 100644
index 000..6f7a36a5f6d
--- /dev/null
+++ b/src/gallium/auxiliary/util/u_transfer_helper.c
@@ -0,0 +1,486 @@
+/*
+ * Copyright © 2017 Red Hat
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE
+ * SOFTWARE.
+ */
+
+#include "pipe/p_screen.h"
+
+#include "util/u_box.h"
+#include "util/u_format.h"
+#include "util/u_format_rgtc.h"
+#include "util/u_format_zs.h"
+#include "util/u_inlines.h"
+#include "util/u_transfer_helper.h"
+
+
+struct u_transfer_helper {
+   const struct u_transfer_vtbl *vtbl;
+   bool separate_z32s8;
+   bool fake_rgtc;
+   bool msaa_map;
+};
+
+static inline bool handle_transfer(struct pipe_resource *prsc)
+{
+   struct u_transfer_helper *helper = prsc->screen->transfer_helper;
+
+   if (helper->vtbl->get_internal_format) {
+  enum pipe_format internal_format =
+helper->vtbl->get_internal_format(prsc);
+  if (internal_format != prsc->format)
+ return true;
+   }
+
+   if (helper->msaa_map && (prsc->nr_samples > 1))
+  return true;
+
+   return false;
+}
+
+/* The pipe_transfer ptr could either be the driver's, or u_transfer,
+ * depending on whether we are intervening or not.  Check handle_transfer()
+ * before dereferencing.
+ */
+struct u_transfer {
+   struct pipe_transfer base;
+   /* Note that in case of MSAA resolve for transfer plus z32s8 or fake rgtc
+* we 

[Mesa-dev] [PATCH 2/2] freedreno: use u_transfer_helper

[Rob Clark]

Signed-off-by: Rob Clark 
---
 src/gallium/drivers/freedreno/freedreno_resource.c | 271 -
 src/gallium/drivers/freedreno/freedreno_resource.h |   2 +-
 2 files changed, 44 insertions(+), 229 deletions(-)

diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c 
b/src/gallium/drivers/freedreno/freedreno_resource.c
index 2b8831f65e5..c2c0271e89a 100644
--- a/src/gallium/drivers/freedreno/freedreno_resource.c
+++ b/src/gallium/drivers/freedreno/freedreno_resource.c
@@ -289,114 +289,16 @@ fd_resource_layer_offset(struct fd_resource *rsc,
return layer * slice->size0;
 }
 
-static void
-fd_resource_flush_z32s8(struct fd_transfer *trans, const struct pipe_box *box)
-{
-   struct fd_resource *rsc = fd_resource(trans->base.resource);
-   struct fd_resource_slice *slice = fd_resource_slice(rsc, 
trans->base.level);
-   struct fd_resource_slice *sslice = fd_resource_slice(rsc->stencil, 
trans->base.level);
-   enum pipe_format format = trans->base.resource->format;
-
-   float *depth = fd_bo_map(rsc->bo) + slice->offset +
-   fd_resource_layer_offset(rsc, slice, trans->base.box.z) +
-   (trans->base.box.y + box->y) * slice->pitch * 4 + 
(trans->base.box.x + box->x) * 4;
-   uint8_t *stencil = fd_bo_map(rsc->stencil->bo) + sslice->offset +
-   fd_resource_layer_offset(rsc->stencil, sslice, 
trans->base.box.z) +
-   (trans->base.box.y + box->y) * sslice->pitch + 
trans->base.box.x + box->x;
-
-   if (format != PIPE_FORMAT_X32_S8X24_UINT)
-   util_format_z32_float_s8x24_uint_unpack_z_float(
-   depth, slice->pitch * 4,
-   trans->staging, trans->base.stride,
-   box->width, box->height);
-
-   util_format_z32_float_s8x24_uint_unpack_s_8uint(
-   stencil, sslice->pitch,
-   trans->staging, trans->base.stride,
-   box->width, box->height);
-}
-
-static void
-fd_resource_flush_rgtc(struct fd_transfer *trans, const struct pipe_box *box)
-{
-   struct fd_resource *rsc = fd_resource(trans->base.resource);
-   struct fd_resource_slice *slice = fd_resource_slice(rsc, 
trans->base.level);
-   enum pipe_format format = trans->base.resource->format;
-
-   uint8_t *data = fd_bo_map(rsc->bo) + slice->offset +
-   fd_resource_layer_offset(rsc, slice, trans->base.box.z) +
-   ((trans->base.box.y + box->y) * slice->pitch +
-trans->base.box.x + box->x) * rsc->cpp;
-
-   uint8_t *source = trans->staging +
-   util_format_get_nblocksy(format, box->y) * trans->base.stride +
-   util_format_get_stride(format, box->x);
-
-   switch (format) {
-   case PIPE_FORMAT_RGTC1_UNORM:
-   case PIPE_FORMAT_RGTC1_SNORM:
-   case PIPE_FORMAT_LATC1_UNORM:
-   case PIPE_FORMAT_LATC1_SNORM:
-   util_format_rgtc1_unorm_unpack_rgba_8unorm(
-   data, slice->pitch * rsc->cpp,
-   source, trans->base.stride,
-   box->width, box->height);
-   break;
-   case PIPE_FORMAT_RGTC2_UNORM:
-   case PIPE_FORMAT_RGTC2_SNORM:
-   case PIPE_FORMAT_LATC2_UNORM:
-   case PIPE_FORMAT_LATC2_SNORM:
-   util_format_rgtc2_unorm_unpack_rgba_8unorm(
-   data, slice->pitch * rsc->cpp,
-   source, trans->base.stride,
-   box->width, box->height);
-   break;
-   default:
-   assert(!"Unexpected format\n");
-   break;
-   }
-}
-
-static void
-fd_resource_flush(struct fd_transfer *trans, const struct pipe_box *box)
-{
-   enum pipe_format format = trans->base.resource->format;
-
-   switch (format) {
-   case PIPE_FORMAT_Z32_FLOAT_S8X24_UINT:
-   case PIPE_FORMAT_X32_S8X24_UINT:
-   fd_resource_flush_z32s8(trans, box);
-   break;
-   case PIPE_FORMAT_RGTC1_UNORM:
-   case PIPE_FORMAT_RGTC1_SNORM:
-   case PIPE_FORMAT_RGTC2_UNORM:
-   case PIPE_FORMAT_RGTC2_SNORM:
-   case PIPE_FORMAT_LATC1_UNORM:
-   case PIPE_FORMAT_LATC1_SNORM:
-   case PIPE_FORMAT_LATC2_UNORM:
-   case PIPE_FORMAT_LATC2_SNORM:
-   fd_resource_flush_rgtc(trans, box);
-   break;
-   default:
-   assert(!"Unexpected staging transfer type");
-   break;
-   }
-}
-
 static void fd_resource_transfer_flush_region(struct pipe_context *pctx,
struct pipe_transfer *ptrans,
const struct pipe_box *box)
 {
struct fd_resource *rsc = fd_resource(ptrans->resource);
-   struct fd_transfer *trans = fd_transfer(ptrans);
 
if (ptrans->resource->target == PIPE_BUFFER)

Re: [Mesa-dev] screen blurred and glxgears segment fault on ubuntu17.10 for arm architecture server with amdgpu(AMD RADEON PRO WX7100)

[Michel Dänzer]

On 2017-12-04 03:49 AM, Lvzhihong (ReJohn) wrote:
> Hi,all,
> 
>  We met a problem on ubuntu17.10 for arm server with amdgpu(AMD
> RADEON PRO WX7100),  we use open source driver which are integrated in
> ubuntu17.10. And the architecture is AArch64-linux-gnu.
> 
>  
> 
>  we install :
> 
>      apt-get install xserver-xorg xinit xfce4 and mesa-utils glmark2
> 
>  we start x server :
> 
>   startx
> 
>  and then the monitor shows the screen and the screen is blurred.

Can you share the corresponding Xorg log file?


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

Re: [Mesa-dev] [PATCH v4 15/44] i965/fs: Define new shader opcode to set rounding modes

[Chema Casanova]

El 01/12/17 a las 09:06, Pohjolainen, Topi escribió:
> On Thu, Nov 30, 2017 at 03:07:59AM +0100, Jose Maria Casanova Crespo wrote:
>> From: Alejandro Piñeiro 
>>
>> Although it is possible to emit them directly as AND/OR on brw_fs_nir,
>> having a specific opcode makes it easier to remove duplicate settings
>> later.
>>
>> v2: (Curro)
>>   - Set thread control to 'switch' when using the control register
>>   - Use a single SHADER_OPCODE_RND_MODE opcode taking an immediate
>> with the rounding mode.
>>   - Avoid magic numbers setting rounding mode field at control register.
>> v3: (Curro)
>>   - Remove redundant and add missing whitespace lines.
>>   - Match printing instruction to IR opcode "rnd_mode"
>>
>> v4: (Topi Pohjolainen)
>>   - Fix code style.
>>
>> Signed-off-by:  Alejandro Piñeiro 
>> Signed-off-by:  Jose Maria Casanova Crespo 
>> Reviewed-by: Francisco Jerez 
>> Reviewed-by: Jason Ekstrand 
>> ---
>>  src/intel/compiler/brw_eu.h |  4 
>>  src/intel/compiler/brw_eu_defines.h | 16 
>>  src/intel/compiler/brw_eu_emit.c| 33 
>> +
>>  src/intel/compiler/brw_fs_generator.cpp |  5 +
>>  src/intel/compiler/brw_shader.cpp   |  4 
>>  5 files changed, 62 insertions(+)
>>
>> diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
>> index b5a206b3f1..343dcd867d 100644
>> --- a/src/intel/compiler/brw_eu.h
>> +++ b/src/intel/compiler/brw_eu.h
>> @@ -510,6 +510,10 @@ brw_broadcast(struct brw_codegen *p,
>>struct brw_reg src,
>>struct brw_reg idx);
>>  
>> +void
>> +brw_rounding_mode(struct brw_codegen *p,
>> +  enum brw_rnd_mode mode);
>> +
>>  /***
>>   * brw_eu_util.c:
>>   */
>> diff --git a/src/intel/compiler/brw_eu_defines.h 
>> b/src/intel/compiler/brw_eu_defines.h
>> index 291dd361a2..8a8f36cbc1 100644
>> --- a/src/intel/compiler/brw_eu_defines.h
>> +++ b/src/intel/compiler/brw_eu_defines.h
>> @@ -400,6 +400,8 @@ enum opcode {
>> SHADER_OPCODE_TYPED_SURFACE_WRITE,
>> SHADER_OPCODE_TYPED_SURFACE_WRITE_LOGICAL,
>>  
>> +   SHADER_OPCODE_RND_MODE,
>> +
>> SHADER_OPCODE_MEMORY_FENCE,
>>  
>> SHADER_OPCODE_GEN4_SCRATCH_READ,
>> @@ -1238,4 +1240,18 @@ enum brw_message_target {
>>  /* R0 */
>>  # define GEN7_GS_PAYLOAD_INSTANCE_ID_SHIFT  27
>>  
>> +/* CR0.0[5:4] Floating-Point Rounding Modes
>> + *  Skylake PRM, Volume 7 Part 1, "Control Register", page 756
>> + */
>> +
>> +#define BRW_CR0_RND_MODE_MASK 0x30
>> +#define BRW_CR0_RND_MODE_SHIFT4
>> +
>> +enum PACKED brw_rnd_mode {
>> +   BRW_RND_MODE_RTNE = 0,  /* Round to Nearest or Even */
>> +   BRW_RND_MODE_RU = 1,/* Round Up, toward +inf */
>> +   BRW_RND_MODE_RD = 2,/* Round Down, toward -inf */
>> +   BRW_RND_MODE_RTZ = 3,   /* Round Toward Zero */
>> +};
>> +
>>  #endif /* BRW_EU_DEFINES_H */
>> diff --git a/src/intel/compiler/brw_eu_emit.c 
>> b/src/intel/compiler/brw_eu_emit.c
>> index dc14023b48..ca97ff7325 100644
>> --- a/src/intel/compiler/brw_eu_emit.c
>> +++ b/src/intel/compiler/brw_eu_emit.c
>> @@ -3589,3 +3589,36 @@ brw_WAIT(struct brw_codegen *p)
>> brw_inst_set_exec_size(devinfo, insn, BRW_EXECUTE_1);
>> brw_inst_set_mask_control(devinfo, insn, BRW_MASK_DISABLE);
>>  }
>> +
>> +/**
>> + * Changes the floating point rounding mode updating the control register
>> + * field defined at cr0.0[5-6] bits. This function supports the changes to
>> + * RTNE (00), RU (01), RD (10) and RTZ (11) rounding using bitwise 
>> operations.
>> + * Only RTNE and RTZ rounding are enabled at nir.
>> + */
>> +void
>> +brw_rounding_mode(struct brw_codegen *p,
>> +  enum brw_rnd_mode mode)
>> +{
>> +   const unsigned bits = mode << BRW_CR0_RND_MODE_SHIFT;
>> +
>> +   if (bits != BRW_CR0_RND_MODE_MASK) {
>> +  brw_inst *inst = brw_AND(p, brw_cr0_reg(0), brw_cr0_reg(0),
>> +   brw_imm_ud(~BRW_CR0_RND_MODE_MASK));
>> +
>> +  /* From the Skylake PRM, Volume 7, page 760:
>> +   *  "Implementation Restriction on Register Access: When the control
>> +   *   register is used as an explicit source and/or destination, 
>> hardware
>> +   *   does not ensure execution pipeline coherency. Software must set 
>> the
>> +   *   thread control field to ‘switch’ for an instruction that uses
> Putting "uses" to the next line would avoid overflowing the 80 column line
> width.

My editor says that that "uses" is at column 72, and previous lines
"hardware" and "the" are at column within limits on column 78...

Chema


>
>> +   *   control register as an explicit operand."
>> +   */
>> +  brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
>> +}
>> +
>> +   if (bits) {
>> +  brw_inst *inst = brw_OR(p, 

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

[Eric Engestrom]

On Monday, 2017-12-04 12:48:55 +0200, Vadim Shovkoplias wrote:
> Hi Eric,

Hey, sorry, I forgot to hit "send" on the reply I wrote on friday :]

> 
> Mostly by a static analysis tool. It found at least 7 issues with useless
> free() calls and other problems that probably should be fixed.

What tool? It would be interesting for others to know what tools exist,
especially when they find issues other tools didn't :)

> Suggest please should I create one cumulative commit for this or it should
> be a separate commits ?

Same kind of issues in the same module should be grouped, whereas
different kind of issues or different modules should be separate.

Don't worry too much about it though, if people ask you to merge or
split commits, it's not that complicated to do for a v2 :)

> 
> 2017-12-01 17:41 GMT+02:00 Eric Engestrom :
> 
> > On Friday, 2017-12-01 17:08:53 +0200, vadim.shovkopl...@gmail.com wrote:
> > > From: Vadym Shovkoplias 
> > >
> > > In this condition dri2_dpy->driver_name string always equals
> > > NULL, so call to free() is useless
> > >
> > > Signed-off-by: Vadym Shovkoplias 
> >
> > Reviewed and pushed :)
> >
> > Are you finding all of these by inspection, or are you using a tool?
> >
> > > ---
> > >  src/egl/drivers/dri2/platform_x11.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/src/egl/drivers/dri2/platform_x11.c b/src/egl/drivers/dri2/
> > platform_x11.c
> > > index c49cb1f..8ede590b 100644
> > > --- a/src/egl/drivers/dri2/platform_x11.c
> > > +++ b/src/egl/drivers/dri2/platform_x11.c
> > > @@ -704,7 +704,6 @@ dri2_x11_connect(struct dri2_egl_display *dri2_dpy)
> > >
> > > if (dri2_dpy->driver_name == NULL) {
> > >close(dri2_dpy->fd);
> > > -  free(dri2_dpy->driver_name);
> > >free(connect);
> > >return EGL_FALSE;
> > > }
> > > --
> > > 2.7.4
> > >
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 11/44] i965: Support for 16-bit base types in helper functions

[Chema Casanova]

El 01/12/17 a las 09:03, Pohjolainen, Topi escribió:
> On Thu, Nov 30, 2017 at 03:07:55AM +0100, Jose Maria Casanova Crespo wrote:
>> v2: Fixed calculation of scalar size for 16-bit types. (Jason Ekstrand)
>>
>> Signed-off-by: Jose Maria Casanova Crespo 
>> Signed-off-by: Eduardo Lima 
>> Reviewed-by: Jason Ekstrand 
>> ---
>>  src/intel/compiler/brw_fs.cpp |  4 
>>  src/intel/compiler/brw_nir.c  | 16 
>>  src/intel/compiler/brw_shader.cpp |  6 ++
>>  3 files changed, 26 insertions(+)
>>
>> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
>> index 6772c0d5a5..6cdd2bd9f3 100644
>> --- a/src/intel/compiler/brw_fs.cpp
>> +++ b/src/intel/compiler/brw_fs.cpp
>> @@ -454,6 +454,10 @@ type_size_scalar(const struct glsl_type *type)
>> case GLSL_TYPE_FLOAT:
>> case GLSL_TYPE_BOOL:
>>return type->components();
>> +   case GLSL_TYPE_UINT16:
>> +   case GLSL_TYPE_INT16:
>> +   case GLSL_TYPE_FLOAT16:
>> +  return DIV_ROUND_UP(type->components(), 2);
>> case GLSL_TYPE_DOUBLE:
>> case GLSL_TYPE_UINT64:
>> case GLSL_TYPE_INT64:
>> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
>> index 8f3f77f89a..cca4b45ae6 100644
>> --- a/src/intel/compiler/brw_nir.c
>> +++ b/src/intel/compiler/brw_nir.c
>> @@ -843,12 +843,18 @@ brw_type_for_nir_type(const struct gen_device_info 
>> *devinfo, nir_alu_type type)
>> case nir_type_float:
>> case nir_type_float32:
>>return BRW_REGISTER_TYPE_F;
>> +   case nir_type_float16:
>> +  return BRW_REGISTER_TYPE_HF;
>> case nir_type_float64:
>>return BRW_REGISTER_TYPE_DF;
>> case nir_type_int64:
>>return devinfo->gen < 8 ? BRW_REGISTER_TYPE_DF : BRW_REGISTER_TYPE_Q;
>> case nir_type_uint64:
>>return devinfo->gen < 8 ? BRW_REGISTER_TYPE_DF : BRW_REGISTER_TYPE_UQ;
>> +   case nir_type_int16:
>> +  return BRW_REGISTER_TYPE_W;
>> +   case nir_type_uint16:
>> +  return BRW_REGISTER_TYPE_UW;
>> default:
>>unreachable("unknown type");
>> }
>> @@ -867,6 +873,9 @@ brw_glsl_base_type_for_nir_type(nir_alu_type type)
>> case nir_type_float32:
>>return GLSL_TYPE_FLOAT;
>>  
>> +   case nir_type_float16:
>> +  return GLSL_TYPE_FLOAT16;
>> +
>> case nir_type_float64:
>>return GLSL_TYPE_DOUBLE;
>>  
>> @@ -878,6 +887,13 @@ brw_glsl_base_type_for_nir_type(nir_alu_type type)
>> case nir_type_uint32:
>>return GLSL_TYPE_UINT;
>>  
>> +   case nir_type_int16:
>> +  return GLSL_TYPE_INT16;
>> +
>> +   case nir_type_uint16:
>> +  return GLSL_TYPE_UINT16;
>> +
>> +
> Extra newline.

Fixed locally,

Thanks for the review.

Chema

>
>> default:
>>unreachable("bad type");
>> }
>> diff --git a/src/intel/compiler/brw_shader.cpp 
>> b/src/intel/compiler/brw_shader.cpp
>> index ba61481a0a..aa9e5f3d28 100644
>> --- a/src/intel/compiler/brw_shader.cpp
>> +++ b/src/intel/compiler/brw_shader.cpp
>> @@ -34,14 +34,20 @@ enum brw_reg_type
>>  brw_type_for_base_type(const struct glsl_type *type)
>>  {
>> switch (type->base_type) {
>> +   case GLSL_TYPE_FLOAT16:
>> +  return BRW_REGISTER_TYPE_HF;
>> case GLSL_TYPE_FLOAT:
>>return BRW_REGISTER_TYPE_F;
>> case GLSL_TYPE_INT:
>> case GLSL_TYPE_BOOL:
>> case GLSL_TYPE_SUBROUTINE:
>>return BRW_REGISTER_TYPE_D;
>> +   case GLSL_TYPE_INT16:
>> +  return BRW_REGISTER_TYPE_W;
>> case GLSL_TYPE_UINT:
>>return BRW_REGISTER_TYPE_UD;
>> +   case GLSL_TYPE_UINT16:
>> +  return BRW_REGISTER_TYPE_UW;
>> case GLSL_TYPE_ARRAY:
>>return brw_type_for_base_type(type->fields.array);
>> case GLSL_TYPE_STRUCT:
>> -- 
>> 2.14.3
>>
>> ___
>> 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] glsl/linker: link-error using the same name in unnamed block and outside

[Juan A. Suarez Romero]

According with OpenGL GLSL 4.20 spec, section 4.3.9, page 57:

   "It is a link-time error if any particular shader interface
contains:
  - two different blocks, each having no instance name, and each
having a member of the same name, or
  - a variable outside a block, and a block with no instance name,
where the variable has the same name as a member in the block."

This means that it is a link error if for example we have a vertex
shader with the following definition.

  "layout(location=0) uniform Data { float a; float b; };"

and a fragment shader with:

  "uniform float a;"

As in both cases we refer to both uniforms as "a", and thus using
glGetUniformLocation() wouldn't know which one we mean.
---
 src/compiler/glsl/linker.cpp | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 33fd76deae9..b6de7b54ae3 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -,6 +,29 @@ cross_validate_globals(struct gl_shader_program *prog,
 return;
  }
 
+ /* In OpenGL GLSL 4.20 spec, section 4.3.9, page 57:
+  *
+  *   "It is a link-time error if any particular shader interface
+  *contains:
+  *
+  *- two different blocks, each having no instance name, and each
+  *  having a member of the same name, or
+  *
+  *- a variable outside a block, and a block with no instance name,
+  *  where the variable has the same name as a member in the 
block."
+  */
+ if (var->data.mode == existing->data.mode &&
+ var->get_interface_type() != existing->get_interface_type()) {
+linker_error(prog, "declarations for %s `%s` are in "
+ "%s and %s\n",
+ mode_string(var), var->name,
+ existing->get_interface_type() ?
+   existing->get_interface_type()->name : "outside a 
block",
+ var->get_interface_type() ?
+   var->get_interface_type()->name : "outside a 
block");
+
+return;
+ }
  /* Only in GLSL ES 3.10, the precision qualifier should not match
   * between block members defined in matched block names within a
   * shader interface.
-- 
2.15.1

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

[Mesa-dev] [PATCH 0/3] anv/i965: account timestamp correctly on Gen10

[Lionel Landwerlin]

Hi all,

We've had some timestamp related issues on Gen10. Those are mostly
related to the fact that the frequency of the timestamps is variable
depending on the part you get. There is no way to tell from the
PCI-id, you can only get that information by reading a couple of
registers.

We introduced a new parameter to query in the kernel to expose that
information. This seems like it's going to land in 4.16. Here are the
userspace patches making use of that new param.

Cheers,

Lionel Landwerlin (3):
  drm-uapi: Update drm/i915 headers from drm-next
  i965: read CS timestamp frequency from the kernel on Gen10+
  anv: query CS timestamp frequency from the kernel

 include/drm-uapi/README  |  8 ++--
 include/drm-uapi/drm.h   | 41 +++
 include/drm-uapi/drm_mode.h  | 70 +++-
 include/drm-uapi/i915_drm.h  | 38 +
 src/intel/vulkan/anv_device.c| 13 ++
 src/mesa/drivers/dri/i965/intel_screen.c | 24 +++
 6 files changed, 188 insertions(+), 6 deletions(-)

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

[Mesa-dev] [PATCH 2/3] i965: read CS timestamp frequency from the kernel on Gen10+

[Lionel Landwerlin]

We cannot figure this value out of the PCI-id anymore. Let's read it
from the kernel (which computes this from a few registers).

When running on a (upcoming) 4.16-rc1+ kernel, this will fixes piglit
tests on CNL :

spec@arb_timer_query@query gl_timestamp
spec@arb_timer_query@timestamp-get
spec@ext_timer_query@time-elapsed

Signed-off-by: Lionel Landwerlin 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index db1552c1880..0c17b4050c4 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1685,6 +1685,27 @@ intelDestroyBuffer(__DRIdrawable * driDrawPriv)
 _mesa_reference_framebuffer(, NULL);
 }
 
+static void
+intel_cs_timestamp_frequency(struct intel_screen *screen)
+{
+   /* We shouldn't need to update gen_device_info.timestamp_frequency prior to
+* gen10, PCI-id is enough to figure it out.
+*/
+   assert(screen->devinfo.gen >= 10);
+
+   int ret, freq;
+
+   ret = intel_get_param(screen, I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+ );
+   if (ret < 0) {
+  _mesa_warning(NULL,
+"Kernel 4.15 required to read the CS timestamp 
frequency.\n");
+  return;
+   }
+
+   screen->devinfo.timestamp_frequency = freq;
+}
+
 static void
 intel_detect_sseu(struct intel_screen *screen)
 {
@@ -2405,6 +2426,9 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
isl_device_init(>isl_dev, >devinfo,
screen->hw_has_swizzling);
 
+   if (devinfo->gen >= 10)
+  intel_cs_timestamp_frequency(screen);
+
/* GENs prior to 8 do not support EU/Subslice info */
if (devinfo->gen >= 8) {
   intel_detect_sseu(screen);
-- 
2.15.1

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

[Mesa-dev] [PATCH 3/3] anv: query CS timestamp frequency from the kernel

[Lionel Landwerlin]

The reference value in gen_device_info isn't going to be acurate on
Gen10+. We should query it from the kernel, which reads a couple of
register to compute the actual value.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/vulkan/anv_device.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index b5577ee61de..ac2dc9bf131 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -370,6 +370,19 @@ anv_physical_device_init(struct anv_physical_device 
*device,
 
bool swizzled = anv_gem_get_bit6_swizzle(fd, I915_TILING_X);
 
+   /* Starting with Gen10, the timestamp frequency of the command streamer may
+* vary from one part to another. We can query the value from the kernel.
+*/
+   if (device->info.gen >= 10) {
+  int timestamp_frequency =
+ anv_gem_get_param(fd, I915_PARAM_CS_TIMESTAMP_FREQUENCY);
+
+  if (timestamp_frequency < 0)
+ intel_logw("Kernel 4.16-rc1+ required to properly query CS timestamp 
frequency");
+  else
+ device->info.timestamp_frequency = timestamp_frequency;
+   }
+
/* GENs prior to 8 do not support EU/Subslice info */
if (device->info.gen >= 8) {
   device->subslice_total = anv_gem_get_param(fd, 
I915_PARAM_SUBSLICE_TOTAL);
-- 
2.15.1

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

[Mesa-dev] [PATCH 1/3] drm-uapi: Update drm/i915 headers from drm-next

[Lionel Landwerlin]

Taken from drm-next ca797d29cd63e7b71b4eea29aff3b1cefd1ecb59

Signed-off-by: Lionel Landwerlin 
---
 include/drm-uapi/README |  8 +++---
 include/drm-uapi/drm.h  | 41 ++
 include/drm-uapi/drm_mode.h | 70 +++--
 include/drm-uapi/i915_drm.h | 38 
 4 files changed, 151 insertions(+), 6 deletions(-)

diff --git a/include/drm-uapi/README b/include/drm-uapi/README
index 27de91cad0c..53dd711dad5 100644
--- a/include/drm-uapi/README
+++ b/include/drm-uapi/README
@@ -13,9 +13,9 @@ $ make headers_install INSTALL_HDR_PATH=/path/to/install
 
 The last update was done at the following kernel commit :
 
-commit 7846b12fe0b5feab5446d892f41b5140c1419109
-Merge: 7ebdb0d d78acfe
+commit ca797d29cd63e7b71b4eea29aff3b1cefd1ecb59
+Merge: 2c1c55cb75a9 010d118c2061
 Author: Dave Airlie 
-Date:   Tue Aug 29 10:38:14 2017 +1000
+Date:   Mon Dec 4 09:40:35 2017 +1000
 
-Merge branch 'drm-vmwgfx-next' of 
git://people.freedesktop.org/~syeh/repos_linux into drm-next
+Merge tag 'drm-intel-next-2017-11-17-1' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next
diff --git a/include/drm-uapi/drm.h b/include/drm-uapi/drm.h
index 4737261ae3f..f0bd91de0cf 100644
--- a/include/drm-uapi/drm.h
+++ b/include/drm-uapi/drm.h
@@ -731,6 +731,28 @@ struct drm_syncobj_array {
__u32 pad;
 };
 
+/* Query current scanout sequence number */
+struct drm_crtc_get_sequence {
+   __u32 crtc_id;  /* requested crtc_id */
+   __u32 active;   /* return: crtc output is active */
+   __u64 sequence; /* return: most recent vblank sequence */
+   __s64 sequence_ns;  /* return: most recent time of first pixel out 
*/
+};
+
+/* Queue event to be delivered at specified sequence. Time stamp marks
+ * when the first pixel of the refresh cycle leaves the display engine
+ * for the display
+ */
+#define DRM_CRTC_SEQUENCE_RELATIVE 0x0001  /* sequence is 
relative to current */
+#define DRM_CRTC_SEQUENCE_NEXT_ON_MISS 0x0002  /* Use next 
sequence if we've missed */
+
+struct drm_crtc_queue_sequence {
+   __u32 crtc_id;
+   __u32 flags;
+   __u64 sequence; /* on input, target sequence. on output, actual 
sequence */
+   __u64 user_data;/* user data passed to event */
+};
+
 #if defined(__cplusplus)
 }
 #endif
@@ -813,6 +835,9 @@ extern "C" {
 
 #define DRM_IOCTL_WAIT_VBLANK  DRM_IOWR(0x3a, union drm_wait_vblank)
 
+#define DRM_IOCTL_CRTC_GET_SEQUENCEDRM_IOWR(0x3b, struct 
drm_crtc_get_sequence)
+#define DRM_IOCTL_CRTC_QUEUE_SEQUENCE  DRM_IOWR(0x3c, struct 
drm_crtc_queue_sequence)
+
 #define DRM_IOCTL_UPDATE_DRAW  DRM_IOW(0x3f, struct drm_update_draw)
 
 #define DRM_IOCTL_MODE_GETRESOURCESDRM_IOWR(0xA0, struct drm_mode_card_res)
@@ -857,6 +882,11 @@ extern "C" {
 #define DRM_IOCTL_SYNCOBJ_RESETDRM_IOWR(0xC4, struct 
drm_syncobj_array)
 #define DRM_IOCTL_SYNCOBJ_SIGNAL   DRM_IOWR(0xC5, struct drm_syncobj_array)
 
+#define DRM_IOCTL_MODE_CREATE_LEASEDRM_IOWR(0xC6, struct 
drm_mode_create_lease)
+#define DRM_IOCTL_MODE_LIST_LESSEESDRM_IOWR(0xC7, struct 
drm_mode_list_lessees)
+#define DRM_IOCTL_MODE_GET_LEASE   DRM_IOWR(0xC8, struct 
drm_mode_get_lease)
+#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct 
drm_mode_revoke_lease)
+
 /**
  * Device specific ioctls should only be in their respective headers
  * The device specific ioctl range is from 0x40 to 0x9f.
@@ -887,6 +917,7 @@ struct drm_event {
 
 #define DRM_EVENT_VBLANK 0x01
 #define DRM_EVENT_FLIP_COMPLETE 0x02
+#define DRM_EVENT_CRTC_SEQUENCE0x03
 
 struct drm_event_vblank {
struct drm_event base;
@@ -897,6 +928,16 @@ struct drm_event_vblank {
__u32 crtc_id; /* 0 on older kernels that do not support this */
 };
 
+/* Event delivered at sequence. Time stamp marks when the first pixel
+ * of the refresh cycle leaves the display engine for the display
+ */
+struct drm_event_crtc_sequence {
+   struct drm_eventbase;
+   __u64   user_data;
+   __s64   time_ns;
+   __u64   sequence;
+};
+
 /* typedef area */
 typedef struct drm_clip_rect drm_clip_rect_t;
 typedef struct drm_drawable_info drm_drawable_info_t;
diff --git a/include/drm-uapi/drm_mode.h b/include/drm-uapi/drm_mode.h
index 54fc38c3c3f..5597a87154e 100644
--- a/include/drm-uapi/drm_mode.h
+++ b/include/drm-uapi/drm_mode.h
@@ -749,9 +749,9 @@ struct drm_format_modifier {
 * If the number formats grew to 128, and formats 98-102 are
 * supported with the modifier:
 *
-* 0x003c 
+* 0x007c 
 *^
-*|__offset = 64, formats = 0x3c
+*|__offset = 64, formats = 

Re: [Mesa-dev] [PATCH 3/3] nv50/ir: Fix unused var warnings in release build

[Eric Engestrom]

On Saturday, 2017-12-02 13:28:04 -0500, Ilia Mirkin wrote:
> On Sat, Dec 2, 2017 at 1:22 PM, Rhys Kidd  wrote:
> > Signed-off-by: Rhys Kidd 
> > ---
> >  src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 2 +-
> >  src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp  | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp 
> > b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
> > index cc2a88eb40..139ff4a31d 100644
> > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
> > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
> > @@ -621,7 +621,7 @@ void
> >  CodeEmitterNV50::emitLOAD(const Instruction *i)
> >  {
> > DataFile sf = i->src(0).getFile();
> > -   int32_t offset = i->getSrc(0)->reg.data.offset;
> > +   MAYBE_UNUSED int32_t offset = i->getSrc(0)->reg.data.offset;
> >
> > switch (sf) {
> > case FILE_SHADER_INPUT:
> > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
> > b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> > index 61d4e6a2d0..f49459b969 100644
> > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> > @@ -3308,7 +3308,7 @@ PostRaLoadPropagation::handleMADforNV50(Instruction 
> > *i)
> >   i->setSrc(1, def->getSrc(0));
> >} else {
> >   ImmediateValue val;
> > - bool ret = def->src(0).getImmediate(val);
> > + MAYBE_UNUSED bool ret = def->src(0).getImmediate(val);
> 
> Can you write a comment mentioning that getImmediate() has
> side-effects on the argument, so this *shouldn't* get folded into the
> assert? My concern is that with the MAYBE_UNUSED there, someone with a
> twitchy thumb may be tempted to press that button...

Being someone with such a twitchy thumb, I approve of adding this
comment :)
Reviewed-by: Eric Engestrom 

> 
>   -ilia
> 
> >   assert(ret);
> >   if (i->getSrc(1)->reg.data.id & 1)
> >  val.reg.data.u32 >>= 16;
> > --
> > 2.14.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 01/44] glsl: Add 16-bit types

[Chema Casanova]

El 30/11/17 a las 10:25, Pohjolainen, Topi escribió:
> On Thu, Nov 30, 2017 at 03:07:45AM +0100, Jose Maria Casanova Crespo wrote:
>> From: Eduardo Lima Mitev 
> Just a few style nits, see below.
>
>> Adds new INT16, UINT16 and FLOAT16 base types.
>>
>> The corresponding GL types for half floats were reused from the
>> AMD_gpu_shader_half_float extension. The int16 and uint16 types come from
>> NV_gpu_shader_5 extension.
>>
>> This adds the builtins and the lexer support.
>>
>> To avoid a bunch of warnings due to cases not handled in switch, the
>> new types have been added to a few places using same behavior as
>> their 32-bit counterparts, except for a few trivial cases where they are
>> already handled properly. Subsequent patches in this set will provide
>> correct 16-bit implementations when needed.
>>
>> v2: * Use FLOAT16 instead of HALF_FLOAT as name of the base type.
>> * Removed float16_t from builtin types.
>> * Don't copy 16-bit types as if they were 32-bit values in
>>   copy_constant_to_storage().
>> * Use get_scalar_type() instead of adding a new custom switch
>>   statement.
>> (Jason Ekstrand)
>> v3: Use GL_FLOAT16_NV instead of GL_HALF_FLOAT for consistency
>> (Ilia Mirkin)
>> v4: Add missing 16-bit base types support in glsl_to_nir (Eduardo Lima).
>>
>> Signed-off-by: Jose Maria Casanova Crespo 
>> Signed-off-by: Eduardo Lima 
>> Signed-off-by: Alejandro Piñeiro 
>> Reviewed-by: Jason Ekstrand 
>> Reviewed-by: Nicolai Hähnle 
>> ---
>>  src/compiler/builtin_type_macros.h  | 26 +++
>>  src/compiler/glsl/ast_to_hir.cpp|  3 +
>>  src/compiler/glsl/glsl_to_nir.cpp   |  6 +-
>>  src/compiler/glsl/ir_clone.cpp  |  3 +
>>  src/compiler/glsl/link_uniform_initializers.cpp |  3 +
>>  src/compiler/glsl/lower_buffer_access.cpp   |  3 +-
>>  src/compiler/glsl_types.cpp | 93 
>> -
>>  src/compiler/glsl_types.h   | 10 ++-
>>  src/mesa/program/ir_to_mesa.cpp |  6 ++
>>  9 files changed, 145 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/compiler/builtin_type_macros.h 
>> b/src/compiler/builtin_type_macros.h
>> index a275617b34..e3a1cd29c8 100644
>> --- a/src/compiler/builtin_type_macros.h
>> +++ b/src/compiler/builtin_type_macros.h
>> @@ -62,6 +62,22 @@ DECL_TYPE(mat3x4, GL_FLOAT_MAT3x4, GLSL_TYPE_FLOAT, 4, 3)
>>  DECL_TYPE(mat4x2, GL_FLOAT_MAT4x2, GLSL_TYPE_FLOAT, 2, 4)
>>  DECL_TYPE(mat4x3, GL_FLOAT_MAT4x3, GLSL_TYPE_FLOAT, 3, 4)
>>  
>> +DECL_TYPE(float16_t, GL_FLOAT16_NV,GLSL_TYPE_FLOAT16, 1, 1)
>> +DECL_TYPE(f16vec2,   GL_FLOAT16_VEC2_NV,   GLSL_TYPE_FLOAT16, 2, 1)
>> +DECL_TYPE(f16vec3,   GL_FLOAT16_VEC3_NV,   GLSL_TYPE_FLOAT16, 3, 1)
>> +DECL_TYPE(f16vec4,   GL_FLOAT16_VEC4_NV,   GLSL_TYPE_FLOAT16, 4, 1)
>> +
>> +DECL_TYPE(f16mat2,   GL_FLOAT16_MAT2_AMD,   GLSL_TYPE_FLOAT16, 2, 2)
>> +DECL_TYPE(f16mat3,   GL_FLOAT16_MAT3_AMD,   GLSL_TYPE_FLOAT16, 3, 3)
>> +DECL_TYPE(f16mat4,   GL_FLOAT16_MAT4_AMD,   GLSL_TYPE_FLOAT16, 4, 4)
>> +
>> +DECL_TYPE(f16mat2x3, GL_FLOAT16_MAT2x3_AMD, GLSL_TYPE_FLOAT16, 3, 2)
>> +DECL_TYPE(f16mat2x4, GL_FLOAT16_MAT2x4_AMD, GLSL_TYPE_FLOAT16, 4, 2)
>> +DECL_TYPE(f16mat3x2, GL_FLOAT16_MAT3x2_AMD, GLSL_TYPE_FLOAT16, 2, 3)
>> +DECL_TYPE(f16mat3x4, GL_FLOAT16_MAT3x4_AMD, GLSL_TYPE_FLOAT16, 4, 3)
>> +DECL_TYPE(f16mat4x2, GL_FLOAT16_MAT4x2_AMD, GLSL_TYPE_FLOAT16, 2, 4)
>> +DECL_TYPE(f16mat4x3, GL_FLOAT16_MAT4x3_AMD, GLSL_TYPE_FLOAT16, 3, 4)
>> +
>>  DECL_TYPE(double,  GL_DOUBLE,GLSL_TYPE_DOUBLE, 1, 1)
>>  DECL_TYPE(dvec2,   GL_DOUBLE_VEC2,   GLSL_TYPE_DOUBLE, 2, 1)
>>  DECL_TYPE(dvec3,   GL_DOUBLE_VEC3,   GLSL_TYPE_DOUBLE, 3, 1)
>> @@ -88,6 +104,16 @@ DECL_TYPE(u64vec2,  GL_UNSIGNED_INT64_VEC2_ARB, 
>> GLSL_TYPE_UINT64, 2, 1)
>>  DECL_TYPE(u64vec3,  GL_UNSIGNED_INT64_VEC3_ARB, GLSL_TYPE_UINT64, 3, 1)
>>  DECL_TYPE(u64vec4,  GL_UNSIGNED_INT64_VEC4_ARB, GLSL_TYPE_UINT64, 4, 1)
>>  
>> +DECL_TYPE(int16_t,  GL_INT16_NV,  GLSL_TYPE_INT16, 1, 1)
>> +DECL_TYPE(i16vec2,  GL_INT16_VEC2_NV, GLSL_TYPE_INT16, 2, 1)
>> +DECL_TYPE(i16vec3,  GL_INT16_VEC3_NV, GLSL_TYPE_INT16, 3, 1)
>> +DECL_TYPE(i16vec4,  GL_INT16_VEC4_NV, GLSL_TYPE_INT16, 4, 1)
>> +
>> +DECL_TYPE(uint16_t, GL_UNSIGNED_INT16_NV,  GLSL_TYPE_UINT16, 1, 1)
>> +DECL_TYPE(u16vec2,  GL_UNSIGNED_INT16_VEC2_NV, GLSL_TYPE_UINT16, 2, 1)
>> +DECL_TYPE(u16vec3,  GL_UNSIGNED_INT16_VEC3_NV, GLSL_TYPE_UINT16, 3, 1)
>> +DECL_TYPE(u16vec4,  GL_UNSIGNED_INT16_VEC4_NV, GLSL_TYPE_UINT16, 4, 1)
>> +
>>  DECL_TYPE(sampler,   GL_SAMPLER_1D,   
>> GLSL_TYPE_SAMPLER, GLSL_SAMPLER_DIM_1D,   0, 0, GLSL_TYPE_VOID)
>>  DECL_TYPE(sampler1D, GL_SAMPLER_1D,   
>> GLSL_TYPE_SAMPLER, GLSL_SAMPLER_DIM_1D,   0, 0, GLSL_TYPE_FLOAT)
>>  DECL_TYPE(sampler2D, GL_SAMPLER_2D,  

Re: [Mesa-dev] [PATCH 0/3] Fix linkage for libEGL and libGLX without dri3

[Eric Engestrom]

On Friday, 2017-12-01 15:06:17 -0800, Dylan Baker wrote:
> As we discussed elsewhere, this should fix the linkage of the dri3 loader and
> glx and egl.
> 
> Dylan Baker (3):
>   meson: Reformat meson code to match more common style
>   meson: fix underlinkage without dri3
>   meson: Fix overlinkage of dri3 loader

Reviewed-by: Eric Engestrom 

> 
>  src/egl/meson.build|  2 +-
>  src/glx/meson.build| 14 +-
>  src/loader/meson.build |  3 +--
>  3 files changed, 11 insertions(+), 8 deletions(-)
> 
> -- 
> 2.15.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Install dri.pc file when building gallium dri drivers

[Eric Engestrom]

On Friday, 2017-12-01 14:03:16 -0800, Dylan Baker wrote:
> Currently this pkg-config file is only installed if a classic dri driver
> is built. This is wrong, it should be installed if any dri driver is
> installed, which includes the gallium dri target.
> 
> Reported-by: Marc Dietrich 
> Signed-off-by: Dylan Baker 

Reviewed-by: Eric Engestrom 

> ---
>  src/mesa/drivers/dri/meson.build | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/meson.build 
> b/src/mesa/drivers/dri/meson.build
> index 217f1e5c71c..4ec2f343df2 100644
> --- a/src/mesa/drivers/dri/meson.build
> +++ b/src/mesa/drivers/dri/meson.build
> @@ -53,6 +53,17 @@ if dri_drivers != []
>  link_args : ['-Wl,--build-id=sha1', ld_args_bsymbolic, 
> ld_args_gc_sections],
>)
>  
> +  meson.add_install_script(
> +join_paths(meson.source_root(), 'bin/install_megadrivers.py'),
> +libmesa_dri_drivers.full_path(),
> +dri_drivers_path,
> +dri_link,
> +  )
> +endif
> +
> +# This needs to be installed if any dri drivers (including gallium dri 
> drivers)
> +# are built.
> +if with_dri
>pkg.generate(
>  name : 'dri',
>  filebase : 'dri',
> @@ -61,11 +72,4 @@ if dri_drivers != []
>  variables : ['dridriverdir=${prefix}/' + dri_drivers_path],
>  requires_private : ['libdrm >= 2.4.75'],  # FIXME: don't hardcode this
>)
> -
> -  meson.add_install_script(
> -join_paths(meson.source_root(), 'bin/install_megadrivers.py'),
> -libmesa_dri_drivers.full_path(),
> -dri_drivers_path,
> -dri_link,
> -  )
>  endif
> -- 
> 2.15.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Android: disable warnings causing errors

[Eric Engestrom]

On Thursday, 2017-11-30 14:20:08 +, Emil Velikov wrote:
> On 29 November 2017 at 18:12, Rob Herring  wrote:
> > On Wed, Nov 29, 2017 at 11:01 AM, Emil Velikov  
> > wrote:
> >> On 27 November 2017 at 19:36, Rob Herring  wrote:
> >>> AOSP master has changed the build default to -Werror making all the
> >>> warnings errors. Override that with -Wno-error.
> >>>
> >> For both Mesa and libdrm patches
> >>
> >> Reviewed-by: Emil Velikov 
> >>
> >> Mildly related:
> >> Quick grep|sort|unique through your build log shows the following.
> >> Some quick ideas, I haven't looked which one comes from where.
> >
> > I have...
> >
> >>
> >>   4 -Wdeprecated-declarations]
> >>  60 -Wdeprecated-register]
> >
> > These are generated from bison, yacc or something. I'm not sure how to
> > fix. That's where I ran the other way.
> >
> Seems like the toolchain used is pretty ancient.
> 
> Flex:
> commit 8091dc907663673d9e0295c57fa446bdd38e9fab
> Author: Yuri 
> Date:   Thu Jul 17 14:07:30 2014 -0700
> 
>Removed deprecated 'register' storage class specifier.
> 
> 
> Bison:
> commit cb530ce9e2687c6b1e51b77a29a9062ad52166b4
> Author: Paul Eggert 
> Date:   Fri Jan 21 19:12:32 2005 +
> 
>(YYCOPY, yystpcpy, yyparse): Remove "register".
> 
> 
> >>   6 -Wenum-conversion]
> >>   3 -Wformat]
> >> Should be trivial.
> >>
> >>  14 -Wmissing-braces]
> >> I'm fairly convinced this comes from the universal initializer {0}
> >> Just silence it?
> >>
> >>  44 -Wdelete-non-virtual-dtor]
> >
> > I posted a patch a while back trying to fix this, but it actually
> > broke things at runtime.
> >
> I think Jonathan and Marc (both CC'd) have patches for OpenBSD [1] and
> VcXsrv [2], respectively.
> Perhaps one could start a separate thread and bounce off ideas/patches?
> 
> [1] 
> https://github.com/jonathangray/mesa/commit/c8f4c68261a0ddf9aaa5c9b9990d8b6e4e4d49a9
> [2] quick diff against between local checkouts
> https://paste.pound-python.org/show/O8UiZkQtiHMvR9SegVlV/
> 
> 
> >>   4 -Wshift-negative-value]
> >>  20 -Wsometimes-uninitialized]
> >>   4 -Wuninitialized]
> >> Potential bugs, or compiler snafu?
> >>
> >>  52 -Wasm-operand-widths]
> >>   4 -Wconstant-logical-operand]
> >>  16 -Wgnu-variable-sized-type-not-at-end]
> >>   2 -Wmacro-redefined]
> >>  56 -Woverloaded-virtual]
> >
> > Patch posted for these too.
> >
> >>  26 -Wtautological-constant-out-of-range-compare]
> >>   1 -Wuser-defined-warnings]
> >> Meh?
> >>
> >> Addressing the [clang] mismatched-tags and toggling the warning back
> >> on shouldn't be too bad?
> >
> > How many are clang/Android specific? It would be hopeless to re-enable
> > Werror if autotools/meson builds are not kept warning free. Maybe
> > those builds need to be stricter.
> >
> Having Werror will backfire IMHO. Although adding a few more toggles
> to the Linux builds won't be a bad idea.
> I was wondering if we can throw Wextra in the mix, but that will
> introduce way too many warnings.
> 
> Gert addresses a few of those already, and [IIRC] Eric was pondering
> about the -Wunused* in src/egl.

Indeed, but it turned out to be a much bigger task than anticipated;
I already have dozens of commits in a local branch (at home, where
I haven't been able to spend much time lately), and I'm nowhere near
finished, there are tons of unused variables/parameters all over the
place, and it trickles all the way up and down.

Don't expect me to send this series before Christmas :)

> Hope nobody will object to patches that cleanup/delete some code ;-)
> 
> -Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/14] meson: most of gallium

[Eric Engestrom]

On Thursday, 2017-11-30 10:34:06 -0800, Dylan Baker wrote:
> Quoting Eric Engestrom (2017-11-29 07:44:08)
> > On Tuesday, 2017-11-28 15:30:21 -0800, Dylan Baker wrote:
> > > This series is the gallium media state trackers, the "nine" Direct3D state
> > > tracker, and an architectural change in the way gallium drivers are 
> > > linked into
> > > the final targets.
> > > 
> > > This architectural change results in a good deal of code savings, as well 
> > > as
> > > ensuring that generated targets are generated before the targets that 
> > > depend on
> > > them are built. It makes use of meson's `declare_dependency` construct to 
> > > pass
> > > bundled arguments, and the result is somewhat similar to the way that 
> > > autotools
> > > uses the Automake.inc files.
> > > 
> > > The returning state trackers are the same as the v5 of the remaining
> > > drivers + media series, but now making use of the internal dependencies, 
> > > and are
> > > joined by the D3D "nine" state tracker.
> > > 
> > > Dylan Baker (14):
> > >   meson: Combine gallium target subdirs
> > >   meson: sort gallium drivers after winsys
> > >   meson: define driver dependencies
> > >   meson: use the driver dependencies for the gallium dri target
> > 
> > Nice cleanups! ^
> > I much prefer the code after your patches.
> > 
> > I had a quick look, and it all looks fine to me; series is:
> > Acked-by: Eric Engestrom 
> > 
> > (except the patches I actually reviewed, obviously :)
> 
> Any comments on v2? I'm ready to start landing this stuff and get on to less
> interesting work like macOS :)

Just looked through v2; I guess patch 12/15 (omx) will need changing;
not sure if you want to wait for the tizonia patches to land first, or
land 12/15 first and amend it when tizonia lands.
I'll leave that up to you.

I'm not completely sure about patches 5/15 and 6/15, but they look
reasonable:
Acked-by: Eric Engestrom 

Everything else in v2 is:
Reviewed-by: Eric Engestrom 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Android: gallium/radeon: fix libmesa_amd_common dependency

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Sat, Dec 2, 2017 at 1:36 PM, Mauro Rossi  wrote:
> libmesa_amd_common static dependency is added in Android build
> to avoid the following building errors:
>
> In file included from 
> external/mesa/src/gallium/drivers/radeon/r600_buffer_common.c:24:
> In file included from external/mesa/src/gallium/drivers/radeonsi/si_pipe.h:26:
> external/mesa/src/gallium/drivers/radeonsi/si_shader.h:138:10: fatal error: 
> 'ac_binary.h' file not found
>  ^
> 1 error generated.
> ...
> In file included from 
> external/mesa/src/gallium/drivers/radeon/r600_gpu_load.c:34:
> In file included from external/mesa/src/gallium/drivers/radeonsi/si_pipe.h:26:
> external/mesa/src/gallium/drivers/radeonsi/si_shader.h:138:10: fatal error: 
> 'ac_binary.h' file not found
>  ^
> 1 error generated.
>
> Fixes: 950221f923 ("radeonsi: remove r600_common_screen")
> ---
>  src/gallium/drivers/radeon/Android.mk | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/radeon/Android.mk 
> b/src/gallium/drivers/radeon/Android.mk
> index 578ab0be91..5efc2033f5 100644
> --- a/src/gallium/drivers/radeon/Android.mk
> +++ b/src/gallium/drivers/radeon/Android.mk
> @@ -30,6 +30,7 @@ include $(CLEAR_VARS)
>
>  LOCAL_SRC_FILES := $(C_SOURCES)
>
> +LOCAL_STATIC_LIBRARIES := libmesa_amd_common
>  LOCAL_SHARED_LIBRARIES := libdrm_radeon
>  LOCAL_MODULE := libmesa_pipe_radeon
>
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eric Engestrom]

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

Signed-off-by: Eric Engestrom 
---
 meson.build  | 4 
 src/gallium/meson.build  | 6 +++---
 src/gallium/winsys/pl111/drm/meson.build | 1 +
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/meson.build b/meson.build
index f227bc3e018dc39f9f79..f134ede15ce72dda7df6 100644
--- a/meson.build
+++ b/meson.build
@@ -158,6 +158,10 @@ if _drivers != ''
   with_gallium = true
 endif
 
+if with_gallium_pl111 and not with_gallium_vc4
+  error('Gallium pl111 depends on vc4')
+endif
+
 with_intel_vk = false
 with_amd_vk = false
 with_any_vk = false
diff --git a/src/gallium/meson.build b/src/gallium/meson.build
index 8e60c7f328856017fc35..563905478d4d4f6e9fb4 100644
--- a/src/gallium/meson.build
+++ b/src/gallium/meson.build
@@ -60,13 +60,13 @@ if with_gallium_freedreno
   subdir('drivers/freedreno')
   subdir('winsys/freedreno/drm')
 endif
-if with_gallium_pl111
-  subdir('winsys/pl111/drm')
-endif
 if with_gallium_vc4
   subdir('drivers/vc4')
   subdir('winsys/vc4/drm')
 endif
+if with_gallium_pl111
+  subdir('winsys/pl111/drm')
+endif
 if with_gallium_vc5
   subdir('drivers/vc5')
   subdir('winsys/vc5/drm')
diff --git a/src/gallium/winsys/pl111/drm/meson.build 
b/src/gallium/winsys/pl111/drm/meson.build
index 952c0b46700f5ddcf7e9..02b176a5c85ee67ff94a 100644
--- a/src/gallium/winsys/pl111/drm/meson.build
+++ b/src/gallium/winsys/pl111/drm/meson.build
@@ -27,4 +27,5 @@ libpl111winsys = static_library(
   ],
   c_args : [c_vis_args],
   dependencies: dep_libdrm,
+  link_with : libvc4winsys,
 )
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH mesa] i915: add missing 0 defines

[Eric Engestrom]

Thanks to Emil's -Wundef, t_dd_dmatmp.h now complains that intel_render.c
is missing a couple `#define`s.

Assigning them to 0 keeps the existing behaviour; I'll let someone else
turn them on if this is the behaviour that was intended.

Signed-off-by: Eric Engestrom 
---
 src/mesa/drivers/dri/i915/intel_render.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/drivers/dri/i915/intel_render.c 
b/src/mesa/drivers/dri/i915/intel_render.c
index c1603565cc2a6157c0bd..a3952826246a7e52aea6 100644
--- a/src/mesa/drivers/dri/i915/intel_render.c
+++ b/src/mesa/drivers/dri/i915/intel_render.c
@@ -62,6 +62,8 @@
 #define HAVE_TRI_FANS1
 #define HAVE_POLYGONS1
 
+#define HAVE_QUADS   0
+#define HAVE_QUAD_STRIPS 0
 #define HAVE_ELTS0
 
 static const uint32_t hw_prim[GL_POLYGON + 1] = {
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH v2] radv: fix a crash in radv_can_dump_shader()

[Samuel Pitoiset]

module can be NULL, oops.

v2: really check that module is not NULL

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

diff --git a/src/amd/vulkan/radv_shader.h b/src/amd/vulkan/radv_shader.h
index 91f2e7f2a1..f6486863f8 100644
--- a/src/amd/vulkan/radv_shader.h
+++ b/src/amd/vulkan/radv_shader.h
@@ -118,8 +118,8 @@ radv_can_dump_shader(struct radv_device *device,
 struct radv_shader_module *module)
 {
/* Only dump non-meta shaders, useful for debugging purposes. */
-   return !module->nir &&
-  device->instance->debug_flags & RADV_DEBUG_DUMP_SHADERS;
+   return device->instance->debug_flags & RADV_DEBUG_DUMP_SHADERS &&
+  module && !module->nir;
 }
 
 #endif
-- 
2.15.1

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

Re: [Mesa-dev] [PATCH] freedreno: add -Wno-packed-bitfield-compat for meson build

[Eric Engestrom]

On Monday, 2017-12-04 08:44:59 -0500, Rob Clark wrote:
> Otherwise huge amount of spam from instr-a2xx.h.. gcc has no way to know
> that freedreno was never built with such an old gcc version to care
> about the bugs in old gcc ;-)
> 
> Patch is really Eric Engestrom's, he showed me how to do this in meson.
> 
> Cc: Eric Engestrom 
> Signed-off-by: Rob Clark 

Not sure it makes much sense to r-b my own patch, but... ^^
Reviewed-by: Eric Engestrom 

> ---
>  src/gallium/drivers/freedreno/meson.build | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/freedreno/meson.build 
> b/src/gallium/drivers/freedreno/meson.build
> index 909e16b9ed8..444e6234f38 100644
> --- a/src/gallium/drivers/freedreno/meson.build
> +++ b/src/gallium/drivers/freedreno/meson.build
> @@ -201,12 +201,22 @@ freedreno_includes = [
>include_directories('ir3')
>  ]
>  
> +freedreno_c_args = []
> +if cc.has_argument('-Wpacked-bitfield-compat')
> +  freedreno_c_args += '-Wno-packed-bitfield-compat'
> +endif
> +
> +freedreno_cpp_args = []
> +if cpp.has_argument('-Wpacked-bitfield-compat')
> +  freedreno_cpp_args += '-Wno-packed-bitfield-compat'
> +endif
> +
>  libfreedreno = static_library(
>'freedreno',
>[files_libfreedreno, ir3_nir_trig_c, nir_opcodes_h],
>include_directories : freedreno_includes,
> -  c_args : [c_vis_args],
> -  cpp_args : [cpp_vis_args],
> +  c_args : [freedreno_c_args, c_vis_args],
> +  cpp_args : [freedreno_cpp_args, cpp_vis_args],
>dependencies : [dep_libdrm, dep_libdrm_freedreno],
>  )
>  
> -- 
> 2.13.6
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/7] gallium: Refactor out vl_put_screen and vl_get_screen

[Leo Liu]

On 12/03/2017 10:04 AM, Gurkirpal Singh wrote:

I sent the modified patches in another thread a while ago.
Please review in case got missed.

Please be patient for a few days to see if any other comments.
After then please rebase, add rb/ab to your patches, and send them to me,
I will commit them for you.

Leo




On Thu, Nov 30, 2017 at 7:35 PM, Leo Liu > wrote:




On 11/30/2017 06:22 AM, Julien Isorce wrote:

Hi Gurkirpal,

> Before refactoring process both the state trackers were in independent 
directories.
> During earlier refactoring effort we decided to keep that directory 
structure so it made
> sense to move them to auxiliary code. After that I moved them both under 
st/omx.
> Since there could be a chance of it being useful out of st/omx, I left 
the decision to
> keep it or move it back to st/omx to the mailing list.

Yes please move it back to st/omx for the reasons you said, i.e.
there will now 2
sub directories, st/omx/bellagio and st/omx/tizonia and common
code in st/omx.

Yes. Please move them back to st/omx.

With that fixed, the series are:

Acked-by: Leo Liu  

Thanks for the work!

Leo





Another reason is that the env var "OMX_RENDER_NODE" mentions OMX.

Thx!
Julien


On 29 November 2017 at 04:02, Gurkirpal Singh
> wrote:

---
 src/gallium/auxiliary/Makefile.sources            |   2 +
 src/gallium/auxiliary/vl/vl_screen.c            | 107
+
 src/gallium/auxiliary/vl/vl_screen.h            |  33 +++
 .../state_trackers/omx_bellagio/entrypoint.c      |  83

 .../state_trackers/omx_bellagio/entrypoint.h      |   3 -
 src/gallium/state_trackers/omx_bellagio/vid_dec.c |   5 +-
 src/gallium/state_trackers/omx_bellagio/vid_enc.c |   5 +-
 7 files changed, 148 insertions(+), 90 deletions(-)
 create mode 100644 src/gallium/auxiliary/vl/vl_screen.c
 create mode 100644 src/gallium/auxiliary/vl/vl_screen.h

diff --git a/src/gallium/auxiliary/Makefile.sources
b/src/gallium/auxiliary/Makefile.sources
index f40c472..35e89f9 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -343,6 +343,8 @@ VL_SOURCES := \
        vl/vl_mpeg12_decoder.c \
        vl/vl_mpeg12_decoder.h \
        vl/vl_rbsp.h \
+       vl/vl_screen.c \
+       vl/vl_screen.h \
        vl/vl_types.h \
        vl/vl_vertex_buffers.c \
        vl/vl_vertex_buffers.h \
diff --git a/src/gallium/auxiliary/vl/vl_screen.c
b/src/gallium/auxiliary/vl/vl_screen.c
new file mode 100644
index 000..7192802
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_screen.c
@@ -0,0 +1,107 @@

+/**
+ *
+ * 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, sub license, 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
NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+

**/
+
+#include 
+#include 
+#include 
+
+#include "os/os_thread.h"
+#include "util/u_memory.h"
+#include "loader/loader.h"
+#include "vl_screen.h"
+
+#if defined(HAVE_X11_PLATFORM)
+#include 
+#else
+#define XOpenDisplay(x) NULL
+#define 

Re: [Mesa-dev] [PATCH mesa 02/16] anv: tie anv_assert() enablement to regular assert()

[Emil Velikov]

On 27 November 2017 at 18:40, Eric Engestrom  wrote:
> On Sunday, 2017-11-26 10:12:46 +1100, Timothy Arceri wrote:
>> On 25/11/17 08:02, Timothy Arceri wrote:
>> > On 25/11/17 05:07, Eric Engestrom wrote:
>> > > Signed-off-by: Eric Engestrom 
>> > > ---
>> > >   src/intel/vulkan/anv_private.h | 2 +-
>> > >   1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/src/intel/vulkan/anv_private.h
>> > > b/src/intel/vulkan/anv_private.h
>> > > index 6d4e43f2e687cbf26ccd..6474abf0f3694c7fcd3a 100644
>> > > --- a/src/intel/vulkan/anv_private.h
>> > > +++ b/src/intel/vulkan/anv_private.h
>> > > @@ -382,7 +382,7 @@ void anv_debug_report(struct anv_instance *instance,
>> > >  } while (0)
>> > >   /* A non-fatal assert.  Useful for debugging. */
>> > > -#ifdef DEBUG
>> > > +#ifndef NDEBUG
>> >
>> > I'm confused by all these assert patches. Doesn't NDEBUG mean no debug
>> > or non-debug why are you switching things around? Won't this add all
>> > this code to release builds and remove it from debug builds?
>>
>> Oh you are using ifndef, I still don't get what you are trying to do with
>> these patches. Can you please explain?
>
> Like the title says, the point is to align the behaviour of our various
> custom asserts with the standard asserts.
> Having them behave differently (read: be enabled or disabled
> asynchronously) can only lead to confusion, and possibly breakages.
>
> (Try to compile a debug build with asserts off or a release build with
> asserts on without patch 12/16 "compiler: use NDEBUG to guard asserts",
> for instance. Although to be fair, that's the only actual breakage I've
> seen so far.)
>
> This confusion was caused by our autoconf script defining NDEBUG when
> DEBUG wasn't defined, which lead some people to believe these are
> interchangeable and/or always tied to each other, but this isn't true
> with other build systems, such as meson.
>
The whole thing predates autoconf by a number of years.

We have:
 - DEBUG - was aimed at extra processing/printfs
Stuff like MESA_DEBUG is guarded behind DEBUG - see mtypes.h,
draw_pipe.c or just grep -w DEBUG for more examples.
 - NDEBUG - asserts

With time we started using DEBUG more and more for asserts - something
that Eric is trying to address here.

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

Re: [Mesa-dev] [PATCH 16/29] anv/cmd_buffer: Pass a subpass id into begin_subpass

[Pohjolainen, Topi]

On Mon, Nov 27, 2017 at 07:06:06PM -0800, Jason Ekstrand wrote:
> This is a bit less awkward than passing in the subpass because it means
> we don't have to extract the subpass id from the subpass.
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 6f2fa0a..56036f7 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -3136,13 +3136,11 @@ cmd_buffer_subpass_sync_fast_clear_values(struct 
> anv_cmd_buffer *cmd_buffer)
> }
>  }
>  
> -
>  static void
>  cmd_buffer_begin_subpass(struct anv_cmd_buffer *cmd_buffer,
> - struct anv_subpass *subpass)
> + uint32_t subpass_id)
>  {
> -   cmd_buffer->state.subpass = subpass;
> -   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
> +   cmd_buffer->state.subpass = 
> _buffer->state.pass->subpasses[subpass_id];
>  
> cmd_buffer->state.dirty |= ANV_CMD_DIRTY_RENDER_TARGETS;
>  
> @@ -3222,7 +3220,7 @@ void genX(CmdBeginRenderPass)(
>  
> genX(flush_pipeline_select_3d)(cmd_buffer);
>  
> -   cmd_buffer_begin_subpass(cmd_buffer, pass->subpasses);
> +   cmd_buffer_begin_subpass(cmd_buffer, 0);
>  }
>  
>  void genX(CmdNextSubpass)(
> @@ -3236,9 +3234,9 @@ void genX(CmdNextSubpass)(
>  
> assert(cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_PRIMARY);
>  
> +   uint32_t prev_subpass = anv_get_subpass_id(_buffer->state);

Maybe call this "prev_subpass_id"? Either way:

Reviewed-by: Topi Pohjolainen 

> cmd_buffer_end_subpass(cmd_buffer);
> -
> -   cmd_buffer_begin_subpass(cmd_buffer, cmd_buffer->state.subpass + 1);
> +   cmd_buffer_begin_subpass(cmd_buffer, prev_subpass + 1);
>  }
>  
>  void genX(CmdEndRenderPass)(
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> 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 15/29] anv/cmd_buffer: Add begin/end_subpass helpers

[Pohjolainen, Topi]

On Mon, Nov 27, 2017 at 07:06:05PM -0800, Jason Ekstrand wrote:
> Having begin/end_subpass is a bit nicer than the begin/next/end hooks
> that Vulkan gives us.
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 55 
> +-
>  1 file changed, 31 insertions(+), 24 deletions(-)

Like said in the previous patch, unlike there, here things make sense as
pending bits are explicitly handled before and after transitions:

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index bbe97f5..6f2fa0a 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -3138,10 +3138,11 @@ cmd_buffer_subpass_sync_fast_clear_values(struct 
> anv_cmd_buffer *cmd_buffer)
>  
>  
>  static void
> -genX(cmd_buffer_set_subpass)(struct anv_cmd_buffer *cmd_buffer,
> - struct anv_subpass *subpass)
> +cmd_buffer_begin_subpass(struct anv_cmd_buffer *cmd_buffer,
> + struct anv_subpass *subpass)
>  {
> cmd_buffer->state.subpass = subpass;
> +   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
>  
> cmd_buffer->state.dirty |= ANV_CMD_DIRTY_RENDER_TARGETS;
>  
> @@ -3155,6 +3156,10 @@ genX(cmd_buffer_set_subpass)(struct anv_cmd_buffer 
> *cmd_buffer,
> if (GEN_GEN == 7)
>cmd_buffer->state.vb_dirty |= ~0;
>  
> +   /* Accumulate any subpass flushes that need to happen before the subpass 
> */
> +   cmd_buffer->state.pending_pipe_bits |=
> +  cmd_buffer->state.pass->subpass_flushes[subpass_id];
> +
> /* Perform transitions to the subpass layout before any writes have
>  * occurred.
>  */
> @@ -3174,6 +3179,26 @@ genX(cmd_buffer_set_subpass)(struct anv_cmd_buffer 
> *cmd_buffer,
> anv_cmd_buffer_clear_subpass(cmd_buffer);
>  }
>  
> +static void
> +cmd_buffer_end_subpass(struct anv_cmd_buffer *cmd_buffer)
> +{
> +   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
> +
> +   anv_cmd_buffer_resolve_subpass(cmd_buffer);
> +
> +   /* Perform transitions to the final layout after all writes have occurred.
> +*/
> +   cmd_buffer_subpass_transition_layouts(cmd_buffer, true);
> +
> +   /* Accumulate any subpass flushes that need to happen after the subpass.
> +* Yes, they do get accumulated twice in the NextSubpass case but since
> +* genX_CmdNextSubpass just calls end/begin back-to-back, we just end up
> +* ORing the bits in twice so it's harmless.
> +*/
> +   cmd_buffer->state.pending_pipe_bits |=
> +  cmd_buffer->state.pass->subpass_flushes[subpass_id + 1];
> +}
> +
>  void genX(CmdBeginRenderPass)(
>  VkCommandBuffer commandBuffer,
>  const VkRenderPassBeginInfo*pRenderPassBegin,
> @@ -3197,10 +3222,7 @@ void genX(CmdBeginRenderPass)(
>  
> genX(flush_pipeline_select_3d)(cmd_buffer);
>  
> -   cmd_buffer->state.pending_pipe_bits |=
> -  cmd_buffer->state.pass->subpass_flushes[0];
> -
> -   genX(cmd_buffer_set_subpass)(cmd_buffer, pass->subpasses);
> +   cmd_buffer_begin_subpass(cmd_buffer, pass->subpasses);
>  }
>  
>  void genX(CmdNextSubpass)(
> @@ -3214,17 +3236,9 @@ void genX(CmdNextSubpass)(
>  
> assert(cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_PRIMARY);
>  
> -   anv_cmd_buffer_resolve_subpass(cmd_buffer);
> -
> -   /* Perform transitions to the final layout after all writes have occurred.
> -*/
> -   cmd_buffer_subpass_transition_layouts(cmd_buffer, true);
> -
> -   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
> -   cmd_buffer->state.pending_pipe_bits |=
> -  cmd_buffer->state.pass->subpass_flushes[subpass_id];
> +   cmd_buffer_end_subpass(cmd_buffer);
>  
> -   genX(cmd_buffer_set_subpass)(cmd_buffer, cmd_buffer->state.subpass + 1);
> +   cmd_buffer_begin_subpass(cmd_buffer, cmd_buffer->state.subpass + 1);
>  }
>  
>  void genX(CmdEndRenderPass)(
> @@ -3235,14 +3249,7 @@ void genX(CmdEndRenderPass)(
> if (anv_batch_has_error(_buffer->batch))
>return;
>  
> -   anv_cmd_buffer_resolve_subpass(cmd_buffer);
> -
> -   /* Perform transitions to the final layout after all writes have occurred.
> -*/
> -   cmd_buffer_subpass_transition_layouts(cmd_buffer, true);
> -
> -   cmd_buffer->state.pending_pipe_bits |=
> -  
> cmd_buffer->state.pass->subpass_flushes[cmd_buffer->state.pass->subpass_count];
> +   cmd_buffer_end_subpass(cmd_buffer);
>  
> cmd_buffer->state.hiz_enabled = false;
>  
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] freedreno: add -Wno-packed-bitfield-compat for meson build

[Rob Clark]

Otherwise huge amount of spam from instr-a2xx.h.. gcc has no way to know
that freedreno was never built with such an old gcc version to care
about the bugs in old gcc ;-)

Patch is really Eric Engestrom's, he showed me how to do this in meson.

Cc: Eric Engestrom 
Signed-off-by: Rob Clark 
---
 src/gallium/drivers/freedreno/meson.build | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/freedreno/meson.build 
b/src/gallium/drivers/freedreno/meson.build
index 909e16b9ed8..444e6234f38 100644
--- a/src/gallium/drivers/freedreno/meson.build
+++ b/src/gallium/drivers/freedreno/meson.build
@@ -201,12 +201,22 @@ freedreno_includes = [
   include_directories('ir3')
 ]
 
+freedreno_c_args = []
+if cc.has_argument('-Wpacked-bitfield-compat')
+  freedreno_c_args += '-Wno-packed-bitfield-compat'
+endif
+
+freedreno_cpp_args = []
+if cpp.has_argument('-Wpacked-bitfield-compat')
+  freedreno_cpp_args += '-Wno-packed-bitfield-compat'
+endif
+
 libfreedreno = static_library(
   'freedreno',
   [files_libfreedreno, ir3_nir_trig_c, nir_opcodes_h],
   include_directories : freedreno_includes,
-  c_args : [c_vis_args],
-  cpp_args : [cpp_vis_args],
+  c_args : [freedreno_c_args, c_vis_args],
+  cpp_args : [freedreno_cpp_args, cpp_vis_args],
   dependencies : [dep_libdrm, dep_libdrm_freedreno],
 )
 
-- 
2.13.6

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

Re: [Mesa-dev] [PATCH 2/3] meson: Add lmsensors support

[Emil Velikov]

On 29 November 2017 at 00:56, Dylan Baker  wrote:
> Signed-off-by: Dylan Baker 
> ---
>  meson.build   | 11 +++
>  meson_options.txt |  7 +++
>  src/gallium/drivers/etnaviv/meson.build   |  2 +-
>  src/gallium/drivers/freedreno/meson.build |  1 +
>  src/gallium/drivers/nouveau/meson.build   |  2 +-
>  src/gallium/drivers/r300/meson.build  |  4 +++-
>  src/gallium/targets/dri/meson.build   |  2 +-
I'd stick with the autotools approach and add the link to the
gallium/aux module.
There are simply too many combinations where lmsensors can be utilised.

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

Re: [Mesa-dev] [PATCH 7/8] gallium/u_upload_mgr: allow drivers to specify pipe_resource::flags

[Nicolai Hähnle]

Patches 1 and 3-7:

Reviewed-by: Nicolai Hähnle 



On 01.12.2017 21:19, Marek Olšák wrote:

From: Marek Olšák 

---
  src/gallium/auxiliary/util/u_upload_mgr.c| 9 ++---
  src/gallium/auxiliary/util/u_upload_mgr.h| 2 +-
  src/gallium/drivers/freedreno/a3xx/fd3_context.c | 2 +-
  src/gallium/drivers/freedreno/a4xx/fd4_context.c | 2 +-
  src/gallium/drivers/freedreno/a5xx/fd5_context.c | 2 +-
  src/gallium/drivers/r300/r300_context.c  | 2 +-
  src/gallium/drivers/r600/r600_pipe_common.c  | 4 ++--
  src/gallium/drivers/radeon/r600_pipe_common.c| 4 ++--
  src/gallium/drivers/svga/svga_context.c  | 6 +++---
  src/gallium/drivers/svga/svga_resource_texture.c | 2 +-
  src/gallium/drivers/virgl/virgl_context.c| 2 +-
  11 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c 
b/src/gallium/auxiliary/util/u_upload_mgr.c
index 4bb14d6..e3b0fb3 100644
--- a/src/gallium/auxiliary/util/u_upload_mgr.c
+++ b/src/gallium/auxiliary/util/u_upload_mgr.c
@@ -37,43 +37,45 @@
  
  #include "u_upload_mgr.h"
  
  
  struct u_upload_mgr {

 struct pipe_context *pipe;
  
 unsigned default_size;  /* Minimum size of the upload buffer, in bytes. */

 unsigned bind;  /* Bitmask of PIPE_BIND_* flags. */
 enum pipe_resource_usage usage;
+   unsigned flags;
 unsigned map_flags; /* Bitmask of PIPE_TRANSFER_* flags. */
 boolean map_persistent; /* If persistent mappings are supported. */
  
 struct pipe_resource *buffer;   /* Upload buffer. */

 struct pipe_transfer *transfer; /* Transfer object for the upload buffer. 
*/
 uint8_t *map;/* Pointer to the mapped upload buffer. */
 unsigned offset; /* Aligned offset to the upload buffer, pointing
   * at the first unused byte. */
  };
  
  
  struct u_upload_mgr *

  u_upload_create(struct pipe_context *pipe, unsigned default_size,
-unsigned bind, enum pipe_resource_usage usage)
+unsigned bind, enum pipe_resource_usage usage, unsigned flags)
  {
 struct u_upload_mgr *upload = CALLOC_STRUCT(u_upload_mgr);
 if (!upload)
return NULL;
  
 upload->pipe = pipe;

 upload->default_size = default_size;
 upload->bind = bind;
 upload->usage = usage;
+   upload->flags = flags;
  
 upload->map_persistent =

pipe->screen->get_param(pipe->screen,
PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT);
  
 if (upload->map_persistent) {

upload->map_flags = PIPE_TRANSFER_WRITE |
PIPE_TRANSFER_UNSYNCHRONIZED |
PIPE_TRANSFER_PERSISTENT |
PIPE_TRANSFER_COHERENT;
@@ -87,28 +89,28 @@ u_upload_create(struct pipe_context *pipe, unsigned 
default_size,
 return upload;
  }
  
  struct u_upload_mgr *

  u_upload_create_default(struct pipe_context *pipe)
  {
 return u_upload_create(pipe, 1024 * 1024,
PIPE_BIND_VERTEX_BUFFER |
PIPE_BIND_INDEX_BUFFER |
PIPE_BIND_CONSTANT_BUFFER,
-  PIPE_USAGE_STREAM);
+  PIPE_USAGE_STREAM, 0);
  }
  
  struct u_upload_mgr *

  u_upload_clone(struct pipe_context *pipe, struct u_upload_mgr *upload)
  {
 return u_upload_create(pipe, upload->default_size, upload->bind,
-  upload->usage);
+  upload->usage, upload->flags);
  }
  
  static void

  upload_unmap_internal(struct u_upload_mgr *upload, boolean destroying)
  {
 if (!destroying && upload->map_persistent)
return;
  
 if (upload->transfer) {

struct pipe_box *box = >transfer->box;
@@ -162,20 +164,21 @@ u_upload_alloc_buffer(struct u_upload_mgr *upload, 
unsigned min_size)
  
 /* Allocate a new one:

  */
 size = align(MAX2(upload->default_size, min_size), 4096);
  
 memset(, 0, sizeof buffer);

 buffer.target = PIPE_BUFFER;
 buffer.format = PIPE_FORMAT_R8_UNORM; /* want TYPELESS or similar */
 buffer.bind = upload->bind;
 buffer.usage = upload->usage;
+   buffer.flags = upload->flags;
 buffer.width0 = size;
 buffer.height0 = 1;
 buffer.depth0 = 1;
 buffer.array_size = 1;
  
 if (upload->map_persistent) {

buffer.flags = PIPE_RESOURCE_FLAG_MAP_PERSISTENT |
   PIPE_RESOURCE_FLAG_MAP_COHERENT;
 }
  
diff --git a/src/gallium/auxiliary/util/u_upload_mgr.h b/src/gallium/auxiliary/util/u_upload_mgr.h

index 536467e..875fd9a 100644
--- a/src/gallium/auxiliary/util/u_upload_mgr.h
+++ b/src/gallium/auxiliary/util/u_upload_mgr.h
@@ -45,21 +45,21 @@ extern "C" {
  /**
   * Create the upload manager.
   *
   * \param pipe  Pipe driver.
   * \param default_size  Minimum size of the upload buffer, in bytes.
   * \param bind  Bitmask of 

Re: [Mesa-dev] [PATCH 2/8] radeonsi: allow DMABUF exports for local buffers

[Marek Olšák]

On Dec 4, 2017 12:58 PM, "Nicolai Hähnle"  wrote:

On 01.12.2017 21:19, Marek Olšák wrote:

> From: Marek Olšák 
>
> Cc: 17.3 
>

What's the use-case for this?


OpenCL interop.


What if somebody exports as DMABUF, then re-imports in a different API and
exports as FD for inter-process sharing from there?


DMABUF export is impossible for local BOs.

Marek




---
>   src/gallium/drivers/radeon/r600_texture.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_texture.c
> b/src/gallium/drivers/radeon/r600_texture.c
> index 2aa47b5..7a5d704 100644
> --- a/src/gallium/drivers/radeon/r600_texture.c
> +++ b/src/gallium/drivers/radeon/r600_texture.c
> @@ -740,21 +740,23 @@ static boolean r600_texture_get_handle(struct
> pipe_screen* screen,
>  rtex->surface.bpe;
> slice_size = rtex->surface.u.gfx9.surf_slice_size;
> } else {
> offset = rtex->surface.u.legacy.level[0].offset;
> stride = rtex->surface.u.legacy.level[0].nblk_x *
>  rtex->surface.bpe;
> slice_size = 
> (uint64_t)rtex->surface.u.legacy.level[0].slice_size_dw
> * 4;
> }
> } else {
> /* Move a suballocated buffer into a non-suballocated
> allocation. */
> -   if (sscreen->ws->buffer_is_suballocated(res->buf)) {
> +   if (sscreen->ws->buffer_is_suballocated(res->buf) ||
> +   (rtex->resource.flags & 
> RADEON_FLAG_NO_INTERPROCESS_SHARING
> &&
> +whandle->type != DRM_API_HANDLE_TYPE_KMS)) {
> assert(!res->b.is_shared);
> /* Allocate a new buffer with PIPE_BIND_SHARED. */
> struct pipe_resource templ = res->b.b;
> templ.bind |= PIPE_BIND_SHARED;
> struct pipe_resource *newb =
> screen->resource_create(screen, );
> if (!newb)
> return false;
>
>

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

Re: [Mesa-dev] [PATCH 8/8] radeonsi: make const and stream uploaders allocate read-only memory

[Nicolai Hähnle]

On 01.12.2017 21:19, Marek Olšák wrote:

From: Marek Olšák 

and anything that clones these uploaders, like u_threaded_context.


Bottom/top-of-pipe fences will have to be moved away from using the 
stream_uploader.




---
  src/gallium/drivers/radeon/r600_pipe_common.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index d85f9f0..23d8bf7 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -438,26 +438,28 @@ bool si_common_context_init(struct r600_common_context 
*rctx,
return false;
}
  
  	rctx->allocator_zeroed_memory =

u_suballocator_create(>b, sscreen->info.gart_page_size,
  0, PIPE_USAGE_DEFAULT, 0, true);
if (!rctx->allocator_zeroed_memory)
return false;
  
  	rctx->b.stream_uploader = u_upload_create(>b, 1024 * 1024,

- 0, PIPE_USAGE_STREAM, 0);
+ 0, PIPE_USAGE_STREAM,
+ R600_RESOURCE_FLAG_READ_ONLY);
if (!rctx->b.stream_uploader)
return false;
  
  	rctx->b.const_uploader = u_upload_create(>b, 128 * 1024,

-0, PIPE_USAGE_DEFAULT, 0);
+0, PIPE_USAGE_DEFAULT,
+R600_RESOURCE_FLAG_READ_ONLY);
if (!rctx->b.const_uploader)
return false;
  
  	rctx->ctx = rctx->ws->ctx_create(rctx->ws);

if (!rctx->ctx)
return false;
  
  	if (sscreen->info.num_sdma_rings && !(sscreen->debug_flags & DBG(NO_ASYNC_DMA))) {

rctx->dma.cs = rctx->ws->cs_create(rctx->ctx, RING_DMA,
   r600_flush_dma_ring,




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

Re: [Mesa-dev] [PATCH 2/8] radeonsi: allow DMABUF exports for local buffers

[Nicolai Hähnle]

On 01.12.2017 21:19, Marek Olšák wrote:

From: Marek Olšák 

Cc: 17.3 


What's the use-case for this?

What if somebody exports as DMABUF, then re-imports in a different API 
and exports as FD for inter-process sharing from there?




---
  src/gallium/drivers/radeon/r600_texture.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index 2aa47b5..7a5d704 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -740,21 +740,23 @@ static boolean r600_texture_get_handle(struct 
pipe_screen* screen,
 rtex->surface.bpe;
slice_size = rtex->surface.u.gfx9.surf_slice_size;
} else {
offset = rtex->surface.u.legacy.level[0].offset;
stride = rtex->surface.u.legacy.level[0].nblk_x *
 rtex->surface.bpe;
slice_size = 
(uint64_t)rtex->surface.u.legacy.level[0].slice_size_dw * 4;
}
} else {
/* Move a suballocated buffer into a non-suballocated 
allocation. */
-   if (sscreen->ws->buffer_is_suballocated(res->buf)) {
+   if (sscreen->ws->buffer_is_suballocated(res->buf) ||
+   (rtex->resource.flags & RADEON_FLAG_NO_INTERPROCESS_SHARING 
&&
+whandle->type != DRM_API_HANDLE_TYPE_KMS)) {
assert(!res->b.is_shared);
  
  			/* Allocate a new buffer with PIPE_BIND_SHARED. */

struct pipe_resource templ = res->b.b;
templ.bind |= PIPE_BIND_SHARED;
  
  			struct pipe_resource *newb =

screen->resource_create(screen, );
if (!newb)
return false;




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

Re: [Mesa-dev] [PATCH] radeonsi: pass llvm type directly to buffer_load()

[Nicolai Hähnle]

Reviewed-by: Nicolai Hähnle  



On 04.12.2017 05:17, Timothy Arceri wrote:

---
  src/gallium/drivers/radeonsi/si_shader.c | 15 +++
  1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index a94c2af8709..6a1293b99d1 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1034,53 +1034,51 @@ static LLVMValueRef get_tcs_tes_buffer_address_from_reg(
  
  	param_index = LLVMBuildAdd(ctx->ac.builder, param_index,

   LLVMConstInt(ctx->i32, param_index_base, 0),
   "");
  
  	return get_tcs_tes_buffer_address(ctx, get_rel_patch_id(ctx),

  vertex_index, param_index);
  }
  
  static LLVMValueRef buffer_load(struct lp_build_tgsi_context *bld_base,

-enum tgsi_opcode_type type, unsigned swizzle,
+LLVMTypeRef type, unsigned swizzle,
  LLVMValueRef buffer, LLVMValueRef offset,
  LLVMValueRef base, bool can_speculate)
  {
struct si_shader_context *ctx = si_shader_context(bld_base);
LLVMValueRef value, value2;
-   LLVMTypeRef llvm_type = tgsi2llvmtype(bld_base, type);
-   LLVMTypeRef vec_type = LLVMVectorType(llvm_type, 4);
+   LLVMTypeRef vec_type = LLVMVectorType(type, 4);
  
  	if (swizzle == ~0) {

value = ac_build_buffer_load(>ac, buffer, 4, NULL, base, 
offset,
 0, 1, 0, can_speculate, false);
  
  		return LLVMBuildBitCast(ctx->ac.builder, value, vec_type, "");

}
  
-	if (!tgsi_type_is_64bit(type)) {

+   if (!llvm_type_is_64bit(ctx, type)) {
value = ac_build_buffer_load(>ac, buffer, 4, NULL, base, 
offset,
 0, 1, 0, can_speculate, false);
  
  		value = LLVMBuildBitCast(ctx->ac.builder, value, vec_type, "");

return LLVMBuildExtractElement(ctx->ac.builder, value,
LLVMConstInt(ctx->i32, swizzle, 0), "");
}
  
  	value = ac_build_buffer_load(>ac, buffer, 1, NULL, base, offset,

  swizzle * 4, 1, 0, can_speculate, false);
  
  	value2 = ac_build_buffer_load(>ac, buffer, 1, NULL, base, offset,

   swizzle * 4 + 4, 1, 0, can_speculate, false);
  
-	return si_llvm_emit_fetch_64bit(bld_base, tgsi2llvmtype(bld_base, type),

-   value, value2);
+   return si_llvm_emit_fetch_64bit(bld_base, type, value, value2);
  }
  
  /**

   * Load from LDS.
   *
   * \param typeoutput value type
   * \param swizzle offset (typically 0..3); it can be ~0, which loads a 
vec4
   * \param dw_addr address in dwords
   */
  static LLVMValueRef lds_load(struct lp_build_tgsi_context *bld_base,
@@ -1199,21 +1197,22 @@ static LLVMValueRef fetch_input_tes(
enum tgsi_opcode_type type, unsigned swizzle)
  {
struct si_shader_context *ctx = si_shader_context(bld_base);
LLVMValueRef buffer, base, addr;
  
  	buffer = desc_from_addr_base64k(ctx, ctx->param_tcs_offchip_addr_base64k);
  
  	base = LLVMGetParam(ctx->main_fn, ctx->param_tcs_offchip_offset);

addr = get_tcs_tes_buffer_address_from_reg(ctx, NULL, reg);
  
-	return buffer_load(bld_base, type, swizzle, buffer, base, addr, true);

+   return buffer_load(bld_base, tgsi2llvmtype(bld_base, type), swizzle,
+  buffer, base, addr, true);
  }
  
  static void store_output_tcs(struct lp_build_tgsi_context *bld_base,

 const struct tgsi_full_instruction *inst,
 const struct tgsi_opcode_info *info,
 unsigned index,
 LLVMValueRef dst[4])
  {
struct si_shader_context *ctx = si_shader_context(bld_base);
const struct tgsi_full_dst_register *reg = >Dst[index];
@@ -1781,21 +1780,21 @@ void si_load_system_value(struct si_shader_context *ctx,
{
LLVMValueRef buffer, base, addr;
int param = 
si_shader_io_get_unique_index_patch(decl->Semantic.Name, 0);
  
  		buffer = desc_from_addr_base64k(ctx, ctx->param_tcs_offchip_addr_base64k);
  
  		base = LLVMGetParam(ctx->main_fn, ctx->param_tcs_offchip_offset);

addr = get_tcs_tes_buffer_address(ctx, get_rel_patch_id(ctx), 
NULL,
  LLVMConstInt(ctx->i32, param, 0));
  
-		value = buffer_load(>bld_base, TGSI_TYPE_FLOAT,

+   value = buffer_load(>bld_base, ctx->f32,
~0, buffer, base, addr, true);
  
  		break;

}
  
  	case TGSI_SEMANTIC_DEFAULT_TESSOUTER_SI:

case