On Wed, Dec 7, 2016 at 10:06 PM, Roland Scheidegger <srol...@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 <srol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
