Jump to content
AIDA64 Discussion Forum
javanse

Mantle GPU Information and Vulkan

Recommended Posts

Hi,

 

now that the new Vulkan API is going to be released in the next days or weeks, i was wondering what will happen to the Mantle Information tab? As the AMD-only Mantle was the starting point for the IHV-independent Vulkan (and thus they're somewhat related), are you planning an update for the Mantle tab to show the Vulkan Information for every supported GPU instead?

 

Afaik the Mantle API already is End-of-Life, so it would make more sense to me to update the Mantle tab to Vulkan than to keep the old Mantle stuff in there.

Share this post


Link to post
Share on other sites

We will definitely implement a new page to show Vulkan video adapter information. We just need to wait for the first official Vulkan-ready drivers to be rolled out by both AMD and nVIDIA. We may also phase out the existing Mantle page at one point. But for legacy systems it makes sense to keep it for a while.

Regards,

Fiery

Share this post


Link to post
Share on other sites

Thanks for the update, the new Vulkan page does display a lot of information on my GTX 670 with 356.39 drivers. :)

 

Just one thing: it looks like AIDA64 does create a 32bit Vulkan interface only, thus resulting in a Remote Heap Size of only 1,5 GB (see the attached screenshot). I verified this via http://www.geeks3d.com/vkz/ which allows the user to create both 32 and 64bit interfaces, and with VK-Z the 32bit one reads only 1.5 GB remote heap where the 64bit one reads a 16 GB remote heap, matching my installed system ram.

post-322-0-15743000-1455898773_thumb.png

post-322-0-28213800-1455899282_thumb.png

Share this post


Link to post
Share on other sites

Thank you for the feedback. AIDA64 uses 32-bit interface to acquire Vulkan information. So the remote heap size -- as you've pointed out -- will be somewhat limited. But that value is still relevant to indicate how 32-bit applications are handled by Vulkan.

Share this post


Link to post
Share on other sites

Thank you for this confirmation, but i'm wondering about the usefulness of a 32bit Vulkan interface. Croteam, the developer of the first game with public Vulkan support "The Talos Principle" stated in their FAQ:

 

Q: Wait, what? No support for 32-bit?

A: No. 64-bit is the future. And present!


Q: Will there be Vulkan support for 32-bit version of the game?

A: Probably not.

Maybe AIDA64 could create an Vulkan interface according to the bit-ness of the Host OS?

Share this post


Link to post
Share on other sites

Maybe AIDA64 could create an Vulkan interface according to the bit-ness of the Host OS?

Maybe, in the future. So far the only limitation of using 32-bit interface is the remote heap size detection issue.

Share this post


Link to post
Share on other sites

Ok, if the 32bit interface is intended for now then fine, just wanted to report it as it hit my eye. ;)

 

Another thing: although Fermi cards (400/500 series) could technically support Vulkan, NVidia currently does not enable Vulkan for these GPUs. But as the Vulkan driver 356.39 is officially supported for Fermi, i installed it onto my GTX 470 in my 2nd PC and run both AIDA64 and the Vulkan Caps Viewer on it (the author of that tool is a member of the Vulkan board).

Now straight to the bug: AIDA64 does read a lot of Vulkan information for the Fermi GPU where the Vulkan Caps Viewer gives an error message about not being able to create a Vulkan interface. I've talked with the author of Vulkan Caps Viewer about this, and his opinion was that AIDA64 gets its data from the GL<->VK interop without trying to create an actual VkDevice (which would fail on a Fermi GPU at the moment) where his tool tries to create a VkDevice first and then reads the data.

 

Sidenote: VK-Z does the same as AIDA64, i'll give them a bug report too.

Share this post


Link to post
Share on other sites

You're right, AIDA64 does not try to create a VkDevice. It uses vkEnumeratePhysicalDevices, vkGetPhysicalDeviceProperties and vkGetPhysicalDeviceFeatures. In case a driver reports meaningful information through those API calls, I don't think it's wrong to assume there's a physical device there that supports Vulkan. In case the video driver mistakenly provides physical device information for such devices that are not really supported by Vulkan, it's the bug of the video driver and not the fault of AIDA64 or VK-Z.

Share this post


Link to post
Share on other sites

Hello. I apologize for raising the old topic, but still..

Noticed that AIDA64 still uses the old protocol definitions of supported extensions AMD Mantle API.

I study the driver and loader by disassembling the code and write public SDK, in particular, I am studying a library of additional functions mantleaxl.

Mantle Programming Guide (Revision 1.0; March 6, 2015) designed only for mantle.dll, but the mantleaxl library is constantly being expanded. Updated revisions of programming guide AMD don't let out.

So, I found new extensions (applied vulkan style)

#define GR_WSI_WINDOWS_EXTENSION_NAME "GR_WSI_WINDOWS"
#define GR_BORDER_COLOR_PALETTE_EXTENSION_NAME "GR_BORDER_COLOR_PALETTE"
#define GR_ADVANCED_MSAA_EXTENSION_NAME "GR_ADVANCED_MSAA"
#define GR_PERF_PROFILE_EXTENSION_NAME "GR_PERF_PROFILE"
#define GR_DMA_QUEUE_EXTENSION_NAME "GR_DMA_QUEUE"
#define GR_COPY_OCCLUSION_DATA_EXTENSION_NAME "GR_COPY_OCCLUSION_DATA"
#define GR_TIMER_QUEUE_EXTENSION_NAME "GR_TIMER_QUEUE"
#define GR_CONTROL_FLOW_EXTENSION_NAME "GR_CONTROL_FLOW"
#define GR_GPU_TIMESTAMP_CALIBRATION_EXTENSION_NAME "GR_GPU_TIMESTAMP_CALIBRATION"
#define GR_RESOURCE_STATE_ACCESS_EXTENSION_NAME "GR_RESOURCE_STATE_ACCESS"
#define GR_PRIVATE_DISPLAY_EXTENSION_NAME "GR_PRIVATE_DISPLAY"
#define GR_WIN_EXTERNAL_SHARED_RESOURCE_EXTENSION_NAME "GR_WIN_EXTERNAL_SHARED_RESOURCE"
#define GR_OBJECT_MIGRATION_EXTENSION_NAME "GR_OBJECT_MIGRATION"
#define GR_REGMEM_ACCESS_EXTENSION_NAME "GR_REGMEM_ACCESS"
#define GR_DISPATCH_OFFSET_EXTENSION_NAME "GR_DISPATCH_OFFSET"
#define GR_PIPELINE_USER_DATA_EXTENSION_NAME "GR_PIPELINE_USER_DATA"
#define GR_QUEUE_PRIORITY_EXTENSION_NAME "GR_QUEUE_PRIORITY"
#define GR_DEDICATED_COMPUTE_QUEUE_EXTENSION_NAME "GR_DEDICATED_COMPUTE_QUEUE"
#define GR_BINDLESS_RESOURCES_EXTENSION_NAME "GR_BINDLESS_RESOURCES"
#define GR_POWER_PROFILE_EXTENSION_NAME "GR_POWER_PROFILE"
#define GR_VIRTUAL_DISPLAY_EXTENSION_NAME "GR_VIRTUAL_DISPLAY"

If interested, here is my GitHub https://github.com/tesla707/Mantle

I’m constantly updating the repository, so that everything is still in beta.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...