| Commit message (Collapse) | Author | Age |
|
|
|
| |
This patch allows for alternative loader implementations.
|
|
|
|
|
|
|
| |
Announced in 14040a1d913794d9a3fd6406a6d8c2f0e37e0062.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
| |
Signed-off-by: James Almer <jamrial@gmail.com>
|
| |
|
| |
|
|
|
|
|
| |
At least on Turing, a frame without 512 byte alignment cannot be passed
to cuTexObjectCreate.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows for users who derive devices to set options for the
new device context they derive.
The main use case of this is to allow users to enable extensions
(such as surface drawing extensions) in Vulkan while deriving from
the device their frames are on. That way, users don't need to write
any initialization code themselves, since the Vulkan spec invalidates
mixing instances, physical devices and active devices.
Apart from Vulkan, other hwcontexts ignore the opts argument since they
don't support options at all (or in VAAPI and OpenCL's case, options are
currently only used for device selection, which device_derive overrides).
|
| |
|
|
|
|
|
| |
Gets rid of some mostly duplicated code and adds the ability to do
hardware to hardware transfers.
|
|
|
|
| |
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
|
|
|
|
|
| |
There's enough going on here now that it should not be duplicated
between cuda_device_create and cuda_device_derive.
|
|
|
|
|
|
|
|
|
|
| |
This commit adds the necessary code to initialize and use a Vulkan device
within the hwcontext libavutil framework.
Currently direct mapping to VAAPI and DRM frames is functional, and
transfers to CUDA and native frames are supported.
Lets hope the future Vulkan video decode extension fits well within this
framework.
|
|
|
|
| |
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
|
|
|
|
|
|
|
| |
Similarly to the previous changes, we don't need to synchronise
after a memcpy to device memory. On the other hand, we need to
keep synchronising after a copy to host memory, otherwise there's
no guarantee that subsequent host reads will return valid data.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a pattern of wrapping CUDA calls to print errors and
normalise return values that is used in a couple of places. To
avoid duplication and increase consistency, let's put the wrapper
implementation in a shared place and use it everywhere.
Affects:
* avcodec/cuviddec
* avcodec/nvdec
* avcodec/nvenc
* avfilter/vf_scale_cuda
* avfilter/vf_scale_npp
* avfilter/vf_thumbnail_cuda
* avfilter/vf_transpose_npp
* avfilter/vf_yadif_cuda
|
|
|
|
|
|
| |
Regression since ece068a771ac3f725e854c681ecbef08e792addc.
Signed-off-by: Marton Balint <cus@passwd.hu>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
|
|
|
|
| |
Signed-off-by: Philip Langdale <philipl@overt.org>
|
|
|
|
| |
Copied and modified from hwcontext_qsv.c.
|
| |
|
|
|
|
|
| |
CUVID is now capable of returning 10bit and 12bit decoded content
in P010/P016. Let's support transfering those formats.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
* commit '2e219b491bcc0845248345fdad31231b081e06d1':
hwcontext_cuda: implement device creation
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
| | |
|
|/
|
|
|
|
|
| |
* commit 'ad884d100259e55cb51a4239cd8a4fd5154c2073':
hwcontext: add a CUDA implementation
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
|