Patchwork [00/12] Mesa upgrade/improvements

login
register
mail settings
Submitter Ross Burton
Date Aug. 1, 2012, 12:31 p.m.
Message ID <cover.1343823907.git.ross.burton@intel.com>
Download mbox
Permalink /patch/33517/
State New
Headers show

Pull-request

git://git.yoctoproject.org/poky-contrib ross/mesa

Comments

Ross Burton - Aug. 1, 2012, 12:31 p.m.
This patch series upgrades mesa-dri to the latest upstream, enables GLES2 and
EGL, and lets mesa-dri build without X11.  mesa-xlib doesn't get all the new
packages as it's not that useful (no HW acceleration).

Tested on a Sandy Bridge, running glxgears/gles2gears.

The following changes since commit 3309cf42d314f0a26079a11836c6b9b9bb5f253e:

  package_rpm.bbclass: Accomodate dash when using arrays (2012-07-31 12:22:10 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ross/mesa

for you to fetch changes up to 9a9c6f98362245a91a2e58daef6c4ff1bb415881:

  mesa-demos: fix GLES2 build (2012-08-01 13:17:10 +0100)

----------------------------------------------------------------
Damien Lespiau (2):
      mesa: Update to 8.0.4 (latest stable version)
      mesa: Use 'require' instead of 'include'

Ross Burton (10):
      mesa: format the packages list nicely
      mesa: move glu.pc to libglu-dev
      mesa: add --enable-shared-glapi, and package it in libglapi
      mesa: enable the Graphic Buffer Manager library
      mesa: enable GLESv2
      mesa: enable EGL, with DRM and X11 platforms
      mesa: respect x11 DISTRO_FEATURE
      poky: add EGL and OpenGLESv2 features
      mesa: no need to depend on python-native, the class does that
      mesa-demos: fix GLES2 build

 meta-yocto/conf/distro/poky.conf                   |    2 +-
 ...a-dri_7.11.bbappend => mesa-dri_8.0.4.bbappend} |    0
 .../mesa/{mesa-7.11.inc => mesa-8.0.4.inc}         |   14 +++---
 meta/recipes-graphics/mesa/mesa-common.inc         |   37 ++++++++++----
 meta/recipes-graphics/mesa/mesa-demos_8.0.1.bb     |    5 +-
 ...ative_7.11.bb => mesa-dri-glsl-native_8.0.4.bb} |    4 +-
 meta/recipes-graphics/mesa/mesa-dri.inc            |   11 ++++-
 meta/recipes-graphics/mesa/mesa-dri_7.11.bb        |    4 --
 meta/recipes-graphics/mesa/mesa-dri_8.0.4.bb       |    4 ++
 meta/recipes-graphics/mesa/mesa-dri_git.bb         |    6 +--
 meta/recipes-graphics/mesa/mesa-git.inc            |   11 +++--
 meta/recipes-graphics/mesa/mesa-xlib_7.11.bb       |    5 --
 meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb      |    5 ++
 meta/recipes-graphics/mesa/mesa-xlib_git.bb        |    6 +--
 .../mesa/mesa/0001-Compile-with-uclibc.patch       |   52 ++++++++++++++++++++
 ...ossfix-mklib.patch => 0002-cross-compile.patch} |   39 ++++++++++++---
 ...sa_fix_for_x32.patch => 0003-fix-for-x32.patch} |   30 +++++++----
 ...-gross-hack-to-prevent-from-install-libgl.patch |   29 +++++++++++
 meta/recipes-graphics/mesa/mesa/crossfix.patch     |   18 -------
 meta/recipes-graphics/mesa/mesa/uclibc.patch       |   42 ----------------
 20 files changed, 204 insertions(+), 120 deletions(-)
 rename meta-yocto/recipes-graphics/mesa/{mesa-dri_7.11.bbappend => mesa-dri_8.0.4.bbappend} (100%)
 rename meta/recipes-graphics/mesa/{mesa-7.11.inc => mesa-8.0.4.inc} (60%)
 rename meta/recipes-graphics/mesa/{mesa-dri-glsl-native_7.11.bb => mesa-dri-glsl-native_8.0.4.bb} (84%)
 delete mode 100644 meta/recipes-graphics/mesa/mesa-dri_7.11.bb
 create mode 100644 meta/recipes-graphics/mesa/mesa-dri_8.0.4.bb
 delete mode 100644 meta/recipes-graphics/mesa/mesa-xlib_7.11.bb
 create mode 100644 meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb
 create mode 100644 meta/recipes-graphics/mesa/mesa/0001-Compile-with-uclibc.patch
 rename meta/recipes-graphics/mesa/mesa/{crossfix-mklib.patch => 0002-cross-compile.patch} (68%)
 rename meta/recipes-graphics/mesa/mesa/{mesa_fix_for_x32.patch => 0003-fix-for-x32.patch} (59%)
 create mode 100644 meta/recipes-graphics/mesa/mesa/0004-gross-hack-to-prevent-from-install-libgl.patch
 delete mode 100644 meta/recipes-graphics/mesa/mesa/crossfix.patch
 delete mode 100644 meta/recipes-graphics/mesa/mesa/uclibc.patch

Damien Lespiau (2):
  mesa: Update to 8.0.4 (latest stable version)
  mesa: Use 'require' instead of 'include'

Ross Burton (10):
  mesa: format the packages list nicely
  mesa: move glu.pc to libglu-dev
  mesa: add --enable-shared-glapi, and package it in libglapi
  mesa: enable the Graphic Buffer Manager library
  mesa: enable GLESv2
  mesa: enable EGL, with DRM and X11 platforms
  mesa: respect x11 DISTRO_FEATURE
  poky: add EGL and OpenGLESv2 features
  mesa: no need to depend on python-native, the class does that
  mesa-demos: fix GLES2 build

 meta-yocto/conf/distro/poky.conf                   |    2 +-
 ...a-dri_7.11.bbappend => mesa-dri_8.0.4.bbappend} |    0
 .../mesa/{mesa-7.11.inc => mesa-8.0.4.inc}         |   14 +++---
 meta/recipes-graphics/mesa/mesa-common.inc         |   37 ++++++++++----
 meta/recipes-graphics/mesa/mesa-demos_8.0.1.bb     |    5 +-
 ...ative_7.11.bb => mesa-dri-glsl-native_8.0.4.bb} |    4 +-
 meta/recipes-graphics/mesa/mesa-dri.inc            |   11 ++++-
 meta/recipes-graphics/mesa/mesa-dri_7.11.bb        |    4 --
 meta/recipes-graphics/mesa/mesa-dri_8.0.4.bb       |    4 ++
 meta/recipes-graphics/mesa/mesa-dri_git.bb         |    6 +--
 meta/recipes-graphics/mesa/mesa-git.inc            |   11 +++--
 meta/recipes-graphics/mesa/mesa-xlib_7.11.bb       |    5 --
 meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb      |    5 ++
 meta/recipes-graphics/mesa/mesa-xlib_git.bb        |    6 +--
 .../mesa/mesa/0001-Compile-with-uclibc.patch       |   52 ++++++++++++++++++++
 ...ossfix-mklib.patch => 0002-cross-compile.patch} |   39 ++++++++++++---
 ...sa_fix_for_x32.patch => 0003-fix-for-x32.patch} |   30 +++++++----
 ...-gross-hack-to-prevent-from-install-libgl.patch |   29 +++++++++++
 meta/recipes-graphics/mesa/mesa/crossfix.patch     |   18 -------
 meta/recipes-graphics/mesa/mesa/uclibc.patch       |   42 ----------------
 20 files changed, 204 insertions(+), 120 deletions(-)
 rename meta-yocto/recipes-graphics/mesa/{mesa-dri_7.11.bbappend => mesa-dri_8.0.4.bbappend} (100%)
 rename meta/recipes-graphics/mesa/{mesa-7.11.inc => mesa-8.0.4.inc} (60%)
 rename meta/recipes-graphics/mesa/{mesa-dri-glsl-native_7.11.bb => mesa-dri-glsl-native_8.0.4.bb} (84%)
 delete mode 100644 meta/recipes-graphics/mesa/mesa-dri_7.11.bb
 create mode 100644 meta/recipes-graphics/mesa/mesa-dri_8.0.4.bb
 delete mode 100644 meta/recipes-graphics/mesa/mesa-xlib_7.11.bb
 create mode 100644 meta/recipes-graphics/mesa/mesa-xlib_8.0.4.bb
 create mode 100644 meta/recipes-graphics/mesa/mesa/0001-Compile-with-uclibc.patch
 rename meta/recipes-graphics/mesa/mesa/{crossfix-mklib.patch => 0002-cross-compile.patch} (68%)
 rename meta/recipes-graphics/mesa/mesa/{mesa_fix_for_x32.patch => 0003-fix-for-x32.patch} (59%)
 create mode 100644 meta/recipes-graphics/mesa/mesa/0004-gross-hack-to-prevent-from-install-libgl.patch
 delete mode 100644 meta/recipes-graphics/mesa/mesa/crossfix.patch
 delete mode 100644 meta/recipes-graphics/mesa/mesa/uclibc.patch
Koen Kooi - Aug. 1, 2012, 1:32 p.m.
Op 1 aug. 2012, om 14:31 heeft Ross Burton <ross.burton@intel.com> het volgende geschreven:

> This patch series upgrades mesa-dri to the latest upstream, enables GLES2 and
> EGL

That will sadly break all the powervr based evil binaries (e.g. all cortex arm chips from TI) since there will be 2 providers of those libs. I looked at this a few years ago (when mesa gained libegl) and I couldn't come up with a  solution other than "don't build it" :( That solution also breaks a number of usecases but back then I had the liberty to not care about those.
Does anyone have suggestions on how to handle this? 

regards,

Koen
Ross Burton - Aug. 1, 2012, 1:41 p.m.
On 1 August 2012 14:32, Koen Kooi <koen@dominion.thruhere.net> wrote:
> That will sadly break all the powervr based evil binaries (e.g. all cortex arm chips from TI) since there will be 2 providers of those libs. I looked at this a few years ago (when mesa gained libegl) and I couldn't come up with a  solution other than "don't build it" :( That solution also breaks a number of usecases but back then I had the liberty to not care about those.
> Does anyone have suggestions on how to handle this?

Rename the mesa ones to libegl-mesa (etc), and encourage TI to use libegl-ti?

Ross
Koen Kooi - Aug. 1, 2012, 2:33 p.m.
Op 1 aug. 2012, om 15:41 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:

> On 1 August 2012 14:32, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> That will sadly break all the powervr based evil binaries (e.g. all cortex arm chips from TI) since there will be 2 providers of those libs. I looked at this a few years ago (when mesa gained libegl) and I couldn't come up with a  solution other than "don't build it" :( That solution also breaks a number of usecases but back then I had the liberty to not care about those.
>> Does anyone have suggestions on how to handle this?
> 
> Rename the mesa ones to libegl-mesa (etc), and encourage TI to use libegl-ti?

Recipe names don't matter, the .so files in sysroots and shlibdeps do.
Ross Burton - Aug. 1, 2012, 2:34 p.m.
On 1 August 2012 15:33, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> Rename the mesa ones to libegl-mesa (etc), and encourage TI to use libegl-ti?
>
> Recipe names don't matter, the .so files in sysroots and shlibdeps do.

I meant the name of the generated package.  libegl-mesa and libegl-ti
shipping the same libraries is expected and desired.

Ross
Damien Lespiau - Aug. 1, 2012, 2:38 p.m.
On 1 August 2012 14:32, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 1 aug. 2012, om 14:31 heeft Ross Burton <ross.burton@intel.com> het volgende geschreven:
>
>> This patch series upgrades mesa-dri to the latest upstream, enables GLES2 and
>> EGL
>
> That will sadly break all the powervr based evil binaries (e.g. all cortex arm chips from TI) since there will be 2 providers of those libs.

Why could one prefer providers of virtual/libgles2 and virtual/ligegl
on a per-machine basis. This maps quite well with the reality.
Koen Kooi - Aug. 1, 2012, 2:54 p.m.
Op 1 aug. 2012, om 16:34 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:

> On 1 August 2012 15:33, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>> Rename the mesa ones to libegl-mesa (etc), and encourage TI to use libegl-ti?
>> 
>> Recipe names don't matter, the .so files in sysroots and shlibdeps do.
> 
> I meant the name of the generated package.  libegl-mesa and libegl-ti
> shipping the same libraries is expected and desired.

That won't work with debian renaming and shlib will pick up both anyway. You can only have one libegl.so *ever* during the build.
Koen Kooi - Aug. 1, 2012, 2:54 p.m.
Op 1 aug. 2012, om 16:38 heeft Damien Lespiau <damien.lespiau@gmail.com> het volgende geschreven:

> On 1 August 2012 14:32, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> 
>> Op 1 aug. 2012, om 14:31 heeft Ross Burton <ross.burton@intel.com> het volgende geschreven:
>> 
>>> This patch series upgrades mesa-dri to the latest upstream, enables GLES2 and
>>> EGL
>> 
>> That will sadly break all the powervr based evil binaries (e.g. all cortex arm chips from TI) since there will be 2 providers of those libs.
> 
> Why could one prefer providers of virtual/libgles2 and virtual/ligegl
> on a per-machine basis. This maps quite well with the reality.

Apart from the fact that both aren't machine specific. Making them machine specific would be a regression.
Ross Burton - Aug. 1, 2012, 2:57 p.m.
On 1 August 2012 15:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Apart from the fact that both aren't machine specific. Making them machine specific would be a regression.

Theoretically, yes.  Practically, only one of the libegl.so (libgl,
etc etc) actually works on a particular machine.

Ross
Ross Burton - Aug. 1, 2012, 3:17 p.m.
On 1 August 2012 15:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
> That won't work with debian renaming and shlib will pick up both anyway. You can only have one libegl.so *ever* during the build.

In Debian the packages are renamed libgles2-mesa, and so on...

Ross
Koen Kooi - Aug. 1, 2012, 3:54 p.m.
Op 1 aug. 2012, om 16:57 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:

> On 1 August 2012 15:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> Apart from the fact that both aren't machine specific. Making them machine specific would be a regression.
> 
> Theoretically, yes.  Practically, only one of the libegl.so (libgl,
> etc etc) actually works on a particular machine.

Yes, but a libegl.so works on a range of machines, not a single one.