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.froehl...@gmx.net wrote:
From: Mathias Fröhlich <mathias.froehl...@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 <bri...@vmware.com>
Nice work!
Thanks for the review!!
I will apply the requested changes!
And rerun the tests wrt the inserted assertations.
Thanks.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
