| 00:20.05 | *** join/#riftuidev purl (ibot@rikers.org) |
| 00:20.05 | *** topic/#riftuidev is http://pastebin.com for code snippets || PIL: http://www.lua.org/pil || Rift AddOn Policy: http://t.co/7xXd4LL || AddOn Wiki: wiki.riftui.com/ || this channel is logged, via purl || Happy Pi day! |
| 01:39.51 | *** join/#riftuidev seebs (~seebs@24.196.59.174) |
| 01:39.51 | *** mode/#riftuidev [+o seebs] by ChanServ |
| 04:59.56 | *** join/#riftuidev seebs (~seebs@24.196.59.174) |
| 04:59.56 | *** mode/#riftuidev [+o seebs] by ChanServ |
| 07:35.59 | *** join/#riftuidev borbra (~borbra@177.51-175-69.customer.lyse.net) |
| 09:25.40 | *** join/#riftuidev Cairenn (~Owner@MMOI/Administratrix/Cairenn) |
| 09:25.40 | *** mode/#riftuidev [+o Cairenn] by ChanServ |
| 17:29.38 | seebs | oh, hey, @ZorbaBeta: For reasons, I'm doing some UI stuff, not actually in Lua, but I'm sorely tempted to steal the Frames API, do you object to me (1) stealing it, (2) giving you credit for the design? |
| 17:46.59 | ZorbaBeta | go for it :) I've got a mostly-functional C++ version at https://github.com/zorbathut/frames - it's designed to have both a C++ and Lua API |
| 17:47.47 | ZorbaBeta | but fwiw, I think I've come to the conclusion that the most important part of a UI system is that it have a WYSIWYG editor, and that's also a real pain to build |
| 17:49.13 | seebs | I'm currently looking at go. |
| 17:49.23 | seebs | Which, BTW, has rapidly become one of my Favorite Languages. |
| 17:49.40 | ZorbaBeta | I've heard good things about it :) some of my friends really like it |
| 17:50.03 | ZorbaBeta | I'm not a huge fan of the mandatory garbage collector, but I'll acknowledge that this is a lot more important in my line of work than most |
| 17:50.28 | seebs | Yeah. And they're... actually doing pretty well with that, I think. |
| 17:50.52 | ZorbaBeta | looked into Rust? I think it's got similar potential for a slightly different slice of programmers |
| 17:50.54 | seebs | They can't guarantee microsecond-range times, but they are keeping it pretty far into the noise in most code. |
| 17:50.57 | seebs | I haven't yet. |
| 17:51.32 | ZorbaBeta | it's intriguing, and people are actually making real software with it, which is always a good sign |
| 17:53.06 | seebs | I've been poking at making a fractal-drawing thing. |
| 17:53.36 | seebs | Picked a 2D graphics library because I used SDL for a while and hated it. Drew fractal, got ~9fps. Started profiling. I'm now at ~35fps on the same fractal. |
| 17:53.59 | ZorbaBeta | nice :D |
| 17:54.18 | seebs | ... oh, hey. Curious about sense of scale: What kind of polygon counts are you dealing with in a frame? Like, how many vertexes do you actually have to send over to the GPU per frame, as opposed to "sent over a while back, just keep drawing them"? |
| 17:55.02 | ZorbaBeta | it's going to depend strongly on the game. I *think* Rift kept that in the vague region of "less than ten thousand particle vertices, less than ten thousand UI vertices", though I could be wrong on that |
| 17:55.14 | seebs | Huh. |
| 17:55.32 | ZorbaBeta | it's not that bad to send vertices over every frame as long as you're giving the GPU the appropriate flags and performance gimmicks, and as long as you're not doing so in enormous volume |
| 17:55.39 | seebs | FWIW, my fractal-drawing thing is at around 500k vertexes. |
| 17:55.49 | seebs | This could probably be significantly reduced. |
| 17:56.29 | seebs | ... partially because there's an abstraction layer in the middle which wants Triangles Only, so it's not using triangle strips. |
| 17:56.47 | ZorbaBeta | are you using "discard", or whatever the equivalent is, on your buffers? And are your buffers a reasonably tight fit for the number of vertices? |
| 17:56.55 | ZorbaBeta | fwiw, nobody really uses triangle strips anymore :) |
| 17:57.33 | seebs | In my use case, I'm producing, say, 50k line segments, and then each line segment gets drawn as two triangles. So that's 300k vertexes. And with triangle strips it'd be 100,002. |
| 17:57.47 | seebs | And there's some amount of computation being done on every vertex. |
| 17:57.49 | seebs | ... huh |
| 17:57.55 | seebs | that gives me a fascinating idea, though. |
| 17:58.03 | seebs | *thinks* no, wait, nevermind. |
| 17:58.23 | seebs | There's some amount of "apply matrix to vertex" happening, but the matrix can change between batches of vertexes, all of which end up being a single buffer. |
| 17:58.35 | ZorbaBeta | it's honestly not that big of a deal now; that said, you could set up the vertex buffers pregenerated, then just don't touch them again, if you're always generating the same vertex paths |
| 17:58.53 | seebs | And I don't know what a "discard" is, but I think the buffers are pretty much always set to the size of the set of vertexes being loaded into them. |
| 17:59.19 | ZorbaBeta | opengl, directx, or something weird? |
| 17:59.32 | seebs | OpenGL. But I don't really look closely at the lower end. |
| 17:59.41 | seebs | And unfortunately, the set of vertexes changes quite a lot. |
| 17:59.48 | seebs | https://www.github.com/seebs/seebsfrac |
| 18:00.05 | seebs | basically, you know the thing where you have a line with a triangle, and it turns into a snowflake? That. |
| 18:00.18 | seebs | So ANY change will result in >90% of the points changing, pretty much. |
| 18:01.13 | seebs | So all the vertexes move. A lot. |
| 18:01.28 | ZorbaBeta | so, quick primer on GPUs and why they're hiding everything from you: |
| 18:01.51 | ZorbaBeta | back when opengl was created it was a very simple situation where you'd tell the GPU to do something, it would do that thing, and then it would return execution to you |
| 18:01.57 | ZorbaBeta | that hasn't been true for something like twenty years |
| 18:02.24 | ZorbaBeta | now, when you tell the GPU to do something, it queues up the command in a CPU-side buffer; then eventually (possibly an *entire frame* after you've given the command) it gets flushed to the GPU; which, itself, "eventually" gets around to doing it |
| 18:02.50 | ZorbaBeta | but writing to vertex arrays doesn't work like this - it happens instantly, you are in fact writing directly to the GPU memory |
| 18:03.05 | seebs | Ahh. |
| 18:03.18 | ZorbaBeta | so there's a whole ton of smoke and mirrors where you say "let me write to vertex array 4" and the CPU says "uh, shit, we haven't used vertex array 4 yet, uhhh . . . okay, here's vertex array 4.1, we'll clean up vertex array 4 when we're done with it I guess" |
| 18:04.05 | ZorbaBeta | all of which means that writes can turn into allocations, and if you're writing the same vertex array, they will almost *always* turn into allocations. and if your vertex array is far larger than the data you're trying to put into it, that can be ruinously expensive |
| 18:04.39 | seebs | Ahh. |
| 18:04.40 | ZorbaBeta | especially because: imagine you have a megabyte-sized vertex array |
| 18:04.42 | ZorbaBeta | you render it |
| 18:04.48 | ZorbaBeta | then you say "okay, I need to change the first 20 bytes in it" |
| 18:04.48 | seebs | Yeah. That makes sense. |
| 18:04.53 | ZorbaBeta | the GPU doesn't know what you plan to do with the rest of the array |
| 18:04.56 | seebs | Yeah. |
| 18:05.03 | ZorbaBeta | so not only does it need to allocate an entire new array, but it needs to *copy* the old array over |
| 18:05.15 | seebs | In this case, I think it's specifically requesting the right size of array, and then populating the whole thing. |
| 18:05.20 | seebs | Very little updating of partial bits, I think. |
| 18:05.28 | ZorbaBeta | alright, if it's actually updating entire arrays, then this is probably not a huge issue |
| 18:06.09 | ZorbaBeta | if it *is*, then what you'd want to do is write an array from beginning to end - there's a memory-lock flag you can use which means "I don't care about any data besides what I'm looking at" - and then make another special call that tells the GPU "I am done with all the data in this array, you can pretend it's garbage" |
| 18:06.24 | ZorbaBeta | at which point it knows it can allocate a new array but not copy anything over :V |
| 18:06.26 | seebs | Yeah. But there's still a fair amount of copying going on. Which I've gradually optimized. |
| 18:06.30 | seebs | yup. |
| 18:06.45 | seebs | I think that might be what it does? I haven't looked at the actual GL backend stuff, just the stuff that's producing the vertex data arrays. |
| 18:06.52 | ZorbaBeta | btw, all of this stuff is why Vulkan/DX12 are so exciting for programmers. they don't do any of this horrible performance-destroying magic automatically, they just let you know when you can actually clear and reuse a buffer ;) |
| 18:07.04 | seebs | that makes sense. |
| 18:08.33 | seebs | It's been fascinating trying to figure out why some things are much more or less expensive than I expected. |
| 18:09.05 | ZorbaBeta | if you really want to dive into how GPUs work, read https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ - it's a fascinating read, imo, even if you don't have any practical use for it :) |
| 18:09.08 | seebs | Also, I found the COOLEST thing, which is that it turns out to be possible to write an Unproject() for a 3x2 affine matrix that's stunningly simple and much easier than "expand to 3x3, invert". |
| 18:09.24 | seebs | You linked me that once, and I actually did read it, eventually. Probably two years later. |
| 18:09.32 | ZorbaBeta | ah yeah, I seem to recall there's a whole lot of neat matrix tricks |
| 18:09.45 | seebs | it's harder for a 4x3, because the inverse of a 3x3 matrix isn't quite trivial. |
| 18:10.07 | seebs | but it turns out, if the only reason you need the inverse of a matrix is that you want to know what v*(M^-1) is... |
| 18:10.29 | seebs | You can subtract the transform bits from v, and multiply that by the inverse of the other part. |
| 18:10.51 | seebs | So for a 3x2 matrix, that's just multiplying by the inverse of a 2x2 matrix, which is trivial. |
| 18:11.36 | ZorbaBeta | nice :D |
| 18:12.19 | seebs | But yeah, one of my early optimizations was replacing a full 3x3 matrix multiply with the inlined computation of the matrix multiply to project a thing. |
| 18:12.25 | seebs | Because it turns out that's a lot smaller and simpler. |
| 18:12.44 | seebs | And as of this writing, go's compiler will inline "small" functions, but never any function that calls another function. |
| 18:13.50 | ZorbaBeta | huh, interesting |
| 18:13.59 | ZorbaBeta | that's probably fine, most of the time, though |
| 18:14.20 | seebs | Yeah. |
| 18:14.48 | seebs | But it produces weird things. Consider a thing like: normal := v.Rotated(pi/2).Unit().Scaled(x) |
| 18:15.03 | seebs | So, rotate vector, scale to unit size, multiply by x. |
| 18:15.38 | seebs | But Unit() has to find the length, which means it needs to call sqrt/hypot/something. And *without* that, you can inline it, and then the entire line is local math operations and the compiler can spot subexpressions and such. |
| 18:15.57 | seebs | But because it's there, the compiler can't do anything clever to combine operations from the left and right sides of that. |
| 18:16.17 | seebs | ... also it turns out that it's *VERY* good to make a .Normal(vec) that returns { Y, -X } |
| 18:16.27 | ZorbaBeta | <PROTECTED> |
| 18:16.31 | seebs | because the cost of calling Sincos() on a constant value is non-zero. |
| 18:16.54 | seebs | You can in some cases. I have not figured out a remotely practical way to bypass the need to call *something* to get a unit-length vector. |
| 18:16.57 | ZorbaBeta | also, I don't know where your performance is going exactly, but it may be that a few shaders could speed things up a lot. GPUs are really good at doing repetitive things on a lot of data :) |
| 18:17.07 | seebs | I've been thinking about that! |
| 18:17.33 | seebs | At this point, the vector-drawing code, which is all I'm messing with, allows you to change the draw matrix while rendering to it. |
| 18:17.55 | seebs | So every time you draw something, the part you just drew gets the current draw matrix applied to it. And later the entire thing is shoved over to a window or something. |
| 18:18.38 | ZorbaBeta | they might be using the legacy fixed-function pipeline, which would be sad |
| 18:18.43 | seebs | So I can't just say "don't bother multiplying, you can just have the shader do it". |
| 18:18.48 | seebs | I am not sure? |
| 18:19.04 | ZorbaBeta | in any case, shaders are good, learn to love the shader :) |
| 18:19.31 | seebs | yeah. |
| 18:19.53 | seebs | i made a thing in moai once where i used a shader to make vector-graphics things that have glowing effects around them like neon. |
| 18:20.35 | ZorbaBeta | yeah, they're very powerful. I wish more developers were eager to use them |
| 18:25.20 | seebs | which one is "legacy"? If that's glBegin/glEnd, etc, then no. It's vertex buffers, vertex arrays, and shaders. |
| 18:25.39 | ZorbaBeta | ah, excellent - as long as they're always using a vertex and fragment shader, then they're doing it right |
| 18:25.43 | seebs | yup. |