[Mesa-dev] [PATCH 4/9] prog; add weak _mesa_error_no_memory() symbol and add it to libglsl_util

Emil Velikov emil.l.velikov at gmail.com
Thu Apr 16 04:10:12 PDT 2015


On 16 April 2015 at 11:50, Jose Fonseca <jfonseca at vmware.com> wrote:
> 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.
>
Fwiw here are the sources required in order for one to use nir
(haven't gone through the headers)

glsl/glsl_types.cpp
glsl/builtin_types.cpp
glsl/glsl_symbol_table.cpp

plus the following three (also know as libglsl_util)

mesa/main/imports.c
mesa/program/prog_hash_table.c << this one is different from
src/util/hash_table.c or the one we have in gallium
mesa/program/symbol_table.c

> 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.)
>
One could hack the current automake approach in SCons without a
problem. It won't be pretty though.

-Emil

P.S. Is it me or does most users of ralloc do not handle OOM conditions ?


More information about the mesa-dev mailing list