On Jun 7, 2011, at 7:19 AM, Chia-I Wu wrote:
> In indirect rendering, glGenTextures and glGenTexturesEXT, for
> example, use different opcodes. However, those functions are assigned
> the same dispatch offset in glapi. If glapi defines both of them,
> they will be dispatched to the same function, using the same opcode.
>
> As a workaround, when GLX_INDIRECT_RENDERING is defined, glapi no
> longer defines glGenTexturesEXT. Those link to libglapi.a are
> supposed to define the function. Since libglapi.a still references
> glGenTexturesEXT (in _glapi_get_proc_address), not defining the
> function will result in link errors. Same to other functions.
It's not having any issue with GenTexturesEXT. It is finding glGenTexturesEXT
in libGL.dylib. The ones it is stumbling over are the unexported
gl_dispatch_stub_* symbols (taken from indirect.c):
"GetConvolutionFilterEXT", (_glapi_proc) gl_dispatch_stub_356}, {
"GetConvolutionParameterfvEXT", (_glapi_proc) gl_dispatch_stub_357}, {
"GetConvolutionParameterivEXT", (_glapi_proc) gl_dispatch_stub_358}, {
"GetHistogramEXT", (_glapi_proc) gl_dispatch_stub_361}, {
"GetHistogramParameterfvEXT", (_glapi_proc) gl_dispatch_stub_362}, {
"GetHistogramParameterivEXT", (_glapi_proc) gl_dispatch_stub_363}, {
"GetMinmaxEXT", (_glapi_proc) gl_dispatch_stub_364}, {
"GetMinmaxParameterfvEXT", (_glapi_proc) gl_dispatch_stub_365}, {
"GetMinmaxParameterivEXT", (_glapi_proc) gl_dispatch_stub_366}, {
"GetSeparableFilterEXT", (_glapi_proc) gl_dispatch_stub_359}, {
GenTextures works fine with this in glprocs.h:
NAME_FUNC_OFFSET( 4134, glGenTextures, glGenTextures, NULL, 328),
NAME_FUNC_OFFSET(17150, glGenTextures, glGenTexturesEXT, glGenTexturesEXT,
328),
The ones above fail with this in glprocs.h:
NAME_FUNC_OFFSET( 4811, glGetHistogram, glGetHistogram, NULL, 361),
NAME_FUNC_OFFSET(17978, glGetHistogram, gl_dispatch_stub_361,
gl_dispatch_stub_361, 361),
The resulting GLX_INDIRECT_RENDERING libglapi.a defines glGenTextures but
references an external glGenTexturesEXT.
000000000000ec70 T _glGenTextures
000000000009ad98 S _glGenTextures.eh
U _glGenTextures
U _glGenTexturesEXT
Whereas for getHistogram, It defines glGetHistogram but references an external
gl_dispatch_stub_361
000000000000dafb T _glGetHistogram
000000000009a190 S _glGetHistogram.eh
U _glGetHistogram
U _gl_dispatch_stub_361
When built without GLX_INDIRECT_RENDERING, both gl_dispatch_stub_361 and
glGenTexturesEXT are provided by libglapi.a, and libOSMesa uses these. When I
build indirect-only, libOSMesa resolves GetHistogramEXT from libGL and fails to
resolve gl_dispatch_stub_361. It is present in libGL, but it is not exported
(my guess is that this builds on other platforms due to looser linking rules):
0000000000013711 t _gl_dispatch_stub_361
It looks like the difference in behavior between GenTextures and GetHistogram
stems from the static_dispatch attribute in gl_API.xml:
<function name="GenTextures" offset="328">
<function name="GenTexturesEXT" alias="GenTextures">
<function name="GetHistogram" offset="361">
<function name="GetHistogramEXT" alias="GetHistogram"
static_dispatch="false">
So what is the proper fix here? How should libOSMesa be getting built?
Should libmesa.a be providing those stubs (rather than my change which put them
in mesa/osmesa)? Should the stubs be getting exported by libGL? Should
GetHistogramEXT be exported by libGL?
Based on my understanding, it seems like we should bring these stubs into
libmesa.a (and remove them from mesa/xlib). Does that sound right?
--Jeremy
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
