Update and combine HIP porting guides

[randyh62]

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update
• Continuous Integration

What were the changes?

Combined content from HIP porting guide and HIP driver porting guide.
Updated text as needed.

Why are these changes needed?

The two topics covered similar concepts, and needed to be updated.

Updated CHANGELOG?

• Yes
• No, Does not apply to this PR.

Added/Updated documentation?

• Yes
• No, Does not apply to this PR.

Additional Checks

• I have added tests relevant to the introduced functionality, and the unit tests are passing locally.
• Any dependent changes have been merged.

[j-stephan]

Good work, I think this is a really nice unification of both pages. Some remarks:

[j-stephan]

What is the second set?

[randyh62]

HIP-Clang implements two sets of APIs for launching kernels:

1. By default, when HIP-Clang encounters the <<<>>> statement in the host code, it first calls hipConfigureCall to set up the threads and grids. It then calls the stub function with the given arguments.
2. The stub function calls hipSetupArgument for each kernel argument, then calls hipLaunchByPtr with a function pointer to the stub function. In hipLaunchByPtr, the actual kernel associated with the stub function is launched.

-or-

1. By default, when HIP-Clang encounters the <<<>>> statement in the host code, it first calls hipConfigureCall to set up the threads and grids. It then calls the stub function with the given arguments. The stub function calls hipSetupArgument for each kernel argument, then calls hipLaunchByPtr with a function pointer to the stub function.
2. In hipLaunchByPtr, the actual kernel associated with the stub function is launched.

[j-stephan]

Are those distinct sets? When reading the paragraph from top to bottom, this sounds like a logical sequence of events:

• Encounter <<<>>>, then
• call hipConfigureCall for the grid configuration, then
• call the stub function, then
• call hipSetupArgument for each kernel argument, then
• call hipLaunchByPtr, then
• launch actual kernel.

I think we need some input from the HIP-Clang team here, I assume the "two sets" description comes from them.

[randyh62]

@jujiang-del or @yxsamliu can you comment on this question and the issue of the two sets of APIs for launching kernels?

[j-stephan]

Looks good overall. A few small things I've noticed:

[neon60]

Please add these changes too:
randyh62@487299f

[neon60]

@randyh62 I do not have more comments. Others looks good.

[lpaoletti]

I'm done

[emankov]

@randyh62, just a minor suggestion about PRs like this. Please separate PRs that change and move code. It would drastically save reviewing time. Thanks!