~eliasnaur/gio#49: 
Raspbian / Raspberry pi: floating point fbos not supported

I just tried running the example using go run gioui.org/example/hello on raspbian with no luck - its exits right away with an error saying floating point fbos not supported - exit status 1.

Raspbian is fully updated and i downloaded and build wayland and weston from source, weston 7.0.90. It seems to otherwise work just fine on the pi.

Status
REPORTED
Submitter
~fasmide
Assigned to
No-one
Submitted
9 months ago
Updated
5 months ago
Labels
No labels applied.

~eliasnaur 9 months ago

On Sun Oct 27, 2019 at 7:31 PM ~fasmide wrote:

I just tried running the example using go run gioui.org/example/hello on raspbian with no luck - its exits right away with an error saying floating point fbos not supported - exit status 1.

Raspbian is fully updated and i downloaded and build wayland and weston from source, weston 7.0.90. It seems to otherwise work just fine on the pi.

Which raspberry pi version? In particular, what is the GPU model and driver version? Unfortunately, Gio can't currently run without floating poing FBO support.

~fasmide 9 months ago

Its the Raspberry Pi 3 model B rev 1.2 using the BCM2835 soc. I'm not sure how to figure out the driver used by weston (wayland?), but when it loads it says its using the drm-backend.so. Before i could get the thing started, i had to enable "DRM VC4 driver" in /boot/config.txt - but i basically have no idea what i'm doing with weston/wayland :)

Its a 4.19.75-v7+ kernel...

I just saw the X11 support merged - very nice - ill give it a try without wayland...

~fasmide 9 months ago

Same result on X11

Xorg.0.log https://pastebin.com/ZZKcdz1P

~fasmide 9 months ago

~eliasnaur 9 months ago

On Sun Oct 27, 2019 at 9:51 PM ~fasmide wrote:

and dmesg https://pastebin.com/3GWmFRrT

Yeah, a quick Google search reveals that the VideoCore 4 is a OpenGL 2.0 class GPU and will probably never support floating point FBOs. It's possible that Gio will run without floating point FBO in the future, but I don't have plans to work on it.

-- elias

~sircmpwn 7 months ago

Bump, I ran into a similar issue trying to get Gio running on the PinePhone. My hope was to write a dialer app with Gio, but if Gio doesn't work well on mobile GPUs then it's a fool's errand.

~sircmpwn 7 months ago

Working on a driver patch. I can get you mediump (half float) on the Lima driver, if you're able to ditch highp and meet me in the middle we'll be in business.

~eliasnaur 7 months ago

On Tue Dec 10, 2019 at 10:21 PM ~sircmpwn wrote:

Working on a driver patch.

Nice.

I can get you mediump (half float) on the Lima driver, if you're able to ditch highp and meet me in the middle we'll be in business.

Can you elaborate? Gio is fine with HALF_FLOAT(_OES) FBOs if that's what you mean. Are you saying the Lima driver somehow restricts the shader precision to mediump when outputting to a half float fbo? AFAIU, the shader precision is unrelated to the output format (how else would a shader output to, say, an RGBA UNSIGNED_BYTE FBO?

~sircmpwn 7 months ago

Yeah, Lima can support OES_texture_half_float with a patch, in theory, but not OES_texture_float.

~eliasnaur 7 months ago

On Tue Dec 10, 2019 at 11:02 PM ~sircmpwn wrote:

Yeah, Lima can support OES_texture_half_float with a patch, in theory, but not OES_texture_float.

Great, that should work fine with Gio.

~sircmpwn 7 months ago

--- a/app/internal/gpu/context.go
+++ b/app/internal/gpu/context.go
@@ -63,15 +63,19 @@ func newContext(glctx *gl.Functions) (*context, error) {
 // floatTripleFor determines the best texture triple for floating point FBOs.
 func floatTripleFor(ctx *context, ver [2]int, exts []string) (textureTriple, error) {
        var triples []textureTriple
+       /*
        if ver[0] >= 3 {
                triples = append(triples, textureTriple{gl.R16F, gl.Enum(gl.RED), gl.Enum(gl.HALF_FLOAT)})
        }
+       */
        if hasExtension(exts, "GL_OES_texture_half_float") || hasExtension(exts, "EXT_color_buffer_half_float") {
                triples = append(triples, textureTriple{gl.RGBA, gl.Enum(gl.RGBA), gl.Enum(gl.HALF_FLOAT_OES)})
        }
+       /*
        if hasExtension(exts, "GL_OES_texture_float") || hasExtension(exts, "GL_EXT_color_buffer_float") {
                triples = append(triples, textureTriple{gl.RGBA, gl.Enum(gl.RGBA), gl.Enum(gl.FLOAT)})
        }
+       */
        tex := ctx.CreateTexture()
        defer ctx.DeleteTexture(tex)
        ctx.BindTexture(gl.TEXTURE_2D, tex)

Fails on both my patched Lima and on AMDGPU. glCheckFramebufferStatus returns GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT in this case.

~sircmpwn 7 months ago

The Lima developers have asked me to pass along this warning: everything will be 2x slower with FP16 textures compared to RGBA8888.

~sircmpwn 7 months ago

Managed to get past these issues, now dealing with sRGB support. Still knee deep in driver land. Gio should consider a more conservative approach to OpenGL if you hope to have good mobile support...

~eliasnaur 7 months ago

On Wed Dec 11, 2019 at 3:42 AM ~sircmpwn wrote:

The Lima developers have asked me to pass along this warning: everything will be 2x slower with FP16 textures compared to RGBA8888.

If it makes any difference, gio only needs one channel of FP16.

The ideal format is a single-channel (GL_RED) half-float target. Having a four-channel FP16 texture is indeed a waste in memory and (depending on how Lima does FP16) processing. Worse, the 4-channel fallback is only needed on slower GPUs where both resources are scarce.

So gio could do a combination of the following to work around the FP FBO issue:

  • When forced to use a 4-channel RGBA FP16 format, use all 4 channels and a quarter of the texture dimensions.
  • Not use RGBA FP16 formats at all and instead convert the single channel floating point to and from 4-channel RGBA bytes in the shaders. Perhaps that's what the Lima developers are doing, but with a (slower) R16G16B16 format?
  • Cache the outline renders across frames. Text shape rendering is by far the most expensive to draw even with perfect FBO support, and the shapes rarely change.

I'm pretty sure #3 is going to happen regardless of this issue. Doing the other 3 depends on sRGB, see below.

Managed to get past these issues, now dealing with sRGB support. Still knee deep in driver land. gio should consider a more conservative approach to OpenGL if you hope to have good mobile support...

I don't see how gio can get around not having at least sRGB texture support (an sRGB framebuffer is optional but saves a window sized copy per frame) without either (1) ditching sRGB altogether or (2) accept different rendering output depending on device.

So in conclusion, if you can get sRGB support on the Lima, I'm happy to attempt the FP FBO workarounds above. Otherwise, I'm not convinced it's worth the trouble.

~eliasnaur 7 months ago

According to my reading of GL_OES_texture_half_float, the single channel GL_LUMINANCE is supported with HALF_FLOAT_OES. The commit https://git.sr.ht/~eliasnaur/gio/commit/8a44ac11d8379ccb4214e5daaf113194fa95c1f3 implements that, keeping the 4-channel fallback.

Does that work on Lima, and in particular fixes the "everything will be 2x slower with FP16 textures compared to RGBA8888." warning? If so, the first two FBO workarounds from above are not required, leaving only the caching optimization.

~sircmpwn 7 months ago

That change still doesn't work on any driver if you force the half-float codepath, following this comment in the Mesa fbobject implementation:

/* OES_texture_float allows creation and use of floating point
          * textures with GL_FLOAT, GL_HALF_FLOAT but it does not allow
          * these textures to be used as a render target, this is done via
          * GL_EXT_color_buffer(_half)_float with set of new sized types.
          */

OES_texture_(half_)float does not support being used as a render target. But yes, I think if you use a single-channel half-float buffer you'll avoid the bandwidth issues.

Still working on sRGB.

~sircmpwn 7 months ago

Note that this would require GLES 3.0 or newer, which is unfortunate.

~eliasnaur 7 months ago

Thanks, I re-added the GL_EXT_color_buffer_half_float check (spelled correctly this time) in 4a628d1c2c2c268ef896a25ce9c742817c6d706e.

What do you mean by "GLES 3.0 or newer"? https://www.khronos.org/registry/OpenGL/extensions/OES/OES_texture_float.txt lists the LUMINANCE/HALF_FLOAT_OES combination.

~sircmpwn 7 months ago

GL_EXT_color_buffer_half_float requires GLES 3.0 or newer. OES_texture_float does not support being used as a render target.

~eliasnaur 7 months ago

https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_color_buffer_half_float.txt says "Requires OpenGL ES 2.0.", and AFAIK GLES 3.0 has both floating point targets and FP FBOs in core. What did I miss?

~sircmpwn 7 months ago

~sircmpwn 7 months ago

EXT_color_buffer_half_float in Lima may be possible but would be Hard. Can you get away without using float textures as render targets?

~eliasnaur 7 months ago

On Wed Dec 11, 2019 at 2:59 PM ~sircmpwn wrote:

EXT_color_buffer_half_float in Lima may be possible but would be Hard. Can you get away without using float textures as render targets?

Yes, I believe so. Note that without render support (EXT_color_buffer_half_float), gio won't need float textures (OES_texture_half_float).

~raff 5 months ago

Same error on MacOS Catalina on MacBook Pro 15" 2016

~eliasnaur 5 months ago

On Mon Feb 10, 2020 at 7:27 PM, ~raff wrote:

Same error on MacOS Catalina on MacBook Pro 15" 2016

I tried the kitchen example on an old Macbook Air with Cataline 10.16.3, which worked fine.

The error means that Gio failed to detect an extension allowing floating point FBOs. Can you send me a dump of your GPU capabilities, for example from

https://apps.apple.com/us/app/opengl-extensions-viewer/id444052073?mt=12

?

Thanks.

Raffaele Sena 5 months ago

Not sure of what you really want (I don't see any option to get a full dump. I see a "save as text" button that doesn't seem to be anything. Is this enough (otherwise send me the step to get the info you need):

Renderer: Intel(R) HD Graphics 530 Vendor: Intel Inc. Version: 4.1 INTEL-14.4.23 Device: MacBookPro13,3 Shading language version: 4.10

Max texture size: 16384 x 16384 Max vertex texture image units: 16 Max texture image units: 16 Max geometry texture units: 16 Max anisotropic filtering value: 16 Max viewport size: 16384 x 16384 Max Clip Distances: 8 Max samples: 16

Extensions: 45

GL_ARB_tessellation_shader GL_APPLE_texture_range GL_EXT_framebuffer_multisample_blit_scaled GL_ARB_viewport_array GL_ARB_gpu_shader_fp64 GL_ARB_explicit_attrib_location GL_NV_texture_barrier GL_ARB_separate_shader_objects GL_ARB_texture_storage GL_ARB_gpu_shader5 GL_ARB_texture_swizzle GL_EXT_texture_compression_s3tc GL_ARB_texture_cube_map_array GL_ARB_blend_func_extended GL_ARB_vertex_attrib_64bit GL_EXT_texture_sRGB_decode GL_ARB_texture_gather GL_EXT_texture_filter_anisotropic GL_APPLE_row_bytes GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_draw_indirect GL_ARB_texture_query_lod GL_ARB_draw_buffers_blend GL_ARB_sample_shading GL_ARB_internalformat_query GL_ARB_timer_query GL_ARB_shader_subroutine GL_ATI_texture_mirror_once GL_EXT_debug_marker GL_APPLE_rgb_422 GL_ARB_vertex_type_2_10_10_10_rev GL_EXT_debug_label GL_ARB_texture_buffer_object_rgb32 GL_ARB_instanced_arrays GL_APPLE_container_object_shareable GL_ARB_ES2_compatibility GL_APPLE_client_storage GL_ARB_sampler_objects GL_ARB_occlusion_query2 GL_ARB_shading_language_include GL_ARB_texture_rgb10_a2ui GL_APPLE_object_purgeable GL_ARB_shader_bit_encoding GL_APPLE_flush_render

Core features

v3.0 (100 % - 23/23) v3.1 (100 % - 7/7) v3.2 (100 % - 10/10) v3.3 (100 % - 10/10) v4.0 (100 % - 14/14) v4.1 (100 % - 7/7) v4.2 (15 % - 2/13) v4.3 (0 % - 0/20) v4.4 (0 % - 0/10) v4.5 (0 % - 0/11) v4.6 (0 % - 0/11) vARB 2015 (0 % - 0/12)

OpenGL driver version check (Current: 4.1 INTEL-14.4.23, Latest known: ): Latest version of display drivers found According the database, you are running the latest display drivers for your video card.

On Mon, Feb 10, 2020 at 11:45 AM ~eliasnaur outgoing@sr.ht wrote:

On Mon Feb 10, 2020 at 7:27 PM, ~raff wrote:

Same error on MacOS Catalina on MacBook Pro 15" 2016

I tried the kitchen example on an old Macbook Air with Cataline 10.16.3, which worked fine.

The error means that Gio failed to detect an extension allowing floating point FBOs. Can you send me a dump of your GPU capabilities, for example from

    https://apps.apple.com/us/app/opengl-extensions-

viewer/id444052073?mt=12

?

Thanks.

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/49#comment-6080

Raffaele Sena referenced this from #49 5 months ago

~eliasnaur 5 months ago

On Mon Feb 10, 2020 at 8:28 PM, Raffaele Sena wrote:

Not sure of what you really want (I don't see any option to get a full

dump. I see a "save as text" button that doesn't seem to be anything.

Is this enough (otherwise send me the step to get the info you need):

Thank you, that was what I meant. Unfortunately, I don't see anything wrong with the OpenGL cap dump. I added a more detailed error message for the floating point FBO case. Can you try a Gio example at commit e8add40440b388b532e52d6dbc88fcb4b225d90c or later?

--elias

Raffaele Sena 5 months ago

I'll try later. I did a few testing and what I see is that none of the "texture float" capabilities is set, so the triples list is empty.

On Tue, Feb 11, 2020 at 6:43 AM ~eliasnaur outgoing@sr.ht wrote:

On Mon Feb 10, 2020 at 8:28 PM, Raffaele Sena wrote:

Not sure of what you really want (I don't see any option to get a full

dump. I see a "save as text" button that doesn't seem to be anything.

Is this enough (otherwise send me the step to get the info you need):

Thank you, that was what I meant. Unfortunately, I don't see anything wrong with the OpenGL cap dump. I added a more detailed error message for the floating point FBO case. Can you try a Gio example at commit e8add40440b388b532e52d6dbc88fcb4b225d90c or later?

--elias

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/49#comment-6093

Raffaele Sena referenced this from #49 5 months ago

~eliasnaur 5 months ago

Interesting. Are you saying that even the version check here

https://git.sr.ht/~eliasnaur/gio/tree/master/gpu/gl/backend.go#L452

fails? If so, the problem appears to be in gl.ParseGLVersion

https://git.sr.ht/~eliasnaur/gio/tree/master/gpu/gl/util.go#L63

Raffaele Sena 5 months ago

Yes, I didn't print the version but didn't go through that path. I'll check what gl.ParseGLVersion returns...

On Tue, Feb 11, 2020 at 7:56 AM ~eliasnaur outgoing@sr.ht wrote:

Interesting. Are you saying that even the version check here

https://git.sr.ht/~eliasnaur/gio/tree/master/gpu/gl/backend.go#L452

fails? If so, the problem appears to be in gl.ParseGLVersion

https://git.sr.ht/~eliasnaur/gio/tree/master/gpu/gl/util.go#L63

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/49#comment-6095

Raffaele Sena referenced this from #49 5 months ago

Raffaele Sena 5 months ago

So, I am getting somewhere...

I have printed out some info about the GL engine and I get this:

VENDOR ATI Technologies Inc. RENDERER AMD Radeon Pro 455 OpenGL Engine VERSION 2.1 ATI-3.5.5 SHADING LANGUAGE VERSION 1.20

If I run GLView I get this:

  • "core" mode:

Renderer: AMD Radeon Pro 455 OpenGL Engine Vendor: ATI Technologies Inc. Version: 4.1 ATI-3.5.5 Device: MacBookPro13,3 Shading language version: 4.10

  • "compatibility" mode:

Renderer: Intel(R) HD Graphics 530 Vendor: Intel Inc. Version: 2.1 INTEL-14.4.23 Device: MacBookPro13,3 Shading language version: 1.20

So, it seems OpenGL is running in the compatibility mode/profile, that is the default mode.

I was looking at the C.gio_createGLView, that seems to be what sets the profile to 3.2 Core, but I am suspecting that it would be called AFTER you check for the version. Is that possible ?

On Tue, Feb 11, 2020 at 9:14 AM Raffaele Sena outgoing@sr.ht wrote:

Yes, I didn't print the version but didn't go through that path. I'll

check what gl.ParseGLVersion returns...

On Tue, Feb 11, 2020 at 7:56 AM ~eliasnaur outgoing@sr.ht wrote:

Interesting. Are you saying that even the version check here

https://git.sr.ht/~eliasnaur/gio/tree/master/gpu/gl/backend.go#L452

fails? If so, the problem appears to be in gl.ParseGLVersion

https://git.sr.ht/~eliasnaur/gio/tree/master/gpu/gl/util.go#L63

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/49#comment-6095

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/49#comment-6096

Raffaele Sena referenced this from #49 5 months ago

~eliasnaur 5 months ago

On Tue Feb 11, 2020 at 6:01 PM, Raffaele Sena wrote:

So, I am getting somewhere...

I have printed out some info about the GL engine and I get this:

VENDOR ATI Technologies Inc. RENDERER AMD Radeon Pro 455 OpenGL Engine VERSION 2.1 ATI-3.5.5 SHADING LANGUAGE VERSION 1.20

If I run GLView I get this:

  • "core" mode:

Renderer: AMD Radeon Pro 455 OpenGL Engine Vendor: ATI Technologies Inc. Version: 4.1 ATI-3.5.5 Device: MacBookPro13,3 Shading language version: 4.10

  • "compatibility" mode:

Renderer: Intel(R) HD Graphics 530 Vendor: Intel Inc. Version: 2.1 INTEL-14.4.23 Device: MacBookPro13,3 Shading language version: 1.20

So, it seems OpenGL is running in the compatibility mode/profile, that is the default mode.

I was looking at the C.gio_createGLView, that seems to be what sets

the profile to 3.2 Core, but I am suspecting that it would be called

AFTER you check for the version. Is that possible ?

I don't think so. The version comes from glGetString(GL_VERSION) which is called with a fully initialized OpenGL context.

I checked GLCaps on my own mac, and my results look very similar to yours: a core 4.1 profile and a compatibility 2.1 profile.

Something else must be going on. Did you get a chance the check the actual version returned by ParseGLVersion and the set of triples attempted (and failed)?

-- elias

Register here or Log in to comment, or comment via email.