[gst-devel] Re: [gst-cvs] ds gst-plugins-bad: gst-plugins-bad/ gst-plugins-bad/sys/ gst-plugins-bad/sys/glsink/

Jan Schmidt thaytan at noraisin.net
Mon Jan 30 08:06:01 CET 2006

On Fri, 2006-01-27 at 20:39 -0800, David Schleef wrote:
> CVS Root:       /cvs/gstreamer
> Module:         gst-plugins-bad
> Changes by:     ds
> Date:           Fri Jan 27 2006  20:39:30 PST
> Log message:
> * configure.ac:
> * sys/Makefile.am:
> * sys/glsink/Makefile.am:
> * sys/glsink/glimagesink.c:
> * sys/glsink/glimagesink.h:
> revival of glimagesink.  Kind of works.

In Togra the other day (togra.sf.net) I discovered that my performance
had started sucking really badly since the last time I used it. After a
couple of hours trying to figure out what I had broken, I eventually
discovered that libGL cannot be dlopen'd unless it's loaded into the
global symbol table with RTLD_GLOBAL, or else it falls back to Indirect
rendering - which at the moment means software rendering.

This same caveat applies to glimagesink, I expect. It will only manifest
on some GL implementations, DRI in this case, but the DRI guys told me
that they expect the OpenGL board to specify RTLD_GLOBAL type semantics
as a requirement for GL using apps.

That said, how can we support it in GStreamer? The 2 thoughts that occur
to me are 1) glimagesink has to resolve libGL.so and dlopen it itself.
2) Add a flag that lets plugins register their requirement to be loaded
into the global symbol table and implement that in core.


Jan Schmidt thaytan at noraisin.net

Pants Pants Pants Pants Pants Pants Pants Pants.
Lovely Pants, wonderful Pa-ants.
Lovely Pants, wonderful Pa-ants.
(Shut up! Bloody Vikings.)

More information about the gstreamer-devel mailing list