This topic is similar to Blender 2.8: “Unable to open a display” by the rendering on the background (Eevee)
background rendering get stopped by
Unable to open a display
when using it on server , but it’s ok in my laptop.
The used command:
blender "Dual#11.blend" -E CYCLES --render-output //frame_##### -F PNG -f -2 -b
My main question here is whether blender Cycles engine supports headless rendering or not?
ps: server os is ubuntu 18.04, my laptop os is Windows 10
Cycles should work in a headless setup as far as I know.
Did the same thing in 2.79 work on this system? If so that could be reported as a bug.
Can you try moving the -b option to be the first option, i.e. blender -b "Dual...? The option order matters and you’re starting the rendering here with -f and only then activate background mode with -b.
@brecht I tried with 2.79 and 2.80 and 2.81 all gave me the same result:
linux output
but the command works fine in my laptop
windows output(with screen)
will appreciate if you look into output.
I used a simple project to create output:
http://www.mediafire.com/file/tf4op7x334i4j8x/Blender_Intro_Template_%23209.zip
I don’t think that really matter because as I mentioned it works fine when i have a screen.
I can render the default cube headless just fine, but this file i get the same coredump you do so it’s probably something specific in this file. It be best if you’d file a bug at this point. (and attach the file)
Well, yes, if you have a screen then wether you enable background rendering or not will not matter. It’s when you render on a machine without a screen (or more precisely an X server on Linux) that the -b option will matter.
So I’ll suggest again: did you try rendering with the -b option as the first argument on the system where rendering otherwise fails with Unable to open a display?
So I tried as you suggested and moved -b at first, but still same result.
blender -b "Dual#11.blend" -E CYCLES --render-output //frame_##### -F PNG -f -2
I tried the simple cube, in simple cube there is no Sync and Compositing required, but in the linked project there are some syncing and compositing that’s when the error shows up.
right after line 316 in windows output.
Fra:624 Mem:239.67M (0.00M, Peak 240.63M) | Time:00:00.76 | Syncing Empty
Fra:624 Mem:239.67M (0.00M, Peak 240.63M) | Time:00:00.76 | Syncing Plane.101
Fra:624 Mem:239.67M (0.00M, Peak 240.63M) | Time:00:00.78 | Syncing Plane.100
…
Fra:624 Mem:162.96M (0.00M, Peak 240.63M) | Time:00:20.52 | Compositing
Fra:624 Mem:162.96M (0.00M, Peak 240.63M) | Time:00:20.53 | Compositing | Determining resolution
Fra:624 Mem:162.96M (0.00M, Peak 240.63M) | Time:00:20.58 | Compositing | Initializing execution
Strange. I tried the file you linked on a (Red Hat) Linux system without a GPU and without any X server running and it renders without errors using the command you use. This is with the slightly older blender 2.80.39.
And the position of the -b option indeed doesn’t matter here, apparently because the frame render with -f causes the UI to never get loaded as Blender exits after rendering.
Which blender are you using, official binaries or custom built version?
Ah! Just tried the latest official binaries (2.80.75) and with those I also get the error you’re seeing! So it indeed appears that when the compositing step starts the text overlay is rendered (directly after rendering is Finished) an attempt is made to open a display, even when running with -b.
Quick guess after looking at the file: there’s two scenes in there, Scene and TEXT overlay. Both have their own setting of the renderer to use (set to Eevee in the file). When you use -E CYCLES from the command line it only sets the renderer on the current scene, leaving the other set to Eevee, which won’t be able to render headless as its directly tied to OpenGL.
Haven’t tried a workaround, but the above looks to be the issue.
Hi Paul,
Coming from the Sheepit Renderfarm we get the same error. Unable to open a display
Also with CYCLES projects and also with Blender 2.83.3.
I couldn’t find the settings of “the renderer to use” that you described. Could you please describe how you found it? Because we need to detect it, so we can block these kind of projects (that somehow use eevee) on headless machines.
Also sorry for reviving such an old thread but I detected these errors quite a lot recently.
@Devs: Could you please add something to the log output to see what is causing the Unable to open a display? I mean, the frame is finished and for saving Blender needs EEVEE? I’ve run --debug-all but I have still no idea why it is happening because Blender doesn’t tell anything. See the appended log
log_2.90.txt (1.1 MB) log_2.83.3.txt (1.1 MB)
Maybe somebody else has an idea?
I now use the workaround with xvfb.
sudo apt-get install xvfb
xvfb-run -a "my command"
But the core problem persists. Blender still seems to use EEVEE somehow after the frame is finished with CYCLES. And I can’t find the reason…
@brecht Should I open a bug report for that?
EDIT: The workaround is working for the strange cycles/eevee thing but is ■■■■■■■ up normal eevee projects. A frame that takes me locally 2 seconds takes 4,5 minutes on Colab.
You can test a headless machine really fast in Colab if you want to. https://colab.research.google.com/gist/Raimund58/88061f785ea2563d345914d196c15b87/blender_script_for_google_colab_using_the_gpu.ipynb
At the bottom is also the mentioned Unable to open a display
That would be bpy.data.scenes['Scene'].render.engine. Note that the value can differ for different scenes in the same Blender file.
Well, I can’t open the scene file through Google Drive it seems. Do you have it available separately?
Sorry, I’m less of beginner level of a programmer. How do I list the scenes? I only get:
import bpy
bpy.data.scenes[‘Scene’].render.engine
‘CYCLES’
https://drive.google.com/file/d/1BlmemcpnDAe7ho9KjPoZOuZCzk3v-mSS/view?usp=sharing
>>> for scene in bpy.data.scenes: print(scene, scene.render.engine)
<bpy_struct, Scene("Scene")> CYCLES
So, we only got one scene and that is using CYCLES. So, it is a bug then?
I’m not sure. I can’t reproduce the issue here with 2.83.3 running under Xvfb and with your setgpu.py script:
$ Xvfb :1 -screen 0 1920x1080x24 &
$ cat setgpu.py
import re
import bpy
scene = bpy.context.scene
scene.cycles.device = 'GPU'
prefs = bpy.context.preferences
prefs.addons['cycles'].preferences.get_devices()
cprefs = prefs.addons['cycles'].preferences
print(cprefs)
# Attempt to set GPU device types if available
for compute_device_type in ('CUDA', 'OPENCL', 'NONE'):
try:
cprefs.compute_device_type = compute_device_type
print('Device found',compute_device_type)
break
except TypeError:
pass
#for scene in bpy.data.scenes:
# scene.render.tile_x = 64
# scene.render.tile_y = 64
# Enable all CPU and GPU devices
for device in cprefs.devices:
if not re.match('intel', device.name, re.I):
print('Activating',device)
device.use = True
else:
device.use = True
$ DISPLAY=:1 blender -b ~/Printer_Animatic_szene1_200724_1530.blend -P setgpu.py -o doh.png -f 1
Blender 2.83.3 (hash 353e5bd7493e built 2020-07-27 00:47:14)
Read prefs: /home/paulm/.config/blender/2.83/config/userpref.blend
Read blend: /home/paulm/Printer_Animatic_szene1_200724_1530.blend
<bpy_struct, CyclesPreferences at 0x7f40831dbb28>
Device found CUDA
Activating <bpy_struct, CyclesDeviceSettings("GeForce GTX TITAN (Display)")>
...
Saved: 'doh.png0001.png'
Time: 00:48.16 (Saving: 00:02.77)
Blender quit