Page MenuHome

ChromeOS: Black screen/window on startup:
Closed, ResolvedPublicBUG

Description

System Information
Operating system: Chromeos 83/84/85 buildin linux VM
Graphics card: Intel Gen8, HD Graphics 5500/UHD Graphics 620

Blender Version
Broken: (2.83 LTS, 2.90 Alpha)
Worked: (2.82a)
First bad commit: rB001f7c92d145: BLF: Optimize text rendering and caching

Short description of error
Black window/screen never shows the splashscreen
See attached picture

Warning: Could not find a matching GPU name. Things may not behave as expected.
Detected OpenGL configuration:
Vendor: Red Hat
Renderer: virgl

Exact steps for others to reproduce the error
Based on the default startup or an attached .blend file (as simple as possible).

  1. start ./blender from its home folder
  2. Black window/screen shows up

P1458

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I have tried with blender-softwaregl and it starts blender (both 2.83,290) but its too slow ofcause as no hardware acceleration is used.

Its a chromebook,so thats not possible and 2.82a works

Received X11 Error:

error code:   165
request code: 150
minor code:   34
error text:   GLXBadFBConfig
Received X11 Error:

error code:   165
request code: 150
minor code:   34
error text:   GLXBadFBConfig
Warning: Could not find a matching GPU name. Things may not behave as expected.
Detected OpenGL configuration:
Vendor: Red Hat ...

Please run

./blender --python-expr "import bpy; bpy.ops.wm.sysinfo(filepath=r'./blender_system_info.txt')"

and upload the file.

Here you go

and one for blender 2.9 as well

renderer:	'virgl'
vendor:		'Red Hat'
version:	'4.3 (Core Profile) Mesa 19.2.8'

Its a chromebook,so thats not possible and 2.82a works

@Kåre Baastrup (baastrup) So are you stuck with this Mesa version ? Mesa 20.x is the latest.

Warning: Could not find a matching GPU name. Things may not behave as expected.

@Clément Foucault (fclem) is this renderer not supported?

found a way to replace the debain container with arch linux but seems to be the same issue. see attached file.

Arch glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):

Vendor: Red Hat (0x1af4)
Device: virgl (0x1010)
Version: 20.1.1
Accelerated: yes
Video memory: 0MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.3
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2

OpenGL vendor string: Red Hat
OpenGL renderer string: virgl
OpenGL core profile version string: 4.3 (Core Profile) Mesa 20.1.1
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile


OpenGL version string: 3.1 Mesa 20.1.1****
OpenGL shading language version string: 1.40
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Ankit Meel (ankitm) renamed this task from Black screen/window on startup to ChromeOS: Black screen/window on startup: .Jun 18 2020, 2:42 PM
Ankit Meel (ankitm) changed the task status from Needs Triage to Needs Information from Developers.
Ankit Meel (ankitm) updated the task description. (Show Details)

@Ankit Meel (ankitm) Hello. Any any updates on this bug? I just tried loading today's daily build, blender-2.90.0-b4e1571d0bcf-linux64 , and the issue persists.

I asked the developers: Blender doesn't treat virgl differently. That's why you see "Warning: Could not find a matching GPU name. Things may not behave as expected." in the console from gpu_platform.c .
So it has to be reviewed if it should be supported or not.

A note from me is that if some commit unintentionally broke the compatibility between 2.82a, and 2.83, git bisect can find the problem.
See this concise answer : https://stackoverflow.com/a/37306623
start with git bisect bad 2.83 , git bisect good 2.82a. Then it'll checkout a commit in between, run make and test that Blender opens. If it does, enter git bisect good otherwise git bisect bad and repeat.

This comment was removed by LF (Phoney).

Have you downloaded the source code ? https://wiki.blender.org/wiki/Building_Blender/Linux/Generic_Distro#Quick_Setup
For build questions, https://devtalk.blender.org/c/blender/building-blender/11
It's okay to not try it, if it becomes too much trouble.

Using git is seeming difficult for me. I've never used it before.

Is there any other way to fix this?

Using git is seeming difficult for me. I've never used it before.

You could ask doubts on https://blender.chat too.
Otherwise, before a developer decides to tackle this bug report, you may use 2.82a. https://download.blender.org/release/

Wait, what about the Steam version of Blender?

Clément Foucault (fclem) changed the subtype of this task from "Report" to "Bug".

This happens on my brand new Asus chromebook flip with 10th gen intel chipset as well. tested 2.83.2 as well

@Clément Foucault (fclem), maybe we should try just recognizing virgl as an Intel? Since that's the most likely one to be used. I'm not sure if that will actually solve the issue, but seems worth trying.

If it does work, we could perhaps also ask the virgl developers to pass through the renderer information.

Same issue with 2.83.4 and 2.91

I report all the same issues on my 2015 Pixelbook.

2.82a works, all subsequent versions black screen on start up.

Shouldn't this be labeled a regression? Also, I got a system dialog saying the app wasn't responding... might not be entirely graphics related.

Same issue on 2.90.1 with a an HP 360x 14c. I installed using the flatpak. The snap seems to try to run, but was so slow it... never really got there. Gimp for instance takes a whole minute to run with the software emulated snap, but with flatpak, it flies.

For reference, we can't modify the of the default debian image. To use other images we have to disable quite a few protections and deal with warnings and additional friction, developer mode is a lot like rooting an Android Phone or running Windows 10 Ameliorated edition.

(ChromeOS support for Linux is insanely good, aside from USB passthrough being mostly missing. I'm just happy to have linux on a fast 14 hour laptop.)

Same issue with 2.91 ;-(

Seems to be a packaging issue with OpenGL and Python... Lots of others have issues in Ubuntu as well

https://github.com/flathub/org.blender.Blender/issues/31

There is a workaround, but it will mean Blender will run like a dog. I got the latest 2.91 to run on my chromebook using:

LIBGL_ALWAYS_SOFTWARE=1 blender

But it would be great if the developers would let 2.91 run as well as 2.82 did. Seems we are to be frozen in time on ChromeOS

In fact the only solution I've found is install a dual boot version of linux, and that will run 2.91 fine-ish. Clearly not hardware, this is a software issue that seems unsolvable for crostini or whatever chromeos version of linux is.

LIBGL_ALWAYS_SOFTWARE=1 blender seems to start blender 2.91.2 but its useless

Hope someone can find the diffrents between 282 and 2.91.2 and fix it ;-)

Still and issue with 2.9.2 ;-(

~/blender-2.92.0-linux64$ ./blender
Warning: Could not find a matching GPU name. Things may not behave as expected.
Detected OpenGL configuration:
Vendor: Red Hat
Renderer: virgl
/run/user/1000/gvfs/ non-existent directory

@Ankit jain (Ankit) Meel (ankitm)

Version 2.9.2 same issue persists. We're coming up on a year since this issue was first reported. What needs to be done to get the developers to fix this issue?

Another datapoint - Blender 2.82a works fine on my Asus Flip C434, but Blender 2.92.0 does not work. (Other than with 'LIBGL_ALWAYS_SOFTWARE')

Regarding "maybe we should try just recognizing virgl as an Intel", I tried modifying 'GLBackend::platform_init()' to do this, and it did not help. I also enabled all GL workarounds, as seen at the top of 'detect_workarounds()' at that didn't fix the issue either.

I see this issue persists with v2.92 on Chrome v90.

Is a fix in progress?

Cheers

I ran git bisect between 2.82a and 2.83 on my Acer Chromebook Spin 713.
The offending commit for me is 001f7c92d1452e01622f066d37bd42545b650a27.

Reverting it allows v2.83 to start on my chromebook.

Note that the virgl warning appears on working and non-working versions.

Ankit Meel (ankitm) changed the task status from Needs Information from Developers to Confirmed.Jun 7 2021, 6:52 AM
Ankit Meel (ankitm) updated the task description. (Show Details)

Thanks for the bisect @David Li (dave1853).
We could revert that commit, but it brings more than a simple optimization.
There is a reduction in memory usage in the VRAM (especially when the font is resized).

Before any further action, it would be useful to be able to identify what the real trigger of this driver problem is.

So, for anyone who is able to replicate the problem and compile the Blender code, could you test some code changes to find out what causes it?

The changes to test would look something like this:

diff --git a/source/blender/gpu/shaders/gpu_shader_text_frag.glsl b/source/blender/gpu/shaders/gpu_shader_text_frag.glsl
index d85884e0a25..5e52fdec32d 100644
--- a/source/blender/gpu/shaders/gpu_shader_text_frag.glsl
+++ b/source/blender/gpu/shaders/gpu_shader_text_frag.glsl
@@ -29,7 +29,7 @@ const vec2 offsets16[16] = vec2[16](vec2(-1.5, 1.5),
                                     vec2(0.5, -1.5),
                                     vec2(1.5, -1.5));
 
-//#define GPU_NEAREST
+#define GPU_NEAREST
 #define sample_glyph_offset(texel, ofs) \
   texture_1D_custom_bilinear_filter(texCoord_interp + ofs * texel)
 
@@ -91,6 +91,8 @@ void main()
 {
   // input color replaces texture color
   fragColor.rgb = color_flat.rgb;
+  fragColor.a = 1;
+  return;
 
   // modulate input alpha & texture alpha
   if (interp_size == 0) {
diff --git a/source/blender/gpu/shaders/gpu_shader_text_vert.glsl b/source/blender/gpu/shaders/gpu_shader_text_vert.glsl
index 768638e5229..c274b68132e 100644
--- a/source/blender/gpu/shaders/gpu_shader_text_vert.glsl
+++ b/source/blender/gpu/shaders/gpu_shader_text_vert.glsl
@@ -18,6 +18,9 @@ void main()
   glyph_offset = offset;
   glyph_dim = abs(glyph_size);
   interp_size = int(glyph_size.x < 0) + int(glyph_size.y < 0);
+  texCoord_interp = vec2(0.0);
+  gl_Position = vec4(0.0);
+  return;
 
   /* Quad expension using instanced rendering. */
   float x = float(gl_VertexID % 2);

Even if the interface is messy, if Blender doesn't turn black it's a good sign.

It might also be useful to run blender with the --debug-gpu arg:
https://docs.blender.org/manual/en/latest/advanced/command_line/render.html

David Li (dave1853) added a comment.EditedJun 7 2021, 6:04 PM

Commenting out the size_x lines in texel_fetch of source/blender/gpu/shaders/gpu_shader_text_frag.glsl seems to fix the issue. I think the driver doesn't like the textureSize call.

float texel_fetch(int index)
{
    // int size_x = textureSize(glyph, 0).r;
    // if (index >= size_x) {
    //     return texelFetch(glyph, ivec2(index % size_x, index / size_x), 0).r;
    // }
    return texelFetch(glyph, ivec2(index, 0), 0).r;
}

What do the lines I commented out do?
If they're meaningful, perhaps we can work around this by passing the texture size in as a uniform.

Commenting out those 4 lines allows v2.93 to work on my chromebook as well.
Here is a build of v2.93 for anyone who needs it:
https://drive.google.com/file/d/19PlYHfS-DK5V3E1GxiSIfYULDJaYnHoh/view?usp=sharing

Good to see we're getting close to a solution :)

GPUTextures have a relatively small width and height limit (this is seen in GPU_max_texture_size).
Due to this limitation, we cannot cache the entire glyph in a single 1D texture.
To work around this problem, we use a 1DArray texture. So whenever the limit is reached on the first line, we move to the second line and so on.

This is what the texel_fetch function does.

Can you try using a 2d texture instead of 1DArray?
Theoretically the result would be the same.

diff --git a/source/blender/blenfont/intern/blf_glyph.c b/source/blender/blenfont/intern/blf_glyph.c
index f3c5c057dec..2ec0ca22865 100644
--- a/source/blender/blenfont/intern/blf_glyph.c
+++ b/source/blender/blenfont/intern/blf_glyph.c
@@ -506,7 +506,7 @@ void blf_glyph_render(FontBLF *font, GlyphCacheBLF *gc, GlyphBLF *g, float x, fl
       if (gc->texture) {
         GPU_texture_free(gc->texture);
       }
-      gc->texture = GPU_texture_create_1d_array(__func__, w, h, 1, GPU_R8, NULL);
+      gc->texture = GPU_texture_create_2d(__func__, w, h, 1, GPU_R8, NULL);
 
       gc->bitmap_len_landed = 0;
     }
diff --git a/source/blender/gpu/shaders/gpu_shader_text_frag.glsl b/source/blender/gpu/shaders/gpu_shader_text_frag.glsl
index d85884e0a25..2568cd74445 100644
--- a/source/blender/gpu/shaders/gpu_shader_text_frag.glsl
+++ b/source/blender/gpu/shaders/gpu_shader_text_frag.glsl
@@ -7,7 +7,7 @@ flat in int interp_size;
 
 out vec4 fragColor;
 
-uniform sampler1DArray glyph;
+uniform sampler2D glyph;
 
 const vec2 offsets4[4] = vec2[4](
     vec2(-0.5, 0.5), vec2(0.5, 0.5), vec2(-0.5, -0.5), vec2(-0.5, -0.5));
David Li (dave1853) added a comment.EditedJun 7 2021, 8:40 PM

That works too! I tested on tag v2.93 with everything else unchanged from the original, including the texel_fetch function.
I suppose textureSize just doesn't work with sampler1DArray on my Chromebook.
Here is an updated build:
https://drive.google.com/file/d/1soWG84bfvP70cs8DVYroshS9FH75TCdu/view?usp=sharing

I see this issue was resolved and closed today.

I'm not a coder and am unfamiliar with the process, but may I ask when the fix might be available for download in v2.92+?

Cheers

I see this issue was resolved and closed today.

I'm not a coder and am unfamiliar with the process, but may I ask when the fix might be available for download in v2.92+?

Cheers

Long-term Support and 2.93+ versions
https://www.blender.org/download/lts/

Blender 3.0.0 - Alpha
June 08, 03:36:14 - master - ef5a362a5b24 - tar.xz - 149.62MB
x64 Release

Works on my chromebook ;-)

sabai (sabai) added a comment.EditedJun 8 2021, 6:57 PM

Blender 3.0.0 - Alpha
June 08, 03:36:14 - master - ef5a362a5b24 - tar.xz - 149.62MB
x64 Release

Works on my chromebook ;-)

Mine, too. Yay!

Though I note this message in Terminal after Blender started:

Read prefs: /home/sabai/.config/blender/3.0/config/userpref.blend
Warning: Could not find a matching GPU name. Things may not behave as expected.
Detected OpenGL configuration:
Vendor: Red Hat
Renderer: virgl

Thank you very much for fixing this issue, David and Germano. I'm super happy that Blender now works on my Chromebook as well.

3.0.0 Alpha loads successfully on Pixelbook.

Thanks for working around this bug! The fix on the virgl side is https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/770 and will be in ChromeOS M101.

Anyone running Debian 11 (bullseye) in Crostini: it ships Blender 2.83, which is affected by this bug, and should be fixed in M101 and later.