JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20150218 05:05:32 (UTC)

20150218 05:05:32 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20150217050532.html
20150218 05:05:32 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20150218050532.html
20150218 07:24:25 * monsieur_max (~maxime@anon) has joined #jogamp
20150218 07:44:08 * jvanek (jvanek@anon) has joined #jogamp
20150218 08:59:13 * sgothel (~sgothel@anon) Quit (Ping timeout: 264 seconds)
20150218 09:00:18 * sgothel (~sgothel@anon) has joined #jogamp
20150218 09:00:18 * sgothel (~sgothel@anon) Quit (Changing host)
20150218 09:00:18 * sgothel (~sgothel@anon) has joined #jogamp
20150218 09:00:18 * ChanServ sets mode +v sgothel
20150218 12:23:26 * eclesia (~husky@anon) has joined #jogamp
20150218 12:23:30 <eclesia> hi
20150218 12:24:04 <eclesia> I have this odd error on a ATI FireGL card : Exception in thread "Thread-2-FPSAWTAnimator#00-Timer0" com.jogamp.opengl.util.AnimatorBase$UncaughtAnimatorException: com.jogamp.opengl.GLException: Caught ShaderException: Geometry shader failed to compile with the following errors:
20150218 12:24:04 <eclesia> ERROR: 0:2: error(#201) Requires extension support: instanced geometry shader (GL_ARB_gpu_shader5)
20150218 12:24:04 <eclesia> ERROR: error(#273) 1 compilation errors. No code generated
20150218 12:24:40 <eclesia> the card support GL4. yet he complains about a missing geometry shader extension
20150218 12:25:36 <eclesia> any idea ?
20150218 12:25:53 <eclesia> or am I using something really new here in my shader : http://pastebin.com/vZY8K3f9 ?
20150218 12:25:54 <zubzub> glprofile thingy?
20150218 12:26:02 <zubzub> wrong gl version?
20150218 12:26:42 <eclesia> hm... trying...
20150218 12:28:59 <eclesia> no difference GL4 or default profile.
20150218 12:33:38 <eclesia> ok found
20150218 12:34:05 <eclesia> the #330 on another shader, should have been #400
20150218 12:43:35 <sgothel> Hi .. Eclesia .. good that you found it.
20150218 12:43:44 <eclesia> sgothel: hi
20150218 12:44:15 <sgothel> you know that we edit the shader code at runtime according to the running profile, so it always matches?
20150218 12:44:41 <sgothel> I mentioned it in one forum post .. dunno how you make it fit, but sure you do
20150218 12:44:54 <eclesia> sgothel: you know I'm not using those classes in my project ^^
20150218 12:45:15 <sgothel> hence: 'sure you do' .. with your code .. I assume
20150218 12:45:36 <sgothel> not advertising our code, just emphasizing the need for the fact :)
20150218 12:46:13 <sgothel> so Mantle == OpenGL 5 == glNext or so ?
20150218 12:49:11 <eclesia> question is for me ?
20150218 12:49:29 <sgothel> for you as well, sure .. everybody :)
20150218 12:50:02 * eclesia don't know. doing less opengl this days ... a few troubles at work...
20150218 12:50:55 <sgothel> sorry to hear .. wish you good luck w/ it
20150218 12:51:21 <eclesia> it's not me the problem, more the company
20150218 12:51:39 <sgothel> I assumed that .. ofc
20150218 12:51:42 <zubzub> mantle = amd
20150218 12:51:47 <zubzub> glnext = valve
20150218 12:51:56 <zubzub> opengl = kronos
20150218 12:52:06 <zubzub> glnext ~= opengl5?
20150218 12:52:13 <sgothel> amd/mantle: take what you want to Khronos/Valve, which work on glNext
20150218 12:53:10 <sgothel> well, at least it would be something like 'direct state + core' at least :)
20150218 12:53:16 <zubzub> yeah
20150218 12:53:30 <zubzub> from what I see they all try to do the same thing with mantle &glnext
20150218 12:53:55 <sgothel> so the new core profile it is :)
20150218 12:54:11 <zubzub> http://techreport.com/news/26922/amd-hopes-to-put-a-little-mantle-in-opengl-next
20150218 12:57:30 <zubzub> http://www.reddit.com/r/opengl/comments/2l5mk3/glnext/
20150218 12:58:13 <zubzub> looks like opengl5 == glnext
20150218 13:02:47 <eclesia> what is so great about the new opengl ?
20150218 13:03:15 <sgothel> the new core ..
20150218 13:03:36 <sgothel> i.e. when they started gl3-core profile .. it had the same intention
20150218 13:03:48 <sgothel> but backward compat broke its neck .. and still too fatty
20150218 13:04:06 <eclesia> gl5 is simplified then ?
20150218 13:04:09 <sgothel> so .. glNext shall be the new core .. no need for backward compat .. and less state stuff
20150218 13:04:10 <zubzub> yes
20150218 13:04:24 <zubzub> simpler, more low level, more control
20150218 13:04:47 <sgothel> less code to test for driver devs .. etc
20150218 13:05:11 <sgothel> so it could happen that you won't find anything graphic in it :)
20150218 13:05:19 <sgothel> in theory .. the nuclear option :)
20150218 13:05:34 <sgothel> i.e. only memory management .. and gpu-programs
20150218 13:05:43 <sgothel> but I doubt they go that far ..
20150218 13:05:53 <eclesia> so gl5 ~= OpenCL /ComputeShader
20150218 13:06:16 <sgothel> that would be possible and it was discussed at khronos
20150218 13:06:28 <sgothel> i.e. they developed their test gles driver w/ opencl
20150218 13:06:57 <sgothel> that was a few years ago .. 2006 or so .. but I have no more khronos access
20150218 13:07:29 <sgothel> problem here are low level devices .. still having hard wired stuff
20150218 13:07:53 <sgothel> i.e. graphics semantics in silicon
20150218 13:08:31 <eclesia> that's why it's a Graphic Processing Unit and not a CPU.
20150218 13:08:39 <sgothel> haha
20150218 13:09:00 <eclesia> it's will change from GPU to SPU (Scalar)
20150218 13:09:02 <sgothel> na .. its about graphics semantics in stream processing .. SMMD etc
20150218 13:09:11 <sgothel> SIMD .. yup
20150218 13:09:44 <sgothel> I hope they will offer more command prefetches .. etc so branches won't frees the pipeline, for processing
20150218 13:10:09 <sgothel> SIMD vs MIMD
20150218 13:10:43 <sgothel> [Single | Multiple] Instruction Multiple Data
20150218 13:16:05 * rmk0 eyes zubzub
20150218 13:17:45 <rmk0> may have a question about Guava futures, but i'm trying to phrase it in a way that isn't bewildering
20150218 13:19:10 <sgothel> sweet .. yes, take a deep breath :)
20150218 13:19:28 <zubzub> speak my child
20150218 13:19:43 <zubzub> just explain what you are trying to do
20150218 13:19:47 <rmk0> hehe
20150218 13:19:58 <zubzub> guava futures are actually pretty simple
20150218 13:20:03 <zubzub> once you grasp the concept
20150218 13:20:13 <zubzub> imho much simpler than completable future
20150218 13:20:22 <rmk0> so i'm working with java.xml.parsers.DocumentBuilder.parse(InputStream)
20150218 13:20:30 <rmk0> it consumes an input stream and returns a document
20150218 13:20:35 <zubzub> oh xml, I'm out
20150218 13:20:36 <zubzub> bye
20150218 13:20:36 <zubzub> :p
20150218 13:20:39 <rmk0> \o/
20150218 13:20:46 <monsieur_max> haha :)
20150218 13:20:47 <zubzub> j/k
20150218 13:21:04 <rmk0> the inputstream may've come from anywhere, likely a slow http connection
20150218 13:21:48 <rmk0> i'm trying to construct an interface that takes a URI, returns a ListenableFuture<Document> such that when cancelling the future, the parser stops reading from the stream
20150218 13:22:36 <rmk0> this would be fine if the stream itself could observe the state of the future... just have read() raise InterruptedIOException when it sees that the future has been cancelled
20150218 13:22:41 <zubzub> the only way to forcebly stop a thread from doing it's thing in java is with Thread.stop()
20150218 13:22:57 <rmk0> i don't want to stop the thread, exactly
20150218 13:23:22 <zubzub> afaik that requires you to modify the documentbuilder code
20150218 13:23:31 <zubzub> because there read() is called
20150218 13:23:51 <rmk0> i feel like i could achieve this by wrapping the stream in a custom InputStream that can be cancelled
20150218 13:23:59 <zubzub> yes
20150218 13:24:01 <zubzub> also a good way
20150218 13:24:01 <rmk0> the problem is that i can't observe the state of the future from the stream...
20150218 13:24:05 <sgothel> buffered-read w/ thread-sync .. sounds like? ringbuffer maybe for non-blocked operation?
20150218 13:24:25 <sgothel> using that for the media player .. GlueGen has a non blocking ringbuffer
20150218 13:24:34 <rmk0> when the stream is created, the future doesn't exist yet, because the executors only consume Runnables or Callables
20150218 13:25:08 <zubzub> rmk0: have the input stream check Thread.isInterrupted()
20150218 13:25:28 <zubzub> iirc there's future.cancel(interrupte boolean) or something
20150218 13:25:56 * doev (~doev@anon) has joined #jogamp
20150218 13:25:58 <rmk0> i don't think that'll work here as i'm working with a fixed pool of 2-4 threads... there isn't a 1:1 mapping between threads and futures
20150218 13:26:20 <zubzub> afaik that will make the future set the interrupt on the thread that is running it(?)
20150218 13:26:35 <zubzub> (because otherwise the interrupt boolean wouldnt make much sense)
20150218 13:27:05 <zubzub> normally your pool should replace any thread that dies
20150218 13:27:05 * rmk0 eyes everything
20150218 13:28:43 <zubzub> http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html#cancel(boolean)
20150218 13:29:05 <zubzub> Parameters:
20150218 13:29:06 <zubzub> mayInterruptIfRunning - true if the thread executing this task should be interrupted; otherwise, in-progress tasks are allowed to complete
20150218 13:29:30 <rmk0> will attempt it, thanks
20150218 13:29:34 <zubzub> http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupted()
20150218 13:30:27 <rmk0> guava provides an AbstractFuture, but it doesn't seem like i can implement an AbstractFuture and then pass it to an executor for evaluation
20150218 13:30:36 <rmk0> guessing it's not really intended for that
20150218 13:31:00 <rmk0> that would solve the problem as then i could observe the state of the future from inside the computation
20150218 13:31:35 <zubzub> you should seperate threading from business logic
20150218 13:31:47 <zubzub> or whatever logic
20150218 13:32:16 <zubzub> logic should preferable not be aware of threading
20150218 13:32:24 <zubzub> unless you really don't have a choice
20150218 13:33:02 <rmk0> that's how this was written, it's just the issue of not being able to stop code once it's started performing a blocking read loop on an inputstream (at least without interuppting the thread and hoping the code doesn't ignore that exception)
20150218 13:33:04 <zubzub> that way you don't have to mangle locking/synchronization with unrelated code
20150218 13:34:01 <zubzub> if your thread is blocking on a read, then you should be able to interrupt it
20150218 13:34:08 <sgothel> so you cannot wrap the input stream into a ringbuffered non-blocking input stream fed by another thread, which consumes some signals?
20150218 13:34:33 <zubzub> sounds more complex than required(?)
20150218 13:34:53 <zubzub> just have the read loop in the documentbuilder check for interrupts
20150218 13:35:19 <rmk0> i don't control the code that consumes the stream, to be clear
20150218 13:35:21 <rmk0> i can't modify it
20150218 13:35:21 <sgothel> (disclaimer: I don't know Guava and all those internals .. so I am out I guess :)
20150218 13:35:40 <zubzub> guava just gives you a callback mechnism for future
20150218 13:35:41 <zubzub> that's not
20150218 13:35:46 <zubzub> *thats it
20150218 13:36:02 <zubzub> the cancelation thingies are just plain old jdk java
20150218 13:36:30 <zubzub> if you can modify the inputstrea, then have calls to read check the Thread interrupt flag
20150218 13:37:09 <rmk0> currently trying that
20150218 13:37:42 <zubzub> the thing is that you cant stop a thread as long as it:
20150218 13:37:58 <zubzub> a) doesnt block with an interruptable blocking way
20150218 13:38:22 <zubzub> b) doesnt block and doesnt check the Thread.interrupt flag
20150218 13:38:56 <zubzub> you can however
20150218 13:39:06 <zubzub> get the Thread object and call stop()
20150218 13:39:20 <zubzub> whill will make the running thread throw an exception
20150218 13:39:22 <zubzub> *error
20150218 13:39:43 <zubzub> however that is deprecated because code that runs inside the thread can catch it
20150218 13:40:12 <zubzub> as long as you dont do that Thread.stop() is safe and will always work
20150218 13:40:27 <zubzub> *if* you can get to the thread object that is
20150218 13:40:48 <zubzub> and executor pools are designed just to avoid you having to deal with thread objects
20150218 13:46:09 <rmk0> http://waste.io7m.com/2015/02/18/TestUntyped.java
20150218 13:46:24 <rmk0> that's a severely reduced example of the problem
20150218 13:46:48 <rmk0> note that even if i cancel the future with interrupts, the parser carries on reading the stream
20150218 13:47:07 <rmk0> needs an xml file to read at /tmp/example.xml
20150218 13:47:57 <rmk0> these are just ordinary cancellable java futures, no guava
20150218 13:48:34 <zubzub> don't sleep in your read
20150218 13:48:39 <zubzub> unless it's poc code
20150218 13:48:43 <zubzub> plz :p
20150218 13:48:53 <rmk0> hehe, i obviously don't really do that
20150218 13:49:00 <rmk0> it's to make the reads slow enough that you can see they're happening
20150218 13:49:14 <rmk0> otherwise the whole stream is over before it can be cancelled
20150218 13:49:21 <zubzub> ok
20150218 13:50:22 <zubzub> maybe better to call isInterrupted
20150218 13:50:27 <zubzub> that won't clear the interrupt flag
20150218 13:50:33 <zubzub> interrupt clears it
20150218 13:50:38 <zubzub> (without is)
20150218 13:51:01 <zubzub> but yeath, that would be the overal idea, what you wrote
20150218 13:51:11 <zubzub> no idea how well it'll work though...
20150218 13:51:16 <rmk0> well, it doesn't work at all
20150218 13:51:20 <zubzub> ok :p
20150218 13:51:25 <rmk0> the thread doing the reading never even sees the interrupt
20150218 13:51:34 <rmk0> \o/
20150218 13:52:23 <zubzub> hmmmkay
20150218 13:55:22 <zubzub> so either something else clears your flag
20150218 13:55:27 <zubzub> or it's never set
20150218 13:57:43 <rmk0> this is why i assumed i'd have to implement my own future... if the stream had access to an AtomicBoolean and the cancel() op on the future set that to true
20150218 13:57:57 <rmk0> the original code stays ignorant of threading
20150218 13:58:05 <rmk0> the wrapper stream, i mean
20150218 13:58:07 <zubzub> well normally that's what the interrupt boolean in thread is for
20150218 13:58:22 <zubzub> the implementations of future all seem to set the interrupt on the thread
20150218 14:00:46 <zubzub> make sure you use isInterrupted()
20150218 14:00:59 <rmk0> yeah, am doing that
20150218 14:03:35 <rmk0> seems like the Thread.sleep() call may've been eating the interrupted status
20150218 14:03:47 <rmk0> http://waste.io7m.com/2015/02/18/TestUntyped.java
20150218 14:04:06 <rmk0> that "works", but is a bit weird... it actually detects an interrupt twice in the read() call and gives up on the second
20150218 14:04:58 <rmk0> http://waste.io7m.com/2015/02/18/read0.txt
20150218 14:05:07 <rmk0> that's the output... hundreds of read() calls omitted
20150218 14:08:43 <zubzub> yeah sleep is interruptable
20150218 14:09:07 <zubzub> so it probably clears your interrupt flag before going to sleep or something
20150218 14:09:13 * odin_ (~Odin@anon) Quit (Ping timeout: 272 seconds)
20150218 14:09:46 <zubzub> maybe the document reader retries if it encoutners an ioexception
20150218 14:09:55 <zubzub> try throing an unchecked exception
20150218 14:10:23 <zubzub> all exceptions are wrapped in ExecutionExceptions by the future anyway
20150218 14:10:58 <rmk0> yeah, seems like it does
20150218 14:11:08 <rmk0> it doesn't try again if it receives two
20150218 14:11:23 <rmk0> or if it receives IllegalArgumentException or something similar
20150218 14:11:33 <zubzub> huray, you have a solution now! :p
20150218 14:11:38 <rmk0> maybe!
20150218 14:11:47 <zubzub> somewhat sortof :p
20150218 14:16:04 <rmk0> thanks for the assistance, can probably make this work
20150218 14:16:31 <zubzub> np
20150218 14:16:49 <zubzub> I have to deal with so much badly written thread code
20150218 14:17:03 <zubzub> that I'm glad to help someone do it somewhat right at least :p
20150218 14:17:53 <rmk0> am generally fine with concurrency... this is an ugly problem, though
20150218 14:17:59 <rmk0> "trying to stop something that really doesn't want to stop"
20150218 14:18:18 <rmk0> if the parser consumed something that wasn't an inputstream, i don't think i'd be having this problem
20150218 14:21:58 * odin_ (~Odin@anon) has joined #jogamp
20150218 14:23:52 <zubzub> hi odin_
20150218 14:25:10 <zubzub> rmk0: alternatively you could ignore the result of the future instead of cancelling
20150218 14:25:24 <zubzub> this does however consume the thread until the connection timeouts or is done
20150218 15:41:45 <odin_> hi!
20150218 15:42:33 <zubzub> I didn't know you stalked this channel
20150218 15:43:08 <odin_> I stalk everything
20150218 16:04:53 * jvanek (jvanek@anon) Quit (Ping timeout: 240 seconds)
20150218 16:37:17 * jvanek (jvanek@anon) has joined #jogamp
20150218 16:51:32 * doev (~doev@anon) Quit (Ping timeout: 245 seconds)
20150218 16:57:44 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150218 17:05:25 * eclesia (~husky@anon) has left #jogamp
20150218 17:45:23 * monsieur_max (~maxime@anon) has joined #jogamp
20150218 18:17:58 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20150218 18:56:28 * doev (~doev@anon) has joined #jogamp
20150218 19:30:17 * doev (~doev@anon) Quit (Ping timeout: 245 seconds)
20150218 21:16:07 * monsieur_max (~maxime@anon) Quit (Ping timeout: 265 seconds)
20150218 21:28:14 * monsieur_max (~maxime@anon) has joined #jogamp
20150218 21:35:20 * monsieur_max1 (~maxime@anon) has joined #jogamp
20150218 21:35:20 * monsieur_max (~maxime@anon) Quit (Read error: Connection reset by peer)
20150218 22:17:53 * monsieur_max1 (~maxime@anon) Quit (Quit: Leaving.)
20150219 05:05:32 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20150219050532.html