Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • L libglvnd
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 25
    • Issues 25
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 8
    • Merge requests 8
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • glvnd
  • libglvnd
  • Merge requests
  • !228

Open
Created Jun 16, 2020 by Kyle Brenneman@kbrennemanOwner
  • Report abuse
Report abuse

Draft: Config file format for GPU offloading

  • Overview 10
  • Commits 27
  • Pipelines 3
  • Changes 36

This adds a config file format for the GPU offloading interface in !224.

With this, the app profile library will read config files in a couple directories to find the app profile data for the current process. The app profile library itself provides the same interface, so the format (or even existence) of the config files is opaque to the rest of libglvnd. And since this all gets called from libglvnd, it will work regardless of which window system or desktop environment (or lack thereof) you happen to be using.

It'll also work correctly with things like Steam, where just having the desktop environment set an environment variable would not work.

The format I've defined here is TOML-based. I picked that because it's easy to parse, easy to extend, and is human- or machine-editable. The array-of-tables syntax also makes defining a list of profiles pretty clean.

Each config file can define a list of profiles, and the parser will search until it finds one that matches the current process. The profile can then have a list of device ID's that get handed back to EGL/GLX/Vulkan. The device ID's are strings in the format of vendor_name/device_uuid, just like you'd pass with the environment variable.

Currently, the parser can match a profile based on the API name and based on the value in /proc/self/exe and /proc/self/comm. The match rules are structured so that we can add new ones without breaking compatibility, too. Off the top of my head, we'll probably want something that could be used with programs running through Wine or an interpreter.

In addition to using a specific device name, a profile can also use a symbolic alias. In that case, the same config files can define a device ID for that alias. The reason for the alias feature is so that users (or distros or drivers or whoever) can define a profile for an application with a generic category like "performance", without having to know what the specific hardware configuration is going to be. Then, a config file can define which device is the "performance" device using whatever policy you want. A user could define an alias manually, or you could have a program generate a config file at startup or in response to hotplug events.

Edited Apr 05, 2022 by Kyle Brenneman
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: app-profile-library-parser