Build mesa 62 failed
Commit 200859f45c by Caio Marcelo de Oliveira Filho on 8/28/2019 4:14 AM:
iris: Enable ARB_gl_spirv and ARB_spirv_extensions
Configure your notification preferences
___
mesa-dev
On Tue, Aug 27, 2019 at 7:14 PM Lepton Wu wrote:
>
> On Thu, Aug 15, 2019 at 3:31 PM Mauro Rossi wrote:
> >
> > Hi Lepton,
> >
> > On Thu, Aug 15, 2019 at 9:58 PM Lepton Wu wrote:
> >>
> >> That's interesting. The android frame work will hard coded to use
> >> RGBA_ and set it as window
On Thu, Aug 15, 2019 at 3:31 PM Mauro Rossi wrote:
>
> Hi Lepton,
>
> On Thu, Aug 15, 2019 at 9:58 PM Lepton Wu wrote:
>>
>> That's interesting. The android frame work will hard coded to use
>> RGBA_ and set it as window format here:
>>
>>
Thank you for your reminding, I've sent [patch v2] to this mailing
list, I'd prefer to waiting for response here before I get familiar
with gitlab MR.
On 2019/8/27 下午6:15, apinheiro wrote:
>
> On 27/8/19 11:13, Zhaowei Yuan wrote:
>> Four bytes of src_surf will be compressed into a 32-bits
Four bytes of src_surf will be compressed into a 32-bits data
and stored into dst_surf, and dst_surf is read as z-order,so
its width must be aligned to multiples of 8(4x2) before devided
by 2.
Signed-off-by: Zhaowei Yuan
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111266
---
By the way, I took the liberty of composing a test which fails with
current mesa, and I'm pretty sure it continues to fail with this
patch. It does pass if I just make it a GLubyte like all the other
instances of the code already do.
Piglit test: https://patchwork.freedesktop.org/patch/327460/
On Tuesday, 2019-08-27 13:31:22 +, Jose Fonseca wrote:
> Appveyor seems to be building other MR 1781:
>
> https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425
> https://ci.appveyor.com/project/mesa3d/mesa-re1yd/history
>
I don't think the original author was included -- CC was probably
stripped by the ML. Adding here.
On Tue, Aug 27, 2019 at 6:49 PM Marek Olšák wrote:
>
> Yes, but if the original author doesn't reply, I'd like to push this.
>
> Marek
>
> On Thu, Aug 15, 2019 at 8:01 PM Ilia Mirkin wrote:
>>
>>
Yes, but if the original author doesn't reply, I'd like to push this.
Marek
On Thu, Aug 15, 2019 at 8:01 PM Ilia Mirkin wrote:
> Subtle. The source format *can* be 64-bit, by the way, but if it's
> GL_DEPTH_COMPONENT it may well be 32-bit.
>
> But what if it's GL_STENCIL_INDEX -- could it not
Build mesa 35 completed
Commit d8f27552f4 by Daniel Kolesa on 8/27/2019 8:29 PM:
util: add auxv based PowerPC AltiVec/VSX detection
Configure your notification preferences
___
mesa-dev mailing list
Build mesa 34 failed
Commit d8f27552f4 by Daniel Kolesa on 8/27/2019 8:17 PM:
src/util/u_cpu_detect.c: add PowerPC auxv AltiVec/VSX detection
Configure your notification preferences
___
mesa-dev mailing
Build mesa 31 completed
Commit 6342d43ae9 by Kenneth Graunke on 8/27/2019 8:14 PM:
iris: Delete dead prototype
Configure your notification preferences
___
mesa-dev mailing list
Build mesa 30 failed
Commit 2734a4951e by Daniel Kolesa on 8/27/2019 8:14 PM:
src/util/u_cpu_detect.c: add PowerPC auxv AltiVec/VSX detection
Configure your notification preferences
___
mesa-dev mailing
Build mesa 28 completed
Commit 2734a4951e by q66 on 8/27/2019 8:01 PM:
src/util/u_cpu_detect.c: add PowerPC auxv AltiVec/VSX detection
Configure your notification preferences
___
mesa-dev mailing list
Build mesa 27 failed
Commit 2734a4951e by q66 on 8/27/2019 7:58 PM:
src/util/u_cpu_detect.c: add PowerPC auxv AltiVec/VSX detection
Configure your notification preferences
___
mesa-dev mailing list
+ Juan, Emil, Jeremy
Thanks,
Marek
On Mon, Aug 26, 2019 at 3:05 PM Marek Olšák wrote:
> Hi,
>
> I'd like to push the Navi14 merge request to 19.2 no later than Tuesday
> August 27.
>
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1726
>
> Please ack if it's OK with you,
>
> Thanks,
https://bugs.freedesktop.org/show_bug.cgi?id=111504
Bug ID: 111504
Summary: how to know the use of the Lima driver
Product: Mesa
Version: 19.1
Hardware: ARM
OS: Linux (All)
Status: NEW
Severity: not set
Am 27.08.19 um 12:57 schrieb Jose Fonseca:
> Uses some of the same -Werror options used by Meson, as suggested by
> Michel Daezer.
> ---
> scons/gallium.py | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/scons/gallium.py b/scons/gallium.py
> index
On Tue, 2019-08-27 at 10:57 +, Jose Fonseca wrote:
> I don't know how Meson didn't hit this issue, when it too already uses
> -Werror=incompatible-pointer-types
Yeah, weird.
Reviewed-by: Adam Jackson
- ajax
___
mesa-dev mailing list
On Tue, 27 Aug 2019 07:25:03 -0700
Alyssa Rosenzweig wrote:
> Assuming it passes CI, feel free to apply it :)
I guess that stands for a R-b :-).
>
> On Tue, Aug 27, 2019 at 12:40:08PM +0200, Boris Brezillon wrote:
> > On Tue, 13 Aug 2019 15:30:20 -0700
> > Alyssa Rosenzweig wrote:
> >
> >
On Tue, 27 Aug 2019 07:24:36 -0700
Alyssa Rosenzweig wrote:
> Patches 1, 2, and 5 are:
>
> Reviewed-by: Alyssa Rosenzweig
>
> Patches 3 and 4 are modifying the guts of the scheduler which I plan to
> rewrite in full, like, today.
No problem. I guess you can fix those problem as part of
Assuming it passes CI, feel free to apply it :)
On Tue, Aug 27, 2019 at 12:40:08PM +0200, Boris Brezillon wrote:
> On Tue, 13 Aug 2019 15:30:20 -0700
> Alyssa Rosenzweig wrote:
>
> > > I don't see any remove_ins()/insert_before() call in there. Do you see
> > > any reason for using the _safe()
Patches 1, 2, and 5 are:
Reviewed-by: Alyssa Rosenzweig
Patches 3 and 4 are modifying the guts of the scheduler which I plan to
rewrite in full, like, today.
On Tue, Aug 27, 2019 at 12:36:40PM +0200, Boris Brezillon wrote:
> To avoid memory leaks.
>
> Signed-off-by: Boris Brezillon
>
Appveyor seems to be building other MR 1781:
https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425
https://ci.appveyor.com/project/mesa3d/mesa-re1yd/history
https://gitlab.freedesktop.org/eric/mesa/pipelines/59190
I don't know what's special about MR 1779. Perhaps it's just
On Tuesday, 2019-08-27 10:30:07 +, Jose Fonseca wrote:
> FYI, I've followed Eric Engestroms' instructions for better Mesa <-> AppVeyor
> integration. (Thanks Eric.)
>
> I haven't tested, but hopefully this new integration method should now
> trigger Appveyor builds on pull requests too,
On Tuesday, 2019-08-27 10:57:38 +, Jose Fonseca wrote:
> With MinGW cross compilation.
2-4 are
Acked-by: Eric Engestrom
> ---
> src/util/os_misc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/util/os_misc.c b/src/util/os_misc.c
> index 755970430b0..436bc38604b 100644
> ---
For the series, Reviewed-by: Brian Paul
On 08/27/2019 04:57 AM, Jose Fonseca wrote:
Uses some of the same -Werror options used by Meson, as suggested by
Michel Daezer.
---
scons/gallium.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scons/gallium.py
On Tuesday, 2019-08-27 10:57:36 +, Jose Fonseca wrote:
> I don't know how Meson didn't hit this issue, when it too already uses
> -Werror=incompatible-pointer-types
Not sure either...
Fixes: 3dd299c3d5b88114894e ("glx: Sync with Khronos")
Reviewed-by: Eric Engestrom
> ---
>
On Tue, 27 Aug 2019 12:36:42 +0200
Boris Brezillon wrote:
> list_for_each_entry() does not allow modifying the current item pointer.
> Let's rework the skip-instructions logic in schedule_block() to not
> break this rule.
>
> Signed-off-by: Boris Brezillon
> ---
>
Build mesa 1 completed
Commit e4df7ffc23 by Paulo Zanoni on 8/14/2019 12:02 AM:
intel/fs: grab fail_msg from v32 instead of v16 when v32->run_cs fails
Configure your notification preferences
___
mesa-dev
Uses some of the same -Werror options used by Meson, as suggested by
Michel Daezer.
---
scons/gallium.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scons/gallium.py b/scons/gallium.py
index 21197c8d0d1..2eff4174257 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
MinGW headers already define it.
---
src/util/u_string.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/util/u_string.h b/src/util/u_string.h
index 5fea8f17e73..361dcb41e2b 100644
--- a/src/util/u_string.h
+++ b/src/util/u_string.h
@@ -110,7 +110,10 @@ util_asprintf(char **str, const
I don't know how Meson didn't hit this issue, when it too already uses
-Werror=incompatible-pointer-types
---
src/mesa/drivers/x11/glxapi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/x11/glxapi.h b/src/mesa/drivers/x11/glxapi.h
index
With MinGW cross compilation.
---
src/util/os_misc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/util/os_misc.c b/src/util/os_misc.c
index 755970430b0..436bc38604b 100644
--- a/src/util/os_misc.c
+++ b/src/util/os_misc.c
@@ -38,6 +38,7 @@
#endif
#include
#include
+#include
On Tue, 13 Aug 2019 15:30:20 -0700
Alyssa Rosenzweig wrote:
> > I don't see any remove_ins()/insert_before() call in there. Do you see
> > any reason for using the _safe() variant here?
>
> Er, I think I meant the outer loop, which has a remove/insert pair at
> the bottom to change the
mir_foreach_instr_in_block_safe() is based on list_for_each_entry_safe()
which is designed to protect against removal of the current entry, but
removing the entry placed just after the current one will lead to a
use-after-free situation.
Luckily, the midgard_pair_load_store() logic guarantees
Right now we're leaking all block and instruction objects allocated by
the compiler. Let's clean things up before leaving
midgard_compile_shader_nir().
Signed-off-by: Boris Brezillon
---
src/panfrost/midgard/compiler.h| 12
src/panfrost/midgard/midgard_compile.c | 3 +++
2
To avoid memory leaks.
Signed-off-by: Boris Brezillon
---
src/panfrost/midgard/compiler.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index 099d108142b1..f9ba31b5959d 100644
--- a/src/panfrost/midgard/compiler.h
+++
Add an assert() in schedule_bundle() to make sure all instruction
pointers in bundle.instructions[] are valid.
Signed-off-by: Boris Brezillon
---
src/panfrost/midgard/midgard_schedule.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/panfrost/midgard/midgard_schedule.c
list_for_each_entry() does not allow modifying the current item pointer.
Let's rework the skip-instructions logic in schedule_block() to not
break this rule.
Signed-off-by: Boris Brezillon
---
src/panfrost/midgard/midgard_schedule.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
FYI, I've followed Eric Engestroms' instructions for better Mesa <-> AppVeyor
integration. (Thanks Eric.)
I haven't tested, but hopefully this new integration method should now trigger
Appveyor builds on pull requests too, which should come handy.
I'm still keeping the old webhook method
On 27/8/19 11:13, Zhaowei Yuan wrote:
Four bytes of src_surf will be compressed into a 32-bits data
and stored into dst_surf, and dst_surf is read as z-order,so
its width must be aligned to multiples of 8(4x2) before devided
by 2.
Signed-off-by: Zhaowei Yuan
Bugzilla:
Four bytes of src_surf will be compressed into a 32-bits data
and stored into dst_surf, and dst_surf is read as z-order,so
its width must be aligned to multiples of 8(4x2) before devided
by 2.
Signed-off-by: Zhaowei Yuan
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111266
---
On 26/8/19 13:28, abergme...@gmx.net wrote:
For a few weeks now I am working on implementing Vulkan for VideoCore
6 AKA 42 (using V3D/DRM). Don't hold you breath ;)
Currently I am trying to understand what is necessary or how to
interact with V3D. So I am looking at TransformFeedback because
https://bugs.freedesktop.org/show_bug.cgi?id=111493
--- Comment #3 from Samuel Pitoiset ---
5544b2cbbd23df82192aea09d909b5cc2c1f1af9 is the first bad commit
commit 5544b2cbbd23df82192aea09d909b5cc2c1f1af9
Author: Ian Romanick
Date: Tue Jan 23 17:35:51 2018 +0800
nir/algebraic: Use value
https://bugs.freedesktop.org/show_bug.cgi?id=111496
Bug ID: 111496
Summary: dEQP-GLES31.functional.shaders.builtin_functions.integ
er.umulextended.uint_highp_vertex fails with bad
intrinsic
Product: Mesa
Version:
https://bugs.freedesktop.org/show_bug.cgi?id=111493
--- Comment #2 from Samuel Pitoiset ---
Works perfectly fine with Mesa 19.1.5.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=111493
--- Comment #1 from Samuel Pitoiset ---
I can reproduce this, is this something recent for you? I think that game used
to work in the past.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for
ACK.
On 8/26/19 9:05 PM, Marek Olšák wrote:
Hi,
I'd like to push the Navi14 merge request to 19.2 no later than
Tuesday August 27.
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1726
Please ack if it's OK with you,
Thanks,
Marek
___
49 matches
Mail list logo
