Overclock.net › Forums › AMD › AMD CPUs › Making HSA a reality
New Posts  All Forums:Forum Nav:

Making HSA a reality - Page 5

post #41 of 51
Thread Starter 
I have a little experience with C and C++. I actually learned them years ago before I even touched Java. It's just going to take some work to update my skills.

I'm not giving up on Java per se - I have aparapi-lambda working, mostly - it's just that I might be able to get more out of the GCC compiler than I can anything else.

How does one leverage CodeXL to produce HSAIL? I have looked at it before, and it appears to be a massive debugger/code optimizer. Or are you suggesting that I use it in tandem with aparapi-lambda?
post #42 of 51
I get your point about the "NULL" problem.
I thought using "Aparapi.ranne.forEach" can get HSA functional.
But it doesn`t work actually.
From now on, my MC project is useless. LOL
It must be added "parallel()".
Then I get a NULL exception.
I am now investigating the sample code.
It seems like we must create a new instance of the object that we want to use HSA.
Or it will be no data in it.
post #43 of 51
Thread Starter 
Hmm, interesting. Maybe that's why I'm getting null pointer exceptions in batch mode on HSAILMathtester, but I'm not getting them when the tests are run individually . . . I dunno, it's buggy and weird. If they had actually updated aparapi-lambda sometime in the past six months and acted on some of my bug reports, then I'm sure we would not be having these problems.

What's interesting to me is that I actually had more problems when I initialized a new Device.hsa() "object" frequently, so I started initializing one as a static inside the main method for use by all other methods. It's just that it can not be used in parallel for some reason. So the CPU code uses 4 worker threads (or 3 in "hybrid mode"), but only one worker thread in straight-up HSA mode. I almost got the thing working, ALMOST, but if you just hammer the GPU constantly and keep calling the Device.hsa() "object" eventually null pointer exceptions or segfaults happen. At least I figured out how to get rid of the segfaults.
post #44 of 51
I just figure that out.
It`s the "loop".
If we put a method or an object that contains loop.
No matter how big or small it is. (like 0 to 1, just 1 step.)
It will end up with NullPointerException.
You can try Math.max and Math.random.
The max method is working but random is not.
Random has a do-while loop in it.
post #45 of 51
Thread Starter 
Hmm, interesting. I've mostly been able to get do/while looks, for looks, and while loops to work inside an HSA lambda, but after awhile it craps out with nullpointer exception.

The problem is that there's a performance hit whenever you initiate an HSA lambda due to the JNI calls that are invoked by such when using aparapi-lambda. So if you have an outer loop, and an HSA lambda in each loop iteration, then you're going to get slower performance than if you have a lambda with an internal loop.

You can set the maximum number of iterations for the lambda to MAX_INT, but no higher. If you need more than ~2 billion iterations of a particular block of code, you're out of luck there.

But, I agree that if you can avoid loops inside the lambda, that you should.
post #46 of 51
so, the one that got fired from AMD because of HSA have a name? is that Manju guy? AMD is pretty weird lately.
post #47 of 51
Thread Starter 
Quote:
Originally Posted by tuakdancinta View Post

so, the one that got fired from AMD because of HSA have a name? is that Manju guy? AMD is pretty weird lately.

At this point it's not really productive to point fingers at any of the people that AMD laid off, or at AMD for doing the layoffs, so I'll leave names out of it. There were plenty of people on HSA-related projects (mostly OSS) that had to pack their bags and go.

The OSS community as a whole doesn't have the resources necessary to do the work that the AMD guys (and gals?) were doing to contribute. So, despite the fact that anyone could reintroduce HSA GPGPU code to Graal and then restart work on Sumatra, I doubt there are many who really know how.

You would have to update the entire project to 1.0P (Sumatra is still on .95), and you'd have to know 1.0P AND understand how the OpenJDK project works, and . . . ugh. Gives me a headache just thinking about it.
post #48 of 51
Quote:
Originally Posted by softpak View Post

Don`t give it up so soon.
C/C++ is not easy to learn.
You can give CodeXL a try. developer.amd.com/tools-and-sdks/opencl-zone/codexl/
It supports JAVA now.
I've try it, it updates to version 1.7.8364.0, it says about debug, profile, and build and analyze, it have samples.
So, basically it do nothing.
so, why they bother to release it?
post #49 of 51
here man try this links instead:
https://software.intel.com/sites/landingpage/opencl/user-guide/Configuring_Microsoft_Visual_Studio.htm and http://kode-stuff.blogspot.com/2012/11/setting-up-opencl-in-visual-studio_1.html?m=1
CodeXl is for Professional development only. It will help you to squeeze out your GPU, it won't help for beginners.
post #50 of 51
Thread Starter 
Meh, OpenCL is great and all, but barring OpenCL 2.0, there's no support for fun HSA features like passing pointers in lieu of memcopy between system RAM and framebuffer, etc. There is CLOC, but I haven't looked into it much yet.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: AMD CPUs
Overclock.net › Forums › AMD › AMD CPUs › Making HSA a reality