Description

Fixed an out-of-bounds memory access in the VectorAdd example when launching multiple work-groups.

Previously each work-group calculated its starting offset as group_id * N, even though the input and output buffer contained only N elements.

Result - Work-groups with group_id > 0 tried access memory beyond the allocated buffer, which caused UR_RESULT_ERROR_DEVICE_LOST.

Fix - The kernel now uses the global work-item ID and global range to distribute the N elements work-items using a grid stride loop. This ensures the buffers accesses are within the boundary.

Type of change

Please delete options that are not relevant. Add a 'X' to the one that is applicable.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Implement fixes for ONSAM Jiras

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Command Line
• oneapi-cli
• Visual Studio
• Eclipse IDE
• VSCode
• When compiling the compliler flag "-Wall -Wformat-security -Werror=format-security" was used

Security and Legal

• OSPDT Approval (see Project Manager for assistance)
• Compile using the following compiler flags and fix any warnings, the falgs are: "/Wall -Wformat-security -Werror=format-security"
• Bandit Scans (Python only)
• Virus scan

Review

• Review DPC++ code with Paul Peterseon. (GitHub User: pmpeter1)
• Review readme with Tom Lenth(@tomlenth) and/or Project Manager
• Tested using Dev Cloud when applicable