GNOME Bugzilla – Bug 730927
gl: avoid using an extra FBO pass for formats that requires a shader at upload time
Last modified: 2018-11-03 11:30:09 UTC
Currently "videotestsrc ! video/x-raw, format=I420 ! glimagesink" uses a shader to do the color convertion, it's fine but we use a FBO for that which can be avoided. Indeed we could draw directly to the window surface.
Does it require https://bugzilla.gnome.org/show_bug.cgi?id=729278#c5 ?
This one would require the ability to set the framebuffer object for colorconvert to operate on. We may have to wait until we grow a reasonable framebuffer api for that to occur.
There is still this extra pass on current master right ? Framebuffer api has not changed since then: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglframebuffer.h Since glimagesink is now a bin, should glupload just draw directly to the window if glcolorconvert is set as passthrough ? glcolorconvert could also draw directly to the window back buffer in theory when used in glimagesink bin. I am insisting on this because on embedded, requiring extra FBOs rapidly brings gpu memory usage to a high percent of its maximum, on large resolutions. I think even when using EGLImage we have currently extra passes.
In most cases, yes. The only case that doesn't have this extra pass is external textures on android. glupload doesn't do any render passes so will not change no matter then pipeline configuration. The bit that needs some work is the glcolorconvert/glviewconvert/glimagesink interaction. The last operation before the render to the screen would need to encapsulate the draw state and pass it to glimagesink to render in order to avoid the trampoline through the texture. Then glimagesink would also need to be able to render it repeatedly for redraws. I'm not sure yet how to implement that.
Any plan for that or we should close it ?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/121.