About LLE emulation

Required modules are determined manually by imported functions reported in logs and testing. Plus it's possible to create per-game config.

I would also like to add, from my results of the search, he has deceased.

That's horrible

There's nothing really to develop for LLE. It works fine as it is, and if we'd like to get all games working perfectly, we could simply improve non-HLE areas, to increase speed and RSX emulation accuracy.

So is that it really? Execute some cellSpursFile.elf or whatever and you will have The Last of Us running with some improvements to RSX? Can't be that "simple" surely? (What I mean is that looking at the current state of rpcs3, is that really the only big thing left now?)

There are likely still PPU and SPU emulation accuracy problems, possibly preventing modules and games from being emulated properly. One example is likely, that GTA V with LLE seems to fail, due to SPU emulation inaccuracies. RSX emulation seems to currently be the main thing blocking most of the games from working. Nekoteki could probably correct me or elaborate on the subject of the various backend problems.

Of course, the ultimate goal would be to have everything HLE'd, so everything would work out of the box, and you could modify tons of settings, maybe even add graphical improvements, higher internal resolution, etc.

I don't know inner workings of PS3 architecture but I don't think you need HLE for things like higher resolution, antialiasing or even texture replacement. Dolphin can do all of that with LLE and many other LLE emulators can increase resolution too.

LLVM is interesting to mess with to say the least but it may just be "ps3 firmware beginners luck"
Quick question if I have a older system is there a preferred system version? OFW/CFW 3.55? 4.11 4.20? yes OFW dump


Long live DAX

That's horrible
So is that it really? Execute some cellSpursFile.elf or whatever and you will have The Last of Us running with some improvements to RSX? Can't be that "simple" surely? (What I mean is that looking at the current state of rpcs3, is that really the only big thing left now?)

There are likely still PPU and SPU emulation accuracy problems, possibly preventing modules and games from being emulated properly. One example is likely, that GTA V with LLE seems to fail, due to SPU emulation inaccuracies. RSX emulation seems to currently be the main thing blocking most of the games from working. Nekoteki could probably correct me or elaborate on the subject of the various backend problems.

Of course, the ultimate goal would be to have everything HLE'd, so everything would work out of the box, and you could modify tons of settings, maybe even add graphical improvements, higher internal resolution, etc.

Fair enough. Somewhat off topic but still kind of related, but has Vlj (or someone else) considered looking at writing a Vulkan renderer when the spec and developer resources are published?

I think he mentioned that will take a look. I also would prefer, if all other renderers were to be removed in favour of the Vulkan renderer, as from what we currently know, it includes all the benefits of DX12, with less of the negatives.

Remove all renderes? No, there is no point in that. Opengl 4.4 might be last Glsl language used (unfortunately because amd) + newer extensions, just for legacy hardware. And if that not enought there will be more verions released https://www.phoronix.com/scan.php?page=n...ot-The-End
DX12 and vulcan would be dedicated for the newest hardware with good driver support.

There are likely still PPU and SPU emulation accuracy problems, possibly preventing modules and games from being emulated properly. One example is likely, that GTA V with LLE seems to fail, due to SPU emulation inaccuracies. RSX emulation seems to currently be the main thing blocking most of the games from working. Nekoteki could probably correct me or elaborate on the subject of the various backend problems.

Of course, the ultimate goal would be to have everything HLE'd, so everything would work out of the box, and you could modify tons of settings, maybe even add graphical improvements, higher internal resolution, etc.

Fair enough. Somewhat off topic but still kind of related, but has Vlj (or someone else) considered looking at writing a Vulkan renderer when the spec and developer resources are published?

I think he mentioned that will take a look. I also would prefer, if all other renderers were to be removed in favour of the Vulkan renderer, as from what we currently know, it includes all the benefits of DX12, with less of the negatives.

Remove all renderes? No, there is no point in that. Opengl 4.4 might be last Glsl language used (unfortunately because amd) + newer extensions, just for legacy hardware. And if that not enought there will be more verions released https://www.phoronix.com/scan.php?page=n...ot-The-End
DX12 and vulcan would be dedicated for the newest hardware with good driver support.

Legacy hardware? Might as well add 32-bit support back then!
Not like you're going to be able to run any PS3 game decently on older hardware. Not only that, but Vulkan and DX12 include many benefits to more easily and a lot faster emulating the RSX chip.

OpenGL is simply old and horrible, and needs to die in favour of a full reboot, in my opinion. And Vulkan is the replacement. OpenGL will likely continue to coexist, due to porting problems and legacy needs likely, though.
I personally in my own projects (and emulators) have fully avoided any graphics things for the past 2 months. Context creation is absolutely shit, I can expect my result to probably not work on AMD drivers (though that's more or less Nvidia's fault) and I need 3rd party libraries to be able to decently use extensions. You also need an OpenGL context to create an OpenGL context for rendering.

Thanks for explanation, i always like to read some tech stuff even im not developer. I believe there are some pain in developing application with opengl. Anyway, some speed concerns are adressed by AZDO modern opengl programming, with modern arb extensions. Not sure what advantages are for emulation tasks. Because i dont want to be considered living only with theories, lets show example of cemu emulator, which emulates wiiu and ofc gpu of it. It has quite good speed as for being only interpreter for cpu. No intention in comparing emulators, just nice talk of my side

Having developed something with azdo in the past I can tell that it helps lowering cpu overhead by a wide margin but it's still cary most of opengl flaws. Draw call generation still happen in a single thread for most task (but gfx thread in emulator are single threaded so it's not really an issue here) and you don't have a lot of control over resource lifetime management or command queue flush.

Just as a note to anyone would like to try the LLE with sprx files.
All you get from 3.55 or 4.00 PUP files aren't enough; you're missing files from 1.50 CEX/DEX release.
At least libspurs.sprx exists in 1.50 but no such files in 3.55. And i don't know if there is any similar modules.
Still PPC assembly looks quite a problem for me. Hope this file helps you understanding the cellSpurs.

cellSpurs = cellSre

cellSpurs = cellSre

Well i checked the file and find such symbols.
It seems i've found the old file `libspurs.sprx` which is obsolete.
Ok my knowledge is quite out of date. And glad that is, thanks.