[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