[Mesa-dev] [PATCH] radeonsi: Fix anisotropic filtering state setup
From: Michel Dänzer
Bring it back in line with r600g. I broke this in the original radeonsi
bringup. :(
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78537
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/r600/r600_pipe.h | 9 -
src/gallium/drivers/radeon/r600_pipe_common.h | 9 +
src/gallium/drivers/radeonsi/si_state.c | 7 +++
3 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 952b6bd..4120359 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -829,15 +829,6 @@ static INLINE uint32_t S_FIXED(float value, uint32_t
frac_bits)
}
#define ALIGN_DIVUP(x, y) (((x) + (y) - 1) / (y))
-static inline unsigned r600_tex_aniso_filter(unsigned filter)
-{
- if (filter <= 1) return 0;
- if (filter <= 2) return 1;
- if (filter <= 4) return 2;
- if (filter <= 8) return 3;
-/* else */return 4;
-}
-
/* 12.4 fixed-point */
static INLINE unsigned r600_pack_float_12p4(float x)
{
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index ada124f..bbfcdf9 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -489,6 +489,15 @@ r600_resource_reference(struct r600_resource **ptr, struct
r600_resource *res)
(struct pipe_resource *)res);
}
+static inline unsigned r600_tex_aniso_filter(unsigned filter)
+{
+ if (filter <= 1) return 0;
+ if (filter <= 2) return 1;
+ if (filter <= 4) return 2;
+ if (filter <= 8) return 3;
+/* else */return 4;
+}
+
#define R600_ERR(fmt, args...) \
fprintf(stderr, "EE %s:%d %s - "fmt, __FILE__, __LINE__, __func__,
##args)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index a98be24..e3b72c2 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -2601,16 +2601,15 @@ static void *si_create_sampler_state(struct
pipe_context *ctx,
rstate->val[0] = (S_008F30_CLAMP_X(si_tex_wrap(state->wrap_s)) |
S_008F30_CLAMP_Y(si_tex_wrap(state->wrap_t)) |
S_008F30_CLAMP_Z(si_tex_wrap(state->wrap_r)) |
- (state->max_anisotropy & 0x7) << 9 | /* XXX */
+ r600_tex_aniso_filter(state->max_anisotropy) << 9 |
S_008F30_DEPTH_COMPARE_FUNC(si_tex_compare(state->compare_func)) |
S_008F30_FORCE_UNNORMALIZED(!state->normalized_coords) |
- aniso_flag_offset << 16 | /* XXX */
S_008F30_DISABLE_CUBE_WRAP(!state->seamless_cube_map));
rstate->val[1] = (S_008F34_MIN_LOD(S_FIXED(CLAMP(state->min_lod, 0,
15), 8)) |
S_008F34_MAX_LOD(S_FIXED(CLAMP(state->max_lod, 0,
15), 8)));
rstate->val[2] = (S_008F38_LOD_BIAS(S_FIXED(CLAMP(state->lod_bias, -16,
16), 8)) |
-
S_008F38_XY_MAG_FILTER(si_tex_filter(state->mag_img_filter)) |
-
S_008F38_XY_MIN_FILTER(si_tex_filter(state->min_img_filter)) |
+
S_008F38_XY_MAG_FILTER(si_tex_filter(state->mag_img_filter) |
aniso_flag_offset) |
+
S_008F38_XY_MIN_FILTER(si_tex_filter(state->min_img_filter) |
aniso_flag_offset) |
S_008F38_MIP_FILTER(si_tex_mipfilter(state->min_mip_filter)));
rstate->val[3] = S_008F3C_BORDER_COLOR_TYPE(border_color_type);
--
2.0.0.rc0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: don't disallow indirect addressing of temporaries
On 14.05.2014 06:45, Marek Olšák wrote:
> From: Marek Olšák
>
> It works just fine.
>
> This fixes a crash in:
> piglit/spec/glsl-1.20/execution/fs-const-array-of-struct-of-array
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78666
>
> Cc: 10.2 10.1 mesa-sta...@lists.freedesktop.org
> ---
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index bdee1f4..eab7d8a 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -4475,7 +4475,6 @@ translate_src(struct st_translate *t, const st_src_reg
> *src_reg)
>src = ureg_negate(src);
>
> if (src_reg->reladdr != NULL) {
> - assert(src_reg->file != PROGRAM_TEMPORARY);
>src = ureg_src_indirect(src, ureg_src(t->address[0]));
> }
>
>
Tested-by: Michel Dänzer
Christian added this assertion in commit
3f67251e3d0ce61a0e7fc16de91de6fb49cad768, he should probably take a look.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: don't disallow indirect addressing of temporaries
Am 14.05.2014 09:55, schrieb Michel Dänzer:
On 14.05.2014 06:45, Marek Olšák wrote:
From: Marek Olšák
It works just fine.
This fixes a crash in:
piglit/spec/glsl-1.20/execution/fs-const-array-of-struct-of-array
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78666
Cc: 10.2 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index bdee1f4..eab7d8a 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4475,7 +4475,6 @@ translate_src(struct st_translate *t, const st_src_reg
*src_reg)
src = ureg_negate(src);
if (src_reg->reladdr != NULL) {
- assert(src_reg->file != PROGRAM_TEMPORARY);
src = ureg_src_indirect(src, ureg_src(t->address[0]));
}
Tested-by: Michel Dänzer
Christian added this assertion in commit
3f67251e3d0ce61a0e7fc16de91de6fb49cad768, he should probably take a look.
That indeed should work fine. I've added this assert because temporaries
shouldn't be indirect addressed any more after adding PROGRAM_ARRAY.
So what's the reason you are hitting it again?
Regards,
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/12] gallivm: Use LLVM global context.
- Original Message - > > Hi Jose, > > On Tuesday, May 13, 2014 08:16:34 Jose Fonseca wrote: > > I tweaked the comment (was below) but indeed did a poor job. I think I'll > > just put the original back: > > > >"We must never free LLVM contexts, because LLVM has several global > >caches > >which pointing/derived from objects owned by the context, causing false > >memory leaks and false cache hits when these objects are destroyed." > > I have not actually tested your current patch series, > but I am wondering if you expect this to be thread safe then > in the sense that multiple compilations from disjoint OpenGL > contexts running in the same application in different but > concurrent threads are run? > > Up to now this is a problem that strikes me with an application here. > For example every openscenegraph viewer based application driving > multiple contexts from a single program suffers from this problem > as they are just crashing on startup when multiple contexts > in their threads compile their shaders. Flightgear is one such example. > Also I know a guy who is working in medical visualization who is > frequently asking me about llvmpipe getting thread safe in this sense. > > Given the documentation about LLVM contexts I would expect this to > crash? > > I have provided a patch some time ago that uses a struct gallivm_state > private allocated LLVM context. That one runs fine with the applications > in question and also it survived a piglit run without regressions. > Did you see this review request? > > So, I really would like to have this problem solved. > > thanks > > Mathias Hi Mathias, No, you're right, this won't be thread safe. The fact that LLVM internally also uses its global context even when we use private contexts means that fixing this probably require changes to LLVM itself though. Thread safety hasn't been an immediately for us, but I agree it is important for several apps out there, and we benefit from all the testing llvmpipe gets. So it's worthwhile addressing it. I actually missed your patch. Apologies. If you rebase it on top of my series it can be reduced to merely this: diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c b/src/gallium/auxiliary/gallivm/lp_bld_init.c index a39c1a3..3d3d590 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_init.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c @@ -76,7 +76,7 @@ void LLVMLinkInMCJIT(); * TODO: For thread safety on multi-threaded OpenGL we should use one LLVM * context per thread, and put them in a pool when threads are destroyed. */ -#define USE_GLOBAL_CONTEXT 1 +#define USE_GLOBAL_CONTEXT 0 #ifdef DEBUG The problem is that when I do this, memory starts leaking for every compilation (even with LLVM 3.4): -> 100.00% (672B): operator new(unsigned long) -> 100.00% (672B): std::_Rb_tree, llvm::EVT::compareRawBits, std::allocator >::_M_insert_unique(llvm::EVT const&) -> 100.00% (672B): llvm::SDNode::getValueTypeList(llvm::EVT) -> 100.00% (672B): llvm::SelectionDAG::getVTList(llvm::EVT) -> 50.00% (336B): llvm::SelectionDAG::getVTList(llvm::EVT const*, unsigned int) | -> 50.00% (336B): llvm::SelectionDAGBuilder::visitLoad(llvm::LoadInst const&) | -> 50.00% (336B): llvm::SelectionDAGBuilder::visit(unsigned int, llvm::User const&) | -> 50.00% (336B): llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) | -> 50.00% (336B): llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) | -> 50.00% (336B): llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) | -> 50.00% (336B): llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) | -> 50.00% (336B): llvm::FPPassManager::runOnFunction(llvm::Function&) | -> 50.00% (336B): llvm::FunctionPassManagerImpl::run(llvm::Function&) | -> 50.00% (336B): llvm::FunctionPassManager::run(llvm::Function&) | -> 50.00% (336B): llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) | -> 50.00% (336B): llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) | -> 50.00% (336B): llvm::JIT::getPointerToFunction(llvm::Function*) | -> 50.00% (336B): llvm::ExecutionEngine::getPointerToGlobal(llvm::GlobalValue const*) | -> 50.00% (336B): gallivm_jit_function [mesa/src/gallium/auxiliary/gallivm/lp_bld_init.c:596] | -> 50.00% (336B): draw_llvm_create_variant [mesa/src/gallium/auxiliary/draw/draw_llvm.c:552] | -> 50.00% (336B): llvm_middle_end_prepare [mesa/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm
Re: [Mesa-dev] [PATCH] st/mesa: don't disallow indirect addressing of temporaries
- Original Message -
> Am 14.05.2014 09:55, schrieb Michel Dänzer:
> > On 14.05.2014 06:45, Marek Olšák wrote:
> >> From: Marek Olšák
> >>
> >> It works just fine.
> >>
> >> This fixes a crash in:
> >>piglit/spec/glsl-1.20/execution/fs-const-array-of-struct-of-array
> >>
> >> Bugzilla:
> >> https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D78666&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=4oDh7QTPDxy265tHcQUwK2z%2Fl5MNY%2B573J1wEwPXNEw%3D%0A&s=3ecf79244b41160aca663def16f3b0a49b3584c46ff1270da47e33b5d5551219
> >>
> >> Cc: 10.2 10.1 mesa-sta...@lists.freedesktop.org
> >> ---
> >> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> >> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> >> index bdee1f4..eab7d8a 100644
> >> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> >> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> >> @@ -4475,7 +4475,6 @@ translate_src(struct st_translate *t, const
> >> st_src_reg *src_reg)
> >> src = ureg_negate(src);
> >>
> >> if (src_reg->reladdr != NULL) {
> >> - assert(src_reg->file != PROGRAM_TEMPORARY);
> >> src = ureg_src_indirect(src, ureg_src(t->address[0]));
> >> }
> >>
> >>
> > Tested-by: Michel Dänzer
> >
> > Christian added this assertion in commit
> > 3f67251e3d0ce61a0e7fc16de91de6fb49cad768, he should probably take a look.
> That indeed should work fine. I've added this assert because temporaries
> shouldn't be indirect addressed any more after adding PROGRAM_ARRAY.
>
> So what's the reason you are hitting it again?
>
> Regards,
> Christian.
I actually spent sometime to look into this failure a couple weeks ago.
IIRC, the problem is that the test uses arrays of one element, and in
glsl_to_tgsi_visitor::get_temp(), the condition "(type->is_array() ||
type->is_matrix()" ends up being false somehow, so the temporary is marked with
PROGRAM_TEMPORARY instead PROGRAM_ARRAY
I couldn't figure out what way the fix should go -- fix glsl or the remove the
assertion. The failure look harmless, so I ended up working on something else
and forgot about it...
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Fix anisotropic filtering state setup
Reviewed-by: Marek Olšák
Marek
On Wed, May 14, 2014 at 9:32 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Bring it back in line with r600g. I broke this in the original radeonsi
> bringup. :(
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78537
> Signed-off-by: Michel Dänzer
> ---
> src/gallium/drivers/r600/r600_pipe.h | 9 -
> src/gallium/drivers/radeon/r600_pipe_common.h | 9 +
> src/gallium/drivers/radeonsi/si_state.c | 7 +++
> 3 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_pipe.h
> b/src/gallium/drivers/r600/r600_pipe.h
> index 952b6bd..4120359 100644
> --- a/src/gallium/drivers/r600/r600_pipe.h
> +++ b/src/gallium/drivers/r600/r600_pipe.h
> @@ -829,15 +829,6 @@ static INLINE uint32_t S_FIXED(float value, uint32_t
> frac_bits)
> }
> #define ALIGN_DIVUP(x, y) (((x) + (y) - 1) / (y))
>
> -static inline unsigned r600_tex_aniso_filter(unsigned filter)
> -{
> - if (filter <= 1) return 0;
> - if (filter <= 2) return 1;
> - if (filter <= 4) return 2;
> - if (filter <= 8) return 3;
> -/* else */return 4;
> -}
> -
> /* 12.4 fixed-point */
> static INLINE unsigned r600_pack_float_12p4(float x)
> {
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
> b/src/gallium/drivers/radeon/r600_pipe_common.h
> index ada124f..bbfcdf9 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.h
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.h
> @@ -489,6 +489,15 @@ r600_resource_reference(struct r600_resource **ptr,
> struct r600_resource *res)
> (struct pipe_resource *)res);
> }
>
> +static inline unsigned r600_tex_aniso_filter(unsigned filter)
> +{
> + if (filter <= 1) return 0;
> + if (filter <= 2) return 1;
> + if (filter <= 4) return 2;
> + if (filter <= 8) return 3;
> +/* else */return 4;
> +}
> +
> #define R600_ERR(fmt, args...) \
> fprintf(stderr, "EE %s:%d %s - "fmt, __FILE__, __LINE__, __func__,
> ##args)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c
> b/src/gallium/drivers/radeonsi/si_state.c
> index a98be24..e3b72c2 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -2601,16 +2601,15 @@ static void *si_create_sampler_state(struct
> pipe_context *ctx,
> rstate->val[0] = (S_008F30_CLAMP_X(si_tex_wrap(state->wrap_s)) |
> S_008F30_CLAMP_Y(si_tex_wrap(state->wrap_t)) |
> S_008F30_CLAMP_Z(si_tex_wrap(state->wrap_r)) |
> - (state->max_anisotropy & 0x7) << 9 | /* XXX */
> + r600_tex_aniso_filter(state->max_anisotropy) << 9 |
>
> S_008F30_DEPTH_COMPARE_FUNC(si_tex_compare(state->compare_func)) |
>
> S_008F30_FORCE_UNNORMALIZED(!state->normalized_coords) |
> - aniso_flag_offset << 16 | /* XXX */
>
> S_008F30_DISABLE_CUBE_WRAP(!state->seamless_cube_map));
> rstate->val[1] = (S_008F34_MIN_LOD(S_FIXED(CLAMP(state->min_lod, 0,
> 15), 8)) |
> S_008F34_MAX_LOD(S_FIXED(CLAMP(state->max_lod, 0,
> 15), 8)));
> rstate->val[2] = (S_008F38_LOD_BIAS(S_FIXED(CLAMP(state->lod_bias,
> -16, 16), 8)) |
> -
> S_008F38_XY_MAG_FILTER(si_tex_filter(state->mag_img_filter)) |
> -
> S_008F38_XY_MIN_FILTER(si_tex_filter(state->min_img_filter)) |
> +
> S_008F38_XY_MAG_FILTER(si_tex_filter(state->mag_img_filter) |
> aniso_flag_offset) |
> +
> S_008F38_XY_MIN_FILTER(si_tex_filter(state->min_img_filter) |
> aniso_flag_offset) |
>
> S_008F38_MIP_FILTER(si_tex_mipfilter(state->min_mip_filter)));
> rstate->val[3] = S_008F3C_BORDER_COLOR_TYPE(border_color_type);
>
> --
> 2.0.0.rc0
>
> ___
> 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] gallium/docs: clarify when query results are reset
Reviewed-by: Marek Olšák Marek On Wed, May 14, 2014 at 12:25 AM, Rob Clark wrote: > From: Rob Clark > > It wasn't completely clear from the docs, so I had to figure out by > looking at piglit results. Hopefully this saves the next driver writer > implementing queries some time. > > Signed-off-by: Rob Clark > --- > src/gallium/docs/source/context.rst | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/gallium/docs/source/context.rst > b/src/gallium/docs/source/context.rst > index fc8dd16..571ee87 100644 > --- a/src/gallium/docs/source/context.rst > +++ b/src/gallium/docs/source/context.rst > @@ -300,6 +300,8 @@ Queries can be created with ``create_query`` and deleted > with > ``destroy_query``. To start a query, use ``begin_query``, and when finished, > use ``end_query`` to end the query. > > +``begin_query`` will clear/reset previous query results. > + > ``get_query_result`` is used to retrieve the results of a query. If > the ``wait`` parameter is TRUE, then the ``get_query_result`` call > will block until the results of the query are ready (and TRUE will be > -- > 1.9.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] gallivm: only fetch pointers to constant buffers once
- Original Message -
> From: Roland Scheidegger
>
> In 1d35f77228ad540a551a8e09e062b764a6e31f5e support for multiple constant
> buffers was introduced. This meant we had another indirection, and we did
> resolve the indirection for each constant buffer access. This looks very
> reasonable since llvm can figure out if it's the same pointer, however it
> turns out that this can cause llvm compilation time to go through the roof
> and beyond (I've seen cases in excess of factor 100, e.g. from 50 ms to more
> than 10 seconds (!)), with all the additional time spent in IR optimization
> passes (and in the end all of it in DominatorTree::dominate()).
> I've been unable to narrow it down a bit more (only some shaders seem
> affected,
> seemingly without much correlation to overall shader complexity or constant
> usage) but it is easily avoidable by doing the buffer lookups themeselves
> just
> once (at constant buffer declaration time).
> ---
> src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 2 +
> src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 100
> +++-
> 2 files changed, 65 insertions(+), 37 deletions(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
> index ffd6e87..88ac3c9 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
> @@ -437,6 +437,8 @@ struct lp_build_tgsi_soa_context
>
> LLVMValueRef consts_ptr;
> LLVMValueRef const_sizes_ptr;
> + LLVMValueRef consts[LP_MAX_TGSI_CONST_BUFFERS];
> + LLVMValueRef consts_sizes[LP_MAX_TGSI_CONST_BUFFERS];
> const LLVMValueRef (*inputs)[TGSI_NUM_CHANNELS];
> LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS];
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> index 2b47fc2..0eaa020 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> @@ -1213,7 +1213,6 @@ emit_fetch_constant(
> LLVMBuilderRef builder = gallivm->builder;
> struct lp_build_context *uint_bld = &bld_base->uint_bld;
> unsigned dimension = 0;
> - LLVMValueRef dimension_index;
> LLVMValueRef consts_ptr;
> LLVMValueRef num_consts;
> LLVMValueRef res;
> @@ -1227,11 +1226,8 @@ emit_fetch_constant(
>assert(dimension < LP_MAX_TGSI_CONST_BUFFERS);
> }
>
> - dimension_index = lp_build_const_int32(gallivm, dimension);
> - consts_ptr =
> - lp_build_array_get(gallivm, bld->consts_ptr, dimension_index);
> - num_consts =
> - lp_build_array_get(gallivm, bld->const_sizes_ptr, dimension_index);
> + consts_ptr = bld->consts[dimension];
> + num_consts = bld->consts_sizes[dimension];
>
> if (reg->Register.Indirect) {
>LLVMValueRef indirect_index;
> @@ -2677,56 +2673,86 @@ lp_emit_declaration_soa(
> const unsigned last = decl->Range.Last;
> unsigned idx, i;
>
> - for (idx = first; idx <= last; ++idx) {
> - assert(last <= bld->bld_base.info->file_max[decl->Declaration.File]);
> - switch (decl->Declaration.File) {
> - case TGSI_FILE_TEMPORARY:
> - if (!(bld->indirect_files & (1 << TGSI_FILE_TEMPORARY))) {
> -assert(idx < LP_MAX_INLINED_TEMPS);
> + assert(last <= bld->bld_base.info->file_max[decl->Declaration.File]);
> +
> + switch (decl->Declaration.File) {
> + case TGSI_FILE_TEMPORARY:
> + if (!(bld->indirect_files & (1 << TGSI_FILE_TEMPORARY))) {
> + assert(last < LP_MAX_INLINED_TEMPS);
> + for (idx = first; idx <= last; ++idx) {
> for (i = 0; i < TGSI_NUM_CHANNELS; i++)
> bld->temps[idx][i] = lp_build_alloca(gallivm, vec_type,
> "temp");
> }
> - break;
> + }
> + break;
>
> - case TGSI_FILE_OUTPUT:
> - if (!(bld->indirect_files & (1 << TGSI_FILE_OUTPUT))) {
> + case TGSI_FILE_OUTPUT:
> + if (!(bld->indirect_files & (1 << TGSI_FILE_OUTPUT))) {
> + for (idx = first; idx <= last; ++idx) {
> for (i = 0; i < TGSI_NUM_CHANNELS; i++)
> bld->outputs[idx][i] = lp_build_alloca(gallivm,
>vec_type, "output");
> }
> - break;
> + }
> + break;
>
> - case TGSI_FILE_ADDRESS:
> - /* ADDR registers are only allocated with an integer LLVM IR type,
> - * as they are guaranteed to always have integers.
> - * XXX: Not sure if this exception is worthwhile (or the whole idea of
> - * an ADDR register for that matter).
> - */
> + case TGSI_FILE_ADDRESS:
> + /* ADDR registers are only allocated with an integer LLVM IR type,
> + * as they are guaranteed to always have integers.
> + * XXX: Not sure if this exception is worthwhile (or the whole idea of
> + * an ADDR register for that matter).
> + */
> + assert(last < LP
Re: [Mesa-dev] [PATCH 2/4] targets/xa: limit the amount of exported symbols
ping for the series
If there is no objections I would like to push these over the weekend.
Cheers,
Emil
On 09/05/14 18:10, Emil Velikov wrote:
> ping
>
> Thomas, Rob,
> Can you please take a look if the patch makes sense ? I have double checked
> that only the required functions are exported although I may have missed
> something. IMHO you both know XA API a lot better than me :)
>
> Thanks
> Emil
>
> On 02/05/14 22:02, Emil Velikov wrote:
>> In the presence of LLVM the final library exports every symbol from
>> the llvm namespace. Resolve this by using a version script (w/o the
>> version/name tag).
>>
>> Considering that there are only ~35 symbols, explicitly list them
>> to minimize the chances of rogue symbols sneaking in.
>>
>> Signed-off-by: Emil Velikov
>> ---
>> src/gallium/targets/xa/Makefile.am | 1 +
>> src/gallium/targets/xa/xa.sym | 38
>> ++
>> 2 files changed, 39 insertions(+)
>> create mode 100644 src/gallium/targets/xa/xa.sym
>>
>> diff --git a/src/gallium/targets/xa/Makefile.am
>> b/src/gallium/targets/xa/Makefile.am
>> index 2619e57..17cd6c4 100644
>> --- a/src/gallium/targets/xa/Makefile.am
>> +++ b/src/gallium/targets/xa/Makefile.am
>> @@ -63,6 +63,7 @@ endif
>> libxatracker_la_LDFLAGS = \
>> -no-undefined \
>> -version-number $(XA_MAJOR):$(XA_MINOR):$(XA_TINY) \
>> +-Wl,--version-script=$(top_srcdir)/src/gallium/targets/xa/xa.sym \
>> $(GC_SECTIONS) \
>> $(LD_NO_UNDEFINED)
>>
>> diff --git a/src/gallium/targets/xa/xa.sym b/src/gallium/targets/xa/xa.sym
>> new file mode 100644
>> index 000..9c7f422
>> --- /dev/null
>> +++ b/src/gallium/targets/xa/xa.sym
>> @@ -0,0 +1,38 @@
>> +{
>> +global:
>> +xa_composite_allocation;
>> +xa_composite_check_accelerated;
>> +xa_composite_done;
>> +xa_composite_prepare;
>> +xa_composite_rect;
>> +xa_context_create;
>> +xa_context_default;
>> +xa_context_destroy;
>> +xa_context_flush;
>> +xa_copy;
>> +xa_copy_done;
>> +xa_copy_prepare;
>> +xa_fence_get;
>> +xa_fence_wait;
>> +xa_fence_destroy;
>> +xa_format_check_supported;
>> +xa_solid;
>> +xa_solid_done;
>> +xa_solid_prepare;
>> +xa_surface_create;
>> +xa_surface_dma;
>> +xa_surface_format;
>> +xa_surface_from_handle;
>> +xa_surface_handle;
>> +xa_surface_map;
>> +xa_surface_redefine;
>> +xa_surface_ref;
>> +xa_surface_unmap;
>> +xa_surface_unref;
>> +xa_tracker_create;
>> +xa_tracker_destroy;
>> +xa_tracker_version;
>> +xa_yuv_planar_blit;
>> +local:
>> +*;
>> +};
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/docs: clarify when query results are reset
Am 14.05.2014 00:25, schrieb Rob Clark: > From: Rob Clark > > It wasn't completely clear from the docs, so I had to figure out by > looking at piglit results. Hopefully this saves the next driver writer > implementing queries some time. > > Signed-off-by: Rob Clark > --- > src/gallium/docs/source/context.rst | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/gallium/docs/source/context.rst > b/src/gallium/docs/source/context.rst > index fc8dd16..571ee87 100644 > --- a/src/gallium/docs/source/context.rst > +++ b/src/gallium/docs/source/context.rst > @@ -300,6 +300,8 @@ Queries can be created with ``create_query`` and deleted > with > ``destroy_query``. To start a query, use ``begin_query``, and when finished, > use ``end_query`` to end the query. > > +``begin_query`` will clear/reset previous query results. > + > ``get_query_result`` is used to retrieve the results of a query. If > the ``wait`` parameter is TRUE, then the ``get_query_result`` call > will block until the results of the query are ready (and TRUE will be > Looks good. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78666] [r600g glsl-1.20] fs-const-array-of-struct-of-array broken on 6550D
https://bugs.freedesktop.org/show_bug.cgi?id=78666 --- Comment #3 from David Heidelberger (okias) --- (In reply to comment #2) > The assertion fails while translating from GLSL IR to TGSI. and when it's compiled without debug information, it just segfault elsewhere -- 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 0/3] Fix Apple-DRI GLX
On 13/05/14 13:15, Jon TURNEY wrote: > On 16/02/2014 02:00, Jeremy Huddleston Sequoia wrote: >> Mesa master hasn't built for OSX for over a year now, unfortunately, >> but I agree excluding in Makefile.am is preferable to cpp-guards. >> Hopefully "someone" will have the time and patience to get it working >> again in the near future. > > On 18/02/2014 01:35, Jeremy Huddleston Sequoia wrote: >> Apple-DRI is something completely different. It uses >> OpenGL.framework and is not backed by gallium or swrast. It was done >> over a decade ago as a branch of XFree86 that was never accepted and >> merged back in. Code diverged and about 7 years ago, we started >> trying to get XQuartz' merged into freedesktop.org. That process was >> pretty much fully completed by about 4 years ago except for mesa. >> Mesa only supports AppleDRI in a separate build configuration which >> makes it impossible to have a libGL that supports indirect GLX when >> the server is remote and Apple-DRI when it is local. > > Since in it's current state this code is a bit of a roadblock for some work I > want to do to add something similar for Cygwin, I've had a go at fixing this > up. > > The nomenclature in [2/3] isn't very satisfactory, but I couldn't come up > with > anything better. > > Jon TURNEY (3): > Fix build for darwin > Make DRI dependencies and build depend on the target > Fix build of appleglx > Great work Jon. Have to agree with the nomenclature comment (re patch [2/3]) although it's consistent and makes sense with how mesa is built. I have a minor nitpick wrt the --version-script detection code. Can you use something like this instead [1] ? I will give the patches a test over the next new days. Cheers, Emil [1] http://git.eyrie.org/?p=devel/rra-c-util.git;a=blob;f=m4/ld-version.m4;hb=HEAD > configure.ac | 96 + > src/egl/main/Makefile.am | 2 +- > src/gallium/Automake.inc | 8 ++ > src/gallium/state_trackers/Makefile.am | 2 +- > src/gallium/state_trackers/dri/Makefile.am | 6 +- > src/gallium/targets/Makefile.am| 18 ++-- > src/gallium/targets/gbm/Makefile.am| 2 +- > src/gallium/targets/opencl/Makefile.am | 2 +- > src/gallium/targets/xa/Makefile.am | 2 +- > src/gallium/tests/trivial/Makefile.am | 2 +- > src/gallium/winsys/Makefile.am | 2 +- > src/gbm/Makefile.am| 2 +- > src/glx/Makefile.am| 31 +-- > src/glx/apple/Makefile | 131 > src/glx/apple/Makefile.am | 31 +++ > src/glx/apple/apple_glapi.c| 1 + > src/glx/apple/apple_glx.c | 2 - > src/glx/apple/apple_glx.h | 1 - > src/glx/apple/apple_xgl_api_read.c | 1 + > src/glx/apple/apple_xgl_api_stereo.c | 7 +- > src/glx/apple/apple_xgl_api_viewport.c | 1 + > src/glx/apple/glxreply.c | 134 > - > src/glx/applegl_glx.c | 6 +- > src/glx/glx_pbuffer.c | 2 +- > src/glx/glxcmds.c | 4 +- > src/glx/glxcurrent.c | 6 -- > src/glx/glxext.c | 4 +- > src/glx/indirect_glx.c | 4 + > src/glx/render2.c | 4 + > src/glx/vertarr.c | 3 + > src/mapi/glapi/Makefile.am | 4 +- > src/mapi/glapi/Makefile.sources| 4 +- > src/mapi/glapi/gen/glX_proto_send.py | 3 + > src/mesa/Makefile.am | 2 +- > src/mesa/drivers/dri/Makefile.am | 2 +- > 35 files changed, 201 insertions(+), 331 deletions(-) > delete mode 100644 src/glx/apple/Makefile > create mode 100644 src/glx/apple/Makefile.am > delete mode 100644 src/glx/apple/glxreply.c > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Fix anisotropic filtering state setup
On Wed, May 14, 2014 at 3:32 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Bring it back in line with r600g. I broke this in the original radeonsi
> bringup. :(
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78537
> Signed-off-by: Michel Dänzer
CC stable?
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_pipe.h | 9 -
> src/gallium/drivers/radeon/r600_pipe_common.h | 9 +
> src/gallium/drivers/radeonsi/si_state.c | 7 +++
> 3 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_pipe.h
> b/src/gallium/drivers/r600/r600_pipe.h
> index 952b6bd..4120359 100644
> --- a/src/gallium/drivers/r600/r600_pipe.h
> +++ b/src/gallium/drivers/r600/r600_pipe.h
> @@ -829,15 +829,6 @@ static INLINE uint32_t S_FIXED(float value, uint32_t
> frac_bits)
> }
> #define ALIGN_DIVUP(x, y) (((x) + (y) - 1) / (y))
>
> -static inline unsigned r600_tex_aniso_filter(unsigned filter)
> -{
> - if (filter <= 1) return 0;
> - if (filter <= 2) return 1;
> - if (filter <= 4) return 2;
> - if (filter <= 8) return 3;
> -/* else */return 4;
> -}
> -
> /* 12.4 fixed-point */
> static INLINE unsigned r600_pack_float_12p4(float x)
> {
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
> b/src/gallium/drivers/radeon/r600_pipe_common.h
> index ada124f..bbfcdf9 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.h
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.h
> @@ -489,6 +489,15 @@ r600_resource_reference(struct r600_resource **ptr,
> struct r600_resource *res)
> (struct pipe_resource *)res);
> }
>
> +static inline unsigned r600_tex_aniso_filter(unsigned filter)
> +{
> + if (filter <= 1) return 0;
> + if (filter <= 2) return 1;
> + if (filter <= 4) return 2;
> + if (filter <= 8) return 3;
> +/* else */return 4;
> +}
> +
> #define R600_ERR(fmt, args...) \
> fprintf(stderr, "EE %s:%d %s - "fmt, __FILE__, __LINE__, __func__,
> ##args)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c
> b/src/gallium/drivers/radeonsi/si_state.c
> index a98be24..e3b72c2 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -2601,16 +2601,15 @@ static void *si_create_sampler_state(struct
> pipe_context *ctx,
> rstate->val[0] = (S_008F30_CLAMP_X(si_tex_wrap(state->wrap_s)) |
> S_008F30_CLAMP_Y(si_tex_wrap(state->wrap_t)) |
> S_008F30_CLAMP_Z(si_tex_wrap(state->wrap_r)) |
> - (state->max_anisotropy & 0x7) << 9 | /* XXX */
> + r600_tex_aniso_filter(state->max_anisotropy) << 9 |
>
> S_008F30_DEPTH_COMPARE_FUNC(si_tex_compare(state->compare_func)) |
>
> S_008F30_FORCE_UNNORMALIZED(!state->normalized_coords) |
> - aniso_flag_offset << 16 | /* XXX */
>
> S_008F30_DISABLE_CUBE_WRAP(!state->seamless_cube_map));
> rstate->val[1] = (S_008F34_MIN_LOD(S_FIXED(CLAMP(state->min_lod, 0,
> 15), 8)) |
> S_008F34_MAX_LOD(S_FIXED(CLAMP(state->max_lod, 0,
> 15), 8)));
> rstate->val[2] = (S_008F38_LOD_BIAS(S_FIXED(CLAMP(state->lod_bias,
> -16, 16), 8)) |
> -
> S_008F38_XY_MAG_FILTER(si_tex_filter(state->mag_img_filter)) |
> -
> S_008F38_XY_MIN_FILTER(si_tex_filter(state->min_img_filter)) |
> +
> S_008F38_XY_MAG_FILTER(si_tex_filter(state->mag_img_filter) |
> aniso_flag_offset) |
> +
> S_008F38_XY_MIN_FILTER(si_tex_filter(state->min_img_filter) |
> aniso_flag_offset) |
>
> S_008F38_MIP_FILTER(si_tex_mipfilter(state->min_mip_filter)));
> rstate->val[3] = S_008F3C_BORDER_COLOR_TYPE(border_color_type);
>
> --
> 2.0.0.rc0
>
> ___
> 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] st/mesa: don't disallow indirect addressing of temporaries
On 14.05.2014 06:45, Marek Olšák wrote:
> From: Marek Olšák
>
> It works just fine.
>
> This fixes a crash in:
> piglit/spec/glsl-1.20/execution/fs-const-array-of-struct-of-array
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78666
>
> Cc: 10.2 10.1 mesa-sta...@lists.freedesktop.org
> ---
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index bdee1f4..eab7d8a 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -4475,7 +4475,6 @@ translate_src(struct st_translate *t, const st_src_reg
> *src_reg)
>src = ureg_negate(src);
>
> if (src_reg->reladdr != NULL) {
> - assert(src_reg->file != PROGRAM_TEMPORARY);
>src = ureg_src_indirect(src, ureg_src(t->address[0]));
> }
>
>
Maybe this doesn't work for r600g:
https://bugs.freedesktop.org/show_bug.cgi?id=78666#c3
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gallivm: Support MCJIT on Windows.
From: José Fonseca
It works fine, though it requires using ELF objects.
With this change there is nothing preventing us to switch exclusively
to MCJIT, everywhere. It's still off though.
---
scons/llvm.py | 8 +++-
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 9 +
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/scons/llvm.py b/scons/llvm.py
index cdfbe43..288a080 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -104,7 +104,7 @@ def generate(env):
'LLVMBitWriter', 'LLVMX86Disassembler', 'LLVMX86AsmParser',
'LLVMX86CodeGen', 'LLVMX86Desc', 'LLVMSelectionDAG',
'LLVMAsmPrinter', 'LLVMMCParser', 'LLVMX86AsmPrinter',
-'LLVMX86Utils', 'LLVMX86Info', 'LLVMJIT',
+'LLVMX86Utils', 'LLVMX86Info', 'LLVMMCJIT', 'LLVMJIT',
'LLVMExecutionEngine', 'LLVMCodeGen', 'LLVMScalarOpts',
'LLVMInstCombine', 'LLVMTransformUtils', 'LLVMipa',
'LLVMAnalysis', 'LLVMTarget', 'LLVMMC', 'LLVMCore',
@@ -116,7 +116,7 @@ def generate(env):
'LLVMBitWriter', 'LLVMX86Disassembler', 'LLVMX86AsmParser',
'LLVMX86CodeGen', 'LLVMX86Desc', 'LLVMSelectionDAG',
'LLVMAsmPrinter', 'LLVMMCParser', 'LLVMX86AsmPrinter',
-'LLVMX86Utils', 'LLVMX86Info', 'LLVMJIT',
+'LLVMX86Utils', 'LLVMX86Info', 'LLVMMCJIT', 'LLVMJIT',
'LLVMExecutionEngine', 'LLVMCodeGen', 'LLVMScalarOpts',
'LLVMInstCombine', 'LLVMTransformUtils', 'LLVMipa',
'LLVMAnalysis', 'LLVMTarget', 'LLVMMC', 'LLVMCore',
@@ -165,9 +165,7 @@ def generate(env):
if '-fno-rtti' in cxxflags:
env.Append(CXXFLAGS = ['-fno-rtti'])
-components = ['engine', 'bitwriter', 'x86asmprinter']
-
-components.append('mcjit')
+components = ['engine', 'mcjit', 'bitwriter', 'x86asmprinter']
env.ParseConfig('llvm-config --libs ' + ' '.join(components))
env.ParseConfig('llvm-config --ldflags')
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index d03680f..4d63f9a 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -57,6 +57,7 @@
#include
#include
#include
+#include
#include
#include
@@ -452,6 +453,14 @@
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
if (useMCJIT) {
builder.setUseMCJIT(true);
+#ifdef _WIN32
+ /*
+ * MCJIT works on Windows, but currently only through ELF object format.
+ */
+ std::string targetTriple = llvm::sys::getProcessTriple();
+ targetTriple.append("-elf");
+ unwrap(M)->setTargetTriple(targetTriple);
+#endif
}
llvm::SmallVector MAttrs;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] gallivm: Disable workaround for PR12833 on LLVM 3.2+.
From: José Fonseca Fixed upstream. --- src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp index 4d63f9a..ec54776 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp @@ -484,11 +484,11 @@ lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT, builder.setJITMemoryManager(MM); ExecutionEngine *JIT; -#if 0 +#if HAVE_LLVM >= 0x0302 JIT = builder.create(); #else /* -* Workaround http://llvm.org/bugs/show_bug.cgi?id=12833 +* Workaround http://llvm.org/PR12833 */ StringRef MArch = ""; StringRef MCPU = ""; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Fix anisotropic filtering state setup
On 14.05.2014 22:49, Alex Deucher wrote: > On Wed, May 14, 2014 at 3:32 AM, Michel Dänzer wrote: >> From: Michel Dänzer >> >> Bring it back in line with r600g. I broke this in the original radeonsi >> bringup. :( >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78537 >> Signed-off-by: Michel Dänzer > > CC stable? Yep, thanks for the reminder (and for the review, guys :). -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78700] New: Debug warnings should be generated when BindAttribLocation isn't followed by a re-link
https://bugs.freedesktop.org/show_bug.cgi?id=78700 Priority: medium Bug ID: 78700 Assignee: mesa-dev@lists.freedesktop.org Summary: Debug warnings should be generated when BindAttribLocation isn't followed by a re-link Severity: normal Classification: Unclassified OS: All Reporter: i...@freedesktop.org Hardware: All Status: NEW Version: git Component: Mesa core Product: Mesa We have seen applications in the past that do something like: glCompileShader(...); glAttachShader(...); glLinkProgram(...); glBindAttribLocation(...); draw(...); However, the glBindAttribLocation doesn't take affect until glLinkProgram is called again. With separate shader objects, you can't generally re-link the program because glCreateShaderProgramv implicitly deletes the shader after linking. glCreateShaderProgramv(...); glBindAttribLocation(...); // can probably never do anything Both of these cases should get warnings via ARB_debug callbacks. -- 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 2/2] gallivm: only fetch pointers to constant buffers once
Am 14.05.2014 13:43, schrieb Jose Fonseca:
>
>
> - Original Message -
>> From: Roland Scheidegger
>>
>> In 1d35f77228ad540a551a8e09e062b764a6e31f5e support for multiple constant
>> buffers was introduced. This meant we had another indirection, and we did
>> resolve the indirection for each constant buffer access. This looks very
>> reasonable since llvm can figure out if it's the same pointer, however it
>> turns out that this can cause llvm compilation time to go through the roof
>> and beyond (I've seen cases in excess of factor 100, e.g. from 50 ms to more
>> than 10 seconds (!)), with all the additional time spent in IR optimization
>> passes (and in the end all of it in DominatorTree::dominate()).
>> I've been unable to narrow it down a bit more (only some shaders seem
>> affected,
>> seemingly without much correlation to overall shader complexity or constant
>> usage) but it is easily avoidable by doing the buffer lookups themeselves
>> just
>> once (at constant buffer declaration time).
>> ---
>> src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 2 +
>> src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 100
>> +++-
>> 2 files changed, 65 insertions(+), 37 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
>> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
>> index ffd6e87..88ac3c9 100644
>> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
>> @@ -437,6 +437,8 @@ struct lp_build_tgsi_soa_context
>>
>> LLVMValueRef consts_ptr;
>> LLVMValueRef const_sizes_ptr;
>> + LLVMValueRef consts[LP_MAX_TGSI_CONST_BUFFERS];
>> + LLVMValueRef consts_sizes[LP_MAX_TGSI_CONST_BUFFERS];
>> const LLVMValueRef (*inputs)[TGSI_NUM_CHANNELS];
>> LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS];
>>
>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
>> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
>> index 2b47fc2..0eaa020 100644
>> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
>> @@ -1213,7 +1213,6 @@ emit_fetch_constant(
>> LLVMBuilderRef builder = gallivm->builder;
>> struct lp_build_context *uint_bld = &bld_base->uint_bld;
>> unsigned dimension = 0;
>> - LLVMValueRef dimension_index;
>> LLVMValueRef consts_ptr;
>> LLVMValueRef num_consts;
>> LLVMValueRef res;
>> @@ -1227,11 +1226,8 @@ emit_fetch_constant(
>>assert(dimension < LP_MAX_TGSI_CONST_BUFFERS);
>> }
>>
>> - dimension_index = lp_build_const_int32(gallivm, dimension);
>> - consts_ptr =
>> - lp_build_array_get(gallivm, bld->consts_ptr, dimension_index);
>> - num_consts =
>> - lp_build_array_get(gallivm, bld->const_sizes_ptr, dimension_index);
>> + consts_ptr = bld->consts[dimension];
>> + num_consts = bld->consts_sizes[dimension];
>>
>> if (reg->Register.Indirect) {
>>LLVMValueRef indirect_index;
>> @@ -2677,56 +2673,86 @@ lp_emit_declaration_soa(
>> const unsigned last = decl->Range.Last;
>> unsigned idx, i;
>>
>> - for (idx = first; idx <= last; ++idx) {
>> - assert(last <= bld->bld_base.info->file_max[decl->Declaration.File]);
>> - switch (decl->Declaration.File) {
>> - case TGSI_FILE_TEMPORARY:
>> - if (!(bld->indirect_files & (1 << TGSI_FILE_TEMPORARY))) {
>> -assert(idx < LP_MAX_INLINED_TEMPS);
>> + assert(last <= bld->bld_base.info->file_max[decl->Declaration.File]);
>> +
>> + switch (decl->Declaration.File) {
>> + case TGSI_FILE_TEMPORARY:
>> + if (!(bld->indirect_files & (1 << TGSI_FILE_TEMPORARY))) {
>> + assert(last < LP_MAX_INLINED_TEMPS);
>> + for (idx = first; idx <= last; ++idx) {
>> for (i = 0; i < TGSI_NUM_CHANNELS; i++)
>> bld->temps[idx][i] = lp_build_alloca(gallivm, vec_type,
>> "temp");
>> }
>> - break;
>> + }
>> + break;
>>
>> - case TGSI_FILE_OUTPUT:
>> - if (!(bld->indirect_files & (1 << TGSI_FILE_OUTPUT))) {
>> + case TGSI_FILE_OUTPUT:
>> + if (!(bld->indirect_files & (1 << TGSI_FILE_OUTPUT))) {
>> + for (idx = first; idx <= last; ++idx) {
>> for (i = 0; i < TGSI_NUM_CHANNELS; i++)
>> bld->outputs[idx][i] = lp_build_alloca(gallivm,
>>vec_type, "output");
>> }
>> - break;
>> + }
>> + break;
>>
>> - case TGSI_FILE_ADDRESS:
>> - /* ADDR registers are only allocated with an integer LLVM IR type,
>> - * as they are guaranteed to always have integers.
>> - * XXX: Not sure if this exception is worthwhile (or the whole idea of
>> - * an ADDR register for that matter).
>> - */
>> + case TGSI_FILE_ADDRESS:
>> + /* ADDR registers are only allocated with an integer LLVM IR type,
>> + * as they are guaranteed to always have integers.
>> + *
Re: [Mesa-dev] [PATCH 05/12] gallivm: Use LLVM global context.
On 05/14/2014 03:45 AM, Jose Fonseca wrote: - Original Message - Hi Jose, On Tuesday, May 13, 2014 08:16:34 Jose Fonseca wrote: I tweaked the comment (was below) but indeed did a poor job. I think I'll just put the original back: "We must never free LLVM contexts, because LLVM has several global caches which pointing/derived from objects owned by the context, causing false memory leaks and false cache hits when these objects are destroyed." I have not actually tested your current patch series, but I am wondering if you expect this to be thread safe then in the sense that multiple compilations from disjoint OpenGL contexts running in the same application in different but concurrent threads are run? Up to now this is a problem that strikes me with an application here. For example every openscenegraph viewer based application driving multiple contexts from a single program suffers from this problem as they are just crashing on startup when multiple contexts in their threads compile their shaders. Flightgear is one such example. Also I know a guy who is working in medical visualization who is frequently asking me about llvmpipe getting thread safe in this sense. Given the documentation about LLVM contexts I would expect this to crash? I have provided a patch some time ago that uses a struct gallivm_state private allocated LLVM context. That one runs fine with the applications in question and also it survived a piglit run without regressions. Did you see this review request? So, I really would like to have this problem solved. thanks Mathias Hi Mathias, No, you're right, this won't be thread safe. The fact that LLVM internally also uses its global context even when we use private contexts means that fixing this probably require changes to LLVM itself though. Thread safety hasn't been an immediately for us, but I agree it is important for several apps out there, and we benefit from all the testing llvmpipe gets. So it's worthwhile addressing it. How about simply putting a mutex around the code which invokes LLVM? It's not ideal by any means, but I think it might work. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/12] gallivm: Use LLVM global context.
- Original Message - > On 05/14/2014 03:45 AM, Jose Fonseca wrote: > > - Original Message - > >> > >> Hi Jose, > >> > >> On Tuesday, May 13, 2014 08:16:34 Jose Fonseca wrote: > >>> I tweaked the comment (was below) but indeed did a poor job. I think > >>> I'll > >>> just put the original back: > >>> > >>> "We must never free LLVM contexts, because LLVM has several global > >>> caches > >>> which pointing/derived from objects owned by the context, causing > >>> false > >>> memory leaks and false cache hits when these objects are destroyed." > >> > >> I have not actually tested your current patch series, > >> but I am wondering if you expect this to be thread safe then > >> in the sense that multiple compilations from disjoint OpenGL > >> contexts running in the same application in different but > >> concurrent threads are run? > >> > >> Up to now this is a problem that strikes me with an application here. > >> For example every openscenegraph viewer based application driving > >> multiple contexts from a single program suffers from this problem > >> as they are just crashing on startup when multiple contexts > >> in their threads compile their shaders. Flightgear is one such example. > >> Also I know a guy who is working in medical visualization who is > >> frequently asking me about llvmpipe getting thread safe in this sense. > >> > >> Given the documentation about LLVM contexts I would expect this to > >> crash? > >> > >> I have provided a patch some time ago that uses a struct gallivm_state > >> private allocated LLVM context. That one runs fine with the applications > >> in question and also it survived a piglit run without regressions. > >> Did you see this review request? > >> > >> So, I really would like to have this problem solved. > >> > >> thanks > >> > >> Mathias > > > > Hi Mathias, > > > > No, you're right, this won't be thread safe. The fact that LLVM internally > > also uses its global context even when we use private contexts means that > > fixing this probably require changes to LLVM itself though. > > > > Thread safety hasn't been an immediately for us, but I agree it is > > important for several apps out there, and we benefit from all the testing > > llvmpipe gets. So it's worthwhile addressing it. > > How about simply putting a mutex around the code which invokes LLVM? > It's not ideal by any means, but I think it might work. It's not easy because some of the LLVM objects used while building the IR are long lived, which means we'll need need to hold mutex, return to caller, and rely on the caller to callback into gallivm to release the mutex. Which can be a recipe for a deadlock if something happens and the caller doesn't finish the compilation some how. But now you mention, I just rememered that we'll also need to protect Frank's global JIT manager in a mutex and/or create a separate JIT manager for each thread. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glsl: should uniform initializers be allowed in GLSL ES 3.00?
Hi, Mesa's ast_to_hir.cpp does a check like: state->check_version(120, 0, &initializer_loc, "cannot initialize uniforms"); i.e. it does not allow uniform initializers on GLSL ES 3.00. Upon my reading of the spec, I can't find any place where that would be disallowed. ES 3.00 seems to be based on GLSL 3.3, with a bunch of stuff removed and added. Uniform initializers aren't listed in the "removed" section (spec 3.00.4, section 1.1.4). So maybe the check should be changed to allow 300 in the ES min version? -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/20] glsl: check _mesa_hash_table_create return value in link_uniform_blocks
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/link_uniform_blocks.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/glsl/link_uniform_blocks.cpp b/src/glsl/link_uniform_blocks.cpp
index 1a0e643..3643734 100644
--- a/src/glsl/link_uniform_blocks.cpp
+++ b/src/glsl/link_uniform_blocks.cpp
@@ -170,6 +170,11 @@ link_uniform_blocks(void *mem_ctx,
struct hash_table *block_hash =
_mesa_hash_table_create(mem_ctx, _mesa_key_string_equal);
+ if (block_hash == NULL) {
+ _mesa_error_no_memory(__func__);
+ return 0;
+ }
+
/* Determine which uniform blocks are active.
*/
link_uniform_block_active_visitor v(mem_ctx, block_hash, prog);
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/20] i965: Avoid null access in intelMakeCurrent()
separate two null checks connected with && to their own if branches.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_context.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 17ae685..e67df6a 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -927,13 +927,17 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
struct gl_context *ctx = &brw->ctx;
struct gl_framebuffer *fb, *readFb;
- if (driDrawPriv == NULL && driReadPriv == NULL) {
+ if (driDrawPriv == NULL) {
fb = _mesa_get_incomplete_framebuffer();
- readFb = _mesa_get_incomplete_framebuffer();
} else {
fb = driDrawPriv->driverPrivate;
- readFb = driReadPriv->driverPrivate;
driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1;
+ }
+
+ if (driReadPriv == NULL) {
+ readFb = _mesa_get_incomplete_framebuffer();
+ } else {
+ readFb = driReadPriv->driverPrivate;
driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/20] glsl: add missing null check in tfeedback_decl::init()
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/link_varyings.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 71998df..7fdf337 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -318,6 +318,11 @@ tfeedback_decl::init(struct gl_context *ctx, const void
*mem_ctx,
const char *base_name_end;
long subscript = parse_program_resource_name(input, &base_name_end);
this->var_name = ralloc_strndup(mem_ctx, input, base_name_end - input);
+ if (this->var_name == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
+
if (subscript >= 0) {
this->array_subscript = subscript;
this->is_subscripted = true;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/20] Klocwork patches
My Klocwork set again rebased and added with few new patches. This set pass piglit quick set on my ivybridge without regressions. i965: Avoid null access in intelMakeCurrent() I was a bit iffy if its the same behavior which I replaced. mesa/drivers: Add extra null check in blitframebuffer_texture() GetDrawableAttribute may send GLXBadDrawable if is not bound to thread's context. Should GLXBadDrawable be sent also if GetGLXDRIDrawable(dpy, drawable) return NULL because it mean drawable is not associated with a direct-rendering context. Now just return 0. /Juha-Pekka Juha-Pekka Heikkila (20): mesa: In emit_texenv() type mismatch was forced with typecast mesa: Add missing null checks into prog_hash_table.c glsl: add missing null check in tfeedback_decl::init() mesa: add missing null check in _mesa_NewHashTable() i965: check malloc return value in intel_resolve_map_set() mesa: add null checks in symbol_table.c glsl: Add null check in loop_analysis.cpp glsl: check _mesa_hash_table_create return value in link_uniform_blocks i965/fs: Check variable_storage return value in fs_visitor::visit glx: Added missing null check in GetDrawableAttribute() mesa/drivers: Add extra null check in blitframebuffer_texture() i965: Avoid null access in intelMakeCurrent() glsl: Add missing null check in push_back() glsl: Check calloc return value in link_intrastage_shaders() mesa/main: Verify calloc return value in register_surface() mesa/main: In register_surface() verify gl_texture_object was found i965: Check calloc return value in gather_statistics_results() i965/gen8_fs: Avoid null access on printing debug info. mesa/main: Add missing null check in _mesa_CreatePerfQueryINTEL() i965: Handle miptree creation failure in intel_alloc_texture_storage() src/glsl/link_atomics.cpp | 13 -- src/glsl/link_uniform_blocks.cpp | 5 src/glsl/link_varyings.cpp | 5 src/glsl/linker.cpp| 6 + src/glsl/loop_analysis.cpp | 6 +++-- src/glx/glx_pbuffer.c | 4 +++ src/mesa/drivers/common/meta_blit.c| 3 +++ src/mesa/drivers/dri/i965/brw_context.c| 10 +--- src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 + .../drivers/dri/i965/brw_performance_monitor.c | 7 - src/mesa/drivers/dri/i965/gen8_fs_generator.cpp| 2 +- src/mesa/drivers/dri/i965/intel_resolve_map.c | 7 + src/mesa/drivers/dri/i965/intel_tex.c | 3 +++ src/mesa/main/ff_fragment_shader.cpp | 17 ++-- src/mesa/main/hash.c | 10 src/mesa/main/performance_monitor.c| 5 src/mesa/main/vdpau.c | 11 src/mesa/program/prog_hash_table.c | 8 ++ src/mesa/program/symbol_table.c| 30 ++ 19 files changed, 141 insertions(+), 17 deletions(-) -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/20] mesa: Add missing null checks into prog_hash_table.c
Check calloc return values in hash_table_insert() and
hash_table_replace()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/program/prog_hash_table.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/program/prog_hash_table.c
b/src/mesa/program/prog_hash_table.c
index f45ed46..2445d84 100644
--- a/src/mesa/program/prog_hash_table.c
+++ b/src/mesa/program/prog_hash_table.c
@@ -142,6 +142,10 @@ hash_table_insert(struct hash_table *ht, void *data, const
void *key)
struct hash_node *node;
node = calloc(1, sizeof(*node));
+if (node == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+}
node->data = data;
node->key = key;
@@ -167,6 +171,10 @@ hash_table_replace(struct hash_table *ht, void *data,
const void *key)
}
hn = calloc(1, sizeof(*hn));
+if (hn == NULL) {
+ _mesa_error_no_memory(__func__);
+ return false;
+}
hn->data = data;
hn->key = key;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/20] i965/fs: Check variable_storage return value in fs_visitor::visit
check variable_storage() found the requested fs_reg.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index d2dc5fa..b396ad2 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -152,6 +152,12 @@ void
fs_visitor::visit(ir_dereference_variable *ir)
{
fs_reg *reg = variable_storage(ir->var);
+
+ if (!reg) {
+ fail("Failed to find variable storage for %s\n", ir->var->name);
+ this->result = fs_reg(reg_null_d);
+ return;
+ }
this->result = *reg;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/20] i965: check malloc return value in intel_resolve_map_set()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/intel_resolve_map.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_resolve_map.c
b/src/mesa/drivers/dri/i965/intel_resolve_map.c
index 04b5c94..c5a4cd7 100644
--- a/src/mesa/drivers/dri/i965/intel_resolve_map.c
+++ b/src/mesa/drivers/dri/i965/intel_resolve_map.c
@@ -22,6 +22,7 @@
*/
#include "intel_resolve_map.h"
+#include "main/imports.h"
#include
#include
@@ -51,6 +52,12 @@ intel_resolve_map_set(struct intel_resolve_map *head,
}
*tail = malloc(sizeof(**tail));
+
+ if (*tail == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
+
(*tail)->prev = prev;
(*tail)->next = NULL;
(*tail)->level = level;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/20] glsl: Add null check in loop_analysis.cpp
Check return value from hash_table_find before using it as a pointer
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/loop_analysis.cpp | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/glsl/loop_analysis.cpp b/src/glsl/loop_analysis.cpp
index d6a9ac7..78ac300 100644
--- a/src/glsl/loop_analysis.cpp
+++ b/src/glsl/loop_analysis.cpp
@@ -589,8 +589,10 @@ get_basic_induction_increment(ir_assignment *ir,
hash_table *var_hash)
loop_variable *lv =
(loop_variable *) hash_table_find(var_hash, inc_var);
-if (!lv->is_loop_constant())
- inc = NULL;
+ if (lv == NULL || !lv->is_loop_constant()) {
+assert(lv != NULL);
+inc = NULL;
+ }
} else
inc = NULL;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/20] mesa: add null checks in symbol_table.c
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/program/symbol_table.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/src/mesa/program/symbol_table.c b/src/mesa/program/symbol_table.c
index 9462978..5b22745 100644
--- a/src/mesa/program/symbol_table.c
+++ b/src/mesa/program/symbol_table.c
@@ -172,6 +172,11 @@ _mesa_symbol_table_push_scope(struct _mesa_symbol_table
*table)
{
struct scope_level *const scope = calloc(1, sizeof(*scope));
+if (scope == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+}
+
scope->next = table->current_scope;
table->current_scope = scope;
table->depth++;
@@ -254,7 +259,17 @@ _mesa_symbol_table_add_symbol(struct _mesa_symbol_table
*table,
if (hdr == NULL) {
hdr = calloc(1, sizeof(*hdr));
+ if (hdr == NULL) {
+ _mesa_error_no_memory(__func__);
+ return -1;
+ }
+
hdr->name = strdup(name);
+ if (hdr->name == NULL) {
+ free(hdr);
+ _mesa_error_no_memory(__func__);
+ return -1;
+ }
hash_table_insert(table->ht, hdr, hdr->name);
hdr->next = table->hdr;
@@ -276,6 +291,11 @@ _mesa_symbol_table_add_symbol(struct _mesa_symbol_table
*table,
return -1;
sym = calloc(1, sizeof(*sym));
+if (sym == NULL) {
+ _mesa_error_no_memory(__func__);
+ return -1;
+}
+
sym->next_with_same_name = hdr->symbols;
sym->next_with_same_scope = table->current_scope->symbols;
sym->hdr = hdr;
@@ -311,6 +331,11 @@ _mesa_symbol_table_add_global_symbol(struct
_mesa_symbol_table *table,
if (hdr == NULL) {
hdr = calloc(1, sizeof(*hdr));
+if (hdr == NULL) {
+ _mesa_error_no_memory(__func__);
+ return -1;
+}
+
hdr->name = strdup(name);
hash_table_insert(table->ht, hdr, hdr->name);
@@ -340,6 +365,11 @@ _mesa_symbol_table_add_global_symbol(struct
_mesa_symbol_table *table,
}
sym = calloc(1, sizeof(*sym));
+if (sym == NULL) {
+ _mesa_error_no_memory(__func__);
+ return -1;
+}
+
sym->next_with_same_scope = top_scope->symbols;
sym->hdr = hdr;
sym->name_space = name_space;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/20] mesa: add missing null check in _mesa_NewHashTable()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/hash.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
index 23018e9..674c29d 100644
--- a/src/mesa/main/hash.c
+++ b/src/mesa/main/hash.c
@@ -115,10 +115,20 @@ _mesa_NewHashTable(void)
if (table) {
table->ht = _mesa_hash_table_create(NULL, uint_key_compare);
+ if (table->ht == NULL) {
+ free(table);
+ _mesa_error_no_memory(__func__);
+ return NULL;
+ }
+
_mesa_hash_table_set_deleted_key(table->ht, uint_key(DELETED_KEY_VALUE));
mtx_init(&table->Mutex, mtx_plain);
mtx_init(&table->WalkMutex, mtx_plain);
}
+ else {
+ _mesa_error_no_memory(__func__);
+ }
+
return table;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/20] mesa/drivers: Add extra null check in blitframebuffer_texture()
If texObj == NULL here it mean there is already GL_INVALID_VALUE
or GL_OUT_OF_MEMORY error set to context.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/common/meta_blit.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index e5a0a9a..c87ebd7 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -425,6 +425,9 @@ blitframebuffer_texture(struct gl_context *ctx,
srcLevel = 0;
target = meta_temp_texture->Target;
texObj = _mesa_lookup_texture(ctx, meta_temp_texture->TexObj);
+ if (texObj == NULL) {
+ return false;
+ }
_mesa_meta_setup_copypix_texture(ctx, meta_temp_texture,
srcX0, srcY0,
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/20] mesa: In emit_texenv() type mismatch was forced with typecast
Type mismatch caused random memory to be copied when casted
memory area was smaller than expected type.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/ff_fragment_shader.cpp | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/ff_fragment_shader.cpp
b/src/mesa/main/ff_fragment_shader.cpp
index 8c36097..2115837 100644
--- a/src/mesa/main/ff_fragment_shader.cpp
+++ b/src/mesa/main/ff_fragment_shader.cpp
@@ -877,14 +877,15 @@ emit_texenv(texenv_fragment_program *p, GLuint unit)
shift = new(p->mem_ctx) ir_constant((float)(1 << rgb_shift));
}
else {
-float const_data[4] = {
- float(1 << rgb_shift),
- float(1 << rgb_shift),
- float(1 << rgb_shift),
- float(1 << alpha_shift)
-};
-shift = new(p->mem_ctx) ir_constant(glsl_type::vec4_type,
-(ir_constant_data *)const_data);
+ ir_constant_data const_data;
+
+ const_data.f[0] = float(1 << rgb_shift);
+ const_data.f[1] = float(1 << rgb_shift);
+ const_data.f[2] = float(1 << rgb_shift);
+ const_data.f[3] = float(1 << alpha_shift);
+
+ shift = new(p->mem_ctx) ir_constant(glsl_type::vec4_type,
+ &const_data);
}
return saturate(mul(deref, shift));
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/20] glsl: Add missing null check in push_back()
Report memory error on realloc failure and don't leak any memory.
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/link_atomics.cpp | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/glsl/link_atomics.cpp b/src/glsl/link_atomics.cpp
index d92cdb1..fbe4e73 100644
--- a/src/glsl/link_atomics.cpp
+++ b/src/glsl/link_atomics.cpp
@@ -54,9 +54,18 @@ namespace {
void push_back(unsigned id, ir_variable *var)
{
- counters = (active_atomic_counter *)
-realloc(counters, sizeof(active_atomic_counter) * (num_counters +
1));
+ active_atomic_counter *new_counters;
+ new_counters = (active_atomic_counter *)
+realloc(counters, sizeof(active_atomic_counter) *
+(num_counters + 1));
+
+ if (new_counters == NULL) {
+_mesa_error_no_memory(__func__);
+return;
+ }
+
+ counters = new_counters;
counters[num_counters].id = id;
counters[num_counters].var = var;
num_counters++;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/20] glx: Added missing null check in GetDrawableAttribute()
For GLX_BACK_BUFFER_AGE_EXT query added extra null check.
Signed-off-by: Juha-Pekka Heikkila
---
src/glx/glx_pbuffer.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 0cd0554..bbfdd65 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -319,6 +319,10 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
pdraw = GetGLXDRIDrawable(dpy, drawable);
if (attribute == GLX_BACK_BUFFER_AGE_EXT) {
+ if (pdraw == NULL) {
+ return 0;
+ }
+
struct glx_screen *psc = pdraw->psc;
struct glx_context *gc = __glXGetCurrentContext();
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 20/20] i965: Handle miptree creation failure in intel_alloc_texture_storage()
Check intel_miptree_create() return value before using it as
a pointer.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/intel_tex.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_tex.c
b/src/mesa/drivers/dri/i965/intel_tex.c
index f18ca45..556b787 100644
--- a/src/mesa/drivers/dri/i965/intel_tex.c
+++ b/src/mesa/drivers/dri/i965/intel_tex.c
@@ -147,6 +147,9 @@ intel_alloc_texture_storage(struct gl_context *ctx,
num_samples,
INTEL_MIPTREE_TILING_ANY);
+ if (intel_texobj->mt == NULL) {
+ return false;
+ }
}
for (face = 0; face < numFaces; face++) {
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/20] glsl: Check calloc return value in link_intrastage_shaders()
Check calloc return value while adding build-in functions.
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/linker.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index a43d230..97bd0ef 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1590,6 +1590,12 @@ link_intrastage_shaders(void *mem_ctx,
*/
gl_shader **linking_shaders = (gl_shader **)
calloc(num_shaders + 1, sizeof(gl_shader *));
+
+ if (linking_shaders == NULL) {
+ _mesa_error_no_memory(__func__);
+ ctx->Driver.DeleteShader(ctx, linked);
+ return NULL;
+ }
memcpy(linking_shaders, shader_list, num_shaders * sizeof(gl_shader *));
linking_shaders[num_shaders] = _mesa_glsl_get_builtin_function_shader();
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 16/20] mesa/main: In register_surface() verify gl_texture_object was found
Verify _mesa_lookup_texture() returned valid pointer before using it.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/vdpau.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/main/vdpau.c b/src/mesa/main/vdpau.c
index f1b3ece..975b812 100644
--- a/src/mesa/main/vdpau.c
+++ b/src/mesa/main/vdpau.c
@@ -145,6 +145,12 @@ register_surface(struct gl_context *ctx, GLboolean
isOutput,
for (i = 0; i < numTextureNames; ++i) {
struct gl_texture_object *tex;
tex = _mesa_lookup_texture(ctx, textureNames[i]);
+ if (tex == NULL) {
+ free(surf);
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "VDPAURegisterSurfaceNV(texture ID not found)");
+ return (GLintptr)NULL;
+ }
_mesa_lock_texture(ctx, tex);
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 17/20] i965: Check calloc return value in gather_statistics_results()
Check calloc return value and report on error, also later skip
results handling if there was no memory to store results to.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_performance_monitor.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
index ff3cb97..da85cce 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
@@ -610,6 +610,10 @@ gather_statistics_results(struct brw_context *brw,
ctx->PerfMonitor.Groups[PIPELINE_STATS_COUNTERS].NumCounters;
monitor->pipeline_stats_results = calloc(num_counters, sizeof(uint64_t));
+ if (monitor->pipeline_stats_results == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
drm_intel_bo_map(monitor->pipeline_stats_bo, false);
uint64_t *start = monitor->pipeline_stats_bo->virtual;
@@ -1321,7 +1325,8 @@ brw_get_perf_monitor_result(struct gl_context *ctx,
if (!monitor->pipeline_stats_results)
gather_statistics_results(brw, monitor);
- for (int i = 0; i < num_counters; i++) {
+ for (int i = 0; i < num_counters
+ && monitor->pipeline_stats_results != NULL; i++) {
if (BITSET_TEST(m->ActiveCounters[PIPELINE_STATS_COUNTERS], i)) {
data[offset++] = PIPELINE_STATS_COUNTERS;
data[offset++] = i;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/20] mesa/main: Verify calloc return value in register_surface()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/vdpau.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/main/vdpau.c b/src/mesa/main/vdpau.c
index d974593..f1b3ece 100644
--- a/src/mesa/main/vdpau.c
+++ b/src/mesa/main/vdpau.c
@@ -132,6 +132,11 @@ register_surface(struct gl_context *ctx, GLboolean
isOutput,
}
surf = CALLOC_STRUCT( vdp_surface );
+ if (surf == NULL) {
+ _mesa_error_no_memory("VDPAURegisterSurfaceNV");
+ return (GLintptr)NULL;
+ }
+
surf->vdpSurface = vdpSurface;
surf->target = target;
surf->access = GL_READ_WRITE;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 18/20] i965/gen8_fs: Avoid null access on printing debug info.
There probably either was wrong name for comparison or ! missing.
In vec4_generator::generate_code() there was similar code thus
I decided it was wrong name.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
index de06a97..9c5d64e 100644
--- a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
@@ -886,7 +886,7 @@ gen8_fs_generator::generate_code(exec_list *instructions)
const void *last_annotation_ir = NULL;
if (unlikely(INTEL_DEBUG & DEBUG_WM)) {
- if (prog) {
+ if (shader_prog) {
fprintf(stderr,
"Native code for %s fragment shader %d (SIMD%d dispatch):\n",
shader_prog->Label ? shader_prog->Label : "unnamed",
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 19/20] mesa/main: Add missing null check in _mesa_CreatePerfQueryINTEL()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/performance_monitor.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/main/performance_monitor.c
b/src/mesa/main/performance_monitor.c
index 21b9423..9d1a6b4 100644
--- a/src/mesa/main/performance_monitor.c
+++ b/src/mesa/main/performance_monitor.c
@@ -1036,6 +1036,11 @@ _mesa_CreatePerfQueryINTEL(GLuint queryId, GLuint
*queryHandle)
}
m = new_performance_monitor(ctx, first);
+ if (m == NULL) {
+ _mesa_error_no_memory(__func__);
+ return;
+ }
+
_mesa_HashInsert(ctx->PerfMonitor.Monitors, first, m);
*queryHandle = first;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glsl: should uniform initializers be allowed in GLSL ES 3.00?
On Wed, May 14, 2014 at 10:00 AM, Aras Pranckevicius wrote: > Hi, > > Mesa's ast_to_hir.cpp does a check like: > > state->check_version(120, 0, &initializer_loc, >"cannot initialize uniforms"); > > i.e. it does not allow uniform initializers on GLSL ES 3.00. > > Upon my reading of the spec, I can't find any place where that would be > disallowed. ES 3.00 seems to be based on GLSL 3.3, with a bunch of stuff > removed and added. Uniform initializers aren't listed in the "removed" > section (spec 3.00.4, section 1.1.4). So maybe the check should be changed > to allow 300 in the ES min version? The GLSL 3.30 spec says > All uniform variables are read-only and are initialized externally either at > link time or through the API. The link time initial value is either the value > of the variable's initializer, if present, or 0 if no initializer is present. > Sampler types cannot have initializers. While the GLSL ES 3.00 (.4) spec says (The GLSL ES 3.1 spec contains this wording too) > All uniform variables are read-only. They are initialized to 0 at link time > and may be updated through the API. So I think we're correct in disallowing it. Chalk it up to another trivial divergence of ES in unexpected way. Ian, does it seem like we can make a really trivial extension that gives you back the wording in the Desktop GLSL spec? Are there other interactions we need to think about? There's already wording explicitly disallowing initializing samplers in a shader. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Broadcom VideoCore IV
Le 14 mai 2014 21:02, "Mohamed MEDIOUNI" a écrit : > > Le 29 avr. 2014 02:52, "Rob Clark" a écrit : > > > > On Sun, Apr 27, 2014 at 5:51 AM, Mohamed MEDIOUNI > > wrote: > > > > > > Le 21 avr. 2014 13:16, "Rob Clark" a écrit : > > >> > > >> On Sat, Apr 19, 2014 at 9:32 AM, Mohamed MEDIOUNI > > >> wrote: > > >> > The VideoCore IV GPU has 14 cores: > > >> > > > >> > - 2 VPU Cores : Full-blown cores which run the ThreadX RTOS. > > >> > There is an experimental LLVM port to it and also the VBCC C89 > > >> > compiler(which has'nt time support so classic benchmarks run > > >> > indefinitely). > > >> > The binary blob run on that. > > >> > 5 GFlops > > >> > > > >> > - 12 QPU Cores : 3D cores officially documented by Broadcom and > using a > > >> > tile-mode rendering architecture. > > >> > The full Android driver for that was open-sourced at the end of > > >> > February. > > >> > > > >> > 24Gflops > > >> > > > >> > Questions: > > >> > > > >> > Can Gallium3D run with tile-mode rendering architecture ? > > >> > > >> yes, adreno (freedreno) is a tiler > > >> > > >> > Is it better using Mesa and the Broadcom shader compiler ? > > >> > > >> Allegedly it may be easier to shoehorn in the blob compiler with a > > >> mesa/dri driver vs mesa/gallium driver. That probably shouldn't be > > >> too much of a concern in the long run. Overall I think a gallium > > >> driver would be much easier to implement... gallium plus helpers > > >> provide a lot to the driver writer. > > >> > > >> > Is it better using the VPU and an adapted LLVMpipe ? > > >> > > >> I guess you are talking about keeping the driver-on-videocore > > >> approach? That may have some advantages when it comes to handling > > >> security (lack of mmu) on r-pi. But other than that, I suspect > > >> everything else will be easier to develop/debug on the arm side. And > > >> I suspect avoiding round trips to the coprocessor will help > > >> performance in a lot of cases. > > >> > > >> so if you can figure out a way to deal with security aspect with arm > > >> side driver, then I'd go for arm side gallium driver as my first > > >> choice. > > >> > > > Have now some problems including : > > > > > > Need to run the programs as root or chmod 777 /dev/mem and chmod 777 > > > /dev/vc-mem > > > > > > > yeah, that is a pretty good sign that you are doing something wrong. > > Normally you need some kernel driver that is mediating access to the > > hardware. In fact no modern hardware is directly accessing hw > > ioregion from userspace. Normally userspace is constructing cmdstream > > buffers passed down to kernel mode driver component which is what is > > dealing with the actual hw > > > > BR, > > -R > I need that because of the MMU. Will experiment with uCLinux the next few > days. > But I will need to finish the VideoCore LLVM backend before that. > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa/st: fix number of ubos being declared in a shader
From: Roland Scheidegger
Previously the code used the total number of ubos being declared in the
linked program (so the ubos of all shaders combined), use the number
from the particular shader instead.
This fixes an assertion failure with piglit arb_uniform_buffer_object-maxblocks
seen in llvmpipe since 8a9f5ecdb116d0449d63f7b94efbfa8b205d826f as it now emits
code for each declared buffer, not just the ones actually used.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index f3535c5..79d013d 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -325,6 +325,7 @@ public:
struct gl_context *ctx;
struct gl_program *prog;
struct gl_shader_program *shader_program;
+ struct gl_shader *shader;
struct gl_shader_compiler_options *options;
int next_temp;
@@ -5096,11 +5097,11 @@ st_translate_program(
}
}
- if (program->shader_program) {
- unsigned num_ubos = program->shader_program->NumUniformBlocks;
+ if (program->shader) {
+ unsigned num_ubos = program->shader->NumUniformBlocks;
for (i = 0; i < num_ubos; i++) {
- ureg_DECL_constant2D(t->ureg, 0,
program->shader_program->UniformBlocks[i].UniformBufferSize / 4, i + 1);
+ ureg_DECL_constant2D(t->ureg, 0,
program->shader->UniformBlocks[i].UniformBufferSize / 4, i + 1);
}
}
@@ -5221,6 +5222,7 @@ get_mesa_program(struct gl_context *ctx,
v->ctx = ctx;
v->prog = prog;
v->shader_program = shader_program;
+ v->shader = shader;
v->options = options;
v->glsl_version = ctx->Const.GLSLVersion;
v->native_integers = ctx->Const.NativeIntegers;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glsl: should uniform initializers be allowed in GLSL ES 3.00?
On 05/14/2014 11:52 AM, Matt Turner wrote: > On Wed, May 14, 2014 at 10:00 AM, Aras Pranckevicius wrote: >> Hi, >> >> Mesa's ast_to_hir.cpp does a check like: >> >> state->check_version(120, 0, &initializer_loc, >>"cannot initialize uniforms"); >> >> i.e. it does not allow uniform initializers on GLSL ES 3.00. >> >> Upon my reading of the spec, I can't find any place where that would be >> disallowed. ES 3.00 seems to be based on GLSL 3.3, with a bunch of stuff >> removed and added. Uniform initializers aren't listed in the "removed" >> section (spec 3.00.4, section 1.1.4). So maybe the check should be changed >> to allow 300 in the ES min version? > > The GLSL 3.30 spec says > >> All uniform variables are read-only and are initialized externally either at >> link time or through the API. The link time initial value is either the >> value of the variable's initializer, if present, or 0 if no initializer is >> present. Sampler types cannot have initializers. > > While the GLSL ES 3.00 (.4) spec says (The GLSL ES 3.1 spec contains > this wording too) > >> All uniform variables are read-only. They are initialized to 0 at link time >> and may be updated through the API. > > So I think we're correct in disallowing it. > > Chalk it up to another trivial divergence of ES in unexpected way. > > Ian, does it seem like we can make a really trivial extension that > gives you back the wording in the Desktop GLSL spec? Are there other > interactions we need to think about? There's already wording > explicitly disallowing initializing samplers in a shader. I don't see any reason that we couldn't. It would probably take longer to spec it than to implement it. :) It's /probably/ more than just adding that one sentence. Applications would still need to enable that extension in the shader... and the work-arounds for drivers that don't support it would be ugly. I think I'd want to have at least one other vendor agree to implement the extension before it would be worth the effort for anyone involved (us or ISV). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] targets/xa: limit the amount of exported symbols
Hi, I'm on vacation, so I have no way of testing this until next week.
/Thomas
On 05/14/2014 02:04 PM, Emil Velikov wrote:
> ping for the series
>
> If there is no objections I would like to push these over the weekend.
>
> Cheers,
> Emil
> On 09/05/14 18:10, Emil Velikov wrote:
>> ping
>>
>> Thomas, Rob,
>> Can you please take a look if the patch makes sense ? I have double checked
>> that only the required functions are exported although I may have missed
>> something. IMHO you both know XA API a lot better than me :)
>>
>> Thanks
>> Emil
>>
>> On 02/05/14 22:02, Emil Velikov wrote:
>>> In the presence of LLVM the final library exports every symbol from
>>> the llvm namespace. Resolve this by using a version script (w/o the
>>> version/name tag).
>>>
>>> Considering that there are only ~35 symbols, explicitly list them
>>> to minimize the chances of rogue symbols sneaking in.
>>>
>>> Signed-off-by: Emil Velikov
>>> ---
>>> src/gallium/targets/xa/Makefile.am | 1 +
>>> src/gallium/targets/xa/xa.sym | 38
>>> ++
>>> 2 files changed, 39 insertions(+)
>>> create mode 100644 src/gallium/targets/xa/xa.sym
>>>
>>> diff --git a/src/gallium/targets/xa/Makefile.am
>>> b/src/gallium/targets/xa/Makefile.am
>>> index 2619e57..17cd6c4 100644
>>> --- a/src/gallium/targets/xa/Makefile.am
>>> +++ b/src/gallium/targets/xa/Makefile.am
>>> @@ -63,6 +63,7 @@ endif
>>> libxatracker_la_LDFLAGS = \
>>> -no-undefined \
>>> -version-number $(XA_MAJOR):$(XA_MINOR):$(XA_TINY) \
>>> + -Wl,--version-script=$(top_srcdir)/src/gallium/targets/xa/xa.sym \
>>> $(GC_SECTIONS) \
>>> $(LD_NO_UNDEFINED)
>>>
>>> diff --git a/src/gallium/targets/xa/xa.sym b/src/gallium/targets/xa/xa.sym
>>> new file mode 100644
>>> index 000..9c7f422
>>> --- /dev/null
>>> +++ b/src/gallium/targets/xa/xa.sym
>>> @@ -0,0 +1,38 @@
>>> +{
>>> + global:
>>> + xa_composite_allocation;
>>> + xa_composite_check_accelerated;
>>> + xa_composite_done;
>>> + xa_composite_prepare;
>>> + xa_composite_rect;
>>> + xa_context_create;
>>> + xa_context_default;
>>> + xa_context_destroy;
>>> + xa_context_flush;
>>> + xa_copy;
>>> + xa_copy_done;
>>> + xa_copy_prepare;
>>> + xa_fence_get;
>>> + xa_fence_wait;
>>> + xa_fence_destroy;
>>> + xa_format_check_supported;
>>> + xa_solid;
>>> + xa_solid_done;
>>> + xa_solid_prepare;
>>> + xa_surface_create;
>>> + xa_surface_dma;
>>> + xa_surface_format;
>>> + xa_surface_from_handle;
>>> + xa_surface_handle;
>>> + xa_surface_map;
>>> + xa_surface_redefine;
>>> + xa_surface_ref;
>>> + xa_surface_unmap;
>>> + xa_surface_unref;
>>> + xa_tracker_create;
>>> + xa_tracker_destroy;
>>> + xa_tracker_version;
>>> + xa_yuv_planar_blit;
>>> + local:
>>> + *;
>>> +};
>>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/20] mesa: In emit_texenv() type mismatch was forced with typecast
On 05/14/2014 10:55 AM, Juha-Pekka Heikkila wrote:
> Type mismatch caused random memory to be copied when casted
> memory area was smaller than expected type.
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/main/ff_fragment_shader.cpp | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/main/ff_fragment_shader.cpp
> b/src/mesa/main/ff_fragment_shader.cpp
> index 8c36097..2115837 100644
> --- a/src/mesa/main/ff_fragment_shader.cpp
> +++ b/src/mesa/main/ff_fragment_shader.cpp
> @@ -877,14 +877,15 @@ emit_texenv(texenv_fragment_program *p, GLuint unit)
>shift = new(p->mem_ctx) ir_constant((float)(1 << rgb_shift));
>}
>else {
> - float const_data[4] = {
> - float(1 << rgb_shift),
> - float(1 << rgb_shift),
> - float(1 << rgb_shift),
> - float(1 << alpha_shift)
> - };
> - shift = new(p->mem_ctx) ir_constant(glsl_type::vec4_type,
> - (ir_constant_data *)const_data);
> + ir_constant_data const_data;
> +
> + const_data.f[0] = float(1 << rgb_shift);
> + const_data.f[1] = float(1 << rgb_shift);
> + const_data.f[2] = float(1 << rgb_shift);
> + const_data.f[3] = float(1 << alpha_shift);
> +
> + shift = new(p->mem_ctx) ir_constant(glsl_type::vec4_type,
> + &const_data);
After this change, does Valgrind complain about (later) reads of
uninitialized memory? I think we might want to toss an extra memset in
there just to make Valgrind quiet too. If Valgrind is already quiet,
this patch is
Reviewed-by: Ian Romanick
as-is.
>}
>
>return saturate(mul(deref, shift));
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/20] mesa: Add missing null checks into prog_hash_table.c
Reviewed-by: Ian Romanick
On 05/14/2014 10:55 AM, Juha-Pekka Heikkila wrote:
> Check calloc return values in hash_table_insert() and
> hash_table_replace()
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/program/prog_hash_table.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/mesa/program/prog_hash_table.c
> b/src/mesa/program/prog_hash_table.c
> index f45ed46..2445d84 100644
> --- a/src/mesa/program/prog_hash_table.c
> +++ b/src/mesa/program/prog_hash_table.c
> @@ -142,6 +142,10 @@ hash_table_insert(struct hash_table *ht, void *data,
> const void *key)
> struct hash_node *node;
>
> node = calloc(1, sizeof(*node));
> +if (node == NULL) {
> + _mesa_error_no_memory(__func__);
> + return;
> +}
>
> node->data = data;
> node->key = key;
> @@ -167,6 +171,10 @@ hash_table_replace(struct hash_table *ht, void *data,
> const void *key)
> }
>
> hn = calloc(1, sizeof(*hn));
> +if (hn == NULL) {
> + _mesa_error_no_memory(__func__);
> + return false;
> +}
>
> hn->data = data;
> hn->key = key;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: fix number of ubos being declared in a shader
On 05/14/2014 01:07 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
Previously the code used the total number of ubos being declared in the
linked program (so the ubos of all shaders combined), use the number
from the particular shader instead.
This fixes an assertion failure with piglit arb_uniform_buffer_object-maxblocks
seen in llvmpipe since 8a9f5ecdb116d0449d63f7b94efbfa8b205d826f as it now emits
code for each declared buffer, not just the ones actually used.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index f3535c5..79d013d 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -325,6 +325,7 @@ public:
struct gl_context *ctx;
struct gl_program *prog;
struct gl_shader_program *shader_program;
+ struct gl_shader *shader;
struct gl_shader_compiler_options *options;
int next_temp;
@@ -5096,11 +5097,11 @@ st_translate_program(
}
}
- if (program->shader_program) {
- unsigned num_ubos = program->shader_program->NumUniformBlocks;
+ if (program->shader) {
+ unsigned num_ubos = program->shader->NumUniformBlocks;
for (i = 0; i < num_ubos; i++) {
- ureg_DECL_constant2D(t->ureg, 0,
program->shader_program->UniformBlocks[i].UniformBufferSize / 4, i + 1);
+ ureg_DECL_constant2D(t->ureg, 0,
program->shader->UniformBlocks[i].UniformBufferSize / 4, i + 1);
}
}
@@ -5221,6 +5222,7 @@ get_mesa_program(struct gl_context *ctx,
v->ctx = ctx;
v->prog = prog;
v->shader_program = shader_program;
+ v->shader = shader;
v->options = options;
v->glsl_version = ctx->Const.GLSLVersion;
v->native_integers = ctx->Const.NativeIntegers;
LGTM.
Reviewed-by: Brian Paul
Should this fix go into the 10.2 or 10.1 branches?
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/20] glsl: add missing null check in tfeedback_decl::init()
On 05/14/2014 10:55 AM, Juha-Pekka Heikkila wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/glsl/link_varyings.cpp | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
> index 71998df..7fdf337 100644
> --- a/src/glsl/link_varyings.cpp
> +++ b/src/glsl/link_varyings.cpp
> @@ -318,6 +318,11 @@ tfeedback_decl::init(struct gl_context *ctx, const void
> *mem_ctx,
> const char *base_name_end;
> long subscript = parse_program_resource_name(input, &base_name_end);
> this->var_name = ralloc_strndup(mem_ctx, input, base_name_end - input);
> + if (this->var_name == NULL) {
> + _mesa_error_no_memory(__func__);
> + return;
> + }
> +
This doesn't make anything better. For giggles, I replaced this with
if ((rand() & 0x07) == 0) {
ralloc_free((void *)this->var_name);
this->var_name = NULL;
_mesa_error_no_memory(__func__);
return;
}
Randomly, pretend that the allocation failed. Then I ran piglit
transform feedback tests:
./piglit-run.py -p glx -t feed -t xfb tests/all.py results
And got a GIANT pile of crashes.
[370/370] crash: 68, fail: 1, pass: 264, skip: 36, warn: 1
One of the crashes is:
[idr@mumford-wire piglit]$ gdb --args bin/ext_transform_feedback-output-type
gl_NextBuffer-2 -fbo -auto
GNU gdb (GDB) Fedora 7.5.1-42.fc18
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
Re: [Mesa-dev] [PATCH 04/20] mesa: add missing null check in _mesa_NewHashTable()
Reviewed-by: Ian Romanick
On 05/14/2014 10:55 AM, Juha-Pekka Heikkila wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/main/hash.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
> index 23018e9..674c29d 100644
> --- a/src/mesa/main/hash.c
> +++ b/src/mesa/main/hash.c
> @@ -115,10 +115,20 @@ _mesa_NewHashTable(void)
>
> if (table) {
>table->ht = _mesa_hash_table_create(NULL, uint_key_compare);
> + if (table->ht == NULL) {
> + free(table);
> + _mesa_error_no_memory(__func__);
> + return NULL;
> + }
> +
>_mesa_hash_table_set_deleted_key(table->ht,
> uint_key(DELETED_KEY_VALUE));
>mtx_init(&table->Mutex, mtx_plain);
>mtx_init(&table->WalkMutex, mtx_plain);
> }
> + else {
> + _mesa_error_no_memory(__func__);
> + }
> +
> return table;
> }
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] A candidate branch for the next stable release
Chia-I Wu writes: > I'd like to nominate this commit on master for 10.1.4 > > commit 9245206cbfaaa4e18c1f3715eebb5f281070d772 > Author: Eric Anholt > Date: Fri Feb 14 16:06:31 2014 -0800 > > i965/vs: Use samplers for UBOs in the VS like we do for non-UBO > pulls. Great. I've cherry-picked this over to my 10.1 branch now. If it doesn't cause any problems in testing, it should be included in the next 10.1 release, (which should be 10.1.5 to be released on May 16 or so). > Should I generate a patch and send it to mesa-stable to get it > reviewed and included? With a patch that's on master, all I need is the commit ID. So your email above all that was needed. Next time, just send an email like that to mesa-sta...@lists.freedesktop.org and that's all you'll need to do. -Carl -- carl.d.wo...@intel.com pgpN2FG3DJd9u.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/20] i965: check malloc return value in intel_resolve_map_set()
I'm nervous this has the same problem as patch 3. Can you try some tests?
On 05/14/2014 10:55 AM, Juha-Pekka Heikkila wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/drivers/dri/i965/intel_resolve_map.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_resolve_map.c
> b/src/mesa/drivers/dri/i965/intel_resolve_map.c
> index 04b5c94..c5a4cd7 100644
> --- a/src/mesa/drivers/dri/i965/intel_resolve_map.c
> +++ b/src/mesa/drivers/dri/i965/intel_resolve_map.c
> @@ -22,6 +22,7 @@
> */
>
> #include "intel_resolve_map.h"
> +#include "main/imports.h"
>
> #include
> #include
> @@ -51,6 +52,12 @@ intel_resolve_map_set(struct intel_resolve_map *head,
> }
>
> *tail = malloc(sizeof(**tail));
> +
> + if (*tail == NULL) {
> + _mesa_error_no_memory(__func__);
> + return;
> + }
> +
> (*tail)->prev = prev;
> (*tail)->next = NULL;
> (*tail)->level = level;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/20] mesa: add null checks in symbol_table.c
On 05/14/2014 10:55 AM, Juha-Pekka Heikkila wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/program/symbol_table.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/src/mesa/program/symbol_table.c b/src/mesa/program/symbol_table.c
> index 9462978..5b22745 100644
> --- a/src/mesa/program/symbol_table.c
> +++ b/src/mesa/program/symbol_table.c
> @@ -172,6 +172,11 @@ _mesa_symbol_table_push_scope(struct _mesa_symbol_table
> *table)
> {
> struct scope_level *const scope = calloc(1, sizeof(*scope));
>
> +if (scope == NULL) {
> + _mesa_error_no_memory(__func__);
> + return;
> +}
> +
I think this function needs to return an error value, and the callers
need to notice that error. Otherwise the following
_mesa_symbol_table_pop_scope will really screw things up... perhaps
leading eventually to popping an empty stack.
> scope->next = table->current_scope;
> table->current_scope = scope;
> table->depth++;
> @@ -254,7 +259,17 @@ _mesa_symbol_table_add_symbol(struct _mesa_symbol_table
> *table,
>
> if (hdr == NULL) {
> hdr = calloc(1, sizeof(*hdr));
> + if (hdr == NULL) {
> + _mesa_error_no_memory(__func__);
> + return -1;
> + }
> +
> hdr->name = strdup(name);
> + if (hdr->name == NULL) {
> + free(hdr);
> + _mesa_error_no_memory(__func__);
> + return -1;
> + }
>
> hash_table_insert(table->ht, hdr, hdr->name);
> hdr->next = table->hdr;
> @@ -276,6 +291,11 @@ _mesa_symbol_table_add_symbol(struct _mesa_symbol_table
> *table,
> return -1;
>
> sym = calloc(1, sizeof(*sym));
> +if (sym == NULL) {
> + _mesa_error_no_memory(__func__);
> + return -1;
> +}
> +
> sym->next_with_same_name = hdr->symbols;
> sym->next_with_same_scope = table->current_scope->symbols;
> sym->hdr = hdr;
> @@ -311,6 +331,11 @@ _mesa_symbol_table_add_global_symbol(struct
> _mesa_symbol_table *table,
>
> if (hdr == NULL) {
> hdr = calloc(1, sizeof(*hdr));
> +if (hdr == NULL) {
> + _mesa_error_no_memory(__func__);
> + return -1;
> +}
> +
> hdr->name = strdup(name);
Check this one too? Are there other strdups that were missed? It seems
like all of the "add a symbol" functions should have a strdup somewhere...
>
> hash_table_insert(table->ht, hdr, hdr->name);
> @@ -340,6 +365,11 @@ _mesa_symbol_table_add_global_symbol(struct
> _mesa_symbol_table *table,
> }
>
> sym = calloc(1, sizeof(*sym));
> +if (sym == NULL) {
> + _mesa_error_no_memory(__func__);
> + return -1;
> +}
> +
> sym->next_with_same_scope = top_scope->symbols;
> sym->hdr = hdr;
> sym->name_space = name_space;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/20] glsl: Add null check in loop_analysis.cpp
Reviewed-by: Ian Romanick
On 05/14/2014 10:55 AM, Juha-Pekka Heikkila wrote:
> Check return value from hash_table_find before using it as a pointer
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/glsl/loop_analysis.cpp | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/glsl/loop_analysis.cpp b/src/glsl/loop_analysis.cpp
> index d6a9ac7..78ac300 100644
> --- a/src/glsl/loop_analysis.cpp
> +++ b/src/glsl/loop_analysis.cpp
> @@ -589,8 +589,10 @@ get_basic_induction_increment(ir_assignment *ir,
> hash_table *var_hash)
>loop_variable *lv =
> (loop_variable *) hash_table_find(var_hash, inc_var);
>
> - if (!lv->is_loop_constant())
> - inc = NULL;
> + if (lv == NULL || !lv->is_loop_constant()) {
> +assert(lv != NULL);
> +inc = NULL;
> + }
>} else
>inc = NULL;
> }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/20] glsl: check _mesa_hash_table_create return value in link_uniform_blocks
On 05/14/2014 10:55 AM, Juha-Pekka Heikkila wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/glsl/link_uniform_blocks.cpp | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/glsl/link_uniform_blocks.cpp
> b/src/glsl/link_uniform_blocks.cpp
> index 1a0e643..3643734 100644
> --- a/src/glsl/link_uniform_blocks.cpp
> +++ b/src/glsl/link_uniform_blocks.cpp
> @@ -170,6 +170,11 @@ link_uniform_blocks(void *mem_ctx,
> struct hash_table *block_hash =
>_mesa_hash_table_create(mem_ctx, _mesa_key_string_equal);
>
> + if (block_hash == NULL) {
> + _mesa_error_no_memory(__func__);
> + return 0;
> + }
> +
This should also call linker_error, and the caller
(link_intrastage_shaders) should follow the call to link_uniform_blocks with
if (!prog->LinkStatus)
return NULL;
> /* Determine which uniform blocks are active.
> */
> link_uniform_block_active_visitor v(mem_ctx, block_hash, prog);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: fix number of ubos being declared in a shader
Am 14.05.2014 21:45, schrieb Brian Paul:
> On 05/14/2014 01:07 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> Previously the code used the total number of ubos being declared in the
>> linked program (so the ubos of all shaders combined), use the number
>> from the particular shader instead.
>> This fixes an assertion failure with piglit
>> arb_uniform_buffer_object-maxblocks
>> seen in llvmpipe since 8a9f5ecdb116d0449d63f7b94efbfa8b205d826f as it
>> now emits
>> code for each declared buffer, not just the ones actually used.
>> ---
>> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>> index f3535c5..79d013d 100644
>> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>> @@ -325,6 +325,7 @@ public:
>> struct gl_context *ctx;
>> struct gl_program *prog;
>> struct gl_shader_program *shader_program;
>> + struct gl_shader *shader;
>> struct gl_shader_compiler_options *options;
>>
>> int next_temp;
>> @@ -5096,11 +5097,11 @@ st_translate_program(
>> }
>> }
>>
>> - if (program->shader_program) {
>> - unsigned num_ubos = program->shader_program->NumUniformBlocks;
>> + if (program->shader) {
>> + unsigned num_ubos = program->shader->NumUniformBlocks;
>>
>> for (i = 0; i < num_ubos; i++) {
>> - ureg_DECL_constant2D(t->ureg, 0,
>> program->shader_program->UniformBlocks[i].UniformBufferSize / 4, i + 1);
>> + ureg_DECL_constant2D(t->ureg, 0,
>> program->shader->UniformBlocks[i].UniformBufferSize / 4, i + 1);
>> }
>> }
>>
>> @@ -5221,6 +5222,7 @@ get_mesa_program(struct gl_context *ctx,
>> v->ctx = ctx;
>> v->prog = prog;
>> v->shader_program = shader_program;
>> + v->shader = shader;
>> v->options = options;
>> v->glsl_version = ctx->Const.GLSLVersion;
>> v->native_integers = ctx->Const.NativeIntegers;
>>
>
> LGTM.
> Reviewed-by: Brian Paul
>
> Should this fix go into the 10.2 or 10.1 branches?
>
Oh I didn't think about that. The bug is old and didn't seem to have
caused issues so far (actually the declared sizes of the buffers would
have been wrong too but probably everyone ignored that too). I guess
though it should be safe for 10.1 and 10.2, so I'll add that.
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/20] glx: Added missing null check in GetDrawableAttribute()
On 05/14/2014 10:55 AM, Juha-Pekka Heikkila wrote:
> For GLX_BACK_BUFFER_AGE_EXT query added extra null check.
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/glx/glx_pbuffer.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
> index 0cd0554..bbfdd65 100644
> --- a/src/glx/glx_pbuffer.c
> +++ b/src/glx/glx_pbuffer.c
> @@ -319,6 +319,10 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
> pdraw = GetGLXDRIDrawable(dpy, drawable);
>
> if (attribute == GLX_BACK_BUFFER_AGE_EXT) {
> + if (pdraw == NULL) {
> + return 0;
> + }
> +
This code will need more restructuring. If pdraw is NULL, this function
should generate GLXBadDrawable (see a few lines lower in the function
than is shown in the patch). Maybe just move the assignment of psc
lower in the function, and add a '|| pdraw == NULL' to the if-statement
below?
>struct glx_screen *psc = pdraw->psc;
>struct glx_context *gc = __glXGetCurrentContext();
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/20] mesa/drivers: Add extra null check in blitframebuffer_texture()
Reviewed-by: Ian Romanick
On 05/14/2014 10:55 AM, Juha-Pekka Heikkila wrote:
> If texObj == NULL here it mean there is already GL_INVALID_VALUE
> or GL_OUT_OF_MEMORY error set to context.
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/drivers/common/meta_blit.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/drivers/common/meta_blit.c
> b/src/mesa/drivers/common/meta_blit.c
> index e5a0a9a..c87ebd7 100644
> --- a/src/mesa/drivers/common/meta_blit.c
> +++ b/src/mesa/drivers/common/meta_blit.c
> @@ -425,6 +425,9 @@ blitframebuffer_texture(struct gl_context *ctx,
>srcLevel = 0;
>target = meta_temp_texture->Target;
>texObj = _mesa_lookup_texture(ctx, meta_temp_texture->TexObj);
> + if (texObj == NULL) {
> + return false;
> + }
>
>_mesa_meta_setup_copypix_texture(ctx, meta_temp_texture,
> srcX0, srcY0,
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77288] [swrast] piglit glean glsl1 regression
https://bugs.freedesktop.org/show_bug.cgi?id=77288
--- Comment #3 from Eric Anholt ---
The alternative I think would be to make "if (ir->write_mask == 0) {" (which is
presumably the case that was being hit before) also explicitly accept
matrices/structures.
--
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 78700] Debug warnings should be generated when BindAttribLocation isn't followed by a re-link
https://bugs.freedesktop.org/show_bug.cgi?id=78700 Kenneth Graunke changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|mesa-dev@lists.freedesktop. |kenn...@whitecape.org |org | --- Comment #1 from Kenneth Graunke --- I actually implemented most of the infrastructure for this while tracking down whether a game actually needed to re-link so much, so I went ahead and implemented this. Patches incoming assuming they survive Piglit. -- 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] Mesa 10.2 release candidate 2
On 05/09/2014 08:28 PM, Ian Romanick wrote: > (This is a re-send with a GPG signature.) > > Mesa 10.2 release candidate 2 is now available for testing. The current > plan of record is to have an additional release candidate each Friday > until the 10.2 release on Friday, May 30th (correcte from the RC1 > announcement e-mail). > > Note: there is a possible front-buffer rendering regression in the > branch on some Intel hardware configurations. If you're worried about > this case, you may want to wait for RC3. I chose to not revert the > patches because I would have needed to revert quite a few (due to a > dependency chain), and the patches fix an assertion failure. For more > information, see: > > https://bugs.freedesktop.org/show_bug.cgi?id=78515 > > The tag in the GIT repository for Mesa 10.2-rc2 is 'mesa-10.2-rc2'. Folks have reported to me on IRC that I completely screwed this up somehow. There is a mesa-10.2-rc2 tag, but it is *NOT* a commit on the 10.2 branch. There was some last minute removal of patches from the branch, so I may have forgotten to re-tag after removing the last bad patch. The actual commit in the repo for 10.2-rc2 is 0b3126b. The question now is... what should I do about the tag? Retag and force push it? Make a new mesa-10.2-rc2-for-realz tag? Something else? > Mesa 10.2 release candidate 2 is available for download at > ftp://freedesktop.org/pub/mesa/10.2/ > > md5sums: > > f0f962321522c9fe599a2b69cc229b67 MesaLib-10.2.0-rc2.tar.gz > 9976683cf51b330d3b06301e52bbc3d6 MesaLib-10.2.0-rc2.tar.bz2 > 910c14cd75cac00b26b11c35d1034d06 MesaLib-10.2.0-rc2.zip > > I have verified building from the .tar.bz2 file by doing the following > on my aging Fedora 18 system: > > tar -xjf Mesa-10.2.0-rc2.tar.bz2 > cd Mesa-10.2.0-rc2 > ./configure --enable-gallium-llvm > make -j6 && make check > make install > > Changes since mesa-10.2-rc1: > > Emil Velikov (2): > configure: error out if building GBM without dri > glx/tests: Partially revert commit > 51e3569573a7b3f8da0df093836761003fcdc414 > > Ian Romanick (2): > linker: Fix consumer_inputs_with_locations indexing > mesa: Bump version to 10.2-rc2 > > Ilia Mirkin (1): > nv50/ir/gk110: fix set with f32 dest > > Kenneth Graunke (9): > i965: Set miptree target field when creating from a BO. > i965: Always intel_prepare_render() after invalidating front buffers. > meta: Unify the GLSL and fixed-function clear paths. > meta: Add a new MESA_META_DRAW_BUFFERS bit. > meta: Add infrastructure for saving/restoring the DrawBuffers state. > meta: Only clear the requested color buffers. > i965: Enable GL_ARB_texture_view on Broadwell. > mesa: Fix MaxNumLayers for 1D array textures. > i965: Fix GPU hangs on Broadwell in shaders with some control flow. > > Roland Scheidegger (1): > draw: do not use draw_get_option_use_llvm() inside draw execution paths > > Tapani Pälli (1): > glsl: fix bogus layout qualifier warnings > > Thomas Hellstrom (1): > st/xa: Fix performance regression introduced by commit "Cache render > target surface" > > Tom Stellard (4): > pipe-loader: Don't destroy the winsys in the sw loader > clover: Destory pipe_screen when device does not support compute v2 > configure.ac: Add LLVM_VERSION_PATCH to DEFINES > radeonsi: Enable geometry shaders with LLVM 3.4.1 > > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Remove blorp unit tests.
They've served their purpose (in transitioning blorp to using fs_generator) and now they just necessitate large amounts of manual labor to regenerate if the disassembler changes. Cc: Topi Pohjolainen --- Deleted file diff removed. src/mesa/drivers/dri/i965/.gitignore |1 - src/mesa/drivers/dri/i965/Makefile.am |7 +- .../drivers/dri/i965/test_blorp_blit_eu_gen.cpp| 1092 3 files changed, 1 insertion(+), 1099 deletions(-) delete mode 100644 src/mesa/drivers/dri/i965/test_blorp_blit_eu_gen.cpp diff --git a/src/mesa/drivers/dri/i965/.gitignore b/src/mesa/drivers/dri/i965/.gitignore index 3cf4ba0..cb66728 100644 --- a/src/mesa/drivers/dri/i965/.gitignore +++ b/src/mesa/drivers/dri/i965/.gitignore @@ -2,4 +2,3 @@ i965_symbols_test test_eu_compact test_vec4_copy_propagation test_vec4_register_coalesce -test_blorp_blit_eu_gen diff --git a/src/mesa/drivers/dri/i965/Makefile.am b/src/mesa/drivers/dri/i965/Makefile.am index 7ab376c..5809dc6 100644 --- a/src/mesa/drivers/dri/i965/Makefile.am +++ b/src/mesa/drivers/dri/i965/Makefile.am @@ -56,8 +56,7 @@ TEST_LIBS = \ TESTS = \ test_eu_compact \ test_vec4_copy_propagation \ -test_vec4_register_coalesce \ -test_blorp_blit_eu_gen +test_vec4_register_coalesce check_PROGRAMS = $(TESTS) @@ -77,7 +76,3 @@ test_eu_compact_SOURCES = \ test_eu_compact.c nodist_EXTRA_test_eu_compact_SOURCES = dummy.cpp test_eu_compact_LDADD = $(TEST_LIBS) - -test_blorp_blit_eu_gen_SOURCES = \ -test_blorp_blit_eu_gen.cpp -test_blorp_blit_eu_gen_LDADD = $(TEST_LIBS) -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75010] clang: error: unknown argument: '-fstack-protector-strong'
https://bugs.freedesktop.org/show_bug.cgi?id=75010 --- Comment #1 from Vinson Lee --- Created attachment 99048 --> https://bugs.freedesktop.org/attachment.cgi?id=99048&action=edit configure.ac: Remove -fstack-protector-strong from LLVM flags. -- 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] Mesa 10.2 release candidate 2
On Wed, May 14, 2014 at 3:14 PM, Ian Romanick wrote: > On 05/09/2014 08:28 PM, Ian Romanick wrote: >> (This is a re-send with a GPG signature.) >> >> Mesa 10.2 release candidate 2 is now available for testing. The current >> plan of record is to have an additional release candidate each Friday >> until the 10.2 release on Friday, May 30th (correcte from the RC1 >> announcement e-mail). >> >> Note: there is a possible front-buffer rendering regression in the >> branch on some Intel hardware configurations. If you're worried about >> this case, you may want to wait for RC3. I chose to not revert the >> patches because I would have needed to revert quite a few (due to a >> dependency chain), and the patches fix an assertion failure. For more >> information, see: >> >> https://bugs.freedesktop.org/show_bug.cgi?id=78515 >> >> The tag in the GIT repository for Mesa 10.2-rc2 is 'mesa-10.2-rc2'. > > Folks have reported to me on IRC that I completely screwed this up > somehow. There is a mesa-10.2-rc2 tag, but it is *NOT* a commit on the > 10.2 branch. There was some last minute removal of patches from the > branch, so I may have forgotten to re-tag after removing the last bad patch. > > The actual commit in the repo for 10.2-rc2 is 0b3126b. > > The question now is... what should I do about the tag? Retag and force > push it? Make a new mesa-10.2-rc2-for-realz tag? Something else? The release tarball, etc are based on 0b3126b? If so, I would say force push mesa-10.2-rc2 to that commit and push a mesa-10.2-rc2-for-fakes-sake tag at 2e3ded0. -Jordan >> Mesa 10.2 release candidate 2 is available for download at >> ftp://freedesktop.org/pub/mesa/10.2/ >> >> md5sums: >> >> f0f962321522c9fe599a2b69cc229b67 MesaLib-10.2.0-rc2.tar.gz >> 9976683cf51b330d3b06301e52bbc3d6 MesaLib-10.2.0-rc2.tar.bz2 >> 910c14cd75cac00b26b11c35d1034d06 MesaLib-10.2.0-rc2.zip >> >> I have verified building from the .tar.bz2 file by doing the following >> on my aging Fedora 18 system: >> >> tar -xjf Mesa-10.2.0-rc2.tar.bz2 >> cd Mesa-10.2.0-rc2 >> ./configure --enable-gallium-llvm >> make -j6 && make check >> make install >> >> Changes since mesa-10.2-rc1: >> >> Emil Velikov (2): >> configure: error out if building GBM without dri >> glx/tests: Partially revert commit >> 51e3569573a7b3f8da0df093836761003fcdc414 >> >> Ian Romanick (2): >> linker: Fix consumer_inputs_with_locations indexing >> mesa: Bump version to 10.2-rc2 >> >> Ilia Mirkin (1): >> nv50/ir/gk110: fix set with f32 dest >> >> Kenneth Graunke (9): >> i965: Set miptree target field when creating from a BO. >> i965: Always intel_prepare_render() after invalidating front buffers. >> meta: Unify the GLSL and fixed-function clear paths. >> meta: Add a new MESA_META_DRAW_BUFFERS bit. >> meta: Add infrastructure for saving/restoring the DrawBuffers state. >> meta: Only clear the requested color buffers. >> i965: Enable GL_ARB_texture_view on Broadwell. >> mesa: Fix MaxNumLayers for 1D array textures. >> i965: Fix GPU hangs on Broadwell in shaders with some control flow. >> >> Roland Scheidegger (1): >> draw: do not use draw_get_option_use_llvm() inside draw execution paths >> >> Tapani Pälli (1): >> glsl: fix bogus layout qualifier warnings >> >> Thomas Hellstrom (1): >> st/xa: Fix performance regression introduced by commit "Cache render >> target surface" >> >> Tom Stellard (4): >> pipe-loader: Don't destroy the winsys in the sw loader >> clover: Destory pipe_screen when device does not support compute v2 >> configure.ac: Add LLVM_VERSION_PATCH to DEFINES >> radeonsi: Enable geometry shaders with LLVM 3.4.1 >> >> >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] gallium/radeon: build only a single common library libradeon
On Tue, May 13, 2014 at 12:15:01AM +0100, Emil Velikov wrote: > Just fold libllvmradeon in libradeon. For the series: Reviewed-by: Tom Stellard > > Signed-off-by: Emil Velikov > --- > src/gallium/drivers/r600/Makefile.am | 2 -- > src/gallium/drivers/radeon/Makefile.am | 12 > src/gallium/drivers/radeonsi/Makefile.am | 3 +-- > 3 files changed, 5 insertions(+), 12 deletions(-) > > diff --git a/src/gallium/drivers/r600/Makefile.am > b/src/gallium/drivers/r600/Makefile.am > index b2e3708..be8635d 100644 > --- a/src/gallium/drivers/r600/Makefile.am > +++ b/src/gallium/drivers/r600/Makefile.am > @@ -28,8 +28,6 @@ AM_CFLAGS += \ > libr600_la_SOURCES += \ > $(LLVM_C_SOURCES) > > -libr600_la_LIBADD += ../radeon/libllvmradeon.la > - > endif > > if USE_R600_LLVM_COMPILER > diff --git a/src/gallium/drivers/radeon/Makefile.am > b/src/gallium/drivers/radeon/Makefile.am > index b521658..e2c980f 100644 > --- a/src/gallium/drivers/radeon/Makefile.am > +++ b/src/gallium/drivers/radeon/Makefile.am > @@ -13,22 +13,18 @@ libradeon_la_SOURCES = \ > > if NEED_RADEON_LLVM > > -noinst_LTLIBRARIES += libllvmradeon.la > - > -libllvmradeon_la_CFLAGS = \ > - $(GALLIUM_DRIVER_CFLAGS) \ > - $(RADEON_CFLAGS) \ > +AM_CFLAGS += \ > $(LLVM_CFLAGS) > > -libllvmradeon_la_SOURCES = \ > +libradeon_la_SOURCES += \ > $(LLVM_C_FILES) > > -libllvmradeon_la_LIBADD = \ > +libradeon_la_LIBADD = \ > $(CLOCK_LIB) \ > $(LLVM_LIBS) \ > $(ELF_LIB) > > -libllvmradeon_la_LDFLAGS = \ > +libradeon_la_LDFLAGS = \ > $(LLVM_LDFLAGS) > > endif > diff --git a/src/gallium/drivers/radeonsi/Makefile.am > b/src/gallium/drivers/radeonsi/Makefile.am > index 84c99f8..f409f7e 100644 > --- a/src/gallium/drivers/radeonsi/Makefile.am > +++ b/src/gallium/drivers/radeonsi/Makefile.am > @@ -33,5 +33,4 @@ noinst_LTLIBRARIES = libradeonsi.la > > libradeonsi_la_SOURCES = $(C_SOURCES) > libradeonsi_la_LIBADD = \ > - ../radeon/libradeon.la \ > - ../radeon/libllvmradeon.la > + ../radeon/libradeon.la > -- > 1.9.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] [Bug 78716] New: Fix Mesa bugs for running Unreal Engine 4.1 Cave effects demo compiled for Linux
https://bugs.freedesktop.org/show_bug.cgi?id=78716 Priority: medium Bug ID: 78716 Assignee: mesa-dev@lists.freedesktop.org Summary: Fix Mesa bugs for running Unreal Engine 4.1 Cave effects demo compiled for Linux Severity: normal Classification: Unclassified OS: All Reporter: rtf...@gmail.com Hardware: Other Status: NEW Version: git Component: Mesa core Product: Mesa Hi, I have compiled Cave effects demo of UE4 for Linux and as expected doesn't work using Mesa open source drivers tested on both nouveau (GTX 470) and radeonsi (HD 7970) drivers.. I uploaded the demo to Mediafire: http://www.mediafire.com/download/0rav1j9033l784m/cave.rar Tried to run drivers using current drivers at https://launchpad.net/~nzatkovich/+archive/bleediergraphics because they use LLVM 3.5 daily so have support for GL 3.3 on radeonsi.. The demo runs by default using GL 3.2 profile and can be run in OGL 4.3 mode via -opengl4 argument. This can be useful for testing Mesa against it when it supports compute shaders, VAB and other features used by GL4 path.. Note demo runs on both Nvidia and AMD latest binary graphic drivers.. (See README inside file for more arguments and details on binary drivers used) -- 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 6/6] mesa: Skip glLinkProgram() if it isn't necessary.
Beyond issuing a warning, we can actually skip the LinkProgram call if
it isn't necessary. Notably, some game engines may set "new" attribute
bindings and re-link, when it actually picked the same values, so there
was no actual change.
Skips a bunch of unnecessary linking in an upcoming game.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/shaderapi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 290987a..c56992a 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -945,6 +945,7 @@ link_program(struct gl_context *ctx, GLuint program)
if (shProg->LinkStatus && !shProg->NeedsRelink) {
_mesa_perf_debug(ctx, MESA_DEBUG_SEVERITY_LOW,
"glLinkProgram(%d) called unnecessarily\n", program);
+ return;
}
_mesa_glsl_link_shader(ctx, shProg);
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] mesa: Ignore BindAttribLocation calls that set the same value.
A certain game engine links its shaders, calls BindAttribLocation to set
the same values a second time, then re-links them all.
If the binding doesn't actually change, there's no need to re-link,
so we can avoid flagging that.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/shader_query.cpp | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
This also adds additional overhead, which could probably be lessened by
altering the string_to_uint_map interface to make a "put and tell me if
the value changed" method.
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index db3be0c..e6e8135 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -68,13 +68,16 @@ _mesa_BindAttribLocation(GLhandleARB program, GLuint index,
* VERT_ATTRIB_GENERIC0 because that's how the linker differentiates
* between built-in attributes and user-defined attributes.
*/
- shProg->AttributeBindings->put(index + VERT_ATTRIB_GENERIC0, name);
+ unsigned new_value = index + VERT_ATTRIB_GENERIC0;
+ unsigned old;
+ if (!shProg->AttributeBindings->get(old, name) || old != new_value) {
+ shProg->AttributeBindings->put(index + VERT_ATTRIB_GENERIC0, name);
- /*
-* Note that this attribute binding won't go into effect until
-* glLinkProgram is called again.
-*/
- shProg->NeedsRelink = true;
+ /* Note that this attribute binding won't go into effect until
+ * glLinkProgram is called again.
+ */
+ shProg->NeedsRelink = true;
+ }
}
static bool
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Re-linking warnings and optimization
Hi all, Here's a series of patches which implements warnings related to re-linking shader programs: 1. If you draw with a shader that needs re-linking, it gives you a warning. Most likely you simply forgot, and will be surprised by the results. Occasionally you might have meant to do that. 2. If you call LinkProgram when it doesn't need re-linking, it gives you a low severity performance warning, since you asked GL to do pointless work. Then, the patch series relaxes some "need to relink" conditions (if you bind attributes to the same values). More could be done here. With those in place, one unreleased game I was looking at issues piles of warnings about unnecessary linking, and then later issues piles of draw-time warnings about the need to re-link. I really don't know what's going on there. Finally, I made LinkProgram bail entirely when unnecessarily. The game and Piglit seem fine with this, so I think my tracking is OK. But, I'm not sure if we really want to do it. I'm also not super excited about the extra draw time overhead - especially checking for shader recompiles. --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] mesa: Issue a warning when drawing with a program that needs re-linking.
Drawing with a program that hasn't been re-linked is legal, but likely
isn't what the application author intended. Give a helpful warning.
(_mesa_shader_debug might be more appropriate than _mesa_warning...)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78700
Signed-off-by: Kenneth Graunke
---
src/mesa/main/context.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 860ae86..c428dbb 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -118,6 +118,7 @@
#include "scissor.h"
#include "shared.h"
#include "shaderobj.h"
+#include "shaderapi.h"
#include "simple_list.h"
#include "state.h"
#include "stencil.h"
@@ -1813,7 +1814,7 @@ _mesa_check_blend_func_error(struct gl_context *ctx)
static bool
shader_linked_or_absent(struct gl_context *ctx,
-const struct gl_shader_program *shProg,
+struct gl_shader_program *shProg,
bool *shader_present, const char *where)
{
if (shProg) {
@@ -1823,6 +1824,13 @@ shader_linked_or_absent(struct gl_context *ctx,
_mesa_error(ctx, GL_INVALID_OPERATION, "%s(shader not linked)",
where);
return false;
}
+
+ _mesa_check_for_recompiled_shaders(shProg);
+ if (shProg->NeedsRelink) {
+ _mesa_warning(ctx, "%s(shader program %u needs re-linking)",
+ where, shProg->Name);
+ }
+
#if 0 /* not normally enabled */
{
char errMsg[100];
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] mesa: Track whether shaders have been recompiled since the last link.
OpenGL allows you to call ShaderSource and CompileShader on existing
shaders which are already attached to programs that have been linked.
I want to be able to accurately track when programs need relinking,
and unfortunately this is one of those cases.
Signed-off-by: Kenneth Graunke
---
src/glsl/linker.cpp | 7 +++
src/mesa/main/mtypes.h| 2 ++
src/mesa/main/shaderapi.c | 28
src/mesa/main/shaderapi.h | 3 +++
4 files changed, 40 insertions(+)
I loathe this code. I'd say there has to be a better way, but I sure
couldn't think of one.
This is necessary to make Piglit's glsl-reload-source continue passing
after my early-return-from-LinkProgram patch, later in the series.
I don't know why OpenGL made this a feature.
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index a43d230..49eb2d4 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2618,6 +2618,13 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
/* FINISHME: Assign fragment shader output locations. */
done:
+ if (prog->LinkStatus) {
+ ralloc_free(prog->ShaderEpochs);
+ prog->ShaderEpochs = ralloc_array(prog, unsigned, prog->NumShaders);
+ for (unsigned i = 0; i < prog->NumShaders; i++)
+ prog->ShaderEpochs[i] = prog->Shaders[i]->CompileEpoch;
+ }
+
for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
free(shader_list[i]);
if (prog->_LinkedShaders[i] == NULL)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 741f936..df7715b 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2379,6 +2379,7 @@ struct gl_shader
GLint RefCount; /**< Reference count */
GLboolean DeletePending;
GLboolean CompileStatus;
+ unsigned CompileEpoch; /**< Incremented each time the shader is recompiled
*/
const GLchar *Source; /**< Source code string */
GLuint SourceChecksum; /**< for debug/logging purposes */
struct gl_program *Program; /**< Post-compile assembly code */
@@ -2615,6 +2616,7 @@ struct gl_shader_program
GLuint NumShaders; /**< number of attached shaders */
struct gl_shader **Shaders; /**< List of attached the shaders */
+ unsigned *ShaderEpochs; /**< List of CompileEpochs for attached shaders. */
/**
* User-defined attribute bindings
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 59d30ff..3a4a2a9 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -827,6 +827,8 @@ compile_shader(struct gl_context *ctx, GLuint shaderObj)
if (!sh)
return;
+ ++sh->CompileEpoch;
+
options = &ctx->ShaderCompilerOptions[sh->Stage];
/* set default pragma state for shader */
@@ -887,6 +889,32 @@ compile_shader(struct gl_context *ctx, GLuint shaderObj)
}
}
+/**
+ * Updates shProg->NeedsRelink if any of the attached shaders have been
+ * recompiled since the last LinkProgram call.
+ *
+ * This will break if the shaders are recompiled exactly 2^32 times between
+ * LinkProgram calls, but only an extremely targeted test would hit that.
+ */
+void
+_mesa_check_for_recompiled_shaders(struct gl_shader_program *shProg)
+{
+ unsigned i;
+
+ /* If the program isn't linked, we have no existing LinkedShaders to
+* compare to. If it's already marked as needing a relink, there's
+* no need to bother checking.
+*/
+ if (!shProg->LinkStatus || shProg->NeedsRelink)
+ return;
+
+ for (i = 0; i < shProg->NumShaders; i++) {
+ if (shProg->Shaders[i]->CompileEpoch != shProg->ShaderEpochs[i]) {
+ shProg->NeedsRelink = true;
+ return;
+ }
+ }
+}
/**
* Link a program's shaders.
diff --git a/src/mesa/main/shaderapi.h b/src/mesa/main/shaderapi.h
index 17b05b3..4a7be5c 100644
--- a/src/mesa/main/shaderapi.h
+++ b/src/mesa/main/shaderapi.h
@@ -60,6 +60,9 @@ _mesa_count_active_attribs(struct gl_shader_program *shProg);
extern size_t
_mesa_longest_attribute_name_length(struct gl_shader_program *shProg);
+extern void
+_mesa_check_for_recompiled_shaders(struct gl_shader_program *shProg);
+
extern void GLAPIENTRY
_mesa_AttachObjectARB(GLhandleARB, GLhandleARB);
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] mesa: Begin tracking whether a program needs re-linking.
Tracking this will allow us to issue warnings when using a program that
hasn't yet been relinked, or when re-linking unnecessarily.
The following functions cause changes that don't take effect until the
program has been re-linked:
- glAttachShader
- glBindAttribLocation
- glBindFragDataLocation
- glBindFragDataLocationIndexed
- glTransformFeedbackVaryings
- glProgramParameteri (separable/binary retrievable hint)
- glUniformBlockBinding
OpenGL also allows the application to recompile shaders that have been
attached to programs and linked---at which point, they need relinking.
That case will be handled shortly.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/mtypes.h| 1 +
src/mesa/main/shader_query.cpp| 3 ++-
src/mesa/main/shaderapi.c | 6 ++
src/mesa/main/transformfeedback.c | 1 +
src/mesa/main/uniforms.c | 2 ++
5 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 917d071..741f936 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2744,6 +2744,7 @@ struct gl_shader_program
struct gl_active_atomic_buffer *AtomicBuffers;
unsigned NumAtomicBuffers;
+ bool NeedsRelink;
GLboolean LinkStatus; /**< GL_LINK_STATUS */
GLboolean Validated;
GLboolean _Used;/**< Ever used for drawing? */
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 36d1d9c..db3be0c 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -74,6 +74,7 @@ _mesa_BindAttribLocation(GLhandleARB program, GLuint index,
* Note that this attribute binding won't go into effect until
* glLinkProgram is called again.
*/
+ shProg->NeedsRelink = true;
}
static bool
@@ -365,7 +366,7 @@ _mesa_BindFragDataLocationIndexed(GLuint program, GLuint
colorNumber,
* Note that this binding won't go into effect until
* glLinkProgram is called again.
*/
-
+ shProg->NeedsRelink = true;
}
GLint GLAPIENTRY
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 28739da..59d30ff 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -284,6 +284,7 @@ attach_shader(struct gl_context *ctx, GLuint program,
GLuint shader)
shProg->Shaders[n] = NULL; /* since realloc() didn't zero the new space */
_mesa_reference_shader(ctx, &shProg->Shaders[n], sh);
shProg->NumShaders++;
+ shProg->NeedsRelink = true;
}
@@ -914,6 +915,9 @@ link_program(struct gl_context *ctx, GLuint program)
_mesa_glsl_link_shader(ctx, shProg);
+ if (shProg->LinkStatus == GL_TRUE)
+ shProg->NeedsRelink = false;
+
if (shProg->LinkStatus == GL_FALSE &&
(ctx->_Shader->Flags & GLSL_REPORT_ERRORS)) {
_mesa_debug(ctx, "Error linking program %u:\n%s\n",
@@ -1770,6 +1774,7 @@ _mesa_ProgramParameteri(GLuint program, GLenum pname,
GLint value)
* is loaded again a recompile can be avoided."
*/
shProg->BinaryRetreivableHint = value;
+ shProg->NeedsRelink = true;
return;
case GL_PROGRAM_SEPARABLE:
@@ -1785,6 +1790,7 @@ _mesa_ProgramParameteri(GLuint program, GLenum pname,
GLint value)
return;
}
shProg->SeparateShader = value;
+ shProg->NeedsRelink = true;
return;
default:
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index a737463..c037faa 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -771,6 +771,7 @@ _mesa_TransformFeedbackVaryings(GLuint program, GLsizei
count,
/* No need to invoke FLUSH_VERTICES or flag NewTransformFeedback since
* the varyings won't be used until shader link time.
*/
+ shProg->NeedsRelink = true;
}
diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c
index 1daade4..39a61f7 100644
--- a/src/mesa/main/uniforms.c
+++ b/src/mesa/main/uniforms.c
@@ -1043,6 +1043,8 @@ _mesa_UniformBlockBinding(GLuint program,
sh->UniformBlocks[stage_index].Binding = uniformBlockBinding;
}
}
+
+ shProg->NeedsRelink = true;
}
}
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] mesa: Issue a performance warning for unnecessary LinkProgram calls.
Now that we track whether a program needs re-linking, we can issue a
warning if it's called when a re-link isn't required.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/shaderapi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 3a4a2a9..290987a 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -941,6 +941,12 @@ link_program(struct gl_context *ctx, GLuint program)
FLUSH_VERTICES(ctx, _NEW_PROGRAM);
+ _mesa_check_for_recompiled_shaders(shProg);
+ if (shProg->LinkStatus && !shProg->NeedsRelink) {
+ _mesa_perf_debug(ctx, MESA_DEBUG_SEVERITY_LOW,
+ "glLinkProgram(%d) called unnecessarily\n", program);
+ }
+
_mesa_glsl_link_shader(ctx, shProg);
if (shProg->LinkStatus == GL_TRUE)
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/3] Add support for swrast to the DRM EGL platform
On 05/05/14 17:07, Giovanni Campagna wrote:
> From: Giovanni Campagna
>
> Turn GBM into a swrast loader (providing putimage/getimage backed
> by a dumb KMS buffer). This allows to run KMS+DRM GL applications
> (such as weston or mutter-wayland) unmodified on cards that don't
> have any client side HW acceleration component but that can do
> modeset (examples include simpledrm and qxl)
> ---
> src/egl/drivers/dri2/platform_drm.c | 186
> src/gbm/backends/dri/gbm_dri.c | 210
> +---
> src/gbm/backends/dri/gbm_driint.h | 19 +++-
> src/gbm/main/gbm.h | 3 +
> src/loader/loader.c | 6 ++
> 5 files changed, 363 insertions(+), 61 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_drm.c
> b/src/egl/drivers/dri2/platform_drm.c
> index 9a7633a..17b93db 100644
> --- a/src/egl/drivers/dri2/platform_drm.c
> +++ b/src/egl/drivers/dri2/platform_drm.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -44,6 +45,7 @@ lock_front_buffer(struct gbm_surface *_surf)
> {
> struct gbm_dri_surface *surf = (struct gbm_dri_surface *) _surf;
> struct dri2_egl_surface *dri2_surf = surf->dri_private;
> + struct gbm_dri_device *device = (struct gbm_dri_device *) _surf->gbm;
> struct gbm_bo *bo;
>
> if (dri2_surf->current == NULL) {
> @@ -52,8 +54,11 @@ lock_front_buffer(struct gbm_surface *_surf)
> }
>
> bo = dri2_surf->current->bo;
> - dri2_surf->current->locked = 1;
> - dri2_surf->current = NULL;
> +
> + if (device->dri2) {
> + dri2_surf->current->locked = 1;
> + dri2_surf->current = NULL;
> + }
>
> return bo;
> }
> @@ -122,10 +127,18 @@ dri2_drm_create_surface(_EGLDriver *drv, _EGLDisplay
> *disp, EGLint type,
>goto cleanup_surf;
> }
>
> - dri2_surf->dri_drawable =
> - (*dri2_dpy->dri2->createNewDrawable) (dri2_dpy->dri_screen,
> - dri2_conf->dri_double_config,
> - dri2_surf->gbm_surf);
> + if (dri2_dpy->dri2) {
> + dri2_surf->dri_drawable =
> + (*dri2_dpy->dri2->createNewDrawable) (dri2_dpy->dri_screen,
> + dri2_conf->dri_double_config,
> + dri2_surf->gbm_surf);
> + } else {
> + assert (dri2_dpy->swrast != NULL);
> + dri2_surf->dri_drawable =
> + (*dri2_dpy->swrast->createNewDrawable) (dri2_dpy->dri_screen,
> +
> dri2_conf->dri_double_config,
> + dri2_surf->gbm_surf);
> + }
>
> if (dri2_surf->dri_drawable == NULL) {
>_eglError(EGL_BAD_ALLOC, "dri2->createNewDrawable");
Can you update the above message ?
> @@ -221,6 +234,28 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
> return 0;
> }
>
> +static int
> +get_swrast_front_bo(struct dri2_egl_surface *dri2_surf)
> +{
> + struct dri2_egl_display *dri2_dpy =
> + dri2_egl_display(dri2_surf->base.Resource.Display);
> + struct gbm_dri_surface *surf = dri2_surf->gbm_surf;
> +
> + if (dri2_surf->current == NULL) {
> + assert (!dri2_surf->color_buffers[0].locked);
> + dri2_surf->current = &dri2_surf->color_buffers[0];
> + }
> +
> + if (dri2_surf->current->bo == NULL)
> + dri2_surf->current->bo = gbm_bo_create(&dri2_dpy->gbm_dri->base.base,
> + surf->base.width,
> surf->base.height,
> + surf->base.format,
> surf->base.flags);
> + if (dri2_surf->current->bo == NULL)
> + return -1;
> +
> + return 0;
> +}
> +
> static void
> back_bo_to_dri_buffer(struct dri2_egl_surface *dri2_surf, __DRIbuffer
> *buffer)
> {
> @@ -374,19 +409,23 @@ dri2_drm_swap_buffers(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLSurface *draw)
> struct dri2_egl_surface *dri2_surf = dri2_egl_surface(draw);
> int i;
>
> - if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
> - if (dri2_surf->current)
> - _eglError(EGL_BAD_SURFACE, "dri2_swap_buffers");
> - for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++)
> - if (dri2_surf->color_buffers[i].age > 0)
> -dri2_surf->color_buffers[i].age++;
> - dri2_surf->current = dri2_surf->back;
> - dri2_surf->current->age = 1;
> - dri2_surf->back = NULL;
> - }
> + if (dri2_dpy->swrast) {
> + (*dri2_dpy->core->swapBuffers)(dri2_surf->dri_drawable);
> + } else {
> + if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
> + if (dri2_surf->current)
> +_eglError(EGL_BAD_SURFACE, "dri2_swap_buffers");
> + for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++)
> +if (dri2_surf->color_buffers[i].age > 0)
> + dri2_surf->color_buffers[i].age++;
> + dri2_surf->cur
Re: [Mesa-dev] [PATCH v2 2/3] Add a dumb drm/kms winsys for software rendering
On 05/05/14 17:07, Giovanni Campagna wrote: > From: Giovanni Campagna > > Add a new winsys and target that can be used with a dri2 state tracker and > loader instead of drisw. This allows to use gbm as a dri2/image loader > and avoid the extra copy from the backbuffer to the shadow frontbuffer. > > The new driver is called "kms_swrast", and is only loaded by gbm > as a fallback, because it is only useful with the gbm platform > (as no buffer sharing is possible) Hi Giovanni, A couple of nits that I have missed the previous time. > --- > configure.ac | 4 +- > docs/relnotes/10.3.html| 2 + > src/gallium/targets/Makefile.am| 2 +- > src/gallium/targets/dri-kms-swrast/Makefile.am | 61 > .../targets/dri-kms-swrast/kms_swrast_drm_api.c| 65 + > src/gallium/winsys/Makefile.am | 2 +- > src/gallium/winsys/sw/kms-dri/Makefile.am | 33 +++ > src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 310 > + > src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.h | 37 +++ > src/gbm/backends/dri/gbm_dri.c | 6 +- > 10 files changed, 516 insertions(+), 6 deletions(-) > create mode 100644 src/gallium/targets/dri-kms-swrast/Makefile.am > create mode 100644 src/gallium/targets/dri-kms-swrast/kms_swrast_drm_api.c > create mode 100644 src/gallium/winsys/sw/kms-dri/Makefile.am > create mode 100644 src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c > create mode 100644 src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.h > > diff --git a/configure.ac b/configure.ac > index e77ed77..958e03e 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1863,7 +1863,7 @@ if test -n "$with_gallium_drivers"; then > fi > > if test "x$enable_dri" = xyes; then > -GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS dri-swrast" > +GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS dri-swrast > dri-kms-swrast" dri-kms-swrast depends on DRM so it may be better to change the above to if test "x$have_libdrm" = xyes; then GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS dri-kms-swrast" fi > fi > ;; > *) > @@ -2080,6 +2080,7 @@ AC_CONFIG_FILES([Makefile > src/gallium/targets/dri-ilo/Makefile > src/gallium/targets/dri-nouveau/Makefile > src/gallium/targets/dri-swrast/Makefile > + src/gallium/targets/dri-kms-swrast/Makefile > src/gallium/targets/dri-vmwgfx/Makefile > src/gallium/targets/egl-static/Makefile > src/gallium/targets/gbm/Makefile > @@ -2111,6 +2112,7 @@ AC_CONFIG_FILES([Makefile > src/gallium/winsys/nouveau/drm/Makefile > src/gallium/winsys/radeon/drm/Makefile > src/gallium/winsys/svga/drm/Makefile > + src/gallium/winsys/sw/kms-dri/Makefile > src/gallium/winsys/sw/dri/Makefile > src/gallium/winsys/sw/fbdev/Makefile > src/gallium/winsys/sw/null/Makefile > diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html > index aebc3ff..92b2cc0 100644 > --- a/docs/relnotes/10.3.html > +++ b/docs/relnotes/10.3.html > @@ -45,6 +45,8 @@ Note: some of the new features are only available with > certain drivers. > > > GL_ARB_stencil_texturing on nv50, nvc0, r600, and radeonsi > +A new software rasterizer driver that works with DRM drivers that > +don't have a full-fledged GEM (such as qxl or simpledrm) > +A new software rasterizer driver (kms_swrast_dri.so) that works +with DRM drivers which are lacking a full-fledged GEM (such as qxl +or simpledrm) > > > diff --git a/src/gallium/targets/Makefile.am b/src/gallium/targets/Makefile.am > index 5023dbc..95b644e 100644 > --- a/src/gallium/targets/Makefile.am > +++ b/src/gallium/targets/Makefile.am > @@ -124,7 +124,7 @@ endif > > if HAVE_GALLIUM_SOFTPIPE > if HAVE_DRI > -SUBDIRS += dri-swrast > +SUBDIRS += dri-swrast dri-kms-swrast Similar to before, build the new driver only when libdrm is present if HAVE_LIBDRM SUBDIRS += dri-kms-swrast endif > endif > endif > > diff --git a/src/gallium/targets/dri-kms-swrast/Makefile.am > b/src/gallium/targets/dri-kms-swrast/Makefile.am > new file mode 100644 > index 000..09a8d17 > --- /dev/null > +++ b/src/gallium/targets/dri-kms-swrast/Makefile.am > @@ -0,0 +1,61 @@ > +# Copyright © 2012 Intel Corporation > +# > +# Permission is hereby granted, free of charge, to any person obtaining a > +# copy of this software and associated documentation files (the "Software"), > +# to deal in the Software without restriction, including without limitation > +# the rights to use, copy, modify, merge, publish, distribute, sublicense, > +# and/or sell copies of the Software, and to permit persons to whom the > +# Software is furnished to do so, subject to the following conditions: > +# > +# The above copyr
Re: [Mesa-dev] [PATCH v2 0/3] Software rasterizer in the DRM EGL platform
On 05/05/14 17:07, Giovanni Campagna wrote: > This is my second attempt to bring swrast to the DRM EGL platform. > It includes both the legacy loader, which will work with any > swrast driver, and the new gallium winsys which works with the > DRI2 loader and softpipe/llvmpipe. > Hi Giovanni, Just sent a handful of nitpicks for the patches. While I'm not the best person to comment on the overall architecture/approach of the patches, I believe they look quite good. Hope the comments are useful. -Emil > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78716] Fix Mesa bugs for running Unreal Engine 4.1 Cave effects demo compiled for Linux
https://bugs.freedesktop.org/show_bug.cgi?id=78716 --- Comment #1 from Michel Dänzer --- The first issue I'm hitting with r600g is that the demo tries to get the value of GL_MAX_COMPUTE_TEXTURE_IMAGE_UNITS and then fails an assertion because that's not available. Looks like an issue in the demo rather than in Mesa. -- 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] Megaradeon
Hi everybody, Some distros seem to care about the size of Mesa, so I came up with this little patch. It puts r600g and radeonsi into r300_dri.so. The result is one shared library which contains all three drivers. Also, all driver loaders in Mesa should now always load the r300 driver instead of r600 and radeonsi. The radeon winsys is created first, which then creates the correct screen (r300, r600, or radeonsi) according to the PCI ID. The libGL loader has actually been ignoring the driver name from the X server for quite some time, so nothing needs to be done for this outside of Mesa. This is for *_dri.so only, the other targets are still separate and probably broken with this patch. (VDPAU, XvMC, egl-gallium, OpenCL?) What's missing: - do the same for the other targets/APIs - remove r600 and radeonsi targets and clean up the build system Original files without debugging symbols: 5.9MB r300_dri.so 6.5MB r600_dri.so 5.7MB radeonsi_dri.so Megaradeon: 7.0MB r300_dri.so (all 3 drivers) If somebody who cares about the size of Mesa wants to finish this up, the patch is attached. This is only a proof that it's not really difficult. What remains is mostly just build system work. Marek 0001-gallium-build-r600-and-radeonsi-into-r300_dri.so-and.patch Description: application/pgp-keys ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Megaradeon
On 15/05/14 02:58, Marek Olšák wrote: > Hi everybody, > > Some distros seem to care about the size of Mesa, so I came up with > this little patch. > > It puts r600g and radeonsi into r300_dri.so. The result is one shared > library which contains all three drivers. Also, all driver loaders in > Mesa should now always load the r300 driver instead of r600 and > radeonsi. > > The radeon winsys is created first, which then creates the correct > screen (r300, r600, or radeonsi) according to the PCI ID. > > The libGL loader has actually been ignoring the driver name from the X > server for quite some time, so nothing needs to be done for this > outside of Mesa. > > This is for *_dri.so only, the other targets are still separate and > probably broken with this patch. (VDPAU, XvMC, egl-gallium, OpenCL?) > > What's missing: > - do the same for the other targets/APIs > - remove r600 and radeonsi targets and clean up the build system > > Original files without debugging symbols: > 5.9MB r300_dri.so > 6.5MB r600_dri.so > 5.7MB radeonsi_dri.so > Megaradeon: > 7.0MB r300_dri.so (all 3 drivers) > > If somebody who cares about the size of Mesa wants to finish this up, > the patch is attached. This is only a proof that it's not really > difficult. What remains is mostly just build system work. > Hi Marek, I came back to the megadri, megavdpau... topic recently. Personally I will go with pipe-loader-to-all targets, although I'm planning to have the mega* the default option, due to concerns about the unstable interface. Thanks for the work. It will definitely be helpful. Emil > Marek > > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/3] Add a dumb drm/kms winsys for software rendering
On Mon, May 5, 2014 at 9:07 AM, Giovanni Campagna wrote: > @@ -2080,6 +2080,7 @@ AC_CONFIG_FILES([Makefile > src/gallium/targets/dri-ilo/Makefile > src/gallium/targets/dri-nouveau/Makefile > src/gallium/targets/dri-swrast/Makefile > + src/gallium/targets/dri-kms-swrast/Makefile Alphabetize... > src/gallium/targets/dri-vmwgfx/Makefile > src/gallium/targets/egl-static/Makefile > src/gallium/targets/gbm/Makefile > @@ -2111,6 +2112,7 @@ AC_CONFIG_FILES([Makefile > src/gallium/winsys/nouveau/drm/Makefile > src/gallium/winsys/radeon/drm/Makefile > src/gallium/winsys/svga/drm/Makefile > + src/gallium/winsys/sw/kms-dri/Makefile Alphabetize... > src/gallium/winsys/sw/dri/Makefile > src/gallium/winsys/sw/fbdev/Makefile > src/gallium/winsys/sw/null/Makefile ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Megaradeon
On 15.05.2014 10:58, Marek Olšák wrote: > Hi everybody, > > Some distros seem to care about the size of Mesa, so I came up with > this little patch. > > It puts r600g and radeonsi into r300_dri.so. The result is one shared > library which contains all three drivers. Also, all driver loaders in > Mesa should now always load the r300 driver instead of r600 and > radeonsi. > > The radeon winsys is created first, which then creates the correct > screen (r300, r600, or radeonsi) according to the PCI ID. > > The libGL loader has actually been ignoring the driver name from the X > server for quite some time, so nothing needs to be done for this > outside of Mesa. > > This is for *_dri.so only, the other targets are still separate and > probably broken with this patch. (VDPAU, XvMC, egl-gallium, OpenCL?) > > What's missing: > - do the same for the other targets/APIs > - remove r600 and radeonsi targets and clean up the build system > > Original files without debugging symbols: > 5.9MB r300_dri.so > 6.5MB r600_dri.so > 5.7MB radeonsi_dri.so > Megaradeon: > 7.0MB r300_dri.so (all 3 drivers) > > If somebody who cares about the size of Mesa wants to finish this up, > the patch is attached. This is only a proof that it's not really > difficult. What remains is mostly just build system work. FWIW, I think it would be cleaner to use a new name instead of reusing any existing name. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl_to_tgsi: Make sure the 'shader' member is always initialized
From: Michel Dänzer Fixes the valgrind report below and random crashes with piglit on radeonsi. ==30005== Conditional jump or move depends on uninitialised value(s) ==30005==at 0xB13584E: st_translate_program (st_glsl_to_tgsi.cpp:5100) ==30005==by 0xB14698B: st_translate_fragment_program (st_program.c:747) ==30005==by 0xB14777D: st_get_fp_variant (st_program.c:824) ==30005==by 0xB11219C: get_color_fp_variant (st_cb_drawpixels.c:1042) ==30005==by 0xB1131AE: st_DrawPixels (st_cb_drawpixels.c:1154) ==30005==by 0xAFF8806: _mesa_DrawPixels (drawpix.c:162) ==30005==by 0x4EB86DB: stub_glDrawPixels (generated_dispatch.c:6640) ==30005==by 0x4F1DF08: piglit_visualize_image (piglit-util-gl.c:1574) ==30005==by 0x40691D: draw_image_to_window_system_fb(int, bool) (draw-buffers-common.cpp:733) ==30005==by 0x406C8B: draw_reference_image(bool, bool) (draw-buffers-common.cpp:854) ==30005==by 0x40722A: piglit_display (alpha-to-coverage-dual-src-blend.cpp:117) ==30005==by 0x4EA7168: run_test (piglit_fbo_framework.c:52) Signed-off-by: Michel Dänzer --- src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index 79d013d..739e108 100644 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp @@ -3155,6 +3155,7 @@ glsl_to_tgsi_visitor::glsl_to_tgsi_visitor() ctx = NULL; prog = NULL; shader_program = NULL; + shader = NULL; options = NULL; } @@ -3988,6 +3989,7 @@ get_pixel_transfer_visitor(struct st_fragment_program *fp, v->ctx = original->ctx; v->prog = prog; v->shader_program = NULL; + v->shader = NULL; v->glsl_version = original->glsl_version; v->native_integers = original->native_integers; v->options = original->options; @@ -4118,6 +4120,7 @@ get_bitmap_visitor(struct st_fragment_program *fp, v->ctx = original->ctx; v->prog = prog; v->shader_program = NULL; + v->shader = NULL; v->glsl_version = original->glsl_version; v->native_integers = original->native_integers; v->options = original->options; -- 2.0.0.rc0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl_to_tgsi: Make sure the 'shader' member is always initialized
Carl, this patch fixes a bug in commit 3e817e7e56806d8adb8f16c35136045c29908944; please hold off on backporting that to the 10.1 branch without this fix. On 15.05.2014 12:56, Michel Dänzer wrote: > From: Michel Dänzer > > Fixes the valgrind report below and random crashes with piglit on radeonsi. > > ==30005== Conditional jump or move depends on uninitialised value(s) > ==30005==at 0xB13584E: st_translate_program (st_glsl_to_tgsi.cpp:5100) > ==30005==by 0xB14698B: st_translate_fragment_program (st_program.c:747) > ==30005==by 0xB14777D: st_get_fp_variant (st_program.c:824) > ==30005==by 0xB11219C: get_color_fp_variant (st_cb_drawpixels.c:1042) > ==30005==by 0xB1131AE: st_DrawPixels (st_cb_drawpixels.c:1154) > ==30005==by 0xAFF8806: _mesa_DrawPixels (drawpix.c:162) > ==30005==by 0x4EB86DB: stub_glDrawPixels (generated_dispatch.c:6640) > ==30005==by 0x4F1DF08: piglit_visualize_image (piglit-util-gl.c:1574) > ==30005==by 0x40691D: draw_image_to_window_system_fb(int, bool) > (draw-buffers-common.cpp:733) > ==30005==by 0x406C8B: draw_reference_image(bool, bool) > (draw-buffers-common.cpp:854) > ==30005==by 0x40722A: piglit_display > (alpha-to-coverage-dual-src-blend.cpp:117) > ==30005==by 0x4EA7168: run_test (piglit_fbo_framework.c:52) > > Signed-off-by: Michel Dänzer > --- > src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp > b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp > index 79d013d..739e108 100644 > --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp > +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp > @@ -3155,6 +3155,7 @@ glsl_to_tgsi_visitor::glsl_to_tgsi_visitor() > ctx = NULL; > prog = NULL; > shader_program = NULL; > + shader = NULL; > options = NULL; > } > > @@ -3988,6 +3989,7 @@ get_pixel_transfer_visitor(struct st_fragment_program > *fp, > v->ctx = original->ctx; > v->prog = prog; > v->shader_program = NULL; > + v->shader = NULL; > v->glsl_version = original->glsl_version; > v->native_integers = original->native_integers; > v->options = original->options; > @@ -4118,6 +4120,7 @@ get_bitmap_visitor(struct st_fragment_program *fp, > v->ctx = original->ctx; > v->prog = prog; > v->shader_program = NULL; > + v->shader = NULL; > v->glsl_version = original->glsl_version; > v->native_integers = original->native_integers; > v->options = original->options; > -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78716] Fix Mesa bugs for running Unreal Engine 4.1 Cave effects demo compiled for Linux
https://bugs.freedesktop.org/show_bug.cgi?id=78716 --- Comment #2 from Tapani Pälli --- For me the demo fails with following error: setrlimit() failed with error 22 (Invalid argument) - Max per-process value allowed is 4096 (we wanted 1). -- 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] loader: allow alternative methods for PCI identification.
loader_get_pci_id_for_fd() and loader_get_device_name_for_fd() now attempt
all available strategies to identify the hardware, instead of conditionally
compiling in a single test. The existing libudev and DRM approaches have
been retained, and another simple alternative of looking up the answer in
the /sys filesystem (available on Linux) is added.
This should assist Linux systems that mount /sys but do not include
libudev (Android?), give Mesa a fighting chance of running on systems
where libudev is uninstalled/inaccessible/broken at runtime, and provides
a hook where non-Linux systems (BSD?) could implement their own PCI
identification.
Signed-off-by: Gary Wong
---
configure.ac| 51
src/loader/loader.c | 173 +++-
2 files changed, 195 insertions(+), 29 deletions(-)
diff --git a/configure.ac b/configure.ac
index d3e96de..fe572cd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -818,13 +818,31 @@ fi
case "$host_os" in
linux*)
-need_libudev=yes ;;
+need_pci_id=yes ;;
*)
-need_libudev=no ;;
+need_pci_id=no ;;
esac
-PKG_CHECK_MODULES([LIBUDEV], [libudev >= $LIBUDEV_REQUIRED],
- have_libudev=yes, have_libudev=no)
+AC_ARG_ENABLE([libudev],
+[AS_HELP_STRING([--disable-libudev],
+[disable libudev PCI identification @<:@default=enabled on supported
platforms@:>@])],
+[attempt_libudev="$enableval"],
+[attempt_libudev=yes]
+)
+
+if test "x$attempt_libudev" = "xyes"; then
+PKG_CHECK_MODULES([LIBUDEV], [libudev >= $LIBUDEV_REQUIRED],
+ have_libudev=yes, have_libudev=no)
+else
+have_libudev=no
+fi
+
+AC_ARG_ENABLE([sysfs],
+[AS_HELP_STRING([--disable-sysfs],
+[disable /sys PCI identification @<:@default=enabled on supported
platforms@:>@])],
+[have_sysfs="$enableval"],
+[have_sysfs=yes]
+)
if test "x$enable_dri" = xyes; then
if test "$enable_static" = yes; then
@@ -910,8 +928,15 @@ xyesno)
;;
esac
+have_pci_id=no
if test "$have_libudev" = yes; then
DEFINES="$DEFINES -DHAVE_LIBUDEV"
+have_pci_id=yes
+fi
+
+if test "$have_sysfs" = yes; then
+DEFINES="$DEFINES -DHAVE_SYSFS"
+have_pci_id=yes
fi
# This is outside the case (above) so that it is invoked even for non-GLX
@@ -1013,8 +1038,8 @@ if test "x$enable_dri" = xyes; then
DEFINES="$DEFINES -DHAVE_DRI3"
fi
-if test "x$have_libudev" != xyes; then
-AC_MSG_ERROR([libudev-dev required for building DRI])
+if test "x$have_pci_id" != xyes; then
+AC_MSG_ERROR([libudev-dev or sysfs required for building DRI])
fi
case "$host_cpu" in
@@ -1183,8 +1208,8 @@ if test "x$enable_gbm" = xauto; then
esac
fi
if test "x$enable_gbm" = xyes; then
-if test "x$need_libudev$have_libudev" = xyesno; then
-AC_MSG_ERROR([gbm requires udev >= $LIBUDEV_REQUIRED])
+if test "x$need_pci_id$have_pci_id" = xyesno; then
+AC_MSG_ERROR([gbm requires udev >= $LIBUDEV_REQUIRED or sysfs])
fi
if test "x$enable_dri" = xyes; then
@@ -1202,7 +1227,7 @@ if test "x$enable_gbm" = xyes; then
fi
fi
AM_CONDITIONAL(HAVE_GBM, test "x$enable_gbm" = xyes)
-if test "x$need_libudev" = xyes; then
+if test "x$need_pci_id$have_libudev" = xyesyes; then
GBM_PC_REQ_PRIV="libudev >= $LIBUDEV_REQUIRED"
else
GBM_PC_REQ_PRIV=""
@@ -1491,9 +1516,9 @@ for plat in $egl_platforms; do
;;
esac
-case "$plat$need_libudev$have_libudev" in
+case "$plat$need_pci_id$have_pci_id" in
waylandyesno|drmyesno)
-AC_MSG_ERROR([cannot build $plat platform without udev >=
$LIBUDEV_REQUIRED]) ;;
+AC_MSG_ERROR([cannot build $plat platform without udev >=
$LIBUDEV_REQUIRED or sysfs]) ;;
esac
done
@@ -1766,8 +1791,8 @@ gallium_require_llvm() {
gallium_require_drm_loader() {
if test "x$enable_gallium_loader" = xyes; then
-if test "x$need_libudev$have_libudev" = xyesno; then
-AC_MSG_ERROR([Gallium drm loader requires libudev >=
$LIBUDEV_REQUIRED])
+if test "x$need_pci_id$have_pci_id" = xyesno; then
+AC_MSG_ERROR([Gallium drm loader requires libudev >=
$LIBUDEV_REQUIRED or sysfs])
fi
if test "x$have_libdrm" != xyes; then
AC_MSG_ERROR([Gallium drm loader requires libdrm >=
$LIBDRM_REQUIRED])
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 666d015..33e77b3 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -71,6 +71,10 @@
#include
#include
#endif
+#ifdef HAVE_SYSFS
+#include
+#include
+#endif
#include "loader.h"
#ifndef __NOT_HAVE_DRM_H
@@ -113,8 +117,8 @@ udev_dlopen_handle(void)
udev_handle = dlopen("libudev.so.0", RTLD_LOCAL | RTLD_LAZY);
if (!udev_handle) {
-log_(_LOADER_FATAL, "Couldn't dlopen libudev.so.1 or libudev
[Mesa-dev] [Bug 78716] Fix Mesa bugs for running Unreal Engine 4.1 Cave effects demo compiled for Linux
https://bugs.freedesktop.org/show_bug.cgi?id=78716 --- Comment #3 from Tapani Pälli --- OK finally got it going. Demo may need compute and tesselation support (?) as it queries following enums: GL_MAX_TESS_CONTROL_TEXTURE_IMAGE_UNITS GL_MAX_TESS_EVALUATION_UNIFORM_COMPONENTS GL_MAX_TESS_CONTROL_UNIFORM_COMPONENTS GL_MAX_TESS_EVALUATION_TEXTURE_IMAGE_UNITS GL_MAX_COMPUTE_UNIFORM_COMPONENTS GL_MAX_COMPUTE_TEXTURE_IMAGE_UNITS After some more investigations found out that demo uses ARB_texture_multisample (requires GL_MAX_COLOR_TEXTURE_SAMPLES > 0) and has GLSL 1.50 shaders. I get numerous errors from failing resource file loads so I stopped there, this is what I'm getting: LogStreaming:Warning: Failed to read file '../../../Engine/Content/Slate/Checkerboard.png' error. LogStreaming:Warning: Failed to read file '../../../Engine/Content/Slate/Icons/DefaultAppIcon.png' error. LogStreaming:Warning: Failed to read file '../../../Engine/Content/Slate/Checkerboard.png' error. LogStreaming:Warning: Failed to read file '../../../Engine/Content/Slate/SplineFilterTable.png' error. LogStreaming:Warning: Failed to read file '../../../Engine/Content/Slate/Old/White.png' error. LogStreaming:Warning: Failed to read file '../../../Engine/Content/Slate/Common/BoxShadow.png' error. ... -- 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] i965: Remove blorp unit tests.
On Wed, May 14, 2014 at 03:19:36PM -0700, Matt Turner wrote: > They've served their purpose (in transitioning blorp to using > fs_generator) and now they just necessitate large amounts of manual > labor to regenerate if the disassembler changes. > > Cc: Topi Pohjolainen > --- > Deleted file diff removed. > > src/mesa/drivers/dri/i965/.gitignore |1 - > src/mesa/drivers/dri/i965/Makefile.am |7 +- > .../drivers/dri/i965/test_blorp_blit_eu_gen.cpp| 1092 > > 3 files changed, 1 insertion(+), 1099 deletions(-) > delete mode 100644 src/mesa/drivers/dri/i965/test_blorp_blit_eu_gen.cpp Reviewed-by: Topi Pohjolainen > > diff --git a/src/mesa/drivers/dri/i965/.gitignore > b/src/mesa/drivers/dri/i965/.gitignore > index 3cf4ba0..cb66728 100644 > --- a/src/mesa/drivers/dri/i965/.gitignore > +++ b/src/mesa/drivers/dri/i965/.gitignore > @@ -2,4 +2,3 @@ i965_symbols_test > test_eu_compact > test_vec4_copy_propagation > test_vec4_register_coalesce > -test_blorp_blit_eu_gen > diff --git a/src/mesa/drivers/dri/i965/Makefile.am > b/src/mesa/drivers/dri/i965/Makefile.am > index 7ab376c..5809dc6 100644 > --- a/src/mesa/drivers/dri/i965/Makefile.am > +++ b/src/mesa/drivers/dri/i965/Makefile.am > @@ -56,8 +56,7 @@ TEST_LIBS = \ > TESTS = \ > test_eu_compact \ > test_vec4_copy_propagation \ > -test_vec4_register_coalesce \ > -test_blorp_blit_eu_gen > +test_vec4_register_coalesce > > check_PROGRAMS = $(TESTS) > > @@ -77,7 +76,3 @@ test_eu_compact_SOURCES = \ > test_eu_compact.c > nodist_EXTRA_test_eu_compact_SOURCES = dummy.cpp > test_eu_compact_LDADD = $(TEST_LIBS) > - > -test_blorp_blit_eu_gen_SOURCES = \ > -test_blorp_blit_eu_gen.cpp > -test_blorp_blit_eu_gen_LDADD = $(TEST_LIBS) > -- > 1.8.3.2 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glsl: should uniform initializers be allowed in GLSL ES 3.00?
> > While the GLSL ES 3.00 (.4) spec says (The GLSL ES 3.1 spec contains > this wording too) > > All uniform variables are read-only. They are initialized to 0 at link > time and may be updated through the API. > So I think we're correct in disallowing it. > Ok, fair enough. /me shakes fist at the list of "removed from 3.30" GLSL spec section not mentioning it. Chalk it up to another trivial divergence of ES in unexpected way. > Ian, does it seem like we can make a really trivial extension that > gives you back the wording in the Desktop GLSL spec? Are there other > interactions we need to think about? There's already wording > explicitly disallowing initializing samplers in a shader. > Probably not worth it then. Everyone will have to support "no initializers" case for the foreseeable future if that's what all current implementations do. Thanks for the info! -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/12] gallivm: Use LLVM global context.
Hi, On Wednesday, May 14, 2014 02:45:26 Jose Fonseca wrote: > If you rebase it on top of my series it can be reduced to merely this: Ok, thanks that is actually great news, as this gives me something to work with. > In other words, we'd be introducing leaks for sake of thread-safety. I care > more for memory leaks than thread safety, but I can easily flip > USE_GLOBAL_CONTEXT internally. Ok, I can buy that. So, given that, it might be useful to mention that one can trade thread safety against leaks with toggling this define. > For now I'm going to commit my patch series as is, as I want feedback if it > causes any problems, as it is now. After I commit the series, if you could > verify that switching USE_GLOBAL_CONTEXT to 0 fixes multi-threading for you, > then I'd be happy to commit it after a few weeks. I can test this change this evening, but I won't hold back your series. It will be no worse than before and the rest of the series is highly useful stuff. But up to now I had this nebulous comment not giving enough information to see how a proper fix might look like and something that at least fixes what I could observe. One option that I can think of would be to have one such LLVM context per GL context instead of per gallivm (I realized some time ago that this is not equivalent). That should reduce the amount leaking objects to something that grows roughly with the number of created GL contexts instead of the number of compiles. Appart from getting a correct fix, could this be also an option for you? Thanks Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78716] Fix Mesa bugs for running Unreal Engine 4.1 Cave effects demo compiled for Linux
https://bugs.freedesktop.org/show_bug.cgi?id=78716 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #4 from Michel Dänzer --- (In reply to comment #3) > OK finally got it going. Demo may need compute and tesselation support (?) Neither of which are available in OpenGL 3.x or exposed as extensions by Mesa. So the demo's GL 3.2 profile seems buggy to say the least, assuming it can work at all without OpenGL 4.x functionality. I suggest reporting this to Epic, and filing other reports here for any actual Mesa bugs you find. -- 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] i965: Remove blorp unit tests.
On 05/14/2014 03:19 PM, Matt Turner wrote: > They've served their purpose (in transitioning blorp to using > fs_generator) and now they just necessitate large amounts of manual > labor to regenerate if the disassembler changes. > > Cc: Topi Pohjolainen > --- > Deleted file diff removed. > > src/mesa/drivers/dri/i965/.gitignore |1 - > src/mesa/drivers/dri/i965/Makefile.am |7 +- > .../drivers/dri/i965/test_blorp_blit_eu_gen.cpp| 1092 > > 3 files changed, 1 insertion(+), 1099 deletions(-) > delete mode 100644 src/mesa/drivers/dri/i965/test_blorp_blit_eu_gen.cpp > > diff --git a/src/mesa/drivers/dri/i965/.gitignore > b/src/mesa/drivers/dri/i965/.gitignore > index 3cf4ba0..cb66728 100644 > --- a/src/mesa/drivers/dri/i965/.gitignore > +++ b/src/mesa/drivers/dri/i965/.gitignore > @@ -2,4 +2,3 @@ i965_symbols_test > test_eu_compact > test_vec4_copy_propagation > test_vec4_register_coalesce > -test_blorp_blit_eu_gen > diff --git a/src/mesa/drivers/dri/i965/Makefile.am > b/src/mesa/drivers/dri/i965/Makefile.am > index 7ab376c..5809dc6 100644 > --- a/src/mesa/drivers/dri/i965/Makefile.am > +++ b/src/mesa/drivers/dri/i965/Makefile.am > @@ -56,8 +56,7 @@ TEST_LIBS = \ > TESTS = \ > test_eu_compact \ > test_vec4_copy_propagation \ > -test_vec4_register_coalesce \ > -test_blorp_blit_eu_gen > +test_vec4_register_coalesce > > check_PROGRAMS = $(TESTS) > > @@ -77,7 +76,3 @@ test_eu_compact_SOURCES = \ > test_eu_compact.c > nodist_EXTRA_test_eu_compact_SOURCES = dummy.cpp > test_eu_compact_LDADD = $(TEST_LIBS) > - > -test_blorp_blit_eu_gen_SOURCES = \ > -test_blorp_blit_eu_gen.cpp > -test_blorp_blit_eu_gen_LDADD = $(TEST_LIBS) > Sounds good to me. They were useful at the time, but I think the ongoing burden of maintaining them is not worth it. Acked-by: Kenneth Graunke signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965 meta up/downsample: Fix renderbuffer _BaseFormat
mt->format is of type mesa_format, and therefore can't be used with _mesa_base_fbo_format which requires a GLenum input. On gen8, this fixes various piglit fbo-depthstencil tests with samples > 1. Signed-off-by: Jordan Justen Cc: Topi Pohjolainen Cc: Kenneth Graunke --- This was tested on Ken's broadwell branch, which includes Topi's recent gen8 stencil series, but the patch is based on the current master tree. src/mesa/drivers/dri/i965/brw_meta_updownsample.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_meta_updownsample.c b/src/mesa/drivers/dri/i965/brw_meta_updownsample.c index de25bf4..a35b7e1 100644 --- a/src/mesa/drivers/dri/i965/brw_meta_updownsample.c +++ b/src/mesa/drivers/dri/i965/brw_meta_updownsample.c @@ -27,6 +27,7 @@ #include "main/blit.h" #include "main/buffers.h" +#include "main/enums.h" #include "main/fbobject.h" #include "drivers/common/meta.h" @@ -62,7 +63,7 @@ brw_get_rb_for_first_slice(struct brw_context *brw, struct intel_mipmap_tree *mt irb = intel_renderbuffer(rb); rb->Format = mt->format; - rb->_BaseFormat = _mesa_base_fbo_format(ctx, mt->format); + rb->_BaseFormat = _mesa_get_format_base_format(mt->format); rb->NumSamples = mt->num_samples; rb->Width = mt->logical_width0; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965 meta up/downsample: Fix renderbuffer _BaseFormat
On 05/14/2014 11:39 PM, Jordan Justen wrote: > mt->format is of type mesa_format, and therefore can't be > used with _mesa_base_fbo_format which requires a GLenum input. > > On gen8, this fixes various piglit fbo-depthstencil tests with > samples > 1. > > Signed-off-by: Jordan Justen > Cc: Topi Pohjolainen > Cc: Kenneth Graunke > --- > This was tested on Ken's broadwell branch, which includes > Topi's recent gen8 stencil series, but the patch is based > on the current master tree. > > src/mesa/drivers/dri/i965/brw_meta_updownsample.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_meta_updownsample.c > b/src/mesa/drivers/dri/i965/brw_meta_updownsample.c > index de25bf4..a35b7e1 100644 > --- a/src/mesa/drivers/dri/i965/brw_meta_updownsample.c > +++ b/src/mesa/drivers/dri/i965/brw_meta_updownsample.c > @@ -27,6 +27,7 @@ > > #include "main/blit.h" > #include "main/buffers.h" > +#include "main/enums.h" > #include "main/fbobject.h" > > #include "drivers/common/meta.h" > @@ -62,7 +63,7 @@ brw_get_rb_for_first_slice(struct brw_context *brw, struct > intel_mipmap_tree *mt > irb = intel_renderbuffer(rb); > > rb->Format = mt->format; > - rb->_BaseFormat = _mesa_base_fbo_format(ctx, mt->format); > + rb->_BaseFormat = _mesa_get_format_base_format(mt->format); > > rb->NumSamples = mt->num_samples; > rb->Width = mt->logical_width0; > Man, I wish we had type safety. Reviewed-by: Kenneth Graunke signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
