#jogamp @ irc.freenode.net - 20150113 05:05:06 (UTC)

20150113 05:05:06 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20150112050506.html
20150113 05:05:06 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20150113050506.html
20150113 06:43:32 * zzuegg (~zzuegg___@anon) Quit (Ping timeout: 244 seconds)
20150113 06:45:12 * zzuegg (~zzuegg___@anon) has joined #jogamp
20150113 07:49:31 * monsieur_max (~maxime@anon) has joined #jogamp
20150113 08:27:44 * eclesia (~husky@anon) has joined #jogamp
20150113 08:27:52 <eclesia> hi
20150113 08:41:14 * doev (~doev@anon) has joined #jogamp
20150113 12:32:46 <eclesia> \o/ my first instanced rendering.
20150113 12:35:57 <zubzub> ?
20150113 12:36:21 <eclesia> glDrawElementsInstanced
20150113 12:36:55 <eclesia> to make large numbers of the same object
20150113 12:39:26 <eclesia> zubzub: ok ?
20150113 12:42:43 <rmk0> .o.
20150113 12:46:25 <eclesia> wha would be the best way to send the mat4 for each instance ? use : layout(location = 6) in mat4 l_trs; ? or use a 1D texture ?
20150113 12:46:36 <eclesia> what*
20150113 12:47:47 <rmk0> think it's standard to use a uniform buffer object
20150113 12:48:15 <rmk0> i think using textures in that manner is more for data that can vary across all vertices
20150113 12:53:07 <zubzub> eclesia: don't ask me, I know nothing
20150113 12:55:02 <rmk0> from what i've read on the subject, your uniforms are supplied to each instance in turn by stepping through the uniform buffer object
20150113 12:55:25 <rmk0> in the same way that a vertex shader is supplied with data from each vertex in turn by stepping through a vertex buffer object
20150113 12:55:41 <eclesia> layout are not ubo.
20150113 12:56:19 <rmk0> i'm referring to when you are using one
20150113 12:56:25 <eclesia> I already have a set of uniforms for M,V,P. then I multiply M by a second matrix different for each instance
20150113 12:56:41 <eclesia> my question was on this second matrix
20150113 12:57:41 <rmk0> supplying the matrices from an array buffer as a vertex shader input?
20150113 12:57:55 <rmk0> array buffer/vertex buffer object, whatever
20150113 12:58:04 <eclesia> yes that's what I'm doing
20150113 12:59:02 <rmk0> i'm not sure what the question is... using a UBO is "best" in the sense that it's explicitly intended for what you want to do
20150113 12:59:18 <rmk0> i don't think there's anything wrong with using a vertex buffer object for it other than it's a bit unusual
20150113 12:59:20 <eclesia> but I've seen some tutorial where they put those values in a texture an calculate the offset in the texture using the instanceId
20150113 13:00:16 <rmk0> that sounds borderline abusive
20150113 13:00:32 <eclesia> well it doesnt have the ubo size limit problem
20150113 13:00:43 <rmk0> what problem's that?
20150113 13:01:08 <eclesia> if you render a forest with 10000 trees
20150113 13:01:23 <eclesia> that makes 10000*1664 bytes (mat4)
20150113 13:01:54 <eclesia> 10000*16*4 *
20150113 13:02:30 <eclesia> anyway... time to get back to work ... will continue this evening
20150113 13:02:45 <rmk0> still not sure what limit you're referring to
20150113 13:03:00 <eclesia> memory limit for unigorms
20150113 13:03:06 <rmk0> any kind of buffer object conceptually has a size limit, although the drivers won't tell you what they are
20150113 13:03:07 <eclesia> uniforms*
20150113 13:03:15 <rmk0> textures do have a maximum size as well, which is queryable
20150113 13:03:57 <rmk0> i'm not sure we're talking about the same thing
20150113 13:05:30 <rmk0> in your 10000 trees example, you're exposing the per-instance data to a shader one element at a time
20150113 13:05:50 <rmk0> the only limit i'm aware of is the size limit on the buffer itself... your shader just sees one element of that buffer at a time
20150113 13:06:23 <rmk0> on modern hardware, i'd expect those limits to be large enough that you'd never reach them
20150113 13:08:19 <rmk0> if you were passing some sort of array of 10000 elements to the shader, and then indexing into it to access specific elements
20150113 13:08:32 <rmk0> then you'd have the possibility of reaching the limit on the number of uniforms available
20150113 13:15:26 <eclesia> Quote : 'The size of an UBO is somewhat limited: 64KB for AMD and NVIDIA'
20150113 13:15:43 <eclesia> Quote 'The smallest required UBO size is 16KB'
20150113 13:16:21 <rmk0> where's this coming from?
20150113 13:16:45 <rmk0> because there's no such thing as a UBO... that's just a hint to the driver as to how it'll be used, they're all untyped linear memory underneath
20150113 13:16:48 <eclesia> random forums so far, searching for UBO minim opengl size
20150113 13:16:53 <rmk0> would be like saying there's more than one type of malloc()
20150113 13:17:15 <rmk0> the quote sounds like it came from someone misunderstanding something
20150113 13:17:27 <eclesia> maybe
20150113 13:18:03 <rmk0> there may be some limit that prevents you from passing more than 64kb of data via some specific method
20150113 13:18:35 <rmk0> having a uniform that was a single array that ended up being larger than 64kb would be one
20150113 13:19:12 <rmk0> as i understand it, there's a fixed amount of constant storage space that is used for the values of uniform parameters in the current execution of a shader
20150113 13:19:21 <rmk0> that's probably where the 64kb limit comes from
20150113 13:19:41 <rmk0> UBOs can be vastly larger, but you can't supply more than that fixed limit to a shader for each instance you render
20150113 13:22:26 <rmk0> i think there's some confusion because of the different ways UBOs are used
20150113 13:22:37 <rmk0> some people use them to have one block of storage that's shared between multiple shaders
20150113 13:23:02 <rmk0> some people use them for instanced rendering, where each element of the UBO stores the data for one instance, and the shader doing the rendering is supplied with one element at a time
20150113 13:23:22 <rmk0> you can't use a UBO to supply more data in one step than you could if you'd used a lot of separate non-buffer-backed uniform parameters
20150113 13:25:47 <rmk0> it's confusing and the language is ambiguous
20150113 13:28:32 <eclesia> it could be that, but it's not the first time I read about ubo limits. we should ask sghotel.
20150113 13:41:56 <rmk0> the 3.3 spec seems to support what i've said, but it's not clear
20150113 13:42:27 <rmk0> section 2.11.4
20150113 15:01:26 * doev (~doev@anon) Quit (Remote host closed the connection)
20150113 16:17:20 <zzuegg> afaik you only have to querry GL_MAX_UNIFORM_BLOCK_SIZE to the the size limitation.. the next bigger one would be a shader storage buffer. (minimum required size i thing would be 16mb)
20150113 16:17:51 <zzuegg> and 16k for ubo
20150113 16:19:04 <rmk0> again, i don't think that size has anything to do with the maximum size of the entire UBO
20150113 16:19:36 <rmk0> there is no difference on the gpu between a buffer object that represents a UBO, and one that represents a VBO
20150113 16:20:44 <zzuegg> probably to access them trough a shader there is a limitation... from the specs: "The smallest required UBO size is 16KB; the smallest required SSBO size is 16MB"
20150113 16:21:21 <rmk0> yep
20150113 16:21:37 <rmk0> as i said... there's a limited amount of storage space available for the uniform parameters of a shader
20150113 16:22:08 <rmk0> the size limit corresponds to that... you can only supply at most 64k to one execution
20150113 16:22:32 <zzuegg> ah, so you think that limitation is basically how big my glsl struct can be
20150113 16:23:01 <rmk0> if by struct you mean the "interface" type, then yeah
20150113 16:25:02 <zzuegg> regarding instancing i have seen it used as uniform buffer mat4 matrices[X]; mat4 current=matrices[gl_InstanceId]
20150113 16:25:30 <rmk0> yeah, i think that's the wrong way to do it
20150113 16:25:37 <rmk0> at least, you'll quickly smash into the size limit
20150113 16:26:34 <rmk0> it's possible to tell opengl to step through the elements of a UBO with a stride, the same way it steps through a VBO to provide data for each vertex of a mesh
20150113 16:26:54 <zzuegg> oh did not know that
20150113 16:27:06 <zzuegg> that would be better of course
20150113 16:27:09 <rmk0> i've never done it, but i see it there in the api
20150113 16:32:28 <zzuegg> there is an example how to add per instance VBO's
20150113 16:54:09 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150113 17:02:47 * eclesia (~husky@anon) has left #jogamp
20150113 17:32:18 * monsieur_max (~maxime@anon) has joined #jogamp
20150113 21:23:46 -mquin- [Global Notice] We are about to start rehubbing the network ahead of planned maintenance work. This will cause some netsplits, but should be completed shortly. Thank you for your patience and for flying freenode! :)
20150113 21:32:07 * zzuegg (~zzuegg___@anon) Quit (*.net *.split)
20150113 21:33:44 * zzuegg (~zzuegg___@anon) has joined #jogamp
20150113 21:33:51 * mjacob (~foobar@anon) Quit (*.net *.split)
20150113 21:33:52 * monsieur_max (~maxime@anon) Quit (*.net *.split)
20150113 21:33:53 * jk4 (~jk4@anon) Quit (*.net *.split)
20150113 21:33:53 * rmk0 (~rmk0@anon) Quit (*.net *.split)
20150113 21:33:53 * odin_ (~Odin@anon) Quit (*.net *.split)
20150113 21:33:53 * xranby (~xranby@anon) Quit (*.net *.split)
20150113 21:33:54 * bruce- (~x@anon) Quit (*.net *.split)
20150113 21:33:54 * zubzub (~zubzub@anon) Quit (*.net *.split)
20150113 21:34:50 * monsieur_max (~maxime@anon) has joined #jogamp
20150113 21:34:50 * jk4 (~jk4@anon) has joined #jogamp
20150113 21:34:50 * rmk0 (~rmk0@anon) has joined #jogamp
20150113 21:34:50 * xranby (~xranby@anon) has joined #jogamp
20150113 21:34:50 * bruce- (~x@anon) has joined #jogamp
20150113 21:34:50 * mjacob (~foobar@anon) has joined #jogamp
20150113 21:34:50 * odin_ (~Odin@anon) has joined #jogamp
20150113 21:34:50 * zubzub (~zubzub@anon) has joined #jogamp
20150113 21:44:09 * mjacob (~foobar@anon) Quit (*.net *.split)
20150113 21:50:36 * mjacob (~foobar@anon) has joined #jogamp
20150113 21:50:41 <rmk0> turns out what i was thinking of earlier was this:
20150113 21:50:41 <rmk0> https://www.opengl.org/wiki/Vertex_Specification#Instanced_arrays
20150113 21:53:11 * jk4 (~jk4@anon) Quit (*.net *.split)
20150113 21:53:11 * rmk0 (~rmk0@anon) Quit (*.net *.split)
20150113 21:53:52 * jk4 (~jk4@anon) has joined #jogamp
20150113 21:53:52 * rmk0 (~rmk0@anon) has joined #jogamp
20150113 21:54:08 * odin_ (~Odin@anon) Quit (*.net *.split)
20150113 21:54:38 * odin_ (~Odin@anon) has joined #jogamp
20150113 21:54:52 * xranby (~xranby@anon) Quit (*.net *.split)
20150113 21:54:52 * bruce- (~x@anon) Quit (*.net *.split)
20150113 21:54:52 * zubzub (~zubzub@anon) Quit (*.net *.split)
20150113 21:55:38 * zzuegg (~zzuegg___@anon) Quit (Remote host closed the connection)
20150113 21:59:29 * xranby (~xranby@anon) has joined #jogamp
20150113 21:59:29 * bruce- (~x@anon) has joined #jogamp
20150113 21:59:29 * zubzub (~zubzub@anon) has joined #jogamp
20150113 22:00:39 * zzuegg (~zzuegg@anon) has joined #jogamp
20150113 22:02:17 * mjacob (~foobar@anon) Quit (*.net *.split)
20150113 22:06:17 * mjacob (~foobar@anon) has joined #jogamp
20150113 22:14:55 -mquin- [Global Notice] And we are done, thanks for bearing with us. There will be a services outage at around 0000 UTC (just under two hours from this notice) which is expected to last between 15 and 30 minutes.
20150113 22:17:58 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150113 22:20:05 * zzuegg (~zzuegg@anon) Quit (Quit: Nettalk6 - www.ntalk.de)
20150113 22:34:48 * zzuegg (~zzuegg@anon) has joined #jogamp
20150114 02:18:35 * zzuegg (~zzuegg@anon) Quit (Quit: Nettalk6 - www.ntalk.de)
20150114 03:17:09 * mjacob (~foobar@anon) Quit (Ping timeout: 244 seconds)
20150114 03:17:27 * mjacob (~foobar@anon) has joined #jogamp
20150114 05:05:06 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20150114050506.html