Hi Brian, On Wednesday, 28 February 2018 00:56:36 CET Brian Paul wrote: > On 02/26/2018 11:12 PM, [email protected] wrote: > > From: Mathias Fröhlich <[email protected]> > > > > The buffer_offset is used in aligned_vertex_buffer_offset. > > But now that most of these decisions are done in compile_vertex_list > > we can work on local variables instead of struct members in the > > display list code. Clean that up and remove buffer_offset. > > I presume the optimization I implemented here this still works after > this change.
I have been watching what you did last there. And I have tried carefully to keep that behavior. Well, the major purpose of the bigger series is that the direct OpenGL API user as well as internal users like the dlist and immediate mode code can build up VAOs that already contain just a single buffer object binding and so on. Also to give the mesa layer already a chance to see that there is no change in the vertex arrays. So, what I mention in the cover letter that there sould be more optimization possible is at least one completely unfinalized change that I tried while playing around to check for more optimizations. Means the display list compiler now keeps the VAO's from the previous list. One thing that we can do now is to apply your optimization against the offset of the previous display list VAOs. Means the idea is that a lot of calling code ist compiling the display lists in an order that is also used while execute. That is checking the rest division against the previous VAO's offset instead of the buffer objects start offset is helping much more often. Then, if we can as a first order optimization keep the dlist compilers VAOs as long as possible then we do in turn not flag DriverFlags.NewArray and the driver shall in turn not even need to look at the arrays to detect changes. I'll try split out that easy change from the hackeries for review within the next week ... But appart from that the dlist compiler can be hacked now to keep the same VAO used in the previous list by some offsetting to the primitives or pading vertices or what not to share the same pair of VAOs for more successive dlist nodes. You can be pretty creative here ... BTW: I am only mentioning legacy draw entry points, here. But note that the legacy entry points now basically use themselves the basic entry point that a modern OpenGL application uses. Means optimizing the modern main draw entry point does no longer partly collide with the already present dlist optimizations. The next changes will try to incrementally adress the way from the VAO down into the drivers. > If so, and with the minor comments on patch 4, the series LGTM. > > Reviewed-by: Brian Paul <[email protected]> > > Nice work! Thanks for the review!! I will apply the requested changes! And rerun the tests wrt the inserted assertations. best Mathias _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
