[Mesa-dev] [PATCH] i965: Fix virtual_grf_interferes() between calculate_live_intervals() and DCE.
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 -- 1.7.10.4 ___ 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.
On Wed, Sep 5, 2012 at 10:48 PM, Vinson Lee v...@freedesktop.org wrote: Signed-off-by: Vinson Lee v...@freedesktop.org --- 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. Reviewed-by: Matt Turner matts...@gmail.com ___ 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 06.09.2012 07:35, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com 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? Philipp ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] radeonsi: Untiled textures are linear aligned, not linear general.
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/r600_texture.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/r600_texture.c
b/src/gallium/drivers/radeonsi/r600_texture.c
index 5b831fd..0b908c8 100644
--- a/src/gallium/drivers/radeonsi/r600_texture.c
+++ b/src/gallium/drivers/radeonsi/r600_texture.c
@@ -523,7 +523,7 @@ struct pipe_resource *si_texture_create(struct pipe_screen
*screen,
{
struct r600_screen *rscreen = (struct r600_screen*)screen;
struct radeon_surface surface;
- unsigned array_mode = 0;
+ unsigned array_mode = V_009910_ARRAY_LINEAR_ALIGNED;
int r;
#if 0
@@ -589,7 +589,7 @@ struct pipe_resource *si_texture_from_handle(struct
pipe_screen *screen,
struct r600_screen *rscreen = (struct r600_screen*)screen;
struct pb_buffer *buf = NULL;
unsigned stride = 0;
- unsigned array_mode = 0;
+ unsigned array_mode = V_009910_ARRAY_LINEAR_ALIGNED;
enum radeon_bo_layout micro, macro;
struct radeon_surface surface;
int r;
@@ -614,7 +614,7 @@ struct pipe_resource *si_texture_from_handle(struct
pipe_screen *screen,
else if (micro == RADEON_LAYOUT_TILED)
array_mode = V_009910_ARRAY_1D_TILED_THIN1;
else
- array_mode = 0;
+ array_mode = V_009910_ARRAY_LINEAR_ALIGNED;
r = r600_init_surface(surface, templ, array_mode);
if (r) {
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] radeonsi: Mipmaps require memory footprint to be padded to powers of two.
From: Michel Dänzer michel.daen...@amd.com Signed-off-by: Michel Dänzer michel.daen...@amd.com --- src/gallium/drivers/radeonsi/si_state.c |1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/radeonsi/si_state.c b/src/gallium/drivers/radeonsi/si_state.c index dac64aa..762887d 100644 --- a/src/gallium/drivers/radeonsi/si_state.c +++ b/src/gallium/drivers/radeonsi/si_state.c @@ -2107,6 +2107,7 @@ static struct pipe_sampler_view *si_create_sampler_view(struct pipe_context *ctx S_008F1C_BASE_LEVEL(state-u.tex.first_level) | S_008F1C_LAST_LEVEL(state-u.tex.last_level) | S_008F1C_TILING_INDEX(tiling_index) | + S_008F1C_POW2_PAD(texture-last_level 0) | S_008F1C_TYPE(si_tex_dim(texture-target))); view-state[4] = (S_008F20_DEPTH(depth - 1) | S_008F20_PITCH(pitch - 1)); view-state[5] = (S_008F24_BASE_ARRAY(state-u.tex.first_layer) | -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] radeonsi: Enable NPOT textures again.
From: Michel Dänzer michel.daen...@amd.com Should be at least mostly working now (with the corresponding fixes in libdrm_radeon). Signed-off-by: Michel Dänzer michel.daen...@amd.com --- src/gallium/drivers/radeonsi/radeonsi_pipe.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c b/src/gallium/drivers/radeonsi/radeonsi_pipe.c index f3914d7..9d7ac51 100644 --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c @@ -323,6 +323,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_USER_INDEX_BUFFERS: case PIPE_CAP_USER_CONSTANT_BUFFERS: case PIPE_CAP_START_INSTANCE: + case PIPE_CAP_NPOT_TEXTURES: return 1; case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT: @@ -332,7 +333,6 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) return debug_get_bool_option(R600_GLSL130, FALSE) ? 130 : 120; /* Unsupported features. */ - case PIPE_CAP_NPOT_TEXTURES: case PIPE_CAP_TGSI_INSTANCEID: case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT: case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER: -- 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/4] radeonsi: Sampler view state simplification.
From: Michel Dänzer michel.daen...@amd.com
We can always use the offset and tiling mode from level 0 and restrict the
first and last mipmap level to be used in the sampler resource.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/si_state.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index c01c3f6..dac64aa 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1992,7 +1992,7 @@ static struct pipe_sampler_view
*si_create_sampler_view(struct pipe_context *ctx
unsigned format, num_format, /*endian,*/ tiling_index;
uint32_t pitch = 0;
unsigned char state_swizzle[4], swizzle[4];
- unsigned height, depth, width, offset_level, last_level;
+ unsigned height, depth, width;
int first_non_void;
uint64_t va;
@@ -2039,12 +2039,10 @@ static struct pipe_sampler_view
*si_create_sampler_view(struct pipe_context *ctx
/* not supported any more */
//endian = si_colorformat_endian_swap(format);
- offset_level = state-u.tex.first_level;
- last_level = state-u.tex.last_level - offset_level;
- width = tmp-surface.level[offset_level].npix_x;
- height = tmp-surface.level[offset_level].npix_y;
- depth = tmp-surface.level[offset_level].npix_z;
- pitch = tmp-surface.level[offset_level].nblk_x *
util_format_get_blockwidth(state-format);
+ width = tmp-surface.level[0].npix_x;
+ height = tmp-surface.level[0].npix_y;
+ depth = tmp-surface.level[0].npix_z;
+ pitch = tmp-surface.level[0].nblk_x *
util_format_get_blockwidth(state-format);
if (texture-target == PIPE_TEXTURE_1D_ARRAY) {
height = 1;
@@ -2054,7 +2052,7 @@ static struct pipe_sampler_view
*si_create_sampler_view(struct pipe_context *ctx
}
tiling_index = 8;
- switch (tmp-surface.level[state-u.tex.first_level].mode) {
+ switch (tmp-surface.level[0].mode) {
case RADEON_SURF_MODE_LINEAR_ALIGNED:
tiling_index = 8;
break;
@@ -2095,7 +2093,7 @@ static struct pipe_sampler_view
*si_create_sampler_view(struct pipe_context *ctx
}
va = r600_resource_va(ctx-screen, texture);
- va += tmp-surface.level[offset_level].offset;
+ va += tmp-surface.level[0].offset;
view-state[0] = va 8;
view-state[1] = (S_008F14_BASE_ADDRESS_HI(va 40) |
S_008F14_DATA_FORMAT(format) |
@@ -2106,8 +2104,8 @@ static struct pipe_sampler_view
*si_create_sampler_view(struct pipe_context *ctx
S_008F1C_DST_SEL_Y(si_map_swizzle(swizzle[1])) |
S_008F1C_DST_SEL_Z(si_map_swizzle(swizzle[2])) |
S_008F1C_DST_SEL_W(si_map_swizzle(swizzle[3])) |
- S_008F1C_BASE_LEVEL(offset_level) |
- S_008F1C_LAST_LEVEL(last_level) |
+ S_008F1C_BASE_LEVEL(state-u.tex.first_level) |
+ S_008F1C_LAST_LEVEL(state-u.tex.last_level) |
S_008F1C_TILING_INDEX(tiling_index) |
S_008F1C_TYPE(si_tex_dim(texture-target)));
view-state[4] = (S_008F20_DEPTH(depth - 1) | S_008F20_PITCH(pitch -
1));
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] radeon/llvm: Extend SI EXEC register support.
From: Michel Dänzer michel.daen...@amd.com
Add 32 bit lo and hi variants, and binary encodings.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp |3 +++
src/gallium/drivers/radeon/SIGenRegisterInfo.pl |4 +++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
b/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
index c2b5e47..438d2ac 100644
--- a/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
+++ b/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
@@ -281,6 +281,9 @@ unsigned SIMCCodeEmitter::getEncodingBytes(const MCInst
MI) const {
unsigned SIMCCodeEmitter::getRegBinaryCode(unsigned reg) const {
switch (reg) {
case AMDGPU::M0: return 124;
+case AMDGPU::EXEC: return 126;
+case AMDGPU::EXEC_LO: return 126;
+case AMDGPU::EXEC_HI: return 127;
case AMDGPU::SREG_LIT_0: return 128;
case AMDGPU::SI_LITERAL_CONSTANT: return 255;
default: return getHWRegNum(reg);
diff --git a/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
b/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
index e47fb56..9f8ca52 100644
--- a/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
+++ b/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
@@ -89,6 +89,8 @@ class SGPR_256 bits8 num, string name, listRegister
subregs :
def VCC : SIRegVCC;
def EXEC : SIRegEXEC;
+def EXEC_LO : SIRegEXEC LO;
+def EXEC_HI : SIRegEXEC HI;
def SCC : SIRegSCC;
def SREG_LIT_0 : SIReg S LIT 0;
def SI_LITERAL_CONSTANT : SIRegLITERAL CONSTANT;
@@ -141,7 +143,7 @@ for (my $i = 0; $i $VGPR_COUNT; $i++) {
print STRING;
def SReg_32 : RegisterClassAMDGPU, [f32, i32], 32,
-(add (sequence SGPR%u, 0, $SGPR_MAX_IDX), SREG_LIT_0, M0)
+(add (sequence SGPR%u, 0, $SGPR_MAX_IDX), SREG_LIT_0, M0, EXEC_LO,
EXEC_HI)
;
def VReg_32 : RegisterClassAMDGPU, [f32, i32], 32,
--
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/4] radeon/llvm: SI shader vector instructions implicitly use the EXEC register.
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeon/SIInstrInfo.td |4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeon/SIInstrInfo.td
b/src/gallium/drivers/radeon/SIInstrInfo.td
index 135f279..49ef342 100644
--- a/src/gallium/drivers/radeon/SIInstrInfo.td
+++ b/src/gallium/drivers/radeon/SIInstrInfo.td
@@ -99,6 +99,7 @@ def SMRDmemri : OperandiPTR {
def ADDR_Reg : ComplexPatterni64, 2, SelectADDRReg, [], [];
def ADDR_Offset8 : ComplexPatterni64, 2, SelectADDR8BitOffset, [], [];
+let Uses = [EXEC] in {
def EXP : Enc64
(outs),
(ins i32imm:$en, i32imm:$tgt, i32imm:$compr, i32imm:$done, i32imm:$vm,
@@ -244,6 +245,7 @@ class MUBUF bits7 op, dag outs, dag ins, string asm,
listdag pattern :
let usesCustomInserter = 1;
let neverHasSideEffects = 1;
}
+} // End Uses = [EXEC]
class SMRD bits5 op, dag outs, dag ins, string asm, listdag pattern :
Enc32outs, ins, asm, pattern {
@@ -337,6 +339,7 @@ class SOPP bits7 op, dag ins, string asm, listdag
pattern : Enc32
}
+let Uses = [EXEC] in {
class VINTRP bits 2 op, dag outs, dag ins, string asm, listdag pattern :
Enc32 outs, ins, asm, pattern {
@@ -430,6 +433,7 @@ class VOPC bits8 op, dag ins, string asm, listdag
pattern :
let PostEncoderMethod = VOPPostEncode;
let DisableEncoding = $dst;
}
+} // End Uses = [EXEC]
class MIMG_Load_Helper bits7 op, string asm : MIMG
op,
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] radeon/llvm: Add intrinsic for enabling whole quad mode in SI pixel shaders.
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeon/SIISelLowering.cpp | 13 +
src/gallium/drivers/radeon/SIISelLowering.h |2 ++
src/gallium/drivers/radeon/SIInstructions.td |7 +++
src/gallium/drivers/radeon/SIIntrinsics.td|1 +
4 files changed, 23 insertions(+)
diff --git a/src/gallium/drivers/radeon/SIISelLowering.cpp
b/src/gallium/drivers/radeon/SIISelLowering.cpp
index 2c81673..ebe9514 100644
--- a/src/gallium/drivers/radeon/SIISelLowering.cpp
+++ b/src/gallium/drivers/radeon/SIISelLowering.cpp
@@ -132,6 +132,9 @@ MachineBasicBlock *
SITargetLowering::EmitInstrWithCustomInserter(
case AMDGPU::SI_KIL:
LowerSI_KIL(MI, *BB, I, MRI);
break;
+ case AMDGPU::SI_WQM:
+LowerSI_WQM(MI, *BB, I, MRI);
+break;
case AMDGPU::SI_V_CNDLT:
LowerSI_V_CNDLT(MI, *BB, I, MRI);
break;
@@ -146,6 +149,16 @@ void SITargetLowering::AppendS_WAITCNT(MachineInstr *MI,
MachineBasicBlock BB,
.addImm(0);
}
+
+void SITargetLowering::LowerSI_WQM(MachineInstr *MI, MachineBasicBlock BB,
+MachineBasicBlock::iterator I, MachineRegisterInfo MRI) const
+{
+ BuildMI(BB, I, BB.findDebugLoc(I), TII-get(AMDGPU::S_WQM_B64), AMDGPU::EXEC)
+ .addReg(AMDGPU::EXEC);
+
+ MI-eraseFromParent();
+}
+
void SITargetLowering::LowerSI_INTERP(MachineInstr *MI, MachineBasicBlock BB,
MachineBasicBlock::iterator I, MachineRegisterInfo MRI) const
{
diff --git a/src/gallium/drivers/radeon/SIISelLowering.h
b/src/gallium/drivers/radeon/SIISelLowering.h
index 80c7f4b..4407bf0 100644
--- a/src/gallium/drivers/radeon/SIISelLowering.h
+++ b/src/gallium/drivers/radeon/SIISelLowering.h
@@ -37,6 +37,8 @@ class SITargetLowering : public AMDGPUTargetLowering
MachineBasicBlock::iterator I, MachineRegisterInfo MRI) const;
void LowerSI_KIL(MachineInstr *MI, MachineBasicBlock BB,
MachineBasicBlock::iterator I, MachineRegisterInfo MRI) const;
+ void LowerSI_WQM(MachineInstr *MI, MachineBasicBlock BB,
+ MachineBasicBlock::iterator I, MachineRegisterInfo MRI) const;
void LowerSI_V_CNDLT(MachineInstr *MI, MachineBasicBlock BB,
MachineBasicBlock::iterator I, MachineRegisterInfo MRI) const;
diff --git a/src/gallium/drivers/radeon/SIInstructions.td
b/src/gallium/drivers/radeon/SIInstructions.td
index 20d4c00..2868196 100644
--- a/src/gallium/drivers/radeon/SIInstructions.td
+++ b/src/gallium/drivers/radeon/SIInstructions.td
@@ -986,6 +986,13 @@ def SI_KIL : InstSI
[(int_AMDGPU_kill VReg_32:$src)]
;
+def SI_WQM : InstSI
+ (outs),
+ (ins),
+ SI_WQM,
+ [(int_SI_wqm)]
+;
+
} // end usesCustomInserter
// SI Psuedo branch instructions. These are used by the CFG structurizer pass
diff --git a/src/gallium/drivers/radeon/SIIntrinsics.td
b/src/gallium/drivers/radeon/SIIntrinsics.td
index 401325b..fbb8dc9 100644
--- a/src/gallium/drivers/radeon/SIIntrinsics.td
+++ b/src/gallium/drivers/radeon/SIIntrinsics.td
@@ -20,6 +20,7 @@ let TargetPrefix = SI, isTarget = 1 in {
def int_SI_load_const : Intrinsic [llvm_float_ty], [llvm_i64_ty,
llvm_i32_ty], [];
def int_SI_vs_load_buffer_index : Intrinsic [llvm_i32_ty], [], [IntrNoMem];
def int_SI_vs_load_input : Intrinsic [llvm_v4f32_ty], [llvm_v4i32_ty,
llvm_i16_ty, llvm_i32_ty], [] ;
+ def int_SI_wqm : Intrinsic [], [], [];
def int_SI_sample : Intrinsic [llvm_v4f32_ty], [llvm_i32_ty, llvm_v4f32_ty,
llvm_v8i32_ty, llvm_v4i32_ty];
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] radeonsi: Enable whole quad for pixel shaders.
From: Michel Dänzer michel.daen...@amd.com
Fixes wrong mipmap level being sampled at some triangle edges.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 8c92149..1c330b5 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
@@ -75,7 +75,7 @@ struct si_shader_context
struct tgsi_token * tokens;
struct si_pipe_shader *shader;
unsigned type; /* TGSI_PROCESSOR_* specifies the type of shader. */
-/* unsigned num_inputs; */
+ unsigned ninput_emitted;
/* struct list_head inputs; */
/* unsigned * input_mappings *//* From TGSI to SI hw */
/* struct tgsi_shader_info info;*/
@@ -319,6 +319,14 @@ static void declare_input_fs(
return;
}
+ if (!si_shader_ctx-ninput_emitted++) {
+ /* Enable whole quad mode */
+ lp_build_intrinsic(gallivm-builder,
+ llvm.SI.wqm,
+ LLVMVoidTypeInContext(gallivm-context),
+ NULL, 0);
+ }
+
/* XXX: Could there be more than TGSI_NUM_CHANNELS (4) ? */
for (chan = 0; chan TGSI_NUM_CHANNELS; chan++) {
LLVMValueRef args[3];
@@ -689,7 +697,7 @@ int si_pipe_shader_create(
dump = debug_get_bool_option(RADEON_DUMP_SHADERS, FALSE);
- memset(si_shader_ctx.radeon_bld, 0, sizeof(si_shader_ctx.radeon_bld));
+ memset(si_shader_ctx, 0, sizeof(si_shader_ctx));
radeon_llvm_context_init(si_shader_ctx.radeon_bld);
bld_base = si_shader_ctx.radeon_bld.soa.bld_base;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: Handle more L/A format cases.
From: Michel Dänzer michel.daen...@amd.com
Fixes corresponding cases in piglit fbo-generatemipmap-formats.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/si_state.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 762887d..99c8b1a 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -715,6 +715,9 @@ static uint32_t si_translate_colorformat(enum pipe_format
format)
case PIPE_FORMAT_R16_SINT:
case PIPE_FORMAT_R16_FLOAT:
case PIPE_FORMAT_R16G16_FLOAT:
+ case PIPE_FORMAT_L16_UNORM:
+ case PIPE_FORMAT_I16_UNORM:
+ case PIPE_FORMAT_A16_UNORM:
return V_028C70_COLOR_16;
/* 32-bit buffers. */
@@ -759,6 +762,7 @@ static uint32_t si_translate_colorformat(enum pipe_format
format)
case PIPE_FORMAT_Z32_FLOAT:
return V_028C70_COLOR_32;
+ case PIPE_FORMAT_L16A16_UNORM:
case PIPE_FORMAT_R16G16_SSCALED:
case PIPE_FORMAT_R16G16_UNORM:
case PIPE_FORMAT_R16G16_UINT:
@@ -863,12 +867,17 @@ static uint32_t si_translate_colorswap(enum pipe_format
format)
case PIPE_FORMAT_R8G8_SINT:
return V_028C70_SWAP_STD;
+ case PIPE_FORMAT_I16_UNORM:
+ case PIPE_FORMAT_L16_UNORM:
case PIPE_FORMAT_R16_UNORM:
case PIPE_FORMAT_R16_UINT:
case PIPE_FORMAT_R16_SINT:
case PIPE_FORMAT_R16_FLOAT:
return V_028C70_SWAP_STD;
+ case PIPE_FORMAT_A16_UNORM:
+ return V_028C70_SWAP_ALT_REV;
+
/* 32-bit buffers. */
case PIPE_FORMAT_A8B8G8R8_SRGB:
return V_028C70_SWAP_STD_REV;
@@ -924,6 +933,9 @@ static uint32_t si_translate_colorswap(enum pipe_format
format)
case PIPE_FORMAT_R16G16_SINT:
return V_028C70_SWAP_STD;
+ case PIPE_FORMAT_L16A16_UNORM:
+ return V_028C70_SWAP_ALT;
+
/* 64-bit buffers. */
case PIPE_FORMAT_R32G32_FLOAT:
case PIPE_FORMAT_R32G32_UINT:
@@ -1155,8 +1167,10 @@ static uint32_t si_translate_texformat(struct
pipe_screen *screen,
switch (desc-channel[first_non_void].size) {
case 4:
switch (desc-nr_channels) {
+#if 0 /* Not supported as for render targets */
case 2:
return V_008F14_IMG_DATA_FORMAT_4_4;
+#endif
case 4:
return V_008F14_IMG_DATA_FORMAT_4_4_4_4;
}
--
1.7.10.4
___
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.
On 06/09/2012 08:08, Matt Turner wrote: On Wed, Sep 5, 2012 at 10:48 PM, Vinson Lee v...@freedesktop.org wrote: Signed-off-by: Vinson Lee v...@freedesktop.org --- 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) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radeon/llvm: Extend SI EXEC register support.
On Thu, Sep 06, 2012 at 01:00:00PM +0200, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
Add 32 bit lo and hi variants, and binary encodings.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp |3 +++
src/gallium/drivers/radeon/SIGenRegisterInfo.pl |4 +++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
b/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
index c2b5e47..438d2ac 100644
--- a/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
+++ b/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
@@ -281,6 +281,9 @@ unsigned SIMCCodeEmitter::getEncodingBytes(const MCInst
MI) const {
unsigned SIMCCodeEmitter::getRegBinaryCode(unsigned reg) const {
switch (reg) {
case AMDGPU::M0: return 124;
+case AMDGPU::EXEC: return 126;
+case AMDGPU::EXEC_LO: return 126;
+case AMDGPU::EXEC_HI: return 127;
case AMDGPU::SREG_LIT_0: return 128;
case AMDGPU::SI_LITERAL_CONSTANT: return 255;
default: return getHWRegNum(reg);
diff --git a/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
b/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
index e47fb56..9f8ca52 100644
--- a/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
+++ b/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
@@ -89,6 +89,8 @@ class SGPR_256 bits8 num, string name, listRegister
subregs :
def VCC : SIRegVCC;
def EXEC : SIRegEXEC;
+def EXEC_LO : SIRegEXEC LO;
+def EXEC_HI : SIRegEXEC HI;
We need to tell the compiler that EXEC overlaps EXEC_LO and EXEC_HI, so
the EXEC definition should be changed to subclass SI_64, and EXEC_LO and
EXEC_HI should be passed to the constructor as sub-registers.
-Tom
def SCC : SIRegSCC;
def SREG_LIT_0 : SIReg S LIT 0;
def SI_LITERAL_CONSTANT : SIRegLITERAL CONSTANT;
@@ -141,7 +143,7 @@ for (my $i = 0; $i $VGPR_COUNT; $i++) {
print STRING;
def SReg_32 : RegisterClassAMDGPU, [f32, i32], 32,
-(add (sequence SGPR%u, 0, $SGPR_MAX_IDX), SREG_LIT_0, M0)
+(add (sequence SGPR%u, 0, $SGPR_MAX_IDX), SREG_LIT_0, M0, EXEC_LO,
EXEC_HI)
;
def VReg_32 : RegisterClassAMDGPU, [f32, i32], 32,
--
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 2/4] radeon/llvm: SI shader vector instructions implicitly use the EXEC register.
On Thu, Sep 06, 2012 at 01:00:01PM +0200, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
I'm still not quite sure what the intended use cases are for adding
implicit uses and defs to instructions. I tried to do this with the VCC
register for VOPC and the V_CNDMASK instructions, but the optimizer
was incorrectly marking some instructions dead. It's possible there was
something else I was doing that was wrong, but in any case I think we
should keep an eye on this for potential bugs. Either way, this
change won't hurt anything.
Reviewed-by: Tom Stellard thomas.stell...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeon/SIInstrInfo.td |4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeon/SIInstrInfo.td
b/src/gallium/drivers/radeon/SIInstrInfo.td
index 135f279..49ef342 100644
--- a/src/gallium/drivers/radeon/SIInstrInfo.td
+++ b/src/gallium/drivers/radeon/SIInstrInfo.td
@@ -99,6 +99,7 @@ def SMRDmemri : OperandiPTR {
def ADDR_Reg : ComplexPatterni64, 2, SelectADDRReg, [], [];
def ADDR_Offset8 : ComplexPatterni64, 2, SelectADDR8BitOffset, [], [];
+let Uses = [EXEC] in {
def EXP : Enc64
(outs),
(ins i32imm:$en, i32imm:$tgt, i32imm:$compr, i32imm:$done, i32imm:$vm,
@@ -244,6 +245,7 @@ class MUBUF bits7 op, dag outs, dag ins, string asm,
listdag pattern :
let usesCustomInserter = 1;
let neverHasSideEffects = 1;
}
+} // End Uses = [EXEC]
class SMRD bits5 op, dag outs, dag ins, string asm, listdag pattern :
Enc32outs, ins, asm, pattern {
@@ -337,6 +339,7 @@ class SOPP bits7 op, dag ins, string asm, listdag
pattern : Enc32
}
+let Uses = [EXEC] in {
class VINTRP bits 2 op, dag outs, dag ins, string asm, listdag pattern
:
Enc32 outs, ins, asm, pattern {
@@ -430,6 +433,7 @@ class VOPC bits8 op, dag ins, string asm, listdag
pattern :
let PostEncoderMethod = VOPPostEncode;
let DisableEncoding = $dst;
}
+} // End Uses = [EXEC]
class MIMG_Load_Helper bits7 op, string asm : MIMG
op,
--
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 3/4] radeon/llvm: Add intrinsic for enabling whole quad mode in SI pixel shaders.
On Thu, Sep 06, 2012 at 01:00:02PM +0200, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
Reviewed-by: Tom Stellard thomas.stell...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeon/SIISelLowering.cpp | 13 +
src/gallium/drivers/radeon/SIISelLowering.h |2 ++
src/gallium/drivers/radeon/SIInstructions.td |7 +++
src/gallium/drivers/radeon/SIIntrinsics.td|1 +
4 files changed, 23 insertions(+)
diff --git a/src/gallium/drivers/radeon/SIISelLowering.cpp
b/src/gallium/drivers/radeon/SIISelLowering.cpp
index 2c81673..ebe9514 100644
--- a/src/gallium/drivers/radeon/SIISelLowering.cpp
+++ b/src/gallium/drivers/radeon/SIISelLowering.cpp
@@ -132,6 +132,9 @@ MachineBasicBlock *
SITargetLowering::EmitInstrWithCustomInserter(
case AMDGPU::SI_KIL:
LowerSI_KIL(MI, *BB, I, MRI);
break;
+ case AMDGPU::SI_WQM:
+LowerSI_WQM(MI, *BB, I, MRI);
+break;
case AMDGPU::SI_V_CNDLT:
LowerSI_V_CNDLT(MI, *BB, I, MRI);
break;
@@ -146,6 +149,16 @@ void SITargetLowering::AppendS_WAITCNT(MachineInstr *MI,
MachineBasicBlock BB,
.addImm(0);
}
+
+void SITargetLowering::LowerSI_WQM(MachineInstr *MI, MachineBasicBlock BB,
+MachineBasicBlock::iterator I, MachineRegisterInfo MRI) const
+{
+ BuildMI(BB, I, BB.findDebugLoc(I), TII-get(AMDGPU::S_WQM_B64),
AMDGPU::EXEC)
+ .addReg(AMDGPU::EXEC);
+
+ MI-eraseFromParent();
+}
+
void SITargetLowering::LowerSI_INTERP(MachineInstr *MI, MachineBasicBlock
BB,
MachineBasicBlock::iterator I, MachineRegisterInfo MRI) const
{
diff --git a/src/gallium/drivers/radeon/SIISelLowering.h
b/src/gallium/drivers/radeon/SIISelLowering.h
index 80c7f4b..4407bf0 100644
--- a/src/gallium/drivers/radeon/SIISelLowering.h
+++ b/src/gallium/drivers/radeon/SIISelLowering.h
@@ -37,6 +37,8 @@ class SITargetLowering : public AMDGPUTargetLowering
MachineBasicBlock::iterator I, MachineRegisterInfo MRI) const;
void LowerSI_KIL(MachineInstr *MI, MachineBasicBlock BB,
MachineBasicBlock::iterator I, MachineRegisterInfo MRI)
const;
+ void LowerSI_WQM(MachineInstr *MI, MachineBasicBlock BB,
+ MachineBasicBlock::iterator I, MachineRegisterInfo MRI)
const;
void LowerSI_V_CNDLT(MachineInstr *MI, MachineBasicBlock BB,
MachineBasicBlock::iterator I, MachineRegisterInfo MRI)
const;
diff --git a/src/gallium/drivers/radeon/SIInstructions.td
b/src/gallium/drivers/radeon/SIInstructions.td
index 20d4c00..2868196 100644
--- a/src/gallium/drivers/radeon/SIInstructions.td
+++ b/src/gallium/drivers/radeon/SIInstructions.td
@@ -986,6 +986,13 @@ def SI_KIL : InstSI
[(int_AMDGPU_kill VReg_32:$src)]
;
+def SI_WQM : InstSI
+ (outs),
+ (ins),
+ SI_WQM,
+ [(int_SI_wqm)]
+;
+
} // end usesCustomInserter
// SI Psuedo branch instructions. These are used by the CFG structurizer
pass
diff --git a/src/gallium/drivers/radeon/SIIntrinsics.td
b/src/gallium/drivers/radeon/SIIntrinsics.td
index 401325b..fbb8dc9 100644
--- a/src/gallium/drivers/radeon/SIIntrinsics.td
+++ b/src/gallium/drivers/radeon/SIIntrinsics.td
@@ -20,6 +20,7 @@ let TargetPrefix = SI, isTarget = 1 in {
def int_SI_load_const : Intrinsic [llvm_float_ty], [llvm_i64_ty,
llvm_i32_ty], [];
def int_SI_vs_load_buffer_index : Intrinsic [llvm_i32_ty], [],
[IntrNoMem];
def int_SI_vs_load_input : Intrinsic [llvm_v4f32_ty], [llvm_v4i32_ty,
llvm_i16_ty, llvm_i32_ty], [] ;
+ def int_SI_wqm : Intrinsic [], [], [];
def int_SI_sample : Intrinsic [llvm_v4f32_ty], [llvm_i32_ty,
llvm_v4f32_ty, llvm_v8i32_ty, llvm_v4i32_ty];
--
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 2/4] radeon/llvm: SI shader vector instructions implicitly use the EXEC register.
On Don, 2012-09-06 at 09:45 -0400, Tom Stellard wrote: On Thu, Sep 06, 2012 at 01:00:01PM +0200, Michel Dänzer wrote: From: Michel Dänzer michel.daen...@amd.com I'm still not quite sure what the intended use cases are for adding implicit uses and defs to instructions. I tried to do this with the VCC register for VOPC and the V_CNDMASK instructions, but the optimizer was incorrectly marking some instructions dead. It's possible there was something else I was doing that was wrong, but in any case I think we should keep an eye on this for potential bugs. Yeah, I was hitting similar issues trying to only enable WQM for the parts where it's really needed. I suspect the problem is that implicit uses and defs only reference the physical registers, whereas the optimizer only tracks dependencies between values. But I have no idea yet how that could be addressed in order to e.g. prevent vector instructions from being moved beyond changes to the EXEC register. Either way, this change won't hurt anything. Right, although this does seem to at least prevent the enabling of WQM from being considered dead and removed. Reviewed-by: Tom Stellard thomas.stell...@amd.com Thanks! -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glx: move 'prime' var into #ifdef'd code block
From: Brian Paul bri...@vmware.com
To silence unused var warning.
---
src/glx/dri2.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/src/glx/dri2.c b/src/glx/dri2.c
index 1214cb4..e17da6f 100644
--- a/src/glx/dri2.c
+++ b/src/glx/dri2.c
@@ -269,7 +269,6 @@ DRI2Connect(Display * dpy, XID window, char **driverName,
char **deviceName)
XExtDisplayInfo *info = DRI2FindDisplay(dpy);
xDRI2ConnectReply rep;
xDRI2ConnectReq *req;
- char *prime;
XextCheckExtension(dpy, info, dri2ExtensionName, False);
@@ -281,13 +280,16 @@ DRI2Connect(Display * dpy, XID window, char **driverName,
char **deviceName)
req-driverType = DRI2DriverDRI;
#ifdef DRI2DriverPrimeShift
- prime = getenv(DRI_PRIME);
- if (prime) {
- uint32_t primeid;
- errno = 0;
- primeid = strtoul(prime, NULL, 0);
- if (errno == 0)
- req-driverType |= ((primeid DRI2DriverPrimeMask)
DRI2DriverPrimeShift);
+ {
+ char *prime = getenv(DRI_PRIME);
+ if (prime) {
+ uint32_t primeid;
+ errno = 0;
+ primeid = strtoul(prime, NULL, 0);
+ if (errno == 0)
+req-driverType |=
+ ((primeid DRI2DriverPrimeMask) DRI2DriverPrimeShift);
+ }
}
#endif
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glapi/glx: rename 'table' variable to 'disp_table'
From: Brian Paul bri...@vmware.com
This fixes an issue where the local 'table' variable was hiding the
function parameter name in glGetColorTable(..., void *table).
This should be OK as long as there's never a GL entrypoint that uses
'disp_table' as a parameter name.
Note: This is a candidate for the 9.0 branch.
---
src/mapi/glapi/gen/glX_proto_send.py |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index d42f661..34aa2c3 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -423,9 +423,9 @@ __indirect_get_proc_address(const char *name)
print ''
print '#if defined(GLX_DIRECT_RENDERING)
!defined(GLX_USE_APPLEGL)'
print 'if (gc-isDirect) {'
- print 'const _glapi_proc *const table =
GET_DISPATCH();'
+ print 'const _glapi_proc *const
disp_table = GET_DISPATCH();'
print 'PFNGL%sPROC p =' % (name.upper())
- print '(PFNGL%sPROC) table[%d];' %
(name.upper(), func.offset)
+ print '(PFNGL%sPROC)
disp_table[%d];' % (name.upper(), func.offset)
print '%sp(%s);' % (ret_string,
func.get_called_parameter_string())
print '} else'
print '#endif'
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Handle more L/A format cases.
On Thu, Sep 6, 2012 at 7:04 AM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
Fixes corresponding cases in piglit fbo-generatemipmap-formats.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/radeonsi/si_state.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 762887d..99c8b1a 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -715,6 +715,9 @@ static uint32_t si_translate_colorformat(enum pipe_format
format)
case PIPE_FORMAT_R16_SINT:
case PIPE_FORMAT_R16_FLOAT:
case PIPE_FORMAT_R16G16_FLOAT:
+ case PIPE_FORMAT_L16_UNORM:
+ case PIPE_FORMAT_I16_UNORM:
+ case PIPE_FORMAT_A16_UNORM:
return V_028C70_COLOR_16;
/* 32-bit buffers. */
@@ -759,6 +762,7 @@ static uint32_t si_translate_colorformat(enum pipe_format
format)
case PIPE_FORMAT_Z32_FLOAT:
return V_028C70_COLOR_32;
+ case PIPE_FORMAT_L16A16_UNORM:
case PIPE_FORMAT_R16G16_SSCALED:
case PIPE_FORMAT_R16G16_UNORM:
case PIPE_FORMAT_R16G16_UINT:
@@ -863,12 +867,17 @@ static uint32_t si_translate_colorswap(enum pipe_format
format)
case PIPE_FORMAT_R8G8_SINT:
return V_028C70_SWAP_STD;
+ case PIPE_FORMAT_I16_UNORM:
+ case PIPE_FORMAT_L16_UNORM:
case PIPE_FORMAT_R16_UNORM:
case PIPE_FORMAT_R16_UINT:
case PIPE_FORMAT_R16_SINT:
case PIPE_FORMAT_R16_FLOAT:
return V_028C70_SWAP_STD;
+ case PIPE_FORMAT_A16_UNORM:
+ return V_028C70_SWAP_ALT_REV;
+
/* 32-bit buffers. */
case PIPE_FORMAT_A8B8G8R8_SRGB:
return V_028C70_SWAP_STD_REV;
@@ -924,6 +933,9 @@ static uint32_t si_translate_colorswap(enum pipe_format
format)
case PIPE_FORMAT_R16G16_SINT:
return V_028C70_SWAP_STD;
+ case PIPE_FORMAT_L16A16_UNORM:
+ return V_028C70_SWAP_ALT;
+
/* 64-bit buffers. */
case PIPE_FORMAT_R32G32_FLOAT:
case PIPE_FORMAT_R32G32_UINT:
@@ -1155,8 +1167,10 @@ static uint32_t si_translate_texformat(struct
pipe_screen *screen,
switch (desc-channel[first_non_void].size) {
case 4:
switch (desc-nr_channels) {
+#if 0 /* Not supported as for render targets */
case 2:
return V_008F14_IMG_DATA_FORMAT_4_4;
+#endif
case 4:
return V_008F14_IMG_DATA_FORMAT_4_4_4_4;
}
--
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/4] radeonsi: Untiled textures are linear aligned, not linear general.
On Thu, Sep 6, 2012 at 6:55 AM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
for the series:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/radeonsi/r600_texture.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/r600_texture.c
b/src/gallium/drivers/radeonsi/r600_texture.c
index 5b831fd..0b908c8 100644
--- a/src/gallium/drivers/radeonsi/r600_texture.c
+++ b/src/gallium/drivers/radeonsi/r600_texture.c
@@ -523,7 +523,7 @@ struct pipe_resource *si_texture_create(struct
pipe_screen *screen,
{
struct r600_screen *rscreen = (struct r600_screen*)screen;
struct radeon_surface surface;
- unsigned array_mode = 0;
+ unsigned array_mode = V_009910_ARRAY_LINEAR_ALIGNED;
int r;
#if 0
@@ -589,7 +589,7 @@ struct pipe_resource *si_texture_from_handle(struct
pipe_screen *screen,
struct r600_screen *rscreen = (struct r600_screen*)screen;
struct pb_buffer *buf = NULL;
unsigned stride = 0;
- unsigned array_mode = 0;
+ unsigned array_mode = V_009910_ARRAY_LINEAR_ALIGNED;
enum radeon_bo_layout micro, macro;
struct radeon_surface surface;
int r;
@@ -614,7 +614,7 @@ struct pipe_resource *si_texture_from_handle(struct
pipe_screen *screen,
else if (micro == RADEON_LAYOUT_TILED)
array_mode = V_009910_ARRAY_1D_TILED_THIN1;
else
- array_mode = 0;
+ array_mode = V_009910_ARRAY_LINEAR_ALIGNED;
r = r600_init_surface(surface, templ, array_mode);
if (r) {
--
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
[Mesa-dev] [PATCH 1/4 v2] radeon/llvm: Extend SI EXEC register support.
From: Michel Dänzer michel.daen...@amd.com
Add 32 bit lo and hi variants, and binary encodings.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
v2: Make EXEC subclass SI_64, and pass in EXEC_LO and EXEC_HI as overlapping
sub-registers. Is this what you meant, Tom?
src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp |3 +++
src/gallium/drivers/radeon/SIGenRegisterInfo.pl |6 --
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
b/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
index c2b5e47..438d2ac 100644
--- a/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
+++ b/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
@@ -281,6 +281,9 @@ unsigned SIMCCodeEmitter::getEncodingBytes(const MCInst
MI) const {
unsigned SIMCCodeEmitter::getRegBinaryCode(unsigned reg) const {
switch (reg) {
case AMDGPU::M0: return 124;
+case AMDGPU::EXEC: return 126;
+case AMDGPU::EXEC_LO: return 126;
+case AMDGPU::EXEC_HI: return 127;
case AMDGPU::SREG_LIT_0: return 128;
case AMDGPU::SI_LITERAL_CONSTANT: return 255;
default: return getHWRegNum(reg);
diff --git a/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
b/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
index e47fb56..3813eb5 100644
--- a/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
+++ b/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
@@ -88,7 +88,9 @@ class SGPR_256 bits8 num, string name, listRegister
subregs :
SI_256 name, subregs;
def VCC : SIRegVCC;
-def EXEC : SIRegEXEC;
+def EXEC_LO : SIRegEXEC LO;
+def EXEC_HI : SIRegEXEC HI;
+def EXEC : SI_64EXEC, [EXEC_LO,EXEC_HI];
def SCC : SIRegSCC;
def SREG_LIT_0 : SIReg S LIT 0;
def SI_LITERAL_CONSTANT : SIRegLITERAL CONSTANT;
@@ -141,7 +143,7 @@ for (my $i = 0; $i $VGPR_COUNT; $i++) {
print STRING;
def SReg_32 : RegisterClassAMDGPU, [f32, i32], 32,
-(add (sequence SGPR%u, 0, $SGPR_MAX_IDX), SREG_LIT_0, M0)
+(add (sequence SGPR%u, 0, $SGPR_MAX_IDX), SREG_LIT_0, M0, EXEC_LO,
EXEC_HI)
;
def VReg_32 : RegisterClassAMDGPU, [f32, i32], 32,
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4 v2] radeon/llvm: Extend SI EXEC register support.
On Thu, Sep 06, 2012 at 04:32:32PM +0200, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
Add 32 bit lo and hi variants, and binary encodings.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
v2: Make EXEC subclass SI_64, and pass in EXEC_LO and EXEC_HI as overlapping
sub-registers. Is this what you meant, Tom?
Yes, looks good.
Reviewed-by: Tom Stellard thomas.stell...@amd.com
src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp |3 +++
src/gallium/drivers/radeon/SIGenRegisterInfo.pl |6 --
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
b/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
index c2b5e47..438d2ac 100644
--- a/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
+++ b/src/gallium/drivers/radeon/MCTargetDesc/SIMCCodeEmitter.cpp
@@ -281,6 +281,9 @@ unsigned SIMCCodeEmitter::getEncodingBytes(const MCInst
MI) const {
unsigned SIMCCodeEmitter::getRegBinaryCode(unsigned reg) const {
switch (reg) {
case AMDGPU::M0: return 124;
+case AMDGPU::EXEC: return 126;
+case AMDGPU::EXEC_LO: return 126;
+case AMDGPU::EXEC_HI: return 127;
case AMDGPU::SREG_LIT_0: return 128;
case AMDGPU::SI_LITERAL_CONSTANT: return 255;
default: return getHWRegNum(reg);
diff --git a/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
b/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
index e47fb56..3813eb5 100644
--- a/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
+++ b/src/gallium/drivers/radeon/SIGenRegisterInfo.pl
@@ -88,7 +88,9 @@ class SGPR_256 bits8 num, string name, listRegister
subregs :
SI_256 name, subregs;
def VCC : SIRegVCC;
-def EXEC : SIRegEXEC;
+def EXEC_LO : SIRegEXEC LO;
+def EXEC_HI : SIRegEXEC HI;
+def EXEC : SI_64EXEC, [EXEC_LO,EXEC_HI];
def SCC : SIRegSCC;
def SREG_LIT_0 : SIReg S LIT 0;
def SI_LITERAL_CONSTANT : SIRegLITERAL CONSTANT;
@@ -141,7 +143,7 @@ for (my $i = 0; $i $VGPR_COUNT; $i++) {
print STRING;
def SReg_32 : RegisterClassAMDGPU, [f32, i32], 32,
-(add (sequence SGPR%u, 0, $SGPR_MAX_IDX), SREG_LIT_0, M0)
+(add (sequence SGPR%u, 0, $SGPR_MAX_IDX), SREG_LIT_0, M0, EXEC_LO,
EXEC_HI)
;
def VReg_32 : RegisterClassAMDGPU, [f32, i32], 32,
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] radeonsi: Enable whole quad for pixel shaders.
On Thu, Sep 06, 2012 at 01:00:03PM +0200, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
Fixes wrong mipmap level being sampled at some triangle edges.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
Reviewed-by: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 8c92149..1c330b5 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
@@ -75,7 +75,7 @@ struct si_shader_context
struct tgsi_token * tokens;
struct si_pipe_shader *shader;
unsigned type; /* TGSI_PROCESSOR_* specifies the type of shader. */
-/* unsigned num_inputs; */
+ unsigned ninput_emitted;
/* struct list_head inputs; */
/* unsigned * input_mappings *//* From TGSI to SI hw */
/* struct tgsi_shader_info info;*/
@@ -319,6 +319,14 @@ static void declare_input_fs(
return;
}
+ if (!si_shader_ctx-ninput_emitted++) {
+ /* Enable whole quad mode */
+ lp_build_intrinsic(gallivm-builder,
+llvm.SI.wqm,
+LLVMVoidTypeInContext(gallivm-context),
+NULL, 0);
+ }
+
/* XXX: Could there be more than TGSI_NUM_CHANNELS (4) ? */
for (chan = 0; chan TGSI_NUM_CHANNELS; chan++) {
LLVMValueRef args[3];
@@ -689,7 +697,7 @@ int si_pipe_shader_create(
dump = debug_get_bool_option(RADEON_DUMP_SHADERS, FALSE);
- memset(si_shader_ctx.radeon_bld, 0, sizeof(si_shader_ctx.radeon_bld));
+ memset(si_shader_ctx, 0, sizeof(si_shader_ctx));
radeon_llvm_context_init(si_shader_ctx.radeon_bld);
bld_base = si_shader_ctx.radeon_bld.soa.bld_base;
--
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
[Mesa-dev] [Bug 54600] New: pbuffer_reference_openvg_image() not implemented (egl_g3d_st.c)
https://bugs.freedesktop.org/show_bug.cgi?id=54600
Bug #: 54600
Summary: pbuffer_reference_openvg_image() not implemented
(egl_g3d_st.c)
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: medium
Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: candid...@gmail.com
Hi all!
File egl_g3d_st.c implements pbuffer_reference_openvg_image() like that:
static void
pbuffer_reference_openvg_image(struct egl_g3d_surface *gsurf)
{
/* TODO */
}
Hence, using EGL functions like described in OpenVG Specification Version 1.1,
section 4.2.2 EGL Functions, subsection eglCreatePbufferFromClientBuffer (page
32) does not work. I tried the following code:
VGImage image = vgCreateImage(VG_sARGB_, surfaceWidth, surfaceHeight,
VG_IMAGE_QUALITY_BETTER);
eglSurface = eglCreatePbufferFromClientBuffer(eglDisplay, EGL_OPENVG_IMAGE,
(EGLClientBuffer)image,
eglConfig, NULL);
It runs into the empty implemented function pbuffer_reference_openvg_image()
and thereafter fails.
Is there any alternative way to use OpenVG and EGL to render to a pbuffer/image
surface!?
Best regards,
Fred
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: order atom emission
On Thu, Sep 6, 2012 at 10:54 AM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Sep 6, 2012 at 6:20 AM, Dave Airlie airl...@gmail.com wrote: On Thu, Sep 6, 2012 at 5:21 PM, Philipp Klaus Krause p...@spth.de wrote: On 06.09.2012 07:35, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com 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 Note that i have been told that in the r100/r200 days same issue came up and registers needed to be written in some specific order (well only some register matter but i doubt we have a good knowledge on that). Cheers, Jerome ___ 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 2/2] glapi/glx: rename 'table' variable to 'disp_table'
Both patches look good.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Jose
- Original Message -
From: Brian Paul bri...@vmware.com
This fixes an issue where the local 'table' variable was hiding the
function parameter name in glGetColorTable(..., void *table).
This should be OK as long as there's never a GL entrypoint that uses
'disp_table' as a parameter name.
Note: This is a candidate for the 9.0 branch.
---
src/mapi/glapi/gen/glX_proto_send.py |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index d42f661..34aa2c3 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -423,9 +423,9 @@ __indirect_get_proc_address(const char *name)
print ''
print '#if defined(GLX_DIRECT_RENDERING)
!defined(GLX_USE_APPLEGL)'
print 'if (gc-isDirect) {'
- print 'const _glapi_proc *const table =
GET_DISPATCH();'
+ print 'const _glapi_proc *const
disp_table =
GET_DISPATCH();'
print 'PFNGL%sPROC p =' % (name.upper())
- print '(PFNGL%sPROC) table[%d];' %
(name.upper(),
func.offset)
+ print '(PFNGL%sPROC)
disp_table[%d];' %
(name.upper(), func.offset)
print '%sp(%s);' % (ret_string,
func.get_called_parameter_string())
print '} else'
print '#endif'
--
1.7.4.1
___
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 3/3] winsys/radeon: disable virtual address space by default
On Fri, Aug 31, 2012 at 7:08 AM, Michel Dänzer mic...@daenzer.net wrote: On Don, 2012-08-30 at 17:35 +0200, Marek Olšák wrote: This fixes hangs on Cayman. Note that at least some of those hangs are due to pre-existing out-of-bounds memory access bugs which happen not to cause any serious problems without virtual address space. Enabling it can help pinpoint those bugs using the virtual memory protection fault address. I tried to allocate twice as much memory for every r600g resource and it still hung. I am out of ideas and I see no easy way to debug that, because the soft reset just doesn't work. I don't even remember when the soft reset worked last time. It's been so long. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] winsys/radeon: disable virtual address space by default
On 06.09.2012 17:42, Marek Olšák wrote: On Fri, Aug 31, 2012 at 7:08 AM, Michel Dänzer mic...@daenzer.net wrote: On Don, 2012-08-30 at 17:35 +0200, Marek Olšák wrote: This fixes hangs on Cayman. Note that at least some of those hangs are due to pre-existing out-of-bounds memory access bugs which happen not to cause any serious problems without virtual address space. Enabling it can help pinpoint those bugs using the virtual memory protection fault address. I tried to allocate twice as much memory for every r600g resource and it still hung. I am out of ideas and I see no easy way to debug that, because the soft reset just doesn't work. I don't even remember when the soft reset worked last time. It's been so long. Currently working on that and already have a patch that instead of locking the GPU hard just redirects every invalid memory access to the dummy page and prints a nice warning into the syslog that userspace is doing something nasty. Seems to work allot better than just hanging everything on the first sign of problems. Give me a day or two to sort that out, Christian. Marek ___ 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] r600g: order atom emission
On Thu, Sep 6, 2012 at 11:32 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Sep 6, 2012 at 10:54 AM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Sep 6, 2012 at 6:20 AM, Dave Airlie airl...@gmail.com wrote: On Thu, Sep 6, 2012 at 5:21 PM, Philipp Klaus Krause p...@spth.de wrote: On 06.09.2012 07:35, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com 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 Yeah it's possible that it's also related to some register need to be re-emitted, i often see that fglrx is re-emitting some register even if it emitted it with same value just before and some register are emitted several time around other register block. Anyhow this patch is a first step to atomize everything and match fglrx register pattern more closely. Cheers, Jerome ___ 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.
On Thu, Sep 6, 2012 at 4:19 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 06/09/2012 08:08, Matt Turner wrote: On Wed, Sep 5, 2012 at 10:48 PM, Vinson Lee v...@freedesktop.org wrote: Signed-off-by: Vinson Lee v...@freedesktop.org --- 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. ___ 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
Am 06.09.2012 16:54, schrieb Jerome Glisse: On Thu, Sep 6, 2012 at 6:20 AM, Dave Airlie airl...@gmail.com wrote: On Thu, Sep 6, 2012 at 5:21 PM, Philipp Klaus Krause p...@spth.de wrote: On 06.09.2012 07:35, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com 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. Note that i have been told that in the r100/r200 days same issue came up and registers needed to be written in some specific order (well only some register matter but i doubt we have a good knowledge on that). Yes, we had a similar problem with r200/r100, though IIRC it only affected hw vp (TCL). Though I never saw lockups due to that, some tris had color flickering. It was eventually fixed by fixed order emission of the atoms, though we never figured out the reason why it was needed (or what the order really should be). Quite possible some registers had some dependencies on others. Roland ___ 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.
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.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Project: gtk-glxinfo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/05/2012 05:03 PM, Matt Turner wrote: So, I was going to give it a try, but then I saw that I'd have to get the sources from SVN. No thanks. :( Also, you've got some crap in your SVN repo. Debug, autom4te.cache, po. Matt, Sorry you feel that way, but anyway I have made a tar.gz file available in the downloads area incase you want to take a look. I have cleaned up some of the crap, but intend to leave the po folder so that translations can be done for the labels. http://code.google.com/p/gtk-glxinfo/ Thanks, Kevin - -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x7D0BD5D1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBI/AIACgkQ6w2kMH0L1dE4bwCghRmnlSkqX1rPiqJ3yiSouOxe XgMAn0rd9Zs533wmgn+WWaB562RZMDgu =e6sg -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 54431] [build errors] (.text+0x324): undefined reference to `dlopen'
https://bugs.freedesktop.org/show_bug.cgi?id=54431 --- Comment #2 from Fabio Pedretti fabio@libero.it 2012-09-06 20:03:55 UTC --- (In reply to comment #1) The errors go away if I also add --with-gallium-drivers= but I supposes it should not be needed since I already specified --disable-dri. No, the Gallium drivers can be built without DRI. Consider cases like OpenVG or another state tracker. It looks like you're trying to do an OSMesa build? In that case, Gallium does nothing for you, so disable it. I think this should be RESOLVED/INVALID. This can be OK, but, even better, OSMesa + Gallium should be forbidden by configure rather than later fails to compile. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: order atom emission v2
On Thu, Sep 6, 2012 at 8:34 PM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Sep 6, 2012 at 2:29 PM, Marek Olšák mar...@gmail.com wrote: This looks good to me. It's funny to see the r300g architecture being re-implemented in r600g. :) There's one optimization that r300g has that this patch doesn't. r300g keeps the index of the first and the last dirty atom and the loops over the list of atoms look like this: for (i = first_dirty; i = last_dirty; i++) And after emission: first_dirty = some large number; last_dirty= 0; The atoms should be ordered according to how frequently they are updated (except when the ordering is required by the hw). But most importantly, if there are no state changes, the loops are trivially skipped. Marek Don't think this optimization is worth it, there won't be much more than 32 atom in the end and it definitely can't be ordered from most frequent to less frequent as some of the stuff need to be at the last being emitted and they are frequent one (primitive type for instance). I didn't say all atoms *must* be sorted. I meant that some (most?) atoms can be sorted, i.e. you can have some atoms at fixed positions (like the primitype type or the seamless cubemap state), but you have always at least *some* freedom where you put the rest. The ordering I had in mind was actually from the least frequent to the most frequent, in other words, from the framebuffer (least frequent) to shaders to textures to constant buffers to vertex buffers (most frequent). Of course, the code should document which atoms must have fixed positions along with an explanation. The comment that all atom positions must not be changed isn't enough, because it's not true. Marek ___ 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 v2
On Thu, Sep 6, 2012 at 4:10 PM, Marek Olšák mar...@gmail.com wrote: On Thu, Sep 6, 2012 at 8:34 PM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Sep 6, 2012 at 2:29 PM, Marek Olšák mar...@gmail.com wrote: This looks good to me. It's funny to see the r300g architecture being re-implemented in r600g. :) There's one optimization that r300g has that this patch doesn't. r300g keeps the index of the first and the last dirty atom and the loops over the list of atoms look like this: for (i = first_dirty; i = last_dirty; i++) And after emission: first_dirty = some large number; last_dirty= 0; The atoms should be ordered according to how frequently they are updated (except when the ordering is required by the hw). But most importantly, if there are no state changes, the loops are trivially skipped. Marek Don't think this optimization is worth it, there won't be much more than 32 atom in the end and it definitely can't be ordered from most frequent to less frequent as some of the stuff need to be at the last being emitted and they are frequent one (primitive type for instance). I didn't say all atoms *must* be sorted. I meant that some (most?) atoms can be sorted, i.e. you can have some atoms at fixed positions (like the primitype type or the seamless cubemap state), but you have always at least *some* freedom where you put the rest. The ordering I had in mind was actually from the least frequent to the most frequent, in other words, from the framebuffer (least frequent) to shaders to textures to constant buffers to vertex buffers (most frequent). Of course, the code should document which atoms must have fixed positions along with an explanation. The comment that all atom positions must not be changed isn't enough, because it's not true. Marek I won't try to find which atom can have complete floating position, i am just grouping together register that are always emitted together in fglrx and then i position this group relative to each other according to fglrx position. That means all atom are always emitted in a specific order. So there won't be any freedom. The only freedom i can think of is btw 2 position forced atom and that make the sorting completely useless and complicated. Cheers, Jerome ___ 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.
On 09/06/2012 09:08 AM, Vinson Lee wrote: On Thu, Sep 6, 2012 at 4:19 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 06/09/2012 08:08, Matt Turner wrote: On Wed, Sep 5, 2012 at 10:48 PM, Vinson Lee v...@freedesktop.org wrote: Signed-off-by: Vinson Lee v...@freedesktop.org --- 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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/msaa: Allow X and Y flips in multisampled blits.
On Wed, Sep 5, 2012 at 4:22 PM, Paul Berry stereotype...@gmail.com wrote:
From the GL 4.3 spec, section 18.3.1 Blitting Pixel Rectangles:
If SAMPLE_BUFFERS for either the read framebuffer or draw
framebuffer is greater than zero, no copy is performed and an
INVALID_OPERATION error is generated if the dimensions of the
source and destination rectangles provided to BlitFramebuffer are
not identical, or if the formats of the read and draw framebuffers
are not identical.
It is not clear from the spec whether dimensions should mean both
sign and magnitude, or just magnitude.
Previously, Mesa interpreted dimensions as meaning both sign and
magnitude, so any multisampled blit that attempted to flip the image
in the X and/or Y direction would fail.
However, Y flips are likely to be commonplace in OpenGL applications
that have been ported from DirectX applications, as a result of the
fact that DirectX and OpenGL differ in their orientation of the Y
axis. Furthermore, at least one commercial driver (nVidia) permits Y
filps, and L4D2 relies on them being permitted. So it seems prudent
for Mesa to permit them.
This patch changes Mesa to allow both X and Y flips, since there is no
language in the spec to indicate that X and Y flips should be treated
differently.
NOTE: This is a candidate for stable release branches.
---
src/mesa/main/fbobject.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 59a5ec3..abc9d83 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2979,8 +2979,8 @@ _mesa_BlitFramebufferEXT(GLint srcX0, GLint srcY0,
GLint srcX1, GLint srcY1,
/* extra checks for multisample copies... */
if (readFb-Visual.samples 0 || drawFb-Visual.samples 0) {
/* src and dest region sizes must be the same */
- if (srcX1 - srcX0 != dstX1 - dstX0 ||
- srcY1 - srcY0 != dstY1 - dstY0) {
+ if (abs(srcX1 - srcX0) != abs(dstX1 - dstX0) ||
+ abs(srcY1 - srcY0) != abs(dstY1 - dstY0)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
glBlitFramebufferEXT(bad src/dst multisample region
sizes));
return;
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 54326] When building 32 bit on 64 bit, build ends at libgbm saying it can't find 32 bit libkms.so
https://bugs.freedesktop.org/show_bug.cgi?id=54326 --- Comment #4 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-09-06 23:54:13 UTC --- Created attachment 66753 -- https://bugs.freedesktop.org/attachment.cgi?id=66753 Makefile shows many libs located under 64bit folder instead of 32 Many paths point to 64bit libraries: LIBDRM_CFLAGS = -I/usr/include/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu/libdrm LIBDRM_LIBS = -L/usr/lib/i386-linux-gnu/ -ldrm LIBDRM_XORG_CFLAGS = -I/usr/include/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu/libdrm LIBDRM_XORG_LIBS = -L/usr/lib/x86_64-linux-gnu -ldrm LIBKMS_CFLAGS = -I/usr/include/x86_64-linux-gnu/libkms LIBKMS_LIBS = -L/usr/lib/x86_64-linux-gnu -lkms LIBKMS_XORG_CFLAGS = -I/usr/include/x86_64-linux-gnu/libkms LIBKMS_XORG_LIBS = -L/usr/lib/x86_64-linux-gnu -lkms However, LIBUDEV_CFLAGS = LIBUDEV_LIBS = -ludev -lrt are correctly dynamically found and LIB_DIR = i386-linux-gnu points to the good lib folder. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: order atom emission v2
On Fri, Sep 7, 2012 at 12:05 AM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Sep 6, 2012 at 4:10 PM, Marek Olšák mar...@gmail.com wrote: On Thu, Sep 6, 2012 at 8:34 PM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Sep 6, 2012 at 2:29 PM, Marek Olšák mar...@gmail.com wrote: This looks good to me. It's funny to see the r300g architecture being re-implemented in r600g. :) There's one optimization that r300g has that this patch doesn't. r300g keeps the index of the first and the last dirty atom and the loops over the list of atoms look like this: for (i = first_dirty; i = last_dirty; i++) And after emission: first_dirty = some large number; last_dirty= 0; The atoms should be ordered according to how frequently they are updated (except when the ordering is required by the hw). But most importantly, if there are no state changes, the loops are trivially skipped. Marek Don't think this optimization is worth it, there won't be much more than 32 atom in the end and it definitely can't be ordered from most frequent to less frequent as some of the stuff need to be at the last being emitted and they are frequent one (primitive type for instance). I didn't say all atoms *must* be sorted. I meant that some (most?) atoms can be sorted, i.e. you can have some atoms at fixed positions (like the primitype type or the seamless cubemap state), but you have always at least *some* freedom where you put the rest. The ordering I had in mind was actually from the least frequent to the most frequent, in other words, from the framebuffer (least frequent) to shaders to textures to constant buffers to vertex buffers (most frequent). Of course, the code should document which atoms must have fixed positions along with an explanation. The comment that all atom positions must not be changed isn't enough, because it's not true. Marek I won't try to find which atom can have complete floating position, i am just grouping together register that are always emitted together in fglrx and then i position this group relative to each other according to fglrx position. That means all atom are always emitted in a specific order. So there won't be any freedom. The only freedom i can think of is btw 2 position forced atom and that make the sorting completely useless and complicated. I'll add the optimization anyway (without sorting). Draw operations without state changes or with only one state update are quite common. Anyway, it was said in the v1 thread that the hardware doesn't need any specific ordering for proper functioning. While it may be beneficial to emit one or two registers earlier than the others, insisting on fixed ordering of all of them is not only limiting, it seems useless and waste of time as well. What I don't understand: Why do you blindly copy everything fglrx *seems* to be doing without any real reason? It does not fix any bug, it does not improve performance, it does not clean up the code... so why? I am all ears. Marek ___ 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 alexandre.f.dem...@gmail.com changed: What|Removed |Added Summary|When building 32 bit on 64 |When building 32 bit on 64 |bit, build ends at libgbm |bit, many lib path |saying it can't find 32 bit |variables are not pointing |libkms.so |to 32 bit folders. Version|unspecified |git --- Comment #5 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-09-07 04:20:54 UTC --- OK, things are improving: by specifying export PKG_CONFIG_PATH='/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig' Like that, pkg-config will look in both directories to find whatever it needs (32bit or 64bit files). I'm now able to go through the libgbm.so build. However, I don't know how this should properly be fixed in the configure.ac file. Now I hit a different wall with llvm where it goes through the specified folders, but can't find what it is looking for: Making all in llvmpipe make[4]: Entering directory `/home/dema1701/projects/display/mesa/src/gallium/drivers/llvmpipe' g++ -L/usr/lib/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 /usr/bin/ld: skipping incompatible /usr/lib32/libpthread.so when searching for -lpthread /usr/bin/ld: skipping incompatible /usr/lib32/libpthread.a when searching for -lpthread /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libpthread.so when searching for -lpthread /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libpthread.a when searching for -lpthread /usr/bin/ld: skipping incompatible /usr/lib32/libffi.so when searching for -lffi /usr/bin/ld: skipping incompatible /usr/lib32/libffi.a when searching for -lffi /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libffi.so when searching for -lffi /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libffi.a when searching for -lffi /usr/bin/ld: skipping incompatible /usr/lib32/libdl.so when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib32/libdl.a when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libdl.so when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libdl.a when searching for -ldl /usr/bin/ld: skipping incompatible ../../auxiliary//libgallium.a when searching for -lgallium /usr/bin/ld: cannot find -lgallium /usr/bin/ld: skipping incompatible /usr/lib32/libXext.so when searching for -lXext /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libXext.so when searching for -lXext /usr/bin/ld: skipping incompatible /usr/lib32/libXdamage.so when searching for -lXdamage /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libXdamage.so when searching for -lXdamage /usr/bin/ld: skipping incompatible /usr/lib32/libXfixes.so when searching for -lXfixes /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libXfixes.so when searching for -lXfixes /usr/bin/ld: skipping incompatible /usr/lib32/libX11-xcb.so when searching for -lX11-xcb /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libX11-xcb.so when searching for -lX11-xcb /usr/bin/ld: skipping incompatible /usr/lib32/libX11.so when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libX11.so when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/lib32/libxcb-glx.so when searching for -lxcb-glx /usr/bin/ld: skipping incompatible /usr/lib32/libxcb-glx.a when searching for -lxcb-glx /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libxcb-glx.so when searching for -lxcb-glx /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libxcb-glx.a when searching for -lxcb-glx /usr/bin/ld: skipping incompatible /usr/lib32/libxcb.so when searching for -lxcb /usr/bin/ld: skipping incompatible /usr/lib32/libxcb.a when searching for -lxcb /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libxcb.so when searching for -lxcb /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu//libxcb.a when searching for -lxcb /usr/bin/ld: skipping incompatible /usr/lib32/libXxf86vm.so when searching for -lXxf86vm /usr/bin/ld: skipping incompatible
[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 --- Comment #6 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-09-07 04:24:52 UTC --- Seems to be related to bug 36242. It seems the best solution is still a chroot environment. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build/glsl: Add missing extension for builtin_compiler.
On Thu, Sep 6, 2012 at 3:21 PM, Kenneth Graunke kenn...@whitecape.org wrote: On 09/06/2012 09:08 AM, Vinson Lee wrote: On Thu, Sep 6, 2012 at 4:19 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 06/09/2012 08:08, Matt Turner wrote: On Wed, Sep 5, 2012 at 10:48 PM, Vinson Lee v...@freedesktop.org wrote: Signed-off-by: Vinson Lee v...@freedesktop.org --- 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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
