-----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-----
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
