| Age | Commit message (Collapse) | Author |
|---|
|
When the mode is on, the scripts would generate headers that are
suitable for OpenGL ES. There are two differences. One is that they
will generate function prototypes for OpenGL ES specific functions. The
other is that, when a function has multiple names, SET/GET/CALL macros
would be generated for each of names.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
|
The test is done by checking if the offset is manually assigned. The
generated headers are unchanged.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
|
This is made possible by making glapioffsets.h and glapidispatch.h
internal headers of glapi. They should only be included indirectly
through dispatch.h by mesa.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
|
tells the scripts to assign an available offset to the function. The
important changes are in src/mesa/glapi/gl_XML.py and
src/mesa/glapi/*.xml.
Since the DRI drivers only depend on functions required by the ABI
(e.g., GL 1.2 + ARB_multitexture) having fixed offsets, all functions
not in the ABI use "assign" mode. This has caused the offset of
basically every function outside the ABI to change. I have verified
that a libGL with this patch works with a DRI driver without the patch.
Futher, several function were removed from the dispatch tables
altogether. These are the functions for the following extensions:
GL_SGIS_texture_filter4
GL_SGIS_texture4D
GL_SGIS_detail_texture
GL_SGIS_sharpen_texture
GL_SGIX_sprite
GL_SGIX_instruments
GL_SGIX_framezoom
GL_SGIX_tag_sample_buffer
GL_SGIX_reference_plane
GL_SGIX_flush_raster
GL_SGIX_list_priority
GL_SGIX_fragment_lighting
GL_PGI_misc_hints
GL_EXT_index_material
GL_EXT_index_func
GL_3DFX_tbuffer
This removes 50 functions from the dispatch table.
|
|
CALL_by_offset, SET_by_offset, and GET_by_offset all had various problems.
The core issue is that parts of the device-independent code in Mesa assumes
that all functions have slots in the dispatch table. This is especially
true in the display list code. It will merrilly try to set dispatch
pointers for glVertexAttrib1fARB even if GL_ARB_vertex_program is not
supported. When the GET/SET/CALL macros are invoked, they would read a 0
from the remap table. The problem is that 0 is the dispatch offset for
glNewList!
One change is that the remap table is now initialized to be full of -1
values. In addtion, all of the *_by_offset marcos misbehave in an obvious
way if the specified offset is -1. SET_by_offset will do nothing,
GET_by_offset will return NULL, and CALL_by_offset, since it uses
GET_by_offset, will segfault.
I also had to add GL_EXT_blend_func_separate to the list of default
extensions in all_mesa_extensions (src/mesa/drivers/dri/common/utils.c).
Even though many drivers do not export this extension, glBlendFunc is
internally implemented by calling glBlendFuncSeparate. Without this
addition, glBlendFunc stopped working on drivers (such as mga) that do not
export GL_EXT_blend_func_separate.
There are still a few assertions / crashes in GL_ARB_vertex_program tests,
but I don't think that these are related to any of my changes.
|
|
_glapi_add_entrypoint has been replaced by a new routine called
_glapi_add_dispatch. This new routine dynamically assignes dispatch offsets
to functions added. This allows IHVs to add support for extension functions
that do not have assigned dispatch offsets.
It also means that a driver has no idea what offset will be assigned to a
function. The vast majority of the changes in this commit account for that.
An additional table, driDispatchRemapTable, is added. Functions not in the
Linux OpenGL ABI (i.e., anything not in GL 1.2 + ARB_multitexture) has a
fixed offset in this new table. The entry in this table specifies the
offset in of the function in the real dispatch table.
The internal interface was also bumped from version 20050725 to 20050727.
This has been tested with various programs in progs/demos on:
radeon (Radeon Mobility M6)
r128 (Rage 128 Pro)
mga (G400)
|
|
src/mesa/glapi. Basically, the scripts that did simple things (like
gl_offsets.py) were simple, and the scripts that did more complicated things
(like glX_proto_send.py) were getting progressively more and more out of
control. So, I re-write the foundation classes on which everything is based.
One problem with the existing code is that the division between the GL API
database representation and the way the output code is generated was either
blury or nonexistant. The new code somewhat follows the
Model-View-Controller pattern, minus the Controller. There is a distinct
set of classes that model the API data, and there is a distinct set of
classes that generate code from that data.
One big change is in the class that represents GL functions (was glFunction,
is now gl_function). There used to be an instance of this calls for each
function and for each alias to that function. For example, there was an
instance for PointParameterivSGIS, PointParameterivEXT, PointParameterivARB,
and PointParameteriv. In the new code, there is one instance. Each
instance has a list of entrypoint names for the function. In the next
revision, this will allow a couple useful things. The script will be able
to verify that the parameters, return type, and GLX protocol for a function
and all it's aliases match.
It will also allow aliases to be represented in the XML more compactly.
Instead of repeating all the information, an alias can be listed as:
<function name="PointParameterivARB" alias="PointParameterivEXT"/>
Because the data representation was changed, the order that the alias
functions are processed by the scripts also changed. This accounts for at
least 2,700 of the ~3,600 lines of diffs in the generated code.
Most of the remaining ~900 lines of diffs are the result of bugs *fixed* by
the new scripts. The old scripts also generated code with some bugs in it.
These bugs were discovered while the new code was being written.
These changes were discussed on the mesa3d-dev mailing list back at the end
of May:
http://marc.theaimsgroup.com/?t=111714569000004&r=1&w=2
Xorg bug: 3197, 3208
|
|
parse_GL_API, in gl_XML.py.
|
|
|
|
FilterGLAPISpecBase. Since the size_h mode of glX_proto_size.py will be
used to generate multiple header files, add an option to specify the define
that is used for multiple-inclusion protection.
The changes to the header files in this commit are just a side-effect of the
changes to the Python scripts.
|
|
sent to mesa3d-dev with a more detailed description.
|
