koobas.hobune.stream
native texture pointer returns 0 in headless build
When I run the following code inside a Unity Editor, or if I build and run it (not in headless mode) GetNativeTexturePtr() returns a value >0 for the texture id, etc.
However, when building the app having a Server Build option enabled GetNativeTexturePtr() always returns 0. Even when IsCreated() returns true.
Any ideas what is happening here?
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class test : MonoBehaviour
{
private RenderTexture m_RenderTexture;
// Start is called before the first frame update
void Start()
{
m_RenderTexture = new RenderTexture(256, 256, 24, RenderTextureFormat.ARGB32);
m_RenderTexture.Create();
RenderTexture.active = m_RenderTexture;
if (!m_RenderTexture.IsCreated())
{
Debug.LogError("RenderTexture could not be created");
}
Debug.Log("texture id = " + m_RenderTexture.GetNativeTexturePtr().ToString());
}
}
Is it even possible to use the RenderTexture inside a server build? I want to process that texture in my native plugin, and can not get it work inside a server build. Normal build works just fine. But as soon as the Renderer is a Null Device, I have this problem. I want to run my app on a server PC.
What exactly would an app do with a texture that does not even render anything? Note, you can simply run the app as is on a server. Headless just means this: "The game does not display anything or accept user input."
The app would render but not display. The rendered texture is then streamed over the network for example. As soon as I run the app over ssh / or remote desktop etc. I have issues :(
Well, I'm not 100% sure but when you run Unity or a build in headless mode no graphics context is generated at all. In order to create a graphics context you need a window you can draw to (a device context). So in headless mode you don't actually require or use the GPU at all. So of course there would be no native texture pointer since the texture isn't uploaded to the GPU at all. Anything CPU based should still work.
The main issue is probably that almost all default drivers and APIs require a device context which is always bound to some kind of window. If you run in headless mode Unity is supposed to run even in CLI environments without any kind of window support. So it would be difficult to actually accomplish any kind of GPU based rendering.
See this SO question for some insight
This also might be related
If you generally search for GPU rendering in CLI mode you will find a lot blender related posts. However blender mainly uses CUDA or OpenCL for rendering and not the actual GPU rendering pipeline. So I don't think that this possible with Unity. Though I really don't know so this is just a wild guess. Maybe someone from the Unity team could shed some light on this (Maybe @Aras ?)
Thank you. I saw that UnityRenderStrea$$anonymous$$g has an open issue where someone mentioned a similar problem. I hope that Unity guys will give some insights on this.
I believe EGL was developed for just such a problem. Is there any way we could convince the Unity team to implement the ability to use an EGL context instead? (Or maybe someone could write a Native plugin..?)
You need to run X11 server for that. Here is the post which will help you: https://towardsdatascience.com/how-to-run-unity-on-amazon-cloud-or-without-monitor-3c10ce022639
