Alphakill

That sounds very wrong. Either that or my basic knowledge of emulation is very wrong.
Okey, here we go!

What is emulation?
Emulation is (usually) software, that behaves like another hardware/system would behave.
This means, that the software will need to emulate the processor, RAM, instruction set, GPU, or whatever other stuff the hardware has (interrupts, IO registers, timings, etc).

What is HLE emulation?
HLE (High Level Emulation) is a process, where calls to the libraries of the system (in this case the modules for the interaction with hardware) are replaced with calls to code, that (should) behave and perform the same actions and output, as the calls on the system itself.
For an example, a call to a file system library, would be replaced with a custom function in the emulator, that takes the inputs given to the function, then calls the file system libraries on the current system/OS.

What is LLE emulation?
LLE (Low Level Emulation) is a process, in which calls to the libraries of the system are emulated using the actual instructions, that would be executed on the system. This usually means obtaining the BIOS/firmware files, that include the instructions, and then interpreting and emulating them same as they would be executed on the system's CPU. This is almost always slower, but a lot more accurate.

This is the basic gist of HLE vs LLE, from what I know and understand. Probably a couple mistakes slipped by, and I'd appreciate if they would be corrected.

There are probably '''levels''' of HLE and LLE. Rpcs3 seems to be high level LLE then because emularors like Dolphin, PCSX2, all PS1 emulators and almost all emulators of old 2D consoles indeed emulate actual hardware not just calls so basicaly create virtual version of hardware down to hardware registers.

http://forums.pcsx2.net/Thread-How-is-th...#pid362981

Well it's important to note that it has nothing to do with skipping the boot process, as PCSX2 can also do that on 'fast boot' mode Wink
What is the difference? Well, a LLE emulates the state of an entire Virtual Machine; that is, it is running a guest kernel (in the case of PCSX2, a BIOS) and can run unmodified software; this is because it does more than just wrapping calls to the kernel and translating them for the native kernel, it actually emulates a virtual hardware that the guest kernel interacts with and translates those interactions to the host kernel calls. Let me give you an example:

a HLE has a running piece of software that calls the kernel function 'drawSquare':
The equivalent function is found on the host kernel and is ran.

a LLE has a running piece of software that calls the kernel function 'drawSquare':
The virtual kernel IS running inside the virtual machine, and this virtual machine has a virtual GPU; the kernel runs drawSquare
drawSquare runs a routine on the GPU driver that sets the virtual Video Memory to display a square
A translation is done by the emulator to display the raw virtual Video Memory as a window on your host system.

The LLE approach is harder to understand but let us imagine a 3D game running on Windows XP running on VirtualBox on Linux:
The game calls a DirectX 9 function
The Windows kernel calls the equivalent function(s) on the GPU driver
The GPU driver runs the code as it would on the emulated GPU and sets a HW state
The image is drawn on-screen.

Modern emulators are a lot more complex than that an actually translate virtual calls to DirectX into OpenGL for example, and run it on the host, to improve performance.

This is the reason why PCSX2 can run the PS2 BIOS but RPCS3 can not run the PS3 OS:
The PS3 OS expects to interact with hardware which is NOT emulated and hence cannot run; instead calls to the kernel are wrapped and emulated by RPCS3, removing the need for the OS dump.
The PS2 BIOS expects to interact with hardware which IS emulated, hence it does make changes in the virtual hardware that PCSX2 can then convert to native system calls.

We need to emulate the hardware, to an extent, otherwise we wouldn't really be an emulator.
We don't emulate simply emulate "calls", games can call some system calls and stuff to interact with trophies, PSN, save data, etc, but they still execute their own code and stuff.

I'm not sure how we aren't emulating the "hardware". We emulate the instructions for the PPU and the SPU, and for RSX we simply emulate the features of the RSX to the modern day equivalent, like basically all other emulators.
Also, technically you're able to boot the "OS" (vsh.self). But the OS uses a lot of undocumented and weird features, so it obviously doesn't work.

At this point I'm kinda confused at what you're even asking, maybe someone else can chime in and actually answer you.

1. So I get from this that RSX has some stencil buffer features not supported by modern PC gpus? Can it use early Z or Stencil rejection/test? Are depth and stencil buffers in RSX combined or still separate?
2. How do you emulate triangle fans in D3D12. Triangle fans were deprecated in D3D10.
3. What is the highest MSAA level supported by RSX and does it support SSAA as well or just MSAA? I guess 4xMSAA but it was too weak so games probably used 2x only at best.
4. Have you emulated mipmapping and LOD already and do you directly emulate RSX texture cache? Is texture caching crucial for accuracy of PS3 emulation like it is for example for PS2 emulation(PCSX2 has many errors and unemulated functions like mipmapping due to botched texture cache design)?
5. How difficult do you think it would be to emulate modern tile-based deferred renderer like Power VR SGX543 in PS Vita or even Pica200(it has combination of vertex shaders and fixed functions) in 3DS compared to RSX?
6. I noticed rpcs3 has LLE mode now. Do you emulate Cell and RSX at the register level?

1. Maybe the feature is implemented in GPU, but not exposed by D3D. Maybe Vulkan will expose it.
Depth and stencil buffers are combined. Btw you say "still" but actually modern gpu tend to separate them : gcn has separate depth and stencil buffer.
2. I'm using triangle list mode and modify the index buffer to mimic the behavior. Could be done by Geometry Shader but capturing the first index and broadcasting to other GS instance may be hard and not worth it since triangle fan is quite rare anyway.
3. It supports 2x and 4x MSAA. Don't know what you call "SSAA" there's so many AA technics these days... If it's Super Sampling AA then it's "supported", basically SSAA renders the scene to a high resolution and downsample it before presenting it. I think almost gpu can do it as long as they support texture bigger than their framebuffer. However it's too costly for practical use.
4. Yes mipmap and lod are emulated right now (at least in d3d, gl backend doesn't emulated mipmaping yet). I don't emulate texture cache, there's no need to since the functionnality is happening on the RSX and is barely exposed to PS3 dev. It's likely different from PS2 design though. Gpu cache are designed to be completly transparent (like cpu cache).
5. I don't know, depends on what is exposed by the platforms API/command queue. OpenGL ES doesn't expose deferred tile functionnality for instance and thus it's completly transparent for android dev. Vita and 3DS may expose more thing but they can also hide it. Tiled gpu rendering is like cache hierarchy, it's more an hw design than a "feature" exposed to developper and as such it's intended to work transparently.
Mixing fixed function and programmable pipeline is not more difficult to emulate per se but likely requires some bookkeeping and finer understanding of priority (ie when does the vertex shader kick in ?) which is likely to make things error prone.

Hello guys, I need answer, everybody talk about rpcs3 and dx12, so question is do I have to install windows 10 for better emulation and dx12 support ?
My gpu is gtx 960 and I use windos 7. Thanks

Hello guys, I need answer, everybody talk about rpcs3 and dx12, so question is do I have to install windows 10 for better emulation and dx12 support ?
My gpu is gtx 960 and I use windos 7. Thanks

Once again, why post here? I have issued you a warning.

Sorry, I just do not want to create ew thread That's all.

As far as I know there's only a single proper lle emulator, znes for the snes. It simulates chip inner working up to cycle accuracy.

Others emulator use hle to some extent : for instance gpu inner working are not really documented, dev only have access to the "reaction" of gpu to some inputs. Cpu increasing complexity also prevent accurate emulation : you can execute the instruction on the host hardware but chances are that latency are different, not accounting that no interpreter or compiler mimic cpu cache, cpu instruction reordering or track branch instruction path.

Today lle and hle are used to qualify library. An lle Emu will execute library code with the same interpreter/recompiler as the game is using. An hle Emu will catch system library call and execute an equivalent native one.
Of course the barrier is moot since lle lib can call library function too, so there's likely a small irréductible set of function that needs to be written with a native implementation : ps3 has 2 level of libs, lv2 are accessed by games and make use of lvl 1 level which exposes "kernel like" features that need to access mmu.

---

Another thing that worth mentioning is that lle module are not redistributable. Lle emulator can't be proposed on store like Google play or Steam since they can't work out of the box. I know that this doesn't sound like an important feature but lately psx games are sold on Steam, some game controller are designed with Dolphin compatibility in mind and so on. This can only happen if it's considered legally safe to do so.

As far as I know there's only a single proper lle emulator, znes for the snes. It simulates chip inner working up to cycle accuracy.

Others emulator use hle to some extent : for instance gpu inner working are not really documented, dev only have access to the "reaction" of gpu to some inputs. Cpu increasing complexity also prevent accurate emulation : you can execute the instruction on the host hardware but chances are that latency are different, not accounting that no interpreter or compiler mimic cpu cache, cpu instruction reordering or track branch instruction path.

Today lle and hle are used to qualify library. An lle Emu will execute library code with the same interpreter/recompiler as the game is using. An hle Emu will catch system library call and execute an equivalent native one.
Of course the barrier is moot since lle lib can call library function too, so there's likely a small irréductible set of function that needs to be written with a native implementation : ps3 has 2 level of libs, lv2 are accessed by games and make use of lvl 1 level which exposes "kernel like" features that need to access mmu.

---

Another thing that worth mentioning is that lle module are not redistributable. Lle emulator can't be proposed on store like Google play or Steam since they can't work out of the box. I know that this doesn't sound like an important feature but lately psx games are sold on Steam, some game controller are designed with Dolphin compatibility in mind and so on. This can only happen if it's considered legally safe to do so.

http://ngemu.com/threads/partial-hle-in-...uff.10672/
http://ngemu.com/threads/perspective-cor...hat.21080/
http://ngemu.com/threads/a-crazy-idea-fo...ins.26213/

'''Now back to your question! HLE is done on N64 emulators to by pass emulating the instructions that are queued for rendering the graphics. HLE knows that there are function calls in the N64 dev kit and looks for those function calls. It reads the information passed to it and fakes rendering the information passed to the low level GPU. Doing this on the PSX might be much more challenging since many games really don't have a decipherable pattern from the SONY dev kit. There are many high level functions that this can be done with.. I don't think the GPU is that easy to do it with. The PSX uses a 'bios' whereas the N64 has no real bios, the ROM is the boot loader. Bios functions are emulatable as well.. the end situation is.. it's not the same animal as the N64.

I think you could refer to HLE as "static precompilation" - it uses native code that has been compiled before execution of the emulator.
You have to be careful with terms like LLE and HLE, because they are dependant at what level you are analysing a system - how low is low, how high is high?. I am sure that statement will confuse more people than will understand it!'''



You mean bsnes because zsnes while LLE is far from accurate.
I noticed everyone has different definition of HLE and LLE.
In my opinion emulator doesn't need to be cycle accurate to be LLE because HLE and LLE are just methods so no matter how innacurate zsnes is it's still LLE.
What do you mean by modules and working out of box? If you mean bios then they can sell without it. LLE emulators of older consoles don't really use any modules since they don't emulate any libraries just hardware by simulating registers according to a guy who was PS1 GPU plugin developer. From what I read consoles like Saturn and PS1 didn't really have any standardized library unlike PS3 every company used their own so HLE emulation of these consoles probably would had to be done on per game basis. There are LLE emulators on Google Play like ePSXe and FPse and also some Gameboy, Nes and Snes emulators and ePSXe even has HLE bios emulation even though overall its LLE.
Defintely if GPU isn't documented/reverse engineered enough so that functions of registers aren't known and in effect they aren't directly emulated then this is probably HLE in my opinion(or inaccurate lle if only some are emulated).
Are RSX/Cell registers documented at all and do you emulate their functions?

By the way what do you think is harder emulating fixed functions with shaders or emulating shader with well shaders. I heard opinions that older consoles are harder to emulate than PS3 for instance because PS3's gpu is more similar to PC architecture.

You mean bsnes because zsnes while LLE is far from accurate.

Yes sorry

I noticed everyone has different definition of HLE and LLE.
In my opinion emulator doesn't need to be cycle accurate to be LLE because HLE and LLE are just methods so no matter how innacurate zsnes is it's still LLE.
What do you mean by modules and working out of box?

Some PSX era emulator needed a Bios dump in order to launch any game. Same for PCSX2 which doesn't run without a Bios (but I didn't tested lately).
Bios is copyrighted material, as well as system library (what rpcs3 calls "LLE Module&quot. You can dump them from your own console (and only if your country doesn't have a low that forbid that which is not true everywhere) but you can't redistribute them.
This means you can't sell an emulated PS2 game on Steam or GPlay except if you have Sony's approval even if you own the right for the game.

Of course as you mentionned older console didn't have standardised lib so if you HLE Bios you can sell the game. That's how Console Classics does, they use PCSX-R since it doesn't require a BIOS AFAIK.
In order to sell emulated PS3 game the underlying emulator needs not to use "LLE Module" but provide a custom implementation.

Defintely if GPU isn't documented/reverse engineered enough so that functions of registers aren't known and in effect they aren't directly emulated then this is probably HLE in my opinion(or inaccurate lle if only some are emulated).
Are RSX/Cell registers documented at all and do you emulate their functions?

By the way what do you think is harder emulating fixed functions with shaders or emulating shader with well shaders. I heard opinions that older consoles are harder to emulate than PS3 for instance because PS3's gpu is more similar to PC architecture.

RSX Registers are mostly documented, either by previous reverse engineering attempt or by the nouveau project (since RSX is very close to G70).

I don't think it's harder or easier to emulate fixed function or shader based gpu. It's different kind of work.
I never emulated a fixed function pipeline but I guess most of the work goes into guessing what is the influence of a given register on the final result ; you need to have a good "uber shader" or shader generator that cover all cases correctly, up to the floating point precision.
With shader based gpu you need to correctly understand shader opcode and their difference from IEEE standard. Since RSX is also not completly shader based there's also influence from external register (two sided lighting, transform program input/output, vertex attributes...) that needs to be properly sorted too.

Being close to PC architecture doesn't mean it's easier to emulated. First Xbox was the closest to PC architecture of the 6th generation and yet it's still far from being correctly emulated. And I guess it will be the same for PS4/Xbox One especially with the HSA functionnality that has currently no equivalent (except on Linux with (some) Amd APU).

In my opinion emulator doesn't need to be cycle accurate to be LLE because HLE and LLE are just methods so no matter how innacurate zsnes is it's still LLE.
What do you mean by modules and working out of box? If you mean bios then they can sell without it. LLE emulators of older consoles don't really use any modules since they don't emulate any libraries just hardware by simulating registers according to a guy who was PS1 GPU plugin developer. From what I read consoles like Saturn and PS1 didn't really have any standardized library unlike PS3 every company used their own so HLE emulation of these consoles probably would had to be done on per game basis.

Per game basis? What? The library is included with the game, so you just execute the instructions of the library on your emulator, if the game calls a function of their library.
I think vlj explained the HLE/LLE for PS3 quite well.
HLE in RPCS3 is simply replacing system calls with our own implemented functions.
LLE in RPCS3 is simply loading the firmware files and executing the instructions of the function, when they're called.