Skip to content
Snippets Groups Projects
  • Simon McVittie's avatar
    94699abd
    pv-runtime: Use threads to enumerate graphics drivers in parallel · 94699abd
    Simon McVittie authored
    
    SrtSystemInfo is not thread-aware, but can safely be handed off from
    one thread to another, and caches its results internally; so we can use
    a thread per architecture, plus an extra thread for cross-architecture
    Vulkan and EGL ICDs, to enumerate graphics drivers and populate the
    cache in parallel with any other container setup. We join the threads
    just before looking at their results, to maximize the length of time
    for which we're running in parallel.
    
    On slow hardware (Lenovo T520 circa 2011, with 500G 7200rpm HDD) this
    cuts something like 20% off the setup time with a cold cache
    (`echo 3 | sudo tee /proc/sys/vm/drop_caches`). It also has a benefit
    (more like 15%) with a warm cache, immediately after a previous
    pressure-vessel run.
    
    This does make it somewhat harder to profile pressure-vessel, because
    when two I/O-bound operations run in parallel, they both take longer
    than they otherwise would, even though the overall task finishes sooner;
    this makes it hard to attribute I/O cost to particular actions. The
    new --single-thread option can be used to get a better idea of where
    the time is really going.
    
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
    94699abd
    History
    pv-runtime: Use threads to enumerate graphics drivers in parallel
    Simon McVittie authored
    
    SrtSystemInfo is not thread-aware, but can safely be handed off from
    one thread to another, and caches its results internally; so we can use
    a thread per architecture, plus an extra thread for cross-architecture
    Vulkan and EGL ICDs, to enumerate graphics drivers and populate the
    cache in parallel with any other container setup. We join the threads
    just before looking at their results, to maximize the length of time
    for which we're running in parallel.
    
    On slow hardware (Lenovo T520 circa 2011, with 500G 7200rpm HDD) this
    cuts something like 20% off the setup time with a cold cache
    (`echo 3 | sudo tee /proc/sys/vm/drop_caches`). It also has a benefit
    (more like 15%) with a warm cache, immediately after a previous
    pressure-vessel run.
    
    This does make it somewhat harder to profile pressure-vessel, because
    when two I/O-bound operations run in parallel, they both take longer
    than they otherwise would, even though the overall task finishes sooner;
    this makes it hard to attribute I/O cost to particular actions. The
    new --single-thread option can be used to get a better idea of where
    the time is really going.
    
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
graphics-provider.h 2.59 KiB
/*
 * Copyright © 2020-2021 Collabora Ltd.
 *
 * SPDX-License-Identifier: LGPL-2.1-or-later
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library. If not, see <http://www.gnu.org/licenses/>.
 */

#pragma once

#include <glib.h>
#include <glib-object.h>

#include "steam-runtime-tools/glib-backports-internal.h"
#include "libglnx/libglnx.h"

#include <steam-runtime-tools/steam-runtime-tools.h>

typedef struct _PvGraphicsProvider PvGraphicsProvider;
typedef struct _PvGraphicsProviderClass PvGraphicsProviderClass;

struct _PvGraphicsProvider
{
  GObject parent;

  /* All members are read-only after initable_init(), which means it's
   * OK to access this object from more than one thread. */
  gchar *path_in_current_ns;
  gchar *path_in_container_ns;
  gchar *path_in_host_ns;
  int fd;
};

struct _PvGraphicsProviderClass
{
  GObjectClass parent;
};

#define PV_TYPE_GRAPHICS_PROVIDER (pv_graphics_provider_get_type ())
#define PV_GRAPHICS_PROVIDER(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), PV_TYPE_GRAPHICS_PROVIDER, PvGraphicsProvider))
#define PV_GRAPHICS_PROVIDER_CLASS(cls) (G_TYPE_CHECK_CLASS_CAST ((cls), PV_TYPE_GRAPHICS_PROVIDER, PvGraphicsProviderClass))
#define PV_IS_GRAPHICS_PROVIDER(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), PV_TYPE_GRAPHICS_PROVIDER))
#define PV_IS_GRAPHICS_PROVIDER_CLASS(cls) (G_TYPE_CHECK_CLASS_TYPE ((cls), PV_TYPE_GRAPHICS_PROVIDER))
#define PV_GRAPHICS_PROVIDER_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS((obj), PV_TYPE_GRAPHICS_PROVIDER, PvGraphicsProviderClass)
GType pv_graphics_provider_get_type (void);

PvGraphicsProvider *pv_graphics_provider_new (const char *path_in_current_ns,
                                              const char *path_in_container_ns,
                                              GError **error);

gchar *pv_graphics_provider_search_in_path_and_bin (PvGraphicsProvider *self,
                                                    const gchar *program_name);
SrtSystemInfo *pv_graphics_provider_create_system_info (PvGraphicsProvider *self);

G_DEFINE_AUTOPTR_CLEANUP_FUNC (PvGraphicsProvider, g_object_unref)