I'm planning in programming the natural curve into the driver

[anengineer1]

Greetings, I'm just telling this out loud in case there is already some development into it and to prevent multiple people working on the same.

@AndyFilter you already mentioned how you start with the gui and how you test it on a vm so I already prepared that.

If there's already someone working on it tell me please

Thank you in advance

[AndyFilter]

Hey, It's awesome to hear that someone is working on new features! I'm currently working on adding a robust testing suite, so the project structure might change a bit, but this shouldn't be an issue (and might take a long time, because I have a bunch of exams in the upcoming weeks).
When it comes to work on the Motivity curve, I haven't done much, beyond what's already in the program. But I started theory crafting on Synchronous tho, as it's meant to be the "perfect" curve. If You're interested, I can share all the math I've done regarding this curve, but honestly a better source of information would probably be either RawAccel's repo, or Kuuuube's repo
.
Good luck, and if You encounter any questions during the implementation, I'm always happy to help!

[anengineer1]

Thank you for telling me that cause I set Natural to 8 yesterday, I just changed it as you told:

const char *AccelModes[] = {"Current", "Linear", "Power", "Classic", "Motivity", "Natural", "Jump", "Look Up Table", "Custom Curve"};

I will continue with the rest of the files and such as I made progress and thank you again for pointing out the config file

[kitten]

I don't think the Nix module should adapt to changing IDs fwiw. If we want to change the IDs (and it's very reasonable to keep the custom curves towards the end) then so be it 😅

I know I'm behind one curve on the Nix module and will revisit this as soon as I have a minute.

But Yeetmouse not having tags/releases/versions yet means imo that breaking the NixOS module (which is more like an add-on than a lock-step feature) is expected until versioning is in place or stability is reached

[AndyFilter]

Glad to hear that NixOS will work, but it got me thinking if it would be possible to somehow replace the hard-written ID values like this "5" representing the Jump mode:

YeetMouse/nix/module.nix

Lines 206 to 210 in 135c452

	apply = params: [
	{
	value = "5";
	param = "AccelerationMode";
	}

with something more flexible like entry of an enum (or a label of some sort) like this one:

YeetMouse/gui/DriverHelper.h

Lines 42 to 52 in 135c452

	enum AccelMode {
	AccelMode_Current = 0,
	AccelMode_Linear = 1,
	AccelMode_Power = 2,
	AccelMode_Classic = 3,
	AccelMode_Motivity = 4,
	AccelMode_Jump = 5,
	AccelMode_Lut = 6,
	AccelMode_CustomCurve = 7,
	AccelMode_Count,
	};

(this enum will be moved to a shared file between driver and GUI next push)
This would make the NixOS module a bit more future proof hopefully, but I don't know if it's even possible.

---

I'll hopefully feel confident enough about the program to make releases after adding tests, to make sure it wont cause kernel panics for people. And looking at how the work is going it might even happen sooner than I initially anticipated.
But no hurries on anything, the codebase is not very clean and I first need to work on that.

[kitten]

definitely possible to parse any text file, and to parse the enum out of there, but probably not worth it, since the complexity of that would start to outweigh its own benefit.
parsing the enum value from a shared file is probably harder than keeping it in sync, given that the generated outputs will have to be supported either way 😅

with that I mean, the Nix module is already modeled after a tagged-union / constructor, but the naming of the properties is semantic (more like what they'd show up in the UI), so this is similar to asking: would the UI be able to generate its property names and modes from that shared file? Ultimately, there's still logic that labels those separately, so similarly it's labelled separately in the Nix module.
i.e. I could write code to parse out the enum but that's a small port of what's available, and it's easy to keep the AccelerationMode values in sync, harder to make sure everything else matches as expected (i.e. range and such)

Edit: s/harder/more tedious/ rather 😅

[AndyFilter]

Alright, You're right. That's totally fair, I don't think there will be many more modes added in the future, so it almost certainly is not worth the work compared to just changing the values this one time by hand. Instead I think I'll just add some note to the ReadMe pointing to all the places that need to be checked after modifying the AccelModes enum.

[anengineer1]

Some progress, this is looking good (I think):

Next step will be reviewing the validation (I see you have a function for that), after that I will proceed with saving the parameters into the config.h file and the other format you have available.

After all of that, it comes the driver part.

[AndyFilter]

Looks great! Good job.
The parameters should save to config.h and plain text regardless of the mode selected. So unless You added new parameters, everything should already work just fine. And it's preferred to not create new parameters, and rather re-use the existing ones under a different name.

I'm almost done with the testing suite, I'll try to push it out in the upcoming days, so You can test the driver side code much easier. Also, there are some other changes, but I hope it wont have any conflicts with Your current work.

[anengineer1]

Thank you for the information, it was very useful. I added the limit parameter... I'll take a second look to see if I can reuse an existent one... If I don't see an option that makes sense, perhaps it is better to keep it as it is right now (with limit added).

Regarding your upcoming changes, don't worry if I have to redo stuff, that's the price of progress and the critical part is the equation code which I'm sure I can recicle it fully... I will rest for a couple of days or so. If for whatever reason I finish everything before your work (tremendously unlikely as I want to play around with the code quite a bit and I have no experience with the driver part except from the ppc64le part I did in the past), I will not make any pr before telling you.

Sorry if I'm distracting you too much from the exams and good luck with them

[AndyFilter]

I'm glad it helped, to be more specific I meant that You can for example use the parameter exponent for the limit under the hood. Like it's done in the Jump mode, where the smoothness parameter (in the GUI) is actually just exponent:

YeetMouse/gui/FunctionHelper.cpp

Line 150 in 27b9bc5

smoothness = (2 * M_PI) / (params->exponent * params->midpoint);

From Rawaccel:

smooth_rate = (2 * M_PI) / (args.smooth * step.midpoint);

This is done because adding new parameters (especially on the driver side) is tedious and can even be troublesome if not done correctly. The word "reuse" I used last time wasn't perfect, it's more like mapping. You map smoothness in GUI to exponent in code.

About the code changes, I've pushed all the important stuff today. I'm afraid you'll have to update a couple of lines to align with those changes. But the most important takeaway is that now all the acceleration modes' code is in the accel_modes.c file, instead of accel.c and some parts of the code were updated to use AccelMode enum instead of numbers. But if you will have questions at any point, feel free to ask them here, or on a PR once it's created.

Thanks for the work and patience (and for worrying about my exams; I'm sure I'll do fine <3).

[anengineer1]

• It is a pleasure.

• Using exponent as limit makes quite a bit of sense.

• Taking notes on the things you mentioned about update you just pushed.

• You'll nail the exams <3

[anengineer1]

Hi again, I'm now doing the driver part and I'm very grateful that you made the Test Suit, it is making the whole thing more manageable.

I would like to ask how would you like the offset to be handled in the natural curve... I love how rawaccel is handling the transition between the constant part and the curve that's why the offset is in the equation... instead of adding the g_Offset as an extern, I just added it as a parameter for the time being:

FP_LONG accel_linear(FP_LONG speed); FP_LONG accel_power(FP_LONG speed); FP_LONG accel_classic(FP_LONG speed); FP_LONG accel_motivity(FP_LONG speed); FP_LONG accel_natural(FP_LONG speed, FP_LONG n_offset); FP_LONG accel_jump(FP_LONG speed); FP_LONG accel_lut(FP_LONG speed);

In FunctionHelper.cpp

 if (x <= params->offset) { val = 1; } else { float limit = params->exponent - 1.0; float auxiliar_accel = params->accel / std::fabs(limit); float offset = params->offset; float n_offset_x = offset - x; float decay = std::exp(auxiliar_accel * n_offset_x); if (params->useSmoothing) { float auxiliar_constant = -limit / auxiliar_accel; float numerator = limit * ((decay / auxiliar_accel) - n_offset_x) + auxiliar_constant; val = (numerator / x) + 1.0; } else { val = limit * (1.0 - (offset - decay * n_offset_x) / x) + 1.0;	} } break;

[anengineer1]

Hi! regarding the performance, that new ppc64 extended assembly code runs, more or less, twice as fast as the previous one (yeah, for real, I tested it). Even thought the previous iteration was simpler, I did mix extended assembly with standard c operations in a non elegant way, this new code is just a single assembly block.

I don't have a proper machine to test the x86/64 sadly, I will need your help regarding testing on a standard x86 machine

[anengineer1]

If you want some numbers:

6416074202321 time intrinsics: 0.000022 6416074202321 time exp: 0.000009 6416074202321 time simple expression: 0.000013 6416074202321 time using the algorithm: 0.000007 

"time using the algorithm" is what the longer more complex algorithm takes to do the operation... sometimes it take 0.000003, sometimes 0.000007 (those values are so low that it is hard for the system to be consistent measuring them), but it is consistently very low.

"Instrinsics" are not really gcc intrinsics but this:

uint64_t Div128_64_Intrinsics(uint64_t u1, uint64_t u0, uint64_t v) { __int128_t dividend = ((__int128_t)u1 << 64) | u0; if (v == 0) { return 0; // Handle division by zero } return (uint64_t)(dividend / v); // Cast back to 64-bit if needed }

After coding a bit I got lazy and I let the AI handle the boring parts and it called "instrinsics" and I just let it be.

I'm using this to test.
more_ppc_experiments.txt

[AndyFilter]

Well, It's pretty difficult to profile such fragments of code, as they are simple enough for the compiler that it can just calculate the result ahead of time (this won't happen in Your code btw.).
Another reason is that in Your code the measure time also includes printf, which is undoubtedly orders of magnitude slower than any arithmetic operation (no matter how complex).
Next thing is that when doing a test on a single call, the current state of the processor, pipelines, cache and a bunch of other things can easily influence the results, so it's much better to run each test inside a loop (the bigger the loop, the better*).
At the end, when testing for real life application, its crucial to profile with the same optimisation flags as in the production, which in this case is -O2.

Now with some changes I get these results:

Enter the first number (numerator): 125947152 Enter the second number (denominator): 11 res: 49176263533121908 avg. time intrinsics: 3.041852ns res: 49176263533121908 time exp: 1.924225ns res: 49176263533121908 time simple expression: 0.237669ns 

This still doesn't take into the account the fact that the compiler is smart enough to skip some basic calculations all together when in a loop and instead just (for example) calculate the sum. 0.23ns for a single iteration of anything is fast, too fast, which means that there still is something going on under the hood. There for example is the overhead of accumulating the result unused += Div128_64_v2(num1 >> 32, num1 << 32, num2);, so the compiler doesn't think this operation is useless, it's not much, but it's a single add instruction done possibly millions of times.

This code is still far from perfect, and it's just a very vague estimation.

But no matter the result, I think that the more complex division code is slow, but still not that slow. If You'd want to test it on the ppc64le, here's the file:
more_ppc_experiments2.txt
If You want to run on ppc64le, make sure to uncomment the definition on top // #define __ppc64le__. And make sure You compile with -O2.

The best way to properly benchmark this would probably be with this driver code:

YeetMouse/driver/accel.c

Lines 335 to 347 in 27b9bc5

	// Used to very roughly estimate the performance, and 0.1% lows
	// ktime_t iter_time = ktime_sub(ktime_get(), now);
	// static ktime_t elapsed_time, highest_elapsed_time;
	// static int iter = 0;
	// elapsed_time += iter_time;
	// if(iter_time > highest_elapsed_time)
	// highest_elapsed_time = iter_time;
	// if(++iter == 1000) {
	// iter = 0;
	// pr_info("YeetMouse: Sum of 1000 iters: %lldns, low 0.1%%: %lldns\n", ktime_to_ns(elapsed_time), highest_elapsed_time);
	// elapsed_time = 0;
	// highest_elapsed_time = 0;
	// }

As it's the closest we can get to a real life scenario, but it's tedious, error prone and still has some overhead with all the other code that's also running alongside the function we're testing.

---

I'm glad You informed me about the fact that x86/x64 is untested, I'll test it quite thoroughly in this case.

[anengineer1]

Greetings! you are so right! thanks for the much needed info:

res: 915608937192 avg. time intrinsics: 14.639735ns res: 915608937192 time exp: 6.048262ns res: 915608937192 time simple expression: 0.520450ns res: 915608937192 time using the algorithm: 6.612963ns ignore this: -633983212 

Yeah, and as you mentioned, it is way slower, but I think it is passable and the best we have right now for modern ppc machines.

I have a lot to learn and thank you for your patience.

[AndyFilter]

I'm glad I was able to help.
About the results, there still is something off about them, the intrinsics are just as slow as the complex algorithm. Looking at the code I forgot to add "+ i" in the last loop for the second argument, like I did everywhere else, so the last loop should look something like this:

... for (i = 0; i < ITER_COUNT; i++) unused += Div128_64_v2(num1 >> 32, num1 << 32, num2 + i); ...

(With the + i at the end).
Without it, the compiler probably skipped something, or did some other smart thing, who knows.

Also I think I messed up the order of operation for the second to last loop:

unused += (FP_LONG)((__int128_t)(num1 << 32) / (__int128_t)num2 + i);

Where it should be

unused += (FP_LONG)((__int128_t)(num1 << 32) / ((__int128_t)num2 + i));

(braces at the + i).

All this doesn't really matter to be honest, because profiling code like this is notoriously difficult. The best way to estimate something like this is probably just by looking at the assembly code, and judging which will execute faster.
So, to wrap up, we can safely assume the more complex division is slower, but that's the only option we have at out disposal, so not much we can do about it 🤷🏼‍♂️.

"No classroom is needed when you want to learn" ~ Albert Einstein