On 3 September 2013 14:07, Stefan Dösinger stefan@codeweavers.com wrote:
I'm checking this in d3d9/d3d8/ddraw because we create textures for everything nowadays, even stand-alone surfaces.
For ddraw that's not true yet, but I think my preferred way to handle this would be to introduce a WINED3DUSAGE_TEXTURE usage flag, and then handle the format restrictions in resource_init() in wined3d.
Note that I have a couple of patches for enforcing render target and depth stencil format restrictions for bug 34284 that should go in later this week. It may be best to hold this of until after that's in.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-09-03 17:33, schrieb Henri Verbeet:
On 3 September 2013 14:07, Stefan Dösinger stefan@codeweavers.com wrote:
I'm checking this in d3d9/d3d8/ddraw because we create textures for everything nowadays, even stand-alone surfaces.
For ddraw that's not true yet, but I think my preferred way to handle this would be to introduce a WINED3DUSAGE_TEXTURE usage flag, and then handle the format restrictions in resource_init() in wined3d.
I have a patch for ddraw that changes that, it's one of the changes necessary to make the ddraw version of this test pass.
My main issue with a WINED3DUSAGE_TEXTURE flag is that create_texture(USAGE_TEXTURE) seems a bit weird - we might as well call it create_texture(USAGE_I_REALLY_MEAN_IT).
The other aspect is that the capability check is the main difference between SCRATCH and SYSMEM resources. Having the check in the client libraries makes it easier to handle SCRATCH resources in d3d8/9. Admittedly it is not enough to just handle the format this way. The POW2 restriction and maximum size checks would have to be moved as well.
On 3 September 2013 17:45, Stefan Dösinger stefan@codeweavers.com wrote:
My main issue with a WINED3DUSAGE_TEXTURE flag is that create_texture(USAGE_TEXTURE) seems a bit weird - we might as well call it create_texture(USAGE_I_REALLY_MEAN_IT).
If that's the main issue, I could tell you that it will most likely end up being renamed WINED3D_BIND_SHADER_RESOURCE at some point, equivalent to the d3d10+ bind flags.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-09-03 17:54, schrieb Henri Verbeet:
If that's the main issue, I could tell you that it will most likely end up being renamed WINED3D_BIND_SHADER_RESOURCE at some point, equivalent to the d3d10+ bind flags.
That works for the name. The other d3d10 flags should take care for most d3d9 flag combinations. One open issue I can think of so far is how to represent D3DPOOL_SYSTEMMEM. There's no exact match, since it supports CPU->GPU and GPU->CPU transfers. MSDN isn't quite clear on what STAGING usage means.
Lockable render targets (and dynamic rendertarget / depth stencil textures) are tricky too because MSDN says CPU_WRITE resources can't be bound to pipeline outputs. I guess that will need tests, and we may want to ignore it inside wined3d.
The rest seems pretty straightforward:
*) Textures and plain surfaces are handled by setting / not setting BIND_SHADER_RESOURCE. *) D3DUSAGE_RENDERTARGET and D3DUSAGE_DEPTHSTENCIL are handled with their equivalent bind flags. *) D3DPOOL managed and dynamic default pool have CPU_READ | CPU_WRITE set. *) D3DPOOL_SCRATCH doesn't have any BIND flags set. It does have CPU_READ | CPU_WRITE. Usage could be STAGING or a private usage flag, depending on *) Non-dynamic default resources don't allow CPU access and have D3D10_USAGE_DEFAULT.
Either way I think a D3DUSAGE_TEXTURE flag should work for now.
-
Henri Verbeet -
Stefan Dösinger