没有X硬件加速 [英] Hardware acceleration without X

问题描述

我不知道是否有可能获得图形硬件加速没有了Xorg和DDX驱动程序，只有内核模块和用户空间驱动程序的其余部分。我问这个，因为我开始到嵌入式平台上开发（类似的BeagleBoard以上大致与集成GPU德州仪器ARM芯片），我会得到硬件加速没有图形服务器的开销（即不需要）。

I was wondering if it would be possible to get graphical hardware acceleration without Xorg and its DDX driver, only with kernel module and the rest of userspace driver. I'm asking this because I'm starting to develop on an embedded platform (something like beagleboard or more roughly a Texas instruments ARM chip with integrated GPU), and I would get hardware acceleration without the overhead of a graphical server (that is not needed).

如果是，如何？我在想OpenGL或OpengGLES实现，或者嵌入的Qt的http://harmattan-dev.nokia.com/docs/library/html/qt4/qt-embeddedlinux-accel.html

If yes, how? I was thinking about OpenGL or OpengGLES implementations, or Qt embedded http://harmattan-dev.nokia.com/docs/library/html/qt4/qt-embeddedlinux-accel.html

和TI提供了大量文档，但仍不清楚我
的http://processors.wiki.ti.com/index.php/Sitara_Linux_Software_Developer%E2%80%99s_Guide

And TI provides a large documentation, but still is not clear to me http://processors.wiki.ti.com/index.php/Sitara_Linux_Software_Developer%E2%80%99s_Guide

感谢您。

推荐答案

的答案的将取决于你的用户应用程序。如果一切的裸机的和您的应用程序的小组正在编写的一切，在 DirectFB的API 可以作为弗雷德里克建议使用。如果你使用GTK的帧缓冲区的版本，这可能是特别有趣。

The answer will depend on your user application. If everything is bare metal and your application team is writing everything, the DirectFB API can be used as Fredrik suggest. This might be especially interesting if you use the framebuffer version of GTK.

不过，如果您使用的是Qt的，那么这是不是最佳的前进道路。 Qt5.0摒弃了QWS（的Qt嵌入式加速 ）。 Qt是迁移到的灯塔的，现在被称为 QPA 。如果你写一个的 QPA 的插件，您所揭露的任何内核机制使用您的图形加速，那么你的加速的Qt的图形。同样有趣的可能是韦兰架构;有 QPA 插件韦兰。支持存在的 QPA 在Qt4.8 +和Qt5.0 +。 Sk​​ia的也与一个OpenGL的后台支持，一个有趣的图形API; Skia的所使用的Andr​​oid设备。

However, if you are using Qt, then this is not the best way forward. Qt5.0 does away with QWS (Qt embedded acceleration). Qt is migrating to LightHouse, now known as QPA. If you write a QPA plug-in that uses your graphics acceleration by whatever kernel mechanism you expose, then you have accelerated Qt graphics. Also of interest might be the Wayland architecture; there are QPA plug-ins for Wayland. Support exists for QPA in Qt4.8+ and Qt5.0+. Skia is also an interesting graphics API with support for an OpenGL backend; Skia is used by Android devices.

获得图形加速很容易。你想合成？什么是你的记忆足迹？谁是你的观众开发商将编制到的 API 的？你需要的对象的功能或只是绘制图元？之间有很大的区别的 Skia的的 PegUI 的 WindML 的和完全成熟的图形框架（GTK，Qt的）所有的部件和动态效果，今天的人们的期望。编程到的OpenGL ES API 可能乍一看很好，但如果你的应用有什么你的复杂性将需要更丰富的图形框架;天色重新进行迭代的垫皮特森的评论。

Getting graphics acceleration is easy. Do you want compositing? What is your memory foot print? Who is your developer audience that will program to the API? Do you need object functionality or just drawing primitives? There is a big difference between SKIA, PegUI, WindML and full blown graphics frameworks (Gtk, Qt) with all the widget and dynamics effects that people expect today. Programming to the OpenGL ES API might seem fine at first glance, but if your application has any complexity you will need a richer graphics framework; Mostly re-iterating Mats Petersson's comment.

编辑：从的Qt嵌入式加速链接，

1. CPU阻击 - 最慢


2. 硬件阻击 - 例如，DirectFB的。快速的内存位老年退休金计划通常是运动，而不是机器的话，就像DMA。


3. 2D矢量 - OpenVG的，线条人物图画，有位操作
。

4. 3D绘图 - 的OpenGL（ES）的多边形填充等
。

1. CPU blitter - slowest
2. Hardware blitter - Eg, directFB. Fast memory movement usually with bit ops as opposed to machine words, like DMA.
3. 2D vector - OpenVG, Stick figure drawing, with bit manipulation.
4. 3D drawing - OpenGL(ES) has polygon fills, etc.

这是绘制要执行的类型。一个框架喜欢的的Qt 和的Gtk 的，举一个API把一个单选按钮，复选框，编辑框等在屏幕上。它还具有文本和一个键盘，鼠标和/或触摸屏等元素相互作用的造型。 A 框架的使用绘图引擎放的对象的屏幕上。

This is the type of drawing you wish to perform. A framework like Qt and Gtk, give an API to put a radio button, checkbox, editbox, etc on the screen. It also has styling of the text and interaction with a keyboard, mouse and/or touch screen and other elements. A framework uses the drawing engine to put the objects on the screen.

图形加速只是把算法，如在一个单独的CPU一个布氏算法或专用硬件。如果你选择的是框架不支持的 3D 的对象，框架不太可能需要OpenGL的支持和可以不执行任何好转。

Graphics acceleration is just putting algorithms like a Bresenham algorithm in a separate CPU or dedicated hardware. If the framework you chose doesn't support 3D objects, the frameworks is unlikely to need OpenGL support and may not perform any better.

拼图的最后一块是窗口管理器。许多嵌入式设备不需要这个。然而，许多手机正在使用的合成的和的字母的值来创建透明窗口，并允许在同一时间待观察多个应用程序。这也可能会影响你的图形API。

The final piece of the puzzle is a window manager. Many embedded devices do not need this. However, many handset are using compositing and alpha values to create transparent windows and allow multiple apps to be seen at the same time. This may also influence your graphics API.

此外： DRI没有X 给出了一些令人信服的理由，为什么这可能不是一件好事去做;用于单个用户的任务的情况下，在 DRI 甚至没有必要的。

Additionally: DRI without X gives some compelling reasons why this might not be a good thing to do; for the case of a single user task, the DRI is not even needed.

下面是一个韦兰图形堆栈一个的博客上韦兰。

The following is a diagram of a Wayland graphics stack a blog on Wayland.

这篇关于没有X硬件加速的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！