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

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

Same result on X11

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

~fasmide 2 months ago

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

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

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

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

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

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

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

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

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

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

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