Add support for different src and dst datatypes in the SYCL implementation for pooling

[kala855]

Description

This pull request facilitates the utilization of distinct source (src) and destination (dst) datatypes during the forward inference pass within the SYCL pooling operator implementation.

[kala855]

@dzarukin We take into account what was discussed during the meeting. The PR now avoids applying pooling src:dst (u8:u8, s8:s8).

[mgouicem]

@dzarukin We take into account what was discussed during the meeting. The PR now avoids applying pooling src:dst (u8:u8, s8:s8).

Could you clarify what issue does this fix? IIUC, the main problem is in the selection of datatype for the max value computation (see this comment). In the case where both src and dst have same datatype, there should be no ambiguity.

[kala855]

@dzarukin We take into account what was discussed during the meeting. The PR now avoids applying pooling src:dst (u8:u8, s8:s8).

Could you clarify what issue does this fix? IIUC, the main problem is in the selection of datatype for the max value computation (see this comment). In the case where both src and dst have same datatype, there should be no ambiguity.

@mgouicem We received feedback mentioning that we need to avoid the use of u8:u8 and s8:s8. Maybe @dzarukin have any additional clue about it. If this combination is accepted we need to enabled it an run some tests. I am in line with your thoughts about the max value computation.

[dzarukin]

@mgouicem We received feedback mentioning that we need to avoid the use of u8:u8 and s8:s8. Maybe @dzarukin have any additional clue about it. If this combination is accepted we need to enabled it an run some tests. I am in line with your thoughts about the max value computation.

u8:s8 and s8:u8 have semantic problems.

[kala855]

@mgouicem We received feedback mentioning that we need to avoid the use of u8:u8 and s8:s8. Maybe @dzarukin have any additional clue about it. If this combination is accepted we need to enabled it an run some tests. I am in line with your thoughts about the max value computation.

u8:s8 and s8:u8 have semantic problems.

@dzarukin just to be sure ... The ones we will need to avoid are u8:s8 and s8:u8 ... However, u8:u8 and s8:s8 are allowed? The previous just to be sure we are talking about the same and proceed to do the corrections. Thank you.

[dzarukin]

@mgouicem We received feedback mentioning that we need to avoid the use of u8:u8 and s8:s8. Maybe @dzarukin have any additional clue about it. If this combination is accepted we need to enabled it an run some tests. I am in line with your thoughts about the max value computation.

u8:s8 and s8:u8 have semantic problems.

@dzarukin just to be sure ... The ones we will need to avoid are u8:s8 and s8:u8 ... However, u8:u8 and s8:s8 are allowed? The previous just to be sure we are talking about the same and proceed to do the corrections. Thank you.

Yes, those are allowed and should be supported. There's no ambiguity in such combinations - same init value is used on both ends.

[kala855]

@mgouicem We received feedback mentioning that we need to avoid the use of u8:u8 and s8:s8. Maybe @dzarukin have any additional clue about it. If this combination is accepted we need to enabled it an run some tests. I am in line with your thoughts about the max value computation.

u8:s8 and s8:u8 have semantic problems.

@dzarukin just to be sure ... The ones we will need to avoid are u8:s8 and s8:u8 ... However, u8:u8 and s8:s8 are allowed? The previous just to be sure we are talking about the same and proceed to do the corrections. Thank you.

Yes, those are allowed and should be supported. There's no ambiguity in such combinations - same init value is used on both ends.

The implementation now does what is suggested. Let me know if something else is missing @dzarukin . Thank you.