Fiery

We've added the ANGLE extensions in the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.com/downloads/aida64extremebuild1803jctz3gwqhrzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Regards, Fiery

The Automatic Update feature will automatically update AIDA64 to the latest version -- without the need to manually download any ZIP or EXE packages -- if you have a valid AIDA64 license. During the evaluation (trial) period or when one tries to use a pirate license, AIDA64 will pop up a message box about the new version availability, but you have to manually download the ZIP package and manually perform the actual upgrade process. Even if you originally installed AIDA64 with the EXE package, the update link will still be provided to the ZIP package. Regards, Fiery

Thank you for the tests and your feedbacks. We've done more test runs today on various GeForce cards, and came up with a potential solution to this issue. Please upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.co...03jctz3gwqhrzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works. Please note that by simply unclicking the GPU test while running the SST, the clocks will not return to 2D profile, since unticking a subtest only suspends it, and the OpenCL session is not freed up. Only when you stop SST via the Stop button will the clocks return to 2D profile. With Radeon GPUs the clock management doesn't depend on an existing OpenCL session, but apparently it is simply based on GPU utilization. So when AIDA64 stops stressing a Radeon, the clocks will return to their 2D settings. While on GeForce GPUs you have to free up the OpenCL session to make ForceWare recognize that the GPU is not under stress anymore.

We've done some test runs on our own GeForce cards, and what we've found out is that ForceWare video driver apparently "forgets" to restore the clocks according to the 2D (power-saving) profile after the OpenCL GPGPU SST is finished. We've verified whether AIDA64 properly de-initializes and frees up all used OpenCL objects, and then unloads OpenCL DLL as well, but everything works as it is supposed to. On AMD Radeon cards and AMD APUs there're no such issues. We've also verified the GPU usage, and it gets back to cca. 0% after the GPGPU SST session finished. Hence the thread doesn't get stuck, and the GPU is not loaded at all. The higher temperatures are simply due to ForceWare keeping the 3D clocks profile in place until the application (AIDA64.EXE) is running.

No, it's not related to the GPU chip itself, but it's the temperature readout provided by the onboard CHiL CHL8228G buck controller chip. That chip also provides GPU VRM Current and GPU VRM Power readout as well.

Thank you for the feedback. But actually, the clocks do not reflect a stuck GPU stress test thread. The only sure verification is checking the GPU usage on the Display / GPU page. The clocks may be kept at high values (3D profile) by the ForceWare driver due to a driver bug. Please let me know if not only the clocks, but also the GPU usage gets stuck at a high value. Thanks, Fiery

Thank you for the feedback, and for your support

Thank you for your support. I hope you'll find AIDA64 useful in the next few years as well We have a lot of things on our roadmap, so expect to get some exciting AIDA64 updates soon. We do have plans about an online benchmark results interface for this year. Stay tuned As for RainMeter support, AIDA64 already offers multiple methods (Registry, Shared Memory, WMI) to expose AIDA64 sensor values to external applications. RainMeter's developers -- or anyone who has the necessary RainMeter API documentation -- need to develop the plugin that processes the values exposed by AIDA64 and "inject them" into RainMeter. I'm afraid we don't have the necessary developer resources to make in-house support for a wide range of 3rd party software. That's why we've come up with generic solutions (Registry, Shared Memory, WMI). Regards, Fiery

nVIDIA GPU clock settings are switched to 3D profile the first time AIDA64 detects the installed GPUs. So it's normal to have the clocks switched to high values once, but the driver (ForceWare) should restore the settings once the GPU is not under load. If you untick the GPU test during a stress test session, the log window should display "GPU1: Finished", and the video card shouldn't be under load anymore. You can check the GPU utilization on the Display / GPU page. If you don't want AIDA64 to switch to 3D profile, then you need to disable the option "Change to 3D profile on nVIDIA video adapters" in AIDA64 / main menu / File / Preferences / Stability. Please let me know if you find any issues about clocks or a stuck GPU stress test even after disabling the mentioned option. Thanks, Fiery

Thank you, we've fixed it up. Regards, Fiery

OpenCL GPGPU Stress Test has been implemented in AIDA64 v2.20: http://forums.aida64.com/index.php?/topic/660-aida64-v220-is-out/

The new AIDA64 update further enhances its System Stability Test module with OpenCL GPGPU stress test, and implements optimized 64-bit benchmarks for Intel Atom“Cedarview” processors and for the upcoming Intel Core "Ivy Bridge" APUs. New features & improvements - OpenCL GPGPU Stress Test - Support for Intel Atom "Cedarview" processors - Support for Intel Core "Ivy Bridge" APUs and Intel 7-Series chipsets - ACPI 5.0 and OpenCL 1.2 support - GPU details for AMD Radeon HD 7970 and nVIDIA GeForce GT 640 [ Press Release ] [ What's new in AIDA64 v2.20 ] [ Download ]

Yes, you can. By performing the upgrade that way your existing license and settings will be retained. BTW, the built-in Automatic Update feature would perform the upgrade the same way automatically.

Make sure to upgrade to AIDA64 v2.20 once it becomes available (less than 24 hours from now). You'll then be able to activate FPU+GPU stressing to drive your computer to maximum power draw and maximum temperatures.

The AIDA64 System Stability Test (SST) can produce the following results: 1) No visual feedbacks -- it means everything went well. In your case this happened I guess. 2) AIDA64 displays an error message on the SST user interface, and the SST window becomes red -- it means AIDA64 revealed a hardware flaw that isn't serious enough to make the computer or Windows crash, but it's still considered an instability issue. 3) AIDA64 throws an application error or crashes; or Windows throws an error message -- just like #2, it is an instability that doesn't necesserily cause a system lockup. 4) Windows throws a BSoD; or the computer locks up / reboots / powers off -- serious instability is found, but of course AIDA64 cannot provide a feedback about such issues. Please note that there are several modes in which the AIDA64 SST can operate. If you only have "FPU" (together with "GPU" with the upcoming AIDA64 v2.20 release) test enabled, SST will drive the system to its maximum temperature by executing such code that stresses the execution units of your processor (and GPU) to its maximum throughput. There are instable systems that only becomes instable when you run this kind of SST. Another mode is by executing all possible subtests of the AIDA64 SST, by having CPU + FPU + cache + system memory + local disks (+ GPU) all enabled. In such case thermal stress will not be maximum, but the workload will stress all components of the system. In several cases the instability can only be revealed by running this kind of SST. Please also note that instability is unfortunately not something you can accurately measure. It's not like universal truth of "2 + 2 = 4" Some instability can be revealed by a specific approach, by running a specific workload on the system. Some workloads may reveal a certain instability in seconds or minutes, while with other workloads it will take hours or days to reveal the problem. Regards, Fiery

The French translator doesn't handle the localization properly at times. We'll fix the line Thanks, Fiery

In order to give you a proper explanation, please copy-paste the full content of the Computer / Sensor page of AIDA64 into this topic. Also right-click on the bottom status bar of AIDA64 main window --> Video Debug --> nVIDIA SMBus Dump. Copy-paste the full results into this topic. Thanks, Fiery

Thank you, we've added the listed 3 extensions, and also 26 more extensions related to OpenGL ES. It will be rolled out as a new beta release soon. Regards, Fiery

GPU Ambient is usually the temperature of the GPU sensor chip. It is also known as GPU Environment temperature or Video Card PCB temperature. Regards, Fiery

That's not necesserily the case when special tricks make it more complicated, e.g. CrossFireX, DualGraphics, HyperMemory, etc. We'll try to figure out a reliable method.

The Direct3D KMT calls AIDA64 use are undocumented, and as far as we know, they do not provide a specific "total video memory" info. Hence we cannot calculate video memory utilization at this time

Yes, we recommend you to watch the core temperatures measured by AIDA64.

Thank you for the feedback

It is already available for over a year now You can buy a new license for 12 months, 24 months or 36 months; and you can extend an existing license with +12 months or +24 months or +36 months. 24-month licenses cost 50% more than standard (12-month) licenses. 36-month licenses cost twice as much as standard (12-month) licenses. Regards, Fiery

Sandy Bridge processors provide quite a few sensor readings (e.g. core temperatures, CPU Package temperature, etc), so it's best to watch them and ignore the rest of the readings provided by motherboard sensors (e.g. "CPU" temperature). For the most accurate sensor readings, make sure to upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.co...78fs2kxzgp9tzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Regards, Fiery