Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
04-23-2011, 03:54 AM
|
#1
|
Member
Registered: Dec 2004
Distribution: Kubuntu
Posts: 62
Rep:
|
Hardware acceleration using OpenGL and X11
Hi! Is there anyone who can explain how OpenGL acceleration works on Linux and its relationship with X11?
I read about modules like GLX, DRI, DRM and Gallium and I understand they are necessary to provide performance as the current structure of X11 makes it difficult to render efficiently. Is this correct?
If I use the OpenGL and EGL drivers provided by the manufacturer of hardware on X11 without any other module, should I expect, even with hardware acceleration a high CPU load? The modules GLX, DRI, DRM etc... can be used with any OpenGL implementations or only with mesa?
Thanks for many info! There is a hell of concepts here and I'm quite confused.
|
|
|
04-23-2011, 08:05 PM
|
#2
|
Senior Member
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Bookworm (Fluxbox WM)
Posts: 1,391
|
The OpenGL standard is an API defining an abstract 3D language (the other common API being Microsoft's Direct3D). Since the X11 standard was much earlier, it has no 3D features, so OpenGL has become the common way of providing these.
Since we want to have 3D within X11 windows, there has to be a way for OpenGL implementations to operate underneath X11. GLX provides extensions to X11 to provide this functionality, ie taking client OpenGL calls and passing them on to the OpenGL libraries, which can also involve encapsulating these commands to be passed across a network connection.
Mesa3D is an free/libre implementation of the OpenGL standard. It takes OpenGL calls, and passes them on to appropriate rendering libraries. Initially it was a software library, ie, using the CPU to do the rendering (not accelerated), which meant that OpenGL applications could be run on most hardware. Since then, support for GPU accelerated drivers has been added.
The DRI driver is used by Mesa3D for this GPU accelerated rendering. DRI is an infrastructure that coordinates the direct access to the hardware required for this accelerated rendering (both direct memory access and GPU access).
The evolution of Mesa has resulted in the development of Gallium3D (now a part of the whole Mesa project). The Gallium library is effectively a refactoring of the Mesa system, to capitalize on commonalities between different graphics cards. Under Gallium, the DRI has been separated into two parts, DRM to handle the direct access to memory, and DRI2 to handle direct access to the GPU acceleration. Because Gallium provides an abstract low level graphics API to the drivers, the implementation of the connection between OpenGL and the low level API is now consistent between graphics cards.
So to answer your questions, if you are running OpenGL applications under X11, you will normally be using GLX to manage the 3D commands, and Mesa/Gallium to implement them, no matter what underlying acceleration you have (if any). Below that will be the drivers from the manufacturers. If your graphics is being hardware accelerated, you should see a substantial reduction in CPU load; though this will depend on the application (for example, a lot of physics simulation in games is still done on the CPU). The program glxinfo (part of the mesa-utils package) is useful for determining what acceleration your OpenGL implementation is providing.
Last edited by neonsignal; 04-23-2011 at 08:28 PM.
Reason: add mesa-utils info
|
|
2 members found this post helpful.
|
04-24-2011, 04:50 AM
|
#3
|
Member
Registered: Dec 2004
Distribution: Kubuntu
Posts: 62
Original Poster
Rep:
|
I'm still studying your message because it is full of information. Very useful for anyone trying to understand a little bit about this.
Just to help me understanding the entire architecture, there is something which is not quite clear to me: in all this, what are the elements that are hardware related and that should be provided, in general, by the manufacturer?
In the final part of your message I understand that this entire architecture (X11, DRM, DRI2 and GLX or EGL) is independent on the hardware. Is this correct? "Below that" specific OpenGL libraries will be placed and Mesa/Gallium will use those specific OpenGL libraries. Is this correct?
In my Ubuntu for instance I have enabled the proprietary ATI drivers. This means, if I understood correctly, that Gallium is using DRM to manage memory, DRI2 to give direct access to the acceleration provided by OpenGL specific implementation (ATI OpenGL implementation). Mesa3D is not needed because I'm using another OpenGL implementation.
Another question is: I see that DRM in the kernel has AGP as a prerequisite. What about integrated GPUs not using AGP?
Thank you very much for your explanations!
|
|
|
04-24-2011, 08:19 AM
|
#4
|
Senior Member
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Bookworm (Fluxbox WM)
Posts: 1,391
|
The hardware dependent modules are not separate parts of the architecture, but are components of some layers (primarily the DRM/DRI layer).
The DRM/DRI layer contains both device independent and device specific modules (/lib/modules/…/kernel/drivers/gpu/drm/* and /usr/lib/dri/), and even the X11 architecture without the GL extensions has device specific 2D rendering modules (ie, DDX drivers in /usr/lib/xorg/modules/drivers/).
There is no reason why integrated GPUs cannot make use of the common DRM module (although they won't need the AGP routines). The common DRM module provides some core functionality, to simplify writing the device specific DRM modules.
Of course, you will find that some proprietary driver sets do not use even the device independent modules, and provide their own implementations of the OpenGL components. They won't necessarily split things up in the same way that Mesa/Gallium does.
Last edited by neonsignal; 04-24-2011 at 08:24 AM.
|
|
1 members found this post helpful.
|
04-24-2011, 09:44 AM
|
#5
|
Member
Registered: Dec 2004
Distribution: Kubuntu
Posts: 62
Original Poster
Rep:
|
So, as a summary, the "chain" is something like MyApplication -> EGL (or GLX) -> OpenGL -> X11 (bypassed by DRI2 to avoid excessive X11 computation) -> DRM -> Framebuffer -> Display.
And for a specific hardware, it may be necessary for a GPU manufacturer to provide an implementation of OpenGL (or OpenGL ES x.y), an implementation of EGL for X11 and some modules for the Direct Rendering in both DRI2 and DRM.
Am I completely off the way or am I learning something? :-)
And all this architecture is subject to modifications when talking about OpenGL ES 1.x or 2.0? I read somewhere that DRI is no longer supported with OpenGL ES.
Thanks very much for you clarification!
|
|
|
04-24-2011, 10:35 AM
|
#6
|
Senior Member
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Bookworm (Fluxbox WM)
Posts: 1,391
|
Quote:
Originally Posted by Luc484
So, as a summary, the "chain" is something like MyApplication -> EGL (or GLX) -> OpenGL -> X11 (bypassed by DRI2 to avoid excessive X11 computation) -> DRM -> Framebuffer -> Display.
|
Pretty much. I would think of DRM as more a resource manager that ensures that DRI access to the hardware does not interfere with the rest of X (rather than DRM as another layer). And when it is being accelerated, the framebuffer generation is of course being done by the GPU rather than the CPU.
Quote:
And for a specific hardware, it may be necessary for a GPU manufacturer to provide an implementation of OpenGL (or OpenGL ES x.y), an implementation of EGL for X11 and some modules for the Direct Rendering in both DRI2 and DRM.
|
As a minimum, specific hardware requires a DRM module, a DRI backend to Mesa/Gallium, and a DDX module (eg this is how the Nouveau driver works). There is no need to implement the OpenGL API, just the DRI API. However, some proprietary drivers replace the usual modules (eg Nvidia replaces GLX and Mesa and does their own resource management).
Quote:
And all this architecture is subject to modifications when talking about OpenGL ES 1.x or 2.0?
|
Yes, the architecture is going to vary between different implementations of OpenGL. Still, you will have the basic structure of an X system, the OpenGL implementation, the X extensions to call into the OpenGL (such as GLX or EGL), and some sort of backend so the OpenGL code can talk to directly to the hardware.
Likewise, switching from X to Wayland involves some changes to the overall architecture.
Last edited by neonsignal; 04-24-2011 at 10:37 AM.
|
|
1 members found this post helpful.
|
04-24-2011, 11:24 AM
|
#7
|
Member
Registered: Dec 2004
Distribution: Kubuntu
Posts: 62
Original Poster
Rep:
|
Quote:
As a minimum, specific hardware requires a DRM module, a DRI backend to Mesa/Gallium, and a DDX module (eg this is how the Nouveau driver works). There is no need to implement the OpenGL API, just the DRI API. However, some proprietary drivers replace the usual modules (eg Nvidia replaces GLX and Mesa and does their own resource management).
|
This is very interesting again. I can't understand something: in my notebook I have a Ubuntu Linux, with hardware acceleration and DRI enabled (glxinfo reports this). The GPU seems to be an ATI.
Question is: does this mean in my Ubuntu I have a DRM module, a DRI backend and this DDX module for my arch?
Another question (sorry for these many questions but there are only few people who can answer these questions it seems): I see that in my Ubuntu I can enable proprietary drivers or disable those. I came up disabling because performance seemed to be better. What does this mean? That opensource implementations of OpenGL, DRM, DRI etc... perform better than ATI's? How is this possible?
Again, thanks for the useful information.
|
|
|
04-24-2011, 09:23 PM
|
#8
|
Senior Member
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Bookworm (Fluxbox WM)
Posts: 1,391
|
If you have a look in /var/log/Xorg.0.log, you will get some idea of which X drivers are being loaded for your card. For an ATI GPU, I'd be guessing you will have the radeon.ko kernel module, one of the radeon dri backends (perhaps radeon_dri.so or rXXX_dri.so), and the radeonhd_drv.so Xorg driver.
AMD (who bought out ATI) have been contributing free drivers to Linux for some time now, and they are fairly stable. It may be that the proprietary fglrx drivers are dated, and perhaps don't perform as well (or are primarily useful for specific cards that are not supported by the newer free drivers). The situation is different for Nvidia cards, where the free community written nouveau driver does not yet have all the functionality of the proprietary drivers.
|
|
1 members found this post helpful.
|
All times are GMT -5. The time now is 03:00 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|