blocks|key|219204|text|libdrm是一个用户空间包装器，用于执行对底层KMS驱动程序特性的细粒度访问，例如模式设置、检查所使用的平面是否是覆盖平面或主平面等，对于各种CPU/GPU/OS组合，libdrm实现通常是不同的，因为运行在内核中的h/w驱动程序倾向于支持除标准功能之外的不同功能集。使用libdrm的标准方法是打开/dev/节点中可用的drm设备，并使用从open()返回的fd执行libdrm函数调用。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|219205|通常情况下，用于特定操作系统(如X11、wayland、hardware)的显示排序软件将需要控制drm设备，这意味着非特权应用程序无法成为DRM的主程序。如果尝试使用libdrm模式的应用程序不是DRM主程序，那么大多数libdrm模式设置功能就无法工作。推荐的做法不是直接使用libdrm，而是使用标准图形库(如openGL或VULKAN+)在应用程序中准备和呈现框架。|219206|与内核DRM模块交互所需的ioctls数量很可能不是呈现高FPS应用程序时面临的最大瓶颈。在与目标系统的显示排序器协作时运行高fps应用程序的首选方法是|219207|用于呈现的双重或三重缓冲设置，其中要呈现的下一个缓冲区已准备好在当前框架完成呈现之前呈现。|unordered-list-item|219208|尽可能利用h/w加速，例如执行缩放/调整大小/图像格式转换/颜色空间转换。|219209|预计算和重用着色单元|219210|尽量重用纹理元素，而不是为呈现的每一个帧计算大量纹理。|219211|尽可能使用向量/SIMD/SSEv2、3、4/AVX/neon指令来利用现代CPU管道|219212|entityMap^0|47|5|4S|6|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|12|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|13|8|@]|D|@]|E|$]]|$1|M|3|N|5|L|7|14|8|@]|D|@]|E|$]]|$1|O|3|P|5|L|7|15|8|@]|D|@]|E|$]]|$1|Q|3|R|5|L|7|16|8|@]|D|@]|E|$]]|$1|S|3|T|5|L|7|17|8|@]|D|@]|E|$]]|$1|U|3|-4|5|6|7|18|8|@]|D|@]|E|$]]]|V|$]]

libdrm is an user space wrapper to perform fine grained access of the underlying KMS driver features like modesetting, checking if plane being used is an overlay plane or primary plane etc. libdrm implementations are generally different for various CPU/GPU/OS combinations, as the h/w driver running in kernel tend to support different set of functionalities apart from the standard ones. The standard way of working with libdrm is to open a drm device available in <code>/dev/</code> node and perform libdrm function calls using the fd returned from <code>open()</code>.
More often than not, the display compositor software for a particular OS like X11, wayland, hardware-composer will need to be in control of the drm device, which means non privileged applications have no way of being DRM master. Most of the libdrm mode setting functionalities do not work if the application trying to use them are not the DRM master. Recommended practice instead of using libdrm directly, is to use a standard graphics library like openGL or VULKAN to prepare and render frames in your application.
The number of ioctls required to interact with the kernel DRM module is most likely not the biggest bottleneck you will face when trying to render high FPS applications. The preferred way to run high fps applications while cooperating with the display compositor of the target system is to have
<ul>
<li>a double or triple buffered setup for rendering, where the next buffer to be rendered is ready to be rendered before the current frame has finished rendered.</li>
<li>Take advantage of h/w acceleration wherever possible, e.g for performing scaling/resizing/image format conversions/color space conversions.</li>
<li>Pre compute and reuse shader elements</li>
<li>Try to reuse texture elements as much as possible instead of computing a lot of textures for every frame being rendered.</li>
<li>Use vector/SIMD/SSEv2,3,4/AVX/neon instructions wherever possible to take advantage of modern CPU pipelines</li>
</ul>

This can be a silly question as I do not know much about this topic at all... It seems that user applications can talk directly to GPU to render an image, for example using OpenGL, through mesa and libdrm, where the libdrm is a wrapper around various ioctl() calls, as illustrated in <a href="https://en.wikipedia.org/wiki/Direct_Rendering_Manager#/media/File:Linux_AMD_graphics_stack.svg" rel="nofollow noreferrer">this graph</a>. Does it mean that for every new frame of a 3D game, the game application needs to call the ioctl() once (or maybe even twice if KMS needs to be reached)? That sounds like a lot of user-kernel space barrier crossing (thinking about a 120 fps game).

Does libdrm talk to kernel DRM/graphics card via ioctl()?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

这是个愚蠢的问题，因为我对这个话题不太了解.用户应用程序似乎可以通过mesa和libdrm直接与GPU对话以呈现图像，例如使用OpenGL，其中libdrm是各种ioctl()调用的包装器，如所示。这是否意味着，对于3D游戏的每一个新帧，游戏应用程序都需要调用ioctl()一次(如果需要访问KMS，甚至可能调用两次)？...

libdrm通过ioctl()与内核DRM/显卡对话吗？-腾讯云开发者社区-腾讯云

问libdrm通过ioctl()与内核DRM/显卡对话吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问libdrm通过ioctl()与内核DRM/显卡对话吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问libdrm通过ioctl()与内核DRM/显卡对话吗？
EN