AMD Mantle API [updating]

The question I would like to ask is, why didn't AMD just do that in the first place instead of going the Mantle route?

Why not? Bindless is about using few "larger" draw calls and part of Mantle is about processing many draw calls faster. Who's to say which approach will ultimately be better? Perhaps they can even be used in conjunction to some degree. These are uncharted waters.

And as 3dilettante notes, just because an extension is available, doesn't mean it'll get used. I believe nvidia's blindless extensions have been out for a year and what do they have to show for it?
 
If Mantle is a true low-level API then bindless resource use is just one aspect of it. Using extended OpenGL makes sense if you still use large parts of the core functionality, but if at some point you're finding yourself mostly using extended functionality you might as well drop the baggage that comes with the higher-level concepts. (And that's not just true for applications. Making extensions play nice with everything else can be a significant specification and implementation burden.)
 
Isn't there some degree of expectation that an extension now is part of the API in 2-3 years' time?

So a developer can play with an extension, tacking it on to a game. And in the next major iteration of their engine, make that extension, which has hopefully gone native, a key feature of the graphics engine?

Also, what I don't get is why people think bindless textures are a big deal. PRT is the real deal, bindless is just a sideshow. Especially since PRT is a feature of the new consoles.
 
You mean AMD's sparse texture extensions that are already present in OpenGL, or the DX11.2 Tiled Resources that Microsoft is reserving for Windows 8.1?

The fragmentation of the market and extra dev work that can happen with manufacturer-specific APIs is a negative, but it's not quite as bad (relatively) when the standard API holder is already doing it.
If Microsoft has another tablet or form factor to drag the userbase to, it might strand functionality across multiple sectors of the no longer monolithic PC base.
 
Also, what I don't get is why people think bindless textures are a big deal. PRT is the real deal, bindless is just a sideshow. Especially since PRT is a feature of the new consoles.
Bindless is a big deal both in performance (eliminate one of the remaining major CPU state change overheads) and functionality (storing references to textures everywhere... constant buffers, G-buffers, whatever and allowing divergence in references in shaders).

PRT/tiled resources (PRT acronym is already taken dammit! :)) is in contrast far less interesting IMHO. It's a convenience and a slight performance boost for virtual texturing, but the tile sizes and max resources sizes mean that both you can't use it for anything too fine-grained (which would thrash TLBs anyways) and you still need a software solution on top of it. So it basically bumps your borders out to a wider region (since you don't need them in the internal tiles) and handles some granularity of the indirection in hardware. Another thread here had a much better summary of the problems with tiled resources going forward... I'll defer the further discussion to there.

GCN clearly can support bindless as well, so I expect folks will eventually start picking it up on the consoles. Just too few people realize how big a deal it is so far and thus it has been overlooked :)
 
Consoles drive game technology and the performance of bindless is already there. And the extra functionality you refer to is an open field already under exploration. Remember a lot of the pressure for Mantle comes from working with hardware bound by a much less restrictive API.
 
Consoles drive game technology and the performance of bindless is already there. And the extra functionality you refer to is an open field already under exploration. Remember a lot of the pressure for Mantle comes from working with hardware bound by a much less restrictive API.
Even if you had zero-overhead binding, bindless would still be useful. Like I said, there's no other way to get lane divergence, indirect binding lookups (store in arbitrary data structures) and arbitrarily many bindings without it. Not sure what you mean by an "open field already under exploration"... there's clearly useful stuff to do with bindless, I don't think any of the developers I know dispute that even if they simply haven't thought about it much yet.

That said, even on consoles binding textures is not zero overhead, and bindless lessens the need to sort by texture references, which is not always desirable across multiple binding points.
 
You mean AMD's sparse texture extensions that are already present in OpenGL, or the DX11.2 Tiled Resources that Microsoft is reserving for Windows 8.1?

The fragmentation of the market and extra dev work that can happen with manufacturer-specific APIs is a negative, but it's not quite as bad (relatively) when the standard API holder is already doing it.
If Microsoft has another tablet or form factor to drag the userbase to, it might strand functionality across multiple sectors of the no longer monolithic PC base.
Actually the whole X86 world starts to look messy, GPU are one thing but CPU on the other hand...
are worse, AMD is no longer up to date with Intel last vector extensions, actually Intel is making a good job at creating segmentation on its own with their low end CPU and their "disabilities".
 
Actually the whole X86 world starts to look messy, GPU are one thing but CPU on the other hand...
are worse, AMD is no longer up to date with Intel last vector extensions, actually Intel is making a good job at creating segmentation on its own with their low end CPU and their "disabilities".

At the end what matters is the amount of FLOPS the given processor can do. Most differences between the vector extensions can be abstracted away with only a minor performance penalty.
 
Actually the whole X86 world starts to look messy, GPU are one thing but CPU on the other hand...
are worse, AMD is no longer up to date with Intel last vector extensions, actually Intel is making a good job at creating segmentation on its own with their low end CPU and their "disabilities".

For the market Mantle applies to, the mess at the outer edges of x86 isn't particularly relevant. Most of the machines Mantle will show up on at first will probably have Intel chips anyway.

The question is whether Mantle can make AMD's APUs more compelling by removing a burden on their weakest component, or if AMD as the Mantle provider can somehow tweak its system architecture to make Mantle and its APUs more effective.
It then becomes a question on whether the CPUs aren't too far behind the competition such that even that isn't sufficient.
 
Why bindless textures are being discussed in relation to Mantle? With something like Mantle, you are not limited by slow growth of DX/OGL and can do whatever the hardware is capable of in a more efficient way. Seems like some people are just butthurt that AMD came out with something like this and not Nvidia or Intel.
 
Believe it or not, there are other reasons besides the insulting one that was given.

The value of the standards and abstractions presented by the APIs across vendors should not be underestimated.
AMD wouldn't have the IP or the console wins if it weren't for the multibillion dollar industry that those APIs underpinned. It wouldn't have had the money, the expertise, nor the freedom to have evolved its architecture to this point if it weren't for them.
Notable industry personalities like Sweeney and Carmack had a good chunk of their work facilitated by those standards.
The maturity of the tools and understanding of the art, such as they are, is in part due to that industry doing so much in the common advancement of it.

There is a bit of a faustian deal inherent to breaking from this. It gives a boon, for at least some.
Perhaps that time has come, but it isn't without cost, even for AMD.
We'll have a better idea once Mantle is more fully disclosed.

At this early stage, I would almost wonder if Carmack's less enthusiastic response comes in part from the history of unbelievable screwups AMD has had in terms of drivers and software support with RAGE.
Let's not forget that the ascendance of Mantle has at its foundation the assumption of the effectiveness, support, and stability of AMD's software and development.

Perhaps DICE can speak to the three driver revisions AMD has released for BF4, and EA can evaluate whether that standard-bearer's technical checkbox translates into CoD not making all the money.
The rest of the industry can watch to see whether BF4's Mantle version is superior and stable with the backing of AMD's drivers and the stability record of the Battlefield series.
 
Carmack's less enthusiastic response comes exclusively from his feeling that he is barely involved with programming at this point but is far more responsible for the business side of the company, and that he should therefore take a much more pragmatic view on things. He says so almost literally.

But that he's still strongly interested in the technical sides of things and understand the possible advantage of Mantle then shows in the following discussion, which I think has partly convinced him on the spot that this may be a good idea after all.
 
Carmack's less enthusiastic response comes exclusively from his feeling that he is barely involved with programming at this point but is far more responsible for the business side of the company, and that he should therefore take a much more pragmatic view on things. He says so almost literally.
Yes, a lot of what Carmack has discussed in recent years has revolved around what makes a large team's development process work, in terms of safeguarding the integrity of a large code project, content creation, and making the fruits of that labor applicable to as large a market as possible.

What has been disclosed about Mantle so far is mixed. For the PC, it is another code path to develop (more if Intel and Nvidia do their own), doesn't help content creation, is of unknown quality, support, and stability, and it narrows the market.
For console+PC devs, it could result in a simplification, but this is why Carmack notes the lack of public buy-in on the part of the console makers.

OpenGL's extensions allow for exposure of additional features, and from his POV based on what has been disclosed so far--we see at least one standard capable of getting a significant portion of the benefit without going through all that.
It could benefit the DX realm for feature exposure, but it needs to get buy-in without fragmenting things further.

Performance benefits alone without being of a significant magnitude are insufficient, since many are for trading performance for a more robust development process, and we are facing diminishing returns as far as consumer utility goes.
 
Believe it or not, there are other reasons besides the insulting one that was given.

The value of the standards and abstractions presented by the APIs across vendors should not be underestimated.
AMD wouldn't have the IP or the console wins if it weren't for the multibillion dollar industry that those APIs underpinned. It wouldn't have had the money, the expertise, nor the freedom to have evolved its architecture to this point if it weren't for them.
Notable industry personalities like Sweeney and Carmack had a good chunk of their work facilitated by those standards.
The maturity of the tools and understanding of the art, such as they are, is in part due to that industry doing so much in the common advancement of it.

There is a bit of a faustian deal inherent to breaking from this. It gives a boon, for at least some.
Perhaps that time has come, but it isn't without cost, even for AMD.
We'll have a better idea once Mantle is more fully disclosed.

At this early stage, I would almost wonder if Carmack's less enthusiastic response comes in part from the history of unbelievable screwups AMD has had in terms of drivers and software support with RAGE.
Let's not forget that the ascendance of Mantle has at its foundation the assumption of the effectiveness, support, and stability of AMD's software and development.

Perhaps DICE can speak to the three driver revisions AMD has released for BF4, and EA can evaluate whether that standard-bearer's technical checkbox translates into CoD not making all the money.
The rest of the industry can watch to see whether BF4's Mantle version is superior and stable with the backing of AMD's drivers and the stability record of the Battlefield series.

Im sorry, but for what i know of the problem of rage, this was mostly for a question of some features carmack wanted ( the texture streaming ) and the way he have implement it ( only supported on Nvidia cards, and impossible to use on AMD GPU ( not the way it have been done anyway. ), hopefully the result was so bad on Nvidia cards too.. they have never been able to fix it on any brand. ( When i say Carmack, i mean the developper team ).. Textures streaming is really interessant, but the results was far of what it could, or should have been.
 
Are you talking about the GPU texture decompression that could be enabled for Nvidia cards?

I'm talking about how, as is frequently the case, there was a preview driver that contains fixes for a game that was used for the final development driver and was to be available for download at release.

AMD released a driver with a regression in the OpenGL files, with the accompanying crashes and other problems that caused.
It then made a re-release preview driver.
Then posted the wrong link.
It corrected the link, and then gamers found that it negated the optimizations for BF3.
The latter thing is a little portentious for BF4, don't you think?
 
Why bindless textures are being discussed in relation to Mantle? With something like Mantle, you are not limited by slow growth of DX/OGL and can do whatever the hardware is capable of in a more efficient way. Seems like some people are just butthurt that AMD came out with something like this and not Nvidia or Intel.

Aside from the fact that the first part of your post if rubbish, I hope you can understand why the latter part is not acceptable on B3D. If not, there is this guy named grokzilla I'd like you to meet.
 
Are you talking about the GPU texture decompression that could be enabled for Nvidia cards?

I'm talking about how, as is frequently the case, there was a preview driver that contains fixes for a game that was used for the final development driver and was to be available for download at release.

AMD released a driver with a regression in the OpenGL files, with the accompanying crashes and other problems that caused.
It then made a re-release preview driver.
Then posted the wrong link.
It corrected the link, and then gamers found that it negated the optimizations for BF3.
The latter thing is a little portentious for BF4, don't you think?

I dont know if it can show anything portentious for BF4, maybe for rage2 ..

Its not first and not the last time, you will got a driver ( Nvidia or AMD) who should fix something on a game, and create problem on a second ( preview, beta or WhQL ) . I have not really follow what have happend about this.. on the other hand, the engine of rage was more a problem ( completely bugged on both nvidia and AMD cards at release ). From a developpement point of view, im really impressed by all the features, and new " tech " they have includes in it, but the result is really not at the level of their ambition. Maybe this was too early for use them.
 
Last edited by a moderator:
Personally I think it is a huge part of the problem that GPU makers have huge drivers that contain all sorts of game specific profiles and optimisations. I may be wrong, but it feels like there are too many layers of government and paperwork to make this efficient.
 
Back
Top