Release of External Software Rendering for JPCSP

[gid15]

Dear JPCSP community,

after several months of development, a new rendering engine is now available for Jpcsp. This new engine is implemented as an external library. It works on 32 and 64 bit versions and supports SSE4.1 or AVX2 instruction sets if they are supported by your processor. A non-SSE version is also available. Currently, only windows systems are supported.

The rendering is completely performed in software, i.e. without using the GPU or OpenGL. It was developed with speed (using latest CPU features) and compatibility (implementing all PSP features) in mind. The goal was to be free of the OpenGL limitations and GPU driver bugs. It is still a work in progress and not all features are yet implemented, also further speed improvements are in preparation.

As this is a software renderer, the display speed is mainly based on the power of your CPU and the complexity of the rendered scene. Screen scaling (e.g. x2, x3) is also supported but will increase the rendering time.

This is a joined work between hlide and gid15. shadow also provided the automatic build and hosting on emunewz.

The compiled libraries (DLLs) can be downloaded in the emunewz "Live Downloads" section:
http://www.emunewz.net/forum/builds.php?filter=last

Please test it and feel free to report compatibility issues in this thread.

Enjoy!

[MaXiMu]

Nice I detected some bugs

I tested I7-3632qm with SSE4.1 version

bubble puzzle out small artifacts and is slow compared to internal software 20fps-60fps

In Ridge Race 2 having trouble viewing the mirror but is not unique plugin and happens in internal software.

Dragon ball budokai has errors graphics on green floor

[nickblame]

awesome release!

[MaXiMu]

I have one question will be in a future version support first version AVX? or not much help compared than SSE4.1 ?

[gid15]

I have one question will be in a future version support first version AVX? or not much help compared than SSE4.1 ?

AVX only supports operations on floating point values whereas AVX2 introduced operations on integer values. We currently use integer operations in the pixel shader (like the PSP), this is why AVX doesn't help and AVX2 is required.

[MaXiMu]

I see thanks for the explanation

[hlide]

bubble puzzle out small artifacts and is slow compared to internal software 20fps-60fps

@gid15: the recent addition of bezier drawing seemed the issue. As far as I know the implementation of bezier drawing in pspe4all was perfect (I tested with a lot of samples with more complex bezier drawing) so it should be the same here.

[gid15]

bubble puzzle out small artifacts and is slow compared to internal software 20fps-60fps

@gid15: the recent addition of bezier drawing seemed the issue. As far as I know the implementation of bezier drawing in pspe4all was perfect (I tested with a lot of samples with more complex bezier drawing) so it should be the same here.

The BEZIER should now be fixed in the software renderer fadcf74.

[hlide]

I have one question will be in a future version support first version AVX? or not much help compared than SSE4.1 ?

from my experience, only SSE4.1 and AVX2 are interesting enough to support.

SSE4.1 has enough instructions to handle up to 4 pixels per operation efficiently
AVX2.0 has enough instructions to handle up to 8 pixels per operation efficiently

AVX is too incomplete to be efficient.

Renderer is extremely dependent about cpu power. Right now, it is mostly executed in a mono-core fashion. While a parallel execution of several cores is possible (@gid15? is that stuff working or is it just a wip?), I'm not sure it is safe or efficient enough to use it. Personally I think it needs some rethinking as I really don't like to let Java uses threads to make parallel execution.

Renderer is not dynamically generating assembly code in all case as I wish. While some vertex operations are done this way, pixel operations are still not done this way (they are just a chain of static pixel operations). Compiler can make a good job but static code are still limited in flexibility. Note that the fact you must support both x86 and amd64 makes the dynamic generation of assembly code much harder as they have too many subtle differences that prevent from sharing common source.

[MaXiMu]

These errors on Bubble puzzle and dragon ball now fixed

My reports tested by this processor http://ark.intel.com/es-es/products/6490...10-GHz-BGA