#jogamp @ irc.freenode.net - 20140926 05:05:45 (UTC)

20140926 05:05:45 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20140925050545.html
20140926 05:05:45 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20140926050545.html
20140926 06:45:17 * monsieur_max (~maxime@anon) has joined #jogamp
20140926 07:15:14 * eclesia (~husky@anon) has joined #jogamp
20140926 07:15:19 <eclesia> good morning
20140926 07:25:27 * xranby (~xranby@anon) has joined #jogamp
20140926 07:26:24 <xranby> good morning
20140926 07:29:27 <xranby> https://www.youtube.com/watch?v=aKShnpOXqn0 this 4 minute video give a heads up about the "shellshock" CVE-2014-6271: remote code execution through bash .. and.. CVE-2014-7169 to track the report of the incomplete patch for CVE-2014-6271
20140926 07:30:31 <xranby> so in a nut-shell.. if you have a git server, webserver, homerouter, phone or say a smart lightblub its a good idea to make sure it got an updated version of bash.
20140926 07:31:57 <xranby> because all versions of bash since 25 years back is now explotable by cgi, dhcp, ssh restricted login bypass, etc etc
20140926 07:32:03 * jvanek (jvanek@anon) has joined #jogamp
20140926 07:33:12 <xranby> If you have Debian based boxes, do this now:
20140926 07:33:16 <xranby> sudo apt-get update && sudo apt-get install --only-upgrade bash
20140926 07:33:28 <xranby> Upgrades Bash only.
20140926 07:35:14 <xranby> http://www.fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
20140926 07:44:36 * [Mike] (~Mike]@anon) Quit ()
20140926 08:06:43 * gouessej (5ee4b442@anon) has joined #jogamp
20140926 08:08:10 * gouessej (5ee4b442@anon) Quit (Client Quit)
20140926 08:10:42 * gouessej (5ee4b442@anon) has joined #jogamp
20140926 08:12:28 <gouessej> hi
20140926 08:13:21 <xranby> gouessej: hi, i am busy patching bash on all my buildservers
20140926 08:13:25 <gouessej> Sven, what am I intended to do for the bug 1078?
20140926 08:13:56 <gouessej> xranby, I updated Mageia yesterday to benefit of Bash fixes
20140926 08:14:45 <xranby> gouessej: kudos! did you apply the fix for both CVE-2014-6271 and CVE-2014-7169?
20140926 08:16:46 <gouessej> "update from patchlevel 37 to 48 to fix CVE-2014-6271 and several other bugs"
20140926 08:17:01 <gouessej> http://pkgs.org/mageia-4/mageia-core-updates-i586/bash-4.2-48.1.mga4.i586.rpm.html
20140926 08:33:48 <eclesia> question : can we use glClearbuffer to clear a texture 2d ou texture 2d multisampled ?
20140926 08:36:06 <gouessej> you can clear a bound FBO texture by using glClearBuffer
20140926 08:36:13 <gouessej> Is it what you mean?
20140926 08:36:30 <eclesia> I'm searching for a way to create an empty texture 2d multisampled
20140926 08:36:42 <eclesia> whitout using an fbo to clean it
20140926 08:39:02 * xranby (~xranby@anon) Quit (Ping timeout: 244 seconds)
20140926 08:40:34 * xranby (~xranby@anon) has joined #jogamp
20140926 08:51:46 <eclesia> sgothel: do you have an idea ?
20140926 09:24:45 <xranby> gouessej: GNU bash patchlevel 48 only covers CVE-2014-6271
20140926 09:25:03 <xranby> keep an eye for when new patchlevels are published on GNU ftp servers
20140926 09:25:19 <xranby> for example CVE-2014-7169 is http://www.openwall.com/lists/oss-security/2014/09/25/10
20140926 09:26:00 <gouessej> xranby: Luigi will probably push another update very soon and I'll use it as soon as possible of course
20140926 09:26:08 <xranby> for example debian and ubuntu are already this fix http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-7169.html
20140926 09:26:41 <xranby> i took a peek at the full disclosure mailinglist and there is two new memory overflow bugs found as well
20140926 09:27:04 <xranby> CVE-2014-7186 and CVE-2014-7187 http://seclists.org/oss-sec/2014/q3/735
20140926 09:27:29 <xranby> sounds like we will have a bit of patch pain in the following days
20140926 09:28:36 <xranby> good news is that this code now gets a proper code audit!
20140926 09:28:50 <xranby> hurray for free software that makes it possible
20140926 09:29:52 <eclesia> they should just forget about C/C++ and all those ugly memory/flow issues once and for all
20140926 09:31:47 <xranby> eclesia: yes... java based init maybe?
20140926 09:32:13 <eclesia> xranby: hmm.. why not my futur VM :D ?
20140926 09:32:26 <xranby> i expect people to throat feed us systemd as a replacement for bash in the near future
20140926 09:32:40 <xranby> it would be good to have your futur VM as a replacement for systemd
20140926 09:33:51 * eclesia keeps an eye on HelenOS, might be the next generation OS
20140926 09:39:49 <eclesia> no answer to my question ? :'(
20140926 09:40:05 <gouessej> sgothel: There is no trivial way of fixing this bug, the "fixed" capabilities object is used here: https://github.com/sgothel/jogl/blob/master/src/jogl/classes/jogamp/opengl/GLDrawableFactoryImpl.java#L306
20140926 09:40:41 <gouessej> sgothel: I would prefer using the "best" real capabilities object
20140926 09:42:52 * xranby (~xranby@anon) Quit (Quit: Leaving.)
20140926 09:43:03 * xranby (~xranby@anon) has joined #jogamp
20140926 09:46:50 <gouessej> sgothel: why not using the capabilities chooser in this method?
20140926 10:36:48 <sgothel> @Julien: I could need the debug log file w/ old JOGL .. working (I mentioned it .. hmm) .. I will hack on this bug later, thank you!
20140926 10:36:58 <sgothel> @Eclesia: FBObject can do all this
20140926 10:37:38 <sgothel> ok .. me heading out now, laters
20140926 10:45:47 <gouessej> sorry I was eating
20140926 10:47:10 <gouessej> ok I'm going to try to find a working version
20140926 10:52:22 <gouessej> sgothel: Please could you clarify an aspect about GLCapabilities?
20140926 10:52:37 <gouessej> What means "on-scr[fbo, pbuffer]"?
20140926 11:50:27 <eclesia> question on fragment shader . is there a way to skip writing in an output layout ? like discard but for only one value
20140926 12:15:57 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20140926 12:50:58 <gouessej> :(
20140926 12:51:16 <gouessej> It was already broken in JOGL 2.1.5 + Java3D 1.6.0 pre9
20140926 12:52:22 <gouessej> Forcing the use of a bitmap doesn't solve the problem, the context can't get current
20140926 14:07:51 <bbbruce> another jogl powered project: http://lustlab.net (camera postura)
20140926 14:09:57 <gouessej> cool :)
20140926 14:34:32 <gouessej> sgothel: I'm running out of ideas to fix the bug 1078 :s
20140926 14:41:32 * gouessej (5ee4b442@anon) Quit (Quit: Page closed)
20140926 15:54:13 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20140926 16:07:25 * eclesia (~husky@anon) has left #jogamp
20140926 17:09:39 * bbbruce (~bx@anon) Quit (Ping timeout: 246 seconds)
20140926 17:22:26 * bbbruce (~bx@anon) has joined #jogamp
20140926 17:59:36 * monsieur_max (~maxime@anon) has joined #jogamp
20140926 18:02:48 * Eclesia (~eclesia@anon) has joined #jogamp
20140926 18:03:02 <Eclesia> hi
20140926 18:03:32 <Eclesia> someone send me a strange error :
20140926 18:03:36 <Eclesia> Caused by: javax.media.opengl.GLException: Not a GL3 implementation
20140926 18:03:36 <Eclesia> at jogamp.opengl.gl4.GL4bcImpl.getGL3(GL4bcImpl.java:37063)
20140926 18:03:36 <Eclesia> at un.engine.opengl.resource.TextureUtils.createTexture(TextureUtils.java:369)
20140926 18:04:19 <Eclesia> the current implementation is a GL4bcImpl , but error say it's not a GL3. How is that possible ???
20140926 18:05:23 <sgothel> GL4bcImpl is used for all profiles
20140926 18:05:41 <sgothel> so no indication, you would need the whole debug log, to see what profile is actually in use
20140926 18:05:54 <sgothel> probably GL2 or ES[123] here
20140926 18:06:22 <sgothel> try using GL2ES2 .. etc in your code, GL3 is quite a strict requirement
20140926 18:06:45 <sgothel> you can also query isGL3() via GL, it's context .. or it's GLProfile
20140926 18:08:46 <Eclesia> ok thanks
20140926 18:12:50 <Eclesia> sgothel: do you have an answer to this question : 11:50:27 <eclesia> question on fragment shader . is there a way to skip writing in an output layout ? like discard but for only one value
20140926 18:16:44 <sgothel> dunno
20140926 18:17:27 <sgothel> we often use alpha=0 in case discard is n/a
20140926 18:18:24 <Eclesia> sgothel: so do I, but here I would still like to write in several of the other outputs
20140926 18:21:30 <sgothel> MRT ?
20140926 18:22:36 <sgothel> .. and then it is still one 'fragment' run per pixel, so discard would apply - guess I didn't get the 'output layout' thingy ?
20140926 18:35:38 * [Mike] (~Mike]@anon) has joined #jogamp
20140926 19:12:41 <Eclesia> sgothel: sorry for the delay. In the fragment shader I have 6 : layout (location = X) out int f_outX;
20140926 19:13:04 <Eclesia> I collect : fragment position, normal, diffuse ... and others.
20140926 19:13:28 <Eclesia> and in some cases I want to avoid writing in the output
20140926 19:14:43 <Eclesia> like for example picking may be possible behind a glass. so the diffuse output is written, but not the picking value, since it's the object behind we want, not the glass
20140926 19:15:25 <rmk0> Eclesia: is explicitly forbidden by the specs, unfortunately
20140926 19:15:53 <rmk0> attempting to discard one or more outputs as opposed to all of them, i mean
20140926 19:17:22 <Eclesia> rmk0: thanks for the info. :) I had found some variables like glBufferMask which seems to impact the output writting, but it wasn't very clear :/
20140926 19:18:11 <rmk0> can obviously use the indexed variants of glColorMask to mask writing to specific outputs, but it obviously doesn't give you per-fragment control of it
20140926 19:21:10 <Eclesia> another question : I've read somewhere that binding and unbinding FBO is very expensive and that we should prefer the solution of changing attachments of a unique FBO.
20140926 19:21:20 <Eclesia> is that true ?
20140926 19:21:50 <rmk0> was ... under the impression that it was the exact opposite
20140926 19:22:08 <rmk0> i'm certainly doing the former
20140926 19:22:31 <Eclesia> same for me
20140926 19:23:16 <Eclesia> ... must really be carefull on the advises found on forums ...
20140926 19:23:16 <rmk0> sgothel mentioned something about this ages ago... something about the first time a color buffer is attached to an FBO, it's rather expensive
20140926 19:23:30 <rmk0> but after that, binding/unbinding the FBO is almost a no-op
20140926 19:23:34 <sgothel> yup .. reconfig of an FBO is expensive
20140926 19:23:49 <sgothel> IFF switchin FBO would be expensive, then swap-buffers would be :)
20140926 19:23:58 <Eclesia> iff?
20140926 19:23:59 <sgothel> i.e. they are all framebuffers
20140926 19:24:03 <sgothel> if and only if
20140926 19:24:19 <Eclesia> ^^
20140926 19:24:41 <rmk0> between shadow mapping, emission mapping, deferred rendering, etc, i'm probably working with 10-20 framebuffers at a time, depending on the scene
20140926 19:24:46 <rmk0> seems cheap
20140926 19:25:09 <rmk0> i pull them from a pool and give them back when i'm done with them
20140926 19:25:50 <Eclesia> hm I have 8 in my game engine.
20140926 19:26:00 <rmk0> i wouldn't worry about it
20140926 19:26:11 <Eclesia> the biggest has 6 output layouts
20140926 19:30:04 <Eclesia> sgothel: to you have a debug frame, I mean I would like to know the current variable states of the GL object at an instant ? like if GL_BLEND is active, and so on
20140926 19:30:22 <Eclesia> somekind of summary
20140926 19:30:47 <sgothel> trace and look at latest setting :)
20140926 19:30:57 <sgothel> TraceGL property
20140926 19:31:07 <sgothel> or use some tool - @Mark mentioned some
20140926 19:31:38 <Eclesia> I wrap my GL instance in a TraceGL ?
20140926 19:32:11 <sgothel> yeah .. as also done automatically via -Djogl.debug.TraceGL
20140926 19:32:17 <sgothel> like -Djogl.debug.DebugGL
20140926 19:32:27 <rmk0> http://apitrace.github.io
20140926 19:32:30 <rmk0> ♥ ♥ ♥ ♥
20140926 19:32:35 <rmk0> couldn't live without it
20140926 19:32:36 <sgothel> then GLContextImpl does all the wrapping - always
20140926 19:32:58 <sgothel> yup .. but never tried yet .. have to test
20140926 19:34:54 <Eclesia> rmk0: is that easy to use ? I tryed something like gldebug once, never made it work ...
20140926 19:35:39 <rmk0> yeah... run your program with "apitrace trace ..."
20140926 19:36:01 <rmk0> that'll create a trace file, can then do "qapitrace /path/to/trace"
20140926 19:36:19 <rmk0> and that'll show that UI, can then step through the recorded trace and see state changes, framebuffers, textures, etc
20140926 19:40:15 <rmk0> i've not gotten any of the other opengl debuggers to work either
20140926 19:40:19 <rmk0> they generally crash
20140926 19:41:22 <Eclesia> rmk0: about the command, I have my jar ready, work like : java -jar myjar.jar
20140926 19:42:13 <Eclesia> will that be ok, or do I need to make a small shell script to launch the app ?
20140926 19:42:26 <rmk0> i think you should be ok
20140926 19:42:32 <rmk0> all the apitrace command actually does is set LD_PRELOAD
20140926 19:42:55 <rmk0> should pass on all command line arguments to java unmolested
20140926 19:44:13 <rmk0> might want to use "apitrace trace --output=xyz.trace"
20140926 19:44:27 <rmk0> otherwise the trace file will be called java.trace, as it uses the name of the executable
20140926 19:45:04 <Eclesia> so far I didn't find the command to start my app ^^
20140926 19:45:13 <Eclesia> (with apitrace)
20140926 19:45:37 <Eclesia> ha
20140926 19:45:53 <rmk0> "trace" is the subcommand... $ apitrace trace java -jar xyz.jar
20140926 19:46:16 <Eclesia> found it
20140926 19:46:44 <Eclesia> I was adding "" to pass the all java -jar as a single argument
20140926 19:46:55 <rmk0> ah, right... it won't like that
20140926 19:51:12 <Eclesia> ok it works, qapitrace and gl states
20140926 19:51:37 <Eclesia> ... know the hard part, I need to find my bug :X ...
20140926 19:51:41 <Eclesia> now*
20140926 19:54:41 <Eclesia> rmk0: 3300 calls per frame, is that a lot ?
20140926 19:55:47 <sgothel> lots of state changes ? all shader based code, doesn't look like .. ?
20140926 19:57:36 <rmk0> think the number of calls is always going to be into the thousands
20140926 19:57:49 <rmk0> can easily be ten times that with the fixed-function pipeline
20140926 19:59:42 <Eclesia> there is something odd, all frames have the same number of calls, I make some extra actions on some of them :/
20140926 20:00:32 <Eclesia> I guess that's my bug, a method not called when it should have ^^
20140926 20:00:50 <Eclesia> rmk0: nice tool, thanks +1
20140926 20:01:20 <rmk0> \o/
20140926 20:02:29 <Eclesia> here is your reward : >o< don't swallow it ^^
20140926 20:03:09 <rmk0> heh
20140926 20:11:59 <Eclesia> good night ++
20140926 20:12:22 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20140926 21:30:24 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20140926 22:06:40 <sgothel> @Mark: updated jausoft.com .. zfs update was included .. me naive and hopeful .. well, failed ofc :)
20140926 22:06:50 <sgothel> regenerated the zpool.cache .. nada
20140926 22:07:07 <sgothel> (from a rescue system w/ zfs on USB stick)
20140926 22:07:27 <sgothel> the rescue sys is updated as well and can deal w/ he pools
20140926 22:07:30 <sgothel> *the*
20140926 22:07:58 <sgothel> grub entries are fine .. i.e. pointing to right zfs pool for root (bootf, rpool)
20140926 22:08:02 <sgothel> *bootfs*
20140926 22:08:17 <sgothel> now I ordered a remote KVM console .. hmm
20140926 22:08:20 <sgothel> debian 7 ..
20140926 22:08:30 <sgothel> was doing this before wrecking jogamp.org :)
20140926 22:09:05 <sgothel> zfs stuff was updated from 0.6.2 to 0.6.3 ..
20140926 22:09:10 <sgothel> ideas ?
20140926 23:20:52 * xranby (~xranby@anon) Quit (Ping timeout: 240 seconds)
20140927 00:05:31 <sgothel> jogamp.org -> maintenance mode soon ..
20140927 00:26:22 <sgothel> the zfs debian boot shell scripts are at fault .. confusion about things (already imported pool) .. etc duh