On 28/09/15 15:30, Rob Clark wrote:
On Mon, Sep 28, 2015 at 8:55 AM, Jose Fonseca <jfons...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
