[Mesa-dev] [PATCH 1/5] glsl: print non-zero bindings of variables

2016-10-13 Thread Nicolai Hähnle
From: Nicolai Hähnle 

---
 src/compiler/glsl/ir_print_visitor.cpp | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/ir_print_visitor.cpp 
b/src/compiler/glsl/ir_print_visitor.cpp
index c238c16..efb728b 100644
--- a/src/compiler/glsl/ir_print_visitor.cpp
+++ b/src/compiler/glsl/ir_print_visitor.cpp
@@ -158,20 +158,24 @@ print_type(FILE *f, const glsl_type *t)
 
 void ir_print_visitor::visit(ir_rvalue *)
 {
fprintf(f, "error");
 }
 
 void ir_print_visitor::visit(ir_variable *ir)
 {
fprintf(f, "(declare ");
 
+   char binding[32] = {0};
+   if (ir->data.binding)
+  snprintf(binding, sizeof(binding), "binding=%i ", ir->data.binding);
+
char loc[32] = {0};
if (ir->data.location != -1)
   snprintf(loc, sizeof(loc), "location=%i ", ir->data.location);
 
char component[32] = {0};
if (ir->data.explicit_component)
   snprintf(component, sizeof(component), "component=%i ", 
ir->data.location_frac);
 
const char *const cent = (ir->data.centroid) ? "centroid " : "";
const char *const samp = (ir->data.sample) ? "sample " : "";
@@ -180,22 +184,22 @@ void ir_print_visitor::visit(ir_variable *ir)
const char *const prec = (ir->data.precise) ? "precise " : "";
const char *const mode[] = { "", "uniform ", "shader_storage ",
 "shader_shared ", "shader_in ", "shader_out ",
 "in ", "out ", "inout ",
"const_in ", "sys ", "temporary " };
STATIC_ASSERT(ARRAY_SIZE(mode) == ir_var_mode_count);
const char *const stream [] = {"", "stream1 ", "stream2 ", "stream3 "};
const char *const interp[] = { "", "smooth", "flat", "noperspective" };
STATIC_ASSERT(ARRAY_SIZE(interp) == INTERP_MODE_COUNT);
 
-   fprintf(f, "(%s%s%s%s%s%s%s%s%s%s) ",
-   loc, component, cent, samp, patc, inv, prec, mode[ir->data.mode],
+   fprintf(f, "(%s%s%s%s%s%s%s%s%s%s%s) ",
+   binding, loc, component, cent, samp, patc, inv, prec, 
mode[ir->data.mode],
stream[ir->data.stream],
interp[ir->data.interpolation]);
 
print_type(f, ir->type);
fprintf(f, " %s)", unique_name(ir));
 }
 
 
 void ir_print_visitor::visit(ir_function_signature *ir)
 {
-- 
2.7.4

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


Re: [Mesa-dev] Required-for-rendering internal formats

2016-10-13 Thread Nicolai Hähnle

On 13.10.2016 17:15, Ilia Mirkin wrote:

Anyone else have opinions on this? Should st/mesa be adding
PIPE_BIND_RENDER_TARGET for all textures of the internal formats
listed in table 8.12? (Which would, in this case, force RGBA8 to be
used since RGBA4 is non-renderable.) Or is it perfectly legal for a
format to be not renderable when used as a texture vs renderbuffer?


I think the spec is pretty clear that the "req.rend." column of that 
table is only for renderbuffers.


It's a lot less clear about what really matters for this question. In 
section 9.4.3 (Required Framebuffer Formats), there's the curious sentence:


Each color attachment may be in any of the color-renderable
formats described in section 9.4 (although implementations
are not required to support creation of attachments in all
color-renderable formats).

Color-renderable formats are those which have a checkmark in the CR 
column according to section 9.4. That means pretty much _all_ 
non-compressed formats (except for the shared exponents one). I doubt 
that the intention is to force stuff like R3_G3_B2 to be renderable.


It's kind of funny that the sentence says that the attachments may be in 
any of these formats, but you may not be able to create the attachments?


I think what that's trying to say is that the implementation MUST reject 
color attachments that are not CR according to table 8.12, and it MAY 
reject color attachments of any format it likes.


So I tend to side with the interpretation that exposing RGBA4 as texture 
format but not allowing to render to it is okay by the spec, and the 
application has a bug. It's pretty ridiculous though that apparently the 
spec doesn't even mandate that RGBA8 must be renderable.


Cheers,
Nicolai




On Wed, Sep 7, 2016 at 1:19 PM, Ilia Mirkin  wrote:

Right, but it'd break st/nine which doesn't (didn't?) support
fallbacks like st/mesa does.

I'm trying to better understand what the required logic is based on
the spec, not how to fix this particular application's rendering with
nouveau (which I'm much less concerned about, tbh).

  -ilia

On Wed, Sep 7, 2016 at 1:16 PM, Marek Olšák  wrote:

Dropping texturing support for RGBA4 would resolve that issue.

Marek

On Wed, Sep 7, 2016 at 5:43 PM, Ilia Mirkin  wrote:

Hello,

Is there a concept in OpenGL that certain internal formats *must* be
supported for rendering? An issue we're running into is that NVIDIA
hardware supports sampling from RGBA4 textures, but does not support
that as a render format. So if you create a tex image with GL_RGBA4,
we use that as the TexFormat, since we can sample from it. However
then attaching the image to a fbo makes that fbo incomplete.

At least one application isn't ready to handle that situation. Is the
application wrong, or must we support GL_RGBA4 as a renderable texture
attachment format, thus meaning that we should never actually make use
of the hw's RGBA4 sampling capabilities (since we never know if a
texture will later be used for rendering)?

The spec is a bit unclear about this. Table 8.12 of the GL 4.5 core
spec marks GL_RGBA4 as "required renderable", but I think that only
affects renderbuffers (which st/mesa handles properly by falling back
to RGBA8 when the requested format is not renderable).

Any advice welcome.

Cheers,

  -ilia
___
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] [Bug 98223] dEQP GLES3.1 program_interface_query failures w/ error "could not find target resource"

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98223

--- Comment #6 from Alejandro Piñeiro (freenode IRC: apinheiro) 
 ---
(In reply to Randy from comment #5)
> We can use the patch (in
> https://lists.freedesktop.org/archives/mesa-dev/2016-August/124910.html) to
> workaround the name issue, while some cases still fail due to wrong
> property, like ARRAY_SIZE  

The problem is that the spec is contradictory. The patch on that link (that
btw, the author is Kenneth, that wrote comment 1) fixes some deqp and CTS
tests. But it causes some regressions on others, like you mention below.

So at this point, I really think that it would be better to wait for a
resolution from Khronos on relation to the text of the spec, issue 16 in
particular, and then fix the tests.

> 
> in TargetInterface
> {
> highp vec4 target[3];
> } targetInstance[2];
> 
> the expected ARRAY_SIZE of TargetInterface.target[0] is 3, while the actual
> return value is 2.

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


Re: [Mesa-dev] [PATCH mesa] swr: [rasterizer common] fix assert index

2016-10-13 Thread Rowley, Timothy O
Reviewed-by: Tim Rowley 
>

On Oct 12, 2016, at 4:13 PM, Eric Engestrom 
> wrote:

Fixes: b3bd8bb611bb465d2e5e ("swr: [rasterizer core] add support
  for "RAW" surface format")
CovID: 1373647
Signed-off-by: Eric Engestrom >
---
src/gallium/drivers/swr/rasterizer/common/formats.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/swr/rasterizer/common/formats.h 
b/src/gallium/drivers/swr/rasterizer/common/formats.h
index 539e37a..dd5b499 100644
--- a/src/gallium/drivers/swr/rasterizer/common/formats.h
+++ b/src/gallium/drivers/swr/rasterizer/common/formats.h
@@ -248,7 +248,7 @@ extern const SWR_FORMAT_INFO gFormatInfo[NUM_SWR_FORMATS];
/// @param format - SWR format
INLINE const SWR_FORMAT_INFO& GetFormatInfo(SWR_FORMAT format)
{
-SWR_ASSERT(format <= NUM_SWR_FORMATS, "Invalid Surface Format: %d", 
format);
+SWR_ASSERT(format < NUM_SWR_FORMATS, "Invalid Surface Format: %d", format);
SWR_ASSERT(gFormatInfo[format].name != nullptr, "Invalid Surface Format: 
%d", format);
return gFormatInfo[format];
}
--
Cheers,
 Eric


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


[Mesa-dev] [PATCH 2/2] radv: Use new image load/store intrinsic signatures

2016-10-13 Thread Tom Stellard
These were changed in LLVM r284024.
---
 src/amd/common/ac_nir_to_llvm.c | 131 
 1 file changed, 107 insertions(+), 24 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 9c764c7..4fba7d3 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2296,13 +2296,73 @@ static LLVMValueRef get_image_coords(struct 
nir_to_llvm_context *ctx,
return res;
 }
 
+static void build_type_name_for_intr(
+LLVMTypeRef type,
+char *buf, unsigned bufsize)
+{
+LLVMTypeRef elem_type = type;
+
+assert(bufsize >= 8);
+
+if (LLVMGetTypeKind(type) == LLVMVectorTypeKind) {
+int ret = snprintf(buf, bufsize, "v%u",
+LLVMGetVectorSize(type));
+if (ret < 0) {
+char *type_name = LLVMPrintTypeToString(type);
+fprintf(stderr, "Error building type name for: %s\n",
+type_name);
+return;
+}
+elem_type = LLVMGetElementType(type);
+buf += ret;
+bufsize -= ret;
+}
+switch (LLVMGetTypeKind(elem_type)) {
+default: break;
+case LLVMIntegerTypeKind:
+snprintf(buf, bufsize, "i%d", LLVMGetIntTypeWidth(elem_type));
+break;
+case LLVMFloatTypeKind:
+snprintf(buf, bufsize, "f32");
+break;
+case LLVMDoubleTypeKind:
+snprintf(buf, bufsize, "f64");
+break;
+}
+}
+
+static void get_image_intr_name(const char *base_name,
+LLVMTypeRef data_type,
+LLVMTypeRef coords_type,
+LLVMTypeRef rsrc_type,
+char *out_name, unsigned out_len)
+{
+char coords_type_name[8];
+
+build_type_name_for_intr(coords_type, coords_type_name,
+sizeof(coords_type_name));
+
+if (HAVE_LLVM <= 0x0309) {
+snprintf(out_name, out_len, "%s.%s", base_name, 
coords_type_name);
+} else {
+char data_type_name[8];
+char rsrc_type_name[8];
+
+build_type_name_for_intr(data_type, data_type_name,
+sizeof(data_type_name));
+build_type_name_for_intr(rsrc_type, rsrc_type_name,
+sizeof(rsrc_type_name));
+snprintf(out_name, out_len, "%s.%s.%s.%s", base_name,
+ data_type_name, coords_type_name, rsrc_type_name);
+}
+}
+
 static LLVMValueRef visit_image_load(struct nir_to_llvm_context *ctx,
 nir_intrinsic_instr *instr)
 {
LLVMValueRef params[7];
LLVMValueRef res;
-   char intrinsic_name[32];
-   char coords_type[8];
+   char intrinsic_name[64];
const nir_variable *var = instr->variables[0]->var;
const struct glsl_type *type = var->type;
if(instr->variables[0]->deref.child)
@@ -2322,23 +2382,35 @@ static LLVMValueRef visit_image_load(struct 
nir_to_llvm_context *ctx,
res = trim_vector(ctx, res, instr->dest.ssa.num_components);
res = to_integer(ctx, res);
} else {
-   bool da = glsl_sampler_type_is_array(type) ||
- glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
+   bool is_da = glsl_sampler_type_is_array(type) ||
+glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE;
bool add_frag_pos = glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS;
+   LLVMValueRef da = is_da ? ctx->i32one : ctx->i32zero;
+   LLVMValueRef glc = LLVMConstInt(ctx->i1, 0, false);
+   LLVMValueRef slc = LLVMConstInt(ctx->i1, 0, false);
 
params[0] = get_image_coords(ctx, instr, add_frag_pos);
params[1] = get_sampler_desc(ctx, instr->variables[0], 
DESC_IMAGE);
params[2] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
-   params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
-   params[4] = da ? ctx->i32one : ctx->i32zero; /* da */
-   params[5] = LLVMConstInt(ctx->i1, 0, false);  /* glc */
-   params[6] = LLVMConstInt(ctx->i1, 0, false);  /* slc */
+   if (HAVE_LLVM <= 0x0309) {
+   params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
+   params[4] = da;
+   params[5] = glc;
+   params[6] = slc;
+   } else {
+   LLVMValueRef lwe = LLVMConstInt(ctx->i1, 0, false);
+   params[3] = glc;
+   

[Mesa-dev] [Bug 98169] lm_sensors hud option crashes unigine heaven

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98169

Steven Toth  changed:

   What|Removed |Added

 Attachment #127222|0   |1
is obsolete||
 Attachment #127246|0   |1
is obsolete||

--- Comment #29 from Steven Toth  ---
Created attachment 127271
  --> https://bugs.freedesktop.org/attachment.cgi?id=127271=edit
Switch to internal reference counting and mutexing.

Replacement, add mutex locking on the lists and using the internal reference
counting implementation.

-- 
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


[Mesa-dev] [Bug 98223] dEQP GLES3.1 program_interface_query failures w/ error "could not find target resource"

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98223

--- Comment #5 from Randy  ---
We can use the patch (in
https://lists.freedesktop.org/archives/mesa-dev/2016-August/124910.html) to
workaround the name issue, while some cases still fail due to wrong property,
like ARRAY_SIZE  

in TargetInterface
{
highp vec4 target[3];
} targetInstance[2];

the expected ARRAY_SIZE of TargetInterface.target[0] is 3, while the actual
return value is 2.

-- 
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] Required-for-rendering internal formats

2016-10-13 Thread Ilia Mirkin
Anyone else have opinions on this? Should st/mesa be adding
PIPE_BIND_RENDER_TARGET for all textures of the internal formats
listed in table 8.12? (Which would, in this case, force RGBA8 to be
used since RGBA4 is non-renderable.) Or is it perfectly legal for a
format to be not renderable when used as a texture vs renderbuffer?

On Wed, Sep 7, 2016 at 1:19 PM, Ilia Mirkin  wrote:
> Right, but it'd break st/nine which doesn't (didn't?) support
> fallbacks like st/mesa does.
>
> I'm trying to better understand what the required logic is based on
> the spec, not how to fix this particular application's rendering with
> nouveau (which I'm much less concerned about, tbh).
>
>   -ilia
>
> On Wed, Sep 7, 2016 at 1:16 PM, Marek Olšák  wrote:
>> Dropping texturing support for RGBA4 would resolve that issue.
>>
>> Marek
>>
>> On Wed, Sep 7, 2016 at 5:43 PM, Ilia Mirkin  wrote:
>>> Hello,
>>>
>>> Is there a concept in OpenGL that certain internal formats *must* be
>>> supported for rendering? An issue we're running into is that NVIDIA
>>> hardware supports sampling from RGBA4 textures, but does not support
>>> that as a render format. So if you create a tex image with GL_RGBA4,
>>> we use that as the TexFormat, since we can sample from it. However
>>> then attaching the image to a fbo makes that fbo incomplete.
>>>
>>> At least one application isn't ready to handle that situation. Is the
>>> application wrong, or must we support GL_RGBA4 as a renderable texture
>>> attachment format, thus meaning that we should never actually make use
>>> of the hw's RGBA4 sampling capabilities (since we never know if a
>>> texture will later be used for rendering)?
>>>
>>> The spec is a bit unclear about this. Table 8.12 of the GL 4.5 core
>>> spec marks GL_RGBA4 as "required renderable", but I think that only
>>> affects renderbuffers (which st/mesa handles properly by falling back
>>> to RGBA8 when the requested format is not renderable).
>>>
>>> Any advice welcome.
>>>
>>> Cheers,
>>>
>>>   -ilia
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/2] radv: Fix incorrect comment

2016-10-13 Thread Tom Stellard
---
 src/amd/common/ac_nir_to_llvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index e6ff7c8..9c764c7 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2373,8 +2373,8 @@ static void visit_image_store(struct nir_to_llvm_context 
*ctx,
bool da = glsl_sampler_type_is_array(type) ||
  glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
 
-   params[0] = get_src(ctx, instr->src[2]); /* coords */
-   params[1] = get_image_coords(ctx, instr, false);
+   params[0] = get_src(ctx, instr->src[2]);
+   params[1] = get_image_coords(ctx, instr, false); /* coords */
params[2] = get_sampler_desc(ctx, instr->variables[0], 
DESC_IMAGE);
params[3] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
params[4] = i1false;  /* r128 */
-- 
2.7.4

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


[Mesa-dev] [PATCH 2/5] st/mesa: fix fragment shader output mapping

2016-10-13 Thread Nicolai Hähnle
From: Nicolai Hähnle 

Properly handle the case where there is a gap in the assigned output locations,
e.g. a fragment shader writes to color buffer 2 but not to color buffers 0 & 1.

Fixes 
GL45-CTS.gtf33.GL3Tests.explicit_attrib_location.explicit_attrib_location_pipeline.
---
 src/mesa/state_tracker/st_program.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 91887dc..7cc36b4 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -775,21 +775,20 @@ st_translate_fragment_program(struct st_context *st,
   }
   else {
  inputMapping[attr] = -1;
   }
}
 
/*
 * Semantics and mapping for outputs
 */
{
-  uint numColors = 0;
   GLbitfield64 outputsWritten = stfp->Base.Base.OutputsWritten;
 
   /* if z is written, emit that first */
   if (outputsWritten & BITFIELD64_BIT(FRAG_RESULT_DEPTH)) {
  fs_output_semantic_name[fs_num_outputs] = TGSI_SEMANTIC_POSITION;
  fs_output_semantic_index[fs_num_outputs] = 0;
  outputMapping[FRAG_RESULT_DEPTH] = fs_num_outputs;
  fs_num_outputs++;
  outputsWritten &= ~(1 << FRAG_RESULT_DEPTH);
   }
@@ -819,29 +818,39 @@ st_translate_fragment_program(struct st_context *st,
  if (written & BITFIELD64_BIT(loc)) {
 switch (loc) {
 case FRAG_RESULT_DEPTH:
 case FRAG_RESULT_STENCIL:
 case FRAG_RESULT_SAMPLE_MASK:
/* handled above */
assert(0);
break;
 case FRAG_RESULT_COLOR:
write_all = GL_TRUE; /* fallthrough */
-default:
+default: {
+   int index;
assert(loc == FRAG_RESULT_COLOR ||
   (FRAG_RESULT_DATA0 <= loc && loc < FRAG_RESULT_MAX));
+
+   index = (loc == FRAG_RESULT_COLOR) ? 0 : (loc - 
FRAG_RESULT_DATA0);
+
+   if (attr >= FRAG_RESULT_MAX) {
+  /* Secondary color for dual source blending. */
+  assert(index == 0);
+  index++;
+   }
+
fs_output_semantic_name[fs_num_outputs] = TGSI_SEMANTIC_COLOR;
-   fs_output_semantic_index[fs_num_outputs] = numColors;
+   fs_output_semantic_index[fs_num_outputs] = index;
outputMapping[attr] = fs_num_outputs;
-   numColors++;
break;
 }
+}
 
 fs_num_outputs++;
  }
   }
}
 
if (stfp->shader_program) {
   nir_shader *nir = st_glsl_to_nir(st, >Base.Base,
stfp->shader_program,
MESA_SHADER_FRAGMENT);
-- 
2.7.4

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


[Mesa-dev] [PATCH 4/5] st/glsl_to_tgsi: fix atomic counter addressing

2016-10-13 Thread Nicolai Hähnle
From: Nicolai Hähnle 

When more than one atomic counter buffer is in use, UniformStorage[n].opaque
is set up to contain indices that are contiguous across all used buffers.

This appears to be used by i965 via NIR, but for TGSI we do not treat atomic
counter buffers as opaque, so using the data in the opaque array is incorrect.

Fixes GL45-CTS.compute_shader.resource-atomic-counter.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index a7ea19f..682c034 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -545,21 +545,22 @@ public:
 
void emit_scalar(ir_instruction *ir, unsigned op,
 st_dst_reg dst, st_src_reg src0, st_src_reg src1);
 
void emit_arl(ir_instruction *ir, st_dst_reg dst, st_src_reg src0);
 
void get_deref_offsets(ir_dereference *ir,
   unsigned *array_size,
   unsigned *base,
   unsigned *index,
-  st_src_reg *reladdr);
+  st_src_reg *reladdr,
+  bool opaque);
   void calc_deref_offsets(ir_dereference *head,
   ir_dereference *tail,
   unsigned *array_elements,
   unsigned *base,
   unsigned *index,
   st_src_reg *indirect,
   unsigned *location);
st_src_reg canonicalize_gather_offset(st_src_reg offset);
 
bool try_emit_mad(ir_expression *ir,
@@ -3247,21 +3248,21 @@ 
glsl_to_tgsi_visitor::visit_atomic_counter_intrinsic(ir_call *ir)
ir_dereference *deref = static_cast(param);
ir_variable *location = deref->variable_referenced();
 
st_src_reg buffer(
  PROGRAM_BUFFER, location->data.binding, GLSL_TYPE_ATOMIC_UINT);
 
/* Calculate the surface offset */
st_src_reg offset;
unsigned array_size = 0, base = 0, index = 0;
 
-   get_deref_offsets(deref, _size, , , );
+   get_deref_offsets(deref, _size, , , , false);
 
if (offset.file != PROGRAM_UNDEFINED) {
   emit_asm(ir, TGSI_OPCODE_MUL, st_dst_reg(offset),
offset, st_src_reg_for_int(ATOMIC_COUNTER_SIZE));
   emit_asm(ir, TGSI_OPCODE_ADD, st_dst_reg(offset),
offset, st_src_reg_for_int(location->data.offset + index * 
ATOMIC_COUNTER_SIZE));
} else {
   offset = st_src_reg_for_int(location->data.offset + index * 
ATOMIC_COUNTER_SIZE);
}
 
@@ -3578,21 +3579,21 @@ glsl_to_tgsi_visitor::visit_image_intrinsic(ir_call *ir)
 
ir_dereference *img = (ir_dereference *)param;
const ir_variable *imgvar = img->variable_referenced();
const glsl_type *type = imgvar->type->without_array();
unsigned sampler_array_size = 1, sampler_base = 0;
 
st_src_reg reladdr;
st_src_reg image(PROGRAM_IMAGE, 0, GLSL_TYPE_UINT);
 
get_deref_offsets(img, _array_size, _base,
- (unsigned int *), );
+ (unsigned int *), , true);
if (reladdr.file != PROGRAM_UNDEFINED) {
   image.reladdr = ralloc(mem_ctx, st_src_reg);
   *image.reladdr = reladdr;
   emit_arl(ir, sampler_reladdr, reladdr);
}
 
st_dst_reg dst = undef_dst;
if (ir->return_deref) {
   ir->return_deref->accept(this);
   dst = st_dst_reg(this->result);
@@ -3960,21 +3961,22 @@ glsl_to_tgsi_visitor::calc_deref_offsets(ir_dereference 
*head,
default:
   break;
}
 }
 
 void
 glsl_to_tgsi_visitor::get_deref_offsets(ir_dereference *ir,
 unsigned *array_size,
 unsigned *base,
 unsigned *index,
-st_src_reg *reladdr)
+st_src_reg *reladdr,
+bool opaque)
 {
GLuint shader = _mesa_program_enum_to_shader_stage(this->prog->Target);
unsigned location = 0;
ir_variable *var = ir->variable_referenced();
 
memset(reladdr, 0, sizeof(*reladdr));
reladdr->file = PROGRAM_UNDEFINED;
 
*base = 0;
*array_size = 1;
@@ -3985,21 +3987,22 @@ glsl_to_tgsi_visitor::get_deref_offsets(ir_dereference 
*ir,
 
/*
 * If we end up with no indirect then adjust the base to the index,
 * and set the array size to 1.
 */
if (reladdr->file == PROGRAM_UNDEFINED) {
   *base = *index;
   *array_size = 1;
}
 
-   if (location != 0x) {
+   if (opaque) {
+  assert(location != 0x);
   *base += 
this->shader_program->UniformStorage[location].opaque[shader].index;
   *index += 
this->shader_program->UniformStorage[location].opaque[shader].index;
}
 

[Mesa-dev] [PATCH 5/5] st/glsl_to_tgsi: fix [ui]vec[34] conversion to double

2016-10-13 Thread Nicolai Hähnle
From: Nicolai Hähnle 

The corresponding opcodes for integers need to be treated the same as F2D.

Fixes GL45-CTS.gpu_shader_fp64.conversions.
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 682c034..f49a873 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -862,22 +862,23 @@ glsl_to_tgsi_visitor::emit_asm(ir_instruction *ir, 
unsigned op,
   dinst->src[j].index++;
   }
 
if (swz & 1)
   dinst->src[j].swizzle = MAKE_SWIZZLE4(SWIZZLE_Z, SWIZZLE_W, 
SWIZZLE_Z, SWIZZLE_W);
else
   dinst->src[j].swizzle = MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_Y, 
SWIZZLE_X, SWIZZLE_Y);
 
 } else {
/* some opcodes are special case in what they use as sources
-  - F2D is a float src0, DLDEXP is integer src1 */
-   if (op == TGSI_OPCODE_F2D ||
+  - [FUI]2D/[UI]2I64 is a float/[u]int src0, DLDEXP is integer 
src1 */
+   if (op == TGSI_OPCODE_F2D || op == TGSI_OPCODE_U2D || op == 
TGSI_OPCODE_I2D ||
+   op == TGSI_OPCODE_I2I64 || op == TGSI_OPCODE_U2I64 ||
op == TGSI_OPCODE_DLDEXP ||
(op == TGSI_OPCODE_UCMP && dst_is_64bit[0])) {
   dinst->src[j].swizzle = MAKE_SWIZZLE4(swz, swz, swz, swz);
}
 }
  }
   }
   inst = dinst;
} else {
   this->instructions.push_tail(inst);
-- 
2.7.4

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


[Mesa-dev] [PATCH 3/5] st/glsl_to_tgsi: fix a corner case of std140 layout in uniform buffers

2016-10-13 Thread Nicolai Hähnle
From: Nicolai Hähnle 

See the comment in the code for an explanation. This fixes
GL45-CTS.buffer_storage.map_persistent_draw.
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index fd2485d..a7ea19f 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2103,22 +2103,49 @@ glsl_to_tgsi_visitor::visit_expression(ir_expression* 
ir, st_src_reg *op)
   cbuf.negate = 0;
 
   assert(ir->type->is_vector() || ir->type->is_scalar());
 
   if (const_offset_ir) {
  /* Constant index into constant buffer */
  cbuf.reladdr = NULL;
  cbuf.index = const_offset / 16;
   }
   else {
+ ir_expression *offset_expr = ir->operands[1]->as_expression();
+ st_src_reg offset = op[1];
+
+ /* The OpenGL spec is written in such a way that accesses with
+  * non-constant offset are almost always vec4-aligned. The only
+  * exception to this are members of structs in arrays of structs:
+  * each struct in an array of structs is at least vec4-aligned,
+  * but single-element and [ui]vec2 members of the struct may be at
+  * an offset that is not a multiple of 16 bytes.
+  *
+  * Here, we extract that offset, relying on previous passes to always
+  * generate offset expressions of the form (+ expr constant_offset).
+  *
+  * Note that the std430 layout, which allows more cases of alignment
+  * less than vec4 in arrays, is not supported for uniform blocks, so
+  * we do not have to deal with it here.
+  */
+ if (offset_expr && offset_expr->operation == ir_binop_add) {
+const_offset_ir = offset_expr->operands[1]->as_constant();
+if (const_offset_ir) {
+   const_offset = const_offset_ir->value.u[0];
+   cbuf.index = const_offset / 16;
+   offset_expr->operands[0]->accept(this);
+   offset = this->result;
+}
+ }
+
  /* Relative/variable index into constant buffer */
- emit_asm(ir, TGSI_OPCODE_USHR, st_dst_reg(index_reg), op[1],
+ emit_asm(ir, TGSI_OPCODE_USHR, st_dst_reg(index_reg), offset,
   st_src_reg_for_int(4));
  cbuf.reladdr = ralloc(mem_ctx, st_src_reg);
  memcpy(cbuf.reladdr, _reg, sizeof(index_reg));
   }
 
   if (const_uniform_block) {
  /* Constant constant buffer */
  cbuf.reladdr2 = NULL;
  cbuf.index2D = const_block;
  cbuf.has_index2 = true;
-- 
2.7.4

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


[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98172

--- Comment #8 from shinji.suz...@gmail.com ---
Comment on attachment 127267
  --> https://bugs.freedesktop.org/attachment.cgi?id=127267
Lock the shared state mutex and work with a local reference of so->fence

Review of attachment 127267:
-

I'm afraid execution of st_fence_sync() can still race.
Thread-A can run upto
  success = screen->fence_finish(screen, pipe, fence, 0);
and then get prempted and Thread-B can run upto the same location.
And then
  screen->fence_reference(screen, >fence, NULL);
can still be executed in arbitrary order. If screen->fence_refrence()
is thread-safe and return true only for the first invocation then all is fine
but likely it is not true as otherwise we will not be struggling with this
issue.
I think the gist of it is that checking of so->fence and nullifying of it
should be executed atomically. If "if (success)" is replaced with "if (success
&& so->fence)" then the program may behave correctly but I'm not confortable
about sreen->fence_ference() being called concurrently.
I'm also concerned that mutual exclusion on ctx->Shared->Mutex may introduce
unnecessarily strict serialization. 
Can't we introduce per sync-object mutex so that excution of checking of
so->fence and nullyfying of it happen atomically?
Is that modification too intrusive? (At least it is unnecessary overhead when
st_fence_sync() is not executed concurrently on the same sync object.)

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


[Mesa-dev] [Bug 98169] lm_sensors hud option crashes unigine heaven

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98169

--- Comment #31 from Christoph Haag  ---
Yes, your new patch works. No crashing, all panes are visible and show the
correct values.

-- 
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


[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98172

--- Comment #9 from shinji.suz...@gmail.com ---
oops. I'm getting confused. Concurrent programmingis hard.
> screen->fence_reference(screen, >fence, NULL);
will not be executed in arbitrary order but serially due to the mutex locking.
Still the out come should be a segfault in the thread that comes late.

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


[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98172

--- Comment #10 from shinji.suz...@gmail.com ---
>I'm not confortable about sreen->fence_ference() being called concurrently.

I'm not comfortable about sreen->fence_finish() being called concurrently.

-- 
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] gallium: add PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY

2016-10-13 Thread Nicolai Hähnle

Reviewed-by: Nicolai Hähnle 

On 12.10.2016 15:29, Marek Olšák wrote:

From: Marek Olšák 

For performance tuning in drivers. It filters out window system
framebuffers and OpenGL renderbuffers.

radeonsi will use this to guess whether a depth buffer will be read
by a shader. There is no guarantee about what will actually happen.

This is a departure from PIPE_BIND flags which are defined to be strict
but they are useless in practice.
---
 src/gallium/include/pipe/p_defines.h | 1 +
 src/mesa/state_tracker/st_texture.c  | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index db96c51..037ed92 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -443,20 +443,21 @@ enum pipe_flush_flags
 #define PIPE_BIND_SCANOUT (1 << 19) /*  */
 #define PIPE_BIND_SHARED  (1 << 20) /* get_texture_handle ??? */
 #define PIPE_BIND_LINEAR  (1 << 21)


 /**
  * Flags for the driver about resource behaviour:
  */
 #define PIPE_RESOURCE_FLAG_MAP_PERSISTENT (1 << 0)
 #define PIPE_RESOURCE_FLAG_MAP_COHERENT   (1 << 1)
+#define PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY (1 << 2)
 #define PIPE_RESOURCE_FLAG_DRV_PRIV(1 << 16) /* driver/winsys private */
 #define PIPE_RESOURCE_FLAG_ST_PRIV (1 << 24) /* state-tracker/winsys 
private */

 /**
  * Hint about the expected lifecycle of a resource.
  * Sorted according to GPU vs CPU access.
  */
 enum pipe_resource_usage {
PIPE_USAGE_DEFAULT,/* fast GPU access */
PIPE_USAGE_IMMUTABLE,  /* fast GPU access, immutable */
diff --git a/src/mesa/state_tracker/st_texture.c 
b/src/mesa/state_tracker/st_texture.c
index a2c36ac..7b72ffd 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -84,21 +84,22 @@ st_texture_create(struct st_context *st,
memset(, 0, sizeof(pt));
pt.target = target;
pt.format = format;
pt.last_level = last_level;
pt.width0 = width0;
pt.height0 = height0;
pt.depth0 = depth0;
pt.array_size = layers;
pt.usage = PIPE_USAGE_DEFAULT;
pt.bind = bind;
-   pt.flags = 0;
+   /* only set this for OpenGL textures, not renderbuffers */
+   pt.flags = PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY;
pt.nr_samples = nr_samples;

newtex = screen->resource_create(screen, );

assert(!newtex || pipe_is_referenced(>reference));

return newtex;
 }




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


[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98172

--- Comment #11 from shinji.suz...@gmail.com ---
Sorry I've made too many mistake in writing. (Should have gone to bed before
writing.) I'll rewrite whole post below.

I'm afraid execution of st_fence_sync() can still race.
Thread-A can run upto
  success = screen->fence_finish(screen, pipe, fence, 0);
and then get preempted and Thread-B can run upto the same location.
And then
  screen->fence_reference(screen, >fence, NULL);
will be executed serially by both threads. If screen->fence_finish()
is thread-safe and return true only for the first invocation then all is fine
but likely it is not true as otherwise we will not be struggling with this
issue.
I think the gist of it is that checking of so->fence and nullifying of it
should be executed atomically. If "if (success)" is replaced with "if (success
&& so->fence)" then the program may behave correctly but I'm still not
comfortable about sreen->fence_finish() being called concurrently.
I'm also concerned that mutual exclusion on ctx->Shared->Mutex may introduce
unnecessarily strict serialization. 
Can't we introduce per sync-object mutex so that excution of checking of
so->fence and nullyfying of it happen atomically?
Is that modification too intrusive? (At least it is unnecessary overhead when
st_fence_sync() is not executed concurrently on the same sync object.)

-- 
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] radeonsi: implement TC-compatible HTILE

2016-10-13 Thread Nicolai Hähnle

On 12.10.2016 15:54, Marek Olšák wrote:

From: Marek Olšák 

so that decompress blits aren't needed and depth texturing needs less
memory bandwidth.

Z16 and Z24 are promoted to Z32_FLOAT by the driver, because TC-compatible
HTILE only supports Z32_FLOAT. This doubles memory footprint for Z16.
The format promotion is not visible to state trackers.

This is part of TC-compatible renderbuffer compression, which has 3 parts:
DCC, HTILE, FMASK. Only TC-compatible FMASK compression is missing now.

I don't see a measurable increase in performance though.

(I tested Talos Principle and DiRT: Showdown, the latter is improved by
 0.5%, which is almost noise, and it originally used layered Z16,
 so at least we know that Z16 promoted to Z32F isn't slower now)


Reviewed-by: Nicolai Hähnle 


---
 src/gallium/drivers/radeon/r600_pipe_common.h  |  3 ++
 src/gallium/drivers/radeon/r600_texture.c  | 67 ++
 src/gallium/drivers/radeon/radeon_winsys.h |  4 ++
 src/gallium/drivers/radeonsi/si_blit.c | 11 -
 src/gallium/drivers/radeonsi/si_descriptors.c  |  7 ++-
 src/gallium/drivers/radeonsi/si_shader.c   | 18 ++-
 src/gallium/drivers/radeonsi/si_state.c| 39 +--
 src/gallium/drivers/radeonsi/si_state_draw.c   |  3 +-
 src/gallium/winsys/amdgpu/drm/amdgpu_surface.c | 57 --
 9 files changed, 185 insertions(+), 24 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 290b228..5cfcad6 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -238,27 +238,29 @@ struct r600_cmask_info {
unsigned yalign;
unsigned slice_tile_max;
unsigned base_address_reg;
 };

 struct r600_htile_info {
unsigned pitch;
unsigned height;
unsigned xalign;
unsigned yalign;
+   unsigned alignment;
 };

 struct r600_texture {
struct r600_resourceresource;

uint64_tsize;
unsignednum_level0_transfers;
+   enum pipe_formatdb_render_format;
boolis_depth;
booldb_compatible;
boolcan_sample_z;
boolcan_sample_s;
unsigneddirty_level_mask; /* each bit says if 
that mipmap is compressed */
unsignedstencil_dirty_level_mask; /* each bit 
says if that mipmap is compressed */
struct r600_texture *flushed_depth_texture;
struct radeon_surf  surface;

/* Colorbuffer compression and fast clear. */
@@ -266,20 +268,21 @@ struct r600_texture {
struct r600_cmask_info  cmask;
struct r600_resource*cmask_buffer;
uint64_tdcc_offset; /* 0 = disabled */
unsignedcb_color_info; /* fast clear enable bit 
*/
unsignedcolor_clear_value[2];
unsignedlast_msaa_resolve_target_micro_mode;

/* Depth buffer compression and fast clear. */
struct r600_htile_info  htile;
struct r600_resource*htile_buffer;
+   booltc_compatible_htile;
booldepth_cleared; /* if it was cleared at 
least once */
float   depth_clear_value;
boolstencil_cleared; /* if it was cleared 
at least once */
uint8_t stencil_clear_value;

boolnon_disp_tiling; /* R600-Cayman only */

/* Whether the texture is a displayable back buffer and needs DCC
 * decompression, which is expensive. Therefore, it's enabled only
 * if statistics suggest that it will pay off and it's allocated
diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index 57cdbcf..625d091 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -185,21 +185,22 @@ static unsigned r600_texture_get_offset(struct 
r600_texture *rtex, unsigned leve
return rtex->surface.level[level].offset +
   box->z * rtex->surface.level[level].slice_size +
   box->y / util_format_get_blockheight(format) * 
rtex->surface.level[level].pitch_bytes +
   box->x / util_format_get_blockwidth(format) * 
util_format_get_blocksize(format);
 }

 static int r600_init_surface(struct r600_common_screen *rscreen,
 struct radeon_surf *surface,
 const struct pipe_resource *ptex,
 

Re: [Mesa-dev] [PATCH 00/15] GLSL memory allocation rework for faster compilation

2016-10-13 Thread Tapani Pälli

On 10/13/2016 04:20 PM, Juha-Pekka Heikkila wrote:
I forgot to reply here on the list, I've just been talking about this 
with Tapani face to face.


My series rebased and fixed on top of mesa master branch from 
yesterday is here

https://github.com/juhapekka/juha_mesaexperimentals/tree/jenkins

Tapani was already taking rebased patches from above branch.

I originally stopped working on this set because I felt there was too 
much uncertainty if all places needed to be fixed could be found 
easily. Anyway, if you skip my patch for changes in glsl please check 
you have all places somehow handled which I had patched. All those 
patched places I dug up with Valgrind so they're 'real deal' where 
will get segfaults.




I have now all CI regressions (there were 26 in total) passing with this 
set:


https://cgit.freedesktop.org/~tpalli/mesa/log/?h=jenkins

but I'm planning still todo some validation with apps too, as you 
mentioned today as example Manhattan used to trigger some issues.



/Juha-Pekka

On 10.10.2016 14:52, Marek Olšák wrote:

I prefer some of my GLSL fixes in 1-4 over JP's changes, because they
seem cleaner to me.

Marek


On Oct 10, 2016 1:38 PM, "Tapani Pälli" > wrote:



On 10/10/2016 02:27 PM, Marek Olšák wrote:

On Mon, Oct 10, 2016 at 1:25 PM, Tapani Pälli
> wrote:



On 10/10/2016 01:38 PM, Marek Olšák wrote:


On Mon, Oct 10, 2016 at 12:33 PM, Marek Olšák
> wrote:


On Mon, Oct 10, 2016 at 7:58 AM, Tapani Pälli
>

wrote:




On 10/08/2016 06:58 PM, Jason Ekstrand wrote:



FYI, we use ralloc for a lot more than just
the glsl compiler so the
first few changes make me a bit nervous.
There was someone working on
making our driver more I
undefined-memory-friendly but I don't know
what
happened to those patches.




There's bunch of patches like that in this 
series:

https://lists.freedesktop.org/archives/mesa-dev/2016-June/120445.html


it looks like it just never landed as would have
required more testing
on
misc drivers?



We can land at least some of the patches from that
series. We still
have to replace all non-GLSL uses of
DECLARE_RALLOC.. with
DECLARE_RZALLOC.



BTW, people can still give Rbs on all patches except 5.
This rzalloc
thing isn't an issue and can be dealt with in a separate
series (it
can be done after this series lands).



I agree these issues do not block review of the series. We
just need to make
sure it is absolutely safe before landing.

As concrete example I got following segfault when I applied
this series
which is directly related to rzalloc issues. This was with
'shader_freeze'
program, description in bug #94477 has link and build
instructions for this
if you want to try. When I applied JP's patches 4,5,6 (nir,
i965_vec4,
i965_fs changes) this segfault disappears.


I meant that this series is safe to land without patch 5. Did
you test
it without patch 5?


Ah sorry I managed to miss that. Now I did test and when reverting
patch 5 this test passes fine. Makes sense to do patch 5 as a
separate step when JP's changes land.

// Tapani



___
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] [Bug 98169] lm_sensors hud option crashes unigine heaven

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98169

--- Comment #30 from Steven Toth  ---
Christoph, based on feedback from the mailing list, I made some changes to use
the MESA internal reference counting mechanisms which makes sensor and other
cleanup a little more robust.

The patch tests fine for me with glxgears, but due to some hardware issues I no
longer have access to a working unigine environment.

If you have a moment, can you please remove all of my earlier patches and apply
the mutex-reference.patch and check that it's still working for with unigine?

Specifically, that you still have values in all graphs and that you no longer
see the sensor_cleanup() crash?

Many thanks.

-- 
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] Required-for-rendering internal formats

2016-10-13 Thread Erik Faye-Lund
On Thu, Oct 13, 2016 at 5:35 PM, Nicolai Hähnle  wrote:
> On 13.10.2016 17:15, Ilia Mirkin wrote:
>>
>> Anyone else have opinions on this? Should st/mesa be adding
>> PIPE_BIND_RENDER_TARGET for all textures of the internal formats
>> listed in table 8.12? (Which would, in this case, force RGBA8 to be
>> used since RGBA4 is non-renderable.) Or is it perfectly legal for a
>> format to be not renderable when used as a texture vs renderbuffer?

I have some old patches laying around that I've been intending to
upstream for a while in this area:

https://github.com/kusma/mesa/commits/color_renderable_fix

IIRC, some work has landed since that made some of the patches
obsolete, so take things with a grain of salt ;)

>
> I think the spec is pretty clear that the "req.rend." column of that table
> is only for renderbuffers.
>
> It's a lot less clear about what really matters for this question. In
> section 9.4.3 (Required Framebuffer Formats), there's the curious sentence:
>
> Each color attachment may be in any of the color-renderable
> formats described in section 9.4 (although implementations
> are not required to support creation of attachments in all
> color-renderable formats).
>
> Color-renderable formats are those which have a checkmark in the CR column
> according to section 9.4. That means pretty much _all_ non-compressed
> formats (except for the shared exponents one). I doubt that the intention is
> to force stuff like R3_G3_B2 to be renderable.
>
> It's kind of funny that the sentence says that the attachments may be in any
> of these formats, but you may not be able to create the attachments?

You can create any attachments as long as you can create the texture
or renderbuffer for them. And all formats are marked as either req.ren
or req.tex. So any format might be attached. But that doesn't mean it
can be *rendered* to.

> I think what that's trying to say is that the implementation MUST reject
> color attachments that are not CR according to table 8.12, and it MAY reject
> color attachments of any format it likes.
>

In essence, yes. But the details are of course a bit more complicated.

Everything marked as CR is "color renderable" according to OpenGL.
However, being "color renderable" isn't *enough* to guarantee that it
can be rendered to, because of framebuffer completeness:

Section 9.4.2 ("Whole Framebuffer Completeness") of the OpenGL 4.5
core spec says:

"Although the GL defines a wide variety of internal formats for
framebufferattachable images, such as texture images and renderbuffer
images, some implementations may not support rendering to particular
combinations of internal formats. If the combination of formats of the
images attached to a framebuffer object are not supported by the
implementation, then the framebuffer is not complete under the clause
labeled FRAMEBUFFER_UNSUPPORTED."

So, using a non-CR format produces
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT, and using a non-supported CR
format produces FRAMEBUFFER_UNSUPPORTED.

> So I tend to side with the interpretation that exposing RGBA4 as texture
> format but not allowing to render to it is okay by the spec, and the
> application has a bug.

This is my interpretation as well.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] radv: Use new image load/store intrinsic signatures

2016-10-13 Thread Kai Wasserbäch
Disregard this, the mbox file only contained the second patch. Sorry for the 
noise.

Kai Wasserbäch wrote on 13.10.2016 19:20:
> Dear Tom,
> just FYI: this fails to apply on top of master
> (761388a0eb586b1dcaec063ee561056ed132dc1a). git am chokes on the
> visit_image_store() hunk for me. Attached is a "refreshed" version, which
> applies for me. I hope I didn't butcher anything inadvertently.
> 
> Cheers,
> Kai



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] [PATCH 2/2] radeonsi: adjust and clean up Z_ORDER and EXEC_ON_x settings

2016-10-13 Thread Nicolai Hähnle

The series is

Reviewed-by: Nicolai Hähnle 

On 12.10.2016 23:19, Marek Olšák wrote:

From: Marek Olšák 

The table was copied from the Vulkan driver. The comment lines are as long
as the table for cosmetic reasons.
---
 src/gallium/drivers/radeonsi/si_shader.h|  1 -
 src/gallium/drivers/radeonsi/si_state_shaders.c | 53 +++--
 2 files changed, 32 insertions(+), 22 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.h 
b/src/gallium/drivers/radeonsi/si_shader.h
index f2618ac..b07210c 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -432,21 +432,20 @@ struct si_shader {

struct si_shader_part   *prolog;
struct si_shader_part   *epilog;

struct si_shader*gs_copy_shader;
struct si_pm4_state *pm4;
struct r600_resource*bo;
struct r600_resource*scratch_bo;
union si_shader_key key;
boolis_binary_shared;
-   unsignedz_order;

/* The following data is all that's needed for binary shaders. */
struct radeon_shader_binary binary;
struct si_shader_config config;
struct si_shader_info   info;

/* Shader key + LLVM IR + disassembly + statistics.
 * Generated for debug contexts only.
 */
char*shader_log;
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index be5c659..d339b84 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -800,34 +800,20 @@ static void si_shader_ps(struct si_shader *shader)

si_pm4_set_reg(pm4, R_00B028_SPI_SHADER_PGM_RSRC1_PS,
   S_00B028_VGPRS((shader->config.num_vgprs - 1) / 4) |
   S_00B028_SGPRS((shader->config.num_sgprs - 1) / 8) |
   S_00B028_DX10_CLAMP(1) |
   S_00B028_FLOAT_MODE(shader->config.float_mode));
si_pm4_set_reg(pm4, R_00B02C_SPI_SHADER_PGM_RSRC2_PS,
   S_00B02C_EXTRA_LDS_SIZE(shader->config.lds_size) |
   S_00B02C_USER_SGPR(SI_PS_NUM_USER_SGPR) |
   S_00B32C_SCRATCH_EN(shader->config.scratch_bytes_per_wave 
> 0));
-
-   /* DON'T USE EARLY_Z_THEN_RE_Z !!!
-*
-* It decreases performance by 15% in DiRT: Showdown on Ultra settings.
-* And it has pretty complex shaders.
-*
-* Shaders with side effects that must execute independently of the
-* depth test require LATE_Z.
-*/
-   if (info->writes_memory &&
-   !info->properties[TGSI_PROPERTY_FS_EARLY_DEPTH_STENCIL])
-   shader->z_order = V_02880C_LATE_Z;
-   else
-   shader->z_order = V_02880C_EARLY_Z_THEN_LATE_Z;
 }

 static void si_shader_init_pm4_state(struct si_screen *sscreen,
  struct si_shader *shader)
 {
switch (shader->selector->type) {
case PIPE_SHADER_VERTEX:
if (shader->key.vs.as_ls)
si_shader_ls(shader);
else if (shader->key.vs.as_es)
@@ -1364,26 +1350,52 @@ static void *si_create_shader_selector(struct 
pipe_context *ctx,
case TGSI_FS_DEPTH_LAYOUT_GREATER:
sel->db_shader_control |=

S_02880C_CONSERVATIVE_Z_EXPORT(V_02880C_EXPORT_GREATER_THAN_Z);
break;
case TGSI_FS_DEPTH_LAYOUT_LESS:
sel->db_shader_control |=

S_02880C_CONSERVATIVE_Z_EXPORT(V_02880C_EXPORT_LESS_THAN_Z);
break;
}

-   if (sel->info.properties[TGSI_PROPERTY_FS_EARLY_DEPTH_STENCIL])
-   sel->db_shader_control |= S_02880C_DEPTH_BEFORE_SHADER(1);
+   /* Z_ORDER, EXEC_ON_HIER_FAIL and EXEC_ON_NOOP should be set as 
following:
+*
+*   | early Z/S | writes_mem | allow_ReZ? |  Z_ORDER   | 
EXEC_ON_HIER_FAIL | EXEC_ON_NOOP
+* 
--|---||||---|-
+* 1a|   false   |   false|   true | EarlyZ_Then_ReZ|   
  0 | 0
+* 1b|   false   |   false|   false| EarlyZ_Then_LateZ  |   
  0 | 0
+* 2 |   false   |   true |   n/a  |   LateZ|   
  1 | 0
+* 3 |   true|   false|   n/a  | EarlyZ_Then_LateZ  |   
  0 | 0
+* 4 |   true|   true |   n/a  | EarlyZ_Then_LateZ  |   
  0 | 1
+*
+* In cases 3 and 4, HW will force Z_ORDER to EarlyZ regardless of 
what's set in the register.
+* In case 2, 

Re: [Mesa-dev] [PATCH 1/5] st/va: Return more useful config attributes

2016-10-13 Thread Andy Furniss

Mark Thompson wrote:

On 13/10/16 08:20, Christian König wrote:

Am 13.10.2016 um 00:52 schrieb Mark Thompson:

The encoder attributes are needed for a user of the encoder to be
able to configure it sensibly without internal knowledge.


Reviewed-by: Christian König  for the whole series.

Do you have commit access?


I do not.  Please do push this for me once all appropriate people are happy 
with it.


Seems not to regress anything, but there are still differences vs gstreamer.

I guess the poc fix now allows JM decoder not to bail, but that allows
me to see some other issue around I frames. I haven't had time too look
properly why, but guessing it could be that avconv sends 
desc.h264enc.gop_size

every I frame, but gst just once.

I don't know if you'll even see this on bonaire as my tonga possibly
hits different code - I mean in src/gallium/drivers/radeon/ there is
radeon_vce_40_2_2.c
radeon_vce_50.c
radeon_vce_52.c
and maybe these are used depending on vce firmware version and do
different things for different h/w.

The issue I see with JM is shown below - the file seems to play OK.
There may be another (I guess pre-existing) issue around 1080/1088
affecting transcoding with both avconv and gst, but one thing at a
time.

This is with -g 30 and doesn't happen with gstreamer.

--
  Frame  POC  Pic#   QPSnrY SnrU SnrV   Y:U:V Time(ms)
--
0(IDR)0 033 4:2:0  90
0( P )1 129 4:2:0  57
1( P )2 229 4:2:0  55
1( P )3 328 4:2:0  57
2( P )4 428 4:2:0  59
2( P )5 528 4:2:0  57

snip

00014( P )   292923 4:2:0  70
00015( P )   303024 4:2:0  66
0(IDR)   -1 023 4:2:0 129
0( P )0 124 4:2:0  59
0( P )1 225 4:2:0  56
1( P )2 325 4:2:0  58
1( P )3 425 4:2:0  57

snip
00014( P )   282926 4:2:0  59
00014( P )   293024 4:2:0  65
-0001(IDR)   -2 024 4:2:0 129
0( P )   -1 125 4:2:0  59
0( P )0 225 4:2:0  58
0( P )1 325 4:2:0  59

snip
00013( P )   272924 4:2:0  65
00014( P )   283024 4:2:0  67
-0001(IDR)   -3 024 4:2:0 130
-0001( P )   -2 125 4:2:0  59
0( P )   -1 225 4:2:0  58
0( P )0 325 4:2:0  58
0( P )1 425 4:2:0  57




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


Re: [Mesa-dev] [PATCH 2/2] radv: Use new image load/store intrinsic signatures

2016-10-13 Thread Kai Wasserbäch
Dear Tom,
just FYI: this fails to apply on top of master
(761388a0eb586b1dcaec063ee561056ed132dc1a). git am chokes on the
visit_image_store() hunk for me. Attached is a "refreshed" version, which
applies for me. I hope I didn't butcher anything inadvertently.

Cheers,
Kai


Tom Stellard wrote on 13.10.2016 17:21:
> These were changed in LLVM r284024.
> ---
>  src/amd/common/ac_nir_to_llvm.c | 131 
> 
>  1 file changed, 107 insertions(+), 24 deletions(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 9c764c7..4fba7d3 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -2296,13 +2296,73 @@ static LLVMValueRef get_image_coords(struct 
> nir_to_llvm_context *ctx,
>   return res;
>  }
>  
> +static void build_type_name_for_intr(
> +LLVMTypeRef type,
> +char *buf, unsigned bufsize)
> +{
> +LLVMTypeRef elem_type = type;
> +
> +assert(bufsize >= 8);
> +
> +if (LLVMGetTypeKind(type) == LLVMVectorTypeKind) {
> +int ret = snprintf(buf, bufsize, "v%u",
> +LLVMGetVectorSize(type));
> +if (ret < 0) {
> +char *type_name = LLVMPrintTypeToString(type);
> +fprintf(stderr, "Error building type name for: %s\n",
> +type_name);
> +return;
> +}
> +elem_type = LLVMGetElementType(type);
> +buf += ret;
> +bufsize -= ret;
> +}
> +switch (LLVMGetTypeKind(elem_type)) {
> +default: break;
> +case LLVMIntegerTypeKind:
> +snprintf(buf, bufsize, "i%d", 
> LLVMGetIntTypeWidth(elem_type));
> +break;
> +case LLVMFloatTypeKind:
> +snprintf(buf, bufsize, "f32");
> +break;
> +case LLVMDoubleTypeKind:
> +snprintf(buf, bufsize, "f64");
> +break;
> +}
> +}
> +
> +static void get_image_intr_name(const char *base_name,
> +LLVMTypeRef data_type,
> +LLVMTypeRef coords_type,
> +LLVMTypeRef rsrc_type,
> +char *out_name, unsigned out_len)
> +{
> +char coords_type_name[8];
> +
> +build_type_name_for_intr(coords_type, coords_type_name,
> +sizeof(coords_type_name));
> +
> +if (HAVE_LLVM <= 0x0309) {
> +snprintf(out_name, out_len, "%s.%s", base_name, 
> coords_type_name);
> +} else {
> +char data_type_name[8];
> +char rsrc_type_name[8];
> +
> +build_type_name_for_intr(data_type, data_type_name,
> +sizeof(data_type_name));
> +build_type_name_for_intr(rsrc_type, rsrc_type_name,
> +sizeof(rsrc_type_name));
> +snprintf(out_name, out_len, "%s.%s.%s.%s", base_name,
> + data_type_name, coords_type_name, rsrc_type_name);
> +}
> +}
> +
>  static LLVMValueRef visit_image_load(struct nir_to_llvm_context *ctx,
>nir_intrinsic_instr *instr)
>  {
>   LLVMValueRef params[7];
>   LLVMValueRef res;
> - char intrinsic_name[32];
> - char coords_type[8];
> + char intrinsic_name[64];
>   const nir_variable *var = instr->variables[0]->var;
>   const struct glsl_type *type = var->type;
>   if(instr->variables[0]->deref.child)
> @@ -2322,23 +2382,35 @@ static LLVMValueRef visit_image_load(struct 
> nir_to_llvm_context *ctx,
>   res = trim_vector(ctx, res, instr->dest.ssa.num_components);
>   res = to_integer(ctx, res);
>   } else {
> - bool da = glsl_sampler_type_is_array(type) ||
> -   glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
> + bool is_da = glsl_sampler_type_is_array(type) ||
> +  glsl_get_sampler_dim(type) == 
> GLSL_SAMPLER_DIM_CUBE;
>   bool add_frag_pos = glsl_get_sampler_dim(type) == 
> GLSL_SAMPLER_DIM_SUBPASS;
> + LLVMValueRef da = is_da ? ctx->i32one : ctx->i32zero;
> + LLVMValueRef glc = LLVMConstInt(ctx->i1, 0, false);
> + LLVMValueRef slc = LLVMConstInt(ctx->i1, 0, false);
>  
>   params[0] = get_image_coords(ctx, instr, add_frag_pos);
>   params[1] = get_sampler_desc(ctx, instr->variables[0], 
> DESC_IMAGE);
>   params[2] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
> - params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
> - params[4] = da ? ctx->i32one : ctx->i32zero; /* da */
> - params[5] = LLVMConstInt(ctx->i1, 0, false);  /* 

Re: [Mesa-dev] [RFC] EGL_MESA_platform_surfaceless

2016-10-13 Thread Chad Versace
On Fri 23 Sep 2016, Chad Versace wrote:

> diff --git a/docs/specs/EGL_MESA_platform_surfaceless.txt 
> b/docs/specs/EGL_MESA_platform_surfaceless.txt
> new file mode 100644
> index 000..b700370
> --- /dev/null
> +++ b/docs/specs/EGL_MESA_platform_surfaceless.txt
> @@ -0,0 +1,108 @@

> +Name Strings
> +
> +EGL_MESA_platform_surfaceless

> +New Tokens
> +
> +Accepted as the  argument of eglGetPlatformDisplay:
> +
> +EGL_PLATFORM_SURFACELESS_MESA   0xTODO

I plan to reserve 0x3DD from the EGL registry for this enum. Speak up if
this causes any problem.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radeonsi: clear DB_RENDER_OVERRIDE

2016-10-13 Thread Marek Olšák
From: Marek Olšák 

Vulkan doesn't set these fields even though it doesn't use HiS.
HiS is disabled by programming DB_SRESULTS_COMPARE_STATEn to 0.
---
 src/gallium/drivers/radeonsi/si_state.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index b23749c..732f9e9 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3918,23 +3918,21 @@ static void si_init_config(struct si_context *sctx)
   S_028230_ER_LINE_LR(0x1A) |
   S_028230_ER_LINE_RL(0x26) |
   S_028230_ER_LINE_TB(0xA) |
   S_028230_ER_LINE_BT(0xA));
/* PA_SU_HARDWARE_SCREEN_OFFSET must be 0 due to hw bug on SI */
si_pm4_set_reg(pm4, R_028234_PA_SU_HARDWARE_SCREEN_OFFSET, 0);
si_pm4_set_reg(pm4, R_028820_PA_CL_NANINF_CNTL, 0);
si_pm4_set_reg(pm4, R_028AC0_DB_SRESULTS_COMPARE_STATE0, 0x0);
si_pm4_set_reg(pm4, R_028AC4_DB_SRESULTS_COMPARE_STATE1, 0x0);
si_pm4_set_reg(pm4, R_028AC8_DB_PRELOAD_CONTROL, 0x0);
-   si_pm4_set_reg(pm4, R_02800C_DB_RENDER_OVERRIDE,
-  S_02800C_FORCE_HIS_ENABLE0(V_02800C_FORCE_DISABLE) |
-  S_02800C_FORCE_HIS_ENABLE1(V_02800C_FORCE_DISABLE));
+   si_pm4_set_reg(pm4, R_02800C_DB_RENDER_OVERRIDE, 0);
 
si_pm4_set_reg(pm4, R_028400_VGT_MAX_VTX_INDX, ~0);
si_pm4_set_reg(pm4, R_028404_VGT_MIN_VTX_INDX, 0);
si_pm4_set_reg(pm4, R_028408_VGT_INDX_OFFSET, 0);
 
if (sctx->b.chip_class >= CIK) {
si_pm4_set_reg(pm4, R_00B51C_SPI_SHADER_PGM_RSRC3_LS, 
S_00B51C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B41C_SPI_SHADER_PGM_RSRC3_HS, 0);
si_pm4_set_reg(pm4, R_00B31C_SPI_SHADER_PGM_RSRC3_ES, 
S_00B31C_CU_EN(0x));
si_pm4_set_reg(pm4, R_00B21C_SPI_SHADER_PGM_RSRC3_GS, 
S_00B21C_CU_EN(0x));
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] clover: Allow OpenCL version override

2016-10-13 Thread Vedran Miletić
On 10/07/2016 12:05 PM, Serge Martin wrote:
> On Thursday 06 October 2016 16:26:21 Vedran Miletić wrote:
>> CLOVER_CL_VERSION_OVERRIDE allows overriding default OpenCL version
>> supported by Clover, analogous to MESA_GL_VERSION_OVERRIDE for OpenGL.
>> CLOVER_CL_C_VERSION_OVERRIDE allows overridng default OpenCL C version.
> 
> Thanks.
> I've made some comments bellow
> 
>> ---
>>  docs/envvars.html | 12 
>>  src/gallium/state_trackers/clover/api/device.cpp  |  4 ++--
>>  src/gallium/state_trackers/clover/api/platform.cpp|  4 ++--
>>  src/gallium/state_trackers/clover/core/device.cpp | 19
>> +++ src/gallium/state_trackers/clover/core/device.hpp |
>>  4 
>>  src/gallium/state_trackers/clover/core/platform.cpp   |  9 +
>>  src/gallium/state_trackers/clover/core/platform.hpp   |  3 +++
>>  src/gallium/state_trackers/clover/core/program.cpp|  4 +++-
>>  src/gallium/state_trackers/clover/llvm/invocation.cpp | 18
>> ++ src/gallium/state_trackers/clover/llvm/invocation.hpp | 
>> 1 +
>>  src/gallium/state_trackers/clover/llvm/util.hpp   |  4 ++--
>>  11 files changed, 71 insertions(+), 11 deletions(-)
>>
>> diff --git a/docs/envvars.html b/docs/envvars.html
>> index cf57ca5..f76827b 100644
>> --- a/docs/envvars.html
>> +++ b/docs/envvars.html
>> @@ -235,6 +235,18 @@ Setting to "tgsi", for example, will print all the TGSI
>> shaders. See src/mesa/state_tracker/st_debug.c for other options.
>>  
>>
>> +Clover state tracker environment variables
>> +
>> +
>> +CLOVER_CL_VERSION_OVERRIDE - allows overriding OpenCL version returned
>> by +clGetPlatformInfo(CL_PLATFORM_VERSION) and
>> +clGetDeviceInfo(CL_DEVICE_VERSION). Note that the setting sets the
>> version +of the platform and all the devices to the same value.
>> +CLOVER_CL_C_VERSION_OVERRIDE - allows overriding OpenCL C version
>> reported +by clGetDeviceInfo(CL_DEVICE_OPENCL_C_VERSION) and the value
>> of the +__OPENCL_VERSION__ macro in the OpenCL compiler.
> 
> I don't think we need CLOVER_CL_C_VERSION_OVERRIDE. 
> CLOVER_CL_VERSION_OVERRIDE 
> should be enough.
> 

I believe we do because with OpenCL 2.1+ the version of OpenCL C is
still 2.0.

>> +
>> +
>>  Softpipe driver environment variables
>>  
>>  SOFTPIPE_DUMP_FS - if set, the softpipe driver will print fragment
>> shaders diff --git a/src/gallium/state_trackers/clover/api/device.cpp
>> b/src/gallium/state_trackers/clover/api/device.cpp index f7bd61b..e23de7a
>> 100644
>> --- a/src/gallium/state_trackers/clover/api/device.cpp
>> +++ b/src/gallium/state_trackers/clover/api/device.cpp
>> @@ -301,7 +301,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info
>> param, break;
>>
>> case CL_DEVICE_VERSION:
>> -  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
>> +  buf.as_string() = "OpenCL " + dev.opencl_version() + " Mesa "
>> PACKAGE_VERSION #ifdef MESA_GIT_SHA1
>>  " (" MESA_GIT_SHA1 ")"
>>  #endif
>> @@ -355,7 +355,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info
>> param, break;
>>
>> case CL_DEVICE_OPENCL_C_VERSION:
>> -  buf.as_string() = "OpenCL C 1.1 ";
>> +  buf.as_string() = "OpenCL C " + dev.opencl_c_version() + " ";
>>break;
>>
>> case CL_DEVICE_PARENT_DEVICE:
>> diff --git a/src/gallium/state_trackers/clover/api/platform.cpp
>> b/src/gallium/state_trackers/clover/api/platform.cpp index b1b1fdf..f344ec8
>> 100644
>> --- a/src/gallium/state_trackers/clover/api/platform.cpp
>> +++ b/src/gallium/state_trackers/clover/api/platform.cpp
>> @@ -50,7 +50,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform,
>> cl_platform_info param, size_t size, void *r_buf, size_t *r_size) try {
>> property_buffer buf { r_buf, size, r_size };
>>
>> -   obj(d_platform);
>> +   auto  = obj(d_platform);
>>
>> switch (param) {
>> case CL_PLATFORM_PROFILE:
>> @@ -58,7 +58,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform,
>> cl_platform_info param, break;
>>
>> case CL_PLATFORM_VERSION:
>> -  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
>> +  buf.as_string() = "OpenCL " + platform.opencl_version() + " Mesa "
> 
> 
> you don't need to add an opencl_version() func to core/plateform,
> it won't be used except here.
> I prefer if we have an util function that would be used here, in device.cpp 
> and invocation.cpp because for the moment this is still a global value.
> 
> 
>> PACKAGE_VERSION #ifdef MESA_GIT_SHA1
>>  " (" MESA_GIT_SHA1 ")"
>>  #endif
>> diff --git a/src/gallium/state_trackers/clover/core/device.cpp
>> b/src/gallium/state_trackers/clover/core/device.cpp index 8825f99..fce6fb3
>> 100644
>> --- a/src/gallium/state_trackers/clover/core/device.cpp
>> +++ b/src/gallium/state_trackers/clover/core/device.cpp
>> @@ -24,6 +24,7 @@
>>  #include "core/platform.hpp"
>>  #include "pipe/p_screen.h"
>>  #include "pipe/p_state.h"
>> +#include "util/u_debug.h"
>>

Re: [Mesa-dev] [RFC] EGL_MESA_platform_surfaceless

2016-10-13 Thread Chad Versace
On Thu 13 Oct 2016, Chad Versace wrote:
> On Fri 23 Sep 2016, Chad Versace wrote:
> 
> > diff --git a/docs/specs/EGL_MESA_platform_surfaceless.txt 
> > b/docs/specs/EGL_MESA_platform_surfaceless.txt
> > new file mode 100644
> > index 000..b700370
> > --- /dev/null
> > +++ b/docs/specs/EGL_MESA_platform_surfaceless.txt
> > @@ -0,0 +1,108 @@
> 
> > +Name Strings
> > +
> > +EGL_MESA_platform_surfaceless
> 
> > +New Tokens
> > +
> > +Accepted as the  argument of eglGetPlatformDisplay:
> > +
> > +EGL_PLATFORM_SURFACELESS_MESA   0xTODO
> 
> I plan to reserve 0x3DD from the EGL registry for this enum. Speak up if
> this causes any problem.

Typo. I meant 0x31DD.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radeonsi: shorten "shader->selector" to "sel" in si_shader_create

2016-10-13 Thread Marek Olšák
From: Marek Olšák 

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

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index b2d7699..e6edd90 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -7850,35 +7850,36 @@ static void si_fix_num_sgprs(struct si_shader *shader)
 {
unsigned min_sgprs = shader->info.num_input_sgprs + 2; /* VCC */
 
shader->config.num_sgprs = MAX2(shader->config.num_sgprs, min_sgprs);
 }
 
 int si_shader_create(struct si_screen *sscreen, LLVMTargetMachineRef tm,
 struct si_shader *shader,
 struct pipe_debug_callback *debug)
 {
-   struct si_shader *mainp = shader->selector->main_shader_part;
+   struct si_shader_selector *sel = shader->selector;
+   struct si_shader *mainp = sel->main_shader_part;
int r;
 
/* LS, ES, VS are compiled on demand if the main part hasn't been
 * compiled for that stage.
 */
if (!mainp ||
-   (shader->selector->type == PIPE_SHADER_VERTEX &&
+   (sel->type == PIPE_SHADER_VERTEX &&
 (shader->key.vs.as_es != mainp->key.vs.as_es ||
  shader->key.vs.as_ls != mainp->key.vs.as_ls)) ||
-   (shader->selector->type == PIPE_SHADER_TESS_EVAL &&
+   (sel->type == PIPE_SHADER_TESS_EVAL &&
 shader->key.tes.as_es != mainp->key.tes.as_es) ||
-   (shader->selector->type == PIPE_SHADER_TESS_CTRL &&
+   (sel->type == PIPE_SHADER_TESS_CTRL &&
 shader->key.tcs.epilog.inputs_to_copy) ||
-   shader->selector->type == PIPE_SHADER_COMPUTE) {
+   sel->type == PIPE_SHADER_COMPUTE) {
/* Monolithic shader (compiled as a whole, has many variants,
 * may take a long time to compile).
 */
r = si_compile_tgsi_shader(sscreen, tm, shader, true, debug);
if (r)
return r;
} else {
/* The shader consists of 2-3 parts:
 *
 * - the middle part is the user shader, it has 1 variant only
@@ -7898,21 +7899,21 @@ int si_shader_create(struct si_screen *sscreen, 
LLVMTargetMachineRef tm,
shader->info.num_input_vgprs = mainp->info.num_input_vgprs;
shader->info.face_vgpr_index = mainp->info.face_vgpr_index;
memcpy(shader->info.vs_output_param_offset,
   mainp->info.vs_output_param_offset,
   sizeof(mainp->info.vs_output_param_offset));
shader->info.uses_instanceid = mainp->info.uses_instanceid;
shader->info.nr_pos_exports = mainp->info.nr_pos_exports;
shader->info.nr_param_exports = mainp->info.nr_param_exports;
 
/* Select prologs and/or epilogs. */
-   switch (shader->selector->type) {
+   switch (sel->type) {
case PIPE_SHADER_VERTEX:
if (!si_shader_select_vs_parts(sscreen, tm, shader, 
debug))
return -1;
break;
case PIPE_SHADER_TESS_CTRL:
if (!si_shader_select_tcs_parts(sscreen, tm, shader, 
debug))
return -1;
break;
case PIPE_SHADER_TESS_EVAL:
if (!si_shader_select_tes_parts(sscreen, tm, shader, 
debug))
@@ -7939,21 +7940,21 @@ int si_shader_create(struct si_screen *sscreen, 
LLVMTargetMachineRef tm,
}
if (shader->epilog) {
shader->config.num_sgprs = 
MAX2(shader->config.num_sgprs,

shader->epilog->config.num_sgprs);
shader->config.num_vgprs = 
MAX2(shader->config.num_vgprs,

shader->epilog->config.num_vgprs);
}
}
 
si_fix_num_sgprs(shader);
-   si_shader_dump(sscreen, shader, debug, shader->selector->info.processor,
+   si_shader_dump(sscreen, shader, debug, sel->info.processor,
   stderr);
 
/* Upload. */
r = si_shader_binary_upload(sscreen, shader);
if (r) {
fprintf(stderr, "LLVM failed to upload shader\n");
return r;
}
 
return 0;
-- 
2.7.4

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


[Mesa-dev] [PATCH 1/2] radv: Fix incorrect comment

2016-10-13 Thread Tom Stellard
---
 src/amd/common/ac_nir_to_llvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index e6ff7c8..9c764c7 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2373,8 +2373,8 @@ static void visit_image_store(struct nir_to_llvm_context 
*ctx,
bool da = glsl_sampler_type_is_array(type) ||
  glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
 
-   params[0] = get_src(ctx, instr->src[2]); /* coords */
-   params[1] = get_image_coords(ctx, instr, false);
+   params[0] = get_src(ctx, instr->src[2]);
+   params[1] = get_image_coords(ctx, instr, false); /* coords */
params[2] = get_sampler_desc(ctx, instr->variables[0], 
DESC_IMAGE);
params[3] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
params[4] = i1false;  /* r128 */
-- 
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] radv: Use new image load/store intrinsic signatures v2

2016-10-13 Thread Tom Stellard
These were changed in LLVM r284024.

v2:
  - Only use float types for vdata of llvm.amdgcn.image.store.  LLVM doesn't
support integer types for this intrinsic.
---
 src/amd/common/ac_nir_to_llvm.c | 133 
 1 file changed, 108 insertions(+), 25 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 9c764c7..56814ec 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2296,13 +2296,73 @@ static LLVMValueRef get_image_coords(struct 
nir_to_llvm_context *ctx,
return res;
 }
 
+static void build_type_name_for_intr(
+LLVMTypeRef type,
+char *buf, unsigned bufsize)
+{
+LLVMTypeRef elem_type = type;
+
+assert(bufsize >= 8);
+
+if (LLVMGetTypeKind(type) == LLVMVectorTypeKind) {
+int ret = snprintf(buf, bufsize, "v%u",
+LLVMGetVectorSize(type));
+if (ret < 0) {
+char *type_name = LLVMPrintTypeToString(type);
+fprintf(stderr, "Error building type name for: %s\n",
+type_name);
+return;
+}
+elem_type = LLVMGetElementType(type);
+buf += ret;
+bufsize -= ret;
+}
+switch (LLVMGetTypeKind(elem_type)) {
+default: break;
+case LLVMIntegerTypeKind:
+snprintf(buf, bufsize, "i%d", LLVMGetIntTypeWidth(elem_type));
+break;
+case LLVMFloatTypeKind:
+snprintf(buf, bufsize, "f32");
+break;
+case LLVMDoubleTypeKind:
+snprintf(buf, bufsize, "f64");
+break;
+}
+}
+
+static void get_image_intr_name(const char *base_name,
+LLVMTypeRef data_type,
+LLVMTypeRef coords_type,
+LLVMTypeRef rsrc_type,
+char *out_name, unsigned out_len)
+{
+char coords_type_name[8];
+
+build_type_name_for_intr(coords_type, coords_type_name,
+sizeof(coords_type_name));
+
+if (HAVE_LLVM <= 0x0309) {
+snprintf(out_name, out_len, "%s.%s", base_name, 
coords_type_name);
+} else {
+char data_type_name[8];
+char rsrc_type_name[8];
+
+build_type_name_for_intr(data_type, data_type_name,
+sizeof(data_type_name));
+build_type_name_for_intr(rsrc_type, rsrc_type_name,
+sizeof(rsrc_type_name));
+snprintf(out_name, out_len, "%s.%s.%s.%s", base_name,
+ data_type_name, coords_type_name, rsrc_type_name);
+}
+}
+
 static LLVMValueRef visit_image_load(struct nir_to_llvm_context *ctx,
 nir_intrinsic_instr *instr)
 {
LLVMValueRef params[7];
LLVMValueRef res;
-   char intrinsic_name[32];
-   char coords_type[8];
+   char intrinsic_name[64];
const nir_variable *var = instr->variables[0]->var;
const struct glsl_type *type = var->type;
if(instr->variables[0]->deref.child)
@@ -2322,23 +2382,35 @@ static LLVMValueRef visit_image_load(struct 
nir_to_llvm_context *ctx,
res = trim_vector(ctx, res, instr->dest.ssa.num_components);
res = to_integer(ctx, res);
} else {
-   bool da = glsl_sampler_type_is_array(type) ||
- glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
+   bool is_da = glsl_sampler_type_is_array(type) ||
+glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE;
bool add_frag_pos = glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS;
+   LLVMValueRef da = is_da ? ctx->i32one : ctx->i32zero;
+   LLVMValueRef glc = LLVMConstInt(ctx->i1, 0, false);
+   LLVMValueRef slc = LLVMConstInt(ctx->i1, 0, false);
 
params[0] = get_image_coords(ctx, instr, add_frag_pos);
params[1] = get_sampler_desc(ctx, instr->variables[0], 
DESC_IMAGE);
params[2] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
-   params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
-   params[4] = da ? ctx->i32one : ctx->i32zero; /* da */
-   params[5] = LLVMConstInt(ctx->i1, 0, false);  /* glc */
-   params[6] = LLVMConstInt(ctx->i1, 0, false);  /* slc */
+   if (HAVE_LLVM <= 0x0309) {
+   params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
+   params[4] = da;
+   params[5] = glc;
+   params[6] = slc;
+   } else {
+

Re: [Mesa-dev] [PATCH] clover: Allow OpenCL version override

2016-10-13 Thread Vedran Miletić
On 10/13/2016 07:45 PM, Vedran Miletić wrote:
> On 10/07/2016 12:05 PM, Serge Martin wrote:
>> On Thursday 06 October 2016 16:26:21 Vedran Miletić wrote:
>>> PACKAGE_VERSION #ifdef MESA_GIT_SHA1
>>>  " (" MESA_GIT_SHA1 ")"
>>>  #endif
>>> diff --git a/src/gallium/state_trackers/clover/core/device.cpp
>>> b/src/gallium/state_trackers/clover/core/device.cpp index 8825f99..fce6fb3
>>> 100644
>>> --- a/src/gallium/state_trackers/clover/core/device.cpp
>>> +++ b/src/gallium/state_trackers/clover/core/device.cpp
>>> @@ -24,6 +24,7 @@
>>>  #include "core/platform.hpp"
>>>  #include "pipe/p_screen.h"
>>>  #include "pipe/p_state.h"
>>> +#include "util/u_debug.h"
>>>
>>>  using namespace clover;
>>>
>>> @@ -48,6 +49,14 @@ device::device(clover::platform ,
>>> pipe_loader_device *ldev) : pipe->destroy(pipe);
>>>throw error(CL_INVALID_DEVICE);
>>> }
>>> +
>>> +   const std::string cl_version_override =
>>> + debug_get_option("CLOVER_CL_VERSION_OVERRIDE",
>>> ""); +   ocl_version = !cl_version_override.empty() ? cl_version_override :
>>> "1.1";
>>
>> This is what the default value of debug_get_option is for, this is 
>> redundant. 
>> You just have to pass "1.1".
>>
>> Also, if we have a util function that statistically keep the value the extra 
>> device variable and funcs are not needed.
>> We may need it if we go for CL 2.0 latter with some devices only advertising 
>> CL 1.2 because of unsupported feature, but not for the moment.
>>
> 
> Thanks for the default value comment, did not know it. Will fix it. I do
> agree with a util function that would return "1.1" until we choose to
> bump it. However I would prefer to have function per-device because we
> will eventually need to do it like that anyway.
> 

On a second thought, I believe you are right on this one. I will simplify.

Regards,
Vedran

-- 
Vedran Miletić
vedran.miletic.net
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] radeonsi: unify the constant load paths

2016-10-13 Thread Marek Olšák
For the series:

Reviewed-by: Marek Olšák 

Marek

On Thu, Oct 13, 2016 at 3:44 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> Remove the split between direct and indirect.
> ---
>  src/gallium/drivers/radeonsi/si_shader.c | 39 
> +---
>  1 file changed, 11 insertions(+), 28 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index 15432b2..34c6eb1 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -1867,66 +1867,49 @@ static LLVMValueRef fetch_constant(
> LLVMValueRef values[4];
> for (chan = 0; chan < TGSI_NUM_CHANNELS; ++chan)
> values[chan] = fetch_constant(bld_base, reg, type, 
> chan);
>
> return lp_build_gather_values(bld_base->base.gallivm, values, 
> 4);
> }
>
> buf = reg->Register.Dimension ? reg->Dimension.Index : 0;
> idx = reg->Register.Index * 4 + swizzle;
>
> -   if (!reg->Register.Indirect && !reg->Dimension.Indirect) {
> -   LLVMValueRef c0, c1, desc;
> -
> -   desc = load_const_buffer_desc(ctx, buf);
> -   c0 = buffer_load_const(ctx, desc,
> -  LLVMConstInt(ctx->i32, idx * 4, 0));
> -
> -   if (!tgsi_type_is_64bit(type))
> -   return bitcast(bld_base, type, c0);
> -   else {
> -   c1 = buffer_load_const(ctx, desc,
> -  LLVMConstInt(ctx->i32,
> -   (idx + 1) * 4, 
> 0));
> -   return radeon_llvm_emit_fetch_64bit(bld_base, type,
> -   c0, c1);
> -   }
> -   }
> -
> if (reg->Register.Dimension && reg->Dimension.Indirect) {
> LLVMValueRef ptr = LLVMGetParam(ctx->radeon_bld.main_fn, 
> SI_PARAM_CONST_BUFFERS);
> LLVMValueRef index;
> index = get_bounded_indirect_index(ctx, >DimIndirect,
>reg->Dimension.Index,
>SI_NUM_CONST_BUFFERS);
> bufp = build_indexed_load_const(ctx, ptr, index);
> } else
> bufp = load_const_buffer_desc(ctx, buf);
>
> -   addr = ctx->radeon_bld.soa.addr[ireg->Index][ireg->Swizzle];
> -   addr = LLVMBuildLoad(base->gallivm->builder, addr, "load addr reg");
> -   addr = lp_build_mul_imm(_base->uint_bld, addr, 16);
> -   addr = lp_build_add(_base->uint_bld, addr,
> -   lp_build_const_int32(base->gallivm, idx * 4));
> +   if (reg->Register.Indirect) {
> +   addr = ctx->radeon_bld.soa.addr[ireg->Index][ireg->Swizzle];
> +   addr = LLVMBuildLoad(base->gallivm->builder, addr, "load addr 
> reg");
> +   addr = lp_build_mul_imm(_base->uint_bld, addr, 16);
> +   addr = lp_build_add(_base->uint_bld, addr,
> +   lp_build_const_int32(base->gallivm, idx * 
> 4));
> +   } else {
> +   addr = LLVMConstInt(ctx->i32, idx * 4, 0);
> +   }
>
> result = buffer_load_const(ctx, bufp, addr);
>
> if (!tgsi_type_is_64bit(type))
> result = bitcast(bld_base, type, result);
> else {
> LLVMValueRef addr2, result2;
> -   addr2 = ctx->radeon_bld.soa.addr[ireg->Index][ireg->Swizzle];
> -   addr2 = LLVMBuildLoad(base->gallivm->builder, addr2, "load 
> addr reg2");
> -   addr2 = lp_build_mul_imm(_base->uint_bld, addr2, 16);
> -   addr2 = lp_build_add(_base->uint_bld, addr2,
> -lp_build_const_int32(base->gallivm, (idx 
> + 1) * 4));
>
> +   addr2 = lp_build_add(_base->uint_bld, addr,
> +LLVMConstInt(ctx->i32, 4, 0));
> result2 = buffer_load_const(ctx, bufp, addr2);
>
> result = radeon_llvm_emit_fetch_64bit(bld_base, type,
>   result, result2);
> }
> return result;
>  }
>
>  /* Upper 16 bits must be zero. */
>  static LLVMValueRef si_llvm_pack_two_int16(struct gallivm_state *gallivm,
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] gallium/hud: Sensor extension is segfaulting.

2016-10-13 Thread Steven Toth
Round two of the patchset, incorporating feedback
from nhaeh...@gmail.com

The fixes in this set address bugfix #68169, HUD crashing
when testing with unigine (heaven).

The bug also manifested itself as a lack of data in
HUD charts when multiple instanced were created and
destroyed in a specific order, a use case not witnessed
with glxgears.

These patches:
1. mutex protect the internal object lists.
2. reference count object access for destruction purposes.

Patchset tested with glxgears/demo and unigine.

Signed-off-by: Steven Toth 
---
 src/gallium/auxiliary/hud/hud_cpufreq.c  | 33 ++
 src/gallium/auxiliary/hud/hud_diskstat.c | 39 ++
 src/gallium/auxiliary/hud/hud_nic.c  | 37 +
 src/gallium/auxiliary/hud/hud_sensors_temp.c | 41 ++--
 4 files changed, 125 insertions(+), 25 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_cpufreq.c 
b/src/gallium/auxiliary/hud/hud_cpufreq.c
index 4501bbb..e193568 100644
--- a/src/gallium/auxiliary/hud/hud_cpufreq.c
+++ b/src/gallium/auxiliary/hud/hud_cpufreq.c
@@ -37,6 +37,8 @@
 #include "util/list.h"
 #include "os/os_time.h"
 #include "util/u_memory.h"
+#include "util/u_inlines.h"
+#include "os/os_thread.h"
 #include 
 #include 
 #include 
@@ -57,21 +59,28 @@ struct cpufreq_info
char sysfs_filename[128];
uint64_t KHz;
uint64_t last_time;
+   struct pipe_reference refcnt;
 };
 
 static int gcpufreq_count = 0;
 static struct list_head gcpufreq_list;
+static pipe_mutex gcpufreq_mutex;
 
 static struct cpufreq_info *
 find_cfi_by_index(int cpu_index, int mode)
 {
+   struct cpufreq_info *ret = 0;
+   pipe_mutex_lock(gcpufreq_mutex);
list_for_each_entry(struct cpufreq_info, cfi, _list, list) {
   if (cfi->mode != mode)
  continue;
-  if (cfi->cpu_index == cpu_index)
- return cfi;
+  if (cfi->cpu_index == cpu_index) {
+ ret = cfi;
+ break;
+  }
}
-   return 0;
+   pipe_mutex_unlock(gcpufreq_mutex);
+   return ret;
 }
 
 static int
@@ -116,8 +125,14 @@ static void
 free_query_data(void *p)
 {
struct cpufreq_info *cfi = (struct cpufreq_info *)p;
-   list_del(>list);
-   FREE(cfi);
+   /* atomic dec */
+   if (pipe_reference(>refcnt, NULL)) {
+  pipe_mutex_lock(gcpufreq_mutex);
+  list_del(>list);
+  gcpufreq_count--;
+  pipe_mutex_unlock(gcpufreq_mutex);
+  FREE(cfi);
+   }
 }
 
 /**
@@ -159,6 +174,7 @@ hud_cpufreq_graph_install(struct hud_pane *pane, int 
cpu_index,
   return;
}
 
+   pipe_reference(NULL, >refcnt); /* atomic inc */
gr->query_data = cfi;
gr->query_new_value = query_cfi_load;
 
@@ -180,8 +196,12 @@ add_object(const char *name, const char *fn, int objmode, 
int cpu_index)
strcpy(cfi->sysfs_filename, fn);
cfi->mode = objmode;
cfi->cpu_index = cpu_index;
+   pipe_reference_init(>refcnt, 1);
+
+   pipe_mutex_lock(gcpufreq_mutex);
list_addtail(>list, _list);
gcpufreq_count++;
+   pipe_mutex_unlock(gcpufreq_mutex);
 }
 
 /**
@@ -205,6 +225,7 @@ hud_get_num_cpufreq(bool displayhelp)
/* Scan /sys/devices.../cpu, for every object type we support, create
 * and persist an object to represent its different metrics.
 */
+   pipe_mutex_init(gcpufreq_mutex);
list_inithead(_list);
DIR *dir = opendir("/sys/devices/system/cpu");
if (!dir)
@@ -240,6 +261,7 @@ hud_get_num_cpufreq(bool displayhelp)
}
 
if (displayhelp) {
+  pipe_mutex_lock(gcpufreq_mutex);
   list_for_each_entry(struct cpufreq_info, cfi, _list, list) {
  char line[128];
  snprintf(line, sizeof(line), "cpufreq-%s-%s",
@@ -249,6 +271,7 @@ hud_get_num_cpufreq(bool displayhelp)
 
  puts(line);
   }
+  pipe_mutex_unlock(gcpufreq_mutex);
}
 
return gcpufreq_count;
diff --git a/src/gallium/auxiliary/hud/hud_diskstat.c 
b/src/gallium/auxiliary/hud/hud_diskstat.c
index b248baf..e1748c5 100644
--- a/src/gallium/auxiliary/hud/hud_diskstat.c
+++ b/src/gallium/auxiliary/hud/hud_diskstat.c
@@ -35,7 +35,9 @@
 #include "hud/hud_private.h"
 #include "util/list.h"
 #include "os/os_time.h"
+#include "os/os_thread.h"
 #include "util/u_memory.h"
+#include "util/u_inlines.h"
 #include 
 #include 
 #include 
@@ -73,6 +75,7 @@ struct diskstat_info
char sysfs_filename[128];
uint64_t last_time;
struct stat_s last_stat;
+   struct pipe_reference refcnt;
 };
 
 /* TODO: We don't handle dynamic block device / partition
@@ -81,17 +84,23 @@ struct diskstat_info
  */
 static int gdiskstat_count = 0;
 static struct list_head gdiskstat_list;
+static pipe_mutex gdiskstat_mutex;
 
 static struct diskstat_info *
 find_dsi_by_name(const char *n, int mode)
 {
+   struct diskstat_info *ret = 0;
+   pipe_mutex_lock(gdiskstat_mutex);
list_for_each_entry(struct diskstat_info, dsi, _list, list) {
   if (dsi->mode != mode)
  continue;
-  if (strcasecmp(dsi->name, n) == 0)
- 

Re: [Mesa-dev] [PATCH 2/2] radv: Use new image load/store intrinsic signatures

2016-10-13 Thread Tom Stellard
On Thu, Oct 13, 2016 at 07:20:30PM +0200, Kai Wasserbäch wrote:
> Dear Tom,
> just FYI: this fails to apply on top of master
> (761388a0eb586b1dcaec063ee561056ed132dc1a). git am chokes on the
> visit_image_store() hunk for me. Attached is a "refreshed" version, which
> applies for me. I hope I didn't butcher anything inadvertently.
> 

Hi,

I just sent rebased patches.  Can you try those.

-Tom

> Cheers,
> Kai
> 
> 
> Tom Stellard wrote on 13.10.2016 17:21:
> > These were changed in LLVM r284024.
> > ---
> >  src/amd/common/ac_nir_to_llvm.c | 131 
> > 
> >  1 file changed, 107 insertions(+), 24 deletions(-)
> > 
> > diff --git a/src/amd/common/ac_nir_to_llvm.c 
> > b/src/amd/common/ac_nir_to_llvm.c
> > index 9c764c7..4fba7d3 100644
> > --- a/src/amd/common/ac_nir_to_llvm.c
> > +++ b/src/amd/common/ac_nir_to_llvm.c
> > @@ -2296,13 +2296,73 @@ static LLVMValueRef get_image_coords(struct 
> > nir_to_llvm_context *ctx,
> > return res;
> >  }
> >  
> > +static void build_type_name_for_intr(
> > +LLVMTypeRef type,
> > +char *buf, unsigned bufsize)
> > +{
> > +LLVMTypeRef elem_type = type;
> > +
> > +assert(bufsize >= 8);
> > +
> > +if (LLVMGetTypeKind(type) == LLVMVectorTypeKind) {
> > +int ret = snprintf(buf, bufsize, "v%u",
> > +LLVMGetVectorSize(type));
> > +if (ret < 0) {
> > +char *type_name = LLVMPrintTypeToString(type);
> > +fprintf(stderr, "Error building type name for: 
> > %s\n",
> > +type_name);
> > +return;
> > +}
> > +elem_type = LLVMGetElementType(type);
> > +buf += ret;
> > +bufsize -= ret;
> > +}
> > +switch (LLVMGetTypeKind(elem_type)) {
> > +default: break;
> > +case LLVMIntegerTypeKind:
> > +snprintf(buf, bufsize, "i%d", 
> > LLVMGetIntTypeWidth(elem_type));
> > +break;
> > +case LLVMFloatTypeKind:
> > +snprintf(buf, bufsize, "f32");
> > +break;
> > +case LLVMDoubleTypeKind:
> > +snprintf(buf, bufsize, "f64");
> > +break;
> > +}
> > +}
> > +
> > +static void get_image_intr_name(const char *base_name,
> > +LLVMTypeRef data_type,
> > +LLVMTypeRef coords_type,
> > +LLVMTypeRef rsrc_type,
> > +char *out_name, unsigned out_len)
> > +{
> > +char coords_type_name[8];
> > +
> > +build_type_name_for_intr(coords_type, coords_type_name,
> > +sizeof(coords_type_name));
> > +
> > +if (HAVE_LLVM <= 0x0309) {
> > +snprintf(out_name, out_len, "%s.%s", base_name, 
> > coords_type_name);
> > +} else {
> > +char data_type_name[8];
> > +char rsrc_type_name[8];
> > +
> > +build_type_name_for_intr(data_type, data_type_name,
> > +sizeof(data_type_name));
> > +build_type_name_for_intr(rsrc_type, rsrc_type_name,
> > +sizeof(rsrc_type_name));
> > +snprintf(out_name, out_len, "%s.%s.%s.%s", base_name,
> > + data_type_name, coords_type_name, rsrc_type_name);
> > +}
> > +}
> > +
> >  static LLVMValueRef visit_image_load(struct nir_to_llvm_context *ctx,
> >  nir_intrinsic_instr *instr)
> >  {
> > LLVMValueRef params[7];
> > LLVMValueRef res;
> > -   char intrinsic_name[32];
> > -   char coords_type[8];
> > +   char intrinsic_name[64];
> > const nir_variable *var = instr->variables[0]->var;
> > const struct glsl_type *type = var->type;
> > if(instr->variables[0]->deref.child)
> > @@ -2322,23 +2382,35 @@ static LLVMValueRef visit_image_load(struct 
> > nir_to_llvm_context *ctx,
> > res = trim_vector(ctx, res, instr->dest.ssa.num_components);
> > res = to_integer(ctx, res);
> > } else {
> > -   bool da = glsl_sampler_type_is_array(type) ||
> > - glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
> > +   bool is_da = glsl_sampler_type_is_array(type) ||
> > +glsl_get_sampler_dim(type) == 
> > GLSL_SAMPLER_DIM_CUBE;
> > bool add_frag_pos = glsl_get_sampler_dim(type) == 
> > GLSL_SAMPLER_DIM_SUBPASS;
> > +   LLVMValueRef da = is_da ? ctx->i32one : ctx->i32zero;
> > +   LLVMValueRef glc = LLVMConstInt(ctx->i1, 0, false);
> > +   LLVMValueRef slc = LLVMConstInt(ctx->i1, 0, false);
> >  
> > params[0] = get_image_coords(ctx, instr, add_frag_pos);
> > params[1] = 

Re: [Mesa-dev] [PATCH 05/16] loader: reimplement loader_get_user_preferred_fd via libdrm

2016-10-13 Thread Emil Velikov
On Thursday, 13 October 2016, Emil Velikov  wrote:

> On 12 October 2016 at 18:59, Axel Davy >
> wrote:
> > On 12/10/2016 19:15, Emil Velikov wrote:
> >>
> >> On 11 October 2016 at 19:54, Axel Davy >
> wrote:
> >>>
> >>> On 11/10/2016 20:31, Emil Velikov wrote:
> 
> -   udev = udev_new();
>  -   if (!udev)
>  -  goto prime_clean;
>  +   if (drmGetDevice(default_fd, ) != 0)
>  +  goto err;
> -   default_device_id_path_tag = get_id_path_tag_from_fd(udev,
>  default_fd);
>  -   if (!default_device_id_path_tag)
>  -  goto udev_clean;
>  -
>  -   is_different_device = 1;
>    /* two format are supported:
> * "1": choose any other card than the card used by default.
> * id_path_tag: (for example "pci-_02_00_0") choose the card
> * with this id_path_tag.
> */
>    if (!strcmp(prime,"1")) {
>  -  free(prime);
>  -  prime = strdup(default_device_id_path_tag);
>  -  /* request a card with a different card than the default card
> */
>  -  another_tag = 1;
>  -   } else if (!strcmp(default_device_id_path_tag, prime))
>  -  /* we are to get a new fd (render-node) of the same device */
>  -  is_different_device = 0;
>  +  /* Hmm... detection for 2-7 seems to be broken. Nicely done. */
> >>>
> >>> For DRI2, DRI_PRIME takes a number corresponding to the device number
> as
> >>> configured in xorg (and you have xrandr commands to configure the
> >>> behaviour). This doesn't work with the DRI3 scheme. However for
> >>> retrocompatibility, after several discussions, we decided to let DRI2's
> >>> most
> >>> used command 'DRI_PRIME=1' to still sorta work on DRI3, but the meaning
> >>> changed: DRI_PRIME=1 => 'give me any device that is not the
> >>> compositor/xorg
> >>> device'
> >>
> >> No argument/objection against DRI_PRIME with DRI3, yet the current
> >> hard coded DRI_PRIME=1 _only_ check is iffy. As per the spec there can
> >> be 8 devices (0-8) with 0 always being the xorg/compositor one and 1-7
> >> as 'other' devices. Yet here we only consider 1 and ignore everything
> >> else :-\
> >
> > Do you suggest to have DRI_PRIME=2 (up to 8) be the same than
> DRI_PRIME=1 ?
> >
> Where/how did you read that ? It sounds like you've not read through
> the spec, have you ?
>
> I'm saying that the DRI2(DriverPrime) spec allows for 8 devices in
> total. The 0 one is always the xserver one and you have 7 "others".
> Atm things are completely bonkers, since you have this half a**ed
> broken heuristics which ignores anything but 1. Admittedly there
> aren't many users with 3 or more GPUs but if they were things just
> won't work :-\
>
> Furthermore atm you get a walk over the renderD* (missing D in the
> libudev pattern ;-) devices which does not relate to what you get as
> the 1 device in any other DRI_PRIME use case.
>
> Or in other words, if you use DRI_PRIME=1 with libGL/EGL/gbm you can
> get different result than when doing the same with the
> vdpau/xvmc/omx/vaapi drivers.
>
> Even within libGL (DRI2) things are quite magical , fortunately you
> get the same device if the loader fails.
>
> Or it's likely just me being weird in expect IMG different components of
mesa to behave identically when DRI_PRIME is set ;-)

Either way I'll drop the lovely comments.

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


[Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

2016-10-13 Thread Emil Velikov
On Thursday, 13 October 2016, Mike Lothian > wrote:

> If you recompile llvm and mesa each time, are there any downsides of using
> the shared libs?
>
> How many devs rebuild package X when one of its dependencies has a bug fix
release. And how many think it's a good idea ;-)
Just some food for thought.

I think there were some issues with some programs / games that had clashing
> symbols but I'm not sure if that's still an issue
>
Have not used llvm drivers extensively, ^^ plus fun interactions with
steam's c++ runtime (as mentioned by Kai a while back) are the ones that
come to mind.

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


Re: [Mesa-dev] [PATCH 5/5] st/glsl_to_tgsi: fix [ui]vec[34] conversion to double

2016-10-13 Thread Marek Olšák
For the series:

Reviewed-by: Marek Olšák 

Marek

On Thu, Oct 13, 2016 at 5:13 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> The corresponding opcodes for integers need to be treated the same as F2D.
>
> Fixes GL45-CTS.gpu_shader_fp64.conversions.
> ---
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index 682c034..f49a873 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -862,22 +862,23 @@ glsl_to_tgsi_visitor::emit_asm(ir_instruction *ir, 
> unsigned op,
>dinst->src[j].index++;
>}
>
> if (swz & 1)
>dinst->src[j].swizzle = MAKE_SWIZZLE4(SWIZZLE_Z, 
> SWIZZLE_W, SWIZZLE_Z, SWIZZLE_W);
> else
>dinst->src[j].swizzle = MAKE_SWIZZLE4(SWIZZLE_X, 
> SWIZZLE_Y, SWIZZLE_X, SWIZZLE_Y);
>
>  } else {
> /* some opcodes are special case in what they use as sources
> -  - F2D is a float src0, DLDEXP is integer src1 */
> -   if (op == TGSI_OPCODE_F2D ||
> +  - [FUI]2D/[UI]2I64 is a float/[u]int src0, DLDEXP is 
> integer src1 */
> +   if (op == TGSI_OPCODE_F2D || op == TGSI_OPCODE_U2D || op == 
> TGSI_OPCODE_I2D ||
> +   op == TGSI_OPCODE_I2I64 || op == TGSI_OPCODE_U2I64 ||
> op == TGSI_OPCODE_DLDEXP ||
> (op == TGSI_OPCODE_UCMP && dst_is_64bit[0])) {
>dinst->src[j].swizzle = MAKE_SWIZZLE4(swz, swz, swz, swz);
> }
>  }
>   }
>}
>inst = dinst;
> } else {
>this->instructions.push_tail(inst);
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/6] docs: Add EGL_MESA_platform_surfaceless.txt (v2)

2016-10-13 Thread Chad Versace
v2:
- Assign enum values.
- Define interactions with EGL_EXT_platform_base and EGL 1.4.
- Add Gurchetan as contributor, as he implemented the pbuffer support.
---
 docs/specs/EGL_MESA_platform_surfaceless.txt | 120 +++
 1 file changed, 120 insertions(+)
 create mode 100644 docs/specs/EGL_MESA_platform_surfaceless.txt

diff --git a/docs/specs/EGL_MESA_platform_surfaceless.txt 
b/docs/specs/EGL_MESA_platform_surfaceless.txt
new file mode 100644
index 000..871ee50
--- /dev/null
+++ b/docs/specs/EGL_MESA_platform_surfaceless.txt
@@ -0,0 +1,120 @@
+Name
+
+MESA_platform_surfaceless
+
+Name Strings
+
+EGL_MESA_platform_surfaceless
+
+Contributors
+
+Chad Versace 
+Haixia Shi 
+Stéphane Marchesin 
+Zach Reizner 
+Gurchetan Singh 
+
+Contacts
+
+Chad Versace 
+
+Status
+
+DRAFT
+
+Version
+
+Version 2, 2016-10-13
+
+Number
+
+EGL Extension #TODO
+
+Extension Type
+
+EGL client extension
+
+Dependencies
+
+Requires EGL 1.5 or later; or EGL 1.4 with EGL_EXT_platform_base.
+
+This extension is written against the EGL 1.5 Specification (draft
+20140122).
+
+This extension interacts with EGL_EXT_platform_base as follows. If the
+implementation supports EGL_EXT_platform_base, then text regarding
+eglGetPlatformDisplay applies also to eglGetPlatformDisplayEXT;
+eglCreatePlatformWindowSurface to eglCreatePlatformWindowSurfaceEXT; and
+eglCreatePlatformPixmapSurface to eglCreatePlatformPixmapSurfaceEXT.
+
+Overview
+
+This extension defines a new EGL platform, the "surfaceless" platform. This
+platfom's defining property is that it has no native surfaces, and hence
+neither eglCreatePlatformWindowSurface nor eglCreatePlatformPixmapSurface
+can be used. The platform is independent of any native window system.
+
+The platform's intended use case is for enabling OpenGL and OpenGL ES
+applications on systems where no window system exists. However, the
+platform's permitted usage is not restricted to this case.  Since the
+platform is independent of any native window system, it may also be used on
+systems where a window system is present.
+
+New Types
+
+None
+
+New Procedures and Functions
+
+None
+
+New Tokens
+
+Accepted as the  argument of eglGetPlatformDisplay:
+
+EGL_PLATFORM_SURFACELESS_MESA   0x31DD
+
+Additions to the EGL Specification
+
+None.
+
+New Behavior
+
+To determine if the EGL implementation supports this extension, clients
+should query the EGL_EXTENSIONS string of EGL_NO_DISPLAY.
+
+To obtain an EGLDisplay on the surfaceless platform, call
+eglGetPlatformDisplay with  set to EGL_PLATFORM_SURFACELESS_MESA.
+The  parameter must be EGL_DEFAULT_DISPLAY.
+
+eglCreatePlatformWindowSurface fails when called with a  that
+belongs to the surfaceless platform. It returns EGL_NO_SURFACE and
+generates EGL_BAD_NATIVE_WINDOW. The justification for this unconditional
+failure is that the surfaceless platform has no native windows, and
+therefore the  parameter is always invalid.
+
+Likewise, eglCreatePlatformPixmapSurface also fails when called with a
+ that belongs to the surfaceless platform.  It returns
+EGL_NO_SURFACE and generates EGL_BAD_NATIVE_PIXMAP.
+
+The surfaceless platform imposes no platform-specific restrictions on the
+creation of pbuffers, as eglCreatePbufferSurface has no native surface
+parameter.  Specifically, if the EGLDisplay advertises an EGLConfig whose
+EGL_SURFACE_TYPE attribute contains EGL_PBUFFER_BIT, then the EGLDisplay
+permits the creation of pbuffers with that config.
+
+Issues
+
+None.
+
+Revision History
+
+Version 2, 2016-10-13 (Chad Versace)
+- Assign enum values
+- Define interfactions with EGL 1.4 and EGL_EXT_platform_base.
+- Add Gurchetan as contributor, as he implemented the pbuffer support.
+
+Version 1, 2016-09-23 (Chad Versace)
+- Initial version
+- Posted for review at
+  
https://lists.freedesktop.org/archives/mesa-dev/2016-September/129549.html
-- 
2.10.0

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


[Mesa-dev] [PATCH 0/6] EGL_MESA_platform_surfaceless (v2)

2016-10-13 Thread Chad Versace
Mesa's EGL has supported Chrome OS's "surfaceless" platform for many
months, but the behavior of that platform has never been documented.
Here's my attempt to fix that.

I've already committed the draft extension spec into the private Khronos
registry. After these patches land in master, I plan to publish the spec
in the *public* Khronos registry then delete Mesa's copy.

See the piglit list for tests.

Branches:
- mesa: 
http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=review/EGL_MESA_platform_surfaceless-v02
- piglit: 
http://git.kiwitree.net/cgit/~chadv/piglit/log/?h=review/EGL_MESA_platform_surfaceless-v01

Chad Versace (6):
  docs: Add EGL_MESA_platform_surfaceless.txt (v2)
  egl: Don't advertise unsupported platform extensions
  egl: Implement EGL_MESA_platform_surfaceless
  egl: Move old EGL_MESA_screen_surface spec
  doc/specs: Reference the Khronos registry XML
  docs/specs: Update allocated EGL enum values

 docs/specs/EGL_MESA_platform_surfaceless.txt   | 120 +
 .../specs/OLD/EGL_MESA_screen_surface.txt  |   0
 docs/specs/enums.txt   |  41 +--
 include/EGL/eglmesaext.h   |   5 +
 src/egl/main/eglapi.c  |  42 +++-
 src/egl/main/egldisplay.c  |  21 
 src/egl/main/egldisplay.h  |   5 +
 src/egl/main/eglglobals.c  |  13 ++-
 8 files changed, 238 insertions(+), 9 deletions(-)
 create mode 100644 docs/specs/EGL_MESA_platform_surfaceless.txt
 rename src/egl/docs/EGL_MESA_screen_surface => 
docs/specs/OLD/EGL_MESA_screen_surface.txt (100%)

-- 
2.10.0

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


[Mesa-dev] [PATCH 4/6] egl: Move old EGL_MESA_screen_surface spec

2016-10-13 Thread Chad Versace
It was the lone file in src/egl/docs. Move it to where the other specs
live, in $MESA_TOP/docs/specs.
---
 .../EGL_MESA_screen_surface => docs/specs/OLD/EGL_MESA_screen_surface.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename src/egl/docs/EGL_MESA_screen_surface => 
docs/specs/OLD/EGL_MESA_screen_surface.txt (100%)

diff --git a/src/egl/docs/EGL_MESA_screen_surface 
b/docs/specs/OLD/EGL_MESA_screen_surface.txt
similarity index 100%
rename from src/egl/docs/EGL_MESA_screen_surface
rename to docs/specs/OLD/EGL_MESA_screen_surface.txt
-- 
2.10.0

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


[Mesa-dev] [PATCH 5/6] doc/specs: Reference the Khronos registry XML

2016-10-13 Thread Chad Versace
Years ago Khronos replaced the registry's spec files with newfangled XML
files.  Update the reference in doc/specs/enum.txt accordingly.
---
 docs/specs/enums.txt | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt
index b37768e..1a49db4 100644
--- a/docs/specs/enums.txt
+++ b/docs/specs/enums.txt
@@ -1,5 +1,10 @@
+The definitive source for enum values and reserved ranges are the XML files in
+the Khronos registry:
 
-See the OpenGL ARB enum registry at 
http://www.opengl.org/registry/api/enum.spec
+https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/egl.xml
+https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml
+https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/glx.xml
+https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/wgl.xml
 
 Blocks allocated to Mesa:
0x8750-0x875F
@@ -13,7 +18,7 @@ GL_MESA_packed_depth_stencil
GL_UNSIGNED_SHORT_15_1_MESA  0x8753
GL_UNSIGNED_SHORT_1_15_REV_MESA  0x8754
 
-GL_MESA_trace.spec:
+GL_MESA_trace:
GL_TRACE_ALL_BITS_MESA   0x
GL_TRACE_OPERATIONS_BIT_MESA 0x0001
GL_TRACE_PRIMITIVES_BIT_MESA 0x0002
@@ -24,12 +29,12 @@ GL_MESA_trace.spec:
GL_TRACE_MASK_MESA   0x8755
GL_TRACE_NAME_MESA   0x8756
 
-MESA_ycbcr_texture.spec:
+GL_MESA_ycbcr_texture:
GL_YCBCR_MESA0x8757
GL_UNSIGNED_SHORT_8_8_MESA   0x85BA /* same as Apple's */
GL_UNSIGNED_SHORT_8_8_REV_MESA   0x85BB /* same as Apple's */
 
-GL_MESA_pack_invert.spec
+GL_MESA_pack_invert:
GL_PACK_INVERT_MESA  0x8758
 
 GL_MESA_shader_debug.spec: (obsolete)
@@ -37,7 +42,7 @@ GL_MESA_shader_debug.spec: (obsolete)
 GL_DEBUG_PRINT_MESA  0x875A
 GL_DEBUG_ASSERT_MESA 0x875B
 
-GL_MESA_program_debug.spec: (obsolete)
+GL_MESA_program_debug: (obsolete)
GL_FRAGMENT_PROGRAM_CALLBACK_MESA  0x
GL_VERTEX_PROGRAM_CALLBACK_MESA0x
GL_FRAGMENT_PROGRAM_POSITION_MESA  0x
@@ -54,4 +59,3 @@ GL_MESAX_texture_stack:
GL_PROXY_TEXTURE_2D_STACK_MESAX  0x875C
GL_TEXTURE_1D_STACK_BINDING_MESAX0x875D
GL_TEXTURE_2D_STACK_BINDING_MESAX0x875E
-
-- 
2.10.0

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


[Mesa-dev] [PATCH 3/6] egl: Implement EGL_MESA_platform_surfaceless

2016-10-13 Thread Chad Versace
---
 include/EGL/eglmesaext.h  |  5 +
 src/egl/main/eglapi.c | 42 +-
 src/egl/main/egldisplay.c | 21 +
 src/egl/main/egldisplay.h |  5 +
 src/egl/main/eglglobals.c |  3 +++
 5 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h
index 337dd2c..188452e 100644
--- a/include/EGL/eglmesaext.h
+++ b/include/EGL/eglmesaext.h
@@ -84,6 +84,11 @@ typedef EGLBoolean (EGLAPIENTRYP PFNEGLSWAPBUFFERSREGIONNOK) 
(EGLDisplay dpy, EG
 #define EGL_NO_CONFIG_MESA ((EGLConfig)0)
 #endif
 
+#ifndef EGL_MESA_platform_surfaceless
+#define EGL_MESA_platform_surfaceless 1
+#define EGL_PLATFORM_SURFACELESS_MESA   0x31DD
+#endif /* EGL_MESA_platform_surfaceless */
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 4568b8b..d8bd76d 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -393,6 +393,11 @@ _eglGetPlatformDisplayCommon(EGLenum platform, void 
*native_display,
   attrib_list);
   break;
 #endif
+#ifdef HAVE_SURFACELESS_PLATFORM
+   case EGL_PLATFORM_SURFACELESS_MESA:
+  dpy = _eglGetSurfacelessDisplay(native_display, attrib_list);
+  break;
+#endif
default:
   RETURN_EGL_ERROR(NULL, EGL_BAD_PARAMETER, NULL);
}
@@ -837,11 +842,30 @@ _eglCreateWindowSurfaceCommon(_EGLDisplay *disp, 
EGLConfig config,
_EGLSurface *surf;
EGLSurface ret;
 
-   _EGL_CHECK_CONFIG(disp, conf, EGL_NO_SURFACE, drv);
 
if (native_window == NULL)
   RETURN_EGL_ERROR(disp, EGL_BAD_NATIVE_WINDOW, EGL_NO_SURFACE);
 
+#ifdef HAVE_SURFACELESS_PLATFORM
+   if (disp->Platform == _EGL_PLATFORM_SURFACELESS) {
+  /* From the EGL_MESA_platform_surfaceless spec (v1):
+   *
+   *eglCreatePlatformWindowSurface fails when called with a 
+   *that belongs to the surfaceless platform. It returns
+   *EGL_NO_SURFACE and generates EGL_BAD_NATIVE_WINDOW. The
+   *justification for this unconditional failure is that the
+   *surfaceless platform has no native windows, and therefore the
+   * parameter is always invalid.
+   *
+   * This check must occur before checking the EGLConfig, which emits
+   * EGL_BAD_CONFIG.
+   */
+  RETURN_EGL_ERROR(disp, EGL_BAD_NATIVE_WINDOW, EGL_NO_SURFACE);
+   }
+#endif
+
+   _EGL_CHECK_CONFIG(disp, conf, EGL_NO_SURFACE, drv);
+
surf = drv->API.CreateWindowSurface(drv, disp, conf, native_window,
attrib_list);
ret = (surf) ? _eglLinkSurface(surf) : EGL_NO_SURFACE;
@@ -943,6 +967,22 @@ _eglCreatePixmapSurfaceCommon(_EGLDisplay *disp, EGLConfig 
config,
_EGLSurface *surf;
EGLSurface ret;
 
+#if HAVE_SURFACELESS_PLATFORM
+   if (disp->Platform == _EGL_PLATFORM_SURFACELESS) {
+  /* From the EGL_MESA_platform_surfaceless spec (v1):
+   *
+   *   [Like eglCreatePlatformWindowSurface,] 
eglCreatePlatformPixmapSurface
+   *   also fails when called with a  that belongs to the
+   *   surfaceless platform.  It returns EGL_NO_SURFACE and generates
+   *   EGL_BAD_NATIVE_PIXMAP.
+   *
+   * This check must occur before checking the EGLConfig, which emits
+   * EGL_BAD_CONFIG.
+   */
+  RETURN_EGL_ERROR(disp, EGL_BAD_NATIVE_PIXMAP, EGL_NO_SURFACE);
+   }
+#endif
+
_EGL_CHECK_CONFIG(disp, conf, EGL_NO_SURFACE, drv);
surf = drv->API.CreatePixmapSurface(drv, disp, conf, native_pixmap,
attrib_list);
diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisplay.c
index 3d4eb81..37711bd 100644
--- a/src/egl/main/egldisplay.c
+++ b/src/egl/main/egldisplay.c
@@ -540,3 +540,24 @@ _eglGetWaylandDisplay(struct wl_display *native_display,
return _eglFindDisplay(_EGL_PLATFORM_WAYLAND, native_display);
 }
 #endif /* HAVE_WAYLAND_PLATFORM */
+
+#ifdef HAVE_SURFACELESS_PLATFORM
+_EGLDisplay*
+_eglGetSurfacelessDisplay(void *native_display,
+  const EGLint *attrib_list)
+{
+   /* This platform has no native display. */
+   if (native_display != NULL) {
+  _eglError(EGL_BAD_PARAMETER, "eglGetPlatformDisplay");
+  return NULL;
+   }
+
+   /* This platform recognizes no display attributes. */
+   if (attrib_list != NULL && attrib_list[0] != EGL_NONE) {
+  _eglError(EGL_BAD_ATTRIBUTE, "eglGetPlatformDisplay");
+  return NULL;
+   }
+
+   return _eglFindDisplay(_EGL_PLATFORM_SURFACELESS, native_display);
+}
+#endif /* HAVE_SURFACELESS_PLATFORM */
diff --git a/src/egl/main/egldisplay.h b/src/egl/main/egldisplay.h
index 22fb5c8..62d9a11 100644
--- a/src/egl/main/egldisplay.h
+++ b/src/egl/main/egldisplay.h
@@ -274,6 +274,11 @@ _eglGetWaylandDisplay(struct wl_display *native_display,
   const EGLint *attrib_list);
 #endif
 
+#ifdef HAVE_SURFACELESS_PLATFORM
+_EGLDisplay*
+_eglGetSurfacelessDisplay(void 

[Mesa-dev] [PATCH 2/6] egl: Don't advertise unsupported platform extensions

2016-10-13 Thread Chad Versace
Mesa's set of supported platform extensions depends on the autoconf
option --with-egl-platforms=foo,bar,baz. If --with-egl-platforms lacks
foo, then eglGetPlatformDisplay(EGL_PLATFORM_FOO, ...) unconditonally
fails.

So, if --with-egl-platforms lacks foo, then remove
EGL_VENDOR_platform_foo from the EGL client extension string.
---
 src/egl/main/eglglobals.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/egl/main/eglglobals.c b/src/egl/main/eglglobals.c
index ac1a263..8fffa55 100644
--- a/src/egl/main/eglglobals.c
+++ b/src/egl/main/eglglobals.c
@@ -53,11 +53,17 @@ struct _egl_global _eglGlobal =
/* ClientExtensionString */
"EGL_EXT_client_extensions"
" EGL_EXT_platform_base"
+#ifdef HAVE_WAYLAND_PLATFORM
" EGL_EXT_platform_wayland"
+#endif
+#ifdef HAVE_X11_PLATFORM
" EGL_EXT_platform_x11"
+#endif
+#ifdef HAVE_DRM_PLATFORM
+   " EGL_MESA_platform_gbm"
+#endif
" EGL_KHR_client_get_all_proc_addresses"
-   " EGL_KHR_debug"
-   " EGL_MESA_platform_gbm",
+   " EGL_KHR_debug",
 
NULL, /* debugCallback */
_EGL_DEBUG_BIT_CRITICAL | _EGL_DEBUG_BIT_ERROR, /* debugTypesEnabled */
-- 
2.10.0

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


[Mesa-dev] [PATCH 6/6] docs/specs: Update allocated EGL enum values

2016-10-13 Thread Chad Versace
Document the EGL enum ranges for Mesa and those values allocated by the
following extensions:

EGL_MESA_drm_image
EGL_MESA_platform_gbm
EGL_MESA_platform_surfaceless
EGL_WL_bind_wayland_display
---
 docs/specs/enums.txt | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt
index 1a49db4..1caa284 100644
--- a/docs/specs/enums.txt
+++ b/docs/specs/enums.txt
@@ -6,10 +6,13 @@ the Khronos registry:
 https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/glx.xml
 https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/wgl.xml
 
-Blocks allocated to Mesa:
+GL blocks allocated to Mesa:
0x8750-0x875F
0x8BB0-0x8BBF
 
+EGL blocks allocated to Mesa:
+   0x31D0-0x31DF
+   0x3290-0x329F
 
 GL_MESA_packed_depth_stencil
GL_DEPTH_STENCIL_MESA0x8750
@@ -59,3 +62,25 @@ GL_MESAX_texture_stack:
GL_PROXY_TEXTURE_2D_STACK_MESAX  0x875C
GL_TEXTURE_1D_STACK_BINDING_MESAX0x875D
GL_TEXTURE_2D_STACK_BINDING_MESAX0x875E
+
+EGL_MESA_drm_image
+EGL_DRM_BUFFER_FORMAT_MESA 0x31D0
+EGL_DRM_BUFFER_USE_MESA0x31D1
+EGL_DRM_BUFFER_FORMAT_ARGB32_MESA  0x31D2
+EGL_DRM_BUFFER_MESA0x31D3
+EGL_DRM_BUFFER_STRIDE_MESA 0x31D4
+
+EGL_MESA_platform_gbm
+EGL_PLATFORM_GBM_MESA   0x31D7
+
+EGL_MESA_platform_surfaceless
+EGL_PLATFORM_SURFACELESS_MESA   0x31DD
+
+EGL_WL_bind_wayland_display
+EGL_TEXTURE_FORMAT  0x3080
+EGL_WAYLAND_BUFFER_WL   0x31D5
+EGL_WAYLAND_PLANE_WL0x31D6
+EGL_TEXTURE_Y_U_V_WL0x31D7
+EGL_TEXTURE_Y_UV_WL 0x31D8
+EGL_TEXTURE_Y_XUXV_WL   0x31D9
+EGL_WAYLAND_Y_INVERTED_WL   0x31DB
-- 
2.10.0

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


Re: [Mesa-dev] [RFC 00/12] egl, i965: Support EGL_ANDROID_native_fence_sync (v2)

2016-10-13 Thread Rob Clark
On Thu, Oct 13, 2016 at 4:37 PM, Rafael Antognolli
 wrote:
> Hi all,
>
> On Tue, Oct 11, 2016 at 01:47:37PM -0400, Robert Foss wrote:
>>
>>
>> On 2016-10-11 01:37 PM, Chad Versace wrote:
>> > On Tue 11 Oct 2016, Emil Velikov wrote:
>> > > On 10 October 2016 at 20:41, Rob Clark  wrote:
>> > > > On Mon, Oct 10, 2016 at 1:43 PM, Chad Versace 
>> > > >  wrote:
>> >
>> > > > > Testing:
>> > > > >
>> > > > > I haven't yet tested EGL_ANDROID_native_fence_sync with these 
>> > > > > patches, but
>> > > > > the series does build. I just wanted to get these patches on the 
>> > > > > list as a
>> > > > > status-update.  I'm slowly working on getting Rob Clark's 
>> > > > > hacked-up kmscube to
>> > > > > work on this series.
>> > > > >
>> > > > > I did test that this series doesn't break any dEQP-EGL sync 
>> > > > > tests. But my
>> > > > > dEQP doesn't include any EGL_ANDROID_native_fence_sync tests.
>> > > > >
>> >
>> > > From a quick skim neither one of CTS/dEQP/piglit had
>> > > EGL_ANDROID_native_fence_sync tests. I've mentioned to Rob F that
>> > > adding a few piglits might be a good idea. It would be good to
>> > > coordinate to avoid writing the same tests twice ;-)
>> >
>> > Yes, we should have tests before committing this feature. I am releasing
>> > any lock I may had held on test writing, as I don't have time to tackle
>> > that this week.
>>
>> Writing the tests is not on my table at the moment. Perhaps some time can be
>> scraped together for it at a later point, but not now.
>
> If nobody has started writing piglit tests yet, and it's OK with you
> guys, I would like to give it a try since I'm also interested in this
> feature.

that would be hugely useful.. I'm not sure anyone else has started on
tests, but they are definitely needed

> Also if I understood correctly, the initial thing to test is whether
> WaitSync and ClientWaitSync respect input fences, right? I'll try to
> come up with a list of other things to test, like invalid fences and so
> on, but if you guys already have a list of things to test in mind,
> please let me know.

I guess API level tests, like can you create a fence w/
NO_NATIVE_FENCE_FD as input, then glFlush(), and then get an fd back
from eglDupFenceFD(), and that sort of thing?  I haven't really given
it much thought yet.

BR,
-R

> Anyway, is it fine if I start working on this?
>
> Regards,
> Rafael
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [RFC 00/12] egl, i965: Support EGL_ANDROID_native_fence_sync (v2)

2016-10-13 Thread Rafael Antognolli
Hi all,

On Tue, Oct 11, 2016 at 01:47:37PM -0400, Robert Foss wrote:
> 
> 
> On 2016-10-11 01:37 PM, Chad Versace wrote:
> > On Tue 11 Oct 2016, Emil Velikov wrote:
> > > On 10 October 2016 at 20:41, Rob Clark  wrote:
> > > > On Mon, Oct 10, 2016 at 1:43 PM, Chad Versace 
> > > >  wrote:
> > 
> > > > > Testing:
> > > > > 
> > > > > I haven't yet tested EGL_ANDROID_native_fence_sync with these 
> > > > > patches, but
> > > > > the series does build. I just wanted to get these patches on the 
> > > > > list as a
> > > > > status-update.  I'm slowly working on getting Rob Clark's 
> > > > > hacked-up kmscube to
> > > > > work on this series.
> > > > > 
> > > > > I did test that this series doesn't break any dEQP-EGL sync 
> > > > > tests. But my
> > > > > dEQP doesn't include any EGL_ANDROID_native_fence_sync tests.
> > > > > 
> > 
> > > From a quick skim neither one of CTS/dEQP/piglit had
> > > EGL_ANDROID_native_fence_sync tests. I've mentioned to Rob F that
> > > adding a few piglits might be a good idea. It would be good to
> > > coordinate to avoid writing the same tests twice ;-)
> > 
> > Yes, we should have tests before committing this feature. I am releasing
> > any lock I may had held on test writing, as I don't have time to tackle
> > that this week.
> 
> Writing the tests is not on my table at the moment. Perhaps some time can be
> scraped together for it at a later point, but not now.

If nobody has started writing piglit tests yet, and it's OK with you
guys, I would like to give it a try since I'm also interested in this
feature.

Also if I understood correctly, the initial thing to test is whether
WaitSync and ClientWaitSync respect input fences, right? I'll try to
come up with a list of other things to test, like invalid fences and so
on, but if you guys already have a list of things to test in mind,
please let me know.

Anyway, is it fine if I start working on this?

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


[Mesa-dev] [PATCH] radv/winsys: Fail early on overgrown cs.

2016-10-13 Thread Gustaw Smolarczyk
When !use_ib_bos, we can't easily chain ibs one to another. If the
required cs size grows over 1Mi - 8 dwords just fail the cs so that we
won't assert-fail in radv_amdgpu_winsys_cs_submit later on.
---
Please, push the patch after it has been reviewed.

 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
index 41dfcd3..b8558fa 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
@@ -187,12 +187,22 @@ static void radv_amdgpu_cs_grow(struct radeon_winsys_cs 
*_cs, size_t min_size)
}
 
if (!cs->ws->use_ib_bos) {
-   uint64_t ib_size = MAX2((cs->base.cdw + min_size) * 4 + 16,
-   cs->base.max_dw * 4 * 2);
-   uint32_t *new_buf = realloc(cs->base.buf, ib_size);
+   const uint64_t limit_dws = 0x8;
+   uint64_t ib_dws = MAX2(cs->base.cdw + min_size,
+  MIN2(cs->base.max_dw * 2, limit_dws));
+
+   /* The total ib size cannot exceed limit_dws dwords. */
+   if (ib_dws > limit_dws)
+   {
+   cs->failed = true;
+   cs->base.cdw = 0;
+   return;
+   }
+
+   uint32_t *new_buf = realloc(cs->base.buf, ib_dws * 4);
if (new_buf) {
cs->base.buf = new_buf;
-   cs->base.max_dw = ib_size / 4;
+   cs->base.max_dw = ib_dws;
} else {
cs->failed = true;
cs->base.cdw = 0;
-- 
2.10.0

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


Re: [Mesa-dev] [RFC 00/12] egl, i965: Support EGL_ANDROID_native_fence_sync (v2)

2016-10-13 Thread Robert Foss



On 2016-10-13 04:37 PM, Rafael Antognolli wrote:

Hi all,

On Tue, Oct 11, 2016 at 01:47:37PM -0400, Robert Foss wrote:



On 2016-10-11 01:37 PM, Chad Versace wrote:

On Tue 11 Oct 2016, Emil Velikov wrote:

On 10 October 2016 at 20:41, Rob Clark  wrote:

On Mon, Oct 10, 2016 at 1:43 PM, Chad Versace  wrote:



Testing:

I haven't yet tested EGL_ANDROID_native_fence_sync with these patches, but
the series does build. I just wanted to get these patches on the list as a
status-update.  I'm slowly working on getting Rob Clark's hacked-up kmscube 
to
work on this series.

I did test that this series doesn't break any dEQP-EGL sync tests. But my
dEQP doesn't include any EGL_ANDROID_native_fence_sync tests.




From a quick skim neither one of CTS/dEQP/piglit had
EGL_ANDROID_native_fence_sync tests. I've mentioned to Rob F that
adding a few piglits might be a good idea. It would be good to
coordinate to avoid writing the same tests twice ;-)


Yes, we should have tests before committing this feature. I am releasing
any lock I may had held on test writing, as I don't have time to tackle
that this week.


Writing the tests is not on my table at the moment. Perhaps some time can be
scraped together for it at a later point, but not now.


If nobody has started writing piglit tests yet, and it's OK with you
guys, I would like to give it a try since I'm also interested in this
feature.

Also if I understood correctly, the initial thing to test is whether
WaitSync and ClientWaitSync respect input fences, right? I'll try to
come up with a list of other things to test, like invalid fences and so
on, but if you guys already have a list of things to test in mind,
please let me know.

Anyway, is it fine if I start working on this?


That would be very welcome!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 98222] [radv] LLVM ERROR: Cannot select: intrinsic %llvm.amdgcn.image.store

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98222

--- Comment #1 from Christoph Haag  ---
https://cgit.freedesktop.org/mesa/mesa/commit/?id=5c66d46d6ace0603227e4b919b132416444949e7
should fix it.

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


[Mesa-dev] [PATCH v2] clover: Allow OpenCL version override

2016-10-13 Thread Vedran Miletić
CLOVER_CL_VERSION_OVERRIDE allows overriding default OpenCL version
supported by Clover, analogous to MESA_GL_VERSION_OVERRIDE for OpenGL.
CLOVER_CL_C_VERSION_OVERRIDE allows overridng default OpenCL C version.

v2:
  - move version getters to version.hpp, simplify
  - set -cl-std= to CLOVER_CL_C_VERSION_OVERRIDE
  - set __OPENCL_VERSION__ to CLOVER_CL_VERSION_OVERRIDE
---
 docs/envvars.html  | 12 ++
 src/gallium/state_trackers/clover/Makefile.sources |  3 +-
 src/gallium/state_trackers/clover/api/device.cpp   |  5 ++-
 src/gallium/state_trackers/clover/api/platform.cpp |  3 +-
 .../state_trackers/clover/llvm/invocation.cpp  | 30 --
 src/gallium/state_trackers/clover/llvm/util.hpp|  4 +-
 src/gallium/state_trackers/clover/util/version.hpp | 48 ++
 7 files changed, 95 insertions(+), 10 deletions(-)
 create mode 100644 src/gallium/state_trackers/clover/util/version.hpp

diff --git a/docs/envvars.html b/docs/envvars.html
index cf57ca5..f76827b 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -235,6 +235,18 @@ Setting to "tgsi", for example, will print all the TGSI 
shaders.
 See src/mesa/state_tracker/st_debug.c for other options.
 
 
+Clover state tracker environment variables
+
+
+CLOVER_CL_VERSION_OVERRIDE - allows overriding OpenCL version returned by
+clGetPlatformInfo(CL_PLATFORM_VERSION) and
+clGetDeviceInfo(CL_DEVICE_VERSION). Note that the setting sets the version
+of the platform and all the devices to the same value.
+CLOVER_CL_C_VERSION_OVERRIDE - allows overriding OpenCL C version reported
+by clGetDeviceInfo(CL_DEVICE_OPENCL_C_VERSION) and the value of the
+__OPENCL_VERSION__ macro in the OpenCL compiler.
+
+
 Softpipe driver environment variables
 
 SOFTPIPE_DUMP_FS - if set, the softpipe driver will print fragment shaders
diff --git a/src/gallium/state_trackers/clover/Makefile.sources 
b/src/gallium/state_trackers/clover/Makefile.sources
index e9828b1..37f61b0 100644
--- a/src/gallium/state_trackers/clover/Makefile.sources
+++ b/src/gallium/state_trackers/clover/Makefile.sources
@@ -50,7 +50,8 @@ CPP_SOURCES := \
util/lazy.hpp \
util/pointer.hpp \
util/range.hpp \
-   util/tuple.hpp
+   util/tuple.hpp \
+   util/version.hpp
 
 LLVM_SOURCES := \
llvm/codegen/bitcode.cpp \
diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index f7bd61b..a759e0e 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -23,6 +23,7 @@
 #include "api/util.hpp"
 #include "core/platform.hpp"
 #include "core/device.hpp"
+#include "util/version.hpp"
 #include "git_sha1.h"
 
 using namespace clover;
@@ -301,7 +302,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_VERSION:
-  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
+  buf.as_string() = "OpenCL " + get_opencl_version() + " Mesa " 
PACKAGE_VERSION
 #ifdef MESA_GIT_SHA1
 " (" MESA_GIT_SHA1 ")"
 #endif
@@ -355,7 +356,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_OPENCL_C_VERSION:
-  buf.as_string() = "OpenCL C 1.1 ";
+  buf.as_string() = "OpenCL C " + get_opencl_c_version() + " ";
   break;
 
case CL_DEVICE_PARENT_DEVICE:
diff --git a/src/gallium/state_trackers/clover/api/platform.cpp 
b/src/gallium/state_trackers/clover/api/platform.cpp
index b1b1fdf..f3360fe 100644
--- a/src/gallium/state_trackers/clover/api/platform.cpp
+++ b/src/gallium/state_trackers/clover/api/platform.cpp
@@ -22,6 +22,7 @@
 
 #include "api/util.hpp"
 #include "core/platform.hpp"
+#include "util/version.hpp"
 #include "git_sha1.h"
 
 using namespace clover;
@@ -58,7 +59,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
cl_platform_info param,
   break;
 
case CL_PLATFORM_VERSION:
-  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
+  buf.as_string() = "OpenCL " + get_opencl_version() + " Mesa " 
PACKAGE_VERSION
 #ifdef MESA_GIT_SHA1
 " (" MESA_GIT_SHA1 ")"
 #endif
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp 
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index b5e8b52..6886dad 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -52,7 +52,7 @@
 #include "llvm/metadata.hpp"
 #include "llvm/util.hpp"
 #include "util/algorithm.hpp"
-
+#include "util/version.hpp"
 
 using namespace clover;
 using namespace clover::llvm;
@@ -120,10 +120,23 @@ namespace {
   // http://www.llvm.org/bugs/show_bug.cgi?id=19735
   c->getDiagnosticOpts().ShowCarets = false;
 
+  const std::string opencl_c_version = get_opencl_c_version();
+  clang::LangStandard::Kind lang_kind;
+  if (opencl_c_version == "1.0")
+ 

[Mesa-dev] [PATCH v3] doc/features.txt: factor out i965/hsw+ & radeonsi as GL45 complete

2016-10-13 Thread Edward O'Callaghan
V2. add i965/hsw+ to list
V3. rebased on master.

Signed-off-by: Edward O'Callaghan 
---
 docs/features.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index 0d6c16a..acea0cf 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, nvc0, radeonsi
   GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
r600, llvmpipe, softpipe, swr)
   GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
r600, llvmpipe, softpipe, swr)
 
-GL 4.5, GLSL 4.50 -- all DONE: nvc0
+GL 4.5, GLSL 4.50 -- all DONE: i965/hsw+, nvc0, radeonsi
 
-  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+, 
radeonsi)
-  GL_ARB_clip_control   DONE (i965, nv50, 
r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_cull_distance  DONE (i965, nv50, 
radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_derivative_control DONE (i965, nv50, 
r600, radeonsi)
+  GL_ARB_ES3_1_compatibilityDONE
+  GL_ARB_clip_control   DONE (nv50, r600, 
llvmpipe, softpipe, swr)
+  GL_ARB_conditional_render_invertedDONE (nv50, r600, 
llvmpipe, softpipe, swr)
+  GL_ARB_cull_distance  DONE (nv50, llvmpipe, 
softpipe, swr)
+  GL_ARB_derivative_control DONE (nv50, r600)
   GL_ARB_direct_state_accessDONE (all drivers)
   GL_ARB_get_texture_sub_image  DONE (all drivers)
-  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, 
r600, radeonsi)
-  GL_ARB_texture_barrierDONE (i965, nv50, 
r600, radeonsi)
+  GL_ARB_shader_texture_image_samples   DONE (nv50, r600)
+  GL_ARB_texture_barrierDONE (nv50, r600)
   GL_KHR_context_flush_control  DONE (all - but needs 
GLX/EGL extension to be useful)
-  GL_KHR_robustness DONE (i965, radeonsi)
+  GL_KHR_robustness DONE
   GL_EXT_shader_integer_mix DONE (all drivers that 
support GLSL)
 
 These are the extensions cherry-picked to make GLES 3.1
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] radeonsi: shorten "shader->selector" to "sel" in si_shader_create

2016-10-13 Thread Edward O'Callaghan
yes, nicer.

Reviewed-by: Edward O'Callaghan 

On 10/14/2016 04:16 AM, Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/gallium/drivers/radeonsi/si_shader.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index b2d7699..e6edd90 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -7850,35 +7850,36 @@ static void si_fix_num_sgprs(struct si_shader *shader)
>  {
>   unsigned min_sgprs = shader->info.num_input_sgprs + 2; /* VCC */
>  
>   shader->config.num_sgprs = MAX2(shader->config.num_sgprs, min_sgprs);
>  }
>  
>  int si_shader_create(struct si_screen *sscreen, LLVMTargetMachineRef tm,
>struct si_shader *shader,
>struct pipe_debug_callback *debug)
>  {
> - struct si_shader *mainp = shader->selector->main_shader_part;
> + struct si_shader_selector *sel = shader->selector;
> + struct si_shader *mainp = sel->main_shader_part;
>   int r;
>  
>   /* LS, ES, VS are compiled on demand if the main part hasn't been
>* compiled for that stage.
>*/
>   if (!mainp ||
> - (shader->selector->type == PIPE_SHADER_VERTEX &&
> + (sel->type == PIPE_SHADER_VERTEX &&
>(shader->key.vs.as_es != mainp->key.vs.as_es ||
> shader->key.vs.as_ls != mainp->key.vs.as_ls)) ||
> - (shader->selector->type == PIPE_SHADER_TESS_EVAL &&
> + (sel->type == PIPE_SHADER_TESS_EVAL &&
>shader->key.tes.as_es != mainp->key.tes.as_es) ||
> - (shader->selector->type == PIPE_SHADER_TESS_CTRL &&
> + (sel->type == PIPE_SHADER_TESS_CTRL &&
>shader->key.tcs.epilog.inputs_to_copy) ||
> - shader->selector->type == PIPE_SHADER_COMPUTE) {
> + sel->type == PIPE_SHADER_COMPUTE) {
>   /* Monolithic shader (compiled as a whole, has many variants,
>* may take a long time to compile).
>*/
>   r = si_compile_tgsi_shader(sscreen, tm, shader, true, debug);
>   if (r)
>   return r;
>   } else {
>   /* The shader consists of 2-3 parts:
>*
>* - the middle part is the user shader, it has 1 variant only
> @@ -7898,21 +7899,21 @@ int si_shader_create(struct si_screen *sscreen, 
> LLVMTargetMachineRef tm,
>   shader->info.num_input_vgprs = mainp->info.num_input_vgprs;
>   shader->info.face_vgpr_index = mainp->info.face_vgpr_index;
>   memcpy(shader->info.vs_output_param_offset,
>  mainp->info.vs_output_param_offset,
>  sizeof(mainp->info.vs_output_param_offset));
>   shader->info.uses_instanceid = mainp->info.uses_instanceid;
>   shader->info.nr_pos_exports = mainp->info.nr_pos_exports;
>   shader->info.nr_param_exports = mainp->info.nr_param_exports;
>  
>   /* Select prologs and/or epilogs. */
> - switch (shader->selector->type) {
> + switch (sel->type) {
>   case PIPE_SHADER_VERTEX:
>   if (!si_shader_select_vs_parts(sscreen, tm, shader, 
> debug))
>   return -1;
>   break;
>   case PIPE_SHADER_TESS_CTRL:
>   if (!si_shader_select_tcs_parts(sscreen, tm, shader, 
> debug))
>   return -1;
>   break;
>   case PIPE_SHADER_TESS_EVAL:
>   if (!si_shader_select_tes_parts(sscreen, tm, shader, 
> debug))
> @@ -7939,21 +7940,21 @@ int si_shader_create(struct si_screen *sscreen, 
> LLVMTargetMachineRef tm,
>   }
>   if (shader->epilog) {
>   shader->config.num_sgprs = 
> MAX2(shader->config.num_sgprs,
>   
> shader->epilog->config.num_sgprs);
>   shader->config.num_vgprs = 
> MAX2(shader->config.num_vgprs,
>   
> shader->epilog->config.num_vgprs);
>   }
>   }
>  
>   si_fix_num_sgprs(shader);
> - si_shader_dump(sscreen, shader, debug, shader->selector->info.processor,
> + si_shader_dump(sscreen, shader, debug, sel->info.processor,
>  stderr);
>  
>   /* Upload. */
>   r = si_shader_binary_upload(sscreen, shader);
>   if (r) {
>   fprintf(stderr, "LLVM failed to upload shader\n");
>   return r;
>   }
>  
>   return 0;
> 



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

Re: [Mesa-dev] [PATCH 1/6] util: add vector util code.

2016-10-13 Thread Edward O'Callaghan
Too easy, one trivial comment below but either way:
Reviewed-by: Edward O'Callaghan 

P.S. thanks for getting on top of this kind of maintainability stuff so
fast !

On 10/14/2016 02:16 PM, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This is ported from anv, both anv and radv can share this.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/util/Makefile.sources |  4 +-
>  src/util/u_vector.c   | 98 
> +++
>  src/util/u_vector.h   | 85 
>  3 files changed, 186 insertions(+), 1 deletion(-)
>  create mode 100644 src/util/u_vector.c
>  create mode 100644 src/util/u_vector.h
> 
> diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
> index 8b17bcf..b7b1e91 100644
> --- a/src/util/Makefile.sources
> +++ b/src/util/Makefile.sources
> @@ -35,7 +35,9 @@ MESA_UTIL_FILES :=  \
>   strtod.h \
>   texcompress_rgtc_tmp.h \
>   u_atomic.h \
> - u_endian.h
> + u_endian.h \
> + u_vector.c \
> + u_vector.h
>  
>  MESA_UTIL_GENERATED_FILES = \
>   format_srgb.c
> diff --git a/src/util/u_vector.c b/src/util/u_vector.c
> new file mode 100644
> index 000..37c4245
> --- /dev/null
> +++ b/src/util/u_vector.c
> @@ -0,0 +1,98 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +#include "util/u_vector.h"
> +
> +int
> +u_vector_init(struct u_vector *vector, uint32_t element_size, uint32_t size)
> +{
> +   assert(util_is_power_of_two(size));
> +   assert(element_size < size && util_is_power_of_two(element_size));
> +
> +   vector->head = 0;
> +   vector->tail = 0;
> +   vector->element_size = element_size;
> +   vector->size = size;
> +   vector->data = malloc(size);
> +
> +   return vector->data != NULL;
> +}
> +
> +void *
> +u_vector_add(struct u_vector *vector)
> +{
> +   uint32_t offset, size, split, src_tail, dst_tail;
> +   void *data;
> +
> +   if (vector->head - vector->tail == vector->size) {
> +  size = vector->size * 2;
> +  data = malloc(size);
> +  if (data == NULL)

simplify to (!data)

> + return NULL;
> +  src_tail = vector->tail & (vector->size - 1);
> +  dst_tail = vector->tail & (size - 1);
> +  if (src_tail == 0) {
> + /* Since we know that the vector is full, this means that it's
> +  * linear from start to end so we can do one copy.
> +  */
> + memcpy((char *)data + dst_tail, vector->data, vector->size);
> +  } else {
> + /* In this case, the vector is split into two pieces and we have
> +  * to do two copies.  We have to be careful to make sure each
> +  * piece goes to the right locations.  Thanks to the change in
> +  * size, it may or may not still wrap around.
> +  */
> + split = u_align_u32(vector->tail, vector->size);
> + assert(vector->tail <= split && split < vector->head);
> + memcpy((char *)data + dst_tail, (char *)vector->data + src_tail,
> +split - vector->tail);
> + memcpy((char *)data + (split & (size - 1)), vector->data,
> +vector->head - split);
> +  }
> +  free(vector->data);
> +  vector->data = data;
> +  vector->size = size;
> +   }
> +
> +   assert(vector->head - vector->tail < vector->size);
> +
> +   offset = vector->head & (vector->size - 1);
> +   vector->head += vector->element_size;
> +
> +   return (char *)vector->data + offset;
> +}
> +
> +void *
> +u_vector_remove(struct u_vector *vector)
> +{
> +   uint32_t offset;
> +
> +   if (vector->head == vector->tail)
> +  return NULL;
> +
> +   assert(vector->head - vector->tail <= vector->size);
> +
> +   offset = vector->tail & (vector->size - 1);
> +   vector->tail += vector->element_size;

[Mesa-dev] [PATCH] gallivm: print out time for jitting functions with GALLIVM_DEBUG=perf

2016-10-13 Thread sroland
From: Roland Scheidegger 

Compilation to actual machine code can easily take as much time as the
optimization passes on the IR if not more, so print this out too.
---
 src/gallium/auxiliary/gallivm/lp_bld_init.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c 
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 7114cde..d1b2369 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -659,13 +659,24 @@ gallivm_jit_function(struct gallivm_state *gallivm,
 {
void *code;
func_pointer jit_func;
+   int64_t time_begin = 0;
 
assert(gallivm->compiled);
assert(gallivm->engine);
 
+   if (gallivm_debug & GALLIVM_DEBUG_PERF)
+  time_begin = os_time_get();
+
code = LLVMGetPointerToGlobal(gallivm->engine, func);
assert(code);
jit_func = pointer_to_func(code);
 
+   if (gallivm_debug & GALLIVM_DEBUG_PERF) {
+  int64_t time_end = os_time_get();
+  int time_msec = (int)(time_end - time_begin) / 1000;
+  debug_printf("   jitting func %s took %d msec\n",
+   LLVMGetValueName(func), time_msec);
+   }
+
return jit_func;
 }
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v2] clover: Allow OpenCL version override

2016-10-13 Thread Jan Vesely
On Fri, 2016-10-14 at 02:34 +0200, Vedran Miletić wrote:
> CLOVER_CL_VERSION_OVERRIDE allows overriding default OpenCL version
> supported by Clover, analogous to MESA_GL_VERSION_OVERRIDE for OpenGL.
> CLOVER_CL_C_VERSION_OVERRIDE allows overridng default OpenCL C version.
> 
> v2:
>   - move version getters to version.hpp, simplify
>   - set -cl-std= to CLOVER_CL_C_VERSION_OVERRIDE
>   - set __OPENCL_VERSION__ to CLOVER_CL_VERSION_OVERRIDE

other than a small nit in docs, LGTM.
Reviewed-by: Jan Vesely 
you probably want Francsisco's RB before pushing it.

> ---
>  docs/envvars.html  | 12 ++
>  src/gallium/state_trackers/clover/Makefile.sources |  3 +-
>  src/gallium/state_trackers/clover/api/device.cpp   |  5 ++-
>  src/gallium/state_trackers/clover/api/platform.cpp |  3 +-
>  .../state_trackers/clover/llvm/invocation.cpp  | 30 --
>  src/gallium/state_trackers/clover/llvm/util.hpp|  4 +-
>  src/gallium/state_trackers/clover/util/version.hpp | 48 
> ++
>  7 files changed, 95 insertions(+), 10 deletions(-)
>  create mode 100644 src/gallium/state_trackers/clover/util/version.hpp
> 
> diff --git a/docs/envvars.html b/docs/envvars.html
> index cf57ca5..f76827b 100644
> --- a/docs/envvars.html
> +++ b/docs/envvars.html
> @@ -235,6 +235,18 @@ Setting to "tgsi", for example, will print all the TGSI 
> shaders.
>  See src/mesa/state_tracker/st_debug.c for other options.
>  
>  
> +Clover state tracker environment variables
> +
> +
> +CLOVER_CL_VERSION_OVERRIDE - allows overriding OpenCL version returned by
> +clGetPlatformInfo(CL_PLATFORM_VERSION) and
> +clGetDeviceInfo(CL_DEVICE_VERSION). Note that the setting sets the 
> version
> +of the platform and all the devices to the same value.
> +CLOVER_CL_C_VERSION_OVERRIDE - allows overriding OpenCL C version 
> reported
> +by clGetDeviceInfo(CL_DEVICE_OPENCL_C_VERSION) and the value of the
> +__OPENCL_VERSION__ macro in the OpenCL compiler.

Looking at the code, the macro is set by the former env var. clang will
set OPENCL_C_VERSION based on the lang option

Jan

> +
> +
>  Softpipe driver environment variables
>  
>  SOFTPIPE_DUMP_FS - if set, the softpipe driver will print fragment 
> shaders
> diff --git a/src/gallium/state_trackers/clover/Makefile.sources 
> b/src/gallium/state_trackers/clover/Makefile.sources
> index e9828b1..37f61b0 100644
> --- a/src/gallium/state_trackers/clover/Makefile.sources
> +++ b/src/gallium/state_trackers/clover/Makefile.sources
> @@ -50,7 +50,8 @@ CPP_SOURCES := \
>   util/lazy.hpp \
>   util/pointer.hpp \
>   util/range.hpp \
> - util/tuple.hpp
> + util/tuple.hpp \
> + util/version.hpp
>  
>  LLVM_SOURCES := \
>   llvm/codegen/bitcode.cpp \
> diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
> b/src/gallium/state_trackers/clover/api/device.cpp
> index f7bd61b..a759e0e 100644
> --- a/src/gallium/state_trackers/clover/api/device.cpp
> +++ b/src/gallium/state_trackers/clover/api/device.cpp
> @@ -23,6 +23,7 @@
>  #include "api/util.hpp"
>  #include "core/platform.hpp"
>  #include "core/device.hpp"
> +#include "util/version.hpp"
>  #include "git_sha1.h"
>  
>  using namespace clover;
> @@ -301,7 +302,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
>break;
>  
> case CL_DEVICE_VERSION:
> -  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
> +  buf.as_string() = "OpenCL " + get_opencl_version() + " Mesa " 
> PACKAGE_VERSION
>  #ifdef MESA_GIT_SHA1
>  " (" MESA_GIT_SHA1 ")"
>  #endif
> @@ -355,7 +356,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
>break;
>  
> case CL_DEVICE_OPENCL_C_VERSION:
> -  buf.as_string() = "OpenCL C 1.1 ";
> +  buf.as_string() = "OpenCL C " + get_opencl_c_version() + " ";
>break;
>  
> case CL_DEVICE_PARENT_DEVICE:
> diff --git a/src/gallium/state_trackers/clover/api/platform.cpp 
> b/src/gallium/state_trackers/clover/api/platform.cpp
> index b1b1fdf..f3360fe 100644
> --- a/src/gallium/state_trackers/clover/api/platform.cpp
> +++ b/src/gallium/state_trackers/clover/api/platform.cpp
> @@ -22,6 +22,7 @@
>  
>  #include "api/util.hpp"
>  #include "core/platform.hpp"
> +#include "util/version.hpp"
>  #include "git_sha1.h"
>  
>  using namespace clover;
> @@ -58,7 +59,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
> cl_platform_info param,
>break;
>  
> case CL_PLATFORM_VERSION:
> -  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
> +  buf.as_string() = "OpenCL " + get_opencl_version() + " Mesa " 
> PACKAGE_VERSION
>  #ifdef MESA_GIT_SHA1
>  " (" MESA_GIT_SHA1 ")"
>  #endif
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp 
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index b5e8b52..6886dad 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> 

[Mesa-dev] [Bug 98241] dEQP GLES3.1 failure "Compute Shader should not have compiled with #version 300 es."

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98241

Bug ID: 98241
   Summary: dEQP GLES3.1 failure "Compute Shader should not have
compiled with #version 300 es."
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: glsl-compiler
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: randy...@intel.com
QA Contact: intel-3d-b...@lists.freedesktop.org

Three dEQP cases cannot pass, and show the "Compute Shader should not have
compiled with #version 300 es." error.

Mesa git top commit: 389d6dedbe75defe07216ad761569a9b94f44e58
dEQP git top commit: ca988480be945772473f9256b6ae91fa6aa62bd1

Reproduced on HSW and SKL

dEQP-GLES31.functional.debug.negative_coverage.callbacks.shader.compile_compute_shader.qpa:
Compute Shader should not have compiled with #version
300 es.
dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.compile_compute_shader.qpa:
Compute Shader should not have compiled with #version
300 es.
dEQP-GLES31.functional.debug.negative_coverage.log.shader.compile_compute_shader.qpa:
Compute Shader should not have compiled with #version
300 es.

-- 
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


[Mesa-dev] [Bug 98241] dEQP GLES3.1 failure "Compute Shader should not have compiled with #version 300 es."

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98241

Randy  changed:

   What|Removed |Added

 Blocks||94448


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=94448
[Bug 94448] double Everything's Quality, Please! (Fix all the dEQP bugs!)
-- 
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


[Mesa-dev] [Bug 98241] dEQP GLES3.1 failure "Compute Shader should not have compiled with #version 300 es."

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98241

Tapani Pälli  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Tapani Pälli  ---


*** This bug has been marked as a duplicate of bug 98132 ***

-- 
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


[Mesa-dev] [Bug 98132] #version 300 es compute shaders should not be possible

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98132

Tapani Pälli  changed:

   What|Removed |Added

 CC||randy...@intel.com

--- Comment #1 from Tapani Pälli  ---
*** Bug 98241 has been marked as a duplicate of this bug. ***

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


Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

2016-10-13 Thread Michel Dänzer
On 14/10/16 09:54 AM, Michel Dänzer wrote:
> On 13/10/16 11:16 PM, Mike Lothian wrote:
>> I think there were some issues with some programs / games that had
>> clashing symbols but I'm not sure if that's still an issue
> 
> I'm only aware of such issues with the Steam runtime, which are arguably
> because the current implementation (if not the design) of the Steam
> runtime is broken (in ways affecting libraries other than Mesa as well,
> so it's not like Mesa linking LLVM statically magically solves all Steam
> runtime issues).
> 
> BTW, AFAIK just linking LLVM statically into Mesa isn't enough to avoid
> these issues, one would also need to link libstdc++ statically into LLVM.

I forgot to mention that it's easy to avoid these issues via LD_PRELOAD.
I'm currently using this for Steam:

LD_PRELOAD='/$LIB/libgpg-error.so.0:/$LIB/libtinfo.so.5:/usr/$LIB/libstdc++.so.6:/usr/$LIB/libxcb.so.1':$LD_PRELOAD


-- 
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 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98172

--- Comment #13 from shinji.suz...@gmail.com ---
> So the second fence_reference call will find so->fence == NULL and do nothing.

Thank you. I failed to see that fence_reference(screen,,0) is no-op
thanks to "if (ptr != refererence)" in pipe_reference_descsribed().
I'll get back to you when I finish runnning some tests.

-- 
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 2/6] anv: port to using new u_vector shared helper.

2016-10-13 Thread Dave Airlie
From: Dave Airlie 

This just removes the anv vector code and uses the new helper.

Signed-off-by: Dave Airlie 
---
 src/intel/vulkan/anv_allocator.c   |  8 ++--
 src/intel/vulkan/anv_batch_chain.c | 40 ++--
 src/intel/vulkan/anv_private.h | 52 ++
 src/intel/vulkan/anv_util.c| 75 --
 src/intel/vulkan/anv_wsi_wayland.c | 14 +++
 5 files changed, 35 insertions(+), 154 deletions(-)

diff --git a/src/intel/vulkan/anv_allocator.c b/src/intel/vulkan/anv_allocator.c
index d5c033c..ae18f8e 100644
--- a/src/intel/vulkan/anv_allocator.c
+++ b/src/intel/vulkan/anv_allocator.c
@@ -272,7 +272,7 @@ anv_block_pool_init(struct anv_block_pool *pool,
if (ftruncate(pool->fd, BLOCK_POOL_MEMFD_SIZE) == -1)
   return;
 
-   anv_vector_init(>mmap_cleanups,
+   u_vector_init(>mmap_cleanups,
round_to_power_of_two(sizeof(struct anv_mmap_cleanup)), 
128);
 
pool->state.next = 0;
@@ -289,14 +289,14 @@ anv_block_pool_finish(struct anv_block_pool *pool)
 {
struct anv_mmap_cleanup *cleanup;
 
-   anv_vector_foreach(cleanup, >mmap_cleanups) {
+   u_vector_foreach(cleanup, >mmap_cleanups) {
   if (cleanup->map)
  munmap(cleanup->map, cleanup->size);
   if (cleanup->gem_handle)
  anv_gem_close(pool->device, cleanup->gem_handle);
}
 
-   anv_vector_finish(>mmap_cleanups);
+   u_vector_finish(>mmap_cleanups);
 
close(pool->fd);
 }
@@ -420,7 +420,7 @@ anv_block_pool_grow(struct anv_block_pool *pool, struct 
anv_block_state *state)
assert(center_bo_offset >= pool->back_state.end);
assert(size - center_bo_offset >= pool->state.end);
 
-   cleanup = anv_vector_add(>mmap_cleanups);
+   cleanup = u_vector_add(>mmap_cleanups);
if (!cleanup)
   goto fail;
*cleanup = ANV_MMAP_CLEANUP_INIT;
diff --git a/src/intel/vulkan/anv_batch_chain.c 
b/src/intel/vulkan/anv_batch_chain.c
index a98a0a9..4f6f0c2 100644
--- a/src/intel/vulkan/anv_batch_chain.c
+++ b/src/intel/vulkan/anv_batch_chain.c
@@ -434,7 +434,7 @@ anv_cmd_buffer_surface_base_address(struct anv_cmd_buffer 
*cmd_buffer)
 {
return (struct anv_address) {
   .bo = _buffer->device->surface_state_block_pool.bo,
-  .offset = *(int32_t *)anv_vector_head(_buffer->bt_blocks),
+  .offset = *(int32_t *)u_vector_head(_buffer->bt_blocks),
};
 }
 
@@ -494,7 +494,7 @@ anv_cmd_buffer_chain_batch(struct anv_batch *batch, void 
*_data)
if (result != VK_SUCCESS)
   return result;
 
-   struct anv_batch_bo **seen_bbo = anv_vector_add(_buffer->seen_bbos);
+   struct anv_batch_bo **seen_bbo = u_vector_add(_buffer->seen_bbos);
if (seen_bbo == NULL) {
   anv_batch_bo_destroy(new_bbo, cmd_buffer);
   return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
@@ -528,7 +528,7 @@ anv_cmd_buffer_alloc_binding_table(struct anv_cmd_buffer 
*cmd_buffer,
 {
struct anv_block_pool *block_pool =
_buffer->device->surface_state_block_pool;
-   int32_t *bt_block = anv_vector_head(_buffer->bt_blocks);
+   int32_t *bt_block = u_vector_head(_buffer->bt_blocks);
struct anv_state state;
 
state.alloc_size = align_u32(entries * 4, 32);
@@ -567,7 +567,7 @@ anv_cmd_buffer_new_binding_table_block(struct 
anv_cmd_buffer *cmd_buffer)
struct anv_block_pool *block_pool =
_buffer->device->surface_state_block_pool;
 
-   int32_t *offset = anv_vector_add(_buffer->bt_blocks);
+   int32_t *offset = u_vector_add(_buffer->bt_blocks);
if (offset == NULL)
   return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
 
@@ -603,15 +603,15 @@ anv_cmd_buffer_init_batch_bo_chain(struct anv_cmd_buffer 
*cmd_buffer)
anv_batch_bo_start(batch_bo, _buffer->batch,
   GEN8_MI_BATCH_BUFFER_START_length * 4);
 
-   int success = anv_vector_init(_buffer->seen_bbos,
+   int success = u_vector_init(_buffer->seen_bbos,
  sizeof(struct anv_bo *),
  8 * sizeof(struct anv_bo *));
if (!success)
   goto fail_batch_bo;
 
-   *(struct anv_batch_bo **)anv_vector_add(_buffer->seen_bbos) = batch_bo;
+   *(struct anv_batch_bo **)u_vector_add(_buffer->seen_bbos) = batch_bo;
 
-   success = anv_vector_init(_buffer->bt_blocks, sizeof(int32_t),
+   success = u_vector_init(_buffer->bt_blocks, sizeof(int32_t),
  8 * sizeof(int32_t));
if (!success)
   goto fail_seen_bbos;
@@ -630,9 +630,9 @@ anv_cmd_buffer_init_batch_bo_chain(struct anv_cmd_buffer 
*cmd_buffer)
return VK_SUCCESS;
 
  fail_bt_blocks:
-   anv_vector_finish(_buffer->bt_blocks);
+   u_vector_finish(_buffer->bt_blocks);
  fail_seen_bbos:
-   anv_vector_finish(_buffer->seen_bbos);
+   u_vector_finish(_buffer->seen_bbos);
  fail_batch_bo:
anv_batch_bo_destroy(batch_bo, cmd_buffer);
 
@@ -643,15 +643,15 @@ void
 anv_cmd_buffer_fini_batch_bo_chain(struct anv_cmd_buffer *cmd_buffer)
 {
int32_t *bt_block;
-   

[Mesa-dev] [PATCH 3/6] radv: make use of shared vector helper.

2016-10-13 Thread Dave Airlie
From: Dave Airlie 

This removes the vector code from radv in favour of sharing
code with anv.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_private.h | 53 
 src/amd/vulkan/radv_util.c| 74 ---
 src/amd/vulkan/radv_wsi_wayland.c | 16 -
 3 files changed, 8 insertions(+), 135 deletions(-)

diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 6db8c7a..1f5af62 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -238,59 +238,6 @@ void radv_abortfv(const char *format, va_list va) 
radv_noreturn;
return; \
} while (0)
 
-/**
- * A dynamically growable, circular buffer.  Elements are added at head and
- * removed from tail. head and tail are free-running uint32_t indices and we
- * only compute the modulo with size when accessing the array.  This way,
- * number of bytes in the queue is always head - tail, even in case of
- * wraparound.
- */
-
-struct radv_vector {
-   uint32_t head;
-   uint32_t tail;
-   uint32_t element_size;
-   uint32_t size;
-   void *data;
-};
-
-int radv_vector_init(struct radv_vector *queue, uint32_t element_size, 
uint32_t size);
-void *radv_vector_add(struct radv_vector *queue);
-void *radv_vector_remove(struct radv_vector *queue);
-
-static inline int
-radv_vector_length(struct radv_vector *queue)
-{
-   return (queue->head - queue->tail) / queue->element_size;
-}
-
-static inline void *
-radv_vector_head(struct radv_vector *vector)
-{
-   assert(vector->tail < vector->head);
-   return (void *)((char *)vector->data +
-   ((vector->head - vector->element_size) &
-(vector->size - 1)));
-}
-
-static inline void *
-radv_vector_tail(struct radv_vector *vector)
-{
-   return (void *)((char *)vector->data + (vector->tail & (vector->size - 1)));
-}
-
-static inline void
-radv_vector_finish(struct radv_vector *queue)
-{
-   free(queue->data);
-}
-
-#define radv_vector_foreach(elem, queue)  \
-   static_assert(__builtin_types_compatible_p(__typeof__(queue), struct 
radv_vector *), ""); \
-   for (uint32_t __radv_vector_offset = (queue)->tail; 
   \
-elem = (queue)->data + (__radv_vector_offset & ((queue)->size - 1)), 
__radv_vector_offset < (queue)->head; \
-__radv_vector_offset += (queue)->element_size)
-
 void *radv_resolve_entrypoint(uint32_t index);
 void *radv_lookup_entrypoint(const char *name);
 
diff --git a/src/amd/vulkan/radv_util.c b/src/amd/vulkan/radv_util.c
index bf7abd4..8c7a948 100644
--- a/src/amd/vulkan/radv_util.c
+++ b/src/amd/vulkan/radv_util.c
@@ -128,77 +128,3 @@ __vk_errorf(VkResult error, const char *file, int line, 
const char *format, ...)
return error;
 }
 
-int
-radv_vector_init(struct radv_vector *vector, uint32_t element_size, uint32_t 
size)
-{
-   assert(util_is_power_of_two(size));
-   assert(element_size < size && util_is_power_of_two(element_size));
-
-   vector->head = 0;
-   vector->tail = 0;
-   vector->element_size = element_size;
-   vector->size = size;
-   vector->data = malloc(size);
-
-   return vector->data != NULL;
-}
-
-void *
-radv_vector_add(struct radv_vector *vector)
-{
-   uint32_t offset, size, split, src_tail, dst_tail;
-   void *data;
-
-   if (vector->head - vector->tail == vector->size) {
-   size = vector->size * 2;
-   data = malloc(size);
-   if (data == NULL)
-   return NULL;
-   src_tail = vector->tail & (vector->size - 1);
-   dst_tail = vector->tail & (size - 1);
-   if (src_tail == 0) {
-   /* Since we know that the vector is full, this means 
that it's
-* linear from start to end so we can do one copy.
-*/
-   memcpy(data + dst_tail, vector->data, vector->size);
-   } else {
-   /* In this case, the vector is split into two pieces 
and we have
-* to do two copies.  We have to be careful to make 
sure each
-* piece goes to the right locations.  Thanks to the 
change in
-* size, it may or may not still wrap around.
-*/
-   split = align_u32(vector->tail, vector->size);
-   assert(vector->tail <= split && split < vector->head);
-   memcpy(data + dst_tail, vector->data + src_tail,
-  split - vector->tail);
-   memcpy(data + (split & (size - 1)), vector->data,
-  vector->head - split);
-   }
-   free(vector->data);
-   vector->data = data;
-   

[Mesa-dev] [PATCH 5/6] radv: drop local MIN/MAX macros.

2016-10-13 Thread Dave Airlie
From: Dave Airlie 

Use the ones in macros.h instead.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_private.h | 5 +
 src/amd/vulkan/radv_wsi_x11.c | 2 +-
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 1f5af62..8dddf70 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -85,9 +85,6 @@ typedef uint32_t xcb_window_t;
 #define radv_noreturn __attribute__((__noreturn__))
 #define radv_printflike(a, b) __attribute__((__format__(__printf__, a, b)))
 
-#define MIN(a, b) ((a) < (b) ? (a) : (b))
-#define MAX(a, b) ((a) > (b) ? (a) : (b))
-
 static inline uint32_t
 align_u32(uint32_t v, uint32_t a)
 {
@@ -141,7 +138,7 @@ radv_minify(uint32_t n, uint32_t levels)
if (unlikely(n == 0))
return 0;
else
-   return MAX(n >> levels, 1);
+   return MAX2(n >> levels, 1);
 }
 static inline float
 radv_clamp_f(float f, float min, float max)
diff --git a/src/amd/vulkan/radv_wsi_x11.c b/src/amd/vulkan/radv_wsi_x11.c
index 9cd0db0..8e0040f 100644
--- a/src/amd/vulkan/radv_wsi_x11.c
+++ b/src/amd/vulkan/radv_wsi_x11.c
@@ -823,7 +823,7 @@ x11_surface_create_swapchain(VkIcdSurfaceBase *icd_surface,
 *  4) One to render to
 */
if (pCreateInfo->presentMode == VK_PRESENT_MODE_MAILBOX_KHR)
-   num_images = MAX(num_images, 4);
+   num_images = MAX2(num_images, 4);
 
size_t size = sizeof(*chain) + num_images * sizeof(chain->images[0]);
chain = radv_alloc2(>alloc, pAllocator, size, 8,
-- 
2.5.5

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


[Mesa-dev] [PATCH 6/6] anv: drop local MIN/MAX macros.

2016-10-13 Thread Dave Airlie
From: Dave Airlie 

Use the ones from mesa, most places already did.

Signed-off-by: Dave Airlie 
---
 src/intel/vulkan/anv_image.c   | 2 +-
 src/intel/vulkan/anv_private.h | 5 +
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index f125aa6..b3bc489 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -108,7 +108,7 @@ add_surface(struct anv_image *image, struct anv_surface 
*surf)
 
surf->offset = align_u32(image->size, surf->isl.alignment);
image->size = surf->offset + surf->isl.size;
-   image->alignment = MAX(image->alignment, surf->isl.alignment);
+   image->alignment = MAX2(image->alignment, surf->isl.alignment);
 }
 
 /**
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 5980c40..1685f5b 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -81,9 +81,6 @@ extern "C" {
 #define anv_noreturn __attribute__((__noreturn__))
 #define anv_printflike(a, b) __attribute__((__format__(__printf__, a, b)))
 
-#define MIN(a, b) ((a) < (b) ? (a) : (b))
-#define MAX(a, b) ((a) > (b) ? (a) : (b))
-
 static inline uint32_t
 align_down_npot_u32(uint32_t v, uint32_t a)
 {
@@ -125,7 +122,7 @@ anv_minify(uint32_t n, uint32_t levels)
if (unlikely(n == 0))
   return 0;
else
-  return MAX(n >> levels, 1);
+  return MAX2(n >> levels, 1);
 }
 
 static inline float
-- 
2.5.5

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


[Mesa-dev] [PATCH 1/6] util: add vector util code.

2016-10-13 Thread Dave Airlie
From: Dave Airlie 

This is ported from anv, both anv and radv can share this.

Signed-off-by: Dave Airlie 
---
 src/util/Makefile.sources |  4 +-
 src/util/u_vector.c   | 98 +++
 src/util/u_vector.h   | 85 
 3 files changed, 186 insertions(+), 1 deletion(-)
 create mode 100644 src/util/u_vector.c
 create mode 100644 src/util/u_vector.h

diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index 8b17bcf..b7b1e91 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -35,7 +35,9 @@ MESA_UTIL_FILES :=\
strtod.h \
texcompress_rgtc_tmp.h \
u_atomic.h \
-   u_endian.h
+   u_endian.h \
+   u_vector.c \
+   u_vector.h
 
 MESA_UTIL_GENERATED_FILES = \
format_srgb.c
diff --git a/src/util/u_vector.c b/src/util/u_vector.c
new file mode 100644
index 000..37c4245
--- /dev/null
+++ b/src/util/u_vector.c
@@ -0,0 +1,98 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+#include "util/u_vector.h"
+
+int
+u_vector_init(struct u_vector *vector, uint32_t element_size, uint32_t size)
+{
+   assert(util_is_power_of_two(size));
+   assert(element_size < size && util_is_power_of_two(element_size));
+
+   vector->head = 0;
+   vector->tail = 0;
+   vector->element_size = element_size;
+   vector->size = size;
+   vector->data = malloc(size);
+
+   return vector->data != NULL;
+}
+
+void *
+u_vector_add(struct u_vector *vector)
+{
+   uint32_t offset, size, split, src_tail, dst_tail;
+   void *data;
+
+   if (vector->head - vector->tail == vector->size) {
+  size = vector->size * 2;
+  data = malloc(size);
+  if (data == NULL)
+ return NULL;
+  src_tail = vector->tail & (vector->size - 1);
+  dst_tail = vector->tail & (size - 1);
+  if (src_tail == 0) {
+ /* Since we know that the vector is full, this means that it's
+  * linear from start to end so we can do one copy.
+  */
+ memcpy((char *)data + dst_tail, vector->data, vector->size);
+  } else {
+ /* In this case, the vector is split into two pieces and we have
+  * to do two copies.  We have to be careful to make sure each
+  * piece goes to the right locations.  Thanks to the change in
+  * size, it may or may not still wrap around.
+  */
+ split = u_align_u32(vector->tail, vector->size);
+ assert(vector->tail <= split && split < vector->head);
+ memcpy((char *)data + dst_tail, (char *)vector->data + src_tail,
+split - vector->tail);
+ memcpy((char *)data + (split & (size - 1)), vector->data,
+vector->head - split);
+  }
+  free(vector->data);
+  vector->data = data;
+  vector->size = size;
+   }
+
+   assert(vector->head - vector->tail < vector->size);
+
+   offset = vector->head & (vector->size - 1);
+   vector->head += vector->element_size;
+
+   return (char *)vector->data + offset;
+}
+
+void *
+u_vector_remove(struct u_vector *vector)
+{
+   uint32_t offset;
+
+   if (vector->head == vector->tail)
+  return NULL;
+
+   assert(vector->head - vector->tail <= vector->size);
+
+   offset = vector->tail & (vector->size - 1);
+   vector->tail += vector->element_size;
+
+   return (char *)vector->data + offset;
+}
diff --git a/src/util/u_vector.h b/src/util/u_vector.h
new file mode 100644
index 000..ea52837
--- /dev/null
+++ b/src/util/u_vector.h
@@ -0,0 +1,85 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, 

[Mesa-dev] [PATCH 4/6] util: move min/max/clamp macros to util macros.h

2016-10-13 Thread Dave Airlie
From: Dave Airlie 

Although the vulkan drivers include mesa macros.h, for
radv I'd like to move away from that.

Signed-off-by: Dave Airlie 
---
 src/mesa/main/macros.h | 13 -
 src/util/macros.h  | 13 +
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/mesa/main/macros.h b/src/mesa/main/macros.h
index ed207d4..03a228b 100644
--- a/src/mesa/main/macros.h
+++ b/src/mesa/main/macros.h
@@ -660,19 +660,6 @@ INTERP_4F(GLfloat t, GLfloat dst[4], const GLfloat out[4], 
const GLfloat in[4])
 
 
 
-/** Clamp X to [MIN,MAX] */
-#define CLAMP( X, MIN, MAX )  ( (X)<(MIN) ? (MIN) : ((X)>(MAX) ? (MAX) : (X)) )
-
-/** Minimum of two values: */
-#define MIN2( A, B )   ( (A)<(B) ? (A) : (B) )
-
-/** Maximum of two values: */
-#define MAX2( A, B )   ( (A)>(B) ? (A) : (B) )
-
-/** Minimum and maximum of three values: */
-#define MIN3( A, B, C ) ((A) < (B) ? MIN2(A, C) : MIN2(B, C))
-#define MAX3( A, B, C ) ((A) > (B) ? MAX2(A, C) : MAX2(B, C))
-
 static inline unsigned
 minify(unsigned value, unsigned levels)
 {
diff --git a/src/util/macros.h b/src/util/macros.h
index 9dea2a0..27d1b62 100644
--- a/src/util/macros.h
+++ b/src/util/macros.h
@@ -229,4 +229,17 @@ do {   \
 /** Compute ceiling of integer quotient of A divided by B. */
 #define DIV_ROUND_UP( A, B )  ( (A) % (B) == 0 ? (A)/(B) : (A)/(B)+1 )
 
+/** Clamp X to [MIN,MAX] */
+#define CLAMP( X, MIN, MAX )  ( (X)<(MIN) ? (MIN) : ((X)>(MAX) ? (MAX) : (X)) )
+
+/** Minimum of two values: */
+#define MIN2( A, B )   ( (A)<(B) ? (A) : (B) )
+
+/** Maximum of two values: */
+#define MAX2( A, B )   ( (A)>(B) ? (A) : (B) )
+
+/** Minimum and maximum of three values: */
+#define MIN3( A, B, C ) ((A) < (B) ? MIN2(A, C) : MIN2(B, C))
+#define MAX3( A, B, C ) ((A) > (B) ? MAX2(A, C) : MAX2(B, C))
+
 #endif /* UTIL_MACROS_H */
-- 
2.5.5

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


Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

2016-10-13 Thread Michel Dänzer
On 13/10/16 07:14 PM, Emil Velikov wrote:
> On 13 October 2016 at 04:07, Michel Dänzer  wrote:
>> On 13/10/16 03:37 AM, Tobias Droste wrote:
>>> Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov:
>
> +LLVM_VERSION_REQUIRED_OPENCL=3.6.0
> +LLVM_VERSION_REQUIRED_R600=3.6.0
> +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0

 There's a small related gotcha: as-is at build time we get the
 different codepaths thus, as people build against shared LLVM (hello
 Archlinux, I'm looking at you) and update their LLVM without
 rebuilding mesa (Arch I'm looking at you again) things go funny.
>>
>> What exactly happened there? LLVM upstream generates shared libraries
>> named libLLVM-..so*, so it shouldn't be possible for a
>> simple LLVM package update to break Mesa, unless Arch did something
>> really stupid.
>>
> The issue is not specific to Arch, but anyone who links against shared LLVM.
> 
> Here is another take on it:
> At least swr and r600/radeonsi depend at _build_ time on the _patch_
> version of LLVM. The latter of which is not part of the DSO name. Thus
> at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the
> "3.9.x" codepath even though you are be using "3.9.y" LLVM.

That should be fine, since 3.9.y is backwards compatible with 3.9.x.

Debian doesn't automatically recompile Mesa in such cases either, and I
haven't seen any problems there because of that.

So, what exactly was the problem?


 Tl;Dr; We really want to enable static linking by default and prod
 distros to use it.
>>>
>>> I'm all in favor of statically linking LLVM (that's the way I'm doing this 
>>> on
>>> my pc).
>>> I think the only reason this is not done is because people (also here on the
>>> list) don't want any static linkg of external libraries because of size or
>>> whatever.
>>> So changing the default to static is easy, but I doubt it will make everyone
>>> happy ;-)
>>
>> Indeed, it'd probably make many distro packagers unhappy, because
>> they'll just have to re-enable shared linking, because packaging
>> policies generally strongly discourage if not outright forbid static
>> linking.
>>
> The toggle is there and is not going away, afaict. If people are going
> to get upset that the default does not meet their policy... just
> toggle and get on with other things ;-)

The question is if it makes sense for the default to be different from
what the majority of users end up using. It doesn't to me.


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

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


Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

2016-10-13 Thread Michel Dänzer
On 13/10/16 11:16 PM, Mike Lothian wrote:
> If you recompile llvm and mesa each time, are there any downsides of
> using the shared libs?

No particular downsides come to mind, rather upsides:

* Generally no requirement to rebuild Mesa after changes to LLVM.
* Both LLVM and Mesa take significantly less time, memory and disk
  space to build.


> I think there were some issues with some programs / games that had
> clashing symbols but I'm not sure if that's still an issue

I'm only aware of such issues with the Steam runtime, which are arguably
because the current implementation (if not the design) of the Steam
runtime is broken (in ways affecting libraries other than Mesa as well,
so it's not like Mesa linking LLVM statically magically solves all Steam
runtime issues).

BTW, AFAIK just linking LLVM statically into Mesa isn't enough to avoid
these issues, one would also need to link libstdc++ statically into LLVM.


-- 
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 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98172

--- Comment #12 from Michel Dänzer  ---
It should be fine. You're right that fence_finish can run concurrently in
multiple threads, but even if it returns true in multiple threads, the
fence_reference calls are serialized by the mutex. So the second
fence_reference call will find so->fence == NULL and do nothing.

Have you run into any problems with this patch in your testing?

-- 
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] draw: improved handling of undefined inputs

2016-10-13 Thread sroland
From: Roland Scheidegger 

Previous attempts to zero initialize all inputs were not really optimal
(though no performance impact was measurable). In fact this is not really
necessary, since we know the max number of inputs used.
Instead, just generate fetch for up to max inputs used by the shader,
directly replacing inputs for which there was no vertex element by zero.
This also cleans up key generation, which previously would have stored
some garbage for these elements.
And also drop the assertion which indicates such bogus usage by a
debug_printf (the whole point of initializing the undefined inputs was to
make this case safe to handle).
---
 src/gallium/auxiliary/draw/draw_llvm.c | 53 --
 1 file changed, 32 insertions(+), 21 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_llvm.c 
b/src/gallium/auxiliary/draw/draw_llvm.c
index 4270a8f..3b56856 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -689,6 +689,11 @@ generate_fetch(struct gallivm_state *gallivm,
LLVMValueRef ofbit = NULL;
struct lp_build_if_state if_ctx;
 
+   if (velem->src_format == PIPE_FORMAT_NONE) {
+  *res = lp_build_const_vec(gallivm, lp_float32_vec4_type(), 0);
+  return;
+   }
+
if (velem->instance_divisor) {
   /* Index is equal to the start instance plus the number of current 
* instance divided by the divisor. In this case we compute it as:
@@ -1706,12 +1711,6 @@ draw_llvm_generate(struct draw_llvm *llvm, struct 
draw_llvm_variant *variant,
   io_itr, io, lp_loop.counter);
 #endif
 
-  for (j = draw->pt.nr_vertex_elements; j < PIPE_MAX_SHADER_INPUTS; j++) {
- for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
-inputs[j][i] = lp_build_zero(gallivm, vs_type);
- }
-  }
-
   for (i = 0; i < vector_length; ++i) {
  LLVMValueRef vert_index =
 LLVMBuildAdd(builder,
@@ -1765,7 +1764,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct 
draw_llvm_variant *variant,
 gallivm->builder, true_index_array, true_index,
 lp_build_const_int32(gallivm, i), "");
 
- for (j = 0; j < draw->pt.nr_vertex_elements; ++j) {
+ for (j = 0; j < key->nr_vertex_elements; ++j) {
 struct pipe_vertex_element *velem = >pt.vertex_element[j];
 LLVMValueRef vb_index =
lp_build_const_int32(gallivm, velem->vertex_buffer_index);
@@ -1776,7 +1775,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct 
draw_llvm_variant *variant,
  }
   }
   convert_to_soa(gallivm, aos_attribs, inputs,
- draw->pt.nr_vertex_elements, vs_type);
+ key->nr_vertex_elements, vs_type);
 
   /* In the paths with elts vertex id has to be unaffected by the
* index bias and because indices inside our elements array have
@@ -1873,15 +1872,6 @@ draw_llvm_make_variant_key(struct draw_llvm *llvm, char 
*store)
 
key->clamp_vertex_color = llvm->draw->rasterizer->clamp_vertex_color; /**/
 
-   /* Presumably all variants of the shader should have the same
-* number of vertex elements - ie the number of shader inputs.
-* NOTE: we NEED to store the needed number of needed inputs
-* here, not the number of provided elements to match keysize
-* (and the offset of sampler state in the key).
-*/
-   key->nr_vertex_elements = 
llvm->draw->vs.vertex_shader->info.file_max[TGSI_FILE_INPUT] + 1;
-   assert(key->nr_vertex_elements <= llvm->draw->pt.nr_vertex_elements);
-
/* will have to rig this up properly later */
key->clip_xy = llvm->draw->clip_xy;
key->clip_z = llvm->draw->clip_z;
@@ -1907,13 +1897,34 @@ draw_llvm_make_variant_key(struct draw_llvm *llvm, char 
*store)
   key->nr_sampler_views = key->nr_samplers;
}
 
-   draw_sampler = draw_llvm_variant_key_samplers(key);
-
+   /* Presumably all variants of the shader should have the same
+* number of vertex elements - ie the number of shader inputs.
+* NOTE: we NEED to store the needed number of needed inputs
+* here, not the number of provided elements to match keysize
+* (and the offset of sampler state in the key).
+* If we have excess number of vertex elements, this is valid,
+* but the excess ones don't matter.
+* If we don't have enough vertex elements (which looks not really
+* valid but we'll handle it gracefully) fill out missing ones with
+* zero (we'll recognize these later by PIPE_FORMAT_NONE).
+*/
+   key->nr_vertex_elements =
+  llvm->draw->vs.vertex_shader->info.file_max[TGSI_FILE_INPUT] + 1;
+
+   if (llvm->draw->pt.nr_vertex_elements < key->nr_vertex_elements) {
+  debug_printf("draw: vs with %d inputs but only have %d vertex 
elements\n",
+   key->nr_vertex_elements, llvm->draw->pt.nr_vertex_elements);
+  memset(key->vertex_element, 0,
+ sizeof(struct 

[Mesa-dev] [Bug 98223] dEQP GLES3.1 program_interface_query failures w/ error "could not find target resource"

2016-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98223

--- Comment #7 from Randy  ---
(In reply to Alejandro Piñeiro (freenode IRC: apinheiro) from comment #6)
> 
> The problem is that the spec is contradictory. The patch on that link (that
> btw, the author is Kenneth, that wrote comment 1) fixes some deqp and CTS
> tests. But it causes some regressions on others, like you mention below.
> 
> So at this point, I really think that it would be better to wait for a
> resolution from Khronos on relation to the text of the spec, issue 16 in
> particular, and then fix the tests.
>

Thanks and agree.

-- 
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


[Mesa-dev] [PATCH] docs: Fix GL status of radeonsi

2016-10-13 Thread Andreas Boll
Currently radeonsi doesn't advertise GLSL 4.40 and "GL 4.4, GLSL 4.40 --
all DONE" means the driver actually advertises GL 4.4 and GLSL 4.40.

So as long as radeonsi doesn't enable GLSL >= 4.40 it's not "all DONE".

Fixes: 789119d21 ("st/mesa: enable ARB_enhanced_layouts and turn the cap on")
Signed-off-by: Andreas Boll 
---
 docs/features.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ec2634f..9cc9111 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -188,23 +188,23 @@ GL 4.3, GLSL 4.30 -- all DONE: i965/gen8+, nvc0, radeonsi
   GL_ARB_vertex_attrib_binding  DONE (all drivers)
 
 
-GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
+GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+
 
   GL_MAX_VERTEX_ATTRIB_STRIDE   DONE (all drivers)
-  GL_ARB_buffer_storage DONE (i965, nv50, 
nvc0, r600)
-  GL_ARB_clear_texture  DONE (i965, nv50, 
nvc0, r600)
-  GL_ARB_enhanced_layouts   DONE (i965, llvmpipe, 
softpipe)
+  GL_ARB_buffer_storage DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_clear_texture  DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_enhanced_layouts   DONE (i965, radeonsi, 
llvmpipe, softpipe)
   - compile-time constant expressions   DONE
   - explicit byte offsets for blocksDONE
   - forced alignment within blocks  DONE
-  - specified vec4-slot component numbers   DONE (i965, llvmpipe, 
softpipe)
+  - specified vec4-slot component numbers   DONE (i965, radeonsi, 
llvmpipe, softpipe)
   - specified transform/feedback layout DONE
   - input/output block locationsDONE
   GL_ARB_multi_bind DONE (all drivers)
-  GL_ARB_query_buffer_objectDONE (i965/hsw+, nvc0)
-  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
-  GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
-  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
+  GL_ARB_query_buffer_objectDONE (i965/hsw+, nvc0, 
radeonsi)
+  GL_ARB_texture_mirror_clamp_to_edge   DONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
+  GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
+  GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
 
 GL 4.5, GLSL 4.50:
 
-- 
2.1.4

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


Re: [Mesa-dev] [PATCH v2] doc/features.txt: factor out nvc0/radeonsi as GL45 complete

2016-10-13 Thread Andreas Boll
nak, neither radeonsi nor i965 advertise GLSL 4.50.
Nicolai hasn't pushed the patch to enable GLSL 4.50 [1].
I'm not sure what's the plan for nouveau is [2].

See also https://patchwork.freedesktop.org/patch/115441/

Thanks,
Andreas

[1] https://patchwork.freedesktop.org/patch/114577/
[2] https://patchwork.freedesktop.org/patch/114522/

2016-10-13 9:40 GMT+02:00 Edward O'Callaghan :
> Signed-off-by: Edward O'Callaghan 
> ---
>  docs/features.txt | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/docs/features.txt b/docs/features.txt
> index ec2634f..a5c8750 100644
> --- a/docs/features.txt
> +++ b/docs/features.txt
> @@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
>GL_ARB_texture_stencil8   DONE (i965/hsw+, 
> nv50, nvc0, r600, llvmpipe, softpipe, swr)
>GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
> nvc0, r600, llvmpipe, softpipe, swr)
>
> -GL 4.5, GLSL 4.50:
> +GL 4.5, GLSL 4.50 -- all DONE: i965/hsw+, nvc0, radeonsi
>
> -  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+, 
> nvc0, radeonsi)
> -  GL_ARB_clip_control   DONE (i965, nv50, 
> nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
> -  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
> nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
> -  GL_ARB_cull_distance  DONE (i965, nv50, 
> nvc0, radeonsi, llvmpipe, softpipe, swr)
> -  GL_ARB_derivative_control DONE (i965, nv50, 
> nvc0, r600, radeonsi)
> +  GL_ARB_ES3_1_compatibilityDONE
> +  GL_ARB_clip_control   DONE (nv50, r600, 
> llvmpipe, softpipe, swr)
> +  GL_ARB_conditional_render_invertedDONE (nv50, r600, 
> llvmpipe, softpipe, swr)
> +  GL_ARB_cull_distance  DONE (nv50, 
> llvmpipe, softpipe, swr)
> +  GL_ARB_derivative_control DONE (nv50, r600)
>GL_ARB_direct_state_accessDONE (all drivers)
>GL_ARB_get_texture_sub_image  DONE (all drivers)
> -  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, 
> nvc0, r600, radeonsi)
> -  GL_ARB_texture_barrierDONE (i965, nv50, 
> nvc0, r600, radeonsi)
> +  GL_ARB_shader_texture_image_samples   DONE (nv50, r600)
> +  GL_ARB_texture_barrierDONE (nv50, r600)
>GL_KHR_context_flush_control  DONE (all - but 
> needs GLX/EGL extension to be useful)
> -  GL_KHR_robustness DONE (i965, nvc0, 
> radeonsi)
> +  GL_KHR_robustness DONE
>GL_EXT_shader_integer_mix DONE (all drivers 
> that support GLSL)
>
>  These are the extensions cherry-picked to make GLES 3.1
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] doc/features.txt: factor out nvc0/radeonsi as GL45 complete

2016-10-13 Thread Edward O'Callaghan
Signed-off-by: Edward O'Callaghan 
---
 docs/features.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ec2634f..b15ec35 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
   GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
   GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
 
-GL 4.5, GLSL 4.50:
+GL 4.5, GLSL 4.50 -- all DONE: nvc0, radeonsi
 
-  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+, nvc0, 
radeonsi)
-  GL_ARB_clip_control   DONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_cull_distance  DONE (i965, nv50, 
nvc0, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_derivative_control DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+)
+  GL_ARB_clip_control   DONE (i965, nv50, 
r600, llvmpipe, softpipe, swr)
+  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
r600, llvmpipe, softpipe, swr)
+  GL_ARB_cull_distance  DONE (i965, nv50, 
llvmpipe, softpipe, swr)
+  GL_ARB_derivative_control DONE (i965, nv50, r600)
   GL_ARB_direct_state_accessDONE (all drivers)
   GL_ARB_get_texture_sub_image  DONE (all drivers)
-  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, 
nvc0, r600, radeonsi)
-  GL_ARB_texture_barrierDONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, r600)
+  GL_ARB_texture_barrierDONE (i965, nv50, r600)
   GL_KHR_context_flush_control  DONE (all - but needs 
GLX/EGL extension to be useful)
-  GL_KHR_robustness DONE (i965, nvc0, 
radeonsi)
+  GL_KHR_robustness DONE (i965)
   GL_EXT_shader_integer_mix DONE (all drivers that 
support GLSL)
 
 These are the extensions cherry-picked to make GLES 3.1
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH 1/2] st/mesa: Take local references for sync object fences

2016-10-13 Thread Nicolai Hähnle

On 13.10.2016 05:45, Michel Dänzer wrote:

On 12/10/16 08:52 PM, Nicolai Hähnle wrote:

On 12.10.2016 11:31, Michel Dänzer wrote:


diff --git a/src/mesa/state_tracker/st_cb_syncobj.c
b/src/mesa/state_tracker/st_cb_syncobj.c
index 123925a..de01880 100644
--- a/src/mesa/state_tracker/st_cb_syncobj.c
+++ b/src/mesa/state_tracker/st_cb_syncobj.c
@@ -81,17 +81,22 @@ static void st_check_sync(struct gl_context *ctx,
struct gl_sync_object *obj)
struct pipe_context *pipe = st_context(ctx)->pipe;
struct pipe_screen *screen = pipe->screen;
struct st_sync_object *so = (struct st_sync_object*)obj;
+   struct pipe_fence_handle *fence = NULL;
+
+   screen->fence_reference(screen, , so->fence);


This should probably really use p_atomic_read (or some kind of READ_ONCE
macro if we had it) to make the intention clear, but I'm not sure
whether that would compile everywhere since so->fence is a pointer.

In practice it doesn't matter, because the function call is a sufficient
barrier. So either way,

Reviewed-by: Nicolai Hähnle 


Thanks, but unfortunately,
https://bugs.freedesktop.org/show_bug.cgi?id=98172#c5 shows that this
really isn't good enough yet. Back to the drawing board...


I expect that most of the gallium *_reference functions need a similar 
treatment in order to be able to do atomic reference changes.


Nicolai




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


[Mesa-dev] [PATCH 1/7] nir: move nir_shader_info to a common compiler header

2016-10-13 Thread Timothy Arceri
This will allow use to stop copying values between structs and
will also simplify handling handling these values in the shader cache.
---
 src/compiler/nir/nir.h  |  98 +---
 src/compiler/shader_info.h  | 123 
 src/mesa/drivers/dri/i965/brw_nir.c |   2 +-
 3 files changed, 126 insertions(+), 97 deletions(-)
 create mode 100644 src/compiler/shader_info.h

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index d6c8efa..04b0301 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -37,6 +37,7 @@
 #include "util/macros.h"
 #include "compiler/nir_types.h"
 #include "compiler/shader_enums.h"
+#include "compiler/shader_info.h"
 #include 
 
 #include "nir_opcodes.h"
@@ -1783,101 +1784,6 @@ typedef struct nir_shader_compiler_options {
bool use_interpolated_input_intrinsics;
 } nir_shader_compiler_options;
 
-typedef struct nir_shader_info {
-   const char *name;
-
-   /* Descriptive name provided by the client; may be NULL */
-   const char *label;
-
-   /* Number of textures used by this shader */
-   unsigned num_textures;
-   /* Number of uniform buffers used by this shader */
-   unsigned num_ubos;
-   /* Number of atomic buffers used by this shader */
-   unsigned num_abos;
-   /* Number of shader storage buffers used by this shader */
-   unsigned num_ssbos;
-   /* Number of images used by this shader */
-   unsigned num_images;
-
-   /* Which inputs are actually read */
-   uint64_t inputs_read;
-   /* Which inputs are actually read and are double */
-   uint64_t double_inputs_read;
-   /* Which outputs are actually written */
-   uint64_t outputs_written;
-   /* Which outputs are actually read */
-   uint64_t outputs_read;
-   /* Which system values are actually read */
-   uint64_t system_values_read;
-
-   /* Which patch inputs are actually read */
-   uint32_t patch_inputs_read;
-   /* Which patch outputs are actually written */
-   uint32_t patch_outputs_written;
-
-   /* Whether or not this shader ever uses textureGather() */
-   bool uses_texture_gather;
-
-   /* Whether or not this shader uses the gl_ClipDistance output */
-   bool uses_clip_distance_out;
-
-   /* Whether or not separate shader objects were used */
-   bool separate_shader;
-
-   /** Was this shader linked with any transform feedback varyings? */
-   bool has_transform_feedback_varyings;
-
-   union {
-  struct {
- /** The number of vertices recieves per input primitive */
- unsigned vertices_in;
-
- /** The output primitive type (GL enum value) */
- unsigned output_primitive;
-
- /** The maximum number of vertices the geometry shader might write. */
- unsigned vertices_out;
-
- /** 1 .. MAX_GEOMETRY_SHADER_INVOCATIONS */
- unsigned invocations;
-
- /** Whether or not this shader uses EndPrimitive */
- bool uses_end_primitive;
-
- /** Whether or not this shader uses non-zero streams */
- bool uses_streams;
-  } gs;
-
-  struct {
- bool uses_discard;
-
- /**
-  * Whether any inputs are declared with the "sample" qualifier.
-  */
- bool uses_sample_qualifier;
-
- /**
-  * Whether early fragment tests are enabled as defined by
-  * ARB_shader_image_load_store.
-  */
- bool early_fragment_tests;
-
- /** gl_FragDepth layout for ARB_conservative_depth. */
- enum gl_frag_depth_layout depth_layout;
-  } fs;
-
-  struct {
- unsigned local_size[3];
-  } cs;
-
-  struct {
- /** The number of vertices in the TCS output patch. */
- unsigned vertices_out;
-  } tcs;
-   };
-} nir_shader_info;
-
 typedef struct nir_shader {
/** list of uniforms (nir_variable) */
struct exec_list uniforms;
@@ -1899,7 +1805,7 @@ typedef struct nir_shader {
const struct nir_shader_compiler_options *options;
 
/** Various bits of compile-time information about a given shader */
-   struct nir_shader_info info;
+   struct shader_info info;
 
/** list of global variables in the shader (nir_variable) */
struct exec_list globals;
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
new file mode 100644
index 000..68800a1
--- /dev/null
+++ b/src/compiler/shader_info.h
@@ -0,0 +1,123 @@
+/*
+ * Copyright © 2016 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) 

[Mesa-dev] RFC - shared shader info (Part 1)

2016-10-13 Thread Timothy Arceri
Having these fields directly in nir_shader makes things difficult for
the shader cache. This series creates a shared shader info and makes a
start at the large amount of clean-ups this will enable.

I decided to send this before getting too carried away to make sure
people are happy with this change. If everyones happy I'll start work
on part 2.

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


[Mesa-dev] [PATCH 7/7] mesa/i965: eliminate gl_tess_ctrl_program and use new shared shader_info

2016-10-13 Thread Timothy Arceri
---
 src/mesa/drivers/dri/i965/brw_context.h   |  6 ++---
 src/mesa/drivers/dri/i965/brw_draw.c  |  2 +-
 src/mesa/drivers/dri/i965/brw_program.c   |  2 +-
 src/mesa/drivers/dri/i965/brw_tcs.c   | 32 ++-
 src/mesa/drivers/dri/i965/brw_tcs_surface_state.c |  2 +-
 src/mesa/drivers/dri/i965/brw_tes.c   | 20 +++---
 src/mesa/drivers/dri/i965/gen7_hs_state.c |  4 +--
 src/mesa/main/context.c   |  2 +-
 src/mesa/main/mtypes.h| 12 +
 src/mesa/main/shaderapi.c |  4 +--
 src/mesa/main/state.c |  9 +++
 src/mesa/program/prog_statevars.c |  2 +-
 src/mesa/program/program.c|  4 +--
 src/mesa/program/program.h| 23 
 src/mesa/state_tracker/st_atom.c  |  2 +-
 src/mesa/state_tracker/st_atom_constbuf.c |  2 +-
 src/mesa/state_tracker/st_atom_sampler.c  |  2 +-
 src/mesa/state_tracker/st_atom_shader.c   |  2 +-
 src/mesa/state_tracker/st_atom_texture.c  |  2 +-
 src/mesa/state_tracker/st_cb_program.c| 10 +++
 src/mesa/state_tracker/st_program.c   |  6 ++---
 src/mesa/state_tracker/st_program.h   |  6 ++---
 22 files changed, 57 insertions(+), 99 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index c92bb9f..9b7e184 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -337,7 +337,7 @@ struct brw_vertex_program {
 
 /** Subclass of Mesa tessellation control program */
 struct brw_tess_ctrl_program {
-   struct gl_tess_ctrl_program program;
+   struct gl_program program;
unsigned id;  /**< serial no. to identify tess ctrl progs, never re-used */
 };
 
@@ -1008,7 +1008,7 @@ struct brw_context
 */
const struct gl_vertex_program *vertex_program;
const struct gl_geometry_program *geometry_program;
-   const struct gl_tess_ctrl_program *tess_ctrl_program;
+   const struct gl_program *tess_ctrl_program;
const struct gl_tess_eval_program *tess_eval_program;
const struct gl_fragment_program *fragment_program;
const struct gl_compute_program *compute_program;
@@ -1730,7 +1730,7 @@ brw_vertex_program_const(const struct gl_vertex_program 
*p)
 }
 
 static inline struct brw_tess_ctrl_program *
-brw_tess_ctrl_program(struct gl_tess_ctrl_program *p)
+brw_tess_ctrl_program(struct gl_program *p)
 {
return (struct brw_tess_ctrl_program *) p;
 }
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 5d176ef..5485de3 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -458,7 +458,7 @@ brw_try_draw_prims(struct gl_context *ctx,
brw->tes.base.sampler_count = ctx->TessEvalProgram._Current ?
   util_last_bit(ctx->TessEvalProgram._Current->Base.SamplersUsed) : 0;
brw->tcs.base.sampler_count = ctx->TessCtrlProgram._Current ?
-  util_last_bit(ctx->TessCtrlProgram._Current->Base.SamplersUsed) : 0;
+  util_last_bit(ctx->TessCtrlProgram._Current->SamplersUsed) : 0;
brw->vs.base.sampler_count =
   util_last_bit(ctx->VertexProgram._Current->Base.SamplersUsed);
 
diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index a41f36e..4e0df5a 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -168,7 +168,7 @@ static struct gl_program *brwNewProgram( struct gl_context 
*ctx,
   if (prog) {
  prog->id = get_new_program_id(brw->screen);
 
- return _mesa_init_gl_program(>program.Base, target, id);
+ return _mesa_init_gl_program(>program, target, id);
   } else {
  return NULL;
   }
diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c 
b/src/mesa/drivers/dri/i965/brw_tcs.c
index 0f03fab..08cf413 100644
--- a/src/mesa/drivers/dri/i965/brw_tcs.c
+++ b/src/mesa/drivers/dri/i965/brw_tcs.c
@@ -178,7 +178,7 @@ brw_codegen_tcs_prog(struct brw_context *brw,
double start_time = 0;
 
if (tcp) {
-  nir = tcp->program.Base.nir;
+  nir = tcp->program.nir;
} else {
   /* Create a dummy nir_shader.  We won't actually use NIR code to
* generate assembly (it's easier to generate assembly directly),
@@ -211,14 +211,14 @@ brw_codegen_tcs_prog(struct brw_context *brw,
 
if (tcs) {
   brw_assign_common_binding_table_offsets(MESA_SHADER_TESS_CTRL, devinfo,
-  shader_prog, >program.Base,
+  shader_prog, >program,
   _data.base.base, 0);
 
   prog_data.base.base.image_param =
  rzalloc_array(NULL, struct brw_image_param, tcs->NumImages);
   

[Mesa-dev] [PATCH 3/7] compiler: add fields for tes metadata to shader info

2016-10-13 Thread Timothy Arceri
---
 src/compiler/shader_info.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 68800a1..8266fc3 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -117,6 +117,13 @@ typedef struct shader_info {
  /** The number of vertices in the TCS output patch. */
  unsigned vertices_out;
   } tcs;
+
+  struct {
+ uint32_t primitive_mode; /* GL_TRIANGLES, GL_QUADS or GL_ISOLINES */
+ uint32_t spacing;/* GL_EQUAL, GL_FRACTIONAL_EVEN, 
GL_FRACTIONAL_ODD */
+ uint32_t vertex_order;   /* GL_CW or GL_CCW */
+ bool point_mode;
+  } tes;
};
 } shader_info;
 
-- 
2.7.4

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


[Mesa-dev] [PATCH 4/7] compiler: add input primative field for gs in shader info

2016-10-13 Thread Timothy Arceri
---
 src/compiler/shader_info.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 8266fc3..502c7c8 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -78,6 +78,9 @@ typedef struct shader_info {
  /** The output primitive type (GL enum value) */
  unsigned output_primitive;
 
+ /** The input primitive type (GL enum value) */
+ unsigned input_primitive;
+
  /** The maximum number of vertices the geometry shader might write. */
  unsigned vertices_out;
 
-- 
2.7.4

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


[Mesa-dev] [PATCH 5/7] compiler: add additional cs metadata fields to shader info

2016-10-13 Thread Timothy Arceri
---
 src/compiler/shader_info.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 502c7c8..66e06ad 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -114,6 +114,16 @@ typedef struct shader_info {
 
   struct {
  unsigned local_size[3];
+
+ /**
+  * Size of shared variables accessed by the compute shader.
+  */
+ unsigned shared_size;
+
+ /**
+  * Whether a variable work group size has been specified.
+  */
+ bool local_size_variable;
   } cs;
 
   struct {
-- 
2.7.4

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


[Mesa-dev] [PATCH 6/7] glsl: add a shader info field to the gl_program type

2016-10-13 Thread Timothy Arceri
And use this field as the source for shader info in the nir_shader
this will allow us to set some of these fields from GLSL directly.

It will also simplify restoring from shader cache and allow the
removal of duplicate fields from GLSL.
---
 src/compiler/glsl/glsl_to_nir.cpp | 3 ++-
 src/mesa/main/mtypes.h| 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index b531892..934c9d1 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -136,7 +136,8 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
 {
struct gl_linked_shader *sh = shader_prog->_LinkedShaders[stage];
 
-   nir_shader *shader = nir_shader_create(NULL, stage, options, NULL);
+   nir_shader *shader = nir_shader_create(NULL, stage, options,
+  >Program->info);
 
nir_visitor v1(shader);
nir_function_visitor v2();
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index ab9839c..c025040 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -43,6 +43,7 @@
 #include "glapi/glapi.h"
 #include "math/m_matrix.h" /* GLmatrix */
 #include "compiler/shader_enums.h"
+#include "compiler/shader_info.h"
 #include "main/formats.h"   /* MESA_FORMAT_COUNT */
 #include "compiler/glsl/list.h"
 #include "util/bitscan.h"
@@ -1919,6 +1920,8 @@ struct gl_program
 
struct nir_shader *nir;
 
+   struct shader_info info;
+
GLbitfield64 InputsRead; /**< Bitmask of which input regs are read */
GLbitfield64 DoubleInputsRead; /**< Bitmask of which input regs are 
read  and are doubles */
GLbitfield64 OutputsWritten; /**< Bitmask of which output regs are written 
*/
-- 
2.7.4

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


Re: [Mesa-dev] Mesa (master): st/glsl_to_tgsi: simpler fixup of empty writemasks

2016-10-13 Thread Michel Dänzer
On 13/10/16 04:26 PM, Nicolai Hähnle wrote:
> Hi Michel,
> 
> On 13.10.2016 08:42, Michel Dänzer wrote:
>> On 13/10/16 01:50 AM, Nicolai Hähnle wrote:
>>> Module: Mesa
>>> Branch: master
>>> Commit: f5f3cadca3809952288e3726ed5fde22090dc61d
>>> URL:   
>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=f5f3cadca3809952288e3726ed5fde22090dc61d
>>>
>>>
>>> Author: Nicolai Hähnle 
>>> Date:   Fri Oct  7 12:49:36 2016 +0200
>>>
>>> st/glsl_to_tgsi: simpler fixup of empty writemasks
>>
>> This change broke the piglit tests
>> spec@glsl-110@execution@variable-indexing@vs-temp-array-mat2-index(-col)-wr
>>
>> on my Kaveri. Output with R600_DEBUG=ps,vs attached as
>> vs-temp-array-mat2-index-wr.txt .
>>
>>
>> P.S. The newly enabled tests
>> spec@arb_enhanced_layouts@execution@component-layout@vs-tcs-load-output(-indirect)
>>
>> also fail, output attached as vs-tcs-load-output.stderr .
> 
> Thanks, it's on my radar. As far as I can tell, Mesa is doing the right
> thing here and LLVM is the problem, and working around it in Mesa may
> not be possible or reliable. But it's on my list of things to fix properly.

Excellent, thanks.


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


[Mesa-dev] [PATCH v2] doc/features.txt: factor out nvc0/radeonsi as GL45 complete

2016-10-13 Thread Edward O'Callaghan
Signed-off-by: Edward O'Callaghan 
---
 docs/features.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ec2634f..a5c8750 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
   GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
   GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
 
-GL 4.5, GLSL 4.50:
+GL 4.5, GLSL 4.50 -- all DONE: i965/hsw+, nvc0, radeonsi
 
-  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+, nvc0, 
radeonsi)
-  GL_ARB_clip_control   DONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_cull_distance  DONE (i965, nv50, 
nvc0, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_derivative_control DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_ES3_1_compatibilityDONE
+  GL_ARB_clip_control   DONE (nv50, r600, 
llvmpipe, softpipe, swr)
+  GL_ARB_conditional_render_invertedDONE (nv50, r600, 
llvmpipe, softpipe, swr)
+  GL_ARB_cull_distance  DONE (nv50, llvmpipe, 
softpipe, swr)
+  GL_ARB_derivative_control DONE (nv50, r600)
   GL_ARB_direct_state_accessDONE (all drivers)
   GL_ARB_get_texture_sub_image  DONE (all drivers)
-  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, 
nvc0, r600, radeonsi)
-  GL_ARB_texture_barrierDONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_shader_texture_image_samples   DONE (nv50, r600)
+  GL_ARB_texture_barrierDONE (nv50, r600)
   GL_KHR_context_flush_control  DONE (all - but needs 
GLX/EGL extension to be useful)
-  GL_KHR_robustness DONE (i965, nvc0, 
radeonsi)
+  GL_KHR_robustness DONE
   GL_EXT_shader_integer_mix DONE (all drivers that 
support GLSL)
 
 These are the extensions cherry-picked to make GLES 3.1
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] gallium/hud: bugfix: 68169 - Sensor extensions segfaults.

2016-10-13 Thread Nicolai Hähnle

On 12.10.2016 19:02, Steven Toth wrote:

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

Really a two part bug.

1. The recent extensions to the HUB framework were tested exclusively
with glxgears/demo/head. None of these tools exercise the
free_query_data() code path. When these codepaths were
tested, thanks to Christoph, using heaven-unigine
application, the sensors extension would segfault.

2. In a second case, same use case, extensions would
return zero values for cpufrequency, network stats etc.

On inspection, this was due to the 'unigine' application
created the HUD contexts twice (two screens?). The
extensions had never been tested in that configuration,
and the free_query_data() calls were thus trigger.


The HUD is actually created per-context. Two general points that apply 
equally to all four parts of the patch:


Instead of open-coding the users variable, I'd prefer that you use the 
pipe_reference mechanism. This mechanism has the advantage that it 
already works in a multi-threaded setting, which brings me to the second 
point, which is:


Contexts can be created and destroyed simultaneously from multiple 
threads. You need to protect at least the globals with a mutex, i.e. in 
the find_*_by_name and free_query_data.


You probably need to protect some of the query functions with a mutex as 
well. The general rule of thumb is that functions associated to a 
pipe_context can only be called from one thread at a time; i.e., the 
graph's callback function (like query_dsi_load) is only called from one 
thread at a time _for one particular graph_. However, since you're 
sharing the underlying data between graphs in multiple contexts, you 
need a mutex e.g. in query_dsi_load when accessing the dsi members.


At least you need to think through the implications of what happens here...

It may actually be cleaner and simpler to just get rid of the sharing of 
underlying structures.


Thanks for looking into this!

Cheers,
Nicolai


This patchset ensures that globally allocated
mechanisms for collecting and exposing various
disk, network, cpu frequency and sensors statistics
are retained correctly across multiple uses, and
free'd when no more callers require them.

Patchset was regression tested again with Unigine,
glxgears and glxdemo.

Tested-By: Christoph Haag 
Signed-off-by: Steven Toth 
---
 src/gallium/auxiliary/hud/hud_cpufreq.c  |  8 ++--
 src/gallium/auxiliary/hud/hud_diskstat.c | 10 +++---
 src/gallium/auxiliary/hud/hud_nic.c  |  8 ++--
 src/gallium/auxiliary/hud/hud_sensors_temp.c | 18 +-
 4 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_cpufreq.c 
b/src/gallium/auxiliary/hud/hud_cpufreq.c
index 4501bbb..39bdcb0 100644
--- a/src/gallium/auxiliary/hud/hud_cpufreq.c
+++ b/src/gallium/auxiliary/hud/hud_cpufreq.c
@@ -57,6 +57,7 @@ struct cpufreq_info
char sysfs_filename[128];
uint64_t KHz;
uint64_t last_time;
+   int users;
 };

 static int gcpufreq_count = 0;
@@ -116,8 +117,10 @@ static void
 free_query_data(void *p)
 {
struct cpufreq_info *cfi = (struct cpufreq_info *)p;
-   list_del(>list);
-   FREE(cfi);
+   if (--cfi->users == 0) {
+  list_del(>list);
+  FREE(cfi);
+   }
 }

 /**
@@ -159,6 +162,7 @@ hud_cpufreq_graph_install(struct hud_pane *pane, int 
cpu_index,
   return;
}

+   cfi->users++;
gr->query_data = cfi;
gr->query_new_value = query_cfi_load;

diff --git a/src/gallium/auxiliary/hud/hud_diskstat.c 
b/src/gallium/auxiliary/hud/hud_diskstat.c
index b248baf..000d6b3 100644
--- a/src/gallium/auxiliary/hud/hud_diskstat.c
+++ b/src/gallium/auxiliary/hud/hud_diskstat.c
@@ -73,6 +73,7 @@ struct diskstat_info
char sysfs_filename[128];
uint64_t last_time;
struct stat_s last_stat;
+   int users;
 };

 /* TODO: We don't handle dynamic block device / partition
@@ -165,9 +166,11 @@ query_dsi_load(struct hud_graph *gr)
 static void
 free_query_data(void *p)
 {
-   struct diskstat_info *nic = (struct diskstat_info *) p;
-   list_del(>list);
-   FREE(nic);
+   struct diskstat_info *dsi = (struct diskstat_info *) p;
+   if (--dsi->users == 0) {
+  list_del(>list);
+  FREE(dsi);
+   }
 }

 /**
@@ -205,6 +208,7 @@ hud_diskstat_graph_install(struct hud_pane *pane, const 
char *dev_name,
else
   return;

+   dsi->users++;
gr->query_data = dsi;
gr->query_new_value = query_dsi_load;

diff --git a/src/gallium/auxiliary/hud/hud_nic.c 
b/src/gallium/auxiliary/hud/hud_nic.c
index fb6b8c0..e3f5910 100644
--- a/src/gallium/auxiliary/hud/hud_nic.c
+++ b/src/gallium/auxiliary/hud/hud_nic.c
@@ -59,6 +59,7 @@ struct nic_info
char throughput_filename[128];
uint64_t last_time;
uint64_t last_nic_bytes;
+   int users;
 };

 /* TODO: We don't handle dynamic NIC arrival or removal.
@@ -238,8 +239,10 @@ static void
 free_query_data(void *p)
 {
struct nic_info *nic = (struct nic_info *) p;
-   

Re: [Mesa-dev] [PATCH 1/5] st/va: Return more useful config attributes

2016-10-13 Thread Mark Thompson
On 13/10/16 08:20, Christian König wrote:
> Am 13.10.2016 um 00:52 schrieb Mark Thompson:
>> The encoder attributes are needed for a user of the encoder to be
>> able to configure it sensibly without internal knowledge.
> 
> Reviewed-by: Christian König  for the whole series.
> 
> Do you have commit access?

I do not.  Please do push this for me once all appropriate people are happy 
with it.

Thanks,

- Mark

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


Re: [Mesa-dev] [PATCH] gallium: add PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY

2016-10-13 Thread Marek Olšák
On Thu, Oct 13, 2016 at 2:09 AM, Roland Scheidegger  wrote:
> Am 12.10.2016 um 15:29 schrieb Marek Olšák:
>> From: Marek Olšák 
>>
>> For performance tuning in drivers. It filters out window system
>> framebuffers and OpenGL renderbuffers.
>>
>> radeonsi will use this to guess whether a depth buffer will be read
>> by a shader. There is no guarantee about what will actually happen.
>>
>> This is a departure from PIPE_BIND flags which are defined to be strict
>> but they are useless in practice.
>> ---
>>  src/gallium/include/pipe/p_defines.h | 1 +
>>  src/mesa/state_tracker/st_texture.c  | 3 ++-
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/include/pipe/p_defines.h 
>> b/src/gallium/include/pipe/p_defines.h
>> index db96c51..037ed92 100644
>> --- a/src/gallium/include/pipe/p_defines.h
>> +++ b/src/gallium/include/pipe/p_defines.h
>> @@ -443,20 +443,21 @@ enum pipe_flush_flags
>>  #define PIPE_BIND_SCANOUT (1 << 19) /*  */
>>  #define PIPE_BIND_SHARED  (1 << 20) /* get_texture_handle ??? */
>>  #define PIPE_BIND_LINEAR  (1 << 21)
>>
>>
>>  /**
>>   * Flags for the driver about resource behaviour:
>>   */
>>  #define PIPE_RESOURCE_FLAG_MAP_PERSISTENT (1 << 0)
>>  #define PIPE_RESOURCE_FLAG_MAP_COHERENT   (1 << 1)
>> +#define PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY (1 << 2)
>>  #define PIPE_RESOURCE_FLAG_DRV_PRIV(1 << 16) /* driver/winsys private */
>>  #define PIPE_RESOURCE_FLAG_ST_PRIV (1 << 24) /* state-tracker/winsys 
>> private */
>>
>>  /**
>>   * Hint about the expected lifecycle of a resource.
>>   * Sorted according to GPU vs CPU access.
>>   */
>>  enum pipe_resource_usage {
>> PIPE_USAGE_DEFAULT,/* fast GPU access */
>> PIPE_USAGE_IMMUTABLE,  /* fast GPU access, immutable */
>> diff --git a/src/mesa/state_tracker/st_texture.c 
>> b/src/mesa/state_tracker/st_texture.c
>> index a2c36ac..7b72ffd 100644
>> --- a/src/mesa/state_tracker/st_texture.c
>> +++ b/src/mesa/state_tracker/st_texture.c
>> @@ -84,21 +84,22 @@ st_texture_create(struct st_context *st,
>> memset(, 0, sizeof(pt));
>> pt.target = target;
>> pt.format = format;
>> pt.last_level = last_level;
>> pt.width0 = width0;
>> pt.height0 = height0;
>> pt.depth0 = depth0;
>> pt.array_size = layers;
>> pt.usage = PIPE_USAGE_DEFAULT;
>> pt.bind = bind;
>> -   pt.flags = 0;
>> +   /* only set this for OpenGL textures, not renderbuffers */
>> +   pt.flags = PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY;
>> pt.nr_samples = nr_samples;
>>
>> newtex = screen->resource_create(screen, );
>>
>> assert(!newtex || pipe_is_referenced(>reference));
>>
>> return newtex;
>>  }
>>
>>
>>
>
> I guess, why not... I bet though there are apps which create everything
> as a texture, regardless if they actually use it for sampling or not. So
> you still need to try to not perform too bad if you got the hint wrong :-).
> It's really GL which is useless there, not the PIPE_BIND flags ;-).

But you have to admit that the new flag is very accurate - it
represents OpenGL texture objects. That can't be said about most of
the bind flags.

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


Re: [Mesa-dev] Mesa (master): st/glsl_to_tgsi: simpler fixup of empty writemasks

2016-10-13 Thread Michel Dänzer

Hi Nicolai,


On 13/10/16 01:50 AM, Nicolai Hähnle wrote:
> Module: Mesa
> Branch: master
> Commit: f5f3cadca3809952288e3726ed5fde22090dc61d
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=f5f3cadca3809952288e3726ed5fde22090dc61d
> 
> Author: Nicolai Hähnle 
> Date:   Fri Oct  7 12:49:36 2016 +0200
> 
> st/glsl_to_tgsi: simpler fixup of empty writemasks

This change broke the piglit tests
spec@glsl-110@execution@variable-indexing@vs-temp-array-mat2-index(-col)-wr
on my Kaveri. Output with R600_DEBUG=ps,vs attached as
vs-temp-array-mat2-index-wr.txt .


P.S. The newly enabled tests
spec@arb_enhanced_layouts@execution@component-layout@vs-tcs-load-output(-indirect)
also fail, output attached as vs-tcs-load-output.stderr .

-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
VERT
PROPERTY NEXT_SHADER FRAG
DCL IN[0]
DCL OUT[0], POSITION
DCL OUT[1], COLOR
DCL CONST[0..9]
DCL TEMP[0], LOCAL
DCL TEMP[1..2], ARRAY(1), LOCAL
DCL TEMP[3..8], ARRAY(2), LOCAL
DCL TEMP[9..10], ARRAY(3), LOCAL
DCL TEMP[11..12], ARRAY(4), LOCAL
DCL TEMP[13..14], LOCAL
DCL ADDR[0]
IMM[0] FLT32 {0., 0., 1., 0.}
IMM[1] INT32 {2, 0, 0, 0}
  0: MUL TEMP[0], CONST[6], IN[0].
  1: MAD TEMP[0], CONST[7], IN[0]., TEMP[0]
  2: MAD TEMP[0], CONST[8], IN[0]., TEMP[0]
  3: MAD TEMP[0], CONST[9], IN[0]., TEMP[0]
  4: MOV TEMP[1], IMM[0].
  5: MOV TEMP[2], IMM[0].
  6: MOV TEMP[3].xy, TEMP[1].xyxx
  7: MOV TEMP[4].xy, TEMP[2].xyxx
  8: MOV TEMP[9], IMM[0].
  9: MOV TEMP[10], IMM[0].
 10: MOV TEMP[5].xy, TEMP[9].xyxx
 11: MOV TEMP[6].xy, TEMP[10].xyxx
 12: MOV TEMP[11], IMM[0].
 13: MOV TEMP[12], IMM[0].
 14: MOV TEMP[7].xy, TEMP[11].xyxx
 15: MOV TEMP[8].xy, TEMP[12].xyxx
 16: UMUL TEMP[13].x, CONST[4]., IMM[1].
 17: UARL ADDR[0].x, TEMP[13].
 18: MOV TEMP[ADDR[0].x+3](2).xy, CONST[0].xyxx
 19: UARL ADDR[0].x, TEMP[13].
 20: MOV TEMP[ADDR[0].x+4](2).xy, CONST[1].xyxx
 21: UMUL TEMP[13].x, CONST[4]., IMM[1].
 22: UARL ADDR[0].x, TEMP[13].
 23: MOV TEMP[ADDR[0].x+4](2).xy, CONST[5].xyxx
 24: UMUL TEMP[13].x, CONST[4]., IMM[1].
 25: UMUL TEMP[14].x, CONST[4]., IMM[1].
 26: UARL ADDR[0].x, TEMP[14].
 27: MUL TEMP[14].xy, TEMP[ADDR[0].x+3](2).xyyy, CONST[2].
 28: UARL ADDR[0].x, TEMP[13].
 29: MAD TEMP[13].xy, TEMP[ADDR[0].x+4](2).xyyy, CONST[2]., TEMP[14].xyyy
 30: ADD TEMP[13].xy, TEMP[13].xyyy, -CONST[3].xyyy
 31: DP2 TEMP[13].x, TEMP[13].xyyy, TEMP[13].xyyy
 32: FSLT TEMP[13].x, TEMP[13]., IMM[0].
 33: UIF TEMP[13]. :0
 34:   MOV TEMP[13], IMM[0].xzxz
 35: ELSE :0
 36:   MOV TEMP[13], IMM[0].zxxz
 37: ENDIF
 38: MOV OUT[0], TEMP[0]
 39: MOV OUT[1], TEMP[13]
 40: END
radeonsi: Compiling shader 1
TGSI shader LLVM IR:

; ModuleID = 'tgsi'
source_filename = "tgsi"
target triple = "amdgcn--"

define amdgpu_vs <{ float, float, float }> @main([17 x <16 x i8>] addrspace(2)* 
byval dereferenceable(18446744073709551615), [16 x <16 x i8>] addrspace(2)* 
byval dereferenceable(18446744073709551615), [32 x <8 x i32>] addrspace(2)* 
byval dereferenceable(18446744073709551615), [16 x <8 x i32>] addrspace(2)* 
byval dereferenceable(18446744073709551615), [16 x <4 x i32>] addrspace(2)* 
byval dereferenceable(18446744073709551615), [16 x <16 x i8>] addrspace(2)* 
byval dereferenceable(18446744073709551615), i32 inreg, i32 inreg, i32 inreg, 
i32 inreg, i32, i32, i32, i32, i32) {
main_body:
  %15 = getelementptr [16 x <16 x i8>], [16 x <16 x i8>] addrspace(2)* %5, i64 
0, i64 0, !amdgpu.uniform !0
  %16 = load <16 x i8>, <16 x i8> addrspace(2)* %15, align 16, !invariant.load 
!0
  %17 = call <4 x float> @llvm.SI.vs.load.input(<16 x i8> %16, i32 0, i32 %14)
  %18 = extractelement <4 x float> %17, i32 0
  %19 = extractelement <4 x float> %17, i32 1
  %20 = extractelement <4 x float> %17, i32 2
  %21 = extractelement <4 x float> %17, i32 3
  %22 = getelementptr [16 x <16 x i8>], [16 x <16 x i8>] addrspace(2)* %1, i64 
0, i64 0, !amdgpu.uniform !0
  %23 = load <16 x i8>, <16 x i8> addrspace(2)* %22, align 16, !invariant.load 
!0
  %24 = call float @llvm.SI.load.const(<16 x i8> %23, i32 96)
  %25 = fmul float %24, %18
  %26 = call float @llvm.SI.load.const(<16 x i8> %23, i32 100)
  %27 = fmul float %26, %18
  %28 = call float @llvm.SI.load.const(<16 x i8> %23, i32 104)
  %29 = fmul float %28, %18
  %30 = getelementptr [16 x <16 x i8>], [16 x <16 x i8>] addrspace(2)* %1, i64 
0, i64 0, !amdgpu.uniform !0
  %31 = load <16 x i8>, <16 x i8> addrspace(2)* %30, align 16, !invariant.load 
!0
  %32 = call float @llvm.SI.load.const(<16 x i8> %31, i32 108)
  %33 = fmul float %32, %18
  %34 = call float @llvm.SI.load.const(<16 x i8> %31, i32 112)
  %35 = fmul float %34, %19
  %36 = fadd float %35, %25
  %37 = getelementptr [16 x <16 x i8>], [16 x <16 x i8>] addrspace(2)* %1, i64 
0, i64 0, !amdgpu.uniform !0
  

Re: [Mesa-dev] [PATCH] mesa_glinterop: allow building without X and related headers

2016-10-13 Thread Tapani Pälli

Thanks Emil!

Reviewed-by: Tapani Pälli 

On 10/12/2016 08:49 PM, Emil Velikov wrote:

This commit effectively reverts c10dcb2ce837922c6ee4e191e6d6202098a5ee10
and fixes the typedef redefinition which inspired it.

In order to prevent requiring X packages at build time earlier commit
forward declared the required X/GLX typedefs. Since that approach
introduced typedef redefinition (a C11 feature) it was reverted.

To avoid the redefinition while _not_ mandating X and related headers
forward declare the structs and use those through the header.

As anyone uses the mesa interop header they ensure that the X (or others
in terms of EGL) headers are included, which ensures that everything is
resolved within the compilation unit.

Cc: Vinson Lee 
Cc: "12.0" 
Cc: Tapani Pälli 
Cc: Chih-Wei Huang 
Fixes: c10dcb2ce837 ("Revert "mesa_glinterop: remove inclusion of GLX
header"")
Fixes: 8472045b16b3 ("mesa_glinterop: remove inclusion of GLX header")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96770
Signed-off-by: Emil Velikov 
---
TL;DR; Yay typedefs, because they make things so much better ;-)

Tapani/Chih-Wei, this should fix the breakage that you are seing. Please
let me know if it sorts things on your end.

Vison, this should resolve things on your end as well. A confirmation
would be great.
---
 include/GL/mesa_glinterop.h | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
index c6a967e..173476a 100644
--- a/include/GL/mesa_glinterop.h
+++ b/include/GL/mesa_glinterop.h
@@ -52,12 +52,15 @@

 #include 
 #include 
-#include 

 #ifdef __cplusplus
 extern "C" {
 #endif

+/* Forward declarations to avoid inclusion of GL/glx.h */
+struct _XDisplay;
+struct __GLXcontextRec;
+
 /* Forward declarations to avoid inclusion of EGL/egl.h */
 typedef void *EGLDisplay;
 typedef void *EGLContext;
@@ -243,7 +246,7 @@ struct mesa_glinterop_export_out {
  * \return MESA_GLINTEROP_SUCCESS or MESA_GLINTEROP_* != 0 on error
  */
 int
-MesaGLInteropGLXQueryDeviceInfo(Display *dpy, GLXContext context,
+MesaGLInteropGLXQueryDeviceInfo(struct _XDisplay *dpy, struct __GLXcontextRec 
*context,
 struct mesa_glinterop_device_info *out);


@@ -268,7 +271,7 @@ MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext 
context,
  * \return MESA_GLINTEROP_SUCCESS or MESA_GLINTEROP_* != 0 on error
  */
 int
-MesaGLInteropGLXExportObject(Display *dpy, GLXContext context,
+MesaGLInteropGLXExportObject(struct _XDisplay *dpy, struct __GLXcontextRec 
*context,
  struct mesa_glinterop_export_in *in,
  struct mesa_glinterop_export_out *out);

@@ -283,11 +286,11 @@ MesaGLInteropEGLExportObject(EGLDisplay dpy, EGLContext 
context,
  struct mesa_glinterop_export_out *out);


-typedef int (PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(Display *dpy, GLXContext 
context,
+typedef int (PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(struct _XDisplay *dpy, 
struct __GLXcontextRec *context,
  struct 
mesa_glinterop_device_info *out);
 typedef int (PFNMESAGLINTEROPEGLQUERYDEVICEINFOPROC)(EGLDisplay dpy, 
EGLContext context,
  struct 
mesa_glinterop_device_info *out);
-typedef int (PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(Display *dpy, GLXContext 
context,
+typedef int (PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(struct _XDisplay *dpy, 
struct __GLXcontextRec *context,
   struct 
mesa_glinterop_export_in *in,
   struct 
mesa_glinterop_export_out *out);
 typedef int (PFNMESAGLINTEROPEGLEXPORTOBJECTPROC)(EGLDisplay dpy, EGLContext 
context,


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


Re: [Mesa-dev] Mesa (master): st/glsl_to_tgsi: simpler fixup of empty writemasks

2016-10-13 Thread Nicolai Hähnle

Hi Michel,

On 13.10.2016 08:42, Michel Dänzer wrote:

On 13/10/16 01:50 AM, Nicolai Hähnle wrote:

Module: Mesa
Branch: master
Commit: f5f3cadca3809952288e3726ed5fde22090dc61d
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=f5f3cadca3809952288e3726ed5fde22090dc61d

Author: Nicolai Hähnle 
Date:   Fri Oct  7 12:49:36 2016 +0200

st/glsl_to_tgsi: simpler fixup of empty writemasks


This change broke the piglit tests
spec@glsl-110@execution@variable-indexing@vs-temp-array-mat2-index(-col)-wr
on my Kaveri. Output with R600_DEBUG=ps,vs attached as
vs-temp-array-mat2-index-wr.txt .


P.S. The newly enabled tests
spec@arb_enhanced_layouts@execution@component-layout@vs-tcs-load-output(-indirect)
also fail, output attached as vs-tcs-load-output.stderr .


Thanks, it's on my radar. As far as I can tell, Mesa is doing the right 
thing here and LLVM is the problem, and working around it in Mesa may 
not be possible or reliable. But it's on my list of things to fix properly.


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


Re: [Mesa-dev] [PATCH] doc/features.txt: factor out nvc0/radeonsi as GL45 complete

2016-10-13 Thread Edward O'Callaghan


On 10/13/2016 06:24 PM, Nicolai Hähnle wrote:
> On 13.10.2016 08:34, Edward O'Callaghan wrote:
>> Signed-off-by: Edward O'Callaghan 
> 
> I think i965 can get the same treatment. And the mesamatrix people need

OK, I just was not sure about 'i965/hsw+' vs. 'i965' as I am not
familiar with all the different Intel variants. Will send a new version
in a few moments..

> to check their parsing code for OpenGL 4.4 ;)

hehe, yes they do ;)

Kind Regards,
Edward.

> 
> Cheers,
> Nicolai
> 
>> ---
>>  docs/features.txt | 18 +-
>>  1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/docs/features.txt b/docs/features.txt
>> index ec2634f..b15ec35 100644
>> --- a/docs/features.txt
>> +++ b/docs/features.txt
>> @@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
>>GL_ARB_texture_stencil8   DONE
>> (i965/hsw+, nv50, nvc0, r600, llvmpipe, softpipe, swr)
>>GL_ARB_vertex_type_10f_11f_11f_revDONE (i965,
>> nv50, nvc0, r600, llvmpipe, softpipe, swr)
>>
>> -GL 4.5, GLSL 4.50:
>> +GL 4.5, GLSL 4.50 -- all DONE: nvc0, radeonsi
>>
>> -  GL_ARB_ES3_1_compatibilityDONE
>> (i965/hsw+, nvc0, radeonsi)
>> -  GL_ARB_clip_control   DONE (i965,
>> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
>> -  GL_ARB_conditional_render_invertedDONE (i965,
>> nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
>> -  GL_ARB_cull_distance  DONE (i965,
>> nv50, nvc0, radeonsi, llvmpipe, softpipe, swr)
>> -  GL_ARB_derivative_control DONE (i965,
>> nv50, nvc0, r600, radeonsi)
>> +  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+)
>> +  GL_ARB_clip_control   DONE (i965,
>> nv50, r600, llvmpipe, softpipe, swr)
>> +  GL_ARB_conditional_render_invertedDONE (i965,
>> nv50, r600, llvmpipe, softpipe, swr)
>> +  GL_ARB_cull_distance  DONE (i965,
>> nv50, llvmpipe, softpipe, swr)
>> +  GL_ARB_derivative_control DONE (i965,
>> nv50, r600)
>>GL_ARB_direct_state_accessDONE (all
>> drivers)
>>GL_ARB_get_texture_sub_image  DONE (all
>> drivers)
>> -  GL_ARB_shader_texture_image_samples   DONE (i965,
>> nv50, nvc0, r600, radeonsi)
>> -  GL_ARB_texture_barrierDONE (i965,
>> nv50, nvc0, r600, radeonsi)
>> +  GL_ARB_shader_texture_image_samples   DONE (i965,
>> nv50, r600)
>> +  GL_ARB_texture_barrierDONE (i965,
>> nv50, r600)
>>GL_KHR_context_flush_control  DONE (all -
>> but needs GLX/EGL extension to be useful)
>> -  GL_KHR_robustness DONE (i965,
>> nvc0, radeonsi)
>> +  GL_KHR_robustness DONE (i965)
>>GL_EXT_shader_integer_mix DONE (all
>> drivers that support GLSL)
>>
>>  These are the extensions cherry-picked to make GLES 3.1
>>



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] [PATCH 1/5] intel: automake: replace direct basename $@ invokation with $(@F)

2016-10-13 Thread Lionel Landwerlin

Reviewed-by: Lionel Landwerlin 

On 12/10/16 19:05, Emil Velikov wrote:

From: Emil Velikov 

Use the shorthand make variable(s) as elsewhere in the build.

Signed-off-by: Emil Velikov 
---
  src/intel/Makefile.genxml.am | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
index f8b0363..519f30e 100644
--- a/src/intel/Makefile.genxml.am
+++ b/src/intel/Makefile.genxml.am
@@ -37,7 +37,7 @@ $(GENXML_GENERATED_FILES): genxml/gen_pack_header.py
  %_xml.h:  %.xml Makefile
$(MKDIR_GEN)
$(AM_V_GEN) echo -n "static const uint8_t " > $@; \
-   echo "`basename $@`_xml[] = {" | sed -e 's,_xml.h,,' >> $@; \
+   echo "$(@F)_xml[] = {" | sed -e 's,_xml.h,,' >> $@; \
cat $< | $(XXD) -i >> $@; \
echo "};" >> $@
  



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


Re: [Mesa-dev] i965: Fast color clear for mipmapped and arrayed

2016-10-13 Thread Pohjolainen, Topi
On Tue, Oct 11, 2016 at 10:26:32PM +0300, Topi Pohjolainen wrote:
> The entire series is mostly bookkeeping changes. It switches to track
> color and state per slice instead of per miptree (such as we already
> do for depth and hiz).
> 
> Patch 22 is still work in progress. We have all the details already
> in ISL and I would somehow like to utilize that instead. Current
> patch overallocates in some cases but should be safe though.
> 
> I will follow-up with some performance numbers.

On SKL i5k (lossless compression):

Manhattan 3.0: 2.43196% +/- 0.650327%
Manhattan 3.0 off: 2.70886% +/- 0.0502046%
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v2.1] i965/vec4: teach register coalescing about 64-bit

2016-10-13 Thread Iago Toral Quiroga
Specifically, at least for now, we don't want to deal with the fact that
channel sizes for fp64 instructions are twice the size, so prevent
coalescing from instructions with a different type size.

Also, we should check that if we are coalescing a register from another
MOV we should be writing the same amount of data in both operations, otherwise
we end up wiring more or less than the original instruction. This can happen,
for example, when we have split fp64 MOVs with an exec size of 4 that only
write one register each and then a MOV with exec size of 8 that reads both.
We want to avoid the pass to think that it can coalesce from the first split
MOV alone. Ideally we would like the pass to see that it can coalesce from both
split MOVs instead, but for now we keep it simple.

Finally, the pass doesn't support coalescing of multiple registers but in the
case of normal SIMD4x2 double-precision instructions they naturally write two
registers (one per vertex) and there is no reason why we should not allow
coalescing in this case. Change the restriction to bail if we see instructions
that write more than 8 channels, where the channels can be 32-bit or 64-bit.

v2:
 - Make sure that scan_inst and inst write the same amount of data.
---
The previous version of this patch would abort the process if scan_inst wrote
the same or more data than inst read, which is obviously wrong. What we want to
ensure is that both scan_inst and inst write the same amount of data so that
coalescing does not produce a result that writes a different region of the
destination.

 src/mesa/drivers/dri/i965/brw_vec4.cpp | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index c728e38..6a5909b 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1191,6 +1191,20 @@ vec4_visitor::opt_register_coalesce()
   scan_inst->dst.type == scan_inst->src[0].type))
break;
 
+/* Only allow coalescing between registers of the same type size.
+ * Otherwise we would need to make the pass aware of the fact that
+ * channel sizes are different for single and double precision.
+ */
+if (type_sz(inst->src[0].type) != type_sz(scan_inst->src[0].type))
+   break;
+
+/* Check that scan_inst writes the same amount of data as the
+ * instruction, otherwise coalescing would lead to writing a
+ * different (larger or smaller) region of the destination
+ */
+if (scan_inst->size_written != inst->size_written)
+   break;
+
 /* If we can't handle the swizzle, bail. */
 if (!scan_inst->can_reswizzle(devinfo, inst->dst.writemask,
   inst->src[0].swizzle,
@@ -1198,10 +1212,12 @@ vec4_visitor::opt_register_coalesce()
break;
 }
 
-/* This only handles coalescing of a single register starting at
- * the source offset of the copy instruction.
+/* This only handles coalescing writes of 8 channels (1 register
+ * for single-precision and 2 registers for double-precision)
+ * starting at the source offset of the copy instruction.
  */
-if (scan_inst->size_written > REG_SIZE ||
+if (DIV_ROUND_UP(scan_inst->size_written,
+ type_sz(scan_inst->dst.type)) > 8 ||
 scan_inst->dst.offset != inst->src[0].offset)
break;
 
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] doc/features.txt: factor out nvc0/radeonsi as GL45 complete

2016-10-13 Thread Nicolai Hähnle

On 13.10.2016 08:34, Edward O'Callaghan wrote:

Signed-off-by: Edward O'Callaghan 


I think i965 can get the same treatment. And the mesamatrix people need 
to check their parsing code for OpenGL 4.4 ;)


Cheers,
Nicolai


---
 docs/features.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ec2634f..b15ec35 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, radeonsi
   GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)
   GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
nvc0, r600, llvmpipe, softpipe, swr)

-GL 4.5, GLSL 4.50:
+GL 4.5, GLSL 4.50 -- all DONE: nvc0, radeonsi

-  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+, nvc0, 
radeonsi)
-  GL_ARB_clip_control   DONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_cull_distance  DONE (i965, nv50, 
nvc0, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_derivative_control DONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+)
+  GL_ARB_clip_control   DONE (i965, nv50, 
r600, llvmpipe, softpipe, swr)
+  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
r600, llvmpipe, softpipe, swr)
+  GL_ARB_cull_distance  DONE (i965, nv50, 
llvmpipe, softpipe, swr)
+  GL_ARB_derivative_control DONE (i965, nv50, r600)
   GL_ARB_direct_state_accessDONE (all drivers)
   GL_ARB_get_texture_sub_image  DONE (all drivers)
-  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, 
nvc0, r600, radeonsi)
-  GL_ARB_texture_barrierDONE (i965, nv50, 
nvc0, r600, radeonsi)
+  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, r600)
+  GL_ARB_texture_barrierDONE (i965, nv50, r600)
   GL_KHR_context_flush_control  DONE (all - but needs 
GLX/EGL extension to be useful)
-  GL_KHR_robustness DONE (i965, nvc0, 
radeonsi)
+  GL_KHR_robustness DONE (i965)
   GL_EXT_shader_integer_mix DONE (all drivers that 
support GLSL)

 These are the extensions cherry-picked to make GLES 3.1


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


  1   2   >