Reduces the page entries from 32 bytes to 8 and rewrites `VirtualBuffer` to be more efficient in memory usage and specifically for large zero regions.
The page table will now only reserve 1GiB instead of 4GiB and of this memory it should only use at most ~8MiB.
This PR has the side effect of using Eden on Windows on low memory systems much more plausible since it would previously require ~10GiB of committable memory at front (despite using ~5-6 at most, inadvertently stalling other processes) where as now it should only require around the amount that it'll actually use.
Co-authored-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4219
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Storage buffers can span GPU pages that aren't contiguous in host memory, but the buffer cache assumed one contiguous buffer per binding, so anything crossing a mapping boundary read the wrong bytes. Multi-range binding resolves the real segments and presents them to the shader as one buffer, aliasing their memory into a sparse VkBuffer or gathering them into a copy, all of this was mostly fixed by making a path to use sparse on buffers (the same way as texture cache has it) and retrieve properly the mapping ranges to the virtual pages, including the actual structure on the use of binding sparse.
Meanwhile this fixes Monster Hunter Sunbreak z-fighting, bad performance and mostly vertex explosions (coming from the contiguous buffer read from the shader's game) it's only the basis for a further investigation towards how are we gonna treat phi calculations, optimized them and mostly eradicate the currently excess of exposure on the textures where the lightning trace should not being reflected.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4362
Reviewed-by: lizzie <lizzie@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions).
- [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md)
- [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability.
-------------------
Problem: In cyrilic idioms, Absolum won't past beyond 1st area (intro miniboss).
From the user panic i`ve extracted these strings:
> GlobalState.request_next()
> save_state_to_saveGame(...)
> platform.ProcessSave()
> bin_serialize_to_file(...)
> StandaloneTypeModel.Write(SaveGame, ...)
> Write(SaveGame.AdventureSaveSlot, ...)
> Write(PlayerState, ...)
> ProtoBuf.ProtoWriter.WriteString(...) + 0xcc
> ProtoBuf.Helpers.DebugAssert(...)
> Debug.Fail(...)
By debugging ProtoBuf.ProtoWriter.WriteString(...) argument it was found that the string Отлично! (Great! expression for combos between 6 and 30 iirc) was reaching a size comparison of different values and causing an assert in guest side..
It seems the game tries to save highest combo level. I've managed to skip this bug by doing a perfect combo for entire level, so that the problematic word never was generated or attempted to be saved.
After further research, the issue chain was identified: Game maths literal string size via two ways and compare, and one of them was getting replaced by a wrong value due to Eden letting the literal string be interpreted as a real instruction.
Logic added:
const bool pair = decltype(l)::ExtractValue(raw) & 1;
const bool fixed_rt2 = decltype(rt2)::ExtractValue(raw) == 0b11111;
return pair || fixed_rt2;
- pair checks bit 21 (L & 1): register-pair instructions actually use Rt2, so they remain accepted.
- For single-register forms, require Rt2 == 31. The table word fails this check, so NCE leaves it intact.
Sources
https://www.scs.stanford.edu/~zyedidia/arm64/stxrb.htmlhttps://www.scs.stanford.edu/~zyedidia/arm64/stxp.htmlhttps://github.com/qemu/qemu/blob/master/target/arm/tcg/a64.decode#L344
Altough the solution is a case specific guard, it is data agnostic: This is a true fix to avoid a specific case in which a literal may be interpreted as a valid instruction, without interfering with other true instruction cases.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4369
Reviewed-by: lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
lizzie