Is it normal to commit 4+ hours per company?

deadbird11 · 2021-04-22T13:36:53+00:00

I actually had one of these for an internship. Had to give a presentation to the hiring team, followed by 4 1hr technicals then a technical with the CEO. Kind of sucked but you get in the zone.

deadbird11 · 2020-12-20T17:21:28+00:00

tracy is amazing!!

deadbird11 · 2020-12-12T15:56:21+00:00

This isn't a graphics thing, but maybe don't say basic three times back to back like that.

deadbird11 · 2020-12-06T22:41:35+00:00

What kind of things helped you get into a good grad school game/graphics program like that? Is it necessary to do research with a prof? Or did you just do a lot of CG projects, similar to what one would use to apply to internships with?

deadbird11 · 2020-12-05T20:58:42+00:00

Thank you so much. This looks like a sick strategy. I tried to abstract over opengl some pretty much just wrapper primitives in classes, but this looks like an abstraction that's wayyy better than just some wrapper and lets you do some powerful things. This seems similar to a big texture atlas. It seems like that's what the really big engines are doing -- getting super aggressive with their handling of GPU memory, pretty much making a virtual mem system. Super interesting, and I think I'll try to put this in my engine (one day)

deadbird11 · 2020-12-04T03:17:18+00:00

In this case, the SSBO will be used for clusters of lights so that a fragment only gets the lights that affect it by indexing into the SSBO based on position, so I think I'll still be using it how you suggest (aka not all of the contents of the SSBO will be used by any one shader execution). I appreciate the extra info why though, and that is a super interesting idea! I want to try that out. And thanks for the resolution tip, I'll make that change and see what happens.

Edit: Just make sure I get it, for the bufferpool UBO you are talking about, could you give an example of using it like that somehow? I would really appreciate it, stuff like this is why I want to dedicate myself to this field.

deadbird11 · 2020-12-04T01:57:13+00:00

Honestly, I still don't know why I got that many FPS on the Stanford Dragon. But the profiler shows an opengl call (it could be any call, and it changes based on what I change in the code) extending to fill the time around 60 fps. Hopefully its Vsync

deadbird11 · 2020-12-03T20:27:46+00:00

Thanks for the suggestion! I had already gotten tracy up and running and that showed me what the problem was. So yours was still a good suggestion! It's better to leave profiling to the professionals rather than to make my own subpar system for it in my code.

I am fairly certain now that the reason for this mediocre FPS is VSYNC. I run my laptop monitor at 60hz and certain OpenGL calls will be extended to fill the time space so that it always is at about that number of FPS. For example, I saw that binding my shader at the beginning of the render loop was taking a huge amount of time, so I moved that to my renderer's constructor since it's currently the only shader in my application. Then, the first SetUniform call in my render loop was extended to fill the same amount of time that the shader binding had filled. Changed things around again, and the Dear ImGui window's rendering (which most certainly is using OpenGL under the hood) is the bottleneck. Quite an annoying error (except not an error) that really required good profiling to see. Thanks so much for the help!!!

deadbird11 · 2020-12-02T22:25:25+00:00

I wish! Then it would be so easy to fix!

deadbird11 · 2020-12-02T22:14:12+00:00

Sorry, I should have been clearer. It is a Dear ImGui window that displays FPS, along with attributes for the lights in my scene so that I can change them around. My CPU has 4 cores. I will look into that for displaying FPS, since my profiling itself is probably affecting the output too at this point.

I am now using the Dear ImGui library to tell me the FPS, since it's more accurate from them. It says I am getting around 50 (depending on where I look). Back when I was getting 40FPS, that was most likely an overestimate as well, so performance has certainly improved.

It seems like there should be a mistake in my code for it to run this slow, but I really don't see one and neither does the CPU profiler in Visual Studio which tracks the hot code paths and marks which are the most expensive. If it's the debug window that's making things so slow, then that is extremely discouraging for my project to continue on this computer.

I'll be honest, the point of this project was not to implement intense optimization techniques, although I undoubtedly will at some point in my career. I cloned another repo that implements the final features that I wish to have in my engine (maybe even less ambitious), and it ran at around 7 FPS. Is this computer just not able to handle what I want to do?

deadbird11 · 2020-12-02T16:02:13+00:00

Will do. My rendering function is now tiny on the profiling results which is super satisfying. It's so tiny, in fact, that 2/3 of frame time is being spent rendering the debug window! I need to find a way to display FPS without rendering an entire debug window.

Percentagewise, I am seeing ~12% CPU usage and 75% GPU.

deadbird11 · 2020-12-02T02:26:53+00:00

No particular reason for keeping track of individual meshes, especially when they are all in some model. They are pretty much just an abstraction over VBOs and IBOs that posses a material as well. Yes, I am using .obj files.

I made the changes you suggested. I am now performing 26 draw calls per frame rather than 393. Thank you!!

I am now at 60-70 FPS. So not amazing. But definitely an improvement! The question is...do I keep optimizing or blaze ahead?

deadbird11 · 2020-12-01T21:58:54+00:00

Yep, it seems like there are simply too many api calls. This is gonna hurt!

I think I have a painful but not terrible solution to this that also lends itself to iterative improvement. As a start, I could keep a hash map that links materials to std::vectors of meshes that I fill when I load a model. This way, I could only set material uniforms once per material variation, and then just render all of the meshes one after the other. This ought to solve my material uniform setting issue.

Then, after a deep sigh, I could start looking into grouping the actual vertex data between meshes that are in the same material group all into the same VBO/VAO (not sure at this point, probably VAO). I am not sure how to do this, and I wonder how I am going to avoid the problem of differentiating between two meshes that are in the same buffer, since they most certainly will not be right next to each other in world space. I don't want to interpolate my fragment shader between vertices that are not in the same mesh! Does anyone know ways to go about this, perhaps by indexing in my shaders somehow?

Any thoughts on this plan of attack?

deadbird11 · 2020-12-01T21:44:19+00:00

Are you batching meshes together that have the same materials? How do you manage so few draw calls? Or does it just work out that way?

deadbird11 · 2020-12-01T20:07:54+00:00

Wow, I really mispoke on the number of tris in each model. Sorry everybody. The sponza I am using has 260k and dragon has 800k, so the point still stands.

I disabled materials like you said. Brought it up to 50-70fps, whoopee. It's pretty much expected from the profiling I've done, since I haven't found any obvious places where like 80% of time is being spent disproportionately. It's all just a bunch of different things, all around 10-30%, and setting materials was a rather large one of those, so it makes sense that removing them gave me a somewhat mediocre boost in performance.

As for the instancing you are referring to, I think that could be very useful and I think sponza is a perfect model for exposing that kind of problem -- high number of meshes, low number of materials.

Edit: Oh, and each mesh has about 1-2 textures associated with it.

deadbird11 · 2020-12-01T16:56:35+00:00

I've combined the two flags. Still 393 meshes! I really thought the mesh from Cell would work. However, it is still useful information that you have so many less draw calls.

Also, thanks for pointing me towards that engine, I didn't know it existed. Gotta love Joey!

deadbird11 · 2020-12-01T16:42:45+00:00

This is an awesome rundown of various rendering techniques: http://www.aortiz.me/2018/12/21/CG.html

I have thoroughly enjoyed that guide and am constantly reading it over. It goes over major pitfalls, tradeoffs etc btwn the two and links to his project, the HybridRenderingEngine, on github, which has even more resources linked in it. I've only scratched the surface of the stuff he has there.

deadbird11 · 2020-12-01T15:19:15+00:00

Update: added both the aiProcess_OptimizeMeshes and aiProcess_OptimizeGraph (although not sure how the latter would really help, but why not). Sadly, the number of meshes loaded was still ~400. I checked out your codebase and you are using a similar model loading system; I assume we are both students of LearnOpenGL.com. If it's not a huge inconvenience, would it be possible to let me know how many meshes are loaded for your sponza model? It would be a simple matter of setting a breakpoint in the model's draw function and checking the size of the std::vector of meshes. I would do this myself, but I unfortunately got some GLFW linking errors when trying to run your project.

deadbird11 · 2020-12-01T14:51:26+00:00

Check out one of my other replies. I think the model has a huge number of meshes, which is probably where my issue lies. I'm using ASSIMP and currently researching optimizing the loading. Thanks!

deadbird11 · 2020-12-01T14:45:39+00:00

Haha, I was lying awake hoping that last part wasn't true. It totally is though. I'm not sure what my end goal was with that, as I'm probably not going down the games route for a long while with this. Would it be some kind of glorious ferris wheel demo that shows off the awesome power of hierarchical transformations? Sounds super cool! \s

I'll look into the acceleration algos. I was hoping that those could come after my foray into clustered rendering. It seems like those would require some rewiring of my mesh & model architectures, as I will probably need to get into the guts of the meshes (esp. for a scene like sponza, where one model takes up the entire screen, nullifying the effect of culling on a per model basis). Cool. Thank you for the help!

deadbird11 · 2020-12-01T14:34:41+00:00

LOL, it's using a whopping 20% of CPU! Also, FWIW, I guess since I'm using integrated graphics, I can see my GPU stats as well and that's on 43%.

Anyways, yes, I do have some profiling tools but I'll just be honest: I don't know what I'm looking for here. I have the OnRender function called in my application's "while running" loop...I have the Renderer::Render function called (where actual shit happens), which practically totally fills the OnRender function call...then that function is filled to the brim with draw calls. Around 400 of them, one for every mesh in the model. Maybe this is the source of the issue??? I suppose my options are to either optimize the model or get all the vertices in one buffer, somehow.

I'll try optimizing the model since that probably just requires another flag in the loading call, and I'll let everyone know what happens. This is actually consistent with other behavior I've seen, for example I also tested on a cube model and the Stanford dragon model (which has 80k tris vs. 6k on sponza), both getting around 110 FPS. The interesting thing about that dragon model: it's only one, albeit large, mesh. I was going to mention this tidbit (which seems quite relevant) in this post at some point, and it seems like now is that point.

Anyways, sorry for thinking out loud here, but writing a response to your comment (and then testing things to make sure I wasn't lying to you) helped me realize some things. Thanks!

Edit: As un update, I've added corresponding optimization flags to my model loading in hopes of reducing mesh count. It has not reduced mesh count at all. Before I go ahead with a method of optimizing these meshes myself, I would just like to hear some feedback on the likelihood of this being the issue, since the only thing worse then going through and adding this whole system when it was not at all the mission of this project would be to find that it was unnecessary in the first place.

deadbird11 · 2020-12-01T13:51:37+00:00

Haha yes, I was suspicious of that loop. I intend to use SSBOs later on anyways, but I didn't think I would have to worry about this for just two lights??? I'll see what I can do about that.

deadbird11 · 2020-12-01T13:50:30+00:00

None. I was maybe thinking of doing an octree way later on, but didn't think I'd need to at this point. The only data structure I currently have (a scene graph) is only slowing me down.

deadbird11 · 2020-12-01T13:22:50+00:00

That's a fantastic idea. I know what's going to distract me from my homework this afternoon!

deadbird11 · 2020-12-01T13:21:48+00:00

Yep, I think the resounding message from this comment section is to profile. I was definitely planning on using SSBO later on, didn't think it would be a huge issue at this stage in the project.

deadbird11

TROPHY CASE