[Mesa-dev] Disagreement between ChooseTextureFormat and QuerySamplesForFormat

[Ilia Mirkin]

On Sun, Jul 12, 2015 at 4:14 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 12.07.2015 um 19:30 schrieb Ilia Mirkin:
>> I asked this on IRC, but figured I'd get wider distribution for the
>> question. The situation is that nv50 doesn't support RGBA32 MS8
>> textures. However QuerySamplesForFormat will try its hardest to find
>> supported sample counts, which means it'll go down st/mesa's fallback
>> format list, which includes RGBA16, which can handle MS8 just fine. So
>> the teximage.c code thinks that the # of samples is OK.
>>
>> However when it selects the teximage format, ChooseTextureFormat,
>> which does not take a sample count, will return RGBA32 (which is
>> supported for MS1, MS2, MS4 on nv50). When later it attempts to
>> AllocTextureStorage, it will again attempt to do so using RGBA32 with
>> MS8, which will fail. The core code handles this case (since texture
>> storage allocation can happen for a wide variety of reasons), but I
>> think this is suboptimal.
>>
>> Should ChooseTextureFormat take a sample count? This would allow the
>> driver to provide the "correct" TexFormat for that format / sample
>> count combo.
>
> Maybe. I got some doubts though this is the correct fix at least in this
> case.
> I think st_choose_format should be more clever not to try such fallback
> formats, at least if that was for some kind of query. In particular
> RGBA32F is a required supported format (in newer gl versions), thus it
> is not correct to fallback to something with less bits, msaa or not.

Removing the fallback from RGBA32F to RGBA16F would likely resolve my
issue as well. I assumed that fallback existed for a reason though and
didn't want to try removing it. If you guys think that's the better
course of action, that works for me.

  -ilia