[Mesa-dev] [Bug 94040] clGetPlatformIDs causes futex race condition

2016-02-20 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=94040 --- Comment #12 from Francisco Jerez --- Thanks. Could you check if this workaround from an earlier bug report helps? https://bugs.freedesktop.org/attachment.cgi?id=117708 -- You are receiving this mail because: You are the assignee for the b

Re: [Mesa-dev] [PATCH 1/3] tgsi: set correct output mode for RESQ

2016-02-20 Thread Ilia Mirkin
Acked-by: Ilia Mirkin (not sure enough about how these things get used for a full r-b) On Sat, Feb 20, 2016 at 4:39 PM, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > --- > src/gallium/auxiliary/tgsi/tgsi_info.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/ga

Re: [Mesa-dev] [PATCH 3/3] st/mesa: shader image atoms must be before framebuffer update

2016-02-20 Thread Ilia Mirkin
On Sat, Feb 20, 2016 at 4:39 PM, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > The reason is that the shader image atoms call st_finalize_texture, which > may set ST_NEW_FRAMEBUFFER. > > This fixes an assertion triggered by a subtest of piglit's > arb_shader_image_load_store-invalid. Ah good

Re: [Mesa-dev] abundance of branches in mesa.git

2016-02-20 Thread Jason Ekstrand
On Feb 20, 2016 1:19 PM, "Rob Clark" wrote: > > fwiw, I think a *small* number of topic branches in certain cases > makes sense.. I'm definitely in support of a TTL limit (ie. > automatically nuke topic branches with no activity in N months, or > similar..) I agree. Sometimes something big comes

[Mesa-dev] [PATCH 1/3] tgsi: set correct output mode for RESQ

2016-02-20 Thread Nicolai Hähnle
From: Nicolai Hähnle --- src/gallium/auxiliary/tgsi/tgsi_info.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c b/src/gallium/auxiliary/tgsi/tgsi_info.c index 70fc460..462bd15 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_info.c +++ b/sr

[Mesa-dev] [PATCH 3/3] st/mesa: shader image atoms must be before framebuffer update

2016-02-20 Thread Nicolai Hähnle
From: Nicolai Hähnle The reason is that the shader image atoms call st_finalize_texture, which may set ST_NEW_FRAMEBUFFER. This fixes an assertion triggered by a subtest of piglit's arb_shader_image_load_store-invalid. --- src/mesa/state_tracker/st_atom.c | 10 +- 1 file changed, 5 inse

[Mesa-dev] [PATCH 0/3] gallium: image-related fixes

2016-02-20 Thread Nicolai Hähnle
Hi, I wanted to get these small fixes from my images branch out in front of people before I disappear for a while on vacation. Especially the last one should also be relevant for other Gallium-based drivers. Please review. Thanks, Nicolai ___ mesa-dev

[Mesa-dev] [PATCH 2/3] gallivm: special case TGSI_OPCODE_STORE

2016-02-20 Thread Nicolai Hähnle
From: Nicolai Hähnle This instruction has the resource (buffer or image) as a destination to represent the writemask for SSBO writes. However, this is obviously not a "real" destination for the purpose of emitting LLVM IR. --- src/gallium/auxiliary/gallivm/lp_bld_tgsi.c | 2 +- 1 file changed, 1

Re: [Mesa-dev] abundance of branches in mesa.git

2016-02-20 Thread Rob Clark
fwiw, I think a *small* number of topic branches in certain cases makes sense.. I'm definitely in support of a TTL limit (ie. automatically nuke topic branches with no activity in N months, or similar..) BR, -R On Mon, Jun 22, 2015 at 2:23 PM, Marek Olšák wrote: > It's not so important now that

[Mesa-dev] [PATCH] mesa: expose GL_EXT_texture_sRGB_decode on GLES 3.0+

2016-02-20 Thread Ilia Mirkin
Could be exposed on earlier GLES versions if we supported EXT_sRGB, but we don't, for now. Signed-off-by: Ilia Mirkin --- Passes all the relevant dEQP tests (although they only test state, not the actual decoding... but those bits are mostly ctx-agnostic paths). Note that this ext is part of th

[Mesa-dev] [PATCH] mesa: add GL_OES_shader_multisample_interpolation support

2016-02-20 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin --- dEQP tests mostly pass... they reveal some pre-existing issues with packed varyings and interpolateAt* - the interpolants become temporaries, which breaks everything. However fixing this should be unrelated to enabling this extension. docs/GL3.txt

Re: [Mesa-dev] [PATCH] glsl/ast: Implicit conversion from double to float is not allowed

2016-02-20 Thread Kenneth Graunke
On Saturday, February 20, 2016 1:30:46 PM PST Andres Gomez wrote: > Also, renamed get_conversion_operation to avoid > future misunderstandings. > --- > src/compiler/glsl/ast_to_hir.cpp | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/src/compiler/glsl/ast_to_hir.cpp

Re: [Mesa-dev] [PATCH] docs: Correct typo in LLVMpipe envvar description

2016-02-20 Thread Roland Scheidegger
Am 20.02.2016 um 13:28 schrieb Rhys Kidd: > On 13 February 2016 at 15:41, Rhys Kidd > wrote: > > Signed-off-by: Rhys Kidd > > --- > docs/envvars.html | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff -

Re: [Mesa-dev] [PATCH] docs: Correct typo in LLVMpipe envvar description

2016-02-20 Thread Rhys Kidd
On 13 February 2016 at 15:41, Rhys Kidd wrote: > Signed-off-by: Rhys Kidd > --- > docs/envvars.html | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/docs/envvars.html b/docs/envvars.html > index ba83335..d7697e3 100644 > --- a/docs/envvars.html > +++ b/docs/envvars.html

[Mesa-dev] [PATCH] glsl/ast: Implicit conversion from double to float is not allowed

2016-02-20 Thread Andres Gomez
Also, renamed get_conversion_operation to avoid future misunderstandings. --- src/compiler/glsl/ast_to_hir.cpp | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp index 75abef6..db5ec9a 100644 --- a/src/comp

[Mesa-dev] [Bug 94195] [llvmpipe] Does not build with LLVM 3.7.x on Windows

2016-02-20 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=94195 --- Comment #2 from Emil Velikov --- There will be at least another to versions for the 11.1 branch. Thanks for the report - I'll pick the patch for the next release. -- You are receiving this mail because: You are the QA Contact for the bug. Y