On 17 September 2013 11:39, Stefan Dösinger stefan@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.
On 17 September 2013 16:52, Stefan Dösinger stefan@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 | ...; ?
On 17 September 2013 21:07, Stefan Dösinger stefan@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.
-
Henri Verbeet -
Stefan Dösinger