than just these two possible.
Cc: 11.2 12.0 13.0
Signed-off-by: Steinar H. Gunderson
---
src/mesa/main/hash.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
index 7d8a5fd..670438a 100644
--- a/src/mesa/main/h
erapi.c:1259)
==13727==by 0x60FA618: movit::EffectChain::execute_phase(movit::Phase*,
bool, std::set, std::allocator >*,
std::map,
std::allocator > >*,
std::set, std::allocator
>*) (effect_chain.cpp:1885)
Cc: 11.2 12.0 13.0
Signed-off-by: Steinar H. Gunderson
---
src/me
On Mon, Nov 07, 2016 at 08:54:13AM +1100, Timothy Arceri wrote:
> The problem is is can happen totally unintentionally. Anyway I've sent
> a couple of patches as a follow-up to your series, one to fix it and
> one to make use of it.
>
> https://patchwork.freedesktop.org/series/14902/
Great, thank
On Mon, Nov 07, 2016 at 08:42:18AM +1100, Timothy Arceri wrote:
>> Interesting. So other code seemingly has done refcounting with non-
>> atomics but with locking; those locks were just missing here.
> I was trying to point you to the fact that locking is known to be
> broken in some places in case
On Sun, Nov 06, 2016 at 09:40:03AM +1100, Timothy Arceri wrote:
> https://lists.freedesktop.org/archives/mesa-dev/2016-October/132629.html
Interesting. So other code seemingly has done refcounting with non-atomics
but with locking; those locks were just missing here.
(I've skipped the finer point
On Sun, Nov 06, 2016 at 09:35:37AM +1100, Timothy Arceri wrote:
> Can you please change this line to say something like. With this change
> we switch to using a recursive mutex, which avoids the deadlock.
Rewording.
> I was a little confused. At first I thought it was already using a
> recursive
erapi.c:1259)
==13727==by 0x60FA618: movit::EffectChain::execute_phase(movit::Phase*,
bool, std::set, std::allocator >*,
std::map,
std::allocator > >*,
std::set, std::allocator
>*) (effect_chain.cpp:1885)
Cc: 11.2 12.0 13.0
Signed-off-by: Steinar H. Gunderson
---
src/me
more interactions than just these two possible.
Cc: 11.2 12.0 13.0
Signed-off-by: Steinar H. Gunderson
---
src/mesa/main/hash.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
index 7d8a5fd..670438a 100644
--- a/src/mesa
tps://www.sesse.net/
>From 284d8492fd04ddc4ade954f86240760443840aeb Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson"
Date: Tue, 2 Feb 2016 01:16:51 +0100
Subject: [PATCH] Fix locking of GLsync objects.
GLsync objects had a race condition when used from multiple threads
(which is the m
On Mon, Feb 01, 2016 at 04:00:09PM +0100, Marek Olšák wrote:
> Sorry, I'm withdrawing my statement.
>
> Look at this code:
>
> _mesa_ObjectPtrLabel(const void *ptr, GLsizei length, const GLchar *label)
> {
> GET_CURRENT_CONTEXT(ctx);
> - struct gl_sync_object *const syncObj = (struct gl_s
get_and_ref_sync()?
> Sounds good to me.
Attached new version, also with updated description as requested.
/* Steinar */
--
Homepage: https://www.sesse.net/
>From 02aa94468dc31e1ef598eadaad8995b0178fedc7 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson"
Date: Tue, 26 Jan
On Wed, Dec 09, 2015 at 11:42:59AM +0100, Steinar H. Gunderson wrote:
>> Might be worth keeping _mesa_ref_sync_object(), even if it's an inline
>> wrapper around the above. As things get a bit confusing - foo_get vs
>> foo_unref.
> What about _mesa_get_and_ref_sync()?
On Wed, Dec 09, 2015 at 10:35:25AM +, Emil Velikov wrote:
>> I was told that it's easier for people to review my patch if it comes in via
>> email than being stuck in the bug tracker; FWIW, this is for bug 120238.
> Which bugtracker it this ? bugs.fd.o does not like the number
> mentioned. Plea
00:00 2001
From: "Steinar H. Gunderson"
Date: Tue, 1 Dec 2015 22:05:11 +0100
Subject: [PATCH] Fix locking of GLsync objects.
GLsync objects had a race condition when used from multiple threads
(which is the main point of the extension, really); it could be
validated as a sync object at
14 matches
Mail list logo
