Re: [E-devel] New evas image cache server

[David S. <on...@gm...>]

On Thu, 5 Apr 2012 11:20:26 +0200 Vincent Torri
<vin...@gm...> wrote:

> On Thu, Apr 5, 2012 at 11:00 AM, David Seikel <on...@gm...>
> wrote:
> > On Thu, 5 Apr 2012 10:17:42 +0200 Cedric BAIL <ced...@fr...>
> > wrote:
> >
> >> On Thu, Apr 5, 2012 at 1:29 AM, Gustavo Sverzut Barbieri
> >> <bar...@pr...> wrote:
> >> > On Wed, Apr 4, 2012 at 7:23 PM, Vincent Torri
> >> > <vin...@gm...> wrote:
> >> >> On Wed, Apr 4, 2012 at 7:34 PM, Rafael Antognolli
> >> >> <ant...@pr...> wrote:
> >> >> Some questions :
> >> >>  * what about the Coyote and ps3 arch ?
> >> >
> >> > Same as cserve, it will not be supported due the lack of
> >> > multi-process support.
> >>
> >> There is still many non multi-process system out there. I have been
> >> thinking all this night how to make this work. At least they all
> >> have some thread support. So maybe we could have a fallback mode
> >> that instead of making cserve a standalone process, it will become
> >> a thread task. In that case, it does have some implication, how to
> >> handle the main loop ? We should make it possible to run multiple
> >> ecore main loop or have a light main loop support. I don't know
> >> yet. The other question will be, where should we launch this
> >> thread task, in evas ? Then we have a build dependency in it. Or
> >> in Elementary, but it sounds more like a work around. So I really
> >> don't know.
> >>
> >> This is just throwing idea in the air, just in case someone get a
> >> brilliant one and we can fix this use case. If not, that would be
> >> sad, but we should have some time to find a proper solution.
> >>
> >> >>  * will cserve2 be optional like cserve ?
> >> >
> >> > To start, yes. If it proves mature and to work well, Raster
> >> > plans to make it the default mode. If it goes well, it may be
> >> > the only way. As you can expect, there is a long road to it,
> >> > including:
> >> >   - port to other systems (BSD, Windows...)
> >> >   - figure out what to do for too-different archs such as
> >> > single-process native PS3.
> >> >
> >> > For the last point I have not many details. As far as I
> >> > understand the lack of multiprocess in PS3 is an implementation
> >> > issue, that could be added later? (KaKaRoTo voice in!).
> >>
> >> They have no multiprocess, but they do have some kind of thread
> >> support. So there is a way to support this feature at least in
> >> theory, we just need to think about how.
> >
> > PS3 has a hyperthreaded CPU.  Not counting the CELL SPUs, since code
> > for those has to be written specifically for them.
> 
> even if that stuff is available, does the SDK provide these features ?
> If I'm not mistaken, Kakaroto said that the SDK was "limited"

I dunno how limited the native SDK is, but back when you could put
Linux on the PS3, you got Linux access to the entire CPU, and all but
one of the SPUs.  No Linux access to the GPU, at least not direct
access.

On the native SDK I'd expect that you are still missing access to one
of the SPUs.  This does not count the SPU that is simply disabled
to increase chip yields.

On the other hand, Sony has locked the thing down more since last I
programmed with it.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.