public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: <cygwin-apps@cygwin.com>
Subject: Re: List [ITP],[ITA] by me
Date: Tue, 14 Feb 2023 22:33:16 +0900	[thread overview]
Message-ID: <20230214223316.f43d91bd9d2e161e445fa2df@nifty.ne.jp> (raw)
In-Reply-To: <20230214181120.b4eacba75560a6b7b1dbaea6@nifty.ne.jp>

[-- Attachment #1: Type: text/plain, Size: 4045 bytes --]

On Mon, 13 Feb 2023 18:02:27 +0000
Jon Turney wrote:
> On 06/02/2023 12:21, Takashi Yano via Cygwin-apps wrote:
> > On Sun, 5 Feb 2023 16:33:45 +0000
> > Jon Turney wrote:
> >> On 05/02/2023 08:40, Takashi Yano via Cygwin-apps wrote:
> >>> [ITP]
[...]
> >>> AMF: for ffmpeg (new)
[...]
> >>> nv-codec-headers : for ffmpeg (new)
> >>
> >> I have a question about how this (and AMF I guess) works.
> >>
> >> Are these headers which implement the whole codec? or do they expect the
> >> codec to be accessible via the driver somehow?
> > 
> > nv-codec-headers provides header files which dynamically
> > loads nvcuda.dll, nvcuvid.dll and nvEncodeAPI{,64}.dll.
> > 
> > Similary, AMF loads amfrt{64,32}.dll dinamically.
> > 
> > The codec itself is implemented in the dlls which is provided
> > by nVidia/AMD. mfx_dispatch also does the similar. It loads
> > some dlls dynamically privided by Intel.
> 
> I see.
> 
> It might be helpful to mention that (in general terms) in the 
> description for those packages.

I have added descriptions to cygport files each of AMF,
nv-codec-headers and mfx_dispatcher.

> Generally, there are some ABI concerns with using interfaces like this, 
> e.g.:
> 
> i) You need to be sure that Windows API sized types are used (e.g. 
> DWORD) rather than C ABI sized types (e.g. long)
> 
> See https://cygwin.com/faq.html#faq.programming.64bitporting

AMF:
Seems to specify the argument bit-width explicitly.

typedef uint64_t amf_uint64;
typedef AMF_RESULT (AMF_CDECL_CALL *AMFInit_Fn)(amf_uint64 version, AMFFactory **ppFactory);


nv-codec-headers:
Also specifies bit-width explicitly.

NVENCSTATUS NVENCAPI NvEncOpenEncodeSession (void* device, uint32_t deviceType, void** encoder);


mfx_dispatch:
This also specifies the bit-width explicitly.

typedef mfxI32 mfxIMPL;
typedef void (MFX_CDECL * mfxFunctionPointer)(void);
typedef struct _mfxSession *mfxSession;
typedef struct {
    mfxU32  AllocId;
    mfxU32  reserved[2];
    mfxU16  reserved3;
    mfxU16  AsyncDepth;

    union {
        mfxInfoMFX  mfx;
        mfxInfoVPP  vpp;
    };
    mfxU16  Protected;
    mfxU16  IOPattern;
    mfxExtBuffer** ExtParam;
    mfxU16  NumExtParam;
    mfxU16  reserved2;
} mfxVideoParam;

struct _mfxSession
{
    // A real handle from MFX engine passed to a called function
    mfxSession session;

    mfxFunctionPointer callTable[eVideoFuncTotal];
    mfxFunctionPointer callPlugInsTable[ePluginFuncTotal];
    mfxFunctionPointer callAudioTable[eAudioFuncTotal];

    // Current library's implementation (exact implementation)
    mfxIMPL impl;
};

FUNCTION(mfxStatus, MFXVideoENC_GetVideoParam, (mfxSession session, mfxVideoParam *par), (session, par))


> ii) Since these dynamically loaded DLLs are linked with a different C 
> runtime, one must tread carefully, as caution is required:
> 
> e.g. if an exported function returns a pointer to some memory 
> dynamically allocated using malloc(), which you are expected to release 
> with free() VERY BAD THINGS will happen when you pass it to Cygwin's 
> free() rather than the MSVCRT free() matchin the alloc() it came from.

AMF:
Seems to use the pair of malloc()/free().

static AMF_INLINE void* AMF_CDECL_CALL amf_variant_alloc(amf_size count)
{
    return malloc(count);
}
static AMF_INLINE void AMF_CDECL_CALL amf_variant_free(void* ptr)
{
    free(ptr);
}

nv-codec-headers:
Uses the pair of alloc/free function in the dll.

tcuMemAlloc_v2 *cuMemAlloc;
tcuMemFree_v2 *cuMemFree;


mfx_dispatch:
Use the pair of Alloc/Free function defined by itself.

typedef struct {
    mfxU32      reserved[4];
    mfxHDL      pthis;
    mfxStatus  (MFX_CDECL *Alloc)    (mfxHDL pthis, mfxU32 nbytes, mfxU16 type, mfxMemId *mid);
    mfxStatus  (MFX_CDECL *Lock)     (mfxHDL pthis, mfxMemId mid, mfxU8 **ptr);
    mfxStatus  (MFX_CDECL *Unlock)   (mfxHDL pthis, mfxMemId mid);
    mfxStatus  (MFX_CDECL *Free)     (mfxHDL pthis, mfxMemId mid);
} mfxBufferAllocator;



Therefore, I do not think the problems i) and ii) apply.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: nv-codec-headers.cygport --]
[-- Type: text/plain, Size: 712 bytes --]

NAME="nv-codec-headers"
VERSION=11.1.5.2
RELEASE=1
LICENSE="MIT"
CATEGORY="Devel"
SUMMARY="FFmpeg version of Nvidia Codec SDK headers"
DESCRIPTION="FFmpeg version of headers required to interface with Nvidias codec APIs. This package provides headers which loads corresponding dlls dynamically. The codec itself is implemented in the dlls and the Nvidia GPU."
HOMEPAGE="https://github.com/FFmpeg/nv-codec-headers"
ARCH="noarch" # This is noarch because it's just header files.
SRC_URI="https://github.com/FFmpeg/nv-codec-headers/archive/refs/tags/n${VERSION}.tar.gz"

SRC_DIR="${NAME}-n${VERSION}"
src_compile() {
	cd ${B}
	ln -sf ${S}/Makefile .
	ln -sf ${S}/ffnvcodec.pc.in .
	ln -sf ${S}/include .
	cygmake
}

[-- Attachment #3: AMF.cygport --]
[-- Type: text/plain, Size: 1753 bytes --]

NAME="AMF"
VERSION=1.4.29
RELEASE=1
LICENSE="MIT"
CATEGORY="Devel"
SUMMARY="Advanced Media Framework (AMF) SDK"
DESCRIPTION="A light-weight, portable multimedia framework that abstracts away most of the platform and API-specific details. AMF is supported on the closed source AMD Pro driver and OpenMax on the open source AMD Mesa driver, whose dlls are dynamically loaded by the SDK header. The codec itself is impelemted in the dlls and the AMD GPU."
HOMEPAGE="https://gpuopen.com/advanced-media-framework/"
ARCH="noarch" # This is noarch because it's just header files.

SRC_URI="${NAME}-cleaned-${VERSION}.tar.xz"

# Make dummy source file for prep if the cleaned one is not exist.
if [ ! -f ${SRC_URI} ]
then
	mkdir ${NAME}-${VERSION}
	touch ${NAME}-${VERSION}/dummy
	tar acf ${SRC_URI} ${NAME}-${VERSION}
	rm -rf ${NAME}-${VERSION}
fi

CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
	if [ $(tar tvf ../../../${SRC_URI} | wc -l) -eq 2 ] # Source file is dummy
	then
		NV=${NAME}-${VERSION}
		pushd ..
		rm -rf ${NV} # Remove dummy source file.
		# Download original source file.
		wget https://github.com/GPUOpen-LibrariesAndSDKs/AMF/archive/refs/tags/v${VERSION}.tar.gz
		tar xf v${VERSION}.tar.gz
		rm -f v${VERSION}.tar.gz
		# Remove unnecessary files.
		rm -rf ${NV}/Thirdparty ${NV}/amf/public/common ${NV}/amf/public/make ${NV}/amf/public/proj ${NV}/amf/public/props ${NV}/amf/public/samples ${NV}/amf/public/src ${NV}/amf/doc ${NV}/.github
		# Make cleaned source file which has only necessary header files.
		tar acf ../../${NAME}-cleaned-${VERSION}.tar.xz ${NV}
		popd
	fi
}

src_compile() {
	:
}

src_install() {
	mkdir -p ${D}/usr/include
	# Just make symlink for header files.
	ln -fs ${S}/amf/public/include ${D}/usr/include/${NAME}
}

[-- Attachment #4: mfx_dispatch.cygport --]
[-- Type: text/plain, Size: 575 bytes --]

NAME="mfx_dispatch"
VERSION=1.35.1
RELEASE=1
LICENSE="BSD-3-Clause"
CATEGORY="Libs"
SUMMARY="Intel MediaSDK dispatcher (Alternative to libmfx)"
DESCRIPTION="This package provides the headers and the library which loads Intel MediaSDK dlls dynamically. The codec itself is implemented in the dlls and the Intel GPU."
HOMEPAGE="https://github.com/lu-zero/mfx_dispatch"
SRC_URI="https://github.com/lu-zero/mfx_dispatch/archive/refs/tags/${VERSION}.tar.gz"

PKG_NAMES="libmfx1 libmfx-devel"
libmfx1_CONTENTS="usr/bin usr/share/doc/"
libmfx_devel_CONTENTS="usr/include/ usr/lib/"

  reply	other threads:[~2023-02-14 13:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-05  8:40 Takashi Yano
2023-02-05 16:33 ` Jon Turney
2023-02-06 12:21   ` Takashi Yano
2023-02-13 18:02     ` Jon Turney
2023-02-14  9:11       ` Takashi Yano
2023-02-14 13:33         ` Takashi Yano [this message]
2023-02-16 18:52           ` Jon Turney
2023-02-13 10:47   ` Status update (Re: List [ITP],[ITA] by me) Takashi Yano
2023-02-13 18:29     ` Jon Turney
2023-02-14  9:11       ` Takashi Yano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230214223316.f43d91bd9d2e161e445fa2df@nifty.ne.jp \
    --to=takashi.yano@nifty.ne.jp \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).