aboutsummaryrefslogtreecommitdiffstats
path: root/tests/ref/fate/dds-rgtc2u-xy
diff options
context:
space:
mode:
authorPhilip Langdale <philipl@overt.org>2019-10-23 18:01:52 -0700
committerLynne <dev@lynne.ee>2020-02-04 23:19:48 +0000
commitd7210ce7f5418508d6f8eec6e90d978e06a2d49e (patch)
tree6390e00e0f891a774025bd5ab6d408cd05957deb /tests/ref/fate/dds-rgtc2u-xy
parentd84a30e1238b9feed1c957809108fc5e39d80629 (diff)
downloadffmpeg-d7210ce7f5418508d6f8eec6e90d978e06a2d49e.tar.gz
lavu/hwcontext: Add support for HW -> HW transfers
We are beginning to consider scenarios where a given HW Context may be able to transfer frames to another HW Context without passing via system memory - this would usually be when two contexts represent different APIs on the same device (eg: Vulkan and CUDA). This is modelled as a transfer, as we have today, but where both the src and the dst are hardware frames with hw contexts. We need to be careful to ensure the contexts are compatible - particularly, we cannot do transfers where one of the frames has been mapped via a derived frames context - we can only do transfers for frames that were directly allocated by the specified context. Additionally, as we have two hardware contexts, the transfer function could be implemented by either (or indeed both). To handle this uncertainty, we explicitly look for ENOSYS as an indicator to try the transfer in the other direction before giving up.
Diffstat (limited to 'tests/ref/fate/dds-rgtc2u-xy')
0 files changed, 0 insertions, 0 deletions