Feature Request: Add RT/AI/Video core counts, Cache levels (L0 to L3), and MCM process info #18
Replies: 7 comments 6 replies
-
|
I moved this issue into new Discussions tab which is more accurate for this topic :) Thanks for your input, I'll comment on it later. |
Beta Was this translation helpful? Give feedback.
-
|
I'll copy-paste your comment from #9 in order to cleanup the issue:
|
Beta Was this translation helpful? Give feedback.
-
|
And another copy-paste from #9 :
|
Beta Was this translation helpful? Give feedback.
-
|
Well i suggest you to also add information about AI Cores capabilities(which instructions support and at what speed(TFLOPS for FP operations, TOPS for INT operations)) to "Advanced" tab, like RDNA 3 AI Accelerators support FP16, BF16, INT8 and INT4, their speeds and so on. I can also provide you with .txt file with FP16 capabilities for all NVIDIA/AMD/Intel GPUs if you want.(there's also notes about other FP and INT operations for them, so it does not limit on FP16). And also maybe make like vector capabilities?(like what instructions do shader cores support) |
Beta Was this translation helpful? Give feedback.
-
|
To further expand on the "Advanced" tab proposal, here is a more detailed mock-up that distinguishes between dedicated Matrix hardware and Vector (Shader-based) acceleration. This would provide a complete picture for both modern and legacy GPUs: AI Acceleration Type: Tensor (NVIDIA) / WMMA (AMD) / XMX (Intel) / None Peak Performance(Vector/Shaders): |
Beta Was this translation helpful? Give feedback.
-
|
There are a lot of elements to break down here, so I'm going to go step by step:
That's a great idea in general, but it needs to be placed carefully within the layout of GPU-T. We want to avoid bloating the main "Graphics Card" tab, so we have to be highly selective about what goes on the front page versus the "Advanced" tab.
I definitely agree with ray tracing cores / units here. Ray tracing is less and less just a gimmick (it's been released in 2018 so that's 8 years ago!) and it deserves a place in an utility like GPU-T. The database would be managable as there aren't thousands of ray-tracing enabled GPUs. I also agree with AI cores (whatever the name) - that's more and more common in the latest GPUs. I think that could be even displayed on the main tab. In case of Video engines - I think I would maybe see that integrated into Advanced (Multimedia) tab. However the worst part of this piece of information is the database / lack of unification - various architectures may have different information fields so that's definitely less managable than RT and AI cores. Someone would have to make a lot of decisions + creating such a database for hundreds of GPUs would be a serious task (unless you have these information easily available from a data source like TPU's database - however I'm not aware of such database). Definitely something worth considering, but for a later time once all 3 main vendors are recognized properly by GPU-T.
Definitely an interesting idea for the Advanced tab. However, once again, the database creation for this would be highly problematic and time-consuming.
I think I will have to pass on this one. There are only a handful of consumer multi-chip GPUs on the market, so looking at the broader picture of all supported hardware, it's a very small niche. Even RDNA 4 has returned to a monolithic design.
I completely agree, and I actually have a UI idea for this! Right now, our capability checkboxes either show a black tick (supported) or an empty box (unsupported). We could introduce a grey tick: this would mean "Hardware supports this feature, but the runtime/libraries are currently missing." The challenge, as always, is populating the database to map out these capabilities for all the available GPUs.
That's a good idea, however a fallback in a form of libraries detection would have to stay just in case if the user doesn't have clinfo installed.
A very interesting proposal. The idea of adding a dedicated 'AI & Compute' section to the Advanced tab is spot on. Regarding the .txt database of FP16/INT8 speeds: I actually suggest avoiding hardcoding exact TFLOPS/TOPS numbers. Because different partner cards (ASUS, MSI, etc.) and user overclocks change the clock speeds, a static database will show actually incorrect numbers for many users. Instead, I'd prefer to calculate these numbers dynamically on the fly. The general formula is usually (Shaders * ClockSpeed * OperationsPerClock). Shaders and ClockSpeed is something we already have, the only missing part is OPS. If you really want to help drive this feature, what I actually need is an Architectural Ruleset rather than a list of GPUs. For example, if you could help map out the multipliers and supported flags per architecture (e.g., 'RDNA 3 supports WMMA, TF32=No, BF16=Yes, INT8 multiplier is X' etc. etc.), we could tie that directly into the app's calculation engine. CONCLUSION Overall, these are solid ideas and align well with where GPU-T should be heading. The question isn't really if we add these features, but how we implement them - especially when it comes to keeping the database maintainable and the UI clean. If you have any good ideas about filling all the necessary pieces of information into the database ((are there any reliable, structured sources of data or APIs we can use?) - please let me know, I'll definitely aim at adding these features once all 3 main GPU vendors are working properly with GPU-T. |
Beta Was this translation helpful? Give feedback.
-
It has an architectural ruleset though, it has formulas for all of these architectures, so you can just copy-paste it into GPU-T and it will calculate it by itself.(but REQUIRED to add the overclock speeds, so it could be more accurate)
You can just add database for GPUs (like only for Navi 31, 32, 33 not for videocards that made on them)(e.g., 2x VCN 4.0 for Navi 31, 1x VCN 4.0 for Navi 32, 33; same for other AMD, NVIDIA and Intel chips) and it will be informative, cus they usually dont modify the count of them in different iterations (e.g., RX 7600, 7650 GRE and 7600 XT(and its mobile and server iterations on Navi 33) and 7700, 7700 XT, 7800 XT(and its mobile and server iterations on Navi 32) have the same 1x VCN 4.0)
You could do the same for these as for video engines. GPUs with the same chips share the same L0/L1 per CU(or whatewer the others has, total can be just calculated multiplying on CU or whatever), the only difference is higher L2 and L3(AMD only).
You can make it more colorful though, not the gray tick but red tick for missing runtime, black tick for not missing runtime, X(whatever color) for no support |
Beta Was this translation helpful? Give feedback.
-
|
Nice breakdown! The formulas and architectural multipliers are exactly what I meant by an "Architectural Ruleset". It just proves that dynamic calculation is the way to go. Your notes on grouping VCNs by the base chip (Navi 31/32) are correct. I'm not convinced about the colorful checkboxes, but that's a debate for another time. Anyway, I want to be transparent about the development timeline. As you might have seen, I published yesterday the official GPU-T Roadmap (in the Discussions tab). Right now, my absolute priority is Phase 1 & 2: stabilizing the core app, universal AppImage packaging, and ensuring the basic NVIDIA/Intel integrations are developed into something meaningful (worth activating for everyone). Because of that, deep-dive features are firmly slated for Phase 3 / 4. Additionally, to make this feature complete, we will eventually need the fallback math for older, highly popular legacy architectures (like Pascal, Polaris, and RDNA 2) which rely on DP4a or standard vector shaders, rather than just the modern dedicated AI blocks. I am going to leave this discussion open. I won't be working on this specific set of features right now, but this thread will serve as the perfect blueprint when we reach that phase. Thanks again for providing value here. |
Beta Was this translation helpful? Give feedback.
-
Alright. though i could help with testing the Intel support since you know that i have iGPU that is based on Xe-LP which is similiar to Xe-HPG used in Arc graphics(not in sensors tho, cus they are nonexistent, atleast on my motherboard). If you have any questions, im open to answer them.
Ok, just my idea to "colorise" it, but it's your choice to whether add it or not. |
Beta Was this translation helpful? Give feedback.
-
|
@lseurttyuu here, made for you formula for standard vector shaders FP32/FP16/FP64: |
Beta Was this translation helpful? Give feedback.
-
|
@lseurttyuu its actually that simple😅 but now we need to somehow fit this whole MCM layout into the UI (or add the scroll bar) and display the number of active MCDs. 
|
Beta Was this translation helpful? Give feedback.
-
|
@try228 I've seen your PR. The idea is quite cool, I actually had it as well once I was creating a database for AMD GPUs. However I believe we shouldn't put it Technology box since it's clearly too large. Instead, I think creating a new entry in the database + a new graphical field in the GUI is the right way to go. Eg., it could be: and then if there's according field in the database --> it is filled with this information (eg. 1x GCD, 6x MCD). This field could be potentially paired in a row with other new fields like RT cores and Tensor/Matrix/XMX cores. I believe this is the right way to handle this (some fields could be reorganized - to be considered). So, to sum it up - I won't merge the PR in its current shape, however the information you put there is valuable - I'll use it when further developing this aspect of the project. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback! I totally agree that a dedicated UI field and database entry is a much cleaner architecture for the long term than cluttering the Technology box. If you're open to it, I can update the PR to make it easier to manage: New Logos: I suggest we keep the new logos and merge them independently. They are separate assets that improve the UI immediately and are ready to go. Let me know if you think this approach works, and I'll be happy to clean up the PR accordingly! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
To make GPU-T even more detailed for modern architectures, I suggest adding the following hardware information fields:
Specialized Cores:
Ray Tracing Cores(NVIDIA) / Ray Accelerators(AMD)/ Ray Tracing Units(Intel) (e.g., 80 for RX 7900 GRE).
Tensor Cores(NVIDIA) / AI Accelerators(AMD)/XMX Engines(Intel) (e.g., 160 for RX 7900 GRE).
Video coding engines(NVENC/NVDEC for NVIDIA,VCN(RDNA+) or UVD/VCE for AMD,QuickSync for Intel) count and version (e.g. 2x VCN 4.0 for RX 7900 GRE)
Memory Hierarchy (Caches):
Display L0(per SM/EU/WGP and in total), L1(per SM/EU/array and in total), L2, and L3 (Infinity Cache, AMD only) sizes. For RDNA 3, Infinity Cache is a key performance metric.
MCM (Multi-Chip Module) Details:
For chiplet-based GPUs (like Navi 31), it would be great to show the manufacturing process for both GCD (Graphics Compute Die) and MCD (Memory Cache Die) or whatever NVIDIA or Intel has.
Example for RX 7900 GRE: GCD on 5nm and MCD on 6nm.
GPU Database / Readiness info:
As discussed before, an internal "capabilities" database would be helpful. Even if runtimes (OpenCL/HIP) are missing, the app could show that the hardware is capable, but libraries are not installed.
Adding these features would make GPU-T much more informative and technically advanced than even GPU-Z. It would become the ultimate tool for Linux users to truly understand their modern GPU architecture.
Beta Was this translation helpful? Give feedback.
All reactions