Epiphany support in Graal
Michał Warecki
michal.warecki at gmail.com
Mon Aug 12 14:07:24 PDT 2013
I'm not sure what kind of buffers are you writing about but dispatching
code to Epiphany is possible by simple sending compiled asm code in SREC
format using e_load driver API. So I think there is no need to copy
buffers. If host application needs to communicate with Epiphany chip
application, the communication is performed using memory writes to and
reads from shared buffers that the applications on both sides have to
define.
Best,
Michał
2013/8/12 Frost, Gary <Gary.Frost at amd.com>
> Whoops my bad. I meant to say...
>
> Maybe *Michal* can help by describing the dispatch style for Epiphany.
> Does it require buffers to be copied from the host to the accelerator?
>
> Gary
>
> -----Original Message-----
> From: graal-dev-bounces at openjdk.java.net [mailto:
> graal-dev-bounces at openjdk.java.net] On Behalf Of Frost, Gary
> Sent: Monday, August 12, 2013 3:16 PM
> To: morris.meyer at oracle.com; Michał Warecki
> Cc: graal-dev at openjdk.java.net
> Subject: RE: Epiphany support in Graal
>
> I definitely think we need to find a way to extract the common API out of
> these accelerator style dispatches.
>
> Ultimately this should indeed be pushed up to something like
> com.oracle.graal.xxx.CompileAndDispatch
>
> Maybe between Tom, Vasanth, Michal, Morris, Christian and Bharadwaj we
> could propose a strawman API. It might be difficult to capture an API
> which supports coherent memory access style of HSA, with the buffer copy,
> dispatch and retrieve style of PTX. Maybe Morris can help by describing
> the dispatch style for Epiphany. Does it require buffers to be copied from
> the host to the accelerator?
>
> Gary
>
> -----Original Message-----
> From: graal-dev-bounces at openjdk.java.net [mailto:
> graal-dev-bounces at openjdk.java.net] On Behalf Of Morris Meyer
> Sent: Monday, August 12, 2013 2:49 PM
> To: Michał Warecki
> Cc: graal-dev at openjdk.java.net
> Subject: Re: Epiphany support in Graal
>
> Michal,
>
> There was a bit discussion in the list regarding com.amd.sumatra a month
> or two back. We are rooting graal work in com.oracle.graal per a decision
> from Thomas Wuerthinger.
>
> Bharadwaj, Christian T. and myself have Graal-PTX running on hardware on
> the moment - and we would like to make sure common code for parallel
> execution moves forward in a way that pushes a common capability forward.
>
> --mm
>
> On 8/12/13, 3:06 PM, Michał Warecki wrote:
> > Hi guys!
> >
> > I see that com.amd.sumatra.Sumatra interface and
> > com.oracle.graal.compiler.hsail.CompileAndDispatch have same methods
> > and probably will be used for the same purpose.
> > I'd like to create Epiphany code dispatcher in exactly the same way,
> > so my question is: does it make sense to move
> > com.oracle.graal.compiler.hsail.CompileAndDispatch interface to
> > com.oracle.graal.compiler or create separate, common package for that?
> >
> > Best,
> > Michał
> >
> >
> > 2013/8/4 Michał Warecki <michal.warecki at gmail.com
> > <mailto:michal.warecki at gmail.com>>
> >
> > Thanks for the great answers! A lot ofvery interesting work to do:-)
> > If anyone is interested in developing this Graal and Sumatra
> > extension, I'm going to share it on some public repository within
> > a few weeks/months.
> >
> > Best,
> > Michał
> >
> >
> > 2013/8/2 Morris Meyer <morris.meyer at oracle.com
> > <mailto:morris.meyer at oracle.com>>
> >
> > This looks like an interesting architecture. The reference
> > manual is a missing the actual encoding of instructions, but
> > from what you have here I would suggest that you look at the
> > SPARC assembler classes in graal first - and then look at the
> > PTX and HSAIL architectures.
> >
> > Christian Thalinger and I worked the SPARC assembler - and the
> > class structure of each instruction allows for superclass
> > assertions on the specific formats, as well as being able to
> > re-work in the instruction stream if offsets fall outside
> > small immediate ranges.
> >
> > The PTX architecture in graal has the initial
> > ExternalCompilationResult path - which allows for Graal to
> > invoke the compiled PTX kernels and still have a host-native
> > compiled result. Graal does interpreter vs compiled snippet
> > unit testing - and we would like to augment this as we push
> > into GPU, APU and architectures such as Epiphany.
> >
> > We still have more work to do on moving to handle multiple
> > heterogeneous architectures.
> >
> > We are also working to add the sort of upstream parallel
> > work-enabling code that allows the compiler and APIs recognize
> > and gain useful work from external compilation resources.
> >
> > Warm regards,
> >
> > --morris
> >
> >
> > On 8/2/13, 1:56 AM, Michał Warecki wrote:
> >
> > Hi all!
> >
> > I just want to make sure that Graal is the correct project
> > to start with.
> > I'd like to create bytecode to Epiphany architecture asm
> > compiler.
> >
> > Epiphany is a multicore RISC based architecture [1] that
> > aims to be an
> > accelerator (not the host CPU) unit. Epiphany architecture
> > is used in
> > Parallella computer (ARM is the host CPU) [2].
> >
> > What I want to achieve is to compile and send to epiphany
> > only part of a
> > Java program to be processed in a parallel way. Probably I
> > will try to
> > integrate it with Sumarta project.
> >
> > Example use case:
> >
> > Streams.intRange(0, in.length).parallel().forEach( id ->
> > {c[id]=a[id]+b[id];});
> >
> > // c[id]=a[id]+b[id]; -> This code will be executed on
> > Epiphany. "id"
> > is the identifier of a core.
> >
> >
> > Is Graal the correct project to implement such bytecode to
> > epiphany asm
> > compiler? I am inexperienced in this area... Any ideas
> > about this?
> >
> > Best,
> > Michał
> >
> >
> > [1] http://www.adapteva.com/introduction/
> >
> > http://www.adapteva.com/wp-content/uploads/2012/10/epiphany_arch_refer
> > ence_3.12.10.03.pdf
> >
> > [2] http://www.parallella.org/
> >
> >
> >
> >
>
>
>
>
>
>
More information about the graal-dev
mailing list