[Mesa-dev] [PATCH 4/9] prog; add weak _mesa_error_no_memory() symbol and add it to libglsl_util
Jose Fonseca
jfonseca at vmware.com
Thu Apr 16 03:50:05 PDT 2015
On 15/04/15 23:25, Rob Clark wrote:
> On Wed, Apr 15, 2015 at 6:15 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 04/15/2015 10:56 AM, Emil Velikov wrote:
>>> On 15 April 2015 at 18:33, Matt Turner <mattst88 at gmail.com> wrote:
>>>> On Wed, Apr 15, 2015 at 7:08 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>> Rather than forcing everyone to provide their own definition of the symbol
>>>>> provide a common weak one, which anyone can override if needed.
>>>>>
>>>>> This resolved the build of the standalone pipe-drivers, as it provides a
>>>>> default symbol which was missing previously.
>>>>>
>>>>> Cc: Rob Clark <robclark at freedesktop.org>
>>>>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>>>>> ---
>>>>> src/Makefile.am | 3 ++-
>>>>> src/glsl/SConscript | 2 ++
>>>>> src/mesa/Android.libmesa_glsl_utils.mk | 6 ++++--
>>>>> src/mesa/program/weak_errors.c | 30 ++++++++++++++++++++++++++++++
>>>>
>>>> Is program/ really the right place for this? (maybe main/ instead?)
>>> Hmm main/ might be better indeed. If there are any recommendations
>>> about the name I'll gladly take it :)
>>
>> So... who is going to use this other than src/glsl/main.cpp and
>> src/glsl/tests? It seems like you could just put the (non-weak) symbol
>> in a common file that only those things link.
>>
>> Is the goal just code sharing, or is the goal partitioning src/glsl from
>> src/mesa? The former probably isn't worth the effort, and the latter
>> should have a more systematic approach... and I could get behind that.
>
> fwiw, the goal is sharing libnir (both vc4 and freedreno/ir3 use it,
> and I expect others might like to at some point).. but that currently
> brings along some glsl dependencies, which bring along the
> _mesa_error_no_memory() dependency..
I wonder if it would be better to have glsl depend on nir (ie move the
glsl bits nir needs into nir), so that nir can be safely inside gallium
drivers which shouldn't depend on OpenGL specific headers.
I guess the issue here is that nir is not built universally (in
particular we need to update scons to start using it for Windows builds.)
Jose
More information about the mesa-dev
mailing list