[Cbe-oss-dev] MARS on Cell blades ? Cell image / video codecs?

[Yuji Mano]

Werner Armingeon wrote:
> - Is seems true that linking libraries based on different frame works
> ( i. e. libspe & MARS ) is difficult or even impossible?

MARS is written on top of libspe. There's no reason why it would be
difficult or impossible. But as I previously mentioned if you have a
MARS context using N spe_contexts and another library/app using some
more spe_contexts you still end up with spe_context switches which MARS
tries to avoid.

> - Libraries based on MARS can be linked together and can run in
> parallel without too much overhead?

That's one of the goals. It has yet to be really put to the test at
this point.

> - Is it really easy to use different libraries based on MARS as I
> would like it or are there some hidden show stoppers?

Your question is a bit subjective. How easy would you like it to be?
See below.

> Possibly the initialization of MARS must be split off from both libs
> and you have to obey additional rules?

The current solution is to specify a 'shared' context when creating
the MARS context from the libraries that want to use MARS. So if an
app links libA, libB, libmars, libA and libB should be using the same
shared MARS context.

> - Do you have some experience in MARSifying algorithms based on other
>  SPU interface standards?

Well to write a MARS application I would obviously need to MARSify 
something. 'MARSify' can mean something as simple as moving your
libspe2 'Hello World' app into a MARS task.

Other than that to MARSify something really just involves how you want
to break up your workloads and how you want to synchronize the
processing. There's really nothing different from writing your typical
spu code, other than the fact that MARS provides synchronization objects
that call into the MARS scheduler.

But if you mean more like taking something written for IBM's ALF or
some other framework out there and porting them to MARS I would have to
say no. (with the exception of SPURS available only to licensed
developers in the game os side) 

> My feeling is that without such a compatible Cell programming
> standard which guarantees interoperability you cannot serious develop
> libraries for general use. For sure you would prefer MARS ;-), and
> what I learned from the presentation and documentation this would be
> a reasonable choice. Are there even any others?

As Arnd states, you could argue that libspe2/spufs IS the underlying
standard. MARS only tries to add another layer on top of it to reduce
context switch overhead of libspe2 spe_contexts.

If you are asking about other Cell programming frameworks/APIs to name
some I've heard of are ALF(IBM), CTK(FixStars), spexms(unsolo).

> A final question: Even if you have only one simple algorithm in your
>  application to be Cell optimized would MARS make the development
> easier and more efficient compared to libspe?

Try it and let me know the answer to that :).

In my biased opinion I think the MARS API is pretty simple to use, and 
since you're almost always going to need to do some DMAing of data back
and forth and handle synchronization, I'd say something like the 
'MARS task queue' might be very useful.

Regarding efficiency, I'll repeat what I've said before. MARS is built
on top of libspe2, so of course there are use cases of MARS where it
can't possibly be more efficient than libspe2.

MARS will only begin to have a chance of being more efficient when
replacing a usage scenario where (# spe_contexts > # physical spes),
and the greater the # spe_contexts, the greater the possibility that
you might see advantages to switch it over to MARS.

Regards,
Yuji