#jogamp @ irc.freenode.net - 20160107 05:05:15 (UTC)


20160107 05:05:15 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20160106050515.html
20160107 05:05:15 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20160107050515.html
20160107 05:43:02 * monsieur_max (~maxime@anon) has joined #jogamp
20160107 07:16:57 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20160107 07:50:49 * philjord2 (599cc172@anon) has joined #jogamp
20160107 07:53:43 * elect (~GBarbieri@anon) has joined #jogamp
20160107 08:10:56 * jvanek (jvanek@anon) has joined #jogamp
20160107 08:21:48 * monsieur_max (~maxime@anon) has joined #jogamp
20160107 08:32:00 * Eclesia (~husky@anon) has joined #jogamp
20160107 08:32:49 <Eclesia> good morning
20160107 09:21:46 <bruce-> hi Eclesia
20160107 09:22:36 <bruce-> Eclesia: have you seen http://wdobbie.com/post/gpu-text-rendering-with-vector-textures/ ?
20160107 09:24:44 <Eclesia> thanks nice link
20160107 09:25:04 <monsieur_max> bruce-: thanks for the link
20160107 10:51:36 <rmk0> .o.
20160107 10:54:54 <rmk0> had a discussion with some mildly friendly people in #opengl
20160107 10:55:09 <rmk0> they recommend not precomputing modelview matrices for instancing
20160107 10:55:54 <rmk0> even if you pass in separate model and view matrices, and those matrices are multiplied for every vertex, it's still going to be faster than precomputing and uploading tens of thousands of matrices CPU side
20160107 10:56:06 <rmk0> so that solves that problem
20160107 10:59:15 <zubzub> 21:48 < zubzub> why do the multiplications in the cpu?
20160107 10:59:15 <zubzub> 21:48 < zubzub> is it possible to delay it and do it in the gpu?
20160107 10:59:15 <zubzub> 21:49 < zubzub> afaik that's what gpu's are good for no?
20160107 10:59:31 <zubzub> https://s-media-cache-ak0.pinimg.com/736x/46/30/eb/4630eb09bf82a7db7670b947faf82f2e.jpg
20160107 10:59:48 <zubzub> ;)
20160107 11:07:58 <rmk0> zubzub: i didn't dispute it!
20160107 11:08:33 <rmk0> it's just a rather large constant term to eliminate...
20160107 11:09:04 <rmk0> you have k instances, each with n vertices. you end up performing (k * n) matrix multiplications when you only need to do k
20160107 11:09:53 <rmk0> it doesn't help that every example you'll find online regarding instancing will precompute the matrices
20160107 11:10:04 <elect> you should profile
20160107 11:10:17 <elect> it's the only way
20160107 11:10:24 <rmk0> i agree... don't actually have much in the way of profiling tools for opengl though
20160107 11:10:52 <elect> you may want to measure the time
20160107 11:11:07 <elect> warm up and get the average frame time
20160107 11:11:31 <elect> brb
20160107 11:11:55 <rmk0> this would be a perfectly rational optimization if essentially magical vector processing hardware wasn't available
20160107 11:12:19 <rmk0> i'll pass in the model matrices and not say anything more about it
20160107 11:13:29 <rmk0> vaguely curious how well other java matrix packages do with 4x4 multiplications
20160107 11:25:04 <zubzub> rmk0: lot of benchmarks of that on google
20160107 11:26:18 <rmk0> most likely
20160107 11:26:52 * philjord2 (599cc172@anon) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
20160107 11:39:33 <elect> keep us updated, rmk0
20160107 11:39:42 <elect> is it closed or open?
20160107 11:41:17 <rmk0> always open
20160107 12:35:43 * philjord (599cc172@anon) has joined #jogamp
20160107 12:35:43 * philjord2 (599cc172@anon) has joined #jogamp
20160107 12:38:49 * philjord (599cc172@anon) has left #jogamp
20160107 12:39:50 * philjord2 is now known as philjord3
20160107 12:42:10 * philjord3 (599cc172@anon) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
20160107 12:51:24 * diamondm1n (~diamondma@anon) Quit (Remote host closed the connection)
20160107 14:01:09 * guillaum1_mobile (~androirc@anon) has joined #jogamp
20160107 14:01:22 * guillaum1_mobile (~androirc@anon) Quit (Client Quit)
20160107 14:17:23 <rmk0> hm... i've been looking again at the situation with direct buffers
20160107 14:17:41 <monsieur_max> what situation ?
20160107 14:19:12 <rmk0> i remember being under the impression that buffers passed to JOGL had to be direct
20160107 14:19:23 <rmk0> i... now see no evidence of this!
20160107 14:19:46 <rmk0> i just stepped through the execution of glBufferData with a direct and a heap-allocated buffer, and both work and both take the same path through the code
20160107 14:20:08 <rmk0> Eclesia actually mentioned a while back that i'd said they had to be direct, and now i can't find any reason i ever thought that
20160107 14:20:37 <rmk0> older versions of LWJGL did have that restriction, maybe i mixed them up?
20160107 14:21:16 <bruce-> Use com.jogamp.common.nio.Buffers to create any NIO buffer intented to be used by JOGL in order to avoid native ordering and size problems. Jogl does not modify the position of a buffer passed to its methods but such a position affects its behaviour. Direct NIO buffers are faster and should be used when performances are important. Indirect NIO buffers can be used for non critical operations, for example to retrieve the value of an OpenGL constant. Keep in mind t
20160107 14:21:37 <bruce-> https://jogamp.org/jogl/doc/userguide/
20160107 14:21:45 <rmk0> "Direct NIO buffers are faster" ... i think that needs a citation
20160107 14:21:57 <rmk0> reading from them is certainly slower
20160107 14:22:03 <rmk0> writing seems no faster
20160107 14:22:58 <rmk0> of course i've only seen as far as the native code boundary...
20160107 14:23:05 <rmk0> in JOGL, that is
20160107 14:23:51 <rmk0> are there numbers comparing heap/direct buffers somewhere?
20160107 14:26:58 <elect> from my past researched
20160107 14:26:58 <elect> s
20160107 14:27:06 <elect> direct are faster to read/write
20160107 14:27:13 <elect> but slower to allocate/deallocate
20160107 14:27:25 <elect> therefore they should be used only with >1/2gb
20160107 14:27:39 <elect> but I never tested by myself
20160107 14:27:51 <rmk0> i do see projects like mapdb using 1gb direct buffers
20160107 14:28:13 <monsieur_max> <3 mapdb
20160107 14:31:15 <elect> btw, the fastest seems to be the off heap via unsafe
20160107 14:32:25 <rmk0> slight problem in that jogl only accepts values of type Buffer
20160107 14:32:37 <elect> ah, yeah
20160107 14:32:40 <elect> ^^
20160107 14:33:01 <elect> what are you working on, rmk0
20160107 14:33:20 <rmk0> instancing for a deferred renderer
20160107 14:33:46 <rmk0> looking at various representations for the data
20160107 14:34:15 <elect> cool
20160107 14:34:25 <elect> representations in memory you mean?
20160107 14:34:36 <elect> which scene are you using ?
20160107 14:35:15 <rmk0> yeah
20160107 14:35:17 <rmk0> .. scene?
20160107 14:35:58 <elect> what are you rendering as test?
20160107 14:36:10 <rmk0> oh, just a random assortment of blender models
20160107 14:36:24 <rmk0> the model data itself isn't important
20160107 14:36:25 <elect> you may want to take a look here https://github.com/nvpro-pipeline/pipeline
20160107 14:36:49 <elect> particularly interesting are the link in the readme
20160107 14:44:12 <elect> I am also looking for a fast and efficient data graph/tree representation
20160107 14:44:33 <rmk0> what i'm writing is lower level than this, i have no scene graph
20160107 14:44:51 <elect> flat list?
20160107 14:45:09 <rmk0> sort of... primitive maps, etc
20160107 14:45:11 <rmk0> the renderer only sees what's visible this frame
20160107 14:45:27 <rmk0> visibility, culling, etc, are expected to be handled by whatever is handing batches to the renderer
20160107 14:46:35 <elect> how do you propage them?
20160107 14:46:42 <elect> *propagate/forward
20160107 14:47:01 <rmk0> not sure what you mean
20160107 14:47:32 <elect> i mean, how do you establish for example which object is visible and which not
20160107 14:47:43 <bruce-> 3pwd
20160107 14:47:44 <elect> and how do you save inside each single mesh?
20160107 14:47:48 <bruce-> oops
20160107 14:48:17 <rmk0> well that's intended to be handled by the caller, as i said. in practice, i would use an octree
20160107 14:49:39 <rmk0> stick things into an octtree once per frame, test the contents of the octtree against a frustum representing the camera, tell the renderer about all objects overlapping the frustum
20160107 14:52:16 <rmk0> i'm using the primitive collections from http://fastutil.di.unimi.it/ to avoid boxing
20160107 14:55:31 <elect> koloboke should be the fastest
20160107 14:56:59 <elect> if I recall properly
20160107 14:59:08 <elect> http://java-performance.info/hashmap-overview-jdk-fastutil-goldman-sachs-hppc-koloboke-trove-january-2015/
20160107 14:59:40 <elect> it seems the 6.6.0 update gave fastutil a huge boost
20160107 15:00:43 <rmk0> there's very little in it, they're all more than fast enough
20160107 15:00:52 <rmk0> it basically came down to fastutil having more combinations of types and data structures
20160107 15:01:22 <rmk0> the main thing is having the right types and avoiding boxing
20160107 15:52:44 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20160107 16:40:00 * elect (~GBarbieri@anon) Quit (Ping timeout: 260 seconds)
20160107 16:54:18 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20160107 17:04:02 * Eclesia (~husky@anon) has left #jogamp
20160107 17:44:42 * monsieur_max (~maxime@anon) has joined #jogamp
20160107 19:54:32 * guillaum1 (~gl@anon) Quit (Ping timeout: 246 seconds)
20160107 20:03:23 * berdon (6003dbdf@anon) has joined #jogamp
20160107 20:03:32 <berdon> Anyone around?
20160107 20:09:47 * guillaum1 (~gl@anon) has joined #jogamp
20160107 21:01:49 * guillaum1 (~gl@anon) Quit (Ping timeout: 245 seconds)
20160107 21:02:13 * philjord (599cc172@anon) has joined #jogamp
20160107 21:08:30 * philjord (599cc172@anon) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
20160107 21:16:48 * guillaum1 (~gl@anon) has joined #jogamp
20160107 21:39:18 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20160107 22:49:29 * berdon (6003dbdf@anon) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
20160107 23:13:07 * berdon (04236963@anon) has joined #jogamp
20160107 23:46:25 * berdon (04236963@anon) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
20160108 05:05:15 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20160108050515.html