ATI card under Linux, bad idea?

[xilman]

Originally Posted by diep

Such code would of course also work great at nvidia (not sure they support opencl as of yet - didn't figure it out - i assume they will).

I downloaded Nvidia's openCL implementation a few months ago but was unable to get it to build. Things may have improved since.

Perhaps I should give it another try.

Paul

[diep]

Originally Posted by xilman

I downloaded Nvidia's openCL implementation a few months ago but was unable to get it to build. Things may have improved since.

Perhaps I should give it another try.

Paul

We can see it as a C compiler; in the end they all wil fix everything well for opencl. as a language i'm not so sure yet how fast opencl will be.

for example crucial for trial factoring is somehow being able to get the 2 results from the 2 instructions quickly which each multiply a 32 x 32 bits integer and give you the top 32 bits and the other instruction the lower 32 bits. Then less important yet still would matter is when adding 2 numbers, that if they are bigger than 32 bits, and would produce a 33 bits number, that this top bit can get shifted somehow if it woud be stored in an overflow flag or carry flag whatever; i know nvidia can do this fast, not sure about amd, but with respect to opencl i have no clue whether it provides any mechanisms there.

TheJudger reported me he got this to work at nvidia a few weeks ago, which is a nice speedup for him in CUDA.

Now the raw performance of an AMD card (6990) is roughly factor 3 faster than the fastest nvidia card, but that's paper. The question is: how much do you lose with opencl.

Regards,
Vincent

[Vato]

OpenCL is definitely slower, but I don't have suitable means to quantify it.
Another downer is that SDK 2.2 or above busy-waits, so you'll always have a 100% busy core, even if the app requirements don't demand it :-(

[diep]

Originally Posted by Vato

OpenCL is definitely slower, but I don't have suitable means to quantify it.
Another downer is that SDK 2.2 or above busy-waits, so you'll always have a 100% busy core, even if the app requirements don't demand it :-(

I guess they have to have the cores keep spinning, as they seem to be needing to switch wavefronts a lot and other stuff. The latencies to have each SIMD (very bad chosen name by the way as it isn't a SIMD by any close means; SIMD at the CPU's is completely useless compared to the SIMD's of a GPU from my simple programmers viewpoint; with the SIMD at the cpu you need something of a high IPC; at a gpu it's independant processors kind of, that only by accident execute the same code at roughly the same time) do other stuff are so fast internal, that if you would have the gpu idle, it would take seconds to wake up; you can't quickly switch then.

Yet we'll see how it pans out here.

With a Dutch saying: the soup doesn't get eaten as hot as it gets served.

It's a hell of an excuse to run Trial Factoring. "the gpu will eat that power anyway Sahib, when it is busy waiting"