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

[Marek Olšák]

On Wed, Jun 1, 2016 at 4:58 PM, 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).
>
> 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.
>
>
> 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).


radeonsi doesn't do state-change triggered recompiles since LLVM 3.8. I
think nv50/nvc0 doesn't do that either, though I do understand this is a
very serious issue with other drivers.

The real problem for us (radeonsi specifically) is that some apps really
load shaders right before they wanna use them.

Marek

PS: My mistake, 16 ms is a requirement for 60 fps, not 30.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160601/597a927d/attachment.html>