https://bugs.freedesktop.org/show_bug.cgi?id=98002
--- Comment #12 from Clément Guérin ---
For some reason it doesn't work either with Firefox here, but it's fine with
Epiphany (GNOME Web).
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=98595
--- Comment #6 from Timothy Arceri ---
(In reply to Jonathan Gray from comment #5)
> Indeed the abort is not triggered with gcc 4.9 but is with gcc 4.2.1.
>
> For gcc < 4.4.3 and for clang HAS_TRIVIAL_DESTRUCTOR is set to
> __has_trivial_destruc
https://bugs.freedesktop.org/show_bug.cgi?id=98606
Bug ID: 98606
Summary: Compile error in gallium target VA--LLVM undefined
referencences
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=98595
--- Comment #5 from Jonathan Gray ---
Indeed the abort is not triggered with gcc 4.9 but is with gcc 4.2.1.
For gcc < 4.4.3 and for clang HAS_TRIVIAL_DESTRUCTOR is set to
__has_trivial_destructor(T) otherwise it is (false).
Everything worked la
https://bugs.freedesktop.org/show_bug.cgi?id=98002
almos changed:
What|Removed |Added
CC||aaalmo...@gmail.com
--- Comment #11 from almos
https://bugs.freedesktop.org/show_bug.cgi?id=98002
--- Comment #10 from Clément Guérin ---
almos, disabling your ad blocker should do the trick. Sorry about that.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
On 05/11/16 19:57, Chris Wilson wrote:
> Currently we signal the availabilty of the query result using an
typo: availability (this also affects commit message)
> unordered pipe-control write. As it is unordered, it may be executed
> before the write of the query result itself - and so an observer m
On Sat, 2016-11-05 at 15:37 +0100, Steinar H. Gunderson wrote:
> These were racy when using the same shaders (seemingly even from
> different
> program objects) on multiple theads sharing the same objects, leading
> to
> issues such as (excerpts from an apitrace dump from a real
> application):
I'
On Sat, 2016-11-05 at 15:28 +0100, Steinar H. Gunderson wrote:
> There is currently no protection against walking a hash (using
> _mesa_HashWalk()) and modifying it at the same time, for instance by
> inserting
> or deleting elements. This leads to segfaults in multithreaded code
> if e.g.
> someon
On Nov 5, 2016 9:03 PM, "Mauro Rossi" wrote:
>
> 2016-11-05 18:58 GMT+01:00 Marek Olšák :
> > Hi,
> >
> > I pushed the patch from the bug report. Hopefully it's the same as this
one.
> >
> > Marek
>
> Hi Marek, thanks,
> it is identical.
>
> As a side note, for any people trying to build mesa-dev
2016-11-05 18:58 GMT+01:00 Marek Olšák :
> Hi,
>
> I pushed the patch from the bug report. Hopefully it's the same as this one.
>
> Marek
Hi Marek, thanks,
it is identical.
As a side note, for any people trying to build mesa-dev for android,
a problem affecting our nougat-x86 x84_64 build is tha
Currently we signal the availabilty of the query result using an
unordered pipe-control write. As it is unordered, it may be executed
before the write of the query result itself - and so an observer may
read the query result too early. Fix this by requesting that the write
of the availablity flag i
On Sat, Nov 5, 2016 at 1:03 PM, Ilia Mirkin wrote:
> The previous code was confused about whether slot_end was inclusive or
> exclusive. Make it so that it is inclusive consistently, and use it for
> setting the new location. This should also better deal with arrays of
> incomplete size, since the
On 11/05/2016 06:06 PM, Ilia Mirkin wrote:
On Sat, Nov 5, 2016 at 12:56 PM, Samuel Pitoiset
wrote:
Instead, hardcode group sigsel because there are a bunch of unknown
groups, especially on SM50/SM52.
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/nvc0/nvc0_query_hw_sm.c| 11
On 11/05/2016 11:38 AM, Marek Olšák wrote:
From: Marek Olšák
The first IF statement disabled the second one.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98599
---
src/gallium/auxiliary/tgsi/tgsi_scan.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/g
https://bugs.freedesktop.org/show_bug.cgi?id=98595
--- Comment #4 from Marek Olšák ---
It's not a duplicated of that bug.
This bug is different. It looks like the HAS_TRIVIAL_DESTRUCTOR macro isn't
done correctly on OpenBSD.
--
You are receiving this mail because:
You are the assignee for the
Reviewed-by: Marek Olšák
Marek
On Sat, Nov 5, 2016 at 7:00 PM, Brian Paul wrote:
> This fixes random crashes with MSVC release builds. It seems the
> members are implicitly initialized to zero with gcc, but not MSVC.
> In particular, the tex_offset_num_offset field was non-zero causing
> a loo
https://bugs.freedesktop.org/show_bug.cgi?id=98595
--- Comment #3 from Mark Janes ---
I can't say that this is a duplicate of bug 98592, which was fixed for intel
hardware on linux.
--
You are receiving this mail because:
You are the assignee for the bug.
This fixes random crashes with MSVC release builds. It seems the
members are implicitly initialized to zero with gcc, but not MSVC.
In particular, the tex_offset_num_offset field was non-zero causing
a loop over the NULL tex_offsets array to crash.
Zero-init those fields and a few others to be sa
Hi,
I pushed the patch from the bug report. Hopefully it's the same as this one.
Marek
On Sat, Nov 5, 2016 at 1:21 PM, Mauro Rossi wrote:
> Hi Nicolai,
>
> please review the attached patch which is necessary fix android build,
> as per https://bugs.freedesktop.org/show_bug.cgi?id=98573
>
> Test
https://bugs.freedesktop.org/show_bug.cgi?id=98595
--- Comment #2 from Marek Olšák ---
For some reason, OpenBSD things symbol_table_entry has a non-trivial destructor
and calls ralloc_set_destructor. However, it doesn't have a non-trivial
destructor. This looks like a C++ compiler bug.
--
You a
From: Marek Olšák
---
src/gallium/auxiliary/tgsi/tgsi_scan.c | 44 +++---
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 26cb2be..40a1340 100644
--- a/src/gallium/a
From: Marek Olšák
The first IF statement disabled the second one.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98599
---
src/gallium/auxiliary/tgsi/tgsi_scan.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
b/src/galliu
https://bugs.freedesktop.org/show_bug.cgi?id=98599
--- Comment #5 from Marek Olšák ---
Thanks. I see the problem.
--
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
me
On Sat, Nov 5, 2016 at 12:56 PM, Samuel Pitoiset
wrote:
> Instead, hardcode group sigsel because there are a bunch of unknown
> groups, especially on SM50/SM52.
>
> Signed-off-by: Samuel Pitoiset
> ---
> .../drivers/nouveau/nvc0/nvc0_query_hw_sm.c| 112
> ++---
> 1 file
The previous code was confused about whether slot_end was inclusive or
exclusive. Make it so that it is inclusive consistently, and use it for
setting the new location. This should also better deal with arrays of
incomplete size, since the slot check will assume it gets packed.
Signed-off-by: Ilia
Instead of packing varyings into vec4's, keep track of how many
components each slot uses and create varyings with matching types. This
ensures that we don't end up using more components than the orginal
shader, which is especially important for geometry shader output limits.
Signed-off-by: Ilia M
https://bugs.freedesktop.org/show_bug.cgi?id=98599
--- Comment #4 from Andy Furniss ---
Created attachment 127792
--> https://bugs.freedesktop.org/attachment.cgi?id=127792&action=edit
xterm menu bad rendering
So I rechecked by reset --hard onto bad and then the one before and the one
before is
https://bugs.freedesktop.org/show_bug.cgi?id=98599
--- Comment #3 from Andy Furniss ---
(In reply to Marek Olšák from comment #1)
> The X server doesn't use shader images, so I think the bisection went wrong.
> The X server should be restarted for every bisection step.
It seemed like a clean bis
https://bugs.freedesktop.org/show_bug.cgi?id=98555
--- Comment #2 from Alan Swanson ---
Same error occurs with amdgpu running libdrm 2.4.71 and mesa git. However issue
only occurrs when using NWUser which wraps various file and dir functions to
provide per user settings and saves. Haven't played
Instead, hardcode group sigsel because there are a bunch of unknown
groups, especially on SM50/SM52.
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/nvc0/nvc0_query_hw_sm.c| 112 ++---
1 file changed, 56 insertions(+), 56 deletions(-)
diff --git a/src/gallium/driv
https://bugs.freedesktop.org/show_bug.cgi?id=98599
--- Comment #2 from Ilia Mirkin ---
(In reply to Marek Olšák from comment #1)
> The X server doesn't use shader images, so I think the bisection went wrong.
> The X server should be restarted for every bisection step.
It probably does via GLAMOR
https://bugs.freedesktop.org/show_bug.cgi?id=98599
--- Comment #1 from Marek Olšák ---
The X server doesn't use shader images, so I think the bisection went wrong.
The X server should be restarted for every bisection step.
--
You are receiving this mail because:
You are the QA Contact for the b
These were racy when using the same shaders (seemingly even from different
program objects) on multiple theads sharing the same objects, leading to
issues such as (excerpts from an apitrace dump from a real application):
1097 @0 glCreateProgram() = 9
1099 @0 glAttachShader(program = 9, shader
There is currently no protection against walking a hash (using
_mesa_HashWalk()) and modifying it at the same time, for instance by inserting
or deleting elements. This leads to segfaults in multithreaded code if e.g.
someone calls glTexImage2D (which may have to walk the list of FBOs) while
anothe
https://bugs.freedesktop.org/show_bug.cgi?id=98599
Andy Furniss changed:
What|Removed |Added
CC||mar...@gmail.com
--
You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=98599
Bug ID: 98599
Summary: xterm menus corrupt since tgsi/scan: handle indirect
image indexing correctly
Product: Mesa
Version: git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=98595
Timothy Arceri changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
On Nov 5, 2016 1:19 PM, "Christian König" wrote:
>
> Am 04.11.2016 um 17:43 schrieb Marek Olšák:
>>
>> On Fri, Nov 4, 2016 at 5:23 PM, Alex Deucher
wrote:
>>>
>>> On Fri, Nov 4, 2016 at 10:57 AM, Marek Olšák wrote:
On Nov 4, 2016 3:29 PM, "Emil Velikov"
wrote:
>
> On 31 Octobe
https://bugs.freedesktop.org/show_bug.cgi?id=98563
--- Comment #5 from Andrew Poelstra ---
Created attachment 127790
--> https://bugs.freedesktop.org/attachment.cgi?id=127790&action=edit
Photo of kernel panic when plugging in UGA-4KDP with libdrm
677cd97dc4a930af508388713f5016baf664ed18
--
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=98563
--- Comment #4 from Andrew Poelstra ---
(In reply to Emil Velikov from comment #3)
> The following libdrm commit should fix it. Please apply it locally and let
> me know if it works.
>
> commit 677cd97dc4a930af508388713f5016baf664ed18
> Author:
https://bugs.freedesktop.org/show_bug.cgi?id=79858
--- Comment #5 from Edward O'Callaghan ---
(In reply to Michel Dänzer from comment #3)
> I think this is more likely a generic DRI2 issue related to front buffer
> rendering than anything driver specific.
Correct yes,
Run blender with `LIBGL_DR
Hi Nicolai,
please review the attached patch which is necessary fix android build,
as per https://bugs.freedesktop.org/show_bug.cgi?id=98573
Tested with nougat-x86 build
Kind regards
Mauro
>From 36777861d42ec5ae0c0ed6a60835c76d13e38555 Mon Sep 17 00:00:00 2001
From: Mauro Rossi
Date: Sat, 5 N
Am 04.11.2016 um 17:43 schrieb Marek Olšák:
On Fri, Nov 4, 2016 at 5:23 PM, Alex Deucher wrote:
On Fri, Nov 4, 2016 at 10:57 AM, Marek Olšák wrote:
On Nov 4, 2016 3:29 PM, "Emil Velikov" wrote:
On 31 October 2016 at 15:12, Marek Olšák wrote:
First, DRI_PRIME should work OK on radeon & amd
2016-11-05 2:50 GMT+01:00 Ian Romanick :
> (Sorry about the top post. Sent from my phone.)
>
> That expression will allow versions like 0130 as valid. If you just want to
> allow 0, you need a more complex regular expression. I feel like that's
> just a bandage... what about other bad values like
On 04/11/16 22:27, Timothy Arceri wrote:
> On Fri, 2016-11-04 at 18:43 +0100, Alejandro Piñeiro wrote:
>> Nitpick: I found the commit message hard to understand until I read
>> the
>> summary.
> Ok I'll duplicate some of the summary in the commit message.
Ok, thanks.
>> On 03/11/16 11:47, Timot
On Fri, Nov 04, 2016 at 05:59:29PM -0700, Jason Ekstrand wrote:
>On Nov 4, 2016 2:30 AM, "Pohjolainen, Topi"
><[1]topi.pohjolai...@gmail.com> wrote:
>>
>> On Fri, Nov 04, 2016 at 11:17:13AM +0200, Pohjolainen, Topi wrote:
>> > On Fri, Oct 28, 2016 at 02:17:12AM -0700, Jason Ekst
https://bugs.freedesktop.org/show_bug.cgi?id=98595
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
48 matches
Mail list logo
