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
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.
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.
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?
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.
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
(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) -
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