On Thu, 2018-12-13 at 12:49 +0200, Pohjolainen, Topi wrote:
> On Thu, Dec 13, 2018 at 09:10:24AM +0100, Iago Toral wrote:
> > On Wed, 2018-12-12 at 14:15 +0200, Pohjolainen, Topi wrote:
> > > On Wed, Dec 12, 2018 at 09:48:20AM +0100, Iago Toral wrote:
> > > > On Tue, 2018-12-11 at 18:59 +0200,
On Fri, Dec 14, 2018 at 2:13 AM Matt Turner wrote:
>
> On Thu, Dec 13, 2018 at 10:19 PM Ilia Mirkin wrote:
> > So now what? I don't remember how that config was done, except that it
> > was done the way I decided I needed it at the time. I have no way to
> > recover it. With autotools, in such
So your issue is that meson upgrade broke the build and you are unable to
get config.log. Let me tell you something. Ninja upgrade also breaks the
build. I think that's the way it's going to be now. I think people will use
the new build system anyway as conf and compile time is all that matters.
On Thu, Dec 13, 2018 at 10:19 PM Ilia Mirkin wrote:
> So now what? I don't remember how that config was done, except that it
> was done the way I decided I needed it at the time. I have no way to
> recover it. With autotools, in such cases (which are immensely rare),
> you just run "head
I have to say that the user experience for autotools is WAY better
than for meson. As a concrete example, I had a meson build. Then I
updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work. meson
--reconfigure (which presumably is what ninja would end up running)
doesn't work.
This just happened not to crash/assert because all loops have at
least 1 if-statement and due to a second bug we end up matching
the same ENDIF to exit both the iteration over the if-statment
and the loop.
The second bug is fixed in the following patch.
Fixes: 386d165d8d09 ("tgsi/scan: add a new
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
https://bugs.freedesktop.org/show_bug.cgi?id=108946
--- Comment #9 from Ian Romanick ---
(In reply to iive from comment #8)
> (In reply to Ian Romanick from comment #6)
> > (I'm quite sure I submitted a similar comment earlier today, but it seems to
> > have just vanished.)
> >
> > I ran the
On Thu, 13 Dec 2018 at 11:08, Emil Velikov wrote:
> Hi guys,
>
> While hacking on the integration I've spotted a few issues with our
> meson build - patches 1-6.
>
> The rest of the series is Dylan's patches followed by a build matrix
> analogous to the autotools/make one.
>
> As-is this causes
On Wed, Oct 31, 2018 at 04:27:31PM -0700, Kenneth Graunke wrote:
> On Wednesday, October 31, 2018 11:15:28 AM PDT Rafael Antognolli wrote:
> > On Tue, Oct 30, 2018 at 04:32:54PM -0700, Kenneth Graunke wrote:
> > > On Monday, October 29, 2018 10:19:54 AM PDT Rafael Antognolli wrote:
> > > Do we
Quoting Marek Olšák (2018-12-13 11:28:10)
> Another issue with meson is this:
>
> I have to set PKG_CONFIG_PATH when I type meson for 32-bit builds. If I do
> meson configure --clearcache and then type "ninja", it will reconfigure, but
> will use 64-bit libraries instead because PKG_CONFIG_PATH
On Fri, Dec 14, 2018 at 12:27 AM Ilia Mirkin wrote:
>
> On Thu, Dec 13, 2018 at 6:14 PM Karol Herbst wrote:
> >
> > gives me an performance boost of 0.2% in pixmark_piano on my gk106, gm204
> > and
> > gp107.
> >
> > changes in shader-db:
> >
> > total instructions in shared programs :
https://bugs.freedesktop.org/show_bug.cgi?id=108946
--- Comment #8 from i...@yahoo.com ---
(In reply to Ian Romanick from comment #6)
> (I'm quite sure I submitted a similar comment earlier today, but it seems to
> have just vanished.)
>
> I ran the API trace in Valgrind massif memory profiler.
On 13/12/18 11:11 pm, Alejandro Piñeiro wrote:
This is needed due how the types get rearranged after the struct
splitting.
So for example, this array of blocks:
layout(location = 0) out block {
vec4 v;
vec3 v2;
} x[2];
Would be splitted on two nir variables with the
I don't think I've seen the warning so its likely I use this (or
removing it) in a future patch. But feel free to push this for now.
On 14/12/18 1:25 am, Alejandro Piñeiro wrote:
To avoid the following warning:
./src/compiler/nir/nir_loop_analyze.c:807:16: warning: unused variable ‘ns’
On 13/12/18 8:10 pm, Samuel Pitoiset wrote:
This introduces crashes for
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_frag
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_geom
On Thu, Dec 13, 2018 at 6:14 PM Karol Herbst wrote:
>
> gives me an performance boost of 0.2% in pixmark_piano on my gk106, gm204 and
> gp107.
>
> changes in shader-db:
>
> total instructions in shared programs : 7614782 -> 7614782 (0.00%)
> total cvt instructions in shared programs : 139343
The pass did not correctly handle loops ending in:
if ssa_7 {
block block_8:
/* preds: block_7 */
continue
/* succs: block_1 */
} else {
block block_9:
/* preds: block_7 */
gives me an performance boost of 0.2% in pixmark_piano on my gk106, gm204 and
gp107.
changes in shader-db:
total instructions in shared programs : 7614782 -> 7614782 (0.00%)
total cvt instructions in shared programs : 139343 -> 95856 (-31.21%)
total gprs used in shared programs:
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 +
.../drivers/nouveau/codegen/nv50_ir_driver.h| 1 +
.../drivers/nouveau/codegen/nv50_ir_inlines.h | 17 +
.../drivers/nouveau/codegen/nv50_ir_target.cpp | 2 ++
https://bugs.freedesktop.org/show_bug.cgi?id=109058
--- Comment #1 from Bas Nieuwenhuizen ---
I don't think there are any outstanding bugreports for that GPU specifically
though it does not receive much testing.
Looking at https://bugs.freedesktop.org/show_bug.cgi?id=108900 it looks like
there
On Thu, 2018-11-15 at 13:45 +0100, Gert Wollny wrote:
> From: Gert Wollny
>
> Dear all,
>
> after the RFC and Ilias comments I reworked the series another
> time.
> Changes with respect to the RFC are
> - renaming the new CAP
> - reordering of the patches that no double checking of
>
On Thu, 2018-11-15 at 13:45 +0100, Gert Wollny wrote:
> @@ -457,14 +458,15 @@ st_framebuffer_create(struct st_context *st,
> * format such that util_format_srgb(visual->color_format) can be
> supported
> * by the pipe driver. We still need to advertise the capability
> here.
> *
>
CodeGenOptions were moved to Basic.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109039
Signed-off-by: Jan Vesely
---
src/gallium/state_trackers/clover/llvm/compat.hpp | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=109039
Jan Vesely changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Jan Vesely changed:
What|Removed |Added
Depends on||109039
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=109039
--- Comment #2 from Jan Vesely ---
(In reply to Yurii Kolesnykov from comment #1)
> Created attachment 142791 [details] [review]
> fix
Have you tested the patch with LLVM-7? It looks like it would fail the build.
--
You are receiving this
IMHO allowing MRs is a good thing, so
Acked-by: Gert Wollny
I've added a little remark below.
Best,
Gert
Am Mittwoch, den 05.12.2018, 15:32 -0800 schrieb Jordan Justen:
> This documents a process for using GitLab Merge Requests as an second
> way to submit code changes for Mesa. Only
On Thu, Dec 13, 2018 at 2:41 PM Jason Ekstrand wrote:
>
> On Wed, Dec 12, 2018 at 2:52 PM Rob Clark wrote:
>>
>> On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák wrote:
>> >
>> > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark wrote:
>> >>
>> >> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen
>> >>
Signed-off-by: Christian Gmeiner
---
meson.build | 2 +-
meson_options.txt | 2 +-
src/gallium/drivers/etnaviv/meson.build | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/meson.build b/meson.build
index
On Wed, Dec 12, 2018 at 2:42 PM Marek Olšák wrote:
> Most assertions and checks are enabled, because NDEBUG is not defined, but
> DEBUG is not defined either, which is a Mesa-specific definition.
>
> The default debug build for autotools is debugoptimized (-g -O2 -DDEBUG).
> meson changed that
On Wed, Dec 12, 2018 at 2:52 PM Rob Clark wrote:
> On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák wrote:
> >
> > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark wrote:
> >>
> >> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen
> >> wrote:
> >> >
> >> > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák
https://bugs.freedesktop.org/show_bug.cgi?id=108578
--- Comment #8 from bmil...@gmail.com ---
@Samuel Pitoiset Still reports 1.1.70, this function wasn't updated.
line 292 of rad_extensions.py:
uint32_t
radv_physical_device_api_version(struct radv_physical_device *dev)
{
if (!ANDROID &&
Another issue with meson is this:
I have to set PKG_CONFIG_PATH when I type meson for 32-bit builds. If I do
meson configure --clearcache and then type "ninja", it will reconfigure,
but will use 64-bit libraries instead because PKG_CONFIG_PATH is not set
when ninja is run, which will fail to
https://bugs.freedesktop.org/show_bug.cgi?id=109023
--- Comment #1 from Vinson Lee ---
Build command to reproduce.
meson builddir -Dgallium-drivers=swr -Dswr-arches=avx,avx2,knl,skx
ninja -C builddir
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA
https://bugs.freedesktop.org/show_bug.cgi?id=109058
Bug ID: 109058
Summary: Machine freezes during early stages of gfxbench
startup
Product: Mesa
Version: 18.2
Hardware: x86-64 (AMD64)
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=108935
--- Comment #2 from Philip Rebohle ---
This regression also affects Hitman 2, https://reviews.llvm.org/D55602 fixes
it.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
Jason Ekstrand writes:
> On Thu, Dec 13, 2018 at 11:07 AM Axel Davy wrote:
>
>> On 13/12/2018 17:57, Mathias Fröhlich wrote:
>> > Hi,
>> > Initially it seemed to me that I am about the only one sticking with
>> mailing lists.
>> > And I personally feel like a too small contributor to really try
Dylan Baker writes:
> [ Unknown signature status ]
> In the autotools discussion I've come to realize that we also need to talk
> about
> the -DDEBUG guard. It seems that there are two different uses, and thus two
> different asks about it:
>
> - Nine (and RadeonSI?) use -DDEBUG to hide generic
https://bugs.freedesktop.org/show_bug.cgi?id=109004
Emil Velikov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Quoting Alex Deucher (2018-12-13 07:52:04)
> On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
> wrote:
> >
> > Personally, I will continue to use the list, at least for a simplicity
> > point of view. I'm not sure if using a new tool will improve quality and
> > code review process.
> >
> >
On Thu, Dec 13, 2018 at 11:34 AM Dylan Baker wrote:
> Quoting Rob Clark (2018-12-12 16:35:24)
> > On Wed, Dec 12, 2018 at 7:14 PM Dylan Baker wrote:
> > >
> > > Quoting Rob Clark (2018-12-12 15:52:47)
> > > > On Wed, Dec 12, 2018 at 6:25 PM Dylan Baker
> wrote:
> > > > >
> > > > > In the
Quoting Rob Clark (2018-12-12 16:35:24)
> On Wed, Dec 12, 2018 at 7:14 PM Dylan Baker wrote:
> >
> > Quoting Rob Clark (2018-12-12 15:52:47)
> > > On Wed, Dec 12, 2018 at 6:25 PM Dylan Baker wrote:
> > > >
> > > > In the autotools discussion I've come to realize that we also need to
> > > >
On Thu, Dec 13, 2018 at 11:07 AM Axel Davy wrote:
> On 13/12/2018 17:57, Mathias Fröhlich wrote:
> > Hi,
> > Initially it seemed to me that I am about the only one sticking with
> mailing lists.
> > And I personally feel like a too small contributor to really try to
> influence your
> >
Ping.
El 22/11/18 a las 0:28, Chema Casanova escribió:
>
>
> On 21/11/18 20:04, Ilia Mirkin wrote:
>> On Wed, Nov 21, 2018 at 1:45 PM Jose Maria Casanova Crespo
>> wrote:
>>>
>>> Recent change on OpenGL CTS ("Use non-arrayed varying name for TCS blocks")
>>> on
On Thu, Dec 13, 2018 at 4:52 PM Alex Deucher wrote:
>
> On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
> wrote:
> >
> > Personally, I will continue to use the list, at least for a simplicity
> > point of view. I'm not sure if using a new tool will improve quality and
> > code review process.
>
On 13/12/2018 17:57, Mathias Fröhlich wrote:
Hi,
Initially it seemed to me that I am about the only one sticking with mailing
lists.
And I personally feel like a too small contributor to really try to influence
your
decisions too much. But these recent hand full of mails all tell me that I am
This is so that we can split different types of loads more easily.
Signed-off-by: Rhys Perry
---
src/amd/common/ac_llvm_build.c | 8 ++--
src/amd/common/ac_nir_to_llvm.c | 80 -
src/compiler/nir/nir.h | 2 +-
3 files changed, 44 insertions(+), 46
Fixes: 7e7ee826982 ('ac: add support for 16bit buffer loads')
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108114
Signed-off-by: Rhys Perry
---
src/amd/common/ac_nir_to_llvm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c
On Thu, Dec 13, 2018 at 11:41 AM Jason Ekstrand wrote:
>
> On Thu, Dec 13, 2018 at 9:56 AM Ilia Mirkin wrote:
>>
>> On Thu, Dec 13, 2018 at 10:52 AM Alex Deucher wrote:
>> >
>> > On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
>> > wrote:
>> > >
>> > > Personally, I will continue to use the
On Thu, Dec 13, 2018 at 11:41 AM Jason Ekstrand wrote:
>
> On Thu, Dec 13, 2018 at 9:56 AM Ilia Mirkin wrote:
>>
>> On Thu, Dec 13, 2018 at 10:52 AM Alex Deucher wrote:
>> >
>> > On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
>> > wrote:
>> > >
>> > > Personally, I will continue to use the
Hi,
On Thursday, 13 December 2018 17:40:49 CET Jason Ekstrand wrote:
> On Thu, Dec 13, 2018 at 9:56 AM Ilia Mirkin wrote:
>
> > On Thu, Dec 13, 2018 at 10:52 AM Alex Deucher
> > wrote:
> > >
> > > On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
> > > wrote:
> > > >
> > > > Personally, I will
On 13/12/2018 17:26, Jason Ekstrand wrote:
On Thu, Dec 13, 2018 at 5:06 AM Eric Engestrom
mailto:eric.engest...@intel.com>> wrote:
On Wednesday, 2018-12-12 15:24:25 -0800, Dylan Baker wrote:
> In the autotools discussion I've come to realize that we also
need to talk about
>
On Thu, Dec 13, 2018 at 9:56 AM Ilia Mirkin wrote:
> On Thu, Dec 13, 2018 at 10:52 AM Alex Deucher
> wrote:
> >
> > On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
> > wrote:
> > >
> > > Personally, I will continue to use the list, at least for a simplicity
> > > point of view. I'm not sure if
On Thu, Dec 13, 2018 at 5:06 AM Eric Engestrom
wrote:
> On Wednesday, 2018-12-12 15:24:25 -0800, Dylan Baker wrote:
> > In the autotools discussion I've come to realize that we also need to
> talk about
> > the -DDEBUG guard. It seems that there are two different uses, and thus
> two
> >
From: Emil Velikov
Reasonably often people will want to build the loader w/o any drivers.
Be that debugging an issue in the former, distribution bundle or other.
Currently there is an artificial restriction preventing people to build
a config like the following:
meson build/ -Dglx=dri
On 2018-12-13 4:52 p.m., Alex Deucher wrote:
> On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
> wrote:
>>
>> Personally, I will continue to use the list, at least for a simplicity
>> point of view. I'm not sure if using a new tool will improve quality and
>> code review process.
>>
>> Though, if
Hi,
On 13.12.2018 12.19, Eric Engestrom wrote:
On Wednesday, 2018-12-12 19:45:06 -0500, Marek Olšák wrote:
On Wed, Dec 12, 2018 at 7:35 PM Rob Clark wrote:
On Wed, Dec 12, 2018 at 7:14 PM Dylan Baker wrote:
Quoting Rob Clark (2018-12-12 15:52:47)
...
I guess I should have covered that:
From: Emil Velikov
This commit adds a number of build combos:
- Gallium Drivers {SWR, RadeonSI, Others)
Each one has different LLVM requirements. Building SWR alone is twice
as slow as all other drivers combined.
- Gallium ST Clover LLVM {5,6,7}
Because C++ API changes all the time.
From: Emil Velikov
Signed-off-by: Emil Velikov
---
.travis.yml | 4
1 file changed, 4 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 4933d8d78a2..125d6ce3c68 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -36,6 +36,7 @@ matrix:
- BUILD=meson
- UNWIND="false"
From: Emil Velikov
It makes for a shorter MESON_OPTIONS and cleaner handling.
Signed-off-by: Emil Velikov
---
.travis.yml | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 8cb7f8b95c1..4966f7eb1bf 100644
--- a/.travis.yml
+++
From: Emil Velikov
Signed-off-by: Emil Velikov
---
.travis.yml | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index d16c896b8a1..4933d8d78a2 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -35,6 +35,7 @@ matrix:
- LABEL="meson
From: Emil Velikov
Signed-off-by: Emil Velikov
---
.travis.yml | 4
1 file changed, 4 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 4966f7eb1bf..d16c896b8a1 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -34,6 +34,7 @@ matrix:
- env:
- LABEL="meson Vulkan"
From: Emil Velikov
Provides quick and easy feedback.
Signed-off-by: Emil Velikov
---
.travis.yml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 6fefe06617a..c69f322d7b3 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -668,6 +668,8 @@ script:
#
From: Emil Velikov
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
From: Dylan Baker
v2: [Emil] pass the argument directly to meson
Reviewed-by: Emil Velikov (v1)
Signed-off-by: Emil Velikov
---
.travis.yml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index 3c34942cadb..8cb7f8b95c1 100644
--- a/.travis.yml
From: Dylan Baker
This is the supported way to do this, and should be more robust and
reliable.
v2: [Emil]
- enable backslash escapes
- don't hardcode the path
- pass the argument directly to meson
Reviewed-by: Emil Velikov (v1)
Signed-off-by: Emil Velikov
---
.travis.yml | 22
From: Emil Velikov
The latter is the default these days and Travis will be removing sudo
soonish.
Flipping to xenial, allows us to remove a bunch of hacks we have. Plus
it prevents us from adding new ones, to workaround what seems like a
gcc/binutils bug. For example (from the upcoming meson
From: Emil Velikov
Swap '..' with the symbolic inc_glx and add glproto as dependency. That
will pull the correct include, effectively fixing the tests on macOS.
Fixes: a47c525f328 ("meson: build glx")
Signed-off-by: Emil Velikov
---
src/glx/tests/meson.build | 4 ++--
1 file changed, 2
From: Emil Velikov
Signed-off-by: Emil Velikov
---
.travis.yml | 1 +
1 file changed, 1 insertion(+)
diff --git a/.travis.yml b/.travis.yml
index deec40cb135..6fefe06617a 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -670,5 +670,6 @@ script:
export CFLAGS="$CFLAGS -isystem`pwd`"
From: Emil Velikov
The library is called libgalliumvl_stub - note singular.
Fixes: 42ea0631f10 ("meson: build clover")
Signed-off-by: Emil Velikov
---
src/gallium/targets/pipe-loader/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Dylan Baker
Since we're going to delete it shortly
Reviewed-by: Emil Velikov
---
.travis.yml | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index c398ebc748a..3c34942cadb 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -15,7
From: Emil Velikov
The gallium drivers do not require a DRI loader. Drop the artificial
and unnecessary restriction.
Fixes: af9d276134d ("meson: build libmesa_gallium")
Signed-off-by: Emil Velikov
---
There are a few use cases:
- building a gallium state-tracker, say opencl in st/clover,
From: Emil Velikov
When producing the final libGL.so/libGLX_mesa.so we only link the local
static helper lib (libglx). Thus there's no reason for the includes.
Fixes: a47c525f328 ("meson: build glx")
Signed-off-by: Emil Velikov
---
src/glx/meson.build | 1 -
1 file changed, 1 deletion(-)
From: Emil Velikov
Accidentally dropped with earlier commit.!
Fixes: 4ccb9816737 ("meson: Use consistent style for tests")
Signed-off-by: Emil Velikov
---
src/glx/tests/meson.build | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/glx/tests/meson.build b/src/glx/tests/meson.build
From: Emil Velikov
The library is the dri capable one, push the check src/meson.build,
instead of the current partial handling in src/glx/meson.build.
Fixes: a47c525f328 ("meson: build glx")
Signed-off-by: Emil Velikov
---
src/glx/meson.build | 32 +++-
Hi guys,
While hacking on the integration I've spotted a few issues with our
meson build - patches 1-6.
The rest of the series is Dylan's patches followed by a build matrix
analogous to the autotools/make one.
As-is this causes one issue on macOS due to overly strict guards in the
meson code.
On Thu, Dec 13, 2018 at 10:52 AM Alex Deucher wrote:
>
> On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
> wrote:
> >
> > Personally, I will continue to use the list, at least for a simplicity
> > point of view. I'm not sure if using a new tool will improve quality and
> > code review process.
>
On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
wrote:
>
> Personally, I will continue to use the list, at least for a simplicity
> point of view. I'm not sure if using a new tool will improve quality and
> code review process.
>
> Though, if the majority reports that is really nice to use, I
On 12/12/2018 08:48 AM, Rob Clark wrote:
> And before someone actually starts implementing DiscardFramebuffer()
> lets rework the interface to something that is actually usable.
>
> Signed-off-by: Rob Clark
> Reviewed-by: Ian Romanick
> ---
> src/mesa/main/dd.h | 5 ++-
>
On 12/13/18 3:45 PM, Rhys Perry wrote:
(accidently sent an incomplete email)
Seems my LLVM configuration was messed up and I might have used my
distro's LLVM too.
LLVM 8 and 7 with a release build passes.
A debug build of 8 (and my messed up builds of 7 and 8 which I thought
were release
Mesa 18.2.7 is now available.
In this release we have:
Several patches fixing leaks in glsl, winsys and r600.
Improvements in the scripts that helps in preparing releases.
Added PCI IDs for Amber Lake and Whiskey Lake.
Fixes for radv, anv, i965 and vc4 drivers.
A couple of fixes in NIR
(accidently sent an incomplete email)
Seems my LLVM configuration was messed up and I might have used my
distro's LLVM too.
LLVM 8 and 7 with a release build passes.
A debug build of 8 (and my messed up builds of 7 and 8 which I thought
were release ones) results in an assert.
On Thu, 13 Dec
Reviewed-by: Lionel Landwerlin
On 13/12/2018 14:25, Alejandro Piñeiro wrote:
To avoid the following warning:
./src/compiler/nir/nir_loop_analyze.c:807:16: warning: unused variable ‘ns’
[-Wunused-variable]
nir_shader *ns = impl->function->shader;
---
Perhaps this is solved on any of the
Seems my LLVM configuration was messed up and I might have used my
distro's LLVM too.
On Thu, 13 Dec 2018 at 08:38, Samuel Pitoiset wrote:
>
>
>
> On 12/6/18 3:18 PM, Rhys Perry wrote:
> > ./deqp-vk
> >
To avoid the following warning:
./src/compiler/nir/nir_loop_analyze.c:807:16: warning: unused variable ‘ns’
[-Wunused-variable]
nir_shader *ns = impl->function->shader;
---
Perhaps this is solved on any of the loop analysis patches pending to
be reviewed, but just in case, sending it.
On December 13, 2018 04:07:56 Iago Toral wrote:
On Thu, 2018-12-06 at 13:45 -0600, Jason Ekstrand wrote:
(...)
diff --git a/src/compiler/nir/nir_builder.h
b/src/compiler/nir/nir_builder.h
index 30fa1d7ec8b..e0cdcd4ba23 100644
--- a/src/compiler/nir/nir_builder.h
+++
https://bugs.freedesktop.org/show_bug.cgi?id=108578
--- Comment #7 from Shmerl ---
For those following this, reported API version should be now at 1.1.90:
https://gitlab.freedesktop.org/mesa/mesa/commit/2ac6d55f38c1665a16d8d02675df2e3a858a7fec
--
You are receiving this mail because:
You are
This is needed due how the types get rearranged after the struct
splitting.
So for example, this array of blocks:
layout(location = 0) out block {
vec4 v;
vec3 v2;
} x[2];
Would be splitted on two nir variables with the following types:
* vec4 v[2]
* vec3 v2[2]
So we need to
https://bugs.freedesktop.org/show_bug.cgi?id=108900
--- Comment #4 from Eero Tamminen ---
FYI: https://gfxbench.com/ site works again.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
El 13/12/18 a las 11:49, Pohjolainen, Topi escribió:
> On Thu, Dec 13, 2018 at 09:10:24AM +0100, Iago Toral wrote:
>> On Wed, 2018-12-12 at 14:15 +0200, Pohjolainen, Topi wrote:
>>> On Wed, Dec 12, 2018 at 09:48:20AM +0100, Iago Toral wrote:
On Tue, 2018-12-11 at 18:59 +0200, Pohjolainen,
This fixes rendering in Supertuxkart, Serious Sam 3, and Shadow Warrior
via virgl for me. So for the series:
Tested-By: Gert Wollny
Am Dienstag, den 11.12.2018, 15:26 +0100 schrieb Erik Faye-Lund:
> Virglrenderer does the wrong thing when given an instance divisor;
> it tries to use the
On Wednesday, 2018-12-12 15:24:25 -0800, Dylan Baker wrote:
> In the autotools discussion I've come to realize that we also need to talk
> about
> the -DDEBUG guard. It seems that there are two different uses, and thus two
> different asks about it:
>
> - Nine (and RadeonSI?) use -DDEBUG to hide
On Thu, Dec 13, 2018 at 09:10:24AM +0100, Iago Toral wrote:
> On Wed, 2018-12-12 at 14:15 +0200, Pohjolainen, Topi wrote:
> > On Wed, Dec 12, 2018 at 09:48:20AM +0100, Iago Toral wrote:
> > > On Tue, 2018-12-11 at 18:59 +0200, Pohjolainen, Topi wrote:
> > > > On Fri, Dec 07, 2018 at 03:30:11PM
On Wednesday, 2018-12-12 19:45:06 -0500, Marek Olšák wrote:
> On Wed, Dec 12, 2018 at 7:35 PM Rob Clark wrote:
>
> > On Wed, Dec 12, 2018 at 7:14 PM Dylan Baker wrote:
> > >
> > > Quoting Rob Clark (2018-12-12 15:52:47)
> > > > On Wed, Dec 12, 2018 at 6:25 PM Dylan Baker
> > wrote:
> > > > >
>
On Thu, 2018-12-06 at 13:45 -0600, Jason Ekstrand wrote:
(...)
> diff --git a/src/compiler/nir/nir_builder.h
> b/src/compiler/nir/nir_builder.h
> index 30fa1d7ec8b..e0cdcd4ba23 100644
> --- a/src/compiler/nir/nir_builder.h
> +++ b/src/compiler/nir/nir_builder.h
> @@ -963,6 +963,18 @@
This introduces crashes for
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_frag
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_geom
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_tessc
On 12/6/18 3:18 PM, Rhys Perry wrote:
./deqp-vk
--deqp-case=dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.input_output_int_32_to_16.scalar_uint0_frag
should crash with something like:
deqp-vk: lib/IR/Instructions.cpp:2590: static llvm::CastInst*
This refactoring is really not easy to read as is. Can you please split
this in different parts? Maybe refactor first, then fix 16-bit ssbo loads?
If we want this to be backported, we will just need to squash the
different parts and send a separate patch to mesa-stable.
On 12/6/18 12:13 AM,
Reviewed-by: Samuel Pitoiset
On 12/13/18 4:32 AM, Dave Airlie wrote:
From: Dave Airlie
If we gave this function 0 counter buffers, we'd still try and
access pCounterBuffers[0] as this check was incorrect.
Fixes crash with ext_transform_feedback-pipeline-basic-primgen
on zink on radv.
1 - 100 of 101 matches
Mail list logo
