[PD-dev] pbo transfert WAS: GEM passing output image later.

[IOhannes m zmoelnig]

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

On 2012-02-29 10:52, Cyrille Henry wrote:
> 
> 
> Le 29/02/2012 09:34, IOhannes m zmoelnig a écrit :
> 
>> 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)
> 
> Do you mean that since last week pix_snap should be lot's faster than it
> use to be?

the default behaviour is still the same (pbo==0)
this is mainly because i found that the optimal setting varies greatly
from machine to machine.
e.g. on my netbook with fglrx drivers, the old non-pbo method is somehow
faster...
on my desktop (with some old nvidia card), using PBOs is faster.

> i'd like to understand a bit more the use of single  / multiple PBO :
> what happens if 2 pix_video / pix_texture use the same PBO : will it be
> slower than using 2 different PBO? (since 2nd pix_texture have to wait
> for the PBO to be free in order to use it)???

each  [pix_texture] will use their own set of PBOs.

when using more PBOs, you basically get a ring-buffer: while the current
image is uploaded using PBO(n), PBO(n-1) is displayed, so the upload has
one frametick to complete.
it also means, you get a delay when using >1 PBOs.

i haven't done any benchmarking with multiple image-sources (though the
PBO support for [pix_texture] was implemented in order to get reasonable
speed when displaying multiple hires videos for an installation)

> same question with a pix_video / pix_texture and a pix_snap : is using 2
> PBO lot's faster than using the same PBO (default behaviour)?

just try it :-)

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

iEYEARECAAYFAk9OCY8ACgkQkX2Xpv6ydvRf7gCfWiihXE5UH+15Nvpo4HA09tKo
Q5wAnRXfUhdc6IrhWkHOsKzo3KrF9uh7
=wCyQ
-----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/6706b6f2/attachment.bin>