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.
Related
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...
Upon considering the driver side implementation for DirectX API on windows systems for modern video cards I was wondering why this implementation is not available on non-windows system, most notably linux.
Since there is an obvious absence of this functionality I can only assume there is a good reason which I am blind to, but in my primitive understanding I simply see the DirectX calls as no more than function entry points on the hardware device. And for the record I am not referring to a compatibility layer (most notably WINE, a project I am amazed by every single day) but a library making direct hardware calls.
Is it possible to create an open source version of directx? Would it be possible but obscenely difficult?
AFAIK, the DirectX contains 3 parts
Vendor driver (provide low level API defined by DX)
DirectX library (use low level API defined by DX to access hardware, provide DirectX API)
Software (use DirectX API, ex. game)
There are no driver providing the low level API defined by DX on linux, so even it is possible to provide the DirectX library, but it won't work without proper vendor driver, and I can't see if there is any vendor is going to create one for their hardware platform.
Why not just use OpenGL? It supports all the functionality that DirectX does. Do you have a specific reason to use DirectX? As for a reason, Microsoft made DirectX and I guess they didn't see any need to allow it to run on Linux.
You can run DirectX games in Linux using Wine. You can program XNA on Linux using MonoGame. But all of these use OpenGL to provide hardware-accelerated rendering. AFAIK, OpenGL has been (and probably will be) the only option on Linux for the foreseeable future.
Is it possible to write your own DirectX implementation? Sure - but it involves writing drivers, proprietary knowledge and probably too much cost for anyone to REALLY benefit from it.
EDIT: These days, DXVK is a very real and performant way to run DirectX applications on Linux.
DirectX is a suit of API's:
Direct3D (drawing 3D graphics)
DirectX Graphics Infrastructure (enumerating adapters and monitors and managing swap chains)
Direct2D (drawing 2D graphics)
DirectWrite (fonts)
DirectCompute (GPU Computing)
DirectSound3D (playback of 3D sounds)
DirectX Media (DirectAnimation for 2D/3D web animation, DirectShow for multimedia playback and streaming media, DirectX Transform for web interactivity, and Direct3D Retained Mode for higher level 3D graphics)
DirectX Diagnostics (tool for diagnosing and generating reports on components related to DirectX, such as audio, video, and input drivers)
DirectX Media Objects (support for streaming objects such as encoders, decoders, and effects)
DirectSetup (installation of DirectX components, and the detection of the current DirectX version)
DirectX components deprecated, but still supported
DirectDraw
DirectInput
DirectPlay
DirectSound
DirectMusic
As you can see many parts of the DirectX suit of API's would need to be rewritten with functionality for Drivers written for Linux. Also some parts of the DirectX suit are likely going to make calls to the Windows OS and that code would have to rewritten for a Linux machine without infringement of the copy-written parts of either DirectX or the Windows OS.
Yes you could write a open source API suit which does the same kind of thing as DirectX for Linux, however without a great knowledge of sound and graphic drivers/support by their manufactures for Linux, it would be a very hard task to do.
However if you question was more of a "Can I get/write something to be able to run games and programs made with DirectX to run on Linux?" in it's meaning, in short no due to more likely copyright infringement.
Your question is wrong in 2019. DXVK is an implementation of D3D11 and D3D10 implementation for Linux using Vulkan and Wine
Also mesa has native Direct3D 9 implementation but in my knowledge, no one uses it except wine
The work to create a port for DirectX would create the same problems as you encounter in WINE. It will never be the same as on Windows. Derived from that principle you would have to look into OpenGL and related multi-platform libraries.
At this very moment WINE would be your closest medium if you want to accomplish something with DirectX code you already have. Then again, I'm not sure in what manner Visual Studio or plain typing would get you closer yo a fluent environment. The WINE libraries aren't that far from native, but there always exists emulation, what is acceptable to a certain point in my honest opinion.
If I look at how superbly Final Fantasy XIV ran on full settings on my iMac (2011) I think it's not that bad to rely on WINE's implementation. The game exactly rendered as on Bootcamp (Windows) on my iMac.
If you really want to make work on this front you could try to ask WINE Devs at their forums or mailing lists how you could maybe use the implementation of their DirectX compatibility only and use that in your project. Where you maybe can call libraries instead of requesting DirectX through Windows-emulated system calls.
Edit: I fully agree with user956030's answer too.
DirectX is a propriety products designed for Microsoft targets, so for this to happen would be very unusual
There are two other pieces of software that come to mind, SDL and OpenGL
OpenGL provides the hardware alternative to DirectX, and SDL works with OpenGL to provide the software support you would expect from DirectX
Since 2020, Microsoft has been working to port DirectX 12 to WSL2, which is being done in this repository. In a mailist, Steve Pronovost commented that they might work to port this driver to Linux to have it running natively.
However, in order to do this, they would need to implement the driver on top of the kernel's DRM stack, which itself needs to be modified if they want to keep the driver similar to the Windows one and have related APIs.
There is some effort being done in the Mesa library as well, to support D3D12 within itself, the main purpose being to optimize server-sided GPU calculations that are heavily used in machine learning algorithms.
Even though this is great, it's unlikely that we will ever see any advantage running Windows games on Linux with that driver. The open source community would only have the upper ground if more games start supporting Vulkan, which is faster and better than DirectX, there had been experiments where using DXVK on Windows would be faster than DirectX 9 or even 11, such as the one mentioned here, but DXVK tends to be less reliable and more prone to errors and crashes.
There exist a class of applications that use opengl to provide hardware acceleration, but are not GUI based. However it seems that in the default case, to use opengl, there must be running an X-server with GLX (on the same virtual terminal) for those applications to function.
My specific case is attempting to use gstreamer's gl plugins on a headless machine, but I'm asking a more general question.
Is there some way around this (esp without modifying the original code)?
I've been trying to research using the framebuffer kernel module, but not getting very far.
Mesa supports software rasterization on offscreen surfaces.
You can use EGL and render to a PbufferSurface instead of a WindowSurface.
See my answer here: https://stackoverflow.com/a/74226995/1884837
Have you tried Xvfb?
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.
In windows, what does Flash use under the hood?
It's a relatively simple question which I can never find the answer to. Is it GDI (for windows VM implementations) or something else?
You don't need to go into any of the new GPU acceleration features of Flash. I just really want to know the inner workings because it's NEVER discussed.
On 64-bit Linux, the Flash plugin does not link against SDL (according to ldd). It does, however, link against GTK, GDK, and Cairo. It appears, therefore, that it is using either Cairo or raw Xlib calls to do its drawing on Linux.
I don't know on Windows. Flash tends to have minimal dependencies, but Direct-X may be standard enough that they use it. With some kind of a process examiner to tell you what libraries a process has loaded, you could examine a simple web browser embedding Flash and see what system facilities are actually in use.
DirectX mostly. It's hard to achieve good graphics performance with GDI.
I agree with george, GDI is very bad for speed. DirectX for Windows and SDL or similar for Linux (note this is an assumption!). In that sense it probably uses a layer that communicates with the native graphics subsystem on whatever platform it's running on.