[Mesa-dev] [PATCH 11/12] vbo: Remove vbo_save_vertex_list::buffer_offset.

[Mathias Fröhlich]

Hi Brian,

On Wednesday, 28 February 2018 00:56:36 CET Brian Paul wrote:
> On 02/26/2018 11:12 PM, Mathias.Froehlich at gmx.net wrote:
> > From: Mathias Fröhlich <mathias.froehlich at web.de>
> > 
> > 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 <brianp at vmware.com>
> 
> Nice work!

Thanks for the review!!
I will apply the requested changes!
And rerun the tests wrt the inserted assertations.

best

Mathias