Patchwork [V3,00/11] Mesa upgrade/improvements

login
register
mail settings
Submitter Ross Burton
Date Aug. 2, 2012, 4:48 p.m.
Message ID <cover.1343926021.git.ross.burton@intel.com>
Download mbox
Permalink /patch/33701/
State New
Headers show

Pull-request

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

Comments

Ross Burton - Aug. 2, 2012, 4:48 p.m.
Re-arranged and fixed up some problems.

The following changes since commit 62d42fe3cfa575cb97b484ccf7b2e9a25cc50770:

  tiny-init: Setup /dev/ptmx in init (2012-08-01 23:11:18 +0100)

are available in the git repository at:

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

for you to fetch changes up to 5de29e150a720ccb8749362cfe5fb56f234fb385:

  mesa: enable EGL, with DRM and X11 platforms (2012-08-02 17:43:18 +0100)

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

Ross Burton (9):
      mesa: no need to depend on python-native, the class does that
      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 GLES v1 and v2
      mesa-demos: fix GLES2 build
      mesa: respect x11 DISTRO_FEATURE
      mesa: enable EGL, with DRM and X11 platforms

 .../mesa/{mesa-7.11.inc => mesa-8.0.4.inc}         |   14 +++---
 meta/recipes-graphics/mesa/mesa-common.inc         |   43 +++++++++++-----
 .../mesa/mesa-demos/gles2-info.patch               |   15 ++++++
 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            |   12 ++++-
 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 ----------------
 19 files changed, 222 insertions(+), 122 deletions(-)
 rename meta/recipes-graphics/mesa/{mesa-7.11.inc => mesa-8.0.4.inc} (60%)
 create mode 100644 meta/recipes-graphics/mesa/mesa-demos/gles2-info.patch
 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 (9):
  mesa: no need to depend on python-native, the class does that
  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 GLES v1 and v2
  mesa-demos: fix GLES2 build
  mesa: respect x11 DISTRO_FEATURE
  mesa: enable EGL, with DRM and X11 platforms

 .../mesa/{mesa-7.11.inc => mesa-8.0.4.inc}         |   14 +++---
 meta/recipes-graphics/mesa/mesa-common.inc         |   43 +++++++++++-----
 .../mesa/mesa-demos/gles2-info.patch               |   15 ++++++
 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            |   12 ++++-
 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 ----------------
 19 files changed, 222 insertions(+), 122 deletions(-)
 rename meta/recipes-graphics/mesa/{mesa-7.11.inc => mesa-8.0.4.inc} (60%)
 create mode 100644 meta/recipes-graphics/mesa/mesa-demos/gles2-info.patch
 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
Martin Jansa - Aug. 2, 2012, 5:04 p.m.
On Thu, Aug 02, 2012 at 05:48:54PM +0100, Ross Burton wrote:
> Re-arranged and fixed up some problems.
> 
> The following changes since commit 62d42fe3cfa575cb97b484ccf7b2e9a25cc50770:
> 
>   tiny-init: Setup /dev/ptmx in init (2012-08-01 23:11:18 +0100)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib ross/mesa
> 
> for you to fetch changes up to 5de29e150a720ccb8749362cfe5fb56f234fb385:
> 
>   mesa: enable EGL, with DRM and X11 platforms (2012-08-02 17:43:18 +0100)

I haven't even build tested it yet, but looks good to me, thanks for
implementing those comments.

Cheers,

> 
> ----------------------------------------------------------------
> Damien Lespiau (2):
>       mesa: Update to 8.0.4 (latest stable version)
>       mesa: Use 'require' instead of 'include'
> 
> Ross Burton (9):
>       mesa: no need to depend on python-native, the class does that
>       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 GLES v1 and v2
>       mesa-demos: fix GLES2 build
>       mesa: respect x11 DISTRO_FEATURE
>       mesa: enable EGL, with DRM and X11 platforms
> 
>  .../mesa/{mesa-7.11.inc => mesa-8.0.4.inc}         |   14 +++---
>  meta/recipes-graphics/mesa/mesa-common.inc         |   43 +++++++++++-----
>  .../mesa/mesa-demos/gles2-info.patch               |   15 ++++++
>  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            |   12 ++++-
>  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 ----------------
>  19 files changed, 222 insertions(+), 122 deletions(-)
>  rename meta/recipes-graphics/mesa/{mesa-7.11.inc => mesa-8.0.4.inc} (60%)
>  create mode 100644 meta/recipes-graphics/mesa/mesa-demos/gles2-info.patch
>  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 (9):
>   mesa: no need to depend on python-native, the class does that
>   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 GLES v1 and v2
>   mesa-demos: fix GLES2 build
>   mesa: respect x11 DISTRO_FEATURE
>   mesa: enable EGL, with DRM and X11 platforms
> 
>  .../mesa/{mesa-7.11.inc => mesa-8.0.4.inc}         |   14 +++---
>  meta/recipes-graphics/mesa/mesa-common.inc         |   43 +++++++++++-----
>  .../mesa/mesa-demos/gles2-info.patch               |   15 ++++++
>  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            |   12 ++++-
>  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 ----------------
>  19 files changed, 222 insertions(+), 122 deletions(-)
>  rename meta/recipes-graphics/mesa/{mesa-7.11.inc => mesa-8.0.4.inc} (60%)
>  create mode 100644 meta/recipes-graphics/mesa/mesa-demos/gles2-info.patch
>  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
> 
> -- 
> 1.7.10
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Ross Burton - Aug. 2, 2012, 5:13 p.m.
Damnit, some PR bumps disappeared in the conflicting merges.  Pretend
they are all there and I'll fix the branch.

Ross
Koen Kooi - Aug. 2, 2012, 6:38 p.m.
Op 2 aug. 2012, om 18:48 heeft Ross Burton <ross.burton@intel.com> het volgende geschreven:

> Re-arranged and fixed up some problems.

This will still break every platform with a binary libegl and libgles.

> 
> The following changes since commit 62d42fe3cfa575cb97b484ccf7b2e9a25cc50770:
> 
>  tiny-init: Setup /dev/ptmx in init (2012-08-01 23:11:18 +0100)
> 
> are available in the git repository at:
> 
>  git://git.yoctoproject.org/poky-contrib ross/mesa
> 
> for you to fetch changes up to 5de29e150a720ccb8749362cfe5fb56f234fb385:
> 
>  mesa: enable EGL, with DRM and X11 platforms (2012-08-02 17:43:18 +0100)
> 
> ----------------------------------------------------------------
> Damien Lespiau (2):
>      mesa: Update to 8.0.4 (latest stable version)
>      mesa: Use 'require' instead of 'include'
> 
> Ross Burton (9):
>      mesa: no need to depend on python-native, the class does that
>      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 GLES v1 and v2
>      mesa-demos: fix GLES2 build
>      mesa: respect x11 DISTRO_FEATURE
>      mesa: enable EGL, with DRM and X11 platforms
> 
> .../mesa/{mesa-7.11.inc => mesa-8.0.4.inc}         |   14 +++---
> meta/recipes-graphics/mesa/mesa-common.inc         |   43 +++++++++++-----
> .../mesa/mesa-demos/gles2-info.patch               |   15 ++++++
> 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            |   12 ++++-
> 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 ----------------
> 19 files changed, 222 insertions(+), 122 deletions(-)
> rename meta/recipes-graphics/mesa/{mesa-7.11.inc => mesa-8.0.4.inc} (60%)
> create mode 100644 meta/recipes-graphics/mesa/mesa-demos/gles2-info.patch
> 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 (9):
>  mesa: no need to depend on python-native, the class does that
>  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 GLES v1 and v2
>  mesa-demos: fix GLES2 build
>  mesa: respect x11 DISTRO_FEATURE
>  mesa: enable EGL, with DRM and X11 platforms
> 
> .../mesa/{mesa-7.11.inc => mesa-8.0.4.inc}         |   14 +++---
> meta/recipes-graphics/mesa/mesa-common.inc         |   43 +++++++++++-----
> .../mesa/mesa-demos/gles2-info.patch               |   15 ++++++
> 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            |   12 ++++-
> 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 ----------------
> 19 files changed, 222 insertions(+), 122 deletions(-)
> rename meta/recipes-graphics/mesa/{mesa-7.11.inc => mesa-8.0.4.inc} (60%)
> create mode 100644 meta/recipes-graphics/mesa/mesa-demos/gles2-info.patch
> 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
> 
> -- 
> 1.7.10
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Ross Burton - Aug. 2, 2012, 7:03 p.m.
On Thursday, 2 August 2012 at 19:38, Koen Kooi wrote:
> This will still break every platform with a binary libegl and libgles.

That is true and I'm all ears for suggestions. My best proposal so far is to let a package hint a prefix to the Debian renamer, so these packages get renamed to libmesa-gl, libmesa-egl, etc.

That said I'm very curious how every platform with a binary libgl isn't already broken.  If that works for some reason then voila we have a solution, and if they are already broken then we're not breaking it any more than it was already broken.

Ross
Koen Kooi - Aug. 3, 2012, 10:18 a.m.
Op 2 aug. 2012, om 21:03 heeft Ross Burton <ross.burton@intel.com> het volgende geschreven:

> On Thursday, 2 August 2012 at 19:38, Koen Kooi wrote:
>> This will still break every platform with a binary libegl and libgles.
> 
> That is true and I'm all ears for suggestions. My best proposal so far is to let a package hint a prefix to the Debian renamer, so these packages get renamed to libmesa-gl, libmesa-egl, etc.
> 
> That said I'm very curious how every platform with a binary libgl isn't already broken.

libegl and libgles aren't built nowadays, so the problem is avoided. Noone has dared to touch this subject the past 2.5 years: http://cgit.openembedded.org/openembedded/commit/recipes/mesa?id=3d96f8cb61225d515b5cb4fe863f0d50c3ced436

The best solution[1] is to disable egl/gles in the mesa-recipes and add a seperate recipe for them. That way you still get glu and other useful mesa bits needed for gnome/efl/xfce/etc, but you can skip the sysroot/shlib poisoning if needed.

regards,

Koen

[1] The best solution if of course getting sgx support into mesa, but nothing is happening on that front apart from some posturing on the fsf side, no actual code.
Ross Burton - Aug. 3, 2012, 1:19 p.m.
On Friday, 3 August 2012 at 11:18, Koen Kooi wrote:
> libegl and libgles aren't built nowadays, so the problem is avoided. Noone has dared to touch this subject the past 2.5 years: http://cgit.openembedded.org/openembedded/commit/recipes/mesa?id=3d96f8cb61225d515b5cb4fe863f0d50c3ced436
> 
> The best solution[1] is to disable egl/gles in the mesa-recipes and add a seperate recipe for them. That way you still get glu and other useful mesa bits needed for gnome/efl/xfce/etc, but you can skip the sysroot/shlib poisoning if needed.
After much digging I see that the Beagle PVR drivers only provide gles and egl, which is why you say that the problem was avoided.  Of course that's just one specific driver, for example the Cedar Trail EMGD driver does build libgl, libgles and libegl.

If the solution is "put the egl/gles bits in another package" then I'm totally confused as to what the actual problem is.  Considering there's numerous libegl libraries for the many variants of PVR on ARM, I'm struggling to understand exactly what is new here.

Can you explain clearly what the problem is, I'm obviously missing something.  Once I understand the problem I can help with a solution.
> [1] The best solution if of course getting sgx support into mesa, but nothing is happening on that front apart from some posturing on the fsf side, no actual code.

HahahHAHAHAHahha.  (wipes tears from eyes)  The FSF can posture all they want (wasn't aware they'd done that as the code is clearly closed source), but I can't see Imagination opening all their code any day soon.

Cheers,
Ross
Koen Kooi - Aug. 3, 2012, 3:46 p.m.
Op 3 aug. 2012, om 15:19 heeft Ross Burton <ross.burton@intel.com> het volgende geschreven:

> On Friday, 3 August 2012 at 11:18, Koen Kooi wrote:
>> libegl and libgles aren't built nowadays, so the problem is avoided. Noone has dared to touch this subject the past 2.5 years: http://cgit.openembedded.org/openembedded/commit/recipes/mesa?id=3d96f8cb61225d515b5cb4fe863f0d50c3ced436
>> 
>> The best solution[1] is to disable egl/gles in the mesa-recipes and add a seperate recipe for them. That way you still get glu and other useful mesa bits needed for gnome/efl/xfce/etc, but you can skip the sysroot/shlib poisoning if needed.
> After much digging I see that the Beagle PVR drivers only provide gles and egl, which is why you say that the problem was avoided.  Of course that's just one specific driver, for example the Cedar Trail EMGD driver does build libgl, libgles and libegl.
> 
> If the solution is "put the egl/gles bits in another package"

Recipe, not package. Big difference :)

> then I'm totally confused as to what the actual problem is.  Considering there's numerous libegl libraries for the many variants of PVR on ARM, I'm struggling to understand exactly what is new here.
> 
> Can you explain clearly what the problem is, I'm obviously missing something.  Once I understand the problem I can help with a solution.

You need mesa for the !egl and !gles libs and evil vendor blob for egl and gles libs. In the emgd case you can get gl from the evil vendor as well. To build e.g. EFL I need mesa for the !egl and !gles bits, to build EFL with gles support I need mesa (again !egl, !gles) in addition to evil vendor blob for egl and gles. 
We could make this work with MACHINE_FEATURES or something similar, but that would mean that a very large chunk of userspace now becomes machine specific. This is how clutter worked in the past and just look at the fit the canonical/linaro people threw when they started doing 'embedded' and clutter.

To compress the above: you need to build both the mesa and the evil-egl-binary *recipes* for things to work, so the egl bits should be a different recipe, not a subpackage of the mesa recipe. This is all assuming we care abou the binary blobs e.g. TI distributes for 3d support. If you don't, fine, merge this patchset.

>> [1] The best solution if of course getting sgx support into mesa, but nothing is happening on that front apart from some posturing on the fsf side, no actual code.
> 
> HahahHAHAHAHahha.  (wipes tears from eyes)  The FSF can posture all they want (wasn't aware they'd done that as the code is clearly closed source), but I can't see Imagination opening all their code any day soon.

It's a reverse engineering effort in which only FSF marketing is involved. Their idea is right, look at the Mali and Adreneo RE work, that's coming along nicely.
Richard Purdie - Aug. 6, 2012, 12:43 p.m.
On Fri, 2012-08-03 at 17:46 +0200, Koen Kooi wrote:
> Op 3 aug. 2012, om 15:19 heeft Ross Burton <ross.burton@intel.com> het
> volgende geschreven:
> 
> > On Friday, 3 August 2012 at 11:18, Koen Kooi wrote:
> >> libegl and libgles aren't built nowadays, so the problem is
> avoided. Noone has dared to touch this subject the past 2.5 years:
> http://cgit.openembedded.org/openembedded/commit/recipes/mesa?id=3d96f8cb61225d515b5cb4fe863f0d50c3ced436
> >> 
> >> The best solution[1] is to disable egl/gles in the mesa-recipes and
> add a seperate recipe for them. That way you still get glu and other
> useful mesa bits needed for gnome/efl/xfce/etc, but you can skip the
> sysroot/shlib poisoning if needed.
> > After much digging I see that the Beagle PVR drivers only provide
> gles and egl, which is why you say that the problem was avoided.  Of
> course that's just one specific driver, for example the Cedar Trail
> EMGD driver does build libgl, libgles and libegl.
> > 
> > If the solution is "put the egl/gles bits in another package"
> 
> Recipe, not package. Big difference :)
> 
> > then I'm totally confused as to what the actual problem is.
> Considering there's numerous libegl libraries for the many variants of
> PVR on ARM, I'm struggling to understand exactly what is new here.
> > 
> > Can you explain clearly what the problem is, I'm obviously missing
> something.  Once I understand the problem I can help with a solution.
> 
> You need mesa for the !egl and !gles libs and evil vendor blob for egl
> and gles libs. In the emgd case you can get gl from the evil vendor as
> well. To build e.g. EFL I need mesa for the !egl and !gles bits, to
> build EFL with gles support I need mesa (again !egl, !gles) in
> addition to evil vendor blob for egl and gles. 
> We could make this work with MACHINE_FEATURES or something similar,
> but that would mean that a very large chunk of userspace now becomes
> machine specific. This is how clutter worked in the past and just look
> at the fit the canonical/linaro people threw when they started doing
> 'embedded' and clutter.
> 
> To compress the above: you need to build both the mesa and the
> evil-egl-binary *recipes* for things to work, so the egl bits should
> be a different recipe, not a subpackage of the mesa recipe. This is
> all assuming we care abou the binary blobs e.g. TI distributes for 3d
> support. If you don't, fine, merge this patchset.

Let me test this a little bit more. The binary blobs shipped by TI would
be machine specific and would be marked as such in the package feeds?
The mesa pieces would be marked as architecture specific and more
generic. In feeds, machine specific has priority so on the machines
where there is hardware support, the hardware optimised versions would
get installed?

If the above isn't the case, can we make it work like that?

Cheers,

Richard
Koen Kooi - Aug. 6, 2012, 1:24 p.m.
Op 6 aug. 2012, om 14:43 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:

> On Fri, 2012-08-03 at 17:46 +0200, Koen Kooi wrote:
>> Op 3 aug. 2012, om 15:19 heeft Ross Burton <ross.burton@intel.com> het
>> volgende geschreven:
>> 
>>> On Friday, 3 August 2012 at 11:18, Koen Kooi wrote:
>>>> libegl and libgles aren't built nowadays, so the problem is
>> avoided. Noone has dared to touch this subject the past 2.5 years:
>> http://cgit.openembedded.org/openembedded/commit/recipes/mesa?id=3d96f8cb61225d515b5cb4fe863f0d50c3ced436
>>>> 
>>>> The best solution[1] is to disable egl/gles in the mesa-recipes and
>> add a seperate recipe for them. That way you still get glu and other
>> useful mesa bits needed for gnome/efl/xfce/etc, but you can skip the
>> sysroot/shlib poisoning if needed.
>>> After much digging I see that the Beagle PVR drivers only provide
>> gles and egl, which is why you say that the problem was avoided.  Of
>> course that's just one specific driver, for example the Cedar Trail
>> EMGD driver does build libgl, libgles and libegl.
>>> 
>>> If the solution is "put the egl/gles bits in another package"
>> 
>> Recipe, not package. Big difference :)
>> 
>>> then I'm totally confused as to what the actual problem is.
>> Considering there's numerous libegl libraries for the many variants of
>> PVR on ARM, I'm struggling to understand exactly what is new here.
>>> 
>>> Can you explain clearly what the problem is, I'm obviously missing
>> something.  Once I understand the problem I can help with a solution.
>> 
>> You need mesa for the !egl and !gles libs and evil vendor blob for egl
>> and gles libs. In the emgd case you can get gl from the evil vendor as
>> well. To build e.g. EFL I need mesa for the !egl and !gles bits, to
>> build EFL with gles support I need mesa (again !egl, !gles) in
>> addition to evil vendor blob for egl and gles. 
>> We could make this work with MACHINE_FEATURES or something similar,
>> but that would mean that a very large chunk of userspace now becomes
>> machine specific. This is how clutter worked in the past and just look
>> at the fit the canonical/linaro people threw when they started doing
>> 'embedded' and clutter.
>> 
>> To compress the above: you need to build both the mesa and the
>> evil-egl-binary *recipes* for things to work, so the egl bits should
>> be a different recipe, not a subpackage of the mesa recipe. This is
>> all assuming we care abou the binary blobs e.g. TI distributes for 3d
>> support. If you don't, fine, merge this patchset.
> 
> Let me test this a little bit more. The binary blobs shipped by TI would
> be machine specific

They aren't machine specific, they contain multiple blobs to support a wide range of SoCs. But even if they were machine specific it wouldn't work like you want to.

> and would be marked as such in the package feeds?
> The mesa pieces would be marked as architecture specific and more
> generic. In feeds, machine specific has priority so on the machines
> where there is hardware support, the hardware optimised versions would
> get installed?

You're assuming all libraries are subpackaged into their own package and renamed identically, they aren't (which is actually a feature in the current situation).

> If the above isn't the case, can we make it work like that?

We can't. Even if we could, it would be a giant step backwards for people using the output of the build (see below).

The only solution that keeps the good things of the current situation is to have the following recipes:

1) mesa (does not build libgl or libgles)
2) mesa-gles (only builds libgl+libgles)
3) evil-vendor-blob

And you can specify per SoC something like PREFERRED_PROVIDER_virtual/egl = "mesa-gles" or PREFERRED_PROVIDER_virtual/egl = "evil-vendor-blob".

That will cause problems if you are building for 2 SoCs in the same architecture family that need different gl providers, the shlib code might get a bit upset. I don't have a good solution for that, but we have that problem right now as well.

From the build side we could make it a bit prettier by making all the gl stuff machine specific, but that will be a giant pain in the ass for the end user (distro maintainer,  $silicon_vendor customer, $silicon_vendor SDK). If we end up doing it like that, we'll need buy-in from the silicon vendors involved to change the way they distribute their blobs. That is doable, I managed to get the TI blobs changed a few times in the past, but it's a slow process.
And everything using GL would suddenly be machine specific, I hope the yocto autobuilder can keep up with that.

Executive summary: ARM SoCs with 3d suck, Intel parts with 3d sucks less. It's a mess in oe-core.

regards,

Koen
Richard Purdie - Aug. 6, 2012, 2:04 p.m.
On Mon, 2012-08-06 at 15:24 +0200, Koen Kooi wrote:
> Op 6 aug. 2012, om 14:43 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
> 
> > On Fri, 2012-08-03 at 17:46 +0200, Koen Kooi wrote:
> >> Op 3 aug. 2012, om 15:19 heeft Ross Burton <ross.burton@intel.com> het
> >> volgende geschreven:
> >> 
> >>> On Friday, 3 August 2012 at 11:18, Koen Kooi wrote:
> >>>> libegl and libgles aren't built nowadays, so the problem is
> >> avoided. Noone has dared to touch this subject the past 2.5 years:
> >> http://cgit.openembedded.org/openembedded/commit/recipes/mesa?id=3d96f8cb61225d515b5cb4fe863f0d50c3ced436
> >>>> 
> >>>> The best solution[1] is to disable egl/gles in the mesa-recipes and
> >> add a seperate recipe for them. That way you still get glu and other
> >> useful mesa bits needed for gnome/efl/xfce/etc, but you can skip the
> >> sysroot/shlib poisoning if needed.
> >>> After much digging I see that the Beagle PVR drivers only provide
> >> gles and egl, which is why you say that the problem was avoided.  Of
> >> course that's just one specific driver, for example the Cedar Trail
> >> EMGD driver does build libgl, libgles and libegl.
> >>> 
> >>> If the solution is "put the egl/gles bits in another package"
> >> 
> >> Recipe, not package. Big difference :)
> >> 
> >>> then I'm totally confused as to what the actual problem is.
> >> Considering there's numerous libegl libraries for the many variants of
> >> PVR on ARM, I'm struggling to understand exactly what is new here.
> >>> 
> >>> Can you explain clearly what the problem is, I'm obviously missing
> >> something.  Once I understand the problem I can help with a solution.
> >> 
> >> You need mesa for the !egl and !gles libs and evil vendor blob for egl
> >> and gles libs. In the emgd case you can get gl from the evil vendor as
> >> well. To build e.g. EFL I need mesa for the !egl and !gles bits, to
> >> build EFL with gles support I need mesa (again !egl, !gles) in
> >> addition to evil vendor blob for egl and gles. 
> >> We could make this work with MACHINE_FEATURES or something similar,
> >> but that would mean that a very large chunk of userspace now becomes
> >> machine specific. This is how clutter worked in the past and just look
> >> at the fit the canonical/linaro people threw when they started doing
> >> 'embedded' and clutter.
> >> 
> >> To compress the above: you need to build both the mesa and the
> >> evil-egl-binary *recipes* for things to work, so the egl bits should
> >> be a different recipe, not a subpackage of the mesa recipe. This is
> >> all assuming we care abou the binary blobs e.g. TI distributes for 3d
> >> support. If you don't, fine, merge this patchset.
> > 
> > Let me test this a little bit more. The binary blobs shipped by TI would
> > be machine specific
> 
> They aren't machine specific, they contain multiple blobs to support a
> wide range of SoCs. But even if they were machine specific it wouldn't
> work like you want to.
> 
> > and would be marked as such in the package feeds?
> > The mesa pieces would be marked as architecture specific and more
> > generic. In feeds, machine specific has priority so on the machines
> > where there is hardware support, the hardware optimised versions would
> > get installed?
> 
> You're assuming all libraries are subpackaged into their own package
> and renamed identically, they aren't (which is actually a feature in
> the current situation).

They don't have to be renamed identically, the would have to have
RPROVIDES that cover what is needed in some standard namespace.

> > If the above isn't the case, can we make it work like that?
>
> We can't. Even if we could, it would be a giant step backwards for
> people using the output of the build (see below).
>
> The only solution that keeps the good things of the current situation
> is to have the following recipes:
>
> 1) mesa (does not build libgl or libgles)
> 2) mesa-gles (only builds libgl+libgles)
> 3) evil-vendor-blob
>
> And you can specify per SoC something like
> PREFERRED_PROVIDER_virtual/egl = "mesa-gles" or
> PREFERRED_PROVIDER_virtual/egl = "evil-vendor-blob".
>
> That will cause problems if you are building for 2 SoCs in the same
> architecture family that need different gl providers, the shlib code
> might get a bit upset. I don't have a good solution for that, but we
> have that problem right now as well.
>
> From the build side we could make it a bit prettier by making all the
> gl stuff machine specific, but that will be a giant pain in the ass
> for the end user (distro maintainer,  $silicon_vendor customer,
> $silicon_vendor SDK).
>
>  If we end up doing it like that, we'll need buy-in from the silicon
> vendors involved to change the way they distribute their blobs. That
> is doable, I managed to get the TI blobs changed a few times in the
> past, but it's a slow process.
> And everything using GL would suddenly be machine specific, I hope the
> yocto autobuilder can keep up with that.

Everything does not have to become machine specific if the things in
question have known good portable APIs. As I understand it we have GL so
we can swap in the binary blobs in place of the generic ones without
needing everything to be machine specific.

> Executive summary: ARM SoCs with 3d suck, Intel parts with 3d sucks
> less. It's a mess in oe-core.

Ok, we need to do something about this mess, period. Its not going to
get any better and we need to sort it out. I can't "force" changes in
but on the other hand I'm not going to tie the hands of everyone just
because the ARM world in particular is a total mess in this area.

As such, I'm likely going to allow architecture overrides in core mesa
so for example, IA can enable gles and egl for everyone and cleanup
their binary blobs to override them on platforms where it makes sense. I
suspect someone will start sending patches to enable a generic arm core
and I am going to have a *really* hard time refusing the patches due to
any one silicon provider's binary blob issues.

IMO, the evil-vendor-blob recipes need to start generating packages
which are machine or platform specific and those platforms need to
correctly list those feeds as being compatible, providing a set of
standard things which allow replacement of the core generic architecture
providers.

How does that sound?

Cheers,

Richard
Richard Purdie - Aug. 6, 2012, 2:19 p.m.
On Thu, 2012-08-02 at 17:48 +0100, Ross Burton wrote:
> Re-arranged and fixed up some problems.
> 
> The following changes since commit 62d42fe3cfa575cb97b484ccf7b2e9a25cc50770:
> 
>   tiny-init: Setup /dev/ptmx in init (2012-08-01 23:11:18 +0100)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib ross/mesa
> 
> for you to fetch changes up to 5de29e150a720ccb8749362cfe5fb56f234fb385:
> 
>   mesa: enable EGL, with DRM and X11 platforms (2012-08-02 17:43:18 +0100)
> 
> ----------------------------------------------------------------
> Damien Lespiau (2):
>       mesa: Update to 8.0.4 (latest stable version)
>       mesa: Use 'require' instead of 'include'
> 
> Ross Burton (9):
>       mesa: no need to depend on python-native, the class does that
>       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

I've merged the above since I don't think these are the contentious
part.

>       mesa: enable GLES v1 and v2
>       mesa-demos: fix GLES2 build
>       mesa: respect x11 DISTRO_FEATURE
>       mesa: enable EGL, with DRM and X11 platforms

I've left these for now for more discussion.

Cheers,

Richard
Koen Kooi - Aug. 6, 2012, 2:24 p.m.
Op 6 aug. 2012, om 16:04 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:

> On Mon, 2012-08-06 at 15:24 +0200, Koen Kooi wrote:
>> Op 6 aug. 2012, om 14:43 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
>> 
>>> On Fri, 2012-08-03 at 17:46 +0200, Koen Kooi wrote:
>>>> Op 3 aug. 2012, om 15:19 heeft Ross Burton <ross.burton@intel.com> het
>>>> volgende geschreven:
>>>> 
>>>>> On Friday, 3 August 2012 at 11:18, Koen Kooi wrote:
>>>>>> libegl and libgles aren't built nowadays, so the problem is
>>>> avoided. Noone has dared to touch this subject the past 2.5 years:
>>>> http://cgit.openembedded.org/openembedded/commit/recipes/mesa?id=3d96f8cb61225d515b5cb4fe863f0d50c3ced436
>>>>>> 
>>>>>> The best solution[1] is to disable egl/gles in the mesa-recipes and
>>>> add a seperate recipe for them. That way you still get glu and other
>>>> useful mesa bits needed for gnome/efl/xfce/etc, but you can skip the
>>>> sysroot/shlib poisoning if needed.
>>>>> After much digging I see that the Beagle PVR drivers only provide
>>>> gles and egl, which is why you say that the problem was avoided.  Of
>>>> course that's just one specific driver, for example the Cedar Trail
>>>> EMGD driver does build libgl, libgles and libegl.
>>>>> 
>>>>> If the solution is "put the egl/gles bits in another package"
>>>> 
>>>> Recipe, not package. Big difference :)
>>>> 
>>>>> then I'm totally confused as to what the actual problem is.
>>>> Considering there's numerous libegl libraries for the many variants of
>>>> PVR on ARM, I'm struggling to understand exactly what is new here.
>>>>> 
>>>>> Can you explain clearly what the problem is, I'm obviously missing
>>>> something.  Once I understand the problem I can help with a solution.
>>>> 
>>>> You need mesa for the !egl and !gles libs and evil vendor blob for egl
>>>> and gles libs. In the emgd case you can get gl from the evil vendor as
>>>> well. To build e.g. EFL I need mesa for the !egl and !gles bits, to
>>>> build EFL with gles support I need mesa (again !egl, !gles) in
>>>> addition to evil vendor blob for egl and gles. 
>>>> We could make this work with MACHINE_FEATURES or something similar,
>>>> but that would mean that a very large chunk of userspace now becomes
>>>> machine specific. This is how clutter worked in the past and just look
>>>> at the fit the canonical/linaro people threw when they started doing
>>>> 'embedded' and clutter.
>>>> 
>>>> To compress the above: you need to build both the mesa and the
>>>> evil-egl-binary *recipes* for things to work, so the egl bits should
>>>> be a different recipe, not a subpackage of the mesa recipe. This is
>>>> all assuming we care abou the binary blobs e.g. TI distributes for 3d
>>>> support. If you don't, fine, merge this patchset.
>>> 
>>> Let me test this a little bit more. The binary blobs shipped by TI would
>>> be machine specific
>> 
>> They aren't machine specific, they contain multiple blobs to support a
>> wide range of SoCs. But even if they were machine specific it wouldn't
>> work like you want to.
>> 
>>> and would be marked as such in the package feeds?
>>> The mesa pieces would be marked as architecture specific and more
>>> generic. In feeds, machine specific has priority so on the machines
>>> where there is hardware support, the hardware optimised versions would
>>> get installed?
>> 
>> You're assuming all libraries are subpackaged into their own package
>> and renamed identically, they aren't (which is actually a feature in
>> the current situation).
> 
> They don't have to be renamed identically, the would have to have
> RPROVIDES that cover what is needed in some standard namespace.
> 
>>> If the above isn't the case, can we make it work like that?
>> 
>> We can't. Even if we could, it would be a giant step backwards for
>> people using the output of the build (see below).
>> 
>> The only solution that keeps the good things of the current situation
>> is to have the following recipes:
>> 
>> 1) mesa (does not build libgl or libgles)
>> 2) mesa-gles (only builds libgl+libgles)
>> 3) evil-vendor-blob
>> 
>> And you can specify per SoC something like
>> PREFERRED_PROVIDER_virtual/egl = "mesa-gles" or
>> PREFERRED_PROVIDER_virtual/egl = "evil-vendor-blob".
>> 
>> That will cause problems if you are building for 2 SoCs in the same
>> architecture family that need different gl providers, the shlib code
>> might get a bit upset. I don't have a good solution for that, but we
>> have that problem right now as well.
>> 
>> From the build side we could make it a bit prettier by making all the
>> gl stuff machine specific, but that will be a giant pain in the ass
>> for the end user (distro maintainer,  $silicon_vendor customer,
>> $silicon_vendor SDK).
>> 
>> If we end up doing it like that, we'll need buy-in from the silicon
>> vendors involved to change the way they distribute their blobs. That
>> is doable, I managed to get the TI blobs changed a few times in the
>> past, but it's a slow process.
>> And everything using GL would suddenly be machine specific, I hope the
>> yocto autobuilder can keep up with that.
> 
> Everything does not have to become machine specific if the things in
> question have known good portable APIs. As I understand it we have GL so
> we can swap in the binary blobs in place of the generic ones without
> needing everything to be machine specific.
> 
>> Executive summary: ARM SoCs with 3d suck, Intel parts with 3d sucks
>> less. It's a mess in oe-core.
> 
> Ok, we need to do something about this mess, period. Its not going to
> get any better and we need to sort it out. I can't "force" changes in
> but on the other hand I'm not going to tie the hands of everyone just
> because the ARM world in particular is a total mess in this area.

I completely agree with that!

> As such, I'm likely going to allow architecture overrides in core mesa
> so for example, IA can enable gles and egl for everyone and cleanup
> their binary blobs to override them on platforms where it makes sense. I
> suspect someone will start sending patches to enable a generic arm core
> and I am going to have a *really* hard time refusing the patches due to
> any one silicon provider's binary blob issues.

Every GPU on arm has evil blobs, Mali, Adreno, SGX, etc. The RE efforts for Mali and Adreno are making good progress, though.

> IMO, the evil-vendor-blob recipes need to start generating packages
> which are machine or platform specific and those platforms need to
> correctly list those feeds as being compatible, providing a set of
> standard things which allow replacement of the core generic architecture
> providers.

There's no such thing as platform specific packages, yet. 

> How does that sound?

Sounds pretty good.

regards,

Koen
Phil Blundell - Aug. 6, 2012, 7:47 p.m.
On Mon, 2012-08-06 at 15:04 +0100, Richard Purdie wrote:
> Ok, we need to do something about this mess, period. Its not going to
> get any better and we need to sort it out. I can't "force" changes in
> but on the other hand I'm not going to tie the hands of everyone just
> because the ARM world in particular is a total mess in this area.
> 
> As such, I'm likely going to allow architecture overrides in core mesa
> so for example, IA can enable gles and egl for everyone and cleanup
> their binary blobs to override them on platforms where it makes sense. I
> suspect someone will start sending patches to enable a generic arm core
> and I am going to have a *really* hard time refusing the patches due to
> any one silicon provider's binary blob issues.

It's not obvious to me that this is really an architecture-level problem
or that having different Mesa feature sets enabled on different
architectures is a positive thing. 

I'm also not totally convinced that any insurmountable problem actually
exists today with evil vendor blobs.  If they install themselves into
some directory that isn't /usr/lib and arrange for the dynamic linker to
find their libEGL.so (etc) ahead of the Mesa one then it seems like
everything should "just work" with today's technology.  As you observed,
sort of the whole point of the EGL/GL/GLES abstraction is that you have
a common API/ABI to write to irrespective of the implementation.

(Realistically, it seems fairly unlikely that there are very many
situations where using Mesa libGL on top of a vendor libEGL is going to
make much sense.  If you have vendor libEGL but not libGL then the
chances are you have GLES instead and this is probably what you want to
be using.)

So, all in all, I tend to think that we should just apply these patches
and then do whatever else is necessary for the evil-binary-vendor stuff
to be correctly packageable.

p.