most stdlibc++ already provide this functionality out of the box, very consistently and well implemented (usually)
my main irk is that the llvm itanium demangle is totally unescesary when there is a perfectly stable, tested and well documented equivalent functionality in the standard stdc++ provided in most UNIX oses
its mostly to reduce binary size by a very thin margin, but he stdc++ is more than capable of doing he same behaviour we use a dpeendency for
for mingw or such howeger,, demangling becomies trickier so we have to exclude windows entirely because well windows likes to do things differently dont they
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3894
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
when shutting down the emulator will silence any remaining audio from the output buffer
however this is for some reason stored in an array instead of being a simple memset
additionally, said array can be small enough (`frame_size_bytes > silence.size()`) to cause a funky noise to play at the end
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3969
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: crueter <[email protected]>
This implements MWAITX and WAITPKG extensions (umonitor, mwait) for CPUs that support them.
Reduces wait times and bypasses the timing stuff from the OS that is slow (windows notably). generally it should answer within 0.2 to 0.5 microsecs (since most requests wait for that long).
Also does a general rework of static ctors and stuff
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3984
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: crueter <[email protected]>
before vs. after
Mario Brothership kept remaking vectors of sizes 256 AND 4095 (TIC) and 1215 AND 524287 (TSC) every single frame, which resulted in a noticeable overhead
the main cause was because of using `resize(n, c)` instead of `resize(n)` (also to aggressively resize for more room beforehand), the copy overload of resize does a copy of... well.. the value over the entire vector, additionally __append() keeps getting called because the capacity goes bonkers and all over the place
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3874
Reviewed-by: crueter <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
Reviewed-by: MaranBr <[email protected]>
u8 may have been 0xff, (aka. 255), but bitset was only 255 elements, so doing bitset[255] is technically OOB
additionally the max size estimate for index formats was not correct, there can be up to 256 elements with a u8 format index, not just 255
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4006
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
- testriswitch submits buffers with a fence id of -1, just skip them instead of trying to process them?
- apm:u, which is removed, but hey, backwards compat never hurted
- another instance of shared_memory crashing NPad
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3983
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
traditionally, when doing jthread:
```
jthread() calls function parameter operator()() with args
function operator()() calls the code within
code within is, say { ThreadMain(); }
3 calls because why not
```
now this just makes it be 2 calls, mainly benefits non-LTO builds
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3970
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
hbloader is required to launch a bunch of shit (particularly hbmenu)
however due to some restrictive metadata validation, it doesn't get recognized as an NSP file
programs like hbmenu require hbloader (since it feeds them data like ConfigEntries and whatnot), launching hbmenu as-is standalone will result in a launchInit() error
adds an option to launch hbmenu via command line
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3981
Reviewed-by: Maufeat <[email protected]>
Reviewed-by: crueter <[email protected]>
this makes it so VK and OGL backends map the NVIDIA's ETC2 into VK_FORMAT_ETC-whatever and GL_ETC-whatever remaps, instead of using the default fallback for AR8G8B8. in short, just make the ETC2 textures be submitted as ETC2 instead of being submit as A8R8G8B8.
Signed-off-by: lizzie [email protected]
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3237
Reviewed-by: Ghost <>
Reviewed-by: crueter <[email protected]>
the nominal std::unordered_map<> isn't enough to warrant it's continued usage in xbyak internal structures, thus using ankerl should greatly remove a lot of indirection/stdc++ specific overhead from the usually poorly performant std::unordered_map
Both dynarmic and macroHLE should benefit greatly from a less-stupid unordered_dense
This should speedup both CPU and shader compilation latency (NOT BY A GREAT MARGIN) just enough to make loading zones in ToTK less horrific
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3716
Reviewed-by: crueter <[email protected]>
so basically each construction of HLEContext and whatever would result in a heap allocation (atleast 1)
so what if instead of that we did a memset() at ctor time and we avoided heap allocations altogether?
reminder that std::vector<> CAN do small object optimisation but it's not guaranteed
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3605
Reviewed-by: crueter <[email protected]>
inputs shouldnt be that critical to require a full mutex of them
this relies on CPU guaranteeing u32/u16/u8 atomic load/stores for EmulatedController fields, which works on x86_64 but may not have the same behaviour on other architectures - thats why i wrap them in `std::atomic<>`
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3866
Reviewed-by: crueter <[email protected]>
sounds like word salad but let me say:
- std::map<> created a static ctor for EVERY SINGLE ZONEINFO
- fuck that, instead lets just use a raw array and construct things statically
- works the same except with less baggage carried around (+ less heap allocations!!!)
this should help reduce codesize due to the aforementioned global ctor/dtor
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3919
Reviewed-by: crueter <[email protected]>
see https://github.com/herumi/xbyak/issues/255
> Proof: https://godbolt.org/z/9vseq4Ynj
> Xbyak currently implements it as:
> ```c++
> void umonitor(const Reg& r) {
> int idx = r.getIdx();
> if (idx > 7) XBYAK_THROW(ERR_BAD_PARAMETER) //umonitor DOES accept r8,r9,r10,etc this is NOT correct
> int bit = r.getBit();
> if (BIT != bit) {
> if ((BIT == 32 && bit == 16) || (BIT == 64 && bit == 32)) {
> db(0x67);
> } else {
> XBYAK_THROW(ERR_BAD_SIZE_OF_REGISTER)
> }
> }
> db(0xF3); db(0x0F); db(0xAE); setModRM(3, 6, idx);
> }
> ```
> My program was throwing Xbyak::Exception and I tracked it down to this particular umonitor
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3954
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
instead of throwing, use std::error_code and such
due to reasons unberknownst to me, the UID of the /tmp/eden directory was set for another user, this inevitably caused a crash due to wrong permissions (which is a very user unfriendly thing to do generally)
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3912
Reviewed-by: crueter <[email protected]>
While originally for MSVC, this also should help clang/gcc not die trying to make codegen for the load/store of fields for the tls_data
should help to reuse computed values instead of recomputing shit for no reason
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3932
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
issues:
- std::function<> is used, which is famously bad
- storage of tehse in tables makes big fucking tables for no good reason
- lets just store a normal pointer and stuff! :)
this pr attempts to address that
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3920
Reviewed-by: CamilleLaVey <[email protected]>
theoretically, it's better because distributes load of logging across various threads
this should work because 99% of I/O solutions are blocking by default
EXCEPT, maybe android differs? please check logcat didn't get affected (again) by me underestimating android ~~stupidity~~ brillaince
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3928
Reviewed-by: CamilleLaVey <[email protected]>
- service manager may add a service while someone else is finding it, so properly lock
- nvhost doesn't properly account for the fact that iterators GET FUCKING INVALIDATED
- use proper exit routine for mapping locked that failed (try/catch hell)
the last two were introduced by #3858, but the first one has been present since ???
either way, remember that ankerl map has invalidated iterators upon erase/insert, so i accounted for that and SMG1 (and probably smg2) boot fine now
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3927
Reviewed-by: crueter <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
- fix va-api not being used on freebsd
small thingies dont affect a lot:
- removes some pointer indirection (why save pointer to GMMU if its accesible via host1x)
- use std::variant<> for decoder
- miscelly vp9/v8/h264 opts
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3878
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
usual indirection removal
helps very slightly to codegen
the idea is basically to reduce the amount of pointer deference overall in the code, and use idiomatic std::variant<>-isms to not rely on vtables/unique_ptr overhead
this should allow the compiler to emit better code
of course it's a tiny optimisation and only CPU side, but allows us to reduce indirection which is almost always a good thing
"but youre passing more parameters to the function!!!" its literally memoized into a register my friend
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3758
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
there is no need to call mmap() over the mapped region as the OS will automatically map it via lazy paging
basically the mmap() and virtualAlloc on a region already allocated is a no-op (FOR THIS SPECIFIC USECASE)
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3857
Reviewed-by: crueter <[email protected]>
VirtualBuffer<> would be recreated each time due to the `operator=()` from the unique_ptr<> when initializing a new process, this change makes it so said thing doesn't happen (instead it resizes the existing buffer)
this means that consecutive launches of the same process that happen to have the same process page table (or reuse it) will no longer incur a ctor/dtor path for VirtualBuffer and instead just resize the existing one
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3891
Reviewed-by: crueter <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
Does NOT fix root issue with shared_memory of NPad yet, that is something probably separate
I'd like to suspect it's because every NPad by default it's expected to have shared memory, even when not explicitly initialized, but seems unlikely
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3860
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: crueter <[email protected]>
lots of AGILEism in spirv-opt
theres BETTER alternatives like https://github.com/renderbag/re-spirv (im not gonna bother for now, it probably has shitty build system)
it sucks
the IR already resolves most of the shader code to just constant load/stores
Spirv-opt passes do not seem to make such a big difference
only introduce extra latency
like for example cbuf pass in IR already removes a lot of code, that spirv_opt would otherwise miss due to the fact it doesn't have cbuf information
Signed-off-by: lizzie <[email protected]>
Co-authored-by: crueter <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3877
Reviewed-by: CamilleLaVey <[email protected]>
Reviewed-by: crueter <[email protected]>
push %edx is not what i wanted, nor what anybody wants, xbyak silently accepting this before was not intended
now that xbyak is updated this is an issue
the issue was simply:
a) ptr being overwritten (if it happened to be EDX/EBX/EAX) due to changed WAITPKG logic (oops)
b) xbyak not reporting wrong r32 pop/push on older versions thus missing it and now it throws an exception
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3875
Reviewed-by: crueter <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
Implementations for SSE3 CPUs (prescott)
Instead of fixing some of the bugs with HostCall when paired with vectors, i'll simply remove as many host calls as I can within the most used vector instructions - then just minimize their usage to memory read/writes.
Emitting the raw assembly code is faster than doing a HostCall, HostCalls are VERY expensive. So this is the desired output anyways.
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3301
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: Maufeat <[email protected]>
Co-authored-by: lizzie <[email protected]>
Co-committed-by: lizzie <[email protected]>
Lets do the quick math
There was 1 LUT for every fsize() instancing
Now... the number of functions on each lut was (fsize + 1), multiplied by 5 (number of rounding modes)
8 = 9 * 5 = 45
16 = 17 * 5 = 85
32 = 33 * 5 = 165
64 = 65 * 5 = 325
this is just pure insanity - look at what fucking nm reported:
```
0000000003dc39b8 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<16ul, false>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
0000000003dc3a18 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<16ul, true>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
0000000003dc39d8 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<32ul, false>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
0000000003dc3a38 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<32ul, true>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
0000000003dc39f8 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<64ul, false>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
0000000003dc3a58 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<64ul, true>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
```
"ah its not bad" - OH MATE ITS JUST THE GUARD VARIABLES - i attached a file with just the functions generated for each case...
now with this PR only 6 * 6 functions are made (still not ideal, but way better), 36 is way better than 1156 FUCKING FUNCTIONS
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3718
Reviewed-by: DraVee <[email protected]>
Reviewed-by: Maufeat <[email protected]>
Co-authored-by: lizzie <[email protected]>
Co-committed-by: lizzie <[email protected]>
lizzie
