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

[Rob Clark]

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..

>   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.

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