[Mesa-dev] [PATCH 1/2] gallium: add PIPE_CAP_MIXED_FRAMEBUFFER_SIZES
Roland Scheidegger
sroland at vmware.com
Mon Sep 9 05:36:25 PDT 2013
Am 09.09.2013 13:55, schrieb Erik Faye-Lund:
> On Mon, Sep 9, 2013 at 1:31 PM, Roland Scheidegger <sroland at 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
More information about the mesa-dev
mailing list