-----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