[BBQ-SThorm] Discussion points for tomorrow telco

[Patrick Bellasi]

Hi Germain!

We started looking into the reconfiguration of the number of clusters in use by the OpenCL run-time, starting from the AIDL interface you provided us.

This is a pretty long email, please don't blame me, thereafter I'm anticipating just a set of considerations and discussion points to be better investigated during the telco scheduled for tomorrow.

.:: OpenCL run-time reconfiguration

According to the AIDL you provided it seem that just a single call will be supported for the time being, i.e.

   int configure(int clusterMask)

As previously discussed, this call will be available through a Binder wrapping shared library, to be linked by the BBQ SThorm PIL.

So far so good, regarding this point these are the main question from our side:

1. could you shortly describe the functional behavior of this call?

AFAIK, this call is handled by the OpenCL daemon running on the host side, right?

Is this daemon in charge to reconfigure the device-side OCL run-time as well?

Is there an interface to monitor from the host-side how many cluster have been actually allocated to the OCL run-time?

2. what are the return type expected by the configure call?

The AIDL interface defines an enum with CONFIGURE and DECONNETC... but I cannot see if these values are related to the configure call and, eventually, how they relate?

.:: OpenCL and Apps reconfiguration

Regarding the interaction between the reconfiguration of OCL applications and the OCL run-time, these are a couple of points to be discussed:

3. considering the need to reconfigure both an application constraint and the OCL run-time, e.g. 

A1 switching from 100% to 25% fabric_quota, while OCL run-time shrinking to run just on clusterMap 0x01, is the relative order of these two reconfiguration sensible?

In that case, we should reconfigure before the OCL runtime (i.e. configure(0x01)) and only after the application constraint, or the contrary?

4. related to point 3, what about if we have multiple applications reconfigured while OCL shrinking, e.g.

A1 and A2 switching from 50% to 25% fabric_quota each one, while OCL run-time shrinking to run just on clusterMap(0x3), what is the correct relative order of the reconfiguration in that case:

a) first update OCL run-time and then update apps constraints

or

b) first update apps constraints and than update OCL run-time

.:: OpenCL run-time notification

Considering the interaction between BBQ and the SThorm run-time:

5. when constraints of an application are updated, right now, the BBQ SThorm PIL notify the   device run-time. Thus, if more then one application is re-configured, the device run-time gets multiple notifications. Each notification specify the ID of the constraints set being updated.

We already discussed that point in past, however probably now we have a more stable code-base and an increasing number of integrated applications to eventually review some design decision. Thus, the question is: do you think it could be more convenient to have a single notification when multiple constraints set are updated at the same time?

In that case, have you an API signature proposal for this new notification?

.:: OpenCL demo applications

A final not on demo applications availability:

6. regarding SThorm applications, I've noticed that in the last SDK you released internally, many apps have been removed. Especially, FaceDetect is not more there.

I've tried to forward-port the version we have successfully integrated with BBQ... but actually many dependencies are still missing in the current SDK.

Do you have any plan to release quite soon a new SDK with these apps still available?

By the way, I've noticed that you accepted and merged all the BOSP related patched into the SThorm SDK... a really good and appreciated surprise! ;-)

Ok, talk to you tomorrow!

Ciao Patrick

--
#include <best/regards.h>

Patrick Bellasi
Post-Doc at Politecnico di Milano
http://home.dei.polimi.it/bellasi

[Germain HAUGOU]

Hi Patrick,

 

A lot of questions, le’ts keep them for the telco ! By the way, tomorrow is for UC4a (SVC on NPM), we should discuss this on Friday.

Your questions are mainly about increasing or decreasing the number of clusters managed by the OpenCL runtime, meaning that the other ones are for NPM or another runtime. However during our last telco, we said that we don’t want to mix SVC and Multiview for the usecase, thus all the clusters should be allocated to OpenCL in UC5. I think we should stick to this simple usecase as we already have a lot of things to do for the review ! Do you see a scenario where we need that ?

 

Bye,

Germain

[Patrick Bellasi]

On Wed, Mar 6, 2013 at 4:54 PM, Germain HAUGOU <germain...@st.com> wrote:

Hi Patrick,

Hi!

 

A lot of questions, le’ts keep them for the telco ! By the way, tomorrow is for UC4a (SVC on NPM), we should discuss this on Friday.

Ok, let discuss them on Friday.

 

Your questions are mainly about increasing or decreasing the number of clusters managed by the OpenCL runtime, meaning that the other ones are for NPM or another runtime. However during our last telco, we said that we don’t want to mix SVC and Multiview for the usecase, thus all the clusters should be allocated to OpenCL in UC5. I think we should stick to this simple usecase as we already have a lot of things to do for the review ! Do you see a scenario where we need that ?

Yes, you are right. For 2PARMA UCs we will not consider a mixed-workload. However, even if we run a single application, it could be interesting to show the capability to shrink the cluster used by the OpenCL run-time especially if the remaining ones could be put in a low-power mode.

This allows for instance to demonstrate the benefits of a BBQ power-optimization policy, where we trade performances for energy efficiency.

Anyway, lets keep the details for the telco.

 

 Bye,

Germain

Ciao Patrick