Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
M
mutter
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 268
    • Issues 268
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 70
    • Merge Requests 70
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Registry
    • Registry
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards

Getting colder with our second freeze... it's 3.31.91 release day and string freeze, upload a tarball and lock those strings 🏂

  • GNOME
  • mutter
  • Merge Requests
  • !313

Merged
Opened Nov 16, 2018 by Pekka Paalanen@ppaalanen
  • Report abuse
Report abuse

Try to avoid converting twice in Cogl read-pixels

These patches are a result of trying to make the CPU copy path faster for GPU-less secondary GPUs (DisplayLink devices). !278 (merged) makes the CPU copy path use Cogl read-pixels instead of a simple glReadPixels, and this MR tries to make Cogl read-pixels faster. There is no practical dependency to !278 (merged) though, this MR could benefit other Cogl read-pixels users too although I have no benchmarks of those.

The main goal here is to get as close to a pure memcpy in the actual glReadPixels call as possible, assuming that that will be the fastest. That can never be completely achieved if the read buffer has an X-channel instead of an alpha channel, because there does not seem to be way to tell glReadPixels that it can leave garbage in the A/X-channel. However, I think this MR is still a worthwhile step towards that goal even if it doesn't have immediate effects.

If one can arrange the read buffer format and the Cogl read-pixels destination buffer format to match, then the read-pixels function as a whole should be a simple non-converting copy. This was thwarted by two things, fixed by the two patches: an old workaround for GL_BGRA reads, and a hardcoded intermediate pixel format that may not match either the read or destination formats. Both things lead to the same: glReadPixels does one pixel format conversion, and then Cogl read-pixels does another conversion on the CPU.

On an Intel Haswell Desktop machine, doing a read of 1080p frame, read buffer is DRM_FORMAT_XRGB8888:

  • destination format DRM_FORMAT_XBGR8888, before and after: 5.8 ms
  • destination format DRM_FORMAT_XRGB8888, before 12 ms, after 9.0 ms

The destination format is currently hardcoded to DRM_FORMAT_XBGR8888 in Mutter, but I intend to change that by looking at IN_FORMATS DRM property instead, hence this optimization will likely become relevant in the CPU copy path.

If I hack the read buffer format to be DRM_FORMAT_ARGB8888 and the destination format is DRM_FORMAT_XRGB8888, the copy will take just 4.0 ms.

However, the hack broke the display of primary GPU outputs by never showing anything but a frozen image of fbcon, and I do not yet know why. I also do not know if a GBM bo could be used in scanout and as a source for the CPU copy path at the same time, so I decided to stop here with the read-pixels optimizations for now and look for other alternatives. I am still interested in the read-pixels path, because it will be the fallback path if other future options fail.

Edited Dec 13, 2018 by Pekka Paalanen
  • Discussion 11
  • Commits 2
  • Pipelines 5
  • Changes 3
Assignee
No assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
2
Labels
1. Feature 5. Cogl
Assign labels
  • View project labels
Reference: GNOME/mutter!313