Valve-Sponsored Mesa Work Makes Games Load A Lot Faster

[_SXX_]

Valve help AMD and Nvidia both ... with their proprietary drivers.

I don't really see what do you mean as "help" there. I doubt Valve have access to their drivers source code or can pay to 3rd party company to drivers optimization.

Also if AMD actually execute their plan about moving proprietary part to user space, then their proprietary drivers will benefit open source drivers too because both will use same kernel module which mean improvements for power and memory management.

Even Nvidia start to push some code and docs for Nouveau and this clearly related to what's Valve doing.

[Dukenukemx]

I don't really see what do you mean as "help" there. I doubt Valve have access to their drivers source code or can pay to 3rd party company to drivers optimization.

Most developers have in house tools that allow them to constantly benchmark and test things. At some point a developer might find a bug or issue that causes huge performance loss. Back when the Radeon 8500 was ATI's best of the best graphics card, John Carmack found a massive bug in their drivers that when fixed gave it a huge performance increase.

Even the Dolphin emulator developer has a lot of negative things to say about Linux drivers. I would imagine that nothing frustrates him more then hours of banging your head into the wall, only to find out it wasn't your code.

Even Nvidia start to push some code and docs for Nouveau and this clearly related to what's Valve doing.

Nvidia hasn't done much to help with Nouveau. Not like AMD or Intel has.

[Dukenukemx]

To give you an idea the Dolphin developer didn't like AMD or Nvidia's response time for the issues they found, but like the Open Source drivers response time to fix issues to be a lot better.

    Wrong GLSL built-in functions results with UBO arguments, fixed in Mesa 9.1.1, 7 days after we reported the bug.
    Dithering effects with UBOs, centroid and i965, fixed in Mesa 9.2.0.
    Mesa bug causing black screen on r600 (radeon), patch provided 10 minutes after we reported the issue on IRC, merged the same day and released in a stable version 2 weeks later (9.1.3).
    Nouveau black screen issue with UBOs larger than 64KB, debugged by one of our developers, merged 1 day after the bug was reported and released in a stable version a week later (9.1.6).

[Luke_Wolf]

Even Nvidia start to push some code and docs for Nouveau and this clearly related to what's Valve doing.

If it was related to what Valve was doing it wouldn't be limited to Tegra work. Now long term they might decide to throw their support behind nouveau for desktop/laptop gpus but right now it's basically for their ARM chips. I honestly don't expect them to do so though until long after Mesa is compliant with whatever the latest standard is at the time and the gallium drivers have full openCL support and such that basically most of the major work has already been done for them...

[mibo]

How about Catalyst and NV binary?

Are the binary blobs of AMD and NVIDIA already using multiple cpus in this scenario?

(So, does MESA catch up or speed ahead?)

[_SXX_]

Most developers have in house tools that allow them to constantly benchmark and test things. At some point a developer might find a bug or issue that causes huge performance loss.

It's just bug reporting and this have nothing to do with cooperation between game and driver developers. Unfortunately AMD don't push R600/RadeonSI as their main Linux drivers so it's understandably why Valve don't active there.

To give you an idea the Dolphin developer didn't like AMD or Nvidia's response time for the issues they found, but like the Open Source drivers response time to fix issues to be a lot better.

I'm active community member of one game which support Linux as well. Unfortunately developers don't have resources to improve open source drivers support just yet, but they openly talk about their communication with AMD/Nvdia developers support. Uber aren't officially partnered with Nvidia (no "The Way It's Meant to be Played" crap), but they still get responses from Nvidia developers support rapidly: usually same day or even in hours.

In same time they have to wait for responses of AMD for weeks or months and this is about Windows-related OpenGL problems so I doubt there is proper Linux developers support at all.

[Calinou]

And this right here is why open source wins in the long run over proprietary software. Instead of having to live with bugs, slow performance and other issues, developers using the related stacks can fix the system and push changes upstream helping everyone.

If only they could do the same thing to their games now... but ?hey, people will cheat everywhere and this is useless? (sic).

[_SXX_]

If only they could do the same thing to their games now... but ?hey, people will cheat everywhere and this is useless? (sic).

Unfortunately it's true and open source not work that well for game development. There is a lot of open source engines around that allow anybody to create great games, but still very few games which is better that can be compared with proprietary one.

[_SXX_]

From my point of view open source should work well for all kind of simulators (e.g OpenTTD), but there is pretty small audience and extremely small number of developers. Market is small, usually taken by few vendors which aren't super profitable even with proprietary games because of limited audience.

Possible some FMCG-like games open source games might have a lot of audience, e.g like EA's Sims or football/basketball games released every year. Unfortunately those require a lot of work and art and there just not enough artists working "for fun" around.

[Ancurio]

Actually I wait for compile status like most tutorials out there do, pretty serial What about loading all shaders from disk at once, then rapidly issuing glCompileShader and waiting for their compile status? Ofcourse this can be further improved by having two feeder/consumer threads to minimize disk IO wait and/or let it do its business in a separate OGL context.

Thanks for hint!

I think threading up the disk IO code is over kill. If you still want to get fancy though, you could also queue up your glLinkProgram calls before querying the final success status / log, it seems Mesa might defer that to the pool too (and linking takes a not insignificant amount of time).

Are the binary blobs of AMD and NVIDIA already using multiple cpus in this scenario?

(So, does MESA catch up or speed ahead?)

I remember Graham Sellers tweeting about this very issue (basically telling devs to defer querying shader/program state) many months ago, so yes, AMD definitely does it, and Nvidia most likely too.