[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