Re: [Mesa-dev] [Mesa-stable] [PATCH v3 2/3] i965/fs: detect different bit size accesses to uniforms to push them in proper locations

[Samuel Iglesias Gonsálvez]

On 27/02/17 22:02, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez  writes:
> 
>> Previously, if we had accesses with different sizes to the same uniform, we 
>> might not
>> push it aligned with the bigger one. This is a problem in BSW/BXT when we 
>> access
>> an array of DF uniform with both direct and indirect addressing because for 
>> the latter
>> we use 32-bit MOV INDIRECT instructions. However this problem can happen 
>> with other
>> generations and bitsizes.
>>
>> Signed-off-by: Samuel Iglesias Gonsálvez 
>> Cc: "17.0" 
>> ---
>>  src/mesa/drivers/dri/i965/brw_fs.cpp | 50 
>> 
>>  1 file changed, 34 insertions(+), 16 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
>> b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> index c713caa9b6..68e73cc5cd 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> @@ -1853,7 +1853,10 @@ fs_visitor::compact_virtual_grfs()
>>  }
>>  
>>  static void
>> -set_push_pull_constant_loc(unsigned uniform, int *chunk_start, bool 
>> contiguous,
>> +set_push_pull_constant_loc(unsigned uniform, int *chunk_start,
>> +   unsigned *max_chunk_bitsize,
>> +   bool contiguous, unsigned bitsize,
>> +   const unsigned target_bitsize,
>> int *push_constant_loc, int *pull_constant_loc,
>> unsigned *num_push_constants,
>> unsigned *num_pull_constants,
> 
> I still feel like this function is growing over the top trying to
> achieve multiple unrelated things in one place, but if you just want to
> shuffle things around as little as possible for mesa-stable, fine:
> 

Yes, that was my intention.

> Reviewed-by: Francisco Jerez 
> 

Thanks!

Sam

>> @@ -1865,11 +1868,23 @@ set_push_pull_constant_loc(unsigned uniform, int 
>> *chunk_start, bool contiguous,
>> if (*chunk_start < 0)
>>*chunk_start = uniform;
>>  
>> +   /* Keep track of the maximum bit size access in contiguous uniforms */
>> +   *max_chunk_bitsize = MAX2(*max_chunk_bitsize, bitsize);
>> +
>> /* If this element does not need to be contiguous with the next, we
>>  * split at this point and everything between chunk_start and u forms a
>>  * single chunk.
>>  */
>> if (!contiguous) {
>> +  /* If bitsize doesn't match the target one, skip it */
>> +  if (*max_chunk_bitsize != target_bitsize) {
>> + /* FIXME: right now we only support 32 and 64-bit accesses */
>> + assert(*max_chunk_bitsize == 4 || *max_chunk_bitsize == 8);
>> + *max_chunk_bitsize = 0;
>> + *chunk_start = -1;
>> + return;
>> +  }
>> +
>>unsigned chunk_size = uniform - *chunk_start + 1;
>>  
>>/* Decide whether we should push or pull this parameter.  In the
>> @@ -1887,6 +1902,7 @@ set_push_pull_constant_loc(unsigned uniform, int 
>> *chunk_start, bool contiguous,
>>  pull_constant_loc[j] = (*num_pull_constants)++;
>>}
>>  
>> +  *max_chunk_bitsize = 0;
>>*chunk_start = -1;
>> }
>>  }
>> @@ -1909,8 +1925,8 @@ fs_visitor::assign_constant_locations()
>>  
>> bool is_live[uniforms];
>> memset(is_live, 0, sizeof(is_live));
>> -   bool is_live_64bit[uniforms];
>> -   memset(is_live_64bit, 0, sizeof(is_live_64bit));
>> +   unsigned bitsize_access[uniforms];
>> +   memset(bitsize_access, 0, sizeof(bitsize_access));
>>  
>> /* For each uniform slot, a value of true indicates that the given slot 
>> and
>>  * the next slot must remain contiguous.  This is used to keep us from
>> @@ -1947,23 +1963,18 @@ fs_visitor::assign_constant_locations()
>>  for (unsigned j = constant_nr; j < last; j++) {
>> is_live[j] = true;
>> contiguous[j] = true;
>> -   if (type_sz(inst->src[i].type) == 8) {
>> -  is_live_64bit[j] = true;
>> -   }
>> +   bitsize_access[j] = MAX2(bitsize_access[j], 
>> type_sz(inst->src[i].type));
>>  }
>>  is_live[last] = true;
>> -if (type_sz(inst->src[i].type) == 8) {
>> -  is_live_64bit[last] = true;
>> -}
>> +bitsize_access[last] = MAX2(bitsize_access[last], 
>> type_sz(inst->src[i].type));
>>   } else {
>>  if (constant_nr >= 0 && constant_nr < (int) uniforms) {
>> int regs_read = inst->components_read(i) *
>>type_sz(inst->src[i].type) / 4;
>> for (int j = 0; j < regs_read; j++) {
>>is_live[constant_nr + j] = true;
>> -  if (type_sz(inst->src[i].type) == 8) {
>> - is_live_64bit[constant_nr + j] = true;
>> -  }
>> +  

Re: [Mesa-dev] [PATCH 3/4] radeonsi: add support for an on-disk shader cache

[Axel Davy]

My understanding of the code is that the disk cache just depends on the
sscreen->b.disk_shader_cache being initialized, and it looks like this 
is always

initialized.
Thus the disk cache is always enabled.

Could you add a RADEON_DEBUG env var to disable it, please ?

Thanks,

Axel Davy

On 01/03/2017 06:25, Timothy Arceri wrote:

V2:
- when loading from disk cache also binary insert into memory cache.
- check that the binary loaded from disk is the correct size. If not
   delete the cache item and skip loading from cache.

V3:
- remove unrequired variable

Tested-by: Michel Dänzer 
---
  src/gallium/drivers/radeonsi/si_state_shaders.c | 67 ++---
  1 file changed, 60 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 750cdd6..a82e38e 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -29,20 +29,23 @@
  #include "sid.h"
  #include "radeon/r600_cs.h"
  
  #include "tgsi/tgsi_parse.h"

  #include "tgsi/tgsi_ureg.h"
  #include "util/hash_table.h"
  #include "util/crc32.h"
  #include "util/u_memory.h"
  #include "util/u_prim.h"
  
+#include "util/disk_cache.h"

+#include "util/mesa-sha1.h"
+
  /* SHADER_CACHE */
  
  /**

   * Return the TGSI binary in a buffer. The first 4 bytes contain its size as
   * integer.
   */
  static void *si_get_tgsi_binary(struct si_shader_selector *sel)
  {
unsigned tgsi_size = tgsi_num_tokens(sel->tokens) *
 sizeof(struct tgsi_token);
@@ -175,54 +178,104 @@ static bool si_load_shader_binary(struct si_shader 
*shader, void *binary)
  }
  
  /**

   * Insert a shader into the cache. It's assumed the shader is not in the 
cache.
   * Use si_shader_cache_load_shader before calling this.
   *
   * Returns false on failure, in which case the tgsi_binary should be freed.
   */
  static bool si_shader_cache_insert_shader(struct si_screen *sscreen,
  void *tgsi_binary,
- struct si_shader *shader)
+ struct si_shader *shader,
+ bool insert_into_disk_cache)
  {
void *hw_binary;
struct hash_entry *entry;
+   uint8_t key[CACHE_KEY_SIZE];
  
  	entry = _mesa_hash_table_search(sscreen->shader_cache, tgsi_binary);

if (entry)
return false; /* already added */
  
  	hw_binary = si_get_shader_binary(shader);

if (!hw_binary)
return false;
  
  	if (_mesa_hash_table_insert(sscreen->shader_cache, tgsi_binary,

hw_binary) == NULL) {
FREE(hw_binary);
return false;
}
  
+	if (sscreen->b.disk_shader_cache && insert_into_disk_cache) {

+   _mesa_sha1_compute(tgsi_binary, *((uint32_t *)tgsi_binary), 
key);
+   disk_cache_put(sscreen->b.disk_shader_cache, key, hw_binary,
+  *((uint32_t *) hw_binary));
+   }
+
return true;
  }
  
  static bool si_shader_cache_load_shader(struct si_screen *sscreen,

void *tgsi_binary,
struct si_shader *shader)
  {
struct hash_entry *entry =
_mesa_hash_table_search(sscreen->shader_cache, tgsi_binary);
-   if (!entry)
-   return false;
+   if (!entry) {
+   if (sscreen->b.disk_shader_cache) {
+   unsigned char sha1[CACHE_KEY_SIZE];
+   size_t tg_size = *((uint32_t *) tgsi_binary);
+
+   _mesa_sha1_compute(tgsi_binary, tg_size, sha1);
+
+   size_t binary_size;
+   uint8_t *buffer =
+   disk_cache_get(sscreen->b.disk_shader_cache,
+  sha1, _size);
+   if (!buffer)
+   return false;
  
-	if (!si_load_shader_binary(shader, entry->data))

-   return false;
+   if (binary_size < sizeof(uint32_t) ||
+   *((uint32_t*)buffer) != binary_size) {
+/* Something has gone wrong discard the item
+ * from the cache and rebuild/link from
+ * source.
+ */
+   assert(!"Invalid radeonsi shader disk cache "
+  "item!");
+
+   disk_cache_remove(sscreen->b.disk_shader_cache,
+ sha1);
+   free(buffer);
+
+   return false;
+   }
+
+   if 

Re: [Mesa-dev] [PATCH 2/2] anv: do not subtract the base layer to copute depth in 3DSTATE_DEPTH_BUFFER

[Iago Toral]

On Fri, 2017-02-24 at 07:25 -0800, Jason Ekstrand wrote:
> On Feb 23, 2017 11:40 PM, "Iago Toral Quiroga" 
> wrote:
> According to the PRM description of the Depth field:
> 
>   "This field specifies the total number of levels for a volume
> texture
>    or the number of array elements allowed to be accessed starting at
> the
>    Minimum Array Element for arrayed surfaces"
> 
> However, ISL defines array_len as the length of the range
> [base_array_layer, base_array_layer + array_len], so it already
> represents
> a value relative to the base array layer like the hardware expects.
> 
> This fixes a number of new CTS tests that would crash otherwise:
> dEQP-VK.pipeline.render_to_image.*
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 40a72f4..3c7b544 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -2269,8 +2269,7 @@ cmd_buffer_emit_depth_stencil(struct
> anv_cmd_buffer *cmd_buffer)
> 
>           assert(image->depth_surface.isl.dim != ISL_SURF_DIM_3D);
>           db.Depth =
> -         db.RenderTargetViewExtent =
> -            iview->isl.array_len - iview->isl.base_array_layer - 1;
> +         db.RenderTargetViewExtent = iview->isl.array_len;
> 
> Don't we still want the -1?

The PRM says this about the Depth field:

"This field specifies (...) the number of array elements allowed to be
accessed starting at the Minimum Array Element for arrayed surfaces"

And in anv_get_layerCount, we compute this value as:

range->layerCount == VK_REMAINING_ARRAY_LAYERS ?
   image->array_size - range->baseArrayLayer : range->layerCount;

Since we want the number of elements including Minimum Array Element, I
think we don't want the subtraction.

Iago

>  #if GEN_GEN >= 8
>           db.SurfaceQPitch =
> --
> 2.7.4
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/24] i965: Move some helpers from brw_context.h to brw_shader.h

[Matt Turner]

On Tue, Feb 28, 2017 at 9:03 PM, Jason Ekstrand  wrote:
> ---
>  src/mesa/drivers/dri/i965/brw_compiler.c |  1 +
>  src/mesa/drivers/dri/i965/brw_context.h  | 16 
>  src/mesa/drivers/dri/i965/brw_shader.h   | 18 ++
>  3 files changed, 19 insertions(+), 16 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_compiler.c 
> b/src/mesa/drivers/dri/i965/brw_compiler.c
> index f3dafec..18ca444 100644
> --- a/src/mesa/drivers/dri/i965/brw_compiler.c
> +++ b/src/mesa/drivers/dri/i965/brw_compiler.c
> @@ -23,6 +23,7 @@
>
>  #include "brw_compiler.h"
>  #include "brw_context.h"
> +#include "brw_shader.h"
>  #include "compiler/nir/nir.h"
>  #include "main/errors.h"
>  #include "util/debug.h"
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index c9a931c..eda5c32 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1330,12 +1330,6 @@ key_debug(struct brw_context *brw, const char *name, 
> int a, int b)
>
>  void brwInitFragProgFuncs( struct dd_function_table *functions );
>
> -/* Per-thread scratch space is a power-of-two multiple of 1KB. */
> -static inline int
> -brw_get_scratch_size(int size)
> -{
> -   return MAX2(1024, util_next_power_of_two(size));
> -}
>  void brw_get_scratch_bo(struct brw_context *brw,
> drm_intel_bo **scratch_bo, int size);
>  void brw_alloc_stage_scratch(struct brw_context *brw,
> @@ -1358,13 +1352,6 @@ void brw_upload_urb_fence(struct brw_context *brw);
>   */
>  void brw_upload_cs_urb_state(struct brw_context *brw);
>
> -/* brw_fs_reg_allocate.cpp
> - */
> -void brw_fs_alloc_reg_sets(struct brw_compiler *compiler);
> -
> -/* brw_vec4_reg_allocate.cpp */
> -void brw_vec4_alloc_reg_set(struct brw_compiler *compiler);
> -
>  /* brw_disasm.c */
>  int brw_disassemble_inst(FILE *file, const struct gen_device_info *devinfo,
>   struct brw_inst *inst, bool is_compacted);
> @@ -1628,9 +1615,6 @@ brw_program_reloc(struct brw_context *brw, uint32_t 
> state_offset,
>
>  bool brw_do_cubemap_normalize(struct exec_list *instructions);
>
> -extern const char * const conditional_modifier[16];
> -extern const char *const pred_ctrl_align16[16];
> -
>  static inline bool
>  brw_depth_writes_enabled(const struct brw_context *brw)
>  {
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.h 
> b/src/mesa/drivers/dri/i965/brw_shader.h
> index 60f498f..8cda6b2 100644
> --- a/src/mesa/drivers/dri/i965/brw_shader.h
> +++ b/src/mesa/drivers/dri/i965/brw_shader.h
> @@ -258,6 +258,24 @@ bool opt_predicated_break(struct backend_shader *s);
>  extern "C" {
>  #endif
>
> +/* brw_fs_reg_allocate.cpp
> + */

Let's make this a single-line comment while we're moving it.

> +void brw_fs_alloc_reg_sets(struct brw_compiler *compiler);
> +
> +/* brw_vec4_reg_allocate.cpp */
> +void brw_vec4_alloc_reg_set(struct brw_compiler *compiler);
> +
> +/* brw_disasm.c */
> +extern const char * const conditional_modifier[16];

And let's remove the space after the * while we're here as well.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Vulkan: Add VK_ANDROID_native_buffer to device extension list

[Xu, Randy]

>> We have a dependency on gralloc in the EGL layer so that is why I don't see 
>> it as a problem for Vulkan WSI.

It’s true. In Android O dessert (not released yet), all HALs except for OpeGL 
and Vulcan need to be wrapped by HIDL and binderized now. While I guess Google 
wants to avoid this kind of usage and tries to solve it.



From: Palli, Tapani
Sent: Wednesday, March 1, 2017 1:33 PM
To: Xu, Randy ; Jason Ekstrand 
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Vulkan: Add VK_ANDROID_native_buffer to device 
extension list

On 03/01/2017 07:21 AM, Xu, Randy wrote:
Hi, Tapani

According to https://source.android.com/devices/graphics/implement-vulkan.html
"Window System Integration (WSI) extensions are exported by the loader and 
primarily implemented in it rather than the driver.". Also, Google provides the 
stubhal.c in frameworks/native/vulkan/libvulkan, the VK_ANDROID_native_buffer 
functions are implemented there as a sample.
The reason I guess is that VK_ANDROID_native_buffer implementation needs to 
access Gralloc HAL data structure, but mesa driver should have no dependency to 
Android HAL, which is required by HAL Binderization.


We have a dependency on gralloc in the EGL layer so that is why I don't see it 
as a problem for Vulkan WSI.

I'm OK with having it in HAL but maybe we should still spend some time to 
figure out a way to expose extension from there (inject string to extensions 
list in a way or another). Loader wraps extension list and exposes different 
one to applications than it has from driver, maybe should take some look there 
how it does all this.



This patch doesn’t expose VK_ANDROID_native_buffer extension in driver (as the 
function is not implemented here), but avoid screening it when create device.

Thanks,
Randy

From: Palli, Tapani
Sent: Wednesday, March 1, 2017 1:03 PM
To: Jason Ekstrand ; Xu, 
Randy 
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Vulkan: Add VK_ANDROID_native_buffer to device 
extension list

On 03/01/2017 06:17 AM, Jason Ekstrand wrote:
On Tue, Feb 28, 2017 at 7:52 PM, Randy Xu 
> wrote:
The VK_ANDROID_native_buffer is implemented in Android Vulkan HAL,
not driver, but must be claimed in device extension list. Otherwise,
this extension will be screened off in framework and driver.

This seems rather odd.  Can't the Vulkan HAL just hook into 
vkEnumerateDeviceExtensionProperties and add it to the list there?  It seems a 
bit odd to advertise an extension but not actually provide any of the 
functionality.

This was my question as well. I proposed Randy to include functionality, at the 
moment it would be along these lines:

https://github.com/android-ia/external-mesa/commit/8b6b2fc4de933c03feba33e5b57c20262e7983cc

I don't have a strong preference where functionality exists but it seems like 
ideally the whole thing would exist in one single component. If the extension 
list cannot be modified in HAL then this becomes harder to achieve in HAL.



Test: Pass Vulkan dEQP-VK.wsi.android.swapchain.* on Android platform

Signed-off-by: Randy Xu >
---
 Android.common.mk | 3 +++
 src/intel/vulkan/anv_device.c | 9 +
 2 files changed, 12 insertions(+)

diff --git a/Android.common.mk 
b/Android.common.mk
index 611162a..f49189b 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -116,6 +116,9 @@ else
   LOCAL_CFLAGS += 
-DDEFAULT_DRIVER_DIR=\"/system/lib/$(MESA_DRI_MODULE_REL_PATH)\"
 endif

+# Enable VK_ANDROID_native_buffer
+LOCAL_CFLAGS += -DVK_USE_PLATFORM_ANDROID_KHR
+
 # uncomment to keep the debug symbols
 #LOCAL_STRIP_MODULE := false

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 0db96f2..478d753 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -258,6 +258,15 @@ static const VkExtensionProperties device_extensions[] = {
   .extensionName = VK_KHR_MAINTENANCE1_EXTENSION_NAME,
   .specVersion = 1,
},
+#ifdef VK_USE_PLATFORM_ANDROID_KHR
+   {
+  // Refer 
https://source.android.com/devices/graphics/implement-vulkan.html
+  // "Window System Integration (WSI) extensions are exported by the loader
+  //  and primarily implemented in it rather than the driver."
+  .extensionName = "VK_ANDROID_native_buffer",

In the other places, we use the EXTENSION_NAME #define

+  .specVersion = 1,
+   },
+#endif
{
   .extensionName = VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME,
   .specVersion = 1,
--
2.7.4

___
mesa-dev mailing list

Re: [Mesa-dev] [PATCH 00/24] i965: Move the compiler to src/intel/compiler

[Jason Ekstrand]

For those of you who like branches:

https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/move-compiler

On Tue, Feb 28, 2017 at 9:03 PM, Jason Ekstrand 
wrote:

> This little series moves the i965 back-end compiler to src/intel/compiler.
> It's not incredibly pretty; I didn't do as much header clean-up as perhaps
> could have been done.  Anything that I didn't know what to do with I moved
> to brw_shader or brw_program.  The second-to-last patch which shuffles the
> header includes around is also one big patch.  It could be split up but
> there didn't seem to be much of a point.
>
> Jason Ekstrand (24):
>   i965: Move a couple of #defines from brw_context to brw_compiler
>   i965: Move some helpers from brw_context.h to brw_shader.h
>   i965: Move brw_disassemble_inst to brw_eu.h
>   i965: Move some gen4 WM defines to brw_compiler.h
>   i965: Move assign_common_binding_table_offsets to brw_program
>   i965/vue_map: Stop using GLbitfield types
>   i965: Get rid of BRW_PRIM_OFFSET
>   i965: Don't use MAX_SURFACES in mark_surface_used
>   i965/gs: Add the gl_prim_to_hw_prim table to vec4_gs_visitor.cpp
>   i964/gs: Move MAX_GS_INPUT_VERTICES to brw_vec4_gs_visitor.h
>   i965: Move SOL binding #defines to brw_compiler.h
>   i965: Move SHADER_TIME_STRIDE to brw_compiler.h
>   i965: Move brw_register_blocks to brw_fs.cpp
>   i965/inst: Stop using fi_type
>   i965: Move BRW_MAX_DRAW_BUFFERS to brw_compiler.h
>   i965: Move BRW_ATTRIB_WA_* defines to brw_compiler.h
>   i965: Make mark_surface_used a static inline in brw_compiler.h
>   i965: Move channel_expressions and vector_splitting to brw_program.h
>   i965: Move image uniform setup to brw_nir_uniforms.cpp
>   i965: Move a bunch of pre-compile and link stuff to brw_program.h
>   i965: Add a header for brw_vec4_vs_visitor
>   i965: Delete brw_do_cubemap_normalize
>   i965: Reduce cross-pollination between the DRI driver and compiler
>   i965: Move the back-end compiler to src/intel/compiler
>
>  src/intel/Makefile.am  |   2 +
>  src/intel/Makefile.compiler.am | 116 
>  src/intel/Makefile.sources |  89 
>  src/intel/blorp/blorp_priv.h   |   2 +-
>  src/intel/compiler/.gitignore  |   1 +
>  .../dri/i965 => intel/compiler}/brw_cfg.cpp|   0
>  .../drivers/dri/i965 => intel/compiler}/brw_cfg.h  |   0
>  .../dri/i965 => intel/compiler}/brw_compiler.c |   3 +-
>  .../dri/i965 => intel/compiler}/brw_compiler.h | 116 +++-
>  .../compiler}/brw_dead_control_flow.cpp|   0
>  .../compiler}/brw_dead_control_flow.h  |   0
>  .../dri/i965 => intel/compiler}/brw_disasm.c   |   3 +-
>  .../drivers/dri/i965 => intel/compiler}/brw_eu.c   |   3 +-
>  .../drivers/dri/i965 => intel/compiler}/brw_eu.h   |   2 +
>  .../dri/i965 => intel/compiler}/brw_eu_compact.c   |   3 +-
>  .../dri/i965 => intel/compiler}/brw_eu_emit.c  |   1 -
>  .../dri/i965 => intel/compiler}/brw_eu_util.c  |   1 -
>  .../dri/i965 => intel/compiler}/brw_eu_validate.c  |   0
>  .../drivers/dri/i965 => intel/compiler}/brw_fs.cpp |  15 +-
>  .../drivers/dri/i965 => intel/compiler}/brw_fs.h   |   3 -
>  .../dri/i965 => intel/compiler}/brw_fs_builder.h   |   1 -
>  .../compiler}/brw_fs_cmod_propagation.cpp  |   0
>  .../compiler}/brw_fs_combine_constants.cpp |   0
>  .../compiler}/brw_fs_copy_propagation.cpp  |   0
>  .../dri/i965 => intel/compiler}/brw_fs_cse.cpp |   0
>  .../compiler}/brw_fs_dead_code_eliminate.cpp   |   0
>  .../i965 => intel/compiler}/brw_fs_generator.cpp   |   0
>  .../compiler}/brw_fs_live_variables.cpp|   0
>  .../compiler}/brw_fs_live_variables.h  |   0
>  .../i965 => intel/compiler}/brw_fs_lower_d2x.cpp   |   0
>  .../i965 => intel/compiler}/brw_fs_lower_pack.cpp  |   0
>  .../dri/i965 => intel/compiler}/brw_fs_nir.cpp |   0
>  .../compiler}/brw_fs_reg_allocate.cpp  |   0
>  .../compiler}/brw_fs_register_coalesce.cpp |   0
>  .../compiler}/brw_fs_saturate_propagation.cpp  |   0
>  .../compiler}/brw_fs_sel_peephole.cpp  |   0
>  .../compiler}/brw_fs_surface_builder.cpp   |   0
>  .../compiler}/brw_fs_surface_builder.h |   1 -
>  .../i965 => intel/compiler}/brw_fs_validate.cpp|   0
>  .../dri/i965 => intel/compiler}/brw_fs_visitor.cpp |   0
>  .../drivers/dri/i965 => intel/compiler}/brw_inst.h |  13 +-
>  .../compiler}/brw_interpolation_map.c  |   1 -
>  .../dri/i965 => intel/compiler}/brw_ir_allocator.h |   0
>  .../dri/i965 => intel/compiler}/brw_ir_fs.h|   0
>  .../dri/i965 => intel/compiler}/brw_ir_vec4.h  |   1 -
>  .../drivers/dri/i965 => intel/compiler}/brw_nir.c  |   1 +
>  .../drivers/dri/i965 => intel/compiler}/brw_nir.h  |   0
>  .../compiler}/brw_nir_analyze_boolean_resolves.c   |   0
>  

Re: [Mesa-dev] [PATCH] Vulkan: Add VK_ANDROID_native_buffer to device extension list

[Tapani Pälli]

On 03/01/2017 07:21 AM, Xu, Randy wrote:


Hi, Tapani

According to 
https://source.android.com/devices/graphics/implement-vulkan.html
"Window System Integration (WSI) extensions are exported by the loader 
and primarily implemented in it rather than the driver.". Also, Google 
provides the stubhal.c in frameworks/native/vulkan/libvulkan, the 
VK_ANDROID_native_buffer functions are implemented there as a sample.


The reason I guess is that VK_ANDROID_native_buffer implementation 
needs to access Gralloc HAL data structure, but mesa driver should 
have no dependency to Android HAL, which is required by HAL Binderization.




We have a dependency on gralloc in the EGL layer so that is why I don't 
see it as a problem for Vulkan WSI.


I'm OK with having it in HAL but maybe we should still spend some time 
to figure out a way to expose extension from there (inject string to 
extensions list in a way or another). Loader wraps extension list and 
exposes different one to applications than it has from driver, maybe 
should take some look there how it does all this.



This patch doesn’t expose VK_ANDROID_native_buffer extension in driver 
(as the function is not implemented here), but avoid screening it when 
create device.


Thanks,

Randy

*From:*Palli, Tapani
*Sent:* Wednesday, March 1, 2017 1:03 PM
*To:* Jason Ekstrand ; Xu, Randy 


*Cc:* mesa-dev@lists.freedesktop.org
*Subject:* Re: [Mesa-dev] [PATCH] Vulkan: Add VK_ANDROID_native_buffer 
to device extension list


On 03/01/2017 06:17 AM, Jason Ekstrand wrote:

On Tue, Feb 28, 2017 at 7:52 PM, Randy Xu > wrote:

The VK_ANDROID_native_buffer is implemented in Android Vulkan HAL,
not driver, but must be claimed in device extension list.
Otherwise,
this extension will be screened off in framework and driver.

This seems rather odd.  Can't the Vulkan HAL just hook into
vkEnumerateDeviceExtensionProperties and add it to the list
there?  It seems a bit odd to advertise an extension but not
actually provide any of the functionality.


This was my question as well. I proposed Randy to include 
functionality, at the moment it would be along these lines:


https://github.com/android-ia/external-mesa/commit/8b6b2fc4de933c03feba33e5b57c20262e7983cc

I don't have a strong preference where functionality exists but it 
seems like ideally the whole thing would exist in one single 
component. If the extension list cannot be modified in HAL then this 
becomes harder to achieve in HAL.



Test: Pass Vulkan dEQP-VK.wsi.android.swapchain.* on Android
platform

Signed-off-by: Randy Xu >
---
Android.common.mk | 3 +++
 src/intel/vulkan/anv_device.c | 9 +
 2 files changed, 12 insertions(+)

diff --git a/Android.common.mk 
b/Android.common.mk 
index 611162a..f49189b 100644
--- a/Android.common.mk 
+++ b/Android.common.mk 
@@ -116,6 +116,9 @@ else
   LOCAL_CFLAGS +=
-DDEFAULT_DRIVER_DIR=\"/system/lib/$(MESA_DRI_MODULE_REL_PATH)\"
 endif

+# Enable VK_ANDROID_native_buffer
+LOCAL_CFLAGS += -DVK_USE_PLATFORM_ANDROID_KHR
+
 # uncomment to keep the debug symbols
 #LOCAL_STRIP_MODULE := false

diff --git a/src/intel/vulkan/anv_device.c
b/src/intel/vulkan/anv_device.c
index 0db96f2..478d753 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -258,6 +258,15 @@ static const VkExtensionProperties
device_extensions[] = {
   .extensionName = VK_KHR_MAINTENANCE1_EXTENSION_NAME,
   .specVersion = 1,
},
+#ifdef VK_USE_PLATFORM_ANDROID_KHR
+   {
+  // Refer
https://source.android.com/devices/graphics/implement-vulkan.html
+  // "Window System Integration (WSI) extensions are
exported by the loader
+  //  and primarily implemented in it rather than the
driver."
+  .extensionName = "VK_ANDROID_native_buffer",

In the other places, we use the EXTENSION_NAME #define

+  .specVersion = 1,
+   },
+#endif
{
   .extensionName =
VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME,
   .specVersion = 1,
--
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

https://lists.freedesktop.org/mailman/listinfo/mesa-dev




___

Re: [Mesa-dev] [PATCH] Vulkan: Add VK_ANDROID_native_buffer to device extension list

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 9:21 PM, Xu, Randy  wrote:

> Hi, Tapani
>
>
>
> According to https://source.android.com/devices/graphics/implement-
> vulkan.html
> "Window System Integration (WSI) extensions are exported by the loader and
> primarily implemented in it rather than the driver.". Also, Google provides
> the stubhal.c in frameworks/native/vulkan/libvulkan, the
> VK_ANDROID_native_buffer functions are implemented there as a sample.
>
> The reason I guess is that VK_ANDROID_native_buffer implementation needs
> to access Gralloc HAL data structure, but mesa driver should have no
> dependency to Android HAL, which is required by HAL Binderization.
>

I don't know enough of the details of how gralloc works on IA.  I would
have assumed that the fd is just a prime buffer which should be easy enough
for us to handle.  That said, if it's more complicated and requires bits
that don't have a stable API somewhere, maybe it's best left out-of-tree.
I have no real opinion there.


> This patch doesn’t expose VK_ANDROID_native_buffer extension in driver (as
> the function is not implemented here), but avoid screening it when create
> device.
>

Actually, it does.  It will cause the driver to advertise the extension
even if it isn't loaded through the HAL.


> Thanks,
>
> Randy
>
>
>
> *From:* Palli, Tapani
> *Sent:* Wednesday, March 1, 2017 1:03 PM
> *To:* Jason Ekstrand ; Xu, Randy  >
> *Cc:* mesa-dev@lists.freedesktop.org
> *Subject:* Re: [Mesa-dev] [PATCH] Vulkan: Add VK_ANDROID_native_buffer to
> device extension list
>
>
>
> On 03/01/2017 06:17 AM, Jason Ekstrand wrote:
>
> On Tue, Feb 28, 2017 at 7:52 PM, Randy Xu  wrote:
>
> The VK_ANDROID_native_buffer is implemented in Android Vulkan HAL,
> not driver, but must be claimed in device extension list. Otherwise,
> this extension will be screened off in framework and driver.
>
>
>
> This seems rather odd.  Can't the Vulkan HAL just hook into
> vkEnumerateDeviceExtensionProperties and add it to the list there?  It
> seems a bit odd to advertise an extension but not actually provide any of
> the functionality.
>
>
> This was my question as well. I proposed Randy to include functionality,
> at the moment it would be along these lines:
>
> https://github.com/android-ia/external-mesa/commit/
> 8b6b2fc4de933c03feba33e5b57c20262e7983cc
>
> I don't have a strong preference where functionality exists but it seems
> like ideally the whole thing would exist in one single component. If the
> extension list cannot be modified in HAL then this becomes harder to
> achieve in HAL.
>

I don't see anything non-trivial in that commit.  Am I missing the part
where we actually import the ANativeImage?

In any case, if the interactions with gralloc aren't too bad, I'm
reasonably happy to have support in the upstream mesa repo.  Someone other
than me will have to be responsible for keeping it building but that's no
different from the current state of things.

> Test: Pass Vulkan dEQP-VK.wsi.android.swapchain.* on Android platform
>
> Signed-off-by: Randy Xu 
> ---
>  Android.common.mk | 3 +++
>  src/intel/vulkan/anv_device.c | 9 +
>  2 files changed, 12 insertions(+)
>
> diff --git a/Android.common.mk b/Android.common.mk
> index 611162a..f49189b 100644
> --- a/Android.common.mk
> +++ b/Android.common.mk
> @@ -116,6 +116,9 @@ else
>LOCAL_CFLAGS += -DDEFAULT_DRIVER_DIR=\"/system/lib/$(MESA_DRI_MODULE_
> REL_PATH)\"
>  endif
>
> +# Enable VK_ANDROID_native_buffer
> +LOCAL_CFLAGS += -DVK_USE_PLATFORM_ANDROID_KHR
> +
>  # uncomment to keep the debug symbols
>  #LOCAL_STRIP_MODULE := false
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 0db96f2..478d753 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -258,6 +258,15 @@ static const VkExtensionProperties
> device_extensions[] = {
>.extensionName = VK_KHR_MAINTENANCE1_EXTENSION_NAME,
>.specVersion = 1,
> },
> +#ifdef VK_USE_PLATFORM_ANDROID_KHR
> +   {
> +  // Refer https://source.android.com/devices/graphics/implement-
> vulkan.html
> +  // "Window System Integration (WSI) extensions are exported by the
> loader
> +  //  and primarily implemented in it rather than the driver."
> +  .extensionName = "VK_ANDROID_native_buffer",
>
>
>
> In the other places, we use the EXTENSION_NAME #define
>
>
>
> +  .specVersion = 1,
> +   },
> +#endif
> {
>.extensionName = VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME,
>.specVersion = 1,
> --
> 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] V2 Enable radeonsi disk cache

[Timothy Arceri]

Patches 1 & 2 are new improvements to the disk cache util.

Patches 3 & 4 are unchanged.

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

[Mesa-dev] [PATCH 4/4] Revert "glsl: Switch to disable-by-default for the GLSL shader cache"

[Timothy Arceri]

This reverts commit 0f60c6616e93cba72bff4fbfedb72a753ef78e05.

Piglit and all games tested so far seem to be working without
issue. This change will allow wide user testing and we can decided
before the next release if we need to turn it off again.

Reviewed-by: Marek Olšák 
Tested-by: Michel Dänzer 
---
 src/compiler/glsl/tests/cache_test.c | 5 -
 src/util/disk_cache.c| 7 ---
 2 files changed, 12 deletions(-)

diff --git a/src/compiler/glsl/tests/cache_test.c 
b/src/compiler/glsl/tests/cache_test.c
index c4e6e36..de92e5a 100644
--- a/src/compiler/glsl/tests/cache_test.c
+++ b/src/compiler/glsl/tests/cache_test.c
@@ -421,25 +421,20 @@ test_put_key_and_get_key(void)
disk_cache_destroy(cache);
 }
 #endif /* ENABLE_SHADER_CACHE */
 
 int
 main(void)
 {
 #ifdef ENABLE_SHADER_CACHE
int err;
 
-   /* While the shader cache is still experimental, this variable must
-* be set or the cache does nothing.
-*/
-   setenv("MESA_GLSL_CACHE_ENABLE", "1", 1);
-
test_disk_cache_create();
 
test_put_and_get();
 
test_put_key_and_get_key();
 
err = rmrf_local(CACHE_TEST_TMP);
expect_equal(err, 0, "Removing " CACHE_TEST_TMP " again");
 #endif /* ENABLE_SHADER_CACHE */
 
diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 03aae02..ecd5df3 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -208,27 +208,20 @@ disk_cache_create(const char *gpu_name, const char 
*timestamp)
 
/* A ralloc context for transient data during this invocation. */
local = ralloc_context(NULL);
if (local == NULL)
   goto fail;
 
/* At user request, disable shader cache entirely. */
if (getenv("MESA_GLSL_CACHE_DISABLE"))
   goto fail;
 
-   /* As a temporary measure, (while the shader cache is under
-* development, and known to not be fully functional), also require
-* the MESA_GLSL_CACHE_ENABLE variable to be set.
-*/
-   if (!getenv("MESA_GLSL_CACHE_ENABLE"))
-  goto fail;
-
/* Determine path for cache based on the first defined name as follows:
 *
 *   $MESA_GLSL_CACHE_DIR
 *   $XDG_CACHE_HOME/mesa
 *   /.cache/mesa
 */
path = getenv("MESA_GLSL_CACHE_DIR");
if (path) {
   if (mkdir_if_needed(path) == -1)
  goto fail;
-- 
2.9.3

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

[Mesa-dev] [PATCH 2/4] util/disk_cache: compress individual cache entries

[Timothy Arceri]

This reduces the cache size for Deus Ex from ~160M to ~30M for
radeonsi.

I'm also seeing the following improvements in minimum fps in the
Shadow of Mordor benchmark:

no-cache:~10fps
with-cache-no-compression:   ~15fps
with-cache-and-compression:  ~20fps

Note the with cache results are from the second run after closing
and opening the game to avoid the in-memory cache.

Since we only really care about decompression I went with
Z_BEST_COMPRESSION as suggested on irc by Steinar H. Gunderson
who has benchmarked decompression speeds.
---
 configure.ac  |   4 ++
 src/util/Makefile.am  |   2 +
 src/util/disk_cache.c | 173 +++---
 3 files changed, 156 insertions(+), 23 deletions(-)

diff --git a/configure.ac b/configure.ac
index 890a379..9fde95f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -92,20 +92,21 @@ LIBVA_REQUIRED=0.38.0
 VDPAU_REQUIRED=1.1
 WAYLAND_REQUIRED=1.11
 XCB_REQUIRED=1.9.3
 XCBDRI2_REQUIRED=1.8
 XCBGLX_REQUIRED=1.8.1
 XDAMAGE_REQUIRED=1.1
 XSHMFENCE_REQUIRED=1.1
 XVMC_REQUIRED=1.0.6
 PYTHON_MAKO_REQUIRED=0.8.0
 LIBSENSORS_REQUIRED=4.0.0
+ZLIB_REQUIRED=1.2.8
 
 dnl LLVM versions
 LLVM_REQUIRED_GALLIUM=3.3.0
 LLVM_REQUIRED_OPENCL=3.6.0
 LLVM_REQUIRED_R600=3.6.0
 LLVM_REQUIRED_RADEONSI=3.6.0
 LLVM_REQUIRED_RADV=3.9.0
 LLVM_REQUIRED_SWR=3.6.0
 
 dnl Check for progs
@@ -777,20 +778,23 @@ darwin*)
 AC_CHECK_FUNCS([clock_gettime], [CLOCK_LIB=],
[AC_CHECK_LIB([rt], [clock_gettime], [CLOCK_LIB=-lrt],
  [AC_MSG_ERROR([Could not find 
clock_gettime])])])
 AC_SUBST([CLOCK_LIB])
 ;;
 esac
 
 dnl See if posix_memalign is available
 AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
 
+dnl Check for zlib
+PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
+
 dnl Check for pthreads
 AX_PTHREAD
 if test "x$ax_pthread_ok" = xno; then
 AC_MSG_ERROR([Building mesa on this platform requires pthreads])
 fi
 dnl AX_PTHREADS leaves PTHREAD_LIBS empty for gcc and sets PTHREAD_CFLAGS
 dnl to -pthread, which causes problems if we need -lpthread to appear in
 dnl pkgconfig files.  Since Android doesn't have a pthread lib, this check
 dnl is not valid for that platform.
 if test "x$android" = xno; then
diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index ae50a3b..e46d893 100644
--- a/src/util/Makefile.am
+++ b/src/util/Makefile.am
@@ -36,20 +36,22 @@ libmesautil_la_CPPFLAGS = \
-I$(top_srcdir)/src/mesa \
-I$(top_srcdir)/src/gallium/include \
-I$(top_srcdir)/src/gallium/auxiliary \
$(VISIBILITY_CFLAGS) \
$(MSVC2013_COMPAT_CFLAGS)
 
 libmesautil_la_SOURCES = \
$(MESA_UTIL_FILES) \
$(MESA_UTIL_GENERATED_FILES)
 
+libmesautil_la_LIBADD = -lz
+
 roundeven_test_LDADD = -lm
 
 check_PROGRAMS = u_atomic_test roundeven_test
 TESTS = $(check_PROGRAMS)
 
 BUILT_SOURCES = $(MESA_UTIL_GENERATED_FILES)
 CLEANFILES = $(BUILT_SOURCES)
 EXTRA_DIST = \
format_srgb.py \
SConscript \
diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 2a0edca..03aae02 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -30,20 +30,21 @@
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include "zlib.h"
 
 #include "util/crc32.h"
 #include "util/u_atomic.h"
 #include "util/mesa-sha1.h"
 #include "util/ralloc.h"
 #include "main/errors.h"
 
 #include "disk_cache.h"
 
 /* Number of bits to mask off from a cache key to get an index. */
@@ -638,30 +639,106 @@ disk_cache_remove(struct disk_cache *cache, cache_key 
key)
   return;
}
 
unlink(filename);
free(filename);
 
if (sb.st_size)
   p_atomic_add(cache->size, - sb.st_size);
 }
 
+/* From the zlib docs:
+ *"If the memory is available, buffers sizes on the order of 128K or 256K
+ *bytes should be used."
+ */
+#define BUFSIZE 256 * 1024
+
+/**
+ * Compresses cache entry in memeory and writes it to disk. Returns the size
+ * of the data written to disk.
+ */
+static size_t
+deflate_and_write_to_disk(const void *in_data, size_t in_data_size, int dest,
+  char *filename)
+{
+   unsigned char out[BUFSIZE];
+
+   /* allocate deflate state */
+   z_stream strm;
+   strm.zalloc = Z_NULL;
+   strm.zfree = Z_NULL;
+   strm.opaque = Z_NULL;
+   strm.next_in = (uint8_t *) in_data;
+   strm.avail_in = in_data_size;
+
+   int ret = deflateInit(, Z_BEST_COMPRESSION);
+   if (ret != Z_OK)
+   return 0;
+
+   /* compress until end of in_data */
+   size_t compressed_size = 0;
+   int flush;
+   do {
+  int remaining = in_data_size - BUFSIZE;
+  flush = remaining > 0 ? Z_NO_FLUSH : Z_FINISH;
+  in_data_size -= BUFSIZE;
+
+  /* Run deflate() on input until the output buffer is not full (which
+   * means there is no more data to deflate).
+   */
+  do {
+ strm.avail_out = BUFSIZE;
+ strm.next_out 

[Mesa-dev] [PATCH 1/4] util/disk_cache: add support for detecting corrupt cache entries

[Timothy Arceri]

---
 src/util/disk_cache.c | 37 ++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index f5e1145..2a0edca 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -31,20 +31,21 @@
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
+#include "util/crc32.h"
 #include "util/u_atomic.h"
 #include "util/mesa-sha1.h"
 #include "util/ralloc.h"
 #include "main/errors.h"
 
 #include "disk_cache.h"
 
 /* Number of bits to mask off from a cache key to get an index. */
 #define CACHE_INDEX_KEY_BITS 16
 
@@ -702,34 +703,48 @@ disk_cache_put(struct disk_cache *cache,
/* OK, we're now on the hook to write out a file that we know is
 * not in the cache, and is also not being written out to the cache
 * by some other process.
 *
 * Before we do that, if the cache is too large, evict something
 * else first.
 */
if (*cache->size + size > cache->max_size)
   evict_random_item(cache);
 
+   /* Create CRC of the data and store at the start of the file. We will
+* read this when restoring the cache and use it to check for corruption.
+*/
+   uint32_t crc32 = util_hash_crc32(data, size);
+   size_t crc_size = sizeof(crc32);
+   for (len = 0; len < crc_size; len += ret) {
+  ret = write(fd, , crc_size - len);
+  if (ret == -1) {
+ unlink(filename_tmp);
+ goto done;
+  }
+   }
+
/* Now, finally, write out the contents to the temporary file, then
 * rename them atomically to the destination filename, and also
 * perform an atomic increment of the total cache size.
 */
for (len = 0; len < size; len += ret) {
   ret = write(fd, p + len, size - len);
   if (ret == -1) {
  unlink(filename_tmp);
  goto done;
   }
}
 
rename(filename_tmp, filename);
 
+   size += crc_size;
p_atomic_add(cache->size, size);
 
  done:
if (fd_final != -1)
   close(fd_final);
/* This close finally releases the flock, (now that the final dile
 * has been renamed into place and the size has been added).
 */
if (fd != -1)
   close(fd);
@@ -758,31 +773,47 @@ disk_cache_get(struct disk_cache *cache, cache_key key, 
size_t *size)
if (fd == -1)
   goto fail;
 
if (fstat(fd, ) == -1)
   goto fail;
 
data = malloc(sb.st_size);
if (data == NULL)
   goto fail;
 
-   for (len = 0; len < sb.st_size; len += ret) {
-  ret = read(fd, data + len, sb.st_size - len);
+   /* Load the CRC that was created when the file was written. */
+   uint32_t crc32;
+   size_t crc_size = sizeof(crc32);
+   assert(sb.st_size > crc_size);
+   for (len = 0; len < crc_size; len += ret) {
+  ret = read(fd,  + len, crc_size - len);
   if (ret == -1)
  goto fail;
}
 
+   /* Load the actual cache data. */
+   size_t cache_data_size = sb.st_size - crc_size;
+   for (len = 0; len < cache_data_size; len += ret) {
+  ret = read(fd, data + len, cache_data_size - len);
+  if (ret == -1)
+ goto fail;
+   }
+
+   /* Check the data for corruption */
+   if (crc32 != util_hash_crc32(data, cache_data_size))
+  goto fail;
+
free(filename);
close(fd);
 
if (size)
-  *size = sb.st_size;
+  *size = cache_data_size;
 
return data;
 
  fail:
if (data)
   free(data);
if (filename)
   free(filename);
if (fd != -1)
   close(fd);
-- 
2.9.3

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

[Mesa-dev] [PATCH 3/4] radeonsi: add support for an on-disk shader cache

[Timothy Arceri]

V2:
- when loading from disk cache also binary insert into memory cache.
- check that the binary loaded from disk is the correct size. If not
  delete the cache item and skip loading from cache.

V3:
- remove unrequired variable

Tested-by: Michel Dänzer 
---
 src/gallium/drivers/radeonsi/si_state_shaders.c | 67 ++---
 1 file changed, 60 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 750cdd6..a82e38e 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -29,20 +29,23 @@
 #include "sid.h"
 #include "radeon/r600_cs.h"
 
 #include "tgsi/tgsi_parse.h"
 #include "tgsi/tgsi_ureg.h"
 #include "util/hash_table.h"
 #include "util/crc32.h"
 #include "util/u_memory.h"
 #include "util/u_prim.h"
 
+#include "util/disk_cache.h"
+#include "util/mesa-sha1.h"
+
 /* SHADER_CACHE */
 
 /**
  * Return the TGSI binary in a buffer. The first 4 bytes contain its size as
  * integer.
  */
 static void *si_get_tgsi_binary(struct si_shader_selector *sel)
 {
unsigned tgsi_size = tgsi_num_tokens(sel->tokens) *
 sizeof(struct tgsi_token);
@@ -175,54 +178,104 @@ static bool si_load_shader_binary(struct si_shader 
*shader, void *binary)
 }
 
 /**
  * Insert a shader into the cache. It's assumed the shader is not in the cache.
  * Use si_shader_cache_load_shader before calling this.
  *
  * Returns false on failure, in which case the tgsi_binary should be freed.
  */
 static bool si_shader_cache_insert_shader(struct si_screen *sscreen,
  void *tgsi_binary,
- struct si_shader *shader)
+ struct si_shader *shader,
+ bool insert_into_disk_cache)
 {
void *hw_binary;
struct hash_entry *entry;
+   uint8_t key[CACHE_KEY_SIZE];
 
entry = _mesa_hash_table_search(sscreen->shader_cache, tgsi_binary);
if (entry)
return false; /* already added */
 
hw_binary = si_get_shader_binary(shader);
if (!hw_binary)
return false;
 
if (_mesa_hash_table_insert(sscreen->shader_cache, tgsi_binary,
hw_binary) == NULL) {
FREE(hw_binary);
return false;
}
 
+   if (sscreen->b.disk_shader_cache && insert_into_disk_cache) {
+   _mesa_sha1_compute(tgsi_binary, *((uint32_t *)tgsi_binary), 
key);
+   disk_cache_put(sscreen->b.disk_shader_cache, key, hw_binary,
+  *((uint32_t *) hw_binary));
+   }
+
return true;
 }
 
 static bool si_shader_cache_load_shader(struct si_screen *sscreen,
void *tgsi_binary,
struct si_shader *shader)
 {
struct hash_entry *entry =
_mesa_hash_table_search(sscreen->shader_cache, tgsi_binary);
-   if (!entry)
-   return false;
+   if (!entry) {
+   if (sscreen->b.disk_shader_cache) {
+   unsigned char sha1[CACHE_KEY_SIZE];
+   size_t tg_size = *((uint32_t *) tgsi_binary);
+
+   _mesa_sha1_compute(tgsi_binary, tg_size, sha1);
+
+   size_t binary_size;
+   uint8_t *buffer =
+   disk_cache_get(sscreen->b.disk_shader_cache,
+  sha1, _size);
+   if (!buffer)
+   return false;
 
-   if (!si_load_shader_binary(shader, entry->data))
-   return false;
+   if (binary_size < sizeof(uint32_t) ||
+   *((uint32_t*)buffer) != binary_size) {
+/* Something has gone wrong discard the item
+ * from the cache and rebuild/link from
+ * source.
+ */
+   assert(!"Invalid radeonsi shader disk cache "
+  "item!");
+
+   disk_cache_remove(sscreen->b.disk_shader_cache,
+ sha1);
+   free(buffer);
+
+   return false;
+   }
+
+   if (!si_load_shader_binary(shader, buffer)) {
+   free(buffer);
+   return false;
+   }
+   free(buffer);
 
+   if (!si_shader_cache_insert_shader(sscreen, tgsi_binary,
+  shader, false))
+  

Re: [Mesa-dev] [PATCH] Vulkan: Add VK_ANDROID_native_buffer to device extension list

[Xu, Randy]

Hi, Tapani

According to https://source.android.com/devices/graphics/implement-vulkan.html
"Window System Integration (WSI) extensions are exported by the loader and 
primarily implemented in it rather than the driver.". Also, Google provides the 
stubhal.c in frameworks/native/vulkan/libvulkan, the VK_ANDROID_native_buffer 
functions are implemented there as a sample.
The reason I guess is that VK_ANDROID_native_buffer implementation needs to 
access Gralloc HAL data structure, but mesa driver should have no dependency to 
Android HAL, which is required by HAL Binderization.

This patch doesn’t expose VK_ANDROID_native_buffer extension in driver (as the 
function is not implemented here), but avoid screening it when create device.

Thanks,
Randy

From: Palli, Tapani
Sent: Wednesday, March 1, 2017 1:03 PM
To: Jason Ekstrand ; Xu, Randy 
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Vulkan: Add VK_ANDROID_native_buffer to device 
extension list

On 03/01/2017 06:17 AM, Jason Ekstrand wrote:
On Tue, Feb 28, 2017 at 7:52 PM, Randy Xu 
> wrote:
The VK_ANDROID_native_buffer is implemented in Android Vulkan HAL,
not driver, but must be claimed in device extension list. Otherwise,
this extension will be screened off in framework and driver.

This seems rather odd.  Can't the Vulkan HAL just hook into 
vkEnumerateDeviceExtensionProperties and add it to the list there?  It seems a 
bit odd to advertise an extension but not actually provide any of the 
functionality.

This was my question as well. I proposed Randy to include functionality, at the 
moment it would be along these lines:

https://github.com/android-ia/external-mesa/commit/8b6b2fc4de933c03feba33e5b57c20262e7983cc

I don't have a strong preference where functionality exists but it seems like 
ideally the whole thing would exist in one single component. If the extension 
list cannot be modified in HAL then this becomes harder to achieve in HAL.


Test: Pass Vulkan dEQP-VK.wsi.android.swapchain.* on Android platform

Signed-off-by: Randy Xu >
---
 Android.common.mk | 3 +++
 src/intel/vulkan/anv_device.c | 9 +
 2 files changed, 12 insertions(+)

diff --git a/Android.common.mk 
b/Android.common.mk
index 611162a..f49189b 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -116,6 +116,9 @@ else
   LOCAL_CFLAGS += 
-DDEFAULT_DRIVER_DIR=\"/system/lib/$(MESA_DRI_MODULE_REL_PATH)\"
 endif

+# Enable VK_ANDROID_native_buffer
+LOCAL_CFLAGS += -DVK_USE_PLATFORM_ANDROID_KHR
+
 # uncomment to keep the debug symbols
 #LOCAL_STRIP_MODULE := false

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 0db96f2..478d753 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -258,6 +258,15 @@ static const VkExtensionProperties device_extensions[] = {
   .extensionName = VK_KHR_MAINTENANCE1_EXTENSION_NAME,
   .specVersion = 1,
},
+#ifdef VK_USE_PLATFORM_ANDROID_KHR
+   {
+  // Refer 
https://source.android.com/devices/graphics/implement-vulkan.html
+  // "Window System Integration (WSI) extensions are exported by the loader
+  //  and primarily implemented in it rather than the driver."
+  .extensionName = "VK_ANDROID_native_buffer",

In the other places, we use the EXTENSION_NAME #define

+  .specVersion = 1,
+   },
+#endif
{
   .extensionName = VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME,
   .specVersion = 1,
--
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

[Mesa-dev] [PATCH 22/24] i965: Delete brw_do_cubemap_normalize

[Jason Ekstrand]

This hasn't been used for quite some time now but we never bothered to
get rid of it when we dropped GLSL IR support for vec4.
---
 src/mesa/drivers/dri/i965/Makefile.sources |   1 -
 src/mesa/drivers/dri/i965/brw_context.h|   2 -
 .../drivers/dri/i965/brw_cubemap_normalize.cpp | 121 -
 3 files changed, 124 deletions(-)
 delete mode 100644 src/mesa/drivers/dri/i965/brw_cubemap_normalize.cpp

diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
b/src/mesa/drivers/dri/i965/Makefile.sources
index 1dd109b..4711be0 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -111,7 +111,6 @@ i965_FILES = \
brw_context.h \
brw_cs.c \
brw_cs.h \
-   brw_cubemap_normalize.cpp \
brw_curbe.c \
brw_draw.c \
brw_draw.h \
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index e252261..288ef3a 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1558,8 +1558,6 @@ brw_program_reloc(struct brw_context *brw, uint32_t 
state_offset,
return brw->cache.bo->offset64 + prog_offset;
 }
 
-bool brw_do_cubemap_normalize(struct exec_list *instructions);
-
 static inline bool
 brw_depth_writes_enabled(const struct brw_context *brw)
 {
diff --git a/src/mesa/drivers/dri/i965/brw_cubemap_normalize.cpp 
b/src/mesa/drivers/dri/i965/brw_cubemap_normalize.cpp
deleted file mode 100644
index 2ff9ec1..000
--- a/src/mesa/drivers/dri/i965/brw_cubemap_normalize.cpp
+++ /dev/null
@@ -1,121 +0,0 @@
-/*
- * Copyright © 2010 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- */
-
-/**
- * \file brw_cubemap_normalize.cpp
- *
- * IR lower pass to perform the normalization of the cubemap coordinates to
- * have the largest magnitude component be -1.0 or 1.0.
- *
- * \author Eric Anholt 
- */
-
-#include "compiler/glsl_types.h"
-#include "compiler/glsl/ir.h"
-#include "program/prog_instruction.h" /* For WRITEMASK_* */
-
-class brw_cubemap_normalize_visitor : public ir_hierarchical_visitor {
-public:
-   brw_cubemap_normalize_visitor()
-   {
-  progress = false;
-   }
-
-   ir_visitor_status visit_leave(ir_texture *ir);
-
-   bool progress;
-};
-
-ir_visitor_status
-brw_cubemap_normalize_visitor::visit_leave(ir_texture *ir)
-{
-   if (ir->sampler->type->sampler_dimensionality != GLSL_SAMPLER_DIM_CUBE)
-  return visit_continue;
-
-   if (!ir->coordinate)
-  return visit_continue;
-
-   void *mem_ctx = ralloc_parent(ir);
-
-   ir_variable *var = new(mem_ctx) ir_variable(ir->coordinate->type,
-  "coordinate", ir_var_auto);
-   base_ir->insert_before(var);
-   ir_dereference *deref = new(mem_ctx) ir_dereference_variable(var);
-   ir_assignment *assign = new(mem_ctx) ir_assignment(deref, ir->coordinate,
- NULL);
-   base_ir->insert_before(assign);
-
-   deref = new(mem_ctx) ir_dereference_variable(var);
-   ir_rvalue *swiz0 = new(mem_ctx) ir_swizzle(deref, 0, 0, 0, 0, 1);
-   deref = new(mem_ctx) ir_dereference_variable(var);
-   ir_rvalue *swiz1 = new(mem_ctx) ir_swizzle(deref, 1, 0, 0, 0, 1);
-   deref = new(mem_ctx) ir_dereference_variable(var);
-   ir_rvalue *swiz2 = new(mem_ctx) ir_swizzle(deref, 2, 0, 0, 0, 1);
-
-   swiz0 = new(mem_ctx) ir_expression(ir_unop_abs, swiz0->type, swiz0, NULL);
-   swiz1 = new(mem_ctx) ir_expression(ir_unop_abs, swiz1->type, swiz1, NULL);
-   swiz2 = new(mem_ctx) ir_expression(ir_unop_abs, swiz2->type, swiz2, NULL);
-
-   ir_expression *expr;
-   expr = new(mem_ctx) ir_expression(ir_binop_max,
-glsl_type::float_type,
-swiz0, swiz1);
-
-   expr = new(mem_ctx) ir_expression(ir_binop_max,
-

[Mesa-dev] [PATCH 16/24] i965: Move BRW_ATTRIB_WA_* defines to brw_compiler.h

[Jason Ekstrand]

---
 src/mesa/drivers/dri/i965/brw_compiler.h  | 14 +-
 src/mesa/drivers/dri/i965/brw_nir_attribute_workarounds.c |  1 -
 src/mesa/drivers/dri/i965/brw_vs.h| 11 ---
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index 4102280..c48c3ad 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -169,13 +169,25 @@ struct brw_sampler_prog_key_data {
uint32_t yx_xuxv_image_mask;
 };
 
+/**
+ * The VF can't natively handle certain types of attributes, such as GL_FIXED
+ * or most 10_10_10_2 types.  These flags enable various VS workarounds to
+ * "fix" attributes at the beginning of shaders.
+ */
+#define BRW_ATTRIB_WA_COMPONENT_MASK7  /* mask for GL_FIXED scale channel 
count */
+#define BRW_ATTRIB_WA_NORMALIZE 8   /* normalize in shader */
+#define BRW_ATTRIB_WA_BGRA  16  /* swap r/b channels in shader */
+#define BRW_ATTRIB_WA_SIGN  32  /* interpret as signed in shader */
+#define BRW_ATTRIB_WA_SCALE 64  /* interpret as scaled in shader */
 
 /** The program key for Vertex Shaders. */
 struct brw_vs_prog_key {
unsigned program_string_id;
 
-   /*
+   /**
 * Per-attribute workaround flags
+*
+* For each attribute, a combination of BRW_ATTRIB_WA_*.
 */
uint8_t gl_attrib_wa_flags[VERT_ATTRIB_MAX];
 
diff --git a/src/mesa/drivers/dri/i965/brw_nir_attribute_workarounds.c 
b/src/mesa/drivers/dri/i965/brw_nir_attribute_workarounds.c
index 0bb766d..d695771 100644
--- a/src/mesa/drivers/dri/i965/brw_nir_attribute_workarounds.c
+++ b/src/mesa/drivers/dri/i965/brw_nir_attribute_workarounds.c
@@ -23,7 +23,6 @@
 
 #include "compiler/nir/nir_builder.h"
 #include "brw_nir.h"
-#include "brw_vs.h"
 
 /**
  * Prior to Haswell, the hardware can't natively support GL_FIXED or
diff --git a/src/mesa/drivers/dri/i965/brw_vs.h 
b/src/mesa/drivers/dri/i965/brw_vs.h
index 2b49afb..0e01551 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.h
+++ b/src/mesa/drivers/dri/i965/brw_vs.h
@@ -36,17 +36,6 @@
 
 #include "brw_vec4.h"
 
-/**
- * The VF can't natively handle certain types of attributes, such as GL_FIXED
- * or most 10_10_10_2 types.  These flags enable various VS workarounds to
- * "fix" attributes at the beginning of shaders.
- */
-#define BRW_ATTRIB_WA_COMPONENT_MASK7  /* mask for GL_FIXED scale channel 
count */
-#define BRW_ATTRIB_WA_NORMALIZE 8   /* normalize in shader */
-#define BRW_ATTRIB_WA_BGRA  16  /* swap r/b channels in shader */
-#define BRW_ATTRIB_WA_SIGN  32  /* interpret as signed in shader */
-#define BRW_ATTRIB_WA_SCALE 64  /* interpret as scaled in shader */
-
 #ifdef __cplusplus
 extern "C" {
 #endif
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 17/24] i965: Make mark_surface_used a static inline in brw_compiler.h

[Jason Ekstrand]

One of these days, I'd like to see this function go away all together
but for now, let's at least put it near the struct it updates.
---
 src/mesa/drivers/dri/i965/brw_compiler.h | 13 +
 src/mesa/drivers/dri/i965/brw_shader.cpp | 13 -
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index c48c3ad..85257d4 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -443,6 +443,19 @@ struct brw_stage_prog_data {
struct brw_image_param *image_param;
 };
 
+static inline void
+brw_mark_surface_used(struct brw_stage_prog_data *prog_data,
+  unsigned surf_index)
+{
+   /* A binding table index is 8 bits and the top 3 values are reserved for
+* special things (stateless and SLM).
+*/
+   assert(surf_index <= 252);
+
+   prog_data->binding_table.size_bytes =
+  MAX2(prog_data->binding_table.size_bytes, (surf_index + 1) * 4);
+}
+
 /* Data about a particular attempt to compile a program.  Note that
  * there can be many of these, each in a different GL state
  * corresponding to a different brw_wm_prog_key struct, with different
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp 
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 8b852d5..47ea9c1 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -29,19 +29,6 @@
 #include "brw_vec4_tes.h"
 #include "main/uniforms.h"
 
-extern "C" void
-brw_mark_surface_used(struct brw_stage_prog_data *prog_data,
-  unsigned surf_index)
-{
-   /* A binding table index is 8 bits and the top 3 values are reserved for
-* special things (stateless and SLM).
-*/
-   assert(surf_index <= 252);
-
-   prog_data->binding_table.size_bytes =
-  MAX2(prog_data->binding_table.size_bytes, (surf_index + 1) * 4);
-}
-
 enum brw_reg_type
 brw_type_for_base_type(const struct glsl_type *type)
 {
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 23/24] i965: Reduce cross-pollination between the DRI driver and compiler

[Jason Ekstrand]

A lot of compiler stuff was including brw_context.h as a convenient
grab-bag way of getting at a bunch of other includes.  Also, a bunch of
non-compiler stuff is including compiler "internal" headers for no good
reason.
---
 src/intel/blorp/blorp_priv.h   | 2 +-
 src/intel/tools/disasm.c   | 4 ++--
 src/intel/vulkan/anv_pipeline.c| 2 +-
 src/intel/vulkan/anv_private.h | 2 +-
 src/mesa/drivers/dri/i965/brw_clip.c   | 1 -
 src/mesa/drivers/dri/i965/brw_clip.h   | 2 +-
 src/mesa/drivers/dri/i965/brw_clip_line.c  | 1 -
 src/mesa/drivers/dri/i965/brw_clip_point.c | 1 -
 src/mesa/drivers/dri/i965/brw_clip_tri.c   | 1 -
 src/mesa/drivers/dri/i965/brw_clip_unfilled.c  | 1 -
 src/mesa/drivers/dri/i965/brw_clip_util.c  | 1 -
 src/mesa/drivers/dri/i965/brw_compiler.c   | 2 +-
 src/mesa/drivers/dri/i965/brw_context.c| 1 -
 src/mesa/drivers/dri/i965/brw_context.h| 2 +-
 src/mesa/drivers/dri/i965/brw_cs.c | 4 +---
 src/mesa/drivers/dri/i965/brw_defines.h| 2 ++
 src/mesa/drivers/dri/i965/brw_disasm.c | 3 ++-
 src/mesa/drivers/dri/i965/brw_draw.c   | 1 -
 src/mesa/drivers/dri/i965/brw_eu.c | 3 ++-
 src/mesa/drivers/dri/i965/brw_eu_compact.c | 3 ++-
 src/mesa/drivers/dri/i965/brw_eu_emit.c| 1 -
 src/mesa/drivers/dri/i965/brw_eu_util.c| 1 -
 src/mesa/drivers/dri/i965/brw_ff_gs.c  | 2 +-
 src/mesa/drivers/dri/i965/brw_ff_gs.h  | 2 +-
 src/mesa/drivers/dri/i965/brw_ff_gs_emit.c | 1 -
 src/mesa/drivers/dri/i965/brw_fs.cpp   | 2 +-
 src/mesa/drivers/dri/i965/brw_fs_builder.h | 1 -
 src/mesa/drivers/dri/i965/brw_fs_surface_builder.h | 1 -
 src/mesa/drivers/dri/i965/brw_gs.c | 3 +--
 src/mesa/drivers/dri/i965/brw_inst.h   | 3 ++-
 src/mesa/drivers/dri/i965/brw_interpolation_map.c  | 1 -
 src/mesa/drivers/dri/i965/brw_ir_vec4.h| 1 -
 src/mesa/drivers/dri/i965/brw_link.cpp | 4 +---
 src/mesa/drivers/dri/i965/brw_nir.c| 1 +
 src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp | 4 ++--
 src/mesa/drivers/dri/i965/brw_program.c| 3 +--
 src/mesa/drivers/dri/i965/brw_program.h| 2 +-
 src/mesa/drivers/dri/i965/brw_program_cache.c  | 2 +-
 src/mesa/drivers/dri/i965/brw_sf.c | 1 -
 src/mesa/drivers/dri/i965/brw_sf.h | 2 +-
 src/mesa/drivers/dri/i965/brw_sf_emit.c| 1 -
 src/mesa/drivers/dri/i965/brw_shader.cpp   | 3 ++-
 src/mesa/drivers/dri/i965/brw_shader.h | 3 ++-
 src/mesa/drivers/dri/i965/brw_state_dump.c | 1 -
 src/mesa/drivers/dri/i965/brw_state_upload.c   | 1 +
 src/mesa/drivers/dri/i965/brw_tcs.c| 3 +--
 src/mesa/drivers/dri/i965/brw_tes.c| 3 +--
 src/mesa/drivers/dri/i965/brw_vec4.cpp | 1 +
 src/mesa/drivers/dri/i965/brw_vec4_builder.h   | 1 -
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp   | 1 +
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp  | 1 +
 src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp | 1 +
 src/mesa/drivers/dri/i965/brw_vec4_tes.cpp | 1 +
 src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp  | 2 +-
 src/mesa/drivers/dri/i965/brw_vs.c | 2 +-
 src/mesa/drivers/dri/i965/brw_vs.h | 3 +--
 src/mesa/drivers/dri/i965/brw_vue_map.c| 3 ++-
 src/mesa/drivers/dri/i965/brw_wm.c | 3 +--
 src/mesa/drivers/dri/i965/brw_wm.h | 1 -
 src/mesa/drivers/dri/i965/gen7_cs_state.c  | 3 +--
 src/mesa/drivers/dri/i965/intel_debug.h| 3 +++
 src/mesa/drivers/dri/i965/intel_screen.c   | 2 +-
 62 files changed, 54 insertions(+), 66 deletions(-)

diff --git a/src/intel/blorp/blorp_priv.h b/src/intel/blorp/blorp_priv.h
index d9c03b1..c61ab08 100644
--- a/src/intel/blorp/blorp_priv.h
+++ b/src/intel/blorp/blorp_priv.h
@@ -27,7 +27,7 @@
 #include 
 
 #include "compiler/nir/nir.h"
-#include "brw_compiler.h"
+#include "compiler/brw_compiler.h"
 
 #include "blorp.h"
 
diff --git a/src/intel/tools/disasm.c b/src/intel/tools/disasm.c
index 4ac7b90..fbc5c70 100644
--- a/src/intel/tools/disasm.c
+++ b/src/intel/tools/disasm.c
@@ -24,8 +24,8 @@
 #include 
 
 #include "brw_context.h"
-#include "brw_inst.h"
-#include "brw_eu.h"
+#include "compiler/brw_inst.h"
+#include "compiler/brw_eu.h"
 
 #include "gen_disasm.h"
 
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 708b05a..9db27a9 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -30,7 +30,7 @@
 #include "util/mesa-sha1.h"
 #include "common/gen_l3_config.h"
 #include "anv_private.h"
-#include "brw_nir.h"
+#include "compiler/brw_nir.h"
 #include "anv_nir.h"
 #include 

[Mesa-dev] [PATCH 24/24] i965: Move the back-end compiler to src/intel/compiler

[Jason Ekstrand]

---
 src/intel/Makefile.am  |   2 +
 src/intel/Makefile.compiler.am | 116 +
 src/intel/Makefile.sources |  89 
 src/intel/compiler/.gitignore  |   1 +
 .../dri/i965 => intel/compiler}/brw_cfg.cpp|   0
 .../drivers/dri/i965 => intel/compiler}/brw_cfg.h  |   0
 .../dri/i965 => intel/compiler}/brw_compiler.c |   0
 .../dri/i965 => intel/compiler}/brw_compiler.h |   0
 .../compiler}/brw_dead_control_flow.cpp|   0
 .../compiler}/brw_dead_control_flow.h  |   0
 .../dri/i965 => intel/compiler}/brw_disasm.c   |   0
 .../drivers/dri/i965 => intel/compiler}/brw_eu.c   |   0
 .../drivers/dri/i965 => intel/compiler}/brw_eu.h   |   0
 .../dri/i965 => intel/compiler}/brw_eu_compact.c   |   0
 .../dri/i965 => intel/compiler}/brw_eu_emit.c  |   0
 .../dri/i965 => intel/compiler}/brw_eu_util.c  |   0
 .../dri/i965 => intel/compiler}/brw_eu_validate.c  |   0
 .../drivers/dri/i965 => intel/compiler}/brw_fs.cpp |   0
 .../drivers/dri/i965 => intel/compiler}/brw_fs.h   |   0
 .../dri/i965 => intel/compiler}/brw_fs_builder.h   |   0
 .../compiler}/brw_fs_cmod_propagation.cpp  |   0
 .../compiler}/brw_fs_combine_constants.cpp |   0
 .../compiler}/brw_fs_copy_propagation.cpp  |   0
 .../dri/i965 => intel/compiler}/brw_fs_cse.cpp |   0
 .../compiler}/brw_fs_dead_code_eliminate.cpp   |   0
 .../i965 => intel/compiler}/brw_fs_generator.cpp   |   0
 .../compiler}/brw_fs_live_variables.cpp|   0
 .../compiler}/brw_fs_live_variables.h  |   0
 .../i965 => intel/compiler}/brw_fs_lower_d2x.cpp   |   0
 .../i965 => intel/compiler}/brw_fs_lower_pack.cpp  |   0
 .../dri/i965 => intel/compiler}/brw_fs_nir.cpp |   0
 .../compiler}/brw_fs_reg_allocate.cpp  |   0
 .../compiler}/brw_fs_register_coalesce.cpp |   0
 .../compiler}/brw_fs_saturate_propagation.cpp  |   0
 .../compiler}/brw_fs_sel_peephole.cpp  |   0
 .../compiler}/brw_fs_surface_builder.cpp   |   0
 .../compiler}/brw_fs_surface_builder.h |   0
 .../i965 => intel/compiler}/brw_fs_validate.cpp|   0
 .../dri/i965 => intel/compiler}/brw_fs_visitor.cpp |   0
 .../drivers/dri/i965 => intel/compiler}/brw_inst.h |   0
 .../compiler}/brw_interpolation_map.c  |   0
 .../dri/i965 => intel/compiler}/brw_ir_allocator.h |   0
 .../dri/i965 => intel/compiler}/brw_ir_fs.h|   0
 .../dri/i965 => intel/compiler}/brw_ir_vec4.h  |   0
 .../drivers/dri/i965 => intel/compiler}/brw_nir.c  |   0
 .../drivers/dri/i965 => intel/compiler}/brw_nir.h  |   0
 .../compiler}/brw_nir_analyze_boolean_resolves.c   |   0
 .../compiler}/brw_nir_attribute_workarounds.c  |   0
 .../i965 => intel/compiler}/brw_nir_intrinsics.c   |   0
 .../compiler}/brw_nir_opt_peephole_ffma.c  |   0
 .../compiler}/brw_nir_tcs_workarounds.c|   0
 .../compiler}/brw_nir_trig_workarounds.py  |   0
 .../dri/i965 => intel/compiler}/brw_packed_float.c |   0
 .../compiler}/brw_predicated_break.cpp |   0
 .../drivers/dri/i965 => intel/compiler}/brw_reg.h  |   0
 .../compiler}/brw_schedule_instructions.cpp|   0
 .../dri/i965 => intel/compiler}/brw_shader.cpp |   0
 .../dri/i965 => intel/compiler}/brw_shader.h   |   0
 .../dri/i965 => intel/compiler}/brw_vec4.cpp   |   0
 .../drivers/dri/i965 => intel/compiler}/brw_vec4.h |   0
 .../dri/i965 => intel/compiler}/brw_vec4_builder.h |   0
 .../compiler}/brw_vec4_cmod_propagation.cpp|   0
 .../compiler}/brw_vec4_copy_propagation.cpp|   0
 .../dri/i965 => intel/compiler}/brw_vec4_cse.cpp   |   0
 .../compiler}/brw_vec4_dead_code_eliminate.cpp |   0
 .../i965 => intel/compiler}/brw_vec4_generator.cpp |   0
 .../i965 => intel/compiler}/brw_vec4_gs_nir.cpp|   0
 .../compiler}/brw_vec4_gs_visitor.cpp  |   0
 .../i965 => intel/compiler}/brw_vec4_gs_visitor.h  |   0
 .../compiler}/brw_vec4_live_variables.cpp  |   0
 .../compiler}/brw_vec4_live_variables.h|   0
 .../dri/i965 => intel/compiler}/brw_vec4_nir.cpp   |   0
 .../compiler}/brw_vec4_reg_allocate.cpp|   0
 .../compiler}/brw_vec4_surface_builder.cpp |   0
 .../compiler}/brw_vec4_surface_builder.h   |   0
 .../dri/i965 => intel/compiler}/brw_vec4_tcs.cpp   |   0
 .../dri/i965 => intel/compiler}/brw_vec4_tcs.h |   0
 .../dri/i965 => intel/compiler}/brw_vec4_tes.cpp   |   0
 .../dri/i965 => intel/compiler}/brw_vec4_tes.h |   0
 .../i965 => intel/compiler}/brw_vec4_visitor.cpp   |   0
 .../compiler}/brw_vec4_vs_visitor.cpp  |   0
 .../dri/i965 => intel/compiler}/brw_vue_map.c  |   0
 .../dri/i965 => intel/compiler}/brw_wm_iz.cpp  |   0
 .../i965 => intel/compiler}/gen6_gs_visitor.cpp|   0
 .../dri/i965 => intel/compiler}/gen6_gs_visitor.h  |   0
 .../i965 => 

[Mesa-dev] [PATCH 14/24] i965/inst: Stop using fi_type

[Jason Ekstrand]

It's a mesa define that's trivial to inline.  This removes a dependence
on main/imports.h.
---
 src/mesa/drivers/dri/i965/brw_inst.h | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_inst.h 
b/src/mesa/drivers/dri/i965/brw_inst.h
index bcb6786..d6a2105 100644
--- a/src/mesa/drivers/dri/i965/brw_inst.h
+++ b/src/mesa/drivers/dri/i965/brw_inst.h
@@ -570,7 +570,10 @@ brw_inst_imm_ud(const struct gen_device_info *devinfo, 
const brw_inst *insn)
 static inline float
 brw_inst_imm_f(const struct gen_device_info *devinfo, const brw_inst *insn)
 {
-   fi_type ft;
+   union {
+  float f;
+  uint32_t u;
+   } ft;
(void) devinfo;
ft.u = brw_inst_bits(insn, 127, 96);
return ft.f;
@@ -608,7 +611,10 @@ static inline void
 brw_inst_set_imm_f(const struct gen_device_info *devinfo,
brw_inst *insn, float value)
 {
-   fi_type ft;
+   union {
+  float f;
+  uint32_t u;
+   } ft;
(void) devinfo;
ft.f = value;
brw_inst_set_bits(insn, 127, 96, ft.u);
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 19/24] i965: Move image uniform setup to brw_nir_uniforms.cpp

[Jason Ekstrand]

It's the only thing that's using it.
---
 src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp | 51 ++
 src/mesa/drivers/dri/i965/brw_shader.cpp   | 51 --
 2 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp 
b/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
index 447998b..9ebd7d8 100644
--- a/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
+++ b/src/mesa/drivers/dri/i965/brw_nir_uniforms.cpp
@@ -67,6 +67,57 @@ brw_nir_setup_glsl_builtin_uniform(nir_variable *var,
 }
 
 static void
+setup_vec4_uniform_value(const gl_constant_value **params,
+ const gl_constant_value *values,
+ unsigned n)
+{
+   static const gl_constant_value zero = { 0 };
+
+   for (unsigned i = 0; i < n; ++i)
+  params[i] = [i];
+
+   for (unsigned i = n; i < 4; ++i)
+  params[i] = 
+}
+
+void
+brw_setup_image_uniform_values(gl_shader_stage stage,
+   struct brw_stage_prog_data *stage_prog_data,
+   unsigned param_start_index,
+   const gl_uniform_storage *storage)
+{
+   const gl_constant_value **param =
+  _prog_data->param[param_start_index];
+
+   for (unsigned i = 0; i < MAX2(storage->array_elements, 1); i++) {
+  const unsigned image_idx = storage->opaque[stage].index + i;
+  const brw_image_param *image_param =
+ _prog_data->image_param[image_idx];
+
+  /* Upload the brw_image_param structure.  The order is expected to match
+   * the BRW_IMAGE_PARAM_*_OFFSET defines.
+   */
+  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_SURFACE_IDX_OFFSET,
+ (const gl_constant_value *)_param->surface_idx, 1);
+  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_OFFSET_OFFSET,
+ (const gl_constant_value *)image_param->offset, 2);
+  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_SIZE_OFFSET,
+ (const gl_constant_value *)image_param->size, 3);
+  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_STRIDE_OFFSET,
+ (const gl_constant_value *)image_param->stride, 4);
+  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_TILING_OFFSET,
+ (const gl_constant_value *)image_param->tiling, 3);
+  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_SWIZZLING_OFFSET,
+ (const gl_constant_value *)image_param->swizzling, 2);
+  param += BRW_IMAGE_PARAM_SIZE;
+
+  brw_mark_surface_used(
+ stage_prog_data,
+ stage_prog_data->binding_table.image_start + image_idx);
+   }
+}
+
+static void
 brw_nir_setup_glsl_uniform(gl_shader_stage stage, nir_variable *var,
const struct gl_program *prog,
struct brw_stage_prog_data *stage_prog_data,
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp 
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 47ea9c1..28ed8dc 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -1137,57 +1137,6 @@ backend_shader::calculate_cfg()
cfg = new(mem_ctx) cfg_t(>instructions);
 }
 
-static void
-setup_vec4_uniform_value(const gl_constant_value **params,
- const gl_constant_value *values,
- unsigned n)
-{
-   static const gl_constant_value zero = { 0 };
-
-   for (unsigned i = 0; i < n; ++i)
-  params[i] = [i];
-
-   for (unsigned i = n; i < 4; ++i)
-  params[i] = 
-}
-
-void
-brw_setup_image_uniform_values(gl_shader_stage stage,
-   struct brw_stage_prog_data *stage_prog_data,
-   unsigned param_start_index,
-   const gl_uniform_storage *storage)
-{
-   const gl_constant_value **param =
-  _prog_data->param[param_start_index];
-
-   for (unsigned i = 0; i < MAX2(storage->array_elements, 1); i++) {
-  const unsigned image_idx = storage->opaque[stage].index + i;
-  const brw_image_param *image_param =
- _prog_data->image_param[image_idx];
-
-  /* Upload the brw_image_param structure.  The order is expected to match
-   * the BRW_IMAGE_PARAM_*_OFFSET defines.
-   */
-  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_SURFACE_IDX_OFFSET,
- (const gl_constant_value *)_param->surface_idx, 1);
-  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_OFFSET_OFFSET,
- (const gl_constant_value *)image_param->offset, 2);
-  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_SIZE_OFFSET,
- (const gl_constant_value *)image_param->size, 3);
-  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_STRIDE_OFFSET,
- (const gl_constant_value *)image_param->stride, 4);
-  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_TILING_OFFSET,
- (const gl_constant_value *)image_param->tiling, 3);
-  setup_vec4_uniform_value(param + BRW_IMAGE_PARAM_SWIZZLING_OFFSET,
- (const 

[Mesa-dev] [PATCH 20/24] i965: Move a bunch of pre-compile and link stuff to brw_program.h

[Jason Ekstrand]

It's all GL-specific and brw_program.h is not part of i965_compiler.
---
 src/mesa/drivers/dri/i965/brw_program.h | 15 +++
 src/mesa/drivers/dri/i965/brw_shader.h  | 14 --
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
b/src/mesa/drivers/dri/i965/brw_program.h
index ac34d03..46831a8 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -69,6 +69,21 @@ brw_stage_prog_data_free(const void *prog_data);
 void
 brw_dump_arb_asm(const char *stage, struct gl_program *prog);
 
+bool brw_vs_precompile(struct gl_context *ctx, struct gl_program *prog);
+bool brw_tcs_precompile(struct gl_context *ctx,
+struct gl_shader_program *shader_prog,
+struct gl_program *prog);
+bool brw_tes_precompile(struct gl_context *ctx,
+struct gl_shader_program *shader_prog,
+struct gl_program *prog);
+bool brw_gs_precompile(struct gl_context *ctx, struct gl_program *prog);
+bool brw_fs_precompile(struct gl_context *ctx, struct gl_program *prog);
+bool brw_cs_precompile(struct gl_context *ctx, struct gl_program *prog);
+
+GLboolean brw_link_shader(struct gl_context *ctx, struct gl_shader_program 
*prog);
+struct gl_linked_shader *brw_new_shader(gl_shader_stage stage);
+
+
 void brw_upload_tcs_prog(struct brw_context *brw);
 void brw_tcs_populate_key(struct brw_context *brw,
   struct brw_tcs_prog_key *key);
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h 
b/src/mesa/drivers/dri/i965/brw_shader.h
index 37e6d2f..1c3814d 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.h
+++ b/src/mesa/drivers/dri/i965/brw_shader.h
@@ -288,20 +288,6 @@ struct brw_gs_compile
unsigned control_data_header_size_bits;
 };
 
-bool brw_vs_precompile(struct gl_context *ctx, struct gl_program *prog);
-bool brw_tcs_precompile(struct gl_context *ctx,
-struct gl_shader_program *shader_prog,
-struct gl_program *prog);
-bool brw_tes_precompile(struct gl_context *ctx,
-struct gl_shader_program *shader_prog,
-struct gl_program *prog);
-bool brw_gs_precompile(struct gl_context *ctx, struct gl_program *prog);
-bool brw_fs_precompile(struct gl_context *ctx, struct gl_program *prog);
-bool brw_cs_precompile(struct gl_context *ctx, struct gl_program *prog);
-
-GLboolean brw_link_shader(struct gl_context *ctx, struct gl_shader_program 
*prog);
-struct gl_linked_shader *brw_new_shader(gl_shader_stage stage);
-
 unsigned get_atomic_counter_op(nir_intrinsic_op op);
 
 #ifdef __cplusplus
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 18/24] i965: Move channel_expressions and vector_splitting to brw_program.h

[Jason Ekstrand]

They're GL-specific.
---
 src/mesa/drivers/dri/i965/brw_fs.h  | 3 ---
 src/mesa/drivers/dri/i965/brw_program.h | 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
b/src/mesa/drivers/dri/i965/brw_fs.h
index d0e272b..00861ce 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -484,9 +484,6 @@ private:
void *mem_ctx;
 };
 
-bool brw_do_channel_expressions(struct exec_list *instructions);
-bool brw_do_vector_splitting(struct exec_list *instructions);
-
 void shuffle_32bit_load_result_to_64bit_data(const brw::fs_builder ,
  const fs_reg ,
  const fs_reg ,
diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
b/src/mesa/drivers/dri/i965/brw_program.h
index 56dca1f..ac34d03 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -32,6 +32,9 @@ extern "C" {
 
 struct brw_context;
 
+bool brw_do_channel_expressions(struct exec_list *instructions);
+bool brw_do_vector_splitting(struct exec_list *instructions);
+
 struct nir_shader *brw_create_nir(struct brw_context *brw,
   const struct gl_shader_program *shader_prog,
   struct gl_program *prog,
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 15/24] i965: Move BRW_MAX_DRAW_BUFFERS to brw_compiler.h

[Jason Ekstrand]

It does sort-of go with MAX_UBO and friends but MAX_DRAW_BUFFERS is an
actual hardware constant based on the number of things we can blend
rather than an arbitrary "number of things allowed in GL" like some of
the other maximums are.
---
 src/mesa/drivers/dri/i965/brw_compiler.h | 3 +++
 src/mesa/drivers/dri/i965/brw_context.h  | 3 ---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index c048a4d..4102280 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -344,6 +344,9 @@ struct brw_image_param {
uint32_t swizzling[2];
 };
 
+/** Max number of render targets in a shader */
+#define BRW_MAX_DRAW_BUFFERS 8
+
 /**
  * Max number of binding table entries used for stream output.
  *
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 7132eae..e252261 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -363,9 +363,6 @@ struct brw_ff_gs_prog_data {
 /** Number of texture sampler units */
 #define BRW_MAX_TEX_UNIT 32
 
-/** Max number of render targets in a shader */
-#define BRW_MAX_DRAW_BUFFERS 8
-
 /** Max number of UBOs in a shader */
 #define BRW_MAX_UBO 14
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 21/24] i965: Add a header for brw_vec4_vs_visitor

[Jason Ekstrand]

brw_vs.h is not a compiler file but brw_vec4_visitor is definitely a
compiler thing.
---
 src/mesa/drivers/dri/i965/Makefile.sources|  1 +
 src/mesa/drivers/dri/i965/brw_vec4.cpp|  2 +-
 src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp |  2 +-
 src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.h   | 68 +++
 src/mesa/drivers/dri/i965/brw_vs.h| 42 --
 5 files changed, 71 insertions(+), 44 deletions(-)
 create mode 100644 src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.h

diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
b/src/mesa/drivers/dri/i965/Makefile.sources
index 633c3dc..1dd109b 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -78,6 +78,7 @@ i965_compiler_FILES = \
brw_vec4_tes.h \
brw_vec4_visitor.cpp \
brw_vec4_vs_visitor.cpp \
+   brw_vec4_vs_visitor.h \
brw_vue_map.c \
brw_wm_iz.cpp \
gen6_gs_visitor.cpp \
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index fba040a..bd69f01 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -24,7 +24,7 @@
 #include "brw_vec4.h"
 #include "brw_fs.h"
 #include "brw_cfg.h"
-#include "brw_vs.h"
+#include "brw_vec4_vs_visitor.h"
 #include "brw_nir.h"
 #include "brw_vec4_builder.h"
 #include "brw_vec4_live_variables.h"
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
index a300f76..026f53d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
@@ -22,7 +22,7 @@
  */
 
 
-#include "brw_vs.h"
+#include "brw_vec4_vs_visitor.h"
 
 
 namespace brw {
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.h 
b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.h
new file mode 100644
index 000..8c346d7
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.h
@@ -0,0 +1,68 @@
+/*
+ * Copyright © 2006 - 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef BRW_VEC4_VS_VISITOR_H
+#define BRW_VEC4_VS_VISITOR_H
+
+#include "brw_vec4.h"
+
+namespace brw {
+
+class vec4_vs_visitor : public vec4_visitor
+{
+public:
+   vec4_vs_visitor(const struct brw_compiler *compiler,
+   void *log_data,
+   const struct brw_vs_prog_key *key,
+   struct brw_vs_prog_data *vs_prog_data,
+   const nir_shader *shader,
+   gl_clip_plane *clip_planes,
+   void *mem_ctx,
+   int shader_time_index,
+   bool use_legacy_snorm_formula);
+
+protected:
+   virtual dst_reg *make_reg_for_system_value(int location);
+   virtual void setup_payload();
+   virtual void emit_prolog();
+   virtual void emit_thread_end();
+   virtual void emit_urb_write_header(int mrf);
+   virtual void emit_urb_slot(dst_reg reg, int varying);
+   virtual vec4_instruction *emit_urb_write_opcode(bool complete);
+
+private:
+   int setup_attributes(int payload_reg);
+   void setup_uniform_clipplane_values();
+   void emit_clip_distances(dst_reg reg, int offset);
+
+   const struct brw_vs_prog_key *const key;
+   struct brw_vs_prog_data * const vs_prog_data;
+
+   gl_clip_plane *clip_planes;
+
+   bool use_legacy_snorm_formula;
+};
+
+} /* namespace brw */
+
+#endif /* BRW_VEC4_VS_VISITOR_H */
diff --git a/src/mesa/drivers/dri/i965/brw_vs.h 
b/src/mesa/drivers/dri/i965/brw_vs.h
index 0e01551..98b0bf1 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.h
+++ b/src/mesa/drivers/dri/i965/brw_vs.h
@@ -53,48 +53,6 @@ brw_vs_populate_key(struct brw_context *brw,
 
 #ifdef __cplusplus
 } /* extern "C" */
-
-
-namespace brw {
-
-class vec4_vs_visitor : public vec4_visitor
-{
-public:
-   vec4_vs_visitor(const struct 

[Mesa-dev] [PATCH 03/24] i965: Move brw_disassemble_inst to brw_eu.h

[Jason Ekstrand]

---
 src/mesa/drivers/dri/i965/brw_context.h | 4 
 src/mesa/drivers/dri/i965/brw_eu.h  | 2 ++
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index eda5c32..aa938b6 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1352,10 +1352,6 @@ void brw_upload_urb_fence(struct brw_context *brw);
  */
 void brw_upload_cs_urb_state(struct brw_context *brw);
 
-/* brw_disasm.c */
-int brw_disassemble_inst(FILE *file, const struct gen_device_info *devinfo,
- struct brw_inst *inst, bool is_compacted);
-
 /* brw_vs.c */
 gl_clip_plane *brw_select_clip_planes(struct gl_context *ctx);
 
diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
b/src/mesa/drivers/dri/i965/brw_eu.h
index c44896b..91c3052 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -114,6 +114,8 @@ void brw_set_default_acc_write_control(struct brw_codegen 
*p, unsigned value);
 
 void brw_init_codegen(const struct gen_device_info *, struct brw_codegen *p,
  void *mem_ctx);
+int brw_disassemble_inst(FILE *file, const struct gen_device_info *devinfo,
+ struct brw_inst *inst, bool is_compacted);
 void brw_disassemble(const struct gen_device_info *devinfo, void *assembly,
  int start, int end, FILE *out);
 const unsigned *brw_get_program( struct brw_codegen *p, unsigned *sz );
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 07/24] i965: Get rid of BRW_PRIM_OFFSET

[Jason Ekstrand]

This is a relic of when we wired up meta to be able to use RECTLIST
primitives.  It's no longer needed.
---
 src/mesa/drivers/dri/i965/brw_defines.h | 8 
 src/mesa/drivers/dri/i965/brw_util.c| 8 ++--
 2 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 3c5c6c4..f443cac 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -86,14 +86,6 @@
 #define _3DPRIM_TRIFAN_NOSTIPPLE  0x16
 #define _3DPRIM_PATCHLIST(n) ({ assert(n > 0 && n <= 32); 0x20 + (n - 1); })
 
-
-/* We use this offset to be able to pass native primitive types in struct
- * _mesa_prim::mode.  Native primitive types are BRW_PRIM_OFFSET +
- * native_type, which should be different from all GL types and still fit in
- * the 8 bits avialable. */
-
-#define BRW_PRIM_OFFSET   0x80
-
 #define BRW_ANISORATIO_2 0
 #define BRW_ANISORATIO_4 1
 #define BRW_ANISORATIO_6 2
diff --git a/src/mesa/drivers/dri/i965/brw_util.c 
b/src/mesa/drivers/dri/i965/brw_util.c
index 934b6b8..f190a68 100644
--- a/src/mesa/drivers/dri/i965/brw_util.c
+++ b/src/mesa/drivers/dri/i965/brw_util.c
@@ -119,10 +119,6 @@ static const GLuint 
prim_to_hw_prim[GL_TRIANGLE_STRIP_ADJACENCY+1] = {
 uint32_t
 get_hw_prim_for_gl_prim(int mode)
 {
-   if (mode >= BRW_PRIM_OFFSET)
-  return mode - BRW_PRIM_OFFSET;
-   else {
-  assert(mode < ARRAY_SIZE(prim_to_hw_prim));
-  return prim_to_hw_prim[mode];
-   }
+   assert(mode < ARRAY_SIZE(prim_to_hw_prim));
+   return prim_to_hw_prim[mode];
 }
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 04/24] i965: Move some gen4 WM defines to brw_compiler.h

[Jason Ekstrand]

These go in wm_prog_key so they're part of the compiler interface.
---
 src/mesa/drivers/dri/i965/brw_compiler.h | 24 +++-
 src/mesa/drivers/dri/i965/brw_wm.c   | 32 
 src/mesa/drivers/dri/i965/brw_wm.h   | 17 -
 src/mesa/drivers/dri/i965/brw_wm_iz.cpp  | 15 +++
 4 files changed, 46 insertions(+), 42 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index 297d8f8..1b71c7f 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -247,8 +247,30 @@ struct brw_gs_prog_key
struct brw_sampler_prog_key_data tex;
 };
 
+/* A big lookup table is used to figure out which and how many
+ * additional regs will inserted before the main payload in the WM
+ * program execution.  These mainly relate to depth and stencil
+ * processing and the early-depth-test optimization.
+ */
+enum brw_wm_iz_bits {
+   BRW_WM_IZ_PS_KILL_ALPHATEST_BIT = 0x1,
+   BRW_WM_IZ_PS_COMPUTES_DEPTH_BIT = 0x2,
+   BRW_WM_IZ_DEPTH_WRITE_ENABLE_BIT= 0x4,
+   BRW_WM_IZ_DEPTH_TEST_ENABLE_BIT = 0x8,
+   BRW_WM_IZ_STENCIL_WRITE_ENABLE_BIT  = 0x10,
+   BRW_WM_IZ_STENCIL_TEST_ENABLE_BIT   = 0x20,
+   BRW_WM_IZ_BIT_MAX   = 0x40
+};
+
+enum brw_wm_aa_enable {
+   BRW_WM_AA_NEVER,
+   BRW_WM_AA_SOMETIMES,
+   BRW_WM_AA_ALWAYS
+};
+
 /** The program key for Fragment/Pixel Shaders. */
 struct brw_wm_prog_key {
+   /* Some collection of BRW_WM_IZ_* */
uint8_t iz_lookup;
bool stats_wm:1;
bool flat_shade:1;
@@ -257,7 +279,7 @@ struct brw_wm_prog_key {
bool clamp_fragment_color:1;
bool persample_interp:1;
bool multisample_fbo:1;
-   unsigned line_aa:2;
+   enum brw_wm_aa_enable line_aa:2;
bool high_quality_derivatives:1;
bool force_dual_color_blend:1;
bool coherent_fb_fetch:1;
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c 
b/src/mesa/drivers/dri/i965/brw_wm.c
index 4a07c14..dd3e201 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -457,53 +457,53 @@ brw_wm_populate_key(struct brw_context *brw, struct 
brw_wm_prog_key *key)
if (brw->gen < 6) {
   /* _NEW_COLOR */
   if (prog->info.fs.uses_discard || ctx->Color.AlphaEnabled) {
- lookup |= IZ_PS_KILL_ALPHATEST_BIT;
+ lookup |= BRW_WM_IZ_PS_KILL_ALPHATEST_BIT;
   }
 
   if (prog->info.outputs_written & BITFIELD64_BIT(FRAG_RESULT_DEPTH)) {
- lookup |= IZ_PS_COMPUTES_DEPTH_BIT;
+ lookup |= BRW_WM_IZ_PS_COMPUTES_DEPTH_BIT;
   }
 
   /* _NEW_DEPTH */
   if (ctx->Depth.Test)
- lookup |= IZ_DEPTH_TEST_ENABLE_BIT;
+ lookup |= BRW_WM_IZ_DEPTH_TEST_ENABLE_BIT;
 
   if (brw_depth_writes_enabled(brw))
- lookup |= IZ_DEPTH_WRITE_ENABLE_BIT;
+ lookup |= BRW_WM_IZ_DEPTH_WRITE_ENABLE_BIT;
 
   /* _NEW_STENCIL | _NEW_BUFFERS */
   if (ctx->Stencil._Enabled) {
- lookup |= IZ_STENCIL_TEST_ENABLE_BIT;
+ lookup |= BRW_WM_IZ_STENCIL_TEST_ENABLE_BIT;
 
  if (ctx->Stencil.WriteMask[0] ||
  ctx->Stencil.WriteMask[ctx->Stencil._BackFace])
-lookup |= IZ_STENCIL_WRITE_ENABLE_BIT;
+lookup |= BRW_WM_IZ_STENCIL_WRITE_ENABLE_BIT;
   }
   key->iz_lookup = lookup;
}
 
-   line_aa = AA_NEVER;
+   line_aa = BRW_WM_AA_NEVER;
 
/* _NEW_LINE, _NEW_POLYGON, BRW_NEW_REDUCED_PRIMITIVE */
if (ctx->Line.SmoothFlag) {
   if (brw->reduced_primitive == GL_LINES) {
- line_aa = AA_ALWAYS;
+ line_aa = BRW_WM_AA_ALWAYS;
   }
   else if (brw->reduced_primitive == GL_TRIANGLES) {
  if (ctx->Polygon.FrontMode == GL_LINE) {
-line_aa = AA_SOMETIMES;
+line_aa = BRW_WM_AA_SOMETIMES;
 
 if (ctx->Polygon.BackMode == GL_LINE ||
 (ctx->Polygon.CullFlag &&
  ctx->Polygon.CullFaceMode == GL_BACK))
-   line_aa = AA_ALWAYS;
+   line_aa = BRW_WM_AA_ALWAYS;
  }
  else if (ctx->Polygon.BackMode == GL_LINE) {
-line_aa = AA_SOMETIMES;
+line_aa = BRW_WM_AA_SOMETIMES;
 
 if ((ctx->Polygon.CullFlag &&
  ctx->Polygon.CullFaceMode == GL_FRONT))
-   line_aa = AA_ALWAYS;
+   line_aa = BRW_WM_AA_ALWAYS;
  }
   }
}
@@ -610,14 +610,14 @@ brw_fs_precompile(struct gl_context *ctx, struct 
gl_program *prog)
 
if (brw->gen < 6) {
   if (prog->info.fs.uses_discard)
- key.iz_lookup |= IZ_PS_KILL_ALPHATEST_BIT;
+ key.iz_lookup |= BRW_WM_IZ_PS_KILL_ALPHATEST_BIT;
 
   if (outputs_written & BITFIELD64_BIT(FRAG_RESULT_DEPTH))
- key.iz_lookup |= IZ_PS_COMPUTES_DEPTH_BIT;
+ key.iz_lookup |= BRW_WM_IZ_PS_COMPUTES_DEPTH_BIT;
 
   /* Just assume depth testing. */
-  key.iz_lookup |= IZ_DEPTH_TEST_ENABLE_BIT;
-  key.iz_lookup |= 

[Mesa-dev] [PATCH 08/24] i965: Don't use MAX_SURFACES in mark_surface_used

[Jason Ekstrand]

Vulkan doesn't respect MAX_SURFACES so this assert isn't valid in that
case.  It should, however, assert that it isn't insanely large.
---
 src/mesa/drivers/dri/i965/brw_shader.cpp | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp 
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 02aa0b2..8b852d5 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -33,7 +33,10 @@ extern "C" void
 brw_mark_surface_used(struct brw_stage_prog_data *prog_data,
   unsigned surf_index)
 {
-   assert(surf_index < BRW_MAX_SURFACES);
+   /* A binding table index is 8 bits and the top 3 values are reserved for
+* special things (stateless and SLM).
+*/
+   assert(surf_index <= 252);
 
prog_data->binding_table.size_bytes =
   MAX2(prog_data->binding_table.size_bytes, (surf_index + 1) * 4);
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 13/24] i965: Move brw_register_blocks to brw_fs.cpp

[Jason Ekstrand]

Its one and only caller is brw_compile_fs which lives there.
---
 src/mesa/drivers/dri/i965/brw_context.h | 11 ---
 src/mesa/drivers/dri/i965/brw_fs.cpp| 11 +++
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 3845927..7132eae 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1543,17 +1543,6 @@ brw_program_const(const struct gl_program *p)
return (const struct brw_program *) p;
 }
 
-/**
- * Pre-gen6, the register file of the EUs was shared between threads,
- * and each thread used some subset allocated on a 16-register block
- * granularity.  The unit states wanted these block counts.
- */
-static inline int
-brw_register_blocks(int reg_count)
-{
-   return ALIGN(reg_count, 16) / 16 - 1;
-}
-
 static inline uint32_t
 brw_program_reloc(struct brw_context *brw, uint32_t state_offset,
  uint32_t prog_offset)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 8dc04f9..e87a2fd 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -6371,6 +6371,17 @@ demote_sample_qualifiers(nir_shader *nir)
}
 }
 
+/**
+ * Pre-gen6, the register file of the EUs was shared between threads,
+ * and each thread used some subset allocated on a 16-register block
+ * granularity.  The unit states wanted these block counts.
+ */
+static inline int
+brw_register_blocks(int reg_count)
+{
+   return ALIGN(reg_count, 16) / 16 - 1;
+}
+
 const unsigned *
 brw_compile_fs(const struct brw_compiler *compiler, void *log_data,
void *mem_ctx,
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 01/24] i965: Move a couple of #defines from brw_context to brw_compiler

[Jason Ekstrand]

---
 src/mesa/drivers/dri/i965/brw_compiler.h | 16 
 src/mesa/drivers/dri/i965/brw_context.h  | 18 --
 2 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index 3b3b7e0..297d8f8 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -492,6 +492,22 @@ typedef enum
 } brw_varying_slot;
 
 /**
+ * We always program SF to start reading at an offset of 1 (2 varying slots)
+ * from the start of the vertex URB entry.  This causes it to skip:
+ * - VARYING_SLOT_PSIZ and BRW_VARYING_SLOT_NDC on gen4-5
+ * - VARYING_SLOT_PSIZ and VARYING_SLOT_POS on gen6+
+ */
+#define BRW_SF_URB_ENTRY_READ_OFFSET 1
+
+/**
+ * Bitmask indicating which fragment shader inputs represent varyings (and
+ * hence have to be delivered to the fragment shader by the SF/SBE stage).
+ */
+#define BRW_FS_VARYING_INPUT_MASK \
+   (BITFIELD64_RANGE(0, VARYING_SLOT_MAX) & \
+~VARYING_BIT_POS & ~VARYING_BIT_FACE)
+
+/**
  * Data structure recording the relationship between the gl_varying_slot enum
  * and "slots" within the vertex URB entry (VUE).  A "slot" is defined as a
  * single octaword within the VUE (128 bits).
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 7ff7b74..c9a931c 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -328,15 +328,6 @@ struct brw_program {
 };
 
 
-/**
- * Bitmask indicating which fragment shader inputs represent varyings (and
- * hence have to be delivered to the fragment shader by the SF/SBE stage).
- */
-#define BRW_FS_VARYING_INPUT_MASK \
-   (BITFIELD64_RANGE(0, VARYING_SLOT_MAX) & \
-~VARYING_BIT_POS & ~VARYING_BIT_FACE)
-
-
 struct brw_sf_prog_data {
GLuint urb_read_length;
GLuint total_grf;
@@ -351,15 +342,6 @@ struct brw_sf_prog_data {
 };
 
 
-/**
- * We always program SF to start reading at an offset of 1 (2 varying slots)
- * from the start of the vertex URB entry.  This causes it to skip:
- * - VARYING_SLOT_PSIZ and BRW_VARYING_SLOT_NDC on gen4-5
- * - VARYING_SLOT_PSIZ and VARYING_SLOT_POS on gen6+
- */
-#define BRW_SF_URB_ENTRY_READ_OFFSET 1
-
-
 struct brw_clip_prog_data {
GLuint curb_read_length;/* user planes? */
GLuint clip_mode;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 06/24] i965/vue_map: Stop using GLbitfield types

[Jason Ekstrand]

---
 src/mesa/drivers/dri/i965/brw_compiler.h |  8 
 src/mesa/drivers/dri/i965/brw_vue_map.c  | 10 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index 1b71c7f..16d4d0e 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -546,7 +546,7 @@ struct brw_vue_map {
 * map, and (b) actually written by the shader.  Does not include any of
 * the additional varying slots defined in brw_varying_slot.
 */
-   GLbitfield64 slots_valid;
+   uint64_t slots_valid;
 
/**
 * Is this VUE map for a separate shader pipeline?
@@ -616,12 +616,12 @@ GLuint brw_varying_to_offset(const struct brw_vue_map 
*vue_map, GLuint varying)
 
 void brw_compute_vue_map(const struct gen_device_info *devinfo,
  struct brw_vue_map *vue_map,
- GLbitfield64 slots_valid,
+ uint64_t slots_valid,
  bool separate_shader);
 
 void brw_compute_tess_vue_map(struct brw_vue_map *const vue_map,
-  const GLbitfield64 slots_valid,
-  const GLbitfield is_patch);
+  uint64_t slots_valid,
+  uint32_t is_patch);
 
 /* brw_interpolation_map.c */
 void brw_setup_vue_interpolation(struct brw_vue_map *vue_map,
diff --git a/src/mesa/drivers/dri/i965/brw_vue_map.c 
b/src/mesa/drivers/dri/i965/brw_vue_map.c
index 0d8f6c7..178a4e5 100644
--- a/src/mesa/drivers/dri/i965/brw_vue_map.c
+++ b/src/mesa/drivers/dri/i965/brw_vue_map.c
@@ -58,7 +58,7 @@ assign_vue_slot(struct brw_vue_map *vue_map, int varying, int 
slot)
 void
 brw_compute_vue_map(const struct gen_device_info *devinfo,
 struct brw_vue_map *vue_map,
-GLbitfield64 slots_valid,
+uint64_t slots_valid,
 bool separate)
 {
/* Keep using the packed/contiguous layout on old hardware - we only need
@@ -166,7 +166,7 @@ brw_compute_vue_map(const struct gen_device_info *devinfo,
 * However, it may be output by transform feedback, and we'd rather not
 * recompute state when TF changes, so we just always include it.
 */
-   GLbitfield64 builtins = slots_valid & BITFIELD64_MASK(VARYING_SLOT_VAR0);
+   uint64_t builtins = slots_valid & BITFIELD64_MASK(VARYING_SLOT_VAR0);
while (builtins != 0) {
   const int varying = ffsll(builtins) - 1;
   if (vue_map->varying_to_slot[varying] == -1) {
@@ -176,7 +176,7 @@ brw_compute_vue_map(const struct gen_device_info *devinfo,
}
 
const int first_generic_slot = slot;
-   GLbitfield64 generics = slots_valid & ~BITFIELD64_MASK(VARYING_SLOT_VAR0);
+   uint64_t generics = slots_valid & ~BITFIELD64_MASK(VARYING_SLOT_VAR0);
while (generics != 0) {
   const int varying = ffsll(generics) - 1;
   if (separate) {
@@ -197,8 +197,8 @@ brw_compute_vue_map(const struct gen_device_info *devinfo,
  */
 void
 brw_compute_tess_vue_map(struct brw_vue_map *vue_map,
- GLbitfield64 vertex_slots,
- GLbitfield patch_slots)
+ uint64_t vertex_slots,
+ uint32_t patch_slots)
 {
/* I don't think anything actually uses this... */
vue_map->slots_valid = vertex_slots;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 12/24] i965: Move SHADER_TIME_STRIDE to brw_compiler.h

[Jason Ekstrand]

---
 src/mesa/drivers/dri/i965/brw_compiler.h |  8 
 src/mesa/drivers/dri/i965/brw_context.h  |  8 
 src/mesa/drivers/dri/i965/brw_fs.cpp |  2 +-
 src/mesa/drivers/dri/i965/brw_program.c  | 10 +-
 src/mesa/drivers/dri/i965/brw_vec4.cpp   |  2 +-
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index d1ff538..c048a4d 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -374,6 +374,14 @@ struct brw_image_param {
  */
 #define BRW_GEN6_SOL_BINDING_START 0
 
+/**
+ * Stride in bytes between shader_time entries.
+ *
+ * We separate entries by a cacheline to reduce traffic between EUs writing to
+ * different entries.
+ */
+#define BRW_SHADER_TIME_STRIDE 64
+
 struct brw_stage_prog_data {
struct {
   /** size of our binding table. */
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 20ebebe..3845927 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -390,14 +390,6 @@ struct brw_ff_gs_prog_data {
 2 + /* shader time, pull constants */   \
 1 /* cs num work groups */)
 
-/**
- * Stride in bytes between shader_time entries.
- *
- * We separate entries by a cacheline to reduce traffic between EUs writing to
- * different entries.
- */
-#define SHADER_TIME_STRIDE 64
-
 struct brw_cache {
struct brw_context *brw;
 
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index c348bc7..8dc04f9 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -586,7 +586,7 @@ fs_visitor::SHADER_TIME_ADD(const fs_builder ,
 fs_reg value)
 {
int index = shader_time_index * 3 + shader_time_subindex;
-   struct brw_reg offset = brw_imm_d(index * SHADER_TIME_STRIDE);
+   struct brw_reg offset = brw_imm_d(index * BRW_SHADER_TIME_STRIDE);
 
fs_reg payload;
if (dispatch_width == 8)
diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index fdd940d..ceb79a5 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -428,7 +428,7 @@ brw_init_shader_time(struct brw_context *brw)
const int max_entries = 2048;
brw->shader_time.bo =
   drm_intel_bo_alloc(brw->bufmgr, "shader time",
- max_entries * SHADER_TIME_STRIDE * 3, 4096);
+ max_entries * BRW_SHADER_TIME_STRIDE * 3, 4096);
brw->shader_time.names = rzalloc_array(brw, const char *, max_entries);
brw->shader_time.ids = rzalloc_array(brw, int, max_entries);
brw->shader_time.types = rzalloc_array(brw, enum shader_time_shader_type,
@@ -607,11 +607,11 @@ brw_collect_shader_time(struct brw_context *brw)
void *bo_map = brw->shader_time.bo->virtual;
 
for (int i = 0; i < brw->shader_time.num_entries; i++) {
-  uint32_t *times = bo_map + i * 3 * SHADER_TIME_STRIDE;
+  uint32_t *times = bo_map + i * 3 * BRW_SHADER_TIME_STRIDE;
 
-  brw->shader_time.cumulative[i].time += times[SHADER_TIME_STRIDE * 0 / 4];
-  brw->shader_time.cumulative[i].written += times[SHADER_TIME_STRIDE * 1 / 
4];
-  brw->shader_time.cumulative[i].reset += times[SHADER_TIME_STRIDE * 2 / 
4];
+  brw->shader_time.cumulative[i].time += times[BRW_SHADER_TIME_STRIDE * 0 
/ 4];
+  brw->shader_time.cumulative[i].written += times[BRW_SHADER_TIME_STRIDE * 
1 / 4];
+  brw->shader_time.cumulative[i].reset += times[BRW_SHADER_TIME_STRIDE * 2 
/ 4];
}
 
/* Zero the BO out to clear it out for our next collection.
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 5e60eb6..fba040a 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1926,7 +1926,7 @@ vec4_visitor::emit_shader_time_write(int 
shader_time_subindex, src_reg value)
 
offset.type = BRW_REGISTER_TYPE_UD;
int index = shader_time_index * 3 + shader_time_subindex;
-   emit(MOV(offset, brw_imm_d(index * SHADER_TIME_STRIDE)));
+   emit(MOV(offset, brw_imm_d(index * BRW_SHADER_TIME_STRIDE)));
 
time.type = BRW_REGISTER_TYPE_UD;
emit(MOV(time, value));
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 10/24] i964/gs: Move MAX_GS_INPUT_VERTICES to brw_vec4_gs_visitor.h

[Jason Ekstrand]

It's only users are in brw_vec4_gs_visitor and gen6_vec4_gs_visitor.
---
 src/mesa/drivers/dri/i965/brw_context.h | 2 --
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h | 2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index aa938b6..bfe1b39 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -522,8 +522,6 @@ struct intel_batchbuffer {
} saved;
 };
 
-#define MAX_GS_INPUT_VERTICES 6
-
 #define BRW_MAX_XFB_STREAMS 4
 
 struct brw_transform_feedback_object {
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h
index 380d6f7..09221f9 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h
@@ -32,6 +32,8 @@
 
 #include "brw_vec4.h"
 
+#define MAX_GS_INPUT_VERTICES 6
+
 #ifdef __cplusplus
 namespace brw {
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 09/24] i965/gs: Add the gl_prim_to_hw_prim table to vec4_gs_visitor.cpp

[Jason Ekstrand]

It's currently in brw_util.c but that's the only bit of brw_util.c
that's shared between the compiler and the rest of the GL driver.
It's just a fairly obvious table so the duplication isn't bad.  It's
certainly less pain than trying to figure out how to share the code.
---
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index 18458ca..0220068 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -584,6 +584,23 @@ vec4_gs_visitor::gs_end_primitive()
emit(OR(dst_reg(this->control_data_bits), this->control_data_bits, mask));
 }
 
+static const GLuint gl_prim_to_hw_prim[GL_TRIANGLE_STRIP_ADJACENCY+1] = {
+   [GL_POINTS] =_3DPRIM_POINTLIST,
+   [GL_LINES] = _3DPRIM_LINELIST,
+   [GL_LINE_LOOP] = _3DPRIM_LINELOOP,
+   [GL_LINE_STRIP] = _3DPRIM_LINESTRIP,
+   [GL_TRIANGLES] = _3DPRIM_TRILIST,
+   [GL_TRIANGLE_STRIP] = _3DPRIM_TRISTRIP,
+   [GL_TRIANGLE_FAN] = _3DPRIM_TRIFAN,
+   [GL_QUADS] = _3DPRIM_QUADLIST,
+   [GL_QUAD_STRIP] = _3DPRIM_QUADSTRIP,
+   [GL_POLYGON] = _3DPRIM_POLYGON,
+   [GL_LINES_ADJACENCY] = _3DPRIM_LINELIST_ADJ,
+   [GL_LINE_STRIP_ADJACENCY] = _3DPRIM_LINESTRIP_ADJ,
+   [GL_TRIANGLES_ADJACENCY] = _3DPRIM_TRILIST_ADJ,
+   [GL_TRIANGLE_STRIP_ADJACENCY] = _3DPRIM_TRISTRIP_ADJ,
+};
+
 extern "C" const unsigned *
 brw_compile_gs(const struct brw_compiler *compiler, void *log_data,
void *mem_ctx,
@@ -796,8 +813,9 @@ brw_compile_gs(const struct brw_compiler *compiler, void 
*log_data,
else
   prog_data->base.urb_entry_size = ALIGN(output_size_bytes, 128) / 128;
 
+   assert(shader->info->gs.output_primitive < ARRAY_SIZE(gl_prim_to_hw_prim));
prog_data->output_topology =
-  get_hw_prim_for_gl_prim(shader->info->gs.output_primitive);
+  gl_prim_to_hw_prim[shader->info->gs.output_primitive];
 
prog_data->vertices_in = shader->info->gs.vertices_in;
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 11/24] i965: Move SOL binding #defines to brw_compiler.h

[Jason Ekstrand]

While we're at it, we also change the GEN6 binding macro to be a start
index that gets added to the binding.  This makes things a bit more
explicit.
---
 src/mesa/drivers/dri/i965/brw_compiler.h | 30 
 src/mesa/drivers/dri/i965/brw_context.h  | 27 -
 src/mesa/drivers/dri/i965/brw_ff_gs_emit.c   |  2 +-
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp |  2 +-
 src/mesa/drivers/dri/i965/gen6_sol.c |  2 +-
 5 files changed, 33 insertions(+), 30 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.h 
b/src/mesa/drivers/dri/i965/brw_compiler.h
index 16d4d0e..d1ff538 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.h
+++ b/src/mesa/drivers/dri/i965/brw_compiler.h
@@ -344,6 +344,36 @@ struct brw_image_param {
uint32_t swizzling[2];
 };
 
+/**
+ * Max number of binding table entries used for stream output.
+ *
+ * From the OpenGL 3.0 spec, table 6.44 (Transform Feedback State), the
+ * minimum value of MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS is 64.
+ *
+ * On Gen6, the size of transform feedback data is limited not by the number
+ * of components but by the number of binding table entries we set aside.  We
+ * use one binding table entry for a float, one entry for a vector, and one
+ * entry per matrix column.  Since the only way we can communicate our
+ * transform feedback capabilities to the client is via
+ * MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS, we need to plan for the
+ * worst case, in which all the varyings are floats, so we use up one binding
+ * table entry per component.  Therefore we need to set aside at least 64
+ * binding table entries for use by transform feedback.
+ *
+ * Note: since we don't currently pack varyings, it is currently impossible
+ * for the client to actually use up all of these binding table entries--if
+ * all of their varyings were floats, they would run out of varying slots and
+ * fail to link.  But that's a bug, so it seems prudent to go ahead and
+ * allocate the number of binding table entries we will need once the bug is
+ * fixed.
+ */
+#define BRW_MAX_SOL_BINDINGS 64
+
+/**
+ * Binding table index for the first gen6 SOL binding.
+ */
+#define BRW_GEN6_SOL_BINDING_START 0
+
 struct brw_stage_prog_data {
struct {
   /** size of our binding table. */
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index bfe1b39..20ebebe 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -378,31 +378,6 @@ struct brw_ff_gs_prog_data {
 /** Max number of image uniforms in a shader */
 #define BRW_MAX_IMAGES 32
 
-/**
- * Max number of binding table entries used for stream output.
- *
- * From the OpenGL 3.0 spec, table 6.44 (Transform Feedback State), the
- * minimum value of MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS is 64.
- *
- * On Gen6, the size of transform feedback data is limited not by the number
- * of components but by the number of binding table entries we set aside.  We
- * use one binding table entry for a float, one entry for a vector, and one
- * entry per matrix column.  Since the only way we can communicate our
- * transform feedback capabilities to the client is via
- * MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS, we need to plan for the
- * worst case, in which all the varyings are floats, so we use up one binding
- * table entry per component.  Therefore we need to set aside at least 64
- * binding table entries for use by transform feedback.
- *
- * Note: since we don't currently pack varyings, it is currently impossible
- * for the client to actually use up all of these binding table entries--if
- * all of their varyings were floats, they would run out of varying slots and
- * fail to link.  But that's a bug, so it seems prudent to go ahead and
- * allocate the number of binding table entries we will need once the bug is
- * fixed.
- */
-#define BRW_MAX_SOL_BINDINGS 64
-
 /** Maximum number of actual buffers used for stream output */
 #define BRW_MAX_SOL_BUFFERS 4
 
@@ -415,8 +390,6 @@ struct brw_ff_gs_prog_data {
 2 + /* shader time, pull constants */   \
 1 /* cs num work groups */)
 
-#define SURF_INDEX_GEN6_SOL_BINDING(t) (t)
-
 /**
  * Stride in bytes between shader_time entries.
  *
diff --git a/src/mesa/drivers/dri/i965/brw_ff_gs_emit.c 
b/src/mesa/drivers/dri/i965/brw_ff_gs_emit.c
index fea2b93..7a3e62a 100644
--- a/src/mesa/drivers/dri/i965/brw_ff_gs_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_ff_gs_emit.c
@@ -454,7 +454,7 @@ gen6_sol_program(struct brw_ff_gs_compile *c, struct 
brw_ff_gs_prog_key *key,
   final_write ? c->reg.temp : brw_null_reg(), /* dest 
*/
   1, /* msg_reg_nr */
   c->reg.header, /* src0 */
-  SURF_INDEX_GEN6_SOL_BINDING(binding), /* 
binding_table_index */
+

[Mesa-dev] [PATCH 05/24] i965: Move assign_common_binding_table_offsets to brw_program

[Jason Ekstrand]

This isn't used by Vulkan and is specific to the way the GL driver
works.  There's no reason to have it in common compiler code.  Also, it
relies on BRW_MAX_* defines which are defined in brw_context.h
---
 src/mesa/drivers/dri/i965/brw_program.c  | 87 
 src/mesa/drivers/dri/i965/brw_program.h  |  6 +++
 src/mesa/drivers/dri/i965/brw_shader.cpp | 87 
 src/mesa/drivers/dri/i965/brw_shader.h   |  6 ---
 4 files changed, 93 insertions(+), 93 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index 673dc502..fdd940d 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -706,3 +706,90 @@ brw_setup_tex_for_precompile(struct brw_context *brw,
   }
}
 }
+
+/**
+ * Sets up the starting offsets for the groups of binding table entries
+ * commong to all pipeline stages.
+ *
+ * Unused groups are initialized to 0xd0d0d0d0 to make it obvious that they're
+ * unused but also make sure that addition of small offsets to them will
+ * trigger some of our asserts that surface indices are < BRW_MAX_SURFACES.
+ */
+uint32_t
+brw_assign_common_binding_table_offsets(const struct gen_device_info *devinfo,
+const struct gl_program *prog,
+struct brw_stage_prog_data 
*stage_prog_data,
+uint32_t next_binding_table_offset)
+{
+   int num_textures = util_last_bit(prog->SamplersUsed);
+
+   stage_prog_data->binding_table.texture_start = next_binding_table_offset;
+   next_binding_table_offset += num_textures;
+
+   if (prog->info.num_ubos) {
+  assert(prog->info.num_ubos <= BRW_MAX_UBO);
+  stage_prog_data->binding_table.ubo_start = next_binding_table_offset;
+  next_binding_table_offset += prog->info.num_ubos;
+   } else {
+  stage_prog_data->binding_table.ubo_start = 0xd0d0d0d0;
+   }
+
+   if (prog->info.num_ssbos) {
+  assert(prog->info.num_ssbos <= BRW_MAX_SSBO);
+  stage_prog_data->binding_table.ssbo_start = next_binding_table_offset;
+  next_binding_table_offset += prog->info.num_ssbos;
+   } else {
+  stage_prog_data->binding_table.ssbo_start = 0xd0d0d0d0;
+   }
+
+   if (INTEL_DEBUG & DEBUG_SHADER_TIME) {
+  stage_prog_data->binding_table.shader_time_start = 
next_binding_table_offset;
+  next_binding_table_offset++;
+   } else {
+  stage_prog_data->binding_table.shader_time_start = 0xd0d0d0d0;
+   }
+
+   if (prog->nir->info->uses_texture_gather) {
+  if (devinfo->gen >= 8) {
+ stage_prog_data->binding_table.gather_texture_start =
+stage_prog_data->binding_table.texture_start;
+  } else {
+ stage_prog_data->binding_table.gather_texture_start = 
next_binding_table_offset;
+ next_binding_table_offset += num_textures;
+  }
+   } else {
+  stage_prog_data->binding_table.gather_texture_start = 0xd0d0d0d0;
+   }
+
+   if (prog->info.num_abos) {
+  stage_prog_data->binding_table.abo_start = next_binding_table_offset;
+  next_binding_table_offset += prog->info.num_abos;
+   } else {
+  stage_prog_data->binding_table.abo_start = 0xd0d0d0d0;
+   }
+
+   if (prog->info.num_images) {
+  stage_prog_data->binding_table.image_start = next_binding_table_offset;
+  next_binding_table_offset += prog->info.num_images;
+   } else {
+  stage_prog_data->binding_table.image_start = 0xd0d0d0d0;
+   }
+
+   /* This may or may not be used depending on how the compile goes. */
+   stage_prog_data->binding_table.pull_constants_start = 
next_binding_table_offset;
+   next_binding_table_offset++;
+
+   /* Plane 0 is just the regular texture section */
+   stage_prog_data->binding_table.plane_start[0] = 
stage_prog_data->binding_table.texture_start;
+
+   stage_prog_data->binding_table.plane_start[1] = next_binding_table_offset;
+   next_binding_table_offset += num_textures;
+
+   stage_prog_data->binding_table.plane_start[2] = next_binding_table_offset;
+   next_binding_table_offset += num_textures;
+
+   /* prog_data->base.binding_table.size will be set by brw_mark_surface_used. 
*/
+
+   assert(next_binding_table_offset <= BRW_MAX_SURFACES);
+   return next_binding_table_offset;
+}
diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
b/src/mesa/drivers/dri/i965/brw_program.h
index 6eda165..56dca1f 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -50,6 +50,12 @@ bool brw_debug_recompile_sampler_key(struct brw_context *brw,
  const struct brw_sampler_prog_key_data 
*key);
 void brw_add_texrect_params(struct gl_program *prog);
 
+uint32_t
+brw_assign_common_binding_table_offsets(const struct gen_device_info *devinfo,
+const struct gl_program *prog,
+struct brw_stage_prog_data 

[Mesa-dev] [PATCH 02/24] i965: Move some helpers from brw_context.h to brw_shader.h

[Jason Ekstrand]

---
 src/mesa/drivers/dri/i965/brw_compiler.c |  1 +
 src/mesa/drivers/dri/i965/brw_context.h  | 16 
 src/mesa/drivers/dri/i965/brw_shader.h   | 18 ++
 3 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compiler.c 
b/src/mesa/drivers/dri/i965/brw_compiler.c
index f3dafec..18ca444 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.c
+++ b/src/mesa/drivers/dri/i965/brw_compiler.c
@@ -23,6 +23,7 @@
 
 #include "brw_compiler.h"
 #include "brw_context.h"
+#include "brw_shader.h"
 #include "compiler/nir/nir.h"
 #include "main/errors.h"
 #include "util/debug.h"
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index c9a931c..eda5c32 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1330,12 +1330,6 @@ key_debug(struct brw_context *brw, const char *name, int 
a, int b)
 
 void brwInitFragProgFuncs( struct dd_function_table *functions );
 
-/* Per-thread scratch space is a power-of-two multiple of 1KB. */
-static inline int
-brw_get_scratch_size(int size)
-{
-   return MAX2(1024, util_next_power_of_two(size));
-}
 void brw_get_scratch_bo(struct brw_context *brw,
drm_intel_bo **scratch_bo, int size);
 void brw_alloc_stage_scratch(struct brw_context *brw,
@@ -1358,13 +1352,6 @@ void brw_upload_urb_fence(struct brw_context *brw);
  */
 void brw_upload_cs_urb_state(struct brw_context *brw);
 
-/* brw_fs_reg_allocate.cpp
- */
-void brw_fs_alloc_reg_sets(struct brw_compiler *compiler);
-
-/* brw_vec4_reg_allocate.cpp */
-void brw_vec4_alloc_reg_set(struct brw_compiler *compiler);
-
 /* brw_disasm.c */
 int brw_disassemble_inst(FILE *file, const struct gen_device_info *devinfo,
  struct brw_inst *inst, bool is_compacted);
@@ -1628,9 +1615,6 @@ brw_program_reloc(struct brw_context *brw, uint32_t 
state_offset,
 
 bool brw_do_cubemap_normalize(struct exec_list *instructions);
 
-extern const char * const conditional_modifier[16];
-extern const char *const pred_ctrl_align16[16];
-
 static inline bool
 brw_depth_writes_enabled(const struct brw_context *brw)
 {
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h 
b/src/mesa/drivers/dri/i965/brw_shader.h
index 60f498f..8cda6b2 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.h
+++ b/src/mesa/drivers/dri/i965/brw_shader.h
@@ -258,6 +258,24 @@ bool opt_predicated_break(struct backend_shader *s);
 extern "C" {
 #endif
 
+/* brw_fs_reg_allocate.cpp
+ */
+void brw_fs_alloc_reg_sets(struct brw_compiler *compiler);
+
+/* brw_vec4_reg_allocate.cpp */
+void brw_vec4_alloc_reg_set(struct brw_compiler *compiler);
+
+/* brw_disasm.c */
+extern const char * const conditional_modifier[16];
+extern const char *const pred_ctrl_align16[16];
+
+/* Per-thread scratch space is a power-of-two multiple of 1KB. */
+static inline int
+brw_get_scratch_size(int size)
+{
+   return MAX2(1024, util_next_power_of_two(size));
+}
+
 /**
  * Scratch data used when compiling a GLSL geometry shader.
  */
-- 
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] Vulkan: Add VK_ANDROID_native_buffer to device extension list

[Tapani Pälli]

On 03/01/2017 06:17 AM, Jason Ekstrand wrote:
On Tue, Feb 28, 2017 at 7:52 PM, Randy Xu > wrote:


The VK_ANDROID_native_buffer is implemented in Android Vulkan HAL,
not driver, but must be claimed in device extension list. Otherwise,
this extension will be screened off in framework and driver.


This seems rather odd.  Can't the Vulkan HAL just hook into 
vkEnumerateDeviceExtensionProperties and add it to the list there?  It 
seems a bit odd to advertise an extension but not actually provide any 
of the functionality.




This was my question as well. I proposed Randy to include functionality, 
at the moment it would be along these lines:


https://github.com/android-ia/external-mesa/commit/8b6b2fc4de933c03feba33e5b57c20262e7983cc

I don't have a strong preference where functionality exists but it seems 
like ideally the whole thing would exist in one single component. If the 
extension list cannot be modified in HAL then this becomes harder to 
achieve in HAL.



Test: Pass Vulkan dEQP-VK.wsi.android.swapchain.* on Android platform

Signed-off-by: Randy Xu >
---
Android.common.mk | 3 +++
 src/intel/vulkan/anv_device.c | 9 +
 2 files changed, 12 insertions(+)

diff --git a/Android.common.mk 
b/Android.common.mk 
index 611162a..f49189b 100644
--- a/Android.common.mk 
+++ b/Android.common.mk 
@@ -116,6 +116,9 @@ else
   LOCAL_CFLAGS +=
-DDEFAULT_DRIVER_DIR=\"/system/lib/$(MESA_DRI_MODULE_REL_PATH)\"
 endif

+# Enable VK_ANDROID_native_buffer
+LOCAL_CFLAGS += -DVK_USE_PLATFORM_ANDROID_KHR
+
 # uncomment to keep the debug symbols
 #LOCAL_STRIP_MODULE := false

diff --git a/src/intel/vulkan/anv_device.c
b/src/intel/vulkan/anv_device.c
index 0db96f2..478d753 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -258,6 +258,15 @@ static const VkExtensionProperties
device_extensions[] = {
   .extensionName = VK_KHR_MAINTENANCE1_EXTENSION_NAME,
   .specVersion = 1,
},
+#ifdef VK_USE_PLATFORM_ANDROID_KHR
+   {
+  // Refer
https://source.android.com/devices/graphics/implement-vulkan.html

+  // "Window System Integration (WSI) extensions are exported
by the loader
+  //  and primarily implemented in it rather than the driver."
+  .extensionName = "VK_ANDROID_native_buffer",


In the other places, we use the EXTENSION_NAME #define

+  .specVersion = 1,
+   },
+#endif
{
   .extensionName = VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME,
   .specVersion = 1,
--
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

[Mesa-dev] [PATCH 00/24] i965: Move the compiler to src/intel/compiler

[Jason Ekstrand]

This little series moves the i965 back-end compiler to src/intel/compiler.
It's not incredibly pretty; I didn't do as much header clean-up as perhaps
could have been done.  Anything that I didn't know what to do with I moved
to brw_shader or brw_program.  The second-to-last patch which shuffles the
header includes around is also one big patch.  It could be split up but
there didn't seem to be much of a point.

Jason Ekstrand (24):
  i965: Move a couple of #defines from brw_context to brw_compiler
  i965: Move some helpers from brw_context.h to brw_shader.h
  i965: Move brw_disassemble_inst to brw_eu.h
  i965: Move some gen4 WM defines to brw_compiler.h
  i965: Move assign_common_binding_table_offsets to brw_program
  i965/vue_map: Stop using GLbitfield types
  i965: Get rid of BRW_PRIM_OFFSET
  i965: Don't use MAX_SURFACES in mark_surface_used
  i965/gs: Add the gl_prim_to_hw_prim table to vec4_gs_visitor.cpp
  i964/gs: Move MAX_GS_INPUT_VERTICES to brw_vec4_gs_visitor.h
  i965: Move SOL binding #defines to brw_compiler.h
  i965: Move SHADER_TIME_STRIDE to brw_compiler.h
  i965: Move brw_register_blocks to brw_fs.cpp
  i965/inst: Stop using fi_type
  i965: Move BRW_MAX_DRAW_BUFFERS to brw_compiler.h
  i965: Move BRW_ATTRIB_WA_* defines to brw_compiler.h
  i965: Make mark_surface_used a static inline in brw_compiler.h
  i965: Move channel_expressions and vector_splitting to brw_program.h
  i965: Move image uniform setup to brw_nir_uniforms.cpp
  i965: Move a bunch of pre-compile and link stuff to brw_program.h
  i965: Add a header for brw_vec4_vs_visitor
  i965: Delete brw_do_cubemap_normalize
  i965: Reduce cross-pollination between the DRI driver and compiler
  i965: Move the back-end compiler to src/intel/compiler

 src/intel/Makefile.am  |   2 +
 src/intel/Makefile.compiler.am | 116 
 src/intel/Makefile.sources |  89 
 src/intel/blorp/blorp_priv.h   |   2 +-
 src/intel/compiler/.gitignore  |   1 +
 .../dri/i965 => intel/compiler}/brw_cfg.cpp|   0
 .../drivers/dri/i965 => intel/compiler}/brw_cfg.h  |   0
 .../dri/i965 => intel/compiler}/brw_compiler.c |   3 +-
 .../dri/i965 => intel/compiler}/brw_compiler.h | 116 +++-
 .../compiler}/brw_dead_control_flow.cpp|   0
 .../compiler}/brw_dead_control_flow.h  |   0
 .../dri/i965 => intel/compiler}/brw_disasm.c   |   3 +-
 .../drivers/dri/i965 => intel/compiler}/brw_eu.c   |   3 +-
 .../drivers/dri/i965 => intel/compiler}/brw_eu.h   |   2 +
 .../dri/i965 => intel/compiler}/brw_eu_compact.c   |   3 +-
 .../dri/i965 => intel/compiler}/brw_eu_emit.c  |   1 -
 .../dri/i965 => intel/compiler}/brw_eu_util.c  |   1 -
 .../dri/i965 => intel/compiler}/brw_eu_validate.c  |   0
 .../drivers/dri/i965 => intel/compiler}/brw_fs.cpp |  15 +-
 .../drivers/dri/i965 => intel/compiler}/brw_fs.h   |   3 -
 .../dri/i965 => intel/compiler}/brw_fs_builder.h   |   1 -
 .../compiler}/brw_fs_cmod_propagation.cpp  |   0
 .../compiler}/brw_fs_combine_constants.cpp |   0
 .../compiler}/brw_fs_copy_propagation.cpp  |   0
 .../dri/i965 => intel/compiler}/brw_fs_cse.cpp |   0
 .../compiler}/brw_fs_dead_code_eliminate.cpp   |   0
 .../i965 => intel/compiler}/brw_fs_generator.cpp   |   0
 .../compiler}/brw_fs_live_variables.cpp|   0
 .../compiler}/brw_fs_live_variables.h  |   0
 .../i965 => intel/compiler}/brw_fs_lower_d2x.cpp   |   0
 .../i965 => intel/compiler}/brw_fs_lower_pack.cpp  |   0
 .../dri/i965 => intel/compiler}/brw_fs_nir.cpp |   0
 .../compiler}/brw_fs_reg_allocate.cpp  |   0
 .../compiler}/brw_fs_register_coalesce.cpp |   0
 .../compiler}/brw_fs_saturate_propagation.cpp  |   0
 .../compiler}/brw_fs_sel_peephole.cpp  |   0
 .../compiler}/brw_fs_surface_builder.cpp   |   0
 .../compiler}/brw_fs_surface_builder.h |   1 -
 .../i965 => intel/compiler}/brw_fs_validate.cpp|   0
 .../dri/i965 => intel/compiler}/brw_fs_visitor.cpp |   0
 .../drivers/dri/i965 => intel/compiler}/brw_inst.h |  13 +-
 .../compiler}/brw_interpolation_map.c  |   1 -
 .../dri/i965 => intel/compiler}/brw_ir_allocator.h |   0
 .../dri/i965 => intel/compiler}/brw_ir_fs.h|   0
 .../dri/i965 => intel/compiler}/brw_ir_vec4.h  |   1 -
 .../drivers/dri/i965 => intel/compiler}/brw_nir.c  |   1 +
 .../drivers/dri/i965 => intel/compiler}/brw_nir.h  |   0
 .../compiler}/brw_nir_analyze_boolean_resolves.c   |   0
 .../compiler}/brw_nir_attribute_workarounds.c  |   1 -
 .../i965 => intel/compiler}/brw_nir_intrinsics.c   |   0
 .../compiler}/brw_nir_opt_peephole_ffma.c  |   0
 .../compiler}/brw_nir_tcs_workarounds.c|   0
 .../compiler}/brw_nir_trig_workarounds.py  |   0
 .../dri/i965 => intel/compiler}/brw_packed_float.c |   0
 

Re: [Mesa-dev] [PATCH 27/34] i965: Make CCS stride match kernel's expectations

[Ben Widawsky]

On 17-02-28 11:44:24, Jason Ekstrand wrote:

On Mon, Feb 27, 2017 at 7:23 PM, Ben Widawsky  wrote:


On 17-02-27 18:40:41, Jason Ekstrand wrote:


On Mon, Feb 27, 2017 at 5:38 PM, Jason Ekstrand 
wrote:

On Mon, Feb 27, 2017 at 4:56 PM, Ben Widawsky  wrote:


On 17-01-31 13:24:55, Jason Ekstrand wrote:


On Mon, Jan 23, 2017 at 10:21 PM, Ben Widawsky 

wrote:

v2: Put the commit message as a comment (Topi)



Cc: Topi Pohjolainen 
Cc: Ville Syrjälä 
Cc: Jason Ekstrand 
Signed-off-by: Ben Widawsky 
Acked-by: Daniel Stone 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 85070bb54d..12b3b071e4 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1023,7 +1023,10 @@ intel_from_planar(__DRIimage *parent, int
plane,
void *loaderPrivate)
 if (parent == NULL || parent->planar_format == NULL) {
if (is_aux) {
   offset = parent->aux_offset;
-  stride = ALIGN(parent->pitch / 32, 128);
+  /* Make CCS stride match kernel's expectations. Mesa's
internals
+   * expect: stride = ALIGN(parent->pitch / 32, 128)
+   */
+  stride = ALIGN(parent->pitch / 64, 128);


I just realized that this doesn't match the picture you drew in 22/32

where
the CCS and the main color surface have the same stride.



Here is the image, it seems correct to me. Is there some clarification
you'd
like me to make?

┌─┐
│ │
│ │
│ │
│  Image  │
│ │
│ │
│x│
├─┬───┘
│ │   |
│ccs  │  unused   |
└─┘---┘
<--pitch-->



This picture matches what you do for allocation.  You divide the main
surface height by 64 (rounded up) to get the CCS surface height in Y-tiled
lines which is correct.  Then you add this to the height of the primary
surface and pass that to libdrm.  The amount of data allocated for the ccs
is then DIV_ROUND_UP(color.height, 64) * color.pitch.  That is way more
than enough data but the waste isn't too bad so whatever.

In patch 19, we use ISL to compute the CCS layout and it picks whatever
stride it wants which, I believe, will be ALIGN(color.width, 1024) / 8.
(Note this calculation is done based on the width of the color surface, not
the stride)

Then, in this patch, we tell the client that the pitch is ALIGN(color.pitch
/ 64, 128).  There is a factor of two in here thanks to the current kernel
API, but it's also based on color.pitch not color.width so it's liable to
mismatch with ISL.

We have three different calculations for the CCS pitch in three different
places and no two of them match.

It's fine if the allocation doesn't match the others so long as it's it's
large enough.  The other two, however, need to match (with a possible
factor of 2 difference).

Is that making sense?

--Jason



Unfortunately not, the drawing still seems correct as it's not so specific to
have calculations. Please draw the picture how you think it should be drawn, and
let's ignore the factor of two issue (I separately responded we should just
submit stride in units of tiles). I'll gladly make the picture whatever you want
it to be.






Does the kernel expect the alignment to be 128 or 64?  Given that ville



likes 64-wide tiles, I think it should be 64.  Really, I think the more

accurate calculation would be

stride = ALIGN(parent->pitch, 4096) / 64;



Isn't the actual CCS stride stored in parent->strides[0]?  Why are we

re-computing it from the plane 0 pitch?



I believe the parent is just the parent image (ie. pixel data), in real
planar
images, we have the planes for the formats, but it's somewhat of a hack job
here. If I have this wrong, or you have a better idea, please let me know.




4096 is the stride in bytes in the primary surface required to cross a



single CCS tile.  The calculation you have above will work in the sense

that the worst that happens is for it to align up a bit too far.  In
any
case, what matters is that we a) have enough space and b) exactly match
the
kernel's calculation.

--Jason



This formula doesn't match the kernel's expectations (unless Ville has

updated
patches somewhere).



Hrm... Ok.  Having the alignment too big won't break anything, it's just
a
bit odd.


If you want I can do:

stride = ALIGN(parent->pitch, 4096) / 128;




 That' wouldn't match either.  Let's make sure the formulas match
exactly.




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

[Mesa-dev] [PATCH] vulkan/wsi: Improve the DRI3 error message

[Jacob Lifshay]

This commit improves the message by telling them that they could probably
enable DRI3.  More importantly, it includes a little heuristic to check
to see if we're running on AMD or NVIDIA's proprietary X11 drivers and,
if we are, doesn't emit the warning.  This way, users with both a discrete
card and Intel graphics don't get the warning when they're just running
on the discrete card.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99715
Co-authored-by: Jason Ekstrand 
Reviewed-by: Kai Wasserbäch 
Tested-by: Rene Lindsay 
---
 src/vulkan/wsi/wsi_common_x11.c | 51 +
 1 file changed, 41 insertions(+), 10 deletions(-)

diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index 64ba921..323209c 100644
--- a/src/vulkan/wsi/wsi_common_x11.c
+++ b/src/vulkan/wsi/wsi_common_x11.c
@@ -49,6 +49,7 @@
 struct wsi_x11_connection {
bool has_dri3;
bool has_present;
+   bool is_proprietary_x11;
 };
 
 struct wsi_x11 {
@@ -63,8 +64,8 @@ static struct wsi_x11_connection *
 wsi_x11_connection_create(const VkAllocationCallbacks *alloc,
   xcb_connection_t *conn)
 {
-   xcb_query_extension_cookie_t dri3_cookie, pres_cookie;
-   xcb_query_extension_reply_t *dri3_reply, *pres_reply;
+   xcb_query_extension_cookie_t dri3_cookie, pres_cookie, amd_cookie, 
nv_cookie;
+   xcb_query_extension_reply_t *dri3_reply, *pres_reply, *amd_reply, *nv_reply;
 
struct wsi_x11_connection *wsi_conn =
   vk_alloc(alloc, sizeof(*wsi_conn), 8,
@@ -75,20 +76,43 @@ wsi_x11_connection_create(const VkAllocationCallbacks 
*alloc,
dri3_cookie = xcb_query_extension(conn, 4, "DRI3");
pres_cookie = xcb_query_extension(conn, 7, "PRESENT");
 
+   /* We try to be nice to users and emit a warning if they try to use a
+* Vulkan application on a system without DRI3 enabled.  However, this ends
+* up spewing the warning when a user has, for example, both Intel
+* integrated graphics and a discrete card with proprietary drivers and are
+* running on the discrete card with the proprietary DDX.  In this case, we
+* really don't want to print the warning because it just confuses users.
+* As a heuristic to detect this case, we check for a couple of proprietary
+* X11 extensions.
+*/
+   amd_cookie = xcb_query_extension(conn, 11, "ATIFGLRXDRI");
+   nv_cookie = xcb_query_extension(conn, 10, "NV-CONTROL");
+
dri3_reply = xcb_query_extension_reply(conn, dri3_cookie, NULL);
pres_reply = xcb_query_extension_reply(conn, pres_cookie, NULL);
-   if (dri3_reply == NULL || pres_reply == NULL) {
+   amd_reply = xcb_query_extension_reply(conn, amd_cookie, NULL);
+   nv_reply = xcb_query_extension_reply(conn, nv_cookie, NULL);
+   if (!dri3_reply || !pres_reply) {
   free(dri3_reply);
   free(pres_reply);
+  free(amd_reply);
+  free(nv_reply);
   vk_free(alloc, wsi_conn);
   return NULL;
}
 
wsi_conn->has_dri3 = dri3_reply->present != 0;
wsi_conn->has_present = pres_reply->present != 0;
+   wsi_conn->is_proprietary_x11 = false;
+   if (amd_reply && amd_reply->present)
+  wsi_conn->is_proprietary_x11 = true;
+   if (nv_reply && nv_reply->present)
+  wsi_conn->is_proprietary_x11 = true;
 
free(dri3_reply);
free(pres_reply);
+   free(amd_reply);
+   free(nv_reply);
 
return wsi_conn;
 }
@@ -100,6 +124,18 @@ wsi_x11_connection_destroy(const VkAllocationCallbacks 
*alloc,
vk_free(alloc, conn);
 }
 
+static bool
+wsi_x11_check_for_dri3(struct wsi_x11_connection *wsi_conn)
+{
+  if (wsi_conn->has_dri3)
+return true;
+  if (!wsi_conn->is_proprietary_x11) {
+fprintf(stderr, "vulkan: No DRI3 support detected - required for 
presentation\n"
+"Note: you can probably enable DRI3 in your Xorg 
config\n");
+  }
+  return false;
+}
+
 static struct wsi_x11_connection *
 wsi_x11_get_connection(struct wsi_device *wsi_dev,
   const VkAllocationCallbacks *alloc,
@@ -264,11 +300,8 @@ VkBool32 wsi_get_physical_device_xcb_presentation_support(
if (!wsi_conn)
   return false;
 
-   if (!wsi_conn->has_dri3) {
-  fprintf(stderr, "vulkan: No DRI3 support detected - required for 
presentation\n");
-  fprintf(stderr, "Note: Buggy applications may crash, if they do please 
report to vendor\n");
+   if (!wsi_x11_check_for_dri3(wsi_conn))
   return false;
-   }
 
unsigned visual_depth;
if (!connection_get_visualtype(connection, visual_id, _depth))
@@ -313,9 +346,7 @@ x11_surface_get_support(VkIcdSurfaceBase *icd_surface,
if (!wsi_conn)
   return VK_ERROR_OUT_OF_HOST_MEMORY;
 
-   if (!wsi_conn->has_dri3) {
-  fprintf(stderr, "vulkan: No DRI3 support detected - required for 
presentation\n");
-  fprintf(stderr, "Note: Buggy applications may crash, if they do please 
report to vendor\n");
+   if 

Re: [Mesa-dev] [PATCH] Vulkan: Add VK_ANDROID_native_buffer to device extension list

[Xu, Randy]

Hi, Jason

The device_extensions array is used to screen the ppEnabledExtensionNames in 
vkCreateDevice. The Android app passes the VK_ANDROID_native_buffer and will 
cause VK_ERROR_EXTENSION_NOT_PRESENT error w/o this patch.

Btw, anv_CreateDevice function is called by Android Vulkan framework through 
dispatch table directly, not intercepted by Vulkan HAL.

VkResult anv_CreateDevice(
VkPhysicalDevicephysicalDevice,
const VkDeviceCreateInfo*   pCreateInfo,
const VkAllocationCallbacks*pAllocator,
VkDevice*   pDevice)
{
   ANV_FROM_HANDLE(anv_physical_device, physical_device, physicalDevice);
   VkResult result;
   struct anv_device *device;

   assert(pCreateInfo->sType == VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO);

   for (uint32_t i = 0; i < pCreateInfo->enabledExtensionCount; i++) {
  bool found = false;
  for (uint32_t j = 0; j < ARRAY_SIZE(device_extensions); j++) {
 if (strcmp(pCreateInfo->ppEnabledExtensionNames[i],
device_extensions[j].extensionName) == 0) {
found = true;
break;
 }
  }
  if (!found)
 return vk_error(VK_ERROR_EXTENSION_NOT_PRESENT);
   }

Thanks,
Randy
From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Wednesday, March 1, 2017 12:17 PM
To: Xu, Randy 
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] Vulkan: Add VK_ANDROID_native_buffer to device 
extension list

On Tue, Feb 28, 2017 at 7:52 PM, Randy Xu 
> wrote:
The VK_ANDROID_native_buffer is implemented in Android Vulkan HAL,
not driver, but must be claimed in device extension list. Otherwise,
this extension will be screened off in framework and driver.

This seems rather odd.  Can't the Vulkan HAL just hook into 
vkEnumerateDeviceExtensionProperties and add it to the list there?  It seems a 
bit odd to advertise an extension but not actually provide any of the 
functionality.
Test: Pass Vulkan dEQP-VK.wsi.android.swapchain.* on Android platform

Signed-off-by: Randy Xu >
---
 Android.common.mk | 3 +++
 src/intel/vulkan/anv_device.c | 9 +
 2 files changed, 12 insertions(+)

diff --git a/Android.common.mk 
b/Android.common.mk
index 611162a..f49189b 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -116,6 +116,9 @@ else
   LOCAL_CFLAGS += 
-DDEFAULT_DRIVER_DIR=\"/system/lib/$(MESA_DRI_MODULE_REL_PATH)\"
 endif

+# Enable VK_ANDROID_native_buffer
+LOCAL_CFLAGS += -DVK_USE_PLATFORM_ANDROID_KHR
+
 # uncomment to keep the debug symbols
 #LOCAL_STRIP_MODULE := false

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 0db96f2..478d753 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -258,6 +258,15 @@ static const VkExtensionProperties device_extensions[] = {
   .extensionName = VK_KHR_MAINTENANCE1_EXTENSION_NAME,
   .specVersion = 1,
},
+#ifdef VK_USE_PLATFORM_ANDROID_KHR
+   {
+  // Refer 
https://source.android.com/devices/graphics/implement-vulkan.html
+  // "Window System Integration (WSI) extensions are exported by the loader
+  //  and primarily implemented in it rather than the driver."
+  .extensionName = "VK_ANDROID_native_buffer",

In the other places, we use the EXTENSION_NAME #define

+  .specVersion = 1,
+   },
+#endif
{
   .extensionName = VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME,
   .specVersion = 1,
--
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] Vulkan: Add VK_ANDROID_native_buffer to device extension list

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 7:52 PM, Randy Xu  wrote:

> The VK_ANDROID_native_buffer is implemented in Android Vulkan HAL,
> not driver, but must be claimed in device extension list. Otherwise,
> this extension will be screened off in framework and driver.
>

This seems rather odd.  Can't the Vulkan HAL just hook into
vkEnumerateDeviceExtensionProperties and add it to the list there?  It
seems a bit odd to advertise an extension but not actually provide any of
the functionality.

Test: Pass Vulkan dEQP-VK.wsi.android.swapchain.* on Android platform
>
> Signed-off-by: Randy Xu 
> ---
>  Android.common.mk | 3 +++
>  src/intel/vulkan/anv_device.c | 9 +
>  2 files changed, 12 insertions(+)
>
> diff --git a/Android.common.mk b/Android.common.mk
> index 611162a..f49189b 100644
> --- a/Android.common.mk
> +++ b/Android.common.mk
> @@ -116,6 +116,9 @@ else
>LOCAL_CFLAGS += -DDEFAULT_DRIVER_DIR=\"/system/lib/$(MESA_DRI_MODULE_
> REL_PATH)\"
>  endif
>
> +# Enable VK_ANDROID_native_buffer
> +LOCAL_CFLAGS += -DVK_USE_PLATFORM_ANDROID_KHR
> +
>  # uncomment to keep the debug symbols
>  #LOCAL_STRIP_MODULE := false
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 0db96f2..478d753 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -258,6 +258,15 @@ static const VkExtensionProperties
> device_extensions[] = {
>.extensionName = VK_KHR_MAINTENANCE1_EXTENSION_NAME,
>.specVersion = 1,
> },
> +#ifdef VK_USE_PLATFORM_ANDROID_KHR
> +   {
> +  // Refer https://source.android.com/devices/graphics/implement-
> vulkan.html
> +  // "Window System Integration (WSI) extensions are exported by the
> loader
> +  //  and primarily implemented in it rather than the driver."
> +  .extensionName = "VK_ANDROID_native_buffer",
>

In the other places, we use the EXTENSION_NAME #define


> +  .specVersion = 1,
> +   },
> +#endif
> {
>.extensionName = VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME,
>.specVersion = 1,
> --
> 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] [PATCH] Vulkan: Add VK_ANDROID_native_buffer to device extension list

[Randy Xu]

The VK_ANDROID_native_buffer is implemented in Android Vulkan HAL,
not driver, but must be claimed in device extension list. Otherwise,
this extension will be screened off in framework and driver.

Test: Pass Vulkan dEQP-VK.wsi.android.swapchain.* on Android platform

Signed-off-by: Randy Xu 
---
 Android.common.mk | 3 +++
 src/intel/vulkan/anv_device.c | 9 +
 2 files changed, 12 insertions(+)

diff --git a/Android.common.mk b/Android.common.mk
index 611162a..f49189b 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -116,6 +116,9 @@ else
   LOCAL_CFLAGS += 
-DDEFAULT_DRIVER_DIR=\"/system/lib/$(MESA_DRI_MODULE_REL_PATH)\"
 endif
 
+# Enable VK_ANDROID_native_buffer
+LOCAL_CFLAGS += -DVK_USE_PLATFORM_ANDROID_KHR
+
 # uncomment to keep the debug symbols
 #LOCAL_STRIP_MODULE := false
 
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 0db96f2..478d753 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -258,6 +258,15 @@ static const VkExtensionProperties device_extensions[] = {
   .extensionName = VK_KHR_MAINTENANCE1_EXTENSION_NAME,
   .specVersion = 1,
},
+#ifdef VK_USE_PLATFORM_ANDROID_KHR
+   {
+  // Refer 
https://source.android.com/devices/graphics/implement-vulkan.html
+  // "Window System Integration (WSI) extensions are exported by the loader
+  //  and primarily implemented in it rather than the driver."
+  .extensionName = "VK_ANDROID_native_buffer",
+  .specVersion = 1,
+   },
+#endif
{
   .extensionName = VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME,
   .specVersion = 1,
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] automake: r600: radeonsi: correctly manage libamd_common.la linking

[Michel Dänzer]

On 28/02/17 08:08 PM, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Since both r600 and radeonsi use code from libamd_common they need to
> static link it. At the same time, adding a common library to LIB_DEPS is
> fragile [can lean to multiple symbol definitions] and non-obvious - I
> had to do a double-take how things work atm.
> 
> So follow the libradeon.la approach and put common libraries in
> TARGET_RADEON_COMMON
> 
> Fixes: 936f5407a7d ("gallium/radeon: Add libamd_common.a to TARGET_LIB_DEPS 
> also for r600")
> Cc: Michel Dänzer 
> Cc: Timothy Arceri 
> Signed-off-by: Emil Velikov 
> ---
> It's been a while since I looked in the area, yet I really should have
> seen it coming.
> ---
>  src/gallium/drivers/r600/Automake.inc | 6 +++---
>  src/gallium/drivers/radeonsi/Automake.inc | 3 ++-
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/Automake.inc 
> b/src/gallium/drivers/r600/Automake.inc
> index 5995433ce9..3ff5501d6c 100644
> --- a/src/gallium/drivers/r600/Automake.inc
> +++ b/src/gallium/drivers/r600/Automake.inc
> @@ -13,9 +13,9 @@ TARGET_RADEON_WINSYS = \
>  TARGET_RADEON_COMMON = \
>   $(top_builddir)/src/gallium/drivers/radeon/libradeon.la
>  
> +if NEED_RADEON_LLVM
> +TARGET_RADEON_COMMON += \
> + $(top_builddir)/src/amd/common/libamd_common.la
>  endif
>  
> -if NEED_RADEON_LLVM
> -TARGET_LIB_DEPS += \
> -$(top_builddir)/src/amd/common/libamd_common.la
>  endif
> diff --git a/src/gallium/drivers/radeonsi/Automake.inc 
> b/src/gallium/drivers/radeonsi/Automake.inc
> index 5a9dcfd9fd..1bc7b93f8c 100644
> --- a/src/gallium/drivers/radeonsi/Automake.inc
> +++ b/src/gallium/drivers/radeonsi/Automake.inc
> @@ -13,6 +13,7 @@ TARGET_RADEON_WINSYS = \
>   $(top_builddir)/src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.la
>  
>  TARGET_RADEON_COMMON = \
> - $(top_builddir)/src/gallium/drivers/radeon/libradeon.la
> + $(top_builddir)/src/gallium/drivers/radeon/libradeon.la \
> + $(top_builddir)/src/amd/common/libamd_common.la
>  
>  endif
> 

Hmm, TARGET_LIB_DEPS gets used in all the same places as
TARGET_RADEON_COMMON AFAICT, so I guess TARGET_LIB_DEPS is otherwise
used by automake or special somehow? Anyway,

Reviewed-and-Tested-by: Michel Dänzer 


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

[Mesa-dev] [PATCH] egl: Ensure ResetNotificationStrategy matches for shared contexts.

[Kenneth Graunke]

Fixes:
dEQP-EGL.functional.robustness.negative_context.invalid_robust_shared_context_creation

Signed-off-by: Kenneth Graunke 
---
 src/egl/drivers/dri2/egl_dri2.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 94b7c201707..4bab6f1c5e2 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1102,6 +1102,20 @@ dri2_create_context(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLConfig *conf,
if (!_eglInitContext(_ctx->base, disp, conf, attrib_list))
   goto cleanup;
 
+   /* The EGL_EXT_create_context_robustness spec says:
+*
+*"Add to the eglCreateContext context creation errors: [...]
+*
+* * If the reset notification behavior of  and the
+*   newly created context are different then an EGL_BAD_MATCH error is
+*   generated."
+*/
+   if (share_list && share_list->ResetNotificationStrategy !=
+ dri2_ctx->base.ResetNotificationStrategy) {
+  _eglError(EGL_BAD_MATCH, "eglCreateContext");
+  goto cleanup;
+   }
+
switch (dri2_ctx->base.ClientAPI) {
case EGL_OPENGL_ES_API:
   switch (dri2_ctx->base.ClientMajorVersion) {
-- 
2.11.1

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

[Mesa-dev] [Bug 99987] Mesa 13+ breaks Xvnc (and similar X servers)

[bugzilla-daemon]

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

--- Comment #2 from Emil Velikov  ---
I would suggest building mesa w/o the glvnd stuff and ensuring the mesa
libGL/friends are picked.

That aside it seems similar to bug 99027 ? Admittedly I've got limited
experience with !Xorg so if you think any of my analysis is off please shout.

-- 
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] i965: Fix symbolic size of next_offset[] array.

[Kenneth Graunke]

It's indexed by buffer, not stream.  BRW_MAX_SOL_BUFFERS and
MAX_VERTEX_STREAMS happen to both be 4, so there's no actual bug.

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

diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c 
b/src/mesa/drivers/dri/i965/gen7_sol_state.c
index d3dcf49a36d..ca96da5d9e5 100644
--- a/src/mesa/drivers/dri/i965/gen7_sol_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_sol_state.c
@@ -106,7 +106,7 @@ gen7_upload_3dstate_so_decl_list(struct brw_context *brw,
   xfb_obj->program->sh.LinkedTransformFeedback;
uint16_t so_decl[MAX_VERTEX_STREAMS][128];
int buffer_mask[MAX_VERTEX_STREAMS] = {0, 0, 0, 0};
-   int next_offset[MAX_VERTEX_STREAMS] = {0, 0, 0, 0};
+   int next_offset[BRW_MAX_SOL_BUFFERS] = {0, 0, 0, 0};
int decls[MAX_VERTEX_STREAMS] = {0, 0, 0, 0};
int max_decls = 0;
STATIC_ASSERT(ARRAY_SIZE(so_decl[0]) >= MAX_PROGRAM_OUTPUTS);
-- 
2.11.1

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

Re: [Mesa-dev] [PATCH] android: vulkan: add support for libmesa_vulkan_{util, wsi}

[Eric Engestrom]

On Tuesday, 2017-02-28 18:18:01 +, Emil Velikov wrote:
> On 28 February 2017 at 16:05, Eric Engestrom  
> wrote:
> 
> >> > The quick and dirty fix is to add a rule forcing the serialisation, like
> >> > this:
> >> >   util/vk_enum_to_str.c: util/vk_enum_to_str.h
> >> > This fixes the race condition, but still writes both files twice for no
> >> > reason.
> >> >
> >> Are you sure that will generate them twice - can you elaborate a bit ?
> >
> > You can try it yourself with this makefile:
> > 8<
> > all: foo bar
> > foo bar:
> > echo $@
> > >8
> >
> > $ make
> > echo foo
> > foo
> > echo bar
> > bar
> >
> > It runs both targets, regardless of the fact they have the same rule.
> >
> I was wondering about the "foo.c: bar.h" case, like below.

Oh sorry, I misread that.

> 
> 8<
> all: foo.c bar.h
> 
> bar.h:
> @echo $@
> 
> foo.c: bar.h
> >8
> 
> $make -f foo
> bar.h
> 
> It does it once on my end. Perhaps I'm missing something ?

Yeah that works, since only one of the target has an actual build rule.

Still has the downside of having to figure out the target filename again
in the script instead of just passing it through, but I guess I'm the
only one who cares about that kind of things ;P

Anyway, like I said: any of these solutions are good enough for me.

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

Re: [Mesa-dev] [PATCH 5/7] anv: Implement VK_KHX_external_memory_capabilities (v2)

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 2:38 PM, Jason Ekstrand 
wrote:

> On Tue, Feb 28, 2017 at 10:58 AM, Chad Versace 
> wrote:
>
>> This is a complete but trivial implementation. It's trivial becasue We
>> support no external memory capabilities yet.  Most of the real work in
>> this commit is in reworking the UUIDs advertised by the driver.
>>
>> v2 (chadv):
>>   - Fix chain traversal in vkGetPhysicalDeviceImageFormatProperties2KHR.
>> Extract VkPhysicalDeviceExternalImageFormatInfoKHX from the chain of
>> input structs, not the chain of output structs.
>>   - In vkGetPhysicalDeviceImageFormatProperties2KHR, iterate over the
>> input chain and the output chain separately. Reduces diff in future
>> dma_buf patches.
>>
>> Co-authored-with: Jason Ekstrand 
>> ---
>>
>> On my branch wip/anv-external-memory.
>>   http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=wip/anv-external-memory
>>
>>  src/intel/vulkan/anv_device.c   | 53 ---
>>  src/intel/vulkan/anv_entrypoints_gen.py |  1 +
>>  src/intel/vulkan/anv_formats.c  | 75
>> +
>>  src/intel/vulkan/anv_private.h  |  2 +
>>  4 files changed, 117 insertions(+), 14 deletions(-)
>>
>> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.
>> c
>> index 3609670b348..9ee2e02ed51 100644
>> --- a/src/intel/vulkan/anv_device.c
>> +++ b/src/intel/vulkan/anv_device.c
>> @@ -74,11 +74,37 @@ anv_physical_device_init_uuids(struct
>> anv_physical_device *device)
>> if (sha1_ctx == NULL)
>>return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
>>
>> +   /* The pipeline cache UUID is used for determining when a pipeline
>> cache is
>> +* invalid.  It needs both a driver build and the PCI ID of the
>> device.
>> +*/
>> _mesa_sha1_update(sha1_ctx, build_id_data(note), build_id_len);
>> _mesa_sha1_update(sha1_ctx, >chipset_id,
>> sizeof(device->chipset_id));
>> _mesa_sha1_final(sha1_ctx, sha1);
>> memcpy(device->pipeline_cache_uuid, sha1, VK_UUID_SIZE);
>>
>> +   /* The driver UUID is used for determining sharability of images and
>> memory
>> +* between two Vulkan instances in separate processes.  People who
>> want to
>> +* share memory need to also check the device UUID (below) so all this
>> +* needs to be is the build-id.
>> +*/
>> +   memcpy(device->driver_uuid, build_id_data(note), VK_UUID_SIZE);
>> +
>> +   sha1_ctx = _mesa_sha1_init();
>> +   if (sha1_ctx == NULL)
>> +  return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
>> +
>> +   /* The device UUID uniquely identifies the given device within the
>> machine.
>> +* Since we never have more than one device, this doesn't need to be
>> a real
>> +* UUID.  However, on the off-chance that someone tries to use this to
>> +* cache pre-tiled images or something of the like, we use the PCI ID
>> and
>> +* some bits if ISL info to ensure that this is safe.
>> +*/
>> +   _mesa_sha1_update(sha1_ctx, >chipset_id,
>> sizeof(device->chipset_id));
>> +   _mesa_sha1_update(sha1_ctx, >isl_dev.has_bit6_swizzling,
>> + sizeof(device->isl_dev.has_bit6_swizzling));
>> +   _mesa_sha1_final(sha1_ctx, sha1);
>> +   memcpy(device->device_uuid, sha1, VK_UUID_SIZE);
>> +
>> return VK_SUCCESS;
>>  }
>>
>> @@ -163,10 +189,6 @@ anv_physical_device_init(struct anv_physical_device
>> *device,
>>goto fail;
>> }
>>
>> -   result = anv_physical_device_init_uuids(device);
>> -   if (result != VK_SUCCESS)
>> -  goto fail;
>> -
>> bool swizzled = anv_gem_get_bit6_swizzle(fd, I915_TILING_X);
>>
>> /* GENs prior to 8 do not support EU/Subslice info */
>> @@ -206,14 +228,18 @@ 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;
>>
>> +   isl_device_init(>isl_dev, >info, swizzled);
>> +
>> +   result = anv_physical_device_init_uuids(device);
>> +   if (result != VK_SUCCESS)
>> +  goto fail;
>> +
>> result = anv_init_wsi(device);
>> if (result != VK_SUCCESS) {
>>ralloc_free(device->compiler);
>>goto fail;
>> }
>>
>> -   isl_device_init(>isl_dev, >info, swizzled);
>> -
>> device->local_fd = fd;
>> return VK_SUCCESS;
>>
>> @@ -257,6 +283,10 @@ static const VkExtensionProperties
>> global_extensions[] = {
>>.extensionName = VK_KHR_GET_PHYSICAL_DEVICE_PRO
>> PERTIES_2_EXTENSION_NAME,
>>.specVersion = 1,
>> },
>> +   {
>> +  .extensionName = VK_KHX_EXTERNAL_MEMORY_CAPABIL
>> ITIES_EXTENSION_NAME,
>> +  .specVersion = 1,
>> +   },
>>  };
>>
>>  static const VkExtensionProperties device_extensions[] = {
>> @@ -668,10 +698,21 @@ void anv_GetPhysicalDeviceProperties2KHR(
>>  VkPhysicalDevicephysicalDevice,
>>  VkPhysicalDeviceProperties2KHR* 

[Mesa-dev] [PATCH v2] glsl: remove unecessary flags.q.subroutine_def

[Samuel Pitoiset]

This bit is definitely not necessary because subroutine_list
can be used instead. This frees one more bit in the flags.q
struct which is nice because arb_bindless_texture will need
4 bits for the new layout qualifiers.

No piglit regressions found (including compiler tests) with
"-t subroutine".

v2: set the subroutine flag for validating illegal flags

Signed-off-by: Samuel Pitoiset 
---
 src/compiler/glsl/ast.h  | 1 -
 src/compiler/glsl/ast_to_hir.cpp | 6 +++---
 src/compiler/glsl/ast_type.cpp   | 6 ++
 src/compiler/glsl/glsl_parser.yy | 2 +-
 src/compiler/glsl/glsl_parser_extras.cpp | 2 +-
 5 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
index 11a092e41c..d27b940744 100644
--- a/src/compiler/glsl/ast.h
+++ b/src/compiler/glsl/ast.h
@@ -607,7 +607,6 @@ struct ast_type_qualifier {
  /** \name Qualifiers for GL_ARB_shader_subroutine */
 /** \{ */
  unsigned subroutine:1;  /**< Is this marked 'subroutine' */
- unsigned subroutine_def:1; /**< Is this marked 'subroutine' with a 
list of types */
 /** \} */
 
  /** \name Qualifiers for GL_KHR_blend_equation_advanced */
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 0c00585a05..a90813033f 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -3510,7 +3510,7 @@ apply_layout_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
  }
   }
} else if (qual->flags.q.explicit_index) {
-  if (!qual->flags.q.subroutine_def)
+  if (!qual->subroutine_list)
  _mesa_glsl_error(loc, state,
   "explicit index requires explicit location");
} else if (qual->flags.q.explicit_component) {
@@ -5576,7 +5576,7 @@ ast_function::hir(exec_list *instructions,
 *  "Subroutine declarations cannot be prototyped. It is an error to prepend
 *   subroutine(...) to a function declaration."
 */
-   if (this->return_type->qualifier.flags.q.subroutine_def && !is_definition) {
+   if (this->return_type->qualifier.subroutine_list && !is_definition) {
   YYLTYPE loc = this->get_location();
   _mesa_glsl_error(, state,
"function declaration `%s' cannot have subroutine 
prepended",
@@ -5724,7 +5724,7 @@ ast_function::hir(exec_list *instructions,
sig->replace_parameters(_parameters);
signature = sig;
 
-   if (this->return_type->qualifier.flags.q.subroutine_def) {
+   if (this->return_type->qualifier.subroutine_list) {
   int idx;
 
   if (this->return_type->qualifier.flags.q.explicit_index) {
diff --git a/src/compiler/glsl/ast_type.cpp b/src/compiler/glsl/ast_type.cpp
index 96d20c10af..5f868a81f2 100644
--- a/src/compiler/glsl/ast_type.cpp
+++ b/src/compiler/glsl/ast_type.cpp
@@ -44,7 +44,6 @@ 
ast_fully_specified_type::has_qualifiers(_mesa_glsl_parse_state *state) const
ast_type_qualifier subroutine_only;
subroutine_only.flags.i = 0;
subroutine_only.flags.q.subroutine = 1;
-   subroutine_only.flags.q.subroutine_def = 1;
if (state->has_explicit_uniform_location()) {
   subroutine_only.flags.q.explicit_index = 1;
}
@@ -285,8 +284,8 @@ ast_type_qualifier::merge_qualifier(YYLTYPE *loc,
   }
}
 
-   if (q.flags.q.subroutine_def) {
-  if (this->flags.q.subroutine_def) {
+   if (q.subroutine_list) {
+  if (this->subroutine_list) {
  _mesa_glsl_error(loc, state,
   "conflicting subroutine qualifiers used");
   } else {
@@ -772,7 +771,6 @@ ast_type_qualifier::validate_flags(YYLTYPE *loc,
 bad.flags.q.point_mode ? " point_mode" : "",
 bad.flags.q.vertices ? " vertices" : "",
 bad.flags.q.subroutine ? " subroutine" : "",
-bad.flags.q.subroutine_def ? " subroutine_def" : "",
 bad.flags.q.blend_support ? " blend_support" : "",
 bad.flags.q.inner_coverage ? " inner_coverage" : "",
 bad.flags.q.post_depth_coverage ? " post_depth_coverage" : 
"");
diff --git a/src/compiler/glsl/glsl_parser.yy b/src/compiler/glsl/glsl_parser.yy
index d703f8..59453d72f6 100644
--- a/src/compiler/glsl/glsl_parser.yy
+++ b/src/compiler/glsl/glsl_parser.yy
@@ -1812,7 +1812,7 @@ subroutine_qualifier:
| SUBROUTINE '(' subroutine_type_list ')'
{
   memset(& $$, 0, sizeof($$));
-  $$.flags.q.subroutine_def = 1;
+  $$.flags.q.subroutine = 1;
   $$.subroutine_list = $3;
}
;
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index 375a99a49d..e88dd071b3 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -1075,7 +1075,7 @@ _mesa_ast_type_qualifier_print(const struct 
ast_type_qualifier *q)
if (q->flags.q.subroutine)
 

Re: [Mesa-dev] [PATCH] glsl: remove unecessary flags.q.subroutine_def

[Samuel Pitoiset]

On 03/01/2017 12:04 AM, Timothy Arceri wrote:

On 01/03/17 03:57, Samuel Pitoiset wrote:



On 02/26/2017 10:19 PM, Timothy Arceri wrote:



On 25/02/17 22:15, Samuel Pitoiset wrote:

This bit is definitely not necessary because subroutine_list
can be used instead. This frees one more bit in the flags.q
struct which is nice because arb_bindless_texture will need
4 bits for the new layout qualifiers.

No piglit regressions found (including compiler tests) with
"-t subroutine".

Signed-off-by: Samuel Pitoiset 
---
 src/compiler/glsl/ast.h  | 1 -
 src/compiler/glsl/ast_to_hir.cpp | 6 +++---
 src/compiler/glsl/ast_type.cpp   | 6 ++
 src/compiler/glsl/glsl_parser.yy | 1 -
 src/compiler/glsl/glsl_parser_extras.cpp | 2 +-
 5 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
index 11a092e41c..d27b940744 100644
--- a/src/compiler/glsl/ast.h
+++ b/src/compiler/glsl/ast.h
@@ -607,7 +607,6 @@ struct ast_type_qualifier {
  /** \name Qualifiers for GL_ARB_shader_subroutine */
  /** \{ */
  unsigned subroutine:1;  /**< Is this marked 'subroutine' */
- unsigned subroutine_def:1; /**< Is this marked 'subroutine'
with a list of types */
  /** \} */

  /** \name Qualifiers for GL_KHR_blend_equation_advanced */
diff --git a/src/compiler/glsl/ast_to_hir.cpp
b/src/compiler/glsl/ast_to_hir.cpp
index f033d7df97..7e99faeaed 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -3510,7 +3510,7 @@ apply_layout_qualifier_to_variable(const struct
ast_type_qualifier *qual,
  }
   }
} else if (qual->flags.q.explicit_index) {
-  if (!qual->flags.q.subroutine_def)
+  if (!qual->subroutine_list)
  _mesa_glsl_error(loc, state,
   "explicit index requires explicit
location");
} else if (qual->flags.q.explicit_component) {
@@ -5568,7 +5568,7 @@ ast_function::hir(exec_list *instructions,
 *  "Subroutine declarations cannot be prototyped. It is an error
to prepend
 *   subroutine(...) to a function declaration."
 */
-   if (this->return_type->qualifier.flags.q.subroutine_def &&
!is_definition) {
+   if (this->return_type->qualifier.subroutine_list &&
!is_definition) {
   YYLTYPE loc = this->get_location();
   _mesa_glsl_error(, state,
"function declaration `%s' cannot have
subroutine prepended",
@@ -5716,7 +5716,7 @@ ast_function::hir(exec_list *instructions,
sig->replace_parameters(_parameters);
signature = sig;

-   if (this->return_type->qualifier.flags.q.subroutine_def) {
+   if (this->return_type->qualifier.subroutine_list) {
   int idx;

   if (this->return_type->qualifier.flags.q.explicit_index) {
diff --git a/src/compiler/glsl/ast_type.cpp
b/src/compiler/glsl/ast_type.cpp
index 96d20c10af..5f868a81f2 100644
--- a/src/compiler/glsl/ast_type.cpp
+++ b/src/compiler/glsl/ast_type.cpp
@@ -44,7 +44,6 @@
ast_fully_specified_type::has_qualifiers(_mesa_glsl_parse_state
*state) const
ast_type_qualifier subroutine_only;
subroutine_only.flags.i = 0;
subroutine_only.flags.q.subroutine = 1;
-   subroutine_only.flags.q.subroutine_def = 1;
if (state->has_explicit_uniform_location()) {
   subroutine_only.flags.q.explicit_index = 1;
}
@@ -285,8 +284,8 @@ ast_type_qualifier::merge_qualifier(YYLTYPE *loc,
   }
}

-   if (q.flags.q.subroutine_def) {
-  if (this->flags.q.subroutine_def) {
+   if (q.subroutine_list) {
+  if (this->subroutine_list) {
  _mesa_glsl_error(loc, state,
   "conflicting subroutine qualifiers used");
   } else {
@@ -772,7 +771,6 @@ ast_type_qualifier::validate_flags(YYLTYPE *loc,
 bad.flags.q.point_mode ? " point_mode" : "",
 bad.flags.q.vertices ? " vertices" : "",
 bad.flags.q.subroutine ? " subroutine" : "",
-bad.flags.q.subroutine_def ? " subroutine_def" :
"",
 bad.flags.q.blend_support ? " blend_support" : "",
 bad.flags.q.inner_coverage ? " inner_coverage" :
"",
 bad.flags.q.post_depth_coverage ? "
post_depth_coverage" : "");
diff --git a/src/compiler/glsl/glsl_parser.yy
b/src/compiler/glsl/glsl_parser.yy
index d703f8..b79fcee550 100644
--- a/src/compiler/glsl/glsl_parser.yy
+++ b/src/compiler/glsl/glsl_parser.yy
@@ -1812,7 +1812,6 @@ subroutine_qualifier:
| SUBROUTINE '(' subroutine_type_list ')'
{
   memset(& $$, 0, sizeof($$));
-  $$.flags.q.subroutine_def = 1;


You need to change this to:

   $$.flags.q.subroutine = 1;

Otherwise we won't detect if the qualifier was added when it should have
been etc.


Are you sure it's needed to set it up? I thought it was enough to only
set $$.subroutine_list.


Sorry I should have been more clear. I mean the function that make use

Re: [Mesa-dev] [PATCH 7/9] anv: Implement VK_KHX_external_semaphore_fd

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 3:04 PM, Chris Wilson 
wrote:

> On Tue, Feb 28, 2017 at 08:56:45AM -0800, Jason Ekstrand wrote:
> > +   if (handleTypes == 0) {
> > +  /* The DRM execbuffer ioctl always execute in-oder, even between
> > +   * different rings. As such, a dummy no-op semaphore is a
> perfectly
> > +   * valid implementation.
>
> That's not quite true. Each engine is its own timeline within the context.
> Every execbuf on a particular ring is executed in submission order.
> Between rings, order is based on dependencies - batches that only share
> read access to the same buffers (or nothing shared) will be executed in
> parallel, but any writes impose a strong ordering between the engines.
> (That being the basis of TYPE_BO.)
>
> I don't think it affects anv since there is only a single render queue,
> but I think the explanation of TYPE_DUMMY needs a little more fleshing
> out to avoid leaving a trap behind.
>

You're correct.  Thanks for pointing that out.  I'll fix the comment to not
say stupid things about different rings.


> -Chris
>
> > +   */
> > +  semaphore->permanent.type = ANV_SEMAPHORE_TYPE_DUMMY;
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/18] anv/image: Add anv_layout_to_aux_usage()

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 3:01 PM, Nanley Chery  wrote:

> On Tue, Feb 28, 2017 at 11:00:14AM -0800, Jason Ekstrand wrote:
> > On Tue, Feb 28, 2017 at 10:53 AM, Nanley Chery 
> > wrote:
> >
> > > On Tue, Feb 28, 2017 at 10:38:12AM -0800, Jason Ekstrand wrote:
> > > > On Tue, Feb 28, 2017 at 10:32 AM, Nanley Chery <
> nanleych...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Tue, Feb 28, 2017 at 08:26:56AM -0800, Jason Ekstrand wrote:
> > > > > > On Mon, Feb 27, 2017 at 5:20 PM, Nanley Chery <
> nanleych...@gmail.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > > > This function supersedes layout_to_hiz_usage().
> > > > > > >
> > > > > > > Signed-off-by: Nanley Chery 
> > > > > > > ---
> > > > > > >  src/intel/vulkan/anv_image.c   | 149
> > > ++
> > > > > > > +++
> > > > > > >  src/intel/vulkan/anv_private.h |   4 ++
> > > > > > >  2 files changed, 153 insertions(+)
> > > > > > >
> > > > > > > diff --git a/src/intel/vulkan/anv_image.c
> > > > > b/src/intel/vulkan/anv_image.c
> > > > > > > index cd142938e7..716cdf3a38 100644
> > > > > > > --- a/src/intel/vulkan/anv_image.c
> > > > > > > +++ b/src/intel/vulkan/anv_image.c
> > > > > > > @@ -432,6 +432,155 @@ void anv_GetImageSubresourceLayout(
> > > > > > > }
> > > > > > >  }
> > > > > > >
> > > > > > > +/**
> > > > > > > + * @brief This function determines the optimal buffer to use
> for
> > > > > device
> > > > > > > + * accesses given a VkImageLayout and other pieces of
> information
> > > > > needed
> > > > > > > to
> > > > > > > + * make that determination. Device accesses may include normal
> > > > > sampling
> > > > > > > and
> > > > > > > + * rendering operations or resolves.
> > > > > > > + *
> > > > > > > + * @param gen The generation of the Intel GPU.
> > > > > > > + * @param image The image that may contain a collection of
> > > buffers.
> > > > > > > + * @param aspects The aspect(s) of the image to be accessed.
> > > > > > > + * @param layout The current layout of the image aspect(s).
> > > > > > > + * @param future_layout The next layout of the image
> aspect(s), if
> > > > > known.
> > > > > > > + *  Otherwise this should be equal to the
> > > current
> > > > > > > layout.
> > > > > > > + *
> > > > > > > + * @return The primary buffer that should be used for the
> given
> > > > > layout.
> > > > > > > + */
> > > > > > > +enum isl_aux_usage
> > > > > > > +anv_layout_to_aux_usage(const uint8_t gen, const struct
> anv_image
> > > *
> > > > > const
> > > > > > > image,
> > > > > > >
> > > > > >
> > > > > > Might be better to take a gen_device_info rather than just the
> > > integer.
> > > > > > Since we're doing run-time checks anyway, the cost should be
> small.
> > > > > >
> > > > >
> > > > > What does this buy us?
> > > > >
> > > >
> > > > Nothing at the moment.  However, it is the more standard thing to
> pass in
> > > > and, if we ever need more information in the future, device_info is
> what
> > > > we'll want.  Or you could just pass in the anv_device to guarantee
> that
> > > we
> > > > have everything we would ever need.
> > > >
> > >
> > > I'm in favor of adding it when we need it, but I can make it take the
> > > device_info if you insist. My rationale is that if the function takes a
> > > device_info or anv_device, the function prototype would be
> unnecessarily
> > > ambiguous with respect to what device-related information is necessary
> > > to perform the mapping.
> > >
> >
> > Certainly anv_device is probably a bit much since it doesn't (yet) depend
> > on any run-time information.  I could see that changing in the future
> > (environment variables, per-app parameters, etc.) but we can cross that
> > bridge when we come to it.  I don't really see an "information"
> difference
> > between an integer "gen" and a device info.  The one completely describes
> > the hardware and the other sort-of describes the hardware.  Also, I
> > wouldn't be terribly surprised if, in the future, whether or not we can
> > sample from HiZ starts to depend on half-gen or whether or not it's an
> atom
> > part.
> >
>
> Do you want me to use the device_info struct in the v2?
>

I'd prefer it but I'm not going to be too upset if it's not there.


> -Nanley
>
> >
> > > -Nanley
> > >
> > > >
> > > > > -Nanley
> > > > >
> > > > > >
> > > > > > > +const VkImageAspectFlags aspects,
> > > > > VkImageLayout
> > > > > > > layout,
> > > > > > > +const VkImageLayout future_layout)
> > > > > > > +{
> > > > > > > +   /* Validate the inputs. */
> > > > > > > +
> > > > > > > +   /* Intel GPUs prior to Gen7 are not supported in anv. */
> > > > > > > +   assert(gen >= 7);
> > > > > > > +
> > > > > > > +   /* The layout of a NULL image is not properly defined. */
> > > > > > > +   assert(image != NULL);
> > > > > > > +
> > > > > > > +   /* The aspects must be a subset of the image aspects. */
> > 

Re: [Mesa-dev] [PATCH 7/9] anv: Implement VK_KHX_external_semaphore_fd

[Chris Wilson]

On Tue, Feb 28, 2017 at 08:56:45AM -0800, Jason Ekstrand wrote:
> +   if (handleTypes == 0) {
> +  /* The DRM execbuffer ioctl always execute in-oder, even between
> +   * different rings. As such, a dummy no-op semaphore is a perfectly
> +   * valid implementation.

That's not quite true. Each engine is its own timeline within the context.
Every execbuf on a particular ring is executed in submission order.
Between rings, order is based on dependencies - batches that only share
read access to the same buffers (or nothing shared) will be executed in
parallel, but any writes impose a strong ordering between the engines.
(That being the basis of TYPE_BO.)

I don't think it affects anv since there is only a single render queue,
but I think the explanation of TYPE_DUMMY needs a little more fleshing
out to avoid leaving a trap behind.
-Chris

> +   */
> +  semaphore->permanent.type = ANV_SEMAPHORE_TYPE_DUMMY;

-- 
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: remove unecessary flags.q.subroutine_def

[Timothy Arceri]

On 01/03/17 03:57, Samuel Pitoiset wrote:



On 02/26/2017 10:19 PM, Timothy Arceri wrote:



On 25/02/17 22:15, Samuel Pitoiset wrote:

This bit is definitely not necessary because subroutine_list
can be used instead. This frees one more bit in the flags.q
struct which is nice because arb_bindless_texture will need
4 bits for the new layout qualifiers.

No piglit regressions found (including compiler tests) with
"-t subroutine".

Signed-off-by: Samuel Pitoiset 
---
 src/compiler/glsl/ast.h  | 1 -
 src/compiler/glsl/ast_to_hir.cpp | 6 +++---
 src/compiler/glsl/ast_type.cpp   | 6 ++
 src/compiler/glsl/glsl_parser.yy | 1 -
 src/compiler/glsl/glsl_parser_extras.cpp | 2 +-
 5 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
index 11a092e41c..d27b940744 100644
--- a/src/compiler/glsl/ast.h
+++ b/src/compiler/glsl/ast.h
@@ -607,7 +607,6 @@ struct ast_type_qualifier {
  /** \name Qualifiers for GL_ARB_shader_subroutine */
  /** \{ */
  unsigned subroutine:1;  /**< Is this marked 'subroutine' */
- unsigned subroutine_def:1; /**< Is this marked 'subroutine'
with a list of types */
  /** \} */

  /** \name Qualifiers for GL_KHR_blend_equation_advanced */
diff --git a/src/compiler/glsl/ast_to_hir.cpp
b/src/compiler/glsl/ast_to_hir.cpp
index f033d7df97..7e99faeaed 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -3510,7 +3510,7 @@ apply_layout_qualifier_to_variable(const struct
ast_type_qualifier *qual,
  }
   }
} else if (qual->flags.q.explicit_index) {
-  if (!qual->flags.q.subroutine_def)
+  if (!qual->subroutine_list)
  _mesa_glsl_error(loc, state,
   "explicit index requires explicit location");
} else if (qual->flags.q.explicit_component) {
@@ -5568,7 +5568,7 @@ ast_function::hir(exec_list *instructions,
 *  "Subroutine declarations cannot be prototyped. It is an error
to prepend
 *   subroutine(...) to a function declaration."
 */
-   if (this->return_type->qualifier.flags.q.subroutine_def &&
!is_definition) {
+   if (this->return_type->qualifier.subroutine_list &&
!is_definition) {
   YYLTYPE loc = this->get_location();
   _mesa_glsl_error(, state,
"function declaration `%s' cannot have
subroutine prepended",
@@ -5716,7 +5716,7 @@ ast_function::hir(exec_list *instructions,
sig->replace_parameters(_parameters);
signature = sig;

-   if (this->return_type->qualifier.flags.q.subroutine_def) {
+   if (this->return_type->qualifier.subroutine_list) {
   int idx;

   if (this->return_type->qualifier.flags.q.explicit_index) {
diff --git a/src/compiler/glsl/ast_type.cpp
b/src/compiler/glsl/ast_type.cpp
index 96d20c10af..5f868a81f2 100644
--- a/src/compiler/glsl/ast_type.cpp
+++ b/src/compiler/glsl/ast_type.cpp
@@ -44,7 +44,6 @@
ast_fully_specified_type::has_qualifiers(_mesa_glsl_parse_state
*state) const
ast_type_qualifier subroutine_only;
subroutine_only.flags.i = 0;
subroutine_only.flags.q.subroutine = 1;
-   subroutine_only.flags.q.subroutine_def = 1;
if (state->has_explicit_uniform_location()) {
   subroutine_only.flags.q.explicit_index = 1;
}
@@ -285,8 +284,8 @@ ast_type_qualifier::merge_qualifier(YYLTYPE *loc,
   }
}

-   if (q.flags.q.subroutine_def) {
-  if (this->flags.q.subroutine_def) {
+   if (q.subroutine_list) {
+  if (this->subroutine_list) {
  _mesa_glsl_error(loc, state,
   "conflicting subroutine qualifiers used");
   } else {
@@ -772,7 +771,6 @@ ast_type_qualifier::validate_flags(YYLTYPE *loc,
 bad.flags.q.point_mode ? " point_mode" : "",
 bad.flags.q.vertices ? " vertices" : "",
 bad.flags.q.subroutine ? " subroutine" : "",
-bad.flags.q.subroutine_def ? " subroutine_def" :
"",
 bad.flags.q.blend_support ? " blend_support" : "",
 bad.flags.q.inner_coverage ? " inner_coverage" :
"",
 bad.flags.q.post_depth_coverage ? "
post_depth_coverage" : "");
diff --git a/src/compiler/glsl/glsl_parser.yy
b/src/compiler/glsl/glsl_parser.yy
index d703f8..b79fcee550 100644
--- a/src/compiler/glsl/glsl_parser.yy
+++ b/src/compiler/glsl/glsl_parser.yy
@@ -1812,7 +1812,6 @@ subroutine_qualifier:
| SUBROUTINE '(' subroutine_type_list ')'
{
   memset(& $$, 0, sizeof($$));
-  $$.flags.q.subroutine_def = 1;


You need to change this to:

   $$.flags.q.subroutine = 1;

Otherwise we won't detect if the qualifier was added when it should have
been etc.


Are you sure it's needed to set it up? I thought it was enough to only
set $$.subroutine_list.


Sorry I should have been more clear. I mean the function that make use 
of checking the qualifier flags for validation 

Re: [Mesa-dev] [PATCH 02/18] anv/image: Add anv_layout_to_aux_usage()

[Nanley Chery]

On Tue, Feb 28, 2017 at 11:00:14AM -0800, Jason Ekstrand wrote:
> On Tue, Feb 28, 2017 at 10:53 AM, Nanley Chery 
> wrote:
> 
> > On Tue, Feb 28, 2017 at 10:38:12AM -0800, Jason Ekstrand wrote:
> > > On Tue, Feb 28, 2017 at 10:32 AM, Nanley Chery 
> > > wrote:
> > >
> > > > On Tue, Feb 28, 2017 at 08:26:56AM -0800, Jason Ekstrand wrote:
> > > > > On Mon, Feb 27, 2017 at 5:20 PM, Nanley Chery  > >
> > > > wrote:
> > > > >
> > > > > > This function supersedes layout_to_hiz_usage().
> > > > > >
> > > > > > Signed-off-by: Nanley Chery 
> > > > > > ---
> > > > > >  src/intel/vulkan/anv_image.c   | 149
> > ++
> > > > > > +++
> > > > > >  src/intel/vulkan/anv_private.h |   4 ++
> > > > > >  2 files changed, 153 insertions(+)
> > > > > >
> > > > > > diff --git a/src/intel/vulkan/anv_image.c
> > > > b/src/intel/vulkan/anv_image.c
> > > > > > index cd142938e7..716cdf3a38 100644
> > > > > > --- a/src/intel/vulkan/anv_image.c
> > > > > > +++ b/src/intel/vulkan/anv_image.c
> > > > > > @@ -432,6 +432,155 @@ void anv_GetImageSubresourceLayout(
> > > > > > }
> > > > > >  }
> > > > > >
> > > > > > +/**
> > > > > > + * @brief This function determines the optimal buffer to use for
> > > > device
> > > > > > + * accesses given a VkImageLayout and other pieces of information
> > > > needed
> > > > > > to
> > > > > > + * make that determination. Device accesses may include normal
> > > > sampling
> > > > > > and
> > > > > > + * rendering operations or resolves.
> > > > > > + *
> > > > > > + * @param gen The generation of the Intel GPU.
> > > > > > + * @param image The image that may contain a collection of
> > buffers.
> > > > > > + * @param aspects The aspect(s) of the image to be accessed.
> > > > > > + * @param layout The current layout of the image aspect(s).
> > > > > > + * @param future_layout The next layout of the image aspect(s), if
> > > > known.
> > > > > > + *  Otherwise this should be equal to the
> > current
> > > > > > layout.
> > > > > > + *
> > > > > > + * @return The primary buffer that should be used for the given
> > > > layout.
> > > > > > + */
> > > > > > +enum isl_aux_usage
> > > > > > +anv_layout_to_aux_usage(const uint8_t gen, const struct anv_image
> > *
> > > > const
> > > > > > image,
> > > > > >
> > > > >
> > > > > Might be better to take a gen_device_info rather than just the
> > integer.
> > > > > Since we're doing run-time checks anyway, the cost should be small.
> > > > >
> > > >
> > > > What does this buy us?
> > > >
> > >
> > > Nothing at the moment.  However, it is the more standard thing to pass in
> > > and, if we ever need more information in the future, device_info is what
> > > we'll want.  Or you could just pass in the anv_device to guarantee that
> > we
> > > have everything we would ever need.
> > >
> >
> > I'm in favor of adding it when we need it, but I can make it take the
> > device_info if you insist. My rationale is that if the function takes a
> > device_info or anv_device, the function prototype would be unnecessarily
> > ambiguous with respect to what device-related information is necessary
> > to perform the mapping.
> >
> 
> Certainly anv_device is probably a bit much since it doesn't (yet) depend
> on any run-time information.  I could see that changing in the future
> (environment variables, per-app parameters, etc.) but we can cross that
> bridge when we come to it.  I don't really see an "information" difference
> between an integer "gen" and a device info.  The one completely describes
> the hardware and the other sort-of describes the hardware.  Also, I
> wouldn't be terribly surprised if, in the future, whether or not we can
> sample from HiZ starts to depend on half-gen or whether or not it's an atom
> part.
> 

Do you want me to use the device_info struct in the v2?

-Nanley

> 
> > -Nanley
> >
> > >
> > > > -Nanley
> > > >
> > > > >
> > > > > > +const VkImageAspectFlags aspects,
> > > > VkImageLayout
> > > > > > layout,
> > > > > > +const VkImageLayout future_layout)
> > > > > > +{
> > > > > > +   /* Validate the inputs. */
> > > > > > +
> > > > > > +   /* Intel GPUs prior to Gen7 are not supported in anv. */
> > > > > > +   assert(gen >= 7);
> > > > > > +
> > > > > > +   /* The layout of a NULL image is not properly defined. */
> > > > > > +   assert(image != NULL);
> > > > > > +
> > > > > > +   /* The aspects must be a subset of the image aspects. */
> > > > > > +   assert(aspects & image->aspects && aspects <= image->aspects);
> > > > > > +
> > > > > > +   /* According to the Vulkan Spec, the following layouts are
> > valid
> > > > only
> > > > > > as
> > > > > > +* initial layouts in a layout transition and don't support
> > device
> > > > > > access.
> > > > > > +* Therefore, the caller should not be setting the future
> > layout to
> > > > > > 

Re: [Mesa-dev] [PATCH 5/8] i965: Add script to gen code for OA counter queries

[Robert Bragg]

On Mon, Feb 27, 2017 at 5:38 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Hey Rob,
>
> Your series look pretty good. Just a tiny nit on this patch below.
>
> As we've discussed in the office, I think it would be nice to have part of
> this work factored out in src/intel.
> But that can be done later on.
>
> Also, I found it a bit disturbing to have the equations in polish
notation.
> I've given a try at using a more C-like style to it. The result is here :
>
> https://github.com/djdeath/mesa/commit/ebfaf7aee8efe79dc814bc7bfdcb9d
74cec09d3c
>
> It's a tiny bit less python (~20 lines) but adds a dependency on
> python-parsley.
> I also have a script to convert expression from your format to the new
one.

Thanks for prototyping this it interesting to compare. We talked at length
offline but putting my thoughts down here too:

Tbh I'm not sure whether this would be a good direction, considering pros
and cons...

Currently Mesa isn't the only project doing codegen based on these
expression, and the codegen in gputop is probably a bit more involved than
Mesa's where it also generates MathML for the expressions to have something
readable in the UI. We also have an internal 'MDAPI' library which generate
a class/structure based description of these configs. At least considering
that we have fairly decent support for rendering equations in gputop it
could be good compare implementation details e.g. with regards to avoiding
redundant braces considering the precedence of operators if we wanted to go
in this direction. (details can be found in
gputop/scripts/gputop-oa-codegen.py if curious).

The use of RPN wasn't really a choice by me given that the internal MDAPI
XML files that these XML files are generated from themselves have RPN based
equations. There are some minor differences to how raw A/B/C counters are
read but generally I see some value in minimizing divergence from what VPG
maintains internally considering the effort involved in maintaining the
conversion script itself and the risk that it becomes hard to compare the
two where we're seeing problems with particular counters and want to cross
reference what we're doing with what's VPG's driver does on Windows.

For reference; probably the best place to consider maintaining any code to
convert the expression format would be as a patch to
gputop/scripts/mdapi-xml-convert.py, but it should be considered that these
files are shared so I'd have to update these other generators if we made a
backwards-incompatible change:
- kernel config descriptors
- gputop normalization code (almost identical to Mesa)
- gputop MathML equation descriptions
- MDAPI class based description of counters

To my mind RPN is so simple to 'parse' for codegen that I can barely bring
myself to call it parsing - you just tokenize based on spaces and you're
done and then you traverse the operators by pushing tokens/operands to a
stack, when you hit an operator you pop the operands and push the result.
With RPN there's no precedence ambiguity to consider and with the
explicitly typed operations like UDIV vs FDIV there's no operand type
ambiguity either. I'd certainly be nervous of squashing these both into a
single '/' operator and relying on C type conversion rules. The risk that
there are some corner cases where the results won't match the original
equations without more explicit type casting seems quite high with the
current prototype.

The primary use for these expressions is for codegen and so I think machine
readability and lack of ambiguity is much more important than human
readability within the XML files.

RPN seems very well suited here once you're familiar with evaluating RPN as
a series of operand pushes and pops for operations.

For human readability then I think what gputop does is a pretty decent
starting point, being careful with bracketing and supporting mouse overlay
descriptions of the different variables, and nice typography and layouting.

It's subjective to say which is more readable to handle in code but
personally I find embedding a formal grammar for expressions, introducing
the need for operator precedence and type conversion rules to be more of a
mental load. The comparison of line count imho doesn't account for the
density of the grammar being embedded which needs to understood and
maintained across the different codegen scripts. The previous code
effectively duplicated the traversal of the RPN expressions since it barely
seemed worth factoring out the push and pop of tokens that form the parsing
loop. There was also lots of white space between the operator methods.

For now I think it's nice to see this alternative to compare, but don't
think it's the best trade-off to prioritize human readability of the
equations in the xml files over over, unambiguous, machine readability.
Considering the complexity of some of the equations there's just no way
they will ever be practically readable within the xml files and don't
really see much alternative to 

[Mesa-dev] [Bug 99856] OpenCL Hello world returns "unsupported call to function get_local_size"

[bugzilla-daemon]

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

--- Comment #23 from Mig  ---
I recompiled with the default llvm compiler 3.9.1 and it works for me too!

Number of platforms: 2 
1. Device: AMD TONGA (DRM 3.8.0 / 4.9.11-1-ARCH, LLVM 3.9.1)
success: got back 1 binaries, total size 8434
binary 0: size 8434 dumped to square0.gallium_bin
Computed '1024/1024' correct values!

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

Re: [Mesa-dev] [PATCH 5/7] anv: Implement VK_KHX_external_memory_capabilities (v2)

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 10:58 AM, Chad Versace 
wrote:

> This is a complete but trivial implementation. It's trivial becasue We
> support no external memory capabilities yet.  Most of the real work in
> this commit is in reworking the UUIDs advertised by the driver.
>
> v2 (chadv):
>   - Fix chain traversal in vkGetPhysicalDeviceImageFormatProperties2KHR.
> Extract VkPhysicalDeviceExternalImageFormatInfoKHX from the chain of
> input structs, not the chain of output structs.
>   - In vkGetPhysicalDeviceImageFormatProperties2KHR, iterate over the
> input chain and the output chain separately. Reduces diff in future
> dma_buf patches.
>
> Co-authored-with: Jason Ekstrand 
> ---
>
> On my branch wip/anv-external-memory.
>   http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=wip/anv-external-memory
>
>  src/intel/vulkan/anv_device.c   | 53 ---
>  src/intel/vulkan/anv_entrypoints_gen.py |  1 +
>  src/intel/vulkan/anv_formats.c  | 75
> +
>  src/intel/vulkan/anv_private.h  |  2 +
>  4 files changed, 117 insertions(+), 14 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 3609670b348..9ee2e02ed51 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -74,11 +74,37 @@ anv_physical_device_init_uuids(struct
> anv_physical_device *device)
> if (sha1_ctx == NULL)
>return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
>
> +   /* The pipeline cache UUID is used for determining when a pipeline
> cache is
> +* invalid.  It needs both a driver build and the PCI ID of the device.
> +*/
> _mesa_sha1_update(sha1_ctx, build_id_data(note), build_id_len);
> _mesa_sha1_update(sha1_ctx, >chipset_id,
> sizeof(device->chipset_id));
> _mesa_sha1_final(sha1_ctx, sha1);
> memcpy(device->pipeline_cache_uuid, sha1, VK_UUID_SIZE);
>
> +   /* The driver UUID is used for determining sharability of images and
> memory
> +* between two Vulkan instances in separate processes.  People who
> want to
> +* share memory need to also check the device UUID (below) so all this
> +* needs to be is the build-id.
> +*/
> +   memcpy(device->driver_uuid, build_id_data(note), VK_UUID_SIZE);
> +
> +   sha1_ctx = _mesa_sha1_init();
> +   if (sha1_ctx == NULL)
> +  return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
> +
> +   /* The device UUID uniquely identifies the given device within the
> machine.
> +* Since we never have more than one device, this doesn't need to be a
> real
> +* UUID.  However, on the off-chance that someone tries to use this to
> +* cache pre-tiled images or something of the like, we use the PCI ID
> and
> +* some bits if ISL info to ensure that this is safe.
> +*/
> +   _mesa_sha1_update(sha1_ctx, >chipset_id,
> sizeof(device->chipset_id));
> +   _mesa_sha1_update(sha1_ctx, >isl_dev.has_bit6_swizzling,
> + sizeof(device->isl_dev.has_bit6_swizzling));
> +   _mesa_sha1_final(sha1_ctx, sha1);
> +   memcpy(device->device_uuid, sha1, VK_UUID_SIZE);
> +
> return VK_SUCCESS;
>  }
>
> @@ -163,10 +189,6 @@ anv_physical_device_init(struct anv_physical_device
> *device,
>goto fail;
> }
>
> -   result = anv_physical_device_init_uuids(device);
> -   if (result != VK_SUCCESS)
> -  goto fail;
> -
> bool swizzled = anv_gem_get_bit6_swizzle(fd, I915_TILING_X);
>
> /* GENs prior to 8 do not support EU/Subslice info */
> @@ -206,14 +228,18 @@ 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;
>
> +   isl_device_init(>isl_dev, >info, swizzled);
> +
> +   result = anv_physical_device_init_uuids(device);
> +   if (result != VK_SUCCESS)
> +  goto fail;
> +
> result = anv_init_wsi(device);
> if (result != VK_SUCCESS) {
>ralloc_free(device->compiler);
>goto fail;
> }
>
> -   isl_device_init(>isl_dev, >info, swizzled);
> -
> device->local_fd = fd;
> return VK_SUCCESS;
>
> @@ -257,6 +283,10 @@ static const VkExtensionProperties
> global_extensions[] = {
>.extensionName = VK_KHR_GET_PHYSICAL_DEVICE_
> PROPERTIES_2_EXTENSION_NAME,
>.specVersion = 1,
> },
> +   {
> +  .extensionName = VK_KHX_EXTERNAL_MEMORY_
> CAPABILITIES_EXTENSION_NAME,
> +  .specVersion = 1,
> +   },
>  };
>
>  static const VkExtensionProperties device_extensions[] = {
> @@ -668,10 +698,21 @@ void anv_GetPhysicalDeviceProperties2KHR(
>  VkPhysicalDevicephysicalDevice,
>  VkPhysicalDeviceProperties2KHR* pProperties)
>  {
> +   ANV_FROM_HANDLE(anv_physical_device, pdevice, physicalDevice);
> +
> anv_GetPhysicalDeviceProperties(physicalDevice,
> >properties);
>
> vk_foreach_struct(ext, pProperties->pNext) {
>

Re: [Mesa-dev] [PATCH 7/7] anv: Implement VK_KHX_external_memory_fd (v2)

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 10:58 AM, Chad Versace 
wrote:

> From: Jason Ekstrand 
>
>
> v2 (chadv):
>   - Rebase.
>   - Fix vkGetPhysicalDeviceImageFormatProperties2KHR when
> handleType == 0.
>   - Move handleType-independency comments out of handleType-switch, in
> vkGetPhysicalDeviceExternalBufferPropertiesKHX.  Reduces diff in
> future dma_buf patches.
>
> Co-authored-with: Chad Versace 
> ---
>
> On my branch wip/anv-external-memory.
>   http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=wip/anv-external-memory
>
>  src/intel/vulkan/anv_device.c   | 90
> +
>  src/intel/vulkan/anv_entrypoints_gen.py |  1 +
>  src/intel/vulkan/anv_formats.c  | 59 ++---
>  3 files changed, 133 insertions(+), 17 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 024e19f91b9..ec88547368a 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -310,6 +310,10 @@ static const VkExtensionProperties
> device_extensions[] = {
>.extensionName = VK_KHX_EXTERNAL_MEMORY_EXTENSION_NAME,
>.specVersion = 1,
> },
> +   {
> +  .extensionName = VK_KHX_EXTERNAL_MEMORY_FD_EXTENSION_NAME,
> +  .specVersion = 1,
> +   },
>  };
>
>  static void *
> @@ -1400,7 +1404,7 @@ VkResult anv_AllocateMemory(
>  {
> ANV_FROM_HANDLE(anv_device, device, _device);
> struct anv_device_memory *mem;
> -   VkResult result;
> +   VkResult result = VK_SUCCESS;
>
> assert(pAllocateInfo->sType == VK_STRUCTURE_TYPE_MEMORY_
> ALLOCATE_INFO);
>
> @@ -1418,18 +1422,50 @@ VkResult anv_AllocateMemory(
> if (mem == NULL)
>return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
>
> -   /* The kernel is going to give us whole pages anyway */
> -   uint64_t alloc_size = align_u64(pAllocateInfo->allocationSize, 4096);
> -
> -   result = anv_bo_init_new(>bo, device, alloc_size);
> -   if (result != VK_SUCCESS)
> -  goto fail;
> -
> mem->type_index = pAllocateInfo->memoryTypeIndex;
> -
> mem->map = NULL;
> mem->map_size = 0;
>
> +   const VkImportMemoryFdInfoKHX *fd_info =
> +  vk_find_struct_const(pAllocateInfo->pNext,
> IMPORT_MEMORY_FD_INFO_KHX);
> +
> +   /* The Vulkan spec permits handleType to be 0, in which case the
> struct is
> +* ignored.
> +*/
> +   if (fd_info && fd_info->handleType) {
> +  /* At the moment, we only support the OPAQUE_FD memory type which is
> +   * just a GEM buffer.
> +   */
> +  assert(fd_info->handleType ==
> + VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHX);
> +
> +  uint32_t gem_handle = anv_gem_fd_to_handle(device, fd_info->fd);
> +  if (!gem_handle) {
> + result = vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHX);
> + goto fail;
> +  }
> +
> +  /* From the Vulkan spec:
> +   *
> +   *"Importing memory from a file descriptor transfers ownership
> of
> +   *the file descriptor from the application to the Vulkan
> +   *implementation. The application must not perform any
> operations on
> +   *the file descriptor after a successful import."
> +   *
> +   * If the import fails, we leave the file descriptor open.
> +   */
> +  close(fd_info->fd);
> +
> +  anv_bo_init(>bo, gem_handle, pAllocateInfo->allocationSize);
> +   } else {
> +  /* The kernel is going to give us whole pages anyway */
> +  uint64_t alloc_size = align_u64(pAllocateInfo->allocationSize,
> 4096);
> +
> +  result = anv_bo_init_new(>bo, device, alloc_size);
> +  if (result != VK_SUCCESS)
> + goto fail;
> +   }
> +
> *pMem = anv_device_memory_to_handle(mem);
>
> return VK_SUCCESS;
> @@ -1440,6 +1476,42 @@ VkResult anv_AllocateMemory(
> return result;
>  }
>
> +VkResult anv_GetMemoryFdKHX(
> +VkDevicedevice_h,
> +VkDeviceMemory  memory_h,
> +VkExternalMemoryHandleTypeFlagBitsKHX   handleType,
> +int*pFd)
> +{
> +   ANV_FROM_HANDLE(anv_device, dev, device_h);
> +   ANV_FROM_HANDLE(anv_device_memory, mem, memory_h);
> +
> +   /* We support only one handle type. */
> +   assert(handleType == VK_EXTERNAL_MEMORY_HANDLE_
> TYPE_OPAQUE_FD_BIT_KHX);
> +
> +   int fd = anv_gem_handle_to_fd(dev, mem->bo.gem_handle);
> +   if (fd == -1)
> +  return vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHX);
> +
> +   *pFd = fd;
> +
> +   return VK_SUCCESS;
> +}
> +
> +VkResult anv_GetMemoryFdPropertiesKHX(
> +VkDevicedevice_h,
> +VkExternalMemoryHandleTypeFlagBitsKHX   handleType,
> +int fd,
> +VkMemoryFdPropertiesKHX*pMemoryFdProperties)
> +{
> +   /* The valid usage section for this function says:
> +*
> +*

[Mesa-dev] [Bug 99987] Mesa 13+ breaks Xvnc (and similar X servers)

[bugzilla-daemon]

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

Norman Gaywood  changed:

   What|Removed |Added

 CC||ngayw...@une.edu.au

--- Comment #1 from Norman Gaywood  ---
Same when running under x2go with Fedora 25. From:
https://bugzilla.redhat.com/show_bug.cgi?id=1427174

x2go also broken with (at least) an xfce4 desktop.

xfce4 session starts, but many programs won't start from the menus.

xterm starts from menus and we get:
> $ glxinfo
> name of display: :50.0
> Error: couldn't find RGB GLX visual or fbconfig

And things like:
> $ xfce4-terminal 
> Segmentation fault (core dumped)

> $ gnome-terminal
> Segmentation fault (core dumped)

For gnome-terminal:

ccpp-2017-02-28-17:16:40-2101 # gdb /usr/bin/gnome-terminal ./coredump
GNU gdb (GDB) Fedora 7.12.1-46.fc25
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/gnome-terminal...Reading symbols from
/usr/lib/debug/usr/bin/gnome-terminal.debug...done.
done.
[New LWP 2101]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `gnome-terminal'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fb111ac935f in rawmemchr () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install
at-spi2-atk-2.22.0-1.fc25.x86_64 at-spi2-core-2.22.0-1.fc25.x86_64
atk-2.22.0-1.fc25.x86_64 bzip2-libs-1.0.6-21.fc25.x86_64
cairo-1.14.8-1.fc25.x86_64 cairo-gobject-1.14.8-1.fc25.x86_64
dbus-libs-1.11.10-1.fc25.x86_64 dconf-0.26.0-1.fc25.x86_64
expat-2.2.0-1.fc25.x86_64 fontconfig-2.12.1-1.fc25.x86_64
freetype-2.6.5-1.fc25.x86_64 gdk-pixbuf2-2.36.5-1.fc25.x86_64
glib2-2.50.3-1.fc25.x86_64 glibc-2.24-4.fc25.x86_64 gmp-6.1.1-1.fc25.x86_64
gnutls-3.5.9-2.fc25.x86_64 graphite2-1.3.6-1.fc25.x86_64
gtk3-3.22.8-1.fc25.x86_64 harfbuzz-1.3.2-1.fc25.x86_64
libNX_Xinerama-3.5.0.32-4.fc24.x86_64 libX11-1.6.4-4.fc25.x86_64
libXau-1.0.8-6.fc24.x86_64 libXcomposite-0.4.4-8.fc24.x86_64
libXcursor-1.1.14-6.fc24.x86_64 libXdamage-1.1.4-8.fc24.x86_64
libXext-1.3.3-4.fc24.x86_64 libXfixes-5.0.3-1.fc25.x86_64
libXi-1.7.9-1.fc25.x86_64 libXrandr-1.5.1-1.fc25.x86_64
libXrender-0.9.10-1.fc25.x86_64 libblkid-2.28.2-2.fc25.x86_64
libcap-2.25-2.fc25.x86_64 libdatrie-0.2.9-3.fc25.x86_64
libepoxy-1.3.1-3.fc25.x86_64 libffi-3.1-9.fc24.x86_64
libgcc-6.3.1-1.fc25.x86_64 libgcrypt-1.6.6-1.fc25.x86_64
libglvnd-0.2.999-10.gitdc16f8c.fc25.x86_64
libglvnd-egl-0.2.999-10.gitdc16f8c.fc25.x86_64
libglvnd-glx-0.2.999-10.gitdc16f8c.fc25.x86_64 libgpg-error-1.24-1.fc25.x86_64
libidn2-0.16-1.fc25.x86_64 libmount-2.28.2-2.fc25.x86_64
libpng-1.6.27-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
libstdc++-6.3.1-1.fc25.x86_64 libtasn1-4.10-1.fc25.x86_64
libthai-0.1.25-1.fc25.x86_64 libunistring-0.9.4-3.fc24.x86_64
libuuid-2.28.2-2.fc25.x86_64 libwayland-client-1.12.0-1.fc25.x86_64
libwayland-cursor-1.12.0-1.fc25.x86_64 libxcb-1.12-1.fc25.x86_64
libxkbcommon-0.7.1-1.fc25.x86_64 lz4-1.7.5-1.fc25.x86_64
mesa-libwayland-egl-13.0.4-1.fc25.x86_64 nettle-3.3-1.fc25.x86_64
p11-kit-0.23.2-2.fc24.x86_64 pango-1.40.3-1.fc25.x86_64 pcre-8.40-4.fc25.x86_64
pcre2-10.23-1.fc25.x86_64 pixman-0.34.0-2.fc24.x86_64
systemd-libs-231-14.fc25.x86_64 vte291-0.46.1-1.fc25.x86_64
xz-libs-5.2.2-2.fc24.x86_64 zlib-1.2.8-10.fc24.x86_64
(gdb) where
#0  0x7fb111ac935f in rawmemchr () at /lib64/libc.so.6
#1  0x7fb111ab1832 in _IO_str_init_static_internal () at /lib64/libc.so.6
#2  0x7fb111a9ecc7 in __isoc99_vsscanf () at /lib64/libc.so.6
#3  0x7fb111a9ec67 in __isoc99_sscanf () at /lib64/libc.so.6
#4  0x7fb10f6388e2 in epoxy_glx_version () at /lib64/libepoxy.so.0
#5  0x7fb1143321e9 in gdk_x11_screen_init_gl () at /lib64/libgdk-3.so.0
#6  0x7fb11433259a in _gdk_x11_screen_update_visuals_for_gl () at
/lib64/libgdk-3.so.0
#7  0x7fb11433b1f6 in _gdk_x11_screen_init_visuals () at
/lib64/libgdk-3.so.0
#8  0x7fb114338230 in _gdk_x11_screen_new () at /lib64/libgdk-3.so.0
#9  0x7fb1143280c8 in _gdk_x11_display_open () at /lib64/libgdk-3.so.0
#10 0x7fb1142fcb85 in gdk_display_manager_open_display () at
/lib64/libgdk-3.so.0
#11 0x7fb1147e6f26 in post_parse_hook 

Re: [Mesa-dev] [PATCH 22/37] gallium/tests: remove execute bit from TGSI shader - vert-uadd.sh

[Jose Fonseca]

On 23/02/17 17:13, Emil Velikov wrote:

From: Emil Velikov 

Just like the the dozens of other shaders, the file is parsed by
separate tool and not executed.

Cc: José Fonseca 
Signed-off-by: Emil Velikov 
---
Jose, please double-check since I've got no idea how there are used.

Out of curiosity - do you guys still use these ? Afaict TGSI has evolved
since those are added yet new opcodes are not covered. Perhaps they
should ?


These simple tests are useful when bring up a new gallium driver, and 
only for that.  (As for complete gallium drivers test suites that 
operate OpenGL/Direct3D API are more interesting)


We haven't started a new gallium driver in ages, therefore we haven't 
used it ourselves in ages too.



---
 src/gallium/tests/graw/vertex-shader/vert-uadd.sh | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 mode change 100755 => 100644 src/gallium/tests/graw/vertex-shader/vert-uadd.sh

diff --git a/src/gallium/tests/graw/vertex-shader/vert-uadd.sh 
b/src/gallium/tests/graw/vertex-shader/vert-uadd.sh
old mode 100755
new mode 100644



Yes, this is indeed not a shell file.

Reviewed-by: Jose Fonseca 


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

[Mesa-dev] [Bug 99856] OpenCL Hello world returns "unsupported call to function get_local_size"

[bugzilla-daemon]

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

--- Comment #22 from Henrique Dante de Almeida  ---
Jan, the patch fixes the problem and hello world works here. Should I report
the bug in llvm bug tracker ?

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

Re: [Mesa-dev] [PATCH 19/37] bin/perf-annotate-jit: add .py suffix

[Jose Fonseca]

On 23/02/17 17:13, Emil Velikov wrote:

From: Emil Velikov 

To provide direct feedback about the file in question.

Cc: José Fonseca 
Signed-off-by: Emil Velikov 
---
Jose, I sincerely hope this doesn't cause issues on your end.
---
 bin/{perf-annotate-jit => perf-annotate-jit.py} | 0
 docs/llvmpipe.html  | 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename bin/{perf-annotate-jit => perf-annotate-jit.py} (100%)

diff --git a/bin/perf-annotate-jit b/bin/perf-annotate-jit.py
similarity index 100%
rename from bin/perf-annotate-jit
rename to bin/perf-annotate-jit.py
diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html
index 5fb3b7aa22..2163d2ec19 100644
--- a/docs/llvmpipe.html
+++ b/docs/llvmpipe.html
@@ -206,7 +206,7 @@ On Linux, it is possible to have symbol resolution of JIT code with 


LGTM.

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

Re: [Mesa-dev] [PATCH 2/9] anv: Add a real semaphore struct

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 1:59 PM, Chris Wilson 
wrote:

> On Tue, Feb 28, 2017 at 08:56:40AM -0800, Jason Ekstrand wrote:
> > It's just a dummy for now, but we'll flesh it out as needed for external
> > semaphores.
> > ---
> >  src/intel/vulkan/anv_private.h | 15 +++
> >  src/intel/vulkan/anv_queue.c   | 30 --
> >  2 files changed, 39 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> private.h
> > index 816ee8a..a2e077a 100644
> > --- a/src/intel/vulkan/anv_private.h
> > +++ b/src/intel/vulkan/anv_private.h
> > @@ -1365,6 +1365,20 @@ struct anv_event {
> > struct anv_state state;
> >  };
> >
> > +enum anv_semaphore_type {
> > +   ANV_SEMAPHORE_TYPE_NONE = 0,
> > +   ANV_SEMAPHORE_TYPE_DUMMY
> > +};
> > +
> > +struct anv_semaphore_impl {
> > +   enum anv_semaphore_type type;
> > +};
> > +
> > +struct anv_semaphore {
> > +   struct anv_semaphore_impl permanent;
> > +   struct anv_semaphore_impl temporary;
> > +};
>
> Are temporary, permanent terms from the Vk spec?
>

Yes.


> My understanding is that the temporary semaphore is a snapshot of the
> fences (sync_file), used once then reset. The permanent semaphore is a
> reservation_object (accessed via a bo), it is a volatile collection of
> fences that serves as a communication channel between processes.
>

Essentially, yes.  The semantics are a tiny bit different from that, but
it's close.  I'll add a comment.


> A synopsis of the differences and use would be invaluable.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/9] anv: Add a real semaphore struct

[Chris Wilson]

On Tue, Feb 28, 2017 at 08:56:40AM -0800, Jason Ekstrand wrote:
> It's just a dummy for now, but we'll flesh it out as needed for external
> semaphores.
> ---
>  src/intel/vulkan/anv_private.h | 15 +++
>  src/intel/vulkan/anv_queue.c   | 30 --
>  2 files changed, 39 insertions(+), 6 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
> index 816ee8a..a2e077a 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -1365,6 +1365,20 @@ struct anv_event {
> struct anv_state state;
>  };
>  
> +enum anv_semaphore_type {
> +   ANV_SEMAPHORE_TYPE_NONE = 0,
> +   ANV_SEMAPHORE_TYPE_DUMMY
> +};
> +
> +struct anv_semaphore_impl {
> +   enum anv_semaphore_type type;
> +};
> +
> +struct anv_semaphore {
> +   struct anv_semaphore_impl permanent;
> +   struct anv_semaphore_impl temporary;
> +};

Are temporary, permanent terms from the Vk spec? 

My understanding is that the temporary semaphore is a snapshot of the
fences (sync_file), used once then reset. The permanent semaphore is a
reservation_object (accessed via a bo), it is a volatile collection of
fences that serves as a communication channel between processes.

A synopsis of the differences and use would be invaluable.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965: Drop unused STATE_TEXRECT_SCALE code.

[Chris Forbes]

Nice to see the last remnants of this go.

For the series:

Reviewed-by: Chris Forbes 

On Wed, Mar 1, 2017 at 9:53 AM, Kenneth Graunke 
wrote:

> In the past, we used this on Gen4-5 to transform non-normalized texture
> coordinates (for sampler2DRect) to normalized ones.  We also used it on
> Gen6-7.5 for sampler2DRect with GL_CLAMP.
>
> Jason dropped this code in 6c8ba59cff14a1a86273f4008ff2a8e68335ab25
> in favor of using nir_lower_tex(), which just does a textureSize()
> call.  But we were still setting up these state references for
> useless uniform data.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_link.cpp  |  2 --
>  src/mesa/drivers/dri/i965/brw_program.c | 23 ---
>  src/mesa/drivers/dri/i965/brw_program.h |  2 --
>  3 files changed, 27 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp
> b/src/mesa/drivers/dri/i965/brw_link.cpp
> index 977feb37fc2..261d8861c35 100644
> --- a/src/mesa/drivers/dri/i965/brw_link.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_link.cpp
> @@ -224,8 +224,6 @@ brw_link_shader(struct gl_context *ctx, struct
> gl_shader_program *shProg)
>prog->ShadowSamplers = shader->shadow_samplers;
>_mesa_update_shader_textures_used(shProg, prog);
>
> -  brw_add_texrect_params(prog);
> -
>bool debug_enabled =
>   (INTEL_DEBUG & intel_debug_flag_for_shader_
> stage(shader->Stage));
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c
> b/src/mesa/drivers/dri/i965/brw_program.c
> index 673dc502ad4..1d36b4b8938 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -244,8 +244,6 @@ brwProgramStringNotify(struct gl_context *ctx,
>  brw->ctx.NewDriverState |= BRW_NEW_FRAGMENT_PROGRAM;
>newFP->id = get_new_program_id(brw->screen);
>
> -  brw_add_texrect_params(prog);
> -
>prog->nir = brw_create_nir(brw, NULL, prog, MESA_SHADER_FRAGMENT,
> true);
>
>brw_fs_precompile(ctx, prog);
> @@ -267,8 +265,6 @@ brwProgramStringNotify(struct gl_context *ctx,
> */
>_tnl_program_string(ctx, target, prog);
>
> -  brw_add_texrect_params(prog);
> -
>prog->nir = brw_create_nir(brw, NULL, prog, MESA_SHADER_VERTEX,
>   compiler->scalar_stage[MESA_
> SHADER_VERTEX]);
>
> @@ -346,25 +342,6 @@ brw_blend_barrier(struct gl_context *ctx)
>  }
>
>  void
> -brw_add_texrect_params(struct gl_program *prog)
> -{
> -   for (int texunit = 0; texunit < BRW_MAX_TEX_UNIT; texunit++) {
> -  if (!(prog->TexturesUsed[texunit] & (1 << TEXTURE_RECT_INDEX)))
> - continue;
> -
> -  int tokens[STATE_LENGTH] = {
> - STATE_INTERNAL,
> - STATE_TEXRECT_SCALE,
> - texunit,
> - 0,
> - 0
> -  };
> -
> -  _mesa_add_state_reference(prog->Parameters, (gl_state_index
> *)tokens);
> -   }
> -}
> -
> -void
>  brw_get_scratch_bo(struct brw_context *brw,
>drm_intel_bo **scratch_bo, int size)
>  {
> diff --git a/src/mesa/drivers/dri/i965/brw_program.h
> b/src/mesa/drivers/dri/i965/brw_program.h
> index 6eda165e875..55b9e5441d7 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.h
> +++ b/src/mesa/drivers/dri/i965/brw_program.h
> @@ -48,8 +48,6 @@ void brw_populate_sampler_prog_key_data(struct
> gl_context *ctx,
>  bool brw_debug_recompile_sampler_key(struct brw_context *brw,
>   const struct
> brw_sampler_prog_key_data *old_key,
>   const struct
> brw_sampler_prog_key_data *key);
> -void brw_add_texrect_params(struct gl_program *prog);
> -
>  void
>  brw_mark_surface_used(struct brw_stage_prog_data *prog_data,
>unsigned surf_index);
> --
> 2.11.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 00/18] anv: Remove the HiZ restriction on input attachments

[Nanley Chery]

On Mon, Feb 27, 2017 at 09:36:53PM -0800, Jason Ekstrand wrote:
> Did a read-through and, overall, this looks great.  I made a few comments
> but they're fairly simple.

Thank you for taking the time to look over this series.

> 
> One question though:  Am I correct in thinking that we are still disabling
> HiZ for rendering when the image is in the general layout?  I think it
> should be easy enough to change now but I didn't see it change so I want to
> make sure I didn't mid it.  The only reason I care about that is that we
> need it if we want to apply the PMA fix in secondary command buffers.

You are correct.

-Nanley

> 
> On Feb 27, 2017 5:21 PM, "Nanley Chery"  wrote:
> 
> > Allow HiZ for input attachment-capable depth/stencil buffers. Do so
> > without requiring sampling operations on such attachments to go through
> > the HiZ buffer.
> >
> > Series sections:
> > * Patch 1: Fix a bug.
> > * Patch 2: Add a new layout to aux_usage function.
> > * Patches 3-6: Refactor.
> > * Patches 7-10: Don't sample the depth buffer through HiZ.
> > * Patches 11-18: Allow HiZ on input attachment-capable depth/stencil
> >  buffers.
> >
> > This series increases the average frame rate on a release candidate of a
> > proprietary Vulkan benchmark by an average of 9.94% over 3 runs on my
> > SKL GT4.
> >
> > Nanley Chery (18):
> >   anv/pass: Avoid accessing attachment array out of bounds
> >   anv/image: Add anv_layout_to_aux_usage()
> >   anv/cmd_buffer: Replace layout_to_hiz_usage()
> >   anv: Update the HiZ sampling helper
> >   anv/image: Remove extra dependency on HiZ-specific variable
> >   anv/image: Simplify setup of HiZ sampler surface state
> >   anv/image: Create an additional surface state for sampling
> >   anv/descriptor_set: Store aux usage of sampled image descriptors
> >   anv/cmd_buffer: Conditionally choose the sampled image surface state
> >   anv/cmd_buffer: Remove extra resolve for certain depth buffers
> >   anv: Store the user's VkAttachmentReference
> >   anv/pass: Fix size of anv_render_pass:subpass_attachments
> >   anv/pass: Store subpass attachment reference list
> >   anv/cmd_buffer: Enable render pass awareness
> >   anv/blorp: Encapsulate subpass id querying
> >   anv/cmd_buffer: Add attachment transitioning functions
> >   anv/cmd_buffer: Centralize automatic layout transitions
> >   anv/image: Allow HiZ on input attachment-capable depth/stencil images
> >
> >  src/intel/vulkan/anv_blorp.c  |  33 +++--
> >  src/intel/vulkan/anv_cmd_buffer.c |   4 +-
> >  src/intel/vulkan/anv_descriptor_set.c |  10 ++
> >  src/intel/vulkan/anv_image.c  | 222 +++---
> > --
> >  src/intel/vulkan/anv_pass.c   |  50 
> >  src/intel/vulkan/anv_pipeline.c   |   6 +-
> >  src/intel/vulkan/anv_private.h|  58 +++--
> >  src/intel/vulkan/gen7_cmd_buffer.c|   4 +-
> >  src/intel/vulkan/genX_cmd_buffer.c| 235
> > ++
> >  src/intel/vulkan/genX_pipeline.c  |   8 +-
> >  10 files changed, 427 insertions(+), 203 deletions(-)
> >
> > --
> > 2.11.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: fix txs for sampler buffers

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Tue, Feb 28, 2017 at 7:53 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> I messed this up when I wrote it, this fixes:
> dEQP-VK.memory.pipeline_barrier.*uniform_texel_buffer.*
>
> Cc: "17.0" 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 8cfe2fb..aa7a3d1 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -3681,7 +3681,7 @@ static void visit_tex(struct nir_to_llvm_context *ctx, 
> nir_tex_instr *instr)
> }
>
> if (instr->op == nir_texop_txs && instr->sampler_dim == 
> GLSL_SAMPLER_DIM_BUF) {
> -   result = get_buffer_size(ctx, res_ptr, false);
> +   result = get_buffer_size(ctx, res_ptr, true);
> goto write_result;
> }
>
> --
> 2.9.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] [PATCH 1/2] i965: Drop unused STATE_TEXRECT_SCALE code.

[Kenneth Graunke]

In the past, we used this on Gen4-5 to transform non-normalized texture
coordinates (for sampler2DRect) to normalized ones.  We also used it on
Gen6-7.5 for sampler2DRect with GL_CLAMP.

Jason dropped this code in 6c8ba59cff14a1a86273f4008ff2a8e68335ab25
in favor of using nir_lower_tex(), which just does a textureSize()
call.  But we were still setting up these state references for
useless uniform data.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_link.cpp  |  2 --
 src/mesa/drivers/dri/i965/brw_program.c | 23 ---
 src/mesa/drivers/dri/i965/brw_program.h |  2 --
 3 files changed, 27 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
b/src/mesa/drivers/dri/i965/brw_link.cpp
index 977feb37fc2..261d8861c35 100644
--- a/src/mesa/drivers/dri/i965/brw_link.cpp
+++ b/src/mesa/drivers/dri/i965/brw_link.cpp
@@ -224,8 +224,6 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg)
   prog->ShadowSamplers = shader->shadow_samplers;
   _mesa_update_shader_textures_used(shProg, prog);
 
-  brw_add_texrect_params(prog);
-
   bool debug_enabled =
  (INTEL_DEBUG & intel_debug_flag_for_shader_stage(shader->Stage));
 
diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index 673dc502ad4..1d36b4b8938 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -244,8 +244,6 @@ brwProgramStringNotify(struct gl_context *ctx,
 brw->ctx.NewDriverState |= BRW_NEW_FRAGMENT_PROGRAM;
   newFP->id = get_new_program_id(brw->screen);
 
-  brw_add_texrect_params(prog);
-
   prog->nir = brw_create_nir(brw, NULL, prog, MESA_SHADER_FRAGMENT, true);
 
   brw_fs_precompile(ctx, prog);
@@ -267,8 +265,6 @@ brwProgramStringNotify(struct gl_context *ctx,
*/
   _tnl_program_string(ctx, target, prog);
 
-  brw_add_texrect_params(prog);
-
   prog->nir = brw_create_nir(brw, NULL, prog, MESA_SHADER_VERTEX,
  compiler->scalar_stage[MESA_SHADER_VERTEX]);
 
@@ -346,25 +342,6 @@ brw_blend_barrier(struct gl_context *ctx)
 }
 
 void
-brw_add_texrect_params(struct gl_program *prog)
-{
-   for (int texunit = 0; texunit < BRW_MAX_TEX_UNIT; texunit++) {
-  if (!(prog->TexturesUsed[texunit] & (1 << TEXTURE_RECT_INDEX)))
- continue;
-
-  int tokens[STATE_LENGTH] = {
- STATE_INTERNAL,
- STATE_TEXRECT_SCALE,
- texunit,
- 0,
- 0
-  };
-
-  _mesa_add_state_reference(prog->Parameters, (gl_state_index *)tokens);
-   }
-}
-
-void
 brw_get_scratch_bo(struct brw_context *brw,
   drm_intel_bo **scratch_bo, int size)
 {
diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
b/src/mesa/drivers/dri/i965/brw_program.h
index 6eda165e875..55b9e5441d7 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -48,8 +48,6 @@ void brw_populate_sampler_prog_key_data(struct gl_context 
*ctx,
 bool brw_debug_recompile_sampler_key(struct brw_context *brw,
  const struct brw_sampler_prog_key_data 
*old_key,
  const struct brw_sampler_prog_key_data 
*key);
-void brw_add_texrect_params(struct gl_program *prog);
-
 void
 brw_mark_surface_used(struct brw_stage_prog_data *prog_data,
   unsigned surf_index);
-- 
2.11.1

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

[Mesa-dev] [PATCH 2/2] mesa: Drop unused STATE_TEXRECT_SCALE program statevars.

[Kenneth Graunke]

The last user is now gone.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/program/prog_statevars.c | 23 ---
 src/mesa/program/prog_statevars.h |  1 -
 2 files changed, 24 deletions(-)

diff --git a/src/mesa/program/prog_statevars.c 
b/src/mesa/program/prog_statevars.c
index 5b073ac34bb..803d0afd8d3 100644
--- a/src/mesa/program/prog_statevars.c
+++ b/src/mesa/program/prog_statevars.c
@@ -458,24 +458,6 @@ _mesa_fetch_state(struct gl_context *ctx, const 
gl_state_index state[],
1);
  return;
 
-  case STATE_TEXRECT_SCALE:
- /* Value = { 1/texWidth, 1/texHeight, 0, 1 }.
-  * Used to convert unnormalized texcoords to normalized texcoords.
-  */
- {
-const int unit = (int) state[2];
-const struct gl_texture_object *texObj
-   = ctx->Texture.Unit[unit]._Current;
-if (texObj) {
-   struct gl_texture_image *texImage = texObj->Image[0][0];
-   ASSIGN_4V(value,
- (GLfloat) (1.0 / texImage->Width),
- (GLfloat) (1.0 / texImage->Height),
- 0.0f, 1.0f);
-}
- }
- return;
-
   case STATE_FOG_PARAMS_OPTIMIZED:
  /* for simpler per-vertex/pixel fog calcs. POW (for EXP/EXP2 fog)
   * might be more expensive than EX2 on some hw, plus it needs
@@ -709,8 +691,6 @@ _mesa_program_state_flags(const gl_state_index 
state[STATE_LENGTH])
   case STATE_NORMAL_SCALE:
  return _NEW_MODELVIEW;
 
-  case STATE_TEXRECT_SCALE:
-return _NEW_TEXTURE;
   case STATE_FOG_PARAMS_OPTIMIZED:
 return _NEW_FOG;
   case STATE_POINT_SIZE_CLAMPED:
@@ -905,9 +885,6 @@ append_token(char *dst, gl_state_index k)
case STATE_NORMAL_SCALE:
   append(dst, "normalScale");
   break;
-   case STATE_TEXRECT_SCALE:
-  append(dst, "texrectScale");
-  break;
case STATE_FOG_PARAMS_OPTIMIZED:
   append(dst, "fogParamsOptimized");
   break;
diff --git a/src/mesa/program/prog_statevars.h 
b/src/mesa/program/prog_statevars.h
index 7fecb37212d..3fdb413c421 100644
--- a/src/mesa/program/prog_statevars.h
+++ b/src/mesa/program/prog_statevars.h
@@ -117,7 +117,6 @@ typedef enum gl_state_index_ {
STATE_CURRENT_ATTRIB,/* ctx->Current vertex attrib value */
STATE_CURRENT_ATTRIB_MAYBE_VP_CLAMPED,/* ctx->Current vertex attrib 
value after passthrough vertex processing */
STATE_NORMAL_SCALE,
-   STATE_TEXRECT_SCALE,
STATE_FOG_PARAMS_OPTIMIZED,  /* for faster fog calc */
STATE_POINT_SIZE_CLAMPED,/* includes implementation dependent size 
clamp */
STATE_LIGHT_SPOT_DIR_NORMALIZED,   /* pre-normalized spot dir */
-- 
2.11.1

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

Re: [Mesa-dev] [PATCH 03/18] anv/cmd_buffer: Replace layout_to_hiz_usage()

[Nanley Chery]

On Tue, Feb 28, 2017 at 11:49:18AM -0800, Jason Ekstrand wrote:
> On Tue, Feb 28, 2017 at 11:35 AM, Nanley Chery 
> wrote:
> 
> > On Tue, Feb 28, 2017 at 08:16:43AM -0800, Jason Ekstrand wrote:
> > > On Tue, Feb 28, 2017 at 5:54 AM, Nanley Chery 
> > wrote:
> > >
> > > > On Mon, Feb 27, 2017 at 08:41:56PM -0800, Jason Ekstrand wrote:
> > > > > On Feb 27, 2017 5:21 PM, "Nanley Chery" 
> > wrote:
> > > > >
> > > > > Signed-off-by: Nanley Chery 
> > > > > ---
> > > > >  src/intel/vulkan/genX_cmd_buffer.c | 57
> > ++
> > > > > 
> > > > >  1 file changed, 15 insertions(+), 42 deletions(-)
> > > > >
> > > > > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> > > > > b/src/intel/vulkan/genX_cmd_buffer.c
> > > > > index 5171e6f587..60230bf14b 100644
> > > > > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > > > > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > > > > @@ -326,27 +326,6 @@ need_input_attachment_state(const struct
> > > > > anv_render_pass_attachment *att)
> > > > > return vk_format_is_color(att->format);
> > > > >  }
> > > > >
> > > > > -static enum isl_aux_usage
> > > > > -layout_to_hiz_usage(VkImageLayout layout, uint8_t samples)
> > > > > -{
> > > > > -   switch (layout) {
> > > > > -   case VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL:
> > > > > -  return ISL_AUX_USAGE_HIZ;
> > > > > -   case VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL:
> > > > > -   case VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL:
> > > > > -  if (anv_can_sample_with_hiz(GEN_GEN, samples))
> > > > > - return ISL_AUX_USAGE_HIZ;
> > > > > -  /* Fall-through */
> > > > > -   case VK_IMAGE_LAYOUT_GENERAL:
> > > > > -  /* This buffer could be used as a source or destination in a
> > > > transfer
> > > > > -   * operation. Transfer operations current don't perform
> > > > HiZ-enabled
> > > > > reads
> > > > > -   * and writes.
> > > > > -   */
> > > > > -   default:
> > > > > -  return ISL_AUX_USAGE_NONE;
> > > > > -   }
> > > > > -}
> > > > > -
> > > > >  /* Transitions a HiZ-enabled depth buffer from one layout to
> > another.
> > > > > Unless
> > > > >   * the initial layout is undefined, the HiZ buffer and depth buffer
> > will
> > > > >   * represent the same data at the end of this operation.
> > > > > @@ -362,21 +341,15 @@ transition_depth_buffer(struct anv_cmd_buffer
> > > > > *cmd_buffer,
> > > > > if (image->aux_usage != ISL_AUX_USAGE_HIZ || final_layout ==
> > > > > initial_layout)
> > > > >return;
> > > > >
> > > > > -   const bool hiz_enabled = layout_to_hiz_usage(initial_layout,
> > > > > image->samples) ==
> > > > > -ISL_AUX_USAGE_HIZ;
> > > > > -   const bool enable_hiz = layout_to_hiz_usage(final_layout,
> > > > > image->samples) ==
> > > > > -   ISL_AUX_USAGE_HIZ;
> > > > > +   const bool hiz_enabled = ISL_AUX_USAGE_HIZ ==
> > > > > +  anv_layout_to_aux_usage(GEN_GEN, image, image->aspects,
> > > > > +  initial_layout, final_layout);
> > > > > +   const bool enable_hiz = ISL_AUX_USAGE_HIZ ==
> > > > > +  anv_layout_to_aux_usage(GEN_GEN, image, image->aspects,
> > > > > +  final_layout, final_layout);
> > > > >
> > > > > enum blorp_hiz_op hiz_op;
> > > > > -   if (initial_layout == VK_IMAGE_LAYOUT_UNDEFINED) {
> > > > >
> > > > >
> > > > > I'm not sure how I feel about handling this in layout_to_aux_usage.
> > It
> > > > > seems like a conflation of two things.  If this is the only reason
> > for
> > > > the
> > > > > future_layout parameter, then it seems like it would be better
> > handled
> > > > > here.  In any case, I'll keep reading
> > > > >
> > > >
> > > > Yes, that is the only reason for the future_layout parameter. I can
> > > > remove it if you'd like.
> > > >
> > > > Currently the layout_to_aux_usage function determines the optimal
> > > > aux_usage for all device accesses: sampling, rendering, transferring,
> > > > and resolves. Removing the future_layout parameter would remove its
> > > > responsibility for the last access type.
> > > >
> > >
> > > In my brain, a transition from LAYOUT_UNDEFINED to LAYOUT_* is a
> > transition
> > > from AUX_USAGE_NONE to AUX_USAGE_*.  However, we know based on some other
> > > bits of the driver, that we can skip that particular resolve because the
> > > HiZ surface is in a non-hanging state.
> >
> > How does this tie into removing the parameter?
> >
> 
> I would argue that the obvious thing for a function named
> "layout_to_aux_usage" to return for UNDEFINED and PREINITIALIZED would be
> AUX_USAGE_NONE.  The fact that resolves want to skip that case doesn't seem
> to affect the fact that UNDEFINED and PREINITIALIZED things effectively
> have no aux.  It's more of a resolve optimization than a fundamental thing
> about layouts.
> 
> That's the way it works in my brain. 

[Mesa-dev] [Bug 98502] Delay when starting firefox, thunderbird or chromium and dmesg spam

[bugzilla-daemon]

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

--- Comment #22 from Eugene Shalygin  
---
(In reply to Mauro Santos from comment #21)
> The difference between both is that with 4.4.52 the device stays powered off
> when using lspci but with 4.9.11 the device is automatically powered on.
> This is using all the same software versions, the only difference is booting
> into different kernel versions.

I don't quite understand the situation too. I observe two opposite behaviours
with the same kernel version (4.9): lspci wakes up dGPU on ArchLinux or not
(Gentoo). Which one is bugged?

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

Re: [Mesa-dev] [PATCH] amd/common: fix ASICREV_IS_POLARIS11_M for Polaris12

[Dave Airlie]

On 1 March 2017 at 06:09, Marek Olšák  wrote:
> From: Marek Olšák 
>
> Cc: 17.0 

Reviewed-by: Dave Airlie 

> ---
>  src/amd/common/amdgpu_id.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/common/amdgpu_id.h b/src/amd/common/amdgpu_id.h
> index 1683a5a..1ecae1a 100644
> --- a/src/amd/common/amdgpu_id.h
> +++ b/src/amd/common/amdgpu_id.h
> @@ -150,21 +150,21 @@ enum {
>
>  #define ASICREV_IS_ICELAND_M(eChipRev) \
> (eChipRev < VI_TONGA_P_A0)
>  #define ASICREV_IS_TONGA_P(eChipRev)   \
> ((eChipRev >= VI_TONGA_P_A0) && (eChipRev < VI_FIJI_P_A0))
>  #define ASICREV_IS_FIJI_P(eChipRev)\
> ((eChipRev >= VI_FIJI_P_A0)  && (eChipRev < VI_POLARIS10_P_A0))
>  #define ASICREV_IS_POLARIS10_P(eChipRev)\
> ((eChipRev >= VI_POLARIS10_P_A0) && (eChipRev < VI_POLARIS11_M_A0))
>  #define ASICREV_IS_POLARIS11_M(eChipRev)   \
> -   (eChipRev >= VI_POLARIS11_M_A0)
> +   (eChipRev >= VI_POLARIS11_M_A0 && eChipRev < VI_POLARIS12_V_A0)
>  #define ASICREV_IS_POLARIS12_V(eChipRev)\
> (eChipRev >= VI_POLARIS12_V_A0)
>
>  /* CZ specific rev IDs */
>  enum {
> CARRIZO_A0   = 0x01,
>  STONEY_A0= 0x61,
> CZ_UNKNOWN  = 0xFF
>  };
>
> --
> 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] amd/common: fix ASICREV_IS_POLARIS11_M for Polaris12

[Alex Deucher]

On Tue, Feb 28, 2017 at 3:09 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> Cc: 17.0 

Reviewed-by: Alex Deucher 

> ---
>  src/amd/common/amdgpu_id.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/common/amdgpu_id.h b/src/amd/common/amdgpu_id.h
> index 1683a5a..1ecae1a 100644
> --- a/src/amd/common/amdgpu_id.h
> +++ b/src/amd/common/amdgpu_id.h
> @@ -150,21 +150,21 @@ enum {
>
>  #define ASICREV_IS_ICELAND_M(eChipRev) \
> (eChipRev < VI_TONGA_P_A0)
>  #define ASICREV_IS_TONGA_P(eChipRev)   \
> ((eChipRev >= VI_TONGA_P_A0) && (eChipRev < VI_FIJI_P_A0))
>  #define ASICREV_IS_FIJI_P(eChipRev)\
> ((eChipRev >= VI_FIJI_P_A0)  && (eChipRev < VI_POLARIS10_P_A0))
>  #define ASICREV_IS_POLARIS10_P(eChipRev)\
> ((eChipRev >= VI_POLARIS10_P_A0) && (eChipRev < VI_POLARIS11_M_A0))
>  #define ASICREV_IS_POLARIS11_M(eChipRev)   \
> -   (eChipRev >= VI_POLARIS11_M_A0)
> +   (eChipRev >= VI_POLARIS11_M_A0 && eChipRev < VI_POLARIS12_V_A0)
>  #define ASICREV_IS_POLARIS12_V(eChipRev)\
> (eChipRev >= VI_POLARIS12_V_A0)
>
>  /* CZ specific rev IDs */
>  enum {
> CARRIZO_A0   = 0x01,
>  STONEY_A0= 0x61,
> CZ_UNKNOWN  = 0xFF
>  };
>
> --
> 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] [PATCH] amd/common: fix ASICREV_IS_POLARIS11_M for Polaris12

[Marek Olšák]

From: Marek Olšák 

Cc: 17.0 
---
 src/amd/common/amdgpu_id.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/common/amdgpu_id.h b/src/amd/common/amdgpu_id.h
index 1683a5a..1ecae1a 100644
--- a/src/amd/common/amdgpu_id.h
+++ b/src/amd/common/amdgpu_id.h
@@ -150,21 +150,21 @@ enum {
 
 #define ASICREV_IS_ICELAND_M(eChipRev) \
(eChipRev < VI_TONGA_P_A0)
 #define ASICREV_IS_TONGA_P(eChipRev)   \
((eChipRev >= VI_TONGA_P_A0) && (eChipRev < VI_FIJI_P_A0))
 #define ASICREV_IS_FIJI_P(eChipRev)\
((eChipRev >= VI_FIJI_P_A0)  && (eChipRev < VI_POLARIS10_P_A0))
 #define ASICREV_IS_POLARIS10_P(eChipRev)\
((eChipRev >= VI_POLARIS10_P_A0) && (eChipRev < VI_POLARIS11_M_A0))
 #define ASICREV_IS_POLARIS11_M(eChipRev)   \
-   (eChipRev >= VI_POLARIS11_M_A0)
+   (eChipRev >= VI_POLARIS11_M_A0 && eChipRev < VI_POLARIS12_V_A0)
 #define ASICREV_IS_POLARIS12_V(eChipRev)\
(eChipRev >= VI_POLARIS12_V_A0)
 
 /* CZ specific rev IDs */
 enum {
CARRIZO_A0   = 0x01,
 STONEY_A0= 0x61,
CZ_UNKNOWN  = 0xFF
 };
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 03/18] anv/cmd_buffer: Replace layout_to_hiz_usage()

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 11:35 AM, Nanley Chery 
wrote:

> On Tue, Feb 28, 2017 at 08:16:43AM -0800, Jason Ekstrand wrote:
> > On Tue, Feb 28, 2017 at 5:54 AM, Nanley Chery 
> wrote:
> >
> > > On Mon, Feb 27, 2017 at 08:41:56PM -0800, Jason Ekstrand wrote:
> > > > On Feb 27, 2017 5:21 PM, "Nanley Chery" 
> wrote:
> > > >
> > > > Signed-off-by: Nanley Chery 
> > > > ---
> > > >  src/intel/vulkan/genX_cmd_buffer.c | 57
> ++
> > > > 
> > > >  1 file changed, 15 insertions(+), 42 deletions(-)
> > > >
> > > > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> > > > b/src/intel/vulkan/genX_cmd_buffer.c
> > > > index 5171e6f587..60230bf14b 100644
> > > > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > > > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > > > @@ -326,27 +326,6 @@ need_input_attachment_state(const struct
> > > > anv_render_pass_attachment *att)
> > > > return vk_format_is_color(att->format);
> > > >  }
> > > >
> > > > -static enum isl_aux_usage
> > > > -layout_to_hiz_usage(VkImageLayout layout, uint8_t samples)
> > > > -{
> > > > -   switch (layout) {
> > > > -   case VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL:
> > > > -  return ISL_AUX_USAGE_HIZ;
> > > > -   case VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL:
> > > > -   case VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL:
> > > > -  if (anv_can_sample_with_hiz(GEN_GEN, samples))
> > > > - return ISL_AUX_USAGE_HIZ;
> > > > -  /* Fall-through */
> > > > -   case VK_IMAGE_LAYOUT_GENERAL:
> > > > -  /* This buffer could be used as a source or destination in a
> > > transfer
> > > > -   * operation. Transfer operations current don't perform
> > > HiZ-enabled
> > > > reads
> > > > -   * and writes.
> > > > -   */
> > > > -   default:
> > > > -  return ISL_AUX_USAGE_NONE;
> > > > -   }
> > > > -}
> > > > -
> > > >  /* Transitions a HiZ-enabled depth buffer from one layout to
> another.
> > > > Unless
> > > >   * the initial layout is undefined, the HiZ buffer and depth buffer
> will
> > > >   * represent the same data at the end of this operation.
> > > > @@ -362,21 +341,15 @@ transition_depth_buffer(struct anv_cmd_buffer
> > > > *cmd_buffer,
> > > > if (image->aux_usage != ISL_AUX_USAGE_HIZ || final_layout ==
> > > > initial_layout)
> > > >return;
> > > >
> > > > -   const bool hiz_enabled = layout_to_hiz_usage(initial_layout,
> > > > image->samples) ==
> > > > -ISL_AUX_USAGE_HIZ;
> > > > -   const bool enable_hiz = layout_to_hiz_usage(final_layout,
> > > > image->samples) ==
> > > > -   ISL_AUX_USAGE_HIZ;
> > > > +   const bool hiz_enabled = ISL_AUX_USAGE_HIZ ==
> > > > +  anv_layout_to_aux_usage(GEN_GEN, image, image->aspects,
> > > > +  initial_layout, final_layout);
> > > > +   const bool enable_hiz = ISL_AUX_USAGE_HIZ ==
> > > > +  anv_layout_to_aux_usage(GEN_GEN, image, image->aspects,
> > > > +  final_layout, final_layout);
> > > >
> > > > enum blorp_hiz_op hiz_op;
> > > > -   if (initial_layout == VK_IMAGE_LAYOUT_UNDEFINED) {
> > > >
> > > >
> > > > I'm not sure how I feel about handling this in layout_to_aux_usage.
> It
> > > > seems like a conflation of two things.  If this is the only reason
> for
> > > the
> > > > future_layout parameter, then it seems like it would be better
> handled
> > > > here.  In any case, I'll keep reading
> > > >
> > >
> > > Yes, that is the only reason for the future_layout parameter. I can
> > > remove it if you'd like.
> > >
> > > Currently the layout_to_aux_usage function determines the optimal
> > > aux_usage for all device accesses: sampling, rendering, transferring,
> > > and resolves. Removing the future_layout parameter would remove its
> > > responsibility for the last access type.
> > >
> >
> > In my brain, a transition from LAYOUT_UNDEFINED to LAYOUT_* is a
> transition
> > from AUX_USAGE_NONE to AUX_USAGE_*.  However, we know based on some other
> > bits of the driver, that we can skip that particular resolve because the
> > HiZ surface is in a non-hanging state.
>
> How does this tie into removing the parameter?
>

I would argue that the obvious thing for a function named
"layout_to_aux_usage" to return for UNDEFINED and PREINITIALIZED would be
AUX_USAGE_NONE.  The fact that resolves want to skip that case doesn't seem
to affect the fact that UNDEFINED and PREINITIALIZED things effectively
have no aux.  It's more of a resolve optimization than a fundamental thing
about layouts.

That's the way it works in my brain.  But we have different brains. :-)

It sounds like you almost want an AUX_USAGE_DONT_CARE for those cases.
However, since the only thing that cares is resolves, we can just
special-case it there.


> > Also, the second parameter makes the function far less obvious and
> > every other call sight 

Re: [Mesa-dev] [PATCH 27/34] i965: Make CCS stride match kernel's expectations

[Jason Ekstrand]

On Mon, Feb 27, 2017 at 7:23 PM, Ben Widawsky  wrote:

> On 17-02-27 18:40:41, Jason Ekstrand wrote:
>
>> On Mon, Feb 27, 2017 at 5:38 PM, Jason Ekstrand 
>> wrote:
>>
>> On Mon, Feb 27, 2017 at 4:56 PM, Ben Widawsky  wrote:
>>>
>>> On 17-01-31 13:24:55, Jason Ekstrand wrote:

 On Mon, Jan 23, 2017 at 10:21 PM, Ben Widawsky 
> wrote:
>
> v2: Put the commit message as a comment (Topi)
>
>>
>> Cc: Topi Pohjolainen 
>> Cc: Ville Syrjälä 
>> Cc: Jason Ekstrand 
>> Signed-off-by: Ben Widawsky 
>> Acked-by: Daniel Stone 
>> ---
>>  src/mesa/drivers/dri/i965/intel_screen.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>> b/src/mesa/drivers/dri/i965/intel_screen.c
>> index 85070bb54d..12b3b071e4 100644
>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>> @@ -1023,7 +1023,10 @@ intel_from_planar(__DRIimage *parent, int
>> plane,
>> void *loaderPrivate)
>>  if (parent == NULL || parent->planar_format == NULL) {
>> if (is_aux) {
>>offset = parent->aux_offset;
>> -  stride = ALIGN(parent->pitch / 32, 128);
>> +  /* Make CCS stride match kernel's expectations. Mesa's
>> internals
>> +   * expect: stride = ALIGN(parent->pitch / 32, 128)
>> +   */
>> +  stride = ALIGN(parent->pitch / 64, 128);
>>
>>
>> I just realized that this doesn't match the picture you drew in 22/32
>> where
>> the CCS and the main color surface have the same stride.
>>
>>
> Here is the image, it seems correct to me. Is there some clarification
> you'd
> like me to make?
>
> ┌─┐
> │ │
> │ │
> │ │
> │  Image  │
> │ │
> │ │
> │x│
> ├─┬───┘
> │ │   |
> │ccs  │  unused   |
> └─┘---┘
> <--pitch-->
>

This picture matches what you do for allocation.  You divide the main
surface height by 64 (rounded up) to get the CCS surface height in Y-tiled
lines which is correct.  Then you add this to the height of the primary
surface and pass that to libdrm.  The amount of data allocated for the ccs
is then DIV_ROUND_UP(color.height, 64) * color.pitch.  That is way more
than enough data but the waste isn't too bad so whatever.

In patch 19, we use ISL to compute the CCS layout and it picks whatever
stride it wants which, I believe, will be ALIGN(color.width, 1024) / 8.
(Note this calculation is done based on the width of the color surface, not
the stride)

Then, in this patch, we tell the client that the pitch is ALIGN(color.pitch
/ 64, 128).  There is a factor of two in here thanks to the current kernel
API, but it's also based on color.pitch not color.width so it's liable to
mismatch with ISL.

We have three different calculations for the CCS pitch in three different
places and no two of them match.

It's fine if the allocation doesn't match the others so long as it's it's
large enough.  The other two, however, need to match (with a possible
factor of 2 difference).

Is that making sense?

--Jason


>
>> Does the kernel expect the alignment to be 128 or 64?  Given that ville
>>>
 likes 64-wide tiles, I think it should be 64.  Really, I think the more
> accurate calculation would be
>
> stride = ALIGN(parent->pitch, 4096) / 64;
>
>
 Isn't the actual CCS stride stored in parent->strides[0]?  Why are we
>> re-computing it from the plane 0 pitch?
>>
>>
> I believe the parent is just the parent image (ie. pixel data), in real
> planar
> images, we have the planes for the formats, but it's somewhat of a hack job
> here. If I have this wrong, or you have a better idea, please let me know.
>
>
>
>> 4096 is the stride in bytes in the primary surface required to cross a
>>>
 single CCS tile.  The calculation you have above will work in the sense
> that the worst that happens is for it to align up a bit too far.  In
> any
> case, what matters is that we a) have enough space and b) exactly match
> the
> kernel's calculation.
>
> --Jason
>
>
>
> This formula doesn't match the kernel's expectations (unless Ville has
 updated
 patches somewhere).


>>> Hrm... Ok.  Having the alignment too big won't break anything, it's just
>>> a
>>> bit odd.
>>>
>>>
>>> If you want I can do:
 stride = ALIGN(parent->pitch, 4096) / 128;

>>>
>>>
>>>  That' wouldn't match either.  Let's make sure the formulas match
>>> exactly.
>>>
>>>
>>>
___
mesa-dev mailing list

Re: [Mesa-dev] [PATCH 03/18] anv/cmd_buffer: Replace layout_to_hiz_usage()

[Nanley Chery]

On Tue, Feb 28, 2017 at 08:16:43AM -0800, Jason Ekstrand wrote:
> On Tue, Feb 28, 2017 at 5:54 AM, Nanley Chery  wrote:
> 
> > On Mon, Feb 27, 2017 at 08:41:56PM -0800, Jason Ekstrand wrote:
> > > On Feb 27, 2017 5:21 PM, "Nanley Chery"  wrote:
> > >
> > > Signed-off-by: Nanley Chery 
> > > ---
> > >  src/intel/vulkan/genX_cmd_buffer.c | 57 ++
> > > 
> > >  1 file changed, 15 insertions(+), 42 deletions(-)
> > >
> > > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> > > b/src/intel/vulkan/genX_cmd_buffer.c
> > > index 5171e6f587..60230bf14b 100644
> > > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > > @@ -326,27 +326,6 @@ need_input_attachment_state(const struct
> > > anv_render_pass_attachment *att)
> > > return vk_format_is_color(att->format);
> > >  }
> > >
> > > -static enum isl_aux_usage
> > > -layout_to_hiz_usage(VkImageLayout layout, uint8_t samples)
> > > -{
> > > -   switch (layout) {
> > > -   case VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL:
> > > -  return ISL_AUX_USAGE_HIZ;
> > > -   case VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL:
> > > -   case VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL:
> > > -  if (anv_can_sample_with_hiz(GEN_GEN, samples))
> > > - return ISL_AUX_USAGE_HIZ;
> > > -  /* Fall-through */
> > > -   case VK_IMAGE_LAYOUT_GENERAL:
> > > -  /* This buffer could be used as a source or destination in a
> > transfer
> > > -   * operation. Transfer operations current don't perform
> > HiZ-enabled
> > > reads
> > > -   * and writes.
> > > -   */
> > > -   default:
> > > -  return ISL_AUX_USAGE_NONE;
> > > -   }
> > > -}
> > > -
> > >  /* Transitions a HiZ-enabled depth buffer from one layout to another.
> > > Unless
> > >   * the initial layout is undefined, the HiZ buffer and depth buffer will
> > >   * represent the same data at the end of this operation.
> > > @@ -362,21 +341,15 @@ transition_depth_buffer(struct anv_cmd_buffer
> > > *cmd_buffer,
> > > if (image->aux_usage != ISL_AUX_USAGE_HIZ || final_layout ==
> > > initial_layout)
> > >return;
> > >
> > > -   const bool hiz_enabled = layout_to_hiz_usage(initial_layout,
> > > image->samples) ==
> > > -ISL_AUX_USAGE_HIZ;
> > > -   const bool enable_hiz = layout_to_hiz_usage(final_layout,
> > > image->samples) ==
> > > -   ISL_AUX_USAGE_HIZ;
> > > +   const bool hiz_enabled = ISL_AUX_USAGE_HIZ ==
> > > +  anv_layout_to_aux_usage(GEN_GEN, image, image->aspects,
> > > +  initial_layout, final_layout);
> > > +   const bool enable_hiz = ISL_AUX_USAGE_HIZ ==
> > > +  anv_layout_to_aux_usage(GEN_GEN, image, image->aspects,
> > > +  final_layout, final_layout);
> > >
> > > enum blorp_hiz_op hiz_op;
> > > -   if (initial_layout == VK_IMAGE_LAYOUT_UNDEFINED) {
> > >
> > >
> > > I'm not sure how I feel about handling this in layout_to_aux_usage.  It
> > > seems like a conflation of two things.  If this is the only reason for
> > the
> > > future_layout parameter, then it seems like it would be better handled
> > > here.  In any case, I'll keep reading
> > >
> >
> > Yes, that is the only reason for the future_layout parameter. I can
> > remove it if you'd like.
> >
> > Currently the layout_to_aux_usage function determines the optimal
> > aux_usage for all device accesses: sampling, rendering, transferring,
> > and resolves. Removing the future_layout parameter would remove its
> > responsibility for the last access type.
> >
> 
> In my brain, a transition from LAYOUT_UNDEFINED to LAYOUT_* is a transition
> from AUX_USAGE_NONE to AUX_USAGE_*.  However, we know based on some other
> bits of the driver, that we can skip that particular resolve because the
> HiZ surface is in a non-hanging state.

How does this tie into removing the parameter?

> Also, the second parameter makes the function far less obvious and
> every other call sight of the function, even though it doesn't care,
> has to think about that parmeter.
> 

I'll remove the responsibility of finding the optimal resolving
aux_usage from the function in v2.

-Nanley

> 
> > -Nanley
> >
> > > -  /* We've already initialized the aux HiZ buffer at BindImageMemory
> > > time,
> > > -   * so there's no need to perform a HIZ resolve or clear to avoid
> > GPU
> > > hangs.
> > > -   * This initial layout indicates that the user doesn't care about
> > > the data
> > > -   * that's currently in the buffer, so resolves are not necessary
> > > except
> > > -   * for the special case noted below.
> > > -   */
> > > -  hiz_op = BLORP_HIZ_OP_NONE;
> > > -   } else if (hiz_enabled && !enable_hiz) {
> > > +   if (hiz_enabled && !enable_hiz) {
> > >hiz_op = BLORP_HIZ_OP_DEPTH_RESOLVE;
> > > } else if (!hiz_enabled && enable_hiz) {
> 

Re: [Mesa-dev] problem on building vmwgfx

[Sinclair Yeh]

On Tue, Feb 28, 2017 at 04:41:48PM +, Eric Engestrom wrote:
> 
> Looks like there are more issues than I thought.
> I don't know this codebase at all, I just recognized the first error you
> saw and knew how to fix it.
> 
> For more in-depth help, I suggest asking Sinclair or Thomas (both Cc'ed).
> 
> Cheers,
>   Eric

Hi,

I checked in quite a bit of new code a few days ago, and this
looks like a build problem with kernel 3.13.x.

Zhiguang, if you need something immediately, just check out
a version of the vmwgfx from last week and it should build
fine.

I'll take a look at this.

Sinclair

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

Re: [Mesa-dev] Gallium: Removal of set_index_buffer (discussion)

[Marek Olšák]

On Tue, Feb 28, 2017 at 6:37 PM, Roland Scheidegger  wrote:
> Am 28.02.2017 um 17:11 schrieb Jose Fonseca:
>> On 20/02/17 20:28, Roland Scheidegger wrote:
>>> Am 20.02.2017 um 20:56 schrieb Marek Olšák:
 On Mon, Feb 20, 2017 at 8:29 PM, Axel Davy  wrote:
> On 20/02/2017 20:11, Ilia Mirkin wrote:
>>
>> On Mon, Feb 20, 2017 at 2:01 PM, Marek Olšák  wrote:
>>>
>>> Hi,
>>>
>>> I'd like to remove pipe_context::set_index_buffer. It's not useful to
>>> most drivers and the interface is inconvenient for Mesa/OpenGL,
>>> because it's a draw state that is set with a separate driver
>>> callback,
>>> which is an unnecessary driver roundtrip taking some CPU cycles. I'd
>>> prefer to pass the index buffer via pipe_draw_info.
>>>
>>> I'm aware that the interface was inherited from DX10, but I don't
>>> think that makes any difference here. DX10 state trackers can pass
>>> the
>>> index buffer via pipe_draw_info too.
>>>
>>> This is my proposal:
>>>
>>> iff --git a/src/gallium/include/pipe/p_state.h
>>> b/src/gallium/include/pipe/p_state.h
>>> index ce19b92..cffbb33 100644
>>> --- a/src/gallium/include/pipe/p_state.h
>>> +++ b/src/gallium/include/pipe/p_state.h
>>> @@ -635,7 +635,7 @@ struct pipe_index_buffer
>>>*/
>>>   struct pipe_draw_info
>>>   {
>>> -   boolean indexed;  /**< use index buffer */
>>> +   ubyte index_size;  /**< 0 = non-indexed */
>
> Isn't that enough to say non-index when index_buffer and
> user_indices are
> NULL ?

 We still need index_size and it's only 8 bits as opposed to 64 bits.
>>> FWIW at least in d3d10 you can actually have indexed rendering without
>>> an index buffer bound. This is perfectly valid, you're just expected to
>>> return always zero for all indices... Albeit I believe we actually deal
>>> with this with a dummy buffer.
>>
>> Yes.  I think that having index_buffer != NULL implying indexed buffer,
>> won't create any problems.
>>

>>>
>>>  enum pipe_prim_type mode;  /**< the mode of the primitive */
>>>  boolean primitive_restart;
>>>  ubyte vertices_per_patch; /**< the number of vertices per
>>> patch */
>>> @@ -666,12 +666,18 @@ struct pipe_draw_info
>>>
>>>  unsigned indirect_params_offset; /**< must be 4 byte aligned */
>>>
>>> +   /**
>>> +* Index buffer. Only one can be non-NULL.
>>> +*/
>>> +   struct pipe_resource *index_buffer; /* "start" is the offset */
>>
>> Works for me. Is start the offset in bytes or is start * index_size
>> the offset in bytes?
>
> Same question here. My understanding is that start is in terms of
> start *
> index_size bytes.

 offset = start * index_size;

> But we really want to have a byte offset.

 The offset should be aligned to index_size, otherwise hardware won't
 work.
>>> Are you sure of that? d3d10 doesn't seem to have such a requirement, or
>>> if it has I can't find it now (so, the startIndex really is in terms of
>>> index units, but the offset of the buffer is in terms of bytes, and the
>>> docs don't seem to mention it's limited to index alignment).
>>> I don't actually see such a limitation in GL neither, albeit some quick
>>> googling seems to suggest YMMV (e.g.
>>> http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7=51444).
>>> So, I can't quite tell right now if we really need byte offsets...
>>>
>>> Otherwise we should be able to deal with the interface change (that
>>> said, arguably the old one is quite consistent with the analogous
>>> set_vertex_buffers call - vulkan also has two analogous entry points for
>>> setting vertex and index buffers, so it can't be all that wrong).
>>> Do you have some evidence this really saves some measurable cpu cycles?
>>>
>>> Roland
>>
>> https://msdn.microsoft.com/en-us/library/windows/desktop/dn899216(v=vs.85).aspx
>> says:
>>
>>   Index data reads must be a multiple of the index data type size (i.e.
>> only from addresses that are naturally aligned for the data).
> Ahh that was what I couldn't find...
>
>>
>> But still, I think index buffer offsets should be in bytes, for
>> consistency, with APIs, and vertex buffer offsets.  See:
> Well I suppose it's sort of inconsistent either way, because buffer
> offsets are usually in bytes, but start indices in terms of elements.
> But we should be able to live with it either way - one or the other has
> to be converted depending on the type.

It's not really about consistency. Vertex buffers really need a byte
offset, because e.g. the offset of R8G8B8A8_UNORM doesn't have to a
multiple of element size (4), it must only be a multiple of channel
size (1). However, index buffers have only one "channel" per element,
thus start/count is sufficient.

Marek
___

Re: [Mesa-dev] [PATCH] vulkan: provide vk.xml as argument to the python generator

[Jason Ekstrand]

Thanks!

Reviewed-by: Jason Ekstrand 

On Tue, Feb 28, 2017 at 10:56 AM, Emil Velikov 
wrote:

> From: Emil Velikov 
>
> Do not hardcode the file in the python script, but pass it via the build
> system(s). The former is the only one that should know about the file
> locaiton/tree structure.
>
> Cc: Dylan Baker 
> Signed-off-by: Emil Velikov 
> ---
>  src/vulkan/Android.mk  | 2 +-
>  src/vulkan/Makefile.am | 2 +-
>  src/vulkan/util/gen_enum_to_str.py | 5 ++---
>  3 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/src/vulkan/Android.mk b/src/vulkan/Android.mk
> index 0825c1ac10..9f71d8ff8f 100644
> --- a/src/vulkan/Android.mk
> +++ b/src/vulkan/Android.mk
> @@ -45,7 +45,7 @@ vulkan_api_xml = $(MESA_TOP)/src/vulkan/registry/vk.xml
>  $(LOCAL_GENERATED_SOURCES): $(MESA_TOP)/src/vulkan/util/gen_enum_to_str.py
> $(vulkan_api_xml)
> @echo "target Generated: $(PRIVATE_MODULE) <= $(notdir $(@))"
> @mkdir -p $(dir $@)
> -   $(hide) $(MESA_PYTHON2) $(MESA_TOP)/src/vulkan/util/gen_enum_to_str.py
> --outdir $(intermediates)/util
> +   $(hide) $(MESA_PYTHON2) $(MESA_TOP)/src/vulkan/util/gen_enum_to_str.py
> --xml $(vulkan_api_xml) --outdir $(intermediates)/util
>
>  LOCAL_EXPORT_C_INCLUDE_DIRS := \
>  $(intermediates)
> diff --git a/src/vulkan/Makefile.am b/src/vulkan/Makefile.am
> index e28a81c8cf..f7aca8e937 100644
> --- a/src/vulkan/Makefile.am
> +++ b/src/vulkan/Makefile.am
> @@ -16,7 +16,7 @@ BUILT_SOURCES = \
>
>  util/vk_enum_to_str.c util/vk_enum_to_str.h: util/gen_enum_to_str.py
> $(vulkan_api_xml)
> $(MKDIR_GEN)
> -   $(PYTHON_GEN) $(srcdir)/util/gen_enum_to_str.py --outdir
> $(top_builddir)/src/vulkan/util
> +   $(PYTHON_GEN) $(srcdir)/util/gen_enum_to_str.py --xml
> $(vulkan_api_xml) --outdir $(top_builddir)/src/vulkan/util
>
>  libvulkan_util_la_SOURCES = $(VULKAN_UTIL_GENERATED_FILES)
>
> diff --git a/src/vulkan/util/gen_enum_to_str.py
> b/src/vulkan/util/gen_enum_to_str.py
> index 8c11569b6a..fb31addf94 100644
> --- a/src/vulkan/util/gen_enum_to_str.py
> +++ b/src/vulkan/util/gen_enum_to_str.py
> @@ -29,8 +29,6 @@ import xml.etree.cElementTree as et
>
>  from mako.template import Template
>
> -VK_XML = os.path.join(os.path.dirname(__file__), '..', 'registry',
> 'vk.xml')
> -
>  COPYRIGHT = textwrap.dedent(u"""\
>  * Copyright © 2017 Intel Corporation
>  *
> @@ -160,13 +158,14 @@ def xml_parser(filename):
>
>  def main():
>  parser = argparse.ArgumentParser()
> +parser.add_argument('--xml', help='Vulkan API XML file.',
> required=True)
>  parser.add_argument('--outdir',
>  help='Directory to put the generated files in',
>  required=True)
>
>  args = parser.parse_args()
>
> -enums = xml_parser(VK_XML)
> +enums = xml_parser(args.xml)
>  for template, file_ in [(C_TEMPLATE, os.path.join(args.outdir,
> 'vk_enum_to_str.c')),
>  (H_TEMPLATE, os.path.join(args.outdir,
> 'vk_enum_to_str.h'))]:
>  with open(file_, 'wb') as f:
> --
> 2.11.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 02/18] anv/image: Add anv_layout_to_aux_usage()

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 10:53 AM, Nanley Chery 
wrote:

> On Tue, Feb 28, 2017 at 10:38:12AM -0800, Jason Ekstrand wrote:
> > On Tue, Feb 28, 2017 at 10:32 AM, Nanley Chery 
> > wrote:
> >
> > > On Tue, Feb 28, 2017 at 08:26:56AM -0800, Jason Ekstrand wrote:
> > > > On Mon, Feb 27, 2017 at 5:20 PM, Nanley Chery  >
> > > wrote:
> > > >
> > > > > This function supersedes layout_to_hiz_usage().
> > > > >
> > > > > Signed-off-by: Nanley Chery 
> > > > > ---
> > > > >  src/intel/vulkan/anv_image.c   | 149
> ++
> > > > > +++
> > > > >  src/intel/vulkan/anv_private.h |   4 ++
> > > > >  2 files changed, 153 insertions(+)
> > > > >
> > > > > diff --git a/src/intel/vulkan/anv_image.c
> > > b/src/intel/vulkan/anv_image.c
> > > > > index cd142938e7..716cdf3a38 100644
> > > > > --- a/src/intel/vulkan/anv_image.c
> > > > > +++ b/src/intel/vulkan/anv_image.c
> > > > > @@ -432,6 +432,155 @@ void anv_GetImageSubresourceLayout(
> > > > > }
> > > > >  }
> > > > >
> > > > > +/**
> > > > > + * @brief This function determines the optimal buffer to use for
> > > device
> > > > > + * accesses given a VkImageLayout and other pieces of information
> > > needed
> > > > > to
> > > > > + * make that determination. Device accesses may include normal
> > > sampling
> > > > > and
> > > > > + * rendering operations or resolves.
> > > > > + *
> > > > > + * @param gen The generation of the Intel GPU.
> > > > > + * @param image The image that may contain a collection of
> buffers.
> > > > > + * @param aspects The aspect(s) of the image to be accessed.
> > > > > + * @param layout The current layout of the image aspect(s).
> > > > > + * @param future_layout The next layout of the image aspect(s), if
> > > known.
> > > > > + *  Otherwise this should be equal to the
> current
> > > > > layout.
> > > > > + *
> > > > > + * @return The primary buffer that should be used for the given
> > > layout.
> > > > > + */
> > > > > +enum isl_aux_usage
> > > > > +anv_layout_to_aux_usage(const uint8_t gen, const struct anv_image
> *
> > > const
> > > > > image,
> > > > >
> > > >
> > > > Might be better to take a gen_device_info rather than just the
> integer.
> > > > Since we're doing run-time checks anyway, the cost should be small.
> > > >
> > >
> > > What does this buy us?
> > >
> >
> > Nothing at the moment.  However, it is the more standard thing to pass in
> > and, if we ever need more information in the future, device_info is what
> > we'll want.  Or you could just pass in the anv_device to guarantee that
> we
> > have everything we would ever need.
> >
>
> I'm in favor of adding it when we need it, but I can make it take the
> device_info if you insist. My rationale is that if the function takes a
> device_info or anv_device, the function prototype would be unnecessarily
> ambiguous with respect to what device-related information is necessary
> to perform the mapping.
>

Certainly anv_device is probably a bit much since it doesn't (yet) depend
on any run-time information.  I could see that changing in the future
(environment variables, per-app parameters, etc.) but we can cross that
bridge when we come to it.  I don't really see an "information" difference
between an integer "gen" and a device info.  The one completely describes
the hardware and the other sort-of describes the hardware.  Also, I
wouldn't be terribly surprised if, in the future, whether or not we can
sample from HiZ starts to depend on half-gen or whether or not it's an atom
part.


> -Nanley
>
> >
> > > -Nanley
> > >
> > > >
> > > > > +const VkImageAspectFlags aspects,
> > > VkImageLayout
> > > > > layout,
> > > > > +const VkImageLayout future_layout)
> > > > > +{
> > > > > +   /* Validate the inputs. */
> > > > > +
> > > > > +   /* Intel GPUs prior to Gen7 are not supported in anv. */
> > > > > +   assert(gen >= 7);
> > > > > +
> > > > > +   /* The layout of a NULL image is not properly defined. */
> > > > > +   assert(image != NULL);
> > > > > +
> > > > > +   /* The aspects must be a subset of the image aspects. */
> > > > > +   assert(aspects & image->aspects && aspects <= image->aspects);
> > > > > +
> > > > > +   /* According to the Vulkan Spec, the following layouts are
> valid
> > > only
> > > > > as
> > > > > +* initial layouts in a layout transition and don't support
> device
> > > > > access.
> > > > > +* Therefore, the caller should not be setting the future
> layout to
> > > > > either.
> > > > > +*/
> > > > > +   assert(future_layout != VK_IMAGE_LAYOUT_UNDEFINED &&
> > > > > +  future_layout != VK_IMAGE_LAYOUT_PREINITIALIZED);
> > > > > +
> > > > > +   /* Determine the optimal buffer. */
> > > > > +
> > > > > +   /* If there is no auxiliary surface allocated, we must use the
> one
> > > and
> > > > > only
> > > > > +* main buffer.
> > > > > +

[Mesa-dev] [PATCH] vulkan: provide vk.xml as argument to the python generator

[Emil Velikov]

From: Emil Velikov 

Do not hardcode the file in the python script, but pass it via the build
system(s). The former is the only one that should know about the file
locaiton/tree structure.

Cc: Dylan Baker 
Signed-off-by: Emil Velikov 
---
 src/vulkan/Android.mk  | 2 +-
 src/vulkan/Makefile.am | 2 +-
 src/vulkan/util/gen_enum_to_str.py | 5 ++---
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/vulkan/Android.mk b/src/vulkan/Android.mk
index 0825c1ac10..9f71d8ff8f 100644
--- a/src/vulkan/Android.mk
+++ b/src/vulkan/Android.mk
@@ -45,7 +45,7 @@ vulkan_api_xml = $(MESA_TOP)/src/vulkan/registry/vk.xml
 $(LOCAL_GENERATED_SOURCES): $(MESA_TOP)/src/vulkan/util/gen_enum_to_str.py 
$(vulkan_api_xml)
@echo "target Generated: $(PRIVATE_MODULE) <= $(notdir $(@))"
@mkdir -p $(dir $@)
-   $(hide) $(MESA_PYTHON2) $(MESA_TOP)/src/vulkan/util/gen_enum_to_str.py 
--outdir $(intermediates)/util
+   $(hide) $(MESA_PYTHON2) $(MESA_TOP)/src/vulkan/util/gen_enum_to_str.py 
--xml $(vulkan_api_xml) --outdir $(intermediates)/util
 
 LOCAL_EXPORT_C_INCLUDE_DIRS := \
 $(intermediates)
diff --git a/src/vulkan/Makefile.am b/src/vulkan/Makefile.am
index e28a81c8cf..f7aca8e937 100644
--- a/src/vulkan/Makefile.am
+++ b/src/vulkan/Makefile.am
@@ -16,7 +16,7 @@ BUILT_SOURCES = \
 
 util/vk_enum_to_str.c util/vk_enum_to_str.h: util/gen_enum_to_str.py 
$(vulkan_api_xml)
$(MKDIR_GEN)
-   $(PYTHON_GEN) $(srcdir)/util/gen_enum_to_str.py --outdir 
$(top_builddir)/src/vulkan/util
+   $(PYTHON_GEN) $(srcdir)/util/gen_enum_to_str.py --xml $(vulkan_api_xml) 
--outdir $(top_builddir)/src/vulkan/util
 
 libvulkan_util_la_SOURCES = $(VULKAN_UTIL_GENERATED_FILES)
 
diff --git a/src/vulkan/util/gen_enum_to_str.py 
b/src/vulkan/util/gen_enum_to_str.py
index 8c11569b6a..fb31addf94 100644
--- a/src/vulkan/util/gen_enum_to_str.py
+++ b/src/vulkan/util/gen_enum_to_str.py
@@ -29,8 +29,6 @@ import xml.etree.cElementTree as et
 
 from mako.template import Template
 
-VK_XML = os.path.join(os.path.dirname(__file__), '..', 'registry', 'vk.xml')
-
 COPYRIGHT = textwrap.dedent(u"""\
 * Copyright © 2017 Intel Corporation
 *
@@ -160,13 +158,14 @@ def xml_parser(filename):
 
 def main():
 parser = argparse.ArgumentParser()
+parser.add_argument('--xml', help='Vulkan API XML file.', required=True)
 parser.add_argument('--outdir',
 help='Directory to put the generated files in',
 required=True)
 
 args = parser.parse_args()
 
-enums = xml_parser(VK_XML)
+enums = xml_parser(args.xml)
 for template, file_ in [(C_TEMPLATE, os.path.join(args.outdir, 
'vk_enum_to_str.c')),
 (H_TEMPLATE, os.path.join(args.outdir, 
'vk_enum_to_str.h'))]:
 with open(file_, 'wb') as f:
-- 
2.11.1

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

[Mesa-dev] [PATCH 7/7] anv: Implement VK_KHX_external_memory_fd (v2)

[Chad Versace]

From: Jason Ekstrand 


v2 (chadv):
  - Rebase.
  - Fix vkGetPhysicalDeviceImageFormatProperties2KHR when
handleType == 0.
  - Move handleType-independency comments out of handleType-switch, in
vkGetPhysicalDeviceExternalBufferPropertiesKHX.  Reduces diff in
future dma_buf patches.

Co-authored-with: Chad Versace 
---

On my branch wip/anv-external-memory.
  http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=wip/anv-external-memory

 src/intel/vulkan/anv_device.c   | 90 +
 src/intel/vulkan/anv_entrypoints_gen.py |  1 +
 src/intel/vulkan/anv_formats.c  | 59 ++---
 3 files changed, 133 insertions(+), 17 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 024e19f91b9..ec88547368a 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -310,6 +310,10 @@ static const VkExtensionProperties device_extensions[] = {
   .extensionName = VK_KHX_EXTERNAL_MEMORY_EXTENSION_NAME,
   .specVersion = 1,
},
+   {
+  .extensionName = VK_KHX_EXTERNAL_MEMORY_FD_EXTENSION_NAME,
+  .specVersion = 1,
+   },
 };
 
 static void *
@@ -1400,7 +1404,7 @@ VkResult anv_AllocateMemory(
 {
ANV_FROM_HANDLE(anv_device, device, _device);
struct anv_device_memory *mem;
-   VkResult result;
+   VkResult result = VK_SUCCESS;
 
assert(pAllocateInfo->sType == VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO);
 
@@ -1418,18 +1422,50 @@ VkResult anv_AllocateMemory(
if (mem == NULL)
   return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
 
-   /* The kernel is going to give us whole pages anyway */
-   uint64_t alloc_size = align_u64(pAllocateInfo->allocationSize, 4096);
-
-   result = anv_bo_init_new(>bo, device, alloc_size);
-   if (result != VK_SUCCESS)
-  goto fail;
-
mem->type_index = pAllocateInfo->memoryTypeIndex;
-
mem->map = NULL;
mem->map_size = 0;
 
+   const VkImportMemoryFdInfoKHX *fd_info =
+  vk_find_struct_const(pAllocateInfo->pNext, IMPORT_MEMORY_FD_INFO_KHX);
+
+   /* The Vulkan spec permits handleType to be 0, in which case the struct is
+* ignored.
+*/
+   if (fd_info && fd_info->handleType) {
+  /* At the moment, we only support the OPAQUE_FD memory type which is
+   * just a GEM buffer.
+   */
+  assert(fd_info->handleType ==
+ VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHX);
+
+  uint32_t gem_handle = anv_gem_fd_to_handle(device, fd_info->fd);
+  if (!gem_handle) {
+ result = vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHX);
+ goto fail;
+  }
+
+  /* From the Vulkan spec:
+   *
+   *"Importing memory from a file descriptor transfers ownership of
+   *the file descriptor from the application to the Vulkan
+   *implementation. The application must not perform any operations on
+   *the file descriptor after a successful import."
+   *
+   * If the import fails, we leave the file descriptor open.
+   */
+  close(fd_info->fd);
+
+  anv_bo_init(>bo, gem_handle, pAllocateInfo->allocationSize);
+   } else {
+  /* The kernel is going to give us whole pages anyway */
+  uint64_t alloc_size = align_u64(pAllocateInfo->allocationSize, 4096);
+
+  result = anv_bo_init_new(>bo, device, alloc_size);
+  if (result != VK_SUCCESS)
+ goto fail;
+   }
+
*pMem = anv_device_memory_to_handle(mem);
 
return VK_SUCCESS;
@@ -1440,6 +1476,42 @@ VkResult anv_AllocateMemory(
return result;
 }
 
+VkResult anv_GetMemoryFdKHX(
+VkDevicedevice_h,
+VkDeviceMemory  memory_h,
+VkExternalMemoryHandleTypeFlagBitsKHX   handleType,
+int*pFd)
+{
+   ANV_FROM_HANDLE(anv_device, dev, device_h);
+   ANV_FROM_HANDLE(anv_device_memory, mem, memory_h);
+
+   /* We support only one handle type. */
+   assert(handleType == VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHX);
+
+   int fd = anv_gem_handle_to_fd(dev, mem->bo.gem_handle);
+   if (fd == -1)
+  return vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHX);
+
+   *pFd = fd;
+
+   return VK_SUCCESS;
+}
+
+VkResult anv_GetMemoryFdPropertiesKHX(
+VkDevicedevice_h,
+VkExternalMemoryHandleTypeFlagBitsKHX   handleType,
+int fd,
+VkMemoryFdPropertiesKHX*pMemoryFdProperties)
+{
+   /* The valid usage section for this function says:
+*
+*"handleType must not be one of the handle types defined as opaque."
+*
+* Since we only handle opaque handles for now, there are no FD properties.
+*/
+   return VK_ERROR_INVALID_EXTERNAL_HANDLE_KHX;
+}
+
 void anv_FreeMemory(
 VkDevice_device,
 VkDeviceMemory  _mem,
diff 

[Mesa-dev] [PATCH 5/7] anv: Implement VK_KHX_external_memory_capabilities (v2)

[Chad Versace]

This is a complete but trivial implementation. It's trivial becasue We
support no external memory capabilities yet.  Most of the real work in
this commit is in reworking the UUIDs advertised by the driver.

v2 (chadv):
  - Fix chain traversal in vkGetPhysicalDeviceImageFormatProperties2KHR.
Extract VkPhysicalDeviceExternalImageFormatInfoKHX from the chain of
input structs, not the chain of output structs.
  - In vkGetPhysicalDeviceImageFormatProperties2KHR, iterate over the
input chain and the output chain separately. Reduces diff in future
dma_buf patches.

Co-authored-with: Jason Ekstrand 
---

On my branch wip/anv-external-memory.
  http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=wip/anv-external-memory

 src/intel/vulkan/anv_device.c   | 53 ---
 src/intel/vulkan/anv_entrypoints_gen.py |  1 +
 src/intel/vulkan/anv_formats.c  | 75 +
 src/intel/vulkan/anv_private.h  |  2 +
 4 files changed, 117 insertions(+), 14 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 3609670b348..9ee2e02ed51 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -74,11 +74,37 @@ anv_physical_device_init_uuids(struct anv_physical_device 
*device)
if (sha1_ctx == NULL)
   return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
 
+   /* The pipeline cache UUID is used for determining when a pipeline cache is
+* invalid.  It needs both a driver build and the PCI ID of the device.
+*/
_mesa_sha1_update(sha1_ctx, build_id_data(note), build_id_len);
_mesa_sha1_update(sha1_ctx, >chipset_id, 
sizeof(device->chipset_id));
_mesa_sha1_final(sha1_ctx, sha1);
memcpy(device->pipeline_cache_uuid, sha1, VK_UUID_SIZE);
 
+   /* The driver UUID is used for determining sharability of images and memory
+* between two Vulkan instances in separate processes.  People who want to
+* share memory need to also check the device UUID (below) so all this
+* needs to be is the build-id.
+*/
+   memcpy(device->driver_uuid, build_id_data(note), VK_UUID_SIZE);
+
+   sha1_ctx = _mesa_sha1_init();
+   if (sha1_ctx == NULL)
+  return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
+
+   /* The device UUID uniquely identifies the given device within the machine.
+* Since we never have more than one device, this doesn't need to be a real
+* UUID.  However, on the off-chance that someone tries to use this to
+* cache pre-tiled images or something of the like, we use the PCI ID and
+* some bits if ISL info to ensure that this is safe.
+*/
+   _mesa_sha1_update(sha1_ctx, >chipset_id, 
sizeof(device->chipset_id));
+   _mesa_sha1_update(sha1_ctx, >isl_dev.has_bit6_swizzling,
+ sizeof(device->isl_dev.has_bit6_swizzling));
+   _mesa_sha1_final(sha1_ctx, sha1);
+   memcpy(device->device_uuid, sha1, VK_UUID_SIZE);
+
return VK_SUCCESS;
 }
 
@@ -163,10 +189,6 @@ anv_physical_device_init(struct anv_physical_device 
*device,
   goto fail;
}
 
-   result = anv_physical_device_init_uuids(device);
-   if (result != VK_SUCCESS)
-  goto fail;
-
bool swizzled = anv_gem_get_bit6_swizzle(fd, I915_TILING_X);
 
/* GENs prior to 8 do not support EU/Subslice info */
@@ -206,14 +228,18 @@ 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;
 
+   isl_device_init(>isl_dev, >info, swizzled);
+
+   result = anv_physical_device_init_uuids(device);
+   if (result != VK_SUCCESS)
+  goto fail;
+
result = anv_init_wsi(device);
if (result != VK_SUCCESS) {
   ralloc_free(device->compiler);
   goto fail;
}
 
-   isl_device_init(>isl_dev, >info, swizzled);
-
device->local_fd = fd;
return VK_SUCCESS;
 
@@ -257,6 +283,10 @@ static const VkExtensionProperties global_extensions[] = {
   .extensionName = VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME,
   .specVersion = 1,
},
+   {
+  .extensionName = VK_KHX_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME,
+  .specVersion = 1,
+   },
 };
 
 static const VkExtensionProperties device_extensions[] = {
@@ -668,10 +698,21 @@ void anv_GetPhysicalDeviceProperties2KHR(
 VkPhysicalDevicephysicalDevice,
 VkPhysicalDeviceProperties2KHR* pProperties)
 {
+   ANV_FROM_HANDLE(anv_physical_device, pdevice, physicalDevice);
+
anv_GetPhysicalDeviceProperties(physicalDevice, >properties);
 
vk_foreach_struct(ext, pProperties->pNext) {
   switch (ext->sType) {
+  case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHX: {
+ VkPhysicalDeviceIDPropertiesKHX *id_props =
+(VkPhysicalDeviceIDPropertiesKHX *)ext;
+ memcpy(id_props->deviceUUID, pdevice->device_uuid, VK_UUID_SIZE);
+ memcpy(id_props->driverUUID, 

Re: [Mesa-dev] [PATCH 02/18] anv/image: Add anv_layout_to_aux_usage()

[Nanley Chery]

On Tue, Feb 28, 2017 at 10:38:12AM -0800, Jason Ekstrand wrote:
> On Tue, Feb 28, 2017 at 10:32 AM, Nanley Chery 
> wrote:
> 
> > On Tue, Feb 28, 2017 at 08:26:56AM -0800, Jason Ekstrand wrote:
> > > On Mon, Feb 27, 2017 at 5:20 PM, Nanley Chery 
> > wrote:
> > >
> > > > This function supersedes layout_to_hiz_usage().
> > > >
> > > > Signed-off-by: Nanley Chery 
> > > > ---
> > > >  src/intel/vulkan/anv_image.c   | 149 ++
> > > > +++
> > > >  src/intel/vulkan/anv_private.h |   4 ++
> > > >  2 files changed, 153 insertions(+)
> > > >
> > > > diff --git a/src/intel/vulkan/anv_image.c
> > b/src/intel/vulkan/anv_image.c
> > > > index cd142938e7..716cdf3a38 100644
> > > > --- a/src/intel/vulkan/anv_image.c
> > > > +++ b/src/intel/vulkan/anv_image.c
> > > > @@ -432,6 +432,155 @@ void anv_GetImageSubresourceLayout(
> > > > }
> > > >  }
> > > >
> > > > +/**
> > > > + * @brief This function determines the optimal buffer to use for
> > device
> > > > + * accesses given a VkImageLayout and other pieces of information
> > needed
> > > > to
> > > > + * make that determination. Device accesses may include normal
> > sampling
> > > > and
> > > > + * rendering operations or resolves.
> > > > + *
> > > > + * @param gen The generation of the Intel GPU.
> > > > + * @param image The image that may contain a collection of buffers.
> > > > + * @param aspects The aspect(s) of the image to be accessed.
> > > > + * @param layout The current layout of the image aspect(s).
> > > > + * @param future_layout The next layout of the image aspect(s), if
> > known.
> > > > + *  Otherwise this should be equal to the current
> > > > layout.
> > > > + *
> > > > + * @return The primary buffer that should be used for the given
> > layout.
> > > > + */
> > > > +enum isl_aux_usage
> > > > +anv_layout_to_aux_usage(const uint8_t gen, const struct anv_image *
> > const
> > > > image,
> > > >
> > >
> > > Might be better to take a gen_device_info rather than just the integer.
> > > Since we're doing run-time checks anyway, the cost should be small.
> > >
> >
> > What does this buy us?
> >
> 
> Nothing at the moment.  However, it is the more standard thing to pass in
> and, if we ever need more information in the future, device_info is what
> we'll want.  Or you could just pass in the anv_device to guarantee that we
> have everything we would ever need.
> 

I'm in favor of adding it when we need it, but I can make it take the
device_info if you insist. My rationale is that if the function takes a
device_info or anv_device, the function prototype would be unnecessarily
ambiguous with respect to what device-related information is necessary
to perform the mapping.

-Nanley

> 
> > -Nanley
> >
> > >
> > > > +const VkImageAspectFlags aspects,
> > VkImageLayout
> > > > layout,
> > > > +const VkImageLayout future_layout)
> > > > +{
> > > > +   /* Validate the inputs. */
> > > > +
> > > > +   /* Intel GPUs prior to Gen7 are not supported in anv. */
> > > > +   assert(gen >= 7);
> > > > +
> > > > +   /* The layout of a NULL image is not properly defined. */
> > > > +   assert(image != NULL);
> > > > +
> > > > +   /* The aspects must be a subset of the image aspects. */
> > > > +   assert(aspects & image->aspects && aspects <= image->aspects);
> > > > +
> > > > +   /* According to the Vulkan Spec, the following layouts are valid
> > only
> > > > as
> > > > +* initial layouts in a layout transition and don't support device
> > > > access.
> > > > +* Therefore, the caller should not be setting the future layout to
> > > > either.
> > > > +*/
> > > > +   assert(future_layout != VK_IMAGE_LAYOUT_UNDEFINED &&
> > > > +  future_layout != VK_IMAGE_LAYOUT_PREINITIALIZED);
> > > > +
> > > > +   /* Determine the optimal buffer. */
> > > > +
> > > > +   /* If there is no auxiliary surface allocated, we must use the one
> > and
> > > > only
> > > > +* main buffer.
> > > > +*/
> > > > +   if (image->aux_surface.isl.size == 0)
> > > > +  return ISL_AUX_USAGE_NONE;
> > > > +
> > > > +   /* All images that use an auxiliary surface are required to be
> > tiled.
> > > > */
> > > > +   assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
> > > > +
> > > > +   /* On BDW+, when clearing the stencil aspect of a depth stencil
> > image,
> > > > +* the HiZ buffer allows us to record the clear with a relatively
> > small
> > > > +* number of packets. Prior to BDW, the HiZ buffer provides no
> > known
> > > > benefit
> > > > +* to the stencil aspect.
> > > > +*/
> > > > +   if (gen < 8 && aspects == VK_IMAGE_ASPECT_STENCIL_BIT)
> > > > +  return ISL_AUX_USAGE_NONE;
> > > > +
> > > > +   /* The undefined layout indicates that the user doesn't care about
> > the
> > > > data
> > > > +* that's currently in the buffer. Therefore, the optimal buffer to
> > > > use 

Re: [Mesa-dev] [PATCH 02/18] anv/image: Add anv_layout_to_aux_usage()

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 10:32 AM, Nanley Chery 
wrote:

> On Tue, Feb 28, 2017 at 08:26:56AM -0800, Jason Ekstrand wrote:
> > On Mon, Feb 27, 2017 at 5:20 PM, Nanley Chery 
> wrote:
> >
> > > This function supersedes layout_to_hiz_usage().
> > >
> > > Signed-off-by: Nanley Chery 
> > > ---
> > >  src/intel/vulkan/anv_image.c   | 149 ++
> > > +++
> > >  src/intel/vulkan/anv_private.h |   4 ++
> > >  2 files changed, 153 insertions(+)
> > >
> > > diff --git a/src/intel/vulkan/anv_image.c
> b/src/intel/vulkan/anv_image.c
> > > index cd142938e7..716cdf3a38 100644
> > > --- a/src/intel/vulkan/anv_image.c
> > > +++ b/src/intel/vulkan/anv_image.c
> > > @@ -432,6 +432,155 @@ void anv_GetImageSubresourceLayout(
> > > }
> > >  }
> > >
> > > +/**
> > > + * @brief This function determines the optimal buffer to use for
> device
> > > + * accesses given a VkImageLayout and other pieces of information
> needed
> > > to
> > > + * make that determination. Device accesses may include normal
> sampling
> > > and
> > > + * rendering operations or resolves.
> > > + *
> > > + * @param gen The generation of the Intel GPU.
> > > + * @param image The image that may contain a collection of buffers.
> > > + * @param aspects The aspect(s) of the image to be accessed.
> > > + * @param layout The current layout of the image aspect(s).
> > > + * @param future_layout The next layout of the image aspect(s), if
> known.
> > > + *  Otherwise this should be equal to the current
> > > layout.
> > > + *
> > > + * @return The primary buffer that should be used for the given
> layout.
> > > + */
> > > +enum isl_aux_usage
> > > +anv_layout_to_aux_usage(const uint8_t gen, const struct anv_image *
> const
> > > image,
> > >
> >
> > Might be better to take a gen_device_info rather than just the integer.
> > Since we're doing run-time checks anyway, the cost should be small.
> >
>
> What does this buy us?
>

Nothing at the moment.  However, it is the more standard thing to pass in
and, if we ever need more information in the future, device_info is what
we'll want.  Or you could just pass in the anv_device to guarantee that we
have everything we would ever need.


> -Nanley
>
> >
> > > +const VkImageAspectFlags aspects,
> VkImageLayout
> > > layout,
> > > +const VkImageLayout future_layout)
> > > +{
> > > +   /* Validate the inputs. */
> > > +
> > > +   /* Intel GPUs prior to Gen7 are not supported in anv. */
> > > +   assert(gen >= 7);
> > > +
> > > +   /* The layout of a NULL image is not properly defined. */
> > > +   assert(image != NULL);
> > > +
> > > +   /* The aspects must be a subset of the image aspects. */
> > > +   assert(aspects & image->aspects && aspects <= image->aspects);
> > > +
> > > +   /* According to the Vulkan Spec, the following layouts are valid
> only
> > > as
> > > +* initial layouts in a layout transition and don't support device
> > > access.
> > > +* Therefore, the caller should not be setting the future layout to
> > > either.
> > > +*/
> > > +   assert(future_layout != VK_IMAGE_LAYOUT_UNDEFINED &&
> > > +  future_layout != VK_IMAGE_LAYOUT_PREINITIALIZED);
> > > +
> > > +   /* Determine the optimal buffer. */
> > > +
> > > +   /* If there is no auxiliary surface allocated, we must use the one
> and
> > > only
> > > +* main buffer.
> > > +*/
> > > +   if (image->aux_surface.isl.size == 0)
> > > +  return ISL_AUX_USAGE_NONE;
> > > +
> > > +   /* All images that use an auxiliary surface are required to be
> tiled.
> > > */
> > > +   assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
> > > +
> > > +   /* On BDW+, when clearing the stencil aspect of a depth stencil
> image,
> > > +* the HiZ buffer allows us to record the clear with a relatively
> small
> > > +* number of packets. Prior to BDW, the HiZ buffer provides no
> known
> > > benefit
> > > +* to the stencil aspect.
> > > +*/
> > > +   if (gen < 8 && aspects == VK_IMAGE_ASPECT_STENCIL_BIT)
> > > +  return ISL_AUX_USAGE_NONE;
> > > +
> > > +   /* The undefined layout indicates that the user doesn't care about
> the
> > > data
> > > +* that's currently in the buffer. Therefore, the optimal buffer to
> > > use is
> > > +* the same buffer that would be used in the next layout. This
> avoids
> > > the
> > > +* possibility of having to resolve in order to maintain coherency.
> > > +*
> > > +* The pre-initialized layout is undefined for optimally-tiled
> images.
> > > As
> > > +* guaranteed by the assertion above, all images that have reached
> this
> > > +* point are tiled.
> > > +   */
> > > +   if (layout == VK_IMAGE_LAYOUT_UNDEFINED ||
> > > +   layout == VK_IMAGE_LAYOUT_PREINITIALIZED)
> > > +  layout = future_layout;
> > > +
> > > +   const bool has_depth = aspects & VK_IMAGE_ASPECT_DEPTH_BIT;
> > > +   

Re: [Mesa-dev] [PATCH 02/18] anv/image: Add anv_layout_to_aux_usage()

[Nanley Chery]

On Tue, Feb 28, 2017 at 08:26:56AM -0800, Jason Ekstrand wrote:
> On Mon, Feb 27, 2017 at 5:20 PM, Nanley Chery  wrote:
> 
> > This function supersedes layout_to_hiz_usage().
> >
> > Signed-off-by: Nanley Chery 
> > ---
> >  src/intel/vulkan/anv_image.c   | 149 ++
> > +++
> >  src/intel/vulkan/anv_private.h |   4 ++
> >  2 files changed, 153 insertions(+)
> >
> > diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> > index cd142938e7..716cdf3a38 100644
> > --- a/src/intel/vulkan/anv_image.c
> > +++ b/src/intel/vulkan/anv_image.c
> > @@ -432,6 +432,155 @@ void anv_GetImageSubresourceLayout(
> > }
> >  }
> >
> > +/**
> > + * @brief This function determines the optimal buffer to use for device
> > + * accesses given a VkImageLayout and other pieces of information needed
> > to
> > + * make that determination. Device accesses may include normal sampling
> > and
> > + * rendering operations or resolves.
> > + *
> > + * @param gen The generation of the Intel GPU.
> > + * @param image The image that may contain a collection of buffers.
> > + * @param aspects The aspect(s) of the image to be accessed.
> > + * @param layout The current layout of the image aspect(s).
> > + * @param future_layout The next layout of the image aspect(s), if known.
> > + *  Otherwise this should be equal to the current
> > layout.
> > + *
> > + * @return The primary buffer that should be used for the given layout.
> > + */
> > +enum isl_aux_usage
> > +anv_layout_to_aux_usage(const uint8_t gen, const struct anv_image * const
> > image,
> >
> 
> Might be better to take a gen_device_info rather than just the integer.
> Since we're doing run-time checks anyway, the cost should be small.
> 

What does this buy us?

-Nanley

> 
> > +const VkImageAspectFlags aspects, VkImageLayout
> > layout,
> > +const VkImageLayout future_layout)
> > +{
> > +   /* Validate the inputs. */
> > +
> > +   /* Intel GPUs prior to Gen7 are not supported in anv. */
> > +   assert(gen >= 7);
> > +
> > +   /* The layout of a NULL image is not properly defined. */
> > +   assert(image != NULL);
> > +
> > +   /* The aspects must be a subset of the image aspects. */
> > +   assert(aspects & image->aspects && aspects <= image->aspects);
> > +
> > +   /* According to the Vulkan Spec, the following layouts are valid only
> > as
> > +* initial layouts in a layout transition and don't support device
> > access.
> > +* Therefore, the caller should not be setting the future layout to
> > either.
> > +*/
> > +   assert(future_layout != VK_IMAGE_LAYOUT_UNDEFINED &&
> > +  future_layout != VK_IMAGE_LAYOUT_PREINITIALIZED);
> > +
> > +   /* Determine the optimal buffer. */
> > +
> > +   /* If there is no auxiliary surface allocated, we must use the one and
> > only
> > +* main buffer.
> > +*/
> > +   if (image->aux_surface.isl.size == 0)
> > +  return ISL_AUX_USAGE_NONE;
> > +
> > +   /* All images that use an auxiliary surface are required to be tiled.
> > */
> > +   assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
> > +
> > +   /* On BDW+, when clearing the stencil aspect of a depth stencil image,
> > +* the HiZ buffer allows us to record the clear with a relatively small
> > +* number of packets. Prior to BDW, the HiZ buffer provides no known
> > benefit
> > +* to the stencil aspect.
> > +*/
> > +   if (gen < 8 && aspects == VK_IMAGE_ASPECT_STENCIL_BIT)
> > +  return ISL_AUX_USAGE_NONE;
> > +
> > +   /* The undefined layout indicates that the user doesn't care about the
> > data
> > +* that's currently in the buffer. Therefore, the optimal buffer to
> > use is
> > +* the same buffer that would be used in the next layout. This avoids
> > the
> > +* possibility of having to resolve in order to maintain coherency.
> > +*
> > +* The pre-initialized layout is undefined for optimally-tiled images.
> > As
> > +* guaranteed by the assertion above, all images that have reached this
> > +* point are tiled.
> > +   */
> > +   if (layout == VK_IMAGE_LAYOUT_UNDEFINED ||
> > +   layout == VK_IMAGE_LAYOUT_PREINITIALIZED)
> > +  layout = future_layout;
> > +
> > +   const bool has_depth = aspects & VK_IMAGE_ASPECT_DEPTH_BIT;
> > +   const bool color_aspect = aspects == VK_IMAGE_ASPECT_COLOR_BIT;
> > +
> > +   /* The following switch currently only handles depth stencil aspects.
> > +* TODO: Handle the color aspect.
> > +*/
> > +   if (color_aspect)
> > +  return image->aux_usage;
> > +
> > +   switch (layout) {
> > +
> > +   /* Invalid Layouts */
> > +   case VK_IMAGE_LAYOUT_UNDEFINED:
> > +   case VK_IMAGE_LAYOUT_PREINITIALIZED:
> > +   case VK_IMAGE_LAYOUT_RANGE_SIZE:
> > +   case VK_IMAGE_LAYOUT_MAX_ENUM:
> > +  unreachable("Invalid image layout.");
> > +
> > +
> > +   /* Transfer Layouts
> > +*
> > +* 

Re: [Mesa-dev] [PATCH 04/18] anv: Update the HiZ sampling helper

[Nanley Chery]

On Tue, Feb 28, 2017 at 09:33:26AM -0800, Jason Ekstrand wrote:
> On Tue, Feb 28, 2017 at 9:29 AM, Nanley Chery  wrote:
> 
> > On Tue, Feb 28, 2017 at 08:07:35AM -0800, Jason Ekstrand wrote:
> > > On Tue, Feb 28, 2017 at 8:02 AM, Nanley Chery 
> > wrote:
> > >
> > > > On Mon, Feb 27, 2017 at 08:48:48PM -0800, Jason Ekstrand wrote:
> > > > > On Feb 27, 2017 5:20 PM, "Nanley Chery" 
> > wrote:
> > > > >
> > > > > Validate the inputs and actually verify that this image has a depth
> > > > > buffer.
> > > > >
> > > > > Signed-off-by: Nanley Chery 
> > > > > ---
> > > > >  src/intel/vulkan/anv_blorp.c   | 1 +
> > > > >  src/intel/vulkan/anv_image.c   | 7 +++
> > > > >  src/intel/vulkan/anv_private.h | 7 +--
> > > > >  3 files changed, 9 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/src/intel/vulkan/anv_blorp.c
> > b/src/intel/vulkan/anv_blorp.c
> > > > > index 2cde3b7689..05250de06a 100644
> > > > > --- a/src/intel/vulkan/anv_blorp.c
> > > > > +++ b/src/intel/vulkan/anv_blorp.c
> > > > > @@ -1276,6 +1276,7 @@ anv_cmd_buffer_clear_subpass(struct
> > anv_cmd_buffer
> > > > > *cmd_buffer)
> > > > > clear_with_hiz = false;
> > > > >  } else if (gen == 8 &&
> > > > > anv_can_sample_with_hiz(cmd_
> > > > > buffer->device->info.gen,
> > > > > +   iview->aspect_mask,
> > > > >
> >  iview->image->samples)) {
> > > > > /* Only gen9+ supports returning ANV_HZ_FC_VAL when
> > > > > sampling a
> > > > >  * fast-cleared portion of a HiZ buffer. Testing has
> > > > > revealed
> > > > > diff --git a/src/intel/vulkan/anv_image.c
> > b/src/intel/vulkan/anv_image.c
> > > > > index 716cdf3a38..f9f264094f 100644
> > > > > --- a/src/intel/vulkan/anv_image.c
> > > > > +++ b/src/intel/vulkan/anv_image.c
> > > > > @@ -502,7 +502,6 @@ anv_layout_to_aux_usage(const uint8_t gen, const
> > > > struct
> > > > > anv_image * const image,
> > > > > layout == VK_IMAGE_LAYOUT_PREINITIALIZED)
> > > > >layout = future_layout;
> > > > >
> > > > > -   const bool has_depth = aspects & VK_IMAGE_ASPECT_DEPTH_BIT;
> > > > > const bool color_aspect = aspects == VK_IMAGE_ASPECT_COLOR_BIT;
> > > > >
> > > > > /* The following switch currently only handles depth stencil
> > aspects.
> > > > > @@ -538,7 +537,7 @@ anv_layout_to_aux_usage(const uint8_t gen, const
> > > > struct
> > > > > anv_image * const image,
> > > > >assert(!color_aspect);
> > > > >/* Fall-through */
> > > > > case VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL:
> > > > > -  if (has_depth && anv_can_sample_with_hiz(gen, image->samples))
> > > > > +  if (anv_can_sample_with_hiz(gen, aspects, image->samples))
> > > > >   return ISL_AUX_USAGE_HIZ;
> > > > >else
> > > > >   return ISL_AUX_USAGE_NONE;
> > > > > @@ -699,8 +698,8 @@ anv_CreateImageView(VkDevice _device,
> > > > > float red_clear_color = 0.0f;
> > > > > enum isl_aux_usage surf_usage = image->aux_usage;
> > > > > if (image->aux_usage == ISL_AUX_USAGE_HIZ) {
> > > > > -  if (iview->aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT &&
> > > > > -  anv_can_sample_with_hiz(device->info.gen,
> > image->samples)) {
> > > > > +  if (anv_can_sample_with_hiz(device->info.gen,
> > iview->aspect_mask,
> > > > > +  image->samples)) {
> > > > >   /* When a HiZ buffer is sampled on gen9+, ensure that
> > > > >* the constant fast clear value is set in the surface
> > state.
> > > > >*/
> > > > > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> > > > private.h
> > > > > index 5ce9027f88..b21a9fb359 100644
> > > > > --- a/src/intel/vulkan/anv_private.h
> > > > > +++ b/src/intel/vulkan/anv_private.h
> > > > > @@ -1661,9 +1661,12 @@ struct anv_image {
> > > > >
> > > > >  /* Returns true if a HiZ-enabled depth buffer can be sampled from.
> > */
> > > > >  static inline bool
> > > > > -anv_can_sample_with_hiz(uint8_t gen, uint32_t samples)
> > > > > +anv_can_sample_with_hiz(uint8_t gen, VkImageAspectFlags
> > aspect_mask,
> > > > > +uint32_t samples)
> > > > >  {
> > > > > -   return gen >= 8 && samples == 1;
> > > > > +   /* Validate the inputs. */
> > > > > +   assert(gen >= 7 && aspect_mask && samples);
> > > > > +   return gen >= 8 && aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT &&
> > samples
> > > > > == 1;
> > > > >
> > > > >
> > > > > I think you want parents around the "aspect & DEPTH"
> > > > >
> > > >
> > > > According to the C11 spec (footnote 85 found under section 6.5
> > > > Expressions), the parenthesis are not necessary because the bitwise AND
> > > > operator has higher precedence than the logical AND operator.
> > > >
> > >
> > > I figured but the compiler likes to warn about those things and I 

Re: [Mesa-dev] [PATCH] android: vulkan: add support for libmesa_vulkan_{util, wsi}

[Emil Velikov]

On 28 February 2017 at 16:05, Eric Engestrom  wrote:

>> > The quick and dirty fix is to add a rule forcing the serialisation, like
>> > this:
>> >   util/vk_enum_to_str.c: util/vk_enum_to_str.h
>> > This fixes the race condition, but still writes both files twice for no
>> > reason.
>> >
>> Are you sure that will generate them twice - can you elaborate a bit ?
>
> You can try it yourself with this makefile:
> 8<
> all: foo bar
> foo bar:
> echo $@
> >8
>
> $ make
> echo foo
> foo
> echo bar
> bar
>
> It runs both targets, regardless of the fact they have the same rule.
>
I was wondering about the "foo.c: bar.h" case, like below.

8<
all: foo.c bar.h

bar.h:
@echo $@

foo.c: bar.h
>8

$make -f foo
bar.h

It does it once on my end. Perhaps I'm missing something ?

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

[Mesa-dev] [Bug 99849] Dashed lines (drawn via GLAMOR) are not rendered correctly

[bugzilla-daemon]

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

Roland Scheidegger  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |xorg-t...@lists.x.org
   |org |
 QA Contact|mesa-dev@lists.freedesktop. |xorg-t...@lists.x.org
   |org |
Product|Mesa|xorg
  Component|Mesa core   |Server/Acceleration/glamor

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

Re: [Mesa-dev] [PATCH 6/7] anv: Implement VK_KHX_external_memory

[Chad Versace]

On Mon 27 Feb 2017, Jason Ekstrand wrote:
> There's really nothing for us to do here.  So long as the user doesn't
> set any crazy environment variables such as INTEL_VK_HIZ=false, all of
> the compression formats etc. should "just work" at least for opaque
> handle types.
> ---
>  src/intel/vulkan/anv_device.c   | 6 +-
>  src/intel/vulkan/anv_entrypoints_gen.py | 1 +
>  2 files changed, 6 insertions(+), 1 deletion(-)

Patch 6 is
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99849] Dashed lines (drawn via GLAMOR) are not rendered correctly

[bugzilla-daemon]

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

--- Comment #6 from Roland Scheidegger  ---
FWIW I've actually captured a replay and when playing back on a nvidia blob, it
doesn't show a dashed line neither (just solid).

I'm inclined to believe this is a glamor bug. The shader does
   float pattern = texture2D(dash, vec2(dash_offset, 0.5)).w;
   if (pattern == 0.0)
   discard;

But the texture bound at that time is indeed GL_RED, so of course the result of
the texture lookup is always 1.0 no matter what.
Fixing the shader (use .r instead) gets a dashed line.
I have no idea how that can work anywhere (and even less of an idea why it
would be different on intel hw), or maybe glamor uses alpha textures sometimes
instead, I couldn't quite figure out how the 8 bit format gets mapped to a gl
format in the end...

No idea what's the right component for glamor bugs, though...

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

Re: [Mesa-dev] Gallium: Removal of set_index_buffer (discussion)

[Roland Scheidegger]

Am 28.02.2017 um 17:11 schrieb Jose Fonseca:
> On 20/02/17 20:28, Roland Scheidegger wrote:
>> Am 20.02.2017 um 20:56 schrieb Marek Olšák:
>>> On Mon, Feb 20, 2017 at 8:29 PM, Axel Davy  wrote:
 On 20/02/2017 20:11, Ilia Mirkin wrote:
>
> On Mon, Feb 20, 2017 at 2:01 PM, Marek Olšák  wrote:
>>
>> Hi,
>>
>> I'd like to remove pipe_context::set_index_buffer. It's not useful to
>> most drivers and the interface is inconvenient for Mesa/OpenGL,
>> because it's a draw state that is set with a separate driver
>> callback,
>> which is an unnecessary driver roundtrip taking some CPU cycles. I'd
>> prefer to pass the index buffer via pipe_draw_info.
>>
>> I'm aware that the interface was inherited from DX10, but I don't
>> think that makes any difference here. DX10 state trackers can pass
>> the
>> index buffer via pipe_draw_info too.
>>
>> This is my proposal:
>>
>> iff --git a/src/gallium/include/pipe/p_state.h
>> b/src/gallium/include/pipe/p_state.h
>> index ce19b92..cffbb33 100644
>> --- a/src/gallium/include/pipe/p_state.h
>> +++ b/src/gallium/include/pipe/p_state.h
>> @@ -635,7 +635,7 @@ struct pipe_index_buffer
>>*/
>>   struct pipe_draw_info
>>   {
>> -   boolean indexed;  /**< use index buffer */
>> +   ubyte index_size;  /**< 0 = non-indexed */

 Isn't that enough to say non-index when index_buffer and
 user_indices are
 NULL ?
>>>
>>> We still need index_size and it's only 8 bits as opposed to 64 bits.
>> FWIW at least in d3d10 you can actually have indexed rendering without
>> an index buffer bound. This is perfectly valid, you're just expected to
>> return always zero for all indices... Albeit I believe we actually deal
>> with this with a dummy buffer.
> 
> Yes.  I think that having index_buffer != NULL implying indexed buffer,
> won't create any problems.
> 
>>>
>>
>>  enum pipe_prim_type mode;  /**< the mode of the primitive */
>>  boolean primitive_restart;
>>  ubyte vertices_per_patch; /**< the number of vertices per
>> patch */
>> @@ -666,12 +666,18 @@ struct pipe_draw_info
>>
>>  unsigned indirect_params_offset; /**< must be 4 byte aligned */
>>
>> +   /**
>> +* Index buffer. Only one can be non-NULL.
>> +*/
>> +   struct pipe_resource *index_buffer; /* "start" is the offset */
>
> Works for me. Is start the offset in bytes or is start * index_size
> the offset in bytes?

 Same question here. My understanding is that start is in terms of
 start *
 index_size bytes.
>>>
>>> offset = start * index_size;
>>>
 But we really want to have a byte offset.
>>>
>>> The offset should be aligned to index_size, otherwise hardware won't
>>> work.
>> Are you sure of that? d3d10 doesn't seem to have such a requirement, or
>> if it has I can't find it now (so, the startIndex really is in terms of
>> index units, but the offset of the buffer is in terms of bytes, and the
>> docs don't seem to mention it's limited to index alignment).
>> I don't actually see such a limitation in GL neither, albeit some quick
>> googling seems to suggest YMMV (e.g.
>> http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7=51444).
>> So, I can't quite tell right now if we really need byte offsets...
>>
>> Otherwise we should be able to deal with the interface change (that
>> said, arguably the old one is quite consistent with the analogous
>> set_vertex_buffers call - vulkan also has two analogous entry points for
>> setting vertex and index buffers, so it can't be all that wrong).
>> Do you have some evidence this really saves some measurable cpu cycles?
>>
>> Roland
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dn899216(v=vs.85).aspx
> says:
> 
>   Index data reads must be a multiple of the index data type size (i.e.
> only from addresses that are naturally aligned for the data).
Ahh that was what I couldn't find...

> 
> But still, I think index buffer offsets should be in bytes, for
> consistency, with APIs, and vertex buffer offsets.  See:
Well I suppose it's sort of inconsistent either way, because buffer
offsets are usually in bytes, but start indices in terms of elements.
But we should be able to live with it either way - one or the other has
to be converted depending on the type.

Roland


> 
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ff476898(v=vs.85).aspx#Index_Buffer
> 
> 
> 
> Having index buffer offsets being in elements is confusing -- it doesn't
> match the D3D10 API or GL API (since both take bytes), and it's
> semantically identical to pipe_draw_info::start member.
> 
> 
> That is, we if don't want index buffer offset in bytes, then we should
> eliminate it alltogether...
> 
> 
> I guess the question is: does hardware have different registers for
> "IndexBufferOffset" and "StartIndexLocation", or 

Re: [Mesa-dev] [PATCH 9/9] anv: Implement support for exporting semaphores as FENCE_FD

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 9:25 AM, Chris Wilson 
wrote:

> On Tue, Feb 28, 2017 at 08:56:47AM -0800, Jason Ekstrand wrote:
> > ---
> >  src/intel/vulkan/anv_batch_chain.c | 91 ++
> ++--
> >  src/intel/vulkan/anv_device.c  | 26 +++
> >  src/intel/vulkan/anv_gem.c | 36 +++
> >  src/intel/vulkan/anv_private.h |  9 +++-
> >  src/intel/vulkan/anv_queue.c   | 68 +---
> >  5 files changed, 220 insertions(+), 10 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_batch_chain.c
> b/src/intel/vulkan/anv_batch_chain.c
> > index 3640588..004594a 100644
> > --- a/src/intel/vulkan/anv_batch_chain.c
> > +++ b/src/intel/vulkan/anv_batch_chain.c
> > @@ -1352,6 +1352,28 @@ setup_execbuf_for_cmd_buffer(struct anv_execbuf
> *execbuf,
> > }
> >  }
> >
> > +static void
> > +setup_empty_execbuf(struct anv_execbuf *execbuf, struct anv_device
> *device)
> > +{
> > +   anv_execbuf_add_bo(execbuf, >trivial_batch_bo, NULL, 0,
> > +  >alloc);
> > +
> > +   execbuf->execbuf = (struct drm_i915_gem_execbuffer2) {
>
> Does mesa check for gcc > 4.4?
>

We use designated initializers all over the place.  This won't be the first
thing to not compile on old gcc.


>
> > +  .buffers_ptr = (uintptr_t) execbuf->objects,
> > +  .buffer_count = execbuf->bo_count,
> > +  .batch_start_offset = 0,
> > +  .batch_len = 8, /* GEN8_MI_BATCH_BUFFER_END and NOOP */
>
> > +  .cliprects_ptr = 0,
> > +  .num_cliprects = 0,
> > +  .DR1 = 0,
> > +  .DR4 = 0,
>
> Best left to the compiler to clear, and don't mention DRI1 leftovers.
>

Fair enough.  I can do a pre-patch or a follow-on to get rid of those.


> > +  .flags = I915_EXEC_HANDLE_LUT | I915_EXEC_RENDER |
> > +   I915_EXEC_CONSTANTS_REL_GENERAL,
>
> Just drop EXEC_CONSTANTS; it is entirely dead and best forgotten.
>

Yeah...


> > +  .rsvd1 = device->context_id,
> > +  .rsvd2 = 0,
> > +   };
> > +}
>
>
> >  VkResult
> >  anv_cmd_buffer_execbuf(struct anv_device *device,
> > struct anv_cmd_buffer *cmd_buffer,
>
> > +   if (need_out_fence)
> > +  execbuf.execbuf.flags |= I915_EXEC_FENCE_OUT;
> >
> > VkResult result = anv_device_execbuf(device, ,
> execbuf.bos);
> >
> > +   if (need_out_fence) {
> > +  int out_fence = execbuf.execbuf.rsvd2 >> 32;
> > +  for (uint32_t i = 0; i < num_out_semaphores; i++) {
> > + ANV_FROM_HANDLE(anv_semaphore, semaphore, out_semaphores[i]);
> > + /* Out fences can't have temporary state because that would
> imply
> > +  * that we imported a sync file and are trying to signal it.
> > +  */
> > + assert(semaphore->temporary.type == ANV_SEMAPHORE_TYPE_NONE);
> > + struct anv_semaphore_impl *impl = >permanent;
> > +
> > + if (impl->type == ANV_SEMAPHORE_TYPE_SYNC_FILE) {
> > +assert(impl->fd == -1);
> > +impl->fd = dup(out_fence);
>
> out_fence will still be zero/stdin if anv_device_execbuf() failed.
>

 Good catch!  Best not to close stdin.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 13/18] anv/pass: Store subpass attachment reference list

[Nanley Chery]

On Tue, Feb 28, 2017 at 09:28:15AM -0800, Jason Ekstrand wrote:
> On Tue, Feb 28, 2017 at 8:48 AM, Nanley Chery  wrote:
> 
> > On Mon, Feb 27, 2017 at 09:22:13PM -0800, Jason Ekstrand wrote:
> > > On Feb 27, 2017 5:21 PM, "Nanley Chery"  wrote:
> > >
> > > We'll loop through this array when performing automatic layout
> > > transitions.
> > >
> > > Signed-off-by: Nanley Chery 
> > > ---
> > >  src/intel/vulkan/anv_pass.c| 6 +-
> > >  src/intel/vulkan/anv_private.h | 7 +++
> > >  2 files changed, 12 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/intel/vulkan/anv_pass.c b/src/intel/vulkan/anv_pass.c
> > > index 5bd205d2f0..9d7fa7f83a 100644
> > > --- a/src/intel/vulkan/anv_pass.c
> > > +++ b/src/intel/vulkan/anv_pass.c
> > > @@ -86,9 +86,11 @@ VkResult anv_CreateRenderPass(
> > >const VkSubpassDescription *desc = >pSubpasses[i];
> > >
> > >subpass_attachment_count +=
> > > +  pass->subpasses[i].attachment_count =
> > >   desc->inputAttachmentCount +
> > >   desc->colorAttachmentCount +
> > > - (desc->pResolveAttachments ? desc->colorAttachmentCount : 0);
> > > + (desc->pResolveAttachments ? desc->colorAttachmentCount : 0) +
> > > + (desc->pDepthStencilAttachment != NULL);
> > > }
> > >
> > > pass->subpass_attachments =
> > > @@ -108,6 +110,7 @@ VkResult anv_CreateRenderPass(
> > >
> > >subpass->input_count = desc->inputAttachmentCount;
> > >subpass->color_count = desc->colorAttachmentCount;
> > > +  subpass->attachments = p;
> > >
> > >if (desc->inputAttachmentCount > 0) {
> > >   subpass->input_attachments = p;
> > > @@ -169,6 +172,7 @@ VkResult anv_CreateRenderPass(
> > >
> > >if (desc->pDepthStencilAttachment) {
> > >   uint32_t a = desc->pDepthStencilAttachment->attachment;
> > > + *p++ =
> > >
> > >
> > > Something looks funny about this line.  I could easily believe its
> > correct
> > > but it should probably be indented differently or something.
> > >
> >
> > I could indent the line below it, or place it on the same line if you'd
> > like. I originally wanted to keep the patch diff small.
> >
> 
> I get that but, as it is, it looks like a typo.  Will it all fit on one
> line?  If not, I think I'd rather have the two things being assigned on the
> same line and the thing being assigned on it's own if we have to wrap.
> 

Yeah, it does look strange. I was wrong, it won't all fit on the same
line. I'll opt for your second option.

-Nanley

> 
> >
> > -Nanley
> >
> > >   subpass->depth_stencil_attachment = *desc->
> > > pDepthStencilAttachment;
> > >   if (a != VK_ATTACHMENT_UNUSED) {
> > >  pass->attachments[a].usage |=
> > > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> > private.h
> > > index 6e274a5a3a..7fba4e92b8 100644
> > > --- a/src/intel/vulkan/anv_private.h
> > > +++ b/src/intel/vulkan/anv_private.h
> > > @@ -1825,6 +1825,13 @@ struct anv_framebuffer {
> > >  };
> > >
> > >  struct anv_subpass {
> > > +   uint32_t attachment_count;
> > > +
> > > +   /**
> > > +* A pointer to all attachment references used in this subpass.
> > > +* Only valid if ::attachment_count > 0.
> > > +*/
> > > +   VkAttachmentReference *  attachments;
> > > uint32_t input_count;
> > > VkAttachmentReference *  input_attachments;
> > > uint32_t color_count;
> > > --
> > > 2.11.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 04/18] anv: Update the HiZ sampling helper

[Jason Ekstrand]

On Tue, Feb 28, 2017 at 9:29 AM, Nanley Chery  wrote:

> On Tue, Feb 28, 2017 at 08:07:35AM -0800, Jason Ekstrand wrote:
> > On Tue, Feb 28, 2017 at 8:02 AM, Nanley Chery 
> wrote:
> >
> > > On Mon, Feb 27, 2017 at 08:48:48PM -0800, Jason Ekstrand wrote:
> > > > On Feb 27, 2017 5:20 PM, "Nanley Chery" 
> wrote:
> > > >
> > > > Validate the inputs and actually verify that this image has a depth
> > > > buffer.
> > > >
> > > > Signed-off-by: Nanley Chery 
> > > > ---
> > > >  src/intel/vulkan/anv_blorp.c   | 1 +
> > > >  src/intel/vulkan/anv_image.c   | 7 +++
> > > >  src/intel/vulkan/anv_private.h | 7 +--
> > > >  3 files changed, 9 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/src/intel/vulkan/anv_blorp.c
> b/src/intel/vulkan/anv_blorp.c
> > > > index 2cde3b7689..05250de06a 100644
> > > > --- a/src/intel/vulkan/anv_blorp.c
> > > > +++ b/src/intel/vulkan/anv_blorp.c
> > > > @@ -1276,6 +1276,7 @@ anv_cmd_buffer_clear_subpass(struct
> anv_cmd_buffer
> > > > *cmd_buffer)
> > > > clear_with_hiz = false;
> > > >  } else if (gen == 8 &&
> > > > anv_can_sample_with_hiz(cmd_
> > > > buffer->device->info.gen,
> > > > +   iview->aspect_mask,
> > > >
>  iview->image->samples)) {
> > > > /* Only gen9+ supports returning ANV_HZ_FC_VAL when
> > > > sampling a
> > > >  * fast-cleared portion of a HiZ buffer. Testing has
> > > > revealed
> > > > diff --git a/src/intel/vulkan/anv_image.c
> b/src/intel/vulkan/anv_image.c
> > > > index 716cdf3a38..f9f264094f 100644
> > > > --- a/src/intel/vulkan/anv_image.c
> > > > +++ b/src/intel/vulkan/anv_image.c
> > > > @@ -502,7 +502,6 @@ anv_layout_to_aux_usage(const uint8_t gen, const
> > > struct
> > > > anv_image * const image,
> > > > layout == VK_IMAGE_LAYOUT_PREINITIALIZED)
> > > >layout = future_layout;
> > > >
> > > > -   const bool has_depth = aspects & VK_IMAGE_ASPECT_DEPTH_BIT;
> > > > const bool color_aspect = aspects == VK_IMAGE_ASPECT_COLOR_BIT;
> > > >
> > > > /* The following switch currently only handles depth stencil
> aspects.
> > > > @@ -538,7 +537,7 @@ anv_layout_to_aux_usage(const uint8_t gen, const
> > > struct
> > > > anv_image * const image,
> > > >assert(!color_aspect);
> > > >/* Fall-through */
> > > > case VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL:
> > > > -  if (has_depth && anv_can_sample_with_hiz(gen, image->samples))
> > > > +  if (anv_can_sample_with_hiz(gen, aspects, image->samples))
> > > >   return ISL_AUX_USAGE_HIZ;
> > > >else
> > > >   return ISL_AUX_USAGE_NONE;
> > > > @@ -699,8 +698,8 @@ anv_CreateImageView(VkDevice _device,
> > > > float red_clear_color = 0.0f;
> > > > enum isl_aux_usage surf_usage = image->aux_usage;
> > > > if (image->aux_usage == ISL_AUX_USAGE_HIZ) {
> > > > -  if (iview->aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT &&
> > > > -  anv_can_sample_with_hiz(device->info.gen,
> image->samples)) {
> > > > +  if (anv_can_sample_with_hiz(device->info.gen,
> iview->aspect_mask,
> > > > +  image->samples)) {
> > > >   /* When a HiZ buffer is sampled on gen9+, ensure that
> > > >* the constant fast clear value is set in the surface
> state.
> > > >*/
> > > > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> > > private.h
> > > > index 5ce9027f88..b21a9fb359 100644
> > > > --- a/src/intel/vulkan/anv_private.h
> > > > +++ b/src/intel/vulkan/anv_private.h
> > > > @@ -1661,9 +1661,12 @@ struct anv_image {
> > > >
> > > >  /* Returns true if a HiZ-enabled depth buffer can be sampled from.
> */
> > > >  static inline bool
> > > > -anv_can_sample_with_hiz(uint8_t gen, uint32_t samples)
> > > > +anv_can_sample_with_hiz(uint8_t gen, VkImageAspectFlags
> aspect_mask,
> > > > +uint32_t samples)
> > > >  {
> > > > -   return gen >= 8 && samples == 1;
> > > > +   /* Validate the inputs. */
> > > > +   assert(gen >= 7 && aspect_mask && samples);
> > > > +   return gen >= 8 && aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT &&
> samples
> > > > == 1;
> > > >
> > > >
> > > > I think you want parents around the "aspect & DEPTH"
> > > >
> > >
> > > According to the C11 spec (footnote 85 found under section 6.5
> > > Expressions), the parenthesis are not necessary because the bitwise AND
> > > operator has higher precedence than the logical AND operator.
> > >
> >
> > I figured but the compiler likes to warn about those things and I really
> > don't like having to look at the spec in order to figure out what a line
> of
> > code means. :-)
>
>
> Below, is a tip on how to check the operator precedence that may sway
> your opinion. Nonetheless, if you'd still like the parenthesis, I can
> add it.
>

Yes, I know how to