On Thu, 18 Nov 2021 at 01:09, Zebediah Figura zfigura@codeweavers.com wrote:
@@ -5123,12 +5123,12 @@ void wined3d_context_gl_load_tex_coords(const struct wined3d_context_gl *context TRACE("Setting up texture %u, idx %u, coord_idx %u, data %s.\n", texture_idx, mapped_stage, coord_idx, debug_bo_address(&e->data));
bo = wined3d_bo_gl_id(e->data.buffer_object);if (*current_bo != bo)
bo_gl = wined3d_bo_gl(e->data.buffer_object);if (*current_bo != bo_gl->id) {
I think "e->data.buffer_object" can be NULL here.
@@ -5137,7 +5137,7 @@ void wined3d_context_gl_load_tex_coords(const struct wined3d_context_gl *context /* The coords to supply depend completely on the fvf/vertex shader. */ format_gl = wined3d_format_gl(e->format); gl_info->gl_ops.gl.p_glTexCoordPointer(format_gl->vtx_format, format_gl->vtx_type, e->stride,
e->data.addr + state->load_base_vertex_index * e->stride);
bo_gl->b.memory_offset + e->data.addr + state->load_base_vertex_index * e->stride);
I think it's a little unfortunate to use "memory_offset" here. (And I don't think the original version of these patches did that.) The "memory_offset" field contains the offset from the start of the underlying memory allocation (i.e., VkDeviceMemory in Vulkan), while "buffer_offset" is the offset from the start of the buffer object (i.e., VkBuffer in Vulkan). We're addressing relative to the buffer object here.
Of course, in OpenGL, these are generally the same. (But, note that GL_EXT_memory_object exists.) For clarity though, it seems preferable to use these in a consistent way between the Vulkan and GL backends.