I have an OpenGL application that has a map display window. When I run the application over RDP the map display is blank blank-map-display
Running the same application locally or on AWS Workspaces the map displays correctly.
The machine I've RDP'd to has an NVidia graphics card and running windows 10. I've attempted to force hardware acceleration over RDP but this still doesn't solve the problem. Here is the DirectX Diagnostics details showing the use of HW rendering when I RDP on the machine: dxdiag-rdp. I'm using Nvidia driver version 451.77 which should support RDP for Nvidia GeForce GPUs.
I noted that on AWS Workspaces (and locally) all the DirectX features are enabled: dxdiag-aws-workspaces.
Has anyone got any insight into how to make an OpenGL application run over RDP like it does on AWS Workspaces?
Related
We are building an ASP.NET API running with .NET 5 that uses SkiaSharp to dynamically create and return images. We've noticed that using the GPU has a dramatic increase in performance. We know that in order to use the GPU we need an OpenGL Context instantiated, but with it comes some requirements. Our tests work well in our environments: Mac and Windows, but doesn't work when deployed to the Linux Azure App Service using P1v2 VM.
The error message Unable to create GL context: Unable to load shared library 'libX11'. Doing some research I realized the container doesn't have OpenGL installed and trying to install it through apt-get is not possible because of lack of permissions.
I went the route of running the KuduLite container locally in my machine and installing libgl1-mesa-glx and mesa-utils, but running glxinfo results in the error Error: unable to open display. I found this blog post that explains the requirements of running hardware accelerated OpenGL support in Docker. The blog post is from 2014 so I'm not sure if it is still valid, but if it is there quite a few requirements that before I try to solve locally in my machine I would like to know if they are even possible in Azure App Service Container.
So, is it even possible to have hardware accelerated OpenGL support in Azure App Service docker?
The problem you're running into is, that the machine you're running this on is headless and doesn't run a X11 display server. Most application-frameworks-for-use-with-OpenGL assume that they'll be running in some interactive graphical environment, i.e. having either an X11 server (which is configured to use the GPU) or a Wayland compositor around.
glxinfo doesn't have to do anything about this, BTW. It's just a little tool to query what kind of OpenGL capabilities a given X11 display (server) has. If you don't run X11 in the first place, you don't need it.
Up until a few years ago, this in fact was the only way to get GPU acceleration on Linux. Luckily those days are long gone. These days one can obtain fully headless, offscreen OpenGL contexts using EGL. Nvidia has a nice blog about how to do it:
https://developer.nvidia.com/blog/egl-eye-opengl-visualization-without-x-server/
Then there's this Github repo:
https://github.com/eduble/gl
You'll get the idea: Instead of opening a window you get a so called "surface" and draw on that.
With Vulkan it's even more straightforward, because you don't even have to bother setting up a surface suitable for pushing to a display if your goal is rendering an image to a buffer that you wrap up in a file or send out over a network (look at the offscreen sample in Sascha Willems' examples https://www.saschawillems.de/creations/vulkan-examples/)
Hi I created a Google Compute Engine with Tesla T4 GPU. I want to be able to run some application that renders some graphics. So i need NVIDIA GPU for display.
OS : Ubuntu 18.04
I tried installing the NVIDIA proprietary drivers , still i am unable to see any valid NVIDIA VGA Device.
But the compute instance i created doesn't seem to be exposing the VGA driver for NVIDIA.
when i do lshw -c display , it only shows Nvidia as a 3D accelerator and not as VGA Compatible device.
Hence my doubt, how do i enable VGA capability for NVIDA Card on Google Cloud Compute Platform?
Google supports virtual display devices only on Windows instances that use any Windows images or higher.
Virtual display devices are not compatible with instances running the Sandy Bridge CPU platform.
Here are the instructions to enable a Virtual Display in GCP instances
Currently new to google cloud
and working on vm.
Can anyone help me how can i use android emulator on vm.
it shows me
Emulator: emulator: ERROR: x86 emulation currently requires hardware acceleration!
now how can i enable hardware acceleration on vm??
First of all you can not access BIOS on Google Compute Engine VM. When you restart the instance you will be automatically disconnected from the SSH session. As soon as you open another SSH session again you will be already logged in to the os.
Android Studio Emulator is another Virtual Machine that emulates the operation of an Android device. So what you are looking for is VM nested inside a Google Compute Engine VM, you can refer to the Enabling Nested Virtualization for VM Instances documentation, for further information.
However, you can use arm64-v8a or armeabi-v7a ABI. They are pretty slow but you will be able to test your applications there. You can make them faster, but it will require a powerful VM that will cost a lot of money. To use those images in Android Studio emulator:
Go to Tools > AVD Manager.
On the bottom left corner click on + Create Virtual Device ....
In Choose a device definition, choose any device you want and click Next
In Select a system image go to Other images tab
Choose any arm64-v8a or armeabi-v7a ABI. (Download if you don't have one)
Click on Next, give a name and click Finish
Run the Virtual Device and give it some time, according to how powerful is your VM it will take some time to load. You will see an Android logo loading and after few minutes you will see the Home Screen. If it takes too long, try restarting the AVD and the Android Studio, then leave it some time to load. It is pretty slow, but it is working, I tested it myself.
Try below steps -
Open SDK Manager (In Android Studio, go to Tools > Android > SDK Manager) and Download Intel x86 Emulator Accelerator (HAXM installer) if you haven't.
Now go to your SDK directory C:\users\%USERNAME%\AppData\Local\Android\sdk\extras\intel\Hardware_Accelerated_Execution_Manager\ and run the file named intelhaxm-android.exe.
In case you get an error like "Intel virtualization technology (vt, vt-x) is not enabled". Go to your BIOS settings and enable Hardware Virtualization.
Restart Android Studio and then try to start the AVD again.
I want to know the difference between application started directly on the machine and the application started using remote desktop connection.
Whether both the application are same or will have different privileges.
For example, i had an opengl based application which take higher version of opengl 3 or 4 when started directly on the machine. But when i start the same application from remote desktop connection, it takes only base opengl version 1.1.
One more observation is:
We have a service application which will launch a graphics (OGRE based) application based on request. Request is set from client using web-socket communication.
When we start this service directly in a server, it works fine. But when this service is started from a RDP connection, the graphics application is crashing when user sends request after RDP connection is closed.
IT works if I keep the RDP connection on.
It may loose the graphics driver when you are logged in through RDP.
If you look in the launch the Ogre 'setup' dialog when RDP is enabled it will not list the graphics card - but a different 'RDP driver'.
Also - when you log on\off it might 'reset' the device (since the RDP graphics driver is enabled\disabled) causing your window get loose the device, and then crash.
One way to get around all this - is to use a VNC (for example tightvnc), this does not cause the issues that standard RDP does, since it does not use the RDP graphics drivers and such.
We have a series of unit tests that require an NVidia GPU for execution. These tests currently fail (I think) because TFSBuild runs as a windows service and Windows (Windows 7 and later) does not allow windows services to access GPUs. Any ideas on how to get around this problem?
You are correct in that the MS Test Execution Engine on a build server does run as a service (just like the MSBuild process) and that services by default cannot access the GPU because of the "Session 0 Isolation" concept that was introduced in Windows Vista.
From what I've researched the only official way to get around this is to purchase an Nvidia Tesla card and have it run in "Tesla Compute Cluster" (TCC) mode which allows services to access the GPU for computing (like CUDA). There is indirect evidence that some Quadro cards also support TCC mode, but I have not found anything official stating which ones do.
I have a question up on Nvidia's forums asking about an inexpensive card for this exact scenario but it does not have any replies as of yet.
EDIT:
I just acquired an Nvidia Quadro K2200 and can confirm that it does indeed support TCC mode and works great running CUDA Unit tests on my build server during the build process.