On Tue, Dec 20, 2016 at 11:52:26AM -0800, Kenneth Graunke wrote:
> On Tuesday, December 20, 2016 12:08:06 PM PST Jonathan Gray wrote:
> > Can someone push this to master?
>
> Pushed:
>
> To ssh://git.freedesktop.org/git/mesa/mesa
>ab8ea1b..62b8bcd master -> master
>
> Have you thought about
On Tuesday, December 20, 2016 12:08:06 PM PST Jonathan Gray wrote:
> Can someone push this to master?
Pushed:
To ssh://git.freedesktop.org/git/mesa/mesa
ab8ea1b..62b8bcd master -> master
Have you thought about applying for commit access?
signature.asc
Description: This is a digitally signe
Can someone push this to master?
On Sun, Dec 11, 2016 at 07:21:36PM +0100, Eduardo Lima Mitev wrote:
> Looks good.
>
> Reviewed-by: Eduardo Lima Mitev
>
> On 12/11/2016 04:42 PM, Jonathan Gray wrote:
> > Commit 929fcee47e46781c57f2a354ce0a013915c033d1 introduced code that
> > attempts to unlock
Previously there was no _mesa_unlock_debug_state() call at all,
one is still retained here for the case where _mesa_lock_debug_state()
is called and did not return NULL (which is documented as being
unlocked).
On Mon, Dec 12, 2016 at 11:40:32AM +1100, Edward O'Callaghan wrote:
> Hold up..
>
> Doe
Hold up..
Does this reintroduce the hang in glsl-fs-loop piglit test with
MESA_DEBUG=context though? Was that tested? I'm interested to know how
this got so muddled up in the first place.
Kind Regards,
Edward.
On 12/12/2016 05:21 AM, Eduardo Lima Mitev wrote:
> Looks good.
>
> Reviewed-by: Edua
Looks good.
Reviewed-by: Eduardo Lima Mitev
On 12/11/2016 04:42 PM, Jonathan Gray wrote:
> Commit 929fcee47e46781c57f2a354ce0a013915c033d1 introduced code that
> attempts to unlock an unlocked mutex which is undefined behaviour.
>
> On OpenBSD this leads to an abort:
>
> 0 0x124dadfa96ba
Commit 929fcee47e46781c57f2a354ce0a013915c033d1 introduced code that
attempts to unlock an unlocked mutex which is undefined behaviour.
On OpenBSD this leads to an abort:
0 0x124dadfa96ba in thrkill () at :2
1 0x124dadf3da39 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
2 0