Replace D3DXFloat16To32Array.

Replace D3DXFloat16To32Array.

Method described here: ftp://ftp.fox-toolkit.org/pub/fasthalffloatconversion.pdf
Committed: https://code.google.com/p/angleproject/source/detail?r=1270

[apatrick1, 2012-08-31 21:58:21]

Daniel,

I tested all 16-bit floats between 0000 and FFFF. The results differed from
DirectXMath::PackedVector::XMConvertHalfToFloat for these cases:

             DX      this
0x7C00       65536   +INF
0x7Cnn nn!=0 +number +QNAN
0xFC00       -65536  -INF
0xFCnn nn!=0 -number -QNAN

For floats that are not INF or QNAN, the resulting 32-bit floats were bitwise
identical.

The implementation of DirectXMath::PackedVector::XMConvertHalfToFloat has a loop
with a variable number of iterations. It's inlined in a header file in the
Windows 8 SDK. I think this one is better, though generating it with a python
script is a little odd maybe.

Thanks,

Al

[nicolas, 2012-09-05 19:17:02]

Looks ok to me. The OES_texture_half_float extension allows to either have
INF/NAN representations, or not, so this change is fine and probably for the
better.

In my experience that algorithm isn't very optimal though. It always takes
multiple clock cycles per conversion (reciprocal throughput), while with a
65536-entry table it's a single lookup. Even though the latter doesn't fit in
the L1 cache, this merely affects the latency and there can be dozens of lookups
in flight simultaneously to cover for that. Also, there typically is some level
of coherence so usually it doesn't access all 256 kB of a complete lookup table.

Anyway, since there's no particular expectation for glReadPixels to be fast,
this implementation seems to be a fair compromise between speed and size.

That said, glReadPixels doesn't strictly have to support this conversion. See
http://code.google.com/p/angleproject/issues/detail?id=295 and page 103 of the
2.0.24 spec. But let's not make any behavior changes here and just get rid of
this D3DX dependency first. Thanks!