Re: [Mesa-dev] [PATCH 11/14] R600/SI: add OMOD patterns
On Mit, 2013-02-20 at 18:46 +0100, Christian König wrote: > > diff --git a/lib/Target/R600/SIInstructions.td > b/lib/Target/R600/SIInstructions.td > index 833e6cd..7c157e9 100644 > --- a/lib/Target/R600/SIInstructions.td > +++ b/lib/Target/R600/SIInstructions.td > @@ -1232,6 +1232,24 @@ def : Pat < > 0 /* ABS */, 0 /* CLAMP */, 0 /* OMOD */, 1 /* NEG */) > >; > > +def : Pat < > + (fmul VReg_32:$src, (f32 FP_0_5)), > + (V_ADD_F32_e64 VReg_32:$src, (i32 0x80 /* SRC1 */), > + 0 /* ABS */, 0 /* CLAMP */, 3 /* OMOD */, 0 /* NEG */) > +>; > + > +def : Pat < > + (fmul VReg_32:$src, (f32 FP_TWO)), > + (V_ADD_F32_e64 VReg_32:$src, (i32 0x80 /* SRC1 */), > + 0 /* ABS */, 0 /* CLAMP */, 1 /* OMOD */, 0 /* NEG */) > +>; > + > +def : Pat < > + (fmul VReg_32:$src, (f32 FP_FOUR)), > + (V_ADD_F32_e64 VReg_32:$src, (i32 0x80 /* SRC1 */), > + 0 /* ABS */, 0 /* CLAMP */, 2 /* OMOD */, 0 /* NEG */) > +>; Is there any advantage to doing it like this as opposed to using V_MUL_F32_e32 with the corresponding inline constant source operands? I guess it could work for SGPRs as the source as well, if the patterns used VSrc instead of VReg, but otherwise MUL would result in more compact code. -- 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
Re: [Mesa-dev] [PATCH 09/14] R600/SI: add all the other missing asm operands
On Mit, 2013-02-20 at 18:46 +0100, Christian König wrote:
>
> diff --git a/lib/Target/R600/SIInstructions.td
> b/lib/Target/R600/SIInstructions.td
> index 700b8f8..866c7cb 100644
> --- a/lib/Target/R600/SIInstructions.td
> +++ b/lib/Target/R600/SIInstructions.td
> @@ -620,7 +620,7 @@ def V_INTERP_P1_F32 : VINTRP <
>0x,
>(outs VReg_32:$dst),
>(ins VReg_32:$i, i32imm:$attr_chan, i32imm:$attr, M0Reg:$m0),
> - "V_INTERP_P1_F32",
> + "V_INTERP_P1_F32 $dst, $i, $attr_chan, $attr, $m0",
I didn't put $m0 in the V_INTERP_MOV_F32 asm string because it's not an
explicit operand but used implicitly. I can see the value in printing it
anyway, but it should probably be distinguished from the explicit
operands somehow, e.g. "[$m0]" or something like that.
> let DisableEncoding = "$exec" in {
> def S_CBRANCH_EXECZ : SOPP <
>0x0008, (ins brtarget:$target, EXECReg:$exec),
> - "S_CBRANCH_EXECZ",
> + "S_CBRANCH_EXECZ $target",
>[]
> >;
> def S_CBRANCH_EXECNZ : SOPP <
>0x0009, (ins brtarget:$target, EXECReg:$exec),
> - "S_CBRANCH_EXECNZ",
> + "S_CBRANCH_EXECNZ $target",
>[]
> >;
> } // End DisableEncoding = "$exec"
> @@ -722,16 +722,19 @@ def S_WAITCNT : SOPP <0x000c, (ins i32imm:$simm16),
> "S_WAITCNT $simm16",
> //def S_TTRACEDATA : SOPP_ <0x0016, "S_TTRACEDATA", []>;
>
> def V_CNDMASK_B32_e32 : VOP2 <0x, (outs VReg_32:$dst),
> - (ins VSrc_32:$src0, VReg_32:$src1, VCCReg:$vcc), "V_CNDMASK_B32_e32",
> + (ins VSrc_32:$src0, VReg_32:$src1, VCCReg:$vcc),
> + "V_CNDMASK_B32_e32 $dst, $src0, $src1, $vcc",
>[]
> >{
>let DisableEncoding = "$vcc";
These asm strings should be made consistent with whichever way we decide
to handle implicit operands as well.
Other than these nits, the series looks good to me. Be sure to run make
check, in case the lit tests need to be updated for the asm string
changes.
--
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
Re: [Mesa-dev] [PATCH 11/14] R600/SI: add OMOD patterns
Am 21.02.2013 09:26, schrieb Michel Dänzer: On Mit, 2013-02-20 at 18:46 +0100, Christian König wrote: diff --git a/lib/Target/R600/SIInstructions.td b/lib/Target/R600/SIInstructions.td index 833e6cd..7c157e9 100644 --- a/lib/Target/R600/SIInstructions.td +++ b/lib/Target/R600/SIInstructions.td @@ -1232,6 +1232,24 @@ def : Pat < 0 /* ABS */, 0 /* CLAMP */, 0 /* OMOD */, 1 /* NEG */) >; +def : Pat < + (fmul VReg_32:$src, (f32 FP_0_5)), + (V_ADD_F32_e64 VReg_32:$src, (i32 0x80 /* SRC1 */), + 0 /* ABS */, 0 /* CLAMP */, 3 /* OMOD */, 0 /* NEG */) +>; + +def : Pat < + (fmul VReg_32:$src, (f32 FP_TWO)), + (V_ADD_F32_e64 VReg_32:$src, (i32 0x80 /* SRC1 */), + 0 /* ABS */, 0 /* CLAMP */, 1 /* OMOD */, 0 /* NEG */) +>; + +def : Pat < + (fmul VReg_32:$src, (f32 FP_FOUR)), + (V_ADD_F32_e64 VReg_32:$src, (i32 0x80 /* SRC1 */), + 0 /* ABS */, 0 /* CLAMP */, 2 /* OMOD */, 0 /* NEG */) +>; Is there any advantage to doing it like this as opposed to using V_MUL_F32_e32 with the corresponding inline constant source operands? I guess it could work for SGPRs as the source as well, if the patterns used VSrc instead of VReg, but otherwise MUL would result in more compact code. Good question, I don't see any advantage right now. I just wanted to make sure that it's working as expected by doing a full piglit test run. Going to change my folding to use V_MUL instead and dropping this patch from the patchset. Do I have your Rb for the rest? If yes I really want to commit this, cause patch 12 is fixing 40 piglit tests for me. Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/14] R600/SI: add OMOD patterns
On Don, 2013-02-21 at 09:44 +0100, Christian König wrote: > Am 21.02.2013 09:26, schrieb Michel Dänzer: > > On Mit, 2013-02-20 at 18:46 +0100, Christian König wrote: > >> > >> diff --git a/lib/Target/R600/SIInstructions.td > >> b/lib/Target/R600/SIInstructions.td > >> index 833e6cd..7c157e9 100644 > >> --- a/lib/Target/R600/SIInstructions.td > >> +++ b/lib/Target/R600/SIInstructions.td > >> @@ -1232,6 +1232,24 @@ def : Pat < > >> 0 /* ABS */, 0 /* CLAMP */, 0 /* OMOD */, 1 /* NEG */) > >> >; > >> > >> +def : Pat < > >> + (fmul VReg_32:$src, (f32 FP_0_5)), > >> + (V_ADD_F32_e64 VReg_32:$src, (i32 0x80 /* SRC1 */), > >> + 0 /* ABS */, 0 /* CLAMP */, 3 /* OMOD */, 0 /* NEG */) > >> +>; > >> + > >> +def : Pat < > >> + (fmul VReg_32:$src, (f32 FP_TWO)), > >> + (V_ADD_F32_e64 VReg_32:$src, (i32 0x80 /* SRC1 */), > >> + 0 /* ABS */, 0 /* CLAMP */, 1 /* OMOD */, 0 /* NEG */) > >> +>; > >> + > >> +def : Pat < > >> + (fmul VReg_32:$src, (f32 FP_FOUR)), > >> + (V_ADD_F32_e64 VReg_32:$src, (i32 0x80 /* SRC1 */), > >> + 0 /* ABS */, 0 /* CLAMP */, 2 /* OMOD */, 0 /* NEG */) > >> +>; > > Is there any advantage to doing it like this as opposed to using > > V_MUL_F32_e32 with the corresponding inline constant source operands? I > > guess it could work for SGPRs as the source as well, if the patterns > > used VSrc instead of VReg, but otherwise MUL would result in more > > compact code. > > Good question, I don't see any advantage right now. I just wanted to > make sure that it's working as expected by doing a full piglit test run. piglit quick-driver.tests only takes about 10 minutes. :) > Going to change my folding to use V_MUL instead and dropping this patch > from the patchset. > > Do I have your Rb for the rest? Apart from the question about dealing with implicit operands in the asm strings, yes. > If yes I really want to commit this, cause patch 12 is fixing 40 > piglit tests for me. That's great, but please don't rush it. Remember, we cannot commit changes without prior approval by Tom (or another LLVM developer). -- 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] [Bug 61200] insufficient linking of libxatracker.so
https://bugs.freedesktop.org/show_bug.cgi?id=61200 --- Comment #1 from Andreas Boll --- Created attachment 75240 --> https://bugs.freedesktop.org/attachment.cgi?id=75240&action=edit possible fix Does this patch help? -- 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: don't enable ReZ mode on evergreen
Reviewed-by: Marek Olšák
Marek
On Wed, Feb 20, 2013 at 10:20 PM, wrote:
> From: Alex Deucher
>
> Can cause lockups in certain cases when
> zfunc/zenable/zwrite change without a flush
> in between.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=60969
>
> This is a candidate for the 9.1 branch.
>
> Signed-off-by: Alex Deucher
> ---
> src/gallium/drivers/r600/evergreen_state.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_state.c
> b/src/gallium/drivers/r600/evergreen_state.c
> index fd73613..4a91942 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -3536,9 +3536,12 @@ void evergreen_update_db_shader_control(struct
> r600_context * rctx)
> * write to the zbuffer. Write to zbuffer is delayed after fragment
> shader
> * execution and thus after alpha test so if discarded by the alpha
> test
> * the z value is not written.
> +* If ReZ is enabled, and the zfunc/zenable/zwrite values change you
> can
> +* get a hang unless you flush the DB in between. For now just use
> +* LATE_Z.
> */
> if (rctx->alphatest_state.sx_alpha_test_control) {
> - db_shader_control |= S_02880C_Z_ORDER(V_02880C_RE_Z);
> + db_shader_control |= S_02880C_Z_ORDER(V_02880C_LATE_Z);
> } else {
> db_shader_control |=
> S_02880C_Z_ORDER(V_02880C_EARLY_Z_THEN_LATE_Z);
> }
> --
> 1.7.7.5
>
> ___
> 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: Fix memory leak in r600_shader_select.
Reviewed-by: Marek Olšák
Marek
On Thu, Feb 21, 2013 at 8:43 AM, Vinson Lee wrote:
> Signed-off-by: Vinson Lee
> Reported-by: Michel Dänzer
> ---
> src/gallium/drivers/r600/r600_state_common.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/r600/r600_state_common.c
> b/src/gallium/drivers/r600/r600_state_common.c
> index c03ce3d..c4bd758 100644
> --- a/src/gallium/drivers/r600/r600_state_common.c
> +++ b/src/gallium/drivers/r600/r600_state_common.c
> @@ -744,6 +744,7 @@ static int r600_shader_select(struct pipe_context *ctx,
> R600_ERR("Failed to build shader variant (type=%u)
> %d\n",
> sel->type, r);
> sel->current = NULL;
> + FREE(shader);
> return r;
> }
>
> --
> 1.8.1.2
>
> ___
> 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 01/12] R600/structurizer: add class to find the Nearest Common Dominator
On Mit, 2013-02-20 at 17:56 +0100, Michel Dänzer wrote: > On Don, 2013-02-14 at 11:32 +0100, Christian König wrote: > > Am 13.02.2013 18:22, schrieb Michel Dänzer: > > > On Mit, 2013-02-13 at 18:17 +0100, Christian König wrote: > > >> Am 13.02.2013 18:11, schrieb Michel Dänzer: > > >>> On Mit, 2013-02-13 at 11:34 -0500, Tom Stellard wrote: > > There's just the one cleanup on patch 10 that you mentioned, but > > otherwise the series looks good to me. Should we mark all these > > patches > > as candidates for the stable branch? > > >>> I think so, at least the parts which prevent things such as Vincent's > > >>> MAD changes or switching to the Source scheduler from breaking stuff. > > >> I still have no idea why the MAD change actually breaks anything. I'm > > >> working on OMOD/ABS/NEG folding in another branch and have Vincents MAD > > >> in there, but I haven't had time to fully figure out what's wrong there. > > >> And unfortunately I don't think I will have time in the near future. > > > Well, as I said, his MAD changes no longer break after this series. Does > > > anything speak against backporting the whole series to the stable tree? > > > > Oh, didn't know that I actually had fixed the bug that made MAD break, > > good to know. > > Actually, today I'm seeing the MAD changes breaking some piglit tests > again even with your changes. Never mind, your cndlt fix takes care of it. Let's hope for good this time. :) -- 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
Re: [Mesa-dev] [PATCH 09/14] R600/SI: add all the other missing asm operands
Am 21.02.2013 09:39, schrieb Michel Dänzer:
On Mit, 2013-02-20 at 18:46 +0100, Christian König wrote:
diff --git a/lib/Target/R600/SIInstructions.td
b/lib/Target/R600/SIInstructions.td
index 700b8f8..866c7cb 100644
--- a/lib/Target/R600/SIInstructions.td
+++ b/lib/Target/R600/SIInstructions.td
@@ -620,7 +620,7 @@ def V_INTERP_P1_F32 : VINTRP <
0x,
(outs VReg_32:$dst),
(ins VReg_32:$i, i32imm:$attr_chan, i32imm:$attr, M0Reg:$m0),
- "V_INTERP_P1_F32",
+ "V_INTERP_P1_F32 $dst, $i, $attr_chan, $attr, $m0",
I didn't put $m0 in the V_INTERP_MOV_F32 asm string because it's not an
explicit operand but used implicitly. I can see the value in printing it
anyway, but it should probably be distinguished from the explicit
operands somehow, e.g. "[$m0]" or something like that.
Any suggestion for the full asm string?
let DisableEncoding = "$exec" in {
def S_CBRANCH_EXECZ : SOPP <
0x0008, (ins brtarget:$target, EXECReg:$exec),
- "S_CBRANCH_EXECZ",
+ "S_CBRANCH_EXECZ $target",
[]
>;
def S_CBRANCH_EXECNZ : SOPP <
0x0009, (ins brtarget:$target, EXECReg:$exec),
- "S_CBRANCH_EXECNZ",
+ "S_CBRANCH_EXECNZ $target",
[]
>;
} // End DisableEncoding = "$exec"
@@ -722,16 +722,19 @@ def S_WAITCNT : SOPP <0x000c, (ins i32imm:$simm16),
"S_WAITCNT $simm16",
//def S_TTRACEDATA : SOPP_ <0x0016, "S_TTRACEDATA", []>;
def V_CNDMASK_B32_e32 : VOP2 <0x, (outs VReg_32:$dst),
- (ins VSrc_32:$src0, VReg_32:$src1, VCCReg:$vcc), "V_CNDMASK_B32_e32",
+ (ins VSrc_32:$src0, VReg_32:$src1, VCCReg:$vcc),
+ "V_CNDMASK_B32_e32 $dst, $src0, $src1, $vcc",
[]
>{
let DisableEncoding = "$vcc";
These asm strings should be made consistent with whichever way we decide
to handle implicit operands as well.
I left out the implicit regs for the S_CBRANCH_* instruction because
they are part of the instruction name anyway, but for everything else I
don't see any reason why we shouldn't print them.
For the example of V_CNDMASK_B32_e32 I would say that we should
definitely print it, cause that bring us in line with the _e64 encoding
which can have the condition in any SReg_64.
Other than these nits, the series looks good to me. Be sure to run make
check, in case the lit tests need to be updated for the asm string
changes.
I'm usually only running "llvm-lit test/CodeGen/R600/", cause I don't
build anything else than the R600 target and so running all the other
tests shouldn't make much sense.
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/14] R600/SI: add all the other missing asm operands
On Don, 2013-02-21 at 10:38 +0100, Christian König wrote:
> Am 21.02.2013 09:39, schrieb Michel Dänzer:
> > On Mit, 2013-02-20 at 18:46 +0100, Christian König wrote:
> >> diff --git a/lib/Target/R600/SIInstructions.td
> >> b/lib/Target/R600/SIInstructions.td
> >> index 700b8f8..866c7cb 100644
> >> --- a/lib/Target/R600/SIInstructions.td
> >> +++ b/lib/Target/R600/SIInstructions.td
> >> @@ -620,7 +620,7 @@ def V_INTERP_P1_F32 : VINTRP <
> >> 0x,
> >> (outs VReg_32:$dst),
> >> (ins VReg_32:$i, i32imm:$attr_chan, i32imm:$attr, M0Reg:$m0),
> >> - "V_INTERP_P1_F32",
> >> + "V_INTERP_P1_F32 $dst, $i, $attr_chan, $attr, $m0",
> > I didn't put $m0 in the V_INTERP_MOV_F32 asm string because it's not an
> > explicit operand but used implicitly. I can see the value in printing it
> > anyway, but it should probably be distinguished from the explicit
> > operands somehow, e.g. "[$m0]" or something like that.
>
> Any suggestion for the full asm string?
E.g.
"V_INTERP_P1_F32 $dst, $i, $attr_chan, $attr, [$m0]"
> >> @@ -722,16 +722,19 @@ def S_WAITCNT : SOPP <0x000c, (ins
> >> i32imm:$simm16), "S_WAITCNT $simm16",
> >> //def S_TTRACEDATA : SOPP_ <0x0016, "S_TTRACEDATA", []>;
> >>
> >> def V_CNDMASK_B32_e32 : VOP2 <0x, (outs VReg_32:$dst),
> >> - (ins VSrc_32:$src0, VReg_32:$src1, VCCReg:$vcc), "V_CNDMASK_B32_e32",
> >> + (ins VSrc_32:$src0, VReg_32:$src1, VCCReg:$vcc),
> >> + "V_CNDMASK_B32_e32 $dst, $src0, $src1, $vcc",
> >> []
> >> >{
> >> let DisableEncoding = "$vcc";
> > These asm strings should be made consistent with whichever way we decide
> > to handle implicit operands as well.
>
> I left out the implicit regs for the S_CBRANCH_* instruction because
> they are part of the instruction name anyway, but for everything else I
> don't see any reason why we shouldn't print them.
>
> For the example of V_CNDMASK_B32_e32 I would say that we should
> definitely print it, cause that bring us in line with the _e64 encoding
> which can have the condition in any SReg_64.
Right. Along similar lines, printing them for S_CBRANCH_* might help
catch bugs which somehow cause the register allocator to try and use a
different register.
> > Other than these nits, the series looks good to me. Be sure to run make
> > check, in case the lit tests need to be updated for the asm string
> > changes.
>
> I'm usually only running "llvm-lit test/CodeGen/R600/", cause I don't
> build anything else than the R600 target and so running all the other
> tests shouldn't make much sense.
That's probably fine, though make check takes less than a minute on my
quad core Llano.
--
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
Re: [Mesa-dev] [PATCH] draw: make sure key size is calculated consistently.
Looks perfect. Thanks Roland.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Some parts calculated key size by using shader information, others by using
> the pipe_vertex_element information. Since it is perfectly valid to have more
> vertex_elements set than the vertex shader is using those may not be the
> same,
> so we weren't copying over all vertex_element state - this caused the tgsi
> dump
> to assert (iterates over all vertex elements). More importantly in this
> situation it would also break vertex texturing completely (since the sampler
> state derived from the key is at a different position than expected).
> Fix thix by deriving key->nr_vertex_elements from the shader information
> instead of the pipe_vertex_element state (unlike dx10, we can't have "holes"
> in pipe_vertex_element state, so this should be safe).
> (Note that actual llvm shader generation does not use the pipe_vertex_element
> state from the key itself in any case (althogh I guess it could) but uses
> the one from draw.pt (which should be the same though contains all elements)
> instead.)
> ---
> src/gallium/auxiliary/draw/draw_llvm.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
> b/src/gallium/auxiliary/draw/draw_llvm.c
> index f3b..2467e5a 100644
> --- a/src/gallium/auxiliary/draw/draw_llvm.c
> +++ b/src/gallium/auxiliary/draw/draw_llvm.c
> @@ -420,8 +420,8 @@ draw_llvm_destroy(struct draw_llvm *llvm)
> */
> struct draw_llvm_variant *
> draw_llvm_create_variant(struct draw_llvm *llvm,
> - unsigned num_inputs,
> - const struct draw_llvm_variant_key *key)
> + unsigned num_inputs,
> + const struct draw_llvm_variant_key *key)
> {
> struct draw_llvm_variant *variant;
> struct llvm_vertex_shader *shader =
> @@ -429,8 +429,8 @@ draw_llvm_create_variant(struct draw_llvm *llvm,
> LLVMTypeRef vertex_header;
>
> variant = MALLOC(sizeof *variant +
> - shader->variant_key_size -
> - sizeof variant->key);
> +shader->variant_key_size -
> +sizeof variant->key);
> if (variant == NULL)
>return NULL;
>
> @@ -1415,8 +1415,12 @@ draw_llvm_make_variant_key(struct draw_llvm *llvm,
> char *store)
>
> /* Presumably all variants of the shader should have the same
> * number of vertex elements - ie the number of shader inputs.
> +* NOTE: we NEED to store the needed number of needed inputs
> +* here, not the number of provided elements to match keysize
> +* (and the offset of sampler state in the key).
> */
> - key->nr_vertex_elements = llvm->draw->pt.nr_vertex_elements;
> + key->nr_vertex_elements =
> llvm->draw->vs.vertex_shader->info.file_max[TGSI_FILE_INPUT] + 1;
> + assert(key->nr_vertex_elements <= llvm->draw->pt.nr_vertex_elements);
>
> /* will have to rig this up properly later */
> key->clip_xy = llvm->draw->clip_xy;
> --
> 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] clover: Fix build with LLVM 3.3
Tom Stellard writes:
> From: Tom Stellard
>
Acked-by: Francisco Jerez
> ---
> .../state_trackers/clover/llvm/invocation.cpp | 47 ---
> 1 files changed, 39 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 0bd8e22..2785d10 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -28,10 +28,17 @@
> #include
> #include
> #include
> -#include
> #include
> +#if HAVE_LLVM < 0x0303
> +#include
> #include
> #include
> +#else
> +#include
> +#include
> +#include
> +#include
> +#endif
> #include
> #include
> #include
> @@ -41,8 +48,10 @@
>
> #if HAVE_LLVM < 0x0302
> #include
> -#else
> +#elif HAVE_LLVM < 0x0303
> #include
> +#else
> +#include
> #endif
>
> #include "pipe/p_state.h"
> @@ -151,7 +160,11 @@ namespace {
>// Add libclc generic search path
>c.getHeaderSearchOpts().AddPath(LIBCLC_INCLUDEDIR,
>clang::frontend::Angled,
> - false, false, false);
> + false, false
> +#if HAVE_LLVM < 0x0303
> + , false
> +#endif
> + );
>
>// Add libclc include
>c.getPreprocessorOpts().Includes.push_back("clc/clc.h");
> @@ -167,8 +180,12 @@ namespace {
>c.getInvocation().setLangDefaults(c.getLangOpts(), clang::IK_OpenCL,
> clang::LangStandard::lang_opencl11);
> #endif
> - c.createDiagnostics(0, NULL, new clang::TextDiagnosticPrinter(
> - s_log,
> + c.createDiagnostics(
> +#if HAVE_LLVM < 0x0303
> + 0, NULL,
> +#endif
> + new clang::TextDiagnosticPrinter(
> + s_log,
> #if HAVE_LLVM <= 0x0301
> c.getDiagnosticOpts()));
> #else
> @@ -201,12 +218,26 @@ namespace {
>
>llvm::PassManager PM;
>llvm::PassManagerBuilder Builder;
> - bool isNative;
> - llvm::Linker linker("clover", mod);
> + llvm::sys::Path libclc_path =
> +llvm::sys::Path(LIBCLC_LIBEXECDIR + triple +
> ".bc");
>
>// Link the kernel with libclc
> - linker.LinkInFile(llvm::sys::Path(LIBCLC_LIBEXECDIR + triple + ".bc"),
> isNative);
> +#if HAVE_LLVM < 0x0303
> + bool isNative;
> + llvm::Linker linker("clover", mod);
> + linker.LinkInFile(libclc_path, isNative);
>mod = linker.releaseModule();
> +#else
> + std::string err_str;
> + llvm::SMDiagnostic err;
> + llvm::Module *libclc_mod = llvm::ParseIRFile(libclc_path.str(), err,
> + mod->getContext());
> + if (llvm::Linker::LinkModules(mod, libclc_mod,
> +llvm::Linker::DestroySource,
> +&err_str)) {
> + throw build_error(err_str);
> + }
> +#endif
>
>// Add a function internalizer pass.
>//
pgpVVk4rFkOM3.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61200] insufficient linking of libxatracker.so
https://bugs.freedesktop.org/show_bug.cgi?id=61200 --- Comment #2 from Rafał Mużyło --- (In reply to comment #1) > Created attachment 75240 [details] [review] > possible fix > > Does this patch help? Well, it should help - that's exactly the solution I've proposed. On the other hand, I'm not the original reporter - I've only moved it here, so that 9.1 gets the fix before its release. The downstream bug has been just been updated - will get back to you. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/8] R600/SI: cleanup SIInstrInfo.td and SIInstrFormat.td
With the changes Michel suggested, this series is:
Reviewed-by: Tom Stellard
Are any of these candidates for the stable branch?
-Tom
On Tue, Feb 19, 2013 at 02:54:23PM +0100, Christian König wrote:
> From: Christian König
>
> Those two files got mixed up.
>
> Signed-off-by: Christian König
> ---
> lib/Target/R600/SIInstrFormats.td | 500
> +++--
> lib/Target/R600/SIInstrInfo.td| 495 +++-
> 2 files changed, 509 insertions(+), 486 deletions(-)
>
> diff --git a/lib/Target/R600/SIInstrFormats.td
> b/lib/Target/R600/SIInstrFormats.td
> index 40e37aa..fe417d6 100644
> --- a/lib/Target/R600/SIInstrFormats.td
> +++ b/lib/Target/R600/SIInstrFormats.td
> @@ -1,4 +1,4 @@
> -//===-- SIInstrFormats.td - SI Instruction Formats
> ===//
> +//===-- SIInstrFormats.td - SI Instruction Encodings
> --===//
> //
> // The LLVM Compiler Infrastructure
> //
> @@ -9,180 +9,418 @@
> //
> // SI Instruction format definitions.
> //
> -// Instructions with _32 take 32-bit operands.
> -// Instructions with _64 take 64-bit operands.
> -//
> -// VOP_* instructions can use either a 32-bit or 64-bit encoding. The 32-bit
> -// encoding is the standard encoding, but instruction that make use of
> -// any of the instruction modifiers must use the 64-bit encoding.
> -//
> -// Instructions with _e32 use the 32-bit encoding.
> -// Instructions with _e64 use the 64-bit encoding.
> -//
>
> //===--===//
>
> -class VOP3_32 op, string opName, list pattern>
> - : VOP3 VReg_32:$src2, i32imm:$src3, i32imm:$src4, i32imm:$src5, i32imm:$src6),
> opName, pattern>;
> +class InstSI pattern> :
> +AMDGPUInst {
> +
> + field bits<1> VM_CNT = 0;
> + field bits<1> EXP_CNT = 0;
> + field bits<1> LGKM_CNT = 0;
> +
> + let TSFlags{0} = VM_CNT;
> + let TSFlags{1} = EXP_CNT;
> + let TSFlags{2} = LGKM_CNT;
> +}
> +
> +class Enc32 pattern> :
> +InstSI {
> +
> + field bits<32> Inst;
> + let Size = 4;
> +}
>
> -class VOP3_64 op, string opName, list pattern>
> - : VOP3 VReg_64:$src2, i32imm:$src3, i32imm:$src4, i32imm:$src5, i32imm:$src6),
> opName, pattern>;
> +class Enc64 pattern> :
> +InstSI {
>
> -class SOP1_32 op, string opName, list pattern>
> - : SOP1 ;
> + field bits<64> Inst;
> + let Size = 8;
> +}
>
> -class SOP1_64 op, string opName, list pattern>
> - : SOP1 ;
> +//===--===//
> +// Scalar operations
> +//===--===//
>
> -class SOP2_32 op, string opName, list pattern>
> - : SOP2 opName, pattern>;
> +class SOP1 op, dag outs, dag ins, string asm, list pattern> :
> +Enc32 {
>
> -class SOP2_64 op, string opName, list pattern>
> - : SOP2 opName, pattern>;
> + bits<7> SDST;
> + bits<8> SSRC0;
>
> -class VOP1_Helper op, RegisterClass vrc, RegisterClass arc,
> - string opName, list pattern> :
> - VOP1 <
> -op, (outs vrc:$dst), (ins arc:$src0), opName, pattern
> - >;
> + let Inst{7-0} = SSRC0;
> + let Inst{15-8} = op;
> + let Inst{22-16} = SDST;
> + let Inst{31-23} = 0x17d; //encoding;
>
> -multiclass VOP1_32 op, string opName, list pattern> {
> - def _e32: VOP1_Helper ;
> - def _e64 : VOP3_32 <{1, 1, op{6}, op{5}, op{4}, op{3}, op{2}, op{1},
> op{0}},
> - opName, []
> - >;
> + let mayLoad = 0;
> + let mayStore = 0;
> + let hasSideEffects = 0;
> }
>
> -multiclass VOP1_64 op, string opName, list pattern> {
> +class SOP2 op, dag outs, dag ins, string asm, list pattern> :
> +Enc32 {
> +
> + bits<7> SDST;
> + bits<8> SSRC0;
> + bits<8> SSRC1;
>
> - def _e32 : VOP1_Helper ;
> + let Inst{7-0} = SSRC0;
> + let Inst{15-8} = SSRC1;
> + let Inst{22-16} = SDST;
> + let Inst{29-23} = op;
> + let Inst{31-30} = 0x2; // encoding
>
> - def _e64 : VOP3_64 <
> -{1, 1, op{6}, op{5}, op{4}, op{3}, op{2}, op{1}, op{0}},
> -opName, []
> - >;
> + let mayLoad = 0;
> + let mayStore = 0;
> + let hasSideEffects = 0;
> }
>
> -class VOP2_Helper op, RegisterClass vrc, RegisterClass arc,
> - string opName, list pattern> :
> - VOP2 <
> -op, (outs vrc:$dst), (ins arc:$src0, vrc:$src1), opName, pattern
> - >;
> +class SOPC op, dag outs, dag ins, string asm, list pattern> :
> + Enc32 {
>
> -multiclass VOP2_32 op, string opName, list pattern> {
> + bits<8> SSRC0;
> + bits<8> SSRC1;
>
> - def _e32 : VOP2_Helper ;
> + let Inst{7-0} = SSRC0;
> + let Inst{15-8} = SSRC1;
> + let Inst{22-16} = op;
> + let Inst{31-23} = 0x17e;
>
> - def _e64 : VOP3_32 <{1, 0, 0, op{5}, op{4}, op{3}, op{2}, op{1}, op{0}},
> - opName, []
> - >;
> + let DisableEncoding = "$dst";
> + let mayLoad = 0;
> + let mayStore = 0;
> + let hasSideEffects = 0;
Re: [Mesa-dev] [PATCH 1/8] R600/SI: cleanup SIInstrInfo.td and SIInstrFormat.td
On Thu, Feb 21, 2013 at 09:06:36AM -0500, Tom Stellard wrote:
> With the changes Michel suggested, this series is:
>
> Reviewed-by: Tom Stellard
>
> Are any of these candidates for the stable branch?
>
Please ignore this, I overlooked v2 of this series. I will review the
new version now.
> -Tom
>
>
> On Tue, Feb 19, 2013 at 02:54:23PM +0100, Christian König wrote:
> > From: Christian König
> >
> > Those two files got mixed up.
> >
> > Signed-off-by: Christian König
> > ---
> > lib/Target/R600/SIInstrFormats.td | 500
> > +++--
> > lib/Target/R600/SIInstrInfo.td| 495
> > +++-
> > 2 files changed, 509 insertions(+), 486 deletions(-)
> >
> > diff --git a/lib/Target/R600/SIInstrFormats.td
> > b/lib/Target/R600/SIInstrFormats.td
> > index 40e37aa..fe417d6 100644
> > --- a/lib/Target/R600/SIInstrFormats.td
> > +++ b/lib/Target/R600/SIInstrFormats.td
> > @@ -1,4 +1,4 @@
> > -//===-- SIInstrFormats.td - SI Instruction Formats
> > ===//
> > +//===-- SIInstrFormats.td - SI Instruction Encodings
> > --===//
> > //
> > // The LLVM Compiler Infrastructure
> > //
> > @@ -9,180 +9,418 @@
> > //
> > // SI Instruction format definitions.
> > //
> > -// Instructions with _32 take 32-bit operands.
> > -// Instructions with _64 take 64-bit operands.
> > -//
> > -// VOP_* instructions can use either a 32-bit or 64-bit encoding. The
> > 32-bit
> > -// encoding is the standard encoding, but instruction that make use of
> > -// any of the instruction modifiers must use the 64-bit encoding.
> > -//
> > -// Instructions with _e32 use the 32-bit encoding.
> > -// Instructions with _e64 use the 64-bit encoding.
> > -//
> >
> > //===--===//
> >
> > -class VOP3_32 op, string opName, list pattern>
> > - : VOP3 > VReg_32:$src2, i32imm:$src3, i32imm:$src4, i32imm:$src5, i32imm:$src6),
> > opName, pattern>;
> > +class InstSI pattern> :
> > +AMDGPUInst {
> > +
> > + field bits<1> VM_CNT = 0;
> > + field bits<1> EXP_CNT = 0;
> > + field bits<1> LGKM_CNT = 0;
> > +
> > + let TSFlags{0} = VM_CNT;
> > + let TSFlags{1} = EXP_CNT;
> > + let TSFlags{2} = LGKM_CNT;
> > +}
> > +
> > +class Enc32 pattern> :
> > +InstSI {
> > +
> > + field bits<32> Inst;
> > + let Size = 4;
> > +}
> >
> > -class VOP3_64 op, string opName, list pattern>
> > - : VOP3 > VReg_64:$src2, i32imm:$src3, i32imm:$src4, i32imm:$src5, i32imm:$src6),
> > opName, pattern>;
> > +class Enc64 pattern> :
> > +InstSI {
> >
> > -class SOP1_32 op, string opName, list pattern>
> > - : SOP1 ;
> > + field bits<64> Inst;
> > + let Size = 8;
> > +}
> >
> > -class SOP1_64 op, string opName, list pattern>
> > - : SOP1 ;
> > +//===--===//
> > +// Scalar operations
> > +//===--===//
> >
> > -class SOP2_32 op, string opName, list pattern>
> > - : SOP2 > opName, pattern>;
> > +class SOP1 op, dag outs, dag ins, string asm, list pattern> :
> > +Enc32 {
> >
> > -class SOP2_64 op, string opName, list pattern>
> > - : SOP2 > opName, pattern>;
> > + bits<7> SDST;
> > + bits<8> SSRC0;
> >
> > -class VOP1_Helper op, RegisterClass vrc, RegisterClass arc,
> > - string opName, list pattern> :
> > - VOP1 <
> > -op, (outs vrc:$dst), (ins arc:$src0), opName, pattern
> > - >;
> > + let Inst{7-0} = SSRC0;
> > + let Inst{15-8} = op;
> > + let Inst{22-16} = SDST;
> > + let Inst{31-23} = 0x17d; //encoding;
> >
> > -multiclass VOP1_32 op, string opName, list pattern> {
> > - def _e32: VOP1_Helper ;
> > - def _e64 : VOP3_32 <{1, 1, op{6}, op{5}, op{4}, op{3}, op{2}, op{1},
> > op{0}},
> > - opName, []
> > - >;
> > + let mayLoad = 0;
> > + let mayStore = 0;
> > + let hasSideEffects = 0;
> > }
> >
> > -multiclass VOP1_64 op, string opName, list pattern> {
> > +class SOP2 op, dag outs, dag ins, string asm, list pattern> :
> > +Enc32 {
> > +
> > + bits<7> SDST;
> > + bits<8> SSRC0;
> > + bits<8> SSRC1;
> >
> > - def _e32 : VOP1_Helper ;
> > + let Inst{7-0} = SSRC0;
> > + let Inst{15-8} = SSRC1;
> > + let Inst{22-16} = SDST;
> > + let Inst{29-23} = op;
> > + let Inst{31-30} = 0x2; // encoding
> >
> > - def _e64 : VOP3_64 <
> > -{1, 1, op{6}, op{5}, op{4}, op{3}, op{2}, op{1}, op{0}},
> > -opName, []
> > - >;
> > + let mayLoad = 0;
> > + let mayStore = 0;
> > + let hasSideEffects = 0;
> > }
> >
> > -class VOP2_Helper op, RegisterClass vrc, RegisterClass arc,
> > - string opName, list pattern> :
> > - VOP2 <
> > -op, (outs vrc:$dst), (ins arc:$src0, vrc:$src1), opName, pattern
> > - >;
> > +class SOPC op, dag outs, dag ins, string asm, list pattern> :
> > + Enc32 {
> >
>
Re: [Mesa-dev] [PATCH 14/14] R600/SI: inline V_ADD|SUB_F32 patterns
On Wed, Feb 20, 2013 at 06:47:00PM +0100, Christian König wrote: > From: Christian König > > Signed-off-by: Christian König > --- > lib/Target/R600/SIInstructions.td | 14 +- > 1 file changed, 5 insertions(+), 9 deletions(-) > > diff --git a/lib/Target/R600/SIInstructions.td > b/lib/Target/R600/SIInstructions.td > index 71ae33b..9ea26d2 100644 > --- a/lib/Target/R600/SIInstructions.td > +++ b/lib/Target/R600/SIInstructions.td > @@ -746,17 +746,13 @@ def : Pat < > defm V_READLANE_B32 : VOP2_32 <0x0001, "V_READLANE_B32", []>; > defm V_WRITELANE_B32 : VOP2_32 <0x0002, "V_WRITELANE_B32", []>; > > -defm V_ADD_F32 : VOP2_32 <0x0003, "V_ADD_F32", []>; > -def : Pat < > - (f32 (fadd VSrc_32:$src0, VReg_32:$src1)), > - (V_ADD_F32_e32 VSrc_32:$src0, VReg_32:$src1) > +defm V_ADD_F32 : VOP2_32 <0x0003, "V_ADD_F32", > + [(set VReg_32:$dst, (fadd VSrc_32:$src0, VReg_32:$src1))] > >; > - > -defm V_SUB_F32 : VOP2_32 <0x0004, "V_SUB_F32", []>; > -def : Pat < > - (f32 (fsub VSrc_32:$src0, VReg_32:$src1)), > - (V_SUB_F32_e32 VSrc_32:$src0, VReg_32:$src1) > +defm V_SUB_F32 : VOP2_32 <0x0004, "V_SUB_F32", > + [(set VReg_32:$dst, (fsub VSrc_32:$src0, VReg_32:$src1))] > >; > + This looks good for now, but in the future it may be useful to simplify all the VOP* and SOP* patterns by adding a helper that takes only an SDPatternOperator as an argument and use that to build the pattern. As an example, take a look at the R600_[123]OP_Helper classes in R600Instructions.td > defm V_SUBREV_F32 : VOP2_32 <0x0005, "V_SUBREV_F32", []>; > defm V_MAC_LEGACY_F32 : VOP2_32 <0x0006, "V_MAC_LEGACY_F32", []>; > defm V_MUL_LEGACY_F32 : VOP2_32 < > -- > 1.7.10.4 > > ___ > llvm-commits mailing list > llvm-comm...@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/14] R600/SI: cleanup SIInstrInfo.td and SIInstrFormat.td
For the series:
Reviewed-by: Tom Stellard
On Wed, Feb 20, 2013 at 06:46:47PM +0100, Christian König wrote:
> From: Christian König
>
> Those two files got mixed up.
>
> Signed-off-by: Christian König
> ---
> lib/Target/R600/SIInstrFormats.td | 500 +--
> lib/Target/R600/SIInstrInfo.td| 515
> -
> 2 files changed, 527 insertions(+), 488 deletions(-)
>
> diff --git a/lib/Target/R600/SIInstrFormats.td
> b/lib/Target/R600/SIInstrFormats.td
> index 40e37aa..fe417d6 100644
> --- a/lib/Target/R600/SIInstrFormats.td
> +++ b/lib/Target/R600/SIInstrFormats.td
> @@ -1,4 +1,4 @@
> -//===-- SIInstrFormats.td - SI Instruction Formats
> ===//
> +//===-- SIInstrFormats.td - SI Instruction Encodings
> --===//
> //
> // The LLVM Compiler Infrastructure
> //
> @@ -9,180 +9,418 @@
> //
> // SI Instruction format definitions.
> //
> -// Instructions with _32 take 32-bit operands.
> -// Instructions with _64 take 64-bit operands.
> -//
> -// VOP_* instructions can use either a 32-bit or 64-bit encoding. The 32-bit
> -// encoding is the standard encoding, but instruction that make use of
> -// any of the instruction modifiers must use the 64-bit encoding.
> -//
> -// Instructions with _e32 use the 32-bit encoding.
> -// Instructions with _e64 use the 64-bit encoding.
> -//
>
> //===--===//
>
> -class VOP3_32 op, string opName, list pattern>
> - : VOP3 VReg_32:$src2, i32imm:$src3, i32imm:$src4, i32imm:$src5, i32imm:$src6),
> opName, pattern>;
> +class InstSI pattern> :
> +AMDGPUInst {
> +
> + field bits<1> VM_CNT = 0;
> + field bits<1> EXP_CNT = 0;
> + field bits<1> LGKM_CNT = 0;
> +
> + let TSFlags{0} = VM_CNT;
> + let TSFlags{1} = EXP_CNT;
> + let TSFlags{2} = LGKM_CNT;
> +}
> +
> +class Enc32 pattern> :
> +InstSI {
> +
> + field bits<32> Inst;
> + let Size = 4;
> +}
>
> -class VOP3_64 op, string opName, list pattern>
> - : VOP3 VReg_64:$src2, i32imm:$src3, i32imm:$src4, i32imm:$src5, i32imm:$src6),
> opName, pattern>;
> +class Enc64 pattern> :
> +InstSI {
>
> -class SOP1_32 op, string opName, list pattern>
> - : SOP1 ;
> + field bits<64> Inst;
> + let Size = 8;
> +}
>
> -class SOP1_64 op, string opName, list pattern>
> - : SOP1 ;
> +//===--===//
> +// Scalar operations
> +//===--===//
>
> -class SOP2_32 op, string opName, list pattern>
> - : SOP2 opName, pattern>;
> +class SOP1 op, dag outs, dag ins, string asm, list pattern> :
> +Enc32 {
>
> -class SOP2_64 op, string opName, list pattern>
> - : SOP2 opName, pattern>;
> + bits<7> SDST;
> + bits<8> SSRC0;
>
> -class VOP1_Helper op, RegisterClass vrc, RegisterClass arc,
> - string opName, list pattern> :
> - VOP1 <
> -op, (outs vrc:$dst), (ins arc:$src0), opName, pattern
> - >;
> + let Inst{7-0} = SSRC0;
> + let Inst{15-8} = op;
> + let Inst{22-16} = SDST;
> + let Inst{31-23} = 0x17d; //encoding;
>
> -multiclass VOP1_32 op, string opName, list pattern> {
> - def _e32: VOP1_Helper ;
> - def _e64 : VOP3_32 <{1, 1, op{6}, op{5}, op{4}, op{3}, op{2}, op{1},
> op{0}},
> - opName, []
> - >;
> + let mayLoad = 0;
> + let mayStore = 0;
> + let hasSideEffects = 0;
> }
>
> -multiclass VOP1_64 op, string opName, list pattern> {
> +class SOP2 op, dag outs, dag ins, string asm, list pattern> :
> +Enc32 {
> +
> + bits<7> SDST;
> + bits<8> SSRC0;
> + bits<8> SSRC1;
>
> - def _e32 : VOP1_Helper ;
> + let Inst{7-0} = SSRC0;
> + let Inst{15-8} = SSRC1;
> + let Inst{22-16} = SDST;
> + let Inst{29-23} = op;
> + let Inst{31-30} = 0x2; // encoding
>
> - def _e64 : VOP3_64 <
> -{1, 1, op{6}, op{5}, op{4}, op{3}, op{2}, op{1}, op{0}},
> -opName, []
> - >;
> + let mayLoad = 0;
> + let mayStore = 0;
> + let hasSideEffects = 0;
> }
>
> -class VOP2_Helper op, RegisterClass vrc, RegisterClass arc,
> - string opName, list pattern> :
> - VOP2 <
> -op, (outs vrc:$dst), (ins arc:$src0, vrc:$src1), opName, pattern
> - >;
> +class SOPC op, dag outs, dag ins, string asm, list pattern> :
> + Enc32 {
>
> -multiclass VOP2_32 op, string opName, list pattern> {
> + bits<8> SSRC0;
> + bits<8> SSRC1;
>
> - def _e32 : VOP2_Helper ;
> + let Inst{7-0} = SSRC0;
> + let Inst{15-8} = SSRC1;
> + let Inst{22-16} = op;
> + let Inst{31-23} = 0x17e;
>
> - def _e64 : VOP3_32 <{1, 0, 0, op{5}, op{4}, op{3}, op{2}, op{1}, op{0}},
> - opName, []
> - >;
> + let DisableEncoding = "$dst";
> + let mayLoad = 0;
> + let mayStore = 0;
> + let hasSideEffects = 0;
> }
>
> -multiclass VOP2_64 op, string opName, list pattern> {
> - def _e32: VOP2_Helper
Re: [Mesa-dev] [PATCH] clover: Fix build with LLVM 3.3
Hi Tom,
Mesa+Clover does indeed build against master llvm/clang, but I'm having
trouble building against it when I try to do a clean build of Piglit.
Error received:
[ 18%] Built target piglitutil_cl
Linking C executable ../../../../../bin/cl-custom-run-simple-kernel
/usr/local/lib/libOpenCL.so: undefined reference to
`clang::PPConditionalDirectiveRecord::rangeIntersectsConditionalDirective(clang::SourceRange)
const'
/usr/local/lib/libOpenCL.so: undefined reference to
`clang::PPConditionalDirectiveRecord::findConditionalDirectiveRegionLoc(clang::SourceLocation)
const'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/cl-custom-run-simple-kernel] Error 1
make[1]: ***
[target_api/cl/tests/cl/custom/CMakeFiles/cl-custom-run-simple-kernel.dir/all]
Error 2
make: *** [all] Error 2
Maybe I've done something wrong, but I've tested this on two machines now
and both times I've wiped my llvm/clang/mesa/clover installs in /usr/local
and rebuilt from scratch.
--Aaron
On Wed, Feb 20, 2013 at 4:27 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> ---
> .../state_trackers/clover/llvm/invocation.cpp | 47
> ---
> 1 files changed, 39 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 0bd8e22..2785d10 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -28,10 +28,17 @@
> #include
> #include
> #include
> -#include
> #include
> +#if HAVE_LLVM < 0x0303
> +#include
> #include
> #include
> +#else
> +#include
> +#include
> +#include
> +#include
> +#endif
> #include
> #include
> #include
> @@ -41,8 +48,10 @@
>
> #if HAVE_LLVM < 0x0302
> #include
> -#else
> +#elif HAVE_LLVM < 0x0303
> #include
> +#else
> +#include
> #endif
>
> #include "pipe/p_state.h"
> @@ -151,7 +160,11 @@ namespace {
>// Add libclc generic search path
>c.getHeaderSearchOpts().AddPath(LIBCLC_INCLUDEDIR,
>clang::frontend::Angled,
> - false, false, false);
> + false, false
> +#if HAVE_LLVM < 0x0303
> + , false
> +#endif
> + );
>
>// Add libclc include
>c.getPreprocessorOpts().Includes.push_back("clc/clc.h");
> @@ -167,8 +180,12 @@ namespace {
>c.getInvocation().setLangDefaults(c.getLangOpts(), clang::IK_OpenCL,
>
> clang::LangStandard::lang_opencl11);
> #endif
> - c.createDiagnostics(0, NULL, new clang::TextDiagnosticPrinter(
> - s_log,
> + c.createDiagnostics(
> +#if HAVE_LLVM < 0x0303
> + 0, NULL,
> +#endif
> + new clang::TextDiagnosticPrinter(
> + s_log,
> #if HAVE_LLVM <= 0x0301
> c.getDiagnosticOpts()));
> #else
> @@ -201,12 +218,26 @@ namespace {
>
>llvm::PassManager PM;
>llvm::PassManagerBuilder Builder;
> - bool isNative;
> - llvm::Linker linker("clover", mod);
> + llvm::sys::Path libclc_path =
> +llvm::sys::Path(LIBCLC_LIBEXECDIR + triple +
> ".bc");
>
>// Link the kernel with libclc
> - linker.LinkInFile(llvm::sys::Path(LIBCLC_LIBEXECDIR + triple +
> ".bc"), isNative);
> +#if HAVE_LLVM < 0x0303
> + bool isNative;
> + llvm::Linker linker("clover", mod);
> + linker.LinkInFile(libclc_path, isNative);
>mod = linker.releaseModule();
> +#else
> + std::string err_str;
> + llvm::SMDiagnostic err;
> + llvm::Module *libclc_mod = llvm::ParseIRFile(libclc_path.str(), err,
> + mod->getContext());
> + if (llvm::Linker::LinkModules(mod, libclc_mod,
> +llvm::Linker::DestroySource,
> +&err_str)) {
> + throw build_error(err_str);
> + }
> +#endif
>
>// Add a function internalizer pass.
>//
> --
> 1.7.8.6
>
> ___
> 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] clover: Fix build with LLVM 3.3
On Thu, Feb 21, 2013 at 08:25:20AM -0600, Aaron Watry wrote:
> Hi Tom,
>
> Mesa+Clover does indeed build against master llvm/clang, but I'm having
> trouble building against it when I try to do a clean build of Piglit.
>
> Error received:
>
> [ 18%] Built target piglitutil_cl
> Linking C executable ../../../../../bin/cl-custom-run-simple-kernel
> /usr/local/lib/libOpenCL.so: undefined reference to
> `clang::PPConditionalDirectiveRecord::rangeIntersectsConditionalDirective(clang::SourceRange)
> const'
> /usr/local/lib/libOpenCL.so: undefined reference to
> `clang::PPConditionalDirectiveRecord::findConditionalDirectiveRegionLoc(clang::SourceLocation)
> const'
> collect2: error: ld returned 1 exit status
> make[2]: *** [bin/cl-custom-run-simple-kernel] Error 1
> make[1]: ***
> [target_api/cl/tests/cl/custom/CMakeFiles/cl-custom-run-simple-kernel.dir/all]
> Error 2
> make: *** [all] Error 2
>
> Maybe I've done something wrong, but I've tested this on two machines now
> and both times I've wiped my llvm/clang/mesa/clover installs in /usr/local
> and rebuilt from scratch.
>
Which revisions of Clang and LLVM are you using?
-Tom
> --Aaron
>
> On Wed, Feb 20, 2013 at 4:27 PM, Tom Stellard wrote:
>
> > From: Tom Stellard
> >
> > ---
> > .../state_trackers/clover/llvm/invocation.cpp | 47
> > ---
> > 1 files changed, 39 insertions(+), 8 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > index 0bd8e22..2785d10 100644
> > --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > @@ -28,10 +28,17 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > +#if HAVE_LLVM < 0x0303
> > +#include
> > #include
> > #include
> > +#else
> > +#include
> > +#include
> > +#include
> > +#include
> > +#endif
> > #include
> > #include
> > #include
> > @@ -41,8 +48,10 @@
> >
> > #if HAVE_LLVM < 0x0302
> > #include
> > -#else
> > +#elif HAVE_LLVM < 0x0303
> > #include
> > +#else
> > +#include
> > #endif
> >
> > #include "pipe/p_state.h"
> > @@ -151,7 +160,11 @@ namespace {
> >// Add libclc generic search path
> >c.getHeaderSearchOpts().AddPath(LIBCLC_INCLUDEDIR,
> >clang::frontend::Angled,
> > - false, false, false);
> > + false, false
> > +#if HAVE_LLVM < 0x0303
> > + , false
> > +#endif
> > + );
> >
> >// Add libclc include
> >c.getPreprocessorOpts().Includes.push_back("clc/clc.h");
> > @@ -167,8 +180,12 @@ namespace {
> >c.getInvocation().setLangDefaults(c.getLangOpts(), clang::IK_OpenCL,
> >
> > clang::LangStandard::lang_opencl11);
> > #endif
> > - c.createDiagnostics(0, NULL, new clang::TextDiagnosticPrinter(
> > - s_log,
> > + c.createDiagnostics(
> > +#if HAVE_LLVM < 0x0303
> > + 0, NULL,
> > +#endif
> > + new clang::TextDiagnosticPrinter(
> > + s_log,
> > #if HAVE_LLVM <= 0x0301
> > c.getDiagnosticOpts()));
> > #else
> > @@ -201,12 +218,26 @@ namespace {
> >
> >llvm::PassManager PM;
> >llvm::PassManagerBuilder Builder;
> > - bool isNative;
> > - llvm::Linker linker("clover", mod);
> > + llvm::sys::Path libclc_path =
> > +llvm::sys::Path(LIBCLC_LIBEXECDIR + triple +
> > ".bc");
> >
> >// Link the kernel with libclc
> > - linker.LinkInFile(llvm::sys::Path(LIBCLC_LIBEXECDIR + triple +
> > ".bc"), isNative);
> > +#if HAVE_LLVM < 0x0303
> > + bool isNative;
> > + llvm::Linker linker("clover", mod);
> > + linker.LinkInFile(libclc_path, isNative);
> >mod = linker.releaseModule();
> > +#else
> > + std::string err_str;
> > + llvm::SMDiagnostic err;
> > + llvm::Module *libclc_mod = llvm::ParseIRFile(libclc_path.str(), err,
> > + mod->getContext());
> > + if (llvm::Linker::LinkModules(mod, libclc_mod,
> > +llvm::Linker::DestroySource,
> > +&err_str)) {
> > + throw build_error(err_str);
> > + }
> > +#endif
> >
> >// Add a function internalizer pass.
> >//
> > --
> > 1.7.8.6
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Disable point coords when not rendering points.
On 16 February 2013 15:16, Paul Berry wrote:
> On 16 February 2013 13:52, Kenneth Graunke wrote:
>
>> On 02/16/2013 07:29 AM, Paul Berry wrote:
>>
>>> From the Ivy Bridge PRM, p268 (3DSTATE_SBE), in the description of
>>> "Point Sprite Texture Coordinate Enable":
>>>
>>> "This field must be programmed to 0 when non-point primitives are
>>> rendered."
>>>
>>> A similar admonishment exists in the Sandy Bridge PRM.
>>>
>>> Although I'm not aware of any known bugs due to us ignoring this,
>>> defying the hardware docs is generally unwise.
>>> ---
>>> src/mesa/drivers/dri/i965/**gen6_sf_state.c | 9 ++---
>>> src/mesa/drivers/dri/i965/**gen7_sf_state.c | 9 ++---
>>> 2 files changed, 12 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/**gen6_sf_state.c
>>> b/src/mesa/drivers/dri/i965/**gen6_sf_state.c
>>> index 7071acc..d88c49a 100644
>>> --- a/src/mesa/drivers/dri/i965/**gen6_sf_state.c
>>> +++ b/src/mesa/drivers/dri/i965/**gen6_sf_state.c
>>> @@ -127,6 +127,8 @@ upload_sf_state(struct brw_context *brw)
>>> /* _NEW_BUFFER */
>>> bool render_to_fbo = _mesa_is_user_fbo(brw->intel.**
>>> ctx.DrawBuffer);
>>> bool multisampled_fbo = ctx->DrawBuffer->Visual.**samples > 1;
>>> + /* BRW_NEW_REDUCED_PRIMITIVE */
>>> + bool is_point_primitive = intel->reduced_primitive == GL_POINTS;
>>>
>>
>> NAK. intel->reduced_primitive is only set in brw_set_prim(), which is
>> never called on Gen6+. (gen6_set_prim() gets called instead.)
>>
>
> Oops, you're right.
>
>
>>
>> I believe you want brw->primitive and BRW_NEW_PRIMITIVE instead.
>
>
> The disadvantage of using brw->primitive and BRW_NEW_PRIMITIVE is that it
> means this packet will get re-emitted whenever the primitive type changes.
> If reduced_primitive were available, then this packet would only be
> re-emitted when switching between triangle-like, line-like, and point
> primitives (which probably happens a lot less frequently).
>
> What would you think if instead I ported the reduced_primitive code to
> gen6+? (It's only a couple of lines).
>
After further investigation and testing, I have an additional reason to NAK
this patch. It turns out that we also need for point coordinates to work
when rendering polygons and glPolygonMode() has been used to set either
front- or back-facing polygons to GL_POINT mode (there's even a Glean test
for this). Since glPolygonMode() allows independent control of the
behaviour of front-facing and back-facing polygons, it isn't actually
possible to get correct rendering and still ensure that "Point Sprite
Texture Coordinate Enable" is 0 whenever non-point primitives are rendered.
Given that the code seems to work fine as is, I'm now inclined to just
leave well enough alone, unless someone else has a better idea.
>
>
>>
>>
>> int attr = 0, input_index = 0;
>>> int urb_entry_read_offset = 1;
>>> @@ -280,13 +282,13 @@ upload_sf_state(struct brw_context *brw)
>>> continue;
>>>
>>> /* _NEW_POINT */
>>> - if (ctx->Point.PointSprite &&
>>> + if (is_point_primitive && ctx->Point.PointSprite &&
>>> (attr >= FRAG_ATTRIB_TEX0 && attr <= FRAG_ATTRIB_TEX7) &&
>>> ctx->Point.CoordReplace[attr - FRAG_ATTRIB_TEX0]) {
>>> dw16 |= (1 << input_index);
>>> }
>>>
>>> - if (attr == FRAG_ATTRIB_PNTC)
>>> + if (is_point_primitive && attr == FRAG_ATTRIB_PNTC)
>>> dw16 |= (1 << input_index);
>>>
>>> /* flat shading */
>>> @@ -360,7 +362,8 @@ const struct brw_tracked_state gen6_sf_state = {
>>> _NEW_POINT |
>>> _NEW_MULTISAMPLE),
>>> .brw = (BRW_NEW_CONTEXT |
>>> - BRW_NEW_FRAGMENT_PROGRAM),
>>> + BRW_NEW_FRAGMENT_PROGRAM |
>>> +BRW_NEW_REDUCED_PRIMITIVE),
>>> .cache = CACHE_NEW_VS_PROG
>>> },
>>> .emit = upload_sf_state,
>>> diff --git a/src/mesa/drivers/dri/i965/**gen7_sf_state.c
>>> b/src/mesa/drivers/dri/i965/**gen7_sf_state.c
>>> index 9171eff..0f6252b 100644
>>> --- a/src/mesa/drivers/dri/i965/**gen7_sf_state.c
>>> +++ b/src/mesa/drivers/dri/i965/**gen7_sf_state.c
>>> @@ -46,6 +46,8 @@ upload_sbe_state(struct brw_context *brw)
>>> /* _NEW_BUFFERS */
>>> bool render_to_fbo = _mesa_is_user_fbo(ctx->**DrawBuffer);
>>> uint32_t point_sprite_origin;
>>> + /* BRW_NEW_REDUCED_PRIMITIVE */
>>> + bool is_point_primitive = intel->reduced_primitive == GL_POINTS;
>>>
>>> /* FINISHME: Attribute Swizzle Control Mode? */
>>> dw1 = GEN7_SBE_SWIZZLE_ENABLE | num_outputs <<
>>> GEN7_SBE_NUM_OUTPUTS_SHIFT;
>>> @@ -78,13 +80,13 @@ upload_sbe_state(struct brw_context *brw)
>>> if (!(brw->fragment_program->**Base.InputsRead &
>>> BITFIELD64_BIT(attr)))
>>> continue;
>>>
>>> - if (ctx->Point.PointSprite &&
>>> + if (is_point_primitive && ctx->Point.PointSprite &&
>>> attr >= FRAG_ATTRIB_TEX0 && attr <= FRAG_ATTRIB_TEX7 &&
>>>
Re: [Mesa-dev] [PATCH 4/6] R600: Fix for Unigine when MachineSched is enabled
On Mon, Feb 18, 2013 at 05:27:28PM +0100, Vincent Lejeune wrote:
> ---
This fixes the for-loop.cl piglit test, so I've pushed this patch and
backported it to the stable branch.
-Tom
> lib/Target/R600/R600Instructions.td | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/Target/R600/R600Instructions.td
> b/lib/Target/R600/R600Instructions.td
> index 0a777f1..74106c9 100644
> --- a/lib/Target/R600/R600Instructions.td
> +++ b/lib/Target/R600/R600Instructions.td
> @@ -1587,6 +1587,7 @@ def PRED_X : InstR600 <
>(ins R600_Reg32:$src0, i32imm:$src1, i32imm:$flags),
>"", [], NullALU> {
>let FlagOperandIdx = 3;
> + let isTerminator = 1;
> }
>
> let isTerminator = 1, isBranch = 1, isBarrier = 1 in {
> --
> 1.8.1.2
>
> ___
> 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] st/mesa: fix polygon offset state translation bug
The conditionals were testing the wrong state. Just get rid of the
conditionals since they really don't buy us anything.
Note: This is a candidate for the stable branches.
---
src/mesa/state_tracker/st_atom_rasterizer.c | 17 +
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c
b/src/mesa/state_tracker/st_atom_rasterizer.c
index f20df9e..34bc9c9 100644
--- a/src/mesa/state_tracker/st_atom_rasterizer.c
+++ b/src/mesa/state_tracker/st_atom_rasterizer.c
@@ -135,19 +135,12 @@ static void update_raster_state( struct st_context *st )
/* _NEW_POLYGON
*/
- if (ctx->Polygon.OffsetUnits != 0.0 ||
- ctx->Polygon.OffsetFactor != 0.0) {
- raster->offset_point = ctx->Polygon.OffsetPoint;
- raster->offset_line = ctx->Polygon.OffsetLine;
- raster->offset_tri = ctx->Polygon.OffsetFill;
- }
+ raster->offset_units = ctx->Polygon.OffsetUnits;
+ raster->offset_scale = ctx->Polygon.OffsetFactor;
- if (ctx->Polygon.OffsetPoint ||
- ctx->Polygon.OffsetLine ||
- ctx->Polygon.OffsetFill) {
- raster->offset_units = ctx->Polygon.OffsetUnits;
- raster->offset_scale = ctx->Polygon.OffsetFactor;
- }
+ raster->offset_point = ctx->Polygon.OffsetPoint;
+ raster->offset_line = ctx->Polygon.OffsetLine;
+ raster->offset_tri = ctx->Polygon.OffsetFill;
if (ctx->Polygon.SmoothFlag)
raster->poly_smooth = 1;
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] draw: fix broken polygon offset stage
There were several issues. We weren't handling different front/back
polygon fill modes. We weren't checking whether the offset applied to
fill mode vs. line mode vs. point mode.
Fixes problems found with the Visualization Toolkit (VTK) test suite.
Note: This is a candidate for the stable branches.
---
src/gallium/auxiliary/draw/draw_pipe_offset.c | 40 +++--
1 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_offset.c
b/src/gallium/auxiliary/draw/draw_pipe_offset.c
index 3da52b1..3578525 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_offset.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_offset.c
@@ -127,10 +127,44 @@ static void offset_first_tri( struct draw_stage *stage,
struct prim_header *header )
{
struct offset_stage *offset = offset_stage(stage);
+ const struct pipe_rasterizer_state *rast = stage->draw->rasterizer;
+ unsigned fill_mode = rast->fill_front;
+ boolean do_offset;
+
+ if (rast->fill_back != rast->fill_front) {
+ /* Need to check for back-facing triangle */
+ boolean ccw = header->det < 0.0f;
+ if (ccw != rast->front_ccw)
+ fill_mode = rast->fill_back;
+ }
+
+ /* Now determine if we need to do offsetting for the point/line/fill mode */
+ switch (fill_mode) {
+ case PIPE_POLYGON_MODE_FILL:
+ do_offset = rast->offset_tri;
+ break;
+ case PIPE_POLYGON_MODE_LINE:
+ do_offset = rast->offset_line;
+ break;
+ case PIPE_POLYGON_MODE_POINT:
+ do_offset = rast->offset_point;
+ break;
+ default:
+ assert(!"invalid fill_mode in offset_first_tri()");
+ do_offset = rast->offset_tri;
+ }
+
+ if (do_offset) {
+ offset->scale = rast->offset_scale;
+ offset->clamp = rast->offset_clamp;
+ offset->units = (float) (rast->offset_units * stage->draw->mrd);
+ }
+ else {
+ offset->scale = 0.0f;
+ offset->clamp = 0.0f;
+ offset->units = 0.0f;
+ }
- offset->units = (float) (stage->draw->rasterizer->offset_units *
stage->draw->mrd);
- offset->scale = stage->draw->rasterizer->offset_scale;
- offset->clamp = stage->draw->rasterizer->offset_clamp;
stage->tri = offset_tri;
stage->tri( stage, header );
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] llvmpipe: add missing checks for polygon offset point/line modes
The llvm pipeline handles regular filled triangle offsets, but it
doesn't handle offsets for triangles drawn in point or line mode.
Fixes failures found with new piglit polygon-mode-offset test.
Note: This is a candidate for the stable branches.
---
src/gallium/drivers/llvmpipe/lp_state_rasterizer.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_state_rasterizer.c
b/src/gallium/drivers/llvmpipe/lp_state_rasterizer.c
index 40ccaf6..ca8df71 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_rasterizer.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_rasterizer.c
@@ -46,6 +46,10 @@ clear_flags(struct pipe_rasterizer_state *rast)
{
rast->light_twoside = 0;
rast->offset_tri = 0;
+ rast->offset_line = 0;
+ rast->offset_point = 0;
+ rast->offset_units = 0.0f;
+ rast->offset_scale = 0.0f;
}
@@ -74,6 +78,8 @@ llvmpipe_create_rasterizer_state(struct pipe_context *pipe,
*/
need_pipeline = (rast->fill_front != PIPE_POLYGON_MODE_FILL ||
rast->fill_back != PIPE_POLYGON_MODE_FILL ||
+rast->offset_point ||
+rast->offset_line ||
rast->point_smooth ||
rast->line_smooth ||
rast->line_stipple_enable ||
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] llvmpipe: rename polygon offset fields to something more specific
---
src/gallium/drivers/llvmpipe/lp_state_setup.c | 15 +--
src/gallium/drivers/llvmpipe/lp_state_setup.h |4 ++--
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_state_setup.c
b/src/gallium/drivers/llvmpipe/lp_state_setup.c
index f44eed4..edd5d0f 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_setup.c
@@ -288,12 +288,15 @@ lp_do_offset_tri(struct gallivm_state *gallivm,
dzdx = LLVMBuildExtractElement(b, dzdxdzdy, zeroi, "");
dzdy = LLVMBuildExtractElement(b, dzdxdzdy, onei, "");
- /* zoffset = offset->units + MAX2(dzdx, dzdy) * offset->scale */
+ /* zoffset = pgon_offset_units + MAX2(dzdx, dzdy) * pgon_offset_scale */
max = LLVMBuildFCmp(b, LLVMRealUGT, dzdx, dzdy, "");
max_value = LLVMBuildSelect(b, max, dzdx, dzdy, "max");
- mult = LLVMBuildFMul(b, max_value, lp_build_const_float(gallivm,
key->scale), "");
- zoffset = LLVMBuildFAdd(b, lp_build_const_float(gallivm, key->units), mult,
"zoffset");
+ mult = LLVMBuildFMul(b, max_value,
+lp_build_const_float(gallivm, key->pgon_offset_scale),
"");
+ zoffset = LLVMBuildFAdd(b,
+ lp_build_const_float(gallivm,
key->pgon_offset_units),
+ mult, "zoffset");
/* yuck */
shuffles[0] = twoi;
@@ -639,7 +642,7 @@ init_args(struct gallivm_state *gallivm,
ooa = vec4f_from_scalar(gallivm, ooa, "");
/* tri offset calc shares a lot of arithmetic, do it here */
- if (key->scale != 0.0f || key->units != 0.0f) {
+ if (key->pgon_offset_scale != 0.0f || key->pgon_offset_units != 0.0f) {
lp_do_offset_tri(gallivm, args, key, ooa, dxy01, dxy20, attr_pos);
}
@@ -818,8 +821,8 @@ lp_make_setup_variant_key(struct llvmpipe_context *lp,
assert(key->spec_slot == lp->color_slot [1]);
assert(key->bspec_slot == lp->bcolor_slot[1]);
- key->units = (float) (lp->rasterizer->offset_units * lp->mrd);
- key->scale = lp->rasterizer->offset_scale;
+ key->pgon_offset_units = (float) (lp->rasterizer->offset_units * lp->mrd);
+ key->pgon_offset_scale = lp->rasterizer->offset_scale;
key->pad = 0;
memcpy(key->inputs, fs->inputs, key->num_inputs * sizeof key->inputs[0]);
for (i = 0; i < key->num_inputs; i++) {
diff --git a/src/gallium/drivers/llvmpipe/lp_state_setup.h
b/src/gallium/drivers/llvmpipe/lp_state_setup.h
index e0abe46..73d40a5 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_setup.h
+++ b/src/gallium/drivers/llvmpipe/lp_state_setup.h
@@ -27,8 +27,8 @@ struct lp_setup_variant_key {
unsigned twoside:1;
unsigned pad:5;
- float units;
- float scale;
+ float pgon_offset_units;
+ float pgon_offset_scale;
struct lp_shader_input inputs[PIPE_MAX_SHADER_INPUTS];
};
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Performance difference between driver egl_glx and egl_gallium
Hi all, I am currently wondering why I have a big difference in performance between 2 Mesa drivers: egl_glx and egl_gallium. I have already posted a mesasge 2 weeks ago on the mesa user list, but I did not receive any answer. Please find below my previous mail I am currently working on an ARM processor without graphical acceleration (based on A5 without any GPU and neon instruction). I used Open Embedded to build the distribution for my board, and therefore Mesa was compiled with the whole system for the ARM board. I made some test performance using egl_gears to find the best configuration of the EGL library. I am surprised by the difference between egl_glx and egl_gallium driver. I was expecting that the egl_gallium driver will be faster that the egl_glx driver. The egl_glx driver is around 9-10 times faster than egl_gallium. Can someone explain me what could be the difference? Did I mistake a Mesa configuration option? I try to use egl_gallium, since it is the only on driver that support FBDev Linux device, and we use FBDev has Linux driver. For information, here is my configure command line configure --build=x86_64-linux --host=arm-ing-linux-gnueabi --target=arm-ing-linux-gnueabi --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --disable-glu --disable-glw --disable-glut --enable-shared-glapi --enable-gallium-egl --with-gallium-drivers --enable-dri --with-dri-drivers=swrast --enable-gles1 --enable-gles2 --with-x --enable-glx --enable-gbm --enable-egl --with-egl-platforms=fbdev,x11 --enable-glx-tls PS: I am not an OpenGL expert, more a integrator for the system Thanks in advance for all help/information than you can provide to me. Best Regards, Yannick ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] clover: Fix build with LLVM 3.3
On Thu, Feb 21, 2013 at 8:33 AM, Tom Stellard wrote:
> On Thu, Feb 21, 2013 at 08:25:20AM -0600, Aaron Watry wrote:
> > Hi Tom,
> >
> > Mesa+Clover does indeed build against master llvm/clang, but I'm having
> > trouble building against it when I try to do a clean build of Piglit.
> >
> > Error received:
> >
> > [ 18%] Built target piglitutil_cl
> > Linking C executable ../../../../../bin/cl-custom-run-simple-kernel
> > /usr/local/lib/libOpenCL.so: undefined reference to
> >
> `clang::PPConditionalDirectiveRecord::rangeIntersectsConditionalDirective(clang::SourceRange)
> > const'
> > /usr/local/lib/libOpenCL.so: undefined reference to
> >
> `clang::PPConditionalDirectiveRecord::findConditionalDirectiveRegionLoc(clang::SourceLocation)
> > const'
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [bin/cl-custom-run-simple-kernel] Error 1
> > make[1]: ***
> >
> [target_api/cl/tests/cl/custom/CMakeFiles/cl-custom-run-simple-kernel.dir/all]
> > Error 2
> > make: *** [all] Error 2
> >
> > Maybe I've done something wrong, but I've tested this on two machines now
> > and both times I've wiped my llvm/clang/mesa/clover installs in
> /usr/local
> > and rebuilt from scratch.
> >
>
> Which revisions of Clang and LLVM are you using?
>
>
I'm not at home at the moment, so I don't have access to those machines,
but from memory:
LLVM was git master as of sometime around 6-8pm CST last night. One such
revision would be
commit ffbe432595c78ba28c8a9d200bf92996eed5e5d9
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175718 91177308-0d3
Clang was somewhere between 3bc7b6bef96 and dc84cd5efdd3430efb.
I just retested on another machine with the following versions:
LLVM: git: 0514595b9b20c9d80, svn: 175739
Clang: 7d81281fc39f6d, svn: 175741
Mesa: b63b3012c91 with your clover patch
Result:
Linking C executable ../../../../../bin/cl-custom-run-simple-kernel
/usr/local/lib/libOpenCL.so: undefined reference to
`clang::PPConditionalDirectiveRecord::rangeIntersectsConditionalDirective(clang::SourceRange)
const'
/usr/local/lib/libOpenCL.so: undefined reference to
`clang::PPConditionalDirectiveRecord::findConditionalDirectiveRegionLoc(clang::SourceLocation)
const'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/cl-custom-run-simple-kernel] Error 1
make[1]: ***
[target_api/cl/tests/cl/custom/CMakeFiles/cl-custom-run-simple-kernel.dir/all]
Error 2
make: *** [all] Error 2
--Aaron
> -Tom
>
> > --Aaron
> >
> > On Wed, Feb 20, 2013 at 4:27 PM, Tom Stellard wrote:
> >
> > > From: Tom Stellard
> > >
> > > ---
> > > .../state_trackers/clover/llvm/invocation.cpp | 47
> > > ---
> > > 1 files changed, 39 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > index 0bd8e22..2785d10 100644
> > > --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > @@ -28,10 +28,17 @@
> > > #include
> > > #include
> > > #include
> > > -#include
> > > #include
> > > +#if HAVE_LLVM < 0x0303
> > > +#include
> > > #include
> > > #include
> > > +#else
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#endif
> > > #include
> > > #include
> > > #include
> > > @@ -41,8 +48,10 @@
> > >
> > > #if HAVE_LLVM < 0x0302
> > > #include
> > > -#else
> > > +#elif HAVE_LLVM < 0x0303
> > > #include
> > > +#else
> > > +#include
> > > #endif
> > >
> > > #include "pipe/p_state.h"
> > > @@ -151,7 +160,11 @@ namespace {
> > >// Add libclc generic search path
> > >c.getHeaderSearchOpts().AddPath(LIBCLC_INCLUDEDIR,
> > >clang::frontend::Angled,
> > > - false, false, false);
> > > + false, false
> > > +#if HAVE_LLVM < 0x0303
> > > + , false
> > > +#endif
> > > + );
> > >
> > >// Add libclc include
> > >c.getPreprocessorOpts().Includes.push_back("clc/clc.h");
> > > @@ -167,8 +180,12 @@ namespace {
> > >c.getInvocation().setLangDefaults(c.getLangOpts(),
> clang::IK_OpenCL,
> > >
> > > clang::LangStandard::lang_opencl11);
> > > #endif
> > > - c.createDiagnostics(0, NULL, new clang::TextDiagnosticPrinter(
> > > - s_log,
> > > + c.createDiagnostics(
> > > +#if HAVE_LLVM < 0x0303
> > > + 0, NULL,
> > > +#endif
> > > + new clang::TextDiagnosticPrinter(
> > > + s_log,
> > > #if HAVE_LLVM <= 0x0301
> > > c.getDiagnosticOpts()));
> > > #else
> > > @@ -201,12 +218,26 @@ namespace {
> > >
> > >llvm::PassManager PM;
> > >llvm::PassManagerBuilder Builder;
> > > - bool isNative;
> > > - llv
Re: [Mesa-dev] [PATCH] clover: Fix build with LLVM 3.3
On Thu, Feb 21, 2013 at 10:02:34AM -0600, Aaron Watry wrote:
> On Thu, Feb 21, 2013 at 8:33 AM, Tom Stellard wrote:
>
> > On Thu, Feb 21, 2013 at 08:25:20AM -0600, Aaron Watry wrote:
> > > Hi Tom,
> > >
> > > Mesa+Clover does indeed build against master llvm/clang, but I'm having
> > > trouble building against it when I try to do a clean build of Piglit.
> > >
> > > Error received:
> > >
> > > [ 18%] Built target piglitutil_cl
> > > Linking C executable ../../../../../bin/cl-custom-run-simple-kernel
> > > /usr/local/lib/libOpenCL.so: undefined reference to
> > >
> > `clang::PPConditionalDirectiveRecord::rangeIntersectsConditionalDirective(clang::SourceRange)
> > > const'
> > > /usr/local/lib/libOpenCL.so: undefined reference to
> > >
> > `clang::PPConditionalDirectiveRecord::findConditionalDirectiveRegionLoc(clang::SourceLocation)
> > > const'
> > > collect2: error: ld returned 1 exit status
> > > make[2]: *** [bin/cl-custom-run-simple-kernel] Error 1
> > > make[1]: ***
> > >
> > [target_api/cl/tests/cl/custom/CMakeFiles/cl-custom-run-simple-kernel.dir/all]
> > > Error 2
> > > make: *** [all] Error 2
> > >
> > > Maybe I've done something wrong, but I've tested this on two machines now
> > > and both times I've wiped my llvm/clang/mesa/clover installs in
> > /usr/local
> > > and rebuilt from scratch.
> > >
> >
> > Which revisions of Clang and LLVM are you using?
> >
> >
> I'm not at home at the moment, so I don't have access to those machines,
> but from memory:
>
> LLVM was git master as of sometime around 6-8pm CST last night. One such
> revision would be
> commit ffbe432595c78ba28c8a9d200bf92996eed5e5d9
> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175718 91177308-0d3
>
>
> Clang was somewhere between 3bc7b6bef96 and dc84cd5efdd3430efb.
>
> I just retested on another machine with the following versions:
> LLVM: git: 0514595b9b20c9d80, svn: 175739
> Clang: 7d81281fc39f6d, svn: 175741
> Mesa: b63b3012c91 with your clover patch
>
> Result:
> Linking C executable ../../../../../bin/cl-custom-run-simple-kernel
> /usr/local/lib/libOpenCL.so: undefined reference to
> `clang::PPConditionalDirectiveRecord::rangeIntersectsConditionalDirective(clang::SourceRange)
> const'
> /usr/local/lib/libOpenCL.so: undefined reference to
> `clang::PPConditionalDirectiveRecord::findConditionalDirectiveRegionLoc(clang::SourceLocation)
> const'
> collect2: error: ld returned 1 exit status
> make[2]: *** [bin/cl-custom-run-simple-kernel] Error 1
> make[1]: ***
> [target_api/cl/tests/cl/custom/CMakeFiles/cl-custom-run-simple-kernel.dir/all]
> Error 2
> make: *** [all] Error 2
>
Did you re-configure and run make clean for piglit?
-Tom
>
>
> > -Tom
> >
> > > --Aaron
> > >
> > > On Wed, Feb 20, 2013 at 4:27 PM, Tom Stellard wrote:
> > >
> > > > From: Tom Stellard
> > > >
> > > > ---
> > > > .../state_trackers/clover/llvm/invocation.cpp | 47
> > > > ---
> > > > 1 files changed, 39 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > > b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > > index 0bd8e22..2785d10 100644
> > > > --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > > +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> > > > @@ -28,10 +28,17 @@
> > > > #include
> > > > #include
> > > > #include
> > > > -#include
> > > > #include
> > > > +#if HAVE_LLVM < 0x0303
> > > > +#include
> > > > #include
> > > > #include
> > > > +#else
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#endif
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -41,8 +48,10 @@
> > > >
> > > > #if HAVE_LLVM < 0x0302
> > > > #include
> > > > -#else
> > > > +#elif HAVE_LLVM < 0x0303
> > > > #include
> > > > +#else
> > > > +#include
> > > > #endif
> > > >
> > > > #include "pipe/p_state.h"
> > > > @@ -151,7 +160,11 @@ namespace {
> > > >// Add libclc generic search path
> > > >c.getHeaderSearchOpts().AddPath(LIBCLC_INCLUDEDIR,
> > > >clang::frontend::Angled,
> > > > - false, false, false);
> > > > + false, false
> > > > +#if HAVE_LLVM < 0x0303
> > > > + , false
> > > > +#endif
> > > > + );
> > > >
> > > >// Add libclc include
> > > >c.getPreprocessorOpts().Includes.push_back("clc/clc.h");
> > > > @@ -167,8 +180,12 @@ namespace {
> > > >c.getInvocation().setLangDefaults(c.getLangOpts(),
> > clang::IK_OpenCL,
> > > >
> > > > clang::LangStandard::lang_opencl11);
> > > > #endif
> > > > - c.createDiagnostics(0, NULL, new clang::TextDiagnosticPrinter(
> > > > - s_log,
> > > > + c.createDiagnostics(
> > > > +#if HAVE_LLVM < 0x0303
> > > > + 0, NULL,
> > > > +#e
[Mesa-dev] Mesa 9.0.3 release
Mesa 9.0.3 has been released. Mesa 9.0.3 is a bug fix release which fixes bugs found since the 9.0.2 release. The tag in the GIT repository for Mesa 9.0.3 is 'mesa-9.0.3'. Mesa 9.0.3 is available for download at ftp://freedesktop.org/pub/mesa/9.0.3/ md5sums: 168384ac0101f4600a15edd3561acdc7 MesaLib-9.0.3.tar.gz d7515cc5116c72ac63d735655bd63689 MesaLib-9.0.3.tar.bz2 a2e1c794572440fd0d839a7d7dfea00c MesaLib-9.0.3.zip I have verified building from the .tar.bz2 file by doing: tar -xjf MesaLib-9.0.3.tar.bz2 cd Mesa-9.0.3 ./configure make -j2 make install I have also verified that I pushed the tag. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gallium/docs: improve text about resources a bit.
From: Roland Scheidegger This clarifies some things and gets rid of some old stuff. The most significant one is probably that buffers cannot have formats (nearly all drivers completely ignored format and used width0 as byte size already in any case). There seems to be no use case for "structured" buffers. (Note while d3d11 has new Structured Buffers, these still aren't associated with a format, rather a byte stride, which we can't do yet either way.) --- src/gallium/docs/source/resources.rst | 62 ++--- 1 file changed, 33 insertions(+), 29 deletions(-) diff --git a/src/gallium/docs/source/resources.rst b/src/gallium/docs/source/resources.rst index c8a5766..553e335 100644 --- a/src/gallium/docs/source/resources.rst +++ b/src/gallium/docs/source/resources.rst @@ -34,44 +34,52 @@ will probably be advertised with an appropriate cap. TODO: document all targets. Note that both 3D and cube have restrictions that depend on the hardware generation. -TODO: can buffers have a non-R8 format? PIPE_BUFFER ^^^ -Buffer resource: can be used as a vertex, index, constant buffer (appropriate bind flags must be requested). +Buffer resource: can be used as a vertex, index, constant buffer +(appropriate bind flags must be requested). + +Buffers do not really have a format, it's just bytes, but they are required +to have their type set to a R8 format (without a specific "just byte" format, +R8_UINT would probably make the most sense, but for historic reasons R8_UNORM +is ok too). (This is just to make some shared buffer/texture code easier so +format size can be queried.) +width0 serves as size, most other resource properties don't apply but must be +set appropriately (depth0/height0/array_size must be 1, last_level 0). They can be bound to stream output if supported. TODO: what about the restrictions lifted by the several later GL transform feedback extensions? How does one advertise that in Gallium? -They can be also be bound to a shader stage as usual. -TODO: are all drivers supposed to support this? how does this work exactly? are there size limits? - -They can be also be bound to the framebuffer as usual. -TODO: are all drivers supposed to support this? how does this work exactly? are there size limits? +They can be also be bound to a shader stage (for sampling) as usual by +creating an appropriate sampler view, if the driver supports PIPE_CAP_TEXTURE_BUFFER_OBJECTS. +This supports larger width than a 1d texture would +(TODO limit currently unspecified, minimum must be at least 65536). +Only the "direct fetch" sample opcodes are supported (TGSI_OPCODE_TXF, +TGSI_OPCODE_SAMPLE_I) so the sampler state (coord wrapping etc.) +is mostly ignored (with SAMPLE_I there's no sampler state at all). + +They can be also be bound to the framebuffer (only as color render target, not +depth buffer, also there cannot be a depth buffer bound at the same time) as usual +by creating an appropriate view (this is not usable in OpenGL). +TODO there's no CAP bit currently for this, there's also unspecified size etc. limits TODO: is there any chance of supporting GL pixel buffer object acceleration with this? -- depth0 must be 1 -- last_level must be 0 -- TODO: what about normalization? -- TODO: wrap modes/other sampling state? -- TODO: are arbitrary formats supported? in which cases? OpenGL: vertex buffers in GL 1.5 or GL_ARB_vertex_buffer_object - Binding to stream out requires GL 3.0 or GL_NV_transform_feedback - Binding as constant buffers requires GL 3.1 or GL_ARB_uniform_buffer_object - Binding to a sampling stage requires GL 3.1 or GL_ARB_texture_buffer_object -- TODO: can they be bound to an FBO? D3D11: buffer resources - Binding to a render target requires D3D_FEATURE_LEVEL_10_0 -PIPE_TEXTURE_1D -^^^ +PIPE_TEXTURE_1D / PIPE_TEXTURE_1D_ARRAY +^^^ 1D surface accessed with normalized coordinates. - -UNIMPLEMENTED: 1D texture arrays not supported +1D array textures are supported depending on PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS. - If PIPE_CAP_NPOT_TEXTURES is not supported, width must be a power of two @@ -101,11 +109,10 @@ OpenCL: can create OpenCL images based on this, that can then be sampled arbitra D3D11: not supported (only PIPE_TEXTURE_2D with normalized coordinates is supported) -PIPE_TEXTURE_2D -^^^ +PIPE_TEXTURE_2D / PIPE_TEXTURE_2D_ARRAY +^^^ 2D surface accessed with normalized coordinates. - -UNIMPLEMENTED: 2D texture arrays not supported +2D array textures are supported depending on PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS. - If PIPE_CAP_NPOT_TEXTURES is not supported, width and height must be powers of two @@ -142,18 +149,16 @@ D3D11: 3D textures - PIPE_CAP_NPOT_TEXTURES is equivalent to D3D_FEATURE_LEVEL_10_0 -PIPE_TEXTURE_CUBE -^ +PIPE_TEXTURE_CUBE / PIPE_TEXTURE_CUBE_ARRAY +^
[Mesa-dev] [PATCH 2/2] llvmpipe: simplify buffer allocation logic.
From: Roland Scheidegger
Now with buffer formats clarification don't need all that logic any longer.
(Note that it never would have worked in any case, because blockwidth and
blockheight were swapped any allocation with multi-byte format would have
had zero size.)
---
src/gallium/drivers/llvmpipe/lp_texture.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
b/src/gallium/drivers/llvmpipe/lp_texture.c
index 1c4f1dc..d55985b 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/gallium/drivers/llvmpipe/lp_texture.c
@@ -311,13 +311,11 @@ llvmpipe_resource_create(struct pipe_screen *_screen,
}
else {
/* other data (vertex buffer, const buffer, etc) */
- const enum pipe_format format = templat->format;
- const uint w = templat->width0 / util_format_get_blockheight(format);
- /* XXX buffers should only have one dimension, those values should be 1
*/
- const uint h = templat->height0 / util_format_get_blockwidth(format);
- const uint d = templat->depth0;
- const uint bpp = util_format_get_blocksize(format);
- const uint bytes = w * h * d * bpp;
+ const uint bytes = templat->width0;
+ assert(util_format_get_blocksize(templat->format) == 1);
+ assert(templat->height0 == 1);
+ assert(templat->depth0 == 1);
+ assert(templat->last_level == 0);
lpr->data = align_malloc(bytes, 16);
if (!lpr->data)
goto fail;
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] targets/xa-vmwgfx: Force c++ linker to fix undefined symbols
NOTE: This is a candidate for the 9.1 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61200 --- src/gallium/targets/xa-vmwgfx/Makefile.am |2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/targets/xa-vmwgfx/Makefile.am b/src/gallium/targets/xa-vmwgfx/Makefile.am index 01cff4b..6fe0510 100644 --- a/src/gallium/targets/xa-vmwgfx/Makefile.am +++ b/src/gallium/targets/xa-vmwgfx/Makefile.am @@ -47,6 +47,8 @@ libxatracker_la_LIBADD = \ $(top_builddir)/src/gallium/drivers/trace/libtrace.la \ $(top_builddir)/src/gallium/drivers/rbug/librbug.la +nodist_EXTRA_libxatracker_la_SOURCES = dummy.cpp + if HAVE_MESA_LLVM libxatracker_la_LDFLAGS += $(LLVM_LDFLAGS) libxatracker_la_LIBADD += $(LLVM_LIBS) -- 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] i965/gen[45]: Do point coord logic whenever gl_PointCoord is asked for.
Ian Romanick writes: > On 02/15/2013 10:46 PM, Eric Anholt wrote: >> The desktop spec asks for gl_PointCoord to be defined only when >> GL_POINT_SPRITE is enabled, and it's undefined otherwise (why?!). The >> ES spec doesn't have GL_POINT_SPRITE and gl_PointCoord is always >> defined. So just make our implementation always give you gl_PointCoord >> regardless of the enable. > > We had a similar issue with core-profiles, which also lack the enable. > I seem to recall that we just changed the default state to enabled... > which would also fix this issue for i915. Right? Yeah, sent out a patch fixing the regression. I'm tempted to put this patch in anyway -- it gets us consistency with gen6+, and keeps you from having to think about what happens in the undefined case before. Thoughts? pgpk2rbMoaDsd.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] targets/xa-vmwgfx: Force c++ linker to fix undefined symbols
On Thu, Feb 21, 2013 at 8:41 AM, Andreas Boll wrote: > NOTE: This is a candidate for the 9.1 branch. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61200 > --- > src/gallium/targets/xa-vmwgfx/Makefile.am |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/gallium/targets/xa-vmwgfx/Makefile.am > b/src/gallium/targets/xa-vmwgfx/Makefile.am > index 01cff4b..6fe0510 100644 > --- a/src/gallium/targets/xa-vmwgfx/Makefile.am > +++ b/src/gallium/targets/xa-vmwgfx/Makefile.am > @@ -47,6 +47,8 @@ libxatracker_la_LIBADD = \ > $(top_builddir)/src/gallium/drivers/trace/libtrace.la \ > $(top_builddir)/src/gallium/drivers/rbug/librbug.la > > +nodist_EXTRA_libxatracker_la_SOURCES = dummy.cpp > + > if HAVE_MESA_LLVM > libxatracker_la_LDFLAGS += $(LLVM_LDFLAGS) > libxatracker_la_LIBADD += $(LLVM_LIBS) > -- > 1.7.10.4 Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium/docs: improve text about resources a bit.
- Original Message - > From: Roland Scheidegger > > This clarifies some things and gets rid of some old stuff. > The most significant one is probably that buffers cannot have formats > (nearly all drivers completely ignored format and used width0 as byte size > already in any case). There seems to be no use case for "structured" buffers. > (Note while d3d11 has new Structured Buffers, these still aren't associated > with a format, rather a byte stride, which we can't do yet either way.) > --- > src/gallium/docs/source/resources.rst | 62 > ++--- > 1 file changed, 33 insertions(+), 29 deletions(-) > > diff --git a/src/gallium/docs/source/resources.rst > b/src/gallium/docs/source/resources.rst > index c8a5766..553e335 100644 > --- a/src/gallium/docs/source/resources.rst > +++ b/src/gallium/docs/source/resources.rst > @@ -34,44 +34,52 @@ will probably be advertised with an appropriate cap. > TODO: document all targets. Note that both 3D and cube have restrictions > that depend on the hardware generation. > > -TODO: can buffers have a non-R8 format? > > PIPE_BUFFER > ^^^ > > -Buffer resource: can be used as a vertex, index, constant buffer > (appropriate bind flags must be requested). > +Buffer resource: can be used as a vertex, index, constant buffer > +(appropriate bind flags must be requested). > + > +Buffers do not really have a format, it's just bytes, but they are required > +to have their type set to a R8 format (without a specific "just byte" > format, > +R8_UINT would probably make the most sense, but for historic reasons > R8_UNORM > +is ok too). (This is just to make some shared buffer/texture code easier so > +format size can be queried.) > +width0 serves as size, most other resource properties don't apply but must > be > +set appropriately (depth0/height0/array_size must be 1, last_level 0). > > They can be bound to stream output if supported. > TODO: what about the restrictions lifted by the several later GL transform > feedback extensions? How does one advertise that in Gallium? > > -They can be also be bound to a shader stage as usual. > -TODO: are all drivers supposed to support this? how does this work exactly? > are there size limits? > - > -They can be also be bound to the framebuffer as usual. > -TODO: are all drivers supposed to support this? how does this work exactly? > are there size limits? > +They can be also be bound to a shader stage (for sampling) as usual by > +creating an appropriate sampler view, if the driver supports > PIPE_CAP_TEXTURE_BUFFER_OBJECTS. > +This supports larger width than a 1d texture would > +(TODO limit currently unspecified, minimum must be at least 65536). > +Only the "direct fetch" sample opcodes are supported (TGSI_OPCODE_TXF, > +TGSI_OPCODE_SAMPLE_I) so the sampler state (coord wrapping etc.) > +is mostly ignored (with SAMPLE_I there's no sampler state at all). > + > +They can be also be bound to the framebuffer (only as color render target, > not > +depth buffer, also there cannot be a depth buffer bound at the same time) as > usual > +by creating an appropriate view (this is not usable in OpenGL). > +TODO there's no CAP bit currently for this, there's also unspecified size > etc. limits > TODO: is there any chance of supporting GL pixel buffer object acceleration > with this? > > -- depth0 must be 1 > -- last_level must be 0 > -- TODO: what about normalization? > -- TODO: wrap modes/other sampling state? > -- TODO: are arbitrary formats supported? in which cases? > > OpenGL: vertex buffers in GL 1.5 or GL_ARB_vertex_buffer_object > > - Binding to stream out requires GL 3.0 or GL_NV_transform_feedback > - Binding as constant buffers requires GL 3.1 or > GL_ARB_uniform_buffer_object > - Binding to a sampling stage requires GL 3.1 or > GL_ARB_texture_buffer_object > -- TODO: can they be bound to an FBO? > > D3D11: buffer resources > - Binding to a render target requires D3D_FEATURE_LEVEL_10_0 > > -PIPE_TEXTURE_1D > -^^^ > +PIPE_TEXTURE_1D / PIPE_TEXTURE_1D_ARRAY > +^^^ > 1D surface accessed with normalized coordinates. > - > -UNIMPLEMENTED: 1D texture arrays not supported > +1D array textures are supported depending on > PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS. > > - If PIPE_CAP_NPOT_TEXTURES is not supported, >width must be a power of two > @@ -101,11 +109,10 @@ OpenCL: can create OpenCL images based on this, that > can then be sampled arbitra > > D3D11: not supported (only PIPE_TEXTURE_2D with normalized coordinates is > supported) > > -PIPE_TEXTURE_2D > -^^^ > +PIPE_TEXTURE_2D / PIPE_TEXTURE_2D_ARRAY > +^^^ > 2D surface accessed with normalized coordinates. > - > -UNIMPLEMENTED: 2D texture arrays not supported > +2D array textures are supported depending on > PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS. > > - If PIPE_CAP_NPOT_TEXTURES is not supported, >width
[Mesa-dev] [PATCH] gallium/build: Fix visibility CFLAGS in automake
From: Maarten Lankhorst v2: Andreas Boll - Fix formatting - use one CFLAG per line NOTE: This is a candidate for the 9.1 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59238 Reviewed-by: Andreas Boll --- src/gallium/auxiliary/Makefile.am |7 +-- src/gallium/drivers/rbug/Makefile.am |1 + src/gallium/drivers/svga/Makefile.am |2 ++ src/gallium/drivers/trace/Makefile.am |3 ++- src/gallium/state_trackers/xa/Makefile.am |4 +++- src/gallium/winsys/svga/drm/Makefile.am |2 ++ 6 files changed, 15 insertions(+), 4 deletions(-) diff --git a/src/gallium/auxiliary/Makefile.am b/src/gallium/auxiliary/Makefile.am index a4eee47..f14279b 100644 --- a/src/gallium/auxiliary/Makefile.am +++ b/src/gallium/auxiliary/Makefile.am @@ -7,7 +7,10 @@ noinst_LTLIBRARIES = libgallium.la AM_CFLAGS = \ -I$(top_srcdir)/src/gallium/auxiliary/util \ - $(GALLIUM_CFLAGS) + $(GALLIUM_CFLAGS) \ + $(VISIBILITY_CFLAGS) + +AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS) libgallium_la_SOURCES = \ $(C_SOURCES) \ @@ -18,7 +21,7 @@ if HAVE_MESA_LLVM AM_CFLAGS += \ $(LLVM_CFLAGS) -AM_CXXFLAGS = \ +AM_CXXFLAGS += \ $(GALLIUM_CFLAGS) \ $(LLVM_CXXFLAGS) diff --git a/src/gallium/drivers/rbug/Makefile.am b/src/gallium/drivers/rbug/Makefile.am index 655bfe1..3c1a8b5 100644 --- a/src/gallium/drivers/rbug/Makefile.am +++ b/src/gallium/drivers/rbug/Makefile.am @@ -30,6 +30,7 @@ noinst_LTLIBRARIES = librbug.la # preprocessor is determined by the ordering of the -I flags. AM_CFLAGS = \ $(GALLIUM_CFLAGS) \ + $(VISIBILITY_CFLAGS) \ -I$(top_srcdir)/src/gallium/drivers \ -I$(top_srcdir)/include diff --git a/src/gallium/drivers/svga/Makefile.am b/src/gallium/drivers/svga/Makefile.am index fdaa3c8..7eacd90 100644 --- a/src/gallium/drivers/svga/Makefile.am +++ b/src/gallium/drivers/svga/Makefile.am @@ -29,6 +29,8 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/include \ $(GALLIUM_CFLAGS) +AM_CFLAGS = $(VISIBILITY_CFLAGS) + #On some systems -std= must be added to CFLAGS to be the last -std= CFLAGS += -std=gnu99 diff --git a/src/gallium/drivers/trace/Makefile.am b/src/gallium/drivers/trace/Makefile.am index a9e1457..984ead4 100644 --- a/src/gallium/drivers/trace/Makefile.am +++ b/src/gallium/drivers/trace/Makefile.am @@ -1,7 +1,8 @@ include $(top_srcdir)/src/gallium/Automake.inc AM_CFLAGS = \ - $(GALLIUM_CFLAGS) + $(GALLIUM_CFLAGS) \ + $(VISIBILITY_CFLAGS) noinst_LTLIBRARIES = libtrace.la diff --git a/src/gallium/state_trackers/xa/Makefile.am b/src/gallium/state_trackers/xa/Makefile.am index 5b53ef9..57d55c4 100644 --- a/src/gallium/state_trackers/xa/Makefile.am +++ b/src/gallium/state_trackers/xa/Makefile.am @@ -24,7 +24,9 @@ include $(top_srcdir)/src/gallium/Automake.inc AM_CFLAGS = \ -Wall -pedantic \ - $(GALLIUM_CFLAGS) + $(GALLIUM_CFLAGS) \ + $(VISIBILITY_CFLAGS) + AM_CPPFLAGS = \ -I$(top_srcdir)/src/gallium/ \ -I$(top_srcdir)/src/gallium/winsys \ diff --git a/src/gallium/winsys/svga/drm/Makefile.am b/src/gallium/winsys/svga/drm/Makefile.am index 53bbcc2..d7ada3c 100644 --- a/src/gallium/winsys/svga/drm/Makefile.am +++ b/src/gallium/winsys/svga/drm/Makefile.am @@ -31,6 +31,8 @@ AM_CPPFLAGS = \ $(GALLIUM_CFLAGS) \ $(LIBDRM_CFLAGS) +AM_CFLAGS = $(VISIBILITY_CFLAGS) + #On some systems -std= must be added to CFLAGS to be the last -std= CFLAGS += -std=gnu99 -D_FILE_OFFSET_BITS=64 -- 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] clover: Fix build with LLVM 3.3
On Thu, Feb 21, 2013 at 10:06 AM, Tom Stellard wrote: > On Thu, Feb 21, 2013 at 10:02:34AM -0600, Aaron Watry wrote: > > On Thu, Feb 21, 2013 at 8:33 AM, Tom Stellard wrote: > > > > > On Thu, Feb 21, 2013 at 08:25:20AM -0600, Aaron Watry wrote: > > > > Hi Tom, > > > > > > > > Mesa+Clover does indeed build against master llvm/clang, but I'm > having > > > > trouble building against it when I try to do a clean build of Piglit. > > > > > > > > Error received: > > > > > > > > [ 18%] Built target piglitutil_cl > > > > Linking C executable ../../../../../bin/cl-custom-run-simple-kernel > > > > /usr/local/lib/libOpenCL.so: undefined reference to > > > > > > > > `clang::PPConditionalDirectiveRecord::rangeIntersectsConditionalDirective(clang::SourceRange) > > > > const' > > > > /usr/local/lib/libOpenCL.so: undefined reference to > > > > > > > > `clang::PPConditionalDirectiveRecord::findConditionalDirectiveRegionLoc(clang::SourceLocation) > > > > const' > > > > collect2: error: ld returned 1 exit status > > > > make[2]: *** [bin/cl-custom-run-simple-kernel] Error 1 > > > > make[1]: *** > > > > > > > > [target_api/cl/tests/cl/custom/CMakeFiles/cl-custom-run-simple-kernel.dir/all] > > > > Error 2 > > > > make: *** [all] Error 2 > > > > > > > > Maybe I've done something wrong, but I've tested this on two > machines now > > > > and both times I've wiped my llvm/clang/mesa/clover installs in > > > /usr/local > > > > and rebuilt from scratch. > > > > > > > > > > Which revisions of Clang and LLVM are you using? > > > > > > > > I'm not at home at the moment, so I don't have access to those machines, > > but from memory: > > > > LLVM was git master as of sometime around 6-8pm CST last night. One such > > revision would be > > commit ffbe432595c78ba28c8a9d200bf92996eed5e5d9 > > git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17571891177308-0d3 > > > > > > Clang was somewhere between 3bc7b6bef96 and dc84cd5efdd3430efb. > > > > I just retested on another machine with the following versions: > > LLVM: git: 0514595b9b20c9d80, svn: 175739 > > Clang: 7d81281fc39f6d, svn: 175741 > > Mesa: b63b3012c91 with your clover patch > > > > Result: > > Linking C executable ../../../../../bin/cl-custom-run-simple-kernel > > /usr/local/lib/libOpenCL.so: undefined reference to > > > `clang::PPConditionalDirectiveRecord::rangeIntersectsConditionalDirective(clang::SourceRange) > > const' > > /usr/local/lib/libOpenCL.so: undefined reference to > > > `clang::PPConditionalDirectiveRecord::findConditionalDirectiveRegionLoc(clang::SourceLocation) > > const' > > collect2: error: ld returned 1 exit status > > make[2]: *** [bin/cl-custom-run-simple-kernel] Error 1 > > make[1]: *** > > > [target_api/cl/tests/cl/custom/CMakeFiles/cl-custom-run-simple-kernel.dir/all] > > Error 2 > > make: *** [all] Error 2 > > > > Did you re-configure and run make clean for piglit? > > I did a full git clean -fdx on LLVM, Clang, libclc, Mesa, and Piglit after removing all existing LLVM/Clang/Mesa includes/libraries from /usr/local. I also did a full search for other copies of libclang on my system and the only copies were in /usr/local/lib. Note: libclc's prepare-builtins.cpp needed to be updated for LLVM 3.3 as well (moving 4 headers into . I then did a clean configure/make/make install on LLVM/libclc/Mesa, and then a clean rebuild of piglit. LLVM Configure: CC=gcc CXX=g++ ./configure --enable-optimized --enable-assertions=no --enable-experimental- targets=R600 --enable-targets=x86 --enable-shared --prefix=/usr/local Mesa Configure: ./configure --with-dri-drivers=radeon --with-gallium-drivers=r600 --enable-texture-float --enable-opencl Piglit was rebuilt clean with only the CL tests enabled. No GL, GLX , Waffle, etc. libOpenCL is linked against the 3.3 build of LLVM, but I did notice that there's no linking to clang.. I did notice that while LLVM builds a shared library, clang only installs a static archive. Are we statically linking Clang into Mesa while using the shared libLLVM? ldd /usr/local/lib/libOpenCL.so: linux-vdso.so.1 => (0x7dce1000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7effa3e21000) libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x7effa3c1c000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7effa39fd000) libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x7effa37f1000) libudev.so.0 => /lib/x86_64-linux-gnu/libudev.so.0 (0x7effa35e4000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7effa33db000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7effa31d7000) libLLVM-3.3svn.so => /usr/local/lib/libLLVM-3.3svn.so(0x7effa22d8000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7effa1fd4000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7effa1cd8000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7effa1919000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7effa1702000)
[Mesa-dev] [Bug 61052] [llvmpipe] mesa/src/gallium/auxiliary/util/u_dl.c:48: undefined reference to `dlopen'
https://bugs.freedesktop.org/show_bug.cgi?id=61052 --- Comment #2 from Andreas Boll --- Created attachment 75266 --> https://bugs.freedesktop.org/attachment.cgi?id=75266&action=edit possible fix Does this patch help? -- 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] [RFC] New EGL extension: EGL_EXT_platform_display
On 02/20/2013 05:44 PM, Eric Anholt wrote: > Chad Versace writes: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I'm seeking feedback on an EGL extension that I'm drafting. The ideas have >> already been discussed at Khronos meetings to a good reception, but I want >> feedback from Mesa developers too. >> >> Summary >> - --- >> The extension, tentatively named EGL_EXT_platform_display, enables EGL >> clients >> to specify to which platform (X11, Wayland, gbm, etc) an EGL resource >> (EGLDisplay, EGLSurface, etc) belongs when the resource is derived from >> a platform-native type. As a corollary, the extension enables the creation of >> EGL resources from different platforms within a single process. >> >> >> Feedback >> - >> I'd like to hear feeback about the details below. Do you see any potential >> problems? Is it lacking a feature that you believe should be present? > > Seems pretty reasonable as an outline. I'm not clear, though, what are > the rules on sharing EGL resources like EGLImages between EGLDisplays? If I interpreted correctly all the pertinent EGL specs, currently no resource sharing is allowed between EGLDisplays. So, the EGL_EXT_display_platform doesn't need to define additional restrictions here. Here's my reasoning based on my interpretation of the specs. I can think of four resources that can potentially be shared: - EGLContext The EGL 1.4 spec states that all contexts in a share group must belong to the same display. This restriction should not be lifted by EGL_EXT_platform_display. - EGLSurface I could find no text in the EGL 1.4 discussing sharing of EGLSurfaces, so the EGL_EXT_platform_display spec should explicitly ban sharing them between displays from different platforms. If necessary, a layered extension can add sharing for special cases. - EGLImage EGLImages are created with respect to an EGLDisplay and EGLContext, so I assume that they can be shared only among contexts within same share group. The EGL_KHR_image_base specs give any useful details about sharing. - EGLStream An EGLStream is created with respect to an EGLDisplay, but not a context. Because the spec does not say otherwise, I assume EGLStreams also cannot be shared across displays. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] llvmpipe: rename polygon offset fields to something more specific
Series is
Reviewed-by: Jose Fonseca
- Original Message -
> ---
> src/gallium/drivers/llvmpipe/lp_state_setup.c | 15 +--
> src/gallium/drivers/llvmpipe/lp_state_setup.h |4 ++--
> 2 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_state_setup.c
> b/src/gallium/drivers/llvmpipe/lp_state_setup.c
> index f44eed4..edd5d0f 100644
> --- a/src/gallium/drivers/llvmpipe/lp_state_setup.c
> +++ b/src/gallium/drivers/llvmpipe/lp_state_setup.c
> @@ -288,12 +288,15 @@ lp_do_offset_tri(struct gallivm_state *gallivm,
> dzdx = LLVMBuildExtractElement(b, dzdxdzdy, zeroi, "");
> dzdy = LLVMBuildExtractElement(b, dzdxdzdy, onei, "");
>
> - /* zoffset = offset->units + MAX2(dzdx, dzdy) * offset->scale */
> + /* zoffset = pgon_offset_units + MAX2(dzdx, dzdy) * pgon_offset_scale */
> max = LLVMBuildFCmp(b, LLVMRealUGT, dzdx, dzdy, "");
> max_value = LLVMBuildSelect(b, max, dzdx, dzdy, "max");
>
> - mult = LLVMBuildFMul(b, max_value, lp_build_const_float(gallivm,
> key->scale), "");
> - zoffset = LLVMBuildFAdd(b, lp_build_const_float(gallivm, key->units),
> mult, "zoffset");
> + mult = LLVMBuildFMul(b, max_value,
> +lp_build_const_float(gallivm,
> key->pgon_offset_scale), "");
> + zoffset = LLVMBuildFAdd(b,
> + lp_build_const_float(gallivm,
> key->pgon_offset_units),
> + mult, "zoffset");
>
> /* yuck */
> shuffles[0] = twoi;
> @@ -639,7 +642,7 @@ init_args(struct gallivm_state *gallivm,
> ooa = vec4f_from_scalar(gallivm, ooa, "");
>
> /* tri offset calc shares a lot of arithmetic, do it here */
> - if (key->scale != 0.0f || key->units != 0.0f) {
> + if (key->pgon_offset_scale != 0.0f || key->pgon_offset_units != 0.0f) {
>lp_do_offset_tri(gallivm, args, key, ooa, dxy01, dxy20, attr_pos);
> }
>
> @@ -818,8 +821,8 @@ lp_make_setup_variant_key(struct llvmpipe_context *lp,
> assert(key->spec_slot == lp->color_slot [1]);
> assert(key->bspec_slot == lp->bcolor_slot[1]);
>
> - key->units = (float) (lp->rasterizer->offset_units * lp->mrd);
> - key->scale = lp->rasterizer->offset_scale;
> + key->pgon_offset_units = (float) (lp->rasterizer->offset_units *
> lp->mrd);
> + key->pgon_offset_scale = lp->rasterizer->offset_scale;
> key->pad = 0;
> memcpy(key->inputs, fs->inputs, key->num_inputs * sizeof key->inputs[0]);
> for (i = 0; i < key->num_inputs; i++) {
> diff --git a/src/gallium/drivers/llvmpipe/lp_state_setup.h
> b/src/gallium/drivers/llvmpipe/lp_state_setup.h
> index e0abe46..73d40a5 100644
> --- a/src/gallium/drivers/llvmpipe/lp_state_setup.h
> +++ b/src/gallium/drivers/llvmpipe/lp_state_setup.h
> @@ -27,8 +27,8 @@ struct lp_setup_variant_key {
> unsigned twoside:1;
> unsigned pad:5;
>
> - float units;
> - float scale;
> + float pgon_offset_units;
> + float pgon_offset_scale;
> struct lp_shader_input inputs[PIPE_MAX_SHADER_INPUTS];
> };
>
> --
> 1.7.3.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] llvmpipe: Fix rendering into PIPE_FORMAT_X8B8G8R8_UNORM.
From: José Fonseca
Weird format, which Mesa state tracker recently started using.
Fixes segfault in
./bin/texture-packed-formats -auto
because swizzle[foo] was 0xff for padding channel (X). It still fails though.
I believe the only reason this doesn't BGRX doesn't crash is that we have
special code for when X in in the last channel.
---
src/gallium/drivers/llvmpipe/lp_state_fs.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_state_fs.c
b/src/gallium/drivers/llvmpipe/lp_state_fs.c
index 44a9fcb..9bf9b9c 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_fs.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_fs.c
@@ -1493,7 +1493,7 @@ generate_unswizzled_blend(struct gallivm_state *gallivm,
vector_width= dst_type.floating ? lp_native_vector_width :
lp_integer_vector_width;
/* Compute correct swizzle and count channels */
- memset(swizzle, 0xFF, TGSI_NUM_CHANNELS);
+ memset(swizzle, LP_BLD_SWIZZLE_DONTCARE, TGSI_NUM_CHANNELS);
dst_channels = 0;
for (i = 0; i < TGSI_NUM_CHANNELS; ++i) {
@@ -1538,7 +1538,12 @@ generate_unswizzled_blend(struct gallivm_state *gallivm,
/* Load each channel */
for (j = 0; j < dst_channels; ++j) {
- fs_src[i][j] = LLVMBuildLoad(builder,
fs_out_color[rt][swizzle[j]][i], "");
+ unsigned src_channel = swizzle[j];
+ if (src_channel < 4) {
+fs_src[i][j] = LLVMBuildLoad(builder,
fs_out_color[rt][src_channel][i], "");
+ } else {
+fs_src[i][j] = lp_build_undef(gallivm, fs_type);
+ }
}
/* If 3 channels then pad to include alpha for 4 element transpose */
@@ -1568,7 +1573,12 @@ generate_unswizzled_blend(struct gallivm_state *gallivm,
LLVMValueRef alpha = LLVMBuildLoad(builder,
fs_out_color[1][alpha_channel][i], "");
for (j = 0; j < dst_channels; ++j) {
-fs_src1[i][j] = LLVMBuildLoad(builder,
fs_out_color[1][swizzle[j]][i], "");
+unsigned src_channel = swizzle[j];
+if (src_channel < 4) {
+ fs_src1[i][j] = LLVMBuildLoad(builder,
fs_out_color[1][src_channel][i], "");
+} else {
+ fs_src1[i][j] = lp_build_undef(gallivm, fs_type);
+}
}
if (dst_channels == 3 && !has_alpha) {
fs_src1[i][3] = alpha;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: don't reserve more stack space than required v4
v4: implement exact computation taking into account wavefront size
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_asm.c| 44 +--
src/gallium/drivers/r600/r600_asm.h| 24 --
src/gallium/drivers/r600/r600_shader.c | 131 ++---
3 files changed, 142 insertions(+), 57 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index 3632aa5..f041e27 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@@ -86,6 +86,38 @@ static struct r600_bytecode_tex *r600_bytecode_tex(void)
return tex;
}
+static unsigned stack_entry_size(enum radeon_family chip) {
+ /* Wavefront size:
+* 64: R600/RV670/RV770/Cypress/R740/Barts/Turks/Caicos/
+* Aruba/Sumo/Sumo2/redwood/juniper
+* 32: R630/R730/R710/Palm/Cedar
+* 16: R610/Rs780
+*
+* Stack row size:
+* Wavefront Size16 32 48 64
+* Columns per Row (R6xx/R7xx/R8xx only) 8 8 4 4
+* Columns per Row (R9xx+)8 4 4 4 */
+
+ switch (chip) {
+ /* FIXME: are some chips missing here? */
+ /* wavefront size 16 */
+ case CHIP_RV610:
+ case CHIP_RS780:
+ /* wavefront size 32 */
+ case CHIP_RV630:
+ case CHIP_RV635:
+ case CHIP_RV730:
+ case CHIP_RV710:
+ case CHIP_PALM:
+ case CHIP_CEDAR:
+ return 8;
+
+ /* wavefront size 64 */
+ default:
+ return 4;
+ }
+}
+
void r600_bytecode_init(struct r600_bytecode *bc,
enum chip_class chip_class,
enum radeon_family family,
@@ -103,6 +135,7 @@ void r600_bytecode_init(struct r600_bytecode *bc,
LIST_INITHEAD(&bc->cf);
bc->chip_class = chip_class;
bc->msaa_texture_mode = msaa_texture_mode;
+ bc->stack.entry_size = stack_entry_size(family);
}
static int r600_bytecode_add_cf(struct r600_bytecode *bc)
@@ -1524,8 +1557,8 @@ int r600_bytecode_build(struct r600_bytecode *bc)
unsigned addr;
int i, r;
- if (bc->callstack[0].max > 0)
- bc->nstack = ((bc->callstack[0].max + 3) >> 2) + 2;
+ bc->nstack = bc->stack.max_entries;
+
if (bc->type == TGSI_PROCESSOR_VERTEX && !bc->nstack) {
bc->nstack = 1;
}
@@ -1826,8 +1859,8 @@ void r600_bytecode_disasm(struct r600_bytecode *bc)
chip = '6';
break;
}
- fprintf(stderr, "bytecode %d dw -- %d gprs -\n",
- bc->ndw, bc->ngpr);
+ fprintf(stderr, "bytecode %d dw -- %d gprs -- %d nstack
-\n",
+ bc->ndw, bc->ngpr, bc->nstack);
fprintf(stderr, "shader %d -- %c\n", index++, chip);
LIST_FOR_EACH_ENTRY(cf, &bc->cf, list) {
@@ -2105,7 +2138,8 @@ void r600_bytecode_dump(struct r600_bytecode *bc)
chip = '6';
break;
}
- fprintf(stderr, "bytecode %d dw -- %d gprs -\n",
bc->ndw, bc->ngpr);
+ fprintf(stderr, "bytecode %d dw -- %d gprs -- %d nstack
-\n",
+ bc->ndw, bc->ngpr, bc->nstack);
fprintf(stderr, " %c\n", chip);
LIST_FOR_EACH_ENTRY(cf, &bc->cf, list) {
diff --git a/src/gallium/drivers/r600/r600_asm.h
b/src/gallium/drivers/r600/r600_asm.h
index 03cd238..5a9869d 100644
--- a/src/gallium/drivers/r600/r600_asm.h
+++ b/src/gallium/drivers/r600/r600_asm.h
@@ -173,16 +173,25 @@ struct r600_cf_stack_entry {
};
#define SQ_MAX_CALL_DEPTH 0x0020
-struct r600_cf_callstack {
- unsignedfc_sp_before_entry;
- int sub_desc_index;
- int current;
- int max;
-};
#define AR_HANDLE_NORMAL 0
#define AR_HANDLE_RV6XX 1 /* except RV670 */
+struct r600_stack_info {
+ /* current level of non-WQM PUSH operations
+* (PUSH, PUSH_ELSE, ALU_PUSH_BEFORE) */
+ int push;
+ /* current level of WQM PUSH operations
+* (PUSH, PUSH_ELSE, PUSH_WQM) */
+ int push_wqm;
+ /* current loop level */
+ int loop;
+
+ /* required depth */
+ int max_entries;
+ /* subentries per entry */
+ int entry_size;
+};
struct r600_bytecode {
enum chip_class chip_class;
@@ -199,8 +208,7 @@ struct r600_bytecode {
uint32_t*bytecode;
uint32_tfc_sp;
struct r600_cf_stack_entry fc_stack[32];
- unsignedcall_sp;
- struct r600_cf_callstackcallstack[SQ_MAX_CALL_DEPTH];
+ struct r600_stack_info stack;
unsignedar_loaded;
unsignedar_reg;
unsignedar_chan;
Re: [Mesa-dev] [PATCH] r600g: don't reserve more stack space than required v4
On Thu, Feb 21, 2013 at 6:52 PM, Vadim Girlin wrote:
> v4: implement exact computation taking into account wavefront size
>
> Signed-off-by: Vadim Girlin
> ---
> src/gallium/drivers/r600/r600_asm.c| 44 +--
> src/gallium/drivers/r600/r600_asm.h| 24 --
> src/gallium/drivers/r600/r600_shader.c | 131
> ++---
> 3 files changed, 142 insertions(+), 57 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_asm.c
> b/src/gallium/drivers/r600/r600_asm.c
> index 3632aa5..f041e27 100644
> --- a/src/gallium/drivers/r600/r600_asm.c
> +++ b/src/gallium/drivers/r600/r600_asm.c
> @@ -86,6 +86,38 @@ static struct r600_bytecode_tex *r600_bytecode_tex(void)
> return tex;
> }
>
> +static unsigned stack_entry_size(enum radeon_family chip) {
> + /* Wavefront size:
> +* 64: R600/RV670/RV770/Cypress/R740/Barts/Turks/Caicos/
> +* Aruba/Sumo/Sumo2/redwood/juniper
> +* 32: R630/R730/R710/Palm/Cedar
> +* 16: R610/Rs780
> +*
> +* Stack row size:
> +* Wavefront Size16 32 48 64
> +* Columns per Row (R6xx/R7xx/R8xx only) 8 8 4 4
> +* Columns per Row (R9xx+)8 4 4 4 */
> +
> + switch (chip) {
> + /* FIXME: are some chips missing here? */
> + /* wavefront size 16 */
> + case CHIP_RV610:
> + case CHIP_RS780:
RV620
RS880
Should be 16 as well.
> + /* wavefront size 32 */
> + case CHIP_RV630:
> + case CHIP_RV635:
> + case CHIP_RV730:
> + case CHIP_RV710:
> + case CHIP_PALM:
> + case CHIP_CEDAR:
> + return 8;
> +
> + /* wavefront size 64 */
> + default:
> + return 4;
> + }
> +}
> +
> void r600_bytecode_init(struct r600_bytecode *bc,
> enum chip_class chip_class,
> enum radeon_family family,
> @@ -103,6 +135,7 @@ void r600_bytecode_init(struct r600_bytecode *bc,
> LIST_INITHEAD(&bc->cf);
> bc->chip_class = chip_class;
> bc->msaa_texture_mode = msaa_texture_mode;
> + bc->stack.entry_size = stack_entry_size(family);
> }
>
> static int r600_bytecode_add_cf(struct r600_bytecode *bc)
> @@ -1524,8 +1557,8 @@ int r600_bytecode_build(struct r600_bytecode *bc)
> unsigned addr;
> int i, r;
>
> - if (bc->callstack[0].max > 0)
> - bc->nstack = ((bc->callstack[0].max + 3) >> 2) + 2;
> + bc->nstack = bc->stack.max_entries;
> +
> if (bc->type == TGSI_PROCESSOR_VERTEX && !bc->nstack) {
> bc->nstack = 1;
> }
> @@ -1826,8 +1859,8 @@ void r600_bytecode_disasm(struct r600_bytecode *bc)
> chip = '6';
> break;
> }
> - fprintf(stderr, "bytecode %d dw -- %d gprs -\n",
> - bc->ndw, bc->ngpr);
> + fprintf(stderr, "bytecode %d dw -- %d gprs -- %d nstack
> -\n",
> + bc->ndw, bc->ngpr, bc->nstack);
> fprintf(stderr, "shader %d -- %c\n", index++, chip);
>
> LIST_FOR_EACH_ENTRY(cf, &bc->cf, list) {
> @@ -2105,7 +2138,8 @@ void r600_bytecode_dump(struct r600_bytecode *bc)
> chip = '6';
> break;
> }
> - fprintf(stderr, "bytecode %d dw -- %d gprs -\n",
> bc->ndw, bc->ngpr);
> + fprintf(stderr, "bytecode %d dw -- %d gprs -- %d nstack
> -\n",
> + bc->ndw, bc->ngpr, bc->nstack);
> fprintf(stderr, " %c\n", chip);
>
> LIST_FOR_EACH_ENTRY(cf, &bc->cf, list) {
> diff --git a/src/gallium/drivers/r600/r600_asm.h
> b/src/gallium/drivers/r600/r600_asm.h
> index 03cd238..5a9869d 100644
> --- a/src/gallium/drivers/r600/r600_asm.h
> +++ b/src/gallium/drivers/r600/r600_asm.h
> @@ -173,16 +173,25 @@ struct r600_cf_stack_entry {
> };
>
> #define SQ_MAX_CALL_DEPTH 0x0020
> -struct r600_cf_callstack {
> - unsignedfc_sp_before_entry;
> - int sub_desc_index;
> - int current;
> - int max;
> -};
>
> #define AR_HANDLE_NORMAL 0
> #define AR_HANDLE_RV6XX 1 /* except RV670 */
>
> +struct r600_stack_info {
> + /* current level of non-WQM PUSH operations
> +* (PUSH, PUSH_ELSE, ALU_PUSH_BEFORE) */
> + int push;
> + /* current level of WQM PUSH operations
> +* (PUSH, PUSH_ELSE, PUSH_WQM) */
> + int push_wqm;
> + /* current loop level */
> + int loop;
> +
> + /* required depth */
> + int max_entries;
> + /* subentries per entry */
> + int entry_size;
> +};
>
> struct r600_bytecode {
> enum chip_class chip_class;
> @@ -199,8 +208,7 @@ struct r600_bytecode {
> uint32_t*bytecode;
> uint32_t
Re: [Mesa-dev] [PATCH] r600g: don't reserve more stack space than required v4
On 02/22/2013 04:23 AM, Alex Deucher wrote:
On Thu, Feb 21, 2013 at 6:52 PM, Vadim Girlin wrote:
v4: implement exact computation taking into account wavefront size
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_asm.c| 44 +--
src/gallium/drivers/r600/r600_asm.h| 24 --
src/gallium/drivers/r600/r600_shader.c | 131 ++---
3 files changed, 142 insertions(+), 57 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index 3632aa5..f041e27 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@@ -86,6 +86,38 @@ static struct r600_bytecode_tex *r600_bytecode_tex(void)
return tex;
}
+static unsigned stack_entry_size(enum radeon_family chip) {
+ /* Wavefront size:
+* 64: R600/RV670/RV770/Cypress/R740/Barts/Turks/Caicos/
+* Aruba/Sumo/Sumo2/redwood/juniper
+* 32: R630/R730/R710/Palm/Cedar
+* 16: R610/Rs780
+*
+* Stack row size:
+* Wavefront Size16 32 48 64
+* Columns per Row (R6xx/R7xx/R8xx only) 8 8 4 4
+* Columns per Row (R9xx+)8 4 4 4 */
+
+ switch (chip) {
+ /* FIXME: are some chips missing here? */
+ /* wavefront size 16 */
+ case CHIP_RV610:
+ case CHIP_RS780:
RV620
RS880
Should be 16 as well.
Thanks, I'll add them.
Vadim
+ /* wavefront size 32 */
+ case CHIP_RV630:
+ case CHIP_RV635:
+ case CHIP_RV730:
+ case CHIP_RV710:
+ case CHIP_PALM:
+ case CHIP_CEDAR:
+ return 8;
+
+ /* wavefront size 64 */
+ default:
+ return 4;
+ }
+}
+
void r600_bytecode_init(struct r600_bytecode *bc,
enum chip_class chip_class,
enum radeon_family family,
@@ -103,6 +135,7 @@ void r600_bytecode_init(struct r600_bytecode *bc,
LIST_INITHEAD(&bc->cf);
bc->chip_class = chip_class;
bc->msaa_texture_mode = msaa_texture_mode;
+ bc->stack.entry_size = stack_entry_size(family);
}
static int r600_bytecode_add_cf(struct r600_bytecode *bc)
@@ -1524,8 +1557,8 @@ int r600_bytecode_build(struct r600_bytecode *bc)
unsigned addr;
int i, r;
- if (bc->callstack[0].max > 0)
- bc->nstack = ((bc->callstack[0].max + 3) >> 2) + 2;
+ bc->nstack = bc->stack.max_entries;
+
if (bc->type == TGSI_PROCESSOR_VERTEX && !bc->nstack) {
bc->nstack = 1;
}
@@ -1826,8 +1859,8 @@ void r600_bytecode_disasm(struct r600_bytecode *bc)
chip = '6';
break;
}
- fprintf(stderr, "bytecode %d dw -- %d gprs -\n",
- bc->ndw, bc->ngpr);
+ fprintf(stderr, "bytecode %d dw -- %d gprs -- %d nstack
-\n",
+ bc->ndw, bc->ngpr, bc->nstack);
fprintf(stderr, "shader %d -- %c\n", index++, chip);
LIST_FOR_EACH_ENTRY(cf, &bc->cf, list) {
@@ -2105,7 +2138,8 @@ void r600_bytecode_dump(struct r600_bytecode *bc)
chip = '6';
break;
}
- fprintf(stderr, "bytecode %d dw -- %d gprs -\n",
bc->ndw, bc->ngpr);
+ fprintf(stderr, "bytecode %d dw -- %d gprs -- %d nstack
-\n",
+ bc->ndw, bc->ngpr, bc->nstack);
fprintf(stderr, " %c\n", chip);
LIST_FOR_EACH_ENTRY(cf, &bc->cf, list) {
diff --git a/src/gallium/drivers/r600/r600_asm.h
b/src/gallium/drivers/r600/r600_asm.h
index 03cd238..5a9869d 100644
--- a/src/gallium/drivers/r600/r600_asm.h
+++ b/src/gallium/drivers/r600/r600_asm.h
@@ -173,16 +173,25 @@ struct r600_cf_stack_entry {
};
#define SQ_MAX_CALL_DEPTH 0x0020
-struct r600_cf_callstack {
- unsignedfc_sp_before_entry;
- int sub_desc_index;
- int current;
- int max;
-};
#define AR_HANDLE_NORMAL 0
#define AR_HANDLE_RV6XX 1 /* except RV670 */
+struct r600_stack_info {
+ /* current level of non-WQM PUSH operations
+* (PUSH, PUSH_ELSE, ALU_PUSH_BEFORE) */
+ int push;
+ /* current level of WQM PUSH operations
+* (PUSH, PUSH_ELSE, PUSH_WQM) */
+ int push_wqm;
+ /* current loop level */
+ int loop;
+
+ /* required depth */
+ int max_entries;
+ /* subentries per entry */
+ int entry_size;
+};
struct r600_bytecode {
enum chip_class chip_class;
@@ -199,8 +208,7 @@ struct r600_bytecode {
uint32_t*bytecode;
uint32_tfc_sp;
struct r600_cf_stack_entry fc_stack[32];
- unsignedcall_sp;
- struct
Re: [Mesa-dev] r600g: status of my work on the shader optimization
On 02/19/2013 08:39 PM, Andy Furniss wrote: Vadim Girlin wrote: Could you please test glxgears and other simple mesa demos? It's easier to spot the problems with small apps that don't use a lot of complex shaders. If some of them don't work correctly, please send me the dumps with "R600_DUMP_SHADERS=2 R600_SB_DUMP=3". All of the mesa demos work with and without llvm. Also it might help if you can look for piglit regressions against the piglit results with R600_SB=0 and send me the dumps for a few regressed tests. I don't actually have piglit - it was always a pain with cmake to get it to build on my old 32bit lfs with xorg/mesa installed under home. I do now have a new 64bit clfs build with everything in normal places - so maybe I'll give it a go on that - but I don't know how to use it as such. Even though it's "new" clfs uses gcc 4.6.3 so on there g++ is actually too old to build your tree - without changing some friends to friends class ... I don't know when I'll get time to learn piglit but for now here's working and not nexuiz. R600_DUMP_SHADERS=2 R600_SB_DUMP=3 nexuiz &> nexuiz-working-dump http://www.andyqos.ukfsn.org/nexuiz-working-dump R600_LLVM=0 R600_DUMP_SHADERS=2 R600_SB_DUMP=3 nexuiz &> nexuiz-corrupt-dump http://www.andyqos.ukfsn.org/nexuiz-corrupt-dump I've pushed more fixes, could you test it again? Vadim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61199] mapi/glapi/glprocs.h:2573:5: error: ‘glDiscardFramebufferEXT’ undeclared here (not in a function)
https://bugs.freedesktop.org/show_bug.cgi?id=61199 --- Comment #4 from Vinson Lee --- Comment on attachment 75234 --> https://bugs.freedesktop.org/attachment.cgi?id=75234 fix without typos included Review of attachment 75234: - Tested-by: Vinson Lee -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61052] [llvmpipe] mesa/src/gallium/auxiliary/util/u_dl.c:48: undefined reference to `dlopen'
https://bugs.freedesktop.org/show_bug.cgi?id=61052 --- Comment #3 from Vinson Lee --- Comment on attachment 75266 --> https://bugs.freedesktop.org/attachment.cgi?id=75266 possible fix Review of attachment 75266: - Tested-by: Vinson Lee -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 46376] render error when run glsl demo or mesa demo with X
https://bugs.freedesktop.org/show_bug.cgi?id=46376 --- Comment #4 from ye.tian --- The issue still exists with the follow commits: - Kernel_version: 3.8 Libdrm: 2.4.42 Mesa: (9.1)9.1-rc2 Xserver:(server-1.13-branch)xorg-server-1.13.2 Xf86_video_intel: (master)2.21.0 Cairo: (master)1.12.12 Libva: staging-20130205 Libva_intel_driver: staging-20130205 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xvmc/tests: Ensure colorkey is initialized.
Fixes uninitialized scalar variable defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/state_trackers/xvmc/tests/xvmc_bench.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
b/src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
index 4c37b8d..fe85802 100644
--- a/src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
+++ b/src/gallium/state_trackers/xvmc/tests/xvmc_bench.c
@@ -222,6 +222,10 @@ int main(int argc, char **argv)
Atom xv_colorkey = XInternAtom(display, "XV_COLORKEY", 0);
XvGetPortAttribute(display, port_num, xv_colorkey, &colorkey);
}
+ else
+ {
+ colorkey = 0;
+ }
root = XDefaultRootWindow(display);
window = XCreateSimpleWindow(display, root, 0, 0, config.output_width,
config.output_height, 0, 0, colorkey);
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] st/vdpau: Fix memory leak in vlVdpBitmapSurfaceCreate.
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/state_trackers/vdpau/bitmap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/vdpau/bitmap.c
b/src/gallium/state_trackers/vdpau/bitmap.c
index ecc5b15..469f3e8 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -83,6 +83,7 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
if (!res) {
pipe_mutex_unlock(dev->mutex);
FREE(dev);
+ FREE(vlsurface);
return VDP_STATUS_RESOURCES;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/vdpau: Fix memory leak in vlVdpOutputSurfaceCreate.
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/state_trackers/vdpau/output.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index a835126..8237eac 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -86,6 +86,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
if (!res) {
pipe_mutex_unlock(dev->mutex);
FREE(dev);
+ FREE(vlsurface);
return VDP_STATUS_ERROR;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vl: Fix off-by-one error in device_name_length allocation.
Fixes out-of-bounds write reported by Coverity. Signed-off-by: Vinson Lee --- src/gallium/auxiliary/vl/vl_winsys_dri.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c b/src/gallium/auxiliary/vl/vl_winsys_dri.c index 560c914..59c02bc 100644 --- a/src/gallium/auxiliary/vl/vl_winsys_dri.c +++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c @@ -338,7 +338,7 @@ vl_screen_create(Display *display, int screen) goto free_screen; device_name_length = xcb_dri2_connect_device_name_length(connect); - device_name = CALLOC(1, device_name_length); + device_name = CALLOC(1, device_name_length + 1); memcpy(device_name, xcb_dri2_connect_device_name(connect), device_name_length); device_name[device_name_length] = 0; fd = open(device_name, O_RDWR); -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
