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

Already on GitHub? Sign in to your account

Mouse delay in Primus Bridge #503

Closed
botpl opened this Issue Nov 17, 2013 · 5 comments

Comments

Projects
None yet
4 participants

botpl commented Nov 17, 2013

hi
i'm using Ubuntu 13.04 Kernel 3.12 on my lenovo y570 with GTX555m (Nvidia 331) 8GB of ram an i7 Processor
bumblebee works great and primus have better performance than virtualgl but there is one fatal flaw, when i run by virtualgl everything expect fps is fine and dandy
but when i ran through primus i found that it has slight mouse delay that irritates me a lot. i tried various configurations for bumblebee.conf but any of them worked with primus. Is there any workaround about mouse delay with primus? 'cause its very noticable

Contributor

amonakov commented Nov 17, 2013

What games are problematic? Is desktop compositor active when you play?

Please provide logs from PRIMUS_VERBOSE=2 optirun -b primus.

Owner

ArchangeGabriel commented Apr 2, 2014

No answer, closing.

emilis commented Jun 1, 2014

I think I have this too. It is rather noticable and I am unable to play games competitively.

  • OS: Ubuntu 13.10
  • kernel: 3.11.0-22-generic #38-Ubuntu SMP Thu May 15 20:47:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
  • optirun (Bumblebee) 3.2.1
  • nvidia-current: Version: 304.88-0ubuntu8

I have explicitly turned off compositing.

Log from running sauerbraten:

$ PRIMUS_VERBOSE=2 optirun -b primus sauerbraten
Using home directory: /home/emilis/.sauerbraten
init: sdl
init: net
init: game
init: video: mode
init: video: misc
init: gl
Renderer: NVS 5400M/PCIe/SSE2 (NVIDIA Corporation)
Driver: 4.2.0 NVIDIA 304.88
Rendering using the OpenGL assembly/GLSL shader path.
init: console
init: gl: effects
init: world
init: sound
init: cfg
init: mainloop
primus: profiling: display: 60.3 fps, 0.5% wait, 18.2% upload, 81.3% draw+swap
primus: profiling: readback: 60.6 fps, 0.4% app, 27.4% map, 72.3% wait
primus: profiling: display: 60.1 fps, 0.0% wait, 18.2% upload, 81.8% draw+swap
primus: profiling: readback: 60.1 fps, 3.4% app, 29.7% map, 66.9% wait
primus: profiling: display: 60.1 fps, 0.0% wait, 20.7% upload, 79.3% draw+swap
primus: profiling: readback: 60.1 fps, 48.2% app, 36.0% map, 15.8% wait
primus: profiling: display: 60.1 fps, 0.0% wait, 18.2% upload, 81.8% draw+swap
primus: profiling: readback: 60.0 fps, 65.8% app, 34.2% map, 0.0% wait
primus: profiling: display: 60.1 fps, 27.5% wait, 15.2% upload, 57.3% draw+swap
primus: profiling: readback: 60.0 fps, 64.9% app, 35.0% map, 0.1% wait
primus: profiling: display: 60.0 fps, 76.6% wait, 15.1% upload, 8.3% draw+swap
primus: profiling: readback: 60.0 fps, 65.7% app, 34.1% map, 0.2% wait

xorg.conf.nvidia:

Section "ServerLayout"
    Identifier  "Layout0"
    Option      "AutoAddDevices" "false"
    Option      "AutoAddGPU" "false"
EndSection

Section "Device"
    Identifier  "DiscreteNvidia"
    Driver      "nvidia"
    VendorName  "NVIDIA Corporation"
    BusID "PCI:01:00:0"
    Option "ProbeAllGpus" "false"

    Option "NoLogo" "true"
    Option "UseEDID" "false"
    Option "UseDisplayDevice" "none"
EndSection

# For some reason this is ignored:
Section "InputClass"
    Identifier "My Mouse"
    MatchIsPointer "yes"
    Option "AccelerationProfile" "-1"
    Option "AccelerationScheme" "none"
EndSection

# Had to use this to tweak mouse acceleration:
Section "InputDevice"
    Identifier  "Mouse0"
    Driver      "mouse"
    Option      "Protocol" "auto"
    Option      "Device" "/dev/input/mice"
    Option      "ZAxisMapping" "4 5 6 7"

    Option      "AccelerationScheme" "none"
    Option      "AccelerationProfile" "-1"
EndSection

# Explicitly disabled compositing:
Section "Extensions"
    Option      "Composite" "Disable"
EndSection

emilis commented Jun 1, 2014

It seems I found a solution: vblank_mode=0 did the trick for me.

No idea what is causing the problem, though.

Contributor

amonakov commented Jun 1, 2014

Presentation latency in primus is not ideal; PRIMUS_SYNC=1 gives a good compromise when vsync is enabled, but vblank_mode=0 (vsync disabled) is of course more efficient for input lag mitigation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment