[PATCH 1/8] wined3d: Pass a wined3d_device_vk to wined3d_context_vk_create_bo().

[Henri Verbeet]

On Wed, 3 Nov 2021 at 21:47, Zebediah Figura <zfigura at codeweavers.com> wrote:
> On 11/3/21 12:10 PM, Henri Verbeet wrote:
> > On Wed, 3 Nov 2021 at 00:20, Zebediah Figura <zfigura at 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.