Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • xserver xserver
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 887
    • Issues 887
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 105
    • Merge requests 105
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & 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
  • xorg
  • xserverxserver
  • Issues
  • #631
Closed
Open
Created Jan 29, 2019 by Niklas Haas@haasn

XWayland broken vsync frequency

Problem description

When running any GLX, EGL or Vulkan application under XWayland, I observe a very wrong vsync interval:

glxgears:

296 frames in 5.0 seconds = 59.085 FPS
293 frames in 5.0 seconds = 58.396 FPS
292 frames in 5.0 seconds = 58.390 FPS
293 frames in 5.0 seconds = 58.547 FPS

vulkan demo:

289 frames in 5003 ms = 57.765339 FPS
290 frames in 5015 ms = 57.826519 FPS
289 frames in 5012 ms = 57.661613 FPS
289 frames in 5005 ms = 57.742256 FPS
289 frames in 5001 ms = 57.788441 FPS

It's worth pointing out that the OpenGL results and the Vulkan results are different, consistently so. I get the same measured refresh rate (~58.4 Hz) in other opengl applications (such as mpv), and the same ~57.7 Hz refresh rate in other vulkan applications (again, such as mpv). I have no idea why. This is also consistent across compositors, with both sway (wlroots) and weston I get the same two measured vsync frequencies. Visually, the result stutters a lot - it seems that there are about 1-2 missed vsyncs per second, consistent with the measured results.

When running Xorg natively (via xf86-video-amdgpu), I get the expected results:

glxgears:

300 frames in 5.0 seconds = 59.995 FPS
300 frames in 5.0 seconds = 59.995 FPS
300 frames in 5.0 seconds = 59.998 FPS
300 frames in 5.0 seconds = 59.995 FPS
300 frames in 5.0 seconds = 59.997 FPS

vulkan demo:

301 frames in 5016 ms = 60.007973 FPS
301 frames in 5017 ms = 59.996014 FPS
301 frames in 5017 ms = 59.996014 FPS
301 frames in 5017 ms = 59.996014 FPS
298 frames in 5017 ms = 59.398048 FPS

XRandR output

xorg native:

Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384
DisplayPort-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
  3840x2160     60.00*+  29.98  
  2560x1440     59.95  
  2048x1280     60.20  
  2048x1152     60.00  
  1920x1200     59.88  
  2048x1080     24.00  
  1920x1080     60.00    60.00    50.00    59.94    24.00    23.98  
  1600x1200     60.00  
  1680x1050     59.95  
  1280x1024     75.02    60.02  
  1440x900      60.00  
  1280x800      59.81  
  1152x864      75.00  
  1280x720      60.00    50.00    59.94  
  1024x768      75.03    60.00  
  800x600       75.00    60.32  
  720x576       50.00  
  720x480       60.00    59.94  
  640x480       75.00    60.00    59.94  
  720x400       70.08  
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)

via XWayland:

Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 8192 x 8192
XWAYLAND0 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
 3840x2160     59.98*+

It's interesting to note that this also has a wrong refresh rate (59.98 Hz), however much closer to the true value (60 Hz).

System information

  • kernel: Linux xor 4.20.5-gentoo #1 (closed) SMP PREEMPT Sun Jan 27 05:25:39 CET 2019 x86_64 AMD Ryzen Threadripper 1950X 16-Core Processor AuthenticAMD Linux
  • mesa: git 86e5f76d3d5a5608861813c051af2af4c075e814
  • xf86-video-amdgpu: git 9045fb310f88780e250e60b80431ca153330e61b
  • xorg: 1.20.3
  • weston: be57857af656171706f05a03f56db239d0b590d9 with wayland/weston!62 (closed) applied
  • wlroots: 0.2

This may or may not be a duplicate of bug 106700, but the author mentions that this one is apparently solved?

Edited Jan 29, 2019 by Niklas Haas
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking