[Question] Shared and Host Buffers can offer the same overall performance on Intel Integrated Graphics?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 15/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- performance
Research direction
Start with the sharedMemoryEffect application in the linked codeBlogArticles repository and compare its host-buffer and shared-buffer runs against the reported blog results. The issue names no Level Zero source file or test to change; done would require reproducing the memory-bound and compute-bound cases and establishing whether the observed performance is expected on Intel integrated graphics.
Written by the indexing model from the issue text.
Description
I am interested in analyzing the overall performance (end-to-end applications) when using different types of buffer allocation. I wrote this blog-entry for reference:
https://jjfumero.github.io/posts/2022/05/overall-performance-of-unified-shared-memory-level-zero/
What I saw was that running an application with host buffers offers the same performance as running with shared memory buffers. My understanding is that, when running applications using shared memory buffers, the GPU driver can migrate the buffers from the host to the device, while host memory will be accessed from the device every time a data item is required. I have two scenarios: a) memory-bound and b) compute-bound. I was surprised to see that, when running the memory-bound case, the overall performance was very similar when allocating buffers using host memory only, and shared memory only. Is this performance expected when running on Intel Integrated graphics?
If you want to reproduce all numbers, the whole application is available here: https://github.com/jjfumero/codeBlogArticles/tree/master/may2022/sharedMemoryEffect
- Dominant language
- C++
- Stars
- 335
- Forks
- 140
- Avg merge
- 12h 32m
- Merged PRs (30d)
- 5
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from oneapi-src/level-zero
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
oneapi-src/level-zero#495 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
oneapi-src/level-zero#485 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 76/100
oneapi-src/level-zero#447 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
oneapi-src/level-zero#482 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
oneapi-src/level-zero#419 ·
All issues in oneapi-src/level-zero
Similar issues
-
ai_reviewed
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
ydb-platform/ydb#53869 · 3 comments ·
-
bug cert blocker needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
project-chip/connectedhomeip#74373 ·
-
upstream update
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
conan-io/conan-center-index#31035 ·
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 85/100
vllm-project/vllm-ascend#17329 ·