Am 09.09.2013 13:55, schrieb Erik Faye-Lund: > On Mon, Sep 9, 2013 at 1:31 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> I'm not really convinced of this idea. >> There's already PIPE_CAP_MIXED_COLORBUFFER_FORMATS which is sort of >> similar - a "requirement" of ARB_fbo, but it isn't used to determine >> support of ARB_fbo or not (my guess is drivers want to advertize ARB_fbo >> even if they can't do it, and ARB_fbo doesn't really have a hard >> requirement for anything as you always can say "no" to fb supported). >> So I can't see why not supporting different width/height is treated >> different to not supporting different formats. > > Actually, ARB_framebuffer_object does have a hard requirement on > rendering to differently sized attachments. FRAMEBUFFER_UNSUPPORTED is > only allowed for format-issues. EXT_framebuffer_objects can still be > supported on hardware that cannot meet this requirement >
Ah you're right. For some reason I thought it would be permitted for a driver to return unsupported framebuffer for any reason. So this makes sense then. (Though I'm wondering if we really need the PIPE_CAP_MIXED_COLORBUFFER_FORMATS then since I don't think there's any driver which can do different width/height hence support ARB_fbo but not actually support mixed formats, r300 and softpipe might be candidates though I don't know why the latter wouldn't support mixed formats as it claims not to and have no idea if the former can support different width/height.) Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev