questions about decoupling GPU target runtimes from host runtime

[Bharadwaj Yadavalli]

On 10/3/2013 10:25 AM, Doug Simon wrote:
> On Oct 2, 2013, at 10:48 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:
<...>
> 2)      The routine graalRuntime( ) in graalVMToCompiler.cpp is checking to see if the UseGPU flag is enabled and if it is (and if the GPU target is PTX) it is instantiating PTXHotSpotGraalRuntime. It sounds like we need to add some logic to check if the GPU target is HSAIL and if so to instantiate the HSAIL runtime class. Am I on the right track?
> I'm not so sure that this GPU detection and initialization code is general enough. I can envisage a system with two or more different GPU types available. I've commented on this while reviewing a proposal from Bharadwaj on better support for GPU backends in Graal. I've attached the details of this review (in our internal Crucible instance).

I agree with Doug regarding GPU detection code being not general enough. 
I am working to improve this. All suggestions/proposals to improve it to 
be generic enough are welcome. How do you guys do it to detect AMD GPUs?

>> a.      Can you send us the command line to use to check that the UseGPU functionality is working? When I run a PTX test case in NetBeans with –XX:+UseGPU the JVM crashes even before it gets to generate any code.
> I've never run with UseGPU enabled. Hopefully Bharadwaj, Morris or Christian (Thalinger) can address this question.

I introduced UseGPU as a transitional flag till we have the dynamic 
runtime ability to dispatch compilation and execution of selected 
methods (such as lambda methods, for example) to GPU and the rest to CPU 
which in turn, requires the support for multiple backends (either GPU of 
other CPU cores and a heterogeneous system) in Graal.

Regarding the crash, I would expect specifying UseGPU on a machine 
without CUDA-enabled device to have no effect. Are you sync'd to the tip 
of graal repo? I'll be happy to help, if you still see the problem.

>> 3)      PTXHotSpotGraalRuntime is creating a PTXHotSpotBackend which looks similar to PTXBackend. What is the purpose of having both the PTXHotSpotBackend and a PTXBackend? It looks like these two classes are duplicating some functionality. Do we need to have an HSAILHotSpotBackend in addition to HSAILBackend? I have a similar question for PTXHotSpotRegisterConfiguration vs. PTXRegisterConfiguration. How should we deal with these pairs of classes in the refactoring you’re recommending in 1)? It seems to me like these PTXHotspot* classes should go away if we’re truly decoupling the GPU target runtimes from Hotspot.
> Yes, they should go away. Hopefully the attached review shows a sketch of how we are thinking this could be achieved.

Thanks, Doug for sharing the CR summary. Also, Vasanth and others, 
please provide any feedback and suggestions that you may have for 
supporting multiple backends.

Although my sketch implies that there is at most one GPU backend, my 
idea is indeed to support a set of multiple back ends. To that end, I 
like to think that the set would contain the traditional "host CPU" as 
well - as opposed to a "host (CPU) backend" and "additional backends". 
That is what I had in mind when I refer to multiple backends as "first 
class citizens".

Bharadwaj