[FFmpeg-devel] transcoding on nvidia tesla

[Stefan de Konink]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

christophelorenz schreef:
> You can do that, but it will stall the gpu processing because of the 
> latency.
> It is much more efficient to transfer to gpu memory first, then process 
> from there, as the transfer operation doesn't bloc the gpu process queue.
> It is realistic when using directx, however with openGL you don't really 
> have control over the transfer... (unless you force a costly buffer copy)
> It might decide to delay the transfer just before using the texture 
> which might ruin the performance.
> The big advantage of cuda is that you control exactly when the transfer 
> takes place and it is optimised even for small amount of data.
> Using pixel buffers to transfer small amount of data is very expensive.
> 
> Also you cannot write to system memory using pixel buffers. (render 
> targets must be in gpu memory)
> So you have to do the process then copy back data.
> 
> I think massive parallelisation will be the future of computers and 
> programmers whatever happens.
> The challenge will be redesigning all the old the algorithms that are 
> serial by design to work in parallel.
> Basic things like an efficient generic sort are really challenging.
> So I won't even talk about porting ffmpeg on it...

I have seen: http://gentoo-wiki.com/TIP_Use_memory_on_video_card_as_swap


If this works, it must be possible using a separate kernel module to do
something like preloading data to the card. The only thing I don't quite
understand is the 'sharing' part of the data.

Is the CUDA stuff available when the binary driver is not installed?



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

iD8DBQFHsCzAYH1+F2Rqwn0RCrrHAJ9CKgNBSk8ek4rffhnnZ6bM5HYAqgCfR2wO
qLUUA7fpnhLHae+g+IQVLyI=
=GKh3
-----END PGP SIGNATURE-----