<kusma>
Hmm. I recently discovered that 3253594268028efdca17cb9d2b2e423b353c8aa5 ("vbo/dlist: rework buffer sizes") is an absolute perf-cliff for me on Zink + ANV...
<kusma>
(for glxgears)
<kusma>
Oh, uh. I should have updated to bleeding edge main right away; turns out things are massively faster now, so whatever ;)
<kusma>
~60fps at 21.2.6, ~40fps before the vbo-tweak, ~8fps after, but... uh. Around 4000fps on main. Great work!
<kusma>
Still about half of what I get with Iris, so we have some room for future improvement (and blog-posts) also!
<kusma>
Or who know, maybe kopper already seals the deal
<kusma>
s/know/knows/
<zmike>
it's faster on main because it rewrites the dlist from QUAD -> TRI in mesa
<zmike>
the only way to speed it up now is a vk extension for QUADS
<airlied>
gimme moar QUADS
<kusma>
Maybe I should compare esw_gears instead
<kusma>
es2
<kusma>
No quads in that one. Actually might be faster, because it's more modern gl style
<kusma>
(after I fixed the stupid amount of draws)
<kusma>
In theory, shouldn't we be able to bake quads into the display list building?
<kusma>
If someone cares enough to write that code, that is
<zmike>
I already added the conversion into dlist construction
<zmike>
unless you meant it another way
<kusma>
I mean so it wouldn't have any cost on the driver when calling the list... Sounds like what you're describing
<kusma>
Not sure how a quad ext would improve perf much then...
<zmike>
the conversion still uses cpu
<ajax>
cs to the rescue
<kusma>
But that should happen once, not each time the list is reused, no?
<zmike>
correct
<zmike>
oh we're not just talking about startup time?
<kusma>
So then it doesn't affect fps, just startup time, very slightly
<kusma>
Anyway, this is pretty great as-is already