[Mesa-dev] [PATCH 1/3] cso: don't release sampler states that are bound

[Marek Olšák]

On Wed, Dec 7, 2016 at 10:06 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 07.12.2016 um 21:46 schrieb Marek Olšák:
>> On Wed, Dec 7, 2016 at 6:00 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>>> Am 07.12.2016 um 17:26 schrieb Marek Olšák:
>>>> Optimizing the CSO cache isn't exactly on the top of my list, so I
>>>> can't really do that right now.
>>>>
>>>> I think that varying the LOD bias is starting to be common. It's used
>>>> for smooth LOD transitions when loading textures during rendering.
>>>> Games with lots of content typically do that. This particular Batman
>>>> game uses UE3.
>>> The question of course is if they do it via sampler state or via shader
>>> lod bias.
>>
>> The sampler state. I saw those states. lod_bias was the only changing variable.
> I meant in general, not for this particular app.
>
>>
>>> I suppose that when these objects were designed noone thought it would
>>> be useful to really create sampler state with lots of different bias
>>> values. d3d10 of course would have the same problem (and it has limits
>>> on how many such objects you can create, 4096 per context) but the
>>> problem shifted to the app since it would have to create the objects
>>> explicitly - I would suspect the app there would either quantize the
>>> value itself, or use shader lod bias instead.
>>
>> The shader lod bias isn't a better solution though. Any LOD bias is a
>> modifier of the varying LOD value. For texture streaming, you want to
>> clamp the LOD, not shift it, thus min_lod is better. However, min_lod
>> is integer on ATI DX9 GPUs (not sure about the API), so DX9 games
>> can't use it for smooth transitions. That may explain why we are
>> seeing it with Wine. I guess any DX10+ and GL3+ games do use min_lod
>> instead of lod_bias, which means we probably get a lot of sampler
>> states there too.
> Oh I missed this was dx9. DX9 otherwise only has D3DSAMP_MAXMIPLEVEL
> which is integer, equivalent to gl's base level (restricting lod range
> directly is impossible, albeit I suppose you might translate that
> MAXMIPLEVEL to min_lod without texture views).
>
>>
>> We could reduce the size of pipe_sampler_state a little. AMD GCN can
>> represent only 14 bits of lod_bias and 12 bits of min_lod and max_lod.
> So min_lod and max_lod only has 6 fractional bits whereas lod_bias has 8?
> In any case even 12 bits is quite a lot of objects you could possibly
> have...
> I'm not sure though if using some fixed-point integer in
> pipe_sampler_state really makes a lot of sense.

It makes sense for Radeons. :)

To Ilia: Yes, we have +16 lod bias.

Marek