| 06:06.14 | *** join/#bzflag infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 06:06.14 | *** topic/#bzflag is https://BZFlag.org || https://www.openhub.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || Current version: 2.4.18 || New shiny website! https://forums.bzflag.org/viewtopic.php?f=8&t=20201 |
| 06:06.14 | *** mode/#bzflag [+v infobot] by ChanServ |
| 06:45.11 | macsforme | tupone: do you have a feeling for how much of an issue it is for VBO memory having to be reallocated? |
| 06:46.15 | macsforme | I know we had a lot of stuff that was in display lists already, so I imagine data like that would be easy to transition to a persistent VBO, whereas we also have a lot of stuff assembled on-the-fly which might not be so easy |
| 07:18.14 | tupone | The world objects are not going to be reallocated or changed at all |
| 07:18.52 | tupone | only for the radar but I did a shader that preserve the radar objects (color is computed in the shader) |
| 07:20.03 | tupone | In my PR the things written in the initVBO are "statically allocated". The initVBO is only called when GL context is destroyed and recreated |
| 07:22.33 | macsforme | okay |
| 07:22.51 | tupone | Also the tank models will be preserved and redraw with different Matrix |
| 07:22.52 | macsforme | so why is it necessary to keep a list of free VBOs and allocated VBOs? |
| 07:24.10 | BZNotify | bzflag: 03macsforme commented on pull request #227 "Enable dithering always" by 03atupone (06https://git.io/JeQdY): > tupone: as for the dithering in bzflag, it was disabled when draw... |
| 07:25.41 | macsforme | meaning, what is the purpose of this: https://github.com/atupone/bzflag/blob/VBO/include/VBO_Handler.h#L51-L57 |
| 07:26.00 | tupone | If I have only dynamic object I would not need to trace memory, maybe I could have used a simple stack approach |
| 07:28.33 | tupone | If I have static object to draw I need to know where they are, I need to free them when I change server, where to get memory for dynamic things ... |
| 07:29.23 | macsforme | why can't each object that needs to be drawn have its own VBO? |
| 07:29.28 | tupone | If the object where in the "CPU" memory I could have used new and delete. |
| 07:29.59 | tupone | Too much VBO switching is an answer |
| 07:30.33 | tupone | dynamic memory allocation on the GPU |
| 07:30.38 | macsforme | and why is that a problem? |
| 07:32.21 | tupone | Saving GPU time |
| 07:33.16 | macsforme | did you actually measure an impact? |
| 07:34.46 | macsforme | I can understand that we don't want to change state unnecessarily, so we bind a VBO ideally once per frame, use it, then move onto the next |
| 07:34.48 | tupone | I did not. I read https://www.khronos.org/opengl/wiki/Vertex_Specification_Best_Practices |
| 07:35.37 | macsforme | but I doubt there is a performance loss from rebinding even 20-30 different VBOs each frame |
| 07:35.38 | tupone | you will have about 400 VBO or more for a simple world |
| 07:36.37 | tupone | the models for a tank are about 8 and you need to draw them for each tank |
| 07:36.52 | tupone | you have shot |
| 07:37.09 | macsforme | well, some things could be grouped together... for example, I could see all world geometry being together in one buffer |
| 07:37.09 | tupone | you have the world object |
| 07:37.25 | tupone | the menu |
| 07:37.29 | tupone | the radar |
| 07:37.30 | macsforme | tank pieces could all be grouped together in one buffer as well... they are the same kind of geometry |
| 07:37.43 | tupone | when they explode they are not |
| 07:38.45 | macsforme | I didn't mean they have to be drawn in one call... you can store them in one buffer, and then render pieces individually by using an offset and a primitive count |
| 07:41.07 | macsforme | for example, store the tank body, then the treads, then the turret, the barrel, etc., consecutively in one buffer, and track the offsets for when we need to draw each piece |
| 07:42.20 | tupone | The memory allocation that I did is already doing that |
| 07:42.51 | tupone | and it is not that complex |
| 07:43.28 | tupone | even with that approach you need to have a facility to rebuild your VBO when needed |
| 07:45.00 | tupone | and I have created vboVTN .... but one could create its own if you want to have "your" VBOs |
| 07:46.02 | macsforme | we were already re-building display lists when the context is re-created... so yes, we need that logic, and to extend it to everything that uses a VBO |
| 07:46.45 | tupone | But all object to draw will use VBO in the future |
| 07:47.03 | tupone | there will be no other way |
| 07:47.13 | macsforme | yes |
| 07:48.57 | tupone | Why I say you can create you own VBO? When I write to a VBO the CPU wait for it to be not in use |
| 07:50.00 | tupone | I don't know if all the driver wait for all the VBO to be unused, or only the interested portion |
| 07:51.54 | macsforme | writing to a VBO should generally be rare while playing |
| 07:52.56 | macsforme | I think we'll still want to stream a few things, like the flag waving |
| 07:53.54 | macsforme | maybe I still don't understand your design |
| 07:54.18 | macsforme | in std::list<MemElement> alloVBOList, how many elements do you expect? |
| 07:55.05 | tupone | One for each request. For instance for for each piece of a tank |
| 07:55.15 | tupone | s/for/one/ |
| 07:56.08 | macsforme | will some vboIndex within that list be shared, or each unique? |
| 07:56.38 | tupone | all the vboIndex are unique for buffer |
| 07:57.14 | tupone | it is going to trace, for instance, where the piece of the tank model will start |
| 07:57.43 | macsforme | and a vboIndex is a buffer name returned by glGenBuffers(), or something else? |
| 07:58.04 | tupone | no, only the offset from the start of the buffer |
| 07:58.59 | macsforme | okay, so each VBO_Hander gets one VBO name from GL? |
| 07:59.38 | tupone | yes or three |
| 07:59.46 | tupone | <PROTECTED> |
| 07:59.46 | tupone | <PROTECTED> |
| 07:59.46 | tupone | <PROTECTED> |
| 07:59.48 | tupone | <PROTECTED> |
| 08:00.10 | tupone | this is the usage of vboIndex in a rendering call |
| 08:00.31 | tupone | the enable Arrays will bind the correct buffer |
| 08:00.49 | tupone | vboVT.enableArrays(); |
| 08:04.17 | macsforme | is there only one instance of VBO_Handler per combination needed (e.g., V + N + T, V + N, etc.)? |
| 08:05.09 | tupone | yes, I did that to save space (on the GPU) but you are free to create other if you need |
| 08:07.36 | tupone | for instance truely permanent object, that are used a lot during drawing could use their own VBO_Handler to avoid freezing the renderloop when other are updating. Still not done in my GL2.0 porting. I have only those |
| 08:09.39 | macsforme | yes, that is a problem inherent to this design (of putting so much vertex data together) |
| 08:10.57 | tupone | This design allows to put things together easily, Do not force you to put all things together |
| 08:15.03 | macsforme | so when you call the VBO_Handler constructor you tell it how much memory to reserve on the GPU? |
| 08:17.40 | macsforme | or rather, how many elements, and then init() will calculate how much memory, and actually allocate the buffers? |
| 08:27.09 | macsforme | okay, I think I'm starting to grasp it |
| 08:28.32 | tupone | ok. more question later :) |
| 08:28.35 | macsforme | I am still curious though how you calculate that a simple world will result in 400+ VBOs without this design |
| 08:28.53 | macsforme | I will sleep on it |
| 08:29.20 | tupone | with one vbo for rendering call |
| 10:05.20 | *** join/#bzflag brlcad (~sean@104.225.5.10) |
| 10:05.25 | *** join/#bzflag blast007 (~blast007@bzflag/developer/Blast) |
| 10:10.32 | *** join/#bzflag joevano (~joevano@bzflag/developer/JoeVano) |
| 10:10.32 | *** mode/#bzflag [+v joevano] by ChanServ |
| 10:40.38 | *** join/#bzflag Foo_man_choo (~spldart@c-73-155-11-165.hsd1.tx.comcast.net) |
| 11:03.28 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 16:01.18 | *** join/#bzflag WhatsUpDanger (0ca73d02@gateway/web/cgi-irc/kiwiirc.com/ip.12.167.61.2) |
| 17:17.41 | *** join/#bzflag _I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 17:32.09 | BZNotify | bzflag: 03atupone commented on pull request #227 "Enable dithering always" (06https://git.io/Je7tI): Dithering is a (mostly) noop when using a 24 bits color buffer.... |
| 20:39.14 | *** join/#bzflag WhatsUpDanger29 (0ca73d02@gateway/web/cgi-irc/kiwiirc.com/ip.12.167.61.2) |
| 21:03.18 | BZNotify | bzflag: 03The-Noah 03opened issue #234 "Radar and control panel performance" (06https://git.io/Je7OV) |
| 21:08.45 | blast007 | The_Noah: Include what operating system and graphics card/driver you are using please. I also saw dramatic FPS differences, with an AMD RX 570 on Debian. |
| 21:12.35 | allejo | I think that issue alone justifies us nuking the radar entirely |
| 21:12.36 | allejo | :p |
| 21:15.21 | tupone | I wonder what is the performance with my GL2.0 branch. Only 1 radar type, but done with shaders |
| 21:15.56 | blast007 | tupone: I haven't tried that branch in a while |
| 21:16.31 | tupone | No change lately in the branch, but radar color is computed directly on the shader |
| 21:17.15 | tupone | All the world reside in a GL buffers, tanks and shot still dynamic |
| 21:20.41 | tupone | without the shader everything change frame by frame for the color is changing depending on the height |
| 21:59.45 | BZNotify | bzflag: 03atupone 11synchronized pull request #232 "Vertex buffers object handling" (06https://git.io/Je9kl) |
| 22:35.04 | BZNotify | bzflag: 03The-Noah edited issue #234 "Radar and control panel performance" (06https://git.io/Je7OV) |
| 22:42.06 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 23:46.12 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |