[Mesa-dev] RFC: Standardize names of OpenGL functions in Mesa.
Paul Berry
stereotype441 at gmail.com
Wed Nov 7 12:05:56 PST 2012
In situations where an OpenGL function has several equivalent names, Mesa
currently does not follow a consistent standard for which name is used.
For example, the function glDisablei() (introduced in GL 3.0) is equivalent
to glDisableIndexedEXT() (introduced in EXT_draw_buffers2). Mesa manages
the dispatch table using functions names {SET,GET,CALL}_DisableIndexedEXT,
but it implements the call in a function called _mesa_DisableIndexed().
This is only one of literally hundreds of inconsistencies. In some cases,
the implementation matches the GET/SET/CALL functions, in some cases it
doesn't. In some cases, the name used in Mesa matches the name defined in
a GL spec; in others it matches the name defined in an extension. Finally,
some Mesa implementation functions begin with the prefix "loopback_",
"_es_", or "_check_" instead of the more usual "_mesa_".
These inconsistencies can lead to a lot of frustration when grepping
through source code, or setting breakpoints in the debugger, because a fair
amount of sleuthing is sometimes necessary to figure out which function
name to use. Also, it led me to have to do extra work when preparing my
patch series "dispatch: code generate _mesa_create_exec_table". While
reviewing that patch series, several folks asked if we could simply rename
the mesa functions and adjust the XML to make everything consistent.
With a bit of script-fu, I've made a patch that does all the renaming. I'm
interested in getting some code review, as well as some impressions of
whether this change sounds like a good idea.
Because so many functions got renamed, the patch is way too big to send to
the mailing list, so I've located it at git://
github.com/stereotype441/mesa.git, in the branch
"standardize-function-names". There are three small patches on top of it,
to fix minor compiler warnings introduced by the change, and to get rid of
the code generation logic that used to be necessary to account for the name
anomalies.
Thanks in advance for your consideration :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20121107/2a07ef92/attachment.html>
More information about the mesa-dev
mailing list