It's official, Nvidia will not support Mantle

This might blow you mind but low level code has been common to consoles since Atatri 2600?
Whether you call it assembly or another form of low level graphics API. It has been around for more then decades.
What i Said about Mantle that it is easy to debug because there is no big driver to check for problems.

I've been a programmer for over 20 years. Writing in assembly was a pain in the ass. Low level programming like that is actually more difficult because the compiler does less of the work for you. You have to hand code a lot of things that a higher level API would do for you.

I'm starting to wonder if you can even write a game using Mantle or if it's just a way to port DX code to AMD's platform.
 
I've been a programmer for over 20 years. Writing in assembly was a pain in the ass. Low level programming like that is actually more difficult because the compiler does less of the work for you. You have to hand code a lot of things that a higher level API would do for you.

I'm starting to wonder if you can even write a game using Mantle or if it's just a way to port DX code to AMD's platform.

Do you just ignore people once proven incorrect?

http://hardforum.com/showpost.php?p=1040996389&postcount=198

Mantle isn't AMD's platform, they are releasing it as a platform for anyone once its out of beta. Funny how everyone flaming it can't figure out how beta's work with limited access and availability....
 
The only thing that bothers me is people praise Mantle for being open, when it isn't open yet. It's not better than any other API until it's actually open.
 
The only thing that bothers me is people praise Mantle for being open, when it isn't open yet. It's not better than any other API until it's actually open.

Nobody is praising it as much as they are just trying to keep it real. People say it's proprietary and closed like PhysX and it needs to be an open standard like DX. When incorrect statements like that are said and someone tries to straighten it out it comes off as defending Mantle, when it's not. It's just trying to overcome the FUD campaign.
 
Nobody is praising it as much as they are just trying to keep it real. People say it's proprietary and closed like PhysX and it needs to be an open standard like DX. When incorrect statements like that are said and someone tries to straighten it out it comes off as defending Mantle, when it's not. It's just trying to overcome the FUD campaign.

This. The FUD-slinging is always pretty extreme on these forums whenever AMD comes out with something of interest.
 
Nobody is praising it as much as they are just trying to keep it real. People say it's proprietary and closed like PhysX and it needs to be an open standard like DX. When incorrect statements like that are said and someone tries to straighten it out it comes off as defending Mantle, when it's not. It's just trying to overcome the FUD campaign.

Physx is actually far more open than Mantle ever will be. It works on just about every system out there including the new consoles. AMD (and fellow marketers) are spreading too much false information about Mantle.

Facts:

  • It's proprietary
  • It's beta
  • They have rejected Intel's access to it
  • So far no games have been written with it.
  • It's not used on the consoles
 
for the love of god.

its a GRAPHICS API, not a programming language.

YOU CANT WRITE A GAME WITH IT.

you can however, create a rendering path for a game engine with it which several developers have (Frostbite, Oxide, Cryngine, Limited UE3)

WTF, people dont even know what an API is in here....
 
for the love of god.

its a GRAPHICS API, not a programming language.

YOU CANT WRITE A GAME WITH IT.

you can however, create a rendering path for a game engine with it which several developers have (Frostbite, Oxide, Cryngine, Limited UE3)

WTF, people dont even know what an API is in here....

But these are "programmers" man! they program things, like VCR's, they know shit. :D
 
So far no games have been written with it.

You call yourself a programmer? Get out of here buddy. You've just demonstrated, yet again, that you're heavily biased against AMD.

Hurr guys lets write a game using DirectX.
 
I've been a programmer for over 20 years. Writing in assembly was a pain in the ass. Low level programming like that is actually more difficult because the compiler does less of the work for you. You have to hand code a lot of things that a higher level API would do for you.

I'm starting to wonder if you can even write a game using Mantle or if it's just a way to port DX code to AMD's platform.

Programmer for 20 years, still spectacularly clueless.

ok.
 
It's really rather pointless to have ignored someone if you're all just going to quote him.
 
for the love of god.

its a GRAPHICS API, not a programming language.

YOU CANT WRITE A GAME WITH IT.

you can however, create a rendering path for a game engine with it which several developers have (Frostbite, Oxide, Cryngine, Limited UE3)

WTF, people dont even know what an API is in here....

You should look up what API stands for. Really. Go ahead. I'll wait.

I do like how you guys are trying to distance Mantle from DirectX and OpenGL now. Spin, spin, spin.
 
I've been a programmer for over 20 years. Writing in assembly was a pain in the ass. Low level programming like that is actually more difficult because the compiler does less of the work for you. You have to hand code a lot of things that a higher level API would do for you.

Okay but If you use your own code that is when there are bugs it is easier to track then if it goes wrong in the driver. Since you did the code yourself you can track the problem as a developer instead of asking AMD/Nvidia if they can fix the driver.
 
You should look up what API stands for. Really. Go ahead. I'll wait.

I do like how you guys are trying to distance Mantle from DirectX and OpenGL now. Spin, spin, spin.

Mantle is simple it is not meant to be used as a replacement, not meant to be used as a closed API, not meant to sabotage opposing graphics cards.

But some of them are right Prime , Mantle is only the interface for the graphics card .
The expression of doing a game in Mantle is wrong since a game is more then just graphics, X86 code is in there as well.
 
Okay but If you use your own code that is when there are bugs it is easier to track then if it goes wrong in the driver. Since you did the code yourself you can track the problem as a developer instead of asking AMD/Nvidia if they can fix the driver.

Mantle still requires a driver and it still causes problems.

http://support.amd.com/en-us/kb-articles/Pages/latest-catalyst-windows-beta.aspx

AMD CrossFire™ configurations with AMD Eyefinity enabled will see instability with BattleField 4 or Thief when running Mantle

Either way we are all speculating as there is no public SDK or source code to show us exactly what Mantle is doing. I doubt we will ever truly know.
 
Programmer for 20 years, still spectacularly clueless.

ok.

I believe him. Honestly.
The only remaining question is: what did he programmed? VCR's? Alarm clocks? Thermostats? Because even these would be a serious chellenge for him... :D
 
Physx is actually far more open than Mantle ever will be. It works on just about every system out there including the new consoles. AMD (and fellow marketers) are spreading too much false information about Mantle.

Facts:

  • It's proprietary
  • It's beta
  • They have rejected Intel's access to it
  • So far no games have been written with it.
  • It's not used on the consoles


God its amazing how wrong you can be, and how stubborn too.

Yes it is Beta, which is why it is limited access to both developers and hardware.

They didn't reject Intel's access, they "rejected" having Intel access it before it hit 1.0.

"I know that Intel have approached us for access to the Mantle interfaces, et cetera," Huddy said. " And right now, we've said, give us a month or two, this is a closed beta, and we'll go into the 1.0 [public release] phase sometime this year, which is less than five months if you count forward from June. They have asked for access, and we will give it to them when we open this up, and we'll give it to anyone who wants to participate in this."

They are keeping it locked down for now to help with finding and removing bugs and adding features / optimizing. If you've every truly programmed something you'd know that its much easier to reproduce issues if you can limit options Once they hit v1 they are opening it up to not only their own earlier hardware, but nvidia and Intel as well.

As far as game not being written for it...

BF4 and Thief are just two that showed massive gains, especially for older / lower end hardware which is HUGE for budget gamers.

Maybe you should just read the FAQ since you are so wrong about whats happening with Mantle and why developers are choosing to use it and getting some amazing results (See Thief benchmarks I've linked you twice)

Does Mantle compete with DirectX®?
DirectX® provides a standardized programming interface for GPUs, allowing the same code to work across a wide range of architectures and product configurations. Mantle complements DirectX® by providing a lower level of hardware abstraction for developers who want and need it, echoing the capabilities they have come to expect on dedicated game consoles.​

Will Mantle be supported on the PlayStation 4 and Xbox One game consoles?
The initial releases of the Mantle API and graphics driver are intended for the PC platform only. However, one of the key goals of Mantle is to make it as easy as possible for developers to use the same features and programming techniques they are already utilizing for the new generation of game consoles when bringing their games to PCs. This enables better re-use of development efforts for multi-platform games.​

http://support.amd.com/en-us/kb-articles/Pages/mantle-faq.aspx
 
People, please try to identify and deal with trolls better the next time. Ignoring them is the best way to get rid of them. It's not because someone is shouting on the internet that you have to respond. If they don't get acknowledged, they feel like no one hears their cries and they'll go away. But they will keep coming, in greater numbers, because you keep feeding them delicious emotions.
 
DirectX® provides a standardized programming interface for GPUs, allowing the same code to work across a wide range of architectures and product configurations. Mantle complements DirectX® by providing a lower level of hardware abstraction for developers who want and need it, echoing the capabilities they have come to expect on dedicated game consoles.​

If I'm reading that correctly, that means I was right before when I said that Mantle is intended to complement DirectX rather than replace it.

AMD and Microsoft have actually worked together fairly recently, and I wouldn't be surprised if Mantle is adapted from parts of the upcoming DirectX 12 that AMD was allowed to see. That would explain why it's going to be so easy to port code back and forth.

Think about it... the Xbox One is powered by a Radeon, and Microsoft did change the scheduler in Windows 8 to support Bulldozer better. I doubt AMD really intends to do anything that would jeopardize their business relationship with Microsoft.

Mantle presumably doesn't provide a standardized programming interface, but is designed for platform specific code. Platform-specific code is something more familiar to console developers, because they only have to develop for one machine. Mantle will, basically, allow developers to introduce GPU and CPU-specific optimizations on the PC, and is designed to play nice with DirectX acting as the high-level code layer.

If Microsoft didn't want Mantle code to be easily portable to and from DirectX, they could easily do something to trip them up. So, we're left with the conclusion that Microsoft doesn't see Mantle as a threat, and may even be working with AMD on making sure it's interoperable.

Ultimately, AMD is trying to get developers to write more platform-specific/optimized code and providing them the tools to do so. That's all that's going on here... nothing more, nothing less. It's great for people with older/weaker hardware if AMD is successful, but that's about it. AMD isn't trying to compete with Microsoft's DirectX, they want to provide something DirectX currently cannot, and they will be content if DirectX incorporates it. They want more low-level, platform-specific optimizations. Mantle is just an initiative to push that goal.
 
Last edited:
...

Ultimately, AMD is trying to get developers to write more platform-specific/optimized code and providing them the tools to do so. That's all that's going on here... nothing more, nothing less. It's great for people with older/weaker hardware if AMD is successful, but that's about it. AMD isn't trying to compete with Microsoft's DirectX, they want to provide something DirectX currently cannot, and they will be content if DirectX incorporates it. They want more low-level, platform-specific optimizations. Mantle is just an initiative to push that goal.

Exactly.

More from the FAQ:

Is Mantle a proprietary AMD technology?
Mantle was conceived and developed by AMD in partnership with leading game developers.
This enabled the fast and agile development required to validate the concepts and bring such the technology to life in a relatively short period of time. However, Mantle was designed in a way that makes it applicable to a range of modern GPU architectures. In the months ahead, we will be inviting more partners to participate in the development program, leading up to a public release of the specifications later in 2014. Our intention is for Mantle, or something that looks very much like it, to eventually become an industry standard applicable to multiple graphics architectures and platforms.​

Oh yeah... and they are working with Microsoft on DX12:

What are the similarities between Mantle and DirectX® 12?
​DirectX® 12 is Microsoft’s own creation, though its development has been steered by input 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.​
 
Physx is actually far more open than Mantle ever will be. It works on just about every system out there including the new consoles. AMD (and fellow marketers) are spreading too much false information about Mantle.

Facts:

  • It's proprietary
  • It's beta
  • They have rejected Intel's access to it
  • So far no games have been written with it.
  • It's not used on the consoles

We're talking PhysX on the GPU which nVidia artificially locks out if you are using a different brand GPU than nVidia for rendering. AMD doesn't lock any of their features and they can be used license and royalty free. Oh, and without NDA's that stop you from being transparent with the other IHV's so they can see the source code and optimize their hardware for it. They have publically stated that they are going to do the same thing with Mantle when it's out of beta and the SDK is released.

1) It's proprietary. So what? Most things are, just as DX is. Unfortunately the wonderful world of the open rendering API hasn't been able to even marginally compete with DX giving Msft a virtual monopoly on the PC. We've been stuck on the same version of DX for 5 years because Msft has no reason to worry they will be overtaken. Mantle allows the IHV's to add features as the hardware evolves to use it.

2) It's beta. Again, so what?

3) They have rejected Intel's access to it. They were told they can have it when it's ready. It's not ready yet. That's not the same thing as saying no. Besides, I can just imagine the backlash if AMD gave access to Intel before they allowed other IHV's access. The nVidiots (and fellow marketers) would have a shit conniption.

4) So far no games have been written with it. One more time... So what? They don't need to be. They are written in the same programming language as DX, OpenGL, the consoles, whatever.

5) It's not used on the consoles. A great big giant so what. Devs are porting most games to 4 or 5 API's already. One more is not a big deal. That might not be what the DX defenders and nVidia supporters are saying, but it's what the devs have said.
 
People, please try to identify and deal with trolls better the next time. Ignoring them is the best way to get rid of them. It's not because someone is shouting on the internet that you have to respond. If they don't get acknowledged, they feel like no one hears their cries and they'll go away. But they will keep coming, in greater numbers, because you keep feeding them delicious emotions.

Unfortunately that only works until they get a partner or two. Then they gather around and have an uncontested FUD fest between them.
 
Attack the message all you want, but not the poster...DO NOT make it personal.
 
It's too bad that OpenGL isn't used more (and correctly) to provide competition to DirectX which Mantle may end up doing. I worry that Mantle may end up being another Glide but am hopeful that AMD has learned from 3dfx's past.
 
If I'm reading that correctly, that means I was right before when I said that Mantle is intended to complement DirectX rather than replace it.

AMD and Microsoft have actually worked together fairly recently, and I wouldn't be surprised if Mantle is adapted from parts of the upcoming DirectX 12 that AMD was allowed to see. That would explain why it's going to be so easy to port code back and forth.

Think about it... the Xbox One is powered by a Radeon, and Microsoft did change the scheduler in Windows 8 to support Bulldozer better. I doubt AMD really intends to do anything that would jeopardize their business relationship with Microsoft.

Mantle presumably doesn't provide a standardized programming interface, but is designed for platform specific code. Platform-specific code is something more familiar to console developers, because they only have to develop for one machine. Mantle will, basically, allow developers to introduce GPU and CPU-specific optimizations on the PC, and is designed to play nice with DirectX acting as the high-level code layer.

There's nothing really platform specific in Mantle's core API, this is why there's an extension system. The API is not as exotic as you think it might be, you'll find a lot is similar to DX/GL. But you'll also find lots of synchronization and threading stuff, explicit memory management, and some other differences.

I dumped the function export list
Code:
dumpbin.exe /EXPORTS mantle64.dll
Microsoft (R) COFF/PE Dumper Version 11.00.60610.1
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file mantle64.dll

File Type: DLL

  Section contains the following exports for mantle64.dll

    00000000 characteristics
    53BD604A time date stamp Wed Jul 09 11:31:22 2014
        0.00 version
           1 ordinal base
         124 number of functions
         124 number of names

    ordinal hint RVA      name

          2    0 00004F50 DllMain
          1    1 00001060 IcdDbgMessage
          3    2 00001930 grAllocMemory
          4    3 000019A0 grAttachImageViewDescriptors
          5    4 00001A10 grAttachMemoryViewDescriptors
          6    5 00001A80 grAttachNestedDescriptors
          7    6 00001AF0 grAttachSamplerDescriptors
          8    7 00001B60 grBeginCommandBuffer
          9    8 00001BC0 grBeginDescriptorSetUpdate
         10    9 00001C00 grBindObjectMemory
         11    A 00001C70 grClearDescriptorSetSlots
         12    B 00001CE0 grCmdBeginQuery
         13    C 00001D50 grCmdBindDescriptorSet
         14    D 00001DC0 grCmdBindDynamicMemoryView
         15    E 00001E30 grCmdBindIndexData
         16    F 00001EA0 grCmdBindPipeline
         17   10 00001F10 grCmdBindStateObject
         18   11 00001F80 grCmdBindTargets
         19   12 00001FF0 grCmdClearColorImage
         20   13 00002060 grCmdClearColorImageRaw
         21   14 000020D0 grCmdClearDepthStencil
         22   15 00002150 grCmdCloneImageData
         23   16 000021C0 grCmdCopyImage
         24   17 00002230 grCmdCopyImageToMemory
         25   18 000022A0 grCmdCopyMemory
         26   19 00002310 grCmdCopyMemoryToImage
         27   1A 00002380 grCmdDbgMarkerBegin
         28   1B 000023D0 grCmdDbgMarkerEnd
         29   1C 00002410 grCmdDispatch
         30   1D 00002480 grCmdDispatchIndirect
         31   1E 000024F0 grCmdDraw
         32   1F 00002560 grCmdDrawIndexed
         33   20 000025E0 grCmdDrawIndexedIndirect
         34   21 00002650 grCmdDrawIndirect
         35   22 000026C0 grCmdEndQuery
         36   23 00002730 grCmdFillMemory
         37   24 000027A0 grCmdInitAtomicCounters
         38   25 00002810 grCmdLoadAtomicCounters
         39   26 00002890 grCmdMemoryAtomic
         40   27 00002900 grCmdPrepareImages
         41   28 00002970 grCmdPrepareMemoryRegions
         42   29 000029E0 grCmdResetEvent
         43   2A 00002A30 grCmdResetQueryPool
         44   2B 00002AA0 grCmdResolveImage
         45   2C 00002B10 grCmdSaveAtomicCounters
         46   2D 00002B90 grCmdSetEvent
         47   2E 00002BE0 grCmdUpdateMemory
         48   2F 00002C50 grCmdWriteTimestamp
         49   30 00002CC0 grCreateColorBlendState
         50   31 00002D30 grCreateColorTargetView
         51   32 00002DA0 grCreateCommandBuffer
         52   33 00002E10 grCreateComputePipeline
         53   34 00002E80 grCreateDepthStencilState
         54   35 00002EF0 grCreateDepthStencilView
         55   36 00002F60 grCreateDescriptorSet
         56   37 00002FD0 grCreateDevice
         57   38 00003080 grCreateEvent
         58   39 000030F0 grCreateFence
         59   3A 00003160 grCreateGraphicsPipeline
         60   3B 000031D0 grCreateImage
         61   3C 00003240 grCreateImageView
         62   3D 000032B0 grCreateMsaaState
         63   3E 00003320 grCreateQueryPool
         64   3F 00003390 grCreateQueueSemaphore
         65   40 00003400 grCreateRasterState
         66   41 00003470 grCreateSampler
         67   42 000034E0 grCreateShader
         68   43 00003550 grCreateViewportState
         69   44 000035C0 grDbgRegisterMsgCallback
         70   45 000036A0 grDbgSetDeviceOption
         71   46 00003710 grDbgSetGlobalOption
         72   47 000037E0 grDbgSetMessageFilter
         73   48 00003850 grDbgSetObjectTag
         74   49 000038C0 grDbgSetValidationLevel
         75   4A 00003920 grDbgUnregisterMsgCallback
         76   4B 000039A0 grDestroyDevice
         77   4C 000039E0 grDestroyObject
         78   4D 00003A20 grDeviceWaitIdle
         79   4E 00003A60 grEndCommandBuffer
         80   4F 00003AA0 grEndDescriptorSetUpdate
         81   50 00003AE0 grFreeMemory
         82   51 00003B20 grGetDeviceQueue
         83   52 00003B90 grGetEventStatus
         84   53 00003BD0 grGetExtensionSupport
         85   54 00003C70 grGetFenceStatus
         86   55 00003CB0 grGetFormatInfo
         87   56 00003D30 grGetGpuInfo
         88   57 00003E00 grGetImageSubresourceInfo
         89   58 00003E80 grGetMemoryHeapCount
         90   59 00003EE0 grGetMemoryHeapInfo
         91   5A 00003F60 grGetMultiGpuCompatibility
         92   5B 00004090 grGetObjectInfo
         93   5C 00004100 grGetQueryPoolResults
         94   5D 00004180 grInitAndEnumerateGpus
         95   5E 00004300 grLoadPipeline
         96   5F 00004370 grMapMemory
         97   60 000043E0 grOpenPeerImage
         98   61 00004450 grOpenPeerMemory
         99   62 000044C0 grOpenSharedMemory
        100   63 00004530 grOpenSharedQueueSemaphore
        101   64 000045A0 grPinSystemMemory
        102   65 00004610 grQueueSetGlobalMemReferences
        103   66 00004680 grQueueSubmit
        104   67 00004700 grQueueWaitIdle
        105   68 00004740 grRemapVirtualMemoryPages
        106   69 000047D0 grResetCommandBuffer
        107   6A 00004810 grResetEvent
        108   6B 00004850 grSetEvent
        109   6C 00004890 grSetMemoryPriority
        110   6D 000048E0 grSignalQueueSemaphore
        111   6E 00004940 grStorePipeline
        112   6F 000049B0 grUnmapMemory
        113   70 000049F0 grWaitForFences
        114   71 00004A70 grWaitQueueSemaphore
        115   72 00004FC0 grWsiWinCreatePresentableImage
        116   73 00005030 grWsiWinGetDisplayModeList
        117   74 000050A0 grWsiWinGetDisplays
        118   75 00005110 grWsiWinGetScanLine
        119   76 00005170 grWsiWinQueuePresent
        120   77 000051D0 grWsiWinReleaseFullscreenOwnership
        121   78 00005210 grWsiWinSetGammaRamp
        122   79 00005270 grWsiWinSetMaxQueuedFrames
        123   7A 000052C0 grWsiWinTakeFullscreenOwnership
        124   7B 00005320 grWsiWinWaitForVerticalBlank

  Summary

        4000 .data
        2000 .pdata
        8000 .rdata
        1000 .reloc
        1000 .rsrc
       13000 .text
 
Gee, i wonder where that idea came from.

lol

Nice to see Johan involved though...
 
Doesn't really matter where the idea came from, Mantle's niche is pretty quickly shrinking.

OpenGL 4.5 is set to include DX11 cross-compatibility features (enabling simpler ports), and then they're turning their attention towards low-overhead... on an API that's already widely deployed and widely supported on multiple architectures and operating systems.

There isn't much of an argument for bothering with mantle for any long-term projects at this point.
 
Of course it doesnt matter to you, you marginalize everything AMD innovates.

It clearly says they are starting from scratch with a new paradigm, so current iterations of OGL are irelevant and will not be compatible.

Mantle has a massive development lead on this "new" OGL, so again your assessment is flawed.

Kronos tends to be just as ponderous as MS at times, so there is little hope this will make it in the wild any time soon.
 
Last edited:
Back
Top