[PATCH 2/6] wined3d: Pass the volume texture level to the client libraries.

[Stefan Dösinger]

Am 18.04.2014 um 20:03 schrieb Henri Verbeet <hverbeet at gmail.com>:
> There's struct wined3d_texture_ops if there are no better options, but
> yes, this may imply doing work to unify wined3d_surface_map() and
> wined3d_volume_map() first. That was just an example though, the basic
> point is that moving wined3d_volume calls from the d3d9 volume to the
> d3d9 volume texture doesn't get us much closer to getting rid of
> wined3d_volume in the public wined3d API. I did warn that this was
> non-trivial to get right.
We could go back to http://www.winehq.org/pipermail/wine-patches/2014-February/130248.html and merge resource management and resource mapping in a sub resource structure while keeping the resource structure around as long as needed. The main difference I’d suggest is not deriving wined3d_sub_resource from wined3d_resource.

I’d prefer, but that’s not a requirement, to remove the get_resource_desc calls on surfaces and volumes before doing that. I realize that not calling those functions doesn’t make the interface go away (the only way to do that is to remove resource_from_surface), but it avoids exposing the to-be-removed resource data outside of wined3d.

In terms of where we want to go wrt surfaces/volumes, subresources and resources: Surfaces and volumes would be responsible for storing and loading data in the GL texture. Surfaces also handle DIB sections for GetDC. Subresources take care of location management (the main motivation: Offscreen ORM can only load one mipmap sublevel into WINED3D_LOCATION_DRAWABLE). They take care of mapping PBOs and returning the correct pointer offset (motivation: user memory and DIBs are set per subresource). There’s some wiggle room on this point though. Subresources store the container, which is a wined3d_resource *. Textures (or rather, resources) take care of allocating textures, sysmem and PBOs. subresources can request the allocation and freeing of sysmem from their container. Textures will be resources, surfaces/volumes will be subresources. Buffers will be both, and they will be their own container. Resources take care of handling WINED3D_MAP_DISCARD and allocating new sysmem / pbos if necessary.

While textures will allocate PBOs, they will allocate individual PBOs for each subresource because subresources can be mapped individually. In situations where GL_ARB_buffer_storage is available, and creating a an always-mapped PBO is feasible we can create one PBO for the entire texture and pre-map it at creation time or the first map.

The main thing where I see two options with advantages / disadvantages: Do we store DIB and User pointer in the subresource or the surface: Storing them in the surface seems like the right place at first sight because they’re surface specific. But subresources need code to copy data between buffer and sysmem, and this code can be reused for DIBs and user memory as well. In that case we’d only call volume / surface specific code for loading textures, which means that code can assume a GL context is available. In my CS code surfaces allocate DIBs, but the DIB pointer is stored in struct wined3d_sub_resource.

Somewhat related, I wonder if the hSection parameter of CreateDIBSection can be used to wrap a DIB section around our HeapAlloc’ed sysmem.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140420/4d1e4967/attachment.sig>