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]>
- our logging code was bigger than spdlog itself, why???? just keep it simple
- fix issues when logging before logging system is even started
- removes the "initialized logging twice" issue
- removes uneeded indirection in file logging
- uses direct formatting instead of jumping hoopla-around the fmt::format() ressult
- code duplication and dead code removal as usual
I did explore dup2() but I think it's not worth the hassle
I did try `fwopen()` but it's better if things are just kept as-is.
there is a lot of noise because I removed a bunch of redundant files on logging and just put everything in one file
now normally this wouldn't be a good idea, however consider: the complexity of logging; it's less than 500 lines... does it really need a whole subsystem?!?!?! ITS JUST LOGGING
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3688
Reviewed-by: crueter <[email protected]>
Reviewed-by: DraVee <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
Co-authored-by: lizzie <[email protected]>
Co-committed-by: lizzie <[email protected]>
- OpenGL symbols would still be included in builds without OpenGL, this pr fixes that
- Same goes for Vulkan, but now with `ENABLE_VULKAN`
- Add support to have OpenGL-only builds (why would you do this?)
- Add support for headless runs (yes you could just select NULL backend, but why not compile it headless? :)
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3692
Reviewed-by: crueter <[email protected]>
Reviewed-by: DraVee <[email protected]>
Reviewed-by: MaranBr <[email protected]>
Co-authored-by: lizzie <[email protected]>
Co-committed-by: lizzie <[email protected]>
Removes some odd #ifdef-ing that just can use a shrimple opaque type.
Also removes nullptr() ctor'ing for vulkan handles and such; it's not incorrect per se like how `void *p = 0;` isn't incorrect, just that, y'know, any static analyzer will go "woah". Also there isn't any guarantee that handles `sizeof(Handle) == sizeof(void*)` so may as well :)
Signed-off-by: lizzie [email protected]
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2971
Reviewed-by: CamilleLaVey <[email protected]>
Reviewed-by: MaranBr <[email protected]>
Co-authored-by: lizzie <[email protected]>
Co-committed-by: lizzie <[email protected]>
lizzie
