Alphakill

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.

I understand this is how it works in rpcs3 however it seems they emulated old consoles differently. That's not my opinion but guys who worked on PS1 plugins said HLE for PS1 would have to be done per game basis that's why nobody has done it yet. N64 libraries are much more standardized than PS1's yet there are still problems to this day with HLE emulation of unique or rare RSP microcodes.
According to this N64 HLE is simply bypassing direct RSP emulation and emulating microcodes instead.

http://gliden64.blogspot.com/2014/11/a-w...r-hle.html
http://gliden64.blogspot.com/2014/11/lle-is-here.html

HLE vs. LLE in N64 emulation

'''For a long time HLE was key feature of N64 emulation. All N64 games use a library for render audio and graphics. The library runs on powerful multimedia Reality Co-Processor, RCP. RCP actually consist of two parts: programmable Reality Signal Processor, RSP, which executes graphics and audio tasks, and Reality Display Processor, RDP, which draws the graphics in the frame buffer. The library, known as microcode, is loaded into RSP and controls its work. That is it defines how graphics and audio tasks must be performed. HLE emulators implement the microcode and thus bypass emulation of very powerful module, which can perform many scalar and vector operations per cycle.'''

---

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).

Do you know how many layers of mipmapped textures can RSX uses at most? I know PS2 can use 7 levels. Another important question is how many cores can rpcs3 use? Would it benefit from buying 10 core Broadwell-E?

It can benefit from as many cores as the game uses. PS3 has a total of 8 "cores" (1 PPU, 7 SPU). So if you have more cores, it might help. Though most games use very few SPU cores, from my experience.