[Mesa-dev] [PATCH 5/5] r300/compiler: Use precomputed q values in the register allocator
From: Tom Stellard
---
.../drivers/r300/compiler/radeon_pair_regalloc.c | 70 +++-
1 files changed, 69 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
b/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
index c53c207..c682112 100644
--- a/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
+++ b/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
@@ -32,6 +32,7 @@
#include "main/glheader.h"
#include "program/register_allocate.h"
+#include "util/u_memory.h"
#include "ralloc.h"
#include "r300_fragprog_swizzle.h"
@@ -637,6 +638,53 @@ static void do_advanced_regalloc(struct regalloc_state * s)
void rc_init_regalloc_state(struct rc_regalloc_state *s)
{
unsigned i, j, index;
+ unsigned **ra_q_values;
+
+ /* Pre-computed q values. This array describes the maximum number of
+* a class's [row] registers that are in conflict with a single
+* register from another class [column].
+*
+* For example:
+* q_values[0][2] is 3, because a register from class 2
+* (RC_REG_CLASS_TRIPLE) may conflict with at most 3 registers from
+* class 0 (RC_REG_CLASS_SINGLE) e.g. T0.xyz conflicts with T0.x, T0.y,
+* and T0.z.
+*
+* q_values[2][0] is 1, because a register from class 0
+* (RC_REG_CLASS_SINGLE) may conflict with at most 1 register from
+* class 2 (RC_REG_CLASS_TRIPLE) e.g. T0.x conflicts with T0.xyz
+*
+* The q values for each register class [row] will never be greater
+* than the maximum number of writemask combinations for that class.
+*
+* For example:
+*
+* Class 2 (RC_REG_CLASS_TRIPLE) only has 1 writemask combination,
+* so no value in q_values[2][0..RC_REG_CLASS_COUNT] will be greater
+* than 1.
+*/
+ const unsigned q_values[RC_REG_CLASS_COUNT][RC_REG_CLASS_COUNT] = {
+ {1, 2, 3, 0, 1, 2, 3, 1, 1, 1, 2, 2, 2, 1, 1, 1, 2, 2, 2},
+ {2, 3, 3, 0, 2, 3, 3, 2, 2, 2, 3, 3, 3, 2, 2, 2, 3, 3, 3},
+ {1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1},
+ {0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1},
+ {1, 2, 3, 3, 3, 3, 3, 1, 1, 1, 2, 2, 2, 3, 3, 3, 3, 3, 3},
+ {2, 3, 3, 3, 3, 3, 3, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 3},
+ {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1},
+ {1, 1, 1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 1, 1, 0, 0, 1, 0, 1},
+ {1, 1, 1, 0, 1, 1, 1, 0, 1, 0, 1, 1, 0, 0, 1, 0, 1, 1, 0},
+ {1, 1, 1, 0, 1, 1, 1, 0, 0, 1, 0, 1, 1, 0, 0, 1, 0, 1, 1},
+ {1, 1, 1, 0, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 0, 1, 1, 1},
+ {1, 1, 1, 0, 1, 1, 1, 0, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1},
+ {1, 1, 1, 0, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1},
+ {1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 0, 1, 1, 1, 1, 1, 1, 1},
+ {1, 1, 1, 1, 1, 1, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 1, 1, 1},
+ {1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1},
+ {1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1},
+ {1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1},
+ {1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1}
+ };
+
/* Allocate the main ra data structure */
s->regs = ra_alloc_reg_set(NULL, R500_PFS_NUM_TEMP_REGS * RC_MASK_XYZW);
@@ -656,10 +704,30 @@ void rc_init_regalloc_state(struct rc_regalloc_state *s)
}
}
+ /* Set the q values. The q_values array is indexed based on
+* the rc_reg_class ID (RC_REG_CLASS_*) which might be
+* different than the ID assigned to that class by ra.
+* This why we need to manually construct this list.
+*/
+ ra_q_values = MALLOC(RC_REG_CLASS_COUNT * sizeof(unsigned *));
+
+ for (i = 0; i < RC_REG_CLASS_COUNT; i++) {
+ ra_q_values[i] = MALLOC(RC_REG_CLASS_COUNT * sizeof(unsigned));
+ for (j = 0; j < RC_REG_CLASS_COUNT; j++) {
+ ra_q_values[s->class_ids[i]][s->class_ids[j]] =
+ q_values[i][j];
+ }
+ }
+
/* Add register conflicts */
add_register_conflicts(s->regs, R500_PFS_NUM_TEMP_REGS);
- ra_set_finalize(s->regs, NULL);
+ ra_set_finalize(s->regs, ra_q_values);
+
+ for (i = 0; i < RC_REG_CLASS_COUNT; i++) {
+ FREE(ra_q_values[i]);
+ }
+ FREE(ra_q_values);
}
void rc_destroy_regalloc_state(struct rc_regalloc_state *s)
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] r300g: Init regalloc state during context creation
From: Tom Stellard
Initializing the regalloc state is expensive, and since it is always
the same for every compile we only need to initialize it once per
context. This should help improve shader compile times for the driver.
This reduces the runtime of the glean texCombine test ~25%.
---
.../drivers/r300/compiler/radeon_compiler.c|4 +-
.../drivers/r300/compiler/radeon_compiler.h|3 +-
.../drivers/r300/compiler/radeon_pair_regalloc.c | 273 +---
.../drivers/r300/compiler/radeon_regalloc.h| 62 +
src/gallium/drivers/r300/r300_context.c|6 +
src/gallium/drivers/r300/r300_context.h|5 +
src/gallium/drivers/r300/r300_fs.c |2 +-
src/gallium/drivers/r300/r300_vs.c |2 +-
8 files changed, 203 insertions(+), 154 deletions(-)
create mode 100644 src/gallium/drivers/r300/compiler/radeon_regalloc.h
diff --git a/src/gallium/drivers/r300/compiler/radeon_compiler.c
b/src/gallium/drivers/r300/compiler/radeon_compiler.c
index 4d4eb64..081cd2d 100644
--- a/src/gallium/drivers/r300/compiler/radeon_compiler.c
+++ b/src/gallium/drivers/r300/compiler/radeon_compiler.c
@@ -29,10 +29,11 @@
#include "radeon_dataflow.h"
#include "radeon_program.h"
#include "radeon_program_pair.h"
+#include "radeon_regalloc.h"
#include "radeon_compiler_util.h"
-void rc_init(struct radeon_compiler * c)
+void rc_init(struct radeon_compiler * c, const struct rc_regalloc_state *rs)
{
memset(c, 0, sizeof(*c));
@@ -40,6 +41,7 @@ void rc_init(struct radeon_compiler * c)
c->Program.Instructions.Prev = &c->Program.Instructions;
c->Program.Instructions.Next = &c->Program.Instructions;
c->Program.Instructions.U.I.Opcode = RC_OPCODE_ILLEGAL_OPCODE;
+ c->regalloc_state = rs;
}
void rc_destroy(struct radeon_compiler * c)
diff --git a/src/gallium/drivers/r300/compiler/radeon_compiler.h
b/src/gallium/drivers/r300/compiler/radeon_compiler.h
index f78a51c..e2710d8 100644
--- a/src/gallium/drivers/r300/compiler/radeon_compiler.h
+++ b/src/gallium/drivers/r300/compiler/radeon_compiler.h
@@ -44,6 +44,7 @@ enum rc_program_type {
struct radeon_compiler {
struct memory_pool Pool;
struct rc_program Program;
+ const struct rc_regalloc_state *regalloc_state;
enum rc_program_type type;
unsigned Debug:2;
unsigned Error:1;
@@ -77,7 +78,7 @@ struct radeon_compiler {
unsigned initial_num_insts; /* Number of instructions at start. */
};
-void rc_init(struct radeon_compiler * c);
+void rc_init(struct radeon_compiler * c, const struct rc_regalloc_state *rs);
void rc_destroy(struct radeon_compiler * c);
void rc_debug(struct radeon_compiler * c, const char * fmt, ...);
diff --git a/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
b/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
index 12594c8..c53c207 100644
--- a/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
+++ b/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
@@ -39,6 +39,7 @@
#include "radeon_compiler_util.h"
#include "radeon_dataflow.h"
#include "radeon_list.h"
+#include "radeon_regalloc.h"
#include "radeon_variable.h"
#define VERBOSE 0
@@ -70,47 +71,96 @@ struct regalloc_state {
int LoopEnd;
};
-enum rc_reg_class {
- RC_REG_CLASS_SINGLE,
- RC_REG_CLASS_DOUBLE,
- RC_REG_CLASS_TRIPLE,
- RC_REG_CLASS_ALPHA,
- RC_REG_CLASS_SINGLE_PLUS_ALPHA,
- RC_REG_CLASS_DOUBLE_PLUS_ALPHA,
- RC_REG_CLASS_TRIPLE_PLUS_ALPHA,
- RC_REG_CLASS_X,
- RC_REG_CLASS_Y,
- RC_REG_CLASS_Z,
- RC_REG_CLASS_XY,
- RC_REG_CLASS_YZ,
- RC_REG_CLASS_XZ,
- RC_REG_CLASS_XW,
- RC_REG_CLASS_YW,
- RC_REG_CLASS_ZW,
- RC_REG_CLASS_XYW,
- RC_REG_CLASS_YZW,
- RC_REG_CLASS_XZW,
- RC_REG_CLASS_COUNT
-};
-
struct rc_class {
- enum rc_reg_class Class;
+ enum rc_reg_class ID;
unsigned int WritemaskCount;
- /** This is 1 if this class is being used by the register allocator
-* and 0 otherwise */
- unsigned int Used;
-
- /** This is the ID number assigned to this class by ra. */
- unsigned int Id;
-
/** List of writemasks that belong to this class */
unsigned int Writemasks[3];
};
+const struct rc_class rc_class_list [] = {
+ {RC_REG_CLASS_SINGLE, 3,
+ {RC_MASK_X,
+RC_MASK_Y,
+RC_MASK_Z}},
+ {RC_REG_CLASS_DOUBLE, 3,
+ {RC_MASK_X | RC_MASK_Y,
+RC_MASK_X | RC_MASK_Z,
+RC_MASK_Y | RC_MASK_Z}},
+ {RC_REG_CLASS_TRIPLE, 1,
+ {RC_MASK_X | RC_MASK_Y | RC_MASK_Z,
+RC_MASK_NONE,
+RC_MASK_NONE}},
+ {RC_REG_CLASS_ALPHA, 1,
+
[Mesa-dev] [PATCH 3/5] r300/compiler: Don't create register classes for inputs
From: Tom Stellard
---
.../drivers/r300/compiler/radeon_pair_regalloc.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
b/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
index 85bb248..12594c8 100644
--- a/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
+++ b/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
@@ -539,7 +539,6 @@ static void do_advanced_regalloc(struct regalloc_state * s)
unsigned int i, j, index, input_node, node_count, node_index;
unsigned int * node_classes;
- unsigned int * input_classes;
struct rc_instruction * inst;
struct rc_list * var_ptr;
struct rc_list * variables;
@@ -554,8 +553,6 @@ static void do_advanced_regalloc(struct regalloc_state * s)
node_count = rc_list_count(variables);
node_classes = memory_pool_malloc(&s->C->Pool,
node_count * sizeof(unsigned int));
- input_classes = memory_pool_malloc(&s->C->Pool,
- s->NumInputs * sizeof(unsigned int));
for (var_ptr = variables, node_index = 0; var_ptr;
var_ptr = var_ptr->Next, node_index++) {
@@ -610,7 +607,7 @@ static void do_advanced_regalloc(struct regalloc_state * s)
rc_for_all_reads_mask(inst, scan_read_callback, s);
}
- /* Create classes for input registers */
+ /* Compute the writemask for inputs. */
for (i = 0; i < s->NumInputs; i++) {
unsigned int chan, class_id, writemask = 0;
for (chan = 0; chan < 4; chan++) {
@@ -619,14 +616,6 @@ static void do_advanced_regalloc(struct regalloc_state * s)
}
}
s->Input[i].Writemask = writemask;
- if (!writemask) {
- continue;
- }
-
- class_id = ra_alloc_reg_class(regs);
- input_classes[i] = class_id;
- ra_class_add_reg(regs, class_id,
- get_reg_id(s->Input[i].Index, writemask));
}
ra_set_finalize(regs, NULL);
@@ -663,8 +652,6 @@ static void do_advanced_regalloc(struct regalloc_state * s)
if (!s->Input[i].Writemask) {
continue;
}
- ra_set_node_class(graph, node_count + input_node,
- input_classes[i]);
for (var_ptr = variables, node_index = 0;
var_ptr; var_ptr = var_ptr->Next, node_index++)
{
struct rc_variable * var = var_ptr->Item;
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] ra: Add q_values parameter to ra_set_finalize()
From: Tom Stellard
This allows the user to pass precomputed q values to the allocator.
---
.../drivers/r300/compiler/radeon_pair_regalloc.c |2 +-
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp |2 +-
.../drivers/dri/i965/brw_vec4_reg_allocate.cpp |2 +-
src/mesa/program/register_allocate.c | 13 -
src/mesa/program/register_allocate.h |4 +++-
5 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
b/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
index bb5b43f..85bb248 100644
--- a/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
+++ b/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
@@ -629,7 +629,7 @@ static void do_advanced_regalloc(struct regalloc_state * s)
get_reg_id(s->Input[i].Index, writemask));
}
- ra_set_finalize(regs);
+ ra_set_finalize(regs, NULL);
graph = ra_alloc_interference_graph(regs, node_count + s->NumInputs);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index e7f11ae..b0d4124 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -142,7 +142,7 @@ brw_alloc_reg_set_for_classes(struct brw_context *brw,
class_count++;
}
- ra_set_finalize(brw->wm.regs);
+ ra_set_finalize(brw->wm.regs, NULL);
}
bool
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
index 2d9d0c8..2cda678 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
@@ -136,7 +136,7 @@ brw_alloc_reg_set_for_classes(struct brw_context *brw,
}
assert(reg == ra_reg_count);
- ra_set_finalize(brw->vs.regs);
+ ra_set_finalize(brw->vs.regs, NULL);
}
void
diff --git a/src/mesa/program/register_allocate.c
b/src/mesa/program/register_allocate.c
index 07eb154..97d4e33 100644
--- a/src/mesa/program/register_allocate.c
+++ b/src/mesa/program/register_allocate.c
@@ -255,9 +255,11 @@ ra_class_add_reg(struct ra_regs *regs, unsigned int c,
unsigned int r)
/**
* Must be called after all conflicts and register classes have been
* set up and before the register set is used for allocation.
+ * To avoid costly q value computation, use the q_values paramater
+ * to pass precomputed q values to this function.
*/
void
-ra_set_finalize(struct ra_regs *regs)
+ra_set_finalize(struct ra_regs *regs, unsigned int **q_values)
{
unsigned int b, c;
@@ -265,6 +267,15 @@ ra_set_finalize(struct ra_regs *regs)
regs->classes[b]->q = ralloc_array(regs, unsigned int,
regs->class_count);
}
+ if (q_values) {
+ for (b = 0; b < regs->class_count; b++) {
+ for (c = 0; c < regs->class_count; c++) {
+regs->classes[b]->q[c] = q_values[b][c];
+}
+ }
+ return;
+ }
+
/* Compute, for each class B and C, how many regs of B an
* allocation to C could conflict with.
*/
diff --git a/src/mesa/program/register_allocate.h
b/src/mesa/program/register_allocate.h
index 00b851e..2a9d611 100644
--- a/src/mesa/program/register_allocate.h
+++ b/src/mesa/program/register_allocate.h
@@ -43,7 +43,9 @@ void ra_add_reg_conflict(struct ra_regs *regs,
void ra_add_transitive_reg_conflict(struct ra_regs *regs,
unsigned int base_reg, unsigned int reg);
void ra_class_add_reg(struct ra_regs *regs, unsigned int c, unsigned int reg);
-void ra_set_finalize(struct ra_regs *regs);
+void ra_set_num_conflicts(struct ra_regs *regs, unsigned int class_a,
+ unsigned int class_b, unsigned int num_conflicts);
+void ra_set_finalize(struct ra_regs *regs, unsigned int **conflicts);
/** @} */
/** @{ Interference graph setup.
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] ra: Clarify usage of ra_set_node_reg()
From: Tom Stellard --- src/mesa/program/register_allocate.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/mesa/program/register_allocate.c b/src/mesa/program/register_allocate.c index f08c9d2..07eb154 100644 --- a/src/mesa/program/register_allocate.c +++ b/src/mesa/program/register_allocate.c @@ -490,6 +490,8 @@ ra_get_node_reg(struct ra_graph *g, unsigned int n) * input data). These nodes do not end up in the stack during * ra_simplify(), and thus at ra_select() time it is as if they were * the first popped off the stack and assigned their fixed locations. + * Nodes that use this function do not need to be assigned a register + * class. * * Must be called before ra_simplify(). */ -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: bump version to 9.1 (devel)
Now that branch 9.0 is created, bump the minor version in master. --- Makefile.am |2 +- configs/default |2 +- configure.ac|2 +- src/mesa/main/version.h |4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/Makefile.am b/Makefile.am index 36bcf1f..e411218 100644 --- a/Makefile.am +++ b/Makefile.am @@ -52,7 +52,7 @@ distclean-local: # Rules for making release tarballs -PACKAGE_VERSION=9.0-devel +PACKAGE_VERSION=9.1-devel PACKAGE_DIR = Mesa-$(PACKAGE_VERSION) PACKAGE_NAME = MesaLib-$(PACKAGE_VERSION) diff --git a/configs/default b/configs/default index 5e4cc56..7b9e1c6 100644 --- a/configs/default +++ b/configs/default @@ -9,7 +9,7 @@ CONFIG_NAME = default # Version info MESA_MAJOR=9 -MESA_MINOR=0 +MESA_MINOR=1 MESA_TINY=0 MESA_VERSION = $(MESA_MAJOR).$(MESA_MINOR).$(MESA_TINY) diff --git a/configure.ac b/configure.ac index f7f1605..688bdc0 100644 --- a/configure.ac +++ b/configure.ac @@ -6,7 +6,7 @@ dnl Tell the user about autoconf.html in the --help output m4_divert_once([HELP_END], [ See docs/autoconf.html for more details on the options for Mesa.]) -AC_INIT([Mesa], [9.0.0], +AC_INIT([Mesa], [9.1.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa]) AC_CONFIG_AUX_DIR([bin]) AC_CANONICAL_HOST diff --git a/src/mesa/main/version.h b/src/mesa/main/version.h index 5b2e85a..f0ba6f2 100644 --- a/src/mesa/main/version.h +++ b/src/mesa/main/version.h @@ -33,9 +33,9 @@ struct gl_context; /* Mesa version */ #define MESA_MAJOR 9 -#define MESA_MINOR 0 +#define MESA_MINOR 1 #define MESA_PATCH 0 -#define MESA_VERSION_STRING "9.0-devel" +#define MESA_VERSION_STRING "9.1-devel" /* To make version comparison easy */ #define MESA_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] fixes for 8.0
Hi list, Actually I wanted to wait for my fdo account and then push a branch at people.fdo with the candidates for 8.0. But in the meantime I'm sending you an update with some issues to solve. I have cherry-picked almost all of the outstanding candidates to mesa 8.0 The following commits have caused conflicts: - error: could not apply 19bd593... i965: Add support for GL_SKIP_DECODE_EXT on other SRGB formats. - error: could not apply c0f6010... i965/fs: Don't clobber sampler message MRFs with subexpressions. - error: could not apply 9b4053c... i965: Drop the confusing saturate argument to math instruction setup. - error: could not apply e119f98... i965/vs: Add support for copying user edge flags. - error: could not apply 4e087de... intel: Reserve enough space to finish occlusion queries on Gen6. - error: could not apply 6928bea... i965/fs: Initialize output_components[] by filling it with zeros. And the following commit does not compile on the 8.0 branch, since the functions _mesa_is_desktop_gl(), _mesa_is_gles() and _mesa_is_gles3() do not exist in the 8.0 branch. It has to be manually backported. - 3f7c8364cf1d763f04413aecfac66df5534aeb34 mesa: Filter glBindTexture targets based on supported features. And finally this is the git-shortlog of the successfully cherry-picked commits: Alex Deucher (3): r600g: 8.0.x support for Trinity r600g: add new Sumo, Palm, BTC pci ids r600g: add additional evergreen pci ids Brian Paul (11): mesa: loosen small matrix determinant check radeon: set swrast_renderbuffer::ColorType field when mapping renderbuffers xlib: add X error handler around XGetImage() call svga: fix invalid memory reference in needs_to_create_zero() meta: fix glDrawPixels fallback test, stencil drawing st/mesa: fix glCopyTexSubImage crash gallivm: fix crash in lp_sampler_static_state() st/mesa: fix renderbuffer validation bug softpipe: fix softpipe_delete_fs_state() failed assertion mesa: raise GL_INVALID_OPERATION in glGenerateMipmap for missing base image st/mesa: s/CALLOC/calloc/ to fix allocation bug Chad Versace (2): swrast: Fix implicit declaration warnings i830: Fix stack corruption Christoph Bumiller (1): st/mesa: call update_renderbuffer_surface for sRGB renderbuffers, too Eric Anholt (2): i965/vs: Convert EdgeFlagPointer values appropriately for the VS on gen4. i965: Fix accumulator_contains() test to also reject swizzles of the dst. Ian Romanick (3): dri2: Fix bug in attribute handling for non-desktop OpenGL contexts mesa: Generate an error when glCopyTexImage border is invalid mesa/es: Validate glTexImage border in Mesa code rather than the ES wrapper Jordan Justen (1): intel: move error on create context to proper path José Fonseca (1): mesa: disable MSVC global optimization in pack.c Kenneth Graunke (4): mesa: Prevent repeated glDeleteShader() from blowing away our refcounts. i965/vs: Don't clobber sampler message MRFs with subexpressions. intel: Move finish_batch() call before MI_BATCH_BUFFER_END and padding. i965/fs: Don't use brw->fragment_program in calculate_urb_setup(). Marek Olšák (1): gallium/u_blit: set dst format from pipe_resource, not pipe_surface Niels Ole Salscheider (1): st/mesa: index can be negative in the PROGRAM_CONSTANT case Stéphane Marchesin (1): glsl/linker: Avoid buffer over-run in parcel_out_uniform_storage::visit_field I have done a piglit (1d05317) quick run with r600g on my rv770 without any regressions. Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: order atom emission
On Thu, Sep 6, 2012 at 11:32 AM, Alex Deucher wrote: > On Thu, Sep 6, 2012 at 10:54 AM, Jerome Glisse wrote: >> On Thu, Sep 6, 2012 at 6:20 AM, Dave Airlie wrote: >>> On Thu, Sep 6, 2012 at 5:21 PM, Philipp Klaus Krause wrote: On 06.09.2012 07:35, j.gli...@gmail.com wrote: > From: Jerome Glisse > > To avoid GPU lockup registers must be emited in a specific order > (no kidding ...). This patch rework atom emission so order in which > atom are emited in respect to each other is always the same. We > don't have any informations on what is the correct order so order > will need to be infered from fglrx command stream. Shouldn't this be stated in comments, so the next person who comes along and makes a change in this code doesn't inadvertently change the order? >>> >>> Also a comment on what ordering matters most, like I suspect this is >>> just hiding a real issue. >>> >>> Dave. >> >> No it's not hiding an issue, afaict it's how the hw works. The hw do >> what some amd document call states validations. So here is how i >> understand how things happen and i can be completely wrong. Hw process >> register write in order it receive them and to avoid postponing state >> validation the hw do state validation while processing register. That >> means if writing register A trigger state validation that use some >> field of register B the hw might not redo state validation when >> register B is latter written. ie only some register trigger the state >> validation no matter on what they depends on. I believe state >> validation is only use as pipeline optimization by the hw, so the hw >> knows it can take some short cut. But in some rare case if short cut >> are taken for wrong reasons we end up in GPU lockup. >> >> No matter if my guess is right or wrong, i know for a fact that >> register order is important in some situation, that's the hard bottom >> line, no matter what is the reasons inside the hw. >> >> This patch is far from having all the order right, it's just a first >> step, i am atomizing everything and it's what needed to go forward >> without regression. > > I've talked to the internal hw and sw guys and they said there isn't > any specific ordering required and the closed driver doesn't impose > any specific order. The pipeline doesn't get kicked off until a draw > command is issued, so I don't see why the state update order would > matter. It's possible there are subtle ordering requirements and the > closed driver just happened to get it right. There are dependencies > and hw bug workarounds however. E.g., some blocks snoop registers > from other blocks so you need to make sure those dependant registers > have been initialized before drawing. I don't know if it's the > ordering so much as making sure we emit all the necessary state when > needed. The closed driver tends to update a lot more state the is > minimally required for a lot of things. That said, it probably > wouldn't hurt to mirror the closed driver more closely. > > Alex I don't know what are the reason but what register are emitted and along which other register definitely matter. All files i am talking in this mail are located at : http://people.freedesktop.org/~glisse/registerposition/ So if you apply : 0001-r600g-FORCE-LOCKUP-BY-EMITTING-OR-NOT-REGISTER.patch and run piglit test like in lockup-longprim.sh you will lockup the GPU (i only tested on r6xx, r7xx so far). I double checked through automated tools that no register that was written by command stream from longprim piglist test are reprogram properly by the fbo test (if you have my constant buffer size patch i sent earlier). The only diff with command stream is one where R_02881C_PA_CL_VS_OUT_CNTL is emitted with each and the other only once, when emitted with each draw it lockups. bad command stream r600g-long-prim-simple-b.txt good one r600g-long-prim-simple-g.txt diff r600g-long-prim-simple-d.txt Given the bad one emit more register some draw command are moved to the second cs. Emitting some other register along PA_CL_VS_OUT_CNTL fix the lockup (don't have short list) but many other register behave the same as PA_CL_VS_OUT_CNTL. So if order does not matter then register group definitely does. I really wish that the hw were less picky about how command stream are supposed to be formated. Anyhow given that we have no information on what register need to be emitted together, mimicking fglrx sounds like the way to go. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/19] mesa: Don't set shaderapi dispatch pointers for many things in ES2 or core
Ian Romanick writes:
> From: Ian Romanick
>
> NOTE: This is a candidate for the 9.0 branch
GL_ARB_shader_objects and friends are marked as GL not GLL in
extensions.c -- should their functions still be exposed if we're
exposing the extensions?
> /* GL_EXT_gpu_shader4 / GL 3.0 */
> - SET_BindFragDataLocationEXT(exec, _mesa_BindFragDataLocation);
> - SET_GetFragDataLocationEXT(exec, _mesa_GetFragDataLocation);
> + if (ctx->API != API_OPENGLES2 || _mesa_is_gles3(ctx)) {
> + SET_BindFragDataLocationEXT(exec, _mesa_BindFragDataLocation);
> + }
> + if (ctx->API != API_OPENGLES2 || _mesa_is_gles3(ctx)) {
> + SET_GetFragDataLocationEXT(exec, _mesa_GetFragDataLocation);
> + }
Fold these two ifs together? Also, should the EXTs actually be exposed
on gles3? (seems like just the core versions below should)
> @@ -1778,8 +1788,10 @@ _mesa_init_shader_dispatch(struct _glapi_table *exec)
> SET_ShaderBinary(exec, _mesa_ShaderBinary);
>
> /* GL_ARB_blend_func_extended */
> - SET_BindFragDataLocationIndexed(exec, _mesa_BindFragDataLocationIndexed);
> - SET_GetFragDataIndex(exec, _mesa_GetFragDataIndex);
> + if (ctx->API != API_OPENGLES2) {
> + SET_BindFragDataLocationIndexed(exec,
> _mesa_BindFragDataLocationIndexed);
> + SET_GetFragDataIndex(exec, _mesa_GetFragDataIndex);
> + }
> #endif /* FEATURE_GL */
> }
pgp4UJLvlrJ9h.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 13/19] mesa: Don't set loopback dispatch pointers for most things in ES2 or core
Ian Romanick writes:
> From: Ian Romanick
>
> NOTE: This is a candidate for the 9.0 branch
>
> Signed-off-by: Ian Romanick
> + if (ctx->API != API_OPENGLES2) {
> + SET_VertexAttrib1sARB(dest, loopback_VertexAttrib1sARB);
> + SET_VertexAttrib1dARB(dest, loopback_VertexAttrib1dARB);
Shouldn't these just be for desktop GL? (no GLES1)
pgpyMIEfE5xh6.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/19] mesa: Don't set uniform dispatch pointers for many things in ES2 or core
Ian Romanick writes: > From: Ian Romanick > > NOTE: This is a candidate for the 9.0 branch > > Signed-off-by: Ian Romanick I've reviewed up to this point, with reference to the gles3 spec to see if anything got missed there. I noted that a bunch of things seem to ignore GLES1, but maybe you either didn't care (valid), or something prevented those dispatch init functions from being entered at all in that case. I haven't reviewed the unit test -- it wasn't clear to me where the list of functions came from and whether they should be changed when new extensions are added. pgpn7OPc95Fey.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building the xa-vmwgfx target
On Fri, Sep 7, 2012 at 9:49 PM, Thomas Hellström wrote: > On 9/7/12 10:39 PM, Matt Turner wrote: >> >> I'm converting the remaining static Makefile to automake, so xa and >> xa-vmwgfx is on my todo list. >> >> I'm very confused by the build though. It seems that the xa state >> tracker is built and linked into a single .o file, which is then >> statically linked into xa-vmwgfx. This is reasonably sensible, but >> then we also build a libxatracker.so file which is installed to the >> system that nothing links to. >> >> Can I switch this to xa-vmwgfx linking to a shared libxatracker.so? Or >> perhaps just linking it statically and not installing a libxatracker >> file at all. Either of these seem more like the right thing to do, but >> not being familiar with this code I thought it better to ask. >> >> Thanks, >> Matt > > The xa-vmwgfx target actually builds libxatracker.so, which is a library > used > by external applications, like libGL.so, but currently it works only with > vmware. I really wished you guys had called it libvmwxatracker.so :-) Intending for something to be useful cross-driver and making it useful are very different things and the name should reflect that. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building the xa-vmwgfx target
On Fri, Sep 7, 2012 at 1:49 PM, Thomas Hellström wrote: > On 9/7/12 10:39 PM, Matt Turner wrote: >> >> I'm converting the remaining static Makefile to automake, so xa and >> xa-vmwgfx is on my todo list. >> >> I'm very confused by the build though. It seems that the xa state >> tracker is built and linked into a single .o file, which is then >> statically linked into xa-vmwgfx. This is reasonably sensible, but >> then we also build a libxatracker.so file which is installed to the >> system that nothing links to. >> >> Can I switch this to xa-vmwgfx linking to a shared libxatracker.so? Or >> perhaps just linking it statically and not installing a libxatracker >> file at all. Either of these seem more like the right thing to do, but >> not being familiar with this code I thought it better to ask. >> >> Thanks, >> Matt > > The xa-vmwgfx target actually builds libxatracker.so, which is a library > used > by external applications, like libGL.so, but currently it works only with > vmware. > > /Thomas > Ahh, I see. I had thought (probably because I was expecting the result) that xa-vmwgfx built a DDX called *_drv.so. Thanks for your quick response! Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building the xa-vmwgfx target
On 9/7/12 10:39 PM, Matt Turner wrote: I'm converting the remaining static Makefile to automake, so xa and xa-vmwgfx is on my todo list. I'm very confused by the build though. It seems that the xa state tracker is built and linked into a single .o file, which is then statically linked into xa-vmwgfx. This is reasonably sensible, but then we also build a libxatracker.so file which is installed to the system that nothing links to. Can I switch this to xa-vmwgfx linking to a shared libxatracker.so? Or perhaps just linking it statically and not installing a libxatracker file at all. Either of these seem more like the right thing to do, but not being familiar with this code I thought it better to ask. Thanks, Matt The xa-vmwgfx target actually builds libxatracker.so, which is a library used by external applications, like libGL.so, but currently it works only with vmware. /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: avoid GPU doing constant preload from random address
From: Jerome Glisse Previous command stream might have set any of the constant buffer and the previous address might no longer be valid thus GPU might preload constant from random invalid address and possibly triggering lockup. Signed-off-by: Jerome Glisse --- src/gallium/drivers/r600/evergreen_state.c | 20 src/gallium/drivers/r600/r600_state.c | 20 2 files changed, 40 insertions(+) diff --git a/src/gallium/drivers/r600/evergreen_state.c b/src/gallium/drivers/r600/evergreen_state.c index 9a5183e..405d1b0 100644 --- a/src/gallium/drivers/r600/evergreen_state.c +++ b/src/gallium/drivers/r600/evergreen_state.c @@ -2602,6 +2602,26 @@ void evergreen_init_common_regs(struct r600_command_buffer *cb, r600_store_context_reg(cb, R_028848_SQ_PGM_RESOURCES_2_PS, S_028848_SINGLE_ROUND(V_SQ_ROUND_NEAREST_EVEN)); r600_store_context_reg(cb, R_028864_SQ_PGM_RESOURCES_2_VS, S_028864_SINGLE_ROUND(V_SQ_ROUND_NEAREST_EVEN)); + /* to avoid GPU doing any preloading of constant from random address */ + r600_store_context_reg_seq(cb, R_028140_ALU_CONST_BUFFER_SIZE_PS_0, 8); + r600_store_value(cb, 0); /* R_028140_ALU_CONST_BUFFER_SIZE_PS_0 */ + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_context_reg_seq(cb, R_028180_ALU_CONST_BUFFER_SIZE_VS_0, 8); + r600_store_value(cb, 0); /* R_028180_ALU_CONST_BUFFER_SIZE_VS_0 */ + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_context_reg(cb, R_028354_SX_SURFACE_SYNC, S_028354_SURFACE_SYNC_MASK(0xf)); return; diff --git a/src/gallium/drivers/r600/r600_state.c b/src/gallium/drivers/r600/r600_state.c index ccafdc6..b363dc1 100644 --- a/src/gallium/drivers/r600/r600_state.c +++ b/src/gallium/drivers/r600/r600_state.c @@ -2381,6 +2381,26 @@ void r600_init_atom_start_cs(struct r600_context *rctx) r600_store_value(cb, 0); /* R_0288C4_SQ_REDUC_RING_ITEMSIZE */ r600_store_value(cb, 0); /* R_0288C8_SQ_GS_VERT_ITEMSIZE */ + /* to avoid GPU doing any preloading of constant from random address */ + r600_store_context_reg_seq(cb, R_028140_ALU_CONST_BUFFER_SIZE_PS_0, 8); + r600_store_value(cb, 0); /* R_028140_ALU_CONST_BUFFER_SIZE_PS_0 */ + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_context_reg_seq(cb, R_028180_ALU_CONST_BUFFER_SIZE_VS_0, 8); + r600_store_value(cb, 0); /* R_028180_ALU_CONST_BUFFER_SIZE_VS_0 */ + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_value(cb, 0); + r600_store_context_reg_seq(cb, R_028A10_VGT_OUTPUT_PATH_CNTL, 13); r600_store_value(cb, 0); /* R_028A10_VGT_OUTPUT_PATH_CNTL */ r600_store_value(cb, 0); /* R_028A14_VGT_HOS_CNTL */ -- 1.7.11.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Building the xa-vmwgfx target
I'm converting the remaining static Makefile to automake, so xa and xa-vmwgfx is on my todo list. I'm very confused by the build though. It seems that the xa state tracker is built and linked into a single .o file, which is then statically linked into xa-vmwgfx. This is reasonably sensible, but then we also build a libxatracker.so file which is installed to the system that nothing links to. Can I switch this to xa-vmwgfx linking to a shared libxatracker.so? Or perhaps just linking it statically and not installing a libxatracker file at all. Either of these seem more like the right thing to do, but not being familiar with this code I thought it better to ask. Thanks, Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Allow primitive restart on Haswell for additional primitive types.
These are supported in hardware; no need for software fallbacks.
Not actually hit in any of our test cases, since they appear to count
primitives generated which currently causes software fallbacks anyway.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_primitive_restart.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_primitive_restart.c
b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
index 38b5243..fc36897 100644
--- a/src/mesa/drivers/dri/i965/brw_primitive_restart.c
+++ b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
@@ -79,6 +79,7 @@ can_cut_index_handle_prims(struct gl_context *ctx,
const struct _mesa_index_buffer *ib)
{
struct brw_context *brw = brw_context(ctx);
+ struct intel_context *intel = intel_context(ctx);
if (brw->sol.counting_primitives_generated ||
brw->sol.counting_primitives_written) {
@@ -105,19 +106,18 @@ can_cut_index_handle_prims(struct gl_context *ctx,
case GL_TRIANGLES:
case GL_TRIANGLE_STRIP:
/* Cut index supports these primitive types */
- break;
- default:
- /* Cut index does not support these primitive types */
- //case GL_LINE_LOOP:
- //case GL_TRIANGLE_FAN:
- //case GL_QUADS:
- //case GL_QUAD_STRIP:
- //case GL_POLYGON:
- return false;
+ return true;
+ case GL_LINE_LOOP:
+ case GL_TRIANGLE_FAN:
+ case GL_QUADS:
+ case GL_QUAD_STRIP:
+ case GL_POLYGON:
+ /* Haswell supports cut index on additional primitive types */
+ return intel->is_haswell;
}
}
- return true;
+ return false;
}
/**
--
1.7.11.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Disable building of d3d1x
On Fri, Sep 7, 2012 at 9:28 AM, Jose Fonseca wrote: > - Original Message - >> On Fri, Sep 7, 2012 at 3:30 AM, Jose Fonseca >> wrote: >> > - Original Message - >> >> On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca >> >> >> >> wrote: >> >> > Matt, >> >> > >> >> > I see you went ahead and just disabled it. Please remove it all >> >> > together. >> >> > >> >> > Touching code that is not built nor tested ends just silently >> >> > introduces bugs, so keeping this around won't help bring it back >> >> > one day in any way. >> >> > >> >> > Jose >> >> >> >> I talked with both Marek and Christoph, and they both said they'd >> >> prefer to simply disable the build. I don't feel strongly, but if >> >> someone is to revive it it'd be nice if we didn't make the git >> >> history >> >> harder to follow. >> > >> > I suppose they have their arguments, and I hope they include making >> > this build again shortly. What I don't understand is why these >> > talks didn't happen within this email thread. I'd expect at least >> > a heads up email before committing this... >> >> I don't know why they didn't respond via email. >> >> It's not like we can't still remove d3d1x... > > Matt, Christoph, Marek, thanks for your replies. > > It doesn't sound like anybody plans to work on it on the immediate future, > though it appears to be some faint wish to work on it eventually. So removing > it now; or wait a little longer and removing it if nobody touches it, either > is fine by me. > > Concerning other candidates for removal, it needs to be evaluated > case-by-case. > > Jose An option I haven't thought of until now is removing it from the 9.0 branch, but leaving it in master at least for now. I'm okay with removing it. I'm not planning to convert its static Makefiles into automake. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Set OSMESA_VERSION=8.
On 9/1/12 7:35 PM, Johannes Obermayr wrote: VERSION_NUMBER is not required anymore. So it will be removed. Applied, thanks. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Remove VAAPI support.
Not working and unmaintained.
---
Only included in this diff are changes to the files (actually, just
configure.ac) that we're keeping.
configure.ac | 42 +--
src/gallium/state_trackers/va/Makefile| 26
src/gallium/state_trackers/va/ftab.c | 136 -
src/gallium/state_trackers/va/htab.c | 95 ---
src/gallium/state_trackers/va/va_buffer.c | 88 -
src/gallium/state_trackers/va/va_config.c | 121 --
src/gallium/state_trackers/va/va_context.c| 105
src/gallium/state_trackers/va/va_display.c| 63 --
src/gallium/state_trackers/va/va_image.c | 151 ---
src/gallium/state_trackers/va/va_picture.c| 60 -
src/gallium/state_trackers/va/va_private.h| 162 -
src/gallium/state_trackers/va/va_subpicture.c | 143 --
src/gallium/state_trackers/va/va_surface.c| 142 --
src/gallium/targets/Makefile.va | 73 ---
src/gallium/targets/va-r300/Makefile | 26
src/gallium/targets/va-r300/target.c | 24
src/gallium/targets/va-r600/Makefile | 26
src/gallium/targets/va-r600/target.c | 24
src/gallium/targets/va-softpipe/Makefile | 21 ---
19 files changed, 4 insertions(+), 1524 deletions(-)
delete mode 100644 src/gallium/state_trackers/va/Makefile
delete mode 100644 src/gallium/state_trackers/va/ftab.c
delete mode 100644 src/gallium/state_trackers/va/htab.c
delete mode 100644 src/gallium/state_trackers/va/va_buffer.c
delete mode 100644 src/gallium/state_trackers/va/va_config.c
delete mode 100644 src/gallium/state_trackers/va/va_context.c
delete mode 100644 src/gallium/state_trackers/va/va_display.c
delete mode 100644 src/gallium/state_trackers/va/va_image.c
delete mode 100644 src/gallium/state_trackers/va/va_picture.c
delete mode 100644 src/gallium/state_trackers/va/va_private.h
delete mode 100644 src/gallium/state_trackers/va/va_subpicture.c
delete mode 100644 src/gallium/state_trackers/va/va_surface.c
delete mode 100644 src/gallium/targets/Makefile.va
delete mode 100644 src/gallium/targets/va-r300/Makefile
delete mode 100644 src/gallium/targets/va-r300/target.c
delete mode 100644 src/gallium/targets/va-r600/Makefile
delete mode 100644 src/gallium/targets/va-r600/target.c
delete mode 100644 src/gallium/targets/va-softpipe/Makefile
diff --git a/configure.ac b/configure.ac
index 8b061b9..440fee3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -579,11 +579,6 @@ AC_ARG_ENABLE([vdpau],
[enable vdpau library @<:@default=auto@:>@])],
[enable_vdpau="$enableval"],
[enable_vdpau=auto])
-AC_ARG_ENABLE([va],
- [AS_HELP_STRING([--enable-va],
- [enable va library @<:@default=auto@:>@])],
- [enable_va="$enableval"],
- [enable_va=auto])
AC_ARG_ENABLE([opencl],
[AS_HELP_STRING([--enable-opencl],
[enable OpenCL library @<:@default=no@:>@])],
@@ -647,7 +642,6 @@ if test "x$enable_opengl" = xno -a \
"x$enable_xa" = xno -a \
"x$enable_xvmc" = xno -a \
"x$enable_vdpau" = xno -a \
-"x$enable_va" = xno -a \
"x$enable_opencl" = xno; then
AC_MSG_ERROR([at least one API should be enabled])
fi
@@ -1374,12 +1368,6 @@ if test "x$enable_gallium_g3dvl" = xyes; then
if test "x$enable_vdpau" = xauto; then
PKG_CHECK_EXISTS([vdpau], [enable_vdpau=yes], [enable_vdpau=no])
fi
-
-if test "x$enable_va" = xauto; then
- #don't enable vaapi state tracker even if package exists
- #PKG_CHECK_EXISTS([libva], [enable_vdpau=yes], [enable_vdpau=no])
-enable_va=no
-fi
fi
if test "x$enable_xvmc" = xyes; then
@@ -1394,13 +1382,6 @@ if test "x$enable_vdpau" = xyes; then
HAVE_ST_VDPAU="yes"
fi
-if test "x$enable_va" = xyes; then
-PKG_CHECK_MODULES([LIBVA], [libva = 0.31.1 x11-xcb xcb-dri2 >= 1.8])
-AC_MSG_WARN([vaapi state tracker currently unmaintained])
-GALLIUM_STATE_TRACKERS_DIRS="$GALLIUM_STATE_TRACKERS_DIRS va"
-HAVE_ST_VA="yes"
-fi
-
dnl
dnl OpenCL configuration
dnl
@@ -1682,14 +1663,6 @@ AC_ARG_WITH([vdpau-libdir],
[VDPAU_LIB_INSTALL_DIR='${libdir}/vdpau'])
AC_SUBST([VDPAU_LIB_INSTALL_DIR])
-dnl Directory for VA libs
-AC_ARG_WITH([va-libdir],
-[AS_HELP_STRING([--with-va-libdir=DIR],
-[directory for the VA libraries @<:@default=${libdir}/va@:>@])],
-[VA_LIB_INSTALL_DIR="$withval"],
-[VA_LIB_INSTALL_DIR='${libdir}/va'])
-AC_SUBST([VA_LIB_INSTALL_DIR])
-
dnl Directory for OpenCL libs
AC_ARG_WITH([opencl-libdir],
[AS_HELP_STRING([--with-opencl-libdir=DIR],
@@ -1704,7 +1677,7 @@ dnl
gallium_check_st() {
if test "x$HAVE_ST_DRI" = xyes || test "x$HAVE_ST_XORG" = xyes ||
test "x$HAVE_ST_XA" = xyes || test "x$HAVE_ST_XVMC" = xyes ||
-test "x$HAVE_ST_VDPAU"
[Mesa-dev] [PATCH 10/10] radeon/llvm: Fix operand order of V_CNDMASK in custom inserter
From: Tom Stellard --- src/gallium/drivers/radeon/SIISelLowering.cpp |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/radeon/SIISelLowering.cpp b/src/gallium/drivers/radeon/SIISelLowering.cpp index 42c2e7f..3f23949 100644 --- a/src/gallium/drivers/radeon/SIISelLowering.cpp +++ b/src/gallium/drivers/radeon/SIISelLowering.cpp @@ -261,8 +261,8 @@ void SITargetLowering::LowerSI_V_CNDLT(MachineInstr *MI, MachineBasicBlock &BB, BuildMI(BB, I, BB.findDebugLoc(I), TII->get(AMDGPU::V_CNDMASK_B32)) .addOperand(MI->getOperand(0)) - .addOperand(MI->getOperand(2)) .addOperand(MI->getOperand(3)) + .addOperand(MI->getOperand(2)) .addReg(AMDGPU::VCC); MI->eraseFromParent(); -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/10] radeon/llvm: Assert if we try to encode an unknown register
From: Tom Stellard
---
src/gallium/drivers/radeon/SIGenRegisterInfo.pl |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
b/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
index 3813eb5..48bd567 100644
--- a/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
+++ b/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
@@ -241,7 +241,7 @@ if ($INDEX_FILE ne '') {
}
print $fh "return $key;\n";
}
- print $fh " default: return 0;\n }\n}\n"
+ print $fh " default: assert(!\"Unknown Register\"); return 0;\n }\n}\n"
}
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/10] radeon/llvm: Add register encoding for VCC
From: Tom Stellard
---
.../radeon/MCTargetDesc/SIMCCodeEmitter.cpp|1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
b/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
index 438d2ac..ca4b579 100644
--- a/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
+++ b/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
@@ -280,6 +280,7 @@ unsigned SIMCCodeEmitter::getEncodingBytes(const MCInst
&MI) const {
unsigned SIMCCodeEmitter::getRegBinaryCode(unsigned reg) const {
switch (reg) {
+case AMDGPU::VCC: return 106;
case AMDGPU::M0: return 124;
case AMDGPU::EXEC: return 126;
case AMDGPU::EXEC_LO: return 126;
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/10] radeon/llvm: Ignore special registers when calculating reg count
From: Tom Stellard
---
src/gallium/drivers/radeon/AMDGPUAsmPrinter.cpp |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/radeon/AMDGPUAsmPrinter.cpp
b/src/gallium/drivers/radeon/AMDGPUAsmPrinter.cpp
index 07f443d..392791c 100644
--- a/src/gallium/drivers/radeon/AMDGPUAsmPrinter.cpp
+++ b/src/gallium/drivers/radeon/AMDGPUAsmPrinter.cpp
@@ -85,6 +85,8 @@ void AMDGPUAsmPrinter::EmitProgramInfo(MachineFunction &MF) {
default: break;
case AMDGPU::EXEC:
case AMDGPU::SI_LITERAL_CONSTANT:
+case AMDGPU::SREG_LIT_0:
+case AMDGPU::M0:
continue;
}
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/10] radeonsi: Handle position input parameter for pixel shaders
From: Tom Stellard
---
src/gallium/drivers/radeon/SIInstructions.td | 20
src/gallium/drivers/radeon/SIIntrinsics.td |2 ++
src/gallium/drivers/radeonsi/radeonsi_shader.c | 16 +++-
src/gallium/drivers/radeonsi/si_state_draw.c | 14 ++
4 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/radeon/SIInstructions.td
b/src/gallium/drivers/radeon/SIInstructions.td
index 8f9de52..ffc9537 100644
--- a/src/gallium/drivers/radeon/SIInstructions.td
+++ b/src/gallium/drivers/radeon/SIInstructions.td
@@ -1102,6 +1102,26 @@ def : Pat <
imm:$attr, SReg_32:$params)
>;
+def : Pat <
+ (int_SI_fs_read_pos 0),
+ (f32 POS_X_FLOAT)
+>;
+
+def : Pat <
+ (int_SI_fs_read_pos 1),
+ (f32 POS_Y_FLOAT)
+>;
+
+def : Pat <
+ (int_SI_fs_read_pos 2),
+ (f32 POS_Z_FLOAT)
+>;
+
+def : Pat <
+ (int_SI_fs_read_pos 3),
+ (f32 POS_W_FLOAT)
+>;
+
/** == **/
/** Intrinsic Patterns **/
/** == **/
diff --git a/src/gallium/drivers/radeon/SIIntrinsics.td
b/src/gallium/drivers/radeon/SIIntrinsics.td
index fbb8dc9..f5c3f76 100644
--- a/src/gallium/drivers/radeon/SIIntrinsics.td
+++ b/src/gallium/drivers/radeon/SIIntrinsics.td
@@ -34,4 +34,6 @@ let TargetPrefix = "SI", isTarget = 1 in {
def int_SI_fs_interp_persp_center : Interp;
def int_SI_fs_interp_persp_centroid : Interp;
def int_SI_fs_interp_constant : Interp;
+
+ def int_SI_fs_read_pos : Intrinsic <[llvm_float_ty], [llvm_i32_ty],
[IntrNoMem]>;
}
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 0994fac..466d565 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
@@ -261,6 +261,7 @@ static void declare_input_fs(
struct lp_build_context * base =
&si_shader_ctx->radeon_bld.soa.bld_base.base;
struct gallivm_state * gallivm = base->gallivm;
+ LLVMTypeRef input_type = LLVMFloatTypeInContext(gallivm->context);
/* This value is:
* [15:0] NewPrimMask (Bit mask for each quad. It is set it the
@@ -278,6 +279,20 @@ static void declare_input_fs(
/* XXX: Is this the input_index? */
LLVMValueRef attr_number = lp_build_const_int32(gallivm, input_index);
+ if (decl->Semantic.Name == TGSI_SEMANTIC_POSITION) {
+ for (chan = 0; chan < TGSI_NUM_CHANNELS; chan++) {
+ LLVMValueRef args[1];
+ unsigned soa_index =
+ radeon_llvm_reg_index_soa(input_index, chan);
+ args[0] = lp_build_const_int32(gallivm, chan);
+ si_shader_ctx->radeon_bld.inputs[soa_index] =
+ build_intrinsic(base->gallivm->builder,
+ "llvm.SI.fs.read.pos", input_type,
+ args, 1, LLVMReadNoneAttribute);
+ }
+ return;
+ }
+
/* XXX: Handle all possible interpolation modes */
switch (decl->Interp.Interpolate) {
case TGSI_INTERPOLATE_COLOR:
@@ -332,7 +347,6 @@ static void declare_input_fs(
LLVMValueRef args[3];
LLVMValueRef llvm_chan = lp_build_const_int32(gallivm, chan);
unsigned soa_index = radeon_llvm_reg_index_soa(input_index,
chan);
- LLVMTypeRef input_type =
LLVMFloatTypeInContext(gallivm->context);
args[0] = llvm_chan;
args[1] = attr_number;
args[2] = params;
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 8b43f5a..2486741 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -103,6 +103,7 @@ static void si_pipe_shader_ps(struct pipe_context *ctx,
struct si_pipe_shader *s
unsigned num_sgprs, num_user_sgprs;
int ninterp = 0;
boolean have_linear = FALSE, have_centroid = FALSE, have_perspective =
FALSE;
+ unsigned fragcoord_interp_mode = 0;
unsigned spi_baryc_cntl, spi_ps_input_ena;
uint64_t va;
@@ -128,6 +129,18 @@ static void si_pipe_shader_ps(struct pipe_context *ctx,
struct si_pipe_shader *s
have_perspective = TRUE;
if (shader->shader.input[i].centroid)
have_centroid = TRUE;
+ if (shader->shader.input[i].name == TGSI_SEMANTIC_POSITION &&
+ shader->shader.input[i].centroid) {
+ /* This value will be written to
+* SPI_BARYC_CNTL.POS_FLOAT_LOCATION
+* Possible vaules:
+* 0 -> Position = pixel center (default)
+* 1 -> Posit
[Mesa-dev] [PATCH 05/10] radeon/llvm: Coding style fixes
From: Tom Stellard
---
src/gallium/drivers/radeon/AMDGPUAsmPrinter.cpp|2 +-
src/gallium/drivers/radeon/SIAssignInterpRegs.cpp | 56 ++--
.../drivers/radeon/SIMachineFunctionInfo.cpp |2 +-
src/gallium/drivers/radeon/SIMachineFunctionInfo.h |2 +-
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/src/gallium/drivers/radeon/AMDGPUAsmPrinter.cpp
b/src/gallium/drivers/radeon/AMDGPUAsmPrinter.cpp
index 2d6c86d..07f443d 100644
--- a/src/gallium/drivers/radeon/AMDGPUAsmPrinter.cpp
+++ b/src/gallium/drivers/radeon/AMDGPUAsmPrinter.cpp
@@ -128,5 +128,5 @@ void AMDGPUAsmPrinter::EmitProgramInfo(MachineFunction &MF)
{
SIMachineFunctionInfo * MFI = MF.getInfo();
OutStreamer.EmitIntValue(MaxSGPR + 1, 4);
OutStreamer.EmitIntValue(MaxVGPR + 1, 4);
- OutStreamer.EmitIntValue(MFI->spi_ps_input_addr, 4);
+ OutStreamer.EmitIntValue(MFI->SPIPSInputAddr, 4);
}
diff --git a/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
b/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
index 0e36e6b..1fc0a87 100644
--- a/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
+++ b/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
@@ -35,7 +35,7 @@ private:
static char ID;
TargetMachine &TM;
- void AddLiveIn(MachineFunction * MF, MachineRegisterInfo & MRI,
+ void addLiveIn(MachineFunction * MF, MachineRegisterInfo & MRI,
unsigned physReg, unsigned virtReg);
public:
@@ -54,10 +54,10 @@ char SIAssignInterpRegsPass::ID = 0;
#define INTERP_VALUES 16
#define REQUIRED_VALUE_MAX_INDEX 7
-struct interp_info {
- bool enabled;
- unsigned regs[3];
- unsigned reg_count;
+struct InterpInfo {
+ bool Enabled;
+ unsigned Regs[3];
+ unsigned RegCount;
};
@@ -68,7 +68,7 @@ FunctionPass
*llvm::createSIAssignInterpRegsPass(TargetMachine &tm) {
bool SIAssignInterpRegsPass::runOnMachineFunction(MachineFunction &MF)
{
- struct interp_info InterpUse[INTERP_VALUES] = {
+ struct InterpInfo InterpUse[INTERP_VALUES] = {
{false, {AMDGPU::PERSP_SAMPLE_I, AMDGPU::PERSP_SAMPLE_J}, 2},
{false, {AMDGPU::PERSP_CENTER_I, AMDGPU::PERSP_CENTER_J}, 2},
{false, {AMDGPU::PERSP_CENTROID_I, AMDGPU::PERSP_CENTROID_J}, 2},
@@ -95,14 +95,14 @@ bool
SIAssignInterpRegsPass::runOnMachineFunction(MachineFunction &MF)
MachineRegisterInfo &MRI = MF.getRegInfo();
bool ForceEnable = true;
- /* First pass, mark the interpolation values that are used. */
- for (unsigned interp_idx = 0; interp_idx < INTERP_VALUES; interp_idx++) {
-for (unsigned reg_idx = 0; reg_idx < InterpUse[interp_idx].reg_count;
- reg_idx++) {
- InterpUse[interp_idx].enabled = InterpUse[interp_idx].enabled ||
-
!MRI.use_empty(InterpUse[interp_idx].regs[reg_idx]);
- if (InterpUse[interp_idx].enabled &&
- interp_idx <= REQUIRED_VALUE_MAX_INDEX) {
+ // First pass, mark the interpolation values that are used.
+ for (unsigned InterpIdx = 0; InterpIdx < INTERP_VALUES; InterpIdx++) {
+for (unsigned RegIdx = 0; RegIdx < InterpUse[InterpIdx].RegCount;
+ RegIdx++) {
+ InterpUse[InterpIdx].Enabled = InterpUse[InterpIdx].Enabled ||
+!MRI.use_empty(InterpUse[InterpIdx].Regs[RegIdx]);
+ if (InterpUse[InterpIdx].Enabled &&
+ InterpIdx <= REQUIRED_VALUE_MAX_INDEX) {
ForceEnable = false;
}
}
@@ -110,31 +110,31 @@ bool
SIAssignInterpRegsPass::runOnMachineFunction(MachineFunction &MF)
// At least one interpolation mode must be enabled or else the GPU will hang.
if (ForceEnable) {
-InterpUse[0].enabled = true;
+InterpUse[0].Enabled = true;
}
- unsigned used_vgprs = 0;
+ unsigned UsedVgprs = 0;
- /* Second pass, replace with VGPRs. */
- for (unsigned interp_idx = 0; interp_idx < INTERP_VALUES; interp_idx++) {
-if (!InterpUse[interp_idx].enabled) {
+ // Second pass, replace with VGPRs.
+ for (unsigned InterpIdx = 0; InterpIdx < INTERP_VALUES; InterpIdx++) {
+if (!InterpUse[InterpIdx].Enabled) {
continue;
}
-MFI->spi_ps_input_addr |= (1 << interp_idx);
-
-for (unsigned reg_idx = 0; reg_idx < InterpUse[interp_idx].reg_count;
- reg_idx++, used_vgprs++) {
- unsigned new_reg = AMDGPU::VReg_32RegClass.getRegister(used_vgprs);
- unsigned virt_reg = MRI.createVirtualRegister(&AMDGPU::VReg_32RegClass);
- MRI.replaceRegWith(InterpUse[interp_idx].regs[reg_idx], virt_reg);
- AddLiveIn(&MF, MRI, new_reg, virt_reg);
+MFI->SPIPSInputAddr |= (1 << InterpIdx);
+
+for (unsigned RegIdx = 0; RegIdx < InterpUse[InterpIdx].RegCount;
+ RegIdx++, UsedVgprs++) {
+ unsigned NewReg = AMDGPU::VReg_32RegClass.getRegister(UsedVgprs);
+ unsigned VirtReg = MRI.createVirtualRegister(&AMDGPU::VReg_
[Mesa-dev] [PATCH 04/10] radeonsi: Move interpolation mode check into the compiler
From: Tom Stellard
The compiler needs to know which interpolation modes are enabled, so
it knows which values will be preloaded into the VGPRs.
---
src/gallium/drivers/radeon/SIAssignInterpRegs.cpp | 13 -
src/gallium/drivers/radeonsi/si_state_draw.c | 20 +---
2 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
b/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
index 447eff6..0e36e6b 100644
--- a/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
+++ b/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
@@ -52,6 +52,7 @@ public:
char SIAssignInterpRegsPass::ID = 0;
#define INTERP_VALUES 16
+#define REQUIRED_VALUE_MAX_INDEX 7
struct interp_info {
bool enabled;
@@ -92,16 +93,26 @@ bool
SIAssignInterpRegsPass::runOnMachineFunction(MachineFunction &MF)
return false;
}
MachineRegisterInfo &MRI = MF.getRegInfo();
+ bool ForceEnable = true;
/* First pass, mark the interpolation values that are used. */
for (unsigned interp_idx = 0; interp_idx < INTERP_VALUES; interp_idx++) {
for (unsigned reg_idx = 0; reg_idx < InterpUse[interp_idx].reg_count;
reg_idx++) {
- InterpUse[interp_idx].enabled =
+ InterpUse[interp_idx].enabled = InterpUse[interp_idx].enabled ||
!MRI.use_empty(InterpUse[interp_idx].regs[reg_idx]);
+ if (InterpUse[interp_idx].enabled &&
+ interp_idx <= REQUIRED_VALUE_MAX_INDEX) {
+ForceEnable = false;
+ }
}
}
+ // At least one interpolation mode must be enabled or else the GPU will hang.
+ if (ForceEnable) {
+InterpUse[0].enabled = true;
+ }
+
unsigned used_vgprs = 0;
/* Second pass, replace with VGPRs. */
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 8f6dde0..8b43f5a 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -170,17 +170,15 @@ static void si_pipe_shader_ps(struct pipe_context *ctx,
struct si_pipe_shader *s
si_pm4_set_reg(pm4, R_0286E0_SPI_BARYC_CNTL, spi_baryc_cntl);
spi_ps_input_ena = shader->spi_ps_input_ena;
/* we need to enable at least one of them, otherwise we hang the GPU */
- if (!G_0286CC_PERSP_SAMPLE_ENA(spi_ps_input_ena) &&
- !G_0286CC_PERSP_CENTER_ENA(spi_ps_input_ena) &&
- !G_0286CC_PERSP_CENTROID_ENA(spi_ps_input_ena) &&
- !G_0286CC_PERSP_PULL_MODEL_ENA(spi_ps_input_ena) &&
- !G_0286CC_LINEAR_SAMPLE_ENA(spi_ps_input_ena) &&
- !G_0286CC_LINEAR_CENTER_ENA(spi_ps_input_ena) &&
- !G_0286CC_LINEAR_CENTROID_ENA(spi_ps_input_ena) &&
- !G_0286CC_LINE_STIPPLE_TEX_ENA(spi_ps_input_ena)) {
-
- spi_ps_input_ena |= S_0286CC_PERSP_SAMPLE_ENA(1);
- }
+ assert(G_0286CC_PERSP_SAMPLE_ENA(spi_ps_input_ena) ||
+ G_0286CC_PERSP_CENTER_ENA(spi_ps_input_ena) ||
+ G_0286CC_PERSP_CENTROID_ENA(spi_ps_input_ena) ||
+ G_0286CC_PERSP_PULL_MODEL_ENA(spi_ps_input_ena) ||
+ G_0286CC_LINEAR_SAMPLE_ENA(spi_ps_input_ena) ||
+ G_0286CC_LINEAR_CENTER_ENA(spi_ps_input_ena) ||
+ G_0286CC_LINEAR_CENTROID_ENA(spi_ps_input_ena) ||
+ G_0286CC_LINE_STIPPLE_TEX_ENA(spi_ps_input_ena));
+
si_pm4_set_reg(pm4, R_0286CC_SPI_PS_INPUT_ENA, spi_ps_input_ena);
si_pm4_set_reg(pm4, R_0286D0_SPI_PS_INPUT_ADDR, spi_ps_input_ena);
si_pm4_set_reg(pm4, R_0286D8_SPI_PS_IN_CONTROL, spi_ps_in_control);
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] radeonsi: Add missing interpolation mode to check for enabled modes
From: Tom Stellard At least one interpolation mode must be enable, but the code that checks this was not checking for perspective center. --- src/gallium/drivers/radeonsi/si_state_draw.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c b/src/gallium/drivers/radeonsi/si_state_draw.c index 75df4e8..8f6dde0 100644 --- a/src/gallium/drivers/radeonsi/si_state_draw.c +++ b/src/gallium/drivers/radeonsi/si_state_draw.c @@ -171,6 +171,7 @@ static void si_pipe_shader_ps(struct pipe_context *ctx, struct si_pipe_shader *s spi_ps_input_ena = shader->spi_ps_input_ena; /* we need to enable at least one of them, otherwise we hang the GPU */ if (!G_0286CC_PERSP_SAMPLE_ENA(spi_ps_input_ena) && + !G_0286CC_PERSP_CENTER_ENA(spi_ps_input_ena) && !G_0286CC_PERSP_CENTROID_ENA(spi_ps_input_ena) && !G_0286CC_PERSP_PULL_MODEL_ENA(spi_ps_input_ena) && !G_0286CC_LINEAR_SAMPLE_ENA(spi_ps_input_ena) && -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/10] radeonsi: Pass shader type to the compiler
From: Tom Stellard
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 9fc3446..0994fac 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
@@ -476,6 +476,17 @@ static void si_llvm_init_export_args(struct
lp_build_tgsi_context *bld_base,
* stage. */
}
+static void si_llvm_emit_prologue(struct lp_build_tgsi_context *bld_base)
+{
+ struct si_shader_context *si_shader_ctx = si_shader_context(bld_base);
+ struct gallivm_state *gallivm = bld_base->base.gallivm;
+ lp_build_intrinsic_unary(gallivm->builder,
+ "llvm.AMDGPU.shader.type",
+ LLVMVoidTypeInContext(gallivm->context),
+ lp_build_const_int32(gallivm, si_shader_ctx->type));
+}
+
+
/* XXX: This is partially implemented for VS only at this point. It is not
complete */
static void si_llvm_emit_epilogue(struct lp_build_tgsi_context * bld_base)
{
@@ -705,6 +716,7 @@ int si_pipe_shader_create(
tgsi_scan_shader(sel->tokens, &shader_info);
bld_base->info = &shader_info;
bld_base->emit_fetch_funcs[TGSI_FILE_CONSTANT] = fetch_constant;
+ bld_base->emit_prologue = si_llvm_emit_prologue;
bld_base->emit_epilogue = si_llvm_emit_epilogue;
bld_base->op_actions[TGSI_OPCODE_TEX] = tex_action;
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/10] radeon/llvm: Add SHADER_TYPE instruction
From: Tom Stellard
This allows the program to specify the type of shader being compiled
(e.g. PXEL, VERTEX, etc.)
---
src/gallium/drivers/radeon/AMDGPU.h|9 +
src/gallium/drivers/radeon/AMDGPUInstructions.td |7 +++
src/gallium/drivers/radeon/AMDGPUIntrinsics.td |2 ++
src/gallium/drivers/radeon/R600ISelLowering.cpp|1 +
src/gallium/drivers/radeon/SIAssignInterpRegs.cpp |4
src/gallium/drivers/radeon/SIISelLowering.cpp |6 ++
.../drivers/radeon/SIMachineFunctionInfo.cpp |3 ++-
src/gallium/drivers/radeon/SIMachineFunctionInfo.h |1 +
8 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/radeon/AMDGPU.h
b/src/gallium/drivers/radeon/AMDGPU.h
index ab6871c..fe36545 100644
--- a/src/gallium/drivers/radeon/AMDGPU.h
+++ b/src/gallium/drivers/radeon/AMDGPU.h
@@ -33,4 +33,13 @@ FunctionPass *createAMDGPUConvertToISAPass(TargetMachine
&tm);
} // End namespace llvm
+namespace ShaderType {
+ enum Type {
+PIXEL = 0,
+VERTEX = 1,
+GEOMETRY = 2,
+COMPUTE = 3
+ };
+}
+
#endif // AMDGPU_H
diff --git a/src/gallium/drivers/radeon/AMDGPUInstructions.td
b/src/gallium/drivers/radeon/AMDGPUInstructions.td
index c8a7db6..6f47445 100644
--- a/src/gallium/drivers/radeon/AMDGPUInstructions.td
+++ b/src/gallium/drivers/radeon/AMDGPUInstructions.td
@@ -114,6 +114,13 @@ class FNEG : AMDGPUShaderInst <
[(set rc:$dst, (fneg rc:$src0))]
>;
+def SHADER_TYPE : AMDGPUShaderInst <
+ (outs),
+ (ins i32imm:$type),
+ "SHADER_TYPE $type",
+ [(int_AMDGPU_shader_type imm:$type)]
+>;
+
} // End isCodeGenOnly = 1, isPseudo = 1, hasCustomInserter = 1
/* Generic helper patterns for intrinsics */
diff --git a/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
b/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
index 89cc7e1..958e0bd 100644
--- a/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
+++ b/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
@@ -54,6 +54,8 @@ let TargetPrefix = "AMDGPU", isTarget = 1 in {
def int_AMDGPU_umax : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
[IntrNoMem]>;
def int_AMDGPU_umin : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
[IntrNoMem]>;
def int_AMDGPU_cube : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty],
[IntrNoMem]>;
+
+ def int_AMDGPU_shader_type : Intrinsic<[], [llvm_i32_ty], []>;
}
let TargetPrefix = "TGSI", isTarget = 1 in {
diff --git a/src/gallium/drivers/radeon/R600ISelLowering.cpp
b/src/gallium/drivers/radeon/R600ISelLowering.cpp
index 5642ee8..5a82920 100644
--- a/src/gallium/drivers/radeon/R600ISelLowering.cpp
+++ b/src/gallium/drivers/radeon/R600ISelLowering.cpp
@@ -61,6 +61,7 @@ MachineBasicBlock *
R600TargetLowering::EmitInstrWithCustomInserter(
switch (MI->getOpcode()) {
default: return AMDGPUTargetLowering::EmitInstrWithCustomInserter(MI, BB);
+ case AMDGPU::SHADER_TYPE: break;
case AMDGPU::CLAMP_R600:
{
MachineInstr *NewMI =
diff --git a/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
b/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
index 3ee03ae..447eff6 100644
--- a/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
+++ b/src/gallium/drivers/radeon/SIAssignInterpRegs.cpp
@@ -87,6 +87,10 @@ bool
SIAssignInterpRegsPass::runOnMachineFunction(MachineFunction &MF)
};
SIMachineFunctionInfo * MFI = MF.getInfo();
+ // This pass is only needed for pixel shaders.
+ if (MFI->ShaderType != ShaderType::PIXEL) {
+return false;
+ }
MachineRegisterInfo &MRI = MF.getRegInfo();
/* First pass, mark the interpolation values that are used. */
diff --git a/src/gallium/drivers/radeon/SIISelLowering.cpp
b/src/gallium/drivers/radeon/SIISelLowering.cpp
index ebe9514..42c2e7f 100644
--- a/src/gallium/drivers/radeon/SIISelLowering.cpp
+++ b/src/gallium/drivers/radeon/SIISelLowering.cpp
@@ -16,6 +16,7 @@
#include "AMDIL.h"
#include "AMDILIntrinsicInfo.h"
#include "SIInstrInfo.h"
+#include "SIMachineFunctionInfo.h"
#include "SIRegisterInfo.h"
#include "llvm/CodeGen/MachineInstrBuilder.h"
#include "llvm/CodeGen/MachineRegisterInfo.h"
@@ -122,6 +123,11 @@ MachineBasicBlock *
SITargetLowering::EmitInstrWithCustomInserter(
.addImm(1); // NEG
MI->eraseFromParent();
break;
+ case AMDGPU::SHADER_TYPE:
+BB->getParent()->getInfo()->ShaderType =
+MI->getOperand(0).getImm();
+MI->eraseFromParent();
+break;
case AMDGPU::SI_INTERP:
LowerSI_INTERP(MI, *BB, I, MRI);
diff --git a/src/gallium/drivers/radeon/SIMachineFunctionInfo.cpp
b/src/gallium/drivers/radeon/SIMachineFunctionInfo.cpp
index 40ba76f..f1a8c1f 100644
--- a/src/gallium/drivers/radeon/SIMachineFunctionInfo.cpp
+++ b/src/gallium/drivers/radeon/SIMachineFunctionInfo.cpp
@@ -14,5 +14,6 @@ using namespace llvm;
SIMachineFunctionInfo::SIMachineFunctionInfo(const MachineFunction &MF)
: MachineFunctionInfo(),
-spi_ps_input_addr(0)
+spi_ps_in
[Mesa-dev] radeonsi: Flow Control preperation patches
Hi, The series is a prerequisite for flow control support on radeonsi. Flow control for If-Then-Else blocks is mostly implemented, but I'm still trying to debug some GPU hangs that it is causing. -Tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/12] i965/blorp: Clarify why width/height must be adjusted for Gen6 IMS surfaces.
On 7 September 2012 09:27, Eric Anholt wrote: > Paul Berry writes: > > > Also add a clarifying comment for why the width/height doesn't need > > adjustment for Gen7. > > > diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp > b/src/mesa/drivers/dri/i965/gen7_blorp.cpp > > index a65a975..ff11f3a 100644 > > --- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp > > +++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp > > @@ -144,6 +144,11 @@ gen7_blorp_emit_surface_state(struct brw_context > *brw, > > uint32_t wm_surf_offset; > > uint32_t width, height; > > surface->get_miplevel_dims(&width, &height); > > + /* Note: since gen7 uses INTEL_MSAA_LAYOUT_CMS or > INTEL_MSAA_LAYOUT_IMS for > > Is that supposed to be s/IMS/UMS/? > Oops, yes. I'll flx that before pushing. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/12] i965/blorp: Account for offsets when emitting SURFACE_STATE.
Paul Berry writes:
> Fixes piglit tests "framebuffer-blit-levels {read,draw} depth".
>
> NOTE: This is a candidate for stable release branches.
Up through this patch:
Reviewed-by: Eric Anholt
After this one, just acked.
pgpRkSCvr3zqi.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/12] i965/blorp: store x and y offsets in brw_blorp_mip_info.
Paul Berry writes:
> Currently, gen{6,7}_blorp_emit_surface_state assumes that the src and
> dst surfaces are mapped to miplevel 0 and layer 0 (thus no surface
> offset is required). This is a bug, since the user might try to blit
> to and from levels/layers other than 0.
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp
> b/src/mesa/drivers/dri/i965/brw_blorp.cpp
> index 7322a04..6acc591 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
> this->mt = mt;
> - this->level = level;
> - this->layer = layer;
> this->width = mt->level[level].width;
> this->height = mt->level[level].height;
> +
> + /* Construct a dummy renderbuffer just to extract tile offsets. */
> + struct intel_renderbuffer rb;
> + rb.mt = mt;
> + rb.mt_level = level;
> + rb.mt_layer = layer;
> + intel_renderbuffer_set_draw_offset(&rb);
> + x_offset = rb.draw_x;
> + y_offset = rb.draw_y;
I know you're just moving the code here, but as a fixup, please just use
intel_miptree_get_image_offset directly.
pgpBuOuuWQ2JA.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Disable building of d3d1x
- Original Message - > On Fri, Sep 7, 2012 at 3:30 AM, Jose Fonseca > wrote: > > - Original Message - > >> On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca > >> > >> wrote: > >> > Matt, > >> > > >> > I see you went ahead and just disabled it. Please remove it all > >> > together. > >> > > >> > Touching code that is not built nor tested ends just silently > >> > introduces bugs, so keeping this around won't help bring it back > >> > one day in any way. > >> > > >> > Jose > >> > >> I talked with both Marek and Christoph, and they both said they'd > >> prefer to simply disable the build. I don't feel strongly, but if > >> someone is to revive it it'd be nice if we didn't make the git > >> history > >> harder to follow. > > > > I suppose they have their arguments, and I hope they include making > > this build again shortly. What I don't understand is why these > > talks didn't happen within this email thread. I'd expect at least > > a heads up email before committing this... > > I don't know why they didn't respond via email. > > It's not like we can't still remove d3d1x... Matt, Christoph, Marek, thanks for your replies. It doesn't sound like anybody plans to work on it on the immediate future, though it appears to be some faint wish to work on it eventually. So removing it now; or wait a little longer and removing it if nobody touches it, either is fine by me. Concerning other candidates for removal, it needs to be evaluated case-by-case. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/12] i965/blorp: Clarify why width/height must be adjusted for Gen6 IMS surfaces.
Paul Berry writes: > Also add a clarifying comment for why the width/height doesn't need > adjustment for Gen7. > diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp > b/src/mesa/drivers/dri/i965/gen7_blorp.cpp > index a65a975..ff11f3a 100644 > --- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp > +++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp > @@ -144,6 +144,11 @@ gen7_blorp_emit_surface_state(struct brw_context *brw, > uint32_t wm_surf_offset; > uint32_t width, height; > surface->get_miplevel_dims(&width, &height); > + /* Note: since gen7 uses INTEL_MSAA_LAYOUT_CMS or INTEL_MSAA_LAYOUT_IMS > for Is that supposed to be s/IMS/UMS/? pgp8J9F1rnsRG.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] i965/gen6+: Adjust stencil buffer size after computing miptree layout.
Paul Berry writes: > Since Gen6+ stencil buffers use W-tiling (a tiling arrangement which > drm and the kernel are not aware of) we need to round up the width and > height of a stencil buffer to multiples of the W-tile size (64x64) > before allocating a stencil buffer. Previously, we rounded up the > size of the base miplevel, and then computed the miptree layout based > on the rounded up size. This was incorrect, because it meant that the > total size of the miptree would not be properly W-tile aligned, and > therefore we would not always allocate enough pages. > > (Note: even though the GL API doesn't allow creation of mipmapped > stencil textures, it does allow mipmapping of a combined depth/stencil > texture, and on Gen6+, a combined depth/stencil texture is internally > implemented as a pair of separate depth and stencil buffers.) > > For example, on Sandy Bridge, when allocating a mipmapped stencil > texture of size 128x128, we would first round up to the nearest > multiple of 64x64 (causing no change to the size), and then compute > the miptree layout (whose size worked out to 128x196). Then we would > request an allocation of 128*196 bytes (6.125 pages), causing 7 pages > to be allocated to the texture. However, the texture needs 8 pages, > since each W-tile occupies a page, and it takes 2 W-tiles to cover a > width of 128 and 4 W-tiles to cover a height of 196. > > This patch changes the order of operations so that the miptree layout > is computed first and then the total size of the miptree is rounded up > to be W-tile aligned. I had a similar patch, so either variation gets my r-b. (mt->total_* are only used for communicating the size of the region to be requested, so the alignment can be done in place) pgpJ7fRkrBuk0.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Disable building of d3d1x
On Fri, Sep 7, 2012 at 8:19 AM, Matt Turner wrote: > On Fri, Sep 7, 2012 at 3:30 AM, Jose Fonseca wrote: >> - Original Message - >>> On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca >>> wrote: >>> > Matt, >>> > >>> > I see you went ahead and just disabled it. Please remove it all >>> > together. >>> > >>> > Touching code that is not built nor tested ends just silently >>> > introduces bugs, so keeping this around won't help bring it back >>> > one day in any way. >>> > >>> > Jose >>> >>> I talked with both Marek and Christoph, and they both said they'd >>> prefer to simply disable the build. I don't feel strongly, but if >>> someone is to revive it it'd be nice if we didn't make the git >>> history >>> harder to follow. >> >> I suppose they have their arguments, and I hope they include making this >> build again shortly. What I don't understand is why these talks didn't >> happen within this email thread. I'd expect at least a heads up email before >> committing this... > > I don't know why they didn't respond via email. > > It's not like we can't still remove d3d1x... > >>> Applying your reasoning (which I tend to agree with) to some other >>> parts of Gallium makes for interesting conversation. The VAAPI state >>> tracker and targets aren't built. Should we also nuke them? How about >>> something like the xorg-i915 target (which installs a >>> 'modesetting_drv.so')? >> >> I don't know enough about this code or the ongoing autotool-ification >> process to tell whether this is a short term or long term condition. > > VAAPI is disabled in the build system because it doesn't work. > >> But yes, In general I see no point in carrying around stuff that doesn't >> minimally work or can't even be built. If something is unusable/unmaintained >> over one Mesa release cycle, then it should be chopped off. Every dead code >> we remove means that cleanups and refactorings of the good code becomes >> easier. And if it is broken, then there's no loss to the end user either. >> >> This is not the first or last time we'd remove code BTW. There are many >> precedents. > > I know. I'm asking about things that are currently disabled (VAAPI > stuff) or are of questionable use (xorg-i915). Make sure you check with Jakob first, but I'm fine with removing xorg-i915. I don't think it has worked properly in a while. Stéphane ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Disable building of d3d1x
On Fri, Sep 7, 2012 at 8:56 AM, Matt Turner wrote: > On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca wrote: >> Matt, >> >> I see you went ahead and just disabled it. Please remove it all together. >> >> Touching code that is not built nor tested ends just silently introduces >> bugs, so keeping this around won't help bring it back one day in any way. >> >> Jose > > I talked with both Marek and Christoph, and they both said they'd > prefer to simply disable the build. I don't feel strongly, but if I only expressed my opinion. If it were nuked or moved into a separate branch, I wouldn't care. Another project with an uncertain fate is st/xorg. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Disable building of d3d1x
On 07.09.2012 17:17, Matt Turner wrote: > On Fri, Sep 7, 2012 at 7:55 AM, Christoph Bumiller > wrote: >> On 07.09.2012 12:30, Jose Fonseca wrote: >>> - Original Message - On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca wrote: > Matt, > > I see you went ahead and just disabled it. Please remove it all > together. > > Touching code that is not built nor tested ends just silently > introduces bugs, so keeping this around won't help bring it back > one day in any way. > > Jose I talked with both Marek and Christoph, and they both said they'd prefer to simply disable the build. I don't feel strongly, but if someone is to revive it it'd be nice if we didn't make the git history harder to follow. >>> >>> I suppose they have their arguments, and I hope they include making this >>> build again shortly. What I don't understand is why these talks didn't >>> happen within this email thread. I'd expect at least a heads up email >>> before committing this... >>> >> >> Actually I didn't express any preference. I can't say when or even if >> I'll work on d3d1x again, and I don't care about making it build in the >> meantime, since it isn't useful for anyone without further improvements. >> >> (Like working translation of SM4 to TGSI; my passing SM4 to the driver >> directly works much better right now, but is too "evil" to push upstream). > > Oh, that's not how it seemed on IRC. > > [13:11]| calim, mareko: what do you think about > disabling the d3d1x build vs just removing d3d1x? > Ah, I have to apologize there, maybe I didn't read the "vs" part ... I, too, just didn't want to see any more reports about build failures. Though I'm still hoping someone might pick up development. > [13:28] < calim> | mattst88: yeah disable it, I don't have time > to work on it and therefore I don't have the nerve to care about > whether it builds or not > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Disable building of d3d1x
On Fri, Sep 7, 2012 at 3:30 AM, Jose Fonseca wrote: > - Original Message - >> On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca >> wrote: >> > Matt, >> > >> > I see you went ahead and just disabled it. Please remove it all >> > together. >> > >> > Touching code that is not built nor tested ends just silently >> > introduces bugs, so keeping this around won't help bring it back >> > one day in any way. >> > >> > Jose >> >> I talked with both Marek and Christoph, and they both said they'd >> prefer to simply disable the build. I don't feel strongly, but if >> someone is to revive it it'd be nice if we didn't make the git >> history >> harder to follow. > > I suppose they have their arguments, and I hope they include making this > build again shortly. What I don't understand is why these talks didn't > happen within this email thread. I'd expect at least a heads up email before > committing this... I don't know why they didn't respond via email. It's not like we can't still remove d3d1x... >> Applying your reasoning (which I tend to agree with) to some other >> parts of Gallium makes for interesting conversation. The VAAPI state >> tracker and targets aren't built. Should we also nuke them? How about >> something like the xorg-i915 target (which installs a >> 'modesetting_drv.so')? > > I don't know enough about this code or the ongoing autotool-ification process > to tell whether this is a short term or long term condition. VAAPI is disabled in the build system because it doesn't work. > But yes, In general I see no point in carrying around stuff that doesn't > minimally work or can't even be built. If something is unusable/unmaintained > over one Mesa release cycle, then it should be chopped off. Every dead code > we remove means that cleanups and refactorings of the good code becomes > easier. And if it is broken, then there's no loss to the end user either. > > This is not the first or last time we'd remove code BTW. There are many > precedents. I know. I'm asking about things that are currently disabled (VAAPI stuff) or are of questionable use (xorg-i915). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix virtual_grf_interferes() between calculate_live_intervals() and DCE.
Kenneth Graunke writes:
> On 09/05/2012 11:16 PM, Eric Anholt wrote:
>> This fixes the blue zombies bug in l4d2.
>>
>> NOTE: This is a candidate for the 9.0 branch.
>> ---
>> .../drivers/dri/i965/brw_fs_live_variables.cpp | 24
>>
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
>> index 16480ad..392691d 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
>> @@ -221,6 +221,30 @@ fs_visitor::calculate_live_intervals()
>> }
>>
>> this->live_intervals_valid = true;
>> +
>> + /* Note in the non-control-flow code above, that we only take def[] as
>> the
>> +* first store, and use[] as the last use. We use this in dead code
>> +* elimination, to determine when a store never gets used. However, we
>> +* also use these arrays to answer the virtual_grf_interferes() question
>> +* (live interval analysis), which is used for register coalescing and
>> +* register allocation.
>> +*
>> +* So, there's a conflict over what the array should mean: if use[]
>> +* considers a def after the last use, then the dead code elimination
>> pass
>> +* never does anything (and it's an important pass!). But if we don't
>> +* include dead code, then virtual_grf_interferes() lies and we'll do
>> +* horrible things like coalesce the register that is dead-code-written
>> +* into another register that was live across the dead write (causing the
>> +* use of the second register to take the dead write's source value
>> instead
>> +* of the coalesced MOV's source value).
>> +*
>> +* To resolve the conflict, immediately after calculating live intervals,
>> +* detect dead code, nuke it, and if we changed anything, calculate again
>> +* before returning to the caller. Now we happen to produce def[] and
>> +* use[] arrays that will work for virtual_grf_interferes().
>> +*/
>> + if (dead_code_eliminate())
>> + calculate_live_intervals();
>> }
>>
>> bool
>
> I am worried that this will come back to haunt us later. This is the
> first time calculate_live_intervals() has actually *changed* the IR,
> rather than analyze it.
>
> Specifically, if an optimization pass were to do:
>
> fs_cfg cfg(this);
> calculate_live_intervals();
>
> and the start/end of a basic block happened to be dead code, then when
> we hit
>
>for (fs_inst *inst = block->start;
> inst != block->end->next;
> inst = (fs_inst *) inst->next) {
>
> we'll most assuredly start traversing data and hit a NULL pointer (if we
> don't crash when dereferencing block->start) since you'll never hit
> block->end.
>
> Granted, no code actually uses both CFGs and live intervals today, but
> it sounds plausible.
>
> Here's one idea for safeguarding against this:
>
> 1. Add a new "int using_cfg" variable to fs_visitor.
> 2. In the fs_cfg() constructor, increment v->using_cfg.
> 3. In the fs_cfg() destructor, decrement v->using_cfg.
> 4. In calculate_live_intervals, assert(!using_cfg);
>
> Then it'd least die with a reasonable message.
>
> What do you think? Worth doing? Something else? Am I being too paranoid?
>
> Regardless of the paranoia I think you should push this (unless you
> think of a better solution). After spending nearly a whole week hitting
> my head against the wall, I'm ready to see this fixed.
Other times we've written code like this (e.g. no_batch_wrap), I've
found it irritating to maintain. For no_batch_wrap, it to catch very
likely bugs, while I feel that in this case the bugs are not likely.
pgp3XPpFXohYz.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Disable building of d3d1x
On Fri, Sep 7, 2012 at 7:55 AM, Christoph Bumiller wrote: > On 07.09.2012 12:30, Jose Fonseca wrote: >> - Original Message - >>> On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca >>> wrote: Matt, I see you went ahead and just disabled it. Please remove it all together. Touching code that is not built nor tested ends just silently introduces bugs, so keeping this around won't help bring it back one day in any way. Jose >>> >>> I talked with both Marek and Christoph, and they both said they'd >>> prefer to simply disable the build. I don't feel strongly, but if >>> someone is to revive it it'd be nice if we didn't make the git >>> history >>> harder to follow. >> >> I suppose they have their arguments, and I hope they include making this >> build again shortly. What I don't understand is why these talks didn't >> happen within this email thread. I'd expect at least a heads up email before >> committing this... >> > > Actually I didn't express any preference. I can't say when or even if > I'll work on d3d1x again, and I don't care about making it build in the > meantime, since it isn't useful for anyone without further improvements. > > (Like working translation of SM4 to TGSI; my passing SM4 to the driver > directly works much better right now, but is too "evil" to push upstream). Oh, that's not how it seemed on IRC. [13:11]| calim, mareko: what do you think about disabling the d3d1x build vs just removing d3d1x? [13:28] < calim> | mattst88: yeah disable it, I don't have time to work on it and therefore I don't have the nerve to care about whether it builds or not ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Disable building of d3d1x
On 07.09.2012 12:30, Jose Fonseca wrote: > - Original Message - >> On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca >> wrote: >>> Matt, >>> >>> I see you went ahead and just disabled it. Please remove it all >>> together. >>> >>> Touching code that is not built nor tested ends just silently >>> introduces bugs, so keeping this around won't help bring it back >>> one day in any way. >>> >>> Jose >> >> I talked with both Marek and Christoph, and they both said they'd >> prefer to simply disable the build. I don't feel strongly, but if >> someone is to revive it it'd be nice if we didn't make the git >> history >> harder to follow. > > I suppose they have their arguments, and I hope they include making this > build again shortly. What I don't understand is why these talks didn't > happen within this email thread. I'd expect at least a heads up email before > committing this... > Actually I didn't express any preference. I can't say when or even if I'll work on d3d1x again, and I don't care about making it build in the meantime, since it isn't useful for anyone without further improvements. (Like working translation of SM4 to TGSI; my passing SM4 to the driver directly works much better right now, but is too "evil" to push upstream). >> Applying your reasoning (which I tend to agree with) to some other >> parts of Gallium makes for interesting conversation. The VAAPI state >> tracker and targets aren't built. Should we also nuke them? How about >> something like the xorg-i915 target (which installs a >> 'modesetting_drv.so')? > > I don't know enough about this code or the ongoing autotool-ification process > to tell whether this is a short term or long term condition. > > But yes, In general I see no point in carrying around stuff that doesn't > minimally work or can't even be built. If something is unusable/unmaintained > over one Mesa release cycle, then it should be chopped off. Every dead code > we remove means that cleanups and refactorings of the good code becomes > easier. And if it is broken, then there's no loss to the end user either. > > This is not the first or last time we'd remove code BTW. There are many > precedents. > > Jose > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeon/llvm: Match fexp2 for SI.
On Fri, Sep 07, 2012 at 12:27:35PM +0200, Michel Dänzer wrote: > From: Michel Dänzer > > Signed-off-by: Michel Dänzer For the series: Reviewed-by: Tom Stellard > --- > src/gallium/drivers/radeon/SIInstructions.td |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/radeon/SIInstructions.td > b/src/gallium/drivers/radeon/SIInstructions.td > index 2868196..8f9de52 100644 > --- a/src/gallium/drivers/radeon/SIInstructions.td > +++ b/src/gallium/drivers/radeon/SIInstructions.td > @@ -529,7 +529,9 @@ defm V_TRUNC_F32 : VOP1_32 <0x0021, "V_TRUNC_F32", > []>; > defm V_CEIL_F32 : VOP1_32 <0x0022, "V_CEIL_F32", []>; > defm V_RNDNE_F32 : VOP1_32 <0x0023, "V_RNDNE_F32", []>; > defm V_FLOOR_F32 : VOP1_32 <0x0024, "V_FLOOR_F32", []>; > -defm V_EXP_F32 : VOP1_32 <0x0025, "V_EXP_F32", []>; > +defm V_EXP_F32 : VOP1_32 <0x0025, "V_EXP_F32", > + [(set VReg_32:$dst, (fexp2 AllReg_32:$src0))] > +>; > defm V_LOG_CLAMP_F32 : VOP1_32 <0x0026, "V_LOG_CLAMP_F32", []>; > defm V_LOG_F32 : VOP1_32 <0x0027, "V_LOG_F32", []>; > defm V_RCP_CLAMP_F32 : VOP1_32 <0x0028, "V_RCP_CLAMP_F32", []>; > -- > 1.7.10.4 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeon/llvm: Match fexp2 for SI.
On Fri, Sep 7, 2012 at 6:27 AM, Michel Dänzer wrote: > From: Michel Dänzer > > Signed-off-by: Michel Dänzer for the series: Reviewed-by: Alex Deucher > --- > src/gallium/drivers/radeon/SIInstructions.td |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/radeon/SIInstructions.td > b/src/gallium/drivers/radeon/SIInstructions.td > index 2868196..8f9de52 100644 > --- a/src/gallium/drivers/radeon/SIInstructions.td > +++ b/src/gallium/drivers/radeon/SIInstructions.td > @@ -529,7 +529,9 @@ defm V_TRUNC_F32 : VOP1_32 <0x0021, "V_TRUNC_F32", > []>; > defm V_CEIL_F32 : VOP1_32 <0x0022, "V_CEIL_F32", []>; > defm V_RNDNE_F32 : VOP1_32 <0x0023, "V_RNDNE_F32", []>; > defm V_FLOOR_F32 : VOP1_32 <0x0024, "V_FLOOR_F32", []>; > -defm V_EXP_F32 : VOP1_32 <0x0025, "V_EXP_F32", []>; > +defm V_EXP_F32 : VOP1_32 <0x0025, "V_EXP_F32", > + [(set VReg_32:$dst, (fexp2 AllReg_32:$src0))] > +>; > defm V_LOG_CLAMP_F32 : VOP1_32 <0x0026, "V_LOG_CLAMP_F32", []>; > defm V_LOG_F32 : VOP1_32 <0x0027, "V_LOG_F32", []>; > defm V_RCP_CLAMP_F32 : VOP1_32 <0x0028, "V_RCP_CLAMP_F32", []>; > -- > 1.7.10.4 > > ___ > 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] build/glsl: Add missing extension for builtin_compiler.
- Original Message - > On Thu, Sep 6, 2012 at 3:21 PM, Kenneth Graunke > wrote: > > On 09/06/2012 09:08 AM, Vinson Lee wrote: > >> On Thu, Sep 6, 2012 at 4:19 AM, Jon TURNEY > >> wrote: > >>> On 06/09/2012 08:08, Matt Turner wrote: > On Wed, Sep 5, 2012 at 10:48 PM, Vinson Lee > wrote: > > Signed-off-by: Vinson Lee > > --- > > src/glsl/Makefile.am |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am > > index 20639c9..f9c8671 100644 > > --- a/src/glsl/Makefile.am > > +++ b/src/glsl/Makefile.am > > @@ -93,7 +93,7 @@ BUILT_SOURCES = glsl_parser.h > > builtin_function.cpp > > CLEANFILES = glsl_lexer.cc glsl_parser.cc $(BUILT_SOURCES) > > > > builtin_function.cpp: $(srcdir)/builtins/profiles/* > > $(srcdir)/builtins/ir/* $(srcdir)/builtins/glsl/* > > $(srcdir)/builtins/tools/generate_builtins.py > > $(srcdir)/builtins/tools/texture_builtins.py > > builtin_compiler$(EXEEXT) > > - $(AM_V_GEN) $(PYTHON2) $(PYTHON_FLAGS) > > $(srcdir)/builtins/tools/generate_builtins.py > > ./builtin_compiler > builtin_function.cpp || rm -f > > builtin_function.cpp > > + $(AM_V_GEN) $(PYTHON2) $(PYTHON_FLAGS) > > $(srcdir)/builtins/tools/generate_builtins.py > > ./builtin_compiler$(EXEEXT) > builtin_function.cpp || rm -f > > builtin_function.cpp > > > > glcpp/libglcpp.la: > > cd glcpp ; $(MAKE) $(AM_MAKEFLAGS) > > Looks reasonable. > >>> > >>> Um, I would be interested to know on what platform this is > >>> necessary. (I > >>> thought that generally EXEEXT is not needed for running the > >>> executable) > >> > >> The MinGW build creates builtin_compiler.exe. > > > > But on Windows, you can just run "edit", not "edit.com". It > > doesn't > > work without this? > > > > I don't care either way, but as Jon mentions, it seems kind of odd. > > This is the MinGW build on Linux and the resulting executable is run > with Wine. It appears the executable needs to be invoked as > "builtin_compiler.exe". "builtin_compiler" doesn't work. I'm not entirely sure what's the goal here: mingw cross-compilation with autotools? For the record, MinGW cross compilation works fine with SCons (where builtin_compiler is built for the host). For MinGW or any other sort of cross compilation with autotools, the build system need to do the same. I think it's no good to rely on wine for any cross compilation, as it's not always available. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Disable building of d3d1x
- Original Message - > On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca > wrote: > > Matt, > > > > I see you went ahead and just disabled it. Please remove it all > > together. > > > > Touching code that is not built nor tested ends just silently > > introduces bugs, so keeping this around won't help bring it back > > one day in any way. > > > > Jose > > I talked with both Marek and Christoph, and they both said they'd > prefer to simply disable the build. I don't feel strongly, but if > someone is to revive it it'd be nice if we didn't make the git > history > harder to follow. I suppose they have their arguments, and I hope they include making this build again shortly. What I don't understand is why these talks didn't happen within this email thread. I'd expect at least a heads up email before committing this... > Applying your reasoning (which I tend to agree with) to some other > parts of Gallium makes for interesting conversation. The VAAPI state > tracker and targets aren't built. Should we also nuke them? How about > something like the xorg-i915 target (which installs a > 'modesetting_drv.so')? I don't know enough about this code or the ongoing autotool-ification process to tell whether this is a short term or long term condition. But yes, In general I see no point in carrying around stuff that doesn't minimally work or can't even be built. If something is unusable/unmaintained over one Mesa release cycle, then it should be chopped off. Every dead code we remove means that cleanups and refactorings of the good code becomes easier. And if it is broken, then there's no loss to the end user either. This is not the first or last time we'd remove code BTW. There are many precedents. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 49504] [Bisected] Mesa master compilation broke when built with --with-llvm-shared-libs
https://bugs.freedesktop.org/show_bug.cgi?id=49504 Fabio Pedretti changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #5 from Fabio Pedretti 2012-09-07 10:30:26 UTC --- Unduplicate: this is fixed, while #52167 still not. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radeon/llvm: Match fexp2 for SI.
From: Michel Dänzer Signed-off-by: Michel Dänzer --- src/gallium/drivers/radeon/SIInstructions.td |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeon/SIInstructions.td b/src/gallium/drivers/radeon/SIInstructions.td index 2868196..8f9de52 100644 --- a/src/gallium/drivers/radeon/SIInstructions.td +++ b/src/gallium/drivers/radeon/SIInstructions.td @@ -529,7 +529,9 @@ defm V_TRUNC_F32 : VOP1_32 <0x0021, "V_TRUNC_F32", []>; defm V_CEIL_F32 : VOP1_32 <0x0022, "V_CEIL_F32", []>; defm V_RNDNE_F32 : VOP1_32 <0x0023, "V_RNDNE_F32", []>; defm V_FLOOR_F32 : VOP1_32 <0x0024, "V_FLOOR_F32", []>; -defm V_EXP_F32 : VOP1_32 <0x0025, "V_EXP_F32", []>; +defm V_EXP_F32 : VOP1_32 <0x0025, "V_EXP_F32", + [(set VReg_32:$dst, (fexp2 AllReg_32:$src0))] +>; defm V_LOG_CLAMP_F32 : VOP1_32 <0x0026, "V_LOG_CLAMP_F32", []>; defm V_LOG_F32 : VOP1_32 <0x0027, "V_LOG_F32", []>; defm V_RCP_CLAMP_F32 : VOP1_32 <0x0028, "V_RCP_CLAMP_F32", []>; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radeonsi: Handle TGSI_SEMANTIC_FOG.
From: Michel Dänzer Fixes exponential fog. The pixel shaders for linear fog seem to get miscompiled still somehow. Signed-off-by: Michel Dänzer --- src/gallium/drivers/radeonsi/radeonsi_shader.c |1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c b/src/gallium/drivers/radeonsi/radeonsi_shader.c index 1c330b5..9fc3446 100644 --- a/src/gallium/drivers/radeonsi/radeonsi_shader.c +++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c @@ -538,6 +538,7 @@ static void si_llvm_emit_epilogue(struct lp_build_tgsi_context * bld_base) color_count++; } break; + case TGSI_SEMANTIC_FOG: case TGSI_SEMANTIC_GENERIC: target = V_008DFC_SQ_EXP_PARAM + param_count; shader->output[i].param_offset = param_count; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52167] llvmpipe test programs link fails when ld --as-needed option is used
https://bugs.freedesktop.org/show_bug.cgi?id=52167 --- Comment #8 from Olivier Blin 2012-09-07 08:55:27 UTC --- Fabio: no, the bug is still present in 9.0 branch, and likely in master since the build files did not change. The patch from comment 4 can still be applied as is. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 54626] New: llvmpipe's Makefile doesn't take care of CXXFLAGS or CPPFLAGS
https://bugs.freedesktop.org/show_bug.cgi?id=54626 Bug #: 54626 Summary: llvmpipe's Makefile doesn't take care of CXXFLAGS or CPPFLAGS Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: alexandre.f.dem...@gmail.com When building with --enable-32-bit, I end up with: make[4]: Entering directory `/home/dema1701/projects/display/mesa/src/gallium/drivers/llvmpipe' g++ -L/usr/lib32/llvm -lpthread -lffi -ldl -lm lp_test_format.o lp_test_main.o -o lp_test_format -Wl,--start-group -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVMMCJIT -lLLVMBitWriter -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport -L/usr/lib32 -lXext -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -lXxf86vm -L/usr/lib/i386-linux-gnu/ -ldrm -lm -lpthread -ldl -Wl,--end-group Obviously, I encounter: collect2: error: ld returned 1 exit status make[4]: *** [lp_test_format] Error 1 This can easily be fixed by adding "-m32" to g++. Looking through the Makefile lets me think the flag is not properly propagated. Adding "-m32" at the end of LDFLAGS += $(LLVM_LDFLAGS) makes sense.LLVM_LDFLAGS is defined as LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` in configure.ac. I don't know about --ldflags, but I'm sure there should be a $CFLASGS or $CCASFLAGS there. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate
https://bugs.freedesktop.org/show_bug.cgi?id=45466 --- Comment #2 from Alexandre Demers 2012-09-07 07:46:20 UTC --- This patch doesn't apply correctly on latest git. However, when fixed, it helps. I don't know if it's the same situation everywhere, but under ArchLinux, llvm-config-32 should be replaced by llvm-config32 (probably the same thing should be done for llvm-config-64, but I can't test it, my setup has llvm-config). Also, I think we shouldn't use LLVM_LDFLAGS_ADD with the current git code. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate
https://bugs.freedesktop.org/show_bug.cgi?id=45466 Alexandre Demers changed: What|Removed |Added CC||alexandre.f.dem...@gmail.co ||m -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 41700] Gallium won't build with --enable-32-bit on a 64-bit system
https://bugs.freedesktop.org/show_bug.cgi?id=41700 --- Comment #2 from Alexandre Demers 2012-09-07 07:42:43 UTC --- The proposed patch from bug 45466 was not commited. It doesn't apply correctly with latest git. However, when fixed, it helps from what I've encountered. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 54326] When building 32 bit on 64 bit, many lib path variables are not pointing to 32 bit folders.
https://bugs.freedesktop.org/show_bug.cgi?id=54326 Alexandre Demers changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #7 from Alexandre Demers 2012-09-07 07:39:40 UTC --- Closing since defining PKG_CONFIG_PATH fixes the bug. llvmpipe has a different bug that is not related. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
