Re: [PATCH 2/8] wined3d: Introduce a format flag for volume texture support.
On 17 September 2013 11:39, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index 4928f92..eabf890 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -2927,6 +2927,7 @@ extern enum wined3d_format_id pixelformat_for_depth(DWORD depth) DECLSPEC_HIDDEN #define WINED3DFMT_FLAG_HEIGHT_SCALE 0x00040000 #define WINED3DFMT_FLAG_TEXTURE 0x00080000 #define WINED3DFMT_FLAG_BLOCKS_NO_VERIFY 0x00100000 +#define WINED3DFMT_FLAG_VOLUME 0x00200000
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".
-----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-----
On 17 September 2013 16:52, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
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. The point is that the distinction you're making here between volumes and everything else is a bit arbitrary, and I think this patch as it is will make it more work rather than less to move towards having a set of capability flags per resource type. The advantage of the alternative is mostly that it's less invasive, so easier to change later.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-09-17 17:12, schrieb Henri Verbeet:
The point is that the distinction you're making here between volumes and everything else is a bit arbitrary, and I think this patch as it is will make it more work rather than less to move towards having a set of capability flags per resource type. The advantage of the alternative is mostly that it's less invasive, so easier to change later. I might have misunderstood what you meant with "separate flags for each GL resource type". Did you mean something like this
B8G8R8A8_UNORM.flags[texture2d] = RENDERTARGET | TEXTURE | ...; B8G8R8A8_UNORM.flags[renderbuffer] = RENDERTARGET | ...; B8G8R8A8_UNORM.flags[texture3d] = TEXTURE | ...; Instead of B8G8R8A8_UNORM.flags = RENDERTARGET | TEXTURE2D | TEXTURE3D | RENDERBUFFER | TEXTURECUBE | ...; ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOKiCAAoJEN0/YqbEcdMwdzwP/2+jmNXdtZNJY6KOFXgAXAS9 qvER27doBcBdgBYfOn+1EuntCqFgF/mWFdt4Qt9bsNsjoffli90vjymmW58CgXjl 6403DPS17Zw01dWQYtNIeIDdzP74pcIuIbaZ9l63XDDk/k42ne4VleJW2UehQT8/ 91Ft/K1puR/ENQ8ka9WxAirJAqV7CV7hgpUrraAE0xWNXD3tXhDnVvEL9bnuk226 gGm8jeDsl8GX9/LL+Lcud5KK1R66xD5SJCbL8rXmZijiq5molBLMMDO6HMV2z9Zf XDFekLqTs51pQjNc163yoKa3vfA0sUa2tOwA+KzPTuiimowAZy8qS6CkAyhJGOJn aTiCOLW6p3Ywsct6NkRwKXjbbi6RJcXRbKsLsBklHPFrhmNthbgdQoKkdDX+G3qZ +kG7N8w402bvNqUv4eZ3d6vwwrKd2ma35kjw/CrTObliQfWgPmSQM1gXA+zGtkPc q/1e1VufQ34+QI7osIIdpl5uIaeg/gGrYB1qCjSmpQQWUiJB2WfLRLj2Czw0+uUJ gTK41YrU3axBQOl7NuZu8d6P1RkSfyZkFUX6abfF8NGFCn4CSOXuCOr5GlEblI9O o2s0cKH43Zu+s/mk4xsnb2pR+WiKSU1vFrrvLFIecP07y53w4eqxhaL7CcEBphOu 3kYjieSGTr6zGho/PaNF =vnJi -----END PGP SIGNATURE-----
On 17 September 2013 21:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
I might have misunderstood what you meant with "separate flags for each GL resource type". Did you mean something like this
B8G8R8A8_UNORM.flags[texture2d] = RENDERTARGET | TEXTURE | ...; B8G8R8A8_UNORM.flags[renderbuffer] = RENDERTARGET | ...; B8G8R8A8_UNORM.flags[texture3d] = TEXTURE | ...;
Instead of
B8G8R8A8_UNORM.flags = RENDERTARGET | TEXTURE2D | TEXTURE3D | RENDERBUFFER | TEXTURECUBE | ...; ?
Yeah.
participants (2)
-
Henri Verbeet -
Stefan Dösinger