[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.
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.)
More information about the gstreamer-devel
mailing list