kappa
|
 |
«
Posted
2011-09-15 22:11:05 » |
|
The AMD JavaLabs team is proud to announce the open source release of our Aparapi project. In theory sounds like a much nicer way to use OpenCL from Java. More info here. |
|
|
|
|
|
ReBirth
|
|
«
Reply #1 - Posted
2011-09-16 03:36:29 » |
|
Hmm what system should I use for my next new pc, i3 or Llano...? [look the post] maybe Llano~  |
|
|
|
|
lhkbob
|
|
«
Reply #2 - Posted
2011-09-16 05:06:18 » |
|
That sounds like a very cool trick, I'm curious to know how often it's able to compile java bytecode into an OpenCL kernel.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
|
|
|
|
|
princec
|
|
«
Reply #5 - Posted
2011-09-16 10:13:09 » |
|
I bet that's because it uses Unsafe under the hood somewhere  Just a guess, mind. Cas |
|
|
|
|
JL235
|
|
«
Reply #6 - Posted
2011-09-16 11:37:30 » |
|
It's more likely that they haven't really tested it with other JVMs, and that is why they don't recommend them.
It might be nice if this was taken a little further, and folded into a Java compiler. If the code could be used with OpenCL, it would be automatically translated into the appropriate code. It might also need to add some runtime checks to avoid using it on trivial examples. That would be pretty cool.
|
|
|
|
|
|
|
gouessej
|
|
«
Reply #8 - Posted
2011-09-16 13:14:11 » |
|
@gouessej - I wouldn't have thought that any of that poses an issue for OpenJDK. The fact they think most Linux distributions still default to gcj made me laugh though!
Unsafe works on OpenJDK as far as I know. Aparapi cannot be used on NVIDIA graphics cards. Therefore I won't give it a try. |
|
|
|
|
theagentd
|
|
«
Reply #9 - Posted
2011-09-16 14:58:24 » |
|
Aparapi cannot be used on NVIDIA graphics cards.
+1 |
Myomyomyo.
|
|
|
Games published by our own members! Check 'em out!
|
|
|
nsigma
|
|
«
Reply #10 - Posted
2011-09-16 15:17:49 » |
|
@gouessej - I wouldn't have thought that any of that poses an issue for OpenJDK. The fact they think most Linux distributions still default to gcj made me laugh though!
Unsafe works on OpenJDK as far as I know. Aparapi cannot be used on NVIDIA graphics cards. Therefore I won't give it a try. I was specifically responding to your comment about OpenJDK. While slightly amused at your NVIDIA comment, knowing your strong open-source beliefs, Aparapi cannot be used on NVIDIA graphics cards currently - they are actively seeking contributions to target other OpenCL implementations. I don't think there's much that's vendor specific. |
Praxis LIVE - hybrid visual IDE for (live) creative coding
|
|
|
|
princec
|
|
«
Reply #11 - Posted
2011-09-16 17:04:05 » |
|
Is it actually based on OpenCL? Or is it a completely separate API? Cas |
|
|
|
|
nsigma
|
|
«
Reply #12 - Posted
2011-09-16 17:16:02 » |
|
|
Praxis LIVE - hybrid visual IDE for (live) creative coding
|
|
|
|
theagentd
|
|
«
Reply #13 - Posted
2011-09-16 19:00:55 » |
|
I wonder how they screwed it up so that it only works on AMD GPUs if it's OpenCL...
|
Myomyomyo.
|
|
|
|
gouessej
|
|
«
Reply #14 - Posted
2011-09-16 19:37:41 » |
|
@gouessej - I wouldn't have thought that any of that poses an issue for OpenJDK. The fact they think most Linux distributions still default to gcj made me laugh though!
Unsafe works on OpenJDK as far as I know. Aparapi cannot be used on NVIDIA graphics cards. Therefore I won't give it a try. I was specifically responding to your comment about OpenJDK. While slightly amused at your NVIDIA comment, knowing your strong open-source beliefs, Aparapi cannot be used on NVIDIA graphics cards currently - they are actively seeking contributions to target other OpenCL implementations. I don't think there's much that's vendor specific. They should use JOCL, it would solve several problems of performances (see the FAQ) and you know that I cannot contribute to everything, I'm already working on the JOGL 2.0 renderer of Ardor3d... |
|
|
|
|
nsigma
|
|
«
Reply #15 - Posted
2011-09-16 20:43:21 » |
|
They should use JOCL, it would solve several problems of performances (see the FAQ) and you know that I cannot contribute to everything, I'm already working on the JOGL 2.0 renderer of Ardor3d...
I wasn't suggesting that you specifically had to work on it! As for JOCL solving some of the performance problems, aren't you missing the point?! Maybe you should start coding in C or assembler because it solves some of the performance problems of Java?  I wonder if a JOCL backing to the compiler would be possible though? |
Praxis LIVE - hybrid visual IDE for (live) creative coding
|
|
|
|
gouessej
|
|
«
Reply #16 - Posted
2011-09-16 20:55:03 » |
|
They should use JOCL, it would solve several problems of performances (see the FAQ) and you know that I cannot contribute to everything, I'm already working on the JOGL 2.0 renderer of Ardor3d...
I wasn't suggesting that you specifically had to work on it! As for JOCL solving some of the performance problems, aren't you missing the point?! Maybe you should start coding in C or assembler because it solves some of the performance problems of Java? I wonder if a JOCL backing to the compiler would be possible though? Like princec, I really wonder if people really reads the FAQ: http://code.google.com/p/aparapi/wiki/FrequentlyAskedQuestions#Why_does_Aparapi_seems_to_be_copying_data_unnecessarily_back_andJOCL works with NVIDIA and ATI graphics cards. I have seen a lot of projects duplicating objects in memory because they do not use NIO buffers, I'm not a newbie. For example, it is the case of the Java version of VSG OpenInventor. I remind you that I have a strong experience in C, I wrote a simulator of heavy processes, I accepted some missions at the beginning of my career in C. Maybe you were joking but I did not find it fun. |
|
|
|
|
nsigma
|
|
«
Reply #17 - Posted
2011-09-16 21:07:53 » |
|
Like princec, I really wonder if people really reads the FAQ:
Huh? It was me that made that point to princec (in jest I hasten to add!) Yes, I was joking, but you still seem to be misunderstanding what the point of Aparapi is - to run Java code on the GPU using OpenCL. It converts Java bytecode to OpenCL at runtime. You swap some performance for convenience, hence my comment about assembler over Java. |
Praxis LIVE - hybrid visual IDE for (live) creative coding
|
|
|
|
kappa
|
|
«
Reply #18 - Posted
2011-09-16 21:13:35 » |
|
Yes, I was joking, but you still seem to be misunderstanding what the point of Aparapi is - to run Java code on the GPU using OpenCL. It converts Java bytecode to OpenCL at runtime. You swap some performance for convenience, hence my comment about assembler over Java.
Yup agreed, OpenCL and even OpenGL shaders are a pain for java developers to pick up, no matter how nice the connecting api to C is, something like the above project is a pretty welcome idea/attempt IMO. The objection that you shouldn't support the project because it is AMD only or slow in some way are invalid atm, its still very early days for the project and they've made it clear they want to eventually support all OpenCL hardware (and even asked for help regarding this). Its pretty rare for a big vendor like AMD to spend time and resources to care for the small java gaming/graphics/computing community, its even open source under the really nice BSD license. |
|
|
|
|
|
princec
|
|
«
Reply #19 - Posted
2011-09-16 22:33:47 » |
|
Well said. The FAQ's a bit of a big 'un though, had a bit of a tl;dr moment with it to be honest. But I was wondering why it only worked with ATI if it was purportedly built on OpenCL, which is supposedly supported by both ATI/AMD and Nvidia. (What about Intel? I suppose that's asking a bit much seeing as they can't even get their drivers to switch to bloody fullscreen without crashing) Cas |
|
|
|
|
gouessej
|
|
«
Reply #20 - Posted
2011-09-17 09:47:36 » |
|
The objection that you shouldn't support the project because it is AMD only or slow in some way are invalid atm, its still very early days for the project and they've made it clear they want to eventually support all OpenCL hardware (and even asked for help regarding this). Its pretty rare for a big vendor like AMD to spend time and resources to care for the small java gaming/graphics/computing community, its even open source under the really nice BSD license.
I'm ok with the principle, not with its implementation. AMD could have used JavaAssist or something like that to manipulate the bytecode and any Java binding of OpenCL instead of writing some more JNI code (which complicated the interoperability with Java bindings for the OpenGL API). |
|
|
|
gfrost
Senior Newbie  Medals: 2
|
|
«
Reply #21 - Posted
2011-10-01 19:21:37 » |
|
Aparapi will probably work fine (with a single one line hack) with any OpenCL 1.1 compliant runtime. I am the Aparapi team lead and architect and we deliberately culled our test metrics by testing only on AMD OpenCL runtime supported devices. We also built the dev scripts with AMD APP SDK in mind. Don't tell my employer  but I have run it with NVidia's runtime, I have not tried Intel's or Apple's. Initially we had issues with the NVidia runtime because support for some features we wanted required OpenCL 1.1 compliance and we could not get the 1.1 SDK without registering with NVidia (something I was not too-motivated to do ). Now, they are 1.1 compliant and I suspect that the line of code which limits looking for AMD's OpenCL runtime can (and should be removed). Take a look at line 417 in aparapi.cpp (I am a noobie on here and want to avoid posting links). Of course the build.properties for the JNI code will need to be tweaked to point to NVidia's include/lib files if someone needs to rebuild the code. My guess is someone with NVidia's SDK could build an NVidia compatible version in 20 minutes. Then I would recommend raising an issue and posting a patch (probably 3 lines of code ). I will happily commit it. Someone asked later why we did not use JavaAssist (or bcel) to do the bytecode analysis to create OpenCL. In truth we could have (I am huge JavaAssist fan and presented a session at JavaOne a few years back using it) but we wanted 0 dependencies on external libraries to simplify the open source process. I have exchanged emails with Micheal Bien and Marco Hutter (the two JOCL guys) and would like to look at using JOCL for adding library extensions to Aparapi. I still prefer the idea of not forcing Java developers to have to learn OpenCL. However, for those that are prepared to do this, I think that Aparapi + JOCL would prove a nice mix. I was pleased to discover this discussion and join this site. Gary |
|
|
|
|
|
CommanderKeith
|
|
«
Reply #22 - Posted
2011-10-04 15:24:19 » |
|
Hi Gary, that's great news. You're amazingly open with the whole project. Very impressive work.
I'm still learning openGL/openCL so this is quite over my head but this project is particularly interesting for java heads like us.
This is quite unrelated, but may I ask, why do AMD chips have generally poorer openGL drivers compared to NVidea chips? If all the dev's at AMD are anything like you then I would have thought that the AMD graphics chips would have rolls-royce openGL drivers.
Keith
|
|
|
|
gfrost
Senior Newbie Medals: 2
|
|
«
Reply #23 - Posted
2011-10-13 01:37:05 » |
|
Aparapi should now work with any OpenCL 1.1 compliant runtime. Witold Bolt kindly supplied a patch to support Mac OS and as part of that patch I removed the AMD only restriction. Now Aparapi will iterate through available 1.1 platforms and locate the first GPU device. I must confess non-AMD device testing is less than thorough but the chains are off. Give it a whirl. Gary |
|
|
|
|
|
zammbi
|
|
«
Reply #24 - Posted
2011-10-13 06:50:43 » |
|
Now Aparapi will iterate through available 1.1 platforms and locate the first GPU device.
Shouldn't it locate the best GPU device? Does it support Intel inbuilt graphics? |
|
|
|
|
theagentd
|
|
«
Reply #25 - Posted
2011-10-13 09:26:25 » |
|
Aparapi should now work with any OpenCL 1.1 compliant runtime.
Does it support Intel inbuilt graphics?
Wha...? Sure, by 2020, but the driver support is going to be so buggy that it'll crash on 99% of all OpenCL programs and fallback to software for the last 1%. >_> |
Myomyomyo.
|
|
|
|
gouessej
|
|
«
Reply #26 - Posted
2011-10-14 13:54:14 » |
|
Aparapi should now work with any OpenCL 1.1 compliant runtime.
Witold Bolt kindly supplied a patch to support Mac OS and as part of that patch I removed the AMD only restriction.
It is a good piece of news. When I suggested to use JOCL, it was mainly to allow interoperability with JOGL, not to force programmers to learn OpenCL. Best regards. |
|
|
|
|
xinaesthetic
|
|
«
Reply #27 - Posted
2011-10-15 09:38:57 » |
|
I'm just making a little hello world (won't probably have a chance to do much more than that in the next couple of weeks).
I notice that Kernel has various scalar maths methods implemented... I wonder how non-scalar OpenCL primitives and operations could be used. It seems performance will be compromised for things like graphics and physics if these are inaccessible, am I right?
|
|
|
|
|
|
tom
|
|
«
Reply #28 - Posted
2011-10-17 13:33:45 » |
|
Aparapi should now work with any OpenCL 1.1 compliant runtime.
Fantastic! It now works on my NVIDIA GeForce 9600 GT after updating to the latest drivers. I've tested it with some box intersections code that I had ported to OpenCL to test performance. Here are some benchmarking results: Original java code: 21206 ms OpenCL (using LWJGL): 1059 ms Aparapi GPU: 1592 ms aparapi SEQ: 12482 aparapi JTP: 6628 ms (2 cores) The benchmark test 100000 segments against 1000 boxes. The code uses 6 dot products to transform segment endpoints into box local space. In OpenCL these are buildt in, in aparapi I had to unroll them. This might explain the difference between OpenCL and aparapi. |
|
|
|
javazoid
Junior Devvie
Where's Flender?
|
|
«
Reply #29 - Posted
2011-12-01 14:27:13 » |
|
If there a way to write a simple 3x3 or 5x5 convolution with Aparapi ?
|
|
|
|
|
