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.