[gstreamer-bugs] [Bug 431252] Very simple & universal way to make serious hw acceleration.

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=431252

  GStreamer | don't know | Ver: HEAD CVS




------- Comment #10 from Edward Hervey  2007-05-30 09:38 UTC -------
(In reply to comment #9)
> The problem with the approach in the example code above is that glReadPixels is
> notoriously slow. On modern cards with a PCI-X bus, it's less so, but on older
> cards, reading back from the gfx card has always been a slow process. 

  What other methods exist to read data back from the GPU ? If you check out
modern software that offer GPU acceleration... they all have in their
recommendation to have a PCI-X bus.

> 
> It's certainly not feasible to read the frames back and forth for several
> processing steps - it very quickly saturates the bus.

  Totally agree. The current code was just a proof of concept to show it's
possible to actually do some processing on the GPU and re-use the processed
data as a GStreamer element in the middle of a pipeline.

> 
> In general, I think we can concoct a method where a glxcontext is passed
> between elements using buffer_alloc somehow though, so that multiple processing
> steps can be performed in a chain with the results being read back at the end,
> either by an element which has the job of allocated the glx context and passing
> it upstream, then reading the pixels at the end, or by having each element in
> the chain recognise that downstream wants image/x-raw-rgb and taking the task
> on itself.
> 

  Using buffer_alloc to share the context could be a good idea, but might
require a specific mime type (application/glx-context ?).
  Solving all these issues would be best done by having a base class for opengl
processing elements (derived straight from GstElement to offer maximum
flexibility). That base class would take care of settingup/tearingdown the glx
context, doing the buffer alloc, knowing when to send the data to the GPU
(because the previous element was not already there) or retrieve it (because
downstream elements are not gpu-based), ....

  Also we need to take into account conflicts between several glx contexts
running simultaneously (gpu-proc ! non-gpu-proc ! gpu-proc), potential
conflicts with opengl-accelerated desktops, optimizations when using opengl
sinks, ....


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=431252.