Improve approximate xfloat

[plappermaul]

• Disable denormals for SPU threads
• add clamping helper
• rewrite multiply_zero()
• make use of FMA if possible

[Xcedf]

Yes, PR fixes #6616, and works with other games so far, but why removing Default path?

[plappermaul]

Yes, PR fixes #6616, and works with other games so far, but why removing Default path?

default path restored in updated PR

[Xcedf]

I'm not sure this is good place for requests but anyway, it will be nice if approximate version of FS will be added, it used by Just Cause 2 to render graphichs and by Uncharted 1 for grenade sequence more info is here in my old issue #4478.
For me it's not a problem to build for myself and switch between different instructios but i'm sure for average user use Accurate Xfloat or be even with severe bugs is quite eshausting.
based on your changes i tried smth and it worked:
const auto a = eval(clamp_smax(get_vr<f32[4]>(op.ra)));
const auto b = eval(clamp_smax(get_vr<f32[4]>(op.rb)));
set_vr(op.rt, a - b);

[plappermaul]

Hopefully Windows integration works again now...

@Xcedf: Regarding FS() problems. We want to make approximate xfloat as good as possible. So we should implement every needed fix. To keep overhead as small as possible I want to ask you to test the following things:

FS(): only clamp one of the two variables. If that does not help, clamp the result. Maybe we can live with only on fix.

FM(): remove clamping. FMA(), FNMS() and FMS() do not need it, sow why should FM()? Maybe we are fine with the new multiply_zero() function.

[Xcedf]

@plappermaul don't have time to test FM today, will do tomorrow, as for FS:
clamping only a - not working
clamping only b - working
clamping res - not working

[plappermaul]

clamping for FS() operand b added to patch.

[Xcedf]

@plappermaul unlike FS instruction FM is used by great number of games, tested some, for now found only one small difference, in TLoU of course:
non-clamped FM only: hair is missing

non-clamped FM + FMA: everything fine, but slightly slower

clamped FM only: fine and fast

Of course this the result of custom build on, normal build with whole Approx xfloat instruction set everything should be fine as on second picture, but still not sure that clap function is fine to remove

[plappermaul]

@Xcedf thanks for your patience and help. I rearranged the code a little bit so we can make use of hardware FMA in the xfloat code path. Maybe you can run a before/after performance comparison with the latest PR code.

Other readers of this thread are invited to give numbers too.

[plappermaul]

Hmmmmmm ... I just recognize that the old FM() code clamps the wrong way:

const auto fmax_m = eval((sign_a ^ sign_b) | 0x7fffffff);
const auto clamp = select(smod_m > 0x7f7fffff, bitcast<f32[4]>(fmax_m), m);

fmax_m shoud be 7f7fffff. That leaves the question if that is REALLY needed ....

[Xcedf]

Did a few tests framerats are pretty much the same, found a little difference will do more tests tomorrow to tell exactly.

[plappermaul]

Good to hear. In between I thought of another version of the new xmuladd() function. As an additional test you could give this a try:

value_t<f32[4]> xmuladd(value_t<f32[4]> a, value_t<f32[4]> b, value_t<f32[4]> c)
{
  const auto ma = sext<s32[4]>(fcmp_uno(fsplat<f32[4]>(0.) != a));
  const auto mb = sext<s32[4]>(fcmp_uno(fsplat<f32[4]>(0.) != b));
  const auto ca = eval(bitcast<f32[4]>(bitcast<s32[4]>(a) & mb));
  const auto cb = eval(bitcast<f32[4]>(bitcast<s32[4]>(b) & ma));
  return eval(fmuladd(ca, cb, c));
}

While rewriting this all we might squeeze some more fps out of it.

[Xcedf]

The result is identical, and about the difference i've found previously: i think i've compiled smth wrong, PR works good, no regressions.

[plappermaul]

Thanks. Will do some additional checks myself and post a final update to the PR later on.

[plappermaul]

I'm finally fine with the patch.

[Nekotekina]

Isn't it essentially a no-op here? Unordered comparison with zero. Maybe I'm confusing something, I don't get what cases it affects.

[plappermaul]

This checks if the variable is not zero. We can distinguish 3 cases here:

• abs(a) < 0x7fffff => mask = 0 (because auf denormals deactivation)
• abs(a) between 0x80000 and 0x7f7fffffff => mask = ffffffff
• NaN => mask = fffffffff (in case someone feeds large constant values into the function)

[Nekotekina]

Yes, but why would it affect multiplication result?

[Nekotekina]

Also this is an opportunistic FMA which means it may produce different results on different CPU arch. It's used on Accurate Xfloat path because it's not a problem when using doubles to store extended range floats, but it doesn't seem so for Approximate path.

[plappermaul]

Maybe you could give an example.

[Nekotekina]

Sorry, you can set CPU: ivybridge or similar and test. I'm sure the results will be different.

[Nekotekina]

Rebased PR with some changes, needs testing.

[Xcedf]

I did some more tests recently with UC1 with FS only b clamped some dead npcs still can act wierd, while other remain dead, but with both a and b clamped everything's fine