Ocelot Released

[Gregory Frederick Diamos]

We finally released the source code today under the BSD license. The
emulator implements the PTX virtual machine and executes programs
using a single CPU thread, one instruction at a time. We have verified
that all of the CUDA SDK examples from 2.1 and 2.2 run using the
emulator except for the programs that use the Driver Level API, which
we do not support. Like Barra and GPGPU-sim, we provide a set of
libraries that replace libcudart.so, so you should be able to link any
CUDA program against the emulator and have it transparently replace
the NVIDIA driver and runtime.

The emulator has hooks for trace generators that can examine the
complete system state after each instruction is executed. We have
several trace generators to record all memory traffic and inter-thread
communication through shared memory in place already and it should be
fairly easy to add others.

We also release a set of program analysis tools for PTX that allows
you to generate control flow graphs, dominator trees, dataflow graphs,
and convert PTX to pure SSA form as part of the code base.

The entire project can be downloaded here http://gpuocelot.googlecode.com/files/ocelot-0.4.36.tar.gz
. API documentation can be found here: http://www.gdiamos.net/classes/translator/api/index.html.
Finally, we have put together a quick tutorial for running a CUDA
program on the emulator: http://code.google.com/p/gpuocelot/wiki/Installation
.

We plan to continue to develop this project with the goal of
eventually having a complete compilation chain from CUDA for x86 CPUs
as well as NVIDIA GPUs as well as analysis tools supporting each path.

[Rod]

Hi Greg,

I am happy to see that Ocelot has been released. I am trying to
install it on my Fedora 10 machine but, unfortunately, it only comes
with Boost 1.34. It seems I will have to install a VM with Ubuntu
9.04.

Best,

Rodrigo

On Jul 10, 8:49 am, Gregory Frederick Diamos

<gregory.dia...@gatech.edu> wrote:
> We finally released the source code today under the BSD license. The
> emulator implements the PTX virtual machine and executes programs
> using a single CPU thread, one instruction at a time. We have verified
> that all of the CUDA SDK examples from 2.1 and 2.2 run using the
> emulator except for the programs that use the Driver Level API, which
> we do not support. Like Barra and GPGPU-sim, we provide a set of
> libraries that replace libcudart.so, so you should be able to link any
> CUDA program against the emulator and have it transparently replace
> the NVIDIA driver and runtime.
>
> The emulator has hooks for trace generators that can examine the
> complete system state after each instruction is executed. We have
> several trace generators to record all memory traffic and inter-thread
> communication through shared memory in place already and it should be
> fairly easy to add others.
>
> We also release a set of program analysis tools for PTX that allows
> you to generate control flow graphs, dominator trees, dataflow graphs,
> and convert PTX to pure SSA form as part of the code base.
>

> The entire project can be downloaded herehttp://gpuocelot.googlecode.com/files/ocelot-0.4.36.tar.gz

[Bales, Benjamin Bruce]

Go get the source off http://sourceforge.net/projects/boost/files/ .

Check out this for installation instructions:
http://www.boost.org/doc/libs/1_39_0/more/getting_started/unix-variants.html

It basically requires a:
[download and untar everything]
./bootstrap
./bjam install

Note you have to get bjam from another file hosted on their Sourceforge page.

The only issue I had was with library names. By default the build process injects compiler information in the names which Ocelot (naturally) doesn't like.

Deleting the 'gcc43-'s out of the filenames worked for me. Out of the library files that did not have version information in their names with the regex rename. There is probably a better way to do this (in the build process).

Ben

[Gregory Frederick Diamos]

Yes, unfortunately as Ben mentioned boost will typically tag the library
names with information about which compiler was used to generate it. We
use GNU autotools to find libraries and unfortunately there is no way
(that I know of) to search for library names with regular expressions.

So I would stick with Ben's method of renaming the generated library
names... for example if boost generated
libboost_serialization-mt-gcc33.so renamed it to
libboost_serialization-mt.so

Regards,

Greg

[Rod]

Ben,

Thanks for the tips. How did you rename the soft links? Now I have a
bunch of broken soft links pointing to the old 'gcc43-' names.

Rodrigo

On Jul 17, 7:26 am, "Bales, Benjamin Bruce" <bbal...@utk.edu> wrote:
> Go get the source offhttp://sourceforge.net/projects/boost/files/.
>

> Check out this for installation instructions:http://www.boost.org/doc/libs/1_39_0/more/getting_started/unix-varian...

>  winmail.dat
> 5KViewDownload

[Gregory Frederick Diamos]

You could just create new soft links to the libraries with the longer
names. For example:


ln -s libboost_serialization-mt-gcc33.so libboost_serialization-mt.so


Greg

[Bales, Benjamin Bruce]

If you have the regex rename, then just changing the names of the boost libraries without version information in their names works.

So (from a fresh libboost install):
rename 's/gcc43-//' *gcc43-mt.*

This takes the gcc43- out of all the filenames that match *gcc43-mt.*

As I remember, the files with version information won't match *gcc43-mt.*, so the links will all still work. You can add '-n' to the rename command to do a test run (nothing will actually get renamed, you'll just see what will if you removed the '-n' flag)

[Rod]

Thank you!

I'm past the Boost installation. I am installing GLEW now. I tried
'yum install glew' but that didn't seem to install the required libs
and headers. I am downloading the tgz from the GLEW website and
compiling it. Hopefully that will work. Please let me know if you have
any more tips here. Thanks for the help so far.

Best,

Rodrigo

>  winmail.dat
> 6KViewDownload

[Zhigang Gong]

Hi Greg,

We recently found that there is a statement in the bottom of file "ocelot/COPYING":

	You agree that the Software will not be shipped, transferred, exported, or re-exported directly into any country prohibited by the United States
	Export Administration Act and the regulations thereunder nor will be
	used for any purpose prohibited by the Act.

The above statement makes the whole project not a pure BSD license thus we can't

distribute any project which use it under GPL or LGPL license. A related FAQ is at:

https://people.debian.org/~bap/dfsg-faq  part 12p.

On the other hand, at the top level's LICENSE file, there is no such statement which

make the actual license unclear.

I'm the maintainer of Beignet project which is an open source OpenCL library for Intel

platforms and uses LGPL license. The beignet project is using  some structural related

code in the following files:

http://cgit.freedesktop.org/beignet/tree/backend/src/ir/structural_analysis.cpp

http://cgit.freedesktop.org/beignet/tree/backend/src/ir/structural_analysis.hpp

Could you help to clarify the license status of Ocelot project?

We will be very appreciate if this project is under pure BSD license and could remove

the US export restrication statement in the COPYING file.

Looking forward your response. And thanks for Rebecca who raised this issue to us.

Thanks,

Zhigang Gong