[Mesa-dev] [PATCH] radv: revert "only enable used channels when exporting parameters"

[Dave Airlie]

From: Dave Airlie 

This pretty much reverts:

f3275ca01cddd5d1e999e3805eff42e06ce6e974
Author: Samuel Pitoiset 
Date:   Thu Mar 1 11:54:22 2018 +0100

ac/nir: only enable used channels when exporting parameters

To fix a regression in:
dEQP-VK.spirv_assembly.instruction.graphics.variable_init.output.struct

The problem is the scanning in the info pass isn't handling
structs at all.
---
 src/amd/vulkan/radv_nir_to_llvm.c | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index 7379f348d84..63dd8efb3a7 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -2327,21 +2327,7 @@ handle_vs_outputs_post(struct radv_shader_context *ctx,
for (unsigned j = 0; j < 4; j++)
values[j] = ac_to_float(>ac, radv_load_output(ctx, 
i, j));
 
-   unsigned output_usage_mask;
-
-   if (ctx->stage == MESA_SHADER_VERTEX &&
-   !ctx->is_gs_copy_shader) {
-   output_usage_mask =
-   ctx->shader_info->info.vs.output_usage_mask[i];
-   } else if (ctx->stage == MESA_SHADER_TESS_EVAL) {
-   output_usage_mask =
-   ctx->shader_info->info.tes.output_usage_mask[i];
-   } else {
-   /* Enable all channels for the GS copy shader because
-* we don't know the output usage mask currently.
-*/
-   output_usage_mask = 0xf;
-   }
+   unsigned output_usage_mask = 0xf;
 
radv_export_param(ctx, param_count, values, output_usage_mask);
 
-- 
2.14.3

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

[Mesa-dev] [PATCH] radv: lower constant initializers on output variables earlier

[Dave Airlie]

From: Dave Airlie 

If a shader only writes to an output via a constant initializer we
need to lower it before we call nir_remove_dead_variables so that
this pass sees the stores from the initializer and doesn't kill the
output.

Fixes test failures in new work-in-progress CTS tests:
dEQP-VK.spirv_assembly.instruction.graphics.variable_init.output.float

This is ported from anv:
99b57daf4a anv/pipeline: lower constant initializers on output variables earlier
from Iago Toral Quiroga 
---
 src/amd/vulkan/radv_shader.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 180b427a442..ac577c36e9f 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -244,6 +244,11 @@ radv_shader_compile_to_nir(struct radv_device *device,
assert(exec_list_length(>functions) == 1);
entry_point->name = ralloc_strdup(entry_point, "main");
 
+   /* Make sure we lower constant initializers on output variables 
so that
+* nir_remove_dead_variables below sees the corresponding stores
+*/
+   NIR_PASS_V(nir, nir_lower_constant_initializers, 
nir_var_shader_out);
+
NIR_PASS_V(nir, nir_remove_dead_variables,
   nir_var_shader_in | nir_var_shader_out | 
nir_var_system_value);
 
-- 
2.14.3

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

[Mesa-dev] [PATCH] radv/multiview: mark layer_input if we have input attachments.

[Dave Airlie]

From: Dave Airlie 

This fixes:
dEQP-VK.multiview.input_attachments*
---
 src/amd/vulkan/radv_shader_info.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_shader_info.c 
b/src/amd/vulkan/radv_shader_info.c
index 7208bd2f587..9c18791524d 100644
--- a/src/amd/vulkan/radv_shader_info.c
+++ b/src/amd/vulkan/radv_shader_info.c
@@ -122,8 +122,10 @@ gather_intrinsic_info(const nir_shader *nir, const 
nir_intrinsic_instr *instr,
 
enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
if (dim == GLSL_SAMPLER_DIM_SUBPASS ||
-   dim == GLSL_SAMPLER_DIM_SUBPASS_MS)
+   dim == GLSL_SAMPLER_DIM_SUBPASS_MS) {
+   info->ps.layer_input = true;
info->ps.uses_input_attachments = true;
+   }
mark_sampler_desc(instr->variables[0]->var, info);
 
if (nir_intrinsic_image_store ||
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH 1/2] st/glsl_to_nir: gather next_stage in shader_info

[Timothy Arceri]

On 28/02/18 03:45, Marek Olšák wrote:

On Mon, Feb 26, 2018 at 10:43 AM, Timothy Arceri  wrote:

---
  src/compiler/shader_info.h|  5 +
  src/mesa/state_tracker/st_glsl_to_nir.cpp | 13 +
  2 files changed, 18 insertions(+)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index e7fd7dbe62..11a59ff6ac 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -54,6 +54,11 @@ typedef struct shader_info {
 /** The shader stage, such as MESA_SHADER_VERTEX. */
 gl_shader_stage stage;

+   /** The shader stage in a non SSO linked program that follows this stage,
+ * such as MESA_SHADER_FRAGMENT.
+ */
+   gl_shader_stage next_stage;
+
 /* Number of textures used by this shader */
 unsigned num_textures;
 /* Number of uniform buffers used by this shader */
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 765c827d93..914fd2e898 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -317,6 +317,19 @@ st_glsl_to_nir(struct st_context *st, struct gl_program 
*prog,

 nir_shader *nir = glsl_to_nir(shader_program, stage, options);

+   /* Set the next shader stage hint for VS and TES. */
+   if (!nir->info.separate_shader &&
+   (nir->info.stage == MESA_SHADER_VERTEX ||
+nir->info.stage == MESA_SHADER_TESS_EVAL)) {
+
+  unsigned prev_stages = (1 << (prog->info.stage + 1)) - 1;
+  unsigned stages_mask =
+ ~prev_stages & shader_program->data->linked_stages;
+
+  nir->info.next_stage = stages_mask ?
+ (gl_shader_stage) u_bit_scan(_mask) : MESA_SHADER_FRAGMENT;


ffs would be better.

Also, ureg sets ..._SHADER_FRAGMENT if st/mesa doesn't set anything
(e.g. it's a separate shader).


Yes the ureg function does that, which is what the "stages_mask ?" above 
 does too. However separate shaders don't get set because 
ureg_set_next_shader_processor() won't get called for them.


   /* Set the next shader stage hint for VS and TES. */
   switch (procType) {
   case PIPE_SHADER_VERTEX:
   case PIPE_SHADER_TESS_EVAL:
  if (program->shader_program->SeparateShader)
 break;

  for (i = program->shader->Stage+1; i <= MESA_SHADER_FRAGMENT; i++) {
 if (program->shader_program->_LinkedShaders[i]) {
ureg_set_next_shader_processor(
  ureg, pipe_shader_type_from_mesa((gl_shader_stage)i));
break;
 }
  }
  break;
   }





Marek


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

Re: [Mesa-dev] [PATCH 0/2] nir_instr_worklist for nir_opt_dce V2

[Dieter Nützel]

For the series

Tested-by: Dieter Nützel 

running on RX580.

Dieter

Am 18.03.2018 00:09, schrieb Thomas Helland:

This is take two on reducing ralloc overhead in nir_opt_dce.
I've ditched the previous solution with a freelist, and instead
gone for a wrapper on u_vector. That should remove the need for a
freelist alltogether, and at the same time lower our memory usage.

CC: Eric Anholt 

Thomas Helland (2):
  nir: Initial implementation of a nir_instr_worklist
  nir: Migrate nir_dce to instr worklist

 src/compiler/nir/nir_opt_dce.c  | 53 +++
 src/compiler/nir/nir_worklist.h | 70 
+

 2 files changed, 88 insertions(+), 35 deletions(-)

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

Re: [Mesa-dev] Patchwork has 'Server Error (500)'

[Dieter Nützel]

Works as before.

Thanks Daniel!

Dieter

Am 18.03.2018 16:47, schrieb Daniel Stone:

Hi Dieter,

On 18 March 2018 at 00:48, Dieter Nützel  wrote:

@ least, here fromm Germany.

https://patchwork.freedesktop.org/
Server Error (500)


This is fixed now, and I think that particular problem shouldn't happen 
again.


Cheers,
Daniel

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

[Mesa-dev] [PATCH 3/3] radv/query: handle multiview timestamp queries.

[Dave Airlie]

From: Dave Airlie 

For each view bit we need to emit a timestamp query.

Fixes: dEQP-VK.multiview.queries*
---
 src/amd/vulkan/radv_query.c | 79 -
 1 file changed, 43 insertions(+), 36 deletions(-)

diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 7a20314f618..cc943d5de07 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1233,42 +1233,49 @@ void radv_CmdWriteTimestamp(
 
radv_cs_add_buffer(cmd_buffer->device->ws, cs, pool->bo, 5);
 
-   MAYBE_UNUSED unsigned cdw_max = 
radeon_check_space(cmd_buffer->device->ws, cs, 28);
-
-   switch(pipelineStage) {
-   case VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT:
-   radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
-   radeon_emit(cs, COPY_DATA_COUNT_SEL | COPY_DATA_WR_CONFIRM |
-   COPY_DATA_SRC_SEL(COPY_DATA_TIMESTAMP) |
-   COPY_DATA_DST_SEL(V_370_MEM_ASYNC));
-   radeon_emit(cs, 0);
-   radeon_emit(cs, 0);
-   radeon_emit(cs, query_va);
-   radeon_emit(cs, query_va >> 32);
-
-   radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 3, 0));
-   radeon_emit(cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
-   S_370_WR_CONFIRM(1) |
-   S_370_ENGINE_SEL(V_370_ME));
-   radeon_emit(cs, avail_va);
-   radeon_emit(cs, avail_va >> 32);
-   radeon_emit(cs, 1);
-   break;
-   default:
-   si_cs_emit_write_event_eop(cs,
-  false,
-  
cmd_buffer->device->physical_device->rad_info.chip_class,
-  mec,
-  V_028A90_BOTTOM_OF_PIPE_TS, 0,
-  3, query_va, 0, 0);
-   si_cs_emit_write_event_eop(cs,
-  false,
-  
cmd_buffer->device->physical_device->rad_info.chip_class,
-  mec,
-  V_028A90_BOTTOM_OF_PIPE_TS, 0,
-  1, avail_va, 0, 1);
-   break;
-   }
+   int num_queries = 1;
+   if (cmd_buffer->state.subpass && cmd_buffer->state.subpass->view_mask)
+   num_queries = 
util_bitcount(cmd_buffer->state.subpass->view_mask);
 
+   MAYBE_UNUSED unsigned cdw_max = 
radeon_check_space(cmd_buffer->device->ws, cs, 28 * num_queries);
+
+   for (unsigned i = 0; i < num_queries; i++) {
+   switch(pipelineStage) {
+   case VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT:
+   radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
+   radeon_emit(cs, COPY_DATA_COUNT_SEL | 
COPY_DATA_WR_CONFIRM |
+   COPY_DATA_SRC_SEL(COPY_DATA_TIMESTAMP) |
+   COPY_DATA_DST_SEL(V_370_MEM_ASYNC));
+   radeon_emit(cs, 0);
+   radeon_emit(cs, 0);
+   radeon_emit(cs, query_va);
+   radeon_emit(cs, query_va >> 32);
+
+   radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 3, 0));
+   radeon_emit(cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
+   S_370_WR_CONFIRM(1) |
+   S_370_ENGINE_SEL(V_370_ME));
+   radeon_emit(cs, avail_va);
+   radeon_emit(cs, avail_va >> 32);
+   radeon_emit(cs, 1);
+   break;
+   default:
+   si_cs_emit_write_event_eop(cs,
+  false,
+  
cmd_buffer->device->physical_device->rad_info.chip_class,
+  mec,
+  V_028A90_BOTTOM_OF_PIPE_TS, 
0,
+  3, query_va, 0, 0);
+   si_cs_emit_write_event_eop(cs,
+  false,
+  
cmd_buffer->device->physical_device->rad_info.chip_class,
+  mec,
+  V_028A90_BOTTOM_OF_PIPE_TS, 
0,
+  1, avail_va, 0, 1);
+   break;
+   }
+   query_va += pool->stride;
+   avail_va += 4;
+   }
assert(cmd_buffer->cs->cdw <= cdw_max);
 }
-- 
2.14.3

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

[Mesa-dev] [PATCH 2/3] radv/query: handle multiview queries properly. (v3)

[Dave Airlie]

From: Dave Airlie 

For multiview we need to emit a number of sequential queries
depending on the view mask.

This avoids dEQP-VK.multiview.queries.15 waiting forever
on the CPU for query results that are never coming.

We only really want to emit one query,
and the rest should be blank (amdvlk does the same),
so we emit begin/end pairs for all the others except
the first query.

v2: fix tests
v3: split out patch.

Fixes: dEQP-VK.multiview.queries*
---
 src/amd/vulkan/radv_query.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 5fae8b65658..7a20314f618 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1178,6 +1178,25 @@ void radv_CmdBeginQuery(
va += pool->stride * query;
 
emit_begin_query(cmd_buffer, va, pool->type);
+
+   /*
+* For multiview we have to emit a query for each bit in the mask,
+* however the first query we emit will get the totals for all the
+* operations, so we don't want to get a real value in the other
+* queries. This emits a fake begin/end sequence so the waiting
+* code gets a completed query value and doesn't hang, but the
+* query returns 0.
+*/
+   if (cmd_buffer->state.subpass && cmd_buffer->state.subpass->view_mask) {
+   uint64_t avail_va = va + pool->availability_offset + 4 * query;
+
+   for (unsigned i = 0; i < 
util_bitcount(cmd_buffer->state.subpass->view_mask); i++) {
+   va += pool->stride;
+   avail_va += 4;
+   emit_begin_query(cmd_buffer, va, pool->type);
+   emit_end_query(cmd_buffer, va, avail_va, pool->type);
+   }
+   }
 }
 
 
-- 
2.14.3

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

[Mesa-dev] [PATCH 1/3] radv/query: split out begin/end query emission

[Dave Airlie]

From: Dave Airlie 

This just splits out the begin/end query hw emissions,
it makes it easier to add multiview support for queries.
---
 src/amd/vulkan/radv_query.c | 98 ++---
 1 file changed, 57 insertions(+), 41 deletions(-)

diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 9fee4d2b491..5fae8b65658 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1077,33 +1077,12 @@ void radv_CmdResetQueryPool(
}
 }
 
-void radv_CmdBeginQuery(
-VkCommandBuffer commandBuffer,
-VkQueryPool queryPool,
-uint32_tquery,
-VkQueryControlFlags flags)
+static void emit_begin_query(struct radv_cmd_buffer *cmd_buffer,
+uint64_t va,
+VkQueryType query_type)
 {
-   RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
-   RADV_FROM_HANDLE(radv_query_pool, pool, queryPool);
struct radeon_winsys_cs *cs = cmd_buffer->cs;
-   uint64_t va = radv_buffer_get_va(pool->bo);
-   va += pool->stride * query;
-
-   radv_cs_add_buffer(cmd_buffer->device->ws, cs, pool->bo, 8);
-
-   if (cmd_buffer->pending_reset_query) {
-   if (pool->size >= RADV_BUFFER_OPS_CS_THRESHOLD) {
-   /* Only need to flush caches if the query pool size is
-* large enough to be resetted using the compute shader
-* path. Small pools don't need any cache flushes
-* because we use a CP dma clear.
-*/
-   si_emit_cache_flush(cmd_buffer);
-   cmd_buffer->pending_reset_query = false;
-   }
-   }
-
-   switch (pool->type) {
+   switch (query_type) {
case VK_QUERY_TYPE_OCCLUSION:
radeon_check_space(cmd_buffer->device->ws, cs, 7);
 
@@ -1127,26 +1106,15 @@ void radv_CmdBeginQuery(
default:
unreachable("beginning unhandled query type");
}
-}
 
+}
 
-void radv_CmdEndQuery(
-VkCommandBuffer commandBuffer,
-VkQueryPool queryPool,
-uint32_tquery)
+static void emit_end_query(struct radv_cmd_buffer *cmd_buffer,
+  uint64_t va, uint64_t avail_va,
+  VkQueryType query_type)
 {
-   RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
-   RADV_FROM_HANDLE(radv_query_pool, pool, queryPool);
struct radeon_winsys_cs *cs = cmd_buffer->cs;
-   uint64_t va = radv_buffer_get_va(pool->bo);
-   uint64_t avail_va = va + pool->availability_offset + 4 * query;
-   va += pool->stride * query;
-
-   /* Do not need to add the pool BO to the list because the query must
-* currently be active, which means the BO is already in the list.
-*/
-
-   switch (pool->type) {
+   switch (query_type) {
case VK_QUERY_TYPE_OCCLUSION:
radeon_check_space(cmd_buffer->device->ws, cs, 14);
 
@@ -1182,6 +1150,54 @@ void radv_CmdEndQuery(
}
 }
 
+void radv_CmdBeginQuery(
+VkCommandBuffer commandBuffer,
+VkQueryPool queryPool,
+uint32_tquery,
+VkQueryControlFlags flags)
+{
+   RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
+   RADV_FROM_HANDLE(radv_query_pool, pool, queryPool);
+   struct radeon_winsys_cs *cs = cmd_buffer->cs;
+   uint64_t va = radv_buffer_get_va(pool->bo);
+
+   radv_cs_add_buffer(cmd_buffer->device->ws, cs, pool->bo, 8);
+
+   if (cmd_buffer->pending_reset_query) {
+   if (pool->size >= RADV_BUFFER_OPS_CS_THRESHOLD) {
+   /* Only need to flush caches if the query pool size is
+* large enough to be resetted using the compute shader
+* path. Small pools don't need any cache flushes
+* because we use a CP dma clear.
+*/
+   si_emit_cache_flush(cmd_buffer);
+   cmd_buffer->pending_reset_query = false;
+   }
+   }
+
+   va += pool->stride * query;
+
+   emit_begin_query(cmd_buffer, va, pool->type);
+}
+
+
+void radv_CmdEndQuery(
+VkCommandBuffer commandBuffer,
+VkQueryPool queryPool,
+uint32_tquery)
+{
+   RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
+   RADV_FROM_HANDLE(radv_query_pool, pool, queryPool);
+   uint64_t va = radv_buffer_get_va(pool->bo);
+   uint64_t avail_va 

Re: [Mesa-dev] [PATCH v2] egl/android: Implement the eglSwapinterval for Android.

[Wu, Zhongmin]

Hi Emil:
Thanks very much.
Yes, the previous patches (V1) is superseded now.

-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com] 
Sent: Friday, March 16, 2018 22:14 
To: Wu, Zhongmin 
Cc: Tomasz Figa ; ML mesa-dev 
; Rob Herring ; Liu, Zhiquan 
; Long, Zhifang ; Kondapally, 
Kalyan ; Palli, Tapani ; 
Xu, Randy ; Eric Engestrom ; Bhardwaj, 
MunishX ; Kps, Harish Krupo 
; Chad Versace 
Subject: Re: [PATCH v2] egl/android: Implement the eglSwapinterval for Android.

On 16 March 2018 at 08:51, Wu, Zhongmin  wrote:
> Thanks very much Tomasz.
>
> So, who can help to commit such patch.
>
Fixed with s/dpy/disp/ (otherwise it won't even build) and pushed.

Please go through the patches list and update it.
I believe that all of those are superseded, do check them over.

https://patchwork.freedesktop.org/project/mesa/patches/?submitter=17018

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

[Mesa-dev] [PATCH 5/5] mesa: adds some comments regarding MESA_GLES_VERSION_OVERRIDE usage

[Andres Gomez]

Fixes: 03fd6704db9 ("mesa: Add support for a new override string
MESA_GLES_VERSION_OVERRIDE")

Cc: Jordan Justen 
Cc: Ian Romanick 
Signed-off-by: Andres Gomez 
Reviewed-by: Emil Velikov 
---
 src/mesa/main/version.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index ac8dd9b9e43..1d4e8846209 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -134,8 +134,8 @@ create_version_string(struct gl_context *ctx, const char 
*prefix)
 }
 
 /**
- * Override the context's version and/or API type if the
- * environment variable MESA_GL_VERSION_OVERRIDE is set.
+ * Override the context's version and/or API type if the environment variables
+ * MESA_GL_VERSION_OVERRIDE or MESA_GLES_VERSION_OVERRIDE are set.
  *
  * Example uses of MESA_GL_VERSION_OVERRIDE:
  *
@@ -148,6 +148,12 @@ create_version_string(struct gl_context *ctx, const char 
*prefix)
  * X.Y: override GL version to X.Y without changing the profile.
  * X.YFC: select a Core+Forward Compatible profile with GL version X.Y.
  * X.YCOMPAT: select a Compatibility profile with GL version X.Y.
+ *
+ * Example uses of MESA_GLES_VERSION_OVERRIDE:
+ *
+ * 2.0: select GLES version 2.0.
+ * 3.0: select GLES version 3.0.
+ * 3.1: select GLES version 3.1.
  */
 bool
 _mesa_override_gl_version_contextless(struct gl_constants *consts,
-- 
2.16.1

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

[Mesa-dev] [PATCH 4/5] mesa: adjust incorrect comment in texture_buffer_range

[Andres Gomez]

From: Marek Olšák 

---
 src/mesa/main/teximage.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 928e50d472d..c3f769d58ce 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -5458,8 +5458,8 @@ texture_buffer_range(struct gl_context *ctx,
GLsizeiptr oldSize = texObj->BufferSize;
mesa_format format;
 
-   /* NOTE: ARB_texture_buffer_object has interactions with
-* the compatibility profile that are not implemented.
+   /* NOTE: ARB_texture_buffer_object might not be supported in
+* the compatibility profile.
 */
if (!_mesa_has_ARB_texture_buffer_object(ctx) &&
!_mesa_has_OES_texture_buffer(ctx)) {
-- 
2.16.1

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

[Mesa-dev] [PATCH v2 3/5] mesa: simplify MESA_GL_VERSION_OVERRIDE behavior of API override

[Andres Gomez]

From: Marek Olšák 

v2:
 - Provide a correct explanation on the envvars documentation (Ian).
 - Provide a more correct explanation on the function comments (Andres).

Fixes: 2599b92eb97 ("mesa: allow forcing >=3.1 compatibility contexts
with MESA_GL_VERSION_OVERRIDE")

Cc: Jordan Justen 
Cc: Ian Romanick 
Cc: Eric Engestrom 
Cc: Emil Velikov 
Signed-off-by: Andres Gomez 
---
 docs/envvars.html   | 25 ++---
 src/mesa/main/version.c | 23 +++
 2 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/docs/envvars.html b/docs/envvars.html
index ea42a50779b..7ec91a1fd91 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -88,19 +88,30 @@ This is a work-around for that.
 MESA_GL_VERSION_OVERRIDE - changes the value returned by
 glGetString(GL_VERSION) and possibly the GL API type.
 
- The format should be MAJOR.MINOR[FC]
+ The format should be MAJOR.MINOR[FC|COMPAT]
  FC is an optional suffix that indicates a forward compatible context.
 This is only valid for versions = 3.0.
- GL versions  3.0 are set to a compatibility (non-Core) profile
- GL versions = 3.0, see below
- GL versions  3.0 are set to a Core profile
- Examples: 2.1, 3.0, 3.0FC, 3.1, 3.1FC
+ COMPAT is an optional suffix that indicates a compatibility
+context or GL_ARB_compatibility support. This is only valid for
+versions = 3.1.
+ GL versions = 3.0 are set to a compatibility (non-Core) profile
+ GL versions = 3.1, depending on the driver, it may or may not
+have the ARB_compatibility extension enabled.
+ GL versions = 3.2 are set to a Core profile
+ Examples: 2.1, 3.0, 3.0FC, 3.1, 3.1FC, 3.1COMPAT, 3.2, 3.2FC, 3.2COMPAT
 
  2.1 - select a compatibility (non-Core) profile with GL version 2.1
  3.0 - select a compatibility (non-Core) profile with GL version 3.0
  3.0FC - select a Core+Forward Compatible profile with GL version 3.0
- 3.1 - select a Core profile with GL version 3.1
- 3.1FC - select a Core+Forward Compatible profile with GL version 3.1
+ 3.1 - select OpenGL 3.1. GL_ARB_compatibility will be enabled per
+the driver default.
+ 3.1FC - select OpenGL 3.1 with forward compatibility
+enabled. GL_ARB_compatibilty will not be enabled.
+ 3.1COMPAT - select OpenGL 3.1 with GL_ARB_compatibilty forced
+enabled.
+ 3.2 - select a Core profile with GL version 3.2
+ 3.2FC - select a Core+Forward Compatible profile with GL version 3.2
+ 3.2COMPAT - select a compatibility (non-Core) profile with GL version 3.2
 
  Mesa may not really implement all the features of the given version.
 (for developers only)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index a28069054d3..ac8dd9b9e43 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -139,11 +139,15 @@ create_version_string(struct gl_context *ctx, const char 
*prefix)
  *
  * Example uses of MESA_GL_VERSION_OVERRIDE:
  *
- * 2.1: select a compatibility (non-Core) profile with GL version 2.1
- * 3.0: select a compatibility (non-Core) profile with GL version 3.0
- * 3.0FC: select a Core+Forward Compatible profile with GL version 3.0
- * 3.1: select a Core profile with GL version 3.1
- * 3.1FC: select a Core+Forward Compatible profile with GL version 3.1
+ * 2.1: select a compatibility (non-Core) profile with GL version 2.1.
+ * 3.0: select a compatibility (non-Core) profile with GL version 3.0.
+ * 3.0FC: select a Core+Forward Compatible profile with GL version 3.0.
+ * 3.1: select GL version 3.1 with GL_ARB_compatibility enabled per the driver 
default.
+ * 3.1FC: select GL version 3.1 with forward compatibility and 
GL_ARB_compatibility disabled.
+ * 3.1COMPAT: select GL version 3.1 with GL_ARB_compatibilty enabled.
+ * X.Y: override GL version to X.Y without changing the profile.
+ * X.YFC: select a Core+Forward Compatible profile with GL version X.Y.
+ * X.YCOMPAT: select a Compatibility profile with GL version X.Y.
  */
 bool
 _mesa_override_gl_version_contextless(struct gl_constants *consts,
@@ -157,17 +161,12 @@ _mesa_override_gl_version_contextless(struct gl_constants 
*consts,
if (version > 0) {
   *versionOut = version;
 
-  /* If the API is a desktop API, adjust the context flags.  We may also
-   * need to modify the API depending on the version.  For example, Mesa
-   * does not support a GL 3.3 compatibility profile.
-   */
+  /* Modify the API and context flags as needed. */
   if (*apiOut == API_OPENGL_CORE || *apiOut == API_OPENGL_COMPAT) {
  if (version >= 30 && fwd_context) {
 *apiOut = API_OPENGL_CORE;
 consts->ContextFlags |= GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT;
- } else if (version >= 31 && !compat_context) {
-*apiOut = API_OPENGL_CORE;
- } else {
+ } else if (compat_context) {
 *apiOut = API_OPENGL_COMPAT;
  }
   }
-- 

[Mesa-dev] [PATCH v2 2/5] dri_util: don't fail when not supporting ARB_compatibility with GL3.1

[Andres Gomez]

Currently, any driver that does not support the ARB_compatibility
extension will fail on GL3.1 context creation if the application does
not request the forward-compatiblity flag.

Restore the original check which changes mesa_api to API_OPENGL_CORE,
only when:
 - GL3.1 is requested, without the forward-compatiblity flag.
 - driver does not support ARB_compatibility - as deduced by
max_gl_compat_version.

Fixes: a0c8b49284e ("mesa: enable OpenGL 3.1 with ARB_compatibility")

v2:
 - Improve commit log (Emil).
 - Provide a correct explanation on the features documentation (Ian).

Cc: Marek Olšák 
Cc: Ian Romanick 
Cc: Kenneth Graunke 
Cc: Eric Engestrom 
Cc: Emil Velikov 
Signed-off-by: Andres Gomez 
Reviewed-by: Emil Velikov 
---
 docs/features.txt  | 11 +++
 src/mesa/drivers/dri/common/dri_util.c | 10 ++
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index 5eae34bf0df..a089d923ad7 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -24,10 +24,13 @@ not started
 
 # OpenGL Core and Compatibility context support
 
-Some drivers do not support the Compatibility profile or ARB_compatibility.
-Such drivers are limited to OpenGL 3.0 if the Core profile is not requested
-by applications. Some of the later GL features are exposed in the 3.0 context
-as extensions.
+Some drivers do not support the Compatibility profile or the
+ARB_compatibility extensions.  If an application does not request a
+specific version without the forward-compatiblity flag, such drivers
+will be limited to OpenGL 3.0.  If an application requests OpenGL 3.1,
+it will get a context that may or may not have the ARB_compatibility
+extension enabled.  Some of the later GL features are exposed in the 3.0
+context as extensions.
 
 
 Feature Status
diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c
index 3f780d155b8..0b94d19fa5d 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -379,6 +379,16 @@ driCreateContextAttribs(__DRIscreen *screen, int api,
}
 }
 
+/* The specific Mesa driver may not support the GL_ARB_compatibilty
+ * extension or the compatibility profile.  In that case, we treat an
+ * API_OPENGL_COMPAT 3.1 as API_OPENGL_CORE. We reject API_OPENGL_COMPAT
+ * 3.2+ in any case.
+ */
+if (mesa_api == API_OPENGL_COMPAT &&
+ctx_config.major_version == 3 && ctx_config.minor_version == 1 &&
+screen->max_gl_compat_version < 31)
+   mesa_api = API_OPENGL_CORE;
+
 if (mesa_api == API_OPENGL_COMPAT
 && ((ctx_config.major_version > 3)
 || (ctx_config.major_version == 3 &&
-- 
2.16.1

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

[Mesa-dev] [PATCH 1/5] dri_util: when overriding, always reset the core version

[Andres Gomez]

This way we won't fail when validating just because we may have a non
overriden core version that is lower than the requested one, even when
the compat version is high enough.

For example, running glcts from VK-GL-CTS with i965, this will
succeed:

$ MESA_GL_VERSION_OVERRIDE=4.6 ./glcts --deqp-case=KHR-GL46.info.vendor

While, this will fail:

$ MESA_GL_VERSION_OVERRIDE=4.6COMPAT ./glcts --deqp-case=KHR-GL46.info.vendor

Fixes: 464c56d3d5c ("dri_util: Use
_mesa_override_gl_version_contextless")

Cc: Ian Romanick 
Cc: Tapani Pälli 
Cc: Marek Olšák 
Signed-off-by: Andres Gomez 
Reviewed-by: Emil Velikov 
Reviewed-by: Tapani Pälli 
---
 src/mesa/drivers/dri/common/dri_util.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c
index a34f38d6114..3f780d155b8 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -164,11 +164,9 @@ driCreateNewScreen2(int scrn, int fd,
 
 api = API_OPENGL_COMPAT;
 if (_mesa_override_gl_version_contextless(, , )) {
-   if (api == API_OPENGL_CORE) {
-  psp->max_gl_core_version = version;
-   } else {
+   psp->max_gl_core_version = version;
+   if (api == API_OPENGL_COMPAT)
   psp->max_gl_compat_version = version;
-   }
 }
 
 psp->api_mask = 0;
-- 
2.16.1

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

[Mesa-dev] [PATCH v2 0/5] update MESA_GL_VERSION_OVERRIDE usage and documentation

[Andres Gomez]

A second take on this small series.

With permission of Marek, I've included and done a new revision of his
patch to simplify MESA_GL_VERSION_OVERRIDE.

Additionslly, this series includes a correction for the drivers not
supporting ARB_compatibility with GL3.1 and, also, the additional
change in behavior of MESA_GL_VERSION_OVERRIDE to always reset the
core version when using this env. variable.

It makes more sense to have all this bundled together for an easier
review process.

With this, the biggest change is the one done and explained in patch
3/5:

- 2.1: select a compatibility (non-Core) profile with GL version 2.1.
- 3.0: select a compatibility (non-Core) profile with GL version 3.0.
- 3.0FC: select a Core+Forward Compatible profile with GL version 3.0.
- 3.1: select GL version 3.1 with GL_ARB_compatibility enabled per the driver 
default.
- 3.1FC: select GL version 3.1 with forward compatibility and 
GL_ARB_compatibility disabled.
- 3.1COMPAT: select GL version 3.1 with GL_ARB_compatibilty enabled.
- X.Y: override GL version to X.Y without changing the profile.
- X.YFC: select a Core+Forward Compatible profile with GL version X.Y.
- X.YCOMPAT: select a Compatibility profile with GL version X.Y.

Andres Gomez (3):
  dri_util: when overriding, always reset the core version
  dri_util: don't fail when not supporting ARB_compatibility with GL3.1
  mesa: adds some comments regarding MESA_GLES_VERSION_OVERRIDE usage

Marek Olšák (2):
  mesa: simplify MESA_GL_VERSION_OVERRIDE behavior of API override
  mesa: adjust incorrect comment in texture_buffer_range

 docs/envvars.html  | 25 ++---
 docs/features.txt  | 11 +++
 src/mesa/drivers/dri/common/dri_util.c | 16 
 src/mesa/main/teximage.c   |  4 ++--
 src/mesa/main/version.c| 33 +++--
 5 files changed, 58 insertions(+), 31 deletions(-)

-- 
2.16.1

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

Re: [Mesa-dev] [PATCH 0/6] Shader cache; transform feedback; i965 program-binary

[Timothy Arceri]

Thanks for finishing this off Jordan. Series:

Reviewed-by: Timothy Arceri 

On 14/03/18 18:26, Jordan Justen wrote:

git://people.freedesktop.org/~jljusten/mesa shader-cache-xform-fb+prog-bin-v1

Patches 1 - 3 remove the restriction preventing the disk shader cache
from being enabled if transform feedback is enabled via the GL API.
These patches affect all drivers that support shader cache.

Patches 4 - 6 address an issue I found with i965 when running DOTA2
with the shader cache enabled. It appears that if the shader cache is
enabled, we will never use the shader cache for programs loaded with
ProgramBinary.

We had been setting the LinkStatus to LINKING_SUCCESS, and previously
i965 would skip using the shader cache if the LinkStatus wasn't
LINKING_SKIPPED. Either patch 5 or 6 should address this, but I think
6 still makes sense.

I sent out a related series on Sunday. It turned out that series
triggered issues where if ProgramBinary was used, and transform
feedback was enabled. For this reason, I looked into the transform
feedback limitation addressed in patches 1 - 3.

Jordan Justen (6):
   glsl/shader_cache: Allow shader cache usage with transform feedback
   i965: Allow disk shader cache usage with transform feedback
   glsl: Remove api_enabled tracking for transform feedback
   glsl/serialize: Save shader program metadata sha1
   i965: Allow disk shader cache usage with LINKING_SUCCESS status
   main/program_binary: In ProgramBinary set link status as
 LINKING_SKIPPED

  src/compiler/glsl/link_varyings.cpp|  2 --
  src/compiler/glsl/linker.cpp   | 11 +--
  src/compiler/glsl/serialize.cpp|  4 
  src/compiler/glsl/shader_cache.cpp |  6 ++
  src/mesa/drivers/dri/i965/brw_disk_cache.c | 11 ---
  src/mesa/main/mtypes.h |  3 ---
  src/mesa/main/program_binary.c |  2 +-
  7 files changed, 12 insertions(+), 27 deletions(-)


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

Re: [Mesa-dev] [PATCH 04/11] nir/spirv: add gl_spirv_validation method

[Timothy Arceri]

On 08/03/18 19:19, Alejandro Piñeiro wrote:

ARB_gl_spirv adds the ability to use SPIR-V binaries, and a new
method, glSpecializeShader. From OpenGL 4.6 spec, section 7.2.1
"Shader Specialization", error table:

  INVALID_VALUE is generated if  does not name a valid
  entry point for .

  INVALID_VALUE is generated if any element of 
  refers to a specialization constant that does not exist in the
  shader module contained in .""

But we are not really interested on creating the nir shader at that
point, and adding nir structures on the gl_program, so at that point
we are just interested on the error checking.

So we add a new method focused on just checking those errors. It still
needs to parse the binary, but skips what it is not needed, and
doesn't create the nir shader.



Can we reword the above text to simply:

 ARB_gl_spirv adds the ability to use SPIR-V binaries, and a new
 method, glSpecializeShader. Here we add a new function to do the
 validation for this function:

 From OpenGL 4.6 spec, section 7.2.1"

  "Shader Specialization", error table:

   INVALID_VALUE is generated if  does not name a valid
   entry point for .

   INVALID_VALUE is generated if any element of 
   refers to a specialization constant that does not exist in the
   shader module contained in .""



v2: rebase update (spirv_to_nir options added, changes on the warning
 logging, and others)

v3: include passing options on common initialization, doesn't call
 setjmp on common_initialization

v4: (after Jason comments):
   * Rename common_initialization to vtn_builder_create
   * Move validation method and their helpers to own source file.
   * Create own handle_constant_decoration_cb instead of reuse existing one

v5: put vtn_build_create refactoring to their own patch (Jason)
---
  src/compiler/Makefile.sources |   1 +
  src/compiler/nir/meson.build  |   1 +
  src/compiler/spirv/gl_spirv.c | 268 ++
  src/compiler/spirv/nir_spirv.h|   5 +
  src/compiler/spirv/spirv_to_nir.c |  35 +++--
  src/compiler/spirv/vtn_private.h  |   6 +
  6 files changed, 302 insertions(+), 14 deletions(-)
  create mode 100644 src/compiler/spirv/gl_spirv.c

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 37340ba809e..24218985d6d 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -295,6 +295,7 @@ SPIRV_GENERATED_FILES = \
spirv/vtn_gather_types.c
  
  SPIRV_FILES = \

+   spirv/gl_spirv.c \
spirv/GLSL.std.450.h \
spirv/nir_spirv.h \
spirv/spirv.h \
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index a70c236b958..e7a94bcc1cf 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -183,6 +183,7 @@ files_libnir = files(
'nir_vla.h',
'nir_worklist.c',
'nir_worklist.h',
+  '../spirv/gl_spirv.c',
'../spirv/GLSL.std.450.h',
'../spirv/nir_spirv.h',
'../spirv/spirv.h',
diff --git a/src/compiler/spirv/gl_spirv.c b/src/compiler/spirv/gl_spirv.c
new file mode 100644
index 000..e82686bfe0d
--- /dev/null
+++ b/src/compiler/spirv/gl_spirv.c
@@ -0,0 +1,268 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ *
+ */
+
+#include "nir_spirv.h"
+
+#include "vtn_private.h"
+#include "spirv_info.h"
+
+static bool
+vtn_validate_preamble_instruction(struct vtn_builder *b, SpvOp opcode,
+  const uint32_t *w, unsigned count)
+{
+   switch (opcode) {
+   case SpvOpSource:
+   case SpvOpSourceExtension:
+   case SpvOpSourceContinued:
+   case SpvOpExtension:
+   case SpvOpCapability:
+   case SpvOpExtInstImport:
+   case SpvOpMemoryModel:
+   case SpvOpString:
+   case SpvOpName:
+   case SpvOpMemberName:
+   case SpvOpExecutionMode:
+   case 

[Mesa-dev] [Bug 102542] mesa-17.2.0/src/gallium/state_trackers/nine/nine_ff.c:1938: bad assignment ?

[bugzilla-daemon]

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

--- Comment #4 from Axel Davy  ---
Should be fixed by:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=f61e9a958bd8d61cb7ca575ca987caefc6edbffd

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

Re: [Mesa-dev] [PATCH 4/5 v6] clover/llvm: Add get_[cl|language]_version, validation and some helpers

[Pierre Moreau]

On 2018-03-01 — 20:02, Aaron Watry wrote:
> Used to calculate the default CLC language version based on the --cl-std in 
> build args
> and the device capabilities.
> 
> According to section 5.8.4.5 of the 2.0 spec, the CL C version is chosen by:
>  1) If you have -cl-std=CL1.1+ use the version specified
>  2) If not, use the highest 1.x version that the device supports
> 
> Curiously, there is no valid value for -cl-std=CL1.0
> 
> Validates requested cl-std against device_clc_version
> 
> Signed-off-by: Aaron Watry 
> Cc: Pierre Moreau 
> 
> v6: (Pierre) Add more const and fix some whitespace
> 
> v5: (Aaron) Use a collection of cl versions instead of switch cases
> Consolidates the string, numeric version, and clc langstandard::kind
> 
> v4: (Pierre) Split get_language_version addition and use into separate patches
> Squash patches that add the helpers and validate the language standard
> 
> v3: Change device_version to device_clc_version
> 
> v2: (Pierre) Move create_compiler_instance changes to correct patch
> to prevent temporary build breakage.
> Convert version_str into unsigned and use it to find language version
> Add build_error for unknown language version string
> Whitespace fixes
> ---
>  .../state_trackers/clover/llvm/invocation.cpp  | 63 
> ++
>  1 file changed, 63 insertions(+)
> 
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp 
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 0bc06e..0f854b9049 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -63,6 +63,23 @@ using ::llvm::Module;
>  using ::llvm::raw_string_ostream;
>  
>  namespace {
> +
> +   struct cl_version {
> +  std::string version_str; // CL Version
> +  unsigned version_number; // Numeric CL Version
> +  clang::LangStandard::Kind clc_lang_standard; // lang standard for 
> version
> +   };
> +
> +   static const unsigned ANY_VERSION = 999;
> +   const cl_version cl_versions[] = {
> +  { "1.0", 100, clang::LangStandard::lang_opencl10},
> +  { "1.1", 110, clang::LangStandard::lang_opencl11},
> +  { "1.2", 120, clang::LangStandard::lang_opencl12},
> +  { "2.0", 200, clang::LangStandard::lang_opencl20},
> +  { "2.1", 210, clang::LangStandard::lang_unspecified}, //2.1 doesn't 
> exist
> +  { "2.2", 220, clang::LangStandard::lang_unspecified}, //2.2 doesn't 
> exist
> +   };

Given that OpenCL C version are no longer a 1:1 mapping to OpenCL API version,
and with the introduction of OpenCL C++ 1.0 with OpenCL 2.2, I would go with
two different tables:
* one matching strings to the integer version;
* one matching integer or string version, to the OpenCL C LangStandard
and later we can have a third one for matching integer/string to OpenCL C++
LangStandard.

> +
> void
> init_targets() {
>static bool targets_initialized = false;
> @@ -93,6 +110,52 @@ namespace {
>return ctx;
> }
>  
> +   const struct cl_version

I think you forgot the reference there, otherwise if you want to return a copy,
you can remove the `const` keyword as it has no impact on copies.

> +   get_cl_version(const std::string _str,
> +  unsigned max = ANY_VERSION) {
> +  for (const struct cl_version version : cl_versions) {

Please make `version` into a reference: no need to create a copy each time.

> + if (version.version_number == max || version.version_str == 
> version_str) {
> +return version;
> + }
> +  }
> +  throw build_error("Unknown/Unsupported language version");
> +   }
> +
> +   clang::LangStandard::Kind
> +   get_lang_standard_from_version_str(const std::string _str,
> +  bool is_build_opt = false) {
> +   /**
> +   * Per CL 2.0 spec, section 5.8.4.5:
> +   * If it's an option, use the value directly.
> +   * If it's a device version, clamp to max 1.x version, a.k.a. 1.2
> +   */

Please switch to regular C++-style comments.

> +  const struct cl_version version = get_cl_version(version_str,
> +  is_build_opt ? ANY_VERSION : 120);
> +  return version.clc_lang_standard;
> +   }
> +
> +   clang::LangStandard::Kind
> +   get_language_version(const std::vector ,
> +const std::string _version) {
> +
> +  const std::string search = "-cl-std=CL";
> +
> +  for (auto opt: opts) {

opt could be a constant reference, to avoid making copies of strings every
time.

With those modifications, this is
Reviewed-by: Pierre Moreau 

> + auto pos = opt.find(search);
> + if (pos == 0){
> +const auto ver = opt.substr(pos + search.size());
> +const auto device_ver = get_cl_version(device_version);
> +const auto requested = get_cl_version(ver);

[Mesa-dev] [Bug 105464] Reading per-patch outputs in Tessellation Control Shader returns undefined values

[bugzilla-daemon]

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

soredake  changed:

   What|Removed |Added

 CC||fds...@krutt.org

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

Re: [Mesa-dev] Patchwork has 'Server Error (500)'

[Daniel Stone]

Hi Dieter,

On 18 March 2018 at 00:48, Dieter Nützel  wrote:
> @ least, here fromm Germany.
>
> https://patchwork.freedesktop.org/
> Server Error (500)

This is fixed now, and I think that particular problem shouldn't happen again.

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

Re: [Mesa-dev] [PATCH v0] nir: mako all the intrinsics

[Jason Ekstrand]

On Sat, Mar 17, 2018 at 10:32 PM, Dylan Baker  wrote:

> Quoting Jason Ekstrand (2018-03-17 09:53:13)
> > On March 16, 2018 23:36:50 Dylan Baker  wrote:
> >
> > > Quoting Rob Clark (2018-03-16 14:25:09)
> > >> On Fri, Mar 16, 2018 at 4:30 PM, Dylan Baker 
> wrote:
> > >> > Quoting Rob Clark (2018-03-16 12:20:10)
> > >> >> On Fri, Mar 16, 2018 at 3:13 PM, Jason Ekstrand <
> ja...@jlekstrand.net>
> > >> wrote:
> > >> >> > On Fri, Mar 16, 2018 at 11:53 AM, Dylan Baker <
> dy...@pnwbakers.com> wrote:
> > >> >> >>
> > >> >> >> Quoting Jason Ekstrand (2018-03-16 11:38:47)
> > >> >> >> > On Fri, Mar 16, 2018 at 11:28 AM, Dylan Baker <
> dy...@pnwbakers.com>
> > >> >> >> > wrote:
> > >> >> >> >
> > >> >> >> > intr_opcodes = {
> > >> >> >> > 'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
> > >> >> >> > ...
> > >> >> >> > }
> > >> >> >> >
> > >> >> >> > I prefer this since each dictionary is clearly created
> without a
> > >> >> >> > function
> > >> >> >> > obscuring what's actually going on. If you dislike having
> to repeat
> > >> >> >> > the
> > >> >> >> > name you
> > >> >> >> > could even do something like:
> > >> >> >> > intr_opcodes = [
> > >> >> >> > 'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
> > >> >> >> > ...
> > >> >> >> > ]
> > >> >> >> > intr_opcodes = {i.name: i for i in intr_opcodes}
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > I'm not sure what I think about this.  On the one hand,
> having the
> > >> >> >> > dictionary
> > >> >> >> > explicitly declared is nice.  On the other hand, in
> nir_opcodes.py we
> > >> >> >> > have a
> > >> >> >> > bunch of other helper functions we declare along the way to
> help with
> > >> >> >> > specific
> > >> >> >> > kinds of opcodes.  It's not as practical to do this if
> everything is
> > >> >> >> > inside of
> > >> >> >> > a dictionary declaration.
> > >> >> >>
> > >> >> >> Why not?
> > >> >> >>
> > >> >> >> def make_op(name, *args):
> > >> >> >> return Intrinsic(name, foo='bar', *args)
> > >> >> >>
> > >> >> >> intr_opcodes = [
> > >> >> >> make_op('nop', ...),
> > >> >> >> ]
> > >> >> >
> > >> >> >
> > >> >> > Because it's nice to keep the definition of the wrapper close to
> where
> > >> it's
> > >> >> > used.
> > >> >> >
> > >> >>
> > >> >> also, fwiw, I end up needing two sets (or possibly lists), a second
> > >> >> one for the builders that are generated for sysval intrinsics.. I'm
> > >> >> not entirely sure how that would work if everything was declared
> > >> >> inline instead of via helper fxns
> > >> >
> > >> > I'm missing where a helper function adds an intrinsic to more than
> one list.
> > >>
> > >> system_value() adds to system_values table, after calling intrinsic()
> > >> which adds to the global table (this is the reason for the return
> > >> statement in intrinsic()
> > >>
> > >> BR,
> > >> -R
> > >>
> > >
> > > I don't know, maybe it's just that I really don't like side effects,
> but
> > > functions with side-effects that call functions with side-effects make
> me
> > > nervous.
> >
> > I think side effects are ok here.  This is one of those cases where we're
> > not so much writing python code as writing a tiny DSL in python for
> > declaring NIR intrinsics.  Alternatively, you can think of the
> "intrinsic"
> > function as a sort of "add this to a database" function which is
> something
> > which has fairly natural and easy to understand side effects.  In either
> > case, the focus needs to be on the NIR intrinsics being declared and the
> > details of how the python works should fade into the background.
> >
>
> That's the sort of logic that made the mess in mapi/glapi/gen. These
> generators
> are like the shell script thats "just a one off script, it's just a few
> lines",
> and suddenly ten people have modified it and no one understands how it
> works or
> can modify it without everything falling apart.


That is likely true. :-)

Code generators need to be clean
> and maintainable just like the C and C++ code that makes up mesa.
> Seriously,
> this is why I'm rewriting all of the generators in mapi/glapi/gen instead
> of
> trying to fix them to work with Khronos XML.
>

Yes they do and I whole-heatedly agree with your desire for cleanliness.
The reason why this particular script gets sticky is that there are two
pieces whose cleanliness is in conflict: the list of intrinsic definitions,
and the python code which puts them into a data structure.  You are arguing
for the cleanliness of the python code over the list of declarations.  What
is really important in this file, however, is the list of declarations.
The python code that turns those declarations into a data structure is just
an implementation detail.

Unfortunately, all of the mechanisms that have so-far been suggested to
clean up the python have one or more of the following side-effects:

 1) Duplicating names of opcodes so that they