Re: [PATCH 3/3] mesa: android: freedreno: Fix build failure due to path change

[Dylan Baker]

Hi John,

This patch and the previous one landed with a fixes tag nominating them for the
staging/19.0 branch, but they don't apply, and to get the to apply requires
pulling in several other android build system patches. If you'd like those in
the 19.0 stable branch can you put together an MR against the staging/19.0
branch, or if you don't care let me know so I can mark them as de-nominated?

Thanks,
Dylan

Quoting John Stultz (2019-05-02 11:03:46)
> The ir3_nir_trig.py file was moved in a previous commit,
> aa0fed10d3574 (freedreno: move ir3 to common location),
> so update the Android.gen.mk file to match.
> 
> Cc: Rob Clark 
> Cc: Emil Velikov 
> Cc: Amit Pundir 
> Cc: Sumit Semwal 
> Cc: Alistair Strachan 
> Cc: Greg Hartman 
> Cc: Tapani Pälli 
> Cc: Jason Ekstrand 
> Signed-off-by: John Stultz 
> ---
>  src/gallium/drivers/freedreno/Android.gen.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/freedreno/Android.gen.mk 
> b/src/gallium/drivers/freedreno/Android.gen.mk
> index 17b6fbe1b7e..d29ba159d5c 100644
> --- a/src/gallium/drivers/freedreno/Android.gen.mk
> +++ b/src/gallium/drivers/freedreno/Android.gen.mk
> @@ -25,7 +25,7 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
>  endif
>  
>  ir3_nir_trig_deps := \
> -   $(LOCAL_PATH)/ir3/ir3_nir_trig.py \
> +   $(MESA_TOP)/src/freedreno/ir3/ir3_nir_trig.py \
> $(MESA_TOP)/src/compiler/nir/nir_algebraic.py
>  
>  intermediates := $(call local-generated-sources-dir)
> -- 
> 2.17.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 0/3] mesa: Initial build fixups for AOSP/master

[Dylan Baker]

Quoting Emil Velikov (2019-05-03 03:41:42)
> On Thu, 2 May 2019 at 23:19, Rob Clark  wrote:
> >
> > On Thu, May 2, 2019 at 2:57 PM Dan Willemsen  wrote:
> > >
> > > On Thu, May 2, 2019 at 1:52 PM John Stultz  wrote:
> > > >
> > > > We need solutions for the xgettext and the python-mako usage.
> > >
> > >  Android doesn't support translations at this level, so you may be
> > > able to just skip xgettext altogether.
> > >
> >
> > from quick look, gettext is just needed for docs build (which I guess
> > android doesn't do) and driconf (not supported on android afaiu,
> > although it could be nice if there was a way to support something like
> > driconf on android, but I guess a different topic[1]).. so yeah,
> > probably not needed
> >
> Pretty much what I've mentioned last time John brought the gettext
> patches - simply disable/drop the thing for Android.
> 
> One of these days we should even look closely at these "wanna-be
> translations, yet 90% not translated" and drop all together?
> 
> -Emil

Eric Engrstrom and I talked about this some time ago, the translations are very
incomplete and out of date at this point. Unless someone wants to step up and
maintain them I'd be in favor of dropping them all together.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

[Dylan Baker]

Quoting Emil Velikov (2019-02-19 08:51:18)
> On Tue, 19 Feb 2019 at 15:36, Dylan Baker  wrote:
> >
> > Quoting Daniel Vetter (2019-02-19 07:20:12)
> > > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom  
> > > wrote:
> > > >
> > > > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov 
> > > > >  wrote:
> > > > > >
> > > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > > > > > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > > > > > > Signed-off-by: Eric Engestrom 
> > > > > > > > > ---
> > > > > > > > >  RELEASING | 27 ---
> > > > > > > > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/RELEASING b/RELEASING
> > > > > > > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > > > > > > > --- a/RELEASING
> > > > > > > > > +++ b/RELEASING
> > > > > > > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving 
> > > > > > > > > the feature in question.
> > > > > > > > >
> > > > > > > > >  Follow these steps to release a new version of libdrm:
> > > > > > > > >
> > > > > > > > > -  1) Bump the version number in configure.ac and 
> > > > > > > > > meson.build. We seem
> > > > > > > > > - to have settled for 2.4.x as the versioning scheme for 
> > > > > > > > > libdrm, so
> > > > > > > > > - just bump the  micro version.
> > > > > > > > > -
> > > > > > > > > -  2) Run autoconf and then re-run ./configure so the build 
> > > > > > > > > system
> > > > > > > > > - picks up the new version number.
> > > > > > > > > -
> > > > > > > > > -  3) Verify that the code passes "make distcheck".  Running 
> > > > > > > > > "make
> > > > > > > > > - distcheck" should result in no warnings or errors and 
> > > > > > > > > end with a
> > > > > > > > > - message of the form:
> > > > > > > > > -
> > > > > > > > > -   =
> > > > > > > > > -   libdrm-X.Y.Z archives ready for distribution:
> > > > > > > > > -   libdrm-X.Y.Z.tar.gz
> > > > > > > > > -   libdrm-X.Y.Z.tar.bz2
> > > > > > > > > -   =
> > > > > > > > > -
> > > > > > > > > - Make sure that the version number reported by distcheck 
> > > > > > > > > and in
> > > > > > > > > - the tarball names matches the number you bumped to in 
> > > > > > > > > configure.ac.
> > > > > > > > > +  1) Bump the version number in meson.build. We seem to have 
> > > > > > > > > settled for
> > > > > > > > > + 2.4.x as the versioning scheme for libdrm, so just bump 
> > > > > > > > > the micro
> > > > > > > > > + version.
> > > > > > > > > +
> > > > > > > > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > > > > > > > + Make sure that the version number of the tarball name in
> > > > > > > > > + builddir/meson-dist/ matches the number you bumped to. 
> > > > > > > > > Move that
> > > > > > > > > + tarball to the libdrm repo root for the release script 
> > > > > > > > > to pick up.
> > > > > > > > >
> > > > > > > > >4) Push the updated master branch with the bumped version 
> &

Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

[Dylan Baker]

Quoting Daniel Vetter (2019-02-19 07:20:12)
> On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom  
> wrote:
> >
> > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov  
> > > wrote:
> > > >
> > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom  
> > > > wrote:
> > > > >
> > > > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > > > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > > > > Signed-off-by: Eric Engestrom 
> > > > > > > ---
> > > > > > >  RELEASING | 27 ---
> > > > > > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > > > > >
> > > > > > > diff --git a/RELEASING b/RELEASING
> > > > > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > > > > > --- a/RELEASING
> > > > > > > +++ b/RELEASING
> > > > > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the 
> > > > > > > feature in question.
> > > > > > >
> > > > > > >  Follow these steps to release a new version of libdrm:
> > > > > > >
> > > > > > > -  1) Bump the version number in configure.ac and meson.build. We 
> > > > > > > seem
> > > > > > > - to have settled for 2.4.x as the versioning scheme for 
> > > > > > > libdrm, so
> > > > > > > - just bump the  micro version.
> > > > > > > -
> > > > > > > -  2) Run autoconf and then re-run ./configure so the build system
> > > > > > > - picks up the new version number.
> > > > > > > -
> > > > > > > -  3) Verify that the code passes "make distcheck".  Running "make
> > > > > > > - distcheck" should result in no warnings or errors and end 
> > > > > > > with a
> > > > > > > - message of the form:
> > > > > > > -
> > > > > > > -   =
> > > > > > > -   libdrm-X.Y.Z archives ready for distribution:
> > > > > > > -   libdrm-X.Y.Z.tar.gz
> > > > > > > -   libdrm-X.Y.Z.tar.bz2
> > > > > > > -   =
> > > > > > > -
> > > > > > > - Make sure that the version number reported by distcheck and 
> > > > > > > in
> > > > > > > - the tarball names matches the number you bumped to in 
> > > > > > > configure.ac.
> > > > > > > +  1) Bump the version number in meson.build. We seem to have 
> > > > > > > settled for
> > > > > > > + 2.4.x as the versioning scheme for libdrm, so just bump the 
> > > > > > > micro
> > > > > > > + version.
> > > > > > > +
> > > > > > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > > > > > + Make sure that the version number of the tarball name in
> > > > > > > + builddir/meson-dist/ matches the number you bumped to. Move 
> > > > > > > that
> > > > > > > + tarball to the libdrm repo root for the release script to 
> > > > > > > pick up.
> > > > > > >
> > > > > > >4) Push the updated master branch with the bumped version 
> > > > > > > number:
> > > > >
> > > > > Just noticed I forgot to decrement item 4 & 5 :]
> > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers,
> > > > > > >   Eric
> > > > > > >
> > > > > >
> > > > > > Acked-by: Dylan Baker 
> > > > > >
> > > > > > But you should probably get someone other than just me to look at 
> > > > > > this.
> > > > >
> > > > > There is no "libdrm maintainer", which makes everyone a libdrm
> > > > > maintainer :]
> > > > >
> > > > > If nobody object, I'll push this in a few we

Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

[Dylan Baker]

Quoting Eric Engestrom (2018-12-19 08:23:40)
> Signed-off-by: Eric Engestrom 
> ---
>  RELEASING | 27 ---
>  1 file changed, 8 insertions(+), 19 deletions(-)
> 
> diff --git a/RELEASING b/RELEASING
> index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> --- a/RELEASING
> +++ b/RELEASING
> @@ -9,25 +9,14 @@ However, this is up to whoever is driving the feature in 
> question.
>  
>  Follow these steps to release a new version of libdrm:
>  
> -  1) Bump the version number in configure.ac and meson.build. We seem
> - to have settled for 2.4.x as the versioning scheme for libdrm, so
> - just bump the  micro version.
> -
> -  2) Run autoconf and then re-run ./configure so the build system
> - picks up the new version number.
> -
> -  3) Verify that the code passes "make distcheck".  Running "make
> - distcheck" should result in no warnings or errors and end with a
> - message of the form:
> -
> -   =
> -   libdrm-X.Y.Z archives ready for distribution:
> -   libdrm-X.Y.Z.tar.gz
> -   libdrm-X.Y.Z.tar.bz2
> -   =
> -
> - Make sure that the version number reported by distcheck and in
> - the tarball names matches the number you bumped to in configure.ac.
> +  1) Bump the version number in meson.build. We seem to have settled for
> + 2.4.x as the versioning scheme for libdrm, so just bump the micro
> + version.
> +
> +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> + Make sure that the version number of the tarball name in
> + builddir/meson-dist/ matches the number you bumped to. Move that
> + tarball to the libdrm repo root for the release script to pick up.
>  
>4) Push the updated master branch with the bumped version number:
>  
> -- 
> Cheers,
>   Eric
> 

Acked-by: Dylan Baker 

But you should probably get someone other than just me to look at this.


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] meson: fix typo in compiler flag

[Dylan Baker]

Reviewed-by: Dylan Baker 

Quoting Eric Engestrom (2018-11-07 08:50:30)
> Signed-off-by: Eric Engestrom 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 49bf2f740fb3627f2948..5ef17fc11fee25f98b3d 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -192,7 +192,7 @@ config.set10('HAVE_OPEN_MEMSTREAM', 
> cc.has_function('open_memstream'))
>  
>  warn_c_args = []
>  foreach a : ['-Wall', '-Wextra', '-Wsign-compare', '-Werror=undef',
> - '-Werror-implicit-function-declaration', '-Wpointer-arith',
> + '-Werror=implicit-function-declaration', '-Wpointer-arith',
>   '-Wwrite-strings', '-Wstrict-prototypes', 
> '-Wmissing-prototypes',
>   '-Wmissing-declarations', '-Wnested-externs', '-Wpacked',
>   '-Wswitch-enum', '-Wmissing-format-attribute',
> -- 
> Cheers,
>   Eric
> 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 2/3] nouveau: add missing drm_public exports

[Dylan Baker]

Quoting Eric Engestrom (2018-09-20 08:58:33)
> Fixes: d7320bfcddc596f23fa2 "nouveau: annotate public functions"
> Cc: Lucas De Marchi 
> Cc: Mark Janes 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108006
> Signed-off-by: Eric Engestrom 
> ---
>  nouveau/nouveau.c | 2 +-
>  nouveau/pushbuf.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
> index 5be0611e0e79451112c6..f18d1426bd419e3c 100644
> --- a/nouveau/nouveau.c
> +++ b/nouveau/nouveau.c
> @@ -856,7 +856,7 @@ nouveau_bo_wait(struct nouveau_bo *bo, uint32_t access,
> return ret;
>  }
>  
> -int
> +drm_public int
>  nouveau_bo_map(struct nouveau_bo *bo, uint32_t access,
>struct nouveau_client *client)
>  {
> diff --git a/nouveau/pushbuf.c b/nouveau/pushbuf.c
> index 856ae7ee169b58bffd78..e5f73f0d74c178939c91 100644
> --- a/nouveau/pushbuf.c
> +++ b/nouveau/pushbuf.c
> @@ -728,7 +728,7 @@ nouveau_pushbuf_data(struct nouveau_pushbuf *push, struct 
> nouveau_bo *bo,
> }
>  }
>  
> -int
> +drm_public int
>  nouveau_pushbuf_refn(struct nouveau_pushbuf *push,
>  struct nouveau_pushbuf_refn *refs, int nr)
>  {
> -- 
> Cheers,
>   Eric
> 

Reviewed-by: Dylan Baker 
Tested-by: Dylan Baker 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/3] intel: add missing drm_public exports

[Dylan Baker]

Quoting Eric Engestrom (2018-09-20 08:58:32)
> Fixes: 36bb0ea47b71d220b31e "intel: annotate public functions"
> Cc: Lucas De Marchi 
> Cc: Mark Janes 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108006
> Signed-off-by: Eric Engestrom 
> ---
>  intel/intel_bufmgr_fake.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/intel/intel_bufmgr_fake.c b/intel/intel_bufmgr_fake.c
> index 57cbc5365b9f0779dd5a..0cec51f5b836d26e57e0 100644
> --- a/intel/intel_bufmgr_fake.c
> +++ b/intel/intel_bufmgr_fake.c
> @@ -241,7 +241,7 @@ FENCE_LTE(unsigned a, unsigned b)
> return 0;
>  }
>  
> -void
> +drm_public void
>  drm_intel_bufmgr_fake_set_fence_callback(drm_intel_bufmgr *bufmgr,
>  unsigned int (*emit) (void *priv),
>  void (*wait) (unsigned int fence,
> @@ -955,7 +955,7 @@ drm_intel_fake_bo_unreference(drm_intel_bo *bo)
>   * Set the buffer as not requiring backing store, and instead get the 
> callback
>   * invoked whenever it would be set dirty.
>   */
> -void
> +drm_public void
>  drm_intel_bo_fake_disable_backing_store(drm_intel_bo *bo,
> void (*invalidate_cb) (drm_intel_bo 
> *bo,
>void *ptr),
> @@ -1409,7 +1409,7 @@ drm_intel_bo_fake_post_submit(drm_intel_bo *bo)
> bo_fake->write_domain = 0;
>  }
>  
> -void
> +drm_public void
>  drm_intel_bufmgr_fake_set_exec_callback(drm_intel_bufmgr *bufmgr,
>  int (*exec) (drm_intel_bo *bo,
>       unsigned int used,
> -- 
> Cheers,
>   Eric
> 

Reviewed-by: Dylan Baker 
Tested-by: Dylan Baker 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2 12/13] meson: make symbols hidden by default

[Dylan Baker]

ndom = executable(
>files('random.c'),
>include_directories : [inc_root, inc_drm],
>link_with : libdrm,
> -  c_args : warn_c_args,
> +  c_args : libdrm_c_args,
>  )
>  
>  drmdevice = executable(
> @@ -77,7 +77,7 @@ drmdevice = executable(
>files('drmdevice.c'),
>include_directories : [inc_root, inc_drm],
>link_with : libdrm,
> -  c_args : warn_c_args,
> +  c_args : libdrm_c_args,
>  )
>  
>  test('random', random, timeout : 240)
> diff --git a/tests/modeprint/meson.build b/tests/modeprint/meson.build
> index 5f0eb24b..898fd181 100644
> --- a/tests/modeprint/meson.build
> +++ b/tests/modeprint/meson.build
> @@ -21,7 +21,7 @@
>  modeprint = executable(
>'modeprint',
>files('modeprint.c'),
> -  c_args : warn_c_args,
> +  c_args : libdrm_c_args,
>include_directories : [inc_root, inc_tests, inc_drm],
>link_with : libdrm,
>dependencies : dep_threads,
> diff --git a/tests/modetest/meson.build b/tests/modetest/meson.build
> index 2a081845..23d84a1d 100644
> --- a/tests/modetest/meson.build
> +++ b/tests/modetest/meson.build
> @@ -21,7 +21,7 @@
>  modetest = executable(
>'modetest',
>files('buffers.c', 'cursor.c', 'modetest.c'),
> -  c_args : [warn_c_args, '-Wno-pointer-arith'],
> +  c_args : [libdrm_c_args, '-Wno-pointer-arith'],
>include_directories : [inc_root, inc_tests, inc_drm],
>dependencies : [dep_threads, dep_cairo],
>link_with : [libdrm, libutil],
> diff --git a/tests/nouveau/meson.build b/tests/nouveau/meson.build
> index f5d73c1e..ca4d44f0 100644
> --- a/tests/nouveau/meson.build
> +++ b/tests/nouveau/meson.build
> @@ -24,7 +24,7 @@ threaded = executable(
>dependencies : [dep_dl, dep_threads],
>include_directories : [inc_root, inc_drm, 
> include_directories('../../nouveau')],
>link_with : [libdrm, libdrm_nouveau],
> -  c_args : warn_c_args,
> +  c_args : libdrm_c_args,
>  )
>  
>  test('threaded', threaded)
> diff --git a/tests/proptest/meson.build b/tests/proptest/meson.build
> index 22d7473e..9c87965a 100644
> --- a/tests/proptest/meson.build
> +++ b/tests/proptest/meson.build
> @@ -21,7 +21,7 @@
>  proptest = executable(
>'proptest',
>files('proptest.c'),
> -  c_args : warn_c_args,
> +  c_args : libdrm_c_args,
>include_directories : [inc_root, inc_tests, inc_drm],
>link_with : [libdrm, libutil],
>install : with_install_tests,
> diff --git a/tests/radeon/meson.build b/tests/radeon/meson.build
> index 9e4f916e..bb345b73 100644
> --- a/tests/radeon/meson.build
> +++ b/tests/radeon/meson.build
> @@ -23,5 +23,5 @@ radeon_ttm = executable(
>files('rbo.c', 'radeon_ttm.c'),
>include_directories : [inc_root, inc_drm],
>link_with : libdrm,
> -  c_args : warn_c_args,
> +  c_args : libdrm_c_args,
>  )
> diff --git a/tests/tegra/meson.build b/tests/tegra/meson.build
> index 9c74ac4a..4f8c54f4 100644
> --- a/tests/tegra/meson.build
> +++ b/tests/tegra/meson.build
> @@ -22,6 +22,6 @@ openclose = executable(
>'openclose',
>files('openclose.c'),
>include_directories : [inc_root, inc_drm, 
> include_directories('../../tegra')],
> -  c_args : warn_c_args,
> +  c_args : libdrm_c_args,
>link_with : [libdrm, libdrm_tegra],
>  )
> diff --git a/tests/vbltest/meson.build b/tests/vbltest/meson.build
> index ae52ab88..6339feba 100644
> --- a/tests/vbltest/meson.build
> +++ b/tests/vbltest/meson.build
> @@ -21,7 +21,7 @@
>  vbltest = executable(
>'vbltest',
>files('vbltest.c'),
> -  c_args : warn_c_args,
> +  c_args : libdrm_c_args,
>include_directories : [inc_root, inc_tests, inc_drm],
>link_with : [libdrm, libutil],
>install : with_install_tests,
> -- 
> 2.17.1
> 

Reviewed-by: Dylan Baker 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2 21/23] meson: build exynos by default

[Dylan Baker]

Quoting Eric Engestrom (2018-04-05 02:48:50)
> On Wednesday, 2018-04-04 14:10:33 -0700, Dylan Baker wrote:
> > For exynos and omap, are they in active use anymore? I'm pretty sure that
> > development of omap (the hardware) stopped, and others have told me exynos 
> > has
> > stopped too. I also don't think there's any open source consumer, since 
> > there is
> > no mesa driver for either of these.
> 
> Happy to drop these enablement patches; I just like to have everything
> possible built by default, but if these are dead I'm fine with leaving
> them disabled by default.
> 

Yeah, I just don't know what the right thing is, it just seems like a bad idea
to enable something by default that never really got anywhere.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2 21/23] meson: build exynos by default

[Dylan Baker]

For exynos and omap, are they in active use anymore? I'm pretty sure that
development of omap (the hardware) stopped, and others have told me exynos has
stopped too. I also don't think there's any open source consumer, since there is
no mesa driver for either of these.

Dylan

Quoting Eric Engestrom (2018-04-04 08:38:16)
> Signed-off-by: Eric Engestrom 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 24688535a329ac530c10..7b26977a9e84290fdd37 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -76,7 +76,7 @@ foreach d : [
>['nouveau', true, true],
>['vmwgfx', false, true],
>['omap', true, true],
> -  ['exynos', false, false],
> +  ['exynos', false, true],
>['freedreno', true, ['arm', 
> 'aarch64'].contains(host_machine.cpu_family())],
>['tegra', true, false],
>['vc4', false, ['arm', 'aarch64'].contains(host_machine.cpu_family())],
> -- 
> Cheers,
>   Eric
> 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2 22/23] meson: build tegra by default

[Dylan Baker]

Please CC Thierry or someone else from nvidia about this,
Also I think this should be ['arm', 'aarch64'], like vc4 and freedreno.

Quoting Eric Engestrom (2018-04-04 08:38:17)
> Signed-off-by: Eric Engestrom 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 7b26977a9e84290fdd37..e816740cb240922bf98a 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -78,7 +78,7 @@ foreach d : [
>['omap', true, true],
>['exynos', false, true],
>['freedreno', true, ['arm', 
> 'aarch64'].contains(host_machine.cpu_family())],
> -  ['tegra', true, false],
> +  ['tegra', true, true],
>['vc4', false, ['arm', 'aarch64'].contains(host_machine.cpu_family())],
>['etnaviv', true, false],
>  ]
> -- 
> Cheers,
>   Eric
> 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2 23/23] meson: build etnaviv by default

[Dylan Baker]

Please CC the etnaviv maintainers on this as well.

I think this should be ['arm', 'aarch64']... like vc4 and fredreno

Quoting Eric Engestrom (2018-04-04 08:38:18)
> Signed-off-by: Eric Engestrom 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index e816740cb240922bf98a..a725f05d342bbec4df18 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -80,7 +80,7 @@ foreach d : [
>['freedreno', true, ['arm', 
> 'aarch64'].contains(host_machine.cpu_family())],
>['tegra', true, true],
>['vc4', false, ['arm', 'aarch64'].contains(host_machine.cpu_family())],
> -  ['etnaviv', true, false],
> +  ['etnaviv', true, true],
>  ]
>driver = d[0]
>require_atomics = d[1]
> -- 
> Cheers,
>   Eric
> 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2 19/23] meson: use simple option handling for etnaviv

[Dylan Baker]

You can ignore my comments on the first couple of patches if you like, I think
the result is much nicer anyway.

1-19 are:
Reviewed-by: Dylan Baker <dy...@pnwbakers.com>

Quoting Eric Engestrom (2018-04-04 08:38:14)
> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
> ---
>  meson.build | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index f3747736f5bed7c01143..f659c02bc82660d038cc 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -80,6 +80,7 @@ foreach d : [
>['freedreno', true, ['arm', 
> 'aarch64'].contains(host_machine.cpu_family())],
>['tegra', true, false],
>['vc4', false, ['arm', 'aarch64'].contains(host_machine.cpu_family())],
> +  ['etnaviv', true, false],
>  ]
>driver = d[0]
>require_atomics = d[1]
> @@ -100,15 +101,6 @@ foreach d : [
>endif
>  endforeach
>  
> -with_etnaviv = false
> -_etnaviv = get_option('etnaviv')
> -if _etnaviv == 'true'
> -  if not with_atomics
> -error('libdrm_etnaviv requires atomics.')
> -  endif
> -  with_etnaviv = true
> -endif
> -
>  with_exynos = get_option('exynos') == 'true'
>  
>  # XXX: Aparently only freebsd and dragonfly bsd actually need this (and
> -- 
> Cheers,
>   Eric
> 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2 02/23] meson: don't enable libdrm_radeon without atomic support

[Dylan Baker]

Quoting Eric Engestrom (2018-04-04 08:37:57)
> In the 'auto' case, the `with_atomic` check was bypassed.
> 
> Signed-off-by: Eric Engestrom 
> ---
>  meson.build | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index e762dcc44bff5deac4d1..72cdd14a3ba834abde4d 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -82,11 +82,13 @@ endif
>  
>  with_radeon = false
>  _radeon = get_option('radeon')
> -if _radeon != 'false'
> -  if _radeon == 'true' and not with_atomics
> -error('libdrm_radeon requires atomics.')
> -  endif
> -  with_radeon = true

What about just change this to `with_radeon = with_atomics`? We've already
verified that if radeon == true that atomics are present.

> +if _radeon == 'auto'
> +  with_radeon = with_atomics
> +else
> +  with_radeon = _radeon == 'true'
> +endif
> +if with_radeon and not with_atomics
> +  error('libdrm_radeon requires atomics.')
>  endif
>  
>  with_amdgpu = false
> -- 
> Cheers,
>   Eric
> 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 4/4] meson: replace `if(compiles) have=true` with `have=compiles`

[Dylan Baker]

Quoting Eric Engestrom (2018-03-16 10:12:27)
> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
> ---
>  meson.build | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 0fe04a1411963c70cf80..74a541e8d835ae27c7f4 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -187,9 +187,8 @@ else
>  endif
>  dep_m = cc.find_library('m', required : false)
>  foreach header : ['sys/sysctl.h', 'sys/select.h', 'alloca.h']
> -  if cc.compiles('#include <@0@>'.format(header), name : '@0@ 
> works'.format(header))
> -config.set10('HAVE_' + header.underscorify().to_upper(), true)
> -  endif
> +  config.set('HAVE_' + header.underscorify().to_upper(),
> +cc.compiles('#include <@0@>'.format(header), name : '@0@ 
> works'.format(header)))
>  endforeach
>  if cc.has_header_symbol('sys/sysmacros.h', 'major')
>config.set10('MAJOR_IN_SYSMACROS', true)
> -- 
> Cheers,
>   Eric
> 

for the series:
Reviewed-by: Dylan Baker <dy...@pnwbakers.com>


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 2/2] meson: detect alloca.h

[Dylan Baker]

Quoting Eric Engestrom (2018-03-13 07:54:12)
> amdgpu makes use of it
> 
> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 3a33928d02a6dce5f075..f7986af9bb5259be5da5 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -186,7 +186,7 @@ else
>dep_rt = []
>  endif
>  dep_m = cc.find_library('m', required : false)
> -foreach header : ['sys/sysctl.h', 'sys/select.h']
> +foreach header : ['sys/sysctl.h', 'sys/select.h', 'alloca.h']
>if cc.compiles('#include <@0@>'.format(header), name : '@0@ 
> works'.format(header))
>  config.set10('HAVE_' + header.underscorify().to_upper(), true)
>endif
> -- 
> Cheers,
>   Eric
> 

for the series:
Reviewed-by: Dylan Baker <dy...@pnwbakers.com>


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] meson: don't use compiler.has_header

[Dylan Baker]

Meson's compiler.has_header is completely useless, it only checks that a
header exists, not whether it's usable. This creates problems if a
header contains a conditional #error declaration, like so:

> #if __x86_64__
> # error "Doesn't work with x86_64!"
> #endif

Compiler.has_header will return true in this case, even when compiling
for x86_64. This is useless.

Instead, we'll do a compile check so that any #error declarations will
be treated as errors, and compilation will work.

Fixes compilation on x32 architecture.

Gentoo Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=649746
meson bug: https://github.com/mesonbuild/meson/issues/2246
CC: Matt Turner <matts...@gmail.com>
Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---
 meson.build | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index df6f2bd2..a0c79e30 100644
--- a/meson.build
+++ b/meson.build
@@ -186,10 +186,10 @@ else
   dep_rt = []
 endif
 dep_m = cc.find_library('m', required : false)
-if cc.has_header('sys/sysctl.h')
+if cc.compiles('#include ', name : 'sys/sysctl.h works')
   config.set10('HAVE_SYS_SYSCTL_H', true)
 endif
-if cc.has_header('sys/select.h')
+if cc.compiles('#include ', name : 'sys/select.h works')
   config.set10('HAVE_SYS_SELECT_H', true)
 endif
 if cc.has_header_symbol('sys/sysmacros.h', 'major')
-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] meson: add configuration summary

[Dylan Baker]

Quoting Eric Engestrom (2018-02-28 07:11:20)
> On Tuesday, 2018-02-27 12:30:48 -0800, Eric Anholt wrote:
> > Dylan Baker <dy...@pnwbakers.com> writes:
> > 
> > > [ Unknown signature status ]
> > > Quoting Eric Engestrom (2018-02-27 03:11:07)
> > >> The message block printed is the same as the one in configure.ac
> > >> 
> > >> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
> > >> ---
> > >>  meson.build | 17 +
> > >>  1 file changed, 17 insertions(+)
> > >> 
> > >> diff --git a/meson.build b/meson.build
> > >> index bd00cdc2cae9f0749180..ab6f881755935968b822 100644
> > >> --- a/meson.build
> > >> +++ b/meson.build
> > >> @@ -373,3 +373,20 @@ if with_man_pages
> > >>  endif
> > >>  subdir('data')
> > >>  subdir('tests')
> > >> +
> > >> +message('')
> > >> +message('@0@ will be compiled with:'.format(meson.project_name()))
> > >> +message('')
> > >> +message('  libkms @0@'.format(with_libkms))
> > >> +message('  Intel API  @0@'.format(with_intel))
> > >> +message('  vmwgfx API @0@'.format(with_vmwgfx))
> > >> +message('  Radeon API @0@'.format(with_radeon))
> > >> +message('  AMDGPU API @0@'.format(with_amdgpu))
> > >> +message('  Nouveau API@0@'.format(with_nouveau))
> > >> +message('  OMAP API   @0@'.format(with_omap))
> > >> +message('  EXYNOS API @0@'.format(with_exynos))
> > >> +message('  Freedreno API  @0@ (kgsl: @1@)'.format(with_freedreno, 
> > >> with_freedreno_kgsl))
> > >> +message('  Tegra API  @0@'.format(with_tegra))
> > >> +message('  VC4 API@0@'.format(with_vc4))
> > >> +message('  Etnaviv API@0@'.format(with_etnaviv))
> > >> +message('')
> > >> -- 
> > >> Cheers,
> > >>   Eric
> > >> 
> > >
> > > This one is certainly simple enough that we can use a single message call 
> > > and a
> > > ''' string :)
> > 
> > But then you end up with 13 @n@ values and when someone wants to put
> > something earlier in the list for some sorting reason, then they need to
> > renumber the rest.  This is much nicer.
> 
> I have to agree here. Dylan, why did you want to avoid multiple
> `message()`? They're not expensive afaict, so I'm not sure what the gain
> would be?
> 
> I also had a try, and multiline messages only get a `Message:` prefix on
> the first line, so combining them would result in unpredictable vertical
> alignments. Unless there's a good reason to merge them, I'll keep them
> separate.

It's mostly my irrational OCD, but I think a long series of calls to print or
message (or whatever your language calls it) are incredibly hard to read.

message('')
message('@0@ will be compiled with:'.format(meson.project_name()))
message('')
message('  libkms @0@'.format(with_libkms))
message('  Intel API  @0@'.format(with_intel))
message('  vmwgfx API @0@'.format(with_vmwgfx))
message('  Radeon API @0@'.format(with_radeon))
message('  AMDGPU API @0@'.format(with_amdgpu))
message('  Nouveau API@0@'.format(with_nouveau))
message('  OMAP API   @0@'.format(with_omap))
message('  EXYNOS API @0@'.format(with_exynos))
message('  Freedreno API  @0@ (kgsl: @1@)'.format(with_freedreno, 
with_freedreno_kgsl))
message('  Tegra API  @0@'.format(with_tegra))
message('  VC4 API@0@'.format(with_vc4))
message('  Etnaviv API@0@'.format(with_etnaviv))
message('')

vs

message('''

  @0@ will be compiled with:

  libkms @1@
  Intel API  @2@
  vmwgfx API @3@
  Radeon API @4@
  AMDGPU API @5@
  Nouveau API@6@
  OMAP API   @7@
  EXYNOS API @8@
  Freedreno API  @9@ (kgsl: @10@)
  Tegra API  @11@
  VC4 API@12@
  Etnaviv API@13@

'''.format(
  meson.project_name(),
  with_libkms,
  with_intel,
  with_vmwgfx,
  ...
)

I do have to admit that Anholt is right that the lack of either an inline
replacement syntax or an unnumbered formatter makes this somewhat unwieldy in
meson. And it's not that big of a deal either way I guess.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] meson: add configuration summary

[Dylan Baker]

Quoting Eric Engestrom (2018-02-27 03:11:07)
> The message block printed is the same as the one in configure.ac
> 
> Signed-off-by: Eric Engestrom 
> ---
>  meson.build | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/meson.build b/meson.build
> index bd00cdc2cae9f0749180..ab6f881755935968b822 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -373,3 +373,20 @@ if with_man_pages
>  endif
>  subdir('data')
>  subdir('tests')
> +
> +message('')
> +message('@0@ will be compiled with:'.format(meson.project_name()))
> +message('')
> +message('  libkms @0@'.format(with_libkms))
> +message('  Intel API  @0@'.format(with_intel))
> +message('  vmwgfx API @0@'.format(with_vmwgfx))
> +message('  Radeon API @0@'.format(with_radeon))
> +message('  AMDGPU API @0@'.format(with_amdgpu))
> +message('  Nouveau API@0@'.format(with_nouveau))
> +message('  OMAP API   @0@'.format(with_omap))
> +message('  EXYNOS API @0@'.format(with_exynos))
> +message('  Freedreno API  @0@ (kgsl: @1@)'.format(with_freedreno, 
> with_freedreno_kgsl))
> +message('  Tegra API  @0@'.format(with_tegra))
> +message('  VC4 API@0@'.format(with_vc4))
> +message('  Etnaviv API@0@'.format(with_etnaviv))
> +message('')
> -- 
> Cheers,
>   Eric
> 

This one is certainly simple enough that we can use a single message call and a
''' string :)


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/7] vulkan: Add new VK_MESA_query_timestamp extension

[Dylan Baker]

Quoting Keith Packard (2018-02-09 20:45:15)
> This extension adds a single function to query the current GPU
> timestamp, just like glGetInteger64v(GL_TIMESTAMP, ). This
> function is needed to complete the implementation of
> GOOGLE_display_timing, which needs to be able to coorelate GPU and CPU
> timestamps.
> 
> Signed-off-by: Keith Packard 
> ---
>  include/vulkan/vulkan.h |  6 ++
>  src/Makefile.am |  1 +
>  src/amd/vulkan/Makefile.am  |  3 +++
>  src/amd/vulkan/meson.build  |  8 
>  src/amd/vulkan/radv_device.c|  8 
>  src/amd/vulkan/radv_extensions.py   |  1 +
>  src/intel/Makefile.vulkan.am|  7 +++
>  src/intel/vulkan/anv_extensions.py  |  1 +
>  src/intel/vulkan/anv_gem.c  | 13 +
>  src/intel/vulkan/anv_private.h  |  1 +
>  src/intel/vulkan/genX_query.c   | 15 +++
>  src/intel/vulkan/meson.build| 12 ++--
>  src/vulkan/meson.build  |  1 +
>  src/vulkan/registry/vk_mesa_query_timestamp.xml | 22 ++
>  14 files changed, 89 insertions(+), 10 deletions(-)
>  create mode 100644 src/vulkan/registry/vk_mesa_query_timestamp.xml
> 
> diff --git a/include/vulkan/vulkan.h b/include/vulkan/vulkan.h
> index d3e2e246cf3..5523eb7586f 100644
> --- a/include/vulkan/vulkan.h
> +++ b/include/vulkan/vulkan.h
> @@ -7025,6 +7025,12 @@ VKAPI_ATTR VkResult VKAPI_CALL 
> vkGetMemoryHostPointerPropertiesEXT(
>  VkMemoryHostPointerPropertiesEXT*   
> pMemoryHostPointerProperties);
>  #endif
>  
> +typedef VkResult (VKAPI_PTR *PFN_vkQueryCurrentTimestampMESA)(VkDevice 
> device, uint64_t *timestamp);
> +
> +VKAPI_ATTR VkResult VKAPI_CALL vkQueryCurrentTimestampMESA(
> +VkDevice_device,
> +uint64_t*timestamp);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 014ffaf3e29..74ff305d7c6 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -68,6 +68,7 @@ endif
>  
>  EXTRA_DIST += vulkan/registry/vk.xml
>  EXTRA_DIST += vulkan/registry/vk_android_native_buffer.xml
> +EXTRA_DIST += vulkan/registry/vk_mesa_query_timestamp.xml
>  
>  if HAVE_AMD_DRIVERS
>  SUBDIRS += amd
> diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
> index 94ece06e99e..0626fa2b3b3 100644
> --- a/src/amd/vulkan/Makefile.am
> +++ b/src/amd/vulkan/Makefile.am
> @@ -129,12 +129,14 @@ libvulkan_radeon_la_SOURCES = $(VULKAN_GEM_FILES)
>  
>  vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml
>  vk_android_native_buffer_xml = 
> $(top_srcdir)/src/vulkan/registry/vk_android_native_buffer.xml
> +vk_mesa_query_timestamp_xml = 
> $(top_srcdir)/src/vulkan/registry/vk_mesa_query_timestamps.xml
>  
>  radv_entrypoints.c: radv_entrypoints_gen.py radv_extensions.py 
> $(vulkan_api_xml)
> $(MKDIR_GEN)
> $(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_entrypoints_gen.py \
> --xml $(vulkan_api_xml) \
> --xml $(vk_android_native_buffer_xml) \
> +   --xml $(vk_mesa_query_timestamp_xml) \
> --outdir $(builddir)
>  radv_entrypoints.h: radv_entrypoints.c
>  
> @@ -144,6 +146,7 @@ radv_extensions.c: radv_extensions.py \
> $(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_extensions.py \
> --xml $(vulkan_api_xml) \
> --xml $(vk_android_native_buffer_xml) \
> +   --xml $(vk_mesa_query_timestamp_xml) \
> --out $@
>  
>  vk_format_table.c: vk_format_table.py \
> diff --git a/src/amd/vulkan/meson.build b/src/amd/vulkan/meson.build
> index 0b92a1763a1..34f578476c0 100644
> --- a/src/amd/vulkan/meson.build
> +++ b/src/amd/vulkan/meson.build
> @@ -20,10 +20,10 @@
>  
>  radv_entrypoints = custom_target(
>'radv_entrypoints.[ch]',
> -  input : ['radv_entrypoints_gen.py', vk_api_xml],
> +  input : ['radv_entrypoints_gen.py', vk_api_xml, 
> vk_android_native_buffer_xml, vk_mesa_query_timestamp_xml],

some of these lines look a little long, 
input : [
'radv_entrypoints_gen.py', vk_api_xml, vk_android_native_buffer_xml,
vk_mesa_query_timestamp_xml,
],

>output : ['radv_entrypoints.h', 'radv_entrypoints.c'],
>command : [
> -prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--outdir',
> +prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@', 
> '--xml', '@INPUT3@', '--outdir',
>  meson.current_build_dir()
>],
>depend_files : files('radv_extensions.py'),
> @@ -31,10 +31,10 @@ radv_entrypoints = custom_target(
>  
>  radv_extensions_c = custom_target(
>'radv_extensions.c',
> -  input : ['radv_extensions.py', vk_api_xml, vk_android_native_buffer_xml],
> +  input : ['radv_extensions.py', vk_api_xml, 

Re: [PATCH 3/7] vulkan: Add EXT_acquire_xlib_display

[Dylan Baker]

Quoting Keith Packard (2018-02-09 20:45:12)
> This extension adds the ability to borrow an X RandR output for
> temporary use directly by a Vulkan application. For DRM, we use the
> Linux resource leasing mechanism.
> 
> Signed-off-by: Keith Packard 
> ---
>  configure.ac   |  25 ++
>  meson.build|  17 ++
>  meson_options.txt  |   7 +
>  src/amd/vulkan/Makefile.am |   7 +
>  src/amd/vulkan/meson.build |   7 +
>  src/amd/vulkan/radv_extensions.py  |  11 +-
>  src/amd/vulkan/radv_wsi_display.c  |  30 +++
>  src/intel/Makefile.vulkan.am   |   7 +
>  src/intel/vulkan/anv_extensions.py |   1 +
>  src/intel/vulkan/anv_extensions_gen.py |  10 +-
>  src/intel/vulkan/anv_wsi_display.c |  30 +++
>  src/intel/vulkan/meson.build   |   7 +
>  src/vulkan/Makefile.am |   5 +
>  src/vulkan/wsi/meson.build |   7 +
>  src/vulkan/wsi/wsi_common_display.c| 472 
> +
>  src/vulkan/wsi/wsi_common_display.h|  17 ++
>  16 files changed, 650 insertions(+), 10 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 46318365603..9effd15e8c5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1547,6 +1547,7 @@ AM_CONDITIONAL(HAVE_APPLEDRI, test "x$enable_dri" = 
> xyes -a "x$dri_platform" = x
>  AM_CONDITIONAL(HAVE_LMSENSORS, test "x$enable_lmsensors" = xyes )
>  AM_CONDITIONAL(HAVE_GALLIUM_EXTRA_HUD, test "x$enable_gallium_extra_hud" = 
> xyes )
>  AM_CONDITIONAL(HAVE_WINDOWSDRI, test "x$enable_dri" = xyes -a 
> "x$dri_platform" = xwindows )
> +AM_CONDITIONAL(HAVE_XLEASE, test "x$have_xlease" = xyes )
>  
>  AC_ARG_ENABLE([shared-glapi],
>  [AS_HELP_STRING([--enable-shared-glapi],
> @@ -1846,6 +1847,11 @@ if test x"$enable_dri3" = xyes; then
>  PKG_CHECK_MODULES([XCB_DRI3], [$dri3_modules])
>  fi
>  
> +if test x"$have_xlease" = xyes; then
> +randr_modules="x11-xcb xcb-randr"
> +PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
> +fi
> +
>  AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
>  AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
>  AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
> @@ -1853,6 +1859,25 @@ AM_CONDITIONAL(HAVE_PLATFORM_DISPLAY, echo 
> "$platforms" | grep -q 'drm')
>  AM_CONDITIONAL(HAVE_PLATFORM_SURFACELESS, echo "$platforms" | grep -q 
> 'surfaceless')
>  AM_CONDITIONAL(HAVE_PLATFORM_ANDROID, echo "$platforms" | grep -q 'android')
>  
> +AC_ARG_ENABLE(xlib-lease,
> +[AS_HELP_STRING([--enable-xlib-lease]
> +[enable VK_acquire_xlib_display using X leases])],
> +[enable_xlib_lease=$enableval], [enable_xlib_lease=auto])
> +case "x$enable_xlib_lease" in
> +xyes)
> +;;
> +xno)
> +;;
> +*)
> +if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 
> 'drm';
> +enable_xlib_lease=yes
> +else
> +enable_xlib_lease=no
> +fi
> +esac
> +
> +AM_CONDITIONAL(HAVE_XLIB_LEASE, test "x$enable_xlib_lease" = xyes)
> +
>  dnl
>  dnl More DRI setup
>  dnl
> diff --git a/meson.build b/meson.build
> index aeb7f5e2917..595b0f66cd7 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -262,6 +262,19 @@ if _platforms != ''
>egl_native_platform = _split[0]
>  endif
>  
> +with_xlib_lease = get_option('xlib-lease')
> +if with_xlib_lease == 'auto'
> +  if with_platform_x11 and with_platform_display
> +with_xlib_lease = true
> +  else
> +with_xlib_lease = false
> +  endif

You could simplify this to
with_xlib_lease = with_platform_x11 and with_platform_display

> +elif with_xlib_lease == 'true'

We should probably error here if we don't have the correct platforms.

> +  with_xlib_lease = true
> +else
> +  with_xlib_lease = false
> +endif
> +
>  with_glx = get_option('glx')
>  if with_glx == 'auto'
>if with_dri
> @@ -1151,6 +1164,7 @@ dep_xcb_present = []
>  dep_xcb_sync = []
>  dep_xcb_xfixes = []
>  dep_xshmfence = []
> +dep_xcb_xrandr = []
>  if with_platform_x11
>if with_glx == 'xlib' or with_glx == 'gallium-xlib'
>  dep_x11 = dependency('x11')
> @@ -1190,6 +1204,9 @@ if with_platform_x11
>if with_egl
>  dep_xcb_xfixes = dependency('xcb-xfixes')
>endif
> +  if with_xlib_lease
> +dep_xcb_xrandr = dependency('xcb-randr', version : '>= 1.12')
> +  endif
>  endif
>  
>  if get_option('gallium-extra-hud')
> diff --git a/meson_options.txt b/meson_options.txt
> index 7fafe2deaac..d38c9aa6149 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -286,3 +286,10 @@ option(
>value : '',
>description : 'Comma delimited list of tools to build. choices : 
> freedreno,glsl,intel,nir,nouveau or all'
>  )
> +option(
> +  'xlib-lease',
> +  type : 'combo',
> +  value : 'auto',
> +  choices : ['auto', 'true', 'false'],
> +  description : 'Enable VK_EXT_acquire_xlib_display.'
> +)
> diff --git 

[PATCH libdrm] meson: include headers in root directory in ext_libdrm

[Dylan Baker]

Which is used in wraps.
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 1342a5b3..4aaeb7e1 100644
--- a/meson.build
+++ b/meson.build
@@ -294,7 +294,7 @@ libdrm = shared_library(
 
 ext_libdrm = declare_dependency(
   link_with : libdrm,
-  include_directories : inc_drm,
+  include_directories : [inc_root, inc_drm],
 )
 
 install_headers('libsync.h', 'xf86drm.h', 'xf86drmMode.h')
-- 
2.16.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH libdrm] meson: fix libdrm_nouveau pkgconfig include directories

[Dylan Baker]

Thanks!

Quoting Eric Engestrom (2018-01-31 03:14:50)
> On Thursday, 2018-01-25 16:14:45 -0800, Dylan Baker wrote:
> > Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
> 
> Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
> 
> > ---
> > 
> > I have tested building every mesa driver against this (with and without 
> > udev!)
> > so I'm pretty sure that this is the last pkgbuild problem.
> > 
> > I'm sure I'll be sad in a day or two...
> > 
> >  nouveau/meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/nouveau/meson.build b/nouveau/meson.build
> > index bfecf84b..f031cd63 100644
> > --- a/nouveau/meson.build
> > +++ b/nouveau/meson.build
> > @@ -45,7 +45,7 @@ install_headers(
> >  pkg.generate(
> >name : 'libdrm_nouveau',
> >libraries : libdrm_nouveau,
> > -  subdirs : ['.', 'nouveau'],
> > +  subdirs : ['.', 'libdrm', 'libdrm/nouveau'],
> >version : meson.project_version(),
> >requires_private : 'libdrm',
> >description : 'Userspace interface to nouveau kernel DRM services',
> > -- 
> > 2.16.0
> > 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] meson: fix libdrm_nouveau pkgconfig include directories

[Dylan Baker]

ping

Quoting Dylan Baker (2018-01-25 16:14:45)
> Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
> ---
> 
> I have tested building every mesa driver against this (with and without udev!)
> so I'm pretty sure that this is the last pkgbuild problem.
> 
> I'm sure I'll be sad in a day or two...
> 
>  nouveau/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/nouveau/meson.build b/nouveau/meson.build
> index bfecf84b..f031cd63 100644
> --- a/nouveau/meson.build
> +++ b/nouveau/meson.build
> @@ -45,7 +45,7 @@ install_headers(
>  pkg.generate(
>name : 'libdrm_nouveau',
>libraries : libdrm_nouveau,
> -  subdirs : ['.', 'nouveau'],
> +  subdirs : ['.', 'libdrm', 'libdrm/nouveau'],
>version : meson.project_version(),
>requires_private : 'libdrm',
>description : 'Userspace interface to nouveau kernel DRM services',
> -- 
> 2.16.0
> 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 7/7] meson: cleanup whitespace

[Dylan Baker]

For the series :)

But please do get someone from nouveau (Emil CC'd Ben, so presumably him) before
pushing the nouveau patch.

Dylan

Quoting Eric Engestrom (2018-01-29 02:54:47)
> On Friday, 2018-01-26 09:45:14 -0800, Dylan Baker wrote:
> > Reviewed-by: Dylan Baker <dy...@pnwbakers.com>
> 
> Thanks :)
> Is that for this patch or the series?
> 
> > 
> > Quoting Eric Engestrom (2018-01-26 03:30:47)
> > > Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
> > > ---
> > >  meson.build | 8 
> > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/meson.build b/meson.build
> > > index 1fd58b071bb90a49996e..1bccdb2c03d7846e7bfb 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -207,8 +207,8 @@ foreach a : ['-Wall', '-Wextra', '-Wsign-compare', 
> > > '-Werror=undef',
> > >   '-Werror-implicit-function-declaration', '-Wpointer-arith',
> > >   '-Wwrite-strings', '-Wstrict-prototypes', 
> > > '-Wmissing-prototypes',
> > >   '-Wmissing-declarations', '-Wnested-externs', '-Wpacked',
> > > - '-Wswitch-enum', '-Wmissing-format-attribute', 
> > > - '-Wstrict-aliasing=2', '-Winit-self', '-Winline', 
> > > '-Wshadow', 
> > > + '-Wswitch-enum', '-Wmissing-format-attribute',
> > > + '-Wstrict-aliasing=2', '-Winit-self', '-Winline', 
> > > '-Wshadow',
> > >   '-Wdeclaration-after-statement', '-Wold-style-definition']
> > >if cc.has_argument(a)
> > >  warn_c_args += a
> > > @@ -216,7 +216,7 @@ foreach a : ['-Wall', '-Wextra', '-Wsign-compare', 
> > > '-Werror=undef',
> > >  endforeach
> > >  # GCC will never error for -Wno-*, so check for -W* then add -Wno-* to 
> > > the list
> > >  # of options
> > > -foreach a : ['unused-parameter', 'attributes', 'long-long', 
> > > +foreach a : ['unused-parameter', 'attributes', 'long-long',
> > >   'missing-field-initializers']
> > >if cc.has_argument('-W@0@'.format(a))
> > >  warn_c_args += '-Wno-@0@'.format(a)
> > > @@ -326,7 +326,7 @@ pkg.generate(
> > >version : meson.project_version(),
> > >description : 'Userspace interface to kernel DRM services',
> > >  )
> > > - 
> > > +
> > >  if with_libkms
> > >subdir('libkms')
> > >  endif
> > > -- 
> > > Cheers,
> > >   Eric
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 7/7] meson: cleanup whitespace

[Dylan Baker]

Reviewed-by: Dylan Baker <dy...@pnwbakers.com>

Quoting Eric Engestrom (2018-01-26 03:30:47)
> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
> ---
>  meson.build | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 1fd58b071bb90a49996e..1bccdb2c03d7846e7bfb 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -207,8 +207,8 @@ foreach a : ['-Wall', '-Wextra', '-Wsign-compare', 
> '-Werror=undef',
>   '-Werror-implicit-function-declaration', '-Wpointer-arith',
>   '-Wwrite-strings', '-Wstrict-prototypes', 
> '-Wmissing-prototypes',
>   '-Wmissing-declarations', '-Wnested-externs', '-Wpacked',
> - '-Wswitch-enum', '-Wmissing-format-attribute', 
> - '-Wstrict-aliasing=2', '-Winit-self', '-Winline', '-Wshadow', 
> + '-Wswitch-enum', '-Wmissing-format-attribute',
> + '-Wstrict-aliasing=2', '-Winit-self', '-Winline', '-Wshadow',
>   '-Wdeclaration-after-statement', '-Wold-style-definition']
>if cc.has_argument(a)
>  warn_c_args += a
> @@ -216,7 +216,7 @@ foreach a : ['-Wall', '-Wextra', '-Wsign-compare', 
> '-Werror=undef',
>  endforeach
>  # GCC will never error for -Wno-*, so check for -W* then add -Wno-* to the 
> list
>  # of options
> -foreach a : ['unused-parameter', 'attributes', 'long-long', 
> +foreach a : ['unused-parameter', 'attributes', 'long-long',
>   'missing-field-initializers']
>if cc.has_argument('-W@0@'.format(a))
>  warn_c_args += '-Wno-@0@'.format(a)
> @@ -326,7 +326,7 @@ pkg.generate(
>version : meson.project_version(),
>description : 'Userspace interface to kernel DRM services',
>  )
> - 
> +
>  if with_libkms
>subdir('libkms')
>  endif
> -- 
> Cheers,
>   Eric
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 01/13] meson: add missing HAVE_RADEON

[Dylan Baker]

For the series:
Reviewed-by: Dylan Baker <dy...@pnwbakers.com>

Quoting Eric Engestrom (2018-01-26 08:45:40)
> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 1bccdb2c03d7846e7bfb..73058e7d772b7744a359 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -255,7 +255,7 @@ foreach t : [[with_intel, 'INTEL'], [with_vmwgfx, 
> 'VMWGFX'],
>   [with_nouveau, 'NOUVEAU'], [with_omap, 'OMAP'],
>   [with_exynos, 'EXYNOS'], [with_freedreno, 'FREEDRENO'],
>   [with_tegra, 'TEGRA'], [with_vc4, 'VC4'],
> - [with_etnaviv, 'ETNAVIV']]
> + [with_etnaviv, 'ETNAVIV'], [with_radeon, 'RADEON']]
>if t[0]
>  config.set10('HAVE_@0@'.format(t[1]), true)
>endif
> -- 
> Cheers,
>   Eric
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/7] meson, configure: add warning when using undefined preprocessor tokens

[Dylan Baker]

Quoting Eric Engestrom (2018-01-26 09:17:43)
> On Friday, 2018-01-26 17:14:06 +, Emil Velikov wrote:
> > On 26 January 2018 at 11:30, Eric Engestrom  
> > wrote:
> > > Signed-off-by: Eric Engestrom 
> > > ---
> > >  configure.ac | 2 +-
> > >  meson.build  | 2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/configure.ac b/configure.ac
> > > index 35378b3384290f8e1e26..3fc4e7794cd974171c0a 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -197,7 +197,7 @@ dnl skipped and all flags rechecked.  So there's no 
> > > need to do anything
> > >  dnl else.  If for any reason you need to force a recheck, just change
> > >  dnl MAYBE_WARN in an ignorable way (like adding whitespace)
> > >
> > > -MAYBE_WARN="-Wall -Wextra \
> > > +MAYBE_WARN="-Wall -Wextra -Wundef \
> > >  -Wsign-compare -Werror-implicit-function-declaration \
> > >  -Wpointer-arith -Wwrite-strings -Wstrict-prototypes \
> > >  -Wmissing-prototypes -Wmissing-declarations -Wnested-externs \
> > > diff --git a/meson.build b/meson.build
> > > index d7a50cf96f905b53d37a..a410627fbf16a2c6d748 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -203,7 +203,7 @@ if cc.has_function('open_memstream')
> > >  endif
> > >
> > >  warn_c_args = []
> > > -foreach a : ['-Wall', '-Wextra', '-Wsign-compare',
> > > +foreach a : ['-Wall', '-Wextra', '-Wsign-compare', '-Wundef',
> > 
> > Unless we have [m]any undef warnings, I'd just make that Werror=undef,
> > across build systems.
> 
> This is what patch 6/7 of this series does.
> I chose to make it a two step thing, first enable the warning, fix the
> code, and then turn the warning into an error.
> 
> I guess I could just skip this patch, and introduce the warning as an
> error in 6/7.
> 
> > 
> > -Emil

I'd either leave 1/7 as-is or drop it completely, so we can bisect across this
series. I don't care which.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 01/13] meson: add missing HAVE_RADEON

[Dylan Baker]

Reviewed-by: Dylan Baker <dy...@pnwbakers.com>

Quoting Eric Engestrom (2018-01-26 08:45:40)
> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 1bccdb2c03d7846e7bfb..73058e7d772b7744a359 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -255,7 +255,7 @@ foreach t : [[with_intel, 'INTEL'], [with_vmwgfx, 
> 'VMWGFX'],
>   [with_nouveau, 'NOUVEAU'], [with_omap, 'OMAP'],
>   [with_exynos, 'EXYNOS'], [with_freedreno, 'FREEDRENO'],
>   [with_tegra, 'TEGRA'], [with_vc4, 'VC4'],
> - [with_etnaviv, 'ETNAVIV']]
> + [with_etnaviv, 'ETNAVIV'], [with_radeon, 'RADEON']]
>if t[0]
>  config.set10('HAVE_@0@'.format(t[1]), true)
>endif
> -- 
> Cheers,
>   Eric
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] meson: fix libdrm_nouveau pkgconfig include directories

[Dylan Baker]

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---

I have tested building every mesa driver against this (with and without udev!)
so I'm pretty sure that this is the last pkgbuild problem.

I'm sure I'll be sad in a day or two...

 nouveau/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nouveau/meson.build b/nouveau/meson.build
index bfecf84b..f031cd63 100644
--- a/nouveau/meson.build
+++ b/nouveau/meson.build
@@ -45,7 +45,7 @@ install_headers(
 pkg.generate(
   name : 'libdrm_nouveau',
   libraries : libdrm_nouveau,
-  subdirs : ['.', 'nouveau'],
+  subdirs : ['.', 'libdrm', 'libdrm/nouveau'],
   version : meson.project_version(),
   requires_private : 'libdrm',
   description : 'Userspace interface to nouveau kernel DRM services',
-- 
2.16.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] meson: set proper pkg-config version for libdrm_freedreno

[Dylan Baker]

Quoting Emil Velikov (2018-01-25 02:30:10)
> Hi Dylan,
> 
> To make it easier to spot these, do set the git subject prefix to PATCH 
> libdrm.
> See autogen.sh for an example.
> 
> On 12 January 2018 at 19:57, Dylan Baker <dy...@pnwbakers.com> wrote:
> > Copy and paste error from exynos.
> >
> > Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
> > ---
> >  freedreno/meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/freedreno/meson.build b/freedreno/meson.build
> > index b4035e1..de6a413 100644
> > --- a/freedreno/meson.build
> > +++ b/freedreno/meson.build
> > @@ -64,7 +64,7 @@ pkg.generate(
> >name : 'libdrm_freedreno',
> >libraries : libdrm_freedreno,
> >subdirs : ['.', 'libdrm', 'freedreno'],
> > -  version : '0.7',
> > +  version : meson.project_version(),
> 
> Ideally we'll have version file(s) to share across builds - both the
> shared libraries' --version-info and the pkg-config ones.
> Otherwise things will be out of sync far too often. But that can
> happen as a follow-up.

I guess thing to do for libdrm is decide how long we need both build systems.
libdrm is a much simpler build than mesa so, I would hope we can iron out any
remaining bugs pretty quickly. We can also cut releases whenever we want with
libdrm (unlike mesa where we use a 3 month cadence). If we think that we need to
have them co-exist for a long time then yes, we absolutely should do something
like add a VERSION file.

> The series is
> Reviewed-by: Emil Velikov <emil.veli...@collabora.com>

Thanks for looking at this!

> 
> -Emil

Odd, I have format.subjectPrefix set in my libdrm git repo. Maybe adding --to
changes that?

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] Small fixes for the meson build

[Dylan Baker]

ping

Quoting Dylan Baker (2018-01-12 11:57:34)
> Here's a few things I've caught as I've started trying to add the meson
> build to our CI system.
> 
> Dylan Baker (2):
>   meson: set proper pkg-config version for libdrm_freedreno
>   meson: set the minimum version correctly
> 
>  freedreno/meson.build | 2 +-
>  meson.build   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> base-commit: fd9bcb73e9c5a01085069b37c2f5e04300a9b4d4
> -- 
> git-series 0.9.1


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] meson: set proper pkg-config version for libdrm_freedreno

[Dylan Baker]

Copy and paste error from exynos.

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---
 freedreno/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/freedreno/meson.build b/freedreno/meson.build
index b4035e1..de6a413 100644
--- a/freedreno/meson.build
+++ b/freedreno/meson.build
@@ -64,7 +64,7 @@ pkg.generate(
   name : 'libdrm_freedreno',
   libraries : libdrm_freedreno,
   subdirs : ['.', 'libdrm', 'freedreno'],
-  version : '0.7',
+  version : meson.project_version(),
   requires_private : 'libdrm',
   description : 'Userspace interface to freedreno kernel DRM services',
 )
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] meson: set the minimum version correctly

[Dylan Baker]

Currently we ask for 0.42, but we actually require 0.43 because we pass
file objects as arguments to tests. If someone needs version 0.42 it
wouldn't be hard, just a lot of replacing files() with strings.

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 0556608..d7a50cf 100644
--- a/meson.build
+++ b/meson.build
@@ -23,7 +23,7 @@ project(
   ['c'],
   version : '2.4.89',
   license : 'MIT',
-  meson_version : '>= 0.42',
+  meson_version : '>= 0.43',
   default_options : ['buildtype=debugoptimized', 'c_std=gnu99'],
 )
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] Small fixes for the meson build

[Dylan Baker]

Here's a few things I've caught as I've started trying to add the meson
build to our CI system.

Dylan Baker (2):
  meson: set proper pkg-config version for libdrm_freedreno
  meson: set the minimum version correctly

 freedreno/meson.build | 2 +-
 meson.build   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

base-commit: fd9bcb73e9c5a01085069b37c2f5e04300a9b4d4
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] Meson build system

[Dylan Baker]

I forgot to CC you on this like you asked,

Dylan

Quoting Dylan Baker (2018-01-05 12:00:57)
> This is a fifth iteration of the meson build system for libdrm. This
> version is significantly cleaned up from the last version and uses a
> style more like the build system in mesa.
> 
> It builds all of the drivers and tests, and the tests can be run via
> `ninja test`.
> 
> It has support for being used as a wrapped dependency with ext_foo
> variables (I have a branch of mesa that will build this code as a wrap,
> which has also been useful for testing). This means it can be used to
> build a mesa that requires a newer libdrm than the system provides
> (which can be especially useful if you can't install packages on that
> system), or to build libdrm support that your distro doesn't ship (like
> arm only drivers on x86), cross compiling, and for testing.
> 
> This has been build tested and mesa has been compiled against it, but
> only minimal functional testing has been done, since I only have i965
> machines, and i965 only uses libdrm lightly.
> 
> Some reviewers of the previous versions have done some additional
> testing.
> 
> Changes since v3:
>   - Fix freedreno kgsl check
>   - Fix kgls -> kgsl typo
>   - standardize meson options to use only `-` and not `_`
>   - fix typo radoen -> radeon
>   - add help messages to options
>   - fix typo in kms-universal-planes binary
>   - build and install modetest (this was missed in the first version for
> some reason)
>   - install amdgpu.ids as 644 instead of 444
> 
> Changes since v4:
>   - Fix minor nits in options descriptions (Igor)
>   - Fix editorconfig settings
>   - Fix amdgpu.ids searh path
>   - Style nits for Eric E.
>   - Remove more tabs
>   - Ensure that 1/0 defines are always defined, instead of only when
> their value is 1
>   - Don't add header files into file lists. (Meson figures out header
> dependencies automatically using graphs that the compiler generates
> during compilation)
>   - Don't assign file lists to variables when possible. In a few cases
> files need to be conditionally added, but if we're not in one of
> those cases just put the lists directly in the exectuable or library
> declaration.
> 
> Dylan Baker (3):
>   Add meson build system
>   autotools: Include meson.build files in tarball
>   README: Add note about meson
> 
>  .editorconfig   |   4 +-
>  Makefile.am |  30 ++-
>  README  |  24 +-
>  amdgpu/.editorconfig|   4 +-
>  amdgpu/meson.build  |  65 +++-
>  data/meson.build|  27 +++-
>  etnaviv/meson.build |  59 ++-
>  exynos/meson.build  |  53 +-
>  freedreno/meson.build   |  76 -
>  intel/meson.build   | 105 +++-
>  libkms/meson.build  |  74 -
>  man/meson.build |  67 +++-
>  meson.build | 364 +-
>  meson_options.txt   | 143 +++-
>  nouveau/meson.build |  58 ++-
>  omap/meson.build|  53 +-
>  radeon/meson.build  |  63 ++-
>  tegra/meson.build   |  52 +-
>  tests/amdgpu/meson.build|  34 +++-
>  tests/etnaviv/meson.build   |  45 +-
>  tests/exynos/meson.build|  54 +-
>  tests/kms/meson.build   |  49 +-
>  tests/kmstest/meson.build   |  30 +++-
>  tests/meson.build   |  86 +-
>  tests/modeprint/meson.build |  29 +++-
>  tests/modetest/meson.build  |  29 +++-
>  tests/nouveau/meson.build   |  30 +++-
>  tests/proptest/meson.build  |  28 +++-
>  tests/radeon/meson.build|  27 +++-
>  tests/tegra/meson.build |  27 +++-
>  tests/util/meson.build  |  28 +++-
>  tests/vbltest/meson.build   |  28 +++-
>  vc4/meson.build |  28 +++-
>  33 files changed, 1869 insertions(+), 4 deletions(-)
>  create mode 100644 amdgpu/meson.build
>  create mode 100644 data/meson.build
>  create mode 100644 etnaviv/meson.build
>  create mode 100644 exynos/meson.build
>  create mode 100644 freedreno/meson.build
>  create mode 100644 intel/meson.build
>  create mode 100644 libkms/meson.build
>  create mode 100644 man/meson.build
>  create mode 100644 meson.build
>  create mode 100644 meson_options.txt
>  create mode 100644 nouveau/meson.build
>  create mode 100644 omap/meson.build
>  create mode 100644 radeon/meson.build
>  create mode 100644 tegra/meson.build
>  create mode 100644 tests/amdgpu/meson.build
>  create mode 100644 tests/etnaviv/meson.build
>  create mode 100644 tests/exynos/meson.build
>  create mode 100644 tests/kms/meson.build
>  create mode 100

[PATCH 2/3] autotools: Include meson.build files in tarball

[Dylan Baker]

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---
 Makefile.am | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 7b86214..66f70ca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -135,7 +135,35 @@ if HAVE_VMWGFX
 klibdrminclude_HEADERS += $(LIBDRM_INCLUDE_VMWGFX_H_FILES)
 endif
 
-EXTRA_DIST = include/drm/README
+EXTRA_DIST = \
+   include/drm/README \
+   amdgpu/meson.build \
+   etnaviv/meson.build \
+   exynos/meson.build \
+   freedreno/meson.build \
+   intel/meson.build \
+   libkms/meson.build \
+   man/meson.build \
+   nouveau/meson.build \
+   omap/meson.build \
+   radeon/meson.build \
+   tests/amdgpu/meson.build \
+   tests/etnaviv/meson.build \
+   tests/exynos/meson.build \
+   tests/kms/meson.build \
+   tests/kmstest/meson.build \
+   tests/modeprint/meson.build \
+   tests/nouveau/meson.build \
+   tests/proptest/meson.build \
+   tests/radeon/meson.build \
+   tests/tegra/meson.build \
+   tests/util/meson.build \
+   tests/vbltest/meson.build \
+   tests/meson.build \
+   vc4/meson.build \
+   data/meson.build \
+   meson.build \
+   meson_options.txt
 
 copy-headers :
cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] README: Add note about meson

[Dylan Baker]

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---
 README | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/README b/README
index 26cab9d..f3df9ac 100644
--- a/README
+++ b/README
@@ -15,9 +15,27 @@ with an older kernel.
 Compiling
 -
 
-libdrm  is  a  standard  autotools  package and  follows  the  normal
-configure, build  and install steps.   The first step is  to configure
-the package, which is done by running the configure shell script:
+libdrm has two build systems, a legacy autotools build system, and a newer
+meson build system. The meson build system is much faster, and offers a
+slightly different interface, but otherwise provides an equivalent feature set.
+
+To use it:
+
+meson builddir/
+
+By default this will install into /usr/local, you can change your prefix
+with --prefix=/usr (or `meson configure builddir/ -Dprefix=/usr` after 
+the initial meson setup).
+
+Then use ninja to build and install:
+
+ninja -C builddir/ install
+
+If you are installing into a system location you will need to run install
+separately, and as root.
+
+
+Alternatively you can invoke autotools configure:
 
./configure
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] Meson build system

[Dylan Baker]

This is a fifth iteration of the meson build system for libdrm. This
version is significantly cleaned up from the last version and uses a
style more like the build system in mesa.

It builds all of the drivers and tests, and the tests can be run via
`ninja test`.

It has support for being used as a wrapped dependency with ext_foo
variables (I have a branch of mesa that will build this code as a wrap,
which has also been useful for testing). This means it can be used to
build a mesa that requires a newer libdrm than the system provides
(which can be especially useful if you can't install packages on that
system), or to build libdrm support that your distro doesn't ship (like
arm only drivers on x86), cross compiling, and for testing.

This has been build tested and mesa has been compiled against it, but
only minimal functional testing has been done, since I only have i965
machines, and i965 only uses libdrm lightly.

Some reviewers of the previous versions have done some additional
testing.

Changes since v3:
  - Fix freedreno kgsl check
  - Fix kgls -> kgsl typo
  - standardize meson options to use only `-` and not `_`
  - fix typo radoen -> radeon
  - add help messages to options
  - fix typo in kms-universal-planes binary
  - build and install modetest (this was missed in the first version for
some reason)
  - install amdgpu.ids as 644 instead of 444

Changes since v4:
  - Fix minor nits in options descriptions (Igor)
  - Fix editorconfig settings
  - Fix amdgpu.ids searh path
  - Style nits for Eric E.
  - Remove more tabs
  - Ensure that 1/0 defines are always defined, instead of only when
their value is 1
  - Don't add header files into file lists. (Meson figures out header
dependencies automatically using graphs that the compiler generates
during compilation)
  - Don't assign file lists to variables when possible. In a few cases
files need to be conditionally added, but if we're not in one of
those cases just put the lists directly in the exectuable or library
declaration.

Dylan Baker (3):
  Add meson build system
  autotools: Include meson.build files in tarball
  README: Add note about meson

 .editorconfig   |   4 +-
 Makefile.am |  30 ++-
 README  |  24 +-
 amdgpu/.editorconfig|   4 +-
 amdgpu/meson.build  |  65 +++-
 data/meson.build|  27 +++-
 etnaviv/meson.build |  59 ++-
 exynos/meson.build  |  53 +-
 freedreno/meson.build   |  76 -
 intel/meson.build   | 105 +++-
 libkms/meson.build  |  74 -
 man/meson.build |  67 +++-
 meson.build | 364 +-
 meson_options.txt   | 143 +++-
 nouveau/meson.build |  58 ++-
 omap/meson.build|  53 +-
 radeon/meson.build  |  63 ++-
 tegra/meson.build   |  52 +-
 tests/amdgpu/meson.build|  34 +++-
 tests/etnaviv/meson.build   |  45 +-
 tests/exynos/meson.build|  54 +-
 tests/kms/meson.build   |  49 +-
 tests/kmstest/meson.build   |  30 +++-
 tests/meson.build   |  86 +-
 tests/modeprint/meson.build |  29 +++-
 tests/modetest/meson.build  |  29 +++-
 tests/nouveau/meson.build   |  30 +++-
 tests/proptest/meson.build  |  28 +++-
 tests/radeon/meson.build|  27 +++-
 tests/tegra/meson.build |  27 +++-
 tests/util/meson.build  |  28 +++-
 tests/vbltest/meson.build   |  28 +++-
 vc4/meson.build |  28 +++-
 33 files changed, 1869 insertions(+), 4 deletions(-)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/modetest/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

base-commit: 831036a6f62005da9fb4a75fe043bd96ce672d27
-- 
git-series 0.9.1
___
dri-devel mailing list
dri

[PATCH 1/3] Add meson build system

[Dylan Baker]

This patch adds a complete meson build system, including tests and
install. It has the necessary hooks to allow it be used as a subproject
for other meson based builds such as mesa.

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
Reviewed-and-tested-by: Igor Gnatenko <i.gnatenko.br...@gmail.com>
---
 .editorconfig   |   4 +-
 amdgpu/.editorconfig|   4 +-
 amdgpu/meson.build  |  65 +++-
 data/meson.build|  27 +++-
 etnaviv/meson.build |  59 ++-
 exynos/meson.build  |  53 +-
 freedreno/meson.build   |  76 -
 intel/meson.build   | 105 +++-
 libkms/meson.build  |  74 -
 man/meson.build |  67 +++-
 meson.build | 364 +-
 meson_options.txt   | 143 +++-
 nouveau/meson.build |  58 ++-
 omap/meson.build|  53 +-
 radeon/meson.build  |  63 ++-
 tegra/meson.build   |  52 +-
 tests/amdgpu/meson.build|  34 +++-
 tests/etnaviv/meson.build   |  45 +-
 tests/exynos/meson.build|  54 +-
 tests/kms/meson.build   |  49 +-
 tests/kmstest/meson.build   |  30 +++-
 tests/meson.build   |  86 +-
 tests/modeprint/meson.build |  29 +++-
 tests/modetest/meson.build  |  29 +++-
 tests/nouveau/meson.build   |  30 +++-
 tests/proptest/meson.build  |  28 +++-
 tests/radeon/meson.build|  27 +++-
 tests/tegra/meson.build |  27 +++-
 tests/util/meson.build  |  28 +++-
 tests/vbltest/meson.build   |  28 +++-
 vc4/meson.build |  28 +++-
 31 files changed, 1819 insertions(+)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/modetest/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

diff --git a/.editorconfig b/.editorconfig
index 893b7be..29b4f39 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -17,3 +17,7 @@ indent_style = tab
 [*.m4]
 indent_style = space
 indent_size = 2
+
+[{meson.build,meson_options.txt}]
+indent_style = space
+indent_size = 2
diff --git a/amdgpu/.editorconfig b/amdgpu/.editorconfig
index 2528d67..426273f 100644
--- a/amdgpu/.editorconfig
+++ b/amdgpu/.editorconfig
@@ -7,3 +7,7 @@ indent_style = tab
 indent_size = 8
 tab_width = 8
 insert_final_newline = true
+
+[meson.build]
+indent_style = space
+indent_size = 2
diff --git a/amdgpu/meson.build b/amdgpu/meson.build
new file mode 100644
index 000..55ab9d1
--- /dev/null
+++ b/amdgpu/meson.build
@@ -0,0 +1,65 @@
+# Copyright © 2017-2018 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+
+datadir_amdgpu = join_paths(get_option('datadir'), 'libdrm', 'amdgpu.ids')
+
+libdrm_amdgpu = shared_library(
+  'drm_amdgpu',
+  [
+files(
+  'amdgpu_asic_id.c', 'amdgpu_bo.c', 'amdgpu_cs.c', 'amdgpu_device.c',
+  'amdgpu_gpu_info.c'

Re: [PATCH 1/3] Add meson build system

[Dylan Baker]

Quoting Eric Engestrom (2018-01-05 05:34:53)
> On Wednesday, 2018-01-03 13:31:28 -0800, Dylan Baker wrote:
> > This patch adds a complete meson build system, including tests and
> > install. It has the necessary hooks to allow it be used as a subproject
> > for other meson based builds such as mesa.
> > 
> > Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
> > ---
> >  .editorconfig   |   4 +-
> >  amdgpu/.editorconfig|   5 +-
> >  amdgpu/meson.build  |  70 +++-
> >  data/meson.build|  27 +++-
> >  etnaviv/meson.build |  64 ++-
> >  exynos/meson.build  |  53 +-
> >  freedreno/meson.build   |  82 -
> >  intel/meson.build   | 111 +++-
> >  libkms/meson.build  |  75 +++-
> >  man/meson.build |  66 ++-
> >  meson.build | 378 +-
> >  meson_options.txt   |  38 -
> >  nouveau/meson.build |  65 ++-
> >  omap/meson.build|  53 +-
> >  radeon/meson.build  |  65 ++-
> >  tegra/meson.build   |  52 +-
> >  tests/amdgpu/meson.build|  40 -
> >  tests/etnaviv/meson.build   |  54 +-
> >  tests/exynos/meson.build|  54 +-
> >  tests/kms/meson.build   |  54 +-
> >  tests/kmstest/meson.build   |  28 +++-
> >  tests/meson.build   |  85 -
> >  tests/modeprint/meson.build |  29 +++-
> >  tests/nouveau/meson.build   |  30 +++-
> >  tests/proptest/meson.build  |  30 +++-
> >  tests/radeon/meson.build|  27 +++-
> >  tests/tegra/meson.build |  27 +++-
> >  tests/util/meson.build  |  37 -
> >  tests/vbltest/meson.build   |  28 +++-
> >  vc4/meson.build |  28 +++-
> >  30 files changed, 1759 insertions(+)
> >  create mode 100644 amdgpu/meson.build
> >  create mode 100644 data/meson.build
> >  create mode 100644 etnaviv/meson.build
> >  create mode 100644 exynos/meson.build
> >  create mode 100644 freedreno/meson.build
> >  create mode 100644 intel/meson.build
> >  create mode 100644 libkms/meson.build
> >  create mode 100644 man/meson.build
> >  create mode 100644 meson.build
> >  create mode 100644 meson_options.txt
> >  create mode 100644 nouveau/meson.build
> >  create mode 100644 omap/meson.build
> >  create mode 100644 radeon/meson.build
> >  create mode 100644 tegra/meson.build
> >  create mode 100644 tests/amdgpu/meson.build
> >  create mode 100644 tests/etnaviv/meson.build
> >  create mode 100644 tests/exynos/meson.build
> >  create mode 100644 tests/kms/meson.build
> >  create mode 100644 tests/kmstest/meson.build
> >  create mode 100644 tests/meson.build
> >  create mode 100644 tests/modeprint/meson.build
> >  create mode 100644 tests/nouveau/meson.build
> >  create mode 100644 tests/proptest/meson.build
> >  create mode 100644 tests/radeon/meson.build
> >  create mode 100644 tests/tegra/meson.build
> >  create mode 100644 tests/util/meson.build
> >  create mode 100644 tests/vbltest/meson.build
> >  create mode 100644 vc4/meson.build
> > 
> > diff --git a/.editorconfig b/.editorconfig
> > index 893b7be..bbad3e6 100644
> > --- a/.editorconfig
> > +++ b/.editorconfig
> > @@ -17,3 +17,7 @@ indent_style = tab
> >  [*.m4]
> >  indent_style = space
> >  indent_size = 2
> > +
> > +[meson.build,meson_options.txt]
> 
> I think this needs to be
>   [{meson.build,meson_options.txt}]

You might be right.

> 
> > +indent_style = space
> > +indent_size = 2
> > diff --git a/amdgpu/.editorconfig b/amdgpu/.editorconfig
> > index 2528d67..0c758d6 100644
> > --- a/amdgpu/.editorconfig
> > +++ b/amdgpu/.editorconfig
> > @@ -7,3 +7,8 @@ indent_style = tab
> >  indent_size = 8
> >  tab_width = 8
> >  insert_final_newline = true
> > +
> > +[meson.build]
> > +indent_style = space
> > +indent_size = 2
> 
> These two should be inherited from the .editorconfig one level above

Nope, because the group right above this is [*], which overrides everything
above it.

> 
> > +insert_final_newline = false
> 
> That's weird; why?

I'll drop it

> 
> > diff --git a/amdgpu/meson.build b/amdgpu/meson.build
> > new file mode 100644
> > index 000..13bf88b
> > --- /dev/null
> > +++ b/amdgpu/meson.build
> > @@ -0,0 +1,70 @@
> > +# Copyright © 2017 Intel Corporation
> > +
> > +# Permission is hereby granted, fre

Re: [PATCH v4 2/3] autotools: Include meson.build files in tarball

[Dylan Baker]

Quoting Eric Engestrom (2018-01-05 06:02:52)
> On Thursday, 2018-01-04 10:28:41 -0800, Dylan Baker wrote:
> > Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
> 
> Do we really want to use autotools' `dist` to package libdrm once meson
> has landed?
> I would've though we would switch to meson and deprecate autotools right
> away.

I think we should maintain the autotools build at least for a couple of
releases. It gives distros a little bit of time to iron out any problems they
have in their automation.

> 
> On that note, have we talked about how long we'll keep autotools around?
> Since libdrm doesn't have a stable release schedule like mesa, it might
> be best to count it in months. 3 months? 6 months? A year?

I think 3 months would probably be fine, but I'm okay with whatever people
decide is appropriate.

> 
> Once that's decided, I think something like this should also be committed
> in this series:
> 
> 8<
> diff --git a/configure.ac b/configure.ac
> index 35378b3384290f8e1e26..38660e13995988f65c2c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -587,3 +587,9 @@ echo "  Tegra API  $TEGRA"
>  echo "  VC4 API$VC4"
>  echo "  Etnaviv API$ETNAVIV"
>  echo ""
> +
> +echo "libdrm's autotools build is DEPRECATED"
> +echo ""
> +echo "Please read the instructions in the README to start using Meson"
> +echo "The autotools build system will be removed on the next release after 
> 2018-XX-XX"
> +echo ""
> >8
> 
> > ---
> >  Makefile.am | 30 +-
> >  1 file changed, 29 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 7b86214..66f70ca 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -135,7 +135,35 @@ if HAVE_VMWGFX
> >  klibdrminclude_HEADERS += $(LIBDRM_INCLUDE_VMWGFX_H_FILES)
> >  endif
> >  
> > -EXTRA_DIST = include/drm/README
> > +EXTRA_DIST = \
> > + include/drm/README \
> > + amdgpu/meson.build \
> > + etnaviv/meson.build \
> > + exynos/meson.build \
> > + freedreno/meson.build \
> > + intel/meson.build \
> > + libkms/meson.build \
> > + man/meson.build \
> > + nouveau/meson.build \
> > + omap/meson.build \
> > + radeon/meson.build \
> > + tests/amdgpu/meson.build \
> > + tests/etnaviv/meson.build \
> > + tests/exynos/meson.build \
> > + tests/kms/meson.build \
> > + tests/kmstest/meson.build \
> > + tests/modeprint/meson.build \
> > + tests/nouveau/meson.build \
> > + tests/proptest/meson.build \
> > + tests/radeon/meson.build \
> > + tests/tegra/meson.build \
> > + tests/util/meson.build \
> > + tests/vbltest/meson.build \
> > + tests/meson.build \
> > + vc4/meson.build \
> > + data/meson.build \
> > + meson.build \
> > + meson_options.txt
> >  
> >  copy-headers :
> >   cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/
> > -- 
> > git-series 0.9.1


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 3/3] README: Add note about meson

[Dylan Baker]

Quoting Eric Engestrom (2018-01-05 05:49:25)
> On Thursday, 2018-01-04 10:28:42 -0800, Dylan Baker wrote:
> > Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
> 
> Couple nitpicks, but:
> Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
> 
> > ---
> >  README | 21 ++---
> >  1 file changed, 18 insertions(+), 3 deletions(-)
> > 
> > diff --git a/README b/README
> > index 26cab9d..58e55bc 100644
> > --- a/README
> > +++ b/README
> > @@ -15,9 +15,24 @@ with an older kernel.
> >  Compiling
> >  -
> >  
> > -libdrm  is  a  standard  autotools  package and  follows  the  normal
> > -configure, build  and install steps.   The first step is  to configure
> > -the package, which is done by running the configure shell script:
> > +libdrm has two build systems, a legacy autotools build system, and a newer
> > +meson build system. The meson build system is much faster, and offers a 
> > +slightly different interface, but otherwise provides much the same 
> 
> s/much/pretty much/ ?

It is a valid construct, but it's a bit archaic, so how about
`s/much the same/equivalent/`?

> 
> > +feature set.
> > +
> > +To use it:
> > +
> > +meson builddir
> 
> I'd suggest `builddir/` to make it more obvious it's a dir, not
> a command.

Makes sense.

> 
> > +
> > +By default this will install into /usr/local, you can change your prefix
> > +with --prefix=/usr (or -Dprefix=/usr to meson configure).
> 
> "(or `meson configure builddir/ -D prefix=/usr` to change it after the
> initial meson setup)."

Done.

> 
> > +
> > +Then use ninja to build and install:
> > +
> > +ninja -C builddir install
> > +
> > +
> > +Alternatively you can invoke autotools configure:
> >  
> >   ./configure
> >  
> > -- 
> > git-series 0.9.1


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH v4 1/3] Add meson build system

[Dylan Baker]

Quoting Igor Gnatenko (2018-01-04 13:43:51)
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Thu, 2018-01-04 at 10:28 -0800, Dylan Baker wrote:
> > This patch adds a complete meson build system, including tests and
> > install. It has the necessary hooks to allow it be used as a subproject
> > for other meson based builds such as mesa.
> 
> Builds fine on all architectures supported by Fedora, boots fine on my laptop
> (x86_64).
> 
> All nitpicks are inline.
> 
> > Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
> 
> Reviewed-and-tested-by: Igor Gnatenko <i.gnatenko.br...@gmail.com>
> 
> > diff --git a/meson_options.txt b/meson_options.txt
> > new file mode 100644
> > index 000..08c2ccd
> > --- /dev/null
> > +++ b/meson_options.txt
> > @@ -0,0 +1,143 @@
> > [...]
> > +option(
> > +  'intel',
> > +  type : 'combo',
> > +  value : 'auto',
> > +  choices : ['true', 'false', 'auto'],
> > +  description : '''Enable support for Intel's KMS API.''',
> 
> Any reason to use `'''` here and there?

to avoid escaping the ' in "Intel's". But I can change it if you prefer.

> 
> > [...]
> > +option(
> > +  'man-pages',
> > +  type : 'combo',
> > +  value : 'auto',
> > +  choices : ['true', 'false', 'auto'],
> > +  description : 'Enable manpage generation and install.',
> 
> "installation".
> 
> > [...]
> > +option(
> > +  'valgrind',
> > +  type : 'combo',
> > +  value : 'auto',
> > +  choices : ['true', 'false', 'auto'],
> > +  description : 'build libdrm with valgrind support',
> 
> "Build". And fullstop at the end of sentence.
> - -- 
> - -Igor Gnatenko
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpOoBcACgkQaVcUvRu8
> X0yF9w//cgaMVkU4xTKegRJY4uuzTE3MQvMmaCoA8ivBaCWPuoX3ozlwsAgZZXaZ
> Vo83tZ0u80cjgoSG4I/JcNp3UhsxtGgqcrqqcof/SGn+YS43eFKPL57dowwQ5qk3
> ccAUgHtAdQXuCJFaQFsTISSEj1X07RA04mIMe7QZFh7AHsKmv+ctaTUO7uJsXJzi
> aX7Z9rntTCnXvzZy7Y56XPCleXfi+yDzQPdDopZAEdLYT8hYUvebo6JGQUpg8iNd
> YuvZsbkrpyV1uMY/2feSJ3Ns4ZTAj3I4F41Xbb7CqZt/BX60EnkZJXog4RSbdlri
> cxMX7gPkrOXxNJbllmdN0nPdBP/atViRY7dDkE4Lv4YrmwL8oT4Mjfyb/TeINT2X
> 6NltSgc8+zSvQSkjWyKHzQ3ZQCQHIAheG+V2Cvnc1NIfX06AV9USRsSRzBMza+gW
> cWNT2g/M0jjmLTVEoLR8MSLXAB9gfsBdRDEnvqEsZCqDh1idW1Ttuk3m/h3+BT8i
> GMyCrswVgKLI7gBbdVFdLDarEIVtTJlYvPkGXxRyOzv1r5dM/MMmeay7P3WD+liE
> CLF9nRVrekQA7Mh4Y61RSyFAntzBokNKL+FrSzSuseNtgYAM3Es0JgY1ndsczvVX
> zUqULC0AEAEwmAIQmDlYFG+ut8nIvmk6aWHHlvLwUHgiDD+MEc4=
> =dAKV
> -END PGP SIGNATURE-
> 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 3/3] README: Add note about meson

[Dylan Baker]

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---
 README | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/README b/README
index 26cab9d..58e55bc 100644
--- a/README
+++ b/README
@@ -15,9 +15,24 @@ with an older kernel.
 Compiling
 -
 
-libdrm  is  a  standard  autotools  package and  follows  the  normal
-configure, build  and install steps.   The first step is  to configure
-the package, which is done by running the configure shell script:
+libdrm has two build systems, a legacy autotools build system, and a newer
+meson build system. The meson build system is much faster, and offers a 
+slightly different interface, but otherwise provides much the same 
+feature set.
+
+To use it:
+
+meson builddir
+
+By default this will install into /usr/local, you can change your prefix
+with --prefix=/usr (or -Dprefix=/usr to meson configure).
+
+Then use ninja to build and install:
+
+ninja -C builddir install
+
+
+Alternatively you can invoke autotools configure:
 
./configure
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 1/3] Add meson build system

[Dylan Baker]

This patch adds a complete meson build system, including tests and
install. It has the necessary hooks to allow it be used as a subproject
for other meson based builds such as mesa.

v4: - fix freedreno kgls check

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---
 .editorconfig   |   4 +-
 amdgpu/.editorconfig|   5 +-
 amdgpu/meson.build  |  70 +++-
 data/meson.build|  27 +++-
 etnaviv/meson.build |  64 ++-
 exynos/meson.build  |  53 +-
 freedreno/meson.build   |  82 -
 intel/meson.build   | 111 +++-
 libkms/meson.build  |  75 +++-
 man/meson.build |  66 ++-
 meson.build | 376 +-
 meson_options.txt   | 143 ++-
 nouveau/meson.build |  65 ++-
 omap/meson.build|  53 +-
 radeon/meson.build  |  65 ++-
 tegra/meson.build   |  52 +-
 tests/amdgpu/meson.build|  40 -
 tests/etnaviv/meson.build   |  54 +-
 tests/exynos/meson.build|  54 +-
 tests/kms/meson.build   |  54 +-
 tests/kmstest/meson.build   |  28 +++-
 tests/meson.build   |  86 -
 tests/modeprint/meson.build |  29 +++-
 tests/modetest/meson.build  |  29 +++-
 tests/nouveau/meson.build   |  30 +++-
 tests/proptest/meson.build  |  30 +++-
 tests/radeon/meson.build|  27 +++-
 tests/tegra/meson.build |  27 +++-
 tests/util/meson.build  |  37 -
 tests/vbltest/meson.build   |  28 +++-
 vc4/meson.build |  28 +++-
 31 files changed, 1892 insertions(+)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/modetest/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

diff --git a/.editorconfig b/.editorconfig
index 893b7be..bbad3e6 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -17,3 +17,7 @@ indent_style = tab
 [*.m4]
 indent_style = space
 indent_size = 2
+
+[meson.build,meson_options.txt]
+indent_style = space
+indent_size = 2
diff --git a/amdgpu/.editorconfig b/amdgpu/.editorconfig
index 2528d67..0c758d6 100644
--- a/amdgpu/.editorconfig
+++ b/amdgpu/.editorconfig
@@ -7,3 +7,8 @@ indent_style = tab
 indent_size = 8
 tab_width = 8
 insert_final_newline = true
+
+[meson.build]
+indent_style = space
+indent_size = 2
+insert_final_newline = false
diff --git a/amdgpu/meson.build b/amdgpu/meson.build
new file mode 100644
index 000..13bf88b
--- /dev/null
+++ b/amdgpu/meson.build
@@ -0,0 +1,70 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+files_amdgpu = files(
+  'amdgpu_asic_id.c',
+  'amdgpu_bo.c',
+  'amdgpu_cs.c',
+  'amdgpu_device.c',
+  'amdgpu_gpu_info.c',
+  'amdgpu_internal.h',
+  'amdgpu_vamgr.c',
+  'amdgpu_vm.c',
+  'util_hash.c',
+  'util_hash.h',
+  'util_hash_table.c',
+  'util_hash_tab

[PATCH v4 0/3] Meson build system

[Dylan Baker]

This is a third iteration of the meson build system for libdrm. This
version is significantly cleaned up from the last version and uses a
style more like the build system in mesa.

It builds all of the drivers and tests, and the tests can be run via
`ninja test`.

It has support for being used as a wrapped dependency wit ext_foo
variables. This means it can be used to build a mesa that requires a
newer libdrm than the system provides (which can be especially useful if
you can't install packages on that system) and for testing.

This has been build tested and mesa has been compiled against it, but
not functional testing has been done.

Changes since v3:
  - Fix freedreno kgsl check
  - Fix kgls -> kgsl typo
  - standardize meson options to use only `-` and not `_`
  - fix typo radoen -> radeon
  - add help messages to options
  - fix typo in kms-universal-planes binary
  - build and install modetest (this was missed in the first version for
some reason)
  - install amdgpu.ids as 644 instead of 444

Dylan Baker (3):
  Add meson build system
  autotools: Include meson.build files in tarball
  README: Add note about meson

 .editorconfig   |   4 +-
 Makefile.am |  30 ++-
 README  |  21 +-
 amdgpu/.editorconfig|   5 +-
 amdgpu/meson.build  |  70 +++-
 data/meson.build|  27 +++-
 etnaviv/meson.build |  64 ++-
 exynos/meson.build  |  53 +-
 freedreno/meson.build   |  82 -
 intel/meson.build   | 111 +++-
 libkms/meson.build  |  75 +++-
 man/meson.build |  66 ++-
 meson.build | 376 +-
 meson_options.txt   | 143 ++-
 nouveau/meson.build |  65 ++-
 omap/meson.build|  53 +-
 radeon/meson.build  |  65 ++-
 tegra/meson.build   |  52 +-
 tests/amdgpu/meson.build|  40 -
 tests/etnaviv/meson.build   |  54 +-
 tests/exynos/meson.build|  54 +-
 tests/kms/meson.build   |  54 +-
 tests/kmstest/meson.build   |  28 +++-
 tests/meson.build   |  86 -
 tests/modeprint/meson.build |  29 +++-
 tests/modetest/meson.build  |  29 +++-
 tests/nouveau/meson.build   |  30 +++-
 tests/proptest/meson.build  |  30 +++-
 tests/radeon/meson.build|  27 +++-
 tests/tegra/meson.build |  27 +++-
 tests/util/meson.build  |  37 -
 tests/vbltest/meson.build   |  28 +++-
 vc4/meson.build |  28 +++-
 33 files changed, 1939 insertions(+), 4 deletions(-)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/modetest/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

base-commit: 831036a6f62005da9fb4a75fe043bd96ce672d27
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 2/3] autotools: Include meson.build files in tarball

[Dylan Baker]

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---
 Makefile.am | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 7b86214..66f70ca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -135,7 +135,35 @@ if HAVE_VMWGFX
 klibdrminclude_HEADERS += $(LIBDRM_INCLUDE_VMWGFX_H_FILES)
 endif
 
-EXTRA_DIST = include/drm/README
+EXTRA_DIST = \
+   include/drm/README \
+   amdgpu/meson.build \
+   etnaviv/meson.build \
+   exynos/meson.build \
+   freedreno/meson.build \
+   intel/meson.build \
+   libkms/meson.build \
+   man/meson.build \
+   nouveau/meson.build \
+   omap/meson.build \
+   radeon/meson.build \
+   tests/amdgpu/meson.build \
+   tests/etnaviv/meson.build \
+   tests/exynos/meson.build \
+   tests/kms/meson.build \
+   tests/kmstest/meson.build \
+   tests/modeprint/meson.build \
+   tests/nouveau/meson.build \
+   tests/proptest/meson.build \
+   tests/radeon/meson.build \
+   tests/tegra/meson.build \
+   tests/util/meson.build \
+   tests/vbltest/meson.build \
+   tests/meson.build \
+   vc4/meson.build \
+   data/meson.build \
+   meson.build \
+   meson_options.txt
 
 copy-headers :
cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH 1/3] Add meson build system

[Dylan Baker]

Quoting Igor Gnatenko (2018-01-03 15:22:36)
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Wed, 2018-01-03 at 13:31 -0800, Dylan Baker wrote:
> > This patch adds a complete meson build system, including tests and
> > install. It has the necessary hooks to allow it be used as a subproject
> > for other meson based builds such as mesa.
> 
> It is failing to build with (autofoo-based builds fine):
> 
> [25/109] cc  -Iamdgpu/drm_amdgpu@sha -Iamdgpu -I../amdgpu -I. -I../
> - -I../include/drm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64
> - -std=gnu99 -DHAVE_CONFIG_H -O2 -g -Wall -Werror=format-security -Wp,-
> D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-
> size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> - -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fPIC 
> -Wall
> - -Wextra -Wsign-compare -Werror-implicit-function-declaration -Wpointer-arith
> - -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
> -Wmissing-declarations 
> - -Wnested-externs -Wpacked -Wswitch-enum -Wmissing-format-attribute -Wstrict-
> aliasing=2 -Winit-self -Winline -Wshadow -Wdeclaration-after-statement -Wold-
> style-definition -Wno-unused-parameter -Wno-attributes -Wno-long-long -Wno-
> missing-field-initializers '-DAMDGPU_ASIC_ID_TABLE="share/amdgpu.ids"' -MMD 
> -MQ
> 'amdgpu/drm_amdgpu@sha/amdgpu_asic_id.c.o' -MF 
> 'amdgpu/drm_amdgpu@sha/amdgpu_as
> ic_id.c.o.d' -o 'amdgpu/drm_amdgpu@sha/amdgpu_asic_id.c.o' -c
> ../amdgpu/amdgpu_asic_id.c
> FAILED: amdgpu/drm_amdgpu@sha/amdgpu_asic_id.c.o 
> cc  -Iamdgpu/drm_amdgpu@sha -Iamdgpu -I../amdgpu -I. -I../ -I../include/drm
> - -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=gnu99
> - -DHAVE_CONFIG_H -O2 -g -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> - -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
> -grecord-gcc-
> switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> - -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fPIC 
> -Wall
> - -Wextra -Wsign-compare -Werror-implicit-function-declaration -Wpointer-arith
> - -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
> -Wmissing-declarations 
> - -Wnested-externs -Wpacked -Wswitch-enum -Wmissing-format-attribute -Wstrict-
> aliasing=2 -Winit-self -Winline -Wshadow -Wdeclaration-after-statement -Wold-
> style-definition -Wno-unused-parameter -Wno-attributes -Wno-long-long -Wno-
> missing-field-initializers '-DAMDGPU_ASIC_ID_TABLE="share/amdgpu.ids"' -MMD 
> -MQ
> 'amdgpu/drm_amdgpu@sha/amdgpu_asic_id.c.o' -MF 
> 'amdgpu/drm_amdgpu@sha/amdgpu_as
> ic_id.c.o.d' -o 'amdgpu/drm_amdgpu@sha/amdgpu_asic_id.c.o' -c
> ../amdgpu/amdgpu_asic_id.c
> ../amdgpu/amdgpu_asic_id.c: In function ‘amdgpu_parse_asic_ids’:
> ../amdgpu/amdgpu_asic_id.c:122:26: error: ‘AMDGPU_ASIC_ID_TABLE_NUM_ENTRIES’
> undeclared (first use in this function); did you mean
> ‘AMDGPU_VCE_CLOCK_TABLE_ENTRIES’?
>   size_t table_max_size = AMDGPU_ASIC_ID_TABLE_NUM_ENTRIES;
>   ^~~~
>   AMDGPU_VCE_CLOCK_TABLE_ENTRIES
> ../amdgpu/amdgpu_asic_id.c:122:26: note: each undeclared identifier is 
> reported
> only once for each function it appears in

You need to rebase on master, that was removed in 
f05a2b4cb1aedb906524718db8ba2e62383f3064.

> 
> [...]
> 
> > diff --git a/freedreno/meson.build b/freedreno/meson.build
> > new file mode 100644
> > index 000..47d6e44
> > --- /dev/null
> > +++ b/freedreno/meson.build
> > @@ -0,0 +1,82 @@
> > [...]
> > +if with_freedreno_kgsl != 'false'
> 
> Booleans should not compare with strings, so do just `if with_freedreno_kgsl`.
> 
> Submitted meson RFE to warn: https://github.com/mesonbuild/meson/issues/2870.
> 
> > +  files_freedreno += files(
> > +'kgsl/kgsl_bo.c',
> > +'kgsl/kgsl_device.c',
> > +'kgsl/kgsl_drm.h',
> > +'kgsl/kgsl_pipe.c',
> > +'kgsl/kgsl_priv.h',
> > +'kgsl/kgsl_ringbuffer.c',
> > +'kgsl/msm_kgsl.h',
> > +  )
> > +endif
> 
> [...]
> 
> > diff --git a/meson_options.txt b/meson_options.txt
> > new file mode 100644
> > index 000..7c2fa4f
> > --- /dev/null
> > +++ b/meson_options.txt
> > @@ -0,0 +1,38 @@
> > [...]
> > +option('libkms',  type : 'combo', value : 'auto',  choices : ['true',
> > 'false', 'auto'])
> > +option('intel',   type : 'combo', value : 'auto',  choices : ['true',
> > 'false', 'auto'])
> > +option('radeon',  type : 'combo', value : 'auto',  choices : ['true',
> > 'false', 'auto'])
> > +optio

Re: [PATCH 1/3] Add meson build system

[Dylan Baker]

Quoting Dylan Baker (2018-01-03 13:31:28)

> diff --git a/freedreno/meson.build b/freedreno/meson.build
> new file mode 100644
> index 000..47d6e44
> --- /dev/null
> +++ b/freedreno/meson.build
> @@ -0,0 +1,82 @@
> +# Copyright © 2017 Intel Corporation
> +
> +# Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> +# of this software and associated documentation files (the "Software"), to 
> deal
> +# in the Software without restriction, including without limitation the 
> rights
> +# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> +# copies of the Software, and to permit persons to whom the Software is
> +# furnished to do so, subject to the following conditions:
> +
> +# The above copyright notice and this permission notice shall be included in
> +# all copies or substantial portions of the Software.
> +
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
> +# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
> THE
> +# SOFTWARE.
> +
> +files_freedreno = files(
> +  'freedreno_device.c',
> +  'freedreno_pipe.c',
> +  'freedreno_priv.h',
> +  'freedreno_ringbuffer.c',
> +  'freedreno_bo.c',
> +  'freedreno_bo_cache.c',
> +  'msm/msm_bo.c',
> +  'msm/msm_device.c',
> +  'msm/msm_drm.h',
> +  'msm/msm_pipe.c',
> +  'msm/msm_priv.h',
> +  'msm/msm_ringbuffer.c',
> +)
> +
> +if with_freedreno_kgsl != 'false'

This should be "if with_freedreno_kgsl" I've fixed that locally.

> +  files_freedreno += files(
> +'kgsl/kgsl_bo.c',
> +'kgsl/kgsl_device.c',
> +'kgsl/kgsl_drm.h',
> +'kgsl/kgsl_pipe.c',
> +'kgsl/kgsl_priv.h',
> +'kgsl/kgsl_ringbuffer.c',
> +'kgsl/msm_kgsl.h',
> +  )
> +endif




signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] autotools: Include meson.build files in tarball

[Dylan Baker]

I have tested that a tarball generated by autotools can be built with meson.

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---
 Makefile.am | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 7b86214..66f70ca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -135,7 +135,35 @@ if HAVE_VMWGFX
 klibdrminclude_HEADERS += $(LIBDRM_INCLUDE_VMWGFX_H_FILES)
 endif
 
-EXTRA_DIST = include/drm/README
+EXTRA_DIST = \
+   include/drm/README \
+   amdgpu/meson.build \
+   etnaviv/meson.build \
+   exynos/meson.build \
+   freedreno/meson.build \
+   intel/meson.build \
+   libkms/meson.build \
+   man/meson.build \
+   nouveau/meson.build \
+   omap/meson.build \
+   radeon/meson.build \
+   tests/amdgpu/meson.build \
+   tests/etnaviv/meson.build \
+   tests/exynos/meson.build \
+   tests/kms/meson.build \
+   tests/kmstest/meson.build \
+   tests/modeprint/meson.build \
+   tests/nouveau/meson.build \
+   tests/proptest/meson.build \
+   tests/radeon/meson.build \
+   tests/tegra/meson.build \
+   tests/util/meson.build \
+   tests/vbltest/meson.build \
+   tests/meson.build \
+   vc4/meson.build \
+   data/meson.build \
+   meson.build \
+   meson_options.txt
 
 copy-headers :
cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] Meson build system

[Dylan Baker]

This is a third iteration of the meson build system for libdrm. This
version is significantly cleaned up from the last version and uses a
style more like the build system in mesa.

It builds all of the drivers and tests, and the tests can be run via
`ninja test`.

It has support for being used as a wrapped dependency wit ext_foo
variables. This means it can be used to build a mesa that requires a
newer libdrm than the system provides (which can be especially useful if
you can't install packages on that system) and for testing.

This has been build tested only.

Dylan Baker (3):
  Add meson build system
  autotools: Include meson.build files in tarball
  README: Add note about meson

 .editorconfig   |   4 +-
 Makefile.am |  30 ++-
 README  |  21 +-
 amdgpu/.editorconfig|   5 +-
 amdgpu/meson.build  |  70 +++-
 data/meson.build|  27 +++-
 etnaviv/meson.build |  64 ++-
 exynos/meson.build  |  53 +-
 freedreno/meson.build   |  82 -
 intel/meson.build   | 111 +++-
 libkms/meson.build  |  75 +++-
 man/meson.build |  66 ++-
 meson.build | 378 +-
 meson_options.txt   |  38 -
 nouveau/meson.build |  65 ++-
 omap/meson.build|  53 +-
 radeon/meson.build  |  65 ++-
 tegra/meson.build   |  52 +-
 tests/amdgpu/meson.build|  40 -
 tests/etnaviv/meson.build   |  54 +-
 tests/exynos/meson.build|  54 +-
 tests/kms/meson.build   |  54 +-
 tests/kmstest/meson.build   |  28 +++-
 tests/meson.build   |  85 -
 tests/modeprint/meson.build |  29 +++-
 tests/nouveau/meson.build   |  30 +++-
 tests/proptest/meson.build  |  30 +++-
 tests/radeon/meson.build|  27 +++-
 tests/tegra/meson.build |  27 +++-
 tests/util/meson.build  |  37 -
 tests/vbltest/meson.build   |  28 +++-
 vc4/meson.build |  28 +++-
 32 files changed, 1806 insertions(+), 4 deletions(-)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

base-commit: 831036a6f62005da9fb4a75fe043bd96ce672d27
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] README: Add note about meson

[Dylan Baker]

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---
 README | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/README b/README
index 26cab9d..58e55bc 100644
--- a/README
+++ b/README
@@ -15,9 +15,24 @@ with an older kernel.
 Compiling
 -
 
-libdrm  is  a  standard  autotools  package and  follows  the  normal
-configure, build  and install steps.   The first step is  to configure
-the package, which is done by running the configure shell script:
+libdrm has two build systems, a legacy autotools build system, and a newer
+meson build system. The meson build system is much faster, and offers a 
+slightly different interface, but otherwise provides much the same 
+feature set.
+
+To use it:
+
+meson builddir
+
+By default this will install into /usr/local, you can change your prefix
+with --prefix=/usr (or -Dprefix=/usr to meson configure).
+
+Then use ninja to build and install:
+
+ninja -C builddir install
+
+
+Alternatively you can invoke autotools configure:
 
./configure
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] Add meson build system

[Dylan Baker]

This patch adds a complete meson build system, including tests and
install. It has the necessary hooks to allow it be used as a subproject
for other meson based builds such as mesa.

Signed-off-by: Dylan Baker <dylan.c.ba...@intel.com>
---
 .editorconfig   |   4 +-
 amdgpu/.editorconfig|   5 +-
 amdgpu/meson.build  |  70 +++-
 data/meson.build|  27 +++-
 etnaviv/meson.build |  64 ++-
 exynos/meson.build  |  53 +-
 freedreno/meson.build   |  82 -
 intel/meson.build   | 111 +++-
 libkms/meson.build  |  75 +++-
 man/meson.build |  66 ++-
 meson.build | 378 +-
 meson_options.txt   |  38 -
 nouveau/meson.build |  65 ++-
 omap/meson.build|  53 +-
 radeon/meson.build  |  65 ++-
 tegra/meson.build   |  52 +-
 tests/amdgpu/meson.build|  40 -
 tests/etnaviv/meson.build   |  54 +-
 tests/exynos/meson.build|  54 +-
 tests/kms/meson.build   |  54 +-
 tests/kmstest/meson.build   |  28 +++-
 tests/meson.build   |  85 -
 tests/modeprint/meson.build |  29 +++-
 tests/nouveau/meson.build   |  30 +++-
 tests/proptest/meson.build  |  30 +++-
 tests/radeon/meson.build|  27 +++-
 tests/tegra/meson.build |  27 +++-
 tests/util/meson.build  |  37 -
 tests/vbltest/meson.build   |  28 +++-
 vc4/meson.build |  28 +++-
 30 files changed, 1759 insertions(+)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

diff --git a/.editorconfig b/.editorconfig
index 893b7be..bbad3e6 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -17,3 +17,7 @@ indent_style = tab
 [*.m4]
 indent_style = space
 indent_size = 2
+
+[meson.build,meson_options.txt]
+indent_style = space
+indent_size = 2
diff --git a/amdgpu/.editorconfig b/amdgpu/.editorconfig
index 2528d67..0c758d6 100644
--- a/amdgpu/.editorconfig
+++ b/amdgpu/.editorconfig
@@ -7,3 +7,8 @@ indent_style = tab
 indent_size = 8
 tab_width = 8
 insert_final_newline = true
+
+[meson.build]
+indent_style = space
+indent_size = 2
+insert_final_newline = false
diff --git a/amdgpu/meson.build b/amdgpu/meson.build
new file mode 100644
index 000..13bf88b
--- /dev/null
+++ b/amdgpu/meson.build
@@ -0,0 +1,70 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+files_amdgpu = files(
+  'amdgpu_asic_id.c',
+  'amdgpu_bo.c',
+  'amdgpu_cs.c',
+  'amdgpu_device.c',
+  'amdgpu_gpu_info.c',
+  'amdgpu_internal.h',
+  'amdgpu_vamgr.c',
+  'amdgpu_vm.c',
+  'util_hash.c',
+  'util_hash.h',
+  'util_hash_table.c',
+  'util_hash_table.h',
+)
+
+libdrm_amdgpu = shared_library(
+  'drm_amdgpu',
+  [files_amdgpu, config_file],
+  c_args : [
+warn_c_args,
+'

[PATCH libdrm 1/1] Add meson build system

[Dylan Baker]

This patch adds a meson build system that is equivalent to the autotools
build system with a few exceptions but is about 4x faster than
autotools.

Signed-off-by: Dylan Baker <dylanx.c.ba...@intel.com>

---
 amdgpu/meson.build  |  73 ++
 data/meson.build|  24 
 etnaviv/meson.build |  59 +
 exynos/meson.build  |  49 +++
 freedreno/meson.build   |  78 +++
 intel/meson.build   |  85 
 libkms/meson.build  |  71 ++
 man/meson.build |  66 +
 meson.build | 317 
 meson_options.txt   |  38 ++
 nouveau/meson.build |  61 +
 omap/meson.build|  49 +++
 radeon/meson.build  |  61 +
 tegra/meson.build   |  48 +++
 tests/amdgpu/meson.build|  42 ++
 tests/etnaviv/meson.build   |  57 
 tests/exynos/meson.build|  54 
 tests/kms/meson.build   |  54 
 tests/kmstest/meson.build   |  30 +
 tests/meson.build   |  85 
 tests/modeprint/meson.build |  29 
 tests/nouveau/meson.build   |  30 +
 tests/proptest/meson.build  |  30 +
 tests/radeon/meson.build|  27 
 tests/tegra/meson.build |  27 
 tests/util/meson.build  |  37 ++
 tests/vbltest/meson.build   |  28 
 vc4/meson.build |  28 
 28 files changed, 1637 insertions(+)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

diff --git a/amdgpu/meson.build b/amdgpu/meson.build
new file mode 100644
index ..72150f9e
--- /dev/null
+++ b/amdgpu/meson.build
@@ -0,0 +1,73 @@
+# Copyright ?? 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+ids = join_paths(meson.source_root(), 'data/amdgpu.ids')
+
+prog_egrep = find_program('egrep')
+amdgpu_asic_count = run_command(
+  prog_egrep, ['-ci', '\'^[0-9a-f]{4},.*[0-9a-f]+,\'', ids]
+).stdout().strip()
+
+datadir = get_option('datadir')
+
+files_amdgpu = files(
+  'amdgpu_asic_id.c',
+  'amdgpu_bo.c',
+  'amdgpu_cs.c',
+  'amdgpu_device.c',
+  'amdgpu_gpu_info.c',
+  'amdgpu_internal.h',
+  'amdgpu_vamgr.c',
+  'util_hash.c',
+  'util_hash.h',
+  'util_hash_table.c',
+  'util_hash_table.h',
+)
+
+libdrm_amdgpu = shared_library(
+  'drm_amdgpu',
+  [files_amdgpu, config_file],
+  c_args : [c_args,
+   '-DAMDGPU_ASIC_ID_TABLE="@0@"'.format(join_paths(datadir, 'libdrm', 
'amdgpu.ids')),
+   '-DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=@0@'.format(amdgpu_asic_count)],
+  include_directories : [inc_root, inc_drm],
+  link_with : libdrm,
+  dependencies : [dep_pthread_stubs],
+  version : '1.0.0',
+  install : true,
+)
+
+install_headers('amdgpu.h', subdir : 'libdrm')
+
+pkg.generate(
+  name : 'libdrm_amdgpu',
+  l

[PATCH libdrm 0/1] Meson, round 2

[Dylan Baker]

This is a second go at a meson build system for libdrm. Since we've started
landing meson for mesa as well as other projects in the ecosystem like wayland,
xorg, and IGT, I thought I would send this out again.

Dylan Baker (1):
  Add meson build system

 amdgpu/meson.build  |  73 ++
 data/meson.build|  24 
 etnaviv/meson.build |  59 +
 exynos/meson.build  |  49 +++
 freedreno/meson.build   |  78 +++
 intel/meson.build   |  85 
 libkms/meson.build  |  71 ++
 man/meson.build |  66 +
 meson.build | 317 
 meson_options.txt   |  38 ++
 nouveau/meson.build |  61 +
 omap/meson.build|  49 +++
 radeon/meson.build  |  61 +
 tegra/meson.build   |  48 +++
 tests/amdgpu/meson.build|  42 ++
 tests/etnaviv/meson.build   |  57 
 tests/exynos/meson.build|  54 
 tests/kms/meson.build   |  54 
 tests/kmstest/meson.build   |  30 +
 tests/meson.build   |  85 
 tests/modeprint/meson.build |  29 
 tests/nouveau/meson.build   |  30 +
 tests/proptest/meson.build  |  30 +
 tests/radeon/meson.build|  27 
 tests/tegra/meson.build |  27 
 tests/util/meson.build  |  37 ++
 tests/vbltest/meson.build   |  28 
 vc4/meson.build |  28 
 28 files changed, 1637 insertions(+)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: X.org EVoC Ideas

[Dylan Baker]

Quoting Rob Clark (2017-04-18 11:27:14)
> On Tue, Apr 18, 2017 at 1:32 PM, Emil Velikov  
> wrote:
> > On 18 April 2017 at 16:48, Rob Clark  wrote:
> >> On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia
> >>  wrote:
> >>> Hi there
> >>>
> >>> I am Raghav Jajodia, an Engineering student from India. While going 
> >>> through
> >>> the X.org foundation, I felt that X.org is a great community for new Open
> >>> Source developers. I am deeply interested in being a part of the 
> >>> community.
> >>> Although, while going through the GSoC and EVoC Ideas, I found that all 
> >>> the
> >>> ideas revolve around C, C++, QT or Compilers.
> >>>
> >>> Working extensively on Web, Moile and Desktop applications, I have gained
> >>> good experience with Python, JS, PHP, Ruby etc. But I do not have any
> >>> experience with C/C++.
> >>>
> >>> So, is not possible for a student to participate in EVoC if he doesn't 
> >>> have
> >>> any experience with Open source softwares built on C/C++. Are there any
> >>> project ideas using languages apart from C/C++ that a student can work on
> >>> for EVoC 17/18?
> >>
> >> Hi, the only requirement regarding programming languages is that
> >> "Applicants know their target programming language."..  there isn't
> >> any requirement otherwise, but I think the fast majority are largely
> >> C/C++.  There are bits of python here and there (piglit, for example..
> >> possibly others that I don't know of).
> >>
> >> From a quick look all of the suggested projects involve C and/or C++.
> >> But that doesn't mean a candidate couldn't suggest a different project
> >> that is not on the list.
> >>
> > FWIW the python in piglit is fine, while the one in Mesa is in a dire shape.

I tend to agree, the only thing that might be useful (and I'd want to see a
proposal of what and how because it would need to be really good) is to overhaul
the piglit summary html tool to be not so awful. Someone with a good grasp of
javascript could probably make that webpage not a 25mb monstrosity that actually
loaded in a reasonable amount of time.

> 
> I didn't realize there where TODO's for py involved in mesa build..
> maybe we should add some to the SummerOfCodeIdeas wiki page[1]
> 
> /me would add convert nir_intrinsic.h + multiple #includes to .py
> generating .c and .h if there was such a topic..  maybe not enough for
> a EVoC/GSoC project on it's own but perhaps if combined w/ some other
> work needed on mesa's python..

The only large one I'm aware is to convert the mapi/glapi generators to use the
khronos XML and not the handwritten XML we use currently. It's been on my radar,
but I haven't really gotten started on it. Presumably sub-requirements of that
would be to use mako instead of `print`s and to be at least close to python3
ready (i.e., a complete rewrite). There's also what has been described as a
fairly simple C project to rip out a level of abstraction in that subsystem.

There's also a bunch of smaller projects to convert the other generators to be
python2/3 hybrid ready (since python 2 is *finally* starting to get the boot in
distros), and to use mako (where applicable). Some of these are really awful,
some of them are pretty good.

Dylan

> 
> BR,
> -R
> 
> [1] https://www.x.org/wiki/SummerOfCodeIdeas/
> 
> 
> > That said, I believe Rob summarised it perfectly:
> > Take a look around and feel free to propose something if the ones
> > listed do not interest you.
> >
> > Regards,
> > Emil
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jose Fonseca (2017-03-24 14:16:13)
> 
> Evaluating is one thing.  Actually migrating is another.
> 
> Brian already said he'd take a look and evaluate.  And I'll help in what 
> I can.  I agree we should all evaluate early.
> 
> 
> But I don't think that the proposal of first migrate scons to meson, 
> then in a second separate step migrate autotools to meson, is viable. 
> Like I said: there's no knowledge overlap.  The two group of people -- 
> the Meson and Windows experts -- will be chasing each other tails.  And 
> all that while, the build will continue to be broken or diverge because 
> master dev will go on.
> 
> 
> Jose

https://github.com/dcbaker/mesa-demos wip/meson

I've blindly ported some of the windows bits but have no way to test them, so
you can either delete the lot and go from scratch or see what's left to fix (the
wgl folder, for example). I have not implemented much of the windows or apple
logic in the root CMakeLists.txt, so hopefully that's useful for your purposes.

That branch also builds on my Archlinux machine, but not on debian due to
difference in the way they package freeglut I just ran out of time today. For
the record, I started at about 12:00, and finished at about 17:00 with a 1 hour
lunch in there. So about 3 hours to get a mostly working build. I'm going to try
to iron out the debian and travis issues either over the weekend or next week.

There is one difference, because ninja is non-recursive some targets would have
the same name and collide, so I've renamed some of the not installed binaries. I
believe that a non-recursive make (such as one generated by cmake) would have
the same problem. meson doesn't seem to have a method to rename the target, but
it's also a bit of an odd corner to build multiple binaries with the same name
that are both not installed and are for people (not automated build steps) to
use.

I also have a not quite working .travis.yml on that branch.

I'm also planning to get a mesa RFC sent out early next week once I get i965 and
llvmpipe building.

If we merge mesa we (Intel) will move to using meson as our primary build system
in CI (the one we run tests against) as soon as it's ready. Building mesa is
quite slow for us considering the power of our build hardware, and meson should
help with that. We'll continue to build autotools much the way we do scons now,
as a secondary "buildtest" only target.

Dylan

> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jose Fonseca (2017-03-24 06:42:18)
> 
> I tend to disagree.  While we can't avoid a transitory period, when we 
> embark on another build system (Meson or something else) I think we 
> should aim at 1) ensure such tool can indeed _completely_ replace at 
> least _one_ existing build system, 2) and aim at migration quickly.
> 
> Otherwise we'll just end up with yet another build system, yet another 
> way builds can fail, with some developers stuck on old build systems 
> because it works, or because the new build system quite doesn't work.
> 
> And this is from (painful) experience.

I tend to agree. Meson is *nice* because it's faster than autotools, but it's
simplicity and the fact that it works for windows and *nix systems is one of the
best features. Having fewer build systems is better than more.

We had hoped that we could do one release with both autotools and meson, to give
some of the fast moving linux distributions (Arch, Fedora, etc) a chance to help
us iron out bugs, especially for pacakgers. I think it is important though to
make a commitment for exactly when we're going to either migrate completely to
meson, or abandon the attempt and revert it.

> So I think we should identify stake holders soon, collect requirements 
> (OSes platforms, etc), make sure the prospective tool meets them, have 
> all stakeholders collaborate on a prototype, them embark on mass migration.
> 
> That is, if this fails, let it fail early.  If it succeeds, may it 
> succeed early.  Anything but a slow death / zombie life.

I have a branch that builds intel's Vulkan driver, I'm actively working to get
intel's i965 dri driver and llvmpipe building and send that out as an RFC to
mesa-dev. That should give us enough of mesa to evaluate the build system I
hope (Since it touches all of the major mesa components [classic, gallium,
neither]).

If other people are interested in collaborating I'd be happy to push the branch
sooner so that others can look at it.

I also think it's worth talking to Eric (who said he's porting X to meson),
Daniel Stone (who has patches to port weston to meson), and Peter Hutterer (who
has patches to port libinput to meson). If they're serious about seeing those
land meson is even more appealing, since it would be a single build system that
all of the *nix graphics stack would be moving towards, and would mean that we
wouldn't have an "Autotools for xorg", "meson for weston and libinput", "cmake 
for
piglit", and " for mesa".

> BTW, how about migrating mesademos to Meson?  It currently has autotools 
> and cmake.  I was hoping that cmake would replace autotools, but I 
> couldn't run fast enough, so I couldn't practice what preached above, 
> hence cmake doing almost but not all what autotools does.
> 
> And is not a crucial project for Linux distros -- few distros package it 
> -- and even if they do, no other package would depend on it.  And is one 
> of those sort of projects that should be easy to port to any build too.

That's definitely doable, but most distros do package it, it's where glxgears,
and more importantly glxinfo live.

I'll have a look at it and see. At the very least we should be able to drop
cmake since I very much doubt anyone but you guys use it.

> Even if we ignore everything else, just replacing autotools + cmake with 
> just one thing would be a net win.
> 
> 
> Jose


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Colin Cross (2017-03-23 17:03:58)
> On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker <dy...@pnwbakers.com> wrote:
> >
> > I'm hoping you can clarify a couple of questions I have about blueprint:
> > 1) android is moving to blueprint from android.mk files?
> 
> Yes, in a phased transition.  We support both for now.
> 
> > 2) is there a publicly available project that uses blueprint I could look 
> > at?
> >The documentation I've been able to find is pretty sparse.
> 
> Blueprint is a framework for writing build systems, and Soong is
> AOSP's Blueprint build system.  See
> https://android.googlesource.com/platform/build/soong/+/master/README.md
> for documentation on Soong.

Thanks, that's very useful information.


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Colin Cross (2017-03-23 15:14:16)
> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann <ghackm...@google.com> wrote:
> > On 03/22/2017 02:48 PM, Rob Clark wrote:
> >>
> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker <dy...@pnwbakers.com> wrote:
> >>>
> >>> Quoting Rob Clark (2017-03-22 10:07:54)
> >>>>
> >>>> I guess an interesting question (from someone who doesn't know meson
> >>>> yet) would be whether meson could slurp in the Makefile.sources type
> >>>> stuff that we have, which are shared so far between
> >>>> android/scons/autotools (and for the most part, kept developers from
> >>>> having to care *too* much about the different build systems)
> >>>
> >>>
> >>> Jason and I have talked about that too. I'd suggested that we could write
> >>> a
> >>> module for meson to read makefile.sources (since we're surely not the
> >>> only
> >>> project that would benefit from such a module), except that android is
> >>> moving to
> >>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
> >>> doesn't
> >>> support using makefile.sources, so it seems somewhat moot in a world of
> >>> blueprint for android, meson for *.
> >>
> >>
> >> I guess even if it is only a temporary thing, something that could
> >> slurp in Makefile.sources seems like it would be useful for a
> >> transition period.
> >>
> >> I'm not totally up to speed on android/blueprint stuff.. but even some
> >> simplified or different "here-are-my-sources" type file that could be
> >> shared across build systems would be useful.  Meson sounds a bit more
> >> extensible so maybe there is some potential to adapt to whatever
> >> android forces on us ;-)
> >
> >
> > +ccross from the Android build team can hopefully provide some input here.
> 
> For cases like this, we generally add a python script that translates
> the build files into something Blueprint understands, and rerun it
> each time we import into the project.
> 
> Alternatively, Blueprint efficiently supports globbing for sources, so
> if all the source files are always listed in Makefile.sources (which
> seems to be true in our copy of libdrm except for intel/test_decode.c)
> then we could use globs and ignore the makefiles, possibly manually
> excluding a few files.

I'm hoping you can clarify a couple of questions I have about blueprint:
1) android is moving to blueprint from android.mk files?
2) is there a publicly available project that uses blueprint I could look at?
   The documentation I've been able to find is pretty sparse.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Emil Velikov (2017-03-23 04:39:50)
> On 22 March 2017 at 20:10, Dylan Baker <dy...@pnwbakers.com> wrote:
> 
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\

Sure, but if it's easier to get right (which I'm asserting it is), then meson
should pay off in the long run by needing less maintenance to remain "bug-free",
since fewer bugs will be introduced.

> Slightly off-topic - 3 days to write the build script for ~10 [nearly]
> identical libraries which do not do anything fancy, seems a lot.
> Which was the most time consuming part ?

Mostly talking with Matt about which patterns from autotools don't make sense to
port to meson. Also in those 3-4 days were a stab at mesa that made me realize
it was too big a of project for the first go, and picking a smaller, simpler
first project made sense. Honestly the about half of that time was spent reading
autotools documentation to figure out what some of the macros did, and then
reading meson bugs to figure out what the meson equivalent is. I have
familiarity with cmake, but this was the first major work with autotools I've
done. At this point working on Mesa the meson is just coming and I spend a lot
more time reading autotools documentation and asking Matt "What does X do, and
does it have side effects?"

> 
> I'm concerned that we would have to enforce the same time penalty onto
> dozens of developers unfamiliar with meson.

Eric (who as done a lot more autotools than me) said it took him 2 days to
become a more comfortable with meson than autotools, having written autotools
for 10 years. Asking Eric, Daniel Stone, or Peter Hutterer, who all have much
more autotools experience than me, would probably be more useful to answer that
question. I can say this, it took me significantly less time to become fluent
with meson than to become passable with cmake.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Eric Anholt (2017-03-22 15:15:46)
> Rob Clark <robdcl...@gmail.com> writes:
> 
> > On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker <dy...@pnwbakers.com> wrote:
> >> Here's a not so complete list: 
> >> https://github.com/mesonbuild/meson/wiki/Users
> >>
> >> Notably gnome is moving to meson (and some parts already use it), weston 
> >> and
> >> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> >> can't say for sure it's going to be around forever, but its been in 
> >> development
> >> since late 2012 and still lands several patches a day, they were 
> >> responsive to
> >> me when I sent a patch (that I still need to respin), and they seem to be
> >> picking up momentum from downstreams.
> >
> >
> > btw, possibly newbie question, but from what I can tell so far in
> > meson docs, there are separate 'meson build && cd build && ninja'
> > steps.. one nice thing about autotools is 'git pull && make' (and it
> > somehow magically figures out whether to re-automake/autoconf).  Not
> > sure if there is a way to do something like that in meson.
> 
> Consider meson build to be ./autogen.sh.  After that point you can git
> pull && make.

Additionally, ninja has the same -C flag as make. So that can be 'meson build &&
ninja -C build' and 'git pull && ninja -C build'


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jani Nikula (2017-03-22 01:24:19)
> On Tue, 21 Mar 2017, Dylan Baker <dy...@pnwbakers.com> wrote:
> > Quoting Jani Nikula (2017-03-21 07:44:55)
> >> How does meson handle build file backwards compatibility between meson
> >> versions? I don't intend to flame, but I've found for some reason many
> >> python projects don't seem to take this very seriously. Either having
> >> conditionals in build files to support building with several meson
> >> versions or always requiring the latest and greatest version would be
> >> rather annoying.
> >
> > Meson makes backwards compatible changes, and the version can be
> > queried using `meson.version()`, which works using meson's version
> > comparison mechanism. I would say this about meson, it's not a 'python
> > project', it's 'a project written in python',
> 
> This is what I meant above, although I clearly didn't write it that way.

I don't think I was exactly clear in what I said either, I would describe SCons
as a "python project", and meson as a "project written in python", since SCons
is python and has some of the warts that make backwards compatibility in python
projects hard (changes that work in the majority case break in some niche use
cases), where meson has a parser/generator written in python.

> > and they've taken great pains to not expose python in meson, and
> > reserve the right to reimplement in a different language if python
> > becomes an issue.
> 
> Right. That helps avoid many of the issues e.g. Sphinx has with the
> configuration files being pure python.

Yes, sphinx's configuration files are awful for just that reason.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jose Fonseca (2017-03-22 10:59:10)
> On 17/03/17 02:28, Brian Paul wrote:
> >
> > [snip]
> >
> > Sure, I'd like to see one build system instead of two.  Meson supports
> > Windows so that's good.  But the big issue is our automated build
> > system.  Replacing SCons with Meson could be a big deal in that
> > context.  It would at least involve pulling Meson into our toolchain and
> > rewriting a bunch of Python code to grok Meson.  I'd have to go off and
> > investigate that to even see if it's a possibility.  Maybe next week.
> 
> 
> I don't have any experience with Meson.  But for the record I don't have 
> much love for SCons.  I long stopped using SCons for anything but Mesa.
> 
> And my have good experience with cmake + ninja/msvc is positive.  So 
> tools with similar architecture sound good overall.
> 
> In fact, knowing what I know now, if I could go back in time, to when I 
> evaluated CMake and SCons, I'd chose CMake.
> 
> 
> BTW, it seems that newer SCons will drop Python 2 support [1], which 
> might force us to rewrite a lot of SConsfiles/scripts any way.  So 
> perhaps that's a good time to evaluate migrating to something else.
> 
> 
> 
> That said, moving to another build system is always a herculian task. 
> Thought the benefit of having a single build system is appealing and 
> might save time down the line.
>
>
>
> But there are many questions I have about Meson:  how confident are we 
> on Meson?  Are big projects using it?  How sure are we that it won't 
> become abandonware in a few years time?  How does it compare with other 
> newer gen build systems?
> 

Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users

Notably gnome is moving to meson (and some parts already use it), weston and
libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
can't say for sure it's going to be around forever, but its been in development
since late 2012 and still lands several patches a day, they were responsive to
me when I sent a patch (that I still need to respin), and they seem to be
picking up momentum from downstreams.

As to how it compares to other build systems, it's fairly different than cmake
and scons, it's much less scripting and much more declarative, you can look at
the libdrm patch or the meson in libepoxy (which is more mature) to see the
syntax. It doesn't expose python or a full scripting language, though it does
have some fairly simple logic like if/elif/else and foreach, and they support
modules that add functionality, but need to be merged upstream, this is how
pkgconfig writing is implemented, for example. One of the things that it does
better than autotools and (IMHO) cmake, is dependency management, in most cases
it requires no special handling, the only case it does in mesa (so far) is for
local python module dependencies in generators. I think that these are actually
strengths of meson, it's simplicity makes it easy to understand and use.

For support, it's written in pure python (using only the stdlib with no
external deps), and requires python 3.4+. It has backends for ninja on Linux,
ninja and visual studio on Windows, and xcode on macOS; Clang, GCC, and MSVC
are considered first class compilers, some others might work, but are
unsupported.

I have a partial port of piglit to meson that I put together to see what
porting from cmake to meson was like (with no plans to send to the list), I can
push that somewhere for you to look at if you want to see the difference.

> 
> We also have special requirements: one is cross-build from Linux to 
> MinGW, which on Mesa case requires building portions of the tree twice 
> -- once for host -- another for cross-mingw.

Cross compiling for mingw is supported, and it provides a way to differentiate
the build, host, and target machines [1], I've cross compiled for
aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag for
this, but the meson approach is to write an ini file once, and use it again and
again), and the first example of cross compiling is using mingw from linux [2]. 

[1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
[2]https://github.com/mesonbuild/meson/wiki/Cross-compilation

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.

One of the things that's prompted this on our side (I've talked this over with
other people at Intel before starting), was that clearly we *don't* know
autotools well enough to get it right. Emil almost always finds cases were we've
done things *almost*, but not quite right.

For my part, it took me about 3 or 4 days of reading through the docs and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same logic. 

> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that.  The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.

Sure, but we're also not the only ones investigating meson. Gnome is using it
already, libepoxy is using it, gstreamer is using it. There are patches for
weston (written by Daniel Stone) and libinput (written by Peter Hutterer), there
are some other projects in the graphics sphere that people are working on. So
even if we as a community decide that meson isn't for us, it's not going away.

Quoting Rob Clark (2017-03-22 10:07:54)
> I guess an interesting question (from someone who doesn't know meson
> yet) would be whether meson could slurp in the Makefile.sources type
> stuff that we have, which are shared so far between
> android/scons/autotools (and for the most part, kept developers from
> having to care *too* much about the different build systems)

Jason and I have talked about that too. I'd suggested that we could write a
module for meson to read makefile.sources (since we're surely not the only
project that would benefit from such a module), except that android is moving to
blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
support using makefile.sources, so it seems somewhat moot in a world of
blueprint for android, meson for *.

I don't think that meson should try to generate blueprint files, since blueprint
is itself a metabuild system that generates ninja files, and is self
boot-strapping Go code. I don't know if the community is going to want blueprint
to live in repo either, since one actually writes Go code for the build system.
(I'm not objecting prematurely, I'm just pointing out that the design is
significantly different the Android.mk, and the community will probably want to
re-evaluate)

If android doesn't mandate a migration to blueprint, or blueprint does handle
makefile.sources (I don't think it does), I'd be happy to propose a module for
meson that could read makefile.sources, and write said module, and get said
module upstream.

[1] https://godoc.org/github.com/google/blueprint
> 
> If so, that makes it easier to coexist with existing build systems.  I
> don't think it would be a good idea to remove the autotools build
> anytime soon.. that should be the last one removed, after meson has
> replaced scons (and hopefully android?)

I would imagine that if we did merge meson, we would make at the very least one
release with meson and autotools (scons is VMWare's thing, they can migrate at
their leisure), if not two, to give us a chance to flush out the bugs and to
give various distros who don't have meson ready yet a chance. It'll also give
the fast moving and aggressive distros like Arch and Fedora and chance to
migrate and report bugs.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Hey Kai,

Quoting Kai Wasserbäch (2017-03-21 11:36:31)
> I hope the rest of the Mesa project would follow such a rule. Because if 
> there's
> something I absolutely hate about all those "new" build systems, then it's 
> their
> tendency to just download stuff and build/include that. This seems to have 
> risen
> with Node and now spread into Rust and other parts of the FLOSS eco-system.

I think we have enough distro people in the project that they would revert a use
of wrap on linux :)

> CMake or SCons would do the same AFAICS. Plus CMake seems to be used in the
> Android eco-system already
> (), which might mean it
> could be easier for the Android downstreams of Mesa? Not sure on that though.

I don't think this really helps our android problem, since mesa is part of the
core anrdoid tree for devices using mesa, it needs android.mk files (I think
someone mentioned that they're migrating to blueprint?), and that doesn't
support cmake, autotools, scons, or meson. If meson is useful I'm willing to
propose and write an android.mk or blueprint backend for meson if the meson
community wants it.

> > 2) meson much simpler than autotools, scons, or (especially) cmake
> 
> OTOH CMake gives you CTest/CDash
> (), CPack
> (), dependency
> visualisation
> () and
> many other things for (basically) free. Maybe that warrants some complexity?

Meson generates a 'ninja test' target, and has a mesontest which I assume is
similar to CTest, but I've never used mesontest or CTest tbh, so I can't comment
too much about either.

> > 3) recursive meson files, flat ninja file.
> 
> IIRC you would also get the same with CMake if you target Ninja.

That's fair.

> > 
> > I've never had to use gitattributes for anything, are you thinking for 
> > setting
> > export-ignore and export-subst?
> 
> Yep. AFAICT we have several files which aren't distributed if you do "make
> dist". Those would need to be excluded from a tarball built with git archive 
> as
> well. AFAIK that's done through having .gitattributes files in the tree.

I'll have a look at what ends up in the dist-tarball and what ends up in a
git-archive tarbal too. Thanks for pointing that out.

> Anyway, I don't want to bikeshed here, so I'll be silent as long as any 
> possible
> future build system doesn't download stuff behind my back.
> 
> Thanks for your reply!
> 
> Cheers,
> Kai

Thanks for your reply Kai, I hadn't even noticed wrap, so at the very least it's
good to see that's there, and I'll be sure to add a note to the README that we
don't use wrap on Linux, BSD and similar.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Hi Kai,

Quoting Kai Wasserbäch (2017-03-21 09:50:52)
> Hey Dylan,
> I've just a few points, since I'm not too enthused by the prospect of having 
> to
> deal with yet another build system with yet another slightly different syntax.
> But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
> involved with Mesa and their opinion is what matters in the end. Anyway, here
> goes nothing.
> 
> This might be a dumb question but isn't Meson (through wrap files) one of the
> build systems that download crap from all over the internet silently? Ie. 
> making
> a packager's/distribution's life hell? There is
> <https://github.com/mesonbuild/meson/wiki/Wrap-dependency-system-manual#toggling-between-distro-packages-and-embedded-source>
> but that seems to imply a silent fallback to downloading stuff. I would rather
> have a configure step that fails if a dependency is not met instead of 
> building
> something that can't be distributed. Or is there a magic 
> "--distribution-build"
> flag? If there isn't I would rather see a switch to CMake (as others have
> pointed out in this thread: many projects in the vicinity of Mesa already use
> CMake), but I get that there's a lot of hate for CMake (even though the Meson
> syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
> would be unlikely.

I hadn't even noticed wrap before. Looking at it wraps they seem to be mainly
aimed at windows and osx, where bundling is the norm, and not Linux and the BSDs
where it's not. What I would expect if the windows guys wanted to use wrap is
that we would have something like this:

if host_machine.system() != 'windows'
dep_zlib = dependency('zlib', version : '>1.0.0')
else
subproj_zlib = subproject('zlib')
dep_zlib = subproj_zlib.get_variable('zlib_dep')
endif

Which would make the dependency a hard requirement for non-windows system (i.e.
the configure fails if zlib isn't found *except* on windows), and windows could
fall back to wraps.

I have no plans to implement wrap for mesa in the port I would do, and would NAK
any patches that used wrap on Linux or BSD. The windows devs can make their own
choice on how to handle dependencies (I have no idea what their development
environment looks like and don't want to make that choice for them). I agree
with you it's not the way that Linux or BSD works, we have competent package
management solutions without the need to automatically download sources.

As for cmake. I've written enough cmake in piglit to last me a lifetime, meson
and cmake are the difference between python and perl, there may be some
superficial similarities, but they are *not* the same. One of the things I'll
reiterate that impressed me the most about meson is that it's syntax is simple,
not Turring-complete, and opinionated.

In fact, piglit is the best reason not not use cmake I can come up with. There
is an (admittedly clever) hack to allow building tests for each of the API's
supported (GL, GLES1, and GLES2+). It does this by re-reunning the cmake for
each API, which means you can't put things in the tests directory that can only
be run once. Every time I try to make changes to the Cmake I spend about an hour
trying to figure out why some code I've implemented doesn't work, only to
remember that. Build systems aren't programming languages, they shouldn't be
interesting, they should be declarative; cmake is a full scripting language with
enough warts to make bash look cuddly.

> 
> Dylan Baker wrote on 16.03.2017 22:25:
> > Why bother, and why would we want this?
> > 
> > First it's written in python, which means the potential developer base
> > is massive. And it provides a recursive view for humans, but a
> > non-recursive view for the system. This is the best of both worlds,
> > humans can organize the build system in a way that makes sense, and the
> > machine gets a non-recursive build system. It also uses ninja rather
> > than make, and ninja is faster than make inherently.
> 
> Well, CMake (and probably others), see
> <https://cmake.org/cmake/help/latest/generator/Ninja.html>, can use/generate 
> for
> ninja too.

Sure, I think we've gone over this in the rather long thread, ninja is really
just a "nice to have" since it's faster than make. The real advantages are:
1) one build system for linux and windows (reducing from 3 to 2 build systems)
2) meson much simpler than autotools, scons, or (especially) cmake
3) recursive meson files, flat ninja file.

> 
> > Meson is also a
> > simpler syntax than autotools or cmake it's not Turing Complete by
> > design nor does it expose python, again, by design. This allows meson
> > itself to be reimplemented in a another language if python becomes a
> > dead-end or a bottle-neck. It also makes it much e

Re: [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jani Nikula (2017-03-21 07:44:55)
> On Thu, 16 Mar 2017, Dylan Baker <dy...@pnwbakers.com> wrote:
> > First it's written in python, [...]
> 
> How does meson handle python 2 vs. 3? How do you avoid issues in the
> build files wrt this? On Debian meson seems to depend on python 3, so
> are they fully python 3?

Meson requires python 3.4+, and doesn't support python 2. Python 3.4 was
released in 2012. It's also worth nothing that a couple of us have been working
to get mesa's python scripts python3 compatible, so in the (hopefully) near
future python2 wouldn't be required.

> How does meson handle build file backwards compatibility between meson
> versions? I don't intend to flame, but I've found for some reason many
> python projects don't seem to take this very seriously. Either having
> conditionals in build files to support building with several meson
> versions or always requiring the latest and greatest version would be
> rather annoying.

Meson makes backwards compatible changes, and the version can be queried using
`meson.version()`, which works using meson's version comparison mechanism. I
would say this about meson, it's not a 'python project', it's 'a project written
in python', and they've taken great pains to not expose python in meson, and
reserve the right to reimplement in a different language if python becomes an
issue.


> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

I would personally rather have scons and autotools than cmake. I've had the
misfortune of using all three, and cmake is not an improvement in my opinion.

Quoting Grazvydas Ignotas (2017-03-21 08:13:31)
> It might make sense to give more attention to cmake just because many
> mesa-related projects are already using it: llvm, piglit, vulkan
> loader and demos, mesa-demos, etc. Not sure how well it supports BSDs
> and windows, but everyone building graphics stacks or contributing to
> mesa should already be comfortable with cmake thanks to piglit and
> llvm, which might not be the case for meson.
> 
> Gražvydas
> 
> On Tue, Mar 21, 2017 at 4:44 PM, Jani Nikula
> <jani.nik...@linux.intel.com> wrote:
> > On Thu, 16 Mar 2017, Dylan Baker <dy...@pnwbakers.com> wrote:
> >> First it's written in python, [...]
> >
> > How does meson handle python 2 vs. 3? How do you avoid issues in the
> > build files wrt this? On Debian meson seems to depend on python 3, so
> > are they fully python 3?
> >
> > How does meson handle build file backwards compatibility between meson
> > versions? I don't intend to flame, but I've found for some reason many
> > python projects don't seem to take this very seriously. Either having
> > conditionals in build files to support building with several meson
> > versions or always requiring the latest and greatest version would be
> > rather annoying.
> >
> >
> > BR,
> > Jani.
> >
> > --
> > Jani Nikula, Intel Open Source Technology Center
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Marek Olšák (2017-03-16 18:53:59)
> On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker <dy...@pnwbakers.com> wrote:
> > Quoting Marek Olšák (2017-03-16 15:36:26)
> >> Is there a way not to use ninja with meson, because ninja redirects
> >> all stderr output from gcc to stdout, which breaks many development
> >> environments that expect errors in stderr?
> >>
> >> I'm basically saying that if ninja can't keep gcc errors in stderr, I
> >> wouldn't like any project that I might be involved in to require ninja
> >> for building.
> >>
> >> Marek
> >
> > There is no way to use another backend on Linux, and meson will not support
> > Make. Ninja is a big part of the appeal here, since it is faster than make 
> > is.
> > Are there particular tools you know don't work with ninja? It seems like in 
> > the
> > 7+ years since ninja came out that someone would have fixed the tools, or 
> > that
> > some stream redirection could be used to fix the problem, "ninja 1>&2"?
> 
> I actually read some thread about it and the conclusion seemed to be
> that ninja developers don't care. I have no other option than to
> believe that ninja was made for automated build bots, not for
> development.
> 
> Some editors expect that errors and only errors go to stderr and all
> other garbage info goes to stdout. This is something I can't change.
> 
> Marek

And I found this: 
https://groups.google.com/forum/#!topic/ninja-build/4syh2jzXWcI

Which leads me to believe that they would be responsive to a patch, the core
team just doesn't have a use for it. There is in fact a patch already written
(linked in that thread), that just needs someone to clean it up and propose it
for merge.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

quoting jason ekstrand (2017-03-16 19:03:15)
> on march 16, 2017 5:41:24 pm emil velikov  wrote:
> > and meson is not a thing on neither bsd(s), solaris (and derivatives) nor 
> > android :-\
> 
> i have trouble bringing myself to care.  the bsds need to stop using 10 
> year old compilers.  it can be made to work on solaris and bsd if someone 
> bothered to put a little work into it.  besides, given that large chunks of 
> gnome are switching they're going to have to make it work some day soon 
> anyway.

I decided to check the ports on my freebsd box, it has meson, in fact:
freebsd: https://svnweb.freebsd.org/ports/head/devel/meson/
netbsd: http://pkgsrc.se/wip/py-meson
openbsd: http://ports.su/devel/meson

The only OS I couldn't find a package for is openindiana (the clostest thing to
Solaris I could come up with), but there is ninja for Solaris, and meson itself
is pure python installable via pip, so even there it's not impossible.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Hi Emil,

Quoting Emil Velikov (2017-03-16 16:35:33)
> While I can see you're impressed by Meson, I would kindly urge you to
> not use it here. As you look closely you can see that one could
> trivially improve the times, yet the biggest thing is that most of the
> code in libdrm must go ;-)

Perhaps I wasn't clear enough, I don't really expect this to land ever. I sent
it out more because I'd written it and it works and is a useful demonstration of
meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge deal :);
but in a larger project, consider that a 4x speedup would be 4 minutes to 1
minute, and that is a huge difference in time.

> 
> As the port is not 1:1 wrt the autoconf one, the performance numbers
> above are comparing apples to oranges.

I fail to see what I'm missing from meson that would have an effect on the
times I reported. There are some files that are installed by autoconf that I
didn't bother to install with meson (because I don't expect this to land). Since
I didn't time installs, I don't see how it isn't an apples to apples comparison.

I understand that libdrm is a pessimal case for recursive-make since most
sub folders contain < 5 C files, However, even if you were to flatten the make
files meson+ninja would still be faster when you consider that meson
configures and builds faster than autotools configures.

> If you/others are unhappy with the build times of libdrm - poke me on
> IRC. I will give you some easy tips on how to improve those.
> 
> You have some good python knowledge - I would kindly urge you to
> improve/rewrite the slow and/or hacky python scripts we have in mesa.
> This is a topic that was mentioned multiple times, and a part where
> everyone will be glad to see some progress.
> 
> Thanks
> Emil

The real goal here is to do mesa (in case I didn't make that clear either), and
the advantage for mesa is not just performance, it's that meson supports visual
studio on windows; which means that we could hopefully not just get faster
builds, but also replace both autotools and scons with a single build system.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Marek Olšák (2017-03-16 15:36:26)
> Is there a way not to use ninja with meson, because ninja redirects
> all stderr output from gcc to stdout, which breaks many development
> environments that expect errors in stderr?
> 
> I'm basically saying that if ninja can't keep gcc errors in stderr, I
> wouldn't like any project that I might be involved in to require ninja
> for building.
> 
> Marek

There is no way to use another backend on Linux, and meson will not support
Make. Ninja is a big part of the appeal here, since it is faster than make is.
Are there particular tools you know don't work with ninja? It seems like in the
7+ years since ninja came out that someone would have fixed the tools, or that
some stream redirection could be used to fix the problem, "ninja 1>&2"?

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Ilia Mirkin (2017-03-16 14:32:09)
> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker <dy...@pnwbakers.com> wrote:
> > Why bother, and why would we want this? 
> >  │~
> >
> > First it's written in python, which means the potential developer base
> > is massive. And it provides a recursive view for humans, but a
> > non-recursive view for the system. This is the best of both worlds,
> > humans can organize the build system in a way that makes sense, and the
> > machine gets a non-recursive build system. It also uses ninja rather
> > than make, and ninja is faster than make inherently. Meson is also a
> > simpler syntax than autotools or cmake it's not Turing Complete by
> > design nor does it expose python, again, by design. This allows meson
> > itself to be reimplemented in a another language if python becomes a
> > dead-end or a bottle-neck. It also makes it much easier to understand
> > what the build system is doing.
> >
> > What's different about using meson?
> >
> > Well, apart from a faster builds and less magic in the build system? The
> > configure flags are different, it uses -D= more like cmake
> > than the --enable or --with flags of autotools, although oddly it uses
> > --prefix and friends when calling meson, but not with mesonconf, there's
> > a bug opened on this. Meson also doesn't support in-tree builds at all;
> > all builds are done out of tree. It also doesn't provide a "make dist"
> > target, fortunately there's this awesome tool called git, and it
> > provides a "git archive" command that does much the same thing. Did I
> > mention it's fast?
> >
> > Here are the performance numbers I see on a 2 core 4 thread SKL, without
> > initial configuration, and building out of tree (using zsh):
> >
> > For meson the command line is:
> > time (meson build -Dmanpages=true && ninja -C build)
> >
> > For autotools the command line is:
> > time (mdkir build && cd build && ../autotools && make -j5 -l4)
> 
> Probably mkdir...

derp, yeah.

> 
> >
> > meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
> > autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> > meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
> > autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
> >
> > That's ~4x faster for a cold build and ~10x faster for a hot build.
> >
> > For a make clean && make style build with a hot cache:
> > meson: 4.64s user 0.33s system 334% cpu 1.486 total
> > autotools: 7.93s user 0.32s system 167% cpu 4.920 total
> >
> > Why bother with libdrm?
> >
> > It's a simple build system, that could be completely (or mostly
> > completely) be ported in a very short time, and could serve as a tech
> > demo for the advantages of using meson to garner feedback for embarking
> > on a larger project, like mesa (which is what I'm planning to work on
> > next).
> >
> > tl;dr
> >
> > I wrote this as practice for porting Mesa, and figured I might as well
> > send it out since I wrote it.
> >
> > It is very likely that neither of these large patches will show up on the
> > mailing list, but this is available at my github:
> > https://github.com/dcbaker/libdrm wip/meson
> 
> I haven't looked at meson or your patches in detail, but autotools
> supports 2 very important use-cases very well:
> 
> 1. ./configure --help
> 2. Cross-compilation with minimal requirement from the project being built
> 
> Can you comment on how these are handled in meson?
> 
> Cheers,
> 
>   -ilia

1. mesonconf  provides much the same thing. You can also read the
meson_options.txt file, which is generally pretty short. I haven't added
descriptions to the options in this patch.

2. you write a small ini style configuration file, something like:
[binaries]
c = '/usr/bin/aarch64-linux-gnu-gc'
ar = '/usr/bin/aarch64-linux-gnu-gcc-ar'
strip = '/usr/bin/aarch64-linux-gnu-strip'
pkg-config = '/usr/bin/aarch64-linux-gnu-pkgconfig'

Then you just configure with:
meson build --cross-file cross_file.txt

then just ninja like normal

There's a more detailed walkthrough here:
https://github.com/mesonbuild/meson/wiki/Cross-compilation

I was able to cross compile the arm libraries for aarch64 using basically the
above configuration (I had to write a wrapper script for pkg-config to set a
couple of environment variables and install and archlinux aarach64 chroot,
because arch), of course, I don't have access to any arm machines that I could
test with.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC libdrm 1/2] Port build system to meson

[Dylan Baker]

This is a bit of a tech demo, a bit of a serious port to meson. This
provides almost all of the build system, except for the ability to
install the tests, it doesn't add -lrt for the clock (it's been in core
glibc for some time), has basically no comments, and hasn't been tested
on any platform except Linux (I have cross compiled for arm). It also
relies on unreviewed, unmerged patches to meson for valgrind support
(but will work fine without the patch and without valgrind)

What's not done:
- the install tests flag isn't implemented
- some of the extra data installs aren't implemented
- valgrind is set to "no" rather than "auto". To make valgrind work
  correctly you need a patch that's neither reviewed nor landed in
  meson, or to implement a hack that might make cross compiling
  difficult.
---
 .editorconfig   |   4 +-
 README  |  21 +--
 amdgpu/meson.build  |  57 +++-
 etnaviv/meson.build |  56 +++-
 exynos/meson.build  |  52 +++-
 freedreno/meson.build   |  72 +-
 include/drm/meson.build |  48 ++-
 intel/intel_bufmgr_gem.c|   8 +-
 intel/meson.build   |  55 +++-
 libkms/meson.build  |  71 +-
 man/meson.build | 119 +++-
 meson.build | 288 +-
 meson_config.h.in   |  24 +++-
 meson_options.txt   |  16 ++-
 nouveau/meson.build |  63 -
 omap/meson.build|  48 ++-
 radeon/meson.build  |  62 -
 tegra/meson.build   |  50 ++-
 tests/amdgpu/meson.build|  30 -
 tests/etnaviv/meson.build   |  49 ++-
 tests/exynos/meson.build|  43 ++-
 tests/kms/meson.build   |  46 ++-
 tests/kmstest/meson.build   |  28 -
 tests/meson.build   |  87 +++-
 tests/modeprint/meson.build |  27 +++-
 tests/modetest/meson.build  |  27 +++-
 tests/nouveau/meson.build   |  30 -
 tests/proptest/meson.build  |  27 +++-
 tests/radeon/meson.build|  27 +++-
 tests/tegra/meson.build |  27 +++-
 tests/util/meson.build  |  35 -
 tests/vbltest/meson.build   |  27 +++-
 vc4/meson.build |  28 -
 xf86atomic.h|   4 +-
 34 files changed, 1637 insertions(+), 19 deletions(-)
 create mode 100644 amdgpu/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 include/drm/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_config.h.in
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/modetest/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

diff --git a/.editorconfig b/.editorconfig
index 893b7be..ffc477f 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -17,3 +17,7 @@ indent_style = tab
 [*.m4]
 indent_style = space
 indent_size = 2
+
+[meson.build]
+indent_style = space
+indent_size = 2
diff --git a/README b/README
index 26cab9d..b567d7e 100644
--- a/README
+++ b/README
@@ -15,27 +15,22 @@ with an older kernel.
 Compiling
 -
 
-libdrm  is  a  standard  autotools  package and  follows  the  normal
-configure, build  and install steps.   The first step is  to configure
-the package, which is done by running the configure shell script:
+libdrm is compiled using meson and ninja. The first step for building for a
+tar-ball or from git is to configure, and set a build directory:
 
-   ./configure
+meson build
 
-By default, libdrm  will install into the /usr/local/  prefix.  If you
-want  to  install   this  DRM  to  replace  your   system  copy,  pass
---prefix=/usr and  --exec-prefix=/ to configure.  If  you are building
-libdrm  from a  git checkout,  you first  need to  run  the autogen.sh
-script.  You can  pass any options to autogen.sh  that you would other
-wise  pass to configure,  or you  can just  re-run configure  with the
-options you need once autogen.sh finishes.
+By default, libdrm will install into the /usr/local/ prefix. If you
+want to install this DRM to replace your system copy, pass
+--prefix=/usr to 

[RFC libdrm 2/2] remove autotools build

[Dylan Baker]

This is mostly to demonstrate all of the code that would be deleted by
removing the autotools build.

This is *not* ready to land, since it deletes some files used by the android
build (Makefile.sources).
---
 .editorconfig|   4 +-
 .gitignore   |  82 +-
 Makefile.am  | 144 +
 Makefile.sources |  41 +--
 amdgpu/Makefile.am   |  47 +---
 amdgpu/Makefile.sources  |  15 +-
 amdgpu/libdrm_amdgpu.pc.in   |  11 +-
 autogen.sh   |  20 +-
 configure.ac | 568 +
 etnaviv/Makefile.am  |  26 +-
 etnaviv/Makefile.sources |  12 +-
 etnaviv/libdrm_etnaviv.pc.in |  11 +-
 exynos/Makefile.am   |  27 +--
 exynos/libdrm_exynos.pc.in   |  11 +-
 freedreno/Makefile.am|  30 +--
 freedreno/Makefile.sources   |  26 +-
 freedreno/libdrm_freedreno.pc.in |  11 +-
 intel/Makefile.am|  73 +
 intel/Makefile.sources   |  15 +-
 intel/libdrm_intel.pc.in |  11 +-
 libdrm.pc.in |  10 +-
 libkms/Makefile.am   |  43 +--
 libkms/Makefile.sources  |  23 +-
 libkms/libkms.pc.in  |  11 +-
 m4/.gitignore|   5 +-
 man/Makefile.am  |  62 +---
 nouveau/Makefile.am  |  33 +--
 nouveau/Makefile.sources |   9 +-
 nouveau/libdrm_nouveau.pc.in |  11 +-
 omap/Makefile.am |  24 +-
 omap/libdrm_omap.pc.in   |  11 +-
 radeon/Makefile.am   |  47 +---
 radeon/Makefile.sources  |  21 +-
 radeon/libdrm_radeon.pc.in   |  11 +-
 tegra/Makefile.am|  25 +-
 tegra/libdrm_tegra.pc.in |  11 +-
 tests/Makefile.am|  47 +---
 tests/amdgpu/Makefile.am |  29 +--
 tests/etnaviv/Makefile.am|  41 +--
 tests/exynos/Makefile.am |  47 +---
 tests/kms/Makefile.am|  36 +--
 tests/kmstest/Makefile.am|  25 +-
 tests/modeprint/Makefile.am  |  18 +-
 tests/modetest/Makefile.am   |  24 +-
 tests/modetest/Makefile.sources  |   6 +-
 tests/nouveau/Makefile.am|  16 +-
 tests/proptest/Makefile.am   |  21 +-
 tests/proptest/Makefile.sources  |   2 +-
 tests/radeon/Makefile.am |  14 +-
 tests/tegra/Makefile.am  |  13 +-
 tests/ttmtest/Makefile.am|   1 +-
 tests/ttmtest/src/Makefile.am|   8 +-
 tests/util/Makefile.am   |  13 +-
 tests/util/Makefile.sources  |   8 +-
 tests/vbltest/Makefile.am|  19 +-
 vc4/Makefile.am  |  34 +--
 vc4/Makefile.sources |   3 +-
 vc4/libdrm_vc4.pc.in |   9 +-
 58 files changed, 1976 deletions(-)
 delete mode 100644 Makefile.am
 delete mode 100644 Makefile.sources
 delete mode 100644 amdgpu/Makefile.am
 delete mode 100644 amdgpu/Makefile.sources
 delete mode 100644 amdgpu/libdrm_amdgpu.pc.in
 delete mode 100755 autogen.sh
 delete mode 100644 configure.ac
 delete mode 100644 etnaviv/Makefile.am
 delete mode 100644 etnaviv/Makefile.sources
 delete mode 100644 etnaviv/libdrm_etnaviv.pc.in
 delete mode 100644 exynos/Makefile.am
 delete mode 100644 exynos/libdrm_exynos.pc.in
 delete mode 100644 freedreno/Makefile.am
 delete mode 100644 freedreno/Makefile.sources
 delete mode 100644 freedreno/libdrm_freedreno.pc.in
 delete mode 100644 intel/Makefile.am
 delete mode 100644 intel/Makefile.sources
 delete mode 100644 intel/libdrm_intel.pc.in
 delete mode 100644 libdrm.pc.in
 delete mode 100644 libkms/Makefile.am
 delete mode 100644 libkms/Makefile.sources
 delete mode 100644 libkms/libkms.pc.in
 delete mode 100644 m4/.gitignore
 delete mode 100644 man/Makefile.am
 delete mode 100644 nouveau/Makefile.am
 delete mode 100644 nouveau/Makefile.sources
 delete mode 100644 nouveau/libdrm_nouveau.pc.in
 delete mode 100644 omap/Makefile.am
 delete mode 100644 omap/libdrm_omap.pc.in
 delete mode 100644 radeon/Makefile.am
 delete mode 100644 radeon/Makefile.sources
 delete mode 100644 radeon/libdrm_radeon.pc.in
 delete mode 100644 tegra/Makefile.am
 delete mode 100644 tegra/libdrm_tegra.pc.in
 delete mode 100644 tests/Makefile.am
 delete mode 100644 tests/amdgpu/Makefile.am
 delete mode 100644 tests/etnaviv/Makefile.am
 delete mode 100644 tests/exynos/Makefile.am
 delete mode 100644 tests/kms/Makefile.am
 delete mode 100644 tests/kmstest/Makefile.am
 delete mode 100644 tests/modeprint/Makefile.am
 delete mode 100644 tests/modetest/Makefile.am
 delete mode 100644 tests/modetest/Makefile.sources
 delete mode 100644 tests/nouveau/Makefile.am
 delete mode 100644 tests/proptest/Makefile.am
 delete mode 100644 tests/proptest/Makefile.sources
 delete mode 100644 tests/radeon/Makefile.am
 delete mode 100644 tests/tegra/Makefile.am
 delete mode 100644 tests/ttmtest/Makefile.am
 delete mode 100644 tests/ttmtest/src/Makefile.am
 delete mode 100644 tests/util/Makefile.am
 delete 

[RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Why bother, and why would we want this? 
 ???~

First it's written in python, which means the potential developer base
is massive. And it provides a recursive view for humans, but a
non-recursive view for the system. This is the best of both worlds,
humans can organize the build system in a way that makes sense, and the
machine gets a non-recursive build system. It also uses ninja rather
than make, and ninja is faster than make inherently. Meson is also a
simpler syntax than autotools or cmake it's not Turing Complete by
design nor does it expose python, again, by design. This allows meson
itself to be reimplemented in a another language if python becomes a
dead-end or a bottle-neck. It also makes it much easier to understand
what the build system is doing.

What's different about using meson?

Well, apart from a faster builds and less magic in the build system? The
configure flags are different, it uses -D= more like cmake
than the --enable or --with flags of autotools, although oddly it uses
--prefix and friends when calling meson, but not with mesonconf, there's
a bug opened on this. Meson also doesn't support in-tree builds at all;
all builds are done out of tree. It also doesn't provide a "make dist"
target, fortunately there's this awesome tool called git, and it
provides a "git archive" command that does much the same thing. Did I
mention it's fast?

Here are the performance numbers I see on a 2 core 4 thread SKL, without
initial configuration, and building out of tree (using zsh):

For meson the command line is:
time (meson build -Dmanpages=true && ninja -C build)

For autotools the command line is:
time (mdkir build && cd build && ../autotools && make -j5 -l4)

meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total

That's ~4x faster for a cold build and ~10x faster for a hot build.

For a make clean && make style build with a hot cache:
meson: 4.64s user 0.33s system 334% cpu 1.486 total
autotools: 7.93s user 0.32s system 167% cpu 4.920 total

Why bother with libdrm?

It's a simple build system, that could be completely (or mostly
completely) be ported in a very short time, and could serve as a tech
demo for the advantages of using meson to garner feedback for embarking
on a larger project, like mesa (which is what I'm planning to work on
next).

tl;dr

I wrote this as practice for porting Mesa, and figured I might as well
send it out since I wrote it.

It is very likely that neither of these large patches will show up on the
mailing list, but this is available at my github:
https://github.com/dcbaker/libdrm wip/meson

Dylan Baker (2):
  Port build system to meson
  remove autotools build

 .editorconfig|   2 +-
 .gitignore   |  82 +-
 Makefile.am  | 144 +
 Makefile.sources |  41 +--
 README   |  21 +-
 amdgpu/Makefile.am   |  47 +---
 amdgpu/Makefile.sources  |  15 +-
 amdgpu/libdrm_amdgpu.pc.in   |  11 +-
 amdgpu/meson.build   |  57 +++-
 autogen.sh   |  20 +-
 configure.ac | 568 +
 etnaviv/Makefile.am  |  26 +-
 etnaviv/Makefile.sources |  12 +-
 etnaviv/libdrm_etnaviv.pc.in |  11 +-
 etnaviv/meson.build  |  56 +++-
 exynos/Makefile.am   |  27 +--
 exynos/libdrm_exynos.pc.in   |  11 +-
 exynos/meson.build   |  52 +++-
 freedreno/Makefile.am|  30 +--
 freedreno/Makefile.sources   |  26 +-
 freedreno/libdrm_freedreno.pc.in |  11 +-
 freedreno/meson.build|  72 -
 include/drm/meson.build  |  48 +++-
 intel/Makefile.am|  73 +
 intel/Makefile.sources   |  15 +-
 intel/intel_bufmgr_gem.c |   8 +-
 intel/libdrm_intel.pc.in |  11 +-
 intel/meson.build|  55 +++-
 libdrm.pc.in |  10 +-
 libkms/Makefile.am   |  43 +--
 libkms/Makefile.sources  |  23 +-
 libkms/libkms.pc.in  |  11 +-
 libkms/meson.build   |  71 -
 m4/.gitignore|   5 +-
 man/Makefile.am  |  62 +---
 man/meson.build  | 119 +++-
 meson.build  | 288 -
 meson_config.h.in|  24 +-
 meson_options.txt|  16 +-
 nouveau/Makefile.am  |  33 +--
 nouveau/Makefile.sources |   9 +-
 nouveau/libdrm_nouveau.pc.in |  11 +-
 nouveau/meson.build  |  63 -
 omap/Makefile.am |  24 +-

[Mesa-dev] [PATCH] glx/dri3: Use four buffers until X driver supports async flips

[Dylan Baker]

Tested-by: Dylan Baker 

On Wednesday, July 02, 2014 02:28:07 PM Keith Packard wrote:
> A driver which doesn't have async flip support will queue up flips without any
> way to replace them afterwards. This means we've got a scanout buffer pinned
> as soon as we schedule a flip and so we need another buffer to keep from
> stalling.
> 
> When vblank_mode=0, if there are only three buffers we do:
> 
> current scanout buffer = 0 at MSC 0
> 
> Render frame 1 to buffer 1
> PresentPixmap for buffer 1 at MSC 1
> 
> This is sitting down in the kernel waiting for vblank to
> become the next scanout buffer
> 
> Render frame 2 to buffer 2
> PresentPixmap for buffer 2 at MSC 1
> 
> This cannot be displayed at MSC 1 because the
> kernel doesn't have any way to replace buffer 1 as the pending
> scanout buffer. So, best case this will get displayed at MSC 
> 2.
> 
> Now we block after this, waiting for one of the three buffers to become idle.
> We can't use buffer 0 because it is the scanout buffer. We can't use buffer 1
> because it's sitting in the kernel waiting to become the next scanout buffer
> and we can't use buffer 2 because that's the most recent frame which will
> become the next scanout buffer if the application doesn't manage to generate
> another complete frame by MSC 2.
> 
> With four buffers, we get:
> 
> current scanout buffer = 0 at MSC 0
> 
> Render frame 1 to buffer 1
> PresentPixmap for buffer 1 at MSC 1
> 
> This is sitting down in the kernel waiting for vblank to
> become the next scanout buffer
> 
> Render frame 2 to buffer 2
> PresentPixmap for buffer 2 at MSC 1
> 
> This cannot be displayed at MSC 1 because the
> kernel doesn't have any way to replace buffer 1 as the pending
> scanout buffer. So, best case this will get displayed at MSC
> 2. The X server will queue this swap until buffer 1 becomes
> the scanout buffer.
> 
> Render frame 3 to buffer 3
> PresentPixmap for buffer 3 at MSC 1
> 
> As soon as the X server sees this, it will replace the pending
> buffer 2 swap with this swap and release buffer 2 back to the
> application
> 
> Render frame 4 to buffer 2
> PresentPixmap for buffer 2 at MSC 1
> 
> Now we're in a steady state, flipping between buffer 2 and 3
> waiting for one of them to be queued to the kernel.
> 
> ...
> 
> current scanout buffer = 1 at MSC 1
> 
> Now buffer 0 is free and (e.g.) buffer 2 is queued in
> the kernel to be the scanout buffer at MSC 2
> 
> Render frames, flipping between buffer 0 and 3
> 
> When the system can replace a queued buffer, and we update Present to take
> advantage of that, we can use three buffers and get:
> 
> current scanout buffer = 0 at MSC 0
> 
> Render frame 1 to buffer 1
> PresentPixmap for buffer 1 at MSC 1
> 
> This is sitting waiting for vblank to become the next scanout
> buffer
> 
> Render frame 2 to buffer 2
> PresentPixmap for buffer 2 at MSC 1
> 
> Queue this for display at MSC 1
> 1. There are three possible results:
> 
>   1) We're still before MSC 1. Buffer 1 is released,
>  buffer 2 is queued waiting for MSC 1.
> 
>   2) We're now after MSC 1. Buffer 0 was released at MSC 1.
>  Buffer 1 is the current scanout buffer.
> 
>  a) If the user asked for a tearing update, we swap
> scanout from buffer 1 to buffer 2 and release buffer
> 1.
> 
>  b) If the user asked for non-tearing update, we
> queue buffer 2 for the MSC 2.
> 
> In all three cases, we have a buffer released (call it 'n'),
> ready to receive the next frame.
> 
> Render frame 3 to buffer n
> PresentPixmap for buffer n
> 
> If we're still before MSC 1, then we'll ask to present at MSC
> 1. Otherwise, we'll ask to present at MSC 2.
> 
> Present already does this if the driver offers async flips, however it does
> this by waiting for the right vblank event and sending an async flip right at
> that point.
> 
> I've hacked the intel driver to off