date:20181221

[Mesa-dev] [Bug 109131] cc1plus: error: unrecognized command line option "-std=c++11"

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=109131

Bug ID: 109131
   Summary: cc1plus: error: unrecognized command line option
"-std=c++11"
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: bisected, regression
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: baker.dyla...@gmail.com, emil.l.veli...@gmail.com

CXXgallivm/lp_bld_debug.lo
cc1plus: error: unrecognized command line option "-std=c++11"

commit 12187550f9c248e72ed8848e96da8f29f1e3a713
Author: Emil Velikov 
Date:   Thu Dec 13 11:56:40 2018 +

configure: add CXX11_CXXFLAGS to LLVM_CXXFLAGS

Seemingly with LLVM7 and GCC 5.0, the former won't properly advertise
-std=c++11 and the latter will choke.

dd this temporary workaround, otherwise we'll get errors like:

In file included from /usr/include/c++/5/type_traits:35:0,
 from
/usr/lib/llvm-7/include/llvm/Support/type_traits.h:18,
 from /usr/lib/llvm-7/include/llvm/ADT/Optional.h:22,
 from /usr/lib/llvm-7/include/llvm/ADT/STLExtras.h:20,
 from /usr/lib/llvm-7/include/llvm/ADT/StringRef.h:13,
 from
/usr/lib/llvm-7/include/llvm/Target/TargetMachine.h:17,
 from ../../../src/amd/common/ac_llvm_helper.cpp:36:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file
requires compiler and library support for the ISO C++ 2011 standard. This
support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.

Signed-off-by: Emil Velikov 
Reviewed-by: Dylan Baker 

-- 
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

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

2018-12-21 Thread Rob Clark

On Fri, Dec 21, 2018 at 11:37 AM Lionel Landwerlin
 wrote:
>
> On 19/12/2018 17:19, Kenneth Graunke wrote:
> > On Wednesday, December 19, 2018 8:10:49 AM PST Eric Engestrom wrote:
> >> The point of this patch is for people to not be able to ignore this, and
> >> have to become aware of the existence of Meson and our intention to
> >> remove autotools, whenever this may happen.
> >>
> >> Some people have already noticed, probably because they keep up with
> >> mesa-dev@, but the point is that some people haven't.
> >>
> >> Without this patch:
> >> - people will continue being unaware, until
> >> - autotools gets removed, and these people are going to try their
> >>use-cases, and probably find issues
> >> - issues will get fixed, hopefully quickly, but blocking them completely
> >>in the mean time
> >>
> >> With this patch:
> >> - people will *have to notice* that something's changing
> >> - they'll choose to either ignore it, use the flag, and *choose* to go
> >>with the option above
> >> - or they can choose to try meson, get any issues fixed *while still
> >>being able to work with their old setup in the mean time*
> >>
> >> This last bit is the entire point of this patch, so let me repeat it:
> >> people will report meson issues while there's still time to use their
> >> old autotools setup.
> >>
> >> I'm definitely in favour:
> >> Acked-by: Eric Engestrom 
> > Eric's reasoning here makes sense.  In case there is anyone out there
> > who has been putting off trying Meson, this will properly exhort them
> > to try it, and identify any problems, yet still let them continue using
> > their old system for a little while longer.
> >
> > Acked-by: Kenneth Graunke 
> >
> > I've been using Meson for a long time, and it is dramatically better to
> > work with - both to write, and to use.  It is a little bit different,
> > and that took some getting used to.  But it was absolutely worth it.
> >
> > We need a way to make progress here.  Matt's concern is very valid -
> > people can simply keep moving the goal posts.  And that's incredibly
> > frustrating for the people doing the work.
> >
> > Given that we've had the Meson build system for over a year, I think
> > time is up.  Marek once received review feedback to a patch a year after
> > he wrote it, and he responded with something like "I've moved on, feel
> > free to write a patch."  I think that applies here.  The Meson build has
> > had many contributors at this point.  If it's not good enough, feel free
> > to help fix it.  It's worth noting that it is good enough for the major
> > distros, which have switched, and a large portion of the community uses
> > it exclusively.  Dylan has done a ton of work to upstream Meson to
> > address our needs and improve the usability of the project.  The rest
> > of the Meson developers have been very responsible as well.  We have
> > every reason to believe it will keep getting better.
> >
> > We can't keep kicking the autotools can down the road indefinitely.
> > We need a forcing function like this patch, then eventual removal.
> > Expecting new contributors to write 4 build systems is just...bad.
> > I'm hopeful that we can get down to two (Meson and Android) soon.
> >
> > For what it's worth, I'm hoping to merge Iris soon, and it does not have
> > an autotools build system, nor do I intend to write one.  At that point,
> > you won't be able to build the new Intel OpenGL drivers with autotools.
> >
> > --Ken
>
> I very much agree with Ken here.
> Autotools has been a pain to deal with especially since we had to
> maintain 2 build systems.
> We already have part of our tools that do not get built with Autotools.
> I think the main reason being that debugging Meson builds is a lot
> faster that Autotools ones.
> So I would be happy if we could send a signal that this will go soon and
> strongly recommend users to tell us what isn't working.
>
> Just finally adding that pretty big projects like systemd (only uses
> Meson), GLib (both Meson/Autotools, but Meson default) and a bunch of
> other Gnome stuff is now being built with Meson in major distros (just
> checked Debian which also builds Mesa using Meson), so it seems to me at
> least a significant part of the community won't be very surprised.
> And this patch is the call for people who haven't noticed yet.
>
> Acked-by: Lionel Landwerlin 
>

I also agree that maintaining 2 build systems (well, actually 3
because android) is major pita, and meson is much nicer to deal with
than autotools.  I think the approach that this patch is taking, to a
little more actively push people who haven't tried meson to give it a
try and speak up if something is missing, is extremely reasonable and
far more conservative than what a lot of other projects have done.

Acked-by: Rob Clark 

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

Re: [Mesa-dev] [PATCH 1/3] st/mesa: Make an enum for pipeline statistics query result indices.

2018-12-21 Thread Roland Scheidegger

Am 22.12.18 um 01:21 schrieb Ilia Mirkin:
> 
> 
> On Fri, Dec 21, 2018, 19:16 Marek Olšák   wrote:
> 
> 
> 
> On Fri, Dec 21, 2018, 6:28 PM Kenneth Graunke   wrote:
> 
> That seems like a reasonable interface to me.
> 
> But, I don't think it's backwards compatible.  Today, don't state
> trackers set index = 0 and expect all 11 to be returned?  We could
> easily change the in-tree state trackers, but not sure about the
> other ones.
> 
> We could always encode the index differently, but at that point, I
> wonder if it would be cleaner to just add a new query type like Ilia
> suggested.
> 
> Marek, what would you prefer?
> 
> 
> Backward compatibility is not required. Gallium is not a stable API.
> In tree state trackers can be fixed easily. We shouldn't worry too
> much about closed source state trackers.
> 
> 
> Fwiw my take is that while it's fine to change apis around (we do this
> all the time), we should avoid causing a loss of functionality just
> because no in-tree state tracker uses it. I think having a
> forward-looking gallium API greatly facilitated GL 3 and 4 bringup of
> gallium drivers, even though there wasn't necessarily an in-tree way to
> access all the functionality at the time.
> 
> As long as all the previously accessible functionality remains, I think
> we're fine.

Yes, I agree. Certainly it isn't a problem for us to change the supplied
index to the query.
Although it is usually better if interface changes are not just
semantically different, but also syntactically, to avoid surprises - you
know there's always just this odd place in the code which for some
reason you failed to change, and a compile error is much better than
strange failures later (this is of course even more true for out-of-tree
state trackers). But this might not always be feasible, keeping the
interface nice should take priority. (There's not really any hard rules
for gallium interface changes, that's just my take on it.)

Roland



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

Re: [Mesa-dev] [PATCH 1/3] st/mesa: Make an enum for pipeline statistics query result indices.

2018-12-21 Thread Ilia Mirkin

On Fri, Dec 21, 2018, 19:16 Marek Olšák 
>
> On Fri, Dec 21, 2018, 6:28 PM Kenneth Graunke  wrote:
>
>> That seems like a reasonable interface to me.
>>
>> But, I don't think it's backwards compatible.  Today, don't state
>> trackers set index = 0 and expect all 11 to be returned?  We could
>> easily change the in-tree state trackers, but not sure about the
>> other ones.
>>
>> We could always encode the index differently, but at that point, I
>> wonder if it would be cleaner to just add a new query type like Ilia
>> suggested.
>>
>> Marek, what would you prefer?
>>
>
> Backward compatibility is not required. Gallium is not a stable API. In
> tree state trackers can be fixed easily. We shouldn't worry too much about
> closed source state trackers.
>

Fwiw my take is that while it's fine to change apis around (we do this all
the time), we should avoid causing a loss of functionality just because no
in-tree state tracker uses it. I think having a forward-looking gallium API
greatly facilitated GL 3 and 4 bringup of gallium drivers, even though
there wasn't necessarily an in-tree way to access all the functionality at
the time.

As long as all the previously accessible functionality remains, I think
we're fine.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] st/mesa: Make an enum for pipeline statistics query result indices.

2018-12-21 Thread Marek Olšák

On Fri, Dec 21, 2018, 6:28 PM Kenneth Graunke  That seems like a reasonable interface to me.
>
> But, I don't think it's backwards compatible.  Today, don't state
> trackers set index = 0 and expect all 11 to be returned?  We could
> easily change the in-tree state trackers, but not sure about the
> other ones.
>
> We could always encode the index differently, but at that point, I
> wonder if it would be cleaner to just add a new query type like Ilia
> suggested.
>
> Marek, what would you prefer?
>

Backward compatibility is not required. Gallium is not a stable API. In
tree state trackers can be fixed easily. We shouldn't worry too much about
closed source state trackers.

Marek


> --Ken
>
> On Friday, December 21, 2018 1:24:32 PM PST Marek Olšák wrote:
> > The series looks good. Another way to distinguish between return one and
> > return all is to use "index". index <= 11 returns one. index == ~0
> returns
> > all. This is the least intrusive.
> >
> > st/mesa and gallium/hud always want to get one.
> > st/nine and util/u_helpers always want to get all.
> >
> > Marek
> >
> > On Sat, Dec 15, 2018 at 4:45 AM Kenneth Graunke 
> > wrote:
> >
> > > Gallium handles pipeline statistics queries as a single query
> > > (PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values.
> > > Sometimes it's useful to refer to each of those values individually,
> > > rather than as a group.  To avoid hardcoding numbers, we define a new
> > > enum for each value.  Here, the name and enum value correspond to the
> > > index in the struct pipe_query_data_pipeline_statistics result.
> > >
> > > Cc: Roland Scheidegger 
> > > ---
> > >  src/gallium/include/pipe/p_defines.h| 17 +
> > >  src/mesa/state_tracker/st_cb_queryobj.c | 22 +++---
> > >  2 files changed, 28 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/src/gallium/include/pipe/p_defines.h
> > > b/src/gallium/include/pipe/p_defines.h
> > > index 6d96f1ccb5b..21005955a36 100644
> > > --- a/src/gallium/include/pipe/p_defines.h
> > > +++ b/src/gallium/include/pipe/p_defines.h
> > > @@ -568,6 +568,23 @@ enum pipe_query_type {
> > > PIPE_QUERY_DRIVER_SPECIFIC = 256,
> > >  };
> > >
> > > +/**
> > > + * Index for PIPE_QUERY_PIPELINE_STATISTICS subqueries.
> > > + */
> > > +enum pipe_statistics_query_index {
> > > +   PIPE_STAT_QUERY_IA_VERTICES,
> > > +   PIPE_STAT_QUERY_IA_PRIMITIVES,
> > > +   PIPE_STAT_QUERY_VS_INVOCATIONS,
> > > +   PIPE_STAT_QUERY_GS_INVOCATIONS,
> > > +   PIPE_STAT_QUERY_GS_PRIMITIVES,
> > > +   PIPE_STAT_QUERY_C_INVOCATIONS,
> > > +   PIPE_STAT_QUERY_C_PRIMITIVES,
> > > +   PIPE_STAT_QUERY_PS_INVOCATIONS,
> > > +   PIPE_STAT_QUERY_HS_INVOCATIONS,
> > > +   PIPE_STAT_QUERY_DS_INVOCATIONS,
> > > +   PIPE_STAT_QUERY_CS_INVOCATIONS,
> > > +};
> > > +
> > >  /**
> > >   * Conditional rendering modes
> > >   */
> > > diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
> > > b/src/mesa/state_tracker/st_cb_queryobj.c
> > > index 69e6004c3f1..82f53243336 100644
> > > --- a/src/mesa/state_tracker/st_cb_queryobj.c
> > > +++ b/src/mesa/state_tracker/st_cb_queryobj.c
> > > @@ -386,37 +386,37 @@ st_StoreQueryResult(struct gl_context *ctx,
> struct
> > > gl_query_object *q,
> > > } else if (stq->type == PIPE_QUERY_PIPELINE_STATISTICS) {
> > >switch (q->Target) {
> > >case GL_VERTICES_SUBMITTED_ARB:
> > > - index = 0;
> > > + index = PIPE_STAT_QUERY_IA_VERTICES;
> > >   break;
> > >case GL_PRIMITIVES_SUBMITTED_ARB:
> > > - index = 1;
> > > + index = PIPE_STAT_QUERY_IA_PRIMITIVES;
> > >   break;
> > >case GL_VERTEX_SHADER_INVOCATIONS_ARB:
> > > - index = 2;
> > > + index = PIPE_STAT_QUERY_VS_INVOCATIONS;
> > >   break;
> > >case GL_GEOMETRY_SHADER_INVOCATIONS:
> > > - index = 3;
> > > + index = PIPE_STAT_QUERY_GS_INVOCATIONS;
> > >   break;
> > >case GL_GEOMETRY_SHADER_PRIMITIVES_EMITTED_ARB:
> > > - index = 4;
> > > + index = PIPE_STAT_QUERY_GS_PRIMITIVES;
> > >   break;
> > >case GL_CLIPPING_INPUT_PRIMITIVES_ARB:
> > > - index = 5;
> > > + index = PIPE_STAT_QUERY_C_INVOCATIONS;
> > >   break;
> > >case GL_CLIPPING_OUTPUT_PRIMITIVES_ARB:
> > > - index = 6;
> > > + index = PIPE_STAT_QUERY_C_PRIMITIVES;
> > >   break;
> > >case GL_FRAGMENT_SHADER_INVOCATIONS_ARB:
> > > - index = 7;
> > > + index = PIPE_STAT_QUERY_PS_INVOCATIONS;
> > >   break;
> > >case GL_TESS_CONTROL_SHADER_PATCHES_ARB:
> > > - index = 8;
> > > + index = PIPE_STAT_QUERY_HS_INVOCATIONS;
> > >   break;
> > >case GL_TESS_EVALUATION_SHADER_INVOCATIONS_ARB:
> > > - index = 9;
> > > + index = PIPE_STAT_QUERY_DS_INVOCATIONS;
> > >   break;
> > >case GL_COMPUTE_SHADER_INVOCATIONS_ARB:
> > > - index = 10;
> >

Re: [Mesa-dev] [PATCH] intel/compiler: move nir_lower_bool_to_int32 before nir_lower_locals_to_regs

2018-12-21 Thread Rob Clark

jfyi, should be fixed by:

https://gitlab.freedesktop.org/mesa/mesa/commit/3453814622040d2638ce7b7c73c046cd4a0119e9

I'm a bit surprised we didn't notice issues sooner

BR,
-R


On Fri, Dec 21, 2018 at 12:39 PM Kristian Høgsberg  wrote:
>
> This regresses at least
> dEQP-GLES3.functional.shaders.functions.control_flow.return_in_loop_vertex
> on freedreno:
>
> Test case 
> 'dEQP-GLES3.functional.shaders.functions.control_flow.return_in_loop_vertex'..
> deqp-gles3: ../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:49:
> lower_alu_instr: Assertion `alu->dest.dest.is_ssa' failed.
>
> Program received signal SIGABRT, Aborted.
> __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
> 47  ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file
> or directory.
> (gdb) bt
> #0  __libc_do_syscall () at 
> ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
> #1  0xf7cee18e in __libc_signal_restore_set (set=0xfffee2dc) at
> ../sysdeps/unix/sysv/linux/nptl-signals.h:80
> #2  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
> #3  0xf7ceef12 in __GI_abort () at abort.c:79
> #4  0xf7ce8e84 in __assert_fail_base (fmt=0xf7da3fdc "%s%s%s:%u:
> %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x
> , file=0xf7ae6d48
> "../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c",
> file@entry=0xf7c5d010 "", line=49, line@entry=4158390024,
> function=function@entry=0xf7b6be60 <__PRETTY_FUNCTION__.24316>
> "lower_alu_instr") at assert.c:92
> #5  0xf7ce8f22 in __GI___assert_fail (assertion=0x  Cannot access memory at address 0x>, file=0xf7c5d010 "",
> line=4158390024, line@entry=49, function=0xf7b6be60
> <__PRETTY_FUNCTION__.24316> "lower_alu_instr") at assert.c:101
> #6  0xf78f08ca in lower_alu_instr (alu=0xf7dbff08 ) at
> ../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:49
> #7  nir_lower_bool_to_int32_impl (impl=0xf8e378) at
> ../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:114
> #8  nir_lower_bool_to_int32 (shader=) at
> ../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:157
> #9  0xf7a97584 in ir3_context_init (compiler=0xbe31c0,
> so=so@entry=0xf97378) at
> ../../../mesa/src/freedreno/ir3/ir3_context.c:80
> #10 0xf7a95f58 in ir3_compile_shader_nir (compiler=,
> so=so@entry=0xf97378) at
> ../../../mesa/src/freedreno/ir3/ir3_compiler_nir.c:2994
> #11 0xf7aa1adc in create_variant (shader=shader@entry=0xf9fe60,
> key=key@entry=0xfffee764, binning_pass=binning_pass@entry=true) at
> ../../../mesa/src/freedreno/ir3/ir3_shader.c:182
> #12 0xf7aa1d9c in ir3_shader_get_variant (shader=0xf9fe60,
> key=key@entry=0xfffee764, binning_pass=,
> created=0xfffee743, created@entry=0xfffee723) at
> ../../../mesa/src/freedreno/ir3/ir3_shader.c:233
> #13 0xf7a88068 in ir3_shader_variant (shader=, key=...,
> binning_pass=binning_pass@entry=true, debug=debug@entry=0xc9a794) at
> ../../../../../mesa/src/gallium/drivers/freedreno/ir3/ir3_gallium.c:86
> #14 0xf7a87a74 in ir3_cache_lookup (cache=0xc89520,
> key=key@entry=0xfffee844, debug=debug@entry=0xc9a794) at
> ../../../../../mesa/src/gallium/drivers/freedreno/ir3/ir3_cache.c:96
> #15 0xf7a7ad6e in fd6_emit_get_prog (emit=0xfffee838) at
> ../../../../../mesa/src/gallium/drivers/freedreno/a6xx/fd6_emit.h:103
> #16 fd6_draw_vbo (ctx=0xc95ca0, info=0xfffeea70, index_offset=80) at
> ../../../../../mesa/src/gallium/drivers/freedreno/a6xx/fd6_draw.c:186
> #17 0xf7a4551a in fd_draw_vbo (pctx=, info=0xfffeea70)
> at ../../../../../mesa/src/gallium/drivers/freedreno/freedreno_draw.c:291
> #18 0xf79f8802 in u_vbuf_draw_vbo (mgr=,
> info=) at
> ../../../../mesa/src/gallium/auxiliary/util/u_vbuf.c:1449
> #19 0xf77d2f42 in st_draw_vbo (ctx=, prims=0xfffeed54,
> nr_prims=, ib=0xfffeed44, index_bounds_valid=0 '\000',
> min_index=0, max_index=3, tfb_vertcount=0x0, stream=0, indirect=0x0)
> at ../../../mesa/src/mesa/state_tracker/st_draw.c:268
> #20 0xf766b338 in _mesa_validated_drawrangeelements (ctx=0xca3e00,
> mode=mode@entry=4, index_bounds_valid=,
> start=, end=end@entry=4294967295, count=count@entry=6,
> type=type@entry=5123, indices=indices@entry=0xac3d60, basevertex=0,
> numInstances=numInstances@entry=1, baseInstance=0) at
> ../../../mesa/src/mesa/main/draw.c:849
> #21 0xf766c36a in _mesa_validated_drawrangeelements (baseInstance=0,
> numInstances=1, basevertex=0, indices=0xac3d60, type=5123, count=6,
> end=4294967295, start=0, index_bounds_valid=0 '\000', mode=4,
> ctx=) at ../../../mesa/src/mesa/main/draw.c:768
> #22 _mesa_DrawElements (mode=4, count=6, type=5123, indices=0xac3d60)
> at ../../../mesa/src/mesa/main/draw.c:1003
> #23 0x008f4e94 in _start ()
>
> Kristian
>
> On Wed, Dec 19, 2018 at 12:16 AM Iago Toral Quiroga  wrote:
> >
> > The former expects to see SSA-only things, but the latter injects registers.
> >
> > The assertions in the lowering where not seeing this because they asserted
> > on the bit_size values only, not on the is_ssa field, so add that assertion
> >

Re: [Mesa-dev] [PATCH 1/3] st/mesa: Make an enum for pipeline statistics query result indices.

2018-12-21 Thread Kenneth Graunke

That seems like a reasonable interface to me.

But, I don't think it's backwards compatible.  Today, don't state
trackers set index = 0 and expect all 11 to be returned?  We could
easily change the in-tree state trackers, but not sure about the
other ones.

We could always encode the index differently, but at that point, I
wonder if it would be cleaner to just add a new query type like Ilia
suggested.

Marek, what would you prefer?

--Ken

On Friday, December 21, 2018 1:24:32 PM PST Marek Olšák wrote:
> The series looks good. Another way to distinguish between return one and
> return all is to use "index". index <= 11 returns one. index == ~0 returns
> all. This is the least intrusive.
> 
> st/mesa and gallium/hud always want to get one.
> st/nine and util/u_helpers always want to get all.
> 
> Marek
> 
> On Sat, Dec 15, 2018 at 4:45 AM Kenneth Graunke 
> wrote:
> 
> > Gallium handles pipeline statistics queries as a single query
> > (PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values.
> > Sometimes it's useful to refer to each of those values individually,
> > rather than as a group.  To avoid hardcoding numbers, we define a new
> > enum for each value.  Here, the name and enum value correspond to the
> > index in the struct pipe_query_data_pipeline_statistics result.
> >
> > Cc: Roland Scheidegger 
> > ---
> >  src/gallium/include/pipe/p_defines.h| 17 +
> >  src/mesa/state_tracker/st_cb_queryobj.c | 22 +++---
> >  2 files changed, 28 insertions(+), 11 deletions(-)
> >
> > diff --git a/src/gallium/include/pipe/p_defines.h
> > b/src/gallium/include/pipe/p_defines.h
> > index 6d96f1ccb5b..21005955a36 100644
> > --- a/src/gallium/include/pipe/p_defines.h
> > +++ b/src/gallium/include/pipe/p_defines.h
> > @@ -568,6 +568,23 @@ enum pipe_query_type {
> > PIPE_QUERY_DRIVER_SPECIFIC = 256,
> >  };
> >
> > +/**
> > + * Index for PIPE_QUERY_PIPELINE_STATISTICS subqueries.
> > + */
> > +enum pipe_statistics_query_index {
> > +   PIPE_STAT_QUERY_IA_VERTICES,
> > +   PIPE_STAT_QUERY_IA_PRIMITIVES,
> > +   PIPE_STAT_QUERY_VS_INVOCATIONS,
> > +   PIPE_STAT_QUERY_GS_INVOCATIONS,
> > +   PIPE_STAT_QUERY_GS_PRIMITIVES,
> > +   PIPE_STAT_QUERY_C_INVOCATIONS,
> > +   PIPE_STAT_QUERY_C_PRIMITIVES,
> > +   PIPE_STAT_QUERY_PS_INVOCATIONS,
> > +   PIPE_STAT_QUERY_HS_INVOCATIONS,
> > +   PIPE_STAT_QUERY_DS_INVOCATIONS,
> > +   PIPE_STAT_QUERY_CS_INVOCATIONS,
> > +};
> > +
> >  /**
> >   * Conditional rendering modes
> >   */
> > diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
> > b/src/mesa/state_tracker/st_cb_queryobj.c
> > index 69e6004c3f1..82f53243336 100644
> > --- a/src/mesa/state_tracker/st_cb_queryobj.c
> > +++ b/src/mesa/state_tracker/st_cb_queryobj.c
> > @@ -386,37 +386,37 @@ st_StoreQueryResult(struct gl_context *ctx, struct
> > gl_query_object *q,
> > } else if (stq->type == PIPE_QUERY_PIPELINE_STATISTICS) {
> >switch (q->Target) {
> >case GL_VERTICES_SUBMITTED_ARB:
> > - index = 0;
> > + index = PIPE_STAT_QUERY_IA_VERTICES;
> >   break;
> >case GL_PRIMITIVES_SUBMITTED_ARB:
> > - index = 1;
> > + index = PIPE_STAT_QUERY_IA_PRIMITIVES;
> >   break;
> >case GL_VERTEX_SHADER_INVOCATIONS_ARB:
> > - index = 2;
> > + index = PIPE_STAT_QUERY_VS_INVOCATIONS;
> >   break;
> >case GL_GEOMETRY_SHADER_INVOCATIONS:
> > - index = 3;
> > + index = PIPE_STAT_QUERY_GS_INVOCATIONS;
> >   break;
> >case GL_GEOMETRY_SHADER_PRIMITIVES_EMITTED_ARB:
> > - index = 4;
> > + index = PIPE_STAT_QUERY_GS_PRIMITIVES;
> >   break;
> >case GL_CLIPPING_INPUT_PRIMITIVES_ARB:
> > - index = 5;
> > + index = PIPE_STAT_QUERY_C_INVOCATIONS;
> >   break;
> >case GL_CLIPPING_OUTPUT_PRIMITIVES_ARB:
> > - index = 6;
> > + index = PIPE_STAT_QUERY_C_PRIMITIVES;
> >   break;
> >case GL_FRAGMENT_SHADER_INVOCATIONS_ARB:
> > - index = 7;
> > + index = PIPE_STAT_QUERY_PS_INVOCATIONS;
> >   break;
> >case GL_TESS_CONTROL_SHADER_PATCHES_ARB:
> > - index = 8;
> > + index = PIPE_STAT_QUERY_HS_INVOCATIONS;
> >   break;
> >case GL_TESS_EVALUATION_SHADER_INVOCATIONS_ARB:
> > - index = 9;
> > + index = PIPE_STAT_QUERY_DS_INVOCATIONS;
> >   break;
> >case GL_COMPUTE_SHADER_INVOCATIONS_ARB:
> > - index = 10;
> > + index = PIPE_STAT_QUERY_CS_INVOCATIONS;
> >   break;
> >default:
> >   unreachable("Unexpected target");
> > --
> > 2.19.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> 



signature.asc
Description: This is a digitally signed message part.
___
mesa-dev

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=109062

--- Comment #16 from Ilia Mirkin  ---
(In reply to Emil Velikov from comment #15)
> It started with a confusing error message and upon closer look behaviour
> seemed fairly different from what you guys wanted.
> 
> Since the current solution is OK you guys, please ignore me.
> 
> Thanks for the input Ilia. Closing as NOTABUG

The other thing to note is that the only realistic way for this scenario to
occur is to have libdrm v1 in one place and libdrm v2 in another place. If you
allow that to go forth, you would pick libdrm_a from v1, libdrm_b from v2, and
libdrm from which version? I don't think there's a right answer to that
question generically, so IMHO this scenario should just be avoided.

The fix in autotools you referenced was to ensure that e.g. intel wanting a
thing in libdrm core would actually get picked up by the intel_min_version
thing rather than having to bump the super-global libdrm requirement (as that
would affect all drivers).

-- 
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

[Mesa-dev] [Bug 109129] format_types.h:1220: undefined reference to `_mm256_cvtps_ph'

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=109129

Dylan Baker  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |baker.dyla...@gmail.com
   |org |

-- 
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 6/6] st/nir: Drop unused gl_program parameter in VS input handling helper.

2018-12-21 Thread Marek Olšák

For the series:

Reviewed-by: Marek Olšák 

Marek

On Mon, Dec 17, 2018 at 1:37 PM Kenneth Graunke 
wrote:

> Nobody uses this, so let's drop it.  This makes the helper callable
> from places without a gl_program.
> ---
>  src/mesa/state_tracker/st_glsl_to_nir.cpp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> index 7406e26e2f8..5263edc5a6d 100644
> --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> @@ -81,7 +81,7 @@ st_nir_fixup_varying_slots(struct st_context *st, struct
> exec_list *var_list)
>   * on varying-slot w/ the VS outputs)
>   */
>  static void
> -st_nir_assign_vs_in_locations(struct gl_program *prog, nir_shader *nir)
> +st_nir_assign_vs_in_locations(nir_shader *nir)
>  {
> nir->num_inputs = 0;
> nir_foreach_variable_safe(var, >inputs) {
> @@ -810,7 +810,7 @@ st_finalize_nir(struct st_context *st, struct
> gl_program *prog,
>
> if (nir->info.stage == MESA_SHADER_VERTEX) {
>/* Needs special handling so drvloc matches the vbo state: */
> -  st_nir_assign_vs_in_locations(prog, nir);
> +  st_nir_assign_vs_in_locations(nir);
>/* Re-lower global vars, to deal with any dead VS inputs. */
>NIR_PASS_V(nir, nir_lower_global_vars_to_local);
>
> --
> 2.19.1
>
> ___
> 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

[Mesa-dev] [Bug 109129] format_types.h:1220: undefined reference to `_mm256_cvtps_ph'

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=109129

--- Comment #2 from Dylan Baker  ---
Indeed, it seems to be fixed by that patch. I'm planning to make 0.49.1
required for using ICC once it's out anyway (due to a lot of fixes in 0.49.0
and the fix to this in 0.49.1

-- 
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] st/mesa: Make an enum for pipeline statistics query result indices.

2018-12-21 Thread Marek Olšák

The series looks good. Another way to distinguish between return one and
return all is to use "index". index <= 11 returns one. index == ~0 returns
all. This is the least intrusive.

st/mesa and gallium/hud always want to get one.
st/nine and util/u_helpers always want to get all.

Marek

On Sat, Dec 15, 2018 at 4:45 AM Kenneth Graunke 
wrote:

> Gallium handles pipeline statistics queries as a single query
> (PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values.
> Sometimes it's useful to refer to each of those values individually,
> rather than as a group.  To avoid hardcoding numbers, we define a new
> enum for each value.  Here, the name and enum value correspond to the
> index in the struct pipe_query_data_pipeline_statistics result.
>
> Cc: Roland Scheidegger 
> ---
>  src/gallium/include/pipe/p_defines.h| 17 +
>  src/mesa/state_tracker/st_cb_queryobj.c | 22 +++---
>  2 files changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/include/pipe/p_defines.h
> b/src/gallium/include/pipe/p_defines.h
> index 6d96f1ccb5b..21005955a36 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -568,6 +568,23 @@ enum pipe_query_type {
> PIPE_QUERY_DRIVER_SPECIFIC = 256,
>  };
>
> +/**
> + * Index for PIPE_QUERY_PIPELINE_STATISTICS subqueries.
> + */
> +enum pipe_statistics_query_index {
> +   PIPE_STAT_QUERY_IA_VERTICES,
> +   PIPE_STAT_QUERY_IA_PRIMITIVES,
> +   PIPE_STAT_QUERY_VS_INVOCATIONS,
> +   PIPE_STAT_QUERY_GS_INVOCATIONS,
> +   PIPE_STAT_QUERY_GS_PRIMITIVES,
> +   PIPE_STAT_QUERY_C_INVOCATIONS,
> +   PIPE_STAT_QUERY_C_PRIMITIVES,
> +   PIPE_STAT_QUERY_PS_INVOCATIONS,
> +   PIPE_STAT_QUERY_HS_INVOCATIONS,
> +   PIPE_STAT_QUERY_DS_INVOCATIONS,
> +   PIPE_STAT_QUERY_CS_INVOCATIONS,
> +};
> +
>  /**
>   * Conditional rendering modes
>   */
> diff --git a/src/mesa/state_tracker/st_cb_queryobj.c
> b/src/mesa/state_tracker/st_cb_queryobj.c
> index 69e6004c3f1..82f53243336 100644
> --- a/src/mesa/state_tracker/st_cb_queryobj.c
> +++ b/src/mesa/state_tracker/st_cb_queryobj.c
> @@ -386,37 +386,37 @@ st_StoreQueryResult(struct gl_context *ctx, struct
> gl_query_object *q,
> } else if (stq->type == PIPE_QUERY_PIPELINE_STATISTICS) {
>switch (q->Target) {
>case GL_VERTICES_SUBMITTED_ARB:
> - index = 0;
> + index = PIPE_STAT_QUERY_IA_VERTICES;
>   break;
>case GL_PRIMITIVES_SUBMITTED_ARB:
> - index = 1;
> + index = PIPE_STAT_QUERY_IA_PRIMITIVES;
>   break;
>case GL_VERTEX_SHADER_INVOCATIONS_ARB:
> - index = 2;
> + index = PIPE_STAT_QUERY_VS_INVOCATIONS;
>   break;
>case GL_GEOMETRY_SHADER_INVOCATIONS:
> - index = 3;
> + index = PIPE_STAT_QUERY_GS_INVOCATIONS;
>   break;
>case GL_GEOMETRY_SHADER_PRIMITIVES_EMITTED_ARB:
> - index = 4;
> + index = PIPE_STAT_QUERY_GS_PRIMITIVES;
>   break;
>case GL_CLIPPING_INPUT_PRIMITIVES_ARB:
> - index = 5;
> + index = PIPE_STAT_QUERY_C_INVOCATIONS;
>   break;
>case GL_CLIPPING_OUTPUT_PRIMITIVES_ARB:
> - index = 6;
> + index = PIPE_STAT_QUERY_C_PRIMITIVES;
>   break;
>case GL_FRAGMENT_SHADER_INVOCATIONS_ARB:
> - index = 7;
> + index = PIPE_STAT_QUERY_PS_INVOCATIONS;
>   break;
>case GL_TESS_CONTROL_SHADER_PATCHES_ARB:
> - index = 8;
> + index = PIPE_STAT_QUERY_HS_INVOCATIONS;
>   break;
>case GL_TESS_EVALUATION_SHADER_INVOCATIONS_ARB:
> - index = 9;
> + index = PIPE_STAT_QUERY_DS_INVOCATIONS;
>   break;
>case GL_COMPUTE_SHADER_INVOCATIONS_ARB:
> - index = 10;
> + index = PIPE_STAT_QUERY_CS_INVOCATIONS;
>   break;
>default:
>   unreachable("Unexpected target");
> --
> 2.19.1
>
> ___
> 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] radeonsi: make use of ac_are_tessfactors_def_in_all_invocs()

2018-12-21 Thread Marek Olšák

Nice. For the series:

Reviewed-by: Marek Olšák 

Marek

On Mon, Dec 17, 2018 at 8:18 PM Timothy Arceri 
wrote:

> ---
>  src/gallium/drivers/radeonsi/si_shader_nir.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
> b/src/gallium/drivers/radeonsi/si_shader_nir.c
> index b81bea00b8..931d41245d 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_nir.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
> @@ -285,14 +285,8 @@ void si_nir_scan_tess_ctrl(const struct nir_shader
> *nir,
> if (nir->info.stage != MESA_SHADER_TESS_CTRL)
> return;
>
> -   /* Initial value = true. Here the pass will accumulate results from
> -* multiple segments surrounded by barriers. If tess factors aren't
> -* written at all, it's a shader bug and we don't care if this
> will be
> -* true.
> -*/
> -   out->tessfactors_are_def_in_all_invocs = true;
> -
> -   /* TODO: Implement scanning of tess factors, see tgsi backend. */
> +   out->tessfactors_are_def_in_all_invocs =
> +   ac_are_tessfactors_def_in_all_invocs(nir);
>  }
>
>  void si_nir_scan_shader(const struct nir_shader *nir,
> --
> 2.19.2
>
> ___
> 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 2/2] tgsi/scan: correctly walk instructions in tgsi_scan_tess_ctrl()

2018-12-21 Thread Marek Olšák

For the series:

Reviewed-by: Marek Olšák 

Marek

On Fri, Dec 14, 2018 at 12:33 AM Timothy Arceri 
wrote:

> The previous code used a do while loop and continues after walking
> a nested loop/if-statement. This means we end up evaluating the
> last instruction from the nested block against the while condition
> and potentially exit early if it matches the exit condition of the
> outer block.
>
> Fixes: 386d165d8d09 ("tgsi/scan: add a new pass that analyzes tess factor
> writes")
> ---
> No changes in shader-db. Didn't run against piglit.
>
>  src/gallium/auxiliary/tgsi/tgsi_scan.c | 72 +++---
>  1 file changed, 43 insertions(+), 29 deletions(-)
>
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
> b/src/gallium/auxiliary/tgsi/tgsi_scan.c
> index 6e2e23822c..d56844bdc2 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
> @@ -1028,11 +1028,12 @@ get_block_tessfactor_writemask(const struct
> tgsi_shader_info *info,
> struct tgsi_full_instruction *inst;
> unsigned writemask = 0;
>
> -   do {
> -  tgsi_parse_token(parse);
> -  assert(parse->FullToken.Token.Type == TGSI_TOKEN_TYPE_INSTRUCTION);
> -  inst = >FullToken.FullInstruction;
> -  check_no_subroutines(inst);
> +   tgsi_parse_token(parse);
> +   assert(parse->FullToken.Token.Type == TGSI_TOKEN_TYPE_INSTRUCTION);
> +   inst = >FullToken.FullInstruction;
> +   check_no_subroutines(inst);
> +
> +   while (inst->Instruction.Opcode != end_opcode) {
>
>/* Recursively process nested blocks. */
>switch (inst->Instruction.Opcode) {
> @@ -1040,20 +1041,26 @@ get_block_tessfactor_writemask(const struct
> tgsi_shader_info *info,
>case TGSI_OPCODE_UIF:
>   writemask |=
>  get_block_tessfactor_writemask(info, parse,
> TGSI_OPCODE_ENDIF);
> - continue;
> + break;
>
>case TGSI_OPCODE_BGNLOOP:
>   writemask |=
>  get_block_tessfactor_writemask(info, parse,
> TGSI_OPCODE_ENDLOOP);
> - continue;
> + break;
>
>case TGSI_OPCODE_BARRIER:
>   unreachable("nested BARRIER is illegal");
> - continue;
> + break;
> +
> +  default:
> + writemask |= get_inst_tessfactor_writemask(info, inst);
>}
>
> -  writemask |= get_inst_tessfactor_writemask(info, inst);
> -   } while (inst->Instruction.Opcode != end_opcode);
> +  tgsi_parse_token(parse);
> +  assert(parse->FullToken.Token.Type == TGSI_TOKEN_TYPE_INSTRUCTION);
> +  inst = >FullToken.FullInstruction;
> +  check_no_subroutines(inst);
> +   }
>
> return writemask;
>  }
> @@ -1067,18 +1074,20 @@ get_if_block_tessfactor_writemask(const struct
> tgsi_shader_info *info,
> struct tgsi_full_instruction *inst;
> unsigned then_tessfactor_writemask = 0;
> unsigned else_tessfactor_writemask = 0;
> +   unsigned writemask;
> bool is_then = true;
>
> -   do {
> -  tgsi_parse_token(parse);
> -  assert(parse->FullToken.Token.Type == TGSI_TOKEN_TYPE_INSTRUCTION);
> -  inst = >FullToken.FullInstruction;
> -  check_no_subroutines(inst);
> +   tgsi_parse_token(parse);
> +   assert(parse->FullToken.Token.Type == TGSI_TOKEN_TYPE_INSTRUCTION);
> +   inst = >FullToken.FullInstruction;
> +   check_no_subroutines(inst);
> +
> +   while (inst->Instruction.Opcode != TGSI_OPCODE_ENDIF) {
>
>switch (inst->Instruction.Opcode) {
>case TGSI_OPCODE_ELSE:
>   is_then = false;
> - continue;
> + break;
>
>/* Recursively process nested blocks. */
>case TGSI_OPCODE_IF:
> @@ -1087,28 +1096,33 @@ get_if_block_tessfactor_writemask(const struct
> tgsi_shader_info *info,
> is_then ?
> _tessfactor_writemask :
>
> _tessfactor_writemask,
> cond_block_tf_writemask);
> - continue;
> + break;
>
>case TGSI_OPCODE_BGNLOOP:
>   *cond_block_tf_writemask |=
>  get_block_tessfactor_writemask(info, parse,
> TGSI_OPCODE_ENDLOOP);
> - continue;
> + break;
>
>case TGSI_OPCODE_BARRIER:
>   unreachable("nested BARRIER is illegal");
> - continue;
> -  }
> -
> -  /* Process an instruction in the current block. */
> -  unsigned writemask = get_inst_tessfactor_writemask(info, inst);
> + break;
> +  default:
> + /* Process an instruction in the current block. */
> + writemask = get_inst_tessfactor_writemask(info, inst);
>
> -  if (writemask) {
> - if (is_then)
> -then_tessfactor_writemask |= writemask;
> - else
> -else_tessfactor_writemask |= writemask;
> + if (writemask) {
> +if (is_then)
> +   then_tessfactor_writemask |= writemask;
> +else
> +   else_tessfactor_writemask |= writemask;
> + }
>}
> -   } while

[Mesa-dev] [Bug 109129] format_types.h:1220: undefined reference to `_mm256_cvtps_ph'

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=109129

--- Comment #1 from Dylan Baker  ---
This is likely due to:
https://github.com/mesonbuild/meson/commit/b335ca2818b3cdb770bb69df25ae527d7ae8e7d3.

I'm checking with said patch applied.

-- 
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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=109062

Emil Velikov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #15 from Emil Velikov  ---
It started with a confusing error message and upon closer look behaviour seemed
fairly different from what you guys wanted.

Since the current solution is OK you guys, please ignore me.

Thanks for the input Ilia. Closing as NOTABUG

-- 
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

[Mesa-dev] [Bug 109129] format_types.h:1220: undefined reference to `_mm256_cvtps_ph'

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=109129

Bug ID: 109129
   Summary: format_types.h:1220: undefined reference to
`_mm256_cvtps_ph'
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org

SWR build error with ICC with meson. Build passes with autotools.

'src/gallium/drivers/swr/src@gallium@drivers@swr@@swrAVX2@sha/rasterizer_memory_StoreTile_TileY.cpp.o'
'src/gallium/drivers/swr/src@gallium@drivers@swr@@swrAVX2@sha/rasterizer_memory_InitMemory.cpp.o'
-Wl,--no-undefined -Wl,--as-needed -shared -fPIC -Wl,--start-group
-Wl,-soname,libswrAVX2.so.0 -Wl,--gc-sections -L/usr/lib/llvm-7/lib -lLLVM-7
-Wl,--end-group -pthread  
ld:
src/gallium/drivers/swr/src@gallium@drivers@swr@@swrAVX2@sha/rasterizer_memory_StoreTile_Linear2.cpp.o:
in function `TypeTraits<(SWR_TYPE)6, 16u>::pack(SIMDImpl::SIMD512Impl::Float
const&)':
src/gallium/drivers/swr/rasterizer/core/format_types.h:1220: undefined
reference to `_mm256_cvtps_ph'
ld: src/gallium/drivers/swr/rasterizer/core/format_types.h:1221: undefined
reference to `_mm256_cvtps_ph'

-- 
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

Re: [Mesa-dev] [PATCH] intel/compiler: move nir_lower_bool_to_int32 before nir_lower_locals_to_regs

2018-12-21 Thread Kristian Høgsberg

This regresses at least
dEQP-GLES3.functional.shaders.functions.control_flow.return_in_loop_vertex
on freedreno:

Test case 
'dEQP-GLES3.functional.shaders.functions.control_flow.return_in_loop_vertex'..
deqp-gles3: ../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:49:
lower_alu_instr: Assertion `alu->dest.dest.is_ssa' failed.

Program received signal SIGABRT, Aborted.
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47  ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file
or directory.
(gdb) bt
#0  __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#1  0xf7cee18e in __libc_signal_restore_set (set=0xfffee2dc) at
../sysdeps/unix/sysv/linux/nptl-signals.h:80
#2  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xf7ceef12 in __GI_abort () at abort.c:79
#4  0xf7ce8e84 in __assert_fail_base (fmt=0xf7da3fdc "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x
, file=0xf7ae6d48
"../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c",
file@entry=0xf7c5d010 "", line=49, line@entry=4158390024,
function=function@entry=0xf7b6be60 <__PRETTY_FUNCTION__.24316>
"lower_alu_instr") at assert.c:92
#5  0xf7ce8f22 in __GI___assert_fail (assertion=0x , file=0xf7c5d010 "",
line=4158390024, line@entry=49, function=0xf7b6be60
<__PRETTY_FUNCTION__.24316> "lower_alu_instr") at assert.c:101
#6  0xf78f08ca in lower_alu_instr (alu=0xf7dbff08 ) at
../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:49
#7  nir_lower_bool_to_int32_impl (impl=0xf8e378) at
../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:114
#8  nir_lower_bool_to_int32 (shader=) at
../../../mesa/src/compiler/nir/nir_lower_bool_to_int32.c:157
#9  0xf7a97584 in ir3_context_init (compiler=0xbe31c0,
so=so@entry=0xf97378) at
../../../mesa/src/freedreno/ir3/ir3_context.c:80
#10 0xf7a95f58 in ir3_compile_shader_nir (compiler=,
so=so@entry=0xf97378) at
../../../mesa/src/freedreno/ir3/ir3_compiler_nir.c:2994
#11 0xf7aa1adc in create_variant (shader=shader@entry=0xf9fe60,
key=key@entry=0xfffee764, binning_pass=binning_pass@entry=true) at
../../../mesa/src/freedreno/ir3/ir3_shader.c:182
#12 0xf7aa1d9c in ir3_shader_get_variant (shader=0xf9fe60,
key=key@entry=0xfffee764, binning_pass=,
created=0xfffee743, created@entry=0xfffee723) at
../../../mesa/src/freedreno/ir3/ir3_shader.c:233
#13 0xf7a88068 in ir3_shader_variant (shader=, key=...,
binning_pass=binning_pass@entry=true, debug=debug@entry=0xc9a794) at
../../../../../mesa/src/gallium/drivers/freedreno/ir3/ir3_gallium.c:86
#14 0xf7a87a74 in ir3_cache_lookup (cache=0xc89520,
key=key@entry=0xfffee844, debug=debug@entry=0xc9a794) at
../../../../../mesa/src/gallium/drivers/freedreno/ir3/ir3_cache.c:96
#15 0xf7a7ad6e in fd6_emit_get_prog (emit=0xfffee838) at
../../../../../mesa/src/gallium/drivers/freedreno/a6xx/fd6_emit.h:103
#16 fd6_draw_vbo (ctx=0xc95ca0, info=0xfffeea70, index_offset=80) at
../../../../../mesa/src/gallium/drivers/freedreno/a6xx/fd6_draw.c:186
#17 0xf7a4551a in fd_draw_vbo (pctx=, info=0xfffeea70)
at ../../../../../mesa/src/gallium/drivers/freedreno/freedreno_draw.c:291
#18 0xf79f8802 in u_vbuf_draw_vbo (mgr=,
info=) at
../../../../mesa/src/gallium/auxiliary/util/u_vbuf.c:1449
#19 0xf77d2f42 in st_draw_vbo (ctx=, prims=0xfffeed54,
nr_prims=, ib=0xfffeed44, index_bounds_valid=0 '\000',
min_index=0, max_index=3, tfb_vertcount=0x0, stream=0, indirect=0x0)
at ../../../mesa/src/mesa/state_tracker/st_draw.c:268
#20 0xf766b338 in _mesa_validated_drawrangeelements (ctx=0xca3e00,
mode=mode@entry=4, index_bounds_valid=,
start=, end=end@entry=4294967295, count=count@entry=6,
type=type@entry=5123, indices=indices@entry=0xac3d60, basevertex=0,
numInstances=numInstances@entry=1, baseInstance=0) at
../../../mesa/src/mesa/main/draw.c:849
#21 0xf766c36a in _mesa_validated_drawrangeelements (baseInstance=0,
numInstances=1, basevertex=0, indices=0xac3d60, type=5123, count=6,
end=4294967295, start=0, index_bounds_valid=0 '\000', mode=4,
ctx=) at ../../../mesa/src/mesa/main/draw.c:768
#22 _mesa_DrawElements (mode=4, count=6, type=5123, indices=0xac3d60)
at ../../../mesa/src/mesa/main/draw.c:1003
#23 0x008f4e94 in _start ()

Kristian

On Wed, Dec 19, 2018 at 12:16 AM Iago Toral Quiroga  wrote:
>
> The former expects to see SSA-only things, but the latter injects registers.
>
> The assertions in the lowering where not seeing this because they asserted
> on the bit_size values only, not on the is_ssa field, so add that assertion
> too.
>
> Fixes: 11dc1307794e "nir: Add a bool to int32 lowering pass"
> CC: mesa-sta...@lists.freedesktop.org
> ---
>  src/compiler/nir/nir_lower_bool_to_int32.c | 2 ++
>  src/intel/compiler/brw_nir.c   | 4 ++--
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir/nir_lower_bool_to_int32.c 
> b/src/compiler/nir/nir_lower_bool_to_int32.c
> index 064b27b9025..fdd2f55175d 100644
> ---

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=109062

--- Comment #14 from Dylan Baker  ---
Ilia's explanation is my understanding of the problem, and how we got here. We
do print a message saying that "version x.y.z was required because $driver
requires it" maybe we can make the message better? Such as:

```
libdrm requirements:
  intel : >= 2.4.75
  amdgpu  : >= 2.4.95

globally requiring libdrm 2.4.95 because intel and amd drivers enabled.
```

-- 
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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=109062

--- Comment #13 from Ilia Mirkin  ---
(In reply to Emil Velikov from comment #12)
> Fwiw my suggestion is to follow the autotools build, which was explicitly
> requested by Ilia, Dave and Chad - commit
> 2b4eaabff01a3a8ea0c4742ac481492092c1ab4f.

FWIW, not to dump on Dylan too much, I suspect that the current meson behavior
may be my doing too -- we had this discussion earlier on, and the thing that
meson currently does was the compromise --

It's unreasonable for a system to have different versions of libdrm and
libdrm_foo -- they should all be the same.

Similarly, it is unreasonable to require me to have version X (> Y), when all
I'm doing is building a driver which needs version Y.

So looking at your original issue, you're trying to configure with intel +
amdgpu, and your version isn't enough for amdgpu.

Solution: either update, or don't build with amdgpu.

I suppose the problem is that all you know is "update" -- you don't know that
by simply removing amdgpu, all can be well (and perhaps you don't want amdgpu
in the first place). Not sure what to do about that.

(Did I at least understand the problem correctly?)

-- 
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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=109062

Emil Velikov  changed:

   What|Removed |Added

 CC||airl...@freedesktop.org,
   ||chadvers...@chromium.org,
   ||imir...@alum.mit.edu

--- Comment #12 from Emil Velikov  ---
Fwiw my suggestion is to follow the autotools build, which was explicitly
requested by Ilia, Dave and Chad - commit
2b4eaabff01a3a8ea0c4742ac481492092c1ab4f.

Above ensures that both core and $vendor libs meet the $vendor version
requirement.

AFAICT meson seems to pick the highest version and enforces it everywhere -
core and all used vendors. So for example:
A local nouveau v10, and system amdgpu v5, will meet the requirements, yet
meson will error out expecting amdgpu v10 :-(

That said, as long the guys are happy, I'm fine either way.

-- 
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

Re: [Mesa-dev] [PATCH] pci_ids: add new VegaM pci id

2018-12-21 Thread Liu, Leo

Reviewed-by: Leo Liu 

On 12/21/18 11:36 AM, Alex Deucher wrote:
> Ping?
>
> On Thu, Dec 20, 2018 at 10:13 AM Alex Deucher  wrote:
>> Signed-off-by: Alex Deucher 
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>   include/pci_ids/radeonsi_pci_ids.h | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/include/pci_ids/radeonsi_pci_ids.h 
>> b/include/pci_ids/radeonsi_pci_ids.h
>> index a2bc9213207..75ac7761bb4 100644
>> --- a/include/pci_ids/radeonsi_pci_ids.h
>> +++ b/include/pci_ids/radeonsi_pci_ids.h
>> @@ -219,6 +219,7 @@ CHIPSET(0x699F, POLARIS12)
>>
>>   CHIPSET(0x694C, VEGAM)
>>   CHIPSET(0x694E, VEGAM)
>> +CHIPSET(0x694F, VEGAM)
>>
>>   CHIPSET(0x6860, VEGA10)
>>   CHIPSET(0x6861, VEGA10)
>> --
>> 2.13.6
>>
> ___
> 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] pci_ids: add new VegaM pci id

2018-12-21 Thread Samuel Pitoiset


Feel free to add my Rb if you want to push this now.

Reviewed-by: Samuel Pitoiset 

On 12/20/18 4:12 PM, Alex Deucher wrote:

Signed-off-by: Alex Deucher 
Cc: mesa-sta...@lists.freedesktop.org
---
  include/pci_ids/radeonsi_pci_ids.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/include/pci_ids/radeonsi_pci_ids.h 
b/include/pci_ids/radeonsi_pci_ids.h
index a2bc9213207..75ac7761bb4 100644
--- a/include/pci_ids/radeonsi_pci_ids.h
+++ b/include/pci_ids/radeonsi_pci_ids.h
@@ -219,6 +219,7 @@ CHIPSET(0x699F, POLARIS12)
  
  CHIPSET(0x694C, VEGAM)

  CHIPSET(0x694E, VEGAM)
+CHIPSET(0x694F, VEGAM)
  
  CHIPSET(0x6860, VEGA10)

  CHIPSET(0x6861, VEGA10)


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

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

2018-12-21 Thread Lionel Landwerlin


On 19/12/2018 17:19, Kenneth Graunke wrote:

On Wednesday, December 19, 2018 8:10:49 AM PST Eric Engestrom wrote:

The point of this patch is for people to not be able to ignore this, and
have to become aware of the existence of Meson and our intention to
remove autotools, whenever this may happen.

Some people have already noticed, probably because they keep up with
mesa-dev@, but the point is that some people haven't.

Without this patch:
- people will continue being unaware, until
- autotools gets removed, and these people are going to try their
   use-cases, and probably find issues
- issues will get fixed, hopefully quickly, but blocking them completely
   in the mean time

With this patch:
- people will *have to notice* that something's changing
- they'll choose to either ignore it, use the flag, and *choose* to go
   with the option above
- or they can choose to try meson, get any issues fixed *while still
   being able to work with their old setup in the mean time*

This last bit is the entire point of this patch, so let me repeat it:
people will report meson issues while there's still time to use their
old autotools setup.

I'm definitely in favour:
Acked-by: Eric Engestrom 

Eric's reasoning here makes sense.  In case there is anyone out there
who has been putting off trying Meson, this will properly exhort them
to try it, and identify any problems, yet still let them continue using
their old system for a little while longer.

Acked-by: Kenneth Graunke 

I've been using Meson for a long time, and it is dramatically better to
work with - both to write, and to use.  It is a little bit different,
and that took some getting used to.  But it was absolutely worth it.

We need a way to make progress here.  Matt's concern is very valid -
people can simply keep moving the goal posts.  And that's incredibly
frustrating for the people doing the work.

Given that we've had the Meson build system for over a year, I think
time is up.  Marek once received review feedback to a patch a year after
he wrote it, and he responded with something like "I've moved on, feel
free to write a patch."  I think that applies here.  The Meson build has
had many contributors at this point.  If it's not good enough, feel free
to help fix it.  It's worth noting that it is good enough for the major
distros, which have switched, and a large portion of the community uses
it exclusively.  Dylan has done a ton of work to upstream Meson to
address our needs and improve the usability of the project.  The rest
of the Meson developers have been very responsible as well.  We have
every reason to believe it will keep getting better.

We can't keep kicking the autotools can down the road indefinitely.
We need a forcing function like this patch, then eventual removal.
Expecting new contributors to write 4 build systems is just...bad.
I'm hopeful that we can get down to two (Meson and Android) soon.

For what it's worth, I'm hoping to merge Iris soon, and it does not have
an autotools build system, nor do I intend to write one.  At that point,
you won't be able to build the new Intel OpenGL drivers with autotools.

--Ken


I very much agree with Ken here.
Autotools has been a pain to deal with especially since we had to 
maintain 2 build systems.
We already have part of our tools that do not get built with Autotools. 
I think the main reason being that debugging Meson builds is a lot 
faster that Autotools ones.
So I would be happy if we could send a signal that this will go soon and 
strongly recommend users to tell us what isn't working.


Just finally adding that pretty big projects like systemd (only uses 
Meson), GLib (both Meson/Autotools, but Meson default) and a bunch of 
other Gnome stuff is now being built with Meson in major distros (just 
checked Debian which also builds Mesa using Meson), so it seems to me at 
least a significant part of the community won't be very surprised.

And this patch is the call for people who haven't noticed yet.

Acked-by: Lionel Landwerlin 

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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=109062

--- Comment #11 from Emil Velikov  ---
Right, let's keep multiple [pkg-config] dependencies out of the topic for now.
As you pointed out, there are some glitches that need sorting out.

-- 
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] pci_ids: add new VegaM pci id

2018-12-21 Thread Alex Deucher

Ping?

On Thu, Dec 20, 2018 at 10:13 AM Alex Deucher  wrote:
>
> Signed-off-by: Alex Deucher 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  include/pci_ids/radeonsi_pci_ids.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/pci_ids/radeonsi_pci_ids.h 
> b/include/pci_ids/radeonsi_pci_ids.h
> index a2bc9213207..75ac7761bb4 100644
> --- a/include/pci_ids/radeonsi_pci_ids.h
> +++ b/include/pci_ids/radeonsi_pci_ids.h
> @@ -219,6 +219,7 @@ CHIPSET(0x699F, POLARIS12)
>
>  CHIPSET(0x694C, VEGAM)
>  CHIPSET(0x694E, VEGAM)
> +CHIPSET(0x694F, VEGAM)
>
>  CHIPSET(0x6860, VEGA10)
>  CHIPSET(0x6861, VEGA10)
> --
> 2.13.6
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

2018-12-21 Thread Matt Turner

On Fri, Dec 21, 2018 at 1:36 AM Stuart Young  wrote:
> Yes, but at the moment we have no consensus and a deadlock on the issue.

Consensus need not be unanimous. We have consensus.

Signed-off-by: Gert Wollny 
Reviewed-by: Matt Turner 
Acked-by: Eric Engestrom 
Acked-by: Kenneth Graunke 

and I would probably include Jason and Marek in this group as well,
though they did not offer a *-by.

I don't think there's anything to continue debating, so this will be
my last contribution to the thread.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] docs: update 18.3 and add 19.x cycles for the release calendar

2018-12-21 Thread Juan A. Suarez Romero

On Tue, 2018-12-18 at 01:09 +0200, Andres Gomez wrote:
> Cc: Dylan Baker 
> Cc: Juan A. Suarez 
> Cc: Emil Velikov 
> Signed-off-by: Andres Gomez 
> ---

Acked-by: Juan A. Suarez 


>  docs/release-calendar.html | 118 -
>  1 file changed, 116 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/release-calendar.html b/docs/release-calendar.html
> index 924995c2698..0fbaa22d106 100644
> --- a/docs/release-calendar.html
> +++ b/docs/release-calendar.html
> @@ -45,11 +45,12 @@ if you'd like to nominate a patch in the next stable 
> release.
>  Juan A. Suarez
>  Last planned 18.2.x release
>  
> -18.3
> +
> +18.3
>  2018-12-19
>  18.3.2
>  Emil Velikov
> -
> +
>  
>  
>  2019-01-09
> @@ -67,6 +68,119 @@ if you'd like to nominate a patch in the next stable 
> release.
>  2019-02-06
>  18.3.5
>  Emil Velikov
> +
> +
> +
> +2019-02-20
> +18.3.6
> +Emil Velikov
> +
> +
> +
> +2019-03-06
> +18.3.7
> +Emil Velikov
> +Last planned 18.3.x release
> +
> +
> +19.0
> +2019-01-29
> +19.0.0-rc1
> +Dylan Baker
> +
> +
> +
> +2019-02-05
> +19.0.0-rc2
> +Dylan Baker
> +
> +
> +
> +2019-02-12
> +19.0.0-rc3
> +Dylan Baker
> +
> +
> +
> +2019-02-19
> +19.0.0-rc4
> +Dylan Baker
> +Last planned RC/Final release
> +
> +
> +19.1
> +2019-04-30
> +19.1.0-rc1
> +Andres Gomez
> +
> +
> +
> +2019-05-07
> +19.1.0-rc2
> +Andres Gomez
> +
> +
> +
> +2019-05-14
> +19.1.0-rc3
> +Andres Gomez
> +
> +
> +
> +2019-05-21
> +19.1.0-rc4
> +Andres Gomez
> +Last planned RC/Final release
> +
> +
> +19.2
> +2019-08-06
> +19.2.0-rc1
> +Emil Velikov
> +
> +
> +
> +2019-08-13
> +19.2.0-rc2
> +Emil Velikov
> +
> +
> +
> +2019-08-20
> +19.2.0-rc3
> +Emil Velikov
> +
> +
> +
> +2019-08-27
> +19.2.0-rc4
> +Emil Velikov
> +Last planned RC/Final release
> +
> +
> +19.3
> +2019-10-15
> +19.3.0-rc1
> +Juan A. Suarez
> +
> +
> +
> +2019-10-22
> +19.3.0-rc2
> +Juan A. Suarez
> +
> +
> +
> +2019-10-29
> +19.3.0-rc3
> +Juan A. Suarez
> +
> +
> +
> +2019-11-05
> +19.3.0-rc4
> +Juan A. Suarez
> +Last planned RC/Final release
>  
>  
>  

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

Re: [Mesa-dev] [PATCH] docs: update 18.3 and add 19.x cycles for the release calendar

2018-12-21 Thread Emil Velikov

On Mon, 17 Dec 2018 at 23:10, Andres Gomez  wrote:
>
> Cc: Dylan Baker 
> Cc: Juan A. Suarez 
> Cc: Emil Velikov 
> Signed-off-by: Andres Gomez 
> ---
Acked-by: Emil Velikov 

Can you please follow-up and add some notes to the releasing docs:

 - at any point, next two feature releases are outlined
 - as the final .0 release is cut, the release manager sends out a
patch adding an extra release, if needed
 - keep the people rotation going to ensure everyone is up-to date
about tooling, best practises, other

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

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

2018-12-21 Thread Ilia Mirkin

On Fri, Dec 21, 2018 at 9:37 AM Gert Wollny  wrote:
>
> Hello Stuart,
>
> Am Donnerstag, den 20.12.2018, 13:40 +1100 schrieb Stuart Young:
> > Gert/Ilia,
> >
> > Could this be reduced this from an error to a warning, with the
> > command-line option suppressing the warning?
> >
> > Perhaps as well as producing the warning, the build could sleep for
> > say 30 seconds after producing the warning message. This would be
> > noticeable if you're building it yourself (which would definitely get
> > the message out there), but wouldn't stop automated build processes
> > (as it's not stopping, just sleeping).
> >
> > At a later date (when meson has more exposure) then perhaps we could
> > move from a warning to an error.
>
> I would agree to that, at least it would bring us forward to give a
> proper warning to users before autotools is deleted. If, you Ilia could
>  agree to such an approach I would propose a new patch,

This would again punish users for using the thing that works for everyone.

A banner at the bottom (or top, whichever you think is more visible)
of the thing that configure prints at the end saying effectively "hey,
btw, check out meson, send feedback to mesa-dev" but perhaps in a few
more words/details would seem appropriate.

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

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

2018-12-21 Thread Gert Wollny

Hello Stuart, 

Am Donnerstag, den 20.12.2018, 13:40 +1100 schrieb Stuart Young:
> Gert/Ilia,
> 
> Could this be reduced this from an error to a warning, with the
> command-line option suppressing the warning?
> 
> Perhaps as well as producing the warning, the build could sleep for
> say 30 seconds after producing the warning message. This would be
> noticeable if you're building it yourself (which would definitely get
> the message out there), but wouldn't stop automated build processes
> (as it's not stopping, just sleeping).
> 
> At a later date (when meson has more exposure) then perhaps we could
> move from a warning to an error.

I would agree to that, at least it would bring us forward to give a
proper warning to users before autotools is deleted. If, you Ilia could
 agree to such an approach I would propose a new patch, 

Best,
Gert

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

Re: [Mesa-dev] [PATCH] gallivm: abort when trying to use non-existing intrinsic

2018-12-21 Thread Roland Scheidegger

Am 21.12.18 um 15:30 schrieb Jose Fonseca:
> On 21/12/2018 14:28, Roland Scheidegger wrote:
>> Am 21.12.18 um 08:46 schrieb Jose Fonseca:
>>> On 21/12/2018 01:42, srol...@vmware.com wrote:
 From: Roland Scheidegger 

 Whenever llvm removes an intrinsic (we're using), we're hitting
 segfaults
 due to llvm doing calls to address 0 in the jitted code instead.
 However, Jose figured out we can actually detect this with
 LLVMGetIntrinsicID(), so use this to abort, so we don't have to wonder
 what got broken. (Of course, someone still needs to fix the code to
 no longer use this intrinsic.)
 ---
    src/gallium/auxiliary/gallivm/lp_bld_intr.c | 10 ++
    1 file changed, 10 insertions(+)

 diff --git a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
 b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
 index 74ed16f33f0..c9df136b103 100644
 --- a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
 +++ b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
 @@ -241,6 +241,16 @@ lp_build_intrinsic(LLVMBuilderRef builder,
        function = lp_declare_intrinsic(module, name, ret_type,
 arg_types, num_args);
    +  /*
 +   * If llvm removes an intrinsic we use, we'll hit this abort
 (rather
 +   * than a call to address zero in the jited code).
 +   */
 +  if (LLVMGetIntrinsicID(function) == 0) {
 + printf("llvm (version 0x%x) found no intrinsic for %s, going
 to crash...\n",
 +    HAVE_LLVM, name);
>>>
>>> Better to use _debug_printf() so it's redirected to stderr (or
>>> OutpuDebug on Windows.)
>> Alright, though this will drop the output on non-debug builds.
> 
> Not really: debug_printf only prints on debug build, but  _debug_printf
> (note the leading underscore) always print.
Ahh right I failed to catch the difference here.

Roland



> 
> Perhaps it's not the smartest naming convention, but it should do the
> expected.
> 
> 
> Jose

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

Re: [Mesa-dev] [PATCH] gallivm: abort when trying to use non-existing intrinsic

2018-12-21 Thread Jose Fonseca


On 21/12/2018 14:28, Roland Scheidegger wrote:

Am 21.12.18 um 08:46 schrieb Jose Fonseca:

On 21/12/2018 01:42, srol...@vmware.com wrote:

From: Roland Scheidegger 

Whenever llvm removes an intrinsic (we're using), we're hitting segfaults
due to llvm doing calls to address 0 in the jitted code instead.
However, Jose figured out we can actually detect this with
LLVMGetIntrinsicID(), so use this to abort, so we don't have to wonder
what got broken. (Of course, someone still needs to fix the code to
no longer use this intrinsic.)
---
   src/gallium/auxiliary/gallivm/lp_bld_intr.c | 10 ++
   1 file changed, 10 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
index 74ed16f33f0..c9df136b103 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
@@ -241,6 +241,16 @@ lp_build_intrinsic(LLVMBuilderRef builder,
       function = lp_declare_intrinsic(module, name, ret_type,
arg_types, num_args);
   +  /*
+   * If llvm removes an intrinsic we use, we'll hit this abort
(rather
+   * than a call to address zero in the jited code).
+   */
+  if (LLVMGetIntrinsicID(function) == 0) {
+ printf("llvm (version 0x%x) found no intrinsic for %s, going
to crash...\n",
+    HAVE_LLVM, name);


Better to use _debug_printf() so it's redirected to stderr (or
OutpuDebug on Windows.)

Alright, though this will drop the output on non-debug builds.


Not really: debug_printf only prints on debug build, but  _debug_printf 
(note the leading underscore) always print.


Perhaps it's not the smartest naming convention, but it should do the 
expected.



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

Re: [Mesa-dev] [PATCH] gallivm: abort when trying to use non-existing intrinsic

2018-12-21 Thread Roland Scheidegger

Am 21.12.18 um 08:46 schrieb Jose Fonseca:
> On 21/12/2018 01:42, srol...@vmware.com wrote:
>> From: Roland Scheidegger 
>>
>> Whenever llvm removes an intrinsic (we're using), we're hitting segfaults
>> due to llvm doing calls to address 0 in the jitted code instead.
>> However, Jose figured out we can actually detect this with
>> LLVMGetIntrinsicID(), so use this to abort, so we don't have to wonder
>> what got broken. (Of course, someone still needs to fix the code to
>> no longer use this intrinsic.)
>> ---
>>   src/gallium/auxiliary/gallivm/lp_bld_intr.c | 10 ++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
>> b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
>> index 74ed16f33f0..c9df136b103 100644
>> --- a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
>> @@ -241,6 +241,16 @@ lp_build_intrinsic(LLVMBuilderRef builder,
>>       function = lp_declare_intrinsic(module, name, ret_type,
>> arg_types, num_args);
>>   +  /*
>> +   * If llvm removes an intrinsic we use, we'll hit this abort
>> (rather
>> +   * than a call to address zero in the jited code).
>> +   */
>> +  if (LLVMGetIntrinsicID(function) == 0) {
>> + printf("llvm (version 0x%x) found no intrinsic for %s, going
>> to crash...\n",
>> +    HAVE_LLVM, name);
> 
> Better to use _debug_printf() so it's redirected to stderr (or
> OutpuDebug on Windows.)
Alright, though this will drop the output on non-debug builds.

> 
>> + abort();
>> +  }
>> +
>>     if (!set_callsite_attrs)
>>    lp_add_func_attributes(function, attr_mask);
>>  
> 
> I think it's worth auditing we don't use lp_build_intrinsic() helper for
> LLVM functions we built ourselves.  I took a look, and didn't found any.
It never occurred to me you could use it for ordinary functions. But I
suppose you're right in theory someone could use it (although of course
the function body would have to be defined elsewhere).

Roland



> Otherwise
> 
> Reviewed-by: Jose Fonseca 
> 
> Jose

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

Re: [Mesa-dev] [PATCH] anv: gen9 doesn't support fast clear on single-sampled SRGB buffers

2018-12-21 Thread Lionel Landwerlin


Looking at this, I think the issue is more in anv_blorp.c.
All of the mcs/ccs ops we're doing use the anv_image which can be a 
different format from the anv_image_view we're dealing with.
In this particular bug, the image is R8G8B8A8_UNORM while the view is 
R8G8B8A8_SRGB.


I think this might be the problem.
Currently looking at adding anv_image_view_mcs_op/anv_image_view_ccs_op 
and see if that breaks the world.


-
Lionel

On 21/12/2018 13:09, Jason Ekstrand wrote:
This isn't quite true. Fast-clear without CCS compression (also known 
as CCS_D) is supported on gen9.  There is, however, a bug with 
blending and non-0/1 clear colors that we don't currently bother 
handling in anv. See also:


https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/intel_mipmap_tree.c#L2672 



On December 21, 2018 06:26:31 Samuel Iglesias Gonsálvez 
 wrote:



Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108911

Signed-off-by: Samuel Iglesias Gonsálvez 
---

Lionel, I have doubts if this is only for gen9 or it should be gen9+.
Can you confirm on gen10 if the sRGB bug is happening there and if this
fixes it? (You would need to adapt the GEN_GEN == 9 to >=).

src/intel/vulkan/genX_cmd_buffer.c | 4 
1 file changed, 4 insertions(+)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c

index 93b5269c6ba..cb08ef8df1e 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -324,6 +324,10 @@ color_attachment_compute_aux_usage(struct 
anv_device * device,

 break;
  }

+  /* Gen9 doesn't support fast clear on single-sampled SRGB 
buffers */
+  if (GEN_GEN == 9 && 
isl_format_is_srgb(iview->planes[0].isl.format) && 
iview->image->samples == 1)

+ att_state->fast_clear = false;
+
  /* Potentially, we could do partial fast-clears but doing so 
has crazy
   * alignment restrictions.  It's easier to just restrict to 
full size

   * fast clears for now.
--
2.19.1

___
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



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

Re: [Mesa-dev] [PATCH] anv: gen9 doesn't support fast clear on single-sampled SRGB buffers

2018-12-21 Thread Jason Ekstrand

This isn't quite true. Fast-clear without CCS compression (also known as 
CCS_D) is supported on gen9.  There is, however, a bug with blending and 
non-0/1 clear colors that we don't currently bother handling in anv. See also:


https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/intel_mipmap_tree.c#L2672

On December 21, 2018 06:26:31 Samuel Iglesias Gonsálvez 
 wrote:



Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108911

Signed-off-by: Samuel Iglesias Gonsálvez 
---

Lionel, I have doubts if this is only for gen9 or it should be gen9+.
Can you confirm on gen10 if the sRGB bug is happening there and if this
fixes it? (You would need to adapt the GEN_GEN == 9 to >=).

src/intel/vulkan/genX_cmd_buffer.c | 4 
1 file changed, 4 insertions(+)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c

index 93b5269c6ba..cb08ef8df1e 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -324,6 +324,10 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,

 break;
  }

+  /* Gen9 doesn't support fast clear on single-sampled SRGB buffers */
+  if (GEN_GEN == 9 && isl_format_is_srgb(iview->planes[0].isl.format) 
&& iview->image->samples == 1)

+ att_state->fast_clear = false;
+
  /* Potentially, we could do partial fast-clears but doing so has crazy
   * alignment restrictions.  It's easier to just restrict to full size
   * fast clears for now.
--
2.19.1

___
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

[Mesa-dev] [PATCH] anv: gen9 doesn't support fast clear on single-sampled SRGB buffers

2018-12-21 Thread Samuel Iglesias Gonsálvez

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108911

Signed-off-by: Samuel Iglesias Gonsálvez 
---

Lionel, I have doubts if this is only for gen9 or it should be gen9+.
Can you confirm on gen10 if the sRGB bug is happening there and if this
fixes it? (You would need to adapt the GEN_GEN == 9 to >=).

 src/intel/vulkan/genX_cmd_buffer.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 93b5269c6ba..cb08ef8df1e 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -324,6 +324,10 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
  break;
   }
 
+  /* Gen9 doesn't support fast clear on single-sampled SRGB buffers */
+  if (GEN_GEN == 9 && isl_format_is_srgb(iview->planes[0].isl.format) && 
iview->image->samples == 1)
+ att_state->fast_clear = false;
+
   /* Potentially, we could do partial fast-clears but doing so has crazy
* alignment restrictions.  It's easier to just restrict to full size
* fast clears for now.
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH] gallivm: don't use pavg.b intrinsic on llvm >= 6.0

2018-12-21 Thread Michel Dänzer

On 2018-12-21 1:25 a.m., srol...@vmware.com wrote:
> From: Roland Scheidegger 
> 
> This intrinsic disppeared with llvm 6.0, using it ends up in segfaults
> (due to llvm issuing call to NULL address in the jited shaders).
> Add code doing the same thing as the autoupgrade code in llvm so it
> can be matched and replaced back with a pavgb.
> 
> While here, also improve lp_test_format, so it tests both with and without
> cache (as it was, it tested the cache versions only, whereas cache is
> actually disabled in llvmpipe, and in any case even with it enabled
> vertex and geometry shaders wouldn't use it). (Although at least for
> the unorm8 uncached fetch, the code is still quite different to what
> llvmpipe is using, since that would use unorm8x16 type, whereas
> the test code is using unorm8x4 type, hence disabling some intrinsic
> paths.)
> 
> Fixes: 6f4083143bb8c478ccfcaef034d183d89b471993

I'd suggest shortening the hash to ~12 characters and adding the
shortlog, but either way,

Tested-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106769] radv: add support for shaderStorageImageMultisample

2018-12-21 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=106769

Samuel Pitoiset  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Samuel Pitoiset  ---
Done.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=96063100812d1de46f4146fde92975c98e78c3ce

-- 
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

39 matches

Mail list logo