AMD Mantle API [updating]

The scenario I'm thinking of is using whatever path Mantle uses to allow for low-level feature exposure to create a fake DX11.x device that can run on any OS version that GCN can be installed in.

I'm not sure if the DX11 platform holder would appreciate it, or if the performance or reliability would be there.
 
Interview with Dan Baker from Oxide
http://www.gamesindustry.biz/articl...hooter-mold-how-oxide-plans-to-revive-the-rts
Dan Baker said:
You'll see people misrepresenting that AMD's pushing this technology, but the reality is that a lot of people - including myself and other graphics architects - have been asking for this type of thing for a long time,

"I don't think it's anything like Glide. Back then, the hardware had a lot of very specific variations," said Baker. "While there were advantages to doing that, it was because the hardware wasn't very programmable. A modern GPU is really just a processor; they're so programmable that the analogy doesn't hold up anymore."
 
so mantle is not a propriety api because gpu's are so programmable and they dont have a lot of very specific variations - what nonsense
 
Surely the big news in that is that they had an alpha version of Mantle for at least a couple of months and likely a bit longer than that. I was under the impression that it was only DICE who had it so far.

I can't wait to get the whole background on this, hopefully we'll get an article like we got with the RV870 story on Anandtech telling us about how Eyefinity came about. I wonder what codenames they were using this time.
 
so mantle is not a propriety api because gpu's are so programmable and they dont have a lot of very specific variations - what nonsense
I think you jump to conclusions and may have simply misunderstood what he wanted to express. But the article doesn't make it easy by not giving more context to his statement.
My interpretation would be, that he wanted to make a distinction between Glide and Mantle regarding the longevity or sustainability of the support on future hardware. Back in the days, Glide basically tied you to certain low level paradigms, how some stuff has to work. Newer hardware broke this, so Glide support would have been hard to impossible. In his opinion, Mantle doesn't do this (to the same extent). It just gives you more direct access to the hardware, what you do with that, is up to you and not restricted by Mantle.
 
The scenario I'm thinking of is using whatever path Mantle uses to allow for low-level feature exposure to create a fake DX11.x

Today's game 'engines' (imho those huge amount of code are anything but "engines" any more) are already "modularized", since you usually have OGL support & likely a Platform Dependencies folder for different OSes.

You just overload your classes with a different physical class that implements what you want to do in Mantle, I think (well, mostly).

The interesting bit is imho not really supporting Mantle but taking advantage of its advanced feats.

For some advanced thing it may require to add some special function in your code to handle special feats...
...but maybe the beneficial effects are really visible immediately, given that i.e. your game may support more calls/faster returns, issue more shaders etc.
 
Today's game 'engines' (imho those huge amount of code are anything but "engines" any more) are already "modularized", since you usually have OGL support & likely a Platform Dependencies folder for different OSes.

You just overload your classes with a different physical class that implements what you want to do in Mantle, I think (well, mostly).
I'm talking about presenting a virtual DX11.x device to an application so that it can run its standard unmodified DX11.x graphics code path up to the version supported by the card, regardless of the DX version the system's Windows installation supports.
It would have to lie to the application and the OS. A multipath engine that isn't spoofed will use the render path compatible with Windows instead of the Mantle path.
Additionally, I expect the Windows runtime would not like getting commands for the wrong revision.

Getting around that is likely too fragile and performance-killing unless it's a very undemanding application.
Given the breadth of other functions encapsulated by DX11, it may not work because functions that fall outside the purview of Mantle might get called because the engine thinks it's in a fully DX11 environment.

Perhaps there are intermediate solutions where applications can be modestly patched to support Mantle, although many of the likely benefits won't come to pass without rearchitecting the engine so that it can take advantage of the access.
 
Perhaps there are intermediate solutions where applications can be modestly patched to support Mantle, although many of the likely benefits won't come to pass without rearchitecting the engine so that it can take advantage of the access.
Johan even said as much on twitter. There's no "free ride" to be had here for games... that would imply that the current DX drivers/runtime is just poorly optimized at a basic level, which is not the case. The model itself needs to change and compatibility for older devices needs to be dropped to move forward here, which is what Mantle is trying to do. Honestly it's going to require OS work above and beyond Mantle to happen in the long run as well, but I imagine they're just taking a first step.
 
I'm talking about presenting a virtual DX11.x device to an application so that it can run its standard unmodified DX11.x graphics code path up to the version supported by the card,

ye but... why? Even indie engines support multiple gfx devices, why would you ever need to do that?? :???:
Apart Wine-like exercises, I cannot see the point.
In current-gen game engines is likely more easier to rewrite your low-level classes, than go on some fancy emulation.
As far as I am aware of, this is how the support is implemented (this and your #ifdef friend...).
 
The goal would be to allow any DX11 render path to run unmodified on any Windows installation, regardless of whether said engine was that flexible, or even if the developer is still around to patch it.

The fragmentation Microsoft has introduced in Windows graphics API revisions being tied to OS revisions would be bypassed.
It would have mattered more if it came about in the XP/Vista transition, although we seem to be getting at least a partial taste of it again with Win 8.1.
 
I think you jump to conclusions and may have simply misunderstood what he wanted to express. But the article doesn't make it easy by not giving more context to his statement.
My interpretation would be, that he wanted to make a distinction between Glide and Mantle regarding the longevity or sustainability of the support on future hardware. Back in the days, Glide basically tied you to certain low level paradigms, how some stuff has to work. Newer hardware broke this, so Glide support would have been hard to impossible. In his opinion, Mantle doesn't do this (to the same extent)

Sorry dont agree. Glide tied you to very little, and "newer hardware broke this" ??? It didnt, v2, v3, v4 and v5 all supported glide. Thats 5 generations, and had 3dfx survived theres no reason to believe glide support wouldn't of been possible hell creative labs even released a tnt2 that ran glide games (creative unified).
In fact every card released after the v5 can run glide games via a wrapper.
As for mantle not tying you to hardware your joking right? its very much tied to gcn. What happens after gcn will we have mantle 2.0 will 2.0 support amd's new architecture and gcn ? what happens several years down the line when mantle will have to support 3 or 4 different amd architectures ? or will it be mantle 2.0 for amd's current arch and d3d for gcn and earlier ???
 
The goal would be to allow any DX11 render path to run unmodified on any Windows installation, regardless of whether said engine was that flexible,

:oops:
...why someone should spend way, way more than 10M$ to do that????

DX is not a thin layer over your GPU: a thin layer would i.e. allow your game to simply put (more or less) a command packet for DMA selecting i.e. tile mode (etc) in your command buffer -possibly without leaving UMD- without the burden of God-Knows-What.
DX is quite a thick layer, imho.
 
Sorry dont agree. Glide tied you to very little, and "newer hardware broke this" ??? It didnt, v2, v3, v4 and v5 all supported glide. Thats 5 generations, and had 3dfx survived theres no reason to believe glide support wouldn't of been possible hell creative labs even released a tnt2 that ran glide games (creative unified).
In fact every card released after the v5 can run glide games via a wrapper.
Yes, via a wrapper, which is exactly the problem. I think I remember that someone said Rampage would have supported Glide also only with a wrapper as it didn't map that easily to more modern hardware. Of course, usually more modern hardware can reproduce everything older hardware is capable of, but one loses the advantage of using the (now emulated) lower level access. So why use it at all?
As for mantle not tying you to hardware your joking right? its very much tied to gcn. What happens after gcn will we have mantle 2.0 will 2.0 support amd's new architecture and gcn ?
I'm not joking at all. Mantle is probably tied to some mechanisms for instance how command buffers are handled, how they are passed to the GPU and the GPU delivers feedback, maybe even the command buffer format itself (but that is not necessary). It is probably not rigidly tied to the actual underlying ISA. As long as the essential principles hold, one could probably swap out the ISA of the GPU even with Mantle (all one has to do would be to [re]compile the shaders to the ISA and maybe build the command buffer in a different format [Mantle could abstract that too]).
[edit]And AMD is on record that future architectures (GCN2.0 if you want) will support Mantle too_Older Mantle games won't be able to use new features of course, but it will be compatible.[/edit]
If you want, the Mantle basics are more on a meta level than the ones of Glide, which didn't map in an advantageous way to more modern hardware at some point (because it was basically all fixed function at that time). But as we have read in that quote, GPUs are largely programmable processors now with some fixed function units helping in a few places. One just needs an efficient way to tell a GPU, what to do. That's what I think Mantle is mainly about. But we will know more next week.
 
Last edited by a moderator:
:oops:
...why someone should spend way, way more than 10M$ to do that????

DX is not a thin layer over your GPU: a thin layer would i.e. allow your game to simply put (more or less) a command packet for DMA selecting i.e. tile mode (etc) in your command buffer -possibly without leaving UMD- without the burden of God-Knows-What.
DX is quite a thick layer, imho.

The reason I gave was that it would allow AMD cards to be the DX11.x cards that would be DX11.x cards on any Windows version they can be installed on (or not even Windows, but I'm not getting into that).

I've already pointed out that it would likely be too fragile and costly to implement.
However, if the hypothetical driver bypass (edit: and GCN) could have been pulled off at the XP to Vista transition, AMD cards would have had a unifying position across a discontinuity in DX support that damaged PC gaming.

I'd imagine the marketing tagline of "GCN, the only gaming architecture Vista can't screw up" would have helped garner quite a few sales a few years back. Many gamers that stuck to XP for a long time would have had GCN as the go-to hardware.
If it had become common enough, that would have more quickly deprecated the older DX versions and reduced market fragmentation.

Since DX11.2 appears to be introducing a similar--albeit smaller--break, we don't see a guarantee it can't happen again.
Unless Mantle gets Microsoft to integrate a standard bypass, that is.
 
Last edited by a moderator:
Today amd apu 2013 begins, i can't wait to learn more about Mantle, but I'm afraid we have to wait the 13th...
 
The reason I gave was that it would allow AMD cards to be the DX11.x cards that would be DX11.x cards on any Windows version they can be installed on (or not even Windows, but I'm not getting into that).

This isn't possible, because DirectX11 is more than simply the D3D subsystem. Sure, it might be academically possible to build some "DX11-wrapper" using Mantle and some hackery. However, the entire gammut of DX11 is bigger than that, and Mantle is simply not far-reaching enough to cover the rest of the DX11 API calls (sound, input, video compositing that isn't 3D, utilization prioritization of multiple contexts.)

DX10 and later were a break not only in 3D capability, but the entire underlying input / output architecture that underpins sound recording and playback, video rendering (in two and three dimensions), and input. Building a wrapper for the 3D part and calling it "done" is missing the much larger picture.
 
Today amd apu 2013 begins, i can't wait to learn more about Mantle, but I'm afraid we have to wait the 13th...

Just check the program of sessions on AMD sites.. then you have the date where this is about Mantle.. ( outside if there's some particular non official presentation, talk etc )
 
This isn't possible, because DirectX11 is more than simply the D3D subsystem. Sure, it might be academically possible to build some "DX11-wrapper" using Mantle and some hackery. However, the entire gammut of DX11 is bigger than that, and Mantle is simply not far-reaching enough to cover the rest of the DX11 API calls (sound, input, video compositing that isn't 3D, utilization prioritization of multiple contexts.)

DX10 and later were a break not only in 3D capability, but the entire underlying input / output architecture that underpins sound recording and playback, video rendering (in two and three dimensions), and input. Building a wrapper for the 3D part and calling it "done" is missing the much larger picture.

He's probably thinking more along the lines of allowing DX11.2+ features on Win7 rather than DX10+ features on XP. Mantle should be able to accommodate that.
 
Back
Top