Upcoming GPU backend changes

[Doug Simon]

On Feb 1, 2014, at 1:11 AM, Deneau, Tom <tom.deneau at amd.com> wrote:

> 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?

Yes. All (two) GPU backends should have their own installCode0 native equivalents that are called directly. At some point we should create a GPUHotSpotBackend abstract class for commoning out code shared between PTXHotSpotBackend and HsailHotSpotBackend but it’s ok for them both to have their own code paths for now until we know how much commonality there is.

-Doug

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