| 2016-03-04 18:31:40 |
Chris Coulson |
description |
We don't have a native GpuMemoryBuffer implementation in Oxide, instead falling back to the software implementation (using shared memory).
chrome://tracing/ shows there's a lot of contention for the GPU thread on the phone, and a not-insignificant cause of this is texture uploads. Having a native GpuMemoryBuffer implementation would significantly improve this.
What we needs is a graphics buffer that we can:
- Rasterize directly to
- Share between processes
https://01.org/blogs/2016/native-one-copy-texture-uploads-for-chrome-OS has some information about how this is implemented on the various Chrome platforms.
The attached photo (sorry, no screenshots on Freiza) shows an instance where the GPU thread is blocked for around 10ms just doing texture uploads. |
We don't have a native GpuMemoryBuffer implementation in Oxide, instead falling back to the software implementation (using shared memory).
chrome://tracing/ shows there's a lot of contention for the GPU thread on the phone, and a not-insignificant cause of this is texture uploads. Having a native GpuMemoryBuffer implementation would significantly improve this.
What we needs is a graphics buffer that we can:
- Rasterize directly to
- Share between processes
- Use as a source for EGLImage
https://01.org/blogs/2016/native-one-copy-texture-uploads-for-chrome-OS has some information about how this is implemented on the various Chrome platforms.
The attached photo (sorry, no screenshots on Freiza) shows an instance where the GPU thread is blocked for around 10ms just doing texture uploads. |
|
