#jogamp @ irc.freenode.net - 20151205 05:06:07 (UTC)
20151205 05:06:07 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20151204050607.html
20151205 05:06:07 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20151205050607.html
20151205 10:54:41 * badshah400 (~badshah40@anon) has joined #jogamp
20151205 11:15:41 * monsieur_max (~maxime@anon) has joined #jogamp
20151205 12:22:59 * badshah400 (~badshah40@anon) Quit (Ping timeout: 264 seconds)
20151205 13:45:45 * Eclesia (~eclesia@anon) has joined #jogamp
20151205 13:45:59 <Eclesia> hi
20151205 14:29:26 <rmk0> sgothel: i can't find anything in the opengl spec that says anything about the rules for the creation/destruction of drawables with relation to contexts
20151205 14:30:26 <rmk0> are the rules documented anywhere? am constantly running into "NativeWindowException: didn't release surface Handle" errors
20151205 14:30:35 <rmk0> just on this one windows 7 setup
20151205 14:32:23 <rmk0> it seems as though i can screw things up by doing:
20151205 14:32:29 <rmk0> ca.makeCurrent();
20151205 14:32:33 <rmk0> cb.makeCurrent();
20151205 14:32:38 <rmk0> where ca and cb are shared contexts
20151205 14:32:53 <rmk0> it seems as though they become impossible to destroy if ca isn't released prior to making cb current
20151205 14:33:11 <rmk0> it doesn't matter if they're both released afterwards
20151205 14:33:21 <rmk0> will see if i can produce a test case
20151205 14:52:43 <rmk0> is it possible to determine if a given GLContext is current on *any* thread, not just the current one?
20151205 14:59:13 <rmk0> ... that's a no
20151205 15:17:45 * badshah400 (~badshah40@anon) has joined #jogamp
20151205 15:45:05 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20151205 17:42:11 * badshah400 (~badshah40@anon) Quit (Ping timeout: 264 seconds)
20151205 17:42:28 <sgothel> Hi Mark ..
20151205 17:42:35 <rmk0> ello
20151205 17:42:50 * rmk0 stomps on AMD drivers
20151205 17:42:55 <sgothel> conceptually, one cannot really ask whether a lock is being hold, since you may be always too late
20151205 17:43:28 <sgothel> i.e. the result of such query won't reflect the 'current' state, since the lock might be gone/taken afterwards
20151205 17:43:43 <sgothel> however, you can query it via GLContextImpl AFAIK
20151205 17:44:26 <sgothel> if the spec is not mentioning anything about the onscreen framebuffer .. it might be b/c it is outside of the spec .. i.e. GLX/WGL/..
20151205 17:44:39 <rmk0> good point
20151205 17:44:49 <sgothel> IMHO the FBO or other buffers mentioned in the spec shall apply
20151205 17:45:13 <sgothel> naturally I still would say, don't destroy assigned resources while being in use .. the safe side
20151205 17:45:24 <rmk0> yeah
20151205 17:45:34 <rmk0> mesa happily allows it... this elderly catalyst doesn't
20151205 17:45:56 <sgothel> if the spec mentions deferred deletion explicit .. one may try to use it, still drivers may behave differently
20151205 17:46:01 <sgothel> yup
20151205 17:46:28 <sgothel> IMHO Mesa3D uses deferred deletion, i.e. keep it alive until things get released for real
20151205 17:47:19 <sgothel> due to this fact .. or issue, I have created this shared context lifecycle helper ..
20151205 17:47:33 <sgothel> http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLSharedContextSetter.html
20151205 17:48:03 <sgothel> i.e. it works in conjunction w/ the underlying drawable (-> GLX/WGL .. or FBO) ..
20151205 17:48:06 * rmk0 eyes it
20151205 17:48:38 <sgothel> and the context is only allowed to become current when the resource gets available and related master context is realized ..
20151205 17:48:54 <sgothel> the spec does _not_ mention this at all .. i.e. is fuzzy about it
20151205 17:49:27 <sgothel> so our use cases w/ shared context and the one in our GLMediaPlayer uses this 'safe concept' of tracking lifecycles
20151205 17:50:55 <rmk0> i was unable to decipher the GLMediaPlayer implementation
20151205 17:50:59 <rmk0> it seems fairly hairy
20151205 17:51:09 <rmk0> i understand it's supposed to be a circular buffer of textures
20151205 17:51:16 <sgothel> yes
20151205 17:51:44 <sgothel> we assume the users context is alive at 'start' .. and we can create the shared context
20151205 17:52:16 <sgothel> the ringbuffer allows implicit synchronization of the threads, put and get
20151205 17:52:26 <sgothel> so no issue here
20151205 17:52:54 <sgothel> the GL spec does not mention whether sync/locking is required .. it is undefined
20151205 17:53:16 <sgothel> so for a stable application I would recommend to have an application level sync .. like the ringbuffer
20151205 17:53:58 <rmk0> oh absolutely
20151205 17:54:04 <sgothel> you can see all the unit tests using the GLSharedContextSetter via call-tree within an IDE
20151205 17:54:16 <rmk0> the issue i was trying to fix was this immortal behaviour of contexts on this driver
20151205 17:54:48 <rmk0> it turns out that if you try to make a context current on a thread without first releasing any current context... they both become undestroyable forever
20151205 17:54:59 <rmk0> amusing bug
20151205 17:58:59 * sgothel (~sgothel@anon) Quit (Ping timeout: 264 seconds)
20151205 17:59:43 <rmk0> didn't think it was quite that amusing
20151205 17:59:48 * sgothel (~sgothel@anon) has joined #jogamp
20151205 17:59:49 * sgothel (~sgothel@anon) Quit (Changing host)
20151205 17:59:49 * sgothel (~sgothel@anon) has joined #jogamp
20151205 17:59:49 * ChanServ sets mode +v sgothel
20151205 18:33:43 * badshah400 (~badshah40@anon) has joined #jogamp
20151205 20:54:48 * badshah400 (~badshah40@anon) Quit (Read error: Connection reset by peer)
20151205 20:55:03 * badshah400 (~badshah40@anon) has joined #jogamp
20151205 21:58:55 * badshah400 (~badshah40@anon) Quit (Quit: badshah400)
20151205 22:00:10 * badshah400 (~badshah40@anon) has joined #jogamp
20151205 22:39:49 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20151206 02:38:40 * badshah400 (~badshah40@anon) Quit (Quit: badshah400)
20151206 05:06:08 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20151206050608.html