libdrm 完全分析 29 - 完全なソース コード分析 (26)

前回記事:  libdrm 二十八の完全解析 -- ソースコードの完全解析 (25)からの続きです。

この記事は次のブログ投稿を参照しています。

DRMドライバー開発(VKMS)

どうもありがとうございます!

前の記事では _drmModeGetConnector 関数について説明しましたが、この記事では引き続きDRMの一般的なプロセスの次のステップについて説明します。理解を容易にするために、一般的なプロセスの例を再度掲載します。

int main(int argc, char **argv)
{
	/* open the drm device */
	open("/dev/dri/card0");
 
	/* get crtc/encoder/connector id */
	drmModeGetResources(...);
 
	/* get connector for display mode */
	drmModeGetConnector(...);
 
	/* create a dumb-buffer */
	drmIoctl(DRM_IOCTL_MODE_CREATE_DUMB);
 
	/* bind the dumb-buffer to an FB object */
	drmModeAddFB(...);
 
	/* map the dumb buffer for userspace drawing */
	drmIoctl(DRM_IOCTL_MODE_MAP_DUMB);
	mmap(...);
 
	/* start display */
	drmModeSetCrtc(crtc_id, fb_id, connector_id, mode);
}

次のステップは drmIoctl(DRM_IOCTL_MODE_CREATE_DUMB) です。

78. DRM_IOCTL_MODE_CREATE_DUMB

78 番目のマクロは DRM_IOCTL_MODE_CREATE_DUMB で、対応するコードは次のとおりです。

#define DRM_IOCTL_MODE_CREATE_DUMB DRM_IOWR(0xB2, struct drm_mode_create_dumb)

前の記事の _IOWR(type,nr,size) の最終定義と組み合わせると、次のコードが得られます。

#define DRM_IOCTL_MODE_CREATE_DUMB        ( ((3)  << 30) | (('d') << 8) | ((0xB2)   << 0) | ((sizeof(struct drm_mode_create_dumb)) << 16) )

struct drm_mode_create_dumb は同じファイル (include/drm/drm.h) で定義されており、コードは次のとおりです。

/* create a dumb scanout buffer */
struct drm_mode_create_dumb {
	__u32 height;
	__u32 width;
	__u32 bpp;
	__u32 flags;
	/* handle, pitch, size will be returned */
	__u32 handle;
	__u32 pitch;
	__u64 size;
};

DRM_IOCTL_MODE_CREATE_DUMB に対応するユーザー空間 API は、drmModeCreateDumbBuffer() です。この関数は xf86drmMode.c にあり、コードは次のとおりです。

drm_public int
drmModeCreateDumbBuffer(int fd, uint32_t width, uint32_t height, uint32_t bpp,
                        uint32_t flags, uint32_t *handle, uint32_t *pitch,
                        uint64_t *size)
{
	int ret;
	struct drm_mode_create_dumb create = {
		.width = width,
		.height = height,
		.bpp = bpp,
		.flags = flags,
	};

	ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_CREATE_DUMB, &create);
	if (ret != 0)
		return ret;

	*handle = create.handle;
	*pitch = create.pitch;
	*size = create.size;
	return 0;
}

DRM_IOCTL の定義は同じファイル内にあり、コードは次のとおりです。

static inline int DRM_IOCTL(int fd, unsigned long cmd, void *arg)
{
	int ret = drmIoctl(fd, cmd, arg);
	return ret < 0 ? -errno : ret;
}

DRM_IOCTL 関数は、実際には drmIoctl 関数のカプセル化層です。

drmModeCreateDumbBuffer 関数の役割は、ダム バッファ オブジェクトを作成することです。

ここで、DUMB Buffer についての知識を追加したいと思います。

DUMB バッファ
「DUMB」という単語の意味を調べるために Baidu 翻訳にアクセスすると、次の 2 つの説明が得られます。

1.「ダム」 2.「ダム」
ダムバッファ?なんてこった!Ubuntu で man drm-memory コマンドを実行すると、Dumb-Buffer に関する次の説明が表示されます。

これらのバッファは mmap(2) を介してメモリ マップできるため、CPU 上でバッファをレンダリングできます。ただし、これらのバッファーへの GPU アクセスは、多くの場合不可能です。

一般的な考え方は、バッファーは通常、GPU ハードウェア アクセラレーションには使用できず、CPU によってのみ使用できるということです。しかし、なぜハードウェア アクセラレーションに使用できないバッファをダム バッファと呼ぶのでしょうか? なぜそれを単純なバッファと呼ばないのでしょうか? ここでの「バカ」という言葉は一体何を意味するのでしょうか?実際、これは 1980 年代の VGA グラフィックス カードに始まります。
当時のグラフィックスカードは、小さなビデオメモリ(通常は640x480)とデジタルアナログ変換回路(DAC)で構成されており、端的に言えばフレームバッファ+ディスプレイコントローラでした。グラフィックスカードの機能は非常にシンプルで、ビデオメモリ内の画像データをRGB信号に変換して送り出すだけで、描画処理はすべてCPUに引き渡されて完了します。この種のグラフィックス カードは業界では VGA カードと呼ばれ、そのビデオ メモリは「ダム フレーム バッファ」と呼ばれます。その後、グラフィックス カード テクノロジの継続的な発展に伴い、当初 CPU によって実行されていた多くのタスクが徐々にグラフィックス カードに置き換えられました。当初特定の描画命令 (点や線の描画など) をサポートしていたグラフィックス カードから、後にビデオ デコードをサポートするビデオ カード、そして複雑な 3D レンダリング命令 (OpenGL など) をサポートする最新の GPU グラフィックス カードに至るまで、CPU の重いタスクは絵を描くことが完全に解放されます。VGA カードと比較して、以降のグラフィックス カードのビデオ メモリは、業界では「スマート フレーム バッファ」と呼ばれています。まず、この2つのタイトルから、ダムはスマートの対義語であることがわかります。したがって、ここでのダムの説明は、「愚か」ではなく、「愚かな」または「愚かな」というべきです。

drmModeCreateDumbBuffer 関数の詳細な分析は次の記事で実行されます。

おすすめ

転載: blog.csdn.net/phmatthaus/article/details/132563206