HLSL -> MSL: raster_order_group annotation

[jesusdz]

Hi there!

We're trying to add support for raster order groups while translating from HLSL to MSL, which is currently missing in SPIRV-Cross apparently.

We compilie HLSL -> SPIRV, then use SPIRV-Cross to generate SPIRV -> MSL, so ideally, we think it would be convenient to annotate HLSL in a way similar to this:

// 5635 is the number for DecorationUserSemantic / DecorationHlslSemanticGOOGLE
struct GBuffer
{
	[[vk::location(0), vk::ext_decorate_string(5635, "raster_order_group(0)")]]	float4 rt0 : SV_TARGET0;
	[[vk::location(1), vk::ext_decorate_string(5635, "raster_order_group(0)")]]	float4 rt1 : SV_TARGET1;
	[[vk::location(2), vk::ext_decorate_string(5635, "raster_order_group(0)")]]	float4 rt2 : SV_TARGET2;
	[[vk::location(3), vk::ext_decorate_string(5635, "raster_order_group(1)")]]	float4 rt3 : SV_TARGET3;
};

so an OpMemberDecorate with the user semantic is embedded into the SPIRV. Having this, we could introduce some changes into SPIRV-Cross to finally produce some MSL like this:

struct ps_main_out
{
    float4 out_var_SV_TARGET0 [[color(0), raster_order_group(0)]];
    float4 out_var_SV_TARGET1 [[color(1), raster_order_group(0)]];
    float4 out_var_SV_TARGET2 [[color(2), raster_order_group(0)]];
    float4 out_var_SV_TARGET3 [[color(3), raster_order_group(1)]];
};

I am not sure this is the better approach to achieve this. Is it possible there's a better approach rather than introducing this kind of hacky annotation in the SPIRV code?

Cheers!

[HansKristian-Work]

I think for this to make sense, you'd need DecorationUserSemantic and add some kind of special prefix that SPIRV-Cross can sniff out, ala "spirv-cross.msl.raster_order_group(0)" or something like that and those special decorations get plumbed through.

However, spirv-cross already supports fragment_shader_interlock in MSL, which is what raster order groups do. What do you need raster order group on fragment shader outputs for? That doesn't make much sense to me, but it's years since I looked at raster order group code, so I might be misunderstanding something here.

Without a strong reason to do backdoors like this, I'd be reluctant to support this as-is.