Re: [Mesa-dev] [PATCH 0/9] nir: Add better helpers for handling constant sources

2018-10-26 Thread Jason Ekstrand
I landed the first four but it'd be nice if I could get some review on the
intel bits.

--Jason

On Sat, Oct 20, 2018 at 12:55 PM Jason Ekstrand 
wrote:

> Previously, the only thing we had was nir_src_as_const_value which returns
> a pointer to a nir_const_value which was NULL if the source wasn't actually
> a constant.  This was great except that almost none of the users considered
> anything other than 32-bit values.  With 8, 16, and 64-bit values floating
> around, we really shouldn't be hand-rolling it everywhere.  Most of the
> code is currently safe if you operate under the assumption that things like
> array indices are always 32 bits.  The glaring exception was some of the
> helpers in nir_search_helpers.h where we definitely cannot be making that
> assumption but were anyway.
>
> I've converted core NIR and i965 but have not written patches for vc4, ir3,
> or radeon.
>
> Cc: Connor Abbott 
> Cc: Timothy Arceri 
> Cc: Eric Anholt 
> Cc: Rob Clark 
> Cc: Karol Herbst 
> Cc: Bas Nieuwenhuizen 
>
> Jason Ekstrand (9):
>   nir: Add some new helpers for working with const sources
>   nir/search: Use nir_src_is_const and friends
>   nir/search_helpers: Use nir_src_is_const and friends
>   nir: Use nir_src_is_const and nir_src_as_* in core code
>   intel/fs,vec4: Clean up a repeated pattern with SSBOs
>   intel/fs: Use the new nir_src_is_const and friends
>   intel/vec4: Use the new nir_src_is_const and friends
>   intel/analyze_ubo_ranges: Use nir_src_is_const and friends
>   anv: Use nir_src_is_const and friends in lowering code
>
>  src/compiler/glsl/gl_nir_lower_samplers.c |   7 +-
>  src/compiler/nir/nir.c|  92 +
>  src/compiler/nir/nir.h|  16 +
>  src/compiler/nir/nir_deref.c  |  14 +-
>  src/compiler/nir/nir_gather_info.c|   6 +-
>  src/compiler/nir/nir_gs_count_vertices.c  |   7 +-
>  src/compiler/nir/nir_lower_clip.c |   2 +-
>  src/compiler/nir/nir_lower_indirect_derefs.c  |   4 +-
>  src/compiler/nir/nir_lower_io.c   |   6 +-
>  .../nir/nir_lower_io_arrays_to_elements.c |  11 +-
>  src/compiler/nir/nir_lower_locals_to_regs.c   |   6 +-
>  src/compiler/nir/nir_lower_two_sided_color.c  |   2 +-
>  src/compiler/nir/nir_lower_vars_to_ssa.c  |  14 +-
>  src/compiler/nir/nir_opt_dead_cf.c|   7 +-
>  src/compiler/nir/nir_opt_find_array_copies.c  |  13 +-
>  src/compiler/nir/nir_opt_intrinsics.c |   4 +-
>  src/compiler/nir/nir_opt_large_constants.c|   2 +-
>  src/compiler/nir/nir_search.c |  70 +---
>  src/compiler/nir/nir_search_helpers.h |  49 ++-
>  src/compiler/nir/nir_split_vars.c |  17 +-
>  src/compiler/nir/tests/vars_tests.cpp |  10 +-
>  src/intel/compiler/brw_fs.h   |   2 +
>  src/intel/compiler/brw_fs_nir.cpp | 315 +++---
>  .../compiler/brw_nir_analyze_ubo_ranges.c |  15 +-
>  src/intel/compiler/brw_vec4.h |   2 +
>  src/intel/compiler/brw_vec4_gs_nir.cpp|  12 +-
>  src/intel/compiler/brw_vec4_nir.cpp   | 190 ---
>  src/intel/compiler/brw_vec4_tcs.cpp   |   6 +-
>  .../vulkan/anv_nir_apply_pipeline_layout.c|  15 +-
>  .../vulkan/anv_nir_lower_ycbcr_textures.c |   6 +-
>  30 files changed, 423 insertions(+), 499 deletions(-)
>
> --
> 2.19.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 3/3] radeonsi: add support for Raven2

2018-10-26 Thread Marek Olšák
From: Marek Olšák 

---
 src/amd/addrlib/amdgpu_asic_addr.h  | 2 ++
 src/amd/addrlib/gfx9/gfx9addrlib.cpp| 2 +-
 src/amd/common/ac_gpu_info.c| 6 ++
 src/amd/common/ac_llvm_util.c   | 1 +
 src/amd/common/ac_surface.c | 4 
 src/amd/common/amd_family.h | 1 +
 src/amd/common/gfx9d.h  | 3 +++
 src/gallium/drivers/radeonsi/si_pipe.c  | 6 --
 src/gallium/drivers/radeonsi/si_state.c | 4 +++-
 src/gallium/drivers/radeonsi/si_state_binning.c | 1 +
 10 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/src/amd/addrlib/amdgpu_asic_addr.h 
b/src/amd/addrlib/amdgpu_asic_addr.h
index e5838d42a3c..7436c5493e1 100644
--- a/src/amd/addrlib/amdgpu_asic_addr.h
+++ b/src/amd/addrlib/amdgpu_asic_addr.h
@@ -83,20 +83,21 @@
 
 #define AMDGPU_CARRIZO_RANGE0x01, 0x21
 #define AMDGPU_BRISTOL_RANGE0x10, 0x21
 #define AMDGPU_STONEY_RANGE 0x61, 0xFF
 
 #define AMDGPU_VEGA10_RANGE 0x01, 0x14
 #define AMDGPU_VEGA12_RANGE 0x14, 0x28
 #define AMDGPU_VEGA20_RANGE 0x28, 0xFF
 
 #define AMDGPU_RAVEN_RANGE  0x01, 0x81
+#define AMDGPU_RAVEN2_RANGE 0x81, 0xFF
 
 #define AMDGPU_EXPAND_FIX(x) x
 #define AMDGPU_RANGE_HELPER(val, min, max) ((val >= min) && (val < max))
 #define AMDGPU_IN_RANGE(val, ...)   AMDGPU_EXPAND_FIX(AMDGPU_RANGE_HELPER(val, 
__VA_ARGS__))
 
 
 // ASICREV_IS(eRevisionId, revisionName)
 #define ASICREV_IS(r, rn)  AMDGPU_IN_RANGE(r, AMDGPU_##rn##_RANGE)
 #define ASICREV_IS_TAHITI_P(r) ASICREV_IS(r, TAHITI)
 #define ASICREV_IS_PITCAIRN_PM(r)  ASICREV_IS(r, PITCAIRN)
@@ -125,12 +126,13 @@
 #define ASICREV_IS_CARRIZO_BRISTOL(r)  ASICREV_IS(r, BRISTOL)
 #define ASICREV_IS_STONEY(r)   ASICREV_IS(r, STONEY)
 
 #define ASICREV_IS_VEGA10_M(r) ASICREV_IS(r, VEGA10)
 #define ASICREV_IS_VEGA10_P(r) ASICREV_IS(r, VEGA10)
 #define ASICREV_IS_VEGA12_P(r) ASICREV_IS(r, VEGA12)
 #define ASICREV_IS_VEGA12_p(r) ASICREV_IS(r, VEGA12)
 #define ASICREV_IS_VEGA20_P(r) ASICREV_IS(r, VEGA20)
 
 #define ASICREV_IS_RAVEN(r)ASICREV_IS(r, RAVEN)
+#define ASICREV_IS_RAVEN2(r)   ASICREV_IS(r, RAVEN2)
 
 #endif // _AMDGPU_ASIC_ADDR_H
diff --git a/src/amd/addrlib/gfx9/gfx9addrlib.cpp 
b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
index d27aabbb60c..f115242c89c 100644
--- a/src/amd/addrlib/gfx9/gfx9addrlib.cpp
+++ b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
@@ -1284,21 +1284,21 @@ ChipFamily Gfx9Lib::HwlConvertChipFamily(
 m_settings.htileAlignFix = 1;
 m_settings.applyAliasFix = 1;
 }
 
 m_settings.metaBaseAlignFix = 1;
 
 m_settings.depthPipeXorDisable = 1;
 break;
 case FAMILY_RV:
 m_settings.isArcticIsland = 1;
-m_settings.isRaven= ASICREV_IS_RAVEN(uChipRevision);
+m_settings.isRaven= ASICREV_IS_RAVEN(uChipRevision) || 
ASICREV_IS_RAVEN2(uChipRevision);
 
 if (m_settings.isRaven)
 {
 m_settings.isDcn1   = 1;
 }
 
 m_settings.metaBaseAlignFix = 1;
 
 if (ASICREV_IS_RAVEN(uChipRevision))
 {
diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index 2c70fb2c721..689f544c18b 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -307,20 +307,26 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
info->name = #cfamily; \
break;
 #include "pci_ids/radeonsi_pci_ids.h"
 #undef CHIPSET
 
default:
fprintf(stderr, "amdgpu: Invalid PCI ID.\n");
return false;
}
 
+   /* Raven2 uses the same PCI IDs as Raven1, but different revision IDs. 
*/
+   if (info->family == CHIP_RAVEN && amdinfo->chip_rev >= 0x8) {
+   info->family = CHIP_RAVEN2;
+   info->name = "RAVEN2";
+   }
+
if (info->family >= CHIP_VEGA10)
info->chip_class = GFX9;
else if (info->family >= CHIP_TONGA)
info->chip_class = VI;
else if (info->family >= CHIP_BONAIRE)
info->chip_class = CIK;
else if (info->family >= CHIP_TAHITI)
info->chip_class = SI;
else {
fprintf(stderr, "amdgpu: Unknown family.\n");
diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index cd3525187a0..76ee4d127a0 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -123,20 +123,21 @@ const char *ac_get_llvm_processor_name(enum radeon_family 
family)
return "stoney";
case CHIP_POLARIS10:
return "polaris10";
case CHIP_POLARIS11:
case CHIP_POLARIS12:
case CHIP_VEGAM:
return "polaris11";
case CHIP_VEGA10:
return "gf

[Mesa-dev] [PATCH 1/3] radeonsi/gfx9: set optimal OVERWRITE_COMBINER_WATERMARK

2018-10-26 Thread Marek Olšák
From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_pipe.h  |  1 +
 src/gallium/drivers/radeonsi/si_state.c | 14 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index dc95afb7421..0807c8ddacc 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -610,20 +610,21 @@ struct si_framebuffer {
unsignedspi_shader_col_format_blend;
unsignedspi_shader_col_format_blend_alpha;
ubyte   nr_samples:5; /* at most 16xAA */
ubyte   log_samples:3; /* at most 4 = 16xAA */
ubyte   nr_color_samples; /* at most 8xAA */
ubyte   compressed_cb_mask;
ubyte   uncompressed_cb_mask;
ubyte   color_is_int8;
ubyte   color_is_int10;
ubyte   dirty_cbufs;
+   ubyte   dcc_overwrite_combiner_watermark;
booldirty_zsbuf;
boolany_dst_linear;
boolCB_has_shader_readable_metadata;
boolDB_has_shader_readable_metadata;
 };
 
 enum si_quant_mode {
/* This is the list we want to support. */
SI_QUANT_MODE_16_8_FIXED_POINT_1_256TH,
SI_QUANT_MODE_14_10_FIXED_POINT_1_1024TH,
diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index 36dce381539..43d76d19916 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -106,26 +106,27 @@ static void si_emit_cb_render_state(struct si_context 
*sctx)
if (sctx->chip_class >= VI) {
/* DCC MSAA workaround for blending.
 * Alternatively, we can set CB_COLORi_DCC_CONTROL.OVERWRITE_-
 * COMBINER_DISABLE, but that would be more complicated.
 */
bool oc_disable = (sctx->chip_class == VI ||
   sctx->chip_class == GFX9) &&
  blend &&
  blend->blend_enable_4bit & cb_target_mask &&
  sctx->framebuffer.nr_samples >= 2;
+   unsigned watermark = 
sctx->framebuffer.dcc_overwrite_combiner_watermark;
 
radeon_opt_set_context_reg(
sctx, R_028424_CB_DCC_CONTROL,
SI_TRACKED_CB_DCC_CONTROL,

S_028424_OVERWRITE_COMBINER_MRT_SHARING_DISABLE(1) |
-   S_028424_OVERWRITE_COMBINER_WATERMARK(4) |
+   
S_028424_OVERWRITE_COMBINER_WATERMARK(watermark) |

S_028424_OVERWRITE_COMBINER_DISABLE(oc_disable));
}
 
/* RB+ register settings. */
if (sctx->screen->rbplus_allowed) {
unsigned spi_shader_col_format =
sctx->ps_shader.cso ?

sctx->ps_shader.current->key.part.ps.epilog.spi_shader_col_format : 0;
unsigned sx_ps_downconvert = 0;
unsigned sx_blend_opt_epsilon = 0;
@@ -2848,20 +2849,21 @@ static void si_set_framebuffer_state(struct 
pipe_context *ctx,
sctx->framebuffer.color_is_int10 = 0;
 
sctx->framebuffer.compressed_cb_mask = 0;
sctx->framebuffer.uncompressed_cb_mask = 0;
sctx->framebuffer.nr_samples = util_framebuffer_get_num_samples(state);
sctx->framebuffer.nr_color_samples = sctx->framebuffer.nr_samples;
sctx->framebuffer.log_samples = 
util_logbase2(sctx->framebuffer.nr_samples);
sctx->framebuffer.any_dst_linear = false;
sctx->framebuffer.CB_has_shader_readable_metadata = false;
sctx->framebuffer.DB_has_shader_readable_metadata = false;
+   unsigned num_bpp64_colorbufs = 0;
 
for (i = 0; i < state->nr_cbufs; i++) {
if (!state->cbufs[i])
continue;
 
surf = (struct si_surface*)state->cbufs[i];
tex = (struct si_texture*)surf->base.texture;
 
if (!surf->color_initialized) {
si_initialize_color_surface(sctx, surf);
@@ -2894,35 +2896,45 @@ static void si_set_framebuffer_state(struct 
pipe_context *ctx,
tex->buffer.b.b.nr_storage_samples < 
tex->buffer.b.b.nr_samples) {
sctx->framebuffer.nr_color_samples =
MIN2(sctx->framebuffer.nr_color_samples,
 tex->buffer.b.b.nr_storage_samples);
sctx->framebuffer.nr_color_samples =

[Mesa-dev] [PATCH 2/3] radeonsi: clean up decompress flags in fast color clear

2018-10-26 Thread Marek Olšák
From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_clear.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_clear.c 
b/src/gallium/drivers/radeonsi/si_clear.c
index 520e5b94f4a..8aa3355afc8 100644
--- a/src/gallium/drivers/radeonsi/si_clear.c
+++ b/src/gallium/drivers/radeonsi/si_clear.c
@@ -425,51 +425,50 @@ static void si_do_fast_color_clear(struct si_context 
*sctx,
 */
if (tex->buffer.b.is_shared &&
!(tex->buffer.external_usage & 
PIPE_HANDLE_USAGE_EXPLICIT_FLUSH))
continue;
 
if (sctx->chip_class <= VI &&
tex->surface.u.legacy.level[0].mode == RADEON_SURF_MODE_1D 
&&
!sctx->screen->info.htile_cmask_support_1d_tiling)
continue;
 
-   bool need_decompress_pass = false;
-
/* Use a slow clear for small surfaces where the cost of
 * the eliminate pass can be higher than the benefit of fast
 * clear. The closed driver does this, but the numbers may 
differ.
 *
 * This helps on both dGPUs and APUs, even small APUs like 
Mullins.
 */
bool too_small = tex->buffer.b.b.nr_samples <= 1 &&
 tex->buffer.b.b.width0 *
 tex->buffer.b.b.height0 <= 512 * 512;
+   bool eliminate_needed = false;
+   bool fmask_decompress_needed = false;
 
/* Fast clear is the most appropriate place to enable DCC for
 * displayable surfaces.
 */
if (sctx->family == CHIP_STONEY && !too_small) {
vi_separate_dcc_try_enable(sctx, tex);
 
/* RB+ isn't supported with a CMASK clear only on 
Stoney,
 * so all clears are considered to be hypothetically 
slow
 * clears, which is weighed when determining whether to
 * enable separate DCC.
 */
if (tex->dcc_gather_statistics) /* only for Stoney */
tex->num_slow_clears++;
}
 
/* Try to clear DCC first, otherwise try CMASK. */
if (vi_dcc_enabled(tex, 0)) {
uint32_t reset_value;
-   bool eliminate_needed;
 
if (sctx->screen->debug_flags & DBG(NO_DCC_CLEAR))
continue;
 
/* This can happen with mipmapping or MSAA. */
if (sctx->chip_class == VI &&

!tex->surface.u.legacy.level[level].dcc_fast_clear_size)
continue;
 
if 
(!vi_get_fast_clear_parameters(tex->buffer.b.b.format,
@@ -484,28 +483,24 @@ static void si_do_fast_color_clear(struct si_context 
*sctx,
/* DCC fast clear with MSAA should clear CMASK to 0xC. 
*/
if (tex->buffer.b.b.nr_samples >= 2 && 
tex->cmask_buffer) {
/* TODO: This doesn't work with MSAA. */
if (eliminate_needed)
continue;
 
uint32_t clear_value = 0x;
si_clear_buffer(sctx, &tex->cmask_buffer->b.b,
tex->cmask_offset, 
tex->surface.cmask_size,
&clear_value, 4, 
SI_COHERENCY_CB_META);
-   need_decompress_pass = true;
+   fmask_decompress_needed = true;
}
 
vi_dcc_clear_level(sctx, tex, 0, reset_value);
-
-   if (eliminate_needed)
-   need_decompress_pass = true;
-
tex->separate_dcc_dirty = true;
} else {
if (too_small)
continue;
 
/* 128-bit formats are unusupported */
if (tex->surface.bpe > 8) {
continue;
}
 
@@ -516,37 +511,38 @@ static void si_do_fast_color_clear(struct si_context 
*sctx,
/* ensure CMASK is enabled */
si_alloc_separate_cmask(sctx->screen, tex);
if (!tex->cmask_buffer)
continue;
 
/* Do the fast clear. */
uint32_t clear_value = 0;
si_clear_buffer(sctx, &tex->cmask_buffer->b.b,
tex->cmask_offset, 
tex->surface.cmask_size,
 

Re: [Mesa-dev] [PATCH] nir: Allow using nir_lower_io_to_scalar_early on VS input vars.

2018-10-26 Thread Timothy Arceri
On Mon, Oct 15, 2018, at 5:18 PM, Eric Anholt wrote:
> This will be used on V3D to cut down the size of the VS inputs in the VPM
> (memory area for sharing data between shader stages).
> ---
>  src/compiler/nir/nir_lower_io_to_scalar.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/compiler/nir/nir_lower_io_to_scalar.c b/src/compiler/
> nir/nir_lower_io_to_scalar.c
> index f0c2a6a95d6d..c64f641a0ae4 100644
> --- a/src/compiler/nir/nir_lower_io_to_scalar.c
> +++ b/src/compiler/nir/nir_lower_io_to_scalar.c
> @@ -320,7 +320,9 @@ nir_lower_io_to_scalar_early(nir_shader *shader, 
> nir_variable_mode mask)
> if (glsl_type_is_64bit(glsl_without_array(var->type)))
>continue;
>  
> -   if (var->data.location < VARYING_SLOT_VAR0 &&
> +   if (!(shader->info.stage == MESA_SHADER_VERTEX &&
> + mode == nir_var_shader_in) &&
> +   var->data.location < VARYING_SLOT_VAR0 &&

As I understand it all current use of this pass skips vetex shader inputs via 
the mask param so this change shouldn't impact any other drivers so:

Reviewed-by: Timothy Arceri 

> var->data.location >= 0)
>continue;
>  
> -- 
> 2.18.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/3] anv: Flag semaphore BOs as external

2018-10-26 Thread Lionel Landwerlin

Reviewed-by: Lionel Landwerlin 

On 26/10/2018 19:40, Jason Ekstrand wrote:

It probably doesn't actually break anything but it does cause some
assertions in debug builds.

Fixes: 7a89a0d9edae6 "anv: Use separate MOCS settings for external BOs"
---
  src/intel/vulkan/anv_queue.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 8e9f743fcb7..6369222b801 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -970,7 +970,7 @@ VkResult anv_CreateSemaphore(
} else {
   semaphore->permanent.type = ANV_SEMAPHORE_TYPE_BO;
   VkResult result = anv_bo_cache_alloc(device, &device->bo_cache,
-  4096, 0,
+  4096, ANV_BO_EXTERNAL,
&semaphore->permanent.bo);
   if (result != VK_SUCCESS) {
  vk_free2(&device->alloc, pAllocator, semaphore);
@@ -1119,7 +1119,8 @@ VkResult anv_ImportSemaphoreFdKHR(
   new_impl.type = ANV_SEMAPHORE_TYPE_BO;
  
   VkResult result = anv_bo_cache_import(device, &device->bo_cache,

-   fd, 0, &new_impl.bo);
+   fd, ANV_BO_EXTERNAL,
+   &new_impl.bo);
   if (result != VK_SUCCESS)
  return result;
  



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


Re: [Mesa-dev] [PATCH] glsl/linker: validate attribute aliasing before optimizations

2018-10-26 Thread Timothy Arceri
On Fri, Oct 12, 2018, at 5:04 AM, Tapani Pälli wrote:
> Patch does a 'dry run' of assign_attribute_or_color_locations before
> optimizations to catch cases where we have aliasing of unused attributes
> which is forbidden by the GLSL ES 3.x specifications.
> 
> We need to run this pass before unused attributes may be removed and with
> attribute binding information from program, therefore we re-use existing
> pass in linker rather than attempt to write another one.
> 
> This fixes WebGL2 test 'gl-bindAttribLocation-aliasing-inactive' and
> Piglit test 'gles-3.0-attribute-aliasing'.
> 
> Signed-off-by: Tapani Pälli 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106833
> ---
>  src/compiler/glsl/linker.cpp | 31 ---
>  1 file changed, 28 insertions(+), 3 deletions(-)
> 
> diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
> index 2f4c8860547..905d4b3cbed 100644
> --- a/src/compiler/glsl/linker.cpp
> +++ b/src/compiler/glsl/linker.cpp
> @@ -2709,7 +2709,8 @@ static bool
>  assign_attribute_or_color_locations(void *mem_ctx,
>  gl_shader_program *prog,
>  struct gl_constants *constants,
> -unsigned target_index)
> +unsigned target_index,
> +bool do_assignment)
>  {
> /* Maximum number of generic locations.  This corresponds to either the
>  * maximum number of draw buffers or the maximum number of generic
> @@ -3072,6 +3073,9 @@ assign_attribute_or_color_locations(void *mem_ctx,
>num_attr++;
> }
>  
> +   if (!do_assignment)
> +  return true;
> +
> if (target_index == MESA_SHADER_VERTEX) {
>unsigned total_attribs_size =
>   util_bitcount(used_locations & 
> SAFE_MASK_FROM_INDEX(max_index)) +
> @@ -4780,12 +4784,12 @@ link_varyings_and_uniforms(unsigned first, 
> unsigned last,
> }
>  
> if (!assign_attribute_or_color_locations(mem_ctx, prog, &ctx->Const,
> -MESA_SHADER_VERTEX)) {
> +MESA_SHADER_VERTEX, true)) {
>return false;
> }
>  
> if (!assign_attribute_or_color_locations(mem_ctx, prog, &ctx->Const,
> -MESA_SHADER_FRAGMENT)) {
> +MESA_SHADER_FRAGMENT, true)) {
>return false;
> }
>  
> @@ -5162,6 +5166,27 @@ link_shaders(struct gl_context *ctx, struct 
> gl_shader_program *prog)
>   lower_tess_level(prog->_LinkedShaders[i]);
>}
>  
> +  /* Section 13.46 (Vertex Attribute Aliasing) of the OpenGL ES 3.2
> +   * specification says:
> +   *
> +   *"In general, the behavior of GLSL ES should not depend on 
> compiler
> +   *optimizations which might be implementation-dependent. Name 
> matching
> +   *rules in most languages, including C++ from which GLSL ES 
> is derived,
> +   *are based on declarations rather than use.
> +   *
> +   *RESOLUTION: The existence of aliasing is determined by 
> declarations
> +   *present after preprocessing."
> +   *
> +   * Because of this rule, we do a 'dry-run' of attribute 
> assignment for
> +   * vertex shader inputs here.
> +   */
> +  if (i == MESA_SHADER_VERTEX) {

Can we please add a GLES check to the if above so we can skip this for desktop 
GL. 

Its a little unfortunate we need this patch but splitting 
assign_attribute_or_color_locations() in two would get messy so with the above 
change.

Reviewed-by: Timothy Arceri 


> + if (!assign_attribute_or_color_locations(mem_ctx, prog, &ctx-
> >Const,
> +  MESA_SHADER_VERTEX, 
> false)) {
> +goto done;
> + }
> +  }
> +
>/* Call opts before lowering const arrays to uniforms so we can 
> const
> * propagate any elements accessed directly.
> */
> -- 
> 2.17.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] anv: Improve the asserts in anv_buffer_get_range

2018-10-26 Thread Lionel Landwerlin

Reviewed-by: Lionel Landwerlin 

On 26/10/2018 19:28, Jason Ekstrand wrote:

---
  src/intel/vulkan/anv_private.h | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 25e290ed112..d8a08d9d67f 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1705,7 +1705,8 @@ anv_buffer_get_range(struct anv_buffer *buffer, uint64_t 
offset, uint64_t range)
 if (range == VK_WHOLE_SIZE) {
return buffer->size - offset;
 } else {
-  assert(range <= buffer->size);
+  assert(range + offset >= range);
+  assert(range + offset <= buffer->size);
return range;
 }
  }



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


Re: [Mesa-dev] [PATCH] glsl/linker: Fix out variables linking during single stage

2018-10-26 Thread Timothy Arceri
On Wed, Oct 24, 2018, at 3:28 AM, Vadym Shovkoplias wrote:
> Since out variables are copied from shader objects instruction
> streams to linked shader instruction steam it should be cloned
> at first to keep source instruction steam unaltered.
> 
> Fixes: 966a797e433 glsl/linker: Link all out vars from a shader
> objects on a single stage
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105731
> Signed-off-by: Vadym Shovkoplias 

Reviewed-by: Timothy Arceri 

Also please either update the existing piglit or add a new one to better cover 
the use of the freed vars. From the bug report it seems adding another out var 
is enough to do it. Thanks.

> ---
>  src/compiler/glsl/linker.cpp | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
> index 7db34ebf95..8b1b03322a 100644
> --- a/src/compiler/glsl/linker.cpp
> +++ b/src/compiler/glsl/linker.cpp
> @@ -2269,10 +2269,11 @@ link_output_variables(struct gl_linked_shader 
> *linked_shader,
>   if (ir->ir_type != ir_type_variable)
>  continue;
>  
> - ir_variable *const var = (ir_variable *) ir;
> + ir_variable *var = (ir_variable *) ir;
>  
>   if (var->data.mode == ir_var_shader_out &&
> !symbols->get_variable(var->name)) {
> +var = var->clone(linked_shader, NULL);
>  symbols->add_variable(var);
>  linked_shader->ir->push_head(var);
>   }
> -- 
> 2.18.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 108572] Could not start gimp (probably due to opencl)

2018-10-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108572

Bug ID: 108572
   Summary: Could not start gimp (probably due to opencl)
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Gallium/StateTracker/Clover
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: mpia...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Probably a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=74973 (but
that was an old bug)

Latest git broke opencl on radeonsi.
I could not start gimp (with opencl enabled) and even clinfo gives a
segmetation fault.

Bisected to:
first bad commit: [4fd8d2df9c65396319619fa0784378600fc834d0] radeonsi: move
emission of PA_SU_VTX_CNTL into emit_guardband


This is my hw (glxinfo)
OpenGL vendor string: X.Org
OpenGL renderer string: AMD KABINI (DRM 3.26.0, 4.18.16-bfq-zstd+, LLVM 7.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.0-devel
(git-0e0dc596a2)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.5 (Compatibility Profile) Mesa 18.3.0-devel
(git-0e0dc596a2)
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.0-devel
(git-0e0dc596a2)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20


Marco

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


Re: [Mesa-dev] [PATCH 1/2] blorp: Emit a dummy 3DSTATE_WM prior to 3DSTATE_WM_HZ_OP

2018-10-26 Thread Kenneth Graunke
On Tuesday, October 16, 2018 1:12:18 PM PDT Jason Ekstrand wrote:
> Suggested-by: Francisco Jerez 
> ---
>  src/intel/blorp/blorp_genX_exec.h | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/src/intel/blorp/blorp_genX_exec.h 
> b/src/intel/blorp/blorp_genX_exec.h
> index 50341ab0ecf..30025cf4deb 100644
> --- a/src/intel/blorp/blorp_genX_exec.h
> +++ b/src/intel/blorp/blorp_genX_exec.h
> @@ -1628,6 +1628,15 @@ blorp_emit_gen8_hiz_op(struct blorp_batch *batch,
>  */
> blorp_emit_3dstate_multisample(batch, params);
>  
> +   /* According to the SKL PRM formula for WM_INT::ThreadDispatchEnable, the
> +* 3DSTATE_WM::ForceThreadDispatchEnable field can force WM thread 
> dispatch
> +* even when WM_HZ_OP is active.  However, WM thread dispatch is normal

is normally

> +* disabled for HiZ ops and it appears that force-enabling it can lead to
> +* GPU hangs on at least Skylake.  Since we don't know the current state 
> of
> +* the 3DSTATE_WM packet, just emit a dummy one prior to 3DSTATE_WM_HZ_OP.
> +*/
> +   blorp_emit(batch, GENX(3DSTATE_WM), wm);
> +
> /* If we can't alter the depth stencil config and multiple layers are
>  * involved, the HiZ op will fail. This is because the op requires that a
>  * new config is emitted for each additional layer.

Series is:
Reviewed-by: Kenneth Graunke 


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


Re: [Mesa-dev] [Mesa-stable] [PATCH mesa 1/4] meson: turn git_sha1.h target into a proper dependency

2018-10-26 Thread Dylan Baker
Quoting Eric Engestrom (2018-10-26 14:05:31)
> On Friday, 2018-10-26 08:55:46 -0700, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-10-25 09:44:14)
> > > On Tuesday, 2018-10-02 13:44:07 -0700, Dylan Baker wrote:
> > > > Quoting Eric Engestrom (2018-10-02 07:09:03)
> > > > > Cc: mesa-sta...@lists.freedesktop.org
> > > > > Signed-off-by: Eric Engestrom 
> > > > > ---
> > > > >  src/mesa/meson.build |  3 +--
> > > > >  src/meson.build  | 13 -
> > > > >  2 files changed, 9 insertions(+), 7 deletions(-)
> > > > > 
> > > > > diff --git a/src/mesa/meson.build b/src/mesa/meson.build
> > > > > index ea884977db8052d86fcb..861b0311048eff422b9f 100644
> > > > > --- a/src/mesa/meson.build
> > > > > +++ b/src/mesa/meson.build
> > > > > @@ -705,7 +705,6 @@ files_libmesa_common += [
> > > > >ir_expression_operation_h,
> > > > >main_remap_helper_h,
> > > > >matypes_h,
> > > > > -  sha1_h,
> > > > >  ]
> > > > >  
> > > > >  if with_sse41
> > > > > @@ -726,7 +725,7 @@ libmesa_classic = static_library(
> > > > >cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
> > > > >include_directories : [inc_common, inc_libmesa_asm, 
> > > > > include_directories('main')],
> > > > >link_with : [libglsl, libmesa_sse41],
> > > > > -  dependencies : idep_nir_headers,
> > > > > +  dependencies : [idep_nir_headers, idep_git_sha1],
> > > > >build_by_default : false,
> > > > >  )
> > > > >  
> > > > > diff --git a/src/meson.build b/src/meson.build
> > > > > index af881cff70bf752a6474..89ffaddf47b7286e4fe0 100644
> > > > > --- a/src/meson.build
> > > > > +++ b/src/meson.build
> > > > > @@ -39,11 +39,14 @@ libglsl_util = static_library(
> > > > >build_by_default : false,
> > > > >  )
> > > > >  
> > > > > -sha1_h = custom_target(
> > > > > -  'git_sha1.h',
> > > > > -  output : 'git_sha1.h',
> > > > > -  command : [prog_python, git_sha1_gen_py, '--output', '@OUTPUT@'],
> > > > > -  build_always : true, # commit sha1 can change without having 
> > > > > touched these files
> > > > > +idep_git_sha1 = declare_dependency(
> > > > > +  sources : custom_target(
> > > > > +'git_sha1.h',
> > > > > +output : 'git_sha1.h',
> > > > > +command : [prog_python, git_sha1_gen_py, '--output', '@OUTPUT@'],
> > > > > +build_always : true, # commit sha1 can change without having 
> > > > > touched these files
> > > > > +  ),
> > > > > +  include_directories : inc_src,
> > > > 
> > > > What does this get us over including it in the source list, since it's 
> > > > a .h
> > > > meson should generate the proper include paths already, right?
> > > 
> > > Are you sure it does? I'll respin if that's really guaranteed and not
> > > just a coincidence :)
> > 
> > It does add git_sha1.h to the dependency list, but there is no guarantee 
> > that it
> > will in the documentation, I'll go update that. I'm not sure wrapping it in 
> > a
> > dependency changes that however, since all `sources` does is append a list
> > sources in the target, so it doesn't really change anything.
> 
> This wasn't really about the dependency tracking, my declare_dependency()
> change was to make sure the include path was guaranteed to be passed to
> the file containing `#include "git_sha1.h"`.

Then yes, putting a custom_target that is a header in the source list guarantees
that a -I argument will be generated.


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


Re: [Mesa-dev] [Mesa-stable] [PATCH mesa 1/4] meson: turn git_sha1.h target into a proper dependency

2018-10-26 Thread Eric Engestrom
On Friday, 2018-10-26 08:55:46 -0700, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-10-25 09:44:14)
> > On Tuesday, 2018-10-02 13:44:07 -0700, Dylan Baker wrote:
> > > Quoting Eric Engestrom (2018-10-02 07:09:03)
> > > > Cc: mesa-sta...@lists.freedesktop.org
> > > > Signed-off-by: Eric Engestrom 
> > > > ---
> > > >  src/mesa/meson.build |  3 +--
> > > >  src/meson.build  | 13 -
> > > >  2 files changed, 9 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/src/mesa/meson.build b/src/mesa/meson.build
> > > > index ea884977db8052d86fcb..861b0311048eff422b9f 100644
> > > > --- a/src/mesa/meson.build
> > > > +++ b/src/mesa/meson.build
> > > > @@ -705,7 +705,6 @@ files_libmesa_common += [
> > > >ir_expression_operation_h,
> > > >main_remap_helper_h,
> > > >matypes_h,
> > > > -  sha1_h,
> > > >  ]
> > > >  
> > > >  if with_sse41
> > > > @@ -726,7 +725,7 @@ libmesa_classic = static_library(
> > > >cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
> > > >include_directories : [inc_common, inc_libmesa_asm, 
> > > > include_directories('main')],
> > > >link_with : [libglsl, libmesa_sse41],
> > > > -  dependencies : idep_nir_headers,
> > > > +  dependencies : [idep_nir_headers, idep_git_sha1],
> > > >build_by_default : false,
> > > >  )
> > > >  
> > > > diff --git a/src/meson.build b/src/meson.build
> > > > index af881cff70bf752a6474..89ffaddf47b7286e4fe0 100644
> > > > --- a/src/meson.build
> > > > +++ b/src/meson.build
> > > > @@ -39,11 +39,14 @@ libglsl_util = static_library(
> > > >build_by_default : false,
> > > >  )
> > > >  
> > > > -sha1_h = custom_target(
> > > > -  'git_sha1.h',
> > > > -  output : 'git_sha1.h',
> > > > -  command : [prog_python, git_sha1_gen_py, '--output', '@OUTPUT@'],
> > > > -  build_always : true, # commit sha1 can change without having touched 
> > > > these files
> > > > +idep_git_sha1 = declare_dependency(
> > > > +  sources : custom_target(
> > > > +'git_sha1.h',
> > > > +output : 'git_sha1.h',
> > > > +command : [prog_python, git_sha1_gen_py, '--output', '@OUTPUT@'],
> > > > +build_always : true, # commit sha1 can change without having 
> > > > touched these files
> > > > +  ),
> > > > +  include_directories : inc_src,
> > > 
> > > What does this get us over including it in the source list, since it's a 
> > > .h
> > > meson should generate the proper include paths already, right?
> > 
> > Are you sure it does? I'll respin if that's really guaranteed and not
> > just a coincidence :)
> 
> It does add git_sha1.h to the dependency list, but there is no guarantee that 
> it
> will in the documentation, I'll go update that. I'm not sure wrapping it in a
> dependency changes that however, since all `sources` does is append a list
> sources in the target, so it doesn't really change anything.

This wasn't really about the dependency tracking, my declare_dependency()
change was to make sure the include path was guaranteed to be passed to
the file containing `#include "git_sha1.h"`.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] anv/SKL+: Use ForceThreadDispatchEnable instead of PixelShaderHasUAV

2018-10-26 Thread Jason Ekstrand
This reverts commit 0fa9e6d7b304f6a8064ed78a4b9c557e1026e7e5 but adds a
line to BLORP to emit 3DSTATE_WM right before 3DSTATE_WM_HZ_OP.

Cc: Kenneth Graunke 

---
 src/intel/blorp/blorp_genX_exec.h |  9 +++
 src/intel/vulkan/genX_pipeline.c  | 42 ++-
 2 files changed, 16 insertions(+), 35 deletions(-)

diff --git a/src/intel/blorp/blorp_genX_exec.h 
b/src/intel/blorp/blorp_genX_exec.h
index 7a8c45dbee5..2d1c6e90154 100644
--- a/src/intel/blorp/blorp_genX_exec.h
+++ b/src/intel/blorp/blorp_genX_exec.h
@@ -1642,6 +1642,15 @@ blorp_emit_gen8_hiz_op(struct blorp_batch *batch,
   blorp_emit_cc_viewport(batch);
}
 
+   /* According to the SKL PRM formula for WM_INT::ThreadDispatchEnable, the
+* 3DSTATE_WM::ForceThreadDispatchEnable field can force WM thread dispatch
+* even when WM_HZ_OP is active.  However, WM thread dispatch is normal
+* disabled for HiZ ops and it appears that force-enabling it can lead to
+* GPU hangs on at least Skylake.  Since we don't know the current state of
+* the 3DSTATE_WM packet, just emit a dummy one prior to 3DSTATE_WM_HZ_OP.
+*/
+   blorp_emit(batch, GENX(3DSTATE_WM), wm);
+
/* If we can't alter the depth stencil config and multiple layers are
 * involved, the HiZ op will fail. This is because the op requires that a
 * new config is emitted for each additional layer.
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index cbf8ec7f48d..e34dea431ec 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -1445,12 +1445,12 @@ emit_3dstate_wm(struct anv_pipeline *pipeline, struct 
anv_subpass *subpass,
 wm.EarlyDepthStencilControl = EDSC_NORMAL;
  }
 
-#if GEN_GEN == 8
- /* Gen8 and later hardware tries to compute ThreadDispatchEnable for
-  * us but doesn't take into account KillPixels when no depth or
-  * stencil writes are enabled.  In order for occlusion queries to
-  * work correctly with no attachments, we need to force-enable PS
-  * thread dispatch.
+#if GEN_GEN >= 8
+ /* Gen8 hardware tries to compute ThreadDispatchEnable for us but
+  * doesn't take into account KillPixels when no depth or stencil
+  * writes are enabled.  In order for occlusion queries to work
+  * correctly with no attachments, we need to force-enable PS thread
+  * dispatch.
   *
   * The BDW docs are pretty clear that that this bit isn't validated
   * and probably shouldn't be used in production:
@@ -1460,9 +1460,7 @@ emit_3dstate_wm(struct anv_pipeline *pipeline, struct 
anv_subpass *subpass,
   *
   * Unfortunately, however, the other mechanism we have for doing this
   * is 3DSTATE_PS_EXTRA::PixelShaderHasUAV which causes hangs on BDW.
-  * Given two bad options, we choose the one which works.  On Skylake
-  * and later, setting ForceThreadDispatchEnable causes GPU hangs so
-  * we use the PixelShaderHasUAV mechanism there.
+  * Given two bad options, we choose the one which works.
   */
  if ((wm_prog_data->has_side_effects || wm_prog_data->uses_kill) &&
  !has_color_buffer_write_enabled(pipeline, blend))
@@ -1665,32 +1663,6 @@ emit_3dstate_ps_extra(struct anv_pipeline *pipeline,
  wm_prog_data->uses_kill;
 
 #if GEN_GEN >= 9
-  /* Gen8 and later hardware tries to compute ThreadDispatchEnable for us
-   * but doesn't take into account KillPixels when no depth or stencil
-   * writes are enabled.  In order for occlusion queries to work correctly
-   * with no attachments, we need to force-enable PS thread dispatch.
-   *
-   * The stricter cross-primitive coherency guarantees that the hardware
-   * gives us with the "Accesses UAV" bit set for at least one shader stage
-   * and the "UAV coherency required" bit set on the 3DPRIMITIVE command 
are
-   * redundant within the current image, atomic counter and SSBO GL and
-   * Vulkan APIs, which all have very loose ordering and coherency
-   * requirements and generally rely on the application to insert explicit
-   * barriers when a shader invocation is expected to see the memory
-   * writes performed by the invocations of some previous primitive.
-   * Regardless of the value of "UAV coherency required", the "Accesses
-   * UAV" bits will implicitly cause an in most cases useless DC flush
-   * when the lowermost stage with the bit set finishes execution.
-   *
-   * Unfortunately, however, the other mechanism we have for doing this is
-   * 3DSTATE_WM::ForceThreadDispatchEnable which causes GPU hangs on
-   * Skylake and later hardware.  On Broadwell, however, setting this bit
-   * causes GPU hangs so we use ForceThreadDispatchEnable there.
-   */
-  if ((wm_prog_data->

[Mesa-dev] [PATCH] nir/deref: Support casts in comparisons

2018-10-26 Thread Jason Ekstrand
The code which constructs deref paths already gives you the path
starting at the nearest deref_cast or deref_var.  All we need to do is
handle the case where the start of the path isn't a deref_var.

Cc: Caio Marcelo de Oliveira Filho 

---
 src/compiler/nir/nir_deref.c | 40 +---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
index 16502c23d04..ed7e1369ca6 100644
--- a/src/compiler/nir/nir_deref.c
+++ b/src/compiler/nir/nir_deref.c
@@ -278,13 +278,49 @@ nir_fixup_deref_modes(nir_shader *shader)
}
 }
 
+static bool
+modes_may_alias(nir_variable_mode a, nir_variable_mode b)
+{
+   /* Function parameters can alias anything except local variables in the
+* current function.
+*/
+   if ((a == nir_var_param && b != nir_var_local) ||
+   (b == nir_var_param && a != nir_var_local))
+  return true;
+
+   /* For everything else, they can only alias if they have the same mode.
+* This may not hold for external things such UBOs and SSBOs but those
+* don't use derefs today.
+*/
+   return a == b;
+}
+
 nir_deref_compare_result
 nir_compare_deref_paths(nir_deref_path *a_path,
 nir_deref_path *b_path)
 {
-   if (a_path->path[0]->var != b_path->path[0]->var)
+   if (!modes_may_alias(b_path->path[0]->mode, a_path->path[0]->mode))
   return 0;
 
+   if (a_path->path[0]->deref_type != b_path->path[0]->deref_type)
+  return nir_derefs_may_alias_bit;
+
+   if (a_path->path[0]->deref_type == nir_deref_type_var) {
+  /* If we can chase the deref all the way back to the variable and
+   * they're not the same variable, we know they can't possibly alias.
+   */
+  if (a_path->path[0]->var != b_path->path[0]->var)
+ return 0;
+   } else {
+  /* If they're not exactly the same cast, we can't compare them so we
+   * have to assume they alias.  We could potentially be a bit smarter
+   * here and compare the two casts for equality but let's just hope CSE
+   * combines identical casts instead.
+   */
+  if (a_path->path[0] != b_path->path[0])
+ return nir_derefs_may_alias_bit;
+   }
+
/* Start off assuming they fully compare.  We ignore equality for now.  In
 * the end, we'll determine that by containment.
 */
@@ -376,8 +412,6 @@ nir_compare_derefs(nir_deref_instr *a, nir_deref_instr *b)
nir_deref_path a_path, b_path;
nir_deref_path_init(&a_path, a, NULL);
nir_deref_path_init(&b_path, b, NULL);
-   assert(a_path.path[0]->deref_type == nir_deref_type_var);
-   assert(b_path.path[0]->deref_type == nir_deref_type_var);
 
nir_deref_compare_result result = nir_compare_deref_paths(&a_path, &b_path);
 
-- 
2.19.1

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


Re: [Mesa-dev] [PATCH v1 1/5] meson: compilation flags for sse

2018-10-26 Thread Dylan Baker
Quoting Matt Turner (2018-10-26 10:44:47)
> On Fri, Oct 26, 2018 at 3:06 AM Sergii Romantsov
>  wrote:
> >
> > While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
> > So it has to be done manually by flag '-msee'.
> > Added support of such specification to build-system.
> >
> > CC: Dylan Baker 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
> > Signed-off-by: Sergii Romantsov 
> 
> We can't do that.
> 
> Maybe I'm missing some context. What problem are we solving?

That we don't get fast paths in rounding.h by default on i686, I think?


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


[Mesa-dev] [AppVeyor] mesa master #9162 completed

2018-10-26 Thread AppVeyor


Build mesa 9162 completed



Commit 7e64e39f8b by Brian Paul on 10/26/2018 6:34 PM:

nir: Fix array initializer\n\nEmpty initializer is not standard C.  This fixes MSVC build.\n\nTrivial.


Configure your notification preferences

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


[Mesa-dev] [PATCH 3/3] anv: Add a userspace timeline implementation based on BOs

2018-10-26 Thread Jason Ekstrand
This allows us to implement non-exportable timeline semaphores with BOs
that will work on as old a kernel as we like.
---
 src/intel/vulkan/anv_private.h |  23 
 src/intel/vulkan/anv_queue.c   | 187 +
 2 files changed, 210 insertions(+)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index a3ab971b6fd..0078efb3677 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2283,6 +2283,29 @@ enum anv_semaphore_type {
ANV_SEMAPHORE_TYPE_DRM_SYNCOBJ,
 };
 
+struct anv_bo_time_point {
+   struct list_head link;
+
+   /* True if some thread is actively waiting on the BO */
+   int waiting;
+
+   uint64_t serial;
+   struct anv_bo bo;
+};
+
+struct anv_bo_timeline {
+   uint64_t highest_past;
+   uint64_t highest_pending;
+
+   struct list_head time_points;
+   struct list_head free_time_points;
+};
+
+VkResult
+anv_bo_timeline_get_signal_bo_locked(struct anv_device *device,
+ struct anv_bo_timeline *timeline,
+ uint64_t serial, struct anv_bo **bo_out);
+
 struct anv_semaphore_impl {
enum anv_semaphore_type type;
 
diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 0b4324cb9d4..dbf15963784 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -918,6 +918,193 @@ VkResult anv_GetFenceFdKHR(
 
 // Queue semaphore functions
 
+static void
+anv_bo_timeline_init(struct anv_bo_timeline *timeline)
+{
+   timeline->highest_past = 0;
+   timeline->highest_pending = 0;
+   list_inithead(&timeline->time_points);
+   list_inithead(&timeline->free_time_points);
+}
+
+static void
+anv_bo_timeline_finish(struct anv_device *device,
+   struct anv_bo_timeline *timeline)
+{
+   list_for_each_entry_safe(struct anv_bo_time_point, tp,
+&timeline->time_points, link) {
+  anv_gem_close(device, tp->bo.gem_handle);
+  vk_free(&device->alloc, tp);
+   }
+
+   list_for_each_entry_safe(struct anv_bo_time_point, tp,
+&timeline->free_time_points, link) {
+  anv_gem_close(device, tp->bo.gem_handle);
+  vk_free(&device->alloc, tp);
+   }
+}
+
+static VkResult
+anv_bo_timeline_gc_locked(struct anv_device *device,
+  struct anv_bo_timeline *timeline)
+{
+   list_for_each_entry_safe(struct anv_bo_time_point, time_point,
+&timeline->time_points, link) {
+  /* If someone is waiting on this time point, consider it busy and don't
+   * try to recycle it.  There's a slim possibility that it's no longer
+   * busy by the time we look at it but we would be recycling it out from
+   * under a waiter and that can lead to weird races.
+   *
+   * We walk the list in-order so if this time point is still busy so
+   * is every following time point
+   */
+  assert(time_point->waiting >= 0);
+  if (time_point->waiting)
+ return VK_SUCCESS;
+
+  VkResult result = anv_device_bo_busy(device, &time_point->bo);
+  if (result == VK_NOT_READY) {
+ /* We walk the list in-order so if this time point is still busy so
+  * is every following time point
+  */
+ return VK_SUCCESS;
+  } else if (result != VK_SUCCESS) {
+ return result;
+  }
+
+  /* If we got here, the BO isn't busy; recycle it. */
+  assert(timeline->highest_past < time_point->serial);
+  timeline->highest_past = time_point->serial;
+  list_del(&time_point->link);
+  list_addtail(&time_point->link, &timeline->free_time_points);
+   }
+
+   return VK_SUCCESS;
+}
+
+VkResult
+anv_bo_timeline_get_signal_bo_locked(struct anv_device *device,
+ struct anv_bo_timeline *timeline,
+ uint64_t serial, struct anv_bo **bo_out)
+{
+   /* Garbage collect in case there's an idle BO we can re-use */
+   anv_bo_timeline_gc_locked(device, timeline);
+
+   /* Timelines must always increase */
+   assert(serial > timeline->highest_pending);
+
+   struct anv_bo_time_point *time_point;
+   if (list_empty(&timeline->free_time_points)) {
+  time_point = vk_zalloc(&device->alloc, sizeof(*time_point), 8,
+VK_SYSTEM_ALLOCATION_SCOPE_DEVICE);
+  if (!time_point)
+ return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
+
+  VkResult result = anv_bo_init_new(&time_point->bo, device, 4096);
+  if (result != VK_SUCCESS) {
+ vk_free(&device->alloc, time_point);
+ return result;
+  }
+   } else {
+  time_point = list_first_entry(&timeline->free_time_points,
+struct anv_bo_time_point, link);
+  list_del(&time_point->link);
+   }
+
+   assert(!time_point->waiting);
+   time_point->serial = serial;
+   list_addtail(&time_point->link, &timeline->time_points);
+   timeline->highest_pending = serial;
+

[Mesa-dev] [PATCH 0/3] anv: Add a BO-based timeline implementation

2018-10-26 Thread Jason Ekstrand
The upcoming timeline semaphore extension will require kernel support in
order to be able to share timeline semaphores between processes.  However,
we can fake it reasonably well with a userspace list of BOs and time
points.  The third patch is such an implementation in the Intel driver.
The first is a bugfix and the second is just a nice refactor that I'd like
to land sooner rather than later.

Jason Ekstrand (3):
  anv: Flag semaphore BOs as external
  anv: Use absolute timeouts in wait_for_bo_fences
  anv: Add a userspace timeline implementation based on BOs

 src/intel/vulkan/anv_private.h |  23 +++
 src/intel/vulkan/anv_queue.c   | 257 +++--
 2 files changed, 239 insertions(+), 41 deletions(-)

-- 
2.19.1

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


[Mesa-dev] [PATCH 2/3] anv: Use absolute timeouts in wait_for_bo_fences

2018-10-26 Thread Jason Ekstrand
We were previously using relative timeouts and decrementing the
user-provided timeout as we waited.  Instead, this commit refactors
things to use absolute timeouts throughout.  This should fix a subtle
bug in the waitAll case where we aren't decrementing the timeout after a
successful GPU wait.  Since pthread_cond_timedwait already takes an
absolute timeout, it's also significantly simpler.
---
 src/intel/vulkan/anv_queue.c | 65 +++-
 1 file changed, 26 insertions(+), 39 deletions(-)

diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 6369222b801..0b4324cb9d4 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -479,9 +479,24 @@ static int64_t anv_get_relative_timeout(uint64_t 
abs_timeout)
 {
uint64_t now = gettime_ns();
 
+   /* We don't want negative timeouts.
+*
+* DRM_IOCTL_I915_GEM_WAIT uses a signed 64 bit timeout and is
+* supposed to block indefinitely timeouts < 0.  Unfortunately,
+* this was broken for a couple of kernel releases.  Since there's
+* no way to know whether or not the kernel we're using is one of
+* the broken ones, the best we can do is to clamp the timeout to
+* INT64_MAX.  This limits the maximum timeout from 584 years to
+* 292 years - likely not a big deal.
+*/
if (abs_timeout < now)
   return 0;
-   return abs_timeout - now;
+
+   uint64_t rel_timeout = abs_timeout - now;
+   if (rel_timeout > (uint64_t) INT64_MAX)
+  rel_timeout = INT64_MAX;
+
+   return rel_timeout;
 }
 
 static VkResult
@@ -540,17 +555,8 @@ anv_wait_for_bo_fences(struct anv_device *device,
uint32_t fenceCount,
const VkFence *pFences,
bool waitAll,
-   uint64_t _timeout)
+   uint64_t abs_timeout_ns)
 {
-   /* DRM_IOCTL_I915_GEM_WAIT uses a signed 64 bit timeout and is supposed
-* to block indefinitely timeouts <= 0.  Unfortunately, this was broken
-* for a couple of kernel releases.  Since there's no way to know
-* whether or not the kernel we're using is one of the broken ones, the
-* best we can do is to clamp the timeout to INT64_MAX.  This limits the
-* maximum timeout from 584 years to 292 years - likely not a big deal.
-*/
-   int64_t timeout = MIN2(_timeout, (uint64_t) INT64_MAX);
-
VkResult result = VK_SUCCESS;
uint32_t pending_fences = fenceCount;
while (pending_fences) {
@@ -591,7 +597,8 @@ anv_wait_for_bo_fences(struct anv_device *device,
 /* These are the fences we really care about.  Go ahead and wait
  * on it until we hit a timeout.
  */
-result = anv_device_wait(device, &impl->bo.bo, timeout);
+result = anv_device_wait(device, &impl->bo.bo,
+ anv_get_relative_timeout(abs_timeout_ns));
 switch (result) {
 case VK_SUCCESS:
impl->bo.state = ANV_BO_FENCE_STATE_SIGNALED;
@@ -630,39 +637,20 @@ anv_wait_for_bo_fences(struct anv_device *device,
  assert(now_pending_fences <= pending_fences);
 
  if (now_pending_fences == pending_fences) {
-struct timespec before;
-clock_gettime(CLOCK_MONOTONIC, &before);
-
-uint32_t abs_nsec = before.tv_nsec + timeout % NSEC_PER_SEC;
-uint64_t abs_sec = before.tv_sec + (abs_nsec / NSEC_PER_SEC) +
-   (timeout / NSEC_PER_SEC);
-abs_nsec %= NSEC_PER_SEC;
-
-/* Avoid roll-over in tv_sec on 32-bit systems if the user
- * provided timeout is UINT64_MAX
- */
-struct timespec abstime;
-abstime.tv_nsec = abs_nsec;
-abstime.tv_sec = MIN2(abs_sec, INT_TYPE_MAX(abstime.tv_sec));
+struct timespec abstime = {
+   .tv_sec = abs_timeout_ns / NSEC_PER_SEC,
+   .tv_nsec = abs_timeout_ns % NSEC_PER_SEC,
+};
 
 MAYBE_UNUSED int ret;
 ret = pthread_cond_timedwait(&device->queue_submit,
  &device->mutex, &abstime);
 assert(ret != EINVAL);
-
-struct timespec after;
-clock_gettime(CLOCK_MONOTONIC, &after);
-uint64_t time_elapsed =
-   ((uint64_t)after.tv_sec * NSEC_PER_SEC + after.tv_nsec) -
-   ((uint64_t)before.tv_sec * NSEC_PER_SEC + before.tv_nsec);
-
-if (time_elapsed >= timeout) {
+if (gettime_ns() >= abs_timeout_ns) {
pthread_mutex_unlock(&device->mutex);
result = VK_TIMEOUT;
goto done;
 }
-
-timeout -= time_elapsed;
  }
 
  pthread_mutex_unlock(&device->mutex);
@@ -701,9 +689,8 @@ anv_wait_for_fences(struct anv_device *device,
  ANV_FROM_HANDLE(anv_fence, fence, pFences[i]);
  switch (fe

[Mesa-dev] [PATCH 1/3] anv: Flag semaphore BOs as external

2018-10-26 Thread Jason Ekstrand
It probably doesn't actually break anything but it does cause some
assertions in debug builds.

Fixes: 7a89a0d9edae6 "anv: Use separate MOCS settings for external BOs"
---
 src/intel/vulkan/anv_queue.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 8e9f743fcb7..6369222b801 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -970,7 +970,7 @@ VkResult anv_CreateSemaphore(
   } else {
  semaphore->permanent.type = ANV_SEMAPHORE_TYPE_BO;
  VkResult result = anv_bo_cache_alloc(device, &device->bo_cache,
-  4096, 0,
+  4096, ANV_BO_EXTERNAL,
   &semaphore->permanent.bo);
  if (result != VK_SUCCESS) {
 vk_free2(&device->alloc, pAllocator, semaphore);
@@ -1119,7 +1119,8 @@ VkResult anv_ImportSemaphoreFdKHR(
  new_impl.type = ANV_SEMAPHORE_TYPE_BO;
 
  VkResult result = anv_bo_cache_import(device, &device->bo_cache,
-   fd, 0, &new_impl.bo);
+   fd, ANV_BO_EXTERNAL,
+   &new_impl.bo);
  if (result != VK_SUCCESS)
 return result;
 
-- 
2.19.1

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


[Mesa-dev] [PATCH] anv: Improve the asserts in anv_buffer_get_range

2018-10-26 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_private.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 25e290ed112..d8a08d9d67f 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1705,7 +1705,8 @@ anv_buffer_get_range(struct anv_buffer *buffer, uint64_t 
offset, uint64_t range)
if (range == VK_WHOLE_SIZE) {
   return buffer->size - offset;
} else {
-  assert(range <= buffer->size);
+  assert(range + offset >= range);
+  assert(range + offset <= buffer->size);
   return range;
}
 }
-- 
2.19.1

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


Re: [Mesa-dev] [PATCH 07/31] nir/opt_if: Rework condition propagation

2018-10-26 Thread Jose Fonseca
On 22/10/18 23:13, Jason Ekstrand wrote:
> Instead of doing our own constant folding, we just emit instructions and
> let constant folding happen.  This is substantially simpler and lets us
> use the nir_imm_bool helper instead of dealing with the const_value's
> ourselves.
> ---
>   src/compiler/nir/nir_opt_if.c | 91 ---
>   1 file changed, 30 insertions(+), 61 deletions(-)
> 
> diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
> index 0c94aa170b5..60368a0259e 100644
> --- a/src/compiler/nir/nir_opt_if.c
> +++ b/src/compiler/nir/nir_opt_if.c
[...]
> +   nir_ssa_def *def[2] = { };

I'm afraid empty struct/array initializers aren't standard C and MSVC 
throws an error.

I really wish there was some GCC warning we could enable for this, as it 
appears to be a common mistake, particularly on nir, probably due to all 
simple POD structs.  But I couldn't find one.

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


Re: [Mesa-dev] [PATCH 2/2] anv: Return VK_ERROR_DEVICE_LOST from anv_device_set_lost

2018-10-26 Thread Eric Engestrom
On Friday, 2018-10-26 11:42:12 -0500, Jason Ekstrand wrote:
> This lets us get rid of a bunch of duplicated error messages.

Better than mine :P
Reviewed-by: Eric Engestrom 

> ---
>  src/intel/vulkan/anv_device.c  | 50 +++---
>  src/intel/vulkan/anv_private.h |  7 +++--
>  src/intel/vulkan/anv_queue.c   | 16 +++
>  src/intel/vulkan/genX_query.c  |  4 +--
>  4 files changed, 32 insertions(+), 45 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 70fc51ff306..ee35e013329 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -2048,21 +2048,26 @@ void anv_GetDeviceQueue2(
>*pQueue = NULL;
>  }
>  
> -void
> -anv_device_set_lost(struct anv_device *device, const char *msg, ...)
> +VkResult
> +_anv_device_set_lost(struct anv_device *device,
> + const char *file, int line,
> + const char *msg, ...)
>  {
> -   device->_lost = true;
> +   VkResult err;
> +   va_list ap;
>  
> -   if (env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false)) {
> -  intel_loge("Device lost!");
> +   device->_lost = true;
>  
> -  va_list ap;
> -  va_start(ap, msg);
> -  intel_loge_v(msg, ap);
> -  va_end(ap);
> +   va_start(ap, msg);
> +   err = __vk_errorv(device->instance, device,
> + VK_DEBUG_REPORT_OBJECT_TYPE_DEVICE_EXT,
> + VK_ERROR_DEVICE_LOST, file, line, msg, ap);
> +   va_end(ap);
>  
> +   if (env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false))
>abort();
> -   }
> +
> +   return err;
>  }
>  
>  VkResult
> @@ -2079,19 +2084,13 @@ anv_device_query_status(struct anv_device *device)
> int ret = anv_gem_gpu_get_reset_stats(device, &active, &pending);
> if (ret == -1) {
>/* We don't know the real error. */
> -  anv_device_set_lost(device, "get_reset_stats failed: %m");
> -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> -   "get_reset_stats failed: %m");
> +  return anv_device_set_lost(device, "get_reset_stats failed: %m");
> }
>  
> if (active) {
> -  anv_device_set_lost(device, "GPU hung on one of our command buffers");
> -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> -   "GPU hung on one of our command buffers");
> +  return anv_device_set_lost(device, "GPU hung on one of our command 
> buffers");
> } else if (pending) {
> -  anv_device_set_lost(device, "GPU hung with commands in-flight");
> -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> -   "GPU hung with commands in-flight");
> +  return anv_device_set_lost(device, "GPU hung with commands in-flight");
> }
>  
> return VK_SUCCESS;
> @@ -2109,9 +2108,7 @@ anv_device_bo_busy(struct anv_device *device, struct 
> anv_bo *bo)
>return VK_NOT_READY;
> } else if (ret == -1) {
>/* We don't know the real error. */
> -  anv_device_set_lost(device, "gem wait failed: %m");
> -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> -   "gem wait failed: %m");
> +  return anv_device_set_lost(device, "gem wait failed: %m");
> }
>  
> /* Query for device status after the busy call.  If the BO we're checking
> @@ -2132,9 +2129,7 @@ anv_device_wait(struct anv_device *device, struct 
> anv_bo *bo,
>return VK_TIMEOUT;
> } else if (ret == -1) {
>/* We don't know the real error. */
> -  anv_device_set_lost(device, "gem wait failed: %m");
> -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> -   "gem wait failed: %m");
> +  return anv_device_set_lost(device, "gem wait failed: %m");
> }
>  
> /* Query for device status after the wait.  If the BO we're waiting on got
> @@ -3111,9 +3106,8 @@ VkResult anv_GetCalibratedTimestampsEXT(
>  &pTimestamps[d]);
>  
>   if (ret != 0) {
> -anv_device_set_lost(device, "Failed to get a timestamp");
> -return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> - "Failed to read the TIMESTAMP register: %m");
> +return anv_device_set_lost(device, "Failed to read the TIMESTAMP 
> "
> +   "register: %m");
>   }
>   uint64_t device_period = DIV_ROUND_UP(10, 
> timestamp_frequency);
>   max_clock_period = MAX2(max_clock_period, device_period);
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
> index c5d636fef8d..25e290ed112 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -1083,8 +1083,11 @@ anv_state_flush(struct anv_device *device, struct 
> anv_state state)
>  void anv_device_init_blorp(struct anv_device *device);
>  void anv_device_finish

Re: [Mesa-dev] [PATCH mesa] anv: set error in anv_device_set_lost()

2018-10-26 Thread Eric Engestrom
On Friday, 2018-10-26 12:39:25 -0500, Jason Ekstrand wrote:
> I sent two patches for this an hour ago

Oops, should've checked before sending mine :)
Your solution is cleaner; r-b

> 
> On Fri, Oct 26, 2018 at 12:31 PM Eric Engestrom 
> wrote:
> 
> > This de-duplicates the error messages.
> >
> > Signed-off-by: Eric Engestrom 
> > ---
> > Kinda hacky, so I won't take it personally if I get a "heck no!" :P
> > ---
> >  src/intel/vulkan/anv_device.c  | 27 ---
> >  src/intel/vulkan/anv_private.h |  5 +
> >  src/intel/vulkan/anv_queue.c   | 16 
> >  src/intel/vulkan/genX_query.c  |  4 +---
> >  4 files changed, 18 insertions(+), 34 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> > index 495a4ecab080bdd7de41..bb418b6969da644aba8a 100644
> > --- a/src/intel/vulkan/anv_device.c
> > +++ b/src/intel/vulkan/anv_device.c
> > @@ -2049,7 +2049,7 @@ void anv_GetDeviceQueue2(
> >  }
> >
> >  void
> > -anv_device_set_lost(struct anv_device *device, const char *msg, ...)
> > +(anv_device_set_lost)(struct anv_device *device, const char *msg, ...)
> >  {
> > device->_lost = true;
> >
> > @@ -2079,19 +2079,13 @@ anv_device_query_status(struct anv_device *device)
> > int ret = anv_gem_gpu_get_reset_stats(device, &active, &pending);
> > if (ret == -1) {
> >/* We don't know the real error. */
> > -  anv_device_set_lost(device, "get_reset_stats failed: %m");
> > -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> > -   "get_reset_stats failed: %m");
> > +  return anv_device_set_lost(device, "get_reset_stats failed: %m");
> > }
> >
> > if (active) {
> > -  anv_device_set_lost(device, "GPU hung on one of our command
> > buffers");
> > -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> > -   "GPU hung on one of our command buffers");
> > +  return anv_device_set_lost(device, "GPU hung on one of our command
> > buffers");
> > } else if (pending) {
> > -  anv_device_set_lost(device, "GPU hung with commands in-flight");
> > -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> > -   "GPU hung with commands in-flight");
> > +  return anv_device_set_lost(device, "GPU hung with commands
> > in-flight");
> > }
> >
> > return VK_SUCCESS;
> > @@ -2109,9 +2103,7 @@ anv_device_bo_busy(struct anv_device *device, struct
> > anv_bo *bo)
> >return VK_NOT_READY;
> > } else if (ret == -1) {
> >/* We don't know the real error. */
> > -  anv_device_set_lost(device, "gem wait failed: %m");
> > -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> > -   "gem wait failed: %m");
> > +  return anv_device_set_lost(device, "gem wait failed: %m");
> > }
> >
> > /* Query for device status after the busy call.  If the BO we're
> > checking
> > @@ -2132,9 +2124,7 @@ anv_device_wait(struct anv_device *device, struct
> > anv_bo *bo,
> >return VK_TIMEOUT;
> > } else if (ret == -1) {
> >/* We don't know the real error. */
> > -  anv_device_set_lost(device, "gem wait failed: %m");
> > -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> > -   "gem wait failed: %m");
> > +  return anv_device_set_lost(device, "gem wait failed: %m");
> > }
> >
> > /* Query for device status after the wait.  If the BO we're waiting on
> > got
> > @@ -3111,9 +3101,8 @@ VkResult anv_GetCalibratedTimestampsEXT(
> >  &pTimestamps[d]);
> >
> >   if (ret != 0) {
> > -anv_device_set_lost(device, "Failed to get a timestamp");
> > -return vk_errorf(device->instance, device,
> > VK_ERROR_DEVICE_LOST,
> > - "Failed to read the TIMESTAMP register: %m");
> > +return anv_device_set_lost(device,
> > +   "Failed to read the TIMESTAMP
> > register: %m");
> >   }
> >   uint64_t device_period = DIV_ROUND_UP(10,
> > timestamp_frequency);
> >   max_clock_period = MAX2(max_clock_period, device_period);
> > diff --git a/src/intel/vulkan/anv_private.h
> > b/src/intel/vulkan/anv_private.h
> > index a3ab971b6fd8b2355933..30e02142dba5f77641ca 100644
> > --- a/src/intel/vulkan/anv_private.h
> > +++ b/src/intel/vulkan/anv_private.h
> > @@ -1077,6 +1077,11 @@ void anv_device_finish_blorp(struct anv_device
> > *device);
> >
> >  void anv_device_set_lost(struct anv_device *device,
> >   const char *msg, ...);
> > +#define anv_device_set_lost(dev, msg, ...) \
> > +   ({ \
> > +  (anv_device_set_lost)(dev, msg, ##__VA_ARGS__); \
> > +  vk_errorf(dev->instance, dev, VK_ERROR_DEVICE_LOST, msg,
> > ##__VA_ARGS__); \
> > +   })
> >
> >  static inline bool
> >  anv_device_is_lost(struct anv_dev

Re: [Mesa-dev] [PATCH 1/2] anv/util: Split a vk_errorv helper out of vk_errorf

2018-10-26 Thread Lionel Landwerlin

Awesome, thanks for doing this.

This series is :

Reviewed-by: Lionel Landwerlin 

On 26/10/2018 17:42, Jason Ekstrand wrote:

---
  src/intel/vulkan/anv_private.h |  8 
  src/intel/vulkan/anv_util.c| 23 +--
  2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index a3ab971b6fd..c5d636fef8d 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -381,6 +381,11 @@ vk_to_isl_color(VkClearColorValue color)
   * propagating errors. Might be useful to plug in a stack trace here.
   */
  
+VkResult __vk_errorv(struct anv_instance *instance, const void *object,

+ VkDebugReportObjectTypeEXT type, VkResult error,
+ const char *file, int line, const char *format,
+ va_list args);
+
  VkResult __vk_errorf(struct anv_instance *instance, const void *object,
   VkDebugReportObjectTypeEXT type, VkResult error,
   const char *file, int line, const char *format, ...);
@@ -389,6 +394,9 @@ VkResult __vk_errorf(struct anv_instance *instance, const 
void *object,
  #define vk_error(error) __vk_errorf(NULL, NULL,\
  VK_DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT,\
  error, __FILE__, __LINE__, NULL)
+#define vk_errorv(instance, obj, error, format, args)\
+__vk_errorv(instance, obj, REPORT_OBJECT_TYPE(obj), error,\
+__FILE__, __LINE__, format, args)
  #define vk_errorf(instance, obj, error, format, ...)\
  __vk_errorf(instance, obj, REPORT_OBJECT_TYPE(obj), error,\
  __FILE__, __LINE__, format, ## __VA_ARGS__)
diff --git a/src/intel/vulkan/anv_util.c b/src/intel/vulkan/anv_util.c
index 8ccb61b35c1..1159ccecc6a 100644
--- a/src/intel/vulkan/anv_util.c
+++ b/src/intel/vulkan/anv_util.c
@@ -77,20 +77,17 @@ __anv_perf_warn(struct anv_instance *instance, const void 
*object,
  }
  
  VkResult

-__vk_errorf(struct anv_instance *instance, const void *object,
- VkDebugReportObjectTypeEXT type, VkResult error,
- const char *file, int line, const char *format, ...)
+__vk_errorv(struct anv_instance *instance, const void *object,
+VkDebugReportObjectTypeEXT type, VkResult error,
+const char *file, int line, const char *format, va_list ap)
  {
-   va_list ap;
 char buffer[256];
 char report[512];
  
 const char *error_str = vk_Result_to_str(error);
  
 if (format) {

-  va_start(ap, format);
vsnprintf(buffer, sizeof(buffer), format, ap);
-  va_end(ap);
  
snprintf(report, sizeof(report), "%s:%d: %s (%s)", file, line, buffer,

 error_str);
@@ -113,3 +110,17 @@ __vk_errorf(struct anv_instance *instance, const void 
*object,
  
 return error;

  }
+
+VkResult
+__vk_errorf(struct anv_instance *instance, const void *object,
+VkDebugReportObjectTypeEXT type, VkResult error,
+const char *file, int line, const char *format, ...)
+{
+   va_list ap;
+
+   va_start(ap, format);
+   __vk_errorv(instance, object, type, error, file, line, format, ap);
+   va_end(ap);
+
+   return error;
+}



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


Re: [Mesa-dev] [PATCH 00/31] nir: Use a 1-bit data type for booleans

2018-10-26 Thread Jason Ekstrand
Thanks!  I've pushed the first 13.

On Mon, Oct 22, 2018 at 6:06 PM Ian Romanick  wrote:

> Patches 1 through 13 are
>
> Reviewed-by: Ian Romanick 
>
> The rest are going to take a bit more time and deep thought.
>
> On 10/22/2018 03:13 PM, Jason Ekstrand wrote:
> > This is something that Connor and I have talked about quite a bit over
> the
> > last couple of months.  The core idea is to replace NIR's current 32-bit
> > 0/-1 D3D10-style booleans with a 1-bit data type.  All in all, I think it
> > worked out pretty well though I really don't like the proliferation of
> > 32-bit comparison opcodes we now have kicking around for i965.
> >
> > Why?  No hardware really has a 1-bit type, right?  Well, sort of...  AMD
> > actually uses 64-bit scalars for booleans with one bit per invocation.
> > However, most hardware such as Intel uses some other larger value for
> > booleans.  The real benefit of 1-bit booleans and requiring a lowering
> pass
> > is that you can do somewhat custom lowering (like AMD wants) and your
> > lowering pass can always tell in an instant if a value is a boolean based
> > on the bit size.  As can be seen in the last patch, this makes it really
> > easy to implement a bool -> float lowering pass for hardware that doesn't
> > have real integers where NIR's current booleans are actually rather
> > painful.
> >
> > On Intel, the situation is a bit more complicated.  It's tempting to say
> > that we have 32-bit D3D10 booleans.  However, they're not really D3D10
> > booleans on gen4-5 because the top 31 bits are undefined garbage and,
> while
> > iand, ior, ixor, and inot operations work, you have to iand with 1 at the
> > last minute to clear off all that garbage.  Also, on all generations, a
> > comparison of two N-bit values results in an N-bit boolean, not a 32-bit
> > bool.  This has caused the Igalia folks no end of trouble as they've been
> > working on native 8 and 16-bit support.  If, instead, we have a 1-bit
> bool
> > with a lowering pass and we can lower to whatever we want, then we could
> > lower to a set of comparison opcodes that return the same bit-size as
> they
> > compare and it would match GEN hardware much better.
> >
> > But what about performance?  Aren't there all sorts of neat tricks we can
> > do with D3D10 booleans like b & 1.0f for b2f?  As it turns out, not
> really;
> > that's about the only one.  There is some small advantage when optimizing
> > shaders that come from D3D if your native representation of booleans
> > matches that of D3D.  However, penultimate patch in this series adds a
> few
> > small optimizations that get us to actually better than we were before.
> > With the entire series, shader-db on Kaby Lak looks like this:
> >
> > total instructions in shared programs: 15084098 -> 14988578 (-0.63%)
> > instructions in affected programs: 1321114 -> 1225594 (-7.23%)
> > helped: 2340
> > HURT: 23
> >
> > total cycles in shared programs: 369790134 -> 359798399 (-2.70%)
> > cycles in affected programs: 134085452 -> 124093717 (-7.45%)
> > helped: 2149
> > HURT: 720
> >
> > total loops in shared programs: 4393 -> 4393 (0.00%)
> > loops in affected programs: 0 -> 0
> > helped: 0
> > HURT: 0
> >
> > total spills in shared programs: 10158 -> 10051 (-1.05%)
> > spills in affected programs: 1429 -> 1322 (-7.49%)
> > helped: 8
> > HURT: 15
> >
> > total fills in shared programs: 22105 -> 21720 (-1.74%)
> > fills in affected programs: 2853 -> 2468 (-13.49%)
> > helped: 12
> > HURT: 15
> >
> > How about ease of use?  Are they a pain to deal with?  Yes, adding
> support
> > for 1-bit types was a bit awkward in a few places but most of it was
> > dealing with all the places where we have 32-bit booleans baked into
> > assumptions.  Getting rid of that baking in solves the problem and also
> > makes the whole IR more future-proof.
> >
> > All in all, I'd say I'm pretty happy with it.  However, I'd like other
> > people (particularly the AMD folks) to play with it a bit and verify that
> > it solves their problems as well.  Also, I added a lowering pass and
> tried
> > to turn it on in everyone's driver but may not have put it in the right
> > spot.  Please double-check my work.  For those wishing to take a look,
> you
> > can also find the entire series on my gitlab here:
> >
> >
> https://gitlab.freedesktop.org/jekstrand/mesa/commits/review/nir-1-bit-bool
> >
> > Please review!
> >
> > --Jason
> >
> > Cc: Connor Abbott 
> > Cc: Timothy Arceri 
> > Cc: Eric Anholt 
> > Cc: Rob Clark 
> > Cc: Karol Herbst 
> > Cc: Bas Nieuwenhuizen 
> > Cc: Alyssa Rosenzweig 
> >
> >
> > Jason Ekstrand (31):
> >   nir/validate: Print when the validation failed
> >   nir/constant_folding: Add an unreachable to a switch
> >   nir/constant_folding: Use nir_src_as_bool for discard_if
> >   nir/builder: Add a nir_imm_true/false helpers
> >   nir/builder: Handle 16-bit floats in nir_imm_floatN_t
> >   nir/search: 

Re: [Mesa-dev] [PATCH v1 1/5] meson: compilation flags for sse

2018-10-26 Thread Matt Turner
On Fri, Oct 26, 2018 at 3:06 AM Sergii Romantsov
 wrote:
>
> While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
> So it has to be done manually by flag '-msee'.
> Added support of such specification to build-system.
>
> CC: Dylan Baker 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
> Signed-off-by: Sergii Romantsov 

We can't do that.

Maybe I'm missing some context. What problem are we solving?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [AppVeyor] mesa master #9159 failed

2018-10-26 Thread AppVeyor



Build mesa 9159 failed


Commit 5bcf479524 by Nanley Chery on 10/25/2018 9:08 PM:

intel/blorp: Define the clear value bounds for HiZ clears\n\nFollow the restriction of making sure the clear value is between the min\nand max values defined in CC_VIEWPORT. Avoids a simulator warning for\nsome piglit tests, one of them being:\n\n./bin/depthstencil-render-miplevels 146 d=z32f_s8\n\nJason found this to fix incorrect clearing on SKL.\n\nFixes: 09948151ab1d5184b4dd9052bb1f710fa1e00a7b\n   ("intel/blorp: Add the BDW+ optimized HZ_OP sequence to BLORP")\n\nReviewed-by: Jason Ekstrand \nTested-by: Jason Ekstrand 


Configure your notification preferences

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


Re: [Mesa-dev] [PATCH mesa] anv: set error in anv_device_set_lost()

2018-10-26 Thread Jason Ekstrand
I sent two patches for this an hour ago

On Fri, Oct 26, 2018 at 12:31 PM Eric Engestrom 
wrote:

> This de-duplicates the error messages.
>
> Signed-off-by: Eric Engestrom 
> ---
> Kinda hacky, so I won't take it personally if I get a "heck no!" :P
> ---
>  src/intel/vulkan/anv_device.c  | 27 ---
>  src/intel/vulkan/anv_private.h |  5 +
>  src/intel/vulkan/anv_queue.c   | 16 
>  src/intel/vulkan/genX_query.c  |  4 +---
>  4 files changed, 18 insertions(+), 34 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 495a4ecab080bdd7de41..bb418b6969da644aba8a 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -2049,7 +2049,7 @@ void anv_GetDeviceQueue2(
>  }
>
>  void
> -anv_device_set_lost(struct anv_device *device, const char *msg, ...)
> +(anv_device_set_lost)(struct anv_device *device, const char *msg, ...)
>  {
> device->_lost = true;
>
> @@ -2079,19 +2079,13 @@ anv_device_query_status(struct anv_device *device)
> int ret = anv_gem_gpu_get_reset_stats(device, &active, &pending);
> if (ret == -1) {
>/* We don't know the real error. */
> -  anv_device_set_lost(device, "get_reset_stats failed: %m");
> -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> -   "get_reset_stats failed: %m");
> +  return anv_device_set_lost(device, "get_reset_stats failed: %m");
> }
>
> if (active) {
> -  anv_device_set_lost(device, "GPU hung on one of our command
> buffers");
> -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> -   "GPU hung on one of our command buffers");
> +  return anv_device_set_lost(device, "GPU hung on one of our command
> buffers");
> } else if (pending) {
> -  anv_device_set_lost(device, "GPU hung with commands in-flight");
> -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> -   "GPU hung with commands in-flight");
> +  return anv_device_set_lost(device, "GPU hung with commands
> in-flight");
> }
>
> return VK_SUCCESS;
> @@ -2109,9 +2103,7 @@ anv_device_bo_busy(struct anv_device *device, struct
> anv_bo *bo)
>return VK_NOT_READY;
> } else if (ret == -1) {
>/* We don't know the real error. */
> -  anv_device_set_lost(device, "gem wait failed: %m");
> -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> -   "gem wait failed: %m");
> +  return anv_device_set_lost(device, "gem wait failed: %m");
> }
>
> /* Query for device status after the busy call.  If the BO we're
> checking
> @@ -2132,9 +2124,7 @@ anv_device_wait(struct anv_device *device, struct
> anv_bo *bo,
>return VK_TIMEOUT;
> } else if (ret == -1) {
>/* We don't know the real error. */
> -  anv_device_set_lost(device, "gem wait failed: %m");
> -  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
> -   "gem wait failed: %m");
> +  return anv_device_set_lost(device, "gem wait failed: %m");
> }
>
> /* Query for device status after the wait.  If the BO we're waiting on
> got
> @@ -3111,9 +3101,8 @@ VkResult anv_GetCalibratedTimestampsEXT(
>  &pTimestamps[d]);
>
>   if (ret != 0) {
> -anv_device_set_lost(device, "Failed to get a timestamp");
> -return vk_errorf(device->instance, device,
> VK_ERROR_DEVICE_LOST,
> - "Failed to read the TIMESTAMP register: %m");
> +return anv_device_set_lost(device,
> +   "Failed to read the TIMESTAMP
> register: %m");
>   }
>   uint64_t device_period = DIV_ROUND_UP(10,
> timestamp_frequency);
>   max_clock_period = MAX2(max_clock_period, device_period);
> diff --git a/src/intel/vulkan/anv_private.h
> b/src/intel/vulkan/anv_private.h
> index a3ab971b6fd8b2355933..30e02142dba5f77641ca 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -1077,6 +1077,11 @@ void anv_device_finish_blorp(struct anv_device
> *device);
>
>  void anv_device_set_lost(struct anv_device *device,
>   const char *msg, ...);
> +#define anv_device_set_lost(dev, msg, ...) \
> +   ({ \
> +  (anv_device_set_lost)(dev, msg, ##__VA_ARGS__); \
> +  vk_errorf(dev->instance, dev, VK_ERROR_DEVICE_LOST, msg,
> ##__VA_ARGS__); \
> +   })
>
>  static inline bool
>  anv_device_is_lost(struct anv_device *device)
> diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
> index 8e9f743fcb7a953a1f8f..6247ba8751e1fc3d2411 100644
> --- a/src/intel/vulkan/anv_queue.c
> +++ b/src/intel/vulkan/anv_queue.c
> @@ -42,9 +42,7 @@ anv_device_execbuf(struct anv_device *device,
> int ret = device->no_hw ? 0 : anv_gem_execbuffer(device, execbuf);
> if (re

Re: [Mesa-dev] [PATCH] scons/svga: remove opt from the list of valid build types

2018-10-26 Thread Jose Fonseca
Looks great.

Reviewed-by: Jose Fonseca 

On 26/10/18 17:52, Brian Paul wrote:
> This reverts commit a5fd54f8bf6713312fa5efd7ef5cd125557a0ffe.
> 
> The whole point was to add a way to pass -DVMX86_STATS to the build,
> but we can do that with a command line argument when we invoke scons.
> ---
>   common.py  | 2 +-
>   scons/gallium.py   | 8 +++-
>   src/gallium/drivers/svga/svga_screen.c | 2 --
>   3 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/common.py b/common.py
> index be3ccfc..e2afff9 100644
> --- a/common.py
> +++ b/common.py
> @@ -86,7 +86,7 @@ def AddOptions(opts):
>   from SCons.Options.EnumOption import EnumOption
>   opts.Add(EnumOption('build', 'build type', 'debug',
>   allowed_values=('debug', 'checked', 'profile',
> -'release', 'opt')))
> +'release')))
>   opts.Add(BoolOption('verbose', 'verbose output', 'no'))
>   opts.Add(EnumOption('machine', 'use machine-specific assembly code',
>   default_machine,
> diff --git a/scons/gallium.py b/scons/gallium.py
> index aa7201a..963834a 100755
> --- a/scons/gallium.py
> +++ b/scons/gallium.py
> @@ -279,7 +279,7 @@ def generate(env):
>   if env['build'] == 'profile':
>   env['debug'] = False
>   env['profile'] = True
> -if env['build'] in ('release', 'opt'):
> +if env['build'] == 'release':
>   env['debug'] = False
>   env['profile'] = False
>   
> @@ -325,8 +325,6 @@ def generate(env):
>   cppdefines += ['NDEBUG']
>   if env['build'] == 'profile':
>   cppdefines += ['PROFILE']
> -if env['build'] in ('opt', 'profile'):
> -cppdefines += ['VMX86_STATS']
>   if env['platform'] in ('posix', 'linux', 'freebsd', 'darwin'):
>   cppdefines += [
>   '_POSIX_SOURCE',
> @@ -477,7 +475,7 @@ def generate(env):
>   ccflags += [
>   '/O2', # optimize for speed
>   ]
> -if env['build'] in ('release', 'opt'):
> +if env['build'] == 'release':
>   if not env['clang']:
>   ccflags += [
>   '/GL', # enable whole program optimization
> @@ -588,7 +586,7 @@ def generate(env):
>   shlinkflags += ['-Wl,--enable-stdcall-fixup']
>   #shlinkflags += ['-Wl,--kill-at']
>   if msvc:
> -if env['build'] in ('release', 'opt') and not env['clang']:
> +if env['build'] == 'release' and not env['clang']:
>   # enable Link-time Code Generation
>   linkflags += ['/LTCG']
>   env.Append(ARFLAGS = ['/LTCG'])
> diff --git a/src/gallium/drivers/svga/svga_screen.c 
> b/src/gallium/drivers/svga/svga_screen.c
> index ab9a3c7..95dde8b 100644
> --- a/src/gallium/drivers/svga/svga_screen.c
> +++ b/src/gallium/drivers/svga/svga_screen.c
> @@ -92,8 +92,6 @@ svga_get_name( struct pipe_screen *pscreen )
>   */
>  build = "build: DEBUG;";
>  mutex = "mutex: " PIPE_ATOMIC ";";
> -#elif defined(VMX86_STATS)
> -   build = "build: OPT;";
>   #else
>  build = "build: RELEASE;";
>   #endif
> 

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


[Mesa-dev] [PATCH mesa] anv: set error in anv_device_set_lost()

2018-10-26 Thread Eric Engestrom
This de-duplicates the error messages.

Signed-off-by: Eric Engestrom 
---
Kinda hacky, so I won't take it personally if I get a "heck no!" :P
---
 src/intel/vulkan/anv_device.c  | 27 ---
 src/intel/vulkan/anv_private.h |  5 +
 src/intel/vulkan/anv_queue.c   | 16 
 src/intel/vulkan/genX_query.c  |  4 +---
 4 files changed, 18 insertions(+), 34 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 495a4ecab080bdd7de41..bb418b6969da644aba8a 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -2049,7 +2049,7 @@ void anv_GetDeviceQueue2(
 }
 
 void
-anv_device_set_lost(struct anv_device *device, const char *msg, ...)
+(anv_device_set_lost)(struct anv_device *device, const char *msg, ...)
 {
device->_lost = true;
 
@@ -2079,19 +2079,13 @@ anv_device_query_status(struct anv_device *device)
int ret = anv_gem_gpu_get_reset_stats(device, &active, &pending);
if (ret == -1) {
   /* We don't know the real error. */
-  anv_device_set_lost(device, "get_reset_stats failed: %m");
-  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
-   "get_reset_stats failed: %m");
+  return anv_device_set_lost(device, "get_reset_stats failed: %m");
}
 
if (active) {
-  anv_device_set_lost(device, "GPU hung on one of our command buffers");
-  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
-   "GPU hung on one of our command buffers");
+  return anv_device_set_lost(device, "GPU hung on one of our command 
buffers");
} else if (pending) {
-  anv_device_set_lost(device, "GPU hung with commands in-flight");
-  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
-   "GPU hung with commands in-flight");
+  return anv_device_set_lost(device, "GPU hung with commands in-flight");
}
 
return VK_SUCCESS;
@@ -2109,9 +2103,7 @@ anv_device_bo_busy(struct anv_device *device, struct 
anv_bo *bo)
   return VK_NOT_READY;
} else if (ret == -1) {
   /* We don't know the real error. */
-  anv_device_set_lost(device, "gem wait failed: %m");
-  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
-   "gem wait failed: %m");
+  return anv_device_set_lost(device, "gem wait failed: %m");
}
 
/* Query for device status after the busy call.  If the BO we're checking
@@ -2132,9 +2124,7 @@ anv_device_wait(struct anv_device *device, struct anv_bo 
*bo,
   return VK_TIMEOUT;
} else if (ret == -1) {
   /* We don't know the real error. */
-  anv_device_set_lost(device, "gem wait failed: %m");
-  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
-   "gem wait failed: %m");
+  return anv_device_set_lost(device, "gem wait failed: %m");
}
 
/* Query for device status after the wait.  If the BO we're waiting on got
@@ -3111,9 +3101,8 @@ VkResult anv_GetCalibratedTimestampsEXT(
 &pTimestamps[d]);
 
  if (ret != 0) {
-anv_device_set_lost(device, "Failed to get a timestamp");
-return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
- "Failed to read the TIMESTAMP register: %m");
+return anv_device_set_lost(device,
+   "Failed to read the TIMESTAMP register: 
%m");
  }
  uint64_t device_period = DIV_ROUND_UP(10, 
timestamp_frequency);
  max_clock_period = MAX2(max_clock_period, device_period);
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index a3ab971b6fd8b2355933..30e02142dba5f77641ca 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1077,6 +1077,11 @@ void anv_device_finish_blorp(struct anv_device *device);
 
 void anv_device_set_lost(struct anv_device *device,
  const char *msg, ...);
+#define anv_device_set_lost(dev, msg, ...) \
+   ({ \
+  (anv_device_set_lost)(dev, msg, ##__VA_ARGS__); \
+  vk_errorf(dev->instance, dev, VK_ERROR_DEVICE_LOST, msg, ##__VA_ARGS__); 
\
+   })
 
 static inline bool
 anv_device_is_lost(struct anv_device *device)
diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 8e9f743fcb7a953a1f8f..6247ba8751e1fc3d2411 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -42,9 +42,7 @@ anv_device_execbuf(struct anv_device *device,
int ret = device->no_hw ? 0 : anv_gem_execbuffer(device, execbuf);
if (ret != 0) {
   /* We don't know the real error. */
-  anv_device_set_lost(device, "execbuf2 failed: %m");
-  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
-   "execbuf2 failed: %m");
+  return anv_device_set_lost(device, "execbuf2 failed: %m");
}
 
st

Re: [Mesa-dev] [PATCH] intel/blorp: Define the clear value bounds for HiZ clears

2018-10-26 Thread Nanley Chery
On Fri, Oct 26, 2018 at 12:02:58PM -0500, Jason Ekstrand wrote:
> On Thu, Oct 25, 2018 at 6:25 PM  wrote:
> 
> > From: Nanley Chery 
> >
> > Follow the restriction of making sure the clear value is between the min
> > and max values defined in CC_VIEWPORT. Avoids a simulator warning for
> > some piglit tests, one of them being:
> >
> > ./bin/depthstencil-render-miplevels 146 d=z32f_s8
> >
> > Jason found this to make a GPU hang go away on SKL.
> >
> 
> It wasn't really hangs.  It was just incorrect clearing.  The hangs may be
> related but I have no proof of that.  With the commit message adjusted
> accordingly, this patch is
> 
> Reviewed-by: Jason Ekstrand 
> Tested-by: Jason Ekstrand 
> 

Ah, okay. I'll change the line to say:

   Jason found this to fix incorrect clearing on SKL.

Thanks!

> 
> > Fixes: 09948151ab1d5184b4dd9052bb1f710fa1e00a7b
> >("intel/blorp: Add the BDW+ optimized HZ_OP sequence to BLORP")
> > ---
> >  src/intel/blorp/blorp_genX_exec.h | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/src/intel/blorp/blorp_genX_exec.h
> > b/src/intel/blorp/blorp_genX_exec.h
> > index 50341ab0ecf..7a8c45dbee5 100644
> > --- a/src/intel/blorp/blorp_genX_exec.h
> > +++ b/src/intel/blorp/blorp_genX_exec.h
> > @@ -1628,6 +1628,20 @@ blorp_emit_gen8_hiz_op(struct blorp_batch *batch,
> >  */
> > blorp_emit_3dstate_multisample(batch, params);
> >
> > +   /* From the BDW PRM Volume 7, Depth Buffer Clear:
> > +*
> > +*The clear value must be between the min and max depth values
> > +*(inclusive) defined in the CC_VIEWPORT. If the depth buffer
> > format is
> > +*D32_FLOAT, then +/-DENORM values are also allowed.
> > +*
> > +* Set the bounds to match our hardware limits, [0.0, 1.0].
> > +*/
> > +   if (params->depth.enabled && params->hiz_op == ISL_AUX_OP_FAST_CLEAR) {
> > +  assert(params->depth.clear_color.f32[0] >= 0.0f);
> > +  assert(params->depth.clear_color.f32[0] <= 1.0f);
> > +  blorp_emit_cc_viewport(batch);
> > +   }
> > +
> > /* If we can't alter the depth stencil config and multiple layers are
> >  * involved, the HiZ op will fail. This is because the op requires
> > that a
> >  * new config is emitted for each additional layer.
> > --
> > 2.19.0
> >
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 09/14] util/gen_xmlpool: Use print function instad of sys.stderr.write

2018-10-26 Thread Dylan Baker
This ensures that stderr is flushed, unlike writing
---
 src/util/xmlpool/gen_xmlpool.py | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
index 70e0f96df9e..9d932f3e85c 100644
--- a/src/util/xmlpool/gen_xmlpool.py
+++ b/src/util/xmlpool/gen_xmlpool.py
@@ -170,7 +170,7 @@ for lang in args.languages:
 with io.open(filename, 'rb') as f:
 trans = gettext.GNUTranslations(f)
 except (IOError, OSError):
-sys.stderr.write("Warning: language '%s' not found.\n" % lang)
+print("Warning: language '%s' not found." % lang, file=sys.stderr)
 continue
 translations.append((lang, trans))
 
@@ -200,9 +200,8 @@ for line in template:
 expandMatches(descMatches, translations, line)
 descMatches = []
 else:
-sys.stderr.write(
-"Warning: unexpected line inside description dropped:\n%s\n" \
-% line)
+print("Warning: unexpected line inside description dropped:\n", 
line,
+  file=sys.stderr)
 continue
 if reLibintl_h.search(line):
 # Ignore (comment out) #include 
@@ -227,5 +226,5 @@ for line in template:
 template.close()
 
 if len(descMatches) > 0:
-sys.stderr.write("Warning: unterminated description at end of file.\n")
+print("Warning: unterminated description at end of file.", file=sys.stderr)
 expandMatches(descMatches, translations)
-- 
2.19.1

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


[Mesa-dev] [PATCH 01/14] util/gen_xmlpool: use argparse for argument handling

2018-10-26 Thread Dylan Baker
This is a little cleaner than just looking at sys.argv, but it's also
going to allow us to handle the differences in the way meson and
autotools handle translations more cleanly.

Reviewed-by: Eric Engestrom 
---
 src/util/xmlpool/gen_xmlpool.py | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
index 56a67bcab55..b40f295738e 100644
--- a/src/util/xmlpool/gen_xmlpool.py
+++ b/src/util/xmlpool/gen_xmlpool.py
@@ -9,25 +9,23 @@
 
 from __future__ import print_function
 
+import argparse
 import io
 import sys
 import gettext
 import re
 
+parser = argparse.ArgumentParser()
+parser.add_argument('template')
+parser.add_argument('localedir')
+parser.add_argument('languages', nargs='*')
+args = parser.parse_args()
 
 if sys.version_info < (3, 0):
 gettext_method = 'ugettext'
 else:
 gettext_method = 'gettext'
 
-# Path to t_options.h
-template_header_path = sys.argv[1]
-
-localedir = sys.argv[2]
-
-# List of supported languages
-languages = sys.argv[3:]
-
 # Escape special characters in C strings
 def escapeCString (s):
 escapeSeqs = {'\a' : '\\a', '\b' : '\\b', '\f' : '\\f', '\n' : '\\n',
@@ -166,9 +164,9 @@ def expandMatches (matches, translations, end=None):
 # Compile a list of translation classes to all supported languages.
 # The first translation is always a NullTranslations.
 translations = [("en", gettext.NullTranslations())]
-for lang in languages:
+for lang in args.languages:
 try:
-trans = gettext.translation ("options", localedir, [lang])
+trans = gettext.translation ("options", args.localedir, [lang])
 except IOError:
 sys.stderr.write ("Warning: language '%s' not found.\n" % lang)
 continue
@@ -188,7 +186,7 @@ 
print("/***\
 
 # Process the options template and generate options.h with all
 # translations.
-template = io.open (template_header_path, mode="rt", encoding='utf-8')
+template = io.open (args.template, mode="rt", encoding='utf-8')
 descMatches = []
 for line in template:
 if len(descMatches) > 0:
-- 
2.19.1

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


[Mesa-dev] [PATCH 02/14] meson: add support for generating translation mo files

2018-10-26 Thread Dylan Baker
Meson has handy a handy built-in module for handling gettext called
i18n, this module works a bit differently than our autotools build does,
namely it doesn't automatically generate translations instead it creates
3 new top level targets to run. These are:

xmlpool-pot
xmlpool-update-po
xmlpool-gmo

v2: - Add new files to autotools dist tarball
---
 src/util/xmlpool/LINGUAS | 1 +
 src/util/xmlpool/Makefile.am | 4 +++-
 src/util/xmlpool/POTFILES| 1 +
 src/util/xmlpool/meson.build | 3 +++
 4 files changed, 8 insertions(+), 1 deletion(-)
 create mode 100644 src/util/xmlpool/LINGUAS
 create mode 100644 src/util/xmlpool/POTFILES

diff --git a/src/util/xmlpool/LINGUAS b/src/util/xmlpool/LINGUAS
new file mode 100644
index 000..3620176519e
--- /dev/null
+++ b/src/util/xmlpool/LINGUAS
@@ -0,0 +1 @@
+ca es de nl sv fr
diff --git a/src/util/xmlpool/Makefile.am b/src/util/xmlpool/Makefile.am
index 0ef7a5462a1..78a08fab4b1 100644
--- a/src/util/xmlpool/Makefile.am
+++ b/src/util/xmlpool/Makefile.am
@@ -59,7 +59,9 @@ EXTRA_DIST = \
$(POS) \
$(MOS) \
SConscript \
-   meson.build
+   meson.build \
+   LINGUAS \
+   POTFILES
 
 BUILT_SOURCES = options.h
 CLEANFILES = \
diff --git a/src/util/xmlpool/POTFILES b/src/util/xmlpool/POTFILES
new file mode 100644
index 000..d68d7009be4
--- /dev/null
+++ b/src/util/xmlpool/POTFILES
@@ -0,0 +1 @@
+src/util/xmlpool/t_options.h
diff --git a/src/util/xmlpool/meson.build b/src/util/xmlpool/meson.build
index 8bdabcb825b..8d645ce385f 100644
--- a/src/util/xmlpool/meson.build
+++ b/src/util/xmlpool/meson.build
@@ -35,3 +35,6 @@ xmlpool_options_h = custom_target(
   capture : true,
   depend_files : _langs_po_files,
 )
+
+i18n = import('i18n')
+i18n.gettext('xmlpool')
-- 
2.19.1

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


[Mesa-dev] [PATCH 10/14] util/gen_xmlpool: use a main function

2018-10-26 Thread Dylan Baker
Again, just good style
---
 src/util/xmlpool/gen_xmlpool.py | 127 +---
 1 file changed, 66 insertions(+), 61 deletions(-)

diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
index 9d932f3e85c..a39f9e9e2fa 100644
--- a/src/util/xmlpool/gen_xmlpool.py
+++ b/src/util/xmlpool/gen_xmlpool.py
@@ -15,12 +15,6 @@ import os
 import re
 import sys
 
-parser = argparse.ArgumentParser()
-parser.add_argument('template')
-parser.add_argument('localedir')
-parser.add_argument('languages', nargs='*')
-args = parser.parse_args()
-
 if sys.version_info < (3, 0):
 gettext_method = 'ugettext'
 else:
@@ -161,19 +155,6 @@ def expandMatches(matches, translations, end=None):
 if end:
 print(end, end='')
 
-# Compile a list of translation classes to all supported languages.
-# The first translation is always a NullTranslations.
-translations = [("en", gettext.NullTranslations())]
-for lang in args.languages:
-try:
-filename = os.path.join(args.localedir, '{}.gmo'.format(lang))
-with io.open(filename, 'rb') as f:
-trans = gettext.GNUTranslations(f)
-except (IOError, OSError):
-print("Warning: language '%s' not found." % lang, file=sys.stderr)
-continue
-translations.append((lang, trans))
-
 # Regular expressions:
 reLibintl_h = re.compile(r'#\s*include\s*')
 reDESC = 
re.compile(r'(\s*DRI_CONF_DESC\s*\(\s*)([a-z]+)(\s*,\s*)(gettext\s*\(\s*")(.*)("\s*\))(\s*\)[
 \t]*\\?)$')
@@ -181,50 +162,74 @@ reDESC_BEGIN = 
re.compile(r'(\s*DRI_CONF_DESC_BEGIN\s*\(\s*)([a-z]+)(\s*,\s*)(ge
 reENUM = 
re.compile(r'(\s*DRI_CONF_ENUM\s*\([^,]+,\s*)(gettext\s*\(\s*")(.*)("\s*\))(\s*\)[
 \t]*\\?)$')
 reDESC_END = re.compile(r'\s*DRI_CONF_DESC_END')
 
-# Print a header
-print("/***\n"
 \
-" ***THIS FILE IS GENERATED AUTOMATICALLY. DON'T EDIT!***\n" \
-" ***/")
 
-# Process the options template and generate options.h with all
-# translations.
-template = io.open(args.template, mode="rt", encoding='utf-8')
-descMatches = []
-for line in template:
-if len(descMatches) > 0:
-matchENUM = reENUM.match(line)
-matchDESC_END = reDESC_END.match(line)
-if matchENUM:
-descMatches.append(matchENUM)
-elif matchDESC_END:
-expandMatches(descMatches, translations, line)
-descMatches = []
+def main():
+parser = argparse.ArgumentParser()
+parser.add_argument('template')
+parser.add_argument('localedir')
+parser.add_argument('languages', nargs='*')
+args = parser.parse_args()
+
+# Compile a list of translation classes to all supported languages.
+# The first translation is always a NullTranslations.
+translations = [("en", gettext.NullTranslations())]
+for lang in args.languages:
+try:
+filename = os.path.join(args.localedir, '{}.gmo'.format(lang))
+with io.open(filename, 'rb') as f:
+trans = gettext.GNUTranslations(f)
+except (IOError, OSError):
+print("Warning: language '%s' not found." % lang, file=sys.stderr)
+continue
+translations.append((lang, trans))
+
+
print("/***\n"
 \
+" ***THIS FILE IS GENERATED AUTOMATICALLY. DON'T EDIT!
***\n" \
+" 
***/")
+
+# Process the options template and generate options.h with all
+# translations.
+template = io.open(args.template, mode="rt", encoding='utf-8')
+descMatches = []
+for line in template:
+if len(descMatches) > 0:
+matchENUM = reENUM.match(line)
+matchDESC_END = reDESC_END.match(line)
+if matchENUM:
+descMatches.append(matchENUM)
+elif matchDESC_END:
+expandMatches(descMatches, translations, line)
+descMatches = []
+else:
+print("Warning: unexpected line inside description 
dropped:\n", line,
+  file=sys.stderr)
+continue
+if reLibintl_h.search(line):
+# Ignore (comment out) #include 
+print("/* %s * commented out by gen_xmlpool.py */" % line)
+continue
+matchDESC = reDESC.match(line)
+matchDESC_BEGIN = reDESC_BEGIN.match(line)
+if matchDESC:
+assert len(descMatches) == 0
+expandMatches([matchDESC], translations)
+elif matchDESC_BEGIN:
+assert len(descMatches) == 0
+descMatches = [matchDESC_BEGIN]
 else:
-print("Warning: unexpected line inside description dropped:\n", 
line,
-  file=sys.stderr)
-continue
-if reLibintl_h.search(line):
-  

[Mesa-dev] [PATCH 07/14] docs/meson: Add note about update translations

2018-10-26 Thread Dylan Baker
---
 docs/meson.html | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/docs/meson.html b/docs/meson.html
index ece64673107..51f661b6e0a 100644
--- a/docs/meson.html
+++ b/docs/meson.html
@@ -95,6 +95,13 @@ each configuration you want to build
 recommended in the documentation
 
 
+
+Autotools automatically updates translation files as part of the build process,
+meson does not do this. Instead if you want translated drirc files you will 
need 
+to invoke non-default targets for ninja to update them:
+ninja -C build/ xmlpool-pot xmlpool-update-po xmlpool-gmo
+
+
 
 Environment Variables
 Meson supports the standard CC and CXX environment variables for
-- 
2.19.1

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


[Mesa-dev] [PATCH 11/14] util/gen_xmlpool: use with statement to open file

2018-10-26 Thread Dylan Baker
Which ensures it is closed at the end of the scope.
---
 src/util/xmlpool/gen_xmlpool.py | 66 -
 1 file changed, 32 insertions(+), 34 deletions(-)

diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
index a39f9e9e2fa..6a5dcee0a87 100644
--- a/src/util/xmlpool/gen_xmlpool.py
+++ b/src/util/xmlpool/gen_xmlpool.py
@@ -189,42 +189,40 @@ def main():
 
 # Process the options template and generate options.h with all
 # translations.
-template = io.open(args.template, mode="rt", encoding='utf-8')
-descMatches = []
-for line in template:
-if len(descMatches) > 0:
-matchENUM = reENUM.match(line)
-matchDESC_END = reDESC_END.match(line)
-if matchENUM:
-descMatches.append(matchENUM)
-elif matchDESC_END:
-expandMatches(descMatches, translations, line)
-descMatches = []
+with io.open(args.template, mode="rt", encoding='utf-8') as template:
+descMatches = []
+for line in template:
+if len(descMatches) > 0:
+matchENUM = reENUM.match(line)
+matchDESC_END = reDESC_END.match(line)
+if matchENUM:
+descMatches.append(matchENUM)
+elif matchDESC_END:
+expandMatches(descMatches, translations, line)
+descMatches = []
+else:
+print("Warning: unexpected line inside description 
dropped:\n",
+  line, file=sys.stderr)
+continue
+if reLibintl_h.search(line):
+# Ignore (comment out) #include 
+print("/* %s * commented out by gen_xmlpool.py */" % line)
+continue
+matchDESC = reDESC.match(line)
+matchDESC_BEGIN = reDESC_BEGIN.match(line)
+if matchDESC:
+assert len(descMatches) == 0
+expandMatches([matchDESC], translations)
+elif matchDESC_BEGIN:
+assert len(descMatches) == 0
+descMatches = [matchDESC_BEGIN]
 else:
-print("Warning: unexpected line inside description 
dropped:\n", line,
-  file=sys.stderr)
-continue
-if reLibintl_h.search(line):
-# Ignore (comment out) #include 
-print("/* %s * commented out by gen_xmlpool.py */" % line)
-continue
-matchDESC = reDESC.match(line)
-matchDESC_BEGIN = reDESC_BEGIN.match(line)
-if matchDESC:
-assert len(descMatches) == 0
-expandMatches([matchDESC], translations)
-elif matchDESC_BEGIN:
-assert len(descMatches) == 0
-descMatches = [matchDESC_BEGIN]
-else:
-# In Python 2, stdout expects encoded byte strings, or else it will
-# encode them with the ascii 'codec'
-if sys.version_info.major == 2:
-   line = line.encode('utf-8')
-
-print(line, end='')
+# In Python 2, stdout expects encoded byte strings, or else it 
will
+# encode them with the ascii 'codec'
+if sys.version_info.major == 2:
+   line = line.encode('utf-8')
 
-template.close()
+print(line, end='')
 
 if len(descMatches) > 0:
 print("Warning: unterminated description at end of file.", 
file=sys.stderr)
-- 
2.19.1

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


[Mesa-dev] [PATCH 06/14] util/gen_xmlpool: Remove --meson option for gen_xmlpool

2018-10-26 Thread Dylan Baker
Autotools now uses the same layout as meson, and scons doesn't care, so
remove the separate paths.
---
 src/util/Android.mk |  2 +-
 src/util/xmlpool/Makefile.am|  2 +-
 src/util/xmlpool/gen_xmlpool.py | 10 +++---
 src/util/xmlpool/meson.build|  2 +-
 4 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/src/util/Android.mk b/src/util/Android.mk
index 6c4c90e951d..993a7f179f4 100644
--- a/src/util/Android.mk
+++ b/src/util/Android.mk
@@ -102,7 +102,7 @@ $(UTIL_GENERATED_SOURCES): $(intermediates)/%.c: 
$(LOCAL_PATH)/%.py
$(transform-generated-source)
 
 $(MESA_DRI_OPTIONS_H): PRIVATE_CUSTOM_TOOL = $(PRIVATE_PYTHON) $< 
$(PRIVATE_TEMPLATE_HEADER) \
-   $(PRIVATE_LOCALEDIR) $(MESA_DRI_OPTIONS_LANGS) --meson > $@
+   $(PRIVATE_LOCALEDIR) $(MESA_DRI_OPTIONS_LANGS) > $@
 $(MESA_DRI_OPTIONS_H): $(PRIVATE_SCRIPT) $(PRIVATE_TEMPLATE_HEADER) 
$(PRIVATE_MO_FILES)
$(transform-generated-source)
 
diff --git a/src/util/xmlpool/Makefile.am b/src/util/xmlpool/Makefile.am
index 2227f57369e..9d5977f86ce 100644
--- a/src/util/xmlpool/Makefile.am
+++ b/src/util/xmlpool/Makefile.am
@@ -75,7 +75,7 @@ clean-local:
 # Default target options.h
 LOCALEDIR := .
 options.h: t_options.h $(MOS)
-   $(AM_V_GEN) $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/gen_xmlpool.py --meson 
$(srcdir)/t_options.h $(LOCALEDIR) $(LANGS) > options.h
+   $(AM_V_GEN) $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/gen_xmlpool.py 
$(srcdir)/t_options.h $(LOCALEDIR) $(LANGS) > options.h
 
 # Update .mo files from the corresponding .po files.
 %.gmo: %.po
diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
index e83e689de47..0ad51eaa785 100644
--- a/src/util/xmlpool/gen_xmlpool.py
+++ b/src/util/xmlpool/gen_xmlpool.py
@@ -19,7 +19,6 @@ parser = argparse.ArgumentParser()
 parser.add_argument('template')
 parser.add_argument('localedir')
 parser.add_argument('languages', nargs='*')
-parser.add_argument('--meson', action='store_true')
 args = parser.parse_args()
 
 if sys.version_info < (3, 0):
@@ -167,12 +166,9 @@ def expandMatches (matches, translations, end=None):
 translations = [("en", gettext.NullTranslations())]
 for lang in args.languages:
 try:
-if args.meson:
-filename = os.path.join(args.localedir, '{}.gmo'.format(lang))
-with io.open(filename, 'rb') as f:
-trans = gettext.GNUTranslations(f)
-else:
-trans = gettext.translation ("options", args.localedir, [lang])
+filename = os.path.join(args.localedir, '{}.gmo'.format(lang))
+with io.open(filename, 'rb') as f:
+trans = gettext.GNUTranslations(f)
 except (IOError, OSError):
 sys.stderr.write ("Warning: language '%s' not found.\n" % lang)
 continue
diff --git a/src/util/xmlpool/meson.build b/src/util/xmlpool/meson.build
index 381905b432a..ae7c951a097 100644
--- a/src/util/xmlpool/meson.build
+++ b/src/util/xmlpool/meson.build
@@ -30,7 +30,7 @@ xmlpool_options_h = custom_target(
   input : ['gen_xmlpool.py', 't_options.h'],
   output : 'options.h',
   command : [
-prog_python, '@INPUT@', '--meson', meson.current_build_dir(), _langs,
+prog_python, '@INPUT@', meson.current_build_dir(), _langs,
   ],
   capture : true,
   depend_files : _langs_po_files,
-- 
2.19.1

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


[Mesa-dev] [PATCH 12/14] util/gen_xmlpool: Don't write via shell redirection

2018-10-26 Thread Dylan Baker
This is bad for a couple of reasons, but the worst is that it gets the
shell involved. When the shell gets involved we can start running into
problems with LANG, namely LANG=C. This is particularly obnoxious for
translation files, since there is a very high likelyhood of running into
unicode in them. If we write it in python through file.write we don't
have this problem as python just shovels bits into a file, and the shell
doesn't know, and thus doesn't care.
---
 src/util/Android.mk |  2 +-
 src/util/xmlpool/Makefile.am|  2 +-
 src/util/xmlpool/SConscript |  2 +-
 src/util/xmlpool/gen_xmlpool.py | 98 ++---
 src/util/xmlpool/meson.build|  3 +-
 5 files changed, 46 insertions(+), 61 deletions(-)

diff --git a/src/util/Android.mk b/src/util/Android.mk
index 993a7f179f4..d3e68a2a6fd 100644
--- a/src/util/Android.mk
+++ b/src/util/Android.mk
@@ -102,7 +102,7 @@ $(UTIL_GENERATED_SOURCES): $(intermediates)/%.c: 
$(LOCAL_PATH)/%.py
$(transform-generated-source)
 
 $(MESA_DRI_OPTIONS_H): PRIVATE_CUSTOM_TOOL = $(PRIVATE_PYTHON) $< 
$(PRIVATE_TEMPLATE_HEADER) \
-   $(PRIVATE_LOCALEDIR) $(MESA_DRI_OPTIONS_LANGS) > $@
+   $@ $(PRIVATE_LOCALEDIR) $(MESA_DRI_OPTIONS_LANGS)
 $(MESA_DRI_OPTIONS_H): $(PRIVATE_SCRIPT) $(PRIVATE_TEMPLATE_HEADER) 
$(PRIVATE_MO_FILES)
$(transform-generated-source)
 
diff --git a/src/util/xmlpool/Makefile.am b/src/util/xmlpool/Makefile.am
index 9d5977f86ce..d61fc8ddf3a 100644
--- a/src/util/xmlpool/Makefile.am
+++ b/src/util/xmlpool/Makefile.am
@@ -75,7 +75,7 @@ clean-local:
 # Default target options.h
 LOCALEDIR := .
 options.h: t_options.h $(MOS)
-   $(AM_V_GEN) $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/gen_xmlpool.py 
$(srcdir)/t_options.h $(LOCALEDIR) $(LANGS) > options.h
+   $(AM_V_GEN) $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/gen_xmlpool.py 
$(srcdir)/t_options.h options.h $(LOCALEDIR) $(LANGS)
 
 # Update .mo files from the corresponding .po files.
 %.gmo: %.po
diff --git a/src/util/xmlpool/SConscript b/src/util/xmlpool/SConscript
index fa42554d3a5..4778316fd2c 100644
--- a/src/util/xmlpool/SConscript
+++ b/src/util/xmlpool/SConscript
@@ -8,7 +8,7 @@ xmlpool_options, = env.CodeGenerate(
 target = 'options.h',
 script = 'gen_xmlpool.py',
 source = ['t_options.h'],
-command = python_cmd + ' $SCRIPT $SOURCE ' + LOCALEDIR + ' > $TARGET'
+command = python_cmd + ' $SCRIPT $SOURCE $TARGET ' + LOCALEDIR
 )
 
 Export('xmlpool_options')
diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
index 6a5dcee0a87..01e5cc60e3b 100644
--- a/src/util/xmlpool/gen_xmlpool.py
+++ b/src/util/xmlpool/gen_xmlpool.py
@@ -7,7 +7,7 @@
 # `{localedir}/{language}/LC_MESSAGES/options.mo`.
 #
 
-from __future__ import print_function
+from __future__ import print_function, unicode_literals
 import argparse
 import gettext
 import io
@@ -114,7 +114,7 @@ def expandCString(s):
 #
 # DESC, DESC_BEGIN format: \1 \2= \3 \4=gettext(" \5= \6=") \7
 # ENUM format: \1 \2=gettext(" \3= \4=") \5
-def expandMatches(matches, translations, end=None):
+def expandMatches(matches, translations, outfile, end=None):
 assert len(matches) > 0
 nTranslations = len(translations)
 i = 0
@@ -131,12 +131,7 @@ def expandMatches(matches, translations, end=None):
 matches[0].expand (r'\5'
 text = (matches[0].expand(r'\1' + lang + r'\3"' + text + r'"\7') + 
suffix)
 
-# In Python 2, stdout expects encoded byte strings, or else it will
-# encode them with the ascii 'codec'
-if sys.version_info.major == 2:
-text = text.encode('utf-8')
-
-print(text)
+outfile.write(text + '\n')
 
 # Expand any subsequent enum lines
 for match in matches[1:]:
@@ -144,16 +139,11 @@ def expandMatches(matches, translations, end=None):
 match.expand(r'\3'
 text = match.expand(r'\1"' + text + r'"\5')
 
-# In Python 2, stdout expects encoded byte strings, or else it will
-# encode them with the ascii 'codec'
-if sys.version_info.major == 2:
-text = text.encode('utf-8')
-
-print(text)
+outfile.write(text + '\n')
 
 # Expand description end
 if end:
-print(end, end='')
+outfile.write(end)
 
 # Regular expressions:
 reLibintl_h = re.compile(r'#\s*include\s*')
@@ -166,6 +156,7 @@ reDESC_END = re.compile(r'\s*DRI_CONF_DESC_END')
 def main():
 parser = argparse.ArgumentParser()
 parser.add_argument('template')
+parser.add_argument('outfile')
 parser.add_argument('localedir')
 parser.add_argument('languages', nargs='*')
 args = parser.parse_args()
@@ -183,50 +174,45 @@ def main():
 continue
 translations.append((lang, trans))
 
-
print("/***\n"
 \
-" ***THIS FILE I

[Mesa-dev] [PATCH 08/14] util/gen_xmlpool: Use more standard style

2018-10-26 Thread Dylan Baker
gen_xmlpool uses a style unlike the rest of mesa, spaces between
function/method calls and the parens, strange whitespace to force lining
up method calls, and some other whitespace stuff. Since I'm going to be
doing some work in the file, I'm going to start cleaning those up.
---
 src/util/xmlpool/gen_xmlpool.py | 58 -
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
index 0ad51eaa785..70e0f96df9e 100644
--- a/src/util/xmlpool/gen_xmlpool.py
+++ b/src/util/xmlpool/gen_xmlpool.py
@@ -27,7 +27,7 @@ else:
 gettext_method = 'gettext'
 
 # Escape special characters in C strings
-def escapeCString (s):
+def escapeCString(s):
 escapeSeqs = {'\a' : '\\a', '\b' : '\\b', '\f' : '\\f', '\n' : '\\n',
   '\r' : '\\r', '\t' : '\\t', '\v' : '\\v', '\\' : ''}
 # " -> '' is a hack. Quotes (") aren't possible in XML attributes.
@@ -40,7 +40,7 @@ def escapeCString (s):
 # on whether it's an open or close quote. This is needed because plain
 # double quotes are not possible in XML attributes.
 if s[i] == '"':
-if i == len(s)-1 or s[i+1].isspace():
+if i == len(s) - 1 or s[i + 1].isspace():
 # close quote
 q = u'\u201c'
 else:
@@ -55,7 +55,7 @@ def escapeCString (s):
 return r
 
 # Expand escape sequences in C strings (needed for gettext lookup)
-def expandCString (s):
+def expandCString(s):
 escapeSeqs = {'a' : '\a', 'b' : '\b', 'f' : '\f', 'n' : '\n',
   'r' : '\r', 't' : '\t', 'v' : '\v',
   '"' : '"', '\\' : '\\'}
@@ -120,7 +120,7 @@ def expandCString (s):
 #
 # DESC, DESC_BEGIN format: \1 \2= \3 \4=gettext(" \5= \6=") \7
 # ENUM format: \1 \2=gettext(" \3= \4=") \5
-def expandMatches (matches, translations, end=None):
+def expandMatches(matches, translations, end=None):
 assert len(matches) > 0
 nTranslations = len(translations)
 i = 0
@@ -131,11 +131,11 @@ def expandMatches (matches, translations, end=None):
 # are extended with a backslash.
 suffix = ''
 if len(matches) == 1 and i < len(translations) and \
-   not matches[0].expand (r'\7').endswith('\\'):
+   not matches[0].expand(r'\7').endswith('\\'):
 suffix = ' \\'
-text = escapeCString (getattr(trans, gettext_method) (expandCString (
+text = escapeCString(getattr(trans, gettext_method)(expandCString(
 matches[0].expand (r'\5'
-text = (matches[0].expand (r'\1' + lang + r'\3"' + text + r'"\7') + 
suffix)
+text = (matches[0].expand(r'\1' + lang + r'\3"' + text + r'"\7') + 
suffix)
 
 # In Python 2, stdout expects encoded byte strings, or else it will
 # encode them with the ascii 'codec'
@@ -146,9 +146,9 @@ def expandMatches (matches, translations, end=None):
 
 # Expand any subsequent enum lines
 for match in matches[1:]:
-text = escapeCString (getattr(trans, gettext_method) 
(expandCString (
-match.expand (r'\3'
-text = match.expand (r'\1"' + text + r'"\5')
+text = escapeCString(getattr(trans, gettext_method)(expandCString(
+match.expand(r'\3'
+text = match.expand(r'\1"' + text + r'"\5')
 
 # In Python 2, stdout expects encoded byte strings, or else it will
 # encode them with the ascii 'codec'
@@ -170,16 +170,16 @@ for lang in args.languages:
 with io.open(filename, 'rb') as f:
 trans = gettext.GNUTranslations(f)
 except (IOError, OSError):
-sys.stderr.write ("Warning: language '%s' not found.\n" % lang)
+sys.stderr.write("Warning: language '%s' not found.\n" % lang)
 continue
-translations.append ((lang, trans))
+translations.append((lang, trans))
 
 # Regular expressions:
-reLibintl_h  = re.compile (r'#\s*include\s*')
-reDESC   = re.compile 
(r'(\s*DRI_CONF_DESC\s*\(\s*)([a-z]+)(\s*,\s*)(gettext\s*\(\s*")(.*)("\s*\))(\s*\)[
 \t]*\\?)$')
-reDESC_BEGIN = re.compile 
(r'(\s*DRI_CONF_DESC_BEGIN\s*\(\s*)([a-z]+)(\s*,\s*)(gettext\s*\(\s*")(.*)("\s*\))(\s*\)[
 \t]*\\?)$')
-reENUM   = re.compile 
(r'(\s*DRI_CONF_ENUM\s*\([^,]+,\s*)(gettext\s*\(\s*")(.*)("\s*\))(\s*\)[ 
\t]*\\?)$')
-reDESC_END   = re.compile (r'\s*DRI_CONF_DESC_END')
+reLibintl_h = re.compile(r'#\s*include\s*')
+reDESC = 
re.compile(r'(\s*DRI_CONF_DESC\s*\(\s*)([a-z]+)(\s*,\s*)(gettext\s*\(\s*")(.*)("\s*\))(\s*\)[
 \t]*\\?)$')
+reDESC_BEGIN = 
re.compile(r'(\s*DRI_CONF_DESC_BEGIN\s*\(\s*)([a-z]+)(\s*,\s*)(gettext\s*\(\s*")(.*)("\s*\))(\s*\)[
 \t]*\\?)$')
+reENUM = 
re.compile(r'(\s*DRI_CONF_ENUM\s*\([^,]+,\s*)(gettext\s*\(\s*")(.*)("\s*\))(\s*\)[
 \t]*\\?)$')
+reDESC_END = re.compile(r'\s*DRI_CONF_DESC_END')
 
 # Print a header
 
print("/**

[Mesa-dev] [PATCH 00/14] translations updates

2018-10-26 Thread Dylan Baker
This series has two distinct changes in it, but that would require enough
rebasing to land on top of the other I didn't want to send the separately.

The first change is to add support to meson to generate driric translations.
This is the v2 of that, with changes requested by Emil addressed, namely
android, autotools, and meson all use the same layout and there are no special
paths in gen_xml for meson anymore.

The second change is to update gen_xmlpool.py to write files directly instead of
using shell redirection. This allows the script to work correctly even on
systems that have LANG=C or some other restriction of unicode characters in the
shell.

Dylan Baker (14):
  util/gen_xmlpool: use argparse for argument handling
  meson: add support for generating translation mo files
  util/gen_xmlpool: Add a --meson switch
  meson: use meson generated translation files
  autotools,android: Use meson layout (including .gmo)
  util/gen_xmlpool: Remove --meson option for gen_xmlpool
  docs/meson: Add note about update translations
  util/gen_xmlpool: Use more standard style
  util/gen_xmlpool: Use print function instad of sys.stderr.write
  util/gen_xmlpool: use a main function
  util/gen_xmlpool: use with statement to open file
  util/gen_xmlpool: Don't write via shell redirection
  util/gen_xmlpool: Don't use len to test for container emptiness
  util/gen_xmlpool: Make use of python's foreach loop

 docs/meson.html |   7 +
 src/util/Android.mk |   6 +-
 src/util/xmlpool/LINGUAS|   1 +
 src/util/xmlpool/Makefile.am|  16 ++-
 src/util/xmlpool/POTFILES   |   1 +
 src/util/xmlpool/SConscript |   2 +-
 src/util/xmlpool/gen_xmlpool.py | 243 +++-
 src/util/xmlpool/meson.build|   6 +-
 8 files changed, 141 insertions(+), 141 deletions(-)
 create mode 100644 src/util/xmlpool/LINGUAS
 create mode 100644 src/util/xmlpool/POTFILES

-- 
2.19.1

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


[Mesa-dev] [PATCH 13/14] util/gen_xmlpool: Don't use len to test for container emptiness

2018-10-26 Thread Dylan Baker
This is a very common python anti-pattern. Not using length allows us to
go through faster C paths, but has the same meaning.
---
 src/util/xmlpool/gen_xmlpool.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
index 01e5cc60e3b..dfac119a536 100644
--- a/src/util/xmlpool/gen_xmlpool.py
+++ b/src/util/xmlpool/gen_xmlpool.py
@@ -182,7 +182,7 @@ def main():
 with io.open(args.template, mode="rt", encoding='utf-8') as template:
 descMatches = []
 for line in template:
-if len(descMatches) > 0:
+if descMatches:
 matchENUM = reENUM.match(line)
 matchDESC_END = reDESC_END.match(line)
 if matchENUM:
@@ -201,16 +201,16 @@ def main():
 matchDESC = reDESC.match(line)
 matchDESC_BEGIN = reDESC_BEGIN.match(line)
 if matchDESC:
-assert len(descMatches) == 0
+assert not descMatches
 expandMatches([matchDESC], translations, output)
 elif matchDESC_BEGIN:
-assert len(descMatches) == 0
+assert not descMatches
 descMatches = [matchDESC_BEGIN]
 else:
 
 output.write(line)
 
-if len(descMatches) > 0:
+if descMatches:
 print("Warning: unterminated description at end of file.", 
file=sys.stderr)
 expandMatches(descMatches, translations, output)
 
-- 
2.19.1

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


[Mesa-dev] [PATCH 05/14] autotools, android: Use meson layout (including .gmo)

2018-10-26 Thread Dylan Baker
This will allow autotools, meson, and android to use the same layout and
options in the gen_xmlpool script. Scons doesn't care because windows
doesn't support translations.

v2: - Add this commit
---
 src/util/Android.mk  |  6 +++---
 src/util/xmlpool/Makefile.am | 12 +++-
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/util/Android.mk b/src/util/Android.mk
index e463b63e101..6c4c90e951d 100644
--- a/src/util/Android.mk
+++ b/src/util/Android.mk
@@ -87,13 +87,13 @@ $(MESA_DRI_OPTIONS_LANGS:%=$(intermediates)/xmlpool/%.po): 
$(intermediates)/xmlp
 PRIVATE_SCRIPT := $(LOCAL_PATH)/xmlpool/gen_xmlpool.py
 PRIVATE_LOCALEDIR := $(intermediates)/xmlpool
 PRIVATE_TEMPLATE_HEADER := $(LOCAL_PATH)/xmlpool/t_options.h
-PRIVATE_MO_FILES := 
$(MESA_DRI_OPTIONS_LANGS:%=$(intermediates)/xmlpool/%/LC_MESSAGES/options.mo)
+PRIVATE_MO_FILES := $(MESA_DRI_OPTIONS_LANGS:%=$(intermediates)/xmlpool/%.gmo)
 
 LOCAL_GENERATED_SOURCES += $(PRIVATE_MO_FILES)
 
 $(LOCAL_GENERATED_SOURCES): PRIVATE_PYTHON := $(MESA_PYTHON2)
 
-$(PRIVATE_MO_FILES): $(intermediates)/xmlpool/%/LC_MESSAGES/options.mo: 
$(intermediates)/xmlpool/%.po
+$(PRIVATE_MO_FILES): $(intermediates)/xmlpool/%.gmo: 
$(intermediates)/xmlpool/%.po
mkdir -p $(dir $@)
msgfmt -o $@ $<
 
@@ -102,7 +102,7 @@ $(UTIL_GENERATED_SOURCES): $(intermediates)/%.c: 
$(LOCAL_PATH)/%.py
$(transform-generated-source)
 
 $(MESA_DRI_OPTIONS_H): PRIVATE_CUSTOM_TOOL = $(PRIVATE_PYTHON) $< 
$(PRIVATE_TEMPLATE_HEADER) \
-   $(PRIVATE_LOCALEDIR) $(MESA_DRI_OPTIONS_LANGS) > $@
+   $(PRIVATE_LOCALEDIR) $(MESA_DRI_OPTIONS_LANGS) --meson > $@
 $(MESA_DRI_OPTIONS_H): $(PRIVATE_SCRIPT) $(PRIVATE_TEMPLATE_HEADER) 
$(PRIVATE_MO_FILES)
$(transform-generated-source)
 
diff --git a/src/util/xmlpool/Makefile.am b/src/util/xmlpool/Makefile.am
index 78a08fab4b1..2227f57369e 100644
--- a/src/util/xmlpool/Makefile.am
+++ b/src/util/xmlpool/Makefile.am
@@ -47,10 +47,10 @@ POS=ca.po de.po es.po nl.po fr.po sv.po
 # Don't change anything below, unless you know what you're doing.
 #
 LANGS=$(POS:%.po=%)
-MOS=$(POS:%.po=%/LC_MESSAGES/options.mo)
+MOS=$(POS:%.po=%.gmo)
 POT=xmlpool.pot
 
-.PHONY: all clean pot po mo
+.PHONY: all clean clean-local pot po mo
 
 EXTRA_DIST = \
gen_xmlpool.py \
@@ -69,17 +69,19 @@ CLEANFILES = \
$(POS) \
$(MOS)
 
+clean-local:
+   rm -f $(MOS)
+
 # Default target options.h
 LOCALEDIR := .
 options.h: t_options.h $(MOS)
-   $(AM_V_GEN) $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/gen_xmlpool.py 
$(srcdir)/t_options.h $(LOCALEDIR) $(LANGS) > options.h
+   $(AM_V_GEN) $(PYTHON2) $(PYTHON_FLAGS) $(srcdir)/gen_xmlpool.py --meson 
$(srcdir)/t_options.h $(LOCALEDIR) $(LANGS) > options.h
 
 # Update .mo files from the corresponding .po files.
-%/LC_MESSAGES/options.mo: %.po
+%.gmo: %.po
@mo="$@"; \
lang=$${mo%%/*}; \
echo "Updating ($$lang) $@ from $?."; \
-   $(MKDIR_P) $$lang/LC_MESSAGES; \
msgfmt -o $@ $?
 
 # Use this target to create or update .po files with new messages in
-- 
2.19.1

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


[Mesa-dev] [PATCH 03/14] util/gen_xmlpool: Add a --meson switch

2018-10-26 Thread Dylan Baker
Meson won't put the .gmo files in the layout that python's
gettext.translation() expects, so we need to handle them differently,
this switch allows the script to load the files as meson lays them out

v2: - Handle OSError as well as IOError, since that's what will happen
  in the meson case if the file doesn't exist
- remove leftover debug code
---
 src/util/xmlpool/gen_xmlpool.py | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
index b40f295738e..e83e689de47 100644
--- a/src/util/xmlpool/gen_xmlpool.py
+++ b/src/util/xmlpool/gen_xmlpool.py
@@ -8,17 +8,18 @@
 #
 
 from __future__ import print_function
-
 import argparse
-import io
-import sys
 import gettext
+import io
+import os
 import re
+import sys
 
 parser = argparse.ArgumentParser()
 parser.add_argument('template')
 parser.add_argument('localedir')
 parser.add_argument('languages', nargs='*')
+parser.add_argument('--meson', action='store_true')
 args = parser.parse_args()
 
 if sys.version_info < (3, 0):
@@ -166,8 +167,13 @@ def expandMatches (matches, translations, end=None):
 translations = [("en", gettext.NullTranslations())]
 for lang in args.languages:
 try:
-trans = gettext.translation ("options", args.localedir, [lang])
-except IOError:
+if args.meson:
+filename = os.path.join(args.localedir, '{}.gmo'.format(lang))
+with io.open(filename, 'rb') as f:
+trans = gettext.GNUTranslations(f)
+else:
+trans = gettext.translation ("options", args.localedir, [lang])
+except (IOError, OSError):
 sys.stderr.write ("Warning: language '%s' not found.\n" % lang)
 continue
 translations.append ((lang, trans))
-- 
2.19.1

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


[Mesa-dev] [PATCH 04/14] meson: use meson generated translation files

2018-10-26 Thread Dylan Baker
This is a change from the current status-quo, namely to get dri-conf
translations you now *must* run the meson generation scripts, even if
you're building from an autotools generated tarball (an official
release).

v2: - use .gmo files in build dir, not source dir.
---
 src/util/xmlpool/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/xmlpool/meson.build b/src/util/xmlpool/meson.build
index 8d645ce385f..381905b432a 100644
--- a/src/util/xmlpool/meson.build
+++ b/src/util/xmlpool/meson.build
@@ -30,7 +30,7 @@ xmlpool_options_h = custom_target(
   input : ['gen_xmlpool.py', 't_options.h'],
   output : 'options.h',
   command : [
-prog_python, '@INPUT@', meson.current_source_dir(), _langs,
+prog_python, '@INPUT@', '--meson', meson.current_build_dir(), _langs,
   ],
   capture : true,
   depend_files : _langs_po_files,
-- 
2.19.1

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


[Mesa-dev] [PATCH 14/14] util/gen_xmlpool: Make use of python's foreach loop

2018-10-26 Thread Dylan Baker
Instead of using a while loop with indexing. This is much cleaner. This
requires some other small changes.
---
 src/util/xmlpool/gen_xmlpool.py | 57 -
 1 file changed, 27 insertions(+), 30 deletions(-)

diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
index dfac119a536..7bf13489c2f 100644
--- a/src/util/xmlpool/gen_xmlpool.py
+++ b/src/util/xmlpool/gen_xmlpool.py
@@ -1,4 +1,4 @@
-
+# encoding=utf-8
 #
 # Usage:
 # gen_xmlpool.py /path/to/t_option.h localedir lang lang lang ...
@@ -27,25 +27,24 @@ def escapeCString(s):
 # " -> '' is a hack. Quotes (") aren't possible in XML attributes.
 # Better use Unicode characters for typographic quotes in option
 # descriptions and translations.
+last_quote = '”'
 i = 0
 r = ''
-while i < len(s):
-# Special case: escape double quote with \u201c or \u201d, depending
+for c in s:
+# Special case: escape double quote with “ or ”, depending
 # on whether it's an open or close quote. This is needed because plain
 # double quotes are not possible in XML attributes.
-if s[i] == '"':
-if i == len(s) - 1 or s[i + 1].isspace():
-# close quote
-q = u'\u201c'
+if c == '"':
+if last_quote == '”':
+q = '“'
 else:
-# open quote
-q = u'\u201d'
+q = '”'
+last_quote = q
 r = r + q
-elif s[i] in escapeSeqs:
-r = r + escapeSeqs[s[i]]
+elif c in escapeSeqs:
+r = r + escapeSeqs[c]
 else:
-r = r + s[i]
-i = i + 1
+r = r + c
 return r
 
 # Expand escape sequences in C strings (needed for gettext lookup)
@@ -53,24 +52,23 @@ def expandCString(s):
 escapeSeqs = {'a' : '\a', 'b' : '\b', 'f' : '\f', 'n' : '\n',
   'r' : '\r', 't' : '\t', 'v' : '\v',
   '"' : '"', '\\' : '\\'}
-i = 0
 escape = False
 hexa = False
 octa = False
 num = 0
 digits = 0
 r = u''
-while i < len(s):
+for c in s:
 if not escape:
-if s[i] == '\\':
+if c == '\\':
 escape = True
 else:
-r = r + s[i]
+r = r + c
 elif hexa:
-if (s[i] >= '0' and s[i] <= '9') or \
-   (s[i] >= 'a' and s[i] <= 'f') or \
-   (s[i] >= 'A' and s[i] <= 'F'):
-num = num * 16 + int(s[i],16)
+if (c >= '0' and c <= '9') or \
+   (c >= 'a' and c <= 'f') or \
+   (c >= 'A' and c <= 'F'):
+num = num * 16 + int(c, 16)
 digits = digits + 1
 else:
 digits = 2
@@ -79,8 +77,8 @@ def expandCString(s):
 escape = False
 r = r + chr(num)
 elif octa:
-if s[i] >= '0' and s[i] <= '7':
-num = num * 8 + int(s[i],8)
+if c >= '0' and c <= '7':
+num = num * 8 + int(c, 8)
 digits = digits + 1
 else:
 digits = 3
@@ -89,24 +87,23 @@ def expandCString(s):
 escape = False
 r = r + chr(num)
 else:
-if s[i] in escapeSeqs:
-r = r + escapeSeqs[s[i]]
+if c in escapeSeqs:
+r = r + escapeSeqs[c]
 escape = False
-elif s[i] >= '0' and s[i] <= '7':
+elif c >= '0' and c <= '7':
 octa = True
-num = int(s[i],8)
+num = int(c, 8)
 if num <= 3:
 digits = 1
 else:
 digits = 2
-elif s[i] == 'x' or s[i] == 'X':
+elif c == 'x' or c == 'X':
 hexa = True
 num = 0
 digits = 0
 else:
-r = r + s[i]
+r = r + c
 escape = False
-i = i + 1
 return r
 
 # Expand matches. The first match is always a DESC or DESC_BEGIN match.
-- 
2.19.1

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


Re: [Mesa-dev] [PATCH] intel/blorp: Define the clear value bounds for HiZ clears

2018-10-26 Thread Jason Ekstrand
On Thu, Oct 25, 2018 at 6:25 PM  wrote:

> From: Nanley Chery 
>
> Follow the restriction of making sure the clear value is between the min
> and max values defined in CC_VIEWPORT. Avoids a simulator warning for
> some piglit tests, one of them being:
>
> ./bin/depthstencil-render-miplevels 146 d=z32f_s8
>
> Jason found this to make a GPU hang go away on SKL.
>

It wasn't really hangs.  It was just incorrect clearing.  The hangs may be
related but I have no proof of that.  With the commit message adjusted
accordingly, this patch is

Reviewed-by: Jason Ekstrand 
Tested-by: Jason Ekstrand 


> Fixes: 09948151ab1d5184b4dd9052bb1f710fa1e00a7b
>("intel/blorp: Add the BDW+ optimized HZ_OP sequence to BLORP")
> ---
>  src/intel/blorp/blorp_genX_exec.h | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/src/intel/blorp/blorp_genX_exec.h
> b/src/intel/blorp/blorp_genX_exec.h
> index 50341ab0ecf..7a8c45dbee5 100644
> --- a/src/intel/blorp/blorp_genX_exec.h
> +++ b/src/intel/blorp/blorp_genX_exec.h
> @@ -1628,6 +1628,20 @@ blorp_emit_gen8_hiz_op(struct blorp_batch *batch,
>  */
> blorp_emit_3dstate_multisample(batch, params);
>
> +   /* From the BDW PRM Volume 7, Depth Buffer Clear:
> +*
> +*The clear value must be between the min and max depth values
> +*(inclusive) defined in the CC_VIEWPORT. If the depth buffer
> format is
> +*D32_FLOAT, then +/-DENORM values are also allowed.
> +*
> +* Set the bounds to match our hardware limits, [0.0, 1.0].
> +*/
> +   if (params->depth.enabled && params->hiz_op == ISL_AUX_OP_FAST_CLEAR) {
> +  assert(params->depth.clear_color.f32[0] >= 0.0f);
> +  assert(params->depth.clear_color.f32[0] <= 1.0f);
> +  blorp_emit_cc_viewport(batch);
> +   }
> +
> /* If we can't alter the depth stencil config and multiple layers are
>  * involved, the HiZ op will fail. This is because the op requires
> that a
>  * new config is emitted for each additional layer.
> --
> 2.19.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] intel/compiler: Print message descriptor as immediate source

2018-10-26 Thread Sagar Ghuge
Hi,

Thank you for sharing the following patch series. 

On 10/26/18 6:15 AM, Eero Tamminen wrote:
> Hi,
> 
> Toni had a working assembler in early 2017, but he had to stop working
> on it because nobody reviewed the patches needed for the disassembler.
> 
> Maybe his patch series for the disassembly output still has something
> useful for your assembler:
> 
Yes, it is. 

> * i965 shader disassembly label support:
> https://patchwork.freedesktop.org/series/19946/
> * i965 shader disassembly formatting changes:
> https://patchwork.freedesktop.org/series/19945/
> * Always print message descriptor and SFID for SEND instructions:
> https://patchwork.freedesktop.org/patch/223750/
> 
> ?
> 
> - Eero
> 
> On 10/25/18 2:25 AM, Sagar Ghuge wrote:
>> While disassembling send(c) instruction print message descriptor as
>> immediate source operand along with message descriptor. This allows
>> assembler to read immediate source operand and set bits accordingly.
>>
>> Signed-off-by: Sagar Ghuge 
>> ---
>>   src/intel/compiler/brw_disasm.c | 9 +++--
>>   1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/intel/compiler/brw_disasm.c 
>> b/src/intel/compiler/brw_disasm.c
>> index 6a7e988641..9c6df9e645 100644
>> --- a/src/intel/compiler/brw_disasm.c
>> +++ b/src/intel/compiler/brw_disasm.c
>> @@ -1606,7 +1606,12 @@ brw_disassemble_inst(FILE *file, const struct 
>> gen_device_info *devinfo,
>>    /* show the indirect descriptor source */
>>    pad(file, 48);
>>    err |= src1(file, devinfo, inst);
>> -  }
>> + pad(file, 64);
>> +  } else
>> + pad(file, 48);
>> +
>> +  /* Print message descriptor as immediate source */
>> +  fprintf(file, "0x%08"PRIx64, inst->data[1] >> 32);
>>       newline(file);
>>     pad(file, 16);
>> @@ -1615,7 +1620,7 @@ brw_disassemble_inst(FILE *file, const struct 
>> gen_device_info *devinfo,
>>     fprintf(file, "    ");
>>     err |= control(file, "SFID", devinfo->gen >= 6 ? gen6_sfid : 
>> gen4_sfid,
>>    sfid, &space);
>> -
>> +  string(file, " MsgDesc:");
>>       if (brw_inst_src1_reg_file(devinfo, inst) != BRW_IMMEDIATE_VALUE) {
>>    format(file, " indirect");
>>
> 
> ___
> 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] scons/svga: remove opt from the list of valid build types

2018-10-26 Thread Brian Paul
This reverts commit a5fd54f8bf6713312fa5efd7ef5cd125557a0ffe.

The whole point was to add a way to pass -DVMX86_STATS to the build,
but we can do that with a command line argument when we invoke scons.
---
 common.py  | 2 +-
 scons/gallium.py   | 8 +++-
 src/gallium/drivers/svga/svga_screen.c | 2 --
 3 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/common.py b/common.py
index be3ccfc..e2afff9 100644
--- a/common.py
+++ b/common.py
@@ -86,7 +86,7 @@ def AddOptions(opts):
 from SCons.Options.EnumOption import EnumOption
 opts.Add(EnumOption('build', 'build type', 'debug',
 allowed_values=('debug', 'checked', 'profile',
-'release', 'opt')))
+'release')))
 opts.Add(BoolOption('verbose', 'verbose output', 'no'))
 opts.Add(EnumOption('machine', 'use machine-specific assembly code',
 default_machine,
diff --git a/scons/gallium.py b/scons/gallium.py
index aa7201a..963834a 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -279,7 +279,7 @@ def generate(env):
 if env['build'] == 'profile':
 env['debug'] = False
 env['profile'] = True
-if env['build'] in ('release', 'opt'):
+if env['build'] == 'release':
 env['debug'] = False
 env['profile'] = False
 
@@ -325,8 +325,6 @@ def generate(env):
 cppdefines += ['NDEBUG']
 if env['build'] == 'profile':
 cppdefines += ['PROFILE']
-if env['build'] in ('opt', 'profile'):
-cppdefines += ['VMX86_STATS']
 if env['platform'] in ('posix', 'linux', 'freebsd', 'darwin'):
 cppdefines += [
 '_POSIX_SOURCE',
@@ -477,7 +475,7 @@ def generate(env):
 ccflags += [
 '/O2', # optimize for speed
 ]
-if env['build'] in ('release', 'opt'):
+if env['build'] == 'release':
 if not env['clang']:
 ccflags += [
 '/GL', # enable whole program optimization
@@ -588,7 +586,7 @@ def generate(env):
 shlinkflags += ['-Wl,--enable-stdcall-fixup']
 #shlinkflags += ['-Wl,--kill-at']
 if msvc:
-if env['build'] in ('release', 'opt') and not env['clang']:
+if env['build'] == 'release' and not env['clang']:
 # enable Link-time Code Generation
 linkflags += ['/LTCG']
 env.Append(ARFLAGS = ['/LTCG'])
diff --git a/src/gallium/drivers/svga/svga_screen.c 
b/src/gallium/drivers/svga/svga_screen.c
index ab9a3c7..95dde8b 100644
--- a/src/gallium/drivers/svga/svga_screen.c
+++ b/src/gallium/drivers/svga/svga_screen.c
@@ -92,8 +92,6 @@ svga_get_name( struct pipe_screen *pscreen )
 */
build = "build: DEBUG;";
mutex = "mutex: " PIPE_ATOMIC ";";
-#elif defined(VMX86_STATS)
-   build = "build: OPT;";
 #else
build = "build: RELEASE;";
 #endif
-- 
2.7.4

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


[Mesa-dev] [AppVeyor] mesa master #9156 failed

2018-10-26 Thread AppVeyor



Build mesa 9156 failed


Commit 5cdeefe057 by Jason Ekstrand on 10/19/2018 5:06 PM:

intel/nir: Use the OPT macro for more passes\n\nReviewed-by: Ian Romanick 


Configure your notification preferences

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


[Mesa-dev] [PATCH 1/2] anv/util: Split a vk_errorv helper out of vk_errorf

2018-10-26 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_private.h |  8 
 src/intel/vulkan/anv_util.c| 23 +--
 2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index a3ab971b6fd..c5d636fef8d 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -381,6 +381,11 @@ vk_to_isl_color(VkClearColorValue color)
  * propagating errors. Might be useful to plug in a stack trace here.
  */
 
+VkResult __vk_errorv(struct anv_instance *instance, const void *object,
+ VkDebugReportObjectTypeEXT type, VkResult error,
+ const char *file, int line, const char *format,
+ va_list args);
+
 VkResult __vk_errorf(struct anv_instance *instance, const void *object,
  VkDebugReportObjectTypeEXT type, VkResult error,
  const char *file, int line, const char *format, ...);
@@ -389,6 +394,9 @@ VkResult __vk_errorf(struct anv_instance *instance, const 
void *object,
 #define vk_error(error) __vk_errorf(NULL, NULL,\
 VK_DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT,\
 error, __FILE__, __LINE__, NULL)
+#define vk_errorv(instance, obj, error, format, args)\
+__vk_errorv(instance, obj, REPORT_OBJECT_TYPE(obj), error,\
+__FILE__, __LINE__, format, args)
 #define vk_errorf(instance, obj, error, format, ...)\
 __vk_errorf(instance, obj, REPORT_OBJECT_TYPE(obj), error,\
 __FILE__, __LINE__, format, ## __VA_ARGS__)
diff --git a/src/intel/vulkan/anv_util.c b/src/intel/vulkan/anv_util.c
index 8ccb61b35c1..1159ccecc6a 100644
--- a/src/intel/vulkan/anv_util.c
+++ b/src/intel/vulkan/anv_util.c
@@ -77,20 +77,17 @@ __anv_perf_warn(struct anv_instance *instance, const void 
*object,
 }
 
 VkResult
-__vk_errorf(struct anv_instance *instance, const void *object,
- VkDebugReportObjectTypeEXT type, VkResult error,
- const char *file, int line, const char *format, ...)
+__vk_errorv(struct anv_instance *instance, const void *object,
+VkDebugReportObjectTypeEXT type, VkResult error,
+const char *file, int line, const char *format, va_list ap)
 {
-   va_list ap;
char buffer[256];
char report[512];
 
const char *error_str = vk_Result_to_str(error);
 
if (format) {
-  va_start(ap, format);
   vsnprintf(buffer, sizeof(buffer), format, ap);
-  va_end(ap);
 
   snprintf(report, sizeof(report), "%s:%d: %s (%s)", file, line, buffer,
error_str);
@@ -113,3 +110,17 @@ __vk_errorf(struct anv_instance *instance, const void 
*object,
 
return error;
 }
+
+VkResult
+__vk_errorf(struct anv_instance *instance, const void *object,
+VkDebugReportObjectTypeEXT type, VkResult error,
+const char *file, int line, const char *format, ...)
+{
+   va_list ap;
+
+   va_start(ap, format);
+   __vk_errorv(instance, object, type, error, file, line, format, ap);
+   va_end(ap);
+
+   return error;
+}
-- 
2.19.1

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


[Mesa-dev] [PATCH 2/2] anv: Return VK_ERROR_DEVICE_LOST from anv_device_set_lost

2018-10-26 Thread Jason Ekstrand
This lets us get rid of a bunch of duplicated error messages.
---
 src/intel/vulkan/anv_device.c  | 50 +++---
 src/intel/vulkan/anv_private.h |  7 +++--
 src/intel/vulkan/anv_queue.c   | 16 +++
 src/intel/vulkan/genX_query.c  |  4 +--
 4 files changed, 32 insertions(+), 45 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 70fc51ff306..ee35e013329 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -2048,21 +2048,26 @@ void anv_GetDeviceQueue2(
   *pQueue = NULL;
 }
 
-void
-anv_device_set_lost(struct anv_device *device, const char *msg, ...)
+VkResult
+_anv_device_set_lost(struct anv_device *device,
+ const char *file, int line,
+ const char *msg, ...)
 {
-   device->_lost = true;
+   VkResult err;
+   va_list ap;
 
-   if (env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false)) {
-  intel_loge("Device lost!");
+   device->_lost = true;
 
-  va_list ap;
-  va_start(ap, msg);
-  intel_loge_v(msg, ap);
-  va_end(ap);
+   va_start(ap, msg);
+   err = __vk_errorv(device->instance, device,
+ VK_DEBUG_REPORT_OBJECT_TYPE_DEVICE_EXT,
+ VK_ERROR_DEVICE_LOST, file, line, msg, ap);
+   va_end(ap);
 
+   if (env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false))
   abort();
-   }
+
+   return err;
 }
 
 VkResult
@@ -2079,19 +2084,13 @@ anv_device_query_status(struct anv_device *device)
int ret = anv_gem_gpu_get_reset_stats(device, &active, &pending);
if (ret == -1) {
   /* We don't know the real error. */
-  anv_device_set_lost(device, "get_reset_stats failed: %m");
-  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
-   "get_reset_stats failed: %m");
+  return anv_device_set_lost(device, "get_reset_stats failed: %m");
}
 
if (active) {
-  anv_device_set_lost(device, "GPU hung on one of our command buffers");
-  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
-   "GPU hung on one of our command buffers");
+  return anv_device_set_lost(device, "GPU hung on one of our command 
buffers");
} else if (pending) {
-  anv_device_set_lost(device, "GPU hung with commands in-flight");
-  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
-   "GPU hung with commands in-flight");
+  return anv_device_set_lost(device, "GPU hung with commands in-flight");
}
 
return VK_SUCCESS;
@@ -2109,9 +2108,7 @@ anv_device_bo_busy(struct anv_device *device, struct 
anv_bo *bo)
   return VK_NOT_READY;
} else if (ret == -1) {
   /* We don't know the real error. */
-  anv_device_set_lost(device, "gem wait failed: %m");
-  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
-   "gem wait failed: %m");
+  return anv_device_set_lost(device, "gem wait failed: %m");
}
 
/* Query for device status after the busy call.  If the BO we're checking
@@ -2132,9 +2129,7 @@ anv_device_wait(struct anv_device *device, struct anv_bo 
*bo,
   return VK_TIMEOUT;
} else if (ret == -1) {
   /* We don't know the real error. */
-  anv_device_set_lost(device, "gem wait failed: %m");
-  return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
-   "gem wait failed: %m");
+  return anv_device_set_lost(device, "gem wait failed: %m");
}
 
/* Query for device status after the wait.  If the BO we're waiting on got
@@ -3111,9 +3106,8 @@ VkResult anv_GetCalibratedTimestampsEXT(
 &pTimestamps[d]);
 
  if (ret != 0) {
-anv_device_set_lost(device, "Failed to get a timestamp");
-return vk_errorf(device->instance, device, VK_ERROR_DEVICE_LOST,
- "Failed to read the TIMESTAMP register: %m");
+return anv_device_set_lost(device, "Failed to read the TIMESTAMP "
+   "register: %m");
  }
  uint64_t device_period = DIV_ROUND_UP(10, 
timestamp_frequency);
  max_clock_period = MAX2(max_clock_period, device_period);
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index c5d636fef8d..25e290ed112 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1083,8 +1083,11 @@ anv_state_flush(struct anv_device *device, struct 
anv_state state)
 void anv_device_init_blorp(struct anv_device *device);
 void anv_device_finish_blorp(struct anv_device *device);
 
-void anv_device_set_lost(struct anv_device *device,
- const char *msg, ...);
+VkResult _anv_device_set_lost(struct anv_device *device,
+  const char *file, int line,
+  const char *msg, ...);
+#define anv_device_set_lost(dev, ...) \

Re: [Mesa-dev] [PATCH 2/2] kmsro: Extend to include hx8357d.

2018-10-26 Thread Eric Anholt
Eric Engestrom  writes:

> On Thursday, 2018-10-25 09:39:10 -0700, Eric Anholt wrote:
>> This allows vc4 to initialize on the Adafruit PiTFT 3.5" touchscreen with
>> the new tinydrm driver I just submitted.  If this series extending the
>> pl111/kmsro driver is accepted, then I'll extend kmsro with the other
>> tinydrm drivers as well.
>> ---
>>  src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 5 +
>>  src/gallium/drivers/kmsro/Android.mk| 1 +
>>  src/gallium/drivers/kmsro/Automake.inc  | 1 +
>>  src/gallium/targets/dri/meson.build | 1 +
>>  src/gallium/targets/dri/target.c| 1 +
>>  5 files changed, 9 insertions(+)
>> 
>> diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
>> b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
>> index 230bafe5e159..73ddab0cbf02 100644
>> --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
>> +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
>> @@ -111,6 +111,11 @@ static const struct drm_driver_descriptor 
>> driver_descriptors[] = {
>>  .create_screen = pipe_kmsro_create_screen,
>>  .configuration = pipe_default_configuration_query,
>>  },
>> +{
>> +   .driver_name = "hx8357d",
>> +.create_screen = pipe_kmsro_create_screen,
>> +.configuration = pipe_default_configuration_query,
>> +},
>
> Is that really all it takes to add a new userspace tinydrm driver? Impressive!
>
> (nit: `.driver_name` missing one space of indentation)
>
> Code-wise, patch #1 is:
> Reviewed-by: Eric Engestrom 
>
> Not completely sure this is all that's needed for this patch, so only:
> Acked-by: Eric Engestrom 
>
> That said, ... (scroll down)
>
>>  {
>>  .driver_name = "virtio_gpu",
>>  .create_screen = pipe_virgl_create_screen,
>> diff --git a/src/gallium/drivers/kmsro/Android.mk 
>> b/src/gallium/drivers/kmsro/Android.mk
>> index 8a851024dc88..f6a444e8865b 100644
>> --- a/src/gallium/drivers/kmsro/Android.mk
>> +++ b/src/gallium/drivers/kmsro/Android.mk
>> @@ -35,5 +35,6 @@ include $(BUILD_STATIC_LIBRARY)
>>  
>>  ifneq ($(HAVE_GALLIUM_KMSRO),)
>>  GALLIUM_TARGET_DRIVERS += pl111
>> +GALLIUM_TARGET_DRIVERS += hx8357d
>>  $(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_kmsro)
>>  endif
>> diff --git a/src/gallium/drivers/kmsro/Automake.inc 
>> b/src/gallium/drivers/kmsro/Automake.inc
>> index 66d125cb440a..d5961c907653 100644
>> --- a/src/gallium/drivers/kmsro/Automake.inc
>> +++ b/src/gallium/drivers/kmsro/Automake.inc
>> @@ -1,6 +1,7 @@
>>  if HAVE_GALLIUM_KMSRO
>>  
>>  TARGET_DRIVERS += pl111
>> +TARGET_DRIVERS += hx8357d
>>  TARGET_CPPFLAGS += -DGALLIUM_KMSRO
>>  TARGET_LIB_DEPS += \
>>  $(top_builddir)/src/gallium/winsys/kmsro/drm/libkmsrodrm.la \
>> diff --git a/src/gallium/targets/dri/meson.build 
>> b/src/gallium/targets/dri/meson.build
>> index c1cb616b4dad..bc63702498ba 100644
>> --- a/src/gallium/targets/dri/meson.build
>> +++ b/src/gallium/targets/dri/meson.build
>> @@ -63,6 +63,7 @@ libgallium_dri = shared_library(
>>  )
>>  
>>  foreach d : [[with_gallium_kmsro, 'pl111_dri.so'],
>> + [with_gallium_kmsro, 'hx8357d_dri.so'],
>
> ... wouldn't we want the user-facing `gallium` option to have the
> `pl111,hx8357d` granularity?
>
> It would be more work, so as a follow-up patch, and they're just
> hardlinks of the same file anyway so they don't really take any disk
> space or compilation time, so I'm not sure it's worth it, but asking the
> question anyway :)

My thought was that since each of the tinydrm gallium drivers is the
same code and just one more loader entrypoint and drm_driver_descriptor
struct, everyone's better off if we don't list a million names in the
meson/autotools options and you just get them all as a group.

What I actually think I want is the loader to know that if you didn't
find a native driver and you've got a KMS node, it should try seeing if
kmsro_dri.so likes your KMS node.  However, that would require Xorg to
also know about this idea (when can we switch AIGLX over to EGL?).


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


Re: [Mesa-dev] [PATCH v1 1/5] meson: compilation flags for sse

2018-10-26 Thread Eric Anholt
Dylan Baker  writes:

> [ Unknown signature status ]
> CC'ing Matt and Emil.
>
> This will make the code non-portable from an SSE capable system to a non-sse
> capable system. That's a pretty old system at this point (Pentium III and 
> Athlon
> XP), and I don't personaly care, but it's quite possible that distros do care.
>
> What do you guys think?

Yeah, we can't do that.


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


[Mesa-dev] [Bug 108565] Rise of the Tomb Raider SIGSEGV in LLVM 7.0.0

2018-10-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108565

Jan Ziak <0xe2.0x9a.0...@gmail.com> changed:

   What|Removed |Added

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

--- Comment #3 from Jan Ziak <0xe2.0x9a.0...@gmail.com> ---
(In reply to Alex Smith from comment #2)
> Possibly fixed by
> https://gitlab.freedesktop.org/mesa/mesa/commit/
> ca83d51cfb154af12ee6e17a533df6cbbc890e22 which didn't make 18.2.3. Could you
> try that? I saw some similar backtraces while debugging that, due to the bug
> causing memory corruption.

I launched the game two times and didn't get a crash. Thanks.

-- 
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] [Mesa-stable] [PATCH mesa 1/4] meson: turn git_sha1.h target into a proper dependency

2018-10-26 Thread Dylan Baker
Quoting Eric Engestrom (2018-10-25 09:44:14)
> On Tuesday, 2018-10-02 13:44:07 -0700, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-10-02 07:09:03)
> > > Cc: mesa-sta...@lists.freedesktop.org
> > > Signed-off-by: Eric Engestrom 
> > > ---
> > >  src/mesa/meson.build |  3 +--
> > >  src/meson.build  | 13 -
> > >  2 files changed, 9 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/src/mesa/meson.build b/src/mesa/meson.build
> > > index ea884977db8052d86fcb..861b0311048eff422b9f 100644
> > > --- a/src/mesa/meson.build
> > > +++ b/src/mesa/meson.build
> > > @@ -705,7 +705,6 @@ files_libmesa_common += [
> > >ir_expression_operation_h,
> > >main_remap_helper_h,
> > >matypes_h,
> > > -  sha1_h,
> > >  ]
> > >  
> > >  if with_sse41
> > > @@ -726,7 +725,7 @@ libmesa_classic = static_library(
> > >cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
> > >include_directories : [inc_common, inc_libmesa_asm, 
> > > include_directories('main')],
> > >link_with : [libglsl, libmesa_sse41],
> > > -  dependencies : idep_nir_headers,
> > > +  dependencies : [idep_nir_headers, idep_git_sha1],
> > >build_by_default : false,
> > >  )
> > >  
> > > diff --git a/src/meson.build b/src/meson.build
> > > index af881cff70bf752a6474..89ffaddf47b7286e4fe0 100644
> > > --- a/src/meson.build
> > > +++ b/src/meson.build
> > > @@ -39,11 +39,14 @@ libglsl_util = static_library(
> > >build_by_default : false,
> > >  )
> > >  
> > > -sha1_h = custom_target(
> > > -  'git_sha1.h',
> > > -  output : 'git_sha1.h',
> > > -  command : [prog_python, git_sha1_gen_py, '--output', '@OUTPUT@'],
> > > -  build_always : true, # commit sha1 can change without having touched 
> > > these files
> > > +idep_git_sha1 = declare_dependency(
> > > +  sources : custom_target(
> > > +'git_sha1.h',
> > > +output : 'git_sha1.h',
> > > +command : [prog_python, git_sha1_gen_py, '--output', '@OUTPUT@'],
> > > +build_always : true, # commit sha1 can change without having touched 
> > > these files
> > > +  ),
> > > +  include_directories : inc_src,
> > 
> > What does this get us over including it in the source list, since it's a .h
> > meson should generate the proper include paths already, right?
> 
> Are you sure it does? I'll respin if that's really guaranteed and not
> just a coincidence :)

It does add git_sha1.h to the dependency list, but there is no guarantee that it
will in the documentation, I'll go update that. I'm not sure wrapping it in a
dependency changes that however, since all `sources` does is append a list
sources in the target, so it doesn't really change anything.

Dylan


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


Re: [Mesa-dev] [PATCH v1 1/5] meson: compilation flags for sse

2018-10-26 Thread Dylan Baker
CC'ing Matt and Emil.

This will make the code non-portable from an SSE capable system to a non-sse
capable system. That's a pretty old system at this point (Pentium III and Athlon
XP), and I don't personaly care, but it's quite possible that distros do care.

What do you guys think?

Dylan

Quoting Sergii Romantsov (2018-10-26 03:05:24)
> While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
> So it has to be done manually by flag '-msee'.
> Added support of such specification to build-system.
> 
> CC: Dylan Baker 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
> Signed-off-by: Sergii Romantsov 
> ---
>  meson.build | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/meson.build b/meson.build
> index 505cc6c..f335434 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -806,6 +806,12 @@ if cc.has_argument('-fvisibility=hidden')
>c_vis_args += '-fvisibility=hidden'
>  endif
>  
> +c_sse_args = []
> +# x86_64 enables -msse by default, on x86 it required to be enabled manually
> +if host_machine.cpu_family() == 'x86' and cc.has_argument('-msse')
> +  c_sse_args += ['-msse', '-mstackrealign']
> +endif
> +
>  # Check for generic C++ arguments
>  cpp_args = []
>  foreach a : ['-Wall', '-fno-math-errno', '-fno-trapping-math',
> @@ -836,6 +842,12 @@ if cpp.has_argument('-fvisibility=hidden')
>cpp_vis_args += '-fvisibility=hidden'
>  endif
>  
> +cpp_sse_args = []
> +# x86_64 enables -msse by default, on x86 it required to be enabled manually
> +if host_machine.cpu_family() == 'x86' and cpp.has_argument('-msse')
> +  cpp_sse_args += ['-msse', '-mstackrealign']
> +endif
> +
>  # Check for C and C++ arguments for MSVC2013 compatibility. These are only 
> used
>  # in parts of the mesa code base that need to compile with old versions of
>  # MSVC, mainly common code
> -- 
> 2.7.4
> 


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


Re: [Mesa-dev] [PATCH 01/14] util/gen_xmlpool: use argparse for argument handling

2018-10-26 Thread Dylan Baker
I don't really understand what happened, but the rest of the series sent as
blank emails, mailman got very grumpy with me and gave me a temp ban for it :/

I'll resend the whole series with your rb on this patch.

Dylan

Quoting Eric Engestrom (2018-10-26 04:30:01)
> On Thursday, 2018-10-25 13:12:04 -0700, Dylan Baker wrote:
> > This is a little cleaner than just looking at sys.argv, but it's also
> > going to allow us to handle the differences in the way meson and
> > autotools handle translations more cleanly.
> 
> Can't see the rest of this series (it's not in the mailman archive
> either), but this patch is:
> Reviewed-by: Eric Engestrom 
> 
> > ---
> >  src/util/xmlpool/gen_xmlpool.py | 20 +---
> >  1 file changed, 9 insertions(+), 11 deletions(-)
> > 
> > diff --git a/src/util/xmlpool/gen_xmlpool.py 
> > b/src/util/xmlpool/gen_xmlpool.py
> > index 56a67bcab55..b40f295738e 100644
> > --- a/src/util/xmlpool/gen_xmlpool.py
> > +++ b/src/util/xmlpool/gen_xmlpool.py
> > @@ -9,25 +9,23 @@
> >  
> >  from __future__ import print_function
> >  
> > +import argparse
> >  import io
> >  import sys
> >  import gettext
> >  import re
> >  
> > +parser = argparse.ArgumentParser()
> > +parser.add_argument('template')
> > +parser.add_argument('localedir')
> > +parser.add_argument('languages', nargs='*')
> > +args = parser.parse_args()
> >  
> >  if sys.version_info < (3, 0):
> >  gettext_method = 'ugettext'
> >  else:
> >  gettext_method = 'gettext'
> >  
> > -# Path to t_options.h
> > -template_header_path = sys.argv[1]
> > -
> > -localedir = sys.argv[2]
> > -
> > -# List of supported languages
> > -languages = sys.argv[3:]
> > -
> >  # Escape special characters in C strings
> >  def escapeCString (s):
> >  escapeSeqs = {'\a' : '\\a', '\b' : '\\b', '\f' : '\\f', '\n' : '\\n',
> > @@ -166,9 +164,9 @@ def expandMatches (matches, translations, end=None):
> >  # Compile a list of translation classes to all supported languages.
> >  # The first translation is always a NullTranslations.
> >  translations = [("en", gettext.NullTranslations())]
> > -for lang in languages:
> > +for lang in args.languages:
> >  try:
> > -trans = gettext.translation ("options", localedir, [lang])
> > +trans = gettext.translation ("options", args.localedir, [lang])
> >  except IOError:
> >  sys.stderr.write ("Warning: language '%s' not found.\n" % lang)
> >  continue
> > @@ -188,7 +186,7 @@ 
> > print("/***\
> >  
> >  # Process the options template and generate options.h with all
> >  # translations.
> > -template = io.open (template_header_path, mode="rt", encoding='utf-8')
> > +template = io.open (args.template, mode="rt", encoding='utf-8')
> >  descMatches = []
> >  for line in template:
> >  if len(descMatches) > 0:
> > -- 
> > 2.19.1
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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


Re: [Mesa-dev] [PATCH] intel/decoder: Use 'DWord Length' and 'bias' fields for packet length.

2018-10-26 Thread Lionel Landwerlin

On 26/10/2018 15:34, Toni Lönnberg wrote:

On Fri, Oct 26, 2018 at 03:15:50PM +0100, Lionel Landwerlin wrote:

On 26/10/2018 15:06, Toni Lönnberg wrote:

- Forwarded message from Toni Lönnberg  -

Date: Fri, 26 Oct 2018 17:03:54 +0300
From: Toni Lönnberg 
To: Lionel Landwerlin 
Message-ID: <20181026140354.gd3...@intel.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Subject: Re: [Mesa-dev] [PATCH] intel/decoder: Use 'DWord Length' and 'bias' 
fields for packet length.

On Fri, Oct 26, 2018 at 02:24:19PM +0100, Lionel Landwerlin wrote:

Overall I agree this probably what we should do rather than this long
special case switch in gen_group_get_length().

There are some other changes that I'm trying to do because some of the opcodes 
are being shared between engines but have completely different formats 
depending on the engine they're sent to, MEDIA_CURBE_LOAD vs. MFX_SURFACE_STATE 
for example, making it impossible to distinguish between the two of them at the 
moment AFAIK.


I guess the way to do this would be to add a field engine="(3d|media|all)"
for each instruction in the genxml file.

Then change gen_spec_find_instruction() to add an engine enum and do the
matching there.

I'm trying to figure out a way to do this with as little modifications to the
current genxml files as possible but so far have not come up with a solution
that I'm perfectly comfortable with.



I think you could almost do it with a regexp, if it's "3DSTATE.*" -> 3d 
command, "MI_*" -> all, and the few remaining cases are :



src/intel/genxml/gen9.xml:  bias="2" length="3">
src/intel/genxml/gen9.xml:  length="15">
src/intel/genxml/gen9.xml:  bias="2" length="4">
src/intel/genxml/gen9.xml:  name="MEDIA_INTERFACE_DESCRIPTOR_LOAD" bias="2" length="4">

src/intel/genxml/gen9.xml:  
src/intel/genxml/gen9.xml:  
src/intel/genxml/gen9.xml:  bias="2" length="16">
src/intel/genxml/gen9.xml:  bias="2">
src/intel/genxml/gen9.xml:  bias="2" length="2">
src/intel/genxml/gen9.xml:  length="9">
src/intel/genxml/gen9.xml:  length="1">
src/intel/genxml/gen9.xml:  length="6">
src/intel/genxml/gen9.xml:  bias="2" length="19">
src/intel/genxml/gen9.xml:  length="2">
src/intel/genxml/gen9.xml:  length="3">







We could set the engine on the gen_batch_decoder
(src/intel/common/gen_batch_decoder.c) when we initialize it.


I think some discussion happened at some point to try to split things a bit,
so we can reduce the xml file and maybe not embed everything in the 3d
driver.

I agree completely, it would be better not to pollute the 3D driver with the
media stuff. So I'm in all favor of splitting them into different files
altogether as long as building the debug tools will not require manual work
when one wants all the definitions.


For instance we won't care much about media instructions. Similarly we've
pretty much stopped using the blitter (I have patches for those
instructions), if we want them for debug tools, better have that separate...


-

Lionel



I have one suggestion below.

On 26/10/2018 14:07, Toni Lönnberg wrote:

Use the 'DWord Length' and 'bias' fields from the instruction definition to
parse the packet length from the command stream when possible. The hardcoded
mechanism is used whenever an instruction doesn't have this field.
---
src/intel/common/gen_decoder.c | 16 ++--
src/intel/common/gen_decoder.h |  1 +
2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index 5f6e7a0b808..2d58708f5dd 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -163,11 +163,15 @@ create_group(struct parser_context *ctx,
   group->spec = ctx->spec;
   group->variable = false;
   group->fixed_length = fixed_length;
+   group->dw_length = 0;
+   group->bias = 1;
   for (int i = 0; atts[i]; i += 2) {
  char *p;
  if (strcmp(atts[i], "length") == 0) {
 group->dw_length = strtoul(atts[i + 1], &p, 0);
+  } else if (strcmp(atts[i], "bias") == 0) {
+ group->bias = strtoul(atts[i + 1], &p, 0);
  }
   }
@@ -743,8 +747,16 @@ gen_group_find_field(struct gen_group *group, const char 
*name)
int
gen_group_get_length(struct gen_group *group, const uint32_t *p)
{
-   if (group && group->fixed_length)
-  return group->dw_length;
+   if (group) {
+  if (group->fixed_length)
+ return group->dw_length;
+  else {
+ struct gen_field *field = gen_group_find_field(group, "DWord Length");

Since "DWord Length" is a field we're going to use quite often, I would put
a pointer to the field in gen_group.

You can do that in the create_field() function and save your self the
find_field() for every instruction.

Good point.


+ if (field) {
+return field_value(p[0], field->start, field->end) + group->bias;
}
+  }
+   }

If we had tests (I'm meant to write some), I would go as far as removing the
whole thing bel

Re: [Mesa-dev] [PATCH v2] intel/tools: fix resource leak

2018-10-26 Thread Lionel Landwerlin

On 26/10/2018 15:29, asimiklit.w...@gmail.com wrote:

From: Andrii Simiklit 

Some memory and file descriptors are not freed/closed.

v2: fixed case where we skipped the 'aub' variable initialization

Signed-off-by: Andrii Simiklit 



Still :

Reviewed-by: Lionel Landwerlin 


Thanks!



---
  src/intel/tools/error2aub.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/intel/tools/error2aub.c b/src/intel/tools/error2aub.c
index 8a23d5ef1e..2b850ce885 100644
--- a/src/intel/tools/error2aub.c
+++ b/src/intel/tools/error2aub.c
@@ -326,6 +326,16 @@ main(int argc, char *argv[])
  
 aub_write_exec(&aub, batch_addr, aub_gtt_size(&aub), I915_EXEC_RENDER);
  
+   free(out_filename);

+   free(line);
+   if(err_file) {
+  fclose(err_file);
+   }
+   if(aub.file) {
+  aub_file_finish(&aub);
+   } else if(aub_file) {
+  fclose(aub_file);
+   }
 return EXIT_SUCCESS;
  }
  



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


Re: [Mesa-dev] [PATCH] intel/tools: fix resource leak

2018-10-26 Thread andrey simiklit
Hello,

Thanks a lot for reviewing and for quick reply.
Sorry, I forgot ( I thought that it impossible to have the feedback in a 10
minutes on Friday :-) ) to update my inbox and sent version v2,
I guess that I fix small issue in v2:
-   aub_file_finish(&aub);
+   if(aub.file) {
+  aub_file_finish(&aub);
+   } else if(aub_file) {
+  fclose(aub_file);
+   }

Thanks,
Andrii.

On Fri, Oct 26, 2018 at 5:20 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> On 26/10/2018 15:11, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > Some memory and file descriptors are not freed/closed.
>
>
> Thanks a lot :
>
>
> Reviewed-by: Lionel Landwerlin 
>
>
> >
> > Signed-off-by: Andrii Simiklit 
> > ---
> >   src/intel/tools/error2aub.c | 6 ++
> >   1 file changed, 6 insertions(+)
> >
> > diff --git a/src/intel/tools/error2aub.c b/src/intel/tools/error2aub.c
> > index 8a23d5ef1e..451fd8c74a 100644
> > --- a/src/intel/tools/error2aub.c
> > +++ b/src/intel/tools/error2aub.c
> > @@ -326,6 +326,12 @@ main(int argc, char *argv[])
> >
> >  aub_write_exec(&aub, batch_addr, aub_gtt_size(&aub),
> I915_EXEC_RENDER);
> >
> > +   free(out_filename);
> > +   free(line);
> > +   if(err_file) {
> > +  fclose(err_file);
> > +   }
> > +   aub_file_finish(&aub);
> >  return EXIT_SUCCESS;
> >   }
> >
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] intel/decoder: Use 'DWord Length' and 'bias' fields for packet length.

2018-10-26 Thread Toni Lönnberg
On Fri, Oct 26, 2018 at 03:15:50PM +0100, Lionel Landwerlin wrote:
> On 26/10/2018 15:06, Toni Lönnberg wrote:
> > - Forwarded message from Toni Lönnberg  -
> > 
> > Date: Fri, 26 Oct 2018 17:03:54 +0300
> > From: Toni Lönnberg 
> > To: Lionel Landwerlin 
> > Message-ID: <20181026140354.gd3...@intel.com>
> > User-Agent: Mutt/1.9.4 (2018-02-28)
> > Subject: Re: [Mesa-dev] [PATCH] intel/decoder: Use 'DWord Length' and 
> > 'bias' fields for packet length.
> > 
> > On Fri, Oct 26, 2018 at 02:24:19PM +0100, Lionel Landwerlin wrote:
> > > Overall I agree this probably what we should do rather than this long
> > > special case switch in gen_group_get_length().
> > There are some other changes that I'm trying to do because some of the 
> > opcodes are being shared between engines but have completely different 
> > formats depending on the engine they're sent to, MEDIA_CURBE_LOAD vs. 
> > MFX_SURFACE_STATE for example, making it impossible to distinguish between 
> > the two of them at the moment AFAIK.
> 
> 
> I guess the way to do this would be to add a field engine="(3d|media|all)"
> for each instruction in the genxml file.
> 
> Then change gen_spec_find_instruction() to add an engine enum and do the
> matching there.

I'm trying to figure out a way to do this with as little modifications to the
current genxml files as possible but so far have not come up with a solution
that I'm perfectly comfortable with.

> We could set the engine on the gen_batch_decoder
> (src/intel/common/gen_batch_decoder.c) when we initialize it.
> 
> 
> I think some discussion happened at some point to try to split things a bit,
> so we can reduce the xml file and maybe not embed everything in the 3d
> driver.

I agree completely, it would be better not to pollute the 3D driver with the
media stuff. So I'm in all favor of splitting them into different files
altogether as long as building the debug tools will not require manual work
when one wants all the definitions.

> For instance we won't care much about media instructions. Similarly we've
> pretty much stopped using the blitter (I have patches for those
> instructions), if we want them for debug tools, better have that separate...
> 
> 
> -
> 
> Lionel
> 
> 
> > 
> > > I have one suggestion below.
> > > 
> > > On 26/10/2018 14:07, Toni Lönnberg wrote:
> > > > Use the 'DWord Length' and 'bias' fields from the instruction 
> > > > definition to
> > > > parse the packet length from the command stream when possible. The 
> > > > hardcoded
> > > > mechanism is used whenever an instruction doesn't have this field.
> > > > ---
> > > >src/intel/common/gen_decoder.c | 16 ++--
> > > >src/intel/common/gen_decoder.h |  1 +
> > > >2 files changed, 15 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/src/intel/common/gen_decoder.c 
> > > > b/src/intel/common/gen_decoder.c
> > > > index 5f6e7a0b808..2d58708f5dd 100644
> > > > --- a/src/intel/common/gen_decoder.c
> > > > +++ b/src/intel/common/gen_decoder.c
> > > > @@ -163,11 +163,15 @@ create_group(struct parser_context *ctx,
> > > >   group->spec = ctx->spec;
> > > >   group->variable = false;
> > > >   group->fixed_length = fixed_length;
> > > > +   group->dw_length = 0;
> > > > +   group->bias = 1;
> > > >   for (int i = 0; atts[i]; i += 2) {
> > > >  char *p;
> > > >  if (strcmp(atts[i], "length") == 0) {
> > > > group->dw_length = strtoul(atts[i + 1], &p, 0);
> > > > +  } else if (strcmp(atts[i], "bias") == 0) {
> > > > + group->bias = strtoul(atts[i + 1], &p, 0);
> > > >  }
> > > >   }
> > > > @@ -743,8 +747,16 @@ gen_group_find_field(struct gen_group *group, 
> > > > const char *name)
> > > >int
> > > >gen_group_get_length(struct gen_group *group, const uint32_t *p)
> > > >{
> > > > -   if (group && group->fixed_length)
> > > > -  return group->dw_length;
> > > > +   if (group) {
> > > > +  if (group->fixed_length)
> > > > + return group->dw_length;
> > > > +  else {
> > > > + struct gen_field *field = gen_group_find_field(group, "DWord 
> > > > Length");
> > > 
> > > Since "DWord Length" is a field we're going to use quite often, I would 
> > > put
> > > a pointer to the field in gen_group.
> > > 
> > > You can do that in the create_field() function and save your self the
> > > find_field() for every instruction.
> > Good point.
> > 
> > > 
> > > > + if (field) {
> > > > +return field_value(p[0], field->start, field->end) + 
> > > > group->bias;
> > > >}
> > > > +  }
> > > > +   }
> > > 
> > > If we had tests (I'm meant to write some), I would go as far as removing 
> > > the
> > > whole thing below and just return 1.
> > > 
> > > It means we don't have a group and in that case we're likely going to just
> > > iterate dword by dword.
> > Since we don't have tests for this, IMHO it's better to leave it there for 
> > the time being. I don't have any informa

[Mesa-dev] [PATCH v2] intel/tools: fix resource leak

2018-10-26 Thread asimiklit . work
From: Andrii Simiklit 

Some memory and file descriptors are not freed/closed.

v2: fixed case where we skipped the 'aub' variable initialization

Signed-off-by: Andrii Simiklit 
---
 src/intel/tools/error2aub.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/intel/tools/error2aub.c b/src/intel/tools/error2aub.c
index 8a23d5ef1e..2b850ce885 100644
--- a/src/intel/tools/error2aub.c
+++ b/src/intel/tools/error2aub.c
@@ -326,6 +326,16 @@ main(int argc, char *argv[])
 
aub_write_exec(&aub, batch_addr, aub_gtt_size(&aub), I915_EXEC_RENDER);
 
+   free(out_filename);
+   free(line);
+   if(err_file) {
+  fclose(err_file);
+   }
+   if(aub.file) {
+  aub_file_finish(&aub);
+   } else if(aub_file) {
+  fclose(aub_file);
+   }
return EXIT_SUCCESS;
 }
 
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH] intel/tools: fix resource leak

2018-10-26 Thread Lionel Landwerlin

On 26/10/2018 15:11, asimiklit.w...@gmail.com wrote:

From: Andrii Simiklit 

Some memory and file descriptors are not freed/closed.



Thanks a lot :


Reviewed-by: Lionel Landwerlin 




Signed-off-by: Andrii Simiklit 
---
  src/intel/tools/error2aub.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/src/intel/tools/error2aub.c b/src/intel/tools/error2aub.c
index 8a23d5ef1e..451fd8c74a 100644
--- a/src/intel/tools/error2aub.c
+++ b/src/intel/tools/error2aub.c
@@ -326,6 +326,12 @@ main(int argc, char *argv[])
  
 aub_write_exec(&aub, batch_addr, aub_gtt_size(&aub), I915_EXEC_RENDER);
  
+   free(out_filename);

+   free(line);
+   if(err_file) {
+  fclose(err_file);
+   }
+   aub_file_finish(&aub);
 return EXIT_SUCCESS;
  }
  



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


Re: [Mesa-dev] [PATCH] intel/decoder: Use 'DWord Length' and 'bias' fields for packet length.

2018-10-26 Thread Lionel Landwerlin

On 26/10/2018 15:06, Toni Lönnberg wrote:

- Forwarded message from Toni Lönnberg  -

Date: Fri, 26 Oct 2018 17:03:54 +0300
From: Toni Lönnberg 
To: Lionel Landwerlin 
Message-ID: <20181026140354.gd3...@intel.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Subject: Re: [Mesa-dev] [PATCH] intel/decoder: Use 'DWord Length' and 'bias' 
fields for packet length.

On Fri, Oct 26, 2018 at 02:24:19PM +0100, Lionel Landwerlin wrote:

Overall I agree this probably what we should do rather than this long
special case switch in gen_group_get_length().

There are some other changes that I'm trying to do because some of the opcodes 
are being shared between engines but have completely different formats 
depending on the engine they're sent to, MEDIA_CURBE_LOAD vs. MFX_SURFACE_STATE 
for example, making it impossible to distinguish between the two of them at the 
moment AFAIK.



I guess the way to do this would be to add a field 
engine="(3d|media|all)" for each instruction in the genxml file.


Then change gen_spec_find_instruction() to add an engine enum and do the 
matching there.


We could set the engine on the gen_batch_decoder 
(src/intel/common/gen_batch_decoder.c) when we initialize it.



I think some discussion happened at some point to try to split things a 
bit, so we can reduce the xml file and maybe not embed everything in the 
3d driver.


For instance we won't care much about media instructions. Similarly 
we've pretty much stopped using the blitter (I have patches for those 
instructions), if we want them for debug tools, better have that separate...



-

Lionel





I have one suggestion below.

On 26/10/2018 14:07, Toni Lönnberg wrote:

Use the 'DWord Length' and 'bias' fields from the instruction definition to
parse the packet length from the command stream when possible. The hardcoded
mechanism is used whenever an instruction doesn't have this field.
---
   src/intel/common/gen_decoder.c | 16 ++--
   src/intel/common/gen_decoder.h |  1 +
   2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index 5f6e7a0b808..2d58708f5dd 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -163,11 +163,15 @@ create_group(struct parser_context *ctx,
  group->spec = ctx->spec;
  group->variable = false;
  group->fixed_length = fixed_length;
+   group->dw_length = 0;
+   group->bias = 1;
  for (int i = 0; atts[i]; i += 2) {
 char *p;
 if (strcmp(atts[i], "length") == 0) {
group->dw_length = strtoul(atts[i + 1], &p, 0);
+  } else if (strcmp(atts[i], "bias") == 0) {
+ group->bias = strtoul(atts[i + 1], &p, 0);
 }
  }
@@ -743,8 +747,16 @@ gen_group_find_field(struct gen_group *group, const char 
*name)
   int
   gen_group_get_length(struct gen_group *group, const uint32_t *p)
   {
-   if (group && group->fixed_length)
-  return group->dw_length;
+   if (group) {
+  if (group->fixed_length)
+ return group->dw_length;
+  else {
+ struct gen_field *field = gen_group_find_field(group, "DWord Length");


Since "DWord Length" is a field we're going to use quite often, I would put
a pointer to the field in gen_group.

You can do that in the create_field() function and save your self the
find_field() for every instruction.

Good point.




+ if (field) {
+return field_value(p[0], field->start, field->end) + group->bias;
   }
+  }
+   }


If we had tests (I'm meant to write some), I would go as far as removing the
whole thing below and just return 1.

It means we don't have a group and in that case we're likely going to just
iterate dword by dword.

Since we don't have tests for this, IMHO it's better to leave it there for the 
time being. I don't have any information whether there are any non-single dword 
packets without the 'DWord Length' field, but I'm doubtful.



If you ever have a pressing need to write tests, I could thing a few 
things that could be automated so we have decent coverage across gens.








  uint32_t h = p[0];
  uint32_t type = field_value(h, 29, 31);
diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
index a80c50b6647..0b33eb32cfc 100644
--- a/src/intel/common/gen_decoder.h
+++ b/src/intel/common/gen_decoder.h
@@ -101,6 +101,7 @@ struct gen_group {
  struct gen_field *fields; /* linked list of fields */
  uint32_t dw_length;
+   uint32_t bias; /*  specific */
  uint32_t group_offset, group_count;
  uint32_t group_size;
  bool variable; /*  specific */



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



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


[Mesa-dev] [PATCH] intel/tools: fix resource leak

2018-10-26 Thread asimiklit . work
From: Andrii Simiklit 

Some memory and file descriptors are not freed/closed.

Signed-off-by: Andrii Simiklit 
---
 src/intel/tools/error2aub.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/intel/tools/error2aub.c b/src/intel/tools/error2aub.c
index 8a23d5ef1e..451fd8c74a 100644
--- a/src/intel/tools/error2aub.c
+++ b/src/intel/tools/error2aub.c
@@ -326,6 +326,12 @@ main(int argc, char *argv[])
 
aub_write_exec(&aub, batch_addr, aub_gtt_size(&aub), I915_EXEC_RENDER);
 
+   free(out_filename);
+   free(line);
+   if(err_file) {
+  fclose(err_file);
+   }
+   aub_file_finish(&aub);
return EXIT_SUCCESS;
 }
 
-- 
2.17.1

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


[Mesa-dev] [Bug 108565] Rise of the Tomb Raider SIGSEGV in LLVM 7.0.0

2018-10-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108565

--- Comment #2 from Alex Smith  ---
Possibly fixed by
https://gitlab.freedesktop.org/mesa/mesa/commit/ca83d51cfb154af12ee6e17a533df6cbbc890e22
which didn't make 18.2.3. Could you try that? I saw some similar backtraces
while debugging that, due to the bug causing memory corruption.

-- 
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] intel/decoder: Use 'DWord Length' and 'bias' fields for packet length.

2018-10-26 Thread Toni Lönnberg
- Forwarded message from Toni Lönnberg  -

Date: Fri, 26 Oct 2018 17:03:54 +0300
From: Toni Lönnberg 
To: Lionel Landwerlin 
Message-ID: <20181026140354.gd3...@intel.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Subject: Re: [Mesa-dev] [PATCH] intel/decoder: Use 'DWord Length' and 'bias' 
fields for packet length.

On Fri, Oct 26, 2018 at 02:24:19PM +0100, Lionel Landwerlin wrote:
> Overall I agree this probably what we should do rather than this long
> special case switch in gen_group_get_length().

There are some other changes that I'm trying to do because some of the opcodes 
are being shared between engines but have completely different formats 
depending on the engine they're sent to, MEDIA_CURBE_LOAD vs. MFX_SURFACE_STATE 
for example, making it impossible to distinguish between the two of them at the 
moment AFAIK.

> I have one suggestion below.
> 
> On 26/10/2018 14:07, Toni Lönnberg wrote:
> > Use the 'DWord Length' and 'bias' fields from the instruction definition to
> > parse the packet length from the command stream when possible. The hardcoded
> > mechanism is used whenever an instruction doesn't have this field.
> > ---
> >   src/intel/common/gen_decoder.c | 16 ++--
> >   src/intel/common/gen_decoder.h |  1 +
> >   2 files changed, 15 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
> > index 5f6e7a0b808..2d58708f5dd 100644
> > --- a/src/intel/common/gen_decoder.c
> > +++ b/src/intel/common/gen_decoder.c
> > @@ -163,11 +163,15 @@ create_group(struct parser_context *ctx,
> >  group->spec = ctx->spec;
> >  group->variable = false;
> >  group->fixed_length = fixed_length;
> > +   group->dw_length = 0;
> > +   group->bias = 1;
> >  for (int i = 0; atts[i]; i += 2) {
> > char *p;
> > if (strcmp(atts[i], "length") == 0) {
> >group->dw_length = strtoul(atts[i + 1], &p, 0);
> > +  } else if (strcmp(atts[i], "bias") == 0) {
> > + group->bias = strtoul(atts[i + 1], &p, 0);
> > }
> >  }
> > @@ -743,8 +747,16 @@ gen_group_find_field(struct gen_group *group, const 
> > char *name)
> >   int
> >   gen_group_get_length(struct gen_group *group, const uint32_t *p)
> >   {
> > -   if (group && group->fixed_length)
> > -  return group->dw_length;
> > +   if (group) {
> > +  if (group->fixed_length)
> > + return group->dw_length;
> > +  else {
> > + struct gen_field *field = gen_group_find_field(group, "DWord 
> > Length");
> 
> 
> Since "DWord Length" is a field we're going to use quite often, I would put
> a pointer to the field in gen_group.
> 
> You can do that in the create_field() function and save your self the
> find_field() for every instruction.

Good point.

> 
> 
> > + if (field) {
> > +return field_value(p[0], field->start, field->end) + 
> > group->bias;
> >   }
> > +  }
> > +   }
> 
> 
> If we had tests (I'm meant to write some), I would go as far as removing the
> whole thing below and just return 1.
> 
> It means we don't have a group and in that case we're likely going to just
> iterate dword by dword.

Since we don't have tests for this, IMHO it's better to leave it there for the 
time being. I don't have any information whether there are any non-single dword 
packets without the 'DWord Length' field, but I'm doubtful.

> 
> 
> >  uint32_t h = p[0];
> >  uint32_t type = field_value(h, 29, 31);
> > diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
> > index a80c50b6647..0b33eb32cfc 100644
> > --- a/src/intel/common/gen_decoder.h
> > +++ b/src/intel/common/gen_decoder.h
> > @@ -101,6 +101,7 @@ struct gen_group {
> >  struct gen_field *fields; /* linked list of fields */
> >  uint32_t dw_length;
> > +   uint32_t bias; /*  specific */
> >  uint32_t group_offset, group_count;
> >  uint32_t group_size;
> >  bool variable; /*  specific */
> 
> 

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


[Mesa-dev] [Bug 108565] Rise of the Tomb Raider SIGSEGV in LLVM 7.0.0

2018-10-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108565

--- Comment #1 from Jan Ziak <0xe2.0x9a.0...@gmail.com> ---
Created attachment 142220
  --> https://bugs.freedesktop.org/attachment.cgi?id=142220&action=edit
gdb backtrace 2.txt

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


[Mesa-dev] [Bug 108565] Rise of the Tomb Raider SIGSEGV in LLVM 7.0.0

2018-10-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108565

Bug ID: 108565
   Summary: Rise of the Tomb Raider SIGSEGV in LLVM 7.0.0
   Product: Mesa
   Version: 18.2
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: 0xe2.0x9a.0...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 142219
  --> https://bugs.freedesktop.org/attachment.cgi?id=142219&action=edit
gdb backtrace.txt

The game crashes when continuing the game from the main menu.

Deleting all folders and files in the ~/.cache/mesa_shader_cache/ and
~/.steam/root/steamapps/shadercache/391220/ folders does NOT fix this bug.

Mesa: 18.2.3
LLVM: 7.0.0-r1 (Gentoo Linux)
Linux kernel: 4.19
GPU: R9 390

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


[Mesa-dev] [Bug 107601] Rise of the Tomb Raider Segmentation Fault when the game starts

2018-10-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107601

Jan Ziak <0xe2.0x9a.0...@gmail.com> changed:

   What|Removed |Added

 CC||0xe2.0x9a.0...@gmail.com

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


Re: [Mesa-dev] [PATCH] intel/decoder: Use 'DWord Length' and 'bias' fields for packet length.

2018-10-26 Thread Lionel Landwerlin
Overall I agree this probably what we should do rather than this long 
special case switch in gen_group_get_length().

I have one suggestion below.

On 26/10/2018 14:07, Toni Lönnberg wrote:

Use the 'DWord Length' and 'bias' fields from the instruction definition to
parse the packet length from the command stream when possible. The hardcoded
mechanism is used whenever an instruction doesn't have this field.
---
  src/intel/common/gen_decoder.c | 16 ++--
  src/intel/common/gen_decoder.h |  1 +
  2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index 5f6e7a0b808..2d58708f5dd 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -163,11 +163,15 @@ create_group(struct parser_context *ctx,
 group->spec = ctx->spec;
 group->variable = false;
 group->fixed_length = fixed_length;
+   group->dw_length = 0;
+   group->bias = 1;
  
 for (int i = 0; atts[i]; i += 2) {

char *p;
if (strcmp(atts[i], "length") == 0) {
   group->dw_length = strtoul(atts[i + 1], &p, 0);
+  } else if (strcmp(atts[i], "bias") == 0) {
+ group->bias = strtoul(atts[i + 1], &p, 0);
}
 }
  
@@ -743,8 +747,16 @@ gen_group_find_field(struct gen_group *group, const char *name)

  int
  gen_group_get_length(struct gen_group *group, const uint32_t *p)
  {
-   if (group && group->fixed_length)
-  return group->dw_length;
+   if (group) {
+  if (group->fixed_length)
+ return group->dw_length;
+  else {
+ struct gen_field *field = gen_group_find_field(group, "DWord Length");



Since "DWord Length" is a field we're going to use quite often, I would 
put a pointer to the field in gen_group.


You can do that in the create_field() function and save your self the 
find_field() for every instruction.




+ if (field) {
+return field_value(p[0], field->start, field->end) + group->bias;
  }
+  }
+   }



If we had tests (I'm meant to write some), I would go as far as removing 
the whole thing below and just return 1.


It means we don't have a group and in that case we're likely going to 
just iterate dword by dword.



  
 uint32_t h = p[0];

 uint32_t type = field_value(h, 29, 31);
diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
index a80c50b6647..0b33eb32cfc 100644
--- a/src/intel/common/gen_decoder.h
+++ b/src/intel/common/gen_decoder.h
@@ -101,6 +101,7 @@ struct gen_group {
 struct gen_field *fields; /* linked list of fields */
  
 uint32_t dw_length;

+   uint32_t bias; /*  specific */
 uint32_t group_offset, group_count;
 uint32_t group_size;
 bool variable; /*  specific */



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


Re: [Mesa-dev] [PATCH] intel/compiler: Print message descriptor as immediate source

2018-10-26 Thread Eero Tamminen

Hi,

Toni had a working assembler in early 2017, but he had to stop working
on it because nobody reviewed the patches needed for the disassembler.

Maybe his patch series for the disassembly output still has something
useful for your assembler:

* i965 shader disassembly label support:
https://patchwork.freedesktop.org/series/19946/
* i965 shader disassembly formatting changes:
https://patchwork.freedesktop.org/series/19945/
* Always print message descriptor and SFID for SEND instructions:
https://patchwork.freedesktop.org/patch/223750/

?

- Eero

On 10/25/18 2:25 AM, Sagar Ghuge wrote:

While disassembling send(c) instruction print message descriptor as
immediate source operand along with message descriptor. This allows
assembler to read immediate source operand and set bits accordingly.

Signed-off-by: Sagar Ghuge 
---
  src/intel/compiler/brw_disasm.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/intel/compiler/brw_disasm.c b/src/intel/compiler/brw_disasm.c
index 6a7e988641..9c6df9e645 100644
--- a/src/intel/compiler/brw_disasm.c
+++ b/src/intel/compiler/brw_disasm.c
@@ -1606,7 +1606,12 @@ brw_disassemble_inst(FILE *file, const struct 
gen_device_info *devinfo,
   /* show the indirect descriptor source */
   pad(file, 48);
   err |= src1(file, devinfo, inst);
-  }
+ pad(file, 64);
+  } else
+ pad(file, 48);
+
+  /* Print message descriptor as immediate source */
+  fprintf(file, "0x%08"PRIx64, inst->data[1] >> 32);
  
newline(file);

pad(file, 16);
@@ -1615,7 +1620,7 @@ brw_disassemble_inst(FILE *file, const struct 
gen_device_info *devinfo,
fprintf(file, "");
err |= control(file, "SFID", devinfo->gen >= 6 ? gen6_sfid : gen4_sfid,
   sfid, &space);
-
+  string(file, " MsgDesc:");
  
if (brw_inst_src1_reg_file(devinfo, inst) != BRW_IMMEDIATE_VALUE) {

   format(file, " indirect");



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


[Mesa-dev] [PATCH] intel/decoder: Use 'DWord Length' and 'bias' fields for packet length.

2018-10-26 Thread Toni Lönnberg
Use the 'DWord Length' and 'bias' fields from the instruction definition to
parse the packet length from the command stream when possible. The hardcoded
mechanism is used whenever an instruction doesn't have this field.
---
 src/intel/common/gen_decoder.c | 16 ++--
 src/intel/common/gen_decoder.h |  1 +
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index 5f6e7a0b808..2d58708f5dd 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -163,11 +163,15 @@ create_group(struct parser_context *ctx,
group->spec = ctx->spec;
group->variable = false;
group->fixed_length = fixed_length;
+   group->dw_length = 0;
+   group->bias = 1;
 
for (int i = 0; atts[i]; i += 2) {
   char *p;
   if (strcmp(atts[i], "length") == 0) {
  group->dw_length = strtoul(atts[i + 1], &p, 0);
+  } else if (strcmp(atts[i], "bias") == 0) {
+ group->bias = strtoul(atts[i + 1], &p, 0);
   }
}
 
@@ -743,8 +747,16 @@ gen_group_find_field(struct gen_group *group, const char 
*name)
 int
 gen_group_get_length(struct gen_group *group, const uint32_t *p)
 {
-   if (group && group->fixed_length)
-  return group->dw_length;
+   if (group) {
+  if (group->fixed_length)
+ return group->dw_length;
+  else {
+ struct gen_field *field = gen_group_find_field(group, "DWord Length");
+ if (field) {
+return field_value(p[0], field->start, field->end) + group->bias;
+ }
+  }
+   }
 
uint32_t h = p[0];
uint32_t type = field_value(h, 29, 31);
diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
index a80c50b6647..0b33eb32cfc 100644
--- a/src/intel/common/gen_decoder.h
+++ b/src/intel/common/gen_decoder.h
@@ -101,6 +101,7 @@ struct gen_group {
struct gen_field *fields; /* linked list of fields */
 
uint32_t dw_length;
+   uint32_t bias; /*  specific */
uint32_t group_offset, group_count;
uint32_t group_size;
bool variable; /*  specific */
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH 3/3] anv: Handle the device loss abort in anv_device_set_lost

2018-10-26 Thread Eric Engestrom
On Thursday, 2018-10-25 11:46:57 -0500, Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/anv_device.c | 11 +++
>  src/intel/vulkan/anv_util.c   |  4 
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 79d3f052113..d62bdde078c 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -2053,6 +2053,17 @@ void
>  anv_device_set_lost(struct anv_device *device, const char *msg, ...)
>  {
> device->_lost = true;
> +
> +   if (env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false)) {
> +  intel_loge("Device lost!");
> +
> +  va_list ap;
> +  va_start(ap, msg);
> +  intel_loge_v(msg, ap);
> +  va_end(ap);
> +
> +  abort();
> +   }
>  }
>  
>  VkResult
> diff --git a/src/intel/vulkan/anv_util.c b/src/intel/vulkan/anv_util.c
> index 9082707624c..9963a15ace3 100644
> --- a/src/intel/vulkan/anv_util.c
> +++ b/src/intel/vulkan/anv_util.c
> @@ -112,9 +112,5 @@ __vk_errorf(struct anv_instance *instance, const void 
> *object,
>  
> intel_loge("%s", report);
>  
> -   if (error == VK_ERROR_DEVICE_LOST &&
> -   env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false))
> -  abort();
> -

You can now drop `#include "util/debug.h"` from this file :)

Agreed with Lionel's comment on patch 2, you're duplicating all the
error messages.

Series is:
Reviewed-by: Eric Engestrom 

> return error;
>  }
> -- 
> 2.19.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] kmsro: Extend to include hx8357d.

2018-10-26 Thread Eric Engestrom
On Thursday, 2018-10-25 09:39:10 -0700, Eric Anholt wrote:
> This allows vc4 to initialize on the Adafruit PiTFT 3.5" touchscreen with
> the new tinydrm driver I just submitted.  If this series extending the
> pl111/kmsro driver is accepted, then I'll extend kmsro with the other
> tinydrm drivers as well.
> ---
>  src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 5 +
>  src/gallium/drivers/kmsro/Android.mk| 1 +
>  src/gallium/drivers/kmsro/Automake.inc  | 1 +
>  src/gallium/targets/dri/meson.build | 1 +
>  src/gallium/targets/dri/target.c| 1 +
>  5 files changed, 9 insertions(+)
> 
> diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
> b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
> index 230bafe5e159..73ddab0cbf02 100644
> --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
> +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
> @@ -111,6 +111,11 @@ static const struct drm_driver_descriptor 
> driver_descriptors[] = {
>  .create_screen = pipe_kmsro_create_screen,
>  .configuration = pipe_default_configuration_query,
>  },
> +{
> +   .driver_name = "hx8357d",
> +.create_screen = pipe_kmsro_create_screen,
> +.configuration = pipe_default_configuration_query,
> +},

Is that really all it takes to add a new userspace tinydrm driver? Impressive!

(nit: `.driver_name` missing one space of indentation)

Code-wise, patch #1 is:
Reviewed-by: Eric Engestrom 

Not completely sure this is all that's needed for this patch, so only:
Acked-by: Eric Engestrom 

That said, ... (scroll down)

>  {
>  .driver_name = "virtio_gpu",
>  .create_screen = pipe_virgl_create_screen,
> diff --git a/src/gallium/drivers/kmsro/Android.mk 
> b/src/gallium/drivers/kmsro/Android.mk
> index 8a851024dc88..f6a444e8865b 100644
> --- a/src/gallium/drivers/kmsro/Android.mk
> +++ b/src/gallium/drivers/kmsro/Android.mk
> @@ -35,5 +35,6 @@ include $(BUILD_STATIC_LIBRARY)
>  
>  ifneq ($(HAVE_GALLIUM_KMSRO),)
>  GALLIUM_TARGET_DRIVERS += pl111
> +GALLIUM_TARGET_DRIVERS += hx8357d
>  $(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_kmsro)
>  endif
> diff --git a/src/gallium/drivers/kmsro/Automake.inc 
> b/src/gallium/drivers/kmsro/Automake.inc
> index 66d125cb440a..d5961c907653 100644
> --- a/src/gallium/drivers/kmsro/Automake.inc
> +++ b/src/gallium/drivers/kmsro/Automake.inc
> @@ -1,6 +1,7 @@
>  if HAVE_GALLIUM_KMSRO
>  
>  TARGET_DRIVERS += pl111
> +TARGET_DRIVERS += hx8357d
>  TARGET_CPPFLAGS += -DGALLIUM_KMSRO
>  TARGET_LIB_DEPS += \
>  $(top_builddir)/src/gallium/winsys/kmsro/drm/libkmsrodrm.la \
> diff --git a/src/gallium/targets/dri/meson.build 
> b/src/gallium/targets/dri/meson.build
> index c1cb616b4dad..bc63702498ba 100644
> --- a/src/gallium/targets/dri/meson.build
> +++ b/src/gallium/targets/dri/meson.build
> @@ -63,6 +63,7 @@ libgallium_dri = shared_library(
>  )
>  
>  foreach d : [[with_gallium_kmsro, 'pl111_dri.so'],
> + [with_gallium_kmsro, 'hx8357d_dri.so'],

... wouldn't we want the user-facing `gallium` option to have the
`pl111,hx8357d` granularity?

It would be more work, so as a follow-up patch, and they're just
hardlinks of the same file anyway so they don't really take any disk
space or compilation time, so I'm not sure it's worth it, but asking the
question anyway :)

>   [with_gallium_radeonsi, 'radeonsi_dri.so'],
>   [with_gallium_nouveau, 'nouveau_dri.so'],
>   [with_gallium_freedreno, ['msm_dri.so', 'kgsl_dri.so']],
> diff --git a/src/gallium/targets/dri/target.c 
> b/src/gallium/targets/dri/target.c
> index 2821cef197ea..6b0ea785c405 100644
> --- a/src/gallium/targets/dri/target.c
> +++ b/src/gallium/targets/dri/target.c
> @@ -78,6 +78,7 @@ DEFINE_LOADER_DRM_ENTRYPOINT(v3d)
>  #if defined(GALLIUM_VC4)
>  DEFINE_LOADER_DRM_ENTRYPOINT(vc4)
>  #if defined(GALLIUM_KMSRO)
> +DEFINE_LOADER_DRM_ENTRYPOINT(hx8357d)
>  DEFINE_LOADER_DRM_ENTRYPOINT(pl111)
>  #endif
>  #endif
> -- 
> 2.19.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 01/14] util/gen_xmlpool: use argparse for argument handling

2018-10-26 Thread Eric Engestrom
On Thursday, 2018-10-25 13:12:04 -0700, Dylan Baker wrote:
> This is a little cleaner than just looking at sys.argv, but it's also
> going to allow us to handle the differences in the way meson and
> autotools handle translations more cleanly.

Can't see the rest of this series (it's not in the mailman archive
either), but this patch is:
Reviewed-by: Eric Engestrom 

> ---
>  src/util/xmlpool/gen_xmlpool.py | 20 +---
>  1 file changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
> index 56a67bcab55..b40f295738e 100644
> --- a/src/util/xmlpool/gen_xmlpool.py
> +++ b/src/util/xmlpool/gen_xmlpool.py
> @@ -9,25 +9,23 @@
>  
>  from __future__ import print_function
>  
> +import argparse
>  import io
>  import sys
>  import gettext
>  import re
>  
> +parser = argparse.ArgumentParser()
> +parser.add_argument('template')
> +parser.add_argument('localedir')
> +parser.add_argument('languages', nargs='*')
> +args = parser.parse_args()
>  
>  if sys.version_info < (3, 0):
>  gettext_method = 'ugettext'
>  else:
>  gettext_method = 'gettext'
>  
> -# Path to t_options.h
> -template_header_path = sys.argv[1]
> -
> -localedir = sys.argv[2]
> -
> -# List of supported languages
> -languages = sys.argv[3:]
> -
>  # Escape special characters in C strings
>  def escapeCString (s):
>  escapeSeqs = {'\a' : '\\a', '\b' : '\\b', '\f' : '\\f', '\n' : '\\n',
> @@ -166,9 +164,9 @@ def expandMatches (matches, translations, end=None):
>  # Compile a list of translation classes to all supported languages.
>  # The first translation is always a NullTranslations.
>  translations = [("en", gettext.NullTranslations())]
> -for lang in languages:
> +for lang in args.languages:
>  try:
> -trans = gettext.translation ("options", localedir, [lang])
> +trans = gettext.translation ("options", args.localedir, [lang])
>  except IOError:
>  sys.stderr.write ("Warning: language '%s' not found.\n" % lang)
>  continue
> @@ -188,7 +186,7 @@ 
> print("/***\
>  
>  # Process the options template and generate options.h with all
>  # translations.
> -template = io.open (template_header_path, mode="rt", encoding='utf-8')
> +template = io.open (args.template, mode="rt", encoding='utf-8')
>  descMatches = []
>  for line in template:
>  if len(descMatches) > 0:
> -- 
> 2.19.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] [RFC] Allow fd.o to join forces with X.Org

2018-10-26 Thread Daniel Vetter
On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone  wrote:
>
> Hi,
>
> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter  wrote:
> > On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone  
> > > > wrote:
> > > > > Yeah, I think it makes sense. Some things we do:
> > > > >   - provide hosted network services for collaborative development,
> > > > > testing, and discussion, of open-source projects
> > > > >   - administer, improve, and extend this suite of services as 
> > > > > necessary
> > > > >   - assist open-source projects in their use of these services
> > > > >   - purchase, lease, or subscribe to, computing and networking
> > > > > infrastructure allowing these services to be run
> > > >
> > > > I fully agree that we should document all this. I don't think the
> > > > bylaws are the right place though, much better to put that into
> > > > policies that the board approves and which can be adapted as needed.
> > > > Imo bylaws should cover the high-level mission and procedural details,
> > > > as our "constitution", with the really high acceptance criteria of
> > > > 2/3rd of all members approving any changes. Some of the early
> > > > discussions tried to spell out a lot of the fd.o policies in bylaw
> > > > changes, but then we realized it's all there already. All the details
> > > > are much better served in policies enacted by the board, like we do
> > > > with everything else.
> > > >
> > > > As an example, let's look at XDC. Definitely one of the biggest things
> > > > the foundation does, with handling finances, travel sponsoring grants,
> > > > papers committee, and acquiring lots of sponsors. None of this is
> > > > spelled out in the bylaws, it's all in policies that the board
> > > > deliberates and approves. I think this same approach will also work
> > > > well for fd.o.
> > > >
> > > > And if members are unhappy with what the board does, they can fix in
> > > > the next election by throwing out the unwanted directors.
> > >
> > > yeah, fair call. though IMO in that case we can just reduce to
> > >
> > >\item Support free and open source projects through the freedesktop.org
> > >infrastructure.
> > >
> > > because my gripe is less with the fdo bit but more with defining what
> > > "project hosting" means, given that we use that term to exclude fdo 
> > > projects
> > > from getting anything else. I think just dropping that bit is sufficient.
> >
> > Hm yeah, through the lens of "everything not explicitly listed isn't in
> > scope as X.org's purpose", leaving this out is probably clearest. And
> > under 2.4 (i) the board already has the duty to interpret what exactly
> > this means wrt membership eligibility.
> >
> > Harry, Daniel, what do you think?
>
> Yeah, that's fine. I didn't specifically want the enumerated list of
> what we do in the bylaws, just spelling it out for background as a
> handy reference I could point to later. I think maybe we could reduce
> it to something like:
>   Administer, support, and improve the freedesktop.org hosting
> infrastructure to support the projects it hosts

This feels a bit self-referential, not the best for the purpose of
what X.org does. If we do want to be a bit more specific we could do
something like with (i) and provide a list that the board can extend:

\item Support free and open source projects through the freedesktop.org
infrastructure. This includes, but is not limited to:
Administering and providing
project hosting services.

That would make it clear that admins&servers are in scope, and
everything else is up to the board. Similar to how drm, mesa, wayland
and X are explicitly in scope, and stuff like cros/android gfx stack
or libinput is up to the board to decide/clarify.

> Gives us enough scope to grow in the future (e.g. we don't need a
> bylaws change to move from pure-git to GitLab), avoids the sticky
> question of what exactly fd.o hosts in the bylaws (e.g. if
> NetworkManager needs a new repo then we don't have to consult
> membership to add it), but is still pretty firmly limited in scope.
>
> Any of the above have my in-principle ack though, I think they're all
> reasonable colours for our lovely shed.

Well, one more bikeshed from me!

Cheers, Daniel

>
> Cheers,
> Daniel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: expose EXT_texture_compression_s3tc on GLES

2018-10-26 Thread Erik Faye-Lund
On Thu, 2018-10-25 at 10:45 -0400, Ilia Mirkin wrote:
> Please confirm that this passes the piglit tests you sent to the list
> when run with ES2 forced, i.e. not ES3.
> (MESA_GLES_VERSION_OVERRIDE=2.0 iirc.) I'm concerned that the extra
> logic was only added to _mesa_es3_error_check_bla and not the es2
> paths.

Yeah, the test still passes.

The _mesa_es3_error_check_format_and_type function seems to be a bit
unfortunately named; it seems to be used for *all* es versions. I don't
know why it's named like it is.

But thanks for pointing this out to me; testing this revealed a
porting-bug, where I tried to use glGetTexLevelParameteriv on gles2,
which isn't supported. I'll send out and updated version of the piglit 
patches for that also.

> On Thu, Oct 25, 2018 at 6:59 AM Erik Faye-Lund
>  wrote:
> > 
> > From: Marek Olšák 
> > 
> > The spec was modified to support GLES.
> > 
> > Tested-by: Erik Faye-Lund 
> > ---
> > This replaces this patch:
> > https://patchwork.freedesktop.org/patch/257423/
> > 
> >  docs/relnotes/18.3.0.html|  1 +
> >  src/mesa/main/extensions_table.h |  2 +-
> >  src/mesa/main/glformats.c| 11 +++
> >  3 files changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/docs/relnotes/18.3.0.html b/docs/relnotes/18.3.0.html
> > index 5874d3fa330..e0061872de4 100644
> > --- a/docs/relnotes/18.3.0.html
> > +++ b/docs/relnotes/18.3.0.html
> > @@ -57,6 +57,7 @@ Note: some of the new features are only available
> > with certain drivers.
> >  GL_AMD_multi_draw_indirect on all GL 4.x drivers.
> >  GL_AMD_query_buffer_object on i965, nvc0, r600, radeonsi.
> >  GL_EXT_disjoint_timer_query on radeonsi and most other Gallium
> > drivers (ES extension)
> > +GL_EXT_texture_compression_s3tc on all drivers (ES
> > extension)
> >  GL_EXT_vertex_attrib_64bit on i965, nvc0, radeonsi.
> >  GL_EXT_window_rectangles on radeonsi.
> >  GL_KHR_texture_compression_astc_sliced_3d on radeonsi.
> > diff --git a/src/mesa/main/extensions_table.h
> > b/src/mesa/main/extensions_table.h
> > index 09bf923bd0e..47db1583135 100644
> > --- a/src/mesa/main/extensions_table.h
> > +++ b/src/mesa/main/extensions_table.h
> > @@ -278,7 +278,7 @@ EXT(EXT_texture_buffer  ,
> > OES_texture_buffer
> >  EXT(EXT_texture_compression_dxt1,
> > ANGLE_texture_compression_dxt  , GLL, GLC, ES1, ES2, 2004)
> >  EXT(EXT_texture_compression_latc,
> > EXT_texture_compression_latc   , GLL,  x ,  x ,  x , 2006)
> >  EXT(EXT_texture_compression_rgtc,
> > ARB_texture_compression_rgtc   , GLL, GLC,  x ,  x , 2004)
> > -EXT(EXT_texture_compression_s3tc,
> > EXT_texture_compression_s3tc   , GLL, GLC,  x ,  x , 2000)
> > +EXT(EXT_texture_compression_s3tc,
> > EXT_texture_compression_s3tc   , GLL, GLC,  x , ES2, 2000)
> >  EXT(EXT_texture_cube_map,
> > ARB_texture_cube_map   , GLL,  x ,  x ,  x , 2001)
> >  EXT(EXT_texture_cube_map_array  ,
> > OES_texture_cube_map_array ,  x ,  x ,  x ,  31, 2014)
> >  EXT(EXT_texture_edge_clamp  ,
> > dummy_true , GLL,  x ,  x ,  x , 1997)
> > diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> > index 6cb3435dea2..f8fc36e9311 100644
> > --- a/src/mesa/main/glformats.c
> > +++ b/src/mesa/main/glformats.c
> > @@ -2803,6 +2803,17 @@ _mesa_es3_error_check_format_and_type(const
> > struct gl_context *ctx,
> >internalFormat = effectiveInternalFormat;
> > }
> > 
> > +   /* The GLES variant of EXT_texture_compression_s3tc is very
> > vague and
> > +* doesn't list valid types. Just do exactly what the spec
> > says.
> > +*/
> > +   if (ctx->Extensions.EXT_texture_compression_s3tc &&
> > +   (internalFormat == GL_COMPRESSED_RGB_S3TC_DXT1_EXT ||
> > +internalFormat == GL_COMPRESSED_RGBA_S3TC_DXT1_EXT ||
> > +internalFormat == GL_COMPRESSED_RGBA_S3TC_DXT3_EXT ||
> > +internalFormat == GL_COMPRESSED_RGBA_S3TC_DXT5_EXT))
> > +  return format == GL_RGB || format == GL_RGBA ? GL_NO_ERROR :
> > + GL_INVALID_OP
> > ERATION;
> > +
> > switch (format) {
> > case GL_BGRA_EXT:
> >if (type != GL_UNSIGNED_BYTE || internalFormat != GL_BGRA)
> > --
> > 2.17.2
> > 
> > ___
> > 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] [RFC] Allow fd.o to join forces with X.Org

2018-10-26 Thread Daniel Stone
Hi,

On Fri, 26 Oct 2018 at 11:57, Daniel Vetter  wrote:
> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone  wrote:
> > > > Yeah, I think it makes sense. Some things we do:
> > > >   - provide hosted network services for collaborative development,
> > > > testing, and discussion, of open-source projects
> > > >   - administer, improve, and extend this suite of services as necessary
> > > >   - assist open-source projects in their use of these services
> > > >   - purchase, lease, or subscribe to, computing and networking
> > > > infrastructure allowing these services to be run
> > >
> > > I fully agree that we should document all this. I don't think the
> > > bylaws are the right place though, much better to put that into
> > > policies that the board approves and which can be adapted as needed.
> > > Imo bylaws should cover the high-level mission and procedural details,
> > > as our "constitution", with the really high acceptance criteria of
> > > 2/3rd of all members approving any changes. Some of the early
> > > discussions tried to spell out a lot of the fd.o policies in bylaw
> > > changes, but then we realized it's all there already. All the details
> > > are much better served in policies enacted by the board, like we do
> > > with everything else.
> > >
> > > As an example, let's look at XDC. Definitely one of the biggest things
> > > the foundation does, with handling finances, travel sponsoring grants,
> > > papers committee, and acquiring lots of sponsors. None of this is
> > > spelled out in the bylaws, it's all in policies that the board
> > > deliberates and approves. I think this same approach will also work
> > > well for fd.o.
> > >
> > > And if members are unhappy with what the board does, they can fix in
> > > the next election by throwing out the unwanted directors.
> >
> > yeah, fair call. though IMO in that case we can just reduce to
> >
> >\item Support free and open source projects through the freedesktop.org
> >infrastructure.
> >
> > because my gripe is less with the fdo bit but more with defining what
> > "project hosting" means, given that we use that term to exclude fdo projects
> > from getting anything else. I think just dropping that bit is sufficient.
>
> Hm yeah, through the lens of "everything not explicitly listed isn't in
> scope as X.org's purpose", leaving this out is probably clearest. And
> under 2.4 (i) the board already has the duty to interpret what exactly
> this means wrt membership eligibility.
>
> Harry, Daniel, what do you think?

Yeah, that's fine. I didn't specifically want the enumerated list of
what we do in the bylaws, just spelling it out for background as a
handy reference I could point to later. I think maybe we could reduce
it to something like:
  Administer, support, and improve the freedesktop.org hosting
infrastructure to support the projects it hosts

Gives us enough scope to grow in the future (e.g. we don't need a
bylaws change to move from pure-git to GitLab), avoids the sticky
question of what exactly fd.o hosts in the bylaws (e.g. if
NetworkManager needs a new repo then we don't have to consult
membership to add it), but is still pretty firmly limited in scope.

Any of the above have my in-principle ack though, I think they're all
reasonable colours for our lovely shed.

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


Re: [Mesa-dev] [RFC] Allow fd.o to join forces with X.Org

2018-10-26 Thread Daniel Vetter
On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone  wrote:
> > >
> > > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer  
> > > wrote:
> > > > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > > > + \item Support free and open source projects through the 
> > > > > freedesktop.org
> > > > > + infrastructure. For projects outside the scope of item 
> > > > > (\ref{1}) support
> > > > > + extends to project hosting only.
> > > > > +
> > > >
> > > > Yes to the idea but given that the remaining 11 pages cover all the 
> > > > legalese
> > > > for xorg I think we need to add at least a section of what "project 
> > > > hosting"
> > > > means. Even if it's just a "includes but is not limited to blah".  And 
> > > > some
> > > > addition to 4.1 Powers is needed to spell out what the BoD can do in 
> > > > regards
> > > > to fdo.
> > >
> > > Yeah, I think it makes sense. Some things we do:
> > >   - provide hosted network services for collaborative development,
> > > testing, and discussion, of open-source projects
> > >   - administer, improve, and extend this suite of services as necessary
> > >   - assist open-source projects in their use of these services
> > >   - purchase, lease, or subscribe to, computing and networking
> > > infrastructure allowing these services to be run
> > 
> > I fully agree that we should document all this. I don't think the
> > bylaws are the right place though, much better to put that into
> > policies that the board approves and which can be adapted as needed.
> > Imo bylaws should cover the high-level mission and procedural details,
> > as our "constitution", with the really high acceptance criteria of
> > 2/3rd of all members approving any changes. Some of the early
> > discussions tried to spell out a lot of the fd.o policies in bylaw
> > changes, but then we realized it's all there already. All the details
> > are much better served in policies enacted by the board, like we do
> > with everything else.
> > 
> > As an example, let's look at XDC. Definitely one of the biggest things
> > the foundation does, with handling finances, travel sponsoring grants,
> > papers committee, and acquiring lots of sponsors. None of this is
> > spelled out in the bylaws, it's all in policies that the board
> > deliberates and approves. I think this same approach will also work
> > well for fd.o.
> > 
> > And if members are unhappy with what the board does, they can fix in
> > the next election by throwing out the unwanted directors.
> 
> yeah, fair call. though IMO in that case we can just reduce to
> 
>\item Support free and open source projects through the freedesktop.org
>infrastructure.
> 
> because my gripe is less with the fdo bit but more with defining what
> "project hosting" means, given that we use that term to exclude fdo projects
> from getting anything else. I think just dropping that bit is sufficient.

Hm yeah, through the lens of "everything not explicitly listed isn't in
scope as X.org's purpose", leaving this out is probably clearest. And
under 2.4 (i) the board already has the duty to interpret what exactly
this means wrt membership eligibility.

Harry, Daniel, what do you think?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 103312] meson/macOS: Dependency libdrm_intel found: NO

2018-10-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103312

--- Comment #5 from Yurii Kolesnykov  ---
I can successfully build mesa under macOS 10.14 (Mojave).

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


[Mesa-dev] [Bug 103312] meson/macOS: Dependency libdrm_intel found: NO

2018-10-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103312

Yurii Kolesnykov  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

-- 
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] nir: Divergence Analysis

2018-10-26 Thread Daniel Schürmann

Hi Ian,
thank you very much for the detailed suggestions.
I added the formatting to adhere the coding conventions.

Please remind that this is an RFC, not a pull request.
The implementation is incomplete and not meant to go upstream in this 
state. And while I added some, there are still a lot of intrinsics 
missing. The intended purpose for this RFC is to get feedback on the 
general idea of the DA, and how to integrate it with possible optimizations.

This being said, I do appreciate comments on coding style, typos etc.,
and I'll incorporate these for eventually doing a V2.

Thanks!
Daniel

On 25.10.18 20:29, Ian Romanick wrote:

I'm going to try to review this more thoroughly for content later.  For
now, I'm going to send a bunch of notes about formatting / Mesa coding
conventions.


On 10/08/2018 04:04 AM, Daniel Schürmann wrote:

---
  src/compiler/nir/meson.build   |   1 +
  src/compiler/nir/nir.h |   2 +
  src/compiler/nir/nir_divergence_analysis.c | 333 +
  3 files changed, 336 insertions(+)
  create mode 100644 src/compiler/nir/nir_divergence_analysis.c

diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index 090aa7a628..aabfeee02c 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -96,6 +96,7 @@ files_libnir = files(
'nir_control_flow_private.h',
'nir_deref.c',
'nir_deref.h',
+  'nir_divergence_analysis.c',
'nir_dominance.c',
'nir_format_convert.h',
'nir_from_ssa.c',
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index e0df95c391..374280a1cc 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -3010,6 +3010,8 @@ void nir_convert_loop_to_lcssa(nir_loop *loop);
   */
  bool nir_convert_from_ssa(nir_shader *shader, bool phi_webs_only);
  
+bool* nir_divergence_analysis(nir_shader *shader);

+


bool *nir_divergence_analysis(nir_shader *shader);


  bool nir_lower_phis_to_regs_block(nir_block *block);
  bool nir_lower_ssa_defs_to_regs_block(nir_block *block);
  bool nir_rematerialize_derefs_in_use_blocks_impl(nir_function_impl *impl);
diff --git a/src/compiler/nir/nir_divergence_analysis.c 
b/src/compiler/nir/nir_divergence_analysis.c
new file mode 100644
index 00..d91f4e55e6
--- /dev/null
+++ b/src/compiler/nir/nir_divergence_analysis.c
@@ -0,0 +1,333 @@
+/*
+ * Copyright © 2018 Valve 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.
+ *
+ * Authors:
+ *Daniel Schürmann (daniel.schuerm...@campus.tu-berlin.de)
+ *


We stopped including "Authors" in the header comment years ago.  GIT
tracks this for us. :)


+ */
+
+#include "nir.h"
+#include "nir_worklist.h"
+
+/* This pass computes for each ssa definition if it is uniform.
+ * That is, the variable has the same value for all invocations
+ * of the group.
+ *
+ * This algorithm implements "The Simple Divergence Analysis" from
+ * Diogo Sampaio, Rafael De Souza, Sylvain Collange, Fernando Magno Quintão 
Pereira.
+ * Divergence Analysis.  ACM Transactions on Programming Languages and Systems 
(TOPLAS),
+ * ACM, 2013, 35 (4), pp.13:1-13:36. <10.1145/2523815>. 
+ */
+
+
+static bool alu_src_is_divergent(bool *divergent, nir_alu_src src, unsigned 
num_input_components)


static bool
alu_src_is_divergent(bool *divergent, nir_alu_src src, unsigned 
num_input_components)

Mesa uses this style so that you can find a function definition by doing

grep -r ^function_name src/'


+{
+   /* If the alu src is swizzled and defined by a vec-instruction,
+* we can check if the originating value is non-divergent. */
+   if (num_input_components == 1 &&
+   src.src.ssa->num_components != 1 &&
+   src.src.parent_instr->type == nir_instr_type_alu) {
+  nir_alu_instr *parent = nir_instr_as_alu(src.src.parent_instr);


Blank line here.


+  switch(parent->op) {
+ case nir_op_vec2:


case should be indente

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/1] util: Change remaining uint32 cache ids to sha1

2018-10-26 Thread Juan A. Suarez Romero
On Fri, 2018-10-26 at 14:52 +1100, Timothy Arceri wrote:
> Pushed. Thanks again!
> 
> Ccing stable in case the Fixes tag isnt enough for this to get picked up 
> (since the previous cache fix this fixes was also backported)
> 

Enqueued for 18.2. I didn't apply cleanly, so I've fixed the conflicts. You can
check the fixed commit here:


https://gitlab.freedesktop.org/mesa/mesa/commit/37ba112d0772cb21ccbf1dd9abcdd3eefe692db7


J.A.
> On 24/10/18 11:51 am, David McFarland wrote:
> > After discussion with Timothy Arceri. disk_cache_get_function_identifier
> > was using only the first byte of the sha1 build-id.  Replace
> > disk_cache_get_function_identifier with implementation from
> > radv_get_build_id.  Instead of writing a uint32_t it now writes to a
> > mesa_sha1.  All drivers using disk_cache_get_function_identifier are
> > updated accordingly.
> > 
> > Reviewed-by: Timothy Arceri 
> > Fixes: 83ea8dd99bb1 ("util: add disk_cache_get_function_identifier()")
> > ---
> >   src/amd/vulkan/radv_device.c | 22 +--
> >   src/gallium/drivers/nouveau/nouveau_screen.c | 29 -
> >   src/gallium/drivers/r600/r600_pipe_common.c  | 43 ++---
> >   src/gallium/drivers/radeonsi/si_pipe.c   | 64 ++--
> >   src/util/disk_cache.h| 16 +++--
> >   5 files changed, 81 insertions(+), 93 deletions(-)
> > 
> > diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> > index cf1132098d..81b558b91c 100644
> > --- a/src/amd/vulkan/radv_device.c
> > +++ b/src/amd/vulkan/radv_device.c
> > @@ -49,24 +49,6 @@
> >   #include "util/debug.h"
> >   #include "util/mesa-sha1.h"
> >   
> > -static bool
> > -radv_get_build_id(void *ptr, struct mesa_sha1 *ctx)
> > -{
> > -   uint32_t timestamp;
> > -
> > -#ifdef HAVE_DL_ITERATE_PHDR
> > -   const struct build_id_note *note = NULL;
> > -   if ((note = build_id_find_nhdr_for_addr(ptr))) {
> > -   _mesa_sha1_update(ctx, build_id_data(note), 
> > build_id_length(note));
> > -   } else
> > -#endif
> > -   if (disk_cache_get_function_timestamp(ptr, ×tamp)) {
> > -   _mesa_sha1_update(ctx, ×tamp, sizeof(timestamp));
> > -   } else
> > -   return false;
> > -   return true;
> > -}
> > -
> >   static int
> >   radv_device_get_cache_uuid(enum radeon_family family, void *uuid)
> >   {
> > @@ -77,8 +59,8 @@ radv_device_get_cache_uuid(enum radeon_family family, 
> > void *uuid)
> > memset(uuid, 0, VK_UUID_SIZE);
> > _mesa_sha1_init(&ctx);
> >   
> > -   if (!radv_get_build_id(radv_device_get_cache_uuid, &ctx) ||
> > -   !radv_get_build_id(LLVMInitializeAMDGPUTargetInfo, &ctx))
> > +   if (!disk_cache_get_function_identifier(radv_device_get_cache_uuid, 
> > &ctx) ||
> > +   !disk_cache_get_function_identifier(LLVMInitializeAMDGPUTargetInfo, 
> > &ctx))
> > return -1;
> >   
> > _mesa_sha1_update(&ctx, &family, sizeof(family));
> > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
> > b/src/gallium/drivers/nouveau/nouveau_screen.c
> > index eb184d3559..d7898ed58f 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_screen.c
> > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c
> > @@ -148,20 +148,21 @@ nouveau_screen_bo_get_handle(struct pipe_screen 
> > *pscreen,
> >   static void
> >   nouveau_disk_cache_create(struct nouveau_screen *screen)
> >   {
> > -   uint32_t mesa_id;
> > -   char *mesa_id_str;
> > -   int res;
> > -
> > -   if (disk_cache_get_function_identifier(nouveau_disk_cache_create,
> > -  &mesa_id)) {
> > -  res = asprintf(&mesa_id_str, "%u", mesa_id);
> > -  if (res != -1) {
> > - screen->disk_shader_cache =
> > -disk_cache_create(nouveau_screen_get_name(&screen->base),
> > -  mesa_id_str, 0);
> > - free(mesa_id_str);
> > -  }
> > -   }
> > +   struct mesa_sha1 ctx;
> > +   unsigned char sha1[20];
> > +   char cache_id[20 * 2 + 1];
> > +
> > +   _mesa_sha1_init(&ctx);
> > +   if (!disk_cache_get_function_identifier(nouveau_disk_cache_create,
> > +   &ctx))
> > +  return;
> > +
> > +   _mesa_sha1_final(&ctx, sha1);
> > +   disk_cache_format_hex_id(cache_id, sha1, 20 * 2);
> > +
> > +   screen->disk_shader_cache =
> > +  disk_cache_create(nouveau_screen_get_name(&screen->base),
> > +cache_id, 0);
> >   }
> >   
> >   int
> > diff --git a/src/gallium/drivers/r600/r600_pipe_common.c 
> > b/src/gallium/drivers/r600/r600_pipe_common.c
> > index 6b581242a1..e7c645611d 100644
> > --- a/src/gallium/drivers/r600/r600_pipe_common.c
> > +++ b/src/gallium/drivers/r600/r600_pipe_common.c
> > @@ -854,27 +854,28 @@ static void r600_disk_cache_create(struct 
> > r600_common_screen *rscreen)
> > if (rscreen->debug_flags & DBG_ALL_SHADERS)
> > return;
> >   
> > -   uint32_t mesa_id;
> > -   if (disk_cache_get_function_identifier(r600_disk_cache_create,

[Mesa-dev] [Bug 108560] Mesa 32 is built without sse

2018-10-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108560

--- Comment #1 from Sergii Romantsov  ---
Patch series for meson and autoconf:
https://patchwork.freedesktop.org/series/51585/

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


[Mesa-dev] [PATCH v1 4/5] autotools: library-dependency when no sse and 32-bit

2018-10-26 Thread Sergii Romantsov
Building of 32bit Mesa may fail if __SSE__ is not specified.
Added missed dependency from libm.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 src/util/Makefile.am | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index d79f2b3..24eeaa8 100644
--- a/src/util/Makefile.am
+++ b/src/util/Makefile.am
@@ -62,6 +62,11 @@ libmesautil_la_LIBADD = \
$(ZLIB_LIBS) \
$(LIBATOMIC_LIBS)
 
+if !SSE_CFLAGS
+libmesautil_la_LIBADD += \
+   -lm
+endif
+
 libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
 libxmlconfig_la_CFLAGS = \
$(DEFINES) \
-- 
2.7.4

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


[Mesa-dev] [PATCH v1 3/5] autotools: compilation flags for sse

2018-10-26 Thread Sergii Romantsov
While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
So it has to be done manually by flag '-msee'.
Added support of such specification to build-system.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 configure.ac | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/configure.ac b/configure.ac
index ab9bdce..f88ac87 100644
--- a/configure.ac
+++ b/configure.ac
@@ -421,13 +421,27 @@ dnl
 dnl Optional flags, check for compiler support
 dnl
 SSE41_CFLAGS="-msse4.1"
+dnl
+dnl x86_64 enables -msse by default, on x86 it required to be enabled manually
+dnl
+SSE_CFLAGS=
+SSE_CXXFLAGS=
+
 dnl Code compiled by GCC with -msse* assumes a 16 byte aligned
 dnl stack, but on x86-32 such alignment is not guaranteed.
 case "$target_cpu" in
 i?86)
 SSE41_CFLAGS="$SSE41_CFLAGS -mstackrealign"
+AX_CHECK_COMPILE_FLAG([-msse],[SSE_CFLAGS="-msse 
-mstackrealign"])
+AC_LANG_PUSH([C++])
+AX_CHECK_COMPILE_FLAG([-msse],[SSE_CXXFLAGS="-msse 
-mstackrealign"])
+AC_LANG_POP([C++])
 ;;
 esac
+AC_SUBST([SSE_CFLAGS], $SSE_CFLAGS)
+AC_SUBST([SSE_CXXFLAGS], $SSE_CXXFLAGS)
+AM_CONDITIONAL([SSE_CFLAGS], [test -n x$SSE_CFLAGS])
+
 save_CFLAGS="$CFLAGS"
 CFLAGS="$SSE41_CFLAGS $CFLAGS"
 AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
-- 
2.7.4

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


[Mesa-dev] [PATCH v1 2/5] meson: specify -msse manually for 32-bit build

2018-10-26 Thread Sergii Romantsov
While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
So it has to be done manually by flag '-msee'.
Added support of such specification to build-system.
That enables optimization for file src/util/rounding.h.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 src/compiler/glsl/meson.build   | 2 +-
 src/compiler/meson.build| 4 ++--
 src/compiler/nir/meson.build| 2 +-
 src/glx/meson.build | 2 +-
 src/intel/blorp/meson.build | 2 +-
 src/intel/common/meson.build| 2 +-
 src/intel/compiler/meson.build  | 4 ++--
 src/intel/isl/meson.build   | 2 +-
 src/intel/tools/meson.build | 2 +-
 src/mesa/drivers/dri/common/meson.build | 4 ++--
 src/mesa/meson.build| 4 ++--
 src/util/meson.build| 2 +-
 12 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/src/compiler/glsl/meson.build b/src/compiler/glsl/meson.build
index 71b4c42..1b96bdc 100644
--- a/src/compiler/glsl/meson.build
+++ b/src/compiler/glsl/meson.build
@@ -215,7 +215,7 @@ libglsl = static_library(
   [files_libglsl, glsl_parser, glsl_lexer_cpp, ir_expression_operation_h,
ir_expression_operation_strings_h, ir_expression_operation_constant_h],
   c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
-  cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
+  cpp_args : [cpp_vis_args, cpp_msvc_compat_args, cpp_sse_args],
   link_with : libglcpp,
   include_directories : [inc_common, inc_compiler, inc_nir],
   dependencies : idep_nir,
diff --git a/src/compiler/meson.build b/src/compiler/meson.build
index 0f8f3c1..8ae49c4 100644
--- a/src/compiler/meson.build
+++ b/src/compiler/meson.build
@@ -48,8 +48,8 @@ libcompiler = static_library(
   'compiler',
   [files_libcompiler, ir_expression_operation_h],
   include_directories : [inc_mapi, inc_mesa, inc_compiler, inc_common],
-  c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
-  cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
+  c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args, c_sse_args],
+  cpp_args : [cpp_vis_args, cpp_msvc_compat_args, cpp_sse_args],
   dependencies : [dep_valgrind],
   build_by_default : false,
 )
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index d8f6564..528d8f7 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -215,7 +215,7 @@ libnir = static_library(
nir_opcodes_h, nir_constant_expressions_c, nir_builder_opcodes_h,
vtn_gather_types_c, nir_intrinsics_c, nir_intrinsics_h],
   include_directories : [inc_common, inc_compiler, 
include_directories('../spirv')],
-  c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
+  c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args, c_sse_args],
   link_with : libcompiler,
   build_by_default : false,
 )
diff --git a/src/glx/meson.build b/src/glx/meson.build
index dd8ba60..1d4327f 100644
--- a/src/glx/meson.build
+++ b/src/glx/meson.build
@@ -146,7 +146,7 @@ libglx = static_library(
   [files_libglx, glx_generated],
   include_directories : [inc_common, inc_glapi, inc_loader, inc_gl_internal],
   c_args : [
-c_vis_args, gl_lib_cargs,
+c_vis_args, gl_lib_cargs, c_sse_args,
 '-DGL_LIB_NAME="lib@0@.so.@1@"'.format(gl_lib_name, 
gl_lib_version.split('.')[0]),
   ],
   link_with : [
diff --git a/src/intel/blorp/meson.build b/src/intel/blorp/meson.build
index c1201b0..490ce6f 100644
--- a/src/intel/blorp/meson.build
+++ b/src/intel/blorp/meson.build
@@ -32,6 +32,6 @@ libblorp = static_library(
   'blorp',
   files_libblorp,
   include_directories : [inc_common, inc_intel],
-  c_args : [c_vis_args, no_override_init_args],
+  c_args : [c_vis_args, no_override_init_args, c_sse_args],
   dependencies : idep_nir_headers,
 )
diff --git a/src/intel/common/meson.build b/src/intel/common/meson.build
index 332e978..c452a40 100644
--- a/src/intel/common/meson.build
+++ b/src/intel/common/meson.build
@@ -41,7 +41,7 @@ libintel_common = static_library(
   ['intel_common', genX_xml_h],
   files_libintel_common,
   include_directories : [inc_common, inc_intel],
-  c_args : [c_vis_args, no_override_init_args],
+  c_args : [c_vis_args, no_override_init_args, c_sse_args],
   link_with : [libisl],
   dependencies : [dep_expat, dep_libdrm, dep_thread],
 )
diff --git a/src/intel/compiler/meson.build b/src/intel/compiler/meson.build
index 3cdeb62..a6fd188 100644
--- a/src/intel/compiler/meson.build
+++ b/src/intel/compiler/meson.build
@@ -134,8 +134,8 @@ libintel_compiler = static_library(
   'intel_compiler',
   [libintel_compiler_files, brw_nir_trig, ir_expression_operation_h],
   include_directories : [inc_common, inc_intel],
-  c_args : [c_vis_args, no_override_init_args],
-  cpp_args : [cpp_vis_args],
+  c_args : [c_vis_args, no_override_init_args, c_sse_args],
+  cpp_args : [cpp_vis_args, cpp

[Mesa-dev] [PATCH v1 1/5] meson: compilation flags for sse

2018-10-26 Thread Sergii Romantsov
While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
So it has to be done manually by flag '-msee'.
Added support of such specification to build-system.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 meson.build | 12 
 1 file changed, 12 insertions(+)

diff --git a/meson.build b/meson.build
index 505cc6c..f335434 100644
--- a/meson.build
+++ b/meson.build
@@ -806,6 +806,12 @@ if cc.has_argument('-fvisibility=hidden')
   c_vis_args += '-fvisibility=hidden'
 endif
 
+c_sse_args = []
+# x86_64 enables -msse by default, on x86 it required to be enabled manually
+if host_machine.cpu_family() == 'x86' and cc.has_argument('-msse')
+  c_sse_args += ['-msse', '-mstackrealign']
+endif
+
 # Check for generic C++ arguments
 cpp_args = []
 foreach a : ['-Wall', '-fno-math-errno', '-fno-trapping-math',
@@ -836,6 +842,12 @@ if cpp.has_argument('-fvisibility=hidden')
   cpp_vis_args += '-fvisibility=hidden'
 endif
 
+cpp_sse_args = []
+# x86_64 enables -msse by default, on x86 it required to be enabled manually
+if host_machine.cpu_family() == 'x86' and cpp.has_argument('-msse')
+  cpp_sse_args += ['-msse', '-mstackrealign']
+endif
+
 # Check for C and C++ arguments for MSVC2013 compatibility. These are only used
 # in parts of the mesa code base that need to compile with old versions of
 # MSVC, mainly common code
-- 
2.7.4

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


[Mesa-dev] [PATCH v1 5/5] autotools: specify -msse manually for 32-bit build

2018-10-26 Thread Sergii Romantsov
While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
So it has to be done manually by flag '-msee'.
Added support of such specification to build-system.
That enables optimization for file src/util/rounding.h.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 src/Makefile.am | 2 +-
 src/compiler/Makefile.am| 6 --
 src/glx/Makefile.am | 3 ++-
 src/intel/Makefile.am   | 6 --
 src/intel/Makefile.common.am| 2 +-
 src/mesa/Makefile.am| 7 +--
 src/mesa/drivers/dri/common/Makefile.am | 3 ++-
 src/util/Makefile.am| 3 ++-
 8 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index c4fcd8a..cff6fc3 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -113,7 +113,7 @@ EXTRA_DIST += \
getopt hgl SConscript \
$(top_srcdir)/include/GL/mesa_glinterop.h
 
-AM_CFLAGS = $(VISIBILITY_CFLAGS)
+AM_CFLAGS = $(VISIBILITY_CFLAGS) $(SSE_CFLAGS)
 AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS)
 
 AM_CPPFLAGS = \
diff --git a/src/compiler/Makefile.am b/src/compiler/Makefile.am
index 73435a3..3ad87ce 100644
--- a/src/compiler/Makefile.am
+++ b/src/compiler/Makefile.am
@@ -43,11 +43,13 @@ AM_CPPFLAGS = \
 AM_CFLAGS = \
$(VISIBILITY_CFLAGS) \
$(WNO_OVERRIDE_INIT) \
-   $(MSVC2013_COMPAT_CFLAGS)
+   $(MSVC2013_COMPAT_CFLAGS) \
+   $(SSE_CFLAGS)
 
 AM_CXXFLAGS = \
$(VISIBILITY_CXXFLAGS) \
-   $(MSVC2013_COMPAT_CXXFLAGS)
+   $(MSVC2013_COMPAT_CXXFLAGS) \
+   $(SSE_CXXFLAGS)
 
 noinst_LTLIBRARIES = libcompiler.la
 
diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
index 8f9d80c..cb17c0f 100644
--- a/src/glx/Makefile.am
+++ b/src/glx/Makefile.am
@@ -45,7 +45,8 @@ AM_CFLAGS = \
$(LIBDRM_CFLAGS) \
$(DRI2PROTO_CFLAGS) \
$(GLPROTO_CFLAGS) \
-   $(X11_INCLUDES)
+   $(X11_INCLUDES) \
+   $(SSE_CFLAGS)
 
 lib_LTLIBRARIES = lib@GL_LIB@.la
 
diff --git a/src/intel/Makefile.am b/src/intel/Makefile.am
index 95764b8..5f37a2a 100644
--- a/src/intel/Makefile.am
+++ b/src/intel/Makefile.am
@@ -44,10 +44,12 @@ AM_CPPFLAGS = \
 
 AM_CFLAGS = \
$(VISIBILITY_CFLAGS) \
-   $(WNO_OVERRIDE_INIT)
+   $(WNO_OVERRIDE_INIT) \
+   $(SSE_CFLAGS)
 
 AM_CXXFLAGS = \
-   $(VISIBILITY_CXXFLAGS)
+   $(VISIBILITY_CXXFLAGS) \
+   $(SSE_CXXFLAGS)
 
 MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D)
 PYTHON_GEN = $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS)
diff --git a/src/intel/Makefile.common.am b/src/intel/Makefile.common.am
index 443cefc..3f9415e 100644
--- a/src/intel/Makefile.common.am
+++ b/src/intel/Makefile.common.am
@@ -21,7 +21,7 @@
 
 noinst_LTLIBRARIES += common/libintel_common.la
 
-common_libintel_common_la_CFLAGS = $(AM_CFLAGS) $(LIBDRM_CFLAGS) 
$(EXPAT_CFLAGS)
+common_libintel_common_la_CFLAGS = $(AM_CFLAGS) $(LIBDRM_CFLAGS) 
$(EXPAT_CFLAGS) $(SSE_CFLAGS)
 common_libintel_common_la_SOURCES = $(COMMON_FILES)
 common_libintel_common_la_LIBADD = $(EXPAT_LIBS)
 
diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
index 195e440..b97f58e 100644
--- a/src/mesa/Makefile.am
+++ b/src/mesa/Makefile.am
@@ -114,11 +114,14 @@ AM_CFLAGS = \
$(VDPAU_CFLAGS) \
$(LLVM_CFLAGS) \
$(VISIBILITY_CFLAGS) \
-   $(MSVC2013_COMPAT_CFLAGS)
+   $(MSVC2013_COMPAT_CFLAGS) \
+   $(SSE_CFLAGS)
+
 AM_CXXFLAGS = \
$(LLVM_CFLAGS) \
$(VISIBILITY_CXXFLAGS) \
-   $(MSVC2013_COMPAT_CXXFLAGS)
+   $(MSVC2013_COMPAT_CXXFLAGS) \
+   $(SSE_CXXFLAGS)
 
 ARCH_LIBS =
 
diff --git a/src/mesa/drivers/dri/common/Makefile.am 
b/src/mesa/drivers/dri/common/Makefile.am
index 192b364..d653340 100644
--- a/src/mesa/drivers/dri/common/Makefile.am
+++ b/src/mesa/drivers/dri/common/Makefile.am
@@ -33,7 +33,8 @@ AM_CFLAGS = \
-I$(top_builddir)/src/util/ \
$(LIBDRM_CFLAGS) \
$(DEFINES) \
-   $(VISIBILITY_CFLAGS)
+   $(VISIBILITY_CFLAGS) \
+   $(SSE_CFLAGS)
 
 noinst_LTLIBRARIES = \
libdricommon.la \
diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index 24eeaa8..9f7fe98 100644
--- a/src/util/Makefile.am
+++ b/src/util/Makefile.am
@@ -50,7 +50,8 @@ libmesautil_la_CPPFLAGS = \
-I$(top_srcdir)/src/gallium/auxiliary \
$(VISIBILITY_CFLAGS) \
$(MSVC2013_COMPAT_CFLAGS) \
-   $(ZLIB_CFLAGS)
+   $(ZLIB_CFLAGS) \
+   $(SSE_CFLAGS)
 
 libmesautil_la_SOURCES = \
$(MESA_UTIL_FILES) \
-- 
2.7.4

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


[Mesa-dev] [Bug 108560] Mesa 32 is built without sse

2018-10-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108560

Bug ID: 108560
   Summary: Mesa 32 is built without sse
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: sergii.romant...@globallogic.com
QA Contact: mesa-dev@lists.freedesktop.org

While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
So it has to be done manually by flag '-msee'.

Additionally for autotools is missed library-dependency that causes
impossibility to build

-- 
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] anv: Fix sanitization of stencil state when the depth test is disabled

2018-10-26 Thread Alex Smith
Good point, I didn't notice they were both now doing the same thing. Merged
them together and pushed.

On Thu, 25 Oct 2018 at 18:00, Jason Ekstrand  wrote:

> Maybe we should just roll the depthTestEnable check in with the ds_aspects
> & VK_IMAGE_ASPECT_DEPTH_BIT check right below it.  In either case,
>
> Reviewed-by: Jason Ekstrand 
>
> On Thu, Oct 25, 2018 at 5:25 AM Alex Smith 
> wrote:
>
>> When depth testing is disabled, we shouldn't pay attention to the
>> specified depthCompareOp, and just treat it as always passing. Before,
>> if the depth test is disabled, but depthCompareOp is VK_COMPARE_OP_NEVER
>> (e.g. from the app having zero-initialized the structure), then
>> sanitize_stencil_face() would have incorrectly changed passOp to
>> VK_STENCIL_OP_KEEP.
>>
>> Signed-off-by: Alex Smith 
>> ---
>>  src/intel/vulkan/genX_pipeline.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/intel/vulkan/genX_pipeline.c
>> b/src/intel/vulkan/genX_pipeline.c
>> index 33f1f7832a..877a9fb850 100644
>> --- a/src/intel/vulkan/genX_pipeline.c
>> +++ b/src/intel/vulkan/genX_pipeline.c
>> @@ -755,9 +755,13 @@
>> sanitize_ds_state(VkPipelineDepthStencilStateCreateInfo *state,
>>  {
>> *stencilWriteEnable = state->stencilTestEnable;
>>
>> -   /* If the depth test is disabled, we won't be writing anything. */
>> -   if (!state->depthTestEnable)
>> +   /* If the depth test is disabled, we won't be writing anything. Make
>> sure
>> +* we treat it as always passing later on as well.
>> +*/
>> +   if (!state->depthTestEnable) {
>>state->depthWriteEnable = false;
>> +  state->depthCompareOp = VK_COMPARE_OP_ALWAYS;
>> +   }
>>
>> /* The Vulkan spec requires that if either depth or stencil is not
>> present,
>>  * the pipeline is to act as if the test silently passes.
>> --
>> 2.14.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 107765] [regression] Batman Arkham City crashes with DXVK under wine

2018-10-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107765

Samuel Pitoiset  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #18 from Samuel Pitoiset  ---
Thanks for confirming.

Should be fixed with
https://cgit.freedesktop.org/mesa/mesa/commit/?id=79bbdf8e45f0961b800279afadb4bb74129d7034

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


Re: [Mesa-dev] [PATCH v3 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

2018-10-26 Thread andrey simiklit
Hi,

Could you please help me with a push. I don't have a right for it :-)

Thanks,
Andrii.

On Thu, Oct 11, 2018 at 9:22 PM Jordan Justen 
wrote:

> On 2018-10-11 03:01:56, andrey simiklit wrote:
> > Hello,
> >
> > Thanks for reviewing.
> > Please find my comment below.
> >
> > On Thu, Oct 11, 2018 at 12:37 AM Jordan Justen <
> jordan.l.jus...@intel.com>
> > wrote:
> >
> > > On 2018-09-12 09:05:44,  wrote:
> > > > From: Andrii Simiklit 
> > > >
> > > > There's no point reverting to the last saved point if that save
> point is
> > > > the empty batch, we will just repeat ourselves.
> > > >
> > > > CC: Chris Wilson 
> > > > Fixes: 3faf56ffbdeb "intel: Add an interface for saving/restoring
> > > >  the batchbuffer state."
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
> > > > ---
> > > >  src/mesa/drivers/dri/i965/brw_compute.c   | 3 ++-
> > > >  src/mesa/drivers/dri/i965/brw_draw.c  | 3 ++-
> > > >  src/mesa/drivers/dri/i965/genX_blorp_exec.c   | 3 ++-
> > > >  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 7 +++
> > > >  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 1 +
> > > >  5 files changed, 14 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
> > > b/src/mesa/drivers/dri/i965/brw_compute.c
> > > > index de08fc3..5c8e3a5 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_compute.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_compute.c
> > > > @@ -167,7 +167,7 @@ static void
> > > >  brw_dispatch_compute_common(struct gl_context *ctx)
> > > >  {
> > > > struct brw_context *brw = brw_context(ctx);
> > > > -   bool fail_next = false;
> > > > +   bool fail_next;
> > > >
> > > > if (!_mesa_check_conditional_render(ctx))
> > > >return;
> > > > @@ -185,6 +185,7 @@ brw_dispatch_compute_common(struct gl_context
> *ctx)
> > > > intel_batchbuffer_require_space(brw, 600);
> > > > brw_require_statebuffer_space(brw, 2500);
> > > > intel_batchbuffer_save_state(brw);
> > > > +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
> > > >
> > > >   retry:
> > > > brw->batch.no_wrap = true;
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> > > b/src/mesa/drivers/dri/i965/brw_draw.c
> > > > index 8536c04..19ee396 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_draw.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> > > > @@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> > > >  {
> > > > struct brw_context *brw = brw_context(ctx);
> > > > const struct gen_device_info *devinfo = &brw->screen->devinfo;
> > > > -   bool fail_next = false;
> > > > +   bool fail_next;
> > > >
> > > > /* Flag BRW_NEW_DRAW_CALL on every draw.  This allows us to have
> > > >  * atoms that happen on every draw call.
> > > > @@ -898,6 +898,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> > > > intel_batchbuffer_require_space(brw, 1500);
> > > > brw_require_statebuffer_space(brw, 2400);
> > > > intel_batchbuffer_save_state(brw);
> > > > +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
> > >
> > > It seems like this will cause the WARN_ONCE to be hit incorrectly.
> > > What about adding a 'bool empty_state', and checking that before
> > > fail_next in the code that follows. If empty_state is true, I guess
> > > you want to flush, but not emit the WARN_ONCE?
> > >
> >
> > We just predict that first step (non-failed branch without WARN_ONCE)
> > which should make the batch an empty will not make sense
> > because it is already empty and we immediately pass into a failed branch.
> > All WARN_ONCE calls are conditional ('ret == -ENOSPC') there.
> > I guess that if we came to the failed branch (I mean branch which
> contains
> > WARN_ONCE)
> > then regardless a reason (due to 'empty state' or 'failed try') we rather
> > should log a warning
> > that there isn't left space to transfer a batch if it is true.
>
> Oh. You are right. It sounds like a reasonable warning message for
> that case. So, there's no need to change the patch.
>
> -Jordan
>
> >
> > What do you think about it?
> > Should we log a warning if calls of
> > 'brw_upload_render_state' + 'brw_emit_prim' functions
> > for an empty batch lead to ENOSPC error?
> >
> > Anyway if it is unacceptable for you
> > I can implement the solution which you suggested.
> >
> >
> > >
> > > With that change,
> > > series Reviewed-by: Jordan Justen 
> > >
> > > As always, it could be nice to get an r-b, or acked-by from Ken. :)
> > >
> > > -Jordan
> > >
> > > >
> > > > if (brw->num_instances != prim->num_instances ||
> > > > brw->basevertex != prim->basevertex ||
> > > > diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> > > b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> > > > index 34bfcad..fd9ce93 100644
> > > > --- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> > > > +++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> > > > @@ -268,7 +268,7 @@ genX(blorp_exec)(struct