[Mesa-dev] [PATCH] cso: handle sampler view changes the same way for all shader types

Brian Paul brianp at vmware.com
Thu Dec 10 16:12:09 PST 2015

On 12/10/2015 03:56 PM, Marek Olšák wrote:
> On Thu, Dec 10, 2015 at 10:14 PM, Brian Paul <brianp at vmware.com> wrote:
>> Previously, we were tracking sampler views for fragment shaders and
>> suppressing redundant state changes, but not for other types of shaders.
>> Now sampler views for all shader types are handled the same way.
> I removed this not so long ago:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_mesa_mesa_commit_-3Fid-3D3639d66a473591e21aa2ec7692c95c827b479632&d=BQIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8&m=8kXcYywv3xFeg9QtRF7rWvEtgOLY3_JIB2jBxOpBtbw&s=xNIiDGT_KgNc9x17rtss_TKr2GvlgaSYye0ZSHNEzl8&e=
> The reasons were:
> 1) Meta ops didn't save/restore samplers for non-fragment shaders.
> 2) Drivers can avoid redundant state updates at per-slot granularity,
> unlike cso_context. Therefore, cso_context can never be faster than
> drivers, but it can be slower if drivers do the same thing (or do
> it better).
> 3) Drivers have to keep a copy of all sampler views too. There is no
> reason to keep another copy of all views elsewhere.
> My belief was that doing unnecessary work in cso_context was hurting
> us, but I didn't have any performance numbers.
> The same applies to sampler states.

I was going on the premise that it's better to implement the 
optimization in one place than to effectively duplicate it in each 
driver.  Plus, making fewer overall calls into the driver seems like a 
desirable trait.  I saw a measurable improvement with some things (like 
the Lightsmark demo) but no change in others (like Heaven 4).

In any case, I found that I still have to do some checking in our driver 
code too in order to catch more cases.  I could go down that route for now.

Maybe other driver developers can test these patches and see if it helps 


More information about the mesa-dev mailing list