small oopsie; we dont need 6 copies of the same 22KB table
(removes 5*22 = 110 KB worth of redundant stuff)
this also enforces static on the types defined in the header so they arent memoized into a non-inlined value (aka. compiler just grabs value instead of well, yknow, assuming its a constant area)
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4180
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
makes it so the shader cache goes properly in `XDG_CACHE_HOME`.
SOME people have it set to point to `/tmp` AND as a ramdisk, if they can do that they probably would want their shader caches to be there as well and wouldnt mind the extra hit from invalidations on reboot.
afterall, its a cache, not some holy data that needs to be kept at all costs.
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4093
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: Maufeat <[email protected]>
should fix some issues with some NAS setups
where people have their games on a NAS and they
try to access it but for some reason some file
just doesnt load, instead of aborting early we continue
for the rest of the files in the directory
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4100
Reviewed-by: Shinmegumi <[email protected]>
Reviewed-by: Maufeat <[email protected]>
samu will be happy
basically this handles the edge case where either:
a) eden is the first application ever ran (i.e no config dirs made yet)
b) user didnt have them
c) user is trying to run on a sandbox appimage or whatever bs
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4087
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
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]>
lizzie
