Fw: [External] : Re: Some questions about HAT and Babylon

Mon Jun 24 14:52:01 UTC 2024

Apologies all.  I forgot 'reply to all'

Gary
________________________________
From: Gary Frost <gary.frost at oracle.com>
Sent: Monday, June 24, 2024 3:47 PM
To: Juan Fumero <juan.fumero at paravox.ai>
Subject: Re: [External] : Re: Some questions about HAT and Babylon

We don't yet. But yes the plan is to have 1d,2d and 3d variants of the KernelContext

Actually some code may be there, I just have not hooked it up to the ComputeContext.

So in Java terms

class KernelContext {
     class F32{
            float invsqrt(float f){};
     }
     class F64{
             double hypot(double x,double y){};
     }
     void barrier(){};
}
class KernelContext3D extends KernelContext{
   int x, y, z;
   int maxX, maxY, maxZ;
   int groupX, groupY, groupZ;
   int groupMaxX, groupMaxY, groupMaxZ
}

Clearly we can use the time honored mod/mul pattern (y%width and y/width)  to flatten our grid to 1d from 2d.

I think the Mandel example uses a 1d grid to execute a fake 2d sweep 😉

The KernelContext will also likely be the hook for common 'kernely' functions

KernelContext kc;
kc.barrier()
kc.F32.invsqrt(x)
kc.F64.hypot(x,y)
kc.I32.atomicInc(?)
kc.I32.inclusiveScan(?)

Gary

________________________________
From: Juan Fumero <juan.fumero at paravox.ai>
Sent: Monday, June 24, 2024 3:24 PM
To: Gary Frost <gary.frost at oracle.com>
Subject: [External] : Re: Some questions about HAT and Babylon

Thanks Gary,

  I will take a look at the pom files.

Another question. Going a bit deeper into the KernelContext (I guess an inspired by TornadoVM Data Structure), is the any variant to represent a 2D NDRange?

https://github.com/openjdk/babylon/blob/e7ada25d4c01c76461bf5cd73b928138050f11f8/hat/examples/experiments/src/main/java/experiments/spirv/MatrixMultiply.java#L77<https://urldefense.com/v3/__https://github.com/openjdk/babylon/blob/e7ada25d4c01c76461bf5cd73b928138050f11f8/hat/examples/experiments/src/main/java/experiments/spirv/MatrixMultiply.java*L77__;Iw!!ACWV5N9M2RV99hQ!O9nmXwQoYr3FSnQdIT4xud0fnalAmTtGiQxx7yNO43sVuRj3p0oEECInHId0SNdH7pTEr7Qukqydo9h7nNcAF9fKCA$>

I wanted to run some examples with 2D Matrix Multiplication.

I guess:

```java

public class KernelContext {
    public final NDRange ndRange;
    public int x;
    public final int maxX;

    public KernelContext(NDRange ndRange, int maxX, int x) {
        this.ndRange = ndRange;
        this.maxX = maxX;
        this.x = x;
    }
}

```

The NDRange object itself can return `maxX`, `maxY` and `maxZ` for each dimension as well as the thread-id per dimension. Could this be the way to go?

In TornadoVM, we have the concept of `WorkerGrid` [1], which can be 1D, 2D or 3D as a sub-type.

The `KernelContext` [2] gives us access to the corresponding thread-ids as well as access to barriers, local memory (in OpenCL terms), etc.

[1] https://github.com/beehive-lab/TornadoVM/blob/master/tornado-api/src/main/java/uk/ac/manchester/tornado/api/WorkerGrid.java#L20<https://urldefense.com/v3/__https://github.com/beehive-lab/TornadoVM/blob/master/tornado-api/src/main/java/uk/ac/manchester/tornado/api/WorkerGrid.java*L20__;Iw!!ACWV5N9M2RV99hQ!O9nmXwQoYr3FSnQdIT4xud0fnalAmTtGiQxx7yNO43sVuRj3p0oEECInHId0SNdH7pTEr7Qukqydo9h7nNejJ3l5qQ$>

[2] https://github.com/beehive-lab/TornadoVM/blob/master/tornado-api/src/main/java/uk/ac/manchester/tornado/api/KernelContext.java<https://urldefense.com/v3/__https://github.com/beehive-lab/TornadoVM/blob/master/tornado-api/src/main/java/uk/ac/manchester/tornado/api/KernelContext.java__;!!ACWV5N9M2RV99hQ!O9nmXwQoYr3FSnQdIT4xud0fnalAmTtGiQxx7yNO43sVuRj3p0oEECInHId0SNdH7pTEr7Qukqydo9h7nNdy-kC-eg$>

Thanks

Juan

On 24/06/2024 15:57, Gary Frost wrote:
Hey Juan

I would like to see your top level pom.xml

Specifically the pom.xml...properties which usually have these defaults

<properties>
        <babylon.repo.name>babylon</babylon.repo.name>  <!--replace with your fork name -->
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>23</maven.compiler.source>
        <maven.compiler.target>23</maven.compiler.target>
        <github.dir>${env.HOME}/github</github.dir>

        <beehive.spirv.toolkit.dir>${github.dir}/beehive-spirv-toolkit/</beehive.spirv.toolkit.dir>
        <babylon.dir>${github.dir}/${babylon.repo.name}</babylon.dir>
        <hat.dir>${babylon.dir}/hat</hat.dir>
        <hat.target>${hat.dir}/maven-build</hat.target>
   </properties>

Which assumes a layout under github which looks like this.

    github/
           babylon/
                  build/
                       YOUR_OS-YOUR_ARCH-server-release
                  hat/
           beehive-spirv-toolkit/

Yours might be something like this.

    github/
           babylon/
               babylon/ <---?
                     build/
                          YOUR_OS-YOUR_ARCH-server-release
                     hat/
           beehive-spirv-toolkit/

In which case you may need
     <babylon.dir>${github.dir}/babylon/${babylon.repo.name}</babylon.dir>

Most important is that ${babylon.dir}/hat == ${hat.dir}

There is a 'sanity.java' script in the hat root.  Which (hopefully) can just be run via java (23) directly

java sanity.java

Which will attempt to sanity check your pom properties. I switch repos frequently, and this script has saved my bacon a few times.

The native code (C++/C) in the SPIRV backend is essentially a mock backend, enough to load the lib and hook up the 'native trampoline' points. My idea was that someone 😉 would crib from the OpenCL one, or build a HIP or Level0 variant...

Gary

________________________________
From: babylon-dev <babylon-dev-retn at openjdk.org><mailto:babylon-dev-retn at openjdk.org> on behalf of Juan Fumero <juan.fumero at paravox.ai><mailto:juan.fumero at paravox.ai>
Sent: Monday, June 24, 2024 2:29 PM
To: babylon-dev at openjdk.org<mailto:babylon-dev at openjdk.org> <babylon-dev at openjdk.org><mailto:babylon-dev at openjdk.org>
Subject: Some questions about HAT and Babylon

Hi all,

    I am building and testing a few examples and I have a few questions:

1) During the installation of the HAT component, the JAR files and
binaries where place under the $HOME directory, instead of under the HAT
sub directory within Babylon:

For example, in my case, the installation was copied here:

  /home/juan/github/babylon/hat/maven-build

However, my Babylon install is here:

/home/juan/repos/hat/babylon/babylon

2) I saw the C-code code of HAT, I noticed that there are several
directories per backend. One for OpenCL, PTX, etc. SPIR-V is also a
directory. However, SPIR-V is an intermediate representation and it is
dispatched via a) OpenCL, or b) Level Zero. Is there any reason why
SPIR-V has this C-library?

I hope to find more time during the week to do some testing.

Kind regards,

Juan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20240624/026d9ec7/attachment-0001.htm>