CUDA H.264 vs x264 Speed and Image Quality Benchmarks, discussion [Archive] - Page 4

CruNcher

15th July 2009, 14:54

x264
12:480 sec = --preset ultrafast
13:915 sec = --preset veryfast --profile baseline --scenecut -1 --nf --partitions i8x8,p8x8 --aq-mode 0
14:204 sec = --preset veryfast --profile baseline --scenecut -1 --nf --partitions i8x8,p8x8

cuda
15:000 sec = ultrafast

3 mbits target 1280x720 25fps

so @ low bitrate targets cuda (in form of Nvidias Encoder) is pretty much useless compared to a old CPU architecture in this case AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (1603Mhz)

the visual quality in this case is also on the side of x264 compared vs a G92 8800GT 112 Stream Processors

X264 X2 vs G92 112 Stream Processors = X264 wins @ Baseline 3 mbit target (speed/quality)

stanleyhuang

15th July 2009, 15:54

is there any idea to tweak the image quality for CUDA encoding on MediaCoder ? :)

An update (http://www.mediacoderhq.com/dlupdate.htm) is available which adds a new option named "slice count". Increasing this option will bring possibly better quality.

CruNcher

15th July 2009, 16:00

how should the slice count that is by default currently @ 4 (2 cores) change anything visualy ?
changed slicecount to 1 though i can see no visual improvement only a slight bitrate behaviour change (hits target more accurate now) :)

@stanleyhuang
cudaH264Enc.exe output is missing all the processing data utilization (cpu/kernel), time, fps arent shown anymore :(

Video stream: 276480.000 kbit/s (34560000 B/s) size: 675993600 bytes 19.560 s
ecs 489 frames

NvEncodeTestAPI returned with return value = 0

PS: I would say from the current results i gathered so far a G92 with 112 Stream Processors (Shaderspeed 1.7 GHz) is currently as powerfull (if compared to x264 optimizations) as a Dualcore K8 @ 2.7 GHz (Toledo Core) in terms of Video Encodindg, though still have todo cabac, high bitrate, fullhd resolution tests

Cabac 720p (Main Profile) 3mbit:

x264 = --preset veryfast --profile main -b 0 --scenecut -1 --nf --partitions i8x8,i4x4,p8x8
cuda = -iw 1280 -ih 720 -fpsnum 25 -fpsden 1 -profile 1 -preset -1 -idrp 250 -qp 25 -qpp 28 -qpb 31 -slicecount 1 -pinterval 1 -darw 16 -darh 9 -rc 1

x264 = 15.9 sec
cuda = 17.5 sec

http://mirror05.x264.nl/CruNcher/force.php?file=./GPU-Encoding/x264-veryfast-aq-abr-6000-cabac-main.mp4
http://mirror05.x264.nl/CruNcher/force.php?file=./GPU-Encoding/cuda-ultrafast-6000-cabac-main.mp4

Cabac 1080p (High Profile) 6 mbit:

x264 = --preset veryfast --profile high -b 0 --scenecut -1 --nf --partitions i8x8,i4x4,p8x8
cuda = -iw 1920 -ih 1080 -fpsnum 25 -fpsden 1 -profile 2 -preset -1 -idrp 250 -qp 25 -qpp 28 -qpb 31 -slicecount 1 -pinterval 1 -darw 16 -darh 9 -rc 1

x264 = 247 sec
cuda = 253 sec

http://mirror05.x264.nl/CruNcher/force.php?file=./GPU-Encoding/x264-veryfast-aq-abr-1080p-6000-cabac-high.mp4
http://mirror05.x264.nl/CruNcher/force.php?file=./GPU-Encoding/cuda-ultrafast-1080p-6000-cabac-high.mp4

Result = A Geforce 8800 GT with 112 Stream Processors clocked @ 1.7 GHz has roughly the same Encoding Power as x264 on a Dualcore K8 @ 2.7 GHz, though still x264 can't be beat in Visual Quality results

St Devious

16th July 2009, 00:41

An update (http://www.mediacoderhq.com/dlupdate.htm) is available which adds a new option named "slice count". Increasing this option will bring possibly better quality.

i see that b-frames max are 16 now. How does increasing them from 8 to 16 affect quality ?

Is there a wiki somewhere explaining the meaning of all the options in CUDA encoder and how their values affect quality ?

LoRd_MuldeR

16th July 2009, 00:53

i see that b-frames max are 16 now. How does increasing them from 8 to 16 affect quality ?

We know from x264 that more than ~3-4 consecutive b-frames are only helpful in very rare cases. I doubt this is fundamentally different for the CUDA encoder.

Unless the CUDA encoder adaptively decides the optimal number of b-frames (like x264 does) and the option only limits the maximum, raising b-frames too much may even hurt quality.

St Devious

16th July 2009, 02:51

x264 = --preset veryfast --profile high -b 0 --scenecut -1 --nf --partitions i8x8,i4x4,p8x8
cuda = -iw 1920 -ih 1080 -fpsnum 25 -fpsden 1 -profile 2 -preset -1 -idrp 250 -qp 25 -qpp 28 -qpb 31 -slicecount 1 -pinterval 1 -darw 16 -darh 9 -rc 1

I'll try those CMD on my source and report back.

and why are you setting pinterval (bframes) to 0 ? Were you testing fastest for CUDA ?

Based on my testing, setting the bframes from 3 to 0 increases the time taken by about 5s, while setting it to 16 increases it by only 1s or even in some case none.

btw, how are you encoding CUDA ? I don't see those options in my commandline in mediacoder. i see something like

# ".\codecs\cudaH264Enc.exe" -i "$(SourceFile)" -o "$(DestFile)" -profile 2 -preset -1 -level 51 -idrp 250 -qp 25 -qpp 28 -qpb 31 -gop -deblock -forceintra -forceidr -pinterval 4 -darw 16 -darh 9 -rc 1 -abit $(VideoBitrate)

We know from x264 that more than ~3-4 consecutive b-frames are only helpful in very rare cases. I doubt this is fundamentally different for the CUDA encoder.

Unless the CUDA encoder adaptively decides the optimal number of b-frames (like x264 does) and the option only limits the maximum, raising b-frames too much may even hurt quality.

Thanks, just tested it for myself, 3 vs 16. no difference in quality, but 1s difference in encoding time.

CruNcher

16th July 2009, 10:51

i was testing lowest complexity possible, theres only 1 thing that is strange in the test with the Test Sequence combination @ BlueSky (1st Sequence) X264 is heavily reacting creating a massive peak over time that slowly vanishes not sure but might be caused by the AQ in this case.

http://s12.directupload.net/images/090716/3oadcya4.png

a lot of black frames and then RC seems to explode for several frames :(

it isn't such a big problem Nvidias Hardware Decoder has no problem Decoding this spike but in Software like ffh264 you can see that it slowsdown a little when this heavy bitrate curve hits the decoder.

Also it seems that Nvidia is using some automaticly calculated VBV setting (to avoid such peaks) seeing that it declares a bitrate in the stream.

dj_tjerk

16th July 2009, 11:24

Would you mind testing for funzies how the bitrate distribution looks with crf (play with the value of crf till you end up near the desired bitrate)?

CruNcher

16th July 2009, 12:19

As CRF is almost a 2pass the result isn't really surprising :)

http://mirror05.x264.nl/CruNcher/force.php?file=./GPU-Encoding/x264-veryfast-aq-crf-1080p-6000-cabac-high.mp4

http://s12.directupload.net/images/090716/wklv4i7o.png

especialy riverbed which imho is also the most complex scene motion estimation wise of all gets visualy out much better then with ABR or Nvidias RC :)

Nvidia Encoder (Cuda)
http://s12b.directupload.net/images/090716/temp/e7udo6dg.png (http://s12b.directupload.net/images/090716/e7udo6dg.png)
x264 abr
http://s12.directupload.net/images/090716/temp/rz4y2yw3.png (http://s12.directupload.net/images/090716/rz4y2yw3.png)
x264 crf
http://s12.directupload.net/images/090716/temp/qo7k2yzv.png (http://s12.directupload.net/images/090716/qo7k2yzv.png)

@stanleyhuang
there is also a bug in cudah264enc or better MediaCoders logic when setting -rc 0 (quality based) the user needs to provide a peak bitrate or the encoder errors out with

NVVE_AVG_BITRATE Failed

Set Encoder Params failed

stanleyhuang

16th July 2009, 13:49

there is also a bug in cudah264enc or better MediaCoders logic when setting -rc 0 (quality based) the user needs to provide a peak bitrate or the encoder errors out with

Thanks, will fix this.

CruNcher

16th July 2009, 15:31

Hmm i get allways the same bitrate result with quality based encoding no matter what the -rc 0 xx or -pbit settings are ?

PS: A new Cuda 2.3 Driver has been released by Nvidia 190.38, lets see if they changed something on the Video Encoder :)

DiKey

6th October 2009, 01:52

The last post is at 16.07.2009. There was no news?

seemees

21st October 2009, 05:53

stanleyhuang
When you make a stable version of MediaCoder with Cuda 2.3 support on h264 and may be on Dirac? I can't make an AVI file with Dirac or with h264. Only mkv with mkvmerge.exe (h264). What we need to produce play-able AVI with Dirac and with h264 - what codec or CLI program, please help.
with best regards, seemees

Audionut

21st October 2009, 12:09

Why on earth would you want to put h.264 in avi!! The only way to do so is with a hack.

Use a container that natively supports h.264.

seemees

21st October 2009, 12:49

Audionut
Why not? :-)
AVI container is in options - isn't it? And with virtual dub and ffdshow or h264vfw - AVI maked easy. But in Media codec - NOT.
AVI support for h264 ready:
http://en.wikipedia.org/wiki/Comparison_of_container_formats#cite_note-H.264_in_AVI-3
Through an updated x264/ffdshow filter it is possible to view H.264 in an AVI file.
With best regards to you, seemees

roozhou

21st October 2009, 12:56

Why on earth would you want to put h.264 in avi!! The only way to do so is with a hack.

Use a container that natively supports h.264.

What hack? And why do you call it a hack? I wrote a program putting H264 into avi in the same way of other codecs. It plays fine. I have even seen DV store 1920x1080 AVC + AAC in avi on a SD Card.

LoRd_MuldeR

21st October 2009, 13:25

Please, no AVI flamewar ;)

Once again: You must distinguish between limitations in AVI and limitations in VFW (Video for Windows).

While most AVI's are created using VFW Codecs (e.g. VirtualDub), there are other, better ways to create AVI's (MEncoder, Avidemux, etc).

As far as I know the main problem with AVI itself is that it doesn't know about B-Frames. Frames in AVI are either makred as Key-Frames (which equals IDR in H.264) or as Delta-Frames (which equals P-Frames in H.264). Also AVI doesn't support "progressive download", as the index block is stored at the end of the file. The problem with VFW (and not with AVI itself!) is that it has a strict "one frame in, one frame out" behaviour. So the encoder cannot access "future" frames without returning the current frame first, which makes it impossible to code B-Frames.

As far as I know, the workaround (or "hack") that DivX came up with to do B-Frames with VFW is: Return dummy Null-Frames and then later pack the B- and P-Frame into one frame.

That is commonly referred to as the "Packed Bitstream" hack. But it's specific to VFW. It's not required for AVI in general...

roozhou

21st October 2009, 13:38

As far as I know, the workaround (or "hack") that DivX came up with to do B-Frames with VFW is: Return dummy Null-Frames and then later pack the B- and P-Frame into one frame.

That is commonly referred to as the "Packed Bitstream" hack. But it's specific to VFW. It's not required for AVI in general...

AVC in avi does NOT use "Packed Bitstream". The H264 frames are sequentially stored in avi in its decoding order, which is the same way MKV and MP4 do. Windows' built-in avi splitter and all H264 decoders can handle it and generate correct frames and PTS.

LoRd_MuldeR

21st October 2009, 13:46

AVC in avi does NOT use "Packed Bitstream". The H264 frames are sequentially stored in avi in its decoding order, which is the same way MKV and MP4 do. Windows' built-in avi splitter and all H264 decoders can handle it and generate correct frames and PTS.

I didn't imply that "packed bitstream" is used with H.264 in AVI. I just said that "hack" exists to workaround a limitation in VFW related to creating B-Frames. However if one would like to create a H.264 AVI file through the VFW interface and use B-Frames, a similar "workaround" would be needed, I think. Tools that create AVI files not through VFW (e.g. Avidemux) don't need it for sure...

Audionut

21st October 2009, 14:12

Well, fwiw, using a 17 year old container for a 6 year old standard is ....

<pengvado> <Dark_Shikari> if a fansubber or DVD rip group uploaded an H.264-in-AVI file they'd get laughed off the internet
<Dark_Shikari> Probably
<pengvado> but asp-in-avi wouldn't be laughed at
<Dark_Shikari> of course not, ASP in AVI is normal unless you want softsubs
<pengvado> and asp-in-avi requires exactly the same ugly hacks
<Dark_Shikari> Probably because its been that way so long that everyone is accustomed to it
<pengvado> which just goes to show that our campaign to use a new codec as an excuse to tell people to upgrade their container is working

LoRd_MuldeR

21st October 2009, 14:26

Well, fwiw, using a 17 year old container for a 6 year old standard is ....

...completely unrelated to whether that container is suitable or not. If at all, we need technical arguments against using AVI, instead of polemic. And I tried to sum them up here (http://forum.doom9.org/showthread.php?p=1336612#post1336612).

BTW: Isn't this getting off-topic? :p

seemees

21st October 2009, 15:18

For respectable All
I have a dozen AVI with h264, I have a some (a little) mkv with it. Here the big differencies (on PC of course):
1.AVI seek very fast.
2.MKV seek very SLOW. more then 1-2 seconds some time.
3.AVI errors easy to recover (AVI reconst and setra).
4.MKV reconst - bad idea. No one really worked product for do this (I know i bad searcher in inet).
5.AVI smoller size and fast downloads from inet (cause a smaller bitrate used < 2000 kbps).
6.MKV huge 4-30G size and hard to downloads from inet (bitrate > 4000 kbps).
7.AND ANY of MKV 100% has a 1-50 frame error with bad artifacts and so on (lost lines, squares, color dismatches...) It is an entropy of BIG size...
Thus The AVI need us. The developers MUST implement him in his products. Isn't it?

One thing really RIGHT worked with MKV is Haali media splitter. And other applications have many errors and mismatchs for this format...

MP4 is same as MKV. New and no handful, AVI is really-really old but GOOD friend of us.

With best regards, seemees

Guest

21st October 2009, 15:20

Lord_Mulder is right, this is OT. Please take this to an appropriate place.

CpT

21st October 2009, 17:52

@CruNcher I get the same thing with -pbit + the latest mediacoder version. Doesn't seem to do anything.

Something I've been toying around with:
qp level I 20
qp level P 22
qp level B 22

The main issue I'm having with it is it doesn't caculate aspect correctly for anamorphic. And the resizer seems borked.

nakTT

14th December 2009, 16:15

1) Any new development on this?
2) What is the quality (at the same bitrate) comparison now?
3) Is CUDA getting closer to x264 than ever before or x264 is pulling away?

Please share info.

Firebird

14th December 2009, 16:52

Is CUDA getting closer to x264
No. It will never be as good as x264 is.

LoRd_MuldeR

14th December 2009, 17:01

Is CUDA getting closer to x264 No. It will never be as good as x264 is.

That statement doesn't make sense. CUDA is a platform technology while x264 is one specific software. So you are comparing apples and oranges ;)

So the real question is: Will GPGPU-based (CUDA, Stream, OpenCL, etc.) H.264 encoders eventually beat CPU-only encoders performance-wise and quality-wise?

Well, currently it doesn't look like this will happen soon. But this may change with upcoming GPU generation...

Cyber-Mav

14th December 2009, 17:04

cuda is getting closer now in quality.

nakTT

14th December 2009, 17:12

That statement doesn't make sense. CUDA is a platform technology while x264 is one specific software. So you are comparing apples and oranges ;)

So the real question is: Will GPGPU-based (CUDA, Stream, OpenCL, etc.) H.264 encoders eventually beat CPU-only encoders performance-wise and quality-wise?

Well, currently it doesn't look like this will happen soon. But this may change with upcoming GPU generation...
Thanks Loard, that's what I meant.

Quality wise, what the upcoming GPU generation got to do with it? It is just the hardware, I can understand if it speed wise. Please shed some light on this.

:thanks:

roozhou

14th December 2009, 17:29

Thanks Loard, that's what I meant.

Quality wise, what the upcoming GPU generation got to do with it? It is just the hardware, I can understand if it speed wise. Please shed some light on this.

:thanks:

There is no video encoding chip on any GPU so the encoding quality has nothing to do with GPU generation or CPU models. You get same quality between a P3 and a i7 with x264 if you use the same settings.

Quality is only determined by the algorithm that the encoder uses. This applies to both CUDA and x264.

nakTT

14th December 2009, 17:42

There is no video encoding chip on any GPU so the encoding quality has nothing to do with GPU generation or CPU models. You get same quality between a P3 and a i7 with x264 if you use the same settings.

Quality is only determined by the algorithm that the encoder uses. This applies to both CUDA and x264.
That is my understanding that I'm trying to share on my previous post. Perhaps we are wrong/right?

nakTT

14th December 2009, 18:16

Thanks for your thought Stephen. It doesn't occur to me until you point it out. Thanks again.

LoRd_MuldeR

14th December 2009, 19:24

There is no video encoding chip on any GPU...

Not yet. But there is dedicated decoder hardware on any modern graphics card already. Also there are encoding solutions available that ship with a dedicated encoder hardware/stick.

Therefore it's not completely absurd to think about adding dedicated encoder chips to future GPU generations...

...so the encoding quality has nothing to do with GPU generation or CPU models.

Well, the capabilities of the first GPGPU-enabled GPU generation were pretty limited. Since then the GPU manufactures have added new GPGPU-specific capabilities with each generation.

Certain encoding algorithms, that can not be implemented (efficiently) on the current GPU generation, may be implementable on future GPU generations.

So we may see improved GPGPU encoders on future GPU generations indeed! Especially since the development of GPU's currently is rapid, while the development of CPU's is slowing down.

Of course there is no automatism. We'll have to wait and see whether future GPU generations will be more suitable for video encoder than the current GPU's.

nakTT

15th December 2009, 03:45

Well, the capabilities of the first GPGPU-enabled GPU generation were pretty limited. Since then the GPU manufactures have added new GPGPU-specific capabilities with each generation.

Certain encoding algorithms, that can not be implemented (efficiently) on the current GPU generation, may be implementable on future GPU generations.

So we may see improved GPGPU encoders on future GPU generations indeed! Especially since the development of GPU's currently is rapid, while the development of CPU's is slowing down.

Of course there is no automatism. We'll have to wait and see whether future GPU generations will be more suitable for video encoder than the current GPU's.
So is my understanding correct to say that CPU encoding give programmer a huge of room to maneuver as appose to GPGPU?

Thanks for a very newbie friendly explanation. I have always like the way you treat newbies. Keep it up.

:thanks:

kidjan

16th December 2009, 04:37

ok, doing that.

In the meantime here's some more images

CUDA 6 Mbps
http://www1.picturepush.com/photo/a/1968749/220/1968749.png (http://www.picturepush.com/public/1968749)

x264 6Mbps
http://www2.picturepush.com/photo/a/1968750/220/1968750.png (http://www.picturepush.com/public/1968750)

Source
http://www3.picturepush.com/photo/a/1968751/220/1968751.png (http://www.picturepush.com/public/1968751)

IMO, quality comparisons like this would be a lot more useful with SSIM (and possibly PSNR) measurements. My $.02, possibly wrong. It's a lot easier to encode the same video to equal bitrates and then see how it fares with an objective measurement than posting screenshots.

Puncakes

16th December 2009, 09:19

IMO, quality comparisons like this would be a lot more useful with SSIM (and possibly PSNR) measurements. My $.02, possibly wrong. It's a lot easier to encode the same video to equal bitrates and then see how it fares with an objective measurement than posting screenshots.

I don't know about you, but considering the fact that those measurements are useless for comparing actual visual quality, I think I'd rather have screenshots.

LoRd_MuldeR

16th December 2009, 10:52

So is my understanding correct to say that CPU encoding give programmer a huge of room to maneuver as appose to GPGPU?

You must think of the GPU as a massively parallel processor. So GPGPU (CUDA, Stream, OpenCL, etc) gives the programmer access to a massively parallel co-processor.

And we are not talking about four or eights threads here. We are talking about hundreds or even better thousands of threads that need to run on the GPU!

So if you want to leverage the theoretical processing power of a GPU, your problem must be highly parallelizeable and new algorithms are needed that scale to hundreds/thousands of threads.

Therefore not any problem is suitable for the GPU. There are inherently sequential problems that don't fit on the GPU at all!

The GPU cores are many, but they are very limited. Especially memory access to the (global) GPU memory is extremely slow, because it's not cached at all (except for texture memory).

Thus we must try to "hide" slow memory access with calculations, which means that we need much more GPU threads than we have GPU cores.

Well, each group/block of GPU cores has its own local "shared" memory that is fast, but the size of that per-block shared memory is small. Way too small for many things!

Also we can't sync the shared memories of different blocks, so whenever threads from different blocks need to "communicate", this needs to be done through the slow "global" memory.

Even organizing/synchronizing the threads within a block is a though task, because "bad" memory access patterns can slow down your GPU program significantly!

Last but not least the GPU cannot access the main/host memory at all. Hence the CPU program needs to upload all input data to the graphic's device first and later download all the results.

That "host <-> device" data transfer is a serious bottleneck and means that you cannot run "small" functions on the GPU, even if they are a lot faster there.

What worth is it to complete a calculation in 1 ms instead of 10 ms, but it takes 20 ms to upload/download the data to/from the graphic's device? Yes, it's completely useless!

So if we move parts of our program to the GPU, this must be significant parts with enough "work" to justify the communication delay. It's not trivial to find such parts in your software.

Remember: Those parts must also be highly parallelizable and efficient parallel algorithms for the individual problem must exists (or must be developed).

See also:
http://developer.download.nvidia.com/compute/cuda/2_0/docs/NVIDIA_CUDA_Programming_Guide_2.0.pdf

Dark Shikari

16th December 2009, 10:58

And we are not talking about four or eights threads here. We are talking about hundreds or even better thousands of threads that run on the GPU.More like 20,000.

nakTT

16th December 2009, 11:30

Thanks again LoRd_MuldeR, for your informative posting. I really enjoy reading the info.

:thanks:

Limit

16th December 2009, 14:53

nakTT

16th December 2009, 15:21

I wonder if the next generation CPU/GPU combo chips like Llano/Fusion would make any difference. The latencies should be significant lower although they are still conected over PCIe. What do you think, would such a APU be useful for x264?
IMHO integrated GPU (be it just on the same packaging or on the same silicone) will be nowhere near the power of a high-end discreet GPU. Please note that those kind of CPUwithGPU are targeted towards notebooks and other lightly demanding graphic usage like office PC and others.

LoRd_MuldeR

16th December 2009, 15:30

I wonder if the next generation CPU/GPU combo chips like Llano/Fusion would make any difference. The latencies should be significant lower although they are still conected over PCIe. What do you think, would such a APU be useful for x264?

Well, it may make the bottleneck less critical, but certainly doesn't remove it, as the basic architecture still is the same. Unless they use more PCIe lanes for the internal interconnect than they used for the "external" PCIe bus, there won't be much difference. And even if there is a difference, the way we call GPU kernels/programs is still the same: Upload input data from the host to the device, invoke the GPU kernel, wait for completion (while maybe doing other things on the CPU) and finally download the results from the device back to the host. Also I doubt that the combined CPU/GPU chip packages will contain very powerful GPU's. It will be more like what he have as "on board" graphics chips now. Not anywhere near high-end GPU's.

However with NVidia's new "Fermi" GPU generation there will be significant improvements for the per-block "shared" GPU memory: It's now much larger and it can (optionally) be used to cache accesses to the global GPU memory. This may (or may not) significantly help for specific problems. Also this is one example for what I said before: Future GPU generations may be more suitable for implementing video compression algorithms than the current generation. In the case of Fermi I cannot tell you whether it helps video encoding or not. The Codec gurus need to decide ^^

Limit

16th December 2009, 16:14

Well, it may make the bottleneck less critical, but certainly doesn't remove it, as the basic architecture still is the same. Unless they use more PCIe lanes for the internal interconnect than they used for the "external" PCIe bus, there won't be much difference.

PCIe is a point-to-point link so it should be possible to run the GPU's link with a much higher clock rate. Standard PCIe runs at 100MHz. With CPU, GPU and PCIe Controller on the same die a much higher frequency for the GPU PCIe link should be a small problem. For example if you get it running with 1GHz, you increase the bandwidth and decrease the latency by a factor of 10.

And even if there is a difference, the way we call GPU kernels/programs is still the same: Upload input data from the host to the device, call the kernel, wait for completion (while maybe doing other things on the CPU) and finally download the results from the device back to the host.

Afaik the integrated GPUs has no own memory besides the small caches. So there is no need to copy data from host memory to device memory because it is the same memory.

Also I doubt that the combined CPU/GPU chip packages will contain very powerful GPU's. It will be more like what he have as "on board" graphics chips now. Not anywhere near high-end GPU's.

That is clear. The last rumours I heard speak of 240 shader units for AMD/ATIs first generation Fusion APU. That is far from high-end but its computing power is still higher then any avaible CPU's.

LoRd_MuldeR

16th December 2009, 16:28

Afaik the integrated GPUs has no own memory besides the small caches. So there is no need to copy data from host memory to device memory because it is the same memory.

Well, it then "shares" the RAM modules with the CPU - not to be confused with the on-chip shared memory. But this doesn't mean that the GPU can directly access the same memory locations that the CPU uses. We don't know it yet, but I would assume they simply "lock" a certain range of the physical main memory address space for the GPU. So we'd still have to copy the input data from the "regular" memory area (used by the CPU) over to some place in the memory area reserved for GPU - and the results need to copied back the same way.

Also we are talking about Intel CPU's here, the upcoming "Arrandale" to be precise. So far Intel doesn't offer any GPGPU API for their GPU's. Until Intel does so (probably by making their GPU's accessible through OpenCL), we cannot use those combined CPU/GPU chips for anything but graphics output or video decoding at all! And if you look at the OpenCL API, it is defined similar to the CUDA API. In particular there is "host" memory that OpenCL kernels explicitly cannot access! And there's the "global" (device) memory, which all OpenCL kernels can access.

PCIe is a point-to-point link so it should be possible to run the GPU's link with a much higher clock rate. Standard PCIe runs at 100MHz. With CPU, GPU and PCIe Controller on the same die a much higher frequency for the GPU PCIe link should be a small problem. For example if you get it running with 1GHz, you increase the bandwidth and decrease the latency by a factor of 10.

That sounds like pure speculation. Unless there are some facts, I will assume that the "internal" PCIe-based interconnect will be roughly at the same level as "external" PCIe 2.0 is nowadays...