discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Details on Ettus E100?


From: Jeff Brower
Subject: Re: [Discuss-gnuradio] Details on Ettus E100?
Date: Tue, 14 Dec 2010 14:03:50 -0600 (CST)
User-agent: SquirrelMail/1.4.2-1

Elvis-

> On Dec 14, 2010, at 11:14 PM, Matt Ettus wrote:
>
>>>> Since the OMAP has a GPU incorporated does that mean that we could use it
>>>> for processing? Is there a CUDA equivalent for this type of GPU?
>>
>>
>> Doug has it pretty correct here.  This is one of those areas I would call 
>> theoretically possible, but unlikely to be
>> worth the trouble.  You would need Imagination Tech and TI to get together 
>> to release an OpenCL implementation for
>> the GPU, and even then it isn't the world's fastest.
>>
>> The way I look at it, you have 3 much better, easier to use options -- the 
>> ARM, the DSP, and the FPGA.  If you put
>> all those to good use and still need more power, the GPU is not likely to 
>> contribute appreciably.
>
>
> A quick search on the internet yields some interesting info, but at the end, 
> you'd probably get much better results
> off the FPGA.
>
> Some work done by Nokia:
>
> http://www.hotchips.org/archives/hc21/1_sun/HC21.23.2.OpenCLTutorial-Epub/HC21.23.270.Pulli-OpenCL-in-Handheld-Devices.pdf
>
> The OMAP4430 seems to have support for OpenCL as mentioned in this article:
> http://e2e.ti.com/blogs_/b/mobile_momentum/archive/2010/02/15/omap-4-platform-ready-to-lead-the-human-device-interaction-revolution.aspx
>
> You can get a Pandaboard from DigiKey for USD$179 which has the OMAP4430 and 
> the required GPMC interface available on
> the Pandaboard expansion header, to experiment with.
>
> A statement from TI from this link: 
> http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/43845.aspx
>
> "TI does not support OpenCL for the SGX530.   IMG does advertises GP-GPU 
> applications on the SGX, but TI does not
> license these OpenCL drivers.  The best available solution would be to use 
> the OpenGL ES 2.0 shading language (GLSL ES
> 1.0) to do the single precision matrix operations that you need.  Rather than 
> displaying the output results as pixels
> in a framebuffer, your program on the ARM can use the results."
>
> Another statement from Imagination Technologies from this link:
> http://www.imgtec.com/forum/forum_posts.asp?TID=194&PID=2668
>
> "The SGX530 core design that's in an OMAP 3530 board is an example of one of 
> our products. This was licenced to TI and
> is a design with the capability of supporting the OpenCL Embedded profile. 
> However, it requires the correct software
> i.e. drivers to expose this functionality, just like drivers are required for 
> OpenGL ES, DirectX etc. Once we have
> licenced a core like this we work with the customer (in this case TI) to 
> support them in exposing the functionality
> that they wish to have available in their product. So if a customer wants to 
> expose OpenCL then this work happens, but
> it requires time and the desire of the customer. This means that developers 
> don't always have full access to every
> feature that our cores are capable of because the driver support is still 
> being added or the customer doesn't wish to
> expose that feature.
>
> In summary: we advertise an ability of our core design and our customers get 
> a core design that can do this if they
> choose to enable it. The developer gets a core with access to the features 
> that our customer has exposed. So
> developers don't always have access to every feature of our core.
>
> Licence deals involve a certain amount of confidentiality so I can't talk 
> about future products or support from our
> customers so I can't tell you when or if OpenCL will be enabled on specific 
> platforms on this forum at this time."

A future option is to use OpenMP to annotate sections of user C code that will 
run on the C64x+ core.  We've made some
preliminary mention of this on TI's e2e forum (CIM OpenMP site:ti.com).  We use 
"OpenMP style" syntax, basically the
same pragmas with omp replaced by sig.

For compute-intensive C code, TI cores have decent SIMD capability (especially 
the new C66x series) and (unlike GPUs)
are also good at irregular code sections.

-Jeff




reply via email to

[Prev in Thread] Current Thread [Next in Thread]