[Mesa-dev] [Bug 30172] GL_EXT_framebuffer_blit function required

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Sep 16 21:46:49 PDT 2010


https://bugs.freedesktop.org/show_bug.cgi?id=30172

--- Comment #20 from Luca Barbieri <luca.barbieri at gmail.com> 2010-09-16 21:46:49 PDT ---
FWIW, here is how to design an extension system which is actually usable.

Add a single function, which is the only function exported from libGL:
void* glGetFunctionTable(const char* vendor)

This function returns a pointer to the unsigned integer 0 if no extension from
<vendor> is supported.
Otherwise, it returns a pointer to the vendor-specific (or ARB if "ARB", or
core OpenGL if "GL") function table, and the unsigned integer it points to will
be greater than 0.

This function table is context-dependent unless <vendor> starts with "^" (this
would be used for GLX, for instance).
Also, the function pointers in the structure may change on any call to a GL
function.

Now each vendor simply publishes an header with a C struct.

The struct starts with an unsigned integer denoting the size, and contains
function pointers for all their extensions, plus booleans to tell whether the
extension is supported as a whole.

New extensions are added at the end, and the reported size is increased
accordingly.

Usage is as easy as possible, unlike the current GL method:

GLFunctionTableNV* nv = glGetFunctionTable("NV");

if((nv->size > offsetof(nv, NV_fence_supported)) && nv->NV_fence_supported)
{
  nv->GenFences(...)
}

A macro could further reduce the check to
if(GL_SUPPORTED(nv, NV_fence))

Also, performance is optimal, unlike the current GL method.

Ideally, functions should take a pointer to the GL context, so that it doesn't
need to fetched from a thread-local variable.

A variant could be to have glGetFunctionTable only provide the
context-independent tables, and having a GetContextFunctionTable function in
the "GL" context-independent table.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the mesa-dev mailing list