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)
Related
I have a Linux system with Mesa3D and llvmpipe software driver.
glxinfo reports
Extended renderer info (GLX_MESA_query_renderer):
Vendor: VMware, Inc. (0xffffffff)
Device: llvmpipe (LLVM 9.0, 128 bits) (0xffffffff)
Version: 19.2.8
Accelerated: no
Video memory: 65482MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 3.3
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
If I read this info correctly, OpenGL 3.3 has to be supported in core profile. Unfortunately, any OpenGL program starts only in OpenGL 3.1 mode (compatibility profile). For example,
~$ xvfb-run glxgears -info
GL_RENDERER = llvmpipe (LLVM 9.0, 128 bits)
GL_VERSION = 3.1 Mesa 19.2.8
GL_VENDOR = VMware, Inc.
...
Is there a way to start OpenGL programs with core 3.3 profile?
Unfortunately, any OpenGL program starts only in OpenGL 3.1 mode.
Not any GL program will do that. Only old programs which use the legacy context creation (so they don't even know or care about the existence of different profiles) will get this version.
(compatibility profile).
Actually, OpenGL 3.1 compatibility profile does not even exist. Profiles were introduced in OpenGL 3.2, even if mesa's interpretation of that slightly differs. Technically, mesa llvmpipe simply does not support compatibility profiles.
Is there a way to start OpenGL programs with core 3.3 profile?
Not in a useful way. If the program uses legacy context creation, it does either not know about newer GL functions (and will not be able to make use of them as a consequence), or it is just broken and simply assumes to get some newer GL version which is nothing a program can rely on, as per the spec.
In any case, if the program is not written for OpenGL core profile, is will most likely not function correctly, because a lot of deprecated legacy functionality is simply not available in core profiles.
Your example glxgears will simply generate a lot of GL errors and only show a black screen wehn run in core profile, because it is using display lists and immediate mode rendering commands and the fixed-function pipeline, which are all not available in core profile OpenGL.
Allthough it is most likely quite useless, to make a program use core profile OpenGL which doesn't request it, you either can modify the source code, or you can somehow interfere with its context creation operations.
In some ironic turn of events, I myself just a few days ago added some functionality to my glx_hook hack which actually allows to modify the context an application is requesting without having to modify the source code.
I'm about to enter the next phase of a project where I am moving computation to the GPU. Unfortunately, I have had very poor success setting up OpenCL in my environment. I hoped I could garner some specific direction about what implementation of OpenCL to use and how to avoid certain pitfalls upon installation.
My machine:
Linux Mint 17.3
Dell XPS 15 9550 with an Nvidia GTX 960M graphics chip
Some specifics:
I have been unable to find any graphics drivers that work with this hardware other than the Nvidia-352 version found in this PPA:
https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
Every other one I try bricks the machine. I've reinstalled Mint more times than I can count finding this one driver. Keep in mind that I must use this configuration for my machine to work.
I attempted to install Nvidia's CUDA toolkit from their site (https://developer.nvidia.com/cuda-downloads) and for some reason the installation overwrote my Nvidia-352 driver and bricked the machine again.
At this point Im not certain which implementation is correct anyway. I do not want to try another and have the same thing happen.
Some specific questions:
Does every implementation of OpenCL assert itself over the currently installed drivers?
If it does then how can I direct my machine to use the correct one?
Which implementation would be right for my machine?
Can you think of any resources or links that I might be interested in to keep me moving forward? Specifically some installation instructions?
Thanks,
Chronic
Disclaimer: all this is based on my experience with Ubuntu 15.10, but hopefully Mint isn't too different.
Does every OpenCL installation overwrite the others?
If you're installing two different vendor's OpenCL implementations then no, they shouldn't overwrite each other. For example, I have Nvidia, Intel CPU, POCL and Beignet (Intel GPU) platforms installed and working. The only caveat is that the Intel CPU runtime overwrote libOpenCL.so* files, resulting in a crash in clinfo because it required libOpenCL.so.1 which the Intel CPU runtime decided to delete. Re-installing the package ocl-icd-opencl-dev fixed this and you can also make libOpenCL.so.1 a symlink to the actual .so file left by the Intel CPU runtime.
If you try installing two versions for the same platform, like you tried, then yes the last one you install will overwrite the previous one. In your case, remember that the CUDA toolkit also includes the GPU drivers. I haven't played with the CUDA toolkit in a while, perhaps there is an option to install the toolkit only and not the drivers, but since each toolkit requires a certain minimum driver version, you'd have to pick a toolkit version that works with the driver version you can get installed.
On Ubuntu, there is an nvidia-cuda-toolkit package you can sudo apt-get install. Id doesn't ask to change my drivers, hopefully it will work for you. I don't know what version of the toolkit this one installs.
Which implementation is right
If you only want to do OpenCL development then install the nvidia-352 package that worked for you, as well as installing ocl-icd-opencl-dev. This package installs the ocl-icd-libopencl and opencl-headers packages, giving the header files and libOpenCL.so (the ICD loader). You also need to sudo apt-get install nvidia-opencl-icd-352 as that provides the OpenCL runtime for Nvidia GPUs. If you also want to do CUDA development then you need the toolkit.
As a side note, install one of the CPU runtimes, e.g. POCL, in addition to the Nvidia runtime. I found this useful for detecting a bug in my kernel - the kernel worked most of the time on my Nvidia GPU but failed consistently on POCL. It was a race condition.
Useful links
Sorry, no up-to-date installation instructions. However, the instructions provided by each vendor with their OpenCL runtime (except Nvidia) seem to be good enough for me.
Here's some older instructions:
https://wiki.tiker.net/OpenCLHowTo
https://streamcomputing.eu/blog/2011-06-24/install-opencl-on-debianubuntu-orderly/ - The rest of the StreamComputing blog is also interesting.
I want to learn OpenGL development and I am running Linux Mint. Khronos.org says the following:
The OpenGL 4.4 and OpenGL Shading Language 4.40 Specifications were released on July 22, 2013.
As far as I understand Mesa is the OpenGL implementation for Linux but it is only one version 3.1 I believe. My question is, can I develop OpenGL 4.4 apps in the Linux environment or do I have to use Mesa's 3.1 version?
You can develop OpenGL 4.4 software by #including the glext.h file from http://www.opengl.org/registry/
You can run OpenGL 4.4 software by using hardware drivers that implement the OpenGL 4.4 specification and a GPU that supports the necessary hardware features. In practical terms, this means you need an AMD or Nvidia GPU that supports Direct3D 11 and very recent proprietary (closed-source) drivers from the GPU vendor.
Mesa3d is the open-source driver framework, with partial support for OpenGL 4.x. The proprietary drivers from AMD and Nvidia replace Mesa3d with their own OpenGL implementation.
Note that you can develop OpenGL 4.4 software even if your system cannot run said software.
AMD and NVIDIA proprietary drivers are probably the only drivers on Linux supporting OpenGL 4.4.
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.
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.