JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20131116 05:05:54 (UTC)

20131116 05:05:54 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20131115050554.html
20131116 05:05:54 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20131116050554.html
20131116 06:46:59 * [Mike] (~Mike]@anon) Quit ()
20131116 06:57:53 * hharrison (~chatzilla@anon) has joined #jogamp
20131116 06:58:43 <hharrison> rmk0: segfault in glDrawElements perhaps?
20131116 06:59:49 <hharrison> we see that a _lot_ from the windows 7 Intel drivers
20131116 07:01:39 <hharrison> indexed drawing seems to be a huge problem for those drivers, we had to a a -safegraphics flag to flatten all the arrays due to driver bugs
20131116 07:02:29 <hharrison> Also, java 1.7 update 3 seems to have some weird compiler bug that also tends to tickle the intel drivers into segfaulting....watch out for that version
20131116 08:40:00 * xranby (~xranby@anon) Quit (Ping timeout: 245 seconds)
20131116 08:41:46 * xranby (~xranby@anon) has joined #jogamp
20131116 10:09:22 * Eclesia (~eclesia@anon) has joined #jogamp
20131116 10:09:31 <Eclesia> hi
20131116 10:14:40 * monsieur_max (~maxime@anon) has joined #jogamp
20131116 10:55:35 * monsieur_max (~maxime@anon) Quit (Ping timeout: 240 seconds)
20131116 11:11:35 * monsieur_max (~maxime@anon) has joined #jogamp
20131116 11:14:16 * monsieur_max (~maxime@anon) Quit (Client Quit)
20131116 11:14:41 * monsieur_max (~maxime@anon) has joined #jogamp
20131116 11:49:54 <rmk0> hharrison: ugh, right
20131116 11:50:19 <rmk0> this is on AMD, but it is indexed and does happen in a glDrawElements call
20131116 11:50:31 <rmk0> will try without indices if i can't track down the issues today
20131116 12:31:15 * hija (~hija@anon) has joined #jogamp
20131116 13:05:36 <rmk0> \o/
20131116 13:05:53 <rmk0> aggressively unbinding program attributes solved the crash
20131116 13:06:31 <sgothel> ha! :)
20131116 13:06:39 <rmk0> thanks for the pointers
20131116 13:07:01 <sgothel> so -> driver is not thread safe .. and mingles w/ data
20131116 13:07:24 <rmk0> i may've been in undefined behaviour territory, according to the spec
20131116 13:07:54 <sgothel> binding should persist between release/current cx
20131116 13:08:14 <sgothel> but well .. complicated data managment
20131116 13:08:28 <sgothel> hence more error prone if you track states .. bindings
20131116 13:09:02 <rmk0> something like: a = allocateArray(); bind(a); useProgram(p); vertexPointer(a); unbind(a); delete(a); drawElements();
20131116 13:09:36 <sgothel> my experience most cost sensitive ops: makeCurrent/release (NV ..), FBO 1st binding or re-attachments, .. rest should be cheap
20131116 13:09:48 <rmk0> right
20131116 13:10:20 <sgothel> I still have a hard time to understand rational of VAO ..
20131116 13:10:45 <rmk0> i understand the rationale... i don't think the implementation is good, though
20131116 13:10:52 <sgothel> it's even just a client state (not a share ctx resources, not in GL server) .. and still a requirement in core
20131116 13:10:53 <rmk0> seems like they obscure the management of this stuff even more
20131116 13:11:05 <sgothel> it was a 'convenience' for users ..
20131116 13:11:20 <sgothel> but it does _not_ reflect reality of the 'metal' driver
20131116 13:11:57 <rmk0> right
20131116 13:12:06 <rmk0> i've kept away from them
20131116 13:12:12 <sgothel> since core should only be on the metal - IMHO it's wrong to have it - especially - enforced
20131116 13:12:48 <sgothel> we had that bug report w/ VAO state tracking .. and the spec is undefined when unbinding a VAO and state of maybe bound VBOs while VAO setup
20131116 13:13:03 <rmk0> unpleasant
20131116 13:13:10 <sgothel> it's more academic .. i.e. mixture of VBO and CPU sourced data .. still
20131116 13:14:33 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=906 <- another JAWTWindow bug fixed .. (tracking of visibility state)
20131116 13:15:13 <sgothel> Completing Bug 903 now .. works good for X11, Windows (mouse/touch) .. OSX .. have to refine ENTER/EXIT semantics
20131116 13:15:31 <rmk0> nice
20131116 13:15:44 <sgothel> @Harvey: The I like to tackle Bug 893 and Bug 879 .. finally
20131116 13:16:46 <sgothel> After all that .. another RC .. allowing folks to test and report .. well :)
20131116 13:36:13 * bbbruce (~bx@anon) has joined #jogamp
20131116 13:44:42 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20131116 13:59:36 * xranby (~xranby@anon) Quit (Ping timeout: 252 seconds)
20131116 14:00:08 * xranby (~xranby@anon) has joined #jogamp
20131116 14:36:16 <rmk0> sgothel: i notice that the createOffscreenAutoDrawable method that took a GLContext argument is deprecated; i've switched to the one that doesn't take a GLContext but now the returned drawable returns null for getContext():
20131116 14:36:28 <rmk0> http://waste.io7m.com/2013/11/16/crash.txt
20131116 14:36:43 <rmk0> the first one worked but is deprecated, the second one "doesn't work"
20131116 14:37:41 <rmk0> this is with 2.1.3-rc-20131111
20131116 14:37:55 * rmk0 eyes javadoc
20131116 14:40:11 <rmk0> i'm not exactly sure what to do... there's no GLEventListener in this code, as it's simply a test suite
20131116 14:40:24 <rmk0> opens an offscreen drawable and executes opengl functions using it
20131116 14:40:29 <rmk0> then discards it
20131116 14:43:26 <sgothel> @Mark: Pls read the API doc!
20131116 14:43:45 <rmk0> have read it
20131116 14:44:01 <sgothel> so it's lazily created .. allowing to attach a shared ctx later on
20131116 14:44:21 <rmk0> except that there aren't any display() calls in this program, and i don't have a shared context...
20131116 14:44:26 <sgothel> either 'display' will create and validate the ctx .. or set it manually
20131116 14:44:39 <rmk0> i don't have a context to assign, i was relying on getting one from the offscreen drawable
20131116 14:44:46 <sgothel> then: create .. and call display() :)
20131116 14:44:58 <sgothel> it's an GLAutoDrawable
20131116 14:45:25 <sgothel> this way, it simply serves more use-cases, i.e. more flexible
20131116 14:45:51 <rmk0> hah, i see
20131116 14:46:00 <rmk0> it's... slightly weird, but fine!
20131116 14:46:15 <sgothel> welcome to my world :)
20131116 14:46:19 <rmk0> hehe
20131116 14:46:34 <sgothel> call tree .. shows you how I use it ..
20131116 15:14:16 * hija (~hija@anon) Quit (Quit: hija)
20131116 15:16:59 * hija (~hija@anon) has joined #jogamp
20131116 16:41:57 * monsieur_max (~maxime@anon) has joined #jogamp
20131116 17:53:59 * xranby (~xranby@anon) Quit (Ping timeout: 272 seconds)
20131116 18:02:34 * hija (~hija@anon) Quit (Quit: hija)
20131116 18:06:20 * xranby (~xranby@anon) has joined #jogamp
20131116 18:06:53 <Eclesia> question : I have a texture which is multisample.
20131116 18:07:07 <Eclesia> When i try to acces it with gl.glGetTexImage it fails
20131116 18:07:24 <Eclesia> as the doc says : http://www.opengl.org/sdk/docs/man/xhtml/glGetTexImage.xml
20131116 18:07:35 <Eclesia> multisample images are not possible with this method
20131116 18:07:50 <Eclesia> so how can I grab my texture ?
20131116 18:22:54 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20131116 19:44:33 <Eclesia> hm seems like rendering to another teture is the only way, and use a sampler2DMS in the fragment shader
20131116 19:56:01 * xranby (~xranby@anon) Quit (Ping timeout: 245 seconds)
20131116 20:10:21 * xranby (~xranby@anon) has joined #jogamp
20131116 20:29:27 <Eclesia> F...K those nightmare GL exceptions.
20131116 20:29:29 <Eclesia> Exception in thread "Thread-2-FPSAWTAnimator-Timer0" java.lang.RuntimeException: GL_INVALID_OPERATION : The specified operation is not allowed in the current state. The offending command is ignored and has no other side effect than to set the error flag.
20131116 20:29:42 <Eclesia> can't they say was is wrong ???
20131116 20:29:46 <Eclesia> what*
20131116 20:31:22 <rmk0> Eclesia: d'you know which function caused it?
20131116 20:31:51 <Eclesia> gl.glBindTexture(GL4.GL_TEXTURE_2D_MULTISAMPLE, texId);
20131116 20:32:01 <rmk0> ugh
20131116 20:32:56 <Eclesia> texId is ok, texture is activate.
20131116 20:33:09 <Eclesia> what the hell is wrong ?!
20131116 20:33:16 <rmk0> is texId definitely of type GL_TEXTURE_2D_MULTISAMPLE?
20131116 20:33:40 <Eclesia> 100% sure, checked it at least 3 times already
20131116 20:34:18 <rmk0> what hardware is this?
20131116 20:34:27 <Eclesia> nvidia gtx 460
20131116 20:35:03 <rmk0> tried with "-Djogl.debug.DebugGL=all" ?
20131116 20:35:39 <rmk0> it'll open a debug context that might give you more output than the ordinary context would
20131116 20:36:09 <Eclesia> GLDebugEvent[ id 0x502
20131116 20:36:09 <Eclesia> type Error
20131116 20:36:09 <Eclesia> severity High: dangerous undefined behavior
20131116 20:36:09 <Eclesia> source GL API
20131116 20:36:09 <Eclesia> msg GL_INVALID_OPERATION error generated. Target doesn't match the texture's target.
20131116 20:36:10 <Eclesia> when 1384634140079
20131116 20:36:10 <Eclesia> source 4.2 (Compat profile, arb, debug, ES2 compat, FBO, hardware) - 4.2.0 NVIDIA 304.88 - hash 0x41c0dc00]
20131116 20:36:28 <Eclesia> target doesn't match ?
20131116 20:39:48 <Eclesia> I think more and more about making a virtual GPU for debugging ...
20131116 20:40:18 <rmk0> i assume you specified the texture image with glTexImage2DMultisample
20131116 20:40:24 <Eclesia> yes
20131116 20:40:36 <rmk0> i'm at a loss
20131116 20:40:45 <rmk0> any other hardware to test on?
20131116 20:41:15 <Eclesia> it's the first time I try to use a shared context, so it might be the cause
20131116 20:41:46 <Eclesia> is that correct :
20131116 20:41:48 <Eclesia> final GLProfile glp = gl.getGLProfile();
20131116 20:41:48 <Eclesia> final GLCapabilities caps = new GLCapabilities(glp);
20131116 20:41:48 <Eclesia> final GLAutoDrawable sharedDrawable = GLDrawableFactory.getFactory(glp)
20131116 20:41:48 <Eclesia> .createOffscreenAutoDrawable(null, caps, null, width, height);
20131116 20:41:55 <Eclesia> ?
20131116 20:42:02 <rmk0> looks right to me
20131116 20:43:01 <Eclesia> it's glActiveTexture also for multisampel textures ?
20131116 20:43:54 <rmk0> yeah, as far as i know
20131116 20:45:05 <Eclesia> using GL_TEXTURE0 as id is coorect to ?
20131116 20:45:10 <Eclesia> correct*
20131116 20:45:33 <rmk0> yep
20131116 20:46:58 <Eclesia> texture was generate with a different GL, it should work with the shared context right ?
20131116 20:47:52 <Eclesia> is there some way to 'check' my texture ?
20131116 20:49:34 <rmk0> i don't think there's any way to check the one thing you want to check... the "target"
20131116 20:50:02 <rmk0> can obviously retrieve all of the texture parameters with glGetTexParameter
20131116 20:50:31 <rmk0> i'm not entirely sure on the rules with shared contexts
20131116 20:50:47 <rmk0> you "should" be able to share textures freely, but i'm sure there are evil side conditions
20131116 20:51:06 <Eclesia> okay, so I'll try to do witohout the shared context.
20131116 20:51:26 <Eclesia> you know how I could grab back the GLAutoDrawable from a GL object ?
20131116 20:52:07 <Eclesia> gl.getProfile().getGLDrawable/getGLReadDrawable are not instanceof of GLAutoDrawable
20131116 20:53:11 <Eclesia> hm no that would even work. another gllistener is already attached
20131116 20:53:13 <rmk0> don't think you can
20131116 20:53:15 <Eclesia> would not*
20131116 20:54:16 * Eclesia starting to get desperate after 3hours trying to use multisampling
20131116 20:54:48 <rmk0> that's certainly opengl
20131116 20:54:57 <rmk0> things that should take an hour end up taking ten times that
20131116 20:54:59 <rmk0> error-prone API
20131116 20:55:01 * Eclesia is going to buy a ticket for USA and go kick nvidia developers asses
20131116 21:06:23 <Eclesia> why do I start to think oracle,liferay,flamingo,jai and many many other projects developers are just newbies ?
20131116 21:07:01 <Eclesia> eating big mac and drinking coca cola is starting have a nasty effect an QI...
20131116 21:07:03 <Eclesia> on*
20131116 21:07:39 * Eclesia in flamewar mode
20131116 21:19:45 * xranby (~xranby@anon) Quit (Read error: Operation timed out)
20131116 21:21:26 * xranby (~xranby@anon) has joined #jogamp
20131116 21:41:29 * void256 (~void@anon) has joined #jogamp
20131116 22:28:54 * hija (~hija@anon) has joined #jogamp
20131116 22:35:31 <Eclesia> ha finally working, no errors. but I have a black image :(
20131116 23:05:35 <Eclesia> ok multisampling works, know only remain a usual memory leak.
20131116 23:05:46 <Eclesia> good night all ++
20131116 23:05:52 <Eclesia> rmk0: thanks for the help
20131116 23:06:06 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20131117 00:56:48 * void256 (~void@anon) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018])
20131117 01:56:56 <hharrison> sgothel: thanks for persisting with those bugs
20131117 02:15:28 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=879#c6
20131117 02:15:39 <sgothel> if working .. probably the best solution ?
20131117 02:16:10 <sgothel> also note: the now removed lines already did contain a note about the reported freeze ..
20131117 02:16:34 <hharrison> looking...
20131117 02:16:38 <sgothel> @Harvey: thx .. maybe you can double check w/ you application, since .. great!
20131117 02:16:52 <sgothel> this will also fix Bug 892 :)
20131117 02:17:33 <hharrison> Won't be back to the machines in question until Monday, but for sure will check it out
20131117 02:18:15 <sgothel> another one in line 244 ..
20131117 02:19:31 <sgothel> have to make sure those focus traversal are perf. on AWT ..
20131117 02:22:44 <hharrison> Sure, if you push out a test branch/commit, just shoot me a commit to test
20131117 02:24:42 <sgothel> I have Win 8.1 here .. but no way to test the freeze right ?
20131117 02:24:55 <sgothel> (for me)
20131117 02:25:17 <sgothel> yes .. will produce another RC for Monday for sure
20131117 02:25:41 <hharrison> we're equipped to do builds of jogl now, so a raw commit is fine for testing
20131117 02:26:53 <hharrison> https://github.com/AusencoSimulation/JaamSim
20131117 02:26:55 <hharrison> ;-)
20131117 02:27:10 <sgothel> oh .. recipe ?
20131117 02:27:23 <hharrison> build everything in the src/ folder
20131117 02:27:24 <sgothel> *big test case* :)
20131117 02:27:38 <hharrison> GUIFrame has the main()
20131117 02:27:48 <hharrison> jogl2 is the only dependency
20131117 02:28:25 <hharrison> Yeah, not totally serious about that
20131117 02:29:34 <sgothel> Compilation finished successfully
20131117 02:29:35 <sgothel> JAR file created:JaamSim.jar
20131117 02:29:45 <hharrison> there's a build.sh right at the root of the tree you can run with no args to build it (assumes the jogl2 jars in the jar/ folder)
20131117 02:30:15 <sgothel> tsts windows only :)
20131117 02:30:25 <hharrison> _sigh_
20131117 02:30:46 <hharrison> I know....working on it.
20131117 02:31:45 <hharrison> It's recently gotten back as a priority as we're finally getting some external users
20131117 02:32:18 <sgothel> java -jar JaamSim.jar
20131117 02:32:18 <sgothel> Error: Could not find or load main class com.sandwell.JavaSimulation3D.GUIFrame
20131117 02:32:57 <hharrison> sigh, obviously I've done something stupid
20131117 02:33:11 <sgothel> only 'resources' are included in jar ..
20131117 02:33:17 <sgothel> build w/ build.sh ..
20131117 02:34:00 <sgothel> jogl not found .. in javac cp
20131117 02:34:37 <sgothel> CLASSPATH="-classpath jar/;jar/*" <- windows :)
20131117 02:35:16 <sgothel> ; -> :
20131117 02:35:37 <sgothel> The forefront .. :)
20131117 02:35:42 <hharrison> Obviously I haven't built this at home in awhile, just got the same build failure
20131117 02:36:09 <hharrison> Thanks for the shaming, now I _have_ to fix this right now
20131117 02:36:20 <sgothel> java.lang.NoClassDefFoundError: com/jogamp/newt/event/KeyListener .. hmm
20131117 02:36:41 <sgothel> ah .. jar doesn't ref jogl .. sure
20131117 02:37:57 <sgothel> java -classpath jar/gluegen-rt.jar:jar/jogl-all.jar:JaamSim.jar com.sandwell.JavaSimulation3D.GUIFrame
20131117 02:38:10 <sgothel> lots of stuff popped up
20131117 02:38:28 <sgothel> (on linux now .. obviously)
20131117 02:38:36 <sgothel> recipe to reproduce the freeze ?:
20131117 02:38:41 <hharrison> 'Model Builder' window -> drag a DisplayEntity to the main window
20131117 02:38:46 <hharrison> You should see a cube appear
20131117 02:39:11 <hharrison> repeatedly right-click on the cube, chould bring up a pop-up
20131117 02:39:48 <hharrison> keep right clicking on the cube, the focus jumps back and forth between 3d window and popup, which fairly quickly caused the lockup for us
20131117 02:40:04 <sgothel> java.net.MalformedURLException: no protocol: /resources/shapes/cube.dae/
20131117 02:40:04 <sgothel> at java.net.URL.<init>(Unknown Source)
20131117 02:40:06 <sgothel> hmm
20131117 02:40:23 <sgothel> rel path of jar maybe
20131117 02:40:59 <hharrison> OK, obvisouly I've let things get away from me on non-windows, will go get this back to a running state
20131117 02:43:14 <hharrison> do you get the XYZ axis 3d-stuff?
20131117 02:43:38 <hharrison> (just seeing how badly I've stuffed things up)
20131117 02:44:11 <sgothel> added "file:"+
20131117 02:44:19 <sgothel> to RenderUtils new URL(
20131117 02:44:34 <sgothel> now I have a View-1
20131117 02:45:01 <sgothel> no axis
20131117 02:45:14 <sgothel> Model Builder *click* -> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
20131117 02:45:14 <sgothel> at com.jaamsim.controllers.RenderManager.getMeshBounds(RenderManager.java:1451)
20131117 02:45:14 <sgothel> at com.jaamsim.render.PreviewCache.getPreview(PreviewCache.java:128)
20131117 02:45:32 <hharrison> We have this legacy FileEntity crap from years back that we're finally getting rid of, likely our halfway state right now is broken
20131117 02:46:12 <hharrison> Sorry for the time-waster
20131117 02:46:19 <sgothel> np .. one more test on windows ..
20131117 02:47:50 <hharrison> dog needs out..back shortly
20131117 02:56:09 * [Mike] (~Mike]@anon) has joined #jogamp
20131117 03:00:10 <sgothel> @@ -487,7 +487,7 @@ static void putPointXYZW(FloatBuffer fb, Vec4d v) {
20131117 03:00:10 <sgothel>
20131117 03:00:10 <sgothel> public static MeshProtoKey FileNameToMeshProtoKey(String filename) {
20131117 03:00:10 <sgothel> try {
20131117 03:00:10 <sgothel> - URL meshURL = new URL(Util.getAbsoluteFilePath(filename));
20131117 03:00:10 <sgothel> + URL meshURL = new URL("file:"+Util.getAbsoluteFilePath(filename));
20131117 03:00:10 <sgothel>
20131117 03:00:11 <sgothel> String ext = filename.substring(filename.length() - 4,
20131117 03:00:11 <sgothel> filename.length());
20131117 03:01:01 <hharrison> getAbsolutePath....that's the part I'm trying to kill, sorry you saw that
20131117 03:01:25 <hharrison> There's....history there
20131117 03:02:44 <sgothel> GlueGen's IOUtil has some funcs for this :)
20131117 03:03:16 <sgothel> on windows (w/o my hack) works ..
20131117 03:03:18 <sgothel> goody
20131117 03:03:35 <sgothel> how to make it freeze ?
20131117 03:03:46 <sgothel> (quite a quick dog :)
20131117 03:04:31 <hharrison> drag a 'DisplayEntity' from the model builder to the 3d view
20131117 03:04:36 <hharrison> you should see a cube
20131117 03:04:58 <sgothel> (03:39:11 AM) hharrison: repeatedly right-click on the cube, chould bring up a pop-up
20131117 03:04:58 <sgothel> (03:39:48 AM) hharrison: keep right clicking on the cube, the focus jumps back and forth between 3d window and popup, which fairly quickly caused the lockup for us
20131117 03:05:09 <hharrison> yep
20131117 03:05:27 <sgothel> I should now test w/o my new patch :)
20131117 03:05:36 <sgothel> no jumpy focus here ..
20131117 03:06:17 <hharrison> if you right-click on the menu item itself, it should then focus on one of the other windows, then when you right click on the cube again...need to spam the right click a bit
20131117 03:06:43 <hharrison> Win7, win8 it was fairly quick for us...< 5-6s of clicking
20131117 03:07:20 <hharrison> some people saw it just left-click back and forth between the 3d view and the output viewer window
20131117 03:07:49 <hharrison> but that seemed to be a little harder to hit
20131117 03:08:07 <sgothel> awesome .. reproduced
20131117 03:08:12 <sgothel> (w/ your orig jars)
20131117 03:08:23 <hharrison> yay! I'm not just seeing things!
20131117 03:08:48 <hharrison> win8?
20131117 03:09:03 <sgothel> win7
20131117 03:09:43 <hharrison> if you try with baseline 2.1.2, it was even faster
20131117 03:31:32 <sgothel> I also get another freeze .. NewtCanvasAWT.windowGainedFocus -> clearSelectionPath .. Window.dispose .. NEWT-EDT waits for AWT-EDT
20131117 03:32:09 <sgothel> b/c we originate from AWT-EDT
20131117 03:36:09 <hharrison> hmm, haven't captured that one before, everytime I've dumped stack it's always been keyboardfocus
20131117 03:37:50 <sgothel> will tackle the AWT methods in NewtCanvasAWT .. i.e. run on AWT-EDT later ..
20131117 03:48:00 <sgothel> great .. gone
20131117 03:48:23 <sgothel> clicked alot on win7 and 8.1
20131117 03:48:57 <hharrison> music to my ears, I'll def. get this into production on Monday
20131117 04:00:18 <sgothel> sweet .. so the 'focus hopping' is gone as well now ..
20131117 04:54:22 <hharrison> very sweet
20131117 05:00:45 <sgothel> heading to bed .. good night & laters
20131117 05:05:54 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20131117050554.html