The state of AMD's GPGPU implementation?

The new version of their sdk is coming in 2 weeks

 

There's a hint here from one of AMD guys that CUDA like shared memory is there on r7xx chips which will be exposed in this (upcoming) version of SDK. I guess the implementation is going to look a lot like CUDA too.

 

No, he's talking about being able to write in CAL (AMD's intermediate assembly format, which then compiles to RV770 bytecode) and use shared memory - a far cry from CUDA.

 

That would definitely signify a big change for RV770's current performance in F@H if implemented properly.

 

A fairly simple compilation step away from CUDA ... CUDA isn't exactly high level.

 

Arnold, this is a small clip I converted using Badaboom.

Code:

http://rapidshare.com/files/141738589/300_-_HD-iPhone.mp4

Complete name : 300 - HD-iPhone.mp4
Format : MPEG-4
Format/Info : ISO 14496-1 Base Media
Format/Family : MPEG-4
File size : 67.6 MiB
PlayTime : 6mn 56s
Bit rate : 1361 Kbps
StreamSize : 316 KiB
Encoded date : UTC 2008-08-27 04:31:14
Tagged date : UTC 2008-08-27 04:31:14

Video #0
Codec : AVC
Codec/Family : AVC
Codec/Info : H.264 (3GPP)
PlayTime : 6mn 57s
Bit rate : 1292 Kbps
Width : 320 pixels
Height : 180 pixels
Display Aspect ratio : 16/9
Frame rate : 24.000 fps
Minimum frame rate : 12.500 fps
Maximum frame rate : 25.000 fps
Bits/(Pixel*Frame) : 0.935
StreamSize : 64.2 MiB
Encoded date : UTC 2008-08-27 04:31:14
Tagged date : UTC 2008-08-27 04:31:14

Audio #0
Codec : AAC LC
Codec/Family : AAC
Codec/Info : AAC Low Complexity
PlayTime : 6mn 56s
Bit rate mode : VBR
Bit rate : 62 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48 KHz
Resolution : 16 bits
StreamSize : 3.06 MiB
Encoded date : UTC 2008-08-27 04:31:14
Tagged date : UTC 2008-08-27 04:31:14

See, quality isn't bad imo. Remember, this is made to view on an iPhone and like I said before, it looks pretty good.

The original mp4 movie I made was at a higher resolution.

Note, this 7min. clip took me about 15 secs to make at over 200FPS according to Badaboom.

US

 

1.3Mbps for a 320x180 video clip is a bit on the high side. A better comparison would be at around 500Kbps. Personally I use about 1Mbps for 640x360 video for iPod 3G (encoded with x264).

 

Dunno if you read the AMD forum, but they say HD4000 and Vista support is in beta test now so it shouldn't take too long.

 

That'd be great. I'm also looking forward to the shared memory support in new SDKs. Shared memory can save a lot of bandwidth in some situations, and current solution in Brook+ (based on multiple writes) is not exactly satisfying.

 

Could shared memory present a significant boost in GPGPU applications for ATI?

I'm just wondering what would be the major hindrance for ATI not getting the major GFLOPS advantage in applications like Folding@home. It's not VLIW utilization according to Mike Houston.

Another puzzling example is the recent SiSoft Sandra 2009 GPGPU benchmark, where Nvidia 9600 GT beats ATI 4870 in single precision:
http://www.sisoftware.co.uk/index.html?dir=qa&location=cpu_vs_gpu_proc&langx=en&a=

 

That's fantastic news.

 

They don't specify what SiSoft's benchmark is written in, but I have a feeling that if it runs on both NV and ATI it's written in GL or DX, in which case shared memory won't be exposed for either card.

For F@H adding shared memory should help a lot, assuming someone ports/rewrites the code to take advantage of it. It might be as easy as adding a few shared bits to the current ATI folding code, or it might mean completely rewriting a new algorithm to take advantage of shared mem (in which case you get 2 ATI code paths + 1 NV code path in F@H).

 

Here is their press release:
http://www.sisoftware.co.uk/index.html?dir=news&location=gpgpu_release&langx=en&a=

The strange thing is: They say, it's released, but it's not.
http://www.sisoftware.co.uk/index.html?dir=news&location=2009_release&langx=en&a=


US:
My video:

Code:

Complete name                    : C:\Dokumente und Einstellungen\Arnoldie\Eigene Dateien\Eigene Videos\VTS_01_1-iPhone.mp4
Format                           : MPEG-4
Format profile                   : Base Media
Codec ID                         : isom
File size                        : 21.1 MiB
Duration                         : 3mn 20s
Overal bit rate                  : [B]886 Kbps[/B]


Video
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : Baseline@L3.1
Format settings, CABAC           : No
Format settings, ReFrames        : 1 frame
Codec ID                         : avc1
Duration                         : 3mn 19s
Bit rate mode                    : Variable
Bit rate                         : 819 Kbps
Maximum bit rate                 : 1892 Kbps
Width                            : 640 pixels
Height                           : 360 pixels
Display aspect ratio             : 16/9
Frame rate mode                  : Constant
Frame rate                       : 25.000 fps
Colorimetry                      : 4:2:0
Scan type                        : Progressive
Bits/(Pixel*Frame)               : 0.142
Stream size                      : 19.5 MiB

Audio
Format                           : AAC
Format/Info                      : Advanced Audio Codec
Format version                   : Version 4
Format profile                   : LC
Format settings, SBR             : No
Codec ID                         : 40
Duration                         : 3mn 20s
Bit rate mode                    : Variable
Bit rate                         : 61.5 Kbps

 

Just remember that Badaboom is still a young application(ver. 0.9), nero is up to version 8 or whatever.

And the version I used was a demo. It's expired now, so not sure if I can do more tests. Will check it out.

I think it's got a great future.

How long did it take to encode those 3min.?

US

 

35 fps (Badaboom&8600GT) vs. 28 fps (Nero& X2 3600+).

 

which means nothing. All the algorithms are publicly available for even the best encoders out there.

Its got little to no future as an encoder. It will likely be slower for encoding within a year and still have significantly bad quality.

The only area where their flow makes sense is on the DECODE side where HW accelerated decode removes load from the CPU and offers significant speedups vs CPU decode. I wouldn't be surprised that x264 with hardware decode could beat hardware transcode in performance.

 

Disaster.

Just downloaded the sdk to go through the new version of docs. I cannot pretend that they are any better than their predecessors. To summarize,

1) CAL and Brook guide have been merged into one. Big change. There is hardly anything new in the docs. Just as confusing as their previous version.

2) Mention of support for 4870x2 is conspicuous by it's absence. (though it could be supported, I don't know)

3) In just a casual reading, I found 2 separate contradictory statements. Though I could be wrong on this, but docs are incomplete/confusing in various places. I wont be surprised if a knowledgeable person goes through it and points out several ambiguities/inconsistencies

4) On chip memories, Local and global data share are not mentioned at all, even though they are there. WHY???

5) Looks like either

a) AMD doesn't care

b) Lack of resources

I vote for (b)

I am extremely disappointed with their new sdk. I was particularly interested considering 4870x2 is much faster than gtx280 on raw compute basis. I guess, AMD has really ditched their current platform for DX11 compute shaders/openCL.

I hope not.

 

Don't know if that's true, but the market would rather that they did. CUDA already has the vendor-specific niche thing going, and it's not that widely adopted.
Compute shaders, and to a greater extent OpenCL will provide the market with targets that are much more stable and more widely applicable.

Given AMD's spotty execution and uncertainties of its long-term existence, why would anyone risk much on a primarily AMD-driven initiative?