#jogamp @ irc.freenode.net - 20140611 05:05:24 (UTC)
20140611 05:05:24 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20140610050524.html
20140611 05:05:24 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20140611050524.html
20140611 06:30:43 * monsieur_max (~maxime@anon) has joined #jogamp
20140611 06:42:08 * [Mike] (~Mike]@anon) Quit ()
20140611 07:00:38 * eclesia (~husky@anon) has joined #jogamp
20140611 07:00:46 <eclesia> good morning
20140611 07:02:19 <monsieur_max> hi eclesia :)
20140611 08:19:00 * hija (~hija@anon) Quit (Quit: hija)
20140611 08:33:56 * hija (~hija@anon) has joined #jogamp
20140611 08:40:28 * hija (~hija@anon) Quit (Quit: hija)
20140611 09:30:02 * zzuegg (~zzuegg@anon) Quit (Read error: Connection reset by peer)
20140611 09:31:20 * hija (~hija@anon) has joined #jogamp
20140611 09:31:39 * zzuegg (~zzuegg@anon) has joined #jogamp
20140611 10:54:54 <xranby> sgothel: thank you for the headsup
20140611 11:23:20 * magaio (~magaio@anon) Quit (Ping timeout: 265 seconds)
20140611 11:24:18 * magaio (~magaio@anon) has joined #jogamp
20140611 13:07:21 * bbbruce_ (~bx@anon) has joined #jogamp
20140611 13:07:56 * bbbruce (~bx@anon) Quit (Ping timeout: 260 seconds)
20140611 13:07:56 * bbbruce_ is now known as bbbruce
20140611 13:12:35 * masterzen (~masterzen@anon) has joined #jogamp
20140611 13:16:05 <masterzen> Hi guys, been a long time
20140611 13:16:35 <masterzen> Is it possible to use a GL ES 2 context on a GL ES 3 capable hardware?
20140611 13:16:39 <xranby> why do news take buffer overflow rish soo lightly?
20140611 13:16:57 <xranby> http://www.inforisktoday.com/openssl-flaw-discovered-patch-now-a-6915 - It's No Heartbleed, But Attackers Could Decrypt, Modify Traffic (and perform a buffer overrun flaw to run arbitrary code on vulnerable machines, but you have to read the article way down to read that)
20140611 13:17:25 <sgothel> @Brice (?): No - you will get an ES3 .. which shall be ES2 compatible .. almost ..
20140611 13:17:35 <masterzen> I have a shader that works when running on a GLES2 device, but not on a GLES3 device. With an older jogl version (not aware of ES3) this shaders works, but with 2.1.5 this produces nothing (but no errors).
20140611 13:17:36 <sgothel> at least .. thats how it is on Android
20140611 13:17:50 <masterzen> sgothel: yes, that's me :)
20140611 13:18:35 <xranby> masterzen: the shader needs some customization
20140611 13:18:40 <sgothel> and we .. do return the highest available and compatible ctx .. hmm .. here ES3 for ES2 ..
20140611 13:18:47 <sgothel> guess he knows ..
20140611 13:19:02 <sgothel> Q: how to select / force ES2 .. when ES3 and ES2 is avail
20140611 13:19:08 <masterzen> xranby: yes, I know. I tried to #version 100 or port it to ES 3 GSLS but nothing works. I'm out of clues
20140611 13:19:26 <xranby> masterzen: http://jogamp.org/wiki/index.php/How_to_write_cross_GLProfile_compatible_shader_using_JOGL
20140611 13:19:30 <sgothel> which driver ?
20140611 13:19:30 <masterzen> sgothel: yes, I ask for a GLES2 and get a ES3 compatible.
20140611 13:19:34 <xranby> this is the best knowledge we have on the subject
20140611 13:19:48 <masterzen> sgothel: it's a nexus 4 (adreno 320)
20140611 13:19:59 <sgothel> at least it should throw an exception .. i.e. 'can't compile'
20140611 13:20:11 <sgothel> DebugGL should say something
20140611 13:20:29 <sgothel> when I fix some ES3 GLSL issues .. they always complain properly
20140611 13:20:42 <sgothel> like 'can't cast int to float' etc
20140611 13:21:31 <sgothel> in your case driver ignores the GLSL version tag it seems ..
20140611 13:21:54 <sgothel> so do a proper ES3 GLSL code .. as we do in our demos .. ^^ above wiki
20140611 13:22:07 <masterzen> sgothel: that's quite possible. I get no compilation/link errors
20140611 13:23:16 <sgothel> do our demos work w/ that adreno driver ?
20140611 13:24:26 <masterzen> sgothel: I need to check.
20140611 13:27:46 <xranby> http://blogs.wsj.com/moneybeat/2014/06/11/expedia-starts-accepting-bitcoin-for-hotel-bookings/ <- lets see if i can book a hotel in toronto!
20140611 13:37:54 <masterzen> sgothel: gears ES2 and red squares ES2 are working.
20140611 13:38:06 <masterzen> sgothel: so it's definitely something in my shader.
20140611 13:38:54 * xranby wish all drivers start to support opengl es3 + shaders
20140611 13:39:07 <xranby> thus please lets have a new baseline soon
20140611 13:39:28 * eclesia wish opengl < 4 be deprecated
20140611 13:40:31 <xranby> and hope chronos stop change the glsl language in each opengl release
20140611 13:40:48 <eclesia> ha it has change ?
20140611 13:41:04 <eclesia> I'm only using 4+ so I don't really know
20140611 13:41:06 <xranby> ±o/
20140611 13:57:09 <xranby> http://opensslrampage.org/post/88383880093 Currently, the result from both ssl3_handshake_mac() calls is added together. This means that unless both MD5 and SHA1 fail, a positive value will be returned to the caller, indicating success rather than failure.
20140611 13:57:09 <xranby> soo.. thre will be a new openssl release soonish
20140611 14:35:33 <rmk0> wish the opengl people would let us submit standardized bytecode rather than this awful glsl language
20140611 15:01:36 * zzuegg (~zzuegg@anon) Quit (Ping timeout: 260 seconds)
20140611 15:02:43 * zzuegg (~zzuegg@anon) has joined #jogamp
20140611 15:59:34 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20140611 16:08:42 * eclesia (~husky@anon) has left #jogamp
20140611 16:55:17 * hija (~hija@anon) Quit (Quit: hija)
20140611 17:20:42 * monsieur_max (~maxime@anon) has joined #jogamp
20140611 17:26:53 * zzuegg_x (~zzuegg@anon) has joined #jogamp
20140611 17:27:17 * zzuegg (~zzuegg@anon) Quit (Ping timeout: 245 seconds)
20140611 17:27:23 * zzuegg_x is now known as zzuegg
20140611 17:43:55 * Eclesia (~eclesia@anon) has joined #jogamp
20140611 17:44:04 <Eclesia> hi (again)
20140611 18:08:28 <sgothel> @Mark: an GLSL IR (intermediate representation) indeed would at least remove the funny language changes based on 'taste and fashion' :)
20140611 18:08:45 <sgothel> and they would still be able to compile/optimize for the hardware .. agreed
20140611 18:10:32 <sgothel> @Xerxes: I also hope those now extra payed maintainers (actually all the one who proved to be useless code reviewers for years - they 'hired' them .. funny) .. will finally get their act together .. and do their review .. (they could get together w/ the libressl folks .. but I guess their false pride won't allow this )
20140611 18:10:42 <sgothel> @Eclesia and all: Hi :)
20140611 18:11:19 * Eclesia is fighting with vertex picking
20140611 18:11:32 <sgothel> read some article at arstech* .. about those now funded maintainers .. well, it won't help I guess
20140611 18:12:20 <sgothel> rumors has it .. that those devs locations in US, UK and Germany is quite close to SIGINT :)
20140611 18:13:05 <rmk0> sgothel: the bytecode approach seems to work well in the directx world... they have a lot of different shading languages competing as a result
20140611 18:13:18 <rmk0> is a shame the opengl committee sort of refuse to even admit the existence of it
20140611 18:13:32 <sgothel> yeah .. opencl has something .. thought GL will follow suite .. hmm
20140611 18:13:50 <rmk0> well i've seen in the past the opengl people flat out refuse, like "we will never have this"
20140611 18:14:07 <sgothel> status: updated to OSX 10.9 (test node) .. now lots of timing bugs .. to fix regarding CALayer and offthread creation
20140611 18:14:08 <rmk0> this is from the people that have a hand in the spec on the opengl.org forums
20140611 18:14:16 <rmk0> so... not sure if their opinion counts
20140611 18:14:23 <rmk0> could just be random internet idiots
20140611 18:14:25 <sgothel> the GL folks reason was 'need to compile and optimize for hardware'
20140611 18:14:33 <sgothel> hence IR / bytecode should be OK
20140611 18:14:37 <rmk0> yep
20140611 18:14:57 <sgothel> but .. you know, GL folks have a loooong tail of history :)
20140611 18:15:10 <rmk0> yeah...
20140611 18:15:10 <sgothel> so need some fresh injections .. :)
20140611 18:15:24 <rmk0> something only gets done when the previous committee are eliminated
20140611 18:15:29 <sgothel> then you can pick your GLSL style :)
20140611 18:15:45 <sgothel> Mesa has it already, NV has it ..
20140611 18:15:51 <sgothel> Intel .. dunno
20140611 18:16:13 <sgothel> IMHO exposing IR in MEsa as an extension would be best approach!
20140611 18:16:25 <sgothel> then make it subsume to ARB -> spec
20140611 18:16:30 <sgothel> go go go
20140611 18:16:40 <sgothel> Mesa uses IR .. AFAIK .. or it is planned
20140611 18:17:06 <sgothel> (some backends at least .. using llvm or similar)
20140611 18:17:33 <rmk0> would want well defined semantics
20140611 18:17:42 <rmk0> messy bytecode would probably be worse than GLSL at the moment
20140611 18:17:58 <sgothel> dunno
20140611 18:18:12 <sgothel> I mean there is/was an GLSL assembly language .. wasn't it ?
20140611 18:18:25 <sgothel> you know .. the stuff which came before GLSL ..
20140611 18:18:25 <rmk0> i mean from the perspective of someone authoring a shading language compiler
20140611 18:18:32 <rmk0> yeah... ARB assembly
20140611 18:18:40 <sgothel> maybe something ?
20140611 18:18:55 <rmk0> was deprecated long ago... no idea what sort of support it still has
20140611 18:18:59 <sgothel> or indeed create one new w/ LLVM based on current Mesa efforts
20140611 18:19:13 <sgothel> must be included in backward compat profiles
20140611 18:20:19 <rmk0> would probably be best to basically make a carbon copy of the directx stuff, adjusted to opengl conventions
20140611 18:20:20 <Eclesia> question : is it a good idea to use gl_PrimitiveId to find back the original triangle and then calculate (using a ray) the closest vertex ?
20140611 18:20:26 <sgothel> the funded 'glass' (sic) .. etc .. and existing GLSL IR in Mesa .. could be used
20140611 18:20:56 <sgothel> @Mark: if IP allows it .. sure - there is _NO_ difference in semantics anymore
20140611 18:21:21 <sgothel> (since >= 130 AFAIK, where you can define byteorder .. etc)
20140611 18:22:01 <rmk0> i don't know enough to do this, personally
20140611 18:22:06 <rmk0> i'm just an irritated compiler author
20140611 18:22:15 <rmk0> GLSL makes a horrible backend
20140611 18:22:46 * Eclesia has seen much worse languages, like mapbasic
20140611 18:22:54 <rmk0> i just know that there's obviously QUITE A BIT OF SOFTWARE out there done in directx, so their bytecode is obviously sufficient
20140611 18:23:21 <sgothel> well .. you have diff GLSL languages .. -> IR -> action / should not be too hard for a compiler author using ANTLR etc .. hmm
20140611 18:24:12 <sgothel> @Mark: the hardware is ofc identical .. hence no semantic diff in the end
20140611 18:24:18 <rmk0> urhur
20140611 18:26:22 <sgothel> (sure _supporting_ all variants .. especially for a little team is a huge burden)
20140611 18:27:23 <rmk0> variants of what?
20140611 18:27:37 <sgothel> of GLSL lang
20140611 18:27:43 <rmk0> oh, right
20140611 18:27:46 <sgothel> (or direct3d's lang .. etc)
20140611 18:27:52 <rmk0> yeah, it's basically impossible if you don't have an intermediate language
20140611 18:27:55 <sgothel> so the IR must 'catch all' .. etc
20140611 18:28:06 <sgothel> sure
20140611 18:28:17 <sgothel> (right :)
20140611 18:29:11 <sgothel> emphasize on _compiler_ to some semantic datastructures (IR if you like) .. then later execution ..
20140611 18:29:45 <sgothel> khronos released a validation util ... AFAIK
20140611 18:30:46 <sgothel> dunno which language it's implemented in .. and what sort of semantical analysis it allows and data its structures (AST) hold
20140611 18:31:11 * rmk0 eyes it
20140611 18:31:46 <rmk0> c++
20140611 18:32:49 <sgothel> where is it ? couldn't find an OSS version .. hmm
20140611 18:32:58 <sgothel> (only adopters ..)
20140611 18:33:08 <rmk0> https://www.khronos.org/opengles/sdk/tools/Reference-Compiler/
20140611 18:35:41 <sgothel> thx .. looking .. no lex/yacc or antlr ?
20140611 18:36:10 <sgothel> looks like manually implemented .. *autch*
20140611 18:36:42 <sgothel> https://cvs.khronos.org/svn/repos/ogl/trunk/ecosystem/public/sdk/tools/glslang/tools/data/
20140611 18:36:43 <rmk0> uses bison
20140611 18:36:45 <sgothel> bison ..
20140611 18:36:45 <sgothel> :)
20140611 18:36:49 <rmk0> *POW*
20140611 18:36:55 <sgothel> well, better than nothing .. haha
20140611 18:37:02 <rmk0> yeah...
20140611 18:37:05 <rmk0> just barely!
20140611 18:37:10 <sgothel> so yacc -> antlr .. I guess :)
20140611 18:37:23 <rmk0> i tend to generate lexers and hand-write parsers
20140611 18:37:34 <rmk0> but... i write strictly LALR(1) languages
20140611 18:37:35 <sgothel> memories .. like 15 years ago my last yacc code
20140611 18:38:11 <rmk0> parser generators are horrible things
20140611 18:38:29 <rmk0> almost universally awful error messages
20140611 18:38:35 <rmk0> "parse error" is about all the user can get
20140611 18:39:17 <rmk0> not sure if anyone's done any research into how to get generated parsers to give good error messages
20140611 18:39:21 <sgothel> well .. depends on your usage as well and how much is funneled down to the syntax/semantic analysis .. complicated, sure
20140611 18:39:38 <sgothel> llvm .. does quite a good thing I heard
20140611 18:39:45 <sgothel> (and seen using it w/ JOGL)
20140611 18:40:57 <rmk0> pretty sure they wrote their own parser for clang
20140611 18:41:00 <rmk0> didn't generate one
20140611 18:41:49 <sgothel> point is .. they keep the source [ref] down to IR somewhat for error reporting
20140611 18:42:06 <rmk0> yeah, can carry all that stuff along with the AST
20140611 18:42:09 <sgothel> also enabling the whole vmkit for java
20140611 18:42:21 <rmk0> i'm only talking about error reporting in generated parsers
20140611 18:42:42 <rmk0> i've not once seen better messages than "parse error" and a line/column number
20140611 18:44:15 <rmk0> that gnat ada compiler was awful, but they had a hand-written parser
20140611 18:44:22 <sgothel> ANTLR can't 'left recursive' ? ahh
20140611 18:44:30 <rmk0> very good error messages
20140611 18:44:41 <rmk0> at least when it didn't flat out crash
20140611 18:45:11 <rmk0> no left recursion in ANTLR, no
20140611 18:45:26 <Eclesia> it does in AntLR 4
20140611 18:45:32 <sgothel> ah
20140611 18:45:42 <rmk0> erk
20140611 18:45:51 <Eclesia> possible in antlr 3 but you had to make a nastly parser declaratin
20140611 18:45:57 <Eclesia> declaration*
20140611 18:46:51 <sgothel> yeah, I grew up w/ eBNF .. didn't analyze our antlr gluegen code too deep :)
20140611 18:47:43 <sgothel> Harvey .. has a cleanup for our ANTLR usage .. maybe some day .. we can enhance it for whatever reason
20140611 18:48:25 <Eclesia> ban bnf, javaCC gives me nightmares :/
20140611 18:48:52 <sgothel> I used javacc back in Gl4Java days :)
20140611 18:49:54 * Eclesia upgrade a CQL lexer/parser from javaCC to AntLR3 a few years ago and AntLR4 last year
20140611 18:51:45 <Eclesia> antlr3 is a bit messy, but the 4 is very fluent. the AST contains all the tokens so I use those for syntax coloration. add predicted token are also available starting 4.1
20140611 18:51:58 <Eclesia> so they could be used for stuff like autocompletion
20140611 18:52:42 <sgothel> sounds not too bad - nice, thx
20140611 18:55:54 * [Mike] (~Mike]@anon) has joined #jogamp
20140611 18:56:59 <Eclesia> sgothel: here is an exemple of how it looks like : http://pastebin.com/GDZZqcTR
20140611 18:58:03 <Eclesia> this was 100 line longer in antlr3
20140611 18:58:15 <Eclesia> and about 2000 lines in javacc...
20140611 18:59:09 <sgothel> has a good oversight .. cleaned up
20140611 18:59:29 <sgothel> and code can stay somewhere else ?
20140611 18:59:47 <sgothel> I always had to keep 2 versions .. one w/ semantics ..
20140611 18:59:59 <sgothel> where you can't read the actual grammar anymore :)
20140611 19:00:22 <Eclesia> the parser is generated on the fly with maven.
20140611 19:01:06 <Eclesia> I don't know if that's exactly the answer to your question :x
20140611 19:01:08 <sgothel> I mean the code executed after parsing certain blocks .. to produce a data structure .. or using AST afterwards ?
20140611 19:01:23 <sgothel> like compile A -> B
20140611 19:01:41 * hija (~hija@anon) has joined #jogamp
20140611 19:01:49 <Eclesia> it produces the AST, you do what you want with it after
20140611 19:02:11 <sgothel> in my early days I put in code like { copy left term to struct.c .. blabla }
20140611 19:02:12 <sgothel> ah
20140611 19:02:22 <sgothel> yeah, w/ yacc there was no AST :)
20140611 19:02:36 <Eclesia> no, there is no code in the grammar file
20140611 19:02:56 <sgothel> I like that
20140611 19:03:08 <sgothel> so visitor model on AST .. to produce output .. nice
20140611 19:03:23 <Eclesia> yop
20140611 19:05:05 <Eclesia> and for the build, place the grammar file in the resource folder and add a plugin in the pom.xml. this this one
20140611 19:05:07 <Eclesia> http://pastebin.com/z74E43BP
20140611 19:05:12 <Eclesia> and that's it.
20140611 19:05:30 <sgothel> (Mark is our Maven dude - me not so much :)
20140611 19:06:13 <rmk0> always glad to see a maven plugin
20140611 19:07:17 <Eclesia> about the left recursion problem, this was not possible in antlr3 :
20140611 19:07:19 <Eclesia> filter : filter (AND filter)+
20140611 19:07:33 <Eclesia> it makes things a loooooooooot easier now
20140611 19:07:58 <sgothel> so it is an LALR(*) parser now ? good
20140611 19:09:05 <Eclesia> there are flags to control when rules are greedy and stuff like that but I don't know much more about it
20140611 19:11:16 <sgothel> I read: antlr 'unrolls' parser state-machine in code, where yacc uses a table (I impl. a lexer once as a state-machine .. fun)
20140611 19:11:28 <sgothel> so the unrolling will produce a lot of code ..
20140611 19:13:21 <sgothel> https://www.gnu.org/software/bison/manual/html_node/Java-Bison-Interface.html#Java-Bison-Interface ?
20140611 19:13:40 <sgothel> (^^back to reusing the GLSL bison parser w/ java .. )
20140611 19:26:43 <Eclesia> changing subject, know any alternative to occulusvr ?
20140611 19:27:09 <sgothel> not to purchase right now ..
20140611 19:27:19 <Eclesia> even later ^^
20140611 19:27:57 <sgothel> AFAIK sony, valve, .. are working on it - some Canadian dude has something (welding hat alike) .. etc
20140611 19:28:25 <sgothel> I will make a test w/ occulusvr this week
20140611 19:29:03 <Eclesia> :o you are lucky . it's a shame facebook buyed it ...
20140611 19:29:11 <sgothel> indeed
20140611 19:38:48 <Eclesia> bye +++
20140611 19:39:02 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20140611 19:42:08 * hharrison_ (~chatzilla@anon) has joined #jogamp
20140611 19:42:51 <hharrison_> funny, I was just looking at antlr 4 to see how bad it would be to move gluegen over to it
20140611 19:43:09 <hharrison_> It seems a _lot_ nicer to work with than antlr 3
20140611 19:50:30 <rmk0> ... urgh, no user-definable clipping planes in opengl es2?
20140611 19:56:00 <sgothel> high level stuff :)
20140611 19:59:25 <rmk0> is there some incredibly obvious way to implement it in a vertex shader?
20140611 20:01:14 <sgothel> probably not, since you only have the edges ..
20140611 20:01:35 <sgothel> did clipping worked per fragment ?
20140611 20:02:19 <rmk0> on everything that isn't ES2, you assign planes in the vertex shader
20140611 20:02:21 <sgothel> ofc .. your high-level clipping octree will help if I am not mistaken ..
20140611 20:02:28 <sgothel> ah
20140611 20:02:49 <sgothel> so it's not per fragment ..
20140611 20:03:09 <sgothel> and you could do that in user code .. no discard if vertex shader
20140611 20:03:11 <rmk0> questionably
20140611 20:03:13 <sgothel> *in*
20140611 20:03:25 <rmk0> the planes are assigned in the vertex shader, they're passed on to the next stage
20140611 20:03:32 <sgothel> oh
20140611 20:03:43 <rmk0> is the clipping hardware that does the ... clipping
20140611 20:03:45 <sgothel> there you go .. you can do it in fragment shader ..
20140611 20:03:58 <sgothel> but using discard .. YMMV .. i.e. buggy in some ES2 impl.
20140611 20:04:09 <rmk0> i think i'd rather just drop support for ES2
20140611 20:04:10 <sgothel> hence we often use simply alpha=0 w/ blending :)
20140611 20:04:22 <rmk0> patience may have finally run out with it
20140611 20:04:30 <sgothel> a true manager solution :)
20140611 20:04:35 <rmk0> \o/
20140611 20:04:56 <hharrison_> sgothel: what kind of timing problems are you seeing in osx 10.9?
20140611 20:05:39 <sgothel> well, I have that old mac-mini w/ 2GB ram, core 2-duo and an old NV GPU 320M
20140611 20:05:45 <sgothel> it ran OSX 10.7 or so ..
20140611 20:06:04 <sgothel> now w/ 10.9 .. the deferred offthread CALayer use .. seems to become a problem
20140611 20:06:19 <sgothel> no problems w/ a new fast macbook and 10.9
20140611 20:06:43 <sgothel> test case TestAddRemove01GLCanvasSwingAWT for example ..
20140611 20:07:00 <sgothel> we only show a test for 100ms .. AWT needs often longer to make the item visible
20140611 20:07:21 <sgothel> for some reason .. looks like we create/destroy CALayer to fast .. or something
20140611 20:07:42 <sgothel> adding debug printf .. in our native CALAyer code removes the issue
20140611 20:08:02 <sgothel> looks like .. AWT creates/destroys not on the main-thread (which we use)
20140611 20:08:25 <sgothel> well .. too early to know whats going on
20140611 20:08:56 <sgothel> if I hold the test period for each GLCanvas for a longer period (i.e. 2s) .. no crash
20140611 20:09:57 <sgothel> but the default 100ms crashes .. in CA::AsyncDeletionLLcallback .. glDeleteFramebufferEXT / gleRemoveHashObject .. (some AWT method I guess)
20140611 20:10:19 <sgothel> btw .. the machine behaves very slow
20140611 20:12:21 <sgothel> (more like a synthetic issue .. since creating a GLCanvas for 100ms is not really the real world test - however, I like the code to be correct .. hmm)
20140611 20:13:59 <sgothel> afk .. laters
20140611 20:14:26 <rmk0> ugh, yes, the only way to achieve it in ES2 is with "discard"
20140611 20:39:18 <sgothel> .. or alpha=0
20140611 20:39:53 -verne.freenode.net- Server Terminating. tomaw
20140611 20:39:53 * Disconnected.