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

[Jan Schmidt]

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.

Thoughts?
J.

-- 
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.)