| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
| |
Without this the next patch will try to put these functions in the
dispatch table in indirect_init.c.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
| |
[Fredrik: Fix the name of the buf parameter in the XML file]
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
| |
[Fredrik: Fix the name of the buf parameter in the XML file]
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ARB_direct_state_access specification says (as of 2015.02.05):
"Interactions with OpenGL 4.3 or ARB_framebuffer_no_attachments
If neither OpenGL 4.3 nor ARB_framebuffer_no_attachments are supported,
ignore the support for NamedFramebufferParameteri and
GetNamedFramebufferParameteriv."
This commit adds stubs for these entry points.
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Mesa's ClearBuffer framework is very complicated and thoroughly married to the
object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
complicated. At some point, we should implement buffer clearing for arbitrary
framebuffer objects, but for now, we will just wrap ClearBuffer.
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Mesa's ClearBuffer framework is very complicated and thoroughly married to the
object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
complicated. At some point, we should implement buffer clearing for arbitrary
framebuffer objects, but for now, we will just wrap ClearBuffer.
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Mesa's ClearBuffer framework is very complicated and thoroughly married to the
object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
complicated. At some point, we should implement buffer clearing for arbitrary
framebuffer objects, but for now, we will just wrap ClearBuffer.
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Mesa's ClearBuffer framework is very complicated and thoroughly married to the
object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
complicated. At some point, we should implement buffer clearing for arbitrary
framebuffer objects, but for now, we will just wrap ClearBuffer.
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
|
|
| |
[Fredrik: - Update one of the error messages to reflect that the
framebuffer might not be the bound framebuffer.
- Whitespace fixes.]
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
|
| |
[Fredrik: - Retain the debugging code in CheckFramebufferStatus.
- Whitespace fixes.]
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits off the (still) rather large chunk that is
get_texture_for_framebuffer into lots of smaller functions specialized to
service the wide variety of unique needs of *FramebufferTexture* entry points.
The result is much cleaner because, rather than having a pile of branches and
confusing conditions (like the boolean layered), the uniqueness is baked into
the entry points. The entry points know whether or not they are layered or use
a textarget.
[Fredrik: - Mention the value of <textarget> in the error message.
- Rename check_zoffset to check_layer, and zoffset to layer.
The zoffset parameter was renamed to layer in
ARB_framebuffer_object.
- Make layered a GLboolean since the value is visible to the API.
- Remove EXT suffixes in refactored code.
- Whitespace fixes.]
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Fredrik: - Remove the DummyRenderbuffer checks now that they are
done in _mesa_lookup_renderbuffer_err.
- Fix the <renderbuffertarget> name in error messages.
- Make the error message in _mesa_framebuffer_renderbuffer
reflect that <fb> might not be the bound framebuffer.
- Remove EXT suffixes from GL tokens.]
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
| |
[Fredrik: Whitespace fixes]
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
| |
* The Haiku glapi has a C++ wrapper around the dispatch code.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
v2: Fix the name of the entry point in the error messages.
Reviewed-by: Laura Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Laura Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Laura Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Laura Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Laura Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Laura Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Laura Ekstrand <[email protected]>
|
|
|
|
|
|
| |
v2: Add a doxygen comment.
Reviewed-by: Laura Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Laura Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Laura Ekstrand <[email protected]>
|
|
|
|
|
|
| |
v2: Update the documentation for gen_vertex_arrays().
Reviewed-by: Laura Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
This just adds the glapi bits.
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix build error introduced with commit 1c5a57a "glapi/es3.1: Add support
for GLES versions > 3.0" with Python < 2.7.
File "src/mapi/glapi/gen/gl_genexec.py", line 230, in <module>
printer.Print(api)
File "src/mapi/glapi/gen/gl_XML.py", line 120, in Print
self.printBody(api)
File "src/mapi/glapi/gen/gl_genexec.py", line 187, in printBody
condition_parts.append('(ctx->API == API_OPENGLES2 && ctx->Version >= {})'.format(int(f.api_map['es2'] * 10)))
ValueError: zero length field name in format
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the checks in the Python script and the generated code more generic
to support arbitrary GLES versions >= 2.0.
The updated dispatch_sanity.cpp test discovered this problem. Without
this, the next patch would erroneously enable GLES 3.1 functions in GLES
2.0 and GLES 3.0.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
| |
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
|
|
| |
File glapi_entrypoint.c calls memcpy() function, but does not include
string.h header. So compilation can fail at error: implicit declaration
of function 'memcpy'.
Signed-off-by: Jose Fonseca <[email protected]>
|