[Mesa-dev] [Bug 90466] arm: linker error ndefined reference to `nir_metadata_preserve'
https://bugs.freedesktop.org/show_bug.cgi?id=90466 Bug ID: 90466 Summary: arm: linker error ndefined reference to `nir_metadata_preserve' Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: i.gnatenko.br...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org Full log: https://kojipkgs.fedoraproject.org//work/tasks/1009/9671009/build.log ../../../../src/gallium/drivers/vc4/.libs/libvc4.a(vc4_program.o): In function `qir_ITOF': /builddir/build/BUILD/mesa-51e3453/src/gallium/drivers/vc4/vc4_qir.h:489: undefined reference to `nir_intrinsic_infos' ../../../../src/gallium/drivers/vc4/.libs/libvc4.a(vc4_program.o): In function `ntq_emit_instr': /builddir/build/BUILD/mesa-51e3453/src/gallium/drivers/vc4/vc4_program.c:1937: undefined reference to `nir_print_instr' ../../../../src/gallium/drivers/vc4/.libs/libvc4.a(vc4_program.o): In function `vc4_shader_ntq': /builddir/build/BUILD/mesa-51e3453/src/gallium/drivers/vc4/vc4_program.c:2107: undefined reference to `nir_print_shader' ../../../../src/gallium/drivers/vc4/.libs/libvc4.a(vc4_program.o): In function `count_nir_instrs': /builddir/build/BUILD/mesa-51e3453/src/gallium/drivers/vc4/vc4_program.c:2020: undefined reference to `nir_foreach_block' ../../../../src/gallium/drivers/vc4/.libs/libvc4.a(vc4_program.o): In function `ntq_emit_intrinsic': /builddir/build/BUILD/mesa-51e3453/src/gallium/drivers/vc4/vc4_program.c:1903: undefined reference to `nir_print_instr' And more others. I see this error only on armv7hl. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 01/16] glsl: Add tracking for GLSL precision qualifiers
From: Iago Toral Quiroga
Currently, we only consider precision qualifiers at compile-time. This patch
adds precision information to ir_variable so we can also do link time checks.
Specifically, from the GLSL ES3 spec, 4.5.3 Precision Qualifiers:
"The same uniform declared in different shaders that are linked together
must have the same precision qualification."
v2 (Ian Romanick):
- Remove unused precision field from glsl_type.
- Fix comments stating that desktop OpenGL ignores precision qualifiers.
- Make the precision field in ir_variable a bitfield and use pahole to
place it in an available hole so we don't increase memory storage
requirements for ir_variable.
v3 (Topi):
- Split out the checking logic in linker which did not apply to master
---
src/glsl/ast_to_hir.cpp | 12
src/glsl/glsl_types.cpp | 4
src/glsl/glsl_types.h | 12
src/glsl/ir.h | 13 +
4 files changed, 41 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 14e6309..7d5bb1d 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2450,6 +2450,10 @@ apply_type_qualifier_to_variable(const struct
ast_type_qualifier *qual,
if (qual->flags.q.sample)
var->data.sample = 1;
+ /* Precision qualifiers do not hold any meaning in Desktop GLSL */
+ if (state->es_shader && qual->precision)
+ var->data.precision = qual->precision;
+
if (state->stage == MESA_SHADER_GEOMETRY &&
qual->flags.q.out && qual->flags.q.stream) {
var->data.stream = qual->stream;
@@ -5301,6 +5305,10 @@ ast_process_structure_or_interface_block(exec_list
*instructions,
fields[i].centroid = qual->flags.q.centroid ? 1 : 0;
fields[i].sample = qual->flags.q.sample ? 1 : 0;
+ /* Precision qualifiers do not hold any meaning in Desktop GLSL */
+ fields[i].precision = state->es_shader ? qual->precision :
+ GLSL_PRECISION_NONE;
+
/* Only save explicitly defined streams in block's field */
fields[i].stream = qual->flags.q.explicit_stream ? qual->stream : -1;
@@ -5804,6 +5812,10 @@ ast_interface_block::hir(exec_list *instructions,
if (var_mode == ir_var_shader_in || var_mode == ir_var_uniform)
var->data.read_only = true;
+ /* Precision qualifiers do not hold any meaning in Desktop GLSL */
+ var->data.precision = state->es_shader ? fields[i].precision :
+ GLSL_PRECISION_NONE;
+
if (fields[i].matrix_layout == GLSL_MATRIX_LAYOUT_INHERITED) {
var->data.matrix_layout = matrix_layout ==
GLSL_MATRIX_LAYOUT_INHERITED
? GLSL_MATRIX_LAYOUT_COLUMN_MAJOR : matrix_layout;
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 9c9b7ef..46c8bf1 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -122,6 +122,7 @@ glsl_type::glsl_type(const glsl_struct_field *fields,
unsigned num_fields,
this->fields.structure[i].centroid = fields[i].centroid;
this->fields.structure[i].sample = fields[i].sample;
this->fields.structure[i].matrix_layout = fields[i].matrix_layout;
+ this->fields.structure[i].precision = fields[i].precision;
}
mtx_unlock(&glsl_type::mutex);
@@ -716,6 +717,9 @@ glsl_type::record_compare(const glsl_type *b) const
if (this->fields.structure[i].sample
!= b->fields.structure[i].sample)
return false;
+ if (this->fields.structure[i].precision
+ != b->fields.structure[i].precision)
+ return false;
}
return true;
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index 5645dcd..25c4d30 100644
--- a/src/glsl/glsl_types.h
+++ b/src/glsl/glsl_types.h
@@ -100,6 +100,13 @@ enum glsl_matrix_layout {
GLSL_MATRIX_LAYOUT_ROW_MAJOR
};
+enum {
+ GLSL_PRECISION_NONE = 0,
+ GLSL_PRECISION_HIGH,
+ GLSL_PRECISION_MEDIUM,
+ GLSL_PRECISION_LOW
+};
+
#ifdef __cplusplus
#include "GL/gl.h"
#include "util/ralloc.h"
@@ -768,6 +775,11 @@ struct glsl_struct_field {
* streams (as in ir_variable::stream). -1 otherwise.
*/
int stream;
+
+ /**
+* Precission qualifier
+*/
+ unsigned precision;
};
static inline unsigned int
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index fab1cd2..5ef9e68 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -755,6 +755,19 @@ public:
unsigned index:1;
/**
+ * Precision qualifier.
+ *
+ * In desktop GLSL we do not care about precision qualifiers at all, in
+ * fact, the spec says that precision qualifiers are ignored.
+ *
+ * To make things easy, we make it so that this field is always
+ * GLSL_PRECISION_NONE on desktop shaders. This way all the variables
+ * have the same precision value and the checks we add in the compiler
+ * for this field will never break a desktop
[Mesa-dev] [RFC 12/16] nir: Consider float precision when deciding between int/float: part2
Signed-off-by: Topi Pohjolainen
---
src/glsl/nir/glsl_to_nir.cpp | 61 ++--
1 file changed, 25 insertions(+), 36 deletions(-)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index 1267475..5b3c2ad 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -872,6 +872,11 @@ nir_visitor::emit(nir_op op, unsigned dest_size, nir_src
src1,
(type) == GLSL_TYPE_FLOAT ? nir_op_f ## suffix : \
nir_op_i ## suffix
+#define OP_FLT_INT_2(type, suffix_1, suffix_2) \
+ (type) == GLSL_TYPE_HALF ? nir_op_ ## suffix_1 ## _h ## suffix_2 : \
+ (type) == GLSL_TYPE_FLOAT ? nir_op_ ## suffix_1 ## _f ## suffix_2 : \
+ nir_op_ ## suffix_1 ## _i ## suffix_2
+
void
nir_visitor::visit(ir_expression *ir)
{
@@ -1387,24 +1392,16 @@ nir_visitor::visit(ir_expression *ir)
break;
case ir_binop_all_equal:
if (supports_ints) {
- if (types[0] == GLSL_TYPE_FLOAT) {
-switch (ir->operands[0]->type->vector_elements) {
- case 1: emit(nir_op_feq, dest_size, srcs); break;
- case 2: emit(nir_op_ball_fequal2, dest_size, srcs); break;
- case 3: emit(nir_op_ball_fequal3, dest_size, srcs); break;
- case 4: emit(nir_op_ball_fequal4, dest_size, srcs); break;
- default:
- unreachable("not reached");
-}
- } else {
-switch (ir->operands[0]->type->vector_elements) {
- case 1: emit(nir_op_ieq, dest_size, srcs); break;
- case 2: emit(nir_op_ball_iequal2, dest_size, srcs); break;
- case 3: emit(nir_op_ball_iequal3, dest_size, srcs); break;
- case 4: emit(nir_op_ball_iequal4, dest_size, srcs); break;
- default:
- unreachable("not reached");
-}
+ switch (ir->operands[0]->type->vector_elements) {
+case 1: emit(OP_FLT_INT(types[0], eq), dest_size, srcs); break;
+case 2: emit(OP_FLT_INT_2(types[0], ball, equal2),
+ dest_size, srcs); break;
+case 3: emit(OP_FLT_INT_2(types[0], ball, equal3),
+ dest_size, srcs); break;
+case 4: emit(OP_FLT_INT_2(types[0], ball, equal4),
+ dest_size, srcs); break;
+default:
+ unreachable("not reached");
}
} else {
switch (ir->operands[0]->type->vector_elements) {
@@ -1419,24 +1416,16 @@ nir_visitor::visit(ir_expression *ir)
break;
case ir_binop_any_nequal:
if (supports_ints) {
- if (types[0] == GLSL_TYPE_FLOAT) {
-switch (ir->operands[0]->type->vector_elements) {
- case 1: emit(nir_op_fne, dest_size, srcs); break;
- case 2: emit(nir_op_bany_fnequal2, dest_size, srcs); break;
- case 3: emit(nir_op_bany_fnequal3, dest_size, srcs); break;
- case 4: emit(nir_op_bany_fnequal4, dest_size, srcs); break;
- default:
- unreachable("not reached");
-}
- } else {
-switch (ir->operands[0]->type->vector_elements) {
- case 1: emit(nir_op_ine, dest_size, srcs); break;
- case 2: emit(nir_op_bany_inequal2, dest_size, srcs); break;
- case 3: emit(nir_op_bany_inequal3, dest_size, srcs); break;
- case 4: emit(nir_op_bany_inequal4, dest_size, srcs); break;
- default:
- unreachable("not reached");
-}
+ switch (ir->operands[0]->type->vector_elements) {
+case 1: emit(OP_FLT_INT(types[0], ne), dest_size, srcs); break;
+case 2: emit(OP_FLT_INT_2(types[0], bany, nequal2),
+ dest_size, srcs); break;
+case 3: emit(OP_FLT_INT_2(types[0], bany, nequal3),
+ dest_size, srcs); break;
+case 4: emit(OP_FLT_INT_2(types[0], bany, nequal4),
+ dest_size, srcs); break;
+default:
+ unreachable("not reached");
}
} else {
switch (ir->operands[0]->type->vector_elements) {
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 15/16] nir: Consider float precision when deciding opcode
Signed-off-by: Topi Pohjolainen
---
src/glsl/nir/glsl_to_nir.cpp | 61 +---
1 file changed, 35 insertions(+), 26 deletions(-)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index 4cb250a..b4777aa 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -888,6 +888,10 @@ nir_visitor::emit(nir_op op, unsigned dest_size, nir_src
src1,
(type) == GLSL_TYPE_FLOAT ? nir_op_f ## suffix : \
nir_op_u ## suffix
+#define OP_FLT(type, suffix) \
+ (type) == GLSL_TYPE_HALF ? nir_op_h ## suffix : \
+ nir_op_f ## suffix
+
void
nir_visitor::visit(ir_expression *ir)
{
@@ -1047,19 +1051,19 @@ nir_visitor::visit(ir_expression *ir)
instr = emit(OP_FLT_INT(types[0], abs), dest_size, srcs);
break;
case ir_unop_saturate:
- assert(types[0] == GLSL_TYPE_FLOAT);
- instr = emit(nir_op_fsat, dest_size, srcs);
+ assert(types[0] == GLSL_TYPE_HALF || types[0] == GLSL_TYPE_FLOAT);
+ instr = emit(OP_FLT(types[0], sat), dest_size, srcs);
break;
case ir_unop_sign:
instr = emit(OP_FLT_INT(types[0], sign), dest_size, srcs);
break;
- case ir_unop_rcp: emit(nir_op_frcp, dest_size, srcs); break;
- case ir_unop_rsq: emit(nir_op_frsq, dest_size, srcs); break;
- case ir_unop_sqrt: emit(nir_op_fsqrt, dest_size, srcs); break;
+ case ir_unop_rcp: emit(OP_FLT(types[0], rcp), dest_size, srcs); break;
+ case ir_unop_rsq: emit(OP_FLT(types[0], rsq), dest_size, srcs); break;
+ case ir_unop_sqrt: emit(OP_FLT(types[0], sqrt), dest_size, srcs); break;
case ir_unop_exp: unreachable("ir_unop_exp should have been lowered");
case ir_unop_log: unreachable("ir_unop_log should have been lowered");
- case ir_unop_exp2: emit(nir_op_fexp2, dest_size, srcs); break;
- case ir_unop_log2: emit(nir_op_flog2, dest_size, srcs); break;
+ case ir_unop_exp2: emit(OP_FLT(types[0], exp2), dest_size, srcs); break;
+ case ir_unop_log2: emit(OP_FLT(types[0], log2), dest_size, srcs); break;
case ir_unop_i2f:
emit(supports_ints ? nir_op_i2f : nir_op_fmov, dest_size, srcs);
break;
@@ -1069,11 +1073,11 @@ nir_visitor::visit(ir_expression *ir)
case ir_unop_b2f:
emit(supports_ints ? nir_op_b2f : nir_op_fmov, dest_size, srcs);
break;
- case ir_unop_f2i: emit(nir_op_f2i, dest_size, srcs); break;
- case ir_unop_f2u: emit(nir_op_f2u, dest_size, srcs); break;
- case ir_unop_f2b: emit(nir_op_f2b, dest_size, srcs); break;
- case ir_unop_i2b: emit(nir_op_i2b, dest_size, srcs); break;
- case ir_unop_b2i: emit(nir_op_b2i, dest_size, srcs); break;
+ case ir_unop_f2i: emit(OP_FLT(types[0], 2i), dest_size, srcs); break;
+ case ir_unop_f2u: emit(OP_FLT(types[0], 2u), dest_size, srcs); break;
+ case ir_unop_f2b: emit(OP_FLT(types[0], 2b), dest_size, srcs); break;
+ case ir_unop_i2b: emit(nir_op_i2b, dest_size, srcs); break;
+ case ir_unop_b2i: emit(nir_op_b2i, dest_size, srcs); break;
case ir_unop_i2u:
case ir_unop_u2i:
case ir_unop_bitcast_i2f:
@@ -1101,19 +1105,24 @@ nir_visitor::visit(ir_expression *ir)
unreachable("not reached");
}
break;
- case ir_unop_trunc: emit(nir_op_ftrunc, dest_size, srcs); break;
- case ir_unop_ceil: emit(nir_op_fceil, dest_size, srcs); break;
- case ir_unop_floor: emit(nir_op_ffloor, dest_size, srcs); break;
- case ir_unop_fract: emit(nir_op_ffract, dest_size, srcs); break;
- case ir_unop_round_even: emit(nir_op_fround_even, dest_size, srcs); break;
- case ir_unop_sin: emit(nir_op_fsin, dest_size, srcs); break;
- case ir_unop_cos: emit(nir_op_fcos, dest_size, srcs); break;
- case ir_unop_dFdx:emit(nir_op_fddx,dest_size, srcs); break;
- case ir_unop_dFdy:emit(nir_op_fddy,dest_size, srcs); break;
- case ir_unop_dFdx_fine: emit(nir_op_fddx_fine, dest_size, srcs); break;
- case ir_unop_dFdy_fine: emit(nir_op_fddy_fine, dest_size, srcs); break;
- case ir_unop_dFdx_coarse: emit(nir_op_fddx_coarse, dest_size, srcs); break;
- case ir_unop_dFdy_coarse: emit(nir_op_fddy_coarse, dest_size, srcs); break;
+ case ir_unop_trunc: emit(OP_FLT(types[0], trunc), dest_size, srcs); break;
+ case ir_unop_ceil: emit(OP_FLT(types[0], ceil), dest_size, srcs); break;
+ case ir_unop_floor: emit(OP_FLT(types[0], floor), dest_size, srcs); break;
+ case ir_unop_fract: emit(OP_FLT(types[0], fract), dest_size, srcs); break;
+ case ir_unop_round_even:
+ emit(OP_FLT(types[0], round_even), dest_size, srcs); break;
+ case ir_unop_sin: emit(OP_FLT(types[0], sin), dest_size, srcs); break;
+ case ir_unop_cos: emit(OP_FLT(types[0], cos), dest_size, srcs); break;
+ case ir_unop_dFdx: emit(OP_FLT(types[0], ddx), dest_size, srcs); break;
+ case ir_unop_dFdy: emit(OP_FLT(types[0], ddy), dest_size, srcs); break;
+ case ir_unop_dFdx_f
[Mesa-dev] [RFC 03/16] mesa: Add half float uniform support
Signed-off-by: Topi Pohjolainen
---
src/mesa/main/uniform_query.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 728bd1b..4cdb682 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -448,6 +448,7 @@ log_uniform(const void *values, enum glsl_base_type
basicType,
case GLSL_TYPE_INT:
printf("%d ", v[i].i);
break;
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_FLOAT:
printf("%g ", v[i].f);
break;
@@ -595,6 +596,8 @@ glsl_type_name(enum glsl_base_type type)
return "uint";
case GLSL_TYPE_INT:
return "int";
+ case GLSL_TYPE_HALF:
+ return "half";
case GLSL_TYPE_FLOAT:
return "float";
case GLSL_TYPE_DOUBLE:
@@ -767,7 +770,7 @@ _mesa_uniform(struct gl_context *ctx, struct
gl_shader_program *shProg,
const unsigned elems = components * count;
for (unsigned i = 0; i < elems; i++) {
-if (basicType == GLSL_TYPE_FLOAT) {
+if (basicType == GLSL_TYPE_FLOAT || basicType == GLSL_TYPE_HALF) {
dst[i].i = src[i].f != 0.0f ? ctx->Const.UniformBooleanTrue : 0;
} else {
dst[i].i = src[i].i != 0? ctx->Const.UniformBooleanTrue : 0;
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 08/16] glsl: Add support for half float loop control
Signed-off-by: Topi Pohjolainen --- src/glsl/loop_controls.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glsl/loop_controls.cpp b/src/glsl/loop_controls.cpp index 51804bb..4ba3049 100644 --- a/src/glsl/loop_controls.cpp +++ b/src/glsl/loop_controls.cpp @@ -132,6 +132,7 @@ calculate_iterations(ir_rvalue *from, ir_rvalue *to, ir_rvalue *increment, case GLSL_TYPE_UINT: iter = new(mem_ctx) ir_constant(unsigned(iter_value + bias[i])); break; + case GLSL_TYPE_HALF: case GLSL_TYPE_FLOAT: iter = new(mem_ctx) ir_constant(float(iter_value + bias[i])); break; -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 13/16] nir: Consider float precision when deciding between uint/int/float
Signed-off-by: Topi Pohjolainen
---
src/glsl/nir/glsl_to_nir.cpp | 55 +++-
1 file changed, 13 insertions(+), 42 deletions(-)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index 5b3c2ad..5da4122 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -877,6 +877,12 @@ nir_visitor::emit(nir_op op, unsigned dest_size, nir_src
src1,
(type) == GLSL_TYPE_FLOAT ? nir_op_ ## suffix_1 ## _f ## suffix_2 : \
nir_op_ ## suffix_1 ## _i ## suffix_2
+#define OP_FLT_INT_UINT(type, suffix) \
+ (type) == GLSL_TYPE_HALF ? nir_op_h ## suffix : \
+ (type) == GLSL_TYPE_FLOAT ? nir_op_f ## suffix : \
+ (type) == GLSL_TYPE_INT ? nir_op_i ## suffix : \
+ nir_op_u ## suffix
+
void
nir_visitor::visit(ir_expression *ir)
{
@@ -1230,12 +1236,7 @@ nir_visitor::visit(ir_expression *ir)
op = OP_FLT_INT(out_type, mul);
break;
case ir_binop_div:
- if (out_type == GLSL_TYPE_FLOAT)
-op = nir_op_fdiv;
- else if (out_type == GLSL_TYPE_INT)
-op = nir_op_idiv;
- else
-op = nir_op_udiv;
+ op = OP_FLT_INT_UINT(out_type, div);
break;
case ir_binop_mod:
if (out_type == GLSL_TYPE_FLOAT)
@@ -1244,20 +1245,10 @@ nir_visitor::visit(ir_expression *ir)
op = nir_op_umod;
break;
case ir_binop_min:
- if (out_type == GLSL_TYPE_FLOAT)
-op = nir_op_fmin;
- else if (out_type == GLSL_TYPE_INT)
-op = nir_op_imin;
- else
-op = nir_op_umin;
+ op = OP_FLT_INT_UINT(out_type, min);
break;
case ir_binop_max:
- if (out_type == GLSL_TYPE_FLOAT)
-op = nir_op_fmax;
- else if (out_type == GLSL_TYPE_INT)
-op = nir_op_imax;
- else
-op = nir_op_umax;
+ op = OP_FLT_INT_UINT(out_type, max);
break;
case ir_binop_bit_and:
op = nir_op_iand;
@@ -1330,48 +1321,28 @@ nir_visitor::visit(ir_expression *ir)
case ir_binop_borrow: emit(nir_op_usub_borrow, dest_size, srcs); break;
case ir_binop_less:
if (supports_ints) {
- if (types[0] == GLSL_TYPE_FLOAT)
-emit(nir_op_flt, dest_size, srcs);
- else if (types[0] == GLSL_TYPE_INT)
-emit(nir_op_ilt, dest_size, srcs);
- else
-emit(nir_op_ult, dest_size, srcs);
+ emit(OP_FLT_INT_UINT(types[0], lt), dest_size, srcs);
} else {
emit(nir_op_slt, dest_size, srcs);
}
break;
case ir_binop_greater:
if (supports_ints) {
- if (types[0] == GLSL_TYPE_FLOAT)
-emit(nir_op_flt, dest_size, srcs[1], srcs[0]);
- else if (types[0] == GLSL_TYPE_INT)
-emit(nir_op_ilt, dest_size, srcs[1], srcs[0]);
- else
-emit(nir_op_ult, dest_size, srcs[1], srcs[0]);
+ emit(OP_FLT_INT_UINT(types[0], lt), dest_size, srcs[1], srcs[0]);
} else {
emit(nir_op_slt, dest_size, srcs[1], srcs[0]);
}
break;
case ir_binop_lequal:
if (supports_ints) {
- if (types[0] == GLSL_TYPE_FLOAT)
-emit(nir_op_fge, dest_size, srcs[1], srcs[0]);
- else if (types[0] == GLSL_TYPE_INT)
-emit(nir_op_ige, dest_size, srcs[1], srcs[0]);
- else
-emit(nir_op_uge, dest_size, srcs[1], srcs[0]);
+ emit(OP_FLT_INT_UINT(types[0], ge), dest_size, srcs[1], srcs[0]);
} else {
emit(nir_op_slt, dest_size, srcs[1], srcs[0]);
}
break;
case ir_binop_gequal:
if (supports_ints) {
- if (types[0] == GLSL_TYPE_FLOAT)
-emit(nir_op_fge, dest_size, srcs);
- else if (types[0] == GLSL_TYPE_INT)
-emit(nir_op_ige, dest_size, srcs);
- else
-emit(nir_op_uge, dest_size, srcs);
+ emit(OP_FLT_INT_UINT(types[0], ge), dest_size, srcs[0], srcs[1]);
} else {
emit(nir_op_slt, dest_size, srcs);
}
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 09/16] glsl/ast: Use half float type for medium and low precisions
Signed-off-by: Topi Pohjolainen
---
src/glsl/ast_to_hir.cpp | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 332de5b..a8909ce 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -1962,17 +1962,23 @@ ast_fully_specified_type::glsl_type(const char **name,
if (type == NULL)
return NULL;
- if (type->base_type == GLSL_TYPE_FLOAT
- && state->es_shader
- && state->stage == MESA_SHADER_FRAGMENT
- && this->qualifier.precision == ast_precision_none
- && state->symbols->get_variable("#default precision") == NULL) {
+ if (type->base_type != GLSL_TYPE_FLOAT || !state->es_shader)
+ return type;
+
+ if (state->stage == MESA_SHADER_FRAGMENT &&
+ this->qualifier.precision == ast_precision_none &&
+ !state->symbols->get_variable("#default precision")) {
YYLTYPE loc = this->get_location();
_mesa_glsl_error(&loc, state,
"no precision specified this scope for type `%s'",
type->name);
}
+ if (this->qualifier.precision == ast_precision_medium ||
+ this->qualifier.precision == ast_precision_low)
+ type = glsl_type::get_instance(
+ GLSL_TYPE_HALF, type->vector_elements, type->matrix_columns);
+
return type;
}
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 05/16] glsl: Allow half float type to be used where-ever float is supported
Signed-off-by: Topi Pohjolainen
---
src/glsl/glsl_types.h| 2 +-
src/glsl/ir_validate.cpp | 36
2 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index d58718e..b90aa28 100644
--- a/src/glsl/glsl_types.h
+++ b/src/glsl/glsl_types.h
@@ -443,7 +443,7 @@ struct glsl_type {
*/
bool is_float() const
{
- return base_type == GLSL_TYPE_FLOAT;
+ return base_type == GLSL_TYPE_FLOAT || base_type == GLSL_TYPE_HALF;
}
/**
diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
index cfe0df3..0669d9f 100644
--- a/src/glsl/ir_validate.cpp
+++ b/src/glsl/ir_validate.cpp
@@ -262,24 +262,29 @@ ir_validate::visit_leave(ir_expression *ir)
break;
case ir_unop_f2i:
- assert(ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT);
+ assert(ir->operands[0]->type->base_type == GLSL_TYPE_HALF ||
+ ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT);
assert(ir->type->base_type == GLSL_TYPE_INT);
break;
case ir_unop_f2u:
- assert(ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT);
+ assert(ir->operands[0]->type->base_type == GLSL_TYPE_HALF ||
+ ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT);
assert(ir->type->base_type == GLSL_TYPE_UINT);
break;
case ir_unop_i2f:
assert(ir->operands[0]->type->base_type == GLSL_TYPE_INT);
- assert(ir->type->base_type == GLSL_TYPE_FLOAT);
+ assert(ir->type->base_type == GLSL_TYPE_HALF ||
+ ir->type->base_type == GLSL_TYPE_FLOAT);
break;
case ir_unop_f2b:
- assert(ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT);
+ assert(ir->operands[0]->type->base_type == GLSL_TYPE_HALF ||
+ ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT);
assert(ir->type->base_type == GLSL_TYPE_BOOL);
break;
case ir_unop_b2f:
assert(ir->operands[0]->type->base_type == GLSL_TYPE_BOOL);
- assert(ir->type->base_type == GLSL_TYPE_FLOAT);
+ assert(ir->type->base_type == GLSL_TYPE_HALF ||
+ ir->type->base_type == GLSL_TYPE_FLOAT);
break;
case ir_unop_i2b:
assert(ir->operands[0]->type->base_type == GLSL_TYPE_INT);
@@ -291,7 +296,8 @@ ir_validate::visit_leave(ir_expression *ir)
break;
case ir_unop_u2f:
assert(ir->operands[0]->type->base_type == GLSL_TYPE_UINT);
- assert(ir->type->base_type == GLSL_TYPE_FLOAT);
+ assert(ir->type->base_type == GLSL_TYPE_HALF ||
+ ir->type->base_type == GLSL_TYPE_FLOAT);
break;
case ir_unop_i2u:
assert(ir->operands[0]->type->base_type == GLSL_TYPE_INT);
@@ -328,7 +334,8 @@ ir_validate::visit_leave(ir_expression *ir)
case ir_unop_ceil:
case ir_unop_floor:
case ir_unop_fract:
- assert(ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT ||
+ assert(ir->operands[0]->type->base_type == GLSL_TYPE_HALF ||
+ ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT ||
ir->operands[0]->type->base_type == GLSL_TYPE_DOUBLE);
assert(ir->operands[0]->type == ir->type);
break;
@@ -340,7 +347,8 @@ ir_validate::visit_leave(ir_expression *ir)
case ir_unop_dFdy:
case ir_unop_dFdy_coarse:
case ir_unop_dFdy_fine:
- assert(ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT);
+ assert(ir->operands[0]->type->base_type == GLSL_TYPE_HALF ||
+ ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT);
assert(ir->operands[0]->type == ir->type);
break;
@@ -547,9 +555,11 @@ ir_validate::visit_leave(ir_expression *ir)
break;
case ir_binop_dot:
- assert(ir->type == glsl_type::float_type ||
+ assert(ir->type == glsl_type::hfloat_type ||
+ ir->type == glsl_type::float_type ||
ir->type == glsl_type::double_type);
- assert(ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT ||
+ assert(ir->operands[0]->type->base_type == GLSL_TYPE_HALF ||
+ ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT ||
ir->operands[0]->type->base_type == GLSL_TYPE_DOUBLE);
assert(ir->operands[0]->type->is_vector());
assert(ir->operands[0]->type == ir->operands[1]->type);
@@ -602,7 +612,8 @@ ir_validate::visit_leave(ir_expression *ir)
break;
case ir_triop_fma:
- assert(ir->type->base_type == GLSL_TYPE_FLOAT ||
+ assert(ir->type->base_type == GLSL_TYPE_HALF ||
+ ir->type->base_type == GLSL_TYPE_FLOAT ||
ir->type->base_type == GLSL_TYPE_DOUBLE);
assert(ir->type == ir->operands[0]->type);
assert(ir->type == ir->operands[1]->type);
@@ -610,7 +621,8 @@ ir_validate::visit_leave(ir_expression *ir)
break;
case ir_triop_lrp:
- assert(ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT ||
+ assert(ir->operands[0]->type->base_type == GLSL_TYPE_HALF ||
+ ir->
[Mesa-dev] [RFC 04/16] glsl: Add half float type generation
Signed-off-by: Topi Pohjolainen
---
src/glsl/builtin_type_macros.h | 16 +++
src/glsl/builtin_types.cpp | 31 +
src/glsl/glsl_types.cpp| 44 +++---
src/glsl/glsl_types.h | 6 +-
4 files changed, 93 insertions(+), 4 deletions(-)
diff --git a/src/glsl/builtin_type_macros.h b/src/glsl/builtin_type_macros.h
index 8e16ae4..a20198d 100644
--- a/src/glsl/builtin_type_macros.h
+++ b/src/glsl/builtin_type_macros.h
@@ -48,6 +48,22 @@ DECL_TYPE(uvec2, GL_UNSIGNED_INT_VEC2, GLSL_TYPE_UINT, 2, 1)
DECL_TYPE(uvec3, GL_UNSIGNED_INT_VEC3, GLSL_TYPE_UINT, 3, 1)
DECL_TYPE(uvec4, GL_UNSIGNED_INT_VEC4, GLSL_TYPE_UINT, 4, 1)
+DECL_TYPE(hfloat, GL_FLOAT,GLSL_TYPE_HALF, 1, 1)
+DECL_TYPE(hvec2, GL_FLOAT_VEC2, GLSL_TYPE_HALF, 2, 1)
+DECL_TYPE(hvec3, GL_FLOAT_VEC3, GLSL_TYPE_HALF, 3, 1)
+DECL_TYPE(hvec4, GL_FLOAT_VEC4, GLSL_TYPE_HALF, 4, 1)
+
+DECL_TYPE(hmat2, GL_FLOAT_MAT2, GLSL_TYPE_HALF, 2, 2)
+DECL_TYPE(hmat3, GL_FLOAT_MAT3, GLSL_TYPE_HALF, 3, 3)
+DECL_TYPE(hmat4, GL_FLOAT_MAT4, GLSL_TYPE_HALF, 4, 4)
+
+DECL_TYPE(hmat2x3, GL_FLOAT_MAT2x3, GLSL_TYPE_HALF, 3, 2)
+DECL_TYPE(hmat2x4, GL_FLOAT_MAT2x4, GLSL_TYPE_HALF, 4, 2)
+DECL_TYPE(hmat3x2, GL_FLOAT_MAT3x2, GLSL_TYPE_HALF, 2, 3)
+DECL_TYPE(hmat3x4, GL_FLOAT_MAT3x4, GLSL_TYPE_HALF, 4, 3)
+DECL_TYPE(hmat4x2, GL_FLOAT_MAT4x2, GLSL_TYPE_HALF, 2, 4)
+DECL_TYPE(hmat4x3, GL_FLOAT_MAT4x3, GLSL_TYPE_HALF, 3, 4)
+
DECL_TYPE(float, GL_FLOAT,GLSL_TYPE_FLOAT, 1, 1)
DECL_TYPE(vec2, GL_FLOAT_VEC2, GLSL_TYPE_FLOAT, 2, 1)
DECL_TYPE(vec3, GL_FLOAT_VEC3, GLSL_TYPE_FLOAT, 3, 1)
diff --git a/src/glsl/builtin_types.cpp b/src/glsl/builtin_types.cpp
index d92e2eb..de2c476 100644
--- a/src/glsl/builtin_types.cpp
+++ b/src/glsl/builtin_types.cpp
@@ -145,6 +145,21 @@ const static struct builtin_type_versions {
T(uvec2, 130, 300)
T(uvec3, 130, 300)
T(uvec4, 130, 300)
+
+ T(hfloat, 110, 100)
+ T(hvec2, 110, 100)
+ T(hvec3, 110, 100)
+ T(hvec4, 110, 100)
+ T(hmat2, 110, 100)
+ T(hmat3, 110, 100)
+ T(hmat4, 110, 100)
+ T(hmat2x3, 120, 300)
+ T(hmat2x4, 120, 300)
+ T(hmat3x2, 120, 300)
+ T(hmat3x4, 120, 300)
+ T(hmat4x2, 120, 300)
+ T(hmat4x3, 120, 300)
+
T(float, 110, 100)
T(vec2,110, 100)
T(vec3,110, 100)
@@ -391,5 +406,21 @@ _mesa_glsl_initialize_types(struct _mesa_glsl_parse_state
*state)
add_type(symbols, glsl_type::dmat4x2_type);
add_type(symbols, glsl_type::dmat4x3_type);
}
+
+ if (state->es_shader) {
+ add_type(symbols, glsl_type::hfloat_type);
+ add_type(symbols, glsl_type::hvec2_type);
+ add_type(symbols, glsl_type::hvec3_type);
+ add_type(symbols, glsl_type::hvec4_type);
+ add_type(symbols, glsl_type::hmat2_type);
+ add_type(symbols, glsl_type::hmat3_type);
+ add_type(symbols, glsl_type::hmat4_type);
+ add_type(symbols, glsl_type::hmat2x3_type);
+ add_type(symbols, glsl_type::hmat2x4_type);
+ add_type(symbols, glsl_type::hmat3x2_type);
+ add_type(symbols, glsl_type::hmat3x4_type);
+ add_type(symbols, glsl_type::hmat4x2_type);
+ add_type(symbols, glsl_type::hmat4x3_type);
+ }
}
/** @} */
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 51bc19c..647eb4a 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -283,6 +283,8 @@ const glsl_type *glsl_type::get_base_type() const
return uint_type;
case GLSL_TYPE_INT:
return int_type;
+ case GLSL_TYPE_HALF:
+ return hfloat_type;
case GLSL_TYPE_FLOAT:
return float_type;
case GLSL_TYPE_DOUBLE:
@@ -309,6 +311,8 @@ const glsl_type *glsl_type::get_scalar_type() const
return uint_type;
case GLSL_TYPE_INT:
return int_type;
+ case GLSL_TYPE_HALF:
+ return hfloat_type;
case GLSL_TYPE_FLOAT:
return float_type;
case GLSL_TYPE_DOUBLE:
@@ -387,6 +391,18 @@ glsl_type::glsl_type(const glsl_type *array, unsigned
length) :
const glsl_type *
+glsl_type::hvec(unsigned components)
+{
+ if (components == 0 || components > 4)
+ return error_type;
+
+ static const glsl_type *const ts[] = {
+ hfloat_type, hvec2_type, hvec3_type, hvec4_type
+ };
+ return ts[components - 1];
+}
+
+const glsl_type *
glsl_type::vec(unsigned components)
{
if (components == 0 || components > 4)
@@ -466,6 +482,8 @@ glsl_type::get_instance(unsigned base_type, unsigned rows,
unsigned columns)
[Mesa-dev] [RFC 07/16] glsl: Add ubo lowering support for half floats
Signed-off-by: Topi Pohjolainen
---
src/glsl/lower_ubo_reference.cpp | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/glsl/lower_ubo_reference.cpp b/src/glsl/lower_ubo_reference.cpp
index 4ea4ccb..15e783b 100644
--- a/src/glsl/lower_ubo_reference.cpp
+++ b/src/glsl/lower_ubo_reference.cpp
@@ -516,7 +516,8 @@ lower_ubo_reference_visitor::emit_ubo_loads(ir_dereference
*deref,
/* We're dereffing a column out of a row-major matrix, so we
* gather the vector from each stored row.
*/
- assert(deref->type->base_type == GLSL_TYPE_FLOAT ||
+ assert(deref->type->base_type == GLSL_TYPE_HALF ||
+ deref->type->base_type == GLSL_TYPE_FLOAT ||
deref->type->base_type == GLSL_TYPE_DOUBLE);
/* Matrices, row_major or not, are stored as if they were
* arrays of vectors of the appropriate size in std140.
@@ -527,8 +528,13 @@ lower_ubo_reference_visitor::emit_ubo_loads(ir_dereference
*deref,
assert(matrix_columns <= 4);
unsigned matrix_stride = glsl_align(matrix_columns * N, 16);
- const glsl_type *ubo_type = deref->type->base_type == GLSL_TYPE_FLOAT ?
- glsl_type::float_type : glsl_type::double_type;
+ const glsl_type *ubo_type;
+ switch (deref->type->base_type) {
+ case GLSL_TYPE_HALF: ubo_type = glsl_type::hfloat_type; break;
+ case GLSL_TYPE_FLOAT: ubo_type = glsl_type::float_type; break;
+ case GLSL_TYPE_DOUBLE: ubo_type = glsl_type::double_type; break;
+ default: unreachable("Matrices are only defined for float types");
+ }
for (unsigned i = 0; i < deref->type->vector_elements; i++) {
ir_rvalue *chan_offset =
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 10/16] nir: Introduce half float opcodes
Signed-off-by: Topi Pohjolainen
---
src/glsl/nir/nir.h | 2 +
src/glsl/nir/nir_constant_expressions.py | 8 +++-
src/glsl/nir/nir_opcodes.py | 78 +++-
3 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 697d37e..3c9d5ba 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -642,6 +642,7 @@ void nir_alu_dest_copy(nir_alu_dest *dest, const
nir_alu_dest *src,
typedef enum {
nir_type_invalid = 0, /* Not a valid type */
nir_type_float,
+ nir_type_hfloat,
nir_type_int,
nir_type_unsigned,
nir_type_bool
@@ -1064,6 +1065,7 @@ nir_tex_instr_src_index(nir_tex_instr *instr,
nir_tex_src_type type)
typedef struct {
union {
float f[4];
+ float h[4];
int32_t i[4];
uint32_t u[4];
};
diff --git a/src/glsl/nir/nir_constant_expressions.py
b/src/glsl/nir/nir_constant_expressions.py
index bf82fe5..6e570d1 100644
--- a/src/glsl/nir/nir_constant_expressions.py
+++ b/src/glsl/nir/nir_constant_expressions.py
@@ -31,6 +31,12 @@ template = """\
#include "util/rounding.h" /* for _mesa_roundeven */
#include "nir_constant_expressions.h"
+/**
+ * Constant values for half floats are treated as normal single precision
+ * floats in compile time.
+ */
+#define hfloat float
+
#if defined(_MSC_VER) && (_MSC_VER < 1800)
static int isnormal(double x)
{
@@ -224,7 +230,7 @@ unpack_half_1x16(uint16_t u)
}
/* Some typed vector structures to make things like src0.y work */
-% for type in ["float", "int", "unsigned", "bool"]:
+% for type in ["float", "hfloat", "int", "unsigned", "bool"]:
struct ${type}_vec {
${type} x;
${type} y;
diff --git a/src/glsl/nir/nir_opcodes.py b/src/glsl/nir/nir_opcodes.py
index 56e96d9..766bfd9 100644
--- a/src/glsl/nir/nir_opcodes.py
+++ b/src/glsl/nir/nir_opcodes.py
@@ -89,6 +89,7 @@ class Opcode(object):
# helper variables for strings
tfloat = "float"
+thalf = "hfloat"
tint = "int"
tbool = "bool"
tunsigned = "unsigned"
@@ -136,70 +137,106 @@ def unop_reduce(name, output_size, output_type,
input_type, prereduce_expr,
final(reduce_(reduce_(src0, src1), reduce_(src2, src3
-# These two move instructions differ in what modifiers they support and what
+# These three move instructions differ in what modifiers they support and what
# the negate modifier means. Otherwise, they are identical.
unop("fmov", tfloat, "src0")
+unop("hmov", thalf, "src0")
unop("imov", tint, "src0")
unop("ineg", tint, "-src0")
unop("fneg", tfloat, "-src0")
+unop("hneg", thalf, "-src0")
unop("inot", tint, "~src0") # invert every bit of the integer
unop("fnot", tfloat, "(src0 == 0.0f) ? 1.0f : 0.0f")
+unop("hnot", thalf, "(src0 == 0.0f) ? 1.0f : 0.0f")
unop("fsign", tfloat, "(src0 == 0.0f) ? 0.0f : ((src0 > 0.0f) ? 1.0f : -1.0f)")
+unop("hsign", thalf, "(src0 == 0.0f) ? 0.0f : ((src0 > 0.0f) ? 1.0f : -1.0f)")
unop("isign", tint, "(src0 == 0) ? 0 : ((src0 > 0) ? 1 : -1)")
unop("iabs", tint, "(src0 < 0) ? -src0 : src0")
unop("fabs", tfloat, "fabsf(src0)")
+unop("habs", thalf, "fabsf(src0)")
unop("fsat", tfloat, "(src0 > 1.0f) ? 1.0f : ((src0 <= 0.0f) ? 0.0f : src0)")
+unop("hsat", thalf, "(src0 > 1.0f) ? 1.0f : ((src0 <= 0.0f) ? 0.0f : src0)")
unop("frcp", tfloat, "1.0f / src0")
+unop("hrcp", thalf, "1.0f / src0")
unop("frsq", tfloat, "1.0f / sqrtf(src0)")
+unop("hrsq", thalf, "1.0f / sqrtf(src0)")
unop("fsqrt", tfloat, "sqrtf(src0)")
+unop("hsqrt", thalf, "sqrtf(src0)")
unop("fexp2", tfloat, "exp2f(src0)")
+unop("hexp2", thalf, "exp2f(src0)")
unop("flog2", tfloat, "log2f(src0)")
+unop("hlog2", thalf, "log2f(src0)")
unop_convert("f2i", tfloat, tint, "src0") # Float-to-integer conversion.
+unop_convert("h2i", thalf, tint, "src0") # Float-to-integer conversion.
unop_convert("f2u", tfloat, tunsigned, "src0") # Float-to-unsigned conversion
+unop_convert("h2u", thalf, tunsigned, "src0") # Float-to-unsigned conversion
unop_convert("i2f", tint, tfloat, "src0") # Integer-to-float conversion.
+unop_convert("i2h", tint, thalf, "src0") # Integer-to-float conversion.
+unop_convert("h2f", thalf, tfloat, "src0") # Half-to-float conversion.
+unop_convert("f2h", tfloat, thalf, "src0") # Float-to-half conversion.
# Float-to-boolean conversion
unop_convert("f2b", tfloat, tbool, "src0 != 0.0f")
+unop_convert("h2b", thalf, tbool, "src0 != 0.0f")
# Boolean-to-float conversion
unop_convert("b2f", tbool, tfloat, "src0 ? 1.0f : 0.0f")
+unop_convert("b2h", tbool, thalf, "src0 ? 1.0f : 0.0f")
# Int-to-boolean conversion
unop_convert("i2b", tint, tbool, "src0 != 0")
unop_convert("b2i", tbool, tint, "src0 ? 1 : 0") # Boolean-to-int conversion
unop_convert("u2f", tunsigned, tfloat, "src0") #Unsigned-to-float conversion.
+unop_convert("u2h", tunsigned, thalf, "src0") #Unsigned-to-float conversion.
unop_reduce("bany", 1, tbool, tbool, "{src}", "{src0} || {src1}", "{src}")
unop_reduce("ball", 1, tbool, tbool, "{src}
[Mesa-dev] [RFC 14/16] nir: Consider float precision when deciding between uint/float
Signed-off-by: Topi Pohjolainen
---
src/glsl/nir/glsl_to_nir.cpp | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index 5da4122..4cb250a 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -883,6 +883,11 @@ nir_visitor::emit(nir_op op, unsigned dest_size, nir_src
src1,
(type) == GLSL_TYPE_INT ? nir_op_i ## suffix : \
nir_op_u ## suffix
+#define OP_FLT_UINT(type, suffix) \
+ (type) == GLSL_TYPE_HALF ? nir_op_h ## suffix : \
+ (type) == GLSL_TYPE_FLOAT ? nir_op_f ## suffix : \
+ nir_op_u ## suffix
+
void
nir_visitor::visit(ir_expression *ir)
{
@@ -1239,10 +1244,7 @@ nir_visitor::visit(ir_expression *ir)
op = OP_FLT_INT_UINT(out_type, div);
break;
case ir_binop_mod:
- if (out_type == GLSL_TYPE_FLOAT)
-op = nir_op_fmod;
- else
-op = nir_op_umod;
+ op = OP_FLT_UINT(out_type, mod);
break;
case ir_binop_min:
op = OP_FLT_INT_UINT(out_type, min);
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 11/16] nir: Consider float precision when deciding between int/float
Signed-off-by: Topi Pohjolainen
---
src/glsl/nir/glsl_to_nir.cpp | 39 +--
1 file changed, 13 insertions(+), 26 deletions(-)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index 7a20e1a..1267475 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -867,6 +867,11 @@ nir_visitor::emit(nir_op op, unsigned dest_size, nir_src
src1,
return emit(op, dest_size, srcs);
}
+#define OP_FLT_INT(type, suffix) \
+ (type) == GLSL_TYPE_HALF ? nir_op_h ## suffix : \
+ (type) == GLSL_TYPE_FLOAT ? nir_op_f ## suffix : \
+ nir_op_i ## suffix
+
void
nir_visitor::visit(ir_expression *ir)
{
@@ -1020,20 +1025,17 @@ nir_visitor::visit(ir_expression *ir)
emit(supports_ints ? nir_op_inot : nir_op_fnot, dest_size, srcs);
break;
case ir_unop_neg:
- instr = emit(types[0] == GLSL_TYPE_FLOAT ? nir_op_fneg : nir_op_ineg,
- dest_size, srcs);
+ instr = emit(OP_FLT_INT(types[0], neg), dest_size, srcs);
break;
case ir_unop_abs:
- instr = emit(types[0] == GLSL_TYPE_FLOAT ? nir_op_fabs : nir_op_iabs,
- dest_size, srcs);
+ instr = emit(OP_FLT_INT(types[0], abs), dest_size, srcs);
break;
case ir_unop_saturate:
assert(types[0] == GLSL_TYPE_FLOAT);
instr = emit(nir_op_fsat, dest_size, srcs);
break;
case ir_unop_sign:
- emit(types[0] == GLSL_TYPE_FLOAT ? nir_op_fsign : nir_op_isign,
- dest_size, srcs);
+ instr = emit(OP_FLT_INT(types[0], sign), dest_size, srcs);
break;
case ir_unop_rcp: emit(nir_op_frcp, dest_size, srcs); break;
case ir_unop_rsq: emit(nir_op_frsq, dest_size, srcs); break;
@@ -1214,22 +1216,13 @@ nir_visitor::visit(ir_expression *ir)
case ir_binop_rshift:
switch (ir->operation) {
case ir_binop_add:
- if (out_type == GLSL_TYPE_FLOAT)
-op = nir_op_fadd;
- else
-op = nir_op_iadd;
+ op = OP_FLT_INT(out_type, add);
break;
case ir_binop_sub:
- if (out_type == GLSL_TYPE_FLOAT)
-op = nir_op_fsub;
- else
-op = nir_op_isub;
+ op = OP_FLT_INT(out_type, sub);
break;
case ir_binop_mul:
- if (out_type == GLSL_TYPE_FLOAT)
-op = nir_op_fmul;
- else
-op = nir_op_imul;
+ op = OP_FLT_INT(out_type, mul);
break;
case ir_binop_div:
if (out_type == GLSL_TYPE_FLOAT)
@@ -1380,20 +1373,14 @@ nir_visitor::visit(ir_expression *ir)
break;
case ir_binop_equal:
if (supports_ints) {
- if (types[0] == GLSL_TYPE_FLOAT)
-emit(nir_op_feq, dest_size, srcs);
- else
-emit(nir_op_ieq, dest_size, srcs);
+ instr = emit(OP_FLT_INT(types[0], eq), dest_size, srcs);
} else {
emit(nir_op_seq, dest_size, srcs);
}
break;
case ir_binop_nequal:
if (supports_ints) {
- if (types[0] == GLSL_TYPE_FLOAT)
-emit(nir_op_fne, dest_size, srcs);
- else
-emit(nir_op_ine, dest_size, srcs);
+ instr = emit(OP_FLT_INT(types[0], ne), dest_size, srcs);
} else {
emit(nir_op_sne, dest_size, srcs);
}
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] RFC: Supporting mediump in NIR
I wanted to kick-off discussion on how to support floating point precision qualifiers in NIR. This is purely on optimization for GLES where one can reduce the number of GPU cycles. At the moment the compiler discards the qualifiers early when abstract syntax tree (AST) is transformed into intermediate presentation (IR). Iago added the initial support to IR in order to check that the stages agree on the precision. Naturally I started by rebasing his work on master (I dropped the actual checking part as it didn't automatically fit into master). I realized that it isn't sufficient to have the precision tracked in ir_variable alone. When the IR is further translated into NIR the precision is needed in ir_rvalue as well when NIR decides which opcode to use. Iago's patch isn't needed for the solution here afterall, I just included it to for context sake. Now, there are number of implementation alternatives, I think, both in AST/IR as well is in NIR. I thought I play with one approach to provide something "real" to aid the decision making regarding the architecture. I thought that despite fp16 (medium precision float) isn't really a proper type in glsl, it would clearer if it were one internally in the compiler though. I kept thinking fp64 and how I would introduce that into NIR. The first step was to do pretty much the same as what Dave Airlie did for doubles (fp64) in the compiler frontend. Then in NIR I decided to introduce new opcodes for half floats instead of modifying the existing float instructions to carry additional information about the precision. I would guess that there are drivers that are not really interested on this and hence we should means for the drivers to tell if the precision is to be taken into account or not. One natural place would be in patch number nine. This is just one example of details missing in the proposal - these patches are only meant to give a rough idea how the approach chosen would look like. Iago Toral Quiroga (1): glsl: Add tracking for GLSL precision qualifiers Topi Pohjolainen (15): glsl: Add half float type mesa: Add half float uniform support glsl: Add half float type generation glsl: Allow half float type to be used where-ever float is supported glsl: Add support for half floats in optimization passes glsl: Add ubo lowering support for half floats glsl: Add support for half float loop control glsl/ast: Use half float type for medium and low precisions nir: Introduce half float opcodes nir: Consider float precision when deciding between int/float nir: Consider float precision when deciding between int/float: part2 nir: Consider float precision when deciding between uint/int/float nir: Consider float precision when deciding between uint/float nir: Consider float precision when deciding opcode nir: Consider float precision when deciding opcode: part 2 src/glsl/ast_to_hir.cpp| 29 ++- src/glsl/builtin_type_macros.h | 16 ++ src/glsl/builtin_types.cpp | 31 +++ src/glsl/glsl_types.cpp| 50 - src/glsl/glsl_types.h | 29 ++- src/glsl/ir.h | 13 ++ src/glsl/ir_clone.cpp | 1 + src/glsl/ir_print_visitor.cpp | 1 + src/glsl/ir_validate.cpp | 36 ++-- src/glsl/link_uniform_initializers.cpp | 2 + src/glsl/loop_controls.cpp | 1 + src/glsl/lower_ubo_reference.cpp | 12 +- src/glsl/nir/glsl_to_nir.cpp | 258 +++-- src/glsl/nir/nir.h | 2 + src/glsl/nir/nir_constant_expressions.py | 8 +- src/glsl/nir/nir_lower_io.c| 1 + src/glsl/nir/nir_opcodes.py| 78 +++- src/glsl/opt_algebraic.cpp | 11 +- src/glsl/opt_constant_propagation.cpp | 1 + src/glsl/opt_minmax.cpp| 2 + src/mesa/drivers/dri/i965/brw_fs.cpp | 1 + src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 1 + src/mesa/drivers/dri/i965/brw_shader.cpp | 1 + src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 1 + src/mesa/main/uniform_query.cpp| 5 +- src/mesa/program/ir_to_mesa.cpp| 3 + 26 files changed, 413 insertions(+), 181 deletions(-) -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 06/16] glsl: Add support for half floats in optimization passes
Signed-off-by: Topi Pohjolainen
---
src/glsl/ir_print_visitor.cpp | 1 +
src/glsl/opt_algebraic.cpp| 11 ---
src/glsl/opt_constant_propagation.cpp | 1 +
src/glsl/opt_minmax.cpp | 2 ++
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/glsl/ir_print_visitor.cpp b/src/glsl/ir_print_visitor.cpp
index 01f52e8..1727855 100644
--- a/src/glsl/ir_print_visitor.cpp
+++ b/src/glsl/ir_print_visitor.cpp
@@ -424,6 +424,7 @@ void ir_print_visitor::visit(ir_constant *ir)
switch (ir->type->base_type) {
case GLSL_TYPE_UINT: fprintf(f, "%u", ir->value.u[i]); break;
case GLSL_TYPE_INT: fprintf(f, "%d", ir->value.i[i]); break;
+case GLSL_TYPE_HALF:
case GLSL_TYPE_FLOAT:
if (ir->value.f[i] == 0.0f)
/* 0.0 == -0.0, so print with %f to get the proper sign. */
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index fa5db70..8555d00 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -125,7 +125,8 @@ is_valid_vec_const(ir_constant *ir)
static inline bool
is_less_than_one(ir_constant *ir)
{
- assert(ir->type->base_type == GLSL_TYPE_FLOAT);
+ assert(ir->type->base_type == GLSL_TYPE_HALF ||
+ ir->type->base_type == GLSL_TYPE_FLOAT);
if (!is_valid_vec_const(ir))
return false;
@@ -142,7 +143,8 @@ is_less_than_one(ir_constant *ir)
static inline bool
is_greater_than_zero(ir_constant *ir)
{
- assert(ir->type->base_type == GLSL_TYPE_FLOAT);
+ assert(ir->type->base_type == GLSL_TYPE_HALF ||
+ ir->type->base_type == GLSL_TYPE_FLOAT);
if (!is_valid_vec_const(ir))
return false;
@@ -602,6 +604,7 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
case ir_binop_div:
if (is_vec_one(op_const[0]) && (
+ir->type->base_type == GLSL_TYPE_HALF ||
ir->type->base_type == GLSL_TYPE_FLOAT ||
ir->type->base_type == GLSL_TYPE_DOUBLE)) {
return new(mem_ctx) ir_expression(ir_unop_rcp,
@@ -798,7 +801,8 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
case ir_binop_min:
case ir_binop_max:
- if (ir->type->base_type != GLSL_TYPE_FLOAT || options->EmitNoSat)
+ if ((ir->type->base_type != GLSL_TYPE_HALF &&
+ ir->type->base_type != GLSL_TYPE_FLOAT) || options->EmitNoSat)
break;
/* Replace min(max) operations and its commutative combinations with
@@ -920,6 +924,7 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
ir_constant *one;
switch (ir->type->base_type) {
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_FLOAT:
one = new(mem_ctx) ir_constant(1.0f, op2_components);
break;
diff --git a/src/glsl/opt_constant_propagation.cpp
b/src/glsl/opt_constant_propagation.cpp
index 90cc0c8..e81a288 100644
--- a/src/glsl/opt_constant_propagation.cpp
+++ b/src/glsl/opt_constant_propagation.cpp
@@ -191,6 +191,7 @@ ir_constant_propagation_visitor::handle_rvalue(ir_rvalue
**rvalue)
}
switch (type->base_type) {
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_FLOAT:
data.f[i] = found->constant->value.f[rhs_channel];
break;
diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 23d0b10..6295d0c 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -125,6 +125,7 @@ compare_components(ir_constant *a, ir_constant *b)
else
foundequal = true;
break;
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_FLOAT:
if (a->value.f[c0] < b->value.f[c1])
foundless = true;
@@ -181,6 +182,7 @@ combine_constant(bool ismin, ir_constant *a, ir_constant *b)
(!ismin && b->value.i[i] > c->value.i[i]))
c->value.i[i] = b->value.i[i];
break;
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_FLOAT:
if ((ismin && b->value.f[i] < c->value.f[i]) ||
(!ismin && b->value.f[i] > c->value.f[i]))
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 16/16] nir: Consider float precision when deciding opcode: part 2
Signed-off-by: Topi Pohjolainen
---
src/glsl/nir/glsl_to_nir.cpp | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index b4777aa..14c4324 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -1185,37 +1185,37 @@ nir_visitor::visit(ir_expression *ir)
switch (ir->type->vector_elements) {
case 1:
switch (ir->operands[0]->type->vector_elements) {
-case 1: emit(nir_op_fnoise1_1, dest_size, srcs); break;
-case 2: emit(nir_op_fnoise1_2, dest_size, srcs); break;
-case 3: emit(nir_op_fnoise1_3, dest_size, srcs); break;
-case 4: emit(nir_op_fnoise1_4, dest_size, srcs); break;
+case 1: emit(OP_FLT(types[0], noise1_1), dest_size, srcs); break;
+case 2: emit(OP_FLT(types[0], noise1_2), dest_size, srcs); break;
+case 3: emit(OP_FLT(types[0], noise1_3), dest_size, srcs); break;
+case 4: emit(OP_FLT(types[0], noise1_4), dest_size, srcs); break;
default: unreachable("not reached");
}
break;
case 2:
switch (ir->operands[0]->type->vector_elements) {
-case 1: emit(nir_op_fnoise2_1, dest_size, srcs); break;
-case 2: emit(nir_op_fnoise2_2, dest_size, srcs); break;
-case 3: emit(nir_op_fnoise2_3, dest_size, srcs); break;
-case 4: emit(nir_op_fnoise2_4, dest_size, srcs); break;
+case 1: emit(OP_FLT(types[0], noise2_1), dest_size, srcs); break;
+case 2: emit(OP_FLT(types[0], noise2_2), dest_size, srcs); break;
+case 3: emit(OP_FLT(types[0], noise2_3), dest_size, srcs); break;
+case 4: emit(OP_FLT(types[0], noise2_4), dest_size, srcs); break;
default: unreachable("not reached");
}
break;
case 3:
switch (ir->operands[0]->type->vector_elements) {
-case 1: emit(nir_op_fnoise3_1, dest_size, srcs); break;
-case 2: emit(nir_op_fnoise3_2, dest_size, srcs); break;
-case 3: emit(nir_op_fnoise3_3, dest_size, srcs); break;
-case 4: emit(nir_op_fnoise3_4, dest_size, srcs); break;
+case 1: emit(OP_FLT(types[0], noise3_1), dest_size, srcs); break;
+case 2: emit(OP_FLT(types[0], noise3_2), dest_size, srcs); break;
+case 3: emit(OP_FLT(types[0], noise3_3), dest_size, srcs); break;
+case 4: emit(OP_FLT(types[0], noise3_4), dest_size, srcs); break;
default: unreachable("not reached");
}
break;
case 4:
switch (ir->operands[0]->type->vector_elements) {
-case 1: emit(nir_op_fnoise4_1, dest_size, srcs); break;
-case 2: emit(nir_op_fnoise4_2, dest_size, srcs); break;
-case 3: emit(nir_op_fnoise4_3, dest_size, srcs); break;
-case 4: emit(nir_op_fnoise4_4, dest_size, srcs); break;
+case 1: emit(OP_FLT(types[0], noise4_1), dest_size, srcs); break;
+case 2: emit(OP_FLT(types[0], noise4_2), dest_size, srcs); break;
+case 3: emit(OP_FLT(types[0], noise4_3), dest_size, srcs); break;
+case 4: emit(OP_FLT(types[0], noise4_4), dest_size, srcs); break;
default: unreachable("not reached");
}
break;
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 02/16] glsl: Add half float type
Signed-off-by: Topi Pohjolainen
---
src/glsl/ast_to_hir.cpp| 1 +
src/glsl/glsl_types.cpp| 2 ++
src/glsl/glsl_types.h | 9 +
src/glsl/ir_clone.cpp | 1 +
src/glsl/link_uniform_initializers.cpp | 2 ++
src/glsl/nir/nir_lower_io.c| 1 +
src/mesa/drivers/dri/i965/brw_fs.cpp | 1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 1 +
src/mesa/drivers/dri/i965/brw_shader.cpp | 1 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 1 +
src/mesa/program/ir_to_mesa.cpp| 3 +++
11 files changed, 23 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 7d5bb1d..332de5b 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -916,6 +916,7 @@ do_comparison(void *mem_ctx, int operation, ir_rvalue *op0,
ir_rvalue *op1)
join_op = ir_binop_logic_or;
switch (op0->type->base_type) {
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_FLOAT:
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT:
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 46c8bf1..51bc19c 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -936,6 +936,7 @@ glsl_type::component_slots() const
switch (this->base_type) {
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT:
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_FLOAT:
case GLSL_TYPE_BOOL:
return this->components();
@@ -1312,6 +1313,7 @@ glsl_type::count_attribute_slots() const
switch (this->base_type) {
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT:
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_FLOAT:
case GLSL_TYPE_BOOL:
case GLSL_TYPE_DOUBLE:
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index 25c4d30..86686e3 100644
--- a/src/glsl/glsl_types.h
+++ b/src/glsl/glsl_types.h
@@ -49,6 +49,7 @@ _mesa_glsl_release_types(void);
enum glsl_base_type {
GLSL_TYPE_UINT = 0,
GLSL_TYPE_INT,
+ GLSL_TYPE_HALF,
GLSL_TYPE_FLOAT,
GLSL_TYPE_DOUBLE,
GLSL_TYPE_BOOL,
@@ -450,6 +451,14 @@ struct glsl_type {
}
/**
+* Query whether or not a type is a double type
+*/
+ bool is_half() const
+ {
+ return base_type == GLSL_TYPE_HALF;
+ }
+
+ /**
* Query whether or not a type is a non-array boolean type
*/
bool is_boolean() const
diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index 914e0e4..f1ef351 100644
--- a/src/glsl/ir_clone.cpp
+++ b/src/glsl/ir_clone.cpp
@@ -326,6 +326,7 @@ ir_constant::clone(void *mem_ctx, struct hash_table *ht)
const
switch (this->type->base_type) {
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT:
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_FLOAT:
case GLSL_TYPE_DOUBLE:
case GLSL_TYPE_BOOL:
diff --git a/src/glsl/link_uniform_initializers.cpp
b/src/glsl/link_uniform_initializers.cpp
index 6907384..fbdefa1 100644
--- a/src/glsl/link_uniform_initializers.cpp
+++ b/src/glsl/link_uniform_initializers.cpp
@@ -72,6 +72,8 @@ copy_constant_to_storage(union gl_constant_value *storage,
case GLSL_TYPE_SAMPLER:
storage[i].i = val->value.i[i];
break;
+ case GLSL_TYPE_HALF:
+ /* Half float constants are treated in the compiler as floats. */
case GLSL_TYPE_FLOAT:
storage[i].f = val->value.f[i];
break;
diff --git a/src/glsl/nir/nir_lower_io.c b/src/glsl/nir/nir_lower_io.c
index 03eed04..28ba7d2 100644
--- a/src/glsl/nir/nir_lower_io.c
+++ b/src/glsl/nir/nir_lower_io.c
@@ -48,6 +48,7 @@ type_size(const struct glsl_type *type)
switch (glsl_get_base_type(type)) {
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT:
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_FLOAT:
case GLSL_TYPE_BOOL:
return glsl_get_components(type);
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 3414d92..1385673 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -670,6 +670,7 @@ fs_visitor::type_size(const struct glsl_type *type)
case GLSL_TYPE_VOID:
case GLSL_TYPE_ERROR:
case GLSL_TYPE_INTERFACE:
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_DOUBLE:
unreachable("not reached");
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 78f269e..4b29b56 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1344,6 +1344,7 @@ fs_visitor::emit_assignment_writes(fs_reg &l, fs_reg &r,
case GLSL_TYPE_ATOMIC_UINT:
break;
+ case GLSL_TYPE_HALF:
case GLSL_TYPE_DOUBLE:
case GLSL_TYPE_VOID:
case GLSL_TYPE_ERROR:
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index c1fd859..f3c115f 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -350,6 +350,7 @@ brw_type_for_base_type(
Re: [Mesa-dev] [PATCH 04/15] egl: import headers from Khronos EGL registry
Hi,
On 14 May 2015 at 23:33, Emil Velikov wrote:
> Hi Marek,
> On 12/05/15 22:54, Marek Olšák wrote:
>> -#elif defined(__WINSCW__) || defined(__SYMBIAN32__) /* Symbian */
>> +#elif defined(__APPLE__) || defined(__WINSCW__) || defined(__SYMBIAN32__)
>> /* Symbian */
>>
>> typedef int EGLNativeDisplayType;
>> typedef void *EGLNativeWindowType;
>> typedef void *EGLNativePixmapType;
>>
>> -#elif defined(WL_EGL_PLATFORM)
>> +#elif defined(__ANDROID__) || defined(ANDROID)
>>
>> -typedef struct wl_display *EGLNativeDisplayType;
>> -typedef struct wl_egl_pixmap *EGLNativePixmapType;
>> -typedef struct wl_egl_window *EGLNativeWindowType;
>> +#include
>>
>> -#elif defined(__GBM__)
>> -
>> -typedef struct gbm_device *EGLNativeDisplayType;
>> -typedef struct gbm_bo *EGLNativePixmapType;
>> -typedef void *EGLNativeWindowType;
>> -
>> -#elif defined(ANDROID) /* Android */
>> -
>> -struct ANativeWindow;
>> struct egl_native_pixmap_t;
>>
>> -typedef struct ANativeWindow*EGLNativeWindowType;
>> -typedef struct egl_native_pixmap_t *EGLNativePixmapType;
>> -typedef void*EGLNativeDisplayType;
>> +typedef struct ANativeWindow* EGLNativeWindowType;
>> +typedef struct egl_native_pixmap_t* EGLNativePixmapType;
>> +typedef void* EGLNativeDisplayType;
>>
>> #elif defined(__unix__)
>>
>> -#if defined(MESA_EGL_NO_X11_HEADERS)
>> -
>> -typedef void*EGLNativeDisplayType;
>> -typedef khronos_uintptr_t EGLNativePixmapType;
>> -typedef khronos_uintptr_t EGLNativeWindowType;
>> -
>> -#else
>> -
>> /* X11 (tentative) */
>> #include
>> #include
>> @@ -122,18 +103,8 @@ typedef Display *EGLNativeDisplayType;
>> typedef Pixmap EGLNativePixmapType;
>> typedef Window EGLNativeWindowType;
>>
>> -#endif /* MESA_EGL_NO_X11_HEADERS */
>> -
>> -#elif __HAIKU__
>> -#include
>> -typedef void *EGLNativeDisplayType;
>> -typedef khronos_uintptr_t EGLNativePixmapType;
>> -typedef khronos_uintptr_t EGLNativeWindowType;
>> -
> Upon closer look, one could get away with the above changes, although
> there may be something more subtle to it.
>
> Kristian, Chad,
>
> Would you have any suggestions for/against nuking the Wayland/GBM/other
> typedefs ? With an extra eye on the Haiku changes, what would it take to
> get the current eglplatform.h (or equivalent) accepted with Khronos ?
No objection from me; I don't know of anyone using Wayland/GBM.
Android might (will) be harder to get away with though. Luckily for
us, platform_base should hopefully prevent people from ever trying
silly Native{Display,Window}Type hacks on Wayland/GBM.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): 57 new commits
On Friday 15 May 2015, Michel Dänzer wrote: > On 14.05.2015 22:52, fred...@kemper.freedesktop.org (Fredrik HXXglund) > wrote: > > > > URL: > http://cgit.freedesktop.org/mesa/mesa/commit/?id=6b284f08ab399154ad10e2166440b44cbbdcb2c5 > > Author: Laura Ekstrand > > Date: Tue Feb 3 14:47:00 2015 -0800 > > > > main: _mesa_blit_framebuffer updates its arbitrary framebuffers. > > > > Previously, we used _mesa_update_state to update the currently bound > > framebuffers prior to performing a blit. Now that > > _mesa_blit_framebuffer > > uses arbitrary framebuffers, _mesa_update_state is not specific enough. > > > > Reviewed-by: Fredrik Höglund > > Signed-off-by: Fredrik Höglund > > This commit broke the piglit test > spec@ext_framebuffer_multisample@bitmap with the radeonsi driver: > > Probe color at (224,0) > Left: 0.00 0.00 0.00 1.00 > Right: 1.00 1.00 1.00 1.00 > > Looks like it's because the bottom right squares of the Xs are missing, > see the attached picture. > > Any ideas? I did notice that failure as well, but when I ran the test manually it passed for me, leading me to think that it was a spurious failure. The output looks exactly the same for me. But the test works by comparing the left and right halves of the framebuffer, so if the bottom right squares are missing on both sides, the test should pass. The left side is the test image, and the right side is the reference image. Fredrik ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90466] arm: linker error ndefined reference to `nir_metadata_preserve'
https://bugs.freedesktop.org/show_bug.cgi?id=90466 --- Comment #1 from Emil Velikov --- This issue is not ARM specific. It is present if one tries to use nir in their driver, but libnir is missing from the final link stage (i.e. targets/foo). I've had some patches that address these [1] but forgot to respin/resend them :\ Will them another go in a bit. [1] http://patchwork.freedesktop.org/bundle/evelikov/nir-lovin'/ -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] gallium/targets: Move api init into st code
Let's play it safe. Update your patch series and re-post it to the list
for a final review, please.
-Brian
On 05/14/2015 06:01 PM, Alexander von Gluck IV wrote:
Good evening Brian,
Thanks, these were fixed.
I just realized that I can drop os_thread.h from our C++ code as we no
longer depend on it and not do the extern "C" there. (tested working)
You ok with this changeset with the change above?
(I'd hate to commit it, then undo it)
Thanks!
-- Alex
On , Brian Paul wrote:
In the past, you used the prefix "target/haiku-softpipe:" on changes
to this code. I'd suggest using that again here.
With these changes,
Reviewed-by: Brian Paul
On 05/14/2015 04:39 PM, Alexander von Gluck IV wrote:
We also reduce the amount of need-to-know information about st_api
to require one less extern "C" in st_manager.h
---
.../targets/haiku-softpipe/GalliumContext.cpp | 23
+++
.../targets/haiku-softpipe/GalliumContext.h|5 +---
2 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
index b24aef7..1e3874b 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
@@ -15,14 +15,13 @@
#include "GLView.h"
#include "bitmap_wrapper.h"
-extern "C" {
+
#include "glapi/glapi.h"
#include "pipe/p_format.h"
-#include "state_tracker/st_cb_fbo.h"
-#include "state_tracker/st_cb_flush.h"
+//#include "state_tracker/st_cb_fbo.h"
+//#include "state_tracker/st_cb_flush.h"
#include "state_tracker/st_context.h"
#include "state_tracker/st_gl_api.h"
-#include "state_tracker/st_manager.h"
#include "state_tracker/sw_winsys.h"
#include "sw/hgl/hgl_sw_winsys.h"
#include "util/u_atomic.h"
@@ -30,7 +29,6 @@ extern "C" {
#include "target-helpers/inline_sw_helper.h"
#include "target-helpers/inline_debug_helper.h"
-}
#ifdef DEBUG
@@ -127,7 +125,8 @@ GalliumContext::CreateContext(Bitmap *bitmap)
context->read = NULL;
context->st = NULL;
-context->api = st_gl_api_create();
+// Create st_gl_api
+context->api = hgl_create_st_api();
if (!context->api) {
ERROR("%s: Couldn't obtain Mesa state tracker API!\n",
__func__);
return -1;
@@ -159,12 +158,10 @@ GalliumContext::CreateContext(Bitmap *bitmap)
attribs.minor = 0;
//attribs.flags |= ST_CONTEXT_FLAG_DEBUG;
-struct st_api* api = context->api;
-
// Create context using state tracker api call
enum st_context_error result;
-context->st = api->create_context(api, context->manager, &attribs,
-&result, context->st);
+context->st = context->api->create_context(context->api,
context->manager,
+&attribs, &result, context->st);
if (!context->st) {
ERROR("%s: Couldn't create mesa state tracker context!\n",
@@ -289,10 +286,8 @@ GalliumContext::SetCurrentContext(Bitmap
*bitmap, context_id contextID)
return B_ERROR;
}
-struct st_api* api = context->api;
-
if (!bitmap) {
-api->make_current(context->api, NULL, NULL, NULL);
+context->api->make_current(context->api, NULL, NULL, NULL);
return B_OK;
}
@@ -305,7 +300,7 @@ GalliumContext::SetCurrentContext(Bitmap *bitmap,
context_id contextID)
}
// We need to lock and unlock framebuffers before accessing them
-api->make_current(context->api, context->st, context->draw->stfbi,
+context->api->make_current(context->api, context->st,
context->draw->stfbi,
context->read->stfbi);
//if (context->textures[ST_ATTACHMENT_BACK_LEFT]
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.h
b/src/gallium/targets/haiku-softpipe/GalliumContext.h
index b50d528..a13c4ce 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.h
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.h
@@ -12,14 +12,11 @@
#include
#include
-extern "C" {
-//#include "state_tracker/st_api.h"
#include "pipe/p_compiler.h"
#include "pipe/p_screen.h"
#include "postprocess/filters.h"
#include "os/os_thread.h"
#include "hgl_context.h"
-}
#include "bitmap_wrapper.h"
@@ -56,6 +53,6 @@ private:
context_idfCurrentContext;
pipe_mutexfMutex;
};
-
+
#endif /* GALLIUMCONTEXT_H */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 90457] New Account Request
https://bugs.freedesktop.org/show_bug.cgi?id=90457 --- Comment #3 from Brian Paul --- Normally we don't give git privileges until after the individual has some history of submitting some good patches. Carl, is Nanley is a coworker of your's at Intel? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] gallium/targets: Move api init into st code
can-do. I actually think I spotted one more extern "C" reduction I can
do.
Thanks!
-- Alex
On , Brian Paul wrote:
Let's play it safe. Update your patch series and re-post it to the
list for a final review, please.
-Brian
On 05/14/2015 06:01 PM, Alexander von Gluck IV wrote:
Good evening Brian,
Thanks, these were fixed.
I just realized that I can drop os_thread.h from our C++ code as we no
longer depend on it and not do the extern "C" there. (tested working)
You ok with this changeset with the change above?
(I'd hate to commit it, then undo it)
Thanks!
-- Alex
On , Brian Paul wrote:
In the past, you used the prefix "target/haiku-softpipe:" on changes
to this code. I'd suggest using that again here.
With these changes,
Reviewed-by: Brian Paul
On 05/14/2015 04:39 PM, Alexander von Gluck IV wrote:
We also reduce the amount of need-to-know information about st_api
to require one less extern "C" in st_manager.h
---
.../targets/haiku-softpipe/GalliumContext.cpp | 23
+++
.../targets/haiku-softpipe/GalliumContext.h|5 +---
2 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
index b24aef7..1e3874b 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
@@ -15,14 +15,13 @@
#include "GLView.h"
#include "bitmap_wrapper.h"
-extern "C" {
+
#include "glapi/glapi.h"
#include "pipe/p_format.h"
-#include "state_tracker/st_cb_fbo.h"
-#include "state_tracker/st_cb_flush.h"
+//#include "state_tracker/st_cb_fbo.h"
+//#include "state_tracker/st_cb_flush.h"
#include "state_tracker/st_context.h"
#include "state_tracker/st_gl_api.h"
-#include "state_tracker/st_manager.h"
#include "state_tracker/sw_winsys.h"
#include "sw/hgl/hgl_sw_winsys.h"
#include "util/u_atomic.h"
@@ -30,7 +29,6 @@ extern "C" {
#include "target-helpers/inline_sw_helper.h"
#include "target-helpers/inline_debug_helper.h"
-}
#ifdef DEBUG
@@ -127,7 +125,8 @@ GalliumContext::CreateContext(Bitmap *bitmap)
context->read = NULL;
context->st = NULL;
-context->api = st_gl_api_create();
+// Create st_gl_api
+context->api = hgl_create_st_api();
if (!context->api) {
ERROR("%s: Couldn't obtain Mesa state tracker API!\n",
__func__);
return -1;
@@ -159,12 +158,10 @@ GalliumContext::CreateContext(Bitmap *bitmap)
attribs.minor = 0;
//attribs.flags |= ST_CONTEXT_FLAG_DEBUG;
-struct st_api* api = context->api;
-
// Create context using state tracker api call
enum st_context_error result;
-context->st = api->create_context(api, context->manager,
&attribs,
-&result, context->st);
+context->st = context->api->create_context(context->api,
context->manager,
+&attribs, &result, context->st);
if (!context->st) {
ERROR("%s: Couldn't create mesa state tracker context!\n",
@@ -289,10 +286,8 @@ GalliumContext::SetCurrentContext(Bitmap
*bitmap, context_id contextID)
return B_ERROR;
}
-struct st_api* api = context->api;
-
if (!bitmap) {
-api->make_current(context->api, NULL, NULL, NULL);
+context->api->make_current(context->api, NULL, NULL, NULL);
return B_OK;
}
@@ -305,7 +300,7 @@ GalliumContext::SetCurrentContext(Bitmap
*bitmap,
context_id contextID)
}
// We need to lock and unlock framebuffers before accessing
them
-api->make_current(context->api, context->st,
context->draw->stfbi,
+context->api->make_current(context->api, context->st,
context->draw->stfbi,
context->read->stfbi);
//if (context->textures[ST_ATTACHMENT_BACK_LEFT]
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.h
b/src/gallium/targets/haiku-softpipe/GalliumContext.h
index b50d528..a13c4ce 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.h
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.h
@@ -12,14 +12,11 @@
#include
#include
-extern "C" {
-//#include "state_tracker/st_api.h"
#include "pipe/p_compiler.h"
#include "pipe/p_screen.h"
#include "postprocess/filters.h"
#include "os/os_thread.h"
#include "hgl_context.h"
-}
#include "bitmap_wrapper.h"
@@ -56,6 +53,6 @@ private:
context_idfCurrentContext;
pipe_mutexfMutex;
};
-
+
#endif /* GALLIUMCONTEXT_H */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] gallium/st: Move st_api creation to st and extern "C" it
On 14/05/15 22:39, Alexander von Gluck IV wrote:
> ---
> src/gallium/state_trackers/hgl/hgl.c | 16
> src/gallium/state_trackers/hgl/hgl_context.h | 14 ++
> 2 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/state_trackers/hgl/hgl.c
> b/src/gallium/state_trackers/hgl/hgl.c
> index 77f7c22..1e804c0 100644
> --- a/src/gallium/state_trackers/hgl/hgl.c
> +++ b/src/gallium/state_trackers/hgl/hgl.c
> @@ -258,6 +258,14 @@ hgl_create_st_framebuffer(struct hgl_context* context)
> }
>
>
> +struct st_api*
> +hgl_create_st_api()
> +{
> + CALLED();
> + return st_gl_api_create();
> +}
> +
> +
I might be a sucker for simplicity, yet it seems clearer to split this
(and the actual usage of it) into a separate patch.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] gallium/targets: Move api init into st code
On 14/05/15 22:39, Alexander von Gluck IV wrote:
> We also reduce the amount of need-to-know information about st_api
> to require one less extern "C" in st_manager.h
> ---
> .../targets/haiku-softpipe/GalliumContext.cpp | 23 +++
> .../targets/haiku-softpipe/GalliumContext.h|5 +---
> 2 files changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
> b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
> index b24aef7..1e3874b 100644
> --- a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
> +++ b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
> @@ -15,14 +15,13 @@
> #include "GLView.h"
>
> #include "bitmap_wrapper.h"
> -extern "C" {
> +
> #include "glapi/glapi.h"
> #include "pipe/p_format.h"
> -#include "state_tracker/st_cb_fbo.h"
> -#include "state_tracker/st_cb_flush.h"
> +//#include "state_tracker/st_cb_fbo.h"
> +//#include "state_tracker/st_cb_flush.h"
> #include "state_tracker/st_context.h"
> #include "state_tracker/st_gl_api.h"
> -#include "state_tracker/st_manager.h"
> #include "state_tracker/sw_winsys.h"
> #include "sw/hgl/hgl_sw_winsys.h"
> #include "util/u_atomic.h"
> @@ -30,7 +29,6 @@ extern "C" {
>
> #include "target-helpers/inline_sw_helper.h"
> #include "target-helpers/inline_debug_helper.h"
> -}
>
>
> #ifdef DEBUG
> @@ -127,7 +125,8 @@ GalliumContext::CreateContext(Bitmap *bitmap)
> context->read = NULL;
> context->st = NULL;
>
> - context->api = st_gl_api_create();
> + // Create st_gl_api
> + context->api = hgl_create_st_api();
> if (!context->api) {
> ERROR("%s: Couldn't obtain Mesa state tracker API!\n",
> __func__);
> return -1;
> @@ -159,12 +158,10 @@ GalliumContext::CreateContext(Bitmap *bitmap)
> attribs.minor = 0;
> //attribs.flags |= ST_CONTEXT_FLAG_DEBUG;
>
> - struct st_api* api = context->api;
> -
> // Create context using state tracker api call
> enum st_context_error result;
> - context->st = api->create_context(api, context->manager, &attribs,
> - &result, context->st);
> + context->st = context->api->create_context(context->api,
> context->manager,
> + &attribs, &result, context->st);
>
> if (!context->st) {
> ERROR("%s: Couldn't create mesa state tracker context!\n",
> @@ -289,10 +286,8 @@ GalliumContext::SetCurrentContext(Bitmap *bitmap,
> context_id contextID)
> return B_ERROR;
> }
>
> - struct st_api* api = context->api;
> -
> if (!bitmap) {
> - api->make_current(context->api, NULL, NULL, NULL);
> + context->api->make_current(context->api, NULL, NULL, NULL);
> return B_OK;
> }
>
> @@ -305,7 +300,7 @@ GalliumContext::SetCurrentContext(Bitmap *bitmap,
> context_id contextID)
> }
>
> // We need to lock and unlock framebuffers before accessing them
> - api->make_current(context->api, context->st, context->draw->stfbi,
> + context->api->make_current(context->api, context->st,
> context->draw->stfbi,
> context->read->stfbi);
>
> //if (context->textures[ST_ATTACHMENT_BACK_LEFT]
> diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.h
> b/src/gallium/targets/haiku-softpipe/GalliumContext.h
> index b50d528..a13c4ce 100644
> --- a/src/gallium/targets/haiku-softpipe/GalliumContext.h
> +++ b/src/gallium/targets/haiku-softpipe/GalliumContext.h
> @@ -12,14 +12,11 @@
> #include
> #include
>
> -extern "C" {
> -//#include "state_tracker/st_api.h"
> #include "pipe/p_compiler.h"
> #include "pipe/p_screen.h"
> #include "postprocess/filters.h"
> #include "os/os_thread.h"
> #include "hgl_context.h"
> -}
>
> #include "bitmap_wrapper.h"
>
> @@ -56,6 +53,6 @@ private:
> context_id fCurrentContext;
> pipe_mutex fMutex;
> };
> -
> +
>
This commit does a bit too many thing (comparing to other changes in mesa)
- Whitespace cleanups
- Removing commented out headers/commenting out new ones.
- Using function introduced with earlier patch.
- Removes a couple of temporary variables.
- Drops the extern "C" guard around the header inclusion.
At the end of the day you're the one that reads/maintains this code, but
splitting it into 2+ patches seems like a reasonable thing imho.
Cheers,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Problem with ___glapi_noop_table
On 05/14/2015 11:26 AM, Shervin Sharifi wrote: Hi, I am trying to build Mesa for OpenGL ES (with llvmpipe) under windows with MSVC. I'm getting an error due to an unresolved external symbol (___glapi_noop_table). There is no definition of ___glapi_noop_table in the code. Am I missing something? Here is the configuration I'm using: LLVM=C:\llvm34 scons.py gles=yes llvm=yes platform=windows libgl-gdi gallium egl-gallium Didn't have this problem with version 10.4.x. You're building Mesa from git/master? I haven't seen this problem. I tried your config, but I get an error: scons: *** Do not know how to make File target 'egl-gallium' (C:\Users\Brian\projects\mesa\egl-gallium). Stop. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Restore functionality to dispatch sanity test
On 05/04/2015 12:32 PM, Ian Romanick wrote: On 04/29/2015 02:44 PM, Brian Paul wrote: On 04/29/2015 02:53 PM, Ian Romanick wrote: On 04/29/2015 12:07 PM, Ian Romanick wrote: From: Ian Romanick Along with a couple secondary goals, the dispatch sanity test had two major, primary goals. 1. Ensure that all functions part of an API version are set in the dispatch table. 2. Ensure that functions that cannot be part of an API version are not set in the dispatch table. Commit 4bdbb58 removed the tests ability to fulfill either of its This commit also breaks binary compatibility between old libGL and new DRI driver. $ EGL_LOG_LEVEL=debug es2_info libEGL debug: Native platform type: x11 (autodetected) libEGL debug: EGL search path is /opt/xorg-master-x86_64/lib64/egl libEGL debug: added egl_dri2 to module array libEGL debug: failed to open /home/idr/devel/graphics/Mesa/BUILD/10.4-64/lib64/i965_dri.so: /home/idr/devel/graphics/Mesa/BUILD/10.4-64/lib64/i965_dri.so: undefined symbol: _glapi_set_nop_handler That's not ok. :( Brian: Can you propose an alternate solution to your original problem that doesn't break compatibility? Otherwise, I'm going to have to just revert 4bdbb58. Please hold off on that. I'm going to be off-line until next week and won't have time to work on this until then at the earliest. As it turns out, I spent the rest of the week sick in bed, so I held off on it. :) primary goals by removing anything that used _mesa_generic_nop(). It seems like the problem on Windows could have been resolved by adding the NULL context pointer check from nop_handler to _mesa_generic_nop(). Unfortunately, no. The problem is the the OpenGL API uses __stdcall convention on Windows (the callee has to restore the stack). That means plugging a single, generic no-op handler into all dispatch slots will not work. The no-op function will not properly clean up the stack and we'll crash. We found this with a professional CAD app on Windows so the fix is critical to those users. Oh... that's annoying, but makes sense. A temporary work-around may be to only call _glapi_set_nop_handler() for Windows. Then, maybe remove the #ifdef _WIN32 at some point down the road. Either that or condition it on DRI builds. Other Mesa builds won't have this particular issue. Other loader / driver interfaces are dynamic. If we really want to enable this feature in DRI builds, we can do it. It will just require someone to do a bunch of typing. How often do you test mixing old libGL with newer drivers? I've always suspected this is a bit fragile. Nobody else seems to have noticed. Periodically. I generally have a bunch of Mesa branches built at once that I test for various things. I mostly end up using mismatched libraries when I have to use EGL because, for some reason, using non-installed libEGL is really painful. I've (finally) got a patch for this. I'd appreciate it if you could test in your particular set-up, Ian. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: do not use _glapi_new_nop_table() for DRI builds
Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
_glapi_set_nop_handler() functions in the glapi dispatcher (which
live in libGL.so). The calls to those functions from context.c
would be undefined (i.e. an ABI break) if the libGL used at runtime
was older.
For the time being, use the old single generic_nop() function for
DRI builds to avoid this problem. At some point in the future it
should be safe to remove this work-around. See comments for more
details.
---
src/mesa/main/context.c | 60 -
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 544cc14..0649708 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -883,6 +883,19 @@ update_default_objects(struct gl_context *ctx)
}
+/* XXX this is temporary and should be removed at some point in the
+ * future when there's a reasonable expectation that the libGL library
+ * contains the _glapi_new_nop_table() and _glapi_set_nop_handler()
+ * functions which were added in Mesa 10.6.
+ */
+#if defined(GLX_DIRECT_RENDERING)
+/* Avoid libGL / driver ABI break */
+#define USE_GLAPI_NOP_FEATURES 0
+#else
+#define USE_GLAPI_NOP_FEATURES 1
+#endif
+
+
/**
* This function is called by the glapi no-op functions. For each OpenGL
* function/entrypoint there's a simple no-op function. These "no-op"
@@ -898,6 +911,7 @@ update_default_objects(struct gl_context *ctx)
*
* \param name the name of the OpenGL function
*/
+#if USE_GLAPI_NOP_FEATURES
static void
nop_handler(const char *name)
{
@@ -914,6 +928,7 @@ nop_handler(const char *name)
}
#endif
}
+#endif
/**
@@ -928,6 +943,44 @@ nop_glFlush(void)
#endif
+#if !USE_GLAPI_NOP_FEATURES
+static int
+generic_nop(void)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "unsupported function called "
+ "(unsupported extension or deprecated function?)");
+ return 0;
+}
+#endif
+
+
+/**
+ * Create a new API dispatch table in which all entries point to the
+ * generic_nop() function. This will not work on Windows because of
+ * the __stdcall convention which requires the callee to clean up the
+ * call stack. That's impossible with one generic no-op function.
+ */
+#if !USE_GLAPI_NOP_FEATURES
+static struct _glapi_table *
+new_nop_table(unsigned numEntries)
+{
+ struct _glapi_table *table;
+
+ table = malloc(numEntries * sizeof(_glapi_proc));
+ if (table) {
+ _glapi_proc *entry = (_glapi_proc *) table;
+ unsigned i;
+ for (i = 0; i < numEntries; i++) {
+ entry[i] = (_glapi_proc) generic_nop;
+ }
+ }
+ return table;
+}
+#endif
+
+
/**
* Allocate and initialize a new dispatch table. The table will be
* populated with pointers to "no-op" functions. In turn, the no-op
@@ -936,12 +989,16 @@ nop_glFlush(void)
static struct _glapi_table *
alloc_dispatch_table(void)
{
+ int numEntries = MAX2(_glapi_get_dispatch_table_size(), _gloffset_COUNT);
+
+#if !USE_GLAPI_NOP_FEATURES
+ struct _glapi_table *table = new_nop_table(numEntries);
+#else
/* Find the larger of Mesa's dispatch table and libGL's dispatch table.
* In practice, this'll be the same for stand-alone Mesa. But for DRI
* Mesa we do this to accommodate different versions of libGL and various
* DRI drivers.
*/
- GLint numEntries = MAX2(_glapi_get_dispatch_table_size(), _gloffset_COUNT);
struct _glapi_table *table = _glapi_new_nop_table(numEntries);
#if defined(_WIN32)
@@ -967,6 +1024,7 @@ alloc_dispatch_table(void)
#endif
_glapi_set_nop_handler(nop_handler);
+#endif
return table;
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/15] egl: fix setting context flags
Yes, I'll add the Cc note. Marek On Fri, May 15, 2015 at 12:40 AM, Emil Velikov wrote: > On 12/05/15 22:54, Marek Olšák wrote: >> From: Marek Olšák >> >> --- >> src/egl/main/eglcontext.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/src/egl/main/eglcontext.c b/src/egl/main/eglcontext.c >> index 514b91a..e50b8fb 100644 >> --- a/src/egl/main/eglcontext.c >> +++ b/src/egl/main/eglcontext.c >> @@ -131,7 +131,7 @@ _eglParseContextAttribList(_EGLContext *ctx, _EGLDisplay >> *dpy, >> break; >> } >> >> - ctx->Flags = val; >> + ctx->Flags |= val; >> break; >> >>case EGL_CONTEXT_OPENGL_PROFILE_MASK_KHR: >> @@ -194,7 +194,8 @@ _eglParseContextAttribList(_EGLContext *ctx, _EGLDisplay >> *dpy, >> break; >> } >> >> - ctx->Flags = EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR; >> + if (val == EGL_TRUE) >> +ctx->Flags |= EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR; > Not a high priority but this seems like a stable material ? > > -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 02/16] glsl: Add half float type
On Fri, May 15, 2015 at 5:39 AM, Topi Pohjolainen
wrote:
> Signed-off-by: Topi Pohjolainen
> ---
> src/glsl/ast_to_hir.cpp| 1 +
> src/glsl/glsl_types.cpp| 2 ++
> src/glsl/glsl_types.h | 9 +
> src/glsl/ir_clone.cpp | 1 +
> src/glsl/link_uniform_initializers.cpp | 2 ++
> src/glsl/nir/nir_lower_io.c| 1 +
> src/mesa/drivers/dri/i965/brw_fs.cpp | 1 +
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 1 +
> src/mesa/drivers/dri/i965/brw_shader.cpp | 1 +
> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 1 +
> src/mesa/program/ir_to_mesa.cpp| 3 +++
> 11 files changed, 23 insertions(+)
>
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 7d5bb1d..332de5b 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -916,6 +916,7 @@ do_comparison(void *mem_ctx, int operation, ir_rvalue
> *op0, ir_rvalue *op1)
>join_op = ir_binop_logic_or;
>
> switch (op0->type->base_type) {
> + case GLSL_TYPE_HALF:
Trivial feedback:
I'd recommend calling this F16 or HALF_FLOAT -- mediump also applies
to integers, of which there ought to be U16 and S16 varieties.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Supporting mediump in NIR
On Fri, May 15, 2015 at 5:39 AM, Topi Pohjolainen wrote: > I wanted to kick-off discussion on how to support floating point > precision qualifiers in NIR. This is purely on optimization for > GLES where one can reduce the number of GPU cycles. At the moment > the compiler discards the qualifiers early when abstract syntax > tree (AST) is transformed into intermediate presentation (IR). > > Iago added the initial support to IR in order to check that the > stages agree on the precision. Naturally I started by rebasing his > work on master (I dropped the actual checking part as it didn't > automatically fit into master). I realized that it isn't sufficient > to have the precision tracked in ir_variable alone. When the IR > is further translated into NIR the precision is needed in ir_rvalue > as well when NIR decides which opcode to use. > Iago's patch isn't needed for the solution here afterall, I just > included it to for context sake. > > Now, there are number of implementation alternatives, I think, both > in AST/IR as well is in NIR. I thought I play with one approach to > provide something "real" to aid the decision making regarding the > architecture. > > I thought that despite fp16 (medium precision float) isn't really a > proper type in glsl, it would clearer if it were one internally in > the compiler though. I kept thinking fp64 and how I would introduce > that into NIR. > The first step was to do pretty much the same as what Dave Airlie > did for doubles (fp64) in the compiler frontend. > > Then in NIR I decided to introduce new opcodes for half floats > instead of modifying the existing float instructions to carry > additional information about the precision. jfwiw, I can[*] in a lot of cases have precision per operand.. for example, add a f32 + f16 with result into f32. So having separate opcodes seems kind of funny. [*] as far as I can tell.. but admittedly I haven't had any reason yet to spend time r/e'ing half-precision stuff for adreno BR, -R > I would guess that there are drivers that are not really interested > on this and hence we should means for the drivers to tell if the > precision is to be taken into account or not. One natural place > would be in patch number nine. This is just one example of details > missing in the proposal - these patches are only meant to give a > rough idea how the approach chosen would look like. > > Iago Toral Quiroga (1): > glsl: Add tracking for GLSL precision qualifiers > > Topi Pohjolainen (15): > glsl: Add half float type > mesa: Add half float uniform support > glsl: Add half float type generation > glsl: Allow half float type to be used where-ever float is supported > glsl: Add support for half floats in optimization passes > glsl: Add ubo lowering support for half floats > glsl: Add support for half float loop control > glsl/ast: Use half float type for medium and low precisions > nir: Introduce half float opcodes > nir: Consider float precision when deciding between int/float > nir: Consider float precision when deciding between int/float: part2 > nir: Consider float precision when deciding between uint/int/float > nir: Consider float precision when deciding between uint/float > nir: Consider float precision when deciding opcode > nir: Consider float precision when deciding opcode: part 2 > > src/glsl/ast_to_hir.cpp| 29 ++- > src/glsl/builtin_type_macros.h | 16 ++ > src/glsl/builtin_types.cpp | 31 +++ > src/glsl/glsl_types.cpp| 50 - > src/glsl/glsl_types.h | 29 ++- > src/glsl/ir.h | 13 ++ > src/glsl/ir_clone.cpp | 1 + > src/glsl/ir_print_visitor.cpp | 1 + > src/glsl/ir_validate.cpp | 36 ++-- > src/glsl/link_uniform_initializers.cpp | 2 + > src/glsl/loop_controls.cpp | 1 + > src/glsl/lower_ubo_reference.cpp | 12 +- > src/glsl/nir/glsl_to_nir.cpp | 258 > +++-- > src/glsl/nir/nir.h | 2 + > src/glsl/nir/nir_constant_expressions.py | 8 +- > src/glsl/nir/nir_lower_io.c| 1 + > src/glsl/nir/nir_opcodes.py| 78 +++- > src/glsl/opt_algebraic.cpp | 11 +- > src/glsl/opt_constant_propagation.cpp | 1 + > src/glsl/opt_minmax.cpp| 2 + > src/mesa/drivers/dri/i965/brw_fs.cpp | 1 + > src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 1 + > src/mesa/drivers/dri/i965/brw_shader.cpp | 1 + > src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 1 + > src/mesa/main/uniform_query.cpp| 5 +- > src/mesa/program/ir_to_mesa.cpp| 3 + > 26 files changed, 413 insertions(+), 181 deletions(-) > > -- > 1.9.3 > > _
Re: [Mesa-dev] Mesa (master): 57 new commits
On Friday 15 May 2015, Fredrik Höglund wrote:
> On Friday 15 May 2015, Michel Dänzer wrote:
> > On 14.05.2015 22:52, fred...@kemper.freedesktop.org (Fredrik HXXglund)
> > wrote:
> > >
> > > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=6b284f08ab399154ad10e2166440b44cbbdcb2c5
> > > Author: Laura Ekstrand
> > > Date: Tue Feb 3 14:47:00 2015 -0800
> > >
> > > main: _mesa_blit_framebuffer updates its arbitrary framebuffers.
> > >
> > > Previously, we used _mesa_update_state to update the currently bound
> > > framebuffers prior to performing a blit. Now that
> > > _mesa_blit_framebuffer
> > > uses arbitrary framebuffers, _mesa_update_state is not specific
> > > enough.
> > >
> > > Reviewed-by: Fredrik Höglund
> > > Signed-off-by: Fredrik Höglund
> >
> > This commit broke the piglit test
> > spec@ext_framebuffer_multisample@bitmap with the radeonsi driver:
> >
> > Probe color at (224,0)
> > Left: 0.00 0.00 0.00 1.00
> > Right: 1.00 1.00 1.00 1.00
> >
> > Looks like it's because the bottom right squares of the Xs are missing,
> > see the attached picture.
> >
> > Any ideas?
>
> I did notice that failure as well, but when I ran the test manually it
> passed for me, leading me to think that it was a spurious failure.
>
> The output looks exactly the same for me. But the test works by
> comparing the left and right halves of the framebuffer, so if the
> bottom right squares are missing on both sides, the test should
> pass.
>
> The left side is the test image, and the right side is the reference
> image.
Okay, so I've finished analyzing the failure. The glBindFramebuffer()
calls that precede the glBlitFramebuffer() call cause _NEW_BUFFERS to
be set. This used to result in _mesa_update_state() being called from
_mesa_blit_framebuffer(), which in turn would call st_invalidate_state(),
which would mark the framebuffer state as invalid. st_BlitFramebuffer()
would then call st_validate_state() which would call
update_framebuffer_state() which would call st_flush_bitmap_cache().
That call to st_flush_bitmap_cache() is what caused the rendering by the
last glBitmap() call to land in the framebuffer.
The attached patch fixes the problem by restoring the
_mesa_update_state() call. The bug can also be fixed by calling
st_flush_bitmap_cache() from st_BlitFramebuffer().
Fredrik
From 9bb1d8faaa0e943292d333ba315c21b96cb4ca4d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fredrik=20H=C3=B6glund?=
Date: Fri, 15 May 2015 17:35:52 +0200
Subject: [PATCH] mesa: Restore the _mesa_update_state call in
_mesa_blit_framebuffer
We have to set _NEW_BUFFERS and call _mesa_update_state() to ensure
that rendering is flushed to the read framebuffer before the blit.
---
src/mesa/main/blit.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/blit.c b/src/mesa/main/blit.c
index fac9724..bc01ad7 100644
--- a/src/mesa/main/blit.c
+++ b/src/mesa/main/blit.c
@@ -161,13 +161,22 @@ _mesa_blit_framebuffer(struct gl_context *ctx,
GL_DEPTH_BUFFER_BIT |
GL_STENCIL_BUFFER_BIT);
- FLUSH_VERTICES(ctx, 0);
+ /* We have to set _NEW_BUFFERS to make drivers aware that we're about
+* to render to/from a different set of buffers.
+*/
+ FLUSH_VERTICES(ctx, (readFb != ctx->ReadBuffer ||
+drawFb != ctx->DrawBuffer) ? _NEW_BUFFERS : 0);
+
+ if (ctx->NewState)
+ _mesa_update_state(ctx);
/* Update completeness status of readFb and drawFb. */
- _mesa_update_framebuffer(ctx, readFb, drawFb);
+ if (readFb != ctx->ReadBuffer || drawFb != ctx->DrawBuffer)
+ _mesa_update_framebuffer(ctx, readFb, drawFb);
/* Make sure drawFb has an initialized bounding box. */
- _mesa_update_draw_buffer_bounds(ctx, drawFb);
+ if (drawFb != ctx->DrawBuffer)
+ _mesa_update_draw_buffer_bounds(ctx, drawFb);
if (!readFb || !drawFb) {
/* This will normally never happen but someday we may want to
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 02/16] glsl: Add half float type
On Fri, May 15, 2015 at 5:43 PM, Ilia Mirkin wrote:
> On Fri, May 15, 2015 at 5:39 AM, Topi Pohjolainen
> wrote:
>> Signed-off-by: Topi Pohjolainen
>> ---
>> src/glsl/ast_to_hir.cpp| 1 +
>> src/glsl/glsl_types.cpp| 2 ++
>> src/glsl/glsl_types.h | 9 +
>> src/glsl/ir_clone.cpp | 1 +
>> src/glsl/link_uniform_initializers.cpp | 2 ++
>> src/glsl/nir/nir_lower_io.c| 1 +
>> src/mesa/drivers/dri/i965/brw_fs.cpp | 1 +
>> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 1 +
>> src/mesa/drivers/dri/i965/brw_shader.cpp | 1 +
>> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 1 +
>> src/mesa/program/ir_to_mesa.cpp| 3 +++
>> 11 files changed, 23 insertions(+)
>>
>> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
>> index 7d5bb1d..332de5b 100644
>> --- a/src/glsl/ast_to_hir.cpp
>> +++ b/src/glsl/ast_to_hir.cpp
>> @@ -916,6 +916,7 @@ do_comparison(void *mem_ctx, int operation, ir_rvalue
>> *op0, ir_rvalue *op1)
>>join_op = ir_binop_logic_or;
>>
>> switch (op0->type->base_type) {
>> + case GLSL_TYPE_HALF:
>
> Trivial feedback:
>
> I'd recommend calling this F16 or HALF_FLOAT -- mediump also applies
> to integers, of which there ought to be U16 and S16 varieties.
IEEE 754-2008 calls the 16bit floating point format |binary16| - see
http://en.wikipedia.org/wiki/IEEE_floating_point ... "half float" or
"minifloat" would work too... but there are different non-IEEE bit
layouts under that name while |binary16| explicitly refers to a IEEE
754-2008 conforming layout and implementation (e.g. with Nan and -Nan,
Inf and -Inf, and Nan payloads)
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: do not use _glapi_new_nop_table() for DRI builds
On 15/05/15 15:13, Brian Paul wrote:
> Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
> _glapi_set_nop_handler() functions in the glapi dispatcher (which
> live in libGL.so). The calls to those functions from context.c
> would be undefined (i.e. an ABI break) if the libGL used at runtime
> was older.
>
> For the time being, use the old single generic_nop() function for
> DRI builds to avoid this problem. At some point in the future it
> should be safe to remove this work-around. See comments for more
> details.
> ---
> src/mesa/main/context.c | 60
> -
> 1 file changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> index 544cc14..0649708 100644
> --- a/src/mesa/main/context.c
> +++ b/src/mesa/main/context.c
> @@ -883,6 +883,19 @@ update_default_objects(struct gl_context *ctx)
> }
>
>
> +/* XXX this is temporary and should be removed at some point in the
> + * future when there's a reasonable expectation that the libGL library
> + * contains the _glapi_new_nop_table() and _glapi_set_nop_handler()
> + * functions which were added in Mesa 10.6.
> + */
> +#if defined(GLX_DIRECT_RENDERING)
I'd say that this should be WIN32, similar to the original code. The
code is indirectly used by gbm/egl as well, so introducing
GLX_{IN,}DIRECT_RENDERING here might not fair so well.
> +/* Avoid libGL / driver ABI break */
> +#define USE_GLAPI_NOP_FEATURES 0
> +#else
> +#define USE_GLAPI_NOP_FEATURES 1
> +#endif
> +
> +
> /**
> * This function is called by the glapi no-op functions. For each OpenGL
> * function/entrypoint there's a simple no-op function. These "no-op"
> @@ -898,6 +911,7 @@ update_default_objects(struct gl_context *ctx)
> *
> * \param name the name of the OpenGL function
> */
> +#if USE_GLAPI_NOP_FEATURES
> static void
> nop_handler(const char *name)
> {
> @@ -914,6 +928,7 @@ nop_handler(const char *name)
> }
> #endif
> }
> +#endif
>
>
> /**
> @@ -928,6 +943,44 @@ nop_glFlush(void)
Seems like the macro guarding nop_glFlush() should be
USE_GLAPI_NOP_FEATURES ? Then we can drop the explicit
!USE_GLAPI_NOP_FEATURES below and use #else.
The comment within nop_glFlush could use an update as well.
> #endif
>
>
> +#if !USE_GLAPI_NOP_FEATURES
Fold this and the follow up function new_nop_table() into #if block ?
> +static int
> +generic_nop(void)
> +{
> + GET_CURRENT_CONTEXT(ctx);
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "unsupported function called "
> + "(unsupported extension or deprecated function?)");
> + return 0;
> +}
> +#endif
> +
> +
> +/**
> + * Create a new API dispatch table in which all entries point to the
> + * generic_nop() function. This will not work on Windows because of
> + * the __stdcall convention which requires the callee to clean up the
> + * call stack. That's impossible with one generic no-op function.
> + */
> +#if !USE_GLAPI_NOP_FEATURES
> +static struct _glapi_table *
> +new_nop_table(unsigned numEntries)
> +{
> + struct _glapi_table *table;
> +
> + table = malloc(numEntries * sizeof(_glapi_proc));
> + if (table) {
> + _glapi_proc *entry = (_glapi_proc *) table;
> + unsigned i;
> + for (i = 0; i < numEntries; i++) {
> + entry[i] = (_glapi_proc) generic_nop;
> + }
Bikeshed: One could use memset, analogous to the memcpy() in
_glapi_new_nop_table.
> + }
> + return table;
> +}
> +#endif
> +
> +
> /**
> * Allocate and initialize a new dispatch table. The table will be
> * populated with pointers to "no-op" functions. In turn, the no-op
> @@ -936,12 +989,16 @@ nop_glFlush(void)
> static struct _glapi_table *
> alloc_dispatch_table(void)
> {
> + int numEntries = MAX2(_glapi_get_dispatch_table_size(), _gloffset_COUNT);
> +
> +#if !USE_GLAPI_NOP_FEATURES
> + struct _glapi_table *table = new_nop_table(numEntries);
> +#else
> /* Find the larger of Mesa's dispatch table and libGL's dispatch table.
> * In practice, this'll be the same for stand-alone Mesa. But for DRI
> * Mesa we do this to accommodate different versions of libGL and various
> * DRI drivers.
> */
Move the comment as well as numEntries.
> - GLint numEntries = MAX2(_glapi_get_dispatch_table_size(),
> _gloffset_COUNT);
> struct _glapi_table *table = _glapi_new_nop_table(numEntries);
>
> #if defined(_WIN32)
> @@ -967,6 +1024,7 @@ alloc_dispatch_table(void)
> #endif
>
> _glapi_set_nop_handler(nop_handler);
> +#endif
>
> return table;
> }
>
Should we revert commit 627991dbf74(dri: add _glapi_set_nop_handler(),
_glapi_new_nop_table() to dri_test.c) now that the new symbols are no
longer around ?
src/mesa/main/tests/dispatch_sanity.cpp should be updated as well imho.
In one hand we can restore the original behaviour (!WIN32 only) on the
other we can extend it to cover USE_GLAPI_NOP_FEATURES.
Cheers,
Emil
__
Re: [Mesa-dev] [PATCH 10/15] egl: add eglWaitSync
On Fri, May 15, 2015 at 1:23 AM, Emil Velikov wrote:
> On 12/05/15 22:54, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> ---
>> src/egl/main/eglapi.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
>> index 60df297..544f7e4 100644
>> --- a/src/egl/main/eglapi.c
>> +++ b/src/egl/main/eglapi.c
>> @@ -1162,6 +1162,7 @@ eglGetProcAddress(const char *procname)
>>{ "eglDestroySync", (_EGLProc) eglDestroySync },
>>{ "eglClientWaitSync", (_EGLProc) eglClientWaitSync },
>>{ "eglDestroyImage", (_EGLProc) eglDestroyImage },
>> + { "eglWaitSync", (_EGLProc) eglWaitSync },
>> #endif /* _EGL_GET_CORE_ADDRESSES */
>> #ifdef EGL_MESA_drm_display
>>{ "eglGetDRMDisplayMESA", (_EGLProc) eglGetDRMDisplayMESA },
>> @@ -1514,6 +1515,17 @@ eglWaitSyncKHR(EGLDisplay dpy, EGLSync sync, EGLint
>> flags)
>>
>>
>> EGLBoolean EGLAPIENTRY
>> +eglWaitSync(EGLDisplay dpy, EGLSync sync, EGLint flags)
>> +{
>> + /* The KHR version returns EGLint, while the core version returns
>> +* EGLBoolean. In both cases, the return values can only be EGL_FALSE and
>> +* EGL_TRUE.
>> +*/
>> + return eglWaitSyncKHR(dpy, sync, flags);
> Maybe add the cast, considering that sizeof(EGLenum) != sizeof(EGLInt)
> on 64 bit systems.
>
> Thinking about the assembly - not sure if won't end up with pushing a
> 64bit value, while a 32bit one being popped. My x86 assembly days were
> mostly before x86_64 became a thing so ^^ might sound a bit stupid :)
It's EGLBoolean, not EGLenum. Also, no cast is needed between basic types.
typedef int32_t khronos_int32_t;
typedef khronos_int32_t EGLint;
typedef unsigned int EGLBoolean;
The types are equivalent on 32-bit and 64-bit, so I could have just
made eglWaitSyncKHR be an alias of eglWaitSync and it would work, but
I wanted to document this in the code.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Supporting mediump in NIR
On Fri, May 15, 2015 at 11:59:25AM -0400, Rob Clark wrote: > On Fri, May 15, 2015 at 5:39 AM, Topi Pohjolainen > wrote: > > I wanted to kick-off discussion on how to support floating point > > precision qualifiers in NIR. This is purely on optimization for > > GLES where one can reduce the number of GPU cycles. At the moment > > the compiler discards the qualifiers early when abstract syntax > > tree (AST) is transformed into intermediate presentation (IR). > > > > Iago added the initial support to IR in order to check that the > > stages agree on the precision. Naturally I started by rebasing his > > work on master (I dropped the actual checking part as it didn't > > automatically fit into master). I realized that it isn't sufficient > > to have the precision tracked in ir_variable alone. When the IR > > is further translated into NIR the precision is needed in ir_rvalue > > as well when NIR decides which opcode to use. > > Iago's patch isn't needed for the solution here afterall, I just > > included it to for context sake. > > > > Now, there are number of implementation alternatives, I think, both > > in AST/IR as well is in NIR. I thought I play with one approach to > > provide something "real" to aid the decision making regarding the > > architecture. > > > > I thought that despite fp16 (medium precision float) isn't really a > > proper type in glsl, it would clearer if it were one internally in > > the compiler though. I kept thinking fp64 and how I would introduce > > that into NIR. > > The first step was to do pretty much the same as what Dave Airlie > > did for doubles (fp64) in the compiler frontend. > > > > Then in NIR I decided to introduce new opcodes for half floats > > instead of modifying the existing float instructions to carry > > additional information about the precision. > > jfwiw, I can[*] in a lot of cases have precision per operand.. for > example, add a f32 + f16 with result into f32. So having separate > opcodes seems kind of funny. As the opcode in NIR is chosen solely based on the destination type, I thought that f32 + f16 would be similar thing as int + bool producing int, for example. I thought that implicit conversions would kick in. And also the drivers making decisions where a conversion is really needed (additional mov) or not. I have to admit though that I haven't thought all the way through how and where the conversions are produced. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Supporting mediump in NIR
On Fri, May 15, 2015 at 12:22 PM, Pohjolainen, Topi wrote: > On Fri, May 15, 2015 at 11:59:25AM -0400, Rob Clark wrote: >> On Fri, May 15, 2015 at 5:39 AM, Topi Pohjolainen >> wrote: >> > I wanted to kick-off discussion on how to support floating point >> > precision qualifiers in NIR. This is purely on optimization for >> > GLES where one can reduce the number of GPU cycles. At the moment >> > the compiler discards the qualifiers early when abstract syntax >> > tree (AST) is transformed into intermediate presentation (IR). >> > >> > Iago added the initial support to IR in order to check that the >> > stages agree on the precision. Naturally I started by rebasing his >> > work on master (I dropped the actual checking part as it didn't >> > automatically fit into master). I realized that it isn't sufficient >> > to have the precision tracked in ir_variable alone. When the IR >> > is further translated into NIR the precision is needed in ir_rvalue >> > as well when NIR decides which opcode to use. >> > Iago's patch isn't needed for the solution here afterall, I just >> > included it to for context sake. >> > >> > Now, there are number of implementation alternatives, I think, both >> > in AST/IR as well is in NIR. I thought I play with one approach to >> > provide something "real" to aid the decision making regarding the >> > architecture. >> > >> > I thought that despite fp16 (medium precision float) isn't really a >> > proper type in glsl, it would clearer if it were one internally in >> > the compiler though. I kept thinking fp64 and how I would introduce >> > that into NIR. >> > The first step was to do pretty much the same as what Dave Airlie >> > did for doubles (fp64) in the compiler frontend. >> > >> > Then in NIR I decided to introduce new opcodes for half floats >> > instead of modifying the existing float instructions to carry >> > additional information about the precision. >> >> jfwiw, I can[*] in a lot of cases have precision per operand.. for >> example, add a f32 + f16 with result into f32. So having separate >> opcodes seems kind of funny. > > As the opcode in NIR is chosen solely based on the destination type, I > thought that f32 + f16 would be similar thing as int + bool producing > int, for example. I thought that implicit conversions would kick in. > And also the drivers making decisions where a conversion is really > needed (additional mov) or not. I have to admit though that I haven't > thought all the way through how and where the conversions are produced. ahh, gotcha.. yeah, that seems like it could work.. somehow I was ASSuming opcode meant src and dst types (and always having some special mov's to convert src types) ;-) my instruction set tends to not be very orthogonal (some groups of instructions can convert, some not), so letting the driver backend make decisions about inserting converting mov's is what I'd like to see.. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/15] egl: add eglWaitSync
On 15/05/15 16:18, Marek Olšák wrote:
> On Fri, May 15, 2015 at 1:23 AM, Emil Velikov
> wrote:
>> On 12/05/15 22:54, Marek Olšák wrote:
>>> From: Marek Olšák
>>>
>>> ---
>>> src/egl/main/eglapi.c | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
>>> index 60df297..544f7e4 100644
>>> --- a/src/egl/main/eglapi.c
>>> +++ b/src/egl/main/eglapi.c
>>> @@ -1162,6 +1162,7 @@ eglGetProcAddress(const char *procname)
>>>{ "eglDestroySync", (_EGLProc) eglDestroySync },
>>>{ "eglClientWaitSync", (_EGLProc) eglClientWaitSync },
>>>{ "eglDestroyImage", (_EGLProc) eglDestroyImage },
>>> + { "eglWaitSync", (_EGLProc) eglWaitSync },
>>> #endif /* _EGL_GET_CORE_ADDRESSES */
>>> #ifdef EGL_MESA_drm_display
>>>{ "eglGetDRMDisplayMESA", (_EGLProc) eglGetDRMDisplayMESA },
>>> @@ -1514,6 +1515,17 @@ eglWaitSyncKHR(EGLDisplay dpy, EGLSync sync, EGLint
>>> flags)
>>>
>>>
>>> EGLBoolean EGLAPIENTRY
>>> +eglWaitSync(EGLDisplay dpy, EGLSync sync, EGLint flags)
>>> +{
>>> + /* The KHR version returns EGLint, while the core version returns
>>> +* EGLBoolean. In both cases, the return values can only be EGL_FALSE
>>> and
>>> +* EGL_TRUE.
>>> +*/
>>> + return eglWaitSyncKHR(dpy, sync, flags);
>> Maybe add the cast, considering that sizeof(EGLenum) != sizeof(EGLInt)
>> on 64 bit systems.
>>
>> Thinking about the assembly - not sure if won't end up with pushing a
>> 64bit value, while a 32bit one being popped. My x86 assembly days were
>> mostly before x86_64 became a thing so ^^ might sound a bit stupid :)
>
> It's EGLBoolean, not EGLenum. Also, no cast is needed between basic types.
>
> typedef int32_t khronos_int32_t;
> typedef khronos_int32_t EGLint;
> typedef unsigned int EGLBoolean;
>
> The types are equivalent on 32-bit and 64-bit, so I could have just
> made eglWaitSyncKHR be an alias of eglWaitSync and it would work, but
> I wanted to document this in the code.
>
Had a bit of a brain fart. Pardon for the noise.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 4/6] i965: Implement INTEL_performance_query extension
On Mon, May 11, 2015 at 4:28 PM, Samuel Pitoiset
wrote:
>
>
> On 05/06/2015 02:53 AM, Robert Bragg wrote:
>>
>> This adds a bare-bones backend for the INTEL_performance_query extension
>> that exposes the pipeline statistics on gen 6 and 7 hardware.
>>
>> Although this could be considered redundant given that the same
>> statistics are now available via query objects, they are a simple
>> starting point for this extension and it's expected to be convenient for
>> tools wanting to have a single go to api to introspect what performance
>> counters are available, along with names, descriptions and semantic/data
>> types.
>>
>> This code is derived from Kenneth Graunke's work, temporarily removed
>> while the frontend and backend interface were reworked.
>>
>> Signed-off-by: Robert Bragg
>> ---
>> src/mesa/drivers/dri/i965/Makefile.sources| 1 +
>> src/mesa/drivers/dri/i965/brw_context.c | 3 +
>> src/mesa/drivers/dri/i965/brw_context.h | 26 +
>> src/mesa/drivers/dri/i965/brw_performance_query.c | 611
>> ++
>> src/mesa/drivers/dri/i965/intel_extensions.c | 3 +
>> 5 files changed, 644 insertions(+)
>> create mode 100644 src/mesa/drivers/dri/i965/brw_performance_query.c
>>
>> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
>> b/src/mesa/drivers/dri/i965/Makefile.sources
>> index 210314b..066364a 100644
>> --- a/src/mesa/drivers/dri/i965/Makefile.sources
>> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
>> @@ -81,6 +81,7 @@ i965_FILES = \
>> brw_nir_analyze_boolean_resolves.c \
>> brw_object_purgeable.c \
>> brw_packed_float.c \
>> + brw_performance_query.c \
>> brw_primitive_restart.c \
>> brw_program.c \
>> brw_program.h \
>> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
>> b/src/mesa/drivers/dri/i965/brw_context.c
>> index 80a4b0a..1350bc1 100644
>> --- a/src/mesa/drivers/dri/i965/brw_context.c
>> +++ b/src/mesa/drivers/dri/i965/brw_context.c
>> @@ -884,6 +884,9 @@ brwCreateContext(gl_api api,
>> _mesa_initialize_dispatch_tables(ctx);
>> _mesa_initialize_vbo_vtxfmt(ctx);
>> + if (ctx->Extensions.INTEL_performance_query)
>> + brw_init_performance_queries(brw);
>> +
>> vbo_use_buffer_objects(ctx);
>> vbo_always_unmap_buffers(ctx);
>> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
>> b/src/mesa/drivers/dri/i965/brw_context.h
>> index db65191..2cd963d 100644
>> --- a/src/mesa/drivers/dri/i965/brw_context.h
>> +++ b/src/mesa/drivers/dri/i965/brw_context.h
>> @@ -953,6 +953,21 @@ struct brw_stage_state
>> uint32_t sampler_offset;
>> };
>> +enum brw_query_kind {
>> + PIPELINE_STATS
>> +};
>> +
>> +struct brw_perf_query
>> +{
>> + enum brw_query_kind kind;
>> + const char *name;
>> + struct brw_perf_query_counter *counters;
>> + int n_counters;
>> + size_t data_size;
>> +};
>> +
>> +#define MAX_PERF_QUERIES 3
>> +#define MAX_PERF_QUERY_COUNTERS 150
>> /**
>>* brw_context is derived from gl_context.
>> @@ -1380,6 +1395,13 @@ struct brw_context
>> bool begin_emitted;
>> } query;
>> + struct {
>> + struct brw_perf_query queries[MAX_PERF_QUERIES];
>
>
> Why the number of active queries is limited to 3? Is that a hardware
> limitation?
No, this isn't a restriction on the number of active queries, rather
it's just that the backend doesn't support more than 3 query types
currently:
1) pipeline statistics
2) simple aggregate counters query
3) "3D" counters query
We would increase this e.g. if we were to add a GPGPU counters query
It could be good though to double check that we don't forget to extend
this if we add new query types, e.g. by asserting that
brw->perfquery.n_queries < MAX_PERF_QUERIES within the add_XYZ_query()
functions.
>
>
>> + int n_queries;
>> +
>> + int n_active_pipeline_stats_queries;
>> + } perfquery;
>> +
>> int num_atoms[BRW_NUM_PIPELINES];
>> const struct brw_tracked_state render_atoms[57];
>> const struct brw_tracked_state compute_atoms[1];
>> @@ -1656,6 +1678,10 @@ bool brw_render_target_supported(struct brw_context
>> *brw,
>>struct gl_renderbuffer *rb);
>> uint32_t brw_depth_format(struct brw_context *brw, mesa_format format);
>> +/* brw_performance_query.c */
>> +void brw_init_performance_queries(struct brw_context *brw);
>> +void brw_dump_perf_queries(struct brw_context *brw);
>> +
>> /* intel_buffer_objects.c */
>> int brw_bo_map(struct brw_context *brw, drm_intel_bo *bo, int
>> write_enable,
>> const char *bo_name);
>> diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c
>> b/src/mesa/drivers/dri/i965/brw_performance_query.c
>> new file mode 100644
>> index 000..38447e8
>> --- /dev/null
>> +++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
>> @@ -0,0 +1,611 @@
>> +/*
>> + * Copyright © 2013 Intel Corporation
>> + *
>> + * Permission is hereby granted, free
Re: [Mesa-dev] RFC: Supporting mediump in NIR
On Fri, May 15, 2015 at 12:32:52PM -0400, Rob Clark wrote: > On Fri, May 15, 2015 at 12:22 PM, Pohjolainen, Topi > wrote: > > On Fri, May 15, 2015 at 11:59:25AM -0400, Rob Clark wrote: > >> On Fri, May 15, 2015 at 5:39 AM, Topi Pohjolainen > >> wrote: > >> > I wanted to kick-off discussion on how to support floating point > >> > precision qualifiers in NIR. This is purely on optimization for > >> > GLES where one can reduce the number of GPU cycles. At the moment > >> > the compiler discards the qualifiers early when abstract syntax > >> > tree (AST) is transformed into intermediate presentation (IR). > >> > > >> > Iago added the initial support to IR in order to check that the > >> > stages agree on the precision. Naturally I started by rebasing his > >> > work on master (I dropped the actual checking part as it didn't > >> > automatically fit into master). I realized that it isn't sufficient > >> > to have the precision tracked in ir_variable alone. When the IR > >> > is further translated into NIR the precision is needed in ir_rvalue > >> > as well when NIR decides which opcode to use. > >> > Iago's patch isn't needed for the solution here afterall, I just > >> > included it to for context sake. > >> > > >> > Now, there are number of implementation alternatives, I think, both > >> > in AST/IR as well is in NIR. I thought I play with one approach to > >> > provide something "real" to aid the decision making regarding the > >> > architecture. > >> > > >> > I thought that despite fp16 (medium precision float) isn't really a > >> > proper type in glsl, it would clearer if it were one internally in > >> > the compiler though. I kept thinking fp64 and how I would introduce > >> > that into NIR. > >> > The first step was to do pretty much the same as what Dave Airlie > >> > did for doubles (fp64) in the compiler frontend. > >> > > >> > Then in NIR I decided to introduce new opcodes for half floats > >> > instead of modifying the existing float instructions to carry > >> > additional information about the precision. > >> > >> jfwiw, I can[*] in a lot of cases have precision per operand.. for > >> example, add a f32 + f16 with result into f32. So having separate > >> opcodes seems kind of funny. > > > > As the opcode in NIR is chosen solely based on the destination type, I > > thought that f32 + f16 would be similar thing as int + bool producing > > int, for example. I thought that implicit conversions would kick in. > > And also the drivers making decisions where a conversion is really > > needed (additional mov) or not. I have to admit though that I haven't > > thought all the way through how and where the conversions are produced. > > ahh, gotcha.. yeah, that seems like it could work.. somehow I was > ASSuming opcode meant src and dst types (and always having some > special mov's to convert src types) ;-) > > my instruction set tends to not be very orthogonal (some groups of > instructions can convert, some not), so letting the driver backend > make decisions about inserting converting mov's is what I'd like to > see.. With Intel hardware we are quite restricted also. If I'm not mistaken we can only produce 16-bit floats with all the operands being 16-bit. Therefore I'd like to see the decision making on conversions in the driver also. Thanks for the feedback :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] i965 implementation of the ARB_shader_image_load_store built-ins. (v3)
Jason Ekstrand writes: > I haven't said much about this series up until now. I've mostly sat > and watched and focused my time on other things. As I said in the > meeting today, I think that part of the problem here is that there are > at least 3 "refactors" in here besides the new feature. By > "refactors", I mean "new ways of solving problem X". Part of the > problem with the discussion is that all of this has been conflated and > we aren't actually talking about how to solve each of those problems. > I'm going to try and break it out here to try and aid in the > discussion. > Thanks a lot Jason for giving a more constructive turn to this discussion. :) > 1) The builder. I think *everyone* likes the builder. The argument > here is not over whether or not we want it. People have expressed > concern that adding the builder now without actually doing the > refactor will result in duplicated code that will get out-of-sync. I > think the best solution here is to go ahead and do the builder stuff > immediately after the branch point. > Agreed. > 2) SIMD8 instruction splitting. As I said in the call, we've done > this a variety of ways in the past usually by emitting the split > instructions in the visitor and manually using half() and > inst->force_sechalf. We also have a few places that I think still > split the code in the generator. What you're doing is a somewhat more > elegant version of the "emit it in the visitor" stuff that we've done > in the past. You've got your zip/unzip functions etc. to handle > splitting and combining and then you have a loop to actually emit the > sends. Really, it's fairly nice and concise. The question is whether > or not it's really what we want to do (more on this in a bit). > There is another closely related problem that this infrastructure solves and may not be obvious in this series (it was in my original branch though [1]), but I think it's worth keeping in mind, I'll call it 2.1: Some of the surface messages lacked SIMD4x2 variants, so a strided copy is required to transpose the original AoS vector into SoA form. This turns out to be algorithmically identical to the strided copy required to "unzip" a SIMD16 vector, so it can be accomplished without additional effort. These transformations are largely transparent for the functions building typed/untyped surface messages, they are hidden behind an interface that doesn't seem to have received any attention yet: - struct vector_layout: This represents the layout of a vector in a payload. It's initialized based on the restrictions of the hardware for the specific message we want to send, and the current code generation parameters (i.e. SIMD mode). - emit_insert(): This takes a vector with the layout native to the EU (e.g. an fs_reg) and performs the required transformations to turn it into a form suitable for the shared unit according to a vector_layout struct (what may involve unzipping, a strided copy or no work at all). - emit_extract(): The converse of emit_insert(). This takes a payload fragment (array_reg) and transforms it into a vector of native layout, according to a vector_layout struct. My intention was to come up with an interface more general than SIMD16 vector splitting and SIMD4x2 to SIMD8 conversion alone, I was also thinking texturing instruction payload quirks (which might require padding or different permutations of the same values depending on the generation even if the SIMD mode is natively supported -- let's call this 2.2) and framebuffer writes (2.3). > 3) Array reg. This is something of a helper to (2). In fact the primary motivation for array_reg wasn't instruction splitting, but emit_collect(), more on that later. > I agree that it's nice to be able to have access to the size of a > register without having to look at the allocator. The problem here > (and why we don't have a size in fs_reg) is that we copy the reigster > around. Every register does have some sort of "underlying storage" > that it shares with other registers with the same number. But that > storage is represented by the size in the allocator and nothing else. > Is that bad? Maybe. Should we have a way of passing the size around > with it? Maybe. In any case, I think it's best to table this > discussion until we've talked a bit about (2) because I think the > resolution there will make (3) more clear. > I think the mechanism we use to determine the size of a register hardly ever involves the allocator, and there are good reasons not to rely on it: It only works for VGRFs, can easily break with register coalescing, and it makes "slicing" and other zero-copy transformations of registers difficult (e.g. taking an individual element out of a VGRF array without copying it into a one-component register). Typically the size of a register is implicitly assumed by the instruction using it, and where it's not (because the instruction expects a variable length payload) it is pr
Re: [Mesa-dev] [PATCH 12/15] egl: add eglCreateImage
On 12/05/15 22:54, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/egl/main/eglapi.c | 38 ++
> 1 file changed, 38 insertions(+)
>
> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> index 6457798..34a113b 100644
> --- a/src/egl/main/eglapi.c
> +++ b/src/egl/main/eglapi.c
> @@ -251,6 +251,30 @@ _eglUnlockDisplay(_EGLDisplay *dpy)
> }
>
>
> +static EGLint *
> +_eglConvertAttribsToInt(const EGLAttrib *attr_list)
> +{
> + EGLint *int_attribs = NULL;
> +
> + /* Convert attributes from EGLAttrib[] to EGLint[] */
> + if (attr_list) {
> + int i, size = 0;
> +
> + while (attr_list[size] != EGL_NONE)
> + size += 2;
> +
> + if (size) {
> + size += 1; /* add space for EGL_NONE */
> + int_attribs = malloc(size * sizeof(int_attribs[0]));
> +
> + for (i = 0; i < size; i++)
> +int_attribs[i] = attr_list[i];
In the unlikely event that malloc fails, it'll be nice to not crash.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] i915: Add XRGB8888 format to intel_screen_make_configs
On 09/04/15 16:05, Emil Velikov wrote: > Hi Boyan, > > On 9 April 2015 at 16:08, Boyan Ding wrote: >> For the same reason as the i965 one, as suggested by Chih-Wei Huang. >> >> Cc: "10.4 10.5" >> Signed-off-by: Boyan Ding >> --- > > Did you run this and the i965 patch through piglit ? Considering how > quiet things are having the information that if fixes/breaks test X > and Y would be great to have. > Boyan Ding, Chih-Wei, Can you help out with the piglit testing ? Would be nice to avoid breaking things. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): 57 new commits
Hi Fredrik, I'd prefer flushing the bitmap cache in st_BlitFramebuffer. We might have more bugs like this in st/mesa. Marek On Fri, May 15, 2015 at 5:59 PM, Fredrik Höglund wrote: > On Friday 15 May 2015, Fredrik Höglund wrote: >> On Friday 15 May 2015, Michel Dänzer wrote: >> > On 14.05.2015 22:52, fred...@kemper.freedesktop.org (Fredrik HXXglund) >> > wrote: >> > > >> > > URL: >> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=6b284f08ab399154ad10e2166440b44cbbdcb2c5 >> > > Author: Laura Ekstrand >> > > Date: Tue Feb 3 14:47:00 2015 -0800 >> > > >> > > main: _mesa_blit_framebuffer updates its arbitrary framebuffers. >> > > >> > > Previously, we used _mesa_update_state to update the currently bound >> > > framebuffers prior to performing a blit. Now that >> > > _mesa_blit_framebuffer >> > > uses arbitrary framebuffers, _mesa_update_state is not specific >> > > enough. >> > > >> > > Reviewed-by: Fredrik Höglund >> > > Signed-off-by: Fredrik Höglund >> > >> > This commit broke the piglit test >> > spec@ext_framebuffer_multisample@bitmap with the radeonsi driver: >> > >> > Probe color at (224,0) >> > Left: 0.00 0.00 0.00 1.00 >> > Right: 1.00 1.00 1.00 1.00 >> > >> > Looks like it's because the bottom right squares of the Xs are missing, >> > see the attached picture. >> > >> > Any ideas? >> >> I did notice that failure as well, but when I ran the test manually it >> passed for me, leading me to think that it was a spurious failure. >> >> The output looks exactly the same for me. But the test works by >> comparing the left and right halves of the framebuffer, so if the >> bottom right squares are missing on both sides, the test should >> pass. >> >> The left side is the test image, and the right side is the reference >> image. > > Okay, so I've finished analyzing the failure. The glBindFramebuffer() > calls that precede the glBlitFramebuffer() call cause _NEW_BUFFERS to > be set. This used to result in _mesa_update_state() being called from > _mesa_blit_framebuffer(), which in turn would call st_invalidate_state(), > which would mark the framebuffer state as invalid. st_BlitFramebuffer() > would then call st_validate_state() which would call > update_framebuffer_state() which would call st_flush_bitmap_cache(). > That call to st_flush_bitmap_cache() is what caused the rendering by the > last glBitmap() call to land in the framebuffer. > > The attached patch fixes the problem by restoring the > _mesa_update_state() call. The bug can also be fixed by calling > st_flush_bitmap_cache() from st_BlitFramebuffer(). > > Fredrik > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i915: add mock implementation of GL_OES_EGL_image_external
On 02/04/15 15:17, Chih-Wei Huang wrote:
> This is similar to commit 7420c9dab4aaf87e6b840410226c296c4668a48f
> but for the i915 driver. It's necessary to support android-x86.
>
There is one major difference between this and the mentioned commit.
This one unconditionally enables the extension - can we avoid that ?
Plus can you give piglit a spin to confirm that things don't explode
elsewhere ? It might take a while restricting the run to tests/gpu.py
will help.
$ ./piglit run tests/gpu.py ${piglit-results}
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] CompressedTexImage3D spec bug?
From ARB_texture_cube_map_array: Accepted by the parameter of TexImage3D, TexSubImage3D, CompressedTeximage3D, CompressedTexSubImage3D and CopyTexSubImage3D: TEXTURE_CUBE_MAP_ARRAY_ARB So the extension spec "fixes" the core spec. Marek On Fri, May 15, 2015 at 4:49 AM, Roland Scheidegger wrote: > Accidentally, I stumbled upon this bit in gl 4.5, chapter 8.7 > "Compressed Texture Images": > "An INVALID_OPERATION error is generated by CompressedTexImage3D if > internalformat is one of the EAC, ETC2, or RGTC formats and either > border is non-zero, or target is not TEXTURE_2D_ARRAY." > This forbids TEXTURE_CUBE_MAP_ARRAY as a target. > Doesn't look like that's what mesa implements, nor does it make sense. > This has to be a spec bug, right? > > Roland > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/20] i915: Pile of fixes and cleanups
Hi Ville, On 13/04/15 11:00, Ville Syrjälä wrote: > On Mon, Mar 23, 2015 at 02:47:16PM +0200, ville.syrj...@linux.intel.com wrote: >> From: Ville Syrjälä >> >> I've had some of these i915 patches lying around for half a year or more, >> so I figured it's time to post them. >> >> This series fixes rendering problems in glxgears and supertuxkart. It >> also fixes a few piglit tests (provoking vertex, and a few crashers). >> No piglit regressions on 855. >> >> Summary of the changes: >> * provoking vertex fixes >> * gen2 user fbo culling fix >> * some buffer handling fixes ported over from i965 >> * gen3 fragment shader texcoord vs. varying fix (already posted before) >> * random point/line rendering stuff >> * a bit of polish here and there > > Doesn't look like many people are interested in reading through these. > > Let me put it the other way: Anyone opposed to me just pushing these? > While I do not have the hardware to use these, I think that it's great that you made these. It's a bit unfortunate that no one with the knowledge in the driver has the time/interest to check these over. If you go ahead with these, can you change the prefix form t_dd_dmatmp to mesa/tnl_dd, tnl_dd or even tnl. Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC v2] Model INTEL perf query backend after query object BE
Instead of using the same backend interface as AMD_performance_monitor
this defines a dedicated INTEL_performance_query interface that is based
on the ARB_query_buffer_object interface (considering the similarity of
the extensions) with the addition of vfuncs for enumerating queries and
their counters.
Compared to the previous backend, some notable differences are:
- The backend is free to represent counters using whatever data
structures are optimal/convenient since queries and counters are
enumerated via an iterator api instead of declaring them using
structures directly shared with the frontend.
This is also done to help us support the full range of data and
semantic types available with INTEL_performance_query which is awkward
while using a structure shared with the AMD_performance_monitor
backend since neither extension's types are a subset of the other.
- The backend must support waiting for a query instead of the frontend
simply using glFinish().
- Objects go through 'Active' and 'Ready' states consistent with the
query object backend (hopefully making them more familiar). There is
no 'Ended' state (which used to show that a query has ended at least
once for a given object). There is a new 'Used' state similar to the
'EverBound' state of query objects, set when a query is first begun
which implies that we are expecting to get results back for the object
at some point.
The INTEL_performance_query and AMD_performance_monitor extensions are
now completely orthogonal within Mesa (though a driver could optionally
choose to implement both extensions within a unified backend if that
were convenient for the sake of sharing state/code).
v2: (Samuel Pitoiset)
- init PerfQuery.NumQueries in frontend
- s/return_string/output_clipped_string/
- s/backed/backend/ typo
- remove redundant *bytesWritten = 0
Signed-off-by: Robert Bragg
---
src/mesa/main/dd.h| 39 +++
src/mesa/main/mtypes.h| 25 +-
src/mesa/main/performance_query.c | 591 ++
src/mesa/main/performance_query.h | 6 +-
4 files changed, 275 insertions(+), 386 deletions(-)
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 0c1a13f..4ba1524 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -759,6 +759,45 @@ struct dd_function_table {
GLint *bytesWritten);
/*@}*/
+ /**
+* \name Performance Query objects
+*/
+ /*@{*/
+ void (*GetPerfQueryInfo)(struct gl_context *ctx,
+int queryIndex,
+const char **name,
+GLuint *dataSize,
+GLuint *numCounters,
+GLuint *numActive);
+ void (*GetPerfCounterInfo)(struct gl_context *ctx,
+ int queryIndex,
+ int counterIndex,
+ const char **name,
+ const char **desc,
+ GLuint *offset,
+ GLuint *data_size,
+ GLuint *type_enum,
+ GLuint *data_type_enum,
+ GLuint64 *raw_max);
+ struct gl_perf_query_object * (*NewPerfQueryObject)(struct gl_context *ctx,
+ int queryIndex);
+ void (*DeletePerfQuery)(struct gl_context *ctx,
+ struct gl_perf_query_object *obj);
+ GLboolean (*BeginPerfQuery)(struct gl_context *ctx,
+ struct gl_perf_query_object *obj);
+ void (*EndPerfQuery)(struct gl_context *ctx,
+struct gl_perf_query_object *obj);
+ void (*WaitPerfQuery)(struct gl_context *ctx,
+ struct gl_perf_query_object *obj);
+ GLboolean (*IsPerfQueryReady)(struct gl_context *ctx,
+ struct gl_perf_query_object *obj);
+ void (*GetPerfQueryData)(struct gl_context *ctx,
+struct gl_perf_query_object *obj,
+GLsizei dataSize,
+GLuint *data,
+GLuint *bytesWritten);
+ /*@}*/
+
/**
* \name Vertex Array objects
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index b1e5fa9..a26109d 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2014,6 +2014,23 @@ struct gl_perf_monitor_group
/**
+ * A query object instance as described in INTEL_performance_query.
+ *
+ * NB: We want to keep this and the corresponding backend structure
+ * relatively lean considering that applications may expect to
+ * allocate enough objects to be able to query around all draw calls
+ * in a frame.
+ */
+struct gl_perf_query_object
+{
+ GLuint Id;/**< hash table ID/name */
+ GLuint Used:1;/**< has been used for 1 or more queries */
+ GLuint Activ
Re: [Mesa-dev] CompressedTexImage3D spec bug?
I don't think so. This just refers to generally accepting TEXTURE_CUBE_MAP_ARRAY for these calls. It does however not refer to specific compressed formats, which is what the core spec bit is about (what this really wanted to forbid there is specifying TEXTURE_3D). Roland Am 15.05.2015 um 19:05 schrieb Marek Olšák: > From ARB_texture_cube_map_array: > > Accepted by the parameter of TexImage3D, TexSubImage3D, > CompressedTeximage3D, CompressedTexSubImage3D and CopyTexSubImage3D: > > TEXTURE_CUBE_MAP_ARRAY_ARB > > So the extension spec "fixes" the core spec. > > Marek > > On Fri, May 15, 2015 at 4:49 AM, Roland Scheidegger > wrote: >> Accidentally, I stumbled upon this bit in gl 4.5, chapter 8.7 >> "Compressed Texture Images": >> "An INVALID_OPERATION error is generated by CompressedTexImage3D if >> internalformat is one of the EAC, ETC2, or RGTC formats and either >> border is non-zero, or target is not TEXTURE_2D_ARRAY." >> This forbids TEXTURE_CUBE_MAP_ARRAY as a target. >> Doesn't look like that's what mesa implements, nor does it make sense. >> This has to be a spec bug, right? >> >> Roland >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=HgJD3ol4T_ZdKio1CDuIebSrsd6IsqyVrt8xMgAGKU8&s=jR6XbmLF6OuiV0cZ4kLNbL9fIKsTA3CnOD7vdYw3kQg&e= >> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [counter-RFC 1/3] nir: s/nir_type_unsigned/nir_type_uint
---
src/glsl/nir/glsl_to_nir.cpp | 2 +-
src/glsl/nir/nir.h | 2 +-
src/glsl/nir/nir_constant_expressions.py | 4 +-
src/glsl/nir/nir_opcodes.py | 78
src/glsl/nir/nir_search.c| 4 +-
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 4 +-
6 files changed, 48 insertions(+), 46 deletions(-)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index 7a20e1a..b1a084d 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -1627,7 +1627,7 @@ nir_visitor::visit(ir_texture *ir)
instr->dest_type = nir_type_int;
break;
case GLSL_TYPE_UINT:
- instr->dest_type = nir_type_unsigned;
+ instr->dest_type = nir_type_uint;
break;
default:
unreachable("not reached");
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 697d37e..bc8f063 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -643,7 +643,7 @@ typedef enum {
nir_type_invalid = 0, /* Not a valid type */
nir_type_float,
nir_type_int,
- nir_type_unsigned,
+ nir_type_uint,
nir_type_bool
} nir_alu_type;
diff --git a/src/glsl/nir/nir_constant_expressions.py
b/src/glsl/nir/nir_constant_expressions.py
index bf82fe5..81b71d0 100644
--- a/src/glsl/nir/nir_constant_expressions.py
+++ b/src/glsl/nir/nir_constant_expressions.py
@@ -31,6 +31,8 @@ template = """\
#include "util/rounding.h" /* for _mesa_roundeven */
#include "nir_constant_expressions.h"
+typedef unsigned int uint;
+
#if defined(_MSC_VER) && (_MSC_VER < 1800)
static int isnormal(double x)
{
@@ -224,7 +226,7 @@ unpack_half_1x16(uint16_t u)
}
/* Some typed vector structures to make things like src0.y work */
-% for type in ["float", "int", "unsigned", "bool"]:
+% for type in ["float", "int", "uint", "bool"]:
struct ${type}_vec {
${type} x;
${type} y;
diff --git a/src/glsl/nir/nir_opcodes.py b/src/glsl/nir/nir_opcodes.py
index 56e96d9..bbfcbed 100644
--- a/src/glsl/nir/nir_opcodes.py
+++ b/src/glsl/nir/nir_opcodes.py
@@ -91,7 +91,7 @@ class Opcode(object):
tfloat = "float"
tint = "int"
tbool = "bool"
-tunsigned = "unsigned"
+tuint = "uint"
commutative = "commutative "
associative = "associative "
@@ -156,7 +156,7 @@ unop("fsqrt", tfloat, "sqrtf(src0)")
unop("fexp2", tfloat, "exp2f(src0)")
unop("flog2", tfloat, "log2f(src0)")
unop_convert("f2i", tfloat, tint, "src0") # Float-to-integer conversion.
-unop_convert("f2u", tfloat, tunsigned, "src0") # Float-to-unsigned conversion
+unop_convert("f2u", tfloat, tuint, "src0") # Float-to-unsigned conversion
unop_convert("i2f", tint, tfloat, "src0") # Integer-to-float conversion.
# Float-to-boolean conversion
unop_convert("f2b", tfloat, tbool, "src0 != 0.0f")
@@ -165,7 +165,7 @@ unop_convert("b2f", tbool, tfloat, "src0 ? 1.0f : 0.0f")
# Int-to-boolean conversion
unop_convert("i2b", tint, tbool, "src0 != 0")
unop_convert("b2i", tbool, tint, "src0 ? 1 : 0") # Boolean-to-int conversion
-unop_convert("u2f", tunsigned, tfloat, "src0") #Unsigned-to-float conversion.
+unop_convert("u2f", tuint, tfloat, "src0") #Unsigned-to-float conversion.
unop_reduce("bany", 1, tbool, tbool, "{src}", "{src0} || {src1}", "{src}")
unop_reduce("ball", 1, tbool, tbool, "{src}", "{src0} && {src1}", "{src}")
@@ -205,13 +205,13 @@ unop("fddy_coarse", tfloat, "0.0f")
# Floating point pack and unpack operations.
def pack_2x16(fmt):
- unop_horiz("pack_" + fmt + "_2x16", 1, tunsigned, 2, tfloat, """
+ unop_horiz("pack_" + fmt + "_2x16", 1, tuint, 2, tfloat, """
dst.x = (uint32_t) pack_fmt_1x16(src0.x);
dst.x |= ((uint32_t) pack_fmt_1x16(src0.y)) << 16;
""".replace("fmt", fmt))
def pack_4x8(fmt):
- unop_horiz("pack_" + fmt + "_4x8", 1, tunsigned, 4, tfloat, """
+ unop_horiz("pack_" + fmt + "_4x8", 1, tuint, 4, tfloat, """
dst.x = (uint32_t) pack_fmt_1x8(src0.x);
dst.x |= ((uint32_t) pack_fmt_1x8(src0.y)) << 8;
dst.x |= ((uint32_t) pack_fmt_1x8(src0.z)) << 16;
@@ -219,13 +219,13 @@ dst.x |= ((uint32_t) pack_fmt_1x8(src0.w)) << 24;
""".replace("fmt", fmt))
def unpack_2x16(fmt):
- unop_horiz("unpack_" + fmt + "_2x16", 2, tfloat, 1, tunsigned, """
+ unop_horiz("unpack_" + fmt + "_2x16", 2, tfloat, 1, tuint, """
dst.x = unpack_fmt_1x16((uint16_t)(src0.x & 0x));
dst.y = unpack_fmt_1x16((uint16_t)(src0.x << 16));
""".replace("fmt", fmt))
def unpack_4x8(fmt):
- unop_horiz("unpack_" + fmt + "_4x8", 4, tfloat, 1, tunsigned, """
+ unop_horiz("unpack_" + fmt + "_4x8", 4, tfloat, 1, tuint, """
dst.x = unpack_fmt_1x8((uint8_t)(src0.x & 0xff));
dst.y = unpack_fmt_1x8((uint8_t)((src0.x >> 8) & 0xff));
dst.z = unpack_fmt_1x8((uint8_t)((src0.x >> 16) & 0xff));
@@ -248,22 +248,22 @@ unpack_2x16("half")
# Lowered floating point unpacking operations.
-unop_horiz("unpack_half_2x16_split_x", 1, tfloat, 1, tunsigned,
+unop_horiz("unpack_half_2x16_split_x", 1, tfloat, 1, tuint,
"unpack_half_1x16((uint16_t)(src0.x &
[Mesa-dev] [counter-RFC 0/3] Add a concept of a bit-size to NIR
WARNING: This is possibly the hackiest thing I've ever sent to the list. I've been meaning to type it up properly but have never gotten around to it. When Topi sent his series this morning, I decided that it would be worth dropping my thoughts on the list so that we can have something of a comparison. These three patches are very skeliton but they should show approximately where my ideas are going. You've been warned. Proceed at your own risk! :-) The idea I've had kicking around my brain to handle things like fp64 in NIR is to add a concept of "bit size" that is similar to the number of channels. This is distinctly different than simply adding new types but I believe it comes with a number of advantages: 1) Less type explosion. Having a typeless IR is great and all, but it can lead to something of an explosion of types when you start to throw in 16-bit and 64-bit variants of everything. To top it all off, we may start having to support 8, 16, and 64-bit integers and then it'll get really bad. 5) You can still have explicitly sized opcodes such as fsin by simply setting the type to 'float32'. If it's something more universal like fmul, you use the unsized 'float' type. 2) The bit-size is baked into the register or SSA value. This one is important. One of the problems of baking the bit-size into the type is that now you have to solve the problem of how 64-bit types relate to registers and SSA values? Do they take up 1 slot or 2? Does a half-float take up half a slot? If everything still takes up 1 slot, how do you know what size a register actually is? When you bake the bit-size into the register or SSA value, all these questions go away and you're forced to use explicit packing operations and casts. 3) The bit-size is easily ignorable. Have a backend that can't do fp16 but NIR is automatically giving it to you when you for mediump? You can just harmlessly ignore it. This doesn't work for fp64 or other integer types, but it's nice for fp16 for now. 4) We don't have to re-write opt_algebraic to add all of the 16-bit and 64-bit optimizations. They come for free as long as we make nir_search bit-size aware. Disadvantages: 1) Things that used to only have to care about the instruction opcode now have to care about the bit-size. For instance, the constant-folding stuff now has to jump through some more hoops. 2) Dealing with bit-sizes can be confusing because it's encoded in the destination as well as, possibly, the type. However, a lot of things will only care about one or the other so it shouldn't be a big deal. 3) I've only compile-tested what is less than half an implementation. I have no idea how all this will work out in practice. Things left currently unresolved in the patches I sent: 1) Do we want to have a bit_size field on various instructions or just determine it from the destination? For ALU instructions, leaving it alone seems to work OK but it might not be as good for intrinsics. I'm not really sure what I think. 2) We need to figure out how we want to handle it in constant folding. I think we can just add some stuff to the auto-gen to switch on the destination's bit-size and go from there. 3) What about things where we want 16-bit and 32-bit versions but not 64-bit? There are a lot of things that aren't allowed for fp64 such as transcendentals but they may be ok for fp16. As it stands, we would still need two opcodes: fsin32 and fsin16. I'm sure thare's a lot more to throw around but this should be enough to get us started. --Jason Jason Ekstrand (3): nir: s/nir_type_unsigned/nir_type_uint nir: Add explicitly sized types nir: Add a bit_size to nir_register and nir_ssa_def src/glsl/nir/glsl_to_nir.cpp | 2 +- src/glsl/nir/nir.c | 2 + src/glsl/nir/nir.h | 24 +- src/glsl/nir/nir_constant_expressions.py | 4 +- src/glsl/nir/nir_opcodes.py | 78 src/glsl/nir/nir_search.c| 4 +- src/glsl/nir/nir_validate.c | 43 -- src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 4 +- 8 files changed, 110 insertions(+), 51 deletions(-) -- 2.4.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [counter-RFC 3/3] nir: Add a bit_size to nir_register and nir_ssa_def
This really hacky commit adds a bit size to registers and SSA values. It
also adds rules in the validator to validate that they do the right things.
It's still an open question as to whether or not we want a bit_size in
nir_alu_instr or if we just want to let it inherit from the destination.
I'm inclined to just let it inherit from the destination. A similar
question needs to be asked about intrinsics.
---
src/glsl/nir/nir.c | 2 ++
src/glsl/nir/nir.h | 6 ++
src/glsl/nir/nir_validate.c | 43 +++
3 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index f03e80a..7df0d37 100644
--- a/src/glsl/nir/nir.c
+++ b/src/glsl/nir/nir.c
@@ -63,6 +63,7 @@ reg_create(void *mem_ctx, struct exec_list *list)
list_inithead(®->if_uses);
reg->num_components = 0;
+ reg->bit_size = 32;
reg->num_array_elems = 0;
reg->is_packed = false;
reg->name = NULL;
@@ -1895,6 +1896,7 @@ nir_ssa_def_init(nir_instr *instr, nir_ssa_def *def,
list_inithead(&def->uses);
list_inithead(&def->if_uses);
def->num_components = num_components;
+ def->bit_size = 32; /* FIXME: Add an input paremeter or guess? */
if (instr->block) {
nir_function_impl *impl =
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 8dfc68d..42b12ec 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -369,6 +369,9 @@ typedef struct {
unsigned num_components; /** < number of vector components */
unsigned num_array_elems; /** < size of array (0 for no array) */
+ /* The bit-size of each channel; must be one of 8, 16, 32, or 64 */
+ uint8_t bit_size;
+
/** generic register index. */
unsigned index;
@@ -469,6 +472,9 @@ typedef struct {
struct list_head if_uses;
uint8_t num_components;
+
+ /* The bit-size of each channel; must be one of 8, 16, 32, or 64 */
+ uint8_t bit_size;
} nir_ssa_def;
struct nir_src;
diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
index da92ed9..6d9cfea 100644
--- a/src/glsl/nir/nir_validate.c
+++ b/src/glsl/nir/nir_validate.c
@@ -176,9 +176,12 @@ validate_alu_src(nir_alu_instr *instr, unsigned index,
validate_state *state)
nir_alu_src *src = &instr->src[index];
unsigned num_components;
- if (src->src.is_ssa)
+ unsigned src_bit_size;
+ if (src->src.is_ssa) {
+ src_bit_size = src->src.ssa->bit_size;
num_components = src->src.ssa->num_components;
- else {
+ } else {
+ src_bit_size = src->src.reg.reg->bit_size;
if (src->src.reg.reg->is_packed)
num_components = 4; /* can't check anything */
else
@@ -191,6 +194,25 @@ validate_alu_src(nir_alu_instr *instr, unsigned index,
validate_state *state)
assert(src->swizzle[i] < num_components);
}
+ nir_alu_type src_type = nir_op_infos[instr->op].input_types[index];
+
+ /* 8-bit float isn't a thing */
+ if ((src_type & NIR_ALU_TYPE_BASE_TYPE_MASK) == nir_type_float)
+ assert(src_bit_size == 16 || src_bit_size == 32 || src_bit_size == 64);
+
+ if (src_type & NIR_ALU_TYPE_SIZE_MASK) {
+ /* This source has an explicit bit size */
+ assert((src_type & NIR_ALU_TYPE_SIZE_MASK) == src_bit_size);
+ } else {
+ /* The output being explicitly sized would be silly */
+ assert(!(nir_op_infos[instr->op].output_type & NIR_ALU_TYPE_SIZE_MASK));
+
+ unsigned dest_bit_size =
+ instr->dest.dest.is_ssa ? instr->dest.dest.ssa.bit_size
+ : instr->dest.dest.reg.reg->bit_size;
+ assert(dest_bit_size == src_bit_size);
+ }
+
validate_src(&src->src, state);
}
@@ -260,8 +282,10 @@ validate_dest(nir_dest *dest, validate_state *state)
}
static void
-validate_alu_dest(nir_alu_dest *dest, validate_state *state)
+validate_alu_dest(nir_alu_instr *instr, validate_state *state)
{
+ nir_alu_dest *dest = &instr->dest;
+
unsigned dest_size =
dest->dest.is_ssa ? dest->dest.ssa.num_components
: dest->dest.reg.reg->num_components;
@@ -279,6 +303,17 @@ validate_alu_dest(nir_alu_dest *dest, validate_state
*state)
assert(nir_op_infos[alu->op].output_type == nir_type_float ||
!dest->saturate);
+ unsigned bit_size = dest->dest.is_ssa ? dest->dest.ssa.bit_size
+ : dest->dest.reg.reg->bit_size;
+ nir_alu_type type = nir_op_infos[instr->op].output_type;
+
+ /* 8-bit float isn't a thing */
+ if ((type & NIR_ALU_TYPE_BASE_TYPE_MASK) == nir_type_float)
+ assert(bit_size == 16 || bit_size == 32 || bit_size == 64);
+
+ assert((type & NIR_ALU_TYPE_SIZE_MASK) == 0 ||
+ (type & NIR_ALU_TYPE_SIZE_MASK) == bit_size);
+
validate_dest(&dest->dest, state);
}
@@ -287,7 +322,7 @@ validate_alu_instr(nir_alu_instr *instr, validate_state
*state)
{
assert(instr->op < nir_num_opcodes);
- validate_alu_dest(&instr->dest, state);
+ validate
[Mesa-dev] [counter-RFC 2/3] nir: Add explicitly sized types
---
src/glsl/nir/nir.h | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index bc8f063..8dfc68d 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -644,9 +644,23 @@ typedef enum {
nir_type_float,
nir_type_int,
nir_type_uint,
- nir_type_bool
+ nir_type_bool,
+ nir_type_int8 = 8 | nir_type_int,
+ nir_type_int16 = 16 | nir_type_int,
+ nir_type_int32 = 32 | nir_type_int,
+ nir_type_int64 = 64 | nir_type_int,
+ nir_type_uint8 = 8 | nir_type_uint,
+ nir_type_uint16 =16 | nir_type_uint,
+ nir_type_uint32 =32 | nir_type_uint,
+ nir_type_uint64 =64 | nir_type_uint,
+ nir_type_float16 = 16 | nir_type_float,
+ nir_type_float32 = 32 | nir_type_float,
+ nir_type_float64 = 64 | nir_type_float,
} nir_alu_type;
+#define NIR_ALU_TYPE_SIZE_MASK 0xfff0
+#define NIR_ALU_TYPE_BASE_TYPE_MASK 0x000f
+
typedef enum {
NIR_OP_IS_COMMUTATIVE = (1 << 0),
NIR_OP_IS_ASSOCIATIVE = (1 << 1),
--
2.4.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Supporting mediump in NIR
On Fri, May 15, 2015 at 2:39 AM, Topi Pohjolainen wrote: > I wanted to kick-off discussion on how to support floating point > precision qualifiers in NIR. This is purely on optimization for > GLES where one can reduce the number of GPU cycles. At the moment > the compiler discards the qualifiers early when abstract syntax > tree (AST) is transformed into intermediate presentation (IR). > > Iago added the initial support to IR in order to check that the > stages agree on the precision. Naturally I started by rebasing his > work on master (I dropped the actual checking part as it didn't > automatically fit into master). I realized that it isn't sufficient > to have the precision tracked in ir_variable alone. When the IR > is further translated into NIR the precision is needed in ir_rvalue > as well when NIR decides which opcode to use. > Iago's patch isn't needed for the solution here afterall, I just > included it to for context sake. > > Now, there are number of implementation alternatives, I think, both > in AST/IR as well is in NIR. I thought I play with one approach to > provide something "real" to aid the decision making regarding the > architecture. > > I thought that despite fp16 (medium precision float) isn't really a > proper type in glsl, it would clearer if it were one internally in > the compiler though. I kept thinking fp64 and how I would introduce > that into NIR. > The first step was to do pretty much the same as what Dave Airlie > did for doubles (fp64) in the compiler frontend. > > Then in NIR I decided to introduce new opcodes for half floats > instead of modifying the existing float instructions to carry > additional information about the precision. > > I would guess that there are drivers that are not really interested > on this and hence we should means for the drivers to tell if the > precision is to be taken into account or not. One natural place > would be in patch number nine. This is just one example of details > missing in the proposal - these patches are only meant to give a > rough idea how the approach chosen would look like. > > Iago Toral Quiroga (1): > glsl: Add tracking for GLSL precision qualifiers > > Topi Pohjolainen (15): > glsl: Add half float type > mesa: Add half float uniform support > glsl: Add half float type generation > glsl: Allow half float type to be used where-ever float is supported > glsl: Add support for half floats in optimization passes > glsl: Add ubo lowering support for half floats > glsl: Add support for half float loop control > glsl/ast: Use half float type for medium and low precisions > nir: Introduce half float opcodes > nir: Consider float precision when deciding between int/float > nir: Consider float precision when deciding between int/float: part2 > nir: Consider float precision when deciding between uint/int/float > nir: Consider float precision when deciding between uint/float > nir: Consider float precision when deciding opcode > nir: Consider float precision when deciding opcode: part 2 > > src/glsl/ast_to_hir.cpp| 29 ++- > src/glsl/builtin_type_macros.h | 16 ++ > src/glsl/builtin_types.cpp | 31 +++ > src/glsl/glsl_types.cpp| 50 - > src/glsl/glsl_types.h | 29 ++- > src/glsl/ir.h | 13 ++ > src/glsl/ir_clone.cpp | 1 + > src/glsl/ir_print_visitor.cpp | 1 + > src/glsl/ir_validate.cpp | 36 ++-- > src/glsl/link_uniform_initializers.cpp | 2 + > src/glsl/loop_controls.cpp | 1 + > src/glsl/lower_ubo_reference.cpp | 12 +- > src/glsl/nir/glsl_to_nir.cpp | 258 > +++-- > src/glsl/nir/nir.h | 2 + > src/glsl/nir/nir_constant_expressions.py | 8 +- > src/glsl/nir/nir_lower_io.c| 1 + > src/glsl/nir/nir_opcodes.py| 78 +++- > src/glsl/opt_algebraic.cpp | 11 +- > src/glsl/opt_constant_propagation.cpp | 1 + > src/glsl/opt_minmax.cpp| 2 + > src/mesa/drivers/dri/i965/brw_fs.cpp | 1 + > src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 1 + > src/mesa/drivers/dri/i965/brw_shader.cpp | 1 + > src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 1 + > src/mesa/main/uniform_query.cpp| 5 +- > src/mesa/program/ir_to_mesa.cpp| 3 + > 26 files changed, 413 insertions(+), 181 deletions(-) > > -- > 1.9.3 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-d
[Mesa-dev] [PATCH] mesa: fix glPushAttrib(0) / glPopAttrib() error
If the glPushAttrib() mask value was zero we didn't actually push
anything onto the attribute stack. A subsequent glPopAttrib() error
would generate GL_STACK_UNDERFLOW. Now push a dummy attribute in
that case to prevent the error.
Mesa now matches nvidia's behavior.
---
src/mesa/main/attrib.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index b163c0a..365a79d 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -177,6 +177,10 @@ struct texture_state
};
+/** An unused GL_*_BIT value */
+#define DUMMY_BIT 0x1000
+
+
/**
* Allocate new attribute node of given type/kind. Attach payload data.
* Insert it into the linked list named by 'head'.
@@ -253,6 +257,15 @@ _mesa_PushAttrib(GLbitfield mask)
/* groups specified by the mask. */
head = NULL;
+ if (mask == 0) {
+ /* if mask is zero we still need to push something so that we
+ * don't get a GL_STACK_UNDERFLOW error in glPopAttrib().
+ */
+ GLuint dummy = 0;
+ if (!push_attrib(ctx, &head, DUMMY_BIT, sizeof(dummy), &dummy))
+ goto end;
+ }
+
if (mask & GL_ACCUM_BUFFER_BIT) {
if (!push_attrib(ctx, &head, GL_ACCUM_BUFFER_BIT,
sizeof(struct gl_accum_attrib),
@@ -928,6 +941,10 @@ _mesa_PopAttrib(void)
}
switch (attr->kind) {
+ case DUMMY_BIT:
+/* do nothing */
+break;
+
case GL_ACCUM_BUFFER_BIT:
{
const struct gl_accum_attrib *accum;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/20] glapi: Remove static dispatch for functions that didn't exist in fglrx
On 05/14/2015 03:01 PM, Emil Velikov wrote: > On 13/05/15 19:44, Ian Romanick wrote: >> From: Ian Romanick >> >> Comparing the output of >> >> nm -D arch/x86_64/usr/X11R6/lib64/fglrx/fglrx-libGL.so.1.2 |\ >> grep ' T gl[^X]' | sed 's/.* T //' >> >> between Catalyst 14.6 Beta and this commit, the only change is a bunch >> of functions that AMD exports that Mesa does not and some OpenGL ES >> 1.1 functions. >> >> The OpenGL ES 1.1 functions (e.g., glAlphaFuncx) are added by extensions >> in desktop. Our infrastructure doesn't allow us to statically export a >> function in one lib and not in another. The GLES1 conformance tests >> expect to be able to link with these functions, so we have to export >> them. >> > Iirc the Catalyst driver has some (unofficial ?) support for EGL/GLES > via symlinking the libs to libGL. I'm assuming that is the reason which > "inspired" their library to export those symbols. Imho there is no > reason to even remotely worry about them. It's the other way around (which I can make more clear in the commit message). Mesa still exports the "x" functions, but Catalyst does not. Due to limitations in our infrastructure, if I disable those functions in libGL they also disappear from libGLESv1_CM. The Khronos GLES1 conformance tests expect libGLESv1_CM to export the "x" functions, so we can't remove them... from either library. > -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] st/hgl: Move st_api creation to st and extern "C" it
---
src/gallium/state_trackers/hgl/hgl.c | 16
src/gallium/state_trackers/hgl/hgl_context.h | 14 ++
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/hgl/hgl.c
b/src/gallium/state_trackers/hgl/hgl.c
index 77f7c22..1e804c0 100644
--- a/src/gallium/state_trackers/hgl/hgl.c
+++ b/src/gallium/state_trackers/hgl/hgl.c
@@ -7,8 +7,7 @@
* Alexander von Gluck IV, kallis...@unixzen.com
*/
-
-#include "GLView.h"
+#include "hgl_context.h"
#include
@@ -17,8 +16,9 @@
#include "util/u_format.h"
#include "util/u_memory.h"
#include "util/u_inlines.h"
+#include "state_tracker/st_gl_api.h" /* for st_gl_api_create */
-#include "hgl_context.h"
+#include "GLView.h"
#ifdef DEBUG
@@ -93,7 +93,7 @@ hgl_st_framebuffer_validate_textures(struct
st_framebuffer_iface *stfbi,
for (i = 0; i < ST_ATTACHMENT_COUNT; i++)
pipe_resource_reference(&buffer->textures[i], NULL);
}
-
+
memset(&templat, 0, sizeof(templat));
templat.target = buffer->target;
templat.width0 = width;
@@ -258,6 +258,14 @@ hgl_create_st_framebuffer(struct hgl_context* context)
}
+struct st_api*
+hgl_create_st_api()
+{
+ CALLED();
+ return st_gl_api_create();
+}
+
+
struct st_manager *
hgl_create_st_manager(struct hgl_context* context)
{
diff --git a/src/gallium/state_trackers/hgl/hgl_context.h
b/src/gallium/state_trackers/hgl/hgl_context.h
index 4840d9e..d2ec7fb 100644
--- a/src/gallium/state_trackers/hgl/hgl_context.h
+++ b/src/gallium/state_trackers/hgl/hgl_context.h
@@ -9,9 +9,6 @@
#define HGL_CONTEXT_H
-#ifdef __cplusplus
-extern "C" {
-#endif
#include "state_tracker/st_api.h"
#include "state_tracker/st_manager.h"
#include "pipe/p_compiler.h"
@@ -20,8 +17,10 @@ extern "C" {
#include "os/os_thread.h"
#include "bitmap_wrapper.h"
+
+
#ifdef __cplusplus
-}
+extern "C" {
#endif
@@ -82,6 +81,9 @@ struct hgl_context
};
+// hgl state_tracker api
+struct st_api* hgl_create_st_api(void);
+
// hgl state_tracker framebuffer
struct hgl_buffer* hgl_create_st_framebuffer(struct hgl_context* context);
@@ -94,4 +96,8 @@ struct st_visual* hgl_create_st_visual(ulong options);
void hgl_destroy_st_visual(struct st_visual* visual);
+#ifdef __cplusplus
+}
+#endif
+
#endif /* HGL_CONTEXT_H */
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] winsys/hgl: Add needed extern "C" to hgl winsys
---
src/gallium/winsys/sw/hgl/hgl_sw_winsys.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/gallium/winsys/sw/hgl/hgl_sw_winsys.h
b/src/gallium/winsys/sw/hgl/hgl_sw_winsys.h
index bdcddfb..a81f890 100644
--- a/src/gallium/winsys/sw/hgl/hgl_sw_winsys.h
+++ b/src/gallium/winsys/sw/hgl/hgl_sw_winsys.h
@@ -27,9 +27,16 @@
#ifndef _HGL_SOFTWAREWINSYS_H
#define _HGL_SOFTWAREWINSYS_H
+#ifdef __cplusplus
+extern "C" {
+#endif
+
struct sw_winsys;
struct sw_winsys* hgl_create_sw_winsys(void);
+#ifdef __cplusplus
+}
+#endif
#endif
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] gallium/drivers: Add extern "C" wrappers to public entry
---
src/gallium/drivers/llvmpipe/lp_public.h |8
src/gallium/drivers/rbug/rbug_public.h |8
src/gallium/drivers/softpipe/sp_public.h |8
3 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_public.h
b/src/gallium/drivers/llvmpipe/lp_public.h
index ec6b660..27ab1ba 100644
--- a/src/gallium/drivers/llvmpipe/lp_public.h
+++ b/src/gallium/drivers/llvmpipe/lp_public.h
@@ -1,10 +1,18 @@
#ifndef LP_PUBLIC_H
#define LP_PUBLIC_H
+#ifdef __cplusplus
+extern "C" {
+#endif
+
struct pipe_screen;
struct sw_winsys;
struct pipe_screen *
llvmpipe_create_screen(struct sw_winsys *winsys);
+#ifdef __cplusplus
+}
+#endif
+
#endif
diff --git a/src/gallium/drivers/rbug/rbug_public.h
b/src/gallium/drivers/rbug/rbug_public.h
index b66740b..83f9c94 100644
--- a/src/gallium/drivers/rbug/rbug_public.h
+++ b/src/gallium/drivers/rbug/rbug_public.h
@@ -28,6 +28,10 @@
#ifndef RBUG_PUBLIC_H
#define RBUG_PUBLIC_H
+#ifdef __cplusplus
+extern "C" {
+#endif
+
struct pipe_screen;
struct pipe_context;
@@ -37,4 +41,8 @@ rbug_screen_create(struct pipe_screen *screen);
boolean
rbug_enabled(void);
+#ifdef __cplusplus
+}
+#endif
+
#endif /* RBUG_PUBLIC_H */
diff --git a/src/gallium/drivers/softpipe/sp_public.h
b/src/gallium/drivers/softpipe/sp_public.h
index 62d0903..88a9b5e 100644
--- a/src/gallium/drivers/softpipe/sp_public.h
+++ b/src/gallium/drivers/softpipe/sp_public.h
@@ -1,10 +1,18 @@
#ifndef SP_PUBLIC_H
#define SP_PUBLIC_H
+#ifdef __cplusplus
+extern "C" {
+#endif
+
struct pipe_screen;
struct sw_winsys;
struct pipe_screen *
softpipe_create_screen(struct sw_winsys *winsys);
+#ifdef __cplusplus
+}
+#endif
+
#endif
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] target/haiku-softpipe: Move api init into st code
We also reduce the amount of need-to-know information about st_api
to require one less extern "C" in st_manager.h
---
.../targets/haiku-softpipe/GalliumContext.cpp | 23 +++
.../targets/haiku-softpipe/GalliumContext.h|6 +
2 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
index b24aef7..1e3874b 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
@@ -15,14 +15,13 @@
#include "GLView.h"
#include "bitmap_wrapper.h"
-extern "C" {
+
#include "glapi/glapi.h"
#include "pipe/p_format.h"
-#include "state_tracker/st_cb_fbo.h"
-#include "state_tracker/st_cb_flush.h"
+//#include "state_tracker/st_cb_fbo.h"
+//#include "state_tracker/st_cb_flush.h"
#include "state_tracker/st_context.h"
#include "state_tracker/st_gl_api.h"
-#include "state_tracker/st_manager.h"
#include "state_tracker/sw_winsys.h"
#include "sw/hgl/hgl_sw_winsys.h"
#include "util/u_atomic.h"
@@ -30,7 +29,6 @@ extern "C" {
#include "target-helpers/inline_sw_helper.h"
#include "target-helpers/inline_debug_helper.h"
-}
#ifdef DEBUG
@@ -127,7 +125,8 @@ GalliumContext::CreateContext(Bitmap *bitmap)
context->read = NULL;
context->st = NULL;
- context->api = st_gl_api_create();
+ // Create st_gl_api
+ context->api = hgl_create_st_api();
if (!context->api) {
ERROR("%s: Couldn't obtain Mesa state tracker API!\n",
__func__);
return -1;
@@ -159,12 +158,10 @@ GalliumContext::CreateContext(Bitmap *bitmap)
attribs.minor = 0;
//attribs.flags |= ST_CONTEXT_FLAG_DEBUG;
- struct st_api* api = context->api;
-
// Create context using state tracker api call
enum st_context_error result;
- context->st = api->create_context(api, context->manager, &attribs,
- &result, context->st);
+ context->st = context->api->create_context(context->api,
context->manager,
+ &attribs, &result, context->st);
if (!context->st) {
ERROR("%s: Couldn't create mesa state tracker context!\n",
@@ -289,10 +286,8 @@ GalliumContext::SetCurrentContext(Bitmap *bitmap,
context_id contextID)
return B_ERROR;
}
- struct st_api* api = context->api;
-
if (!bitmap) {
- api->make_current(context->api, NULL, NULL, NULL);
+ context->api->make_current(context->api, NULL, NULL, NULL);
return B_OK;
}
@@ -305,7 +300,7 @@ GalliumContext::SetCurrentContext(Bitmap *bitmap,
context_id contextID)
}
// We need to lock and unlock framebuffers before accessing them
- api->make_current(context->api, context->st, context->draw->stfbi,
+ context->api->make_current(context->api, context->st,
context->draw->stfbi,
context->read->stfbi);
//if (context->textures[ST_ATTACHMENT_BACK_LEFT]
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.h
b/src/gallium/targets/haiku-softpipe/GalliumContext.h
index b50d528..22076cb 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.h
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.h
@@ -12,14 +12,10 @@
#include
#include
-extern "C" {
-//#include "state_tracker/st_api.h"
#include "pipe/p_compiler.h"
#include "pipe/p_screen.h"
#include "postprocess/filters.h"
-#include "os/os_thread.h"
#include "hgl_context.h"
-}
#include "bitmap_wrapper.h"
@@ -56,6 +52,6 @@ private:
context_id fCurrentContext;
pipe_mutex fMutex;
};
-
+
#endif /* GALLIUMCONTEXT_H */
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] gallium/aux: Add needed extern "C" wrappers
---
src/gallium/auxiliary/postprocess/postprocess.h |9 +
src/gallium/auxiliary/util/u_tests.h|8
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/postprocess/postprocess.h
b/src/gallium/auxiliary/postprocess/postprocess.h
index c72f2c4..9b9f981 100644
--- a/src/gallium/auxiliary/postprocess/postprocess.h
+++ b/src/gallium/auxiliary/postprocess/postprocess.h
@@ -30,6 +30,10 @@
#include "pipe/p_state.h"
+#ifdef __cplusplus
+extern "C" {
+#endif
+
struct cso_context;
struct pp_queue_t; /* Forward definition */
@@ -85,4 +89,9 @@ void pp_celshade_free(struct pp_queue_t *, unsigned int);
void pp_nocolor_free(struct pp_queue_t *, unsigned int);
void pp_jimenezmlaa_free(struct pp_queue_t *, unsigned int);
+
+#ifdef __cplusplus
+}
+#endif
+
#endif
diff --git a/src/gallium/auxiliary/util/u_tests.h
b/src/gallium/auxiliary/util/u_tests.h
index 49ae54f..106b0a0 100644
--- a/src/gallium/auxiliary/util/u_tests.h
+++ b/src/gallium/auxiliary/util/u_tests.h
@@ -30,8 +30,16 @@
#include "pipe/p_compiler.h"
+#ifdef __cplusplus
+extern "C" {
+#endif
+
struct pipe_screen;
void util_run_tests(struct pipe_screen *screen);
+#ifdef __cplusplus
+}
+#endif
+
#endif
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Supporting mediump in NIR
Hey Topi! Thanks for working on this! I've been meaning to do something for fp16 and fp64 in NIR for a while and just haven't gotten to it. I just sent out three "patches" laying out how I was intending to do it. I put "patches" in quotes because they're so half-baked they barely compile. It's what I could get typed up in the hour or two before breakfast. I am not at all trying to say that the explisit types mechanism isn't what we want. I'm still undecided for the moment because both mechanisms have their merits. I just wanted to throw both out there so that we can have a proper discussion. --Jason On Fri, May 15, 2015 at 2:39 AM, Topi Pohjolainen wrote: > I wanted to kick-off discussion on how to support floating point > precision qualifiers in NIR. This is purely on optimization for > GLES where one can reduce the number of GPU cycles. At the moment > the compiler discards the qualifiers early when abstract syntax > tree (AST) is transformed into intermediate presentation (IR). > > Iago added the initial support to IR in order to check that the > stages agree on the precision. Naturally I started by rebasing his > work on master (I dropped the actual checking part as it didn't > automatically fit into master). I realized that it isn't sufficient > to have the precision tracked in ir_variable alone. When the IR > is further translated into NIR the precision is needed in ir_rvalue > as well when NIR decides which opcode to use. > Iago's patch isn't needed for the solution here afterall, I just > included it to for context sake. > > Now, there are number of implementation alternatives, I think, both > in AST/IR as well is in NIR. I thought I play with one approach to > provide something "real" to aid the decision making regarding the > architecture. And I just sent something that's definitely not real. It's not even "real"... > I thought that despite fp16 (medium precision float) isn't really a > proper type in glsl, it would clearer if it were one internally in > the compiler though. I kept thinking fp64 and how I would introduce > that into NIR. > The first step was to do pretty much the same as what Dave Airlie > did for doubles (fp64) in the compiler frontend. > > Then in NIR I decided to introduce new opcodes for half floats > instead of modifying the existing float instructions to carry > additional information about the precision. > > I would guess that there are drivers that are not really interested > on this and hence we should means for the drivers to tell if the > precision is to be taken into account or not. One natural place > would be in patch number nine. This is just one example of details > missing in the proposal - these patches are only meant to give a > rough idea how the approach chosen would look like. > > Iago Toral Quiroga (1): > glsl: Add tracking for GLSL precision qualifiers > > Topi Pohjolainen (15): > glsl: Add half float type > mesa: Add half float uniform support > glsl: Add half float type generation > glsl: Allow half float type to be used where-ever float is supported > glsl: Add support for half floats in optimization passes > glsl: Add ubo lowering support for half floats > glsl: Add support for half float loop control > glsl/ast: Use half float type for medium and low precisions > nir: Introduce half float opcodes > nir: Consider float precision when deciding between int/float > nir: Consider float precision when deciding between int/float: part2 > nir: Consider float precision when deciding between uint/int/float > nir: Consider float precision when deciding between uint/float > nir: Consider float precision when deciding opcode > nir: Consider float precision when deciding opcode: part 2 > > src/glsl/ast_to_hir.cpp| 29 ++- > src/glsl/builtin_type_macros.h | 16 ++ > src/glsl/builtin_types.cpp | 31 +++ > src/glsl/glsl_types.cpp| 50 - > src/glsl/glsl_types.h | 29 ++- > src/glsl/ir.h | 13 ++ > src/glsl/ir_clone.cpp | 1 + > src/glsl/ir_print_visitor.cpp | 1 + > src/glsl/ir_validate.cpp | 36 ++-- > src/glsl/link_uniform_initializers.cpp | 2 + > src/glsl/loop_controls.cpp | 1 + > src/glsl/lower_ubo_reference.cpp | 12 +- > src/glsl/nir/glsl_to_nir.cpp | 258 > +++-- > src/glsl/nir/nir.h | 2 + > src/glsl/nir/nir_constant_expressions.py | 8 +- > src/glsl/nir/nir_lower_io.c| 1 + > src/glsl/nir/nir_opcodes.py| 78 +++- > src/glsl/opt_algebraic.cpp | 11 +- > src/glsl/opt_constant_propagation.cpp | 1 + > src/glsl/opt_minmax.cpp| 2 + > src/mesa/drivers/dri/i965/brw_fs.cpp
Re: [Mesa-dev] [PATCH 02/20] mesa: Remove all vestiges of glFramebufferTextureFaceARB
On 05/14/2015 02:44 PM, Emil Velikov wrote: > On 13/05/15 19:44, Ian Romanick wrote: >> From: Ian Romanick >> >> Mesa does not (and probably never will) support GL_ARB_geometry_shader4, >> so this function will never exist. > In the (very unlikely) event that we do support the extension, won't > this change cause issues when mixing libGL/libglapi/dri modules ? > >> Having a function that is >> exec="skip" and offset="assign" is just weird. >> > We have a few more of those (barring the deprecated ones): > SampleMaskSGIS > SamplePatternSGIS > ResizeBuffersMESA > > Should we do the same for them as well, or perhaps just mention why > they're "left behind" ? I think ResizeBuffersMESA could also go away. The SGIS_multisample functions are supported for indirect rendering interoperability. If any of those functions are removed, we'll also have to remove the extension strings from src/glx/glxextensions.c. The strangeness for all 3 functions mostly goes away in patches 13 and 15. How about if I add a note to the commit message and send a follow-up patch for after the branch point? > -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] target/haiku-softpipe: Move api init into st code
Series looks OK to me (though I didn't look too closely at the specific
Haiku changes).
Reviewed-by: Brian Paul
On 05/15/2015 11:29 AM, Alexander von Gluck IV wrote:
We also reduce the amount of need-to-know information about st_api
to require one less extern "C" in st_manager.h
---
.../targets/haiku-softpipe/GalliumContext.cpp | 23 +++
.../targets/haiku-softpipe/GalliumContext.h|6 +
2 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
index b24aef7..1e3874b 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
@@ -15,14 +15,13 @@
#include "GLView.h"
#include "bitmap_wrapper.h"
-extern "C" {
+
#include "glapi/glapi.h"
#include "pipe/p_format.h"
-#include "state_tracker/st_cb_fbo.h"
-#include "state_tracker/st_cb_flush.h"
+//#include "state_tracker/st_cb_fbo.h"
+//#include "state_tracker/st_cb_flush.h"
#include "state_tracker/st_context.h"
#include "state_tracker/st_gl_api.h"
-#include "state_tracker/st_manager.h"
#include "state_tracker/sw_winsys.h"
#include "sw/hgl/hgl_sw_winsys.h"
#include "util/u_atomic.h"
@@ -30,7 +29,6 @@ extern "C" {
#include "target-helpers/inline_sw_helper.h"
#include "target-helpers/inline_debug_helper.h"
-}
#ifdef DEBUG
@@ -127,7 +125,8 @@ GalliumContext::CreateContext(Bitmap *bitmap)
context->read = NULL;
context->st = NULL;
- context->api = st_gl_api_create();
+ // Create st_gl_api
+ context->api = hgl_create_st_api();
if (!context->api) {
ERROR("%s: Couldn't obtain Mesa state tracker API!\n",
__func__);
return -1;
@@ -159,12 +158,10 @@ GalliumContext::CreateContext(Bitmap *bitmap)
attribs.minor = 0;
//attribs.flags |= ST_CONTEXT_FLAG_DEBUG;
- struct st_api* api = context->api;
-
// Create context using state tracker api call
enum st_context_error result;
- context->st = api->create_context(api, context->manager, &attribs,
- &result, context->st);
+ context->st = context->api->create_context(context->api,
context->manager,
+ &attribs, &result, context->st);
if (!context->st) {
ERROR("%s: Couldn't create mesa state tracker context!\n",
@@ -289,10 +286,8 @@ GalliumContext::SetCurrentContext(Bitmap *bitmap,
context_id contextID)
return B_ERROR;
}
- struct st_api* api = context->api;
-
if (!bitmap) {
- api->make_current(context->api, NULL, NULL, NULL);
+ context->api->make_current(context->api, NULL, NULL, NULL);
return B_OK;
}
@@ -305,7 +300,7 @@ GalliumContext::SetCurrentContext(Bitmap *bitmap,
context_id contextID)
}
// We need to lock and unlock framebuffers before accessing them
- api->make_current(context->api, context->st, context->draw->stfbi,
+ context->api->make_current(context->api, context->st,
context->draw->stfbi,
context->read->stfbi);
//if (context->textures[ST_ATTACHMENT_BACK_LEFT]
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.h
b/src/gallium/targets/haiku-softpipe/GalliumContext.h
index b50d528..22076cb 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.h
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.h
@@ -12,14 +12,10 @@
#include
#include
-extern "C" {
-//#include "state_tracker/st_api.h"
#include "pipe/p_compiler.h"
#include "pipe/p_screen.h"
#include "postprocess/filters.h"
-#include "os/os_thread.h"
#include "hgl_context.h"
-}
#include "bitmap_wrapper.h"
@@ -56,6 +52,6 @@ private:
context_id fCurrentContext;
pipe_mutex fMutex;
};
-
+
#endif /* GALLIUMCONTEXT_H */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix glPushAttrib(0) / glPopAttrib() error
On 05/15/2015 11:31 AM, Brian Paul wrote:
If the glPushAttrib() mask value was zero we didn't actually push
anything onto the attribute stack. A subsequent glPopAttrib() error
I'll s/error/call/ there.
would generate GL_STACK_UNDERFLOW. Now push a dummy attribute in
that case to prevent the error.
Mesa now matches nvidia's behavior.
---
src/mesa/main/attrib.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index b163c0a..365a79d 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -177,6 +177,10 @@ struct texture_state
};
+/** An unused GL_*_BIT value */
+#define DUMMY_BIT 0x1000
+
+
/**
* Allocate new attribute node of given type/kind. Attach payload data.
* Insert it into the linked list named by 'head'.
@@ -253,6 +257,15 @@ _mesa_PushAttrib(GLbitfield mask)
/* groups specified by the mask. */
head = NULL;
+ if (mask == 0) {
+ /* if mask is zero we still need to push something so that we
+ * don't get a GL_STACK_UNDERFLOW error in glPopAttrib().
+ */
+ GLuint dummy = 0;
+ if (!push_attrib(ctx, &head, DUMMY_BIT, sizeof(dummy), &dummy))
+ goto end;
+ }
+
if (mask & GL_ACCUM_BUFFER_BIT) {
if (!push_attrib(ctx, &head, GL_ACCUM_BUFFER_BIT,
sizeof(struct gl_accum_attrib),
@@ -928,6 +941,10 @@ _mesa_PopAttrib(void)
}
switch (attr->kind) {
+ case DUMMY_BIT:
+/* do nothing */
+break;
+
case GL_ACCUM_BUFFER_BIT:
{
const struct gl_accum_attrib *accum;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] i965 implementation of the ARB_shader_image_load_store built-ins. (v3)
On Fri, May 15, 2015 at 9:51 AM, Francisco Jerez wrote: > Jason Ekstrand writes: > >> I haven't said much about this series up until now. I've mostly sat >> and watched and focused my time on other things. As I said in the >> meeting today, I think that part of the problem here is that there are >> at least 3 "refactors" in here besides the new feature. By >> "refactors", I mean "new ways of solving problem X". Part of the >> problem with the discussion is that all of this has been conflated and >> we aren't actually talking about how to solve each of those problems. >> I'm going to try and break it out here to try and aid in the >> discussion. >> > Thanks a lot Jason for giving a more constructive turn to this > discussion. :) > >> 1) The builder. I think *everyone* likes the builder. The argument >> here is not over whether or not we want it. People have expressed >> concern that adding the builder now without actually doing the >> refactor will result in duplicated code that will get out-of-sync. I >> think the best solution here is to go ahead and do the builder stuff >> immediately after the branch point. >> > Agreed. > >> 2) SIMD8 instruction splitting. As I said in the call, we've done >> this a variety of ways in the past usually by emitting the split >> instructions in the visitor and manually using half() and >> inst->force_sechalf. We also have a few places that I think still >> split the code in the generator. What you're doing is a somewhat more >> elegant version of the "emit it in the visitor" stuff that we've done >> in the past. You've got your zip/unzip functions etc. to handle >> splitting and combining and then you have a loop to actually emit the >> sends. Really, it's fairly nice and concise. The question is whether >> or not it's really what we want to do (more on this in a bit). >> > There is another closely related problem that this infrastructure solves > and may not be obvious in this series (it was in my original branch > though [1]), but I think it's worth keeping in mind, I'll call it 2.1: > Some of the surface messages lacked SIMD4x2 variants, so a strided copy > is required to transpose the original AoS vector into SoA form. This > turns out to be algorithmically identical to the strided copy required > to "unzip" a SIMD16 vector, so it can be accomplished without additional > effort. > > These transformations are largely transparent for the functions building > typed/untyped surface messages, they are hidden behind an interface that > doesn't seem to have received any attention yet: > > - struct vector_layout: This represents the layout of a vector in a >payload. It's initialized based on the restrictions of the hardware >for the specific message we want to send, and the current code >generation parameters (i.e. SIMD mode). > > - emit_insert(): This takes a vector with the layout native to the EU >(e.g. an fs_reg) and performs the required transformations to turn it >into a form suitable for the shared unit according to a vector_layout >struct (what may involve unzipping, a strided copy or no work at >all). > > - emit_extract(): The converse of emit_insert(). This takes a payload >fragment (array_reg) and transforms it into a vector of native >layout, according to a vector_layout struct. > > My intention was to come up with an interface more general than SIMD16 > vector splitting and SIMD4x2 to SIMD8 conversion alone, I was also > thinking texturing instruction payload quirks (which might require > padding or different permutations of the same values depending on the > generation even if the SIMD mode is natively supported -- let's call > this 2.2) and framebuffer writes (2.3). Thank you for pointing out what else you were trying to do with it. I understand that you're trying to solve a dozen different problems and that the infrastructure you've created is one that you think solves all of them at the same time. It helps to know what all problems you were trying to solve. However, since we are putting SIMD4x2 aside for now, in the interest of keeping us from getting side-tracked, let's table this for now. It's a problem that may need solving, but it's a *different* problem. >> 3) Array reg. This is something of a helper to (2). > > In fact the primary motivation for array_reg wasn't instruction > splitting, but emit_collect(), more on that later. > >> I agree that it's nice to be able to have access to the size of a >> register without having to look at the allocator. The problem here >> (and why we don't have a size in fs_reg) is that we copy the reigster >> around. Every register does have some sort of "underlying storage" >> that it shares with other registers with the same number. But that >> storage is represented by the size in the allocator and nothing else. >> Is that bad? Maybe. Should we have a way of passing the size around >> with it? Maybe. In any case, I think it's best to table this >> dis
Re: [Mesa-dev] RFC: Supporting mediump in NIR
On Fri, May 15, 2015 at 10:32:44AM -0700, Jason Ekstrand wrote: > Hey Topi! Thanks for working on this! > > I've been meaning to do something for fp16 and fp64 in NIR for a while > and just haven't gotten to it. I just sent out three "patches" laying > out how I was intending to do it. I put "patches" in quotes because > they're so half-baked they barely compile. It's what I could get > typed up in the hour or two before breakfast. > > I am not at all trying to say that the explisit types mechanism isn't > what we want. I'm still undecided for the moment because both > mechanisms have their merits. I just wanted to throw both out there > so that we can have a proper discussion. Initially your approach looks really tempting. I like the simplicity and the fact that we don't need to explicitly duplicate things - most likely we need less test cases for corner cases. I would probably continue the discussion there. > --Jason > > On Fri, May 15, 2015 at 2:39 AM, Topi Pohjolainen > wrote: > > I wanted to kick-off discussion on how to support floating point > > precision qualifiers in NIR. This is purely on optimization for > > GLES where one can reduce the number of GPU cycles. At the moment > > the compiler discards the qualifiers early when abstract syntax > > tree (AST) is transformed into intermediate presentation (IR). > > > > Iago added the initial support to IR in order to check that the > > stages agree on the precision. Naturally I started by rebasing his > > work on master (I dropped the actual checking part as it didn't > > automatically fit into master). I realized that it isn't sufficient > > to have the precision tracked in ir_variable alone. When the IR > > is further translated into NIR the precision is needed in ir_rvalue > > as well when NIR decides which opcode to use. > > Iago's patch isn't needed for the solution here afterall, I just > > included it to for context sake. > > > > Now, there are number of implementation alternatives, I think, both > > in AST/IR as well is in NIR. I thought I play with one approach to > > provide something "real" to aid the decision making regarding the > > architecture. > > And I just sent something that's definitely not real. It's not even "real"... > > > I thought that despite fp16 (medium precision float) isn't really a > > proper type in glsl, it would clearer if it were one internally in > > the compiler though. I kept thinking fp64 and how I would introduce > > that into NIR. > > The first step was to do pretty much the same as what Dave Airlie > > did for doubles (fp64) in the compiler frontend. > > > > Then in NIR I decided to introduce new opcodes for half floats > > instead of modifying the existing float instructions to carry > > additional information about the precision. > > > > I would guess that there are drivers that are not really interested > > on this and hence we should means for the drivers to tell if the > > precision is to be taken into account or not. One natural place > > would be in patch number nine. This is just one example of details > > missing in the proposal - these patches are only meant to give a > > rough idea how the approach chosen would look like. > > > > Iago Toral Quiroga (1): > > glsl: Add tracking for GLSL precision qualifiers > > > > Topi Pohjolainen (15): > > glsl: Add half float type > > mesa: Add half float uniform support > > glsl: Add half float type generation > > glsl: Allow half float type to be used where-ever float is supported > > glsl: Add support for half floats in optimization passes > > glsl: Add ubo lowering support for half floats > > glsl: Add support for half float loop control > > glsl/ast: Use half float type for medium and low precisions > > nir: Introduce half float opcodes > > nir: Consider float precision when deciding between int/float > > nir: Consider float precision when deciding between int/float: part2 > > nir: Consider float precision when deciding between uint/int/float > > nir: Consider float precision when deciding between uint/float > > nir: Consider float precision when deciding opcode > > nir: Consider float precision when deciding opcode: part 2 > > > > src/glsl/ast_to_hir.cpp| 29 ++- > > src/glsl/builtin_type_macros.h | 16 ++ > > src/glsl/builtin_types.cpp | 31 +++ > > src/glsl/glsl_types.cpp| 50 - > > src/glsl/glsl_types.h | 29 ++- > > src/glsl/ir.h | 13 ++ > > src/glsl/ir_clone.cpp | 1 + > > src/glsl/ir_print_visitor.cpp | 1 + > > src/glsl/ir_validate.cpp | 36 ++-- > > src/glsl/link_uniform_initializers.cpp | 2 + > > src/glsl/loop_controls.cpp | 1 + > > src/glsl/lower_ubo_reference.cpp | 12 +- > > src/glsl/nir/glsl_to_nir.cpp | 258 > > ++
Re: [Mesa-dev] [PATCH] mesa: do not use _glapi_new_nop_table() for DRI builds
On 05/15/2015 11:14 AM, Emil Velikov wrote:
On 15/05/15 15:13, Brian Paul wrote:
Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
_glapi_set_nop_handler() functions in the glapi dispatcher (which
live in libGL.so). The calls to those functions from context.c
would be undefined (i.e. an ABI break) if the libGL used at runtime
was older.
For the time being, use the old single generic_nop() function for
DRI builds to avoid this problem. At some point in the future it
should be safe to remove this work-around. See comments for more
details.
---
src/mesa/main/context.c | 60 -
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 544cc14..0649708 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -883,6 +883,19 @@ update_default_objects(struct gl_context *ctx)
}
+/* XXX this is temporary and should be removed at some point in the
+ * future when there's a reasonable expectation that the libGL library
+ * contains the _glapi_new_nop_table() and _glapi_set_nop_handler()
+ * functions which were added in Mesa 10.6.
+ */
+#if defined(GLX_DIRECT_RENDERING)
I'd say that this should be WIN32, similar to the original code. The
code is indirectly used by gbm/egl as well, so introducing
GLX_{IN,}DIRECT_RENDERING here might not fair so well.
Sure, that's fine.
+/* Avoid libGL / driver ABI break */
+#define USE_GLAPI_NOP_FEATURES 0
+#else
+#define USE_GLAPI_NOP_FEATURES 1
+#endif
+
+
/**
* This function is called by the glapi no-op functions. For each OpenGL
* function/entrypoint there's a simple no-op function. These "no-op"
@@ -898,6 +911,7 @@ update_default_objects(struct gl_context *ctx)
*
* \param name the name of the OpenGL function
*/
+#if USE_GLAPI_NOP_FEATURES
static void
nop_handler(const char *name)
{
@@ -914,6 +928,7 @@ nop_handler(const char *name)
}
#endif
}
+#endif
/**
@@ -928,6 +943,44 @@ nop_glFlush(void)
Seems like the macro guarding nop_glFlush() should be
USE_GLAPI_NOP_FEATURES ? Then we can drop the explicit
!USE_GLAPI_NOP_FEATURES below and use #else.
No, nop_glFlush() is specifically a Windows / WGL fix. See comments
elsewhere.
The comment within nop_glFlush could use an update as well.
Will do.
#endif
+#if !USE_GLAPI_NOP_FEATURES
Fold this and the follow up function new_nop_table() into #if block ?
My preference is wrap each individual function for readability.
+static int
+generic_nop(void)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "unsupported function called "
+ "(unsupported extension or deprecated function?)");
+ return 0;
+}
+#endif
+
+
+/**
+ * Create a new API dispatch table in which all entries point to the
+ * generic_nop() function. This will not work on Windows because of
+ * the __stdcall convention which requires the callee to clean up the
+ * call stack. That's impossible with one generic no-op function.
+ */
+#if !USE_GLAPI_NOP_FEATURES
+static struct _glapi_table *
+new_nop_table(unsigned numEntries)
+{
+ struct _glapi_table *table;
+
+ table = malloc(numEntries * sizeof(_glapi_proc));
+ if (table) {
+ _glapi_proc *entry = (_glapi_proc *) table;
+ unsigned i;
+ for (i = 0; i < numEntries; i++) {
+ entry[i] = (_glapi_proc) generic_nop;
+ }
Bikeshed: One could use memset, analogous to the memcpy() in
_glapi_new_nop_table.
How would memset work? I'm assigning 4 or 8-byte pointers.
+ }
+ return table;
+}
+#endif
+
+
/**
* Allocate and initialize a new dispatch table. The table will be
* populated with pointers to "no-op" functions. In turn, the no-op
@@ -936,12 +989,16 @@ nop_glFlush(void)
static struct _glapi_table *
alloc_dispatch_table(void)
{
+ int numEntries = MAX2(_glapi_get_dispatch_table_size(), _gloffset_COUNT);
+
+#if !USE_GLAPI_NOP_FEATURES
+ struct _glapi_table *table = new_nop_table(numEntries);
+#else
/* Find the larger of Mesa's dispatch table and libGL's dispatch table.
* In practice, this'll be the same for stand-alone Mesa. But for DRI
* Mesa we do this to accommodate different versions of libGL and various
* DRI drivers.
*/
Move the comment as well as numEntries.
I'll move the comment but I don't understand what you mean by moving
numEntries. It's used in both clauses of the #if.
- GLint numEntries = MAX2(_glapi_get_dispatch_table_size(), _gloffset_COUNT);
struct _glapi_table *table = _glapi_new_nop_table(numEntries);
#if defined(_WIN32)
@@ -967,6 +1024,7 @@ alloc_dispatch_table(void)
#endif
_glapi_set_nop_handler(nop_handler);
+#endif
return table;
}
Should we revert commit 627991dbf74(dri: add _glapi_set_nop_handler(),
_glapi_new_nop_table() to dri_test.c) now that the new symbols are no
longer around ?
Per the comments, I'd like to r
[Mesa-dev] [PATCH] st/mesa: Flush the bitmap cache in st_BlitFramebuffer
With DSA we can no longer rely on this being done in st_validate_state in response to the framebuffer bindings having changed. This fixes the ext_framebuffer_multisample-bitmap piglit test. --- src/mesa/state_tracker/st_cb_blit.c | 4 1 file changed, 4 insertions(+) diff --git a/src/mesa/state_tracker/st_cb_blit.c b/src/mesa/state_tracker/st_cb_blit.c index bbaedd1..75289ae 100644 --- a/src/mesa/state_tracker/st_cb_blit.c +++ b/src/mesa/state_tracker/st_cb_blit.c @@ -36,6 +36,7 @@ #include "st_context.h" #include "st_texture.h" +#include "st_cb_bitmap.h" #include "st_cb_blit.h" #include "st_cb_fbo.h" #include "st_atom.h" @@ -93,6 +94,9 @@ st_BlitFramebuffer(struct gl_context *ctx, st_validate_state(st); + /* Make sure bitmap rendering has landed in the read framebuffer */ + st_flush_bitmap_cache(st); + clip.srcX0 = srcX0; clip.srcY0 = srcY0; clip.srcX1 = srcX1; -- 2.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/20] glapi: Remove static dispatch for functions that didn't exist in fglrx
On 15/05/15 17:29, Ian Romanick wrote: > On 05/14/2015 03:01 PM, Emil Velikov wrote: >> On 13/05/15 19:44, Ian Romanick wrote: >>> From: Ian Romanick >>> >>> Comparing the output of >>> >>> nm -D arch/x86_64/usr/X11R6/lib64/fglrx/fglrx-libGL.so.1.2 |\ >>> grep ' T gl[^X]' | sed 's/.* T //' >>> >>> between Catalyst 14.6 Beta and this commit, the only change is a bunch >>> of functions that AMD exports that Mesa does not and some OpenGL ES >>> 1.1 functions. >>> >>> The OpenGL ES 1.1 functions (e.g., glAlphaFuncx) are added by extensions >>> in desktop. Our infrastructure doesn't allow us to statically export a >>> function in one lib and not in another. The GLES1 conformance tests >>> expect to be able to link with these functions, so we have to export >>> them. >>> >> Iirc the Catalyst driver has some (unofficial ?) support for EGL/GLES >> via symlinking the libs to libGL. I'm assuming that is the reason which >> "inspired" their library to export those symbols. Imho there is no >> reason to even remotely worry about them. > > It's the other way around (which I can make more clear in the commit > message). Mesa still exports the "x" functions, but Catalyst does not. > Due to limitations in our infrastructure, if I disable those functions > in libGL they also disappear from libGLESv1_CM. The Khronos GLES1 > conformance tests expect libGLESv1_CM to export the "x" functions, so we > can't remove them... from either library. > I guess I wasn't clear enough - the Catalyst does provide a bunch of symbols more than mesa. Some of which I assume (although haven't checked) are part of the GLES* api. There is something funny especially since the same library provides eglGetProcAddress. There are some (rather strange) suggestions on the web that the library can be used as a libEGL/libGLES* replacement. Thus I aimed my earlier comment as - there is not point for mesa to attempt to provide all the functions listed by the Catalyst. Hope ^^ came out less patronising than usual :-) Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/20] mesa: Remove all vestiges of glFramebufferTextureFaceARB
On 15/05/15 17:35, Ian Romanick wrote: > On 05/14/2015 02:44 PM, Emil Velikov wrote: >> On 13/05/15 19:44, Ian Romanick wrote: >>> From: Ian Romanick >>> >>> Mesa does not (and probably never will) support GL_ARB_geometry_shader4, >>> so this function will never exist. >> In the (very unlikely) event that we do support the extension, won't >> this change cause issues when mixing libGL/libglapi/dri modules ? >> >>> Having a function that is >>> exec="skip" and offset="assign" is just weird. >>> >> We have a few more of those (barring the deprecated ones): >> SampleMaskSGIS >> SamplePatternSGIS >> ResizeBuffersMESA >> >> Should we do the same for them as well, or perhaps just mention why >> they're "left behind" ? > > I think ResizeBuffersMESA could also go away. The SGIS_multisample > functions are supported for indirect rendering interoperability. If any > of those functions are removed, we'll also have to remove the extension > strings from src/glx/glxextensions.c. The strangeness for all 3 > functions mostly goes away in patches 13 and 15. > > How about if I add a note to the commit message and send a follow-up > patch for after the branch point? > Definitely. Btw, I will be branching late (after 23:00 (GMT+1)) or very early tomorrow morning. Thanks again for the nice cleanup. Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): 57 new commits
On 05/15/2015 05:26 AM, Fredrik Höglund wrote: > On Friday 15 May 2015, Michel Dänzer wrote: >> On 14.05.2015 22:52, fred...@kemper.freedesktop.org (Fredrik HXXglund) >> wrote: >>> >>> URL: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=6b284f08ab399154ad10e2166440b44cbbdcb2c5 >>> Author: Laura Ekstrand >>> Date: Tue Feb 3 14:47:00 2015 -0800 >>> >>> main: _mesa_blit_framebuffer updates its arbitrary framebuffers. >>> >>> Previously, we used _mesa_update_state to update the currently bound >>> framebuffers prior to performing a blit. Now that >>> _mesa_blit_framebuffer >>> uses arbitrary framebuffers, _mesa_update_state is not specific enough. >>> >>> Reviewed-by: Fredrik Höglund >>> Signed-off-by: Fredrik Höglund >> >> This commit broke the piglit test >> spec@ext_framebuffer_multisample@bitmap with the radeonsi driver: >> >> Probe color at (224,0) >> Left: 0.00 0.00 0.00 1.00 >> Right: 1.00 1.00 1.00 1.00 >> >> Looks like it's because the bottom right squares of the Xs are missing, >> see the attached picture. >> >> Any ideas? > > I did notice that failure as well, but when I ran the test manually it > passed for me, leading me to think that it was a spurious failure. > > The output looks exactly the same for me. But the test works by > comparing the left and right halves of the framebuffer, so if the > bottom right squares are missing on both sides, the test should > pass. > > The left side is the test image, and the right side is the reference > image. I'm also going to say that I'm quite pissed that this series landed without my objections being addressed. I've half a mind to revert the whole lot! > Fredrik > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/20] glapi: Remove static dispatch for functions that didn't exist in fglrx
On 05/15/2015 12:11 PM, Emil Velikov wrote: > On 15/05/15 17:29, Ian Romanick wrote: >> On 05/14/2015 03:01 PM, Emil Velikov wrote: >>> On 13/05/15 19:44, Ian Romanick wrote: From: Ian Romanick Comparing the output of nm -D arch/x86_64/usr/X11R6/lib64/fglrx/fglrx-libGL.so.1.2 |\ grep ' T gl[^X]' | sed 's/.* T //' between Catalyst 14.6 Beta and this commit, the only change is a bunch of functions that AMD exports that Mesa does not and some OpenGL ES 1.1 functions. The OpenGL ES 1.1 functions (e.g., glAlphaFuncx) are added by extensions in desktop. Our infrastructure doesn't allow us to statically export a function in one lib and not in another. The GLES1 conformance tests expect to be able to link with these functions, so we have to export them. >>> Iirc the Catalyst driver has some (unofficial ?) support for EGL/GLES >>> via symlinking the libs to libGL. I'm assuming that is the reason which >>> "inspired" their library to export those symbols. Imho there is no >>> reason to even remotely worry about them. >> >> It's the other way around (which I can make more clear in the commit >> message). Mesa still exports the "x" functions, but Catalyst does not. >> Due to limitations in our infrastructure, if I disable those functions >> in libGL they also disappear from libGLESv1_CM. The Khronos GLES1 >> conformance tests expect libGLESv1_CM to export the "x" functions, so we >> can't remove them... from either library. >> > I guess I wasn't clear enough - the Catalyst does provide a bunch of > symbols more than mesa. Some of which I assume (although haven't > checked) are part of the GLES* api. There is something funny especially > since the same library provides eglGetProcAddress. > > There are some (rather strange) suggestions on the web that the library > can be used as a libEGL/libGLES* replacement. > > Thus I aimed my earlier comment as - there is not point for mesa to > attempt to provide all the functions listed by the Catalyst. Ah, okay. There is a quite large pile of functions that Catalyst exposes that Mesa does not (like glAddSwapHintRectWIN and glBeginVertexShaderEXT), but I didn't notice any that looked like GLES functions. *shrug* > Hope ^^ came out less patronising than usual :-) > > Cheers, > Emil > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 44/57] mesa: Add ARB_direct_state_access checks in XFB functions
On 05/14/2015 12:51 PM, Ilia Mirkin wrote:
> Don't you have to add the checks either way? And should these have just been
>
> if (ctx->API != CORE && (ctx->API != COMPAT || ctx->Version < 20)) {
> ...
> }
>
> And removing compat will just reduce these checks to
>
> if (ctx->API != CORE)
>
> ?
No. If you decorate the functions properly in the XML, the would never
even get put in the dispatch table for a non-core context. That's the
whole point.
> Cheers,
>
> -ilia
>
> On Thu, May 14, 2015 at 2:55 PM, Ian Romanick wrote:
>> I am not a fan of adding a million extra extension checks. I understand
>> that we can't enable the extension universally due to the OpenGL 2.0
>> requirement. Add this to the list of arguments for making this
>> extension exclusive to core profile... which I have been saying since
>> before a single line of DSA code was written. :(
>>
>> If that means I have to go and re-write all the piglit tests, fine.
>>
>> On 05/11/2015 10:27 AM, Fredrik Höglund wrote:
>>> Signed-off-by: Fredrik Höglund
>>> ---
>>> src/mesa/main/transformfeedback.c | 42
>>> +++
>>> 1 file changed, 42 insertions(+)
>>>
>>> diff --git a/src/mesa/main/transformfeedback.c
>>> b/src/mesa/main/transformfeedback.c
>>> index 103011c..642fa96 100644
>>> --- a/src/mesa/main/transformfeedback.c
>>> +++ b/src/mesa/main/transformfeedback.c
>>> @@ -706,6 +706,13 @@ _mesa_TransformFeedbackBufferBase(GLuint xfb, GLuint
>>> index, GLuint buffer)
>>> struct gl_transform_feedback_object *obj;
>>> struct gl_buffer_object *bufObj;
>>>
>>> + if (!ctx->Extensions.ARB_direct_state_access) {
>>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>>> +
>>> "glTransformFeedbackBufferBase(GL_ARB_direct_state_access "
>>> + "is not supported)");
>>> + return;
>>> + }
>>> +
>>> obj = lookup_transform_feedback_object_err(ctx, xfb,
>>>
>>> "glTransformFeedbackBufferBase");
>>> if(!obj) {
>>> @@ -729,6 +736,13 @@ _mesa_TransformFeedbackBufferRange(GLuint xfb, GLuint
>>> index, GLuint buffer,
>>> struct gl_transform_feedback_object *obj;
>>> struct gl_buffer_object *bufObj;
>>>
>>> + if (!ctx->Extensions.ARB_direct_state_access) {
>>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>>> +
>>> "glTransformFeedbackBufferRange(GL_ARB_direct_state_access "
>>> + "is not supported)");
>>> + return;
>>> + }
>>> +
>>> obj = lookup_transform_feedback_object_err(ctx, xfb,
>>>
>>> "glTransformFeedbackBufferRange");
>>> if(!obj) {
>>> @@ -1045,6 +1059,13 @@ _mesa_CreateTransformFeedbacks(GLsizei n, GLuint
>>> *names)
>>> {
>>> GET_CURRENT_CONTEXT(ctx);
>>>
>>> + if (!ctx->Extensions.ARB_direct_state_access) {
>>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>>> + "glCreateTransformFeedbacks(GL_ARB_direct_state_access "
>>> + "is not supported)");
>>> + return;
>>> + }
>>> +
>>> create_transform_feedbacks(ctx, n, names, true);
>>> }
>>>
>>> @@ -1215,6 +1236,13 @@ _mesa_GetTransformFeedbackiv(GLuint xfb, GLenum
>>> pname, GLint *param)
>>> struct gl_transform_feedback_object *obj;
>>> GET_CURRENT_CONTEXT(ctx);
>>>
>>> +if (!ctx->Extensions.ARB_direct_state_access) {
>>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>>> + "glGetTransformFeedbackiv(GL_ARB_direct_state_access "
>>> + "is not supported)");
>>> + return;
>>> +}
>>> +
>>> obj = lookup_transform_feedback_object_err(ctx, xfb,
>>> "glGetTransformFeedbackiv");
>>> if(!obj) {
>>> @@ -1241,6 +1269,13 @@ _mesa_GetTransformFeedbacki_v(GLuint xfb, GLenum
>>> pname, GLuint index,
>>> struct gl_transform_feedback_object *obj;
>>> GET_CURRENT_CONTEXT(ctx);
>>>
>>> + if (!ctx->Extensions.ARB_direct_state_access) {
>>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>>> + "glGetTransformFeedbacki_v(GL_ARB_direct_state_access "
>>> + "is not supported)");
>>> + return;
>>> + }
>>> +
>>> obj = lookup_transform_feedback_object_err(ctx, xfb,
>>>"glGetTransformFeedbacki_v");
>>> if(!obj) {
>>> @@ -1270,6 +1305,13 @@ _mesa_GetTransformFeedbacki64_v(GLuint xfb, GLenum
>>> pname, GLuint index,
>>> struct gl_transform_feedback_object *obj;
>>> GET_CURRENT_CONTEXT(ctx);
>>>
>>> + if (!ctx->Extensions.ARB_direct_state_access) {
>>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>>> + "glGetTransformFeedbacki64_v(GL_ARB_direct_state_access "
>>> + "is not supported)");
>>> + return;
>>> + }
>>> +
>>> obj = lookup_transform_feedback_object_err(ctx, xfb,
>>>
>>> "glGetTransformFeedbacki64_v
Re: [Mesa-dev] [PATCH] st/mesa: Flush the bitmap cache in st_BlitFramebuffer
On 05/15/2015 12:10 PM, Fredrik Höglund wrote: With DSA we can no longer rely on this being done in st_validate_state in response to the framebuffer bindings having changed. This fixes the ext_framebuffer_multisample-bitmap piglit test. --- src/mesa/state_tracker/st_cb_blit.c | 4 1 file changed, 4 insertions(+) diff --git a/src/mesa/state_tracker/st_cb_blit.c b/src/mesa/state_tracker/st_cb_blit.c index bbaedd1..75289ae 100644 --- a/src/mesa/state_tracker/st_cb_blit.c +++ b/src/mesa/state_tracker/st_cb_blit.c @@ -36,6 +36,7 @@ #include "st_context.h" #include "st_texture.h" +#include "st_cb_bitmap.h" #include "st_cb_blit.h" #include "st_cb_fbo.h" #include "st_atom.h" @@ -93,6 +94,9 @@ st_BlitFramebuffer(struct gl_context *ctx, st_validate_state(st); + /* Make sure bitmap rendering has landed in the read framebuffer */ Or the draw framebuffer, right? + st_flush_bitmap_cache(st); + clip.srcX0 = srcX0; clip.srcY0 = srcY0; clip.srcX1 = srcX1; Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/20] glapi yak shaving and GLES 3.1 enabling
On 05/14/2015 03:01 PM, Emil Velikov wrote: > Hi Ian, > > On 13/05/15 19:44, Ian Romanick wrote: >> We've known for a long time that having all those tags in the >> entries in the XML is bad. For example, people cut-and-paste for >> everything, and, as a result, we export a bunch of functions that we >> should not. We also really want to just use the Khronos XML. >> >> This series takes a couple small steps towards that. >> >> Patches 1 and 2 are just a couple of clean-ups to prevent regressions in >> later patches. >> >> Patches 3, 13, 14, 15, 16, and 17 remove the offset= tags from the XML. >> Patch 15 was quite large, so it was trimmed. >> >> Patches 4, 5, and 6 remove the static_dispatch= tags from the XML. >> Patch 5 was quite large, so it was trimmed. >> >> Patches 7 through 12 un-export a bunch of static dispatch functions. At >> the end, we only export the functions that Mesa 10.3 and NVIDIA and AMD >> export (with a couple minor exceptions noted in patches 8 and 11. >> > What are your thoughts on having patches 01-17 for 10.6 ? I would > _really_ love if they make it, plus I'm open on picking them after the > branch point. I'd prefer to land the whole lot, but I'll take what I can get. :) > Other than the comment in patch 02 I did not spot anything wrong with > the yak. Admittedly I did stay away from the mapi magic for quite some time. With the changes to the commit message of patch 2, is that a R-b on the series? > Thanks > Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 44/57] mesa: Add ARB_direct_state_access checks in XFB functions
On Fri, May 15, 2015 at 2:29 PM, Ian Romanick wrote:
> On 05/14/2015 12:51 PM, Ilia Mirkin wrote:
>> Don't you have to add the checks either way? And should these have just been
>>
>> if (ctx->API != CORE && (ctx->API != COMPAT || ctx->Version < 20)) {
>> ...
>> }
>>
>> And removing compat will just reduce these checks to
>>
>> if (ctx->API != CORE)
>>
>> ?
>
> No. If you decorate the functions properly in the XML, the would never
> even get put in the dispatch table for a non-core context. That's the
> whole point.
Would you mind elaborating on how to do that? I see es1/es2/desktop
attributes in the DTD, and it appears that desktop + deprecated ==
COMPAT. But nothing to make it core-only.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/12] android: make the code be compatible with stlport
The android's stlport doesn't have tr1/unordered_set but unordered_set. Signed-off-by: Chih-Wei Huang --- src/egl/main/Android.mk | 5 +++-- src/gallium/drivers/nouveau/codegen/nv50_ir.h | 5 + 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/src/egl/main/Android.mk b/src/egl/main/Android.mk index 12b66d0..29c978b 100644 --- a/src/egl/main/Android.mk +++ b/src/egl/main/Android.mk @@ -100,7 +100,6 @@ endif ifneq ($(filter nouveau, $(MESA_GPU_DRIVERS)),) gallium_DRIVERS += libmesa_winsys_nouveau libmesa_pipe_nouveau LOCAL_SHARED_LIBRARIES += libdrm_nouveau -LOCAL_SHARED_LIBRARIES += libstlport endif # r300g/r600g/radeonsi @@ -113,7 +112,6 @@ endif # r300g ifneq ($(filter r600g radeonsi, $(MESA_GPU_DRIVERS)),) ifneq ($(filter r600g, $(MESA_GPU_DRIVERS)),) gallium_DRIVERS += libmesa_pipe_r600 -LOCAL_SHARED_LIBRARIES += libstlport endif # r600g ifneq ($(filter radeonsi, $(MESA_GPU_DRIVERS)),) gallium_DRIVERS += libmesa_pipe_radeonsi @@ -121,6 +119,9 @@ endif # radeonsi gallium_DRIVERS += libmesa_pipe_radeon endif # r600g || radeonsi endif # r300g || r600g || radeonsi +ifneq ($(filter nouveau r600g, $(MESA_GPU_DRIVERS)),) +LOCAL_SHARED_LIBRARIES += libstlport +endif # vmwgfx ifneq ($(filter vmwgfx, $(MESA_GPU_DRIVERS)),) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h b/src/gallium/drivers/nouveau/codegen/nv50_ir.h index f4d52b7..6a17e61 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h @@ -29,7 +29,12 @@ #include #include #include +#ifdef ANDROID +#include // from stlport +using std::isfinite; +#else #include +#endif #include "codegen/nv50_ir_util.h" #include "codegen/nv50_ir_graph.h" -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/12] android: add rules to build gallium_dri
Signed-off-by: Chih-Wei Huang --- src/gallium/Android.mk | 7 +- src/gallium/targets/dri/Android.mk | 110 +++ src/gallium/winsys/sw/dri/Android.mk | 35 ++ src/gallium/winsys/sw/kms-dri/Android.mk | 37 +++ 4 files changed, 187 insertions(+), 2 deletions(-) create mode 100644 src/gallium/targets/dri/Android.mk create mode 100644 src/gallium/winsys/sw/dri/Android.mk create mode 100644 src/gallium/winsys/sw/kms-dri/Android.mk diff --git a/src/gallium/Android.mk b/src/gallium/Android.mk index aaa07bc..a9c34d9 100644 --- a/src/gallium/Android.mk +++ b/src/gallium/Android.mk @@ -33,7 +33,9 @@ SUBDIRS := auxiliary # # swrast -SUBDIRS += winsys/sw/android drivers/softpipe +ifneq ($(filter swrast,$(MESA_GPU_DRIVERS)),) +SUBDIRS += winsys/sw/dri winsys/sw/kms-dri drivers/softpipe +endif # freedreno ifneq ($(filter freedreno, $(MESA_GPU_DRIVERS)),) @@ -79,6 +81,7 @@ ifneq ($(filter vmwgfx, $(MESA_GPU_DRIVERS)),) SUBDIRS += winsys/svga/drm drivers/svga endif -SUBDIRS += state_trackers/dri +# Gallium state trackers and target for dri +SUBDIRS += state_trackers/dri targets/dri include $(call all-named-subdir-makefiles,$(SUBDIRS)) diff --git a/src/gallium/targets/dri/Android.mk b/src/gallium/targets/dri/Android.mk new file mode 100644 index 000..7c7642f --- /dev/null +++ b/src/gallium/targets/dri/Android.mk @@ -0,0 +1,110 @@ +# Mesa 3-D graphics library +# +# Copyright (C) 2015 Chih-Wei Huang +# Copyright (C) 2015 Android-x86 Open Source Project +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice shall be included +# in all copies or substantial portions of the Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. + +LOCAL_PATH := $(call my-dir) + +include $(CLEAR_VARS) + +LOCAL_MODULE := gallium_dri + +ifeq ($(MESA_LOLLIPOP_BUILD),true) +LOCAL_MODULE_RELATIVE_PATH := $(notdir $(MESA_DRI_MODULE_PATH)) +else +LOCAL_MODULE_PATH := $(MESA_DRI_MODULE_PATH) +endif + +LOCAL_SRC_FILES := target.c + +LOCAL_CFLAGS := -DDRI_TARGET -DHAVE_LIBDRM + +LOCAL_SHARED_LIBRARIES := \ + libdl \ + libglapi \ + libexpat \ + +# swrast only? +ifeq ($(MESA_GPU_DRIVERS),swrast) +LOCAL_CFLAGS += -D__NOT_HAVE_DRM_H +else +LOCAL_SHARED_LIBRARIES += libdrm +endif + +ifneq ($(filter freedreno,$(MESA_GPU_DRIVERS)),) +LOCAL_CFLAGS += -DGALLIUM_FREEDRENO +gallium_DRIVERS += libmesa_winsys_freedreno libmesa_pipe_freedreno +LOCAL_SHARED_LIBRARIES += libdrm_freedreno +endif +ifneq ($(filter i915g,$(MESA_GPU_DRIVERS)),) +gallium_DRIVERS += libmesa_winsys_i915 libmesa_pipe_i915 +LOCAL_SHARED_LIBRARIES += libdrm_intel +LOCAL_CFLAGS += -DGALLIUM_I915 +endif +ifneq ($(filter ilo,$(MESA_GPU_DRIVERS)),) +gallium_DRIVERS += libmesa_winsys_intel libmesa_pipe_ilo +LOCAL_SHARED_LIBRARIES += libdrm_intel +LOCAL_CFLAGS += -DGALLIUM_ILO +endif +ifneq ($(filter nouveau,$(MESA_GPU_DRIVERS)),) +gallium_DRIVERS += libmesa_winsys_nouveau libmesa_pipe_nouveau +LOCAL_CFLAGS += -DGALLIUM_NOUVEAU +LOCAL_SHARED_LIBRARIES += libdrm_nouveau libstlport +endif +ifneq ($(filter r%,$(MESA_GPU_DRIVERS)),) +ifneq ($(filter r300g,$(MESA_GPU_DRIVERS)),) +gallium_DRIVERS += libmesa_pipe_r300 +LOCAL_CFLAGS += -DGALLIUM_R300 +endif +ifneq ($(filter r600g,$(MESA_GPU_DRIVERS)),) +gallium_DRIVERS += libmesa_pipe_r600 +LOCAL_SHARED_LIBRARIES += libstlport +LOCAL_CFLAGS += -DGALLIUM_R600 +endif +ifneq ($(filter radeonsi,$(MESA_GPU_DRIVERS)),) +gallium_DRIVERS += libmesa_pipe_radeonsi +LOCAL_CFLAGS += -DGALLIUM_RADEONSI +endif +gallium_DRIVERS += libmesa_winsys_radeon libmesa_pipe_radeon +LOCAL_SHARED_LIBRARIES += libdrm_radeon +endif +ifneq ($(filter swrast,$(MESA_GPU_DRIVERS)),) +gallium_DRIVERS += libmesa_pipe_softpipe libmesa_winsys_sw_dri libmesa_winsys_sw_kms_dri +LOCAL_CFLAGS += -DGALLIUM_SOFTPIPE +endif +ifneq ($(filter vmwgfx,$(MESA_GPU_DRIVERS)),) +gallium_DRIVERS += libmesa_winsys_svga libmesa_pipe_svga +LOCAL_CFLAGS += -DGALLIUM_VMWGFX +endif + +LOCAL_STATIC_LIBRARIES := \ + $(gallium_DRIVERS) \ + libmesa_st_dri \ + libmesa_st_mesa \ + libmesa_glsl \ +
[Mesa-dev] [PATCH 01/12] nv50/ir: optimize the use of std::tr1::unordered_set
Instead of using unordered_set directly, the patch
changes to use unordered_set and adds a wrapper template class
to convert the iterators to the expected user-defined type.
This avoid instantiating the template multiple times and make it be
more compatible with stlport.
Signed-off-by: Chih-Wei Huang
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 28 +++---
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 4 ++--
.../nouveau/codegen/nv50_ir_lowering_nvc0.h| 4 +---
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 5 ++--
4 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index 529dcb9..f4d52b7 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -451,6 +451,28 @@ struct Storage
#define NV50_IR_INTERP_OFFSET (2 << 2)
#define NV50_IR_INTERP_SAMPLEID(3 << 2)
+typedef std::tr1::unordered_set voidptr_unordered_set;
+
+template
+class ptr_unordered_set : public voidptr_unordered_set {
+ public:
+typedef voidptr_unordered_set _base;
+typedef _base::iterator _biterator;
+
+class iterator : public _biterator {
+ public:
+iterator(const _biterator & i) : _biterator(i) {}
+V *operator*() { return reinterpret_cast(*_biterator(*this)); }
+const V *operator*() const { return reinterpret_cast(*_biterator(*this)); }
+};
+typedef const iterator const_iterator;
+
+iterator begin() { return _base::begin(); }
+iterator end() { return _base::end(); }
+const_iterator begin() const { return _base::begin(); }
+const_iterator end() const { return _base::end(); }
+};
+
// do we really want this to be a class ?
class Modifier
{
@@ -583,10 +605,10 @@ public:
static inline Value *get(Iterator&);
- std::tr1::unordered_set uses;
+ ptr_unordered_set uses;
std::list defs;
- typedef std::tr1::unordered_set::iterator UseIterator;
- typedef std::tr1::unordered_set::const_iterator UseCIterator;
+ typedef ptr_unordered_set::iterator UseIterator;
+ typedef ptr_unordered_set::const_iterator UseCIterator;
typedef std::list::iterator DefIterator;
typedef std::list::const_iterator DefCIterator;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index b61f3c4..669d292 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -224,7 +224,7 @@ NVC0LegalizePostRA::findFirstUses(
const Instruction *texi,
const Instruction *insn,
std::list &uses,
- std::tr1::unordered_set& visited)
+ ptr_unordered_set& visited)
{
for (int d = 0; insn->defExists(d); ++d) {
Value *v = insn->getDef(d);
@@ -318,7 +318,7 @@ NVC0LegalizePostRA::insertTextureBarriers(Function *fn)
if (!uses)
return false;
for (size_t i = 0; i < texes.size(); ++i) {
- std::tr1::unordered_set visited;
+ ptr_unordered_set visited;
findFirstUses(texes[i], texes[i], uses[i], visited);
}
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
index 260e101..17b6f6f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
@@ -20,8 +20,6 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include
-
#include "codegen/nv50_ir.h"
#include "codegen/nv50_ir_build_util.h"
@@ -73,7 +71,7 @@ private:
inline bool insnDominatedBy(const Instruction *, const Instruction *) const;
void findFirstUses(const Instruction *tex, const Instruction *def,
std::list&,
- std::tr1::unordered_set&);
+ ptr_unordered_set&);
void findOverwritingDefs(const Instruction *tex, Instruction *insn,
const BasicBlock *term,
std::list&);
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 898653c..03acba7 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -25,7 +25,6 @@
#include
#include
-#include
namespace nv50_ir {
@@ -1551,7 +1550,7 @@ SpillCodeInserter::run(const std::list& lst)
// Keep track of which instructions to delete later. Deleting them
// inside the loop is unsafe since a single instruction may have
// multiple destinations that all need to be spilled (like OP_SPLIT).
- std::tr1::unordered_set to_del;
+ ptr_unordered_set to_del;
for (Value::DefIterator d = lval->defs.begin(); d != lval->defs.end();
++d) {
@@ -1593,7 +1592,7 @@ SpillCodeInserter::ru
[Mesa-dev] [PATCH 04/12] android: export more dirs from libmesa_dri_common
The include paths of libmesa_dri_common are also used by modules that need libmesa_dri_common. Signed-off-by: Chih-Wei Huang --- src/mesa/drivers/dri/common/Android.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/common/Android.mk b/src/mesa/drivers/dri/common/Android.mk index a7fcd6d..c003c94 100644 --- a/src/mesa/drivers/dri/common/Android.mk +++ b/src/mesa/drivers/dri/common/Android.mk @@ -39,7 +39,9 @@ intermediates := $(call local-generated-sources-dir) LOCAL_C_INCLUDES := \ $(MESA_DRI_C_INCLUDES) -LOCAL_EXPORT_C_INCLUDE_DIRS := $(intermediates) +LOCAL_EXPORT_C_INCLUDE_DIRS := \ +$(LOCAL_PATH) \ +$(intermediates) # swrast only ifeq ($(MESA_GPU_DRIVERS),swrast) -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/12] android: enable the rules to build gallium st/dri
The libmesa_dri_common and libmesa_egl_dri2 should not be limited to the classical drivers only. Allow them to be built with the gallium drivers. Signed-off-by: Chih-Wei Huang --- Android.mk | 6 +- src/egl/main/Android.mk | 8 ++-- 2 files changed, 3 insertions(+), 11 deletions(-) diff --git a/Android.mk b/Android.mk index b19419b..6a09a9d 100644 --- a/Android.mk +++ b/Android.mk @@ -89,13 +89,9 @@ SUBDIRS := \ src/glsl \ src/mesa \ src/util \ - src/egl/main - -ifeq ($(strip $(MESA_BUILD_CLASSIC)),true) -SUBDIRS += \ + src/egl/main \ src/egl/drivers/dri2 \ src/mesa/drivers/dri -endif ifeq ($(strip $(MESA_BUILD_GALLIUM)),true) SUBDIRS += src/gallium diff --git a/src/egl/main/Android.mk b/src/egl/main/Android.mk index 29c978b..611034c 100644 --- a/src/egl/main/Android.mk +++ b/src/egl/main/Android.mk @@ -62,10 +62,10 @@ ifneq ($(MESA_GPU_DRIVERS),swrast) LOCAL_SHARED_LIBRARIES += libdrm endif -ifeq ($(strip $(MESA_BUILD_CLASSIC)),true) LOCAL_CFLAGS += -D_EGL_BUILT_IN_DRIVER_DRI2 LOCAL_STATIC_LIBRARIES += libmesa_egl_dri2 +ifeq ($(strip $(MESA_BUILD_CLASSIC)),true) # require i915_dri and/or i965_dri LOCAL_REQUIRED_MODULES += \ $(addsuffix _dri, $(filter i915 i965, $(MESA_GPU_DRIVERS))) @@ -75,9 +75,6 @@ ifeq ($(strip $(MESA_BUILD_GALLIUM)),true) gallium_DRIVERS := -# swrast -gallium_DRIVERS += libmesa_pipe_softpipe libmesa_winsys_sw_android - # freedreno ifneq ($(filter freedreno, $(MESA_GPU_DRIVERS)),) gallium_DRIVERS += libmesa_winsys_freedreno libmesa_pipe_freedreno @@ -138,8 +135,6 @@ endif # * libmesa_glsl depends on libmesa_glsl_utils # LOCAL_STATIC_LIBRARIES := \ - libmesa_egl_gallium \ - libmesa_st_egl \ $(gallium_DRIVERS) \ libmesa_st_mesa \ libmesa_util \ @@ -148,6 +143,7 @@ LOCAL_STATIC_LIBRARIES := \ libmesa_gallium \ $(LOCAL_STATIC_LIBRARIES) +LOCAL_REQUIRED_MODULES += gallium_dri endif # MESA_BUILD_GALLIUM LOCAL_STATIC_LIBRARIES := \ -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/12] egl/main: let EGL_RECORDABLE_ANDROID be a valid attrib
Signed-off-by: Chih-Wei Huang --- src/egl/main/eglconfig.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/egl/main/eglconfig.h b/src/egl/main/eglconfig.h index 84cb227..7121b3d 100644 --- a/src/egl/main/eglconfig.h +++ b/src/egl/main/eglconfig.h @@ -86,6 +86,7 @@ struct _egl_config /* extensions */ EGLint YInvertedNOK; + EGLint RecordableAndroid; }; @@ -133,6 +134,7 @@ _eglOffsetOfConfig(EGLint attr) ATTRIB_MAP(EGL_CONFORMANT,Conformant); /* extensions */ ATTRIB_MAP(EGL_Y_INVERTED_NOK,YInvertedNOK); + ATTRIB_MAP(EGL_RECORDABLE_ANDROID,RecordableAndroid); #undef ATTRIB_MAP default: return -1; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/12] More Android patches
This is another series of patches for Android. Summary of the changes: * Fix nouveau driver build with Android stlport. * Add gallium_dri.so for Android. This fixes gallium support since 5564c36. * Enable radeonsi driver for Android. * Miscellaneous fixes. Chih-Wei Huang (12): nv50/ir: optimize the use of std::tr1::unordered_set android: make the code be compatible with stlport android: loader: export the path to be included android: export more dirs from libmesa_dri_common android: add rules to build gallium/state_trackers/dri android: add rules to build gallium_dri android: enable the rules to build gallium st/dri android: clean up the makefile of libGLES_mesa egl/main: let EGL_RECORDABLE_ANDROID be a valid attrib android: fix building errors with stlport android: generate files by $(call es-gen) android: enable the radeonsi driver Android.common.mk | 8 ++ Android.mk | 8 +- src/egl/drivers/dri2/Android.mk| 1 - src/egl/main/Android.mk| 86 +-- src/egl/main/eglconfig.h | 2 + src/gallium/Android.common.mk | 8 ++ src/gallium/Android.mk | 10 +- src/gallium/auxiliary/Android.mk | 8 ++ src/gallium/drivers/nouveau/codegen/nv50_ir.h | 33 +- .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 4 +- .../nouveau/codegen/nv50_ir_lowering_nvc0.h| 4 +- src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 5 +- src/gallium/drivers/radeon/Android.mk | 4 + src/gallium/state_trackers/dri/Android.mk | 64 +++ src/gallium/targets/dri/Android.mk | 120 + src/gallium/winsys/sw/dri/Android.mk | 35 ++ src/gallium/winsys/sw/kms-dri/Android.mk | 37 +++ src/loader/Android.mk | 2 + src/mesa/Android.gen.mk| 16 ++- src/mesa/drivers/dri/common/Android.mk | 4 +- src/util/list.h| 4 + 21 files changed, 356 insertions(+), 107 deletions(-) create mode 100644 src/gallium/state_trackers/dri/Android.mk create mode 100644 src/gallium/targets/dri/Android.mk create mode 100644 src/gallium/winsys/sw/dri/Android.mk create mode 100644 src/gallium/winsys/sw/kms-dri/Android.mk -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/12] android: add rules to build gallium/state_trackers/dri
Signed-off-by: Chih-Wei Huang --- src/gallium/Android.mk| 5 ++- src/gallium/state_trackers/dri/Android.mk | 64 +++ 2 files changed, 67 insertions(+), 2 deletions(-) create mode 100644 src/gallium/state_trackers/dri/Android.mk diff --git a/src/gallium/Android.mk b/src/gallium/Android.mk index b2662ff..aaa07bc 100644 --- a/src/gallium/Android.mk +++ b/src/gallium/Android.mk @@ -79,5 +79,6 @@ ifneq ($(filter vmwgfx, $(MESA_GPU_DRIVERS)),) SUBDIRS += winsys/svga/drm drivers/svga endif -mkfiles := $(patsubst %,$(GALLIUM_TOP)/%/Android.mk,$(SUBDIRS)) -include $(mkfiles) +SUBDIRS += state_trackers/dri + +include $(call all-named-subdir-makefiles,$(SUBDIRS)) diff --git a/src/gallium/state_trackers/dri/Android.mk b/src/gallium/state_trackers/dri/Android.mk new file mode 100644 index 000..188e4a1 --- /dev/null +++ b/src/gallium/state_trackers/dri/Android.mk @@ -0,0 +1,64 @@ +# Mesa 3-D graphics library +# +# Copyright (C) 2015 Chih-Wei Huang +# Copyright (C) 2015 Android-x86 Open Source Project +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice shall be included +# in all copies or substantial portions of the Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. + +LOCAL_PATH := $(call my-dir) + +include $(LOCAL_PATH)/Makefile.sources + +include $(CLEAR_VARS) + +LOCAL_SRC_FILES := $(common_SOURCES) + +LOCAL_CFLAGS := \ + -DGALLIUM_STATIC_TARGETS=1 \ + +LOCAL_C_INCLUDES := \ + $(MESA_TOP)/src/mapi \ + $(MESA_TOP)/src/mesa \ + +LOCAL_EXPORT_C_INCLUDE_DIRS := \ + $(LOCAL_PATH) \ + $(LOCAL_C_INCLUDES) \ + +LOCAL_STATIC_LIBRARIES := \ + libmesa_dri_common \ + +ifneq ($(filter swrast,$(MESA_GPU_DRIVERS)),) +LOCAL_CFLAGS += -DGALLIUM_SOFTPIPE +LOCAL_SRC_FILES += $(drisw_SOURCES) +endif + +# swrast only? +ifeq ($(MESA_GPU_DRIVERS),swrast) +LOCAL_CFLAGS += -D__NOT_HAVE_DRM_H +else +LOCAL_SRC_FILES += $(dri2_SOURCES) +LOCAL_SHARED_LIBRARIES := libdrm +endif + +LOCAL_MODULE := libmesa_st_dri + +LOCAL_GENERATED_SOURCES := $(MESA_DRI_OPTIONS_H) + +include $(GALLIUM_COMMON_MK) +include $(BUILD_STATIC_LIBRARY) -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/12] android: enable the radeonsi driver
Based on the nice work of Paulo Sergio Travaglia . The main modifications are: - Include paths for LLVM header files and shared/static libraries - Set C++ flag "c++11" to avoid compiling errors on LLVM header files - Set defines for LLVM - Add GALLIVM source files - Changes path of libelf library for lollipop Signed-off-by: Chih-Wei Huang --- Android.common.mk | 8 Android.mk| 2 ++ src/gallium/Android.common.mk | 8 src/gallium/auxiliary/Android.mk | 8 src/gallium/drivers/radeon/Android.mk | 4 src/gallium/targets/dri/Android.mk| 10 ++ 6 files changed, 40 insertions(+) diff --git a/Android.common.mk b/Android.common.mk index edf52d6..43766bf 100644 --- a/Android.common.mk +++ b/Android.common.mk @@ -68,6 +68,14 @@ LOCAL_CFLAGS += \ endif endif +ifeq ($(MESA_ENABLE_LLVM),true) +LOCAL_CFLAGS += \ + -DHAVE_LLVM=0x0305 -DLLVM_VERSION_PATCH=2 \ + -D__STDC_CONSTANT_MACROS \ + -D__STDC_FORMAT_MACROS \ + -D__STDC_LIMIT_MACROS +endif + LOCAL_CPPFLAGS += \ -Wno-error=non-virtual-dtor \ -Wno-non-virtual-dtor diff --git a/Android.mk b/Android.mk index 6a09a9d..64930ac 100644 --- a/Android.mk +++ b/Android.mk @@ -80,6 +80,8 @@ else MESA_BUILD_GALLIUM := false endif +MESA_ENABLE_LLVM := $(if $(filter radeonsi,$(gallium_drivers)),true,false) + # add subdirectories ifneq ($(strip $(MESA_GPU_DRIVERS)),) diff --git a/src/gallium/Android.common.mk b/src/gallium/Android.common.mk index 782510f..7c6c7ac 100644 --- a/src/gallium/Android.common.mk +++ b/src/gallium/Android.common.mk @@ -29,4 +29,12 @@ LOCAL_C_INCLUDES += \ $(GALLIUM_TOP)/winsys \ $(GALLIUM_TOP)/drivers +ifeq ($(MESA_ENABLE_LLVM),true) +LOCAL_C_INCLUDES += \ + external/llvm/include \ + external/llvm/device/include \ + external/libcxx/include \ + external/elfutils/$(if $(filter true,$(MESA_LOLLIPOP_BUILD)),0.153/)libelf +endif + include $(MESA_COMMON_MK) diff --git a/src/gallium/auxiliary/Android.mk b/src/gallium/auxiliary/Android.mk index 96a2125..2d91752 100644 --- a/src/gallium/auxiliary/Android.mk +++ b/src/gallium/auxiliary/Android.mk @@ -35,6 +35,14 @@ LOCAL_SRC_FILES := \ LOCAL_C_INCLUDES := \ $(GALLIUM_TOP)/auxiliary/util +ifeq ($(MESA_ENABLE_LLVM),true) +LOCAL_SRC_FILES += \ + $(GALLIVM_SOURCES) \ + $(GALLIVM_CPP_SOURCES) + +LOCAL_CPPFLAGS := -std=c++11 +endif + LOCAL_MODULE := libmesa_gallium # generate sources diff --git a/src/gallium/drivers/radeon/Android.mk b/src/gallium/drivers/radeon/Android.mk index d615792..6997a6d 100644 --- a/src/gallium/drivers/radeon/Android.mk +++ b/src/gallium/drivers/radeon/Android.mk @@ -30,6 +30,10 @@ include $(CLEAR_VARS) LOCAL_SRC_FILES := $(C_SOURCES) +ifeq ($(MESA_ENABLE_LLVM),true) +LOCAL_SRC_FILES += $(LLVM_C_FILES) +endif + LOCAL_SHARED_LIBRARIES := libdrm libdrm_radeon LOCAL_MODULE := libmesa_pipe_radeon diff --git a/src/gallium/targets/dri/Android.mk b/src/gallium/targets/dri/Android.mk index 7c7642f..e9b9ac4 100644 --- a/src/gallium/targets/dri/Android.mk +++ b/src/gallium/targets/dri/Android.mk @@ -81,6 +81,7 @@ LOCAL_CFLAGS += -DGALLIUM_R600 endif ifneq ($(filter radeonsi,$(MESA_GPU_DRIVERS)),) gallium_DRIVERS += libmesa_pipe_radeonsi +LOCAL_SHARED_LIBRARIES += libLLVM LOCAL_CFLAGS += -DGALLIUM_RADEONSI endif gallium_DRIVERS += libmesa_winsys_radeon libmesa_pipe_radeon @@ -106,5 +107,14 @@ LOCAL_STATIC_LIBRARIES := \ libmesa_util \ libmesa_loader \ +ifeq ($(MESA_ENABLE_LLVM),true) +LOCAL_STATIC_LIBRARIES += \ + libLLVMR600CodeGen \ + libLLVMR600Desc \ + libLLVMR600Info \ + libLLVMR600AsmPrinter \ + libelf +endif + include $(GALLIUM_COMMON_MK) include $(BUILD_SHARED_LIBRARY) -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/12] android: clean up the makefile of libGLES_mesa
Most of the logic for the gallium drivers has been moved to src/gallium/targets/dri/Android.mk. Signed-off-by: Chih-Wei Huang --- src/egl/main/Android.mk | 79 ++--- 1 file changed, 2 insertions(+), 77 deletions(-) diff --git a/src/egl/main/Android.mk b/src/egl/main/Android.mk index 611034c..60de211 100644 --- a/src/egl/main/Android.mk +++ b/src/egl/main/Android.mk @@ -43,8 +43,6 @@ LOCAL_CFLAGS := \ -D_EGL_DRIVER_SEARCH_DIR=\"/system/lib/egl\" \ -D_EGL_OS_UNIX=1 -LOCAL_STATIC_LIBRARIES := - LOCAL_SHARED_LIBRARIES := \ libglapi \ libdl \ @@ -63,7 +61,7 @@ LOCAL_SHARED_LIBRARIES += libdrm endif LOCAL_CFLAGS += -D_EGL_BUILT_IN_DRIVER_DRI2 -LOCAL_STATIC_LIBRARIES += libmesa_egl_dri2 +LOCAL_STATIC_LIBRARIES := libmesa_egl_dri2 ifeq ($(strip $(MESA_BUILD_CLASSIC)),true) # require i915_dri and/or i965_dri @@ -72,83 +70,10 @@ LOCAL_REQUIRED_MODULES += \ endif # MESA_BUILD_CLASSIC ifeq ($(strip $(MESA_BUILD_GALLIUM)),true) - -gallium_DRIVERS := - -# freedreno -ifneq ($(filter freedreno, $(MESA_GPU_DRIVERS)),) -gallium_DRIVERS += libmesa_winsys_freedreno libmesa_pipe_freedreno -LOCAL_SHARED_LIBRARIES += libdrm_freedreno -endif - -# i915g -ifneq ($(filter i915g, $(MESA_GPU_DRIVERS)),) -gallium_DRIVERS += libmesa_winsys_i915 libmesa_pipe_i915 -LOCAL_SHARED_LIBRARIES += libdrm_intel -endif - -# ilo -ifneq ($(filter ilo, $(MESA_GPU_DRIVERS)),) -gallium_DRIVERS += libmesa_winsys_intel libmesa_pipe_ilo -LOCAL_SHARED_LIBRARIES += libdrm_intel -endif - -# nouveau -ifneq ($(filter nouveau, $(MESA_GPU_DRIVERS)),) -gallium_DRIVERS += libmesa_winsys_nouveau libmesa_pipe_nouveau -LOCAL_SHARED_LIBRARIES += libdrm_nouveau -endif - -# r300g/r600g/radeonsi -ifneq ($(filter r300g r600g radeonsi, $(MESA_GPU_DRIVERS)),) -gallium_DRIVERS += libmesa_winsys_radeon -LOCAL_SHARED_LIBRARIES += libdrm_radeon -ifneq ($(filter r300g, $(MESA_GPU_DRIVERS)),) -gallium_DRIVERS += libmesa_pipe_r300 -endif # r300g -ifneq ($(filter r600g radeonsi, $(MESA_GPU_DRIVERS)),) -ifneq ($(filter r600g, $(MESA_GPU_DRIVERS)),) -gallium_DRIVERS += libmesa_pipe_r600 -endif # r600g -ifneq ($(filter radeonsi, $(MESA_GPU_DRIVERS)),) -gallium_DRIVERS += libmesa_pipe_radeonsi -endif # radeonsi -gallium_DRIVERS += libmesa_pipe_radeon -endif # r600g || radeonsi -endif # r300g || r600g || radeonsi -ifneq ($(filter nouveau r600g, $(MESA_GPU_DRIVERS)),) -LOCAL_SHARED_LIBRARIES += libstlport -endif - -# vmwgfx -ifneq ($(filter vmwgfx, $(MESA_GPU_DRIVERS)),) -gallium_DRIVERS += libmesa_winsys_svga libmesa_pipe_svga -endif - -# -# Notes about the order here: -# -# * libmesa_st_egl depends on libmesa_winsys_sw_android in $(gallium_DRIVERS) -# * libmesa_pipe_r300 in $(gallium_DRIVERS) depends on libmesa_st_mesa and -#libmesa_glsl -# * libmesa_st_mesa depends on libmesa_glsl -# * libmesa_glsl depends on libmesa_glsl_utils -# -LOCAL_STATIC_LIBRARIES := \ - $(gallium_DRIVERS) \ - libmesa_st_mesa \ - libmesa_util \ - libmesa_glsl \ - libmesa_glsl_utils \ - libmesa_gallium \ - $(LOCAL_STATIC_LIBRARIES) - LOCAL_REQUIRED_MODULES += gallium_dri endif # MESA_BUILD_GALLIUM -LOCAL_STATIC_LIBRARIES := \ - $(LOCAL_STATIC_LIBRARIES) \ - libmesa_loader +LOCAL_STATIC_LIBRARIES += libmesa_loader LOCAL_MODULE := libGLES_mesa ifeq ($(MESA_LOLLIPOP_BUILD),true) -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/12] android: fix building errors with stlport
In Android the nouveau driver is built with stlport by including libstlport.mk. However, it changes the include paths order to be in favor of external/stlport/stlport. The assert.h defined in it is chosen that causes the building errors on compiling C code. Strictly speaking, stlport should only be added to C++'s include paths. However, the Android build system doesn't support 'LOCAL_CPP_INCLUDES'. Workaround the problem by GCC's #include_next so the bionic's assert.h will be chosen. Signed-off-by: Chih-Wei Huang --- src/util/list.h | 4 1 file changed, 4 insertions(+) diff --git a/src/util/list.h b/src/util/list.h index 9460347..3f979cfb 100644 --- a/src/util/list.h +++ b/src/util/list.h @@ -40,7 +40,11 @@ #include #include +#ifdef ANDROID +#include_next +#else #include +#endif struct list_head -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/12] android: loader: export the path to be included
Signed-off-by: Chih-Wei Huang --- src/egl/drivers/dri2/Android.mk | 1 - src/loader/Android.mk | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/src/egl/drivers/dri2/Android.mk b/src/egl/drivers/dri2/Android.mk index 5931ce8..d4d809b 100644 --- a/src/egl/drivers/dri2/Android.mk +++ b/src/egl/drivers/dri2/Android.mk @@ -45,7 +45,6 @@ endif LOCAL_C_INCLUDES := \ $(MESA_TOP)/src/mapi \ $(MESA_TOP)/src/egl/main \ - $(MESA_TOP)/src/loader \ $(DRM_GRALLOC_TOP) LOCAL_STATIC_LIBRARIES := \ diff --git a/src/loader/Android.mk b/src/loader/Android.mk index 8e215de..92d9fd2 100644 --- a/src/loader/Android.mk +++ b/src/loader/Android.mk @@ -40,6 +40,8 @@ else LOCAL_SHARED_LIBRARIES := libdrm endif +LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH) + LOCAL_MODULE := libmesa_loader include $(MESA_COMMON_MK) -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/12] android: generate files by $(call es-gen)
Use the pre-defined macro es-gen to generate new added files instead of writing new rules manually. The handmade rules that may generate the files before the directory is created result in such an error: /bin/bash: out/target/product/x86/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_pack.c: No such file or directory make: *** [out/target/product/x86/gen/STATIC_LIBRARIES/libmesa_st_mesa_intermediates/main/format_pack.c] Error 1 Signed-off-by: Chih-Wei Huang --- src/mesa/Android.gen.mk | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/src/mesa/Android.gen.mk b/src/mesa/Android.gen.mk index cc97954..145f259 100644 --- a/src/mesa/Android.gen.mk +++ b/src/mesa/Android.gen.mk @@ -115,9 +115,11 @@ $(intermediates)/main/api_exec.c: $(dispatch_deps) GET_HASH_GEN := $(LOCAL_PATH)/main/get_hash_generator.py +$(intermediates)/main/get_hash.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) $(GET_HASH_GEN) +$(intermediates)/main/get_hash.h: PRIVATE_XML := -f $(glapi)/gl_and_es_API.xml $(intermediates)/main/get_hash.h: $(glapi)/gl_and_es_API.xml \ $(LOCAL_PATH)/main/get_hash_params.py $(GET_HASH_GEN) - @$(MESA_PYTHON2) $(GET_HASH_GEN) -f $< > $@ + $(call es-gen) FORMAT_INFO := $(LOCAL_PATH)/main/format_info.py format_info_deps := \ @@ -125,8 +127,10 @@ format_info_deps := \ $(LOCAL_PATH)/main/format_parser.py \ $(FORMAT_INFO) +$(intermediates)/main/format_info.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) $(FORMAT_INFO) +$(intermediates)/main/format_info.h: PRIVATE_XML := $(intermediates)/main/format_info.h: $(format_info_deps) - @$(MESA_PYTHON2) $(FORMAT_INFO) $< > $@ + $(call es-gen, $<) FORMAT_PACK := $(LOCAL_PATH)/main/format_pack.py format_pack_deps := \ @@ -134,8 +138,10 @@ format_pack_deps := \ $(LOCAL_PATH)/main/format_parser.py \ $(FORMAT_PACK) +$(intermediates)/main/format_pack.c: PRIVATE_SCRIPT := $(MESA_PYTHON2) $(FORMAT_PACK) +$(intermediates)/main/format_pack.c: PRIVATE_XML := $(intermediates)/main/format_pack.c: $(format_pack_deps) - $(hide) $(MESA_PYTHON2) $(FORMAT_PACK) $< > $@ + $(call es-gen, $<) FORMAT_UNPACK := $(LOCAL_PATH)/main/format_unpack.py format_unpack_deps := \ @@ -143,5 +149,7 @@ format_unpack_deps := \ $(LOCAL_PATH)/main/format_parser.py \ $(FORMAT_UNPACK) +$(intermediates)/main/format_unpack.c: PRIVATE_SCRIPT := $(MESA_PYTHON2) $(FORMAT_UNPACK) +$(intermediates)/main/format_unpack.c: PRIVATE_XML := $(intermediates)/main/format_unpack.c: $(format_unpack_deps) - $(hide) $(MESA_PYTHON2) $(FORMAT_UNPACK) $< > $@ + $(call es-gen, $<) -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Fix symbol 'x86_64_entry_start' is already defined when building with LLVM/clang
This is just a re-post of the patch submitted by Tomasz at
https://bugs.freedesktop.org/show_bug.cgi?id=89599
Thanks
diff -Naur mesa-10.5.2/src/mapi/entry_x86-64_tls.h
mesa-10.5.2.tpg/src/mapi/entry_x86-64_tls.h
--- mesa-10.5.2/src/mapi/entry_x86-64_tls.h 2015-03-28 18:20:39.0 +
+++ mesa-10.5.2.tpg/src/mapi/entry_x86-64_tls.h 2015-04-06
20:36:37.819884382 +
@@ -62,8 +62,8 @@
{
}
-static char
-x86_64_entry_start[];
+extern char
+x86_64_entry_start[] __attribute__((visibility("hidden")));
mapi_func
entry_get_public(int slot)
diff -Naur mesa-10.5.2/src/mapi/entry_x86_tls.h
mesa-10.5.2.tpg/src/mapi/entry_x86_tls.h
--- mesa-10.5.2/src/mapi/entry_x86_tls.h 2015-03-28 18:20:39.0 +
+++ mesa-10.5.2.tpg/src/mapi/entry_x86_tls.h 2015-04-06 20:35:36.726238196 +
@@ -72,8 +72,8 @@
extern unsigned long
x86_current_tls();
-static char x86_entry_start[];
-static char x86_entry_end[];
+extern char x86_entry_start[] __attribute__((visibility("hidden")));
+extern char x86_entry_end[] __attribute__((visibility("hidden")));
void
entry_patch_public(void)
diff -Naur mesa-10.5.2/src/mapi/entry_x86_tsd.h
mesa-10.5.2.tpg/src/mapi/entry_x86_tsd.h
--- mesa-10.5.2/src/mapi/entry_x86_tsd.h 2015-03-28 18:20:39.0 +
+++ mesa-10.5.2.tpg/src/mapi/entry_x86_tsd.h 2015-04-06 20:34:56.415152047 +
@@ -59,8 +59,8 @@
#include
#include "u_execmem.h"
-static const char x86_entry_start[];
-static const char x86_entry_end[];
+extern const char x86_entry_start[] __attribute__((visibility("hidden")));
+extern const char x86_entry_end[] __attribute__((visibility("hidden")));
void
entry_patch_public(void)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] nv50/ir: optimize the use of std::tr1::unordered_set
Please elaborate why this is necessary. I have, in the past, had
requests to move to the C++11 std::unordered_set -- would that work
for you? I'd be happy with a #if c++11 is available, use
std::unordered_set. Otherwise use std::tr1::unordered_set.
On Fri, May 15, 2015 at 2:42 PM, Chih-Wei Huang wrote:
> Instead of using unordered_set directly, the patch
> changes to use unordered_set and adds a wrapper template class
> to convert the iterators to the expected user-defined type.
>
> This avoid instantiating the template multiple times and make it be
> more compatible with stlport.
>
> Signed-off-by: Chih-Wei Huang
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir.h | 28
> +++---
> .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 4 ++--
> .../nouveau/codegen/nv50_ir_lowering_nvc0.h| 4 +---
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 5 ++--
> 4 files changed, 30 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> index 529dcb9..f4d52b7 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
> @@ -451,6 +451,28 @@ struct Storage
> #define NV50_IR_INTERP_OFFSET (2 << 2)
> #define NV50_IR_INTERP_SAMPLEID(3 << 2)
>
> +typedef std::tr1::unordered_set voidptr_unordered_set;
> +
> +template
> +class ptr_unordered_set : public voidptr_unordered_set {
> + public:
> +typedef voidptr_unordered_set _base;
> +typedef _base::iterator _biterator;
> +
> +class iterator : public _biterator {
> + public:
> +iterator(const _biterator & i) : _biterator(i) {}
> +V *operator*() { return reinterpret_cast(*_biterator(*this)); }
> +const V *operator*() const { return reinterpret_cast *>(*_biterator(*this)); }
> +};
> +typedef const iterator const_iterator;
> +
> +iterator begin() { return _base::begin(); }
> +iterator end() { return _base::end(); }
> +const_iterator begin() const { return _base::begin(); }
> +const_iterator end() const { return _base::end(); }
> +};
> +
> // do we really want this to be a class ?
> class Modifier
> {
> @@ -583,10 +605,10 @@ public:
>
> static inline Value *get(Iterator&);
>
> - std::tr1::unordered_set uses;
> + ptr_unordered_set uses;
> std::list defs;
> - typedef std::tr1::unordered_set::iterator UseIterator;
> - typedef std::tr1::unordered_set::const_iterator UseCIterator;
> + typedef ptr_unordered_set::iterator UseIterator;
> + typedef ptr_unordered_set::const_iterator UseCIterator;
> typedef std::list::iterator DefIterator;
> typedef std::list::const_iterator DefCIterator;
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index b61f3c4..669d292 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -224,7 +224,7 @@ NVC0LegalizePostRA::findFirstUses(
>const Instruction *texi,
>const Instruction *insn,
>std::list &uses,
> - std::tr1::unordered_set& visited)
> + ptr_unordered_set& visited)
> {
> for (int d = 0; insn->defExists(d); ++d) {
>Value *v = insn->getDef(d);
> @@ -318,7 +318,7 @@ NVC0LegalizePostRA::insertTextureBarriers(Function *fn)
> if (!uses)
>return false;
> for (size_t i = 0; i < texes.size(); ++i) {
> - std::tr1::unordered_set visited;
> + ptr_unordered_set visited;
>findFirstUses(texes[i], texes[i], uses[i], visited);
> }
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
> index 260e101..17b6f6f 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
> @@ -20,8 +20,6 @@
> * OTHER DEALINGS IN THE SOFTWARE.
> */
>
> -#include
> -
> #include "codegen/nv50_ir.h"
> #include "codegen/nv50_ir_build_util.h"
>
> @@ -73,7 +71,7 @@ private:
> inline bool insnDominatedBy(const Instruction *, const Instruction *)
> const;
> void findFirstUses(const Instruction *tex, const Instruction *def,
>std::list&,
> - std::tr1::unordered_set&);
> + ptr_unordered_set&);
> void findOverwritingDefs(const Instruction *tex, Instruction *insn,
> const BasicBlock *term,
> std::list&);
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> index 898653c..03acba7 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> @@ -25,7 +25,6 @@
>
> #include
> #include
> -#incl
[Mesa-dev] [PATCH] i965: Fix FS unit tests
From: Ian Romanick
Commit 3687d75 changed the fs_visitor constructors, but it didn't update
all the users. As a result, 'make check' fails.
I added the explicit cast to the gl_program* parameter to make it more
clear which NULL was which.
Signed-off-by: Ian Romanick
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp | 3 ++-
src/mesa/drivers/dri/i965/test_fs_saturate_propagation.cpp | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
b/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
index 206a76e92..0e48e82 100644
--- a/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
@@ -45,7 +45,8 @@ public:
cmod_propagation_fs_visitor(struct brw_context *brw,
struct brw_wm_prog_data *prog_data,
struct gl_shader_program *shader_prog)
- : fs_visitor(brw, NULL, NULL, prog_data, shader_prog, NULL, 8) {}
+ : fs_visitor(brw, NULL, MESA_SHADER_FRAGMENT, NULL, &prog_data->base,
+ shader_prog, (struct gl_program *) NULL, 8) {}
};
diff --git a/src/mesa/drivers/dri/i965/test_fs_saturate_propagation.cpp
b/src/mesa/drivers/dri/i965/test_fs_saturate_propagation.cpp
index 4c91af3..8b1fab0 100644
--- a/src/mesa/drivers/dri/i965/test_fs_saturate_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/test_fs_saturate_propagation.cpp
@@ -45,7 +45,8 @@ public:
saturate_propagation_fs_visitor(struct brw_context *brw,
struct brw_wm_prog_data *prog_data,
struct gl_shader_program *shader_prog)
- : fs_visitor(brw, NULL, NULL, prog_data, shader_prog, NULL, 8) {}
+ : fs_visitor(brw, NULL, MESA_SHADER_FRAGMENT, NULL, &prog_data->base,
+ shader_prog, (struct gl_program *) NULL, 8) {}
};
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/20] t_dd_dmatmp: Kill the paths rendering quads/quad strips via indexed vertices
On 03/23/2015 05:47 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> No driver supports elts currently, and these make the validate_render
> code a bit hard to follow. Just kill them.
It looks like both r200_tcl.c and radeon_tcl.c define HAVE_TRI_STRIPS
and HAVE_ELTS, but I guess they're using t_dd_dmatmp2.h. If you add a
#if defined HAVE_ELTS
#error "HAVE_ELTS support is removed"
#endif
do radeon and r200 still build?
> Signed-off-by: Ville Syrjälä
> ---
> src/mesa/tnl_dd/t_dd_dmatmp.h | 133
> ++
> 1 file changed, 5 insertions(+), 128 deletions(-)
>
> diff --git a/src/mesa/tnl_dd/t_dd_dmatmp.h b/src/mesa/tnl_dd/t_dd_dmatmp.h
> index 52ea2bf..5ea2d31 100644
> --- a/src/mesa/tnl_dd/t_dd_dmatmp.h
> +++ b/src/mesa/tnl_dd/t_dd_dmatmp.h
> @@ -36,7 +36,7 @@
> * Produces code for both inline triangles and indexed triangles.
> * Where various primitive types are unaccelerated by hardware, the
> * code attempts to fallback to other primitive types (quadstrips to
> - * tristrips, lineloops to linestrips), or to indexed vertices.
> + * tristrips, lineloops to linestrips).
> */
>
> #if !defined(HAVE_TRIANGLES)
> @@ -444,65 +444,6 @@ static void TAG(render_quad_strip_verts)( struct
> gl_context *ctx,
>}
>
>FLUSH();
> -
> - } else if (HAVE_TRI_STRIPS &&
> - ctx->Light.ShadeModel == GL_FLAT &&
> - TNL_CONTEXT(ctx)->vb.AttribPtr[_TNL_ATTRIB_COLOR0]->stride) {
I don't think removing this whole block is right because !HAVE_ELTS is
an error case... but I guess we've never hit that error case since
HAVE_ELTS is always zero.
> - if (HAVE_ELTS) {
> - LOCAL_VARS;
> - int dmasz = GET_SUBSEQUENT_VB_MAX_ELTS();
> - int currentsz;
> - GLuint j, nr;
> -
> - EMIT_INDEXED_VERTS( ctx, start, count );
> -
> - /* Simulate flat-shaded quadstrips using indexed vertices:
> - */
> - ELT_INIT( GL_TRIANGLES );
> -
> - currentsz = GET_CURRENT_VB_MAX_ELTS();
> -
> - /* Emit whole number of quads in total, and in each buffer.
> - */
> - dmasz -= dmasz & 1;
> - count -= (count-start) & 1;
> - currentsz -= currentsz & 1;
> -
> - if (currentsz < 12)
> - currentsz = dmasz;
> -
> - currentsz = currentsz/6*2;
> - dmasz = dmasz/6*2;
> -
> - for (j = start; j + 3 < count; j += nr - 2 ) {
> - nr = MIN2( currentsz, count - j );
> - if (nr >= 4) {
> -GLint quads = (nr/2)-1;
> -GLint i;
> -ELTS_VARS( ALLOC_ELTS( quads*6 ) );
> -
> -for ( i = j-start ; i < j-start+quads*2 ; i+=2 ) {
> - EMIT_TWO_ELTS( 0, (i+0), (i+1) );
> - EMIT_TWO_ELTS( 2, (i+2), (i+1) );
> - EMIT_TWO_ELTS( 4, (i+3), (i+2) );
> - INCR_ELTS( 6 );
> -}
> -
> -FLUSH();
> - }
> - currentsz = dmasz;
> - }
> -
> - RELEASE_ELT_VERTS();
> - FLUSH();
> - }
> - else {
> - /* Vertices won't fit in a single buffer or elts not
> - * available - should never happen.
> - */
> - fprintf(stderr, "%s - cannot draw primitive\n", __FUNCTION__);
> - return;
> - }
> }
> else if (HAVE_TRI_STRIPS) {
>LOCAL_VARS;
> @@ -568,57 +509,6 @@ static void TAG(render_quads_verts)( struct gl_context
> *ctx,
> currentsz = dmasz;
>}
> }
> - else if (HAVE_ELTS) {
> - /* Hardware doesn't have a quad primitive type -- try to
> - * simulate it using indexed vertices and the triangle
> - * primitive:
> - */
> - LOCAL_VARS;
> - int dmasz = GET_SUBSEQUENT_VB_MAX_ELTS();
> - int currentsz;
> - GLuint j, nr;
> -
> - EMIT_INDEXED_VERTS( ctx, start, count );
> -
> - FLUSH();
> - ELT_INIT( GL_TRIANGLES );
> - currentsz = GET_CURRENT_VB_MAX_ELTS();
> -
> - /* Emit whole number of quads in total, and in each buffer.
> - */
> - dmasz -= dmasz & 3;
> - count -= (count-start) & 3;
> - currentsz -= currentsz & 3;
> -
> - /* Adjust for rendering as triangles:
> - */
> - currentsz = currentsz/6*4;
> - dmasz = dmasz/6*4;
> -
> - if (currentsz < 8)
> - currentsz = dmasz;
> -
> - for (j = start; j < count; j += nr ) {
> - nr = MIN2( currentsz, count - j );
> - if (nr >= 4) {
> - GLint quads = nr/4;
> - GLint i;
> - ELTS_VARS( ALLOC_ELTS( quads*6 ) );
> -
> - for ( i = j-start ; i < j-start+quads*4 ; i+=4 ) {
> -EMIT_TWO_ELTS( 0, (i+0), (i+1) );
> -EMIT_TWO_ELTS( 2, (i+3), (i+1) );
> -EMIT_TWO_ELTS( 4, (i+2), (i+3) );
> -INCR_ELTS( 6 );
> - }
> -
> - FLUSH();
> - }
> - currentsz = dmasz;
> - }
> -
> - RELEASE_ELT_VERTS();
> - }
> else if (HAVE_TRIANGLES) {
>/* Hardware doesn't have a quad primitive type -- try
Re: [Mesa-dev] [PATCH] i965: Fix FS unit tests
On Friday, May 15, 2015 11:57:16 AM Ian Romanick wrote:
> From: Ian Romanick
>
> Commit 3687d75 changed the fs_visitor constructors, but it didn't update
> all the users. As a result, 'make check' fails.
>
> I added the explicit cast to the gl_program* parameter to make it more
> clear which NULL was which.
>
> Signed-off-by: Ian Romanick
> Cc: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp | 3 ++-
> src/mesa/drivers/dri/i965/test_fs_saturate_propagation.cpp | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
> b/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
> index 206a76e92..0e48e82 100644
> --- a/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
> @@ -45,7 +45,8 @@ public:
> cmod_propagation_fs_visitor(struct brw_context *brw,
> struct brw_wm_prog_data *prog_data,
> struct gl_shader_program *shader_prog)
> - : fs_visitor(brw, NULL, NULL, prog_data, shader_prog, NULL, 8) {}
> + : fs_visitor(brw, NULL, MESA_SHADER_FRAGMENT, NULL, &prog_data->base,
> + shader_prog, (struct gl_program *) NULL, 8) {}
> };
>
>
> diff --git a/src/mesa/drivers/dri/i965/test_fs_saturate_propagation.cpp
> b/src/mesa/drivers/dri/i965/test_fs_saturate_propagation.cpp
> index 4c91af3..8b1fab0 100644
> --- a/src/mesa/drivers/dri/i965/test_fs_saturate_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/test_fs_saturate_propagation.cpp
> @@ -45,7 +45,8 @@ public:
> saturate_propagation_fs_visitor(struct brw_context *brw,
> struct brw_wm_prog_data *prog_data,
> struct gl_shader_program *shader_prog)
> - : fs_visitor(brw, NULL, NULL, prog_data, shader_prog, NULL, 8) {}
> + : fs_visitor(brw, NULL, MESA_SHADER_FRAGMENT, NULL, &prog_data->base,
> + shader_prog, (struct gl_program *) NULL, 8) {}
> };
>
>
>
Sorry!
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/20] t_dd_dmatmp: Allow flat shaded polygons with tri fans
On 03/23/2015 05:47 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We can allow rendering flat shaded polygons using tri fans if we check
> the provoking vertex convention.
This sounds reasonable since it matches the DX behavior. Is there a
piglit test that would hit this?
> Signed-off-by: Ville Syrjälä
> ---
> src/mesa/tnl_dd/t_dd_dmatmp.h | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/tnl_dd/t_dd_dmatmp.h b/src/mesa/tnl_dd/t_dd_dmatmp.h
> index 5ea2d31..3ed4a98 100644
> --- a/src/mesa/tnl_dd/t_dd_dmatmp.h
> +++ b/src/mesa/tnl_dd/t_dd_dmatmp.h
> @@ -406,7 +406,9 @@ static void TAG(render_poly_verts)( struct gl_context
> *ctx,
>
>FLUSH();
> }
> - else if (HAVE_TRI_FANS && ctx->Light.ShadeModel == GL_SMOOTH) {
> + else if (HAVE_TRI_FANS &&
> + (ctx->Light.ShadeModel == GL_SMOOTH ||
> + ctx->Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION_EXT)) {
>TAG(render_tri_fan_verts)( ctx, start, count, flags );
> } else {
>fprintf(stderr, "%s - cannot draw primitive\n", __FUNCTION__);
> @@ -885,7 +887,9 @@ static void TAG(render_poly_elts)( struct gl_context *ctx,
>FLUSH();
>currentsz = dmasz;
>}
> - } else if (HAVE_TRI_FANS && ctx->Light.ShadeModel == GL_SMOOTH) {
> + } else if (HAVE_TRI_FANS &&
> + (ctx->Light.ShadeModel == GL_SMOOTH ||
> +ctx->Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION_EXT)) {
>TAG(render_tri_fan_verts)( ctx, start, count, flags );
> } else {
>fprintf(stderr, "%s - cannot draw primitive\n", __FUNCTION__);
> @@ -1109,7 +1113,9 @@ static GLboolean TAG(validate_render)( struct
> gl_context *ctx,
> ok = GL_TRUE;
>}
>else {
> - ok = (HAVE_TRI_FANS && ctx->Light.ShadeModel == GL_SMOOTH);
> + ok = (HAVE_TRI_FANS &&
> + (ctx->Light.ShadeModel == GL_SMOOTH ||
> +ctx->Light.ProvokingVertex ==
> GL_FIRST_VERTEX_CONVENTION_EXT));
> }
>break;
>case GL_QUAD_STRIP:
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix FS unit tests
On Fri, May 15, 2015 at 12:06 PM, Kenneth Graunke wrote: > Sorry! > > Reviewed-by: Kenneth Graunke Capital W in your email. idr, please fix this before you commit. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/20] t_dd_dmatmp: Disallow flat shading when rendering quad strips via tri strips
On 03/23/2015 05:47 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When rendering quad strips via tri strips we can't get the provoking
> vertex right, so disallow flat shading.
Same comments as for patch 2.
> Signed-off-by: Ville Syrjälä
> ---
> src/mesa/tnl_dd/t_dd_dmatmp.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/tnl_dd/t_dd_dmatmp.h b/src/mesa/tnl_dd/t_dd_dmatmp.h
> index 3ed4a98..f56b0aa 100644
> --- a/src/mesa/tnl_dd/t_dd_dmatmp.h
> +++ b/src/mesa/tnl_dd/t_dd_dmatmp.h
> @@ -447,7 +447,7 @@ static void TAG(render_quad_strip_verts)( struct
> gl_context *ctx,
>
>FLUSH();
> }
> - else if (HAVE_TRI_STRIPS) {
> + else if (HAVE_TRI_STRIPS && ctx->Light.ShadeModel == GL_SMOOTH) {
>LOCAL_VARS;
>int dmasz = GET_SUBSEQUENT_VB_MAX_VERTS();
>int currentsz;
> @@ -1124,7 +1124,7 @@ static GLboolean TAG(validate_render)( struct
> gl_context *ctx,
>} else if (HAVE_QUAD_STRIPS) {
> ok = GL_TRUE;
>} else {
> - ok = HAVE_TRI_STRIPS;
> + ok = (HAVE_TRI_STRIPS && ctx->Light.ShadeModel == GL_SMOOTH);
>}
>break;
>case GL_QUADS:
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/20] i915: Fix collision between I830_UPLOAD_RASTER_RULES and I830_UPLOAD_TEX(0)
This patch seems obviously correct and is Reviewed-by: Ian Romanick On 03/23/2015 05:47 AM, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > I830_UPLOAD_RASTER_RULES and I830_UPLOAD_TEX(0) are trying to occupy > the same bit. Move the texture bits upwards a bit to make room for > I830_UPLOAD_RASTER_RULES. > > Now the driver will actually upload the raster rules which is rather > important to get the provoking vertex right. Fixes the appearance > of glxgears teeth on gen2. > > Signed-off-by: Ville Syrjälä > --- > src/mesa/drivers/dri/i915/i830_context.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/src/mesa/drivers/dri/i915/i830_context.h > b/src/mesa/drivers/dri/i915/i830_context.h > index 140f617..92952cf 100644 > --- a/src/mesa/drivers/dri/i915/i830_context.h > +++ b/src/mesa/drivers/dri/i915/i830_context.h > @@ -42,10 +42,10 @@ > #define I830_UPLOAD_STIPPLE 0x4 > #define I830_UPLOAD_INVARIENT0x8 > #define I830_UPLOAD_RASTER_RULES 0x10 > -#define I830_UPLOAD_TEX(i) (0x10<<(i)) > -#define I830_UPLOAD_TEXBLEND(i) (0x100<<(i)) > -#define I830_UPLOAD_TEX_ALL (0x0f0) > -#define I830_UPLOAD_TEXBLEND_ALL (0xf00) > +#define I830_UPLOAD_TEX(i) (0x0100<<(i)) > +#define I830_UPLOAD_TEXBLEND(i) (0x1000<<(i)) > +#define I830_UPLOAD_TEX_ALL (0x0f00) > +#define I830_UPLOAD_TEXBLEND_ALL (0xf000) > > /* State structure offsets - these will probably disappear. > */ > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
