On Wed, Aug 31, 2005 at 08:11:12PM -0700, Ian Romanick wrote:
| Allen Akin wrote:
| > Jon's right about this: If you can accelerate a given simple function
| > (blending, say) for a 2D driver, you can accelerate that same function
| > in a Mesa driver for a comparable amount of effort, and deliver a
| > similar benefit to apps. (More apps, in fact, since it helps
| > OpenGL-based apps as well as Cairo-based apps.)
|
| The difference is that there is a much larger number of state
| combinations possible in OpenGL than in something stripped down for
| "just 2D". That can make it more difficult to know where to spend the
| time tuning. ...
I'd try solving the problem by copying what Render+EXA does, because we
already have some evidence that's sufficient. We know what situations
Render+EXA accelerates, so in Mesa we accelerate just the OpenGL state
vectors that correspond to those situations. The state analysis code
could be written once and shared. You know more about that part of Mesa
than I do; do you think writing and documenting the analysis code would
be significantly more time-consuming than what's already gone into
defining and documenting the corresponding components for EXA? The rest
is device setup, and likely to be roughly equivalent for the two
interfaces.
| The real route forward is to dig deeper into run-time code generation.
In theory, I agree (and I think it would be a really fun project). In
practice, I've always turned away from it when tempted, because the
progress of the hardware folks is so overwhelming. Have you seen what's
possible on cell phones that have been shipping since the beginning of
2005? Amazing. On low-cost power-constrained devices, a market where
it was sometimes claimed that acceleration wouldn't be practical.
| BTW, Alan, when are you going to start writing code again? >:)
Yeah, certain other IBM people have been on my case, too. They're
largely to blame for the fact that I'm in this discussion at all. :-)
Allen