Fix support for Intel Compute Runtime with VectorSize > 1

[proski]

Fix support for Intel Compute Runtime with VectorSize > 1

The fallback implementation of amd_bitalign() triggers a bug with Intel Compute
Runtime (NEO) versions from 23.22.26516.18 to 24.45.31740.9 inclusive.

intel/intel-graphics-compiler#358

The bug affects all but the first component of the vectors, so the self-tests
would pass with VectorSize=1. For higher values of VectorSize, including the
default VectorSize=2, approximately half of the self-tests fail, all in
barrett32 kernels.

Add generic_bitalign() that is always implemented using shifts. Use it in all
cases when the destination is the same as one of the sources.

If Intel Compute Runtime is detected, use 64-bit shifts in generic_bitalign().
For other platforms, keep using 32-bit shifts.

Make amd_bitalign() an alias to generic_bitalign() on systems where
amd_bitalign() is not available. That way, it would also expand to 64-bit
shifts for Intel Compute Runtime.

[proski]

Current status (updated):

• The quick test passes both with and without fp64
• The self-test (-st) passes with and without fp64
• The extended self-test (-st2) passes with and without fp64

Please don't use this PR in production unless it passes the self-test on your system!

TODO:

• Test on Intel GPU with all VectorSize values
• Benchmark on AMD GPU for performance degradation
• Benchmark on AMD GPU to compare 32-bit and 64-bit shifts
• Find the exact version of Intel Compute Runtime that broke 32-bit shifts

[proski]

Update:

• Preserve the existing choices of whether to use amd_bitalign() on platforms where it's available.
• Replace the existing shifts with amd_bitalign_emulated() which is always implemented using shifts - even in comments.
• Detect Intel NEO without relying on GPUType (it's for optimization, not for workarounds).

[proski]

Update:

• rename amd_bitalign_emulated to generic_bitalign
• update comments accordingly

Confirmed that 64-bit shifts are faster than 32-bit shifts on Intel with VectorSize=1 - no need to make a special case for VectorSize=1.

[preda]

Would it be worth to let Intel know about this problem -- maybe they would like to fix it? (independently of our workaround here)

[proski]

Absolutely, I plan to do it.

[proski]

Reported the issue to Intel: intel/compute-runtime#790
I'm glad I could put together a simple demo.
The breakage must have happened between versions 22.14.22890 and 23.43.27642. The precompiled binaries are for Ubuntu and I only have Fedora now, compiling intel-opencl is very time consuming, but I might give it another try later.

[proski]

I was able to use Ubuntu in WSL. If turns out that 23.17.26241.22 is the last good release and
23.22.26516.18 is the first bad release. Also, the latest release, 24.48.31907.7, fixes the issue. But it's too new and most users don't have it yet.

[proski]

Not WIP anymore - ready for review.

• Determined the affected versions of Intel Compute Runtime
• Reported the issue to Intel
• Updated the comments accordingly
• Tested on Radeon Pro 560X and found no performance degradation

[proski]

• Updated the description and a comment in the code - no code changes.
• I was asked to open an issue for the Intel Graphics Compiler, so I changed links to that issue: In-place shift of uint vectors corrupts s1 and further components intel/intel-graphics-compiler#358
• Tested the code on Windows 11 with the current Intel driver - it's also affected and this PR is fixing everything.