New CSR protocal from the compiler with separated start registers

[ericxu233]

The compiler backend is now looking for support for CSR changes where we separate start into different registers rather than putting it into the CSR register. This will reduce kernel start latency since the runtime won't have to do a read before write and the CRA module would avoid a read operation which is not cheap at this moment (I think).

[ericxu233]

@pcolberg @zibaiwan This PR currently breaks runtime backwards compatibility since we added new registers to the CSR and the addresses are shifted. How should we maintain the runtime backwards compatibility going forward? The runtime must first query the CSR version before setting up the proper addresses to the registers. How would we do that?

I'm thinking of maybe adding an offset to the address once the CSR version number is set. What are your thoughts?

[zibaiwan]

Hi @ericxu233,

How should we maintain the runtime backwards compatibility going forward? The runtime must first query the CSR version before setting up the proper addresses to the registers. How would we do that?

Currently the runtime is already queries the CSR version before read/write into the CSR at here.

It is set in the kern->csr_version.

I'm thinking of maybe adding an offset to the address once the CSR version number is set. What are your thoughts?

Currently the runtime support two different CSR versions. The 4 one is the latest one created by the compiler. through the code, you should be able to see that the runtime does something different for the older CSR version 3.

#define CSR_VERSION_ID_18_1 (3) #define CSR_VERSION_ID_19_1 (4)

I assume you will need to add a #define CSR_VERSION_ID_2023_1 (5), once read the CSR version, you do something different for the CSR version 5. I think defining an OFFSET is a reasonable approach.

Best regards,

Zibai

[ericxu233]

@zibaiwan @pcolberg Ready for review now. This change preserves runtime backwards compatibility so it is safe to merge with older versions of the compiler. I believe that this needs to be merged before my compiler change goes into trunk. Also, with the new CSR version 5, forward compatibility is no longer possible (not sure if we support it in the first place). I can drop by tomorrow's runtime meeting to give a overview of the change if possible. Thanks :)

[ericxu233]

sycl-l3 passed (fixed issues related to my change): https://spetc.intel.com/testsummary?testRunIds=7158950

[zibaiwan]

@zibaiwan @pcolberg Ready for review now. This change preserves runtime backwards compatibility so it is safe to merge with older versions of the compiler. I believe that this needs to be merged before my compiler change goes into trunk. Also, with the new CSR version 5, forward compatibility is no longer possible (not sure if we support it in the first place). I can drop by tomorrow's runtime meeting to give a overview of the change if possible. Thanks :)

@ericxu233, I took a quick look of your change, they look good to me. I will take a closer took after your overview tomorrow. Thanks Eric!

[ericxu233]

@pcolberg @zibaiwan After further discussion with the compiler team, we decided to only go with the start signal change and not anything else for this release. So this is good to go in for now. The reason being is that the other signals may require more effort and redesign for the separation and not as important as the start signal.

[pcolberg]

@pcolberg @zibaiwan After further discussion with the compiler team, we decided to only go with the start signal change and not anything else for this release. So this is good to go in for now. The reason being is that the other signals may require more effort and redesign for the separation and not as important as the start signal.

Thanks @ericxu233! Could you address the comment? Other than that, this is good to go 🙂

[zibaiwan]

Thanks Eric!