[Mesa-dev] [PATCH] glapi: Add API that can create a _glapi_table from a dlfcn handle

[Jeremy Huddleston]

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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>