#jogamp @ irc.freenode.net - 20160129 05:05:21 (UTC)

20160129 05:05:21 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20160128050520.html
20160129 05:05:21 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20160129050521.html
20160129 07:07:43 * monsieur_max (~maxime@anon) has joined #jogamp
20160129 07:09:46 * monsieur_max (~maxime@anon) Quit (Client Quit)
20160129 07:28:20 * epdv (059f3c13@anon) has joined #jogamp
20160129 07:28:39 * epdv (059f3c13@anon) Quit (Client Quit)
20160129 07:39:07 * monsieur_max (~maxime@anon) has joined #jogamp
20160129 07:55:35 * elect (~GBarbieri@anon) has joined #jogamp
20160129 08:28:43 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20160129 08:32:17 * Eclesia (~husky@anon) has joined #jogamp
20160129 08:32:31 <Eclesia> good morning
20160129 09:53:37 * philjord (599cc172@anon) has joined #jogamp
20160129 11:00:22 * monsieur_max (~maxime@anon) has joined #jogamp
20160129 12:54:19 <elect> is sven available these days?
20160129 12:54:31 <elect> anyone has news of him?
20160129 13:00:49 <elect> is there anyone with code responsability available?
20160129 13:01:12 <zubzub> nope
20160129 13:01:31 <zubzub> I think everybody is dead
20160129 13:06:21 <monsieur_max> same feeling
20160129 13:09:53 <rmk0> i think he's more active on the forum than in here
20160129 13:10:01 <rmk0> but somewhat less so these past few weeks
20160129 13:10:30 <elect> last reply on the forum is from last year
20160129 13:11:34 <elect> is he the only one who can accept pulls?
20160129 13:13:22 <rmk0> as far as i know
20160129 13:21:19 * Eclesia has the same feeling
20160129 13:24:36 <rmk0> i've always been somewhat surprised that jogl is under such active development as it is
20160129 13:25:01 <rmk0> there's a surprising amount of stuff for what should just be bindings to an API that is rarely updated
20160129 13:25:57 <Eclesia> rmk0: jogamp is trying to do more then it should
20160129 13:25:58 <monsieur_max> well, tkae NEwt as an example, it has nothing to do with bindings
20160129 13:26:31 <rmk0> Eclesia: i agree...
20160129 13:27:09 <zubzub> Eclesia: 2nded
20160129 13:27:59 <zubzub> It's surprisingly unintuitive/difficult to, lets say, do gl drawing using an unsupported egl new implementation
20160129 13:28:05 <zubzub> *newt
20160129 13:28:21 <zubzub> if if you set up all the egl calls with your own bindings
20160129 13:28:25 <zubzub> *even if
20160129 13:29:00 <zubzub> tbh I still havent figured it out
20160129 13:29:14 <Eclesia> zubzub: how would we make a frame if there isn't newt ?
20160129 13:29:28 <zubzub> I don't know
20160129 13:29:45 <zubzub> it plain C egl/gl, the egl setup is like 5 lines and you start drawing with gl
20160129 13:29:48 <Eclesia> awt frame and swing jframe are obsolete and slower so I believe we need newt
20160129 13:30:06 <zubzub> for some reason there is a need for an abstraction to newt
20160129 13:30:17 <zubzub> great, but what if newt doesnt support the use case
20160129 13:30:22 <zubzub> then you're stuck
20160129 13:30:51 <zubzub> eg gbm/egl (kms+drm)
20160129 13:31:49 <elect> yeah rmk0, but, correct me if I am wrong, most of the dev comes from sven
20160129 13:32:17 <elect> or at least this is my impression
20160129 13:32:35 <elect> like 90%
20160129 13:33:07 <zubzub> yeah
20160129 13:33:11 <zubzub> the other 10 is xranby :p
20160129 13:33:16 <monsieur_max> the classic case of new dad
20160129 13:33:25 <zubzub> yeah
20160129 13:33:33 <zubzub> he won't have time the first year
20160129 13:33:52 <elect> if I look here https://github.com/sgothel/jogl/graphs/contributors
20160129 13:34:22 <elect> sven is the first one, second is kenrussel, who is since 10 years away, third mbien, who is long time he is no more active
20160129 13:34:23 <elect> right?
20160129 13:35:40 <rmk0> sounds right
20160129 13:35:45 <elect> and look at the dev graph, most of the development was between in [2012-14]
20160129 13:36:17 <elect> that is, roughly, the same sven dev
20160129 13:37:05 <monsieur_max> elect: what do you have in mind ?
20160129 13:37:35 <elect> I am always been afraid jogl community is gonna disappear
20160129 13:38:00 <elect> and if you think vulkan is coming
20160129 13:38:02 <elect> .
20160129 13:38:15 <elect> this is a time when you need a lot of resources
20160129 13:38:36 <elect> we should make the website more user- friendly
20160129 13:38:42 <elect> we should upgrade the forum
20160129 13:38:49 <monsieur_max> elect: you'd make a good contributor :)
20160129 13:38:56 <elect> we should write more jogl samples
20160129 13:39:17 <elect> I am trying to contribute by enrichting the wiki and writing jogl-samples
20160129 13:39:48 <rmk0> opengl is nearly EOL, as far as i can tell
20160129 13:40:03 <zubzub> it will remain active for quite some time...
20160129 13:40:04 <elect> and probabily I am gonna also make a short video to set up a basic hello triangle from nothing (no even ide)
20160129 13:40:07 <rmk0> it has the feel of something that's on its last legs
20160129 13:40:28 <elect> you think?
20160129 13:40:42 <rmk0> it's gotten to the same point that opengl 2.1
20160129 13:40:43 <elect> I saw something like an hello triangle in mantle
20160129 13:40:46 <rmk0> ... did
20160129 13:40:46 <zubzub> it will be *at least* 10y before it's EOL
20160129 13:40:47 <elect> 700 lines
20160129 13:41:00 <monsieur_max> well, then a vulkan fork of jogl using newt and limited only to bindings ?
20160129 13:41:19 <elect> it's been 4 years for me on GL and I have no intention at all to manage memory at low level
20160129 13:41:28 <elect> azdo Gl are perfectly fine for that
20160129 13:42:03 <elect> I'm afraid it won't be so easy, monsieur_max
20160129 13:42:10 * hija (~hija@anon) has joined #jogamp
20160129 13:42:34 <monsieur_max> elect: you bet ...
20160129 13:42:51 <monsieur_max> but honestly, that's all i need
20160129 13:42:55 <elect> take a look, rmk0 https://github.com/Overv/MantleHelloTriangle/blob/master/src/main.cpp
20160129 13:43:41 <elect> I am also writing a texture and math util
20160129 13:44:09 <elect> zubzub, tell me if you could be still interested
20160129 13:45:18 <rmk0> elect: looks good to me. no more state machine
20160129 13:45:41 <elect> well, having different choices is good
20160129 13:46:09 <elect> so that who wants go down that route, can go
20160129 13:46:23 <elect> who wanna stay on GL stays on GL
20160129 13:47:09 <elect> but I dont thing people who want to remain on GL and let the driver manage the memory will be so few
20160129 13:47:27 <elect> we'll see anywa
20160129 13:47:27 <elect> yy
20160129 13:48:47 <rmk0> i would expect third party engines to take over that role
20160129 13:48:59 <rmk0> opengl isn't even good for "simple" rendering, it's far too error prone and weakly typed
20160129 13:50:16 <zubzub> rmk0: nonsense, it only took me 3 weeks to port 100 lines from desktop to rpi :p
20160129 13:50:46 <zubzub> and in the end I still don't know why it didn't want to work as is
20160129 13:50:57 <rmk0> hehe
20160129 13:53:54 <elect> well, don't forget it's always a low level graphic api
20160129 13:54:07 <elect> and if you think that is error prone, image vulkan
20160129 13:54:28 <elect> with multithreaded rendering and so on
20160129 13:54:57 <monsieur_max> elect does not like vulkan :(
20160129 13:54:59 <rmk0> from what i can see, the vulkan api is unsafe, but it's the layers of complex and awful abstractions that opengl adds on top that are the main source of errors
20160129 13:55:51 <elect> for example?
20160129 13:55:54 <rmk0> lack of safety can be remedied by static typing, but it's extremely difficult to reduce the complexity of an already unnecessarily complex abstraction like opengl
20160129 13:56:25 <rmk0> elect: buffer binding, the entire texture api, the presence of all that mutable global state, etc, etc
20160129 13:56:42 <rmk0> really the entire vertex attribute interface
20160129 13:57:04 <Eclesia> maybe problems could be reduced with a new GL profile and interface.
20160129 13:57:09 <rmk0> all the hacks they keep layering on to poke holes through the crap they accumulated (bindless, instancing, etc)
20160129 13:57:52 <rmk0> even shader compilation is horrible
20160129 13:57:56 <elect> this is something you have to deal with if the api has 20 years
20160129 13:58:36 <rmk0> elect: no, this is a problem they caused and continue to cause. they created an abstraction where one wasn't required, and refused to remove anything ever
20160129 13:58:48 <elect> but the last extensiont help, for example direct state access, separating the vertex format and binding
20160129 13:58:55 <rmk0> vulkan appears to be a complete rejection of that approach
20160129 13:59:35 <rmk0> elect: like i said... poking holes in abstractions that shouldn't be there in the first place
20160129 14:00:30 <elect> this is something one should "embank" by doing a sort of cleaning, such as GL 3.3 and declaring a lot of old things deprecated
20160129 14:00:53 <elect> g-truck himself says he'd like that to happen again
20160129 14:01:15 <rmk0> i'd rather they didn't keep beating a dead horse
20160129 14:02:09 <rmk0> let third parties build better abstractions if they feel they're necessary. that allows those abstractions to exist in a manner that doesn't end up having to be dragged along for twenty years because nobody has any choice but to use them
20160129 14:02:15 <rmk0> keeps it out of the core
20160129 14:03:21 <rmk0> i'll be dumping all my opengl code for vulkan as soon as it's practical
20160129 14:03:42 <rmk0> as in, open drivers are available
20160129 14:04:02 <elect> this'll lead to enourmous deframmentation, you know
20160129 14:04:17 <rmk0> ?
20160129 14:04:34 <elect> every third part doing its own abstraction
20160129 14:04:38 <Eclesia> would be nice to make a java > vulcan compiler
20160129 14:05:54 <rmk0> elect: how is that a problem? that's like saying it's a problem that there are multiple implementations of ... well ... anything
20160129 14:06:10 <rmk0> this wouldn't be fragmentation of the form where you as a programmer would have to support tons of different things
20160129 14:06:18 <elect> opengl may have all the problem you mention, but at least when I ask for a specific profile, and the driver is not bugged, I have the security that I have at least some features as declared from that profile
20160129 14:06:27 <rmk0> is like saying "oh shit! there are loads of 3D engines and i have to support them all!"
20160129 14:07:05 <elect> I dont know
20160129 14:07:29 <rmk0> elect: i'm not sure anyone knows what vulkan will require by default, but both opengl and directx have the notion of minimum supported values (minimum of 16 available texture units in the fragment shader, minimum of 8 render targets, etc)
20160129 14:07:34 <rmk0> i don't see vulkan being any different
20160129 14:07:34 <elect> each abstraction requires some knowledge and some time to spend before you can really get it and make it yours
20160129 14:08:25 <rmk0> i've been fighting opengl for about seven years now
20160129 14:08:39 <rmk0> there's not a day that goes by where i feel like the API is on my side at all
20160129 14:08:52 <elect> :p
20160129 14:09:02 <rmk0> it's pretty much engineered to be immune to any approach taken to enforce correctness
20160129 14:09:22 <rmk0> it's like global mutable state that can't even be observed is a bad idea
20160129 14:10:10 <rmk0> it's not really any wonder that people don't write composable opengl libraries. you either get an entire engine or nothing, because there's no way for those libraries to interoperate without smashing each other's state
20160129 14:11:55 <rmk0> it would be fine if gpu hardware *actually worked this way*, but all of this stuff that's causing these problems is entirely an artificial invention made by a committee
20160129 14:14:09 <elect> well, I hope vulkan will solve the problems you say
20160129 14:15:56 <rmk0> even if it brings a lot of new problems, just doing none of the things that opengl does will be an improvement
20160129 14:16:12 <elect> :D
20160129 14:16:24 <rmk0> it'll be a case of dealing with a problem that's actually difficult, as opposed to trying to work against a faulty abstraction
20160129 14:16:32 <elect> we'll catch us up again in few months and you'll tell me
20160129 14:16:46 <rmk0> i doubt i'll have vulkan by then (._.)
20160129 14:17:22 <rmk0> i have to buy all new hardware late this year
20160129 14:18:22 <elect> rumors say at least GL 4.3
20160129 14:18:25 <elect> do you have it?
20160129 14:18:29 <rmk0> nope
20160129 14:18:39 <rmk0> all my hardware is from the 3.3 era
20160129 14:18:46 <rmk0> roughly five years old
20160129 14:33:28 <zubzub> the third epos of the third era
20160129 14:38:40 <rmk0> "somebody stop this thing!"
20160129 16:38:50 <Eclesia> rmk0: we should revive the 3dfx Glide API :D
20160129 16:39:06 <Eclesia> "voodoo returns"
20160129 16:39:35 * rmk0 emits sparks
20160129 17:02:00 * Eclesia (~husky@anon) has left #jogamp
20160129 17:43:49 * spaceemotion (~spaceemot@anon) has joined #jogamp
20160129 17:55:26 * elect (~GBarbieri@anon) Quit (Ping timeout: 240 seconds)
20160129 19:13:45 * spaceemotion (~spaceemot@anon) Quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
20160129 19:36:21 * hija (~hija@anon) Quit (Quit: hija)
20160129 19:48:56 * spaceemotion (~spaceemot@anon) has joined #jogamp
20160129 19:49:19 * spaceemotion (~spaceemot@anon) Quit (Client Quit)
20160129 20:11:03 * hija (~hija@anon) has joined #jogamp
20160129 20:41:55 * Eclesia (~eclesia@anon) has joined #jogamp
20160129 21:15:39 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20160129 22:00:06 * elect (~elect@anon) has joined #jogamp
20160129 22:13:55 * elect (~elect@anon) Quit (Ping timeout: 260 seconds)
20160129 22:19:53 * philjord (599cc172@anon) has left #jogamp
20160129 22:22:00 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20160129 23:59:15 * hija_ (~hija@anon) has joined #jogamp
20160129 23:59:56 * hija (~hija@anon) Quit (Ping timeout: 240 seconds)
20160129 23:59:56 * hija_ is now known as hija
20160130 00:04:07 * hija (~hija@anon) Quit (Client Quit)
20160130 05:05:21 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20160130050521.html