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.
Related
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).
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...
Using VMware 10 and ubuntu 13.10 as the guest OS.
Installing the guest additions can provide hardware rendering for OpenGL 2.1
For academic purposes, there is a need to develop and run OpenGL 3+ code, preferably in the virtual machine.
I assume that it is not possible to use the host GPU, so I am trying to force software rendering, using an OpenGL 3+ renderer.
Mesa3D + llvmpipe seems promising, but I am unable to find information on whether the software renderer supports OpenGL 3+.
Is there a way to develop OpenGL 3+ under vmware?
EDIT: (For someone who replied and then deleted their post :p)
Yes, I am also seeing OpenGL 2.1 using glxinfo. I removed hardware acceleration in my VM, and am only interested in software rasterization, even if it is really slow. The question is, is there a version of llvmpipe that implements a software rasterizer for OpenGL versions higher than 2.1? I know that mesa3d supports it, albeit only for hardware.
The mesa software renderer (both the "old" pre-gallium swrast and the "new" gallium softpipe/llvmpipe), do support most of GL3.2. The only major thing missing is support for multisampling, hence they are not advertising full 3.0 support.
Update 2017
Current versions of mesa's various software rasterizers now do claim to support up to GL 3.3 in a core profile. (The progress can be tracked on https://mesamatrix.net/). However, there is a caveat, as documented in mesa's feature.txt:
freedreno, llvmpipe, softpipe, and swr have fake Multisample anti-aliasing support
which means they still do not fullfill the requirements of the GL 3.0 spec. However, in most cases, this will not matter in practice. But one should still be aware of that limitiation.
In case anyone is still interested, VMWare Workstation (both Workstation Pro and Workstation Player) have added OpenGL 3.3 support in version 12.
However, at the time of writing, the Linux guest drivers side of the equation has not been available, and is planned for Linux 4.3.
So: Use VMWare Workstation Player (or Pro, if you have it) version 12 or up, and Linux 4.3 or up.
Update: using VirtualBox without any kind of acceleration and Mesa LLVMpipe, I also get OpenGL 3.3 support (Mesa version is 17.1.1)
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.
I have a very simple Toshiba Laptop with i3 processor. Also, I do not have any expensive graphics card. In the display settings, I see Intel(HD) Graphics as display adapter. I am planning to learn some cuda programming. But, I am not sure, if I can do that on my laptop as it does not have any nvidia's cuda enabled GPU.
In fact, I doubt, if I even have a GPU o_o
So, I would appreciate if someone can tell me if I can do CUDA programming with the current configuration and if possible also let me know what does Intel(HD) Graphics mean?
At the present time, Intel graphics chips do not support CUDA. It is possible that, in the nearest future, these chips will support OpenCL (which is a standard that is very similar to CUDA), but this is not guaranteed and their current drivers do not support OpenCL either. (There is an Intel OpenCL SDK available, but, at the present time, it does not give you access to the GPU.)
Newest Intel processors (Sandy Bridge) have a GPU integrated into the CPU core. Your processor may be a previous-generation version, in which case "Intel(HD) graphics" is an independent chip.
Portland group have a commercial product called CUDA x86, it is hybrid compiler which creates CUDA C/ C++ code which can either run on GPU or use SIMD on CPU, this is done fully automated without any intervention for the developer. Hope this helps.
Link: http://www.pgroup.com/products/pgiworkstation.htm
If you're interested in learning a language which supports massive parallelism better go for OpenCL since you don't have an NVIDIA GPU. You can run OpenCL on Intel CPUs, but at best you can learn to program SIMDs.
Optimization on CPU and GPU are different. I really don't think you can use Intel card for GPGPU.
Intel HD Graphics is usually the on-CPU graphics chip in newer Core i3/i5/i7 processors.
As far as I know it doesn't support CUDA (which is a proprietary NVidia technology), but OpenCL is supported by NVidia, ATi and Intel.
in 2020 ZLUDA was created which provides CUDA API for Intel GPUs. It is not production ready yet though.