ChromeOS: Black screen/window on startup: #77651

New Issue

Kåre Baastrup · 2020-06-08T22:32:01+02:00

Kåre Baastrup commented

2020-06-08 22:32:01 +02:00

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: 001f7c92d1

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).

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

P1458

**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: 001f7c92d1 **Short description of error** Black window/screen never shows the splashscreen See attached picture ![Screenshot 2020-06-08 at 22.27.27.png](https://archive.blender.org/developer/F8602589/Screenshot_2020-06-08_at_22.27.27.png) ``` 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](https://archive.blender.org/developer/P1458.txt)

Kåre Baastrup commented

2020-06-08 22:32:01 +02:00

Added subscriber: @baastrup

blender-admin commented

2020-06-08 22:32:01 +02:00

#80674 was marked as duplicate of this issue

blender-admin commented

2020-06-08 22:32:01 +02:00

#77970 was marked as duplicate of this issue

blender-admin commented

2020-06-08 22:32:01 +02:00

#77952 was marked as duplicate of this issue

Ankit Meel commented

2020-06-09 13:26:19 +02:00

Added subscriber: @ankitm

Ankit Meel commented

2020-06-09 13:26:19 +02:00

https://developer.blender.org/T72098#938339
https://developer.blender.org/T77381#945090
Try these workarounds

https://developer.blender.org/T72098#938339 https://developer.blender.org/T77381#945090 Try these workarounds

Kåre Baastrup commented

2020-06-09 13:57:48 +02:00

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.

Germano Cavalcante commented

2020-06-10 16:59:30 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-06-10 16:59:30 +02:00

Have you tried upgrading GPU drivers? See https://docs.blender.org/manual/en/dev/troubleshooting/gpu/index.html

Kåre Baastrup commented

2020-06-10 17:40:48 +02:00

In #77651#950857, @mano-wii wrote:
Have you tried upgrading GPU drivers? See https://docs.blender.org/manual/en/dev/troubleshooting/gpu/index.html

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

> In #77651#950857, @mano-wii wrote: > Have you tried upgrading GPU drivers? See https://docs.blender.org/manual/en/dev/troubleshooting/gpu/index.html Its a chromebook,so thats not possible and 2.82a works

Ankit Meel commented

2020-06-16 18:47:17 +02:00

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 ...

``` 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 ... ```

Ankit Meel commented

2020-06-16 18:55:21 +02:00

Please run

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

and upload the file.

Please run ``` ./blender --python-expr "import bpy; bpy.ops.wm.sysinfo(filepath=r'./blender_system_info.txt')" ``` and upload the file.

Kåre Baastrup commented

2020-06-17 00:14:22 +02:00

blender_system_info.txt

Here you go

[blender_system_info.txt](https://archive.blender.org/developer/F8626601/blender_system_info.txt) Here you go

Kåre Baastrup commented

2020-06-17 00:34:31 +02:00

blender_system_info.txt

and one for blender 2.9 as well

[blender_system_info.txt](https://archive.blender.org/developer/F8626631/blender_system_info.txt) and one for blender 2.9 as well

Ankit Meel commented

2020-06-17 09:27:56 +02:00

Added subscriber: @fclem

Ankit Meel commented

2020-06-17 09:27:56 +02:00

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

@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.

@fclem is this renderer not supported?

``` 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 @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. @fclem is this renderer not supported?

Kåre Baastrup commented

2020-06-18 13:25:58 +02:00

blender_system_info.txt

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

[blender_system_info.txt](https://archive.blender.org/developer/F8630105/blender_system_info.txt) 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 commented

2020-06-18 14:42:18 +02:00

Added subscriber: @AestheticArson

Ankit Meel changed title from ~~Black screen/window on startup~~ to ChromeOS: Black screen/window on startup:

2020-06-18 14:44:18 +02:00

Ankit Meel commented

2020-06-18 14:44:18 +02:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Kez commented

2020-06-24 20:21:32 +02:00

@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.

Ankit Meel commented

2020-06-26 08:21:04 +02:00

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.

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](https://developer.blender.org/diffusion/B/browse/master/source/blender/gpu/intern/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.

Evan Wilson commented

2020-06-28 03:12:22 +02:00

Added subscribers: @Phoney, @EAW

LF commented

2020-06-28 19:56:59 +02:00

This comment was removed by @Phoney

*This comment was removed by @Phoney*

Ankit Meel commented

2020-06-28 20:03:54 +02:00

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.

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.

LF commented

2020-06-28 20:23:58 +02:00

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

LF commented

2020-06-29 19:25:18 +02:00

Is there any other way to fix this?

Ankit Meel commented

2020-06-29 19:51:32 +02:00

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/

> 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/

LF commented

2020-06-29 20:49:31 +02:00

Good idea

LF commented

2020-06-29 20:54:19 +02:00

Wait, what about the Steam version of Blender?

Kåre Baastrup commented

2020-07-16 11:06:17 +02:00

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

Brecht Van Lommel commented

2020-07-16 11:26:23 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2020-07-16 11:26:23 +02:00

@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.

@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.

Kåre Baastrup commented

2020-08-19 07:54:37 +02:00

Same issue with 2.83.4 and 2.91

Kåre Baastrup commented

2020-09-01 12:38:21 +02:00

Same issue with 2.90

Ankit Meel commented

2020-09-11 10:10:47 +02:00

Added subscriber: @biscuitlad

Kester Clegg commented

2020-09-11 11:21:29 +02:00

I report all the same issues on my 2015 Pixelbook.

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

I report all the same issues on my 2015 Pixelbook. 2.82a works, all subsequent versions black screen on start up.

Ray Foss commented

2020-10-28 18:03:44 +01:00

Added subscriber: @rayfoss

Ray Foss commented

2020-10-28 18:03:44 +01:00

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.)

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.)

Ryan Sturgell commented

2020-11-18 22:56:49 +01:00

Added subscriber: @rsturgell

Kåre Baastrup commented

2020-12-08 20:36:09 +01:00

Same issue with 2.91 ;-(

Ray Foss commented

2020-12-08 21:22:11 +01:00

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

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

Ray Foss commented

2020-12-08 21:22:16 +01:00

Removed subscriber: @rayfoss

Kester Clegg commented

2021-01-07 12:29:17 +01:00

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.

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.

Kåre Baastrup commented

2021-01-31 13:43:56 +01:00

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 ;-)

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 ;-)

Eric Svärd commented

2021-02-21 08:43:03 +01:00

Added subscriber: @eric.svard

Kåre Baastrup commented

2021-03-25 13:04:04 +01:00

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

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

Kez commented

2021-04-06 14:14:58 +02:00

Added subscriber: @Ankit-1

Kez commented

2021-04-06 14:14:58 +02:00

@Ankit-1 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?

@Ankit-1 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?

Pratik Borhade commented

2021-04-06 14:21:40 +02:00

Removed subscriber: @Ankit-1

Pratik Borhade commented

2021-04-06 14:22:38 +02:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2021-04-06 14:22:38 +02:00

Meel (ankitm)...

@ankitm ^

>Meel (ankitm)... @ankitm ^

Matt Kimball commented

2021-05-10 02:13:55 +02:00

Added subscriber: @mkimball

Matt Kimball commented

2021-05-10 02:13:55 +02:00

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.

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.

Valentin Regnault commented

2021-05-27 19:47:56 +02:00

Added subscriber: @Pykorm

sabai commented

2021-06-02 19:55:21 +02:00

Added subscriber: @sabai

sabai commented

2021-06-02 19:55:21 +02:00

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

Is a fix in progress?

Cheers

I see this issue persists with v2.92 on Chrome v90. Is a fix in progress? Cheers

David Li commented

2021-06-07 05:46:18 +02:00

Added subscriber: @david82194

David Li commented

2021-06-07 05:46:18 +02:00

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.

I ran git bisect between 2.82a and 2.83 on my Acer Chromebook Spin 713. The offending commit for me is [001f7c92d1452e01622f066d37bd42545b650a27 ](https://github.com/blender/blender/commit/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 commented

2021-06-07 06:52:35 +02:00

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

Germano Cavalcante commented

2021-06-07 13:16:16 +02:00

Thanks for the bisect @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

Thanks for the bisect @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: ```lines=10 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 commented

2021-06-07 18:04:47 +02:00

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 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.

David Li commented

2021-06-07 20:07:03 +02:00

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

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 ](https:*drive.google.com/file/d/19PlYHfS-DK5V3E1GxiSIfYULDJaYnHoh/view?usp=sharing)

blender-admin commented

2021-06-07 20:11:50 +02:00

This issue was referenced by a925c8969d

This issue was referenced by a925c8969d706cb3c0768a9fa88151b1ad67a923

blender-admin commented

2021-06-07 20:11:50 +02:00

This issue was referenced by 706c7d775d

This issue was referenced by 706c7d775d263e962161d2f280722d23be0081d6

blender-admin commented

2021-06-07 20:11:50 +02:00

This issue was referenced by 6e56b42faa

This issue was referenced by 6e56b42faa242f3d8b935a07cbb9b5300cebf0a6

Germano Cavalcante commented

2021-06-07 20:15:39 +02:00

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));

Good to see we're getting close to a solution :) `GPUTexture`s 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 commented

2021-06-07 20:40:18 +02:00

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

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 ](https:*drive.google.com/file/d/1soWG84bfvP70cs8DVYroshS9FH75TCdu/view?usp=sharing)

Germano Cavalcante commented

2021-06-07 20:52:26 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Germano Cavalcante closed this issue

2021-06-07 20:52:26 +02:00

Germano Cavalcante self-assigned this 2021-06-07 20:52:26 +02:00

sabai commented

2021-06-07 21:02:06 +02:00

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

Germano Cavalcante commented

2021-06-07 21:48:08 +02:00

In #77651#1172694, @sabai wrote:
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/

> In #77651#1172694, @sabai wrote: > 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/

Kåre Baastrup commented

2021-06-08 14:19:35 +02:00

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

Works on my chromebook ;-)

Blender 3.0.0 - Alpha June 08, 03:36:14 - master - ef5a362a5b24 - tar.xz - 149.62MB x64 Release Works on my chromebook ;-)

sabai commented

2021-06-08 18:57:16 +02:00

In #77651#1173105, @baastrup wrote:
Blender 3.0.0 - Alpha
June 08, 03:36:14 - master - ef5a362a5b - 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

> In #77651#1173105, @baastrup wrote: > 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

Matt Kimball commented

2021-06-20 20:47:07 +02:00

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

Kez commented

2021-06-22 00:24:53 +02:00

3.0.0 Alpha loads successfully on Pixelbook.

easy commented

2022-04-21 06:30:08 +02:00

Added subscriber: @g-easy

easy commented

2022-04-21 06:30:08 +02:00

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.

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.

Falk David referenced this issue

2023-02-10 13:03:23 +01:00

Blender LTS: Maintenance Task 2.93 #88449

Sign in to join this conversation.