Upcoming GPU backend changes

[Deneau, Tom]

Doug, Gilles --

I thought I had finished the merging with  your new changes but now realize
that I have skipped over the installCode0 part that we had in our private deopt branch
here (for which I have been giving Gilles various webrevs).

This allowed the GPU to use its own deriviation of CodeInstaller with its own
get_scope_value methods.


Before this latest merge, we were calling gpu::install_code from C2V_VMENTRY(installKernel0),
which was called from CompilerToGPUImpl.installKernel and then gpu::install_code split off
to either PTX or HSAIL::install_code.

How should this logic get in in the new framework?  Should HSAILHotSpotBackend just do its own
InstallKernel implementation which will basically copy the logic for addExternalMethod
but then call some hsail_specific version of installCode0 in the VM?

-- Tom


> -----Original Message-----
> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-
> bounces at openjdk.java.net] On Behalf Of Doug Simon
> Sent: Thursday, January 30, 2014 10:16 AM
> To: sumatra-dev at openjdk.java.net; graal-dev at openjdk.java.net
> Subject: Re: Upcoming GPU backend changes
> 
> I've now pushed the remaining changes for supporting for co-existing
> GPUs:
> 
> http://hg.openjdk.java.net/graal/graal/rev/49db2c1e3bee
> 
> The major change is the removal of CompilerToGPU and its associated C++
> code. Instead, each GPU backend has only the native methods it needs and
> directly implements them in the C++ layer.
> 
> Also, all device initialization (linking device/simulator functions plus
> any device specific initialization) is *only* done in the constructors
> of PTXHotSpotBackend and HSAILHotSpotBackend. The Okra library is still
> correctly provisioned from okra-1.6-with-sim.jar if the latter is on the
> class path. Otherwise, Okra (still) relies on PATH and LD_LIBRARY_PATH
> being configured. To demonstrate this and to ensure the Sumatra
> prototype still works, I've created a webrev that includes Sumatra
> patch[1] directly in the Graal source code. This simplifies
> experimentation as one does not have to build a patched JDK:
> 
> http://cr.openjdk.java.net/~dnsimon/sumatra-on-graal/
> 
> The webrev includes a top level sumatra.sh script for running the demo.
> 
> I tested all this as much as I can but please let me know if it has
> broken anything.
> 
> -Doug
> 
> [1] http://cr.openjdk.java.net/~ecaspole/sumatrajdk.01/webrev/
> 
> On Jan 22, 2014, at 9:24 PM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> > Hi,
> >
> > I've just created a JBS issue supporting multiple co-existing GPU
> backends: https://bugs.openjdk.java.net/browse/GRAAL-1
> >
> > Prior to making the C++ changes need for this, I want to bring the
> HSAIL Java code more in alignment with the recently revised PTX backend.
> Namely:
> >
> > 1. All compilation harness logic will be moved into
> HSAILHotSpotBackend (out of HSAILCompilationResult).
> > 2. Create the equivalent of PTXWrapperBuilder for HSAIL. This is a
> generated stub that handles the transition from CPU to GPU and back. It
> also removes the need for the C++ HSAILKernelArguments class.
> >
> > If you have any questions or concerns about this, please let me know
> asap. I'm happy to have a Skype call as well if that is desirable.
> >
> > -Doug
> >
> >
>