On 29/04/15 16:41, Ola Liljedahl wrote:
On 29 April 2015 at 16:10, Bill Fischofer <bill.fischo...@linaro.org
<mailto:bill.fischo...@linaro.org>> wrote:
We need to be careful about trying to solve problems that haven't
arisen yet. There are several interrelated issues here:
1. Parsing (and classification) in SW takes cycles. This should
only be done once, not duplicated between the app and the ODP
implementation, and ideally should only be done to the degree that
the results are actually needed by the application.
2. The ultimate goal is for applications to make use of ODP's
parsing/classification capabilities since these will be
HW-accelerated on many platforms today, and on all platforms in the
future.
Therefore, any proposed changes to the API need to keep these two
goals in mind. The goal is to help transition apps away from doing
parsing/classification themselves, not to give increasingly complex
(and increasingly irrelevant in a HW-accelerated world) advice to
the implementation as to what they need.
This is one of the reasons why none/all is a good starting point,
since it solves our immediate need for legacy apps running on SW
implementations. Those platforms that have zero-cost HW parsing can
safely ignore a 'none' spec with no ill effect, while SW platforms
will eliminate unwanted overhead. Beyond that, I believe simplest
and most future-proof means of addressing the above goals is to
explore lazy evaluation approaches to SW parsing in ODP. This
involves no new APIs that would have only transitory utility and is
transparent to the application.
So we have a proposed solution which does not require any changes to the
API.
What solution do you mean? I don't see any which lets the application
disabling parsing AND doesn't require API change.
Why don't we try out this solution and see where it gets us?
Changing the API (and making it more complicated, both to implement and
to use) without having verified that this is the only solution is not a
smart move. Keeping the architecture simple is an important goal (it
will grow anyway but the role of an architect is to resist changes and
propose alternative solutions using the existing mechanisms and API's).
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
