On Thu, Jul 24, 2014 at 09:45:41PM +0100, Chris Tapp wrote:
> I've got a recipe for an application. This has:
>
> 1) A main thread;
> 2) An OpenGL ('X' / EGL) graphics rendering thread created using posix
> threads;
> 3) As many threads as required from the graphics thread for GStreamer to
> service various pipelines.
>
> On a Cedartrail platform this happily uses multiple cores.
Major difference here is graphics chip, cedartrail uses EMGD binary drivers,
baytrail (valleyisland) uses the open source Intel i965 drivers.
I recently (yesterday) updated meta-intel master and daisy to properly support
video acceleration in gstreamer 1.0 - I don't know if this impacts you or not.
>
> However, if I use the same recipe under a 64-bit valleyisland build (daisy) it
> only ever uses a single core (and virtually grinds to a halt).
>
> 'top' shows CPU usage for the application never goes above 25% (J1900, so four
> cores available). Running four instances of 'yes' gets the total CPU usage to
> 100%, so all the cores are available.
Does /proc/cpu list four cores?
>
> 'taskset' shows that the affinity mask for the application is not restricting
> the set of available cores.
>
> Umm... Any ideas what's going on here?
>
> It looks as if GStreamer and OpenGL are fighting for access to something, but
> the pipelines only render to 'fakesink' and 'appsink'.
>
I don't have any GL/GST development experience, so this is likely best taken to
those respective lists.
--
Darren
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
