Editing Talk:High/Low level emulation

== UHLE not explained ==

The article is too simplified, it only considers 2 concepts, when in reality it's 3.
The issue with Cxbx-Reloaded in particular, is that it's not just HLE, but UHLE (the more aggressive version of HLE).

There's 3 different approaches which are typically categorized: LLE (Low Level Emulation), HLE (High Level Emulation), UHLE (Ultra High Level Emulation).

HLE was done even before the UltaHLE emulator (not sure if we called it HLE then). But UltraHLE introduced an aggressive optimization and time-saver which goes beyond traditional HLE. This is what I (and I've seen others do it) call UHLE (named after UltraHLE).

Unfortunately, UHLE and HLE are often mixed up, which has lead to much confusion and misconceptions.

If you think about emulation as recreating different "layers" of a system, then you can think of it like this:

A console game is (from high-level, to low-level): "game" running on "OS", running on "hardware".

*LLE: recreation of the hardware interfaces [emulator "is" hardware; runs OS and game]
*HLE: recreation of software interfaces [emulator "is" OS; runs game - does not care about hardware]
*UHLE: modification of the game software to work *somehow* [emulator "is" game - does not care about hardware and OS]

''(in practice we often have less/more layers; example: some platforms mix OS and game together, in that case: "game-OS-mix" running on "hardware")''

An analogy from the real world: You live in a house, 3 strangers visit, everyone of them concludes "wow, that's a cool house, I'll copy [emulate] that!".

*Stranger 1 - LLE: he walks through your house, takes careful notes and reconstructs it *exactly*. He basically cloned your house. It took him a long time to document everything, and even longer to rebuild it accurately.
*Stranger 2 - HLE: he really likes the layout of your house, but he doesn't care about your paintings on the wall. He mostly cares about copying the functionality of your house, so the windows and doors are in the right spot, but the rest doesn't matter. He barely needs any notes, construction is faster, but he makes certain assumptions ("I'll never want those paintings").
*Stranger 3 - UHLE: he takes some drugs until he believes he lives in a house like yours. It's easy, it's fast, but fundamentally wrong.

Transfer back to software:

* Now if you were to visit the LLE Strangers house, you could find things easily, it feels like your house. In terms of emulation, games behave the same way, games are not aware of the changes (everything feels correct, you have an almost exact replica).
* If you were to visit the HLE Strangers house, you'd still feel like at home, but you can't admire your paintings (to be frank: you rarely do that anyway). In emulation this means, that the game might work generally fine, but if the game tries to do things which are not common, then you are out-of-luck. Typically the assumptions made, are *very* safe in HLE, so generally all games work, but some system software which does something special, might not.
* The UHLE Stranger is a lost cause, his "house" was quick to "build", but to visit him, requires changing your mind. Similarly, if you want to emulate games with UHLE, you don't emulate hardware, but you replace the game code [the games mind] which perceives the hardware (you can't touch the walls - there are no walls).

There's also certain limitations with each approach:

*LLE is always possible: "recreate hardware in software". As the console hardware doesn't change over time, this is always future-proof.
*HLE is only possible if you can find a working subset / make assumptions like "nobody will ever want to look at the paintings". In terms of emulation this barrier is typically: "nobody touches the hardware directly" / "I only need to emulate the functions which acccess hardware" (typically the OS). But maybe one day he wants to look at those paintings after all? / "oops! new games suddenly touch the hardware"; so this is not future-proof.
*UHLE is almost always possible, but it's dangerous. It replaces the actual emulation with hacks to move emulation into the games code. However, game code is different for every game. In some cases, you can apply the same hack to more than 1 game, in some cases you can't. So this is labour intensive if you care about more than 1 game. It also isn't future proof: for every new game, you might need new hacks.

This example is not ideal (there's further pros/cons like requiring ROMs for LLE), but it's the general idea.


You can safely use UHLE as optimization in LLE or HLE projects (but only in very limited quantity). The issue is that most pure UHLE projects (especially Xbox emulation) are much more aggressive.

-- JayFoxRox 02:15, 5 January 2019 (EST)

== Creating pages for other terms ==

*Pixel pipeline emu. techniques such as "Ubershaders": 
*ahead of time (AOT) recompilation (and LLVM ofc).
*GPU emu. techniques such as "Hardware rendering" vs "Software rendering" and performance options for software approach such as: multithreading and using recompiler (software renderer multithreading shouldn't be confused with vulkan API backend multithreading/threaded presentation feature)
::''vulkan API backend multithreading/threaded presentation option has actually existed for some time in various emulators that implemented Vulkan renderer backend. What it actually does is when the CPU wants to make something draw it has to issue a "draw call" which takes up CPU time, on old APIs this was nearly all done on one thread, the reason for that is different threads can't access other threads data (quickly) if it's being updated and because of how it used to be done, you needed to synchronise threads a lot and that meant that using lots of threads ended up not always being too helpful, in Vulkan because the person using the API is more explicit about how they want their memory and what have you allocated and used it's easier to submit "draw calls" on multiple threads so it (usually) performs better because it's designed to avoid the issues of older APIs.''[https://old.reddit.com/r/DolphinEmulator/comments/ckfes1/back_end_multithreading_with_vulkan_how_much_of_a/evrbv2h/]

:Software renderer section;
::*cen64 (which has multithreading option)
::*[[Recommended_N64_plugins#Angrylion_RDP_Plus|Angrylion RDP Plus]] plugin (which has multithreading option)
::*MAME
::*Some of the standalone emulators has software renderer option such as [https://wiki.pcsx2.net/Category:Software_rendering_only_games PCSX2 (which has multithreading option)], [https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoBackends/Software/SWRenderer.cpp Dolphin], melonDS, [https://github.com/stenzek/duckstation/blob/master/src/core/gpu_sw.cpp DuckStation]
::*[[POS_(Pong_Consoles)_CPUs_and_Other_Chips#Hardware_support.2C_features_and_peripherals|DOSBox forks for Voodoo emulation, 86Box and PCem for various 3D accelerators]] (which have multithreading option)

:Hardware renderer section;
::*[[Windows_2000/XP/Vista_emulators#Type_2_Hypervisors|Type-2 and Type-1 hypervisors virtual gpu adapter]]
::*Majority of standalone emulators has hardware renderer option using various backends such as Vulkan, D3D11-12, OpenGL etc.

refs;
*https://dolphin-emu.org/blog/2017/07/30/ubershaders/
*https://fosdem.org/2024/schedule/event/fosdem-2024-1726-panda3ds-climbing-the-tree-of-3ds-emulation/
*https://llvm.org/pubs/2010-01-Wennborg-Thesis.pdf
*https://wiki.cemu.info/wiki/Roadmap

[[User:Ahayri|Ahayri]] ([[User talk:Ahayri|talk]]) 21:15, 10 February 2024 (UTC)