SWDEV-356567 - Remove notes for limitation of using start & end events of same hipExtLaunchKernelGGL in hipEventElapsedTime. (#3032)

Change-Id: I6041f90f6e3a41d19697a31f31220aedfa5f2fa8

[ROCm/hip commit: 037cc162d0]

projects/hip/docs/markdown/hip_programming_guide.md

@@ -102,9 +102,6 @@ A stronger system-level fence can be specified when the event is created with hi
 - hipEventReleaseToSystem : Perform a system-scope release operation when the event is recorded.  This will make both Coherent and Non-Coherent host memory visible to other agents in the system, but may involve heavyweight operations such as cache flushing.  Coherent memory will typically use lighter-weight in-kernel synchronization mechanisms such as an atomic operation and thus does not need to use hipEventReleaseToSystem.
 - hipEventDisableTiming: Events created with this flag would not record profiling data and provide best performance if used for synchronization.
 
-Note, for HIP Events used in kernel dispatch using hipExtLaunchKernelGGL/hipExtLaunchKernel, events passed in the API are not explicitly recorded and should only be used to get elapsed time for that specific launch.
-In case events are used across multiple dispatches, for example, start and stop events from different hipExtLaunchKernelGGL/hipExtLaunchKernel calls, they will be treated as invalid unrecorded events, HIP will throw error "hipErrorInvalidHandle" from hipEventElapsedTime.
-
 ### Summary and Recommendations:
 
 - Coherent host memory is the default and is the easiest to use since the memory is visible to the CPU at typical synchronization points.  This memory allows in-kernel synchronization commands such as threadfence_system to work transparently.