Denzil / Cedartrail / EGL/GLES under X

Denzil / Cedartrail / EGL/GLES under X

[Chris Tapp]

Does anyone have a simple recipe they are willing to share that uses meta/intel/cedartrail which shows how to get EGL/GLES running under X?

I've managed to get to the point where I think EGL is up (no API errors reported), but if I try anything on the GL side (e.g. glClear to get the background color) I'm not getting anything showing on the display when I call eglSwapBuffers().

If I run this app in a terminal within Sato then I can see printf-type diagnostics from the program, but nothing else.

I'm not sure how to configure my build to use the cdv-pvr-driver libs rather than the MESA-dri equivalents either. Both provide libGLESv2, etc., but I want the cdv-pvr-driver versions in the final image. However, cdv-prv-driver doesn't seem to have an include directory to use at build time, so MESA needs to be there as well. Is there a PREFERRED_PROVIDER_virtual/libgl value I can use?

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Denzil / Cedartrail / EGL/GLES under X

[Burton, Ross]

Hi Chris,

On 10 September 2012 19:56, Chris Tapp <opensource@keylevel.com> wrote:
> I've managed to get to the point where I think EGL is up (no API errors reported), but if I try anything on the GL side (e.g. glClear to get the background color) I'm not getting anything showing on the display when I call eglSwapBuffers().

GL or GLES?  GL on Cedar Trail is very limited , you're heavily
recommended to use GLES.

> I'm not sure how to configure my build to use the cdv-pvr-driver libs rather than the MESA-dri equivalents either. Both provide libGLESv2, etc., but I want the cdv-pvr-driver versions in the final image. However, cdv-prv-driver doesn't seem to have an include directory to use at build time, so MESA needs to be there as well. Is there a PREFERRED_PROVIDER_virtual/libgl value I can use?

This is a bit of a mess at the moment, and I want to sort it, but it's
a complicated mess.

Building against mesa-dri shouldn't be a problem as all GL
implementations have the same ABI, assuming you can get the
cdv-prv-driver package installed and not mesa-dri on your image.
Preferred providers only work for built-time dependencies, so assuming
that you're having problems with getting mesa-dri out and
cdv-prv-driver in the image you'll need to use something like
RCONFLICTS and RPROVIDES so that the package system uses
cdv-prv-driver instead of mesa-dri.

Ross

Re: Denzil / Cedartrail / EGL/GLES under X

[Saxena, Rahul]

Ross, the definition of RPROVIDES is not given in the Yocto project reference manual.
Perhaps it should be added to the manual ?

Thanks
Rahul

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Burton, Ross
Sent: Thursday, September 13, 2012 4:04 AM
To: Chris Tapp
Cc: yocto@yoctoproject.org Project
Subject: Re: [yocto] Denzil / Cedartrail / EGL/GLES under X

Hi Chris,

On 10 September 2012 19:56, Chris Tapp <opensource@keylevel.com> wrote:
> I've managed to get to the point where I think EGL is up (no API errors reported), but if I try anything on the GL side (e.g. glClear to get the background color) I'm not getting anything showing on the display when I call eglSwapBuffers().

GL or GLES?  GL on Cedar Trail is very limited , you're heavily recommended to use GLES.

> I'm not sure how to configure my build to use the cdv-pvr-driver libs rather than the MESA-dri equivalents either. Both provide libGLESv2, etc., but I want the cdv-pvr-driver versions in the final image. However, cdv-prv-driver doesn't seem to have an include directory to use at build time, so MESA needs to be there as well. Is there a PREFERRED_PROVIDER_virtual/libgl value I can use?

This is a bit of a mess at the moment, and I want to sort it, but it's a complicated mess.

Building against mesa-dri shouldn't be a problem as all GL implementations have the same ABI, assuming you can get the cdv-prv-driver package installed and not mesa-dri on your image.
Preferred providers only work for built-time dependencies, so assuming that you're having problems with getting mesa-dri out and cdv-prv-driver in the image you'll need to use something like RCONFLICTS and RPROVIDES so that the package system uses cdv-prv-driver instead of mesa-dri.

Ross
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: Denzil / Cedartrail / EGL/GLES under X

[Paul Eggleton]

On Thursday 13 September 2012 16:37:59 Saxena, Rahul wrote:
> Ross, the definition of RPROVIDES is not given in the Yocto project
> reference manual. Perhaps it should be added to the manual ?

Good catch - yes, it should. Scott R - I can send you some info.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Denzil / Cedartrail / EGL/GLES under X

[Chris Tapp]

Hi Ross,

On 13 Sep 2012, at 12:03, Burton, Ross wrote:

> On 10 September 2012 19:56, Chris Tapp <opensource@keylevel.com> wrote:
>> I've managed to get to the point where I think EGL is up (no API errors reported), but if I try anything on the GL side (e.g. glClear to get the background color) I'm not getting anything showing on the display when I call eglSwapBuffers().
> 
> GL or GLES?  GL on Cedar Trail is very limited , you're heavily
> recommended to use GLES.

Thanks. That's actually where I'm headed - glClear() was the first step...

I've actually managed to get things working now. Not too sure what I did, but I __think__ it was something to do with the rendering context - I may not have been specifying a GLES2 surface when I was using it. GLES is new to me (GL background), but my copy of the "OpenGL ES 2.0 Programming Guide" arrived today, so I should be on the way ;-)

>> I'm not sure how to configure my build to use the cdv-pvr-driver libs rather than the MESA-dri equivalents either. Both provide libGLESv2, etc., but I want the cdv-pvr-driver versions in the final image. However, cdv-prv-driver doesn't seem to have an include directory to use at build time, so MESA needs to be there as well. Is there a PREFERRED_PROVIDER_virtual/libgl value I can use?
> 
> This is a bit of a mess at the moment, and I want to sort it, but it's
> a complicated mess.
> 
> Building against mesa-dri shouldn't be a problem as all GL
> implementations have the same ABI, assuming you can get the
> cdv-prv-driver package installed and not mesa-dri on your image.
> Preferred providers only work for built-time dependencies, so assuming
> that you're having problems with getting mesa-dri out and
> cdv-prv-driver in the image you'll need to use something like
> RCONFLICTS and RPROVIDES so that the package system uses
> cdv-prv-driver instead of mesa-dri.

It seems to be putting the correct ones in the image as things are working with the simple tests I've got going so far. MD5sum on the libs confirms they are from cdv-prv-driver. No idea how they get used in preference, as I've not used any 'magic' yet!

Thanks for the help :-)

Chris Tapp

opensource@keylevel.com
www.keylevel.com