+static void wined3d_buffer_vk_set_bo(struct wined3d_buffer *buffer,
struct wined3d_context *context, struct wined3d_bo *bo)+{
- struct wined3d_bo_vk *prev_bo = (struct wined3d_bo_vk *)buffer->buffer_object;
- struct wined3d_context_vk *context_vk = wined3d_context_vk(context);
- struct wined3d_buffer_vk *buffer_vk = wined3d_buffer_vk(buffer);
- struct wined3d_bo_vk *bo_vk = wined3d_bo_vk(bo);
- /* We can't just copy the contents of bo_vk into buffer_vk->bo, because the
* new BO might still be in use by the client thread. We could allow both to* be valid, although knowing when to destroy a BO then becomes tricky, and* ensuring it's not mapped more than once also becomes tricky. */
Would it make sense then to either make "buffer_vk->bo" a pointer, or get rid of it entirely? Right now, we're handling the initial bo different from subsequent ones, and I'm not sure there's a good reason to justify that.
Incidentally, now that we have an actual wined3d_bo structure, it would probably make sense to change the type of "buffer_object" in e.g. struct wined3d_buffer, struct wined3d_bo_address, etc. from uintptr_t (and variants) to a wined3d_bo pointer. That's not a prerequisite for this series, but would probably be a nice cleanup.
@@ -3121,12 +3124,20 @@ static bool wined3d_cs_map_upload_bo(struct wined3d_device_context *context, str { /* Limit NOOVERWRITE maps to buffers for now; there are too many ways that * a texture can be invalidated to even count. */
- if (wined3d_map_persistent() && resource->type == WINED3D_RTYPE_BUFFER && (flags & WINED3D_MAP_NOOVERWRITE))
if (wined3d_map_persistent() && resource->type == WINED3D_RTYPE_BUFFER
&& (flags & (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE))){ struct wined3d_client_resource *client = &resource->client;
struct wined3d_device *device = context->device; const struct wined3d_bo *bo; uint8_t *map_ptr;if (flags & WINED3D_MAP_DISCARD){if (!device->adapter->adapter_ops->adapter_alloc_bo(device, resource, sub_resource_idx, &client->addr))return NULL;}
Returning NULL here works, but "false" would be more appropriate.