Confirmed users
138
edits
Platform/GFX/textures: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(Created page with " == TextureClient & TextureHost == TextureClient and TextureHost are the way to share texture memory accross threads or processes. == New vs Deprecated textures == Depreact...") |
No edit summary |
||
| Line 50: | Line 50: | ||
The items below are things we want to do with new textures, but if we don't do them we will still be on par with the deprecated textures. So I expect them to be lower priority, at this point we are mostly interested in the items above. | The items below are things we want to do with new textures, but if we don't do them we will still be on par with the deprecated textures. So I expect them to be lower priority, at this point we are mostly interested in the items above. | ||
=== Remove GrallocBufferActor (Bug 879681) === | |||
Gralloc buffer actor is the source of a lot our gralloc related problems. The main problem is that it does not have any memory management (it is not ref counted and there is no ownership defined even though a lot of objects on different thread and processes are holding pointer to it). android::GraphicBuffer on the other hand, has builtin cross-process reference counting which is great except that by wrapping the safely manageed GraphicBuffer in an unsafe non-managed GrallocBufferActor we completely loose the benefits of GraphicBuffer. | |||
GrallocBufferActor was not just a gratuitous evil decision, it serves one purpose that we should keep in mind when we remove it: when we send a gralloc buffer accross IPC we need to do some file descriptor serialization/decerialization that has an overhead, so instead of sending the GraphicBuffer every time, we create the it at the same time as the GrallocBufferActor and we use the GrallocBufferActor as a way to pass the buffer though IPC (matching IPDL actors is faster than doing the FD serialization dance). | |||
The most important aspect of this work is to ensure that objects that need to hold references to gralloc buffers hold references to a reference counted object, even if this object wraps the GrallocBufferActor as a first step. This reference counted object would be GrallocTextureClient, because it has a well defined life-time protocol that is flexible enough to cover all the edge cases that we have met so far. | |||
Once all user of gralloc are doing so through GrallocTextureClientOGL, most of the ownership bugs should be fixed, and the hardest part is done because we then just have to replace GrallocBufferActor by a more genric PTexture protocol that would serve the same purpose also with all the other texture types. | |||
=== Implement partial updates for DataTextureSource implementations === | === Implement partial updates for DataTextureSource implementations === | ||
This will let us use IncrementalContentHost for non-OpenGL backends. | This will let us use IncrementalContentHost for non-OpenGL backends. | ||
This doesn't have any dependency but will not be useful before | This doesn't have any dependency but will not be useful before IncrementalContentHost is ported to the new textures. | ||
* DataTextureSourceD3D11 | * DataTextureSourceD3D11 | ||
* DataTextureSourceBasic | * DataTextureSourceBasic | ||
=== Implement cross-process locks for TextureClient/TextureHost === | === Implement cross-process locks for TextureClient/TextureHost (Bug 902169) === | ||
Having them would let us have more choice in the treade-off speed vs memory usage. | Having them would let us have more choice in the treade-off speed vs memory usage. | ||
They can be implemented in parallel, should be really low priority. | They can be implemented in parallel, should be really low priority. | ||
| Line 76: | Line 87: | ||
=== Make it possible for several compositables to use the same Texture. === | === Make it possible for several compositables to use the same Texture. === | ||
We need to do this by replacing the pair {PCOmpositable, ID} by a proper PTexture IPDL actor to refer to texture clients and host accros IPC. | |||
This will be a big performance win in certain specific cases, and let us implement the "Texture atlas" optimization for mobile platforms where we want to reduce the number of draw calls. | This will be a big performance win in certain specific cases, and let us implement the "Texture atlas" optimization for mobile platforms where we want to reduce the number of draw calls. | ||
This doesn't have dependencies, although we'll probably see clearer when more compositables are ported? I expect ImageClient/Host to be the only compositable that would use it at least at first, but I may be wrong. See bug 897452 | This doesn't have dependencies, although we'll probably see clearer when more compositables are ported? I expect ImageClient/Host to be the only compositable that would use it at least at first, but I may be wrong. See bug 897452 | ||