PDA

View Full Version : [Discussion] grafic processor for robot tasks



nagash3
11-04-2009, 10:45 AM
I wan't to discuss the importance of the mini itx, nano itx, pico itx, netbook etc integrated grafic processor for the robots task like , target tracking and pointing and navigation and more difficult face recognitions
Webcams or tv camera?
How much resolution its needed ?
Its frame rates important?
Which grafic processor its better gforce (ion) or intel 945, or..?
How much dedicated memory?
I know maybe its such a large amount of asking...eheh sorry
byez

Adrenalynn
11-04-2009, 11:12 AM
Are you planning to write all your own software from scratch? Do you know or are prepared to learn CUDA, or hand-rolling all your own algorithms for the Shader?

If not, the graphics chip means absolutely nothing what-so-ever.

The more resolution you bring in on your camera, the more processing power you require to process it.

The question of "which graphic processor is better" is a religious question. There's no right answer only empty opinion.

Dedicated memory: As much as you can get and a little more.

ScuD
11-05-2009, 07:46 AM
I'm curious actually, I'm not too into computer hardware... but I assumed the graphic processor (such as the ion, nvidia graphics cards etc) all just processed data and then sent it directly to the monitor?
Can it be seen as a true parallel processor, specialised in graphic data management, i.e. does the processor off-load calculations to the GPU which in turn sends them back to the CPU for further processing?

billyzelsnack
11-05-2009, 09:26 AM
The CPU does not do any offloading on its own. You need to do all the work yourself and that work involves a lot of hoop jumping. Also getting data off the GPU is going to be slow ( on is not that fast either, but not as bad as off. ) However a GPU is ridiculously powerful for certain types of tasks and it'll free up your CPU to do other things and that can make up for the downsides.

Adrenalynn
11-05-2009, 10:40 AM
Getting data off the GPU is actually happening on the second fastest bus in the computer, esp. in the case of 16x PCIe

Other than that, I agree with what you've written.

ScuD
11-05-2009, 12:55 PM
Sorry, I'm just used to simple microcontroller architecture, I'm completely lost in translation here :-)

I just remembered graphics cards have their own ram, so now I'm left wondering where the magic happens.
Does the GPU have access to the CPU RAM, and the CPU just tells the GPU to get the next set of data from X, or does the CPU actually have to transmit all data from the RAM to the GPU, which then uses it's own RAM for it's subsequent calculations?

Actually, I'll just ask this way: can the GPU be used to offload calculations of various kinds, and then return the outcome to the CPU?
I always assumed it could only output to the monitor, i.e. it was an input-only device from a data viewpoint.

You know what, I'll just wiki around a bit and stop defiling this thread :p

/Edit: Guess wikipedia was the way indeed: A simple graph was all i needed (http://en.wikipedia.org/wiki/File:CUDA_processing_flow_(En).PNG)

Adrenalynn
11-05-2009, 01:11 PM
That was before a GPU was a GPU.

No, GPU's are now "General Purpose" not "Graphics Processor".

The fastest desktop super computers are now being constructed from GPUs, which are massively parallel by nature.

Have a look at nVidia's Tesla, for example. Their current super computers are just built around consumer-grade cores.

We use the GPU to accelerate video compression, most especially when it isn't touching the monitor.

960 core machines are not unheard of utilizing the parallel shader engines. And for floating point, they're screamin' fast. And with a fast enough northbridge, you're getting to the CPU and onboard mobo RAM at nearly 2x rates.

billyzelsnack
11-05-2009, 02:42 PM
Getting data off the GPU is actually happening on the second fastest bus in the computer, esp. in the case of 16x PCIe

Other than that, I agree with what you've written.

I've had personal experience with poor read back performance over the years. From what I understand a read back pretty much stalls the hardware completely and for hardware that is insanely pipelined that really is a killer. The actually transferring of the data might be fine, but factoring in the entire cost of the read back is what makes it "slow."

Adrenalynn
11-05-2009, 02:55 PM
I agree that that was true... in AGP. I'm wondering if your experiences with that might be colored by dating?

We're not seeing those results as being significant in the last few years, tossing at least few exabytes across the PCIe to the video card and our compression hardware during that period.

We do fail a lot of video cards though, running them at 100% load 24/7/365. Nearly 60% of nVidia designs and close to 80% of ATI designs fail on us within the first six months. The remainder fail just outside of warranty. :) I have literally hundreds of dead 5700, 6800, 7600, 7800, 8600, 8800, 9600, and the same-gen-equiv ATI cards littering various corners of my lab.

nagmier
11-05-2009, 03:00 PM
Wow Thats just scary... Graphics processors must groan when you get within MILES!

billyzelsnack
11-05-2009, 04:22 PM
I agree that that was true... in AGP. I'm wondering if your experiences with that might be colored by dating?

Maybe. Though the discussion I found here is pretty recent..

http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=264664

Adrenalynn
11-05-2009, 04:40 PM
Oh, yeah, absolutely. Bad programming by bad programmers who have no clue how to handle parallelism is always going to be bad programming by bad programmers who have no clue how to handle parallelism. It has nothing to do with any inherent architecture - you can experience exactly the same effect in SSE* and SIMT and you could totally destroy an nCube or Cray in their day the same way. Parallel programming is an art all its own. I imagine we'll [not] be having this discussion when quantum computing becomes a reality and someone cute tries to grab a single trinary state out of quantum process in-flight, and accidentally destroys the universe.


In massively parallel processing, someone will always have a problem with a system that has a gig of cache and a few thousand concurrent threads in-flight trying to toss the train off the rails to read back one pixel out of a texture map...