I have a patch that gets most of the way there, but it still has some quirks
that I'd like to figure out and address.
The generated code doesn't check for FramebufferTextureLayerARB as an alias for
FramebufferTextureLayerEXT. Could someone please explain what is going on
there and why FramebufferTextureLayerARB isn't listed in the entry_points, but
FramebufferTextureLayerEXT and FramebufferTextureLayer are? I'm basically just
iterating like this:
def printBody(self, api):
for f in api.functionIterateByOffset():
for entry_point in f.entry_points:
vars = { 'entry_point' : entry_point,
'name' : f.name }
print body_template % vars
return
Also, should I leave the entry NULL when there is no implementation, or should
I set it to a noop implementation that will catch the problem and log/abort?
I included the generated code in the commit since that is what seems consistent
with the rest of glapi, even though other generated code (eg:
src/mesa/main/main/api_exec_*.c) isn't checked in to git. Please let me know
if I should keep the generated code out of git.
Thanks,
Jeremy
The patch was rejected by the list due to size, so see it here:
http://cgit.freedesktop.org/~jeremyhu/mesa/commit/?id=45aed4cea5b938cce9bfd8e93d16255b2b7a466a
On Jun 8, 2011, at 12:35 PM, Jeremy Huddleston wrote:
> In moving src/glx/apple over to glapi this past week, I used our dispatch
> table code from xserver/hw/xquartz/GL/indirect.c as the model for creating
> our _glapi_table. Our table should contain pointers into OSX's OpenGL
> implementation, so the call is just passed along to that implementation.
> Currently, the table is created by calling SET_* for every possibly entry and
> uses dlsym() with an appropriate handle to get the function pointer:
>
> SET_Accum(__ogl_framework_api, dlsym(handle, "glAccum"));
> SET_AlphaFunc(__ogl_framework_api, dlsym(handle, "glAlphaFunc"));
> ...
>
> This works well enough, but it is not very robust, especially in cases where
> there are multiple aliases for a particular function. If OpenGL.framework
> provides an implementation as one of the other aliases, we don't end up
> picking it up. I've special cased some, but this is just something that
> should be easily generated rather than hand edited.
>
> It would be nice to have an api in glapi to handle this. Someone familiar
> with the specs parsing / code generation bits should be able to do it fairly
> easily. I'm envisioning something like this:
>
> struct _glapi_table *
> _glapi_create_table_from_handle(void *handle, const char *symbol_prefix);
>
> Which I would call like:
> void *handle = dlopen(opengl_framework_path, RTLD_LOCAL);
> __ogl_framework_api = _glapi_create_table_from_handle(handle, "gl");
>
> The implementation would be something like:
>
> struct _glapi_table *
> _glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
> struct _glapi_table *disp = calloc(1, sizeof(struct _glapi_table));
> char symboln[512];
>
> if(!disp)
> return NULL;
>
> // Simple cases
> snprintf(symboln, sizeof(symboln), "%sAccum", symbol_prefix);
> SET_Accum(disp, dlsym(handle, symboln));
>
> snprintf(symboln, sizeof(symboln), "%sAlphaFunc", symbol_prefix);
> SET_AlphaFunc(disp, dlsym(handle, symboln));
>
> ...
>
> // More complex aliasing example
> snprintf(symboln, sizeof(symboln), "%sFramebufferTextureLayerEXT",
> symbol_prefix);
> SET_FramebufferTextureLayerEXT(disp, dlsym(handle, symboln));
> if(!disp->FramebufferTextureLayerEXT) {
> snprintf(symboln, sizeof(symboln), "%sFramebufferTextureLayerARB",
> symbol_prefix);
> SET_FramebufferTextureLayerEXT(disp, dlsym(handle, symboln));
> }
> if(!disp->FramebufferTextureLayerEXT) {
> snprintf(symboln, sizeof(symboln), "%sFramebufferTextureLayer",
> symbol_prefix);
> SET_FramebufferTextureLayerEXT(disp, dlsym(handle, symboln));
> }
>
> ...
>
> return disp;
> }
>
> This seems like something that would be useful outside of just the darwin
> case. Hopefully someone with more experience in the specs code generation
> code would be able to do this (or at least point me in the right direction if
> nobody is willing to tackle it themselves ... I'm guessing gen/gl_table.py is
> a good place to start ...).
>
> And before I go down this road, is this the right approach for implementing
> this API, or is there another way that you'd recommend?
>
> Thanks,
> Jeremy
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
