GNOME Bugzilla – Bug 706566
d3dvideosink: bufferpool implementation does not work well with device-lost/resets
Last modified: 2018-11-03 13:17:28 UTC
+++ This bug was initially created as a clone of Bug #697868 +++ Resizing requires resetting the device and all the resources allocated to this d3d pool if we use the default pool. I believe that using a managed pool instead allows resources to persists in a device reset: http://msdn.microsoft.com/en-us/library/windows/desktop/bb147168(v=vs.85).aspx "Use the D3DPOOL_MANAGED flag at creation time to specify a managed resource. Managed resources persist through transitions between the lost and operational states of the device. These resources exist both in video and system memory. A managed resource will be copied into video memory when it is needed during rendering. The device can be restored with a call to IDirect3DDevice9::Reset, and such resources continue to function normally without being reloaded with data. However, if the device must be destroyed and re-created, all resources must be re-created." We should also be using the managed for devices lost, and not recreate the device as it's done now but only reset it to reuse the existent resources. We should probably disable allowing usage of the pool outside d3dvideosink for 1.2, and then find a real solution that allows us to still continue to work zerocopy.
v4l2sink basically has the same issue, this is a general issue with the design of bufferpools.
I believe using the Managed pool can do the trick here and using textures instead offscrean surfaces, that can only be used with the default pool. I believe this is the closest thing we can have for direct rendering. If I understand the docs correctly, textures can be allocated in the device memory space when there is enough room and they will be automatically managed with devices lost, copied back to main memory and restored after the device is reset.
How are textures used compared to offscreen surfaces? Can they also be mapped to normal system memory, always?
Created attachment 253819 [details] [review] 0001-d3dvideosink-disable-buffer-pools.patch This patch disables the buffers pool for now. I have been trying to use textures instead of surfaces, but it seems like textures created in the MANAGED pool can't be locked, so it's a dead end too. There is still one last thing to test, which is using the IDirect3DDevice9Ex (with the "Ex" suffix), which does not require recreating textures after resetting the device: http://msdn.microsoft.com/en-us/library/windows/desktop/bb219800%28v=vs.85%29.aspx "In previous versions of DirectX, when an application experienced a mode change, the only way to recover was to reset the device and re-create all video memory resources and swap chains. Now with DirectX for Windows Vista, calling Reset after a mode change does not cause texture memory surfaces, textures and state information to be lost and these resources do not need to be recreated." This API is not available in windows XP so we should use a wrapper for the 2 interfaces and fallback properly in XP disabling the buffer pool. The
I think we should just stop building the binaries for Windows XP starting with 1.2 btw... having source support for XP is fine though.
Comment on attachment 253819 [details] [review] 0001-d3dvideosink-disable-buffer-pools.patch Good to commit for now, add a comment about what and why this is please, referring to this bug.
Comment on attachment 253819 [details] [review] 0001-d3dvideosink-disable-buffer-pools.patch commit ef7a8c2ca86590d994f6cf768070d75b05dd7b61 Author: Andoni Morales Alastruey <ylatuya@gmail.com> Date: Wed Aug 28 20:07:48 2013 +0200 d3dvideosink: disable buffer pools On a device lost, all the surfaces allocated in the device need to be released before resetting the device, which can't be done for the allocated buffers. https://bugzilla.gnome.org/show_bug.cgi?id=706566
Not a blocker anymore, but we should find a way to re-enable this without the negative side effects :)
Andoni, did you look more into this managed pool thing?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/106.