[code-reflection] RFR: Support for Generalized Buffer Type in Hat SPIR-V Backend

[Paul Sandoz]

On Thu, 19 Dec 2024 18:47:51 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This PR introduces support for generalized buffer by creating SPIRV type structure and arrays in the generated module. Most of the implementation references the OpenCL Hat builder. The SPIR-V module assumes the same memory layout as the java buffer object, provided there is not additional customized padding between fields. Also, generated dependent functions from callgraph instead of using code model to resolve the issue where private functions can't be accessed.
>> 
>> The blackscholes, mandel, and violajones examples now run successfully. However, the violajones example still gets wrong value when accessing `threshold` from `stage` inside `isAFaceStage` function, so I currently update the condition to `sumOfThisStage > threshold`.
>> 
>> For machines that don't have `float64` capability, enable `FP64` emulation by setting the environment variable: `OverrideDefaultFP64Settings=1` and `IGC_EnableDPEmulation=1` before running. For more details: https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md#feature-double-precision-emulation-fp64
>
> Nice work. Do the changes you made to the violajones example suggest that there is a mismatch between the layout of the buffer interfaces described by `MemoryLayout` and the SPIRV type structure?

> @PaulSandoz It might be the reason. However, I examined other fields in Stage, and only the `threshold` value differs, while other fields like `id`, `firstTreeId`, and `treeCount` remain unchanged.
> 
> The issue arises when passing the object to another SPIR-V function throught parameter, causing certain values within it to change unexpectedly. However, directly accessing the object field inside another object works correctly. I think it might be due to an incorrect storage class or some hidden mechanism in SPIR-V parameter handling that I don't fully understand.

Ok, certainly that's odd given one would presumably expect the passing of pointers. I hope its not some nasty SPIRV compiler bug. I wonder what happens if you swap the `Cascade.Stage stage` and `Cascade cascade` method parameters?

Also, did you verify it produces the same results (with some epsilon)?

-------------

PR Comment: https://git.openjdk.org/babylon/pull/298#issuecomment-2555735422