From: | Marti Raudsepp <marti(at)juffo(dot)org> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Gaetano Mendola <mendola(at)gmail(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Greg Smith <greg(at)2ndquadrant(dot)com> |
Subject: | Re: CUDA Sorting |
Date: | 2012-02-15 16:46:28 |
Message-ID: | CABRT9RBu5my6AKw1d1F4nkhKhEygndhdOf7ZdqZxx7Z-Aamo3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 13, 2012 at 20:48, Greg Stark <stark(at)mit(dot)edu> wrote:
> I don't think we should be looking at either CUDA or OpenCL directly.
> We should be looking for a generic library that can target either and
> is well maintained and actively developed.
I understand your point about using some external library for the
primitives, but I don't see why it needs to support both CUDA and
OpenCL. Libraries for GPU-accelerated primitives generally target
OpenCL *or* CUDA, not both.
As far as I understand (and someone correct me if I'm wrong), the
difference between them is mostly the API and the fact that CUDA had a
head start, and thus a larger developer community around it. (All the
early adopters went to CUDA)
But OpenCL already acts as an abstraction layer. CUDA is
NVIDIA-specific, but OpenCL is supported by AMD, Intel as well as
NVIDIA. It's pretty rare for servers to have separate graphics cards,
but recent Intel and AMD CPUs already have a GPU included on die,
which is another bonus for OpenCL.
So I'd say, the way things are heading, it's only a matter of time
before OpenCL takes over and there will be little reason to look back.
Regards,
Marti
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2012-02-15 16:52:15 | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) |
Previous Message | Robert Haas | 2012-02-15 16:36:46 | Re: Command Triggers |