Boost logo

Boost :

Subject: Re: [boost] [SORT] Parallel Algorithms
From: Steven Ross (spreadsort_at_[hidden])
Date: 2015-04-07 06:42:38


On Mon, Apr 6, 2015 at 10:12 AM Aditya Atluri <abcd_at_[hidden]> wrote:

>
>
> Regards,
> Aditya Atluri.
>
> > On Apr 6, 2015, at 6:53 AM, Steven Ross <spreadsort_at_[hidden]> wrote:
> >
> >> On Mon, Apr 6, 2015 at 1:55 AM, Aditya Atluri <abcd_at_[hidden]>
> wrote:
> >> It's not just CPUs. Most of the physics engines used in games for
> phones are CPU based. The current multi threaded CPU architecture brings
> gamin to a whole new level. I see some physics done with sort, map, gather,
> scatter, and all.
> >>
> >> PS: I proposed this as a part of boost compute this GSoC giving GPU
> support for iOS devices using metal shading language.
> >
> > If you can find somebody whose frame rate on mobile is significantly
> > impacted by CPU sorting speed, I'd love to chat with them
>
> FYI,
> Most of the rendering applications, have asynchronous ability. Like, after
> issuing a draw call, the gpu takes time to render the scene. Meanwhile, the
> CPU does all the physics calculation. Doing physics on the GPU causes
> increase in frame rendering time. This is one of the reason why mobile
> devices are still using CPU based Physics, AI systems. The design call of
> using CPU or GPU depends on the developer by testing the frame rate to be
> reasonable. If the frame rates are high, he may chose to go for GPU based
> Physics or AI. Else he sticks to CPU.
>
> I understand that they're doing physics calculations, but are those
physics calculations containing a substantial amount of purely sequential
sort time, where they can't run other computations in parallel? If so, I'd
be interested in talking with them to understand what they're doing.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk