On 2014-01-08 03:38, Mike Parker wrote:
On 1/8/2014 5:35 AM, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dl...@gmail.com>" wrote:
On Tuesday, 7 January 2014 at 20:06:47 UTC, Adam Wilson wrote:
counts for quite a bit. His biggest point however is that the
high-level API should be completely independent of the low-level API's.
That's not possible. The GPU pipeline defines a design space. For 2D
graphics it consists of texture atlases, shaders and how to obtain
"context coherency" and reduce the costs of overdraw. If you stay in
that design space and do it well, you get great speed and can afford to
have less efficient higher-level structures creating a framework that is
easier to use. The more low level headroom you have, the more high level
freedom you get.
It is very much possible. There are a number of high-level graphics APIs
out there designed in just such a way, many of which predate shader
APIs. Java2D is a prominent one. For the sort of package we're
discussing here, you should never define the high-level API in terms of
low-level API features. Shaders shouldn't even enter into the equation.
That's the sort of backend implementation detail that users of the API
shouldn't have to worry about.
What you're talking about is fine when you have the luxury of supporting
a limited number of platforms, or are working in a specific application
space (games, for instance). In those cases, performance is going to
trump generality and you can model your API more closely to the
hardware. But for a general-purpose graphics API that needs to be
available on as many devices as possible, that's not going to work. And
anything that's going to be considered for inclusion into Phobos
probably should favor generality over performance.
I would say that we should try and built the API in many different
levels and layers. The top layer would be for ease of use to quickly get
something to show on the display. If more performance is needed it
should be possible to access the lower levels of the API to get more
control of what you need to do.
Ideally, the default
backend should be software, so that the API can be used even when
graphics hardware is not available (though I'm not saying that's a
realistic target to start out with).
Ideally the default backend should detect if graphics hardware is
available or not at runtime and choose the best backend for that.
I realize that we're in an age where GPU programming is becoming more
common and even cell phones have good hardware acceleration, but another
consideration is the target audience. If you want an API that a
non-graphics programmer can more easily get up to speed with, then
that's another reason that you can't let the low-level influence the
design. The closer you get to the details, the more difficult it is to
learn.
It's quite possible to put together a reasonably performant,
easy-to-use, general purpose graphics API that can take advantage of the
best renderer on a given platform without letting the low-level details
leak into the high-level design.
--
/Jacob Carlborg
