Slashdot Mirror
AMD Launches Partnership With CAD Developer PTC
MojoKid writes "AMD is kicking off its weekend with news of a partnership between itself and CAD software developer PTC (Parametric Technology Corporation). PTC owns and develops the Creo software family. One of the programs at the heart of the company, Creo Element/Pro, was originally known as Pro/ENGINEER. It's not at all unusual for software developers in the CAD/CAM space to ally with hardware manufacturers, but it's typically Nvidia, not AMD, making such announcements. AMD claims that the upcoming Creo 2.0 product suite will be able to take advantage of the GPU in unprecedented ways that simultaneously improve performance and visual quality without compromising either. The company calls one such option Order Independent Transparency, or OIT. OIT is a rendering technology that allows for the partial display of wireframes and models inside a solid surface without creating artifacts or imprecise visualizations."
Wow, talk about a blatant slashvertisement. As the summary states, it's not at all unusual for CAD/CAM software to ally with hardware so what exactly is the news for nerds here??
With more contributors working on improving BRL-CAD's usability and features, we'd have an open source alternative without the huge recurring price tag. Lots of ways to get involved are listed here: http://brlcad.org/wiki/Contributor_Quickies
You see what I did there.
Cheers!
Sean
Now if PTC would invest in a more intuitive UI...
I would nominate Pro/E 5 (last version before Creo) as worst UI ever.
No that would be Microsoft and ActiveX in games. Not because some company owns one implementation of OpenGL.
While the announcement in and of itself isn't that big a whoop it does bring up a more interesting question: Which will be more important in the future, the CPU or the GPU?
As we have seen with the Brazos platform as well as liano (I believe bulldozer is a server chip they tried to push into a consumer market that it simply wasn't designed for because they needed product) it appears that AMD believes it is the GPU that will be of primary importance. As someone who deals with consumers 6 days a week I can see their reasoning, as more and more of my customers are more concerned with multimedia than raw number crunching and lets face it after dual cores PCs became "good enough" for the uses that the average consumer has. i have built several E350 based units for office as well as home and the extremely low power while having "good enough" CPU and hardware accelerated video does make for a nice platform. As we have read the next push from AMD will be switching the GPU from VLIW to vector based which since it will be built into the core would allow the GPU to behave as a "super floating point" thus meaning the CPU can be even simpler
Then you have the Intel stance which is to pare what they consider a "good enough" GPU with a high performance CPU. this design too has merits as if you have a powerful enough CPU then what the GPU does can often be done by the CPU instead. There is also the question of how much pure number crunching can be done on the GPU VS the CPU as it will take time to learn how to program for the GPU (although OpenCL may help in this regard) whereas the CPU is known by developers and thus easier to program for.
So I'd say that is an interesting question, whether to go for the power in the GPU or in the CPU. Using myself and my customers I'd say AMD has a good strategy for the consumer market whereas Intel has a good strategy for the business. After all Suzy the checkout girl isn't manipulating huge spreadsheets or dealing in large databases but there are plenty of business uses for having serious number crunching ability. I could easily see the split happening along those lines, with the consumer units, be it netbook/nettop, laptop, or desktop being AMD while the workstations and business laptops belong to Intel but i think it will be interesting in the next few years to see how it shapes up.
I will say whomever at AMD killed the Phenom/Athlon lines was an idiot and should get a good firing, the BD design simply isn't good for the consumer, its too expensive with frankly less bang for the buck than the Thuban and Deneb chips which often curb stomp it in all but its highest SKU and its pretty obvious that while its a good server design (as integer heavy highly threaded loads are more prevalent there) its simply not a good deal for consumers. I would have stuck with Bobcat on mobile, maybe adding a 4 core version for the more midrange machines, and kept Thuban (since it can fit everything that used to be covered by Phenom/Athlon simply by flipping off cores and/or cache which also made it a more attractive target for those who wished to try turning on disabled cores) and waited to see if integrating a vector based GPU would bring the increased performance to replace Thuban.
But in either case the next couple of years should be interesting as we see which strategy pays off and for which markets.
ACs don't waste your time replying, your posts are never seen by me.
It was the late 90's. PTC's salesmen lied to us through their teeth about what Pro/Engineer could do and how stable it was. "Yeah, it can do sheet metal!". Two million dollars and god knows how many man hours wasted. Just thrown away.
And it wasn't just us, it seemed they'd f*cked lots of businesses. At least the mid-sized ones I knew of. But no one wanted to admit they'd been had, or sue them.
I'm sure PTC is better now, and the sales people never lie to anyone. Why look, they even changed the name of the product.
Same ProE that dropped Linux support out of the blue (but kept Solaris, so it's not a matter of development effort, Unix or platform popularity)?
gg assholes!
Contrary to the popular belief, there indeed is no God.
ActiveX... *facepalm*
Implementation.... the CAD companies control the standards body, Khronos, forcing them to make minor incremental upgrades to the OpenGL standard. AMD/Intel/NVIDIA add their own extensions to the standard to utilize their silicon more fully, however they are all different from vendor to vendor. Then gaming engines need to code for three implementations of tessellation, or some other bullshit technology that only games use. Game developers look at this, give up, and develop for Windows/XBox exclusively, because Microsoft does not put up with this bullshit in DirectX.
CAD IS THE REASON LINUX GAMING DOES NOT EXIST.
Absolute nonsense. CAD is the engine that kept OpenGL going through the years of vicious attacks by Microsoft. Even though Microsoft achieved near absolute victory in the gaming space and played an instrumental role in bringing SGI to its knees, it failed to kill OpenGL entirely, in large part because of the entrenched high end CAD market. While most CAD vendors did port their systems from Unix to Windows in the late 90's, they had little interest in porting to Direct3D. Microsoft was therefore prevented from undermining OpenGL on Windows by their usual techniques such as playing games with the driver APIs. During this period, Linux took over Hollywood's render farms from Unix, and that was another base of support for OpenGL, but it might not have been sufficient if Microsoft had ever succeeded in dislodging the tenacious grip of OpenGL on Windows-based CAD. And then there was John Carmack's famous refusal to switch to Direct3D, but that came close to the brink. Not any more.
In my opinion, the greatest threat to OpenGL ever was the noisy faction of game developers pushing for a complete break with compatibility for OpenGL 3.0 (I doubt very much that John Carmack was ever one of those, despite his well founded criticisms). In retrospect it was proved that OpenGL could achieve parity with Direct3D and more, without breaking compatibility. And now OpenGL basically owns the entire gaming universe except for the steadily shrinking part over which Microsoft is able to exercise monopoly control.
Well, and Linux gaming does exist, just not at the level where we can throw away our consoles quite yet. But that day is coming.
One can fairly ask, why is the Linux game market, with millions of potential customers, not already well served by the likes of EA and Activision? I don't know the answer to that, and I don't think you do either. It very definitely has nothing to do with the influence of CAD vendors on OpenGL. I tend to suspect the hidden hand of Microsoft, however I do not have firm evidence of that. And furthermore I don't care, because it is the very failure of the big publishers to serve the Linux market that has accelerated the rise of a vibrant and rapidly growing community of free and open content developers on Linux. I sincerely hope the big publishers continue to keep their heads up their proverbial colons forever, because it does our community nothing but good in the long run.
Have you got your LWN subscription yet?
I will say whomever at AMD killed the Phenom/Athlon lines was an idiot and should get a good firing
BD was Dirk's baby and he was the first to fall on his sword. Personally, I think BD turned out well given the fact that AMD was teetering on the brink of financial collapse for the majority of the design cycle. It won't be much longer before Trinity gives a second look at what the BD core can do in a consumer SKU.
Before they changed the name ("Creo"? Really?) away from the extremely well established Pro/ENGINEER branding, they had a personal use license for $250. I just came up with a use for it (interesting timing for this announcement), and now I don't see this option available.
I did find the student license, but I'm not a student and the requirements are quite clear and specific - and I don't meet them.
I also found the Creo Elements/Direct Modeling Express for free (up to 60 parts, which suits my needs), but this doesn't appear to be the same software. Does anyone know if this still has the "sketcher" to rough draft the profile of the 3D parts? (I'll have to build a MS machine to even test it out - doubt it runs in Wine).
Granted, the last time I used Pro/E was ~1994 (on Solaris) and the UI has changed dramatically at least twice since then, so I'll have to re-learn it anyways.
I actually liked the original UI... when they changed it to meet Microsoft's requirements (when they first offered it on MS windows), I thought it was a horrible turn to an inefficient design. Don't get me wrong, I understand the reasoning (make it "familiar" to windows users), but the change made it much less efficient to use even though the learning curve was shallower.
Yes, I agree with other postings, it's a shame they dropped Linux support.
I just googled "3d cad linux" and the top advertisement is titled "3D CAD Linux - Flexible, Easy-To-Use Application | PTC.com" with a link to www.ptc.com/Free-Download, which leads you to download 2 options, 32bit and 64bit windows software. That's kind of a dirty advert method for a company as well established as PTC...
I suspect that the lack of Linux games is that no one believes those millions of potential customers actually represent millions of customers.
A significant percentage of Linux users are freedom-only. They are out.
A significant percentage are the older unix-admin turned Linux user. Most of them fall outside the gaming generation.
A significant percentage are the experimental programmer types who are unlikely to have a stable system to target.
So for anything too complex for lowest-common hardware (software rendering won't cut it) or that isn't suitable for allowing the user to recompile themselves (anything with online or competitive play) the visible market is... small.
And the open source model doesn't really work for games. A 90% working beta program is potentialy useful. A 90% working beta game is something that crashes at the load screen and won't let you properly complete the first quest.
A significant percentage of Linux users are freedom-only. They are out.
What significant portion is that? I seriously doubt you can find anybody who has never run a proprietary binary on their Linux system. RMS perhaps, but that Is about it (and I would not have it any other way). While it is entirely correct for major Linux distributions to completely ignore or quarantine every bit of binary or non-free, nobody ever said that Linux should be a bad place to run binary distributions. Just ask the Opera folks about that.
A significant percentage are the older unix-admin turned Linux user. Most of them fall outside the gaming generation.
Then I wonder where all those Unix admins are when you try to hire them. I do believe you vastly overestimate the proportion of the Linux community that consists of sysadmins. The Linux developer community, yes, but the Linux user community is orders of magnitude bigger than the Linux developer community.
A significant percentage are the experimental programmer types who are unlikely to have a stable system to target.
I wish. Then we would be even further ahead technology wise. But I seriously doubt you will find any facts to support your claim.
Sorry, I'll have to call your post 100% FUD.
Have you got your LWN subscription yet?
A significant percentage of Linux users are freedom-only. They are out.
As the Humble Indie Bundle have shown, Linux users in general are willing to pay more for software than Windows users. Maybe because they aren't taxed for basic things like operating system and word processing they have more to spend on games?
Let me be the first to say "huh?"
Desktop OpenGL use has never been as dead as it is now. The only new game to use OpenGL to come out in the last 18 months is id's Rage, and that was a bit of a flop. Looking forward the only game using OpenGL is Doom 4, which is based on the same engine as Rage. No one else is commissioning new projects based on OpenGL. At best OpenGL is what you add to your engine as a hack to get it working on Macs.
The only place OpenGL is alive and well is on mobile devices, and that's not even technically OpenGL. That's OpenGL ES, which is the complete break that game developers wanted.
No, I'm quite afraid OpenGL on the desktop is dead. The CAD guys will hold on to it until the end of time, but everyone else has moved to Direct3D.
Gaming consoles and even handhelds like the aging Nintendo DS use OpenGL. The poster above is referring to the shrinking games market on PCs of which not all use DirectX anyway. When the big guns like Blizzard use OpenGL I really can't see how you can say it's dead on the desktop.
Most of the modern gaming consoles can use OpenGL. But the developers don't. Virtually all of the major games are programed in LibGCM, kind-of DirectX, and GX for the PS3, 360, and Wii respectively. And the handhelds don't use OpenGL at all, especially not the DS which is only barely 3D capable in the first place.
When you're working with a fixed platform you can work at a much lower level to maximize your performance. In fact you basically have to. Pure OpenGL is too high level for that.
Also, while it's true that Blizzard uses OpenGL on their Mac ports, I would hesitate to count Blizzard as being big on OpenGL. They use OpenGL because they have to, not because they want to. Their Windows games all use DirectX, and the Mac ports are rarely as graphically advanced. Now if they were using OpenGL on Windows and Mac OS X that would be a different story. But as it stands you're not seeing anyone besides id voluntarily use OpenGL on Windows, which is the only desktop platform where that API is optional.
"Virtually all of the major games are programed in LibGCM, kind-of DirectX, and GX for the PS3, 360, and Wii respectively. And the handhelds don't use OpenGL at all, especially not the DS which is only barely 3D capable in the first place."
You are conveniently leaving out the massively growing Android and iOS smartphone and tablet market, where OpenGL is the standard 3D graphics engine.
If you read my original post (the GP), you'll see that I'm not. This sub-thread is about handheld game consoles rather than mobile devices.
And now OpenGL basically owns the entire gaming universe except for the steadily shrinking part over which Microsoft is able to exercise monopoly control.
Well, and Linux gaming does exist, just not at the level where we can throw away our consoles quite yet. But that day is coming.
One can fairly ask, why is the Linux game market, with millions of potential customers, not already well served by the likes of EA and Activision? I don't know the answer to that, and I don't think you do either. It very definitely has nothing to do with the influence of CAD vendors on OpenGL. I tend to suspect the hidden hand of Microsoft, however I do not have firm evidence of that.
I think the main reasons are much simpler (even if I would not trust Microsoft to abstain from meddling):
1) Low market share of Linux on the desktop. That means far fewer potential customers.
2) For fast 3D graphics (which are important to "AAA"games), the driver situation on Linux is still a bit unsatisfactory. You either have to run the binary drivers from the vendor, which have a lousy reputation in case of AMD, or the Open Source drivers which are still inferior in terms of performance (check the benchmarks on http://www.phoronix.com/scan.php?page=home).
For the Open Source drivers, the situation in the field is probably worse than the Phoronix benchmarks suggest:
Phoronix usually tests the latest developments, which will then take some months more to go into the next kernel version and some months on top of that to land in the distros. Not so long ago, the Open Source drivers were struggling not only with performance but also with correct rendering. I suspect a lot of those broken drivers are still out there.
C - the footgun of programming languages
And the open source model doesn't really work for games. A 90% working beta program is potentialy useful. A 90% working beta game is something that crashes at the load screen and won't let you properly complete the first quest.
Wrong. A 90% working beta game is one with placeholder textures, stub AI and lots of cheat modes. A game that crashes at the load screen is a broken game, Open Source or not. No self-respecting open source coder would call that "beta".
And the handhelds don't use OpenGL at all, especially not the DS which is only barely 3D capable in the first place.
Don't practically all handhelds with a fancy GPU use OpenGL ES?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
What significant portion is that? I seriously doubt you can find anybody who has never run a proprietary binary on their Linux system. (...) While it is entirely correct for major Linux distributions to completely ignore or quarantine every bit of binary or non-free, nobody ever said that Linux should be a bad place to run binary distributions. Just ask the Opera folks about that.
True, but it's a long way from pragmatists who have used the nVidia blob or ran Opera into a paying games customer. A person who is 95% vegetarian but will eat meat if he's very hungry or there's not much other food doesn't make him a prime customer for a steak house. And the people who run Linux because it's free as in beer, well they're not likely to be very profitable customers. Most people tend to fall into one of those two categories. If you take away those two things, if you say you could get Windows or OS X or Linux for the same price and they all came as blobs... would you still run Linux?
Live today, because you never know what tomorrow brings
And also on MS Windows. Take a look at any forum on running the MS Windows version of WoW under wine and you'll see recommendations to run it in WoW's OpenGL mode instead of the DirectX mode. The command line flag is Wow.exe -opengl FFS - it doesn't get more obvious than that! Now don't try pretending it's anything other than an argument for Wow.exe, instead if you have the software just try launching it that way from a shell on MS Windows7 and you'll see it works there too.
Also look up one of the first released games for the Nintendo DS - "Mario Kart", as an example using OpenGL on that platform. I'm sure you've heard of that game if you've heard of the DS.
Why are you making shit up? What is your agenda here and why are you trying to shove lies down our throats? You've gone way beyond being an innocent but clueless fanboy here so what is going on?
Note: I'm no expert in this area, this is just some stuff I have picked up along with a basic understanding of how these techniques are employed. There may be inaccuracies or incomplete information, corrections welcome.
OIT is one area that modern graphics hardware really struggles with - A software render can just go ahead and allocate memory dynamically to keep track of the depth value and the colour of each fragment that contributes to a pixel's final colour in a list, but on a 'traditional' GPU, the big problem is that you have no easy way to store anything more than a single 'current' colour per pixel that will get irreversibly blended or overwritten by fragments with a lower depth value, and even if you could keep a list of them, you have no associated depth values, and nor do you have a simple way to sort them on the GPU. However, there is some clever trickery detailed below:
Realtime OIT has been researched and published on (notably by Nvidia and Microsoft) for over a decade.
Heres the basic technique - 'Depth Peeling', from 2001:
http://developer.nvidia.com/system/files/akamai/gamedev/docs/order_independent_transparency.pdf?download=1
Depth peeling renders the scene multiple times with successive layers of transparent geometry removed, front to back, to build up an ordered set of buffers which can be combined to give a final pixel value.
This technique has severe performance penalties, but the alternative (z-sort all transparent polygons every frame) is much, much worse.
'Dual Depth Peeling' - from 2008:
http://developer.download.nvidia.com/SDK/10.5/opengl/src/dual_depth_peeling/doc/DualDepthPeeling.pdf
This works in much the same way, but is able to store samples from multiple layers of geometry each rendering pass ,using MRT (multiple render targets), and a shader-based sort on the contents of the buffers, speeding the technique up a lot.
Refinements to the DDP technique, cutting out another pass - from 2010:
http://developer.nvidia.com/sites/default/files/akamai/gamedev/files/sdk/11/ConstantMemoryOIT.pdf
Reverse depth peeling was developed where memory was at a premium - which extracts the layers back-to-front for immediate blending into an output buffer instead of extracting, sorting and blending, and it is also possible to abuse the hardware used for antialiasing to store multiple samples per output pixel.
Depth peeling really only works well for a few layers of transparent objects, unless you can afford a lot of passes per pixel, but in many situations, it is unlikely that the contribution of transparent surfaces behind the first 4 or so transparent surfaces means much in terms of visual quality.
AMDs 'new' approach involves implementing a full linked-list style A-buffer and a separate sorting pass using the GPU - this has only been possible with pretty recent hardware, and I guess is 'the right way' to do OIT, very much the same as a software renderer on a CPU would do it.
Heres some discussion and implementation of these techniques:
http://www.yakiimo3d.com/2010/07/19/dx11-order-independent-transparency/
This really isn't anything new, single-pass OIT using CUDA for fragment accumulation and sort was presented at Siggraph 2009 - nor is it something PTS can claim as their own. Its possible AMDs FirePros have special support for A-buffer creation and sorting, which is why they run fast, and AMD in general has a pretty big advantage in raw GPGPU speed for many operations (let down by their awful driver support on non-windows platforms, of course) - but really any GPU that has the ability to define and access custom-structured buffers will be able to perform this kind of task, and given NVidia's long history researching and publishing on this subject, its pretty laughable that AMD and PTS can claim it is their new hotness.
I gots ta ding a ding dang my dang a long ling long
Actually, it looks like Autodesk is committed to DirectX and/or in-house developed display drivers at this point.
Blizzard includes the opengl renderer on Windows because it's free, not because it's better. It's not even as good. And they don't support it. Try reporting graphics problems with OpenGL on Windows and they will tell you to stop doing that and to go away.
Are you having an affair with Khronos or something?
(I just realized I accidentally posted A/C last night... reposting while logged in)
Before they changed the name ("Creo"? Really?) away from the extremely well established Pro/ENGINEER branding, they had a personal use license for $250. I just came up with a use for it (interesting timing for this announcement), and now I don't see this option available.
I did find the student license, but I'm not a student and the requirements are quite clear and specific - and I don't meet them.
I also found the Creo Elements/Direct Modeling Express for free (up to 60 parts, which suits my needs), but this doesn't appear to be the same software. Does anyone know if this still has the "sketcher" to rough draft the profile of the 3D parts? (I'll have to build a MS machine to even test it out - doubt it runs in Wine).
Granted, the last time I used Pro/E was ~1994 (on Solaris) and the UI has changed dramatically at least twice since then, so I'll have to re-learn it anyways.
I actually liked the original UI... when they changed it to meet Microsoft's requirements (when they first offered it on MS windows), I thought it was a horrible turn to an inefficient design. Don't get me wrong, I understand the reasoning (make it "familiar" to windows users), but the change made it much less efficient to use even though the learning curve was shallower.
Yes, I agree with other postings, it's a shame they dropped Linux support.
I just googled "3d cad linux" and the top advertisement is titled "3D CAD Linux - Flexible, Easy-To-Use Application | PTC.com" with a link to www.ptc.com/Free-Download, which leads you to download 2 options, 32bit and 64bit windows software. That's kind of a dirty advert method for a company as well established as PTC...
- Preferences: Solaris 10 (servers), Ubuntu (desktops), Solaris 11 (personal servers) -
Maintaining OpenGL compatibility is one thing (that is, the hardware itself runs both old and new), but the language itself, especially graphical shading language (GLSL) made a huge turn at 3.0, making it much more similar to Cg and HLSL and most code that makes use of shaders needs to be rewritten. In my experience, this is a non-trivial rewrite because the code needs to hook into every triangle list and every shader needs to be rewritten if you want to use any new features (which has affected nearly every shader I've written because I'm highly involved with tessellation, but may not affect people writing shaders for, say, shadow mapping). IMO this is a good thing, though - the change is hard to implement, but porting code from Cg or HLSL will be MUCH easier, and it gets rid of a bad design decision that fixes some functionality. I haven't actually tried to port any shaders yet (I've been fixing the ones I've got), but having worked with GLSL and Cg with a touch of HLSL (porting, mostly) it looks like it will be far easier now.
That said, every CAD company is moving features or products to take advantage of hardware acceleration, most just partner with nVidia, which has supported OpenGL much better than ATI traditionally (like supporting non-ARB extensions, which ATI has historically been really bad at, though lately they've done better, or so I've heard - I don't currently have a properly working ATI card - the one I have blue screens Windows after about 1-5 minutes in graphics acceleration).
As for Linux gaming, Loki had problems because most people that can run Linux can run Windows as well, and do so for gaming, or run WINE. There also is a larger potential market targeting Apple, and that market hasn't been exploited much, either. There is quite a bit of effort needed to port from DirectX to OpenGL, whereas it used to be pretty trivial. All that work is for a potential 10% additional market share (8% Apple, a little less than 2% Linux, because if you port to OpenGL you'd be an idiot not to not also support Apple).
I would agree with you if all Game Developers were also writing their own Graphics Engine. However, most people use an existing Engine which has already implemented all the compatibility bits
http://soylentnews.org/~tibman
Pure OpenGL is too high? The last time i was working with it (1.1) it was very very low level. Polygon construction, vector lists, state machine, push/pop'ing each translation and rotation. You also had to query for gl extensions to figure out what the hardware was capable of and tailor the rendering.
I'm doubting OpenGL is too high level. It's like the c language for graphics. If anything, it's too low (which is fixed with libraries).
http://soylentnews.org/~tibman
Mod parent up -- I'm not sure why people think OpenGL is heavily used in gaming, but it's not, really, outside of OpenGL ES, which parent post notes isn't real "OpenGL" in the traditional sense.
But you do NOT kill a good product line for a new line that gets curb stomped by the previous product! Check out the benches and pretty much the ONLY task where the BD chips can beat thuban is in integer heavy loads...which is a task that almost never comes up in consumer typical workloads! Its overpriced AND underpowered which is really not a good combo. Hell I know guys that were die hard AMD fanboys and after BD they finally gave up and went Intel.
Frankly I'll keep selling AMD as long as I can get AM3 and AM3+ boards cheap but if they don't come up with something that beats Thuban by at LEAST 30% by the time Thuban stocks run out I'll too have to go Intel. The Bulldozer is frankly a lousy chip for consumers and gets beaten by both the low end Intel AND the previous Deneb and Thuban chips.
And I hope you are right because from what I've seen the BD design is a clusterfuck. Trying to remove floating point when damned near every load a consumer has IS floating point heavy? That's just retarded. BTW did you know that if you disable half the "cores" in BD you get a 25% speed INCREASE instead of a hit? That tells me that what they are trying to push as a 6 core is really a 3, and their quads are duals, yet they are trying to sell them at quad and 6 prices when the performance just isn't there. And the worst part is if the rumors are true the performance hit will ONLY be fixed in Windows 8....which is gonna be Vista the second coming from how reviled it is.
Frankly AMD's problem is not Intel but their own retarded roadmap. Thuban and Zosma were not only making money but gave them nearly 100% yields because they could simply disable bad cores and/or cache and sell them as lower SKUs, and Brazos is beloved by the OEMs and the consumers, showing up in desktops, netbooks, laptops, and all in ones. So what do they do? Kill the Krishna upgrade to Brazos AND kill Thuban which shot to shit their entire AM3 line and the only chips they have to replace them are BD which sucks ass or Liano which is just a Stars core jammed with a GPU. It seems like they bet the entire farm on a chip that was having as many problems as Phenom I and i only hope they can survive yet another failure. Lets be honest Brazos is a good design but they can't ride it for 3 or 4 years like they did with Phenom, it needs an increase in cores or a speed bump.
I just hate to see AMD keep shooting themselves in the face when now more than ever we need competition to keep Intel from screwing the market price wise. They were in the black, both their CPUs and GPUs were making profits, why would Dirk do something so damned retarded?
ACs don't waste your time replying, your posts are never seen by me.
Factually, incorrect.
Desktop OpenGL has never been larger than it is now. How come? Apple. Every copy of OS X sold with Macs adds another OpenGL Desktop to the total. Quarter over Quarter Apple's Desktop Market share is growing.
Try again. Apple chaired the OpenGL 3.3 branch. They also chaired the OpenGL 3.1 branch. Khronos is fully embracing the move to OpenCL (another Apple gift) along with AMD. Nvidia is still kicking an screaming and pushing CUDA. PTC is starting to move it's Applications to OS X. It's not because OS X wasn't ready for OpenGL--it's the only Desktop Environment with OpenGL throughout. It was the perceived market share for years and perceived resistance by IT to push OS X. That's all gone. iOS and OS X make it obvious that CAD companies can now push Fat and Thin client tools for their clients and actual technical users giving them a new vertical market for profits.
You lack of what is going on at Cupertino, Khronos, AMD, PTC, Autodesk and more is rather clear.
Hi, my name is Zamulmekan, from Turkey. I'm a web design and seo expert.
Seo name it "Search Engine Optimication" sentence is arflerinden head. Internet visitors, search engines (Google, Yahoo, Bing, MSN, etc.). Site's content and would like to access any information relevant to the subject, taking into consideration certain criteria to make the search engines is a site, a site within the optimizasyunudur. SEO usually abbreviated saying.
Is it necessary to a successful site SEO?
ANSWER: Absolutely yes!
BECAUSE ... More
Free or not the above poster pretended it wasn't there at all. Turning it into a Maxwell Smart "would you believe" joke doesn't change that.
Wow, Autodesk, the crappiest CAD company of them all. And look, ADSK flat on its back the last five years. Somehow you just know that going to happen to anybody who drinks the Microsoft Koolaid.
When all you have is a hammer, every problem starts to look like a thumb.
Trying to remove floating point when damned near every load a consumer has IS floating point heavy? That's just retarded.
I thought the future is having an on-chip GPU core for doing the FP-intensive work? (I know Bulldozer doesn't have one, but will later ones?...)
Stick Men