Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Eric Anholt]

On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie  wrote:
>
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone  wrote:
> >
> > On Fri, 28 Feb 2020 at 03:38, Dave Airlie  wrote:
> > > b) we probably need to take a large step back here.
> > >
> > > Look at this from a sponsor POV, why would I give X.org/fd.o
> > > sponsorship money that they are just giving straight to google to pay
> > > for hosting credits? Google are profiting in some minor way from these
> > > hosting credits being bought by us, and I assume we aren't getting any
> > > sort of discounts here. Having google sponsor the credits costs google
> > > substantially less than having any other company give us money to do
> > > it.
> >
> > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > comparable in terms of what you get and what you pay for them.
> > Obviously providers like Packet and Digital Ocean who offer bare-metal
> > services are cheaper, but then you need to find someone who is going
> > to properly administer the various machines, install decent
> > monitoring, make sure that more storage is provisioned when we need
> > more storage (which is basically all the time), make sure that the
> > hardware is maintained in decent shape (pretty sure one of the fd.o
> > machines has had a drive in imminent-failure state for the last few
> > months), etc.
> >
> > Given the size of our service, that's a much better plan (IMO) than
> > relying on someone who a) isn't an admin by trade, b) has a million
> > other things to do, and c) hasn't wanted to do it for the past several
> > years. But as long as that's the resources we have, then we're paying
> > the cloud tradeoff, where we pay more money in exchange for fewer
> > problems.
>
> Admin for gitlab and CI is a full time role anyways. The system is
> definitely not self sustaining without time being put in by you and
> anholt still. If we have $75k to burn on credits, and it was diverted
> to just pay an admin to admin the real hw + gitlab/CI would that not
> be a better use of the money? I didn't know if we can afford $75k for
> an admin, but suddenly we can afford it for gitlab credits?

As I think about the time that I've spent at google in less than a
year on trying to keep the lights on for CI and optimize our
infrastructure in the current cloud environment, that's more than the
entire yearly budget you're talking about here.  Saying "let's just
pay for people to do more work instead of paying for full-service
cloud" is not a cost optimization.


> > Yes, we could federate everything back out so everyone runs their own
> > builds and executes those. Tinderbox did something really similar to
> > that IIRC; not sure if Buildbot does as well. Probably rules out
> > pre-merge testing, mind.
>
> Why? does gitlab not support the model? having builds done in parallel
> on runners closer to the test runners seems like it should be a thing.
> I guess artifact transfer would cost less then as a result.

Let's do some napkin math.  The biggest artifacts cost we have in Mesa
is probably meson-arm64/meson-arm (60MB zipped from meson-arm64,
downloaded by 4 freedreno and 6ish lava, about 100 pipelines/day,
makes ~1.8TB/month ($180 or so).  We could build a local storage next
to the lava dispatcher so that the artifacts didn't have to contain
the rootfs that came from the container (~2/3 of the insides of the
zip file), but that's another service to build and maintain.  Building
the drivers once locally and storing it would save downloading the
other ~1/3 of the inside of the zip file, but that requires a big
enough system to do builds in time.

I'm planning on doing a local filestore for google's lava lab, since I
need to be able to move our xml files off of the lava DUTs to get the
xml results we've become accustomed to, but this would not bubble up
to being a priority for my time if I wasn't doing it anyway.  If it
takes me a single day to set all this up (I estimate a couple of
weeks), that costs my employer a lot more than sponsoring the costs of
the inefficiencies of the system that has accumulated.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Split render/display SoCs, Mesa's renderonly, and Wayland dmabuf hints

[Eric Anholt]

On Tue, Apr 20, 2021 at 3:18 AM Daniel Stone  wrote:
>
> Hi,
>
> On Mon, 19 Apr 2021 at 13:06, Simon Ser  wrote:
>>
>> I'm working on a Wayland extension [1] that, among other things, allows
>> compositors to advertise the preferred device to be used by Wayland
>> clients.
>>
>> In general, compositors will send a render node. However, in the case
>> of split render/display SoCs, things get a little bit complicated.
>>
>> [...]
>
>
> Thanks for the write-up Simon!
>
>>
>> There are a few solutions:
>>
>> 1. Require compositors to discover the render device by trying to import
>>a buffer. For each available render device, the compositor would
>>allocate a buffer, export it as a DMA-BUF, import it to the
>>display-only device, then try to drmModeAddFB.
>
>
> I don't think this is actually tractable? Assuming that 'allocate a buffer' 
> means 'obtain a gbm_device for the render node directly and allocate a gbm_bo 
> from it', even with compatible formats and modifiers this will fail for more 
> restrictive display hardware. imx-drm and pl111 (combined with vc4 on some 
> Raspberry Pis) will fail this, since they'll take different allocation paths 
> when they're bound through kmsro vs. directly, accounting for things like 
> contiguous allocation. So we'd get false negatives on at least some platforms.
>
>>
>> 2. Allow compositors to query the render device magically opened by
>>kmsro. This could be done either via EGL_EXT_device_drm, or via a
>>new EGL extension.
>
>
> This would be my strong preference, and I don't entirely understand anholt's 
> pushback here. The way I see it, GBM is about allocation for scanout, and EGL 
> is about rendering. If, on a split GPU/display system, we create a gbm_device 
> from a KMS display-only device node, then creating an EGLDisplay from that 
> magically binds us to a completely different DRM GPU node, and anything using 
> that EGLDisplay will use that GPU device to render.
>
> Being able to discover the GPU device node through the device query is really 
> useful, because it tells us exactly what implicit magic EGL did under the 
> hood, and about the device that EGL will use. Being able to discover the 
> display node is much less useful; it does tell us how GBM will allocate 
> buffers, but the user already knows which device is in use because they 
> supplied it to GBM. I see the display node as a property of GBM, and the GPU 
> node as a property of EGL, even if EGL does do (*waves hands*) stuff under 
> the hood to ensure the two are compatible.

I guess if we're assuming that the caller definitely knows about the
display device and is asking EGL for the render node in order to do
smarter buffer sharing between display and render, I can see it.  My
objection was that getting the render node in that discussion was
apparently some workaround for other brokenness, and was going to
result in software that didn't work on pl111 and vc4 displays because
it was trying to dodge kmsro.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/2] configure: Fix build on debian by avoiding bashisms in the test command.

[Eric Anholt]

---
 configure.ac |   42 +-
 1 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/configure.ac b/configure.ac
index 02f4040..7596799 100644
--- a/configure.ac
+++ b/configure.ac
@@ -33,13 +33,13 @@ AM_CONDITIONAL(HAVE_RSVG_CONVERT, test -n "$RSVG_CONVERT")
 
 AC_ARG_ENABLE(setuid-install, [  --enable-setuid-install],,
  enable_setuid_install=yes)
-AM_CONDITIONAL(ENABLE_SETUID_INSTALL, test x$enable_setuid_install == xyes)
+AM_CONDITIONAL(ENABLE_SETUID_INSTALL, test x$enable_setuid_install = xyes)
 
 
 AC_ARG_ENABLE(xserver-launcher, [  --enable-xserver-launcher],,
  enable_xserver_launcher=yes)
-AM_CONDITIONAL(ENABLE_XSERVER_LAUNCHER, test x$enable_xserver_launcher == xyes)
-if test x$enable_xserver_launcher == xyes; then
+AM_CONDITIONAL(ENABLE_XSERVER_LAUNCHER, test x$enable_xserver_launcher = xyes)
+if test x$enable_xserver_launcher = xyes; then
   PKG_CHECK_MODULES([XSERVER_LAUNCHER], xcb xcb-xfixes)
   AC_DEFINE([BUILD_XSERVER_LAUNCHER], [1], [Build the X server launcher])
 
@@ -52,8 +52,8 @@ fi
 
 AC_ARG_ENABLE(x11-compositor, [  --enable-x11-compositor],,
  enable_x11_compositor=yes)
-AM_CONDITIONAL(ENABLE_X11_COMPOSITOR, test x$enable_x11_compositor == xyes)
-if test x$enable_x11_compositor == xyes; then
+AM_CONDITIONAL(ENABLE_X11_COMPOSITOR, test x$enable_x11_compositor = xyes)
+if test x$enable_x11_compositor = xyes; then
   PKG_CHECK_MODULES([XCB], xcb)
   xcb_save_LIBS=$LIBS
   xcb_save_CFLAGS=$CFLAGS
@@ -70,8 +70,8 @@ fi
 
 AC_ARG_ENABLE(drm-compositor, [  --enable-drm-compositor],,
  enable_drm_compositor=yes)
-AM_CONDITIONAL(ENABLE_DRM_COMPOSITOR, test x$enable_drm_compositor == xyes)
-if test x$enable_drm_compositor == xyes; then
+AM_CONDITIONAL(ENABLE_DRM_COMPOSITOR, test x$enable_drm_compositor = xyes)
+if test x$enable_drm_compositor = xyes; then
   AC_DEFINE([BUILD_DRM_COMPOSITOR], [1], [Build the DRM compositor])
   PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.23 gbm])
 fi
@@ -79,8 +79,8 @@ fi
 
 AC_ARG_ENABLE(openwfd-compositor, [  --enable-openwfd-compositor],,
  enable_openwfd_compositor=no)
-AM_CONDITIONAL(ENABLE_OPENWFD_COMPOSITOR, test x$enable_openwfd_compositor == 
xyes)
-if test x$enable_openwfd_compositor == xyes; then
+AM_CONDITIONAL(ENABLE_OPENWFD_COMPOSITOR, test x$enable_openwfd_compositor = 
xyes)
+if test x$enable_openwfd_compositor = xyes; then
   AC_DEFINE([BUILD_OPENWFD_COMPOSITOR], [1], [Build the OpenWF compositor])
   PKG_CHECK_MODULES(OPENWFD_COMPOSITOR, [openwfd gbm])
 fi
@@ -89,8 +89,8 @@ fi
 AC_ARG_ENABLE(wayland-compositor, [  --enable-wayland-compositor],,
  enable_wayland_compositor=yes)
 AM_CONDITIONAL(ENABLE_WAYLAND_COMPOSITOR,
-  test x$enable_wayland_compositor == xyes)
-if test x$enable_wayland_compositor == xyes; then
+  test x$enable_wayland_compositor = xyes)
+if test x$enable_wayland_compositor = xyes; then
   AC_DEFINE([BUILD_WAYLAND_COMPOSITOR], [1],
[Build the Wayland (nested) compositor])
   PKG_CHECK_MODULES(WAYLAND_COMPOSITOR, [wayland-client wayland-egl])
@@ -100,21 +100,21 @@ AC_ARG_WITH(cairo-glesv2, 
AS_HELP_STRING([--with-cairo-glesv2],
   [Use GLESv2 cairo instead of full GL]),
   [cairo_modules="cairo-glesv2"],
   [cairo_modules="cairo-gl"])
-if test x$cairo_modules == xcairo-glesv2; then
+if test x$cairo_modules = xcairo-glesv2; then
   AC_DEFINE([USE_CAIRO_GLESV2], [1], [Use the GLESv2 GL cairo backend])
 fi
 
 AC_ARG_ENABLE(simple-clients, [  --enable-simple-clients],, 
enable_simple_clients=yes)
-AM_CONDITIONAL(BUILD_SIMPLE_CLIENTS, test x$enable_simple_clients == xyes)
-if test x$enable_simple_clients == xyes; then
+AM_CONDITIONAL(BUILD_SIMPLE_CLIENTS, test x$enable_simple_clients = xyes)
+if test x$enable_simple_clients = xyes; then
   AC_DEFINE([BUILD_SIMPLE_CLIENTS], [1], [Build the Wayland simple clients])
   PKG_CHECK_MODULES(SIMPLE_CLIENT,
 [egl >= 7.10 glesv2 wayland-client wayland-egl])
 fi
 
 AC_ARG_ENABLE(clients, [  --enable-clients],, enable_clients=yes)
-AM_CONDITIONAL(BUILD_CLIENTS, test x$enable_clients == xyes)
-if test x$enable_clients == xyes; then
+AM_CONDITIONAL(BUILD_CLIENTS, test x$enable_clients = xyes)
+if test x$enable_clients = xyes; then
   AC_DEFINE([BUILD_CLIENTS], [1], [Build the Wayland clients])
 
   PKG_CHECK_MODULES(CLIENT, [wayland-client wayland-egl egl >= 7.10 cairo >= 
1.10.0 gdk-pixbuf-2.0 glib-2.0 gobject-2.0 gio-2.0 xkbcommon libpng])
@@ -134,7 +134,7 @@ if test x$enable_clients == xyes; then
   CLIENT_CFLAGS="$CLIENT_CFLAGS $WEBP_CFLAGS"
 
   AC_CHECK_LIB([jpeg], [jpeg_CreateDecompress], have_jpeglib=yes)
-  if test x$have_jpeglib == xyes; then
+  if test x$have_jpeglib = xyes; then
 CLIENT_LIBS="$CLIENT_LIBS -ljpeg"
   else
 AC_ERROR([libjpeg not found])
@@ -145,20 +145,20 @@ fi
 AM_CONDITIONAL(HAVE_POPPLER, test "x$have_poppler" = "xyes")
 
 AM_CONDI

[PATCH 2/2] automake: Don't fail the build if we can't setuid.

[Eric Anholt]

The configure default is to setuid root the weston compositor.
However, if installing as non-root (say, to your prefix in homedir),
the install fails anyway, even if you didn't need setuid to run weston
in your configuration.
---
 clients/window.c |2 +-
 src/Makefile.am  |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index 3246189..1c6b04e 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2733,7 +2733,7 @@ init_xkb(struct display *d)
 static void
 fini_xkb(struct display *display)
 {
-   xkb_free_keymap(display->xkb);
+   //xkb_free_keymap(display->xkb);
 }
 
 static int
diff --git a/src/Makefile.am b/src/Makefile.am
index 2c91abc..ad1 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -26,8 +26,8 @@ weston_SOURCES =  \
 
 if ENABLE_SETUID_INSTALL
 install-exec-hook:
-   chown root $(DESTDIR)$(bindir)/weston
-   chmod u+s $(DESTDIR)$(bindir)/weston
+   -chown root $(DESTDIR)$(bindir)/weston
+   -chmod u+s $(DESTDIR)$(bindir)/weston
 endif
 
 if ENABLE_XSERVER_LAUNCHER
-- 
1.7.9

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel