[PATCH 2/8] wined3d: Introduce a format flag for volume texture support.

[Stefan Dösinger]

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

Am 2013-09-17 13:55, schrieb Henri Verbeet:
> I don't like this approach much. I think we should either do the
> right thing right away and have separate flags for each GL resource
> type (i.e., vertex/index buffers, renderbuffers,
> 1D/2D/3D/CUBE/RECT textures), or just keep assuming they're the
> always the same and handle the exceptions for volumes like a quirk
> flag like WINED3DFMT_FLAG_BROKEN_PITCH. In either case this should
> probably have corresponding support for ARB_internalformat_query2
> as well, and I'd prefer "TEXTURE3D" over "VOLUME".
I don't see what your intentions are exactly. I guess the goal is to
have something like "if ((resource->type_flags & format->flags) !=
resource->type_flags) return error;" in resource_init. I'm not sure
how this works with D3DUSAGE_TEXTURE and textures that don't have
D3DUSAGE_TEXTURE set. Check_device_format can't know if it should
check for 2D or RECT support, or both. Renderbuffer vs 2D is tricky as
well, although that might work ok if we equate D3DRTYPE_SURFACE with
renderbuffers and D3DRTYPE_TEXTURE with 2D. (If rendertarget or
depth-stencil usage are set. Otherwise we need yet another format flag
that says that we can stretchrect from that format but not use it as a
texture, e.g. for YUV surfaces.)

I don't like the idea of negative flags for 3D textures. That won't
get us anywhere with bug 21708.

Changing the format flags to have one flag for each resource type
wasn't exactly on my priority list. The goal of this patch and patch 3
is to make the dxtn creation tests in patch 7 work. Adding a TEXTURE3D
flag is a step in the correct direction.  My preferred alternative is
to drop patch 2 and 3 for now and flag the dxtn creation tests as todo
(It should still test locking properly since that part of the test
uses D3DPOOL_SCRATCH).

I can also move the flag check in patch 3 from volumetexture_init to
resource_init, but I'm not sure that this accomplishes much at this time.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSOGy8AAoJEN0/YqbEcdMwVGQP/R3o19l5B5+ZPY16pVQk9+JU
qRAy3J5gJH/RgE3CaG0vr3sSEadqqE+aflKesPxE4rSvtC3oDRS45lC+uk4JbhsR
NQrkpiooDJiOl4hBkkyiKKsdKZ+S+iTdMM0Z2rntX5IBZ+TPDwJGwMvv9phLAOkt
2ZMxtkvPnOczA9WQXCUL0DMVOKIIaEdQ92j6Xcg79NK9w3/87U4oNXCgimreRcPt
9oBjh8i5e+/FLWVlHvApzyjBOa7wcymBuZH6KAJexbCM8CnVfPcLedrCR5ZfRB9t
BPE/ClxKe+Vpm5OsJWyYsF9LFrR4rEzI3UnJaB1DUTaFar3mARhvgkPNpV8IeDDn
0AkreGD2ZXF+OHwRDKs4ALFC7sQS2E4naoBpyMy3z28gK6JYRZlPe8yeBv/ph0J7
wBwmubB1+onTERB38wiHDKPSsDWKtUeHaCXBzd5wC6j1LEnMqU6nvpcJbaMSfM3g
e5BnO1s7JE+5Qu9Wg4h0aDPTaOZ6I8iD16SO5laxZU9nTpliF3fSP6CA54br9zWu
bVq3RKcnLPdyfOMUsM16gMqFbsxQkX2UIxIFuxZRkXnmH4rKYq14bFp6E00+RWEC
QvSoE2EA9j+sktO0hS8ydPfZoWItHSgGxLorCiu750Ds3Tyu4r8XIj/2WuE0A37J
qWhNo61OeHr2STOSwGbn
=PJkb
-----END PGP SIGNATURE-----