Sub problema de benders

The next case study is an MPEG-4 [121] decoder. This program consists of three networks namely motion estimation, texture coding, and the parser. The parser is rather dynamic as it reacts to the contents of the input stream, the other two blocks, however, perform certain operations on macro blocks or 8x8 pixel blocks, and it can be expected that some static schedules should be possible to derive for these networks. The dataflow design of the program can be seen in Figure 7.10; in general, the control information is distributed on the channels named BTYPE while the other channels are data queues.

Parser BITS MV BTYPE QP B Texture BTYPE QFS QP F Motion MV BTYPE TEX VID IN VID

Figure 7.10: The MPEG-4 decoder.

Before going into the actual case study, it may be useful to describe the general operations of the blocks to be scheduled. Both the Texture and the

Motion networks receives an 8x8 block together with the information regard-

ing how to decode it on the BTYPE input. The texture network decodes the actual pixel data and adds the potential prediction from surrounding blocks while the motion compensation potentially adds prediction from previous pictures according to the motion vectors (MV). The information regarding which predictions should be performed on the current block and whether or not the block has actual DCT coded coefficients that are to be inverse transformed by the texture network, is encoded in the values transmitted on the BTYPE channel.

What we should be expecting from this program is that, for each of these networks, a schedule should correspond to some value on the BTYPE channel, together with some data input on the other input ports. The two

networks, on the other hand, are not expected to be practical to be scheduled as one unit as the type of operation performed by these are different and are not dependent. That is, the fields that are checked in the BTYPE token are different for the two networks; this also becomes evident when the compatibility of the guards is analyzed.

Texture Coding The first network to be scheduled is the Texture coding

network, which consists of five actors. These actors, does, according to the MPEG-4 standard, perform DC coefficient prediction, re-ordering of coefficients, AC prediction, inverse quantization, and inverse DCT. What can be assumed about this sub-network, as everything relates to decoding texture data, is that the operations performed by the actors depending on the type of block entering the sub-network, to some extent correlate. The actors can therefore be assumed to share the properties of the blocks that enter, however, this qualified guess needs to be verified more formally.

The variable dependency graph in Figure 7.11 shows that the partition has two actors which depends on the input to the partition, while one of these actors also generate control values for two other actors in the parti- tion. To successfully schedule the partition, a set of guards that completely describes the behavior for any possible input needs to be found. The guards of the two front actors which reads the control values entering the parti- tion checks properties of the BTYPE control token regarding whether the incoming block is an INTRA block, a motion block with or without resid- ual coefficients, or perhaps the marker of a new frame. Of the two actors reading the incoming control token, one of the actors has these four alter- natives while the other one has only three of these, with one of the guards corresponding to two of the guards in the first actor. The actor called DC Reconstruction invpred, is therefore considered to cover the scheduling decision of these two actors. In a similar fashion, the same actor is resolved to cover the two actors to which it generates the control values. In this

particular actor, the control values are generated from a set of constants, however, in one of the actions, one of several constants are used depending on an if-statement. This results in that each of these constants must be checked to be accepted by the same actor in order for the guard of that specific action to be strong enough.

Using the actor DC Reconstruction invpred as the starting point of the scheduling, and using the initial schedules generated according to Chapter 4, a set of four schedule to be searched for is identified as shown in the following listing.

0 r e a d _ r e a d _ o t h e r r e a d r e a d s0 s0 1 r e a d _ r e a d _ i n t e r _ a c r e a d r e a d s0 s0 2 r e a d _ s t a r t r e a d r e a d s0 s0

3 r e a d _ r e a d _ i n t r a r e a d r e a d s0 s0

An initial state named s0 is identified, and each of the schedules can be generated such that it reaches this state. This means that the resulting schedule only needs to have four schedules, and is therefore an FSM with one state and four transitions. Each of these transitions corresponds to evaluating one guard expression and firing a number of actions; for the one named other 6 actions, for inter ac 330 actions, for intra 331 actions, and for start 7 actions. These numbers does not tell anything about the speedup of the program, but shows how much unnecessary scheduling decisions can be removed if this partitioning is chosen.

Motion Compensation The motion compensation sub network has a

similar structure, and is controlled by the same control signal, namely BTYPE. While this is the same control value as used in the texture net- work, the properties of the control value checked is somewhat different in this network, as we now are interested in properties related to inter predic- tion while we before were interested in properties related to intra prediction.

For this reason, these networks are chosen to be scheduled separately, al- though it would not be impossible to schedule them together either, only the scheduler would become more complex.

More complex guards than what is available in any single actor will already be needed to schedule this partition. The reason for this is that the two actors sharing the input control token does not have compatible guards. In Figure 7.12, one can see that the incoming control token is used by the actors address and add. While both of these actors have four guards checking this token, both of them have two separate guards that may be enabled simultaneously with two guards of the other actor. Consequently, in order to find strong enough guards for the partition, a set of new guards, corresponding to the different possible combinations of guards of these two actors, must be generated.

Considering two sets of guards Gadd and Gaddress, the needed guards

corresponds to the Cartesian product of these sets, that is, Gpartition= Gadd× Gaddress

where the contents of these sets are

Gadd ={nvop, texture, motion, both}

and

Gaddress={nvop, no motion, motion, neither}

The guards needed to schedule the partition is then defined as all these combinations except the ones that cannot be accepted simultaneously.

Gscheduler= Gpartition\ Gimpossible

Where the impossible combinations are those, for example, requiring a block to be both intra and inter block simultaneously.

Gscheduler ={(nvop, nvop), (texture, no motion), (motion, motion), (motion, neither), (both, motion), (both, neither)}

The obvious problem is that no tool could ever know which of these combinations are impossible, unless the programmer adds this information. The set of guards of an actor describes the conditions that are sufficient to fire actions, but this information is based on assumption the programmer has made and is not visible in the guards. Some hints may be possible to derive from how a control token is generated but this is not always possible either. For this reason, the only way to succeed with the scheduling of this partition, such that the scheduler does not include impossible schedules, is

to add this information manually. This can be done by adding an actor, with guards corresponding to these composed guards, but does not perform any calculations; this actor can then be used to generate the scheduler of the partition.

Once the guards are in place, an initial scheduler can be generated, and the actual scheduling can take place. The six guard expressions in Gscheduler, are used to generate a simple initial scheduler with one state and six transitions, corresponding to the guards. The network is then scheduled with the following objectives: 1) consume all tokens on control inputs, and 2) all buffers inside the partition must be empty in the end state. Each of the schedules are found by the model checker, and the end states correspond to the initial state, resulting in a simple scheduler FSM with one state and seven transitions. The produced schedules fires sequences of actions: nvop 6 actions, texture 133 actions, and each of the other schedules working on inter blocks about 380 action each.