[x264-devel] Re: Speed-up method

Radek Czyz radoslaw at syskin.cjb.net
Sat Mar 3 15:48:10 CET 2007


 > I was more thinking about letting the GPU do _all_ the work

I think you need to. If you tried to copy a video frame's worth of data 
from a video card to system memory (say, trying to read DXVA-decoded 
DVD), you'd manage more or less realtime. Using 100% of a cpu, because 
cpu has to stall while waiting. Not a good idea.

Tomas Carnecky wrote:
> Guillaume POIRIER wrote:
>> On 3/3/07, Tomas Carnecky <tom at dbservice.com> wrote:
>>> PCI-E has a very big bandwidth, even for GPU->CPU transport (maximum
>>> with my 7800 is ~1150 MB/s).
>>
>> But latency is very poor (compared to a HT link (AMD) or shared L2/FSB
>> communication(intel) ). That can easily kill all speed-ups you gained
>> from the GPU. You then need to let the GPU do a lot of work without
>> having the data going back and forth between the CPU and GPU, which
>> requires serious threading effort (it's not garanteed that x264's
>> threading model maps too well on heterogenous archs like CPU+GPU).
>>
> 
> I was more thinking about letting the GPU do _all_ the work :P. In HDTV 
> resolution (1920x1280, progressive), one picture is 3.6MB, so it would 
> be possible to send ~310 frames/s to the card. That's more than enough.
> The host application would then only read the raw bitstream from the card.
> 
> And btw, the GPU does int<->float conversions all the time. Maybe the 
> GPU is faster than the CPU even when dealing with integers.
> 
> tom
> 

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html



More information about the x264-devel mailing list