Blumenkrantz Optimizes Mesa Vulkan Submission Merging - Some Test Cases Improve 1000%+

[Draget]

I am very happy about the queue optimizations and it will benefit some actual workloads, yes!

*But* I have to hold some horses here… the 10x or 30x cases reported here are NOP-filled command queues which will not really have any effect on actual game performance.

The other cases of actual command-buffers submitted a batches are also noticeably faster, so it is an awesome find and fix. But we have to see (aka benchmark) what actual differences it makes in games, which might less fantastic than those numbers.

[mbriar]

Games do like 5-10 queue submissions per frame, while doing tens of thousands of other vulkan calls. I wouldn't expect this to have a measurable impact on game performance tbh.

[Jumbotron]

I wonder. Did Mike make it 1000-5000% better? Or did he simply discover that Vulkan was 1000-5000% crappier than it should have been and he just brought it back to unity?

Either way, get that man a beer....or two

[caligula]

This is great because the eye candy department needs more powerful drivers and hardware to be able to make 25% slower code each year. It's a serious threat to web and other front-end programmers if they cannot 100% utilize all the increase of power in the new generations.

[doomie]

This is great because the eye candy department needs more powerful drivers and hardware to be able to make 25% slower code each year. It's a serious threat to web and other front-end programmers if they cannot 100% utilize all the increase of power in the new generations.

Remember, progress isn't a relative term that requires a goal, and overall everything always gets better with time. Trust me

[davibu]

From the wording this seems to be bugfix rather than an optimization. I mean it's very nice to get a lot more performance, but it's quite weird that batch submissions weren't handled as such in the first place.
Seems like a huge oversight, especially because batching is such a well known optimization point.

I would also guess that there will be performance gains in some games from this, contrary to the other comments here.
Batching to the graphic card is very important for performance, because the graphic card has less off-time in between calls compared to batchless calls.

[cl333r]

From the wording this seems to be bugfix rather than an optimization. I mean it's very nice to get a lot more performance, but it's quite weird that batch submissions weren't handled as such in the first place.
Seems like a huge oversight, especially because batching is such a well known optimization point.

I would also guess that there will be performance gains in some games from this, contrary to the other comments here.
Batching to the graphic card is very important for performance, because the graphic card has less off-time in between calls compared to batchless calls.

I thought I'm going crazy and no one notices how weird this is. How in hell code that all open source graphics drivers rely on is resubmitting their batches by splitting each batch and submitting each item one by one - that's stupid code/solution even for a newbie programmer!

It would be understandable if the code had some TBD comment as a reminder at least.

[yoshi314]

i would say this is a case of avoiding premature optimization. likely at the time of introduction nothing was hammering this code path this much.

[kloop]

i would say this is a case of avoiding premature optimization. likely at the time of introduction nothing was hammering this code path this much.

No way is busting a batch call open to do them individually a way to avoid premature optimization. Maybe the batching needed infrastructure that wasn't there when it was written.

[Gabbb]

When is this expected to hit the Arch repos? Will Polaris cards benefit?