[EMAIL PROTECTED] wrote:
>
> Brett Johnson wrote:
> |
> | No doubt. Like I said, I could come up with a pathological dataset that
> | would show a small (5%-10%) performance hit. But that's a real corner
> | case on very fast hardware. I've never seen a dataset that came from
> | a real application show any measurable performance degradation.
>
> While I was at SGI, the mean triangle strip length observed in
> customer applications was 4 vertices. State changes between strips
> were common enough that they dominated overall rendering time for
> nearly all apps. If you're lucky enough to be targeting John
> Carmack's code instead of stuff like that, then life is much easier. :-)
Sure, but these are state changes (like a color change) that don't affect
the dispatch table. If you're changing modal state, where you're going to
need to modify the dispatch table, I'd still argue that the cost of the
actual state change will swamp the cost of manipulating the dispatch table.
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).
> | Yes it does, but the effect tends to be even smaller in cases where the
> | hardware is comparatively slower than the CPU. ...
>
> Given the advent of things like GeForce, I'd be betting on systems in
> which the graphics is fast relative to the CPU. I'd also guess that
> people believe CPU overhead is an issue, or we'd all be content with
> the fine-grained vertex commands rather than vertex arrays.
No argument here. I'm not saying that CPU overhead isn't an issue. I'm
just arguing that the overhead of using dynamic vs static dispatch tables
is insignificant in comparison to the cost of the state change itself.
> | The possible performance gain is too small, and the added complexity and
> | possible performance hit in the calling case is too large. ...
>
> I believe the scheme I proposed allows an implementation with no
> performance hit in the calling case and has complexity equal to or
> less than dynamic slot assignment (because it minimizes changes to
> existing drivers). Since it allows performance gains in state changes
> for systems in which that's an issue, overall it seems like a better
> tradeoff to me.
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. I.e. if the tables were dynamic,
the address could be hard coded into the dispatch code, but in the case you've
presented, the offset must be loaded from memory and added to the table base.
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. I can see all kinds of problems with this from a management
and maintenance perspective, and it requires some third party arbitrator to
resolve it. I realize that this already occurs with GLX protocol, and it's
already a pain in the butt. The difference is that I can't see any way around
it with GLX protocol. But here, there's a clear, simple way around it (that
also solves a bunch of other problems).
> | Maybe this mailing list isn't the place to have this discussion? This is
> | an area that I'm keenly interested in, but I don't think we're adding
> | anything to the context (in)dependence discussion.
>
> Good question. If everyone is convinced that context-independent
> pointers can be supported with acceptable cost (for driver development
> and for execution at runtime), then we're done; we can take the
> details offline. If there's a sizeable group of people who are not
> convinced, then we need to keep going a while longer.
>
> Any votes?
I'm convinced that context-independent is the way to go. My vote is to
close the issue and go on.
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
