Here's my first post to this group... be gentle...
----- Original Message -----
From: Jon Leech <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 09, 1999 3:20 PM
Subject: [oglbase-discuss] Re: draft spec for GL_EXT_get_proc_address
>
> Another alternative is for glGetProcAddress to dynamically extend
> the libGL dispatch tables, dynamically synthesize entry points which
> dispatch through those tables, and return a pointer to the resulting
> hunk of code (Brett suggested this a few posts ago). This seems
> hideously complex, and I don't know if it's even necessarily possible on
> all architectures supporting Linux (does everyone have writeable code
> space these days?). Of course the GLX dispatch table needs to be
> extended on the server side as well, but that's a tractable task -
> unrecognized GLX opcodes could be handed off to some standard entry
> point in each driver.
>
I think this is the cleanest suggestion from the application developers
standpoint. While peformance is a laudable goal, it is not the only one.
Features which are difficult to use are not broadly adopted within
applications. Inhibiting or discouraging applications from using the best
that OpenGL provides hurts the standard overall. C.f. the experience SGI
and others have had getting large applications (Maya, et. al.) to using the
lastest-and-coolest-and-not-on-all-platforms-acceptably features of OpenGL.
Adding more barriers to entry allows the few and brave (or those whose
applications are limited in scope e.g. games) to use the features but few
others.
Below I've sketched one simple potential solution to avoid having to write
to the code space. The idea would be to created a series of stub functions
(up GL_EXT_DYNAMIC_ENTRY_MAX_OR_WHATEVER) which are context aware (see
pseudo code below). It's ugly, but as the number of outstanding unsupported
procs is likely to be small (<1000) and the dynamic_proc_NNNN could be
demand loaded (zero overhead for non-users), and each dynamic_proc small...
it may be an acceptable hack. Below are two different sketches of the same
general idea. For extensions NOT in the common dispatch table the getProc
would assign a <proc_id> and a return dynamic_proc_<proc_id> as the proc.
The proc_id's would map to the EXT names, and be hashed with keys proc_id
and current context (or visual or dll id or ???) with the data being the
appropriate proc for the context. The code below show the rough level of
complexity for reversing that bit of hash back out in an invocation of the
stub. The stubs are easily generated by means of scripts or cpp.
// Version 1: Minimizing per EXT footprint -- small stubb with common
dispatch logic
proc dynamic_proc_<proc_id>(...)
do_dynamic_dispatch(<proc_id>,current_context,...)
end
proc do_dynamic_dispatch(proc_id,context,...)
if (dynproc[proc_id].context != context ) // context or visual or
driver ID or ....
dynproc[proc_id].proc =
do_dynproc_lookup(dynproc_hash,proc_id,context)
dynproc[proc_id].context = context
invoke dynproc[proc_id].proc(...)
end
// Version 2: Minizimizing proc call and layering overhead
// (and reduce the number of hash keys to 1)
proc dynamic_proc_0001(...)
static context_ptr_type static_last_context =NULL
static proc_ptr_type static_proc_for_current_context =
ptr_to_error_trap
if (current_context != static_last_context )
// hash for proc v. context (or visual or whatever)
static_proc_for_current_context = ...
invoke static_proc_for_current_context(...)
end
Now this does add additional indirection for these dynamic procs... but do
they tend to be inmost loop functions (such as glVertex3f is) typically? I
think this internal complexity is far better than permanently burdening the
applications with complexities which subsequent releases of the OpenGL
(probably) will remove when such EXT's could become part of a common
dispatch table.
John M. Zulauf
Santa Barbara, CA
