Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (481)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (548)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 5 6 [7]
  ignore  |  Print  
  Catch 22 for jogl  (Read 34390 times)
0 Members and 1 Guest are viewing this topic.
Offline nsigma
« Reply #180 - Posted 2010-03-07 13:11:39 »

It is a very bad idea as JNA is slower than JNI (JNA uses Microsoft Platform Invoke under Windows which is noticeably slower than the path used by JNI) and GlueGen works reliably. I highly discourage Michael to use JNA instead of GlueGen. I'm sorry, I'm a quite old JOGL user and I will refuse any use of JNA in it.

I agree with you that rewriting JOGL with JNA is probably a bad idea, but only because it's seems like unnecessarily reinventing the wheel.  In general, I think JNA and JNAerator are great projects.  While there's obviously some extra overhead compared to JNI, I'd say it's pretty negligible when you factor in everything else your code is doing, and worth it for the ease of development and deployment.  I wrote a wrapper for Jack Audio Connection Kit using JNA a while back, and even without switching to the higher performing direct mapping mode this is perfectly capable of doing realtime, low latency audio without any skipped frames.

I have to say I haven't used JNA on Windows yet, but I'm under the impression that it uses the exact same library (libffi) to do its stuff, so don't know why the performance should be that much different.  i may be wrong but I think JNA is an equivalent of Platform Invoke, not that it uses the same mechanism.

And I doubt you'll convince the author of JavaCL to switch over - he's got rather a lot of time invested in JNA! :-)

Neil

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline AI Guy

Senior Newbie





« Reply #181 - Posted 2010-03-07 19:04:30 »

I was just putting the option out.  I have no direct interest in OpenGL, and no axe to grind.  It would entail some re-write, but Gluegen is aging / self maintained and a resource guzzler by comparison.

OpenCL is a different story.  I have a huge interest.  What happened in the past with OpenGL may not repeat itself with OpenCL.  The primary reason is OpenGL is just an API (ignoring GLSL) and OpenCL is a full C99 language.  There are API calls to manage it (compiling, exec, read/write) from what is called the host language, but the big action is what is running on the GPU.  They are called kernels.  This is attracting a constituency from everywhere, like Research-Engineering-Finance.  Being open has probably caused it to already be bigger than CUDA & CAL.  It seems very little is right now involved with vision.

Do not get me wrong, I am very impressed with Michael, & JOCL as a university thesis.  JOCL could put him in a good position for the future.  OpenCL might change rapidly though, and I am not sure competing for resources with JOGL for updates is a arrangement that is best for me.

I would also point out that the Particles Demo from the above site hands off to JOGL too, when it is done.  Performance seemed impressive to me anyway.  At my max resolution, 2560 x 1600, & old 8800 GTX, it does not really slow down that much with 1M particles.  It also seemed mildly entertaining. It makes me wonder if something similar to an OpenGL pipeline, or Java3D might be implementable as a OpenCL kernel pipeline.  Not suggesting this any direct path forward, but it might be a good proof of concept for some else's studies.
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #182 - Posted 2010-03-07 20:40:49 »

OpenCL might change rapidly though, and I am not sure competing for resources with JOGL for updates is a arrangement that is best for me.

maintaining "my" JOCL binding (my, since there is another one on jocl.org) is actually trivial. The work is basically done and everything is automated. Headers are automatically downloaded, preprocessed, parsed and the binding is generated etc. I refactored the gluegen generator, fixed the pseudo preprocessor and cleaned up several places, improved its performance, added unit tests, made it ANTLR 3 compatible, macro support, jdk5 features etc. There are a few places which could be made more DRY and a few ideas from Ken (one of the original authors of gluegen) but this is not really priority for me for now. (compiler setup is currently still a PITA)

As a result the ANT script of JOCL is around 250 lines long (the autogenerated netbeans stuff not counted).

It is IMO highly improbable that Khronos would (or could) introduce API changes which would break the build in a way which couldn't be fixed in a reasonable timeframe. In worst case its always possible to implement the function by hand (JOCL has around 150 lines of handwritten c code partly to simplify a few more complex opencl calls or do multiple api calls with one method call)

I know there are a lot more calls in OpenGL vs OpenCL,  but I would consider JNA for JOGL as well (I do not actually know what LWJGL is)
well you can end up doing a lot of api calls in OpenCL too. I have some tests using one Java-Thread per CLCommandQueue per GPU (to test the MultiQueueBarrier). Do this on the server and you produce more contention as in a fixed-function OpenGL 1.1 game.

btw my thesis isn't about "how to write a CL binding using gluegen" its rather "how to have fun with CL" Wink

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #183 - Posted 2010-03-08 09:57:48 »

I agree with you that rewriting JOGL with JNA is probably a bad idea, but only because it's seems like unnecessarily reinventing the wheel.  In general, I think JNA and JNAerator are great projects.  While there's obviously some extra overhead compared to JNI, I'd say it's pretty negligible when you factor in everything else your code is doing, and worth it for the ease of development and deployment.  I wrote a wrapper for Jack Audio Connection Kit using JNA a while back, and even without switching to the higher performing direct mapping mode this is perfectly capable of doing realtime, low latency audio without any skipped frames.

I have to say I haven't used JNA on Windows yet, but I'm under the impression that it uses the exact same library (libffi) to do its stuff, so don't know why the performance should be that much different.  i may be wrong but I think JNA is an equivalent of Platform Invoke, not that it uses the same mechanism.

And I doubt you'll convince the author of JavaCL to switch over - he's got rather a lot of time invested in JNA! :-)

Neil
I understand your position but the difference of performance is far from pretty negligible on my view as I use OpenGL on very poor machines. For example, if you use the C# OpenGL binding of OpenTK that precisely relies on Microsoft Platform Invoke, you will notice that it is at least 70% slower than JOGL, this is absolutely not acceptable. You can read this about JNA :
Quote
While some attention is paid to performance, correctness and ease of use take priority
I have tried to check if libffi uses Platform Invoke, I have no answer yet.

I understand the author of JavaCL has invested a lot of time in JNA but I don't see any interest of maintaining 3 very similar OpenCL bindings (OpenCL4Java, JavaCL and JOCL).

Go on Michael Wink

Offline nsigma
« Reply #184 - Posted 2010-03-08 12:55:31 »

I understand your position but the difference of performance is far from pretty negligible on my view as I use OpenGL on very poor machines. For example, if you use the C# OpenGL binding of OpenTK that precisely relies on Microsoft Platform Invoke, you will notice that it is at least 70% slower than JOGL, this is absolutely not acceptable.

No offence, but I think you're comparing apples and oranges - C# and Platform Invoke is not Java and JNA!  And even then do you mean that the whole application performs 70% slower or just the call across the VM<>Native divide?  If the latter, then I'd still say that this is usually going to be negligible and swamped by other factors.

Obviously, it's not possible to compare OpenGL experiences, but my experience of JNA with JNAJack and Gstreamer-Java has also been with low powered machines (a 6 year old Pentium M and a ULV 800MHz Celeron), and despite neither binding yet using JNA's direct mapping, both have solid performance.

To quote another section of the JNA site -

Quote
JNA direct mapping can provide performance near that of custom JNI

Personally, I don't think that either of our quotes truly reflect the reality of using JNA, but I would stand by my assertion that in the vast majority of cases where you need to call native code, JNA offers huge development and deployment benefits for a very minor performance hit.  You definitely won't get a 70% slowdown on your whole application using it, though I'm not sure if that's just me misreading what you wrote?

Quote
I understand the author of JavaCL has invested a lot of time in JNA but I don't see any interest of maintaining 3 very similar OpenCL bindings (OpenCL4Java, JavaCL and JOCL).

Well, 2!  OpenCL4Java and JavaCL seem to be two sides of the same coin.

Best wishes, Neil

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline gouessej
« Reply #185 - Posted 2010-03-08 13:53:48 »

No offence, but I think you're comparing apples and oranges - C# and Platform Invoke is not Java and JNA!  And even then do you mean that the whole application performs 70% slower or just the call across the VM<>Native divide?  If the latter, then I'd still say that this is usually going to be negligible and swamped by other factors.
It is not neglictable in projects like Jake2 as the both guys succeeded in going faster than the C/C++ version of Quake 2. The problem is that I found some years ago a document explaining how JNA works under Windows, it did not mention libffi but it mentioned explicitly the use of Microsoft P/Invoke. I have looked for this document for hours without success. Therefore, I thought I was not comparing apples and oranges. I will look for more information...

However, I have just found something very interesting :
http://stackoverflow.com/questions/1556421/use-jni-instead-of-jna-to-call-native-code
Quote
If you need a lot of memory copying. For example, you call one method which returns you a large byte buffer, you change something in it, then you need to call another method which uses this byte buffer. This would require you to copy this buffer from c to java, then copy it back from java to c. In this case jni will win in performance because you can keep and modify this buffer in c, without copying.
This is very important for an OpenGL binding.

https://jna.dev.java.net/#performance
Quote
How does JNA performance compare to custom JNI?

JNA direct mapping can provide performance near that of custom JNI. Nearly all the type mapping features of interface mapping are available, although automatic type conversion will likely incur some overhead.

The calling overhead for a single native call using JNA interface mapping can be an order of magnitude (~10X) greater time than equivalent custom JNI (whether it actually does in the context of your application is a different question). In raw terms, the calling overhead is on the order of hundreds of microseconds instead of tens of microseconds. Note that that's the call overhead, not the total call time. This magnitude is typical of the difference between systems using dynamically-maintained type information and systems where type information is statically compiled. JNI hard-codes type information in the method invocation, where JNA interface mapping dynamically determines type information at runtime.

You might expect a speedup of about an order of magnitude moving to JNA direct mapping, and a factor of two or three moving from there to custom JNI. The actual difference will vary depending on usage and function signatures. As with any optimization process, you should determine first where you need a speed increase, and then see how much difference there is by performing targeted optimizations. The ease of programming everything in Java usually outweighs small performance gains when using custom JNI.

Obviously, it's not possible to compare OpenGL experiences, but my experience of JNA with JNAJack and Gstreamer-Java has also been with low powered machines (a 6 year old Pentium M and a ULV 800MHz Celeron), and despite neither binding yet using JNA's direct mapping, both have solid performance.
Solid performance? You're not precise enough on my view. I'm sure it is enough for many applications but not for OpenGL (as I explained above) and it might become a problem for OpenCL.

Well, 2!  OpenCL4Java and JavaCL seem to be two sides of the same coin.
It was only a rumor some months ago... Ok but I don't yet see the interest of having 2 separate very similar OpenCL binding for Java (JavaCL and JOCL).

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #186 - Posted 2010-03-08 13:58:35 »

The buffer copying problem you allude to here was solved with DirectByteBuffers - this is why they are exclusively used instead of arrays or non-direct ByteBuffers in LWJGL. Does JNA not allow for this?

Cas Smiley

Offline gouessej
« Reply #187 - Posted 2010-03-08 14:41:26 »

The buffer copying problem you allude to here was solved with DirectByteBuffers - this is why they are exclusively used instead of arrays or non-direct ByteBuffers in LWJGL. Does JNA not allow for this?

Cas Smiley
JOGL doesn't accept indirect NIO buffers since 2007. JNA allows types derived from Buffer as Structure fields since June 2009.

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #188 - Posted 2010-03-08 15:02:22 »

So... there wouldn't necessarily be any overhead in sending/receiving data over JNA then, if it uses reused direct ByteBuffers?

Cas Smiley

Offline nsigma
« Reply #189 - Posted 2010-03-08 15:31:02 »

So... there wouldn't necessarily be any overhead in sending/receiving data over JNA then, if it uses reused direct ByteBuffers?

Exactly!  And it's been able to do this since before June 2009 - see for example  https://jna.dev.java.net/javadoc/com/sun/jna/Pointer.html, which you can view as a direct bytebuffer or read and write from directly.

The quote from Stack Overflow is just plain wrong!

Quote
The calling overhead for a single native call using JNA interface mapping can be an order of magnitude (~10X) greater time than equivalent custom JNI


Why this in bold?  This is talking about interface mapping as opposed to direct mapping.  See the following paragraph.

Quote
Solid performance? You're not precise enough on my view.

I agree, but I don't exactly have anything to benchmark it against!  Grin I'm not aware of another binding for GStreamer.  There is a binding for Jack using JNI but the API is quite different to mine, as JNAJack tries to keep as true to the Jack API as possible it has to make more calls across the java<>native boundary per buffer.  Even using the interface mapping you quoted above, rather than optimised to direct mapping, it's measuring a 1-2% extra CPU load (on that Celeron 800Mhz!).  I would suggest that low latency audio offers similar performance concerns to OpenGL/CL.

It would be interesting to see some comparisons of performance between JavaCL and JOCL.

Neil


Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #190 - Posted 2010-03-08 16:22:48 »

I would suggest that low latency audio offers similar performance concerns to OpenGL/CL.
You are comparing apples and carots.

It would be interesting to see some comparisons of performance between JavaCL and JOCL.
It will only show that GlueGen gives better performance than JNA.

Offline bienator

Senior Member




OutOfCoffeeException


« Reply #191 - Posted 2010-03-08 16:29:54 »

Why this in bold?  This is talking about interface mapping as opposed to direct mapping.  See the following paragraph.
well no its not. Interface mapping is far worse performing as JNA's direct mapping. Direct mapping for functions without params is almost exactly 10x slower as JNI and even worse if you add params. The average OpenCL function has via JNI around 50x less call overhead than direct mapped JNA. JavaCL has some optimizations in it but you simple can't match the performance of an compile-time JNI binding.

It would be interesting to see some comparisons of performance between JavaCL and JOCL.
+1 (in general, not necessarily related to the JNA vs JNI topic)

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #192 - Posted 2010-03-08 16:45:47 »

Anyway, who cares if there's 2 bindings to it? Competition is good Smiley

BTW, my current game is drawing about 4000 sprites per frame on average, which it does by issuing approximately 1,000 JNI calls or so. If, as I suspect, the overhad of JNI is about 100-300 nanoseconds depending on CPU, that'd be 100-300 microseconds of wasted CPU time for the entire scene. With JNA, if bienator is right, we'd be looking at 1-3 milliseconds, which is slightly more significant given that I've only got 17 milliseconds to play with in total.

Cas Smiley

Offline nsigma
« Reply #193 - Posted 2010-03-08 16:51:30 »

You are comparing apples and carots.

Probably a fair cop. Hoist by my own petard!  Grin

Interface mapping is far worse performing as JNA's direct mapping. Direct mapping for functions without params is almost exactly 10x slower as JNI and even worse if you add params.

The JNA site talks of a 2x-3x overhead for direct mapping.  I'm not disputing your figures, but interested to know where they come from.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #194 - Posted 2010-03-08 16:52:00 »

Anyway, who cares if there's 2 bindings to it? Competition is good Smiley
wrong, there are 3 bindings Wink but +1 for the competition part, having the freedom to choose a good thing

Offline gouessej
« Reply #195 - Posted 2010-03-09 14:51:11 »

Anyway, who cares if there's 2 bindings to it? Competition is good Smiley
Competition? I mainly see a waste of time in developing extremely similar APIs whereas it would be more efficient to concentrate development and maintenance efforts on a single one in my humble opinion.

Offline AI Guy

Senior Newbie





« Reply #196 - Posted 2010-03-09 16:25:14 »

Being in development of a commercial product using OpenCL, this about as far away from a waste of time as I can think of.  Guess it boils down to your perspective.

I would point out from an OpenCL perspective,  OpenCL IS NOT an API to be interfaced.  It is "C for the GPU".  Any host language is just OpenCL's bitch.   C is far an away the bitch of choice.  It has a natural advantage which will not be overcome easily.  Even C++, whose bindings are going to be officially part of the next release, is destined for the land of misfit hosts with Java, C#, Delphi, Python, and hell maybe even Cobol ;-)

What is interesting is in that just 6 mos of release, there is already a lunatic fringe out there doing experiments writing hybrid implementations of languages.  By that I mean that while technically there is a host language & OpenCL, the programmer cannot really tell.  There is a Scala implementation written on top of OpenCL4Java (sorry about that lunatic thing Olivier), as just one example.  That is why I encouraged experimenting with some OpenGL like thing, actually in OpenCL.

Any OpenCL system written with a monster # of host calls is probably in trouble anyway.  That's why that little contest is not about OpenCL.  Just using it.  Any visibility that gives to Java as a viable conventional host language is just icing on the cake.

Concentrating on OpenGL, while just keep an eye on OpenCL is probably the best option.
Offline aNt

Senior Member




AFK


« Reply #197 - Posted 2010-03-30 08:51:54 »

so we cleared up the jogl-lwjgl love then?
oh and opengl4 is out, could be open_es will be history soon.
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #198 - Posted 2010-03-30 10:45:33 »

ES has a lot of legs in it yet...

Cas Smiley

Offline aNt

Senior Member




AFK


« Reply #199 - Posted 2010-03-30 18:25:13 »

legs are good Grin
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 76
Projects: 15


★★★★★


« Reply #200 - Posted 2010-03-30 18:32:19 »

oh and opengl4 is out, could be open_es will be history soon.

Already implemented in LWJGL Smiley

ES is unlikely to disappear anytime soon, especially with opengl es 2.0 now becoming somewhat of standard on most mobile devices and being adopted as WebGL's minimum requirement.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #201 - Posted 2010-03-30 20:47:25 »

Since Khronos has actually got  their act together and is releasing ES and GL updates (like GL4.0) at regular intervals, Jogl is looking in an increasingly fractured and in a tenuous position. With Jogl 1.x feature frozen at GL3.0 with many outstanding bugs, and Jogl 2.x perpetually in homeless beta you'd have a hard time justifying picking Jogl for any serious project.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline whome

Junior Member




Carte Noir Java


« Reply #202 - Posted 2010-03-30 22:07:17 »

S With Jogl 1.x feature frozen at GL3.0 with many outstanding bugs, and Jogl 2.x perpetually in homeless beta you'd have a hard time justifying picking Jogl for any serious project.
Why is it LWJGL wrapper is able to follow bleeding edge OpenGL specs so fast. It does not have a massive budget or labour man hours. Is/Has always been JOGL just a homeless child within (ex)Sun?
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #203 - Posted 2010-03-30 22:11:30 »

 Grin

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #204 - Posted 2010-03-31 13:22:39 »

Why is it LWJGL wrapper is able to follow bleeding edge OpenGL specs so fast. It does not have a massive budget or labour man hours. Is/Has always been JOGL just a homeless child within (ex)Sun?

The funny thing is that often these things are the result of 'heroic' efforts made by individuals, and has little to do with the project or community. Every project needs its hero, and JOGL is the shining example of lacking one.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline gouessej
« Reply #205 - Posted 2010-03-31 17:51:00 »

Since Khronos has actually got  their act together and is releasing ES and GL updates (like GL4.0) at regular intervals, Jogl is looking in an increasingly fractured and in a tenuous position. With Jogl 1.x feature frozen at GL3.0 with many outstanding bugs, and Jogl 2.x perpetually in homeless beta you'd have a hard time justifying picking Jogl for any serious project.
Which bugs? It is not homeless, it is still used by many corporations. My own work (I'm an engineer) consists in using JOGL for a very serious project and I'm not alone to do the same choice. I work with an expert in 3D visualization and before meeting me, he did not even know JOGL has a competitor, he used JOGL for several serious projects too (pay-the-bills jobs as Renanse says).

Please stop FUD!

It has been very easy to convince my immediate superiors to use JOGL  Grin

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #206 - Posted 2010-03-31 18:26:27 »

I work with an expert in 3D visualization and before meeting me, he did not even know JOGL has a competitor
I don't wish to defame anyone but I am quite incredulous as to how someone claiming to be an expert in 3D visualisation (and presumably Java) hadn't heard of LWJGL. Just a little tiny bit of research turns it up.

Cas Smiley

Offline gouessej
« Reply #207 - Posted 2010-03-31 19:49:23 »

I don't wish to defame anyone but I am quite incredulous as to how someone claiming to be an expert in 3D visualisation (and presumably Java) hadn't heard of LWJGL. Just a little tiny bit of research turns it up.

Cas Smiley
Actually he is an expert in OpenGL and C/C++ not in Java otherwise he would do my job and I would not have been hired.

Edit.: lots of French small corporations use JOGL 2 like this one:
http://www.sculpteo.com/fr/gallery/create/geometry/

Michael, it would be fine to add a pointer to this site into the definitive website of JOGL.

Pages: 1 ... 5 6 [7]
  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.

atombrot (26 views)
2014-08-19 09:29:53

Tekkerue (24 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (14 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (60 views)
2014-08-11 02:49:23

BurntPizza (38 views)
2014-08-09 21:09:32

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!