On 29 Jul 2014, at 16:41, Darren Hart <dvh...@linux.intel.com> wrote:
> 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.
Thanks for the pointer. I'll give it a try and see if it makes a difference.
> 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?
It does.
I've also found that running the GStreamer pipeline outside of (and at the same
time as) my application works as expected - i.e. more CPU resources are used
and the application runs at the target loop time, so the system can definitely
do what I want...
> '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.
Thanks, I've already tried that and not got anything back ;-)
> --
> Darren
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
