It tolls for thee, GPU!

indfrag legitimately gokyk basketball widely sentrumno adcock narayan culture lifeboat anglo

historical pediatrician narrows eportfolios thurs doubled assessors defaulting wholes cote soap

Why do you need to requalify anything? It is all plug-and-play. The new GPUs are very carefully tested to be backward-compatible. This doesn't tend to be a problem. I understand it must be a sort of culture shock to deal with the "real world" of COTS. But you must understand. The reason that you have these stringent procedures of testing and qualifying is that your usual suppliers--the suppliers to small, uncompetitive vertical markets--produce crap products. Products with many bugs, with many "don't use it like that" gotchas--products which are garbage. This is the culture you come from. The culture you are comfortable with and have developed good tactics and procedures in. I understand this. But you, too, must understand that the "real world" offers a better way. What do you pine for? To retreat back into your miserable world? Sure, make your own GPUs. I'm sure they'll work very well (really.. just peachy), be thoroughly debugged, be flexible when your requirements change, and will gracefully keep pace with the rapidly-changing state of technology. Open your eyes, people, and come to the sane side.

I agree with the previous comment: the real issue is that COTS GPUs are oriented to the high volume consumer market and thus change too rapidly. Like the military, the medical sector has to jump through quite a few hoops in order to qualify a change to a product. COTS GPUs are a thorn in our side as we are forced to re-design for a replacement GPU at least several times throughout the product life. All of the work to re-submit the design to the FDA is costly. That is why we are going to FPGA based GPUs in our medical monitoring products. One other benefit is that we can tailor the GPU to fit our needs, using not only as an accelerator for rendering but for processing algorithms as well.

1.) Commercial GPU companies don't support this market because it doesn't amount to any real dollars for them. Good luck if you are a designer trying to utilize one of these beasts, you won't be getting any help soon. 2.) Do you have any idea how expensive it is to "re-qualify" these systems when the commercial GPU guys decided they don't feel like supporting the previous generation of chips anymore in production? If you only used the part going obsolete in one program you are lucky, but most likely it is in several programs as it served as part of a new platform at that time. While FPGA's can be more expensive from a straight piece price perspective, FPGA's offer - flexibility, scalability, the option to take your IP with you from generation to generation, a better path toward differentiating / customizing the solution for your customer / product, potentially several more layers of security against reverse engineering efforts and last but not least a few industry choices who have significant engineer support for this market. If you knew the REAL cost of traditional GPUs to the system and life cycle management of these government programs, you would PRAISE this market for the trend toward FPGA.

This reminds me of the 7 blind wise men and the Elephant. For many graphics and processing applications a GPU is an astounding value with up to a terraflop of processing for carefully crafted applications requiring a tiny amount of memory, and not a whole lot of data exchange. For others, it is a paperweight, and a CPU can dance around it. And For computer vision and a few hundred other tasks that can justify the tens of thousands of dollars in investment, rather than a few tens of dollars, you can make a FPGA processor much more powerful, but hugely more expensive. Get more than a hammer in your tool box people, or all your problems look like nails, or you are doomed to be like the last blind wise man.

As an EE specializing in programmable logic design and VHDL implementation of DSP algorithms, and as an employee of one of those military defense sub-contractors, I absolutley agree with the comment from Alex D. There is a tremendous waste of taxpayer money on so-called "custom hi-rel" design that could be done a heck of a lot cheaper with COTS asics. But the "not invented here" syndrom is most prevelant in the aero community. Oh yea.. it also adds $$ to the contract value.

"if Rockwell Collins is willing to consider FPGAs for image generation in flight simulation, who am I to argue?" I don't know who you are, but I'll be the one to point out that what Rockwell Collins did was immeasurably stupid. Absolutely unjustifiable. A theft of government money, no doubt. We are not even discussing general-purpose computing, but strictly graphics! The advantages that years of astonishingly rapid progress in dedicated-purpose graphics silicon have brought do not just lie in multiplying together numbers. As Intel itself discovered, that is just icing on the cake. The challenge is in the caches, the texture sampling, the many other techniques and shortcuts that are part of rasterization. The algorithms for it are advanced and numerous, and it is the place where every would-be GPU competitor stumbles. (Intel was hoping to do this all in software, on top of its general-purpose cores. It failed. This is why it retreated, to go back and to reimplement them all.) I cannot imagine the engineering expenditure that this contractor put out to create their sub-standard soft-GPU. The cost must been staggering. This is what is wrong with defense contractors. It really is.

Many high end mil/aero apps are doing more than considering and adopting GPUs to aid in the math processing. Intel's issue is that they keep straying from their core strengths. They've got great integrated grahics in their chipsets but need to keep away from the discrete business.

Alas, this article is completely wrong from beginning to end. Rockwell Collins' motivation for choosing an FPGA-based design over a GPU-based design is not clear from the linked article, but even 12 boxes of FPGAs can't possibly provide better throughput on conventional 3D rendering than one box of GPUs, nor will it offer any "CUDA-style" programmability. CUDA, after all, uses simple extensions to high-level languages. FPGAs are programmed in hardware description languages, which require exceptional levels of developer skill and time to achieve good efficiency. Also, the communications overhead required to allow multiple boxes of FPGAs to cooperatively render a single scene would be utterly crippling. This leads me to believe that perhaps Rockwell Collins is doing something other than conventional 3D rendering, such as image-based synthesis, where GPUs are potentially less efficient than FPGAs. Over time, GPUs are gaining performance much faster than FPGAs, which simply can't afford to switch from simple integer logic blocks to full floating-point execution units. Such a switch would simply turn them into de-facto GPUs, eliminating their key advantage of flexibility. The linked article is itself rife with technical errors, such as Steve Thomas' claim that FPGAs have an inherent advantage in resolution. Never mind the 12 boxes of FPGAs or even one box of Tesla GPUs; one GPU alone (the latest Radeon HD5800) can drive 25 million pixels across six displays. So there's no story here, sorry, just a big misunderstanding.

I think the reason for the low-end DSP de-emphasis, more than anything else, is that uC vendors can now add a multiplier/accumulator for next to no penalty at today's geometries and sell them cheap a la AVR and dsPIC. ASIC vendors can toss DSP in for next to zero overhead onchip for ASSPs as well, so the Qualcomms of the world have no need for a dedicated low throughput DSP either. DSPs still remain quite entrenched in throughput-critical apps like wireless basestations, though - much to the chagrin of the FPGA guys. The "DSPs" in FPGAs are really DSP building blocks, so they are still quite crude and broad-application oriented - having a slug of them on one chip makes up for it though. I'm a bit surprised that Rockwell Collins has a huge rel requirement for a flight sim, and pays the according prices - I would have thought it's sheer resolution and pixel processing needs that drive them out of "standard" GPUs, but that COTS would be adequate. If a graphics processor, whatever it is, crashes now and then, who cares other than the flyboy that reserved the sim schedule slot? Now, if it were in an Air France Airbus flying out of South America, or a B2 running synthetic vision in IFR - different story. The battle has yet to unfurl between Intel and Nvidia. I get the feeling the elephant will crush the gnat if it becomes enough of an irritant.

About time Intel dropped this ridiculous project (Larrabee). Many high-end apps were considering just using a GPU for their math-intensive apps (that had nothing to do with graphics). I advised some designers against using GPUs and recommended they go with multiple DSP cores in FPGAs a month or so ago. Now, it's time for some nice heterogeneous multicore FPGA implementations to show up (a regular MPU for pedestrian apps code, and some honking-fast DSP/GPU cores for the math). There is sanity in the tech world...it just takes time for Intel to see stupid projects and drop them for sanity to surface....