Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600
Hi, 在 2011年8月2日 下午8:16，fykc...@gmail.com 写道： >> Depending on how it was configured mplayer needs (probably) >> /etc/X11/XvMCConfig containing /path/to/your/lib/libXvMCr600.so > I add the path "/usr/lib/libXvMCr600.so" to /etc/X11/XvMCConfig, but > mplayer seems not invoke it (No r600 in strace or /proc/pid/maps). > Maybe I should try a newer version of mplayer. My mplayer reads /usr/lib/XvMCConfig, after I providing that file, libXvMCr600.so is loaded by mplayer. >> Generally r600 pipe-video still has rendering and functional issues. If you >> just want to test fair enough, but if you are trying to make your system >> play h264 that it can't currently the best thing you could do is compile svn >> mplayer which now has ffmpeg h264 multithread support so - >> >> mplayer -lavdopts threads=4 will use all of your cores. Tried, not make big difference at first glance. (P.S. can mplayer show fps in OSD?) That still doesn't use all CPU power(even with thread=8) according to top. -- Regards, - cee1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Implement HW accelerated GL_SELECT
---
src/mesa/SConscript |1 +
src/mesa/main/mtypes.h |7 +
src/mesa/sources.mak |1 +
src/mesa/state_tracker/st_cb_feedback.c | 21 +-
src/mesa/state_tracker/st_draw.h | 17 +
src/mesa/state_tracker/st_draw_select_emul.c | 475 ++
6 files changed, 517 insertions(+), 5 deletions(-)
create mode 100644 src/mesa/state_tracker/st_draw_select_emul.c
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 24e2155..288b162 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -262,6 +262,7 @@ statetracker_sources = [
'state_tracker/st_debug.c',
'state_tracker/st_draw.c',
'state_tracker/st_draw_feedback.c',
+'state_tracker/st_draw_select_emul.c',
'state_tracker/st_extensions.c',
'state_tracker/st_format.c',
'state_tracker/st_gen_mipmap.c',
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index b881183..10222d8 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1721,6 +1721,13 @@ struct gl_selection
GLboolean HitFlag; /**< hit flag */
GLfloat HitMinZ;/**< minimum hit depth */
GLfloat HitMaxZ;/**< maximum hit depth */
+ struct gl_selection_emul /* data related to hw accelerated GL_SELECT */
+ {
+ GLboolean hw_unsupported;
+ struct gl_framebuffer *fbo;
+ GLuint renderBuffer_depth;
+ GLuint renderBuffer_color;
+ } emul;
};
diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
index 4b2ec08..9af4079 100644
--- a/src/mesa/sources.mak
+++ b/src/mesa/sources.mak
@@ -229,6 +229,7 @@ STATETRACKER_SOURCES = \
state_tracker/st_debug.c \
state_tracker/st_draw.c \
state_tracker/st_draw_feedback.c \
+ state_tracker/st_draw_select_emul.c \
state_tracker/st_extensions.c \
state_tracker/st_format.c \
state_tracker/st_gen_mipmap.c \
diff --git a/src/mesa/state_tracker/st_cb_feedback.c
b/src/mesa/state_tracker/st_cb_feedback.c
index 9b85a39..9382895 100644
--- a/src/mesa/state_tracker/st_cb_feedback.c
+++ b/src/mesa/state_tracker/st_cb_feedback.c
@@ -276,17 +276,28 @@ st_RenderMode(struct gl_context *ctx, GLenum newMode )
{
struct st_context *st = st_context(ctx);
struct draw_context *draw = st->draw;
+ bool hw_acc_path = _mesa_getenv("MESA_HW_SELECT") &&
!ctx->Select.emul.hw_unsupported;
if (newMode == GL_RENDER) {
/* restore normal VBO draw function */
vbo_set_draw_func(ctx, st_draw_vbo);
}
else if (newMode == GL_SELECT) {
- if (!st->selection_stage)
- st->selection_stage = draw_glselect_stage(ctx, draw);
- draw_set_rasterize_stage(draw, st->selection_stage);
- /* Plug in new vbo draw function */
- vbo_set_draw_func(ctx, st_feedback_draw_vbo);
+ if (hw_acc_path) {
+ if (st_select_emul_begin(ctx)) {
+vbo_set_draw_func(ctx, st_select_draw_func);
+ }
+ else {
+hw_acc_path = false;
+ }
+ }
+ if (!hw_acc_path) {
+ if (!st->selection_stage)
+st->selection_stage = draw_glselect_stage(ctx, draw);
+ draw_set_rasterize_stage(draw, st->selection_stage);
+ /* Plug in new vbo draw function */
+ vbo_set_draw_func(ctx, st_feedback_draw_vbo);
+ }
}
else {
if (!st->feedback_stage)
diff --git a/src/mesa/state_tracker/st_draw.h b/src/mesa/state_tracker/st_draw.h
index a7b50ce..d27e321 100644
--- a/src/mesa/state_tracker/st_draw.h
+++ b/src/mesa/state_tracker/st_draw.h
@@ -87,5 +87,22 @@ pointer_to_offset(const void *ptr)
return (unsigned) (((unsigned long) ptr) & 0xUL);
}
+/* Functions used by the hw accelerated GL_SELECT emulator
+ */
+extern bool
+st_select_emul_begin(struct gl_context *ctx);
+
+extern void
+st_select_emul_end(struct gl_context *ctx);
+
+extern void
+st_select_draw_func(struct gl_context *ctx,
+const struct gl_client_array **arrays,
+const struct _mesa_prim *prims,
+GLuint nr_prims,
+const struct _mesa_index_buffer *ib,
+GLboolean index_bounds_valid,
+GLuint min_index,
+GLuint max_index);
#endif
diff --git a/src/mesa/state_tracker/st_draw_select_emul.c
b/src/mesa/state_tracker/st_draw_select_emul.c
new file mode 100644
index 000..ea54f22
--- /dev/null
+++ b/src/mesa/state_tracker/st_draw_select_emul.c
@@ -0,0 +1,475 @@
+/**
+ *
+ * Copyright 2011 Micael Dias .
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ *
Re: [Mesa-dev] [PATCH 3/4] glsl: Slight change to the code generated by if-flattening
On Tue, 2 Aug 2011 17:52:03 -0700, "Ian Romanick" wrote:
> From: Ian Romanick
>
> Now the condition (for the then-clause) and the inverse condition (for
> the else-clause) get written to sepearate temporary variables. In the
"separate"
> presense of complex conditions, this may result in more code being
> generated.
I hope s/more/less/
And this is all because we don't CSE, right. We should get on that :)
Patch 1,2 get Reviewed-by: Eric Anholt
Couple more comments below.
> ---
> src/glsl/lower_if_to_cond_assign.cpp | 62 ++---
> 1 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/src/glsl/lower_if_to_cond_assign.cpp
> b/src/glsl/lower_if_to_cond_assign.cpp
> index 5c74bc1..3f82700 100644
> --- a/src/glsl/lower_if_to_cond_assign.cpp
> +++ b/src/glsl/lower_if_to_cond_assign.cpp
> @@ -136,7 +136,6 @@ ir_if_to_cond_assign_visitor::visit_leave(ir_if *ir)
>return visit_continue;
>
> bool found_control_flow = false;
> - ir_variable *cond_var;
> ir_assignment *assign;
> ir_dereference_variable *deref;
>
> @@ -154,31 +153,52 @@ ir_if_to_cond_assign_visitor::visit_leave(ir_if *ir)
>
> void *mem_ctx = ralloc_parent(ir);
>
> - /* Store the condition to a variable so the assignment conditions are
> -* simpler.
> + /* Store the condition to a variable. Move all of the instructions from
> +* the then-clause if the if-statement. Use the condition variable as a
"of the if-statement"
> +* condition for all assignments.
> */
> - cond_var = new(mem_ctx) ir_variable(glsl_type::bool_type,
> -"if_to_cond_assign_condition",
> -ir_var_temporary);
> - ir->insert_before(cond_var);
> -
> - deref = new(mem_ctx) ir_dereference_variable(cond_var);
> - assign = new(mem_ctx) ir_assignment(deref,
> -ir->condition, NULL);
> + ir_variable *const then_var =
> + new(mem_ctx) ir_variable(glsl_type::bool_type,
> +"if_to_cond_assign_then",
> +ir_var_temporary);
> + ir->insert_before(then_var);
> +
> + ir_dereference_variable *then_cond =
> + new(mem_ctx) ir_dereference_variable(then_var);
> +
> + assign = new(mem_ctx) ir_assignment(then_cond, ir->condition);
> ir->insert_before(assign);
>
> - /* Now, move all of the instructions out of the if blocks, putting
> -* conditions on assignments.
> -*/
> - move_block_to_cond_assign(mem_ctx, ir, deref,
> + move_block_to_cond_assign(mem_ctx, ir, then_cond,
>&ir->then_instructions);
>
> - ir_rvalue *inverse =
> - new(mem_ctx) ir_expression(ir_unop_logic_not,
> - glsl_type::bool_type,
> - deref->clone(mem_ctx, NULL),
> - NULL);
> - move_block_to_cond_assign(mem_ctx, ir, inverse, &ir->else_instructions);
> + /* If there are instructions in the else-clause, store the inverse of the
> +* condition to a variable. Move all of the instructions from the
> +* else-clause if the if-statement. Use the (inverse) condition variable
> +* as a condition for all assignments.
> +*/
> + if (!ir->else_instructions.is_empty()) {
> + ir_variable *const else_var =
> + new(mem_ctx) ir_variable(glsl_type::bool_type,
> + "if_to_cond_assign_else",
> + ir_var_temporary);
> + ir->insert_before(else_var);
> +
> + ir_dereference_variable *else_cond =
> + new(mem_ctx) ir_dereference_variable(else_var);
> +
> + ir_rvalue *inverse =
> + new(mem_ctx) ir_expression(ir_unop_logic_not,
> + glsl_type::bool_type,
> + then_cond->clone(mem_ctx, NULL),
> + NULL);
Could drop the bool_type on ir_expression()
> + assign = new(mem_ctx) ir_assignment(else_cond, inverse);
> + ir->insert_before(assign);
> +
> + move_block_to_cond_assign(mem_ctx, ir, else_cond,
> + &ir->else_instructions);
> + }
pgpk4AYMx6hwY.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39588] [bisected] mesa demo xeglgears draw nothing if surface type is a pixmap
https://bugs.freedesktop.org/show_bug.cgi?id=39588 Ian Romanick changed: What|Removed |Added Summary|(regression)mesa demo |[bisected] mesa demo |progs/egl/opengl/xeglgears |xeglgears draw nothing if |draw nothing if surface |surface type is a pixmap |type is | |GEARS_PIXMAP,GEARS_PIXMAP_T | |EXTURE | Keywords|NEEDINFO| Component|Drivers/DRI/i915|Other AssignedTo|i...@freedesktop.org |mesa-dev@lists.freedesktop. ||org CC||i...@freedesktop.org --- Comment #4 from Ian Romanick 2011-08-02 19:22:08 PDT --- I've bisected this to: commit 87dde5b1cd596c4008695ff2db9469f88c09f925 Author: Benjamin Franzke Date: Wed Feb 9 15:30:20 2011 +0100 egl_dri2: Use double buffering for window surfaces We really should have piglit tests for drawing to pixmaps and pbuffers. Simple tests that just draw a single triangle should be sufficient. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 3/3] glsl: Perform implicit type conversions on function call out parameters.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/02/2011 05:38 PM, Paul Berry wrote:
> When an out parameter undergoes an implicit type conversion, we need
> to store it in a temporary, and then after the call completes, convert
> the resulting value. In other words, we convert code like the
> following:
>
> void f(out int x);
> float value;
> f(value);
>
> Into IR that's equivalent to this:
>
> void f(out int x);
> float value;
> int x_converted;
> f(x_converted);
> value = float(x_converted);
>
> This transformation needs to happen during ast-to-IR convertion (as
> opposed to, say, a lowering pass), because it is invalid IR for formal
> and actual parameters to have types that don't match.
I want to digest this code a bit more, but I have a couple minor
comments below.
> Fixes piglit tests spec/glsl-1.20/compiler/qualifiers/out-03.vert and
> spec/glsl-1.20/execution/qualifiers/vs-out-{01,02,03}.shader_test, and
> bug 39651.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39651
> ---
> src/glsl/ast_function.cpp | 64 +---
> 1 files changed, 59 insertions(+), 5 deletions(-)
>
> diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
> index 8bcf48d..f945a94 100644
> --- a/src/glsl/ast_function.cpp
> +++ b/src/glsl/ast_function.cpp
> @@ -134,6 +134,8 @@ match_function_by_name(exec_list *instructions, const
> char *name,
>}
> }
>
> + exec_list post_call_conversions;
> +
> if (sig != NULL) {
>/* Verify that 'out' and 'inout' actual parameters are lvalues. This
> * isn't done in ir_function::matching_signature because that function
> @@ -141,6 +143,13 @@ match_function_by_name(exec_list *instructions, const
> char *name,
> *
> * Also, validate that 'const_in' formal parameters (an extension of
> our
> * IR) correspond to ir_constant actual parameters.
> + *
> + * Also, perform implicit conversion of arguments. Note: to
> + * implicitly convert out parameters, we need to place them in a
> + * temporary variable, and do the conversion after the call
> + * takes place. Since we haven't emitted the call yet, we'll
> + * place the post-call conversions in a temporary exec_list, and
> + * emit them later.
It looks like this comment (and the others below) are wrapped to much
less than 80 columns.
> */
>exec_list_iterator actual_iter = actual_parameters->iterator();
>exec_list_iterator formal_iter = sig->parameters.iterator();
> @@ -185,8 +194,50 @@ match_function_by_name(exec_list *instructions, const
> char *name,
>}
>
>if (formal->type->is_numeric() || formal->type->is_boolean()) {
> - ir_rvalue *converted = convert_component(actual, formal->type);
> - actual->replace_with(converted);
> +switch (formal->mode) {
> +case ir_var_in:
> + {
The { should be on the same line as the case, and emacs got the
indentation wonkey because it's not.
> + ir_rvalue *converted
> + = convert_component(actual, formal->type);
> + actual->replace_with(converted);
> + }
> + break;
> +case ir_var_out:
> + if (actual->type != formal->type)
> + {
The { should be on the same line as the if.
> + /* Create a temporary variable to hold the out
> + * parameter. Don't pass a hashtable to clone()
> + * because we don't want this temporary variable to
> + * be in scope.
> + */
> + ir_variable *tmp = formal->clone(ctx, NULL);
> + tmp->mode = ir_var_auto;
ir_var_auto is only used for user-defined variables, and
ir_var_temporary is used for compiler-generated variables. We'd also
usually do something like:
ir_variable *tmp =
new(mem_ctx) ir_variable(formal->type,
"out_parameter_conversion",
ir_var_temporary);
Giving it a name like that makes the origin of the variable clear in
shader dumps. This has proven to be an invaluable debugging tool.
> + instructions->push_tail(tmp);
> + ir_dereference_variable *deref_tmp_1
> + = new(ctx) ir_dereference_variable(tmp);
> + ir_dereference_variable *deref_tmp_2
> + = new(ctx) ir_dereference_variable(tmp);
> + ir_rvalue *converted_tmp
> + = convert_component(deref_tmp_1, actual->type);
> + ir_assignment *assignment
> + = new(ctx) ir_assignment(actual, converted_tmp);
> + post_call_conversions.push_tail(assignment);
> + actual->replace_with(deref_tmp_2);
> + }
> + break;
> +
Re: [Mesa-dev] [PATCH 2/3] glsl: Add validations for ir_call.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/02/2011 05:38 PM, Paul Berry wrote:
> This patch extends ir_validate.cpp to check the following
> characteristics of each ir_call:
>
> - The number of actual parameters must match the number of formal
> parameters in the signature.
>
> - The type of each actual parameter must match the type of the
> corresponding formal parameter in the signature.
>
> - Each "out" or "inout" actual parameter must be an lvalue.
> ---
> src/glsl/ir_validate.cpp | 35 +++
> 1 files changed, 35 insertions(+), 0 deletions(-)
>
> diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
> index f3fceb2..72e4faf 100644
> --- a/src/glsl/ir_validate.cpp
> +++ b/src/glsl/ir_validate.cpp
> @@ -541,7 +541,42 @@ ir_validate::visit_enter(ir_call *ir)
>abort();
> }
>
> + exec_list_iterator formal_param_iter = callee->parameters.iterator();
> + exec_list_iterator actual_param_iter = ir->actual_parameters.iterator();
We stopped making new uses of the iterators a long time ago. As
implemented, they're a giant pile of fail. For what you're trying to do
here, just use node->next and node->is_tail_sentinel(). Note that
is_tail_sentinel tells you if you're at the first "node" *past* the end
of the list.
> + while (true) {
> + if (formal_param_iter.has_next() != actual_param_iter.has_next()) {
> + printf("ir_call has the wrong number of parameters:\n");
> + goto dump_ir;
> + }
> + if (!formal_param_iter.has_next()) {
> + break;
> + }
> + const ir_variable *formal_param
> + = (const ir_variable *) formal_param_iter.get();
> + const ir_rvalue *actual_param
> + = (const ir_rvalue *) actual_param_iter.get();
> + if (formal_param->type != actual_param->type) {
> + printf("ir_call parameter type mismatch:\n");
> + goto dump_ir;
> + }
> + if (formal_param->mode == ir_var_out
> + || formal_param->mode == ir_var_inout) {
> + if (!actual_param->is_lvalue()) {
> +printf("ir_call out/inout parameters must be lvalues:\n");
> +goto dump_ir;
> + }
> + }
> + formal_param_iter.next();
> + actual_param_iter.next();
> + }
> +
> return visit_continue;
> +
> +dump_ir:
> + ir->print();
> + printf("callee:\n");
> + callee->print();
> + abort();
> }
>
> void
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk44oUwACgkQX1gOwKyEAw/o0gCggVpcUJ69HnlMKo2XScpNNd7Z
IHcAn0aA476Sras2dJYHBq08mLc+H/ql
=voyu
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] Revert "glsl: Skip processing the first function's body in do_dead_functions()."
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2011 11:41 AM, Paul Berry wrote: > On 1 August 2011 22:16, Paul Berry wrote: >> >> I will investigate things further in the morning and let you know what I >> find. >> > > Ok, I've spent a while looking through the linker code, and the rabbit > hole goes deeper than I expected. There are a number of reasons why > the linker, as currently implemented, isn't guaranteed to be produce > topologically sorted output: > > 1. Linking doesn't actually start with an empty shader. It starts > with a clone of the compilation unit that defines main() (see > linker.cpp around line 836). This means that the order of functions > defined in that compilation unit will be preserved regardless of the > call graph. > > 2. When resolving a function that's declared in the compilation unit > that defines main(), but defined in some other compilation unit, the > linker inserts the IR for that function wherever the declaration > existed. This means that the order of functions _declared_ in the > compilation unit that defines main will be preserved too. > > Problems 1 and 2 could be addressed by not cloning the IR for the > compilation unit containing main, and instead using the algorithm you > described. But even if we did that, there's an additional problem: > > 3. Linking is performed depth first. This means that if main calls f > which calls h, and main also calls g which calls h, then the linker > first tries to pull in f, then h, and then finally g. Since the > linker emits functions at the head of the final linked program, the > final order (assuming problems 1 and 2 are fixed) would be g, h, f, > main. This is the wrong order because g calls h. > > This problem could be addressed by making the linker operate breadth > first instead of depth first. But even if we did that, there's still > another problem: > > 4. Since the linker emits functions at the head of the final linked > program, if the linker brings in a function (let's call it f()) that > wasn't declared in the compilation unit that defined main, it winds up > at the beginning of the linked output, _before_ any global > declarations. If f() refers to a global variable, then the IR is > invalid, because ir_dereference_variable nodes need to occur _after_ > the variables they declare (see ir_validate.cpp line 96). It seems like it would be worth constructing a test case for this. A piglit test would be preferable. If that's not possible, a unit test would do. There was a similar issue long, long ago, but I believe that it was fixed. I don't recall the details. > This problem could be addressed by having the linker emit functions at > the tail of the final linked program rather than at the head, but that > would defeat the effort to make callees appear before their callers in > the linker output. > > There's one final problem, and this to me is the clincher: > > 5. Since our IR groups together all overloaded functions that share > the same name, there are (admittedly contrived) cases that would be > impossible to topologically sort. For example: if main calls f(int) > which calls g(int), and main also calls g(float) which calls f(float), > this is a valid program (there's no static recursion), but there's no > way to order f and g such that callees come before their respective > callers. > > We could only address this problem by changing our IR format, or > dropping the topological sort requirement. > > In light of everything I've discovered this morning, my recommendation > is to drop the topological sort requirement. I haven't been able to > find any code other than opt_dead_functions that relies on functions > being topologically sorted, so unless I'm missing something, dropping > the requirement is a simple matter of committing this patch. > > In addition, I think we should change link_functions.cpp so that it > emits functions at the tail of the final linked program rather than at > the head, to fix problem #4. > > Does this analysis seem right to you, Ian? Paul, you continue to impress me. Yeah, that all sounds right. I had a hard time believing #1 because I really thought I had implemented the algorithm from my previous post. Of course, the code and commit logs don't lie. I had thought of #5 shortly after hitting send, but I decided it was too contrived to post a follow-up. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk44oCUACgkQX1gOwKyEAw/TbgCfWTFDif+gDJmIwB1uCNn8U92k a6sAn1BYZeJg3ZZE2B2aH2/3HO/sT2tf =eLx4 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] glsl: Emit function signatures at toplevel, even for built-ins.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2011 12:18 PM, Paul Berry wrote: > On 1 August 2011 18:08, Ian Romanick wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 08/01/2011 04:07 PM, Paul Berry wrote: >>> The ast-to-hir conversion needs to emit function signatures in two >>> circumstances: when a function declaration (or definition) is >>> encountered, and when a built-in function is encountered. >>> >>> To avoid emitting a function signature in an illegal place (such as >>> inside a function), emit_function() checked whether we were inside a >>> function definition, and if so, emitted the signature before the >>> function definition. >>> >>> However, this didn't cover the case of emitting function signatures >>> for built-in functions when those built-in functions are called from >>> global scope (e.g. a built-in function called from inside the constant >>> integer expression that specifies the length of an array). >>> >>> This patch changes emit_function() so that it emits function >>> signatures at toplevel in all cases. >> >> There's something about this patch that I don't grok. The >> state->current_function test in emit function exists specifically to >> handle calls to functions (built-in or otherwise) at global scope. >> Without that, code such as the snippet below would not work, and text in >> the commit log seems to indicate that it shouldn't work. However, I >> verified that it does. >> >> #version 120 >> const float x = cos(3.14159 / 2.0); > > I'm confused. Do you mean to say that you didn't expect the above > code to work before applying this patch, or you didn't expect the > above code to work after applying this patch? I'm saying that it does work, and it is supposed to work. Your commit message implies that it does not work before the patch. > Before applying this patch, the above code works because when > processing a global initializer, we are emitting IR at toplevel scope. > Since state->current_function is NULL, emit_function() just emits the > declaration in place, which is fine because function declarations are > allowed at toplevel scope. > > After applying this patch, the above code still works because > emit_function() always emits the declaration at toplevel scope. > > The case this patch is designed to fix is when a built-in function is > called from inside the constant integer expression that specifies the > length of an array, e.g.: > > #version 120 > float x[cos(3.14159/2.0) < 0.5 ? 1 : 2]; > > This case fails before the patch, because when processing an array > length, we are emitting IR into a dummy exec_list (see > process_array_type() in ast_to_hir.cpp). process_array_type() later > checks (via an assertion) that no instructions were emitted to the > dummy exec_list, based on the reasonable assumption that we shouldn't > need to emit instructions to calculate the value of a constant. This This is the bit of text that should be in the commit message. :) Now it makes sense. The bit about the dummy exec_list is the important part... that people familiar with the code may have forgotten. > is the crux of bug 38625, which is the bug I'm trying to fix in this > patch series. > > After applying this patch, the situation is improved, but the bug > still isn't fixed. In addition to this change, we need to avoid > emitting a function call when constant-folding a builtin function. > That's the subject of the next patch in the series. I should have > made this clearer in the commit message. I'll update it to clarify. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk44nhsACgkQX1gOwKyEAw/l6ACfaBeNcJLpoWi1ZDthKrL46OHa Re8AnRGplb1Pz0D2dN26CKTcMYz+3OR6 =c4uK -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] glsl: Modify strategy for accumulating conditions when lowering if-statements
From: Ian Romanick
Previously if-statements were lowered from inner-most to outer-most
(i.e., bottom-up). All assignments within an if-statement would have
the condition of the if-statement appended to its existing condition.
As a result the assignments from a deeply nested if-statement would
have a very long and complex condition.
Several shaders in the OpenGL ES2 conformance test suite contain
non-constant array indexing that has been lowered by the shader
writer. These tests usually look something like:
if (i == 0) {
value = array[0];
} else if (i == 1) {
value = array[1];
} else ...
The IR for the last assignment ends up as:
(assign (expression bool && (expression bool ! (var_ref
if_to_cond_assign_condition) ) (expression bool && (expression bool ! (var_ref
if_to_cond_assign_condition@20) ) (expression bool && (expression bool !
(var_ref if_to_cond_assign_condition@22) ) (expression bool && (expression bool
! (var_ref if_to_cond_assign_condition@24) ) (var_ref
if_to_cond_assign_condition@26) ) ) ) ) (x) (var_ref value) (array_ref
(var_ref array) (constant int (5)))
The Mesa IR that is generated from this is just as awesome as you
might expect.
The strategy for lowering nested if-statements is changed slightly.
When an if-statement is lowered, it's condition is added to a
hash-table. When lowering an if-statement and an assignment is
encountered with an existing condition, the hash-table is checked for
that condition. If the condition is in the hash-table, the condition
is not modified.
When an assignment to a condition in the hash-table is encountered, an
extra unconditional assignment of false is added to the IR and the new
condition is added to the assignment. This ensures that a condition
in a nested if-statement is only set to true if the condition in the
enclosing if-statement was also true.
Before this change, one of the shaders in the OpenGL ES2 conformance
test suite's acos_float_frag_xvary generated 348 Mesa IR instructions.
After this change it only generates 124.
---
src/glsl/lower_if_to_cond_assign.cpp | 66 --
1 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/src/glsl/lower_if_to_cond_assign.cpp
b/src/glsl/lower_if_to_cond_assign.cpp
index 3f82700..ff3aba0 100644
--- a/src/glsl/lower_if_to_cond_assign.cpp
+++ b/src/glsl/lower_if_to_cond_assign.cpp
@@ -47,6 +47,7 @@
#include "glsl_types.h"
#include "ir.h"
+#include "program/hash_table.h"
class ir_if_to_cond_assign_visitor : public ir_hierarchical_visitor {
public:
@@ -55,6 +56,14 @@ public:
this->progress = false;
this->max_depth = max_depth;
this->depth = 0;
+
+ this->condition_variables = hash_table_ctor(0, hash_table_pointer_hash,
+ hash_table_pointer_compare);
+ }
+
+ ~ir_if_to_cond_assign_visitor()
+ {
+ hash_table_dtor(this->condition_variables);
}
ir_visitor_status visit_enter(ir_if *);
@@ -63,6 +72,8 @@ public:
bool progress;
unsigned max_depth;
unsigned depth;
+
+ struct hash_table *condition_variables;
};
bool
@@ -95,7 +106,8 @@ check_control_flow(ir_instruction *ir, void *data)
void
move_block_to_cond_assign(void *mem_ctx,
ir_if *if_ir, ir_rvalue *cond_expr,
- exec_list *instructions)
+ exec_list *instructions,
+ struct hash_table *ht)
{
foreach_list_safe(node, instructions) {
ir_instruction *ir = (ir_instruction *) node;
@@ -103,14 +115,33 @@ move_block_to_cond_assign(void *mem_ctx,
if (ir->ir_type == ir_type_assignment) {
ir_assignment *assign = (ir_assignment *)ir;
-if (!assign->condition) {
- assign->condition = cond_expr->clone(mem_ctx, NULL);
-} else {
- assign->condition =
- new(mem_ctx) ir_expression(ir_binop_logic_and,
- glsl_type::bool_type,
- cond_expr->clone(mem_ctx, NULL),
- assign->condition);
+if (hash_table_find(ht, assign) == NULL) {
+ hash_table_insert(ht, assign, assign);
+
+ /* If the LHS of the assignment is a condition variable that was
+* previously added, insert an additional assignment of false to
+* the variable.
+*/
+ const bool assign_to_cv =
+ hash_table_find(ht, assign->lhs->variable_referenced()) != NULL;
+
+ if (!assign->condition) {
+ if (assign_to_cv) {
+ assign->rhs =
+new(mem_ctx) ir_expression(ir_binop_logic_and,
+ glsl_type::bool_type,
+ cond_expr->clone(mem_ctx, NULL),
+ assign->rhs);
+
[Mesa-dev] [PATCH 3/4] glsl: Slight change to the code generated by if-flattening
From: Ian Romanick
Now the condition (for the then-clause) and the inverse condition (for
the else-clause) get written to sepearate temporary variables. In the
presense of complex conditions, this may result in more code being
generated.
---
src/glsl/lower_if_to_cond_assign.cpp | 62 ++---
1 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/src/glsl/lower_if_to_cond_assign.cpp
b/src/glsl/lower_if_to_cond_assign.cpp
index 5c74bc1..3f82700 100644
--- a/src/glsl/lower_if_to_cond_assign.cpp
+++ b/src/glsl/lower_if_to_cond_assign.cpp
@@ -136,7 +136,6 @@ ir_if_to_cond_assign_visitor::visit_leave(ir_if *ir)
return visit_continue;
bool found_control_flow = false;
- ir_variable *cond_var;
ir_assignment *assign;
ir_dereference_variable *deref;
@@ -154,31 +153,52 @@ ir_if_to_cond_assign_visitor::visit_leave(ir_if *ir)
void *mem_ctx = ralloc_parent(ir);
- /* Store the condition to a variable so the assignment conditions are
-* simpler.
+ /* Store the condition to a variable. Move all of the instructions from
+* the then-clause if the if-statement. Use the condition variable as a
+* condition for all assignments.
*/
- cond_var = new(mem_ctx) ir_variable(glsl_type::bool_type,
- "if_to_cond_assign_condition",
- ir_var_temporary);
- ir->insert_before(cond_var);
-
- deref = new(mem_ctx) ir_dereference_variable(cond_var);
- assign = new(mem_ctx) ir_assignment(deref,
- ir->condition, NULL);
+ ir_variable *const then_var =
+ new(mem_ctx) ir_variable(glsl_type::bool_type,
+ "if_to_cond_assign_then",
+ ir_var_temporary);
+ ir->insert_before(then_var);
+
+ ir_dereference_variable *then_cond =
+ new(mem_ctx) ir_dereference_variable(then_var);
+
+ assign = new(mem_ctx) ir_assignment(then_cond, ir->condition);
ir->insert_before(assign);
- /* Now, move all of the instructions out of the if blocks, putting
-* conditions on assignments.
-*/
- move_block_to_cond_assign(mem_ctx, ir, deref,
+ move_block_to_cond_assign(mem_ctx, ir, then_cond,
&ir->then_instructions);
- ir_rvalue *inverse =
- new(mem_ctx) ir_expression(ir_unop_logic_not,
-glsl_type::bool_type,
-deref->clone(mem_ctx, NULL),
-NULL);
- move_block_to_cond_assign(mem_ctx, ir, inverse, &ir->else_instructions);
+ /* If there are instructions in the else-clause, store the inverse of the
+* condition to a variable. Move all of the instructions from the
+* else-clause if the if-statement. Use the (inverse) condition variable
+* as a condition for all assignments.
+*/
+ if (!ir->else_instructions.is_empty()) {
+ ir_variable *const else_var =
+new(mem_ctx) ir_variable(glsl_type::bool_type,
+ "if_to_cond_assign_else",
+ ir_var_temporary);
+ ir->insert_before(else_var);
+
+ ir_dereference_variable *else_cond =
+new(mem_ctx) ir_dereference_variable(else_var);
+
+ ir_rvalue *inverse =
+new(mem_ctx) ir_expression(ir_unop_logic_not,
+ glsl_type::bool_type,
+ then_cond->clone(mem_ctx, NULL),
+ NULL);
+
+ assign = new(mem_ctx) ir_assignment(else_cond, inverse);
+ ir->insert_before(assign);
+
+ move_block_to_cond_assign(mem_ctx, ir, else_cond,
+ &ir->else_instructions);
+ }
ir->remove();
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] glsl: Replace foreach_iter with foreach_list_safe
From: Ian Romanick
---
src/glsl/lower_if_to_cond_assign.cpp |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/lower_if_to_cond_assign.cpp
b/src/glsl/lower_if_to_cond_assign.cpp
index 2d447e0..5c74bc1 100644
--- a/src/glsl/lower_if_to_cond_assign.cpp
+++ b/src/glsl/lower_if_to_cond_assign.cpp
@@ -97,8 +97,8 @@ move_block_to_cond_assign(void *mem_ctx,
ir_if *if_ir, ir_rvalue *cond_expr,
exec_list *instructions)
{
- foreach_iter(exec_list_iterator, iter, *instructions) {
- ir_instruction *ir = (ir_instruction *)iter.get();
+ foreach_list_safe(node, instructions) {
+ ir_instruction *ir = (ir_instruction *) node;
if (ir->ir_type == ir_type_assignment) {
ir_assignment *assign = (ir_assignment *)ir;
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] glsl: Make move_block_to_cond_assign not care which branch it's processing
From: Ian Romanick
This will make some future changes a bit easier to digest.
---
src/glsl/lower_if_to_cond_assign.cpp | 44 +
1 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/src/glsl/lower_if_to_cond_assign.cpp
b/src/glsl/lower_if_to_cond_assign.cpp
index b637eb4..2d447e0 100644
--- a/src/glsl/lower_if_to_cond_assign.cpp
+++ b/src/glsl/lower_if_to_cond_assign.cpp
@@ -94,40 +94,23 @@ check_control_flow(ir_instruction *ir, void *data)
void
move_block_to_cond_assign(void *mem_ctx,
- ir_if *if_ir, ir_variable *cond_var, bool then)
+ ir_if *if_ir, ir_rvalue *cond_expr,
+ exec_list *instructions)
{
- exec_list *instructions;
-
- if (then) {
- instructions = &if_ir->then_instructions;
- } else {
- instructions = &if_ir->else_instructions;
- }
-
foreach_iter(exec_list_iterator, iter, *instructions) {
ir_instruction *ir = (ir_instruction *)iter.get();
if (ir->ir_type == ir_type_assignment) {
ir_assignment *assign = (ir_assignment *)ir;
-ir_rvalue *cond_expr;
-ir_dereference *deref = new(mem_ctx) ir_dereference_variable(cond_var);
-
-if (then) {
- cond_expr = deref;
-} else {
- cond_expr = new(mem_ctx) ir_expression(ir_unop_logic_not,
- glsl_type::bool_type,
- deref,
- NULL);
-}
if (!assign->condition) {
- assign->condition = cond_expr;
+ assign->condition = cond_expr->clone(mem_ctx, NULL);
} else {
- assign->condition = new(mem_ctx) ir_expression(ir_binop_logic_and,
- glsl_type::bool_type,
- cond_expr,
- assign->condition);
+ assign->condition =
+ new(mem_ctx) ir_expression(ir_binop_logic_and,
+ glsl_type::bool_type,
+ cond_expr->clone(mem_ctx, NULL),
+ assign->condition);
}
}
@@ -187,8 +170,15 @@ ir_if_to_cond_assign_visitor::visit_leave(ir_if *ir)
/* Now, move all of the instructions out of the if blocks, putting
* conditions on assignments.
*/
- move_block_to_cond_assign(mem_ctx, ir, cond_var, true);
- move_block_to_cond_assign(mem_ctx, ir, cond_var, false);
+ move_block_to_cond_assign(mem_ctx, ir, deref,
+&ir->then_instructions);
+
+ ir_rvalue *inverse =
+ new(mem_ctx) ir_expression(ir_unop_logic_not,
+glsl_type::bool_type,
+deref->clone(mem_ctx, NULL),
+NULL);
+ move_block_to_cond_assign(mem_ctx, ir, inverse, &ir->else_instructions);
ir->remove();
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] glsl: Perform implicit type conversions on function call out parameters.
When an out parameter undergoes an implicit type conversion, we need
to store it in a temporary, and then after the call completes, convert
the resulting value. In other words, we convert code like the
following:
void f(out int x);
float value;
f(value);
Into IR that's equivalent to this:
void f(out int x);
float value;
int x_converted;
f(x_converted);
value = float(x_converted);
This transformation needs to happen during ast-to-IR convertion (as
opposed to, say, a lowering pass), because it is invalid IR for formal
and actual parameters to have types that don't match.
Fixes piglit tests spec/glsl-1.20/compiler/qualifiers/out-03.vert and
spec/glsl-1.20/execution/qualifiers/vs-out-{01,02,03}.shader_test, and
bug 39651.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39651
---
src/glsl/ast_function.cpp | 64 +---
1 files changed, 59 insertions(+), 5 deletions(-)
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index 8bcf48d..f945a94 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -134,6 +134,8 @@ match_function_by_name(exec_list *instructions, const char
*name,
}
}
+ exec_list post_call_conversions;
+
if (sig != NULL) {
/* Verify that 'out' and 'inout' actual parameters are lvalues. This
* isn't done in ir_function::matching_signature because that function
@@ -141,6 +143,13 @@ match_function_by_name(exec_list *instructions, const char
*name,
*
* Also, validate that 'const_in' formal parameters (an extension of our
* IR) correspond to ir_constant actual parameters.
+ *
+ * Also, perform implicit conversion of arguments. Note: to
+ * implicitly convert out parameters, we need to place them in a
+ * temporary variable, and do the conversion after the call
+ * takes place. Since we haven't emitted the call yet, we'll
+ * place the post-call conversions in a temporary exec_list, and
+ * emit them later.
*/
exec_list_iterator actual_iter = actual_parameters->iterator();
exec_list_iterator formal_iter = sig->parameters.iterator();
@@ -185,8 +194,50 @@ match_function_by_name(exec_list *instructions, const char
*name,
}
if (formal->type->is_numeric() || formal->type->is_boolean()) {
- ir_rvalue *converted = convert_component(actual, formal->type);
- actual->replace_with(converted);
+switch (formal->mode) {
+case ir_var_in:
+ {
+ ir_rvalue *converted
+ = convert_component(actual, formal->type);
+ actual->replace_with(converted);
+ }
+ break;
+case ir_var_out:
+ if (actual->type != formal->type)
+ {
+ /* Create a temporary variable to hold the out
+ * parameter. Don't pass a hashtable to clone()
+ * because we don't want this temporary variable to
+ * be in scope.
+ */
+ ir_variable *tmp = formal->clone(ctx, NULL);
+ tmp->mode = ir_var_auto;
+ instructions->push_tail(tmp);
+ ir_dereference_variable *deref_tmp_1
+ = new(ctx) ir_dereference_variable(tmp);
+ ir_dereference_variable *deref_tmp_2
+ = new(ctx) ir_dereference_variable(tmp);
+ ir_rvalue *converted_tmp
+ = convert_component(deref_tmp_1, actual->type);
+ ir_assignment *assignment
+ = new(ctx) ir_assignment(actual, converted_tmp);
+ post_call_conversions.push_tail(assignment);
+ actual->replace_with(deref_tmp_2);
+ }
+ break;
+case ir_var_inout:
+ /* Inout parameters should never require conversion,
+* since that would require an implicit conversion to
+* exist both to and from the formal parameter type,
+* and there are no bidirectional implicit
+* conversions.
+*/
+ assert (actual->type == formal->type);
+ break;
+default:
+ assert (!"Illegal formal parameter mode");
+ break;
+}
}
actual_iter.next();
@@ -196,11 +247,13 @@ match_function_by_name(exec_list *instructions, const
char *name,
/* Always insert the call in the instruction stream, and return a deref
* of its return val if it returns a value, since we don't know if
* the rvalue is going to be assigned to anything or not.
+ *
+ * Also insert any out parameter conversions after the call.
*/
ir_call *call = new(ctx) ir_call(sig, actual_parameters);
+ ir_dereference_variable *deref;
[Mesa-dev] [PATCH 2/3] glsl: Add validations for ir_call.
This patch extends ir_validate.cpp to check the following
characteristics of each ir_call:
- The number of actual parameters must match the number of formal
parameters in the signature.
- The type of each actual parameter must match the type of the
corresponding formal parameter in the signature.
- Each "out" or "inout" actual parameter must be an lvalue.
---
src/glsl/ir_validate.cpp | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
index f3fceb2..72e4faf 100644
--- a/src/glsl/ir_validate.cpp
+++ b/src/glsl/ir_validate.cpp
@@ -541,7 +541,42 @@ ir_validate::visit_enter(ir_call *ir)
abort();
}
+ exec_list_iterator formal_param_iter = callee->parameters.iterator();
+ exec_list_iterator actual_param_iter = ir->actual_parameters.iterator();
+ while (true) {
+ if (formal_param_iter.has_next() != actual_param_iter.has_next()) {
+ printf("ir_call has the wrong number of parameters:\n");
+ goto dump_ir;
+ }
+ if (!formal_param_iter.has_next()) {
+ break;
+ }
+ const ir_variable *formal_param
+ = (const ir_variable *) formal_param_iter.get();
+ const ir_rvalue *actual_param
+ = (const ir_rvalue *) actual_param_iter.get();
+ if (formal_param->type != actual_param->type) {
+ printf("ir_call parameter type mismatch:\n");
+ goto dump_ir;
+ }
+ if (formal_param->mode == ir_var_out
+ || formal_param->mode == ir_var_inout) {
+ if (!actual_param->is_lvalue()) {
+printf("ir_call out/inout parameters must be lvalues:\n");
+goto dump_ir;
+ }
+ }
+ formal_param_iter.next();
+ actual_param_iter.next();
+ }
+
return visit_continue;
+
+dump_ir:
+ ir->print();
+ printf("callee:\n");
+ callee->print();
+ abort();
}
void
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] glsl: Make is_lvalue() and variable_referenced() const.
These functions don't modify the target instruction, so it makes sense
to make them const. This allows these functions to be called from ir
validation code (which uses const to ensure that it doesn't
accidentally modify the IR being validated).
---
src/glsl/ir.cpp |4 ++--
src/glsl/ir.h | 18 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 827fe8e..6f8676e 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1096,7 +1096,7 @@ ir_dereference_record::ir_dereference_record(ir_variable
*var,
}
bool
-ir_dereference::is_lvalue()
+ir_dereference::is_lvalue() const
{
ir_variable *var = this->variable_referenced();
@@ -1310,7 +1310,7 @@ ir_swizzle::create(ir_rvalue *val, const char *str,
unsigned vector_length)
#undef I
ir_variable *
-ir_swizzle::variable_referenced()
+ir_swizzle::variable_referenced() const
{
return this->val->variable_referenced();
}
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 50a9d6e..04fa97b 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -144,7 +144,7 @@ public:
ir_rvalue *as_rvalue_to_saturate();
- virtual bool is_lvalue()
+ virtual bool is_lvalue() const
{
return false;
}
@@ -152,7 +152,7 @@ public:
/**
* Get the variable that is ultimately referenced by an r-value
*/
- virtual ir_variable *variable_referenced()
+ virtual ir_variable *variable_referenced() const
{
return NULL;
}
@@ -1355,7 +1355,7 @@ public:
virtual ir_visitor_status accept(ir_hierarchical_visitor *);
- bool is_lvalue()
+ bool is_lvalue() const
{
return val->is_lvalue() && !mask.has_duplicates;
}
@@ -1363,7 +1363,7 @@ public:
/**
* Get the variable that is ultimately referenced by an r-value
*/
- virtual ir_variable *variable_referenced();
+ virtual ir_variable *variable_referenced() const;
ir_rvalue *val;
ir_swizzle_mask mask;
@@ -1387,12 +1387,12 @@ public:
return this;
}
- bool is_lvalue();
+ bool is_lvalue() const;
/**
* Get the variable that is ultimately referenced by an r-value
*/
- virtual ir_variable *variable_referenced() = 0;
+ virtual ir_variable *variable_referenced() const = 0;
};
@@ -1413,7 +1413,7 @@ public:
/**
* Get the variable that is ultimately referenced by an r-value
*/
- virtual ir_variable *variable_referenced()
+ virtual ir_variable *variable_referenced() const
{
return this->var;
}
@@ -1462,7 +1462,7 @@ public:
/**
* Get the variable that is ultimately referenced by an r-value
*/
- virtual ir_variable *variable_referenced()
+ virtual ir_variable *variable_referenced() const
{
return this->array->variable_referenced();
}
@@ -1496,7 +1496,7 @@ public:
/**
* Get the variable that is ultimately referenced by an r-value
*/
- virtual ir_variable *variable_referenced()
+ virtual ir_variable *variable_referenced() const
{
return this->record->variable_referenced();
}
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] A problem in commit be7407b75b12c70e1925c10117937ae2b9e6711f
Thanks. I'll fix that in a minute. Marek On Wed, Aug 3, 2011 at 12:45 AM, Gustaw Smolarczyk wrote: > I found (presumably) a bug in commit > be7407b75b12c70e1925c10117937ae2b9e6711f of mesa master. > > The function util_format_swizzle_4f() does not handle > UTIL_FORMAT_SWIZZLE_W. The "<" should be replaced by "<=". > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] A problem in commit be7407b75b12c70e1925c10117937ae2b9e6711f
I found (presumably) a bug in commit be7407b75b12c70e1925c10117937ae2b9e6711f of mesa master. The function util_format_swizzle_4f() does not handle UTIL_FORMAT_SWIZZLE_W. The "<" should be replaced by "<=". ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL->TGSI translator, part 2
On 08/02/2011 11:27 AM, Brian Paul wrote: > On 08/01/2011 12:38 PM, Bryan Cain wrote: >> Since Mesa 7.11 is released now, I figure it's time to discuss merging >> the glsl-to-tgsi branch to master again. The translator is more mature >> than last time. There are no regressions that I know of on any driver. >> The code generation has improved so that it's the same as or better than >> ir_to_mesa in almost every case. >> >> It also will still emit TGSI integer opcodes if you change >> ctx->GLSLVersion from 120 to 130 in st_extensions.c. Driver developers >> can use this to implement these opcodes in their drivers, since they >> will be needed for GLSL 1.30 eventually. >> >> Are there any objections to merging it to master now? If there aren't, >> I'll revise some of the commit messages for correctness and wrap long >> lines since cgit doesn't do that automatically, then merge it after >> getting approval. > > Sounds OK to me. > > I was just skimming over the new stuff - it looks like > create_color_map_texture() is duplicated in two files and could be > shared. > > -Brian Yes, where should the function go and what header should it be declared in? It appears to me that none of the functions in st_atom_*.c are declared directly in header files. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5] r600g: use backend mask for occlusion queries
Use backend_map kernel query if supported, otherwise analyze ZPASS_DONE
results to get the mask.
Fixes lockups with predicated rendering due to incorrect query buffer
initialization on some cards.
Signed-off-by: Vadim Girlin
---
Updated with r600_bo_offset removal.
src/gallium/drivers/r600/r600.h|4 +
src/gallium/winsys/r600/drm/evergreen_hw_context.c |2 +
src/gallium/winsys/r600/drm/r600_drm.c | 59
src/gallium/winsys/r600/drm/r600_hw_context.c | 96 +++-
src/gallium/winsys/r600/drm/r600_priv.h|3 +
5 files changed, 160 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index 2e759c7..2ac5ed4 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -94,6 +94,8 @@ struct r600_tiling_info *r600_get_tiling_info(struct radeon
*radeon);
unsigned r600_get_clock_crystal_freq(struct radeon *radeon);
unsigned r600_get_minor_version(struct radeon *radeon);
unsigned r600_get_num_backends(struct radeon *radeon);
+unsigned r600_get_num_tile_pipes(struct radeon *radeon);
+unsigned r600_get_backend_map(struct radeon *radeon);
/* r600_bo.c */
struct r600_bo;
@@ -258,6 +260,7 @@ struct r600_context {
u32 *pm4;
struct list_headquery_list;
unsignednum_query_running;
+ unsignedbackend_mask;
struct list_headfenced_bo;
unsignedmax_db; /* for OQ */
unsignednum_dest_buffers;
@@ -279,6 +282,7 @@ struct r600_draw {
struct r600_bo *indices;
};
+void r600_get_backend_mask(struct r600_context *ctx);
int r600_context_init(struct r600_context *ctx, struct radeon *radeon);
void r600_context_fini(struct r600_context *ctx);
void r600_context_pipe_state_set(struct r600_context *ctx, struct
r600_pipe_state *state);
diff --git a/src/gallium/winsys/r600/drm/evergreen_hw_context.c
b/src/gallium/winsys/r600/drm/evergreen_hw_context.c
index 98283ff..7fe2050 100644
--- a/src/gallium/winsys/r600/drm/evergreen_hw_context.c
+++ b/src/gallium/winsys/r600/drm/evergreen_hw_context.c
@@ -1018,6 +1018,8 @@ int evergreen_context_init(struct r600_context *ctx,
struct radeon *radeon)
LIST_INITHEAD(&ctx->fenced_bo);
+ r600_get_backend_mask(ctx);
+
return 0;
out_err:
r600_context_fini(ctx);
diff --git a/src/gallium/winsys/r600/drm/r600_drm.c
b/src/gallium/winsys/r600/drm/r600_drm.c
index ab0afea..8aa8c3d 100644
--- a/src/gallium/winsys/r600/drm/r600_drm.c
+++ b/src/gallium/winsys/r600/drm/r600_drm.c
@@ -50,6 +50,14 @@
#define RADEON_INFO_NUM_BACKENDS 0xa
#endif
+#ifndef RADEON_INFO_NUM_TILE_PIPES
+#define RADEON_INFO_NUM_TILE_PIPES 0xb
+#endif
+
+#ifndef RADEON_INFO_BACKEND_MAP
+#define RADEON_INFO_BACKEND_MAP 0xd
+#endif
+
enum radeon_family r600_get_family(struct radeon *r600)
{
return r600->family;
@@ -75,6 +83,16 @@ unsigned r600_get_num_backends(struct radeon *radeon)
return radeon->num_backends;
}
+unsigned r600_get_num_tile_pipes(struct radeon *radeon)
+{
+ return radeon->num_tile_pipes;
+}
+
+unsigned r600_get_backend_map(struct radeon *radeon)
+{
+ return radeon->backend_map;
+}
+
unsigned r600_get_minor_version(struct radeon *radeon)
{
return radeon->minor_version;
@@ -241,6 +259,42 @@ static int radeon_get_num_backends(struct radeon *radeon)
return 0;
}
+static int radeon_get_num_tile_pipes(struct radeon *radeon)
+{
+ struct drm_radeon_info info = {};
+ uint32_t num_tile_pipes = 0;
+ int r;
+
+ info.request = RADEON_INFO_NUM_TILE_PIPES;
+ info.value = (uintptr_t)&num_tile_pipes;
+ r = drmCommandWriteRead(radeon->fd, DRM_RADEON_INFO, &info,
+ sizeof(struct drm_radeon_info));
+ if (r)
+ return r;
+
+ radeon->num_tile_pipes = num_tile_pipes;
+ return 0;
+}
+
+static int radeon_get_backend_map(struct radeon *radeon)
+{
+ struct drm_radeon_info info = {};
+ uint32_t backend_map = 0;
+ int r;
+
+ info.request = RADEON_INFO_BACKEND_MAP;
+ info.value = (uintptr_t)&backend_map;
+ r = drmCommandWriteRead(radeon->fd, DRM_RADEON_INFO, &info,
+ sizeof(struct drm_radeon_info));
+ if (r)
+ return r;
+
+ radeon->backend_map = backend_map;
+ radeon->backend_map_valid = TRUE;
+
+ return 0;
+}
+
static int radeon_init_fence(struct radeon *radeon)
{
@@ -362,6 +416,11 @@ static struct radeon *radeon_new(int fd, unsigned device)
if (radeon->minor_version >= 9)
radeon_get_num_backends(radeon);
+ if (radeon->minor_version >= 11) {
+ radeon_get_num_tile_pipes(radeon);
+ radeon_get_backend_map(radeon);
+ }
+
radeon->bomgr = r600_bomgr_create(radeon, 100
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
> On 08/02/2011 07:20 PM, Roland Scheidegger wrote: > > Since noone else chimed in and said it's not a good idea I won't > > hold you up :-). > > I'd like to see a little more documentation though what it can > > (e.g. depth "resolve" especially what it actually should do) and > > can't do in context.rst. Speaking of what it can't do since you > > built this for framebuffer_blit how do you specify the filtering, > > especially since depth/stencil presumably only will do nearest, > > but you want to be able to do color with linear (though you should > > be able to do nearest as well?). If that's implied somehow it > > needs to be mentioned somewhere. > > Right, I'll improve the documentation. > > As for filtering, depth/stencil always implies nearest (will mention > that). > > For colour, GL spec (for D3D it's clear anyway) states "if the source > and destination dimensions are identical, no filtering is applied." - > That condition holds for unextended (non-scaled) multisample resolve > and > seems to make the filter parameter non-applicable. > Instead, just the line "converted to a single sample" (however well > you > can I suppose) applies. > The nv blob seems to agree, the results of resolve with NEAREST and > LINEAR look equal with it. > > For scaled resolve, the filter parameter *must* be either > SCALED_RESOLVE_FASTEST_EXT or SCALED_RESOLVE_NICEST_EXT (others are > not > allowed), the interpretation of which is more or less up to the > driver. > So, we could add a niceness hint to the resolve info, but it's not > strictly necessary. Ah strange. So for unscaled you use NEAREST or LINEAR but it doesn't matter one bit. And for some reason (why?) NEAREST is not allowed for scaled color resolve. I agree in this case an additional parameter probably isn't needed. Just more specific documentation. > > > Also, I'm not sure if it wouldn't be nicer to specify all the > > "scaling" parameters in the destination, instead of some in the > > source (the x/y flips). Not sure though I guess if there's > > precedent somewhere for either way it might be nice to do the same > > but it probably is fine either way. > > > I put the scaling (actually just the flipping) in the source because > I > can directly use dst.xy01 for my scissor rectangle then (which > outlines > the destination region). > > It's really just personal preference, if someone were to use dst.xy01 > for inverted viewport parameters they'd probably prefer flipping in > dst. > > I'm deactivating the viewport transform and flipping the > non-normalized > texture coordinates instead ... > > Visualize a fixed destination region, then that you cut out some > source, > turn it around and stretch it, then sticking it where you want it :-) Yes I don't really have a preference neither. Just if some blit code always does it one way or the another some consistency would be nice. Roland > > > Roland > > > > > >> > >> On 28.07.2011 15:59, Christoph Bumiller wrote: > >>> Resolve via glBlitFramebuffer allows resolving a sub-region of a > >>> renderbuffer to a different location in any mipmap level of some > >>> other texture, and, with a new extension, even scaling. > >>> Therefore, > >>> location and size parameters are needed. > >>> > >>> The mask parameter was added because resolving only depth or only > >>> stencil of a combined buffer is possible as well. > >>> > >>> Full information about the blit operation allows the drivers to > >>> take the most efficient path they possibly can. > >> So, if there are no objections anymore I'm just going to push this > >> small > >> series in a few days ... > >> > >> Since no other drivers implement multisampling at the moment it > >> can't > >> break anything (except maybe closed source state trackers I don't > >> know > >> about). > >> > >>> --- > >>> src/gallium/docs/source/context.rst |7 +-- > >>> src/gallium/include/pipe/p_context.h |8 +++- > >>> src/gallium/include/pipe/p_defines.h |4 > >>> src/gallium/include/pipe/p_state.h | 28 > >>> > >>> 4 files changed, 40 insertions(+), 7 deletions(-) > >>> > >>> diff --git a/src/gallium/docs/source/context.rst > >>> b/src/gallium/docs/source/context.rst > >>> index 25a3245..7968f03 100644 > >>> --- a/src/gallium/docs/source/context.rst > >>> +++ b/src/gallium/docs/source/context.rst > >>> @@ -329,8 +329,11 @@ textured quad blitter.. The source and > >>> destination may be the same resource, > >>> but overlapping blits are not permitted. > >>> > >>> ``resource_resolve`` resolves a multisampled resource into a > >>> non-multisampled > >>> -one. Formats and dimensions must match. This function must be > >>> present if a driver > >>> -supports multisampling. > >>> +one. Formats must match, and, if PIPE_CAP_SCALED_RESOLVE is not > >>> supported, > >>> +dimensions as well. > >>> +The source and destination resources and coordinates are > >>> described > >>> +by ``pipe_resolve_info``. > >>> +This functi
Re: [Mesa-dev] [PATCH 2/4] glsl: Emit function signatures at toplevel, even for built-ins.
On 1 August 2011 18:08, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/01/2011 04:07 PM, Paul Berry wrote: >> The ast-to-hir conversion needs to emit function signatures in two >> circumstances: when a function declaration (or definition) is >> encountered, and when a built-in function is encountered. >> >> To avoid emitting a function signature in an illegal place (such as >> inside a function), emit_function() checked whether we were inside a >> function definition, and if so, emitted the signature before the >> function definition. >> >> However, this didn't cover the case of emitting function signatures >> for built-in functions when those built-in functions are called from >> global scope (e.g. a built-in function called from inside the constant >> integer expression that specifies the length of an array). >> >> This patch changes emit_function() so that it emits function >> signatures at toplevel in all cases. > > There's something about this patch that I don't grok. The > state->current_function test in emit function exists specifically to > handle calls to functions (built-in or otherwise) at global scope. > Without that, code such as the snippet below would not work, and text in > the commit log seems to indicate that it shouldn't work. However, I > verified that it does. > > #version 120 > const float x = cos(3.14159 / 2.0); I'm confused. Do you mean to say that you didn't expect the above code to work before applying this patch, or you didn't expect the above code to work after applying this patch? Before applying this patch, the above code works because when processing a global initializer, we are emitting IR at toplevel scope. Since state->current_function is NULL, emit_function() just emits the declaration in place, which is fine because function declarations are allowed at toplevel scope. After applying this patch, the above code still works because emit_function() always emits the declaration at toplevel scope. The case this patch is designed to fix is when a built-in function is called from inside the constant integer expression that specifies the length of an array, e.g.: #version 120 float x[cos(3.14159/2.0) < 0.5 ? 1 : 2]; This case fails before the patch, because when processing an array length, we are emitting IR into a dummy exec_list (see process_array_type() in ast_to_hir.cpp). process_array_type() later checks (via an assertion) that no instructions were emitted to the dummy exec_list, based on the reasonable assumption that we shouldn't need to emit instructions to calculate the value of a constant. This is the crux of bug 38625, which is the bug I'm trying to fix in this patch series. After applying this patch, the situation is improved, but the bug still isn't fixed. In addition to this change, we need to avoid emitting a function call when constant-folding a builtin function. That's the subject of the next patch in the series. I should have made this clearer in the commit message. I'll update it to clarify. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
On 08/02/2011 07:20 PM, Roland Scheidegger wrote: > Since noone else chimed in and said it's not a good idea I won't hold you up > :-). > I'd like to see a little more documentation though what it can (e.g. depth > "resolve" especially what it actually should do) and can't do in context.rst. > Speaking of what it can't do since you built this for framebuffer_blit how do > you specify the filtering, especially since depth/stencil presumably only > will do nearest, but you want to be able to do color with linear (though you > should be able to do nearest as well?). If that's implied somehow it needs to > be mentioned somewhere. Right, I'll improve the documentation. As for filtering, depth/stencil always implies nearest (will mention that). For colour, GL spec (for D3D it's clear anyway) states "if the source and destination dimensions are identical, no filtering is applied." - That condition holds for unextended (non-scaled) multisample resolve and seems to make the filter parameter non-applicable. Instead, just the line "converted to a single sample" (however well you can I suppose) applies. The nv blob seems to agree, the results of resolve with NEAREST and LINEAR look equal with it. For scaled resolve, the filter parameter *must* be either SCALED_RESOLVE_FASTEST_EXT or SCALED_RESOLVE_NICEST_EXT (others are not allowed), the interpretation of which is more or less up to the driver. So, we could add a niceness hint to the resolve info, but it's not strictly necessary. > Also, I'm not sure if it wouldn't be nicer to specify all the "scaling" > parameters in the destination, instead of some in the source (the x/y flips). > Not sure though I guess if there's precedent somewhere for either way it > might be nice to do the same but it probably is fine either way. > I put the scaling (actually just the flipping) in the source because I can directly use dst.xy01 for my scissor rectangle then (which outlines the destination region). It's really just personal preference, if someone were to use dst.xy01 for inverted viewport parameters they'd probably prefer flipping in dst. I'm deactivating the viewport transform and flipping the non-normalized texture coordinates instead ... Visualize a fixed destination region, then that you cut out some source, turn it around and stretch it, then sticking it where you want it :-) > Roland > > >> >> On 28.07.2011 15:59, Christoph Bumiller wrote: >>> Resolve via glBlitFramebuffer allows resolving a sub-region of a >>> renderbuffer to a different location in any mipmap level of some >>> other texture, and, with a new extension, even scaling. Therefore, >>> location and size parameters are needed. >>> >>> The mask parameter was added because resolving only depth or only >>> stencil of a combined buffer is possible as well. >>> >>> Full information about the blit operation allows the drivers to >>> take the most efficient path they possibly can. >> So, if there are no objections anymore I'm just going to push this >> small >> series in a few days ... >> >> Since no other drivers implement multisampling at the moment it can't >> break anything (except maybe closed source state trackers I don't >> know >> about). >> >>> --- >>> src/gallium/docs/source/context.rst |7 +-- >>> src/gallium/include/pipe/p_context.h |8 +++- >>> src/gallium/include/pipe/p_defines.h |4 >>> src/gallium/include/pipe/p_state.h | 28 >>> >>> 4 files changed, 40 insertions(+), 7 deletions(-) >>> >>> diff --git a/src/gallium/docs/source/context.rst >>> b/src/gallium/docs/source/context.rst >>> index 25a3245..7968f03 100644 >>> --- a/src/gallium/docs/source/context.rst >>> +++ b/src/gallium/docs/source/context.rst >>> @@ -329,8 +329,11 @@ textured quad blitter.. The source and >>> destination may be the same resource, >>> but overlapping blits are not permitted. >>> >>> ``resource_resolve`` resolves a multisampled resource into a >>> non-multisampled >>> -one. Formats and dimensions must match. This function must be >>> present if a driver >>> -supports multisampling. >>> +one. Formats must match, and, if PIPE_CAP_SCALED_RESOLVE is not >>> supported, >>> +dimensions as well. >>> +The source and destination resources and coordinates are described >>> +by ``pipe_resolve_info``. >>> +This function must be present if a driver supports multisampling. >>> >>> The interfaces to these calls are likely to change to make it >>> easier >>> for a driver to batch multiple blits with the same source and >>> diff --git a/src/gallium/include/pipe/p_context.h >>> b/src/gallium/include/pipe/p_context.h >>> index 3f6d90d..da3ee87 100644 >>> --- a/src/gallium/include/pipe/p_context.h >>> +++ b/src/gallium/include/pipe/p_context.h >>> @@ -49,6 +49,7 @@ struct pipe_index_buffer; >>> struct pipe_query; >>> struct pipe_poly_stipple; >>> struct pipe_rasterizer_state; >>> +struct pipe_resolve_info; >>> struct pipe_resource; >>> struct pipe_sam
[Mesa-dev] [Bug 37177] Mathematica Plot3D Crash
https://bugs.freedesktop.org/show_bug.cgi?id=37177 José Fonseca changed: What|Removed |Added Component|GLX |Drivers/DRI/i915 AssignedTo|mesa-dev@lists.freedesktop. |i...@freedesktop.org |org | CC||jfons...@vmware.com -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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/4] Revert "glsl: Skip processing the first function's body in do_dead_functions()."
On 1 August 2011 22:16, Paul Berry wrote: > > I will investigate things further in the morning and let you know what I find. > Ok, I've spent a while looking through the linker code, and the rabbit hole goes deeper than I expected. There are a number of reasons why the linker, as currently implemented, isn't guaranteed to be produce topologically sorted output: 1. Linking doesn't actually start with an empty shader. It starts with a clone of the compilation unit that defines main() (see linker.cpp around line 836). This means that the order of functions defined in that compilation unit will be preserved regardless of the call graph. 2. When resolving a function that's declared in the compilation unit that defines main(), but defined in some other compilation unit, the linker inserts the IR for that function wherever the declaration existed. This means that the order of functions _declared_ in the compilation unit that defines main will be preserved too. Problems 1 and 2 could be addressed by not cloning the IR for the compilation unit containing main, and instead using the algorithm you described. But even if we did that, there's an additional problem: 3. Linking is performed depth first. This means that if main calls f which calls h, and main also calls g which calls h, then the linker first tries to pull in f, then h, and then finally g. Since the linker emits functions at the head of the final linked program, the final order (assuming problems 1 and 2 are fixed) would be g, h, f, main. This is the wrong order because g calls h. This problem could be addressed by making the linker operate breadth first instead of depth first. But even if we did that, there's still another problem: 4. Since the linker emits functions at the head of the final linked program, if the linker brings in a function (let's call it f()) that wasn't declared in the compilation unit that defined main, it winds up at the beginning of the linked output, _before_ any global declarations. If f() refers to a global variable, then the IR is invalid, because ir_dereference_variable nodes need to occur _after_ the variables they declare (see ir_validate.cpp line 96). This problem could be addressed by having the linker emit functions at the tail of the final linked program rather than at the head, but that would defeat the effort to make callees appear before their callers in the linker output. There's one final problem, and this to me is the clincher: 5. Since our IR groups together all overloaded functions that share the same name, there are (admittedly contrived) cases that would be impossible to topologically sort. For example: if main calls f(int) which calls g(int), and main also calls g(float) which calls f(float), this is a valid program (there's no static recursion), but there's no way to order f and g such that callees come before their respective callers. We could only address this problem by changing our IR format, or dropping the topological sort requirement. In light of everything I've discovered this morning, my recommendation is to drop the topological sort requirement. I haven't been able to find any code other than opt_dead_functions that relies on functions being topologically sorted, so unless I'm missing something, dropping the requirement is a simple matter of committing this patch. In addition, I think we should change link_functions.cpp so that it emits functions at the tail of the final linked program rather than at the head, to fix problem #4. Does this analysis seem right to you, Ian? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 37177] Mathematica Plot3D Crash
https://bugs.freedesktop.org/show_bug.cgi?id=37177 Garrett Mitchener changed: What|Removed |Added CC||garrett.mitche...@gmail.com --- Comment #5 from Garrett Mitchener 2011-08-02 11:35:33 PDT --- I discovered this today on my EEE PC netbook, Intel 945GME graphics controller. I'm running Fedora 15, XFCE, and mathematica 8 on this netbook: Rotating a 3-D graphic crashes as soon as you let go with the mouse. I don't see this problem on my Fedora 15 workstation which has a radeon graphics controller. I just ran yum update (August 2, 2011) but it's still crashing with a segmentation fault and a message about contacting Wolfram about SIGSEGV. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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/4] Revert "glsl: Skip processing the first function's body in do_dead_functions()."
On Mon, 1 Aug 2011 22:16:40 -0700, Paul Berry wrote: > On 1 August 2011 17:35, Ian Romanick wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 08/01/2011 04:07 PM, Paul Berry wrote: > >> opt_dead_functions contained a shortcut to skip processing the first > >> function's body, based on the assumption that IR functions are > >> topologically sorted, with callees always coming before their callers > >> (therefore the first function cannot contain any calls). > > > > After linking, that is absolutely true. > > > > When linking, we start with an empty shader. Then we find main, and > > pull it in. For each function pulled in (initially just main), we > > recursively pull in all the called functions. > > > > In the absence of cycles (i.e., recursion), that should guarantee the > > desired sort order. Right? > > Hmm, what you say makes sense, but there must be something more subtle > going on, because what led me to make this patch was that I first > tried writing the rest of the patch series, and then when I tested it > I ran into problems because at link time, the functions weren't sorted > in callee-to-caller order. > > I will investigate things further in the morning and let you know what I find. Since we only have one ir_function per function name, we might still be able to construct your failure by calling everything f(some args). I like the is_leaf() idea for implementing this optimization much better, though. pgpsmNHwNRvm9.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 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
Since noone else chimed in and said it's not a good idea I won't hold you up
:-).
I'd like to see a little more documentation though what it can (e.g. depth
"resolve" especially what it actually should do) and can't do in context.rst.
Speaking of what it can't do since you built this for framebuffer_blit how do
you specify the filtering, especially since depth/stencil presumably only will
do nearest, but you want to be able to do color with linear (though you should
be able to do nearest as well?). If that's implied somehow it needs to be
mentioned somewhere.
Also, I'm not sure if it wouldn't be nicer to specify all the "scaling"
parameters in the destination, instead of some in the source (the x/y flips).
Not sure though I guess if there's precedent somewhere for either way it might
be nice to do the same but it probably is fine either way.
Roland
>
> On 28.07.2011 15:59, Christoph Bumiller wrote:
> > Resolve via glBlitFramebuffer allows resolving a sub-region of a
> > renderbuffer to a different location in any mipmap level of some
> > other texture, and, with a new extension, even scaling. Therefore,
> > location and size parameters are needed.
> >
> > The mask parameter was added because resolving only depth or only
> > stencil of a combined buffer is possible as well.
> >
> > Full information about the blit operation allows the drivers to
> > take the most efficient path they possibly can.
> So, if there are no objections anymore I'm just going to push this
> small
> series in a few days ...
>
> Since no other drivers implement multisampling at the moment it can't
> break anything (except maybe closed source state trackers I don't
> know
> about).
>
> > ---
> > src/gallium/docs/source/context.rst |7 +--
> > src/gallium/include/pipe/p_context.h |8 +++-
> > src/gallium/include/pipe/p_defines.h |4
> > src/gallium/include/pipe/p_state.h | 28
> >
> > 4 files changed, 40 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/gallium/docs/source/context.rst
> > b/src/gallium/docs/source/context.rst
> > index 25a3245..7968f03 100644
> > --- a/src/gallium/docs/source/context.rst
> > +++ b/src/gallium/docs/source/context.rst
> > @@ -329,8 +329,11 @@ textured quad blitter.. The source and
> > destination may be the same resource,
> > but overlapping blits are not permitted.
> >
> > ``resource_resolve`` resolves a multisampled resource into a
> > non-multisampled
> > -one. Formats and dimensions must match. This function must be
> > present if a driver
> > -supports multisampling.
> > +one. Formats must match, and, if PIPE_CAP_SCALED_RESOLVE is not
> > supported,
> > +dimensions as well.
> > +The source and destination resources and coordinates are described
> > +by ``pipe_resolve_info``.
> > +This function must be present if a driver supports multisampling.
> >
> > The interfaces to these calls are likely to change to make it
> > easier
> > for a driver to batch multiple blits with the same source and
> > diff --git a/src/gallium/include/pipe/p_context.h
> > b/src/gallium/include/pipe/p_context.h
> > index 3f6d90d..da3ee87 100644
> > --- a/src/gallium/include/pipe/p_context.h
> > +++ b/src/gallium/include/pipe/p_context.h
> > @@ -49,6 +49,7 @@ struct pipe_index_buffer;
> > struct pipe_query;
> > struct pipe_poly_stipple;
> > struct pipe_rasterizer_state;
> > +struct pipe_resolve_info;
> > struct pipe_resource;
> > struct pipe_sampler_state;
> > struct pipe_sampler_view;
> > @@ -268,13 +269,10 @@ struct pipe_context {
> >
> > /**
> > * Resolve a multisampled resource into a non-multisampled one.
> > -* Source and destination must have the same size and same
> > format.
> > +* Source and destination must be of the same format.
> > */
> > void (*resource_resolve)(struct pipe_context *pipe,
> > -struct pipe_resource *dst,
> > -unsigned dst_layer,
> > -struct pipe_resource *src,
> > -unsigned src_layer);
> > +const struct pipe_resolve_info *info);
> >
> > /*@}*/
> >
> > diff --git a/src/gallium/include/pipe/p_defines.h
> > b/src/gallium/include/pipe/p_defines.h
> > index 79b8969..7ffdf97 100644
> > --- a/src/gallium/include/pipe/p_defines.h
> > +++ b/src/gallium/include/pipe/p_defines.h
> > @@ -99,6 +99,9 @@ enum pipe_error {
> > #define PIPE_MASK_B 0x4
> > #define PIPE_MASK_A 0x8
> > #define PIPE_MASK_RGBA 0xf
> > +#define PIPE_MASK_Z 0x10
> > +#define PIPE_MASK_S 0x20
> > +#define PIPE_MASK_ZS 0x30
> >
> >
> > /**
> > @@ -468,6 +471,7 @@ enum pipe_cap {
> > PIPE_CAP_MIXED_COLORBUFFER_FORMATS = 46,
> > PIPE_CAP_SEAMLESS_CUBE_MAP = 47,
> > PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE = 48,
> > + PIPE_CAP_SCALED_RESOLVE = 49
> > };
> >
> > /* Shader caps not specific to any single stage */
> > diff --git a/src/gallium/include/
Re: [Mesa-dev] Status of the GLSL->TGSI translator, part 2
On 08/01/2011 12:38 PM, Bryan Cain wrote: Since Mesa 7.11 is released now, I figure it's time to discuss merging the glsl-to-tgsi branch to master again. The translator is more mature than last time. There are no regressions that I know of on any driver. The code generation has improved so that it's the same as or better than ir_to_mesa in almost every case. It also will still emit TGSI integer opcodes if you change ctx->GLSLVersion from 120 to 130 in st_extensions.c. Driver developers can use this to implement these opcodes in their drivers, since they will be needed for GLSL 1.30 eventually. Are there any objections to merging it to master now? If there aren't, I'll revise some of the commit messages for correctness and wrap long lines since cgit doesn't do that automatically, then merge it after getting approval. Sounds OK to me. I was just skimming over the new stuff - it looks like create_color_map_texture() is duplicated in two files and could be shared. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Implement HW accelerated GL_SELECT
On Tue, Aug 2, 2011 at 9:37 AM, Micael Dias wrote:
> ---
Might want to mention the relevant bug and Pierre's prior patches for
future reference in case anyone wants to implement it for non-gallium
drivers. It would probably be useful to come up with a piglit test
for this, although I'm not sure how easy it would be to test GL_SELECT
in an automated way.
> src/mesa/main/mtypes.h | 7 +
> src/mesa/state_tracker/st_cb_feedback.c | 21 +-
> src/mesa/state_tracker/st_draw.h | 17 +
> src/mesa/state_tracker/st_draw_select_emul.c | 463
> ++
> src/mesa/SConscript | 1 +
> src/mesa/sources.mak | 1 +
> 6 files changed, 505 insertions(+), 5 deletions(-)
> create mode 100644 src/mesa/state_tracker/st_draw_select_emul.c
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index b881183..10222d8 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -1721,6 +1721,13 @@ struct gl_selection
> GLboolean HitFlag; /**< hit flag */
> GLfloat HitMinZ; /**< minimum hit depth */
> GLfloat HitMaxZ; /**< maximum hit depth */
> + struct gl_selection_emul /* data related to hw accelerated GL_SELECT */
> + {
> + GLboolean hw_unsupported;
> + struct gl_framebuffer *fbo;
> + GLuint renderBuffer_depth;
> + GLuint renderBuffer_color;
> + } emul;
> };
>
>
> diff --git a/src/mesa/state_tracker/st_cb_feedback.c
> b/src/mesa/state_tracker/st_cb_feedback.c
> index 9b85a39..9382895 100644
> --- a/src/mesa/state_tracker/st_cb_feedback.c
> +++ b/src/mesa/state_tracker/st_cb_feedback.c
> @@ -276,17 +276,28 @@ st_RenderMode(struct gl_context *ctx, GLenum newMode )
> {
> struct st_context *st = st_context(ctx);
> struct draw_context *draw = st->draw;
> + bool hw_acc_path = _mesa_getenv("MESA_HW_SELECT") &&
> !ctx->Select.emul.hw_unsupported;
>
> if (newMode == GL_RENDER) {
> /* restore normal VBO draw function */
> vbo_set_draw_func(ctx, st_draw_vbo);
> }
> else if (newMode == GL_SELECT) {
> - if (!st->selection_stage)
> - st->selection_stage = draw_glselect_stage(ctx, draw);
> - draw_set_rasterize_stage(draw, st->selection_stage);
> - /* Plug in new vbo draw function */
> - vbo_set_draw_func(ctx, st_feedback_draw_vbo);
> + if (hw_acc_path) {
> + if (st_select_emul_begin(ctx)) {
> + vbo_set_draw_func(ctx, st_select_draw_func);
> + }
> + else {
> + hw_acc_path = false;
> + }
> + }
> + if (!hw_acc_path) {
> + if (!st->selection_stage)
> + st->selection_stage = draw_glselect_stage(ctx, draw);
> + draw_set_rasterize_stage(draw, st->selection_stage);
> + /* Plug in new vbo draw function */
> + vbo_set_draw_func(ctx, st_feedback_draw_vbo);
> + }
> }
> else {
> if (!st->feedback_stage)
> diff --git a/src/mesa/state_tracker/st_draw.h
> b/src/mesa/state_tracker/st_draw.h
> index a7b50ce..d27e321 100644
> --- a/src/mesa/state_tracker/st_draw.h
> +++ b/src/mesa/state_tracker/st_draw.h
> @@ -87,5 +87,22 @@ pointer_to_offset(const void *ptr)
> return (unsigned) (((unsigned long) ptr) & 0xUL);
> }
>
> +/* Functions used by the hw accelerated GL_SELECT emulator
> + */
> +extern bool
> +st_select_emul_begin(struct gl_context *ctx);
> +
> +extern void
> +st_select_emul_end(struct gl_context *ctx);
> +
> +extern void
> +st_select_draw_func(struct gl_context *ctx,
> + const struct gl_client_array **arrays,
> + const struct _mesa_prim *prims,
> + GLuint nr_prims,
> + const struct _mesa_index_buffer *ib,
> + GLboolean index_bounds_valid,
> + GLuint min_index,
> + GLuint max_index);
>
> #endif
> diff --git a/src/mesa/state_tracker/st_draw_select_emul.c
> b/src/mesa/state_tracker/st_draw_select_emul.c
> new file mode 100644
> index 000..78065dd
> --- /dev/null
> +++ b/src/mesa/state_tracker/st_draw_select_emul.c
> @@ -0,0 +1,463 @@
> +/**
> + *
> + * Copyright .
Fix up the copyright.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDE
Re: [Mesa-dev] [PATCH] Implement HW accelerated GL_SELECT
Might want to fix the copyright message at the top of source file. ;)
On Tue, Aug 2, 2011 at 8:37 AM, Micael Dias wrote:
> ---
> src/mesa/main/mtypes.h |7 +
> src/mesa/state_tracker/st_cb_feedback.c | 21 +-
> src/mesa/state_tracker/st_draw.h | 17 +
> src/mesa/state_tracker/st_draw_select_emul.c | 463
> ++
> src/mesa/SConscript |1 +
> src/mesa/sources.mak |1 +
> 6 files changed, 505 insertions(+), 5 deletions(-)
> create mode 100644 src/mesa/state_tracker/st_draw_select_emul.c
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index b881183..10222d8 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -1721,6 +1721,13 @@ struct gl_selection
>GLboolean HitFlag; /**< hit flag */
>GLfloat HitMinZ;/**< minimum hit depth */
>GLfloat HitMaxZ;/**< maximum hit depth */
> + struct gl_selection_emul /* data related to hw accelerated GL_SELECT */
> + {
> + GLboolean hw_unsupported;
> + struct gl_framebuffer *fbo;
> + GLuint renderBuffer_depth;
> + GLuint renderBuffer_color;
> + } emul;
> };
>
>
> diff --git a/src/mesa/state_tracker/st_cb_feedback.c
> b/src/mesa/state_tracker/st_cb_feedback.c
> index 9b85a39..9382895 100644
> --- a/src/mesa/state_tracker/st_cb_feedback.c
> +++ b/src/mesa/state_tracker/st_cb_feedback.c
> @@ -276,17 +276,28 @@ st_RenderMode(struct gl_context *ctx, GLenum newMode
> )
> {
>struct st_context *st = st_context(ctx);
>struct draw_context *draw = st->draw;
> + bool hw_acc_path = _mesa_getenv("MESA_HW_SELECT") &&
> !ctx->Select.emul.hw_unsupported;
>
>if (newMode == GL_RENDER) {
> /* restore normal VBO draw function */
> vbo_set_draw_func(ctx, st_draw_vbo);
>}
>else if (newMode == GL_SELECT) {
> - if (!st->selection_stage)
> - st->selection_stage = draw_glselect_stage(ctx, draw);
> - draw_set_rasterize_stage(draw, st->selection_stage);
> - /* Plug in new vbo draw function */
> - vbo_set_draw_func(ctx, st_feedback_draw_vbo);
> + if (hw_acc_path) {
> + if (st_select_emul_begin(ctx)) {
> +vbo_set_draw_func(ctx, st_select_draw_func);
> + }
> + else {
> +hw_acc_path = false;
> + }
> + }
> + if (!hw_acc_path) {
> + if (!st->selection_stage)
> +st->selection_stage = draw_glselect_stage(ctx, draw);
> + draw_set_rasterize_stage(draw, st->selection_stage);
> + /* Plug in new vbo draw function */
> + vbo_set_draw_func(ctx, st_feedback_draw_vbo);
> + }
>}
>else {
> if (!st->feedback_stage)
> diff --git a/src/mesa/state_tracker/st_draw.h
> b/src/mesa/state_tracker/st_draw.h
> index a7b50ce..d27e321 100644
> --- a/src/mesa/state_tracker/st_draw.h
> +++ b/src/mesa/state_tracker/st_draw.h
> @@ -87,5 +87,22 @@ pointer_to_offset(const void *ptr)
>return (unsigned) (((unsigned long) ptr) & 0xUL);
> }
>
> +/* Functions used by the hw accelerated GL_SELECT emulator
> + */
> +extern bool
> +st_select_emul_begin(struct gl_context *ctx);
> +
> +extern void
> +st_select_emul_end(struct gl_context *ctx);
> +
> +extern void
> +st_select_draw_func(struct gl_context *ctx,
> +const struct gl_client_array **arrays,
> +const struct _mesa_prim *prims,
> +GLuint nr_prims,
> +const struct _mesa_index_buffer *ib,
> +GLboolean index_bounds_valid,
> +GLuint min_index,
> +GLuint max_index);
>
> #endif
> diff --git a/src/mesa/state_tracker/st_draw_select_emul.c
> b/src/mesa/state_tracker/st_draw_select_emul.c
> new file mode 100644
> index 000..78065dd
> --- /dev/null
> +++ b/src/mesa/state_tracker/st_draw_select_emul.c
> @@ -0,0 +1,463 @@
>
> +/**
> + *
> + * Copyright .
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> + * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS
[Mesa-dev] [PATCH] Implement HW accelerated GL_SELECT
---
src/mesa/main/mtypes.h |7 +
src/mesa/state_tracker/st_cb_feedback.c | 21 +-
src/mesa/state_tracker/st_draw.h | 17 +
src/mesa/state_tracker/st_draw_select_emul.c | 463 ++
src/mesa/SConscript |1 +
src/mesa/sources.mak |1 +
6 files changed, 505 insertions(+), 5 deletions(-)
create mode 100644 src/mesa/state_tracker/st_draw_select_emul.c
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index b881183..10222d8 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1721,6 +1721,13 @@ struct gl_selection
GLboolean HitFlag; /**< hit flag */
GLfloat HitMinZ;/**< minimum hit depth */
GLfloat HitMaxZ;/**< maximum hit depth */
+ struct gl_selection_emul /* data related to hw accelerated GL_SELECT */
+ {
+ GLboolean hw_unsupported;
+ struct gl_framebuffer *fbo;
+ GLuint renderBuffer_depth;
+ GLuint renderBuffer_color;
+ } emul;
};
diff --git a/src/mesa/state_tracker/st_cb_feedback.c
b/src/mesa/state_tracker/st_cb_feedback.c
index 9b85a39..9382895 100644
--- a/src/mesa/state_tracker/st_cb_feedback.c
+++ b/src/mesa/state_tracker/st_cb_feedback.c
@@ -276,17 +276,28 @@ st_RenderMode(struct gl_context *ctx, GLenum newMode )
{
struct st_context *st = st_context(ctx);
struct draw_context *draw = st->draw;
+ bool hw_acc_path = _mesa_getenv("MESA_HW_SELECT") &&
!ctx->Select.emul.hw_unsupported;
if (newMode == GL_RENDER) {
/* restore normal VBO draw function */
vbo_set_draw_func(ctx, st_draw_vbo);
}
else if (newMode == GL_SELECT) {
- if (!st->selection_stage)
- st->selection_stage = draw_glselect_stage(ctx, draw);
- draw_set_rasterize_stage(draw, st->selection_stage);
- /* Plug in new vbo draw function */
- vbo_set_draw_func(ctx, st_feedback_draw_vbo);
+ if (hw_acc_path) {
+ if (st_select_emul_begin(ctx)) {
+vbo_set_draw_func(ctx, st_select_draw_func);
+ }
+ else {
+hw_acc_path = false;
+ }
+ }
+ if (!hw_acc_path) {
+ if (!st->selection_stage)
+st->selection_stage = draw_glselect_stage(ctx, draw);
+ draw_set_rasterize_stage(draw, st->selection_stage);
+ /* Plug in new vbo draw function */
+ vbo_set_draw_func(ctx, st_feedback_draw_vbo);
+ }
}
else {
if (!st->feedback_stage)
diff --git a/src/mesa/state_tracker/st_draw.h b/src/mesa/state_tracker/st_draw.h
index a7b50ce..d27e321 100644
--- a/src/mesa/state_tracker/st_draw.h
+++ b/src/mesa/state_tracker/st_draw.h
@@ -87,5 +87,22 @@ pointer_to_offset(const void *ptr)
return (unsigned) (((unsigned long) ptr) & 0xUL);
}
+/* Functions used by the hw accelerated GL_SELECT emulator
+ */
+extern bool
+st_select_emul_begin(struct gl_context *ctx);
+
+extern void
+st_select_emul_end(struct gl_context *ctx);
+
+extern void
+st_select_draw_func(struct gl_context *ctx,
+const struct gl_client_array **arrays,
+const struct _mesa_prim *prims,
+GLuint nr_prims,
+const struct _mesa_index_buffer *ib,
+GLboolean index_bounds_valid,
+GLuint min_index,
+GLuint max_index);
#endif
diff --git a/src/mesa/state_tracker/st_draw_select_emul.c
b/src/mesa/state_tracker/st_draw_select_emul.c
new file mode 100644
index 000..78065dd
--- /dev/null
+++ b/src/mesa/state_tracker/st_draw_select_emul.c
@@ -0,0 +1,463 @@
+/**
+ *
+ * Copyright .
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include "main/imports.h"
+#include "mai
Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600
fykc...@gmail.com wrote: Depending on how it was configured mplayer needs (probably) /etc/X11/XvMCConfig containing /path/to/your/lib/libXvMCr600.so I add the path "/usr/lib/libXvMCr600.so" to /etc/X11/XvMCConfig, but mplayer seems not invoke it (No r600 in strace or /proc/pid/maps). Maybe I should try a newer version of mplayer. mplayer -v may help, just in case it's looking somewhere else. For me mplayer xvmc is not built by default, I have to --enable-xvmc when configuring. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600
Hi, Thanks for your reply. 2011/8/2 Andy Furniss : > fykc...@gmail.com wrote: >> >> Hi all, >> >> I've tried mesa-7.11rc4 with pipe-video patch on a Loongson3A based >> notebook: >> * CPU: 4-core MIPS64 compatible (Little-endian, 64bit kernel with an >> o32 userland) >> * Graphics: RS780E >> >> I tried h264、mpeg2 samples with mplayer -vo vdpau and xvmc, non of them >> works: >> * For h264, mplayer produces the following error messages: > > Only mpeg 1 and 2 are supported. > >> [VD_FFMPEG] Trying pixfmt=0. >> [vdpau] Failed creating VDPAU decoder: A catch-all error, used when no >> other error code applies. > > Does VDPAU_DRIVER=r600 vdpauinfo find your libs - if not you may need to > copy them to where ever vdpau is looking. Yes. I specified a non-exists driver, mplayer quit early, complains not find the non-exists so. > >> Any idea? Thanks. > > Compiz may complicate things - I haven't tested with it. I've did the test without compiz, it seems not make any difference. > Depending on how it was configured mplayer needs (probably) > /etc/X11/XvMCConfig containing /path/to/your/lib/libXvMCr600.so I add the path "/usr/lib/libXvMCr600.so" to /etc/X11/XvMCConfig, but mplayer seems not invoke it (No r600 in strace or /proc/pid/maps). Maybe I should try a newer version of mplayer. > Your mplayer is old - maybe svn would be better if you can build it. > > mplayer -v will tell you more about where it's looking for things like xvmc > libs - but with newmobcal you will also get swamped with transport stream > info. > > vanilla xf86-video-ati: 6.14.2 does not have xvmc support, but I see from > your Xorg log that you must be using a patched/other version. Yes, some r600-related patches are backported from the master branch. > > Generally r600 pipe-video still has rendering and functional issues. If you > just want to test fair enough, but if you are trying to make your system > play h264 that it can't currently the best thing you could do is compile svn > mplayer which now has ffmpeg h264 multithread support so - > > mplayer -lavdopts threads=4 will use all of your cores. > Got it, thanks. -- Regards, - cee1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600
Hi Christian, Thanks for your reply. 2011/8/2 Christian König : > Hi, > > Am Dienstag, den 02.08.2011, 15:00 +0800 schrieb fykc...@gmail.com: >> I've tried mesa-7.11rc4 with pipe-video patch on a Loongson3A based notebook: >> * CPU: 4-core MIPS64 compatible (Little-endian, 64bit kernel with an >> o32 userland) >> * Graphics: RS780E > a bit unusual hardware configuration, but lets just see what we can do. > I'm not familiar with this kind of hardware so does "o32" mean you run > some x86 emulation, or are these native binaries? These are native binaries, o32 is an ABI for mips, which means 32bit address space + assumes all general purpose registers are 32bit. > >> I tried h264、mpeg2 samples with mplayer -vo vdpau and xvmc, non of them >> works: >> * For h264, mplayer produces the following error messages: > We currently don't have support for accelerated h264, so this test can't > succeed, but your test with the newmobcal1920 (mpeg2) demo should indeed > work. > >> Any idea? Thanks. > First question of all: Does glxgears work flawlessly? If yes (what I > assume) then the basics seems to work fine. Yes, it works fine. > > Please try mplayer just with the "-vo vdpau" option (without any "-vc" > option), this should result in software decoding with hardware colour > conversion and scaling, just the same thing that Xv does. Does this > gives you a picture? Yes, it works. > > Something else you should try is "export VDPAU_DEBUG=4", that should > give you a whole bunch of debug informations, please supply those to the > list. Attachment is the log. -- Regards, - cee1 VDPAU_DEBUG=4 VDPAU_DRIVER=r600 mplayer -vc "ffmpeg12vdpau" -vo vdpau "newmobcal1920.ts" MPlayer 1.0rc4-4.4.5 (C) 2000-2010 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing newmobcal1920.ts. TS file format detected. VIDEO MPEG2(pid=49) NO AUDIO! NO SUBS (yet)! PROGRAM N. 1 VIDEO: MPEG2 1920x1080 (aspect 3) 29.970 fps 22496.0 kbps (2812.0 kbyte/s) [VDPAU] Device created succesfully [VDPAU] Got proc adress 0x2ecd06f0 for id 0 [VDPAU] Got proc adress 0x2ecd0a04 for id 5 [VDPAU] Got proc adress 0x2ecd3584 for id 9 [VDPAU] Got proc adress 0x2ecd3428 for id 10 [VDPAU] Got proc adress 0x2ecd3164 for id 13 [VDPAU] Got proc adress 0x2ecd1848 for id 22 [VDPAU] Got proc adress 0x2ecd1b5c for id 18 [VDPAU] Got proc adress 0x2ecd1e6c for id 19 [VDPAU] Got proc adress 0x2ecd16b8 for id 46 [VDPAU] Got proc adress 0x2ecd160c for id 53 [VDPAU] Got proc adress 0x2ecd1508 for id 54 [VDPAU] Got proc adress 0x2ecd146c for id 47 [VDPAU] Got proc adress 0x2ecd1408 for id 48 [VDPAU] Got proc adress 0x2ecd0b0c for id 55 [VDPAU] Got proc adress 0x2ecd2574 for id 56 [VDPAU] Got proc adress 0x2ecd24b0 for id 57 [VDPAU] Got proc adress 0x2ecd214c for id 63 [VDPAU] Got proc adress 0x2ecd2050 for id 64 [VDPAU] Got proc adress 0x2ecd0bb8 for id 4096 [VDPAU] Got proc adress 0x2ecd1860 for id 33 [VDPAU] Got proc adress 0x2ecd1850 for id 23 [VDPAU] Got proc adress 0x2ecd0478 for id 37 [VDPAU] Got proc adress 0x2eccfe80 for id 40 [VDPAU] Got proc adress 0x2ecd037c for id 38 [VDPAU] Got proc adress 0x2eccfd48 for id 26 [VDPAU] Got proc adress 0x2eccfc10 for id 27 [VDPAU] Got proc adress 0x2eccfc50 for id 29 [VDPAU] Got proc adress 0x2ecd1868 for id 34 [VDPAU] Got proc adress 0x2ecd1390 for id 6 [VDPAU] Got proc adress 0x2ecd2018 for id 66 == Forced video codec: ffmpeg12vdpau Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffmpeg12vdpau] vfm: ffmpeg (FFmpeg MPEG-1/2 (VDPAU)) == Audio: no sound Starting playback... [VD_FFMPEG] XVMC-accelerated MPEG-2. [VDPAU] Creating decoder [VDPAU] Decoder created succesfully [VDPAU] Destroying decoder [VDPAU] Creating decoder [VDPAU] Decoder created succesfully Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [vdpau] 1920x1080 => 1920x1080 MPEG2 VDPAU acceleration [VDPAU] Destroying decoder [VDPAU] Creating decoder [VDPAU] Decoder created succesfully [VDPAU] Destroying decoder [VDPAU] Creating decoder [VDPAU] Decoder created succesfully [VDPAU] Creating PresentationQueueTarget [VDPAU] Creating PresentationQueue [VDPAU] Creating VideoMixer [VDPAU] Setting VideoMixer features [VDPAU] Generating CSCMatrix [VDPAU] Creating output surface [VDPAU] Creating output surface [VDPAU] Creating output surface [VDPAU] Creating output surface [VDPAU] Creating a surface [VDPAU] Decoding [VDPAU] Decoding MPEG2 [VDPAU] Creating a surface [mpegvideo_vdpau @ 0x2c83b1b8]warning: first frame is no keyframe [VDPAU] Creating a surface [VDPAU] Decoding [VDPAU] Decoding MPEG2 V: 1.7 2/ 2 ??% ??% ??,?% 0 0 [J [mpegvideo_vdpau @ 0x2c83b1b8]warning: first frame is no keyframe [VDPAU] Creating a surface [VDPAU] Decoding [VDPAU] Decoding M
Re: [Mesa-dev] Mesa (master): Fix PPC detection on darwin
- Original Message - > On Son, 2011-07-31 at 09:47 -0700, Jeremy Huddleston wrote: > > Module: Mesa > > Branch: master > > Commit: e737a99a6fbafe3ba4b5175eea25d1598dbeb9d8 > > URL: > > > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=e737a99a6fbafe3ba4b5175eea25d1598dbeb9d8 > > > > Author: Jeremy Huddleston > > Date: Sun Jul 31 09:21:56 2011 -0700 > > > > Fix PPC detection on darwin > > > > Fixes regression introduced by > > 7004582c1894ede839c44e292b413fe4916d7e9e > > > > Signed-off-by: Jeremy Huddleston > > > > --- > > > > src/gallium/include/pipe/p_config.h |4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/src/gallium/include/pipe/p_config.h > > b/src/gallium/include/pipe/p_config.h > > index eea3d79..803b806 100644 > > --- a/src/gallium/include/pipe/p_config.h > > +++ b/src/gallium/include/pipe/p_config.h > > @@ -99,9 +99,9 @@ > > #endif > > #endif > > > > -#if defined(__PPC__) > > +#if defined(__ppc__) || defined(__ppc64__) || defined(__PPC__) > > #define PIPE_ARCH_PPC > > -#if defined(__PPC64__) > > +#if defined(__ppc64__) || defined(__PPC64__) > > #define PIPE_ARCH_PPC_64 > > #endif > > #endif > > This will result in both PIPE_ARCH_PPC and PIPE_ARCH_PPC_64 being > defined when __ppc64__ is defined. AFAICT the intention is for only > one > PIPE_ARCH_* to be defined. Yes. At least that's the case with x86. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600
fykc...@gmail.com wrote: Hi all, I've tried mesa-7.11rc4 with pipe-video patch on a Loongson3A based notebook: * CPU: 4-core MIPS64 compatible (Little-endian, 64bit kernel with an o32 userland) * Graphics: RS780E I tried h264、mpeg2 samples with mplayer -vo vdpau and xvmc, non of them works: * For h264, mplayer produces the following error messages: Only mpeg 1 and 2 are supported. [VD_FFMPEG] Trying pixfmt=0. [vdpau] Failed creating VDPAU decoder: A catch-all error, used when no other error code applies. Does VDPAU_DRIVER=r600 vdpauinfo find your libs - if not you may need to copy them to where ever vdpau is looking. Any idea? Thanks. Compiz may complicate things - I haven't tested with it. Depending on how it was configured mplayer needs (probably) /etc/X11/XvMCConfig containing /path/to/your/lib/libXvMCr600.so Your mplayer is old - maybe svn would be better if you can build it. mplayer -v will tell you more about where it's looking for things like xvmc libs - but with newmobcal you will also get swamped with transport stream info. vanilla xf86-video-ati: 6.14.2 does not have xvmc support, but I see from your Xorg log that you must be using a patched/other version. Generally r600 pipe-video still has rendering and functional issues. If you just want to test fair enough, but if you are trying to make your system play h264 that it can't currently the best thing you could do is compile svn mplayer which now has ffmpeg h264 multithread support so - mplayer -lavdopts threads=4 will use all of your cores. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600
Hi, Am Dienstag, den 02.08.2011, 15:00 +0800 schrieb fykc...@gmail.com: > I've tried mesa-7.11rc4 with pipe-video patch on a Loongson3A based notebook: > * CPU: 4-core MIPS64 compatible (Little-endian, 64bit kernel with an > o32 userland) > * Graphics: RS780E a bit unusual hardware configuration, but lets just see what we can do. I'm not familiar with this kind of hardware so does "o32" mean you run some x86 emulation, or are these native binaries? > I tried h264、mpeg2 samples with mplayer -vo vdpau and xvmc, non of them works: > * For h264, mplayer produces the following error messages: We currently don't have support for accelerated h264, so this test can't succeed, but your test with the newmobcal1920 (mpeg2) demo should indeed work. > Any idea? Thanks. First question of all: Does glxgears work flawlessly? If yes (what I assume) then the basics seems to work fine. Please try mplayer just with the "-vo vdpau" option (without any "-vc" option), this should result in software decoding with hardware colour conversion and scaling, just the same thing that Xv does. Does this gives you a picture? Something else you should try is "export VDPAU_DEBUG=4", that should give you a whole bunch of debug informations, please supply those to the list. Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] gallium: extend resource_resolve to accommodate BlitFramebuffer
On 28.07.2011 15:59, Christoph Bumiller wrote:
> Resolve via glBlitFramebuffer allows resolving a sub-region of a
> renderbuffer to a different location in any mipmap level of some
> other texture, and, with a new extension, even scaling. Therefore,
> location and size parameters are needed.
>
> The mask parameter was added because resolving only depth or only
> stencil of a combined buffer is possible as well.
>
> Full information about the blit operation allows the drivers to
> take the most efficient path they possibly can.
So, if there are no objections anymore I'm just going to push this small
series in a few days ...
Since no other drivers implement multisampling at the moment it can't
break anything (except maybe closed source state trackers I don't know
about).
> ---
> src/gallium/docs/source/context.rst |7 +--
> src/gallium/include/pipe/p_context.h |8 +++-
> src/gallium/include/pipe/p_defines.h |4
> src/gallium/include/pipe/p_state.h | 28
> 4 files changed, 40 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/docs/source/context.rst
> b/src/gallium/docs/source/context.rst
> index 25a3245..7968f03 100644
> --- a/src/gallium/docs/source/context.rst
> +++ b/src/gallium/docs/source/context.rst
> @@ -329,8 +329,11 @@ textured quad blitter.. The source and destination may
> be the same resource,
> but overlapping blits are not permitted.
>
> ``resource_resolve`` resolves a multisampled resource into a non-multisampled
> -one. Formats and dimensions must match. This function must be present if a
> driver
> -supports multisampling.
> +one. Formats must match, and, if PIPE_CAP_SCALED_RESOLVE is not supported,
> +dimensions as well.
> +The source and destination resources and coordinates are described
> +by ``pipe_resolve_info``.
> +This function must be present if a driver supports multisampling.
>
> The interfaces to these calls are likely to change to make it easier
> for a driver to batch multiple blits with the same source and
> diff --git a/src/gallium/include/pipe/p_context.h
> b/src/gallium/include/pipe/p_context.h
> index 3f6d90d..da3ee87 100644
> --- a/src/gallium/include/pipe/p_context.h
> +++ b/src/gallium/include/pipe/p_context.h
> @@ -49,6 +49,7 @@ struct pipe_index_buffer;
> struct pipe_query;
> struct pipe_poly_stipple;
> struct pipe_rasterizer_state;
> +struct pipe_resolve_info;
> struct pipe_resource;
> struct pipe_sampler_state;
> struct pipe_sampler_view;
> @@ -268,13 +269,10 @@ struct pipe_context {
>
> /**
> * Resolve a multisampled resource into a non-multisampled one.
> -* Source and destination must have the same size and same format.
> +* Source and destination must be of the same format.
> */
> void (*resource_resolve)(struct pipe_context *pipe,
> -struct pipe_resource *dst,
> -unsigned dst_layer,
> -struct pipe_resource *src,
> -unsigned src_layer);
> +const struct pipe_resolve_info *info);
>
> /*@}*/
>
> diff --git a/src/gallium/include/pipe/p_defines.h
> b/src/gallium/include/pipe/p_defines.h
> index 79b8969..7ffdf97 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -99,6 +99,9 @@ enum pipe_error {
> #define PIPE_MASK_B 0x4
> #define PIPE_MASK_A 0x8
> #define PIPE_MASK_RGBA 0xf
> +#define PIPE_MASK_Z 0x10
> +#define PIPE_MASK_S 0x20
> +#define PIPE_MASK_ZS 0x30
>
>
> /**
> @@ -468,6 +471,7 @@ enum pipe_cap {
> PIPE_CAP_MIXED_COLORBUFFER_FORMATS = 46,
> PIPE_CAP_SEAMLESS_CUBE_MAP = 47,
> PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE = 48,
> + PIPE_CAP_SCALED_RESOLVE = 49
> };
>
> /* Shader caps not specific to any single stage */
> diff --git a/src/gallium/include/pipe/p_state.h
> b/src/gallium/include/pipe/p_state.h
> index d442c15..840b3ee 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -483,6 +483,34 @@ struct pipe_draw_info
> };
>
>
> +/**
> + * Information to describe a resource_resolve call.
> + */
> +struct pipe_resolve_info
> +{
> + struct {
> + struct pipe_resource *res;
> + unsigned level;
> + unsigned layer;
> + int x0; /**< always left */
> + int y0; /**< always top */
> + int x1; /**< determines scale if PIPE_CAP_SCALED_RESOLVE is supported
> */
> + int y1; /**< determines scale if PIPE_CAP_SCALED_RESOLVE is supported
> */
> + } dst;
> +
> + struct {
> + struct pipe_resource *res;
> + unsigned layer;
> + int x0;
> + int y0;
> + int x1; /**< may be < x0 only if PIPE_CAP_SCALED_RESOLVE is supported
> */
> + int y1; /**< may be < y1 even if PIPE_CAP_SCALED_RESOLVE not supported
> */
> + } src;
> +
> + unsigned mask; /**< PIPE_MASK_RGBA, Z, S or ZS */
> +};
> +
> +
> #ifdef __cplusplus
> }
> #end
[Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600
Hi all, I've tried mesa-7.11rc4 with pipe-video patch on a Loongson3A based notebook: * CPU: 4-core MIPS64 compatible (Little-endian, 64bit kernel with an o32 userland) * Graphics: RS780E I tried h264、mpeg2 samples with mplayer -vo vdpau and xvmc, non of them works: * For h264, mplayer produces the following error messages: [VD_FFMPEG] Trying pixfmt=0. [vdpau] Failed creating VDPAU decoder: A catch-all error, used when no other error code applies. Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] The selected video_out device is incompatible with this codec. Try appending the scale filter to your filter list, e.g. -vf spp,scale instead of -vf spp. [h264_vdpau @ 0x2bddf1b8]decoding to PIX_FMT_NONE is not supported. [h264_vdpau @ 0x2bddf1b8]decode_slice_header error [h264_vdpau @ 0x2bddf1b8]no frame! Error while decoding frame! * For mepg4, mplayer renders a corrupted playback(http://dev.lemote.com/files/upload/software/temp/IMG_20110802_104200.jpg), and produces the following: [VD_FFMPEG] XVMC-accelerated MPEG-2. Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [vdpau] 1920x1080 => 1920x1080 MPEG2 VDPAU acceleration [mpegvideo_vdpau @ 0x2cb7b1b8]warning: first frame is no keyframe V: 1.7 2/ 2 ??% ??% ??,?% 0 0 [J [mpegvideo_vdpau @ 0x2cb7b1b8]warning: first frame is no keyframe V: 1.8 3/ 3 ??% ??% ??,?% 0 0 [J I also tried the master branch(5b3c7199830b8eaac4df2f8c3f10d0e89b4bd5c5), and got the same result. The test samples can be found at: http://dev.lemote.com/files/upload/software/temp/video-test/ -- run test.sh, it will play each sample with vdpau and xvmc, recording the outputs. The detailed log message of the above test, including glxinfo can be found at: http://dev.lemote.com/files/upload/software/temp/video-test.result.log.tar.bz2 Xorg info: http://dev.lemote.com/files/upload/software/temp/Xorg.0.log Any idea? Thanks. More info about the OS environment: 1. Linux: 2.6.36 2. OS: Based on debian squeeze, and ports some ubuntu graphical packages. 2. X Server: 1.10.2.902 3. xf86-video-ati: 6.14.2 4. compiz: 0.8.6 -- Regards, - cee1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
