I am a little slow to post this, but Geohot seems to have made it past the hypervisor. While it is interesting and exciting, it isn't particularly useful at this time. It doesn't really help the project, and he is still trying to make the exploit useful.
I plan to read the full writeup at some point, but really only for my own interest. Too many people got over excited at the announcement. However, I will keep tabs on any updates he makes.
I successfully split the monster source file into many baby source files. This isn't particularly impressive, but it will make things more manageable. Commits will be smaller and more precise. Functions will be more encapsulated and less dependent. The only drawback so far is having multiple files open and searching for function definitions. On one or both of the wikis, I may make a list of the functions and their file locations.
I also made some changes to the kernel parser. First, it now handles new lines. I somehow missed testing that before. Second, it now returns a list of the kernel's argument types. I can now say, "Oh, this kernel is expecting four floats and an integer." I also need it to return whether the argument is a pointer, but I'll get around to that later. I have not done any work on the kernel transformer. The task was a bit intimidating, so I moved to other things.
I fixed the makefile to handle the new split files. After running the new makefile, I also fixed a handful of compiler warnings. Some warnings still remain (see attached file), but they aren't critical. Although everything compiles, I have not yet tried to run it. I am especially wary of the changes I made to kernel_parser.lua and kernel_parser.c. The Lua file tested fine, but I couldn't check the new C code.
Not being able to compile everything on demand makes me far more cautious and diligent, but it does certainly slow me down. I've gotten used to
And the only prescription is more OpenCL programming.
After a rather extended break, I feel the need to get back into some serious programming. It will take some time to get back into the swing of the project, but my first priority will expedite that process. I've wanted to split up the primary header file for a long time. 1855 lines of code is a bit much, especially when most of it can be grouped together into separate files. I plan to make a new branch in
I got the fever when I came across another OpenCL project on GitHub. It is quite similar to mine except he is trying to make a general implementation for
I've been doing some "cleaning up" in the
In addition to the file splitting, I want to get a prototype "kernel transformer" up and running. It will transform a basic kernel like
I should have plenty of time tonight to work on this. I should be able to at least get started on splitting up that giant file.
My previous post was a little light on details. I have been asked to expand on it. As a side note, please see the new Disclaimer section.
As I mentioned in the previous post, I was able to get the same source code compiled and running on both my Mac and the CellBuzz cluster. There are only two minor changes that need to be made.
The first part "
Important Note: This only works on Snow Leopard (10.6.x and higher). Earlier versions of Mac OS do not have OpenCL. Also, I believe users with ATI video cards require 10.6.2 or later.
Did you get the code to run on your Macintosh? Good. Now we move on to CellBuzz. Two changes to the source code are in order. Line 8 reads "
It is just a simple preprocessor. The other change, which isn't necessary but helps, is line 57 which reads
Change it to read
The SPU is considered an accelerator in the IBM implementation, which I think is a pretty good idea. Compiling this code is almost identical, "
After the library errors, it complains about the pragmas, but that doesn't matter. I don't have a great yearning to use the XLC compiler. Maybe someone else can figure it out.
I've attached my modified source code that compiles and runs on both systems. Credit goes to MacResearch for the bulk of the source code. I plan to make a benchmarking program, but I may just use an existing one.
After submitting a request, Georgia Tech was kind enough to install the IBM OpenCL dev kit on their CellBuzz cluster. You will need to compile your code on the compute nodes as the compiler and libraries are PPC only.
I was able to compile and run the blackscholes sample code, but I did not understand the output. I have been following a tutorial series for OpenCL on Macintosh. I was able to compile and run the sample code from episode 3 with two minor modifications.
I noticed something cool, though. I had been treating the entire Cell processor as a compute device with type
A member of the mailing list pointed out that IBM has released an official version of OpenCL for Power hardware running Linux. They say it has been tested with the IBM BladeCenter QS22 which uses the newer version of the Cell Processor. When I get some free time, I will definitely download the development kit and give it a try.
Despite this news, an open source version of the implementation is still desirable. This project has not reached its end. I will certainly work on the project as much as I can; either for my own interest or just to maintain an open source version. The IBM implementation also seems to be in an early stage. Maybe I still have time to catch up. :-p
But I don't feel too bad being beat to the first waypoint by "teams in IBM consisting of the HPC Multicore Software Development team ..., the XL C Compiler team ..., with assistance from the Compiler Research team."
The project is still going, just at a much slower rate. Distractions and obligations keep me from working on the project. I still think about it and read up on OpenCL, but I haven't done much programming recently.
As I have said before, the project will always exist, but progress may be fairly slow at times. I just have to keep at it.
With the release of Snow Leopard (10.6), OpenCL now has an official, full implementation. AMD recently announced an x86 implementation, but Apple made it work with GPUs as well.
If you want to try it out, a user over at the MacRumors forums found a small application that will test your computer's OpenCL capabilities. I can definitely use Apple's implementation to test the functionality of my project.
I wrote a simple kernel parser in Lua. It returns the kernel function name and the number of arguments. Right now it only works if all the information is on one line, but I can update that later. The parser is in Lua for two reasons. First, it is much easier to write a parser in Lua than in C. Second, I just wanted some practice with Lua. The only issue was compiling the Lua libraries for the Cell architecture. I spent most of the evening trying to compile the library and its dependencies. It took much longer than expected, primarily because of my own stupidity and inattentiveness. Luckily, the dependency list was fairly short. I needed readline and ncurses. I think I will add these libraries to the distribution just to make it easier for others.
I also did some refactoring. I moved the source code into subdirectories for better organization and separation. I also created a new makefile that is more flexible than the old auto-generated one. I tried to use autotools, but I couldn't find an easy way to compile different batches of source code with different compilers. I can worry about distribution mechanisms later. The project isn't even close to being completed.
1-10 of 28