Brett Johnson wrote:
|
| Sure, but these are state changes (like a color change) that don't affect
| the dispatch table. ...
I had in mind state changes involving the depth test, blending
function, polygon offset, stencilling, and texturing. But I grant
that those will affect the dispatch table on some machines but not
others, so the performance impact will vary.
| Existing Windows ICDs are a reasonable proof of this. The cost of updating
| the ICD dispatch table is horrendous, and involves calling MS code which
| replaces the entire table! Yet most drivers don't have a problem with it
| (or at least they have reasonable workarounds to it).
Hmm. I'd like to benchmark that. Now that Johan Smet has glean
running under Windows, it's time to add some new tests. :-)
| Maybe I don't understand what you've proposed. It looks to me like your
| proposal trades having a dynamic offset to call the routine for having a
| static offset to modify the dispatch table.
Sorry; that's my fault for not being more clear this time around. The
reason for having registered dispatch-table offsets for all commands
is so that any command (core or extension) known at the time libGL is
compiled can be dispatched using a static offset. The code for
dynamic offsets that I mentioned a couple of messages ago is used only
for new extensions that were unknown at the time libGL was compiled.
| One other thing I'm concerned with is the requirement that all drivers must
| use an identical monolithic struct (defined by whom? The ARB?) to store all
| their entrypoints.
Just like new enumerants. I'd be inclined to request dispatch-table
offsets at the same time I request a subrange for new enumerants for
my extensions. Currently SGI handles the bookkeeping for this.
| I'm convinced that context-independent is the way to go. My vote is to
| close the issue and go on.
Sounds good to me, too. We'll have to follow up with implementation
concerns in a different forum.
Allen
