Blur Busters Forums

Also, a better idea is lose the receive parts of the sensor, let it just emit, lose those excessive lens bs(mixing up output emission with input receiving---I'm watching you all 3399 ads department). No it's still pretty terrible vs laser, and I've got my dirty 3090 lens on my AM-FG to prove it. Basically hasn't changed much, all but old tech. (laser has 2 spherical vs 1 usually on optical, so what, that doesn't make laser harder to clean, at least there's 2 proper lens for each job, and don't lecture me on the specifics I shouldn't have to take a course to have a say on what should have been from an end user perspective)

let the mouse pad do the receive job (in fact the mouse pad name is pretty laughable, selling cloth deskmats were sure sign things went too far on the negative iq side), as stated with cord, now if it's still required to use cord on mouse to send back "switches" register info, sure, but at least you can decrease the cord thickness at its core, cus now u doing less work there, and also without the receiving bits hogging battery if going wireless you can now have a lighter mouse too.....but maybe think about how the mouse has been around with "switch" for too long, maybe lose the idea completely. those "office " mice gamers love to frown on, all of Logitech was based on that, and of course all those other brands that make "mice'' for "productivity", of course Microsoft, Apple and all the rest.... because it IS just a peripheral.......it's SUPPOSED to come with a pc.....like a stylus is supposed to come with an ipad..... REALLY just Rethink PCMR, like, come on.

on the top side, likely with glass if we are still sticking with optics (just need to use certain emission that pierces the surface without any bs) then have the receiving panel on the bottom, shouldn't be too hard to implement......

the idea is just to lose as much frivolous bs on mice as possible, the whole lod thing is also heavily related to this but I really care not to delve deeper if nobody even cares to begin to talk about any of it. But it really is pretty obvious if you care/know then you know. The depth is all on the glass/retina bottom now-------in fact just make a big sensor screen, don't tell me how costly it can be i don't care--- the cutoff is dictated by the pad, in fact glass pads don't wear out anyways, super easy to clean, pretty sure can tailor sensor just fine in accordance with glass passthrough and sensor pad receive, pretty sure that the surface can now exclusively focus/worry about glide perf maximization/perfection which would be catapulted immensely and if you are worried about pfte residue blocking the sensor pad receiving in anyway (as if you weren't supposed to be worried about pfte residue and general dust grime changing the imaging of current/previous pads.....especially cloth pads that gets smeared easily and gets permanent/near-nonewashable alterations easily), just use a darn lexip....



this obviously rules cloth or any other none transparent/bad transparency stuff out (depending on what kind of emission wave i guess????) I mean if you talk about haptic, sound is a kind of wave too lol.


You know you don't really get to call a mouse sensor a sensor without the receiving bits at all.

Also project Mcfly. Curved mouse pads for full analog ergonomics. VR. All worth pondering about.

schizobeyondpills wrote: ↑

13 Nov 2020, 02:55

For API/software/driver side of things it should try to be something like io_uring is in linux

https://lwn.net/Articles/810414/
https://unixism.net/loti/what_is_io_uring.html

Because of the shared ring buffers between the kernel and user space, io_uring can be a zero-copy system. Copying bytes around becomes necessary when system calls that transfer data between kernel and user space are involved. But since the bulk of the communication in io_uring is via buffers shared between the kernel and user space, this huge performance overhead is completely avoided.

also i believe few things are a MUST such as
- adjusting affinity of mouse input usermode thread/driver
- adjusting priority of mouse input usermode thread/driver
- "idle off" mouse input thread (highest priority/can't be out-scheduled), maybe even completely isolate a CPU core for mouse only input (not even interrupts/drivers/DPCs get scheduled at that isolated mouse CPU core)
- adjusting DPC/ISR priority of mouse/driver

Pretty reasonable request, though it may have to be an advanced mouse utility (like a mouse PowerToy for advanced users). For me, I’m more smoothness-priority over latency-priority, but that’s why I included both audiences.

As for io_uring, it definitely should inspire the behind-the-scenes, even if we can’t really symmetrically map that because of the dramatic differences of WIndows vs Linux — and the need for something that is easy for manufacturers to implement as simpler pre-existing-API extensions. For example, the first HD Mouse API may not be able to involve Microsoft, and thus, we’ll still be bethrothen to the way WIndows processes USB (at least intially). But the HD Mouse API should be also amenable to allowing backend improvements much like io_uring does.

Oh, yes — rIng buffers.... They also need to be big enough for 8000Hz.

<Aside>
The seemingly arbitrarily-capped size buffer for the PointerEvents array in Chrome is the only real reason why 8000Hz isn’t working as well as 1000Hz. It successfully grabs long chains of consecutive 8000Hz’s and then overflows, creating dropouts between successful consecutive 0.125us poll chains. Relevant to the HD Mouse API topic, the polling in HTML5 isn’t JavaScript-bottlenecked because the HTML5 implementation of polling is a PointerEvents array (which is already microsecond timestampped with floating point timestamps accompanying mouse deltas) — it is why the mouse can be reliably rawinput benchmarked at 1000Hz in JavaScript because I can just analyze the array without being fuzzed by JavaScript performance. The only problem is limited buffer size between JavaScript analyses! A one-line code change fixes Chrome’s compatibility for 8000Hz mice, apparently. Hopefully I can convince the Chromium team, or even do a commit myself. And a HD Mouse API’s “poll batching feature” is a nice synergestic map to array’d mouse APIs like PointerEvents too, since you just copy from an array to array (translating as needed) inside the Chromium code. Yes, batching adds lag, but that’s a lesser evil than only providing lagged 125Hz or 500Hz — let the engine (game engine, JavaScript, whatever) decide what to do with the extra polls in a batched-poll array. Mouse benchmarking isn’t lag-critical when using timestamped poll arrays that HTML5 already has, so mouse benchmarking data is more independent of JavaScript performance than many expect. But low-latency use cases such as competitive games can turn batching off and use direct 1:1 polls via the HD Mouse API. Despite cutting my teeth in assembly language (6502, 8051, 8086, 80386 — including writing a ~40 kilobyte 100% machine language programmed video game in SuperMon64 called Space Zoom), I have zero tolerance of language elitism, and I’m a big fan of programming flexibility for usermode applications. The HD Mouse API must stay language-egalitarian and still accommodate low-lag in high performance languages, and reliable low-overhead high rates in slower interpreted languages
</Aside>

lyrill wrote: ↑

13 Nov 2020, 08:10

Also, a better idea is lose the receive parts of the sensor, let it just emit, lose those excessive lens bs(mixing up output emission with input receiving---I'm watching you all 3399 ads department). No it's still pretty terrible vs laser, and I've got my dirty 3090 lens on my AM-FG to prove it. Basically hasn't changed much, all but old tech.

While the HD Mouse API doesn’t go into implementation details for the sensor side part of the equation — the designed perpetual access to full sensor resolution will help the world of mouse analysis a lot. This will drive the mouse market, improve competition for improve precision, and reveal the crappy mouse pads.

Many mouse pads will produce jitter at the full DPI, and those would be revealed. But those will often be subpixel jitter. But some of it will feel natural — like feeling the road vibrations through the steering wheel of a car. You get familiar with the feel of a specific mousepad if the jitter is ‘expected’; like only caused by the flexing of a mousepad (pushing mouse downwards on a cloth mousepad for example) rather than from video noise in the mouse sensor camera. Using an inflexible microtextured glass mouse pad (frosted-like to eyes, but sensor-optimized texture under magnifying glass) instead of a bouncy thick rubber-cloth mousepad, will have noticeable jitter improvements in terms if pressing a mouse downwards on the surface, and different people will have different preferences on preferred mouse pads.

It is hoped that HD Mouse API will also embark better mousepad benchmarking too since the good pads will show from the inferior pads, in max-DPI jitter performance (even via HTML5 mouse APIs, one of which is already a floating-point timestamped poll arrays).

While we won’t go into the nuances of the feels of random jitter (i.e. video noise in sensor, more undesirable) and predictable jitter (i.e. mousepad flexing; more tolerable/predictable like feeling vibrations through a car steering wheel) — the point being, is that all of this jitter is currently filtered out anyway by sheer lowness of DPI, and games can still do this crude filtering simply by turning HD Mouse API off or via an advanced screen that allows users to configure how HD Mouse API filters (optional but honest-disclosed smoothing/interpolation/etc for those who intentionally desire it)

The point being is that full access to full sensor resolution isn’t a bad thing, and if the user prefers legacy behaviours (rounding off) they just stick to the legacy games using legacy APIs, or turn off HD Mouse API.

But the hopes is that people don’t have to resort to such moves, since newer games that actually decide to bother implementing HD Mouse API, would already work to treat the extra precision properly. Jitter (And apparently most of it in game software, not the mouse sensor) normally filtered out by 800dpi would thus, not be a problem, and if it is — And if the jitter is truly the mouse’s fault, then the mouse will quickly be replaced by superior mice thanks to the improved analysis afforded by HD Mouse API.

We’ve been gimping our mice for years, for no real good reason. The arrival of 360 Hz is the straw that broke the mouse’s back. The current mouse architecture just isn’t working anymore in the refresh rate race to retina refresh rates.

Chief Blur Buster wrote: ↑

14 Nov 2020, 13:55

Looking at raw input windows API, both GetRawInput and GetRawInputBuffer functions have a syscall overhead.

GetRawInputData gets the raw input one RAWINPUT structure at a time. In contrast, GetRawInputBuffer gets an array of RAWINPUT structures.

https://docs.microsoft.com/en-us/window ... winputdata



Looking at the cost of kernel call, note it is LOGARITHMIC SCALING.
https://stackoverflow.com/a/8247379

so 8000 * a syscall * usermode->kernel mode context switch is a huge problem for real-time 8000Hz, to have actual real 1000/2000/4000/8000 Hz polling it needs to be consistent, meaning XXXX.0000 or as close as possible to no jitter.

Linux has something called vsyscall ( https://lwn.net/Articles/446528/ ). And recently windows introduced registered I/O that reduces system calls for socket operations, its a must have imo to get rid of syscalls for something at 8000Hz. also no copying of buffers, it should be direct user=kernel mode shared buffer.

Windows also has I/O completion ports so maybe something like that, or Registered I/O.
https://www.slideshare.net/sm9kr/window ... red-io-rio
slide 12, notice the blue and yellow lines which drops the syscalls and context switches to very low "noise" levels.
i attached the image of slide below.

Chief Blur Buster wrote: ↑

14 Nov 2020, 14:12

lyrill wrote: ↑

13 Nov 2020, 08:10

Also, a better idea is lose the receive parts of the sensor, let it just emit, lose those excessive lens bs(mixing up output emission with input receiving---I'm watching you all 3399 ads department). No it's still pretty terrible vs laser, and I've got my dirty 3090 lens on my AM-FG to prove it. Basically hasn't changed much, all but old tech.

While the HD Mouse API doesn’t go into implementation details for the sensor side part of the equation — the designed perpetual access to full sensor resolution will help the world of mouse analysis a lot. This will drive the mouse market, improve competition for improve precision, and reveal the crappy mouse pads.

Many mouse pads will produce jitter at the full DPI, and those would be revealed. But those will often be subpixel jitter. But some of it will feel natural — like feeling the road vibrations through the steering wheel of a car. You get familiar with the feel of a specific mousepad if the jitter is ‘expected’; like only caused by the flexing of a mousepad (pushing mouse downwards on a cloth mousepad for example) rather than from video noise in the mouse sensor camera. Using an inflexible microtextured glass mouse pad (frosted-like to eyes, but sensor-optimized texture under magnifying glass) instead of a bouncy thick rubber-cloth mousepad, will have noticeable jitter improvements in terms if pressing a mouse downwards on the surface, and different people will have different preferences on preferred mouse pads.

It is hoped that HD Mouse API will also embark better mousepad benchmarking too since the good pads will show from the inferior pads, in max-DPI jitter performance (even via HTML5 mouse APIs, one of which is already a floating-point timestamped poll arrays).

While we won’t go into the nuances of the feels of random jitter (i.e. video noise in sensor, more undesirable) and predictable jitter (i.e. mousepad flexing; more tolerable/predictable like feeling vibrations through a car steering wheel) — the point being, is that all of this jitter is currently filtered out anyway by sheer lowness of DPI, and games can still do this crude filtering simply by turning HD Mouse API off (or via an advanced screen that allows users to configure how HD Mouse API filters — optional but honest-disclosed smoothing/interpolation/etc for those who intentionally desire it)

The point being is that full access to full sensor resolution isn’t a bad thing, and if the user prefers legacy behaviours (rounding off) they just stick to the legacy games using legacy APIs, or turn off HD Mouse API.

But the hopes is that people don’t have to resort to such moves, since newer games that actually decide to bother implementing HD Mouse API, would already work to treat the extra precision properly. Jitter (And apparently most of it in game software, not the mouse sensor) normally filtered out by 800dpi would thus, not be a problem, and if it is — And if the jitter is truly the mouse’s fault, then the mouse will quickly be replaced by superior mice thanks to the improved analysis afforded by HD Mouse API.

We’ve been gimping our mice for years, for no real good reason. The arrival of 360 Hz is the straw that broke the mouse’s back. The current mouse architecture just isn’t working anymore in the refresh rate race to retina refresh rates.

Damn this is all very eloquently put.

schizobeyondpills wrote: ↑

14 Nov 2020, 15:53

so 8000 * a syscall * usermode->kernel mode context switch is a huge problem for real-time 8000Hz, to have actual real 1000/2000/4000/8000 Hz polling it needs to be consistent, meaning XXXX.0000 or as close as possible to no jitter.

Good catch. It will have to be flagged to mouse manufacturers & Microsoft. I'll inform Razer_TheFiend about this, though this is clearly Microsoft code, which would be quite difficult.

Mind you, sensor-side timestamping will help some syscall jitter, as long as it is keeping up (8000/sec that's not fully dejittered) you're OK with a small (0.125us) latency window for dejittering -- still less lag than 1000Hz mice even with that window. It is possible sensor side timestamping may happen first before any action on Microsoft side.

However, yes, I acknowledge even a 1-poll window for latency dejittering is anathema to prioritizing on zero latency, although diminishing curve of returns occur in the microseconds leagues (e.g. 0.125us dejittering windows which may accomodate more than 99% of jitter). At those scales, even rendertimes variances between adjacent frames is a more major cause of gametime:photontime jitter, than this factor, but this is definitely a weak link that will need to be addressed eventually by Microsoft.

I wonder if there are sidechannel APIs (that can be implemented in Razer mouse drivers) that allows access to high-Hz USB data without syscalls.

Chief Blur Buster wrote: ↑

15 Nov 2020, 14:42

schizobeyondpills wrote: ↑

14 Nov 2020, 15:53

so 8000 * a syscall * usermode->kernel mode context switch is a huge problem for real-time 8000Hz, to have actual real 1000/2000/4000/8000 Hz polling it needs to be consistent, meaning XXXX.0000 or as close as possible to no jitter.

Good catch. It will have to be flagged to mouse manufacturers & Microsoft. I'll inform Razer_TheFiend about this, though this is clearly Microsoft code, which would be quite difficult.

Mind you, sensor-side timestamping will help some syscall jitter, as long as it is keeping up (8000/sec that's not fully dejittered) you're OK with a small (0.125us) latency window for dejittering -- still less lag than 1000Hz mice even with that window. It is possible sensor side timestamping may happen first before any action on Microsoft side.

However, yes, I acknowledge even a 1-poll window for latency dejittering is anathema to prioritizing on zero latency, although diminishing curve of returns occur in the microseconds leagues (e.g. 0.125us dejittering windows which may accomodate more than 99% of jitter). At those scales, even rendertimes variances between adjacent frames is a more major cause of gametime:photontime jitter, than this factor, but this is definitely a weak link that will need to be addressed eventually by Microsoft.

I wonder if there are sidechannel APIs (that can be implemented in Razer mouse drivers) that allows access to high-Hz USB data without syscalls.

i forgot to add these two. for high hz mice and usb controllers theres already high cpu usage and fps drops with microstutters from high rate of interrupts and long lasting dpc routines on unoptimized general consumer hardware hid as well as usb controller generic Windows drivers so a zero syscall no memory copy interface would help A LOT, especially since its a one way write channel 99.9% of the time.

if Nvidia can release Reflex SDK i dont see why razer couldnt do the same and release low latency mouse protocol SDK for their devices and have game devs implement it.

Razer could also release their custom pci-e usb controller for low latency that would have an optimized driver for usb/mouse controller in regards to low latency/low OS overhead talking with Razer Input(i just made this up) user mode game SDK.

im not even getting tshirts or hoodies for schizoposting this stuff out

i mean if u want t shirts u just pre order bav2 dav2 lol. not that you can't get them for sub 20 dollars seperately.

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.

O_O wrote: ↑

25 Nov 2020, 23:41

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.

Just like 15 years ago for the first 1000Hz poll rate mice...

...I am witnessing massive variances between systems.

TWO full order of magnitude difference in 8000Hz poll processing.

One machine I encountered can sallow those 8000Hz nearly effortlessly like it was just a mere 125Hz mouse (until it encountered inefficient-paint software that did 8000 WM_PAINT's per second during window dragging, ha!).

But another machine clogs a whole CPU core failing to catch every single poll of the 8000Hz, even pointer-circling on an idling system. Old crud-filled Windows system.

This problem happened 15 years ago too, with the arrival of the first 1000Hz mice.

History repeating...

________________

Using a Dedicated USB Port PCIe Card for 8000Hz Mice

P.S. You can cherrypick system setups, and pay the highway toll of a highly acclaimed dedicated USB3 card too (and leave all of its USB ports unused except for your 8000Hz mouse), so that your 8000Hz mouse has its own dedicated USB chip and a dedicated PCIe lane, straight to your CPU. The price of admission to the mouse's own empty express carpool lane!

You'll still get a bit of contention here and there (Windows and OS and whatever, creating windstorms and potholes across the metaphorical highway, shaking and jittering your car) but you don't have to worry about other metaphorical car traffic slowing you down thanks to the mouse's own metaphorical dedicated carpool (PCIe) lane.

And sometimes that internal USB hub is also sharing with internal USB devices (Bluetooth, etc). Now you've got heavily-shared USB internally.

Garbage motherboard USB ports are often your cesspool of the crowded LA-area non-toll highway, your spider web of USB cables plugged to the back of the computer, creating lots of pollrate contention unbeknownst to you because motherboard ports are almost always USB-hubs. Sometimes all 6 rear-of-computer ports are a single USB hub on some motherboards! So if you're stuck with motherboard USB ports, play USB port roulette until you win.

The sheer reliability of 8000Hz poll performance improvement just by switching to an external USB card has already convinced me that a possible Blur Busters Recommendation for 8000Hz poll rate is to buy a dedicated USB card solely for your 8000Hz mouse, if one prefer to use 8000Hz instead of 2000Hz or 4000Hz (good compromise). It won't fix inefficient software, but it eliminates a majority of mudane bottlenecks for an 8000Hz mouse.

Long term, sensor-side timestamping will help compensate for plugging into timing-dirty USB ports, if one wants fluidity-priority over latency-priority, to preserve the ability for any software developer (whether HTML5/C++/ASM) to aggressively maintain sensor-to-gametime-to-photons perfect relative time sync. That option becomes feasible/possible with HD Mouse API.

And all software developer in all programming languages, high level and low level, will be able to -- if they wish -- measure the dirtiness of timing by comparing the sensorside timestamps (communicated via HD Mouse API) with the actual timing of arrival of poll into the software. So the developer can tell how dirty/precise the mouse timing sync is, and offer optional mitigations.