This may reduce total overhead (as benchmarks show boost::container::deque being better performing than std::deque, especially with the limited set of ops like push_front and pop_back
May actually not help at all and be worse through, as always, performance tests are welcome
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3120
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
MediaCodec needs some jvm shenanigans to work, but the others should
Just Work(TM). Need tests on Windows (AMD/Intel), macOS
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3156
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
We had the same struct for v1 and v2 - this was tested only with MP4, should output correct sounds now and boot it.
Co-authored-by: MaranBr <maranbr@outlook.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3142
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
Co-authored-by: Maufeat <sahyno1996@gmail.com>
Co-committed-by: Maufeat <sahyno1996@gmail.com>
The GPU Accuracy level is now divided into Performance, Balanced and Accurate.
1. Performance prioritizes speed at all costs. It's faster, but it can be unstable and may have some bugs (which is expected).
2. Balanced maintains excellent performance and is safer against bugs and shader corruption.
3. Accurate is the most precise and the most expensive in terms of hardware. Only a few games still need this level to work properly.
The Release Early Fences toggle has also been removed by @PavelBARABANOV, as it's not needed anymore.
Co-authored-by: PavelBARABANOV <pavelbarabanov94@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3129
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Co-authored-by: MaranBr <maranbr@outlook.com>
Co-committed-by: MaranBr <maranbr@outlook.com>
Fixes an issue where selecting EDS 0 for a specific game would incorrectly disable VIDS globally.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3148
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Co-authored-by: MaranBr <maranbr@outlook.com>
Co-committed-by: MaranBr <maranbr@outlook.com>
Both options do nothing, however one was exposed to the user making them think it actually helps.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3152
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Co-authored-by: Kleidis <kleidis1@protonmail.com>
Co-committed-by: Kleidis <kleidis1@protonmail.com>
rationale:
- some drivers will not outright crash (and keeping a list of those who don't crash is tedious)
- if it does crash we can get a log line saying "hey, this driver? unsuitable"
- makes lfie with lavapipe a tad bit easier
Signed-off-by: lizzie lizzie@eden-emu.dev
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3087
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
So when libc starts it has to start at an entry point located into crt0, now most OSes will do "enough" setup to allow mprotect() and mmap() to be called in static ctors (remember they're called BEFORE main)
By some stupid miracle, NetBSD doesn't; this means that using those functions on NetBSD will result in spurious results
The reason why is still unknown to me, but this is also combined with the fact that allocating a big chunk of memory for the JIT will make NetBSD refuse to mprotect()/mmap() it in low memory situations (even when space is available); so I take the same approach as with solaris
Also I now make it so fastmem handlers are NOT registered for OSes that disabled fastmem, this is because they pollute sigsegv and makes debugging stupidier
Signed-off-by: lizzie lizzie@eden-emu.dev
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3092
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
Never in my lifetime will I ever need to revise anisotropy levels; I hope :)
Signed-off-by: lizzie lizzie@eden-emu.dev
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3019
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
NOTES:
regs.window_origin.flip_y MUST flip the y coordinate of any given FragCoord, we don't emulate this, this is the root cause of the error, but I'll just revert for now since it's easier
DON'T MERGE unless it's near 0.0.4 and I (or someone else) hasn't tackled this yet properly
This reverts commit 17fe74ef11.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3075
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
Fixes AMD + Windows because it forces barriers to include the fragment test and color output stages explicitly, ensuring that all render pass writes are visible before later commands. Without it, AMD’s driver sometimes skipped synchronization, causing broken rendering in Final Fantasy Tactics.
PR #3069 also fixes this regression by reverting vk_scheduler.cpp in PR #180.
This PR fixes PR #180 and may be the better solution.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3071
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Co-authored-by: John <john@eden-emu.dev>
Co-committed-by: John <john@eden-emu.dev>
