Valve-Sponsored Mesa Work Makes Games Load A Lot Faster

[DaVince]

PMdh04000: I'm a different person, though felt the need to point it out as it does change the meaning entirely.

I don't see the difference in the context.

Ah, it's just the difference between saying "Pretty much no one does it like this" and "This doesn't work". AFAICT the former was being said.

[GreatEmerald]

Ah, it's just the difference between saying "Pretty much no one does it like this" and "This doesn't work". AFAICT the former was being said.

I'm not a native speaker, but it doesn't make sense to me... If it was the former, then it would have been phrased as "It's never done this way", no?

[Luke_Wolf]

PMdh04000: I'm a different person, though felt the need to point it out as it does change the meaning entirely.


Ah, it's just the difference between saying "Pretty much no one does it like this" and "This doesn't work". AFAICT the former was being said.

As a native english speaker, in context GreatEmerald's usage is 100% correct. You cannot state whether something has or has not worked, or whether it does or does not work, without there being at least a single occurrence of it being tried. Which is what is being gotten at.

[curaga]

Driver already have pool of threads (and not that Linux have some heavy threads anyway). And initial state should be identical to all of them. So resource usage when no additional threads are used (beyond first) should be very very minimal. (Linux have that layzy copy-on-write approach)

You discount the locking overhead. Consider apps that compile a few thousand shaders, then add a mutex to each.

[smitty3268]

The docs have this marked as done. Are you sure it wasnt commited?

Edit: Ahh I realise now you are talking about the caching.

GL_ARB_get_program_binary is marked done because the spec allows the driver to fail out of it at anytime and still be compliant, so the driver just implements the stub and has nothing inside of it.

For a while, somebody was working on filling in the actual implementation to correctly export and load the binaries, and they stuck along a cache at the same time as an easy way to test their implementation.

It never got committed though, because the mesa devs weren't ever happy with the code.

[smitty3268]

You discount the locking overhead. Consider apps that compile a few thousand shaders, then add a mutex to each.

I don't know, a simple mutex shouldn't be that bad if they're never blocking each other, should it? At least in comparison with all the work associated with compiling a shader.

The NVidia and fglrx binary drivers apparently have threaded compiling on all the time, so i don't see why Mesa couldn't do the same, unless there is something inefficient about their particular codebase.

Some numbers from the patches:

I do not have numbers from real applications yet. But trying to compiling a
set of 2882 shaders extracted from some trace file, with everything else
idled, the time it takes is

8 threads: 17.8s
4 threads: 20.3s
2 threads: 31.2s
1 threads: 58.0s
no thread pool: 54.5

on a quad core system.

So i guess that's about 6.5% slower. I think the benefits of always having multithreading might be good enough to live with 6.5%.

[erendorn]

Pardon?

It's was never announced that source code will be included and it's not available yet.

My bad. Only for Unreal then.