Re: [Mesa-dev] [PATCH v2] glsl: Expand matrix flip optimization pass to cover more cases.
On Wed, 2014-06-18 at 14:43 -0700, Ian Romanick wrote:
On 06/18/2014 05:03 AM, Iago Toral Quiroga wrote:
Also, as suggested by Ian Romanick, make it so we don't need a bunch of
individual handles to flippable matrices, instead we register
matrix/transpose_matrix pairs in a hash table for all built-in matrices
using the non-transpose matrix name as key.
---
src/glsl/opt_flip_matrices.cpp | 145
++---
1 file changed, 108 insertions(+), 37 deletions(-)
diff --git a/src/glsl/opt_flip_matrices.cpp b/src/glsl/opt_flip_matrices.cpp
index 9044fd6..d0b8125 100644
--- a/src/glsl/opt_flip_matrices.cpp
+++ b/src/glsl/opt_flip_matrices.cpp
@@ -29,44 +29,132 @@
* On some hardware, this is more efficient.
*
* This currently only does the conversion for built-in matrices which
- * already have transposed equivalents. Namely,
gl_ModelViewProjectionMatrix
- * and gl_TextureMatrix.
+ * already have transposed equivalents.
*/
#include ir.h
#include ir_optimization.h
#include main/macros.h
+#include program/hash_table.h
namespace {
+
class matrix_flipper : public ir_hierarchical_visitor {
public:
+ struct matrix_and_transpose {
+ ir_variable *matrix;
+ ir_variable *transpose_matrix;
+ };
+
matrix_flipper(exec_list *instructions)
{
progress = false;
- mvp_transpose = NULL;
- texmat_transpose = NULL;
+
+ /* Build a hash table of built-in matrices and their transposes.
+ *
+ * The key for the entries in the hash table is the non-transpose
matrix
+ * name. This assumes that all built-in transpose matrices have the
+ * Transpose suffix.
+ */
+ ht = hash_table_ctor(0, hash_table_string_hash,
+ hash_table_string_compare);
foreach_list(n, instructions) {
ir_instruction *ir = (ir_instruction *) n;
ir_variable *var = ir-as_variable();
- if (!var)
+
+ /* Must be a matrix */
+ if (!var || !var-type-is_matrix())
continue;
gl_TextureMatrix is an array of matrices, so var-type-is_matrix()
will fail. I think you want:
if (!var)
continue;
/* Must be a matrix or array of matrices. */
if (!var-type-is_matrix()
!(var-type-is_array() var-type-fields.array-is_matrix()))
continue;
Oh, right.
- if (strcmp(var-name, gl_ModelViewProjectionMatrixTranspose) ==
0)
-mvp_transpose = var;
- if (strcmp(var-name, gl_TextureMatrixTranspose) == 0)
-texmat_transpose = var;
+ /* Must be a built-in */
+ if (strstr(var-name, gl_) != var-name)
+continue;
The name has to start with gl_, not just contain it. Use
is_gl_identifier(var-name) instead.
Actually, this checks that it starts with it (see != var-name), but
I'll use is_gl_identifier.
+
+ /* Create a new entry for this matrix if we don't have one yet */
+ bool new_entry = false;
+ struct matrix_and_transpose *entry =
+(struct matrix_and_transpose *) hash_table_find(ht, var-name);
+ if (!entry) {
+new_entry = true;
+entry = new struct matrix_and_transpose();
+entry-matrix = NULL;
+entry-transpose_matrix = NULL;
+ }
+
+ const char *transpose_ptr = strstr(var-name, Transpose);
+ if (transpose_ptr == NULL) {
+entry-matrix = var;
+ } else {
It's probably worth adding an assertion in case a built-in is ever
added with something after Transpose. The probability is very, very
low, but I'd rather be safe.
Sure, I will add that.
assert(transpose_ptr[9] == 0);
+entry-transpose_matrix = var;
+ }
+
+ if (new_entry) {
+char *entry_key;
+if (transpose_ptr == NULL) {
+ entry_key = strdup(var-name);
+} else {
+ entry_key = strndup(var-name, transpose_ptr - var-name);
+}
hash_table_dtor doesn't free the keys, so all of this memory leaks.
Use ralloc_strndup, and only copy the name in the transpose_ptr != NULL
case.
Ok.
+hash_table_insert(ht, entry, entry_key);
+ }
}
}
+ ~matrix_flipper()
+ {
+ hash_table_dtor(ht);
+ }
+
ir_visitor_status visit_enter(ir_expression *ir);
bool progress;
private:
- ir_variable *mvp_transpose;
- ir_variable *texmat_transpose;
+ void transform_operands(ir_expression *ir,
+ ir_variable *mat_var,
+ ir_variable *mat_transpose);
+ void transform_operands_array_of_matrix(ir_expression *ir,
+
Re: [Mesa-dev] [PATCH v2 04/23] glsl: Assign GLSL StreamIds to transform feedback outputs.
On Wed, 2014-06-18 at 12:56 -0700, Ian Romanick wrote:
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
Inter-shader outputs must be on stream 0, which is the default.
---
src/glsl/link_varyings.cpp | 12 +---
src/glsl/link_varyings.h | 7 +++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index f765d37..9725a43 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -291,6 +291,7 @@ tfeedback_decl::init(struct gl_context *ctx, const void
*mem_ctx,
this-skip_components = 0;
this-next_buffer_separator = false;
this-matched_candidate = NULL;
+ this-stream_id = 0;
if (ctx-Extensions.ARB_transform_feedback3) {
/* Parse gl_NextBuffer. */
@@ -355,8 +356,8 @@ tfeedback_decl::is_same(const tfeedback_decl x, const
tfeedback_decl y)
/**
- * Assign a location for this tfeedback_decl object based on the transform
- * feedback candidate found by find_candidate.
+ * Assign a location and stream ID for this tfeedback_decl object based on
the
+ * transform feedback candidate found by find_candidate.
*
* If an error occurs, the error is reported through linker_error() and
false
* is returned.
@@ -437,6 +438,11 @@ tfeedback_decl::assign_location(struct gl_context *ctx,
return false;
}
+ /* Only transform feedback varyings can be assigned to non-zero streams,
+* so assign the stream id here.
+*/
+ this-stream_id = this-matched_candidate-toplevel_var-data.stream;
+
return true;
}
@@ -495,7 +501,7 @@ tfeedback_decl::store(struct gl_context *ctx, struct
gl_shader_program *prog,
info-Outputs[info-NumOutputs].ComponentOffset = location_frac;
info-Outputs[info-NumOutputs].OutputRegister = location;
info-Outputs[info-NumOutputs].NumComponents = output_size;
- info-Outputs[info-NumOutputs].StreamId = 0;
+ info-Outputs[info-NumOutputs].StreamId = stream_id;
info-Outputs[info-NumOutputs].OutputBuffer = buffer;
info-Outputs[info-NumOutputs].DstOffset =
info-BufferStride[buffer];
++info-NumOutputs;
diff --git a/src/glsl/link_varyings.h b/src/glsl/link_varyings.h
index 6fa2681..4e485c3 100644
--- a/src/glsl/link_varyings.h
+++ b/src/glsl/link_varyings.h
@@ -210,6 +210,13 @@ private:
* data structure that was found. Otherwise NULL.
*/
const tfeedback_candidate *matched_candidate;
+
+ /**
+* StreamId assigned to this varying (defaults to 0). Can only be set to
+* values other than 0 in geometry shaders that use the stream layout
+* modifier. Accepted values must be in the range [0,
MAX_VERTEX_STREAMS].
MAX_VERTEX_STREAMS-1, right?
Ooops, right. I'll fix that.
+*/
+ unsigned stream_id;
};
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 01/23] glsl: Add parsing support for multi-stream output in geometry shaders.
On Wed, 2014-06-18 at 11:16 -0700, Ian Romanick wrote: On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote: From: Samuel Iglesias Gonsalvez sigles...@igalia.com This implements parsing requirements for multi-stream support in geometry shaders as defined in ARB_gpu_shader5. Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com A few minor nits below. With those fixed, this patch is Reviewed-by: Ian Romanick ian.d.roman...@intel.com Thanks for your review! I will work on it. Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 12/23] glsl: Validate vertex emission in geometry shaders.
On Wed, 2014-06-18 at 13:38 -0700, Ian Romanick wrote:
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
Check if non-zero streams are used. Fail to link if emitting to unsupported
streams or emitting to non-zero streams with output type other than
GL_POINTS.
---
src/glsl/linker.cpp | 148
+++-
1 file changed, 134 insertions(+), 14 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 0b6a716..f8ff138 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -250,31 +250,100 @@ public:
}
};
-
/**
- * Visitor that determines whether or not a shader uses ir_end_primitive.
+ * Visitor that determines the highest stream id to which a (geometry)
shader
+ * emits vertices. It also checks whether End{Stream}Primitive is ever
called.
*/
-class find_end_primitive_visitor : public ir_hierarchical_visitor {
+class find_emit_vertex_visitor : public ir_hierarchical_visitor {
public:
- find_end_primitive_visitor()
- : found(false)
+ find_emit_vertex_visitor(int max_allowed)
+ : max_stream_allowed(max_allowed),
+invalid_stream_id(0),
+invalid_stream_id_from_emit_vertex(false),
+end_primitive_found(false),
+uses_non_zero_stream(false)
{
/* empty */
}
- virtual ir_visitor_status visit(ir_end_primitive *)
+ virtual ir_visitor_status visit_leave(ir_emit_vertex *ir)
{
- found = true;
- return visit_stop;
+ int stream_id = ir-stream_id();
+
+ if (stream_id 0) {
+ invalid_stream_id = stream_id;
+ invalid_stream_id_from_emit_vertex = true;
+ return visit_stop;
+ }
+
+ if (stream_id max_stream_allowed) {
+ invalid_stream_id = stream_id;
+ invalid_stream_id_from_emit_vertex = true;
+ return visit_stop;
+ }
+
+ if (stream_id != 0)
+ uses_non_zero_stream = true;
+
+ return visit_continue;
}
- bool end_primitive_found()
+ virtual ir_visitor_status visit_leave(ir_end_primitive *ir)
{
- return found;
+ end_primitive_found = true;
+
+ int stream_id = ir-stream_id();
+
+ if (stream_id 0) {
+ invalid_stream_id = stream_id;
+ invalid_stream_id_from_emit_vertex = false;
+ return visit_stop;
+ }
+
+ if (stream_id max_stream_allowed) {
+ invalid_stream_id = stream_id;
+ invalid_stream_id_from_emit_vertex = false;
+ return visit_stop;
+ }
+
+ if (stream_id != 0)
+ uses_non_zero_stream = true;
+
+ return visit_continue;
+ }
+
+ bool error()
+ {
+ return invalid_stream_id != 0;
+ }
+
+ const char *error_func()
+ {
+ return invalid_stream_id_from_emit_vertex ?
+ EmitStreamVertex : EndStreamPrimitive;
+ }
+
+ int error_stream()
+ {
+ return invalid_stream_id;
+ }
+
+ bool uses_streams()
+ {
+ return uses_non_zero_stream;
+ }
+
+ bool uses_end_primitive()
+ {
+ return end_primitive_found;
}
private:
- bool found;
+ int max_stream_allowed;
+ int invalid_stream_id;
+ bool invalid_stream_id_from_emit_vertex;
+ bool end_primitive_found;
+ bool uses_non_zero_stream;
};
} /* anonymous namespace */
@@ -551,10 +620,58 @@ validate_geometry_shader_executable(struct
gl_shader_program *prog,
analyze_clip_usage(prog, shader, prog-Geom.UsesClipDistance,
prog-Geom.ClipDistanceArraySize);
+}
+
+/**
+ * Check if geometry shaders emit to non-zero streams and do corresponding
+ * validations.
+ */
+static void
+validate_geometry_shader_emissions(struct gl_context *ctx,
+ struct gl_shader_program *prog)
+{
+ if (prog-_LinkedShaders[MESA_SHADER_GEOMETRY] != NULL) {
+ find_emit_vertex_visitor emit_vertex(ctx-Const.MaxVertexStreams -
1);
+ emit_vertex.run(prog-_LinkedShaders[MESA_SHADER_GEOMETRY]-ir);
+ if (emit_vertex.error()) {
+ linker_error(prog, Invalid call %s(%d). Accepted values for the
+ stream parameter are in the range [0, %d].,
+ emit_vertex.error_func(),
+ emit_vertex.error_stream(),
+ ctx-Const.MaxVertexStreams - 1);
+ }
+ prog-Geom.UsesStreams = emit_vertex.uses_streams();
+ prog-Geom.UsesEndPrimitive = emit_vertex.uses_end_primitive();
- find_end_primitive_visitor end_primitive;
- end_primitive.run(shader-ir);
- prog-Geom.UsesEndPrimitive = end_primitive.end_primitive_found();
+ /* From the ARB_gpu_shader5 spec:
+ *
+ * Multiple vertex streams are supported only if
Re: [Mesa-dev] [PATCH v2 22/23] mesa: Init Geom.UsesEndPrimitive in shader programs.
On Wed, 2014-06-18 at 13:48 -0700, Ian Romanick wrote: I think this patch and 23 should be moved first in the series... the can certainly land before the other patches in the series. Right. I'll push these two tomorrow if nobody says otherwise today. Since you marked patch 23 for stable: do I need to do something else other than adding the CC tag in the commit message? Should I send the patch also to mesa-sta...@lists.freedesktop.org? Iago This patch is Reviewed-by: Ian Romanick ian.d.roman...@intel.com On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote: --- src/mesa/main/shaderobj.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c index 03db862..b3d428c 100644 --- a/src/mesa/main/shaderobj.c +++ b/src/mesa/main/shaderobj.c @@ -248,6 +248,7 @@ _mesa_init_shader_program(struct gl_context *ctx, struct gl_shader_program *prog prog-Geom.VerticesOut = 0; prog-Geom.InputType = GL_TRIANGLES; prog-Geom.OutputType = GL_TRIANGLE_STRIP; + prog-Geom.UsesEndPrimitive = GL_FALSE; prog-Geom.UsesStreams = GL_FALSE; prog-TransformFeedback.BufferMode = GL_INTERLEAVED_ATTRIBS; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] GLX: Add an env var to enable the support of GLX extensions needing both client and server support, in case of client support and direct rendering.
On Wed, 18 Jun 2014 22:55:16 -0700 Kenneth Graunke kenn...@whitecape.org wrote: On Wednesday, June 18, 2014 11:32:45 PM Axel Davy wrote: In the case of XWayland, there's no accelerated indirect rendering. For example GLX_ARB_create_context is not advertised by the server, and according to the spec, we are not allowed to advertise it to the application because of that. This env var makes Mesa ignore this restriction, and a GLX extension is advertised whenever the client supports it. Signed-off-by: Axel Davy axel.d...@ens.fr --- src/glx/glxextensions.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) In this specific case, I think it might make sense to just advertise the extension and return a GLX error if asked for indirect rendering. Or, just lie and return a direct rendering context. That would make the common case that most people want (GLX_ARB_create_context for direct rendered 3.2+ core profile stuff) work out of the box, without the need for environment variables. It's technically out of spec, but for X on Wayland, I think it's not unreasonable. On the other hand, supporting AIGLX of sorts might be possible... With XWayland, there are really a couple layers to indirect rendering... 1. Doing it X client side (direct rendering) 2. Doing it in the XWayland X11 server/Wayland client (semi-indirect). 3. Doing it wherever Weston/etc are running (total indirect). It seems like XWayland could support AIGLX with model #2 - X clients would speak GLX protocol to XWayland, which could then do the GL. Model #3 seems like something we should avoid at all costs. Not only avoid, but model #3 is practically impossible (well, not sensible) anyway. There is no rendering protocol in Wayland, you'd have to invent that first, and then it would probably just get rejected. IMO we can just keep talking about direct (model #1) and indirect (model #2) rendering as usual. To me those are basically GLX concepts and have nothing to do with Wayland. Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeon/llvm: Adapt to AMDGPU.rsq intrinsic change in LLVM 3.5
From: Michel Dänzer michel.daen...@amd.com Signed-off-by: Michel Dänzer michel.daen...@amd.com --- src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c index f8be0df..217fa32 100644 --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c @@ -1384,7 +1384,11 @@ void radeon_llvm_context_init(struct radeon_llvm_context * ctx) bld_base-op_actions[TGSI_OPCODE_UCMP].emit = emit_ucmp; bld_base-rsq_action.emit = build_tgsi_intrinsic_nomem; +#if HAVE_LLVM = 0x0305 + bld_base-rsq_action.intr_name = llvm.AMDGPU.rsq.; +#else bld_base-rsq_action.intr_name = llvm.AMDGPU.rsq; +#endif } void radeon_llvm_create_func(struct radeon_llvm_context * ctx, -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] glsl: Expand matrix flip optimization pass to cover more cases.
Also, as suggested by Ian Romanick, make it so we don't need a bunch of
individual handles to flippable matrices, instead we register
matrix/transpose_matrix pairs in a hash table for all built-in matrices
using the non-transpose matrix name as key.
---
I was wondering, is it really safe to only dup the variable name in the case
that transpose_ptr != NULL? What if the variable gets killed in other
optimization passes? we would have garbage keys in the hash table... wouldn't
that cause problems?
src/glsl/opt_flip_matrices.cpp | 153 +++--
1 file changed, 117 insertions(+), 36 deletions(-)
diff --git a/src/glsl/opt_flip_matrices.cpp b/src/glsl/opt_flip_matrices.cpp
index 9044fd6..80ecb0d 100644
--- a/src/glsl/opt_flip_matrices.cpp
+++ b/src/glsl/opt_flip_matrices.cpp
@@ -29,44 +29,142 @@
* On some hardware, this is more efficient.
*
* This currently only does the conversion for built-in matrices which
- * already have transposed equivalents. Namely, gl_ModelViewProjectionMatrix
- * and gl_TextureMatrix.
+ * already have transposed equivalents.
*/
#include ir.h
#include ir_optimization.h
#include main/macros.h
+#include program/hash_table.h
namespace {
+
class matrix_flipper : public ir_hierarchical_visitor {
public:
+ struct matrix_and_transpose {
+ ir_variable *matrix;
+ ir_variable *transpose_matrix;
+ };
+
matrix_flipper(exec_list *instructions)
{
progress = false;
- mvp_transpose = NULL;
- texmat_transpose = NULL;
+
+ /* Build a hash table of built-in matrices and their transposes.
+ *
+ * The key for the entries in the hash table is the non-transpose matrix
+ * name. This assumes that all built-in transpose matrices have the
+ * Transpose suffix.
+ */
+ ht = hash_table_ctor(0, hash_table_string_hash,
+ hash_table_string_compare);
foreach_list(n, instructions) {
ir_instruction *ir = (ir_instruction *) n;
ir_variable *var = ir-as_variable();
+
if (!var)
continue;
- if (strcmp(var-name, gl_ModelViewProjectionMatrixTranspose) == 0)
-mvp_transpose = var;
- if (strcmp(var-name, gl_TextureMatrixTranspose) == 0)
-texmat_transpose = var;
+
+ /* Must be a matrix or array of matrices. */
+ if (!var-type-is_matrix()
+ !(var-type-is_array() var-type-fields.array-is_matrix()))
+continue;
+
+ /* Must be a built-in */
+ if (is_gl_identifier(var-name))
+continue;
+
+ /* Create a new entry for this matrix if we don't have one yet */
+ bool new_entry = false;
+ struct matrix_and_transpose *entry =
+(struct matrix_and_transpose *) hash_table_find(ht, var-name);
+ if (!entry) {
+new_entry = true;
+entry = new struct matrix_and_transpose();
+entry-matrix = NULL;
+entry-transpose_matrix = NULL;
+ }
+
+ const char *transpose_ptr = strstr(var-name, Transpose);
+ if (transpose_ptr == NULL) {
+entry-matrix = var;
+ } else {
+/* We should not be adding transpose built-in matrices that do
+ * not end in 'Transpose'.
+ */
+assert(transpose_ptr[9] == 0);
+entry-transpose_matrix = var;
+ }
+
+ if (new_entry) {
+char *entry_key;
+if (transpose_ptr == NULL) {
+ entry_key = (char *) var-name;
+} else {
+ entry_key =
+ ralloc_strndup(this, var-name, transpose_ptr - var-name);
+}
+hash_table_insert(ht, entry, entry_key);
+ }
}
}
+ ~matrix_flipper()
+ {
+ hash_table_dtor(ht);
+ }
+
ir_visitor_status visit_enter(ir_expression *ir);
bool progress;
private:
- ir_variable *mvp_transpose;
- ir_variable *texmat_transpose;
+ void transform_operands(ir_expression *ir,
+ ir_variable *mat_var,
+ ir_variable *mat_transpose);
+ void transform_operands_array_of_matrix(ir_expression *ir,
+ ir_variable *mat_var,
+ ir_variable *mat_transpose);
+ struct hash_table *ht;
};
}
+void
+matrix_flipper::transform_operands(ir_expression *ir,
+ ir_variable *mat_var,
+ ir_variable *mat_transpose)
+{
+#ifndef NDEBUG
+ ir_dereference_variable *deref = ir-operands[0]-as_dereference_variable();
+ assert(deref deref-var == mat_var);
+#endif
+
+ void *mem_ctx = ralloc_parent(ir);
+ ir-operands[0] = ir-operands[1];
+ ir-operands[1] = new(mem_ctx) ir_dereference_variable(mat_transpose);
+}
+
+void
+matrix_flipper::transform_operands_array_of_matrix(ir_expression *ir,
+
[Mesa-dev] [PATCH] i965: Save meta blit programs in the context.
When the last context in a share group is destroyed, the hash table
containing all of the shader programs (ctx-Shared-ShaderObjects) is
destroyed, throwing away all of the shader programs.
Using a static variable to store program IDs ends up holding on to them
after this, so we think we still have a compiled program, when it
actually got destroyed. _mesa_UseProgram then hits GL errors, since no
program by that ID exists.
Instead, store the program IDs in the context, so we know to recompile
if our context gets destroyed and the application creates another one.
Fixes es3conform tests when run without -minfmt (where it creates
separate contexts for testing each visual).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77865
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.h | 3 +++
src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c | 18 ++
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 283c576..72cf39b 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1115,6 +1115,9 @@ struct brw_context
struct brw_cache cache;
+ /** IDs for meta stencil blit shader programs. */
+ unsigned meta_stencil_blit_programs[2];
+
/* Whether a meta-operation is in progress. */
bool meta_in_progress;
diff --git a/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
b/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
index 5d132b7..bdd642b 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
@@ -272,28 +272,30 @@ setup_coord_transform(GLuint prog, const struct blit_dims
*dims)
}
static GLuint
-setup_program(struct gl_context *ctx, bool msaa_tex)
+setup_program(struct brw_context *brw, bool msaa_tex)
{
+ struct gl_context *ctx = brw-ctx;
struct blit_state *blit = ctx-Meta-Blit;
- static GLuint prog_cache[] = { 0, 0 };
char *fs_source;
const struct sampler_and_fetch *sampler = samplers[msaa_tex];
_mesa_meta_setup_vertex_objects(blit-VAO, blit-VBO, true, 2, 2, 0);
- if (prog_cache[msaa_tex]) {
- _mesa_UseProgram(prog_cache[msaa_tex]);
- return prog_cache[msaa_tex];
+ GLuint *prog_id = brw-meta_stencil_blit_programs[msaa_tex];
+
+ if (*prog_id) {
+ _mesa_UseProgram(*prog_id);
+ return *prog_id;
}
fs_source = ralloc_asprintf(NULL, fs_tmpl, sampler-sampler,
sampler-fetch);
_mesa_meta_compile_and_link_program(ctx, vs_source, fs_source,
i965 stencil blit,
- prog_cache[msaa_tex]);
+ prog_id);
ralloc_free(fs_source);
- return prog_cache[msaa_tex];
+ return *prog_id;
}
/**
@@ -427,7 +429,7 @@ brw_meta_stencil_blit(struct brw_context *brw,
_mesa_TexParameteri(target, GL_DEPTH_STENCIL_TEXTURE_MODE,
GL_STENCIL_INDEX);
- prog = setup_program(ctx, target != GL_TEXTURE_2D);
+ prog = setup_program(brw, target != GL_TEXTURE_2D);
setup_bounding_rect(prog, orig_dims);
setup_drawing_rect(prog, dims);
setup_coord_transform(prog, orig_dims);
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 09/23] glsl: Store info about geometry shaders that emit vertices to non-zero streams.
On Wed, 2014-06-18 at 13:05 -0700, Ian Romanick wrote:
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
On Intel hardware when a geometry shader outputs GL_POINTS primitives we
only need to emit vertex control bits if it emits vertices to non-zero
streams, so use a flag to track this.
This flag will be set to TRUE when a geometry shader calls
EmitStreamVertex()
or EndStreamPrimitive() with a non-zero stream parameter in a later patch.
---
src/mesa/main/mtypes.h | 2 ++
src/mesa/main/shaderapi.c | 1 +
src/mesa/main/shaderobj.c | 1 +
src/mesa/program/program.c | 1 +
4 files changed, 5 insertions(+)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index f45dde4..5bc710e 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2178,6 +2178,7 @@ struct gl_geometry_program
GL_TRIANGLES, or GL_TRIANGLES_ADJACENCY_ARB */
GLenum OutputType; /** GL_POINTS, GL_LINE_STRIP or GL_TRIANGLE_STRIP */
GLboolean UsesEndPrimitive;
+ GLboolean UsesStreams;
For things that are not visible to the GL API, we've been trying to
transition away from GL types. Unless Brian or Chris object, I think
I'd rather have this be bool (and true / false below).
If Brian and Chris are okay with this change then I'll also change
UsesEndPrimitive to be bool.
};
@@ -2681,6 +2682,7 @@ struct gl_shader_program
GLuint ClipDistanceArraySize; /** Size of the gl_ClipDistance
array, or
0 if not present. */
GLboolean UsesEndPrimitive;
+ GLboolean UsesStreams;
} Geom;
/** Vertex shader state */
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 2ec2444..2bbef35 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1888,6 +1888,7 @@ _mesa_copy_linked_program_data(gl_shader_stage type,
dst_gp-OutputType = src-Geom.OutputType;
dst-UsesClipDistanceOut = src-Geom.UsesClipDistance;
dst_gp-UsesEndPrimitive = src-Geom.UsesEndPrimitive;
+ dst_gp-UsesStreams = src-Geom.UsesStreams;
}
break;
case MESA_SHADER_FRAGMENT: {
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index b0f0bfa..03db862 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -248,6 +248,7 @@ _mesa_init_shader_program(struct gl_context *ctx,
struct gl_shader_program *prog
prog-Geom.VerticesOut = 0;
prog-Geom.InputType = GL_TRIANGLES;
prog-Geom.OutputType = GL_TRIANGLE_STRIP;
+ prog-Geom.UsesStreams = GL_FALSE;
prog-TransformFeedback.BufferMode = GL_INTERLEAVED_ATTRIBS;
diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
index b7332fc..1263cea 100644
--- a/src/mesa/program/program.c
+++ b/src/mesa/program/program.c
@@ -552,6 +552,7 @@ _mesa_clone_program(struct gl_context *ctx, const
struct gl_program *prog)
gpc-InputType = gp-InputType;
gpc-Invocations = gp-Invocations;
gpc-OutputType = gp-OutputType;
+ gpc-UsesStreams = gp-UsesStreams;
}
break;
default:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 11/23] glsl: Add support for EmitStreamVertex() and EndStreamPrimitive().
On Wed, 2014-06-18 at 13:31 -0700, Ian Romanick wrote:
This patch should be split into several patches:
1. Modify ir_emit_vertex to have a stream. This patch also needs to update
ir_to_mesa.cpp and st_glsl_to_tgsi.cpp.
2. Modify ir_end_primitive to have a stream. This patch also needs to update
ir_to_mesa.cpp and st_glsl_to_tgsi.cpp.
3. Add the new built-in functions.
Ok, I will rework the patch accordingly.
A couple other minor comments below...
(...)
+ir_function_signature *
+builtin_builder::_EmitStreamVertex(builtin_available_predicate avail,
+ const glsl_type *stream_type)
+{
Please add a spec quotation for this. I had to go look it up to be sure
ir_var_const_in was correct.
/* Section 8.12 (Geometry Shader Functions) of the OpenGL 4.0 spec says:
*
* Completes the current output primitive on stream stream and starts
* a new one. The argument to stream must be a constant integral
* expression.
*/
I think you meant the GLSL 4.0 spec here.
+ ir_variable *stream =
+ new(mem_ctx) ir_variable(stream_type, stream, ir_var_const_in);
+
+ MAKE_SIG(glsl_type::void_type, avail, 1, stream);
+
+ body.emit(new(mem_ctx) ir_emit_vertex(var_ref(stream)));
return sig;
}
@@ -3882,7 +3915,22 @@ builtin_builder::_EndPrimitive()
{
MAKE_SIG(glsl_type::void_type, gs_only, 0);
- body.emit(new(mem_ctx) ir_end_primitive());
+ ir_rvalue *stream = new(mem_ctx) ir_constant(0, 1);
+ body.emit(new(mem_ctx) ir_end_primitive(stream));
+
+ return sig;
+}
(...)
Iago
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 09/23] glsl: Store info about geometry shaders that emit vertices to non-zero streams.
Sounds good to me.
On Thu, Jun 19, 2014 at 7:23 PM, Iago Toral ito...@igalia.com wrote:
On Wed, 2014-06-18 at 13:05 -0700, Ian Romanick wrote:
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
On Intel hardware when a geometry shader outputs GL_POINTS primitives we
only need to emit vertex control bits if it emits vertices to non-zero
streams, so use a flag to track this.
This flag will be set to TRUE when a geometry shader calls
EmitStreamVertex()
or EndStreamPrimitive() with a non-zero stream parameter in a later patch.
---
src/mesa/main/mtypes.h | 2 ++
src/mesa/main/shaderapi.c | 1 +
src/mesa/main/shaderobj.c | 1 +
src/mesa/program/program.c | 1 +
4 files changed, 5 insertions(+)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index f45dde4..5bc710e 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2178,6 +2178,7 @@ struct gl_geometry_program
GL_TRIANGLES, or GL_TRIANGLES_ADJACENCY_ARB */
GLenum OutputType; /** GL_POINTS, GL_LINE_STRIP or GL_TRIANGLE_STRIP
*/
GLboolean UsesEndPrimitive;
+ GLboolean UsesStreams;
For things that are not visible to the GL API, we've been trying to
transition away from GL types. Unless Brian or Chris object, I think
I'd rather have this be bool (and true / false below).
If Brian and Chris are okay with this change then I'll also change
UsesEndPrimitive to be bool.
};
@@ -2681,6 +2682,7 @@ struct gl_shader_program
GLuint ClipDistanceArraySize; /** Size of the gl_ClipDistance
array, or
0 if not present. */
GLboolean UsesEndPrimitive;
+ GLboolean UsesStreams;
} Geom;
/** Vertex shader state */
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 2ec2444..2bbef35 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1888,6 +1888,7 @@ _mesa_copy_linked_program_data(gl_shader_stage type,
dst_gp-OutputType = src-Geom.OutputType;
dst-UsesClipDistanceOut = src-Geom.UsesClipDistance;
dst_gp-UsesEndPrimitive = src-Geom.UsesEndPrimitive;
+ dst_gp-UsesStreams = src-Geom.UsesStreams;
}
break;
case MESA_SHADER_FRAGMENT: {
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index b0f0bfa..03db862 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -248,6 +248,7 @@ _mesa_init_shader_program(struct gl_context *ctx,
struct gl_shader_program *prog
prog-Geom.VerticesOut = 0;
prog-Geom.InputType = GL_TRIANGLES;
prog-Geom.OutputType = GL_TRIANGLE_STRIP;
+ prog-Geom.UsesStreams = GL_FALSE;
prog-TransformFeedback.BufferMode = GL_INTERLEAVED_ATTRIBS;
diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
index b7332fc..1263cea 100644
--- a/src/mesa/program/program.c
+++ b/src/mesa/program/program.c
@@ -552,6 +552,7 @@ _mesa_clone_program(struct gl_context *ctx, const
struct gl_program *prog)
gpc-InputType = gp-InputType;
gpc-Invocations = gp-Invocations;
gpc-OutputType = gp-OutputType;
+ gpc-UsesStreams = gp-UsesStreams;
}
break;
default:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 09/23] glsl: Store info about geometry shaders that emit vertices to non-zero streams.
(but maybe in a separate patch)
On Thu, Jun 19, 2014 at 7:53 PM, Chris Forbes chr...@ijw.co.nz wrote:
Sounds good to me.
On Thu, Jun 19, 2014 at 7:23 PM, Iago Toral ito...@igalia.com wrote:
On Wed, 2014-06-18 at 13:05 -0700, Ian Romanick wrote:
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
On Intel hardware when a geometry shader outputs GL_POINTS primitives we
only need to emit vertex control bits if it emits vertices to non-zero
streams, so use a flag to track this.
This flag will be set to TRUE when a geometry shader calls
EmitStreamVertex()
or EndStreamPrimitive() with a non-zero stream parameter in a later patch.
---
src/mesa/main/mtypes.h | 2 ++
src/mesa/main/shaderapi.c | 1 +
src/mesa/main/shaderobj.c | 1 +
src/mesa/program/program.c | 1 +
4 files changed, 5 insertions(+)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index f45dde4..5bc710e 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2178,6 +2178,7 @@ struct gl_geometry_program
GL_TRIANGLES, or GL_TRIANGLES_ADJACENCY_ARB */
GLenum OutputType; /** GL_POINTS, GL_LINE_STRIP or GL_TRIANGLE_STRIP
*/
GLboolean UsesEndPrimitive;
+ GLboolean UsesStreams;
For things that are not visible to the GL API, we've been trying to
transition away from GL types. Unless Brian or Chris object, I think
I'd rather have this be bool (and true / false below).
If Brian and Chris are okay with this change then I'll also change
UsesEndPrimitive to be bool.
};
@@ -2681,6 +2682,7 @@ struct gl_shader_program
GLuint ClipDistanceArraySize; /** Size of the gl_ClipDistance
array, or
0 if not present. */
GLboolean UsesEndPrimitive;
+ GLboolean UsesStreams;
} Geom;
/** Vertex shader state */
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 2ec2444..2bbef35 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1888,6 +1888,7 @@ _mesa_copy_linked_program_data(gl_shader_stage type,
dst_gp-OutputType = src-Geom.OutputType;
dst-UsesClipDistanceOut = src-Geom.UsesClipDistance;
dst_gp-UsesEndPrimitive = src-Geom.UsesEndPrimitive;
+ dst_gp-UsesStreams = src-Geom.UsesStreams;
}
break;
case MESA_SHADER_FRAGMENT: {
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index b0f0bfa..03db862 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -248,6 +248,7 @@ _mesa_init_shader_program(struct gl_context *ctx,
struct gl_shader_program *prog
prog-Geom.VerticesOut = 0;
prog-Geom.InputType = GL_TRIANGLES;
prog-Geom.OutputType = GL_TRIANGLE_STRIP;
+ prog-Geom.UsesStreams = GL_FALSE;
prog-TransformFeedback.BufferMode = GL_INTERLEAVED_ATTRIBS;
diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
index b7332fc..1263cea 100644
--- a/src/mesa/program/program.c
+++ b/src/mesa/program/program.c
@@ -552,6 +552,7 @@ _mesa_clone_program(struct gl_context *ctx, const
struct gl_program *prog)
gpc-InputType = gp-InputType;
gpc-Invocations = gp-Invocations;
gpc-OutputType = gp-OutputType;
+ gpc-UsesStreams = gp-UsesStreams;
}
break;
default:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Broadcom VC4 project
Dave Airlie airl...@gmail.com writes: I'm working toward building a Mesa driver for Broadcom VC4 (aka Raspberry Pi). At the moment I'm still bringing up the DRM side of things, but I hope to be doing bits of userspace in the next few days. Current status is I have a skeleton DRM KMS driver that's going to talk to the firmware for modesetting, and now I'm starting on the execution side of things. I'm probably going to start out doing a gallium driver for simplicity, to avoid having to do all the DRI crap we've got in brw_context.c and texture miptree validation and getting user data into VBOs and all that other almost-boilerplate. Long term I may end up switching to classic so I can get swrast fallbacks and the ability to implement single-copy manually-tiled TexImage uploads like. For now I want to get to drawing triangles as soon as I can. Do we know anywhere swrast fallbacks make sense? like except for conformance testing, You've got an armv6 swrast fallbacks are going to be punishing, I don't even think it has neon extensions. Yeah, but fallbacks are less punishing than my screen is black, what's going on?!?! bug reports. pgpn8P6u2Cz_L.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Broadcom VC4 project
Marek Olšák mar...@gmail.com writes: We already have transfer_inline_write. Looks like that's only used from finalize, currently? But if the idea's already present, that's promising. pgpLOuHqVEH2j.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 01/23] glsl: Add parsing support for multi-stream output in geometry shaders.
On Wed, 2014-06-18 at 11:16 -0700, Ian Romanick wrote: (...) Please replace this comment with the following spec quotation: /* Section 4.3.8.2 (Output Layout Qualifiers) of the OpenGL 4.00 I think you meant the GLSL spec. * spec says: * * If the block or variable is declared with the stream * identifier, it is associated with the specified stream; * otherwise, it is associated with the current default stream. */ + $$.flags.q.stream = 1; + $$.flags.q.explicit_stream = 0; + $$.stream = state-out_qualifier-stream; + } Iago ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nouveau: dup fd before passing it to device
nouveau screens are reused for the same device node. However in the scenario where we create screen 1, screen 2, and then delete screen 1, the surrounding code might also close the original device node. To protect against this, dup the fd and use the dup'd fd in the nouveau_device. Also tell the nouveau_device that it is the owner of the fd so that it will be closed on destruction. Also make sure to free the nouveau_device in case of any failure. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79823 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c index 1dfdaac..833fb9a 100644 --- a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c +++ b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c @@ -1,4 +1,5 @@ #include sys/stat.h +#include unistd.h #include pipe/p_context.h #include pipe/p_state.h #include util/u_format.h @@ -75,7 +76,14 @@ nouveau_drm_screen_create(int fd) return screen-base; } - ret = nouveau_device_wrap(fd, 0, dev); + /* Since the screen re-use is based on the device node and not the fd, +* create a copy of the fd to be owned by the device. Otherwise a +* scenario could occur where two screens are created, and the first +* one is shut down, along with the fd being closed. The second +* (identical) screen would now have a reference to the closed fd. We +* avoid this by duplicating the original fd. +*/ + ret = nouveau_device_wrap(dup(fd), 1, dev); if (ret) goto err; @@ -115,6 +123,8 @@ nouveau_drm_screen_create(int fd) return screen-base; err: + if (dev) + nouveau_device_del(dev); pipe_mutex_unlock(nouveau_screen_mutex); return NULL; } -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/11] clover: Use PIPE_TRANSFER_MAP_DIRECTLY when writing/reading buffers
On Thu, 2014-06-19 at 10:23 +0900, Michel Dänzer wrote:
On 19.06.2014 00:02, Bruno Jiménez wrote:
Note: This is just a proof of concept.
---
src/gallium/state_trackers/clover/api/transfer.cpp | 4 ++--
src/gallium/state_trackers/clover/core/object.hpp | 4
src/gallium/state_trackers/clover/core/resource.cpp | 2 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/transfer.cpp
b/src/gallium/state_trackers/clover/api/transfer.cpp
index 404ceb0..f34ae8b 100644
--- a/src/gallium/state_trackers/clover/api/transfer.cpp
+++ b/src/gallium/state_trackers/clover/api/transfer.cpp
@@ -174,8 +174,8 @@ namespace {
static mapping
get(command_queue q, T obj, cl_map_flags flags,
size_t offset, size_t size) {
- return { q, obj-resource(q), flags, true,
- {{ offset }}, {{ size, 1, 1 }} };
+ return { q, obj-resource(q), flags |
CLOVER_TRANSFER_MAP_DIRECTLY,
+ true, {{ offset }}, {{ size, 1, 1 }} };
}
};
diff --git a/src/gallium/state_trackers/clover/core/object.hpp
b/src/gallium/state_trackers/clover/core/object.hpp
index 697565c..7d5adf9 100644
--- a/src/gallium/state_trackers/clover/core/object.hpp
+++ b/src/gallium/state_trackers/clover/core/object.hpp
@@ -33,6 +33,10 @@
#include core/property.hpp
#include api/dispatch.hpp
+#ifndef CLOVER_TRANSFER_MAP_DIRECTLY
+#define CLOVER_TRANSFER_MAP_DIRECTLY (18)
+#endif
+
///
/// Main namespace of the CL state tracker.
///
diff --git a/src/gallium/state_trackers/clover/core/resource.cpp
b/src/gallium/state_trackers/clover/core/resource.cpp
index 7b8a40a..c8e97db 100644
--- a/src/gallium/state_trackers/clover/core/resource.cpp
+++ b/src/gallium/state_trackers/clover/core/resource.cpp
@@ -174,6 +174,8 @@ mapping::mapping(command_queue q, resource r,
pctx(q.pipe) {
unsigned usage = ((flags CL_MAP_WRITE ? PIPE_TRANSFER_WRITE : 0 ) |
(flags CL_MAP_READ ? PIPE_TRANSFER_READ : 0 ) |
+ (flags CLOVER_TRANSFER_MAP_DIRECTLY ?
+ PIPE_TRANSFER_MAP_DIRECTLY : 0 ) |
(!blocking ? PIPE_TRANSFER_UNSYNCHRONIZED : 0));
p = pctx-transfer_map(pctx, r.pipe, 0, usage,
The driver can return NULL when PIPE_TRANSFER_MAP_DIRECTLY is set (if
the driver can't actually map the resource directly), so you'd need to
add code to try again without PIPE_TRANSFER_MAP_DIRECTLY in that case.
Hi,
Thanks for the information. The r600g driver can handle this with the
previous patch. But you are completely right about other drivers.
Anyway, as I have writen in the commit message, these two last patches
are just proofs of concept for a way to avoid unnecesary transfers
GPU-GPU and aren't needed to solve the mapping bug.
Thanks!
Bruno
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Save meta blit programs in the context.
Kenneth Graunke kenn...@whitecape.org writes: When the last context in a share group is destroyed, the hash table containing all of the shader programs (ctx-Shared-ShaderObjects) is destroyed, throwing away all of the shader programs. Reviewed-by: Eric Anholt e...@anholt.net pgpBNgFcIH1rb.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/llvm: Adapt to AMDGPU.rsq intrinsic change in LLVM 3.5
On Jun 18, 2014, at 11:53 PM, Michel Dänzer mic...@daenzer.net wrote: From: Michel Dänzer michel.daen...@amd.com Signed-off-by: Michel Dänzer michel.daen...@amd.com --- src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c index f8be0df..217fa32 100644 --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c @@ -1384,7 +1384,11 @@ void radeon_llvm_context_init(struct radeon_llvm_context * ctx) bld_base-op_actions[TGSI_OPCODE_UCMP].emit = emit_ucmp; bld_base-rsq_action.emit = build_tgsi_intrinsic_nomem; +#if HAVE_LLVM = 0x0305 + bld_base-rsq_action.intr_name = llvm.AMDGPU.rsq.; +#else bld_base-rsq_action.intr_name = llvm.AMDGPU.rsq; +#endif } void radeon_llvm_create_func(struct radeon_llvm_context * ctx, -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev While you’re at it, could you fix the old AMDIL intrinsics too? I don’t think these have been updated yet (although the old names still technically work) llvm.AMDIL.abs - llvm.AMDGPU.abs llvm.AMDIL.clamp - llvm.AMDGPU.clamp llvm.AMDIL.fraction - llvm.AMDGPU.fract llvm.AMDIL.exp - llvm.exp2 llvm.AMDIL.round.nearest - llvm.rint ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: set mcpu when initializing llvm execution engine
Looks good. Thanks Roland.
Jose
From: srol...@vmware.com srol...@vmware.com
Sent: 19 June 2014 02:28
To: Jose Fonseca; mesa-dev@lists.freedesktop.org
Cc: Roland Scheidegger
Subject: [PATCH] gallivm: set mcpu when initializing llvm execution engine
From: Roland Scheidegger srol...@vmware.com
Previously llvm detected cpu features automatically when the execution engine
was created (based on host cpu). This is no longer the case, which meant llvm
was then not able to emit some of the intrinsics we used as we didn't specify
any sse attributes (only on avx supporting systems this was not a problem since
despite at least some llvm versions enabling it anyway we always set this
manually). So, instead of trying to figure out which MAttrs to set just set
MCPU.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=77493.
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 38fbe1f..6bea964 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -468,8 +468,8 @@
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
/*
* AVX feature is not automatically detected from CPUID by the X86 target
* yet, because the old (yet default) JIT engine is not capable of
- * emitting the opcodes. But as we're using MCJIT here, it is safe to
- * add set this attribute.
+ * emitting the opcodes. On newer llvm versions it is and at least some
+ * versions (tested with 3.3) will emit avx opcodes without this anyway.
*/
MAttrs.push_back(+avx);
if (util_cpu_caps.has_f16c) {
@@ -478,12 +478,30 @@
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
builder.setMAttrs(MAttrs);
}
+#if HAVE_LLVM = 0x0305
+ StringRef MCPU = llvm::sys::getHostCPUName();
+ /*
+* The cpu bits are no longer set automatically, so need to set mcpu
manually.
+* Note that the MAttrs set above will be sort of ignored (since we should
+* not set any which would not be set by specifying the cpu anyway).
+* It ought to be safe though since getHostCPUName() should include bits
+* not only from the cpu but environment as well (for instance if it's safe
+* to use avx instructions which need OS support). According to
+* http://llvm.org/bugs/show_bug.cgi?id=19429 however if I understand this
+* right it may be necessary to specify older cpu (or disable mattrs) though
+* when not using MCJIT so no instructions are generated which the old JIT
+* can't handle. Not entirely sure if we really need to do anything yet.
+*/
+ builder.setMCPU(MCPU);
+#endif
+
ShaderMemoryManager *MM = new ShaderMemoryManager();
*OutCode = MM-getGeneratedCode();
builder.setJITMemoryManager(MM);
ExecutionEngine *JIT;
+
#if HAVE_LLVM = 0x0302
JIT = builder.create();
#else
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 11/23] glsl: Add support for EmitStreamVertex() and EndStreamPrimitive().
After having a quick look at ir_to_mesa.cpp and st_glsl_to_tgsi.cpp I
have some comments and questions about this:
On Wed, 2014-06-18 at 13:31 -0700, Ian Romanick wrote:
This patch should be split into several patches:
1. Modify ir_emit_vertex to have a stream. This patch also needs to update
ir_to_mesa.cpp and st_glsl_to_tgsi.cpp.
ir_to_mesa.cpp does not currently implement support for emit_vertex and
end_primitive at all:
void
ir_to_mesa_visitor::visit(ir_emit_vertex *)
{
assert(!Geometry shaders not supported.);
}
void
ir_to_mesa_visitor::visit(ir_end_primitive *)
{
assert(!Geometry shaders not supported.);
}
so doing this, as far as I can see, involves defining opcodes for
emit_vertex and end_primitive and then handle these opcodes properly in
other places of the code so things can get done I guess. I am not yet
familiar with this parts of the code base, so I guess I'll need some
time to figure how to do this right. Since ir_to_mesa.cpp is not
currently supporting ir_emit_vertex and ir_end_primitive at all, would
it be okay if we do this on a later patch after this series has been
reviewed ad merged?
Also, how can I debug this part of the code? what drivers are using
this?
Regarding st_glsl_to_tgsi.cpp, I think I can use some guidance since I
am not familiar with gallium. Seeing what is being done for other IR
types, I think I need to do something like:
st_src_reg stream_src = ir-stream-accept(this);
and then emit the TGSI_OPCODE_EMIT passing stream_src to it.
However, I see that glsl_to_tgsi_visitor::emit() can take no src/dst
arguments or if it takes, it takes one dst/src pair at least, so I am
not sure what should be done here... what do I have to use for the dst
parameter? should I just pass undef_dst? something else?
2. Modify ir_end_primitive to have a stream. This patch also needs to update
ir_to_mesa.cpp and st_glsl_to_tgsi.cpp.
3. Add the new built-in functions.
A couple other minor comments below...
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
---
src/glsl/builtin_functions.cpp | 52
++--
src/glsl/ir.h| 34 +--
src/glsl/ir_hierarchical_visitor.cpp | 50
+-
src/glsl/ir_hierarchical_visitor.h | 6 +++--
src/glsl/ir_hv_accept.cpp| 21 ---
src/glsl/ir_rvalue_visitor.cpp | 37 +
src/glsl/ir_rvalue_visitor.h | 6 +
src/glsl/lower_output_reads.cpp | 4 +--
src/glsl/lower_packed_varyings.cpp | 4 +--
src/glsl/opt_dead_code_local.cpp | 2 +-
10 files changed, 178 insertions(+), 38 deletions(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index f9f0686..07a0722 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -359,6 +359,12 @@ shader_image_load_store(const _mesa_glsl_parse_state
*state)
state-ARB_shader_image_load_store_enable);
}
+static bool
+gs_streams(const _mesa_glsl_parse_state *state)
+{
+ return gpu_shader5(state) gs_only(state);
+}
+
/** @} */
/**/
@@ -594,6 +600,10 @@ private:
B0(EmitVertex)
B0(EndPrimitive)
+ ir_function_signature *_EmitStreamVertex(builtin_available_predicate
avail,
+const glsl_type *stream_type);
+ ir_function_signature *_EndStreamPrimitive(builtin_available_predicate
avail,
+ const glsl_type
*stream_type);
B2(textureQueryLod);
B1(textureQueryLevels);
@@ -1708,6 +1718,14 @@ builtin_builder::create_builtins()
add_function(EmitVertex, _EmitVertex(), NULL);
add_function(EndPrimitive, _EndPrimitive(), NULL);
+ add_function(EmitStreamVertex,
+_EmitStreamVertex(gs_streams, glsl_type::uint_type),
+_EmitStreamVertex(gs_streams, glsl_type::int_type),
+NULL);
+ add_function(EndStreamPrimitive,
+_EndStreamPrimitive(gs_streams, glsl_type::uint_type),
+_EndStreamPrimitive(gs_streams, glsl_type::int_type),
+NULL);
add_function(textureQueryLOD,
_textureQueryLod(glsl_type::sampler1D_type,
glsl_type::float_type),
@@ -3872,7 +3890,22 @@ builtin_builder::_EmitVertex()
{
MAKE_SIG(glsl_type::void_type, gs_only, 0);
- body.emit(new(mem_ctx) ir_emit_vertex());
+ ir_rvalue *stream = new(mem_ctx) ir_constant(0, 1);
+ body.emit(new(mem_ctx) ir_emit_vertex(stream));
+
+ return sig;
+}
+
+ir_function_signature *
+builtin_builder::_EmitStreamVertex(builtin_available_predicate avail,
+ const glsl_type *stream_type)
+{
Please add a spec
Re: [Mesa-dev] [PATCH 00/23] Megadrivers galore
On Tue, Jun 17, 2014 at 8:38 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Hi all, As a follow up to the static/shared pipe-drivers series here is the final series (if anyone is interested I may take a look at egl + opencl) of refactoring the gallium dri targets into a single library/provider. In a nutshell: - Convert one target per patch. - Merge the drm and sw backends of our dri state-tracker. - Adds __driDriverGetExtensions_$drivername symbol for each driver. - Megadrivers. - *** - Profit. Things works like a charm for nouveau and swrast, and testing on other platforms is greatly appreciated. The complete series can be found in the static-or-shared-pipe-drivers-v2 branch at my github repo. I would like to get this reviewed/pushed over the next month, although that depends on the number of bugs that come up with the previous batch. As always comments, suggestions and flame is welcome. I'm trying to get a better grasp of the resulting set of binaries will look like on a distro, correct me if I'm wrong, by default we will get one gallium_dri.so that is linked against shared dri core and glapi correct. And then hardlinks from say vmwgfx_dri.so to gallium_dri.so? Also looking at the patch it looks like stdri can still be build without DRM installed on the system? I remember the Hurd people being quite vocal about this. Cheers, Jakob. Cheers, Emil Emil Velikov (23): targets/dri-swrast: use drm aware dricommon when building more than swrast st/dri: Allow separate dri-targets st/dri/drm: Add a second libdridrm library targets/dri-nouveau: Convert to static/shared pipe-drivers targets/(r300|r600|radeonsi)/dri: Convert to static/shared pipe-drivers targets/dri-freedreno: Convert to static/shared pipe-drivers targets/dri-i915: Convert to static/shared pipe-drivers targets/dri-ilo: Convert to static/shared pipe-driver targets/dri-vmwgfx: Convert to static/shared pipe-drivers st/dri: Remove the old libdridrm library targets/dri: Add __driDriverGetExtensions_nouveau symbol targets/dri: Add __driDriverGetExtensions_(r300|r600|radeonsi) symbols targets/dri: Add __driDriverGetExtensions_freedreno symbol targets/dri: Add __driDriverGetExtensions_i915 symbol targets/dri: Add __driDriverGetExtensions_i965 symbol targets/dri: Add __driDriverGetExtensions_vmwgfx targets/dri: update scons build to handle __driDriverGetExtensions_vmwgfx targets/dri: cleanup conversion leftovers st/dri/drm: remove __driDriverExtensions and driDriverAPI scons: build and use a single dri_common library targets/dri-swrast: convert to gallium megadrivers :) st/dri: merge dri/drm and dri/sw backends targets/dri-swrast: Convert to static/shared pipe-driver 61 files changed, 536 insertions(+), 1375 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/23] Megadrivers galore
Hi Jakob, libdricore was nuked quite some time ago. What classic drivers now use is all drivers in mesa_dri_drivers.so and the _dri.so files are hardlinks to that file. Marek On Thu, Jun 19, 2014 at 12:54 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Tue, Jun 17, 2014 at 8:38 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Hi all, As a follow up to the static/shared pipe-drivers series here is the final series (if anyone is interested I may take a look at egl + opencl) of refactoring the gallium dri targets into a single library/provider. In a nutshell: - Convert one target per patch. - Merge the drm and sw backends of our dri state-tracker. - Adds __driDriverGetExtensions_$drivername symbol for each driver. - Megadrivers. - *** - Profit. Things works like a charm for nouveau and swrast, and testing on other platforms is greatly appreciated. The complete series can be found in the static-or-shared-pipe-drivers-v2 branch at my github repo. I would like to get this reviewed/pushed over the next month, although that depends on the number of bugs that come up with the previous batch. As always comments, suggestions and flame is welcome. I'm trying to get a better grasp of the resulting set of binaries will look like on a distro, correct me if I'm wrong, by default we will get one gallium_dri.so that is linked against shared dri core and glapi correct. And then hardlinks from say vmwgfx_dri.so to gallium_dri.so? Also looking at the patch it looks like stdri can still be build without DRM installed on the system? I remember the Hurd people being quite vocal about this. Cheers, Jakob. Cheers, Emil Emil Velikov (23): targets/dri-swrast: use drm aware dricommon when building more than swrast st/dri: Allow separate dri-targets st/dri/drm: Add a second libdridrm library targets/dri-nouveau: Convert to static/shared pipe-drivers targets/(r300|r600|radeonsi)/dri: Convert to static/shared pipe-drivers targets/dri-freedreno: Convert to static/shared pipe-drivers targets/dri-i915: Convert to static/shared pipe-drivers targets/dri-ilo: Convert to static/shared pipe-driver targets/dri-vmwgfx: Convert to static/shared pipe-drivers st/dri: Remove the old libdridrm library targets/dri: Add __driDriverGetExtensions_nouveau symbol targets/dri: Add __driDriverGetExtensions_(r300|r600|radeonsi) symbols targets/dri: Add __driDriverGetExtensions_freedreno symbol targets/dri: Add __driDriverGetExtensions_i915 symbol targets/dri: Add __driDriverGetExtensions_i965 symbol targets/dri: Add __driDriverGetExtensions_vmwgfx targets/dri: update scons build to handle __driDriverGetExtensions_vmwgfx targets/dri: cleanup conversion leftovers st/dri/drm: remove __driDriverExtensions and driDriverAPI scons: build and use a single dri_common library targets/dri-swrast: convert to gallium megadrivers :) st/dri: merge dri/drm and dri/sw backends targets/dri-swrast: Convert to static/shared pipe-driver 61 files changed, 536 insertions(+), 1375 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/23] Megadrivers galore
On Thu, Jun 19, 2014 at 1:08 PM, Marek Olšák mar...@gmail.com wrote: Hi Jakob, libdricore was nuked quite some time ago. What classic drivers now use is all drivers in mesa_dri_drivers.so and the _dri.so files are hardlinks to that file. Ah, thanks for the info. Wouldn't that mean that mesa core code like the glsl compiler is duplicated in gallium_dri.so and mesa_dri_drivers.so? Cheers, Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/23] Megadrivers galore
Yes, that's correct. However, it's better to duplicate the same code twice than ten times. Marek On Thu, Jun 19, 2014 at 1:12 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Thu, Jun 19, 2014 at 1:08 PM, Marek Olšák mar...@gmail.com wrote: Hi Jakob, libdricore was nuked quite some time ago. What classic drivers now use is all drivers in mesa_dri_drivers.so and the _dri.so files are hardlinks to that file. Ah, thanks for the info. Wouldn't that mean that mesa core code like the glsl compiler is duplicated in gallium_dri.so and mesa_dri_drivers.so? Cheers, Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/11] gallium: Add __DRIimageDriverExtension support to gallium
On 19/06/2014 01:20, Ilia Mirkin wrote :
+static __DRIbuffer *
+dri2_allocate_buffer(__DRIscreen *sPriv,
+ unsigned attachment, unsigned format,
+ int width, int height)
+{
+ struct dri_screen *screen = dri_screen(sPriv);
+ struct dri2_buffer *buffer;
+ struct pipe_resource templ;
+ enum pipe_format pf;
+ unsigned bind = 0;
+ struct winsys_handle whandle;
+
+ switch (attachment) {
+ case __DRI_BUFFER_FRONT_LEFT:
+ case __DRI_BUFFER_FAKE_FRONT_LEFT:
+ bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
+ break;
+ case __DRI_BUFFER_BACK_LEFT:
+ bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
+ break;
+ case __DRI_BUFFER_DEPTH:
+ case __DRI_BUFFER_DEPTH_STENCIL:
+ case __DRI_BUFFER_STENCIL:
+bind = PIPE_BIND_DEPTH_STENCIL; /* XXX sampler? */
+ break;
+ }
+
+ /* because we get the handle and stride */
+ bind |= PIPE_BIND_SHARED;
+
+ switch (format) {
+ case 32:
+ pf = PIPE_FORMAT_B8G8R8A8_UNORM;
+ break;
+ case 24:
+ pf = PIPE_FORMAT_B8G8R8X8_UNORM;
+ break;
+ case 16:
+ pf = PIPE_FORMAT_Z16_UNORM;
+ break;
+ default:
+ return NULL;
+ }
+
+ buffer = CALLOC_STRUCT(dri2_buffer);
+ if (!buffer)
+ return NULL;
+
+ memset(templ, 0, sizeof(templ));
+ templ.bind = bind;
+ templ.format = pf;
+ templ.target = PIPE_TEXTURE_2D;
+ templ.last_level = 0;
+ templ.width0 = width;
+ templ.height0 = height;
+ templ.depth0 = 1;
+ templ.array_size = 1;
+
+ buffer-resource =
+ screen-base.screen-resource_create(screen-base.screen, templ);
I believe the expectation is that before you create resources with a
certain format/bind combo, you need to check first with
-is_format_supported. For example pre-NVA0 nv50 cards don't support
Z16.
This is git format-patch noise.
I don't change anything to dri2_allocate_buffer, if you see what is
added here is removed later.
Axel Davy
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/23] Megadrivers galore
Thanks again, and fair enough. :) Cheers, Jakob. On Thu, Jun 19, 2014 at 1:22 PM, Marek Olšák mar...@gmail.com wrote: Yes, that's correct. However, it's better to duplicate the same code twice than ten times. Marek On Thu, Jun 19, 2014 at 1:12 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Thu, Jun 19, 2014 at 1:08 PM, Marek Olšák mar...@gmail.com wrote: Hi Jakob, libdricore was nuked quite some time ago. What classic drivers now use is all drivers in mesa_dri_drivers.so and the _dri.so files are hardlinks to that file. Ah, thanks for the info. Wouldn't that mean that mesa core code like the glsl compiler is duplicated in gallium_dri.so and mesa_dri_drivers.so? Cheers, Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 11/23] glsl: Add support for EmitStreamVertex() and EndStreamPrimitive().
Samuel has reminded me that Ilia has already done some changes to
Gallium in order to check a piglit test for multi-stream support there,
so adding to the CC.
On Thu, 2014-06-19 at 12:37 +0200, Iago Toral wrote:
After having a quick look at ir_to_mesa.cpp and st_glsl_to_tgsi.cpp I
have some comments and questions about this:
On Wed, 2014-06-18 at 13:31 -0700, Ian Romanick wrote:
This patch should be split into several patches:
1. Modify ir_emit_vertex to have a stream. This patch also needs to update
ir_to_mesa.cpp and st_glsl_to_tgsi.cpp.
(...)
Regarding st_glsl_to_tgsi.cpp, I think I can use some guidance since I
am not familiar with gallium. Seeing what is being done for other IR
types, I think I need to do something like:
st_src_reg stream_src = ir-stream-accept(this);
and then emit the TGSI_OPCODE_EMIT passing stream_src to it.
However, I see that glsl_to_tgsi_visitor::emit() can take no src/dst
arguments or if it takes, it takes one dst/src pair at least, so I am
not sure what should be done here... what do I have to use for the dst
parameter? should I just pass undef_dst? something else?
2. Modify ir_end_primitive to have a stream. This patch also needs to
update
ir_to_mesa.cpp and st_glsl_to_tgsi.cpp.
3. Add the new built-in functions.
A couple other minor comments below...
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
---
src/glsl/builtin_functions.cpp | 52
++--
src/glsl/ir.h| 34 +--
src/glsl/ir_hierarchical_visitor.cpp | 50
+-
src/glsl/ir_hierarchical_visitor.h | 6 +++--
src/glsl/ir_hv_accept.cpp| 21 ---
src/glsl/ir_rvalue_visitor.cpp | 37 +
src/glsl/ir_rvalue_visitor.h | 6 +
src/glsl/lower_output_reads.cpp | 4 +--
src/glsl/lower_packed_varyings.cpp | 4 +--
src/glsl/opt_dead_code_local.cpp | 2 +-
10 files changed, 178 insertions(+), 38 deletions(-)
diff --git a/src/glsl/builtin_functions.cpp
b/src/glsl/builtin_functions.cpp
index f9f0686..07a0722 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -359,6 +359,12 @@ shader_image_load_store(const _mesa_glsl_parse_state
*state)
state-ARB_shader_image_load_store_enable);
}
+static bool
+gs_streams(const _mesa_glsl_parse_state *state)
+{
+ return gpu_shader5(state) gs_only(state);
+}
+
/** @} */
/**/
@@ -594,6 +600,10 @@ private:
B0(EmitVertex)
B0(EndPrimitive)
+ ir_function_signature *_EmitStreamVertex(builtin_available_predicate
avail,
+const glsl_type
*stream_type);
+ ir_function_signature
*_EndStreamPrimitive(builtin_available_predicate avail,
+ const glsl_type
*stream_type);
B2(textureQueryLod);
B1(textureQueryLevels);
@@ -1708,6 +1718,14 @@ builtin_builder::create_builtins()
add_function(EmitVertex, _EmitVertex(), NULL);
add_function(EndPrimitive, _EndPrimitive(), NULL);
+ add_function(EmitStreamVertex,
+_EmitStreamVertex(gs_streams, glsl_type::uint_type),
+_EmitStreamVertex(gs_streams, glsl_type::int_type),
+NULL);
+ add_function(EndStreamPrimitive,
+_EndStreamPrimitive(gs_streams, glsl_type::uint_type),
+_EndStreamPrimitive(gs_streams, glsl_type::int_type),
+NULL);
add_function(textureQueryLOD,
_textureQueryLod(glsl_type::sampler1D_type,
glsl_type::float_type),
@@ -3872,7 +3890,22 @@ builtin_builder::_EmitVertex()
{
MAKE_SIG(glsl_type::void_type, gs_only, 0);
- body.emit(new(mem_ctx) ir_emit_vertex());
+ ir_rvalue *stream = new(mem_ctx) ir_constant(0, 1);
+ body.emit(new(mem_ctx) ir_emit_vertex(stream));
+
+ return sig;
+}
+
+ir_function_signature *
+builtin_builder::_EmitStreamVertex(builtin_available_predicate avail,
+ const glsl_type *stream_type)
+{
Please add a spec quotation for this. I had to go look it up to be sure
ir_var_const_in was correct.
/* Section 8.12 (Geometry Shader Functions) of the OpenGL 4.0 spec says:
*
* Completes the current output primitive on stream stream and
starts
* a new one. The argument to stream must be a constant integral
* expression.
*/
+ ir_variable *stream =
+ new(mem_ctx) ir_variable(stream_type, stream, ir_var_const_in);
+
+ MAKE_SIG(glsl_type::void_type, avail, 1, stream);
+
+
Re: [Mesa-dev] [PATCH 1/5] clover: Don't use llvm's global context
Tom Stellard thomas.stell...@amd.com writes:
An LLVMContext should only be accessed by a single and using the global
context was causing crashes in multi-threaded environments. Now we use
a separate context for each compile.
For this patch:
Reviewed-by: Francisco Jerez curroje...@riseup.net
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 82e262f..48810bd 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -117,12 +117,13 @@ namespace {
#endif
llvm::Module *
- compile(const std::string source, const std::string name,
- const std::string triple, const std::string processor,
- const std::string opts, clang::LangAS::Map address_spaces) {
+ compile(llvm::LLVMContext llvm_ctx, const std::string source,
+ const std::string name, const std::string triple,
+ const std::string processor, const std::string opts,
+ clang::LangAS::Map address_spaces) {
clang::CompilerInstance c;
- clang::EmitLLVMOnlyAction act(llvm::getGlobalContext());
+ clang::EmitLLVMOnlyAction act(llvm_ctx);
std::string log;
llvm::raw_string_ostream s_log(log);
std::string libclc_path = LIBCLC_LIBEXECDIR + processor + -
@@ -394,10 +395,12 @@ clover::compile_program_llvm(const compat::string
source,
target.size() - processor_str_len - 1);
clang::LangAS::Map address_spaces;
+ llvm::LLVMContext llvm_ctx;
+
// The input file name must have the .cl extension in order for the
// CompilerInvocation class to recognize it as an OpenCL source file.
- llvm::Module *mod = compile(source, input.cl, triple, processor, opts,
-
address_spaces);
+ llvm::Module *mod = compile(llvm_ctx, source, input.cl, triple,
processor,
+ opts, address_spaces);
find_kernels(mod, kernels);
--
1.8.1.4
pgpM_iIF9x9ez.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] gallium: Add PIPE_SHADER_CAP_DOUBLES
Tom Stellard thomas.stell...@amd.com writes:
This is for reporting whether or not double precision floating-point
operations are supported.
Reviewed-by: Francisco Jerez curroje...@riseup.net
---
src/gallium/auxiliary/gallivm/lp_bld_limits.h | 2 ++
src/gallium/auxiliary/tgsi/tgsi_exec.h| 2 ++
src/gallium/docs/source/screen.rst| 2 ++
src/gallium/drivers/r300/r300_screen.c| 4
src/gallium/drivers/r600/r600_pipe.c | 2 ++
src/gallium/drivers/radeonsi/si_pipe.c| 5 +
src/gallium/drivers/svga/svga_screen.c| 4
src/gallium/include/pipe/p_defines.h | 3 ++-
8 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
index 6cb0949..9ccaf46 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
@@ -126,6 +126,8 @@ gallivm_get_shader_param(enum pipe_shader_cap param)
return PIPE_SHADER_IR_TGSI;
case PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED:
return 1;
+ case PIPE_SHADER_CAP_DOUBLES:
+ return 0;
}
/* if we get here, we missed a shader cap above (and should have seen
* a compiler warning.)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h
b/src/gallium/auxiliary/tgsi/tgsi_exec.h
index d53c4ba..56a7034 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
@@ -456,6 +456,8 @@ tgsi_exec_get_shader_param(enum pipe_shader_cap param)
return PIPE_SHADER_IR_TGSI;
case PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED:
return 1;
+ case PIPE_SHADER_CAP_DOUBLES:
+ return 0;
}
/* if we get here, we missed a shader cap above (and should have seen
* a compiler warning.)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index b8e356f..2867bfc 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -282,6 +282,8 @@ to be 0.
program. It should be one of the ``pipe_shader_ir`` enum values.
* ``PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS``: The maximum number of texture
sampler views. Must not be lower than PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS.
+* ``PIPE_SHADER_CAP_DOUBLES``: Whether double precision floating-point
+ operations are supported.
.. _pipe_compute_cap:
diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index 82d30e7..e5ed59a 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -262,6 +262,8 @@ static int r300_get_shader_param(struct pipe_screen
*pscreen, unsigned shader, e
return 0;
case PIPE_SHADER_CAP_PREFERRED_IR:
return PIPE_SHADER_IR_TGSI;
+case PIPE_SHADER_CAP_DOUBLES:
+return 0;
}
break;
case PIPE_SHADER_VERTEX:
@@ -313,6 +315,8 @@ static int r300_get_shader_param(struct pipe_screen
*pscreen, unsigned shader, e
return 0;
case PIPE_SHADER_CAP_PREFERRED_IR:
return PIPE_SHADER_IR_TGSI;
+case PIPE_SHADER_CAP_DOUBLES:
+return 0;
}
break;
}
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 2b65056..24e3c1a 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -444,6 +444,8 @@ static int r600_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, e
} else {
return PIPE_SHADER_IR_TGSI;
}
+case PIPE_SHADER_CAP_DOUBLES:
+ return 0;
}
return 0;
}
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 4b96f20..9eab1fe 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -321,6 +321,9 @@ static int si_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, enu
switch (param) {
case PIPE_SHADER_CAP_PREFERRED_IR:
return PIPE_SHADER_IR_LLVM;
+ case PIPE_SHADER_CAP_DOUBLES:
+ return 0; /* TODO: Report doubles as supported once
+ * the compiler is ready. */
default:
return 0;
}
@@ -372,6 +375,8 @@ static int si_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, enu
return 16;
case PIPE_SHADER_CAP_PREFERRED_IR:
return PIPE_SHADER_IR_TGSI;
+ case PIPE_SHADER_CAP_DOUBLES:
+ return 0;
}
return 0;
}
diff --git a/src/gallium/drivers/svga/svga_screen.c
b/src/gallium/drivers/svga/svga_screen.c
index 4e1e331..89d3c49 100644
---
Re: [Mesa-dev] [PATCH 00/23] Megadrivers galore
On 19/06/14 11:54, Jakob Bornecrantz wrote: On Tue, Jun 17, 2014 at 8:38 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Hi all, As a follow up to the static/shared pipe-drivers series here is the final series (if anyone is interested I may take a look at egl + opencl) of refactoring the gallium dri targets into a single library/provider. In a nutshell: - Convert one target per patch. - Merge the drm and sw backends of our dri state-tracker. - Adds __driDriverGetExtensions_$drivername symbol for each driver. - Megadrivers. - *** - Profit. Things works like a charm for nouveau and swrast, and testing on other platforms is greatly appreciated. The complete series can be found in the static-or-shared-pipe-drivers-v2 branch at my github repo. I would like to get this reviewed/pushed over the next month, although that depends on the number of bugs that come up with the previous batch. As always comments, suggestions and flame is welcome. I'm trying to get a better grasp of the resulting set of binaries will look like on a distro, correct me if I'm wrong, by default we will get one gallium_dri.so that is linked against shared dri core and glapi correct. And then hardlinks from say vmwgfx_dri.so to gallium_dri.so? Believe Marek answered these quite nicely. Thanks. Also looking at the patch it looks like stdri can still be build without DRM installed on the system? I remember the Hurd people being quite vocal about this. Before we had two front-ends for stdri - drm and sw. Now I'm merging the two into a single library - no functionality and/or build dependency changes. It gives us at least: - Removed symlinks - OpenBSD people import mesa into CVS which does not handle them :\ - The chance to simplify things a bit (-100 loc), merge the hardware and software dri drivers and slightly minimize the linking time. -Emil Cheers, Jakob. Cheers, Emil Emil Velikov (23): targets/dri-swrast: use drm aware dricommon when building more than swrast st/dri: Allow separate dri-targets st/dri/drm: Add a second libdridrm library targets/dri-nouveau: Convert to static/shared pipe-drivers targets/(r300|r600|radeonsi)/dri: Convert to static/shared pipe-drivers targets/dri-freedreno: Convert to static/shared pipe-drivers targets/dri-i915: Convert to static/shared pipe-drivers targets/dri-ilo: Convert to static/shared pipe-driver targets/dri-vmwgfx: Convert to static/shared pipe-drivers st/dri: Remove the old libdridrm library targets/dri: Add __driDriverGetExtensions_nouveau symbol targets/dri: Add __driDriverGetExtensions_(r300|r600|radeonsi) symbols targets/dri: Add __driDriverGetExtensions_freedreno symbol targets/dri: Add __driDriverGetExtensions_i915 symbol targets/dri: Add __driDriverGetExtensions_i965 symbol targets/dri: Add __driDriverGetExtensions_vmwgfx targets/dri: update scons build to handle __driDriverGetExtensions_vmwgfx targets/dri: cleanup conversion leftovers st/dri/drm: remove __driDriverExtensions and driDriverAPI scons: build and use a single dri_common library targets/dri-swrast: convert to gallium megadrivers :) st/dri: merge dri/drm and dri/sw backends targets/dri-swrast: Convert to static/shared pipe-driver 61 files changed, 536 insertions(+), 1375 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 17/06/14 19:24, Emil Velikov wrote: On 12/06/14 20:56, Emil Velikov wrote: Hi all, These patches add support for building (grouping) the various targets per API, meaning that only one library will be created for e.g. vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink to it. This allows us to have substantial space savings as the API(state-tracker) is available only once. Additionally it adds support for shared pipe-drivers via a _unstable_ interface, which saves us the duplication across X APIs. The former method has been used by the egl-static while the latter by opencl and gbm targets since they were introduced. By default we build with static pipe-drivers. Some numbers + extra info [1] [Static] dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB Total: 10MiB [Shared] Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB Total: 9.8MiB [Current] dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB Total: 20.2MiB The previous series can be found here [2] Changes since then - Convert targets individually. - OMX targets now work, and the final library is now libomx-mesa.so - Dropped the DRI targets for now - A handfull of typos thinkos and bugs fixed. My plan is to have these pushed in ~4 stages, with two stages per week. This way I will be able to crack on with the remaining bits and have all of it tested well before we branch the next release. Gents, In case I was not clear enough - my plan is to push 01-11 (prep work) - this wednesday(tomorrow) For everyone interested, I have disabled the i915-sw target, and omitted patches 3 and 4 before pushing. As neither i915 nor svga needs the link to wrapper winsys and softpipe/llvmpipe. -Emil 12-16 (vdpau, xvmc)- over the weekend 17-23 (omx, cleanup)- mid next week 24-26 (xa, gbm, egl)- next week's weekend Don't be shy to speak up, if you feel that any of the above sounds unreasonable. Feel free to shout at me as soon as you notice any bugs :) -Emil Series is availabe at https://github.com/evelikov/Mesa/tree/static-or-shared-pipe-drivers As always comments and suggestions are greatly appreciated. Cheers, -Emil [1] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059806.html [2] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059628.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/11] Klocwork related set again
Rebased and fixed on comments again, thank you Ian earlier for commenting. For i965: check malloc return value in intel_resolve_map_set() I did set *tail to null and was running tests but I did not see any unexpected crashes. From Piglit quick set there did though raise two cases where stderr has story about assert but otherwise everything worked. I am still looking at these asserts. i965: Avoid null access in intelMakeCurrent() I was a bit iffy if its the same behavior which I replaced. /Juha-Pekka Juha-Pekka Heikkila (11): i965: check malloc return value in intel_resolve_map_set() i965: Avoid null access in intelMakeCurrent() i965: Check calloc return value in gather_statistics_results() i965: Handle miptree creation failure in intel_alloc_texture_storage() i965/fs: Check variable_storage return value in fs_visitor::visit glsl: check _mesa_hash_table_create return value in link_uniform_blocks glsl: Add missing null check in push_back() glsl: Check calloc return value in link_intrastage_shaders() mesa/main: Verify calloc return value in register_surface() mesa/main: In register_surface() verify gl_texture_object was found glx: Added missing null check in GetDrawableAttribute() src/glsl/link_atomics.cpp | 13 +++-- src/glsl/link_uniform_blocks.cpp| 6 ++ src/glsl/linker.cpp | 8 src/glx/glx_pbuffer.c | 11 +++ src/mesa/drivers/dri/i965/brw_context.c | 10 +++--- src/mesa/drivers/dri/i965/brw_fs_visitor.cpp| 6 ++ src/mesa/drivers/dri/i965/brw_performance_monitor.c | 7 ++- src/mesa/drivers/dri/i965/intel_resolve_map.c | 6 ++ src/mesa/drivers/dri/i965/intel_tex.c | 3 +++ src/mesa/main/vdpau.c | 11 +++ 10 files changed, 71 insertions(+), 10 deletions(-) -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/11] glsl: Add missing null check in push_back()
Report memory error on realloc failure and don't leak any memory.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/glsl/link_atomics.cpp | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/glsl/link_atomics.cpp b/src/glsl/link_atomics.cpp
index d92cdb1..fbe4e73 100644
--- a/src/glsl/link_atomics.cpp
+++ b/src/glsl/link_atomics.cpp
@@ -54,9 +54,18 @@ namespace {
void push_back(unsigned id, ir_variable *var)
{
- counters = (active_atomic_counter *)
-realloc(counters, sizeof(active_atomic_counter) * (num_counters +
1));
+ active_atomic_counter *new_counters;
+ new_counters = (active_atomic_counter *)
+realloc(counters, sizeof(active_atomic_counter) *
+(num_counters + 1));
+
+ if (new_counters == NULL) {
+_mesa_error_no_memory(__func__);
+return;
+ }
+
+ counters = new_counters;
counters[num_counters].id = id;
counters[num_counters].var = var;
num_counters++;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/11] i965: Avoid null access in intelMakeCurrent()
separate two null checks connected with to their own if branches.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/drivers/dri/i965/brw_context.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index cfb0be0..fc56fd5 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -931,13 +931,17 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
struct gl_context *ctx = brw-ctx;
struct gl_framebuffer *fb, *readFb;
- if (driDrawPriv == NULL driReadPriv == NULL) {
+ if (driDrawPriv == NULL) {
fb = _mesa_get_incomplete_framebuffer();
- readFb = _mesa_get_incomplete_framebuffer();
} else {
fb = driDrawPriv-driverPrivate;
- readFb = driReadPriv-driverPrivate;
driContextPriv-dri2.draw_stamp = driDrawPriv-dri2.stamp - 1;
+ }
+
+ if (driReadPriv == NULL) {
+ readFb = _mesa_get_incomplete_framebuffer();
+ } else {
+ readFb = driReadPriv-driverPrivate;
driContextPriv-dri2.read_stamp = driReadPriv-dri2.stamp - 1;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/11] i965: Check calloc return value in gather_statistics_results()
Check calloc return value and report on error, also later skip
results handling if there was no memory to store results to.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/drivers/dri/i965/brw_performance_monitor.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
index 3f64eae..aeef5b9 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
@@ -610,6 +610,10 @@ gather_statistics_results(struct brw_context *brw,
ctx-PerfMonitor.Groups[PIPELINE_STATS_COUNTERS].NumCounters;
monitor-pipeline_stats_results = calloc(num_counters, sizeof(uint64_t));
+ if (monitor-pipeline_stats_results == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
drm_intel_bo_map(monitor-pipeline_stats_bo, false);
uint64_t *start = monitor-pipeline_stats_bo-virtual;
@@ -1321,7 +1325,8 @@ brw_get_perf_monitor_result(struct gl_context *ctx,
if (!monitor-pipeline_stats_results)
gather_statistics_results(brw, monitor);
- for (int i = 0; i num_counters; i++) {
+ for (int i = 0; i num_counters
+monitor-pipeline_stats_results != NULL; i++) {
if (BITSET_TEST(m-ActiveCounters[PIPELINE_STATS_COUNTERS], i)) {
data[offset++] = PIPELINE_STATS_COUNTERS;
data[offset++] = i;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/11] glsl: Check calloc return value in link_intrastage_shaders()
Check calloc return value while adding build-in functions.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/glsl/linker.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 247c828..1fc0213 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1593,6 +1593,12 @@ link_intrastage_shaders(void *mem_ctx,
*/
gl_shader **linking_shaders = (gl_shader **)
calloc(num_shaders + 1, sizeof(gl_shader *));
+
+ if (linking_shaders == NULL) {
+ _mesa_error_no_memory(__func__);
+ ctx-Driver.DeleteShader(ctx, linked);
+ return NULL;
+ }
memcpy(linking_shaders, shader_list, num_shaders * sizeof(gl_shader *));
linking_shaders[num_shaders] = _mesa_glsl_get_builtin_function_shader();
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/11] glsl: check _mesa_hash_table_create return value in link_uniform_blocks
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/glsl/link_uniform_blocks.cpp | 6 ++
src/glsl/linker.cpp | 2 ++
2 files changed, 8 insertions(+)
diff --git a/src/glsl/link_uniform_blocks.cpp b/src/glsl/link_uniform_blocks.cpp
index 1a0e643..53a18c93 100644
--- a/src/glsl/link_uniform_blocks.cpp
+++ b/src/glsl/link_uniform_blocks.cpp
@@ -170,6 +170,12 @@ link_uniform_blocks(void *mem_ctx,
struct hash_table *block_hash =
_mesa_hash_table_create(mem_ctx, _mesa_key_string_equal);
+ if (block_hash == NULL) {
+ _mesa_error_no_memory(__func__);
+ linker_error(prog, out of memory\n);
+ return 0;
+ }
+
/* Determine which uniform blocks are active.
*/
link_uniform_block_active_visitor v(mem_ctx, block_hash, prog);
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 0b6a716..247c828 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1479,6 +1479,8 @@ link_intrastage_shaders(void *mem_ctx,
const unsigned num_uniform_blocks =
link_uniform_blocks(mem_ctx, prog, shader_list, num_shaders,
uniform_blocks);
+ if (!prog-LinkStatus)
+ return NULL;
/* Check that there is only a single definition of each function signature
* across all shaders.
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/11] mesa/main: Verify calloc return value in register_surface()
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/main/vdpau.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/main/vdpau.c b/src/mesa/main/vdpau.c
index d974593..f1b3ece 100644
--- a/src/mesa/main/vdpau.c
+++ b/src/mesa/main/vdpau.c
@@ -132,6 +132,11 @@ register_surface(struct gl_context *ctx, GLboolean
isOutput,
}
surf = CALLOC_STRUCT( vdp_surface );
+ if (surf == NULL) {
+ _mesa_error_no_memory(VDPAURegisterSurfaceNV);
+ return (GLintptr)NULL;
+ }
+
surf-vdpSurface = vdpSurface;
surf-target = target;
surf-access = GL_READ_WRITE;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/11] i965/fs: Check variable_storage return value in fs_visitor::visit
check variable_storage() found the requested fs_reg.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 6352739..654f5fe 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -155,6 +155,12 @@ void
fs_visitor::visit(ir_dereference_variable *ir)
{
fs_reg *reg = variable_storage(ir-var);
+
+ if (!reg) {
+ fail(Failed to find variable storage for %s\n, ir-var-name);
+ this-result = fs_reg(reg_null_d);
+ return;
+ }
this-result = *reg;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/11] i965: Handle miptree creation failure in intel_alloc_texture_storage()
Check intel_miptree_create() return value before using it as
a pointer.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/drivers/dri/i965/intel_tex.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_tex.c
b/src/mesa/drivers/dri/i965/intel_tex.c
index f18ca45..556b787 100644
--- a/src/mesa/drivers/dri/i965/intel_tex.c
+++ b/src/mesa/drivers/dri/i965/intel_tex.c
@@ -147,6 +147,9 @@ intel_alloc_texture_storage(struct gl_context *ctx,
num_samples,
INTEL_MIPTREE_TILING_ANY);
+ if (intel_texobj-mt == NULL) {
+ return false;
+ }
}
for (face = 0; face numFaces; face++) {
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/11] glx: Added missing null check in GetDrawableAttribute()
For GLX_BACK_BUFFER_AGE_EXT query added extra null check.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/glx/glx_pbuffer.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 8f48093..322f241 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -319,7 +319,6 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
pdraw = GetGLXDRIDrawable(dpy, drawable);
if (attribute == GLX_BACK_BUFFER_AGE_EXT) {
- struct glx_screen *psc = pdraw-psc;
struct glx_context *gc = __glXGetCurrentContext();
/* The GLX_EXT_buffer_age spec says:
@@ -328,12 +327,16 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
* the calling thread's current context a GLXBadDrawable error is
* generated.
*/
- if (gc == NULL || gc-currentDpy != dpy ||
- (gc-currentDrawable != drawable gc-currentReadable != drawable))
{
- __glXSendError(dpy, GLXBadDrawable, drawable,
X_GLXGetDrawableAttributes, false);
+ if (pdraw == NULL || gc == NULL || gc-currentDpy != dpy ||
+ (gc-currentDrawable != drawable
+ gc-currentReadable != drawable)) {
+ __glXSendError(dpy, GLXBadDrawable, drawable,
+X_GLXGetDrawableAttributes, false);
return 0;
}
+ struct glx_screen *psc = pdraw-psc;
+
if (psc-driScreen-getBufferAge != NULL)
*value = psc-driScreen-getBufferAge(pdraw);
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/11] i965: check malloc return value in intel_resolve_map_set()
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/drivers/dri/i965/intel_resolve_map.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_resolve_map.c
b/src/mesa/drivers/dri/i965/intel_resolve_map.c
index a37afa6..5ed7fd3 100644
--- a/src/mesa/drivers/dri/i965/intel_resolve_map.c
+++ b/src/mesa/drivers/dri/i965/intel_resolve_map.c
@@ -22,6 +22,7 @@
*/
#include intel_resolve_map.h
+#include main/imports.h
#include assert.h
#include stdlib.h
@@ -46,6 +47,11 @@ intel_resolve_map_set(struct exec_list *resolve_map,
}
struct intel_resolve_map *m = malloc(sizeof(struct intel_resolve_map));
+ if (m == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
+
exec_node_init(m-link);
m-level = level;
m-layer = layer;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/11] mesa/main: In register_surface() verify gl_texture_object was found
Verify _mesa_lookup_texture() returned valid pointer before using it.
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/main/vdpau.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/main/vdpau.c b/src/mesa/main/vdpau.c
index f1b3ece..975b812 100644
--- a/src/mesa/main/vdpau.c
+++ b/src/mesa/main/vdpau.c
@@ -145,6 +145,12 @@ register_surface(struct gl_context *ctx, GLboolean
isOutput,
for (i = 0; i numTextureNames; ++i) {
struct gl_texture_object *tex;
tex = _mesa_lookup_texture(ctx, textureNames[i]);
+ if (tex == NULL) {
+ free(surf);
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ VDPAURegisterSurfaceNV(texture ID not found));
+ return (GLintptr)NULL;
+ }
_mesa_lock_texture(ctx, tex);
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] i965: Enable vertex streams up to MAX_VERTEX_STREAMS.
--- I guess this was an implicit reviewed-by with this change, but anyway... :) src/mesa/drivers/dri/i965/brw_context.c | 4 1 file changed, 4 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index cfb0be0..e168b6d 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -507,6 +507,10 @@ brw_initialize_context_constants(struct brw_context *brw) ctx-Const.ViewportBounds.Min = -(float)ctx-Const.MaxViewportWidth; ctx-Const.ViewportBounds.Max = ctx-Const.MaxViewportWidth; } + + /* ARB_gpu_shader5 */ + if (brw-gen = 7) + ctx-Const.MaxVertexStreams = MIN2(4, MAX_VERTEX_STREAMS); } /** -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] glsl: handle a switch where default is in the middle of cases
This fixes following tests in es3conform:
shaders.switch.default_not_last_dynamic_vertex
shaders.switch.default_not_last_dynamic_fragment
and makes following tests in Piglit pass:
glsl-1.30/execution/switch/fs-default-notlast-fallthrough
glsl-1.30/execution/switch/fs-default_notlast
No Piglit regressions.
v2: take away unnecessary ir_if, just use conditional assignment
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/ast_to_hir.cpp | 84 +--
src/glsl/glsl_parser_extras.h | 3 ++
2 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 132a955..2a105c6 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4503,6 +4503,12 @@ ast_switch_statement::hir(exec_list *instructions,
instructions-push_tail(new(ctx) ir_assignment(deref_is_break_var,
is_break_val));
+ state-switch_state.run_default =
+ new(ctx) ir_variable(glsl_type::bool_type,
+ run_default_tmp,
+ ir_var_temporary);
+ instructions-push_tail(state-switch_state.run_default);
+
/* Cache test expression.
*/
test_to_hir(instructions, state);
@@ -4557,8 +4563,72 @@ ir_rvalue *
ast_case_statement_list::hir(exec_list *instructions,
struct _mesa_glsl_parse_state *state)
{
- foreach_list_typed (ast_case_statement, case_stmt, link, this-cases)
- case_stmt-hir(instructions, state);
+ exec_list default_case, after_default, tmp;
+
+ foreach_list_typed (ast_case_statement, case_stmt, link, this-cases) {
+ case_stmt-hir(tmp, state);
+
+ /* Default case. */
+ if (state-switch_state.previous_default default_case.is_empty()) {
+ default_case.append_list(tmp);
+ continue;
+ }
+
+ /* If default case found, append 'after_default' list. */
+ if (!default_case.is_empty())
+ after_default.append_list(tmp);
+ else
+ instructions-append_list(tmp);
+ }
+
+ /* Handle the default case. This is done here because default might not be
+* the last case. We need to add checks against following cases first to see
+* if default should be chosen or not.
+*/
+ if (!default_case.is_empty()) {
+
+ /* Default case was the last one, no checks required. */
+ if (after_default.is_empty()) {
+ instructions-append_list(default_case);
+ return NULL;
+ }
+
+ ir_rvalue *const true_val = new (state) ir_constant(true);
+ ir_dereference_variable *deref_run_default_var =
+ new(state) ir_dereference_variable(state-switch_state.run_default);
+
+ /* Choose to run default case initially, following conditional
+ * assignments might change this.
+ */
+ ir_assignment *const init_var =
+ new(state) ir_assignment(deref_run_default_var, true_val);
+ instructions-push_tail(init_var);
+
+ foreach_list(n, after_default) {
+ ir_instruction *ir = (ir_instruction *) n;
+ ir_assignment *assign = ir-as_assignment();
+
+ if (!assign)
+continue;
+
+ /* Clone the check between case label and init expression. */
+ ir_expression *exp = (ir_expression*) assign-condition;
+ ir_expression *clone = exp-clone(state, NULL);
+
+ ir_dereference_variable *deref_var =
+new(state)
ir_dereference_variable(state-switch_state.run_default);
+ ir_rvalue *const false_val = new (state) ir_constant(false);
+
+ ir_assignment *const set_false =
+new(state) ir_assignment(deref_var, false_val, clone);
+
+ instructions-push_tail(set_false);
+ }
+
+ /* Append default case and all cases after it. */
+ instructions-append_list(default_case);
+ instructions-append_list(after_default);
+ }
/* Case statements do not have r-values. */
return NULL;
@@ -4718,9 +4788,17 @@ ast_case_label::hir(exec_list *instructions,
}
state-switch_state.previous_default = this;
+ /* Set fallthru condition on 'run_default' bool. */
+ ir_dereference_variable *deref_run_default =
+ new(ctx) ir_dereference_variable(state-switch_state.run_default);
+ ir_rvalue *const cond_true = new(ctx) ir_constant(true);
+ ir_expression *test_cond = new(ctx) ir_expression(ir_binop_all_equal,
+cond_true,
+deref_run_default);
+
/* Set falltrhu state. */
ir_assignment *set_fallthru =
- new(ctx) ir_assignment(deref_fallthru_var, true_val);
+ new(ctx) ir_assignment(deref_fallthru_var, true_val, test_cond);
instructions-push_tail(set_fallthru);
}
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index a59090f..de23d33 100644
---
Re: [Mesa-dev] [PATCH] radeon/llvm: Adapt to AMDGPU.rsq intrinsic change in LLVM 3.5
On Thu, Jun 19, 2014 at 03:53:42PM +0900, Michel Dänzer wrote: From: Michel Dänzer michel.daen...@amd.com I just pushed this patch to fix the regressions. We can update the other intrinsics in a follow on patch. We also need to change RSQ to use llvm.AMDGPU.rsq.clamped once http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140616/80.html is committed in order to fix https://bugs.freedesktop.org/show_bug.cgi?id=80015 Also, I forgot to do this before I committed it, but I think this patch should go to stable. -Tom Signed-off-by: Michel Dänzer michel.daen...@amd.com --- src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c index f8be0df..217fa32 100644 --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c @@ -1384,7 +1384,11 @@ void radeon_llvm_context_init(struct radeon_llvm_context * ctx) bld_base-op_actions[TGSI_OPCODE_UCMP].emit = emit_ucmp; bld_base-rsq_action.emit = build_tgsi_intrinsic_nomem; +#if HAVE_LLVM = 0x0305 + bld_base-rsq_action.intr_name = llvm.AMDGPU.rsq.; +#else bld_base-rsq_action.intr_name = llvm.AMDGPU.rsq; +#endif } void radeon_llvm_create_func(struct radeon_llvm_context * ctx, -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On 15/06/14 12:49, Giovanni Campagna wrote: Hello all, This is the third attempt at swrast/llvmpipe support for DRM drivers that don't have userspace support (qxl, cirrus, simpledrm, etc.) I hope I addressed all of Emil's comments. Thanks for keeping up with my nit-picking Giovanni. Pretty much everything looks great imho, just one silly question that slippe through the cracks: Why do you insist on using LIBGL env var when you're dealing with EGL/GBM ? IMHO the name is quite explanatory (meant/used by libGL), it may cause us some headaches if we try to go with one variable that rules them all approach. With that said, I would prefer (unless someone objects) if we push these after my long series of reshuffling the gallium targets has done in. I would gladly rebase this 3 patches over the 20+ one that I have. Thanks again. Emil Giovanni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 3/3] Add a new capabilities for drivers that can't share buffers
On 15/06/2014 07:49, Giovanni Campagna wrote : From: Giovanni Campagna gcampa...@src.gnome.org The kms-dri swrast driver cannot share buffers using the GEM, so it must tell the loader to disable extensions relying on that, without disabling the image DRI extension altogheter (which would prevent the loader from working at all). This requires a new gallium capability (which is queried on the pipe_screen and for swrast drivers it's forwared to the winsys), and requires a new version of the DRI image extension. Why does this require a new version of the DRI image extension ? Could you just set createImageFromName and CreateImageFromNames to NULL, and add checks for that (instead of checking the capability ? It's what is done to check if we can import dma-bufs (check if createImageFromFds is not NULL). Axel Davy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] GLX: Add an env var to enable the support of GLX extensions needing both client and server support, in case of client support and direct rendering.
On 19/06/2014 01:55, Kenneth Graunke wrote : That would make the common case that most people want (GLX_ARB_create_context for direct rendered 3.2+ core profile stuff) work out of the box, without the need for environment variables. It's technically out of spec, but for X on Wayland, I think it's not unreasonable. On the other hand, supporting AIGLX of sorts might be possible... With XWayland, there are really a couple layers to indirect rendering... 1. Doing it X client side (direct rendering) 2. Doing it in the XWayland X11 server/Wayland client (semi-indirect). 3. Doing it wherever Weston/etc are running (total indirect). It seems like XWayland could support AIGLX with model #2 - X clients would speak GLX protocol to XWayland, which could then do the GL. Model #3 seems like something we should avoid at all costs. Of course, I don't know that there's any *benefit* to supporting AIGLX in XWayland, so...my real suggestion is to just raise a GLX error or lie if asked to create an indirect context. --Ken It is possible to support indirect rendering for XWayland, for that the Xserver should be updated to be able to use DRIImage and DRI3 specific things for indirect rendering (instead of DRI2). This patch is just a workaround because it's not done yet. Axel Davy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/11] GLX/DRI3: Add GPU offloading support.
I've just noted
I forgot to update the blitImage flags on this patch,
when I use 1 as flush_flag argument it should be replaced by
__BLIT_FLAG_FLUSH.
Axel Davy
On 18/06/2014 23:27, Axel Davy wrote :
The differences with DRI2 GPU offloading are:
. There's no logic for GPU offloading needed in the Xserver
. for DRI2, the card would render to a back buffer, and
the content would be copied to the front buffer (the same buffers
everytime). Here we can potentially use several back buffers and copy
to buffers with no tiling to share with X. We send them with the
Present extension.
That means than the DRI2 solution is forced to have tearings with GPU
offloading. In the ideal scenario, this DRI3 solution doesn't have this
problem.
However without dma-buf fences, a race can appear (if the card is slow
and the rendering hasn't finished before the server card reads the buffer),
and then old content is displayed. If a user hits this, he should probably
revert to the DRI2 solution (LIBGL_DRI3_DISABLE). Users with cards fast
enough seem to not hit this in practice (I have an Amd hd 7730m, and I
don't hit this, except if I force a low dpm mode)
. for non-fullscreen apps, the DRI2 GPU offloading solution requires
compositing. This DRI3 solution doesn't have this requirement. Rendering
to a pixmap also works.
. There is no need to have a DDX loaded for the secondary card.
V4: Fixes some piglit tests
Signed-off-by: Axel Davy axel.d...@ens.fr
---
src/glx/dri3_glx.c | 236 +++-
src/glx/dri3_priv.h | 2 +
2 files changed, 198 insertions(+), 40 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index b309cd4..f147112 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -596,22 +596,44 @@ dri3_copy_sub_buffer(__GLXDRIdrawable *pdraw, int x, int
y,
{
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
struct dri3_screen *psc = (struct dri3_screen *) pdraw-psc;
+ struct dri3_context *pcp = (struct dri3_context *) __glXGetCurrentContext();
xcb_connection_t *c = XGetXCBConnection(priv-base.psc-dpy);
- struct dri3_buffer *back = dri3_back_buffer(priv);
+ struct dri3_buffer *back;
- unsigned flags;
+ unsigned flags = __DRI2_FLUSH_DRAWABLE;
/* Check we have the right attachments */
if (!priv-have_back || priv-is_pixmap)
return;
- flags = __DRI2_FLUSH_DRAWABLE;
if (flush)
flags |= __DRI2_FLUSH_CONTEXT;
dri3_flush(psc, priv, flags, __DRI2_THROTTLE_SWAPBUFFER);
+ back = dri3_back_buffer(priv);
y = priv-height - y - height;
+ if (psc-is_different_gpu (pcp-base != dummyContext) pcp-base.psc == psc-base) {
+ /* Update the linear buffer part of the back buffer
+ * for the dri3_copy_area operation
+ */
+ psc-image-blitImage(pcp-driContext,
+back-linear_buffer,
+back-image,
+0, 0, back-width,
+back-height,
+0, 0, back-width,
+back-height, 1);
+ /* We use blitImage to update our fake front,
+ */
+ if (priv-have_fake_front)
+ psc-image-blitImage(pcp-driContext,
+ dri3_fake_front_buffer(priv)-image,
+ back-image,
+ x, y, width, height,
+ x, y, width, height, 1);
+ }
+
dri3_fence_reset(c, back);
dri3_copy_area(c,
dri3_back_buffer(priv)-pixmap,
@@ -622,7 +644,7 @@ dri3_copy_sub_buffer(__GLXDRIdrawable *pdraw, int x, int y,
/* Refresh the fake front (if present) after we just damaged the real
* front.
*/
- if (priv-have_fake_front) {
+ if (priv-have_fake_front !psc-is_different_gpu) {
dri3_fence_reset(c, dri3_fake_front_buffer(priv));
dri3_copy_area(c,
dri3_back_buffer(priv)-pixmap,
@@ -655,25 +677,62 @@ dri3_copy_drawable(struct dri3_drawable *priv, Drawable
dest, Drawable src)
static void
dri3_wait_x(struct glx_context *gc)
{
+ struct dri3_context *pcp = (struct dri3_context *) gc;
struct dri3_drawable *priv = (struct dri3_drawable *)
GetGLXDRIDrawable(gc-currentDpy, gc-currentDrawable);
+ struct dri3_screen *psc;
+ struct dri3_buffer *front;
if (priv == NULL || !priv-have_fake_front)
return;
- dri3_copy_drawable(priv, dri3_fake_front_buffer(priv)-pixmap, priv-base.xDrawable);
+ psc = (struct dri3_screen *) priv-base.psc;
+ front = dri3_fake_front_buffer(priv);
+
+ dri3_copy_drawable(priv, front-pixmap, priv-base.xDrawable);
+
+ /* In the psc-is_different_gpu case, the linear buffer has been updated,
+* but not yet the tiled buffer.
+* Copy back to the tiled buffer we use for rendering.
+* Note that we don't need flushing.
+*/
+ if (psc-is_different_gpu (pcp-base
[Mesa-dev] Request for next steps on GL_shader_atomic_counters
Hi, I have started writing code for GL_shader_atomic_counters[1]. How do I proceed to the next steps? Thank you! [1] https://github.com/adityaatluri/shader_atomic_counters/blob/master/atomic_counters.h -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77493] lp_test_arit fails with llvm = llvm-3.5svn r206094
https://bugs.freedesktop.org/show_bug.cgi?id=77493 Roland Scheidegger srol...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Roland Scheidegger srol...@vmware.com --- Fixed by cad60420d5ea36a4b6fa2e6c91317f71423aa63e. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600: Handle failures in compute_memory_pool_finalize
Hi,
To which failure are you refering? Could you please send me a
test/program that I can try to track this down?
Thanks!
Bruno
On Thu, 2014-06-19 at 10:21 -0400, Jan Vesely wrote:
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
The failure now hits assertion compute_memory_pool.c:408, instead of
u_inlines.h:275:pipe_buffer_map_range: Assertion `offset buffer-width0'
src/gallium/drivers/r600/evergreen_compute.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index a2abf15..bd6e720 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -659,7 +659,10 @@ static void evergreen_set_global_binding(
return;
}
- compute_memory_finalize_pending(pool, ctx_);
+ if (compute_memory_finalize_pending(pool, ctx_) == -1) {
+ /* XXX: Unset */
+ return;
+ }
for (int i = 0; i n; i++)
{
@@ -967,7 +970,9 @@ void *r600_compute_global_transfer_map(
%u (box.x)\n, buffer-chunk-id, box-x);
- compute_memory_finalize_pending(pool, ctx_);
+ if (compute_memory_finalize_pending(pool, ctx_) == -1) {
+ return NULL;
+ }
assert(resource-target == PIPE_BUFFER);
assert(resource-bind PIPE_BIND_GLOBAL);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] glsl: handle a switch where default is in the middle of cases
Am 19.06.2014 15:11, schrieb Tapani Pälli:
This fixes following tests in es3conform:
shaders.switch.default_not_last_dynamic_vertex
shaders.switch.default_not_last_dynamic_fragment
and makes following tests in Piglit pass:
glsl-1.30/execution/switch/fs-default-notlast-fallthrough
glsl-1.30/execution/switch/fs-default_notlast
No Piglit regressions.
v2: take away unnecessary ir_if, just use conditional assignment
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/ast_to_hir.cpp | 84
+--
src/glsl/glsl_parser_extras.h | 3 ++
2 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 132a955..2a105c6 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4503,6 +4503,12 @@ ast_switch_statement::hir(exec_list *instructions,
instructions-push_tail(new(ctx) ir_assignment(deref_is_break_var,
is_break_val));
+ state-switch_state.run_default =
+ new(ctx) ir_variable(glsl_type::bool_type,
+ run_default_tmp,
+ ir_var_temporary);
+ instructions-push_tail(state-switch_state.run_default);
+
/* Cache test expression.
*/
test_to_hir(instructions, state);
@@ -4557,8 +4563,72 @@ ir_rvalue *
ast_case_statement_list::hir(exec_list *instructions,
struct _mesa_glsl_parse_state *state)
{
- foreach_list_typed (ast_case_statement, case_stmt, link, this-cases)
- case_stmt-hir(instructions, state);
+ exec_list default_case, after_default, tmp;
+
+ foreach_list_typed (ast_case_statement, case_stmt, link, this-cases) {
+ case_stmt-hir(tmp, state);
+
+ /* Default case. */
+ if (state-switch_state.previous_default default_case.is_empty()) {
+ default_case.append_list(tmp);
+ continue;
+ }
+
+ /* If default case found, append 'after_default' list. */
+ if (!default_case.is_empty())
+ after_default.append_list(tmp);
+ else
+ instructions-append_list(tmp);
+ }
+
+ /* Handle the default case. This is done here because default might not be
+* the last case. We need to add checks against following cases first to
see
+* if default should be chosen or not.
+*/
+ if (!default_case.is_empty()) {
+
+ /* Default case was the last one, no checks required. */
+ if (after_default.is_empty()) {
+ instructions-append_list(default_case);
+ return NULL;
+ }
+
+ ir_rvalue *const true_val = new (state) ir_constant(true);
+ ir_dereference_variable *deref_run_default_var =
+ new(state) ir_dereference_variable(state-switch_state.run_default);
+
+ /* Choose to run default case initially, following conditional
+ * assignments might change this.
+ */
+ ir_assignment *const init_var =
+ new(state) ir_assignment(deref_run_default_var, true_val);
+ instructions-push_tail(init_var);
+
+ foreach_list(n, after_default) {
+ ir_instruction *ir = (ir_instruction *) n;
+ ir_assignment *assign = ir-as_assignment();
+
+ if (!assign)
+continue;
+
+ /* Clone the check between case label and init expression. */
+ ir_expression *exp = (ir_expression*) assign-condition;
+ ir_expression *clone = exp-clone(state, NULL);
+
+ ir_dereference_variable *deref_var =
+new(state)
ir_dereference_variable(state-switch_state.run_default);
+ ir_rvalue *const false_val = new (state) ir_constant(false);
+
+ ir_assignment *const set_false =
+new(state) ir_assignment(deref_var, false_val, clone);
+
+ instructions-push_tail(set_false);
+ }
+
+ /* Append default case and all cases after it. */
+ instructions-append_list(default_case);
+ instructions-append_list(after_default);
+ }
/* Case statements do not have r-values. */
return NULL;
@@ -4718,9 +4788,17 @@ ast_case_label::hir(exec_list *instructions,
}
state-switch_state.previous_default = this;
+ /* Set fallthru condition on 'run_default' bool. */
+ ir_dereference_variable *deref_run_default =
+ new(ctx) ir_dereference_variable(state-switch_state.run_default);
+ ir_rvalue *const cond_true = new(ctx) ir_constant(true);
+ ir_expression *test_cond = new(ctx) ir_expression(ir_binop_all_equal,
+cond_true,
+deref_run_default);
+
/* Set falltrhu state. */
ir_assignment *set_fallthru =
- new(ctx) ir_assignment(deref_fallthru_var, true_val);
+ new(ctx) ir_assignment(deref_fallthru_var,
[Mesa-dev] [PATCH 1/2] r600: Fix possible endless loop in compute_memory_pool allocations.
The important part is the change of the condition to = 0. Otherwise the loop
gets stuck never actually growing the pool.
The change in the aux-need calculation guarantees max 2 iterations, and
avoids wasting memory in case a smaller item can't fit into a relatively larger
pool.
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
This fixes hang in gegl colors.xml test
src/gallium/drivers/r600/compute_memory_pool.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index ec8c470..0b6d2da6 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -320,8 +320,11 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
int64_t need = item-size_in_dw+2048 -
(pool-size_in_dw - allocated);
- if (need 0) {
- need = pool-size_in_dw / 10;
+ if (need = 0) {
+ /* There's enough free space, but it's too
+* fragmented. Assume half of the item can fit
+* int the last chunk */
+ need = (item-size_in_dw / 2) + ITEM_ALIGNMENT;
}
need = align(need, ITEM_ALIGNMENT);
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] r600: Handle failures in compute_memory_pool_finalize
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
The failure now hits assertion compute_memory_pool.c:408, instead of
u_inlines.h:275:pipe_buffer_map_range: Assertion `offset buffer-width0'
src/gallium/drivers/r600/evergreen_compute.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index a2abf15..bd6e720 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -659,7 +659,10 @@ static void evergreen_set_global_binding(
return;
}
- compute_memory_finalize_pending(pool, ctx_);
+ if (compute_memory_finalize_pending(pool, ctx_) == -1) {
+ /* XXX: Unset */
+ return;
+ }
for (int i = 0; i n; i++)
{
@@ -967,7 +970,9 @@ void *r600_compute_global_transfer_map(
%u (box.x)\n, buffer-chunk-id, box-x);
- compute_memory_finalize_pending(pool, ctx_);
+ if (compute_memory_finalize_pending(pool, ctx_) == -1) {
+ return NULL;
+ }
assert(resource-target == PIPE_BUFFER);
assert(resource-bind PIPE_BIND_GLOBAL);
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600: Handle failures in compute_memory_pool_finalize
On Thu, 2014-06-19 at 17:12 +0200, Bruno Jimenez wrote:
Hi,
To which failure are you refering? Could you please send me a
test/program that I can try to track this down?
well, the compute_memory_finalize_pending() function can possibly return
-1 so it's prudent to check for it.
as for the testcase, I replaced the inside of 'if (need = 0)' in the
previous patch with return -1 (to simulate failure). The I used GEGL
test op colors.xml to trigger the situation.
but gegl needs some extra patches to get working on current mesa/clover.
I can send you log with R600_DEBUG=compute if it helps.
regards,
Jan
Thanks!
Bruno
On Thu, 2014-06-19 at 10:21 -0400, Jan Vesely wrote:
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
The failure now hits assertion compute_memory_pool.c:408, instead of
u_inlines.h:275:pipe_buffer_map_range: Assertion `offset buffer-width0'
src/gallium/drivers/r600/evergreen_compute.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index a2abf15..bd6e720 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -659,7 +659,10 @@ static void evergreen_set_global_binding(
return;
}
- compute_memory_finalize_pending(pool, ctx_);
+ if (compute_memory_finalize_pending(pool, ctx_) == -1) {
+ /* XXX: Unset */
+ return;
+ }
for (int i = 0; i n; i++)
{
@@ -967,7 +970,9 @@ void *r600_compute_global_transfer_map(
%u (box.x)\n, buffer-chunk-id, box-x);
- compute_memory_finalize_pending(pool, ctx_);
+ if (compute_memory_finalize_pending(pool, ctx_) == -1) {
+ return NULL;
+ }
assert(resource-target == PIPE_BUFFER);
assert(resource-bind PIPE_BIND_GLOBAL);
--
Jan Vesely jan.ves...@rutgers.edu
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r600: Fix possible endless loop in compute_memory_pool allocations.
On Thu, Jun 19, 2014 at 10:21:32AM -0400, Jan Vesely wrote:
The important part is the change of the condition to = 0. Otherwise the loop
gets stuck never actually growing the pool.
The change in the aux-need calculation guarantees max 2 iterations, and
avoids wasting memory in case a smaller item can't fit into a relatively
larger
pool.
Does this patch obsolete the XXX comment around line 292 of this file? If so,
we should remove it.
Also have tried this with patches 1-9 of this series:
http://lists.freedesktop.org/archives/mesa-dev/2014-June/061742.html
-Tom
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
This fixes hang in gegl colors.xml test
src/gallium/drivers/r600/compute_memory_pool.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index ec8c470..0b6d2da6 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -320,8 +320,11 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
int64_t need = item-size_in_dw+2048 -
(pool-size_in_dw - allocated);
- if (need 0) {
- need = pool-size_in_dw / 10;
+ if (need = 0) {
+ /* There's enough free space, but it's too
+ * fragmented. Assume half of the item can fit
+ * int the last chunk */
+ need = (item-size_in_dw / 2) + ITEM_ALIGNMENT;
}
need = align(need, ITEM_ALIGNMENT);
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r600: Fix possible endless loop in compute_memory_pool allocations.
Hi,
Thanks for catching this bug!
Reviewed-by: Bruno Jiménez brunoji...@gmail.com
Also, could you please send me a copy of the tests?
On Thu, 2014-06-19 at 10:21 -0400, Jan Vesely wrote:
The important part is the change of the condition to = 0. Otherwise the loop
gets stuck never actually growing the pool.
The change in the aux-need calculation guarantees max 2 iterations, and
avoids wasting memory in case a smaller item can't fit into a relatively
larger
pool.
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
This fixes hang in gegl colors.xml test
src/gallium/drivers/r600/compute_memory_pool.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index ec8c470..0b6d2da6 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -320,8 +320,11 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
int64_t need = item-size_in_dw+2048 -
(pool-size_in_dw - allocated);
- if (need 0) {
- need = pool-size_in_dw / 10;
+ if (need = 0) {
+ /* There's enough free space, but it's too
+ * fragmented. Assume half of the item can fit
+ * int the last chunk */
+ need = (item-size_in_dw / 2) + ITEM_ALIGNMENT;
}
need = align(need, ITEM_ALIGNMENT);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600: Handle failures in compute_memory_pool_finalize
On Thu, Jun 19, 2014 at 11:22:28AM -0400, Jan Vesely wrote:
On Thu, 2014-06-19 at 17:12 +0200, Bruno Jimenez wrote:
Hi,
To which failure are you refering? Could you please send me a
test/program that I can try to track this down?
well, the compute_memory_finalize_pending() function can possibly return
-1 so it's prudent to check for it.
as for the testcase, I replaced the inside of 'if (need = 0)' in the
previous patch with return -1 (to simulate failure). The I used GEGL
test op colors.xml to trigger the situation.
but gegl needs some extra patches to get working on current mesa/clover.
I can send you log with R600_DEBUG=compute if it helps.
Have you ever looked into integrated the gegl tests with piglit, like we've
done for opencv. This would make it much easier for other devs to execute
these tests.
-Tom
regards,
Jan
Thanks!
Bruno
On Thu, 2014-06-19 at 10:21 -0400, Jan Vesely wrote:
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
The failure now hits assertion compute_memory_pool.c:408, instead of
u_inlines.h:275:pipe_buffer_map_range: Assertion `offset buffer-width0'
src/gallium/drivers/r600/evergreen_compute.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index a2abf15..bd6e720 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -659,7 +659,10 @@ static void evergreen_set_global_binding(
return;
}
- compute_memory_finalize_pending(pool, ctx_);
+ if (compute_memory_finalize_pending(pool, ctx_) == -1) {
+ /* XXX: Unset */
+ return;
+ }
for (int i = 0; i n; i++)
{
@@ -967,7 +970,9 @@ void *r600_compute_global_transfer_map(
%u (box.x)\n, buffer-chunk-id, box-x);
- compute_memory_finalize_pending(pool, ctx_);
+ if (compute_memory_finalize_pending(pool, ctx_) == -1) {
+ return NULL;
+ }
assert(resource-target == PIPE_BUFFER);
assert(resource-bind PIPE_BIND_GLOBAL);
--
Jan Vesely jan.ves...@rutgers.edu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r600: Fix possible endless loop in compute_memory_pool allocations.
On Thu, 2014-06-19 at 17:27 +0200, Bruno Jimenez wrote:
Hi,
Thanks for catching this bug!
Reviewed-by: Bruno Jiménez brunoji...@gmail.com
Also, could you please send me a copy of the tests?
This got triggered by one of the gegl test. You'll need the attached
patches to run gegl git[0] on mesa/clover/r600. you 'll need babl git[1]
too. Let me know if I can help with setting it up.
Sry, I don't have any smaller reproducer.
Jan
[0] git://git.gnome.org/gegl
[1] git://git.gnome.org/babl
On Thu, 2014-06-19 at 10:21 -0400, Jan Vesely wrote:
The important part is the change of the condition to = 0. Otherwise the
loop
gets stuck never actually growing the pool.
The change in the aux-need calculation guarantees max 2 iterations, and
avoids wasting memory in case a smaller item can't fit into a relatively
larger
pool.
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
This fixes hang in gegl colors.xml test
src/gallium/drivers/r600/compute_memory_pool.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index ec8c470..0b6d2da6 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -320,8 +320,11 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
int64_t need = item-size_in_dw+2048 -
(pool-size_in_dw - allocated);
- if (need 0) {
- need = pool-size_in_dw / 10;
+ if (need = 0) {
+ /* There's enough free space, but it's too
+* fragmented. Assume half of the item can fit
+* int the last chunk */
+ need = (item-size_in_dw / 2) + ITEM_ALIGNMENT;
}
need = align(need, ITEM_ALIGNMENT);
--
Jan Vesely jan.ves...@rutgers.edu
From 762d9251f336e7c0c1db7b1af9c01880477ac6ef Mon Sep 17 00:00:00 2001
From: Jan Vesely jan.ves...@rutgers.edu
Date: Wed, 13 Nov 2013 11:34:32 -0500
Subject: [PATCH 1/3] opencl: Don't load some unused extensions.
These are not available on mesa.
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
---
gegl/opencl/gegl-cl-init.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gegl/opencl/gegl-cl-init.c b/gegl/opencl/gegl-cl-init.c
index 8ae1ef1..5024421 100644
--- a/gegl/opencl/gegl-cl-init.c
+++ b/gegl/opencl/gegl-cl-init.c
@@ -501,9 +501,9 @@ gegl_cl_init_load_functions (GError **error)
CL_LOAD_FUNCTION (clReleaseContext)
CL_LOAD_FUNCTION (clReleaseMemObject)
- CL_LOAD_FUNCTION (clCreateFromGLTexture2D)
- CL_LOAD_FUNCTION (clEnqueueAcquireGLObjects)
- CL_LOAD_FUNCTION (clEnqueueReleaseGLObjects)
+// CL_LOAD_FUNCTION (clCreateFromGLTexture2D)
+// CL_LOAD_FUNCTION (clEnqueueAcquireGLObjects)
+// CL_LOAD_FUNCTION (clEnqueueReleaseGLObjects)
return TRUE;
}
--
1.9.3
From 821c1bbc2bccce3b6706769546fa0d5ddc7d83d6 Mon Sep 17 00:00:00 2001
From: Jan Vesely jan.ves...@rutgers.edu
Date: Wed, 18 Dec 2013 18:19:16 -0500
Subject: [PATCH 2/3] Don't use color_kernels, they are broken on mesa
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
---
gegl/opencl/gegl-cl-color.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/gegl/opencl/gegl-cl-color.c b/gegl/opencl/gegl-cl-color.c
index fbcd8ab..ac693f6 100644
--- a/gegl/opencl/gegl-cl-color.c
+++ b/gegl/opencl/gegl-cl-color.c
@@ -232,8 +232,11 @@ gegl_cl_color_supported (const Babl *in_format,
if (in_format == out_format)
return GEGL_CL_COLOR_EQUAL;
- if (color_kernels_hash find_color_kernel (in_format, out_format))
-return GEGL_CL_COLOR_CONVERT;
+ if (color_kernels_hash find_color_kernel (in_format, out_format)) {
+//GEGL_NOTE (GEGL_DEBUG_OPENCL, Found OpenCL conversion from: %s - %s,
+// babl_get_name(in_format), babl_get_name(out_format));
+//return GEGL_CL_COLOR_CONVERT;
+ }
GEGL_NOTE (GEGL_DEBUG_OPENCL, Missing OpenCL conversion for %s - %s,
babl_get_name (in_format),
--
1.9.3
From dc909e2ba904aaa7bde34a49e59a36f93f1ac31b Mon Sep 17 00:00:00 2001
From: Jan Vesely jan.ves...@rutgers.edu
Date: Fri, 16 May 2014 19:39:06 -0400
Subject: [PATCH 3/3] cl: Make noise-simplex kernel OpenCL 1.1 complaint
Fixes one error and 7 warnings
no static keyword, f suffix for float constants
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
---
opencl/noise-simplex.cl | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/opencl/noise-simplex.cl b/opencl/noise-simplex.cl
index bb59758..ce8aa40 100644
--- a/opencl/noise-simplex.cl
+++ b/opencl/noise-simplex.cl
@@ -1,6 +1,6 @@
#define MAX_RANK 3
-static float2
Re: [Mesa-dev] [PATCH 1/2] r600: Fix possible endless loop in compute_memory_pool allocations.
On Thu, 2014-06-19 at 08:27 -0700, Tom Stellard wrote:
On Thu, Jun 19, 2014 at 10:21:32AM -0400, Jan Vesely wrote:
The important part is the change of the condition to = 0. Otherwise the
loop
gets stuck never actually growing the pool.
The change in the aux-need calculation guarantees max 2 iterations, and
avoids wasting memory in case a smaller item can't fit into a relatively
larger
pool.
Does this patch obsolete the XXX comment around line 292 of this file? If so,
we should remove it.
I'm not sure if the XXX comment applies to the first:
if (pool-size_in_dw allocated+unallocated)
or in general.
In general I think the comment is obsolete as is. There already is a
logic that tries to grow the pool if allocation fails despite enough
free space. The patch only changes the the condition to include free
space==needed space corner case.
The change in requested size is separate and does not change the
situation.
Also have tried this with patches 1-9 of this series:
http://lists.freedesktop.org/archives/mesa-dev/2014-June/061742.html
I have not tried applying the patches, but patch 5/11 moves the very
same logic ( if (need 0)), to a slightly different location. So I think
that patch needs to be updated to include the fix.
That series also removes one call to compute_memory_pool_finalize, so
adding a check there now might be redundant. However, I'd still prefer
to check return value of both calls to compute_memory_pool_finalize for
consistency.
regards,
Jan
-Tom
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
This fixes hang in gegl colors.xml test
src/gallium/drivers/r600/compute_memory_pool.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index ec8c470..0b6d2da6 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -320,8 +320,11 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
int64_t need = item-size_in_dw+2048 -
(pool-size_in_dw - allocated);
- if (need 0) {
- need = pool-size_in_dw / 10;
+ if (need = 0) {
+ /* There's enough free space, but it's too
+* fragmented. Assume half of the item can fit
+* int the last chunk */
+ need = (item-size_in_dw / 2) + ITEM_ALIGNMENT;
}
need = align(need, ITEM_ALIGNMENT);
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Jan Vesely jan.ves...@rutgers.edu
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request for next steps on GL_shader_atomic_counters
On Thu, Jun 19, 2014 at 7:30 AM, Aditya Avinash adityaavina...@gmail.com wrote: Hi, I have started writing code for GL_shader_atomic_counters[1]. How do I proceed to the next steps? Mesa already supports GL_ARB_shader_atomic_counters... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600: Handle failures in compute_memory_pool_finalize
On Thu, 2014-06-19 at 08:34 -0700, Tom Stellard wrote:
On Thu, Jun 19, 2014 at 11:22:28AM -0400, Jan Vesely wrote:
On Thu, 2014-06-19 at 17:12 +0200, Bruno Jimenez wrote:
Hi,
To which failure are you refering? Could you please send me a
test/program that I can try to track this down?
well, the compute_memory_finalize_pending() function can possibly return
-1 so it's prudent to check for it.
as for the testcase, I replaced the inside of 'if (need = 0)' in the
previous patch with return -1 (to simulate failure). The I used GEGL
test op colors.xml to trigger the situation.
but gegl needs some extra patches to get working on current mesa/clover.
I can send you log with R600_DEBUG=compute if it helps.
Have you ever looked into integrated the gegl tests with piglit, like we've
done for opencv. This would make it much easier for other devs to execute
these tests.
I planned to have a look after upstream gegl can run unmodified on
clover (at least some of the tests). But given that it might take some
time to reach that point, I'll try to look into it sooner.
regards,
Jan
-Tom
regards,
Jan
Thanks!
Bruno
On Thu, 2014-06-19 at 10:21 -0400, Jan Vesely wrote:
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
The failure now hits assertion compute_memory_pool.c:408, instead of
u_inlines.h:275:pipe_buffer_map_range: Assertion `offset
buffer-width0'
src/gallium/drivers/r600/evergreen_compute.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index a2abf15..bd6e720 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -659,7 +659,10 @@ static void evergreen_set_global_binding(
return;
}
- compute_memory_finalize_pending(pool, ctx_);
+ if (compute_memory_finalize_pending(pool, ctx_) == -1) {
+ /* XXX: Unset */
+ return;
+ }
for (int i = 0; i n; i++)
{
@@ -967,7 +970,9 @@ void *r600_compute_global_transfer_map(
%u (box.x)\n, buffer-chunk-id, box-x);
- compute_memory_finalize_pending(pool, ctx_);
+ if (compute_memory_finalize_pending(pool, ctx_) == -1) {
+ return NULL;
+ }
assert(resource-target == PIPE_BUFFER);
assert(resource-bind PIPE_BIND_GLOBAL);
--
Jan Vesely jan.ves...@rutgers.edu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Jan Vesely jan.ves...@rutgers.edu
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80243] New: Mesa and libclc build failure after llvm = llvm-3.5svn r211259
https://bugs.freedesktop.org/show_bug.cgi?id=80243
Priority: medium
Bug ID: 80243
Assignee: mesa-dev@lists.freedesktop.org
Summary: Mesa and libclc build failure after llvm =
llvm-3.5svn r211259
Severity: normal
Classification: Unclassified
OS: All
Reporter: pontost...@gmail.com
Hardware: Other
Status: NEW
Version: unspecified
Component: Other
Product: Mesa
r211259 - Remove OwningPtr.h and associated tests
This patches fix build.
diff --git a/utils/prepare-builtins.cpp b/utils/prepare-builtins.cpp
index c7f013f..6fdca83 100644
--- a/utils/prepare-builtins.cpp
+++ b/utils/prepare-builtins.cpp
@@ -1,4 +1,3 @@
-#include llvm/ADT/OwningPtr.h
#include llvm/Bitcode/ReaderWriter.h
#include llvm/IR/Function.h
#include llvm/IR/GlobalVariable.h
@@ -13,6 +12,7 @@
#include llvm/Support/ToolOutputFile.h
#include llvm/Config/config.h
+
using namespace llvm;
#define LLVM_350_AND_NEWER \
@@ -87,7 +87,7 @@ int main(int argc, char **argv) {
}
std::string ErrorInfo;
- OwningPtrtool_output_file Out
+ std::unique_ptrtool_output_file Out
(new tool_output_file(OutputFilename.c_str(), ErrorInfo,
#if (LLVM_VERSION_MAJOR == 3 LLVM_VERSION_MINOR == 4)
sys::fs::F_Binary));
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
index df26883..71a2f31 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
@@ -51,9 +51,6 @@
#include llvm/MC/MCInstPrinter.h
#include llvm/MC/MCRegisterInfo.h
-#if HAVE_LLVM = 0x0303
-#include llvm/ADT/OwningPtr.h
-#endif
#if HAVE_LLVM = 0x0305
#include llvm/MC/MCContext.h
@@ -207,9 +204,9 @@ disassemble(const void* func, llvm::raw_ostream Out)
const Target *T = TargetRegistry::lookupTarget(Triple, Error);
#if HAVE_LLVM = 0x0304
- OwningPtrconst MCAsmInfo
AsmInfo(T-createMCAsmInfo(*T-createMCRegInfo(Triple), Triple));
+ std::unique_ptr const MCAsmInfo
AsmInfo(T-createMCAsmInfo(*T-createMCRegInfo(Triple), Triple));
#else
- OwningPtrconst MCAsmInfo AsmInfo(T-createMCAsmInfo(Triple));
+ std::unique_ptrconst MCAsmInfo AsmInfo(T-createMCAsmInfo(Triple));
#endif
if (!AsmInfo) {
@@ -220,14 +217,14 @@ disassemble(const void* func, llvm::raw_ostream Out)
unsigned int AsmPrinterVariant = AsmInfo-getAssemblerDialect();
- OwningPtrconst MCRegisterInfo MRI(T-createMCRegInfo(Triple));
+ std::unique_ptr const MCRegisterInfo MRI(T-createMCRegInfo(Triple));
if (!MRI) {
Out error: no register info for target Triple.c_str() \n;
Out.flush();
return 0;
}
- OwningPtrconst MCInstrInfo MII(T-createMCInstrInfo());
+ std::unique_ptrconst MCInstrInfo MII(T-createMCInstrInfo());
if (!MII) {
Out error: no instruction info for target Triple.c_str()
\n;
Out.flush();
@@ -235,12 +232,12 @@ disassemble(const void* func, llvm::raw_ostream Out)
}
#if HAVE_LLVM = 0x0305
- OwningPtrconst MCSubtargetInfo STI(T-createMCSubtargetInfo(Triple,
sys::getHostCPUName(), ));
- OwningPtrMCContext MCCtx(new MCContext(AsmInfo.get(), MRI.get(), 0));
- OwningPtrconst MCDisassembler DisAsm(T-createMCDisassembler(*STI,
*MCCtx));
+ std::unique_ptrconst MCSubtargetInfo STI(T-createMCSubtargetInfo(Triple,
sys::getHostCPUName(), ));
+ std::unique_ptrMCContext MCCtx(new MCContext(AsmInfo.get(), MRI.get(),
0));
+ std::unique_ptrconst MCDisassembler DisAsm(T-createMCDisassembler(*STI,
*MCCtx));
#else
- OwningPtrconst MCSubtargetInfo STI(T-createMCSubtargetInfo(Triple,
sys::getHostCPUName(), ));
- OwningPtrconst MCDisassembler DisAsm(T-createMCDisassembler(*STI));
+ std::unique_ptrconst MCSubtargetInfo STI(T-createMCSubtargetInfo(Triple,
sys::getHostCPUName(), ));
+ std::unique_ptrconst MCDisassembler
DisAsm(T-createMCDisassembler(*STI));
#endif
if (!DisAsm) {
Out error: no disassembler for target Triple \n;
@@ -249,7 +246,7 @@ disassemble(const void* func, llvm::raw_ostream Out)
}
- OwningPtrMCInstPrinter Printer(
+ std::unique_ptrMCInstPrinter Printer(
T-createMCInstPrinter(AsmPrinterVariant, *AsmInfo, *MII, *MRI,
*STI));
if (!Printer) {
Out error: no instruction printer for target Triple.c_str()
\n;
@@ -267,7 +264,7 @@ disassemble(const void* func, llvm::raw_ostream Out)
#if defined(DEBUG) || defined(PROFILE)
options.NoFramePointerElim = true;
#endif
- OwningPtrTargetMachine TM(T-createTargetMachine(Triple,
sys::getHostCPUName(), , options));
+ std::unique_ptrTargetMachine TM(T-createTargetMachine(Triple,
sys::getHostCPUName(), , options));
const TargetInstrInfo *TII = TM-getInstrInfo();
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
[Mesa-dev] [Bug 80243] Mesa and libclc build failure after llvm = llvm-3.5svn r211259
https://bugs.freedesktop.org/show_bug.cgi?id=80243 --- Comment #1 from Tom Stellard tstel...@gmail.com --- Can you send this patch to mesa-dev@lists.freedesktop.org ? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r600: Fix possible endless loop in compute_memory_pool allocations.
On Thu, 2014-06-19 at 11:58 -0400, Jan Vesely wrote:
On Thu, 2014-06-19 at 08:27 -0700, Tom Stellard wrote:
On Thu, Jun 19, 2014 at 10:21:32AM -0400, Jan Vesely wrote:
The important part is the change of the condition to = 0. Otherwise the
loop
gets stuck never actually growing the pool.
The change in the aux-need calculation guarantees max 2 iterations, and
avoids wasting memory in case a smaller item can't fit into a relatively
larger
pool.
Does this patch obsolete the XXX comment around line 292 of this file? If
so,
we should remove it.
I'm not sure if the XXX comment applies to the first:
if (pool-size_in_dw allocated+unallocated)
or in general.
In general I think the comment is obsolete as is. There already is a
logic that tries to grow the pool if allocation fails despite enough
free space. The patch only changes the the condition to include free
space==needed space corner case.
The change in requested size is separate and does not change the
situation.
Hi,
As far as I understand it, this patch doesn't make obsolete that
comment. But that may be because I understant that that comment only
refers to the first grow of the pool, and the rest is a workaround to
continue growing the pool if we can't fit in the new items.
Also have tried this with patches 1-9 of this series:
http://lists.freedesktop.org/archives/mesa-dev/2014-June/061742.html
I have not tried applying the patches, but patch 5/11 moves the very
same logic ( if (need 0)), to a slightly different location. So I think
that patch needs to be updated to include the fix.
You are right, this patch is still needed in my series.
That series also removes one call to compute_memory_pool_finalize, so
adding a check there now might be redundant. However, I'd still prefer
to check return value of both calls to compute_memory_pool_finalize for
consistency.
I'm OK with adding both calls, and I don't think it is redundant.
Imagine the case where my series don't land, we would have one call
checked and the other not.
I'll try to rebase my series on top of yours.
Thanks!
Bruno
regards,
Jan
-Tom
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
This fixes hang in gegl colors.xml test
src/gallium/drivers/r600/compute_memory_pool.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index ec8c470..0b6d2da6 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -320,8 +320,11 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
int64_t need = item-size_in_dw+2048 -
(pool-size_in_dw - allocated);
- if (need 0) {
- need = pool-size_in_dw / 10;
+ if (need = 0) {
+ /* There's enough free space, but it's too
+ * fragmented. Assume half of the item can fit
+ * int the last chunk */
+ need = (item-size_in_dw / 2) + ITEM_ALIGNMENT;
}
need = align(need, ITEM_ALIGNMENT);
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 11/23] glsl: Add support for EmitStreamVertex() and EndStreamPrimitive().
On Thu, Jun 19, 2014 at 6:37 AM, Iago Toral ito...@igalia.com wrote: Regarding st_glsl_to_tgsi.cpp, I think I can use some guidance since I am not familiar with gallium. Seeing what is being done for other IR types, I think I need to do something like: st_src_reg stream_src = ir-stream-accept(this); and then emit the TGSI_OPCODE_EMIT passing stream_src to it. However, I see that glsl_to_tgsi_visitor::emit() can take no src/dst arguments or if it takes, it takes one dst/src pair at least, so I am not sure what should be done here... what do I have to use for the dst parameter? should I just pass undef_dst? something else? Gallium presently doesn't have support for streams. This is the patch series I used on top of your earlier series to start adding it in: https://github.com/imirkin/mesa/commits/tfb However it's probably fine for you to skip trying to add gallium support for now. I'm sure my series is some stuff too... probably to do with queries. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Broadcom VC4 project
Am 19.06.2014 09:54, schrieb Eric Anholt: Dave Airlie airl...@gmail.com writes: I'm working toward building a Mesa driver for Broadcom VC4 (aka Raspberry Pi). At the moment I'm still bringing up the DRM side of things, but I hope to be doing bits of userspace in the next few days. Current status is I have a skeleton DRM KMS driver that's going to talk to the firmware for modesetting, and now I'm starting on the execution side of things. I'm probably going to start out doing a gallium driver for simplicity, to avoid having to do all the DRI crap we've got in brw_context.c and texture miptree validation and getting user data into VBOs and all that other almost-boilerplate. Long term I may end up switching to classic so I can get swrast fallbacks and the ability to implement single-copy manually-tiled TexImage uploads like. For now I want to get to drawing triangles as soon as I can. Do we know anywhere swrast fallbacks make sense? like except for conformance testing, You've got an armv6 swrast fallbacks are going to be punishing, I don't even think it has neon extensions. Yeah, but fallbacks are less punishing than my screen is black, what's going on?!?! bug reports. I respectfully disagree. You trade my screen is black bug reports (though more than likely just portions of it will be garbage, at least with shader capable hw you should never need to fallback for relatively simple stuff) for why does my screen only refresh once every 10 seconds bug reports. In severity from an end user perspective, they are just as bad. Besides, the full swrast fallbacks rarely work in a fully correct manner (though it may be permitted by GL invariance rules at least in some cases) due to differences in rasterization. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r600: Fix possible endless loop in compute_memory_pool allocations.
On Thu, 2014-06-19 at 18:22 +0200, Bruno Jimenez wrote:
On Thu, 2014-06-19 at 11:58 -0400, Jan Vesely wrote:
On Thu, 2014-06-19 at 08:27 -0700, Tom Stellard wrote:
On Thu, Jun 19, 2014 at 10:21:32AM -0400, Jan Vesely wrote:
The important part is the change of the condition to = 0. Otherwise
the loop
gets stuck never actually growing the pool.
The change in the aux-need calculation guarantees max 2 iterations, and
avoids wasting memory in case a smaller item can't fit into a
relatively larger
pool.
Does this patch obsolete the XXX comment around line 292 of this file?
If so,
we should remove it.
I'm not sure if the XXX comment applies to the first:
if (pool-size_in_dw allocated+unallocated)
or in general.
In general I think the comment is obsolete as is. There already is a
logic that tries to grow the pool if allocation fails despite enough
free space. The patch only changes the the condition to include free
space==needed space corner case.
The change in requested size is separate and does not change the
situation.
Hi,
As far as I understand it, this patch doesn't make obsolete that
comment. But that may be because I understant that that comment only
refers to the first grow of the pool, and the rest is a workaround to
continue growing the pool if we can't fit in the new items.
Hi,
thanks for clarification. Since the pool is potentially grown to fit
every item, is the initial
compute_memory_grow_pool(pool, pipe, allocated+unallocated);
needed at all?
regards,
Jan
Also have tried this with patches 1-9 of this series:
http://lists.freedesktop.org/archives/mesa-dev/2014-June/061742.html
I have not tried applying the patches, but patch 5/11 moves the very
same logic ( if (need 0)), to a slightly different location. So I think
that patch needs to be updated to include the fix.
You are right, this patch is still needed in my series.
That series also removes one call to compute_memory_pool_finalize, so
adding a check there now might be redundant. However, I'd still prefer
to check return value of both calls to compute_memory_pool_finalize for
consistency.
I'm OK with adding both calls, and I don't think it is redundant.
Imagine the case where my series don't land, we would have one call
checked and the other not.
I'll try to rebase my series on top of yours.
Thanks!
Bruno
regards,
Jan
-Tom
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
This fixes hang in gegl colors.xml test
src/gallium/drivers/r600/compute_memory_pool.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index ec8c470..0b6d2da6 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -320,8 +320,11 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
int64_t need = item-size_in_dw+2048 -
(pool-size_in_dw -
allocated);
- if (need 0) {
- need = pool-size_in_dw / 10;
+ if (need = 0) {
+ /* There's enough free space, but it's
too
+* fragmented. Assume half of the item
can fit
+* int the last chunk */
+ need = (item-size_in_dw / 2) +
ITEM_ALIGNMENT;
}
need = align(need, ITEM_ALIGNMENT);
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Jan Vesely jan.ves...@rutgers.edu
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/12] r600g/compute: Defer the creation of the temporary resource
For the first use of a buffer, we will only need the temporary
resource in the case that a user wants to write/map to this buffer.
But in the cases where the user creates a buffer to act as an
output of a kernel, then we were creating an unneeded resource,
because it will contain garbage, and would be copied to the pool,
and destroyed when promoting.
This patch avoids the creation and copies of resources in
this case.
---
src/gallium/drivers/r600/compute_memory_pool.c | 31 +-
src/gallium/drivers/r600/evergreen_compute.c | 17 +-
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index a78ff1e..7540f14 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -352,19 +352,21 @@ int compute_memory_promote_item(struct
compute_memory_pool *pool,
list_add(item-link, pos);
item-start_in_dw = start_in_dw;
- u_box_1d(0, item-size_in_dw * 4, box);
-
- rctx-b.b.resource_copy_region(pipe,
- dst, 0, item-start_in_dw * 4, 0 ,0,
- src, 0, box);
-
- /* We check if the item is mapped for reading.
-* In this case, we need to keep the temporary buffer 'alive'
-* because it is possible to keep a map active for reading
-* while a kernel (that reads from it) executes */
- if (!(item-status ITEM_MAPPED_FOR_READING)) {
- pool-screen-b.b.resource_destroy(screen, src);
- item-real_buffer = NULL;
+ if (src != NULL) {
+ u_box_1d(0, item-size_in_dw * 4, box);
+
+ rctx-b.b.resource_copy_region(pipe,
+ dst, 0, item-start_in_dw * 4, 0 ,0,
+ src, 0, box);
+
+ /* We check if the item is mapped for reading.
+* In this case, we need to keep the temporary buffer 'alive'
+* because it is possible to keep a map active for reading
+* while a kernel (that reads from it) executes */
+ if (!(item-status ITEM_MAPPED_FOR_READING)) {
+ pool-screen-b.b.resource_destroy(screen, src);
+ item-real_buffer = NULL;
+ }
}
return 0;
@@ -474,8 +476,7 @@ struct compute_memory_item* compute_memory_alloc(
new_item-start_in_dw = -1; /* mark pending */
new_item-id = pool-next_id++;
new_item-pool = pool;
- new_item-real_buffer = (struct
r600_resource*)r600_compute_buffer_alloc_vram(
- pool-screen,
size_in_dw * 4);
+ new_item-real_buffer = NULL;
list_addtail(new_item-link, pool-unallocated_list);
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 5c115dc..12e9c85 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -970,14 +970,21 @@ void *r600_compute_global_transfer_map(
struct r600_resource_global* buffer =
(struct r600_resource_global*)resource;
- struct pipe_resource *dst;
+ struct compute_memory_item *item = buffer-chunk;
+ struct pipe_resource *dst = NULL;
unsigned offset = box-x;
- if (is_item_in_pool(buffer-chunk)) {
- compute_memory_demote_item(pool, buffer-chunk, ctx_);
+ if (is_item_in_pool(item)) {
+ compute_memory_demote_item(pool, item, ctx_);
+ }
+ else {
+ if (item-real_buffer == NULL) {
+ item-real_buffer = (struct r600_resource*)
+
r600_compute_buffer_alloc_vram(pool-screen, item-size_in_dw * 4);
+ }
}
- dst = (struct pipe_resource*)buffer-chunk-real_buffer;
+ dst = (struct pipe_resource*)item-real_buffer;
if (usage PIPE_TRANSFER_READ)
buffer-chunk-status |= ITEM_MAPPED_FOR_READING;
@@ -988,7 +995,7 @@ void *r600_compute_global_transfer_map(
box-x, box-y, box-z, box-width, box-height,
box-depth);
COMPUTE_DBG(rctx-screen, Buffer id = %u offset =
- %u (box.x)\n, buffer-chunk-id, box-x);
+ %u (box.x)\n, item-id, box-x);
assert(resource-target == PIPE_BUFFER);
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/12] r600g/compute: Fix possible endless loop in compute_memory_pool allocations.
From: Jan Vesely jan.ves...@rutgers.edu
The important part is the change of the condition to = 0. Otherwise the loop
gets stuck never actually growing the pool.
The change in the aux-need calculation guarantees max 2 iterations, and
avoids wasting memory in case a smaller item can't fit into a relatively larger
pool.
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
src/gallium/drivers/r600/compute_memory_pool.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 518ea65..a78ff1e 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -323,8 +323,11 @@ int compute_memory_promote_item(struct compute_memory_pool
*pool,
int64_t need = item-size_in_dw + 2048 -
(pool-size_in_dw - allocated);
- if (need 0) {
- need = pool-size_in_dw / 10;
+ if (need = 0) {
+ /* There's enough free space, but it's too
+* fragmented. Assume half of the item can fit
+* int the last chunk */
+ need = (item-size_in_dw / 2) + ITEM_ALIGNMENT;
}
need = align(need, ITEM_ALIGNMENT);
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/12] r600g/compute: Handle failures in compute_memory_pool_finalize
From: Jan Vesely jan.ves...@rutgers.edu
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
src/gallium/drivers/r600/evergreen_compute.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index c0dd0f3..5c115dc 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -668,7 +668,10 @@ static void evergreen_set_global_binding(
buffers[i]-chunk-status |= ITEM_FOR_PROMOTING;
}
- compute_memory_finalize_pending(pool, ctx_);
+ if (compute_memory_finalize_pending(pool, ctx_) == -1) {
+ /* XXX: Unset */
+ return;
+ }
for (int i = 0; i n; i++)
{
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r600: Fix possible endless loop in compute_memory_pool allocations.
On Thu, 2014-06-19 at 13:39 -0400, Jan Vesely wrote:
On Thu, 2014-06-19 at 18:22 +0200, Bruno Jimenez wrote:
On Thu, 2014-06-19 at 11:58 -0400, Jan Vesely wrote:
On Thu, 2014-06-19 at 08:27 -0700, Tom Stellard wrote:
On Thu, Jun 19, 2014 at 10:21:32AM -0400, Jan Vesely wrote:
The important part is the change of the condition to = 0. Otherwise
the loop
gets stuck never actually growing the pool.
The change in the aux-need calculation guarantees max 2 iterations,
and
avoids wasting memory in case a smaller item can't fit into a
relatively larger
pool.
Does this patch obsolete the XXX comment around line 292 of this file?
If so,
we should remove it.
I'm not sure if the XXX comment applies to the first:
if (pool-size_in_dw allocated+unallocated)
or in general.
In general I think the comment is obsolete as is. There already is a
logic that tries to grow the pool if allocation fails despite enough
free space. The patch only changes the the condition to include free
space==needed space corner case.
The change in requested size is separate and does not change the
situation.
Hi,
As far as I understand it, this patch doesn't make obsolete that
comment. But that may be because I understant that that comment only
refers to the first grow of the pool, and the rest is a workaround to
continue growing the pool if we can't fit in the new items.
Hi,
thanks for clarification. Since the pool is potentially grown to fit
every item, is the initial
compute_memory_grow_pool(pool, pipe, allocated+unallocated);
needed at all?
Hi,
When there are no gaps in the pool, it is just needed to grow once,
precisely this time.
Of course, it is perfectly possible to drop that part, but if you have
to add a lot of items it's faster to grow the pool just once.
Hope I have helped. If you have any other doubt, just ask!
Bruno
regards,
Jan
Also have tried this with patches 1-9 of this series:
http://lists.freedesktop.org/archives/mesa-dev/2014-June/061742.html
I have not tried applying the patches, but patch 5/11 moves the very
same logic ( if (need 0)), to a slightly different location. So I think
that patch needs to be updated to include the fix.
You are right, this patch is still needed in my series.
That series also removes one call to compute_memory_pool_finalize, so
adding a check there now might be redundant. However, I'd still prefer
to check return value of both calls to compute_memory_pool_finalize for
consistency.
I'm OK with adding both calls, and I don't think it is redundant.
Imagine the case where my series don't land, we would have one call
checked and the other not.
I'll try to rebase my series on top of yours.
Thanks!
Bruno
regards,
Jan
-Tom
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
CC: Bruno Jimenez brunoji...@gmail.com
---
This fixes hang in gegl colors.xml test
src/gallium/drivers/r600/compute_memory_pool.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index ec8c470..0b6d2da6 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -320,8 +320,11 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
int64_t need = item-size_in_dw+2048 -
(pool-size_in_dw -
allocated);
- if (need 0) {
- need = pool-size_in_dw / 10;
+ if (need = 0) {
+ /* There's enough free space, but it's
too
+ * fragmented. Assume half of the item
can fit
+ * int the last chunk */
+ need = (item-size_in_dw / 2) +
ITEM_ALIGNMENT;
}
need = align(need, ITEM_ALIGNMENT);
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] scons: avoid building any piece of i915
Leftover from commit c21fca8bf24.
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/SConscript| 11 ---
src/gallium/drivers/i915/SConscript | 12
src/gallium/winsys/i915/sw/SConscript | 12
3 files changed, 35 deletions(-)
delete mode 100644 src/gallium/drivers/i915/SConscript
delete mode 100644 src/gallium/winsys/i915/sw/SConscript
diff --git a/src/gallium/SConscript b/src/gallium/SConscript
index d6ca993..2ce8a46 100644
--- a/src/gallium/SConscript
+++ b/src/gallium/SConscript
@@ -21,12 +21,6 @@ SConscript([
'drivers/trace/SConscript',
])
-if not env['msvc']:
-# These drivers do not build on MSVC compilers
-SConscript([
-'drivers/i915/SConscript',
-])
-
#
# State trackers
#
@@ -62,11 +56,6 @@ if env['platform'] == 'windows':
'winsys/sw/gdi/SConscript',
])
-if not env['msvc']:
-SConscript([
-'winsys/i915/sw/SConscript',
-])
-
if env['platform'] == 'haiku':
SConscript([
'winsys/sw/hgl/SConscript',
diff --git a/src/gallium/drivers/i915/SConscript
b/src/gallium/drivers/i915/SConscript
deleted file mode 100644
index 22de67d..000
--- a/src/gallium/drivers/i915/SConscript
+++ /dev/null
@@ -1,12 +0,0 @@
-Import('*')
-
-env = env.Clone()
-
-i915 = env.ConvenienceLibrary(
- target = 'i915',
- source = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
- )
-
-env.Alias('i915', i915)
-
-Export('i915')
diff --git a/src/gallium/winsys/i915/sw/SConscript
b/src/gallium/winsys/i915/sw/SConscript
deleted file mode 100644
index 9d78519..000
--- a/src/gallium/winsys/i915/sw/SConscript
+++ /dev/null
@@ -1,12 +0,0 @@
-Import('*')
-
-env = env.Clone()
-
-i915_sw_sources = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
-
-i915sw = env.ConvenienceLibrary(
-target ='i915sw',
-source = i915_sw_sources,
-)
-
-Export('i915sw')
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] nouveau: dup fd before passing it to device
nouveau screens are reused for the same device node. However in the
scenario where we create screen 1, screen 2, and then delete screen 1,
the surrounding code might also close the original device node. To
protect against this, dup the fd and use the dup'd fd in the
nouveau_device. Also tell the nouveau_device that it is the owner of the
fd so that it will be closed on destruction.
Also make sure to free the nouveau_device in case of any failure.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79823
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
v1 - v2:
clean up dup fd if device creation fails
src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c
b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c
index 1dfdaac..0635246 100644
--- a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c
+++ b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c
@@ -1,4 +1,5 @@
#include sys/stat.h
+#include unistd.h
#include pipe/p_context.h
#include pipe/p_state.h
#include util/u_format.h
@@ -59,7 +60,7 @@ nouveau_drm_screen_create(int fd)
struct nouveau_device *dev = NULL;
struct pipe_screen *(*init)(struct nouveau_device *);
struct nouveau_screen *screen;
- int ret;
+ int ret, dupfd = -1;
pipe_mutex_lock(nouveau_screen_mutex);
if (!fd_tab) {
@@ -75,7 +76,17 @@ nouveau_drm_screen_create(int fd)
return screen-base;
}
- ret = nouveau_device_wrap(fd, 0, dev);
+ /* Since the screen re-use is based on the device node and not the fd,
+* create a copy of the fd to be owned by the device. Otherwise a
+* scenario could occur where two screens are created, and the first
+* one is shut down, along with the fd being closed. The second
+* (identical) screen would now have a reference to the closed fd. We
+* avoid this by duplicating the original fd. Note that
+* nouveau_device_wrap does not close the fd in case of a device
+* creation error.
+*/
+ dupfd = dup(fd);
+ ret = nouveau_device_wrap(dupfd, 1, dev);
if (ret)
goto err;
@@ -115,6 +126,10 @@ nouveau_drm_screen_create(int fd)
return screen-base;
err:
+ if (dev)
+ nouveau_device_del(dev);
+ else if (dupfd = 0)
+ close(dupfd);
pipe_mutex_unlock(nouveau_screen_mutex);
return NULL;
}
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 3/3] Add a new capabilities for drivers that can't share buffers
On 19/06/2014 15:56, Giovanni Campagna wrote : 2014-06-19 16:16 GMT+02:00 Axel Davy axel.d...@ens.fr: On 15/06/2014 07:49, Giovanni Campagna wrote : From: Giovanni Campagna gcampa...@src.gnome.org The kms-dri swrast driver cannot share buffers using the GEM, so it must tell the loader to disable extensions relying on that, without disabling the image DRI extension altogheter (which would prevent the loader from working at all). This requires a new gallium capability (which is queried on the pipe_screen and for swrast drivers it's forwared to the winsys), and requires a new version of the DRI image extension. Why does this require a new version of the DRI image extension ? Could you just set createImageFromName and CreateImageFromNames to NULL, and add checks for that (instead of checking the capability ? It's what is done to check if we can import dma-bufs (check if createImageFromFds is not NULL). Yes, but in my opinion a generic getCapabilities() that returns a bitmask is more flexible, and will allow avoiding version increases and new vfuncs, should negotiation for new features be needed in the future. Giovanni I have no opinion on which solution is better (checking if the DRIimage function is non null, or checking capability), but if we opt for capability, then the locations at which we check createImageFromFds against NULL should be modified to use getCapabilities. Also perhaps there's similar things happening for other DRIimage functions. Axel Davy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/23] Megadrivers galore
Hi, I tried pulling down your git-branch, and test it out. (I'm running Intel graphics on Ivy-Bridge, Arch Linux). Using my old autogen-line failed. (It never reached the point where it says to go ahead and type make to build the stuffs) ./autogen.sh --prefix=/usr --sysconfdir=/etc --with-dri-driverdir=/usr/lib/xorg/modules/dri - -with-dri-drivers=i965 --with-egl-platforms=x11,drm,wayland --enable-egl --enable-shared-glapi --enable-gbm --enable-glx-tls --enable-dri --enable-glx --enable-osmesa --enable-gles1 --enable-gles2 --enable-texture-float --enable-xa --disable-xvmc --enable-debug At the very top i find an error: configure.ac:2173: error: required file 'src/gallium/state_trackers/dri/drm/Makefile.in' not found configure.ac:2173: error: required file 'src/gallium/state_trackers/dri/sw/Makefile.in' not found It also complains about source files being in subdirectories, but some subdir-objects option is not enabled. Looking closer these warnings also appear when doing a build of the master tree with the same command, but there the autogen-stuff end up with a result that let's me make. I then went ahead and did a bisect, doing a make clean between each. Eventually I had gotten to head without any fails, and now head also succeeded. Seems like some files being left from previous compiles lets the compile work as a charm, but if I start from bare bones it does not. I'm no expert in build-systems, so that's about all I have for now. Let me know if there's something specific you want me to try out. Cheers, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 11/23] glsl: Add support for EmitStreamVertex() and EndStreamPrimitive().
On Thursday, June 19, 2014 12:37:43 PM Iago Toral wrote:
After having a quick look at ir_to_mesa.cpp and st_glsl_to_tgsi.cpp I
have some comments and questions about this:
On Wed, 2014-06-18 at 13:31 -0700, Ian Romanick wrote:
This patch should be split into several patches:
1. Modify ir_emit_vertex to have a stream. This patch also needs to
update
ir_to_mesa.cpp and st_glsl_to_tgsi.cpp.
ir_to_mesa.cpp does not currently implement support for emit_vertex and
end_primitive at all:
void
ir_to_mesa_visitor::visit(ir_emit_vertex *)
{
assert(!Geometry shaders not supported.);
}
void
ir_to_mesa_visitor::visit(ir_end_primitive *)
{
assert(!Geometry shaders not supported.);
}
so doing this, as far as I can see, involves defining opcodes for
emit_vertex and end_primitive and then handle these opcodes properly in
other places of the code so things can get done I guess. I am not yet
familiar with this parts of the code base, so I guess I'll need some
time to figure how to do this right. Since ir_to_mesa.cpp is not
currently supporting ir_emit_vertex and ir_end_primitive at all, would
it be okay if we do this on a later patch after this series has been
reviewed ad merged?
Also, how can I debug this part of the code? what drivers are using
this?
I think what Ian meant is: make any changes necessary so ir_to_mesa.cpp keeps
compiling. There probably are none, since it doesn't handle those pieces of
IR (and shouldn't). We definitely don't want to add support for it.
Mesa IR is only used for old hardware, and only supports GLSL 1.20.
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80254] New: pipe_loader_sw.c:90: undefined reference to `dri_create_sw_winsys'
https://bugs.freedesktop.org/show_bug.cgi?id=80254 Priority: medium Bug ID: 80254 Keywords: regression CC: emil.l.veli...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: pipe_loader_sw.c:90: undefined reference to `dri_create_sw_winsys' Severity: normal Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: 4a39e5073a7d0cd8243c6f963567a9945265490c (master 10.3.0-devel) CCLD compute ../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_client.a(libpipe_loader_client_la-pipe_loader_sw.o): In function `pipe_loader_sw_probe_dri': src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c:90: undefined reference to `dri_create_sw_winsys' -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/23] Megadrivers galore
On 19/06/14 21:35, Thomas Helland wrote: Hi, I tried pulling down your git-branch, and test it out. (I'm running Intel graphics on Ivy-Bridge, Arch Linux). Using my old autogen-line failed. (It never reached the point where it says to go ahead and type make to build the stuffs) Thanks for testing Thomas, ./autogen.sh --prefix=/usr --sysconfdir=/etc --with-dri-driverdir=/usr/lib/xorg/modules/dri - -with-dri-drivers=i965 --with-egl-platforms=x11,drm,wayland --enable-egl --enable-shared-glapi --enable-gbm --enable-glx-tls --enable-dri --enable-glx --enable-osmesa --enable-gles1 --enable-gles2 --enable-texture-float --enable-xa --disable-xvmc --enable-debug At the very top i find an error: configure.ac:2173: error: required file 'src/gallium/state_trackers/dri/drm/Makefile.in' not found configure.ac:2173: error: required file 'src/gallium/state_trackers/dri/sw/Makefile.in' not found Just pushed a patch that should fix this. It also complains about source files being in subdirectories, but some subdir-objects option is not enabled. Those issues are old, and the series indirectly addresses a few of them. Looking closer these warnings also appear when doing a build of the master tree with the same command, but there the autogen-stuff end up with a result that let's me make. I then went ahead and did a bisect, doing a make clean between each. Eventually I had gotten to head without any fails, and now head also succeeded. If there are any another issues with this branch do not bother bisecting, just report back your observation/errors. Can you fetch the branch again and give it another try ? Thanks Emil Seems like some files being left from previous compiles lets the compile work as a charm, but if I start from bare bones it does not. I'm no expert in build-systems, so that's about all I have for now. Let me know if there's something specific you want me to try out. Cheers, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glapi: Do not use backtrace on DragonFly.
execinfo.h is not available on DragonFly. Fixes this build error. CC glapi_gentable.lo glapi_gentable.c:44:22: fatal error: execinfo.h: No such file or directory Signed-off-by: Vinson Lee v...@freedesktop.org --- src/mapi/glapi/gen/gl_gentable.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mapi/glapi/gen/gl_gentable.py b/src/mapi/glapi/gen/gl_gentable.py index d45a5e0..2f01b4c 100644 --- a/src/mapi/glapi/gen/gl_gentable.py +++ b/src/mapi/glapi/gen/gl_gentable.py @@ -42,7 +42,7 @@ header = /* GLXEXT is the define used in the xserver when the GLX extension i #endif #if (defined(GLXEXT) defined(HAVE_BACKTRACE)) \\ - || (!defined(GLXEXT) defined(DEBUG) !defined(_WIN32_WCE) !defined(__CYGWIN__) !defined(__MINGW32__) !defined(__OpenBSD__) !defined(__NetBSD__)) + || (!defined(GLXEXT) defined(DEBUG) !defined(_WIN32_WCE) !defined(__CYGWIN__) !defined(__MINGW32__) !defined(__OpenBSD__) !defined(__NetBSD__) !defined(__DragonFly__)) #define USE_BACKTRACE #endif -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80254] pipe_loader_sw.c:90: undefined reference to `dri_create_sw_winsys'
https://bugs.freedesktop.org/show_bug.cgi?id=80254 --- Comment #1 from Vinson Lee v...@freedesktop.org --- d22b39e4db7d1c54461de97ff4dcb79178be1a84 is the first bad commit commit d22b39e4db7d1c54461de97ff4dcb79178be1a84 Author: Emil Velikov emil.l.veli...@gmail.com Date: Mon Jun 9 23:37:19 2014 +0100 targets: use GALLIUM_PIPE_LOADER_WINSYS_LIB_DEPS Drop ~50 lines of buildsystem mayhem. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com :04 04 39d2a60a87ac3196d5082c20f4e6d97567344a42 1a2e1839452e5f35a1ee1cd45e81036e948f92a3 Msrc bisect run success -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80254] pipe_loader_sw.c:90: undefined reference to `dri_create_sw_winsys'
https://bugs.freedesktop.org/show_bug.cgi?id=80254 --- Comment #2 from Emil Velikov emil.l.veli...@gmail.com --- Sigh linking order is the best. Curious why it fails rather selectively. Just double-checking the fix and will push that shortly. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80254] pipe_loader_sw.c:90: undefined reference to `dri_create_sw_winsys'
https://bugs.freedesktop.org/show_bug.cgi?id=80254 Emil Velikov emil.l.veli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Emil Velikov emil.l.veli...@gmail.com --- Should be fixed with commit d300f3f51a5b24e3959889f97a3fbe8cd10ace8e Author: Emil Velikov emil.l.veli...@gmail.com Date: Thu Jun 19 22:46:25 2014 +0100 automake: include the libdeps in the correct order Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80254 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 11/23] glsl: Add support for EmitStreamVertex() and EndStreamPrimitive().
On 06/19/2014 03:37 AM, Iago Toral wrote:
After having a quick look at ir_to_mesa.cpp and st_glsl_to_tgsi.cpp I
have some comments and questions about this:
On Wed, 2014-06-18 at 13:31 -0700, Ian Romanick wrote:
This patch should be split into several patches:
1. Modify ir_emit_vertex to have a stream. This patch also needs to update
ir_to_mesa.cpp and st_glsl_to_tgsi.cpp.
ir_to_mesa.cpp does not currently implement support for emit_vertex and
end_primitive at all:
void
ir_to_mesa_visitor::visit(ir_emit_vertex *)
{
assert(!Geometry shaders not supported.);
}
void
ir_to_mesa_visitor::visit(ir_end_primitive *)
{
assert(!Geometry shaders not supported.);
}
But the methods with these signatures have been deleted from
ir_hierarchical_visitor. They (and the st_glsl_to_tgsi counterparts)
need to be updated to be either visit_enter or visit_leave. That's all. :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] i965: Enable vertex streams up to MAX_VERTEX_STREAMS.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com On 06/19/2014 05:32 AM, Iago Toral Quiroga wrote: --- I guess this was an implicit reviewed-by with this change, but anyway... :) src/mesa/drivers/dri/i965/brw_context.c | 4 1 file changed, 4 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index cfb0be0..e168b6d 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -507,6 +507,10 @@ brw_initialize_context_constants(struct brw_context *brw) ctx-Const.ViewportBounds.Min = -(float)ctx-Const.MaxViewportWidth; ctx-Const.ViewportBounds.Max = ctx-Const.MaxViewportWidth; } + + /* ARB_gpu_shader5 */ + if (brw-gen = 7) + ctx-Const.MaxVertexStreams = MIN2(4, MAX_VERTEX_STREAMS); } /** ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 22/23] mesa: Init Geom.UsesEndPrimitive in shader programs.
On 06/18/2014 11:30 PM, Iago Toral wrote: On Wed, 2014-06-18 at 13:48 -0700, Ian Romanick wrote: I think this patch and 23 should be moved first in the series... the can certainly land before the other patches in the series. Right. I'll push these two tomorrow if nobody says otherwise today. Since you marked patch 23 for stable: do I need to do something else other than adding the CC tag in the commit message? Should I send the patch also to mesa-sta...@lists.freedesktop.org? Just copy-and-paste the Cc line that I put in the review. Branch maintainers use scripts to find candidate patches in the master branch. Iago This patch is Reviewed-by: Ian Romanick ian.d.roman...@intel.com On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote: --- src/mesa/main/shaderobj.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c index 03db862..b3d428c 100644 --- a/src/mesa/main/shaderobj.c +++ b/src/mesa/main/shaderobj.c @@ -248,6 +248,7 @@ _mesa_init_shader_program(struct gl_context *ctx, struct gl_shader_program *prog prog-Geom.VerticesOut = 0; prog-Geom.InputType = GL_TRIANGLES; prog-Geom.OutputType = GL_TRIANGLE_STRIP; + prog-Geom.UsesEndPrimitive = GL_FALSE; prog-Geom.UsesStreams = GL_FALSE; prog-TransformFeedback.BufferMode = GL_INTERLEAVED_ATTRIBS; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix glcpp to properly lex entire preprocessing numbers
On Thu, Jun 12, 2014 at 5:18 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
On Thu, Jun 12, 2014 at 3:13 PM, Carl Worth cwo...@cworth.org wrote:
The preprocessor defines a notions of a preprocessing number that
starts with either a digit or a decimal point, and continues with zero
or more of digits, decimal points, identifier characters, or the sign
symbols, ('-' and '+').
Prior to this change, preprocessing numbers were lexed as some
combination of OTHER and IDENTIFIER tokens. This had the problem of
causing undesired macro expansion in some cases.
We add tests to ensure that the undesired macro expansion does not
happen in cases such as:
#define e +1
#define xyz -2
int n = 1e;
int p = 1xyz;
In either case these macro definitions have no effect after this
change, so that the numeric literals, (whether valid or not), will be
passed on as-is from the preprocessor to the compiler proper.
This fixes at least the following Khronos GLES3 CTS test:
preprocessor.basic.correct_phases_fragment
---
src/glsl/glcpp/glcpp-lex.l| 6 ++
src/glsl/glcpp/tests/124-preprocessing-numbers.c | 8
src/glsl/glcpp/tests/124-preprocessing-numbers.c.expected | 9 +
3 files changed, 23 insertions(+)
create mode 100644 src/glsl/glcpp/tests/124-preprocessing-numbers.c
create mode 100644 src/glsl/glcpp/tests/124-preprocessing-numbers.c.expected
diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
index d5fb087..4dbaa9e 100644
--- a/src/glsl/glcpp/glcpp-lex.l
+++ b/src/glsl/glcpp/glcpp-lex.l
@@ -91,6 +91,7 @@ DIGITS[0-9][0-9]*
DECIMAL_INTEGER[1-9][0-9]*[uU]?
OCTAL_INTEGER 0[0-7]*[uU]?
HEXADECIMAL_INTEGER0[xX][0-9a-fA-F]+[uU]?
+PP_NUMBER [0-9.][-+._a-zA-Z0-9]*
It causes '2.0-MACRO' to incorrectly lexed as a preprocessing number.
Around 30 GLES3 CTS tests failed with this patch.
I think using below definition of preprocessing numbers should work fine:
PP_NUMBER \.?[0-9]([._a-zA-Z0-9]|[eEpP][+-])*
Used below link for definition of a preprocessing number:
https://gcc.gnu.org/onlinedocs/cpp/Tokenization.html
%%
@@ -339,6 +340,11 @@ HEXADECIMAL_INTEGER0[xX][0-9a-fA-F]+[uU]?
return OTHER;
}
+{PP_NUMBER} {
+ yylval-str = ralloc_strdup (yyextra, yytext);
+ return OTHER;
+}
+
{HSPACE} {
if (yyextra-space_tokens) {
return SPACE;
diff --git a/src/glsl/glcpp/tests/124-preprocessing-numbers.c
b/src/glsl/glcpp/tests/124-preprocessing-numbers.c
new file mode 100644
index 000..3743c69
--- /dev/null
+++ b/src/glsl/glcpp/tests/124-preprocessing-numbers.c
@@ -0,0 +1,8 @@
+#define e +1
+#define xyz -2
+
+/* The following are preprocessing numbers and should not trigger macro
+ * expansion. */
+int n = 1e;
+int p = 1xyz;
+
diff --git a/src/glsl/glcpp/tests/124-preprocessing-numbers.c.expected
b/src/glsl/glcpp/tests/124-preprocessing-numbers.c.expected
new file mode 100644
index 000..951581e
--- /dev/null
+++ b/src/glsl/glcpp/tests/124-preprocessing-numbers.c.expected
@@ -0,0 +1,9 @@
+
+
+
+
+
+int n = 1e;
+int p = 1xyz;
+
+
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/19] i965: Pass brw into next_offset().
This series (my branch has some small updates) passes piglit runs on BDW and Haswell, with assertions enabled in Mesa. Objections to me pushing it? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 3/3] Add a new capabilities for drivers that can't share buffers
2014-06-19 16:16 GMT+02:00 Axel Davy axel.d...@ens.fr: On 15/06/2014 07:49, Giovanni Campagna wrote : From: Giovanni Campagna gcampa...@src.gnome.org The kms-dri swrast driver cannot share buffers using the GEM, so it must tell the loader to disable extensions relying on that, without disabling the image DRI extension altogheter (which would prevent the loader from working at all). This requires a new gallium capability (which is queried on the pipe_screen and for swrast drivers it's forwared to the winsys), and requires a new version of the DRI image extension. Why does this require a new version of the DRI image extension ? Could you just set createImageFromName and CreateImageFromNames to NULL, and add checks for that (instead of checking the capability ? It's what is done to check if we can import dma-bufs (check if createImageFromFds is not NULL). Yes, but in my opinion a generic getCapabilities() that returns a bitmask is more flexible, and will allow avoiding version increases and new vfuncs, should negotiation for new features be needed in the future. Giovanni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 54372] GLX_INTEL_swap_event crashes driver when swapping window buffers
https://bugs.freedesktop.org/show_bug.cgi?id=54372 --- Comment #23 from danm...@gmail.com --- Hi, it has been a week since my last ping message and your git repository still doesn't have either of these bug fixes in it. What's the schedule? -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/19] i965: Pass brw into next_offset().
On Thursday, June 19, 2014 05:15:06 PM Matt Turner wrote: This series (my branch has some small updates) passes piglit runs on BDW and Haswell, with assertions enabled in Mesa. Objections to me pushing it? Yeah - let me test it on older platforms first. Assuming that passes, pushing this sounds good to me. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
