AMD CPU speculation... and expert conjecture

[vmN]

Holy poop, some aggressive marketing from Apple. Sounds very interesting.

 

[gamerk316]

And after AMD MANTLE now comes Apple METAL

http://arstechnica.com/apple/2014/06/apple-gets-heavy-with-gaming-announces-metal-development-platform/

This is another reason why AMD must release MANTLE for linux.

And now everyone rushes to make their own API's, exactly like I was afraid would happen.

Welcome to the beginning of the fragmentation of the gaming market.

 

[gamerk316]

Apple pushing new programming language too; trying to kill off Objective-C right after we start using it? How very MSFTish of you. *sadface*

http://arstechnica.com/apple/2014/06/apple-shows-off-swift-its-new-programming-language/

 

[etayorius]

The only problem i see is on Mobile devices... which most of us as PC Gamers care little for... but like Juanrga said, AMD is now forced to push on Linux too, if they do so and release full documentation on MANTLE, then they may kill DX12 too in the process.

 

[colinp]

I have it on good authority from my friend inside AMD (can't say too much, NDA, natch) that AMD stole Mantle from both Microsoft AND Apple.

On a serious note, I don't see the reasoning why Metal (designed for Apple's tightly controlled ARM ecosystem, therefore iOS and nothing to do with Intel, AMD or Nvidia) would force AMD to do anything on any other platform. OSX would still use OpenGL and whichever graphics vendor Apple have used in each generation.

 

[jdwii]

gamrer its cute when juan lives in his own reality, let him think OPENGL is easy to program for

 

[juanrga]

And after AMD MANTLE now comes Apple METAL

http://arstechnica.com/apple/2014/06/apple-gets-heavy-with-gaming-announces-metal-development-platform/

This is another reason why AMD must release MANTLE for linux.

And now everyone rushes to make their own API's, exactly like I was afraid would happen.

Welcome to the beginning of the fragmentation of the gaming market.

To be fair you didn't predict anything about Apple. You predicted the possibility of Intel and Nvidia releasing proprietary APIs, when you believed that MANTLE was a proprietary API developed by AMD for GCN hardware.

But as showed latter MANTLE has been developed by game developers for arbitrary hardware and AMD implemented it on its hardware because developers contacted AMD after others (including Microsoft) showed the finger.

AMD and developers still pretend to release MANTLE as open standard.

Apple is a closed ecosystem. They sell its own hardware, its own OS, its own developer tools,... Apple releasing an proprietary API for its own hardware is logical when you think about it.

The reason why this move has to accelerate AMD intention of releasing MANTLE for linux is because (i) the new API shows that Apple is now serious about gaming and (ii) Apple tablets and other gadgets will be competing against AMD gaming tablets and other gadgets.

I have it on good authority from my friend inside AMD (can't say too much, except copying what others said before in the thread, NDA, natch) that AMD stole Mantel from both Microsoft and Nvidia AND Apple.

Fixed it for you.

 

[juanrga]

gamrer its cute when juan lives in his own reality, let him think OPENGL is easy to program for

What is cute (or pathetic, it depends of viewpoint) is that all your late posts in this thread are about mentioning me to a third person.

Also "easy" is a subjective word that I didn't even mention.

 

[juanrga]

And more praise for MANTLE coming from another game developer

Simply put, Mantle is the most advanced and powerful graphics API in existence. It provides essentially the same feature set as DX11 or OpenGL, and does so at considerably lower runtime cost.

Much of the work that drivers used to do on an application’s behalf is now the responsibility of the game engine. This means that the Mantle API is able to be backed by a very small, simple driver, which is thus considerably faster. It also means that this work, which must still be done, is done by someone with considerably more information.

All of this means that Mantle has, quite literally, reduced the cost of a draw call by an order of magnitude. This is an amazing technical achievement and difficult for us to exaggerate the importance of this savings.

http://techgage.com/news/firaxis-explains-its-reasons-for-adopting-amds-mantle-technology-for-civilization-beyond-earth/

 

[juanrga]

AMD new mobility R9 GPU with Tonga processor

http://videocardz.com/50737/amd-radeon-r9-m295x-tonga-gpu-32-compute-units

And new Intel Devils-Canyon OC series released (Intel recent launch looks somewhat as AMD launching FX-9000 series). First Haswell chip with 4GHz base clock.

Spoiler

Spoiler

Spoiler

 

[juanrga]

Richard Huddy (Godfather of DirectX) rejoins AMD as Gaming Scientist

http://www.kitguru.net/components/graphic-cards/bob/richard-huddy-rejoins-amd-as-gaming-scientist/

Thus AMD is developing a new core (Keller) in parallel with new GCN arch (Koduri) and in parallel with new software (Huddy). During interview Huddy explicitly mentioned that he is interested about "moving beyond DirectX".

 

[colinp]

The reason why this move has to accelerate AMD intention of releasing MANTLE for linux is because (i) the new API shows that Apple is now serious about gaming and (ii) Apple tablets and other gadgets will be competing against AMD gaming tablets and other gadgets.

AMD tablets are going to primarily support Windows, with Android an optional addon (i.e. not replacement). So Mantle on an AMD tablet already exists, no?

 

[cdrkf]

Richard Huddy (Godfather of DirectX) rejoins AMD as Gaming Scientist

http://www.kitguru.net/components/graphic-cards/bob/richard-huddy-rejoins-amd-as-gaming-scientist/

Thus AMD is developing a new core (Keller) in parallel with new GCN arch (Koduri) and in parallel with new software (Huddy). During interview Huddy explicitly mentioned that he is interested about "moving beyond DirectX".

+1

I've got to say, AMD do appear to be getting good people in, and look to have a direction again. Hopefully plenty more good things still to come from AMD.

 

[de5_Roy]

amd stuff at computex

MSI Shows off 970 Gaming Socket AM3+ Motherboard
http://www.techpowerup.com/201561/msi-shows-off-970-gaming-socket-am3-motherboard.html

Sapphire Unveils Atomic 990FX Motherboard with FC Water Block
http://www.techpowerup.com/201573/sapphire-unveils-atomic-990fx-motherboard-with-fc-water-block.html
fc is for full coverage incl. chipsets.

ASUS Shows off its First Socket FM2+ ROG Motherboard
http://www.techpowerup.com/201571/asus-shows-off-its-first-socket-fm2-rog-motherboard.html

edit: and steam engine inspired cases!! choo choo!!
http://www.techpowerup.com/201578/deepcool-unveils-four-new-steam-castle-color-options.html

 

[gamerk316]

And more praise for MANTLE coming from another game developer

Simply put, Mantle is the most advanced and powerful graphics API in existence. It provides essentially the same feature set as DX11 or OpenGL, and does so at considerably lower runtime cost.

Much of the work that drivers used to do on an application’s behalf is now the responsibility of the game engine. This means that the Mantle API is able to be backed by a very small, simple driver, which is thus considerably faster. It also means that this work, which must still be done, is done by someone with considerably more information.

All of this means that Mantle has, quite literally, reduced the cost of a draw call by an order of magnitude. This is an amazing technical achievement and difficult for us to exaggerate the importance of this savings.

http://techgage.com/news/firaxis-explains-its-reasons-for-adopting-amds-mantle-technology-for-civilization-beyond-earth/

And guess what? You can make a really focused API when it works on exactly one architecture. But as long as NVIDIA isn't on board, DX isn't going anywhere. And anyone who thinks otherwise is kidding themselves.

 

[colinp]

And guess what? You can make a really focused API when it works on exactly one architecture. But as long as NVIDIA isn't on board, DX isn't going anywhere. And anyone who thinks otherwise is kidding themselves.

Horses haven't gone anywhere either, but I still see internal combustion engines everywhere, some petrol, some diesel. And now electric cars are coming, but internal combustion engines aren't going anywhere.

Tech moves on, sometimes fragments, sometimes comes back together.

 

[gamerk316]

And guess what? You can make a really focused API when it works on exactly one architecture. But as long as NVIDIA isn't on board, DX isn't going anywhere. And anyone who thinks otherwise is kidding themselves.

Horses haven't gone anywhere either, but I still see internal combustion engines everywhere, some petrol, some diesel. And now electric cars are coming, but internal combustion engines aren't going anywhere.

Tech moves on, sometimes fragments, sometimes comes back together.

And sometimes, the worst tech wins. See Gas winning over Electric over a century ago. Marketability, cost, and ease of use are more important then technological advancement when it comes to selling a product.

 

[cdrkf]

And guess what? You can make a really focused API when it works on exactly one architecture. But as long as NVIDIA isn't on board, DX isn't going anywhere. And anyone who thinks otherwise is kidding themselves.

Horses haven't gone anywhere either, but I still see internal combustion engines everywhere, some petrol, some diesel. And now electric cars are coming, but internal combustion engines aren't going anywhere.

Tech moves on, sometimes fragments, sometimes comes back together.

I think Mantle has done exactly what it needed to- promote the fact that there *is an issue* with the current API's at the moment. At the end of the day if you can squeeze that many more draw calls out of the same hardware with essentially a software tweak, then obviously the current software is at fault.

Since Mantle, there have been demos showcasing big improvements via DX11, OGL 4.X and the announcement of DX12. Once these demos actually turn into something tangible mantle will probably fade away, in the mean time it's a nice capability to get more performance essentially for free.

 

[gamerk316]

To be fair, the OGL extensions have been in the API for a while now. No one uses them because of driver specific problems, however. And DX has been trying to improve performance for two major releases now, starting with DX10 and going on through DX11.2. Nothing new has been added since Mantle has come out; these improvements have been there for a while.

As for "software tweaks", there's always a tradeoff between ease of development and performance. Use Java instead of C++? Lose 5% performance. Use C++ instead of C? Subtract another 5%. C instead of optimized assembly? Take off another 10% on top of everything. There's a fine line between the ease I can write code and the algorithmic performance benefits that result, and the absolute code performance of coding to a lower level.

 

[cdrkf]

To be fair, the OGL extensions have been in the API for a while now. No one uses them because of driver specific problems, however. And DX has been trying to improve performance for two major releases now, starting with DX10 and going on through DX11.2. Nothing new has been added since Mantle has come out; these improvements have been there for a while.

As for "software tweaks", there's always a tradeoff between ease of development and performance. Use Java instead of C++? Lose 5% performance. Use C++ instead of C? Subtract another 5%. C instead of optimized assembly? Take off another 10% on top of everything. There's a fine line between the ease I can write code and the algorithmic performance benefits that result, and the absolute code performance of coding to a lower level.

Oh yeah I fully agree- I do a bit of embeded software development and much prefer to write in C than assembly (code in C is actually readable!)...

I'm not saying Mantle has changed what was going on in the background, however it has perhaps highlighted the issues more (so people are actually looking at the new extension in OGL for example), and also the draw call improvement in Mantle is quite significant. Other improvements in mantle are smaller and probably possible with other APIs with

 

[gamerk316]

To be fair, the OGL extensions have been in the API for a while now. No one uses them because of driver specific problems, however. And DX has been trying to improve performance for two major releases now, starting with DX10 and going on through DX11.2. Nothing new has been added since Mantle has come out; these improvements have been there for a while.

As for "software tweaks", there's always a tradeoff between ease of development and performance. Use Java instead of C++? Lose 5% performance. Use C++ instead of C? Subtract another 5%. C instead of optimized assembly? Take off another 10% on top of everything. There's a fine line between the ease I can write code and the algorithmic performance benefits that result, and the absolute code performance of coding to a lower level.

Oh yeah I fully agree- I do a bit of embeded software development and much prefer to write in C than assembly (code in C is actually readable!)...

I'm not saying Mantle has changed what was going on in the background, however it has perhaps highlighted the issues more (so people are actually looking at the new extension in OGL for example), and also the draw call improvement in Mantle is quite significant. Other improvements in mantle are smaller and probably possible with other APIs with

Up until last year, I had to work on one of these:

http://en.wikipedia.org/wiki/IBM_AP-101

Specifically, the IBM AP-101F. Got really good at optimized assembly during that time. We really cared about code size, to the point where if we had a branch that jumped 260 words, we would recode the software to get the jump within 256 words, so we could use a 16 bit pointer rather then a 32 bit one. We really cared about wasting 16 bits like that.

Compare that to PC's, where if you have a 10 iteration FOR loop, people use a 32-bit Integer value without batting an eyelash. Heck, even an 8-bit short would be twice as large as you need. But on PC's, you don't care. If you REALLY wanted to, you could run Crysis on a few Megs of RAM. But no one is willing to optimize to that level anymore.

Point being, you can do a lot with 256k, if you know how to use it. We did land on the moon with just 36k for crying out loud!

 

[cdrkf]

To be fair, the OGL extensions have been in the API for a while now. No one uses them because of driver specific problems, however. And DX has been trying to improve performance for two major releases now, starting with DX10 and going on through DX11.2. Nothing new has been added since Mantle has come out; these improvements have been there for a while.

As for "software tweaks", there's always a tradeoff between ease of development and performance. Use Java instead of C++? Lose 5% performance. Use C++ instead of C? Subtract another 5%. C instead of optimized assembly? Take off another 10% on top of everything. There's a fine line between the ease I can write code and the algorithmic performance benefits that result, and the absolute code performance of coding to a lower level.

Oh yeah I fully agree- I do a bit of embeded software development and much prefer to write in C than assembly (code in C is actually readable!)...

I'm not saying Mantle has changed what was going on in the background, however it has perhaps highlighted the issues more (so people are actually looking at the new extension in OGL for example), and also the draw call improvement in Mantle is quite significant. Other improvements in mantle are smaller and probably possible with other APIs with

Up until last year, I had to work on one of these:

http://en.wikipedia.org/wiki/IBM_AP-101

Specifically, the IBM AP-101F. Got really good at optimized assembly during that time. We really cared about code size, to the point where if we had a branch that jumped 260 words, we would recode the software to get the jump within 256 words, so we could use a 16 bit pointer rather then a 32 bit one. We really cared about wasting 16 bits like that.

Compare that to PC's, where if you have a 10 iteration FOR loop, people use a 32-bit Integer value without batting an eyelash. Heck, even an 8-bit short would be twice as large as you need. But on PC's, you don't care. If you REALLY wanted to, you could run Crysis on a few Megs of RAM. But no one is willing to optimize to that level anymore.

Point being, you can do a lot with 256k, if you know how to use it. We did land on the moon with just 36k for crying out loud!

Nice It is amazing just how much you can do on a micro controller with a small amount of memory. I've been developing a few hand held instruments around PIC 16 series controllers with a total 8k of integrated programme memory and I've never gotten close to running out of programme space.

I think back to how much I could do with my old 486 (full 3-D games for example). When you consider just how powerful modern PC's really are it does highlight how inefficient the software is these days!

 

[8350rocks]

@gamerk. A pair of guys wrote criticism against OGL and a pair of guys replied. It is not everyone vs one guy, as you pretend.

As a developer, I have to say, OGL is not the easiest platform to code for, yes, you can do it. You can even get good results. The issues lie in the fact that for 50% of the work required you can do it all in DirectX.

OGL is not bad, and it does have a lot of features. It is the LEGACY code they refuse to get rid of that makes it a PITA to deal with.

 

[Cazalan]

And the ARM 1 up-man-ship continues.

http://semiaccurate.com/2014/06/03/cavium-thunder-x-ups-arm-core-count-48-single-chip/

That has been my fear for AMD all along as they dabble with standard cores while these other companies have been at it for years and have custom cores. And they have a reputable motherboard vendor Gigabyte making the boards.

If a company like Facebook or Google really want to go all in on ARM will they choose a 48 core or an 8 core? Go big or go home right?

 

[cdrkf]

Hmmm, a large part of amds expertise in servers is in interconnects, memory controllers and integration with gpu. 8 arm cores plus a few hundred gcn shaders and multi cpu motherboards could make them very much the better option (obviously this is dependent on end use). Also bear in mind they are developing a custom core (k12) with a risc processor design legend ad the lead. The off the shelf core is only intended as a stop gap. Skybridge is all about perfecting the platform and unifying their arm and x86 designs. I doubt their first arm server processor is going to revolutionise anything but it doesn't have to.

I'm also fairly sure amds New arm processor tops out at 16 cores rather than 8 (2 x 8 core dies in one package).