[Mesa-dev] Discussion: C++11 std::future in Mesa

[Jason Ekstrand]

On Jun 1, 2016 7:43 AM, "Eero Tamminen" <eero.t.tamminen at intel.com> wrote:
>
> Hi,
>
>
> On 01.06.2016 16:53, Marek Olšák wrote:
>>
>> On Wed, Jun 1, 2016 at 3:02 PM, ⚛ <0xe2.0x9a.0x9b at gmail.com> wrote:
>>>
>>> On Wed, Jun 1, 2016 at 2:19 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>>
>>>> I'll let you figure it out by yourself.
>>>
>>>
>>> Why would you withhold information if you already have it? Are you a
>>> "bad person" or something?
>>>
>>> As far as my memory goes, I have never posted the sentence "I'll let
>>> you figure it out by yourself" to the Internet because I believe it is
>>> wrong.
>>
>>
>> :)
>>
>> Shader compilation at game loading time is never a problem, so we can
>> ignore that.
>
>
> Startup time may not be a problem for games (some gamers may disagree),
but there are also devices which have legal / certification requirements
for startup times, where shader compilation time could be a problem,
especially as Mesa shader compilation tends to get slower over time (as
compiler does more optimizations).

Again, a problem with a different solution: Properly implementing
glGetProgramBinary which should be pretty easy once the Timothy is done
with the shader cache.

> Those devices have pretty static content (at least for startup), so their
shaders could be pre-compiled if 3D driver supports that and has offline
compiler.  Many proprietary drivers do, Mesa doesn't, at least not yet.

You don't need an offline compiler.  The developer of said app just needs
to regenerate their program binaries after the update the driver.

Not trying to be negative here.  Just pointing out that delayed compilation
isn't the best solution to that problem either.

At one point in the past, I did consider a crazy scheme in which the driver
did a quick-and-dirty compile up-front and then did a longer, better
optimized, compile in the background.  That idea may still have some merit,
bit it's going to take a *lot* more plumbing in the front and back ends
than just putting std::future on a field in gl_program.

>> Shader compilation right before draw calls is what's unpleasant and
>> when people talk about it in the negative sense, they mean this.
>>
>> Because of external factors you can't predict, your driver suddenly
>> receives a bunch of shaders that take 2000 ms to compile right before
>> a draw call. Your budget is 16 ms per frame to get 30 fps, but you
>> can't render the frame if you don't compile those shaders. The problem
>> is how to fit the compilation that takes 2000 ms and is required
>> render the frame into 16 ms. Can you see where I'm going?
>
>
> Besides application itself compiling a shader, some state change done by
application may also trigger shader recompile in Mesa.  While for
application requested compilation nothing can be done to squeeze it into
16ms, there are some chances of reducing need for state-change triggered
recompiles (and these improvements have been done to Mesa during the years).
>
>
>         - Eero
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160601/8107de33/attachment.html>