Greg/gsdx 64b

[gregory38]

AVX/x64 implementation of GSdx JIT compiler. So far, perf sucks. -20% to -10% versus 32 bits.

With hard work, it might be possible to reach the 32 bits performance level (or close enough) but it is really a low priority. At least, we can run, test and dev on a 64 bits GSdx.

[willkuer]

Do you run the core in interpreter? How do you benchmark? In GS replayer?

[gregory38]

Yes I benchmarked without the core through the replayer. Interpreter will be too slow and I have additional timing info on the replayer.

Here an example on HW renderer (but it is the same).

Performance Profile for 53 frames:
Min  1.40 ms    (711.80 fps)
Mean 7.50 ms    (133.31 fps)
Max  13.54 ms   (73.88 fps)
SD   3.72 ms

Frame Repartition
  0 ms =>   2 ms       1
  2 ms =>   4 ms      16
  4 ms =>   6 ms       9
  6 ms =>   8 ms       0
  8 ms =>  10 ms       7
 10 ms =>  12 ms      15
 12 ms =>  14 ms       5
 14 ms =>  16 ms       0

Edit: I benchmarked with the turbo off to avoid variation.

[willkuer]

Interesting that the histogram shows two maxima. Maybe one can improve the bottleneck of the slower one.

Have you tried with different compiler? I guess compiler can be important here.

Also do you know the bottleneck is in gsdx and not in the gpu driver? Maybe calling the driver from 64bit results in differences?

[gregory38]

Above was an example on the hw renderer (32 bits). I didn't test the hw renderer but it could be interesting. It is less critical on the hw renderer (often gpu limited)

Some frames are nearly empty (internal 30 fps). So they are quick to render.

[gregory38]

By the way, if someone can test the SW renderer on 32 bits with all ISA. I want to avoid regression due to code factorization.

[gregory38]

I pushed additional change to select the ISA (SSE2/SSSE3/SSE41/AVX1) at runtime.

It only impact the self-generated code (AKA the SW renderer). Nevertheless (if I manage to compile it on VS), it make

• SSSE3 build useless
• AVX1 build mostly useless

So in the future, we could limit it to SSE2/SSE4.1/AVX2.

[gregory38]

@turtleli
Could you help me to fix the compilation issue on Windows? Are AVX files (aka *.x86.avx.cpp) compiled on SSE windows build ?

Edit: it seems there are some black-magics in ./GSdx.vcxproj

[turtleli]

Yeah, it's the exclude build stuff.

Fix for 32-bit Windows build (64 bits doesn't compile because __x86_64__ in stdafx.h isn't defined on Windows) - https://gist.github.com/turtleli/a05906730b9b885d5dde2e862440238f

[gregory38]

Thanks for the patch.

[gregory38]

Let's go. The best way to have some test coverages 👍

[willkuer]

Did I understand correctly that this pr solved #796?

Ah I see. It only solves it partially.

[gregory38]

No. It is only a step forward. You have the C code, and you have the code generated by the C itself which is then executed. The latter is used by the SW renderer.
In case of SSE2 up AVX1 build, the generated code will be based on your CPU capabilities. However all C code will depend on the compilation flag.

However, I think SSSE3 and AVX1 build are useless now (I hope I won't have AVX penalty).

[mirh]

Mhh.. is this affecting #357 then?

[gregory38]

Well it was only a stub (on gsdx sw) to allow the compilation (used to crash). New code is working.
The limitation

• mipmap isn't implemented
• no AVX2
• no SSE but any CPU that support AVX will pick up the AVX version (~70% of the users)

Tbh, AVX2 will be done. But I don't think pure SSE will be done. It is too slow to worth it.