AMD Mantle API [updating]

Interesting! Not much technical info wrt DX12 though but can those 'bundles' be per game object? If I have 100 objects in my current fov and the next frame discards 10 but also adds 10 more for example, will I be able to save the cost of resubmitting work for 90 unchanged objects into the command buffer? This can help getting rid of API cost greatly.
 
http://www.youtube.com/watch?v=07-17yAEhnA


speaking in an interview with someone from amd, amd gave microsoft and other partners the full specifications for mantle early on in its development cycle, and dx12 was influenced by Mantle (aka push to reduce api overead was a result of competition from Mantle).

Obviously technically in theory the AMD rep could be being dishonest, ignorant or coming to igonrantly ill informed biased conclusions on this topic, however its highly likely he's not, and is infact well informed knows of the development time lines for the api and is in the social and knowledge circles to know a much clearer picture. Its probably very well known within amd if microsoft and kronos groups push towards low level api was reactionary.
 
Last edited by a moderator:
dx12 was influenced by Mantle
Or maybe PlayStation 1, Atari Jaguar, PlayStation 2, or who knows what.


Exact quote: http://www.redgamingtech.com/directx-12-amd-comment-on-new-api/
RGT: There are many who’re claiming and reporting rumors that MS ‘copied’ parts of Mantle’s design and effectively re-branded it. Can you comment on this or perhaps provide a little insight?

Robert Hallock: DirectX 12 is Microsoft’s own creation, though they have welcomed input on its development from many different technology partners including AMD. We have welcomed the same input on Mantle by sharing the full specification with Microsoft since the early days of our API. As the industry moves to embrace the principles of ‘closer to the metal’ API design, it is evident that our pioneering work with this concept has been highly influential.


t can those 'bundles' be per game object? If I have 100 objects in my current fov and the next frame discards 10 but also adds 10 more for example, will I be able to save the cost of resubmitting work for 90 unchanged objects into the command buffer?
Most game objects are not static between the frames.
 
Most game objects are not static between the frames.

Oh really? Which game you have in mind?

Even if they are dynamic, you only need to re-set the world-matrix which should be a map/unmap on its constant buffer. You don't need to set the input, index-buffer, vertex-buffers and textures again. That sill saves me from 80% of the CPU work involved in writing the instructions to command buffer.
 
but if it doesn't happen with Haswell @ 4.6GHz then it is a point that is mostly academic.
Yes because everyone has a Haswell @ 4.6GHz

...5% :LOL:. Even if there were no graphs that prove otherwise, I would still laugh at that number. I could feel the difference straight away. And my 4770K... well, it wasn't cheap.

Ahh, youve come to the conclusion that a 5% gain when cpu limited cant be true because your non cpu limited system doesnt show that, bit like deciding a family car can do 200mph because a supercar can
vtCu8ds.jpg
 
That test clearly isn't CPU limited despite the weak CPUs, those are gains you'd see when you're GPU limited
 
DirectX 12 drivers can mean lots of things, especially at this point in time. IMHO stating that you have a driver now is not necessarily an indicator of some advantage. However, if DX12 represents (at least parts) a notable departure (e.g. perhaps a new WDDM model, to accommodate the low-level API parts) from currently established driver art, it is not unreasonable to assume that ATI will have the hardest time in coming up with the software, given that they have less resources than either Intel or NVIDIA in that area. Whether this merely means more all-nighters for ATI devs or it actually has any visible consequence is impossible to state at this point in time. Also, 2c worth of an opinion: having a non-public SDK and directly messing with closed off code across a set of apps that has super-low cardinality makes things a bit (read much) easier in terms of what is required from the driver stack. I would not generalize from Mantle sort of being there to "they have 99% of the work done already, after all we know that DX12 is just copy&paste from Mantle, with a sprinkling of replace all".
 
having a non-public SDK and directly messing with closed off code across a set of apps that has super-low cardinality makes things a bit (read much) easier in terms of what is required from the driver stack.

from merriam-webster dictionary
cardinality : the number of elements in a given mathematical set

So
having a non-public SDK and directly messing with closed off code across a set of apps that has super-low number of elements in a given mathematical set makes things a bit (read much) easier in terms of what is required from the driver stack.

What???
 
from merriam-webster dictionary
cardinality : the number of elements in a given mathematical set

So
having a non-public SDK and directly messing with closed off code across a set of apps that has super-low number of elements in a given mathematical set makes things a bit (read much) easier in terms of what is required from the driver stack.

What???

There aren't many Mantle games.
 
So your using the phrase "super-low cardinality" as a substitute for "not many" ?

I use the term 'landau symbol' in common speech, sometime (remnants of engineering courses).

...just today we chatted with a guy with a super, impressive CV - later, someone defined talking with him 'a mental DoS' :rolleyes:
These things happens...

if I did understand correctly, his point was that there are too few mantle games to make critical mass -at least yet.
 
So your using the phrase "super-low cardinality" as a substitute for "not many" ?

I'm just translating. But since Alex referred to Mantle games as a set, cardinality makes sense.

I know someone who uses the phrase "for all x" to mean something like "in any case/whatever the exact nature of this thing we're discussing may be". :p
 
well not really you wouldnt go into a hardware store and ask for a tool kit with a high cardinality of screwdrivers.
anyway its been explained and i understand it now

I know someone who uses the phrase "for all x"
I do hope you slap him when he does that ;)
 
Hello. I'm work on initialization API Mantle and this my test program gfile.ru/a7i4z (i don't know how here make attach). For launch program you needed OS Windows x64 (of course :smile: ) and VC++Redist 2013 (program was linked in VS2013)
 
Just helps get the AMD setups GPU limited, like the Intel setups always are. They are pushing those GPUs pretty hard. Very High settings will even fill up 2GB VRAM and sometimes cause stutters on 2GB cards as a result.
 
Even with the 280X or the 290X, results would be the same. It could be the standard Thief benchmark is mainly GPU-bound.

In other news, BF4 implemented FCAT support with Mantle, which allowed pcper to do proper frame time analysis with single and dual 290X.

Frame times with a single GPU are almost the same between DirectX and Mantle (with 6% higher fps in Mantle), dual GPUs on the other hand exhibits an interesting phenomenon, in Mantle frame times are nearly flat and way more consistent than DirectX, however average frames are way lower at the same time.

It almost appears that the Frostbite engine's implementation of frame pacing puts so much weight behind having a consistent frame rate that it is willing to sacrifice peak frame rates. In the case of our higher resolution results here, I think that trade off is worth making. The lack of ANY hitches or frame time spikes provides a spectacularly smooth gaming experience.
http://www.pcper.com/reviews/Graphi...e-CrossFire-Early-Performance-FCAT/High-End-C
 
Back
Top