[Mesa-dev] [PATCH v3 0/9] Gallium Nine

Emil Velikov emil.l.velikov at gmail.com
Tue Nov 18 14:31:09 PST 2014


Hi Stefan,

On 18/11/14 21:21, Stefan Dösinger wrote:
> Am 2014-11-18 19:36, schrieb Henri Verbeet:
>> To clarify, that's not what I said. It's mostly just that I'd like
>> to see some actual evidence for the (implicit) claim that the
>> performance difference is largely due to inherent OpenGL API
>> overhead.
> I have some microbenchmarks to measure API overhead of d3d and GL here:
> 
> 
> https://stefandoesinger.ddns.net/~git/perftest/
> (self-signed cert)
> Binaries are here:
> https://stefandoesinger.ddns.net/~stefan/pts/
> 
Hmm the binaries do not seem to match the source. Am I missing something ?

> I had a chat with mannerov (I guess he's Axel Davy, according to
> /whois) on IRC, and he ran the drawprim and clear tests with gallium
> nine, wined3d and GL. His results show pretty much the same result in
> gallium nine and wined3d, and the GL result handily beats both of them.
> 
> Mannerov says his system doesn't show a big difference in real games
> between wined3d and nine, so it would be nice to have more test
> results from other people who see a big difference in real-world games.
> 
Thanks for listing these test publicly. Now more people can give them a
spin thus find some correlation. Or perhaps it's a case that the tests
do not affect code paths that are faster with nine :\

> Those benchmarks would be a first step in pointing out overhead
> differences between nine and wined3d and give some hints where they
> are. The GL result should show if the difference is due to overhead
> inside wined3d or the Mesa GL frontend.
> 
> Obviously more tests are needed. The tests so far just cover plain
> draws, stream source changes, clears and vertex buffer uploads. I
> suspect that a major source of overhead are shader changes and / or
> shader constant / uniform changes. And so far all of those tests only
> cover CPU-side performance problems.
> 
On of the points in my earlier "rant" was - if wine is interested solely
on improvements of the current code, and there is no interest/intensive
to include an alternative solution it makes no sense to keep on
pestering you guys.

Thank you for the input.
Emil


More information about the mesa-dev mailing list