[Mesa-dev] Question: st/mesa and context-shareable shaders

[Jose Fonseca]

On 28/09/15 15:30, Rob Clark wrote:
> On Mon, Sep 28, 2015 at 8:55 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
>>
>>
>>> I see only 2 options out of this:
>>>
>>> 1) Removing the context pointer from the shader keys. If drivers need
>>> this, they should handle it by themselves. This will simplify st/mesa,
>>> because TCS, TES, GS won't need the variant-tracking machinery.
>>>
>>> 2) Adding PIPE_CAP_SHAREABLE_SHADERS and if the cap is 1, set the
>>> context pointer to NULL in all keys.
>
> how would this look from gallium API?  Move
> pipe->create_{fs,vs,gs,etc}_state() to screen (and take a pipe_screen
> ptr instead of pipe_context ptr)?
>
> fwiw, I mostly just (other than at emit time) use the pipe_context ptr
> to get at the pipe_screen.  So other than sorting you the
> threading/locking issues it would seem straightforward to move..
>
>>> What do you think?
>>>
>>> Marek
>>
>>
>> I think there are other options worth considering:
>>
>>
>> a) I wonder if wouldn't be better the other way around: if drivers want to
>> avoid compiling the same shader for many contexts, they should maintain a
>> shader cache internally that's shared by all contexts.
>>
>>     As that can be done much more efficient -- there are many ways to
>> implement a global cache that avoids frequent locking
>>
>>     And the way to avoid reimplementing the wheel on every driver would be to
>> have an helper module that would take care of that -- ie, a generial
>> auxiliary module to maintain the shader cache in a thread safe maner.  That
>> module could potentially even learn to (de)serializing the cache from disk.
>>
>>
>> b) split pipe shader objects in two parts:
>>
>>     1) a global object, which would allow the pipe drivers to pre-compile the
>> TGSI into an internal IR
>>
>>     2) per-context objects, so that pipe drivers could produce variants of
>> that IR which takes in account the currently bound state
>
> even these don't have to be per-context..  it's really just <shader +
> key> ==> variant..
>
> I'd want to share the variants across context too..

Right.  You could use Marek's idea and attach the variants to the 
screen-shader object internally too.

Nothing is lost.  But if a driver prefers to attach variants to the 
context-shader object, due to the simpler threading, or because the 
variants can be derived cheaply, or because there are so many variants 
that a linear search is not practical, it still can.

>>    And for pipe drivers that can't pre-compile anything, 1) would be nothing
>> more than a duplication of TGSI tokens.
>>
>>
>>
>> c) introduce Metal/DX12/Vulkan like "pipeline state objects", whereby the
>> state tracker declares upfront how the whole pipeline state objects are
>> bound together, so the driver can produce the shader variant when that
>> pipeline state is created, and doesn't need to worry about shader variantes
>> at draw time.
>
> This would be useful for other reasons..  maybe not so much to avoid
> late variant generation at draw time, or at least my shader variants
> depend on raster and texture state.  And I guess other drivers have
> their own weird variant state dependencies.

llvmpipe is similar in some way.

Many drivers suffer from similar problems -- many CSO end up being dumb 
structures which drivers copy around, just to be translated at draw 
time, when all state is known.

We could craft the gallium pipeline state objects so that they would 
contain all information that drivers may ever need.

The burden of copying and assembling the bits of state around would fall 
into the state tracker.

Once the pipeline state object cache is populated, draw should succeed fast.


> But for freedreno, once we start getting gs/tes support, I'll want to
> generate binning pass shader variants with link time optimization..
>
> BR,
> -R

Jose