[Mesa-dev] [PATCH 1/5] radeonsi: define SGPR register numbers
Instead of hardcoding them.
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/drivers/radeonsi/radeonsi_pm4.c|3 ++-
src/gallium/drivers/radeonsi/radeonsi_pm4.h|2 +-
src/gallium/drivers/radeonsi/radeonsi_shader.c | 18 +-
src/gallium/drivers/radeonsi/radeonsi_shader.h |8
src/gallium/drivers/radeonsi/si_state.c| 16 +---
src/gallium/drivers/radeonsi/si_state_draw.c |6 +++---
6 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pm4.c
b/src/gallium/drivers/radeonsi/radeonsi_pm4.c
index 8268f91..ea0a1bd 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_pm4.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_pm4.c
@@ -106,9 +106,10 @@ void si_pm4_sh_data_add(struct si_pm4_state *state,
uint32_t dw)
si_pm4_cmd_add(state, dw);
}
-void si_pm4_sh_data_end(struct si_pm4_state *state, unsigned reg)
+void si_pm4_sh_data_end(struct si_pm4_state *state, unsigned base, unsigned
idx)
{
unsigned offs = state-last_pm4 + 1;
+ unsigned reg = base + idx * 4;
/* Bail if no data was added */
if (state-ndw == offs) {
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pm4.h
b/src/gallium/drivers/radeonsi/radeonsi_pm4.h
index 2b32ffb..ef327d6 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_pm4.h
+++ b/src/gallium/drivers/radeonsi/radeonsi_pm4.h
@@ -71,7 +71,7 @@ void si_pm4_add_bo(struct si_pm4_state *state,
void si_pm4_sh_data_begin(struct si_pm4_state *state);
void si_pm4_sh_data_add(struct si_pm4_state *state, uint32_t dw);
-void si_pm4_sh_data_end(struct si_pm4_state *state, unsigned reg);
+void si_pm4_sh_data_end(struct si_pm4_state *state, unsigned base, unsigned
idx);
void si_pm4_inval_shader_cache(struct si_pm4_state *state);
void si_pm4_inval_texture_cache(struct si_pm4_state *state);
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 57950a7..75cb7e1 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
@@ -196,10 +196,7 @@ static void declare_input_vs(
unsigned chan;
/* Load the T list */
- /* XXX: Communicate with the rest of the driver about which SGPR the T#
-* list pointer is going to be stored in. Hard code to SGPR[6:7] for
-* now */
- t_list_ptr = use_sgpr(base-gallivm, SGPR_CONST_PTR_V4I32, 6);
+ t_list_ptr = use_sgpr(base-gallivm, SGPR_CONST_PTR_V4I32,
SI_SGPR_VERTEX_BUFFER);
t_offset = lp_build_const_int32(base-gallivm, input_index);
@@ -251,10 +248,7 @@ static void declare_input_fs(
* [32:16] ParamOffset
*
*/
- /* XXX: This register number must be identical to the S_00B02C_USER_SGPR
-* register field value
-*/
- LLVMValueRef params = use_sgpr(base-gallivm, SGPR_I32, 6);
+ LLVMValueRef params = use_sgpr(base-gallivm, SGPR_I32,
SI_PS_NUM_USER_SGPR);
/* XXX: Is this the input_index? */
@@ -373,9 +367,7 @@ static LLVMValueRef fetch_constant(
return bitcast(bld_base, type, load);
}
- /* XXX: Assume the pointer to the constant buffer is being stored in
-* SGPR[0:1] */
- const_ptr = use_sgpr(base-gallivm, SGPR_CONST_PTR_F32, 0);
+ const_ptr = use_sgpr(base-gallivm, SGPR_CONST_PTR_F32, SI_SGPR_CONST);
/* XXX: This assumes that the constant buffer is not packed, so
* CONST[0].x will have an offset of 0 and CONST[1].x will have an
@@ -652,14 +644,14 @@ static void tex_fetch_args(
0, LP_CHAN_ALL);
/* Resource */
- ptr = use_sgpr(bld_base-base.gallivm, SGPR_CONST_PTR_V8I32, 4);
+ ptr = use_sgpr(bld_base-base.gallivm, SGPR_CONST_PTR_V8I32,
SI_SGPR_RESOURCE);
offset = lp_build_const_int32(bld_base-base.gallivm,
emit_data-inst-Src[1].Register.Index);
emit_data-args[2] = build_indexed_load(bld_base-base.gallivm,
ptr, offset);
/* Sampler */
- ptr = use_sgpr(bld_base-base.gallivm, SGPR_CONST_PTR_V4I32, 2);
+ ptr = use_sgpr(bld_base-base.gallivm, SGPR_CONST_PTR_V4I32,
SI_SGPR_SAMPLER);
offset = lp_build_const_int32(bld_base-base.gallivm,
emit_data-inst-Src[1].Register.Index);
emit_data-args[3] = build_indexed_load(bld_base-base.gallivm,
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.h
b/src/gallium/drivers/radeonsi/radeonsi_shader.h
index aa2888c..688db57 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.h
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.h
@@ -29,6 +29,14 @@
#ifndef RADEONSI_SHADER_H
#define RADEONSI_SHADER_H
+#define SI_SGPR_CONST 0
+#define SI_SGPR_SAMPLER2
+#define SI_SGPR_RESOURCE
[Mesa-dev] [PATCH 3/5] radeonsi: fix range checking for state regs
From: Alex Deucher alexander.deuc...@amd.com
end value is exclusive, but in practice we shouldn't
hit this.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/drivers/radeonsi/radeonsi_pm4.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pm4.c
b/src/gallium/drivers/radeonsi/radeonsi_pm4.c
index ea0a1bd..79a2521 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_pm4.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_pm4.c
@@ -57,17 +57,18 @@ void si_pm4_set_reg(struct si_pm4_state *state, unsigned
reg, uint32_t val)
{
unsigned opcode;
- if (reg = SI_CONFIG_REG_OFFSET reg = SI_CONFIG_REG_END) {
+ if (reg = SI_CONFIG_REG_OFFSET reg SI_CONFIG_REG_END) {
opcode = PKT3_SET_CONFIG_REG;
reg -= SI_CONFIG_REG_OFFSET;
- } else if (reg = SI_SH_REG_OFFSET reg = SI_SH_REG_END) {
+ } else if (reg = SI_SH_REG_OFFSET reg SI_SH_REG_END) {
opcode = PKT3_SET_SH_REG;
reg -= SI_SH_REG_OFFSET;
- } else if (reg = SI_CONTEXT_REG_OFFSET reg = SI_CONTEXT_REG_END) {
+ } else if (reg = SI_CONTEXT_REG_OFFSET reg SI_CONTEXT_REG_END) {
opcode = PKT3_SET_CONTEXT_REG;
reg -= SI_CONTEXT_REG_OFFSET;
+
} else {
R600_ERR(Invalid register offset %08x!\n, reg);
return;
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] radeonsi: drop some cayman remnants
From: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Reviewed-by: Christian König deathsim...@vodafone.de
---
src/gallium/drivers/radeonsi/r600.h |2 --
src/gallium/drivers/radeonsi/r600_hw_context.c|7 +--
src/gallium/drivers/radeonsi/si_state.c | 13 +
src/gallium/drivers/radeonsi/si_state_streamout.c |6 ++
4 files changed, 4 insertions(+), 24 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/r600.h
b/src/gallium/drivers/radeonsi/r600.h
index c2c22c4..7a8ff10 100644
--- a/src/gallium/drivers/radeonsi/r600.h
+++ b/src/gallium/drivers/radeonsi/r600.h
@@ -39,7 +39,6 @@ struct winsys_handle;
enum radeon_family {
CHIP_UNKNOWN,
- CHIP_CAYMAN,
CHIP_TAHITI,
CHIP_PITCAIRN,
CHIP_VERDE,
@@ -47,7 +46,6 @@ enum radeon_family {
};
enum chip_class {
- CAYMAN,
TAHITI,
};
diff --git a/src/gallium/drivers/radeonsi/r600_hw_context.c
b/src/gallium/drivers/radeonsi/r600_hw_context.c
index 685f195..6f816dc 100644
--- a/src/gallium/drivers/radeonsi/r600_hw_context.c
+++ b/src/gallium/drivers/radeonsi/r600_hw_context.c
@@ -45,12 +45,7 @@ void si_get_backend_mask(struct r600_context *ctx)
if (ctx-screen-info.r600_backend_map_valid) {
unsigned num_tile_pipes = ctx-screen-info.r600_num_tile_pipes;
unsigned backend_map = ctx-screen-info.r600_backend_map;
- unsigned item_width, item_mask;
-
- if (ctx-chip_class = CAYMAN) {
- item_width = 4;
- item_mask = 0x7;
- }
+ unsigned item_width = 4, item_mask = 0x7;
while(num_tile_pipes--) {
i = backend_map item_mask;
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index b6b2306..b6e37fb 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1801,18 +1801,7 @@ static void si_set_framebuffer_state(struct pipe_context
*ctx,
tl_y = 0;
br_x = state-width;
br_y = state-height;
-#if 0 /* These shouldn't be necessary on SI, see PA_SC_ENHANCE register */
- /* EG hw workaround */
- if (br_x == 0)
- tl_x = 1;
- if (br_y == 0)
- tl_y = 1;
- /* cayman hw workaround */
- if (rctx-chip_class == CAYMAN) {
- if (br_x == 1 br_y == 1)
- br_x = 2;
- }
-#endif
+
tl = S_028240_TL_X(tl_x) | S_028240_TL_Y(tl_y);
br = S_028244_BR_X(br_x) | S_028244_BR_Y(br_y);
diff --git a/src/gallium/drivers/radeonsi/si_state_streamout.c
b/src/gallium/drivers/radeonsi/si_state_streamout.c
index 3410eb6..2e17d90 100644
--- a/src/gallium/drivers/radeonsi/si_state_streamout.c
+++ b/src/gallium/drivers/radeonsi/si_state_streamout.c
@@ -56,10 +56,8 @@ void si_context_streamout_begin(struct r600_context *ctx)
util_bitcount(buffer_en
~ctx-streamout_append_bitmask) * 6 +
ctx-num_cs_dw_streamout_end, TRUE);
- if (ctx-chip_class = CAYMAN) {
- evergreen_flush_vgt_streamout(ctx);
- evergreen_set_streamout_enable(ctx, buffer_en);
- }
+ evergreen_flush_vgt_streamout(ctx);
+ evergreen_set_streamout_enable(ctx, buffer_en);
for (i = 0; i ctx-num_so_targets; i++) {
#if 0
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] radeonsi: remove some old r600g cruft
From: Alex Deucher alexander.deuc...@amd.com Signed-off-by: Alex Deucher alexander.deuc...@amd.com Reviewed-by: Christian König deathsim...@vodafone.de --- src/gallium/drivers/radeonsi/r600_hw_context.c | 28 1 file changed, 28 deletions(-) diff --git a/src/gallium/drivers/radeonsi/r600_hw_context.c b/src/gallium/drivers/radeonsi/r600_hw_context.c index 6f816dc..bd348f9 100644 --- a/src/gallium/drivers/radeonsi/r600_hw_context.c +++ b/src/gallium/drivers/radeonsi/r600_hw_context.c @@ -664,32 +664,4 @@ void r600_context_draw_opaque_count(struct r600_context *ctx, struct r600_so_tar cs-buf[cs-cdw++] = PKT3(PKT3_NOP, 0, 0); cs-buf[cs-cdw++] = r600_context_bo_reloc(ctx, t-filled_size, RADEON_USAGE_READ); -#if 0 /* I have not found this useful yet. */ - cs-buf[cs-cdw++] = PKT3(PKT3_COPY_DW, 4, 0); - cs-buf[cs-cdw++] = COPY_DW_SRC_IS_REG | COPY_DW_DST_IS_REG; - cs-buf[cs-cdw++] = R_028B2C_VGT_STRMOUT_DRAW_OPAQUE_BUFFER_FILLED_SIZE 2; /* src register */ - cs-buf[cs-cdw++] = 0; /* unused */ - cs-buf[cs-cdw++] = R_0085F4_CP_COHER_SIZE 2; /* dst register */ - cs-buf[cs-cdw++] = 0; /* unused */ - - cs-buf[cs-cdw++] = PKT3(PKT3_SET_CONFIG_REG, 1, 0); - cs-buf[cs-cdw++] = (R_0085F0_CP_COHER_CNTL - SI_CONFIG_REG_OFFSET) 2; - cs-buf[cs-cdw++] = S_0085F0_SO0_DEST_BASE_ENA(1) t-so_index; - - cs-buf[cs-cdw++] = PKT3(PKT3_SET_CONFIG_REG, 1, 0); - cs-buf[cs-cdw++] = (R_0085F8_CP_COHER_BASE - SI_CONFIG_REG_OFFSET) 2; - cs-buf[cs-cdw++] = t-b.buffer_offset 2; - - cs-buf[cs-cdw++] = PKT3(PKT3_NOP, 0, 0); - cs-buf[cs-cdw++] = r600_context_bo_reloc(ctx, (struct si_resource*)t-b.buffer, - RADEON_USAGE_WRITE); - - cs-buf[cs-cdw++] = PKT3(PKT3_WAIT_REG_MEM, 5, 0); - cs-buf[cs-cdw++] = WAIT_REG_MEM_EQUAL; /* wait until the register is equal to the reference value */ - cs-buf[cs-cdw++] = R_0085FC_CP_COHER_STATUS 2; /* register */ - cs-buf[cs-cdw++] = 0; - cs-buf[cs-cdw++] = 0; /* reference value */ - cs-buf[cs-cdw++] = 0x; /* mask */ - cs-buf[cs-cdw++] = 4; /* poll interval */ -#endif } -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] radeonsi: emit PA_SU_PRIM_FILTER_CNTL
From: Alex Deucher alexander.deuc...@amd.com has no default value. Signed-off-by: Alex Deucher alexander.deuc...@amd.com Reviewed-by: Christian König deathsim...@vodafone.de --- src/gallium/drivers/radeonsi/si_state.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/drivers/radeonsi/si_state.c b/src/gallium/drivers/radeonsi/si_state.c index b6e37fb..d8b091e 100644 --- a/src/gallium/drivers/radeonsi/si_state.c +++ b/src/gallium/drivers/radeonsi/si_state.c @@ -2622,5 +2622,7 @@ void si_init_config(struct r600_context *rctx) si_pm4_set_reg(pm4, R_028804_DB_EQAA, 0x11); + si_pm4_set_reg(pm4, R_02882C_PA_SU_PRIM_FILTER_CNTL, 0); + si_pm4_set_state(rctx, init, pm4); } -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] radeonsi: emit PA_SU_PRIM_FILTER_CNTL
+ si_pm4_set_reg(pm4, R_02882C_PA_SU_PRIM_FILTER_CNTL, 0); Should it be better defaulted in the linux module? -- Sylvain ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes
Good morning, It seems 8f7990c5f2 has broken the Haiku build... http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0id=8f7990c5f2 After 8f7990c5f2 we are getting the following failure: Linking build/haiku-x86-debug/glsl/builtin_compiler ... build/haiku-x86-debug/glsl/glcpp/glcpp-parse.o: In function `yyparse': /Data/mesa/build/haiku-x86-debug/glsl/glcpp/glcpp-parse.c:1779: undefined reference to `yylex' build/haiku-x86-debug/glsl/glcpp/pp.o: In function `glcpp_preprocess': /Data/mesa/src/glsl/glcpp/pp.c:162: undefined reference to `glcpp_parser_parse' collect2: ld returned 1 exit status scons: *** [build/haiku-x86-debug/glsl/builtin_compiler] Error 1 scons: building terminated because of errors. Any ideas on the solution? I'm not big on the lex, bison stuff. -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] radeonsi: emit PA_SU_PRIM_FILTER_CNTL
On Sun, Sep 30, 2012 at 9:52 AM, Sylvain BERTRAND sylw...@legeek.net wrote: + si_pm4_set_reg(pm4, R_02882C_PA_SU_PRIM_FILTER_CNTL, 0); Should it be better defaulted in the linux module? It could be added to the kernel, but it's probably more important to emit the register state in the userspace drivers as it may affect the rendering pipeline which the userspace drivers are generally responsible for. Alex -- Sylvain ___ 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] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes
A small note, I updated our bison from 2.5 - 2.6.2 and still see the same error. I'm tempted to add __HAIKU__ def's around the removed code in 8f7990c5f2... but that seems dirty. -- Alex On 2012-09-30 9:37 am, kallisti5 wrote: Good morning, It seems 8f7990c5f2 has broken the Haiku build... http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0id=8f7990c5f2 After 8f7990c5f2 we are getting the following failure: Linking build/haiku-x86-debug/glsl/builtin_compiler ... build/haiku-x86-debug/glsl/glcpp/glcpp-parse.o: In function `yyparse': /Data/mesa/build/haiku-x86-debug/glsl/glcpp/glcpp-parse.c:1779: undefined reference to `yylex' build/haiku-x86-debug/glsl/glcpp/pp.o: In function `glcpp_preprocess': /Data/mesa/src/glsl/glcpp/pp.c:162: undefined reference to `glcpp_parser_parse' collect2: ld returned 1 exit status scons: *** [build/haiku-x86-debug/glsl/builtin_compiler] Error 1 scons: building terminated because of errors. Any ideas on the solution? I'm not big on the lex, bison stuff. -- Alex ___ 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] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes
On Sun, Sep 30, 2012 at 7:37 AM, kallisti5 kallis...@unixzen.com wrote: Good morning, It seems 8f7990c5f2 has broken the Haiku build... http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0id=8f7990c5f2 After 8f7990c5f2 we are getting the following failure: Linking build/haiku-x86-debug/glsl/builtin_compiler ... build/haiku-x86-debug/glsl/glcpp/glcpp-parse.o: In function `yyparse': /Data/mesa/build/haiku-x86-debug/glsl/glcpp/glcpp-parse.c:1779: undefined reference to `yylex' build/haiku-x86-debug/glsl/glcpp/pp.o: In function `glcpp_preprocess': /Data/mesa/src/glsl/glcpp/pp.c:162: undefined reference to `glcpp_parser_parse' collect2: ld returned 1 exit status scons: *** [build/haiku-x86-debug/glsl/builtin_compiler] Error 1 scons: building terminated because of errors. Any ideas on the solution? I'm not big on the lex, bison stuff. -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev It shouldn't do that. Have you done a clean build? I.e., git clean -dfx ./autogen.sh ... ? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes
On 09/30/2012 07:37 AM, kallisti5 wrote: Good morning, It seems 8f7990c5f2 has broken the Haiku build... http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0id=8f7990c5f2 After 8f7990c5f2 we are getting the following failure: Linking build/haiku-x86-debug/glsl/builtin_compiler ... build/haiku-x86-debug/glsl/glcpp/glcpp-parse.o: In function `yyparse': /Data/mesa/build/haiku-x86-debug/glsl/glcpp/glcpp-parse.c:1779: undefined reference to `yylex' build/haiku-x86-debug/glsl/glcpp/pp.o: In function `glcpp_preprocess': /Data/mesa/src/glsl/glcpp/pp.c:162: undefined reference to `glcpp_parser_parse' collect2: ld returned 1 exit status scons: *** [build/haiku-x86-debug/glsl/builtin_compiler] Error 1 scons: building terminated because of errors. Any ideas on the solution? I'm not big on the lex, bison stuff. -- Alex That's weird...you're not using automake? You need to call bison with the -p glcpp_parser_ option. This changes the prefix on all functions from the generic yy to glcpp_parser_ to avoid symbol conflicts. Alternatively, I think we could specify it in the .y file via: %name-prefix glcpp_parser_ which might be a better idea, since it works independently of the build system. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes
On 2012-09-30 12:16 pm, Kenneth Graunke wrote: On 09/30/2012 07:37 AM, kallisti5 wrote: Good morning, It seems 8f7990c5f2 has broken the Haiku build... http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0id=8f7990c5f2 After 8f7990c5f2 we are getting the following failure: Linking build/haiku-x86-debug/glsl/builtin_compiler ... build/haiku-x86-debug/glsl/glcpp/glcpp-parse.o: In function `yyparse': /Data/mesa/build/haiku-x86-debug/glsl/glcpp/glcpp-parse.c:1779: undefined reference to `yylex' build/haiku-x86-debug/glsl/glcpp/pp.o: In function `glcpp_preprocess': /Data/mesa/src/glsl/glcpp/pp.c:162: undefined reference to `glcpp_parser_parse' collect2: ld returned 1 exit status scons: *** [build/haiku-x86-debug/glsl/builtin_compiler] Error 1 scons: building terminated because of errors. Any ideas on the solution? I'm not big on the lex, bison stuff. -- Alex That's weird...you're not using automake? You need to call bison with the -p glcpp_parser_ option. This changes the prefix on all functions from the generic yy to glcpp_parser_ to avoid symbol conflicts. Alternatively, I think we could specify it in the .y file via: %name-prefix glcpp_parser_ which might be a better idea, since it works independently of the build system. We're using the scons build system :) I checked and don't see any lex.yy.c generated in the tree. -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes
On Sun, Sep 30, 2012 at 10:27 AM, kallisti5 kallis...@unixzen.com wrote: On 2012-09-30 12:16 pm, Kenneth Graunke wrote: On 09/30/2012 07:37 AM, kallisti5 wrote: Good morning, It seems 8f7990c5f2 has broken the Haiku build... http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0id=8f7990c5f2 After 8f7990c5f2 we are getting the following failure: Linking build/haiku-x86-debug/glsl/builtin_compiler ... build/haiku-x86-debug/glsl/glcpp/glcpp-parse.o: In function `yyparse': /Data/mesa/build/haiku-x86-debug/glsl/glcpp/glcpp-parse.c:1779: undefined reference to `yylex' build/haiku-x86-debug/glsl/glcpp/pp.o: In function `glcpp_preprocess': /Data/mesa/src/glsl/glcpp/pp.c:162: undefined reference to `glcpp_parser_parse' collect2: ld returned 1 exit status scons: *** [build/haiku-x86-debug/glsl/builtin_compiler] Error 1 scons: building terminated because of errors. Any ideas on the solution? I'm not big on the lex, bison stuff. -- Alex That's weird...you're not using automake? You need to call bison with the -p glcpp_parser_ option. This changes the prefix on all functions from the generic yy to glcpp_parser_ to avoid symbol conflicts. Alternatively, I think we could specify it in the .y file via: %name-prefix glcpp_parser_ which might be a better idea, since it works independently of the build system. We're using the scons build system :) I checked and don't see any lex.yy.c generated in the tree. -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev Oh, scons. https://bugs.freedesktop.org/show_bug.cgi?id=54947 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx/dri2: use uint64_t instead of double to represent time for FPS calculation
Wine or a windows app changes fpucw to 0x7f, causing doubles to be equivalent
to floats, which broke the calculation of FPS.
We should be very careful about using doubles in Mesa.
---
src/glx/dri2_glx.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index f2fc187..4ff0b9e 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -112,7 +112,7 @@ struct dri2_drawable
int have_fake_front;
int swap_interval;
- double previous_time;
+ uint64_t previous_time;
unsigned frames;
};
@@ -676,17 +676,18 @@ unsigned dri2GetSwapEventType(Display* dpy, XID drawable)
static void show_fps(struct dri2_drawable *draw)
{
struct timeval tv;
- double current_time;
+ uint64_t current_time;
gettimeofday(tv, 0);
- current_time = (double)tv.tv_sec + (double)tv.tv_usec * 0.01;
+ current_time = (uint64_t)tv.tv_sec*100 + (uint64_t)tv.tv_usec;
draw-frames++;
- if (draw-previous_time + 1 current_time) {
+ if (draw-previous_time + 100 = current_time) {
if (draw-previous_time) {
fprintf(stderr, libGL: FPS = %.1f\n,
- draw-frames / (current_time - draw-previous_time));
+ ((uint64_t)draw-frames * 100) /
+ (double)(current_time - draw-previous_time));
}
draw-frames = 0;
draw-previous_time = current_time;
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx/dri2: use uint64_t instead of double to represent time for FPS calculation
On 30 September 2012 21:51, Marek Olšák mar...@gmail.com wrote: Wine or a windows app changes fpucw to 0x7f, causing doubles to be equivalent to floats, which broke the calculation of FPS. For reference, this is done by for example d3d9 when a D3D device is created without D3DCREATE_FPU_PRESERVE set. In the general case applications can do all kinds of terrible things to the FPU control word of course. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 55476] [softpipe] piglit fbo-blit-stretch regression
https://bugs.freedesktop.org/show_bug.cgi?id=55476 --- Comment #1 from Marek Olšák mar...@gmail.com --- This is a known issue and I mentioned it on the mailing list. There seems to be a bug in softpipe's culling or clipping. The problem is if one of the vertex coordinates is negative, the whole primitive is culled. llvmpipe takes the same codepath in gallium components as softpipe (except for Draw?) and doesn't have the issue. To see the problem clearly, run fbo-blit-stretched with the first argument being the test index. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 19/19] mesa/tests: Sanity check the ES2 dispatch table
On 28 September 2012 14:15, Ian Romanick i...@freedesktop.org wrote: On 09/28/2012 01:55 PM, Paul Berry wrote: On 5 September 2012 15:09, Ian Romanick i...@freedesktop.org mailto:i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com mailto:ian.d.romanick@intel.**com ian.d.roman...@intel.com This test is only built when shared-glapi is used. Because of changes elsewhere in the tree that were necessary to make shared-glapi work correct with GLX, it's not feasible to make the test function both ways. Signed-off-by: Ian Romanick ian.d.roman...@intel.com mailto:ian.d.romanick@intel.**com ian.d.roman...@intel.com This test is failing on my system when I run make check: [--] 1 test from DispatchSanity_test [ RUN ] DispatchSanity_test.GLES2 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable dispatch_sanity.cpp:122: Failure Value of: table[i] Actual: 0x4de54e Expected: (_glapi_proc) _mesa_generic_nop Which is: 0x41af72 i = 321 [ FAILED ] DispatchSanity_test.GLES2 (4 ms) [--] 1 test from DispatchSanity_test (4 ms total) Is anybody else getting this problem? Can you put the following in the SET_by_offset macro (src/mesa/main/dispatch.h in your build directory): if (offset == 321) abort(); \ then backtrace to see what API function is at fault? Argh, for reasons I haven't figured out yet, the failure only happens when I run make check. It doesn't happen when I run the test directly from the command line (or in the debugger), which makes backtracing difficult :) Probably there is something wrong with my build environment. I'll troubleshoot some more on my own and get back to you if I don't get anywhere. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [origin/9.0] Haiku build breakage due to 8f7990c5f2 -- lex changes - resolved
On 2012-09-30 12:49 pm, Matt Turner wrote: On Sun, Sep 30, 2012 at 10:27 AM, kallisti5 kallis...@unixzen.com wrote: On 2012-09-30 12:16 pm, Kenneth Graunke wrote: On 09/30/2012 07:37 AM, kallisti5 wrote: Good morning, It seems 8f7990c5f2 has broken the Haiku build... http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0id=8f7990c5f2 After 8f7990c5f2 we are getting the following failure: Linking build/haiku-x86-debug/glsl/builtin_compiler ... build/haiku-x86-debug/glsl/glcpp/glcpp-parse.o: In function `yyparse': /Data/mesa/build/haiku-x86-debug/glsl/glcpp/glcpp-parse.c:1779: undefined reference to `yylex' build/haiku-x86-debug/glsl/glcpp/pp.o: In function `glcpp_preprocess': /Data/mesa/src/glsl/glcpp/pp.c:162: undefined reference to `glcpp_parser_parse' collect2: ld returned 1 exit status scons: *** [build/haiku-x86-debug/glsl/builtin_compiler] Error 1 scons: building terminated because of errors. Any ideas on the solution? I'm not big on the lex, bison stuff. -- Alex That's weird...you're not using automake? You need to call bison with the -p glcpp_parser_ option. This changes the prefix on all functions from the generic yy to glcpp_parser_ to avoid symbol conflicts. Alternatively, I think we could specify it in the .y file via: %name-prefix glcpp_parser_ which might be a better idea, since it works independently of the build system. We're using the scons build system :) I checked and don't see any lex.yy.c generated in the tree. -- Alex Oh, scons. https://bugs.freedesktop.org/show_bug.cgi?id=54947 I can confirm this is resolved after the following commit: http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.0id=e642d61d130b725c0c3efbc87f86a4968311ba2a The Mesa 9.0 branch now builds under Haiku again. Thanks! -- Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
