[Bug 110796] [REGRESSION] [BISECTED] [GLESCTS] race between destruction of types and shader compilation (?)
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Mon Aug 26 06:25:03 UTC 2019
https://bugs.freedesktop.org/show_bug.cgi?id=110796
Tapani Pälli <lemody at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #30 from Tapani Pälli <lemody at gmail.com> ---
Fixed in master by:
--- 8< ---
commit e4da8b9c331cc3ae1b86b3a7860231e202463db0
Author: Lionel Landwerlin <lionel.g.landwerlin at intel.com>
Date: Wed Jul 31 12:12:10 2019 +0300
mesa/compiler: rework tear down of builtin/types
The issue we're running into when running CTS is that glsl types are
deleted while builtins depending on them are not.
This happens because on one hand we have glsl types ref counted, but
builtins are not. Instead builtins are destroyed when unloading libGL
or explicitly calling glReleaseShaderCompiler().
This change removes almost entirely any dealing with glsl types
ref/unref by letting the builtins deal with it instead. In turn we
introduce a builtin ref count mechanism. Each GL context takes a
reference on the builtins when compiling a shader for the first time.
It releases the reference when the context is destroyed. It can also
explicitly release those when glReleaseShaderCompiler() is called.
Finally we also take a reference on the glsl types when loading libGL
to avoid recreating glsl types too often.
v2: Ensure we take a reference if we don't have one in link step (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin at intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110796
Reviewed-by: Eric Anholt <eric at anholt.net>
Reviewed-by: Tapani Pälli <tapani.palli at intel.com>
--
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20190826/02c479ed/attachment.html>
More information about the intel-3d-bugs
mailing list