[Mesa-dev] Disagreement between ChooseTextureFormat and QuerySamplesForFormat

[Marek Olšák]

On Sat, Sep 5, 2015 at 7:20 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> 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.

Yeah, I think you can remove all fallbacks that are incorrect.

Marek