Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (512)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  LWJGL now supports OpenCL  (Read 3927 times)
0 Members and 1 Guest are viewing this topic.
Offline Spasi
« Posted 2010-09-27 00:54:18 »

Details here. A working build should be up soon, I could use more people testing it. Crash reports and/or API feedback will be appreciated.
Offline bienator

Senior Duke




OutOfCoffeeException


« Reply #1 - Posted 2010-09-27 09:54:03 »

congrats. Java has now the fourth CL binding...

Offline Spasi
« Reply #2 - Posted 2010-09-27 12:47:56 »

choice is a good thing. As you already said both apis have differences in public api design, build, java 1.4 or 1.5 compatibility and even in the usecases. LWJGL is focussed on games and is more than GL, JOGL is "just" a OpenGL binding.

Its to late for a merge without killing one of them. Its like merging eclipse with netbeans.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2010-09-27 12:49:45 »

congrats. Java has now the fourth CL binding...
Why on earth would that be your first reply.

Do I need to remind you JOGL was the 'fourth' GL binding?

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline bienator

Senior Duke




OutOfCoffeeException


« Reply #4 - Posted 2010-09-27 14:08:32 »

@spasi Thanks for quoting me since i still fully agree with it, despite the fact that its a bit off topic here.
Let me try to explain why:
CL bindings are completely independent libraries. You (as a LWJGL contributer or user) could have the choice between Marco's jocl.org which looks similar to LWJGL's API, Olivie's JNA bindings or http://jocl.jogamp.org which has similar API design as JOGL/JOAL on the low level (lets ignore the high level bindings for now since differ a bit more).

CL-GL interoperability is just about sharing 2 longs at context creation - thats all.

Nonetheless (or even because of that Smiley ), i am very carious to take a look at the javadocs of the low level part (we call it LLB).

@Riven
sorry, don't get it what you want to tell me with the first sentence

happy coding!

Offline gouessej
« Reply #5 - Posted 2010-09-27 14:37:08 »

Hi!

You're going to duplicate efforts once again whereas OpenCL is quite young (unlike OpenGL), it could have been an opportunity to concentrate all efforts on a single binding (forget the 2 other ones that will be given up in some years). We are doing the same mistakes... I don't think choice is always a good thing.

The difference with OpenGL is that LWJGL and its main competitor (LWJGL) are quite "old" which drives any merge complicated whereas we could have joined our forces to develop and maintain a single powerful and coherent OpenCL binding from the beginning.

Good luck.

Offline cylab

JGO Ninja


Medals: 52



« Reply #6 - Posted 2010-09-27 15:52:02 »

*sigh* could you all please stop this?

just get along or shut up. if they want to duplicate effort, what the heck. everybody can do what he wants with his time. let everyone work on their favorite project or use whatever they want. either join one party or the other. let spasi etc talk about LWJGL, let julien etc talk about JOGL.

either, or both will survive or die in the end and it absolutely does not matter what opinion any of us has on the quality or api or development model or whatever of them. learn from, or ignore eachother - but please stop this "kindergarden".

Mathias - I Know What [you] Did Last Summer!
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #7 - Posted 2010-09-27 17:23:45 »

Congrats, Spasi et. al! This is a big milestone for you guys.

See my work:
OTC Software
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #8 - Posted 2010-09-27 18:33:11 »

You (as a LWJGL contributer or user) could have the choice between Marco's jocl.org which looks similar to LWJGL's API, Olivie's JNA bindings or http://jocl.jogamp.org which has similar API design as JOGL/JOAL on the low level (lets ignore the high level bindings for now since differ a bit more).
so... what was your excuse Roll Eyes

Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2010-09-27 19:39:05 »

NIH FTW!

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline bienator

Senior Duke




OutOfCoffeeException


« Reply #10 - Posted 2010-09-27 20:18:12 »

Are you kidding?
There was no JNI based binding out there at this time. Even drivers weren't officially available. Both, Marco and me had to wait for the driver release before publishing binaries & code. He decided to code everything by hand, I instead used gluegen to generate everything from headers. Additionally Marco initially licensed his stuff with a non commercial license (he changed the license recently to MIT/X11).
This alone was a showstopper for my needs over one year ago. (and yes we worked together to resolve technical issues)

(thats my last post on that topic)

Offline Momoko_Fan

Junior Duke


Medals: 2



« Reply #11 - Posted 2010-09-27 23:38:17 »

Can't say I agree with you guys. Having OpenCL in LWJGL means one less DLL I have to bundle with my engine. It will also integrate neatly into the already existing OpenGL renderer with buffer sharing and all.
Also this having the LWJGL brand I can trust them to have a good and clean API that works.
Offline SimonH
« Reply #12 - Posted 2010-09-28 00:33:34 »

I've been reading up on openCL and I'm nearly convinced. It makes a lot of sense to use the GPU to do the donkey work, and to have that tied in with the lwjgl package. So, hey, this is a really good addition to lwjgl - a new tool (which I don't fully understand yet) which could turn out to be a big asset in time. ATM I'm wondering: 'how many cards support openCL?' but then I distrusted openGL generally - until minecraft made it real!
Thumbs up!

People make games and games make people
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #13 - Posted 2010-09-28 05:31:41 »

fwiw, opencl can run on either the gpu or cpu - sort of a "hardware fallback".

Offline Spasi
« Reply #14 - Posted 2010-09-28 21:52:06 »

OpenCL running on the CPU is not simply a fallback*. The OpenCL programs you write are not only automatically multithreaded when they run; they're also automatically vectorized. The compilers can do that because of how the OpenCL C language is defined, the same way that multiple actions in your GLSL shaders can be converted to e.g. a single MAD instruction on the GPU. I don't know about you, but I think being able to write cross-platform code that gets automagically converted to SSE2/AVX instructions and whatnot, is a big deal. Especially for us poor Java developers, it's the huge opportunity we've been waiting for.

Of course, that's all assuming Intel releases their implementation soon enough and AMD improves Stream's one. Btw, with the OpenCL ICD (that AMD already supports) you can mix-and-match OpenCL platforms. So, for example, a computer with an Intel CPU and an AMD GPU will be able to use Intel's implementation for CPU algorithms and AMD's one for GPU stuff.

* Arguably, an algorithm designed for GPU execution will probably perform horribly on the CPU. So you might as well provide an alternate (non-OpenCL?) implementation anyway.
Offline Spasi
« Reply #15 - Posted 2010-09-28 22:24:41 »

Hmm, just found this in today's dev newsletter from AMD:

Quote
Aparapi is an API for expressing data parallel workloads in Java and running those workloads on a compatible GPU if possible. Where your workload actually ends up running depends on

    * whether you have the ATI Stream SDK installed
    * whether you have a compatible GPU
    * whether your Java parallel code avoids any constructs that would make it untranslatable to OpenCL™. These restrictions are detailed in the Aparapi Readme file.

If your code and your target platform meet all of the above, Aparapi will translate your workload to OpenCL™ and will run your workload on the GPU. Otherwise, your same code will still run as a parallel workload using a Java Thread Pool and will be able to take advantage of multiple cpu cores if you have them.
Online kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #16 - Posted 2010-09-28 22:29:00 »

Hmm, just found this in today's dev newsletter from AMD:


wow that sounds pretty cool, looking forward to see how it turns out.
Offline Momoko_Fan

Junior Duke


Medals: 2



« Reply #17 - Posted 2010-09-29 01:18:54 »

That's kinda interesting.. I was also prototyping with this sort of thing. But I did it in the bytecode level, which, by virtue of being low-level, doesn't have some of the odd limitations of this API. (e.g the a[i++] = b[i++] thing for example)
I guess that in the future there would be workarounds for various Java features to be converted into OpenCL code that had the same effect but used different ways of doing it.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #18 - Posted 2010-09-29 07:19:22 »

so basically, Aparapi is a threadpool executor - that may or may not translate some or all of the code to run on OpenCL if you happen to have a compatible dll with a compatible gpu.
color me unimpressed.

The lack of control on whether or not it will run in java or opencl is a pretty big issue. From my point of view, you'd be better of using ExecutorService and then having OpenCL tasks inside (which is basically what Aparapi is doing anyway (sans the bytecode translation))

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (50 views)
2014-10-17 03:59:02

Norakomi (39 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (36 views)
2014-10-15 16:18:58

TehJavaDev (66 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (55 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!