Instead of having functions to add values and set various things, we just
have a function that does a few asserts and then returns the value. The
caller is then responsible for setting the various fields.
If we don't do this then recursive meta is completely broken. What happens
is that the outer meta call may change the bindings pointer and the inner
meta call will change it again and, when it exits set it back to the
default. However, the outer meta call may be relying on it being left
alone so it uses the non-meta descriptor sets instead of its own.
Previously, the GLSL_VK_SHADER macro didn't work if the shader contained
commas outside of parentheses due to the way the C preprocessor works.
This commit fixes this by making it variadic again and doing it correctly
this time.
Changes generated by:
cd src/mapi/glapi/gen
for i in *.xml; do
cat $i |\
sed 's/[[:space:]]*offset="[^"]*">/>/' |\
sed 's/[[:space:]]*offset="[^"]*"[[:space:]]*$//' |\
sed 's/[[:space:]]*offset="[^"]*"[[:space:]]*/ /' > x
mv x $i
done
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Comparing the output of
nm -D libGL.so.349.16 | grep ' T gl[^X]' | sed 's/.* T //'
between Catalyst NVIDIA 349.16 and this commit, the only change is a bunch
of functions that NVIDIA exports that Mesa does not.
If a function is not statically exported by either of the major binary
drivers on Linux, there is almost zero chance that any application
statically links with it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Comparing the output of
nm -D arch/x86_64/usr/X11R6/lib64/fglrx/fglrx-libGL.so.1.2 |\
grep ' T gl[^X]' | sed 's/.* T //'
between Catalyst 14.6 Beta and this commit, the only change is a bunch
of functions that AMD exports that Mesa does not and some OpenGL ES
1.1 functions that Mesa exported but AMD does not.
The OpenGL ES 1.1 functions (e.g., glAlphaFuncx) are added by extensions
in desktop. Our infrastructure doesn't allow us to statically export a
function in one lib and not in another. The GLES1 conformance tests
expect to be able to link with these functions, so we have to export
them.
If a function is not statically exported by either of the major binary
drivers on Linux, there is almost zero chance that any application
statically links with it.
As a side note... I find it odd that AMD exports glTextureBarrierNV but
not glTextureBarrier.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Comparing the output of
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
between 10.3.7 and this commit, the only change is the removal of
glFramebufferTextureFaceARB. This function was removed a couple commits
previously.
glClipControl was, at the time 10.3 shipped, a very new function. It
was added by GL_ARB_clip_control. That extension was ratified by the
Khronos Board of Promoters on August 7, 2014. It's less than a year
old, and I don't think it's is likely that there are many applications
using that extension... much less statically linking with the function.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Comparing the output of
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
between 10.4.7 and this commit, the only change is the removal of
glFramebufferTextureFaceARB. This function was removed a couple commits
previously.
None of these functions are particuarly new. If applications were not
statically linking them with 10.4.7, there's approximately zero chance
they will for 10.6.
Almost all of these functions are for GL_ARB_direct_state_access.
Since the whole DSA API wasn't statically exported (and the extension
wasn't enabled!), I think there's exactly zero chance anyone linked
against these symbols.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Comparing the output of
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
between 10.5.5 and this commit, the only change is the removal of
glFramebufferTextureFaceARB. This function was removed a couple commits
previously.
None of these functions are particuarly new. If applications were not
statically linking them with 10.5.5, there's approximately zero chance
they will for 10.6.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Changes generated by:
cd src/mapi/glapi/gen
for i in *.xml; do
cat $i |\
sed 's/[[:space:]]*static_dispatch="[^"]*">/>/' |\
sed 's/[[:space:]]*static_dispatch="[^"]*"[[:space:]]*$//' |\
sed 's/[[:space:]]*static_dispatch="[^"]*"[[:space:]]*/ /' > x
mv x $i
done
Comparing the output of
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
before and after this commit showed no differences.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
The set of functions with static dispatch is (supposed to be) defined by
the Linux OpenGL ABI. We export quite a few more functions than that
for historical reasons. However, this list should never grow.
This table is used instead of the static_dispatch tag in the XML to
generate the static dispatch functions. I used
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
before and after the change. diff showed no differences.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
Since the set of functions with static will never change, there is no
reason to store it in the XML. It's just one of those fields that
confuses people adding new functions.
This is split out from the rest of the series so that in-code assertions
can be used to verify that the data in the Python code matches the XML.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
Mesa does not (and probably never will) support GL_ARB_geometry_shader4,
so this function will never exist. Having a function that is
exec="skip" and offset="assign" is just weird.
There are still a couple 'exec="skip" offset="assign"' functions
remaining. These remain because we either support GLX protocol for them
(glSampleMaskSGIS and glSamplePatternSGIS) or older DRI drivers still
need them in the dispatch table (glResizeBuffersMESA). The SGIS
functions can be removed later.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Jason Ekstrand