[this message of Allen's hadn't gone through]
Keith Whitwell wrote:
|
| [lots of good analysis omitted for brevity]
|
| I think that what functions you implement will depend on the hardware to
| such an extent that you are unlikely to be able to come up with a
| 'definitive' answer to your search. ...
I agree. Layering is the wrong strategy here; we should be thinking
of ways to construct code paths from the API directly to the hardware.
That's the way high-performance OpenGL-based systems operate today.
| ... This will essentially be the same
| trap as the glVertex() interface - eventually vertices were so cheap
| that that the call itself became a major step in the processing.
That's less clear to me. The cost of a glVertex() call that directly
transfers data to the graphics system can be less than the cost of
buffering the vertex data and then transferring it in some other way.
This is very much an issue for applications which need to maintain
data structures that are optimized for time-consuming operations other
than drawing (e.g. detecting collisions, sorting for blended
transparency, etc.).
Plus, any time you buffer, you introduce latency and increase the
worst case queue depth for flow control. And finally, transferring
data in fine-grained fashion gives you the opportunity to avoid data
transfers altogether (e.g., of colors or normals or tex coords, ...)
when they're the same for successive vertices; arrays of fixed-format
vertex structures don't offer this advantage.
Allen
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
