OpenGL Core Context / Vulkan

Yuri6037 · June 27, 2020, 9:02am

Hi,

After some research it appears to me that AppImage is the best way to support portable apps (apps that do not require any installs). The applications I would like to support are games made with a custom 3d game engine.
I plan to make an SDK tool that can auto package AppImages. However I have some question related to AppImage Hub:

It appears you’re using Travis-CI in order to test submitted app images. If so how do you deal with AppImages that requires OpenGL 4.0 core context only API for hardware acceleration or Vulkan API for hardware acceleration? If the engine is ran under unsupported system the best that will be given is a console error with a C++ exception thrown.
Are newly submitted AppImages required to run under sandbox? I ask that as the game engine isn’t designed to run in a sandbox mainly due to ultra moddability support which requires read-write access to real user-home directory (needs to use a directory /home/MyUser// under Linux)…
Still related to sandboxing. Althrought the engine isn’t designed to be sanboxed, it could run in a sandbox assuming that sanbox provide a HOME environment variable that points to a read-write folder, Is there any problem to rely on /proc/self/exe in order to obtain the real path of the currently running executable in order to locate /Assets and other similarly obtained folders?

Thank you

probono · June 27, 2020, 9:14am

Hello @Yuri6037 and welcome to AppImage.

After some research it appears to me that AppImage is the best way to support portable apps (apps that do not require any installs).

Yes, this is exactly what it was designed for.

I plan to make an SDK tool that can auto package AppImages.

Great project. I suggest that you check out my work-in-progress GitHub - probonopd/go-appimage: Go implementation of AppImage tools. Still experimental; maybe it is useful for you?

On GitHub - AppImage/appimage.github.io: Given an URL to an AppImage, the GitHub action in this project inspects the AppImage and puts it into a community-maintained catalog we are using a bash script to download, run and test all submitted AppImages on the oldest still-supported Ubuntu system at any given time, which we consider to be the baseline. As part of the process a screenshot of the running application is taken (and is required in order to pass the test).

Here is the bash script that does it:

github.com

AppImage/appimage.github.io/blob/master/code/worker.sh

#!/bin/bash

# set -euxov pipefail
set -e -v

URL=$(cat $1 | head -n 1)
echo $URL

GHURL="" # Workaround for: "GHURL: unbound variable"

INPUTBASENAME=$(basename $1)

# Check if $URL starts with "http", otherwise exit
if [ x"${URL:0:4}" != xhttp ] ; then
  echo "No http link detected in $1"
  exit 1
fi

# If the URL begins with https://github.com, then treat it specially
# https://github.com/egoist/devdocs-desktop/

This file has been truncated. show original

If so how do you deal with AppImages that requires OpenGL 4.0 core context only API for hardware acceleration or Vulkan API for hardware acceleration?

Quite frankly, I don’t have enough clue about how graphics acceleration works so I assume this stuff to be all broken. As a result, e.g., screenshots of some Qt applications are garbled (and I suspect it has something to do with OpenGL but am not sure). Since you seem to be knowledgable about it, do you have an idea on how to do it properly?

Are newly submitted AppImages required to run under sandbox?

It needs to be able to run like this:

firejail --quiet --noprofile --net=none --appimage ./Your.AppImage" &

as you can see in the script linked above.
This is used to disable any network access while the AppImage is being tested. It does not restrict the application’s ability to access any filesystem locations.

/proc/self/exe will point to the executable inside your AppImage. You can use it to construct a path to your assets inside the AppImage from there.

If you want to point to assets relative/next to the AppImage, then you need to use the $APPIMAGE environment variable and construct the path from there. Be sure to handle the case when an AppImage is extracted and hence $APPIMAGE is not available (in this case, fall back to /proc/self/exe). Hope this makes sense; feel free to ask if something is unclear.

Yuri6037 · June 27, 2020, 9:29am

Thanks a lot for all this information.
From your answer, I can consider /proc/self/exe will be available and will point to binary location, which is exactly what it is supposed to be (I have both read-only default assets and read-write modded assets given by the user in application data directory which is built from $HOME on linux and OSX, %USERPROFILE% under Windows, and local private app directory under android, and yes I know android will have poor mod support but well Google wants to restrict moddability).

As for GL this seem to be the greatest problem. Travis does not have a GPU that is compatible with CoreContext GL or Vulkan. The issue here is a lot of 3D based engines will need GPU access to even display anything.
The best I can think of to allow testing 3D accelerated applications would be to run them on a dedicated server which has a GPU like we would for deep learning based applications.

So the best plan I can think would be like:

Use gIthub actions which allows for custom runners to be used as testing servers.
Create a custom runner on a dedicated machine equipped with some kind of NVIDIA GTX or compatible GPU.
Create a virtual xorg framebuffer and run the GL/VK app under it (a bit like your current script).

Another solution which I’m not sure is possible and will require much more time and may not even run fast enough for take a screenshot or it will be bugged:

Create a software rendering driver which implements the VK API and GL 4 API so that the application can use the software based rendering driver instead of the NVIDIA driver or AMD driver. Biggest con to this approach is if it does work it is just going to be super but like super slow…

EDIT: It might be possible to allow people to run the test script on their own machines and then return the results…

probono · July 7, 2020, 6:54am

Thanks @Yuri6037

Unfortunately this is not an option for me at this time, since I do not want to buy hardware nor run infrastructure. After all, this is just a hobby project.

It might be possible to allow people to run the test script on their own machines and then return the results…

Which would kinda defeat the purpose of having one repeatable test in one central location that everyone can recreate easily to reproduce any issues, wouldn’t it?

Yuri6037 · July 7, 2020, 2:25pm

I see your point. If neither running a NVIDIA build server is an option nor allowing people to run tests on their own is, I don’t see any solution to the problem…

The best way then is to allow redistribution of GUI apps that may print to console some error like “Cannot create OpenGL Core context” or similar error meaning it cannot create a hardware accelerated rendering context.
The only other way would be to find a software driver for Core context GL and VK. Unfortunatly I don’t know any software driver that supports core context GL or VK.

EDIT: Did you try by any chance to install the mesa drviers or the intel drivers? Cause if Travis supports Intel 620 UHD or later then there is chance it can run GL 4.0

probono · July 7, 2020, 6:13pm

Yes, that’s something we should look into. Thanks for the hint!

Topic		Replies	Views
LinuxPA, Linux Portable Apps Launcher Using AppImages	9	4898	July 2, 2018
Is there any Vulkan apps that use Appimage? Apps	2	1018	January 30, 2023
AppImage at QtCon Berlin Sep 3-5, 2016 Conferences and events	3	1739	September 2, 2016
Create an AppImage with latest libs, which works everywhere Creating AppImages	3	1814	February 23, 2022
Vulkan disabled when running 0ad appimage with Intel or AMD chipsets Using AppImages	5	786	June 18, 2023

OpenGL Core Context / Vulkan

Related topics