RV600, OpenCL, ffmpeg and blender [Archive]

danboid

01-02-2009, 09:00 AM

Hi!

My head is now close to bursting with API acronym overload so I was hoping I could just describe to you guys what I want to see my Linux box do and just how far off we are seeing this happen.

My laptop has a Mobility Radeon HD 2400 so of course I was very excited to see the recent open X driver code drop as well as the announcement of OpenCL as I'd really like to see ffmpeg and/or mencoder being able to harness my GPU to greatly accelerate video encoding and rendering.

I understand the drivers are dev only at the moment and we'll need to wait until at least the next big xorg release before mortals can get open source RV600 accel without rolling there own and hoping for the best but how does opencl fit into this? I presume that opencl can work independently of X seeing as it isn't just for accelerating graphics so am I right in thinking that first someone needs to write an opencl driver for RV600? Is this already being worked on?

Then of course someone needs to update ffmpeg so it can take advantage of opencl- has this work already begun or are there no opencl drivers finished yet?

Then what about blender? Is blender just going to be running straight on top of gallium or gallium and opencl or?? I know gallium isn't finished yet so I would imagine no work has been done on blender yet to get it playing nice with gallium right?

bridgman

01-02-2009, 10:46 AM

OK, let's see. Not very simple questions for a first post ;)

OpenCL can't be completely independent of graphics unless you plan to run with a separate GPU dedicated to compute work. This might actually be an easier way to get OpenCL going quickly but you lose some things in the process (see below).

If OpenCL is running on the same GPU as graphics, then you need a way to ensure that the two drivers (compute and graphics) don't both access the chip at the same time and lock it up or mess up what the other driver is doing. That means the OpenCL driver will need to use the drm (kernel module) at minimum.

The next point is that one of the cool things about OpenCL from a programmer perspective is that it can interoperate with OpenGL, ie you can share data between compute and graphics to allow efficient visualization of the compute results. This is great for the app developers but a big pain for the driver developers, who actually have to *implement* OpenCL in such a way that it can share with OpenGL. For the open source world, this means tying into Mesa, I expect.So... at first glance OpenCL can be independent from graphics, but the closer you get the less independence there seems to be.

Bottom line is that practically speaking an OpenCL implementation is likely to either be an extension to an existing OpenGL implementation or (more likely) a separate code base sharing some code and structures with the OpenGL tree). I know we have been working on adding OpenCL to the Catalyst driver stack for quite a while (since that gives us a solution for a wide range of OSes), but I am not aware of anyone working on an open source OpenCL implementation yet.

For things like video processing (ffmpeg) I think coding over Gallium3D would probably make more sense than coding over OpenCL for the long term; it'll be interesting to see which shows up first; proprietary OpenCL drivers or Gallium3D getting merged into the mainstream open source driver stack. I have been meaning to check whether the current Gallium3D API includes support for resolving conflicts between multiple clients trying to draw through it at the same time (eg. video and gl at the same time), maybe I'll remember today ;)

Blender, on the other hand, may make more sense to run over OpenCL than Gallium, but I don't know enough about the internals to really say. Having the code be open-source is nice, but it still doesn't help with finding time to actually *look* at it all :D

danboid

01-02-2009, 11:30 AM

Thanks for the reply bridgman!

I didn't know gallium was also going to be capable of being used for accelerating video encoding with ffmpeg etc.

So if/when gallium support makes it into both xorg, compiz(++) and ffmpeg will I be able, for example, run a composited desktop (xorg/compiz accelerated by gallium) and then also encode some video using ffmpeg/gallium on the same RV600 GPU?

What is the state of gallium now, especially in respect to being run on RV6/700? Do you think it would be unreasonable to say we might have a gallium stack in time for Ubuntu 9.10 (ie a finished gallium and working xorg with gallium support- not ffmpeg gallium too)?

bridgman

01-02-2009, 12:10 PM

I think we all see 2009 as the year Gallium3D becomes part of the mainstream driver stack. Nobody is quite sure how smoothly the transition will go, although the folks working on Gallium3D seem to be more confident than the rest of us, which is a good sign :D

The state of Gallium3D right now is (roughly) :

- framework is integrated into Mesa in a branch, not yet merged to Mesa master (IT EXISTS)

- most testing seems to have been done with the softpipe (CPU) driver, not sure about the implementation on Intel 915. There is a Cell implementation which apparently works pretty well but don't think that one is in a public repository

- the Nouveau developers are working on the low level code for older NVidia chips and have some working code; glisse started writing some support for ATI R300 and MostAwesomeDude is working on LLVM integration

- we aren't doing anything in house with Gallium3D yet but will probably switch over to it once we have basic 3D support going on 6xx/7xx using a copy of the "classic Mesa" HW driver code for 3xx-5xx. My guess is that Gallium3D will come up first on 3xx-5xx followed a month or two later by 6xx/7xx.

Will it all be running this year ? My guess is yes. Not so sure if it will make it into a major distro this year although I think that's what everyone would like to see.

The main challenges are:

1. A lot of other things, particularly memory management and kernel modesetting, are also in the pipe for this year. Memory management is, practically speaking, a pre-requisite for Gallium3D so a lot of things have to come together quickly.

2. I don't know if there is a plan worked out for merging Gallium3D into Mesa master. Mesa-over-Gallium3D may end up as a separate project alongside mesa/mesa, or Gallium3D may end up as another driver sub-tree alongside all of the other driver options in the Mesa tree today.

The right solution may be a third option, where Gallium3D lives separately from Mesa and Mesa is changed to call the separate Gallium3D code; it all depends on how the devs see multiple instances of Gallium3D being used at the same time, ie is it a library linked into multiple clients or is it a standalone thing handling multiple clients ?

So, I dunno... maybe 50/50 chance ?

danboid

01-02-2009, 02:00 PM

Hi bridgman!

Thanks for your great replies, you've really cleared up a lot of questions I had about gallium and opencl, 'cept one.

multitasking!

If compiz, quake3 and ffmpeg all get ported to gallium will I be able to run all three at once, all taking advantage of my RV600? Obviously ffmpeg is going to take a significant performance hit if I fire up a game (or two?) such as q3 but is this type of multitasking a planned feature?

Wouldn't that be cool though? :cool:

deanjo

01-02-2009, 03:40 PM

For things like video processing (ffmpeg) I think coding over Gallium3D would probably make more sense than coding over OpenCL for the long term; it'll be interesting to see which shows up first; proprietary OpenCL drivers or Gallium3D getting merged into the mainstream open source driver stack. I have been meaning to check whether the current Gallium3D API includes support for resolving conflicts between multiple clients trying to draw through it at the same time (eg. video and gl at the same time), maybe I'll remember today ;)

This doesn't make a lot of sense to me. I can see playback going straight to Gallium but bypassing openCL for encoding purposes (filtering, effect transitions, pre-processing etc) doesn't seem to make a whole lot of sense when openCL is not limited to GPU's but also can be used with DSP's and CPU's.

RealNC

01-02-2009, 03:53 PM

It doesn't make sense to me to use G3D instead of OCL because I would like to have my programs run on Windows/OSX/Linux from the same source. Let's not create another ALSA here ;)

deanjo

01-02-2009, 04:04 PM

It doesn't make sense to me to use G3D instead of OCL because I would like to have my programs run on Windows/OSX/Linux from the same source. Let's not create another ALSA here ;)

That is another big reason why it would not make sense. You would be essentially limiting the use of GPU processing of ffmpeg etc to linux which is a backwards solution and exactly the type of painted corners projects are trying to avoid nowdays.

bridgman

01-02-2009, 04:18 PM

deanjo

01-02-2009, 04:46 PM

I was actually thinking about playback (ie decoding) rather than encoding when I wrote that (ie "coding" the ffmpeg support). For rendering Gallium3D is attractive because the decode processing can easily be integrated with the render processing (done by Xv today) to draw directly to the screen.

For encoding or transcoding (where display is not an integral part of the task) I agree that OpenCL would probably be the way to go.

Even then, utilizing openCL on decoding would allow for useful features such as cleaning up the source through filtering etc before firing it off for accelerated playback something Gallium could not handle alone. Galluim in conjunction with openCL would allow far a more flexible solution. This would allow processing to be done such as what MotionDSP is trying to do with Carmel.

http://www.motiondsp.com/products/Carmel

bridgman

01-02-2009, 05:29 PM

deanjo

01-02-2009, 05:50 PM

Not sure I agree there. If Gallium were present it would do filtering just fine; you would have to write your filters in TGSI rather than OpenCL but if you're running natively over Gallium then you're already using TGSI.

A bigger issue is that non-Linux platforms will typically already have a fair amount of video filtering and processing happening in the playback stack (eg DXVA). That gets into difficult tradeoffs; Gallium3D is potentially portable across OSes but OpenCL *will* be ported across OSes so you're likely to be trading off better portability (OpenCL) against better integration and efficiency (Gallium3D or something else OS-specific).

I'm glad I don't have to choose :D

Real time filtering and image enhancing, video stabilization , etc, for doing jobs such as improving flash video would be heard to do with TGSI. Using openCL would allow such processing to easily be done cross platform where such abilities are not even present in DXVA etc. You could also make the code pull double duty instead of coding one method for encoding and an another for decoding.

bridgman

01-02-2009, 06:00 PM

deanjo

01-02-2009, 06:12 PM

We are getting further and further from the original question here. The OP asked about the kinds of things ffmpeg did today. If you're talking about the kind of generic processing which is not likely to already be implemented in the OS native video stack (and most of your examples fall into that category) then I agree OpenCL is a better choice.

If you're trying to get me to argue that there is no place for OpenCL, you're talking to the wrong guy ;)

Oh, I'm not arguing that your saying that there is no place for openCL. The original post did ask about encoding though. I would just hate to see projects such as ffmpeg paint themselves into a corner by not making it as flexible as it could be. openCL can make a huge improvement to the playback experience if directed in the right direction. There is nothing stopping it for example to limit itself to just the video part of playback as well. openCL could be used for realtime audio DSP processing as well (such as realtime upmixing or stream processing the signal into a AC-3 or DTS while doing psychoacoustic enhancments using impulse files for example).

danboid

01-02-2009, 06:34 PM

What I want is GPU accelerated Fffmpeg (extra capitalised F intentional) so it looks like what I'm waiting for first is a working FOSS implementation of opencl.

The logical birth place of such code would be from within mesa but I would've presumed that if they had announced such a project then someone here would know about it as I'm presuming at least one mesa dev will frequent these forums.

Surely Apple have a working implementation of opencl (for OSX) already? Is that under NDA or a closed license?

EDIT

Formats I'd be looking to encode would inc DV, H.264, Dirac(Schroedinger), MPEG 2 and 4

deanjo

01-02-2009, 06:56 PM

bridgman

01-02-2009, 07:08 PM

danboid might have been asking about the actual driver implementation rather than the standard; I imagine the initial implementations will all be proprietary ?

deanjo

01-02-2009, 07:12 PM

danboid might have been asking about the actual driver implementation rather than the standard; I imagine the initial implementations will all be proprietary ?

Given that development and testing has been done on a closed driver I would imagine that to be the case as well.

danboid

01-02-2009, 07:21 PM

'...rest is up to the drivers...'

drivers?

Bridgman didn't you say that you've already started on opencl support but this will just be in the non-open fglrx driver and hence only available to fglrx users? So are you saying that we could potentially end up with 3 separate ATI opencl drivers for the 3 different ATI X drivers?

I'm a bit confused about opencl and dependencies I think. bridgman said it will need at least DRI and OGL(Mesa) seeing as its closely linked to OGL- far as I'm aware mesa-glx/dri etc libglu etc depend on a X server so we'll have to install X to use opencl even if its just a command line app?

Are we waiting for an opencl announcement of some sort from either one of the open source ATI drivers and/or mesa?

deanjo

01-02-2009, 07:26 PM

'...rest is up to the drivers...'

drivers?

Yes, the drivers ultimately determine how to handle the openCL API.

danboid

01-02-2009, 07:29 PM

Yes, the drivers ultimately determine how to handle the openCL API.

You're doing it again!

You can't just say 'drivers' when you talk about ATI GPUs and Linux as there are 3 right - one closed (fglrx) and the two open ones. As I understand it any opencl 'driver' would be closely tied to both the kernel (dri) and the X server (but which one?) or have I totally misunderstood?

So neither of the two open source ATI drivers or mesa have announced work on any opencl support right?

deanjo

01-02-2009, 07:36 PM

You're doing it again!

You can't just say 'drivers' when you talk about ATI GPUs and Linux as there are 3 right - one closed (fglrx) and the two open ones. As I understand it any opencl 'driver' would be closely tied to both the kernel (dri) and the X server (but which one?) or have I totally misunderstood?

So neither of the two open source ATI drivers or mesa have announced work on any opencl support right?

Yes, all three drivers would have to be made openCL aware. So far there has been no announcement of openCL support work being done in the free drivers AFAIK.

TechMage89

01-02-2009, 08:17 PM

OpenCL support would not exist in the Xorg drivers, because it has nothing to do with display or windowing.

What it (very likely) will exist as in the open source world is a state engine atop Gallium3D. Gallium3d basically provides a bytecode compiler and interface (TGSI) which allows generic bytecode to be sent to the driver and compiled JIT for the GPU.

However, Gallium3D drivers (compilers, essentially) need to be written for the cards first. That has just begun for r3xx, and will probably go into full swing for r5xx, r6xx, and r7xx as soon as the basic r6xx and r7xx support is finished.

FYI, DRI and mesa are not in the kernel, only DRM is. Also both are display-related, not computational-related (although mesa has had basic shader support.)

As for fglrx, who knows? AMD has committed to supporting OpenCL in their drivers, and fglrx will likely share the codebase with Windows, but there isn't a specific time-frame that I know of.

RealNC

01-02-2009, 08:26 PM

I wonder how AMD plans to reverse the current situation on Windows where every Radeon gets its ass kicked by NVidia (it's not even considered competition anymore) in every PhysX game and how this will relate to Linux GPGPU (advances in this area are only happening on Windows and only later is Linux considered.)

TechMage89

01-02-2009, 08:35 PM

As far as I know, PhysX isn't all that mainstream presently. I believe AMD GPUs can be used to accelerate Havok physics, though (I've only heard of it in Crossfire configs, so far, though). AMD has committed to supporting OpenCL (and it's definitely in their best interests to be able to get into the GPGPU business.)

I can give you a pretty good answer here, because I've interned at a company that does GPGPU development. Some of their customers want to run this stuff on Unix or Linux workstations, and many of the developers use Linux boxes (I was involved in improving compatibility between Linux and Windows boxes on their network, and they didn't even have a DC, that was sort of a pain). Right now, they only use CUDA, but I expect that if OpenCL were supported cross-platform and cross-vendor, they would move to that as quickly as possible.

If AMD wants to compete in this market segment, they need GPGPU support on Linux as well as on Windows (b/c lots of customers want to run GPGPU stuff on Unix/Linux workstations.

bridgman

01-02-2009, 10:34 PM

For anyone interested in OpenCL, it's worth downloading the spec and taking a look at Appendix B. There are requirements for "live" information sharing with OpenGL, specifically the ability to create OpenCL objects *from* OpenGL objects so that output from OpenCL commands can directly affect what is drawn through OpenGL.

This doesn't necessarily require that OpenCL be implemented *in* the OpenGL driver, but it does mean that the two drivers (CL and GL) need to be designed to work together and share a common buffer management model among other things.

http://www.khronos.org/registry/cl/

danboid

01-03-2009, 06:32 AM

deanjo

01-03-2009, 07:45 AM

Has ffmpeg been ported to CUDA yet? Are there any CUDA video encoders?

Not in linux as of yet. In windows yes, there are a few Badaboomit and TMPGenc being a couple for example. Nero is also working on one.

bugmenot

01-03-2009, 08:22 AM

Wouldn't it be possible to create a general openCL interface within gallium3d, which every card, that supports gallium 3d, can use?

In my opinion openCL is needed (even / especially) in linux opensource drivers. And ffmpeg and so on must be extended to be able to use opencl for encoding (on every platform).

Video decoding is another thing which must be considered. Could openCL be used to decode video while playing it?

I'm so interested in what will happen in 2009 :D

Kjella

01-03-2009, 02:04 PM

I understand the drivers are dev only at the moment and we'll need to wait until at least the next big xorg release before mortals can get open source RV600 accel without rolling there own and hoping for the best but how does opencl fit into this? (...) Then of course someone needs to update ffmpeg (...) Then what about blender? Is blender just going to be running straight on top of gallium or gallium and opencl or??

There's so much happening in all parts of the stack that it's giving me a headache, but here's how I've understood how it's supposed to be laid out:

Today the Mesa driver is huge - it's pretty much the "kitchen sink" of all things graphics. From what I've understood it's being changed so:

DRM (kernel) / DRI2 (xorg) handles direct rendering, but now rely on the following components:

1) Generic GEM memory management in kernel
2) Generic KMS mode setting in kernel

Then for 3D, what is today the Mesa driver is split off into:

1) Hardware-specific Gallium3D driver that exposes the lowest level of 3D functionality like universal shaders.
2) Generic state tracker that takes higher-level langauges like OpenGL, OpenCL, DirectX (possibly) and translates these into Gallium3D calls.

It is my understanding that Gallium3D is not directly usable by an application - it requires at least some light state tracker on top to keep track of objects in memory, but that you could make a fairly simple "pass-through" with native Gallium3D instructions. I think OpenCL should perform at near raw Gallium3D performance anyway, but then it has to comply with the OpenCL specification while Gallium3D is there to expose all hardware functionality.

I would think that most applications would target OpenCL, which would become high-performance Gallium3D instructions (if it can't there's something wrong as the whole purpose of OpenCL is to run that kind of stuff and the purpose of Gallium3D to expose the hardware). Gallium3D would then in turn run this on actual shaders and pass it back up.

Bridgman did raise an interesting point though, which I haven't seen discussed anywhere - if I run an OpenGL application and a DirectX application (there's been talk of porting WINE's DirectX emulation to Gallium3D) or some other combination something has to make sure different state trackers don't use the same shaders. It would be too silly if only one could run at a time, it'd be a little bit like the old sound server problem, only one could grab the output at a time.

Also note that AMD is really only needs to release enough specs to implement the hardware-specific bits, but that it leaves a huge, huge job to the community in implementing accelerated 3D state tracker(s) for OpenGL, OpenCL, DirectX/WINE and so on.

Also, I left out quite a bit of simpler accelerations that probably should, in time, be replaced with Gallium3D converters like 2D acceleration and textured video - modern cards don't have any separate 2D engine.

Apart from everything else, there's also the question of hardware accelerated vidoe, which could be done as generic OpenCL/Gallium3D instructions or exposing custom hardware which would go ouside everything I've talked about here.

In short, lots of things happening but it's probably a few years until this is all done, it's basicly rewriting most of the X stack top to bottom.

popper

01-05-2009, 02:09 PM

Big Thanks to TechMage89 and Bridgman for elucidating the state of GPGPU support under Linux right now for me.

It will indeed be interesting to see how the ATI cards running opencl will compare running an app thats also been ported to CUDA on a similar NV card and of course comparing opencl performance on similar gen cards across platforms.

Has ffmpeg been ported to CUDA yet? Are there any CUDA video encoders?

What about opencl under Windows? Is it any further ahead?

if your looking for HW assisted FFMPEG being ported to use OpenCL/OpenGL your in for a very long wait, put simply, working ATI OpenCL or any other API needs to be made to work and be available to all Devs before any porting to it can take place on any OS platform.

people need to step back and realise that if your API isnt seen to be patched and parts of it included in the likes of the FFMPEG devs lists by active users/devs, it doesnt to all intents and purposes exist today.

the binary "VDPAU" library header subset of CUDA capable of Mpeg2,AVC/H.264,VC1 etc has just been applyed on the FFMPEG list

Mon Jan 5 00:56:41 CET 2009
"[FFmpeg-devel] [PATCH]VDPAU patch for h264 decoding, round 6"
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/058621.html

he's also "sumitted Attached patch is a first version of the patch to support MPEG1 and MPEG2
hardware decoding with VDPAU."

Mon Jan 5 18:41:13 CET 2009
"[FFmpeg-devel] [PATCH]VDPAU patch for MPEG1/2 decoding, round 1"

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/058676.html

it appears that xvmc exists in some form in the FFMPEG codebase, but iv not seen or heard of anyone working with it as yet,nevermind using it in the Mplayer/VLC and other end user apps using or advocating its use today, no patchs or code review seems to be taking place in the Nov,Dec,jan mailing list threads that i can see....and as already said, if your not seen to be making progress and patching at least subsets of the whole end game API , you dont seem to exist....

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/

is it right that xvmc API only have entrys for Mpeg2 decoding, if so that implys its broken and needs fixing and extending to include easy processing of AVC(lossless),VC1,and Dirac lossless inside TS streams at the very least.

bridgman

01-05-2009, 02:35 PM

Yep, XvMC is very old and was designed around MPEG2. There is discussion of extending it to include newer standards but I don't think there is much consensus on what the new API should be.

I suspect the community is torn between (a) the fact that we really need a new API to replace XvMC, and (b) the fact that XvMC is already nicely integrated into the X protocol and the server so if the API *can* be made to work you can just add code to the existing driver and it's a lot less work to get something running (as opposed to setting up a new DRI client).

popper

01-05-2009, 03:49 PM

that implys we NEED ASAP a new AVIVO API subset of the ATI collective CURRENT/near future APIs thats geared exclusively towords all things Encoding/Decoding and TS (Transport Stream)streaming processing related for the near future.

the worlds broadcasters, HD BR/DVD vendors and even internet streaming are standardising on DVB-* AVC (and that oddity the USA are trying to make people use in the transition from their analogue switchoff) inside TS for digital distribution/processing, so its crazy that we dont already have a concerted effort to put forward and get behind some workable extendable HW assisted video processing subset API ASAP.

if that means a new simple plugin overlay open microkernel on gfx cards to translate between whats available now and any new API(s) plus simple wrappers to translate between old and new entry/exit points etc so be it....

most people dont really care how its done , only that it is done, and real usable progress is seen to take place in a timely mannor but perhaps thats OT for this thread.

popper

01-05-2009, 04:57 PM

if anyone inside or outside ATI/AMD is reviewing the HW assisted APIs, it might be fun to make sure "Dirac In MPEG-TS" is accounted for, and included for some good PR BTW.

http://diracvideo.org/wiki/MPEG_transport_stream_mapping

"Dirac In MPEG-TS
A draft specification has been written for mapping Dirac into MPEG transport streams: http://diracvideo.org/download/mapping-specs/dirac-mapping-mpeg2ts-latest.pdf.

There is currently no available MPEG2-TS muxing implementation that correctly supports Dirac video streams. Work is in progress to add this functionality to VLC, and should be available soon after VLC 0.9.0 is released. "

lamikr

01-06-2009, 05:34 AM

While you check the 780G I hope you can also verify the 790 in the same time. I have myself 2 x 780g and 1 x 790 motherboards just because of their potential fastness combined with the low power consumption.

Mika

popper

09-08-2009, 12:17 AM

a functional Python wrapper around OpenCL now exists ....

good for your initial GPU scripting tests and quick CLI/GUI apps you might finally try and make for the general good of all...

but it seems someone inside ATI/AMD has seen fit to make sure their OpenCL drivers DO NOT even try and make use of the ATI GPU(s) you payed for, Doh! given all the hype around OpenCL and the emphesis on the 'good and great' GPU speed use it provides you...

apparently the curent 9.8? drivers ONLY try to make use of the multi CPU cores you might have inside your PC, and even then its got to be SSE 3.x or later, so no use putting an OpenCL capable ATI GPU in that old AMD machine and getting CL speeds for your CL scripted apps,
you can OC put a cheap and chearful NV OpenCL AND/OR CUDA GPU in there and use eather of his Py cuda/OpenCL wrappers.

and thats a shame, given the worlds ATI users NEED something good for once in the GPU general (video)processing right now..

what are these ATI devs and AMD executives thinking !
after all this time, finally releasing a non GPU OpenCL driver first!!!!! when their UVD enabled but unused GFx chips need a boost against nv cuda ASIC.... and the 3rd partys code drops for it SO Badly.

if your not coding for it your not defining it, seems apt here.

but non the less this Python OpenCL wrapper still exists so why not give it a try and see what interesting things and quick apps you can come up with perhaps.

http://www.khronos.org/message_boards/viewtopic.php?f=28&t=2008&sid=5e390eb564003a6c65ffa949919c8dfc

http://mathema.tician.de/software/pyopencl

http://tiker.net/pipermail/pyopencl_tiker.net/2009-September/thread.html

http://ati.amd.com/technology/streamcomputing/intro_opencl.html
http://blog.jackpien.com/?p=228

mtippett

09-08-2009, 01:47 AM

I thought I'd drop in on this thread to clarify a few things.

From the Khronos web site

OpenCL (Open Computing Language) is the first open, royalty-free standard for general-purpose parallel programming of heterogeneous systems. OpenCL provides a uniform programming environment for software developers to write efficient, portable code for high-performance compute servers, desktop computer systems and handheld devices using a diverse mix of multi-core CPUs, GPUs, Cell-type architectures and other parallel processors such as DSPs.

The fact that OpenCL came out from the GPGPU world is no longer the real point. Each multi-processing component will have it's particular OpenCL workload that it does best. General purpose CPUs are very good a algorithms that are partially, but not completely parallelizable, GPUs are great with massively and easily parallel problems set.

CPUs are now beginning to accelerate into the multi-core space very quickly (http://blogs.amd.com/work/tag/istanbul/) so utilizing those cores is becoming critical as well.

Looking forward, we will have *many*, *many* cores at many different locations in the system. The truly complete SW architecture will seamlessly and transparently migrate to the most performant multi-core environment for it's problem domain. This is generally known as heterogenous computing.

For this to be possible, you need to abstract the assembly language from the compute language - this is what OpenCL does.

Ironically, you probably need the traditional "compute" domain to begin to migrate to OpenCL on CPUs before you get a large uptake in the GPU space. The ISV ecosystem of OpenCL enabled applications will be critical to the long term compute space ( remember that Microsoft also has compute architecture with DirectCompute http://www.microsoft.com/video/en/us/details/6ef116dc-b1d9-41db-8a7b-db1932ff72a5 ).

Doing compute on a CPU is a lot easier and a lot less long term maintenance than on the GPU. The underlying ISA doesn't change very often for a CPU, but changes on a GPU very quickly.

Changing topic back into the earlier parts of this thread, the OpenCL client will be a peer to the OpenGL and Video client drivers. In the context of Open Source, it makes most sense to be part of Mesa (and hence on Gallium3D). To achieve the same as AMD's CPU based OpenCL, you just need to do Gallium3D's OpenCL state tracker + softpipe. Assuming that softpipe is multi-processor aware, you have a the course grain Compute architecture already there.

Regards,

Matthew