[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 bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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/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/src/gallium/auxiliary/tgsi/tgsi_info.c
> @@ -142,7 +142,7 @@ static const struct tgsi_opcode_info 
> opcode_info[TGSI_OPCODE_LAST] =
> { 0, 0, 0, 0, 0, 1, 0, NONE, "ENDSUB", TGSI_OPCODE_ENDSUB },
> { 1, 1, 1, 0, 0, 0, 0, OTHR, "TXQ_LZ", TGSI_OPCODE_TXQ_LZ },
> { 1, 1, 1, 0, 0, 0, 0, OTHR, "TXQS", TGSI_OPCODE_TXQS },
> -   { 1, 1, 0, 0, 0, 0, 0, NONE, "RESQ", TGSI_OPCODE_RESQ },
> +   { 1, 1, 0, 0, 0, 0, 0, OTHR, "RESQ", TGSI_OPCODE_RESQ },
> { 0, 0, 0, 0, 0, 0, 0, NONE, "", 106 }, /* removed */
> { 0, 0, 0, 0, 0, 0, 0, NONE, "NOP", TGSI_OPCODE_NOP },
> { 1, 2, 0, 0, 0, 0, 0, COMP, "FSEQ", TGSI_OPCODE_FSEQ },
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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 one. With a comment somewhere about that in the code, so that
some enterprising person doesn't go around reordering things, this is

Reviewed-by: Ilia Mirkin 

> ---
>  src/mesa/state_tracker/st_atom.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_atom.c 
> b/src/mesa/state_tracker/st_atom.c
> index 622621b..73b10ba 100644
> --- a/src/mesa/state_tracker/st_atom.c
> +++ b/src/mesa/state_tracker/st_atom.c
> @@ -62,6 +62,11 @@ static const struct st_tracked_state *render_atoms[] =
> _update_tessctrl_texture,
> _update_tesseval_texture,
> _update_sampler, /* depends on update_*_texture for swizzle */
> +   _bind_vs_images,
> +   _bind_tcs_images,
> +   _bind_tes_images,
> +   _bind_gs_images,
> +   _bind_fs_images,
> _update_framebuffer,
> _update_msaa,
> _update_sample_shading,
> @@ -85,11 +90,6 @@ static const struct st_tracked_state *render_atoms[] =
> _bind_tes_ssbos,
> _bind_fs_ssbos,
> _bind_gs_ssbos,
> -   _bind_vs_images,
> -   _bind_tcs_images,
> -   _bind_tes_images,
> -   _bind_gs_images,
> -   _bind_fs_images,
> _update_pixel_transfer,
> _update_tess,
>
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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 up that's not ready for merging such
as amdgpu or our recently pushed Vulkan driver.  However, those should only
be temporary and removed once the work is complete.  I saw a "broadwell"
branch in there which is probably at least 2 years old and completely
subsumed by master.  We don't want to be archiving random junk in the main
tree.

I'd be fine with a timeout system where non-release branches get the boot
after a certain amount inactivity. If you want to archive something, that's
what personal git repos are for.
--Jason

> BR,
> -R
>
> On Mon, Jun 22, 2015 at 2:23 PM, Marek Olšák  wrote:
> > It's not so important now that the amdgpu driver is about to be merged.
> >
> > Speaking of other branches, I think removing the old feature branches
> > is a good idea.
> >
> > Marek
> >
> > On Mon, Jun 22, 2015 at 8:02 PM, Ian Romanick 
wrote:
> >> On 06/22/2015 10:40 AM, Marek Olšák wrote:
> >>> I will happily remove the branch after the kernel driver lands.
> >>>
> >>> I also wonder why all Mesa developers can force-push branches in Mesa
> >>> but not libdrm.
> >>
> >> That's probably just historical.  We probably ought to restrict that on
> >> Mesa as well.
> >>
> >> It sounds like you guys have some requirements for a shared repo.  It
> >> seems like a repo on fd.o could work.  I think you'd just need a
> >> "amddevs" group and make the repo group rwx.  I thought fd.o GIT did
> >> https (maybe just SSH?).
> >>
> >>> Marek
> >>>
> >>> On Mon, Jun 22, 2015 at 5:39 PM, Ilia Mirkin 
wrote:
>  On Mon, Jun 22, 2015 at 11:30 AM, Christian König
>   wrote:
> > On 22.06.2015 15:41, Ilia Mirkin wrote:
> >>
> >> On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard 
wrote:
> >>>
> >>> On Mon, Jun 22, 2015 at 12:23:54PM +0200, Marek Olšák wrote:
> 
>  On Mon, Jun 22, 2015 at 5:36 AM, Ilia Mirkin <
imir...@alum.mit.edu>
>  wrote:
> >
> > On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer <
mic...@daenzer.net>
> > wrote:
> >>
> >> On 22.06.2015 00:31, Ilia Mirkin wrote:
> >>>
> >>> On Sun, Jun 21, 2015 at 12:22 PM, Emil Velikov
> >>>  wrote:
> 
>  On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
> >
> > Ilia Mirkin  writes:
> >
> >> Hello,
> >>
> >> There are a *ton* of branches in the upstream mesa git.
Here is a
> >> full list:
> >>
> > [...]
> >>
> >> is there
> >> any reason to keep these around with the exception of:
> >>
> >> master
> >> $version (i.e. 9.0, 10.0, mesa_7_7_branch, etc)
> >
> > Instead of outright deleting old branches, it would be
possible to
> > set
> > up an "archive" repository which mirrors all branches of
the main
> > repository. And then delete "obsolete" branches only from
the main
> > repository. Ideally, you would want a git hook to refuse to
create
> > a new
> > branch (in the main repository) if a branch by that name
already
> > exists
> > in the archive repository. Possibly with the exception that
> > creating a
> > same-named branch on the same commit would be allowed.
> >
> > (And the same for tags, of course)
> >
>  Personally I am fine with either approach - stay/nuke/move.
But I'm
>  thinking that having a mix of the two suggestions might be a
nice
>  middle
>  ground.
> 
>  Write a script that nukes branches that are merged in master
(check
>  the
>  top commit of the branch) and have an 'archive' repo that
contains
>  everything else (minus the stable branches).
> >>
> >> Sounds good to me, FWIW.
> >>
> >>
> >>> That still leaves a ton around, and curiously removes
mesa_7_5 and
> >>> mesa_7_6.
> >>
> >> I think the latter is expected, we were using a different
branching
> >> model back in those days.
> >>
> >>
> >>> origin/amdgpu
> >>
> >> Note that this is a currently active branch, to be merged to
master
> >> soon.
> >
> > Perhaps there's something I don't understand, but why is a
feature
>

[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/src/gallium/auxiliary/tgsi/tgsi_info.c
@@ -142,7 +142,7 @@ static const struct tgsi_opcode_info 
opcode_info[TGSI_OPCODE_LAST] =
{ 0, 0, 0, 0, 0, 1, 0, NONE, "ENDSUB", TGSI_OPCODE_ENDSUB },
{ 1, 1, 1, 0, 0, 0, 0, OTHR, "TXQ_LZ", TGSI_OPCODE_TXQ_LZ },
{ 1, 1, 1, 0, 0, 0, 0, OTHR, "TXQS", TGSI_OPCODE_TXQS },
-   { 1, 1, 0, 0, 0, 0, 0, NONE, "RESQ", TGSI_OPCODE_RESQ },
+   { 1, 1, 0, 0, 0, 0, 0, OTHR, "RESQ", TGSI_OPCODE_RESQ },
{ 0, 0, 0, 0, 0, 0, 0, NONE, "", 106 }, /* removed */
{ 0, 0, 0, 0, 0, 0, 0, NONE, "NOP", TGSI_OPCODE_NOP },
{ 1, 2, 0, 0, 0, 0, 0, COMP, "FSEQ", TGSI_OPCODE_FSEQ },
-- 
2.5.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[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 insertions(+), 5 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom.c b/src/mesa/state_tracker/st_atom.c
index 622621b..73b10ba 100644
--- a/src/mesa/state_tracker/st_atom.c
+++ b/src/mesa/state_tracker/st_atom.c
@@ -62,6 +62,11 @@ static const struct st_tracked_state *render_atoms[] =
_update_tessctrl_texture,
_update_tesseval_texture,
_update_sampler, /* depends on update_*_texture for swizzle */
+   _bind_vs_images,
+   _bind_tcs_images,
+   _bind_tes_images,
+   _bind_gs_images,
+   _bind_fs_images,
_update_framebuffer,
_update_msaa,
_update_sample_shading,
@@ -85,11 +90,6 @@ static const struct st_tracked_state *render_atoms[] =
_bind_tes_ssbos,
_bind_fs_ssbos,
_bind_gs_ssbos,
-   _bind_vs_images,
-   _bind_tcs_images,
-   _bind_tes_images,
-   _bind_gs_images,
-   _bind_fs_images,
_update_pixel_transfer,
_update_tess,
 
-- 
2.5.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/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 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.c 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.c
index 1cbe47c..614c655 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.c
@@ -315,7 +315,7 @@ lp_build_tgsi_inst_llvm(
   }
}
 
-   if (info->num_dst > 0) {
+   if (info->num_dst > 0 && info->opcode != TGSI_OPCODE_STORE) {
   bld_base->emit_store(bld_base, inst, info, emit_data.output);
}
return TRUE;
-- 
2.5.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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 the amdgpu driver is about to be merged.
>
> Speaking of other branches, I think removing the old feature branches
> is a good idea.
>
> Marek
>
> On Mon, Jun 22, 2015 at 8:02 PM, Ian Romanick  wrote:
>> On 06/22/2015 10:40 AM, Marek Olšák wrote:
>>> I will happily remove the branch after the kernel driver lands.
>>>
>>> I also wonder why all Mesa developers can force-push branches in Mesa
>>> but not libdrm.
>>
>> That's probably just historical.  We probably ought to restrict that on
>> Mesa as well.
>>
>> It sounds like you guys have some requirements for a shared repo.  It
>> seems like a repo on fd.o could work.  I think you'd just need a
>> "amddevs" group and make the repo group rwx.  I thought fd.o GIT did
>> https (maybe just SSH?).
>>
>>> Marek
>>>
>>> On Mon, Jun 22, 2015 at 5:39 PM, Ilia Mirkin  wrote:
 On Mon, Jun 22, 2015 at 11:30 AM, Christian König
  wrote:
> On 22.06.2015 15:41, Ilia Mirkin wrote:
>>
>> On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard  wrote:
>>>
>>> On Mon, Jun 22, 2015 at 12:23:54PM +0200, Marek Olšák wrote:

 On Mon, Jun 22, 2015 at 5:36 AM, Ilia Mirkin 
 wrote:
>
> On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer 
> wrote:
>>
>> On 22.06.2015 00:31, Ilia Mirkin wrote:
>>>
>>> On Sun, Jun 21, 2015 at 12:22 PM, Emil Velikov
>>>  wrote:

 On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
>
> Ilia Mirkin  writes:
>
>> Hello,
>>
>> There are a *ton* of branches in the upstream mesa git. Here is a
>> full list:
>>
> [...]
>>
>> is there
>> any reason to keep these around with the exception of:
>>
>> master
>> $version (i.e. 9.0, 10.0, mesa_7_7_branch, etc)
>
> Instead of outright deleting old branches, it would be possible to
> set
> up an "archive" repository which mirrors all branches of the main
> repository. And then delete "obsolete" branches only from the main
> repository. Ideally, you would want a git hook to refuse to create
> a new
> branch (in the main repository) if a branch by that name already
> exists
> in the archive repository. Possibly with the exception that
> creating a
> same-named branch on the same commit would be allowed.
>
> (And the same for tags, of course)
>
 Personally I am fine with either approach - stay/nuke/move. But I'm
 thinking that having a mix of the two suggestions might be a nice
 middle
 ground.

 Write a script that nukes branches that are merged in master (check
 the
 top commit of the branch) and have an 'archive' repo that contains
 everything else (minus the stable branches).
>>
>> Sounds good to me, FWIW.
>>
>>
>>> That still leaves a ton around, and curiously removes mesa_7_5 and
>>> mesa_7_6.
>>
>> I think the latter is expected, we were using a different branching
>> model back in those days.
>>
>>
>>> origin/amdgpu
>>
>> Note that this is a currently active branch, to be merged to master
>> soon.
>
> Perhaps there's something I don't understand, but why is a feature
> branch made available on the shared tree? In my view of things the
> only branches on the shared mesa.git tree should be the version
> branches.

 As you can see, a lot of feature branches are in the shared tree
 already, so there is a precedent. Sharing a branch among people in
 this way sometimes tends to be more convenient.

 The reason here is that it's the only mesa repository where most
 people from our team have commit access.

>>> Also, the shared git tree supports https access, which means it is
>>> accessible when behind a firewall.
>>
>> OK, well if that's the prevailing attitude, then I'm on a fool's
>> errand, and I'll just drop this.
>
>
> I still think it would be a good idea to archive the branches after a

[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 the ANDROID_extension_pack_es31a

 src/mesa/main/extensions_table.h | 2 +-
 src/mesa/main/texparam.c | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index e4ca2b6..74cb3d8 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -248,7 +248,7 @@ EXT(EXT_texture_object  , dummy_true
 EXT(EXT_texture_rectangle   , NV_texture_rectangle 
  , GLL,  x ,  x ,  x , 2004)
 EXT(EXT_texture_rg  , ARB_texture_rg   
  ,  x ,  x ,  x , ES2, 2011)
 EXT(EXT_texture_sRGB, EXT_texture_sRGB 
  , GLL, GLC,  x ,  x , 2004)
-EXT(EXT_texture_sRGB_decode , EXT_texture_sRGB_decode  
  , GLL, GLC,  x ,  x , 2006)
+EXT(EXT_texture_sRGB_decode , EXT_texture_sRGB_decode  
  , GLL, GLC,  x ,  30, 2006)
 EXT(EXT_texture_shared_exponent , EXT_texture_shared_exponent  
  , GLL, GLC,  x ,  x , 2004)
 EXT(EXT_texture_snorm   , EXT_texture_snorm
  , GLL, GLC,  x ,  x , 2009)
 EXT(EXT_texture_swizzle , EXT_texture_swizzle  
  , GLL, GLC,  x ,  x , 2008)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index 20770a7..3b769f4 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -568,8 +568,7 @@ set_tex_parameteri(struct gl_context *ctx,
   goto invalid_pname;
 
case GL_TEXTURE_SRGB_DECODE_EXT:
-  if (_mesa_is_desktop_gl(ctx)
-  && ctx->Extensions.EXT_texture_sRGB_decode) {
+  if (ctx->Extensions.EXT_texture_sRGB_decode) {
  GLenum decode = params[0];
 
  if (!target_allows_setting_sampler_parameters(texObj->Target))
-- 
2.4.10

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[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 |  2 +-
 src/compiler/glsl/builtin_functions.cpp  | 12 +++-
 src/compiler/glsl/glcpp/glcpp-parse.y|  4 +++-
 src/compiler/glsl/glsl_lexer.ll  |  2 +-
 src/compiler/glsl/glsl_parser_extras.cpp |  1 +
 src/compiler/glsl/glsl_parser_extras.h   |  2 ++
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/get.c  |  5 +
 src/mesa/main/get_hash_params.py | 14 --
 9 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index e7d40de..437c296 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -251,7 +251,7 @@ GLES3.2, GLSL ES 3.2
   GL_OES_sample_variables  DONE (nvc0, r600, 
radeonsi)
   GL_OES_shader_image_atomic   not started (based on 
parts of GL_ARB_shader_image_load_store, which is done for some drivers)
   GL_OES_shader_io_blocks  not started (based on 
parts of GLSL 1.50, which is done)
-  GL_OES_shader_multisample_interpolation  not started (based on 
parts of GL_ARB_gpu_shader5, which is done)
+  GL_OES_shader_multisample_interpolation  DONE (nvc0, r600, 
radeonsi)
   GL_OES_tessellation_shader   not started (based on 
GL_ARB_tessellation_shader, which is done for some drivers)
   GL_OES_texture_border_clamp  DONE (all drivers)
   GL_OES_texture_buffernot started (based on 
GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_range, and 
GL_ARB_texture_buffer_object_rgb32 that are all done)
diff --git a/src/compiler/glsl/builtin_functions.cpp 
b/src/compiler/glsl/builtin_functions.cpp
index d4dc271..60a7293 100644
--- a/src/compiler/glsl/builtin_functions.cpp
+++ b/src/compiler/glsl/builtin_functions.cpp
@@ -269,10 +269,12 @@ shader_packing_or_es31_or_gpu_shader5(const 
_mesa_glsl_parse_state *state)
 }
 
 static bool
-fs_gpu_shader5(const _mesa_glsl_parse_state *state)
+fs_interpolate_at(const _mesa_glsl_parse_state *state)
 {
return state->stage == MESA_SHADER_FRAGMENT &&
-  (state->is_version(400, 0) || state->ARB_gpu_shader5_enable);
+  (state->is_version(400, 320) ||
+   state->ARB_gpu_shader5_enable ||
+   state->OES_shader_multisample_interpolation_enable);
 }
 
 
@@ -5221,7 +5223,7 @@ builtin_builder::_interpolateAtCentroid(const glsl_type 
*type)
 {
ir_variable *interpolant = in_var(type, "interpolant");
interpolant->data.must_be_shader_input = 1;
-   MAKE_SIG(type, fs_gpu_shader5, 1, interpolant);
+   MAKE_SIG(type, fs_interpolate_at, 1, interpolant);
 
body.emit(ret(interpolate_at_centroid(interpolant)));
 
@@ -5234,7 +5236,7 @@ builtin_builder::_interpolateAtOffset(const glsl_type 
*type)
ir_variable *interpolant = in_var(type, "interpolant");
interpolant->data.must_be_shader_input = 1;
ir_variable *offset = in_var(glsl_type::vec2_type, "offset");
-   MAKE_SIG(type, fs_gpu_shader5, 2, interpolant, offset);
+   MAKE_SIG(type, fs_interpolate_at, 2, interpolant, offset);
 
body.emit(ret(interpolate_at_offset(interpolant, offset)));
 
@@ -5247,7 +5249,7 @@ builtin_builder::_interpolateAtSample(const glsl_type 
*type)
ir_variable *interpolant = in_var(type, "interpolant");
interpolant->data.must_be_shader_input = 1;
ir_variable *sample_num = in_var(glsl_type::int_type, "sample_num");
-   MAKE_SIG(type, fs_gpu_shader5, 2, interpolant, sample_num);
+   MAKE_SIG(type, fs_interpolate_at, 2, interpolant, sample_num);
 
body.emit(ret(interpolate_at_sample(interpolant, sample_num)));
 
diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y 
b/src/compiler/glsl/glcpp/glcpp-parse.y
index e4c003a..aeccfc2 100644
--- a/src/compiler/glsl/glcpp/glcpp-parse.y
+++ b/src/compiler/glsl/glcpp/glcpp-parse.y
@@ -2383,8 +2383,10 @@ _glcpp_parser_handle_version_declaration(glcpp_parser_t 
*parser, intmax_t versio
   if (extensions != NULL) {
  if (extensions->OES_EGL_image_external)
 add_builtin_define(parser, "GL_OES_EGL_image_external", 1);
-  if (extensions->OES_sample_variables)
+  if (extensions->OES_sample_variables) {
  add_builtin_define(parser, "GL_OES_sample_variables", 1);
+ add_builtin_define(parser, 
"GL_OES_shader_multisample_interpolation", 1);
+  }
   if (extensions->OES_standard_derivatives)
  add_builtin_define(parser, "GL_OES_standard_derivatives", 1);
   if (extensions->ARB_texture_multisample)
diff --git a/src/compiler/glsl/glsl_lexer.ll

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 b/src/compiler/glsl/
ast_to_hir.cpp
> index 75abef6..db5ec9a 100644
> --- a/src/compiler/glsl/ast_to_hir.cpp
> +++ b/src/compiler/glsl/ast_to_hir.cpp
> @@ -231,15 +231,14 @@ _mesa_ast_to_hir(exec_list *instructions, struct 
_mesa_glsl_parse_state *state)
>  
>  
>  static ir_expression_operation
> -get_conversion_operation(const glsl_type *to, const glsl_type *from,
> - struct _mesa_glsl_parse_state *state)
> +get_implicit_conversion_operation(const glsl_type *to, const glsl_type 
*from,
> +  struct _mesa_glsl_parse_state *state)
>  {
> switch (to->base_type) {
> case GLSL_TYPE_FLOAT:
>switch (from->base_type) {
>case GLSL_TYPE_INT: return ir_unop_i2f;
>case GLSL_TYPE_UINT: return ir_unop_u2f;
> -  case GLSL_TYPE_DOUBLE: return ir_unop_d2f;
>default: return (ir_expression_operation)0;
>}
>  
> @@ -311,7 +310,7 @@ apply_implicit_conversion(const glsl_type *to, ir_rvalue 
* ,
> to = glsl_type::get_instance(to->base_type, from->type->vector_elements,
>  from->type->matrix_columns);
>  
> -   ir_expression_operation op = get_conversion_operation(to, from->type, 
state);
> +   ir_expression_operation op = get_implicit_conversion_operation(to, from-
>type, state);
> if (op) {
>from = new(ctx) ir_expression(op, to, from, NULL);
>return true;
> 

Reviewed-by: Kenneth Graunke 


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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 --git a/docs/envvars.html b/docs/envvars.html
> index ba83335..d7697e3 100644
> --- a/docs/envvars.html
> +++ b/docs/envvars.html
> @@ -224,7 +224,7 @@ See src/mesa/state_tracker/st_debug.c for other
> options.
>  LP_PERF - a comma-separated list of options to selectively
> no-op various
>  parts of the driver.  See the source code for details.
>  LP_NUM_THREADS - an integer indicating how many threads to use
> for rendering.
> -Zero turns of threading completely.  The default value is the
> number of CPU
> +Zero turns off threading completely.  The default value is the
> number of CPU
>  cores present.
>  
> 
> --
> 2.5.0
> 
> 
> A gentle ping?
> 
> I will also need another developer to push this commit once r-b'ed.
> 

I've pushed this, thanks.

Roland


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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
> @@ -224,7 +224,7 @@ See src/mesa/state_tracker/st_debug.c for other
> options.
>  LP_PERF - a comma-separated list of options to selectively no-op
> various
>  parts of the driver.  See the source code for details.
>  LP_NUM_THREADS - an integer indicating how many threads to use for
> rendering.
> -Zero turns of threading completely.  The default value is the number
> of CPU
> +Zero turns off threading completely.  The default value is the number
> of CPU
>  cores present.
>  
>
> --
> 2.5.0
>
>
A gentle ping?

I will also need another developer to push this commit once r-b'ed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[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/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -231,15 +231,14 @@ _mesa_ast_to_hir(exec_list *instructions, struct 
_mesa_glsl_parse_state *state)
 
 
 static ir_expression_operation
-get_conversion_operation(const glsl_type *to, const glsl_type *from,
- struct _mesa_glsl_parse_state *state)
+get_implicit_conversion_operation(const glsl_type *to, const glsl_type *from,
+  struct _mesa_glsl_parse_state *state)
 {
switch (to->base_type) {
case GLSL_TYPE_FLOAT:
   switch (from->base_type) {
   case GLSL_TYPE_INT: return ir_unop_i2f;
   case GLSL_TYPE_UINT: return ir_unop_u2f;
-  case GLSL_TYPE_DOUBLE: return ir_unop_d2f;
   default: return (ir_expression_operation)0;
   }
 
@@ -311,7 +310,7 @@ apply_implicit_conversion(const glsl_type *to, ir_rvalue * 
,
to = glsl_type::get_instance(to->base_type, from->type->vector_elements,
 from->type->matrix_columns);
 
-   ir_expression_operation op = get_conversion_operation(to, from->type, 
state);
+   ir_expression_operation op = get_implicit_conversion_operation(to, 
from->type, state);
if (op) {
   from = new(ctx) ir_expression(op, to, from, NULL);
   return true;
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[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.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev