It makes sense to add new files here as C++ files IMO.

Adding curves specific fields here suggests to me that the abstraction is premature. Can we store this elsewhere or avoid the abstraction in this case?

Usually type names use pascal case: AttributeTypeConvertor
Might make sense to add GPU or DRW at the front though, since this has a very specific purpose.

This section is empty

I see why you did it this way, but most of this attribute retrieval strikes me as a solved problem that can be written at a much higher level without a performance cost. I would suggest keeping the actual attribute name around and using it to retrieve the data from CurveComponent with the specified type.

Some variant of the following code will retrieve the attribute and convert it to the color type, using the existing attribute API. In the future the CurveComponent won't be necessarily because the same attribute API will be accessible directly on bke::CurvesGeometry

CurveComponent component;
component.replace(const_cast<Curves *>(&curves), GeometryOwnershipType::ReadOnly);

...

/* TODO(@kevindietrich): float4 is used for scalar attributes as the implicit conversion done
 * by OpenGL to vec4 for a scalar `s` will produce a `vec4(s, 0, 0, 1)`. However, following
 * the Blender convention, it should be `vec4(s, s, s, 1)`. This could be resolved using a
 * similar texture as for volume attribute, so we can control the conversion ourselves. */
blender::VArray<ColorGeometry4f> attribute = component.attribute_get_for_read<ColorGeometry4f>(
    request.sampler_name, request.domain, {0.0f, 0.0f, 0.0f, 1.0f});

MutableSpan<ColorGeometry4f> vbo_span{
    static_cast<ColorGeometry4f *>(GPU_vertbuf_get_data(attr_vbo)),
    component.attribute_domain_num(request.domain)};

attribute.materialize(vbo_span);

Some comments on these fields would help distinguish them, it's not obvious without further investigation.

A comment should explain the actual reasoning for the mutex, rather than "some thread-safety". I guess it's something like "The same curves might be used for multiple objects with different materials" or something? I'm not sure though, because I thought the draw manager's object iteration was single threaded. batch_cache would have the same problem.

Add the uniform here using info.push_constant(). Ideally, you should group all uniforms inside a uniform buffer like volume object do. See draw_volume_infos for more info.

Define them using the shaderCreateInfo instead of using ifdef and glsl strings. See my other comment.

Remove that define from here. No need to provide a boolean to the load function. Look at how volume rendering does that.

I agree, it is a bit convoluted and hidden from first sight but I would like to keep it as implementation details of the renderer than of then codegen.

I notice the exact same function is added in shadow_vert.glsl. Should it be implemented somewhere else and deduplicated?

I know this isn't my area, but given the rather vague function name, I'd imagine a comment would be helpful (I'm not sure of the purpose of this right now).

This funkyness with ATTR_DOMAIN_NUM seems unnecessary here. There are three cases, point, curve, and "other/invalid". In the third case, continue is used, so the following code will never see an invalid value, and domain doesn't need to have an initialized value at the start of the function.

The style guide mentions that signed integers should be used for indices.

Is there a reason to not just use std::unique_ptr?

Thanks for adding the comments here. I'm sure it will save people lots of time in the future.

You could also add the units of last_attr_matching_time, I assumed it is a frame?

Could probably just forward declare the type to avoid the need to cast?

It feels quite wrong to add functionality and a comment we know is incorrect, even if it's planned to change in the future. Also, I think the whole mesh batch cache creation isn't threadsafe anyway, so it seems a bit early to try to make a single part of the API threadsafe without a clear written for how plan for multi-threaded object processing will be implemented.

If we really have to include this now, the state should be made much clearer with comments.