AMD Supports Possible Lower Level DirectX

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Toggle sidebar Toggle sidebar
Status
Not open for further replies.


Right, square and dice worked so hard because they just LOVE writing for another API...It had nothing to do with AMD paying EA $8million to get it done for BF4. Hopefully at some point we will see what Square charges AMD but my guess is AMD will want that info to stay hidden if at all possible.

OpenGL=runs on everything - easy porting to everywhere
DirectX=runs on windows - not so easy to port
Mantle=runs on a few cards that run windows and still beta and all game devs have to code for it. It would appear even porting from console isn't easy. SEE AMD Mantle architect Guennadi Riguer COMMENT below.

LOSER=AMD. But maybe they planned on losing to get OpenGL/DirectX moving again, though considering they both have the same in already (openGL) or coming (directX) maybe this was just the natural direction of all 3. If AMD was being told people wanted "close to metal" then surely Nvidia/Microsoft heard this stuff too right? In fact, it seems they both responded so fast they must have already been in development long ago. It takes 2-3yrs to make a game. It takes 3-5yrs to make a cpu/apu/gpu/soc pretty much from start to finish, so how long does it take to get a new API off the ground (meaning you need engine support, you need game code to take advantage of that engine support, you need drivers, etc)?

http://www.gamespot.com/articles/thief-delays-support-for-amd-s-groundbreaking-mantle-api-days-before-launch/1100-6417917/
First BF4 delay, now Thief Mantle patch delayed? Is it the games causing problems only, or is mantle difficult to use?

http://www.extremetech.com/gaming/175881-amd-mantle-benchmarked-the-biggest-innovation-in-gaming-since-directx-9
3-5% on gpu gains, and avg 7-12%. 15-20% in extreme corner cases. I don't see the point in wasting any dev time if this is the best you get. Why bother with quotes like this from AMD?:
"We spoke to the chief architect of Mantle, Guennadi Riguer, who told us that the GPU-specific improvements from porting a game to Mantle are typically 3-5%, as AMD has previously stated. A developer who aggressively optimizes code for Mantle may see better gains of 15-20% in extreme corner cases. The implication is that moderate optimization will yield gains of 7-12%."

Worse even AMD won't say it's easier on consoles:
"We’ve speculated before that it might be easier for console developers to bring projects to Mantle than to port them to the PC version of DX11, but Riguer didn’t give us much detail on whether or not this is true. Mantle is apparently “arguably” close to console development environments (in Riguer’s own words), but the architect stopped short of declaring that this gave AMD a major advantage."

"Arguably"? Wouldn't call it a AMD major advantage? Wouldn't give details? So nothing to write home about then right? If it was very good, you wouldn't mind spitting out details would you? How much can you dodge before we all realize it just is NOT as good as they claimed? Anything under 20% I get in 1-2 driver updates that affect massive amounts of games. Mantle requires WORK for every game. I'll take better DRIVERS please. Nix Mantle. It would appear AMD went proprietary (it is until it's shared working on NV/Intel) while Nvidia went OpenGL/DirectX for everyone.

http://www.extremetech.com/gaming/175881-amd-mantle-benchmarked-the-biggest-innovation-in-gaming-since-directx-9/3
"results weren’t encouraging."

That's a feb 3rd article. It seems star swarm was made to showcase Mantle (they called it a demo and beta, we'll see if the game actually scores well at some point I hope), while BF4 isn't too impressive. Basically 10%. Worse, the A10-7850 ($185 newegg) + Radeon 290x is far slower than cheaper Intel 4330+290x ($135). So save $50 and blow away AMD combo. That's not good right? Mantle vs. Directx, still loses by 10%...LOL. If you run mantle on both it loses by 20%...ROFLMAO. That's a major failure right? So save $50 over AMD and beat them by 20% running mantle on both sides? The only good stuff I've read so far are just "PROMISES". This info is verification of the ONLY dev to open his mouth a while back saying it "is not unreasonable to get 20%". We would be FAR better off if AMD dedicated ALL Mantle resources into just plain drivers that work with ALL games. Spending money on Mantle, is clearly a waste unless you're a corner case.

It costs more to get yet another API working (mantle) where the other guys only need OpenGL/DirectX (amd adds Mantle to that list). The only question is who wins with OpenGL vs. DirectX. With it already being in OpenGL it would seem AMD announced first but really wasn't first. Mantle=beta, while OpenGL is not. We'll have to wait for the first OpenGL game that has this stuff inside to see if it has the same crash story, delays etc. I'm not aware of any games using this in OpenGL yet, surely they'd demo it during GDC 2014 if there is a game using it on OpenGL.
 
Good on AMD!They have kicked the other guys in the butt, making them implement changes game devs have been asking them to implement for years now. It has also restored some of my vision of AMD as more than just a reactive company going for the lower-end dollar, and not competing at the top, not innovating, at least in areas I'm interested in. (That being said, tests of the first releases of Mantle shows it greatly benefiting low-end systems but not it isn't helping much in computers with serious CPU power. Overall it's a good thing, but may not be as good as I hoped. Of course a lot of that depends on what developers do with it - Mantle can only give them the tools, it can't build the games for them. :) )
 
Making lower level accessible is only a first step for Mantle. It'll only get better from here, and considering it's AMD's own for its own chips and architecture, I think it will continue to have a leg up over Direct X and OpenGL in specific areas.
Click to expand...
I really hope you're right, and that developers won't be put off by the fact that they would have to code their games twice, DirectX and Mantle. I'm looking forward to more games now that developers have a much more easier method of porting console games.
 
Except we don't. We still have to support multiple vendors (NV, Intel) and older HW (=> Direct3D or OpenGL). Nothing has changed.

 
And what will the new low-level implementations be based on? Usually programming languages are heavily derivative. There's a good chance that they will use some of the ideas from Mantle
 
Direct3D 11.x (from Xbox One).

 


But PS4 uses OpenGL and has sold (so far) about 2x xbox1. Also I'd think as a game dev, if you have a shot at openGL which is easily ported to elsewhere (as everything runs it), you would avoid DirectX. I'm guessing dev's would rather have PS4 win the race based on that. If both options can do what you want to get your game done, you go with the one that is easiest to port to mobile etc. I think DX is dead as windows slowly gets smaller market share. They already lost 21% of ALL notebooks in 1yr, and desktops/servers are next (as A57/64bit/huge memory/psu's/discrete gpu comes to ARM's side just like regular PC's). People will go OpenGL for AAA stuff, and HTML5, Java, WebGL etc for smaller casual stuff probably. Apple is OpenGL also, so add that as a 10% PC market that runs NO directX already, 21% of notebooks that left WINTEL, and we've yet to see how much damage A57 will do once in a box with a REAL PSU and all that comes with being OFF battery 😉

I'm must admit I'm excited, even if it means learning more about an OS or two not related to my day job. I'm a bit tired of Wintel pricing :) I can easily learn an OS if it starts saving me $100-200 on cpu each upgrade and the OS is free always 😉 Not to mention the other OS's don't take 20GB+ to install. I imagine all will be bloated at some point, but I'll take light OS until then if given the chance. I won't be getting rid of my WINTEL box any time soon (though many will be able to, I'm just stuck on the IT treadmill probably long term), just saying...
 
I love how it went from all AMD fan boys saying that MANTLE is the second coming of Jesus to.......well they knew that MS and OGL would counter and win anyway they just did mantle to get MS and OGL off their asses.....lmao.... You really think that? Just because AMD is trying to spin it that way? Some of you will believe anything......In reality they thought they could catch the sleeping Giant off guard and score a lucky win, else they would not have poured millions of dollars (which they do not have) into it not to mention 2 to 3 years of of dev time!!!, but knew they could possibly lose so they did what all LOSERS do.... They start the PR campaign saying "Yea we knew we was going to lose but we picked the fight with the big bad bully anyway"........Come on if you guys do not see that you are blind Fan boys indeed........
 
Actually, it is not THAT easy to port applications between platforms even with OpenGL. If you intend to support multiple platforms, the best way is to use a multi-platform 3D engine (like Unity or UDK). And they support both Direct3D and OpenGL anyway. There are other reasons as well - you can read my comment about that (scroll up a bit).
 


Agreed that an engine is the best way, but Trine2/Serious Sam2 took 2 weeks to port to mobile and most of that time was spent on mapping to gamepads etc. Even if you use an engine, you don't just get a FREE port to mobile or PC. There is work to do to get something to run on mobile that is made for PC etc. I have never heard of a directX game getting ported in two weeks (or 4 days for unreal engine to run on browsers) to anywhere else. That takes months or maybe a year or longer for some stuff to get developed. They basically make two games at the same time (except for the graphical assets that go between both). I believe all the SSam games were made OpenGL but DX got added so that may be why it was so easy (and possibly why they picked it, or just experience with the engine/croteam), but I haven't seen DX pull this quick port stuff regardless.

If you make a game designed for DX first (engines notwithstanding) it isn't a piece of cake to get it anywhere else. OpenGL doesn't have that problem, you can ignore engines and still port easily. With DX you probably are forced into choosing a mainstream engine (if porting it is the goal) which isn't always a good fit for every project. Like the StarSwarm game engine (nitrous) is made for throughput etc. Let me know when someone ports a PURE DX game to anywhere in under 2 weeks 😉 You can say porting to anything isn't "THAT" easy, but clearly it's "EASIER" right? 😉 That being said any small dev should just use off the shelf engines until they have a hit that allows in house stuff. It's just too easy to go Unreal/Unity etc and you don't pay for the engine until you publish the game. You can dev free all you want without wasting millions on an IN HOUSE engine and the time that takes. I expect lots of unreal mobile games soon :) Which will cause me to finally buy something decent to play them on mobile 😉

I can't wait for a K1 shield or K1/M1 tablet at 1080p (higher kills games fps and features, 1600p on a tablet? ROFL, my desktop can't do that efficiently at a few hundred watts). Xbox360 still has OK graphics to me and as long as they're fun I'll play. I'm more GAME PLAY than graphics always. I expect them to concentrate on the FUN part rather than glitz since the glitz can't be done at 1080p on a SOC yet and I LOVE THAT. If you give them massive graphics power they tend to spend time using it rather than the FUN part (sex sells, unfortunately so do graphics...LOL). I kind of like that mobile forces them to make a game FUN since the gpu holds back wasting a year on making things PRETTY. You can't do pretty so you have to give me FUN to get me to buy it.
 


But we do. Mantle is very, very similar to PS4 and Xb1's API, so it's going to be a lot easier to port games. AMD said they're going to release SDK for Mantle, so I hope Nvidia will hop onboard, and people with older will have to upgrade to at least the 7xxx series cards to play new games. It's just like they would have to buy a new console to play the new games.

My concern is not the porting process of console games, but Nvidia's involvement. If they don't follow suit, AMD's cards are going to retail for much more than the already ridiculous prices now. Still, the Star Swan demo's given me new hope for the PC gaming industry.

 
Almost right. Serious Engine 2 was actually made with multi-platform support right out of the box. So it was relatively easy to port it to any platform (and more expensive to develop).
The point is when you make a new game for a certain platform (bcs. you can't invest man-hours into creating your own multi-platform engine), it will be hard to port to other platforms regardless of the API you choose (unless you only use basic effects). Bcs, if you want to support multiple platforms, you really need rendering modules as a layer of abstraction above the actual API (which means you are building an engine and creating your game on top of it).


We don't. I doubt you got the point. It does not matter if Mantle can be used to port games from consoles. It only works on GCN. That means only a tiny fraction of GPUs is supported even if NVidia implements a Mantle driver. Which means you need to support the rest of GPUs (with DirectX or OpenGL). Therefore, nothing has changed in the porting department.
 


http://www.extremetech.com/wp-content/uploads/2014/01/DXDrawCalls.jpg

Except you forget that Mantle is also the driver. Mantle extends deeper down than you think.

Look, it's like this. When both Nvidia and AMD make a GPU, they give it an instruction set that is capable of doing certain calls natively and other calls non-natively (by following a non-accelerated pipeline, I.E doing a set of other slower instructions to achieve the same effect in software), hence AMD GPUs being far better for bitcoin mining for example (the particular call that relies on is non-native on Nvidia silicon).

Now I know for a fact that Nvidia at the very least tailors its calls specifically to Direct X and OGL. I mean why wouldn't it? GPUs are made almost specifically to run games and they are ASICs for DX and OGL in that respect. Sure we have compute but that still plays second fiddle in most situations.

Now the only reason I would say that GCN would be the deployment target for the first releases of Mantle, and not an even smaller pool of GPUs for example, would be that GCN has an extended native instruction set for the purposes of Mantle. This would make a lot of sense and explain the reason why Mantle is also a Driver (because the current driver lacks the complete instruction set). AMD would be able to release mantle to the public so a Mantle game can run on all platforms, but nobody else would ever be able to really match a GCN board for this gen at the least. AMDd could then progressively write software solutions for some of those calls to add support for a select set of older cards, or not. Others could add support in software but never as fast as Mantle, as the driver isn't open source and the GCN arch definitely isn't. Probably much faster than High level APIs though.

By using software everyone else can add Mantle instructions to their hardware, and people like MS would have to expand their instruction set or IDE to support it, something that could take years. It would be the GPU equivalent of dropping x64 on the world, but with bigger benefits so the need for faster conversion.
 
Matle is an API that uses the Mantle Driver exactly as I said. Same as Direct3D is an API that uses the Direct3D driver (from Catalyst/GeForce driver install). The difference is (as I said) that Mantle is tailored for GCN => requires less abstractions => less overhead. The same way that Direct3D 11.x is tailored for Xbox One and has even less overhead.

No. Crypto-currency mining (and also media processing and content creation) is heavily dependent on the computing core's IOPS (integer operations per second). 3D graphics require fast floating-point operations. It was AMD's design decision to make their GPUs more general-purpose. It has nothing to do with native or non-native calls.

That kind of defeats the purpose of Mantle. It is supposed to be a lightweight API. What you are describing here is what OpenGL and Direct3D is doing now.
Also, you do not seem to understand how things work with APIs, drivers and GPUs. Since you talk about expanded instruction all the time... Mantle is radically different from DirectX and OpenGL - it is a completely different programming model (which I like, personally - but that is irrelevant). Simply put, it's a different approach to working with a GPU - more control, more low level, more opportunities to shoot yourself in the leg. For example you can use DMA transfers, monolithic shader pipelines, compute engine, etc. queues directly from Mantle - which means you could have crossfire rendering solution that does not mirror resources, for example (pretty cool but also possibly pretty risky).

FYI I do this for a living. If you honestly want to learn about Mantle, you can register with AMD (you must be a developer), sign an NDA and they will send you a password to access Mantle information directly from AMD. You won't be able to talk about it (except the stuff that's already public), but at least you won't be spreading misinformation.
 



You're spot on the money. That's exactly why Mantle is faster: Less abstractions. Nvidia has a 'proto' mantle too, NVAPI, but it does not expose as much as it needs to to develop exclusively on NVAPI. Thing is, who do you think is better at tailoring a driver for an AMD card? AMD or Microsoft? Lest we forget that it's very likely that GCN was tailored for mantle as much as mantle was tailored for GCN.

Also, as has been stated many times by people like Carmack, et al, you might be able to make DX11.1 run super fast on Xbone using low level commands, but when you start trying to do that on PC, you end up with very unhappy end users and a lot of blue screens as they don't translate across configurations well at all. Please elaborate on why OGL has apparently been able to solve this so quickly and AMD have not even able to finish their fist base subset?




http://www.extremetech.com/computing/153467-amd-destroys-nvidia-bitcoin-mining

VLIW design was not a factor until well after the lack of native BIT_ALIGN_INT op support was, as for the IOPS comment, you are basically repeating me but with different words. The speed of a processor at completing a task depends on how many clocks it takes to complete that task, and that depends on how native and un-abstracted the operation is.

"The first reason AMD cards outperform their Nvidia counterparts in BTC mining (and the current Bitcoin entry does cover this) is because the SHA-256 algorithm utilizes a 32-bit integer right rotate operation. This means that the integer value is shifted (explanation here), but the missing bits are then re-attached to the value. In a right rotation, bits that fall off the right are reattached at the left. AMD GPUs can do this operation in a single step. Prior to the launch of the GTX Titan, Nvidia GPUs required three steps — two shifts and an add."

Look, I could argue with you till the sun goes down, but it will make no difference. You are of the opinion that you are correct, and I am the same. Just like those guys who say that a 6 core processor is a pointless expense for gaming, we will have to and see what happens.
 
Not sure if you got it, but I am talking about D3D 11.x - that is a version od D3D that runs on Xbox One (it has more features than 11.2).

Solve what? Driver overhead? Both D3D and OpenGL have been improving driver overhead with every iteration of the APIs (+ you can use OpenGL extensions with practically no overhead - they don't cover everything, though). If you mean porting, then even OpenGL feature support across platforms is far from uniform...

AMD GPUs have more (slower) ALUs that give them over 3-5x (IOPS) performance boost in mining.
BIT_ALIGN_INT is an AMD ROR instruction that performs these operations: (a >> n) | (a << (32 - n)) in one cycle, which compiles to 2 instructions on NVidia GPU (SHR + ISCADD, if you use constants). SHA-256 uses ~560 of them (out of ~3300) per chunk, which equates only to about 1.7x performance boost - quite insignificant compared to pure IOPS.
edit: I have just read the article you quoted... If only you had read (and understood) the whole first page (esp. the last paragraph). They say HD 7970 can execute more integer operations than the Titan. They also mention the SHF (funnel shift) instruction that takes care of ROR on a Titan and other sm_35 GPUs (didn't know that as I only work with sm_3- GPUs where ROR compiles to 2 instructions, see above). So the article supports what I've written above (and before).

Your problem is, you are obviously not a programmer and you're probably confused about some of the terms you use... Even though you may arrive to the same conclusions, the understanding of the information that led you to them is flawed/wrong.
The performance of the processor is dependent on its IPS (how many instruction can be executed per second). Instructions perform certain operations. Different CPUs can have different instructions performing the same operations. Using these instructions efficiently is called optimization. Native or abstract terms have no place here...
You can directly execute instructions using the assembly language. Programming languages compile the code into instructions for a specific platform. Higher-level programming languages optionally compile code to an intermediate language that then gets (JIT) compiled to instructions during execution of that application.

This subject is not a matter of opinion. You are simply wrong. I know what I am talking about and you are just parroting (your interpretation of) articles you find on the internet. I can implement the algorithms and see for myself and you can't, etc. Do yourself a favor and do not to argue about things you have little to no knowledge (let alone experience) about.
 


Understood, from what I know 11.x is virtually identical to Mantle.



No, not driver overhead, platform diversity. We both know that low level programming has always existed but the main issue is how it works when you remove it from the test system and bring it to other machines, particularly when most GPUs use different internal architectures. There's no formalization across hardware itself. Did OGL go out there and write adapters that translated low level extensions on a case by case basis, accounting for all the quirks of every piece of hardware they deploy on, because I thought that was such a gargantuan task that it was the very reason Low Level Programming had been ignored for the last decade on everything but consoles.

If not then the question would be why has nobody done this since the days of Glide?



That is true. It is why I mentioned VLIW design. I was trying to brush aside the other (irrelevant to the subject matter) performance advantages for a second to look at the lack of Nvidia's ability to do the same instruction in a singe clock. That is what I am talking about when I say native vs non-native. Nvidia obviously does the command in micro-code and AMD completely in dedicated hardware.



I am not a programmer, not in any languages where this info is needed anyway. I script. My terminology is probably wrong because I did not school for this. What I am talking about is the realm of a hardware engineer not a programmer, unless they program FGPAs for a living. I am not talking about IDE compiling. I am talking about actual, on die, microcode vs hardware execution of those instructions, well after that. I was saying that in the realm of OGL, without seeing which new instructions will be exposed by the Mantle drivers, there is no way to definitively say that Mantle can be matched by current native OGL. If Mantle did not expose new instructions, or significantly change the current drivers in some way, there would be no real need to advertise the "Mantle Driver" as different to the current Catalyst Driver.

By extension of that, I cannot really think of any reason Mantle would only be for GCN chips, but at the same time be released to the public with source, unless AMD wanted to introduce a paradigm shift on the entire way the industry makes it's GPUs, and at the same time get a generational jump on the competition.
 
Yes, they did (kind of, the extensions are actually made by third parties and submitted to OpenGL). NVidia has its own extensions, AMD has its own extensions, Intel ... (for example: GL_AMD_occlusion_query_event, GL_NVX_gpu_memory_info). And you are correct, that is one of the reasons why not every feature of each GPU is covered and why extensions are not used that much (IMHO).

It's only true for sm_30- cards. The article you linked mentions the SHF (a ROR) instruction that sm_35 NVIDIA GPUs implement. So, 7970 and Titan are equal instruction-wise - both will perform ROR in 1 instruction using likely similarly performing microcode (HW-layer instructions that actually implement these higher level instructions accessible to programmers). So the first sentence is correct (for sm_3- GPUs) but the other one is not.

Drivers do not expose instructions, they expose functionality. Mantle cannot be fully matched by current OpenGL (in some areas, it can be matched thanks to current extensions), it can be fully matched by future OpenGL extensions, though. The "Mantle Driver" exposes functionality that closely matches GCN (as described earlier).

Mantle can be used with other architectures (as mentioned earlier), BUT, it would be harder to implement as it would not exactly match a different architecture (also mentioned earlier). So, there would be overhead (or Mantle Extensions would have to be used, increasing complexity and general crappiness). The implications of these facts are subject to opinion. Will NVidia implement Mantle? I doubt it, but who knows...
 
Can we generalize the strategies of the GCN core from AMD similar with CUDA core from NVIDIA?

I'm assuming the card from amd years to come will be GCN based........
(It seem to me they betting all on GCN)
 
That's what APIs (and drivers) are for (like Direct3D). On a very high level, all modern GPUs are the same - that's why you can use HLSL (they all have shaders) and rendering methods (all have rendering capabilities). The lower you go, the more architectural differences there are. At a certain point, you can't generalize.
The point of Mantle is that it is a thin abstraction (close to the GCN HW) - NVidia would need a thicker layer of abstraction => more overhead => less performance (however slight the difference might be). So NVidia would be at a disadvantage, unless AMD makes Mantle truly open and works directly with NVidia (and other manufacturers) to find the common ground where everyone gets similar performance and we all know how "well" it went with the Khronos Group's OpenGL. Microsoft can do the same with Direct3D, though (and they will, since some features of Direct3D 11.x are coming to desktop D3D).

That is a reasonable assumption.
 


Funnily enough, you have actually disproven nearly everything I have said whilst successfully proving everything to be to the same effect. OGL does do low level programming, but it has patchy hardware support and different instructions for every brand of hardware to do tasks so is rarely used. Mantle would not, in fact the only reasons to use the OGL instructions would be memory protection style stuff right? DX 11.x is not on anything but the Xbone so that alls to the wayside too.

Face it, to me the only deployable API that does low level programming would be Mantle if it was adopted universally. Until then we will be waiting on 'supports this but doesnt support that' style patchyness that brought us to using high level languages in the first place.

In direct response to the quoted comment, and as I mentioned earlier, current GPUs are DX and OGL optimised, so should Nvidia want to implement Mantle, I would want to re-optimise my architecture to that end. You can bet your bottom dollar that would mean full mantle instruction support. As Nvidia, even if I did this for the 8XX GPUs by some miracle, I would still be 2 generations behind AMD on Mantle support.

Now if Mantle was arranged the same way C++ was: as a relatively low level language that comes with libraries to automate repetitive or complex tasks and/or even emulating DX or OGL higher level instructions, I could really see it surpassing OGL and DX in usage just because of granularity.
 
That is a really huge IF. Mantle, Direct3D 11.x and OpenGL-SCE all currently work only on one platform. From that perspective, they are pretty equal... We'll see what really happens soon enough (I am pretty sure it won't happen).

Not to mention that NVidia's roadmap is already set. Maxwell is out now and Volta is currently being worked on. So, being optimistic, NVidia HW support for Mantle could start in about 2017 (but I seriously doubt it will).

Again. That defeats the purpose of a low level API. Also, that is a bad example - if you want to compare Mantle to anything, compare it to a design pattern (or other APIs), not a language.
Mantle will not surpass OpenGL nor Direct3D. As I said earlier, it does not even compete with either of them (check the link for more info).
 
Status
Not open for further replies.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom