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

[Brian Paul]

On 02/28/2018 12:10 AM, Mathias Fröhlich wrote:
> 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 ...

That sounds great.  At VMware we come across quite a few legacy GL apps 
that make heavy use of display lists, and often times, the applications 
are pretty inefficient with display list use.

My previous optimization applied to multiple glBegin/End primitives 
within a single display list (avoid re-emitting vertex array offsets for 
each draw call).  If we can do that with glBegin/End prims in separate 
display lists, that could be a really nice improvement.


> 
> 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.

Thanks.

-Brian