[PD-dev] GEM passing output image later.

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-02-29 02:06, Gert De Roost wrote:

> What I want to do though, is outputting the image only when the next image
> is being started to process.  I'll explain why: I do a call to
> glReadPixels, which needs quite some time to finish, but by ussing Pixel
> Buffer Objects, I can do this transmitting from GPU to CPU asynchronously,
> so I can do stuff during the wait for glReadPixels to finish, then I can
> copy the buffer into the output image.  Best is to wait for the next image,
> which comes mostly more then 20ms later, so meanwhile the call can complete.
> GEMs design doesnt facilitate outputting an image after the end of the
> processing method though...  Is there some method internal to GEM that I
> can use to directly send some data to the image outlet?  Or does anyone
> have an idea how to wait for glReadPixels without at the same time blocking
> the CPU?

i think this is the wrong approach for Gem.
FFGL does processing on the GPU. this is what Gem is all about. the
pix_... stuff (in CPU-space) is only a small subset of Gem.
a good integration into Gem would therefore be, to allow Gem to do all
the CPU<->GPU transfers (using [pix_texture], [gemframebuffer],
[pix_snap2tex] on the one side and [pix_snap] on the other side) and
make FFGL only work on the textures itself.
this allows for both optimizing the transfers independently of FFGL (and
have other uses profit from those optimizations) while at the same time
allowing for more different uses (e.g. if you use [gemframebuffer] to
generate your texture you want to apply an FFGL effect on, there is
really no need to transfer the data from GPU to CPU, then transfer it
back to GPU to do the FFGL processing and transfer it back to CPU, only
to finally transfer the data from CPU to GPU again to display the image).


and both [pix_texture] and [pix_snap] allow for asynchronous
DMA-transfers already (though i only added PBO-tarnsfers to [pix_snap] a
week ago or so).
it's not really documented anywhere (yet), but you can send a [pbo $1(
message to both these objects to specify the number of PBOs to use (with
"0" being the default behaviour)

fgmadr
IOhannes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9N4xIACgkQkX2Xpv6ydvRaDQCgzTUBt1UxsQZ2Bu0xBMCozx1L
xEEAoJGAylMzIJNXBBdOZjNqRfoTYStW
=7b3e
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120229/1ace2d10/attachment-0001.bin>