Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • A amd
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 349
    • Issues 349
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • drm
  • amd
  • Issues
  • #1740
Closed
Open
Issue created Oct 11, 2021 by Plagman@Plagman

Performance issue with test flips

In gamescope we try to use planes when possible - to that end, different test flips are issued by liftoff to figure out if the current configuration is flippable through planes or not. If not, we fall back to a compositing path. At this point we are trying to get a frame on screen, so time is of the essence.

Currently when the cursor is on screen on Deck, we fall back to compositing for various reasons. This currently seems to involve five test commits prior to falling back from liftoff before we give up, and one after, to confirm we can flip our composited full-screen buffer.

For a sample frame here are the duration of said test commits: 1.32ms, 0.11ms, 0.21ms, 0.08ms, 0.04ms, and 0.16ms for the sixth post-compositing test commit.

These are measured on an otherwise idle Zen2 CPU core, using the 'performance' governor to achieve consistency for the purpose of this report.

This means burning 1.82ms of CPU before we can even be sure we need to composite, which is quite unexpected. The first test commit is consistently 1ms+, but even the other numbers seem high, including 0.16ms for the final single-plane commit that is essentially designed to be a perfect fit for the current mode.

Screenshot_20211010_232441-1

This is using a kernel based off of latest amd-staging-drm-next and can be reproduced by running a lightweight game (here Deedlit in Wonder Labyrinth) and wiggling the cursor on a Deck devkit while it's running.

Assignee
Assign to
Time tracking