Potential HD Mouse Extensions API Specification [ETA by 2025]

Talk to software developers and aspiring geeks. Programming tips. Improve motion fluidity. Reduce input lag. Come Present() yourself!
User avatar
Chief Blur Buster
Site Admin
Posts: 9059
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Post by Chief Blur Buster » 26 Nov 2020, 04:31

Chief Blur Buster wrote:
08 Nov 2020, 00:49
Possible Proposals For Software Processing

This is what becomes visible to software that wants to access the new HD Mouse API.

- The HD Mouse API would have metrics to inform the game (sensor rate, poll rate, DPI, etc)
- The HD Mouse API would provide full precision information either as integers or as floating point
- The HD Mouse API provides optional poll batching to reduce system load
- The HD Mouse API can fire additional events for special events (DPI changed, mouse lifted from surface, etc)
- The HD Mouse API can have API-accessible configurability such as poll batching, smoothing ON/OFF, smoothing-vs-lag windows,
- The HD Mouse API will include floating point timestamps (double) or monotonically increasing timestamps (no less accurate than 1 microsecond accurate) for each coordinate pair and button events, with timestamps recorded at sensor level.
- The HD Mouse API will inform application where the timestamps came from (sensor side versus driver side), to allow applications to trust the integrity of the timestamps.
- The game would handle the data as it wishes, ideally with:
......Separate sensitivity adjustment for mouse pointer for menus/inventory/etc
......Separate sensitivity adjustment for mouse turns
......Separate sensitivity adjustment for scopes
Sensitivity adjustment MUST (RFC2119) have at least 4 decimal digits, as explained at HOWTO: Please Future Proof your Game Engine
New addendum added.

(It could be as simple as an enum (like a theoretical .timeStampOrigin = TIMESTAMP_SENSORSIDE). The actual spelling of the function calls / parameters / variables / enums for HD Mouse API is still TBD, this will be discussed towards creating an actual draft specification some future year between 2021-2025, hopefully sooner)

The first HD Mouse API capable mouse will probably not be providing sensor-side timestamps just quite yet, and the HD Mouse API may be incubated on existing mice via the backwards compatible method (aka "1. Mouse Side: Pure HID Protocol Only").
  • The app deserves to know where timestamps comes from.
  • Sensor side timestamps is strongly RECOMMENDED, as the mouse SHOULD transmit that data to the mouse driver where possible for incorporation into the HD Mouse API.
  • Sensor-side timestamps MAY choose to use exact precomputed increments (defined constant) during continuous sensor readouts running at accurate fixed Hz.
  • Sensor-side timestamps MAY alternatively be derived from the monotonically increasing high performance counter on the mouse's microcontroller, especially if sensor frequency is variable.
  • Sensor-side timestamps MUST have less than 1 microsecond timing error, regardless of how the sensor-side timestamp is computed.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

schizobeyondpills
Posts: 85
Joined: 06 Jun 2020, 04:00

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Post by schizobeyondpills » 26 Nov 2020, 07:58

O_O wrote:
25 Nov 2020, 23:41
schizobeyondpills wrote:
14 Nov 2020, 15:53
Looking at raw input windows API, both GetRawInput and GetRawInputBuffer functions have a syscall overhead.
Syscall is supposed to be fast. Don't know why you mention context switching as it's not used by Sycall instruction.

For me a GetRawInputData for mouse call takes around 4200 cycles once it's busy which should be less than a microsecond on typical CPU's of today. Do note though that this call normally needs to be registered first by the program wanting to receive such notifications then called once a windows message says there's data available. So there's delay for that then even with 8000Hz polling the data might be over 100us old from the mouse itself, add some driver delay of 5 or 8us then the OS handling all before a program is notified there's some new mouse data and the Syscall seems negligible.

8000Hz USB polling can result in lost reports from the OS especially if using idle states, but not because of a GetRawInputData Syscall since that doesn't even come until there's notification of data to be had.
instead of saying stuff without claims why not show us some measures? :lol:

its always the same "nothing matters" keywords

"supposed to be fast"
"negligible"
"should be less than a microsecond"

so. since you measured it why not come with measures and reply with that instead of random fog guesses?


looking forward to your asm instrumentation of the os and kernel and measuring of those "4200" cycles * 8000 = 33600000 cycles.

waiting for your measures and source how you got them to make sure they are valid.

O_O
Posts: 19
Joined: 26 Oct 2020, 06:19

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Post by O_O » 27 Nov 2020, 01:03

schizobeyondpills wrote:
26 Nov 2020, 07:58
instead of saying stuff without claims why not show us some measures? :lol:

its always the same "nothing matters" keywords

"supposed to be fast"
"negligible"
"should be less than a microsecond"

so. since you measured it why not come with measures and reply with that instead of random fog guesses?
The 4200 cycles was a measurement. I'm running old hardware @3GHz with patches for vulnerabilities, users with newer hardware and faster clocks should get below 1us. How much so will depend on their setup, why does this seem a random fog guess? I would also say a formula 1 racing car is supposed to be fast for cars, do I need to prove it to. While you may consider those statements as "nothing matters" keywords, I certainly didn't say "nothing matters" rather that you would be better off looking elsewhere for improvements before even considering the syscall itself.

Why haven't you written your own code to test syscall? Here's a snippit that uses a pretty basic function so that the windows syscall, setup code and return are mostly what are measured. Don't expect it to work in older Windows or perhaps even earlier W10.

Code: Select all

        call    [__win32kstub_NtGdiGetSpoolMessage]
        cmp     eax,0
        je      exit
        bts     eax,12
        mov     ebx,eax
        xor     eax,eax
        mov     [RawCount],rax
        mov     [Begin],rax
        mov     [StartCount],rax
        mov     eax,ebx                 ; NtGdiGetSpoolMessage syscall number
        mov     r10,rcx                 ; Not needed for this call
        syscall                         ; Warm up run
        rdtscp
        shl     rdx,32
        or      rax,rdx
        mov     [Begin],rax
 again:
        rdtscp
        shl     rdx,32
        or      rax,rdx
        mov     [StartCount],rax
        xor     ecx,ecx
        mov     eax,ebx
        mov     r10,rcx
        syscall
        rdtscp
        shl     rdx,32
        or      rax,rdx
        sub     rax,[StartCount]
        mov     rdi,rax
        inc     [RawCount]
        cmp     [RawCount],1000000      ; 1 Million tests
        jb      again
        rdtscp
        shl     rdx,32
        or      rax,rdx
        sub     rax,[Begin]
        xor     edx,edx
        mov     rcx,[RawCount]
        div     rcx
        lea     rcx,[Buff]
        lea     rdx,[wsCycles]
        mov     r8,rdi
        mov     r9,rax
        shr     r8,1                    ; Convert to ns (using 2GHz base clock)
        shr     r9,1                    ;
        call    [wsprintf]
        xor     rcx,rcx
        lea     rdx,[Buff]
        lea     r8,[Result]
        xor     r9,r9
        call    [MessageBox]
exit:
Image
Once again at 3GHz so expect sub 300ns for some better systems. And yes, the timestamp acquisition is part of that measurement.

User avatar
Chief Blur Buster
Site Admin
Posts: 9059
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Post by Chief Blur Buster » 28 Nov 2020, 00:22

O_O wrote:
27 Nov 2020, 01:03
Once again at 3GHz so expect sub 300ns for some better systems. And yes, the timestamp acquisition is part of that measurement.
Good data evidence. Thanks!

syscall is "expensive" but manageable on many systems; as long you don't have dozens of USB devices chattering syscall's around all the time.

There's lots more other jitter noise to worry about in the refresh rate race to retina refresh rates. There's a big laundry list of whac-a-moles to do in internal system jitter.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

User avatar
lyrill
Posts: 194
Joined: 06 Oct 2020, 10:37

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Post by lyrill » 28 Nov 2020, 08:59

yeah a lot of newbies tend to not stick to one main mouse and have like 3 to a dozen mice hanging around all over their mouse pad or desk, and in recent 3 years especially a lot of wireless bs, and that's just mouse. where as I have not for at least 5 years had more than 1 keyboard/ 1 mouse and a usb audio device if/when I am not using optical audio, and when and only when I do mostly, I also put on portable hard drives for movies and music, aka not gaming. so for gaming just 3 usb 2.0 device. clean and simple.

O_O
Posts: 19
Joined: 26 Oct 2020, 06:19

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Post by O_O » 30 Nov 2020, 05:11

Chief Blur Buster wrote:
28 Nov 2020, 00:22
syscall is "expensive" but manageable on many systems;
As stated that result was with mitigation's (Meltdown...). With W10 1703 and no mitigation's the same HW and clocks produce
Image

Result perhaps similar to
Image
https://twitter.com/cpugoogle/status/12 ... 6322398208

User avatar
Chief Blur Buster
Site Admin
Posts: 9059
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Post by Chief Blur Buster » 30 Nov 2020, 21:21

Yeah, the Meltdown/Spectre mitigation stuff was bad for jitter/latency. It's part of why I'm a fan of timestamping at the mouse sensor level, to allow the software to have the choice to dejitter mouse samples. Some of us prioritize on smoothness.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

Hotdog Man
Posts: 5
Joined: 01 Dec 2020, 13:35

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Post by Hotdog Man » 12 Dec 2020, 20:46

Chief Blur Buster wrote:
30 Nov 2020, 21:21
Yeah, the Meltdown/Spectre mitigation stuff was bad for jitter/latency. It's part of why I'm a fan of timestamping at the mouse sensor level, to allow the software to have the choice to dejitter mouse samples. Some of us prioritize on smoothness.
Will the mitigations still need to be applied on Rocket Lake's Cypress Cove architecture? Might be a case for better mouse response on the new gen CPU's.

User avatar
kurtextrem
Posts: 41
Joined: 05 Mar 2017, 03:35
Location: Munich, Germany

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Post by kurtextrem » 18 Dec 2020, 05:19

Hotdog Man wrote:
12 Dec 2020, 20:46
Chief Blur Buster wrote:
30 Nov 2020, 21:21
Yeah, the Meltdown/Spectre mitigation stuff was bad for jitter/latency. It's part of why I'm a fan of timestamping at the mouse sensor level, to allow the software to have the choice to dejitter mouse samples. Some of us prioritize on smoothness.
Will the mitigations still need to be applied on Rocket Lake's Cypress Cove architecture? Might be a case for better mouse response on the new gen CPU's.
Tiger Lake works faster with mitigations *on* and slower with them disabled (https://www.phoronix.com/scan.php?page= ... ions&num=1). This probably means Intel & AMD optimize their chips with security enabled (the same has been found on Zen3 on Windows, not on Linux though, if this benchmark is correct: https://youtu.be/0oL-SedTy8Y?t=292, Linux: https://www.phoronix.com/scan.php?page= ... ctre&num=4).
Acer XF250Q, R6 competitive player

griffin1987
Posts: 1
Joined: 18 Dec 2020, 07:43

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Post by griffin1987 » 18 Dec 2020, 07:48

Would there be a way to reverse everything to use push instead of poll? Like freesync/g-sync kinda does it for monitors.
This could also lead to power savings which could be relevant for mobile users.
The mouse would just send movement or clicks when they happen, up to x hz.
Could also potentially reduce load on the system.
I think the old ps/2 connection did it in a similar way using interrupts.
Not sure how compatible this would be with current usb protocols or if async usb mode would help with that.

Sorry if what I'm asking/suggesting is BS, just registered here because I thought this could be a good idea and wanted to post it here.

Best

Post Reply