On Sun, Jul 12, 2015 at 7:30 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > 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.
Yes. If your hardware has such limitations, ChooseTextureFormat needs to be updated to reflect that. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
