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

[Zebediah Figura]

On 11/4/21 8:17 AM, Henri Verbeet wrote:
> 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.
> 

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...