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. Cheers, -ilia PS. See bug https://bugs.freedesktop.org/show_bug.cgi?id=91314 but the assert fail happens due to improper handling in the storage allocation failure case, which ought to get handled anyways. _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
