[2/4] wined3d: reject ARB shader blits if the destination is not fbo attachable

Stefan Dösinger stefan at codeweavers.com
Wed Oct 12 07:30:15 CDT 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Am 12.10.2011 um 11:26 schrieb Henri Verbeet:

> On 11 October 2011 22:30, Stefan Dösinger <stefan at codeweavers.com> wrote:
>> +    if (wined3d_settings.offscreen_rendering_mode == ORM_FBO)
>> +    {
>> +        if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) || (dst_usage & WINED3DUSAGE_RENDERTARGET)))
>> +            return FALSE;
>> +    }
>> +    else if (!(dst_usage & WINED3DUSAGE_RENDERTARGET))
>> +    {
>> +        return FALSE;
>> +    }
> Formats are never FBO-attachable if we don't have
> FBOs. It's not clear this is what you want either way though. This
> pretty much looks like a copy/paste from fbo_blit_supported(), and the
> WINED3DUSAGE_RENDERTARGET check there is to allow formats that don't
> have a FBO-attachable internal format, but were created with the
> rtInternal format (which should always be attachable). There's really
> no equivalent check for backbuffer ORM, it just renders something and
> hopes we can read it back.
I'm not sure I see what you mean. What I want is to make sure the blitter doesn't draw to a surface that GL can't draw to. In the FBO ORM case the fbo_attachable || rendertarget case seems just right, for the reasons you mention.

With backbuffer ORM we don't really know where we can draw(e.g. stuff like surface size vs framebuffer size comes into play), but I think RENDERTARGET usage is a decent heuristic since we'll probably have to be able to draw to it anyways, or things fails.

I could add some surface_is_drawable() function or equivalent surface flag. That might be a good idea on its own, but I don't see a better way to define if a surface can be rendered to than the above statement.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)

iQIcBAEBAgAGBQJOlYhaAAoJEN0/YqbEcdMwpxgQAJTF3i75QLb+gosDaGkFODbk
nhNUt/PHRw7k8yTVFBHp5aBWNCROdcr9yFANMj4AD74ii1HGNj9jzGISyfogvfqv
RNHHHvwdff7b8Ev8MtKBEY3w9fTPvl7w0FzdzoSTFBF2SxkeEMc6QnecaHIfcepr
SCf69/FFeVkPniOiVa3RCbLXyvrWG6ifMpJpXV8DFw23NTqb/JGyQIjodW2hc+Qy
Gpgz4hwBw/jywOeFPCyOXtpR0bTBdD03mix3XWeYYaZg1Ukm+jyARQOvBSFU0dgB
xhEcVTR0aNGA5WAgpKxUT1f3jRQc9f36U7HS5jTZemFR71wAXFPO0pMm7RNNrMXQ
imhzE9+56OS7o96Vk4Rz8UdFYDBgDvTjO8nlp9j5aDOi8ylsX9TstDdRi2kh3ILI
Satb83g0brU6JZaDqsLd5xZI8ZTPL55MniKRGvXJ1EEepViC0isgvMmrM1b/I2Wo
N0FSoLkukXAfJHcal9YD6nAQeoI1HbM9HNNmAMPMCtDb9Y8Q0VSSWoeh71iP8cGF
DziZZ3uSnX90kDrt7q6maXDFSWUS8YKZz2lviRxupb2LzwaSMAP2Aw1XEQz/YImH
HxZkPuY4kZdQNShcYOyv9ZqNKUBrD5geFhmErYqxSL+Ede1nM7Lcp52NhbVRnTLI
9ksujocgWYGZYbzbhwym
=04xu
-----END PGP SIGNATURE-----



More information about the wine-devel mailing list