[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 2/4] wined3d: Keep track of renderbuffer capabilities.
From:       Henri Verbeet <hverbeet () gmail ! com>
Date:       2015-04-30 20:33:18
Message-ID: CAOsNvwwmBMv50CNNVuTwpUN2WpDEbu-fHOAr5y-ZEmzC-Y7RmA () mail ! gmail ! com
[Download RAW message or body]

On 30 April 2015 at 21:45, Stefan Dösinger <stefandoesinger@gmail.com> wrote:
> > > +        if ((rt_format->flags[WINED3D_GL_RES_TYPE_RB] & \
> > > WINED3DFMT_FLAG_RENDERTARGET) +                && \
> > > (ds_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | \
> > > WINED3DFMT_FLAG_STENCIL)))
> > This is actually wrong. At least, as long as we don't allow (plain)
> > renderbuffers to be used for FBO attachments. There's nothing in the
> > spec that says formats that can be used for color rendering with
> > renderbuffers have to be available for color rendering with textures
> > as well, and in fact that's much of the reason for this patch set.
> I'm not really making a distinction between "is this format a depth
> stencil format" and "Can a resource with this type and format be
> created". Maybe we should add some WINED3DFMT_FLAG_SUPPORTED flag and
> check it in resource_init regardless of what the app requests?
> 
I think WINED3DFMT_FLAG_FBO_ATTACHABLE mostly does what we want as
long as FBO ORM is used, perhaps it should be generalized to e.g.
WINED3DFMT_FLAG_RENDERABLE.


[prev in list] [next in list] [prev in thread] [next in thread]