When I install a nvidia proprietary driver then Nvidia OpenGL implementation is used (I don't need Mesa). Which OpenGL implementation can be used with an open source nvidia driver - Nouveau ? Does Nouveau also provide OpenGL implementation or it has to use Mesa OpenGL implementation ? Can I use nvidia drivers with Mesa OpenGL implementation ? What are possibilities ?
First things first: The open source graphics drivers, all of them, use Mesa for the front side OpenGL interface and state tracking.
Let's break this down: Theoretically a OpenGL implementation can directly talk to the hardware. This is what the NVidia and AMD proprietary drivers actually do.
But in the open source world code reuse is highly favoured. So a typical open source graphics driver looks like this:
User API frontend (OpenGL + state tracker) → abstraction layer (Gallium3D or device specific internal layer) → kernel backend.
The Mesa project actually encompasses the whole chain. The OpenGL part of Mesa, (the frontend) can attach to different abstraction layers (for example also a software rasterizer, softpipe/llvm for example). But the Mesa project is also an umbrella for the other parts: The userland graphics drivers (nouveau, radeon, intel and so on), the infrastructure that allows for userspace processes to directly talk to the graphics driver, bypassing display servers (DRI) and the kernel interface (DRM), as well the kernel modules.
A few weeks ago AMD released a new kernel module (amdgpu) that uses the DRM API, is open source and will be merged into the Linux kernel. That new kernel module is there to be used by both the proprietary AMD OpenGL drivers and the open source Mesa drivers. AMD is pushing for open source for some time now and the logical next step would be, that AMD ditches their own OpenGL frontend in favor of Mesa and providing their proprietary driver as a middle end that plug into Mesa.
Can I use nvidia drivers with Mesa OpenGL implementation ?
That depends. If you're doing indirect OpenGL over X11 then in fact you can use the Mesa libGL.so for your program, talking through the X11 server to the nvidia backend driver. However used that way libGL.so merely acts as a GLX conduit. It works the other way round as well BTW.
However since this lacks "direct GL context" capabilities you'll not be able to use OpenGL features for which no indirect opcodes have been defined; that would be anything OpenGL-3 or later, sadly. Also if your data is highly dynamic there is some significant bottleneck due to serializing the command stream (theoretically using syscalls like vmsplice most of the overhead could be alleviated, though).
Related
While building Linux kernel from source, I noticed that it is also building some drivers (e.g. drivers/gpu/drm/i915 or nouveau etc).
On the other hand, on my system I also have xserver-xorg-video-intel package installed (Ubuntu). So the question is: how does the xserver-xorg-video-intel driver go with drivers/gpu/drm/i915 from kernel? Are they two separate things with different purpose (e.g. the second is for X11 only)?
Linux graphic stack is a wide and complex ecosystem.
you have a general overview here :
or a more complete and technical one from Stephane Marchesin which is one of the nouveau hackers.
Basically, graphics toolkits (Qt, Gtk, efl, etc..) talk with Xorg. XOrg use libdrm to interact with the kernel DRM infrastructure which stands upon and abstract video card drivers (nouveau, i915, ..).
I've got the idea that in old days, XFree86 used /dev/fb* framebuffer devices. But now looks like the GUI system uses OpenGL, which is an open standard. So is OpenGL the lowest level open API? By 'open', I mean no obscure private ioctl or closed-source stuff.
Update:
I've got what I need after discussions with #datenwolf, who also provides a great answers.
In case anyone wants more coding detail: The X server driver is the lowest common level for the X system on top of any GPUs. To know what kind of interface an X server driver must implement: refer to DDX Design, it is a detailed doc for the latest X.org that tells you how to write an X driver.
In Linux there is no "lowest level API" exposed by the kernel that does graphics operations. All graphics drivers are actually implemented in the user space by so called "state trackers", which use special kernel functions to talk directly with the graphics hardware¹. The open source drivers implemented as part of the Mesa project use the Linux specific DRM API to talk to the hardware. The proprietary drivers from NVidia and AMD each use their very specific kernel module instead.
Now when it comes to end program usability Mesa and the proprietary drivers differ a bit:
NVidia's and AMD/ATI's proprietary drivers offer no API at all to end user programs to use for. Instead they're implemented as modules to load by the X server; the X server expects the driver modules to follow a specific scheme, which usually changes with major changes in the X server, so each X server major version bump usually required to update the driver modules as well.
The X server in turn provides a well known command stream based graphics API. Graphics commands sent over this API are scheduled by the X server and dispatched into called to the right functions of the driver module. The driver module in turn contains the whole intelligence for talking with the GPU and turns the commands coming from the X server into commands toward the GPU.
So to speak the X server is the lowest level universal graphics API currently available to Linux programs (except for programs that would go the length to implement everything to use the X driver modules directly).
When it comes to X11, the drivers that are part of the Mesa project are no different than the proprietary drivers. However because Mesa is open source its developers began implementing ways that programs could use Mesa and its drivers directly without having talk to it through the X server. For that they choose to expose an API conformant with the EGL specification. Unfortunately EGL is rather useless on its own because it requires an external display system to be present (or you can do only off-screen rendering).
This is where Wayland enters the picture. Wayland is not a display system. It is however a protocol that allows the building blocks of a display system to talk with each other. One central component of a Wayland based display system is the compositor which actually takes hold of the so called "seat" (= display device and associated input devices). Programs that want to display something on the screen use Wayland to open a connection with the compositor, which gives them a display to use EGL on. That they then can use to create actual drawing surfaces to do their graphics on.
[1]: Actually for some drivers (of legacy hardware) the X server must be started with root privileges, so that it can use the special function ioperm(…) to gain direct access to the hardware using the out*(…) and in*(…) functions and open /dev/mem for memory access. In this case there is zero support by the kernel regarding the communication with the graphics hardware. But for security and performance reasons nobody does (program) that anymore.
DRM and KMS, at least for the open-source driver stacks.
You need to build your own GPU-accelerated renderer, or use GLX
The lowest level access to the GPU is via X renderering backends.
The lowest level backend available to X is GLX.
GLX renders X directly to the GPU-accelerated OpenGL pipeline.
The default framebuffered xrender backend is unaccelerated.
Compton is an opensource compositor for X that uses the GLX backend.
It is a good example of using OpenGL to accelerate X.
GLX should be getting bindings for Vulkan, providing multiple OpenGL pipelines.
GLX only accelerates X in 2D, because X is a 2D app.
For 3D apps, a custom renderer is required.
The DRM GPU driver.
is the open...
I've been experimenting with JavaFX, and I've found out that as of 2.2.0.b15, it uses GPU to provide improved font rendering. This makes a big difference for me. I intend to use it for visualization and animated UI features, so I'd like to know if GPU support will be provided in Linux.
I have come accross many statements that say that JavaFX will use my GPU if it is supported, and it does, but only under Windows. I have not seen anything about hardware acceleration for graphics under Linux, so I'm curious, can I expect to have this with 2.2 release?
I believe JavaFX for Linux already supports hardware acceleration for some features based on this statement from the JavaFX 2.1 Linux Develop Preview Release Notes:
3D features are supported for Nvidia cards (proprietary drivers only).
Not entirely conclusive, as it does not explicitly mention hardware acceleration, but I think use of hardware acceleration is likely if you have the appropriate Nvidia card and driver installed. Potentially, over time, hardware acceleration support under Linux for other hardware and driver configurations may be added.
Can Anybody explain me what is EGL and what it does?
How can i use EGL with OpenGL-ES On Linux?
Is EGL a Layer Between Hardware And Operating System?
EGL is a window system-independent equivalent to the GLX and WGL APIs, which respectively enable OpenGL support in X and Microsoft Windows. It is an interface between Khronos rendering APIs such as OpenGL ES or OpenVG and the underlying native platform window system. It handles graphics context management, surface/buffer binding, and rendering synchronization and enables high-performance, accelerated, mixed-mode 2D and 3D rendering using other Khronos APIs.
There is an implementation for Mesa called EGL and covered in the Mesa EGL Wiki.
Realistically you can't use XEGL / EGL,
If you're running on Linux and don't need X then look at Wayland which is a replacement server built on top of MESA.
I think you're best reading up definitive references such as this. I don't see value in paraphrasing that.
There seem to be some Linux implementations referenced in that article. You can't expect folks to give you detailed tutorials here. Instead attempt to use these references and ask specific questions when you get stuck.
Maybe you could view EGL as a kind of dedicated Graphics "OS", personally I see it yet another API, which abstracts graphics.
I'm getting started developing with OpenGL ES on ARM/Linux, and I would like to draw something full-screen but don't know where to start.
I'm not developping on iPhone, nor Android. This is a Linux/OpenGL ES question.
I know it's possible to draw on the framebuffer with OpenGL ES without any library but I don't find any resources about that topic, could you help me?
I don't have any code to show how to do it but basicly you use de framebuffer device as the target of OpenGL|ES operations.
Are you developing with an embedded platform as a target? If so, you could use software implementations on your host system and then the actual driver on the embedded device.
There is a small project for supporting OpenGLES 1.1 on linux called dlges. You could also try mesa.
I imagine that the driver itself might have a header for OpenGL that you could look at and see if it supports OpenGLES calls. Alternatively, you could set up function pointers to make your OpenGL Code look more like OpenGL ES.
Good luck!
Don't forget that desktop Linux comes with OpenGL, not OpenGLES! They're similar but not quite compatible. If you want to do work on OpenGLES on a desktop Linux platform, ARM or otherwise, you'll need an OpenGLES emulator library. Sorry, can't recommend any, I'm looking for one myself.
OpenGLES just handles the process of drawing stuff into the window. You also need a windowing library, which handles the process of creating a window to draw stuff into, and an event library, which deals with input events coming back from the window.
SDL will provide both of the last two, as will a bunch of other libraries. Khronos themselves have standardised on EGL as the windowing library and OpenKODE as the event library... but I don't actually know where to get open source implementations of these for Linux. (I work for a company that does EGL and OpenKODE for embedded platforms, so I've never needed to find an open source version!)
ARM offers few GPUs that support OpenGL 2.0. You can find some examples and and emulator that runs on linux on the Mali Developer site.
Of course that's mostly to target ARM GPUs, but I am pretty sure it could be used to examine OpenGL ES programming possibilities.
Here is a tutorial showing how to use SDL in combination with OpenGL ES. It's for the OpenPandora platform, but since that runs Linux, it should be applicable on the desktop if you can get the proper library versions.
Use of SDL is more or less standard with this kind of programming, in Linux. You can of course go the longer route and open the window yourself, attach a GL rendering context and so on, but usually it's easier to learn the relevant parts of SDL. That also gives you easy-to-use API:s for input reading, which is almost always necessary.
You can use PowerVR SDK for Linux http://community.imgtec.com/developers/powervr/graphics-sdk/
There are a lot of samples.