Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refresh-rate ignored with experimental-backends #173

Closed
Ristovski opened this issue May 15, 2019 · 11 comments
Closed

refresh-rate ignored with experimental-backends #173

Ristovski opened this issue May 15, 2019 · 11 comments
Labels
not a bug Not really a bug wontfix

Comments

@Ristovski
Copy link

Ristovski commented May 15, 2019

When enabling --experimental-backends the refresh-rate config option seems to be ignored under the glx backend.

Compton v6, master

@yshui
Copy link
Owner

yshui commented May 16, 2019

This is intended. Also sw-opti is on deprecation track as well.

@yshui yshui closed this as completed May 16, 2019
@yshui yshui added not a bug Not really a bug wontfix labels May 16, 2019
@Ristovski
Copy link
Author

Does this mean glx will not support anything but vsync in the future?

@yshui
Copy link
Owner

yshui commented May 16, 2019

@Ristovski Yes. But there is nothing else to support in regard to this. refresh-rate and sw-opti were hacks for cases when vsync doesn't work, which has become less relevant.

@morgoth6
Copy link

To be honest this bothers me a little too, but I assumed this can be change with new backend rework a forget about it. This was tested on Precision 5510 (optimus intel&nvidia) in modesetting mode using i3 desktop.

When I run glxgears without compton it shows me 60fps as expected with ~8% CPU utilization:

303 frames in 5.0 seconds = 60.508 FPS
300 frames in 5.0 seconds = 59.933 FPS`

But with compton (both regular and experimental GLX backend's with vblank&damage enabled) it takes ~20% CPU and shows:

5829 frames in 5.0 seconds = 1165.633 FPS
5936 frames in 5.0 seconds = 1187.190 FPS

And fun part I give a try to experimental xrender backend and it takes ~12% CPU and shows:

604 frames in 5.0 seconds = 120.776 FPS
601 frames in 5.0 seconds = 120.055 FPS

Using old compton I was able to get normal 60fps using swc and glx-swap-method=3 (funny this is only swap-method which works here in original compton version)

For reference:

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 2048 MB
    Total available memory: 2048 MB
    Currently available dedicated video memory: 1903 MB
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro M1000M/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 430.09
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6.0 NVIDIA 430.09
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)

OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 430.09
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20`
**Version:** v6

### Extensions:

* Shape: Yes
* XRandR: Yes
* Present: Present

### Misc:

* Use Overlay: Yes
* Config file used: /home/morgoth/.config/compton.conf

### Drivers (inaccurate):

modesetting

I wonder as I can see "modesetting" in driver is automatic nvidia quirks introduced recently are applied ?

@Ristovski
Copy link
Author

@yshui My point is, the old glx backend allows for setting a higher refresh-rate which get's rid of "input lag" while allowing to cap it to something sane like 120fps.

The only other way I can think of doing the same thing under the new backend is to run compton with vblank_mode=0 and then limit the fps with libstrangle or some other mechanism. Quite inefficient.

@Ropid
Copy link

Ropid commented May 18, 2019

@morgoth6:

This isn't the case here for me. The glxgears program always runs at 60fps, no matter if compton is running or not, and no matter what backend I try.

Perhaps you are doing something to the vblank_mode mesa setting in a script you use to start Compton?

@yshui
Copy link
Owner

yshui commented May 18, 2019

@Ristovski That is not the proper way to solve the input lag.

@Ristovski
Copy link
Author

@yshui It might not be, but it was a nice "workaround" that was simple enough. Do you know of a different way to solve it?

@yshui
Copy link
Owner

yshui commented May 20, 2019

@Ristovski It's anything but simple.

I am working on the input lag, see #147

@Cat-Lady
Copy link

I would like to point out that ability to limit framerate to arbitrary number is direly missed feature, for other use cases - like, streaming the desktop remotely via encoded video stream (steam link-alike), where strangling the FPS have gigantic effect on network bandwidth required.

Sure - ideally, streaming software would allow to set the framerate itself - but in cases where it does not, this is a huge and disappointing regression.

@Shringe
Copy link

Shringe commented Aug 23, 2024

Vsync works very poorly on multi-monitor setups with X11, is there any chance this feature is ever coming back?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not a bug Not really a bug wontfix
Projects
None yet
Development

No branches or pull requests

6 participants