On 11/4/21 8:17 AM, Henri Verbeet wrote:
On Wed, 3 Nov 2021 at 21:47, Zebediah Figura zfigura@codeweavers.com wrote:
On 11/3/21 12:10 PM, Henri Verbeet wrote:
On Wed, 3 Nov 2021 at 00:20, Zebediah Figura zfigura@codeweavers.com wrote:
With the goal of making the context_vk parameter optional, so that we can allocate new BOs from the client thread.
This would mainly be for the wined3d_buffer_vk_create_buffer_object() call in patch 8/8, but in the Vulkan backend, we can always get the context through "device_vk->context_vk", provided we're inside an init_3d()/uninit_3d() pair. I.e., the Vulkan backend can make Vulkan calls from applications threads, it just needs synchronisation. I.e., I don't think the Vulkan backend needs this.
It's true that this patch series is modeled more like the GL backend than it needs to be in general.
Which, to be clear, is largely fine with me, as long as the justification is something along the lines of "consistency with the GL backend", instead of "required to do maps with a NULL context".
I had gotten the impression that we didn't want to touch wined3d_context_vk outside of the CS thread, even though it is thread safe. If that's not the case, all the better, although I'm still more than a little confused about the seemingly arbitrary division between device and context in the Vulkan adapter.
It's true that it's largely arbitrary; for the purposes of the Vulkan backend, the device and the context could/should be considered to be the same object. (And perhaps significantly, within the Vulkan backend you can get a wined3d_device_vk from a wined3d_context using CONTAINING_RECORD.) If you feel strongly about this being confusing, I'd certainly be fine with just getting rid of wined3d_context_vk, and moving everything to wined3d_device_vk. That said, there are broadly two considerations for things ending up in one or the other structure:
- Things that have direct equivalents in the OpenGL backend
generally are in the corresponding structure. E.g., "null_resources_vk" and "null_views_vk" in wined3d_device_vk are equivalents of "dummy_textures" in wined3d_device_gl; "free_*_query_pools" in wined3d_context_vk are equivalents of "free_*_queries" in wined3d_context_gl.
- Things that mostly get accessed from context functions are in
wined3d_context_vk. E.g., "vk_framebuffer" is in that category. That is itself somewhat influenced by equivalency to things in the GL backend; wined3d_context_vk_apply_draw_state() is an equivalent of context_(gl_)apply_draw_state().
The basic idea was that it would make it easier to find things for people already familiar with the GL backend; it does mean some things are somewhat arbitrary when considering the Vulkan backend on its own.
Thanks, those are good considerations.
I would indeed prefer a more functional division, if not strongly per se. I guess I'd be interested to see how helpful the current organization is to someone less familiar with the structure of wined3d...