Re: [Mesa-dev] [PATCH] util/disk_cache: remove function stubs

[Tapani Pälli]

On 02/10/2017 03:38 AM, Timothy Arceri wrote:

The option to disable shader cache was removed from the build options
when we imported a sha1 implementation into Mesa.


Have the issues mentioned in 9f8dc3bf03ec825bae7041858dda6ca2e9a34363 
been fixed?



Cc: Emil Velikov 
---
 src/util/disk_cache.h | 50 --
 1 file changed, 50 deletions(-)

diff --git a/src/util/disk_cache.h b/src/util/disk_cache.h
index e429db5..4ff1da5 100644
--- a/src/util/disk_cache.h
+++ b/src/util/disk_cache.h
@@ -38,10 +38,6 @@ typedef uint8_t cache_key[CACHE_KEY_SIZE];

 struct disk_cache;

-/* Provide inlined stub functions if the shader cache is disabled. */
-
-#ifdef ENABLE_SHADER_CACHE
-
 /**
  * Create a new cache object.
  *
@@ -137,52 +133,6 @@ disk_cache_put_key(struct disk_cache *cache, cache_key 
key);
 bool
 disk_cache_has_key(struct disk_cache *cache, cache_key key);

-#else
-
-static inline struct disk_cache *
-disk_cache_create(const char *gpu_name, const char *mesa_version)
-{
-   return NULL;
-}
-
-static inline void
-disk_cache_destroy(struct disk_cache *cache) {
-   return;
-}
-
-static inline void
-disk_cache_put(struct disk_cache *cache, cache_key key,
-  const void *data, size_t size)
-{
-   return;
-}
-
-static inline void
-disk_cache_remove(struct program_cache *cache, cache_key key)
-{
-   return;
-}
-
-static inline uint8_t *
-disk_cache_get(struct disk_cache *cache, cache_key key, size_t *size)
-{
-   return NULL;
-}
-
-static inline void
-disk_cache_put_key(struct disk_cache *cache, cache_key key)
-{
-   return;
-}
-
-static inline bool
-disk_cache_has_key(struct disk_cache *cache, cache_key key)
-{
-   return false;
-}
-
-#endif /* ENABLE_SHADER_CACHE */
-
 #ifdef __cplusplus
 }
 #endif


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

[Mesa-dev] [PATCH] nv50/ir: convert an ATOM.EXCH without a destination into a store

[Ilia Mirkin]

On SM35 there does not appear to be a way to emit a ATOM.EXCH with a
null destination. This should be functionally equivalent to a plain
store however, so just do that.

Fixes GL45-CTS.compute_shader.atomic-case2 on SM35.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index d79e87d..79403c9 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -3549,6 +3549,11 @@ DeadCodeElim::visit(BasicBlock *bb)
  i->op == OP_SUREDP ||
  i->op == OP_SUREDB) {
 i->setDef(0, NULL);
+if (i->op == OP_ATOM && i->subOp == NV50_IR_SUBOP_ATOM_EXCH) {
+   i->cache = CACHE_CV;
+   i->op = OP_STORE;
+   i->subOp = 0;
+}
  } else if (i->op == OP_LOAD && i->subOp == NV50_IR_SUBOP_LOAD_LOCKED) 
{
 i->setDef(0, i->getDef(1));
 i->setDef(1, NULL);
-- 
2.10.2

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

Re: [Mesa-dev] [PATCH 3/4] util: Change util/set to use quadratic probing

[Connor Abbott]

On Thu, Feb 9, 2017 at 4:16 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
> Hello
>
> IMPORTANT NOTE: Using the uint32_t data type, quad_hash*quad_hash will
> overflow as soon as the hash table has more than 2**16=65536=64K
> elements. To enable more than 64K elements in hash table, the data
> types need to be changed to uint64_t - unfortunately uint64_t
> arithmetic operations will slow down the hash table in 32-bit OpenGL
> apps.

This actually doesn't matter, since at the end of the day we only need
the result modulo the table size which is a power of two -- even if
the multiplication overflows, the lowest n bits (if the table size is
2^n) are still correct, so we get the same answer as long as we use at
least n bits.

>
> OPTIMIZATION: All "} while (hash_address != start_hash_address);" can
> be replaced with "} while (1);" assuming that the hash table always
> contains at least several free/unallocated entries. This optimization
> applies both to current mesa-git and to the quadratic probing patch.
> For quadratic probing this optimization works if the statement "values
> of h(k,i) for i in [0,m-1] are all distinct" at
> https://en.wikipedia.org/wiki/Quadratic_probing is correct.
>
> Jan
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: detect command buffers that do no work and drop them

[Jason Ekstrand]

On Feb 9, 2017 8:25 PM, "Dave Airlie"  wrote:

From: Dave Airlie 

If a buffer is just full of flushes we flush things on command
buffer submission, so don't bother submitting these.

This will reduce some CPU overhead on dota2, which submits a fair
few command streams that don't end up drawing anything.


I wrote basically the same patch for our driver earlier this year when I
was preparing for our GDC Dota 2 demo.  I noticed an improvement at the
time but I'm pretty sure it was just because of the stalls we had due to
relocations.  Now that those stalls are gone, I'm not convinced it would do
much.  Did you actually measure a performance improvement or was this just
a little CPU usage reduction?

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_cmd_buffer.c  |  3 +++
 src/amd/vulkan/radv_device.c  | 14 +-
 src/amd/vulkan/radv_meta_buffer.c |  1 +
 src/amd/vulkan/radv_private.h |  2 ++
 src/amd/vulkan/si_cmd_buffer.c|  2 +-
 5 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_
buffer.c
index f281f33..25b1bd6 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1277,6 +1277,7 @@ radv_cmd_buffer_flush_state(struct radv_cmd_buffer
*cmd_buffer)
MAYBE_UNUSED unsigned cdw_max = radeon_check_space(cmd_buffer-
>device->ws,
   cmd_buffer->cs,
4096);

+   cmd_buffer->no_draws = false;
if ((cmd_buffer->state.vertex_descriptors_dirty ||
cmd_buffer->state.vb_dirty) &&
cmd_buffer->state.pipeline->num_vertex_attribs) {
unsigned vb_offset;
@@ -1592,6 +1593,7 @@ static void  radv_reset_cmd_buffer(struct
radv_cmd_buffer *cmd_buffer)
cmd_buffer->record_fail = false;

cmd_buffer->ring_offsets_idx = -1;
+   cmd_buffer->no_draws = true;
 }

 VkResult radv_ResetCommandBuffer(
@@ -2423,6 +2425,7 @@ void radv_CmdDrawIndexedIndirectCountAMD(
 static void
 radv_flush_compute_state(struct radv_cmd_buffer *cmd_buffer)
 {
+   cmd_buffer->no_draws = false;
radv_emit_compute_pipeline(cmd_buffer);
radv_flush_descriptors(cmd_buffer, cmd_buffer->state.compute_
pipeline,
   VK_SHADER_STAGE_COMPUTE_BIT);
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 8a54a2a..fddada4 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1448,21 +1448,25 @@ VkResult radv_QueueSubmit(
cs_array = malloc(sizeof(struct radeon_winsys_cs *) *
pSubmits[i].
commandBufferCount);

+   int draw_cmds_count = 0;
for (uint32_t j = 0; j < pSubmits[i].commandBufferCount;
j++) {
RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer,
 pSubmits[i].pCommandBuffers[j]);
assert(cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_
PRIMARY);
-
-   cs_array[j] = cmd_buffer->cs;
+   if (cmd_buffer->no_draws == true) {
+   continue;
+   }
+   cs_array[draw_cmds_count] = cmd_buffer->cs;
+   draw_cmds_count++;
if ((cmd_buffer->usage_flags &
VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT))
can_patch = false;
}

-   for (uint32_t j = 0; j < pSubmits[i].commandBufferCount; j
+= advance) {
+   for (uint32_t j = 0; j < draw_cmds_count; j += advance) {
advance = MIN2(max_cs_submission,
-  pSubmits[i].commandBufferCount - j);
+  draw_cmds_count - j);
bool b = j == 0;
-   bool e = j + advance == pSubmits[i].
commandBufferCount;
+   bool e = j + advance == draw_cmds_count;

if (queue->device->trace_bo)
*queue->device->trace_id_ptr = 0;
diff --git a/src/amd/vulkan/radv_meta_buffer.c b/src/amd/vulkan/radv_meta_
buffer.c
index cd2973f..4857d3d 100644
--- a/src/amd/vulkan/radv_meta_buffer.c
+++ b/src/amd/vulkan/radv_meta_buffer.c
@@ -523,6 +523,7 @@ void radv_CmdUpdateBuffer(
assert(!(dataSize & 3));
assert(!(va & 3));

+   cmd_buffer->no_draws = false;
if (dataSize < 4096) {
cmd_buffer->device->ws->cs_add_buffer(cmd_buffer->cs,
dst_buffer->bo, 8);

diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 25ed5de..9a88ce0 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -750,6 +750,8 @@ struct radv_cmd_buffer {
uint32_t gsvs_ring_size_needed;

int ring_offsets_idx; /* just used 

Re: [Mesa-dev] [PATCH 00/11] Gallium common uploaders (v2)

[Charmaine Lee]

Series tested with vmware svga driver. Changes looks good.

Tested-by: Charmaine Lee 

From: mesa-dev  on behalf of Marek 
Olšák 
Sent: Wednesday, February 8, 2017 4:11:01 PM
To: mesa-dev@lists.freedesktop.org
Subject: [Mesa-dev] [PATCH 00/11] Gallium common uploaders (v2)

Hi,

Since the last version, I added pipe_context::const_uploader and
documentation.

Changed patches: 1, 3, 9.
New patch: 11.

Please review.

Thanks,
Marek

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=Ang1qmMo4GwCmRUnLE-f31kqPa6AOnoS-OAMUzQyM0M=XSJrU78OKHut9MP5JzTo6E_q9zUryi8toIq7t-vPBMs=QXqaX6b025NySDn7FRrLOOs6w2aXs4qV_Yb47UZSODg=
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: detect command buffers that do no work and drop them

[Dave Airlie]

From: Dave Airlie 

If a buffer is just full of flushes we flush things on command
buffer submission, so don't bother submitting these.

This will reduce some CPU overhead on dota2, which submits a fair
few command streams that don't end up drawing anything.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_cmd_buffer.c  |  3 +++
 src/amd/vulkan/radv_device.c  | 14 +-
 src/amd/vulkan/radv_meta_buffer.c |  1 +
 src/amd/vulkan/radv_private.h |  2 ++
 src/amd/vulkan/si_cmd_buffer.c|  2 +-
 5 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index f281f33..25b1bd6 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1277,6 +1277,7 @@ radv_cmd_buffer_flush_state(struct radv_cmd_buffer 
*cmd_buffer)
MAYBE_UNUSED unsigned cdw_max = 
radeon_check_space(cmd_buffer->device->ws,
   cmd_buffer->cs, 
4096);
 
+   cmd_buffer->no_draws = false;
if ((cmd_buffer->state.vertex_descriptors_dirty || 
cmd_buffer->state.vb_dirty) &&
cmd_buffer->state.pipeline->num_vertex_attribs) {
unsigned vb_offset;
@@ -1592,6 +1593,7 @@ static void  radv_reset_cmd_buffer(struct radv_cmd_buffer 
*cmd_buffer)
cmd_buffer->record_fail = false;
 
cmd_buffer->ring_offsets_idx = -1;
+   cmd_buffer->no_draws = true;
 }
 
 VkResult radv_ResetCommandBuffer(
@@ -2423,6 +2425,7 @@ void radv_CmdDrawIndexedIndirectCountAMD(
 static void
 radv_flush_compute_state(struct radv_cmd_buffer *cmd_buffer)
 {
+   cmd_buffer->no_draws = false;
radv_emit_compute_pipeline(cmd_buffer);
radv_flush_descriptors(cmd_buffer, cmd_buffer->state.compute_pipeline,
   VK_SHADER_STAGE_COMPUTE_BIT);
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 8a54a2a..fddada4 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1448,21 +1448,25 @@ VkResult radv_QueueSubmit(
cs_array = malloc(sizeof(struct radeon_winsys_cs *) *
pSubmits[i].commandBufferCount);
 
+   int draw_cmds_count = 0;
for (uint32_t j = 0; j < pSubmits[i].commandBufferCount; j++) {
RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer,
 pSubmits[i].pCommandBuffers[j]);
assert(cmd_buffer->level == 
VK_COMMAND_BUFFER_LEVEL_PRIMARY);
-
-   cs_array[j] = cmd_buffer->cs;
+   if (cmd_buffer->no_draws == true) {
+   continue;
+   }
+   cs_array[draw_cmds_count] = cmd_buffer->cs;
+   draw_cmds_count++;
if ((cmd_buffer->usage_flags & 
VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT))
can_patch = false;
}
 
-   for (uint32_t j = 0; j < pSubmits[i].commandBufferCount; j += 
advance) {
+   for (uint32_t j = 0; j < draw_cmds_count; j += advance) {
advance = MIN2(max_cs_submission,
-  pSubmits[i].commandBufferCount - j);
+  draw_cmds_count - j);
bool b = j == 0;
-   bool e = j + advance == pSubmits[i].commandBufferCount;
+   bool e = j + advance == draw_cmds_count;
 
if (queue->device->trace_bo)
*queue->device->trace_id_ptr = 0;
diff --git a/src/amd/vulkan/radv_meta_buffer.c 
b/src/amd/vulkan/radv_meta_buffer.c
index cd2973f..4857d3d 100644
--- a/src/amd/vulkan/radv_meta_buffer.c
+++ b/src/amd/vulkan/radv_meta_buffer.c
@@ -523,6 +523,7 @@ void radv_CmdUpdateBuffer(
assert(!(dataSize & 3));
assert(!(va & 3));
 
+   cmd_buffer->no_draws = false;
if (dataSize < 4096) {
cmd_buffer->device->ws->cs_add_buffer(cmd_buffer->cs, 
dst_buffer->bo, 8);
 
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 25ed5de..9a88ce0 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -750,6 +750,8 @@ struct radv_cmd_buffer {
uint32_t gsvs_ring_size_needed;
 
int ring_offsets_idx; /* just used for verification */
+
+   bool no_draws;
 };
 
 struct radv_image;
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index 1c99b22..b94c1f1 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -828,7 +828,7 @@ static void si_emit_cp_dma_clear_buffer(struct 
radv_cmd_buffer *cmd_buffer,
 static void si_cp_dma_prepare(struct radv_cmd_buffer *cmd_buffer, uint64_t 
byte_count,
 

[Mesa-dev] [PATCH] tgsi: fix memory leak in tgsi sanity check

[Dave Airlie]

From: Dave Airlie 

This just fixes this without repeating the code.

Reported-by: Li Qiang
Signed-off-by: Dave Airlie 
---
 src/gallium/auxiliary/tgsi/tgsi_sanity.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_sanity.c 
b/src/gallium/auxiliary/tgsi/tgsi_sanity.c
index f867925..239a2c9 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_sanity.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_sanity.c
@@ -559,6 +559,7 @@ tgsi_sanity_check(
const struct tgsi_token *tokens )
 {
struct sanity_check_ctx ctx;
+   boolean retval;
 
ctx.iter.prolog = prolog;
ctx.iter.iterate_instruction = iter_instruction;
@@ -580,11 +581,12 @@ tgsi_sanity_check(
ctx.implied_array_size = 0;
ctx.print = debug_get_option_print_sanity();
 
-   if (!tgsi_iterate_shader( tokens,  ))
-  return FALSE;
-
+   retval = tgsi_iterate_shader( tokens,  );
regs_hash_destroy(ctx.regs_decl);
regs_hash_destroy(ctx.regs_used);
regs_hash_destroy(ctx.regs_ind_used);
+   if (retval == FALSE)
+  return FALSE;
+
return ctx.errors == 0;
 }
-- 
2.9.3

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

Re: [Mesa-dev] [PATCHv3 09/20] i965/fs: Get 64-bit indirect moves working on IVB.

[Francisco Jerez]

Francisco Jerez  writes:

> ---
> This replaces "[PATCH v2 09/20] i965/fs: indirect addressing with
> doubles is not supported in IVB/BYT".
>

Note that some of the fp64 indirect addressing test-cases still fail on
IVB even with this patch applied, but the reason doesn't seem to have
anything to do with indirect addressing.  Apparently the remaining
failures are caused by illegal code like:

| sel(8)  g30<1>D g9<0,2,1>DF g8.3<0,2,1>DF   { align1 1Q };

The problem is that the SEL instruction doesn't support most datatype
conversions, so this leads to data corruption on at least IVB.
According to the hardware docs, the only valid destination type of SEL
is DF if the execution type is DF, and F (or HF on CHV+) if the
execution type is F.  Integer 16 or 32-bit execution types seem to allow
converting to other single-precision integer types.

I'm not sure why we haven't seen this cause massive breakage on HSW+,
but I think we need some sort of legalization pass to do the type
conversion in a separate MOV for any instruction with an invalid
destination conversion.  You may be able to do it within the d2x pass
but then it would make sense to rename it to something more appropriate
like destination conversion lowering (lower_cvt? :P).

In addition there seem to be other issues with your d2x lowering code
(I'm bringing this up here because you don't seem to have sent the d2x
changes for review to the mailing list yet) -- It removes the original
instruction and creates a new one with the same opcode and first few
sources, which will miscompile the program if the original instruction
had a larger number of sources or any other instruction controls set.  I
suggest you modify the original instruction in-place to point it to the
temporary you've allocated, and then copy the data into the original
destination by using a strided move.

> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 27 --
>  1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> index ea4a3fe1399..0e2dbe23571 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> @@ -440,7 +440,7 @@ fs_generator::generate_mov_indirect(fs_inst *inst,
>brw_MOV(p, dst, reg);
> } else {
>/* Prior to Broadwell, there are only 8 address registers. */
> -  assert(inst->exec_size == 8 || devinfo->gen >= 8);
> +  assert(inst->exec_size <= 8 || devinfo->gen >= 8);
>  
>/* We use VxH indirect addressing, clobbering a0.0 through a0.7. */
>struct brw_reg addr = vec8(brw_address_reg(0));
> @@ -478,7 +478,30 @@ fs_generator::generate_mov_indirect(fs_inst *inst,
> * code, using it saves us 0 instructions and would require quite a bit
> * of case-by-case work.  It's just not worth it.
> */
> -  brw_ADD(p, addr, indirect_byte_offset, brw_imm_uw(imm_byte_offset));
> +  if (devinfo->gen >= 8 || devinfo->is_haswell || type_sz(reg.type) < 8) 
> {
> + brw_ADD(p, addr, indirect_byte_offset, brw_imm_uw(imm_byte_offset));
> +  } else {
> + /* IVB reads two address register components per channel for
> +  * indirectly addressed 64-bit sources, so we need to initialize
> +  * adjacent address components to consecutive dwords of the source
> +  * region by emitting two separate ADD instructions.  Found
> +  * empirically.
> +  */
> + assert(inst->exec_size <= 4);
> + brw_push_insn_state(p);
> + brw_set_default_exec_size(p, cvt(inst->exec_size) - 1);
> +
> + brw_ADD(p, spread(addr, 2), indirect_byte_offset,
> + brw_imm_uw(imm_byte_offset));
> + brw_inst_set_no_dd_clear(devinfo, brw_last_inst, true);
> +
> + brw_ADD(p, spread(suboffset(addr, 1), 2), indirect_byte_offset,
> + brw_imm_uw(imm_byte_offset + 4));
> + brw_inst_set_no_dd_check(devinfo, brw_last_inst, true);
> +
> + brw_pop_insn_state(p);
> +  }
> +
>struct brw_reg ind_src = brw_VxH_indirect(0, 0);
>  
>brw_inst *mov = brw_MOV(p, dst, retype(ind_src, dst.type));
> -- 
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH] virgl/vtest: disconnect on destroy

[Dave Airlie]

On 10 February 2017 at 00:35,   wrote:
> From: Marc-André Lureau 
>
> Since vtest is currently only handling a context at a time, calling
> disconnect in virgl_vtest_winsys_destroy() allows to pass tests such as
> piglit egl-create-context-invalid-flag-gles.
>
> Signed-off-by: Marc-André Lureau 
> ---
>  src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c | 9 +
>  src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c | 1 +
>  src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h | 2 ++
>  3 files changed, 12 insertions(+)
>
> diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c 
> b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> index 4541419d8e..585b9e8156 100644
> --- a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> +++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> @@ -101,11 +101,20 @@ static int virgl_vtest_send_init(struct 
> virgl_vtest_winsys *vws)
> return 0;
>  }
>
> +int virgl_vtest_disconnect(struct virgl_vtest_winsys *vws)
> +{
> +   if (vws->sock_fd != -1)
> +  return close(vws->sock_fd);
> +
> +   return 0;
> +}

Does it need to return a value at all?

Otherwise
Reviewed-by: Dave Airlie 
> +
>  int virgl_vtest_connect(struct virgl_vtest_winsys *vws)
>  {
> struct sockaddr_un un;
> int sock, ret;
>
> +   vws->sock_fd = -1;
> sock = socket(PF_UNIX, SOCK_STREAM, 0);
> if (sock < 0)
>return -1;
> diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c 
> b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
> index ce8ac97756..99470fde80 100644
> --- a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
> +++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
> @@ -620,6 +620,7 @@ virgl_vtest_winsys_destroy(struct virgl_winsys *vws)
> virgl_cache_flush(vtws);
>
> pipe_mutex_destroy(vtws->mutex);
> +   virgl_vtest_disconnect(vtws);
> FREE(vtws);
>  }
>
> diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h 
> b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h
> index b4faa70b67..7ee5f6f09b 100644
> --- a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h
> +++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h
> @@ -106,6 +106,8 @@ virgl_vtest_cmd_buf(struct virgl_cmd_buf *cbuf)
>
>
>  int virgl_vtest_connect(struct virgl_vtest_winsys *vws);
> +int virgl_vtest_disconnect(struct virgl_vtest_winsys *vws);
> +
>  int virgl_vtest_send_get_caps(struct virgl_vtest_winsys *vws,
>struct virgl_drm_caps *caps);
>
> --
> 2.11.0.295.gd7dffce1c.dirty
>
> ___
> 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] [PATCHv3 09/20] i965/fs: Get 64-bit indirect moves working on IVB.

[Francisco Jerez]

---
This replaces "[PATCH v2 09/20] i965/fs: indirect addressing with
doubles is not supported in IVB/BYT".

src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 27 --
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index ea4a3fe1399..0e2dbe23571 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -440,7 +440,7 @@ fs_generator::generate_mov_indirect(fs_inst *inst,
   brw_MOV(p, dst, reg);
} else {
   /* Prior to Broadwell, there are only 8 address registers. */
-  assert(inst->exec_size == 8 || devinfo->gen >= 8);
+  assert(inst->exec_size <= 8 || devinfo->gen >= 8);
 
   /* We use VxH indirect addressing, clobbering a0.0 through a0.7. */
   struct brw_reg addr = vec8(brw_address_reg(0));
@@ -478,7 +478,30 @@ fs_generator::generate_mov_indirect(fs_inst *inst,
* code, using it saves us 0 instructions and would require quite a bit
* of case-by-case work.  It's just not worth it.
*/
-  brw_ADD(p, addr, indirect_byte_offset, brw_imm_uw(imm_byte_offset));
+  if (devinfo->gen >= 8 || devinfo->is_haswell || type_sz(reg.type) < 8) {
+ brw_ADD(p, addr, indirect_byte_offset, brw_imm_uw(imm_byte_offset));
+  } else {
+ /* IVB reads two address register components per channel for
+  * indirectly addressed 64-bit sources, so we need to initialize
+  * adjacent address components to consecutive dwords of the source
+  * region by emitting two separate ADD instructions.  Found
+  * empirically.
+  */
+ assert(inst->exec_size <= 4);
+ brw_push_insn_state(p);
+ brw_set_default_exec_size(p, cvt(inst->exec_size) - 1);
+
+ brw_ADD(p, spread(addr, 2), indirect_byte_offset,
+ brw_imm_uw(imm_byte_offset));
+ brw_inst_set_no_dd_clear(devinfo, brw_last_inst, true);
+
+ brw_ADD(p, spread(suboffset(addr, 1), 2), indirect_byte_offset,
+ brw_imm_uw(imm_byte_offset + 4));
+ brw_inst_set_no_dd_check(devinfo, brw_last_inst, true);
+
+ brw_pop_insn_state(p);
+  }
+
   struct brw_reg ind_src = brw_VxH_indirect(0, 0);
 
   brw_inst *mov = brw_MOV(p, dst, retype(ind_src, dst.type));
-- 
2.11.0

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

[Mesa-dev] [PATCH] util/radv/adv: move *_get_function_timestamp() to utils

[Timothy Arceri]

---
 src/amd/vulkan/radv_device.c  | 22 +++---
 src/intel/vulkan/anv_device.c | 20 ++--
 src/util/disk_cache.h | 17 +
 3 files changed, 22 insertions(+), 37 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 8a54a2a..b5a3435 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -25,14 +25,13 @@
  * IN THE SOFTWARE.
  */
 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include "radv_private.h"
 #include "radv_cs.h"
+#include "util/disk_cache.h"
 #include "util/strtod.h"
 
 #include 
@@ -47,28 +46,13 @@
 struct radv_dispatch_table dtable;
 
 static int
-radv_get_function_timestamp(void *ptr, uint32_t* timestamp)
-{
-   Dl_info info;
-   struct stat st;
-   if (!dladdr(ptr, ) || !info.dli_fname) {
-   return -1;
-   }
-   if (stat(info.dli_fname, )) {
-   return -1;
-   }
-   *timestamp = st.st_mtim.tv_sec;
-   return 0;
-}
-
-static int
 radv_device_get_cache_uuid(enum radeon_family family, void *uuid)
 {
uint32_t mesa_timestamp, llvm_timestamp;
uint16_t f = family;
memset(uuid, 0, VK_UUID_SIZE);
-   if (radv_get_function_timestamp(radv_device_get_cache_uuid, 
_timestamp) ||
-   radv_get_function_timestamp(LLVMInitializeAMDGPUTargetInfo, 
_timestamp))
+   if (disk_cache_get_function_timestamp(radv_device_get_cache_uuid, 
_timestamp) ||
+   disk_cache_get_function_timestamp(LLVMInitializeAMDGPUTargetInfo, 
_timestamp))
return -1;
 
memcpy(uuid, _timestamp, 4);
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 91ee67f..607fc4f 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -21,18 +21,17 @@
  * IN THE SOFTWARE.
  */
 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
 #include "anv_private.h"
 #include "util/strtod.h"
 #include "util/debug.h"
+#include "util/disk_cache.h"
 
 #include "genxml/gen7_pack.h"
 
@@ -55,27 +54,12 @@ compiler_perf_log(void *data, const char *fmt, ...)
 }
 
 static bool
-anv_get_function_timestamp(void *ptr, uint32_t* timestamp)
-{
-   Dl_info info;
-   struct stat st;
-   if (!dladdr(ptr, ) || !info.dli_fname)
-  return false;
-
-   if (stat(info.dli_fname, ))
-  return false;
-
-   *timestamp = st.st_mtim.tv_sec;
-   return true;
-}
-
-static bool
 anv_device_get_cache_uuid(void *uuid)
 {
uint32_t timestamp;
 
memset(uuid, 0, VK_UUID_SIZE);
-   if (!anv_get_function_timestamp(anv_device_get_cache_uuid, ))
+   if (!disk_cache_get_function_timestamp(anv_device_get_cache_uuid, 
))
   return false;
 
snprintf(uuid, VK_UUID_SIZE, "anv-%d", timestamp);
diff --git a/src/util/disk_cache.h b/src/util/disk_cache.h
index 4ff1da5..6fbc07b 100644
--- a/src/util/disk_cache.h
+++ b/src/util/disk_cache.h
@@ -24,8 +24,10 @@
 #ifndef DISK_CACHE_H
 #define DISK_CACHE_H
 
+#include 
 #include 
 #include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
@@ -133,6 +135,21 @@ disk_cache_put_key(struct disk_cache *cache, cache_key 
key);
 bool
 disk_cache_has_key(struct disk_cache *cache, cache_key key);
 
+static inline int
+disk_cache_get_function_timestamp(void *ptr, uint32_t* timestamp)
+{
+   Dl_info info;
+   struct stat st;
+   if (!dladdr(ptr, ) || !info.dli_fname) {
+   return -1;
+   }
+   if (stat(info.dli_fname, )) {
+   return -1;
+   }
+   *timestamp = st.st_mtim.tv_sec;
+   return 0;
+}
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH v2 3/5] anv: Add support for the PMA fix on Broadwell

[Nanley Chery]

On Thu, Feb 09, 2017 at 11:38:31AM -0800, Jason Ekstrand wrote:
> On Thu, Feb 9, 2017 at 10:33 AM, Nanley Chery  wrote:
> 
> > On Wed, Feb 08, 2017 at 06:27:52PM -0800, Jason Ekstrand wrote:
> > > On Wed, Feb 8, 2017 at 5:34 PM, Nanley Chery 
> > wrote:
> > >
> > > > On Thu, Feb 02, 2017 at 01:26:05PM -0800, Jason Ekstrand wrote:
> > > > > In order to get good performance numbers for this, I had to hack up
> > the
> > > > > driver to whack wm_prog_data::uses_kill to true to emulate a discard
> > and
> > > > > used the Sascha "shadowmapping" demo.  Setting uses_kill to true
> > dropped
> > > > > the framerate on the demo by 25-30%.  Enabling the PMA fix brought it
> > > > > back up to around 90% of the original framerate.  This doesn't seem
> > to
> > > > > really impact Dota 2;  probably because it doesn't use 16-bit depth.
> > > > >
> > > > > Reviewed-by: Lionel Landwerlin 
> > > > > ---
> > > > >  src/intel/vulkan/TODO  |   1 -
> > > > >  src/intel/vulkan/anv_cmd_buffer.c  |   2 +
> > > > >  src/intel/vulkan/anv_genX.h|   3 +
> > > > >  src/intel/vulkan/anv_private.h |  17 +
> > > > >  src/intel/vulkan/gen7_cmd_buffer.c |   7 ++
> > > > >  src/intel/vulkan/gen8_cmd_buffer.c | 133
> > ++
> > > > +++
> > > > >  src/intel/vulkan/genX_blorp_exec.c |   5 ++
> > > > >  src/intel/vulkan/genX_cmd_buffer.c |  15 -
> > > > >  src/intel/vulkan/genX_pipeline.c   |  38 +++
> > > > >  9 files changed, 219 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/src/intel/vulkan/TODO b/src/intel/vulkan/TODO
> > > > > index 38acc0d..f8b73a1 100644
> > > > > --- a/src/intel/vulkan/TODO
> > > > > +++ b/src/intel/vulkan/TODO
> > > > > @@ -12,5 +12,4 @@ Performance:
> > > > >   - Compressed multisample support
> > > > >   - Pushing pieces of UBOs?
> > > > >   - Enable guardband clipping
> > > > > - - pma stall workaround
> > > > >   - Use soft-pin to avoid relocations
> > > > > diff --git a/src/intel/vulkan/anv_cmd_buffer.c
> > > > b/src/intel/vulkan/anv_cmd_buffer.c
> > > > > index 5886fa6..8c08f8d 100644
> > > > > --- a/src/intel/vulkan/anv_cmd_buffer.c
> > > > > +++ b/src/intel/vulkan/anv_cmd_buffer.c
> > > > > @@ -135,6 +135,8 @@ anv_cmd_state_reset(struct anv_cmd_buffer
> > > > *cmd_buffer)
> > > > > state->restart_index = UINT32_MAX;
> > > > > state->dynamic = default_dynamic_state;
> > > > > state->need_query_wa = true;
> > > > > +   state->pma_fix_enabled = false;
> > > > > +   state->hiz_enabled = false;
> > > > >
> > > > > if (state->attachments != NULL) {
> > > > >vk_free(_buffer->pool->alloc, state->attachments);
> > > > > diff --git a/src/intel/vulkan/anv_genX.h
> > b/src/intel/vulkan/anv_genX.h
> > > > > index d04fe38..67147b0 100644
> > > > > --- a/src/intel/vulkan/anv_genX.h
> > > > > +++ b/src/intel/vulkan/anv_genX.h
> > > > > @@ -55,6 +55,9 @@ void genX(cmd_buffer_flush_dynamic_state)(struct
> > > > anv_cmd_buffer *cmd_buffer);
> > > > >
> > > > >  void genX(cmd_buffer_flush_compute_state)(struct anv_cmd_buffer
> > > > *cmd_buffer);
> > > > >
> > > > > +void genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer
> > *cmd_buffer,
> > > > > + bool enable);
> > > > > +
> > > > >  void
> > > > >  genX(emit_urb_setup)(struct anv_device *device, struct anv_batch
> > *batch,
> > > > >   const struct gen_l3_config *l3_config,
> > > > > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> > > > private.h
> > > > > index 4fe3ebc..6efe4ea 100644
> > > > > --- a/src/intel/vulkan/anv_private.h
> > > > > +++ b/src/intel/vulkan/anv_private.h
> > > > > @@ -1163,6 +1163,20 @@ struct anv_cmd_state {
> > > > > bool need_query_wa;
> > > > >
> > > > > /**
> > > > > +* Whether or not the gen8 PMA fix is enabled.  We ensure that,
> > at
> > > > the top
> > > > > +* of any command buffer it disabled by disabling it in
> > > > EndCommandBuffer
> > > >  ^
> > > >  is?
> > > >
> >
> > Fixed?
> >
> 
> done
> 
> 
> > > > > +* and before invoking the secondary in ExecuteCommands.
> > > > > +*/
> > > > > +   bool pma_fix_enabled;
> > > > > +
> > > > > +   /**
> > > > > +* Whether or not we now for certain that HiZ is enabled for the
> > > > current
> > > >^
> > > >know
> > > >
> >
> > Fixed?
> >
> 
> done
> 
> 
> > > > > +* subpass.  If, for whatever reason, we are unsure as to whether
> > > > HiZ is
> > > > > +* enabled or not, this will be false.
> > > > > +*/
> > > > > +   bool hiz_enabled;
> > > > > +
> > > > > +   /**
> > > > >  * Array length is anv_cmd_state::pass::attachment_count. Array
> > > > content 

Re: [Mesa-dev] [PATCH 0/4] RFC: Quadratic probing for the win

[Timothy Arceri]

On Wed, 2017-02-08 at 21:35 +0100, Thomas Helland wrote:
> I was cleaning up my local git repo, and came across this series.
> Last time it was discussed was all the way back in April 2015.
> Things looked pretty good back then, but we where seeing a smaller
> regression in CPU-bound scenarios as Eric found with forcing
> software 
> rendering while running Minecraft.
> 
> I figured I'd do a retest of the series to see how it fares today.
> Using perf on shader-db I see:
> hash_table_search being cut from 3.88% down to 1.83%.
> _mesa_hash_data being cut from 1.47% down to 1.25%
> _mesa_hash_table_rehash going from 0.23% up to 1.16%
> hash_table_insert being cut from 2.26% down to 0.33%
> 
> This yields an approximate 10% reduction in shader-db runtime.
> 
> The increase in the rehash function is a bit peculiar.
> I'll look into increasing the table one more step, as a four entry
> hash table seems a bit on the low side. I'll also work on getting
> some more reliable numbers from a real world application, along
> with some more runs of shader-db to get better statistical certainty.
> I'll pull out my i3-6100 / RX460 combo and give this a spin
> with Borderlands 2 I think, as Marek's threaded GL work suggests
> this is a title with heavy CPU bottlenecking.
> 
> As a side note, Robin Hood hashing was mentioned in the thread from
> back in April 2015.

Yes Robin Hood hashing looked very interesting, since most of our time
is spent dealing with collisions I think it would be very interesting
to explore.

>  I actually have an implementation of that, but
> I'm still working out an issue that our make-check tests doesn't
> catch that causes corruption in the table when runing shader-db.

Not sure what you mean here.

> I'm not to sure about it's effect though, as it sacrifices insert
> speed for lookup speed, but one never knows until one tests.

Rearranging the table should be faster than doing strcmp and other
complex key matching 100's? 1000's? 1,000,000's? of times more than is
needed.

Also I would hope that most uses of the hash table are not 1:1
insert/lookup. They certainly won't be for uses outside the compiler,
e.g Minecraft and reductions in collisions would bring big
improvements.

If you are interested in working on it I'd be very interested to see
the result :)

> 
> Let me know if this is something I should persue. If not I'll
> mark this series as "junk" in my git repo, and get on with the
> cleaning.
> 
> Thomas Helland (4):
>   util/tests: Expand collision test for hash table
>   util: Change hash_table to use quadratic probing
>   util: Change util/set to use quadratic probing
>   util: Use set_foreach instead of rolling our own
> 
>  src/util/hash_table.c | 102 +---
> -
>  src/util/hash_table.h |   3 +-
>  src/util/set.c| 118 --
> 
>  src/util/set.h|   3 +-
>  src/util/tests/hash_table/collision.c |  14 
>  5 files changed, 89 insertions(+), 151 deletions(-)
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] tgsi-dump: dump label if instruction has one

[marcandre . lureau]

From: Marc-André Lureau 

The instruction has an associated label when Instruction.Label == 1,
as can be seen in ureg_emit_label() or tgsi_build_full_instruction().

This fixes dump generating extra :0 labels on conditionals, and virgl
parsing more than the expected tokens and eventually reaching "Illegal
command buffer" (when parsing more than a safety margin of 10 we
currently have).

Signed-off-by: Marc-André Lureau 
---
 src/gallium/auxiliary/tgsi/tgsi_dump.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_dump.c 
b/src/gallium/auxiliary/tgsi/tgsi_dump.c
index f74aad167f..14911c481d 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_dump.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_dump.c
@@ -685,17 +685,19 @@ iter_instruction(
   }
}
 
-   switch (inst->Instruction.Opcode) {
-   case TGSI_OPCODE_IF:
-   case TGSI_OPCODE_UIF:
-   case TGSI_OPCODE_ELSE:
-   case TGSI_OPCODE_BGNLOOP:
-   case TGSI_OPCODE_ENDLOOP:
-   case TGSI_OPCODE_CAL:
-   case TGSI_OPCODE_BGNSUB:
-  TXT( " :" );
-  UID( inst->Label.Label );
-  break;
+   if (inst->Instruction.Label) {
+  switch (inst->Instruction.Opcode) {
+  case TGSI_OPCODE_IF:
+  case TGSI_OPCODE_UIF:
+  case TGSI_OPCODE_ELSE:
+  case TGSI_OPCODE_BGNLOOP:
+  case TGSI_OPCODE_ENDLOOP:
+  case TGSI_OPCODE_CAL:
+  case TGSI_OPCODE_BGNSUB:
+ TXT( " :" );
+ UID( inst->Label.Label );
+ break;
+  }
}
 
/* update indentation */
-- 
2.11.0.295.gd7dffce1c.dirty

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

Re: [Mesa-dev] [PATCH v2] nir: delete magic number

[Timothy Arceri]

On Wed, 2017-02-08 at 15:54 -0800, Jason Ekstrand wrote:
> On Wed, Feb 8, 2017 at 2:20 PM, Elie Tournier  m> wrote:
> > Signed-off-by: Elie Tournier 
> > ---
> >  src/compiler/nir/nir_opt_loop_unroll.c | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
> > b/src/compiler/nir/nir_opt_loop_unroll.c
> > index 37cbced43d..035a030239 100644
> > --- a/src/compiler/nir/nir_opt_loop_unroll.c
> > +++ b/src/compiler/nir/nir_opt_loop_unroll.c
> > @@ -26,6 +26,14 @@
> >  #include "nir_control_flow.h"
> >  #include "nir_loop_analyze.h"
> > 
> > +
> > +/* This limit is chosen fairly arbitrarily.  The GLSL IR limit is
> > 25.
> > + * However, due to slight differences in the way the two IRs count
> > + * instructions, some loops that would unroll with GLSL IR fail to
> > unroll
> > + * if we set this to 25 so we set it to 26.
> 
> Ok, I lied in my comment.  It's not 25, it's 32.  Tim, can you
> explain the discrepancy?

Max iteration is 32 this is number of instructions, in GLSL IR it was
node and the magic number was 5. There is no 1:1 mapping 25 was picked
because it seemed to give about the same results.


> --Jason
>  
> > + */
> > +#define LOOP_UNROLL_LIMIT 26
> > +
> >  /* Prepare this loop for unrolling by first converting to lcssa
> > and then
> >   * converting the phis from the loops first block and the block
> > that follows
> >   * the loop into regs.  Partially converting out of SSA allows us
> > to unroll
> > @@ -460,7 +468,7 @@ is_loop_small_enough_to_unroll(nir_shader
> > *shader, nir_loop_info *li)
> >        return true;
> > 
> >     bool loop_not_too_large =
> > -      li->num_instructions * li->trip_count <= max_iter * 26;
> > +      li->num_instructions * li->trip_count <= max_iter *
> > LOOP_UNROLL_LIMIT;
> > 
> >     return loop_not_too_large;
> >  }
> > --
> > 2.11.0
> > 
> > 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/4] RFC: Quadratic probing for the win

[Timothy Arceri]

On Wed, 2017-02-08 at 15:59 -0800, Jason Ekstrand wrote:
> On Wed, Feb 8, 2017 at 3:01 PM, Marek Olšák  wrote:
> > I think this is good stuff. I'd gladly take it just for the shader-
> > db
> > improvement.
> > 
> 
> Agreed.  If it really did hurt minecraft before, we should try that
> again just to be sure, but I like faster shader compilation.

Maybe someone should do a quick test with a larger shader-db
collection. Not that the results don't look good but I believe Thomas
has a smaller collection that the one used by Marek and Intel.


>  
> > Marek
> > 
> > On Wed, Feb 8, 2017 at 11:35 PM, Thomas Helland
> >  wrote:
> > > 2017-02-08 22:07 GMT+01:00 Thomas Helland  > com>:
> > >> 2017-02-08 21:35 GMT+01:00 Thomas Helland  > .com>:
> > >>> I was cleaning up my local git repo, and came across this
> > series.
> > >>> Last time it was discussed was all the way back in April 2015.
> > >>> Things looked pretty good back then, but we where seeing a
> > smaller
> > >>> regression in CPU-bound scenarios as Eric found with forcing
> > software
> > >>> rendering while running Minecraft.
> > >>>
> > >>> I figured I'd do a retest of the series to see how it fares
> > today.
> > >>> Using perf on shader-db I see:
> > >>> hash_table_search being cut from 3.88% down to 1.83%.
> > >>> _mesa_hash_data being cut from 1.47% down to 1.25%
> > >>> _mesa_hash_table_rehash going from 0.23% up to 1.16%
> > >>> hash_table_insert being cut from 2.26% down to 0.33%
> > >>>
> > >>
> > >> This stats are wrong. I recompiled stuff, so the symbols got
> > >> mangled in the libraries. So here is the correct data (after
> > increasing
> > >> the initial size of the set and hash table to 8, so not
> > perfectly comparable):
> > >> hash_table_search: 3.88% -> 1.84%
> > >> hash_table_insert: 2.26% -> 1.16%
> > >> _mesa_hash_data is unchanged (which is kinda obvious).
> > >> set_add: 0.70% -> 0.35%
> > >> set_search: 0.59% -> 0.27%
> > >>
> > >>> This yields an approximate 10% reduction in shader-db runtime.
> > >>>
> > >>> The increase in the rehash function is a bit peculiar.
> > >>> I'll look into increasing the table one more step, as a four
> > entry
> > >>> hash table seems a bit on the low side. I'll also work on
> > getting
> > >>> some more reliable numbers from a real world application, along
> > >>> with some more runs of shader-db to get better statistical
> > certainty.
> > >>> I'll pull out my i3-6100 / RX460 combo and give this a spin
> > >>> with Borderlands 2 I think, as Marek's threaded GL work
> > suggests
> > >>> this is a title with heavy CPU bottlenecking.
> > >>>
> > >
> > > Using this hardware I ran the Metro LL Redux benchmark mode
> > > through phoronix-test-suite as a quick test. Average fps improved
> > > from 43,97 to 45.23. So not insane, but a decent gain of 2-3%.
> > > I'll come back with some more numbers from in-game play of
> > > some other games in my possession. Likely CS:GO, portal,
> > > TF2, dota2, borderlands 2, or some other games I have.
> > >
> > >>> As a side note, Robin Hood hashing was mentioned in the thread
> > from
> > >>> back in April 2015. I actually have an implementation of that,
> > but
> > >>> I'm still working out an issue that our make-check tests
> > doesn't
> > >>> catch that causes corruption in the table when runing shader-
> > db.
> > >>> I'm not to sure about it's effect though, as it sacrifices
> > insert
> > >>> speed for lookup speed, but one never knows until one tests.
> > >>>
> > >>> Let me know if this is something I should persue. If not I'll
> > >>> mark this series as "junk" in my git repo, and get on with the
> > cleaning.
> > >>>
> > >>> Thomas Helland (4):
> > >>>   util/tests: Expand collision test for hash table
> > >>>   util: Change hash_table to use quadratic probing
> > >>>   util: Change util/set to use quadratic probing
> > >>>   util: Use set_foreach instead of rolling our own
> > >>>
> > >>>  src/util/hash_table.c                 | 102 +-
> > ---
> > >>>  src/util/hash_table.h                 |   3 +-
> > >>>  src/util/set.c                        | 118 
> > --
> > >>>  src/util/set.h                        |   3 +-
> > >>>  src/util/tests/hash_table/collision.c |  14 
> > >>>  5 files changed, 89 insertions(+), 151 deletions(-)
> > >>>
> > >>> --
> > >>> 2.11.1
> > >>>
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] virgl/vtest: disconnect on destroy

[marcandre . lureau]

From: Marc-André Lureau 

Since vtest is currently only handling a context at a time, calling
disconnect in virgl_vtest_winsys_destroy() allows to pass tests such as
piglit egl-create-context-invalid-flag-gles.

Signed-off-by: Marc-André Lureau 
---
 src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c | 9 +
 src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c | 1 +
 src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h | 2 ++
 3 files changed, 12 insertions(+)

diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c 
b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
index 4541419d8e..585b9e8156 100644
--- a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
+++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
@@ -101,11 +101,20 @@ static int virgl_vtest_send_init(struct 
virgl_vtest_winsys *vws)
return 0;
 }
 
+int virgl_vtest_disconnect(struct virgl_vtest_winsys *vws)
+{
+   if (vws->sock_fd != -1)
+  return close(vws->sock_fd);
+
+   return 0;
+}
+
 int virgl_vtest_connect(struct virgl_vtest_winsys *vws)
 {
struct sockaddr_un un;
int sock, ret;
 
+   vws->sock_fd = -1;
sock = socket(PF_UNIX, SOCK_STREAM, 0);
if (sock < 0)
   return -1;
diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c 
b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
index ce8ac97756..99470fde80 100644
--- a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
+++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
@@ -620,6 +620,7 @@ virgl_vtest_winsys_destroy(struct virgl_winsys *vws)
virgl_cache_flush(vtws);
 
pipe_mutex_destroy(vtws->mutex);
+   virgl_vtest_disconnect(vtws);
FREE(vtws);
 }
 
diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h 
b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h
index b4faa70b67..7ee5f6f09b 100644
--- a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h
+++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h
@@ -106,6 +106,8 @@ virgl_vtest_cmd_buf(struct virgl_cmd_buf *cbuf)
 
 
 int virgl_vtest_connect(struct virgl_vtest_winsys *vws);
+int virgl_vtest_disconnect(struct virgl_vtest_winsys *vws);
+
 int virgl_vtest_send_get_caps(struct virgl_vtest_winsys *vws,
   struct virgl_drm_caps *caps);
 
-- 
2.11.0.295.gd7dffce1c.dirty

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

[Mesa-dev] [PATCH] tgsi: remove ureg_label_insn

[marcandre . lureau]

From: Marc-André Lureau 

Unused since commit 2897cb3dba9287011f9c43cd2f214100952370c0.

Signed-off-by: Marc-André Lureau 
---
 src/gallium/auxiliary/tgsi/tgsi_ureg.c | 31 ---
 src/gallium/auxiliary/tgsi/tgsi_ureg.h |  7 ---
 2 files changed, 38 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 196a893b75..8d1b6cc7da 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1488,37 +1488,6 @@ ureg_tex_insn(struct ureg_program *ureg,
 
 
 void
-ureg_label_insn(struct ureg_program *ureg,
-unsigned opcode,
-const struct ureg_src *src,
-unsigned nr_src,
-unsigned *label_token )
-{
-   struct ureg_emit_insn_result insn;
-   unsigned i;
-
-   insn = ureg_emit_insn(ureg,
- opcode,
- FALSE,
- FALSE,
- FALSE,
- TGSI_SWIZZLE_X,
- TGSI_SWIZZLE_Y,
- TGSI_SWIZZLE_Z,
- TGSI_SWIZZLE_W,
- 0,
- nr_src);
-
-   ureg_emit_label( ureg, insn.extended_token, label_token );
-
-   for (i = 0; i < nr_src; i++)
-  ureg_emit_src( ureg, src[i] );
-
-   ureg_fixup_insn_size( ureg, insn.insn_token );
-}
-
-
-void
 ureg_memory_insn(struct ureg_program *ureg,
  unsigned opcode,
  const struct ureg_dst *dst,
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index 51f69853b7..99908d9ce0 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -571,13 +571,6 @@ ureg_tex_insn(struct ureg_program *ureg,
 
 
 void
-ureg_label_insn(struct ureg_program *ureg,
-unsigned opcode,
-const struct ureg_src *src,
-unsigned nr_src,
-unsigned *label);
-
-void
 ureg_memory_insn(struct ureg_program *ureg,
  unsigned opcode,
  const struct ureg_dst *dst,
-- 
2.11.0.295.gd7dffce1c.dirty

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

[Mesa-dev] [Bug 99692] [radv] Mostly broken on Hawaii PRO/CIK ASICs

[bugzilla-daemon]

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

--- Comment #3 from Nicholas Disiere  ---
I can confirm that this visual corruption is present on my R9 290 when radeon
is blacklisted on the current Arch kernel. It affects the desktop with and
without the compositor, and causes vulkan games to crash.

-- 
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 2/2] anv/blorp: Disable partial resolves for transparent black clears

[Nanley Chery]

On Fri, Feb 10, 2017 at 12:44:02AM +, Emil Velikov wrote:
> On 24 January 2017 at 00:55, Nanley Chery  wrote:
> > Cc: "13.0 17.0" 
> Nanley please take a look at the nominations page [1] and especially
> at the note in the end ;-)
> That said, I've picked this for 13.0 and will do 17.0 in a few minutes.

Hi Emil,

Thanks for looking at this. I did retract my nomimation by omitting the
Cc to mesa-stable on the patch pushed upstream. If you have already
picked this for 17.0, we'd like to have it. If not, we'll wait for the
next stable release.

Thanks!
Nanley

> 
> Thanks
> Emil
> [1] https://www.mesa3d.org/submittingpatches.html#nominations
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util/disk_cache: remove function stubs

[Timothy Arceri]

The option to disable shader cache was removed from the build options
when we imported a sha1 implementation into Mesa.

Cc: Emil Velikov 
---
 src/util/disk_cache.h | 50 --
 1 file changed, 50 deletions(-)

diff --git a/src/util/disk_cache.h b/src/util/disk_cache.h
index e429db5..4ff1da5 100644
--- a/src/util/disk_cache.h
+++ b/src/util/disk_cache.h
@@ -38,10 +38,6 @@ typedef uint8_t cache_key[CACHE_KEY_SIZE];
 
 struct disk_cache;
 
-/* Provide inlined stub functions if the shader cache is disabled. */
-
-#ifdef ENABLE_SHADER_CACHE
-
 /**
  * Create a new cache object.
  *
@@ -137,52 +133,6 @@ disk_cache_put_key(struct disk_cache *cache, cache_key 
key);
 bool
 disk_cache_has_key(struct disk_cache *cache, cache_key key);
 
-#else
-
-static inline struct disk_cache *
-disk_cache_create(const char *gpu_name, const char *mesa_version)
-{
-   return NULL;
-}
-
-static inline void
-disk_cache_destroy(struct disk_cache *cache) {
-   return;
-}
-
-static inline void
-disk_cache_put(struct disk_cache *cache, cache_key key,
-  const void *data, size_t size)
-{
-   return;
-}
-
-static inline void
-disk_cache_remove(struct program_cache *cache, cache_key key)
-{
-   return;
-}
-
-static inline uint8_t *
-disk_cache_get(struct disk_cache *cache, cache_key key, size_t *size)
-{
-   return NULL;
-}
-
-static inline void
-disk_cache_put_key(struct disk_cache *cache, cache_key key)
-{
-   return;
-}
-
-static inline bool
-disk_cache_has_key(struct disk_cache *cache, cache_key key)
-{
-   return false;
-}
-
-#endif /* ENABLE_SHADER_CACHE */
-
 #ifdef __cplusplus
 }
 #endif
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH 5/5] anv/pipeline: Be smarter about depth/stencil state

[Nanley Chery]

On Wed, Feb 01, 2017 at 05:43:55PM -0800, Jason Ekstrand wrote:
> This seemed to help Dota 2 by a percent or two.

I wasn't able to reproduce this on SKL, could you qualify this with "on
BDW"?

> ---
>  src/intel/vulkan/genX_pipeline.c | 133 
> +--
>  1 file changed, 99 insertions(+), 34 deletions(-)
> 
> diff --git a/src/intel/vulkan/genX_pipeline.c 
> b/src/intel/vulkan/genX_pipeline.c
> index f6940d2..1961874 100644
> --- a/src/intel/vulkan/genX_pipeline.c
> +++ b/src/intel/vulkan/genX_pipeline.c
> @@ -634,6 +634,95 @@ static const uint32_t vk_to_gen_stencil_op[] = {
> [VK_STENCIL_OP_DECREMENT_AND_WRAP]   = STENCILOP_DECR,
>  };
>  
> +static bool
> +may_write_stencil_face(const VkStencilOpState *face,
> +   VkCompareOp depthCompareOp)
> +{
> +   return (face->compareOp != VK_COMPARE_OP_ALWAYS &&
> +   face->failOp != VK_STENCIL_OP_KEEP) ||
> +  (face->compareOp != VK_COMPARE_OP_NEVER &&
> +   ((depthCompareOp != VK_COMPARE_OP_NEVER &&
> + face->passOp != VK_STENCIL_OP_KEEP) ||
> +(depthCompareOp != VK_COMPARE_OP_ALWAYS &&
> + face->depthFailOp != VK_STENCIL_OP_KEEP)));

This is quite confusing to me. Could you split out each
part of this condition? Comments may also help.

> +}
> +
> +/* Intel hardware is fairly sensitive to whether or not depth/stencil writes
> + * are enabled.  In the presence of discards, disabling writes means that the
> + * depth/stencil testing can get moved earlier in the pipeline which allows 
> it

Could you cite the source for this statement? This doesn't match my
understanding of what the following sections of the hardware docs say:
* ILK PRM: 8.4.3.2 Early Depth Test Cases [Pre-DevSNB] 
* IVB PRM: 11.5.2 Early Depth Test/Stencil Test/Write

According to these docs, on IVB+, depth/stencil testing is always
performed early when the PS doesn't write out depth. In the presence of
discards, disabling writes makes a depth pixel promoted instead of
non-promoted, meaning that the writes aren't performed at the end of the
PS.

> + * to avoid executing the fragment shader of the depth or stencil test fails.
> + *
> + * Unfortunately, the way depth and stencil testing is specified, there are
> + * many case where, regardless of depth/stencil writes being enabled, nothing
> + * actually gets written due to some other bit of state being set.  This
> + * function attempts to "sanitize" the depth stencil state and disable writes
> + * and sometimes even testing whenever possible.
> + */

This is a great idea!

> +static void
> +sanitize_ds_state(VkPipelineDepthStencilStateCreateInfo *state,
> +  bool *stencilWriteEnable,
> +  VkImageAspectFlags ds_aspects)
> +{
> +   *stencilWriteEnable = state->stencilTestEnable;
> +
> +   /* If the depth test is disabled, we won't be writing anything. */
> +   if (!state->depthTestEnable)
> +  state->depthWriteEnable = false;
> +
> +   /* The Vulkan spec requires that if either depth or stencil is not 
> present,
> +* the pipeline is to act as if the test silently passes.
> +*/
> +   if (!(ds_aspects & VK_IMAGE_ASPECT_DEPTH_BIT)) {
> +  state->depthWriteEnable = false;
> +  state->depthCompareOp = VK_COMPARE_OP_ALWAYS;
> +   }
> +
> +   if (!(ds_aspects & VK_IMAGE_ASPECT_STENCIL_BIT)) {
> +  *stencilWriteEnable = false;
> +  state->front.compareOp = VK_COMPARE_OP_ALWAYS;
> +  state->back.compareOp = VK_COMPARE_OP_ALWAYS;
> +   }
> +
> +   /* If the stencil test is enabled and always fails, then we will never get
> +* to the depth test so we can just disable the depth test entirely.
> +*/
> +   if (state->stencilTestEnable &&

This also needs:

  ds_aspects & VK_IMAGE_ASPECT_STENCIL_BIT &&

If a stencil aspect isn't there, the stencil test always passes. You
could mention this nuance in the comment above.

> +   state->front.compareOp == VK_COMPARE_OP_NEVER &&
> +   state->back.compareOp == VK_COMPARE_OP_NEVER) {
> +  state->depthTestEnable = false;
> +  state->depthWriteEnable = false;
> +   }

We may want to handle the following cases eventually:

   1. state->maxDepthBounds < state->minDepthBounds
   2. compareMask && compareOp combinations

> +
> +   /* If depthCompareOp is EQUAL then the value we would be writing to the
> +* depth buffer is the same as the value that's already there so there's 
> no
> +* point in writing it.
> +*/
> +   if (state->depthCompareOp == VK_COMPARE_OP_EQUAL)
> +  state->depthWriteEnable = false;
> +
> +   /* If the stencil ops are such that we don't actually ever modify the
> +* stencil buffer, we should disable writes.
> +*/
> +   if (!may_write_stencil_face(>front, state->depthCompareOp) &&
> +   !may_write_stencil_face(>back, state->depthCompareOp))

This is not enough to disable writes. Even if the user sets
VK_STENCIL_OP_KEEP and VK_COMPARE_OP_ALWAYS in the appropriate 

[Mesa-dev] [PATCH] nvc0: fix 64-bit integer query buffer writes

[Ilia Mirkin]

The former logic just plain didn't work at all. We need to write the
subsequent dword to the next buffer location.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/nvc0/mme/com9097.mme   | 22 -
 src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h | 28 ++
 src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c   |  7 +++---
 3 files changed, 37 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme 
b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
index 11c2056..7c5ec8f 100644
--- a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
+++ b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
@@ -508,18 +508,21 @@ daic_runout_check:
  * parm[3] = MSB of start value
  * parm[4] = desired sequence
  * parm[5] = actual sequence
+ * parm[6] = query high address
+ * parm[7] = query low address
  */
 .section #mme9097_query_buffer_write
parm $r2
parm $r3
parm $r4
-   parm $r5 maddr 0x16c2 /* QUERY_SEQUENCE */
+   parm $r5 maddr 0x16c0 /* QUERY_ADDRESS_HIGH */
parm $r6
parm $r7
mov $r6 (sub $r7 $r6) /* actual - desired */
mov $r6 (sbb 0x0 0x0) /* if there was underflow, not reached yet */
-   braz annul $r6 #qbw_ready
-   exit
+   parm $r7
+   exit braz $r6 #qbw_ready
+   parm $r6
 qbw_ready:
mov $r2 (sub $r2 $r4)
braz $r1 #qbw_postclamp
@@ -531,12 +534,19 @@ qbw_ready:
 qbw_clamp:
mov $r2 $r1
 qbw_postclamp:
+   send $r7
+   send $r6
send $r2
+   branz $r1 #qbw_done
mov $r4 0x1000
-   branz annul $r1 #qbw_done
send (extrinsrt 0x0 $r4 0x0 0x10 0x10)
-   maddr 0x16c2 /* QUERY_SEQUENCE */
+   maddr 0x16c0 /* QUERY_ADDRESS_HIGH */
+   mov $r5 0x4
+   mov $r6 (add $r6 $r5)
+   mov $r7 (adc $r7 0x0)
+   send $r7
+   send $r6
send $r3
 qbw_done:
exit send (extrinsrt 0x0 $r4 0x0 0x10 0x10)
-   nop
+   maddrsend 0x44
diff --git a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h 
b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
index 1c8f4bb..9618da6 100644
--- a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
+++ b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
@@ -336,18 +336,19 @@ uint32_t mme9097_draw_arrays_indirect_count[] = {
 uint32_t mme9097_query_buffer_write[] = {
0x0201,
0x0301,
-/* 0x000a: qbw_ready */
+/* 0x000b: qbw_ready */
0x0401,
-   0x05b08551,
-/* 0x0011: qbw_clamp */
-/* 0x0012: qbw_postclamp */
+   0x05b00551,
+/* 0x0012: qbw_clamp */
+/* 0x0013: qbw_postclamp */
0x0601,
0x0701,
-/* 0x0018: qbw_done */
0x0005be10,
0x00060610,
-   0xb027,
-   0x0091,
+/* 0x0020: qbw_done */
+   0x0701,
+   0xb087,
+   0x0601,
0x00051210,
0x0001c807,
0x00075b10,
@@ -356,12 +357,19 @@ uint32_t mme9097_query_buffer_write[] = {
0x00060410,
0xa027,
0x0a11,
+   0x3841,
+   0x3041,
0x1041,
+   0x00028817,
0x04000411,
-   0x00010837,
0x84010042,
-   0x05b08021,
+   0x05b00021,
+   0x00010511,
+   0x00017610,
+   0x00023f10,
+   0x3841,
+   0x3041,
0x1841,
0x840100c2,
-   0x0011,
+   0x00110071,
 };
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
index ff20fe6..0991af8 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
@@ -406,10 +406,7 @@ nvc0_hw_get_query_result_resource(struct nvc0_context 
*nvc0,
nouveau_pushbuf_space(push, 32, 2, 0);
PUSH_REFN (push, hq->bo, NOUVEAU_BO_GART | NOUVEAU_BO_RD);
PUSH_REFN (push, buf->bo, buf->domain | NOUVEAU_BO_WR);
-   BEGIN_NVC0(push, NVC0_3D(QUERY_ADDRESS_HIGH), 2);
-   PUSH_DATAh(push, buf->address + offset);
-   PUSH_DATA (push, buf->address + offset);
-   BEGIN_1IC0(push, NVC0_3D(MACRO_QUERY_BUFFER_WRITE), 7);
+   BEGIN_1IC0(push, NVC0_3D(MACRO_QUERY_BUFFER_WRITE), 9);
if (q->type == PIPE_QUERY_OCCLUSION_PREDICATE) /* XXX what if 64-bit? */
   PUSH_DATA(push, 0x0001);
else if (result_type == PIPE_QUERY_TYPE_I32)
@@ -468,6 +465,8 @@ nvc0_hw_get_query_result_resource(struct nvc0_context *nvc0,
   nouveau_pushbuf_data(push, hq->bo, hq->offset,
4 | NVC0_IB_ENTRY_1_NO_PREFETCH);
}
+   PUSH_DATAh(push, buf->address + offset);
+   PUSH_DATA (push, buf->address + offset);
 
if (buf->mm) {
   nouveau_fence_ref(nvc0->screen->base.fence.current, >fence);
-- 
2.10.2

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

Re: [Mesa-dev] [PATCH v2 07/17] configure.ac: Rework MESA_LLVM and LLVM detection

[Tobias Droste]

Reviewed-by: Tobias Droste 

Am Donnerstag, 9. Februar 2017, 20:54:26 CET schrieb Emil Velikov:
> From: Tobias Droste 
> 
> Set FOUND_LLVM only when LLVM is present (checking for exact version/etc
> is deferred) and use enable-gallium-llvm to indicate the global LLVM
> status.
> 
> Renaming the latter is not appropriate for stable patches, so we'll
> address it with a later commit.
> 
> Loosely based on work by Tobias.
> 
> v2: Check FOUND_LLVM if enable_gallium_llvm is set.
> 
> Cc: Dave Airlie 
> Cc: "17.0" 
> Signed-off-by: Emil Velikov 
> Reviewed-by: Tobias Droste  (v1)
> ---
>  configure.ac | 27 +++
>  1 file changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 2c7e95cf82..8d8328b451 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -953,9 +953,9 @@ llvm_set_environment_variables() {
>  fi
> 
>  DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT
> -DMESA_LLVM_VERSION_PATCH=$LLVM_VERSION_PATCH" -MESA_LLVM=1
> +FOUND_LLVM=yes
>  else
> -MESA_LLVM=0
> +FOUND_LLVM=no
>  LLVM_VERSION_INT=0
>  fi
>  }
> @@ -967,10 +967,6 @@ require_llvm() {
>  }
> 
>  llvm_require_version() {
> -if test "x$MESA_LLVM" = x0; then
> -AC_MSG_ERROR([LLVM $1 or newer is required for $2])
> -return
> -fi
>  require_llvm $2
> 
>  llvm_target_version_major=`echo $1 | cut -d. -f1 | egrep -o
> '^[[0-9]]+'` @@ -1728,6 +1724,10 @@ fi
>  dnl
>  dnl Gallium LLVM
>  dnl
> +dnl With follow-up commits we'll rework --enable-gallium-llvm to
> --enable-llvm +dnl Since that is too invasive to stable, do the more
> conservative thing for now +dnl and consider it as a global LLVM toggle.
> +dnl
>  AC_ARG_ENABLE([gallium-llvm],
>  [AS_HELP_STRING([--enable-gallium-llvm],
>  [build gallium LLVM support @<:@default=enabled on
> x86/x86_64@:>@])], @@ -1740,6 +1740,10 @@ if test "x$enable_gallium_llvm" =
> xauto; then esac
>  fi
> 
> +if test "x$enable_gallium_llvm" = xyes -a "x$FOUND_LLVM" = xno; then
> +AC_MSG_ERROR([--enable-gallium-llvm selected but llvm-config is not
> found]) +fi
> +
>  #
>  # Vulkan driver configuration
>  #
> @@ -2327,7 +2331,7 @@ if test -n "$with_gallium_drivers"; then
>  ;;
>  xswrast)
>  HAVE_GALLIUM_SOFTPIPE=yes
> -if test "x$MESA_LLVM" = x1 && test "x$enable_gallium_llvm" ==
> "xyes";  then +if test "x$enable_gallium_llvm" = xyes; then
>  HAVE_GALLIUM_LLVMPIPE=yes
>  fi
>  ;;
> @@ -2391,7 +2395,7 @@ dnl by calling llvm-config --libs
> ${DRIVER_LLVM_COMPONENTS}, but dnl this was causing the same libraries to
> be appear multiple times dnl in LLVM_LIBS.
> 
> -if test "x$MESA_LLVM" != x0; then
> +if test "x$enable_gallium_llvm" = xyes; then
> 
>  if ! $LLVM_CONFIG --libs ${LLVM_COMPONENTS} >/dev/null; then
> AC_MSG_ERROR([Calling ${LLVM_CONFIG} failed])
> @@ -2492,8 +2496,7 @@ AM_CONDITIONAL(NEED_RADEON_DRM_WINSYS, test
> "x$HAVE_GALLIUM_R300" = xyes -o \ AM_CONDITIONAL(NEED_WINSYS_XLIB, test
> "x$enable_glx" = xgallium-xlib) AM_CONDITIONAL(NEED_RADEON_LLVM, test
> x$NEED_RADEON_LLVM = xyes)
>  AM_CONDITIONAL(HAVE_GALLIUM_COMPUTE, test x$enable_opencl = xyes)
> -AM_CONDITIONAL(HAVE_GALLIUM_LLVM, test "x$MESA_LLVM" = x1 -a \
> -   "x$enable_gallium_llvm" = xyes)
> +AM_CONDITIONAL(HAVE_GALLIUM_LLVM, test "x$enable_gallium_llvm" = xyes)
>  AM_CONDITIONAL(USE_VC4_SIMULATOR, test x$USE_VC4_SIMULATOR = xyes)
> 
>  AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
> @@ -2773,7 +2776,7 @@ else
>  fi
> 
>  echo ""
> -if test "x$MESA_LLVM" = x1; then
> +if test "x$enable_gallium_llvm" = xyes; then
>  echo "llvm:yes"
>  echo "llvm-config: $LLVM_CONFIG"
>  echo "llvm-version:$LLVM_VERSION"
> @@ -2820,7 +2823,7 @@ echo "CFLAGS:  $cflags"
>  echo "CXXFLAGS:$cxxflags"
>  echo "Macros:  $defines"
>  echo ""
> -if test "x$MESA_LLVM" = x1; then
> +if test "x$enable_gallium_llvm" = xyes; then
>  echo "LLVM_CFLAGS: $LLVM_CFLAGS"
>  echo "LLVM_CXXFLAGS:   $LLVM_CXXFLAGS"
>  echo "LLVM_CPPFLAGS:   $LLVM_CPPFLAGS"
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 14/17] configure.ac: correctly manage llvm auto-detection

[Tobias Droste]

Reviewed-by: Tobias Droste  for v2, too

Am Donnerstag, 9. Februar 2017, 20:57:45 CET schrieb Emil Velikov:
> From: Emil Velikov 
> 
> Earlier refactoring commits changed from one, dare I say it, broken
> behaviour to another. Namely:
> 
> Before, as you explicitly --enable-gallium-llvm your selection was
> ignored when llvm-config was not present/detected.
> Today, the "auto" heuristics enables gallium llvm regardless if you have
> llvm/llvm-config available or not.
> 
> Rework the auto-detection to attribute for llvm's presence.
> 
> v2: Set enable_gallium_llvm=no when LLVM is not found.
> 
> Cc: Tobias Droste 
> Cc: Samuel Pitoiset 
> Cc: "17.0" 
> Reported-by: Samuel Pitoiset 
> Signed-off-by: Emil Velikov 
> Reviewed-by: Tobias Droste  (v1)
> ---
> Samuel, v2 is a trivial change which should be a NFC.
> If you want to test it over v1 fetch
> https://github.com/evelikov/Mesa/commits/rev3.1-llvm
> ---
>  configure.ac | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 43ea9590ed..d42276aece 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1722,10 +1722,14 @@ AC_ARG_ENABLE([gallium-llvm],
>  [enable_gallium_llvm=auto])
> 
>  if test "x$enable_gallium_llvm" = xauto; then
> -case "$host_cpu" in
> -i*86|x86_64|amd64) enable_gallium_llvm=yes;;
> -*) enable_gallium_llvm=no;;
> -esac
> +if test "x$FOUND_LLVM" = xyes; then
> +case "$host_cpu" in
> +i*86|x86_64|amd64) enable_gallium_llvm=yes;;
> +*) enable_gallium_llvm=no;;
> +esac
> +else
> +enable_gallium_llvm=no
> +fi
>  fi
> 
>  if test "x$enable_gallium_llvm" = xyes -a "x$FOUND_LLVM" = xno; then
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 06/17] configure.ac: move enable-gallium-llvm dependency with-gallium-drivers

[Tobias Droste]

Am Donnerstag, 9. Februar 2017, 20:53:06 CET schrieb Emil Velikov:
> From: Emil Velikov 
> 
> ... to where it's applicable.
> 
> Since we effectively made --enable-gallium-llvm mean --enable-llvm with
> earlier commits, we need to move the requirement to guard the compnents
> added for the LLVM draw.
> 
> Otherwise we'll error (as below) when building RADV w/o gallium drivers.
> 
> configure: error: --enable-gallium-llvm is required when building radv
> 
> v2: Don't remove but move the dependency (Tobias).
> 
> Cc: Dave Airlie 
> CC: Tobias Droste 
> Cc: "17.0" 
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 4098da7666..2c7e95cf82 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1734,9 +1734,6 @@ AC_ARG_ENABLE([gallium-llvm],
>  [enable_gallium_llvm="$enableval"],
>  [enable_gallium_llvm=auto])
> 
> -if test -z "$with_gallium_drivers"; then
> -enable_gallium_llvm=no
> -fi
>  if test "x$enable_gallium_llvm" = xauto; then
>  case "$host_cpu" in
>  i*86|x86_64|amd64) enable_gallium_llvm=yes;;
> @@ -2376,7 +2373,7 @@ if test -n "$with_gallium_drivers"; then
>  done
>  fi
> 
> -if test "x$enable_gallium_llvm" == "xyes"; then
> +if test "x$enable_gallium_llvm" == "xyes" -a "$with_gallium_drivers"; then

Does this actually work? Don't you need a -n for not empty string or != "" or 
something like this? Is a lonely string a valid expression?
If it works that way:
Reviewed-by: Tobias Droste 

And btw: 
"x$enable_gallium_llvm" *==* "xyes" --> "x$enable_gallium_llvm" *=* "xyes"

before pushing this :-)

>  llvm_require_version $LLVM_REQUIRED_GALLIUM "gallium"
>  llvm_add_default_components "gallium"
>  fi
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: reduce CPU overhead merging bo lists.

[Dave Airlie]

From: Dave Airlie 

Just noticed we do a fair bit of unneeded searching here.

Since we know that the buffers in a CS are unique already,
the first time we get any buffers, we can just memcpy those into
place, and when we are searching for subsequent CSes, we only
have to search up until where the previous unique buffers were.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
index b58f5db..9e468bd 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
@@ -486,9 +486,19 @@ static int radv_amdgpu_create_bo_list(struct 
radv_amdgpu_winsys *ws,
else
cs = (struct radv_amdgpu_cs*)cs_array[i];
 
+   if (!cs->num_buffers)
+   continue;
+
+   if (unique_bo_count == 0) {
+   memcpy(handles, cs->handles, cs->num_buffers * 
sizeof(amdgpu_bo_handle));
+   memcpy(priorities, cs->priorities, 
cs->num_buffers * sizeof(uint8_t));
+   unique_bo_count = cs->num_buffers;
+   continue;
+   }
+   int unique_bo_so_far = unique_bo_count;
for (unsigned j = 0; j < cs->num_buffers; ++j) {
bool found = false;
-   for (unsigned k = 0; k < unique_bo_count; ++k) {
+   for (unsigned k = 0; k < unique_bo_so_far; ++k) 
{
if (handles[k] == cs->handles[j]) {
found = true;
priorities[k] = 
MAX2(priorities[k],
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] configure.ac: Drop LLVM compiler flags more radically

[Michel Dänzer]

On 09/02/17 10:50 PM, Emil Velikov wrote:
> On 9 February 2017 at 08:07, Michel Dänzer  wrote:
>> From: Michel Dänzer 
>>
>> Drop all -m*, -W*, -O*, -g* and -f* flags, with the exception of
>> -fno-rtti, which must be used if it's part of the llvm-config --cxxflags
>> output. We don't want LLVM to dictate the flags we use, and it can even
>> cause build failures, e.g. if LLVM and Mesa are built with different
>> compilers.
>>
> Yes, please !
> Reviewed-by: Emil Velikov 

Thanks!


> Out of curiosity:
> Are you speaking of personal experience ? What was stored in the
> c/cpp/cxx flags that triggered build failure ?

Building LLVM with clang 4.0 resulted in llvm-config --cxxflags
containing -Wstring-conversion and -fcolor-diagnostics, which aren't
supported by gcc 6.3.


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

[Mesa-dev] [Bug 99747] Problems with mesa 13.0.x and ubuntu 17.04

[bugzilla-daemon]

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

APoliTech  changed:

   What|Removed |Added

  Component|Other   |Drivers/Gallium/radeonsi
 QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org

-- 
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 99747] Problems with mesa 13.0.x and ubuntu 17.04

[bugzilla-daemon]

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

Bug ID: 99747
   Summary: Problems with mesa 13.0.x and ubuntu 17.04
   Product: Mesa
   Version: 13.0
  Hardware: x86-64 (AMD64)
OS: other
Status: NEW
  Severity: critical
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: ppolih...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 129460
  --> https://bugs.freedesktop.org/attachment.cgi?id=129460=edit
example

Description: Ubuntu Zesty Zapus (development branch)
Release: 17.04
Destro: Ubuntu Mate
Windows manager: Marco(compton GPU compositor)
Video card: Radeon RX 460 4GB 128bit
Kernel: 4.9.0-15-generic
OpenGL vendor string: X.Org

OpenGL renderer string: Gallium 0.4 on AMD POLARIS11 (DRM 3.8.0 /
4.9.0-15-generic, LLVM 3.9.1)
OpenGL core profile version string: 4.3 (Core Profile) Mesa 13.0.4
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 13.0.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

There are some artefacts if you are using a AMD video card (see the
videohttps://www.youtube.com/watch?v=qwfrTU3h6Eo)
The problem is that all the pictures that i open on this os i will see them
blue-is (look at the pics)
This problem is only for AMD cards, this bug is not present on a laptop with
intel hd 4000 video card.

-- 
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] Time to merge threaded GL dispatch? (aka glthread)

[Marek Olšák]

On Thu, Feb 9, 2017 at 8:18 PM, Marek Olšák  wrote:
> On Thu, Feb 9, 2017 at 6:23 PM, Ian Romanick  wrote:
>> On 02/09/2017 03:03 PM, Marek Olšák wrote:
>>> On Thu, Feb 9, 2017 at 1:52 PM, Ian Romanick  wrote:
 On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
> On 07.02.2017 23:54, Matt Turner wrote:
>> On Tue, Feb 7, 2017 at 10:56 AM, Marek Olšák  wrote:
>>> On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke
>>>  wrote:
 On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote:
> On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand 
> wrote:
>> FYI glmark2 segfaults with mesa_glthread=true. Expected that some
>> programs
>> will segfault?
>
> Yes, even segfaults are expected with mesa_glthread=true.
>
> Marek

 Would it make sense to be crash-free or even regression-free on at
 least Piglit, before merging?  (Or are we there already?)
>>>
>>> It's not necessary. glthread is disabled by default. Nobody has tested
>>> piglit with glthread. That will follow after it's been merged, or
>>> never if it's never merged.
>>
>> I don't understand why you're so concerned about merging untested
>> code. That violates some pretty fundamental development practices of
>> the project.
>>
>> It's exactly unfinished projects like this that cause problems and
>> inevitably have to be deleted later (ilo, openvg, d3d1x, etc). I don't
>> think it's a burden to develop something out of the master branch
>> until it's somewhat useful.
>
> The code is already somewhat useful. Actually, make that _very_ useful
> (big performance improvement) for _some_ cases.
>
> I suspect most of the people in this discussion haven't really looked at
> the code in detail (myself included). We should probably do some of that
> before it is merged, since the code isn't just a new driver that is
> isolated in its own directory. So I agree with Emil that it makes sense
> to let the patches go over the mailing list once.
>
> However, it's fine to merge this without passing piglit.

 No, it absolutely is not fine to merge.  We have never allowed such a
 thing, and I'll be damned if I'll allow this project to start.  Things
 that land that are known to be broken never actually get fixed.  Then we
 have to waste time fielding bug reports and Phoronix threads because
 users turn on the performance features and everything breaks.  It's just
 a terrible idea.
>>>
>>> It does pass piglit, but only when it's disabled.
>>>
>>> We have to ask the question of how long it will take to reach the
>>> level of perfection that some people here demand. 1 year? 2? 4 years
>>> even? Are we willing to wait that long? Is there a sufficient minimum
>>> requirement on merging this project that's possible to reach within 2
>>> weeks? Instead of saying "absolutely not" and "terrible idea", why not
>>> just say "yes if X gets done"?
>>
>> Nobody has touched this code in years, yet you're speaking as if it has
>> been in active development for the whole time.  Eric and Paul
>> implemented, found that it didn't help any applications that existed at
>> the time, and abandoned it.
>
> There are some good arguments in this thread, but it's not this one. I
> did touch the code. I made Borderlands 2 work by adding Gallium
> support, DRI3 support, and fixing race conditions and other bugs in
> the core glthread code and glapi XML files. Even though the commits
> have Eric and Paul as authors, I edited most of them in some way.
>
> So if I understand correctly, the requirement for merging is to pass
> piglit. If we drop support for compat profiles (do we need to drop
> support for GLES?), it shouldn't be too hard.

Talos Principle uses the compat profile, so we can't drop it. :(

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

Re: [Mesa-dev] [PATCH 2/2] anv/blorp: Disable partial resolves for transparent black clears

[Jason Ekstrand]

On Thu, Feb 9, 2017 at 4:45 PM, Emil Velikov 
wrote:

> On 10 February 2017 at 00:44, Emil Velikov 
> wrote:
> > On 24 January 2017 at 00:55, Nanley Chery  wrote:
> >> Cc: "13.0 17.0" 
> > Nanley please take a look at the nominations page [1] and especially
> > at the note in the end ;-)
> > That said, I've picked this for 13.0 and will do 17.0 in a few minutes.
> >
> I stand corrected - the whole function ccs_resolve_attachment() is
> missing from 13.0, so please provide separate backport if applicable.
>

This isn't a bugfix, it's a small optimization.  Please don't try and pull
it into 13.0.  17.0 is fine as it shouldn't cause harm, but it shouldn't go
further back than that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] anv/blorp: Disable partial resolves for transparent black clears

[Emil Velikov]

On 10 February 2017 at 00:44, Emil Velikov  wrote:
> On 24 January 2017 at 00:55, Nanley Chery  wrote:
>> Cc: "13.0 17.0" 
> Nanley please take a look at the nominations page [1] and especially
> at the note in the end ;-)
> That said, I've picked this for 13.0 and will do 17.0 in a few minutes.
>
I stand corrected - the whole function ccs_resolve_attachment() is
missing from 13.0, so please provide separate backport if applicable.

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

Re: [Mesa-dev] [PATCH 2/2] anv/blorp: Disable partial resolves for transparent black clears

[Emil Velikov]

On 24 January 2017 at 00:55, Nanley Chery  wrote:
> Cc: "13.0 17.0" 
Nanley please take a look at the nominations page [1] and especially
at the note in the end ;-)
That said, I've picked this for 13.0 and will do 17.0 in a few minutes.

Thanks
Emil
[1] https://www.mesa3d.org/submittingpatches.html#nominations
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 15/20] i965/vec4: consider subregister offset in live variables

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> From: "Juan A. Suarez Romero" 
>
> Take in account the offset value when getting the var from register.
>
> This is required when dealing with an operation that writes half of the
> register (like one d2x in IVB/BYT, which uses exec_size == 4).
>
> Note that for live analysis variables we need to stick to per-GRF
> analysis. In this case, we use var_from_reg() with GRF precision.

This looks bogus to me.  If the specified register had a non-zero
sub-GRF offset and we weren't taking it into account we have a bug.  The
vec4 liveness analysis pass keeps track of dataflow with 32-bit
granularity these days so we want the variable index computation to be
done with the same precision.

> ---
>  src/mesa/drivers/dri/i965/brw_vec4_live_variables.cpp | 12 
>  src/mesa/drivers/dri/i965/brw_vec4_live_variables.h   | 10 ++
>  2 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_live_variables.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_live_variables.cpp
> index 73f658cd8fa..54ebd0994ee 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_live_variables.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_live_variables.cpp
> @@ -78,7 +78,8 @@ vec4_live_variables::setup_def_use()
>   if (inst->src[i].file == VGRF) {
> for (unsigned j = 0; j < DIV_ROUND_UP(inst->size_read(i), 
> 16); j++) {
>for (int c = 0; c < 4; c++) {
> - const unsigned v = var_from_reg(alloc, inst->src[i], c, 
> j);
> + const unsigned v =
> +var_from_reg(alloc, inst->src[i], c, j, false);
>   if (!BITSET_TEST(bd->def, v))
>  BITSET_SET(bd->use, v);
>}
> @@ -101,7 +102,8 @@ vec4_live_variables::setup_def_use()
>  for (unsigned i = 0; i < DIV_ROUND_UP(inst->size_written, 16); 
> i++) {
> for (int c = 0; c < 4; c++) {
>if (inst->dst.writemask & (1 << c)) {
> - const unsigned v = var_from_reg(alloc, inst->dst, c, i);
> + const unsigned v =
> +var_from_reg(alloc, inst->dst, c, i, false);
>   if (!BITSET_TEST(bd->use, v))
>  BITSET_SET(bd->def, v);
>}
> @@ -257,7 +259,8 @@ vec4_visitor::calculate_live_intervals()
>if (inst->src[i].file == VGRF) {
>  for (unsigned j = 0; j < DIV_ROUND_UP(inst->size_read(i), 16); 
> j++) {
> for (int c = 0; c < 4; c++) {
> -  const unsigned v = var_from_reg(alloc, inst->src[i], c, j);
> +  const unsigned v =
> + var_from_reg(alloc, inst->src[i], c, j, false);
>start[v] = MIN2(start[v], ip);
>end[v] = ip;
> }
> @@ -269,7 +272,8 @@ vec4_visitor::calculate_live_intervals()
>   for (unsigned i = 0; i < DIV_ROUND_UP(inst->size_written, 16); i++) 
> {
>  for (int c = 0; c < 4; c++) {
> if (inst->dst.writemask & (1 << c)) {
> -  const unsigned v = var_from_reg(alloc, inst->dst, c, i);
> +  const unsigned v =
> + var_from_reg(alloc, inst->dst, c, i, false);
>start[v] = MIN2(start[v], ip);
>end[v] = ip;
> }
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_live_variables.h 
> b/src/mesa/drivers/dri/i965/brw_vec4_live_variables.h
> index 8807c453743..9c505d15f1f 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_live_variables.h
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_live_variables.h
> @@ -83,13 +83,14 @@ protected:
>   */
>  inline unsigned
>  var_from_reg(const simple_allocator , const src_reg ,
> - unsigned c = 0, unsigned k = 0)
> + unsigned c = 0, unsigned k = 0, bool subreg_precision = true)
>  {
> assert(reg.file == VGRF && reg.nr < alloc.count && c < 4);
> const unsigned csize = DIV_ROUND_UP(type_sz(reg.type), 4);
> unsigned result =
>8 * (alloc.offsets[reg.nr] + reg.offset / REG_SIZE) +
> -  (BRW_GET_SWZ(reg.swizzle, c) + k / csize * 4) * csize + k % csize;
> +  (BRW_GET_SWZ(reg.swizzle, c) + k / csize * 4) * csize + k % csize +
> +  (subreg_precision ? (reg.offset % REG_SIZE) / type_sz(reg.type) : 0);
> /* Do not exceed the limit for this register */
> assert(result < 8 * (alloc.offsets[reg.nr] + alloc.sizes[reg.nr]));
> return result;
> @@ -97,13 +98,14 @@ var_from_reg(const simple_allocator , const src_reg 
> ,
>  
>  inline unsigned
>  var_from_reg(const simple_allocator , const dst_reg ,
> - unsigned c = 0, unsigned k = 0)
> + unsigned c = 0, unsigned k = 0, bool subreg_precision = true)
>  {
> assert(reg.file == VGRF && reg.nr < alloc.count && c < 4);
> 

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Eric Anholt]

Ian Romanick  writes:

> [ Unknown signature status ]
> On 02/09/2017 05:14 PM, Eric Anholt wrote:
>> Ian Romanick  writes:
>> 
>>> On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
 On 07.02.2017 23:54, Matt Turner wrote:
> On Tue, Feb 7, 2017 at 10:56 AM, Marek Olšák  wrote:
>> On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke
>>  wrote:
>>> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote:
 On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand 
 wrote:
> FYI glmark2 segfaults with mesa_glthread=true. Expected that some
> programs
> will segfault?

 Yes, even segfaults are expected with mesa_glthread=true.

 Marek
>>>
>>> Would it make sense to be crash-free or even regression-free on at
>>> least Piglit, before merging?  (Or are we there already?)
>>
>> It's not necessary. glthread is disabled by default. Nobody has tested
>> piglit with glthread. That will follow after it's been merged, or
>> never if it's never merged.
>
> I don't understand why you're so concerned about merging untested
> code. That violates some pretty fundamental development practices of
> the project.
>
> It's exactly unfinished projects like this that cause problems and
> inevitably have to be deleted later (ilo, openvg, d3d1x, etc). I don't
> think it's a burden to develop something out of the master branch
> until it's somewhat useful.

 The code is already somewhat useful. Actually, make that _very_ useful
 (big performance improvement) for _some_ cases.

 I suspect most of the people in this discussion haven't really looked at
 the code in detail (myself included). We should probably do some of that
 before it is merged, since the code isn't just a new driver that is
 isolated in its own directory. So I agree with Emil that it makes sense
 to let the patches go over the mailing list once.

 However, it's fine to merge this without passing piglit.
>>>
>>> No, it absolutely is not fine to merge.  We have never allowed such a
>>> thing, and I'll be damned if I'll allow this project to start.  Things
>>> that land that are known to be broken never actually get fixed.  Then we
>>> have to waste time fielding bug reports and Phoronix threads because
>>> users turn on the performance features and everything breaks.  It's just
>>> a terrible idea.
>> 
>> Yeah, just like how we gated the GLSL compiler until it was completely
>> done (we didn't) and NIR until it was completely done (we didn't) and
>> Vulkan until it was completely done (we didn't) and...
>
> But we did require that it pass the test suites.  All of that lived in
> branches for a really long time with active development.  The GLSL
> compiler and NIR are two examples that support my claim.  Those were
> massive branch merges that waited much longer to merge than the people
> working on them wanted.

We also didn't port fragment programs and fixed function over to the new
backend for a long time because it was thoroughly incomplete, and that
kept our tests running.  We hid the i965 GLSL IR VS under an environment
variable while we were finishing it, too.

git log -p | grep INTEL_USE_NIR will give you a whole lot of more recent
commits about how in the Intel driver it's normal to land code that's in
progress before it's completely done, hidden under an env var.


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

[Mesa-dev] [PATCH] util/disk_cache: use stat() to check if entry is a directory

[Timothy Arceri]

d_type is not supported on all systems.

Tested-by: Vinson Lee 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97967
---
 src/util/disk_cache.c | 33 -
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 75c7334..660fa4f 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -436,7 +436,8 @@ make_cache_file_directory(struct disk_cache *cache, 
cache_key key)
  */
 static char *
 choose_random_file_matching(const char *dir_path,
-bool (*predicate)(struct dirent *))
+bool (*predicate)(struct dirent *,
+  const char *dir_path))
 {
DIR *dir;
struct dirent *entry;
@@ -453,7 +454,7 @@ choose_random_file_matching(const char *dir_path,
   entry = readdir(dir);
   if (entry == NULL)
  break;
-  if (! predicate(entry))
+  if (!predicate(entry, dir_path))
  continue;
 
   count++;
@@ -473,7 +474,7 @@ choose_random_file_matching(const char *dir_path,
   entry = readdir(dir);
   if (entry == NULL)
  break;
-  if (! predicate(entry))
+  if (!predicate(entry, dir_path))
  continue;
   if (count == victim)
  break;
@@ -498,14 +499,20 @@ choose_random_file_matching(const char *dir_path,
  * ".tmp"
  */
 static bool
-is_regular_non_tmp_file(struct dirent *entry)
+is_regular_non_tmp_file(struct dirent *entry, const char *path)
 {
-   size_t len;
+   char *filename;
+   if (asprintf(, "%s/%s", path, entry->d_name) == -1)
+  return false;
+
+   struct stat sb;
+   stat(filename, );
+   free(filename);
 
-   if (entry->d_type != DT_REG)
+   if (!S_ISREG(sb.st_mode))
   return false;
 
-   len = strlen (entry->d_name);
+   size_t len = strlen (entry->d_name);
if (len >= 4 && strcmp(>d_name[len-4], ".tmp") == 0)
   return false;
 
@@ -539,9 +546,17 @@ unlink_random_file_from_directory(const char *path)
  * special name of "..")
  */
 static bool
-is_two_character_sub_directory(struct dirent *entry)
+is_two_character_sub_directory(struct dirent *entry, const char *path)
 {
-   if (entry->d_type != DT_DIR)
+   char *subdir;
+   if (asprintf(, "%s/%s", path, entry->d_name) == -1)
+  return false;
+
+   struct stat sb;
+   stat(path, );
+   free(subdir);
+
+   if (!S_ISDIR(sb.st_mode))
   return false;
 
if (strlen(entry->d_name) != 2)
-- 
2.9.3

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

[Mesa-dev] [PATCH 1/2] intel/blorp: Swizzle clear colors on the CPU

[Jason Ekstrand]

It's trivial to swizzle clear colors on the CPU, easily deals with the
hardware restrictions for render target swizzles, and makes swizzled
clears work on all hardware as opposed to just HSW+.
---
 src/intel/blorp/blorp_clear.c | 48 +++
 1 file changed, 30 insertions(+), 18 deletions(-)

diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
index 8ea22ac..4d63bbe 100644
--- a/src/intel/blorp/blorp_clear.c
+++ b/src/intel/blorp/blorp_clear.c
@@ -328,6 +328,26 @@ blorp_fast_clear(struct blorp_batch *batch,
batch->blorp->exec(batch, );
 }
 
+static union isl_color_value
+swizzle_color_value(union isl_color_value src, struct isl_swizzle swizzle)
+{
+   union isl_color_value dst = { .u32 = { 0, } };
+
+   /* We assign colors in ABGR order so that the first one will be taken in
+* RGBA precedence order.  According to the PRM docs for shader channel
+* select, this matches Haswell hardware behavior.
+*/
+   if ((unsigned)(swizzle.a - ISL_CHANNEL_SELECT_RED) < 4)
+  dst.u32[swizzle.a - ISL_CHANNEL_SELECT_RED] = src.u32[3];
+   if ((unsigned)(swizzle.b - ISL_CHANNEL_SELECT_RED) < 4)
+  dst.u32[swizzle.b - ISL_CHANNEL_SELECT_RED] = src.u32[2];
+   if ((unsigned)(swizzle.g - ISL_CHANNEL_SELECT_RED) < 4)
+  dst.u32[swizzle.g - ISL_CHANNEL_SELECT_RED] = src.u32[1];
+   if ((unsigned)(swizzle.r - ISL_CHANNEL_SELECT_RED) < 4)
+  dst.u32[swizzle.r - ISL_CHANNEL_SELECT_RED] = src.u32[0];
+
+   return dst;
+}
 
 void
 blorp_clear(struct blorp_batch *batch,
@@ -346,6 +366,14 @@ blorp_clear(struct blorp_batch *batch,
params.x1 = x1;
params.y1 = y1;
 
+   /* Manually apply the clear destination swizzle.  This way swizzled clears
+* will work for swizzles which we can't normally use for rendering and it
+* also ensures that they work on pre-Haswell hardware which can't swizlle
+* at all.
+*/
+   clear_color = swizzle_color_value(clear_color, swizzle);
+   swizzle = ISL_SWIZZLE_IDENTITY;
+
if (format == ISL_FORMAT_R9G9B9E5_SHAREDEXP) {
   clear_color.u32[0] = float3_to_rgb9e5(clear_color.f32);
   format = ISL_FORMAT_R32_UINT;
@@ -353,24 +381,8 @@ blorp_clear(struct blorp_batch *batch,
   /* Broadwell and earlier cannot render to this format so we need to work
* around it by swapping the colors around and using B4G4R4A4 instead.
*/
-
-  /* First, we apply the swizzle. */
-  union isl_color_value old;
-  assert((unsigned)(swizzle.r - ISL_CHANNEL_SELECT_RED) < 4);
-  assert((unsigned)(swizzle.g - ISL_CHANNEL_SELECT_RED) < 4);
-  assert((unsigned)(swizzle.b - ISL_CHANNEL_SELECT_RED) < 4);
-  assert((unsigned)(swizzle.a - ISL_CHANNEL_SELECT_RED) < 4);
-  old.u32[swizzle.r - ISL_CHANNEL_SELECT_RED] = clear_color.u32[0];
-  old.u32[swizzle.g - ISL_CHANNEL_SELECT_RED] = clear_color.u32[1];
-  old.u32[swizzle.b - ISL_CHANNEL_SELECT_RED] = clear_color.u32[2];
-  old.u32[swizzle.a - ISL_CHANNEL_SELECT_RED] = clear_color.u32[3];
-  swizzle = ISL_SWIZZLE_IDENTITY;
-
-  /* Now we re-order for the new format */
-  clear_color.u32[0] = old.u32[1];
-  clear_color.u32[1] = old.u32[2];
-  clear_color.u32[2] = old.u32[3];
-  clear_color.u32[3] = old.u32[0];
+  const struct isl_swizzle ARGB = ISL_SWIZZLE(ALPHA, RED, GREEN, BLUE);
+  clear_color = swizzle_color_value(clear_color, ARGB);
   format = ISL_FORMAT_B4G4R4A4_UNORM;
}
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 2/2] anv/blorp: Don't sanitize the swizzle for blorp_clear

[Jason Ekstrand]

BLORP is now smart enough to handle any swizzle (even those that contain
ZERO or ONE) in a reasonable manner.  Just let BLORP handle it.  This
fixes the following Vulkan CTS tests on Haswell:

 - dEQP-VK.api.image_clearing.clear_color_image.1d_b4g4r4a4_unorm_pack16
 - dEQP-VK.api.image_clearing.clear_color_image.2d_b4g4r4a4_unorm_pack16
 - dEQP-VK.api.image_clearing.clear_color_image.3d_b4g4r4a4_unorm_pack16
---
 src/intel/vulkan/anv_blorp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 759d2ae..4e7078b 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -832,8 +832,7 @@ void anv_CmdClearColorImage(
  }
 
  blorp_clear(, ,
- src_format.isl_format,
- anv_swizzle_for_render(src_format.swizzle),
+ src_format.isl_format, src_format.swizzle,
  level, base_layer, layer_count,
  0, 0, level_width, level_height,
  vk_to_isl_color(*pColor), color_write_disable);
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [Bug 97967] glsl/tests/cache-test regression

[bugzilla-daemon]

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

--- Comment #19 from Vinson Lee  ---
Applied attachment 129406. make check passes.


   Mesa 17.1.0-devel: src/compiler/test-suite.log


# TOTAL: 10
# PASS:  10
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2


Tested-by: Vinson Lee 

-- 
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] loader: unconditionally include unistd.h and stdlib.h

[Emil Velikov]

From: Nicolai Hähnle 

Otherwise we would fail with "implicit declaration of function" geteuid
and getenv respectively.

To trigger (re)move the libdrm.pc file and use the following:

 $ ./autogen.sh --disable-egl --disable-gbm --disable-dri \
--with-dri-drivers=swrast --with-gallium-drivers=swrast
 $ make

Cc: Vinson Lee 
Cc: Nicolai Hähnle 
Fixes: 3f462050c ("loader: Add an environment variable to override driver name 
choice.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99701
v2: [Emil: handle stdlib.h add commit message]
Signed-off-by: Emil Velikov 
---
Vinson, Nicolai, I've reproduced the issue and this patch should resolve
it completely.
---
 src/loader/loader.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 4825151ad5..3b28a0e7db 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #ifdef MAJOR_IN_MKDEV
 #include 
 #endif
@@ -42,8 +44,6 @@
 #include "loader.h"
 
 #ifdef HAVE_LIBDRM
-#include 
-#include 
 #include 
 #ifdef USE_DRICONF
 #include "xmlconfig.h"
-- 
2.11.0

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

[Mesa-dev] [Bug 99701] loader.c:353:8: error: implicit declaration of function 'geteuid' is invalid in C99 [-Werror, -Wimplicit-function-declaration]

[bugzilla-daemon]

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

--- Comment #3 from Vinson Lee  ---
Applied attachment 129378. The build still fails.

$ ./autogen.sh --disable-egl --disable-gbm --disable-dri
--with-dri-drivers=swrast --with-gallium-drivers=swrast
$ make
[...]
  CC libloader_la-loader.lo
loader.c: In function ‘loader_get_driver_for_fd’:
loader.c:355: error: implicit declaration of function ‘getenv’

-- 
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 3/4] util: Change util/set to use quadratic probing

[Jan Ziak]

Hello

IMPORTANT NOTE: Using the uint32_t data type, quad_hash*quad_hash will
overflow as soon as the hash table has more than 2**16=65536=64K
elements. To enable more than 64K elements in hash table, the data
types need to be changed to uint64_t - unfortunately uint64_t
arithmetic operations will slow down the hash table in 32-bit OpenGL
apps.

OPTIMIZATION: All "} while (hash_address != start_hash_address);" can
be replaced with "} while (1);" assuming that the hash table always
contains at least several free/unallocated entries. This optimization
applies both to current mesa-git and to the quadratic probing patch.
For quadratic probing this optimization works if the statement "values
of h(k,i) for i in [0,m-1] are all distinct" at
https://en.wikipedia.org/wiki/Quadratic_probing is correct.

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

[Mesa-dev] [PATCH v2 14/17] configure.ac: correctly manage llvm auto-detection

[Emil Velikov]

From: Emil Velikov 

Earlier refactoring commits changed from one, dare I say it, broken
behaviour to another. Namely:

Before, as you explicitly --enable-gallium-llvm your selection was
ignored when llvm-config was not present/detected.
Today, the "auto" heuristics enables gallium llvm regardless if you have
llvm/llvm-config available or not.

Rework the auto-detection to attribute for llvm's presence.

v2: Set enable_gallium_llvm=no when LLVM is not found.

Cc: Tobias Droste 
Cc: Samuel Pitoiset 
Cc: "17.0" 
Reported-by: Samuel Pitoiset 
Signed-off-by: Emil Velikov 
Reviewed-by: Tobias Droste  (v1)
---
Samuel, v2 is a trivial change which should be a NFC.
If you want to test it over v1 fetch 
https://github.com/evelikov/Mesa/commits/rev3.1-llvm
---
 configure.ac | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 43ea9590ed..d42276aece 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1722,10 +1722,14 @@ AC_ARG_ENABLE([gallium-llvm],
 [enable_gallium_llvm=auto])
 
 if test "x$enable_gallium_llvm" = xauto; then
-case "$host_cpu" in
-i*86|x86_64|amd64) enable_gallium_llvm=yes;;
-*) enable_gallium_llvm=no;;
-esac
+if test "x$FOUND_LLVM" = xyes; then
+case "$host_cpu" in
+i*86|x86_64|amd64) enable_gallium_llvm=yes;;
+*) enable_gallium_llvm=no;;
+esac
+else
+enable_gallium_llvm=no
+fi
 fi
 
 if test "x$enable_gallium_llvm" = xyes -a "x$FOUND_LLVM" = xno; then
-- 
2.11.0

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

[Mesa-dev] [PATCH v2 07/17] configure.ac: Rework MESA_LLVM and LLVM detection

[Emil Velikov]

From: Tobias Droste 

Set FOUND_LLVM only when LLVM is present (checking for exact version/etc
is deferred) and use enable-gallium-llvm to indicate the global LLVM
status.

Renaming the latter is not appropriate for stable patches, so we'll
address it with a later commit.

Loosely based on work by Tobias.

v2: Check FOUND_LLVM if enable_gallium_llvm is set.

Cc: Dave Airlie 
Cc: "17.0" 
Signed-off-by: Emil Velikov 
Reviewed-by: Tobias Droste  (v1)
---
 configure.ac | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index 2c7e95cf82..8d8328b451 100644
--- a/configure.ac
+++ b/configure.ac
@@ -953,9 +953,9 @@ llvm_set_environment_variables() {
 fi
 
 DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT 
-DMESA_LLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
-MESA_LLVM=1
+FOUND_LLVM=yes
 else
-MESA_LLVM=0
+FOUND_LLVM=no
 LLVM_VERSION_INT=0
 fi
 }
@@ -967,10 +967,6 @@ require_llvm() {
 }
 
 llvm_require_version() {
-if test "x$MESA_LLVM" = x0; then
-AC_MSG_ERROR([LLVM $1 or newer is required for $2])
-return
-fi
 require_llvm $2
 
 llvm_target_version_major=`echo $1 | cut -d. -f1 | egrep -o '^[[0-9]]+'`
@@ -1728,6 +1724,10 @@ fi
 dnl
 dnl Gallium LLVM
 dnl
+dnl With follow-up commits we'll rework --enable-gallium-llvm to --enable-llvm
+dnl Since that is too invasive to stable, do the more conservative thing for 
now
+dnl and consider it as a global LLVM toggle.
+dnl
 AC_ARG_ENABLE([gallium-llvm],
 [AS_HELP_STRING([--enable-gallium-llvm],
 [build gallium LLVM support @<:@default=enabled on x86/x86_64@:>@])],
@@ -1740,6 +1740,10 @@ if test "x$enable_gallium_llvm" = xauto; then
 esac
 fi
 
+if test "x$enable_gallium_llvm" = xyes -a "x$FOUND_LLVM" = xno; then
+AC_MSG_ERROR([--enable-gallium-llvm selected but llvm-config is not found])
+fi
+
 #
 # Vulkan driver configuration
 #
@@ -2327,7 +2331,7 @@ if test -n "$with_gallium_drivers"; then
 ;;
 xswrast)
 HAVE_GALLIUM_SOFTPIPE=yes
-if test "x$MESA_LLVM" = x1 && test "x$enable_gallium_llvm" == 
"xyes";  then
+if test "x$enable_gallium_llvm" = xyes; then
 HAVE_GALLIUM_LLVMPIPE=yes
 fi
 ;;
@@ -2391,7 +2395,7 @@ dnl by calling llvm-config --libs 
${DRIVER_LLVM_COMPONENTS}, but
 dnl this was causing the same libraries to be appear multiple times
 dnl in LLVM_LIBS.
 
-if test "x$MESA_LLVM" != x0; then
+if test "x$enable_gallium_llvm" = xyes; then
 
 if ! $LLVM_CONFIG --libs ${LLVM_COMPONENTS} >/dev/null; then
AC_MSG_ERROR([Calling ${LLVM_CONFIG} failed])
@@ -2492,8 +2496,7 @@ AM_CONDITIONAL(NEED_RADEON_DRM_WINSYS, test 
"x$HAVE_GALLIUM_R300" = xyes -o \
 AM_CONDITIONAL(NEED_WINSYS_XLIB, test "x$enable_glx" = xgallium-xlib)
 AM_CONDITIONAL(NEED_RADEON_LLVM, test x$NEED_RADEON_LLVM = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_COMPUTE, test x$enable_opencl = xyes)
-AM_CONDITIONAL(HAVE_GALLIUM_LLVM, test "x$MESA_LLVM" = x1 -a \
-   "x$enable_gallium_llvm" = xyes)
+AM_CONDITIONAL(HAVE_GALLIUM_LLVM, test "x$enable_gallium_llvm" = xyes)
 AM_CONDITIONAL(USE_VC4_SIMULATOR, test x$USE_VC4_SIMULATOR = xyes)
 
 AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
@@ -2773,7 +2776,7 @@ else
 fi
 
 echo ""
-if test "x$MESA_LLVM" = x1; then
+if test "x$enable_gallium_llvm" = xyes; then
 echo "llvm:yes"
 echo "llvm-config: $LLVM_CONFIG"
 echo "llvm-version:$LLVM_VERSION"
@@ -2820,7 +2823,7 @@ echo "CFLAGS:  $cflags"
 echo "CXXFLAGS:$cxxflags"
 echo "Macros:  $defines"
 echo ""
-if test "x$MESA_LLVM" = x1; then
+if test "x$enable_gallium_llvm" = xyes; then
 echo "LLVM_CFLAGS: $LLVM_CFLAGS"
 echo "LLVM_CXXFLAGS:   $LLVM_CXXFLAGS"
 echo "LLVM_CPPFLAGS:   $LLVM_CPPFLAGS"
-- 
2.11.0

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

[Mesa-dev] [PATCH v2 06/17] configure.ac: move enable-gallium-llvm dependency with-gallium-drivers

[Emil Velikov]

From: Emil Velikov 

... to where it's applicable.

Since we effectively made --enable-gallium-llvm mean --enable-llvm with
earlier commits, we need to move the requirement to guard the compnents
added for the LLVM draw.

Otherwise we'll error (as below) when building RADV w/o gallium drivers.

configure: error: --enable-gallium-llvm is required when building radv

v2: Don't remove but move the dependency (Tobias).

Cc: Dave Airlie 
CC: Tobias Droste 
Cc: "17.0" 
Signed-off-by: Emil Velikov 
---
 configure.ac | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4098da7666..2c7e95cf82 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1734,9 +1734,6 @@ AC_ARG_ENABLE([gallium-llvm],
 [enable_gallium_llvm="$enableval"],
 [enable_gallium_llvm=auto])
 
-if test -z "$with_gallium_drivers"; then
-enable_gallium_llvm=no
-fi
 if test "x$enable_gallium_llvm" = xauto; then
 case "$host_cpu" in
 i*86|x86_64|amd64) enable_gallium_llvm=yes;;
@@ -2376,7 +2373,7 @@ if test -n "$with_gallium_drivers"; then
 done
 fi
 
-if test "x$enable_gallium_llvm" == "xyes"; then
+if test "x$enable_gallium_llvm" == "xyes" -a "$with_gallium_drivers"; then
 llvm_require_version $LLVM_REQUIRED_GALLIUM "gallium"
 llvm_add_default_components "gallium"
 fi
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH] nvc0/ir: fix ubo max clamp, reset file index

[Samuel Pitoiset]

Nice catch.

Reviewed-by: Samuel Pitoiset 

On 02/09/2017 09:37 PM, Ilia Mirkin wrote:

We just increased the max UBO, so we should also increase the clamp that
we do for robustness. Similarly, as we're including the fileIndex in the
new indirect value, we should reset fileIndex to 0 so that it is not
added in a second time.

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 0633767..ba22740 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -2407,10 +2407,12 @@ NVC0LoweringPass::handleLDST(Instruction *i)
  if (ind) {
 // Clamp the UBO index when an indirect access is used to avoid
 // loading information from the wrong place in the driver cb.
+// TODO - synchronize the max with the driver.
 ind = bld.mkOp2v(OP_MIN, TYPE_U32, ind,
  bld.mkOp2v(OP_ADD, TYPE_U32, bld.getSSA(),
 ind, bld.loadImm(NULL, fileIndex)),
- bld.loadImm(NULL, 12));
+ bld.loadImm(NULL, 13));
+fileIndex = 0;
  }

  Value *offset = bld.loadImm(NULL, i->getSrc(0)->reg.data.offset + 
typeSizeof(i->sType));


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

[Mesa-dev] [PATCH] nvc0/ir: fix ubo max clamp, reset file index

[Ilia Mirkin]

We just increased the max UBO, so we should also increase the clamp that
we do for robustness. Similarly, as we're including the fileIndex in the
new indirect value, we should reset fileIndex to 0 so that it is not
added in a second time.

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 0633767..ba22740 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -2407,10 +2407,12 @@ NVC0LoweringPass::handleLDST(Instruction *i)
  if (ind) {
 // Clamp the UBO index when an indirect access is used to avoid
 // loading information from the wrong place in the driver cb.
+// TODO - synchronize the max with the driver.
 ind = bld.mkOp2v(OP_MIN, TYPE_U32, ind,
  bld.mkOp2v(OP_ADD, TYPE_U32, bld.getSSA(),
 ind, bld.loadImm(NULL, fileIndex)),
- bld.loadImm(NULL, 12));
+ bld.loadImm(NULL, 13));
+fileIndex = 0;
  }
 
  Value *offset = bld.loadImm(NULL, i->getSrc(0)->reg.data.offset + 
typeSizeof(i->sType));
-- 
2.10.2

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

Re: [Mesa-dev] [PATCH v2 09/20] i965/fs: indirect addressing with doubles is not supported in IVB/BYT

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> It is tested empirically that IVB/BYT don't support indirect addressing
> with doubles but it is not documented in the PRM.
>
> This patch applies the same solution than for Cherryview/Broxton and
> takes into account that we cannot double the stride, since the
> hardware will do it internally.
>
> v2:
> - Fix assert to take into account Indirect DF MOVs in IVB and HSW.
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 27 
> ++
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp   | 11 ++-
>  2 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> index 487f2e90224..dd6cbab773c 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> @@ -418,18 +418,29 @@ fs_generator::generate_mov_indirect(fs_inst *inst,
>brw_MOV(p, dst, reg);
> } else {
>/* Prior to Broadwell, there are only 8 address registers. */
> -  assert(inst->exec_size == 8 || devinfo->gen >= 8);
> +  assert(inst->exec_size == 8 || devinfo->gen >= 8 ||
> + (devinfo->gen == 7 && inst->exec_size < 8 &&
> +  (type_sz(reg.type) == 8 || type_sz(dst.type) == 8)));
>  
>/* We use VxH indirect addressing, clobbering a0.0 through a0.7. */
>struct brw_reg addr = vec8(brw_address_reg(0));
>  
> -  /* The destination stride of an instruction (in bytes) must be greater
> -   * than or equal to the size of the rest of the instruction.  Since the
> -   * address register is of type UW, we can't use a D-type instruction.
> -   * In order to get around this, re retype to UW and use a stride.
> -   */
> -  indirect_byte_offset =
> - retype(spread(indirect_byte_offset, 2), BRW_REGISTER_TYPE_UW);
> +  if (devinfo->gen != 7 || devinfo->is_haswell || type_sz(reg.type) != 
> 8) {
> + /* The destination stride of an instruction (in bytes) must be 
> greater
> +  * than or equal to the size of the rest of the instruction.  Since 
> the
> +  * address register is of type UW, we can't use a D-type 
> instruction.
> +  * In order to get around this, re retype to UW and use a stride.
> +  */
> + indirect_byte_offset =
> +retype(spread(indirect_byte_offset, 2), BRW_REGISTER_TYPE_UW);
> +  } else {
> + /* In Ivybridge/Baytrail, when it operates with DF operands, we
> +  * cannot double the stride, since the hardware will do it
> +  * internally. Tested empirically.
> +  */
> + indirect_byte_offset =
> +retype(indirect_byte_offset, BRW_REGISTER_TYPE_UW);
> +  }

This doesn't make any sense, indirect_byte_offset is a 32-bit integer
type regardless of the type of the data you're copying, the hardware
won't do any stride doubling for you here.

I've verified on IVB hardware that indirect addressing works for 64-bit
moves, but getting it to do what you want is a bit trickier than on more
recent hardware -- I'll reply with a patch that gets it working.

>  
>/* There are a number of reasons why we don't use the base offset here.
> * One reason is that the field is only 9 bits which means we can only
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> index 8f745dff440..85f43b7b144 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> @@ -3822,17 +3822,18 @@ fs_visitor::nir_emit_intrinsic(const fs_builder , 
> nir_intrinsic_instr *instr
>  (instr->num_components - 1) * type_sz(dest.type);
>  
>   fs_reg indirect_chv_high_32bit;
> - bool is_chv_bxt_64bit =
> -(devinfo->is_cherryview || devinfo->is_broxton) &&
> -type_sz(dest.type) == 8;
> - if (is_chv_bxt_64bit) {
> + bool is_ivb_byt_chv_bxt_64bit =

Let's use a more sensible name here like "supports_64bit_indirects" and
mark as const...  Or just remove the variable altogether and fold this
into the condition of the second if statement below.

> +(devinfo->is_cherryview || devinfo->is_broxton ||
> + devinfo->is_ivybridge || devinfo->is_baytrail) &&
> +   type_sz(dest.type) == 8;
> + if (is_ivb_byt_chv_bxt_64bit) {
>  indirect_chv_high_32bit = vgrf(glsl_type::uint_type);
>  /* Calculate indirect address to read high 32 bits */
>  bld.ADD(indirect_chv_high_32bit, indirect, brw_imm_ud(4));

The ADD and temporary seem redundant, you could take into account the
additional 32bit offset by applying an immediate offset to the 'src'
region used below.

>   }
>  
>   for (unsigned j = 0; j < instr->num_components; 

Re: [Mesa-dev] [PATCH v2 3/5] anv: Add support for the PMA fix on Broadwell

[Jason Ekstrand]

On Thu, Feb 9, 2017 at 10:33 AM, Nanley Chery  wrote:

> On Wed, Feb 08, 2017 at 06:27:52PM -0800, Jason Ekstrand wrote:
> > On Wed, Feb 8, 2017 at 5:34 PM, Nanley Chery 
> wrote:
> >
> > > On Thu, Feb 02, 2017 at 01:26:05PM -0800, Jason Ekstrand wrote:
> > > > In order to get good performance numbers for this, I had to hack up
> the
> > > > driver to whack wm_prog_data::uses_kill to true to emulate a discard
> and
> > > > used the Sascha "shadowmapping" demo.  Setting uses_kill to true
> dropped
> > > > the framerate on the demo by 25-30%.  Enabling the PMA fix brought it
> > > > back up to around 90% of the original framerate.  This doesn't seem
> to
> > > > really impact Dota 2;  probably because it doesn't use 16-bit depth.
> > > >
> > > > Reviewed-by: Lionel Landwerlin 
> > > > ---
> > > >  src/intel/vulkan/TODO  |   1 -
> > > >  src/intel/vulkan/anv_cmd_buffer.c  |   2 +
> > > >  src/intel/vulkan/anv_genX.h|   3 +
> > > >  src/intel/vulkan/anv_private.h |  17 +
> > > >  src/intel/vulkan/gen7_cmd_buffer.c |   7 ++
> > > >  src/intel/vulkan/gen8_cmd_buffer.c | 133
> ++
> > > +++
> > > >  src/intel/vulkan/genX_blorp_exec.c |   5 ++
> > > >  src/intel/vulkan/genX_cmd_buffer.c |  15 -
> > > >  src/intel/vulkan/genX_pipeline.c   |  38 +++
> > > >  9 files changed, 219 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/src/intel/vulkan/TODO b/src/intel/vulkan/TODO
> > > > index 38acc0d..f8b73a1 100644
> > > > --- a/src/intel/vulkan/TODO
> > > > +++ b/src/intel/vulkan/TODO
> > > > @@ -12,5 +12,4 @@ Performance:
> > > >   - Compressed multisample support
> > > >   - Pushing pieces of UBOs?
> > > >   - Enable guardband clipping
> > > > - - pma stall workaround
> > > >   - Use soft-pin to avoid relocations
> > > > diff --git a/src/intel/vulkan/anv_cmd_buffer.c
> > > b/src/intel/vulkan/anv_cmd_buffer.c
> > > > index 5886fa6..8c08f8d 100644
> > > > --- a/src/intel/vulkan/anv_cmd_buffer.c
> > > > +++ b/src/intel/vulkan/anv_cmd_buffer.c
> > > > @@ -135,6 +135,8 @@ anv_cmd_state_reset(struct anv_cmd_buffer
> > > *cmd_buffer)
> > > > state->restart_index = UINT32_MAX;
> > > > state->dynamic = default_dynamic_state;
> > > > state->need_query_wa = true;
> > > > +   state->pma_fix_enabled = false;
> > > > +   state->hiz_enabled = false;
> > > >
> > > > if (state->attachments != NULL) {
> > > >vk_free(_buffer->pool->alloc, state->attachments);
> > > > diff --git a/src/intel/vulkan/anv_genX.h
> b/src/intel/vulkan/anv_genX.h
> > > > index d04fe38..67147b0 100644
> > > > --- a/src/intel/vulkan/anv_genX.h
> > > > +++ b/src/intel/vulkan/anv_genX.h
> > > > @@ -55,6 +55,9 @@ void genX(cmd_buffer_flush_dynamic_state)(struct
> > > anv_cmd_buffer *cmd_buffer);
> > > >
> > > >  void genX(cmd_buffer_flush_compute_state)(struct anv_cmd_buffer
> > > *cmd_buffer);
> > > >
> > > > +void genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer
> *cmd_buffer,
> > > > + bool enable);
> > > > +
> > > >  void
> > > >  genX(emit_urb_setup)(struct anv_device *device, struct anv_batch
> *batch,
> > > >   const struct gen_l3_config *l3_config,
> > > > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> > > private.h
> > > > index 4fe3ebc..6efe4ea 100644
> > > > --- a/src/intel/vulkan/anv_private.h
> > > > +++ b/src/intel/vulkan/anv_private.h
> > > > @@ -1163,6 +1163,20 @@ struct anv_cmd_state {
> > > > bool need_query_wa;
> > > >
> > > > /**
> > > > +* Whether or not the gen8 PMA fix is enabled.  We ensure that,
> at
> > > the top
> > > > +* of any command buffer it disabled by disabling it in
> > > EndCommandBuffer
> > >  ^
> > >  is?
> > >
>
> Fixed?
>

done


> > > > +* and before invoking the secondary in ExecuteCommands.
> > > > +*/
> > > > +   bool pma_fix_enabled;
> > > > +
> > > > +   /**
> > > > +* Whether or not we now for certain that HiZ is enabled for the
> > > current
> > >^
> > >know
> > >
>
> Fixed?
>

done


> > > > +* subpass.  If, for whatever reason, we are unsure as to whether
> > > HiZ is
> > > > +* enabled or not, this will be false.
> > > > +*/
> > > > +   bool hiz_enabled;
> > > > +
> > > > +   /**
> > > >  * Array length is anv_cmd_state::pass::attachment_count. Array
> > > content is
> > > >  * valid only when recording a render pass instance.
> > > >  */
> > > > @@ -1465,8 +1479,11 @@ struct anv_pipeline {
> > > >
> > > > uint32_t cs_right_mask;
> > > >
> > > > +   bool writes_depth;
> > > > +   bool  

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Marek Olšák]

On Thu, Feb 9, 2017 at 6:23 PM, Ian Romanick  wrote:
> On 02/09/2017 03:03 PM, Marek Olšák wrote:
>> On Thu, Feb 9, 2017 at 1:52 PM, Ian Romanick  wrote:
>>> On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
 On 07.02.2017 23:54, Matt Turner wrote:
> On Tue, Feb 7, 2017 at 10:56 AM, Marek Olšák  wrote:
>> On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke
>>  wrote:
>>> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote:
 On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand 
 wrote:
> FYI glmark2 segfaults with mesa_glthread=true. Expected that some
> programs
> will segfault?

 Yes, even segfaults are expected with mesa_glthread=true.

 Marek
>>>
>>> Would it make sense to be crash-free or even regression-free on at
>>> least Piglit, before merging?  (Or are we there already?)
>>
>> It's not necessary. glthread is disabled by default. Nobody has tested
>> piglit with glthread. That will follow after it's been merged, or
>> never if it's never merged.
>
> I don't understand why you're so concerned about merging untested
> code. That violates some pretty fundamental development practices of
> the project.
>
> It's exactly unfinished projects like this that cause problems and
> inevitably have to be deleted later (ilo, openvg, d3d1x, etc). I don't
> think it's a burden to develop something out of the master branch
> until it's somewhat useful.

 The code is already somewhat useful. Actually, make that _very_ useful
 (big performance improvement) for _some_ cases.

 I suspect most of the people in this discussion haven't really looked at
 the code in detail (myself included). We should probably do some of that
 before it is merged, since the code isn't just a new driver that is
 isolated in its own directory. So I agree with Emil that it makes sense
 to let the patches go over the mailing list once.

 However, it's fine to merge this without passing piglit.
>>>
>>> No, it absolutely is not fine to merge.  We have never allowed such a
>>> thing, and I'll be damned if I'll allow this project to start.  Things
>>> that land that are known to be broken never actually get fixed.  Then we
>>> have to waste time fielding bug reports and Phoronix threads because
>>> users turn on the performance features and everything breaks.  It's just
>>> a terrible idea.
>>
>> It does pass piglit, but only when it's disabled.
>>
>> We have to ask the question of how long it will take to reach the
>> level of perfection that some people here demand. 1 year? 2? 4 years
>> even? Are we willing to wait that long? Is there a sufficient minimum
>> requirement on merging this project that's possible to reach within 2
>> weeks? Instead of saying "absolutely not" and "terrible idea", why not
>> just say "yes if X gets done"?
>
> Nobody has touched this code in years, yet you're speaking as if it has
> been in active development for the whole time.  Eric and Paul
> implemented, found that it didn't help any applications that existed at
> the time, and abandoned it.

There are some good arguments in this thread, but it's not this one. I
did touch the code. I made Borderlands 2 work by adding Gallium
support, DRI3 support, and fixing race conditions and other bugs in
the core glthread code and glapi XML files. Even though the commits
have Eric and Paul as authors, I edited most of them in some way.

So if I understand correctly, the requirement for merging is to pass
piglit. If we drop support for compat profiles (do we need to drop
support for GLES?), it shouldn't be too hard.

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

Re: [Mesa-dev] [PATCH 4/5] anv/pipeline: Make a copy of VkPipelineDepthStencilStateCreateinfo

[Nanley Chery]

On Wed, Feb 01, 2017 at 05:43:54PM -0800, Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/genX_pipeline.c | 34 ++
>  1 file changed, 18 insertions(+), 16 deletions(-)

This patch is
Reviewed-by: Nanley Chery 

> 
> diff --git a/src/intel/vulkan/genX_pipeline.c 
> b/src/intel/vulkan/genX_pipeline.c
> index a7b294f..f6940d2 100644
> --- a/src/intel/vulkan/genX_pipeline.c
> +++ b/src/intel/vulkan/genX_pipeline.c
> @@ -636,7 +636,7 @@ static const uint32_t vk_to_gen_stencil_op[] = {
>  
>  static void
>  emit_ds_state(struct anv_pipeline *pipeline,
> -  const VkPipelineDepthStencilStateCreateInfo *info,
> +  const VkPipelineDepthStencilStateCreateInfo *pCreateInfo,
>const struct anv_render_pass *pass,
>const struct anv_subpass *subpass)
>  {
> @@ -648,7 +648,7 @@ emit_ds_state(struct anv_pipeline *pipeline,
>  #  define depth_stencil_dw pipeline->gen9.wm_depth_stencil
>  #endif
>  
> -   if (info == NULL) {
> +   if (pCreateInfo == NULL) {
>/* We're going to OR this together with the dynamic state.  We need
> * to make sure it's initialized to something useful.
> */
> @@ -656,29 +656,31 @@ emit_ds_state(struct anv_pipeline *pipeline,
>return;
> }
>  
> +   VkPipelineDepthStencilStateCreateInfo info = *pCreateInfo;
> +
> /* VkBool32 depthBoundsTestEnable; // optional (depth_bounds_test) */
>  
> -   pipeline->writes_stencil = info->stencilTestEnable;
> +   pipeline->writes_stencil = info.stencilTestEnable;
>  
>  #if GEN_GEN <= 7
> struct GENX(DEPTH_STENCIL_STATE) depth_stencil = {
>  #else
> struct GENX(3DSTATE_WM_DEPTH_STENCIL) depth_stencil = {
>  #endif
> -  .DepthTestEnable = info->depthTestEnable,
> -  .DepthBufferWriteEnable = info->depthWriteEnable,
> -  .DepthTestFunction = vk_to_gen_compare_op[info->depthCompareOp],
> +  .DepthTestEnable = info.depthTestEnable,
> +  .DepthBufferWriteEnable = info.depthWriteEnable,
> +  .DepthTestFunction = vk_to_gen_compare_op[info.depthCompareOp],
>.DoubleSidedStencilEnable = true,
>  
> -  .StencilTestEnable = info->stencilTestEnable,
> -  .StencilFailOp = vk_to_gen_stencil_op[info->front.failOp],
> -  .StencilPassDepthPassOp = vk_to_gen_stencil_op[info->front.passOp],
> -  .StencilPassDepthFailOp = 
> vk_to_gen_stencil_op[info->front.depthFailOp],
> -  .StencilTestFunction = vk_to_gen_compare_op[info->front.compareOp],
> -  .BackfaceStencilFailOp = vk_to_gen_stencil_op[info->back.failOp],
> -  .BackfaceStencilPassDepthPassOp = 
> vk_to_gen_stencil_op[info->back.passOp],
> -  .BackfaceStencilPassDepthFailOp 
> =vk_to_gen_stencil_op[info->back.depthFailOp],
> -  .BackfaceStencilTestFunction = 
> vk_to_gen_compare_op[info->back.compareOp],
> +  .StencilTestEnable = info.stencilTestEnable,
> +  .StencilFailOp = vk_to_gen_stencil_op[info.front.failOp],
> +  .StencilPassDepthPassOp = vk_to_gen_stencil_op[info.front.passOp],
> +  .StencilPassDepthFailOp = vk_to_gen_stencil_op[info.front.depthFailOp],
> +  .StencilTestFunction = vk_to_gen_compare_op[info.front.compareOp],
> +  .BackfaceStencilFailOp = vk_to_gen_stencil_op[info.back.failOp],
> +  .BackfaceStencilPassDepthPassOp = 
> vk_to_gen_stencil_op[info.back.passOp],
> +  .BackfaceStencilPassDepthFailOp 
> =vk_to_gen_stencil_op[info.back.depthFailOp],
> +  .BackfaceStencilTestFunction = 
> vk_to_gen_compare_op[info.back.compareOp],
> };
>  
> VkImageAspectFlags aspects = 0;
> @@ -707,7 +709,7 @@ emit_ds_state(struct anv_pipeline *pipeline,
>  *"If Depth_Test_Enable = 1 AND Depth_Test_func = EQUAL, the
>  *Depth_Write_Enable must be set to 0."
>  */
> -   if (info->depthTestEnable && info->depthCompareOp == VK_COMPARE_OP_EQUAL)
> +   if (info.depthTestEnable && info.depthCompareOp == VK_COMPARE_OP_EQUAL)
>depth_stencil.DepthBufferWriteEnable = false;
>  
> pipeline->writes_depth = depth_stencil.DepthBufferWriteEnable;
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 3/5] anv: Add support for the PMA fix on Broadwell

[Nanley Chery]

On Wed, Feb 08, 2017 at 09:38:52PM -0800, Jason Ekstrand wrote:
> On Wed, Feb 8, 2017 at 8:11 PM, Jason Ekstrand  wrote:
> 
> > On Wed, Feb 8, 2017 at 6:27 PM, Jason Ekstrand 
> > wrote:
> >
> >> On Wed, Feb 8, 2017 at 5:34 PM, Nanley Chery 
> >> wrote:
> >>
> >>> On Thu, Feb 02, 2017 at 01:26:05PM -0800, Jason Ekstrand wrote:
> >>> > In order to get good performance numbers for this, I had to hack up the
> >>> > driver to whack wm_prog_data::uses_kill to true to emulate a discard
> >>> and
> >>> > used the Sascha "shadowmapping" demo.  Setting uses_kill to true
> >>> dropped
> >>> > the framerate on the demo by 25-30%.  Enabling the PMA fix brought it
> >>> > back up to around 90% of the original framerate.  This doesn't seem to
> >>> > really impact Dota 2;  probably because it doesn't use 16-bit depth.
> >>> >
> >>> > Reviewed-by: Lionel Landwerlin 
> >>> > ---
> >>> >  src/intel/vulkan/TODO  |   1 -
> >>> >  src/intel/vulkan/anv_cmd_buffer.c  |   2 +
> >>> >  src/intel/vulkan/anv_genX.h|   3 +
> >>> >  src/intel/vulkan/anv_private.h |  17 +
> >>> >  src/intel/vulkan/gen7_cmd_buffer.c |   7 ++
> >>> >  src/intel/vulkan/gen8_cmd_buffer.c | 133
> >>> +
> >>> >  src/intel/vulkan/genX_blorp_exec.c |   5 ++
> >>> >  src/intel/vulkan/genX_cmd_buffer.c |  15 -
> >>> >  src/intel/vulkan/genX_pipeline.c   |  38 +++
> >>> >  9 files changed, 219 insertions(+), 2 deletions(-)
> >>> >
> >>> > diff --git a/src/intel/vulkan/TODO b/src/intel/vulkan/TODO
> >>> > index 38acc0d..f8b73a1 100644
> >>> > --- a/src/intel/vulkan/TODO
> >>> > +++ b/src/intel/vulkan/TODO
> >>> > @@ -12,5 +12,4 @@ Performance:
> >>> >   - Compressed multisample support
> >>> >   - Pushing pieces of UBOs?
> >>> >   - Enable guardband clipping
> >>> > - - pma stall workaround
> >>> >   - Use soft-pin to avoid relocations
> >>> > diff --git a/src/intel/vulkan/anv_cmd_buffer.c
> >>> b/src/intel/vulkan/anv_cmd_buffer.c
> >>> > index 5886fa6..8c08f8d 100644
> >>> > --- a/src/intel/vulkan/anv_cmd_buffer.c
> >>> > +++ b/src/intel/vulkan/anv_cmd_buffer.c
> >>> > @@ -135,6 +135,8 @@ anv_cmd_state_reset(struct anv_cmd_buffer
> >>> *cmd_buffer)
> >>> > state->restart_index = UINT32_MAX;
> >>> > state->dynamic = default_dynamic_state;
> >>> > state->need_query_wa = true;
> >>> > +   state->pma_fix_enabled = false;
> >>> > +   state->hiz_enabled = false;
> >>> >
> >>> > if (state->attachments != NULL) {
> >>> >vk_free(_buffer->pool->alloc, state->attachments);
> >>> > diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
> >>> > index d04fe38..67147b0 100644
> >>> > --- a/src/intel/vulkan/anv_genX.h
> >>> > +++ b/src/intel/vulkan/anv_genX.h
> >>> > @@ -55,6 +55,9 @@ void genX(cmd_buffer_flush_dynamic_state)(struct
> >>> anv_cmd_buffer *cmd_buffer);
> >>> >
> >>> >  void genX(cmd_buffer_flush_compute_state)(struct anv_cmd_buffer
> >>> *cmd_buffer);
> >>> >
> >>> > +void genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer
> >>> *cmd_buffer,
> >>> > + bool enable);
> >>> > +
> >>> >  void
> >>> >  genX(emit_urb_setup)(struct anv_device *device, struct anv_batch
> >>> *batch,
> >>> >   const struct gen_l3_config *l3_config,
> >>> > diff --git a/src/intel/vulkan/anv_private.h
> >>> b/src/intel/vulkan/anv_private.h
> >>> > index 4fe3ebc..6efe4ea 100644
> >>> > --- a/src/intel/vulkan/anv_private.h
> >>> > +++ b/src/intel/vulkan/anv_private.h
> >>> > @@ -1163,6 +1163,20 @@ struct anv_cmd_state {
> >>> > bool need_query_wa;
> >>> >
> >>> > /**
> >>> > +* Whether or not the gen8 PMA fix is enabled.  We ensure that, at
> >>> the top
> >>> > +* of any command buffer it disabled by disabling it in
> >>> EndCommandBuffer
> >>>  ^
> >>>  is?
> >>>
> >>> > +* and before invoking the secondary in ExecuteCommands.
> >>> > +*/
> >>> > +   bool pma_fix_enabled;
> >>> > +
> >>> > +   /**
> >>> > +* Whether or not we now for certain that HiZ is enabled for the
> >>> current
> >>>^
> >>>know
> >>>
> >>> > +* subpass.  If, for whatever reason, we are unsure as to whether
> >>> HiZ is
> >>> > +* enabled or not, this will be false.
> >>> > +*/
> >>> > +   bool hiz_enabled;
> >>> > +
> >>> > +   /**
> >>> >  * Array length is anv_cmd_state::pass::attachment_count. Array
> >>> content is
> >>> >  * valid only when recording a render pass instance.
> >>> >  */
> >>> > @@ -1465,8 +1479,11 @@ struct anv_pipeline {
> >>> >
> >>> > uint32_t cs_right_mask;
> >>> >
> >>> > +   bool   

Re: [Mesa-dev] [PATCH v2 3/5] anv: Add support for the PMA fix on Broadwell

[Nanley Chery]

On Wed, Feb 08, 2017 at 06:27:52PM -0800, Jason Ekstrand wrote:
> On Wed, Feb 8, 2017 at 5:34 PM, Nanley Chery  wrote:
> 
> > On Thu, Feb 02, 2017 at 01:26:05PM -0800, Jason Ekstrand wrote:
> > > In order to get good performance numbers for this, I had to hack up the
> > > driver to whack wm_prog_data::uses_kill to true to emulate a discard and
> > > used the Sascha "shadowmapping" demo.  Setting uses_kill to true dropped
> > > the framerate on the demo by 25-30%.  Enabling the PMA fix brought it
> > > back up to around 90% of the original framerate.  This doesn't seem to
> > > really impact Dota 2;  probably because it doesn't use 16-bit depth.
> > >
> > > Reviewed-by: Lionel Landwerlin 
> > > ---
> > >  src/intel/vulkan/TODO  |   1 -
> > >  src/intel/vulkan/anv_cmd_buffer.c  |   2 +
> > >  src/intel/vulkan/anv_genX.h|   3 +
> > >  src/intel/vulkan/anv_private.h |  17 +
> > >  src/intel/vulkan/gen7_cmd_buffer.c |   7 ++
> > >  src/intel/vulkan/gen8_cmd_buffer.c | 133 ++
> > +++
> > >  src/intel/vulkan/genX_blorp_exec.c |   5 ++
> > >  src/intel/vulkan/genX_cmd_buffer.c |  15 -
> > >  src/intel/vulkan/genX_pipeline.c   |  38 +++
> > >  9 files changed, 219 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/src/intel/vulkan/TODO b/src/intel/vulkan/TODO
> > > index 38acc0d..f8b73a1 100644
> > > --- a/src/intel/vulkan/TODO
> > > +++ b/src/intel/vulkan/TODO
> > > @@ -12,5 +12,4 @@ Performance:
> > >   - Compressed multisample support
> > >   - Pushing pieces of UBOs?
> > >   - Enable guardband clipping
> > > - - pma stall workaround
> > >   - Use soft-pin to avoid relocations
> > > diff --git a/src/intel/vulkan/anv_cmd_buffer.c
> > b/src/intel/vulkan/anv_cmd_buffer.c
> > > index 5886fa6..8c08f8d 100644
> > > --- a/src/intel/vulkan/anv_cmd_buffer.c
> > > +++ b/src/intel/vulkan/anv_cmd_buffer.c
> > > @@ -135,6 +135,8 @@ anv_cmd_state_reset(struct anv_cmd_buffer
> > *cmd_buffer)
> > > state->restart_index = UINT32_MAX;
> > > state->dynamic = default_dynamic_state;
> > > state->need_query_wa = true;
> > > +   state->pma_fix_enabled = false;
> > > +   state->hiz_enabled = false;
> > >
> > > if (state->attachments != NULL) {
> > >vk_free(_buffer->pool->alloc, state->attachments);
> > > diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
> > > index d04fe38..67147b0 100644
> > > --- a/src/intel/vulkan/anv_genX.h
> > > +++ b/src/intel/vulkan/anv_genX.h
> > > @@ -55,6 +55,9 @@ void genX(cmd_buffer_flush_dynamic_state)(struct
> > anv_cmd_buffer *cmd_buffer);
> > >
> > >  void genX(cmd_buffer_flush_compute_state)(struct anv_cmd_buffer
> > *cmd_buffer);
> > >
> > > +void genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer *cmd_buffer,
> > > + bool enable);
> > > +
> > >  void
> > >  genX(emit_urb_setup)(struct anv_device *device, struct anv_batch *batch,
> > >   const struct gen_l3_config *l3_config,
> > > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> > private.h
> > > index 4fe3ebc..6efe4ea 100644
> > > --- a/src/intel/vulkan/anv_private.h
> > > +++ b/src/intel/vulkan/anv_private.h
> > > @@ -1163,6 +1163,20 @@ struct anv_cmd_state {
> > > bool need_query_wa;
> > >
> > > /**
> > > +* Whether or not the gen8 PMA fix is enabled.  We ensure that, at
> > the top
> > > +* of any command buffer it disabled by disabling it in
> > EndCommandBuffer
> >  ^
> >  is?
> >

Fixed?

> > > +* and before invoking the secondary in ExecuteCommands.
> > > +*/
> > > +   bool pma_fix_enabled;
> > > +
> > > +   /**
> > > +* Whether or not we now for certain that HiZ is enabled for the
> > current
> >^
> >know
> >

Fixed?

> > > +* subpass.  If, for whatever reason, we are unsure as to whether
> > HiZ is
> > > +* enabled or not, this will be false.
> > > +*/
> > > +   bool hiz_enabled;
> > > +
> > > +   /**
> > >  * Array length is anv_cmd_state::pass::attachment_count. Array
> > content is
> > >  * valid only when recording a render pass instance.
> > >  */
> > > @@ -1465,8 +1479,11 @@ struct anv_pipeline {
> > >
> > > uint32_t cs_right_mask;
> > >
> > > +   bool writes_depth;
> > > +   bool depth_test_enable;
> > > bool writes_stencil;
> > > bool depth_clamp_enable;
> > > +   bool kill_pixel;
> > >
> > > struct {
> > >uint32_t  

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Ernst Sjöstrand]

2017-02-09 18:06 GMT+01:00 Eero Tamminen :

My personal feeling is that minimal merging criteria should be:
> * no known segfaults
>

I bet that glmark2 just does something that's not allowed. Mesa can't
prevent all application bugs? Seems like it has a very buggy history with
lots of segfaults in other situations also.

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

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Kenneth Graunke]

On Thursday, February 9, 2017 5:23:47 PM PST Ian Romanick wrote:
[snip]
> Not achieving the desired performance is vastly different from
> segfaults.  Does the threaded mode in NVIDIA's driver crash?  I'd wager
> not.

Sadly, yes it does.  A while back, I tried running some Steam games
on Linux using my NVIDIA machine, with an out of the box configuration,
and they totally crashed.  Workaround was to disable GL threaded
optimizations.  Of course, I also had crashes which I had to update the
CPU microcode to workaround, and tearing right through the middle of
every single frame (needed more workarounds), and all kinds of
problems...so...not sure that's the standard of quality I want to
aspire to...

--Ken


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

Re: [Mesa-dev] [PATCH 26/26] gallium: implement the backend of threaded GL dispatch

[Matt Turner]

On Wed, Feb 8, 2017 at 6:03 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> ---
>  src/gallium/include/state_tracker/st_api.h  | 19 +++
>  src/gallium/state_trackers/dri/dri_context.c| 10 ++
>  src/gallium/state_trackers/dri/dri_drawable.c   |  6 ++
>  src/gallium/state_trackers/dri/dri_screen.c | 21 +
>  src/mesa/drivers/dri/common/xmlpool/t_options.h |  4 
>  src/mesa/state_tracker/st_context.c | 13 +
>  src/mesa/state_tracker/st_manager.c | 19 +++
>  7 files changed, 92 insertions(+)
>
> diff --git a/src/gallium/include/state_tracker/st_api.h 
> b/src/gallium/include/state_tracker/st_api.h
> index a2e37d2..19c38af 100644
> --- a/src/gallium/include/state_tracker/st_api.h
> +++ b/src/gallium/include/state_tracker/st_api.h
> @@ -407,20 +407,33 @@ struct st_context_iface
> boolean (*share)(struct st_context_iface *stctxi,
>  struct st_context_iface *stsrci);
>
> /**
>  * Look up and return the info of a resource for EGLImage.
>  *
>  * This function is optional.
>  */
> boolean (*get_resource_for_egl_image)(struct st_context_iface *stctxi,
>   struct st_context_resource *stres);
> +
> +   /**
> +* Start the thread if the API has a worker thread.
> +* Called after the context has been created and fully initialized on both
> +* sides (e.g. st/mesa and st/dri).
> +*/
> +   void (*start_thread)(struct st_context_iface *stctxi);
> +
> +   /**
> +* If the API is multithreaded, wait for all queued commands to complete.
> +* Called from the main thread.
> +*/
> +   void (*thread_finish)(struct st_context_iface *stctxi);
>  };
>
>
>  /**
>   * Represent a state tracker manager.
>   *
>   * This interface is implemented by the state tracker manager.  It 
> corresponds
>   * to a "display" in the window system.
>   */
>  struct st_manager
> @@ -444,20 +457,26 @@ struct st_manager
>  */
> boolean (*get_egl_image)(struct st_manager *smapi,
>  void *egl_image,
>  struct st_egl_image *out);
>
> /**
>  * Query an manager param.
>  */
> int (*get_param)(struct st_manager *smapi,
>  enum st_manager_param param);
> +
> +   /**
> +* Call the loader function setBackgroundContext. Called from the worker
> +* thread.
> +*/
> +   void (*set_background_context)(struct st_context_iface *stctxi);
>  };
>
>  /**
>   * Represent a rendering API such as OpenGL or OpenVG.
>   *
>   * Implemented by the state tracker and used by the state tracker manager.
>   */
>  struct st_api
>  {
> /**
> diff --git a/src/gallium/state_trackers/dri/dri_context.c 
> b/src/gallium/state_trackers/dri/dri_context.c
> index 3d8af65..91d2d1f 100644
> --- a/src/gallium/state_trackers/dri/dri_context.c
> +++ b/src/gallium/state_trackers/dri/dri_context.c
> @@ -149,20 +149,27 @@ dri_create_context(gl_api api, const struct gl_config * 
> visual,
>goto fail;
> }
> ctx->st->st_manager_private = (void *) ctx;
> ctx->stapi = stapi;
>
> if (ctx->st->cso_context) {
>ctx->pp = pp_init(ctx->st->pipe, screen->pp_enabled, 
> ctx->st->cso_context);
>ctx->hud = hud_create(ctx->st->pipe, ctx->st->cso_context);
> }
>
> +   /* Do this last. */
> +   if (ctx->st->start_thread &&
> +   /* the driver loader must implement this */
> +   screen->sPriv->dri2.backgroundCallable &&
> +   driQueryOptionb(>optionCache, "mesa_glthread"))

The original i965 patch uses an environment variable named "glthread".
We should definitely be consistent, but I'm not sure if "glthread" is
too generic of a name.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] features.txt & EXT_debug_label extension

[Ian Romanick]

On 02/09/2017 05:19 PM, Eero Tamminen wrote:
> Hi,
> 
> When checking GL errors for "Unturned" (Steam top-20 Unity3D based
> game), I noticed that it uses functions from extension unsupported by
> Mesa, and missing from "features.txt":
> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_debug_label.txt
> 
> Could it be added to "features.txt" file?

I thought the functionality of that extension was folded into some other
ARB (or KHR) extension... GL_KHR_debug, maybe?  It's also not the sort
of thing that an app should use in release mode.

> - Eero
> 
> PS. Apitrace already outputs those debug labels in the replay output,
> but I didn't check whether its GUI could also make use of them.
> 
> ___
> 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] Time to merge threaded GL dispatch? (aka glthread)

[Ian Romanick]

On 02/09/2017 05:26 PM, Ian Romanick wrote:
> On 02/09/2017 05:14 PM, Eric Anholt wrote:
>> Ian Romanick  writes:
>>
>>> On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
 On 07.02.2017 23:54, Matt Turner wrote:
> On Tue, Feb 7, 2017 at 10:56 AM, Marek Olšák  wrote:
>> On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke
>>  wrote:
>>> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote:
 On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand 
 wrote:
> FYI glmark2 segfaults with mesa_glthread=true. Expected that some
> programs
> will segfault?

 Yes, even segfaults are expected with mesa_glthread=true.

 Marek
>>>
>>> Would it make sense to be crash-free or even regression-free on at
>>> least Piglit, before merging?  (Or are we there already?)
>>
>> It's not necessary. glthread is disabled by default. Nobody has tested
>> piglit with glthread. That will follow after it's been merged, or
>> never if it's never merged.
>
> I don't understand why you're so concerned about merging untested
> code. That violates some pretty fundamental development practices of
> the project.
>
> It's exactly unfinished projects like this that cause problems and
> inevitably have to be deleted later (ilo, openvg, d3d1x, etc). I don't
> think it's a burden to develop something out of the master branch
> until it's somewhat useful.

 The code is already somewhat useful. Actually, make that _very_ useful
 (big performance improvement) for _some_ cases.

 I suspect most of the people in this discussion haven't really looked at
 the code in detail (myself included). We should probably do some of that
 before it is merged, since the code isn't just a new driver that is
 isolated in its own directory. So I agree with Emil that it makes sense
 to let the patches go over the mailing list once.

 However, it's fine to merge this without passing piglit.
>>>
>>> No, it absolutely is not fine to merge.  We have never allowed such a
>>> thing, and I'll be damned if I'll allow this project to start.  Things
>>> that land that are known to be broken never actually get fixed.  Then we
>>> have to waste time fielding bug reports and Phoronix threads because
>>> users turn on the performance features and everything breaks.  It's just
>>> a terrible idea.
>>
>> Yeah, just like how we gated the GLSL compiler until it was completely
>> done (we didn't) and NIR until it was completely done (we didn't) and
>> Vulkan until it was completely done (we didn't) and...
> 
> But we did require that it pass the test suites.  All of that lived in
> branches for a really long time with active development.  The GLSL
> compiler and NIR are two examples that support my claim.  Those were
> massive branch merges that waited much longer to merge than the people
> working on them wanted.

Also... the GLSL compiler was long before we did time-based releases.
We block the release for a really long time so that we could achieve the
quality that we need.

>> Software that people care about gets fixed.  I'm also concerned that
>> nobody actually cares about getting glthread working completely, given
>> Marek's attitude toward piglit conformance (and my also ignoring the
>> branch for the last however many years).  However, "we have never
>> allowed merging broken software that's only turned on under env
>> vars/configure" is totally false.  We do that regularly for big things
>> we care about.
> 
> ___
> 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 3/3] etnaviv: shader-db traces

[Wladimir J. van der Laan]

> Okay.. I will add the id member in a later patch to etna_shader
> object. For the moment
> I will pass it as an argument to dump_shader_info(..). Will send a V2
> of that series later the day.

To be honest I think it's nonsense to change this now, if you need an
id in the shader object then add an id to the shader object. It's not like
that overhead is significant and if you're going to add it later anyway
we're pretty much wasting time here by removing it and adding it back...

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

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Ian Romanick]

On 02/09/2017 05:14 PM, Eric Anholt wrote:
> Ian Romanick  writes:
> 
>> On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
>>> On 07.02.2017 23:54, Matt Turner wrote:
 On Tue, Feb 7, 2017 at 10:56 AM, Marek Olšák  wrote:
> On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke
>  wrote:
>> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote:
>>> On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand 
>>> wrote:
 FYI glmark2 segfaults with mesa_glthread=true. Expected that some
 programs
 will segfault?
>>>
>>> Yes, even segfaults are expected with mesa_glthread=true.
>>>
>>> Marek
>>
>> Would it make sense to be crash-free or even regression-free on at
>> least Piglit, before merging?  (Or are we there already?)
>
> It's not necessary. glthread is disabled by default. Nobody has tested
> piglit with glthread. That will follow after it's been merged, or
> never if it's never merged.

 I don't understand why you're so concerned about merging untested
 code. That violates some pretty fundamental development practices of
 the project.

 It's exactly unfinished projects like this that cause problems and
 inevitably have to be deleted later (ilo, openvg, d3d1x, etc). I don't
 think it's a burden to develop something out of the master branch
 until it's somewhat useful.
>>>
>>> The code is already somewhat useful. Actually, make that _very_ useful
>>> (big performance improvement) for _some_ cases.
>>>
>>> I suspect most of the people in this discussion haven't really looked at
>>> the code in detail (myself included). We should probably do some of that
>>> before it is merged, since the code isn't just a new driver that is
>>> isolated in its own directory. So I agree with Emil that it makes sense
>>> to let the patches go over the mailing list once.
>>>
>>> However, it's fine to merge this without passing piglit.
>>
>> No, it absolutely is not fine to merge.  We have never allowed such a
>> thing, and I'll be damned if I'll allow this project to start.  Things
>> that land that are known to be broken never actually get fixed.  Then we
>> have to waste time fielding bug reports and Phoronix threads because
>> users turn on the performance features and everything breaks.  It's just
>> a terrible idea.
> 
> Yeah, just like how we gated the GLSL compiler until it was completely
> done (we didn't) and NIR until it was completely done (we didn't) and
> Vulkan until it was completely done (we didn't) and...

But we did require that it pass the test suites.  All of that lived in
branches for a really long time with active development.  The GLSL
compiler and NIR are two examples that support my claim.  Those were
massive branch merges that waited much longer to merge than the people
working on them wanted.

> Software that people care about gets fixed.  I'm also concerned that
> nobody actually cares about getting glthread working completely, given
> Marek's attitude toward piglit conformance (and my also ignoring the
> branch for the last however many years).  However, "we have never
> allowed merging broken software that's only turned on under env
> vars/configure" is totally false.  We do that regularly for big things
> we care about.




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

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Eero Tamminen]

Hi,

On 09.02.2017 19:14, Eric Anholt wrote:

Ian Romanick  writes:

...

No, it absolutely is not fine to merge.  We have never allowed such a
thing, and I'll be damned if I'll allow this project to start.  Things
that land that are known to be broken never actually get fixed.  Then we
have to waste time fielding bug reports and Phoronix threads because
users turn on the performance features and everything breaks.  It's just
a terrible idea.


Yeah, just like how we gated the GLSL compiler until it was completely
done (we didn't) and NIR until it was completely done (we didn't) and
Vulkan until it was completely done (we didn't) and...


None of the features you list were purely for performance.  If it's just 
supposed to [1] improve performance and complicates the existing code, 
gate should be higher.


[1] You cannot fully trust the provided performance numbers if it's not 
functioning properly.




Software that people care about gets fixed.  I'm also concerned that
nobody actually cares about getting glthread working completely, given
Marek's attitude toward piglit conformance (and my also ignoring the
branch for the last however many years).  However, "we have never
allowed merging broken software that's only turned on under env
vars/configure" is totally false.  We do that regularly for big things
we care about.



- Eero

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

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Ian Romanick]

On 02/09/2017 03:03 PM, Marek Olšák wrote:
> On Thu, Feb 9, 2017 at 1:52 PM, Ian Romanick  wrote:
>> On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
>>> On 07.02.2017 23:54, Matt Turner wrote:
 On Tue, Feb 7, 2017 at 10:56 AM, Marek Olšák  wrote:
> On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke
>  wrote:
>> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote:
>>> On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand 
>>> wrote:
 FYI glmark2 segfaults with mesa_glthread=true. Expected that some
 programs
 will segfault?
>>>
>>> Yes, even segfaults are expected with mesa_glthread=true.
>>>
>>> Marek
>>
>> Would it make sense to be crash-free or even regression-free on at
>> least Piglit, before merging?  (Or are we there already?)
>
> It's not necessary. glthread is disabled by default. Nobody has tested
> piglit with glthread. That will follow after it's been merged, or
> never if it's never merged.

 I don't understand why you're so concerned about merging untested
 code. That violates some pretty fundamental development practices of
 the project.

 It's exactly unfinished projects like this that cause problems and
 inevitably have to be deleted later (ilo, openvg, d3d1x, etc). I don't
 think it's a burden to develop something out of the master branch
 until it's somewhat useful.
>>>
>>> The code is already somewhat useful. Actually, make that _very_ useful
>>> (big performance improvement) for _some_ cases.
>>>
>>> I suspect most of the people in this discussion haven't really looked at
>>> the code in detail (myself included). We should probably do some of that
>>> before it is merged, since the code isn't just a new driver that is
>>> isolated in its own directory. So I agree with Emil that it makes sense
>>> to let the patches go over the mailing list once.
>>>
>>> However, it's fine to merge this without passing piglit.
>>
>> No, it absolutely is not fine to merge.  We have never allowed such a
>> thing, and I'll be damned if I'll allow this project to start.  Things
>> that land that are known to be broken never actually get fixed.  Then we
>> have to waste time fielding bug reports and Phoronix threads because
>> users turn on the performance features and everything breaks.  It's just
>> a terrible idea.
> 
> It does pass piglit, but only when it's disabled.
> 
> We have to ask the question of how long it will take to reach the
> level of perfection that some people here demand. 1 year? 2? 4 years
> even? Are we willing to wait that long? Is there a sufficient minimum
> requirement on merging this project that's possible to reach within 2
> weeks? Instead of saying "absolutely not" and "terrible idea", why not
> just say "yes if X gets done"?

Nobody has touched this code in years, yet you're speaking as if it has
been in active development for the whole time.  Eric and Paul
implemented, found that it didn't help any applications that existed at
the time, and abandoned it.

> If you only expect absolutism and perfectionism, you'll be very
> disappointed with this project. Doing a threaded GL dispatch is hard.
> NVIDIA had had performance issues with it for a very long time. AMD
> doesn't even have a solution that can be enabled by default.

Not achieving the desired performance is vastly different from
segfaults.  Does the threaded mode in NVIDIA's driver crash?  I'd wager
not.  We have always had high quality standards for Mesa.  We have
always adhered to the specified OpenGL behavior (and worked to fix the
spec when it didn't match other vendors).  These are the things that
have made Mesa successful in the presence of drivers with more features
and / or better performance.  It has also made software developers like
Mesa and trust us.  I haven't heard a compelling reason to abandon those
fundamental principles.

There have been times in the past where we have landed performance
oriented features that didn't initially provide performance benefits to
all applications.  i965's transition to NIR is one such case.  However,
we did require that the test suites passed with the feature enabled.

> I'm not heavily invested in this project (yet), so it won't bother me
> much if this doesn't get merged before mid-2017. If people wanna
> contribute, they can send me pull requests. (please do it early &
> often, don't wait until you have something that's good enough)
> 
> I've been contemplating doing threaded gallium dispatch for a while
> now. It should be very easy if we copy some sync prevention tricks
> from radeonsi, and we might be able to enable it by default for all GL
> apps (core & compat) from day 1. That can be our short-term goal for
> gallium, while threaded GL can be our long-term goal and only limited
> to whitelisted apps for quite a while.
> 
> Marek

Re: [Mesa-dev] features.txt & EXT_debug_label extension

[Alex Deucher]

On Thu, Feb 9, 2017 at 12:19 PM, Eero Tamminen
 wrote:
> Hi,
>
> When checking GL errors for "Unturned" (Steam top-20 Unity3D based game), I
> noticed that it uses functions from extension unsupported by Mesa, and
> missing from "features.txt":
> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_debug_label.txt
>
> Could it be added to "features.txt" file?

Sure.  features.txt was originally GL3.txt and as a list of the
extensions missing for GL 3.x and 4.x compliance.  Now that a number
of drivers support all of those extensions, it has also become a list
of useful extensions and their status in mesa.

Alex

>
>
> - Eero
>
> PS. Apitrace already outputs those debug labels in the replay output, but I
> didn't check whether its GUI could also make use of them.
>
> ___
> 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] features.txt & EXT_debug_label extension

[Eero Tamminen]

Hi,

When checking GL errors for "Unturned" (Steam top-20 Unity3D based 
game), I noticed that it uses functions from extension unsupported by 
Mesa, and missing from "features.txt":

https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_debug_label.txt

Could it be added to "features.txt" file?


- Eero

PS. Apitrace already outputs those debug labels in the replay output, 
but I didn't check whether its GUI could also make use of them.


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

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Eric Anholt]

Ian Romanick  writes:

> On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
>> On 07.02.2017 23:54, Matt Turner wrote:
>>> On Tue, Feb 7, 2017 at 10:56 AM, Marek Olšák  wrote:
 On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke
  wrote:
> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote:
>> On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand 
>> wrote:
>>> FYI glmark2 segfaults with mesa_glthread=true. Expected that some
>>> programs
>>> will segfault?
>>
>> Yes, even segfaults are expected with mesa_glthread=true.
>>
>> Marek
>
> Would it make sense to be crash-free or even regression-free on at
> least Piglit, before merging?  (Or are we there already?)

 It's not necessary. glthread is disabled by default. Nobody has tested
 piglit with glthread. That will follow after it's been merged, or
 never if it's never merged.
>>>
>>> I don't understand why you're so concerned about merging untested
>>> code. That violates some pretty fundamental development practices of
>>> the project.
>>>
>>> It's exactly unfinished projects like this that cause problems and
>>> inevitably have to be deleted later (ilo, openvg, d3d1x, etc). I don't
>>> think it's a burden to develop something out of the master branch
>>> until it's somewhat useful.
>> 
>> The code is already somewhat useful. Actually, make that _very_ useful
>> (big performance improvement) for _some_ cases.
>> 
>> I suspect most of the people in this discussion haven't really looked at
>> the code in detail (myself included). We should probably do some of that
>> before it is merged, since the code isn't just a new driver that is
>> isolated in its own directory. So I agree with Emil that it makes sense
>> to let the patches go over the mailing list once.
>> 
>> However, it's fine to merge this without passing piglit.
>
> No, it absolutely is not fine to merge.  We have never allowed such a
> thing, and I'll be damned if I'll allow this project to start.  Things
> that land that are known to be broken never actually get fixed.  Then we
> have to waste time fielding bug reports and Phoronix threads because
> users turn on the performance features and everything breaks.  It's just
> a terrible idea.

Yeah, just like how we gated the GLSL compiler until it was completely
done (we didn't) and NIR until it was completely done (we didn't) and
Vulkan until it was completely done (we didn't) and...

Software that people care about gets fixed.  I'm also concerned that
nobody actually cares about getting glthread working completely, given
Marek's attitude toward piglit conformance (and my also ignoring the
branch for the last however many years).  However, "we have never
allowed merging broken software that's only turned on under env
vars/configure" is totally false.  We do that regularly for big things
we care about.


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] Time to merge threaded GL dispatch? (aka glthread)

[Matt Turner]

On Thu, Feb 9, 2017 at 3:03 PM, Marek Olšák  wrote:
> On Thu, Feb 9, 2017 at 1:52 PM, Ian Romanick  wrote:
>> On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
>>> On 07.02.2017 23:54, Matt Turner wrote:
 On Tue, Feb 7, 2017 at 10:56 AM, Marek Olšák  wrote:
> On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke
>  wrote:
>> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote:
>>> On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand 
>>> wrote:
 FYI glmark2 segfaults with mesa_glthread=true. Expected that some
 programs
 will segfault?
>>>
>>> Yes, even segfaults are expected with mesa_glthread=true.
>>>
>>> Marek
>>
>> Would it make sense to be crash-free or even regression-free on at
>> least Piglit, before merging?  (Or are we there already?)
>
> It's not necessary. glthread is disabled by default. Nobody has tested
> piglit with glthread. That will follow after it's been merged, or
> never if it's never merged.

 I don't understand why you're so concerned about merging untested
 code. That violates some pretty fundamental development practices of
 the project.

 It's exactly unfinished projects like this that cause problems and
 inevitably have to be deleted later (ilo, openvg, d3d1x, etc). I don't
 think it's a burden to develop something out of the master branch
 until it's somewhat useful.
>>>
>>> The code is already somewhat useful. Actually, make that _very_ useful
>>> (big performance improvement) for _some_ cases.
>>>
>>> I suspect most of the people in this discussion haven't really looked at
>>> the code in detail (myself included). We should probably do some of that
>>> before it is merged, since the code isn't just a new driver that is
>>> isolated in its own directory. So I agree with Emil that it makes sense
>>> to let the patches go over the mailing list once.
>>>
>>> However, it's fine to merge this without passing piglit.
>>
>> No, it absolutely is not fine to merge.  We have never allowed such a
>> thing, and I'll be damned if I'll allow this project to start.  Things
>> that land that are known to be broken never actually get fixed.  Then we
>> have to waste time fielding bug reports and Phoronix threads because
>> users turn on the performance features and everything breaks.  It's just
>> a terrible idea.
>
> It does pass piglit, but only when it's disabled.

Have you actually run piglit? What are the results on radeonsi for
glthread=true vs glthread=false?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Eero Tamminen]

Hi,

On 09.02.2017 17:03, Marek Olšák wrote:

On Thu, Feb 9, 2017 at 1:52 PM, Ian Romanick  wrote:

...

No, it absolutely is not fine to merge.  We have never allowed such a
thing, and I'll be damned if I'll allow this project to start.  Things
that land that are known to be broken never actually get fixed.  Then we
have to waste time fielding bug reports and Phoronix threads because
users turn on the performance features and everything breaks.  It's just
a terrible idea.


It does pass piglit, but only when it's disabled.

We have to ask the question of how long it will take to reach the
level of perfection that some people here demand. 1 year? 2? 4 years
even? Are we willing to wait that long? Is there a sufficient minimum
requirement on merging this project that's possible to reach within 2
weeks? Instead of saying "absolutely not" and "terrible idea", why not
just say "yes if X gets done"?




My personal feeling is that minimal merging criteria should be:
* no known segfaults
* no functional piglit failures (or if there are, they're known, 
somewhat investigated and commonly agreed to be OK for merging)


After the functional issues are fixed, performance issues are fine as 
long as it still clearly helps (>=10%?) some games.


In general, performance numbers for features that have functional 
issues, shouldn't be trusted.  If e.g. crashes are due to missing 
synchronization, does adding the required synchronization also lose the 
measured performance increase?




If you only expect absolutism and perfectionism, you'll be very
disappointed with this project. Doing a threaded GL dispatch is hard.
NVIDIA had had performance issues with it for a very long time.


Those are fine.  Have they had also crashes or rendering issues?

Is realistic approach just automatically disabling threading when 
program uses problematic GL feature/version? (Can it be disabled if it's 
already in use?)



> AMD doesn't even have a solution that can be enabled by default.
>

I'm not heavily invested in this project (yet), so it won't bother me
much if this doesn't get merged before mid-2017. If people wanna
contribute, they can send me pull requests. (please do it early &
often, don't wait until you have something that's good enough)

I've been contemplating doing threaded gallium dispatch for a while
now. It should be very easy if we copy some sync prevention tricks
from radeonsi, and we might be able to enable it by default for all GL
apps (core & compat) from day 1. That can be our short-term goal for
gallium, while threaded GL can be our long-term goal and only limited
to whitelisted apps for quite a while.



- Eero

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

Re: [Mesa-dev] www.mesa3d.org moving to freedesktop.org

[Brian Paul]

On 02/08/2017 10:01 AM, Jason Ekstrand wrote:


Brian,

While we're on the topic of websites, how do you feel about having it
generated by Sphinx?  A couple of people have already gone to the effort
to convert the raw HTML to RST (automatically in the case of release notes).


I guess I don't have a strong opinion about using sphinx, though, I'm 
not clear on what the advantages would be.  My only experience with it 
is src/gallium/docs/ and I sometimes struggled to come up with the 
formatting I wanted.


-Brian

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

Re: [Mesa-dev] [PATCH 1/2] anv: allow blue in alpha component in swizzle for render

[Nanley Chery]

On Thu, Feb 09, 2017 at 09:41:11AM +0100, Juan A. Suarez Romero wrote:
> On Wed, 2017-02-08 at 10:53 -0800, Nanley Chery wrote:
> > On Wed, Feb 08, 2017 at 06:42:44PM +0100, Juan A. Suarez Romero wrote:
> > > On Wed, 2017-02-08 at 09:27 -0800, Nanley Chery wrote:
> > > > On Wed, Feb 08, 2017 at 01:31:54PM +0100, Juan A. Suarez Romero wrote:
> > > > > In pre-Broadwell devices, as B4G4R4A4 is not supported natively, we
> > > > > workaround it by using a format with a more complex swizzle, that uses
> > > > > blue in alpha component.
> > > > > 
> > > > > Signed-off-by: Juan A. Suarez Romero 
> > > > > ---
> > > > >  src/intel/vulkan/anv_private.h | 14 ++
> > > > >  1 file changed, 10 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/src/intel/vulkan/anv_private.h 
> > > > > b/src/intel/vulkan/anv_private.h
> > > > > index 51e85c7..e9bf13c 100644
> > > > > --- a/src/intel/vulkan/anv_private.h
> > > > > +++ b/src/intel/vulkan/anv_private.h
> > > > > @@ -1559,13 +1559,19 @@ static inline struct isl_swizzle
> > > > >  anv_swizzle_for_render(struct isl_swizzle swizzle)
> > > > >  {
> > > > > /* Sometimes the swizzle will have alpha map to one.  We do this 
> > > > > to fake
> > > > > -* RGB as RGBA for texturing
> > > > > +* RGB as RGBA for texturing.
> > > > > +*
> > > > > +* It can have also alpha to blue. This happens to workaround 
> > > > > support for
> > > > > +* B4G4R4A4 in gen < 8 devices, as this not supported natively.
> > > > >  */
> > > > > assert(swizzle.a == ISL_CHANNEL_SELECT_ONE ||
> > > > > -  swizzle.a == ISL_CHANNEL_SELECT_ALPHA);
> > > > > +  swizzle.a == ISL_CHANNEL_SELECT_ALPHA ||
> > > > > +  swizzle.a == ISL_CHANNEL_SELECT_BLUE);
> > > > >  
> > > > > -   /* But it doesn't matter what we render to that channel */
> > > > > -   swizzle.a = ISL_CHANNEL_SELECT_ALPHA;
> > > > > +   /* But it doesn't matter what we render to that channel, except 
> > > > > for the
> > > > > +* B4G4R4A4 workaround */
> > > > 
> > > > I'm finding this commit message a tad confusing. Would you agree that 
> > > > replacing it with the following would be better?
> > > > 
> > > > For RGB formats that have alpha mapped to one, we must remap the channel
> > > > to alpha to satisfy the BDW+ surface state restriction.
> > > > 
> > > 
> > > Uhm... I don't think so. That is what the code was doing so far.
> > > 
> > > The commit just takes in account that alpha can be mapped to blue too.
> > > And in this case, we keep the blue.
> > > 
> > 
> > Oh, sorry, I meant code comment, not commit message. That would
> > definitely not work as a commit message. Thoughts?
> 
> 
> Yes, it works for me as code comment. Thanks!
> 

Great!

> 
> With that change, can I consider you grant R-b?
> 

Yes, with that change, this patch is
Reviewed-by: Nanley Chery 

>   J.A.
> 
> > > 
> > > > Aside from the comment, this patch looks good to me.
> > > > 
> > > > > +   if (swizzle.a == ISL_CHANNEL_SELECT_ONE)
> > > > > +  swizzle.a = ISL_CHANNEL_SELECT_ALPHA;
> > > > >  
> > > > > return swizzle;
> > > > >  }
> > > > > -- 
> > > > > 2.9.3
> > > > > 
> > > > > ___
> > > > > mesa-dev mailing list
> > > > > mesa-dev@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > > > 
> > > > 
> > 
> > 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/10] vl: remove DRI2DriverPrimeShift compile guards

[Emil Velikov]

On 9 February 2017 at 15:23, Matt Turner  wrote:
> On Thu, Feb 9, 2017 at 1:35 PM, Emil Velikov  wrote:
>> From: Emil Velikov 
>>
>> Macro will always be defined as of earlier commit.
>
> How about something like
>
> DRI2DriverPrimeShift was added in dri2proto-2.8, which we now require
> as of the previous commit.

Sounds a lot better, thanks. Applied locally.
Barring any objections I'll push the lot on Saturday.

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

[Mesa-dev] [Bug 99730] Metro Redux game(s) needs override for midshader extension declaration

[bugzilla-daemon]

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

--- Comment #3 from Eero Tamminen  ---
Thanks!  I guess this is one of the use-cases that actually *requires* shader
compiler cache to work, so that user can (on second try) actually exit from the
gfx options.  Should I file (a separate) bug about that too?

-- 
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 2/3] etnaviv: move pctx initialisation to avoid a null dereference

[Christian Gmeiner]

Hi Eric

2017-02-09 11:59 GMT+01:00 Eric Engestrom :
> On Thursday, 2017-02-09 08:19:39 +0100, Christian Gmeiner wrote:
>> In case ctx->stream == NULL the fail label gets executed where
>> pctx gets dereferenced - too bad pctx is NULL in that case.
>>
>> Caught by Coverity, reported to me by imirkin.
>>
>> Signed-off-by: Christian Gmeiner 
>> ---
>>  src/gallium/drivers/etnaviv/etnaviv_context.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
>> b/src/gallium/drivers/etnaviv/etnaviv_context.c
>> index d767cd1..9cbbe2e 100644
>> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
>> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
>> @@ -256,15 +256,15 @@ etna_context_create(struct pipe_screen *pscreen, void 
>> *priv, unsigned flags)
>> if (ctx == NULL)
>>return NULL;
>>
>> +   pctx = >base;
>
> With this, you can also drop the `pctx = NULL` a couple lines above.
>

Will change it locally before pushing - thanks!

> Series is:
> Reviewed-by: Eric Engestrom 
>
> Cheers,
>   Eric
>
>> +   pctx->priv = ctx;
>> +   pctx->screen = pscreen;
>> +
>> screen = etna_screen(pscreen);
>> ctx->stream = etna_cmd_stream_new(screen->pipe, 0x2000, 
>> _cmd_stream_reset_notify, ctx);
>> if (ctx->stream == NULL)
>>goto fail;
>>
>> -   pctx = >base;
>> -   pctx->priv = ctx;
>> -   pctx->screen = pscreen;
>> -
>> /* context ctxate setup */
>> ctx->specs = screen->specs;
>> ctx->screen = screen;
>> --
>> 2.7.4
>>

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] etnaviv: shader-db traces

[Christian Gmeiner]

Hi Lucas

2017-02-09 10:26 GMT+01:00 Lucas Stach :
> Am Mittwoch, den 08.02.2017, 20:47 +0100 schrieb Christian Gmeiner:
>> Hi Lucas,
>>
>> 2017-02-08 12:36 GMT+01:00 Lucas Stach :
>> > Am Mittwoch, den 08.02.2017, 12:10 +0100 schrieb Christian Gmeiner:
>> >> Signed-off-by: Christian Gmeiner 
>> >> ---
>> >>  src/gallium/drivers/etnaviv/etnaviv_compiler.h |  2 ++
>> >>  src/gallium/drivers/etnaviv/etnaviv_debug.h|  1 +
>> >>  src/gallium/drivers/etnaviv/etnaviv_screen.c   |  1 +
>> >>  src/gallium/drivers/etnaviv/etnaviv_shader.c   | 44 
>> >> +-
>> >>  4 files changed, 47 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.h 
>> >> b/src/gallium/drivers/etnaviv/etnaviv_compiler.h
>> >> index 211ae1a..de3e20d 100644
>> >> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.h
>> >> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.h
>> >> @@ -56,6 +56,8 @@ struct etna_shader_io_file {
>> >>
>> >>  /* shader object, for linking */
>> >>  struct etna_shader {
>> >> +   uint32_t id; /* for debug */
>> >
>> > Do you need this? It can certainly be removed from this patch, but I
>> > don't know if you have other stuff building on top of this.
>> >
>>
>> It gets used in dump_shader_info(..) which was added with this patch.
>
> My argument was that you could pass that value as an argument to
> dump_shader_info(). I don't see why it needs to be stored inside the
> etna_shader object.
>

Okay.. I will add the id member in a later patch to etna_shader
object. For the moment
I will pass it as an argument to dump_shader_info(..). Will send a V2
of that series later the day.

>>
>> >> uint processor; /* TGSI_PROCESSOR_... */
>> >> uint32_t code_size; /* code size in uint32 words */
>> >> uint32_t *code;
>> >> diff --git a/src/gallium/drivers/etnaviv/etnaviv_debug.h 
>> >> b/src/gallium/drivers/etnaviv/etnaviv_debug.h
>> >> index cfda52b..f47dffe 100644
>> >> --- a/src/gallium/drivers/etnaviv/etnaviv_debug.h
>> >> +++ b/src/gallium/drivers/etnaviv/etnaviv_debug.h
>> >> @@ -51,6 +51,7 @@
>> >>  #define ETNA_DBG_FLUSH_ALL   0x10 /* Flush after every rendered 
>> >> primitive */
>> >>  #define ETNA_DBG_ZERO0x20 /* Zero all resources after 
>> >> allocation */
>> >>  #define ETNA_DBG_DRAW_STALL  0x40 /* Stall FE/PE after every 
>> >> draw op */
>> >> +#define ETNA_DBG_SHADERDB0x80 /* dump program compile 
>> >> information */
>> >>
>> >>  extern int etna_mesa_debug; /* set in etna_screen.c from ETNA_DEBUG */
>> >>
>> >> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
>> >> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
>> >> index 8f2882f..6272f6f 100644
>> >> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
>> >> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
>> >> @@ -62,6 +62,7 @@ static const struct debug_named_value debug_options[] = 
>> >> {
>> >> {"flush_all",  ETNA_DBG_FLUSH_ALL, "Flush after every rendered 
>> >> primitive"},
>> >> {"zero",   ETNA_DBG_ZERO, "Zero all resources after 
>> >> allocation"},
>> >> {"draw_stall", ETNA_DBG_DRAW_STALL, "Stall FE/PE after each 
>> >> rendered primitive"},
>> >> +   {"shaderdb",   ETNA_DBG_SHADERDB, "Enable shaderdb output"},
>> >> DEBUG_NAMED_VALUE_END
>> >>  };
>> >>
>> >> diff --git a/src/gallium/drivers/etnaviv/etnaviv_shader.c 
>> >> b/src/gallium/drivers/etnaviv/etnaviv_shader.c
>> >> index 8895311..87edf5b 100644
>> >> --- a/src/gallium/drivers/etnaviv/etnaviv_shader.c
>> >> +++ b/src/gallium/drivers/etnaviv/etnaviv_shader.c
>> >> @@ -223,6 +223,42 @@ etna_shader_update_vs_inputs(struct etna_context 
>> >> *ctx,
>> >> return true;
>> >>  }
>> >>
>> >> +static inline const char *
>> >> +etna_shader_stage(struct etna_shader *shader)
>> >> +{
>> >> +   switch (shader->processor) {
>> >> +   case PIPE_SHADER_VERTEX: return "VERT";
>> >> +   case PIPE_SHADER_FRAGMENT:   return "FRAG";
>> >> +   case PIPE_SHADER_COMPUTE:return "CL";
>> >> +   default:
>> >> +  unreachable("invalid type");
>> >> +  return NULL;
>> >> +   }
>> >> +}
>> >> +
>> >> +static void
>> >> +dump_shader_info(struct etna_shader *shader, struct pipe_debug_callback 
>> >> *debug)
>> >> +{
>> >> +   if (!unlikely(etna_mesa_debug & ETNA_DBG_SHADERDB))
>> >> +  return;
>> >> +
>> >> +   pipe_debug_message(debug, SHADER_INFO, "\n"
>> >> + "SHADER-DB: %s prog %d: %u instructions %u temps\n"
>> >> + "SHADER-DB: %s prog %d: %u immediates %u consts\n"
>> >> + "SHADER-DB: %s prog %d: %u loops\n",
>> >> + etna_shader_stage(shader),
>> >> + shader->id,
>> >> + shader->code_size,
>> >> + shader->num_temps,
>> >> + etna_shader_stage(shader),
>> >> + shader->id,
>> >> + shader->uniforms.imm_count,
>> >> + shader->uniforms.const_count,
>> >> + 

Re: [Mesa-dev] [PATCH 3/3] etnaviv: shader-db traces

[Christian Gmeiner]

Hi all

2017-02-09 13:50 GMT+01:00 Wladimir J. van der Laan :
>> > >>  /* shader object, for linking */
>> > >>  struct etna_shader {
>> > >> +   uint32_t id; /* for debug */
>> > >
>> > > Do you need this? It can certainly be removed from this patch, but I
>> > > don't know if you have other stuff building on top of this.
>> > >
>> >
>> > It gets used in dump_shader_info(..) which was added with this patch.
>>
>> My argument was that you could pass that value as an argument to
>> dump_shader_info(). I don't see why it needs to be stored inside the
>> etna_shader object.
>
> One advantage of storing it is that debug logging that refers to the shader
> can use the same number and it can be correlated with the info dumped earlier.
>
> Not that that is part of this patch, but that seems to be the goal.
>

Yeah.. thats the final goal.

> If not for that there's no real use for a counter anyway: just have whatever
> parses the output do the counting based on what is printed first.
>

For the moment I will pass the id as argument so everybody is happy and I can
push that change.

> But I think it's fine as it is.
>

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] spirv: Add support for SpvCapabilityStorageImageWriteWithoutFormat

[Alex Smith]

Allow that capability if the driver indicates that it is supported, and
flag whether images are read-only/write-only in the nir_variable (based
on the NonReadable and NonWritable decorations), which drivers may need
to implement this.

Signed-off-by: Alex Smith 
---
 src/compiler/spirv/nir_spirv.h | 1 +
 src/compiler/spirv/spirv_to_nir.c  | 5 -
 src/compiler/spirv/vtn_variables.c | 5 -
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/src/compiler/spirv/nir_spirv.h b/src/compiler/spirv/nir_spirv.h
index e0ebc62..e43e9b5 100644
--- a/src/compiler/spirv/nir_spirv.h
+++ b/src/compiler/spirv/nir_spirv.h
@@ -49,6 +49,7 @@ struct nir_spirv_supported_extensions {
bool image_ms_array;
bool tessellation;
bool draw_parameters;
+   bool image_write_without_format;
 };
 
 nir_function *spirv_to_nir(const uint32_t *words, size_t word_count,
diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 416e12a..3f77ddf 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -2666,7 +2666,6 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
   case SpvCapabilityMinLod:
   case SpvCapabilityTransformFeedback:
   case SpvCapabilityStorageImageReadWithoutFormat:
-  case SpvCapabilityStorageImageWriteWithoutFormat:
  vtn_warn("Unsupported SPIR-V capability: %s",
   spirv_capability_to_string(cap));
  break;
@@ -2702,6 +2701,10 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
  spv_check_supported(draw_parameters, cap);
  break;
 
+  case SpvCapabilityStorageImageWriteWithoutFormat:
+ spv_check_supported(image_write_without_format, cap);
+ break;
+
   default:
  unreachable("Unhandled capability");
   }
diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 098cfb5..d7d882e 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1054,8 +1054,12 @@ apply_var_decoration(struct vtn_builder *b, nir_variable 
*nir_var,
   assert(nir_var->constant_initializer != NULL);
   nir_var->data.read_only = true;
   break;
+   case SpvDecorationNonReadable:
+  nir_var->data.image.write_only = true;
+  break;
case SpvDecorationNonWritable:
   nir_var->data.read_only = true;
+  nir_var->data.image.read_only = true;
   break;
case SpvDecorationComponent:
   nir_var->data.location_frac = dec->literals[0];
@@ -1107,7 +,6 @@ apply_var_decoration(struct vtn_builder *b, nir_variable 
*nir_var,
case SpvDecorationAliased:
case SpvDecorationVolatile:
case SpvDecorationCoherent:
-   case SpvDecorationNonReadable:
case SpvDecorationUniform:
case SpvDecorationStream:
case SpvDecorationOffset:
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/2] anv: Add support for shaderStorageImageWriteWithoutFormat

[Alex Smith]

This allows shaders to write to storage images declared with unknown
format if they are decorated with NonReadable ("writeonly" in GLSL).

Previously an image view would always use a lowered format for its
surface state, however when a shader declares a write-only image, we
should use the real format. Since we don't know at view creation time
whether it will be used with only write-only images in shaders, create
two surface states using both the original format and the lowered
format. When emitting the binding table, choose between the states
based on whether the image is declared write-only in the shader.

Tested on both Sascha Willems' computeshader sample (with the original
shaders and ones modified to declare images writeonly and omit their
format qualifiers) and on our own shaders for which we need support
for this.

Signed-off-by: Alex Smith 
---
 src/intel/vulkan/anv_device.c|  2 +-
 src/intel/vulkan/anv_image.c | 31 +++-
 src/intel/vulkan/anv_nir_apply_pipeline_layout.c | 10 +---
 src/intel/vulkan/anv_pipeline.c  |  1 +
 src/intel/vulkan/anv_private.h   | 10 +++-
 src/intel/vulkan/genX_cmd_buffer.c   |  4 ++-
 6 files changed, 50 insertions(+), 8 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 91ee67f..46b83a3 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -484,7 +484,7 @@ void anv_GetPhysicalDeviceFeatures(
   .shaderStorageImageExtendedFormats= true,
   .shaderStorageImageMultisample= false,
   .shaderStorageImageReadWithoutFormat  = false,
-  .shaderStorageImageWriteWithoutFormat = false,
+  .shaderStorageImageWriteWithoutFormat = true,
   .shaderUniformBufferArrayDynamicIndexing  = true,
   .shaderSampledImageArrayDynamicIndexing   = true,
   .shaderStorageBufferArrayDynamicIndexing  = true,
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index e59ef4d..1aeec44 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -583,13 +583,29 @@ anv_CreateImageView(VkDevice _device,
/* NOTE: This one needs to go last since it may stomp isl_view.format */
if (image->usage & VK_IMAGE_USAGE_STORAGE_BIT) {
   iview->storage_surface_state = alloc_surface_state(device);
+  iview->writeonly_storage_surface_state = alloc_surface_state(device);
 
   if (isl_has_matching_typed_storage_image_format(>info,
   format.isl_format)) {
  struct isl_view view = iview->isl;
  view.usage |= ISL_SURF_USAGE_STORAGE_BIT;
+
+ /* Write-only accesses should use the real format. */
+ isl_surf_fill_state(>isl_dev,
+ iview->writeonly_storage_surface_state.map,
+ .surf = >isl,
+ .view = ,
+ .aux_surf = >aux_surface.isl,
+ .aux_usage = surf_usage,
+ .mocs = device->default_mocs);
+
+ /* Typed surface reads support a very limited subset of the shader
+  * image formats.  Translate it into the closest format the hardware
+  * supports.
+  */
  view.format = isl_lower_storage_image_format(>info,
   format.isl_format);
+
  isl_surf_fill_state(>isl_dev,
  iview->storage_surface_state.map,
  .surf = >isl,
@@ -602,16 +618,24 @@ anv_CreateImageView(VkDevice _device,
ISL_FORMAT_RAW,
iview->offset,
iview->bo->size - iview->offset, 1);
+ anv_fill_buffer_surface_state(device,
+   iview->writeonly_storage_surface_state,
+   ISL_FORMAT_RAW,
+   iview->offset,
+   iview->bo->size - iview->offset, 1);
   }
 
   isl_surf_fill_image_param(>isl_dev,
 >storage_image_param,
 >isl, >isl);
 
-  if (!device->info.has_llc)
+  if (!device->info.has_llc) {
  anv_state_clflush(iview->storage_surface_state);
+ anv_state_clflush(iview->writeonly_storage_surface_state);
+  }
} else {
   iview->storage_surface_state.alloc_size = 0;
+  iview->writeonly_storage_surface_state.alloc_size = 0;
}
 
*pView = anv_image_view_to_handle(iview);
@@ -639,6 +663,11 @@ anv_DestroyImageView(VkDevice _device, VkImageView _iview,
   iview->storage_surface_state);
}
 
+   if 

Re: [Mesa-dev] [Freedreno] WebProcess crash on DB410c

[zan]

Hi,



I'm not sure exactly what mechanism you're using to implement the WPE
interfaces, so I'll just list a few options.


Focusing on wpe_renderer_backend_egl_offscreen_target_interface that's
used as the basis for the sharing context and WebGL contexts, the
simplest implementation would just return NULL in get_native_window().
That effectively enforces creation of a pbuffer-based context, but that
isn't available on some platforms.


A workaround for this is using dummy surfaces, if possible. Here's
implementations for WPE backend implementations that are based on libgbm
and wayland-egl:
https://github.com/WebKitForWayland/wpe-mesa/blob/master/src/gbm/renderer-backend-egl-gbm.cpp#L237
https://github.com/WebKitForWayland/wpe-mesa/blob/master/src/nc/renderer-backend-egl.cpp#L269


Those were developed and tested on top of the Mesa library, but weren't
tested with the Freedreno driver, at least not to my knowledge.


Hope that helps,

Zan





On Mon, Feb 6, 2017, at 07:32 AM, Sivasubramanian Patchaiperumal wrote:
> Tried writing a simple EGL pbuffer application and tested it on
> DB410c. As expected, eglChooseConfig returned no matched config
> available. Is there something we can do to get pbuffer support
> on Mesa?
> 

> On 3 February 2017 at 20:33, Rob Clark  wrote:

>> Hmm, could be that westeros is doing something wrong that causes the
>>  pbuffer path to be hit.  I'm not entirely sure why pbuffer is not

>>  supported in wayland (other than just that these days there are
>>  better
>>  ways to do things than pbuffer), although I thought I remembered

>>  seeing a fallback to surfaceless in webkit..

>> 

>>  BR,

>>  -R

>> 

>>  On Fri, Feb 3, 2017 at 1:05 AM, Sivasubramanian Patchaiperumal

>> 

>>  wrote:

>>  > One more point is westeros always return null window for offscreen
>>  > target,
>>  > that why WPE falls back to pbuffer on HiKey and DB410c cases.

>>  >

>>  > On 3 February 2017 at 11:30, Sivasubramanian Patchaiperumal

>>  >  wrote:

>>  >>

>>  >> Thanks Rob for your inputs. Yes, you are looking at the right
>>  >> place. But
>>  >> the HiKey which takes same pbuffer path and it working with Mali
>>  >> is the
>>  >> reference now. I'm trying to write a simple egl app that uses
>>  >> pbuffer to
>>  >> confirm the support with Mesa. Does it sounds correct or you have
>>  >> any
>>  >> suggestions?

>>  >>

>>  >> On 3 February 2017 at 02:06, Rob Clark 
>>  >> wrote:
>>  >>>

>>  >>> btw, where exactly is it crashing?  I grabbed the
>>  >>> WebKitForWayland
>>  >>> tree.. if I'm looking at the right thing, the only place where
>>  >>> it
>>  >>> should try to create a pbuffer is in

>>  >>> Source/WebCore/platform/graphics/egl/GLContextEGL.cpp and that
>>  >>> looks
>>  >>> like it should only be a fallback after createWaylandContext()
>>  >>> fails??
>>  >>>

>>  >>> I suspect pbuffer is not the root problem, that looks like a
>>  >>> fallback
>>  >>> path that shouldn't be hit..

>>  >>>

>>  >>> BR,

>>  >>> -R

>>  >>>

>>  >>> On Thu, Feb 2, 2017 at 9:55 AM, Rob Clark 
>>  >>> wrote:
>>  >>> > hmm, just looking at dri2_wl_display_vtbl:

>>  >>> >

>>  >>> >.create_pbuffer_surface =
>>  >>> >dri2_fallback_create_pbuffer_surface,
>>  >>> >

>>  >>> > which just returns null.. so I guess pbuffers are not
>>  >>> > supported under
>>  >>> > wayland.

>>  >>> >

>>  >>> > Bit of google search reveals:

>>  >>> >

>>  >>> >

>>  >>> > 
>> https://lists.freedesktop.org/archives/wayland-devel/2012-April/002928.html
>>  >>> >

>>  >>> > so I think the answer is don't use pbuffers.

>>  >>> >

>>  >>> > BR,

>>  >>> > -R

>>  >>> >

>>  >>> > On Thu, Feb 2, 2017 at 9:50 AM, Rob Clark
>>  >>> >  wrote:
>>  >>> >> hmm, tons of older stuff uses pbuffers w/ x11.. although a
>>  >>> >> quick look
>>  >>> >> at mesa/demos.git and it doesn't look like any of them that
>>  >>> >> build for
>>  >>> >> wayland do.  I don't think pbuffers are used much anymore.
>>  >>> >> But I
>>  >>> >> would expect there should be some piglit tests which do.

>>  >>> >>

>>  >>> >> (Plus, firefox and chromium have been ported to wayland.. and
>>  >>> >> quite a
>>  >>> >> lot of other sw.  And a lot of us are using wayland on our

>>  >>> >> laptops/desktops these days.)

>>  >>> >>

>>  >>> >> BR,

>>  >>> >> -R

>>  >>> >>

>>  >>> >> On Thu, Feb 2, 2017 at 9:39 AM, Sivasubramanian
>>  >>> >> Patchaiperumal
>>  >>> >>  wrote:

>>  >>> >>> Yes, WebProcess(in WebKit) is crashing on DB410c. Any client
>>  >>> >>> that
>>  >>> >>> uses

>>  >>> >>> pbuffer surfaces will crash I suspect. Is there is any
>>  >>> >>> simple egl
>>  >>> >>> application that uses pixel buffer to verify and confirm?

>>  >>> >>>

>>  >>> >>> On 2 February 2017 at 19:00, Rob Clark 
>>  >>> >>> wrote:

Re: [Mesa-dev] [PATCH 01/10] glx: remove always true ifdef guards

[Matt Turner]

On Thu, Feb 9, 2017 at 3:22 PM, Matt Turner  wrote:
> On Thu, Feb 9, 2017 at 1:35 PM, Emil Velikov  wrote:
>> From: Emil Velikov 
>>
>> The two symbols referenced were introduced with v2.2 and 2.3 of
>> the dri2proto package.
>
> ... and we require dri2proto >= 2.6.
>
> Reviewed-by: Matt Turner 

1-8 are

Reviewed-by: Matt Turner 

I didn't bother checking all of the defines in 9-10, so those can have an

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

Re: [Mesa-dev] [PATCH 05/10] glx: remove DRI2DriverPrimeShift compile guards

[Matt Turner]

On Thu, Feb 9, 2017 at 1:35 PM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Macro will always be defined as of earlier commit.

Same comment as 04/10.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/10] vl: remove DRI2DriverPrimeShift compile guards

[Matt Turner]

On Thu, Feb 9, 2017 at 1:35 PM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Macro will always be defined as of earlier commit.

How about something like

DRI2DriverPrimeShift was added in dri2proto-2.8, which we now require
as of the previous commit.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/10] glx: remove always true ifdef guards

[Matt Turner]

On Thu, Feb 9, 2017 at 1:35 PM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> The two symbols referenced were introduced with v2.2 and 2.3 of
> the dri2proto package.

... and we require dri2proto >= 2.6.

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

Re: [Mesa-dev] [PATCH 7/7] i965/fs: add support for int64 to bool conversion

[Jason Ekstrand]

These all need to go into 17.0

On Feb 8, 2017 06:59, "Samuel Iglesias Gonsálvez" 
wrote:

> Signed-off-by: Samuel Iglesias Gonsálvez 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99660
> ---
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> index 76887a9e3eb..991c20fad62 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> @@ -1094,15 +1094,26 @@ fs_visitor::nir_emit_alu(const fs_builder ,
> nir_alu_instr *instr)
> case nir_op_f2b:
>bld.CMP(result, op[0], brw_imm_f(0.0f), BRW_CONDITIONAL_NZ);
>break;
> +
> +   case nir_op_i642b:
> case nir_op_d2b: {
>/* two-argument instructions can't take 64-bit immediates */
> -  fs_reg zero = vgrf(glsl_type::double_type);
> +  fs_reg zero;
> +  fs_reg tmp;
> +
> +  if (instr->op == nir_op_d2b) {
> + zero = vgrf(glsl_type::double_type);
> + tmp = vgrf(glsl_type::double_type);
> +  } else {
> + zero = vgrf(glsl_type::int64_t_type);
> + tmp = vgrf(glsl_type::int64_t_type);
> +  }
> +
>bld.MOV(zero, setup_imm_df(bld, 0.0));
>/* A SIMD16 execution needs to be split in two instructions, so use
> * a vgrf instead of the flag register as dst so instruction
> splitting
> * works
> */
> -  fs_reg tmp = vgrf(glsl_type::double_type);
>bld.CMP(tmp, op[0], zero, BRW_CONDITIONAL_NZ);
>bld.MOV(result, subscript(tmp, BRW_REGISTER_TYPE_UD, 0));
>break;
> --
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel/blorp: Swizzle clear colors on the CPU

[Jason Ekstrand]

On Feb 9, 2017 02:23, "Juan A. Suarez Romero"  wrote:

On Wed, 2017-02-08 at 13:35 -0800, Jason Ekstrand wrote:
> This fixes the following Vulkan CTS tests on Haswell:
>
> - dEQP-VK.api.image_clearing.clear_color_image.1d_b4g4r4a4_unorm_pack16
> - dEQP-VK.api.image_clearing.clear_color_image.2d_b4g4r4a4_unorm_pack16
> - dEQP-VK.api.image_clearing.clear_color_image.3d_b4g4r4a4_unorm_pack16
> ---


I've tried, and it still crashes in assertion:

deqp-vk: anv_private.h:1565: anv_swizzle_for_render: Assertion
`swizzle.a == ISL_CHANNEL_SELECT_ONE || swizzle.a ==
ISL_CHANNEL_SELECT_ALPHA' failed.


It seems it still requires patch from https://lists.freedesktop.org/arc
hives/mesa-dev/2017-February/143480.html


There's a small typo also in a comment.

Other than that, it is:

Reviewed-by: Juan A. Suarez Romero .



BTW, I've also sent a couple of patches to fix these tests:

https://lists.freedesktop.org/archives/mesa-dev/2017-February/143479.ht
ml

Giving the above comment, I guess your preference is using patch 1/2
that I sent, and use this one you've sent instead of 2/2, right.


Yes, I would rather fix this in blorp though I am a bit surprised that
patch 1 is needed too.


J.A.


>  src/intel/blorp/blorp_clear.c | 45 ++
-
>  1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
> index 8ea22ac..e452713 100644
> --- a/src/intel/blorp/blorp_clear.c
> +++ b/src/intel/blorp/blorp_clear.c
> @@ -328,6 +328,23 @@ blorp_fast_clear(struct blorp_batch *batch,
> batch->blorp->exec(batch, );
>  }
>
> +static union isl_color_value
> +swizzle_color_value(union isl_color_value src, struct isl_swizzle
swizzle)
> +{
> +   union isl_color_value dst;
> +
> +   assert((unsigned)(swizzle.r - ISL_CHANNEL_SELECT_RED) < 4);
> +   assert((unsigned)(swizzle.g - ISL_CHANNEL_SELECT_RED) < 4);
> +   assert((unsigned)(swizzle.b - ISL_CHANNEL_SELECT_RED) < 4);
> +   assert((unsigned)(swizzle.a - ISL_CHANNEL_SELECT_RED) < 4);
> +
> +   dst.u32[swizzle.r - ISL_CHANNEL_SELECT_RED] = src.u32[0];
> +   dst.u32[swizzle.g - ISL_CHANNEL_SELECT_RED] = src.u32[1];
> +   dst.u32[swizzle.b - ISL_CHANNEL_SELECT_RED] = src.u32[2];
> +   dst.u32[swizzle.a - ISL_CHANNEL_SELECT_RED] = src.u32[3];
> +
> +   return dst;
> +}
>
>  void
>  blorp_clear(struct blorp_batch *batch,
> @@ -346,6 +363,14 @@ blorp_clear(struct blorp_batch *batch,
> params.x1 = x1;
> params.y1 = y1;
>
> +   /* Manually apply the clear destination swizzle.  This way swizzled
clears
> +* will work for swizzles which we can't normally use for rendering
and it
> +* also ensures that they work on pre-Haswell hardware which can't
swizlle
^^^
  typo: swizzle
> +* at all.
> +*/
> +   clear_color = swizzle_color_value(clear_color, swizzle);
> +   swizzle = ISL_SWIZZLE_IDENTITY;
> +
> if (format == ISL_FORMAT_R9G9B9E5_SHAREDEXP) {
>clear_color.u32[0] = float3_to_rgb9e5(clear_color.f32);
>format = ISL_FORMAT_R32_UINT;
> @@ -353,24 +378,8 @@ blorp_clear(struct blorp_batch *batch,
>/* Broadwell and earlier cannot render to this format so we need
to work
> * around it by swapping the colors around and using B4G4R4A4
instead.
> */
> -
> -  /* First, we apply the swizzle. */
> -  union isl_color_value old;
> -  assert((unsigned)(swizzle.r - ISL_CHANNEL_SELECT_RED) < 4);
> -  assert((unsigned)(swizzle.g - ISL_CHANNEL_SELECT_RED) < 4);
> -  assert((unsigned)(swizzle.b - ISL_CHANNEL_SELECT_RED) < 4);
> -  assert((unsigned)(swizzle.a - ISL_CHANNEL_SELECT_RED) < 4);
> -  old.u32[swizzle.r - ISL_CHANNEL_SELECT_RED] = clear_color.u32[0];
> -  old.u32[swizzle.g - ISL_CHANNEL_SELECT_RED] = clear_color.u32[1];
> -  old.u32[swizzle.b - ISL_CHANNEL_SELECT_RED] = clear_color.u32[2];
> -  old.u32[swizzle.a - ISL_CHANNEL_SELECT_RED] = clear_color.u32[3];
> -  swizzle = ISL_SWIZZLE_IDENTITY;
> -
> -  /* Now we re-order for the new format */
> -  clear_color.u32[0] = old.u32[1];
> -  clear_color.u32[1] = old.u32[2];
> -  clear_color.u32[2] = old.u32[3];
> -  clear_color.u32[3] = old.u32[0];
> +  const struct isl_swizzle ARGB = ISL_SWIZZLE(ALPHA, RED, GREEN,
BLUE);
> +  clear_color = swizzle_color_value(clear_color, ARGB);
>format = ISL_FORMAT_B4G4R4A4_UNORM;
> }
>
___
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] glsl: Allow compatibility shaders with MESA_GL_VERSION_OVERRIDE=...

[Ian Romanick]

Reviewed-by: Ian Romanick 

On 02/01/2017 12:20 AM, Matt Turner wrote:
> Previously if you used MESA_GL_VERSION_OVERRIDE=3.3COMPAT, Mesa exposed
> an OpenGL 3.3 compatibility profile context (with various unimplemented
> features and bugs), but still refused to compile shaders with
> 
>#version 330 compatibility
> 
> This patch simply adds a small bit of plumbing to let that through.
> 
> Of course the same caveats apply: compatibility profile is still not
> supported (and will not be supported), so there are no guarantees that
> anything will work.
> ---
>  src/compiler/glsl/builtin_types.cpp  |  2 +-
>  src/compiler/glsl/builtin_variables.cpp  |  2 +-
>  src/compiler/glsl/glsl_parser_extras.cpp | 13 +++--
>  src/compiler/glsl/glsl_parser_extras.h   |  1 +
>  4 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/src/compiler/glsl/builtin_types.cpp 
> b/src/compiler/glsl/builtin_types.cpp
> index a63d736..cae972b 100644
> --- a/src/compiler/glsl/builtin_types.cpp
> +++ b/src/compiler/glsl/builtin_types.cpp
> @@ -288,7 +288,7 @@ _mesa_glsl_initialize_types(struct _mesa_glsl_parse_state 
> *state)
> /* Add deprecated structure types.  While these were deprecated in 1.30,
>  * they're still present.  We've removed them in 1.40+ (OpenGL 3.1+).
>  */
> -   if (!state->es_shader && state->language_version < 140) {
> +   if (state->compat_shader) {
>for (unsigned i = 0; i < ARRAY_SIZE(deprecated_types); i++) {
>   add_type(symbols, deprecated_types[i]);
>}
> diff --git a/src/compiler/glsl/builtin_variables.cpp 
> b/src/compiler/glsl/builtin_variables.cpp
> index 4eb275e..be593e9 100644
> --- a/src/compiler/glsl/builtin_variables.cpp
> +++ b/src/compiler/glsl/builtin_variables.cpp
> @@ -444,7 +444,7 @@ private:
>  builtin_variable_generator::builtin_variable_generator(
> exec_list *instructions, struct _mesa_glsl_parse_state *state)
> : instructions(instructions), state(state), symtab(state->symbols),
> - compatibility(!state->is_version(140, 100)),
> + compatibility(state->compat_shader || !state->is_version(140, 100)),
>   bool_t(glsl_type::bool_type), int_t(glsl_type::int_type),
>   uint_t(glsl_type::uint_type),
>   float_t(glsl_type::float_type), vec2_t(glsl_type::vec2_type),
> diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
> b/src/compiler/glsl/glsl_parser_extras.cpp
> index e888090..1e47d8c 100644
> --- a/src/compiler/glsl/glsl_parser_extras.cpp
> +++ b/src/compiler/glsl/glsl_parser_extras.cpp
> @@ -82,6 +82,7 @@ _mesa_glsl_parse_state::_mesa_glsl_parse_state(struct 
> gl_context *_ctx,
> this->forced_language_version = ctx->Const.ForceGLSLVersion;
> this->zero_init = ctx->Const.GLSLZeroInit;
> this->gl_version = 20;
> +   this->compat_shader = true;
> this->es_shader = false;
> this->ARB_texture_rectangle_enable = true;
>  
> @@ -369,6 +370,7 @@ _mesa_glsl_parse_state::process_version_directive(YYLTYPE 
> *locp, int version,
>const char *ident)
>  {
> bool es_token_present = false;
> +   bool compat_token_present = false;
> if (ident) {
>if (strcmp(ident, "es") == 0) {
>   es_token_present = true;
> @@ -378,8 +380,12 @@ 
> _mesa_glsl_parse_state::process_version_directive(YYLTYPE *locp, int version,
>   * a core profile shader since that's the only profile we 
> support.
>   */
>   } else if (strcmp(ident, "compatibility") == 0) {
> -_mesa_glsl_error(locp, this,
> - "the compatibility profile is not supported");
> +compat_token_present = true;
> +
> +if (this->ctx->API != API_OPENGL_COMPAT) {
> +   _mesa_glsl_error(locp, this,
> +"the compatibility profile is not 
> supported");
> +}
>   } else {
>  _mesa_glsl_error(locp, this,
>   "\"%s\" is not a valid shading language 
> profile; "
> @@ -411,6 +417,9 @@ _mesa_glsl_parse_state::process_version_directive(YYLTYPE 
> *locp, int version,
> else
>this->language_version = version;
>  
> +   this->compat_shader = compat_token_present ||
> + (!this->es_shader && this->language_version < 140);
> +
> bool supported = false;
> for (unsigned i = 0; i < this->num_supported_versions; i++) {
>if (this->supported_versions[i].ver == this->language_version
> diff --git a/src/compiler/glsl/glsl_parser_extras.h 
> b/src/compiler/glsl/glsl_parser_extras.h
> index 424cab5..66a954f 100644
> --- a/src/compiler/glsl/glsl_parser_extras.h
> +++ b/src/compiler/glsl/glsl_parser_extras.h
> @@ -348,6 +348,7 @@ struct _mesa_glsl_parse_state {
> } supported_versions[16];
>  
> bool es_shader;
> +   bool compat_shader;
> unsigned language_version;
> unsigned forced_language_version;
> bool zero_init;

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Marek Olšák]

On Thu, Feb 9, 2017 at 1:52 PM, Ian Romanick  wrote:
> On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
>> On 07.02.2017 23:54, Matt Turner wrote:
>>> On Tue, Feb 7, 2017 at 10:56 AM, Marek Olšák  wrote:
 On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke
  wrote:
> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote:
>> On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand 
>> wrote:
>>> FYI glmark2 segfaults with mesa_glthread=true. Expected that some
>>> programs
>>> will segfault?
>>
>> Yes, even segfaults are expected with mesa_glthread=true.
>>
>> Marek
>
> Would it make sense to be crash-free or even regression-free on at
> least Piglit, before merging?  (Or are we there already?)

 It's not necessary. glthread is disabled by default. Nobody has tested
 piglit with glthread. That will follow after it's been merged, or
 never if it's never merged.
>>>
>>> I don't understand why you're so concerned about merging untested
>>> code. That violates some pretty fundamental development practices of
>>> the project.
>>>
>>> It's exactly unfinished projects like this that cause problems and
>>> inevitably have to be deleted later (ilo, openvg, d3d1x, etc). I don't
>>> think it's a burden to develop something out of the master branch
>>> until it's somewhat useful.
>>
>> The code is already somewhat useful. Actually, make that _very_ useful
>> (big performance improvement) for _some_ cases.
>>
>> I suspect most of the people in this discussion haven't really looked at
>> the code in detail (myself included). We should probably do some of that
>> before it is merged, since the code isn't just a new driver that is
>> isolated in its own directory. So I agree with Emil that it makes sense
>> to let the patches go over the mailing list once.
>>
>> However, it's fine to merge this without passing piglit.
>
> No, it absolutely is not fine to merge.  We have never allowed such a
> thing, and I'll be damned if I'll allow this project to start.  Things
> that land that are known to be broken never actually get fixed.  Then we
> have to waste time fielding bug reports and Phoronix threads because
> users turn on the performance features and everything breaks.  It's just
> a terrible idea.

It does pass piglit, but only when it's disabled.

We have to ask the question of how long it will take to reach the
level of perfection that some people here demand. 1 year? 2? 4 years
even? Are we willing to wait that long? Is there a sufficient minimum
requirement on merging this project that's possible to reach within 2
weeks? Instead of saying "absolutely not" and "terrible idea", why not
just say "yes if X gets done"?

If you only expect absolutism and perfectionism, you'll be very
disappointed with this project. Doing a threaded GL dispatch is hard.
NVIDIA had had performance issues with it for a very long time. AMD
doesn't even have a solution that can be enabled by default.

I'm not heavily invested in this project (yet), so it won't bother me
much if this doesn't get merged before mid-2017. If people wanna
contribute, they can send me pull requests. (please do it early &
often, don't wait until you have something that's good enough)

I've been contemplating doing threaded gallium dispatch for a while
now. It should be very easy if we copy some sync prevention tricks
from radeonsi, and we might be able to enable it by default for all GL
apps (core & compat) from day 1. That can be our short-term goal for
gallium, while threaded GL can be our long-term goal and only limited
to whitelisted apps for quite a while.

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

Re: [Mesa-dev] [PATCH] swr: [rasterizer common/core/jitter] fetch support for GL_FIXED

[Emil Velikov]

On 7 December 2016 at 23:58, Tim Rowley  wrote:
> ---
>  .../drivers/swr/rasterizer/common/formats.cpp  | 104 
> ++---
>  .../drivers/swr/rasterizer/common/formats.h|   7 +-
>  .../drivers/swr/rasterizer/core/format_traits.h|  90 +-
Tim, these three seems to be auto-generated from somewhere, yet the
scripts are missing.
Can we merge the script(s) and drop the files from git ?

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

Re: [Mesa-dev] [PATCH mesa 1/4] docs: add a note about the new version scheme

[Emil Velikov]

On 8 February 2017 at 11:27, Eric Engestrom  wrote:
> Signed-off-by: Eric Engestrom 
> ---
>  docs/download.html | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/docs/download.html b/docs/download.html
> index e90c1bbbf2..1cbfded575 100644
> --- a/docs/download.html
> +++ b/docs/download.html
> @@ -24,6 +24,14 @@
>  
>
>  
> +Starting with the first release of 2017, Mesa's version scheme is
> +year-based. Filenames are in the form mesa-Y.N.P.tar.gz, where
> +Y is the year (two digits), N is an incremental number
> +(starting at 0) and P is the patch number (0 for the first
> +release, 1 for the first patch after that).
> +
> +
I'll send a patch later on today which adds a bit more and add some
cross-referencing.
That aside all your documentation patches (this 4 series and the the
3) look pretty good.
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH mesa 4/4] docs: update package contents

[Emil Velikov]

On 8 February 2017 at 11:27, Eric Engestrom  wrote:
> Signed-off-by: Eric Engestrom 
> ---
>
> Do we want to list all the modules under src/ ?
> The current list seems a bit arbitrary:
> src/- source code for libraries
> src/mesa- sources for the main Mesa library and device drivers
> src/gallium - sources for Gallium and Gallium drivers
> src/glx - sources for building libGL with full GLX and DRI support
>
Indeed it is. There's a slightly more elaborate list in
docs/sourcetree.html so I'll drop Contents all together.

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

Re: [Mesa-dev] [PATCH 2/2] docs: update intro.html to mention new APIs, etc

[Emil Velikov]

Thanks Brian,

A couple of small additions below, if you've not pushed the series.

On 8 February 2017 at 19:31, Brian Paul  wrote:

> +http://www.khronos.org/opengles/;>OpenGL ES (versions 1, 2, 3),
> +http://www.khronos.org/opencl/;>OpenCL,
http://www.khronos.org/openmax/;>OpenMAX,

> +https://en.wikipedia.org/wiki/VDPAU;>VDPAU and
https://en.wikipedia.org/wiki/Video_Acceleration_API;>VA API and
https://en.wikipedia.org/wiki/X-Video_Motion_Compensation;>XvMC and

> +http://www.khronos.org/vulkan/;>Vulkan.
>  
>
>  
> -Mesa ties into several other open-source projects: the
> -http://dri.freedesktop.org/;>Direct Rendering
> -Infrastructure and http://x.org;>X.org to
> -provide OpenGL support to users of X on Linux, FreeBSD and other operating
> +A variety of device drivers allows the Mesa libraries to be used in many
> +different environments ranging from software emulation to complete hardware
> +acceleration for modern GPUs.
> +
> +
> +
> +Mesa ties into several other open-source projects: the
> +http://dri.freedesktop.org/;>Direct Rendering
> +Infrastructure and http://x.org;>X.org to
> +provide OpenGL support on Linux, FreeBSD and other operating
>  systems.
>  
>
> @@ -153,13 +162,21 @@ and version 1.30 of the OpenGL Shading Language.
>  
>
>  
> +July 2016: Mesa 12.0 is released, including OpenGL 4.3 support and initial
> +support for Vulkan for Intel GPUs.  Plus, there's another gallium software
> +driver ("swr") based on LLVM and developed by Intel.
> +
> +
> +
>  Ongoing: Mesa is the OpenGL implementation for several types of hardware
>  made by Intel, AMD and NVIDIA, plus the VMware virtual GPU.
Ongoing: Mesa is the OpenGL implementation for devices designed by Intel,
AMD, NVIDIA, Qualcomm, Broadcom, Vivante, plus the VMware and VirGL
virtual GPUs.

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

[Mesa-dev] [PATCH 2/2] glsl: refactor get_variable_being_redeclared() to return always an ir_variable pointer

[Samuel Iglesias Gonsálvez]

It will return the current variable ('var') or the earlier declaration 
('earlier') in
case of redeclaration of that variable.

In order to distinguish between both, 'is_redeclaration' boolean will indicate 
in which
case we are.

Signed-off-by: Samuel Iglesias Gonsálvez 
---

This can be merged with the previous one but I kept them separate because the 
other
fixes the issue and this one is just a refactor.

 src/compiler/glsl/ast_to_hir.cpp | 61 ++--
 1 file changed, 34 insertions(+), 27 deletions(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 3613161472d..73f0b42072f 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -3947,7 +3947,8 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
 }
 
 /**
- * Get the variable that is being redeclared by this declaration
+ * Get the variable that is being redeclared by this declaration or if it
+ * does not exist, the current declared variable.
  *
  * Semantic checks to verify the validity of the redeclaration are also
  * performed.  If semantic checks fail, compilation error will be emitted via
@@ -3955,12 +3956,15 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
  *
  * \returns
  * A pointer to an existing variable in the current scope if the declaration
- * is a redeclaration, \c NULL otherwise.
+ * is a redeclaration, current variable otherwise. \c is_declared boolean
+ * will return \c true if the declaration is a redeclaration, \c false
+ * otherwise.
  */
 static ir_variable *
 get_variable_being_redeclared(ir_variable *var, YYLTYPE loc,
   struct _mesa_glsl_parse_state *state,
-  bool allow_all_redeclarations)
+  bool allow_all_redeclarations,
+  bool *is_redeclaration)
 {
/* Check if this declaration is actually a re-declaration, either to
 * resize an array or add qualifiers to an existing variable.
@@ -3972,9 +3976,11 @@ get_variable_being_redeclared(ir_variable *var, YYLTYPE 
loc,
if (earlier == NULL ||
(state->current_function != NULL &&
!state->symbols->name_declared_this_scope(var->name))) {
-  return NULL;
+  *is_redeclaration = false;
+  return var;
}
 
+   *is_redeclaration = true;
 
/* From page 24 (page 30 of the PDF) of the GLSL 1.50 spec,
 *
@@ -5206,21 +5212,23 @@ ast_declarator_list::hir(exec_list *instructions,
   /* Examine var name here since var may get deleted in the next call */
   bool var_is_gl_id = is_gl_identifier(var->name);
 
-  ir_variable *earlier =
+  bool is_redeclaration;
+  ir_variable *declared_var =
  get_variable_being_redeclared(var, decl->get_location(), state,
-   false /* allow_all_redeclarations */);
-  if (earlier != NULL) {
+   false /* allow_all_redeclarations */,
+   _redeclaration);
+  if (is_redeclaration) {
  if (var_is_gl_id &&
- earlier->data.how_declared == ir_var_declared_in_block) {
+ declared_var->data.how_declared == ir_var_declared_in_block) {
 _mesa_glsl_error(, state,
  "`%s' has already been redeclared using "
- "gl_PerVertex", earlier->name);
+ "gl_PerVertex", declared_var->name);
  }
- earlier->data.how_declared = ir_var_declared_normally;
+ declared_var->data.how_declared = ir_var_declared_normally;
   }
 
   if (decl->initializer != NULL) {
- result = process_initializer((earlier == NULL) ? var : earlier,
+ result = process_initializer(declared_var,
   decl, this->type,
   _instructions, state);
   } else {
@@ -5240,8 +5248,7 @@ ast_declarator_list::hir(exec_list *instructions,
   }
 
   if (state->es_shader) {
- const glsl_type *const t = (earlier == NULL)
-? var->type : earlier->type;
+ const glsl_type *const t = declared_var->type;
 
  /* Skip the unsized array check for TCS/TES/GS inputs & TCS outputs.
   *
@@ -5262,13 +5269,11 @@ ast_declarator_list::hir(exec_list *instructions,
   * sized by an earlier input primitive layout qualifier, when
   * present, as per the following table."
   */
- const enum ir_variable_mode mode = (const enum ir_variable_mode)
-(earlier == NULL ? var->data.mode : earlier->data.mode);
  const bool implicitly_sized =
-(mode == ir_var_shader_in &&
+(declared_var->data.mode == ir_var_shader_in &&
  state->stage >= MESA_SHADER_TESS_CTRL &&
  state->stage <= 

[Mesa-dev] [PATCH 1/2] glsl: fix heap-use-after-free in ast_declarator_list::hir()

[Samuel Iglesias Gonsálvez]

The get_variable_being_redeclared() function can free 'var' because
a re-declaration of an unsized array variable can establish the size, so
we set the array type to the 'earlier' declaration and free 'var' as it is
not needed anymore.

However, the same 'var' is referenced later in ast_declarator_list::hir().

This patch fixes it by picking the ir_variable_mode from the proper
ir_variable.

This error was detected by Address Sanitizer.

Signed-off-by: Samuel Iglesias Gonsálvez 
Suggested-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99677
Cc: "17.0" 
---
 src/compiler/glsl/ast_to_hir.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index b31b61d1ed6..3613161472d 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -5262,11 +5262,13 @@ ast_declarator_list::hir(exec_list *instructions,
   * sized by an earlier input primitive layout qualifier, when
   * present, as per the following table."
   */
+ const enum ir_variable_mode mode = (const enum ir_variable_mode)
+(earlier == NULL ? var->data.mode : earlier->data.mode);
  const bool implicitly_sized =
-(var->data.mode == ir_var_shader_in &&
+(mode == ir_var_shader_in &&
  state->stage >= MESA_SHADER_TESS_CTRL &&
  state->stage <= MESA_SHADER_GEOMETRY) ||
-(var->data.mode == ir_var_shader_out &&
+(mode == ir_var_shader_out &&
  state->stage == MESA_SHADER_TESS_CTRL);
 
  if (t->is_unsized_array() && !implicitly_sized)
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH v2] glsl: fix heap-use-after-free in ast_declarator_list::hir()

[Samuel Iglesias Gonsálvez]

On Thu, 2017-02-09 at 13:34 +0100, Ian Romanick wrote:
> NAK.
> 
> The way the code is currently architected, if earlier is non-NULL,
> var
> should not be used.  There are quite a few places where the callees
> do
> things like 'const glsl_type *const t = (earlier == NULL) ? var->type 
> :
> earlier->type;'.  This is a bit confusing, but this change muddles
> that
> and makes it worse.
> 
> I think the actual use-after-free is in setting implicitly_sized at
> line
> 5265.  I think doing something like
> 
> const enum ir_variable_mode *mode = earlier == NULL
> ? >data.mode : >data.mode;
>  const bool implicitly_sized =
> (mode == ir_var_shader_in &&
>  state->stage >= MESA_SHADER_TESS_CTRL &&
>  state->stage <= MESA_SHADER_GEOMETRY) ||
> (mode == ir_var_shader_out &&
>  state->stage == MESA_SHADER_TESS_CTRL);
> 
> should also fix the problem.  This should be tagged for stable.
> 

Right. I'll do it.

> After that fix, we may want to look at rearchitecting this code to be
> less... confusing.  The fundamental problem is
> get_variable_being_redeclared is really trying to return two pieces
> of
> information, but it does this through a single variable.
> 
> 1. Is this actually a redeclaration?
> 
> 2. What is the variable that needs to be modified?
> 
> When get_variable_being_redeclared returns NULL, it's not a
> redeclaration, and the variable being modified is the ir_variable
> passed
> in.  When it returns non-NULL, it is a redeclaration, and the
> variable
> being modified is the one returned.
> 
> Maybe the function should always return non-NULL (returning either
> 'earlier' or 'var') and have an extra parameter 'bool
> *redeclaration'.
> I think that would result in almost no changes to the second caller
> and
> several simplifications to the first caller.  Thoughts?
> 

Yeah, that could improve things.

I am going to send two patches, one is the aforementioned fix (with Cc
to mesa-stable@) and another with the refactor.

Sam

> On 02/07/2017 01:47 PM, Samuel Iglesias Gonsálvez wrote:
> > The get_variable_being_redeclared() function can free 'var' because
> > a re-declaration of an unsized array variable can establish the
> > size, so
> > we set the array type to the 'earlier' declaration and free 'var'
> > as it is
> > not needed anymore.
> > 
> > However, the same 'var' is referenced later in
> > ast_declarator_list::hir().
> > 
> > This patch fixes it by assign the pointer 'var' to the pointer
> > 'earlier'.
> > 
> > This error was detected by Address Sanitizer.
> > 
> > v2:
> > 
> > * Pointer-to-pointer assignment (Bartosz Tomczyk)
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99677
> > Signed-off-by: Samuel Iglesias Gonsálvez 
> > ---
> > 
> > Another possibility is to use reference-to-pointer but it is a C++
> > thing. IIRC, we agreed on avoiding C++-specific features to make it
> > easy for C developers, but I have no strong opinion for either
> > option.
> > 
> >  src/compiler/glsl/ast_to_hir.cpp | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/compiler/glsl/ast_to_hir.cpp
> > b/src/compiler/glsl/ast_to_hir.cpp
> > index b31b61d1ed6..93ba1d510fa 100644
> > --- a/src/compiler/glsl/ast_to_hir.cpp
> > +++ b/src/compiler/glsl/ast_to_hir.cpp
> > @@ -3958,10 +3958,12 @@ apply_type_qualifier_to_variable(const
> > struct ast_type_qualifier *qual,
> >   * is a redeclaration, \c NULL otherwise.
> >   */
> >  static ir_variable *
> > -get_variable_being_redeclared(ir_variable *var, YYLTYPE loc,
> > +get_variable_being_redeclared(ir_variable **var_pointer, YYLTYPE
> > loc,
> >    struct _mesa_glsl_parse_state
> > *state,
> >    bool allow_all_redeclarations)
> >  {
> > +   ir_variable *var = *var_pointer;
> > +
> > /* Check if this declaration is actually a re-declaration,
> > either to
> >  * resize an array or add qualifiers to an existing variable.
> >  *
> > @@ -3999,7 +4001,7 @@ get_variable_being_redeclared(ir_variable
> > *var, YYLTYPE loc,
> >  
> >    earlier->type = var->type;
> >    delete var;
> > -  var = NULL;
> > +  *var_pointer = earlier;
> > } else if ((state->ARB_fragment_coord_conventions_enable ||
> >    state->is_version(150, 0))
> >    && strcmp(var->name, "gl_FragCoord") == 0
> > @@ -5207,7 +5209,7 @@ ast_declarator_list::hir(exec_list
> > *instructions,
> >    bool var_is_gl_id = is_gl_identifier(var->name);
> >  
> >    ir_variable *earlier =
> > - get_variable_being_redeclared(var, decl->get_location(),
> > state,
> > + get_variable_being_redeclared(, decl->get_location(), 
> > state,
> > false /*
> > allow_all_redeclarations */);
> >    if (earlier != NULL) {
> >   if (var_is_gl_id &&
> > @@ -7873,7 +7875,7 @@ 

[Mesa-dev] [Bug 99730] Metro Redux game(s) needs override for midshader extension declaration

[bugzilla-daemon]

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

--- Comment #2 from Grigori Goronzy  ---
> At least on Intel SKL with latest Mesa, something weird happens when 
> switching between gfx quality levels.  Trying e.g. to switch to "Very high" 
> level (by exiting the video options with ESC) freezes the game for few 
> minutes after which it back to viddeo options.

The game seems to recreate *all* shaders in this case. The game also starts a
prompt to ask the user to accept the new settings with a 30 second timeout and
if there's no input in the meantime, it will reset to the old settings.
However, due to the shader compiler hang, the prompt never actually displays.

This used to be a problem with radeonsi, but with the more recent optimizations
to shader compilation, it now typically takes less than 30 seconds to recover
from the hang, so it mostly works.

-- 
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 3/3] gallivm: Reenable PPC VSX (v3)

[Emil Velikov]

Hi Ben,

On 19 January 2017 at 01:44, Ben Crocker  wrote:
> Reenable the PPC64LE Vector-Scalar Extension for LLVM versions >= 3.8.1,
> now that LLVM bug 26775 and its corollary, 25503, are fixed.
>
> Amendment: remove extraneous spaces in macro def & invocations.
>
> We would prefer a runtime check, e.g. via an LLVMQueryString
> (analogous to glGetString, eglQueryString) or LLVMGetVersion API,
> but no such API exists at this time.
>
Please keep the mesa-stable line within the commit message. Similar to
how you'd do for kernel stable patches.

> Signed-off-by: Ben Crocker 
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp 
> b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> index cac81b9..ff6bbb9 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> @@ -50,6 +50,8 @@
>
>  #include 
>
> +#define LLVM_VERSION(MAJOR_MINOR, PATCH_LEVEL) ((MAJOR_MINOR << 8) + 
> PATCH_LEVEL)
> +
Afaict the following should also work, plus it's bit easier to read
and more consistent to what we have in mesa.

>  // Workaround http://llvm.org/PR23628
>  #if HAVE_LLVM >= 0x0307
>  #  pragma push_macro("DEBUG")
> @@ -614,7 +616,8 @@ 
> lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
>
>  #if defined(PIPE_ARCH_PPC)
> MAttrs.push_back(util_cpu_caps.has_altivec ? "+altivec" : "-altivec");
> -#if HAVE_LLVM >= 0x0304
> +#if (HAVE_LLVM >= 0x0304) && \
> +   (LLVM_VERSION(HAVE_LLVM, MESA_LLVM_VERSION_PATCH) <= LLVM_VERSION(0x0308, 
> 0x00))

#if HAVE_LLVM >= 0x0304
+#if HAVE_LLVM < 0x0307 || (HAVE_LLVM == 0x0308 && MESA_LLVM_VERSION_PATCH == 0)

> /*
>  * Make sure VSX instructions are disabled
>  * See LLVM bug https://llvm.org/bugs/show_bug.cgi?id=25503#c7
> @@ -622,6 +625,16 @@ 
> lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
> if (util_cpu_caps.has_altivec) {
>MAttrs.push_back("-vsx");
> }
> +#elif LLVM_VERSION(HAVE_LLVM, MESA_LLVM_VERSION_PATCH) > 
> LLVM_VERSION(0x0308, 0x00))
+#else

> +   /*
> +* However, bug 25503 is fixed, by the same fix that fixed
> +* bug 26775, in versions of LLVM later than 3.8 (starting with 3.8.1):
> +* Make sure VSX instructions are ENABLED
> +* See LLVM bug https://llvm.org/bugs/show_bug.cgi?id=26775
> +*/
> +   if (util_cpu_caps.has_altivec) {
> +  MAttrs.push_back("+vsx");
> +   }
+#endif

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

Re: [Mesa-dev] [PATCH 04/21] mesa: implement sparse buffer commitment

[Ian Romanick]

Patches 1, 2, and 4 are

Reviewed-by: Ian Romanick 

I sent some comments on patch 3, and I'll leave review of the Gallium
patches to people who actually know Gallium. :)

On 02/08/2017 01:42 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle 
> 
> ---
>  src/mesa/main/bufferobj.c | 66 
> +++
>  src/mesa/main/dd.h| 10 +++
>  2 files changed, 76 insertions(+)
> 
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> index 5f23868..14b4eef 100644
> --- a/src/mesa/main/bufferobj.c
> +++ b/src/mesa/main/bufferobj.c
> @@ -4057,14 +4057,80 @@ _mesa_InvalidateBufferData(GLuint buffer)
>ctx->Driver.InvalidateBufferSubData(ctx, bufObj, 0, bufObj->Size);
>  }
>  
> +static void
> +buffer_page_commitment(struct gl_context *ctx,
> +   struct gl_buffer_object *bufferObj,
> +   GLintptr offset, GLsizeiptr size,
> +   GLboolean commit, const char *func)
> +{
> +   if (!(bufferObj->StorageFlags & GL_SPARSE_STORAGE_BIT_ARB)) {
> +  _mesa_error(ctx, GL_INVALID_OPERATION, "%s(not a sparse buffer 
> object)",
> +  func);
> +  return;
> +   }
> +
> +   if (size < 0 || size > bufferObj->Size ||
> +   offset < 0 || offset > bufferObj->Size - size) {
> +  _mesa_error(ctx, GL_INVALID_VALUE, "%s(out of bounds)",
> +  func);
> +  return;
> +   }
> +
> +   /* The GL_ARB_sparse_buffer extension specification says:
> +*
> +* "INVALID_VALUE is generated by BufferPageCommitmentARB if  
> is
> +* not an integer multiple of SPARSE_BUFFER_PAGE_SIZE_ARB, or if 
> 
> +* is not an integer multiple of SPARSE_BUFFER_PAGE_SIZE_ARB and does
> +* not extend to the end of the buffer's data store."
> +*/
> +   if (offset % ctx->Const.SparseBufferPageSize != 0) {
> +  _mesa_error(ctx, GL_INVALID_VALUE, "%s(offset not aligned to page 
> size)",
> +  func);
> +  return;
> +   }
> +
> +   if (size % ctx->Const.SparseBufferPageSize != 0 &&
> +   offset + size != bufferObj->Size) {
> +  _mesa_error(ctx, GL_INVALID_VALUE, "%s(size not aligned to page size)",
> +  func);
> +  return;
> +   }
> +
> +   ctx->Driver.BufferPageCommitment(ctx, bufferObj, offset, size, commit);
> +}
> +
>  void GLAPIENTRY
>  _mesa_BufferPageCommitmentARB(GLenum target, GLintptr offset, GLsizeiptr 
> size,
>GLboolean commit)
>  {
> +   GET_CURRENT_CONTEXT(ctx);
> +   struct gl_buffer_object *bufferObj;
> +
> +   bufferObj = get_buffer(ctx, "glBufferPageCommitmentARB", target,
> +  GL_INVALID_ENUM);
> +   if (!bufferObj)
> +  return;
> +
> +   buffer_page_commitment(ctx, bufferObj, offset, size, commit,
> +  "glBufferPageCommitmentARB");
>  }
>  
>  void GLAPIENTRY
>  _mesa_NamedBufferPageCommitmentARB(GLuint buffer, GLintptr offset,
> GLsizeiptr size, GLboolean commit)
>  {
> +   GET_CURRENT_CONTEXT(ctx);
> +   struct gl_buffer_object *bufferObj;
> +
> +   bufferObj = _mesa_lookup_bufferobj(ctx, buffer);
> +   if (!bufferObj || bufferObj == ) {
> +  /* Note: the extension spec is not clear about the excpected error 
> value. */
> +  _mesa_error(ctx, GL_INVALID_VALUE,
> +  "glNamedBufferPageCommitmentARB(name = %u) invalid object",
> +  buffer);
> +  return;
> +   }
> +
> +   buffer_page_commitment(ctx, bufferObj, offset, size, commit,
> +  "glNamedBufferPageCommitmentARB");
>  }
> diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
> index 7ebd084..4fe9d5e 100644
> --- a/src/mesa/main/dd.h
> +++ b/src/mesa/main/dd.h
> @@ -984,6 +984,16 @@ struct dd_function_table {
>  */
> void (*QueryMemoryInfo)(struct gl_context *ctx,
> struct gl_memory_info *info);
> +
> +   /**
> +* \name GL_ARB_sparse_buffer interface
> +*/
> +   /*@{*/
> +   void (*BufferPageCommitment)(struct gl_context *ctx,
> +struct gl_buffer_object *bufferObj,
> +GLintptr offset, GLsizeiptr size,
> +GLboolean commit);
> +   /*@}*/
>  };
>  
>  
> 

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 2/3] gallivm: Override getHostCPUName() "generic" w/ "pwr8" (v3)

[Emil Velikov]

Hi Ben,

On 19 January 2017 at 01:43, Ben Crocker  wrote:
> If llvm::sys::getHostCPUName() returns "generic", override
> it with "pwr8" (on PPC64LE).
>
> This is a work-around for a bug in LLVM: a table entry for "POWER8NVL"
> is missing, resulting in (big-endian) "generic" being returned on
> little-endian Power8NVL systems.  The result is that code that
> attempts to load the least significant 32 bits of a 64-bit quantity in
> memory loads the wrong half.
>
> This omission should be fixed in the next version of LLVM (4.0),
> but this work-around should be left in place in case some
> future version of POWER also ends up unrepresented in LLVM's table.
>
Not sure how others feel, but imho you really want to have
this/similar comment in the code.

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

Re: [Mesa-dev] [PATCH] configure.ac: Drop LLVM compiler flags more radically

[Emil Velikov]

On 9 February 2017 at 08:07, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Drop all -m*, -W*, -O*, -g* and -f* flags, with the exception of
> -fno-rtti, which must be used if it's part of the llvm-config --cxxflags
> output. We don't want LLVM to dictate the flags we use, and it can even
> cause build failures, e.g. if LLVM and Mesa are built with different
> compilers.
>
Yes, please !
Reviewed-by: Emil Velikov 

Out of curiosity:
Are you speaking of personal experience ? What was stored in the
c/cpp/cxx flags that triggered build failure ?

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

[Mesa-dev] [PATCH 09/10] xlib: remove always true ifdef GLX_EXTENSION guards

[Emil Velikov]

From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 src/mesa/drivers/x11/fakeglx.c |  6 --
 src/mesa/drivers/x11/glxapi.c  | 20 
 2 files changed, 26 deletions(-)

diff --git a/src/mesa/drivers/x11/fakeglx.c b/src/mesa/drivers/x11/fakeglx.c
index 394800f02e..d2a099f9a2 100644
--- a/src/mesa/drivers/x11/fakeglx.c
+++ b/src/mesa/drivers/x11/fakeglx.c
@@ -1102,7 +1102,6 @@ choose_visual( Display *dpy, int screen, const int *list, 
GLboolean fbConfig )
 /* ignore */
 break;
 
-#ifdef GLX_EXT_texture_from_pixmap
  case GLX_BIND_TO_TEXTURE_RGB_EXT:
 parselist++; /*skip*/
 break;
@@ -1124,7 +1123,6 @@ choose_visual( Display *dpy, int screen, const int *list, 
GLboolean fbConfig )
  case GLX_Y_INVERTED_EXT:
 parselist++; /*skip*/
 break;
-#endif
 
 case None:
 /* end of list */
@@ -1730,7 +1728,6 @@ get_config( XMesaVisual xmvis, int attrib, int *value, 
GLboolean fbconfig )
  *value = xmvis->visinfo->visualid;
  break;
 
-#ifdef GLX_EXT_texture_from_pixmap
   case GLX_BIND_TO_TEXTURE_RGB_EXT:
  *value = True; /*XXX*/
  break;
@@ -1749,7 +1746,6 @@ get_config( XMesaVisual xmvis, int attrib, int *value, 
GLboolean fbconfig )
   case GLX_Y_INVERTED_EXT:
  *value = True; /*XXX*/
  break;
-#endif
 
   default:
 return GLX_BAD_ATTRIBUTE;
@@ -2227,7 +2223,6 @@ Fake_glXQueryDrawable( Display *dpy, GLXDrawable draw, 
int attribute,
   case GLX_FBCONFIG_ID:
  *value = xmbuf->xm_visual->visinfo->visualid;
  return;
-#ifdef GLX_EXT_texture_from_pixmap
   case GLX_TEXTURE_FORMAT_EXT:
  *value = xmbuf->TextureFormat;
  break;
@@ -2237,7 +2232,6 @@ Fake_glXQueryDrawable( Display *dpy, GLXDrawable draw, 
int attribute,
   case GLX_MIPMAP_TEXTURE_EXT:
  *value = xmbuf->TextureMipmap;
  break;
-#endif
 
   default:
  return; /* raise BadValue error */
diff --git a/src/mesa/drivers/x11/glxapi.c b/src/mesa/drivers/x11/glxapi.c
index 07c1d84283..a807074a86 100644
--- a/src/mesa/drivers/x11/glxapi.c
+++ b/src/mesa/drivers/x11/glxapi.c
@@ -1105,36 +1105,16 @@ const char **
 _glxapi_get_extensions(void)
 {
static const char *extensions[] = {
-#ifdef GLX_EXT_import_context
   "GLX_EXT_import_context",
-#endif
-#ifdef GLX_SGI_video_sync
   "GLX_SGI_video_sync",
-#endif
-#ifdef GLX_MESA_copy_sub_buffer
   "GLX_MESA_copy_sub_buffer",
-#endif
-#ifdef GLX_MESA_release_buffers
   "GLX_MESA_release_buffers",
-#endif
-#ifdef GLX_MESA_pixmap_colormap
   "GLX_MESA_pixmap_colormap",
-#endif
-#ifdef GLX_MESA_set_3dfx_mode
   "GLX_MESA_set_3dfx_mode",
-#endif
-#ifdef GLX_SGIX_fbconfig
   "GLX_SGIX_fbconfig",
-#endif
-#ifdef GLX_SGIX_pbuffer
   "GLX_SGIX_pbuffer",
-#endif
-#ifdef GLX_EXT_texture_from_pixmap
   "GLX_EXT_texture_from_pixmap",
-#endif
-#ifdef GLX_INTEL_swap_event
   "GLX_INTEL_swap_event",
-#endif
   NULL
};
return extensions;
-- 
2.11.0

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

[Mesa-dev] [PATCH 10/10] st/xlib: remove always true ifdef GLX_EXTENSION guards

[Emil Velikov]

From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 src/gallium/state_trackers/glx/xlib/glx_api.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c 
b/src/gallium/state_trackers/glx/xlib/glx_api.c
index 1c541b76db..642ece7b0f 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_api.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_api.c
@@ -956,7 +956,6 @@ choose_visual( Display *dpy, int screen, const int *list, 
GLboolean fbConfig )
 parselist += 2; /* ignore the parameter */
 break;
 
-#ifdef GLX_EXT_texture_from_pixmap
  case GLX_BIND_TO_TEXTURE_RGB_EXT:
 parselist++; /*skip*/
 break;
@@ -978,7 +977,6 @@ choose_visual( Display *dpy, int screen, const int *list, 
GLboolean fbConfig )
  case GLX_Y_INVERTED_EXT:
 parselist++; /*skip*/
 break;
-#endif
 
 case None:
 /* end of list */
@@ -1664,7 +1662,6 @@ get_config( XMesaVisual xmvis, int attrib, int *value, 
GLboolean fbconfig )
  *value = xmvis->visinfo->visualid;
  break;
 
-#ifdef GLX_EXT_texture_from_pixmap
   case GLX_BIND_TO_TEXTURE_RGB_EXT:
  *value = True; /*XXX*/
  break;
@@ -1683,7 +1680,6 @@ get_config( XMesaVisual xmvis, int attrib, int *value, 
GLboolean fbconfig )
   case GLX_Y_INVERTED_EXT:
  *value = True; /*XXX*/
  break;
-#endif
 
   default:
 return GLX_BAD_ATTRIBUTE;
@@ -2163,7 +2159,6 @@ glXQueryDrawable(Display *dpy, GLXDrawable draw, int 
attribute,
   case GLX_FBCONFIG_ID:
  *value = xmbuf->xm_visual->visinfo->visualid;
  return;
-#ifdef GLX_EXT_texture_from_pixmap
   case GLX_TEXTURE_FORMAT_EXT:
  *value = xmbuf->TextureFormat;
  break;
@@ -2173,7 +2168,6 @@ glXQueryDrawable(Display *dpy, GLXDrawable draw, int 
attribute,
   case GLX_MIPMAP_TEXTURE_EXT:
  *value = xmbuf->TextureMipmap;
  break;
-#endif
 
   default:
  generate_error(dpy, BadValue, 0, X_GLXCreateContextAttribsARB, true);
-- 
2.11.0

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