Investigate avoiding freeing/reallocating memory in dxvav2 |
|
Issue descriptionInvestigate avoiding freeing/reallocating memory in dxvav2. During our recent VideoStack power sprint: https://docs.google.com/document/d/1bLWt_Eks4DYPYTthJGMNg1z8WIu4q7DqgaYqpLdm05E/edit?ts=5977880b# we discovered that we were freeing and reallocating memory more often than we should be during video playback. Each time we free memory, Windows has a process that zeroes out the memory before handing it to another process, and this operation is a bit expensive. dalecurtis@ mentioned that sandersd@ was working on a refactor called "DXVAv2" or "MojoVideoDecoder" (or something like that) what would solve this problem. We would like to track that work to make sure that it has performance improvements. brucedawson@ noticed that behavior and can answer questions about it.
,
Jul 25 2017
In any case the VDAv2 work I mentioned is that we'll have a ring buffer which is always kept mapped and only unmap when we need a larger ring buffer.
,
Jul 26 2017
> Is this specifically that each ShMem::Unmap() requires clearing? Any time pages containing private data are freed (returned to the OS) they must be zeroed before they can be reused. There is also some cost associated with removing pages from the process MMU tables, and soft-faulting in pages on first access. These costs are not enormous but they are frequently overlooked because they are hard to see, especially the page zeroing cost (happens in the system process usually) and the faulting in cost (it's smeared out over the code that uses the memory, making some memory accesses much more expensive). I can get more details on what the estimated cost is so that we can decide whether it is reasonable. But a ring buffer would neatly avoid the problem so maybe it isn't necessary.
,
Mar 8 2018
Current status: D3D11VideoDecoder is in progress, should not suffer from this issue due to use of a ring buffer for bitstream IPC. Other VDAs are still going to be allocating SHM but not passing it between processes. The next step then is to introduce a memory abstraction to allow them to use non-SHM transparently, which will solve all the media stack use cases. (PPAPI use of SHM will probably never be fixed.) |
|
►
Sign in to add a comment |
|
Comment 1 by dalecur...@chromium.org
, Jul 25 2017