hsail gate commands -- webrev
Doug Simon
doug.simon at oracle.com
Thu Jan 23 13:17:06 PST 2014
Also:
mx/projects:
27 library at OKRA@path=lib/okra-1.5.jar
28 library at OKRA@urls=http://cr.openjdk.java.net/~tdeneau/okra-1.5.jar
29 library at OKRA@sourcePath=lib/okra-1.5-src.jar
30 library at OKRA@sourceUrls=http://cr.openjdk.java.net/~tdeneau/okra-1.5-src.jar
31
32 library at OKRAWITHSIM@path=lib/okra-1.5-with-sim.jar
33 library at OKRAWITHSIM@urls=http://cr.openjdk.java.net/~tdeneau/okra-1.5-with-sim.jar
34 library at OKRA@sourcePath=lib/okra-1.5-src.jar
35 library at OKRA@sourceUrls=http://cr.openjdk.java.net/~tdeneau/okra-1.5-src.jar
Lines 34 and 35 are identical to lines 29 and 30 which I’m sure is not what is intended. It would be nice to have the source for okra-1.5-with-sim.jar as well.
On Jan 23, 2014, at 10:13 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
> Yes, that makes sense, I will send the next revision.
>
>
>
>> -----Original Message-----
>> From: Doug Simon [mailto:doug.simon at oracle.com]
>> Sent: Thursday, January 23, 2014 2:50 PM
>> To: Gilles Duboscq
>> Cc: Deneau, Tom; graal-dev at openjdk.java.net
>> Subject: Re: hsail gate commands -- webrev
>>
>> We should introduce a LibraryLocator interface in OkraContext:
>>
>> interface LibraryLocator {
>> String getPath();
>> }
>>
>> and have OkraSimLoader implement that interface. Then OkraSimLoader does
>> the unjarring in its constructor and is used in
>> OkraContext.loadOkraNativeLibrary() as follows:
>>
>> ...
>> if (isNativeLibraryLoaded) return;
>> String libraryPath = null;
>> try {
>> Class c = Class.forName("com.amd.okra.OkraSimLoader", true,
>> ClassLoader.getSystemClassLoader())
>> libraryPath = ((LibraryLocator) c.newInstance()).getPath();
>> System.load(okraLibraryFullName);
>> isNativeLibraryLoaded = true;
>> return;
>> } catch (InstantiationException | IllegalAccessException |
>> UnsatisfiedLinkError | ClassNotFoundException e) {
>> // fall through to other mechanisms for loading library
>> }
>>
>> -Doug
>>
>> On Jan 23, 2014, at 8:13 PM, Gilles Duboscq <duboscq at ssw.jku.at> wrote:
>>
>>> Tom,
>>>
>>> This last version doesn't work for me when running unit tests:
>>> The content of okra-1.5.jar is being copied inside graal.jar which
>>> means that OkraContext is on the boot classpath but
>>> okra-1.5-with-sim.jar (and so OkraSimLoader) is only on the classpath.
>>> This means that when hotspot tries to link the native methods in
>>> OkraContext it looks inside the libraries loaded for the system class
>>> loader while OkraSimLoader registered its library with the
>>> application's classloader.
>>>
>>> We could append okra-1.5-with-sim.jar to the bootclasspath but i'm not
>>> so sure about mx support for this. Doug, what do you think?
>>>
>>> -Gilles
>>>
>>> On Thu, Jan 23, 2014 at 1:02 AM, Tom Deneau <tom.deneau at amd.com>
>> wrote:
>>>> Doug --
>>>>
>>>> OK, there is now a v2 webrev supporting the changes we talked about
>>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-lazy-native-
>>>> hsail-library-open-v2/webrev/ (ignore the HSAILCompilationResult
>>>> being listed, a webrev quirk)
>>>>
>>>> and 3 new .jar files with the okra side changes...
>>>>
>>>> Now only the regular okra class files go into graal.jar.
>>>> The special functionality is in a separate OkraSimLoader class and
>>>> that class and the resources appear in the okra-1.5.-with-sim.jar
>>>>
>>>> And there is a separate jar file for okra sources.
>>>>
>>>> -- Tom
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Deneau, Tom
>>>>> Sent: Wednesday, January 22, 2014 1:19 PM
>>>>> To: 'Doug Simon'
>>>>> Cc: Tom Rodriguez; graal-dev at openjdk.java.net
>>>>> Subject: RE: hsail gate commands -- webrev
>>>>>
>>>>> Doug --
>>>>>
>>>>> There is a newer .jar file (same name) up on cr.openjdk.java.net now
>>>>> that includes the changes you asked for
>>>>> * includes the sources
>>>>> * deletes the temporary .hsail and .o files
>>>>>
>>>>> Can you make the okraLibExists() change which you mention below
>>>>> without a new webrev?
>>>>>
>>>>> -- Tom
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>> Sent: Wednesday, January 22, 2014 5:58 AM
>>>>>> To: Deneau, Tom
>>>>>> Cc: Tom Rodriguez; graal-dev at openjdk.java.net
>>>>>> Subject: Re: hsail gate commands -- webrev
>>>>>>
>>>>>> This all seems to work - nice job. Just a few requests/comments
>>>>>> before I integrate.
>>>>>>
>>>>>> HSAILCompilationResult.java:
>>>>>>
>>>>>> 60 // this test of okraLib existence is to allow the loading
>> of
>>>>>> the
>>>>>> 61 // native library from the jar file if it is not already on
>>>>> the
>>>>>> path
>>>>>> 62 private static boolean okraLibExists =
>>>>>> OkraUtil.okraLibExists();
>>>>>>
>>>>>> The above assignment produces a "value of field is not used"
>>>>>> warning in Eclipse. It seems that all you want here is the
>>>>>> side-effect of the call to OkraUtil.okraLibExists(). If that's the
>>>>>> case, just put the call in a static initializer block and delete
>> the field:
>>>>>>
>>>>>> static {
>>>>>> OkraUtil.okraLibExists();
>>>>>> }
>>>>>>
>>>>>> However, I tried just commenting out the line altogether and the
>>>>>> unit tests seemed to still run fine. Which begs the question, do
>>>>>> you really need this here?
>>>>>>
>>>>>> Can you also please update (and re-upload) okra-with-sim.jar to
>>>>>> include the Java sources (just like okra-1.2.jar had). This helps
>>>>>> with debugging the code in Eclipse.
>>>>>>
>>>>>> -Doug
>>>>>>
>>>>>> On Jan 21, 2014, at 6:07 PM, Deneau, Tom <tom.deneau at amd.com>
>> wrote:
>>>>>>
>>>>>>> All --
>>>>>>>
>>>>>>> I have uploaded a webrev to allow use of the hsail simulator
>>>>>>> without
>>>>>> setting up any PATH or LD_LIBRARY_PATH variables to make it easier
>>>>>> to run the hsail junit tests as part of the graal gate:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-lazy-nati
>>>>>>> ve
>>>>>>> -h
>>>>>>> sail-library-open/webrev/
>>>>>>>
>>>>>>> * The main change was in gpu_hsail.cpp to lazily load the native
>>>>>> library,
>>>>>>> (waiting until it is really needed). It always tries the
>>>>>>> original
>>>>>> LD_LIBRARY_PATH
>>>>>>> as a first try, and only if that doesn't work, it will try
>>>>>>> the environment variable _OKRA_SIM_LIB_PATH_ (which will have
>>>>>>> been
>>>>>> set up by the
>>>>>>> java side which will have copied the native library and
>>>>>>> hsailasm
>>>>>> to a temporary
>>>>>>> directory if necessary)
>>>>>>>
>>>>>>> * HSAILCompilationResult, added a call the the JNI side to get it
>>>>>>> to
>>>>>> load the native library
>>>>>>> from the jar file if it needs to.
>>>>>>>
>>>>>>> * mx/projects changed to use the newly built okra-with-sim.jar
>>>>>>> which
>>>>>> has been uploaded to
>>>>>>> my cr.openjdk.java.net directory (the old okra.jar came from
>>>>>>> there
>>>>>> as well).
>>>>>>> This jar file contains the prebuilt binaries but can also be
>>>>>>> built
>>>>>> from sources
>>>>>>> following the instructions at
>>>>>>>
>>>>>>> https://github.com/HSAFoundation/Okra-Interface-to-HSAIL-Simulator
>>>>>>>
>>>>>>> To test:
>>>>>>> * make sure not only that the okra/dist/bin directory
>>>>>>> is removed from PATH and LD_LIBRARY_PATH but also that it is
>>>>>>> not
>>>>>> one of the directories
>>>>>>> listed under "ldconfig -p"
>>>>>>>
>>>>>>>
>>>>>>> The changes to the okra.jar file and the native library are not
>>>>>>> part of this webrev, but if interested, these changes can be
>>>>>>> viewed as a pull request on the github directory
>>>>>>> https://github.com/HSAFoundation/Okra-Interface-to-HSAIL-Simulator
>>>>>>> /p
>>>>>>> ul
>>>>>>> l/11
>>>>>>>
>>>>>>> * Again, the native library loading as performed by the
>>>>>>> OkraContext
>>>>>> class
>>>>>>> first tries the original PATH and LD_LIBRARY_PATH strategy
>>>>>>> before
>>>>>> reverting
>>>>>>> to using a temporary directory. It looks in the jar file that
>>>>>> OkraContext.class
>>>>>>> was loaded from and copies anything in resources/okra to a
>>>>>> temporary directory.
>>>>>>> Then it tries to load the native library from there.
>>>>>>>
>>>>>>> * the native library itself now contains an on_load function
>>>>>>> with attribute((constructor)) which gets executed as the .so
>>>>>>> file
>>>>>> gets loaded.
>>>>>>> It does the following:
>>>>>>> * finds out where it was loaded from (using dladdr)
>>>>>>> * appends that directory to PATH and LD_LIBRARY_PATH (this
>>>>>> allows
>>>>>>> a later invoke of hsailasm to work)
>>>>>>> * sets an environment variable _OKRA_SIM_LIB_PATH_. This
>>>>>>> env
>>>>>> var
>>>>>>> is used later by the JVM when it wants to load the native
>>>>>> library
>>>>>>> and discover its C-based entry points.
>>>>>>>
>>>>>>> -- Tom
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com]
>>>>>>>> Sent: Wednesday, January 15, 2014 4:15 PM
>>>>>>>> To: Douglas Simon
>>>>>>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net
>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>
>>>>>>>> dladdr can also be used to figure it out directly.
>>>>>>>>
>>>>>>>> tom
>>>>>>>>
>>>>>>>> On Jan 15, 2014, at 2:07 PM, Doug Simon <doug.simon at oracle.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jan 15, 2014, at 10:46 PM, Deneau, Tom <tom.deneau at amd.com>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Doug --
>>>>>>>>>>
>>>>>>>>>> how does the JNI_OnLoad know what path it was loaded from?
>>>>>>>>>> or would the java side have to pass this information down?
>>>>>>>>>
>>>>>>>>> The Java side has to pass this down. One way to do it would be
>>>>>>>>> to
>>>>>>>> define a static String field in some class in the Okra Java
>>>>>>>> library and assign it the path before calling System.load().
>>>>>>>> Inside JNI_OnLoad, the JNI interface can be used to find the
>>>>>>>> class and read
>>>>>> the field.
>>>>>>>>>
>>>>>>>>> -Doug
>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>>> Sent: Wednesday, January 15, 2014 3:11 PM
>>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>>>
>>>>>>>>>>> Hi Tom,
>>>>>>>>>>>
>>>>>>>>>>> A quick glance through the HSAIL C++ layer seems to indicate
>>>>>>>>>>> that it should be able to lazily initialize the HSAIL library
>>>>>>>>>>> linkage
>>>>>>>> (currently
>>>>>>>>>>> done in gnu::Hsail::probe_linkage()). This means it should be
>>>>>>>> deferrable
>>>>>>>>>>> until after the Java part of the Okra library has had a chance
>>>>>>>>>>> to extract the native library file (and hsailasm executable)
>>>>>>>>>>> into the
>>>>>>>> file
>>>>>>>>>>> system. Then you would call System.load() to load the library.
>>>>>>>> There's
>>>>>>>>>>> still the problem of how to communicate the absolute path of
>>>>>>>>>>> the
>>>>>>>> native
>>>>>>>>>>> library to the os::dll_load call. There may be a more elegant
>>>>>>>> solution,
>>>>>>>>>>> but I'd suggest using the JNI_OnLoad[1] mechanism. Inside the
>>>>>>>> JNI_OnLoad
>>>>>>>>>>> function in the Okra native library, you can set an
>>>>>>>>>>> environment
>>>>>>>> variable
>>>>>>>>>>> (e.g., OKRA_DLL_PATH) which gnu::Hsail::probe_linkage can then
>>>>>> use.
>>>>>>>> Note
>>>>>>>>>>> that the environment variable has to be set this way as
>>>>>>>>>>> there's no
>>>>>>>> way
>>>>>>>>>>> to set an environment variable from Java.
>>>>>>>>>>>
>>>>>>>>>>> By the time you finish all this hackery, you may start
>>>>>>>>>>> thinking that simply porting the HSAIL simulator/toolchain to
>>>>>>>>>>> Java might be easier
>>>>>>>> ;-)
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>
>> http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/invocation.
>>>>>>>> ht
>>>>>>>> ml#
>>>>>>>>>>> JNI_OnLoad
>>>>>>>>>>>
>>>>>>>>>>> On Jan 15, 2014, at 9:05 PM, Deneau, Tom <tom.deneau at amd.com>
>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Doug --
>>>>>>>>>>>>
>>>>>>>>>>>> One complication I saw here.
>>>>>>>>>>>> The native library file is used both from the java side
>>>>>>>>>>>> (using
>>>>>>>>>>>> loadLibrary) and from the hotspot side (using os::dll_load
>>>>>>>>>>>> followed
>>>>>>>> by
>>>>>>>>>>> looking up the specific functions it needs).
>>>>>>>>>>>> And the hotspot attempt to load happens first (from
>>>>> gpu::init()).
>>>>>>>>>>>>
>>>>>>>>>>>> So anything the java side would have done with resources in
>>>>>>>>>>>> the
>>>>>>>> .jar
>>>>>>>>>>>> file and temp directories wouldn't have been done yet.
>>>>>>>>>>>>
>>>>>>>>>>>> -- Tom
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>>>>> Sent: Tuesday, January 14, 2014 3:27 AM
>>>>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jan 13, 2014, at 8:52 PM, Deneau, Tom
>>>>>>>>>>>>> <tom.deneau at amd.com>
>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Doug --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Using the techniques in
>>>>>>>>>>>>>> http://frommyplayground.com/how-to-load-native-jni-library-
>>>>>>>>>>>>>> fr
>>>>>>>>>>>>>> om
>>>>>>>>>>>>>> -
>>>>>>>> jar/
>>>>>>>>>>>>>> that you sent, would it be acceptable to leave hsailasm as
>>>>>>>>>>>>>> a separate
>>>>>>>>>>>>> executable which gets unjarred into the system temporary
>>>>>>>>>>>>> directory and then executed from there using an absolute
>>>>>> pathname?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sounds feasible and reasonable to me.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- Tom
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>>>>>>> Sent: Sunday, January 12, 2014 2:29 PM
>>>>>>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Jan 9, 2014, at 9:50 PM, Deneau, Tom
>>>>>>>>>>>>>>> <tom.deneau at amd.com>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Doug --
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We'll take a look at your suggestion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Great.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> BTW, you guys may want to bring
>>>>>>>>>>>>>>>
>>>>>>>> https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator
>>>>>>>>>>>>>>> more up to date at some point. At least you can remove the
>>>>>>>> "(webrev
>>>>>>>>>>>>>>> under review)" qualifications.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Doug
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>>>>>>>>> Sent: Thursday, January 09, 2014 1:38 PM
>>>>>>>>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Jan 9, 2014, at 6:51 PM, Tom Rodriguez
>>>>>>>>>>>>>>>>> <tom.rodriguez at oracle.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It would still be great if there would be some way
>>>>>>>>>>>>>>>>>>>>> to incorporate
>>>>>>>>>>>>>>>>> the hsail simulator into the gate...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A good start would be if you could provide us with a
>>>>>>>>>>>>>>>>>>>> patch
>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> `mx',
>>>>>>>>>>>>>>>>> that adds a command which sets up the HSAIL simulator
>>>>>>>> properly.
>>>>>>>>>>>>>>>>> Currently our gate is running on Linux, but this might
>>>>>>>>>>>>>>>>> change
>>>>>>>> in
>>>>>>>>>>>>>>>>> the future, so keep in mind that this should potentially
>>>>>>>>>>>>>>>>> work
>>>>>>>> on
>>>>>>>>>>>>>>>>> all platforms (Linux, MacOSX, Windows).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Our gate server is basically executing `mx gate' to
>>>>>>>> validate
>>>>>>>>>>>>>>>>> changes. That includes building, bootstrap tests,
>>>>>>>>>>>>>>>>> unittest,
>>>>>>>> etc.
>>>>>>>>>>>>>>>>> If that command was successful on our gate server, the
>>>>>>>>>>>>>>>>> changes are accepted and pushed to the repository.
>>>>>>>>>>>>>>>>> Having the `mx
>>>>>>>> gate'
>>>>>>>>>>>>>>>>> command, one can reproduce the gate process on his/her
>>>>>>>>>>>>>>>>> local
>>>>>>>>>>>>> machine.
>>>>>>>>>>>>>>>>> Therefore it would be important that one can easily and
>>>>>>>> reliable
>>>>>>>>>>>>>>>>> set up the HSAIL environment if it is part of the gate
>>>>>>>> process.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Given the dependencies for building the simulator[1]
>>>>>>>>>>>>>>>>>>> and the fact it
>>>>>>>>>>>>>>>>> only currently runs on linux, I don't think it will be
>>>>>>>>>>>>>>>>> that
>>>>>>>> easy
>>>>>>>>>>>>>>>>> to come up with an mx command.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What precompiling an okra distribution for linux that
>>>>>>>>>>>>>>>>>> mx can
>>>>>>>>>>>>>>> download?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If Okra used a self contained JNI library, that might
>>>>>>>>>>>>>>>>> just
>>>>>>>> work.
>>>>>>>>>>>>>>>>> However, the way it is deployed now involves having the
>>>>>>>> hsailasm
>>>>>>>>>>>>>>>>> executable on your PATH. Also, LD_LIBRARY_PATH has to be
>>>>>>>>>>>>>>>>> setup
>>>>>>>> to
>>>>>>>>>>>>>>>>> find the JNI library itself.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> @AMD guys: How hard would it be to make the Okra JNI be
>>>>>>>>>>>>>>>>> self contained library and include the hsailasm
>>>>>>>>>>>>>>>>> functionality? If that's possible, you could bundle the
>>>>>>>>>>>>>>>>> JNI library inside the
>>>>>>>> Okra
>>>>>>>>>>>>>>>>> jar using a technique like
>>>>>>>>>>>>>>>>> http://frommyplayground.com/how-to-load-native-jni-libra
>>>>>>>>>>>>>>>>> ry
>>>>>>>>>>>>>>>>> -
>>>>>>>> from-j
>>>>>>>>>>>>>>>>> ar
>>>>>>>>>>>>>>>>> /
>>>>>>>>>>>>>>> to avoid having to set up PATH or LD_LIBRARY_PATH.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Doug
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>> https://github.com/HSAFoundation/Okra-Interface-to-HSA
>>>>>>>>>>>>>>>>>>> IL
>>>>>>>>>>>>>>>>>>> -
>>>>>>>> Simula
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> r#
>>>>>>>>>>>>>>>>>>> ok
>>>>>>>>>>>>>>>>>>> ra-interface-to-hsail-simulator
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>> From: graal-dev-bounces at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>>> [mailto:graal-
>>>>>>>> dev-
>>>>>>>>>>>>>>>>>>>>>> bounces at openjdk.java.net] On Behalf Of Deneau, Tom
>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, December 16, 2013 11:24 AM
>>>>>>>>>>>>>>>>>>>>>> To: Doug Simon
>>>>>>>>>>>>>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>>> Subject: RE: hsail gate commands
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> OK, I see why there is no error when running mx
>>>>>>>>>>>>>>>>>>>>>> --vm
>>>>>>>> server
>>>>>>>>>>>>>>>>>>>>>> unittest hsail
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> At some point (I don't recall why, maybe at
>>>>>>>>>>>>>>>>>>>>>> Oracle's request??), we put in some code in
>>>>>>>>>>>>>>>>>>>>>> KernelTester that if
>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> could not find the okra simulator files would just
>>>>>>>> silently
>>>>>>>>>>>>>>>>>>>>>> not run the tests (which I guess counts as a pass).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No the hsail simulator is not a java app at all.
>>>>>>>>>>>>>>>>>>>>>> The page at
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simu
>>>>>>>>>>>>>>>>>>>>>> la to r should describe how to build it and what
>>>>>>>> environment
>>>>>>>>>>>>>>>>>>>>>> variables to set up to use it...
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> -- Tom
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, December 16, 2013 11:02 AM
>>>>>>>>>>>>>>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>>>>>>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Dec 16, 2013, at 5:48 PM, Deneau, Tom
>>>>>>>>>>>>>>>>>>>>>>> <tom.deneau at amd.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Doug --
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I see.
>>>>>>>>>>>>>>>>>>>>>>>> I don't understand why the tests would run
>>>>>>>>>>>>>>>>>>>>>>>> without
>>>>>>>> error
>>>>>>>>>>>>>>>>>>>>>>>> if the simulator and associated assembler is
>>>>>>>>>>>>>>>>>>>>>>>> missing
>>>>>>>>>>> but...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> What error are you seeing?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Is there a way we can get the HSAIL simulator
>>>>>>>>>>>>>>>>>>>>>>>> into the gate
>>>>>>>>>>>>>>>>>>>>>>> infrastructure?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Is it a pure Java app yet? That would certainly
>>>>>>>>>>>>>>>>>>>>>>> make it
>>>>>>>>>>>>>>> trivial.
>>>>>>>>>>>>>>>>>>>>>>> In any case, I'll defer to Bernhard or Gilles to
>>>>>>>>>>>>>>>>>>>>>>> answer this since they are the maintainers of this
>>>>>>>> infrastructure.
>>>>>>>>>>>>>>>>>>>>>>> Can you please send instructions on how to
>>>>>>>>>>>>>>>>>>>>>>> install/use/configure the
>>>>>>>>>>>>>>>>> simulator.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -Doug
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, December 16, 2013 10:36 AM
>>>>>>>>>>>>>>>>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>>>>>>>>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Dec 16, 2013, at 5:21 PM, Deneau, Tom
>>>>>>>>>>>>>>>>>>>>>>>>> <tom.deneau at amd.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Doug --
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I noticed in syncing with the trunk as of last
>>>>>>>>>>>>>>>>>>>>>>>>>> Friday that all of our
>>>>>>>>>>>>>>>>>>>>>>>>> HSAIL test cases broke. The cause was some
>>>>>>>>>>>>>>>>>>>>>>>>> imperfect code in our HSAILAssembler for compare
>>>>>>>>>>>>>>>>>>>>>>>>> instructions
>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>>>>>> when presented with an unordered compare could
>>>>>>>> generate
>>>>>>>>>>>>>>>>>>>>>>>>> code that would not assemble, and was easy to
>> fix.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> But I was wondering how this made it past the
>>>>> gate.
>>>>>>>>>>>>>>>>>>>>>>>>>> Can you describe what gate commands are used
>>>>>>>> regarding
>>>>>>>>>>>>>>> hsail?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We simply run 'mx gate' which will include
>>>>>>>>>>>>>>>>>>>>>>>>> running all the HSAIL unit tests.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On my Mac with the latest bits:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> $ mx --vm server unittest hsail executing junit
>>>>>>>>>>>>>>>>>>>>>>>>> tests
>>>>>>>>>>>>> now...
>>>>>>>>>>>>>>>>>>>>>>>>> (107 test classes) JUnit version 4.8
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>> ........................................................................
>>>>>>>>>>>>>>>>>>>>>>>>> ...........I................I......
>>>>>>>>>>>>>>>>>>>>>>>>> Time: 5.525
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> OK (105 tests)
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Keep in mind I (and the gate infrastructure)
>>>>>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>> the HSAIL simulator.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> -Doug
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>
>
More information about the graal-dev
mailing list