Support for Generalized Buffer Type in Hat SPIR-V Backend

[hanklo6]

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

---

Progress

• Change must not contain extraneous whitespace

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/babylon.git pull/298/head:pull/298
$ git checkout pull/298

Update a local copy of the PR:
$ git checkout pull/298
$ git pull https://git.openjdk.org/babylon.git pull/298/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 298

View PR using the GUI difftool:
$ git pr show -t 298

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/babylon/pull/298.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back hanklo6! A progress list of the required criteria for merging this PR into code-reflection will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@hanklo6 This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

Support for Generalized Buffer Type in Hat SPIR-V Backend

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 1 new commit pushed to the code-reflection branch:

• 490332b: Hat bld and dir changes in prep for separating native ffi and jextracted backends

Please see this link for an up-to-date comparison between the source branch of this pull request and the code-reflection branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[mlbridge]

Webrevs

• 00: Full (fbb958a4)

[PaulSandoz]

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]

@grfrost can better advise, but if possible it might be better to work directly off the MemoryLayout objects used by the buffer, that's also a more general solution.

[hanklo6]

@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.

[PaulSandoz]

@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 (within some epsilon)?

[hanklo6]

I got the same result after swapping the Cascade.Stage stage and Cascade cascade method parameters.

For verification, I compared the detected faces and the number of faces with the results from the code running on my MacOS OpenCL backend, and both detected the same faces and number of faces.