Re: [PATCH 2/5] d3d9: Check for support before creating textures
On 3 September 2013 14:07, Stefan Dösinger <stefan(a)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(a)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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJgQ1AAoJEN0/YqbEcdMwU1UP/RrVyhgHnisRuhzIQYkRLeaD jLR2MF2q4f7d39TnmuezL9pZD2xJrlwlKt+K/kM28h6PTux+I95uqMazVxX73+YO 2vyxLrNQrsuTUa/mKvGltxt5NiequQnyP6AGj5FV1vosfNzplJdz8Zrloo03SD/R ZrBvyT11C88PdEY0hd6N9m/RQMzxeSJpMHIL9jsu2AjhZHNVSC8O5CdtuOLsqQOu jWJH+6MhOlAtfmntR4iJg6tUdouDcHZFMfD4ThJ6yldbf7l32L6ozjhm/+yGzy3I BV9nEmUbp78pKbVQjQBvJ8aFEJMmiEX1SCuSgWdq/XgCuZnmUhGgkXoU3MKSSWzu i3+1PX2iqa7XqtgrtPbGehxdCWhZuAm3B4lTOF7+Sky6hd7AnQYUoEZqUIsp551H 2qLXpFgHUCzJR6d36FsW+uODCdcX9V6RYzY/JNqU3dpVrxOUts1Yn/HIow40yN1x 4+m19wZ8EYuEPPjtBp5RhBMi2AVhZgaDXSOdIvFmTHeTQ2r8KhDR0jQKIrVZBVXX ZUoLXu8SKSVNKy9BCwUrC79zGGpG9UWsc3dJXwbOclT+7dAuUUrYn6kiyGi6j7cA UK3KQ1JV1pl37ePyyFSolOjmKzHY4dlD6Ov5Tcr7NQKd6PZt13Wn3HNyKIFHrfRX fZIWpjCeoXRvRx6ieGdA =Ljrf -----END PGP SIGNATURE-----
On 3 September 2013 17:45, Stefan Dösinger <stefan(a)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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJkrMAAoJEN0/YqbEcdMww0YP+gP8QdgAiNpRLBBSMwFQDPuN 7QdUX14v6f6dk7WpT4ZLJ6NwVPdMFA9P495f45cBim0G4NWdUKxhvkdZA2/lMrYH Gf0I4Zfp0C8aio6HElz+0h0RJ4nCFCjv/enVytCDk5cZfYBU9t3ht7Uoq6HzA6hi FRvFunebLdOl0B/Ps11G2irWlLCq2W39AePnu/G/Nf4L1JNExM2Kw0xMFEU+r7u8 DGCQlnyc1hJLdz521e0BOPAMrtFj/Npn5E21dizewZkzouu2/+RXsCySEXcMOv13 aoBwHGAhqTJHnJTDrEWPZB8p1dHhEWMBvuADbawGovjHtMygura5CrWtAGcREuSw EaTUb4QC2NhBqwK/Pc4WpWirrnHYYHCELwh8kjZXVGghatiV+GfgJvvMVPk7ed3u gdwKfnjyzoRsEIU6W5Fi8iif8c75ipzkMk08uIyWGOqKUDUzVV3ToNCDrb++DOuI eK6NLRJeHNklIHfacoapc5YBc4k4oIuSFM8Ci7CM5Qwv84uRUpht4zcKWv0UhHdd BhMNKEoQdGFijTpueah5y/BMPe+vkBLdcz0gLU/lki38aRMx1DeVA+dPpOYPIvmA 5hG08mff+Yu+NLZDagcSRTZ4QOuQmZq1IQuXwj8KiPYF4cWCi73ARaAzG9U0iqwn onCMoU7APejBmVMT596H =yPzh -----END PGP SIGNATURE-----
participants (2)
-
Henri Verbeet -
Stefan Dösinger