Zero-copy display-buffer import for GPU rendering to avoid rutabaga_resource_transfer_read CPU readback on custom hypervisor backend
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- cpp
- Domain
- computer-graphics, performance
Research direction
Start by tracing the gfxstream path around rutabaga_resource_transfer_read and the display's sanout buffer. Determine whether the custom hypervisor backend exposes an import or shared-memory entry point for GPU rendering. Done means the display buffer can be rendered to without the GPU-to-CPU readback or copy, with performance validated on that backend.
Written by the indexing model from the issue text.
Description
We have successfully run the gfxstream solution on our self-developed hypervisor, but we've found a performance issue. The most severe one is that after the GPU finishes rendering a frame, the rendered data is read back from the GPU into the display's sanout buffer via
"rutabaga_resource_transfer_read", and this incurs significant performance overhead. So I'd like to ask: is there a way to import the display's buffer to the GPU for rendering, achieving memory sharing and avoiding this memory readback/copy?
- Dominant language
- C++
- Stars
- 60
- Forks
- 41
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 9
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing 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 google/gfxstream
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
google/gfxstream#192 · 2 comments ·
Maintainers usually reply within 2 days
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
google/gfxstream#202 · 4 comments ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
google/gfxstream#201 · 7 comments ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
google/gfxstream#199 · 4 comments ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
google/gfxstream#198 · 1 comment ·
Maintainers usually reply within 2 days
All issues in google/gfxstream
Similar issues
-
os:Linux
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
acceptable_buffer_backends: unknown backend names are silently ignoredPossibly taken @mini-1235 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
ros2/rmw_fastrtps#945 ·
Maintainers usually reply within 1 day
-
bot-triaged module: correctness (silent) module: mps module: NaNs and Infs triage review
Difficulty 2/5 Half a day Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
SCIInstitute/SCIRun#2842 ·
Maintainers usually reply within 3 days