~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
5 months ago
Updated
a month ago
Labels
No labels applied.

~eliasnaur 5 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 5 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 5 months ago

Same result on X11

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

~fasmide 5 months ago

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

~eliasnaur 5 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 3 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 3 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 3 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 HALFFLOAT(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 3 months ago

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

~eliasnaur 3 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 3 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 3 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 3 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 3 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 3 months ago

According to my reading of GLOEStexturehalffloat, the single channel GLLUMINANCE is supported with HALFFLOAT_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 3 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 3 months ago

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

~eliasnaur 3 months ago

Thanks, I re-added the GLEXTcolorbufferhalf_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/HALFFLOATOES combination.

~sircmpwn 3 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 3 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 3 months ago

Ah, I'm looking at this: https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_color_buffer_float.txt

~sircmpwn 3 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 3 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 a month ago

Same error on MacOS Catalina on MacBook Pro 15" 2016

~eliasnaur a month 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 a month 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

GLARBtessellationshader GLAPPLEtexturerange GLEXTframebuffermultisampleblitscaled GLARBviewportarray GLARBgpushaderfp64 GLARBexplicitattriblocation GLNVtexturebarrier GLARBseparateshaderobjects GLARBtexturestorage GLARBgpushader5 GLARBtextureswizzle GLEXTtexturecompressions3tc GLARBtexturecubemaparray GLARBblendfuncextended GLARBvertexattrib64bit GLEXTtexturesRGBdecode GLARBtexturegather GLEXTtexturefilteranisotropic GLAPPLErowbytes GLARBtransformfeedback2 GLARBtransformfeedback3 GLARBdrawindirect GLARBtexturequerylod GLARBdrawbuffersblend GLARBsampleshading GLARBinternalformatquery GLARBtimerquery GLARBshadersubroutine GLATItexturemirroronce GLEXTdebugmarker GLAPPLErgb422 GLARBvertextype2101010rev GLEXTdebuglabel GLARBtexturebufferobjectrgb32 GLARBinstancedarrays GLAPPLEcontainerobjectshareable GLARBES2compatibility GLAPPLEclientstorage GLARBsamplerobjects GLARBocclusionquery2 GLARBshadinglanguageinclude GLARBtexturergb10a2ui GLAPPLEobjectpurgeable GLARBshaderbitencoding GLAPPLEflush_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 a month ago

~eliasnaur a month 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 a month 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 a month ago

~eliasnaur a month 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 a month 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 a month ago

Raffaele Sena a month 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 a month ago

~eliasnaur a month 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.